Column

LLMに業務ツールを「全部つなぐ」と何が起きるか——MCPサーバーの5パターンとツール数爆発の罠

15のMCPサーバーを横断分析した研究が、アーキテクチャパターンを5種類に体系化した。ツール数が閾値を超えるとClaudeの選択精度が顕著に低下するという定量的知見は、エンタープライズAI設計の常識を書き換えるかもしれない。

2026 / 06 / 30 5 分で読める English version →

複数のビジネスシステムがMCPサーバーを経由してLLMに接続される構成図のフラットイラスト

こんにちは。Affectosphere Group の井下です。

「全部つないでしまえ」という発想、あなたの組織にもないでしょうか。

ERPも、CRMも、社内の文書管理システムも、コミュニケーションツールも——LLMにつながれば、自然言語だけで全部の業務が完結するんじゃないか。そのビジョンに向けて動き始めた企業は、今まさに壁にぶつかっています。

どんな壁かというと「接続の仕方がわからない」という壁です。MCP（Model Context Protocol）というAnthropicが策定したプロトコルがあれば、LLMと外部ツールを標準的な方法でつなぐことができます。でも、「どういう構造で実装すればいいか」という設計の知見が、まだ整理されていなかった。

2026年6月にarXivで公開された研究（Rodrigues & Vas, arXiv:2606.30317）が、その整理に取り組みました。独立して開発された15のMCPサーバーを横断的に分析し、5つのアーキテクチャパターンを抽出・体系化したものです。

実装者の経験値に頼るのではなく、現実の実装を観察して帰納的に導いた分類です。そしてその過程で見えてきた「ツール数が増えすぎると何が起きるか」という知見が、特に示唆に富んでいます。

今日伝えたいこと

MCPサーバーの実装パターンは5種類に分類でき、それぞれ適切なユースケースと設計上の注意点がある
ツール数が一定の閾値を超えると、Claudeモデルのツール選択精度が顕著に低下することが定量的に示された
認証・オブザーバビリティといった横断的関心事の設計が、本番運用の安定性を左右する

① 5つのパターンとは何か

研究が抽出した5つのアーキテクチャパターンは、以下の通りです。

Resource Gateway（リソースゲートウェイ）は、データや文書へのアクセスを仲介する役割です。ファイルシステム、データベース、クラウドストレージといった「情報の源泉」をLLMに接続する際に使われます。

Tool Orchestrator（ツールオーケストレーター）は、複数のツールを組み合わせた複雑なワークフローを制御します。単一のリクエストに対して複数のアクションを順番に実行するような場面で登場します。

Stateful Session Server（ステートフルセッションサーバー）は、セッション状態を保持します。ブラウザ操作の自動化や、複数ステップにわたる対話を維持する必要があるユースケースに対応します。

Proxy Aggregator（プロキシアグリゲーター）は、複数の下位MCPサーバーをまとめて一つのインターフェースとして提供します。組織内に複数のMCPサーバーが乱立した際に、統合管理の窓口として機能します。

Domain-Specific Adapter（ドメイン特化アダプター）は、特定の業務領域に最適化した変換層です。ERPのAPIやCRMのデータ構造をLLMが扱いやすい形に変換します。

② なぜパターン分類が必要なのか

「とりあえず全部のAPIをツールとして登録すればいい」と考えてしまいがちです。でも実際の実装では、それが大きな問題を引き起こします。

この研究で最も注目すべき知見の一つが、ツール数と精度の関係です。ツール数が一定の閾値を超えると、Claudeモデルが適切なツールを選択する精度が顕著に低下することが定量的に示されました。

これは直感的に考えれば納得できます。人間でも「このボタンを押せばいいですか？それともこっちですか？あっちですか？」と20個の選択肢を並べられると、判断が鈍くなります。LLMも同様で、選択肢が多すぎると意図していないツールを呼び出す確率が上がる。

だからこそパターン分類が重要になります。Proxy Aggregatorを使えば、内部の多数のツールを束ねつつ、LLMに見せるインターフェースを絞ることができます。Domain-Specific Adapterを使えば、業務領域ごとにツールセットを分割して、一度に提示するツール数を制御できます。

③ アンチパターンという視点

研究は5つのパターンに加えて、各パターンに付随するアンチパターンも整理しています。

アンチパターンとは「実装者がやりがちだが、後で問題になる設計」のことです。

よくあるアンチパターンの一例として挙げられるのが、ツールの粒度が荒すぎる問題です。「何でもできる多機能ツール」を一つ作るより、単機能の小さなツールを複数用意する方が、LLMの意図理解精度が上がります。しかし今度はツール数が増えすぎるという前述の問題に直面する。この二律背反をどうバランスするかが設計の肝です。

認証の一貫性のなさも問題になります。複数のツールがそれぞれ異なる認証方式を持っていると、エラーハンドリングが複雑になります。MCPサーバー層で認証を統一することで、ツール側の実装をシンプルに保てます。

④ 横断的関心事——認証とオブザーバビリティ

研究が特に重視しているのが、個別パターンを超えた「横断的関心事」の設計です。

認証については、MCPサーバー層で統一的に扱うアーキテクチャが推奨されます。各ツールが個別に認証情報を管理するモデルは、スケールしません。

オブザーバビリティ（観測可能性）は、本番運用で特に重要になります。「どのツールが呼び出されたか」「レスポンスタイムはどうだったか」「エラーはどこで発生したか」が追跡できないと、問題発生時のデバッグが困難になります。

LLMを使ったシステムは、従来のソフトウェアと違って動作が確率的です。同じ入力でも違うツールが選ばれることがある。だからこそ、観測ログを充実させて「何が起きているか」を把握できる設計が不可欠です。

⑤ エンタープライズ実装への応用提案

この研究の知見を、実際の企業内システム構築に当てはめてみます。

想定するのは、SaaSプロダクトを複数運用する中堅規模のIT企業です。ERP、CRM、プロジェクト管理ツール、ドキュメント管理の4システムをLLMエージェントに接続する場面を考えます。

まず各システムとの接続にはDomain-Specific Adapterを選択します。ERPのビジネスロジックはCRMとは全く異なるため、それぞれの業務語彙をLLMが扱いやすいツール定義に変換する層を個別に設計します。

その上に、Proxy Aggregatorを一枚噛ませます。LLMに見せるツールセットをここで絞ります。「ERPの在庫確認」「CRMの顧客検索」「ドキュメント検索」など、ユースケースとして想定される操作を中心に、提示ツール数を制御する設計です。

KPIとしては、ツール選択の精度率（意図したツールが呼ばれた率）と、タスク完了率の二軸を設定することを推奨します。ツール数を変えたときにこれらがどう変化するかを週次でモニタリングし、最適なツールセット構成を継続的に調整します。

まとめ——「つなぎ方」に設計思想を持つ時代

LLMと業務ツールを接続するMCPの普及とともに、「どう接続するか」の設計知見が急速に重要になっています。

この研究が示すのは、接続は単なる技術的作業ではなく、アーキテクチャ選択を伴う設計活動だということです。5つのパターンを状況に応じて使い分け、ツール数の上限を意識し、横断的関心事を適切に扱う。そうした設計判断の積み重ねが、LLMエージェントの実用的な精度を左右します。

「とりあえず全部つなぐ」から「意図的に設計してつなぐ」へ。その転換を促す研究だと思います。

では！

参考論文

Rodrigues, Carson, & Vas, Oysturn. (2026). MCP Server Architecture Patterns for LLM-Integrated Applications. arXiv preprint (2026).

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。