GPT-5.6 Solの料金｜API費用を抑える使い方2026

入力100万トークンあたり5.00ドル、出力100万トークンあたり30.00ドル。キャッシュ経由の入力なら0.50ドル。この3つの数字の差が、GPT-5.6 Sol を「高いモデル」にするか「安いモデル」にするかを決める。OpenAIが2026年7月9日に一般提供を開始したGPT-5.6ファミリーの最上位モデルは、素の単価だけ見れば決して安くない。ところが課金設計を理解して組めば、同じ処理が10分の1のコストで回る。

ここを読み飛ばしたまま本番に投入して請求額に驚く、というのがいちばんもったいない。この記事はSol単体のAPI費用に絞って、公式ドキュメントと第三者ベンチマークの数字だけで組み立てる。

GPT-5.6 Sol の料金とスペックを数字で押さえる

GPT-5.6 Sol はGPT-5.6ファミリーの最上位モデルだ。OpenAIの発表では、複雑な推論・コーディング・科学領域を担当する位置づけとされている。命名は太陽（Sol）・地球（Terra）・月（Luna）で、そのまま能力と価格の階層を表している。

まず単価を確認する。以下はOpenAI公式のモデルリファレンスに記載された価格（100万トークンあたり、米ドル）。

Sol と Luna の差は入力で5倍、出力でも5倍。並べるとSolは贅沢品に見える。だが実効コストを決めるのは単価ではない。キャッシュがどれだけ効くか、そして同じ仕事を何トークンで終わらせるか。この2つが最終的な請求額を握っていて、単価表はその出発点にすぎない。

コンテキスト長と最大出力

Sol のコンテキストウィンドウは1,050,000トークン。最大出力は128,000トークンまで。105万トークンは日本語換算でおおよそ書籍10冊分に相当する容量で、中規模リポジトリのソースを丸ごと投げても収まる。

ただしこの数字は「入れられる」であって「入れるべき」ではない。105万トークンを毎回フルに使えば、キャッシュなしで1リクエスト5.25ドル。100回叩けば525ドルになる。容量は保険であって常用枠ではない。

推論モードは2段階

Sol には標準（standard）とプロ（pro）の推論モードがある。加えて max reasoning effort と ultra multi-agent モードが新たに入った。pro モードは、速度やコストよりも信頼性が優先される難所向けの設定という位置づけだ。日常のコード補完に pro を使う理由はない。

同じモデルでも設定次第で請求額が数倍動く。主要AI APIの料金比較で他社モデルの課金体系と並べると、この「設定で変わる幅」はOpenAIが特に大きい。

コーディングでSolが選ばれる理由｜ベンチマークの読み方

結論から書く。Sol がコーディング用途で評価されているのは、スコアが高いからではなく、同じスコアに到達するまでのトークンと時間が短いからだ。

Artificial Analysis の検証によると、Coding Agent Index では max reasoning 設定の Sol が80点を記録して首位に立った。2位の Claude Fable 5 との差は2.8点。スコア差だけなら僅差だが、注目すべきは到達コストのほうだ。

知能指数では1点届いていない。それでもコーディングエージェント用途で逆転する。理由は単純で、寄り道が少ないからだ。エージェント運用では出力トークンがそのまま請求額とレイテンシの両方に乗ってくるため、思考の無駄が減ることが二重の節約になって効いてくる。

Terminal-Bench 2.1 と DeepSWE

Sol はコマンドライン作業を測る Terminal-Bench 2.1 と、実在リポジトリでの長期エンジニアリングを測る DeepSWE でも新記録を出している。どちらも「1回の応答の賢さ」ではなく「何十手も続く作業を破綻させずに完走できるか」を見るベンチマークだ。

コーディング・プログラミング系ベンチマークの横断集計では、130モデル中3位、平均78.2点。トップではないが、価格帯を考えれば上出来の位置にいる。

ツール選定の全体像はAIコーディングツール徹底比較2026にまとめてある。モデル単体の性能と、それを載せるツールの使い勝手は別の話だ。

105万トークンのコンテキストは使いどころを間違えると高い

GPT-5.6 の課金でいちばん事故が起きやすいのがここだ。入力が272,000トークンを超えると、そのリクエスト全体が入力2倍・出力1.5倍で再計算される。超過分だけが高くなるのではない。リクエスト丸ごとが割増単価に乗り換わる。

Sol の場合、実際の単価はこう変わる。

27万トークンをわずかに超えるだけでいい。それで支払いは倍近くに跳ねる。Terra は$2.50/$15が$5/$22.50へ、Luna は$1/$6が$2/$9へ。全モデル共通の仕組みだ。

272Kの壁をまたぐ設計は避ける

いちばん質が悪いのは、27万トークン付近を行ったり来たりする実装だ。同じ処理なのに請求額が日によって倍近く揺れ、しかも原因がコード上のどこにも書かれていないので、調査に半日溶ける。リポジトリ全体を投げるRAG。長い会話履歴をそのまま積むチャット。どちらもこの罠を踏みやすい。

対策は単純で、投げる前にトークン数を数えて分岐させる。

import tiktoken

LONG_CONTEXT_THRESHOLD = 272_000

def route_by_context(prompt: str) -> str:
    enc = tiktoken.get_encoding("o200k_base")
    n = len(enc.encode(prompt))
    if n > LONG_CONTEXT_THRESHOLD:
        # 割増単価に入る。要約して縮めるか、分割して複数回に分けるか判断
        raise ValueError(f"{n} tokens: 272Kの壁を超える。要約か分割が必要")
    return "gpt-5.6-sol"

例外を投げるのが乱暴なら、自動で要約パスに落とす手もある。いずれにせよ「気づかないうちにまたいでいた」という状態を潰すのが目的だ。

プロンプトキャッシュでAPI費用を10分の1にする

Sol のキャッシュ読み出しは100万トークンあたり0.50ドル。素の入力5.00ドルに対して90%引きだ。ここを効かせられるかどうかで、実効コストは文字通り一桁変わる。

キャッシュの課金ルールを正確に押さえる

GPT-5.6 世代のキャッシュ課金は3つの数字で決まる。

損益分岐点は暗算できる。書き込みで1.25倍払い、読み出しで0.1倍。2回目の利用で合計1.35、素で2回叩けば2.00。つまり同じプロンプトを30分以内に2回以上使うなら、キャッシュしたほうが必ず安い。1回しか使わないならキャッシュは25%の純損失だ。

明示的なキャッシュブレークポイントを置く

GPT-5.6 からキャッシュの挙動が読みやすくなり、キャッシュブレークポイントを明示的に指定できるようになった。固定部分と可変部分の境目を自分で決められる、という意味だ。

効かせ方の原則はひとつ。変わらないものを前に、変わるものを後ろに置く。

# NG: 日付が先頭にあるとプレフィックスが毎回変わり、キャッシュが一切効かない
messages = [
    {"role": "system", "content": f"今日は{today}。以下の規約に従え。\n{terms_50k_tokens}"},
    {"role": "user", "content": question},
]

# OK: 固定の規約を先頭へ。可変値は後ろのメッセージに逃がす
messages = [
    {"role": "system", "content": terms_50k_tokens},   # ここがキャッシュ対象
    {"role": "user", "content": f"今日は{today}。質問: {question}"},
]

差は1行の位置だけ。それで5万トークンの規約文が毎回0.25ドルか0.025ドルかに分かれる。10倍だ。もったいないと感じるのは、この差に気づかないまま数ヶ月運用してしまうケースで、請求書を見て初めて気づいたときにはすでに数十万円が消えている。

実費用のシミュレーション

社内規約5万トークンを前提に、1日1,000件の問い合わせへ回答するbotを想定する。1件あたり出力は500トークンとする。

月換算では約7,950ドルが約1,209ドルになる。差額は6,700ドル超。日本円にして100万円を超える金額が、プロンプトの並び順とキャッシュ設定という2つの地味な調整だけで浮く計算だ。地味だが効果が大きい。モデルを乗り換える前に、まずここを直したい。

長い固定プロンプトの設計そのものについては、プロンプトの構造化そのものが土台になる。キャッシュは構造がきれいであるほど効く。

この試算は、リクエストが途切れずに届いてキャッシュが温まったままの状態を前提にしている。夜間に数時間アクセスが止まる運用なら、その都度キャッシュ書き込みが再発生する分だけ上振れする。それでも桁は変わらない。

reasoning effort と ultra multi-agent の費用対効果

推論の深さを上げると、出力トークンとは別枠で内部推論トークンが消費される。ここがGPT-5.6の請求額を最も大きく動かす変数だ。ベンチマークで話題になる80点という数字は max 設定のものであり、その設定を本番でそのまま使えばコストは跳ね上がる。

深く考えさせるほど請求額が伸びる

推論設定を最小にした場合と最大にした場合とで、1リクエストあたりのコストが2桁変わるという検証結果が複数の技術ブログで報告されている。内部推論トークンは出力単価で課金されるため、Sol なら100万トークンあたり30ドルが効いてくる。数千トークン考え込むだけで、単純な応答の数十倍になる計算だ。

タスク種別で設定を切り替える実装にしておくと、後から効いてくる。

from openai import OpenAI

client = OpenAI()

EFFORT_BY_TASK = {
    "classify":  "minimal",   # 分類・ラベル付けは考え込む必要がない
    "draft":     "medium",    # 文章生成はほどほどで足りる
    "debug":     "high",      # 原因究明は深さが精度に直結する
}

def ask(task: str, prompt: str):
    return client.responses.create(
        model="gpt-5.6-sol",
        reasoning={"effort": EFFORT_BY_TASK[task]},
        input=prompt,
    )

設定名はSDKのバージョンで変わる。導入前に公式のモデルリファレンスで有効な値を確認しておきたい。

ultra multi-agent モードは切り札に取っておく

Sol には ultra multi-agent モードがある。複数の内部エージェントに並行して検討させる仕組みで、当然トークン消費は跳ね上がる。切り札だ。通常のCI連携やコード補完で常用する理由はない。

エージェント構成そのものの設計指針はAIエージェント完全ガイドにまとめてある。モデル側のモードに頼る前に、アプリ側の分割で解ける問題も多い。

Terra・Lunaへの振り分け設計でさらに削る

Sol を全処理に使う構成は、ほぼ確実に払いすぎになる。GPT-5.6が3階層で出荷されたのは、振り分けて使うことが前提だからだ。

典型的なWebサービスなら、処理をこう割り当てる。

安いモデルの高設定が勝つ帯域がある

ここは見落としがちだ。Luna を高い推論設定で回したほうが、Sol を最高設定で回すよりコスト効率で上回る価格帯が存在する。安いモデルに深く考えさせる。そのほうが、高いモデルに深く考えさせるより安く上がる場面がある。直感に反するが、単価差が5倍もあれば十分に起こりうる話だ。

モデル名で選ばず、タスクごとに「必要な精度に到達する最も安い組み合わせ」を実測で探す。この一手間が効く。

# 段階的エスカレーション: 安いモデルで試し、通らなければ上げる
LADDER = ["gpt-5.6-luna", "gpt-5.6-terra", "gpt-5.6-sol"]

def solve(prompt, validator):
    for model in LADDER:
        result = call(model, prompt)
        if validator(result):      # テスト通過・スキーマ一致などで判定
            return result, model
    raise RuntimeError("全モデルで失敗")

検証関数を用意できるタスク（コード生成、JSON抽出、SQL生成）ならこの構成が強い。Luna で8割が通れば、残り2割だけがSolの料金になる。

Claude Fable 5・Opus 5・Gemini 3.6 Flash との比較

Sol の立ち位置は「最高性能」ではなく「最高性能の一歩手前を、はるかに安く速く」だ。この性格は競合と並べると輪郭がはっきりする。

Artificial Analysis の Intelligence Index では Sol が59点、Claude Fable 5 が60点。1点差でSolが下だ。ところがコーディングエージェント用途では逆転し、コストはおよそ3分の1になる。

各モデルの詳細は個別にまとめてある。Claude Fable 5の料金と性能、Claude Opus 5入門、Gemini 3.6 Flash入門を並べて読むと、価格帯ごとの選択肢が見える。

自分ならどうするか。コーディングエージェントを常時回す用途はSolに寄せる。トークン効率の差がそのまま月額に出るからだ。一方で文章の最終品質が売り物になる仕事は Fable 5 に投げる。1点差の知能指数より、出てくる日本語の質の差のほうが実務では大きい。

最小構成で動かす手順

課金設計の話が長くなったので、実際に叩くところまで戻す。必要なのはAPIキーとPython SDKだけだ。

1. 環境を用意する

pip install openai tiktoken
export OPENAI_API_KEY="sk-..."

2. 最小のリクエストを投げる

from openai import OpenAI

client = OpenAI()

resp = client.responses.create(
    model="gpt-5.6-sol",
    input="このリポジトリのCI設定で最も壊れやすい箇所を1つ挙げて",
)
print(resp.output_text)

3. 使用量を必ず記録する

最初にこれを入れておかないと、あとで請求書とコードの対応が取れなくなる。usage にはキャッシュヒット分と推論トークン分が別々に入るので、両方を残す。

u = resp.usage
print(f"input={u.input_tokens} output={u.output_tokens}")
print(f"cached={getattr(u.input_tokens_details, 'cached_tokens', 0)}")
print(f"reasoning={getattr(u.output_tokens_details, 'reasoning_tokens', 0)}")

キャッシュヒット率が想定より低ければ、プロンプトの並び順を疑う。推論トークンが膨らんでいれば、設定を1段下げて精度が落ちるかを見る。この2つを見張るだけで、月額はかなり違ってくる。

よくある質問

GPT-5.6 Sol は ChatGPT の有料プランでも使えるか

使える。ただし本記事で扱った単価はAPI経由の従量課金の話で、ChatGPTの月額プランとは課金体系が別だ。API費用の最適化という観点で意味を持つのはAPI経由の利用になる。

キャッシュは何分もつのか

最低30分。継続してアクセスがあれば実質的に温まったままになる。夜間に止まる社内システムなら、朝いちばんのリクエストで書き込みが再発生すると考えておけばいい。

Sol と Terra、どちらから始めるべきか

Terra から始めて、精度が足りないタスクだけ Sol に上げる。逆順は高くつく。Solで組んでしまうと「下げても大丈夫か」の検証を後回しにしがちで、そのまま本番に残る。

105万トークンのコンテキストは常用していいのか

よくない。272,000トークンを超えた時点でリクエスト全体が入力2倍・出力1.5倍になる。105万トークンは一度きりの大規模監査のような場面に取っておく枠だと考えたほうがいい。

Luna の記事との違いは何か

GPT-5.6 Lunaの記事は3モデルの位置づけと速度面を扱っている。この記事はSol単体のAPI課金設計に絞っている。両方読むと振り分けの判断がしやすい。

推論設定を最小にすると精度はどれくらい落ちるか

タスク依存としか言えない。分類や抽出のように正解が一意なタスクではほとんど落ちず、原因究明のような多段推論では目に見えて落ちる。自分のタスクで実測するしかない。

まとめ

GPT-5.6 Sol は入力5.00ドル・出力30.00ドルという単価だけ見れば高い部類に入る。だが実効コストを決めるのは単価ではない。キャッシュを効かせれば入力は0.50ドルまで落ち、272Kの壁を踏まなければ割増も回避できる。

やることは3つに絞られる。固定プロンプトを先頭に置いてキャッシュを効かせる。入力トークン数を数えて272Kの手前で止める。推論設定は最小から上げていく。この3つを最初に組み込んでおけば、月額は桁で変わる。

そのうえでモデルを固定しない。分類はLuna、下書きはTerra、難所だけSol。Solを全処理に使う構成は、性能ではなく請求額を最大化するだけの選択だ。コーディングエージェントを常時回すならSolに寄せる価値は確実にある。トークン効率と速度の差が、そのまま毎月の数字に出るからだ。

今日やる作業を1つだけ挙げるなら、既存のAPI呼び出しに print(resp.usage) を差し込むことだ。キャッシュヒット率と推論トークン数が数字で出た瞬間、削るべき場所は自分で見つかる。