🧠 概要：
概要
この記事では、AIエージェントの開発における「Function Calling（FC）」と「Model Context Protocol（MCP）」の違いについて解説しています。FCはOpenAIが提唱した並行してツールと連携するための仕組みで、MCPはその連携を共通プロトコル化することで、非エンジニアでもAIエージェントを容易に開発できるようにします。MCPでは、プログラミングの手間を大幅に削減し、メンテナンス性を向上させるための機能が備わっており、2025年には経営者自らがAIエージェントを開発できる時代が到来することを訴えています。
要約（箇条書き）
- FC（Function Calling）: LLMが外部ツールと連携する仕組み。構造化された情報フォーマットで、特定のタスクを実行するために使用される。
- MCP（Model Context Protocol）: LLMと外部ツールの連携を共通プロトコルにすることで、他のAIモデルでも同じ方法でツール連携が可能に。
- MCPの利点:
- プログラミング工数の大幅削減。
- メンテナンス性が向上。
- 自動化された「ツールディスカバリ」機能により、非エンジニアでもAIエージェントが開発可能。
- オープンソースモデルの活用: コストの最適化を実現。
- 2025年には: 経営者が自身でノーコードで必要なAIエージェントを開発する時代が進化。
- 具体例: 天気情報を取得する際、FCを使って構造化されたアプローチでAPIにアクセス。
- MCP vs FC: MCPは全体の共通化を図ることから、フレームワーク間の互換性があり、開発が容易になる。FCは特定のモデルに依存しがち。
- 結果として: MCPにより、AIエージェントの開発がよりシンプルになり、初心者でも利用しやすくなる。
時間がない人向け要約
Claudeの要約
本記事ではAIエージェント開発における「Function Calling（FC）」と「Model Context Protocol（MCP）」の違いを解説します。FCはOpenAIが提唱した仕組みで、LLMが外部ツールと連携するための構造化された指示形式です。一方、MCPはLLMと外部ツールの連携を共通プロトコル化し、様々なAIモデルで同じ方法でツール連携ができるようにした規格です。MCPの最大の利点は、プログラミング工数の大幅削減とメンテナンス性の向上です。「ツールディスカバリ」機能により、LLMへのツール説明が自動化され、DifyやN8nなどのノーコードツールと組み合わせることで、非エンジニアでもAIエージェント開発が可能になります。さらに、オープンソースモデルの活用でコスト最適化も実現し、2025年には経営者自らが必要なAIエージェントを開発・導入する時代へと進化しています。
読了時間：約5分
最近AIエージェント開発をしている過程でMCPを接続し、AIに必要な情報を自ら取りに行かせることができるという情報を見ました。LangchainやLangGraphというAIエージェント開発フレームワークについて聞いたことがある人なら知っているかもしれませんが、その手のことはOpenAIがかなり前から提唱しているFanction Callingというものを使うことで実現可能です。なぜ最近になって（と言っても数ヶ月前の話ですが）MCPが話題になっているのでしょうか？
MCPとFanction Callingでなにが違うのでしょうか？
今回はこの部分について、Vibe Coder目線で説明していきたいと思います。
Function calling（以下FC）とは？
まずはFCの説明からいきます。FCとは、LLM（大規模言語モデル）に対して「特定のタスクを実行するために必要な情報を構造化された形式で出力してもらう」仕組みです。簡単に言えば、「こういうことをしたい場合は、こういう形式で指示をくれれば、その指示を元に処理を実行し結果を返す」というLLMと外部ツールとの情報連携手段です。
LLMは通常テキストを生成するだけですが、FCを使うと、JSONのような構造化された形式でデータを出力できるようになります。これにより、外部APIやサービスと連携して、LLM自体が持っていない情報にアクセスすることが可能になります。
具体例：天気情報の取得
例えばユーザーが「東京の今日の天気は？」と質問した場合を考えてみましょう。
-
LLMは天気情報をリアルタイムで知りません
-
FCを使うと、LLMはこのような構造化されたJSONを出力できます：
{ "name": "get_weather", "parameters": { "location": "東京", "date": "today" }}3.アプリケーション側でこのJSONを受け取り、実際の天気APIに問い合わせを行います
4.天気APIから返ってきた結果（例：{“condition”: “晴れ”, “temperature”: “25°C”}）をLLMに渡します
5.LLMはこの情報を使って「東京の今日の天気は晴れで、気温は25°Cです」のように人間が理解しやすい形で回答を生成します。
つまりどういうことか
非エンジニア向けに要約するなら、FCは「天気が知りたいなら、”get_weather”という呪文と地名を教えてくれれば、詳細はこっちで取得して結果だけ教えるからね」とLLMにユーザーとの会話の前に事前情報として伝えておくわけです。
そうするとLLMはユーザーから天気に関する問い合わせがあったときに、「あ！そういえばお天気呪文があったな」と思い出したかのように魔法を唱えるのです。
JSONフォーマットについて
先のFCの例ではJSONという書式でこの情報のやり取りを定めていました。しかし、これがややこしいことに、使うLLMによってこのJSONのフォーマットは違ったりします。
人間で例えるなら、日本人は日本語で「東京の天気教えて？」って言ってくるけど、アメリカ人は英語で”Tell me about the weather in Tokyo.”って言ってくるようなものです（よく見ると「」や””などセリフの表示も違うように、細かな点も異なります）。
ソフトウェアを開発している人からしたら、これらすべての言い回しを想定して、その指示に対する返答を生成するための仕組みを作らないといけないわけです。非常にだるいことになりました。「みんな英語を話せばいいのに」と思ったそこのあなた。MCPがその願いを叶えます。
MCPとは？
MCPとはModel Context Protocolの略称で、LLMと外部ツールとの情報のやり取りを共通プロトコル化してより連携しやすくするための決まりごとです。
公式ドキュメントはUSB-Cに例えていました。USB-Cは充電もできるし、情報のやり取りもできますよね。充電にしても高速充電や低速充電など、様々な機能に対応しています。USB-Cという形状一つ指定されれば、すべてのデバイスに必ず刺さります。これが共通化されているということです。
上記の例で言えば、「みんな英語を話している状態」です。これで英語に関してだけ準備を行えば、あらゆる外部ツールとの連携ができるようになりました。
共通化されたことで特定のLLMに依存することがなくなり、オープンソースのモデル（DeepSeekやLlamaなど）でも外部ツールとの連携がシームレスに可能になります。
マニアックな話をすると、FCはOpenAIが提唱し始めた概念で、他のモデルではツールコールが適切に発動しないといった問題を抱えていたりします。これはAIエージェント開発において、モデルの選択肢を大幅に狭める原因となり、最終的には高コストなモデルを使わざるを得なくなって、エンドユーザーのサブスクリプション料金に転嫁される原因になりかねません。
でもVibe Coder向けに言いたいのはこんなことではない
薄々気づいている方もいるかもしれませんが、この記事では最終的に「MCPが最高」ということを伝えたいわけです。
何が最高なのか？MCPはVibe Coderにとってもとても嬉しいことがあります。それはシンプルに言えば、書くコードが減ること、そしてメンテナンスが楽になることです。
FCではLLMからの指示を受け取ったら、その指示に基づきどう処理するかといった部分に関しても、AIエージェントのコードと一緒に書く必要があります。つまり外部ツールの仕様が変わったり、新しいツールを追加したりする場合は、複雑なエージェントのコードに手を加える必要が出てきます。
LangGraphというフレームワークは複数のツールを使いこなせますが、過去の会話履歴の管理なども全て自分でする必要があり、非常に大変です。私は挫折しました。
MCPの真価
MCPの場合、何がいいのでしょうか？MCPには「ツールディスカバリ」という機能があり、LLMが初回起動時に「こんなツールラインナップがあります」「各ツールは何をするためのものか」という説明をLLMに対して渡す部分まで自動で行ってくれます。
これによりFCに関するコードを一切書かなくて良くなります。そしてツールに変更が生じた際もMCP側だけ（本当にツール側だけ）変更すれば良くなります。
MCP自体はDifyやn8nなどのノーコードツールを使うことで非エンジニアでも作れる時代です。そのため、複雑なツールをカスタマイズしてLLMと組み合わせることが、プログラミングの専門知識がなくてもできるようになります。
会話の記憶管理も自動化してくれているフレームワークは多数あります。一方でFCは当然、個々のニーズに応じてプログラムを書く必要があるため、どんなフレームワークを使っても苦労は同じです。
MCPなら記憶の管理やMCPの接続の部分まで整ったフレームワークを採用することで、複数のツールを使いこなしてユーザーの要望を達成するAIエージェントの作成が、ノーコードに近いローコードで達成可能になります。
また、特定の簡単なタスクに関しては、コストの低いオープンソースモデルを使うことで、システム全体のコストを下げるなどの最適化も自由自在です。
2025年、非エンジニア、特に経営者、ビジネスニーズに一番敏感な張本人が自分でノーコードで必要なAIエージェントを開発して現場投入する自体です。
Views: 0
