SaaS の設定には、API も Terraform プロバイダもなく、管理コンソールの画面からしか変えられないものがある。
この設定を、担当者が画面をたどって毎回手作業で変えている。
Claude Code と Cursor は、どちらも実際のブラウザを操作できるようになった。
このブラウザ操作を管理コンソールに向け、画面しかない設定作業を担当者の手から外すための方針を、つまずいた点も含めてまとめる。
ここでは、画面を読み、クリックや入力を返す主体をエージェントと呼ぶ。
SaaSの設定領域
SaaS の設定作業には、自動化の素直な入口が二つある。
一つは提供元の API を叩くこと、もう一つは Terraform のようなプロバイダで宣言的に管理することだ。
どちらも使えないまま、管理コンソールの画面だけが残っている設定は多い。
権限ロールの微調整、通知ルール、監査ログの転送先、SSO の属性マッピングといった項目は、画面のフォームからしか変えられないことがある。
こうした設定は、手順としては決まっている。
どのメニューを開き、どの項目をどう変えるかは、担当者の頭の中で固まっている。
決まった手順を画面上でなぞるだけなら、機械が代われる作業だ。
ただし、この作業には API 経由の自動化にない障害がある。
画面を読んで、いま何が表示されていて、どのボタンが目的の操作に対応するかを、その場で判断しなければならない。
この判断こそ、ブラウザを操作するエージェントが引き受けられる部分だ。
エージェントとブラウザのつなぎ方
Cursor と Claude Code では、ブラウザへのつなぎ方が異なる。
Cursor は、ブラウザ操作をエディタに内蔵している。
Cursor が持つ Chromium のタブを Chrome DevTools Protocol 経由で制御し、ページの構造をエージェントへ渡す。
利用者が別途サーバを立てなくても、エディタの中から URL を開き、クリックや入力を指示できる。
Claude Code は、外部の MCP サーバを通じてブラウザにつなぐ。
代表的なサーバは三つある。
Microsoft の Playwright MCP、Google の chrome-devtools-mcp、そして browser-use だ。
いずれも ~/.cursor/mcp.json や Claude Code の設定にサーバを登録すると、ブラウザ操作のツール群がエージェントから使えるようになる。
たとえば Playwright MCP は、次のように登録する。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}この既定の設定では、エージェント専用のまっさらなブラウザが起動する。
まっさらな状態から始まるということは、対象の SaaS へのログインが済んでいないということだ。
設定作業を任せるうえで、この初期状態こそが最初の壁になる。
資格情報をエージェントに渡さない
まっさらなブラウザにログインさせる素直な発想は、SaaS の資格情報をエージェントに渡すことだ。
しかしこの経路は採らない。
資格情報を渡せば、それが会話の履歴やログに残り、漏洩したときの被害が広がる。
多要素認証や SSO が挟まると、そもそも資格情報だけではログインが完了しないことも多い。
代わりに、ログインは担当者本人が画面で済ませる。
エージェントが操作するブラウザに対して、担当者が手でログインしておき、以降の画面操作だけをエージェントに任せる。
Cursor の内蔵ブラウザなら、対象の SaaS へのログインをそのタブの中で一度だけ済ませておく。
以降の操作は、そのタブに残ったログイン状態の上で動く。
Claude Code の Playwright MCP には、この使い分けを支えるプロファイルモードがある。
既定の persistent モードは、ログイン状態と Cookie をプロファイルに保存する。
一度ログインすれば、次にエージェントを起動したときもログイン状態が残る。
一方の isolated モードは毎回まっさらから始まるため、ログインが要る設定作業には向かない。
こうして、資格情報はブラウザの中にとどまり、エージェントの側には渡らない。
担当者が判断するのはログインまでで、その先の決まった画面操作をエージェントが引き受ける。
画面を読む単位を、見た目ではなく構造に置く
エージェントに画面を読ませる方法は二通りある。
一つは画面の写真を撮って、写った内容から次の操作を決めさせることだ。
もう一つは、ページのアクセシビリティツリーを取り出し、要素の役割と名前の一覧として読ませることだ。
この後者を、ここではスナップショットと呼ぶ。
設定作業では、スナップショットを主に据える。
理由は、操作の対象を安定して指し示せるからだ。
スナップショットは各要素に一意の参照を割り当てるため、エージェントは「保存ボタン」を座標ではなく参照で指定してクリックできる。
画面の写真から座標を推定する方式は、ボタンの位置がわずかに動いただけで対象を外す。
一方で、画面の写真がまったく不要になるわけではない。
トグルの色や、保存後に出る通知の帯のように、構造には現れず見た目にだけ現れる状態がある。
こうした確認には写真が要る。
操作の指定はスナップショットで行い、結果の目視確認に写真を補助として使う、という役割分担にする。
設定変更は書き込みだと扱う
画面から情報を読むだけの操作と違い、設定変更は SaaS の状態を書き換える。
書き換えは一度実行すると戻せないことがあり、途中で失敗すると中途半端な状態が残る。
そこで、操作を「観察、実行、検証」の一歩ずつに分けて進める。
まずスナップショットで現在の画面を観察し、目的の項目が想定どおりに表示されているかを確かめる。
次に、その項目に対して一つの操作だけを実行する。
最後に、もう一度スナップショットを取り、変更が反映されたことを確認してから次へ進む。
この分け方は、冪等性の確保にもつながる。
設定をある値に「する」という指示は、すでにその値であれば何もしないでよい。
観察の段階で現在値を読めば、同じ操作を繰り返しても二重に適用されず、途中から再開しても破綻しない。
書き込みを盲目的に繰り返さないための足場が、観察の一歩にある。
エージェントを迷子にさせない
ブラウザを操作するエージェントは、目的の画面から離れてしまうことがある。
関連しそうなリンクをたどり、別の設定画面を開き、意図しない項目に触れる。
設定作業では、この逸脱がそのまま誤った書き込みになる。
逸脱を抑えるための歯止めが二つある。
一つは、操作の範囲を対象のタブに固定することだ。
Cursor の内蔵ブラウザにはタブをロックする操作があり、自動操作の間はそのタブ以外に影響が及ばない。
もう一つは、破壊的な操作の手前で必ず人の確認を挟むことだ。
削除や不可逆な変更を含む手順は、エージェントに実行まで任せず、最後のクリックを担当者に残す。
ログインと同じく、人が引き取るべき場面もある。
多要素認証のコード入力、決済の承認、規約への同意は、担当者本人が判断する場面だ。
これらに差しかかったら、エージェントは操作を止めて担当者に手渡す。
エージェントが担うのは、判断の要らない画面遷移と入力の連なりに限る。
手順を固定するか、都度探索させるか
エージェントの強みは、初めての管理コンソールを手探りで進み、どのメニューにどの項目があるかを突き止める探索にある。
同じ設定を何度も繰り返すなら、この探索の結果を固定した手順に落とす価値がある。
Playwright MCP は、実行した操作を Playwright のスクリプトとして書き出せる。
一度エージェントに探索させて正しい手順を確定したら、その手順をスクリプトとして保存する。
以降の定常運用では、探索を伴わないスクリプトを流すだけで済み、実行のたびに結果がぶれない。
ただし、固定した手順は画面の構造に依存する。
管理コンソールのレイアウトが定期的に変わる SaaS では、保存したスクリプトが要素を見失って壊れる。
壊れるたびにスクリプトを書き直すのは、手作業に戻るのと変わらない。
こうした変わりやすい画面では、手順を固定せず、都度エージェントに探索させるほうが適切に動く。
エージェントは実行のたびに現在の画面をスナップショットで読み直し、名前や役割から目的の要素を見つける。
レイアウトが変わっても、担当者がメニューの新しい位置を探し直して悩む前に、エージェントが今の画面に合わせて操作を組み立てる。
つまり、画面の変わりやすさで二つを使い分ける。
構造が安定している設定は、スクリプトに固定して結果を揃える。
構造がよく変わる設定は、エージェントの探索に任せて変更への強さを取る。
担当者が判断するのは、どの設定をどの値にするかという方針だけになる。
この方法が向く条件
ブラウザをエージェントに操作させる方法は、次の条件がそろうときに有効だ。
- 変えたい設定が、ログイン済みの画面からは変えられる：API や IaC がないだけで、画面操作としては存在する。
- 操作する担当者が、その SaaS にログインできる：担当者本人がログインした状態で操作を始められる。
- 操作を担当者の権限の範囲にとどめられる：本人ができる設定変更を自動化するだけで、権限の昇格を伴わない。
逆に、無人のバッチで定期実行したい場合や、担当者がログインしない経路で動かしたい場合には向かない。
その場合は担当者のログインを挟めず、結局エージェントに資格情報を持たせることになるからだ。
API がないことは、設定を自動化できない理由にはならない。
担当者がログインした画面をエージェントに操作させれば、画面しかない設定作業にも自動化の手が届く。
