Programmatic Tool Calling は「まとめ処理」と「承認が要る実行」を混ぜるなと迫る

何が変わったのか

この guide は tool use を「model が関数名を返す」だけの話から一段進めています。generated JavaScript を hosted runtime で動かし、parallel call、loop、condition、途中結果の整理まで許す一方、その runtime 自体はかなり狭く制限されています。外部との接点は有効化した tools 経由だけです。 さらに重要なのは、使い分けの規則をかなり具体的に書いている点です。predictable control flow なら Programmatic Tool Calling、semantic judgment や approval-sensitive action、native artifact や citation の最終検証は direct tool calling を使う。つまり「便利だから全部 program」にしないための guardrail が本文の中心です。

なぜ重要か

日本語圏では「複数 tool をコードで束ねれば agent が賢くなる」という語りになりやすいですが、運用で本当に大事なのは責任境界です。どこまでが read-only の整形で、どこからが money movement、外部送信、在庫変更、公開更新のような重い操作なのかを明確にしないと、事故時に説明できません。 創業者や PM にも意味があります。Programmatic Tool Calling は機能追加ではなく、workflow 分解を迫る仕様だからです。集計や比較は高速化できても、承認や最終確認まで自動で飲み込ませるべきではない、と公式が書いている点は導入判断の基準になります。

技術的ポイント

1. OpenAI は generated program を fresh な isolated V8 runtime で実行し、Node.js、package install、direct network、汎用 filesystem、subprocess、永続 JavaScript state は持たせません。外部接続は request で有効化した tool 経由だけです。
2. `allowed_callers` で tool ごとに direct だけ許すか、program からだけ許すか、両方許すかを分けます。つまり「その tool を誰が呼べるか」が API 契約に入ります。
3. guide は read-only 集約や predictable な依存 call には program を勧めますが、write や approval-sensitive action には direct tool calling を既定にせよとしています。承認境界を保つためです。
4. MCP tool は `require_approval` で program を一時停止できます。つまり program があるから approval が消えるのではなく、どこで止まるかを app 側が設計する必要があります。
5. guide の orchestration 例では、side-effecting action を program に繰り返させず、retry 回数、停止条件、structured failure を先に決めるよう求めています。便利さより failure behavior の明文化が優先です。

英日キーワード

関連原典

• Programmatic Tool Calling
• Function calling guide
• Using tools guide
• Computer use guide