MCPの概要

MCPの概要 2025/10/14 李 碩根

自己紹介 製造からSIer, ITコンサルから会社経営まで、AIをいろんな分野、業務に適応する業務を10年以上やってきました。今はAI エージェントでどうパフォーマンスを上げるかに興味を持っています。 李 碩根（イ サクン） ・韓国生まれ ・2010~2015 日本の製造業会社でシミュレーションを用いた生産性向上業務 担当 ・2015~2019 SierでIT全般とAIプロジェクトを担当 ・2019~2020 日本IBMでデータサイエンティストとしてAIプロジェクトを担当 ・2020~2023 AIを活用したインディーゲームを制作（現在廃業） ・2023~現在 東京大学松尾・岩澤研究室/株式会社松尾研究所でシニア データサイエンティストとしてAIプロジェクトを担当中 ・2025~現在 SozoWorks株式会社の創業

MCPの概要の説明 この資料は概念の説明にフォーカスされています。 実装のコード実装はMCPのHPをご参照ください

課題：標準なきツール利用 LLMによるツール利用が一般化する一方、統一された規格が存在しない課題がありました。 あるシステム 属人化、個別最適化、非効率性 システムに依存 するツール 異なる 使い方 LLM 同じツール の再開発 同じツール の再開発

解決策 バラバラな開発が問題なので、みんなが便利に使える共通規格を作ると解決できる！ ツール やり取り ツール LLM ツール LLMのプログラムがツールとやり取りする方法を統 一すれば問題解決！どうすれば良いか？

概念①：共通言語のJson-RPC 2.0 共通規格の最も基本になるのは共通言語。LLMのプログラムとツールが話す時はこの言語（Json-RPC）だけを使って！ これでみんなが同じ言語で話すようになりました。Json-RPCを使うことでシステムと独立したツール設計にもなる！ ツール Json-RPC ツール Json-RPC LLM ちなみに、Json-RPCはこんなもの { “jsonrpc”:2.0, “id”: 2, “method”: “tools/call”, “params”: {…} } ツール

概念②：共通ルールのライフサイクル 共通言語だけだとまだ足りない。どのようなルールで話すかを決める必要がある。共通言語が英語や日本語で、共通ルールがビ ジネスマナーのようなもの。最初は名刺交換し、お互いのどんな役割かを説明し、その後に協力ができる。それを決めるのがライ フサイクル ① 初期化 ツール ② メッセージ交換 ツール LLM ③ 終了 ツール

概念③：どのような要求ができるのか？MCPプリミティブ 共通言語とルールが設定されたら、実際にどのような内容を話していいかを決める必要があります。MCPではツールは「ツール、リ ソース、プロンプト」を提供可能にしていて、ユーザー側では「サンプリング、情報要求、ロギング」を提供可能に定義しています。 誰が？ 話せる内容 説明 ツール ツール AIアプリケーションが実行できる関数。（DB queries, API calls,…） リソース LLMに文脈を提供するために、サーバーがユーザーに公開するデータ。ファイ ルやDBスキーマ、アプリケーションの固有情報など。 プロンプト MCPサーバーを活用するために、LLMに提供すべきプロンプトのテンプレート。 サンプリング サーバー側からユーザー側にLLMによる補足や活用を要求する 情報要求 サーバーがユーザーに追加情報を要求。サーバー実行前に追加情報を要 求したり、承認を要求する時。 ロギング サーバーがデバッグや監視を目的として、クライアントにログメッセージを送信 ツール ユーザー ユーザー 何でもかんでも話せるわけではない。話せる内容が定義されている。

概念④：メッセージを送るには？トランスポート 共通言語が決まり、共通ルールが決まりました。では、実際にどうメッセージを送る？それを決めるのがトランスポート。MCPは stdioとStreamable httpが標準になっている { “jsonrpc”:2.0, “id”: 2, “method”: “tools/call”, “params”: {…} ツール } 例：request 運ぶ LLM ツール 例：response 運ぶ ツール { “jsonrpc”:2.0, “id”: 2, “result”: “…”, }

ここまでが概念。実装パートを簡略に見る 詳細は省略します

実装の前提：MCPのアーキテクチャー 概念を簡略に説明しました。これらを実装するためにMCPは「ホスト」「クライアント」「サーバー」の三つの要素で構成されていま す。 ホスト クライアント１ クライアント２ 1対1の対応 Json RPC利用 サーバー１ サーバー２ LLM クライアント３ クライアントがサーバーとの通信 チャンネルの管理、セッションの 管理を行う サーバー３

実装①：JsonRPC(共通言語)に対応する 概念①で共通言語としてJson-RPCを使うことを説明しました。実装では、ホストやサーバーの依頼をJson-RPCに変換する 役割をSessionクラスが担当しています。 ホスト クライアント１ サーバー１ クライアント２ サーバー２ クライアント３ サーバー３ LLM サーバーはServerSession。でもこれは internal用 ClientSessionにいろんなメソッドが容易 されていて、それを使うと簡単にJsonRPC に変換可能

実装②：共通ルールのライフサイクル 概念②でライフサイクルについて触れました。実際にライフサイクルはサーバー側のセッションで管理されています。セッションは Json-RPCへの交換だけではなく、ライフサイクルのState管理も行います。（でも内部処理用なので、分からなくていい？） ホスト クライアント１ サーバー１ クライアント２ サーバー２ クライアント３ サーバー３ LLM ライフサイクルの管理をサーバー側の Sessionで行う

実装③：MCPプリミティブ どんな内容が話せるかの定義、MCPプリミティブは、mcp/types.pyに定義されています。 class Tool(BaseMetadata): """Definition for a tool the client can call.""" description: str | None = None """A human-readable description of the tool.""" inputSchema: dict[str, Any] """A JSON Schema object defining the expected parameters for the tool.""" … このように、Pydanticモデルを使ってプリミティブを定義しています。

実装④：メッセージを送るには？トランスポート 概念③でトランスポート層について触れました。実際の実装では、クライアント側のstdio, streamable httpが Active/initiator, サーバー側がstdio, streamable httpを使ってPassive/Listenerを担当する機能が容易されています。 ホスト クライアント１ サーバー１ クライアント２ サーバー２ クライアント３ サーバー３ LLM client/stdio/, streamable_http.py server/stdio.py, streamable_http.pyなど

実装⑤：その他の機能 それ以外にもエラーハンドリングとか、認証とかいろいろ機能がありますね。でも、概念と大体な実装の構成が分かるとアップデー トもすぐ理解できるはず！ でも、今までの内容を分からなくても、MCPは簡単に使える！ 公式ホームページに分かりやすいチュートリアルがあるので使ってみてください！