GPT-5.6モデルファミリーは、フロンティア水準のエージェント性能をはるかに低コストで使えるようにするとともに、可能なことの最前線も押し広げます。GPT-5以降、各モデル世代はより少ないトークンでより長期(long-horizon)のタスクに取り組むことを目指してきました。GPT-5.6もその流れを継続しており、基盤のハーネス(harness)の変更を最小限に抑えつつ、エージェント性能の向上とコストの低下を実現しています。
GPT-5.6は、エージェントをより効率的に動作させる3つの補完的なアーキテクチャ上の介入を組み込んで、エンドツーエンドで訓練されています。
たとえば、エージェントによる分析の前に手書きメモを解析するリーガルテック系スタートアップなら、ユースケース全体をフロンティアモデル(frontier model)に任せるのではなく、抽出に5.6ファミリーの小型モデルであるTerraまたはLunaを使うことで、大幅なコスト削減を実現できます。
スタートアップは、より賢いモデル選択と、reasoning continuity(推論の継続性)・マルチエージェントのオーケストレーション(multi-agent orchestration)・プログラムによるツール呼び出し(programmatic tool calling)に役立つ新しいAPIコントロールを使い、より高速で高機能なエージェントを数分の一のコストで構築しています。
OpenAIは、GPT-5.6の性能を標準状態で高めることに加え、さらなる向上のためにResponses APIに新しいプリミティブを追加しました。
3つの介入と再利用・並列分解・コード化
3つの介入の1つ目「Reuse work already performed(すでに行った作業を再利用する)」は、モデルのターンをまたいで推論を保持できるようにし、長時間続く会話をネイティブのコンパクション(圧縮)で縮めることで、モデルが混乱したり以前のコンテキストを再構築したりすることなく、より長いタスクの範囲にわたって作業の一貫性を保てるようにするものです。
「Parallel decomposition where appropriate(適切な場合は並列に分解する)」では、ネイティブのマルチエージェントのオーケストレーションを使うと、複数のエージェントを並列のワークストリームにわたって調整でき、複雑なタスクをより速く終えられます。
「Move deterministic work into code(決定的な作業をコードに移す)」では、プログラムによるツール呼び出しを使い、ツールの出力のフィルタ・集約・オーケストレーションをモデルのコンテキストウィンドウ(context window)の外で行います。
プログラムによるツール呼び出しによって、モデルのトークンを判断のために確保でき、コスト、レイテンシ、コンテキストロット(context rot)を減らせます。
エージェントが100件の提出書類を取得し、日付で絞り込み、関連する取引を特定する場合、モデルがコンテキストウィンドウ内のすべての中間結果について推論する必要はありません。
プログラムによるツール呼び出しでは、GPT-5.6がJavaScriptを書いてツールをオーケストレーションし、独立した呼び出しを並列に実行し、その出力をコンテキストウィンドウの外で処理します。
プログラムによるツール呼び出しを使うと、モデルは判断を下すという知性を要する部分に集中できます。
マルチエージェント構成の動かし方
複雑で並列化できるタスクでは、アクションと推論を複数のエージェントのワークストリームに分散すると、タスクをより速く完了でき、より高い知能も得られます。
マルチエージェント構成では、メインエージェント(primary agent)がサブエージェントの統括とタスクの委任を担います。
サブエージェントは目的を並行して進め、最後に出力をメインエージェントへ返し、メインエージェントが最終的に統合します。
Responses APIでmulti-agentを有効にすれば、チームはマルチエージェントをネイティブに使い始められます。ChatGPTの「ultra」と呼ばれる能力設定も、この仕組みで動いています。
GPT-5.6は適切なサブエージェント数とそれを生成すべきタイミングをよく把握していますが、マルチエージェントの挙動は非常に誘導しやすい(steerable)ものです。
サブエージェントを呼び出すべきタイミングをモデルに指示すると、追加のトークン消費がより良い性能につながる状況に限って、エージェントを生成する可能性を高められます。
小型モデルと推論の強度によるコスト低下
従来、長期のユースケースにおいては、利用可能な最高の推論の強度(reasoning effort)でフラッグシップモデルにアップグレードすることが最良の選択肢でした。これは、フラッグシップモデルがコスト最適化モデルよりも、より長いコンテキストの処理やツール呼び出し(tool calling)においてはるかに高性能であったことが大きな理由です。しかし、5.6ファミリーではこの状況が変わりました。テスト時の計算量(test-time compute)を増やすと、LunaとTerraはGPT-5.4や5.5に似た性能を発揮できることが多く、しかもコストははるかに低くなります。
Agents’ Last Examでは、ハーネスを一定に保った場合、推論の強度が「low」のGPT-5.6 Solが、推論の強度が「high」のGPT-5.5を上回りました。全体的なコスト効率の改善に加え、低い推論の強度での精度も向上しています。また、本番環境でのテストでも同様の成功例が見られており、スタートアップからは、推論の強度を従来のデフォルトから下げることで、さまざまなワークフローで大幅なコスト改善が得られたとの報告があります。
検索ベースのベンチマークであるBrowseCompは、あまり知られていない事実を検索するモデルの能力をテストします。OpenAIによると、3か月前のGPT-5.5(Extra High)が総コスト$33.27でスコア84.36%だったのに対し、GPT-5.6 Luna(Extra High)は公開時点で、コスト$1.33でスコア84.04%とほぼ同じ性能を示しました。その後、価格はさらに引き下げられています。
5.6ファミリーの小型モデルは、大量処理のワークロード、レイテンシに敏感なやり取り、エージェント型ワークフロー(agentic workflows)内で繰り返されるステップに適しています。エージェント型ワークフローには、判断を要するタスクと、主にデータの移動・フィルタリング・結合を要する作業という、2種類の作業が含まれることがよくあります。
プロンプトキャッシュの改善
モデルファミリー全体において、プロンプトキャッシュ(prompt cache)のTTLが最低30分に延長されました。また、コンテキストウィンドウ内でキャッシュブレークポイント(cache breakpoints)を決定的に設定できるようになり、これによりスタートアップはキャッシュヒット率を大きく改善できました。キャッシュブレークポイントの設定に加えて、適切なprompt_cache_keyを使い続けると、同じプレフィックスを以前に処理した推論エンジンにリクエストが届く可能性が高まり、レイテンシが下がります。
顧客の声と著者、まとめ
顧客の声として、オープンエンドな研究課題に取り組むエージェントのチームを運用しているQualiaは、GPT-5.6 SolがGPT-5.5より顕著に改善し、テストしたほぼすべての他モデルより速く終え、すぐに同社の定番のOpenAIモデルになったと述べています。別の顧客の声として、GPT-5.6はOpenAIのモデルで見た中で最高のオーケストレーターであり、6つの仕様を同時に投げ、それらすべてについて執筆、構築、議論を行っても、品質が崩れずにすべてを把握し続けたと述べています。
著者であるSamarth Madduru、Prashant Mital、Dave Leo、Julien Reimanは、GPT-5.6を使って構築するスタートアップと初期テストから本番運用まで密接に取り組んだ経験に基づいて、このガイドを作成しました。
以前はすべてのステップでフロンティアモデルが必要だったユースケースでも、より小さいモデルの利用、推論の強度の調整、効率的なアーキテクチャ選択によって、数分の一のコストで同等かそれ以上の結果を得られるようになりました。エージェントを構築する際の経済性が、以前と比べて大きく変わったことが、OpenAIが挙げた複数の事例を通じて際立っています。