Function Calling（Tool Use、ツール呼び出し）とは、LLMが外部の関数やツールを「この関数をこの引数で実行したい」という構造化された形式で指定できるようにする仕組みです。 LLM単体では外部のシステムを動かせませんが、Function Callingを通じて検索、計算、データベース照会、システム操作といった実作業につながります。 AIエージェントの基盤になる、いちばん土台側の機能です。
Function Callingとは何か
LLMの出力は、本来ただのテキストです。 「東京の今日の天気は？」と聞いても、モデルは学習時点の知識から、それらしい文章を作ることしかできません。 最新の天気を答えるには、天気APIを呼ぶ必要がありますが、モデル自身はAPIを実行できません。
Function Callingは、この隙間を埋めます。 アプリケーション側が「こういう関数が使えます」という定義をあらかじめモデルに渡しておくと、モデルは必要に応じて「get_weather関数を、場所=東京という引数で呼びたい」という意図を、プログラムで処理できる形式（JSON）で返すようになります。 アプリケーションがその指示どおりに実際のAPIを実行し、結果をモデルに戻すと、モデルは結果を踏まえた回答を作ります。
この機能は2023年6月にOpenAIが「Function Calling」としてAPIに追加し、その後AnthropicやGoogleも同種の機能を提供しています。 Anthropicは同じ仕組みを「Tool Use」と呼びます。 名前は違いますが、モデルにツール定義を渡し、モデルが呼び出し意図を構造化して返す、という骨格は共通で、主要なLLMプラットフォームで標準的に使える機能になっています。
重要なのは、モデルは関数を実行しないという点です。 モデルが返すのは「呼びたい」という宣言だけで、自作したツールを実際に実行するのは常にアプリケーション側です。 何を実行させるか、実行してよいかの最終判断は、アプリケーションを作る側が握っています。 この分担が、後述する安全設計の土台になります。
仕組み
Function Callingの1回のやりとりは、4つのステップで進みます。
- ツール定義を渡す：アプリケーションがモデルへのリクエストに、使える関数の一覧を添えます。各関数には、名前、何をする関数かの説明文、受け取る引数の型（JSONスキーマ）を付けます
- モデルが呼び出しを宣言する：モデルはユーザーの依頼を読み、ツールが必要だと判断すると、関数名と引数をJSONで返します。必要なければ普通の文章で答えます
- アプリケーションが実行する：返ってきた関数名と引数を受けて、アプリケーションが実際の処理（API呼び出し、DB検索など）を実行します
- 結果を返して回答を得る：実行結果をモデルに送り返すと、モデルが結果を踏まえた最終回答を作ります。さらに別のツールが必要なら、モデルは次の呼び出しを宣言します
このステップ2〜4を、目標が達成されるまで繰り返すループにしたものが、AIエージェントです。 「計画を立て、ツールを実行し、結果を見て次を決める」というエージェントの動作は、Function Callingの連続呼び出しにほかなりません。 エージェントの解説で必ずこの言葉が出てくるのは、そのためです。
混同されやすい用語との関係
- 構造化出力（Structured Output）：モデルの出力を指定したJSONスキーマに従わせる機能です。Function Callingの引数も構造化された出力ですが、用途が違います。ツールを呼ばせたいならFunction Calling、回答自体を決まった形式のデータで受け取りたいなら構造化出力、と使い分けます
- MCP（Model Context Protocol）：ツールをどう定義し、どう配布し、どう接続するかをアプリケーションの外側で標準化した規格です。Function Callingが「モデルがツールを呼ぶ手の動かし方」だとすれば、MCPは「道具箱の規格」にあたります。MCPで接続したツールも、最終的にはFunction Callingの仕組みで呼び出されます
- RAG（検索拡張生成）：外部の文書を検索して回答に使う手法です。モデルが必要なときに自分で検索ツールを呼ぶ構成のRAGでは、Function Callingが実装手段になります
実務での使いどころと注意点
自社システムとLLMをつなぐ場面が、Function Callingの主戦場です。 在庫を照会して答えるチャットボット、問い合わせ内容から顧客レコードを引くサポート画面、自然文の指示で社内の帳票を作る業務ツールなど、「AIがその場の判断で社内のデータや機能を使う」という要件の多くは、この仕組みの上に実装されます。 既製のAIアプリにつなぐだけならMCPで足りることが多く、自社サービスの中にAI機能を組み込むときに、SDK経由でFunction Callingを直接扱うことになります。
実装上の注意点は4つあります。
- 説明文の質が精度を決める：モデルは関数の説明文と引数名だけを頼りに、どのツールをいつ使うかを判断します。曖昧な説明は誤った呼び出しに直結するため、ツール定義の説明文は人間向けドキュメントと同じ水準で書きます。精度が出ないときに直すべきは、モデルよりも先に説明文です
- 引数は検証してから実行する：モデルが生成する引数は、形式が正しくても中身が誤っていることがあります。存在しないIDや範囲外の値をそのまま実行しないよう、通常のAPI開発と同じ入力検証を挟みます
- ツールを増やしすぎない：使えるツールが多いほど、モデルの選択は不正確になります。数十個を一度に渡すより、用途ごとに絞って渡す方が安定します
- 危険な操作には承認を挟む：削除、送金、外部送信のような取り返しのつかない操作は、モデルの宣言を即実行せず、人間の確認を挟む設計にします。実行権がアプリケーション側にあるからこそ、この安全弁を仕込めます
開発投資の目線で見ると
Function Callingそのものは、主要LLMに標準で付いてくる機能であり、機能自体への追加料金はありません（ツール定義や実行結果はトークンとして課金対象になります）。 工数がかかるのはその先で、どの社内機能をツールとしてAIに開放するか、どの権限で実行させるか、誤呼び出しをどう検知するか、という設計と運用の部分です。
AI機能の開発を発注・検討する立場では、「AIと社内システムの連携」と聞いたら、その実態はツール定義と権限設計の集まりだと理解しておくと、見積もりの妥当性を判断しやすくなります。 つなぐこと自体は難しくなくなった今、価値を分けるのは、何をどこまでAIに委ねるかという業務側の設計です。
関連して読める記事
Function Callingは、AIエージェントの動作の土台であり、MCPで接続したツールも最終的にはこの仕組みで呼ばれます。AIエージェントやMCP、AI駆動開発の全体像とあわせて読むと、AIと社内システムの連携が理解しやすくなります。
AI駆動開発（AIDD）とは？従来の開発との違いと導入の考え方
AI駆動開発（AIDD）とは、生成AIを開発工程の主役に置き、人間が方針決定と検証を担う開発スタイルです。コード補完との違い、開発工程がどう変わるか、導入の順序と注意点を解説します。
2026年7月25日
MCP（Model Context Protocol）とは？仕組みとできること
MCP（Model Context Protocol）とは、AIアプリと外部ツールをつなぐオープンな共通規格です。ホスト、クライアント、サーバの仕組みと、社内システム接続での使いどころ、セキュリティ上の注意点を解説します。
2026年7月25日
AIエージェントとは？チャットボットとの違いと業務での使いどころ
AIエージェントとは、目標を与えるとAIが計画とツール実行を繰り返して作業を完了させるシステムです。チャットボットとの違い、LLMとツールとループという仕組み、業務での注意点を解説します。
2026年7月25日