GPT-6.1 Sol Ultrafast が提供開始 — DevDay の「近日」が実現、Responses API は service_tier 1行で全ユーザーが使える
OpenAI が 2026-10-08 に GPT-6.1 Sol の Ultrafast を提供開始した。2026-09-29 の DevDay で Ultrafast ティアが新設された時点では GPT-6 Astra Ultrafast のみ提供中で、Sol 版は「近日」とされていた。今回それが実現した。API 面では Responses API の service_tier に "ultrafast" を指定すると出力トークン間の待ち時間が短くなる。対象は API の全ユーザーで、処理は global、US と EU のデータレジデンシーに対応する。単価は標準の6倍で、短コンテキスト（272K 入力トークン以下）が入力 12 ドル / 出力 60 ドル per MTok、長コンテキストが入力 24 ドル / 出力 90 ドル。標準は 2 ドル / 10 ドル、中間の Fast ティアは2倍の 4 ドル / 20 ドル。製品面では Codex と ChatGPT Work で使えるようになり、対象は Pro 500 と条件を満たす Enterprise / Edu。Enterprise では既定で無効で workspace の owner が有効化する。
ニュース原文を読む ↗要約
OpenAI が GPT-6.1 Sol の Ultrafast を提供開始しました。API 面と製品面の2か所で同日に告知されています。
これは新機能の発表ではなく、約束の履行です。 Ultrafast ティア自体は 2026-09-29 の DevDay で新設されました。ただしその時点で提供中だったのは GPT-6 Astra Ultrafast だけで、**GPT-6.1 Sol Ultrafast は「近日」**とされていました。今回それが実現しました。
この順序が重要なのは、Sol が「Astra の5分の1単価でほぼ同等性能」として出たモデルだからです。 速度を買う選択肢が、単価の安い側のモデルにも開いたということになります。
API 面では、Responses API の service_tier に "ultrafast" を指定すると、生成される出力トークンの間隔が短くなります。 対象は API の全ユーザーで、レート上限の範囲内で使えます。処理は global で、US と EU のデータレジデンシーに対応します。
単価は標準の6倍です。 公式 Pricing の数字は次のとおりです。
| ティア | 標準比 | 短コンテキスト 入力 / 出力 | 長コンテキスト 入力 / 出力 |
|---|---|---|---|
| Standard | 1倍 | $2.00 / $10.00 | $4.00 / $15.00 |
| Fast | 2倍 | $4.00 / $20.00 | $8.00 / $30.00 |
| Ultrafast | 6倍 | $12.00 / $60.00 | $24.00 / $90.00 |
| Flex / Batch | 0.5倍 | $1.00 / $5.00 | $2.00 / $7.50 |
（100万トークンあたり。短コンテキストは入力 272K トークン以下、長コンテキストはそれ超）
速度の倍率は、公式の説明では Codex で最大8倍、API で最大6倍です。
製品面では、Ultrafast が Codex と ChatGPT Work で使えるようになりました。対象は Pro 500 と、条件を満たす Enterprise / Edu プランです。Enterprise では既定で無効で、workspace の owner が有効化する必要があります。
実務で効くのは、6倍と1倍の間に2倍があることです。
Ultrafast の話をすると「6倍を払うか払わないか」という二択に見えます。 しかしFast が2倍で存在します。 速度が足りない、しかし6倍は出せない、という状況で中間の選択肢があるかどうかは、判断の質を大きく変えます。 本件を読んで最初にやるべきことは、Ultrafast を試すことではなく、Fast で足りるかを確認することです。
何が変わったか
- GPT-6.1 Sol Ultrafast が提供開始（2026-10-08）。DevDay 2026-09-29 で「近日」とされていたものが実現
- Responses API の
service_tierに"ultrafast"を指定すると、出力トークン間の待ち時間が短くなる - API 側の対象は 全 API ユーザー。レート上限の範囲内で利用可能
- 処理は global、US / EU のデータレジデンシーに対応
- 単価は標準の6倍。短コンテキスト（272K 入力トークン以下）で 入力 $12.00 / 出力 $60.00 per MTok、長コンテキストで 入力 $24.00 / 出力 $90.00
- 標準は $2.00 / $10.00、中間の Fast ティアは2倍の $4.00 / $20.00、Flex / Batch は0.5倍の $1.00 / $5.00
- 速度の倍率は Codex で最大8倍、API で最大6倍（公式）
- Codex と ChatGPT Work でも Ultrafast が選べる。対象は Pro 500 と条件を満たす Enterprise / Edu
- Enterprise では既定で無効。 workspace の owner が有効化する
業務インパクト（一般企業向け）
効く用途と効かない用途が、はっきり分かれます。そして単価が6倍なので、分け方を間違えると高くつきます。
効くのは、人が待っている処理です。 社内チャットボット、問い合わせ対応の下書き生成、コード補完、音声の応答。これらは応答の体感が、そのまま満足度になります。
効かないのは、人が待っていない処理です。 夜間に回す要約、定期的なデータ整形、レポート生成。ここに Ultrafast を付けるのは、単価を6倍にして誰も得をしない支出です。 むしろこの領域は、0.5倍の Flex / Batch を検討すべき側です。
service_tier はリクエスト単位で指定できるので、用途ごとに分けられます。 全体の設定で一律に切り替えるのではなく、対話系のエンドポイントにだけ付ける実装にしてください。設定を1か所にまとめる設計は、この機能では損をします。
判断の手順は、Fast を先に試すことです。
6倍を払う前に、2倍で足りるかを確認してください。 速度が足りないという課題に対して、打てる手が「6倍払う」しかないわけではありません。 Fast が2倍で存在します。
手順としては、代表的なリクエストで Standard / Fast / Ultrafast の3つを測り、体感の差と単価の差を並べるのが確実です。測る際の注意が1つあります。 これはトークン間隔が変わる機能なので、出力が長いリクエストほど差が出ます。 短い応答で測ると差が見えず、「効果がない」と誤った結論になります。実際の業務で出る長さのリクエストで測ってください。
原価計算をやり直す必要がある組織もあります。
入力 $12 / 出力 $60 は、Sol の標準から見ると6倍ですが、絶対額としてはまだ抑えられた水準です。 DevDay 時点で提供されていた Astra Ultrafast と比べると、公式コミュニティの説明では Sol Ultrafast は Astra の約1.2倍のコストにあたります。つまり**「Astra 相当の速度と性能を、Astra より少し高い程度の単価で」**という位置づけになります。Astra Ultrafast を使っていた構成があるなら、Sol Ultrafast への移行で単価が下がる可能性があります。 ここは試算の価値があります。
272K トークンの境界は、原価計算で見落としやすい点です。 長コンテキストに入ると入力が $12 → $24、出力が $60 → $90 になります。RAG で大量の文書を詰める構成では、この境界を超えるかどうかで実効単価が変わります。 絞り込みの設計が、価格表で正当化される形です。
Enterprise の管理者には別の作業があります。
既定で無効なので、何もしなければ利用者からは存在しません。 慎重な既定値として妥当です。ただし「使えるようになったと聞いたが選べない」という問い合わせは来ます。 原因は owner の設定なので、有効化の方針を決めて周知した方が安いです。
そして有効化すると、単価6倍の選択肢を利用者が自分で選べる状態になります。 Codex で日常的に Ultrafast を使われると、請求額が読めなくなります。 有効化の判断には、使途のガイドラインと、コストの観測手段をセットで用意するのが前提です。
データレジデンシーが US / EU のみという点は、国内要件がある案件で確認が必要です。 global 処理で US / EU のレジデンシーに対応、という書き方です。既存の構成で国内要件を満たしている場合、Ultrafast を付けたときに処理の経路が変わらないかを確認してください。
副業・個人活用視点
API 側は全ユーザーが対象なので、個人でも試せます。ただし請求は自分に来ます。
単価が6倍だという点を、まず受け止めてください。 個人開発でうっかり全リクエストに付けると、月末の請求で驚きます。 検証するなら、プロジェクトやキーを分けて、Ultrafast のコストを単独で見られる形にしてから付けてください。
個人の案件で Ultrafast が正当化される場面は、限られます。
自分の作業時間が縮むなら、6倍は安いという計算は成立します。Codex で待ち時間が8分の1になるなら、時間単価で考えて元が取れることはあります。しかし Codex 側は Pro 500 という価格帯が条件です。月額の差を速度に払う判断になるので、1か月試して自分の作業時間がどれだけ変わったかを測るのが順序です。測らずに上位プランへ行くと、高くつきます。
受託では、改善策の選択肢として価値があります。
クライアントに「応答が遅い」と言われたとき、通常打てる手はモデルを軽くする、プロンプトを短くする、ストリーミングにする、キャッシュを入れるです。どれも品質か実装工数のどちらかを払います。 service_tier の1行なら、払うのは単価だけです。
提案の形としては、3つ並べるのが誠実です。 「現状のまま」「Fast で2倍」「Ultrafast で6倍」。単価と体感差を実測した表を出せば、クライアントが自分で選べます。 これは技術提案というよりコストの選択肢を渡す仕事で、信頼につながりやすい形です。最初から Ultrafast だけを提案すると、6倍の根拠を説明し続けることになります。
学習の題材としては、「速度が課金軸になった」という構造の理解が本題です。
従来、LLM の単価はモデルの性能で決まっていました。 良いモデルは高い。Ultrafast は、同じモデルで速度だけを買う仕組みです。 これは性能・速度・コストが独立した3軸になったことを意味します。
選定表の書き方が変わります。 モデルを縦に並べて単価を書く表では足りません。モデル × ティアのマトリクスになります。 Sol だけで Standard / Fast / Ultrafast / Flex / Batch の5段階があり、さらに 272K の境界で2つに分かれます。選択肢が増えたぶん、用途ごとに選べるようになりました。
自分が使っている構成を、この表に当てはめてみてください。 「なんとなく標準を使っている」処理の中に、Flex / Batch へ落として半額にできるものが混ざっているはずです。Ultrafast の発表をきっかけに、安い側を見直すのが、実は一番利益が出る読み方です。