CodexのCLI・Chrome拡張・Computer Useを使い分ける判断基準¶

画面操作をAIに任せる前に決めること¶

対象 / ポイント

対象: Codex appでCLI、in-app browser、Chrome拡張、Computer Useの使い分けに迷っている開発者。

ポイント:

CLIで済ませる作業と、画面操作へ渡す作業を分けられる
ログイン済みChrome、GUI、複数アプリケーション横断の使いどころが分かる
Windows/Macでの最小設定、サイト許可、トラブルシュートを確認できる

Salesforceのキャンペーン画面で、リード一覧の列だけが本番環境で崩れる。 CIは通っている。APIでデータを取ると正常に見える。しかし、ログイン済みChromeで画面を開き、フィルターを押し、表の横スクロールとモーダルの重なりを見ないと症状が分からない。

このような作業では、CodexにChromeやComputer Useを使わせる価値が出る。逆に、コード編集、テスト実行、ログ検索、APIレスポンス確認ならCLIがよい。 CLIは再現性が高く、差分もレビューしやすい。

この記事の核心は、設定手順ではない。 AIに画面操作を任せる前に、CLI・in-app browser・Chrome拡張・Computer Useのどれを使うかを決める判断基準だ。

判断基準：CLIで足りる作業を先に外す¶

このセクションの問いは、どの作業を画面操作に渡さずCLIに残すかだ。

まず前提として、CLIで完結する作業はCLIに任せる。たとえば、テスト実行、lint、ログ検索、ファイル編集、APIレスポンス確認はCLIが速く、監査もしやすい。

Computer Useを使う価値が出るのは、作業対象が「ファイル」や「コマンド出力」ではなく、 画面上の状態にあるときだ。ボタンが押せるか、モーダルが重なるか、社内SaaSのフォームに何が表示されているかは、 CLIだけでは判断しにくい。

判断基準	CLI向き	Computer Use / Chrome向き
対象	コード、ログ、テスト、API	画面、ログイン済みサイト、GUIアプリケーション
再現性	高い。同じコマンドを再実行できる	画面状態やログイン状態に依存する
レビュー	Git diffや標準出力で追いやすい	スクリーンショット、操作結果、許可範囲の確認が必要
使う理由	速い、確実、監査しやすい	CLIでは見えない状態を確認・操作できる

Computer UseはCLIの上位互換ではない。 CLIの外に残るGUI作業を回収する補助線として考えると、使いどころが見える。

3つの面を選ぶ¶

このセクションの問いは、画面操作が必要だと分かったあと、どの面をCodexに使わせるかだ。

結論はシンプルだ。 localhostや公開ページはin-app browser、ログイン済みChromeが必要なサイトはChrome拡張、画面操作そのものが必要なアプリケーションはComputer Useに分ける。

使う機能	向いている作業	避けたい作業
in-app browser	localhost、ファイルプレビュー、ログイン不要の公開ページ	認証フロー、Cookie、既存タブ、Chrome拡張が必要なページ
Chrome拡張	Gmail、Salesforce、LinkedIn、社内ツールなどログイン済みサイト	ログイン状態が不要なローカル確認
Computer Use	GUIでしか見えない状態、複数アプリケーション横断、通常アプリケーション内の作業	APIや専用プラグインで処理できる定型データ操作

OpenAIのdocsでも、ローカル開発サーバーやログイン不要ページは in-app browserを先に使うよう案内されている。¹ Chrome拡張は、Codexがサインイン済みブラウザー状態を必要とするときの道具だ。² Computer Useは、Codexがアプリケーションを見て、クリックし、入力する必要がある場合に使う。³

ここを混ぜると、余計な権限を渡しやすい。 Chrome連携は便利だが、最初から全ブラウザー作業に使うものではない。

活用事例：画面操作が価値になる3パターン¶

このセクションの問いは、CLIではなく画面操作を使うメリットが実務でどこに出るかだ。

実務でComputer UseやChrome連携が効くのは、GUI状態、ログイン済み状態、複数アプリケーション横断のどれかが入る作業だ。 OpenAIのユースケースでも、通常のアプリケーションUIをクリック・確認・入力する仕事や、アプリケーション間を移動する仕事が例として挙げられている。⁴

パターン	何が便利か	CLIでは弱い理由
ログイン済み管理画面の確認	社内SaaS、CRM、管理コンソールを実際のログイン状態で確認できる	認証、Cookie、テナント状態をCLIで再現しにくい
GUIだけで出るバグ再現	hover、drag/drop、モーダル、フォーカス移動を実画面で追える	DOMやテストでは実際の見え方を取り逃がすことがある
ブラウザー拡張込みの検証	パスワード管理、翻訳、社内拡張など込みで確認できる	in-app browserは通常のChromeプロファイルや拡張を使わない
生成物の目視確認	PDF、スライド、表計算ファイルの崩れを画面で確認できる	ファイル構造は読めても、見た目の崩れは別問題
社内ツール間の下書き	Slack/Notion/CRM/採用管理などを見比べて下書きできる	API連携が未整備だとデータ取得から詰まる

1. ログイン済み管理画面の表示崩れを再現する¶

問い合わせは「本番のCRMで、特定キャンペーンのリード一覧だけ横に崩れる」。 CLIでAPIを叩く → データは正常 → @Chrome で検証用アカウントの該当画面を開く。キャンペーン名でフィルターする → 表の列幅、横スクロール、モーダルの重なりを見る。 DOMとCSSの仮説を出す → CLIで修正する → 同じURLで再確認する。

この流れでは、Chrome拡張がログイン済み状態を引き受け、CLIが修正とテストを引き受ける。どちらか片方に寄せるより、役割分担した方が速い。

2. Chromeプロファイルや拡張前提の動線を確認する¶

社内SSO、パスワード管理、翻訳、検証用拡張が入ったChromeプロファイルでしか再現しない不具合がある。 Codexに対象サイトを開かせる → SSO後の画面を確認する → 拡張が挿入したUIの有無を見る → 送信や権限変更は止める → 見えた症状だけを報告させる。

この作業は、in-app browserでは弱い。 in-app browserはローカル確認には向くが、通常のChromeプロファイル、既存タブ、拡張を前提にしない。¹

3. 生成物を画面でレビューしてからCLIへ戻す¶

レポート生成スクリプトでPDFやスライドを作る。 CLIでファイルを生成する → Computer UseでビューアーやPowerPointを開く。ページ末尾の文字切れ、表のはみ出し、グラフ凡例の重なりを見る。問題のページ番号と症状を返す → CLIでテンプレートを直す。

ファイル構造が正しくても、見た目が崩れることはある。この場合、Computer Useは「修正する人」ではなく「画面で崩れを見つけるレビュー担当」として使う。

実用プロンプトは、操作範囲を先に狭めると扱いやすい。

@Chrome stagingのCRMでキャンペーン「Spring-2026」のリード一覧を確認してください。

目的:
- フィルター適用後に表の列幅や横スクロールが崩れるかを見る

操作範囲:
- 閲覧、フィルター変更、表示確認だけを行う
- 送信、削除、権限変更、外部共有は行わない

出力:
- 再現手順
- 画面で見えた症状
- 関係しそうなDOM/CSSの仮説
- CLIで修正する候補ファイル

npm test、rg、git diff、APIのJSON確認で足りるなら、Computer Useを使う理由は薄い。その線引きを持っておくと、権限を広げすぎずに済む。

運用ルール：許可を狭くして結果を疑う¶

このセクションの問いは、ChromeやComputer Useを使うとき、どこまで許可するかだ。

Codexは、新しいWebサイトを操作する前に確認を求めるのが基本だ。許可はホスト名単位で扱われ、現在のチャットだけ許可、常に許可、拒否を選べる。²

日常運用では、次の方針が扱いやすい。

localhostや自社検証環境は必要に応じて許可する
本番管理画面はチャット単位の許可に留める
決済、認証、セキュリティ設定の画面は常時許可にしない
不審なページや不要な外部サイトはblocklistへ入れる
送信、購入、権限変更を伴う操作は人間が最終確認する

Browser historyは別枠で慎重に扱う。公式docsは、履歴には内部URL、検索語、他デバイスの活動などが含まれうると説明している。² Codexが履歴を使いたい場合は都度確認され、常時許可の選択肢はない。²

Chrome連携は、ログイン済みブラウザー状態を一時的に貸す機能だ。 Codex用のChromeプロファイルを分け、機密画面を閉じてから始めると監査しやすい。

最小設定：必要になってからつなぐ¶

このセクションの問いは、判断したあと、どこを設定すれば使い始められるかだ。

Chrome連携を使う前に、Codex appをLocalまたはWorktreeで動かせる状態にしておく。 Codex appはmacOSとWindowsで提供され、プロジェクトを選び、Localを選ぶとローカルマシン上で作業できる。⁵⁶ Windows版はPowerShell上のネイティブエージェントやWindows sandbox、WSL2構成にも対応している。⁷

最小の前提は次の4つだ。

Codex appにChatGPTアカウントまたはOpenAI APIキーでサインインしている
対象プロジェクトをCodex appに追加している
ローカルWebアプリケーションなら開発サーバーを起動できる
Git差分を確認できる状態にしている

Chrome連携だけを先に入れても、作業対象が曖昧だと危うい。先に「どのURLを開くか」「どのアカウントでログイン済みか」「何を変更してよいか」を決めておく。

Chrome連携は、現在のCodex appでは 設定 > 設定 > コンピューターの使用 から管理する。この画面に Google Chrome が表示され、管理 から接続状態や許可を確認できる。

公式docsでは、Plugins からChromeプラグインを追加し、セットアップフローに従ってChrome拡張のインストールまたは接続と権限承認を進める流れも案内されている。² つまり、初回追加はプラグイン導線、日常の確認・許可管理は コンピューターの使用 画面、と捉えると迷いにくい。

設定後はChrome側でCodex拡張が Connected と表示されることを確認する。新しいCodexスレッドを開始すると、Codexはログイン済みWebサイトが必要なタスクでChromeを提案できる。明示したい場合は、プロンプトで @Chrome を使う。

@Chrome open the internal dashboard, check the failed deploy page,
and summarize only the visible error messages.

Chromeが開いていない場合、CodexはChromeを開ける。 Chromeでのブラウザー作業は、スレッドごとにタブグループとしてまとまりやすい設計になっている。²

Computer UseはChrome拡張とは別の層だ。アプリケーションをCodexが見て、クリックし、入力するための機能で、画面操作そのものが必要なタスクに使う。³

セットアップは 設定 > 設定 > コンピューターの使用 でComputer Use関連の項目を確認する。 macOSでは次の権限が求められる。³

Screen Recording: Codexが対象アプリケーションを見るため
Accessibility: Codexがクリック、入力、移動するため

Windowsでは、Codex app自体がWindows対応で、プラグインやin-app browserなどの中核機能もWindows版で扱える。⁷ Computer Use設定が表示されている環境では、同じく対象アプリケーションと許可範囲を狭くして使う。ただし、OS側の権限名や確認ダイアログはmacOSと同じではない。

実行時は @Computer または @AppName を指定し、対象アプリケーションと操作範囲を狭く書く。

Open @Chrome and verify the checkout page still works.
Do not change account settings or submit any payment form.

Computer Useは、プロジェクト外のアプリケーションやシステム状態にも影響しうる。そのため、許可プロンプトは流れで承認せず、対象アプリケーションが正しいかを毎回見る。

うまく接続できないときの確認順¶

このセクションの問いは、Chrome連携が動かないときにどこから確認するかだ。

Chromeに接続できないときは、いきなり再インストールするより、状態を上から潰す。公式docsのトラブルシュートは、拡張の接続状態、プラグインの有効化、Chromeプロファイルの一致を先に確認する流れだ。²

確認順は次で十分だ。

Chromeツールバーまたは拡張メニューでCodex拡張を開き、Connected か確認する
設定 > 設定 > コンピューターの使用 でGoogle Chromeが接続済みか確認する
Codex拡張を入れたChromeプロファイルで作業しているか確認する
新しいCodexスレッドで同じChromeタスクを試す
ChromeとCodexを再起動し、必要ならChrome連携を削除して追加し直す

ファイルアップロードが必要なChromeタスクでは、Chrome拡張の詳細画面で Allow access to file URLs を有効にする必要がある。² ローカルHTMLやファイルプレビューを扱うときに見落としやすい点だ。

まとめ¶

CodexのChrome連携やComputer Useは、CLI作業を置き換えるための機能ではない。 CLIで見えない画面状態、ログイン済み状態、アプリケーション横断作業だけを任せるのが安全な始め方だ。

ローカルWebアプリケーションはin-app browser、ログイン済みサイトはChrome拡張、デスクトップアプリケーションやGUI横断タスクはComputer Use。この3つを分けておけば、権限を広げすぎずにCodexの画面操作を活かせる。

次に効いてくるのは、ブラウザー権限の標準運用だ。チームで使うなら、どのホストを許可するか、どの操作は人間承認に残すかを先に決める。 Chrome連携は個人の便利機能ではなく、AIエージェントにログイン済み画面を見せる運用設計として扱うべきだ。