2026 年 5 月、Hacker News で Computer Use is 45x more expensive than structured APIs のベンチマーク記事が大きな話題になりました。「同じタスクを Computer Use（スクリーンショット + ブラウザ操作）で実行すると、構造化 API の 45 倍のトークンを消費する」という結果は、AI 受託の現場に 「便利だけど高い」選択肢の存在を強く印象づけました。
弊社でも Computer Use（Claude / OpenAI Operator / Gemini Browser Use 等）を組み込んだ案件の相談が増えていますが、「とりあえず Computer Use で全部やる」設計は受託として破綻します。本記事では、Computer Use と構造化 API を使い分けるコストエンジニアリングの設計指針を整理します。
なぜ 45 倍の差が出るのか
Computer Use と構造化 API のコスト差は、以下の 4 点で構造的に生まれます。
| 項目 | Computer Use | 構造化 API |
|---|---|---|
| 入力 | 1 アクションごとに 1 〜 4 枚のスクリーンショット | JSON / GraphQL の数百トークン |
| 出力 | ”click at (x, y)” の連続生成 | 構造化された 1 オブジェクト |
| 試行回数 | UI 変更で再試行が頻発 | 仕様変更まで安定 |
| エラー回復 | スクショ連発で原因特定 | ステータスコード即判定 |
特に スクリーンショットの 1 枚あたりトークン消費が支配的で、Vision モデルへの入力が線形ではなく対数的にコスト増する性質があります。
これは GitHub Copilot 従量課金とトークンガバナンス で扱った “トークン消費型課金” 時代の典型的な落とし穴で、「Computer Use を案件に入れる = 月予算の 30 〜 50% を消費する可能性がある」ことを最初に顧客に説明する必要があります。
受託で組む「Computer Use 採用判定」の決定木
弊社では、案件で Computer Use を採用するかを以下の決定木で判定しています。
Q1: 連携先に公式 API は存在するか？
└ YES → 構造化 API を採用（45 倍の節約）
└ NO → Q2 へ
Q2: 連携先に MCP / Skill 実装はあるか？
└ YES → MCP 経由で構造化アクセス
└ NO → Q3 へ
Q3: Web スクレイピングで 80% カバーできるか？
└ YES → Playwright + パターンマッチで実装
└ NO → Q4 へ
Q4: 操作頻度 / 月 100 回以下か？
└ YES → Computer Use を許容
└ NO → 公式 API のリクエストを連携先と協議特に Q3 の「Playwright + パターンマッチ」は中間解として優秀で、Computer Use の 1/10 程度のコストで多くの業務シナリオをカバーできます。これは Playwright AI QA 自動化を受託に組み込む で扱ったテスト自動化と同じ手法を、業務操作に応用する発想です。
コスト試算のひな型
Computer Use を採用する案件では、月次コスト試算を契約締結前に必ず提示します。弊社で使っているシンプルな試算式を示します。
月次トークン消費 ≒ 操作回数 × 1 操作あたりスクショ数 × 1 スクショのトークン
+ 操作回数 × 1 操作あたり判断ステップ数 × 1 判断のトークン
例: 1 日 50 回操作 × 22 営業日 × 平均 6 スクショ × 1500 トークン
+ 1 日 50 回 × 22 営業日 × 4 ステップ × 800 トークン
≒ 990 万トークン + 35 万トークン
≒ 1025 万トークンこれに Sonnet 4.6 / GPT-5.5 / Gemini 2.5 Pro あたりの単価を掛けると、月数万円 〜 数十万円のレンジに収まります。「予測可能なコスト構造を顧客に説明できる」ことが、Computer Use を受託で扱う最低条件です。
受託契約に書く「Computer Use 利用条項」
Computer Use を組み込む案件では、契約に以下の条項を明記します。
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 採用判定基準 | 決定木の各分岐の合意 | 構造化代替案の検討記録 |
| 月次コスト上限 | 試算式に基づく上限値 | 上限超過時の協議 |
| 連携先 API 申請 | 公式 API の取得を継続要求 | 申請進捗の共有 |
| モデル選択 | 利用モデルの列挙 | コスト感の納得 |
| 失敗時の課金 | スクリーンショット数失敗の負担按分 | 試行回数の上限 |
| ログ保持 | スクショ・判断ログの保管期間 | データ主権 |
特に **「失敗時の課金」を曖昧にすると、UI が変更された日に 試行回数が爆発して月予算を 1 日で食いつぶす事故が起きます。「同一操作の失敗 5 回でアラート、10 回で停止」**といった機械的な閾値を契約に含めます。
価格モデル — Computer Use 案件の受託パッケージ
Computer Use を含む受託パッケージは、以下のレンジで提供しています。
| プラン | 初期 / 月額 | 対象 | 内容 |
|---|---|---|---|
| CU Lite | 80 万円 / 12 万円〜 | 単発自動化 | 1 業務 + コスト試算 + ログ可視化 |
| CU Standard | 250 万円 / 35 万円〜 | 中小企業の業務自動化 | 3 〜 5 業務 + 監視ダッシュボード + 月次最適化 |
| CU Enterprise | 600 万円〜 / 80 万円〜 | 上場・複雑業務 | Standard + フェイルオーバー + RBAC + SLA |
特に CU Standard は 「Computer Use と Playwright を併用してコスト最適化」するレンジで、月 35 万円で複数業務を AI が自律実行する構成を実現できます。
ハマりやすい 5 つの落とし穴
最後に、Computer Use を受託で扱うときに踏みやすい落とし穴を共有します。
落とし穴 1: 「とりあえず Computer Use で」始める
「公式 API を調べる時間が惜しい」と Computer Use で開始すると、月次コストが想定の 5 〜 10 倍になります。初日に必ず公式 API / MCP / スクレイピングを順に検討します。
落とし穴 2: スクショ枚数の最適化を後回し
1 アクションあたりのスクショ枚数を 「とりあえず多めに」取る設定で運用すると、コストが線形に膨らみます。操作前後の差分が小さい場合はスクショ枚数を 1 枚に抑えるチューニングを必ず行います。
落とし穴 3: モデルを高性能のままで放置
Computer Use の判断ステップ全てに 最高性能モデルを使うと、判断 1 回あたり 800 〜 2000 トークンを消費します。ルーティン判断は安価なモデル、複雑判断のみ高性能モデルに振り分けます。
落とし穴 4: UI 変更検知を組み込まない
連携先サイトの UI が変わると、試行回数が爆発してコストが暴騰します。スクショの差分検知 + 失敗閾値で自動停止する仕組みを最初から組み込みます。
落とし穴 5: ログを残さず再現できない
「成功した結果だけを納品」する運用は、何が起きていたか後から検証できません。スクショ・判断ログ・コストを BigQuery 等に常時格納し、再現可能な状態にします。
まとめ — 「Computer Use を使うか」より「いつ使わないか」
Computer Use は強力ですが、構造化 API の 45 倍のコストを消費する選択肢です。受託として健全に提供するには、「いつ Computer Use を使わないか」の判定軸を最初に設計し、コスト試算と契約条項に落とし込むことが必須です。
弊社では CU Lite / Standard / Enterprise の 3 段階で Computer Use を組み込んだ受託パッケージを提供しています。「業務自動化に Computer Use を使いたいがコストが読めない」「既に Computer Use を入れたが月次コストが想定外」というご相談は お問い合わせフォーム からお気軽にどうぞ。
