OpenAIがGPT-5.6のLunaとTerraを値下げ｜業務で見直すこと、見直さなくていいこと

OpenAIは2026年7月30日、GPT-5.6ファミリーのうち下位2モデル(Luna・Terra)のAPI価格を引き下げました。Lunaは80%、Terraは20%の値下げで、最上位のSolは据え置きです。GPT-5.6ファミリーの一般公開が2026年7月9日でしたから、公開からわずか3週間ほどでの改定ということになります。この記事では、公式のPricingページで確認できる現行単価を起点に事実を固めたうえで、「この値下げは自社の業務の何を変え、何を変えないのか」を切り分けます。GPT-5.6ファミリーそのものの位置づけやChatGPT Workについては別記事で扱っているため、ここでは価格改定という個別の出来事と、それを受けた実務の見直しに絞ります。

何が変わったのか#

まず事実関係です。OpenAIの公式Pricingページ(developers.openai.com)で執筆時点(2026年8月1日)に確認できるGPT-5.6の標準単価と、報道で伝えられている改定前の単価を並べると次のようになります。金額はいずれも100万トークンあたりの米ドルです。

改定後の数値(Luna 0.20/1.20、Terra 2.00/12.00、Sol 5.00/30.00)は公式Pricingページで確認できます。改定前の数値(Luna 1.00/6.00、Terra 2.50/15.00)はCNBC・InfoWorld・ITmedia・窓の杜など複数の報道が一致して伝えている値で、公式ページには過去の単価が残らないため、この部分は二次情報に依拠しています。

ここで一つ注意が必要です。上の表に載せた単価は、公式Pricingページの標準料金表のうちShort contextの列の値です。GPT-5.6の3モデルには、同じ表にLong contextの列も別建てで用意されていて、そちらはLunaが入力0.40ドル・出力1.80ドル、Terraが入力4.00ドル・出力18.00ドル、Solが入力10.00ドル・出力45.00ドルと単価が上がります。長い文書の要約やRAGのように文脈が長くなる処理では、Short contextの単価だけで試算すると実際の請求と食い違う可能性があります。なお、Short contextとLong contextを切り替える閾値は、GPT-5.6の行には併記されていません(gpt-5.5・gpt-5.4の行には272Kコンテキスト長未満を示す注記が付いています)。自社の入力長がどちらに当たるかは、請求実績で確かめるのが確実です。

公式Pricingページでは、標準単価のほかに次の区分も確認できます。Lunaのキャッシュ済み入力は0.20ドルの10分の1にあたる0.02ドル、キャッシュ書き込みは0.25ドルです。時間的な制約が緩い処理に使うBatchとFlexはいずれも標準の半額で、Lunaなら入力0.10ドル・出力0.60ドルになります。大量処理の見積もりでは、標準単価だけでなくこれらの区分まで見ておくと桁が変わります。

Priority processingがFast modeへ改称#

同じ日に、処理速度に関する提供形態の名称も変わっています。公式Pricingページの注記には、Priority processingが2026年7月30日にFast modeへ改称されたこと、APIリクエストではservice_tier: "priority"とservice_tier: "fast"のどちらも引き続き使えることが明記されています。既存の実装をすぐ書き換える必要はない、という後方互換の扱いです。

改称と同時に、Sol向けのFast modeの処理速度も引き上げられています。公式のFast modeガイドには、改称にあわせてgpt-5.6-solのFast modeの速度を上げ、標準処理に対して最大2.5倍速くしたという趣旨の説明があります。単価のほうは、公式Pricingページ上でSol・Terra・LunaのいずれもShort contextの標準単価のちょうど2倍です(Solは入力10.00ドル・出力60.00ドル、Lunaは入力0.40ドル・出力2.40ドル)。「最大」である点と、速度引き上げの対象としてSolが挙げられている点は、見積もりに使う際に踏まえておきたいところです。

値下げの理由として説明されていること#

OpenAI側の説明は、報道を通じて次のように伝えられています。InfoWorldは、同社が価格引き下げの理由を「サービング効率の改善」、すなわち学習・推論インフラ全体の最適化に帰していると報じています。ITmediaはより具体的に、Solが本番環境のカーネルを自律的に書き換えて最適化し、多数の実験を設計・実行した結果、モデル提供のエンドツーエンドのコストが20%削減され、トークン生成効率が15%以上向上したという説明を伝えています。

ここは冷静に読むべきところです。効率改善の数値はいずれも提供元自身の説明であり、第三者が検証したものではありません。また、効率が改善したことと、それを価格に反映することの間には経営判断が挟まります。同じ効率改善があっても値下げしない選択肢はあり得たわけで、「効率が上がったから自動的に安くなった」という因果だけで理解すると、次の改定の読み違いにつながります。

同様に、OpenAIがLunaについて他社モデルとの比較で「タスクあたりの推定コストが大幅に低い」といった主張をしていることも報じられていますが、これはベンダー自身が選んだタスクと条件での比較です。自社の業務で同じ差が出るかは、自社のデータで測るまで分かりません。

改定後の単価(Short context・Long contextとも)・Batch/Flex/Fast modeの単価・Priority processingのFast modeへの改称(2026年7月30日)・Solが標準比で最大2.5倍速とされる点は、OpenAI公式のPricingページおよびFast modeガイドで確認しました。改定前の単価、値下げ率(Luna 80%・Terra 20%)、OpenAI側が説明したとされる効率改善の内訳、競合状況の記述は、CNBC・InfoWorld・ITmedia・窓の杜の報道に基づく二次情報です。効率改善の数値および他社比較の主張は提供元の説明であり、独立した検証結果ではありません。

背景にあるもの:安い階層での競争#

なぜ下位2モデルだけが下がり、最上位のSolは据え置かれたのか。ここは推測を避けたい部分ですが、報道が伝える市場の状況は参考になります。

CNBCは、企業がAIへの支出に慎重になり、投資対効果がはっきりしないまま高価なモデルを本番投入することをためらうようになっていること、そして中国系スタートアップやGoogle・Microsoftといった大手が費用対効果を前面に出したモデルを打ち出していることを、今回の改定の背景として挙げています。同記事では、Moonshot AIが7月に公開したオープンウェイトモデルKimi K3が一部のベンチマークで先行モデルを上回ったこと、AnthropicがClaude Opus 5をFable 5の半額として投入したこと、GoogleがGemini 3.6 Flashを含む低価格帯の新モデルを出したことが、具体例として言及されています。

つまり、価格圧力がかかっているのは主に「安くて十分使える」帯であって、最上位帯ではありません。下位2モデルだけが下がったという改定の形は、この構図と整合的です。ただしこれは報道が示す状況からの読み取りであり、OpenAIが公式に「競合対応で下げた」と述べたわけではない点は区別しておきます。

実務で何が変わるか#

ここからが本題です。単価が下がったという事実を、自社の業務のどこに効かせるかを整理します。

1. 大量処理タスクの経済性が変わる#

いちばん直接的に効くのは、件数が多く、1件あたりの処理が定型的なタスクです。問い合わせの分類、文書の要約、投稿のモデレーション、タグ付け、抽出といった処理が該当します。

具体的に計算してみます。1件あたり入力2,000トークン・出力300トークンの分類タスクを、月100万件処理する場合を考えます。入力が短いため、Short contextの単価で計算しています。

Lunaは5分の1になります。この規模だと、これまで「コストが見合わないので人手のまま残していた」処理が、検討の土俵に乗ってくる可能性があります。さらにBatchやFlexが使える性質の処理なら、Lunaで380ドルまで下がります。

2. モデル階層の使い分けの判断軸を引き直す#

今回の改定でより重要なのは、単価そのものより階層間の価格差が変わったことです。出力単価の比を見ると、Sol:Terra:Lunaは改定前が30:15:6、すなわち5:2.5:1でした。改定後は30:12:1.2で、25:10:1になります。

これが意味するのは、「Solで済ませていた仕事をLunaに落とせたときの見返り」が、以前の5倍から25倍に広がったということです。逆に言えば、上位モデルを惰性で使い続けることのコストが、相対的に重くなりました。

見直しの判断軸は、次の3つで足ります。

3. 価格が動く前提で作っておく#

公開から3週間で8割の値下げが入ったという事実は、それ自体が設計への示唆です。価格も、モデルのラインナップも、提供形態の名称すら(Priority processingがFast modeになったように)動きます。動くものを前提に作っておくというのが、今回のいちばん実務的な教訓かもしれません。

具体的には、次のような作りにしておくと、改定のたびの作業が小さくなります。

特に4つ目のログは、値下げの効果を測るときにも、次の改定で判断するときにも効きます。どのタスクが月にいくら使っているかが分からないと、「どこを下位モデルに落とすべきか」の優先順位が付けられません。逆にこれさえあれば、改定のたびに数分で影響額を試算できます。

4. 価格だけで乗り換えないための評価#

安くなったモデルへ切り替えるかどうかは、価格ではなく品質で決める判断です。ここを飛ばすと、請求額は下がったが問い合わせの誤分類が増えていた、という形で後から跳ね返ってきます。

手順としては、次の順番が現実的です。

値下げしても変わらないもの#

最後に、今回の改定で変わらないものを明示しておきます。ここを混同すると、コスト削減の判断が品質やリスクの判断を押し流してしまいます。

• 精度要件:単価が下がっても、そのタスクに必要な精度は下がりません。安いモデルで要件を満たせないなら、それは「安く済んだ」ではなく「使えない」です。
• レイテンシ:価格と応答速度は別の軸です。速度が要件になる用途では、Fast modeのような上位の処理区分を選ぶことで、値下げ分が相殺されることもあります。
• データの取り扱い:入力したデータがどう扱われるか、どの地域で処理されるかといった条件は、価格改定とは無関係です。契約・利用規約の側で確認する項目のままです。
• ベンダーロックイン:安い階層に業務を寄せるほど、そのベンダーへの依存度は上がります。単価が下がったからといって、切り替え経路を持たなくてよい理由にはなりません。
• 移行コスト:モデルを差し替える作業自体には、検証と監視のコストがかかります。月額の削減幅が小さいタスクでは、移行コストのほうが上回ることが普通にあります。

よくある質問#

まとめ#

2026年7月30日のGPT-5.6 Luna・Terraの値下げは、単価そのものより、階層間の価格差が広がったことに実務上の意味があります。上位モデルを惰性で使い続けるコストが相対的に重くなり、下位モデルへ落とせる仕事を見つける作業の見返りが大きくなりました。一方で、精度要件やデータの取り扱いといった、価格とは別の軸で決めるべきことは何も変わっていません。公開から3週間で8割動く世界では、特定の単価に最適化するより、単価が動いても素早く追随できる状態を作っておくほうが、結果的に安く済みます。まずは自社の呼び出しログを開いて、どのタスクにいくら払っているかを確かめるところからで十分です。