Function Callingとは｜AIエージェント発注前に押さえる仕組みと判断軸

「ベンダー提案書に『Function Calling を活用します』『Tool Use で外部システムと連携します』と書かれているが、それが見積の妥当性や運用リスクにどう効いてくるのか説明できない」——AI エージェント案件の発注担当者・DX 推進責任者から、こうした声をよく聞きます。

エンジニアに意味を尋ねると「LLM が関数を呼ぶ機能です」という一言で終わってしまい、要件定義や見積レビューで自分が何を判断すればよいのかが結び付かない。これは、Function Calling の解説記事の多くが開発者向けのコード実装を中心に書かれているために起きる、意思決定者側特有の課題です。

Function Calling（Anthropic では「Tool Use」、Google Gemini では「Function Calling」と呼ばれます）は、AI エージェントの中核を成す仕組みです。ここを理解せずに発注してしまうと、「マルチベンダー切り替え不可能な作りになっていた」「LLM 呼び出しコストが想定の 3 倍に膨らんだ」「エラー時にツールが暴走した」といったリスクが後から顕在化します。

本記事では、非エンジニアの意思決定者が発注前に押さえておくべき Function Calling の基礎を、以下の 4 点に絞って解説します。(1) Function Calling / Tool Use の定義とベンダー間の呼称違い、(2) 動作の 3 ステップフロー、(3) 典型的な 3 つの活用パターン、(4) MCP との違いと、発注時に確認すべき 5 つの判断軸。読み終えたときに、ベンダー打ち合わせで「その設計だとコストが跳ねませんか」「エラー時のフォールバックはどうなっていますか」といった質問を自分から投げられる状態を目指します。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

Function Calling（Tool Use）とは？発注者が知っておくべき基礎

Function Calling とは何か（定義と成り立ち）

Function Calling とは、大規模言語モデル（LLM）が、開発者側で定義した外部の関数（Function）や API を「必要なときに、必要な引数を組み立てて呼び出せる」ようにする仕組みです。LLM 単体は自然文の生成能力しか持ちませんが、Function Calling を組み合わせることで「社内 DB の在庫を検索する」「決済 API を叩く」「カレンダーに予定を入れる」といった実行系のアクションを、自然言語の指示から連動させられるようになります。

OpenAI が 2023 年 6 月に GPT-3.5/GPT-4 で Function Calling 機能を提供開始したのが業界的な起点で、その後 Anthropic の Claude、Google の Gemini などの主要 LLM が同等機能を実装しました。現在ではほぼすべての商用 LLM API に標準搭載されている機能であり、AI エージェント開発の事実上の共通基盤となっています（OpenAI Function calling ドキュメント、Anthropic Tool use ドキュメント）。

「Function Calling」と「Tool Use」の呼び分け（OpenAI / Anthropic / Google の対応）

ベンダー提案書を読み解く上でつまずきやすいのが、同じ機能なのに提供元によって呼び名が異なる点です。以下の対応関係を押さえておけば、提案書の記述が同じ機能を指しているのか、別の設計思想を指しているのかを判別できます。

つまり、提案書に「Tool Use を採用」と書かれていた場合、それは「Anthropic Claude を前提とした設計」であることを示唆しています。逆に「Function Calling を採用」と書かれていた場合、OpenAI / Google のいずれか、あるいは両対応の設計である可能性があります。呼称の違いから採用予定のベンダーを推測できる、というのが発注者側の実務的な使いどころです。

なぜAIエージェント発注前に押さえるべきなのか

Function Calling は、AI エージェントの見積・要件定義・運用リスクの三方に直接影響します。

見積の妥当性判断: Function Calling を使うと LLM の API 呼び出し回数が単純な会話の 2〜5 倍に増える構造があります（後述の仕組みの章で解説）。ベンダーが「月額 10 万円で運用可能」と提示してきたときに、その前提が現実的なリクエスト量を織り込んでいるかを検証するには、Function Calling のコスト構造の理解が不可欠です。

要件定義の粒度: 「どんな業務を自動化するか」を要件定義書に落とす際、Function Calling では「ツール（関数）の粒度」が設計の中心になります。粒度の設計を曖昧なまま発注すると、ベンダー側が独断で決めた粒度が納品時にミスマッチを起こし、追加工数が発生します。

運用時のリスク把握: Function Calling では LLM が「どのツールをいつ呼ぶか」を自律的に判断します。ここに権限管理・エラー時挙動・監視設計を組み込まないと、「本番で意図しない DB 更新が走った」「ツール失敗時に無限リトライしてコストが跳ねた」といった事故が起きます。

以降の章で、これらを具体的に判断できるようにしていきます。なお、そもそも AI エージェントとは何か・どのような構成要素で成り立っているかを先に押さえておきたい方は、AIエージェントとはもあわせてご覧ください。

Function Callingの仕組み｜3ステップで動く基本フロー

Function Calling の動作は、開発者側と LLM 側の責務分担を理解すると全体像がクリアになります。全体は 3 ステップで完結する単純な構造ですが、この責務分担が「どこにベンダーの実装工数がかかるのか」を判断する材料になります。

ステップ1: ツール定義（スキーマ）をLLMに渡す

まず、開発者が「LLM に呼び出させたい関数」の一覧をスキーマとして LLM に渡します。スキーマには最低限、以下の 3 点が含まれます。

• 関数名（例: search_customer_order）
• 関数の説明（例: 「顧客の注文履歴を検索する」）
• 引数の定義（例: customer_id: 文字列、必須。period: 日付範囲、任意）

このスキーマ設計こそが、Function Calling を使ったエージェント開発の初期工数の大半を占めます。ベンダーが「10 個の関数を実装します」と言った場合、それは「10 個の関数コードを書く工数 + 10 個のスキーマを設計する工数 + LLM が正しく呼び分けるかを検証する工数」を含んでいます。

ステップ2: LLMがどのツールを呼ぶか判断

ユーザーがエージェントに指示を投げると（例:「田中さんの先月の注文を教えて」）、LLM は事前に渡されたツール定義の一覧を参照し、「どの関数を呼べばこの要求に応えられるか」「引数として何を渡すべきか」を判断します。

この判断が最初のポイントです。ツール定義が曖昧だったり、似た機能の関数が複数存在すると、LLM が誤った関数を選択したり、引数を間違えたりします。ツール数が増えれば増えるほど判断精度が下がる傾向があるため、後述する「ツールの粒度と数」の設計が発注時に問われることになります。

判断結果として、LLM は「この関数を、この引数で呼び出してほしい」という指示を返します。この時点で LLM は関数を「実行」してはおらず、あくまで「呼び出したい関数の名前と引数」を返すだけである、というのが重要な点です。

ステップ3: 実行結果をLLMに返して回答生成

LLM から返ってきた「関数呼び出し指示」を受けて、実際にその関数を実行するのはアプリケーション側（開発者が書いたコード）の責務です。DB を叩く、API を叩く、といった実行を行い、返ってきた結果を再度 LLM に「関数実行結果」として渡します。

LLM はこの結果を受け取り、自然文の回答に整形してユーザーに返します（例:「田中様の先月のご注文は 3 件で、合計金額は 45,000 円でした」）。

このフローで注意すべきは、1 回のユーザー質問に対して LLM の API 呼び出しが最低 2 回発生する点です（ツール呼び出しを判断する 1 回目 + 実行結果から回答を生成する 2 回目）。複数のツールを連鎖的に呼ぶ場合はさらに増え、複雑なエージェントでは 1 回のユーザー質問で 5〜10 回の LLM 呼び出しが走るケースもあります。これがコスト構造の章で解説する「呼び出し回数が跳ねる」構造の正体です。

Function Callingで実現できること｜典型的な3つの活用パターン

Function Calling を使った AI エージェントは、実装難易度と連携範囲によって大きく 3 パターンに分類できます。自社の要件がどのパターンに該当するかを最初に整理すると、ベンダーとの認識合わせが格段にスムーズになります。

社内システム・DBを参照するパターン

社内の在庫 DB、顧客 DB、ナレッジベース、勤怠システム等を LLM から検索・参照させるパターンです。「今月の A 社の売上を教えて」「田中さんの残業時間を教えて」といった、自然言語での社内データ問い合わせを実現できます。

発注時に想定すべき技術難易度・データ連携範囲: 社内システムに検索用の API が既に存在するか、新規開発が必要かで工数が大きく変わります。検索 API がある場合は比較的シンプルですが、既存 DB に直接 SQL を発行させる方式（Text-to-SQL）を採用する場合はセキュリティ・権限管理の設計負荷が跳ね上がります。

外部API・SaaSを連携させるパターン

Slack への通知投稿、Google Calendar への予定登録、決済 API（Stripe 等）の呼び出し、Google Maps での経路計算など、外部サービスと連携するパターンです。カスタマーサポート系のエージェント（問い合わせを受けて Slack にエスカレーション）や、業務自動化エージェント（会議録画から議事録を生成し社内 Wiki に登録）で多用されます。

発注時に想定すべき技術難易度・データ連携範囲: 各 SaaS の API 認証（OAuth 等）と、レート制限・課金体系の把握が必要です。特に決済系・書き込み系の API は、後述する「権限管理・実行前確認」の設計を確実に組み込む必要があります。

複数ツールを組み合わせた業務自動化パターン

「顧客から問い合わせを受けたら、顧客 DB から履歴を取得し、担当営業のカレンダーを確認して空き時間を提案し、Slack で担当営業に通知する」といった、複数のツールを連鎖的に呼び出す複雑なワークフローを実現するパターンです。これがいわゆる「AI エージェント」の中核的な形です。

発注時に想定すべき技術難易度・データ連携範囲: 単一ツール活用と比べて、判断ミス時のリカバリー設計・エラー時の中断制御・状態管理（どこまで処理が進んだか）が必要になり、開発工数は 2〜3 倍に膨らみます。運用時のモニタリング・ログ設計も、単純パターンと同じ感覚で見積もると必ず不足します。

Function CallingとMCPの違い｜混同しやすい2つの技術

近年、Function Calling と並んで「MCP（Model Context Protocol）」という言葉がベンダー提案書に登場するようになりました。両者は混同されがちですが、レイヤーが異なる技術です。ここを理解しないまま発注すると、後々の設計変更コストにつながります。

Function Callingは LLM ベンダー独自の実装

Function Calling は、前述のとおり OpenAI・Anthropic・Google などの LLM ベンダーがそれぞれ独自に実装している API 機能です。呼び出し方法（引数の渡し方・レスポンスの形式）はベンダーごとに微妙に異なり、あるベンダー向けに書いたコードを別ベンダーで使うには一定の書き換えが必要になります。

MCPは複数ツール・複数LLMを繋ぐ標準プロトコル

MCP（Model Context Protocol）は、Anthropic が 2024 年 11 月にオープンソースで公開した、LLM とツール群を繋ぐための標準プロトコルです（Anthropic: Introducing the Model Context Protocol）。ツールの提供側（MCP サーバー）と LLM の利用側（MCP クライアント）を分離することで、「一度作った MCP サーバーは、Claude でも GPT でも Gemini でも同じように使える」という再利用性を実現しています。

MCP は Function Calling を置き換えるものではなく、補完する関係にあります。実際、MCP サーバーが LLM にツールを提供する内部の仕組みは、多くの場合 Function Calling を土台にして動いています。日経クロステックも「MCP と Function Calling は AI エージェントの外部ツール連携で欠かせない存在」と整理しており、両者は共存前提の技術として位置付けられています（出典: 日経クロステック「AIエージェントの外部ツール連係、MCPとFunction Callingが欠かせない存在に」、2025年）。

発注時の使い分け判断軸

意思決定者としては、次の観点でベンダー提案を評価できます。

ベンダー提案書が「Function Calling を直接利用」で書かれている場合、それが「シンプルさを優先した選択」なのか「MCP を検討していない選択」なのかを確認する価値があります。将来的にマルチベンダー化・エージェント資産の横展開を見据えているなら、MCP の採否は必ず論点に上げるべきです。

Function Callingを前提としたAIエージェント発注で確認すべき5つの論点

ここまでの内容を踏まえ、発注者が要件定義・見積レビュー・ベンダー打ち合わせで必ず確認すべき 5 つの論点を整理します。この章が本記事の中核であり、読み終えたときにこの 5 点をチェックリストとして持ち帰れる状態を目指します。

論点1: ツール数・粒度をどう設計するか

Function Calling では、LLM に渡すツール（関数）の粒度と数が、判断精度と拡張性を左右します。

粒度が細かすぎる場合: 「顧客名で検索」「顧客 ID で検索」「顧客メールで検索」を別関数にする、といった細分化は、LLM がどれを選ぶべきか迷い、誤選択の原因になります。

粒度が粗すぎる場合: 「あらゆる社内データを検索」といった万能関数は、LLM が引数を間違いやすく、また関数内部の分岐が複雑化して保守性が下がります。

確認すべき質問例: 「今回のエージェントで想定しているツール数は何個ですか？」「どの粒度で分割していますか？」「ツールを追加・修正するときの改修範囲はどう見積もっていますか？」

論点2: 権限管理と実行前確認フロー

DB への書き込み、決済実行、外部への通知送信など、副作用のあるツールは、LLM の判断を「そのまま実行」させると事故につながります。

発注時に組み込むべき設計:

• 参照系（Read）と実行系（Write）でツールを明確に分離
• Write 系ツールには実行前に人間の承認を挟むフロー（Human-in-the-Loop）
• ロールベースの実行権限（このユーザーはこのツールを呼べる/呼べない）

確認すべき質問例: 「Write 系ツールを人間承認なしで自動実行させる設計になっていませんか？」「もし誤った引数で実行されたらどう検知・巻き戻しますか？」

論点3: コスト構造の見積り方

前述のとおり、1 回のユーザー質問で LLM 呼び出しが最低 2 回、複雑なエージェントでは 5〜10 回発生します。ここに「入力トークン（プロンプト + ツール定義 + 会話履歴）」×「出力トークン（LLM の応答）」の従量課金がかかります。

見積で必ず確認すべき数字は以下です。

• 想定される月間ユーザー質問数
• 1 質問あたりの LLM 平均呼び出し回数（設計に依存）
• 使用予定モデルの入力・出力トークン単価
• ツール定義の平均トークン数（会話ごとに毎回送られる固定コスト）

確認すべき質問例: 「月間の想定リクエスト数と 1 リクエストあたりの LLM 呼び出し回数を教えてください」「ピーク時のコスト上限をどう制御しますか？」「モデルを安価なものに切り替える判断基準は？」

LLM 呼び出し費用は Function Calling コストの一部にすぎず、実際の発注では初期構築費・データ連携開発費・運用保守費・追加改修費など複数の費目が重なります。コスト構造の全体像（開発費と運用費の内訳・相場感）を体系的に把握したい場合は、AIエージェント開発コストもあわせて参照し、ベンダー見積との突き合わせにお使いください。

論点4: エラー時のフォールバック設計

ツール実行が失敗したとき（外部 API のタイムアウト、DB のエラー、権限不足など）、LLM は結果を受け取れず、多くの場合「再度同じツールを呼ぼうとする」「別のツールで代替を試みる」といった判断をします。

必須で組み込むべき設計:

• 同一ツールへのリトライ回数の上限
• ツール失敗時にエージェント全体を中断してユーザーに委ねる条件
• タイムアウト値（LLM が延々と試行し続けるのを防ぐ）

確認すべき質問例: 「ツール失敗時に無限ループする可能性はありませんか？」「リトライ上限は何回に設定していますか？」「失敗時のユーザーへのエラー通知はどうしますか？」

論点5: モニタリング・ログ設計

Function Calling ベースのエージェントは、内部で LLM が自律的に判断するため、後から「なぜこの動作になったか」を追跡できないと、障害対応・改善サイクルが回りません。

必須で組み込むべき設計:

• どのツールが、どの引数で、いつ呼ばれたかの完全なログ
• LLM への入力プロンプトと出力レスポンスの記録
• ツールごとの呼び出し回数・成功率・平均応答時間のダッシュボード

確認すべき質問例: 「エージェントの動作ログはどこに、どの粒度で残りますか？」「本番で異常が起きたときの調査手順は？」「ツールごとの呼び出し統計をどこで見られますか？」

まとめ｜Function Callingの理解で発注リスクを下げる

本記事では、AI エージェント発注前に非エンジニアの意思決定者が押さえておくべき Function Calling（Tool Use）の基礎を、以下の 4 点で整理しました。

• 定義と呼称: Function Calling は LLM が外部の関数・API を呼び出す仕組み。OpenAI・Google は「Function Calling」、Anthropic は「Tool Use」と呼ぶが、機能の実質は同じ
• 仕組み: ツール定義を渡す → LLM が呼び出しを判断 → 実行結果を LLM に返して回答生成、という 3 ステップ。1 質問で LLM 呼び出しが最低 2 回発生する
• 活用パターン: 社内システム参照 / 外部 API 連携 / 複数ツール組み合わせの 3 種類。パターンによって開発工数・運用リスクが大きく異なる
• 発注時の 5 論点: ツールの粒度と数 / 権限管理と実行前確認 / コスト構造 / エラー時フォールバック / モニタリング・ログ

次のアクションとして、以下を推奨します。

1. 社内案件の分類: 現在検討中の AI エージェント案件が、上記 3 つの活用パターンのどれに該当するかを整理する。パターンによってベンダーに求めるべき実績・工数見積の妥当性ラインが変わります
2. ベンダー提案書の再レビュー: 手元にあるベンダー提案書を、上記 5 論点の観点で見直す。特に「コスト構造」「エラー時フォールバック」「モニタリング設計」は提案書に明記されていないケースが多く、追加質問すべき論点として抽出できます
3. MCP 採否の組織判断: 単発のエージェント案件ではなく、社内で複数のエージェント・ツールを継続的に構築していく方針があるなら、MCP を前提とした設計標準を早期に組織のロードマップに組み込むことを検討してください。後から MCP 対応にリファクタリングするコストは、初期から MCP 前提で作るコストの数倍になります
4. 導入プロセスの型化: 発注担当者以外のステークホルダー（事業部門・情シス・経営層）とも AI エージェント導入の全体像を共有し、要件定義から本番運用までのプロセスを組織として型化しておく。導入ステップの整理にはAIエージェント導入ガイドが実務のたたき台として使えます

Function Calling は「開発者だけが理解していればよい技術」ではありません。発注者が仕組みと判断軸を持つことで、AI エージェント案件の見積・要件定義・運用リスクを一段深く評価できるようになり、ベンダーとの対話の質が変わります。本記事を発注時のチェックリストとして活用いただければ幸いです。

—Free Download / 資料ダウンロード

はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ

この資料でわかること

AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。

こんな方におすすめです

• AI導入を検討しているが、何から始めればよいか分からない
• ベンダーの選び方や費用感がつかめず、判断できない
• 社内でAI導入の稟議を通すための資料が必要

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。