この長文は分割して翻訳します。続けて翻訳してよろしいですか？
Scalekitのベンチマークは、GitHubのCopilotサーバーへのMCP呼び出しで28%の失敗率を記録しました。25回の実行中、7回がTCPレベルの接続タイムアウトで失敗しました。リモートサーバーが時間内に応答しませんでした。プロトコルエラーでも、ツール呼び出しの不具合でもありません。接続は完了しませんでした。
CLIエージェントにはこの障害モードはありません。バイナリはローカルで実行されます。タイムアウトするリモートサーバーも、枯渇させるコネクションプールも、中継点もありません。エージェントが apideck accounting invoices list を実行すると、Apideck APIへ直接HTTPSコールを行います。1ホップ、2ホップではありません。
スケール時にはこれが重要です。月間10,000件の操作で、28%の失敗率はおよそ2,800回のリトライを意味し、それぞれ追加のトークンと遅延を発生させます。Scalekitは月額コスト差を$3.20（CLI）対$55.20（直接MCP）と見積もり、17倍のコスト倍率と信頼性の課税を上乗せします。
リモートMCPサーバーは改善されるでしょう。コネクションプーリング、より良いインフラ、ゲートウェイ層が差を縮めます。しかし「バイナリがあなたのマシン上にある」という点は、サーバー側のインフラ設計のいかなる対策よりも信頼性の保証となります。
構造的安全性はプロンプトベースの安全性に勝る
システムプロンプトで「本番データを決して削除しない」とエージェントに伝えることは、核発射ボタンに付箋を貼るようなものです。うまく機能するかもしれません。多分。創造的なプロンプトインジェクションがその付箋を剥がすまでは。
CI/CDにおけるAIエージェントのセキュリティ研究は、プロンプトインジェクションが高権限トークンを持つエージェントを操作して秘密情報を漏らさせたりインフラを変更させたりできることを示しています。パターンは常に同じです：信頼できない入力がプロンプトに注入され、エージェントは広範なツールアクセスを持ち、悪いことが起こる。
Apideck CLIは構造的アプローチを採用しています。権限分類はHTTPメソッドに基づいてバイナリに組み込まれています：
// From internal/permission/engine.go
switch op.Permission {
case spec.PermissionRead:
return ActionAllow // GET → auto-approved
case spec.PermissionWrite:
return ActionPrompt // POST/PUT/PATCH → confirmation required
case spec.PermissionDangerous:
return ActionBlock // DELETE → blocked by default
}
No prompt can override this. A DELETE operation is blocked unless the caller explicitly passes --force. A POST requires --yes or interactive confirmation. GET operations run freely because they can't modify state.
The agent frameworks reinforce this. Claude Code, Cursor, and GitHub Copilot all have permission systems that gate shell command execution. So you get two layers of structural safety: the agent framework asks "should I run this command?" and the CLI itself enforces "is this operation allowed?"
You can also customize the policy per operation:
# ~/.apideck-cli/permissions.yaml
defaults:
read: allow
write: prompt
dangerous: block
overrides:
accounting.payments.create: block # payments are sensitive
crm.contacts.delete: prompt # contacts can be soft-deleted
This is the same principle behind Duda blocking destructive MCP actions, but enforced structurally in the binary, not through prompt instructions that compete with everything else in the context window.
構造的安全性はプロンプトベースの安全性に勝る
ユニバーサル互換性、ゼロプロトコルオーバーヘッド
MCPは、あなたのエージェントが他の人のユーザーを代表して行動する場合に有利です。 これは、CLI対MCPの比較で最も見過ごされがちな次元であり、率直に語る価値があります。あなたのエージェントが自分自身のワークフローを自動化する場合、環境資格情報で問題ありません。あなたがユーザーで、リスクを負う唯一の人はあなた自身です。 しかし、エージェントがあなたの顧客の従業員を代表して行動するB2B製品を構築している場合、顧客が管理する組織を横断して、アイデンティティの問題は三層になります：どのエージェントが呼び出しているか、どのユーザーがそれを承認したか、どのテナントのデータ境界が適用されるか。 スコープ付きアクセス、同意フロー、構造化された監査証跡を含むユーザーごとのOAuthは、その境界で実際の要件であり、生のCLI認証（gh auth login、環境変数）だけでは解決するように設計されていません。 MCPの認可モデルは、効率性コストがどうであれ、これをネイティブに解決します。
とはいえ、統合APIアーキテクチャにおけるギャップは見た目よりも狭いです。ApideckはすでにVaultを介して認証を集中管理しています: 認証情報は顧客ごと、接続ごと、サービスごとに管理され、サービスによってスコープが設定されます。 --service-id フラグは、特定の顧客の Vault 内の特定の統合を対象とします。構造的権限システムは、読み取り、書き込み、削除の境界をバイナリレベルで強制します。不足しているのは、ユーザーごとのOAuth同意フローとテナント単位の監査証跡です。実際にはギャップは存在しますが、それらはプラットフォーム層に位置しており、エージェントのインターフェース層にはありません。CLIがインターフェースとなり、バックエンドが委任認可を処理することも可能です。これらは互いに排他的ではありません。
注意すべき点として、MCPの認証ストーリーは見かけよりも落ち着いていません。SpeakeasyのMCP OAuthガイドが明確にしているように、ユーザー向けOAuth交換はMCP仕様で実際には必須ではありません。アクセストークンを直接渡すこともAPIキーを直接渡すことも完全に有効です。実際の複雑さは、MCPクライアントがOAuthフローを動的に処理する必要がある場合に生じます。これにはDynamic Client Registration (DCR) が必要ですが、今日多くのAPIプロバイダーはこの機能をサポートしていません。StripeやAsanaのような企業は、MCPに対応するためにDCRを導入し始めていますが、依然として高摩擦の統合です。CLIに対するMCPの認証の利点は理論上は確かですが、実際にはエコシステムがまだ仕様に追いついていません。
CLIsはストリーミングと双方向通信には弱い。 CLI呼び出しはリクエスト-レスポンスです。サーバー送信イベント、WebSocketストリーム、長寿命の接続が必要な場合は、接続を開いたままにできるSDKやMCPサーバーが望ましいです。
配布には摩擦があります。 MCPサーバーは理論上、URLの背後に配置できます。CLIsはプラットフォームごとにバイナリ、更新、PATH管理が必要です。Apideck CLIでは、依存関係なしでどこでも実行できる静的なGoバイナリを配布していますが、それでもインストールが必要なバイナリです。
正直な見解として、MCP、コード実行、CLIは補完的なツールです。多くの統合パターンでは、CLIはコンテキストオーバーヘッドを約100倍削減して機能します。
What this means for API providers
2026年に開発者ツールを構築している場合、AIエージェントはAPI表面の主要な消費者の1つになりつつあります。人間の開発者も依然として重要ですが、急速に増えています。
検討すべき点がいくつかあります：
OpenAPI仕様がコンテキストウィンドウには大きすぎる。 エンドポイントが50以上ある場合、仕様をMCPツールへ変換すると、ほとんどのエージェント対話のコストを消費してしまいます。最小限のエントリポイントがどのような形になるかを考えてください。
段階的公開は、もはやUXパターンだけではありません。 それはトークン最適化戦略です。すべてを一度に公開するのではなく、エージェントが機能を段階的に発見できる方法を提供してください。
構造的安全性は交渉の余地がありません。 プロンプトベースのガードレールは、名誉規範の駐車制度に相当するセキュリティです。ツールに権限モデルを組み込み、プロンプトには依存しません。操作をリスクレベルで分類し、その分類をコードで強制してください。
機械向け出力フォーマットを提供してください。 対話型でない文脈ではデフォルトでJSONを出力します。安定した終了コード。決定論的な出力。これらはAgentic CLI Design: 7つの原則で文書化されたエージェント・CLI設計の原則であり、次のパワーユーザーが手を使えないかもしれないため重要です。
参考資料
- MCPとAPI - MCPとREST APIの関係（Apideckブログ）
- エージェント時代のAPI設計原則 - AIエージェントをファーストクラスの消費者としてAPIを設計
- MCPのセキュリティ動向を理解する - MCPセキュリティの深掘り
- MCP Context Tax - MCPトークンオーバーヘッドの詳細分析
- Agentic CLI Design: 7 Principles - エージェントインターフェースとしてのCLI設計原則
- MCP vs CLI Benchmark - Scalekit's head-to-head benchmark data（75回の実行、Claude Sonnet 4）
- Code Mode: the better way to use MCP
