「MCPを使ってる人」が より詳しくなるための解説

このプレゼンテーションは、「MCPを使ってる人」がより詳しくなるための解説を目的としています。

内容としては、以下のトピックが扱われています。
MCPとは何か: MCPの基本的な概念と、Function Callingとの違いについて説明しています。
MCPの簡単な仕様: MCPの構造、登場する概念（MCP Server、MCP Client、MCP Protocolなど）、具体的な使い方、Transport Layer（JSON RPC、StdinTransport、StreamableHTTP、HTTP+SSE）について解説しています。
なぜMCPが流行っているのか: MCPのメリットや、なぜ注目されているかを解説しています。
MCPの問題点: MCPの課題点と、その分類（MCP自身が内包する問題とAgentがMCPを使用する際に発生する問題）について説明しています。
今後の展望: A2Aの紹介とマルチエージェント時代の可能性について触れています。

Transcript

1. 「MCPを使ってる⼈」が より詳しくなるための解説 やまぐち
2. 今⽇はこないだZennで多くの⽅に⾒てもらった記事をもう少し詳 しく解説しようと思います 実装⽅法などはやらないので、気になる⽅は読んでみてください！
3. 今⽇学べること • MCPとは何か • FunctionCallingと何が違うか • MCPの簡単な仕様 • 問題点は？
4. 覚えていますか？ 2022年LLMはちゃんとツールを使えませんでした
5. 2023年6⽉ OpenAI FunctionCallingが誕⽣ LLMがツールを使う独⾃規格が誕⽣
6. Function CallingでLLMはツールを使うようになった
7. 各社のFunctionCallingを出している　
8. 各社FunctionCallingのインターフェイスが異なる
9. LLMライブラリでは吸収するためにこんなにパッケージが ... https://github.com/vercel/ai/tree/main/packages
10. (推測)ツール提供側も困るし、利用者側も困ってた このモデルFunctionCallingのレイ ヤー作らないと... ツール提供者 アプリor プラットフォーム開発者 LLMの利用者 あのリソース使って調べ物したい、 開発したいなあ Difyでは提供してないかー Langchainならあるかー 自作するかー リソースあって、LLMに使わせるツー ル作りたいけど、 Langchainで提供がいい？ Vercel AI SDKがいい？？ Difyのプラグイン作る？？ わからない・・・
11. MCP誕生 MCP は、アプリケーションが LLM にコンテキストを提供する ⽅法を標準化するオープン プロ トコルです。MCP は、AI アプリ ケーション⽤の USB-C ポートの ようなものです。 (https://modelcontextprotocol.i o/introduction より)
12. (推測)MCPが出てきてみんなハッピー！ ツール載せるのはMCPで統一できそ う！ FunctionCallingをいいい感じにする レイヤーいらなくなった！ アプリor プラットフォーム開発者 LLMの利用者 ツール提供者 あのリソースMCPで提供して る！ラッキー！ とりあえずMCPにのせてリソース公 開すればええやん！ 開発者側にも 利用者側にも使ってもらうぞ！
13. (推測)MCPが出てきてみんなハッピー！ ツール載せるのはMCPで統一できそ う！ FunctionCallingをいいい感じにする レイヤーいらなくなった！ アプリor プラットフォーム開発者 LLMの利用者 ツール提供者 あのリソースMCPで提供して る！ラッキー！ とりあえずMCPにのせてリソース公 開すればええやん！ 開発者側にも 利用者側にも使ってもらうぞ！ MCP Clientさえあれば、ツール提供者と そのままやりとりできる
14. 世の中はだんだんと MCPブームに移りゆく
15. ではそんな MCPの仕様 ざっくり理解してみましょう
16. MCPはLLMにリソース (ツール)を使わせるための標準規格 MCP は、アプリケーションが LLM にコンテキストを提供する⽅法を標準化するオープン プ ロトコルです。MCP は、AI アプリケーション⽤の USB-C ポートのようなものです。 (https://modelcontextprotocol.io/introduction より) https://modelcontextprotocol.io/introduction より
17. 登場する概念 • MCP Server ◦ 各社がリソースを公開して いるかはこちらを確認しよ う • MCP Client ◦ CursorやClaude Desktop などがこれにあたる • MCP Protocol ◦ MCPClientとMCPServerを 間の通信を扱うプロトコル 部分 https://modelcontextprotocol.io/introduction より
18. 登場する概念 実装する可能性の高い、 この間部分を今日は深掘 りします！ • MCP Server ◦ 各社がリソースを公開して いるかはこちらを確認しよ う • MCP Client ◦ CursorやClaude Desktop などがこれにあたる • MCP Protocol ◦ MCPClientとMCPServerを 間の通信を扱うプロトコル 部分 https://modelcontextprotocol.io/introduction より
19. まずはMCPがどう使われているか を確認しましょう
20. MCPが使われるまでのフロー
21. まずはTransport Layerを理解しよう
22. JSON RPC TransportLayer MCP ClientとServerの間は？ stdin StreamableHTT P HTTP+SSE 接続方式 標準入力＋出力 HTTP HTTP＋EventSo urce Client→Server 文字列 （JSON-RPC）を 逐次書き込み POST 追加送信は別 REST 呼び出しが 必要 Server→Client stdout へ逐次 書き込み SSE ストリームで プッシュ／単発 JSON SSEエンドポイント でSSE ストリーム - ステートレスにでき る？ - Transport層一覧
23. StdinTransportとは？
24. StdinTransportとは？ StdinTransport 標準入力 (stdin) 標準出力 (stdout) MCPClientの⼦プロセスと して⽴ち上がる
25. StdinTransportとは？ シーケンス図
26. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？
27. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET
28. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET ②セッションを発⾏＋ HTTP POSTのエンドポイントを返却
29. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET ②セッションを発⾏＋ HTTP POSTのエンドポイントを返却 ③メッセージを送信
30. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET ②セッションを発⾏＋ HTTP POSTのエンドポイントを返却 ③メッセージを送信 ④イベント キャッチ メッセージ返 却先をセッ ションIDで特 定してSSEかレ スポンス
31. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET ②セッションを発⾏＋ HTTP POSTのエンドポイントを返却 ③メッセージを送信 ④イベント キャッチ メッセージ返 却先をセッ ションIDで特 定してSSEかレ スポンス ⑤SSEメッセージをPush
32. StreamableHTTP とHTTP+SSEの違い HTTP+SSEとは？ HTTPP OST SSE ①GET ②セッションを発⾏＋ HTTP POSTのエンドポイントを返却 ③メッセージを送信 ④イベント キャッチ メッセージ返 却先をセッ ションIDで特 定してSSEかレ スポンス ⑤EventをPush すでにHTTP＋SSEはLegacy これからは StreamableHTTP
33. StreamableHTTP とHTTP+SSEの違い StreamableHTTPとは？
34. StreamableHTTP とHTTP+SSEの違い StreamableHTTP= (HTTP+SSE) ＋ちゃんとしたセッション管理
35. StreamableHTTP とHTTP+SSEの違い StreamableHTTP HTTP /mcp 一つのHTTP POSTエンドポイントのみ ただし、場合によっては GET,DELETEの2つも使う可能性あり
36. まずはステートレスStreamableHTTP streamを使⽤しない場合
37. ステートレスStreamableHTTP streamを使⽤しない場合 HTTP /mcp ①POST messageを送る
38. ステートレスStreamableHTTP streamを使⽤しない場合 HTTP /mcp ①POST messageを送る ② Content-Type: application/json でレスポンス
39. 次にステートレスStreamableHTTP streamを使⽤する場合
40. ステートレスStreamableHTTP streamを使⽤する場合 HTTP /mcp ①POST messageを送る
41. ステートレスStreamableHTTP streamを使⽤する場合 HTTP /mcp ①POST messageを送る ② Content-Type:text/event-stream でSSEメッセージをPush
42. ステートフルStreamableHTTPは？
43. 仕様に任せます。どこかでちゃんと書くかもしれません https://modelcontextprotocol.io /specification/2025-03-26/basic/ transports
44. なぜSSE＋HTTPからStreamableHTTPに移行した？ 前提： • 実装負荷が低く扱いやすい HTTP + SSEを最初に採⽤ ◦ HTTP＋SSEは約160⾏、streamableHTTPは約700⾏ほど 問題： • mcpが広く使われ、PaaS へのデプロイ で、接続を保持する⽅式が⾜かせ • コネクション状態をサーバ側が抱えるため オートスケール∕サーバーレス環境でス ケールアップ‧ダウンが困難。 解決策： • 接続状態を持たない ストリーミング対応 HTTP へ置き換え、MCP を ステートレス化 ⼀部私の推測が⼊っていますが、基本移⾏の流れはGithubDiscussionに書かれています。 https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206
45. なぜWebSocketは選ばれなかった？ https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206　に理由が書かれています
46. なぜWebSocketにしなかった？ ~WebSocketを眺めながら https://github.com/modelcontextprotocol/modelcontextprotocol/pull/206　に理由が書かれています
47. なぜWebSocketにしなかった？ ~WebSocketを眺めながら 問題点① 呼び出ごとにソケットを貼るのは重い 現状想定しているのは単発低頻度で動くRPCのような動かし⽅っ 毎回毎回 WebSocket を開閉すると HTTP‐>WS アップグレード ローズ処理のたびに往復遅延とオーバーヘッドが発⽣します 問題点① 呼び出ごとにソケットを貼るのは重い 現状想定しているのは単発低頻度で動くRPCのような動かし⽅っ 毎回毎回 WebSocket を開閉すると HTTP‐>WS アップグレード ローズ処理のたびに往復遅延とオーバーヘッドが発⽣します →とはいえ⾼頻度なやり取りがある場合はWebSocketの⽅がオー ヘッドは少なくなります
48. なぜWebSocketにしなかった？ ~WebSocketを眺めながら 問題点② ブラウザからは、Authorizationヘッダー ( など) を添付す る⽅法はない →Cookieやクエリパラメータなら⼀応対処できる
49. なぜWebSocketにしなかった？ ~WebSocketを眺めながら 問題点③ GetでまずはHTTPからWSにアップグレードします。ただ WebSocketはGETでのみアップグレードを許可している ので、RPCはPOSTベースなのでアップグレードするのに ２段階の処理が必要になり、複雑かつ待機時間が増える
50. WebSocket対応の要望は多いので 再検討される可能性はありそうです
51. では、ClientとServerの機能要素は どんなものがあるでしょうか？
52. Sampling Roots Tool Resource Prompt ClientとServerの機能は？
53. Sampling Roots Tool Resource Prompt Tool 実際動いている箇所
54. Tool Resource Prompt Tool • Tool ◦ アクションを実⾏するためにLLMに公開される関数 ◦ 基本モデルが制御するもので、世の中の⼈がMCPと 思っているのもこれ MCP Server側の機能(Tool)
55. Tool Resource Prompt Tool • Resource ◦ MCP サーバーがクライアントに提供したいあらゆ る種類のデータを提供する ◦ アプリケーションが制御するもの。ユーザーにどう 使わせるかは各MCP Clientの⾃由とされています。 ◦ 選ばせてもいいし、⾃動で⼊⼒されてもいい • Prompt ◦ サーバーは再利⽤可能なプロンプト テンプレートと ワークフローを定義でき、クライアントはそれを ユーザーや LLM に簡単に表⽰できます ◦ 基本はユーザーが制御するもので、ユーザーが明⽰ 的に選択する ◦ ClaudeForDesktopで主に採⽤されている MCP Server側の機能(Resource, Prompt)
56. Roots • Roots ◦ MCPClientがServerと接続する時に呼ば れる ◦ ServerにClient側のルートを教えるために あるエンドポイント。この範囲でみて ね！みたいな？ MCP Client側の機能(Roots)
57. • Sample ◦ Server側がClient側に対 してLLMの⽣成‧補完を 要求できる機能 ◦ Claude for Desktopでも まだない機能 ◦ アプリケーション側が ⾃由に実装しても良い MCP Client側の機能(Sampling) Sampling https://modelcontextprotocol.io/specification/2025-03-26/client/sampling より
58. MCPの正体がわかりましたね
59. MCPはLLMのためのプロトコルでし た。
60. なぜ流行っている？
61. (推測)MCPが出てきてみんなハッピー！ ツール載せるのはMCPで統一できそ う！ FunctionCallingをいいい感じにする レイヤーいらなくなった！ アプリor プラットフォーム開発者 LLMの利用者 ツール提供者 あのリソースMCPで提供して る！ラッキー！ とりあえずMCPにのせてリソース公 開すればええやん！ 開発者側にも 利用者側にも使ってもらうぞ！ MCP Clientさえあれば、ツール提供者と そのままやりとりできる
62. MCPは最高？
63. もうちょっとよくなればいいな
64. MCPの問題点 ~私が⾟いなと思う瞬間４選~ 大量のコンテキス トを渡してくる。 それがノイズになっ て邪魔してくる。辛 い ① エージェントが MCPちゃんと選ん でくれない ツール大量で多分 選ぶの大変そう。 ツール多いとノイズ にもなりそう ② 長時間・非同期タ スクに適してない notificaiton/progr essを使うことで ⻑時間タスクを進 捗確認しながら実 ⾏できるが、コネ クション繋ぎなが らなので⾮同期で はない。 ③ MCPで外部リソー スを検索するのコ スパわるい 「A」を書いてるド キュメント取得する ために list→read→read →read…を繰り返 して見つからなくて 辛い。 時間もコストだけで 成果はない ④
65. MCPの問題点は2つに分類 ① MCP自身が 内包する問題 ② AgentがMCP を使用する際に 発生する問題
66. ①MCP⾃⾝が内包する問題 • セキュリティ ◦ stdio機能を介して、MCPサーバーがローカルで悪意のあるコードを実⾏する可 能性 ◦ MCPサーバー側で意図せずに使っている悪意あるサードパーティのライブラリ を実⾏してしまう。 ◦ MCPではツールの名前や説明が実際に動くコードが違うことでうっかり悪意の あるツールを実⾏してしまう。 • 使い勝⼿ ◦ Approve押すのめんどくさいけど、ないと不安 • ⾮同期‧⻑時間タスク ◦ notificaiton/progressを使うことで⻑時間タスクを進捗確認しながら実⾏でき るが、コネクション繋ぎながらなので⾮同期ではない。 ◦ LLMにpollingすることをプロンプトで指⽰することで⾮同期チックなことは可 能だが、Agentがそれをどのタイミングで確認させるかや、確認が積み重なる ことでコンテキストを圧迫してしまいよくない。
67. ②AgentがMCPを使⽤する際に発⽣する問題 • MCPのツールをいっぱい提供するとコンテキスト圧迫する • 問題が複雑であればあるほど解決するためのステップ数やその組み合わせが⼤きく なってうまくいかない。 • MCPに実装されているツールに依存して以下の問題が発⽣(この辺は実装が触れるな ら解決できる) ◦ コンテキストの量の制御ができないので、コンテキストが多すぎてコスト増加 ‧精度低下を起こしてしまう。 ◦ 「A」を書いてるドキュメント取得するために、 list→read→read→read…を繰り返 して見つからなくて辛い。時間もコストだけで成果はない
68. ②AgentがMCPを使⽤する際に発⽣する問題 • MCPのツールをいっぱい提供するとコンテキスト圧迫する • 問題が複雑であればあるほど解決するためのステップ数やその組み合わせが⼤きく なってうまくいかない。 • MCPに実装されているツールに依存して以下の問題が発⽣(この辺は実装が触れるな ら解決できる) ◦ コンテキストの量の制御ができないので、コンテキストが多すぎてコスト増加 ‧精度低下を起こしてしまう。 ◦ 「A」を書いてるドキュメント取得するために、 list→read→read→read…を繰り返 して見つからなくて辛い。時間もコストだけで成果はない 問題解決空間ごとに責務を分ければ うまくいきそう
69. ②AgentがMCPを使⽤する際に発⽣する問題 • MCPのツールをいっぱい提供するとコンテキスト圧迫する • 問題が複雑であればあるほど解決するためのステップ数やその組み合わせが⼤きく なってうまくいかない。 • MCPに実装されているツールに依存して以下の問題が発⽣(この辺は実装が触れるな ら解決できる) ◦ コンテキストの量の制御ができないので、コンテキストが多すぎてコスト増加 ‧精度低下を起こしてしまう。 ◦ 「A」を書いてるドキュメント取得するために、 list→read→read→read…を繰り返 して見つからなくて辛い。時間もコストだけで成果はない 問題解決空間ごとに責務を分ければ うまくいきそう エージェントごとに責務を作れば、うまく問 題解決空間絞れてうまくいきそう
70. ②AgentがMCPを使⽤する際に発⽣する問題 • MCPのツールをいっぱい提供するとコンテキスト圧迫する • 問題が複雑であればあるほど解決するためのステップ数やその組み合わせが⼤きく なってうまくいかない。 • MCPに実装されているツールに依存して以下の問題が発⽣(この辺は実装が触れるな ら解決できる) ◦ コンテキストの量の制御ができないので、コンテキストが多すぎてコスト増加 ‧精度低下を起こしてしまう。 ◦ 「A」を書いてるドキュメント取得するために、 list→read→read→read…を繰り返 して見つからなくて辛い。時間もコストだけで成果はない 問題解決空間ごとに責務を分ければ うまくいきそう エージェントごとに責務を作れば、うまく問 題解決空間絞れてうまくいきそう マルチエージェント時代が 次に来るのでは？
72. A2AはMCPを補完してくれる https://google.github.io/A2A/#why-a2a-mattersより MCPのツール・リソースでコ ンテキスト圧迫、性能低下 複雑な問題を解決するた めのステップ数やその組 み合わせが⼤きくLLMが 発散する エージェントごとに責務を分 けて問題解決空間をエー ジェントごとに分ける MCPに関連する問題 解決⽅法 解決⼿段