GPT-5.6 プログラマティックツール呼び出し: モデルがオーケストレーションコードを生成

古典的な関数呼び出しは、すべてのエージェント開発者が熟知している形をしています。モデルは1つのツール呼び出しをリクエストし、アプリケーションがそれを実行し、結果を付加し、モデルが次のリクエストを行います。4つのツールなら4回の往復、40のツールなら40回の往復です。各パスはネットワークの遅延と再請求されるコンテキストを追加します。OpenAIがGPT-5.6を2026年7月9日に一般公開した際、この手間のかかるプロセスから解放される方法として、Responses APIにおけるプログラマティックツール呼び出しを提供しました。

その考え方は直接的です。コードがループ内で実行するためにツール呼び出しを一つずつ返す代わりに、モデル自身が複数のツール呼び出しをオーケストレートするJavaScriptを作成します。そのコードは、ネットワークアクセスなしの隔離されたV8ランタイムで実行されます。ツールは、コードが外部世界にアクセスできる唯一の方法であるため、OpenAIの関数呼び出しですでに考慮していたセキュリティ境界はそのまま維持されます。変わるのはオーケストレーション、つまりこれまではアプリケーション内にあったループ、条件分岐、集約の部分です。

ボタン

この変化はAPIのあなたの側にも及びます。あなたが公開するすべてのツールは、これまでのようにターンごとに慎重に1回呼び出されるのではなく、モデルが数十回まとめて呼び出す可能性のある契約となります。スキーマの精度、エラーの形式、レートの挙動は、先週よりも重要になります。この記事では、何が提供されたのか、なぜ以前のループが問題だったのか、何が変わらないのか、そしてApidogを使ってツールエンドポイントをモデルに渡す前に準備する方法について説明します。

ボタン

要約

GPT-5.6は2026年7月9日にGA（一般提供）されました。GA時点で、Responses APIはOpenAIの開発者ドキュメントで確認されているプログラマティックツール呼び出しを獲得しました。
往復ごとに1つのツール呼び出しを行う代わりに、モデルがあなたのツールに対してループ、条件分岐、集約を構成するJavaScriptを作成します。
生成されたコードは、ネットワークアクセスなしの隔離されたV8サンドボックスで実行されます。ツール定義は外部システムへの唯一のパスであり続けるため、セキュリティ境界は移動しません。
ツール呼び出しの数に比例して増加していたレイテンシとトークンコストが解消されます。これは、古典的なエージェントループで問題となっていた点です。
この機能はまだ新しいです。正確なリクエストパラメータと制限についてはOpenAIのAPIリファレンスに記載されているので、開発する前に読んでください。
モデルがツールをオーケストレートする前に、各ツールエンドポイントをテストおよびモックしてください。スキーマの曖昧さは、ループ内で繰り返されるバグとなります。

7月9日に提供されたもの

GPT-5.6は、最も深い推論のためのgpt-5.6-sol、バランスの取れた作業のためのgpt-5.6-terra、高速で費用対効果の高い大量処理のためのgpt-5.6-lunaという3つの階層ファミリーとして登場しました。エイリアスgpt-5.6はSolにルーティングされます。これら3つすべては、7月8日にアクセス制限が解除された2週間の限定プレビューの後、プラン制限なしでAPIを通じてセルフサービスで利用可能です。

モデルファミリーは発表当日の注目を最も集めましたが、エージェント開発者にとっては新しいAPIサーフェスの方がより大きなニュースです。MarkTechPostの発表記事およびOpenAI自身のドキュメントによると、Responses APIはGA時に以下の4つの機能を追加しました。プログラマティックツール呼び出し、マルチエージェントベータ版、ターン間の推論の永続化、および元の画像寸法を保持するビジョン詳細設定です。

プログラマティックツール呼び出しが目玉機能です。OpenAIは、これをモデルがツール呼び出しをオーケストレートするJavaScriptを作成し、それがネットワークアクセスなしの隔離されたV8ランタイムで実行されるものと説明しています。モデルはターンごとのリクエスターであるのをやめ、オーケストレーションレイヤーの作成者となるのです。

プログラマティックツール呼び出しが置き換えるループ

以下は、今日のほとんどすべての本番環境のエージェントが使用している、Responses APIに対する古典的な関数呼び出しの例です。

import OpenAI from "openai";
const client = new OpenAI();

const tools = [
  {
    type: "function",
    name: "get_flight_status",
    description: "Return live status for a flight by IATA flight number.",
    parameters: {
      type: "object",
      properties: {
        flight_number: {
          type: "string",
          description: "IATA flight number, for example SQ317"
        }
      },
      required: ["flight_number"]
    }
  }
];

let response = await client.responses.create({
  model: "gpt-5.6",
  input: "Which of these 12 flights are delayed: SQ317, BA15, UA857...",
  tools
});

モデルはデータなしでは回答できないため、関数呼び出しを発行します。あなたのコードが検索を実行し、function_call_outputアイテムを付加し、再度APIを呼び出します。

// ツール呼び出しごとに1回の往復。このループはコストです。
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response); // your code, your infra
  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

12便の場合、このループは12回実行される可能性があり、各イテレーションで2重のコストが発生します。まずレイテンシについてです。呼び出しN+1がモデルが結果Nを見ることに依存するため、OpenAIへの完全なネットワーク往復とモデル時間が直列で発生します。次にトークンについてです。ツール結果はコンテキストに蓄積されるため、後のイテレーションでは初期のイテレーションで生成されたすべてが再処理されます。エージェントを連結すると、この複合的な問題はさらに悪化します。各ステップが10回の呼び出しループを内包する5ステップのエージェントは、50回のモデル呼び出しとして請求されます。

このループのどの部分も知能ではありません。それは配管のようなものであり、今週までモデル自身がこの配管を記述する方法はありませんでした。

プログラマティックモードが形をどう変えるか

プログラマティックツール呼び出しを使用すると、モデルはフライトの質問に異なる方法で答えます。12のフライト番号をループ処理し、それぞれにget_flight_statusを呼び出し、遅延ステータスでフィルタリングし、遅延時間でソートし、その集計を返す短いJavaScriptプログラムを作成します。サンドボックスがそのプログラムを実行します。ツールは依然として実際の作業を行いますが、それらを囲む制御フローはモデルに属するようになります。

以下の3つの特性により、これは警戒すべきではなく、実用的なものとなります。

ランタイムは隔離されています。OpenAIは生成されたJavaScriptをネットワークアクセスなしのV8サンドボックスで実行します。コードはURLをフェッチしたり、ソケットを開いたり、独自の判断で何かを外部に持ち出したりすることはできません。
ツールが唯一の出口です。すべての外部への影響は、あなたが定義したツールサーフェスを経由します。もしdelete_recordツールを公開していなければ、生成されたコードがレコードを削除することはできません。
制御フローが表現豊かになります。ループ、条件分岐、早期終了、結果の集約など、N回の往復が必要だったパターンが、単一の応答サイクル内で発生するようになります。

	古典的な関数呼び出し	プログラマティックツール呼び出し
制御フローを記述するのは誰か	あなたのアプリケーション	モデル（JavaScriptとして）
N回のツール呼び出しにかかる往復回数	N回、直列実行	1回の応答サイクル
オーケストレーションが実行される場所	あなたのインフラストラクチャ	隔離されたV8サンドボックス、ネットワークなし
ツールの実行方法	あなたのコードが呼び出す	定義されたツールサーフェス経由で
セキュリティ境界	ツール定義	ツール定義（変更なし）

変わらないこと

あなたは引き続き、上記のコードと全く同じように、名前、説明、JSON Schemaパラメータを使用してツールを定義します。モデルはあなたが宣言したツールへの呼び出しのみを構成できます。つまり、「このエージェントは私のシステムに何ができるのか」という問いに対する答えは、これまでと同じです。すなわち、あなたのツールサーフェスが許可することだけであり、それ以外は何もできません。

スキーマの品質は、これまで以上に重要になります。古典的なループでは、曖昧なパラメータ記述は1回の誤った呼び出しを生じさせ、次の往復の前にそれを捕捉して修正することができました。プログラマティックモードでは、同じ曖昧さがループに組み込まれ、1つの結果を見る前にすべてのイテレーションで繰り返される可能性があります。構造化出力のために培った習慣が直接適用されます。厳密な型、閉じたセットに対する列挙型、単位と形式を明記する記述、真に必須であるフィールドの指定などです。

制限と未解決の疑問

この機能はまだ数日しか経っていません。これに基づいてエージェントスタックを再構築する前に、いくつかの注意点があります。

正確なリクエストパラメータ、実行制限、タイムアウト動作については、OpenAIのAPIリファレンスとモデルガイドを参照してください。GAリリース後の磨き上げの過程でパラメータ名が変更される可能性があるため、この機能に対してコードを書く前にリファレンスを読んでください。
デバッグは新たな領域です。オーケストレーションがリポジトリ内にあったときはブレークポイントを設定できましたが、今や制御フローの一部はリクエストごとに新たに生成されます。サンドボックスが行うツール呼び出しシーケンスをログに記録することは、重要な可観測性タスクとなります。
まだ本番環境での実績はありません。Simon WillisonによるGPT-5.6の初日レビューは、独立したテストで明らかになったことの良い記録となっています。公式ドキュメントで言及される前に、そこで問題点が見つかることを予想してください。
健全なロールアウト順序として、まずリードオンリーのツールから始め、生成されたオーケストレーションを監視し、古いループとのトークン計算を検証し、その後で副作用のあるツールを公開してください。

あなたのツールは、他の誰かのコードが呼び出すAPIになりました

古典的な関数呼び出しでは、ツールは往復ごとに1回呼び出され、人間が作成したループがペースと順序を決定していました。プログラマティックツール呼び出しでは、生成されたコードがあなたのツールを一斉に呼び出し、その応答に基づいて分岐し、出力を集約します。各ツールは、実行される前にあなたがレビューすることのない、機械によって書かれたクライアントが消費するAPI契約となります。

これにより、以下の4つのことに対するハードルが上がります。

スキーマの精度。すべてのパラメータ記述で単位、形式、範囲を明記してください。曖昧な日付形式は、もはや単一の悪い呼び出しではなく、それらのループとなります。
エラーの形式。生成されたコードは失敗時に分岐します。エラーメッセージが文字列に埋め込まれた200を返すツールは、あなたのスキーマに対して書かれたオーケストレーションを誤解させます。正直なステータスコードと構造化されたエラーボディを返してください。
冪等性（Idempotency）とレートの挙動。1分間隔で到着していた12回の呼び出しが、今や一斉に到着する可能性があります。モデルがあなたのエンドポイントの挙動を発見する前に、そのパターン下で何が起こるかを知っておいてください。
レイテンシ。8秒かかるツールは、以前はターンごとに1回であれば許容されていました。12回反復するループの中では、それが応答時間を決定することになります。

ここに真のAPIワークベンチの価値があります。各ツールエンドポイントの仕様を定義またはインポートし、それに対してテストリクエストを送信し、応答スキーマがツール定義の約束と一致することを確認してください。さらに一歩進んで、ツールAPIをモックして、本番環境に触れることなく、予測可能な偽データに対してオーケストレーションを試すことができます。Apidogをダウンロードすると、内蔵のモックサーバーが定義したすべてのエンドポイントに対してスキーマに沿った応答を提供するため、実際のレコードに触れる前にモデルに完全なツールサーフェスを提供し、そのオーケストレーションを観察することができます。

ボタン

その他のGA機能の概要

プログラマティックツール呼び出しは単独で提供されたわけではありません。Responses APIに隣接する2つの追加機能が重要です。

マルチエージェント（ベータ版）：APIによって管理される並列サブエージェント実行。初期段階であり、期待するよりも注視すべき機能です。
推論の永続化：reasoning.contextを介してターン間で推論コンテキストが再利用されるため、長期間のエージェントセッションで毎ターン同じ結論を再導出する必要がなくなります。

これらは両方ともプログラマティックツール呼び出しと組み合わさることで効果を発揮します。ターン間で推論を保持し、自身のオーケストレーションを記述するエージェントは、タスクごとに無駄な作業を大幅に減らすことができます。

プログラマティックツール呼び出し vs ウルトラモード

この発表ではウルトラモードも提供され、どちらも1リクエストあたりでより多くのことを行うため混同されがちですが、それぞれ異なるボトルネックを解決します。

ウルトラモードはマルチエージェント設定で、デフォルトで4つのエージェントを並行して実行し、意図的に多くのトークンを消費して実時間を短縮します。OpenAIによると、これによりTerminal-Bench 2.1のスコアが88.8%から91.9%に向上します。これはChatGPT WorkのProおよびEnterpriseプランで、またCodexではPlusプラン以上で利用可能です。プログラマティックツール呼び出しは、1つのエージェントがコードでツールをオーケストレートするAPI機能です。ウルトラモードは思考を並列化し、プログラマティックツール呼び出しは実行の往復回数を削減します。詳細な説明は弊社のGPT-5.6ウルトラモードに関する記事にありますが、簡単に言うと、ボトルネックがツール呼び出しのレイテンシにある場合はプログラマティックツール呼び出しを、難しい問題に対する検討時間にある場合はウルトラモードを選びます。

ボタン

よくある質問

既存のツール定義を書き直す必要がありますか？

いいえ、必要ありません。ツールは上記のコードに示されているのと同じJSON Schemaの形状を維持しており、古典的な関数呼び出し用に書かれた定義もそのまま引き継がれます。価値のある作業は、それらを厳密にすることです。列挙型を追加し、形式を明記し、生成されたコードが誤解しないように記述を十分に具体的にしてください。

生成されたJavaScriptはインターネットにアクセスできますか？

いいえ、できません。コードはネットワークアクセスなしの隔離されたV8ランタイムで実行され、宣言されたツールがサンドボックス外の何かに影響を与える唯一の方法です。そのため、あなたのツールサーフェス全体がリスクモデルとなるため、パブリックAPIに与えるのと同じ注意を払って、どのツールを公開するかを監査してください。

どのGPT-5.6モデルがプログラマティックツール呼び出しをサポートしていますか？

OpenAIのドキュメントでは、GPT-5.6ファミリー向けのResponses APIサーフェスとして記載されており、3つのティアすべて（gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna）がすべてのAPIアカウントでセルフサービスで利用可能です。いずれかのティアにコミットする前に、ティアごとの詳細についてAPIリファレンスを確認してください。主要なセットアップと最初のリクエストのチュートリアルについては、GPT-5.6 APIの使い方を参照してください。

これはコードインタープリターとどう違うのですか？

コードインタープリターは、分析、チャート、ファイル変換といった成果物としてコードを実行します。プログラマティックツール呼び出しは、宣言されたツールを調整することのみを目的としたコードを生成します。成果物は集約されたツール結果であり、コード自体ではありません。

現状と今後の展望

往復ループは、あなたがリリースしたすべてのエージェントの中で最も面白みのない部分でしたが、GPT-5.6はそれをオプションにしました。オーケストレーションはモデルに移り、クリーンで正確、そして適切に動作するツールAPIに対する責任は、これまで以上にあなたの側にかかってきます。

次のステップは具体的です。読み取りが中心となるワークフローを一つ選び、それに必要なツールスキーマを作成または厳格化し、各エンドポイントをApidogのAPIクライアントとモックサーバーでテストして、大量の呼び出しや不正な入力に対しても契約が保持されることを確認してください。モデルがあなたのツールに対してコードを書き始めたとき、そのコードがすでにテスト済みのサーフェスから読み取られることを望むでしょう。