GPT-5.6 Sol、Terra、Lunaを用途で選ぶ
GPT-5.6のモデルを選ぶとき、最高価格のモデルをすべての処理へ割り当てる必要はありません。
最初に、公式モデルページからmodel ID、料金、コンテキスト長、最大出力、reasoning effortを確認します。
その上で、失敗コストの高い課題だけを上位モデルへ上げ、検証可能な定型処理を下位モデルへ移します。
以下の数値は2026年8月に公式ページで確認した値です。
モデル、alias、料金は変わり得るため、実装時には公式モデル一覧とモデル比較を再確認します。
公式ページの数値を表にする
| 項目 | Sol | Terra | Luna |
|---|---|---|---|
| API model ID | gpt-5.6-sol |
gpt-5.6-terra |
gpt-5.6-luna |
| input / 1M tokens | $5.00 | $2.00 | $0.20 |
| cached input / 1M tokens | $0.50 | $0.20 | $0.02 |
| output / 1M tokens | $30.00 | $12.00 | $1.20 |
| context window | 1,050,000 | 1,050,000 | 1,050,000 |
| maximum output | 128,000 | 128,000 | 128,000 |
| knowledge cutoff | 2026-02-16 | 2026-02-16 | 2026-02-16 |
3モデルは同じGPT-5.6ファミリーに属するが、料金と想定する利用量が異なります。
モデルページではreasoning effortとしてnone、low、medium、high、xhigh、maxが案内されています。
推論強度はモデルの選択とは別の軸です。
gpt-5.6というaliasの向き先と各モデルの位置づけは、実装時に最新モデルガイドでも確認します。
Solへ上げる課題
Solを候補にするのは、モデル単価だけでなく失敗時の損失が大きい課題です。
- 複数領域の制約が絡む設計
- 長い調査結果を統合する判断
- 失敗時のレビューコストが高い変更
- Terraで代表課題の成功率が足りない処理
Solを選んでも、reasoning effortを常にmaxにする必要はありません。
まずTerraとSolで同じeffortを使い、モデル差を測ります。
その後、Solのeffortだけを変えて増分を確認します。
Terraを基準にする課題
Terraは、新しいワークロードの基準として試しやすいです。
- 日常的な実装とコードレビュー
- 既存コードベースの理解
- 中程度のリファクタリング
- 品質と費用の釣り合いを取りたい処理
Terraで明確に失敗した課題だけをSolへ昇格します。
逆に、出力の品質が過剰で検証も容易な処理はLunaへ下げます。
この昇格と降格の条件を先に決めると、モデル選択が好みだけで決まりにくいです。
Lunaへ下げる条件
Lunaを選ぶ条件は、課題が簡単そうに見えることではありません。
出力の誤りをテスト、schema、ルール、再試行で検出できることです。
- 分類、抽出、整形
- 小さく明確な修正
- 大量ログの一次要約
- 失敗を自動検出できるsubagent処理
- 再実行しても副作用を増やさない処理
誤りを検出できない高リスク判断では、単価だけでLunaを選びません。
料金の概算を再計算する
1回の処理が100万input tokensと10万output tokensを使うと仮定します。
cache、tool料金、長文料金を除く概算は次です。
| モデル | input | output | 合計 |
|---|---|---|---|
| Sol | $5.00 | $3.00 | $8.00 |
| Terra | $2.00 | $1.20 | $3.20 |
| Luna | $0.20 | $0.12 | $0.32 |
APIの使用量には、通常のinput、cached input、outputなどを分けて記録する場合があります。
実際の請求では、レスポンスのusage項目と公式料金表の単位を対応させてから合計します。
1リクエストのinputが272Kを超える場合は、公式モデルページの長文料金も確認します。
この条件では、リクエスト全体へinput 2倍とoutput 1.5倍の料金が適用されます。
毎回巨大なコンテキストを送る設計では、モデルを下げる前に情報の分割、キャッシュ、不要な履歴の除去を検討します。
推論強度を含む比較手順
比較では、prompt、tools、timeout、入力資料を固定します。
次にモデルを固定し、reasoning effortだけを変えます。
自分の代表課題を3〜5回ずつ実行し、次を記録します。
- 成功率
- 人による修正回数
- 入力と出力のtoken数
- 待ち時間
- 料金
- 自動検証で検出できた失敗
選定の目的は、最高モデルを決めることではありません。
課題ごとの失敗コストに対して、必要な成功率を最小の費用で満たす組み合わせを見つけることです。