OpenAI が Codex を（ほぼ）あらゆる用途に開放したとき、技術界は注目した。AI がコードを書き、メールを下書きするようになってから何年も経つが、Codex が macOS を「自前のカーソルで見て、クリックし、タイピングする」ことで操作できるという主張は、根本的に異なる能力を示している。
クラウド上の言語モデルとローカルのオペレーティングシステムの間の溝を埋めることは、非常に困難なことで知られている。何十年にもわたり、自動化は脆い Application Programming Interface (API) や DOM スクレイピングスクリプトに依存してきたが、こうしたものは UI 要素が一つ変わっただけで壊れてしまう。
核となる技術的洞察は次のとおりだ。Codex はコードレベルの統合を捨て、ピクセルレベルの実行を選んだ。 OpenAI はマルチモーダルビジョンと低レベルのカーネルイベント注入を組み合わせることで、Graphical User Interface (GUI) をユニバーサルな API に変えてしまった。
これを実現する技術アーキテクチャを解説しよう。
Mac ネイティブエージェントのアーキテクチャ
AI が人の介入なしにアプリケーションをテストしたり、フロントエンドのデザインを反復改良したりするには、継続的な Perceive-Reason-Act（知覚・推論・行動） ループが必要だ。macOS 上で Codex が各段階をどう実装しているかは、おそらく次のとおりである。
1. 知覚: セマンティックビジョンとグラウンディングエンジン
AppleScript のような従来の自動化ツールは、UI のアクセシビリティツリーを読み取る。このアプローチは高速だが、UI 要素に適切なアクセシビリティタグが存在しないカスタムの Electron アプリ、Web キャンバス、ゲームでは失敗する。
OpenAI は Codex がアプリを「見る」ことで使うと述べており、これは Computer Vision に依存していることを意味する。Mac 上で動くホストアプリケーションは、デスクトップを高頻度でキャプチャする。そしてマルチモーダルモデルが、これらのフレームをセマンティックセグメンテーションによって解析する。HTML タグを探すのではなく、ボタン、検索バー、メニューのようなインターフェース要素の形状と文脈を視覚的に認識するのだ。
ここでの鍵となる技術的課題は グラウンディング（Grounding） である。AI が対象を特定したら、そのセマンティックなオブジェクトを画面上の正確なピクセル座標に対応付ける計算を実行する。「閉じるボタンをクリック」という指示を、ディスプレイの解像度やスケーリング係数を加味した正確な (x, y) 座標に変換するのだ。
| 段階 | 何が起きるか | 技術 |
|---|---|---|
| フレームキャプチャ | デスクトップの高頻度スクリーンショット | ホストアプリケーション |
| セマンティック解析 | コードではなく視覚的な見た目で UI 要素を特定 | マルチモーダルビジョンモデル |
| グラウンディング | セマンティックな対象をピクセル座標に対応付け | 座標回帰モデル |
| アクションディスパッチ | 合成入力イベントを OS に注入 | システムフレームワークのフック |
2. 行動: OS レベルのイベント注入
クリック位置を知っているだけでは、ソフトウェアが実際にそのアクションを引き起こせなければ意味がない。Codex は物理ハードウェアを完全にバイパスする。
macOS をネイティブレベルで操作するため、Codex は Apple の最も深いシステムフレームワーク、すなわち Quartz Event Services と Accessibility API をほぼ確実に利用している。
Codex がクリックを決めたとき、仮想的な CGEvent を合成し、mouseDown に続けて mouseUp を送り、それを macOS のシステムイベントキューに直接注入する。オペレーティングシステムから見れば、この合成イベントは物理的なトラックパッドの押下と区別がつかない。だからこそ Codex は どんな アプリケーションでも操作できる。人間がクリックできるものなら、Codex もクリックできるのだ。
3. 分離: 「ゴーストカーソル」の仕組み
おそらく最も技術的に野心的な主張は、Codex が「コンピュータを乗っ取ることなくバックグラウンドで動く」という点だろう。マクロレコーダーを使ったことがある人なら、従来の自動化がマウスカーソルを完全に乗っ取ってしまうことを知っている。
並行実行を実現するには、AI の入力とユーザーの物理的な入力を分離しなければならない。実装アプローチとしては次の二つが有力である。
| アプローチ | 仕組み | トレードオフ |
|---|---|---|
| ターゲットウィンドウルーティング | macOS は特定の Process Identifier (PID) に対してイベントを送れる。Codex は合成したクリックをグローバルなハードウェアカーソルを経由せず、対象アプリケーションのイベントループに直接届ける。 | オーバーヘッドが小さい。正確なウィンドウの特定が必要。 |
| 仮想フレームバッファ | システムがヘッドレスな仮想デスクトップ層を立ち上げる。Codex はこの見えないワークスペースを「見て」操作する間、ユーザーはプライマリなワークスペースで邪魔されずに作業を続けられる。 | メモリ使用量が多い。より強力な分離を保証。 |
仮想フレームバッファ方式は、Anthropic が自社の Computer Use 機能を発表した際に観察された仕組みと一致しており、デスクトップ AI エージェントにおける業界標準のパターンとして定着しつつあることがうかがえる。
展望: ポスト API の世界
その波及効果は技術的な実装の枠を遥かに超える。OS レベルでビジョンからアクションまでのパイプラインを解決したことで、OpenAI は従来の API をオプショナルなものにした。私たちはいま Large Action Model (LAM) の時代に入っている。
実務的な含意を考えてみよう。
- レガシーソフトウェアの統合: API のない 2008 年のエンタープライズツール？Codex には API は不要だ。アプリケーションを開き、インターフェースを操作し、データをコピーして、現代のダッシュボードに貼り付ける。
- プラットフォームの制限: 激しい API レート制限で開発者のアクセスを制限するプラットフォーム？Codex は Web ブラウザを開き、人間のユーザーと同じようにインターフェースを直接操作する。
- アプリ間のワークフロー: 以前なら繋がっていないアプリ間に専用のミドルウェアが必要だったタスクも、単一の自然言語の指示で编排できるようになる。
ソフトウェア業界は何十年もかけてアプリ間の架け橋を築いてきた。Codex が macOS の GUI をマスターした今、アプリ同士が話す必要はもうない。AI が私たちに代わってアプリを使うのだ。
FAQ
Codex は macOS 上で画面をどう「見る」のか？
Codex はホストアプリケーションを使い、デスクトップの高頻度スクリーンショットを取得する。そしてマルチモーダルビジョンモデルがこれらのフレームに対してセマンティックセグメンテーションを行い、背後のコードやアクセシビリティタグではなく、見た目に基づいてボタン、メニュー、テキストフィールドといった UI 要素を特定する。
クリックとキー入力をシミュレートするために Codex はどの macOS フレームワークを使っているのか？
Codex はおそらく Apple の Quartz Event Services と Accessibility API と連携している。仮想の CGEvent（mouseDown や mouseUp など）を合成して macOS のシステムイベントキューに注入し、物理ハードウェアのイベントと区別がつかない入力を作り出す。
カーソルを乗っ取らずにバックグラウンドでどう操作できるのか？
システムはおそらく、特定の Process Identifier (PID) に直接イベントを送るターゲットウィンドウルーティングか、あるいは仮想フレームバッファのいずれかを使っている。後者は見えないデスクトップワークスペースを作り出し、ユーザーの物理的なカーソルには影響を与えずに AI が独立して動くことを可能にする。
Large Action Model (LAM) とは何か。LLM とどう違うのか？
Large Action Model は、Large Language Model の能力をテキスト生成から現実世界のタスク実行へと拡張したものだ。LLM が応答を生成するのに対し、LAM はビジョンによって環境を知覚し、どのアクションを取るべきか推論し、システムレベルの入力注入を通じてそのアクションを実行する。Codex は LAM の概念を現実に実装した一例である。
