ツールアーキテクチャ
MCP、CLI、API はすべてインターフェースであり、万能な勝者はない
重要なのは新しさではありません。どこで実行するか、誰が発見するか、データをどう検証するか、どの運用コストを受け入れるかで選びます。
CLI: 運びやすく観察しやすい
ターミナル、スクリプト、CI では CLI が自然です。ローカル filesystem を直接扱え、普遍的なツールでデバッグできます。課題は人向け出力が不規則だと利用側が再解釈しなければならない点です。
qzx diagnoseProject . --jsonAPI: 明確なネットワーク境界
能力が既にサービスとして存在し、認証を中央化し、多数のリモートクライアントから使うなら API が適しています。その代わりネットワーク、可用性、資格情報、サーバー運用が加わります。
MCP: AI クライアント向けの発見と契約
MCP は対応クライアントがツールや schema を発見する共通方式を提供します。各サーバー専用の統合を減らしたい場合に特に有効です。
ロジックを複製しない
同じ操作を CLI と MCP の両方で提供するなら、処理本体を輸送方式から独立させます。テストと意味を共有し、各アダプターは自分の UI とプロトコルだけを担当できます。
よくある質問
最も簡単な方式はどれですか？
環境によります。ターミナルでは CLI、サービス間では API、対応クライアントでのツール発見では MCP が自然です。
三つを組み合わせてもよいですか？
はい。中核処理を一つに保ち、複数のアダプターから公開すれば、ビジネスロジックの重複を避けられます。
構造化された結果が重要なのはなぜですか？
成功、エラー、データ、次の処理をソフトウェアやエージェントが曖昧さなく判断しやすくなるからです。