ここのところ、MCP(Model Context Protocol)が大きな話題になっています。
「AIエージェントを開発してます。外部サービスの連携にはMCPを使うといいですか?」という質問をよくいただくため、この記事でMCPを使うべきかの判断基準を整理します。
注意事項
- MCPの概要はこの記事では説明しません。
- MCPの用途はTools機能(外部サービスをLLMの判断で呼び出す機能)がほとんどのため、この記事の議論もMCPのTools機能を前提とします。
結論:MCPを使うべきかの判断フローチャート
まず結論として、AIエージェントの開発者の視点で、MCPを使うべきかの判断フローチャートを示します。
※このフローチャートでは「AIエージェントの開発者の視点」だけを考慮しています。「外部サービスの開発者の視点」については、あとで補足します。
フローチャートの説明
ここから上記のフローチャートを説明していきます。
外部サービスとの連携を利用時に設定したい場合
開発しているAIエージェントがMCPをサポートするべきかを議論するうえでは、外部サービスとの連携を開発時ではなく利用時に設定したいかが最も重要な観点だと考えています。
Claude DesktopやClaude Codeのように、利用者が自由に好きな外部サービスと連携できるようにしたい場合、まさにMCPが適しています。
ただし、利用者が自由に外部サービスと連携できるようにする場合は、セキュリティ面で十分な注意が必要ですし、利用者のリテラシーも必要になります。
外部サービスとの連携を開発時に実装したい場合
MCPの最も大きなユースケースは上記の通り、外部サービスとの連携を利用時に設定したいしたい場合でした。 今度は、外部サービスとの連携を開発時に実装したい場合について見ていきます。
外部サービスを必ず呼び出す場合
LLMアプリを外部サービスと連携する1つの方法として、外部サービスを必ず呼び出すワークフローを組む場合があります。
たとえば、「検索」して「回答生成」といういわゆるRAGのワークフローを考えてみます。
このように必ず外部サービスを呼び出すようワークフローを実装するときは、MCPは使用しません。
このケースでは、MCPを使用するメリットは基本的にありません。 そして、外部サービスが提供する通常のAPI等で連携したほうが、MCPで連携するよりも簡単に実装できることが多いはずです。
LLMの判断で呼び出す場合
LLMの判断で外部サービスを呼び出す場合、つまりFunction calling(Tool use)を使用する場合を考えます。
このようなケースでは、LLMのFunction calling機能を直接使ってもよいですし、LangChain等のフレームワークのTool機能を使ってもよいですし、MCPを使ってもよいです。
ただし、MCPを使うことによる動作上のメリットは基本的にありません。 MCPのツールの呼び出しは、内部的にはLLMのFunction calling機能で実装します。 つまり、MCPで呼び出してもFunction callingを直接使っても、内部動作はほとんど同じです。
このようなケースでは通常、Function callingを直接使ったり、LangChain等のフレームワークのToolを使って実装することになります。 もしも連携したい外部サービスがMCPサーバーを提供していて、他の方法よりも簡単に実装できそうなのであれば、MCPを使うのも選択肢になります。
補足1)外部サービスの開発者の視点
ここまで、AIエージェントの開発者の視点で説明してきました。 ここで、外部サービス側の開発者の視点について補足します。
外部サービスの開発者の視点としては、LLMの判断で使えるツールを提供したいかどうかが最も重要です。
たとえば、以下のようなケースが考えられます。
- Claude DesktopやClaude Codeといった既製のLLMアプリから、自分たちのサービスを呼び出せるようにしたい
- Python等で実装したLLMアプリから、Function callingで自分たちのサービスを呼び出せるようにしたい
このような場面で使えるプロトコルがまさにMCPです。
MCPは現在、実質的にFunction callingで使えるツールの標準的な提供方法として活用されています。 Function callingで使えるツールを提供したい場合は、MCPサーバーを実装するのは適切な選択肢になります。
ただし実際には、Function calling以外でもそのサービスを呼び出せるようにしたいことが多いはずです。 まずは通常のAPI等の提供が優先であり、MCPサーバーの提供はそのうえでの追加要素として検討すべき、という場面も多いと考えています。
補足2)MCPの限界(Function callingの限界)
MCPを使用するか考える際には、MCPの限界(Function callingの限界)にも注意が必要です。
たとえば、指定したファイル(マークダウン等)の内容をそのままMCPで外部サービスに送信したいと考えるかもしれません。 LLMに「このファイルの内容を◯◯(外部サービス)に保存して」といった指示をするイメージです。
このようなケースでは、LLMがMCPで外部サービスにデータを送信する際に、テキストを要約したり加工したりしてしまう可能性があります。
この問題は、ローカルでMCPサーバーを実行するケースであればファイルパスを指定するといった方法で回避できます。 しかし、リモートのMCPサーバーを使用する場合は解決が困難です。
また、MCPではなく、LLMを介さない通常のAPI等での外部サービスとの連携であれば発生しない問題となります。
おわりに
以上、MCPを使うべきかの判断基準を整理しました。
「AIエージェントを開発しているのですが、MCPを使ったほうがいいですか?」といった疑問を持った際の参考になれば幸いです。
追記
こちらの記事投稿後、もう少し見解を整理しました。
改めて考えると、AIエージェントを「作る」ときは、MCPが嬉しいことは実は少ない。汎用エージェントやプラットフォームを作っているならMCPは嬉しいけど、特化型のエージェントではMCPは必要ないことが多い。AIエージェントを「使う」ときは、自分なりの拡張ができるのでMCPはとても嬉しい。
— しま / 大嶋勇樹 (@oshima_123) 2025年6月17日