コンソールや通信を読み取るツールを接続すると、Codexはブラウザのエラーや失敗したリクエストを調べられます。Chrome DevTools MCPはChromeへの接続を提供します。まず不具合を再現し、エラーメッセージと通信を対応させます。原因のコードを修正したら、同じ操作をブラウザでもう一度確認します。
あるCodex利用者は、コンソールのエラーを繰り返しクライアントに貼り付けていたと述べました。ここではその情報をブラウザから取得します。
アカウントのいらないローカルページを例にします。取得先のパスに誤字があり、HTMLは200でもAPIは404になります。画像、コンソール、通信はそれぞれ別の手がかりを示します。
要点
MCP登録は設定の確認です。ページとスナップショットで動作中の接続を確かめます。
ブラウザが実際に要求したパスをコードのルートと照合します。
修正前のレスポンスと症状を記録します。
修正後に操作を再現して、通信、ログ、画面を確認します。
分離したブラウザを使い、報告から機密情報を除きます。
集めるブラウザの証拠
| 情報 | ツールや表示 | 記録するもの |
|---|---|---|
| 現在のページ | ページ一覧とスナップショット | URL、対象ページ、画面の症状 |
| コンソール | list_console_messages、get_console_message | エラー、ID、確認できるソース位置 |
| 通信 | list_network_requests、get_network_request | メソッド、パス、ステータス、ID、共有可能なレスポンス |
| 画面の結果 | take_screenshotまたはスナップショット | エラー表示または修正後の状態 |
| コード | Codexのプロジェクト | fetchのパスとサーバーのルート |
ブラウザ自動化エージェントはスナップショットで表示を確認できます。この例では「Could not load preferences」が見え、通信記録からどのリクエストが失敗したかが分かります。操作の仕組みはブラウザ自動化ガイドを参照してください。
1. CodexにChrome DevTools MCPを接続する
Codex CLIの公式コマンド形式でMCPサーバーを登録します。例では検証に使ったバージョンを指定し、分離したChromeをヘッドレスで起動します。利用統計と実ユーザーの性能データ取得も無効にします。
codex mcp add chrome-devtools -- npx -y chrome-devtools-mcp@1.12.0 \
--headless --isolated --no-usage-statistics --no-performance-crux
codex mcp list新しいCodexセッションでページ一覧と許可されたローカルURLを開く操作を依頼します。コマンド一覧は登録を示します。実際のページのスナップショットを取れば接続を確かめられます。OpenAIのCLIリファレンスと公式リポジトリを参照してください。
ChatGPT内蔵ブラウザには開発者モードの完全CDP設定があります。組織が制限できるため、OpenAIの開発者設定を参照します。ページを読む、押すだけならブラウザエージェントで足りる場合があります。サーバーに届く構成なら仮想ブラウザも使えます。
2. 失敗するリクエストを再現する
練習用コードを preferences-fixture.cjs として保存し、node preferences-fixture.cjs を実行します。サーバーはループバックのみで待ち受け、URLを表示します。末尾に ?stage=before を付けて開くと、テーマの取得後に「Could not load preferences」が出ます。
CodexにはURL、症状、コンソールのメッセージ、通信詳細を報告してもらいます。この例の証拠はローカルMCPクライアントからChrome DevTools MCP 1.12.0を直接呼び出して採取しました。Codex CLIの設定構文は別に確認しています。
?stage=before を付けたローカルURLを開き、設定の状態が変わるまで待つ。
URL、表示、該当コンソールメッセージ、失敗したGETのメソッド、
パス、HTTPステータスを報告する。IDで通信詳細を調べる。
このローカルオリジンだけで操作する。3. コンソールと通信を照合する
文書はHTTP 200で読み込まれました。GET /api/prefences は404で、本文は unknown route です。コンソールには [preferences] GET /api/prefences failed: HTTP 404 が出ました。これらはfetch先の誤字を示します。「リソースの読み込み失敗」だけでは対象を特定できません。
メソッドとパスを合わせてからIDで調べます。ページを移動するとIDが変わる場合があります。CORS、タイムアウト、リダイレクト、401が起きた場合は、まず観測した原因を切り分けます。
4. パスを修正して再確認する
?stage=after では取得先だけが /api/preferences になります。サーバーと画面の構造は同じです。実際のアプリでは該当箇所を直し、同じテスト環境で元の操作をやり直します。決まった秒数を待つ代わりに、確認できる表示を条件にします。
| 確認点 | 修正前 | 修正後 |
|---|---|---|
| HTML文書 | HTTP 200 | HTTP 200 |
| データ要求 | GET /api/prefences、HTTP 404 | GET /api/preferences、HTTP 200 |
| コンソール | 設定の要求に失敗 | lightの読み込みを記録 |
| 画面 | Could not load preferences | Theme: light |
通信が200でも表示が違えば、レスポンスの項目と表示処理を調べます。変わるべき要素を指定してください。最初のブラウザエージェント作業のチェックリストも参考になります。
診断の対象をテスト環境に限る
ログイン済みプロファイルには認証されたページや通信詳細が含まれます。分離したブラウザでも通信は行えるため、許可されたローカルやテスト用オリジンを使います。Cookie、認証情報、非公開レスポンスは報告に残しません。Agentic Browserの安全ガイドを参照してください。
別の開発者は手動テストで使っているセッションをそのまま調べたかったと述べています。新規プロファイルでローカルの不具合を再現するのとは別の用途です。
Webページの読み取りや操作にはTabbit Browserを使えます。コンソールと通信の情報が必要なら、使う接続方法がそのデータを提供するか確認します。TabbitとCodexの違いとTabbitの仕組みも参考になります。
修正報告には、失敗したリクエスト、変更点、症状が消えたと確かめた結果を残します。
よくある質問
CodexはChromeのコンソールを読めますか？
コンソールを公開するブラウザツールをクライアントに接続すれば読めます。Chrome DevTools MCPは選択したページのメッセージを一覧化し、IDで詳細を取得できます。
失敗したネットワークリクエストを調べられますか？
Chrome DevTools MCPでページのリクエストを一覧にし、IDで詳細を調べられます。URL、メソッド、ステータスを、失敗を起こした操作と照合します。
ページが200なのにAPIが404なのはなぜですか？
HTML文書と後から発行するAPIリクエストは別のHTTP処理です。HTMLを取得できても、スクリプトが正しいURLにアクセスしたとは限りません。
ログイン済みのChromeプロファイルが必要ですか？
ローカルで再現できる問題なら、通常は分離したChromeで足ります。ログインが必要な場合は、許可されたテスト用プロファイルを使い、機密情報は報告から外します。
Chrome DevTools MCPはChatGPTアプリの完全なCDPアクセスと同じですか？
接続経路が異なります。Chrome DevTools MCPは個別に設定するサーバーです。ChatGPTの内蔵ブラウザには独自のCDP設定と組織のポリシーがあります。
修正できたことをどう示しますか？
最初の操作をもう一度行い、リクエスト、コンソール、実際の表示を確かめます。この例では正しいパスが200を返し、Theme: lightと表示されます。