概要
https://zenn.dev/ncdc/articles/c1d65b6e939185
詳細内容
## APIをそのままMCPサーバーにするな
https://zenn.dev/ncdc/articles/c1d65b6e939185
既存APIをMCP（Model Context Protocol）サーバーへ単純移行することで生じるコスト増大と精度低下を指摘し、AIに最適化されたインターフェース設計の重要性を説く。
**Content Type**: Technical Reference
**Language**: ja
**Scores**: Signal:5/5 | Depth:4/5 | Unique:4/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 89/100 | **Annex Potential**: 82/100 | **Overall**: 88/100
**Topics**: [[MCP, AIエージェント, トークン最適化, API設計, LLMコスト]]
Model Context Protocol（MCP）の普及に伴い、既存のAPIをそのままMCPサーバーとして公開する例が増えているが、著者はこれに強い警鐘を鳴らしている。その最大の理由は、人間向けに設計されたAPIとAIエージェントが求めるインターフェースには「レイヤーの違い」があり、安易な統合は実害を招くからである。具体的には「AIのコスト増大」と「応答精度の悪化」という、実運用において無視できない2つの問題が挙げられている。
まず、エンドポイントの多さが問題となる。人間向けのAPIは細かい操作ごとに分かれているが、これをそのままツール化すると、AIはリクエストのたびに全てのツール定義を読み込む必要があり、読み込み文字数（トークン数）に比例してコストが跳ね上がる。また、選択肢が多すぎることでAIが適切なツールを選べなくなるリスクも指摘されている。著者は、関連する操作を統合した高レベルなツールへの再設計や、必要最小限の機能への絞り込みを推奨している。
次に、説明文の冗長性だ。網羅性を重視したAPI仕様書をそのままツールの説明文に転用すると、1ツールで数百から数千トークンを消費することになる。著者はAIが判断に必要な情報だけに絞り、説明文を200文字以下に抑えるべきだと主張している。さらに、レスポンスの巨大さも深刻な問題だ。不要なフィールドや大量のメタデータを含むレスポンスは、そのままコンテキストを圧迫し、会話が続くほどコストが雪だるま式に増大していく。必要な情報のみを抽出し、大きなデータは要約やページングを行う工夫が不可欠である。
記事ではサーバー側の設計指針に加え、既存の「綺麗ではないMCPサーバー」を扱うクライアント側の対策として、ツールの定義をキャッシュ（Prompt Caching）する方法や、セマンティック検索を用いた動的なツール選択、レスポンスの機械的な要約についても言及している。
筆者の主張の根幹は、「APIは人間向け、MCPはAI向け」という明確な使い分けにある。開発者はAPIをただラップするのではなく、AIにとって使いやすく、かつ経済的な「AIネイティブなインターフェース」を意識して構築すべきである。これは、AIツールの実運用フェーズにおけるコスト管理と信頼性確保に直結する、エンジニアが今まさに意識すべきプラクティスと言える。