GPT-5.6 Sol Ultrafast vs GPT-5.6 Sol：同じ重み、異なるサービスティア

GPT-5.6 Sol Ultrafast は新しいモデルではなく、これは新製品発表の記事でもない。ベンダーは2026年8月13日にこのモードを発表し、同じ日に値 ultrafast が同社の公開 OpenAPI スキーマ内、仕様の ServiceTierResponses の説明に現れた。その説明は、それ自体の文言によってこの階層を gpt-5.6-sol エンドポイントに限定し、アクセス制御されていると記している。このページを私たちのキューに戻したのは、より小さく、より具体的なことだ。2026年9月25日、コミット fe4f7a1 がその値をさらに2つの列挙、すなわちリクエストレベルの service-tier パラメータとエージェントの service-tier ポリシーフィールドに拡張した。発表から6週間後、この階層は依然としてウェイトリストに載っており、公表された価格もなく、実際に提供できる以上に多くの API サーフェスに組み込まれている。GPT-5.6 Sol Ultrafast と GPT-5.6 Sol は同じモデルだ。この比較が決められる唯一のことは、誰がポインタを制御しているか、そして誰があなたにコストを告げたかだ。

つまり、見出しにあるこの対決は異例だ。GPT-5.6 Sol Ultrafast と GPT-5.6 Sol は同じモデルである。同じ重み、同じチェックポイント、同じ推論挙動、同じ105万トークンのコンテキストウィンドウ、同じ128Kの最大出力、同じ回答。OpenAI 自身の説明は「より賢いモデル」ではなく「1秒あたりより多くの有用な作業」だ。この比較の2つの列で異なるのは、トークンがどのように生成されるかと、リクエストボディでそのティアが何と呼ばれるかだけ——だからこそ、現行ラインナップで最もクリーンな対照実験であり、同時に最も選びにくいものでもある。というのも、2つのティアのうち一方には公表価格がまったくないからだ。

今週、実際に何が変わったのか

9月の変更の根拠はブログ記事ではなくコミットだ。OpenAIは、自社APIの機械可読スキーマを公開するリポジトリopenai-openapiを維持しており、2026-09-25付のコミットfe4f7a1は、2つの列挙にultrafastを追加している。すなわち、エージェントに付与されるサービス階層ポリシーと、仕様が「モデルリクエストに使用されるサービス階層」と記述するリクエストレベルのフィールドである。これは初登場ではなく拡張だ。このコミット以前、それら2つのリストはauto、default、flex、priority、fastであり、その階層はすでに8月13日からスキーマに存在していた。このコミットが注目に値するのは、それがどのフィールドに到達したかによる——エージェントに設定されるポリシーフィールドであり、これはリクエスト単位のオーバーライドとは異なる領域である。

重要な説明はこのコミットではなく、8月13日のコミットに由来しており、OpenAI がこのティアについてこれまでどこで公表した中でも最も具体的な記述です。新しい値と並んで、仕様にはこう書かれています。「'ultrafast' に設定すると、リクエストはアクセス制御された Ultrafast Processing サービステアで処理されます。このティアは現在 gpt-5.6-sol で利用可能です。それを介して返される応答には service_tier=ultrafast と表示されます。」

その文を二度読んでください。そうすれば、この比較ページが本来なら曖昧にせざるを得ない2つの疑問に決着がつきます。このティアは1つのモデル、つまりラインナップ内のGPT-5.6 Solフラッグシップのみを対象としており、オープンではなくアクセス制御されています。これは、OpenAIがウェイティングリスト制プレビューと位置づけていることと一致します。また、自分がそれを利用できたことをどうやって知るかも示しています。レスポンスは、実際にリクエストを処理したティアをそのまま返すので、標準処理へのフォールバックは、レイテンシから推測しなければならないものではなく、レスポンスボディで確認できます。同じ説明は、標準およびBeta Responsesスキーマの両方に記載されており、8月13日からそうなっています。

翌日、2つ目の、より弱いシグナルが届いた。9月26日の報道では、Responses API Playgroundに新しいSpeedセレクター（Fast、Standard、Ultrafast）が登場し、OpenAIの開発者会議DevDayの後にUltrafastの提供範囲が広がる見込みだと説明されている。私たち自身はこのセレクターを確認しておらず、OpenAIもロールアウトに関する告知を出していないため、これは出荷済み機能ではなく単一ソースの報道として扱うべきだ。今日確認できる部分は、公開スキーマにある2つの箇所と、このティアについて料金表がまだ出ていないという事実だ。

何が変わっていないかも同じくらい重要だ。依然としてUltrafastの価格は存在しない。9月27日に確認したOpenAIの価格ページには、以前と同じ4つのタブ — Standard、Batch、Flex、Fast — があり、「ultrafast」という文字列はどこにも出てこない。アクセスは依然として、一部の顧客向けの限定プレビューと説明されており、キャパシティの増加に伴って拡大している。このティアは契約書にはあるのに、同時に価格表にはない。そしてそれが正直な現状だ。

2つの階層を並べて

機能面でこの2つを分けるものがないため、比較はほぼ完全に配信と課金の話に集約されます。以下の各行は、どちらの側も同じ1行に並べて示しています。

• モデル — GPT-5.6 Sol Ultrafast は、GPT-5.6 Sol standard processing と同一の GPT-5.6 Sol チェックポイントを実行します。チェックポイントは同じで、蒸留もサイズ削減もありません。

• 出力スループット — 毎秒最大750出力トークン、標準の最大14倍。OpenAIの8月13日の発表によると、GPUクラスタ上での標準GPT-5.6 Sol処理との比較であり、これが14倍の基準となる数値です。

• ハードウェア — Cerebrasのウェハスケールチップ。重みはオンチップSRAMに常駐し、OpenAIが2026年1月にCerebrasと結んだコンピュート提携の最初の製品で、3年間で約100億ドル相当と報じられている。これに対し、従来のGPU推論では、時間の多くがメモリと演算部の間で重みを移動することに費やされる。

• 価格 — 2026年9月27日時点では未公表。一方、100万トークンあたり入力$4.00／出力$20.00（OpenAIの現在のプロモーション料金）、さらにキャッシュ入力には100万トークンあたり$0.40。

• 提供状況 — 一部の選定顧客向けのウェイトリスト制限定プレビュー 対 デフォルトの経路。APIキーを持つ誰でも呼び出し可能。

• 返ってくる回答 — 原則的に同一 対 原則的に同一。同じプロンプトでそれらが食い違うなら、それは仕様ではなく発見だ。

速度の主張と、それに対する上限

見出しの数字は14倍であり、それはこのページの他の部分と同じ丁寧な扱いに値する。OpenAIは標準的な処理と比べて毎秒最大750出力トークンと述べている——これは出力トークンについてのスループット値であり、すべてのリクエストが14倍早く完了するという主張ではない。エンドツーエンドの時間には入力処理とモデル自身の推論も含まれ、そのどちらもウェハスケールのハードウェアが同じ比率で圧縮できるものではない。だからこそ同社は14倍を測定値ではなく上限値と呼んでいる。

公表されている比較は、表の両側ともベンダー報告であり、そのうちの1つは2社のスタックにまたがっている。Humanity's Last Exam の2,500問の実行は、Ultrafast では11時間11分で完了したと報告されているのに対し、Claude Fable 5 では78時間27分で、精度は同等とされている。つまりこれは、OpenAI と Cerebras が、競合のモデルを含むベンチマークについて語っているのであり、この発表に関する独立系の報道は、同じ実行についてより限定的な約11倍という生成速度の比較を引用している一方、Cerebras 自身の数値はテスト総時間について約7倍を示唆している。14倍、11倍、7倍の間の差は矛盾ではない。それは、3者が1つのワークロードの異なる部分を測定したときに起こることだ。Cerebras は別途、GDP-Val でエンドツーエンド5.6倍、測定可能な品質低下はないと報告している。そのいずれも第三者によって再現されていない。

価格表には穴がある

ここで二つのティアは対称ではなくなる。GPT-5.6 Sol には4つの公開料金表があり、Ultrafast はそのいずれでもない。

• Standard GPT-5.6 Sol — 100万トークンあたり$4.00 / $20.00、キャッシュ済み入力は$0.40、入力が約272Kトークンを超えるとロングコンテキスト階層は$8.00 / $30.00。

• Fast mode — $8.00 / $40.00、標準料金のちょうど2倍です。これは2026年7月30日に Priority processing から名称変更されたティアで、API は service_tier: "priority" または service_tier: "fast" のいずれかを受け付けます。最大で約2.5倍の出力速度が得られます。

• Batch and Flex — $2.00 / $10.00、スケジュールの融通が利く代わりに、標準料金から一律50%オフ。

• Ultrafast — 料金表なし。私たちが推測で埋めた空白ではない。OpenAIが残した空白だ。

そのFastモードの行は、誰もがUltrafastを比較衡量する際に頼れる唯一の実質的な先行事例であり、予算を計画している者にとっては考えさせられるものだ。OpenAIが実際に数字を公表した唯一の速度ティアは、標準料金のちょうど2倍の価格で2.5倍の速度というものだ。Ultrafastは、より希少なハードウェアに依拠する、より大きな速度の主張である——Cerebrasのウェハー生産能力はコモディティではない——ため、最終的な割増料金の方向性は疑いようがない。その大きさは別だ。料金表が存在するまでは、どこで引用されていようと「GPT-5.6 Sol Ultrafast price」の数値は誰かの推測であり、私たちの推測も含まれる。

実際にあなたがそれをどう呼ぶか

スキーマの変更は、最終的な呼び出しの形を教えてくれる。そのティアが他のティアと同じパターンに従うなら、すでに行っているリクエストに追加フィールドとして載ってくる。つまり、モデルは gpt-5.6-sol のまま、プロンプトもそのまま、ティアセレクターを追加するだけだ。今日 Fast モードが priority を fast に置き換えることで選ばれるのと同じ要領だ。モデルが何も変わらないのだから、レスポンスのパースも何も変わらない。これがモデルスワップではなくサービングティアを使うことの魅力のすべてであり、このような比較ページに比較するものがほとんどない理由でもある。

今日できないのは、それを呼び出すことだ。列挙値は存在するが、その背後にあるキャパシティは、ほとんどのアカウントでは存在しない。したがって、今後数週間の実務上の問いは、2つのティアのどちらを選ぶかではなく、その選択肢が利用できない間に何を動かすかである。

それは、待機リストよりもゲートウェイのほうがよく答えてくれる問いです。このモデルの標準ティアは、openai/gpt-5.6-sol として今まさに OrcaRouter 上で稼働しており、プロバイダー自身の料金でトークンへのマークアップはゼロ、api.orcarouter.ai/v1 の OpenAI 互換エンドポイントを通じて提供されています——つまり OpenAI のプロモーション価格 $4 / $20 と、長コンテキスト時の $8 / $30 という段階は、私たちが値付けし直すのではなくそのまま反映され、それらに変更があれば OpenAI 側に反映されたその日のうちにこちら側にも反映されます。同じキーで200 以上ものモデルを利用できますが、ここではそれがいつも以上に重要です。というのも、service_tier: "ultrafast" を設定すれば答えが得られるわけではないため、今日レイテンシーを買う手段はワークロードのルーティングを変えることだからです——インタラクティブな呼び出しは、カタログの中であなたの品質基準を最も速くクリアするモデルに送り、夜間バッチは基準を満たす中で最も安いレーンに載せておくのです。このティアが実際に開放されたとき、スイッチを切り替える場所になるのはこのルーターであり、それまではそれが待機リストと計画の違いになります。

どちらが本番環境に属するものですか？

「versus」という言葉は少しの間忘れてください。ここでは品質に関する判断をする必要がないからです。トークンあたりのコストを最適化するなら、標準のGPT-5.6 Solが答えであり、待てるものであれば何でも50%オフのBatchレーンが答えです。人間がスピナーの前でどれだけ長く待つかを最適化するなら、利用できるようになった瞬間にUltrafastが答えです。そしてOpenAIがプレビュー向けに挙げているワークロードは、その理由をまさに示しています。ライブ障害時にログと差分を開きながら行うインシデント対応、刻々と変わるデータに対する不正チェック、0.5秒の沈黙が壊れたプロダクトのように受け取られるサポート会話、そして以前は一晩中走っていた研究ループが1回の作業セッションに圧縮されることです。

判断材料になるのは、リクエストグラフの形であり、プロンプトの大きさではない。単一の長い生成は、理論上は14倍になるが、実際にはそれよりかなり少ない。入力処理と推論は、その比率では圧縮されないからだ。ユーザーから見える1つの操作の背後にある40回の逐次ツール呼び出しは、フルの倍率にはるかに近いものを得る。それらの往復の1つ1つが、ユーザーが待たされているレイテンシだからだ。あなたのワークロードが2番目のようなものなら、そのティアはあなた向けだ。1番目のようなものなら、標準レーンで常に十分だったはずだ。

注視すべき点が2つあり、どちらもここから決着をつけられる噂ではない。第一に、料金表だ。価格のないプレミアム階層は予算化できないし、Fast-modeの前例を考えれば、それが小さいはずはない。第二に、報じられているようにDevDayの前後でウェイトリストが実際に解除されるかどうか——なぜなら、ほとんどのアカウントが使えないservice_tierの値はドキュメントであって可用性ではなく、その2つの違いは計画と約束の違いだからだ。