Function calling は「AIに外部処理を任せる境界」を雑にしないための基本部品

要点

要点まとめ

AI に外部システムを触らせると、便利になる一方で『勝手に送る』『勝手に更新する』『間違った相手に処理する』という事故も起きうる。
だから最初に分けるべきなのは、情報を読むだけの操作と、何かを変更する操作である。読み取りは広めに許せても、書き込みは確認や制限が要る。
function calling は、その線引きを自然文のお願いで済ませず、AI が外部処理を呼ぶ入口をあらかじめ決めておく仕組みである。
OpenAI の guide は、AI に任せる部分と、アプリ側が必ず縛る部分を分けている。AI は呼び出し内容を提案し、実際に処理を走らせる責任はアプリ側に残る。
そのうえで、入力の形を固定する、使える処理を絞る、同時に走らせてよい処理を分ける、という実装上の制御が出てくる。

読解

何が変わったのか

この guide は、『AI が API を呼べる』という雑な説明で終わっていません。OpenAI は function tool、つまり AI が使える外部処理の入口を JSON schema で定義し、モデルはその定義に沿った引数だけを返し、実際の処理はアプリ側が実行して結果をまたモデルへ返す、という往復を前提にしています。さらに `tool_choice` によって使える関数の幅や呼び出し強制を制御でき、parallel function calling では同時実行の安全性まで設計対象になります。

日本の文脈

なぜ重要か

日本の実装では、web search、MCP、code execution、社内 API 呼び出しを全部まとめて『tool use』と呼びがちです。ここが粗い。built-in tool と custom function では責任が違います。function calling を理解すると、『どの action を hosted tool に寄せ、どの action を自前 function に残すか』を切り分けやすくなります。AI が賢く見えることより、失敗時に誰がどこを直すのかを明確にできる点のほうが重要です。

技術ポイント

技術的ポイント

function calling は function tool を JSON schema で定義し、その schema に沿った引数をモデルに生成させる。自由文のお願いではなく、受け付ける入力の形を先に固定するのが本体である。
docs は `strict: true` を付けた schema 例を示している。これは余計な項目を混ぜにくくし、必要項目の抜けも減らすための厳格モードとして読むと分かりやすい。
実処理は model が直接行うのではなく、application、つまりアプリ側が tool call を受けて関数を実行し、その結果を再び model に返す。副作用、認可、監査ログ、再試行制御は application 側の責任で残る。
`tool_choice` では auto、required、特定 function の強制、allowed tools の部分制限を指定できる。呼べる関数を全部渡して model に任せる以外の運用が前提化されている。
parallel function calling は体感速度を上げうるが、複数の write action や依存順序のある処理を同時実行すると事故の面積が広がる。速さの前に、どこまで同時実行して安全かを決める必要がある。

用語

英日キーワード

英語	日本語	補足
function calling	関数呼び出し	モデル出力をアプリ側の関数実行に接続する仕組み。schema 設計と失敗時処理が実装品質を左右する。
JSON schema	JSONスキーマ	関数や構造化出力に渡す入力の形を定義する仕様。AI に外部処理を任せる時の受け口を狭める。
strict	厳格モード	schema から外れた余計な項目を出しにくくする設定。便利さより入力制御を優先する場面で使う。
tool_choice	ツール選択制御	モデルにどの tool を使わせるか、使わせないか、必ず使わせるかを制御する設定。
parallel function calling

試す

試すなら

まず外部処理を読み取り、下書き作成、確定書き込みに分け、書き込み系だけ別 function と確認手順に分離する。
function schema は最小項目から始め、`additionalProperties` を許し過ぎない。
`tool_choice` を auto にする前に、どの function まで model に見せるかを棚卸しする。
parallel 呼び出しを使うなら、同時に走ってよい関数と直列でなければ危険な関数を先に分類する。

注意

注意点

schema を厳密にしても、業務上妥当な引数かどうかまでは自動保証されない。金額、日時、顧客 ID の整合性確認は別に要る。
function calling は外部処理の入口を整えるが、認可や監査を代行しない。社内 API をつなぐほどこの責任は重くなる。
hosted tool と custom function の違いを曖昧にしたまま設計すると、失敗時の責任分界が崩れる。