MCP を通じて既存の API を LLM に公開する方法:包括的ガイド

大規模言語モデル(LLM)と既存の API を統合することは難しい場合があります。従来は、AI があなたのサービスにアクセスできるようにするためには、カスタムコネクタやプラットフォーム固有のプラグインが必要でした。Model Context Protocol(MCP) はより良い方法を提供します。
モデルコンテキストプロトコル(MCP)とは何か?
MCP は Anthropic が開発したオープンスタンダード(現在はオープンソースプロジェクト)で、AI アシスタントが外部データやツールに接続する方法を標準化します。MCP は ユニバーサルアダプター、つまり「AI アプリケーション用の USB-C ポート」 と考えてください。各モデルやプラットフォームごとに一回限りの統合を構築する代わりに、MCP を通じて API を一度公開すれば、MCP 対応の LLM ならどれでもそれを使用できます。
MCP の主な利点
- 標準化:断片化した統合を単一の一貫したプロトコルに置き換える
- 再利用性:API コネクタを MCP サーバーとして一度構築すれば、複数の AI クライアントがそれを活用できる
- 制御:MCP サーバーはあなたの環境で実行されるため、セキュリティを強制し、モデルがアクセスできる内容を正確に管理できる
MCP は LLM 向けのユニバーサルプラグインシステムとして機能し、AI が外部ソースから関数を呼び出したりデータを取得したりするための構造化された方法を提供します。
MCP プリミティブを理解する
MCP は機能を公開するために 3 つの主要な概念を使用します:
- リソース:これらは読み取り専用のデータエンドポイントのようなものです。リソースは URI(例:
todo://list
)で識別され、モデルにデータを提供します。リソースはモデルにコンテキストをロードするためのもの(ドキュメント、データベースレコード、タスクのリストなどの取得)です。これらは GET リクエストに似ており、通常は状態を変更しません。 - ツール:これらはモデルが呼び出すことができるアクションや操作です—本質的にはパラメータと戻り値を持つ関数で、LLM が呼び出せるものです。ツールは副作用を持ったり計算を実行したりできます。ツールは「AI が呼び出せる関数」のようなものと考えてください。
- プロンプト:MCP は再利用可能な会話テンプレートやワークフローの定義を可能にします。プロンプトはサーバーがクライアントに提供できる、あらかじめ定義された会話スニペットのようなものです。
要約すると:リソースはモデルのデータをロードし、ツールはアクションを実行し、プロンプトは対話をガイドします。
実装:ステップバイステップガイド
MCP を使用して単純な REST API を AI アシスタントに公開する方法を見ていきましょう。
ステップ 1:単純な REST API の例をセットアップする
例として基本的な To-Do リスト API を使用します。Flask を使用した最小限の実装は次のとおりです:
from flask import Flask, request, jsonify
app = Flask(__name__)
tasks = [ {"id": 1, "title": "Sample Task", "done": False} ]
@app.route('/tasks', methods=['GET'])
def get_tasks():
# Return the full list of tasks
return jsonify(tasks)
@app.route('/tasks', methods=['POST'])
def create_task():
# Add a new task from the JSON request body
data = request.get_json()
new_task = {
"id": len(tasks) + 1,
"title": data.get("title"),
"done": False
}
tasks.append(new_task)
return jsonify(new_task), 201
# Run with: flask run
この API には 2 つのエンドポイントがあります:
GET /tasks
- すべてのタスクを取得POST /tasks
- 新しいタスクを追加
実際のシナリオでは、これはデータベースバックエンドを持つ既存の API かもしれません。
ステップ 2:API をラップする MCP サーバーを作成する
次に、To-Do API を LLM に公開する MCP サーバーを Python で作成します:
まず、MCP パッケージをインストールします:
pip install "mcp[cli]"
次に、todo_mcp_server.py
というファイルを作成します:
from mcp.server.fastmcp import FastMCP
import requests # we'll use requests to call our REST API
# Initialize an MCP server with a descriptive name
mcp = FastMCP("To-Do API MCP Server")
# Define a Resource for reading tasks (like a GET endpoint)
@mcp.resource("todo://list")
def list_tasks() -> list:
"""Fetch all to-do tasks from the API."""
response = requests.get("http://localhost:5000/tasks")
response.raise_for_status()
return response.json() # return the list of tasks
# Define a Tool for adding a new task (like a POST operation)
@mcp.tool()
def add_task(title: str) -> dict:
"""Add a new task via the API and return the created task."""
payload = {"title": title}
response = requests.post("http://localhost:5000/tasks", json=payload)
response.raise_for_status()
return response.json() # return the new task data
if __name__ == "__main__":
mcp.run(transport="stdio")
何が起きているのか分解してみましょう:
"To-Do API MCP Server"
という名前のFastMCP
インスタンスを作成し、サーバーをセットアップしてツール/リソースを登録します。@mcp.resource("todo://list")
を使用して、タスクのリストを返すリソースを公開します。これは API の GET エンドポイントにマッピングされます。@mcp.tool()
を使用して、新しいタスクを追加するツールを公開します。これは API の POST エンドポイントにマッピングされます。- 各関数のドキュメント文字列は重要です - LLM はツールの使用方法を決定する際にこれらの説明を参照します。
mcp.run(transport="stdio")
でサーバーを実行し、標準入出力を使用して通信します(ローカル開発に適しています)。
この時点で、2 つの機能を持つ MCP サーバーができました:リソース todo://list
(タスクを取得するため)とツール add_task
(タスクを作成するため)です。これらは API の機能に対応しています。実質的に、REST API を MCP でラップしました。
ステップ 3:MCP サーバーをローカルで実行してテストする
MCP サーバーを実行する前に、Flask API が実行されていることを確認してください(例:flask run
で)。
次に、開発モードで MCP サーバーを起動します:
mcp dev ./todo_mcp_server.py
mcp dev
コマンドはブラウザでインタラクティブな開発ダッシュボードを起動します。このダッシュボードでは以下のことができます:
- MCP サーバーの名前と利用可能なツール/リソースを確認する
todo://list
リソースをテストする - 現在のタスクリストを返すはずですadd_task
ツールをテストする - タスクのタイトルを入力して実行する- 結果を確認し、履歴パネルでログを確認する
このダッシュボードは開発とデバッグに非常に役立ちます。実際の LLM クライアントが使用するのと同じ MCP プロトコルを使用していますが、テスト用の GUI があります。
ステップ 4:MCP サーバーを LLM クライアントに接続する
次に、MCP サーバーを実際の LLM に接続しましょう。いくつかの AI アシスタントとツールが MCP をサポートしています:
Claude デスクトップとの接続
Anthropic の Claude Desktop アプリケーションにはローカル MCP サーバーのサポートが組み込まれています。統合するには:
mcp install ./todo_mcp_server.py
これによりサーバーが Claude に登録されます。Claude のインターフェースで、「To-Do API MCP Server」が利用可能になっているはずです。これで Claude との会話で以下のことができます:
- 「To-Do タスクを一覧表示して」と尋ねる - Claude は
todo://list
リソースを使用します - 「牛乳を買うという To-Do 項目を追加して」とリクエストする - Claude は
add_task
ツールを使用します
Claude は MCP サーバーの実行とリクエストのルーティングを AI が使用すると判断したときに処理します。
Cursor IDE との接続
Cursor は MCP をサポートする AI アシスタントを備えたコードエディタです。接続するには:
- Cursor の「Model Context Protocol」設定に移動します
todo_mcp_server.py
へのパスを提供して MCP サーバーを追加します- トランスポート(stdIo)を指定します
接続すると、Cursor はサーバーのツールとリソースを検出します。その後、「To-Do リストにどんなタスクがある?」や「‘ブログ記事を書く’をタスクに追加して」などの質問を Cursor アシスタントに尋ねることができます。
LLM クライアントに関する一般的な注意事項
正確な接続手順はクライアントによって異なります:
- Claude Desktop の場合、
mcp install
またはアプリの UI を使用します - Cursor の場合、設定でサーバーを構成します
- 他の環境では異なるアプローチがあるかもしれません
接続後、AI にツールの使用を促すようなプロンプトを与えてテストします。多くの MCP クライアントは AI がツールを使用するときに視覚的に表示します。
セキュリティに関する注意:MCP サーバーを接続すると、LLM はそのサーバーが公開するものにアクセスできるようになります。MCP サーバーは通常、ローカルまたはあなたのインフラストラクチャ内で実行されるため、セキュリティ上は良いことです。API が認証を必要とする場合は、MCP サーバーコードにそれらの認証情報を含めることができます。
MCP と従来のアプローチの比較
MCP を使用して API を公開する方法が、他の統合方法とどのように異なるかを比較してみましょう:
直接的な LLM API 呼び出し(MCP なし)
MCP がなければ、以下のようになるかもしれません:
- プラットフォーム固有の関数呼び出しやプラグインを使用する(OpenAI や特定の環境に依存)
- API の詳細をプロンプトに埋め込む方法は誤りが生じやすい - モデルがエンドポイントを誤って生成したり、不正確なフォーマットを送信したりする可能性がある
GraphQL やその他のクエリ言語
GraphQL では、LLM にクエリを構築させることができますが:
- モデルはスキーマとクエリ構文を知る必要がある
- モデルのクエリを検証するためのカスタム統合レイヤーが必要になる可能性が高い
MCP の利点
MCP を使用すると、これらの詳細が標準化されたインターフェースに抽象化されます:
- LLM は HTTP メソッドやクエリ構文を知る必要がない
- 人間が読みやすい名前と説明を持つ利用可能なツールとリソースについて MCP サーバーに問い合わせる
- プロセスは低レベルの呼び出しではなく機能に焦点を当てる
- 同じ MCP サーバーがプロトコルをサポートするどのクライアントでも機能する
詳細な比較は次のとおりです:
側面 従来の API 統合 MCP 統合の使用 標準化 統一された標準がない - 各プラットフォームには独自の統合方法またはプラグイン形式がある プラットフォーム間で一つのオープンスタンダード - 一度構築すれば、どこでも使用可能 アクションの発見 LLM には利用可能なエンドポイント/クエリが何かを伝える必要がある、またはハードコードされている LLM クライアントは MCP サーバーから利用可能なツール/リソースをプログラムで一覧表示できる データアクセス API レスポンスはしばしばプロンプトを介して送信され、コンテキスト制限に達する MCP リソースはデータを管理された方法で直接 LLM のコンテキストにロードする コーディング労力 高い - 各モデルに対してカスタム HTTP 呼び出し、解析、エラー処理が必要 簡素化 - MCP SDK がプロトコルの詳細を処理し、Python 関数を書くだけ セキュリティと制御 制約がなければ、モデルは任意の HTTP 呼び出しを生成する可能性がある MCP サーバーはゲートキーパーとして機能 - 公開する内容を正確に決定できる 柔軟性 新しい LLM やユースケースに適応するのが難しい 非常に柔軟 - モデルは複数の MCP 呼び出しをオーケストレーションでき、新しいツールを簡単に追加できる
簡単に言えば、MCP は API の上に AI フレンドリーなレイヤーを提供します。生の HTTP 呼び出しを扱う代わりに、モデルは会話の中で意味をなす名前付きのアクションとデータとやり取りします。
結論
MCP を通じて既存の REST API を LLM に公開することで、統合を大幅に簡素化できます。各 AI プラットフォーム向けに一回限りの接続を作成する代わりに、Model Context Protocol を一度実装すれば、サポートするクライアントとの互換性が得られます。
MCP は AI とデータを橋渡しするための標準化された、安全で柔軟な方法を提供します。API を任意の高度な AI が責任を持って知的に使用できるモジュラーコンポーネントに変えます。これにより新たな可能性が開かれます:LLM を活用したアシスタントが、同じ統一されたフレームワーク内で、あなたの API と他の MCP コネクタを組み合わせることができます。
よくある質問
はい。MCP は非常に柔軟です – アクセスするためのコードを書くことができれば、どんな API や外部サービスもラップできます。API が JSON、XML、その他の形式を返す場合でも、Python で処理して Python のデータ型を返すことができます(MCP が LLM 用にシリアライズします)。
LLM 自体は本質的に MCP を「話す」わけではありません – モデルと MCP クライアントの組み合わせがこれを可能にします。2025年現在、Claude、Cursor、Zed、Replitなどが MCP クライアントを統合しています。完全な UI クライアントなしで LLM と MCP サーバー間の対話をスクリプト化したい場合は、公式の Python クライアントライブラリもあります。
これらは同様の目標 – AI が外部 API を呼び出せるようにすること – に対応していますが、MCP はオープンスタンダードであり、異なる AI システム間で機能します。ChatGPT プラグインは OpenAI の ChatGPT インターフェースに固有のものであり、GPT-4 の関数呼び出しは OpenAI の API に特化しています。1つの MCP サーバーが多くの異なるモデル/クライアントに対応できます。
MCP はまだ比較的新しいですが、急速に成熟しています。セキュリティに関しては:MCP は AI がコードを実行したりデータを取得したりすることを可能にするため、MCP サーバーを API と同じ注意で扱ってください。必要なものだけを公開してください。AI は定義したツールのみを呼び出すことができ、それ以外は呼び出せません。MCP の利点の一つは、サーバーをファイアウォール内またはローカルで実行できるため、露出が減ることです。
Python が現在最も成熟した SDK を持っていますが、MCP は言語に依存しません。プロトコル自体(通常は stdio や SSE 上の JSON-RPC を使用)は任意の言語で実装できます。C# や JavaScript など、他の言語でも SDK や例があります。
もちろんです。MCP サーバーは、異なるシステムに関連していても、複数のツールとリソースを公開できます。To-Do API、天気 API、ローカルデータベースファイル用のリソースを持つ単一の MCP サーバーを作成することができます。あるいは、複数の MCP サーバー(サービスごとに 1 つ)を実行し、それらをすべてクライアントに接続することもできます。