Codex がコンピューターを使う三つの方法：Computer Use、Chrome 拡張機能、内蔵ブラウザ

Wed, 17 Jun 2026 12:19:30 +0800

Jason は X で、Codex がコンピューターを操作する能力について長い記事を公開しました。実用上の論点は明快です。Codex は Computer Use、Chrome 拡張機能、内蔵ブラウザという三つの方法で「コンピューターを使う」ことができますが、それぞれの境界は少し紛らわしい。

要点は次の通りです。

プラグインや MCP で解決できるなら、まず構造化ツールを使う。
デスクトップアプリ、システム設定、API のない画面を操作する必要があるなら @Computer。
ログイン済みの Chrome、アカウント状態、Cookie、複数タブに依存するなら @Chrome。
Web サイトの開発、ローカルページのデバッグ、レスポンシブ確認、視覚的フィードバックなら @Browser。

視覚的な操作は、構造化ツールが届かない境界で最も役に立ちます。Slack プラグインは、Codex に Slack 画面をクリックさせるより正確なことが多いです。GitHub プラグインの操作も、Web サイトを操作するより検査しやすい。API、プラグイン、MCP が最後の一手をカバーできないときだけ、Codex に画面を見てボタンを押させる、という考え方がよさそうです。

元の投稿：https://x.com/jxnlco/status/2066970432855581052

1. `@Computer` でデスクトップアプリとネイティブアプリを操作する

Computer Use は三つの中で最も広い操作面です。Codex は、あなたが許可した macOS または Windows アプリの GUI を観察し、ウィンドウ、メニュー、キーボード入力、クリップボードを使って操作できます。

同時に、たいてい最も遅い方法でもあります。構造化プラグインなら API を直接呼べますが、Computer Use は画面を見て、どこをクリックするか判断し、アプリの反応を待ち、次の状態を確認します。この視覚ループには時間がかかります。ただし、有用な API を公開していないソフトウェアも扱えるのが利点です。

macOS では、「遅い」ことが必ずしも邪魔になるとは限りません。Computer Use は、許可されたアプリ内でバックグラウンド作業を進めながら、あなたはコンピューターのほかの部分を使い続けられます。扱える対象は、インストール済みで許可したアプリによります。Spotify、Xcode、システム設定、iOS シミュレーター、さらには iPhone Mirroring などが候補になります。

@Computer が向いているタスク：

Spotify、金融アプリ、デザインツールなどのネイティブデスクトップアプリ；
iOS シミュレーター、iPhone Mirroring、その他 GUI でしか操作できないフロー；
システム設定やアプリ設定；
プラグイン、MCP、API がないデータソース；
複数のローカルアプリをまたぐワークフロー；
構造化連携で大部分は完了しているが、最後の UI 操作だけが足りない場合。

インストール方法：

Codex の Settings を開く。
Computer Use に移動する。
Install をクリックし、案内に従って権限を付与する。

起動方法：

`1`	`Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.`

`1`	`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.`

元の投稿には、境界をよく示す例があります。Jason は盗まれた Amazon 荷物のサポート待ちを Codex に任せたことがあります。Amazon は担当者につながるまで約 25 分かかると表示していました。そこで Codex に、5 分ごとにチャットを確認し、担当者が現れたら 1 分ごとの確認に切り替え、できる範囲で返金対応を進めるよう依頼しました。戻ってきたときには返金が完了していました。

もう一つの典型的な使い方は「最後の一歩」です。Codex が Slack からフィードバックを読み、コードを変更し、動画をレンダリングできても、そのスレッドで使える Slack 連携がファイルアップロードに対応していない場合があります。このとき Computer Use は Add file をクリックするだけで、構造化ツールに欠けていた最後の操作を完了できます。

安全境界はより広くなります。Computer Use には、一度に一つの明確なアプリまたはフローだけを与えるのがよいです。金融、アカウント、支払い、認証情報、プライバシー、システムセキュリティに関わる操作では、人がその場にいて、権限プロンプトを確認すべきです。

2. `@Chrome` でログイン状態、複数タブ、アカウント関連タスクを扱う

Codex Chrome 拡張機能は、ログイン済みの Chrome 状態を Codex に使わせます。タスクがアカウント、Cookie、ブラウザプロファイル、既存タブ、拡張機能に依存するなら、@Chrome が向いています。

@Chrome が向いているタスク：

Gmail、LinkedIn などログインが必要なサイト；
Salesforce、サポートコンソール、社内ツール；
社内ダッシュボード；
複数の認証済みサイトをまたぐ調査；
アカウント、Cookie、ブラウザ拡張機能に依存するフォーム。

インストール方法：

Codex の Plugins を開く。
Chrome を追加する。
案内に従って Codex Chrome 拡張機能をインストールし、権限を承認する。
拡張機能が Connected と表示したら、新しいスレッドを開始する。

起動方法：

`1`	`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.`

Chrome タスクはタブグループ内で実行されるため、同じ Codex スレッドに関係するページをまとめておけます。内蔵ブラウザと違って、この操作面はあなたの実ブラウザ ID を使います。そのため能力は高く、同時により慎重に扱う必要があります。

Chrome のもう一つの大きな利点は、複数タブの制御です。一つのタブで文脈を読み、別のタブで情報を比較し、三つ目のタブで作業を続けられます。Computer Use もブラウザを視覚的に操作できますが、Chrome はタスクを画面座標の連続ではなく、ブラウザワークフローとして理解できます。

元の投稿では Strudel Composer の例が紹介されています。Jason は、すでに開いていた音楽制作タブを Codex に渡し、音楽をもっと面白くするよう依頼しました。Chrome は選択中のタブと、そのページが提供する WebMCP ツールを Codex に渡しました。Codex は作品を調べ、和声と 4 分間の構成を書き直し、テンポを変更し、曲を保存して再生状態のままにしました。各ボタンを視覚的に探す必要はありませんでした。Chrome がタブの文脈とページの構造化機能を組み合わせられたからです。

長期タスクにも Chrome は向いています。たとえば、毎日 Chrome で X の DM、関連ニュース、フィードバックを確認し、長期的に残す価値があるものをローカルの vault に追加し、投稿や送信はしないよう明示できます。

1
2
3

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.

重要なのは、Codex が X を開けることではありません。同じスレッドが時間をまたいで同じログイン済み作業に戻り、見つけた情報をローカルファイルにつなげ、レビュー可能な結果を残せることです。

Chrome の信頼境界も明確にする必要があります。Web サイトは Codex のクリック、送信、メッセージをあなたの行動として扱います。ページ内容そのものも信頼できない入力になり得ます。より安全なのは、調査、移動、下書きは自動化し、送信、公開、購入、提出の前にはあなたの確認を必須にすることです。

タスク全体がブラウザ内にあり、ログイン状態が必要なら、Computer Use より先に Chrome を選びます。

3. `@Browser` で Web サイトを開発、デバッグする

内蔵ブラウザは Codex スレッド内にあるブラウザです。あなたと Codex は同じレンダリング済みページを見るため、Web 開発、視覚的デバッグ、デザインフィードバックに特に向いています。

@Browser が向いているタスク：

ローカル開発サーバー；
ローカル HTML やファイルのプレビュー；
ログイン不要の公開ページ；
視覚的なバグの再現；
レスポンシブレイアウトの確認；
ページ要素へのデザインフィードバック。

最も重要な制約は分離です。内蔵ブラウザは、通常のブラウザプロファイル、Cookie、拡張機能、ログインセッション、既存タブを使いません。アカウントが必要なタスクでは制約になりますが、不要なタスクでは明確な安全境界になります。

インストール方法：

Codex の Plugins を開く。
Browser プラグインを追加する。
有効化する。

起動方法：

`1`	`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 は関連するスクリーンショットと要素の文脈を受け取り、ファイルを変更し、同じページを開き直します。

デザイン作業では、アイデア、調査メモ、プロジェクト状況を Codex に渡し、単一ファイルの index.html を生成して内蔵ブラウザで開かせることができます。別のプロンプトでデザイン全体を説明し直す代わりに、実際のページへ直接注釈できます。

1
2

Create a single-file index.html for this project brief and open it in the
in-app @Browser.

この場合、ページ自体が仕様になります。

内蔵ブラウザは混合ワークフローの起点としても便利です。元の投稿では X 投稿の例が挙げられています。まず内蔵ブラウザで投稿を開き、Codex にどの投稿を指しているか確認させます。その後 Twitter CLI に切り替え、ブラウザ UI では隠れていたネスト返信を含む 38 件の返信を取得します。これは「最も狭い操作面で画面上の文脈を確立し、深い取得には構造化ツールを使う」というルールの実例です。

ただし、Google ログイン、Passkey、ブラウザ拡張機能、アカウント状態で詰まる場合は、内蔵ブラウザから Chrome に切り替えるべきです。

Appshots：文脈を指し示すもので、実行手段ではない

Appshots は、Codex がコンピューターを制御する第四の方法ではありません。目の前の文脈を Codex に渡す方法です。

Mac では CMD を 2 回押すと、直近のウィンドウをキャプチャできます。Codex は画像と利用可能なテキストをスレッドに添付します。エラー、メール、デザイン、設定パネル、見慣れないフォームを Appshot し、Codex に何をしてほしいか伝えられます。

覚えやすいモデルは次の通りです。

Appshots はコンピューター上のものを指し示す。Browser、Chrome、Computer Use はそれに対して行動する。

Appshots は現在、macOS の Codex app から作成されます。キャプチャするのは最前面のウィンドウで、デスクトップ全体ではありません。そのため、アプリの制御権を与えずに、焦点の合った文脈を渡すのに向いています。

どう選ぶか

日常のワークフローでは、次の順序で判断できます。

まずプラグイン、MCP、CLI、API があるか確認する。構造的に完了できるなら、Codex に UI をクリックさせない。
デスクトップアプリ、システム設定、シミュレーター、複数のローカルアプリが必要なら @Computer。
ブラウザ内のタスクで、ログイン状態、Cookie、拡張機能、複数タブに依存するなら @Chrome。
Web 開発、公開ページ確認、ローカルプレビュー、デザイン注釈なら @Browser。
Codex に「このウィンドウを見て」と伝えたいだけなら、まず Appshots で文脈を渡し、その後どの操作面を使うか決める。

これらの入口の違いは、機能の違いだけではありません。信頼境界の違いでもあります。実際のアカウントやデスクトップ環境に近づくほど、目的を明確にし、実行してはいけない操作を書き、送信、提出、支払い、公開の前に人間の確認を残すべきです。

Chrome拡張機能 on KnightLiブログ

Codex がコンピューターを使う三つの方法：Computer Use、Chrome 拡張機能、内蔵ブラウザ

1. @Computer でデスクトップアプリとネイティブアプリを操作する

2. @Chrome でログイン状態、複数タブ、アカウント関連タスクを扱う

3. @Browser で Web サイトを開発、デバッグする

Appshots：文脈を指し示すもので、実行手段ではない

どう選ぶか

1. `@Computer` でデスクトップアプリとネイティブアプリを操作する

2. `@Chrome` でログイン状態、複数タブ、アカウント関連タスクを扱う

3. `@Browser` で Web サイトを開発、デバッグする