【ざっくり理解】LLMのFunction Callingはどこから来たのか？ ─ ReActからMCP・AIエージェントまで

Posted at 2026-10-04

はじめに

最近は「AIエージェント」や「MCP」という言葉をよく見かけます。その土台の一つが、LLMに外部ツールを選ばせる Function Calling（Tool Use） です。

今では多くのLLM APIで利用できますが、最初から現在の形だったわけではありません。

Function Calling以前は、どうやってLLMにツールを使わせていたのか
ReActとFunction Callingは、どのような関係にあるのか
Function Calling、Structured Outputs、MCP、AIエージェントは何が違うのか

本記事では、この3点を中心に時系列で整理します。

先に結論を書くと、LLMが出した命令を外部プログラムが実行する考え方はFunction Calling以前からあり、Function Callingはその受け渡しをAPIで扱いやすい構造化形式にしたものと捉えると分かりやすそうです。MCPはその単純な置き換えではなく、AIアプリケーションと外部のツールやデータを接続する側を標準化します。

※本記事は技術史の入口をつかむための整理メモです。論文はarXiv初版日、製品やAPIは公式発表日、ライブラリは公開リポジトリの作成日など、確認できた節目を使っています。各技術が直接影響し合ったと公式資料が説明していない箇所は、筆者による整理として記載しています。情報は2026年10月3日時点で確認しました。

※本記事の図は、論文・公式ドキュメント・公式発表をもとに筆者が独自に作成したものであり、各社・各団体の公式図ではありません。

まず前提：カスタム関数はLLMの外側で実行される

Function Callingという名前から、LLM自身が関数を実行するように見えるかもしれません。カスタム関数を使う一般的な構成では、役割を次のように分けます。

アプリケーションが、利用できるツールの名前・説明・引数スキーマをモデルへ渡す
モデルが、呼び出すツールと引数を構造化して返す
アプリケーションが引数を検証し、外部APIや関数を実行する
実行結果をモデルへ返す
モデルが最終回答、または次のツール呼び出しを返す

モデルが返す呼び出し内容を単純化すると、次のような形です。

{
  "name": "get_weather",
  "arguments": {
    "city": "Tokyo",
    "unit": "celsius"
  }
}

Function Callingの要点は、ツール名と引数を、自然文よりもプログラムで検証・処理しやすい形で受け取ることにあります。

ただし、構造化されていれば内容も正しいとは限りません。存在しないID、不適切な値、権限外の操作が指定される可能性は残ります。アプリケーション側で、型、値、認証・認可、実行対象を検証する必要があります。

また、現在のLLM APIには、検索やコード実行などをプロバイダー側で実行する組み込みツールもあります。本記事では、アプリケーションが実行を担当するカスタム関数を中心に扱います。

前史：インテントとスロットにも似た分け方があった

LLM以前の音声アシスタントやチャットボットでは、ユーザーの発話を次のように分けて扱う設計が使われていました。

インテント（意図）：ユーザーが何をしたいか
スロット（値）：処理に必要な場所、日時、数量など

たとえば「明日の東京の天気は？」という発話を、次のように解釈します。

GetWeather(location=東京, date=明日)

これは「処理の種類」と「処理に必要な値」を分ける点で、Function Callingの関数名と引数に通じます。

一方、従来のシステムでは、開発者がインテント、スロット、エンティティ、学習フレーズなどを事前に設計・登録するのが一般的でした。LLMを使ったFunction Callingでは、ツールの説明とスキーマから、どのツールをどの引数で使うかをその場で判断させやすくなりました。

同じ仕組みではありませんが、自然文から実行可能な命令を取り出すという課題は、LLM以前から続いていると整理できます。

ざっくり年表

年月	節目	本記事での位置づけ
2021年12月	WebGPTのarXiv初版	モデルがブラウザ操作コマンドを出し、環境が実行する研究例
2022年5月	MRKL SystemsのarXiv初版	LLMをルーターとして外部モジュールへ処理を振り分ける構成
2022年10月	ReActのarXiv初版	ReasoningとActingを交互に行う軌跡を提示
2022年10月	LangChain公開リポジトリ作成	LLM、ツール、エージェントを組み合わせる実装基盤の一例
2023年2月	ToolformerのarXiv初版	API呼び出しをモデルの能力として自己教師あり学習する研究
2023年3月	ChatGPT Plugins発表	OpenAPI仕様と説明を使って外部サービスへ接続する製品例
2023年6月	OpenAI Function Calling発表	関数定義と呼び出し結果をAPI上の構造として扱う
2023年11月	OpenAI DevDay	`tools`インターフェースと並列Function Callingを案内
2023年12月	Gemini API公開	GoogleのモデルAPIでもFunction Callingを提供
2024年5月	Claude Tool UseがGA	Claude 3モデル群でTool Useを正式提供
2024年8月	OpenAI Structured Outputs発表	指定したJSON Schemaへの準拠を強化
2024年11月	MCP発表	AIアプリケーションと外部システムの接続方法をオープンなプロトコルとして提示
2025年3〜5月	OpenAI Agents SDK / Responses APIのMCP対応	Agent向け実行基盤からMCPサーバーを利用する流れが拡大
2025年12月	MCPをAAIFへ寄贈	Linux Foundation傘下で中立的なガバナンスを目指す体制へ

これは一本の技術が直線的に進歩した年表ではありません。研究、モデル学習、API、ライブラリ、接続プロトコルという異なる層の出来事を並べています。

2021〜2022年：テキストで「次の行動」を出す

WebGPT：モデルがブラウザ操作コマンドを出す

OpenAIのWebGPT論文は、2021年12月17日にarXivへ初版が投稿されました。

WebGPTでは、モデルが検索、リンクのクリック、ページ内検索、引用などの操作を選び、ブラウザ環境から得た情報をもとに回答します。モデルが外部環境への命令を出し、環境側が実行する構成を確認できる代表例です。

MRKL：LLMを外部モジュールへつなぐ

AI21 LabsらのMRKL Systems論文は、2022年5月1日にarXivへ初版が投稿されました。

MRKLは、LLMと計算機、データベース、知識ベースなどの外部モジュールを組み合わせるモジュール型アーキテクチャを提案しました。現在の「LLM＋ツール群」を考えるうえで参考になる早い時期の研究です。

ReAct：考えることと行動することを交互に進める

ReAct論文のarXiv初版は2022年10月6日です。ReActは Reasoning（推論）とActing（行動）を交互に生成する方法を示しました。

イメージを単純化すると、次のような流れです。

Thought: 東京の今日の天気を調べる必要がある
Action: search["東京 天気 今日"]
Observation: 検索結果が返る
Thought: 必要な情報がそろった
Answer: 検索結果をもとに回答する

この形式では、環境側がAction:の内容を読み取り、ツールを実行してObservation:を返します。書式が崩れたり、存在しないツール名や不正な引数が出たりすると、パースや実行に失敗します。

ReActはFunction Callingの直接の起源だと公式に位置づけられているわけではありません。ただし、現在のエージェントに近い考える → 行動する → 結果を見るというループを理解する代表例です。

LangChain：エージェント実装を試しやすくする

LangChainの公開GitHubリポジトリは2022年10月17日に作成されました。LLM、ツール、エージェントを組み合わせる実装基盤が広がっていく時期の一例として位置づけられます。

この時期は、LLMに行動を選ばせることはできるが、受け渡し形式の安定性は実装側に委ねられていたと整理できます。

2023年前半：ツール利用をモデルや製品へ組み込む

Toolformer：API呼び出しを学習対象にする

Meta AIのToolformer論文は、2023年2月9日にarXivへ初版が投稿されました。

Toolformerは、モデル自身がAPI呼び出しを含む学習データを作り、どの場面でどのAPIを呼ぶと役立つかを自己教師ありで学習する方法を提案しました。対象には計算機、検索、翻訳、カレンダーなどが含まれます。

これは、ツール利用をプロンプト上の書式だけでなく、モデルが学習できる能力として扱った研究例です。

ChatGPT Plugins：API仕様を読んで外部サービスへ接続する

OpenAIは2023年3月23日にChatGPT Pluginsを発表しました。プラグインはOpenAPI仕様と自然言語の説明などを使い、ChatGPTから外部APIへ接続する仕組みでした。

「APIの説明とスキーマをモデルへ提示し、利用するAPIを選ばせる」という製品体験が、一般の利用者にも見える形で提供された例です。

自律エージェントへの期待と難しさ

同じ時期には、Auto-GPTなど、目標からタスクを分解し、ツールを繰り返し使うプロジェクトも注目されました。

一方で、ツール選択、停止条件、エラー処理、長期タスクの状態管理は、形式を整えるだけでは解決しません。Function Callingが安定させるのは主に呼び出しの受け渡しであり、エージェント全体の判断が自動的に正しくなるわけではありません。

2023年6月以降：ツール呼び出しをAPIの構造として扱う

OpenAI Function Calling

OpenAIは2023年6月13日、Chat Completions APIのgpt-4-0613とgpt-3.5-turbo-0613でFunction Callingを発表しました。

ここで大きかったのは、次の2点です。

関数名、説明、引数をJSON Schemaに基づく定義としてAPIへ渡す
モデルが、呼び出す関数と引数をAPIレスポンス内の構造として返す

これにより、自由形式のAction:文字列をアプリケーション独自のルールで解析する方法に加えて、プロバイダーが用意したツール呼び出し用インターフェースを利用できるようになりました。

ただし、Function Callingは業界共通の一つの標準規格ではありません。各社でメッセージ形式、スキーマ対応、ツール選択の指定方法などが異なります。共通しているのは、ツールの説明と引数スキーマをモデルへ渡し、呼び出し内容を構造化して受け取るという設計パターンです。

各社へ広がったFunction Calling / Tool Use

その後、主要なモデルAPIで似た設計が提供されました。

時期	提供元	出来事
2023年11月	OpenAI	DevDayで`tools`インターフェースと並列Function Callingを案内
2023年12月	Google	Gemini APIでFunction Callingを提供
2024年5月	Anthropic	Claude 3モデル群のTool UseがGA
2024年8月	OpenAI	Structured Outputsを発表

OpenAIのtoolsは、旧functionsパラメーターとはAPI上の形も異なり、より一般的なツールを扱うインターフェースとして整理されています。

Structured OutputsはFunction Callingと同じではない

Structured Outputsは、モデル出力を開発者が指定したJSON Schemaへ準拠させるための機能です。Function Callingでも引数を厳密なスキーマへ合わせる用途に使えますが、両者の目的は同じではありません。

概念	主な役割
Structured Outputs	モデルの回答やツール引数を、指定したスキーマに合わせる
Function Calling / Tool Use	呼び出すツールと引数を構造化して返す
MCP	外部サーバーがツールやコンテキストを公開し、AIアプリケーションが発見・利用する方法をそろえる
Agent	ツール呼び出しと結果確認を繰り返し、複数ステップのタスクを進める

OpenAIのStructured Outputsではstrict: trueを指定することで、対応範囲内のJSON Schemaへの準拠を強化できます。ただし、モデルの拒否、出力上限による中断、意味的に不正な値まで自動で防げるわけではありません。スキーマ検証に加えて、業務ルールや権限の検証が必要です。

2024年11月以降：MCPは外部機能との接続をそろえる

Anthropicは2024年11月25日、Model Context Protocol（MCP）を発表しました。MCPは、AIアプリケーションと外部のデータソースやツールを接続するためのオープンなプロトコルです。公開時の最初の仕様リビジョンは2024-11-05で、発表日とは異なります。

Function CallingとMCPは、単純な新旧関係ではありません。

Function Calling / Tool Use：モデルに提示したツールのうち、何をどの引数で呼ぶかを構造化する
MCP：AIアプリケーションと外部サーバーの間で、ツールやコンテキストを公開・発見・利用する方法をそろえる
Agent：モデル呼び出し、ツール実行、結果確認を反復し、タスクを進める

実装では、MCPサーバーから取得したToolをFunction Calling用のツールとしてモデルへ渡す構成があります。この意味では、MCPを「Function Callingの周辺で接続を担う仕組み」と捉えると理解しやすいです。ただし、MCP仕様がFunction Callingを必須の内側レイヤーとして定義しているわけではありません。

MCPはToolsだけを扱うものではない

MCPサーバーは、少なくとも次の要素を公開できます。

Tools：API呼び出し、検索、計算などの実行可能な機能
Resources：ファイル、データ、スキーマなどのコンテキスト
Prompts：引数付きで再利用できるプロンプトやワークフロー

さらに、接続初期化、Capability Negotiation、通知、トランスポートなども仕様の対象です。そのため、「ツールの配り方」よりも、AIアプリケーションと外部機能・コンテキストのつなぎ方を共通化するもの、と表現する方が正確です。

OpenAIもMCPへ対応

OpenAIは2025年3月11日にResponses APIとAgents SDKを発表しました。その後、Python版Agents SDKは3月26日のv0.0.7でMCP対応を追加し、5月21日にはResponses APIのRemote MCP対応とAgents SDKのHosted MCP対応が案内されました。

MCPはAAIFへ寄贈された

2025年12月9日、AnthropicはMCPプロジェクトを、Linux Foundation傘下に新設されたAgentic AI Foundation（AAIF）へ寄贈しました。Linux Foundationの発表では、MCP、Blockのgoose、OpenAIのAGENTS.mdが創設時の寄贈プロジェクトとして挙げられています。

変わったものと、変わっていないもの

流れを振り返ると、変わったのは主にインターフェースと接続方法です。

段階	変わったもの	変わっていないもの
インテント / スロット	意図と値を定義して発話を分類	実際の処理は外部プログラムが行う
WebGPT / ReAct	モデルが行動をテキストで表現	環境側が命令を解釈・実行する
Function Calling	ツール名と引数をAPIの構造として受け取る	引数検証と副作用の管理はアプリ側に残る
MCP	外部機能の公開・発見・呼び出し方法をそろえる	接続先の信頼性や権限管理は別途必要
Agent	呼び出しと観察を複数回繰り返す	最終的な副作用は外部システムで発生する

構造化と標準化が進んでも、モデルが返した内容を無条件に実行してよいわけではありません。

信頼できるツールやMCPサーバーだけを接続する
引数、対象リソース、認証・認可を検証する
外部へ送信されるデータを確認する
書き込み、送信、削除などには人間の承認を挟む
Tool Callの成功と、業務結果の正しさを分けて確認する

この責任境界は、ツールを呼ぶ仕組みが便利になるほど重要になります。

まとめ

LLMが命令を出し、外部環境が実行する構成は、Function Calling以前のWebGPTやReActなどにも見られる
ReActは現在のエージェントに近い反復ループを理解する代表例だが、Function Callingの唯一の起源ではない
Function Callingは、ツール名と引数をAPIで扱いやすい構造として受け渡す
Structured Outputsはスキーマ準拠、MCPは外部システムとの接続、Agentは反復実行を主に担う
MCPはFunction Callingの単純な代替ではなく、Tools、Resources、Promptsなどを外部サーバーから公開・利用するためのプロトコルである
形式が安定しても、引数検証、認証・認可、人間による承認はアプリケーション側に残る

ひとことでまとめると、テキストとして行動を書かせる段階から、構造化された呼び出し、共通の接続方法、反復実行へと、異なる層が少しずつ整備されてきた歴史と整理できそうです。

参考（一次資料・公式情報）

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up