【ITニュース解説】What I Learned Building Multiple MCP Servers for Local LLMs (Qwen3-8B): Tool Granularity, Latency Traps, and Dogfooding

筆者は最近、ローカル環境で大規模言語モデル（LLM）であるQwen3-8Bと、カスタムのModel Context Protocol（MCP）サーバーを組み合わせてデータ分析スタックを構築している。このシステムは、180以上の正規化された日本の政府・企業データセットをLLMでクエリし、分析することを目的としている。当初、あらゆる機能に対応するMCPツール（ウェブスクレイピング、株価、気候データなど）を多数作成しようと考えたが、ローカルの8Bモデルで複数のMCPサーバーを動かした結果、クラウドの高性能モデルでは気づきにくい現実的なボトルネックに直面した。

まず、一つ目の大きな課題は「隠れたトークン税」であった。多くのMCPサーバーを有効にすると、ローカルLLMの速度が著しく低下することが判明した。LLMにメッセージを送るたびに、有効なすべてのMCPツールの機能定義がJSONスキーマ形式でシステムプロンプトに挿入される。例えば、一つあたりのツール定義が約150～300トークンであるため、4～5つのツールを有効にするだけで約1,000トークンが消費される。これが35～40のツールとなると、会話が始まる前から8,000～10,000トークン以上が毎ターン消費されることになる。16kのコンテキストウィンドウを持つ8Bのローカルモデルでは、これはコンテキストウィンドウの半分を占め、最初のトークンが出力されるまでの時間（Time-to-First-Token, TTFT）が大幅に劣化する。さらに、8Bモデルが約15個以上のツールを同時に見ると、ツール選択の精度が落ち、不必要なツール呼び出しを繰り返すようになるため、8Bのローカルモデルでは、同時にアクティブにするツールの総数を5～10個以下に抑えるのが経験則として推奨される。

次に、ツールの「粒度」に関する最適な設計原則が見出された。ツールの数を減らす必要があるからといって、すべての機能を一つの巨大なツールに詰め込むのが常に良いわけではない。 ツールを一つに「マージすべき」なのは、PythonのバックエンドコードがLLMの中間的な推論を必要とせずに、ワークフロー全体を端から端まで実行できる場合である。例えば、相関発見ツールを設計する際、最初は複数のツールに分けていたが、これでは8Bモデルが複雑なSQLクエリを書き、頻繁に失敗した。これらをインメモリのDuckDBとPythonエンジンを搭載した「discover_correlations」という一つの統一されたツールに統合することで、LLMはSQLエラーを起こすことなく、相関の解釈に集中できるようになり、非常に高速に処理できるようになった。 逆に、ツールを複数に「分割すべき」なのは、LLMが次のステップに進むために前のステップで得られた正確な情報（例えば、正確なカラム名）が必須となる場合である。例えば、データカタログサーバーでは、「データセットを一覧表示する」「データセットのカラム名と型を検査する」「読み取り専用SQLを実行する」というように、4つの異なるツールが提供されている。これは、LLMが「記述する」ツールで正確なカラム名を確認しない限り、「SQLを実行する」ツールで有効なSQLクエリを作成できないためである。統合すると、8Bモデルはスキーマの検査を飛ばして、テーブル名やカラム名を勝手に作り出す傾向がある。「リスト→記述→クエリ」と分割することで、モデルを正しい順序のワークフローに自然と導くガードレールとして機能する。

また、Qwen3-8Bのようなモデルでは、シーケンシャル思考を促すMCPが逆効果になることが分かった。シーケンシャル思考MCPは、小規模モデルの推論能力を向上させるために人気があるが、Qwen3-8Bは既に強力なネイティブの<think>...</think>推論ブロックを内蔵しているため、外部の思考ツールを追加すると「二重思考ループ」が発生する。これにより、レイテンシとトークン使用量は倍増するだけで、分析品質の向上には繋がらない。ネイティブな推論能力を持つモデルには、その能力をそのまま活用させ、MCPは外部データの取得や確定的な計算処理に厳しく限定すべきである。

公開するデータMCPサーバーには、セキュリティの強化が不可欠である。LLMは信頼できない呼び出し元として扱う必要がある。データベース接続は常にread_only=Trueで開き、SET enable_external_access=falseとSET lock_configuration=trueを設定して設定をロックすることで、SQLインジェクションや、LLMが勝手に作り出したクエリによるホストOS上のファイル読み書きを防ぐ。出力パスはPath.resolve().relative_to(base_dir)を用いて必ず検証し、ファイル削除機能は絶対に公開しない。外部からのテキストからは制御トークンを削除し、信頼できない文字列はタグで囲むことで、間接的なプロンプトインジェクションを防ぐ。さらに、Gitのコミット履歴にローカルOSのユーザー名、絶対パス、APIキーなどが含まれないよう、プリプッシュ正規表現チェックを実施する。

最後に、MCPサーバーを構築する中で意外な発見があった。当初、オープンソースのMCPサーバーを構築しても収益には繋がらないと考え、開発者ツールを磨き続ける「ツール構築の罠」に陥ることを懸念していた。しかし、実際にQwen3-8BをMCPサーバーに接続し、商用データセットに対して自然言語クエリや自動相関スキャンを実行したところ、LLMが自社のデータに構造的な欠陥があることをすぐに露呈させたのである。例えば、政府調達テーブルから上位の調達金額をランク付けするようLLMに依頼したところ、金額でソートできなかった。これは、データ取り込みパイプラインが誤って落札業者名、契約日、調達金額を一つのテキストカラムに連結してしまっていたためで、LLMは数値を抽出するために非常に複雑なSQLクエリを書く必要があった。自動テストではこのような使いやすさの欠陥は全く検出されなかったが、ローカル8BモデルをMCP経由で利用する「ドッグフーディング」（自社製品を自社で利用すること）が、データ品質を測る究極の試金石となることが判明した。8Bモデルが最初の試みでテーブルをきれいにクエリできないのであれば、人間のアナリストや有料APIの顧客も同様に使いたがらないだろうという結論に至った。これらの学びは、MCPサーバーの設計と開発において重要な指針となる。