AI統合のグルーコードを激減させるMCP活用術【4×9問題を実例で解説】

「AIエージェントを1つ追加するたびに、バックエンドとの繋ぎ込みコードを何本も書き直している…」そんな状況、心当たりありませんか？ 🤔

この記事では、MCP（Model Context Protocol）がグルーコードの組み合わせ爆発をどう根本解決するかに絞って深掘りします。MCPの概要や基本的な仕組みが気になる方はまず👇の記事をどうぞ。

MCP（Model Context Protocol）とは？AIが外部ツールと連携できる新標準をわかりやすく解説

本記事はその先、「既存システムへのMCP導入」と「フレームワーク横断での再利用」という実務視点に特化した内容です。

Contents

🔥 グルーコード問題の実態：4×9＝36本の地獄
💡 MCPでN×M→N＋Mへ：繋ぎ込み数の試算比較
🛠 既存バックエンドをMCPサーバー化する移行手順
- ステップ1：既存のビジネスロジックをそのまま関数化する
- ステップ2：MCPサーバーとしてラップして公開する
🔁 LangChain・LlamaIndex横断での再利用パターン
📌 まとめ：MCPでグルーコードから解放される

🔥 グルーコード問題の実態：4×9＝36本の地獄

AI integration architecture / Photo by Mikhail Nilov via Pexels

グルーコード（Glue Code）とは、異なるシステムを繋ぎ合わせるためだけに書かれたアダプターコードのことです。AI開発では次のような状況が頻繁に起きます。

AIエージェントが 4つ（分析Bot・要約Bot・通知Bot・レポートBot）
バックエンドAPIが 9つ（在庫・CRM・分析・通知・請求・認証・ログ・検索・レポート）
→ 理論上 4 × 9 = 36本の繋ぎ込みが必要 😱

さらに怖いのは、エージェントが5つ・6つと増えるたびに掛け算で膨らむ点です。バックエンドのAPI仕様が変わるたびに、関係するアダプターを全部直す羽目にもなります。

AIロードマップが行き詰まる原因は「モデルの質」ではなく、このN×M問題（組み合わせ爆発）であることが多いのです。

💡 MCPでN×M→N＋Mへ：繋ぎ込み数の試算比較

MCPを導入すると、構造が根本的に変わります。

✅ 各バックエンドを MCPサーバーとして1回だけ公開（9本）
✅ 各エージェントを MCPクライアントとして1回だけ実装（4本）
→ 合計 9 + 4 = 13本で済む！

36本 → 13本。エージェントやAPIが増えても、追加は「＋1」ずつになります。これがMCPが「USBポート方式」と呼ばれる理由です。

🛠 既存バックエンドをMCPサーバー化する移行手順

「既存のREST APIをMCPサーバーに変える」のは、思ったより手順がシンプルです。

ステップ1：既存のビジネスロジックをそのまま関数化する

既存のバックエンド処理をPython関数に切り出します。ここでロジックを書き直す必要はありません。

# 既存バックエンド（例：マーケティング分析API）
# 変更前：FlaskなどのREST APIエンドポイントだったもの

# 既存ロジック関数（ステップ1）
def get_campaign_metrics_logic(campaign_id: str) -> dict:
    """既存DBからキャンペーン指標を取得（ロジックはそのまま流用）"""
    # 実際の処理は既存コードをそのまま使う
    return {
        "campaign_id": campaign_id,
        "clicks": 1024,
        "conversions": 87,
        "cost": 45000
    }

# 既存ロジック関数（ステップ1）
def list_active_campaigns_logic() -> list:
    """アクティブなキャンペーン一覧を返す"""
    return [{"id": "camp_001", "name": "夏季セール"}, {"id": "camp_002", "name": "新商品PR"}]

ステップ2：MCPサーバーとしてラップして公開する

既存関数をMCPの@mcp.tool()デコレータでラップするだけです。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("marketing-analytics")

# 既存関数をそのままMCPツールとして登録
@mcp.tool()
def get_campaign_metrics(campaign_id: str) -> dict:
    """キャンペーンの指標を取得する"""
    # ステップ1の関数をそのまま呼び出すだけでOK
    return get_campaign_metrics_logic(campaign_id)

@mcp.tool()
def list_active_campaigns() -> list:
    """アクティブなキャンペーン一覧を返す"""
    return list_active_campaigns_logic()

# MCPプロトコルで自動公開
mcp.run()

ここが重要です 👇

エージェント側はツールの存在を自動的に発見（ディスカバリ）できる
新しいエージェントを追加しても、サーバー側のコードは変更不要
既存のREST APIと並行稼働させることも可能（段階的移行に便利）

実際にMCPサーバーを自作してみたい方はこちらのチュートリアルが参考になります 👇

MCPサーバーを30分で自作しよう！AIツールを自分で作る入門チュートリアル

🔁 LangChain・LlamaIndex横断での再利用パターン

MCPの最大の強みが「フレームワーク非依存」であることです。AnthropicがMCPをオープン仕様として公開したことで、主要なAIフレームワークが対応を進めています。

一度作ったMCPサーバーを複数フレームワークから使い回すイメージはこうなります。

# ── LangChainエージェントからMCPサーバーを使う例 ──
from langchain_mcp_adapters.client import MultiServerMCPClient
from langchain.agents import create_tool_calling_agent

# MCPサーバーに接続してツール一覧を自動取得
client = MultiServerMCPClient({
    "marketing": {"url": "http://localhost:8000/mcp", "transport": "streamable_http"}
})
tools = await client.get_tools()

# あとは通常のLangChainエージェントと同じ
agent = create_tool_calling_agent(llm=llm, tools=tools, prompt=prompt)

# ── LlamaIndexエージェントから同じMCPサーバーを使う例 ──
from llama_index.tools.mcp import BasicMCPClient, McpToolSpec
from llama_index.agent.openai import OpenAIAgent

# 同じサーバーURLを指定するだけで、ツールを再利用できる
mcp_client = BasicMCPClient("http://localhost:8000/mcp")
tool_spec = McpToolSpec(client=mcp_client)
tools = tool_spec.to_tool_list()

agent = OpenAIAgent.from_tools(tools, verbose=True)

ポイントをまとめると：