Codex の Chrome 拡張で Codex にブラウザを操作させる — 本格運用してみた所感と Claude in Chrome との住み分け
5 か月前に Claude in Chrome を本格運用してみた記事 を書きましたが、その OpenAI 側の対抗馬にあたる Codex の Chrome 拡張 が 2026 年 5 月 7 日にリリースされました（Anthropic の Claude for Chrome との対で「Codex for Chrome」と呼ばれることもありますが、OpenAI 公式の呼称としては「Chrome plugin in the Codex app」が使われており、この記事では便宜上「Codex の Chrome 拡張」と表記します）。
私は普段 Codex をターミナルからヘビーに使っているので、Codex の Chrome 拡張も出た直後から日常業務に組み込んで回しています。この記事は、その 2 か月あまりの本格運用をふまえて、Codex の Chrome 拡張の効き所と Claude in Chrome との住み分けを整理したものです。
Codex の Chrome 拡張とは何か
リリースは 2026 年 5 月 7 日、OpenAI 公式アカウントからのアナウンスは次のとおりです。
Codex now works directly in Chrome on macOS and Windows.
— OpenAI (@OpenAI) May 7, 2026
It’s even better at working with apps and sites in Chrome, and now works in parallel across tabs in the background without taking over your browser.
To get started, install the Chrome plugin in the Codex app. pic.twitter.com/pjtHd9gC69
要旨は、Codex が macOS・Windows の Chrome で直接動くようになったこと、Chrome 上のアプリやサイトとの連携が強化されたこと、ブラウザのフォアグラウンドを奪わずバックグラウンドでタブを並列に扱えること、そして Codex アプリの Chrome プラグイン経由でインストールする、という 4 点です。
Codex の Chrome 拡張は、Codex エージェントに Chrome のセッションを操作させる公式の Chrome 拡張です。macOS・Windows の Chrome で動きます。中身は、Codex 側の Web / デスクトップ / CLI から始めたセッションを、拡張機能経由で「今開いている Chrome のタブ」に橋渡しし、ログイン済みの状態のままそのタブを Codex に操作させる、という仕組みです。
OpenAI の公式アナウンス が挙げているユースケースは、大きく次のような系統です。
- Web アプリの挙動テスト（開発中のフロントを Codex に触らせて挙動を確認させる）
- タブ横断の context 収集（Salesforce・Gmail・社内 Grafana など複数の SaaS を跨いだ情報整理）
- Web DevTools 経由でのデバッグ支援
- ログイン後の SaaS 画面での操作代行
半分は開発者ワークフロー寄り、もう半分は Claude in Chrome と同じ「人間がログインまではやり、その後の操作は Codex に任せる」モデルです。数字の面では、Codex は 2026 年の年初から週間アクティブユーザーが 8 倍に伸びて 400 万を超えたと発表されており、Chrome 拡張はその成長エンジンのひとつとして位置づけられています。
導入手順
Codex の Chrome 拡張は、Chrome ウェブストアからの直接インストールではなく、Codex 側の Plugins メニュー経由で入れる作りになっています。
- Codex アプリ にサインインする（macOS・Windows のデスクトップ版か、chatgpt.com/codex の Web 版）
- Plugins メニューを開き、Chrome の項目からインストールを実行する
- Chrome 側にリダイレクトされ、拡張機能の追加を承認する
- 最初にアクセスするサイトで、そのオリジンへの操作権限を Codex に許可する
拡張機能自体が要求する Chrome 権限は、Access the page debugger・Read and change all your data on all websites・Read and change your browsing history on all your signed-in devices・Display notifications, manage bookmarks, handle downloads と、DOM 操作系拡張としては最大級の広さです。Claude in Chrome のときと同様、これはブラウザ内エージェントが DOM を見て操作するという性質上避けようがない範囲ですが、承認する前に理解しておくべきです。
Chromium 系の他ブラウザ（Brave・Arc・Vivaldi）や、モバイル Chrome への正式対応はまだありません。ここも Claude in Chrome と同じ状況です。
実際に任せて動くタスク
2 か月あまり本格運用して、日常的に任せているタスクは大きく 3 系統に分かれます。
第一が、Claude in Chrome のときと同じ読み取り主体の系統です。
- 開いている技術記事・PDF・GitHub の PR ページの要約と、そこから抽出したポイントを構造化テキストにする
- 複数の分析ダッシュボードタブ（Grafana・Datadog・BigQuery コンソール）を横断して数字を突き合わせる
- Google Calendar 上の予定を開いて、参加者リストと関連ドキュメントリンクを別タブに切り替えながらまとめる
第二が、ログイン後の SaaS 画面上での操作代行です。これは Claude in Chrome と重なる守備範囲ですが、Codex 側は「Codex 本体の会話コンテキスト・実行履歴と地続きになっている」点が実務では効きます。
- Salesforce や社内 CRM で、直近のミーティングログを他タブから拾って活動ログを起票させる
- 経費申請 SaaS で、レシート画像とカレンダー上の会議情報を突き合わせて、日付・金額・費目・目的欄を埋めさせる
- 稟議・タスク管理系 SaaS（Notion・Linear など）で、テンプレを開いた状態から具体案件のフィールドを埋めさせる
- 社内 SSO 経由で入る各種管理画面から、条件に合うレコードだけ抜き出す
第三が、Claude in Chrome にはなかった開発者ワークフロー系です。これが Codex の Chrome 拡張を Codex を使う開発者にとって明確に有利にしている部分です。
- ローカルで立てた開発サーバー（
localhost:3000など）を Codex に開かせ、実際にフォーム入力や画面遷移をさせて挙動を確認する - Chrome DevTools の Console・Network タブを Codex に読ませて、失敗している API 呼び出しを特定させる
- 本番と開発のタブを並べて開き、両者の DOM 構造の差分を報告させる
- Playwright や Selenium を書く前段として、想定されるユーザーフローを Codex に手動で通させ、そのログを元にテストスクリプトの叩き台を CLI 側の Codex に書かせる
最後の 4 つ目は特に効き所で、「テストを書くほどではないが、開発中に何度も手で押している画面」を Codex の Chrome 拡張に押させ、その結果を Codex CLI 側の実装セッションに戻して次の実装に進む、という一連のループが自然に組めます。ブラウザ拡張とターミナル側の Codex が同じ会話コンテキストにぶら下がっているので、context の受け渡しに一手いらないのが本当に楽です。
誤操作の影響が大きく、人が確認する必要のあるタスク
Codex の Chrome 拡張についても、任せるべきでないタスクは Claude in Chrome とほぼ同じです。
- 金融取引・ネットバンキング上での操作
- 医療情報・保険情報など、機微情報を含む画面上での操作
- 認証情報（パスワード・API キー）を入力する画面での操作
- ワンウェイな結果を伴う操作（送信ボタン・削除ボタン・支払い確定など）を含むフロー
Codex の Chrome 拡張は「ログイン済みの実 Chrome プロファイル」を直接触るので、Claude in Chrome よりむしろ危険側に振れた設計です。ページ内容に対するプロンプトインジェクションが刺さった場合、操作対象は本人のログイン済み Gmail・Salesforce・GitHub になります。OpenAI 側もこの点は認識していて、Codex Chrome の紹介 では per-site 確認プロンプトをデフォルトで有効化し、明示的な「always-allow」設定でのみプロンプトを外せるようにしています。
社内展開する立場としては、Codex の Chrome 拡張は Claude in Chrome より一段強いポリシー設計が必要だと感じています。特に「開発者以外にはデフォルトで配らない」「配布する場合は allowlist を狭く切る」あたりは、Codex for Business プランのポリシー と組み合わせて統制すべきポイントです。
権限モデルの構造
Codex の Chrome 拡張の権限モデルは、Claude in Chrome とほぼ相似形ですが、いくつか差があります。
| レイヤー | 何を制御するか | 誰が決めるか |
|---|---|---|
| Per-site Confirmation | 新規オリジンにアクセスするたびに操作確認プロンプト | ユーザー |
| Always-allow | 特定オリジンで確認プロンプトをスキップする設定 | ユーザー |
| Foreground / Background | フォアグラウンドタブを奪わない設計。作業は基本バックグラウンドタブで進む | OpenAI（実装） |
| Enterprise Policy | 組織単位の allowlist・blocklist、拡張機能配布ポリシー | 組織管理者 |
| Chrome Profile Isolation | どの Chrome プロファイルで動かすか（個人・仕事用の分離） | ユーザー |
Claude in Chrome との違いは 2 点あります。ひとつは Site Blocklist（銀行系・成人向けなど、Anthropic 側でそもそも操作を許さない領域）が Codex の Chrome 拡張には明示的には見当たらないこと。設計思想として「危ない領域は per-site 確認とユーザー責任で担保する」寄りに寄っています。もうひとつは Chrome Profile Isolation を意識的に運用する必要があること。私は個人用と仕事用で Chrome プロファイルを分けており、Codex の Chrome 拡張は仕事用プロファイルにだけ入れて、個人プロファイルからは触れないようにしています。
Claude in Chrome との住み分け
2 か月あまり使ってみて、Claude in Chrome と Codex の Chrome 拡張は排他ではなく、両方入れて日常業務・開発業務で使い分けるのが実務的だと落ち着きました。
flowchart TD
Q1{タスクの主戦場は開発か日常業務か}
Q1 -- 開発 --> Q2{Codex 側で既に手を動かしているか}
Q2 -- Yes --> P1[Codex の Chrome 拡張]
Q2 -- No --> Q3{再現性・CI 実行が要るか}
Q3 -- Yes --> P2[Playwright / Selenium で明示的にスクリプト化]
Q3 -- No --> P3[Claude Code の claude-in-chrome MCP]
Q1 -- 日常業務 --> Q4{Codex エージェント側の履歴と地続きにしたいか}
Q4 -- Yes --> P4[Codex の Chrome 拡張]
Q4 -- No --> P5[Claude in Chrome サイドバー]
分岐の核は「Codex エージェント側の実行履歴と地続きにしたいか」です。Codex の Chrome 拡張はターミナル・IDE・Web での Codex セッションと同じアカウント・履歴で動くので、たとえば「Codex CLI で書いた API を、Codex の Chrome 拡張でその場で画面から呼ぶ」といった往復が滑らかに組めます。この一貫性は、開発者ワークフローに関しては Claude in Chrome を上回るポイントです。
一方、日常業務（経費申請・稟議・スケジュール調整）で「開発者側の履歴と混ざる必要がない」タスクについては、Claude in Chrome のサイドバー UX のほうがカジュアルに使えます。両方入っていると気になるのが Chrome の重さですが、私は仕事用プロファイルで両方常駐させても実用上は問題を感じていません。
本格運用してみての評価
2 か月あまり本格運用してみて一番強く感じるのは、「Codex エージェントに任せられる作業の縦の広さ」が拡張機能で一段深くなった、という手応えです。ターミナル起点で始めた作業を、ブラウザ上での確認・微修正まで同じセッションで通せます。Claude in Chrome を導入して「AI エージェントに任せられるタスクの幅」が横に広がったのに対し、Codex の Chrome 拡張は「ひとつのタスクの中で AI エージェントに任せられる工程の深さ」が縦に伸びた、というのが率直な感覚です。
社内展開する立場からは、Claude in Chrome の記事のときと同じことをもう一段強く言いたいところです。Codex の Chrome 拡張は per-site 確認以外の統制手段が Anthropic 側より薄めなので、開発者以外への配布は allowlist で慎重に絞るべきです。特に「default で全社員に配って、後で問題が起きたら塞ぐ」という順序は避けたい構成です。
まとめ
- 2026 年 5 月 7 日、Codex の Chrome 拡張がリリース。macOS・Windows の Chrome で動作し、Codex 側の Plugins メニューからインストール
- Codex の Chrome 拡張の効き所は 3 系統: 読み取り主体・ログイン後の SaaS 業務・開発者ワークフロー系。特に 3 系統目は Claude in Chrome にはない差別化ポイント
- Claude in Chrome との違いは、Site Blocklist が明示的にはない点と、Chrome プロファイル分離を意識的に運用する必要がある点
- 実務的には両方入れて、日常業務は Claude in Chrome、開発の縦深化は Codex の Chrome 拡張、という住み分けが落ち着きどころ
- 社内展開する場合は per-site 確認のデフォルトを崩さず、開発者以外への配布は狭い allowlist で
以上、Codex の Chrome 拡張を本格運用してみて、Claude in Chrome との住み分けを整理した、現場からお送りしました。