Codex にブラウザ操作を任せたいが、built-in browser で足りるのか、Chrome extension を使うべきなのかで迷いやすいです。特に社内SaaS、管理画面、広告管理、CRM、認証付きドキュメントのように、すでに Chrome でログインしている画面を扱う場合、便利さとリスクが同時に増えます。
この記事では、2026年7月29日時点の OpenAI 公式ドキュメントを前提に、Codex Chrome extension を既存Chromeプロファイルへ接続するときの運用境界を整理します。built-in browser で localhost や公開ページを確認する話は Codex browser use ガイド、Codex の外部通信そのものは Codex internet access 安全運用ガイド、作業ごとの権限切替は Codex config profile 設計ガイド、plugin と skill の責務分担は Codex Plugins と Skills の違い、Remote host 側の副作用は Codex Remote 設計ガイド に分けています。
今回扱うのは、Chrome profile、signed-in session、open tabs、site permission を Codex にどう見せるかです。
先に結論: Chrome extension は「既存ログイン状態が必要な作業」だけに使う
Chrome extension は、普段使っている Chrome の文脈を Codex に渡せる点が強いです。既存のログイン状態、開いているタブ、Chrome 拡張、社内ツールの表示状態が必要な作業では、built-in browser より速く進みます。
ただし、私は最初から Chrome を既定にはしません。
| 使うもの | 向いている作業 | 注意点 |
|---|---|---|
| built-in browser | localhost、公開ページ、短いUI確認 | 通常の Chrome profile とは別状態 |
| Chrome extension | 既存ログイン、開いているタブ、Chrome拡張が必要 | 個人セッションや機密タブを巻き込みやすい |
| 専用plugin / connector | Gmail、Drive、GitHub、Notion など明確な外部サービス | ブラウザ画面ではなくAPI接続の権限設計が必要 |
判断基準は単純です。
Chrome extension を使う条件:
- その作業に既存Chromeログインが必要
- 対象タブや対象URLを具体的に指定できる
- Codex が触ってよいアカウントを人間が確認できる
- 送信、削除、公開、権限変更を別承認に分けられる
built-in browser で足りる条件:
- localhost や公開ページを見ればよい
- 新しいログインで問題ない
- 既存タブやChrome拡張に依存しないChrome extension は「ブラウザ操作の上位版」ではありません。自分の Chrome 状態を使わせる必要があるときの専用レーンです。
既存プロファイルを使う前に閉じるものを決める
OpenAI の docs では、Chrome extension はすでにサインインしているサイトや内部ツールで read / act できると説明されています。これは実務では強力ですが、Chrome profile には作業対象外の情報も載っています。
私なら、Codex に Chrome を使わせる前に次を確認します。
- 対象作業に使う Chrome profile か
- 別アカウントでログインしていないか
- 作業対象外の機密タブを閉じたか
- 入力途中のフォームや管理画面が残っていないか
- パスワードマネージャや決済画面が前面に出ていないか
たとえば、広告管理画面を見せたいだけなのに、同じ window に本番管理画面、個人メール、請求設定、社内ダッシュボードが並んでいる状態は避けます。Codex が勝手に全部読むとは限りませんが、作業対象を狭くする責任は人間側にあります。
Chrome profile は「ブラウザ」ではなく「権限の束」です。作業前に window を分ける、不要タブを閉じる、専用 profile を使う。この程度の手間で、事故の面積はかなり下がります。
site permission は allowlist と blocklist を運用単位で分ける
Chrome extension で一番重要なのは、どのサイトを Codex に触らせるかです。OpenAI docs では、ChatGPT / Codex が新しい website を使う前に確認し、許可済みサイトや blocklist は settings から管理できると説明されています。
私は次の3段階で分けます。
| レベル | 許可の考え方 | 例 |
|---|---|---|
| one-off allow | その場の1タスクだけ許可 | 公開pricingページの比較 |
| scoped allow | 特定hostだけ継続許可 | staging.example.com のUI確認 |
| blocklist | Codex に触らせない | production admin、billing、personal mail |
最初から「よく使うから全部許可」にしない方がよいです。Chrome extension の価値は、普段のブラウザ状態を使えることです。つまり、許可も普段使いの便利さに引っ張られやすいです。
実務では、次のように運用メモを置くと判断が揺れません。
chrome_access_policy:
allowed:
- host: staging.example.com
purpose: UI reproduction and screenshot verification
actions: read, click, filter, export csv
forbidden: submit payment, change role, delete record
- host: docs.example.com
purpose: read-only product docs lookup
actions: read, search
forbidden: edit, publish
blocked:
- host: admin.example.com
reason: production write surface
- host: billing.example.com
reason: payment and plan changesここで大事なのは、host だけでなく action も書くことです。閲覧は許すが submit は許さない、検索は許すが公開は許さない、という境界がないと「Chrome を許可した」が作業全体の白紙委任になります。
依頼文は tab、account、action、stop condition で固定する
悪い依頼はこうです。
@Chrome で管理画面を見て、よさそうに直してこれでは、どのタブ、どのアカウント、どの操作まで許しているのかが曖昧です。Chrome extension では、最低限この粒度にします。
Use @Chrome only on the currently active tab:
https://staging.example.com/reports/acquisition
Before acting, confirm the visible account name is "staging-admin".
Inspect the weekly activation chart and identify why the export button is disabled.
You may click filters and open read-only details.
Do not submit forms, change permissions, delete records, or export customer data.
Stop and ask if the page switches to production, billing, or a different account.私が必ず入れるのは、次の4点です。
- 対象 tab / URL
- 確認すべき account / environment
- 許可する action
- 止まる条件
Chrome extension では、Codex が見える画面の情報量が多いです。だからこそ、依頼文は短くても境界だけは硬くします。
「専用pluginで済む仕事」をChromeへ逃がさない
OpenAI docs では、専用 integration がある場合は plugin、ログイン済み browser context が必要な場合は Chrome、localhost などは built-in browser という使い分けが説明されています。
これはかなり重要です。Chrome extension は万能に見えますが、すべての外部ツール操作をブラウザ経由に寄せると監査しづらくなります。
私ならこう分けます。
| 作業 | 優先する入口 |
|---|---|
| Google Drive の文書を読み、要約する | Google Drive plugin |
| GitHub PR の差分を読み、レビューする | GitHub plugin / Codex GitHub integration |
| localhost のUIを確認する | built-in browser |
| 社内SaaSのログイン済み画面を確認する | Chrome extension |
| Chrome拡張依存の画面を再現する | Chrome extension |
Chrome を使う理由が「API接続を設定するのが面倒だから」なら、少し危ないです。API / plugin は scope、audit、対象データが比較的説明しやすい一方、Chrome は画面に出ている文脈をまとめて扱います。
plugin は Codex Plugins と Skills の違い で書いた通り、外部接続と配布単位です。Chrome extension は、専用pluginが届かない「人間がブラウザで見ている状態」を扱うときに使う方が役割が立ちます。
Developer mode は「Chromeの中を深掘りする権限」として別扱いにする
Developer mode は、Chrome や built-in browser で console、network、DOM、applied styles、performance trace などを見るための強い確認手段です。OpenAI docs では full CDP access を有効化できる一方、機微な browser internals に触れ得るため、利用前に明示承認が必要だと説明されています。
Chrome extension と Developer mode を同じ許可にしない方がよいです。
通常Chrome操作:
- ページを読む
- ボタンを押す
- filter を切り替える
- 表示状態を確認する
Developer mode:
- console error を読む
- network request / response shape を見る
- DOM / computed style を調べる
- performance trace を取る単なる画面確認や文言確認に full CDP access は不要です。API が失敗している、console error が出ている、CSS の適用元が分からない、performance が重い、というときだけ上げます。
組織運用なら、Developer mode をユーザー裁量で開けるか、managed configuration で無効化するかも決めておきます。日常作業の便利さより、どの browser internal へアクセスさせたかを説明できることを優先します。
実務で使う最小runbook
私が Chrome extension を使うなら、毎回この順番にします。
- 専用pluginか built-in browser で済まないか確認する
- 対象 Chrome profile と account を確認する
- 不要な機密タブを閉じる
- 対象URLと許可 action を依頼文に書く
- website access の許可を host 単位で確認する
- 送信、削除、公開、権限変更は別承認にする
- 最後に Codex の説明ではなく、画面・差分・操作ログを見る
たとえば、社内ダッシュボードの表示崩れを見る依頼ならこうです。
Use @Chrome on the current staging dashboard tab only.
Confirm the page is staging, not production.
Check the account menu and report the visible workspace name before acting.
Reproduce the table overflow at 390px width.
You may inspect the page and click filters.
Do not export, submit, delete, publish, or change permissions.
After proposing a fix, use the repo diff and browser evidence to report what changed.ここまで書くと長く見えますが、実務ではテンプレート化できます。毎回考えるべきなのは、対象URL、account、許可action、止まる条件だけです。
接続できないときの確認順
Chrome extension が動かないときは、いきなり再インストールしません。OpenAI docs の troubleshooting に沿って、まず状態を切り分けます。
- 対象 website が blocklist に入っていないか
- Chrome extension が有効か
- Codex / ChatGPT 側で Chrome plugin が有効か
- 使っている Chrome profile に extension が入っているか
- 新しい chat で接続状態が戻るか
特に複数 profile を使っている場合、「普段の Chrome では入っているが、今開いている profile には extension がない」が起きます。Chrome extension の問題に見えて、実際は profile 違いということが多いです。
まとめ
Codex Chrome extension は、既存の Chrome profile、ログイン済みセッション、開いているタブ、Chrome拡張が必要な作業にだけ使うと強いです。built-in browser で足りるUI確認や、専用pluginで扱える外部サービスまで Chrome に寄せると、便利さより監査しづらさが勝ちます。
運用の要点は、Chrome を許可する前に「どの profile / account / URL / action を見せるか」を決めることです。site permission は host と action の両方で管理し、送信、削除、公開、権限変更は別承認に分ける。Developer mode は console / network / DOM / performance が必要なときだけ上げる。
Chrome extension はレビューを省くための機能ではありません。人間がすでに持っているブラウザ文脈を、狭い範囲で Codex に渡すための機能です。ここを守ると、社内SaaSやログイン済み画面でも、作業速度と安全運用を両立しやすくなります。