Akira

Posted on Jul 10 • Originally published at apidog.com

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

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

今すぐApidogを試す

考え方は直接的です。アプリケーションがツール呼び出しを1件ずつ実行する代わりに、モデル自身が複数のツール呼び出しをオーケストレートするJavaScriptを作成します。そのコードはネットワークアクセスのない隔離済みV8ランタイムで実行されます。コードが外部へアクセスできる経路はツールだけなので、OpenAIの関数呼び出しで設計していたセキュリティ境界は維持されます。

変わるのはオーケストレーションです。これまでアプリケーション側にあったループ、条件分岐、結果の集約を、モデルが生成するコードへ移します。

この変更は、公開するツールAPIの設計にも影響します。各ツールはターンごとに慎重に1回呼び出されるのではなく、モデルから短時間に数十回呼び出される可能性があります。スキーマの精度、エラー形式、レート制限、冪等性はこれまで以上に重要です。

この記事では、プログラマティックツール呼び出しで何が変わるのか、既存の関数呼び出しループの課題、そしてApidogを使ってツールエンドポイントを準備・検証する手順を説明します。

要約

GPT-5.6は2026年7月9日にGA（一般提供）されました。GA時点で、Responses APIにはプログラマティックツール呼び出しが追加されました。
往復ごとに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経由のセルフサービス利用が可能になりました。

モデルファミリーが注目を集めましたが、エージェント開発者にとってはResponses APIの新しい機能も重要です。MarkTechPostの発表記事およびOpenAIのドキュメントによると、GA時に追加された主な機能は次の4つです。

プログラマティックツール呼び出し
マルチエージェント（ベータ版）
ターン間の推論の永続化
元の画像寸法を保持するビジョン詳細設定

この中で、ツールを使うエージェントの設計を直接変えるのがプログラマティックツール呼び出しです。モデルはツール呼び出しをオーケストレートする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を入力に追加して、再度Responses APIを呼び出します。

// ツール呼び出しごとに1回の往復が必要になる
while (hasFunctionCalls(response)) {
  const outputs = await executeToolCalls(response);

  response = await client.responses.create({
    model: "gpt-5.6",
    previous_response_id: response.id,
    input: outputs,
    tools
  });
}

12便を確認する場合、このループは最大12回実行される可能性があります。コストは主に2つです。

レイテンシ: 呼び出しN+1は結果Nに依存するため、モデル処理とネットワーク往復が直列化されます。
トークン: ツール結果がコンテキストに蓄積されるため、後続のイテレーションでは先行イテレーションの情報も再処理されます。

エージェントを連結すると、この問題はさらに大きくなります。たとえば、各ステップが10回の呼び出しループを持つ5ステップのエージェントでは、最大50回のモデル呼び出しが発生します。

このループの大部分は推論ではなく配管処理です。従来は、その配管をアプリケーションが実装する必要がありました。

プログラマティックモードで変わること

プログラマティックツール呼び出しでは、モデルはフライトの質問に対して異なる形で処理します。

フライト番号の一覧をループする
各番号に対してget_flight_statusを呼び出す
遅延している便だけをフィルタリングする
遅延時間でソートする
集約結果を返す

この制御フローを含むJavaScriptをモデルが作成し、サンドボックスが実行します。ツール自体が実際の処理を行う点は同じですが、ツールの呼び出し順序、分岐、集約はモデル側のオーケストレーションになります。

項目	古典的な関数呼び出し	プログラマティックツール呼び出し
制御フローを記述する主体	アプリケーション	モデル（JavaScriptとして）
N回のツール呼び出しに必要な往復	N回、直列実行	1回の応答サイクル
オーケストレーションの実行場所	自分のインフラ	ネットワークなしの隔離済みV8サンドボックス
ツールの実行経路	アプリケーションコードが呼び出す	定義済みツールサーフェス経由
セキュリティ境界	ツール定義	ツール定義（変更なし）

実装時に重要なのは、次の3点です。

ランタイムは隔離されている

OpenAIによると、生成されたJavaScriptはネットワークアクセスのないV8サンドボックスで実行されます。コードが任意のURLを取得したり、ソケットを開いたりすることはできません。
ツールが唯一の外部アクセス経路になる

すべての外部副作用は、開発者が定義したツールを経由します。delete_recordを公開していなければ、生成コードはレコードを削除できません。
制御フローをより表現できる

ループ、条件分岐、早期終了、結果の集約といったパターンを、N回のモデル往復なしで実行できます。

変わらないこと

ツール定義の基本形は変わりません。引き続き、名前、説明、JSON Schemaパラメータを使ってツールを定義します。モデルが構成できるのは、宣言したツール呼び出しだけです。

つまり、「このエージェントは何を実行できるか」という問いへの答えは変わりません。答えは、ツールサーフェスで許可したことだけです。

ただし、スキーマ品質の重要性は上がります。古典的なループでは、曖昧なパラメータ記述が1件の誤った呼び出しにつながっても、次の往復前に修正できる余地がありました。プログラマティックモードでは、同じ曖昧さがループに組み込まれ、複数回繰り返される可能性があります。

構造化出力で培った設計原則をそのまま適用してください。

型を厳密に指定する
閉じた値集合には列挙型を使う
単位とフォーマットをdescriptionに明記する
必須項目だけをrequiredに含める
エラーケースをレスポンススキーマとして定義する

たとえば、日時やステータスを受け取るツールでは、曖昧な文字列ではなく制約を明示します。

const tools = [
  {
    type: "function",
    name: "search_orders",
    description: "注文を検索する。日時はISO 8601形式、金額はJPYの整数で扱う。",
    parameters: {
      type: "object",
      additionalProperties: false,
      properties: {
        status: {
          type: "string",
          enum: ["pending", "paid", "shipped", "cancelled"],
          description: "対象注文の現在の状態"
        },
        created_after: {
          type: "string",
          description: "ISO 8601形式の開始日時。例: 2026-07-09T00:00:00Z"
        },
        limit: {
          type: "integer",
          minimum: 1,
          maximum: 100,
          description: "取得件数。1から100まで"
        }
      },
      required: ["status"]
    }
  }
];

制限と未解決の疑問

この機能はまだ新しいため、エージェントスタックを全面的に再設計する前に検証が必要です。

API仕様を先に確認する

正確なリクエストパラメータ、実行制限、タイムアウト動作は、OpenAIのAPIリファレンスとモデルガイドを確認してください。GA後の調整でパラメータ名が変わる可能性もあるため、実装前に一次情報を確認することが重要です。
可観測性を設計する

従来のオーケストレーションはリポジトリ内にあり、ブレークポイントを設定できました。プログラマティックモードでは、制御フローの一部がリクエストごとに生成されます。ツール呼び出しの順序、引数、レスポンス、失敗理由を記録できるようにしてください。
本番実績を過信しない

Simon WillisonによるGPT-5.6の初日レビューのような独立検証も確認してください。公式ドキュメントに記載される前に、実運用上の問題が見つかる可能性があります。
読み取り専用ツールから始める

最初は検索・取得・分析などのリードオンリーなツールに限定します。生成されたオーケストレーション、トークン使用量、従来ループとのレイテンシ差を確認してから、副作用のあるツールを段階的に公開します。

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

古典的な関数呼び出しでは、ツールは往復ごとに1回呼び出され、人間が作成したループがペースと順序を決めていました。

プログラマティックツール呼び出しでは、生成されたコードがツールをまとめて呼び出し、レスポンスをもとに分岐し、結果を集約します。ツールは、実行前に人間がレビューしない機械生成クライアントから利用されるAPI契約になります。

そのため、次の4項目を実装前チェックリストに含めてください。

1. スキーマの精度

すべてのパラメータに単位、形式、範囲を指定します。曖昧な日付形式は、単発の失敗ではなく、複数イテレーションで繰り返される失敗になります。

2. エラー形式

生成コードは失敗時にレスポンスを見て分岐します。エラー情報をHTTP 200レスポンスの文字列に埋め込む実装は、ツール契約を誤解させます。

正しいHTTPステータスコードと、構造化されたエラーボディを返してください。

{
  "error": {
    "code": "FLIGHT_NOT_FOUND",
    "message": "指定されたIATA便名は見つかりませんでした。",
    "details": {
      "flight_number": "SQ999"
    }
  }
}

3. 冪等性とレート制限

以前は1分間に分散していた12回の呼び出しが、短時間に集中する可能性があります。書き込みを伴うツールでは冪等性キーを検討し、読み取りツールでもバースト時の挙動を確認してください。

確認すべき項目は次のとおりです。

同一リクエストの再送時に副作用が重複しないか
同時実行数の上限を超えた場合に何を返すか
429 Too Many Requests時の再試行条件が明確か
部分失敗時に結果を識別できるか

4. レイテンシ

8秒かかるツールが、1ターンに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サーフェスとして記載されています。gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-lunaの3ティアはすべてのAPIアカウントでセルフサービス利用が可能です。

特定ティアを採用する前に、モデルごとの機能詳細をAPIリファレンスで確認してください。基本セットアップと最初のリクエストについては、GPT-5.6 APIの使い方を参照してください。

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

コードインタープリターは、分析、チャート、ファイル変換などの成果物を作るためにコードを実行します。

プログラマティックツール呼び出しは、宣言済みツールを調整することを目的としてコードを生成します。成果物はコードそのものではなく、オーケストレーションされたツール結果です。

現状と今後の展望

往復ループは、多くのエージェント実装で最も面白みのない部分でした。GPT-5.6では、そのループをオプションにできます。

オーケストレーションはモデル側へ移ります。その一方で、正確で、安全で、予測可能に動作するツールAPIを提供する責任は、これまで以上に開発者側にあります。

最初の導入は、次の順番で進めると安全です。

読み取り中心のワークフローを1つ選ぶ
必要なツールスキーマを作成または厳格化する
正常系・異常系・レート制限時のレスポンスを定義する
各エンドポイントをテストする
モックサーバーでバースト呼び出しと不正入力を再現する
ツール呼び出し順序と結果をログに残す
従来の関数呼び出しループとレイテンシ・トークン使用量を比較する
検証後に、副作用のあるツールを段階的に追加する

ApidogのAPIクライアントとモックサーバーで各エンドポイントを検証し、大量呼び出しや不正入力でもAPI契約が維持されることを確認してください。モデルがツールに対するコードを書き始めるとき、そのコードがテスト済みのサーフェスだけを呼び出す状態を作ることが重要です。

DEV Community