AI agentはツールをどう使うのか(Function Callingの解説)
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
AI agentは、function callingを通じてツールを使います。モデルは目の前のタスクを読み取り、与えられたツールと照らし合わせ、ツール名と渡す値を指定した構造化リクエストを出力します。アプリケーション(ホスト型ツールの場合はAIプロバイダー自身)がそのリクエストを実際のシステムに対して実行し、結果を返します。モデルはその結果を読んでから、次に何をするかを決めます。function callingは、言語モデルを、テキストを書くだけの存在から、カレンダーを確認し、CRMのレコードを更新し、返金を実行できる存在に変える仕組みです。
これはもはやニッチな機能ではありません。Gartnerは、2026年末までにエンタープライズアプリケーションの40%がタスク特化型のAI agentを搭載すると予測しています。2025年は5%未満でした。そして、そのほぼすべてのagentが、返信を生成する以上のことをするためにfunction callingに依存しています。agentを構築または購入するなら、ツール呼び出しが実際にどう動き、どこで壊れるかを理解しているかどうかが、本当に役立つagentと、デモでは見栄えがよいが本番では破綻するagentの分かれ目になります。
タスクについて語ることから、実行することへ
ツールを持たないモデルは、何が起きるべきかを説明できます。「木曜日に変更して、確認メッセージを送ることをお勧めします」といった具合です。ツールを持つモデルは、それを実現できます。カレンダーツールを呼び出して木曜日の空き状況を確認し、メッセージツールを呼び出して確認を送信し、完了したと報告します。これがチャットボットとagentの違いのすべてで、AI agentの仕組みでさらに詳しく取り上げています。知覚が推論に入力され、推論がツールを選び、ツールこそがモデルの外側で実際に何かを変えるものです。
この概念は、AIの文献ではツール利用(tool use)と呼ばれ、ベンダーによってはfunction callingとも呼ばれます。平易な定義とビジネス上の位置付けは、ツール利用とはで取り上げています。この記事は、agentを実際に運用する段階で重要になる点に焦点を絞って、もう一歩深く掘り下げます。ツール呼び出しがどう組み立てられるか、モデルがどう呼び出しを決めるか、うまくいかないときに何が起きるか、増えていくツールの集合を混乱させずにどう管理するか、です。
ツール呼び出しの構造
agentが使えるツールはすべて、どのAIプロバイダーを使っていても、基本的に同じ方法で定義されます。定義は3つの要素でできており、モデルはこの3つに入れたもの以外は何も見ません。この構造は、Anthropicのツール利用プラットフォームをはじめ、他の主要なプロバイダーすべてで一貫して文書化されています。
| 要素 | 内容 | 例 |
|---|---|---|
| 名前 | アクションを表す短い識別子 | check_order_status |
| 説明 | ツールが何をするか、いつ使うかを説明する平易な言葉 | 「注文IDで顧客の注文の現在のステータスを調べる」 |
| パラメータスキーマ | ツールに必要な正確なフィールド、その型、必須かどうか | order_id(文字列、必須)、include_history(ブール値、任意) |
モデルがツールを使うと決めても、自分でコードを実行することはありません。ツール名を指定し、パラメータを埋めた構造化オブジェクトを出力します。たとえば「order_id: 48213でcheck_order_statusを呼び出す」といったものです。あなたのシステム(ベンダー側で動作するWeb検索のようなツールの場合は、プロバイダーのホスト型インフラ)が、その呼び出しを実際の注文システムに対して実行し、同じ会話の中で結果を返します。モデルは結果を新しい情報として読み取り、続行します。知覚、推論、行動、観察のループが説明するとおりの動きです。
結果の大部分は、説明とスキーマの質で決まります。どんな種類のレコードか、どのフィールドを受け付けるかの説明がないupdate_recordというツールは、モデルにほとんど手がかりを与えません。パラメータの型が緩く、厳密な形式ではなく自由記述のdateフィールドになっているなど、誤用できるツールは、いずれ誰も想定しなかった値で呼び出されます。
モデルはツールを呼び出すかどうかをどう決めるのか
各ターンで、モデルは小さな判断を下します。このリクエストにはツールが必要か、それとも既に知っていることから答えられるか、です。返金ポリシーに関する質問は、ポリシーのテキストが既にコンテキストにあれば、直接答えられるかもしれません。特定の顧客の注文に関する質問にはツールが必要です。モデルはそのデータを知らず、調べない限り知ることもないからです。
この判断を左右する要素は2つあります。1つ目は、ツールの説明がリクエストにどれだけ合致するかです。曖昧な説明は、見送られるか誤って適用されます。2つ目は、システムプロンプトやagentの設定が、振る舞いをどう方向付けているかです。agentには、回答する前に必ずナレッジベースを確認する、必要と明示された場合にのみツールを使う、特定のシナリオでは応答する前に必ずツール呼び出しを行う、といった指示を与えられます。これはほとんどのagentフレームワークで調整可能な設定であり、固定された動作ではありません。そのため、同じ基盤モデルの上に構築された2つのagentが、ツールに手を伸ばすよう指示される強さによって、大きく異なる動きをします。
この判断の瞬間は、まさにagentのループの「推論」の部分です。AI agentの仕組みで、そのサイクル全体をより詳しく取り上げています。ここで説明しているツール選択の瞬間は、推論が行動に変わる場所です。ツールが呼び出される前に推論側で何が起きるかは、AI agentはどう推論するのかで詳しく解説しています。
単一、逐次、並列、条件付きの呼び出し
すべてのタスクが1回のツール呼び出しで済むわけではありません。実際のagentの仕事は、たいてい次の4つの形のいずれかに当てはまります。
| パターン | 動き | 例 |
|---|---|---|
| 単一の呼び出し | 1つのツールで1つのアクションを行い、完了する | 出荷の追跡番号を調べる |
| 逐次 | 各呼び出しが直前の結果に依存する | カレンダーの空きを確認し、空いている枠を予約し、招待を送る |
| 並列 | 独立した複数の呼び出しを同時に実行する | 同じ企業のファーモグラフィックデータを3つの情報源から同時に取得する |
| 条件付き | 次に実行するツールが、前のステップの結果によって決まる | 分類結果に応じて、チケットを返金ツールまたはエスカレーションツールに振り分ける |
AI Meeting Scheduler Agentのブループリントは、逐次の分かりやすい例です。空き状況の検索、予約、確認の順に、各ステップが直前のステップに依存します。AI Research Agentのブループリントは、並列と逐次の呼び出しを組み合わせて使います。複数の情報源に同時に問い合わせ、各結果を読んで次の検索を決めます。AI Support Triage Agentのブループリントは条件付きの例です。分類の結果によって、次のツール呼び出しがナレッジベースの検索、ルーティング、エスカレーションのどれになるかが決まります。
本番のブループリントにおけるツールの実際
抽象的な説明には限界があります。実際の業務で、ツールの集合がどのようなものかを見てみましょう。
AI SDR Agentは、対象アカウントのファーモグラフィックデータを取得するリサーチツール、既存の関係を確認してアウトリーチを記録するCRMツール、シーケンスを送信するメールツールを呼び出します。3つのツール、3つの異なるシステム、そして1つの一貫した仕事です。
AI Invoice AP Agentは、請求書から明細行を抽出するドキュメント抽出ツール、それを発注書と照合するベンダー検索ツール、承認済みの支払いを計上するERPツールを呼び出します。ここでの各ツール呼び出しは、実際の金銭的な影響を伴います。だからこそ、agentがそのまま連続して処理を進めるのではなく、抽出と計上の間に承認ステップが置かれています。
パターンに注目してください。agentがアクセスできるツールが、できることの上限を決め、それ以上のことはできません。読み取り専用のCRMツールを持つagentは、レコードを調べられますが、変更はできません。書き込み可能なツールを持つagentは変更できます。この境界は偶然ではなく設計上の判断であり、agentが想定外のことをしたとき、通常、最初に見直す価値があるのはここです。
ツール呼び出しが失敗したとき:エラー、リトライ、制限
ツール呼び出しは、デモが示すよりも頻繁に失敗します。よくある失敗パターンは次のとおりです。
- 誤った、または不足しているパラメータ。 モデルが、与えられていない値を推測します。曖昧なリクエストでは特に起こりがちです。よくできたagentは、重要な内容については推測せず、確認の質問をします。
- 権限エラー。 ツールは存在しますが、agentの認証情報ではその特定のアクションが許可されていません。これは安全策であり、アクセス範囲を広げて「解決」するのではなく、維持すべきものです。
- ツールが存在しない、または記憶違い。 小さくてスコープの明確なツールセットよりも、大きくて整理されていないツールセットで起こりやすくなります。
- タイムアウトと障害。 下流のシステムが遅いか停止しています。agentには、固まったり結果を推測したりしないための、定義済みのフォールバックが必要です。
規模が大きくなると、この問題は変わります。OpenAI自身のfunction callingガイドは、1ターンで利用できるツールの数を少なく、一般に20未満に保つよう推奨しています。似たように見える選択肢の中から区別しなければならない数が増えるほど、精度が下がるからです。大規模なツールライブラリが本当に必要なagentの場合、解決策はすべてをすべてのプロンプトに詰め込むことではありません。目の前のタスクに関連するサブセットだけを読み込み、モデルが圧倒されるほどの選択肢ではなく、短く関連性の高いリストから選べるようにします。
このほとんどを捉えるのが、観察ステップです。よく設計されたagentは、ツール呼び出しが実際に成功したかを確認してから完了とみなし、一時的な失敗ならリトライし、失敗が繰り返されるときは推測せず人間に引き継ぎます。ツール呼び出しを発行して、うまくいったものと思い込むagentは、「AIはメールを送ったと言ったが、送られていなかった」という事態の最も一般的な根本原因です。
Function callingと標準化の課題
しばらくの間、ツールの統合はどれもカスタムの作業でした。CRM用の専用コネクタ、カレンダー用の別のコネクタ、サポートデスク用のさらに別のコネクタ。基盤となるAPIが変わったりAIプロバイダーを切り替えたりするたびに、それぞれが少しずつ違う形で壊れました。Model Context Protocolは、モデルがツールを発見して呼び出す方法を標準化することでこれに対処します。一度作ったツールを、プロバイダーごとに作り直さず、異なるAIプロバイダーで使えるようにします。
この標準は急速に広がっています。MCPを最初に開発したAnthropicは、2025年12月時点で1万を超えるアクティブな公開MCPサーバーがあると報告しています。1年前の公開時点では数百でした。このプロトコルは今や、主要なagenticプラットフォームの多くで、横ではなく土台の位置を占めています。モデルを変えるたびに統合レイヤーを作り直すことなく、増え続けるビジネスツールにagentを接続したい場合は、Model Context Protocolとはがより深いリファレンスです。幅広いサーバーに接続することで生じるセキュリティ上の考慮事項も含まれています。
ガードレール:ツールに自由に許してはいけないこと
すべてのツール呼び出しが、同じだけの信頼に値するわけではありません。読み取り専用の検索と、返金を実行するアクションでは、agentが間違えたときのリスクが大きく異なります。両者を同じように扱うと、小さな推論の誤りが、実際の金銭的損害や顧客への損害に変わります。
うまくいくパターンは次のとおりです。各ツールには、仕事をこなせる範囲で最も狭い権限を与え、金銭に関わるもの、取り消せないもの、大規模に顧客と接するものには人間の承認ステップを求め、すべての呼び出しをログに残して、誤った行動が後から追跡できるようにします。謎のままにしません。これはAI agentのガードレールで取り上げているのと同じ規律であり、放置しても安全に動かせるagentと、うまくいかなくなる日まで技術的には動いているだけのagentを分けるものです。Autonomous Agentパターンでは、あらゆる呼び出しが実際の状態を変える機会になるため、ツール呼び出しのループがagent設計で最もリスクの高い部分である理由を、さらに掘り下げています。
Key Facts
- Function callingは、ツール名、平易な言葉の説明、パラメータスキーマの3つの要素で動作します。モデルは自分でコードを実行することはなく、あなたのシステムが実行する構造化リクエストを出力します。
- モデルは、リクエストをツールの説明と照合し、ツールに手を伸ばすか直接答えるかについて与えられた指示に従って、ツールを呼び出すかどうかを決めます。
- ツール呼び出しには、単一、逐次、並列、条件付きの4つの形があり、1つのagentの実行の中で組み合わされることが多くあります。
- 利用可能なツールの数が増えると、精度は下がります。OpenAIは、有効なツールリストを約20未満に保ち、大規模なライブラリでは追加のツールを必要に応じて読み込むことを推奨しています。
- Model Context Protocolは、AIプロバイダーをまたぐツール統合を標準化しており、エコシステムは1万を超えるアクティブな公開サーバーに成長しています。
AI agentのツール利用に関するよくある質問
AI agentにおけるfunction callingとは何ですか。
Function callingは、AIモデルがテキストを生成するだけでなく、実際の行動を取れるようにする仕組みです。モデルが特定のツールとそのパラメータを指定した構造化リクエストを出力し、アプリケーションまたはAIプロバイダーがそのリクエストを実際のシステムに対して実行し、結果がモデルに返されて、次のステップの前に読み取られます。
function callingとツール利用の違いは何ですか。
どちらも同じ能力を指します。ツール利用は、AIが外部の関数、API、サービスを呼び出すことの総称です。Function callingは、ほとんどのプロバイダーがそれを実装するために使う具体的な仕組みで、モデルが定義済みのスキーマに合致する構造化された呼び出しを出力します。実際には、多くの人がこの2つの用語を同じ意味で使っています。
AI agentはどのツールを呼び出すかをどう決めますか。
モデルは、現在のタスクを利用可能な各ツールの説明と照合し、合致するものを選びます。すでにコンテキストにある内容から答えられる場合は、ツールは不要と判断します。どれだけ積極的にツールに手を伸ばすかは、システムプロンプトやagentの設定で調整でき、固定されてはいません。
ツール呼び出しが失敗するとどうなりますか。
よくできたagentは、成功したと思い込まず、すべてのツール呼び出しの結果を確認します。タイムアウト、権限エラー、パラメータの不足といった失敗では、一時的なものならリトライし、値が不足していれば確認の質問をし、自力で解決できないときは人間に引き継ぎます。
AI agentは同時にいくつのツールを使えますか。
厳密な上限はありませんが、リストが長くなるほど、モデルが似たように見える選択肢を区別しなければならず、精度が下がります。OpenAIは、1ターンで有効なツールセットを約20未満に保ち、より大きなライブラリが必要なagentでは追加のツールを必要に応じて読み込むことを推奨しています。
Model Context Protocolはfunction callingと同じものですか。
いいえ。Function callingは、モデルがツールを呼び出すための仕組みです。MCPは、そもそもAIクライアントがツールサーバーを発見して接続する方法に関するオープンな標準で、同じツール統合をプロバイダーごとに作り直さず、異なるAIプロバイダーで使えるようにします。
次に読むもの
ツール利用は、agentに手を与えるものです。ループの推論側と組み合わせて、モデルがどのツールにいつ手を伸ばし、いつ止まるかを判断する仕組みを理解するには、AI agentはどう推論するのかをご覧ください。これらのツール呼び出しが収まるループ全体は、AI agentの仕組みで確認できます。構築の土台となるプラットフォームを比較している場合は、自動化ツールの一覧とベストなノーコード自動化ツールのガイドで、今購入できる製品のどこにツール呼び出し機能があるかを確認できます。
