Codex Computer Use と内蔵ブラウザの実践: エージェントにページを見せ、アプリを操作させ、フロントエンドを反復する

フロントエンドを直しても、スクリーンショットだけでは agent に本当の見え方が伝わらないことがあります。だったら、agent 自身にブラウザを開かせてページを見せ、その場でコメントさせ、さらに続けられたらどうでしょう。

macOS では、agent が複数アプリをバックグラウンドで並列処理している間に、あなたはコードを書き続けられます。Windows では、agent がカーソルを引き継ぐので、いったん他の作業を止める必要があります。フロントエンドの反復では、コードを直し、ブラウザを開かせ、ページでコメントし、また直す。この流れがそのまま実用になります。Computer Use と内蔵ブラウザの価値は、こうしたワークフローを作れることにあります。プラットフォームの違いが作業の仕方を決め、安全境界が権限の線を決めます。

1. Computer Use の基礎: カーソルでアプリを見て、クリックして、入力する

1.1 「完全接管」ではなく、「目的を伝えると GUI を操作する」

Computer Use は、Codex が自分のカーソルで PC 上のアプリを見て、クリックして、入力する機能です。公開 API のないデスクトップツールも含めて操作できます。たとえば「この PDF を Word に変えて」と伝えると、Codex はフォーカスを移し、ウィンドウをクリックし、テキストを入力して GUI の流れを完了します。

これはバックグラウンドのスクリプトとは違います。Windows では Codex が前面であなたのカーソルを引き継ぎます。macOS ではバックグラウンド並列で動くので、他のアプリで作業を続けられます。

解決できるのは主に 2 種類です。

1. API のないツールを操作する場面。デザインソフト、システム設定、デスクトップアプリなど、GUI で完結するなら操作できます。
2. 「実際の画面を見る必要がある」場面。GUI のデバッグ、デザインモックの再現、デスクトップ操作のテストです。

1.2 macOS と Windows: バックグラウンド並列 vs 前面引き継ぎ

Computer Use で最も大きい分かれ目は、作業を並行できるかどうかです。

特性	macOS	Windows	説明
操作モード	バックグラウンド並列	前面で引き継ぎ	macOS は複数 agent の並列実行が可能、Windows はカーソルを引き継ぐ
作業への干渉	少ない	大きい	macOS では他アプリで作業を続けられる
複数 agent の並列	対応	非対応	macOS なら異なる app を同時に操作できます
向いている場面	並列マルチタスク	1 つの作業に集中	ワークフローで選びます
版	初期リリース	26.527 (2026-05-29)	Windows は 5 月 29 日に対応
利用可否	EEA/UK/スイスは除外	EEA/UK/スイスは除外	EU/UK へ順次展開中

macOS なら、Computer Use は「並列の助手」として使いやすいです。デザインソフトを 1 つ動かしながら、あなたはエディタでコードを書き続けられます。Windows では「集中時間」を決めて、Codex にカーソルを任せ、他の作業を止めて終わるのを待つのが現実的です。

2. 内蔵ブラウザ: フロントエンドを直す → ページを見る → その場でコメントする → 続ける

2.1 フロントエンド反復の流れ（4 ステップ）

内蔵ブラウザが解決する核心は、agent がフロントエンドを直しても、実際のレンダリング結果を見られないことです。スクリーンショット頼みでは、やり取りがすぐに重くなります。

流れはこうです。

1. フロントエンドを直す: スタイル、レイアウト、操作ロジックを変更する。
2. ブラウザを開く: Codex に localhost かローカル web アプリを開かせる。
3. ページでコメントする: ブラウザ上で直接クリック、注釈、コメントを行い、agent に具体的な指示を出す。
4. さらに直す: コメントをもとに調整し、もう一度ブラウザで結果を確認する。

この流れで、フロントエンドの反復は「コードを直す → スクリーンショットを送る → 返答をもらう → 直す」から、「コードを直す → ページを見る → コメントする → 直す」に変わります。agent は描画結果を直接見られるので、あなたが何度もスクリーンショットを撮る必要はありません。

2.2 今は主にフロントエンド / ゲームの反復向け

OpenAI の現在の位置づけは明確で、内蔵ブラウザは localhost の web アプリ、フロントエンド開発、ゲーム開発に向いています。

今後はより広いブラウザ制御へ広がっていく予定です。外部サイトを操作したい場合、たとえば本番環境のデバッグや第三者サイトのテストは、現時点ではまだ制限があり、今後の展開を待つ必要があります。

2.3 Developer mode: Codex に Chrome DevTools Protocol を与える

Developer mode は 2026-06-11 に 6.609 版で公開され、Codex に制御された Chrome DevTools Protocol アクセスを与えます。

できることは次のとおりです。

• パフォーマンス分析: JavaScript の profile や描画時間の計測
• ネットワークデバッグ: リクエスト、レスポンス、時間の確認
• Console 出力: 実行時エラーや console.log の読み取り
• ページ状態の確認: DOM と適用済みスタイルの inspection

さらに、CDP は反復速度も上げます。DOM snapshot により、重い再描画やスクリーンショット転送を減らせます。複雑なページでは、毎回フルリロードする必要がなく、snapshot を起点に続けられるので、反復が最大 2 倍速くなることがあります。

有効化は Settings > Browser > Enable full CDP access です。組織で Developer mode が無効化されている場合は、ローカルでは有効にできません。これは個人アカウント設定ではなく、組織ポリシーです。

3. Appshots: macOS で Command を 2 回押して、アプリを一発で Codex に送る

3.1 普通のスクリーンショットではなく、「スクリーンショット + 隠れテキスト」

Appshots は 2026-05-21 に公開され、スクリーンショットの細かい弱点を解決しました。スクロール領域の外にある内容が見えにくい問題です。

Command キーを 2 回押すと、Codex は最前面の app ウィンドウのスクリーンショットと利用可能なテキストを取得します。スクロール外の隠れテキストも含まれます。たとえば、Web ページのエラースタックがスクロール外にあって普通のスクリーンショットでは見えない場合でも、Appshots ならページ全体のテキストを抽出できます。

3.2 向いている場面

Appshots の典型的な使い方は次のとおりです。

• Web エラーのデバッグ: スクロール外のエラースタックを含むブラウザ全体を Codex に送る。
• デザイン再現: デザインソフトのウィンドウを agent に送り、レイアウトを分析してもらう。
• PDF の選択できないテキスト抽出: PDF ウィンドウの内容をそのまま読む。

agent は視覚情報とテキスト情報を同時に見られるので、単なるスクリーンショットより効率的です。

3.3 Appshots の操作フロー

1. 対象の app ウィンドウを開き、クリックしてフォーカスを当てます。
2. Command キーを 2 回押して、離します。
3. Codex の右下に 1.2 秒ほどアイコンが出れば、取得成功です。
4. 直近 60 秒のアクティブな会話スレッドに自動で添付されます。

注意: Appshots は macOS のみ対応で、システム言語は英語か簡体字中国語である必要があります。日本語と韓国語の環境には既知の制限があります。この 2 言語では、スクロール外のテキスト抽出が不完全になったり、選択できないテキストを正しく取得できなかったりします。日本語 / 韓国語環境を使う場合は、まず英語か簡体字中国語で動作確認するのがおすすめです。

4. 安全境界: いつ完全アクセスを与えないか

4.1 デフォルトは sandbox、権限は必要時だけ

Codex はデフォルトで sandbox モードで動き、agent は作業フォルダとブランチの中に制限されます。高い権限が必要な操作は承認が必要です。Computer Use と内蔵ブラウザはより高権限の機能なので、慎重に許可する必要があります。

機能	デフォルト権限	高権限の必要性	推奨
通常のコーディング	sandbox	なし	デフォルトで十分
Computer Use	sandbox	追加承認が必要	必要時のみ許可、Windows では app 単位で制限
内蔵ブラウザ	sandbox	Developer mode の承認が必要	フロントエンド反復時のみ有効化
Appshots	読み取り専用	なし	安全、読み取りのみ

Windows ユーザーはさらに細かく制御できます。Settings > Computer Use > Configure per-app access control で、Codex が特定のアプリだけを操作するように制限できます。

4.2 いつ完全アクセスを与えないか

Computer Use の権限は、かなり慎重に判断する必要があります。次のような場面では推奨しません。

• 信頼していない第三者コードベース。agent が機密ファイルに触れる可能性があります。
• 本番環境のデータベース。agent が誤操作する可能性があります。
• 高権限のシステム設定。Windows では app 単位の制御が重要です。

基本方針は単純です。

• まず sandbox に置き、必要だと明確に分かるときだけ権限を与える。
• Windows では per-app access control を使って範囲を絞る。

5. 取捨選択: いつ Computer Use を使い、いつ通常のコーディングのほうが安いか

5.1 シナリオ表

Computer Use は万能ではありません。タスクの種類で判断してください。

場面	推奨	理由
フロントエンド / UI スタイル修正	内蔵ブラウザ	実際の描画結果が見え、反復ループが完結する
API のないデスクトップツール操作	Computer Use	GUI しか道がない
単純なコード生成	通常のコーディング	Computer Use はコストが高く、割に合わない
フロントエンドの性能デバッグ	Developer mode	CDP の性能分析 + ネットワークデバッグ
app をすぐ Codex に送る	Appshots (macOS)	一発スクリーンショット + 隠れテキスト

核心は単純です。通常のコーディングで終わるなら、Computer Use は使わないでください。価値が出るのは、API のないツールを操作したり、「実際の画面を見る」必要がある場面です。

5.2 コスト面: Computer Use / ブラウザは少し高い

Computer Use と内蔵ブラウザの呼び出しコストは、通常のコーディングより高めです。

• Computer Use: スクリーンショットと操作でトークン消費が増える。
• ブラウザ反復: 1 ラウンドごとに呼び出しが発生する。

簡単な作業は通常のコーディングで、複雑な GUI 作業だけ Computer Use を使うのがよいです。

6. FAQ: よくある疑問

Q1: Computer Use とは何ですか。どこまでできますか？

Computer Use では、Codex が自分のカーソルで見て、クリックして、入力して、PC 上のすべてのアプリを操作できます。公開 API のないデスクトップツールも対象です。完全自動で奪うのではなく、あなたが目標を伝え、Windows では前面、macOS ではバックグラウンドで GUI を操作します。

Q2: macOS と Windows の違いは何ですか？

macOS はバックグラウンド並列に対応しているので、複数の agent が別アプリを同時に操作しても、他の作業の邪魔をしません。Windows は現時点で前面操作のみで、agent がカーソルを引き継ぐため、他の作業は止める必要があります。どちらもアプリ自体は操作できます。選ぶ基準はワークフローです。

Q3: 内蔵ブラウザでフロントエンドをどう反復しますか？

フロントエンドを直し、内蔵ブラウザで localhost のページを開き、ページ上でコメントし、agent に続きの変更をさせ、またブラウザで結果を確認します。これで edit-view-comment-edit のループができます。今は主にフロントエンドとゲームの反復に向いています。

Q4: 安全ですか。完全アクセスは必要ですか？

基本は sandbox で、agent は作業フォルダとブランチに制限されます。高権限は承認が必要です。Computer Use とブラウザは高権限の機能なので、必要時のみ許可してください。Windows では app 単位で制限もできますし、信頼できない場面で完全アクセスを与えるべきではありません。

Q5: いつ Computer Use を使う価値がありますか？

API のないデスクトップツール、たとえばデザインソフトやシステム設定を操作するとき、また agent に実際の画面を見せたいとき、たとえば GUI のデバッグやモック再現をしたいときに向いています。単純なコード生成は通常のコーディングのほうが安いです。

Q6: Developer mode のブラウザは何ができますか？

Codex に制御された Chrome DevTools Protocol アクセスを与え、性能分析、ネットワークデバッグ、Console 出力、DOM / スタイル確認を行えます。2026-06-11 に追加されました。場面によっては DOM snapshot により反復速度が最大 2 倍ほど改善します。

7. 次の一歩と参考リンク

関連記事

• 上流: Codex の安全 sandbox と権限境界: いつ完全アクセスを与えないか（公開待ち）
• 下流: Codex Cloud agent のワークフロー: リモート機器の操作と監視（公開待ち）
• 下流: Codex のコスト実践: Computer Use、ブラウザ、長時間タスクの予算管理（公開待ち）

公式リソース

• Codex 公式ドキュメント
• Codex Changelog
• Codex for (almost) everything（2026-04-16 の大型アップデート）

結論

Computer Use と内蔵ブラウザが解決する核心は、AI が実際の画面を見ないと仕事を終えられない場面です。フロントエンド修正はレンダリング結果を見る必要があり、API のないツールは GUI を見て操作する必要があります。

プラットフォームの違いは作業の仕方を決めます。macOS では agent にアプリをバックグラウンドで操作させながら、あなたはコードを書き続けられます。Windows では集中時間を取り、agent にカーソルを任せる必要があります。

安全境界は抑制が必要です。基本は sandbox に置き、必要だと明確に分かるときだけ権限を与え、Windows では per-app access control で範囲を絞ってください。

コストの取捨選択も明確です。簡単な作業は通常のコーディングのほうが安く、複雑な GUI 作業こそ Computer Use の出番です。

次のおすすめ:

• macOS ユーザーなら、デザインソフトをバックグラウンドで動かしながら、エディタで作業してみてください。
• フロントエンドを反復したいなら、内蔵ブラウザで edit-view-comment-edit の流れを作ってください。
• 安全境界にまだ迷いがあるなら、完全アクセスを与える前に Codex の安全 sandbox と権限境界を読んでください。