上司から「AIにカレンダー登録やメール送信まで任せられないか」と検討を振られ、AIエージェントの解説記事を読み始めたものの、「Function Calling」という言葉の意味が掴めず手が止まっていないでしょうか。
AIチャットは、質問に答えるだけの存在から外部のサービスを操作する存在へと変わりました。
その転換を支えているのが、この数年で実用段階に入ったFunction Calling（Tool Use）という仕組みです。
この記事では、業務自動化の構築設計で使っている考え方をもとに、Function Callingとは何かという基本から、AIが暴走せずに外部ツールを扱える理由、導入時に確認すべき点までを整理しています。
Function Callingとは何か
Function Callingは、AIが自分の言葉で回答するだけでなく外部の機能を呼び出すための仕組みです。
呼び方は各社で異なり、Anthropicの製品ではTool Use、Googleの製品ではTool Callingと呼ばれます。
呼び出す対象は、API（Application Programming Interface：ソフトウェア同士がデータをやり取りするための窓口）として用意された関数です。
AIはこれを介して、実際の情報取得や操作につなげます。
AI単体では、学習データに含まれていない今日の天気や自社の在庫データを知ることはできません。
Function Callingは、この『知らない情報』や『AI自身では実行できない操作』を、あらかじめ用意しておいた外部の機能に橋渡しする役割を持ちます。
OpenAIは2023年6月13日にこの機能を正式発表し、その後Anthropic、Googleを含む主要なAIモデル提供各社が同種の仕組みを実装しました。
出典： OpenAI「Function calling and other API updates」
呼び方は各社で異なりますが、AIが「この作業には外部の機能が必要だ」と判断し、必要な情報を添えて呼び出しを要求する、という基本構造は共通しています。
なぜAIに外部ツールとの連携が必要なのか
AIモデルは大量の文章から学習した知識をもとに回答を生成しますが、学習した時点のデータしか持たず、日々更新される情報や社内システムの状態を単独では把握できません。
たとえば「来週の会議をカレンダーに追加して」という依頼に、AI単体で応じることはできません。
カレンダーというシステムに実際に書き込む手段を、AIは自分の中に持っていないためです。
Function Callingがあることで、AIは「カレンダー登録用の機能を呼び出す必要がある」と判断し、日時とタイトルを整理した形で外部システムに渡せるようになります。
外部システム側はその情報を受け取り、実際の書き込みを実行します。
最新の為替レートを調べる、社内データベースから顧客情報を検索する、メールの下書きを作成するといった作業も、同じ仕組みで実現できるものばかりです。
AIが『考える』部分と、外部システムが『実行する』部分が分かれていることが、この仕組みの土台になっています。
たとえば問い合わせ対応であれば、AIが顧客の質問内容を読み取り、注文履歴を照会する関数を呼び出し、返ってきたデータをもとに回答文を組み立てるという流れになります。
注文履歴そのものはAIの学習データには存在しないため、この連携がなければ「現在の配送状況」のような個別の質問には答えられません。
Function Callingはどう動くのか
Function Callingの動作は、大きく3つの段階に分けて理解すると全体像を掴みやすくなります。
1つ目は開発者が事前に準備する段階、2つ目はAIが判断する段階、3つ目は外部システムが実際に処理を行う段階です。
どの段階も欠けると仕組み全体が成立しないため、順番に見ていきます。
Step1. 開発者がツールを定義する
まず開発者が、AIに使わせたい機能を「関数」として事前に登録します。
登録する内容は、関数の名前、何をする機能か、そして実行に必要な情報（引数）の3点です。
たとえば「カレンダー登録」という関数なら、日時とタイトルと参加者を引数として定義します。
この定義がなければ、AIはそもそもその機能の存在を認識できません。
Step2. AIが呼び出すツールと引数を判断する
ユーザーから「来週火曜の10時に定例会議を登録して」と依頼されると、AIは登録済みの関数一覧の中から適切なものを選びます。
このときAI自身が関数を実行することはありません。
出力するのは「カレンダー登録の関数を、日時=来週火曜10時、タイトル=定例会議、という条件で呼び出したい」という要求データだけで、書式にはJSON（プログラムが読み取りやすく整えられたデータ形式）が使われます。
つまりAIの役割は「どの関数を、どんな条件で使いたいか」を宣言するところまでで、実行そのものは次の段階に委ねられています。
Step3. 外部システムが実行し結果をAIに返す
AIから渡された呼び出し要求を受け取るのは、開発者が用意したプログラムです。
このプログラムが実際にカレンダーへの書き込みを実行し、成功したか失敗したかという結果をAIに送り返す流れです。
AIは受け取った結果をもとに、「来週火曜10時に定例会議を登録しました」という自然な文章の返答を生成します。
この最後のやり取りがあるおかげで、ユーザーが意識するのは会話として受け取る結果だけになります。
Function Callingを実際にAIへ組み込む際は、各社が公開するAPIを直接呼ぶ方法のほかに、複数のツールを共通の形式でつなぐMCPという規格を使う方法もあります。
仕組みの違いは次の記事で詳しく整理しています。
AIが勝手に実行してしまわないか
「AIに任せると、確認なしで送信や予約を進めてしまうのでは」という不安は、Function Callingの仕組みを検討する読者から最もよく出る疑問です。
結論として、AI自身に実行する権限はなく、実行の可否を決めるのは常に外部システム側です。
Step2で見た通り、AIが出力するのは「この関数をこの条件で呼び出したい」という要求データだけであり、それを実行に移すかどうかは開発者が用意したプログラムの判断に委ねられています。
この構造があるため、金額が一定以上の送金や、削除のように取り消せない操作の前には、人による確認画面を挟むという設計を後から追加できるのです。
もう1つ押さえておきたいのは、AIが要求できる操作の範囲そのものが、Step1で定義した関数に限られるという点です。
定義していない操作は、AIがどれだけ気を利かせようとしても要求の出しようがありません。
「メール送信の関数を渡していないのに勝手にメールを送る」という事態は、仕組みの構造上起こらないわけです。
また、AIが誤った内容の要求を出した場合でも、受け取る側のプログラムがその内容を検査し、条件に合わなければ実行せずに差し戻せます。
たとえば「営業時間外の予約」や「存在しない顧客IDの照会」のような要求は、実行前のチェックで弾く設計にできます。
AIの判断ミスと実害の間に必ず検査のしくみを置けることが、生成AIの文章ミス（ハルシネーション）とはリスクの扱い方が異なる部分です。
実務では、AIの呼び出し要求を受け取った直後に「この内容で実行してよいか」という確認ステップを挟む構成がよく使われます。
たとえば読み取り専用の検索や情報取得は自動で進め、送信や削除のように取り消せない操作だけ承認を必須にする、という切り分け方です。
メール送信を任せる場合であれば、AIが作成した下書きと宛先を画面に表示し、担当者が承認して初めて送信される、という流れになります。
すべての操作を自動化すると誤送信のリスクが残るため、影響範囲が大きい操作ほど確認ステップを厚くするのが実務上の考え方です。
Function CallingとAIエージェントはどう違うのか
Function Callingは『AIが外部ツールを呼び出すための1つの機能』であり、AIエージェントは『その機能を使って目標達成まで自律的に動くシステム全体』を指します。
両者は階層が異なり、AIエージェントの内部でFunction Callingが繰り返し使われている、という関係です。
1回のFunction Callingは、1つの依頼に対して1つの関数を呼び出して結果を返すところで完結します。
一方でAIエージェントは、目標を受け取ってから複数回のFunction Callingを連続で実行するシステムです。
途中の結果を見ながら次の行動を判断し直すという流れを繰り返す点が異なります。
「A社の情報を調べて、レポートにまとめてSlackに投稿して」という依頼であれば、検索、情報整理、投稿という複数の関数呼び出しを1つの流れとしてつなげる部分がAIエージェントの役割です。
指示に答えるだけの生成AIと、目標を渡すと自律的に複数ステップをこなすAIエージェントの違いは、次の記事で詳しく整理しています。
こうした複数回のFunction Callingを1から自前で組むのではなく、フレームワークを使って組み立てる方法もあります。
代表的なLangChainについては次の記事で扱っています。
導入する際に何を確認すればよいか
Function Callingを業務に組み込む際は、機能そのものの理解よりも「どこまでを自動実行させ、どこから人の確認を挟むか」という運用設計の方が重要になります。
確認すべき点は、実行内容の取り消し可否、権限の範囲、そして向かない業務の3つです。
どれもFunction Callingの技術仕様ではなく、自社の業務とリスクをどう切り分けるかという運用側の論点なので、上司への説明でもこの3点を軸にすると話が通りやすくなります。
取り消し可否で自動実行の範囲を決める
取り消せない操作、たとえば送金、削除、外部への公開といった処理は、確認ステップを必須にする設計が前提になります。
一方、社内資料の検索や情報の要約のように取り消しの必要がない処理は、自動実行にしても影響が限定的です。
迷ったときは「間違えたときに元へ戻せるか」だけを基準にすると、業務ごとの線引きを機械的に決められます。
AIに渡す権限を必要最小限に絞る
権限の範囲についても、AIに渡す関数はできるだけ狭く絞ることが安全性の基本です。
『顧客データベース全体を操作できる関数』ではなく『特定の顧客IDの情報だけを参照できる関数』のように、必要最小限の権限を持つ関数を用意する設計が実務では推奨されています。
広い権限のまま運用を始めると、AIが関数や引数を取り違えたときの影響範囲がそのまま権限の広さに比例してしまうためです。
向かない業務を見分ける
向かない条件としては、判断基準があいまいで人によって正解が割れる業務や、社外のシステムとの連携部分がまだ整備されていない業務が挙げられます。
このような業務にFunction Callingを組み込むと、AIの判断が食い違った際の責任の所在が不明確になりやすく、まずは読み取り専用の用途から始めて実績を積む進め方が現実的です。
たとえば経費精算の一次チェックであれば、領収書の金額と申請内容を照合して不一致を検出する読み取り専用の関数から始めれば、AIが誤った判断をしても実害は確認の手間が増える程度にとどまります。
一方、承認まで自動で完結させる構成は、社内の稟議ルールが明文化され、例外パターンが少ない業務に限って検討するのが安全な進め方です。
Function Callingを使った業務自動化について相談してみませんか？
「AIにどこまで実行させてよいか判断できない」「取り消せない操作のリスクにどこまで備えるべきか分からない」「社内に権限設計まで含めて構築できる人材がいない」
少しでもお心当たりがあれば、お気軽にご相談ください。
現在、AIの業務活用に関するお悩みをお伺いする 無料の個別相談 を実施しています。
よくある質問
Q. Function CallingとRAGは同じもの？
別の仕組みです。
RAG（Retrieval Augmented Generation：検索で取得した情報をもとに回答を生成する手法）は、AIが回答前に関連文書を検索して参照する仕組みです。
情報を『読む』ことに主眼があり、Function Callingのように書き込みや送信を『実行する』ところまでは扱いません。
実務では両者を組み合わせて、検索した情報をもとに関数を呼び出す構成もよく使われます。
Q. Function Callingを使うのにプログラミング知識は必要？
関数を定義する側には必要ですが、利用する側には必須ではありません。
ChatGPTやClaudeのアプリ上であらかじめ用意された連携機能を使うだけであれば、設定画面の操作で完結します。
自社独自のシステムと連携する関数を新たに作る場合は、開発者による設計と実装が必要です。
Q. AIが誤った関数を呼び出すことはある？
あります。
似た名前の関数を取り違えたり、引数の内容を誤って解釈したりするケースが典型的な失敗パターンです。
そのため、影響が大きい関数ほど実行前の確認ステップを設ける、関数の説明文を具体的に書いて誤解の余地を減らす、といった対策が実務では取られています。
Q. 小規模な会社でもFunction Callingを導入できる？
導入できます。
ChatGPTやClaudeが提供する標準的な連携機能を使う範囲であれば、専門のエンジニアを新たに雇わずに始められるケースも多いです。
ただし、自社システムと連携する独自の関数を作る場合は、設計と保守を担える人材か外部の支援が必要になります。
