MCP設計時の落とし穴を解説！既存のAPI、そのままMCP化してませんか？
本記事はCDataが提供する「CData Blog」に掲載された「MCP設計時の落とし穴を解説！既存のAPI、そのままMCP化してませんか？」を再編集したものです。
翻訳者ノート
こんにちは！コンテンツチームの加藤です。
MCPサーバーを設計する際には「既存のAPIエンドポイントをそのままツールとして公開すればいい」と考えてしまいがちですが、それがAIエージェントの判断精度を下げる原因になることをご存知でしょうか。本記事では、「APIをMCPとしてそのまま公開」が引き起こすコンテキストウィンドウ圧迫問題と、スコープ化された設計によってエージェントのパフォーマンスを高める具体的な方法を解説します。MCPサーバーの設計・運用に携わるエンジニアや、AIエージェントの精度向上を目指す方にとって、すぐに実践できる指針になるのではと思います。
MCPサーバーの初期設計で陥りやすい失敗のひとつは、ある意味で自然な発想から生まれます。チームが既存のAPIを持っていて、エージェントにそれを使わせたい場合、最初に思いつく方法は各エンドポイントをMCPツールとしてラップすることです。OpenAPI仕様からマニフェストを生成してSDKに処理を任せれば、半日あれば動くサーバーができあがります。問題が表面化するのは、そのMCPを実際のエージェントに接続し、さらに2〜3個のMCPと組み合わせる段階です。単純なツール1本だったころと比べて、エージェントの判断精度が大きく下がり始めます。
本記事では、APIをそのまま活用したMCPサーバーがエージェントのパフォーマンスを低下させる仕組み、適切にスコープ化されたツール設計の考え方、既存の構成を見直す際の診断手順を順を追って説明します。最後に、CData Connect AIのWorkspaceとToolkitがこれらの原則をどのように実装しているかも紹介します。
MCPツールはコンテキストウィンドウにどう影響するのか？
MCPサーバーの仕組み自体はシンプルです。エージェントがMCPサーバーに接続すると、サーバーはすべてのツールマニフェスト（ツール名・説明・パラメータスキーマ）を公開します。このマニフェストは、エージェントが最初のユーザーメッセージを処理する前にLLMのコンテキストウィンドウに注入されます。モデルは初回接続時だけでなく、毎回のリクエストでこの内容をすべて読み込みます。マニフェストが「毎ターンの固定オーバーヘッド」になる理由はここにあります。
トークン消費はすぐに積み上がります。ツール1個あたり名前・説明・パラメータスキーマを含めると通常200〜600トークンかかります。MCPサーバーが5台あり各30ツールを持てば、150ツールがコンテキストに入ります。その時点でツールのメタデータだけで、200,000トークンのコンテキストウィンドウの25〜30%を消費します。ユーザーのメッセージも、タスクの履歴も、取得データも、まだ何も入っていない段階でです。
主要なAIクライアントの制限値も、この問題を反映しています。CursorはMCPツールを40個に制限し、GitHub Copilotは128個でハードリミットを設けています。いずれもその閾値を超えるとパフォーマンスが測定可能な形で低下するという実測データに基づいた数値です。タスクに関連する情報ではなくツールの定義に費やされるコンテキストウィンドウの割合は、いわば「コンテキスト税」であり、ツールを追加するたびに線形に増加します。
なぜ「APIをそのままMCPに活用すること」が問題なのか？
開発者がAPIエンドポイントを直接ツールにマッピングしてMCPサーバーを構築すると、APIの構造とその冗長さがそのままLLMのコンテキストに持ち込まれます。40のRESTエンドポイントを持つCRMは、そのまま40のMCPツールになります。細粒度のCRUD操作はさらに問題を大きくします。create_account、update_account、delete_account、get_account、search_accountという5つのツールは、適切に設計されたサーバーなら1つにまとめられる操作です。RESTクライアントには合理的だったインターフェースが、まったく異なる特性を持つ推論モデルにそのまま適用されてしまいます。
この問題が起きる理由は構造的です。OpenAPI仕様やSDKラッパーから自動生成されたMCPサーバーは、最も手間のかからない実装を選びます。エンドポイント1つにつきツール1つという方針です。素早くデリバリでき、保守も簡単で、データソースが1つのエージェントならちゃんと動いているように見えることさえあります。乖離が表面化するのは、複数のデータソースを組み合わせた段階です。Salesforce、Jira、Snowflakeをそれぞれ別のAPIをそのまま使ったサーバー経由で参照するエージェントは、タスク固有のコンテキストが読み込まれる前の時点で、100〜200個のツールを抱えることになります。推論リソースの大半が「100個以上あるツールのどれが今の状況に当てはまるか」の評価に費やされることになります。
APIアーキテクチャの領域で普及しつつある「エクスペリエンスAPI」という考え方が、ここでは参考になります。MCPツールは、細粒度の複数操作をひとつの能力型インターフェースの背後に収める形で設計すべきです。基盤となるAPIメソッドの名称を反映するのではなく、エージェントがやろうとしていることを表す設計が求められます。APIをそのままツールとして公開するのではなく、接続目的に合わせて整形する実例については、ジョブカン経費精算のAPIをドライバー化した事例が、設計の考え方を理解する上で参考になります。
ツールの増加がエージェント精度を下げる理由
悪影響はトークン消費にとどまりません。LLMはコンテキストウィンドウ内のすべての内容にアテンションを分散させるため、ツールセットが大きくなるほど、モデルの注意が多くの選択肢に分散します。その結果、誤ったツールを選択したり、ハルシネーションしたパラメータでツールを呼び出したり、ツールの出力を誤解したりする確率が高まります。スコープが不適切なツールがわずかな数であっても、ツール呼び出しの精度は測定可能な形で低下します。
実務上、この問題は3つの失敗パターンとして現れます。1つ目は「ツール選択の誤り」です。タスクで必要なget_accountではなく、似た名前のget_contactを選んでしまうケースが典型例です。2つ目は「パラメータの誤り」です。多数のツールにまたがるパラメータスキーマが混濁し、もっともらしいが誤った値を必須パラメータに埋めてしまいます。3つ目は「コンテキストの置き換え」です。ツールの定義によって重要な情報がコンテキストから押し出され、エージェントがユーザーの本来の要求の文脈を見失います。
見落とされがちなコスト面の問題もあります。コンテキストに注入されたツールの説明は、セッション内の毎回のリクエストにトークンを追加します。ツールの公開は1回限りのオーバーヘッドではなく、繰り返し発生する推論コストになるわけです。Amazon Prime Videoのエンジニアリングチームは、数百の選択肢からコンテキストに適した3〜4個のツールに絞り込んだ後、エージェントの精度が測定可能な形で向上し、ハルシネーションも明確に減少したと公表しています。
適切に設計されたMCPツールとはどういうものか？
核心的な原則は一文にまとめられます。MCPサーバーが公開すべきものは「APIエンドポイント」ではなく「ケイパビリティ（能力）」です。設計の出発点も変わります。「このAPIコールは何をするか？」ではなく「エージェントが達成すべきタスクは何か？」という問いから始める。この視点の転換が、ツールの設計と数の両方を変えます。
適切にスコープ化されたMCPツールには3つの特性があります。1つ目は「タスク指向」であること。基盤となるAPIメソッドの名称ではなく、エージェントがやろうとしていることを表した名前を付けます。2つ目は「広い適用性」を持つこと。複数のオブジェクトや要素にまたがって機能し、ツールの総数を少なく保ちます。3つ目は「ユースケースへのスコープ化」です。公開するツールセットをデータソースシステムの全機能ではなく、エージェントのワークフローに合わせて絞り込みます。
ユースケースへのスコープ化は、多くのチームで最も改善効果が大きい部分です。カスタマーサクセス向けのエージェントにはアカウント・チケット・契約データが必要であり、財務向けエージェントには総勘定元帳・請求書・予算データが必要です。この2つが同一の肥大化したサーバーを共有する必然性はありません。各エージェントは、そのタスクに合わせてスコープ化されたサーバーに接続すべきです。実務では1エージェントあたりのアクティブなツール数を10〜15個以下に抑えることが推奨されています。スコープを設計上の制約として最初から組み込んでおくと、この閾値は自然と守りやすくなります。
既存のMCPサーバー設計を監査する方法は？
まずツールのインベントリを作成することをお勧めします。各エージェントに公開されているすべてのツールをリストアップし、合計数を確認してトークンオーバーヘッドの概算を出します。1エージェントあたりのツール数が15〜20個を超えていれば、そのサーバーは再設計の候補です。これはハードルールではありませんが、設計がエージェントのワークフローではなくAPIサーフェスをミラーリングしているという強いシグナルになります。
次に、4つの問いで設計の問題を特定できます。第一に、get_account・get_contact・get_leadのように、異なるオブジェクトに対する同一操作が別々のツールになっていないか。第二に、現在のワークフローで実際には使われていないツールが公開されていないか。第三に、ツールの名前がタスクの語彙ではなくAPIの語彙で表現されていないか。第四に、エージェントが実際にはクエリしないデータソースへのアクセスが含まれていないか。いずれかに当てはまる場合、そのツールはコストを払いながら何も貢献していないコンテキストです。
アーキテクチャ上の修正は、データソースシステム単位ではなくユースケース単位でグループ化することです。すべてのエージェントにSalesforceの全機能を公開する汎用の「Salesforce MCPサーバー」を作るのではなく、パイプラインレビューに必要なオブジェクトだけを持つ「パイプライン管理サーバー」と、CSワークフローに必要なオブジェクトだけを持つ「カスタマーヘルスサーバー」を別々に構築します。パフォーマンス上のメリットは明確ですが、ガバナンス上のメリットも無視できません。スコープ化されたサーバーはエージェントレベルで最小権限アクセスを強制するため、エージェントが誤動作した場合の影響範囲を限定できます。
Connect AIが実装するスコープ化の仕組み
CData Connect AIはこのアーキテクチャを前提に設計されています。データソースごとにエンドポイント単位のMCPツールを生成する代わりに、Connect AIはすべての接続済みデータソースに対して均一に機能する固定のユニバーサルツールセットを公開します。getCatalogs、getSchemas、getTables、getColumns、queryData、getProcedures、executeProcedureの7つです。あるデータソースでユニバーサルツールの使い方を習得したエージェントは、別のデータソースに対しても同じ方法でやり取りできます。下位に何百ものシステムが接続されていても、ツールのサーフェスは7個のまま変わりません。
データアクセスのスコープ化はWorkspaceが担います。管理者はWorkspaceを、業務機能ごとに整理されたデータカタログとして定義します。特定のテーブル・ビュー・派生ビューをまとめたものです。「カスタマーサクセス」という名前のWorkspaceには、CSエージェントが必要とするSalesforceのアカウントテーブル、Zendeskのチケットビュー、契約データだけが含まれます。Workspaceは最小権限データアクセスの単位として一度定義すれば、同じスコープを必要とするエージェントで再利用できます。
利用可能なツールの制御はToolkitが担います。読み取り専用のレポートエージェントにはgetSchemas・getTables・getColumns・queryDataを持つToolkitを割り当て、書き込み操作が必要な運用エージェントには追加ツールを重ねます。各Workspace + Toolkitの組み合わせは、専用のMCPサーバーエンドポイントとして自動的にデプロイされます。追加のインフラ構築は必要ありません。
この結果、管理者は用途に合わせて設計されたMCPサーバーをデプロイできます。各サーバーは最小限のツールサーフェス、スコープ化されたデータアクセス、専用エンドポイントを持ち、接続先のエージェントに合わせた構成になっています。コンテキストはコンパクトに保たれ、接続レイヤーは個別サーバーが乱立することなく単一のマネージドプラットフォームとして管理されます。
Connect AIでスコープ化されたMCPサーバーを構築する
CData Connect AIのWorkspaceとToolkitを使うと、数百の業務システムを対象に、エージェントの用途に合わせたMCPサーバーを構築できます。各サーバーは専用エンドポイントとしてデプロイされ、エージェントが実際に必要とするツールとデータアクセスだけを提供します。CData Connect AIの無償トライアルを開始すると、チームで利用するエージェントの接続レイヤーをスコープ化された構成で試せます。
本記事はアフィリエイトプログラムによる収益を得ている場合があります