ログイン済みのブラウザに DevTools で繋ぐまでの往復

支援先が使っている会員管理システムを Chrome で開いたまま、「この画面に何が見えているか教えてください」と Claude Code に頼んだ。 返ってきたのは、この端末には使用許諾がないという趣旨の画面だった。

自分のディスプレイには事業者の一覧が出ている。 道具の側は、その手前で止まっていた。

どのブラウザを見ているのか

最初に引っかかったのは、プロファイルのロックだった。

Chrome DevTools MCP が自前の Chrome を起動しようとして、既存のプロファイルとぶつかった。 別セッションが立ち上げたまま残していた自動操作用の Chrome がまだプロファイルを掴んでいる。 1時間半ほど放置されていたものだったので、終了させてロックを外させた。

途中でブラウザの履歴を読ませようとしたところは分類器にブロックされた。 妥当な線引きなので、深追いはさせていない。

ロックが外れて MCP 側のブラウザは起動した。 それでも画面は変わらない。

ここで理由が分かった。 このシステムは、ログインの前段に端末ごとの使用許諾登録を挟む。 許諾の情報は、JavaScript が書き込むクライアント側の Cookie に保持される。 フレームセット構成で文字コードは Shift-JIS というそこそこ古い作りでもあった。

Chrome DevTools MCP が動かしていたのは、その Cookie を一つも持たない専用プロファイルだ。 自分が見ている画面と道具が見ている画面は最初から別物だった。

「そうではなくて、私のログイン済みの Chrome のプロファイルでやってほしい」と言い直した。

拡張機能経由という別の経路

次に試したのは、claude-in-chrome の拡張機能だった。 最初は繋がらなかった。 実 Chrome 側で有効になっているかを確かめてから再接続させたら通った。

新しいタブが開き、スクリーンショットにポータルのトップ画面が写った。 ここで一度、見えるようになった。

分かったことは全部 HTML のドキュメントにまとめさせた。 自分が忘れるからで、あとで開き直せる形にしておきたかった。 スクリーンショット2枚を埋め込んで、支援先用のリポジトリの当日メモに置かせた。

ただしこの時点で、同じブラウザをもう一つの Claude Code セッションが操作していた。 操作がぶつかるので、こちらの自動操作は一旦止めさせた。

許可のダイアログが出ない

止めている間に、別セッションからの報告が上がってきた。

トップ画面の一覧からリンクを1件クリックしたら、新しいタブが開いた。 そこは別システムのログイン画面で、社内グループウェアだった。 パスワードの入力が要るので、そこから先は自分で操作するしかない。 ID とパスワードの入力は AI にやらせない。 線はここで引いた。

セキュリティは思ったより厳しく、操作の途中で強制ログアウトも起きた。 ボット検知が働いているらしい。

厄介だったのは、どのセッションが何をやったのかが混ざったことだ。 こちらのセッションが実行したのは、ページ移動が1回とスクリーンショットが2回だけだった。 リンクのクリックは別セッションの仕業だ。 同じ拡張機能と同じタブグループを二つのセッションが共有していたので、報告だけを読むと自分の操作に見える。 事実関係の確認から入り直すことになった。

そのあと、Cookie は共有されているのかを確かめさせた。 同じプロファイルなので共有されていて、タブを開き直しただけでログアウト用のボタンが増えていた。 どこかでログインした認証済みのセッションがこちらのタブにも反映されている。

それでも、自分が見ている一覧までは辿り着かない。

引っかかったのは、許可のダイアログが一度も出ていないことだった。 ログイン済みの Chrome に DevTools で繋ぐなら、ブラウザ側に「この接続を許可するか」の確認が出るはずだ。 それが出ていない。 つまり、そもそも実 Chrome には繋ぎに行っていない。

「あの許可のダイアログ出てないし」と伝えて、そこを直させた。

実 Chrome に繋ぐための条件

原因は登録の中身だった。 Chrome DevTools MCP は自分専用のプロファイルを新規に起動するだけの設定になっていて、実 Chrome を探しに行っていない。 --autoConnect を付けて登録し直させた。

Chrome 136 で既定のプロファイルへのデバッグ接続そのものが塞がれ、144 以降になって、ブラウザ側で許可を出せば繋げる経路が戻ってきた。 その許可は自分でオンにした。

Claude Code からは「設定を反映するにはセッションを開き直す必要がある」と返ってきた。 起動済みのプロセスが古い引数のまま動くから、という説明だった。 これ自体は間違っていない。 ただ、リコネクトは済んでいるはずだったので、開き直す前にもう一度試させた。

繋がった。 実 Chrome の全タブが一覧で返ってきて、自分が開いていたページがそのまま見えた。 新しいセッションを立てる手間は、結果としては要らなかった。

画面の裏で何を叩いているか

繋がったところで、方針を変えた。

ボット検知が厳しい相手に画面操作を積み重ねるのは筋が悪い。 それより、この画面が裏で何を叩いているかを知りたい。 内部 API の仕様を調べさせることにした。

すでに発生していた通信を読み取り専用で解析させたら、構造はかなり見えた。 参照系と更新系が処理名の末尾で区別される命名規則になっていて、リクエストの組み立て方も追える。 レスポンスに伏せるべき値が混ざっていたので、そこは落として構造だけドキュメントに残させた。

ここで一度、書き込みは見送りたいと返ってきた。 開いていたのは検証用のダミー環境ではなく、実在の事業者の本番記録だったからだ。 相談記録の入力欄には本物のやりとりが入っていて、ログインしているのは支援先本人のアカウントだった。

その判断は自分がする話なので、テストしたいと伝えて実行させた。 あとで消しやすいよう、テストと分かる文言を入れて更新ボタンを押させた。

POST が1本増えて、200 が返り、一覧画面に戻った。 更新系の API が想定どおりの命名で動くことが確認できた。 書き込んだテキストは、後で自分の手で消した。

音声から起こすか、手元の資料を渡すか

もともとこのシステムには、別の効率化案が出ていた。 面談の音声を AI に読ませて議事録を自動生成し、システムに入力すべき項目を整理させてチャットに出す。 それを人間が画面に転記する、という形だ。

今回のやり方を見て、そこは変えることにした。 スライドや文書やフロー図といった手元の資料をこちらから渡して、まず概要を把握させる。 音声から起こして人間が転記する経路より、こちらのほうが早い。

その場で計画書を HTML にまとめさせた。 これも自分が忘れるからで、渡す資料が揃った時点で読み返せるようにしておきたかった。

残った未了事項

セッションの終わりに、分かったことがドキュメントに揃っているかを照合させた。

抜けは出た。 書き込みテストの後片付けが終わっていないのに、注意事項の節は古い記述のままだった。 強制ログアウトの件も未解明事項に入っていない。 両方を追記させ、ブラウザで開き直して崩れがないところまで確かめた。

そのあと2回、別のセッションで拾い直している。 夕方に計画書のステータスを確認させたら、まだ構想段階のままで、次のアクションはどれも未着手だった。 夜には、その日に作った計画書と記録を全部読ませて積み残しを洗い出させた。 5系統出てきて、最優先は本番データに手を入れたままの件だった。 そこは自分で消してあるので、クリーンアップ済みとしてドキュメントを更新させた。

途中で Overloaded と接続切断に1回ずつ当たったが、続きから再開すれば済んだ。

学び

• ブラウザ越しの調査は、まず「どのプロファイルを見ているか」を確定させる。画面が出ないのは権限の問題とは限らず、別の Chrome を見ているだけのことがある
• 許可ダイアログが出ないことは、接続できていない証拠として使える。繋がっているつもりで設定をいじり続けるより早い
• 同じブラウザを二つの自動操作ツールで同時に触らない。操作の帰属が分からなくなり、事実関係の確認から始めることになる
• ID とパスワードの入力は自分でやる。AI に渡す範囲はここで切る
• 検知が厳しい相手には、画面を操作し続けるより内部の通信を読むほうが静かで速い
• 「設定の反映には再起動が必要」と言われても、リコネクト済みなら一度試させる価値はある
• 分かったことはその場で HTML にまとめておく。忘れるし、別セッションで拾い直すときの入力になる