数字は嘘をつかない:ツール呼び出し30%削減、トークン25%削減

一般的なユーザー作業において、MCPとCLI + SKILLを比較しました。その結果、ツール呼び出し回数の削減、トークンの無駄の減少、エラー回復の向上が見られ、その理由はデータが示しています。

Oliver Kingsley

Oliver Kingsley

6 7月 2026

数字は嘘をつかない:ツール呼び出し30%削減、トークン25%削減

Apidog エンタープライズ

オンプレミスデプロイ

SSO & RBAC

SOC 2 準拠

Apidog Enterpriseを見る

ApidogがAPIテストおよびAPIライフサイクル管理用のコマンドラインツールであるApidog CLIをどのように開発したかについて、全10回の連載でお届けします。順番に読むことも、興味のある投稿に直接飛ぶこともできます:

タイトル 焦点
1 126個のMCPツールを構築しましたが、それはAgentにとって最善のソリューションではありませんでした 問題の発見
2 なぜ私たちは全く新しいApidog CLIを開発したのか アーキテクチャ開発
3 黄金律:CLIは事実を生み出し、モデルは事実に従って行動する 核となる哲学
4 agentHints:CLIにAgentとの対話を教える 構造化された出力
5 SKILL:運用経験をコードとして出荷する 運用経験
6 数字は嘘をつかない:ツール呼び出し30%減、トークン25%減 定量的な結果
7 PRDからテストループまで:Apidog CLIを使った完全なAgentワークフロー 実用的なチュートリアル
8 AgentツールにとってCI/CD互換性が不可欠である理由 DevOpsの視点
9 AIブランチ:AIエージェントによるより安全なプロジェクト変更 セキュリティ層
10 Spec-Firstは昨日。Skill-Firstへようこそ。 ビジョンと未来

私たちは、一般的なユーザー作業において、MCPとCLI + SKILLを比較しました。結果として、ツール呼び出しの回数が減り、トークンの無駄が減り、エラー回復が改善されました。その理由をデータが説明しています。

重要な問い

これまで共有してきたすべての哲学と設計原則は、実際に機能するのでしょうか?

私たちは内部で、両方のアプローチにわたって多くの一般的なユーザー作業を比較しました:

タスクタイプ 説明
テストケースの追加 + 検証 エンドポイントのテストケースを作成し、テストを実行
テストシナリオの保守 複雑な複数ステップのシナリオを更新
プロジェクトアセットのインポート/検証 データをインポートし、構造を確認し、テストを実行

結果は単なる主観的な改善ではありませんでした。それは**測定可能な削減**でした。


タスク1:エンドポイントに基づいたテストケースの追加

ユーザー要求:

「このエンドポイントのテストを追加し、検証を実行してください」

MCPルート

ステージ 何が起こるか
ツール発見 Agentがツールリストを検索
ツール選択 正しいツールを選択するために複数回試行
フィールド発見 Agentがツールスキーマを読み取る
フィールド推測 Agentが必須フィールドを推測
書き込み試行 Agentが作成ツールを呼び出す
エラー応答 サーバーが拒否(フィールドが間違っている/必須が不足している)
再試行 Agentが調整し、再試行
さらに再試行 成功するまで繰り返す
テスト実行 Agentが実行ツールを見つけ、実行

一般的なパターン:

ツール検索 → ツール選択 → スキーマ読み込み → フィールド推測 → 書き込み → エラー → 再試行 → 書き込み → エラー → 再試行 → 成功 → 実行ツール検索 → 実行

CLI + SKILLルート

ステージ 何が起こるか
SKILLガイド SKILLがタスクタイプを識別し、ワークフローを提供
エンドポイントの読み込み CLIがエンドポイントの事実を読み取る
テストケースの生成 Agentが実際のエンドポイントデータに基づいて生成
ローカルで検証 書き込み前にcli-schemaが検証
書き込み CLIがテストケースを作成
読み戻し CLIが作成された構造 + agentHintsを返す
テスト実行 agentHintsが実行を提案し、Agentがそれに従う

一般的なパターン:

SKILLがガイド → エンドポイント読み込み → 生成 → 検証 → 書き込み → 読み戻し → 実行

結果

指標 MCPルート CLI + SKILL 改善
ツール呼び出しステップ数 約15-20 約10-12 ↓ 約30%
記述からのトークン数 約50,000ロード 約2,000ロード ↓ 約96%
再試行からのトークン数 約5,000+無駄 約500無駄 ↓ 約90%
合計トークン無駄 約55,000 約2,500 ↓ 約25%

ツール呼び出しステップは約30%減少しました。無効なツール記述とエラー再試行によるトークン消費は約25%減少しました。


タスク2:構造化書き込み(プロセッサー、アサーション、エクストラクター)

ユーザー要求:

「このテストケースに、事後操作のアサーションと変数抽出を追加してください」

MCPルート

ステージ 何が起こるか
フィールド名の推測 Agentは正確な名前を知らない
enum値の推測 Agentが比較演算子、型を推測
書き込み試行 サーバーが間違った値を拒否
ネットワーク再試行 各エラーに対して往復
複数回の試行 3-5回の再試行が一般的

一般的なエラー:

間違った推測 正しい値 再試行回数
comparator: "contains" comparator: "include" 1-2
type: "global" type: "globals" 1-2
subject: "responseBody" subject: "responseJson" 1-2

各エラーは、1回のネットワーク往復 + 応答 + Agent処理を意味します。

CLI + SKILLルート

ステージ 何が起こるか
テストケースの読み込み CLIが実際の構造を取得
追加項目の生成 Agentが実際のフォーマットに基づいて生成
ローカルで検証 cli-schemaがネットワーク前にエラーを捕捉
ローカルで修正 Agentが検証出力に基づいて調整
再検証 修正を確認
書き込み 有効な書き込みのみがサーバーに送られる

すべてのエラーはローカルで捕捉されます。フィールドエラーによるネットワーク再試行はありません。

結果

指標 MCPルート CLI + SKILL 改善
構造エラーによるネットワーク再試行回数 3-5 0 ↓ 約100%
エラー応答からのトークン数 約2,000 約0 ↓ 約100%
合計反復呼び出し回数 約5 約1 ↓ 約40%

構造エラーによる繰り返しの呼び出しは約40%減少しました。


タスク3:作成後の連続操作

ユーザー要求:

「これらのエンドポイントを使ってテストシナリオを作成してください」

MCPルート

ステージ 何が起こるか
シナリオ作成 Agentが作成ツールを呼び出す
成功応答 Agentが「作成済み」と認識
書き込み継続 Agentがすぐに更新/追加を続ける
読み戻しをスキップ Agentが実際の構造を読み取らない
仮定に基づいて書き込み Agentが推測されたID/構造で書き込む
エラーまたは不完全 結果が期待と一致しない

問題:実行慣性。

モデルは成功後すぐに続行する傾向があり、読み戻しステップをスキップします。

CLI + SKILLルート

ステージ 何が起こるか
シナリオ作成 CLIがシナリオを作成
成功 + agentHints CLIが成功 + 次のステップの提案を返す
agentHints:「まず読み戻しを」 Agentが提案を見る
提案に従う Agentが読み戻しを行う
実際の構造で作業 Agentが正確なデータで処理を進める

agentHintsは明示的に読み戻しを提案します。Agentはそれに従います。

結果

指標 MCPルート CLI + SKILL 改善
継続前に読み戻しを行った割合 約20% 約85% ↑ 約425%
直接ジャンプによるエラー再試行回数 約3-5 約0-1 ↓ 約21%

Agentが積極的に読み戻し、検証し、検証を実行する割合が大幅に増加しました。次のステップに直接ジャンプすることによるエラー再試行は約21%減少しました。


要約:削減の源泉

削減の源泉 説明
ツール発見 CLIコマンドには明確な名前があり、SKILLが選択をガイド
スキーマ検証 ローカル検証により、ネットワーク呼び出し前にエラーを捕捉
エラー回復 agentHintsは「失敗」だけでなく、実行可能な提案を提供
読み戻しガイダンス 仮定に基づく書き込みを防止
ワークフローシーケンス SKILLが意思決定ポイントを削減

真のコスト分析

重要な洞察:

製品のAgent有効化は、ツールが多ければ多いほど良いというものではない。

モデルが実際に消費するもの:

コストタイプ MCPの負担 CLI + SKILLの負担
コンテキスト ツール記述、スキーマ タスクに焦点を絞ったSKILLのみ
注意 多くのツールの中から選択 ガイドされたワークフローに従う
パス選択 シーケンスの推測 SKILLによって定義されたシーケンス
ユーザーのトークンコスト 再試行、失敗した呼び出し 検証済み書き込み、少ない呼び出し

ツール数が増加した後、モデルが本当に消費するのはAPI呼び出し機能ではなく、コンテキスト、注意、パス選択、およびユーザーのトークンコスト間のトレードオフです。


エンジニアリングの原則

目標:

これらのコストをモデルのコンテキストから取り除き、エンジニアリングシステムが負担できる位置に戻すこと。
コスト MCPでの場所 CLI + SKILLでの場所
ツール発見 モデルが検索する必要がある SKILLが提供
フィールド検証 モデルが知る必要がある cli-schemaが検証
次のステップのガイダンス モデルが決定する必要がある agentHintsが提案
製品のセマンティクス モデルが理解する必要がある CLIが処理

エンジニアリングシステムが複雑さを吸収します。モデルは生成と判断に集中します。


これらの数字が意味するもの

これらの数字は、より具体的な問題を説明しています:

洞察 含意
ツール呼び出しが30%減少 複雑さが発見からガイダンスへ移行
無駄なトークンが25%減少 ネットワーク前にエラーを捕捉
構造的再試行が40%減少 検証ゲートが機能している
ジャンプエラーが21%減少 agentHintsが盲目的な継続を防止

CLI + SKILLは単なるアーキテクチャの優雅さではありません。それは測定可能な効率です。


次は何でしょう

数値でアプローチが検証されたので、実際に動作を見てみましょう。

パート7、PRDからテストループまで:完全なAgentワークフローでは、実際の例を見ていきます。あるチームが「注文払い戻し」のPRDを持っており、AgentがCLI + SKILLを使用してOpenAPIを生成し、テストを作成し、検証します。


重要なポイント


Apidogをダウンロードして、一つのワークスペースでAPIの設計モックテストドキュメント化を行いましょう。 コマンドラインAPIテスト、CI自動化、AI Agentワークフローに関するApidog CLIの詳細についてはこちらをご覧ください。

button

ApidogでAPIデザイン中心のアプローチを取る

APIの開発と利用をよりシンプルなことにする方法を発見できる