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を生成し、テストを作成し、検証します。
重要なポイント
- ツール呼び出しステップが約30%減少
- 記述と再試行によるトークンの無駄が約25%減少
- 構造エラーの再試行が約40%減少
- 読み戻しをスキップすることによるジャンプエラーが約21%減少
- 削減の源泉は、ガイド付き発見、ローカル検証、実行可能なヒントにある
- 複雑さがコンテキストからエンジニアリングシステムへ移行
Apidogをダウンロードして、一つのワークスペースでAPIの設計、モック、テスト、ドキュメント化を行いましょう。 コマンドラインAPIテスト、CI自動化、AI Agentワークフローに関するApidog CLIの詳細についてはこちらをご覧ください。
