GPT-5.6とは、OpenAIが3階層で提供する汎用モデルファミリーである。
階層は Sol・Terra・Luna の3つ。単価は入力で5倍、出力でも5倍の開きがあります。ところが「高いほど良い／安いほど得」で選ぶと、どちらの方向にも外れる。長い文脈に散った複数箇所の回収が重要なら Terra 以上を起点に検証し、短文を大量にさばくなら Luna を起点にする。探索そのものに価値がある難所だけ Sol へ上げる。この切り分けが目安になります。この骨子を、公式が公開している単価・評価値・推論効率の仕様と、第三者が公開した実測検証から順に組み立てていきます。
なお本記事の料金・モデルID・推論効率の段階・提供プランは、2026年7月22日時点で参照した OpenAI 公式ドキュメントおよび GitHub 公式の変更履歴に基づく値です。この領域は改定が速いため、実運用前の最終確認は各公式ページで行ってください。以降の章ではこの注意書きを繰り返しません。
- API のモデル仕様では、3モデルともコンテキスト1,050,000トークン・最大出力128,000トークンが共通（ただし Codex などの製品経路では利用できる上限が異なる場合がある）。本記事が特に扱うのは価格と MRCR 型の長文多点想起（OpenAI MRCR v2 8-needle の 256K〜512K 区間で Sol 91.5%・Terra 89.6% に対し Luna 41.3%）の差だが、能力・速度・タスク別の性能にも階層差がある
- 入力単価は Sol $5.00／Terra $2.50／Luna $1.00（$/1Mトークン、2026年7月22日時点の公式値）。キャッシュや Batch は絶対額を大きく動かすが、同じトークン量・同じ課金区分なら階層間の比は 5:2.5:1 のまま。総額の比がずれるのは、モデルごとに出力・推論トークン量や再試行回数が変わるとき
- 階層とは別に推論効率のつまみがあり、GPT-5.6 で指定できるのは
none/low/medium/high/xhigh/maxの6段階。さらに Responses API には効率とは独立した実行モード（standard / pro）がある。コストが合わないときは階層を落とす前に効率を1段下げ、同じ代表タスクで測るほうが失うものが少ない
Sol・Terra・Lunaは何が違うのか｜3階層の位置づけと共通仕様
GPT-5.6 は2026年7月9日に一般提供が始まりました（当日は最大24時間をかけた段階展開）。API では Sol・Terra・Luna の3モデルを指定できます。Work in ChatGPT では Plus・Pro・Business・Enterprise が3モデルを利用でき、Codex では Free・Go が Terra、Plus 以上で3モデルから選べます。通常の Chat は GPT-5.5 Instant が既定で、対象の有料プランでは、プランに応じて Medium・High・Extra High を選んだときに Sol が使われるほか、自動切り替えが有効なら複雑な依頼で Instant から Medium へ移ることもあります。Pro・Business・Enterprise では Sol Pro も選べます。世代番号（5.6）と能力の階層を分離した命名で、モデルIDは gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna。公式のモデルドキュメントによると、gpt-5.6 とだけ指定した場合は最上位の Sol にルーティングされます。ここを意識せずエイリアスで書いていると、最上位を常時呼び続ける構成になりかねません。
公式のモデル一覧における位置づけは、次のように整理されています。
公式ドキュメントでは、sol はフラッグシップ、terra は低価格で強い性能を出す選択肢、luna は高ボリューム処理向けの効率重視モデル、と位置づけられています。
先に押さえておきたいのが、共通仕様の広さ。API のモデルページでは、3モデルとも入力コンテキストは1,050,000トークン、最大出力は128,000トークン、知識のカットオフは2026年2月16日で揃っています。ただしこれは、各製品上で常に1,050,000トークンを使えることを意味しません。ともあれ「Luna は器が小さいから長文を渡せない」わけではない。100万トークン級の入力を投げること自体は、API では最安の Luna でも仕様上は可能です。
では何が違うのか。選定で効いてくる比較軸は、能力・速度・価格、そして長文をどう扱えるかの4つです。器の大きさは共通なので、差が出るのはその中身のほうになります。関数呼び出しや構造化出力、ストリーミングといった API 機能は3モデルとも対応しており、機能の有無で切り分ける場面はほとんどありません。選定の論点は、精度の落差と価格構造、そして次章以降で扱う推論効率の設定に移ります。
3モデルの比較表
| 項目 | Sol | Terra | Luna |
|---|---|---|---|
| モデルID | gpt-5.6-sol | gpt-5.6-terra | gpt-5.6-luna |
| 入力単価（$/1Mトークン） | $5.00 | $2.50 | $1.00 |
| 出力単価（$/1Mトークン） | $30.00 | $15.00 | $6.00 |
| キャッシュ読み込み単価（$/1Mトークン） | $0.50 | $0.25 | $0.10 |
| API コンテキスト上限 | 1,050,000トークン | 1,050,000トークン | 1,050,000トークン |
| 長文からの多点想起 （MRCR v2 8-needle / 256K〜512K） |
91.5% | 89.6% | 41.3% |
| 用途別の目安 （公式の位置づけ＋本記事の評価から整理） |
難所の探索・大規模な書き換え | 日常的な実装・レビュー・要約 | 短文の分類・整形・抽出を大量に（MRCR 型の長文多点回収では Terra 以上を優先候補に） |
最終行は公式のティア説明そのものではなく、公式の位置づけ（Sol=フラッグシップ、Terra=低価格で高性能、Luna=最速・最安）に、ここまでの評価値を重ねて整理したものです。表で目を引くのは単価の5倍差ですが、選定を分けるのは最終行と最終行のひとつ上。多点想起の成績と想定ワークロードが、価格以上に用途を規定します。長い仕様書やログを扱う場合、MRCR に近い多点回収が処理の中心なら、Luna で精度差が出ないかを代表タスクで確認する必要があります。
料金差5倍をどう読むか｜単価表と実効コストのズレ
公式料金ページに載っている単価は、あくまで標準区分の値。実際の請求額は、そこにいくつかの係数が掛かった結果です。単価表の比率がそのまま月額の比率になるとは限りません。
まず効くのがキャッシュ入力。同じプレフィックスを繰り返し送る構成では、キャッシュヒットした入力トークンは通常入力の10分の1の単価で計上されます。Sol なら $5.00 が $0.50、Terra なら $2.50 が $0.25。長いシステムプロンプトや共通の参照資料を毎回先頭に置くエージェント構成では、入力側の実効単価が大きく下がります。ただし下がり方は3階層とも同じ10分の1なので、階層間の比は変わりません。動くのは絶対額のほうです。「Sol は入力が高いから避ける」という判断は、キャッシュヒット率を測る前だと粗すぎる。
一方で見落としやすいのがキャッシュ書き込み。GPT-5.6 系では、キャッシュへ書き込まれたトークンは通常入力の単価ではなく、その1.25倍のキャッシュ書き込み単価で課金されます。ヒット時の割引だけを見積もりに入れて書き込み分を落とすと、試算は実額より低く出ます。
処理の緊急度でも単価は動きます。Batch 区分に流せば標準の50%引き、逆に Priority 区分は標準の2倍です。夜間にまとめて回せる分類・要約バッチを Batch に寄せれば請求額は半分になりますが、これも3階層に同率で効くため、Terra と Luna の比は 2.5:1 のまま変わりません。さらに、入力が272,000トークンを超えるリクエストは長文区分に入り、そのリクエスト全体が入力2倍・出力1.5倍で課金されます。API のコンテキスト上限が1,050,000トークンあるとはいえ、その4分の1ほどで単価が跳ねる計算です。100万トークン級どころか、数十万トークンの仕様書やログを常用する設計なら見積もりに織り込む必要があります。
整理すると、キャッシュ・Batch・Priority・長文区分は請求の絶対額を大きく動かします。ただしこれらの係数は3階層すべてに同じ割合で掛かるため、同じトークン量を同じ区分で流す限り、単価比 5:2.5:1 は崩れません。総額の比が単価表からずれるのは、モデルごとに出力・推論トークン量、再試行や失敗の頻度、キャッシュヒット率、タスク完了までのエージェント往復数が変わるからです。つまり階層を落とすかどうかは、単価表でも係数でもなく「同じ仕事を終えるのに何トークン使うか」を測ってから判断することになります。
得意分野の差はどこに出るか｜コーディング指標と長文文脈で挙動が割れる
公開されている評価値を並べると、指標によって3階層の並び方がまったく違います。ここが選定の分かれ目。
コーディング系のエージェント評価では、OpenAI の発表ページに掲載された Artificial Analysis Coding Agent Index で Sol 80・Terra 77.4・Luna 74.6 と、価格順に小差で並びます（いずれも推論効率 max での測定値）。5点あまりの幅に3階層が収まっている。この指標だけを見るなら、単価が5分の1の Luna は十分に健闘していると読めます。ただし点差の細部に依存した順位づけは避けたほうがよく、ここで読み取るべきは「コーディング系の総合評価では階層差が劇的には開かない」という事実にとどめます。
挙動が割れるのが、長い文脈から複数の該当箇所を回収する形式。OpenAI が公表している MRCR v2 8-needle では、256K〜512K の区間で Sol 91.5%・Terra 89.6% に対して Luna は 41.3%。512K〜1M では Sol 73.8%・Terra 72.5%・Luna 41.3% で、上位2階層も落ちます。価格順に緩やかに下がる指標ではなく、Luna のところで崖になっている形です。
ただし、これを「長文全般で Luna は不向き」と読むのは行き過ぎです。同じ公式表の GraphWalks BFS（f1）では、256K で Sol 90.7・Terra 76.9・Luna 81.3 と、Luna が Terra を上回っています。1M では Sol 77.1・Terra 71.2・Luna 51.2 と順序が戻ります。長文での強さは課題の形式によって入れ替わる、というのが実際のところ。MRCR から言えるのは、長い文脈に散った複数の該当箇所を正確に回収する用途で、特に 256K〜512K 区間の Luna に大きな落差が確認された、という限定的な範囲です。窓のサイズは「入る」ことを保証しても、「読める」ことは保証しません。
逆に、入力が短く自己完結しているタスク——1件ずつの問い合わせ分類、決まった書式への整形、短いテキストからの項目抽出——では、この崖は踏みません。Luna が向くのは、渡す文脈が短く、1回あたりの失敗コストが低く、件数が多い領域。この条件から離れるほど、Luna のままでよいかを実タスクで確かめる必要が増える、と考えると整理しやすいはずです。
なお、ここで挙げた数値はいずれも公開されている評価値であり、当サイトが実機で測ったものではありません。品質の体感や、特定の業務タスクへの適性は別の次元で、本記事では未評価です。ご自身の代表タスクで確認する前提で読み進めてください。
階層を変える前に、推論設定を試す
GPT-5.6 の選定でモデル名だけを議論するのは、レバーを1本しか使っていない状態。API では推論効率を none / low / medium / high / xhigh / max の6段階で指定でき、同じモデルでも投じる推論量が変わります。OpenAI の Reasoning models ガイドでは minimal に対応するモデルも案内されていますが、GPT-5.6 の各モデルページに対応値としての記載はありません。同じ Terra でも、low と high では所要時間もコストも出力の質も別物になる。
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-5.6-terra",
reasoning={"effort": "high"},
input="このモジュールのバグを特定して修正案を出して",
)
print(resp.output_text)実務上の起点は medium。応答速度を優先する対話用途や、推論をほぼ必要としない整形処理では none / low へ下げます。逆に high / xhigh へ上げるのは、上げた効果が自分のタスクで測れたときだけ。効果を測らずに上げると、目に見える出力に加えて課金対象の推論トークンが増えるぶん、請求が伸びることがあります。max は最上段ですが、常用ではなく xhigh との直接比較で採否を決める位置づけと考えたほうが実態に合います。
混同しやすいのが ultra。これは API の効率設定の値ではなく、製品側に用意された設定で、既定で4つのエージェントインスタンスを並列に調整して多段のタスクに当たります。API 側で同種のことをしたいなら、効率値を上げるのではなく、Responses API のマルチエージェント機能（ベータ）を使う方向になります。multi_agent.enabled を有効にすると、親エージェントが複数のサブエージェントを並列に走らせて結果を統合する構成になり、公式は同時実行数（max_concurrent_subagents）の既定値として3を案内しています。ベータ提供のため、SDK なら betas 引数に、生の HTTP なら OpenAI-Beta ヘッダーに responses_multi_agent=v1 を渡すオプトインが要ります。仕様変更もありえます。いずれにせよ「ultra を effort に指定する」という書き方はできません。なお API には効率とは別に reasoning.mode があり、pro を指定すると同じ効率設定のままモデル側の処理量を増やして単一の回答を返します。効率とモードは独立した軸なので、難所に当てるなら効率を上げるのか pro に切り替えるのかを別々に測るのが順当です。
世代を乗り換えるときの手順にも触れておきます。GPT-5.5 など前世代から移す場合、効率設定を揃えないまま新旧を比べると、世代差なのか効率差なのか切り分けられません。まず現行と同じ効率値で基準を取り、そこから1段動かして測る。この順で回すと、階層を上げるべきか効率を上げるべきかの判断材料が同時に手に入ります。
maxを上げても伸びないタスク、伸びるタスク
推論効率を上げる価値はタスクの形で割れます。開発ツール Tura のメンテナーが GPT-5.6 Sol を対象に公開した自己分析（独立したレビューではない旨を本人が明記）によると、DeepSWE v1.1 のうち機械的に「限定的な修正」と分類した7タスクでは、high 64.3% に対して max 57.1% とスコアがむしろ下がりました。一方、機能実装では high 70.2% に対して max 74.6% と max が上回ります。データセット全体では 69.4% から 72.7% への上昇に対し、コストは2.42倍。サンプルが7件と小さく、測定対象も Sol のみのため、バグ修正全般や他の階層へ一般化できる結果ではありません。
この分かれ方には筋が通ります。max が買っているのは探索・修正・エージェントの試行回数であり、進むべき道筋が未確定なタスクほど効く。失敗するテストや修正範囲がすでに絞られているタスクでは、追加の探索に使える不確実性が比較的少ない、という説明が成り立ちます。本人による自己分析でサンプルも限られますが、「効率を上げれば常に良くなる」という前提を持たないための材料としては使えます。
第三者の実測検証が示した「最安が最善にならない」条件
公式の指標と別に、同一環境で3階層を回した検証も公開されています。Zennの検証記事によると、Raspberry Pi 5 上の Codex CLI で3タスクを各10回、モデルと推論効率の組み合わせ16パターン、合計480試行を実施。採点はエージェントに見せない隠しテストで自動判定し、世代間の比較は出力元を伏せた別モデルのブラインド判定で行っています。なお同記事のコストは実請求額ではなく、公表単価からの推定換算（キャッシュ書き込み分を含まない下限側の見積もり）です。
その結果として同記事が挙げているのが次の3点。
- コスパの山は最上位でも最安でもなく中位 × 高効率に来た（致命的な誤りがゼロで、所要時間と推定コストが抑えられた）
- 最安構成は10回中10回で同じ誤りを再現し、表面上のスコアが高くても品質面では使えなかった
- 同単価の前世代との差は、品質・推定コスト・時間の3軸では明確に出なかった（ブラインド判定では新世代側が優勢）
注意したいのは、これが第三者の個人による検証であり、当サイトの実測ではないという点。タスク内容も実行環境も限定的で、別のワークロードにそのまま当てはまる保証はありません。それでも読者側に翻訳できる見方が1つあります。平均スコアが高くても、同じ失敗が毎回再現するなら業務では使えない、ということ。10回中2回ばらばらに失敗するモデルと、10回中10回同じ箇所を外すモデルでは、後者のほうが平均点は高く出ることさえあります。評価するときは平均だけでなく、失敗の中身が毎回同じかどうかを見てください。
実際に触れる経路で選択肢が変わる（API・ChatGPT・Codex・GitHub Copilot）
同じファミリーでも、どこから使うかで選べるものが変わります。API では3モデルとも指定でき、推論効率も自由に設定可能。Work in ChatGPT では Plus・Pro・Business・Enterprise が Sol・Terra・Luna を利用でき、Codex では Free・Go が Terra、Plus 以上で3モデルを選べます。一方、通常の Chat は GPT-5.5 Instant が既定で、Sol が使われるのは、対象の有料プランでプランに応じた推論レベル（Medium・High・Extra High）を選んだとき、または自動切り替えが有効で複雑な依頼と判断されたときです。Free と Go にはその選択肢がありません。Pro・Business・Enterprise では Sol Pro も選べます。「ChatGPT でも Terra や Luna に落としてコストを下げる」という設計は、経路によっては成立しません。ultra も Work in ChatGPT では Pro と Enterprise、Codex では Plus 以上と提供範囲が分かれるため、契約内容を確認してから設計に組み込むのが安全です。
GitHub Copilot では、GitHub 公式の変更履歴によると Sol は Pro+ / Max / Business / Enterprise が対象で、Pro には含まれません。Terra と Luna は Pro 以上で使えます。Business と Enterprise では管理者がポリシーを有効化する必要があり、既定では無効。VS Code や Visual Studio、JetBrains 系 IDE、CLI、Web など選べる場所は広く、既存のモデル切替から選ぶ形です。
なお、API モデルのコンテキスト上限と、各製品で実際に使える上限は同一とは限りません。たとえば Codex CLI 0.144.6 では、GPT-5.6 の3モデルについてコンテキストウィンドウが272,000トークンへ訂正されています。API 料金が長文区分に入る境界も272,000トークンですが、こちらは課金の区分であって窓の大きさの話ではないため、混同しないでください。
チーム導入では、モデル選定より先にプランと管理ポリシーが制約になります。「Sol を標準にする」と決めても、メンバーの契約が Pro のままなら誰も選べません。社内標準を決める前に、全員のプランと管理画面の設定を揃えるところから。
選定でよくある外し方
選び方を間違えるパターンは、だいたい次のどれかに収まります。
- とりあえず最上位で固定する。推論効率を検証しないまま階層で押し切ると、コストだけが増えます
- とりあえず最安で固定する。表面のスコアが出ていても、同一の失敗が再現すれば手戻りで相殺されます
- 前世代からの移行で効率設定を据え置いたまま比べ、「変わらない」と結論づける
- 単価表だけで見積もり、キャッシュ書き込みや Priority などの区分を落とす
- Copilot のプラン制約を考慮せず社内標準を決める
共通しているのは、レバーが複数あるのに1本しか動かしていないこと。階層・推論効率・実行モード（standard / pro）は別々のつまみで、どれを回すかで効き方も費用も変わります。
まとめ
GPT-5.6 の3階層は、API のモデル仕様上はコンテキスト長や最大出力といった器が共通で、能力・速度・価格・長文処理の特性が異なります。長い文脈に散った複数箇所を回収する MRCR 型の処理では、Terra 以上を優先候補にする根拠があります（MRCR v2 8-needle の 256K〜512K 区間での落差）。ただし長文課題全般で Luna が劣るわけではなく、GraphWalks BFS の 256K では Luna が Terra を上回ります（本記事が参照した公表値の範囲では逆転はこの区間だけで、同じ GraphWalks でも 1M では順序が戻ります）。日常的な実装やレビューは Terra を基準線に置き、探索そのものに価値がある大規模な書き換えや移行だけ Sol へ上げる。定型の分類・整形・抽出は Luna へ落とす。この順で降ろせば、最上位固定と最安固定の両方を避けられます。
第三者検証の結果は個人による限定環境での測定であり、当サイトの実測ではありません。プラン別の提供状況も確認時点のもの。まず手元の代表タスクで、推論効率を1段だけ動かして測ってみてください。階層を変えるかどうかの判断は、そのあとで十分間に合います。
よくある質問
Q. Sol・Terra・Lunaで料金はどれくらい違いますか？
OpenAI 公式の料金ページによると、100万トークンあたりの入力単価は Sol が5.00ドル、Terra が2.50ドル、Luna が1.00ドル。出力単価は順に30.00ドル、15.00ドル、6.00ドルです。上位と下位で5倍の開きがありますが、キャッシュ読み込みやバッチ処理の区分で実効単価は変わります。
Q. ultra は API から指定できますか？
ultra は API の推論効率パラメータではなく、製品側の設定です。API で指定する効率は none / low / medium / high / xhigh / max の6段階です。ultra は既定で複数のエージェントを並列に調整する動作で、利用できるプランも限られます。
Q. GitHub Copilot で Sol が選べないのはなぜですか？
GitHub 公式の変更履歴では、Sol の対象は Pro+ / Max / Business / Enterprise とされており、Pro プランには含まれません。また Business と Enterprise では管理者がポリシーを有効にする必要があり、既定は無効です。プランと管理設定の両方を確認してください。
