生成AIのモデル選定は、これまで精度と単価が中心だった。だが、AIが会話、監視、調査、コーディング、ツール実行を担うようになると、もう一つ外せない指標がある。仕事が終わるまでの速さだ。
OpenAIは2026年8月13日、Cerebrasを基盤にGPT-5.6 Solを動かすAPIの新しいサービス階層「Ultrafast」を発表した。OpenAIの説明では、Standard processing比で最大14倍、最大750 output tokens/sを掲げる。提供は一部顧客への限定プレビューであり、価格や一般提供時期は公表されていない。OpenAIのUltrafast発表
このニュースを「トークン生成が速くなった」とだけ読むのは惜しい。本当に変わるのは、AIを画面の向こうで待つ道具から、仕事の流れの中で反応する部品に置き直せる可能性である。ただし、そのためにはtokens/secという一つの数字ではなく、待ち時間を分解し、品質・コスト・安全性と一緒に運用する必要がある。
750 tokens/sは何を意味し、何を意味しないか
OpenAIはUltrafastを、GPT-5.6 SolをCerebras基盤で動かすサービスとして説明している。最大750 output tokens/s、Standard処理比で最大14倍という値は、OpenAIの発表値である。提供条件と公称性能
Cerebrasも、同社のWafer-Scale Engine上での推論を説明し、モデル重みを44GBのオンチップSRAMへ保持することで、外部メモリとのデータ移動を抑える方式を示している。これはCerebrasによる技術説明・測定であり、あらゆるプロンプト、同時実行数、リージョン、障害条件で同じ速さを保証するものではない。Cerebrasの技術説明
さらにCerebrasは、GDPVal上の一部タスクで、medium reasoningを使うCodex条件において5.6倍のエンドツーエンド高速化を報告している。これは有用な材料だが、ベンチマークの測定者はCerebrasである。自社のコード、データ、ツール、アクセス制約で同じ結果になると解釈してはいけない。
重要なのは、出力スループットが速くても、利用者が最初の意味のある反応をすぐ得られるとは限らないことだ。
利用者の体感時間
= キュー待ち
+ 入力の受信・前処理
+ 推論・reasoning
+ 最初の応答が届くまでの時間
+ 出力生成
+ 検索・コード実行・外部APIなどのツール待ち
+ 再試行・人間確認
長い入力や強いreasoning設定、ツール呼び出しがあるエージェントでは、tokens/secだけを上げても、全体時間の支配要因が別の場所へ移る。速度は単一の性能表ではなく、ワークフローのボトルネックを見つける問題である。
「レイテンシ」と「スループット」を分ける
AIの速さを議論するとき、少なくとも二つの指標を混同しない。
| 指標 | 意味 | 影響が大きい体験 | 見落としやすい点 |
|---|---|---|---|
| Time to first token / first answer | リクエスト後、最初の応答が届くまで | 対話、音声、操作支援、アラート確認 | reasoning時間や入力処理、キュー待ちを含み得る |
| Output throughput | 出力を始めた後のtokens/sec | 長文生成、コード生成、大量の並列処理 | 最初の待機時間やツール待ちは表さない |
| End-to-end time | 依頼から業務上の完了まで | エージェント、障害対応、調査、申請処理 | モデル以外の検索・承認・再試行が入る |
| Tail latency | P95/P99など遅い側の時間 | 本番SLO、複数利用者のサービス | 平均値がよくても混雑時に崩れる |
たとえば、1,000トークンの報告書を一度生成するなら出力スループットが効く。一方、「現在の障害の影響を確認して」と依頼する運用エージェントでは、ログ検索、権限確認、複数ツール、再試行、根拠の検証が加わる。最初の画面更新が速くても、最終的な調査結果が遅ければ、障害対応の判断は速くならない。
逆に、モデルが途中経過をすぐ示し、バックグラウンドで調査を続けられれば、利用者は待ち時間を別の作業に使える。これはモデルを速くするだけでなく、UIとタスク状態を設計する問題でもある。
速さは、モデルの能力ではなくプロダクト要件になる
Ultrafastと同じ週には、Googleが品質・コスト・レイテンシのバランスを設定できるGemini 3.7 Flashを、NVIDIAが軽量のNemotron 3.5 Lightningとモデルルーティング用ライブラリNeMo Switchyardを発表した。Googleの発表 NVIDIAの発表
各社の数字を同じ表へ並べても、利用判断はできない。重要なのは、その速さがどの製品要件を満たすかである。
| 目的 | まず守る時間の要件 | 適した設計 | 速度だけで決められない点 |
|---|---|---|---|
| 対話・音声UI | 最初の反応と割り込みへの追従 | 即応層と深い調査層を分ける | 正確性、会話状態、確認方法 |
| 開発支援 | 編集・テスト・レビューの反復時間 | 短い変更を速く返し、重い検証は非同期化 | テスト通過、差分品質、レビュー負荷 |
| 障害対応 | 観測から次の確認までの時間 | 読み取り専用の調査を並列化する | 変更権限、根拠、誤検知、停止 |
| 顧客対応 | 会話を止めずに必要情報を出す時間 | FAQは即答、個別調査は引き継ぐ | 誤案内、個人情報、有人エスカレーション |
| バックオフィス | 締め処理・バッチの完了時刻 | キュー、並列実行、再開可能な処理 | 正確性、監査、データ整合性 |
速いモデルを使う理由は、「ベンチマーク順位が上がるから」ではない。以前は待ち時間が長くて成立しなかった操作や反復が、品質条件を満たした状態で成立するかを問うためである。
エージェントでは、遅延がステップごとに積み上がる
エージェントは一度のモデル呼び出しで終わらない。計画、検索、ツール実行、結果の読解、再計画、最終回答を繰り返す。1ステップの遅延が小さく見えても、ループが増えれば累積する。
依頼
↓
分類・ルーティング
↓
モデル推論 ──→ 検索／DB照会／コード実行
↑ ↓
└──── 結果を評価・再計画 ────┘
↓
根拠付きの提案
↓
人間の承認 → 実行 または 停止
ここで、すべてのステップを最速の高性能モデルへ送ることが最適とは限らない。
- ルールで判定できる入力形式の検査は、通常のプログラムで済ませる
- 文書IDの照合や権限確認は、モデルに推測させず決定的なシステムで行う
- 短い分類・抽出は、品質を満たす軽量モデルへ送る
- 難しい推論や設計、曖昧な例外だけを高性能モデルへ上げる
- 書き込み、送信、権限変更は、モデルの速度にかかわらず承認ゲートを通す
NVIDIAが公開したSwitchyardのようなルーティング部品は、選択肢を増やす。しかし、ルーティング自体が新しい障害点になる。速い経路へ誤って送った結果、品質が下がったり、機密データを許可されない提供先へ出したりすれば、速度の利点は失われる。
したがってルーティングには、少なくともtask_type、data_classification、quality_threshold、max_latency_ms、max_cost、approved_provider、fallback_routeを明示する。実際に選ばれたモデル・バージョン・設定・処理時間も、実行IDに結び付けて記録する。
「高速化の検証」はベンチマークの再現ではない
提供元や第三者のベンチマークは比較の入口になる。しかし導入前に必要なのは、自社の重要な一連の仕事での計測である。特に、平均値だけでなく遅い側を測る。
| 設計するもの | 最低限そろえる条件 |
|---|---|
| 評価タスク | 実際の短文・長文、ツールあり・なし、成功・失敗・例外を含める |
| 入力条件 | コンテキスト量、キャッシュの有無、reasoning設定、同時実行数を固定する |
| 時間計測 | キュー、TTFT、出力、各ツール、再試行、完了までを別々に記録する |
| 品質判定 | 正答、根拠、テスト、レビュー、人手修正、危険な出力を評価する |
| 失敗時の挙動 | タイムアウト、フォールバック、キャンセル、部分結果、再開を試験する |
計測ログの例は次のようになる。
trace_id
workflow_id
model / model_version / reasoning_effort
route_policy_version
input_tokens / output_tokens / cache_status
queue_ms / ttft_ms / generation_ms / tool_ms / retry_count
end_to_end_ms / result_quality / human_handoff / cancel_event
これを持てば、「遅い」の原因がモデルなのか、RAGの検索なのか、外部SaaSなのか、再試行なのかを分けられる。モデルを替えた後に、速くなった代わりに再問い合わせやレビュー時間が増えていないかも追える。
速度のSLOは、品質・安全性のSLOと対にする
速度をKPIにすると、短いが不完全な回答、根拠を確認しない自動実行、失敗を隠した打ち切りが起こりやすい。そこでサービス目標は、時間だけで定義しない。
たとえば、障害調査支援なら次のように置ける。
| 指標 | 例となる目標 |
|---|---|
| 応答性 | P95で指定時間内に、調査開始と現在の状態を返す |
| 完了性 | 必要なログ・変更履歴・影響範囲の確認項目を満たす |
| 正確性 | 人間レビューで重大な誤誘導がない割合を維持する |
| 安全性 | 本番変更は必ず別の承認経路を通る |
| 復旧性 | タイムアウトやキャンセル時に、何を実行したかを追跡して安全に再開できる |
数値の閾値は、業務のリスクと既存の人手プロセスから決めるべきである。会話表示と、本番環境を変更する操作に同じSLOを置く必要はない。後者では、速度よりも停止可能性、二重確認、監査可能性を優先する場面がある。
速い推論が価値になるのは、人の判断を急かさないとき
OpenAIはUltrafastのユースケースとして、障害対応、金融調査、セキュリティ、サポート、ライブな実験を挙げる。その説明でも、障害対応ではエンジニアが判断とデプロイに責任を持つとしている。OpenAIが示す利用例
これは重要な線引きだ。AIが速く状況を整理できることと、AIに素早く重要な変更を実行させることは別である。
速さを活かすなら、まずは読み取り専用の観測、情報の整理、次の確認候補の提示、下書き作成、並列調査に使う。外部送信、顧客への確定回答、本番変更、権限変更は、速度に関係なく宛先・条件・承認・監査を独立した仕組みで確認する。
モデル選定は「能力・単価・速度」から「完了性能」へ
Ultrafastは、フロンティアモデルをより速く返すという新しい選択肢を示した。限定プレビューの現時点では、発表値だけで採用を決める段階ではない。それでも、AIを選ぶ物差しに速度を加えること自体は正しい。
ただし見るべきなのは、出力tokens/secだけではない。
- 利用者が最初の有用な反応を得るまでの時間
- ツール、再試行、承認を含む業務完了までの時間
- P95/P99で守れるかという本番の安定性
- 同じ品質・安全性を保ったまま、どれだけ人の反復を短くできるか
- プロバイダーやモデルを替えたときに、測定・制御・復旧できるか
高速なAIは、待ち時間を短くするだけではない。観測、仮説、検証、判断という仕事のループを短くする。その価値を実際の業務へ変えるのは、速いモデルそのものではなく、時間を測り、適切に振り分け、止められる形で運用するシステム設計である。
作成日：2026年8月28日