おっと!フォームの送信中に問題が発生しました。
あなたのコーディングエージェントはコードを書けます。しかし、経費報告書を提出したり、デスクトップアプリを開いたり、ログインが必要なフォームに入力したりできるでしょうか？
それが、AIツールにおける最新のカテゴリである「コンピュータ利用エージェント」を推進する問いです。OpenAIのCodexには、エージェントが画面を見て、スクリーンショットとマウスクリックを通じてアプリケーションと対話できるComputer Use機能が搭載されました。SimularのSimulangは根本的に異なるアプローチを取ります。オペレーティングシステムのアクセシビリティツリーを読み取り、LLMを介さずに再現可能な決定論的スクリプトを作成するのです。
私は両方を同じデスクトップ自動化タスクのセットでテストしました。その結果と、どちらを選ぶべきかをご紹介します。
CodexはOpenAIのAIエージェント プラットフォームです。2021年にコード生成モデルとして最初にリリースされましたが、Codexはコードを書き、ターミナルコマンドを実行し、ウェブを閲覧できる多機能エージェントへと進化しました。そして、最新のアップデートでは、Computer Use機能を通じてデスクトップアプリケーションを制御できます。
Computer Use機能は、ユーザーの画面のスクリーンショットを撮り、それらをビジョンモデルに送信し、マウス/キーボードアクションを返すことで動作します。エージェントはあなたが見るもの、つまりピクセルのグリッドを見て、どこをクリックし、何を入力し、いつスクロールするかを決定します。
Codexはデフォルトでクラウドサンドボックス内で実行されます。Computer Use機能は、プラグインアーキテクチャを通じてこれをローカルデスクトップに拡張します。
Simulang は、ブラウザ、ネイティブアプリ、OSレベルのワークフローを自動化するためのスクリプト言語です。オープンソースであり、でインストールでき、
npm install -g @simular-ai/simulangオペレーティングシステムのアクセシビリティAPIを通じてアプリケーションと対話するTypeScriptスクリプトを生成します。Simulangは Simularによって開発・サポートされています。
スクリーンショットを見る代わりに、 Simulangはアクセシビリティツリーを読み取ります — VoiceOverやJAWSのようなスクリーンリーダーが使用するのと同じ構造化されたインターフェースです。すべてのボタン、テキストフィールド、メニュー項目、ラベルは、名前付きの参照可能な要素として公開されます。スクリプトはピクセル座標ではなく、参照によって対話します。
Simulangは設計されています コーディングエージェントの出力形式となります。Claude Code、Cursor、またはLLMを搭載したあらゆるコーディングツールは、Simulangスクリプトを一度書けば、そのスクリプトは決定論的に再生され、実行時にLLMは不要です。
これが中核となるアーキテクチャの違いであり、下流のすべてに影響を及ぼします。
Codexのコンピューター操作 スクリーンショット（通常1920x1080ピクセル）を撮り、それをビジョンモデルに送って「送信ボタンはどこですか？」と尋ねます。モデルは座標を返し、Codexはその座標にマウスを移動してクリックします。
このアプローチには3つの問題があります。
Simulang アクセシビリティツリーを読み取り、各要素に安定した参照IDを割り当てます。スクリプトは次のように指示します。 tree.activate("ref_42") 「ピクセル(847, 312)をクリック」ではありません。ウィンドウが移動しても、参照は有効です。OSのスケーリングが変更されても、参照は有効です。ダイアログが表示されても、Simulangは新しいツリーを読み取り、その意味的識別子によって要素を見つけます。
アクションごとの応答時間：ミリ秒。10ステップのワークフローは1秒未満で完了します。
この違いが、コストと信頼性の両方を左右します。
Codexのコンピューター操作 あらゆる操作にLLMコールが必要です。メニューを開く、ボタンをクリックする、フィールドに入力する、そのたびにLLMコールが発生します。各コールはトークンを消費し、レイテンシーを増加させ、誤解釈の可能性を生じさせます。同じワークフローを100回実行すると、100 x N回（Nはステップ数）のLLMコールの費用がかかります。
Simulang LLMを使用するのは、スクリプト作成時の一度だけです。コーディングエージェント（Claude Code、Cursorなど）がSimulangスクリプトを作成し、それ以降、スクリプトは決定論的に実行されます。100回実行しても、追加のLLMコール費用はかかりません。
コストの差は無視できません。週5日稼働する20ステップの日常ワークフローの場合：
どちらのツールも、画面に表示されるあらゆるアプリケーションと対話できますが、そのメカニズムは異なります。
Codex 設計上、アプリケーションに依存しません。ピクセルとして表示されていれば、Codexはそれと対話しようとします。これは、API、アクセシビリティサポート、自動化フックがないアプリケーションにとって非常に有用です。レガシーなエンタープライズソフトウェア、カスタムレンダリングされたキャンバス、リモートデスクトップセッションなど、すべてが対象となります。
Simulang ブラウザをネイティブに処理し（PlaywrightスタイルのアクセシビリティAPIを介して）、アクセシビリティデータを公開するあらゆるネイティブアプリケーション（事実上すべての標準的なmacOS、Windows、Linuxアプリケーションを含む）に拡張されます。アクセシビリティデータを公開しない稀なアプリケーションの場合、Simulangはビジョン・グラウンディングにフォールバックし、スクリーンショットを撮り、ビジョンモデルを使用してターゲット要素を特定します。
実用的な違いは次のとおりです。Simulangは、95%の操作で高速で決定論的なパス（アクセシビリティツリー）を使用し、残りの5%で低速で確率論的なパス（ビジョン）を使用します。一方、Codexは、100%の操作で低速で確率論的なパスを使用します。
Codex デフォルトではクラウドVMで動作します。コード、ファイル、認証情報はOpenAIのインフラストラクチャにアップロードされます。Computer UseプラグインはCodexをローカルデスクトップに拡張しますが、コアアーキテクチャはクラウドファーストです。
Simulang お使いのローカルマシン上で完全に動作します。スクリプトは、ブラウザセッション、ログイン中のアプリケーション、ファイルシステムなど、実際のデスクトップに対して実行されます。何もアップロードされません。スクリプトが明示的にデータをどこかに送信しない限り、マシンからデータが離れることはありません。
コンプライアンス要件（SOC 2、HIPAA、金融規制など）を持つ企業にとって、ローカル実行はしばしば譲れない条件となります。認証セッション（メール、銀行、社内ツールなど）を伴うワークフローを自動化したい個人開発者にとって、ローカル実行は認証情報の共有が不要であることを意味します。
公平性が重要です。ここにCodexの真の利点があります。
本番環境の自動化ワークフローを構築するほとんどの開発者にとって、Simulangはより実用的な選択肢です。スクリプトを一度書けば、永続的に実行でき、実行ごとに費用はかかりません。画面上のAIに「これを実行して」と指示するようなアドホックなデスクトップタスクでは、Codex Computer Useの方が迅速に開始できます。
これら2つのツールは相互に排他的ではありません。Codex（またはClaude Code、Cursor）を使用してSimulangスクリプトを作成することで、作成時のLLMインテリジェンスと実行時の決定論的実行という、両方の利点を享受できます。