LLMは文章を生成できますが、モデルの重みだけで最新の在庫を確認したり、メールを送信したりはできません。
外部システムの情報を取得し、操作まで行うには、LLMとプログラムを接続する「道具」が必要です。
この仕組みを学ぶときに混同しやすいのが、Function Calling、MCP、Agentです。
この記事では、3つの役割と使い分けを図で整理し、安全にツールを使うための設計まで説明します。
この記事のAPI例と仕様説明は、2026年7月時点の公式ドキュメントをもとにしています。利用時は各リンクから最新仕様も確認してください。
先に3つの違いを整理する
Function Calling、MCP、Agentは、競合する選択肢ではありません。それぞれ担当する層が違います。
| 用語 | 主な役割 | 具体例 |
|---|---|---|
| Function Calling | LLMが呼び出す関数と引数を構造化する | get_inventory(product_id="A-001") |
| MCP | 道具・リソース・プロンプトを共通方式で接続する | GitHub、Slack、DBなどのMCPサーバー |
| Agent | 目標に向けて判断・実行・観察を繰り返す | 調査して結果をまとめ、承認後に通知する |
3つは競合する選択肢ではありません。たとえばAgentは、MCPで接続したツールをFunction Calling形式で呼び出せます。
Function Callingは「実行」ではなく「実行リクエスト」を作る
Function Callingでは、アプリケーションが利用可能な関数を名前、説明、入力スキーマとともにLLMへ渡します。
ユーザーが「商品A-001の在庫を確認して」と依頼すると、モデルは次のような呼び出しを返せます。
{
"name": "get_inventory",
"arguments": {
"product_id": "A-001"
}
}
重要なのは、LLM自身が在庫データベースへ接続するわけではない点です。
アプリケーションが引数を検証し、権限を確認してから関数を実行します。その結果をLLMへ返すと、LLMはユーザー向けの回答を生成します。
ここでいう「AIアプリ」とは、スマートフォンアプリやチャット画面だけを指す言葉ではありません。LLMから実行リクエストを受け取り、入力検証・権限確認・DBやAPIの実行を担当するWebサーバーやバックエンドのプログラムを指します。
OpenAIの公式ガイドでは、ツール呼び出しを次の5段階で説明しています。
- 呼び出せるツールを含めてモデルへリクエストする
- モデルからツール呼び出しを受け取る
- アプリケーション側でコードを実行する
- 実行結果をモデルへ返す
- 最終回答または次のツール呼び出しを受け取る
LLMは実行リクエストを作り、実際の検証・認可・実行はアプリケーションが担当します。
Function Callingの往復を理解する
在庫確認を例にすると、処理は次のように進みます。
- アプリが「在庫確認ツールでは商品IDを受け取る」とLLMへ伝える
- LLMが
get_inventoryとproduct_idを指定する - アプリが商品IDと利用者の権限を確認する
- アプリが在庫システムを呼び出し、結果をLLMへ返す
- LLMが「A-001の在庫は12個です」と回答する
入力スキーマを厳密にすると、モデルが生成する引数の形式を揃えやすくなります。ただし、形式が正しいことと、その操作を許可してよいことは別問題です。
商品IDの存在確認、利用者の権限、対象データ、操作回数などは、ツールを実行するアプリケーション側で検証します。
MCPはツールの接続方法を共通化する
関数をアプリケーションへ直接実装する方法は、小規模な用途では分かりやすいものです。
しかし、GitHub、Slack、Google Drive、データベースなど、接続先が増えるたびに独自のツール定義と接続処理を作ると、実装が分散します。
MCP（Model Context Protocol）は、AIアプリケーションが外部の機能や文脈へ接続する方法を標準化するプロトコルです。
MCPサーバーは、主に次の3種類を公開できます。
| プリミティブ | 役割 | 例 |
|---|---|---|
| Tools | 実行できる操作 | Issue作成、検索、メール送信 |
| Resources | 読み取るデータ | ファイル、DBレコード、APIレスポンス |
| Prompts | 再利用する指示テンプレート | 調査手順、レビュー形式 |
MCPでは、クライアントがtools/listで利用可能なツールを発見し、tools/callで実行できます。各ツールは、名前、説明、入力のJSON Schemaなどを公開します。
MCPはツールの接続規格であり、それだけでAgentになるわけではありません。接続したツールをいつ、何回、どの順番で使うかは、AIアプリケーションやAgent側が制御します。
Remote MCPを接続するときの確認項目
OpenAIのResponses APIなど、Remote MCPサーバーへ接続できるAI基盤もあります。接続時には、少なくとも次を設定・確認します。
- 接続先が信頼できるMCPサーバーか
- モデルへ公開するツールを必要最小限に絞っているか
- 送信や変更を伴う操作で実行前の承認を求めるか
- MCPサーバーへ送るデータと、その保存方針に問題がないか
「接続できること」と「安全に利用できること」は別です。認証情報、公開ツール、承認条件、送信データを接続先ごとに管理します。
ツールは「LLMが選べる」だけで「自由に実行できる」わけではない
モデルが正しい形式のツール呼び出しを生成しても、その操作が安全とは限りません。
たとえば、同じ業務システムでも操作ごとに影響が違います。
| 操作 | 基本方針の例 |
|---|---|
| 商品情報の検索 | 権限確認後に自動実行 |
| メールやSlackの下書き作成 | 自動実行して人が確認 |
| メール送信・Issue作成 | 実行直前に承認 |
| データ削除・権限変更 | 原則拒否または厳格な承認 |
モデルの判断と実際の実行の間に、認証・認可・承認を置きます。
ツール実行時には、少なくとも次を確認します。
- 誰が実行を依頼したか
- どのデータを対象にするか
- 読み取りか、外部送信か、変更・削除か
- 何件に影響するか
- 承認が必要な操作か
ツールの説明文は認可の代わりにはなりません。「管理者だけが使う」と説明しても、サーバー側の権限チェックがなければ安全にはなりません。
Agentは判断・実行・観察を繰り返す
1回のツール呼び出しだけで終わらず、複数の結果を見ながら次の行動を決める仕組みがAgentです。
たとえば「未対応の問い合わせを調べ、回答案を作って担当者へ共有する」という依頼には、複数の手順があります。
- 未対応の問い合わせを検索する
- 関連するFAQや過去事例を調べる
- 回答案を作る
- 内容を検証する
- 担当者の承認後に共有する
Agentは「次の行動を決める→ツールを実行する→結果を観察する」を、完了するまで繰り返します。
Agent向けのSDKは、モデル呼び出し、ツール実行、結果の追加、再度のモデル呼び出しというループを管理しやすくします。
ただし、SDKを使うだけで安全になるわけではありません。何を許可し、どこで止めるかはアプリケーション側で設計します。
Agentには停止条件を先に決める
Agentがツールを使えるようになると、同じ検索を繰り返す、失敗を無制限に再試行する、想定以上の費用を使うといった問題が起こり得ます。
Agentは「何をするか」だけではなく、「いつ止めるか」も実装します。
最低限、次の条件を決めます。
- 最大ターン数・最大ツール実行回数
- タイムアウト
- トークン・API・外部サービスの費用上限
- 同じ失敗を再試行する回数
- 目標を達成したと判断する条件
- 人へ引き継ぐ条件
書き込み、送信、購入、削除、権限変更などは、Agentが計画した時点ではなく、実行直前に対象と内容を表示して承認を求めます。
どこから実装すればよいか
最初から自律的なAgentを作る必要はありません。次の順番で段階的に広げると、問題を切り分けやすくなります。
- 1つの読み取りツールをFunction Callingで試す
- 入力検証、権限確認、ログ、エラー処理を追加する
- 接続先が増えたらMCPで共通化する
- 複数手順が必要な場合だけAgentループを追加する
- 送信や変更操作へ実行時承認を追加する
- 代表タスクで成功率、誤実行、手順数、費用を評価する
単純な検索や決められた処理なら、通常のコードやワークフローの方が予測しやすく、安価です。途中結果によって次の行動が変わる仕事にAgentを使います。
まとめ
3つの違いは、次のように整理できます。
- Function Calling：モデルが関数名と引数を構造化して返す
- MCP：外部のツール・リソース・プロンプトを共通方式で接続する
- Agent：目標に向けてツール実行と観察を繰り返す
どの仕組みを使っても、LLMの出力をそのまま実行するのではなく、アプリケーション側で検証、認可、承認、ログ、停止条件を実装します。
まずは読み取り専用のツールを1つ接続し、正しいツールと引数を選べるか確認します。複数手順が本当に必要になってから、Agentへ広げるのが安全です。
次回は、LLMアプリを速く安定して動かすための遅延、コスト、失敗時の設計を扱います。
シリーズ記事
「LLM・VLM実践学習」は、LLMの仕組みからアプリ開発、運用、カスタマイズ、VLMまでを順に学ぶシリーズです。
- #1 LLMは文章をどう理解して生成するのか — トークン・Transformer・Attention
- #2 LLMへ知識を与える — Embedding・ベクトル検索・RAG
- #3 LLMへ道具を使わせる — Function Calling・MCP・Agentの違い（本記事）
参考資料
- OpenAI — Function calling
- OpenAI — MCP and Connectors
- OpenAI Agents SDK — Agents
- OpenAI Agents SDK — Running agents
- OpenAI Agents SDK — Human-in-the-loop
- Model Context Protocol — Architecture overview
本記事は社内学習資料をもとに、公開向けに再検証して加筆したものです。記事内の図は、本シリーズのために作成したオリジナルの概念図です。