この記事で分かること

  • 関数呼び出し（Function Calling）とは、AIがあらかじめ用意された外部の処理を呼び出せる仕組みであること
  • ファイナンス実務では「AIに計算をさせない」ための手段として重要であること
  • 副作用を伴う処理を含める場合のリスクと、人の承認を挟む設計の考え方
  • 整数設例で、直接計算と関数呼び出しとで検証にかかる確認回数がどれだけ変わるかを検算する方法

30秒で分かる定義

関数呼び出し（Function Calling）とは、AIモデルがあらかじめ用意された外部の処理（計算・検索・データ取得など）を呼び出せるようにする仕組みです。英語ではFunction Calling、読み方は「かんすうよびだし」で、実務では「ツールコール（Tool Calling）」とほぼ同義で使われることもあります。ポイントは、AIが行うのは「どの処理をどの引数で呼ぶか」の判断までであり、実際の計算やデータ取得そのものは外部のプログラムが実行するという役割分担です。

なぜファイナンス実務で重要なのか

ファイナンス実務でこの仕組みが重視される最大の理由は、AIに直接計算をさせないための手段になるという点です。大規模言語モデルは文章としてもっともらしい数値を生成できますが、内部で四則演算の正確性を保証しているわけではなく、桁数の大きい計算や複雑な数式では誤りが混じることがあります。関数呼び出しを使えば、AIは「どの計算式を、どの数値で実行するか」を判断するだけにとどめ、実際の計算は表計算ソフトやプログラムに委ねられます。これにより同じ入力からは常に同じ結果が返るという、財務数値の再現性・検証可能性の面で欠かせない性質が得られます。同様に、決算数値や市場データの取得も外部の関数に任せることで、AIが記憶や推測から数字を作り出してしまう問題を避けやすくなります。検証の考え方は生成AI出力の検証手順でも解説しています。

仕組み

関数呼び出しの流れは、おおむね次の3段階に分けられます。

  1. ①利用者がAIに依頼を出す（例：「A社の売上高とEBITDAからEBITDAマージンを計算して」）
  2. ②AIは依頼内容を解釈し、あらかじめ定義された関数の一覧の中から適切な関数と引数（会社コード・期間・金額など）を選び出す
  3. ③実際の計算やデータ取得は外部のプログラムが実行し、その結果をAIに返す。AIは結果を受け取って回答文を組み立てる

ここで重要なのは、②までがAIの役割であり、③の実行そのものはAIの外側で行われる点です。呼び出せる関数の種類・権限をどこまで用意するかはシステムを設計する側が決めます。読み取り専用の関数（照会・計算）だけを用意するか、書き込みを伴う関数（発注・送金・ファイル更新など）まで含めるかで、リスクの性質が大きく変わります。複数の関数を連続して呼び出しながらタスクを進めるAIエージェントの構成も広がっています。

整数設例で確認する

設例（架空）。あるKPI比率（売上高に対する費用の比率）を、同じ入力（売上高・費用の数値）を与えて10回算出させ、方式ごとの結果と、担当者が確認すべき回数を比べます。

方式10回中、正しい値が返った回数担当者が確認すべき回数
AIが直接計算7回（3回は異なる値）10回（毎回個別に検算）
関数呼び出しで表計算に委任10回（常に同一結果）1回（計算式自体の検証のみ）

検算：AIに直接計算させる方式は10回すべてを個別に確認する必要があるのに対し、関数呼び出しで委任する方式は、計算式（関数）自体を1回検証すれば、同じ入力に対して常に同じ結果が返ることが保証されるため、以降の個別検算は不要になります。確認回数の差は10－1＝9回分です。ただし、これは計算式自体が正しく作られていることが前提であり、関数呼び出しを使えば自動的に正確になるわけではありません。呼ぶ処理（関数）自体を間違えれば、結果はやはり誤ります。

関数の設計と権限の分類

実務で関数呼び出しを設計する際は、用意する関数を大きく2種類に分けて考えると整理しやすくなります。

  • 読み取り専用の関数：データの照会・集計・計算など、実行しても外部の状態を変えないもの。誤りが起きても被害が限定的です。
  • 副作用を伴う関数：メール送信・ファイル更新・発注・支払指示など、実行結果が外部に反映されるもの。AIの判断ミスがそのまま実行されてしまうリスクがあります。

財務・経理業務では、まず読み取り専用の関数から導入し、副作用を伴う関数を組み込む場合は人による承認を必ず挟むのが基本方針とされています（ヒューマン・イン・ザ・ループ）。あわせて、AIが渡してくる引数（期間・会社コード・金額など）が妥当な範囲に収まっているかを、関数側でも検査することが求められます。AIを信頼して引数をそのまま受け取らないという点が設計上の要です。さらに、外部から読み込んだ文書に紛れ込んだ指示によって意図しない関数が呼ばれてしまうプロンプトインジェクションと組み合わさると、被害が拡大しやすくなる点にも注意が必要です。

実務での使い方

  • 財務指標の計算をAIの文章生成ではなく、あらかじめ検証済みの計算式（関数）に実行させる
  • 決算資料や契約書から数値・条件を抽出させ、その数値を照会用の関数に渡して社内データベースと突合する
  • 市場データや為替レートなど時点によって変わる数値の取得を外部の取得関数に任せ、AIの記憶に頼らせない

どの使い方であっても、関数が返した結果をそのまま最終数値として採用する前に、担当者が原本資料や既存システムの値と突き合わせる検証工程を挟むことが欠かせません。関数呼び出しは計算過程の再現性を高めますが、入力データの誤りや関数そのものの設計ミスまでは防げないためです。金融機関向けAIアシスタントの権限管理やログの設計については金融AIアシスタントの参照アーキテクチャで解説しています。

実務家が確認するポイントとよくある誤解

よくある誤解は、「関数呼び出しを使えば計算結果は完全に正確になる」というものです。実際には、AIがどの関数を呼ぶかを間違えたり、渡す引数を取り違えたりすれば、結果は誤ったまま返ってきます。関数呼び出しが保証するのはあくまで「同じ関数・同じ入力なら同じ計算過程を通る」という再現性であり、正しさそのものではありません。導入時に確認すべき点として、①副作用のある関数に無条件でアクセスさせていないか、②引数の検査（バリデーション）が関数側にあるか、③外部から取り込んだ文章がAIの判断を誘導し、意図しない関数呼び出しにつながらないか、の3点が挙げられます。AIが返す数値をそのまま正しいものとして扱わない姿勢はハルシネーションへの対策とも共通します。

日本実務での扱い

関数呼び出しという技術要素そのものを直接規定する日本の法令・ガイドラインは、2026年8月時点で確認できていません。もっとも、AIを業務システムに組み込む際の考え方としては、総務省・経済産業省が公表する「AI事業者ガイドライン」がリスクに応じた対策の実施を求めており、参考になります。実務上は、社内で①どの関数（処理）にAIからのアクセスを許すかの棚卸し、②副作用を伴う処理を実行する前の承認フロー、③委託先ベンダーが提供するAIサービスが呼び出す関数の範囲、といった社内規程・委託先管理の論点として扱われることが一般的です。制度・指針は改定が続く分野であるため、適用の判断は最新の公表資料と専門家への確認が前提になります。

面接・実務で問われるポイント

面接や実務では、「なぜAIに直接計算させず、関数呼び出しを使うのか」を、再現性・検証可能性の観点から説明できるかが問われます。また、「どのような関数であれば安全に自動実行してよいか」という線引き（読み取り専用か、副作用を伴うか）についての考え方も、実務理解の深さを示すポイントです。「関数呼び出しを使えば結果は自動的に正確になる」と単純化せず、関数選択・引数・検証まで含めてリスクを語れるかが評価されます。

よくある質問（FAQ）

Q. 関数呼び出しを使えば、AIの計算ミスは完全になくなりますか。
A. いいえ。計算そのものの誤りは減らせますが、AIがどの関数をどの引数で呼ぶかを誤れば、結果は誤ったまま返ります。関数の選択・引数を含めた検証が必要です。

Q. 副作用のある処理（送金・発注など）もAIに任せてよいのですか。
A. 慎重な検討が必要です。実行前に人が確認・承認するプロセスを挟むのが基本とされ、無条件の自動実行は避けるべきとされています。

出典・参考（2026-08-16確認）