AIエージェントの「実行のかたち」が、また一段変わりました。2026年7月9日、OpenAI は新しいモデルファミリー GPT-5.6（Sol / Terra / Luna の3層）を一般提供に切り替え、同時に Responses API へ2つの機能を投入しました——Programmatic Tool Calling（プログラム的ツール呼び出し） と、ネイティブなマルチエージェントです（OpenAI, "GPT-5.6"／MarkTechPost, 2026年7月9日）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の「PoCから本番・全社へ」を日々支援しています。本稿は特定モデルの宣伝ではありません。今回の変更は、エージェントがツールをどう呼ぶかという一見地味な部分の話ですが、実は企業がエージェントを統制する『制御点』の置き場所に直結します。何が変わり、なぜ従来の前提が崩れ、日本企業がいま何を設計し直すべきか——可視性・承認・監査・コストの4軸で整理します。
そもそも何が変わったのか——「往復」から「コード実行」へ
まず、これまでのツール呼び出し（Function Calling）の形を思い出してください。エージェント開発者なら誰もが知っている、あの繰り返しです。
- モデルが「ツールAを、この引数で呼びたい」と1件返す。
- アプリ側のコードがツールAを実行する。
- 結果をモデルの文脈（コンテキスト）に追記する。
- モデルが「次はツールB…」と、また1件返す。
ツールを4回呼べば、モデルとの往復は4回。ツール結果がすべてコンテキストに積み上がるため、呼び出しが増えるほど遅延とトークン消費が雪だるま式に膨らむ——これが古典的なエージェントループの弱点でした。
GPT-5.6 の Programmatic Tool Calling は、この構図を変えます。モデルが1件ずつツール呼び出しを返す代わりに、モデル自身がコード（JavaScript）を書き、それを隔離されたサンドボックス上で実行して、複数のツール呼び出しをまとめて制御するのです（apidog, "GPT-5.6 programmatic tool calling"／OpenAI API Docs: Programmatic Tool Calling）。ループも条件分岐も並列呼び出しも、そのコードの中で完結します。大きな中間結果はランタイム内に留まり、必要な最終結果だけがモデルに戻る——OpenAI は早期テストで、一部のタスクにおいて最大35%のトークン削減を報告しています。
セキュリティ境界そのものは保たれる、という点は正しく理解しておく必要があります。コードが走るのはネットワーク非接続の隔離ランタイムで、外部に影響を与える唯一の経路は「開発者が明示的に宣言したツール」だけ。つまり、モデルが勝手に未許可のAPIを叩けるようになるわけではありません（apidog）。変わるのは「境界の位置」ではなく、その境界の内側で何が起きているかの見え方です。
| 観点 | 従来のFunction Calling | Programmatic Tool Calling |
|---|---|---|
| 呼び出しの制御 | モデルが1件ずつ返し、アプリが実行 | モデルが書いたコードがまとめて制御 |
| 往復回数 | ツール数だけモデルと往復 | 1回のコード実行に集約されうる |
| 中間結果 | すべてコンテキストに積み上がる | ランタイム内に留まり、最終結果だけ戻る |
| コスト/遅延 | 呼び出しに比例して増える | 早期テストで最大35%のトークン減 |
| 開発者から見た可視性 | 各呼び出しが逐一手元を通る | 中間の呼び出しはランタイム内で進む |
マルチエージェントが「標準機能」になった
もう一つの変更が、マルチエージェントのネイティブ化です。GPT-5.6 は、1回のリクエストの中で複数のサブエージェントを並列に立ち上げ、それぞれの成果を1つの応答に統合できるようになりました（ベータ提供、OpenAI API Docs: Multi-agent）。API のドキュメント上、同時に走るサブエージェント数の既定値は max_concurrent_subagents = 3 とされています。ChatGPT の製品側「Ultra」モードは、既定で4エージェントを並列に協調させる、という別立ての設定です（digitalapplied, 2026年7月）。
典型的な使いどころは「調査のファンアウト」です。5つの部分課題を5つのサブエージェントに同時に投げ、結果を束ねて1つの答えにする——独立した部分に分解できるタスク（複数市場の比較、コードベースの各領域レビューなど）で効きます。
ここで実務上効いてくるのは、「1リクエスト＝1エージェント＝直列のツール呼び出し」という素朴な前提が崩れることです。1つのリクエストが、内部で複数のサブエージェント × それぞれのツール呼び出しへと枝分かれ（ファンアウト）する。エージェント設計の生産性は上がりますが、その裏でツール呼び出しの総量と同時実行数が一気に増える——統制とコストの観点では、この点を見落とせません。
統制の前提が崩れる3つのポイント
Programmatic Tool Calling とマルチエージェント。この2つが組み合わさると、多くの企業が「エージェントの制御点」として暗黙に置いてきた場所が、機能しにくくなります。崩れるのは主に3点です。
① 可視性——「各ツール呼び出しが手元を通る」が前提でなくなる。 従来は、モデルが1件ずつツール呼び出しを返す瞬間が、アプリ側で「何をしようとしているか」を覗ける自然な観測点でした。ところが Programmatic Tool Calling では、中間のツール呼び出しと大きな中間出力はランタイム内に留まり、モデルの文脈（＝開発者のループ）には戻らない。まさにそこがトークン削減の源泉なのですが、裏返せば「隠れた推論が見えるワークフローになった」半面、個々の一手が手元のログに逐一残りにくくなるということです（apidog）。
② 承認ゲートの位置がずれる。 「高インパクトなツール（メール送信・レコード削除・本番書き込み・支払い）を呼ぶ瞬間に人手承認を挟む」——これは2026年の統制のベストプラクティスでした。しかしその承認をモデルの往復（各Function Callの戻り）に仕掛けていた場合、コードがサンドボックス内で複数呼び出しをまとめて回す設計では、同じ位置での差し込みが効きにくくなります。ゲートはモデルの応答ではなく、ツールそのものの実行直前に置き直す必要があります。
③ コストと監査がファンアウトで膨らむ。 マルチエージェントは1リクエストを内部でN本のサブエージェントへ枝分かれさせます。うれしい半面、1リクエストあたりのトークン消費・ツール呼び出し回数・監査対象イベントが数倍になりうる。「リクエスト数」でコストや証跡を数えていた運用は、実態とズレていきます。
誤解しないでください。これは「GPT-5.6 は危険」という話ではありません。セキュリティ境界（未許可ツールを叩けない）は保たれています。危ういのは、統制を『モデルの往復を覗く』ことに依存して組んでいた企業です。実行がランタイムの内側とサブエージェントへ移るほど、モデル境界での観測・承認は取りこぼしを生みます。制御点を、モデルの外側——ツール定義とツール実行の層——へ降ろしておく必要があります。
だから制御点は「ツールとゲートウェイの層」へ降りる
崩れた前提の裏返しが、そのまま設計指針になります。エージェントの実行がモデルの内側へ潜り、サブエージェントへ枝分かれしても揺るがない制御点は、エージェントとツールの「あいだ」にしかありません。具体的には、ツール定義・接続・実行を束ねるゲートウェイ層に、次の4つを持たせます。
| 制御の軸 | 崩れた前提 | 置き直す先 |
|---|---|---|
| 可視性・監査 | 各ツール呼び出しがモデル往復で手元を通る | ツール実行層で全呼び出しを記録（改ざん耐性のあるログ） |
| 承認ゲート | モデルの応答（Function Callの戻り）に人手承認を挟む | 高インパクトなツールの実行直前に承認を必須化 |
| 権限・最小化 | プロンプトやモデル設定で行動を絞る | ツール単位・エージェントID単位のスコープ（RBAC） |
| コスト統制 | リクエスト数で費用を管理 | ツール呼び出し・トークン・サブエージェント本数で計測し閾値管理 |
要は、「モデルが何を考えたか」を覗くのをやめ、「どのツールが・誰の権限で・実際に実行されたか」を制御・記録する方向へ、統制の重心を移すということです。Programmatic Tool Calling がツールを「唯一の外部への出口」に固定した設計は、この方針とむしろ整合的です。出口が絞られているからこそ、その出口を組織横断の一枚岩のゲートウェイで押さえれば、モデルやエージェントの内部構造が変わっても統制は効き続けます。
homulaの観点——実行が潜っても効く「制御層」を先に組む
homula は、エージェント導入を「便利な自動化を足す」話ではなく、制御層を先に組んでから機能を載せる順序で設計します。今回の GPT-5.6 の変化は、その設計思想の重要性をむしろ後押しするものです。
- ツールの出口を一枚岩で押さえる: Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供します。統制点をモデルの往復ではなくツール実行の層に置くため、モデルが Programmatic Tool Calling で内部に処理を潜らせても、マルチエージェントでファンアウトしても、「どのツールが・誰の権限で・実際に何をしたか」を証跡に残し、高インパクトな操作には実行直前に承認を噛ませられます。
- 接続は絞って速く、統制の設計に時間を割く: Agens は MCP を活用し、200以上のツールと構築ゼロで接続します。ツールが「唯一の外部への出口」である以上、その出口の定義とスコープ設計こそが統制の要。接続自体を作り込まずに用意できるぶん、どのツールにゲートを噛ませ、どの権限を誰に持たせるかの設計に集中できます。
- 適所適ツールで実装する: n8n / Dify / LangGraph を組み合わせ、ツール単位の人手承認（HITL）や最小権限を、業務の重要度に応じて作り分けます。「全部止める／全部任せる」の二択ではなく、リスクの大小でゲートの強弱を設計します。
- 着手前に統制要件とコスト計測を定義する: AIエージェント・ブートキャンプでは、業務棚卸し・プロトタイプ構築・ROI試算を3〜5日で完結します。マルチエージェントのファンアウトを見越し、「どのアクションを承認対象にするか」「何を単位にコストと証跡を数えるか」を最初の要件として置くことが、後戻りと想定外の請求を防ぎます。
順序が肝心です。実行モデルがモデルの内側へ潜っていく時代に、統制を後付けすると、承認も監査も「実態が見えないまま形骸化」します。ツールの出口・承認ゲート・監査証跡・コスト計測を先に置き、その上で自律性とファンアウトを少しずつ広げる——これが、処理時間の大幅削減のような成果を全社規模で安全に取りにいくための現実的な道筋です。
まとめ——覗くのは「モデルの往復」ではなく「ツールの出口」
GPT-5.6 が示したのは、「モデルが賢くなった」以上に、エージェントの実行が構造ごと変わったことです。ツール呼び出しはモデルの往復からサンドボックス内のコード実行へ、1リクエストは複数サブエージェントのファンアウトへ。効率は上がり、開発の生産性も上がります。その裏で、多くの企業が暗黙に頼ってきた「モデルの往復を覗いて統制する」やり方は、取りこぼしを生みはじめます。
日本企業がいま準備すべきは、モデルの内部を追いかけることではなく、ツールという『唯一の出口』を組織横断で押さえる制御層を定義することです。可視性・承認・最小権限・コスト——この4軸をツール実行の層に置いておけば、モデルやエージェントの実行モデルがこの先また変わっても、統制は効き続けます。統制はブレーキではなく、実行の進化を安心して取り込むための土台です。
「便利だが任せきれない」を、「統制された自律」に変えませんか。homula は、ツールの出口を押さえる制御層づくり——承認・最小権限・監査・コスト計測——を、業務棚卸しからROI試算まで一気通貫で支援します。