エージェント型AI、結局何が"エージェント"なのか整理してみた（ReAct・Function Calling・MCP）

はじめに

「AIエージェント」「エージェンティックAI」という言葉を最近あちこちで見かけますが、実際に調べてみると ReAct、Function Calling（Tool Calling）、MCP（Model Context Protocol）といった単語が次々出てきて、正直どれが何のレイヤーの話をしているのか混乱していました。

• ReActは「エージェントの一種」なのか？
• Function CallingとMCPは対立する技術なのか、それとも組み合わせるものなのか？
• そもそも「AIエージェント」の定義って何なのか？

この記事は、自分の頭を整理するために「誰が」「何のレイヤーで」「何を解決しているのか」という観点で3つを整理し直したものです。同じところで混乱している方の参考になれば幸いです。

対象読者

この記事は、以下のような方を想定しています。

• ChatGPTやClaudeなどのLLMは日常的に使っているが、「AIエージェント」「ReAct」「Function Calling」「MCP」といった単語の関係を整理できていない方
• それぞれの単語をニュースや技術記事で見聞きしたことはあるが、どのレイヤーの話なのかを説明できない方
• これからAIエージェントやMCPサーバーの実装に入る前に、全体像を掴んでおきたいエンジニアの方

逆に、各技術の詳しい実装手順や、最新のベンチマーク・性能比較の数値を知りたい方には向いていません。この記事はあくまで概念・関係性の整理が目的です。

そもそも「AIエージェント」とは何か

普通のチャットボット（生成AI）は、1回の質問に対して1回テキストを生成して終わりです。一方で「AIエージェント」と呼ばれるものは、おおむね以下のようなループを自律的に回します。

1. 目標（ゴール）を理解する
2. 今の状況を踏まえて次に何をすべきか考える（推論）
3. 必要なら外部のツールやAPIを実行する（行動）
4. 実行結果を観察し、目標が達成されたか判断する
5. 未達なら2に戻る。達成したら終了する

つまり「エージェント」という言葉自体は特定の技術を指すのではなく、LLMを中心に据えた"考える→行動する→観察する"という自律的なループの設計思想を指しています。ReAct・Function Calling・MCPは、このループを構成する別々のレイヤーの話をしている、というのが今回自分なりに整理した結論です。

大まかに対応させるとこうなります。

レイヤー	役割	該当する技術
推論パターン（どう考えるか）	ループの思考プロセスを設計する	ReAct
実行インターフェース（モデルがどうツールを呼ぶと表明するか）	モデルの出力からツール呼び出しを構造化する	Function Calling（Tool Calling）
接続の標準規格（ツールやデータソースをどう用意するか）	ツール・データソースへの接続方法を統一する	MCP

以下、それぞれ詳しく見ていきます。

ReAct：推論と行動を交互に行う「思考パターン」

ReAct（Reasoning and Acting）は、2022年10月にPrinceton大学とGoogle Research（Brain Team）の研究者らが発表した論文『ReAct: Synergizing Reasoning and Acting in Language Models』（Yao et al., 2022／ICLR 2023採択）[^react-paper]で提案された、LLMに対するプロンプティング手法・推論パターンです。

ポイントは、Chain-of-Thought（CoT）のような「考えるだけ」のプロンプティングに、外部ツールを使った「行動」を組み込んだことです。具体的には次の3ステップのループを繰り返します。

Thought: 東京の明日の天気を知る必要がある
Action: search("東京 天気 明日")
Observation: 「明日の東京は晴れ、最高気温28度」という検索結果を得た
Thought: 必要な情報が揃った。ユーザーに回答できる
Action: finish("明日の東京は晴れで、最高気温は28度の予想です")

論文発表当時は Search[...] のようなテキストベースの疑似関数呼び出しでしたが、これはあくまで当時それを表現する手段がテキストしかなかったからです。現在ではこの「Action」の部分を、後述するFunction Calling（構造化されたJSON形式のツール呼び出し）で実装するのが一般的になっています。

つまりReActは「モデルの内部で何が起きているべきか」という設計思想・振る舞いのパターンであり、それ自体が実装や製品ではない、という点が最初に押さえておきたいポイントでした。

Function Calling：ReActの「Action」を実装する手段

Function Calling（Tool Calling）は、ReActのループのうち「Action」の部分を、モデルとアプリケーションの間で安全かつ構造的にやり取りするためのAPI上の仕組みです。OpenAIが2023年6月13日に「Function calling and other API updates」として導入し[^function-calling]、その後Anthropicなど各社のAPIでも同様の機能が提供されています。

流れはシンプルです。

1. アプリ側が「使えるツール一覧」をJSON Schemaのような形式でモデルに渡す
2. モデルは自然言語で回答する代わりに、「この関数を、この引数で呼びたい」という構造化データ（JSON）を返す
3. 実際の関数実行はアプリケーション側が行う（モデル自身はコードを実行しない）
4. 実行結果をモデルに渡し、続きの推論・回答生成をさせる

例えば天気を調べるツールを定義する場合、モデルへのツール定義はこのようなイメージです。

{
  "name": "get_weather",
  "description": "指定した都市の天気予報を取得する",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "都市名" },
      "date": { "type": "string", "description": "日付（YYYY-MM-DD）" }
    },
    "required": ["city"]
  }
}

モデルはこれに対して、直接天気を答える代わりに次のような呼び出し要求を返します。

{
  "type": "tool_use",
  "name": "get_weather",
  "input": { "city": "東京", "date": "2026-09-05" }
}

ここで重要なのは、モデルは「呼びたい」と意思表示するだけで、実行主体はあくまでアプリケーション側だという点です。この「モデルが構造化された形でツール利用の意図を表明する」というインターフェースこそがFunction Callingの本質で、ReActという思考パターンを現代のAPIで実現するための具体的な実装手段、という位置づけになります。

MCP：ツールとの「つなぎ方」を標準化するプロトコル

ここまでの話だけだと「Function Callingがあれば十分では？」と思うかもしれません。実際、Function Calling自体は単一のアプリケーション内で素早くツール連携を実装するには便利です。

ただし実務でエージェントを作っていくと、次のような課題が出てきます。

• Slack、GitHub、社内DB…と連携先が増えるたびに、アプリごとに関数実装をゼロから書く必要がある
• 同じ「GitHub連携」でも、プロジェクトAとプロジェクトBで実装がバラバラになりがち
• ツールの実装ロジックとエージェントのアプリケーションロジックが密結合してしまう

これを解決するためにAnthropicが2024年11月25日に発表した[^mcp-announce]のが**MCP（Model Context Protocol）**です。AIモデルを外部のデータソースやツールに接続するための、オープンな共通規格として設計されています。

MCPは大きく3つの登場人物からなるクライアント・サーバー構造を取ります。

• MCPサーバー：Google Drive、Slack、GitHub、社内APIなど、実際にデータやツールを公開する側
• MCPクライアント：MCPサーバーに接続するAIアプリケーション側のコンポーネント
• ホスト：クライアントとサーバーを仲介するアプリケーション本体（Claude Desktopなど）

やり取りはJSON-RPCという標準プロトコル上で行われ、エージェント（モデル）は個々のツールの実装詳細を意識することなく、抽象化されたインターフェースを通じて機能を利用できるようになります[^fc-vs-mcp]。

Function CallingとMCP、結局どう違うのか

この2つはよく比較されますが、対立する技術というより抽象度が異なる、という理解が今のところ自分の中でしっくりきています。

観点	Function Calling	MCP
何のレイヤーか	モデル⇔アプリ間のツール呼び出しインターフェース	アプリ⇔外部システム間の接続プロトコル
ツールの実装場所	呼び出し元アプリケーションが個別に実装	MCPサーバー側に集約・共通化
再利用性	アプリごとに実装し直しになりがち	一度作ったMCPサーバーは他のアプリからも再利用可能
向いているケース	単一アプリ内で素早くツール連携したいとき	複数のエージェント・プロジェクトでツールを使い回したいとき
関係性	MCPサーバーとのやり取りも、内部的にはFunction Calling（Tool Calling）の仕組みを使って実現されることが多い	Function Callingを置き換えるものではなく、ツールの"配布・接続"を標準化するもの

つまりMCPは、Function Callingという仕組みそのものを不要にするわけではなく、「どんなツールをどう用意し、どう繋ぐか」という部分を標準化したものだと理解すると腹落ちしました。よく「USBやHTTPのような役割」に例えられますが、個別配線（Function Callingの個別実装）を共通の差込口（MCP）に置き換えるようなイメージです。

3つの関係をまとめると

最後に、冒頭の疑問に対する自分なりの答えを整理します。

• ReAct：エージェントが「どう考え、どう行動するか」という推論の設計パターン。技術というより思考のフレームワーク。
• Function Calling：ReActの「Action」を、現代のLLM APIで実現するための具体的な呼び出しインターフェース。実行はアプリ側の責任。
• MCP：Function Callingで呼び出す先のツール・データソースをどう用意し、どう繋ぐかを標準化するプロトコル。再利用性・保守性を高める。

「AIエージェント」というのはこれら3つ（あるいはそれ以外の仕組み）を組み合わせて実現される、自律的なループそのものを指す言葉、というのが今回の結論です。バズワードとして一括りにされがちですが、レイヤーを分けて理解すると、それぞれの技術がどんな課題を解決しているのかがクリアになりました。

参考資料

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv)
• ReAct: Synergizing Reasoning and Acting in Language Models — Google Research Blog
• ReActパターンとツール呼び出しの基礎 — Qiita
• Introducing the Model Context Protocol \ Anthropic
• Function calling and other API updates \ OpenAI
• Function Calling vs. MCP──LLMを"真のエージェント"化する仕組み比較 — Zenn
• OpenAI API における Function Calling | OpenAI Help Center