CodeNote.net

サイト内検索

Open Interpreter rust-v0.0.42 の Computer Use 内部実装を読む — QA スキルから cua-driver CLI へ至る経路

#open-interpreter#cua#computer-use#code-reading#trycua#internals
重岡 正 · Tue, September 8, 2026

先日 Hermes Agent v2026.9.7 の Computer Use 内部実装を読む を書きました。読んでいて気になったのが、その少し前の macOS と Windows 両対応の Computer Use エージェント選定メモ で候補に挙げた Open Interpreter です。README に trycua/cua を利用すると明記されているので、同じドライバーを使うならエージェント側の実装も似ているのだろうか、という関心が続いていました。この記事はその続きで、openinterpreter/openinterpreter の Git tag rust-v0.0.42（commit 67299aeb）を固定して読んだコードリーディングノートです。

対象は Open Interpreter 側の実装です。trycua 側は補足調査として、調査時 HEAD の commit b4e3caec を別に固定しました。この Cua commit は Open Interpreter 側の依存としてロックされているわけではなく、QA スキルが何を外部へ委ねているかを説明するための別時点の参照資料です。以降のコードリンクは rust-v0.0.42 と補足 Cua commit の該当行を指しています。今回は GUI 操作・ドライバーのインストール・Rust テスト実行は行わず、公開ソースの静的調査にとどめました。

結論を先に書くと

Open Interpreter は trycua を使いますが、この版の標準 QA 導線は「同梱の qa-testing スキルがモデルに cua-driver CLI を使わせる」構成です。README の Computer Use 節と、そのスキル本文の両方で確認できます（README.md L99–103 と SKILL.md L1–101）。前回追った Hermes の専用 computer_use ハンドラーと「同じ統合方式」と書くと不正確になるので、そこは分けて説明します。

コードを追って印象に残った設計上の分かれ道は次の 6 点でした。

  • 配布されるのは操作ドライバーそのものではなく、まず QA の手順書。Rust バイナリに Markdown を埋め込み、スキル用キャッシュへ展開する
  • Web には agent-browser、ネイティブアプリには cua-driver を案内する。具体的な操作仕様は外部ツール自身から取得させる
  • 「観測 → 操作 → 再観測」はスキルに書かれたモデル向け規約であり、QA 専用の Rust コードが毎クリック後に自動検証する構成ではない
  • 実行には汎用コマンド実行基盤を使える。コマンドの承認・サンドボックス、Cua の認可、OS の権限を別々に考える必要がある
  • 画像は Cua 側の保存経路と view_image などの汎用画像入力を組み合わせないと、モデルへ直接届かない
  • Open Interpreter の tag だけでは実験条件を固定できない。PATH 上の既存ドライバーを再利用し、未導入時は Cua の可変な main 上のインストーラーを取得する

以下、それぞれをコードに当てながら書きます。本文では「標準 QA 導線」「この tag」「静的調査で確認できた範囲」を主語にして、利用者が別途 MCP サーバーを登録した構成、別プラグイン、旧 Python 版の OS mode まで同じだと一般化しないよう気を付けています。

全体像

処理経路は「スキルを読む経路」と「PC を操作する経路」の 2 段に分けて描くと見通しがよくなります。

flowchart TD
    A[OI バイナリに埋め込まれた QA スキル] --> B[skills/.system に展開]
    B --> C[スキル一覧と本文をモデルへ提供]
    U[ユーザーのアプリ検証依頼] --> L[選択したモデルとハーネス]
    C --> L
    L --> E[汎用コマンド実行と承認処理]
    E --> W[agent-browser CLI]
    E --> D[cua-driver CLI]
    W --> WB[Web ブラウザ]
    D --> S[Cua daemon / native runtime]
    S --> O[ネイティブアプリ]
    D --> R[テキスト・構造化結果・画像ファイル]
    R --> L
    R -.画像を読む追加呼び出し.-> I[view_image など]
    I --> L

図の cua-driver CLI → daemon は補足調査した Cua commit で確認した経路（Cua cli.rs L2255–2326）です。view_image は Open Interpreter に存在する汎用画像入力経路の例（view_image.rs L92–211）で、QA スキルがこの呼び出しを必ず発行するわけではありません。選択したハーネス・実行環境でツール名や提供機能が変わるため、全モデルが必ず exec_command を呼ぶという図にもしていません。

責務を分けると次のようになります。

層この調査で確認した責務主なソース
製品 READMEWeb とネイティブの操作基盤を宣言README.md
QA スキルツール導入、操作後確認、重要操作の事前確認を指示qa-testing/SKILL.md
スキル配布埋め込み、キャッシュ更新、探索 root への追加skills/src/lib.rs、ext/skills
ハーネススキルやツールをモデルへ見せる方式catalog_prompt.rs、Kimi の Skill handler など
コマンド実行権限要求、実行ポリシー、サンドボックスを処理unified exec handler / process manager
CuaCLI 引数を native runtime へ渡す外部リポジトリの cli.rs
画像入力ファイルを画像としてモデルへ渡すview_image.rs

samples にあるが、実際にはバイナリへ同梱される

入口は codex-rs/skills/src/assets/samples/qa-testing/SKILL.md です。ファイル名だけを見ると配布対象外のサンプルにも見えますが、skills/src/lib.rs の SYSTEM_SKILLS_DIR は include_dir! で src/assets/samples 全体を埋め込んでいます（lib.rs L55–100）。

install_system_skills() は次の処理を行います。

  1. home 配下の skills ディレクトリを用意する
  2. skills/.system のマーカーを埋め込み内容のフィンガープリントと比較する
  3. 一致すれば何もしない
  4. 更新が必要なら .system を削除して、埋め込み内容を展開し直す
  5. フィンガープリントをマーカーへ書く

ここでの「install」はスキルファイルの展開であって cua-driver のインストールではありません。Cua の導入は、モデルが後からスキル本文に沿って行う別工程です（SKILL.md L61–78）。

HostSkillsService::ensure_system_skills_installed() がこの処理を呼び、スキル root の構築では system cache を SkillScope::System として追加します（host_service.rs L459–463 と host_roots.rs L93–111）。

パスの説明にも注意が要ります。内部変数やコメントには codex_home / CODEX_HOME が残っていますが、Open Interpreter 製品の home は既定で ~/.openinterpreter、上書きは INTERPRETER_HOME で、CODEX_HOME を意図的に無視します（lib.rs L8–35）。したがって通常の展開先は次の形になります。

~/.openinterpreter/skills/.system/qa-testing/SKILL.md

テスト refreshes_only_the_oix_owned_system_skills_namespace は、古いマーカーのあるキャッシュを更新して QA スキルを埋め込み内容に戻すこと、廃止された system skill を除去すること、system 外のユーザースキルを残すこと、を検査しています。これは「スキルが確かに配布される」証拠として使えますが、PC 操作の E2E テストではありません（lib.rs L254–305）。

専用の操作 schema ではなく、外部 CLI の仕様を読ませる

QA スキルの構成はとても短いです。

  • 先にネットワーク到達性を確認する
  • Web は agent-browser を用意して agent-browser skills get core を読む
  • ネイティブは cua-driver を用意して cua-driver list-tools を読む
  • 操作前後の状態を比較する
  • 購入・メッセージ送信・フォーム送信・削除などは事前確認する

Web 側は macOS / Linux でプラットフォーム別の配布バイナリ、Windows で npm の導入手順を案内します（SKILL.md L25–59）。ネイティブ側は macOS / Linux 用 shell、Windows 用 PowerShell の導入手順を用意しています（SKILL.md L61–78、検証手順は SKILL.md L80–101）。

Cua の導入判定は macOS / Linux では command -v、Windows では Get-Command を使います。存在していれば、そのバイナリをそのまま使う設計で、版の一致や互換性まで Open Interpreter のスキルが検証するわけではありません。未導入時の取得先は trycua/cua/main/libs/cua-driver/scripts/install.* で、OI の固定 tag に対応した特定 Cua release を指定していません。

この設計の利点は、外部ツールの増減に Open Interpreter 側の巨大な schema を追従させずに済むところにあります。一方でモデルは、CLI の説明を読み、引数を組み立て、状態やエラーを解釈する必要があります。これはコードからの設計上の読み取りであり、Hermes より精度が高い・低いという実測結果ではありません。

list-tools が成功しても GUI 操作の準備完了とは限らない

補足調査した Cua の main.rs では、ListTools は inspect_tools_without_runtime() から一覧を表示します（Cua main.rs L507–540）。対して Call は run_call() へ入り、daemon の応答を確認して動いていなければ終了します（Cua cli.rs L2255–2326）。つまりスキルにある list-tools は仕様発見には有効ですが、daemon 起動・TCC 許可・操作対象の列挙まで検証するヘルスチェックとは違います。

OI 側スキルには Cua の doctor や daemon 起動手順まで明示されていません。導入後に実際の操作が成立するかは、ドライバーの導入状態と実行環境で確かめる必要があります。

スキルをモデルに届けるハーネス側の処理

一般のスキル案内は ext/skills/src/catalog_prompt.rs にあります。モデルへは名前・説明・場所を示し、該当タスクなら本文を読むという段階的な開示を指示します（catalog_prompt.rs L3–40）。ファイルのある場所を示すことと、本文がモデルに実際に読み込まれることは別段階です。

より具体的な実装例としては Kimi Code ハーネスの kimi_code_skill.rs が読みやすいです。

  1. Skill 呼び出しの skill と任意の args を解析する
  2. 内蔵の特別なスキルでなければ、現在の skill snapshot から有効な名前を探す
  3. read_skill_text() で本文を取得する
  4. frontmatter を除去し、引数を展開する
  5. <kimi-skill-loaded ...> で包んだテキストを user message として会話へ記録する
  6. ツール結果は読み込み済みであることを返す

これは Kimi Code 経路の具体例で、全ハーネス共通の呼び出し形式ではありません。ここにも Cua 専用の操作処理はなく、QA スキルを読んだモデルが次に何を実行するかを決めます（kimi_code_skill.rs L19–108）。

1 回のネイティブ QA を追う

「検証用アプリのカウンターを 1 増やし、表示が変わったことを確認して」と依頼した場合、スキルに沿う想定フローは次のようになります。これは収録済みの実行ログではなく、コードから組み立てた想定フローです。

  1. モデルが qa-testing の説明と本文を読む
  2. スキルの手順に従ってネットワークと CLI の有無を確認する
  3. 必要なら、通常のコマンド承認経路で CLI を導入する
  4. cua-driver list-tools などから利用可能な操作と仕様を把握する
  5. CLI を通じて対象アプリ・ウィンドウの初期状態を取得する
  6. モデルが要素や座標を選び、操作コマンドを組み立てる
  7. 汎用コマンド実行基盤がコマンドを処理する
  8. Cua 側の runtime が操作を実行し、結果を返す
  9. モデルが新しい状態を取得し、カウンターが変わったかを確認する
  10. 必要に応じて画像を読み、確認できた結果を利用者へ報告する

汎用実行経路の具体例では、unified exec handler が権限要求を解決し、manager.exec_command() へ進みます。process manager は shell command に対する承認要件を作り、UnifiedExecRuntime と ToolOrchestrator::run() を通します。これは GUI 専用の click 審査器ではなく、汎用コマンド実行の経路です（exec_command.rs L304–430 と process_manager.rs L1369–1439）。

Cua の補足ソースでは、run_call() は DaemonRequest の method="call" と tool 名・引数を daemon へ送ります。OI から Cua への入口が CLI であることと、Cua 内部が daemon を使うことは両立します。CLI 方式だから各プロセスが直接 OS API を呼ぶ、と説明してはいけない部分です（Cua cli.rs L2255–2326）。

セッションの持続性も CLI 経由で決まる

調査した Cua の run_call() では、明示的な非 default の session があるかを見て処理を分けます。匿名の one-shot call には一時的な transport session を発行し、応答後に session_end を送ります。明示的な session label には別の所有権名前空間を使います。

OI の QA スキルにはその session の付け方まで規定されていません。したがって「前回の capture の対象や要素参照が次の CLI 呼び出しへ必ず保持される」とは、このスキルだけからは保証できません。対象・session・element の寿命は、利用する Cua 版の仕様と実際にモデルが出した引数で確認する必要があります。これは Hermes との比較で深掘りできる、よい実機検証ポイントだと感じました。

verify は明示されているが、強制する場所が違う

QA スキルは、click コマンドが成功と返っただけで完了にせず、操作前後を取り直して、表示テキスト・カウンター・ステータス・選択状態・入力値・画像などで実変化を確認するよう求めます（SKILL.md L80–101）。

ここで区別したいのは次の 2 つです。

種類この導線での位置づけ
手順上の規約モデルがスキルを読み、再観測と比較を実行する
プログラム上の不変条件専用 handler が操作を包み、検証・宛先照合・再送可否を機械的に決める

本調査で確認した OI の QA 導線は前者にあたります。後者に相当する Cua 専用 adapter は確認できませんでした。Cua 自身が返す操作検証情報が存在しても、それを OI が独自の verdict へ正規化する処理がある、とは言えません。

同様に、OI のスキルには background-first の詳細な escalation ladder や、書き込み系を timeout 時に再送しない規約は書かれていません。「OI には再試行がない」と全体を否定するのでもなく、この統合部では Computer Use 固有の再送保証を確認できない、と書くのが正確です。

CLI の画像をモデルへ戻すには別の橋が要る

OI の QA スキルはスクリーンショットを証拠に使えるとしていますが、固定の保存先、最大保持枚数、auxiliary vision への自動切替は定義していません（SKILL.md L80–101）。

補足調査した Cua CLI は --screenshot-out-file がある場合、image content をデコードしてファイルへ保存します。指定がなければ画像を構造化 JSON へ screenshot_png_b64 等として載せる経路があります（Cua cli.rs L2327–2388）。

ここは注意点で、シェル出力に base64 が出ることと、モデルに画像入力が届くことは同じではありません。OI 側で利用できる経路の一例は、保存したファイルを view_image で開くことです。

ViewImageHandler は次を行います。

  • モデルの input modality に image があるかを確認し、非対応ならエラーにする
  • 選択された実行環境でパスを解決し、sandbox context を付けてファイルを読む
  • 画像としてデコード可能か検査する
  • 画像データ URL を持つ出力を作り、tool result の InputImage として返す

（view_image.rs L92–211 と view_image.rs L227–250）

この経路はソース上で存在しますが、QA スキルが必ず view_image を呼ぶという保証ではありません。また、非画像モデルを補助 VLM へ自動で救済する Cua 専用経路も、この調査範囲では確認できませんでした。README の「あらゆるモデル」という表現はモデル選択の自由度として読み、「あらゆるモデルがスクリーンショットを直接理解する保証」とは区別したいところです（README.md L99–103）。

macOS / Windows と承認の読み分け

標準 QA スキルは macOS / Linux・Windows の両方に導入例を持ち、Windows PowerShell 5.1 では && が使えない点、@ で始まる参照引数を引用する点まで案内します。これはクロスプラットフォームの利用を意図している証拠ですが、全 OS・全 GUI の動作検証結果ではありません（SKILL.md L1–101）。

権限については 4 つに分けると説明しやすいです。最初の「モデルへの行動指示」はスキル本文の規約で、残り 3 つがランタイム上の権限層にあたります。excerpt や本文で「3 層」と呼んでいるのはこの後者の 3 つを指します。

境界確認できたこと
モデルへの行動指示スキルは重要な操作の事前確認を求める
OI のコマンド実行汎用の approval policy、実行ポリシー、sandbox 設定が適用される
Cua runtime の認可Cua 自身の permission mode などで制御される。OI スキルは mode を設定していない
OS 権限とデスクトップセッションドライバーが実際に画面を取得・入力できる環境が必要

（process_manager.rs L1369–1439 と Cua README.md L38–62）

調査した Cua README では、standard は通常の CLI・MCP 利用向けの既定プロファイルで、既定の boundaries は残るとされます。bounded はマニフェストに基づく deny-by-default、unrestricted には明示的な bypass の承諾が必要とされます。mode は runtime を所有するプロセスに属し、起動時に決まります。これを「OI で毎クリック確認が出る」と読み替えないよう気を付けたい部分です。

macOS では Cua README が responsible app identity と TCC の帰属を説明しており、スタンドアロンの CuaDriver.app、direct MCP、embedded で起動の責務が変わります（Cua README.md L158–169）。OI のスキルはこの分岐を詳述していないため、「ターミナルに権限を付ければ必ずよい」と記事で決めつけないほうが安全です。

Windows の補足調査では、Cua インストーラーのコメントに autostart 既定 off と読める説明がある一方、実際のパラメータ定義は $AutoStart = $true で -NoAutoStart が off にする挙動でした（Cua install.ps1 L79–126）。このようにコメントと実装が食い違うことがあるため、実機記事では導入した版と起動状態を記録しておきたいところです。OI 側スキルはこのインストーラーを追加引数なしで取得・実行します。

computer_use.rs というファイル名だけで Cua 接続と判断しない

リポジトリには ComputerUseConfigToml、macOS の bundle ID、Windows の AUMID / exe に関する設定型も存在します（computer_use.rs L1–39）。しかし、その存在だけでは qa-testing → cua-driver CLI の各操作をこの設定が検査すると証明できません。Cua 固有の接続経路との関連は別途追う必要があるため、本記事ではこれを Cua の権限設定として紹介していません。

再現性：OI の版と Cua の版は別々に固定する

OI 側は tag を固定して読める一方、QA スキルの依存取得は動的です。

対象QA スキルでの扱い
QA 手順書OI の tag に含まれる内容で固定できる
既存の cua-driverPATH で見つかれば再利用。版指定なし
未導入時の Cua インストーラー外部 main 上の shell / PowerShell を取得
Web 用の配布物macOS / Linux は latest release URL、Windows は版未指定の npm
外部ツールの操作仕様実際にインストールされたツールから取得

Cua の調査時インストーラーは CUA_DRIVER_RS_VERSION を案内していますが、これは Cua 側インストーラーの機能であり、OI がその値を設定しているわけではありません。shell インストーラーはさらに公開 URL の _install-rust.sh へ委譲するため、最初の script URL だけ固定しても全取得物が固定されるとは限りません（Cua install.sh L18–38 と Cua install.sh L93–122）。Windows 側には調査時点で焼き込みの 0.26.1 がありましたが、これも OI rust-v0.0.42 が常に 0.26.1 を使う意味ではありません。

実験の記録には、OI commit、ハーネス名、モデル名、Cua の実体パス・版・hash、OS 版、daemon 起動方式をセットで残すのがよさそうです。両者が Rust 製という共通点より、実行時依存が別配布になっている点のほうが再現性には直接効いてきます。

Hermes 記事との比較表

Hermes 列は Hermes Agent v2026.9.7 の Computer Use 内部実装を読む の整理に基づきます。OI 列は今回の固定ソース調査です。

観点Hermes v2026.9.7OI rust-v0.0.42 の標準 QA 導線
モデルの入口単一 computer_use toolQA スキルと汎用コマンドツール
Cua への接続専用 backend から MCPモデルが CLI を呼ぶ
対象の保持wrapper が sticky target を管理QA スキルは専用状態を持たない
操作確認結果を verdict へ整形モデルに前後比較を指示
timeout 時mutation の自動再送を抑制Cua 専用の再送規約を未確認
画像専用の結果変換経路汎用画像ツール等との接続が必要

比較から言えるのは、OI は少量の手順書で外部 CLI を使える構成、Hermes は操作要求と結果の意味を専用層で管理する構成、という責務配置の差です。操作成功率、費用、速度、非干渉性の優劣は測定していないため、順位付けはしていません。

断言を避けたい表現の整理

書き分けの意図を残すために、避けたい表現と、コードに沿う表現の対応もまとめておきます。

避けたい表現調査に沿う表現
OI は Cua の MCP を標準接続している同梱の QA スキルは Cua CLI の利用を案内する
QA スキルに Cua バイナリが同梱される手順書が同梱され、ドライバーは必要時に外部導入する
click 成功なら QA 成功前後の実状態を比較するようスキルが指示する
必ずバックグラウンドで操作する背景操作の可否は利用する Cua と対象環境で確かめる
任意のモデルが画像を理解できる画像入力にはモデルの対応と画像を渡す経路が必要
OI の tag で Cua の版も固定されるCua の版・実体・起動条件は別途記録する
OI に Computer Use 関連コードはない専用設定等はあるが、QA の Cua 経路と混同しない

次に実機で確かめたいこと

コード上の結論と runtime 挙動を混同しないために、次はエージェント経由ではなくホストの端末から追試するつもりです。デイリースタンドアップやチームミーティングで結果を共有して、次に検証する人が、未確認の挙動と再現条件を把握できるように残しておきます。

  • OI 版・commit、ハーネス、モデル、Cua 版・hash を並べて記録し、コード調査との対応を確認する
  • skill listing と読み込んだ本文を確認し、QA スキルが無効化・上書きされていないかを見る
  • PATH、インストーラー版、daemon 状態を並べて list-tools 後に実操作へ進めるかを確認する
  • カウンターを 1 増やす簡単な題材で、操作前後の結果と CLI 呼び出し引数の履歴を保存する
  • 複数ウィンドウの検証で、pid・window・session・element 参照が CLI 呼び出し間で正しい対象を維持するかを見る
  • フォーカスとカーソルの前後状態を記録して、ドライバー・アプリごとの非干渉範囲を確かめる
  • 日本語入力の入力手段・確定結果・保存後の内容を並べて、IME と貼り付けの差を見る
  • screenshot の保存先と画像ツール呼び出しをセットで観察し、画像がモデルへ実際に届いているかを確かめる
  • OI 側の承認・Cua mode・OS 許可の 3 層をそれぞれ独立に記録し、どの層で許可・拒否されたかを見る
  • 安全なテストアプリで timeout を人為的に起こし、モデルが同じ変更を再送してしまわないかをログで確認する

収集するコマンドの例（端末で実行する場合。自動インストールや GUI 操作は含めない）はこの形を想定しています。

# Open Interpreter の checkout 内
git rev-parse 'rust-v0.0.42^{commit}'
git show -s --format=fuller rust-v0.0.42
 
# 実際に使うバイナリ。未導入ならその事実を記録する
command -v interpreter
interpreter --version
command -v cua-driver
cua-driver --version
cua-driver list-tools

list-tools の結果は仕様発見用であり、画面取得の成功記録とは分けます。hash は macOS なら shasum -a 256、Windows なら Get-FileHash などで、ラッパーと実体を区別して取得します。

調査の根拠と限界

  • 既存 checkout は main のまま、調査対象ファイルは git show rust-v0.0.42:<path> で読みました。作業ツリーの現在版と tag 版を混ぜていません
  • 公開 remote に対して git ls-remote で tag の commit を照合しました
  • tag 全体で trycua / cua-driver / cua_driver を検索し、主要な一致は README 翻訳、QA スキル、Kimi 関連ドキュメント、スキル本文を扱うテストでした。Cua 専用 Rust adapter や固定 Cargo 依存の証拠は、この検索と呼び出し経路からは確認できませんでした
  • computer_use の文字列も別途確認し、設定型や guardian 関連の名前があることを確認しました。「Cua 専用経路を未確認」と「Computer Use 関連コードが皆無」を区別しています
  • スキル配布テストはソースを読んだだけで、今回テストを実行して pass した、という意味ではありません
  • 外部 Cua は README、インストーラー、CLI 入口と run_call() を補足確認しました。OS 別 native backend 全体や操作検証アルゴリズムを監査していません
  • Hermes 比較は指定された既存記事に基づきます。現在の Hermes 最新版や全プラットフォームの再調査ではありません
  • GUI 実測がないため、速度、成功率、日本語入力、画像認識精度、無干渉動作は未評価です

以上、Open Interpreter rust-v0.0.42 の Computer Use を tag に固定して読み、バイナリ埋め込みの QA スキル・外部 CLI への責務委譲・汎用コマンド実行と承認・view_image を介した画像経路・Cua permission mode と OS 権限の 3 層・OI と Cua の版が別々になる再現性、という 6 つの分かれ道を Hermes 実装と比較して整理した、現場からお送りしました。

参考情報