GPT-5.6の3階層: Sol・Terra・Lunaのどれを使うか (2026)

3階層、1世代。 GPT-5.6はSol、Terra、Lunaとして提供されます: 同じ1Mコンテキスト、同じ128K出力上限で、価格と性能の曲線上の3つの異なる点です。Solはフラッグシップで100万トークンあたり$5/$30、Terraはちょうど半額 ($2.50/$15) のバランス型ミドル階層、Lunaは$1/$6の安価な働き者です。難しいのは動かすことではありません。難しいのは各用途に正しい階層を選び、使いもしない能力に過剰に支払わないことです。このガイドは両方を扱います: 3つ全部への到達方法と、どのリクエストをどれに処理させるかの決め方です。

30秒でわかるGPT-5.6: できること、できないこと

一文でまとめると: 大量トラフィックのデフォルトをLunaかTerraにし、難しい末端にSolを残し、常に明示的な階層IDを渡し、最大エフォートが必要なときはResponses APIを使う。これ以降はすべて詳細です。

判断の枠組み: この階層化が報われるとき (そうでないとき)

階層化は設定フラグではなく習慣です。トラフィックが本当に混在しているときに報われ、そうでないときは時間の無駄になります。

3階層すべてを運用すべきとき。 ワークロードが能力レベルにまたがるとき、Sol/Terra/Lunaを使い分けます: 同じ製品の中で、安価な分類やルーティングと、難しい複数ファイルのリファクタリングが隣り合うような場合です。月額請求が十分に大きく、大量トラフィックにおける2倍や5倍の価格差が現実の金額になる場合。コスト重視だが、難しい10%のリクエストで能力を落とせない場合。これがルーターの想定用途であり、100万出力トークンあたり$1から$30という価格幅が、引ける手綱に変わる場面です。

わざわざやる必要がないとき。 すべてのリクエストがだいたい同じ難易度なら、1つの階層を選んでそれで終わりです。単一目的の分類器はLunaだけを動かすべきで、他は不要です。難しい推論しかしない研究エージェントはSolを動かし、ルーティングロジックは省くべきです。総支出が1日数ドル未満なら、階層ルーティングを構築するエンジニアリング時間の方が節約額を上回ります。そしてOpenAIの直接APIを使っていて、素の gpt-5.6 エイリアスがSolに解決されることに依存しているなら、実際にTerraやLunaが必要になるまで階層ロジックの追加は何の得にもなりません。

打ち切りルール。 目的が単にフラッグシップを呼ぶことなら、gpt-5.6-sol (ゲートウェイでは openai/gpt-5.6-sol) を使い、次のセクションで読むのをやめてください。以下の階層選択とルーティングの内容は、難易度の異なる少なくとも2種類のリクエストがある場合にのみ役立ちます。

システム要件

特殊なものは不要です。2つのアクセス面のいずれかと、OpenAIプロトコルを話すSDKが必要です。

2列の違いを小さくしたのは意図的です。ゲートウェイ経路は、3つのプロバイダアカウントを別々に持たずに、1つのキーで3つのGPT-5.6階層すべてと、使う他のすべてのモデルに到達できるように存在します。すでにOpenAI SDKを使っているなら、ゲートウェイへの移行はベースURLとモデル文字列の変更だけで、それ以上のことはありません。

3階層を並べて比較

各階層が実際に何を提供するかを、2026年7月13日時点のofoxモデルカタログと照合して検証しました。すべてのレートは100万トークンあたりです。

判断のほとんどを左右する事実が2つあります。第一に、スペックの枠は階層間で同一です: 同じ1Mコンテキスト、同じ128K出力上限。コンテキストとコストをトレードオフすることは決してありません。モジュール全体のプロンプトは、Solにフィットするのとまったく同じようにLunaにもフィットします。選んでいるのはトークンあたりの能力であって、容量ではありません。第二に、価格幅が広いこと。Lunaの出力トークンはSolの5分の1です。エージェントの請求が集中する出力の多い作業では、その比率こそが、品質が許す限りトラフィックを階層の下へ押し下げる根拠のすべてです。

Solの表示価格 ($5/$30) は前世代のフラッグシップGPT-5.5と一致します。Terraは同じワークロードをちょうど半額で再価格設定します。Lunaはさらに一段下に位置します。世代番号は3つとも5.6のままで、価格を動かすのは階層名です。

どの用途にどの階層

きれいな選び方は、タスクが「どれくらい賢いか」という勘ではなく、リクエストの形で選ぶことです。用途を階層にマッピングし、ルーターにそれを強制させます。

ほぼすべてのチームが収束するパターンは2階層構成です: 大量リクエストはLunaかTerraへ、そして小さな難しい末端がSolへエスカレートします。これで、フラッグシップを必要としない90%のトラフィックで価格幅を取り込み、フラッグシップの予算は、数ポイントの合格率が結果を変える場面だけに使います。

同じロジックを、ルーティング関数にそのまま持ち込めるフローチャートにするとこうなります。

flowchart TD
    A[Incoming request] --> B{Bounded output?<br/>classify / route / extract}
    B -->|Yes| L[openai/gpt-5.6-luna]
    B -->|No| C{Everyday coding<br/>or agentic work?}
    C -->|Yes| D{Latency or cost<br/>the priority?}
    D -->|Yes| T[openai/gpt-5.6-terra]
    D -->|No, hardest tasks| S[openai/gpt-5.6-sol]
    C -->|No, hardest reasoning| S
    S --> U{Needs max effort or<br/>Ultra heavy compute?}
    U -->|Yes| R[Sol via Responses API]
    U -->|No| S2[Sol via chat/completions]

階層選択がタスクあたりでいくらかかるか

階層差は、タスクの形を当てはめるまでは抽象的です。単一の多ターンエージェントタスクを取ります: 入力50Kトークン (リポジトリコンテキスト、ツール結果、数ターン分) と出力15K (編集、説明、リトライ)。同じタスク、3階層、上の表のofoxレートを使用します。

1日1,000タスクでは、すべてをSolで動かす場合とすべてをLunaで動かす場合の差は、月あたり約$16,800です。すべてをLunaで動かすべき人などいません。それらのタスクの多くはLunaが与える以上のものを必要とするからです。しかしこの数字は、なぜ階層化がルーティングコードに見合うのかを説明します: そのトラフィックの3分の1でもLunaに十分な範囲で、別の3分の1がTerraの基準を満たすなら、難しい末端に手を付けずに、混合請求は全Sol線をはるかに下回る位置に着地します。

この計算について押さえておくべきことが2つあります。第一に、出力が高価な半分です。Solの出力トークンはLunaの5倍で、入力トークンも5倍ですが、入力は通常より大きい生カウントなので、出力の少ないタスクでは階層が圧縮され、出力の多いタスクでは広がります。出力の多い生成 (テストの足場、コードモッド、長い説明) をまず階層の下へルーティングしてください。そこが階層差の噛みつきが最も強い場所だからです。第二に、キャッシュは順位を変えません。各階層のキャッシュ入力レートはそれ自身のキャッシュなし入力レートのちょうど10分の1 (Lunaで$0.10対$1、Terraで$0.25対$2.50、Solで$0.50対$5) なので、キャッシュはすべての階層の入力請求を同じ割合で下げ、どのヒット率でもLunaがTerraより安く、TerraがSolより安いままです。絶対的な節約のためにキャッシュを有効にし、それでどの階層を選ぶかを変えないでください。

ステップバイステップ: 3階層すべてを1キーで動かす

これはofoxの経路です。1つのキーで3階層すべてに到達することが要点だからです。OpenAI直接の経路は、ベースURLと openai/ プレフィックスを外す以外は同一です。

ステップ1: キーとベースURLを設定

export OFOX_API_KEY="sk-..."      # from app.ofox.ai
export OFOX_BASE_URL="https://api.ofox.ai/v1"

想定される結果: 2つの環境変数が設定される。まだネットワーク呼び出しはなし。

ステップ2: 各階層を1回ずつ呼び出してアクセスを確認

from openai import OpenAI
import os

client = OpenAI(base_url=os.environ["OFOX_BASE_URL"], api_key=os.environ["OFOX_API_KEY"])

for tier in ["openai/gpt-5.6-luna", "openai/gpt-5.6-terra", "openai/gpt-5.6-sol"]:
    r = client.chat.completions.create(
        model=tier,
        messages=[{"role": "user", "content": "Reply with your tier name only."}],
    )
    print(tier, "->", r.choices[0].message.content.strip())

想定される結果: 階層ごとに1行、計3行。いずれかの行がnot-foundエラーを出す場合、まずモデル文字列のスペルを確認し、次にキーにGPT-5.6アクセスがあることを確認してください。

ステップ3: 階層ルーターを構築

1つの関数がリクエストタイプをモデル文字列に変換します。これが階層化システムのすべてです。

def pick_tier(job: str) -> str:
    if job in {"classify", "route", "extract", "autocomplete"}:
        return "openai/gpt-5.6-luna"
    if job in {"code", "review", "refactor", "docgen"}:
        return "openai/gpt-5.6-terra"
    return "openai/gpt-5.6-sol"   # hard reasoning / agentic tail

resp = client.chat.completions.create(
    model=pick_tier(job_type),
    messages=messages,
)

想定される結果: 各リクエストが、品質基準を満たす最も安価な階層に着地する。請求書のモデル列に各リクエストのコストが正確に表示され、pick_tier は構成比を調整する唯一の場所になります。

ステップ4: Node、同じ形

スタックがJavaScriptなら、ルーターは形が同一です。

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: process.env.OFOX_BASE_URL,
  apiKey: process.env.OFOX_API_KEY,
});

const pickTier = (job) => {
  if (["classify", "route", "extract"].includes(job)) return "openai/gpt-5.6-luna";
  if (["code", "review", "refactor"].includes(job)) return "openai/gpt-5.6-terra";
  return "openai/gpt-5.6-sol";
};

const resp = await client.chat.completions.create({
  model: pickTier(jobType),
  messages,
});

ステップ5: 最大エフォートとSol Ultraに到達 (Responses API)

max 推論エフォートとSolの高負荷計算Pro/Ultraモードは /v1/chat/completions では動作しません。Responses APIが必要です。Solは none、low、medium、high、xhigh、max にわたる推論エフォートをサポートします。その範囲の頂点とサブエージェントのUltraモードが、フラッグシップがその価格に見合う場所です。

resp = client.responses.create(
    model="openai/gpt-5.6-sol",
    input="Trace this deadlock across the four files below and propose a fix.",
    reasoning={"effort": "high"},   # max also valid here; not on chat/completions
)
print(resp.output_text)

想定される結果: 推論の重い回答。同じ呼び出しを chat.completions に対して高エフォート設定と関数ツール付きで試すと、代わりに次のセクションの400が返ってきます。

GPT-5.6実行時のよくあるエラー (と修正)

not-foundとアクセス失敗の完全な手順 (モデルリストの確認とVPNのリージョンブロックのケースを含む) は、GPT-5.6 model-not-available エラーの修正を参照してください。短い版は表にあり、長い版には診断の順序があります。

ベンチマークが各階層について実際に言っていること (と言っていないこと)

階層は価格と自分自身の評価で選び、ローンチの見出しでは選ばないでください。見出しの数字はすべての階層をカバーしていないからです。ここに、誰が何を採点したかを正確に分けた、正直な帰属を示します。

実用的な読み方: Solには実在する公開数値があります。TerraとLunaには価格引き下げと、Claude Fable 5に対する1つの曖昧な相対主張があるだけで、それ以上はありません。だからマーケティングがGPT-5.6はTerminal-Benchで91.9%を達成したと言うとき、それはUltraモードのSolであって、日常のコーディングをルーティングする階層ではありません。計画にSolのベンチマークをTerraへ持ち越さないでください。コスト削減のためにワークロードをSolからTerraへ下げるなら、まず自分のログで20から30タスクのA/Bを実行してください。Terraは安いので評価も安く、それがOpenAIのではなくあなたのトラフィックを記述する唯一の数字です。Terra対GPT-5.5のコスト内訳では、そのA/B計算とベンチマークの帰属をより深く掘り下げています。

チームおよび複数開発者向けの構成

階層選択は、チームで共有すると価値が上がるのであって、下がるのではありません。チームでの失敗モードは、各開発者が異なるモデル文字列をハードコードすることで、トラフィックの半分がLunaで十分こなせるタスクに対してこっそりフラッグシップを動かしてしまうことです。

階層マップを一元化しましょう。pick_tier (またはそのNode版) を共有の内部パッケージに置き、アプリケーションコードでの生のモデル文字列を禁止します。これで、評価や予算が変わったときにLuna/Terra/Solの境界を移せる場所が1つになり、コストの帰属が読みやすくなります。請求書のモデル列が、100個の個別推測ではなくポリシーを反映するようになるからです。

1つのキー面を共有しましょう。3階層すべてを単一の https://api.ofox.ai/v1 キー経由で動かすと、請求項目が1つ、アクセス付与が1つ、開発者ごとのOpenAI組織のやりくりが不要になります。新しいエンジニアは同じ3つのモデルIDと同じルーターを受け取ります。あとで別のベンダーから4つ目のモデルを追加するとき、それは新しい統合ではなく同じキーと同じルーティング関数に加わります。カタログ全体を1つのエンドポイントの背後にルーティングする一般的なパターンはマルチモデルルーターガイドを、同じキーをコーディングCLIに配線する方法はCodex CLIカスタムプロバイダ構成を参照してください。

フラッグシップに上限を設けましょう。Sol支出が懸念なら、エスカレーションパスだけが到達できるようルーターの背後にゲートし、すべてのSol呼び出しをその用途タイプとともにログします。ほとんどのチームは、A/BでTerraが問題なくこなしたSolトラフィックの塊を発見し、ルーターはそれを移す場所になります。

代替手段: GPT-5.6 (とその先) に到達する他の方法

ofoxゲートウェイ。 1つの https://api.ofox.ai/v1 キーで、OpenAI互換プロトコル上で3階層すべて (openai/gpt-5.6-sol、openai/gpt-5.6-terra、openai/gpt-5.6-luna) を他のモデルと並べて従量課金で動かし、階層ルーターがリクエストごとのコストを決めます。これはこのガイドが中心に据えた構成で、階層をコミットする前にA/Bする最も摩擦の少ない方法です。価格はライブコンソールに追従します。

OpenAI直接。 platform.openai.com は同じ3階層を素のID (gpt-5.6-sol など) で提供し、max エフォートとSolのPro/UltraモードにResponses APIを備えます。すでにOpenAIの組織ツールに深く入り込んでいて、同じキー上に2つ目のベンダーを必要としないなら、これを選んでください。トレードオフは、アクセスが面ごと・組織ごとにスコープされることで、間違った組織のキーは、同じ人物がChatGPTでモデルを使えても404になります。

GitHub Copilotと他の面。 GPT-5.6はGA時点でCopilotでも稼働開始しました。エディタ内のインタラクティブなコーディングには問題ありませんが、プログラム的なトラフィックをルーティングするAPIではないので、アプリ構築のためのゲートウェイや直接経路を置き換えるものではありません。

他の選択肢についての正直な注記: OpenAI直接はモデルの真実の情報源であり、エイリアスの挙動とResponses APIの機能が保証される唯一の場所です。ゲートウェイの利点は、階層とベンダーをまたぐ単一キーと、ドロップインのコストA/Bです。1ベンダーのシンプルさを重視するか、マルチモデルのルーティングを重視するかで選んでください。

FAQ

上のフロントマターのFAQブロックは、GPT-5.6の階層選択のPeople Also Askで最も多く現れる8つの質問に答えています: 3つの階層とは何か、それらの動かし方、どれを選ぶか、gpt-5.6 は gpt-5.6-sol と等しいか、Ultraモードとは何か、トークンあたりのコスト、400推論エフォートエラー、コード変更なしでの階層切り替えです。

この更新のために確認した出典

• OpenAI GPT-5.6 Sol model reference
• OpenAI API pricing
• OpenAI reasoning guide (effort levels, Responses API)
• Simon Willison: the new GPT-5.6 family (Luna, Terra, Sol)
• OpenAI community: GPT-5.6 chat-completion reasoning-effort behavior
• ofox model catalog: GPT-5.6 Sol
• ofox model catalog: GPT-5.6 Terra
• ofox model catalog: GPT-5.6 Luna