Partnered With:

Codexをパソコンで使う方法：3つのアクセス方法と権限の境界線

この記事を読むのに必要な時間は 28 分

重要なのはAIにより多くの権限を与えることではなく、適切な行動範囲を選択させることだ。

原文标题：Three Ways Codex Can Use a Computer
原文作者：jason
编译：Peggy，BlockBeats

編集者注：本稿では、Codexが外部環境を操作する3つの入り口、すなわちComputer Use、Chrome拡張機能、アプリ内ブラウザについて整理する。これらはいずれも「Codexにコンピュータを使わせる」という課題を解決するように見えるが、それぞれ異なるタスクシナリオ、権限境界、信頼レベルに対応している。

その中でもComputer Useは最も広範なカバレッジを持ち、macOS/Windows上の認可されたネイティブアプリ、システム設定、iOSシミュレーターを直接操作でき、複数のアプリをまたいでワークフローを完了することも可能だ。APIやプラグイン、構造化ツールがサポートされていないGUIフローに適しているが、代償として速度が遅く、権限境界も最も広い。Chrome拡張機能は、ログイン状態、Cookie、複数タブ、ブラウザのアイデンティティに依存するタスク、例えばGmail、LinkedIn、Salesforce、内部バックエンド、または複数のサイトにログインした状態での調査に適している。アプリ内ブラウザは、開発やデバッグのシナリオに重点を置いており、特にローカルサービス、視覚的なバグ、レスポンシブレイアウト、デザインノートに適している。ユーザーの通常のブラウザのログイン状態を継承せず、能力はより限定的だが、分離性もより強い。

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

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

以下が原文である：

Codexがコンピュータを使う方法は3つある：Computer Use、Chrome拡張機能、そしてアプリ内ブラウザである。

これらの間には一定の重複があり、ちょうど混乱を招きやすい程度に重なっています。

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

簡潔版は以下の通りです：

とはいえ、可能な限りプラグインやMCPを優先的に使用してください。例えば、SlackプラグインはSlack内でクリックを繰り返すよりも、スレッドをより正確に検索できます。GitHubプラグインが生成する操作は、CodexがWebページを操作するよりもチェックが容易です。ビジュアルコントロールは、構造化ツールの能力が限界に達した場面で最も適しています。

すべては @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 Mirroring、その他グラフィカルインターフェースでのみ操作可能なフロー；

システムまたはアプリケーションの設定；

プラグインやAPIがないデータソース；

複数のアプリケーションを切り替える必要があるワークフロー；

特定の構造化インテグレーションにおいて欠落している最後のステップ。

インストール方法：CodexのSettings > Computer Useを開き、Installをクリックします。

トリガー方法：@Computerに言及するか、CodexにComputer Useの使用を明示的に要求します。モデルの能力が向上するにつれて、将来的には必要に応じて自動的に呼び出されるようになります。

まずはいくつかの例を試してみてください：

私が最も気に入っている例は、荷物が盗まれたことに起因します。Amazonからは、カスタマーサービスに繋がるまで約25分待つように言われました。そこで、CodexのスレッドをComputer Useに任せ、5分ごとにチャットウィンドウをチェックし、カスタマーサービスが現れたら1分ごとにチェックするように変更し、返金を受けられるよう最善を尽くさせました。私がシャワーから戻ると、返金はすでに完了していました。

@Computerを使ってSpotifyを開き、Discover Weeklyプレイリストを見つけて再生を開始してください。アカウントやサブスクリプションの設定は変更しないでください。@Computerを使ってiPhoneミラーリングを開き、iOSアプリのオンボーディングバグを再現し、エラー状態のスクリーンショットを撮ってください。最小限の関連コードパスを修正し、同じフローをもう一度実行してください。

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

また、これら3つの中で最も信頼境界が広いものです。一度に明確なアプリケーションまたはプロセスを1つだけ与えてください。タスクの一部ではない機密性の高いアプリケーションはオフにしておき、権限ポップアップを注意深く確認し、金融、アカウント、支払い、認証情報、プライバシー、システムセキュリティの変更に関わる場合は、人間が立ち会って監督するのが最善です。

@Chrome で複数タブとログイン状態を扱う

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

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

Gmail や LinkedIn；

Salesforce やカスタマーサポートダッシュボード；

社内ダッシュボード；

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

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

インストール方法：Codex の Plugins を開き、Chrome を追加し、セットアップ手順に従ってください。Codex が Codex Chrome 拡張機能のインストールと Chrome の権限承認を案内します。拡張機能が Connected と表示されたら、新しいスレッドを開始してください。

トリガー方法：@Chrome に言及するか、Codex にあなたがログインしている Chrome ブラウザを使用するよう明示的に依頼します：

@Chrome を使って開いている顧客アカウントを確認し、別のタブにあるサポートチケットと比較し、不足しているフィールドを下書きしてください。送信する前に停止してください。

Chrome のタスクはタブグループ内で実行され、特定の Codex スレッドに関連するタブをまとめるのに役立ちます。アプリ内ブラウザとは異なり、この操作インターフェースはあなたのブラウザのアイデンティティを保持します。これにより、より強力で、よりセンシティブなものになります。

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

最近のスレッドでは、既に開いている Strudel Composer のタブを Codex に渡し、音楽をより面白くするよう依頼しました。Chrome は選択されたタブと、そのページが公開する WebMCP ツールを提供しました。Codex は楽曲構造を確認し、ハーモニーと4分間の全体形式を書き換え、テンポを変更し、トラックを保存し、再生を続けました。Chrome がタブのコンテキストとページが提供する構造化された能力を組み合わせられるため、各コントロールを視覚的に探す必要はありませんでした。

また、これを使って長期間のTwitterスレッドを運用しています。大まかな指示は次の通りです：

毎日、Chromeを使って自分のDMを確認し、関連ニュースをチェックし、把握すべきフィードバックやメンションを探してください。永続的なものは自分のVaultに追加してください。投稿やメッセージの送信は行わないでください。

興味深いのは、CodexがTwitterを開けることではなく、このスレッドが長期間にわたって同じログイン済みの作業環境に戻り、発見した内容をローカルファイルに接続し、私が確認できる結果を残せる点です。

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

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

アプリ内 @Browser を使って開発中のウェブサイトを処理する

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

通常、以下のような作業から始めます：

ローカル開発サーバー；

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

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

視覚的なバグの再現；

レスポンシブレイアウトの確認；

ページ要素に対するデザインフィードバックの残置。

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

設定方法：CodexのPluginsを開き、Browserプラグインを追加して有効にします。

トリガー方法：プロンプト内で @Browser に言及するか、Codex にアプリ内ブラウザの使用を明示的に指示します：

@Browser を使って http://localhost:3000/ の Vite アプリを開き、モバイルのオーバーフローバグを再現して修正し、デスクトップとモバイルの両方の幅で同じルートを再度確認してください。

これにより、密接なフィードバックループが形成されます：Codex はコードの編集、ページの操作、レンダリング状態の確認、スクリーンショットの取得、そして修正後に同じフローを再検証できます。

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

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

このプロジェクト概要用に単一ファイルの index.html を作成し、アプリ内 @Browser で開いてください。

このループは、スクリーンショットとテキスト説明をやり取りするよりも、デザイナーと同じキャンバスで作業している感覚に近いです。

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

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