DEV Community

Cover image for コンピューター利用 vs 構造化API：それぞれの強み (2026年)
Akira
Akira

Posted on • Originally published at apidog.com

コンピューター利用 vs 構造化API：それぞれの強み (2026年)

LLM のコンピュータ利用モデルでブラウザを操作すると、同じベンダーを構造化 API 経由で呼び出す場合よりも約 45 倍高くつくことがあります。

今すぐ Apidog を試す

このガイドでは、その 45 倍という差がどこから生まれるのか、コンピュータ利用を選ぶべき場面、そして Apidog で構造化 API とブラウザ操作の両方を低コストに設計・検証する方法を整理します。対象は OpenAI Operator、Anthropic の computer use、browser-use、Skyvern、その他スクリーンショットループを使うエージェント全般です。

AI エージェント向けに API を作成する場合は、agents.md ファイルの書き方も確認してください。構造化 API パスを呼び出し元にとって自然なデフォルトにできます。

要約

  • コンピュータ利用: LLM がスクリーンショットを見て、クリック、キー入力、スクロールを指示する方式。
  • 構造化 API: LLM が JSON ツール呼び出しを生成し、バックエンドで実行する方式。
  • 同じタスクでも、コンピュータ利用は各ステップでスクリーンショットを送るため、30〜50 倍多くのトークンを消費しやすい。
  • API が存在しない、API がレート制限されている、認証や UI 制約でスクリプト化が難しい場合のみ、コンピュータ利用を検討する。
  • 支払い、検索、CRM 更新、社内ツールなど OpenAPI で表現できる処理は、構造化 API を優先する。
  • 現実的にはハイブリッドが多い。90% は構造化 API、残りのロングテールをコンピュータ利用で処理する。
  • Apidog を使うと、JSON ツールスキーマの設計、エンドポイントのモック、エージェントフローの再生を行いやすい。

なぜコスト差が大きいのか

45 倍という差は特殊なベンチマークではなく、トークン消費の構造から自然に発生します。

構造化 API 呼び出しでは、通常は次の流れになります。

  1. ユーザー要求とツールスキーマをモデルに渡す
  2. モデルが JSON オブジェクトを返す
  3. ランタイムが HTTP/API 呼び出しを実行する

この場合、入力は数百トークン、出力は数十トークン程度で済みます。ネットワークホップも基本的に 1 回です。

一方、コンピュータ利用ループでは次の処理を繰り返します。

  1. プロンプトとスクリーンショットを送る
  2. モデルがクリック座標や入力内容を返す
  3. ブラウザで実行する
  4. 次のスクリーンショットを撮る
  5. もう一度モデルに送る

「フライトを予約する」のようなタスクでは、このラウンドが 12〜30 回発生することがあります。各スクリーンショットは通常解像度でも約 1,500 トークンを消費します。ここに誤クリック、スクロールの行き過ぎ、クッキーバナーの処理などが加わります。

Anthropic のコンピュータ利用に関するドキュメントでも、スクリーンショットのトークンコストが説明されています。HN の「Computer Use is 45x more expensive than structured APIs」でも、一般的なペナルティは 30〜50 倍とされています。これは Apidog で同じタスクを両方のパスで再生したときに観測される傾向とも一致します。

構造化 API を選ぶべきケース

次の条件に当てはまる場合は、構造化 API をデフォルトにしてください。

1. OpenAPI / GraphQL / REST ドキュメントが存在する

ベンダーが OpenAPI スペック、GraphQL スキーマ、または REST API ドキュメントを公開しているなら、まず API を使います。

JSON 形式が存在すれば、LLM はそこに必要な値を埋められます。GPT-5.5、Claude 4.5、DeepSeek V4 のようなモデルでは、文書化されたエンドポイントに対するツール呼び出し精度は高く、失敗しても検出とリトライが安価です。

2. タスクが 1〜2 個のエンドポイントで完結する

以下のような処理は、ブラウザを開く必要がありません。

  • Stripe 顧客を作成する
  • HubSpot の取引ステージを更新する
  • Slack にメッセージを投稿する
  • CI ジョブを再実行する
  • 請求書一覧を取得する

これらをブラウザ操作で実行するのは、API があるのに UI を遠回りする設計です。

3. 非監視で実行する

Cron、Webhook、キューワーカーなどは、エージェントが誤ってスクロールしたりクリックしたりする様子を人間が監視できません。

構造化 API はネットワーク層で実行されるため、失敗時のステータスコード、エラー本文、リトライ条件を明確に扱えます。

4. レイテンシが重要

構造化 API 呼び出しは、多くの場合 200〜800ms 程度で返ります。

一方、15 ラウンドのコンピュータ利用ループは 30〜90 秒かかることがあります。リトライが入るとさらに遅くなります。ユーザーが待っているフローでは、ほぼ常に API が有利です。

5. 出荷前にテストしたい

Apidog なら、JSON エンドポイントをすぐにモックできます。エージェントの実行前に、API レスポンスとスキーマを検証できます。

ブラウザのスクリーンショットループを同じ精度でモックするのは、はるかに難しい作業です。

コンピュータ利用が役立つケース

コンピュータ利用は高価ですが、使うべき場面はあります。

レガシーベンダーポータル

一部の調達、貨物、福利厚生ポータルは REST API を持っていません。機械向けインターフェースがなく、古い ASP.NET セッションの背後にある場合もあります。

このようなケースでは、四半期ごとに壊れる Selenium スクリプトの代替として、コンピュータ利用が妥当な選択になることがあります。45 倍の実行コストよりも、メンテナンスコスト削減の価値が大きい場合です。

変更できない社内ツール

以下のような環境では、API 化が現実的でないことがあります。

  • 2014 年に導入された CRM
  • レガシー ERP
  • 古い SharePoint ダッシュボード
  • クライアント管理下の業務システム

統合を追加できず、iPaaS の導入もできない場合、スクリーンショットループは現実的な逃げ道になります。

単発のオペレータータスク

「競合 50 社を調査して、要点を Notion に貼り付ける」のような 1 回限りの作業では、構造化 API を設計する方が高くつく場合があります。

この場合、コンピュータ利用で一度だけ処理し、その後は捨てる設計が合理的です。

ToS に反するスクレイピングは避ける

「コンピュータ利用でこのサイトをスクレイピングする」という要求の多くは、ベンダーの利用規約に違反する可能性があります。この場合、コストは最小の問題です。

意思決定フレームワーク

コンピュータ利用を選ぶ前に、次の 4 つを確認してください。

チェック はいの場合 いいえの場合
文書化された API はありますか？ API を使う 次へ
プライベートエンドポイントをラップする軽量なサーバーサイドアダプターを作れますか？ アダプターを作り、JSON として公開する 次へ
タスクは単発、または低頻度ですか？（1 日 100 回未満など） コンピュータ利用を検討する 次へ
毎回 30〜50 倍のトークンコストを支払えますか？ コンピュータ利用 API アクセスを交渉する

実務では、多くのワークフローが 1 または 2 で構造化 API にできます。コンピュータ利用は、そこから漏れたものだけに使います。

エージェントで構造化 API を呼び出す例

「昨日の失敗した支払いを取得する」タスクを、構造化ツール呼び出しとして表現します。

import json
from openai import OpenAI

client = OpenAI()

tools = [{
    "type": "function",
    "function": {
        "name": "list_failed_payments",
        "description": "List failed payments in a date range",
        "parameters": {
            "type": "object",
            "properties": {
                "start": {"type": "string", "format": "date"},
                "end": {"type": "string", "format": "date"},
            },
            "required": ["start", "end"],
        },
    },
}]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "user", "content": "Show yesterday's failed payments."}
    ],
    tools=tools,
    tool_choice="auto",
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"],
    },
    limit=100,
)
Enter fullscreen mode Exit fullscreen mode

この設計では、エージェントはダッシュボードを見ません。

実行フローは次の通りです。

  1. ユーザー要求を受け取る
  2. モデルが list_failed_payments の JSON 引数を生成する
  3. アプリケーションが Stripe API を呼び出す
  4. 結果をユーザーに返す

コンピュータ利用で同じことをすると、ブラウザ起動、Stripe ログイン、日付ピッカー操作、スクリーンショット取得、スクロール、ピクセルからの数値抽出が必要になります。12 ラウンド程度になることも珍しくありません。

Apidog で構造化パスを設計する

チームがコンピュータ利用に流れる理由は、コストを無視しているからではなく、エージェント向けのクリーンなツールサーフェスが存在しないからです。

Apidog を使うと、構造化 API パスを次の手順で設計できます。

ステップ 1: エージェントが必要とする操作をエンドポイント化する

まず、エージェントが実行する操作を API としてモデル化します。

例:

  • POST /invoices/list
  • POST /deals/update-stage
  • POST /messages/send
  • POST /payments/list-failed

少数のエンドポイントだけでも、オペレーター型デモの多くを置き換えられます。Apidog は設計ビューから OpenAPI 3.1 ドキュメントを生成できます。

ステップ 2: OpenAPI をエージェントフレームワークに渡す

生成した OpenAPI ドキュメントを、利用するエージェントフレームワークに渡します。

対応例:

  • OpenAI の tools 配列
  • Anthropic の tool use スキーマ
  • LangChain の OpenAPI ローダー
  • DeepSeek V4 のツール呼び出し形式

これにより、エージェントは自然言語ではなく、型付きの関数呼び出しとして操作を実行できます。

ステップ 3: モックサーバーを有効にする

Apidog のモックサーバーをオンにすると、各エンドポイントに対して現実的な JSON を返せます。

本番 API に接続する前に、次を検証できます。

  • エージェントが正しいツールを選ぶか
  • 必須パラメータを埋めるか
  • 型が合っているか
  • 想定レスポンスを処理できるか

同じパターンは、Apidog の契約優先開発ガイドでも説明されています。

ステップ 4: リクエストとレスポンスを再生する

Apidog でエージェント実行中のリクエストとレスポンスを記録すれば、成功した実行と失敗した実行を比較できます。

確認すべき点:

  • どのツール呼び出しがずれたか
  • パラメータが欠けていないか
  • スキーマ変更で破壊的変更が入っていないか
  • エージェントが不要にブラウザへフォールバックしていないか

「昨日は動いたのに今日は壊れた」という問題を、HTTP レベルで追跡できます。

ステップ 5: 公開・QA・監視に同じプロジェクトを使う

同じ Apidog プロジェクトを、次の用途に使えます。

  • 公開 API ドキュメント
  • QA 用のテストハーネス
  • モックサーバー
  • リクエスト履歴の確認
  • エージェント向けツールスキーマ管理

ハイブリッド構成にする

本番環境のエージェントは、多くの場合ハイブリッドになります。

基本方針は次の通りです。

  • 90% の操作は、設計済みの構造化ツールサーフェスを使う
  • 10% のレガシーポータルや例外処理だけ、コンピュータ利用にフォールバックする
  • ルータープロンプトで、操作ごとにパスを選ぶ

ルーターはシンプルで構いません。

If tool_name is in known_tools, call the structured tool.
Otherwise, pass the task to the browser agent.
Enter fullscreen mode Exit fullscreen mode

Claude 4.5 や GPT-5.5 は、この種のルーティングを安定して処理できます。DeepSeek V4 でも同様のパターンを使えます。リクエスト形式は DeepSeek V4 API の使用方法を参照してください。

監視では、2 つのパスを必ず分けて追跡します。

  • 構造化 API: ボリュームの大半、コストの少数派
  • コンピュータ利用: ボリュームの少数派、コストの大半

もしコンピュータ利用がボリュームでもコストでも増え続けているなら、新しい構造化エンドポイントを設計すべきサインです。

避けるべき一般的な間違い

スキーマを渡さない

散文だけのシステムプロンプトでエージェントを動かすと、構造化呼び出しは安定しません。

常に JSON Schema を渡してください。スキーマが厳密なほど、モデルは正しい引数を生成しやすくなります。

実行時にエージェントへスキーマを作らせる

スキーマはプロダクトのインターフェースです。

Apidog で作成し、バージョン管理し、通常の API 変更と同じように扱ってください。自己変更スキーマは、本番障害の原因になります。

トークンではなく総額だけを見る

コンピュータ利用のコストは、画像入力トークンに隠れます。多くのオブザーバビリティツールでは、画像入力の価格を正確に反映できない場合があります。

プロバイダーの請求コンソールで、実際の入力・出力・画像トークンを確認してください。

コンピュータ利用と RPA を混同する

RPA は、既知の DOM 要素や固定 UI に対してスクリプト化されたクリックを実行します。

コンピュータ利用は、スクリーンショットごとに「次に何をクリックするか」をモデルが再判断します。

  • RPA: 安価で繰り返し可能だが、UI 変更に弱い
  • コンピュータ利用: 柔軟だが高価で遅い

RPA で十分な場面では、コンピュータ利用を使う必要はありません。

レイテンシを軽視する

45 倍のトークン料金だけが問題ではありません。60 秒のスクリーンショットループは、ユーザー体験も悪化させます。

ユーザーが待つフローでは、API 化を優先してください。

代替案

ベンダーが公式 API を持たない場合でも、コンピュータ利用以外の選択肢があります。

Playwright / Puppeteer

ヘッドレスブラウザスクリプトは、実行時の LLM コストがかかりません。

ただし、UI 変更で壊れます。保守コストを見積もったうえで採用します。

Zapier / Make コネクタ

ベンダーが Zapier や Make のコネクタを公開している場合、iPaaS 側が統合の負担を引き受けています。

シート代を払う方が、独自統合やコンピュータ利用より早く出荷できる場合があります。

プライベート API のラップ

DevTools の Network タブを見ると、ベンダーダッシュボードが内部 JSON エンドポイントと通信していることがあります。

同じ認証クッキーで呼べる場合は、それを薄いサーバーサイドアダプターでラップし、Apidog で文書化します。半安定な API として扱い、変更検知とテストを用意してください。

この手法は、Postman なしでの API テストでも説明されています。

コンピュータ利用は、最初の選択肢ではなく最後の手段です。

実際の使用例

あるフィンテックコンプライアンスチームは、6 ステップのコンピュータ利用 Stripe レポートを、3 つの構造化 API 呼び出しに置き換えました。トークンコストは 92% 減少し、実行時間は 41 秒から 2 秒になりました。

ある B2B SaaS のサポートエージェントは、API がないベンダー調達ポータルだけにコンピュータ利用を残しました。その他の処理は、Apidog で設計した OpenAPI ツール呼び出しに移行しました。エージェントの総トークン費用は月額 4,200 ドルから 310 ドルに減少しました。

ある単独創業者は、レガシー ERP から Notion ダッシュボードを更新する処理に、週 1 回だけコンピュータ利用を使いました。週 1 回なら 45 倍の実行コストは数セントで、代替となる統合開発は数週間かかります。これはコンピュータ利用に向いたケースです。

結論

45 倍という差は現実的で、再現可能です。エージェント設計では、まず Apidog で構造化 API を設計し、API が存在せず、実行頻度が低く、トークンコストが許容範囲の場合だけコンピュータ利用を検討してください。

持ち帰るべきポイントは次の 5 つです。

  • コンピュータ利用は、同等の構造化 API 呼び出しより 30〜50 倍多くのトークンを消費しやすい。
  • 文書化されたエンドポイントと JSON Schema は、コスト、レイテンシ、信頼性でスクリーンショットループより有利。
  • ハイブリッド構成が現実的。90% を Apidog で設計し、残りのロングテールだけブラウザ操作にフォールバックする。
  • ライブモデルに接続する前に、構造化ツールサーフェスをモックする。
  • オブザーバビリティでは、構造化 API とコンピュータ利用を別々に追跡する。

次のステップとして、Apidog でエージェント用の API プロジェクトを作成し、モックサーバーを有効にしてください。コンピュータ利用で出荷しようとしていたワークフローが、2 つの構造化呼び出しに置き換えられるか、短時間で確認できます。

FAQ

コンピュータ利用が構造化 API より安くなることはありますか？

1 回あたりの実行では、通常は安くなりません。スクリーンショットのトークンが大きいためです。

ただし、API が存在しない低頻度ワークフローでは、統合開発コストの方が数年分の実行コストを上回る場合があります。その場合、総コストではコンピュータ利用が安くなることがあります。

エージェント用の JSON ツールサーフェスをモックするには？

Apidog でエンドポイントを設計し、組み込みのモックサーバーをオンにします。その後、エージェントのベース URL をモック URL に向けます。

これにより、本番接続や追加トークンコストなしで、現実的な JSON レスポンスを使ってフローを検証できます。詳しくは QA エンジニア向けの API テストツールを参照してください。

OpenAPI を任意のモデルのツール呼び出しに使えますか？

はい。OpenAI の tools パラメータ、Anthropic の tool_use ブロック、DeepSeek V4 のツール呼び出しエンドポイントはいずれも OpenAPI 3.1 スキーマを利用できます。

Apidog はスキーマをエクスポートできます。DeepSeek の形式は DeepSeek V4 API の使用方法で確認できます。

GPT-5.5 はコンピュータ利用をサポートしていますか？

OpenAI は Operator 製品と Responses API を通じてコンピュータ利用を提供しています。コスト構造は、スクリーンショットあたりの入力コストという点で Anthropic と近い傾向があります。

この記事の推奨事項は、特定ベンダーに依存しません。

Skyvern、browser-use、その他のオープンソースエージェントではどうですか？

計算は同じです。安価なオープンモデルを使うと 1 回あたりの価格は下がりますが、ラウンド数とスクリーンショットサイズは大きく変わりません。

API が存在する場所では、構造化 API が依然として有利です。

エージェントタスクに必要なエンドポイントがないことをどう検出しますか？

エージェントがどのツール呼び出しで失敗するか、またはブラウザにフォールバックしようとするかを確認します。

何度もブラウザへ逃げる場合、それはツールサーフェスに必要なエンドポイントがないサインです。Apidog でエンドポイントを追加し、スキーマを再生成すれば、エージェントは構造化 API パスを選びやすくなります。

Top comments (0)