編集者注：この記事は、Codexが外部環境とやり取りする3つの入口——Computer Use、Chrome拡張機能、およびアプリ内ブラウザー——を整理しています。これらはすべて「Codexにコンピューターを使用させる」という問題を解決しているように見えますが、それぞれ異なるタスクシナリオ、権限の境界、信頼レベルに対応しています。

その中で、Computer Use は、許可された macOS / Windows 上のネイティブアプリ、システム設定、iOSシミュレーターを直接操作でき、複数のアプリにまたがるワークフローを実行できます。これはAPI、プラグイン、または構造化ツールのサポートがないGUIプロセスに適していますが、速度が遅く、権限範囲も最も広くなります。Chrome拡張機能は、Gmail、LinkedIn、Salesforce、内部バックエンド、または複数のウェブサイトにまたがるログイン済みのリサーチなど、ログイン状態、クッキー、複数タブ、ブラウザの認証に依存するタスクに適しています。アプリ内ブラウザは開発やデバッグのシナリオに焦点を当てており、ローカルサービス、ビジュアルバグ、レスポンシブレイアウト、デザインコメントに特に適しています。これはユーザーの通常のブラウザのログイン状態を継承せず、機能は限定的ですが、隔離性はより強くなります。

コアな判断は、Codex が「コンピュータを使用する」方法を一つだけ持っているわけではないことであり、真に重要なのはタスクに応じて最も狭く、最も安全で、最も構造化された操作インターフェースを選択することである。プラグインまたは MCP で対応可能な場合は、まずビジュアル制御を用いるべきではない。タスクがウェブ開発のみを含む場合は、アプリ内ブラウザを優先して使用する。ユーザーのブラウザ認証やログイン状態が必要な場合にのみ Chrome に切り替える。構造化ツールではカバーできない場合かつタスクがデスクトップグラフィカルインターフェースに依存する場合にのみ、Computer Use が最終手段となる。

Appshotsは、コンピューターを制御する第四の方法ではなく、現在の画面のコンテキストをCodexに「示す」ためのツールである。これはコンテキスト入力の問題を解決し、Browser、Chrome、Computer Useは行動の問題を解決する。これらを総合的に見ると、この階層構造はAIエージェントの製品化における鍵を明らかにする：モデルに無制限の権限を与えるのではなく、具体的なタスクにおいて権限を段階的に狭め、境界を明確にし、ユーザーが重要な行動の承認権を維持することである。

以下が原文です：

Codexは、コンピュータ使用、Chrome拡張機能、およびアプリ内ブラウザの3つの方法で使用できます。

それらにはある程度の重複があり、混乱しやすいほど重なっています。

この記事を読むことで、この3つの方法のインストールとトリガーの方法、それぞれの使用シナリオ、AppshotsとDeveloper modeをどのように連携させるか、そしてCodexが適切な操作インターフェースを自ら選択できるようにAGENTS.mdに何を記述すべきかがわかります。

シンプル版は：

ただし、可能な限りプラグインまたはMCPを優先してください。たとえば、SlackプラグインはSlack内で至る所をクリックするよりも、スレッドをより正確に検索できます。GitHubプラグインによって生成される操作は、Codexがウェブページを駆動するよりもチェックしやすいです。ビジュアルコントロールは、構造化されたツールの機能が限界に達した場所で最も適しています。

すべては@Computerで可能です

Computer Use は、この3つの操作インターフェースの中で最も広範囲にわたるものです。これにより、Codex は macOS および Windows 上でウィンドウ、メニュー、キーボード入力、およびあなたが許可したアプリケーション内のクリップボードを表示および操作できます。

それは通常最も遅いです。構造化プラグインはAPIを直接呼び出せますが、Computer Useはインターフェースを観察し、どこをクリックすべきか判断し、アプリの応答を待ってから次のステータスを確認する必要があります。このビジュアルループには時間がかかりますが、その代わりにCodexは完全にAPIが利用できないアプリケーションも操作できるという利点があります。

macOSでは、遅いことが必ずしもあなたを妨げることを意味しません。Computer Useは、あなたが許可したアプリをバックグラウンドで操作しながら、あなたは他の部分をそのまま使い続けることができます。多くの場合、私はCodexを使ってあるアプリを開こうとしたとき、Codexがすでにバックグラウンドで一連のワークフローを静かに完了していたことに気づきます。

インストールされ、許可されたアプリに応じて、これらの操作対象にはSpotify、Xcode、System Settings、iOSシミュレーター、さらにはiPhone MirroringでiPhoneを制御することも含まれます。また、複数のアプリ間で切り替えたり、異なるアプリにまたがるワークフローを処理することも可能です。

タスクが以下の内容に依存する場合、これを使用できます：

Spotifyや金融系アプリなどのネイティブデスクトップアプリケーション；

iOSシミュレーター、iPhoneミラーリング、またはグラフィカルインターフェースでのみ操作可能なプロセス；

システムまたはアプリ設定；

プラグインやAPIなしのデータソース；

複数のアプリ間で切り替える必要があるワークフロー；

構造化インテグレーションで欠けている最後のステップ。

インストール方法：CodexのSettings > Computer Useを開き、[Install]をクリックしてください。

トリガー方法：@Computer を言及するか、明確にCodexにComputer Useを実行するよう指示する。モデルの能力が向上するにつれ、今後は必要に応じて自ら呼び出すようになる。

いくつか例を試してみてください：

私が最も気に入っている例の一つは、荷物が盗まれたことがきっかけでした。Amazonは、カスタマーサポートに繋がるまで約25分かかると言いました。私はCodexのスレッドをComputer Useに渡し、5分ごとにチャットウィンドウをチェックさせ、カスタマーサポートが現れたら1分ごとにチェックし、返金を取得するよう尽力させました。私が風呂から上がったときには、返金が完了していました。

私もComputer Useを、構造化ワークフローにおける「ラストマイル」として使用しています。ある動画の公開時に、CodexはSlackからフィードバックを読み取り、コードを修正し、新しい動画をレンダリングできましたが、その時のSlack統合ではファイルのアップロードができませんでした。そこでComputer Useが「Add file」をクリックし、欠けていたステップを補いました。

それは三者の中で信頼境界が最も広いものです。一度に一つの明確なアプリケーションまたはプロセスのみに使用してください。敏感なアプリケーションがタスクに含まれていない場合は、常にオフにしてください。権限ポップアップを慎重に確認してください。金融、アカウント、支払い、認証情報、プライバシー、システムセキュリティの変更に関わる場合は、必ず人がそばで監督することをお勧めします。

@Chrome を使用して複数のタブとログイン状態を処理してください

Codex Chrome拡張機能により、CodexはすでにログインしているChromeの状態にアクセスできるようになります。タスクがアカウント、クッキー、ブラウザプロファイル、またはすでに開いて認証済みのタブに依存する場合、これを使用してください。

このような操作インターフェースは、以下のツールでの作業に適しています：

Gmail または LinkedIn；

Salesforce またはカスタマーサポートバックエンド；

内部ダッシュボード；

複数のウェブサイトにまたがるログイン済み調査；

あなたのアカウントまたはブラウザ拡張機能のフォームに依存します。

インストール方法：CodexのPluginsを開き、Chromeを追加して設定フローに従って操作してください。CodexはCodex Chrome拡張機能のインストールとChromeの権限承認をガイドします。拡張機能が「Connected」と表示されたら、新しいスレッドを開始してください。

トリガー方法：@Chrome を言及するか、Codex にログイン済みの Chrome ブラウザを使用するよう明示的に要求する：

Chromeのタスクはタブグループ内で実行され、これによりCodexスレッドに関連するタブをまとめて管理できます。アプリ内ブラウザとは異なり、この操作インターフェースはあなたのブラウザの身份を引き継ぎます。これにより、より強力で、より敏感な機能を実現します。

もう一つの主要な利点は、複数のタブ制御です。Chromeでは、複数のタブを同じタスクに関連付け、1つのタブでコンテキストを読み取り、別のタブで情報を参照し、3つ目のタブでワークフローを継続できます。Computer Useも視覚的にブラウザを操作できますが、Chromeはタスクを一連の画面座標操作ではなく、ブラウザワークフローとして理解します。

最近、私は開いていたStrudel ComposerのタブをCodexに渡し、音楽をより面白くしてもらいました。Chromeは選択されたタブと、そのページが提供するWebMCPツールをCodexに渡しました。Codexは楽曲の構造を確認し、和声と4分間の全体的な形式を再構成し、テンポを調整し、曲を保存して再生を継続しました。Codexは、Chromeがタブのコンテキストとページが提供する構造化された機能を組み合わせることができるため、インターフェース上の各コントロールを視覚的に探す必要がありませんでした。

私はそれを使って長期的なTwitterスレッドも実行しています。大まかな指示は：

面白い点は、CodexがTwitterを開けることではなく、このスレッドが同じログイン済みの作業環境に長期間戻ることができ、発見した内容をローカルファイルにリンクさせ、私が確認できる結果を残せる点である。

ここでの信頼境界は重要です。ウェブサイトは、Codexのクリック、フォーム送信、メッセージ送信をあなた自身の行動と見なす可能性があります。ウェブページのコンテンツ自体も信頼できない入力です。重大な結果を伴うステップは明確に区別してください：調査、ナビゲーション、ドラフト作成は自動で実行できますが、送信、公開、購入、または提出の前には、必ずあなたが確認してください。

タスク全体をブラウザ内で完了する場合は、Computer UseではなくChromeを優先してください。Chromeは、このようなタスクに必要なブラウザネイティブなコンテキストを提供し、デスクトップ全体へのアクセス範囲を広げません。

開発中のウェブサイトをアプリ内 @Browser で処理してください

アプリ内ブラウザは、Codexスレッド内に存在するブラウザです。あなたとCodexは同じレンダリングページを共有しているため、Webアプリの構築とデバッグに特に適しています。

私は通常、ここから処理を始めます。

ローカル開発サーバー；

ファイルのプレビューページ；

ログイン不要の公開ページ；

ビジュアルバグを再現する；

レスポンシブレイアウトを確認する；

ページ要素に関するデザインフィードバックを残してください。

最も重要な制約は隔離です。アプリ内ブラウザは、通常のブラウザのプロファイル、クッキー、拡張機能、ログインセッション、または既存のタブを使用しません。タスクにアカウント認証が必要な場合、これは制限になりますが、アカウントが不要なタスクでは、むしろ有用な境界となります。

設定方法：Codexのプラグインを開き、Browserプラグインを追加して有効化してください。

トリガー方式：プロンプトに@Browserと記載するか、Codexにアプリ内ブラウザの使用を明示的に要求する場合：

これにより、Codexがコードを編集し、ページを操作し、レンダリング状態を確認し、スクリーンショットを撮影した後、修正後に同じプロセスを再検証する、密なフィードバックループが形成されます。

私が最も気に入っているのはコメント機能です。ローカルアプリをレビューする際、特定の要素をクリックしたり、領域を選択してコメントを残すことができます。スタイルコントロールにより、テキスト、フォント、間隔、色をより正確にプレビューし、フィードバックを提供できます。私は通常、音声入力とプロセスガイドと組み合わせて使用します。ページをレビューし、コメントを残した後、Codexが現在のフィードバックを処理している間に、さらに多くの意見を追加し続けます。このページ自体が仕様書になります。

これはデザイン作業に特に役立ちます。私はよくCodexに、アイデアや研究パック、プロジェクトの状態を1つのindex.htmlファイルに整理して、アプリ内ブラウザで開くように依頼します。別のプロンプトで全体のデザインを説明する代わりに、実際のページ上で「この階層関係が逆です」「ここはカードのように見せすぎないでください」「これらのコントロールにはさらにスペースが必要です」、または「サイト全体でこのフォントサイズの比率を使用してください」と直接コメントできます。Codexは関連するスクリーンショットと要素のコンテキストを含むコメントを受け取り、ファイルを修正して同じページを再開き、次のラウンドに進みます。

このサイクルは、スクリーンショットや文字説明をやり取りするよりも、デザイナーと一つのキャンバスで一緒に作業していることに近いです。

アプリ内ブラウザは、ハイブリッドワークフローの開始点としても適しています。別のスレッドで、アプリ内ブラウザを使ってXの投稿を開き、Codexにその議論を調査させました。表示されたページは、私がどの投稿を指しているかをCodexが確認するのに役立ちました。その後、CodexはTwitter CLIに切り替えて、ブラウザビューでは隠されていたネストされた返信を含む38件の返信を取得しました。これは「最も狭い操作インターフェースを使用する」という原則の実践です：ブラウザで画面上のコンテキストを確認し、その後、構造化されたツールでより深く検索します。

ここにもトレードオフがあります。アプリ内ブラウザの隔離性は開発環境として優れていますが、Googleログインやパスキー、ブラウザ拡張に依存するウェブサイトには適していません。認証が重要な場合は、Chromeに切り替えてください。

Appshots

Appshotは、Codexがコンピュータを制御する第四の方法ではありません。これは、Codexをあなたの眼前的なコンテキストに指向させる方法です。

Macでは、CMDキーを2回押すと、直前のウィンドウをスクリーンショットできます。Codexは、画像と利用可能なすべてのテキストをスレッドに添付します。エラー、メール、デザイン、設定パネル、または不慣れなフォームに対してAppshotを撮影し、次のように直接言います：

私が最も覚えやすいメンタルモデルだと考えるのは、Appshots はコンピューター上の何かを指し示すための方法であり、Browser、Chrome、Computer Use は Codex が行動を取る方法であるということです。

Appshots は現在、macOS 上の Codex アプリを通じて作成されます。これはデスクトップ全体ではなく、最前面のウィンドウをキャプチャします。これにより、アプリへの制御権を付与することなく、焦点を絞ったコンテキストを提供できる便利な方法となります。

これらの進展をどのようにフォローアップしますか？

これらの操作インターフェースは急速に変化しています。巨大なリリースまとめを待つのではなく、実用的な詳細を知りたい場合は：

Ari Weinstein（@AriX）をフォローして、Computer Use と Appshots をチェックしてください；

ブラウザ関連の情報を得るには、James Sun（@JamesZmSun）をフォローしてください。

Andrew Ambrosino（@ajambrosino）をフォローして、Codexアプリのリリースとより大きなデスクトップ製品のナラティブをご覧ください；

より広範なCodexおよびOpenAI Platformのニュースを知るには、OpenAI Developers（@OpenAIDevs）をフォローしてください。