Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.
Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting.
Every day, use Chrome to check my DMs, read relevant news, and look for feedback or mentions I should know about. Add anything durable to my vault. Do not post or send messages.
Use @Browser to open vite app on http://localhost:3000/, reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths.
Codexはどのようにコンピュータを操作しますか？三つの入口と権限の境界
編者注：この記事は、Codexが外部環境を操作する三つの入口：コンピュータ利用、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がコンピュータを使う方法は三つ：Computer Use、Chrome拡張、アプリ内ブラウザ。
それらには一定の重複があり、混乱を招きやすい部分もあります。
この記事を読めば、これら三つの方法のインストールとトリガー方法、それぞれの適したシナリオ、AppshotsとDeveloper modeの連携方法、そしてAGENTS.mdに何を書くべきかがわかり、Codexが自動的に適切な操作インターフェースを選べるようになります。
簡単なまとめは：
とはいえ、可能な限りプラグインやMCPを優先すべきです。例えばSlackプラグインは、Slack内のあちこちをクリックして探すよりも、特定のスレッドをより正確に検索できます。GitHubの操作も、Codexにウェブを操作させるよりも、チェックしやすくなります。視覚制御は、構造化ツールの能力の境界に達したときに最も効果的です。
すべては @Computer になり得る
Computer Useは、この三つの操作インターフェースの中で最も範囲が広いものです。macOSやWindows上で、ウィンドウ、メニュー、キーボード入力、許可されたアプリのクリップボードを操作できます。
通常、最も遅いとも言えます。構造化プラグインはAPIを直接呼び出せますが、Computer Useは画面を観察し、どこをクリックすべきか判断し、アプリの応答を待ち、次の状態を確認します。この視覚ループは時間を消費しますが、APIが使えないアプリも操作可能です。
macOSでは、遅いからといって必ずしも邪魔になるわけではありません。Computer Useはバックグラウンドで許可されたアプリを操作でき、あなたは他の作業を続けられます。多くの場合、Codexを使っているときにアプリを開くと、Codexが静かにワークフローを完了していることに気づきます。
インストールできるアプリは、Spotify、Xcode、システム設定、iOSエミュレータ、さらにはiPhoneミラーリングでiPhoneを操作することも含まれます。複数アプリ間の切り替えも可能です。
タスクが以下に依存するときに使えます：
ネイティブデスクトップアプリ（例：Spotifyや金融アプリ）；
iOSエミュレータ、iPhoneミラーリング、またはグラフィカル操作が必要なフロー；
システムやアプリの設定；
プラグインやAPIのないデータソース；
複数アプリ間の切り替えを伴うワークフロー；
構造化された統合の最後の操作。
インストール方法：Codexの設定 > Computer Useを開き、「インストール」をクリック。
トリガー方法：@Computerを言及、または明示的にCodexにComputer Useの使用を要求。
例をいくつか：
私のお気に入りの例は、荷物が盗まれたときです。Amazonは約25分待つ必要があると伝え、カスタマーサポートに繋がるのを待ちます。私はCodexのスレッドをComputer Useに渡し、5分ごとにチャットウィンドウを確認させ、サポートが現れたら1分ごとに切り替え、返金を得る手助けをさせました。お風呂から上がったら、返金は完了していました。
また、Computer Useは構造化ワークフローの「ラストマイル」としても使います。ある動画公開時、CodexはSlackからフィードバックを読み取り、コードを修正し、新しい動画をレンダリングできますが、そのときSlackのインテグレーションがファイルアップロードできませんでした。そこでComputer Useは「ファイル追加」をクリックし、そのステップを補完しました。
最も信頼の境界が広いのはこれです。一度に明確なアプリやフローだけを許可します。敏感なアプリがタスクに関係ない場合は閉じたままにし、権限のポップアップを注意深く確認します。金融、アカウント、支払い、証明書、プライバシー、システム安全性の変更に関わる場合は、監督者がいるのが望ましいです。
用 @Chrome で複数タブとログイン状態を扱う
Codex Chrome拡張は、あなたがすでにログインしているChromeの状態にアクセスできます。タスクがアカウント、クッキー、ブラウザ設定ファイル、または認証済みのタブに依存するときは、これを使います。
この操作インターフェースは、以下のツールでの作業に適しています：
GmailやLinkedIn；
Salesforceやカスタマーサポートバックエンド；
内部ダッシュボード；
複数サイト間のログイン済み調査；
アカウントやブラウザ拡張に依存するフォーム。
インストール方法：CodexのPluginsを開き、Chromeを追加し、設定手順に従います。CodexはChrome拡張をインストールし、権限を承認します。拡張が「Connected」と表示されたら、新しいスレッドを開始します。
トリガー方法：@Chromeを言及、または明示的にCodexに既ログインのChromeブラウザの使用を指示。
例：
Chromeタスクはタブグループ内で動作し、特定のCodexスレッドに関連するタブをまとめるのに役立ちます。アプリ内ブラウザと違い、このインターフェースはあなたのブラウザアイデンティティを持ち込みます。これにより、より強力で敏感な操作が可能です。
もう一つの大きな利点は、多タブ制御です。Chromeは複数のタブを同じタスクに関連付け、あるページでコンテキストを読み取り、別のページで情報を照合し、三つ目のページでワークフローを続行できます。Computer Useも視覚的にブラウザを操作できますが、Chromeはタスクをブラウザのワークフローとして理解し、連続した画面座標操作ではなく、構造化されたページの情報を活用します。
最近の例では、既に開いていたStrudel ComposerのタブをCodexに渡し、音楽をより面白くする作業をさせました。Chromeは選択されたタブと、そのページから抽出されたWebMCPツールを提供します。Codexは楽曲構造を分析し、和声や全体の四分の三の形式を書き換え、速度を調整し、曲を保存し、再生を続けさせました。画面上の各コントロールを視覚的に探す必要はなく、Chromeはタブのコンテキストとページの構造化能力を組み合わせているからです。
また、長期のTwitterスレッドも操作しました。大まかな指示は：
面白いのは、CodexがTwitterを開くことではなく、このスレッドが長期的に同じログイン済みの作業環境に戻り、見つけた内容をローカルファイルに結びつけ、私の監査用結果を残せる点です。
この信頼の境界は重要です。ウェブサイトは、Codexのクリックやフォーム送信、メッセージ送信をあなた本人の行動とみなすことがあります。ページの内容も信用できない入力です。結果に重みのあるステップは明確に区別し、調査・ナビゲーション・草稿作成は自動化できますが、送信・公開・購入・提出前にはあなたの監査が必要です。
もしタスク全体をブラウザ内で完結させるなら、Chromeを優先し、Computer Useは避けるべきです。Chromeはこの種のタスクに必要なブラウザのネイティブコンテキストを持ち、アクセス範囲もデスクトップ全体には広がりません。
アプリ内 @Browser で開発中のウェブサイトを扱う
アプリ内ブラウザは、Codexスレッド内に存在するブラウザです。あなたとCodexは同じレンダリングページを共有しているため、Webアプリの構築やデバッグに特に適しています。
私がよく始めるのは：
ローカル開発サーバ；
ファイルベースのプレビューページ；
ログイン不要の公開ページ；
ビジュアルバグの再現；
レスポンシブレイアウトの確認；
ページ要素へのデザインフィードバック。
最も重要な制約は隔離です。アプリ内ブラウザは、あなたの通常のブラウザ設定、クッキー、拡張、ログインセッション、既存のタブを使用しません。アカウントが必要な場合は制限となりますが、必要ない場合は有効な境界となります。
設定方法：CodexのPluginsを開き、Browserプラグインを追加して有効化。
トリガー方法：プロンプト内で @Browser を言及、または明示的にCodexにアプリ内ブラウザの使用を指示：
これにより、密なフィードバックループが形成されます。Codexはコード編集、ページ操作、レンダリング状態の確認、スクリーンショットを行い、修正後に同じフローを再検証します。
私が最も気に入っているのは、注釈です。ローカルアプリをレビューするとき、要素を直接クリックしたり、範囲を選択してコメントを残したりできます。スタイルコントロールも、文字やフォント、間隔、色のプレビューとフィードバックをより正確に行えます。これを音声入力やプロセス誘導と組み合わせると、ページをレビューし、コメントを残し、Codexがフィードバックを処理している間に次の意見を追加できます。このページ自体が仕様書のようになります。
これは特にデザイン作業に役立ちます。私はよく、アイデアや調査パッケージ、プロジェクトの状態をindex.htmlという単一ファイルに整理させ、それをアプリ内ブラウザで開きます。別のプロンプトで設計全体を説明するよりも、実ページ上で「この階層構造は逆だ」「ここはカードのように見せない」「これらのコントロールにはもっとスペースを」「全体のフォント比率をこれに」などと直接注釈を付けられます。Codexは関連スクリーンショットと要素のコンテキストを含むコメントを受け取り、ファイルを修正し、再び同じページを開いて次のサイクルに入ります。
このループは、まるでデザイナーと同じキャンバス上で作業しているような感覚です。スクリーンショットや文字のやりとりを何度も行うよりも、より密な連携が可能です。
アプリ内ブラウザは、ハイブリッドワークフローの出発点としても適しています。別のスレッドでは、私はアプリ内ブラウザでXの投稿を開き、関連議論を調査させました。ページの可視性は、どの投稿かを確認させるのに役立ち、その後CodexはTwitter CLIに切り替え、38件の返信を取得しました。これには、ブラウザビューに隠されたネスト返信も含まれます。これは、「最も狭い操作インターフェースを使う」原則の実践例です：ブラウザで画面のコンテキストを確認し、構造化ツールでより深く検索します。
ここにもトレードオフがあります。アプリ内ブラウザの隔離性は、良い開発インターフェースですが、Googleログインやpasskey、ブラウザ拡張に依存するサイトには適しません。アイデンティティが重要な場合はChromeに切り替えましょう。
Appshots
Appshotは、Codexがコンピュータを制御する第四の方法ではありません。これは、Codexにあなたの目の前のコンテキストを指し示す方法です。
Macでは、CMDキーを二回押すと、最近のウィンドウをキャプチャできます。Codexは画像と利用可能なテキストをスレッドに付加します。エラー、メール、デザイン、設定パネル、または見知らぬフォームに対してAppshotを行い、次のように直接伝えられます：
これが私が最も覚えやすい心のモデルです：Appshotsはあなたがコンピュータ上の何かを指し示す方法であり、Browser、Chrome、Computer UseはCodexが行動を起こす方法です。
現在、macOS上のCodexアプリを通じてAppshotsを作成します。これは最前面のウィンドウをキャプチャし、デスクトップ全体ではありません。これにより、焦点を絞ったコンテキストを提供しつつ、そのアプリの制御権を与えない便利な方法となっています。
これらの進展を追うには
これらの操作インターフェースは非常に速く変化しています。実用的な詳細を知りたい場合は、以下をフォローしてください：
Ari Weinstein（@AriX）をフォローし、Computer UseとAppshotsの情報を得る；
James Sun（@JamesZmSun）をフォローし、Browser関連の内容を把握；
Andrew Ambrosino（@ajambrosino）をフォローし、Codexのリリースやデスクトップ製品の大きなストーリーを追う；
OpenAI Developers（@OpenAIDevs）をフォローし、CodexやOpenAI Platformの最新ニュースを得る。
[原文リンク]
律動BlockBeatsの求人情報はこちらをクリック
律動BlockBeats公式コミュニティに参加しましょう：
Telegram登録グループ：https://t.me/theblockbeats
Telegram交流グループ：https://t.me/BlockBeats_App
Twitter公式アカウント：https://twitter.com/BlockBeatsAsia