AI Agent(AIエージェント)について学習していると、必ずと言っていいほど登場するのが、次の2つの技術です。
- Function Calling(ファンクションコーリング)
- MCP(Model Context Protocol)
どちらもAIが外部のツールやシステムと連携するための技術ですが、最初は違いがわかりにくいと思います。
「Function CallingがあればMCPはいらないのでは?」
「MCPはFunction Callingの代わりになるの?」
「両方を組み合わせて利用するの?」
この記事では、そんな疑問を解消するために、Pythonによる実装例を交えながら、Function CallingとMCPの関係性を解説します。
1. まず結論:Function CallingとMCPは役割が違う
最初に結論から説明します。
Function Callingは、AIが「どの機能を、どの引数で使うか」を決める仕組みです。
一方、MCPは、AIアプリケーションと外部ツールやデータを、共通の規格で接続するためのプロトコルです。
例えば、AIに次のようにお願いしたとします。
「商品ID 1001の在庫を確認して」
Function Callingは、AIがこの指示を理解して、
「get_stock という関数に product_id=1001 を渡せばよさそうだ」
と判断し、関数呼び出しの情報を生成する仕組みです。
一方、MCPは、get_stock という機能を提供するサーバーに接続し、利用可能なツールを発見して呼び出すための共通ルールを提供します。
| 比較項目 | Function Calling | MCP |
|---|---|---|
| 主な役割 | AIによるツール呼び出しの判断・引数生成 | 外部ツールとの接続・通信の標準化 |
| 主な対象 | AIモデルとアプリケーション | MCPクライアントとMCPサーバー |
| ツールの定義 | モデルAPIにスキーマを渡す | MCPサーバーがツールを公開する |
| ツールの発見 | アプリ側が利用可能なツールを渡す |
tools/list などで発見できる |
| 実行 | アプリ側などが実行する | MCPサーバーが実行する |
| 単独利用 | 可能 | 可能 |
| 組み合わせ | 可能 | 可能 |
ここで重要なのは、Function CallingとMCPは競合する技術ではなく、異なる役割を担当する技術だということです。
また、MCP自体にもツールを呼び出す仕組みがあります。必ずFunction Callingと組み合わせなければならないわけではありません。
それぞれの役割をもう少し詳しく見ていきましょう。
2. Function Callingとは?
Function Callingは、LLM(大規模言語モデル)が外部の関数やAPIを利用するための仕組みです。
通常、LLMは入力された文章をもとに回答を生成します。
しかし、例えば「現在の商品在庫を確認して」と言われても、LLMは社内データベースの在庫情報を最初から知っているわけではありません。
そこでFunction Callingを利用します。
Function Callingの処理の流れ
重要なポイントは、LLM自身がPython関数を実行しているわけではないということです。
LLMは、どの関数を使うか、どの引数を渡すかを判断して、呼び出し情報を返します。
実際に関数を実行するのは、Pythonなどで構築したアプリケーション側です。
Pythonで実装してみる
OpenAI APIのResponses APIを使って、Function Callingを実装してみます。
今回は理解しやすいように、データベースの代わりにPythonの辞書を使用します。
① 必要なライブラリをインストール
pip install openai
APIキーを環境変数に設定します。
export OPENAI_API_KEY="your-api-key"
② 在庫確認用の関数を作成
import json
from openai import OpenAI
client = OpenAI()
# 仮の商品データベース
products = {
1001: {"name": "ノートPC", "stock": 15},
1002: {"name": "マウス", "stock": 30},
1003: {"name": "キーボード", "stock": 8},
}
def get_stock(product_id: int):
"""指定された商品IDの在庫を取得する"""
product = products.get(product_id)
if product is None:
return {"error": "商品が見つかりません"}
return {
"product_id": product_id,
"name": product["name"],
"stock": product["stock"]
}
この段階では、ただのPython関数です。
③ AIに利用可能な関数を教える
tools = [
{
"type": "function",
"name": "get_stock",
"description": "商品IDから商品名と在庫数を取得する",
"parameters": {
"type": "object",
"properties": {
"product_id": {
"type": "integer",
"description": "商品ID"
}
},
"required": ["product_id"],
"additionalProperties": False
},
"strict": True
}
]
ここで定義したJSON Schemaをもとに、AIは利用可能な関数と必要な引数を理解します。
④ Function Callingを実行
response = client.responses.create(
model="gpt-5.4",
input="商品ID 1001の在庫を教えて",
tools=tools
)
# AIが要求した関数呼び出しを取得
function_calls = [
item
for item in response.output
if item.type == "function_call"
]
tool_outputs = []
for call in function_calls:
if call.name == "get_stock":
arguments = json.loads(call.arguments)
# 実際にPython関数を実行
result = get_stock(**arguments)
tool_outputs.append({
"type": "function_call_output",
"call_id": call.call_id,
"output": json.dumps(result, ensure_ascii=False)
})
if tool_outputs:
# 関数の実行結果をAIへ返す
final_response = client.responses.create(
model="gpt-5.4",
previous_response_id=response.id,
input=tool_outputs,
tools=tools
)
print(final_response.output_text)
else:
print(response.output_text)
実行結果の例:
商品ID 1001の「ノートPC」の在庫は15個です。
今回は1回のツール実行で完結する例ですが、実際のAI Agentでは、追加のツール呼び出しが返された場合も処理するループを実装します。
Function Callingのポイント
AIが行っているのは、主に以下の処理です。
- ユーザーの指示を理解する
- 利用可能な関数から適切なものを選択する
- 引数を生成する
- 関数の実行結果を受け取る
- 実行結果をもとに回答を生成する
この仕組みによって、AIは文章を生成するだけでなく、アプリケーションの機能を利用できるようになります。
3. MCP(Model Context Protocol)とは?
ここまでのFunction Callingだけでも、AIからPython関数を利用できることがわかりました。
では、なぜMCPが必要なのでしょうか?
例えば、AI Agentから以下のシステムを操作したいとします。
- MySQLからデータを取得する
- GitHubのIssueを確認する
- Slackへ通知を送信する
- AWSのリソースを確認する
- 社内APIにアクセスする
Function Callingでも、それぞれの機能を実装できます。
しかし、複数のAIアプリケーションから同じ機能を利用したい場合、ツール定義や接続処理を個別に実装・管理する必要が出てきます。
そこで登場するのがMCPです。
MCPはAIと外部システムを接続する共通規格
MCPは、AIアプリケーションと外部のツール・データソースを接続するためのオープンなプロトコルです。
MCPを利用すると、MCPサーバーとして公開された機能を、対応する複数のAIアプリケーションから共通の方式で利用できます。
※図では簡略化していますが、実際にはAIアプリケーション内のMCPクライアントがMCPサーバーと通信します。
MCPはHTTPなどの通信方式の上で動作し、ツールの一覧取得や実行などを標準化しています。
MCPには3つの重要な機能がある
MCPはFunction Callingと関連が深いToolsだけでなく、次の機能も扱います。
| 機能 | 役割 | 使用例 |
|---|---|---|
| Tools | 外部の処理を実行する | データベース検索、API呼び出し |
| Resources | データや情報を提供する | ファイル内容、DBスキーマ |
| Prompts | 再利用可能なプロンプトを提供する | コードレビュー用テンプレート |
つまり、MCPは単純な関数呼び出しだけの仕組みではありません。
AIが外部システムの機能やコンテキストを利用するための共通インターフェースだと理解するとわかりやすいでしょう。
4. PythonでMCPサーバーを作ってみる
今度は、Function Callingの例と同じ在庫取得処理を、MCPサーバーとして公開してみます。
ここでのポイントは、AIモデル側のコードを実装しなくても、MCPサーバーを作成できるという点です。
① MCP SDKをインストール
pip install "mcp[cli]"
② MCPサーバーを作成
server.py を作成します。
from mcp.server import MCPServer
# MCPサーバーを作成
mcp = MCPServer("InventoryServer")
# 仮の商品データベース
products = {
1001: {"name": "ノートPC", "stock": 15},
1002: {"name": "マウス", "stock": 30},
1003: {"name": "キーボード", "stock": 8},
}
@mcp.tool()
def get_stock(product_id: int) -> dict:
"""商品IDを指定して商品名と在庫数を取得する"""
product = products.get(product_id)
if product is None:
return {"error": "商品が見つかりません"}
return {
"product_id": product_id,
"name": product["name"],
"stock": product["stock"]
}
if __name__ == "__main__":
mcp.run()
これだけで、MCPサーバーとしてツールを公開できます。
なお、このサンプルはMCP Python SDK v2系のAPIを使用しています。v1系では FastMCP を使う書き方が一般的です。
③ MCPサーバーをテストする
MCP Inspectorを使用して、サーバーの動作を確認できます。
mcp dev server.py
Inspectorから get_stock というツールを選択し、以下の引数を指定します。
{
"product_id": 1001
}
すると、次のような情報が取得できます。
{
"product_id": 1001,
"name": "ノートPC",
"stock": 15
}
Function Callingと何が違う?
Function Callingの例では、AIに渡す関数のスキーマを手動で定義していました。
一方、MCPでは以下のコードに注目してください。
@mcp.tool()
def get_stock(product_id: int) -> dict:
MCP SDKがPythonの型ヒントやDocstringをもとに、ツール情報を生成します。
MCPクライアントは tools/list によって利用可能なツールを取得でき、tools/call によって実行できます。
つまり、MCPサーバーを利用する側は、個々のツールの定義を毎回手動で書く必要がありません。
ただし、MCPサーバーを作成しただけで、AIが自動的にツールを選択して実行するわけではありません。
AIアプリケーション側で、モデルとの連携やツールの実行制御を行う必要があります。
5. Function CallingとMCPを組み合わせるとどうなる?
ここが今回の記事で最も重要な部分です。
Function CallingとMCPを組み合わせることで、AIモデルによるツール選択と、外部ツールとの標準化された通信を分離できます。
具体的には、以下のような構成です。
処理の流れを順番に見てみましょう。
STEP 1:MCPクライアントがツールを取得する
AIアプリケーションはMCPサーバーに接続し、利用可能なツールを取得します。
例えば、次のような情報です。
{
"name": "get_stock",
"description": "商品IDから在庫を取得する",
"inputSchema": {
"type": "object",
"properties": {
"product_id": {
"type": "integer"
}
},
"required": ["product_id"]
}
}
STEP 2:AIモデルに利用可能なツールを渡す
AIアプリケーションは、取得したツール情報をFunction Calling用の形式に変換して、モデルに渡します。
STEP 3:AIが使用するツールを判断する
ユーザーが次のように入力します。
商品ID 1001の在庫を教えて
AIは、次のようなツール呼び出しを生成します。
{
"name": "get_stock",
"arguments": {
"product_id": 1001
}
}
STEP 4:MCPクライアントがMCPサーバーへ実行を依頼する
AIアプリケーションはMCPを使用し、取得した関数名と引数をMCPサーバーに渡します。
STEP 5:MCPサーバーが処理を実行する
MCPサーバーは必要に応じてデータベースなどにアクセスし、処理結果を返します。
STEP 6:AIが回答を生成する
AIアプリケーションがツール実行結果をモデルに渡し、最終的な回答を生成します。
商品ID 1001の「ノートPC」は、現在15個の在庫があります。
つまり、どういう関係なのか?
この構成では、次のような役割分担になります。
- Function Calling: AIモデルが利用するツールと引数を決定する
- MCPクライアント: MCPサーバーからツール情報を取得し、実行を依頼する
- MCPサーバー: 実際の処理を実行して結果を返す
- AIアプリケーション: それぞれを連携させ、処理全体を制御する
なお、OpenAI APIなどにはMCPサーバーと直接連携するための組み込みツールもあります。その場合、上記の橋渡し処理の一部をAPI側に任せることができます。
そのため、Function CallingとMCPを必ず自分で組み合わせる必要があるわけではありません。
6. Function Callingだけではダメなのか?
結論から言うと、Function Callingだけでも問題ありません。
例えば、Laravelで開発したWebシステムにAIチャットを追加するとしましょう。
ユーザーが、
「会員ID 1234のポイント残高を教えて」
と質問すると、AIが get_user_points を呼び出し、Laravel側でデータベースからポイント残高を取得する仕組みです。
このようなケースで、利用するツールが少なく、特定のアプリケーションだけで完結するのであれば、Function Callingだけでも十分です。
一方、同じ会員情報取得機能を複数のAIアプリケーションから利用したい場合、MCP化するメリットが生まれます。
例えば、
- 社内向けAIチャット
- 開発者向けAI Agent
- 管理画面のAIアシスタント
これらから共通のMCPサーバーを利用するようにすれば、ツールの公開方法を統一できます。
使い分けの目安
| 開発するシステム | 推奨する構成 |
|---|---|
| 小規模なAIチャット | Function Calling |
| 既存アプリ内だけで利用するAI機能 | Function Calling |
| 複数のAI Agentで共有するツール | MCP |
| 社内システムへの共通アクセス基盤 | MCP |
| 多数の外部サービスを操作するAI Agent | MCP + Function Callingなど |
| MCP対応のAI開発ツールとの連携 | MCP |
MCPにはサーバーの運用、接続管理、認証・認可などの考慮事項もあります。
そのため、シンプルなアプリケーションに無理に導入する必要はありません。
7. MCPを使えばAI Agentになるのか?
ここも誤解しやすいポイントです。
MCPサーバーを接続しただけでは、必ずしもAI Agentになるわけではありません。
AI Agentは一般に、与えられた目的に対して、必要な処理を判断し、ツールを利用しながらタスクを進めるシステムを指します。
例えば、ユーザーが次のように依頼した場合です。
「在庫が10個未満の商品を調べて、担当者にSlackで通知して」
AI Agentは、次のような処理を行います。
この処理では、AIが複数のツールを組み合わせながらタスクを進めています。
Function Callingは、各ステップで必要なツールを選択するために利用できます。
MCPは、在庫検索ツールやSlack送信ツールを共通の方法で利用するために活用できます。
また、AI Agentには、これらの仕組み以外にも、状態管理、エラー処理、実行回数の制御、権限管理などが必要です。
特にSlackへの送信など、外部に影響を与える処理では、実行前の確認や許可の仕組みを設けることが重要です。
8. 実務でMCPを導入する場合の注意点
MCPを利用すると外部ツールを簡単に接続できる一方、セキュリティ設計が重要になります。
例えば、データベースに接続するMCPサーバーを構築する場合、AIから任意のSQLを実行できるようにするのは危険です。
以下のような設計を検討する必要があります。
- 最小権限: データ参照だけなら読み取り専用のDBユーザーを使用する
- 入力値の検証: AIが生成した引数も信用せず検証する
- 操作の制限: 更新・削除系のツールは対象や操作内容を制限する
- ユーザー認可: 実行ユーザーごとのアクセス可能範囲を確認する
- 実行ログ: 誰がどのツールを実行したか記録する
- 外部サービスの検証: 信頼できるMCPサーバーだけを接続する
MCPはツールとの通信を標準化するプロトコルであり、業務上の権限制御や安全性を自動的に保証するものではありません。
Function Callingも同様です。
AIが呼び出しを要求したからといって、その処理を無条件に実行してはいけません。
この点は、本番環境でAI Agentを構築する際に特に意識したいところです。
9. まとめ
今回は、Function CallingとMCPの違いと関係性について解説しました。
最後に、それぞれの役割を整理します。
| 技術 | 一言で説明すると |
|---|---|
| Function Calling | AIが適切な関数と引数を選ぶ仕組み |
| MCP | AIアプリと外部ツールを接続する共通プロトコル |
| MCPサーバー | 外部ツールやデータを公開するプログラム |
| MCPクライアント | MCPサーバーと通信するコンポーネント |
| AI Agent | AIがツールを活用しながら目的達成に向けて処理を進めるシステム |
一番覚えておきたいのは、次の関係です。
Function Callingは「何を呼び出すか」を決める仕組み。
MCPは「外部の機能をどう公開し、どう接続して利用するか」を標準化する仕組み。
両方を組み合わせれば、AIによる柔軟なツール選択と、外部システムとの再利用可能な接続を実現できます。
ただし、MCPはFunction Callingの上位互換でも代替品でもありません。
小規模なAI機能ならFunction Callingだけで十分なこともありますし、共通ツール基盤を構築するならMCPが有効です。
これからAI Agentを開発する場合は、両者を別の役割を持つ技術として理解し、システムの規模や要件に合わせて使い分けるとよいでしょう。
参考資料
※本記事は2026年10月時点の仕様を参考にしています。Pythonのサンプルは学習用の最小構成です。ライブラリのバージョンによりAPIが異なる場合があります。