Function Calling完全ガイド2026｜LLMをアクション可能にする中核技術とAIエージェント実装

Function Calling（ツール呼び出し）とは｜LLMをアクション可能にする中核技術

Function Calling（ツール呼び出し、Tool Use）とは、LLM（大規模言語モデル）に「特定の関数・APIを呼び出す」能力を与える仕組みのことです。LLM単体は本質的に「次に来る単語を予測するテキスト生成器」ですが、Function Callingを使うと「ユーザーの依頼を読み取り、どの関数をどんな引数で呼べば良いか決定し、関数の実行結果を踏まえて応答を返す」というアクション可能なシステムに変わります。AIエージェントの根幹技術であり、2026年の生成AI実装で最も重要な概念の1つです。

renueでは広告代理AIエージェント・AI PMOエージェント・Drawing Agentなど複数のAIエージェント事業を運営する立場から、「Function Callingを使いこなせるかどうかで、エージェントの実力が決まる」という現実を実体験から把握しています。本記事ではFunction Callingの仕組み、OpenAI/Anthropic実装の違い、設計パターン、よくある落とし穴、renue独自視点の実務知見を体系的に解説します。

Function Callingの仕組み｜LLMは関数を実行しない、決めるだけ

重要な誤解を最初に解消しておきます。LLM自体は関数を実行しません。LLMが行うのは「どの関数を、どんな引数で呼ぶべきか」を構造化された出力(典型的にはJSON)で示すことだけです。実際の関数実行はアプリケーション側が行い、結果を再びLLMに渡して最終応答を生成させます。

典型的な処理フロー:

開発者が「使える関数のリスト」(tools/functions)をLLMに渡す
ユーザーが「東京の天気を教えて」と質問する
LLMが「get_weather(city="Tokyo") を呼ぶべき」と判断し、構造化出力で返す
アプリケーションがその関数を実行し、結果("Tokyo: 18°C, 晴れ")を取得
結果をLLMに渡し、「東京は晴れで18度です」という自然言語応答を生成させる

このループによって、LLMは「外部システムにアクセスできる」「リアルタイム情報を取得できる」「業務システムを操作できる」存在に変わります。これがAIエージェントの根幹です。

OpenAI vs Anthropic vs Google｜主要LLMのFunction Calling実装比較

項目	OpenAI (GPT-5など)	Anthropic (Claude)	Google (Gemini)
呼称	Function Calling / Tools	Tool Use	Function Calling
関数定義の渡し方	`tools`パラメータ・JSON Schema	`tools`配列・JSON Schema	`tools`パラメータ・OpenAPI互換
結果の返却	assistant message の tool_calls	tool_use コンテンツブロック(id付き)	functionCall content part
結果の戻し	tool roleのメッセージ	tool_result コンテンツブロック(tool_use_idで紐付け)	functionResponse content part
並列呼び出し	○ Parallel Function Calling	○ 並列ツール呼び出し	○ 並列対応
強制呼び出し	`tool_choice: "required"`	`tool_choice: {"type": "tool", "name": "..."}`	`tool_config: ANY`
JSON出力強制	`response_format`	tool_use経由で実現	`response_mime_type`
互換性ラッパー	—	OpenAI互換モード提供	OpenAI互換エンドポイント提供

形式は似ていますが、コンテンツブロックのID紐付けや戻し方の流儀が微妙に異なります。マルチLLM対応する場合は、LangChain・Vercel AI SDK・LiteLLMなどのラッパーを使うか、各社のSDKを抽象化レイヤーで包むのが現実解です。

Function Callingで実現できる典型ユースケース

外部APIアクセス: 天気・株価・ニュース・地図など、リアルタイム情報の取得
業務システム操作: CRM/ERP/SaaSへの読み書き(Salesforce/Slack/Notion/Gmail等)
データベース検索: 自然言語クエリをSQLやベクトル検索クエリに変換
計算・データ処理: Python/JavaScriptの関数を呼び出して計算実行
ファイル操作: ドキュメント生成・PDF処理・画像変換
マルチステップエージェント: 複数ツールを連鎖呼び出しして複雑なタスクを完遂
RAG検索結果の取得: 「関連情報を検索→回答生成」の連鎖
確認フローと承認: 「メール送信前にユーザー承認を得る」など

マルチステップツール呼び出し｜ReAct パターンの実装

1回のLLM呼び出しで完結しない複雑なタスクでは、ReAct (Reason + Act) パターンが標準です。これは「推論→ツール呼び出し→結果観察→次の推論」を繰り返すループで、エージェント動作の基本形です。

ReActループの典型例:

Thought: LLMが「ユーザーは東京と大阪の天気を比較したいので、両方の情報が必要」と推論
Action: get_weather("Tokyo") を呼び出し
Observation: "Tokyo: 18°C 晴れ" を取得
Thought: 「次は大阪を調べる必要がある」
Action: get_weather("Osaka") を呼び出し
Observation: "Osaka: 20°C 曇り" を取得
Final Answer: 「東京は18°C晴れ、大阪は20°C曇りです」

LangGraph/Mastra/CrewAI 等のフレームワークはこのReActループを抽象化して提供しており、複雑なエージェント実装を容易にします。

renueの視点｜AIエージェント本番運用で見えた7つの実務原則

renueでは複数のAIエージェント事業を本番運用する中で、Function Callingについて次の7つの実務原則を確立しています。

(1) ツールの粒度設計が運用品質を決める: 関数の数を増やしすぎるとLLMが選択を誤りやすくなり、少なすぎると1つの関数に過剰なロジックが集中します。5〜15個を目安に整理し、関数名・引数・説明を明確にすることが重要です。

(2) 説明文(description)はLLMの判断材料そのもの: ツール定義の説明文は、開発者向けではなくLLM向けに書きます。「何のための関数か」「いつ呼ぶべきか」「呼ぶべきでないケース」を明示するのが鉄則です。

(3) 破壊的操作には必ず人間承認を挟む: メール送信、データ削除、課金処理、決済実行などの取り返しのつかない操作は、最初から完全自動化せず、ユーザー承認のステップを挟む設計にします。安定運用が確認できてから段階的に自動化を進めます。

(4) Function呼び出しもログ・トレースの対象: どのツールが、どんな引数で、何を返したかを構造化ログとして保存します。Langfuse/LangSmith等のObservabilityツールに統合するのが現実解です。

(5) ツール呼び出しの失敗時の挙動を設計: APIエラー・タイムアウト・認証失敗などの失敗ケースを、エージェントがどう扱うかを設計します。「失敗をLLMに伝えてリトライさせる」「ユーザーにエラーを伝える」「フォールバック処理」など複数の方針を使い分けます。

(6) コスト最適化のためのキャッシング: 同じ引数で同じ結果を返すツール(天気予報など)はキャッシュすることで、API呼び出しコストとレイテンシを大幅に削減できます。

(7) ツール権限の最小化: エージェントに渡す関数の権限スコープは最小化します。「メール送信」のツールも「特定のドメインだけ送信可能」「テンプレート使用必須」など制約を入れます。生成AIセキュリティの観点でも必須です。

Function Callingでよくある失敗パターン

失敗1: ツールが多すぎる — 30個も関数を渡すとLLMの選択精度が落ちる。役割別にエージェントを分割すべき
失敗2: 説明文が開発者向け — LLMが理解できない技術用語ばかりで、適切な関数選択ができない
失敗3: 引数バリデーション不足 — LLMが間違った型/値を生成しても通ってしまい、システムエラーになる
失敗4: 無限ループ — エージェントが終了条件なしにツール呼び出しを繰り返す。最大ループ回数の設定が必須
失敗5: 並列呼び出しの依存関係を無視 — 実は順序依存があるツールを並列実行してしまう
失敗6: 例外時のリカバリ未設計 — APIエラー時にエージェント全体が止まる
失敗7: 監視なしで本番投入 — どのツールがどれだけ呼ばれているか分からず、コスト爆発や品質劣化に気付けない

主要なFunction Callingフレームワーク

フレームワーク	提供企業	特徴
LangChain / LangGraph	LangChain Inc.	マルチLLM対応・エージェントオーケストレーション標準
LlamaIndex	LlamaIndex	RAG特化・データ接続が豊富
Mastra	Mastra	TypeScript エージェントフレームワーク
CrewAI	CrewAI	マルチエージェント協調
AutoGen	Microsoft	Pythonベースのマルチエージェント
Semantic Kernel	Microsoft	.NET/C# 中心、エンタープライズ向け
NeMo Agent Toolkit	NVIDIA	Reactパターン特化
Vercel AI SDK	Vercel	TypeScript・Next.js連携・streaming対応
OpenAI Agents SDK	OpenAI	OpenAI公式エージェント実装
LiteLLM	LiteLLM	マルチLLMラッパー・統一API

MCP (Model Context Protocol) との関係

Function Callingと並んで、2024年にAnthropicが提唱した MCP(Model Context Protocol) もAIエージェントツール連携の標準化で重要です。MCPは「LLMとツールを接続する標準プロトコル」で、Function Callingが各社個別実装なのに対し、MCPはツール提供側が一度実装すれば多くのLLMから使えるようになります。

2025〜2026年にかけて、Anthropic以外のLLMプロバイダもMCPサポートを進めており、「Function Callingで個別実装」から「MCPで標準化された接続」に徐々に移行が進む見通しです。renueでは両方の方式を併用しながら、MCPベースの設計に段階的にシフトしています。

よくある質問（FAQ）

Q1. Function CallingとAIエージェントは同じものですか？

Function Callingは「LLMが関数呼び出しを決定する技術」で、AIエージェントは「Function Callingを含む複数の技術を組み合わせて自律的にタスクを実行するシステム」です。Function CallingはAIエージェントの根幹技術ですが、それだけでは完結しません。

Q2. どのLLMが Function Calling に最も強いですか？

OpenAI GPT-5/Claude Sonnet 4.6/Gemini 2.5 Pro はいずれも高品質ですが、複雑なツール選択では Claude が信頼性で評価されることが多いです。コスパなら Gemini Flash-Lite、汎用なら GPT-5 が選ばれる傾向があります。

Q3. ツール定義はLLM呼び出しのたびに渡す必要がありますか？

はい、各リクエストでツール定義を含める必要があります。プロンプトキャッシング機能を使うと、同じツール定義の再送コストを削減できます。

Q4. 関数呼び出しの順序を制御できますか？

明示的な順序制御はLLM任せですが、システムプロンプトで「この順番でやって」と指示する、あるいは明示的なワークフロー(LangGraph等)を組むことで制御できます。

Q5. renueはFunction Calling/AIエージェントの実装支援を提供していますか？

はい、renueは複数のAIエージェント事業を本番運用してきた実体験を活かし、Function Calling設計、ツール粒度設計、ReAct/MCPベースのエージェント実装、Observability統合、本番運用ガードレール設計までを一気通貫で支援しています。

Function Calling・AIエージェント実装のご相談はrenueへ

renueは広告代理AIエージェント・AI PMOエージェント・Drawing Agentなど複数のAIエージェントを本番運用してきた技術コンサルティング企業です。Function Calling設計、ツール粒度設計、ReAct/MCPベースのエージェント実装、本番運用ガードレール、Observability統合、コスト最適化などをご検討の方はお気軽にお問い合わせください。