AIがツールを呼んだら処理済み？Function callingでアプリが実行すること

情報確認日：2026年10月15日

開発者が定義した関数を使うFunction callingでは、モデルが返すのは「この関数へ、この引数で依頼する」という呼出し情報です。その時点で予約や送信が完了したとは限りません。アプリ側が内容と権限を確認して処理を実行し、その結果をモデルへ戻します。

以下はOpenAIのResponses APIで開発者が用意する関数を中心にした説明です。提供元が実行環境を持つ組込みツールとは、処理を担う場所が異なります。

モデルが決めることと、アプリが行うこと

OpenAIの公式ガイドは、Function callingを、モデルと外部システムをつなぐ仕組みと説明しています。モデルへ利用可能な関数を知らせると、必要に応じて関数名と引数を返します。Function callingの公式ガイド

たとえば天気を調べる関数なら、モデルは場所としてParisを指定できます。その情報を受けたアプリが、実際の天気データを取得します。モデルが関数名を出力しただけで、天気の取得先と通信したことにはなりません。

予約や返金でも同じ区別が必要です。「予約する関数を呼んだ」と「予約システムが受け付けた」は別の段階として扱います。画面へ完了と表示するのは、実行側で成功を確認してからです。

ガイドが示す大まかな流れは、次の5段階です。

最初の回答で終わるとは限らず、必要に応じてこの流れを続けます。アプリが関数を実装していなかったり、結果を返さなかったりすれば、ツールの一覧を渡しただけでは仕事は完了しません。

組込みのWeb検索やコード実行などは、プラットフォーム側が用意するツールです。自分で定義した関数と同じ名前の「ツール」でも、誰が実行し、結果を返す仕組みなのかを公式仕様で確認します。

Responses APIの呼出し項目には、function_callという種類、関数名、JSON形式の引数、call_idなどが含まれます。アプリは関数名に対応する処理へ渡し、結果を該当する呼出しに結び付けて返します。

公式ガイドは、応答に呼出しが0件、1件、複数件含まれる場合を説明しています。いつも一つだけあると決めず、返された各項目を扱う設計にします。

結果を返さない送信処理などでも、成功・失敗を示す文字列を返す方法が公式に案内されています。何も確認せず、常に成功と返す実装では、モデルも処理の失敗を把握できません。

関数の引数はJSON Schemaで定義できます。strict:trueは、対応するスキーマに沿う呼出しを得るための設定です。必須項目や追加プロパティの扱いなど、仕様上の条件があります。

ただし、形式が正しくても、その利用者が対象注文を操作してよいか、金額が業務上の上限内かまでは別です。数値として正しい「10000」が、許された返金額なのかは、アプリの業務データで確認します。

権限や本人確認の判断を、モデルが返した利用者IDだけで済ませないようにします。既にアプリが把握している注文IDなどをモデルに埋めさせず、コード側で渡す設計も、公式ガイドの推奨事項です。

天気の読取りと、メール送信・予約変更・返金では影響が異なります。アプリで許す処理を決め、書込みの対象、内容、実行前の確認を具体化します。

たとえば予約変更なら、現在の予約、新しい日時、料金の変化を利用者へ示し、必要な同意を得た後に実行する構成が考えられます。これは設計例で、Function callingを有効にすれば、その確認画面が自動で付くという意味ではありません。

利用可能な関数の説明には、何をするときに使うか、引数の意味、結果が何を示すかを明記します。誤用が続く場合は、説明だけでなく、関数の分け方や、そもそもモデルに決めさせる範囲を見直します。

処理中に通信が切れた場合、モデルの返答が届かなかったことと、外部システムが未処理だったことは同じではありません。再び送信や予約を行う前に、実行側の記録を確認します。

アプリのログには、呼出しと対象、結果、確認待ちかどうかを対応させます。秘密情報や不要な個人情報まで記録する必要はありません。利用者へは、確認できた成功と、結果が未確認の処理を分けて伝えてください。

動かないときは、関数を知らせたか、呼出しを受信したか、アプリが実行したか、結果を正しい呼出しへ戻したかを順に追います。API側のエラーと自分の業務処理のエラーを分け、日時と呼出しの対応を開発担当者へ示すと、停止した段階を調べやすくなります。

執筆・検証：カネさん（政経プラスチャンネル運営）＋ ChatGPT

ほかの記事を探す