AIエージェントが複数のツールを使うたびに、すべての中間結果をモデルへ戻して「次は何をするか」を考え直させる必要はありません。OpenAIはResponses APIに、モデルがJavaScriptを書いてツール群を制御する「Programmatic Tool Calling」を用意しました。重要なのは新機能そのものより、判断が必要な工程と、コードに任せる工程を分ける設計です。
Programmatic Tool Callingとは
OpenAIの公式ドキュメントによると、Programmatic Tool Callingでは、モデルが生成したJavaScriptがツール呼び出しを調整します。並列実行、ループ、条件分岐が使え、中間結果をホストされた実行環境に保持したまま処理できます。
たとえば100件の商品情報を取得し、条件に合うものだけを重複除去して集計する場合を考えます。従来のように全結果をモデルへ戻すのではなく、コード側で絞り込み、最終判断に必要な小さな構造化データだけを返せます。OpenAIも、これによりツール中心の処理でトークン、モデルとの往復、追加指示を減らせると説明しています。
「コードに任せる範囲」を先に決める
公式ドキュメントが示す使い分けは明快です。
- コード向き：複数結果の絞り込み、結合、順位付け、重複除去、集計、形式検証
- モデル向き：検索結果ごとに意味判断が必要な処理、適応的な探索
- 直接呼び出し向き：書き込み、承認が必要な操作、引用や元の成果物を保持すべき最終確認
在庫確認と需要取得は並列化できますが、発注の実行は別です。「不足数を計算する」まではコードに任せ、「本当に注文するか」は明示的な承認境界に戻すべきです。高速化のために、責任の境界まで自動化してはいけません。
実行環境の制約は安全設計の材料になる
生成プログラムは毎回、新しい隔離済みV8環境で動きます。Node.js、パッケージ追加、直接のネットワークアクセス、汎用ファイルシステム、サブプロセス、永続的なJavaScript状態は提供されません。外部システムへ到達できるのは、リクエストで許可したツール経由だけです。
さらに各ツールのallowed_callersで、モデルからの直接呼び出し、プログラムからの呼び出し、その両方を指定できます。これは単なるAPI設定ではなく、工程ごとに権限を狭める仕組みです。集計用プログラムには読み取りツールだけを渡し、変更系ツールは直接呼び出しと承認に限定する、といった分離ができます。
運用では「停止条件」と「証拠」を仕様にする
プログラムに「効率よく処理して」とだけ伝えるのは危険です。OpenAIは、対象工程、利用可能なツール、返却形式、停止条件、再試行回数、副作用の禁止、失敗時の構造化結果まで具体化する例を示しています。
設計レビューでは、次の4点を先に決めると実装が安定します。
- どの工程までを決定論的なコードにするか
- 最終判断へ残す根拠データは何か
- 何回失敗したら停止するか
- 書き込みや承認をどこで分離するか
GPT-5.6の公式発表では、この機能を使い、ツールの調整、中間結果の処理、進行状況の監視、次の行動選択を軽量なプログラムで行えると説明しています。ただし、コード化できることと、コード化すべきことは同じではありません。
まとめ
エージェント設計の要点は、すべてをAIに考えさせることではありません。予測可能な制御フローはコードへ、意味判断はモデルへ、外部への変更は承認境界へ分けます。賢いモデルを使うだけでなく、「考えなくてよい仕事」を明確にすることが、速さ・コスト・監査性を同時に改善する近道です。
公式ソース