# はじめに LLMを使ったAIエージェントの文脈で、近年 **MCP** という用語を見かけることが多くなりました。 MCPとは、**Model Context Protocol** の略です。簡単に言えば、**LLMが外部のツールやデータベース、アプリケーションと安全かつ標準化された形でやり取りするための仕組み**です。これはAnthropicが2024年11月25日に正式発表した規格で、翌年3月には競合であるOpenAIでもMCPの規格を採用することを[Sam Altman氏がX上で告知](https://x.com/sama/status/1904957253456941061)して当時話題となりました。 https://www.anthropic.com/news/model-context-protocol しかし、上記の説明は少し抽象的かもしれません。そこで本稿では、MCPを「役所での住所変更手続き」に例えて説明します。自然言語で依頼を受けたLLMが、MCPに従ってツール群を呼び出し、結果を取得し、最終的な応答を返すまでの流れを、役所の窓口業務に対応付けて理解してみましょう。 > HTTPやAPIの概念も役所での手続きによく例えられますが、MCPもプロトコルの一種なのでこれら同様に例えることができます。 > 分かりやすさを優先するため、細かい部分の違いはここでは無視します。 # MCPとは何か MCPは、**LLMが外部システムを利用するための共通規格**です。 従来、LLMに外部ツールを使わせようとすると、ツールごとに個別の接続方法やAPI仕様を用意する必要がありました。例えば次のようなものです。 ``` - ファイルを読み取るツール - GitHubのリポジトリを操作するツール - データベースを検索するツール - カレンダーを参照するツール - メールを検索・作成するツール - ローカルPC上のスクリプトを実行するツール ``` これらをLLMから利用するたびに、個別に接続仕様を作り込んでいると、開発も運用も複雑になってしまい大変です。MCPはこの問題を解決するために、LLMと外部ツールの間に共通の取り決めを設けます。 MCPの役割は、例えば以下のようなものです。 ``` - どのようなツールが利用可能かをLLM側に知らせる - 各ツールがどのような入力を受け付けるかを定義する - ツール呼び出しの形式を標準化する - ツールから返ってくる結果の扱いを整理する - LLMが外部システムに無秩序にアクセスしないようにする ``` ここで重要なのは、MCPが「LLMそのもの」**ではない**という点です。MCPは、LLMが外の世界と接続するための取り決めのことを指します。外部との接点を提供するものなので、LLMにとっては外部ツールを操作するためのインターフェースとも表現できます。 # 役所での住所変更に例える 冒頭でも述べたように、MCPを理解するには「役所で何か手続きをする場面」を考えると分かりやすいです。 あなたが市役所に行き、窓口で次のように伝えたとします。 > 引っ越したので住所変更をしたいです。 これは自然言語による依頼です。この時点では、あなたは細かい行政手続きの内部仕様を知っている必要はありません。例えば、次のようなことを完全に理解していなくても、窓口職員が必要な手続きを案内してくれます。 ``` - どの申請書が必要か - 本人確認書類が必要か - 住民票の情報をどう更新するか - マイナンバーカードの住所変更が必要か - 国民健康保険や児童手当など、関連手続きがあるか - どの部署に確認すべきか ``` このとき、窓口職員は、あなたの自然言語の依頼を受け取り、役所内部の手続きに変換しています。 MCPにおけるLLMも、これと似た役割を果たします。役所の住所変更手続きと、LLM + MCP の構成要素を対応させると、次のようになります。 | 役所の比喩 | MCPにおける対応物 | |---|---| | 市民 | ユーザー | | 「住所変更をしたいです」という依頼 | 自然言語プロンプト | | 窓口職員 | LLM | | 役所内の手続きルール | MCPの仕様 | | 申請書の形式 | ツール呼び出しの入力スキーマ | | 住民課・保険課・税務課などの部署 | 外部ツール・外部サービス | | 部署ごとの内部システム | MCPサーバーの背後にある実システム | | 窓口職員が部署に照会する行為 | LLMがMCP経由でツールを呼び出す行為 | | 部署から返ってくる確認結果 | ツールの実行結果 | | 最終的な案内や処理完了の説明 | LLMによる応答 | この対応関係で考えると、MCPの役割はかなり明確になります。MCPは、LLMという「窓口職員」が、役所内の各部署やシステムに対して、決められた形式で問い合わせや処理依頼を行うための共通手続き、と理解できます。 ## 具体例： 住所変更の流れと対応付ける ここでは、MCPを使ったLLMの処理を、役所での住所変更手続きと対応させて整理します。まず、この流れを図解してみます。 ![MCP.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697094/ea85cbc8-3f31-4c0f-b027-c15b09c49f92.png) > この図はAIを使用せず、筆者がPowerPointで作成したものです。 図の左側は、LLM + MCPにおける実際の処理の流れです。図の右側は、それに対応する「役所で住所変更を行う場合」の流れです。 両者に共通しているのは、次の構造です。 ``` 自然言語の依頼 ↓ 意図の理解 ↓ 手続きの書式の確認 ↓ 構造化された依頼 ↓ 実際の処理 ↓ 結果を返す ↓ 説明 ↓ 最終案内 ``` MCPを理解する上で重要なのは、LLMがいきなり外部システムを自由に操作しているわけではない、という点です。ユーザーの自然言語による依頼を受け取り、必要な手続きを判断し、MCPで定義された形式に従ってツールを呼び出し、その結果を読み取って、最後に自然言語で説明します。 これは、役所の窓口職員が市民の相談を受け、必要な申請書式や担当部署を確認し、内部システムで処理を行い、最後に市民へ結果を案内する流れに似ています。 先ほどの図で重要なのは、ユーザーが直接データベースや業務システムを操作するのではなく、あくまで自然言語で依頼するだけでよい、という点です。その依頼をLLMが解釈し、必要な外部ツールを判断してMCPに従って呼び出します。そして結果を受け取ったLLMが、最終的にユーザーへ分かりやすい言葉で返答します。 * * * 以下、各ステップごとに、もう少し詳しく見ていきましょう。 ### 1. 自然言語の依頼 LLM + MCPの場合、最初にあるのはユーザーからの自然言語の依頼です。例えば次のような依頼です。 > ファイルを検索して要約して この時点では、ユーザーはどのツールを使うべきか、どのAPIを呼ぶべきか、どのような引数を渡すべきかを指定していません。役所での住所変更に対応させると、これは市民が窓口で次のように伝える場面に相当します。 > 引っ越したので住所を変更したいです 市民も、最初から申請書の内部処理や住民記録システムの仕様を理解しているわけではありません。まずは自然言語で「何をしたいか」を伝えます。 ### 2. 意図の理解 次に、LLMはユーザーの依頼の意図を理解します。「ファイルを検索して要約して」という依頼であれば、LLMは少なくとも次のことを判断します。 - 何らかのファイル検索が必要である - 検索対象となる文書やキーワードを特定する必要がある - 見つかった内容を読み取る必要がある - 読み取った結果を要約する必要がある この段階では、LLMはまだ実際の検索処理をしているわけではありません。依頼の目的を解釈し、どのような外部ツールが必要になりそうかを判断しています。役所の例で言えば、窓口職員が市民の相談内容を聞き取り、「これは住所変更の手続きであり、本人確認や申請書の記入、住民情報の更新が必要だ」と判断する段階です。 ### 3. 手続きの書式を確認する LLMが外部ツールを使うには、利用可能なツールや入力形式を知る必要があります。MCPでは、利用可能な `tools`、入力の `schema`、参照可能な `resources` などが定義されます（これらは用語として重要です） 例えば、ファイル検索ツールが次のような入力を要求するとします。 ```json { "keyword": "string", "limit": "number" } ``` この場合、LLMは「検索キーワード」と「取得件数」を構造化して渡す必要があります。これは、役所で住所変更届の申請書式や受付ルールを確認する段階に相当します。住所変更では、例えば次のような情報が必要になります。 ``` - 氏名 - 旧住所 - 新住所 - 異動日 - 本人確認情報 - 世帯情報 ``` MCPにおける `schema` は、役所でいう申請書の記入欄や受付条件に相当します。 ### 4. 構造化された依頼を作る 次に、LLMは自然言語の依頼を、ツールが処理できる構造化された形式に変換します。例えば、ユーザーの依頼が「MCPについて書かれたファイルを検索して要約して」であれば、LLMは次のようなツール呼び出しを作るかもしれません。 ``` search_documents(keyword="MCP", limit=5) ``` あるいは、JSON形式で表すなら次のようになります。 ```json { "tool": "search_documents", "arguments": { "keyword": "MCP", "limit": 5 } } ``` ここで起きているのは、自然言語から構造化データへの変換です。役所の住所変更で言えば、市民の「引っ越したので住所を変更したいです」という相談を、申請書に必要な項目へ落とし込み、登録に向けた準備を整えます。 ``` 氏名：山田太郎 旧住所：千葉県○○市…… 新住所：東京都○○区…… 異動日：2026年5月1日 ``` MCPにおける `tool call` は、役所で言えば、申請書を記入して担当部署へ渡せる状態にすることに対応します。 ### 5. 実際の処理を行う 構造化された依頼が作られると、MCPサーバーや外部ツールが実際の処理を行います。ファイル検索の例であれば、外部ツールは次のような処理を担当します。 - ファイル一覧を検索する - キーワードに一致する文書を探す - 必要に応じて文書の中身を読む - 関連する検索結果を返す ここで重要なのは、実際にファイルシステムやデータベースへアクセスするのはLLM本体ではなく、MCPサーバーや外部ツール側だという点です。LLMはどのツールをどう呼ぶかを判断し、実際の検索やDB問い合わせ、API実行は外部ツールが担当します。 役所の例で言えば、窓口職員が住所変更の必要事項を確認したあと、住民課や内部システムで住所変更処理を行う段階です。窓口職員がすべてを口頭で済ませているわけではなく、内部の業務システムや担当部署が実処理を担っています。 ### 6. 結果を返す 外部ツールで処理が完了すると、その結果がLLM側に返されます。ファイル検索であれば、例えば次のような結果です。 ```json { "status": "success", "results": [ { "title": "MCPの概要.md", "snippet": "MCPはLLMが外部ツールを利用するための共通プロトコルです。" }, { "title": "AIエージェント設計メモ.md", "snippet": "MCPサーバーを介して、ファイル検索やAPI呼び出しを行う。" } ] } ``` この結果には、検索が成功したか、どの文書が見つかったか、どのような内容が含まれていたか、といった情報が含まれます。役所の住所変更で言えば、担当部署や内部システムから次のような処理結果が返ってくる段階です。 ``` 受付完了 不備なし 追加確認なし 住所変更処理完了 ``` 不備がある場合には、追加書類や再確認が必要であることも返されます。 ### 7. 結果を読み取り、説明を作る ツールから結果が返ってきたあと、LLMはその結果を読み取ります。ここでLLMが行うのは、単なるデータの転記ではありません。検索結果の中から重要な部分を取り出し、ユーザーの依頼に合うように整理し、分かりやすい説明を作ります。 例えば、ファイル検索結果に複数の文書が含まれていた場合、LLMは次のような判断を行います。 - どの文書が依頼に最も関係しているか - 重複している内容はどれか - 要約に含めるべき中心的な情報は何か - ユーザーにそのまま見せるべきでない内部情報はないか - エラーや不確実性をどう説明すべきか 役所の例で言えば、窓口職員が内部システムの処理結果を見て、市民への分かりやすい説明を考える段階です。内部システムの画面や処理ログをそのまま市民に見せるのではなく、「手続きは完了しました」「この書類だけ追加で必要です」といった形に整理します。 ### 8. 最終応答を返す 最後に、LLMはユーザーに自然言語で応答します。ファイル検索と要約の例であれば、次のような応答になります。 > MCPに関するファイルを検索したところ、主に2件の関連文書が見つかりました。内容を要約すると、MCPはLLMが外部ツールやデータソースを標準化された形式で利用するためのプロトコルであり、AIエージェントがファイル検索、DB問い合わせ、API実行などを安全に扱うための基盤として使われます。 役所の住所変更であれば、窓口職員が市民に次のように案内する場面です。 > 住所変更の手続きは完了いたしました。記入事項に不備はございませんでした。必要に応じて、マイナンバーカードや保険関係の住所変更もご確認ください。 このように、最終応答では内部で行われた処理そのものよりも、ユーザーにとって意味のある結果が返されます。これで一連の手続きは終了です。 ## MCPは「役所内の共通手続き」 役所では、窓口職員が各部署へ自由な形式で依頼するわけではありません。住民票の住所変更ひとつとっても、決められた申請書・確認項目・本人確認・住所の記載形式など、厳格なルールが存在します。関連部署への情報共有にも、一定の業務フローが定められています。 MCPも同じ発想です。LLMが外部ツールを呼び出す際、「いい感じに処理して」と曖昧に投げるのではなく、次のような情報を構造化して渡します。 ``` - 呼び出すツール名 - 入力すべきパラメータ - 入力値の型 - 必須項目 - 実行結果の形式 - 利用可能なリソース - 権限や接続先 ``` これは、役所で言えば「所定の申請書に必要事項を記入して、各担当部署に回す」ことに相当します。 ## MCPサーバーは「各部署との接続窓口」 先ほどからすでに何度か登場している用語ですが、プロトコルとしてのMCPにおいて外部ツールやデータソースを提供する側のサーバーを「**MCPサーバー**」と呼びます。 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/697094/d706a12c-51da-4616-b8f9-80fc1266bb39.png) > この図は GPT-5.5 が作成しました。 これも役所の例で理解できます。 窓口職員が住民基本台帳のデータベースを直接操作するとは限りません。実際には、住民課のシステムや担当部署の業務端末を通じて情報を確認します。MCPサーバーも同様に、LLMから見た外部機能の提供口です。例えば次のようなものが挙げられます。 ``` - ファイル検索 - GitHub操作 - データベース検索 - Webブラウザ操作 - ローカルコマンド実行 - カレンダー参照 - メール検索 - 社内ドキュメント検索 ``` LLMはこれらの実システムを直接操作するのではなく、MCPサーバーが公開している機能を通じてアクセスします。 ここで押さえておきたいのは、LLMがすべてを自ら実行しているわけではないという点です。役所の窓口職員も同様で、すべての処理を一人で完結させているわけではありません。住民票の更新には住民記録システムが、保険変更には保険担当部署が、税務確認には税務部署がそれぞれ関わります。 窓口職員の役割は、次のように整理できます。 ``` - 市民の依頼内容を理解する - 必要な手続きを判断する - 必要な部署に照会する - 必要書類や入力項目を確認する - 戻ってきた結果を整理する - 市民に分かりやすく説明する ``` LLMも同じです。ユーザーの依頼を自然言語で受け取り、必要なツールを選んでMCP経由で呼び出し、結果を統合して返答します。 つまりLLMの本質的な役割は、外部システムの「実行主体」ではなく、自然言語と構造化された手続きの間を橋渡しする「**判断・調整・説明の主体**」です。 * * * **※ 参考： *Understanding MCP servers* - [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro)** https://modelcontextprotocol.io/docs/learn/server-concepts ## MCPが重要になる場面 MCPが特に重要になるのは、LLMに単なる文章生成以上の作業をさせたい場面です。例えば次のような用途が挙げられます。 ``` - ファイルを読んで内容を要約する - GitHubのIssueやPull Requestを確認する - ローカル環境でスクリプトを実行する - データベースから条件に合う情報を検索する - カレンダーを見て予定を調整する - メールを検索して返信案を作る - 社内文書を参照して質問に答える - 複数のツールを組み合わせてワークフローを実行する ``` これらはいずれも、LLM単体では完結しません。LLMは自然言語を理解し、方針を立て、応答を生成できます。しかし最新のファイル、ローカルPC上のデータ、社内システム、外部APIといったリソースにアクセスするには、何らかの接続機構が必要です。その接続機構を標準化するものがMCPです。 :::note ### MCPによってLLMが賢くなっている訳ではない MCPについて考えるときに把握しておきたいのは、MCPそのものがLLMの賢さを高めるわけではないという点です。MCPはあくまで、LLMが外部ツールを使うための接続規格です。導入したからといって、LLMの推論能力自体が急に向上するわけではありません。 役所の例で言えば、MCPは「窓口職員の知識量を増やす技術」ではなく、単に「窓口職員が各部署と正しく連携するための業務フロー」です。どんなに賢い窓口職員（＝LLM）でも、部署間の連携ルールが整っていなければ手続きは混乱します。逆に、連携ルールが整っていても、窓口職員が依頼内容を誤解すれば、間違った手続き方法でフローが進んでしまいます。 LLM + MCPの場合も同様です。MCPは外部ツールとの連携を整理するものですが、どのツールをいつ呼ぶべきか、結果をどう解釈すべきかは、LLM側が判断します。したがって実用上は、MCPに従うことのできる程度には賢いLLMをユーザーが選択しなければなりません。 > これは、図書館のレファレンスサービスにも似ています。 > > 優れた司書は、すべての知識を自分の頭の中に持っている訳ではありません。利用者の質問を聞き取り、必要な情報を見極め、蔵書検索、分類体系、専門データベース、参考図書などを使い分けながら、信頼できる情報に辿り着きます。 > > 提供される情報が大変に重厚かつ正確で有益であったとしても、それは情報を提供する司書自身が全知全能であることを意味しているのではなく、適切な情報源にアクセスし、それを評価し、利用者に分かりやすく整理して返す能力があるということだけです。（勿論、このような能力が優れたものであることは間違いありません） > > LLM + MCP もこれに近い構造を有しています。MCPはLLMそのものを賢くする技術ではありません。しかし、LLMが外部ツールやデータソースに接続し、それらを一定の手続きに従って利用できるようにします。その結果、LLM単体では答えられない質問にも、外部情報を参照しながら答えられるようになります。 > > つまり、MCPはLLMの「知能そのもの」を増やすのではなく、**LLMが参照できる情報源と実行できる手続きを広げる仕組み**と理解すべきです。 ::: # まとめ ここまでの内容を、住所変更の例で改めて整理します。 市民（＝ユーザー）は、役所の内部システムの仕様を知りません。それでも「住所変更をしたい」と伝えれば、窓口職員が必要な手続きを判断してくれます。LLMの場合も同じです。ユーザーは外部ツールのAPI仕様を知る必要はなく、「このファイルを読んで要約して」「GitHubのIssueを確認して」「予定を調整して」と自然言語で依頼するだけで良いのです。LLMがその意図を解釈し、どれが目的達成に必要なツールかを判断します。 MCPは、LLMがそれらのツールに対して決められた形式で安全にアクセスするための共通の手続きです。役所で言えば、申請書の様式・部署間の連携や情報伝達のルール・承認フロー・照会手続きなどに相当します。 * * * ここまで役所の比喩を用いて長々と説明してきましたが、要約すると、 - LLM ＝ 自然言語を理解する窓口 - MCP ＝ その窓口が外部システムに正しい形式で依頼を出すための手続き - 外部ツール ＝ 実際の処理を担当する各部署 と整理できます。この三者の関係を理解すると、MCPがなぜAIエージェント時代の基盤技術として重要視されているのかが分かります。