OpenAI GPT-5.6の価格・速度改定とモデル選択戦略

OpenAIは、GPT-5.6製品群の実行効率の改善を、API価格の引き下げと処理速度の向上につなげた。重要なのは、最も強力なモデル1つをすべての作業に適用することではなく、作業のリスク・複雑さ・レイテンシ・検証可能性に応じてSol、Terra、Lunaを組み合わせ、結果当たりのコストを下げることである。

価格と性能の数値は、OpenAIが2026年7月30日に発表した内容に基づく。顧客企業のベンチマークと効率改善の数値は、OpenAIまたは発表内で引用された企業による測定結果であるため、すべての環境で同様に再現されるとは限らない。

2026年7月30日のAPI価格変更

GPT-5.6 LunaとTerraの変更後のAPI価格は次のとおりである。

ChatGPTとCodexの有料サブスクリプション価格や全体の割り当て予算は、今回の発表では変更されない。ただし、TerraとLunaを使用する際に差し引かれるクレジットは減少する。AWS経由の価格変更は、7月30日遅くから順次適用されるとOpenAIは案内した。

APIコストの計算例

トークンコストは次のように計算できる。

総コスト = 入力トークン数 ÷ 1,000,000 × 入力単価 + 出力トークン数 ÷ 1,000,000 × 出力単価

たとえば、入力1,000万トークンと出力200万トークンを処理する場合、単純なトークン単価に基づくコストは次のとおりである。

実際の請求額には、キャッシュの適用有無、選択した処理方式、ツール呼び出し構造など、サービスごとの条件が影響する可能性がある。

GPT-5.6製品群の役割

GPT-5.6は単一モデルではなく、コストと性能が異なる階層型の製品群で構成される。

GPT-5.6 Sol

Solは、最高水準の推論と複雑な問題解決を担う。要件が曖昧な場合や失敗コストが大きい判断、長期計画、重要な結果のレビューに適している。

GPT-5.6 Terra

Terraは、性能、コスト、応答速度のバランスを目標とする。組織内の質疑応答、範囲が定められたエージェント業務、一般的な分析やコーディングなど、Lunaより高い判断力が必要だが、常にSolを使用する必要はない作業に適している。

GPT-5.6 Luna

Lunaは最も高速で低価格な階層である。単純な短文生成だけでなく、ツール呼び出しや複数段階のワークフローにも対応するため、明確に定義された作業を大規模に繰り返す実行モデルとして活用できる。

代表的な適用業務は次のとおりである。

• 大量の文書および顧客問い合わせの分類
• 構造化されたデータの抽出
• 反復的なコード修正
• テストの作成と実行
• ルールが明確な文書生成
• 大規模なコンテンツレビュー
• バックグラウンドエージェントの自動化
• 反復的なリサーチ支援

OpenAIは、Lunaが1年前に最先端クラスと評価されていたモデルと同程度の性能を、推定される作業当たり約6%のコストと、ほぼ9倍の速度で提供すると主張している。ここでの6%はトークン単価の直接比較ではなく、同じ作業結果を得るために必要な推定コストを比較した値である。

Sol Fast modeの特徴

GPT-5.6 Solには、API向けのFast modeが導入された。これは従来のPriority Processingに代わるもので、Codexの/fast機能に対応する概念である。

Fast modeの最大2.5倍という表現は、すべてのリクエストのレイテンシが正確に同じ割合で短縮されることを保証するものではない。プロンプトの長さ、出力の長さ、サービス負荷、ツール呼び出し回数によって、実際に体感する速度は異なる可能性がある。

Fast modeが適している場合

• ユーザーが応答を待つリアルタイムサービス
• コードの修正と確認を迅速に繰り返す開発環境
• Solの呼び出しがエージェント全体のレイテンシを決める作業
• インシデント対応や障害分析のように、数分の遅延も重要となる状況
• 処理遅延によって発生するコストが追加のAPIコストを上回る業務

バックグラウンドバッチ、夜間分析、非同期処理のように、完了時点を急がない作業ではStandard処理の方が経済的な場合がある。

結果重視のモデル選択基準

モデル選択は、ランキング表で最上位のモデルを選ぶ問題ではない。次の質問を作業ごとに検討する必要がある。

明確で自動検証が可能な作業は、Lunaに適している可能性が高い。一定の判断力が必要ならTerraを検討できる。曖昧さの解消、高リスクの判断、または失敗結果の最終レビューにはSolが適している。

Solで計画しLunaで実行する構成

1つのエージェント作業内でも、段階ごとに異なるモデルを配置できる。たとえば、コーディングエージェントは次のように構成できる。

1. Solが要件の曖昧さを見つけ、質問を整理する。
2. Solが実装計画、変更範囲、リスク要因を決定する。
3. Lunaが明確になった変更内容をコードとして実装する。
4. Lunaがテストを作成して実行する。
5. LunaまたはTerraがテスト結果とコードの差分を評価する。
6. 失敗の可能性が高い、または重要な結論のみをSolが再検討する。

この構成では、すべての段階でSolを使う方式よりコストを抑えながら、重要な判断に高い推論能力を集中できる。ただし、モデルを分ける場合は、ルーティングルール、エラー処理、ログ追跡、評価体系を別途設計する必要がある。

価格引き下げを支えた3つの効率階層

OpenAIは、コスト削減が単なる価格政策ではなく、3つの階層における技術的改善から生まれたと説明している。

1. モデル自体のトークン効率
2. 推論システムのハードウェア効率
3. モデル・ツール・コンテキストを接続するエージェントハーネスの効率

この説明はOpenAIが公開した技術資料に基づくものであり、詳細なコスト構造のすべてが外部に公開されたわけではない。したがって、価格引き下げに対して技術効率と戦略的な価格政策がそれぞれどの程度寄与したかを、外部から確定することは難しい。

モデルと推論システムの最適化

トークン当たりの作業遂行量の改善

GPT-5.6は、作業成功率だけでなく処理効率も同時に最適化するよう訓練されたというのがOpenAIの説明である。不必要に長い推論や反復を減らし、より少ないトークンで必要な結果に到達するよう設計することで、トークン当たりの知能と作業遂行量を高めたという意味である。

負荷分散とリクエストルーティング

推論システムは、地域、利用可能な容量、アクセラレーターの種類に基づいて、リクエストをデータセンターとクラスターに分配する。クラスター内部では、現在の負荷、入力コンテキストの長さ、キャッシュの利用可能性、リクエストの特性などを考慮してモデルインスタンスを選択する。

OpenAIは、GPT-5.6 SolとCodexをプロダクショントラフィックの分析、負荷不均衡の原因調査、ルーティング戦略の試験、ヒューリスティクスの調整に活用したと明らかにした。

GPUカーネルの最適化

GPUカーネルは、モデルの数学演算をハードウェア上で実行する中核コードである。メモリ移動、同期、データ配列、並列化方式によって、同じGPUでも処理コストは異なる。

OpenAIによると、GPT-5.6 SolはCodex環境でTritonとGluonを使用し、プロダクションカーネルの作成と最適化に関与した。カーネルの改善と関連する最適化を合わせた結果、モデル提供のエンドツーエンドコストが20%削減されたと同社は明らかにした。

エンドツーエンドコストとは、特定の演算1つではなく、ルーティング、データ移動、モデル実行、出力生成など、実際のリクエスト処理全体にかかるコストを指す。

カーネルの正確性検証

高速なカーネルでも、数値的に誤った結果を生成すれば使用できない。OpenAIは、AIが作成したカーネルの正確性を確認するため、FpSanを含む検証ツールに投資したと説明している。FpSanはFloating-Point Sanitizerの略で、浮動小数点演算に関連するエラーを検出するオープンソースツールである。

これは、AIがプロダクションインフラのコードを生成する際、性能ベンチマークだけでなく、数値検証、回帰テスト、失敗時の復旧手順も必要であることを示している。

投機的デコーディングとKVキャッシュ

投機的デコーディング

投機的デコーディングは、小さなドラフトモデルが今後生成されるトークンを先に提案し、大きなメインモデルが複数の候補を並列に検証する方式である。提案が受け入れられれば、メインモデルによる高コストな逐次計算の回数を減らせる。

OpenAIは、GPT-5.6 Solがドラフトモデルのサイズと構造を変更する数百件の実験を設計・実行し、学習をモニタリングしたと明らかにした。その結果、トークン生成効率が15%以上向上したという説明である。

KVキャッシュとワークロード別の設定

モデルは入力を処理しながらKey-Valueキャッシュ、すなわちKVキャッシュを作成する。最適な設定は、入力と出力の長さ、バッチサイズ、キャッシュヒット率、同時リクエスト数、メモリ容量、モデルのシャーディング方式によって異なる。

OpenAIは、SolとCodexで実際のワークロードを分析し、設定候補を評価して、作業タイプ別のエンジン構成を細かく調整したと説明している。目的は、同じハードウェアでより多くのリクエストを処理することである。

エージェントハーネスとコンテキストコスト

エージェントは、1回のユーザーリクエストを解決するために、モデルとツールを複数回呼び出す。モデル呼び出しが30回必要な作業で、各呼び出しに1秒の不要な遅延が発生すると、全体の遅延は約30秒増える可能性がある。

OpenAIは、モデル、ツール、ユーザー環境を接続するRustベースのオーケストレーション階層を、エージェントハーネスと説明している。

必要なツールのみを遅延公開

ツール、プラグイン、スキル、MCP統合情報を最初からすべてプロンプトに入れると、入力トークンとレイテンシが増加する。ハーネスは、必要な時点でのみ関連するツール情報を公開する遅延探索方式を使用する。ツール出力は、モデルが別途上限を要求しない限り、デフォルトで1万トークンに制限されるとOpenAIは明らかにした。

正確なプレフィックスの保持とプロンプトキャッシュ

プロンプトキャッシングは、以前に処理した入力と同一の冒頭部分を再利用し、重複演算を減らす。キャッシュを再利用するには、プロンプトのプレフィックスが正確に一致する必要がある。

OpenAIのハーネスは、履歴を追記専用構造で管理し、新しいメッセージとツール結果を末尾に追加する。ツールは決定論的な順序で提示し、承認ポリシーのような実行設定はツール定義自体を変更せず、ランタイムに適用する。この方式は、反復的なエージェントループのキャッシュヒット率を高めるうえで有利である。

企業事例の数値の読み方

OpenAIの公式発表には、Replit、Notion、Ramp、Blitzy、Cognition、Dustなどの評価が含まれている。

• Notionは自社評価において、TerraがGPT-5.5と同程度の品質を、作業当たり半分のコストと60%短い時間で提供したと明らかにした。
• Blitzyは、Lunaの適用後、プロンプトキャッシュの再利用率が24%から90%に上昇し、従来のデフォルトモデルよりコストが87%低かったと説明した。
• Dustは、同じエージェント業務において、Lunaが従来のデフォルトモデルより40%高速で、40%低コストだったと明らかにした。
• Rampは、Lunaをバックグラウンドエージェント自動化のデフォルトモデルとして使用していると明らかにした。

これらの数値は、各企業の内部作業、プロンプト、評価基準、システム構造で測定された事例である。独立した共通ベンチマークではないため、他の組織の業務にそのまま適用すべきではない。導入前には、実際のデータとエラーコストを反映した独自評価が必要である。

導入前の検証チェックリスト

1. 代表的な作業サンプルと正解または評価基準を用意する。
2. Luna、Terra、Solの成功率と再試行率を同じ条件で比較する。
3. トークンコストだけでなく、ツール呼び出し、レビュー要員、失敗からの復旧コストを含める。
4. 平均レイテンシとともに、上位95%または99%のレイテンシを測定する。
5. 自動テストやスキーマ検証が可能な段階を、低価格モデルの候補として分類する。
6. 個人情報、セキュリティ、規制に関連する作業には、別途承認と記録のポリシーを適用する。
7. 信頼度の低い結果をTerraまたはSolにエスカレーションするルーティング基準を定める。
8. Fast modeの追加コストよりレイテンシ短縮の価値が大きいか、実際のトラフィックで検証する。

意義と限界

今回の再編は、AIモデル競争の基準が最高スコア1つから結果当たりのコストへ移行していることを示している。大規模な反復作業にはLuna、日常的な知識業務にはTerra、曖昧で重要な判断にはSolを配置することで、知能・速度・コストを業務ごとに組み合わせられる。

ただし、80%の価格引き下げが技術効率の改善と市場戦略にそれぞれどの程度由来するのかは、公開情報だけでは切り分けることが難しい。また、低価格モデルの経済性はトークン価格だけで決まるものではない。エラー率が高くなり、再試行や人によるレビューが増えれば、作業全体のコストが上昇する可能性がある。

したがって、重要な指標はモデル呼び出し1回の価格ではなく、検証を通過した結果1件を生み出すためにかかった総コストである。モデル別の成功率、再試行回数、レイテンシ、レビューコストを合わせて測定してこそ、GPT-5.6の価格引き下げが実際の事業価値につながるかを判断できる。