Computer Use という言葉を、最近になってようやく実際に使えるものとして捉えられるようになってきました。AI が画面を見て、ボタンを押したり、文字を入力したりしながらアプリを操作するのは実用機能というよりデモ寄りの技術というのが筆者のこれまでの印象です。
ところが最近は、Computer Use が単なるコンセプトではなく、ローカルアプリを実際に操作する機能として実用化してきているように見えます。特に Codex App の Computer Use は、想像していたよりも速くそれなりに正確に動きます。
そこでこの記事では、OpenAI のドキュメント Computer Use と Codex App の実装を起点に、Codex App で Computer Use がどのように見えているのかを確認します。そのうえで、Computer Use plugin に含まれる Skill、MCP サーバー定義、ローカル実行ファイルから、仕組みをどこまで読み解けるかを見ていきます。
Computer Use とは何か
OpenAI の Computer Use ガイドでは、Computer Use は computer tool を使った Responses API のループとして説明されています。モデルは画面の状態を見ながら、クリック、入力、スクロールなどの操作を決めます。実行側のプログラムは、その操作を実際の環境で実行し、更新後の画面状態を再びモデルに返します。
ざっくり言うと、Computer Use は次のようなループです。
task を送る
↓
必要に応じて画面状態を取得する
↓
モデルが次の UI 操作を決める
↓
実行側が click / type / scroll などを実行する
↓
更新後の画面状態を返す
↓
モデルが完了と判断するまで続ける
この仕組みでは、モデルが単にテキストを返すだけではありません。画面を見て、操作対象を判断し、実行側に UI 操作を依頼します。そのため、通常の API 呼び出しよりも遅く、不安定になりやすい面があります。画面の変化、権限ダイアログ、ログイン状態、確認ボタン、アクセシビリティ情報の有無などに左右されるためです。
また、Computer Use は実際のアプリやアカウントを操作します。送信、削除、購入、権限変更、ファイル操作のような操作では、間違えると現実の環境に影響が出ます。そのため、安全確認や実行前の確認が重要になります。
Computer Use plugin の中身を見る
Codex App のプラグイン画面で Computer Use を開くと、Control Mac apps from Codex という説明とともに、含まれるものとして Computer-use MCP サーバーと Computer Use Skill が表示されます。
つまり Codex App の Computer Use は、単体の魔法の機能というより、MCP サーバーと Skill をまとめた plugin として提供されているように見えます。
手元のファイルシステムでは、インストール済みの Computer Use plugin は次の場所にありました。
~/.codex/plugins/cache/openai-bundled/computer-use/1.0.780/
主なファイルは次のようになっていました。
~/.codex/plugins/cache/openai-bundled/computer-use/<version>/
├── .codex-plugin/
│ └── plugin.json
├── .mcp.json
├── assets/
│ └── app-icon.png
├── skills/
│ └── computer-use/
│ └── SKILL.md
└── Codex Computer Use.app/
└── Contents/
├── Info.plist
├── MacOS/
│ └── SkyComputerUseService
└── SharedSupport/
└── SkyComputerUseClient.app/
└── Contents/
└── MacOS/
└── SkyComputerUseClient
この構成を見ると、Computer Use plugin には少なくとも次の要素が含まれていることが分かります。
- plugin 定義
- MCP サーバー定義
- Computer Use 用の Skill
- macOS ネイティブアプリ
- MCP サーバーとして起動されるクライアント実行ファイル
- 背後で動くサービスらしき実行ファイル
Computer Use Skill に書かれていること
skills/computer-use/SKILL.md には、Mac の UI を操作するときのガードレールのような内容が書かれています。
冒頭では、Computer Use がローカル Mac アプリを読み取り、クリック、入力、スクロール、ドラッグ、キー操作などで UI を操作するためのものだと説明されています。そのうえで、専用 plugin や別の interface で完了できる場合はそちらを優先し、Computer Use は必要なときに使うように指示しています。
これは重要です。Computer Use は実際のローカル環境に対して操作を行います。アプリ、ファイル、アカウント、外部サービスに影響を与える可能性があります。そのため、通常の tool 呼び出しよりも慎重に扱う必要があります。
SKILL.md では、特に次のような操作について確認ルールが定められていました。
- データの削除
- アカウント作成の最終ステップ
- 権限やアクセス範囲の変更
- API キーや OAuth キーの作成
- ファイルのアップロード
- 第三者へのメッセージ送信
- 購入や金融取引
- ローカルシステム設定の変更
- 医療関連の操作
- 機密情報の入力や送信
また、Web ページ、PDF、アップロードされた文書などに書かれている指示を、そのままユーザーの許可として扱ってはいけない、という境界線も示されています。これは prompt injection 対策としてかなり重要です。
つまり SKILL.md は、Computer Use の実行能力そのものではなく、「その能力をどう使うべきか」「どこで確認を挟むべきか」を Codex に教える部分だと考えられます。
MCP サーバーとして起動されるもの
次に .mcp.json を見ると、Computer Use MCP サーバーの起動設定が確認できます。手元では、次のような設定になっていました。
{
"mcpServers" => {
"computer-use" => {
"args" => [
0 => "mcp"
]
"command" => "./Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient"
"cwd" => "."
}
}
}
この設定から、Codex App は SkyComputerUseClient mcp をローカル MCP サーバーとして起動していることが分かります。
実際に SkyComputerUseClient --help を見ると、mcp サブコマンドがあり、説明も Runs the Computer Use client as an MCP server になっていました。つまり、Codex App から見た Computer Use の入口は SkyComputerUseClient です。
今回確認した Computer Use MCP サーバーでは、次のような tool が見えていました。
list_appsget_app_stateclickperform_secondary_actionset_valuescrolldragpress_keytype_text
この tool 一覧を見ると、Computer Use がかなり素朴な UI 操作プリミティブの集合として提供されていることが分かります。アプリ一覧を取り、アプリの状態を読み、要素をクリックし、値を設定し、スクロールし、ドラッグし、キー入力やテキスト入力を行う、という構成です。
ここまでを見ると、役割分担は次のように見えます。
- Skill は「Computer Use をどう使うべきか」を教える
-
SkyComputerUseClientは MCP サーバーとして tool を公開する -
SkyComputerUseServiceは macOS 側の画面取得や操作に関わるサービスのように見える
ただし、SkyComputerUseClient や SkyComputerUseService はコンパイル済みの macOS ネイティブ実行ファイルです。ソースコードが同梱されているわけではないため、内部実装を直接読むことはできません。ここで述べている役割分担は、ファイル構成、起動設定、tool の返り値、実際の挙動から見た推定です。
Sky という名前について
ここで出てくる SkyComputerUseClient や SkyComputerUseService の Sky という名前も気になります。
OpenAI は 2025-10-23 に、Mac 向け AI インターフェイス Sky を開発していた Software Applications Incorporated の買収を発表しています。Sky は、Mac の画面上の内容を理解し、ユーザーのアプリを使って操作できることを狙った製品でした。
そのため、SkyComputerUseClient や SkyComputerUseService の Sky は、この買収前の Sky に由来する内部名が残っている可能性が高そうです。
ただし、OpenAI が公式に「SkyComputerUseClient の Sky はこの製品名に由来する」と説明している一次情報は見つかりませんでした。したがって、ここは推定として扱うのが安全です。
macOS の Screen Recording と Accessibility 権限を許可する意味
Codex App で Computer Use を使うには、macOS の Screen Recording と Accessibility 権限を許可する必要があります。
これは単なる初期設定ではありません。Computer Use が画面を読み、UI を操作するための前提です。
Screen Recording は、画面の見た目そのものを画像として取得するための権限です。一方、Accessibility は、アプリが macOS に公開している UI 要素の役割や階層を読み取り、必要に応じてその要素を操作するための権限です。
実際、後で見る get_app_state の返り値には、ウィンドウ、ツールバー、ボタン、検索テキストフィールド、見出しのような構造化された情報が含まれていました。これは単なるスクリーンショット OCR というより、macOS のアクセシビリティツリーに近い情報を利用しているように見えます。
つまり Computer Use は、画像としての画面と、アクセシビリティ情報としての UI 構造の両方を使っている可能性が高いです。
実際に動かしてみる
ここからは、実際に tool を呼び出して挙動を見ていきます。
まず list_apps を実行すると、この環境で Computer Use が対象候補として検出している macOS アプリの一覧を取得できました。
返ってきた一覧には、次のようなアプリが含まれていました。
Google Chrome — com.google.Chrome [running]
Codex — com.openai.codex [running]
Code — com.microsoft.VSCode [running]
Finder — com.apple.finder [running]
システム設定 — com.apple.systempreferences
株価 — com.apple.stocks
Kindle — com.amazon.Lassen [running]
ChatGPT — com.openai.chat
Amical — com.amical.desktop
メール — com.apple.mail
1Password — com.1password.1password
カレンダー — com.apple.iCal
この時点で、Computer Use が単にブラウザだけを対象にしているわけではないことが分かります。Chrome、Finder、VS Code、株価、メール、カレンダーなど、ローカルの Mac アプリを対象候補として認識しています。
株価アプリを操作してみる
次に、macOS の株価アプリを対象にして状態取得とクリックを試しました。
最初の get_app_state では、初回起動時の案内画面が返ってきました。Computer Use からも、ようこそ 株価へ という文言と 続ける ボタンが見えていました。
その 続ける を押して状態を取り直すと、ウォッチリストとニュース一覧が返り、その中に Nikkei 225 が含まれていました。画面上では 5月10日 表示で、Nikkei 225 の値は 62,713.65、前日比は -120.19 と読めます。画像とアクセシビリティツリー由来の情報を見ながら指数の値まで辿れていることが分かります。
最後に、computer-use MCP サーバの返り値を確認できました。実際、手元で確認できた JSON には server: "computer-use"、tool: "click"、app: "com.apple.stocks"、element_index: "12" があり、結果の content[] にアクセシビリティ由来と見られるテキストダンプと PNG 画像が同時に含まれていました。つまり Codex App 側では、MCP tool の実行結果として画像と構造化情報をまとめて受け取り、それを次の判断材料にしているようです。
なぜ速く感じるのか
Computer Use を触ってみると、冒頭で書いたように、想像より速く感じる場面があります。
その理由は、公開されているソースコードを読めるわけではないため断定できません。ただし、今回の観察からはいくつかの仮説が立てられます。
まず、画像だけを見て座標を推測しているわけではなさそうです。get_app_state では、画面画像に加えて、アクセシビリティツリー由来と見られる構造化情報が返っています。これを使えば、モデルは「画面のどこをクリックするか」を毎回ゼロから画像だけで推測する必要がありません。
たとえば、続ける ボタンが UI 要素として取得できていれば、「ボタンらしき場所を画像から探す」のではなく、「この index のボタンをクリックする」という操作に落とせます。これなら、対象要素の特定が速く、安定しやすくなります。
仕組みを図にすると
今回の観察結果をもとにすると、Computer Use MCP は次のような構成に見えます。
Codex App
|
| MCP / JSON-RPC over stdio
v
SkyComputerUseClient mcp
|
| local IPC と思われる通信
v
SkyComputerUseService
|
| macOS Accessibility / Screenshot / Keyboard / Mouse
v
Target App
Codex App は、Computer Use plugin に定義された MCP サーバーを起動します。その入口が SkyComputerUseClient mcp です。
SkyComputerUseClient は、list_apps、get_app_state、click、type_text などの tool を Codex に公開します。そしてその背後で、SkyComputerUseService が macOS の Screen Recording、Accessibility、キーボード、マウス操作に関わっているように見えます。
ただし、この内部構成は観察に基づく推定です。実装本体はコンパイル済みのネイティブ実行ファイルであり、ソースコードが同梱されているわけではありません。そのため、実際のプロセス間通信やアクセシビリティ情報の整形方法までは確認できていません。
まとめ
今回確認した範囲では、Computer Use plugin は次の要素で構成されています。
- Computer Use の使い方と安全ルールを定義する Skill
- Codex から呼び出される MCP サーバー定義
- MCP サーバーとして起動される
SkyComputerUseClient - macOS 側の画面取得や操作に関わるように見える
SkyComputerUseService- スクリーンショットとアクセシビリティツリー由来と見られる構造化情報
-
click、type_text、scroll、press_keyなどの UI 操作 tool
特に重要なのは、Computer Use が画像だけで動いているわけではなさそうな点です。get_app_state の返り値には、スクリーンショットだけでなく、ウィンドウ、ボタン、テキストフィールド、見出し、action などの構造化情報が含まれていました。これは macOS の Accessibility API に近い情報であり、Codex App がそれを次の操作判断に使っているようです