GPT-5.6 Luna 80% 値下げ｜80 回の実測で分かった落とし穴

はじめに

2026 年 7 月 30 日、OpenAI が GPT-5.6 Luna の料金を 80%、Terra を 20% 引き下げました。一般提供の開始から約 3 週間という早さでの改定です。

ただし、報じられている内容の大半は API の単価です。ChatGPT の有料プランを使っているものの API は契約していない、という方にとっては、この値下げが自分にどう効くのかが判断しづらい状況です。

もう 1 つ、実務者の間では以前から懐疑的な指摘もありました。低価格モデルは同じ仕事に多くのトークンを消費するため、単価の比較にはあまり意味がないという見方です。

そこで、ChatGPT Plus プランの Codex CLI を使い、同一タスクを 80 回実行して測定しました。

結論を先に述べます。同じタスクを Luna で 20 回実行したところ、全項目を正答したのは 2 回（10%）でした。Terra に上げても 7 回（35%）、推論設定を high にしても 3 回（15%）で、いずれも統計的に有意な改善は得られていません。 一方、プロンプトに読み切りと件数の明示を加えると 18 回（90%）まで改善し、消費トークンの増加は 13% にとどまりました。

つまり、このタスクにおいては、モデルや推論設定を上げるよりプロンプトを直すほうが、はるかに費用対効果が高いという結果です。値下げによってコスト差は広がりましたが、安さを活かせるかどうかは指示の書き方に左右されました。

なお、これは 300 行のログ要約という単一のタスクでの結果です。すべての用途に一般化できるものではありませんが、測定手順は本文に記載しているため、ご自身のワークロードで再現していただけます。

GPT-5.6 の値下げ内容とサブスクへの反映

まず改定の内容と、それが API 以外のどこに波及しているかを整理します。

改定された単価

引き下げ幅は Luna が 80%、Terra が 20% で、Sol は据え置きです。

参考: Advancing the price-performance frontier with GPT-5.6（OpenAI 公式）
“Starting today, GPT-5.6 Luna, our fastest and most affordable model, will cost 80% less”
（本日より、最速かつ最も低価格なモデルである GPT-5.6 Luna は 80% 安くなる）
https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/

上位ティアの価格が変わっていない点は押さえておく必要があります。 恩恵を受けるのは、下位ティアを大量に回すワークロードに限られます。各モデルの性能差やベンチマーク上の位置づけについては、関連記事『GPT-5.6 の 3 モデルの違いと使い分け』で整理しています。

サブスクリプションでは「消費クレジットの減少」として現れます

ChatGPT Work と Codex の使用量は、API のトークン単価に連動したクレジットで計測されています。今回の改定では、サブスクリプションの価格と利用枠は据え置きのまま、Terra と Luna を使ったときの消費クレジットだけが減少しました。

つまりサブスク利用者にとっての値下げは、請求額の減少ではなく「同じ枠でより多く実行できる」という形で現れます。ドル建ての支払いが減るのは API 利用の場合です。

この点は Anthropic 側の考え方とも異なります。プランごとの利用制限の設計については、関連記事『Claude Fable 5 の Pro プラン制限｜日本時間の切り替え時刻と使用クレジットの実際』もあわせてご覧ください。

利用枠の共有範囲を実機で確認しました

ChatGPT の設定画面には、利用量の共有範囲が明記されています。

• 対象: Codex、Work、Workspace Agents、ChatGPT for Excel
• 対象外: Chat の会話

Chat での通常の会話がこの枠を消費しない点は、測定を行ううえで重要でした。 検証中に別タブで調べ物をしても、数値が汚れません。

利用枠のリセットについても実機で確認しています。筆者の環境では、その週に最初に利用した時刻のちょうど 7 日後がリセット時刻として表示されました。曜日固定ではなく、初回利用からのローリング方式である可能性が高いと考えられます。ただし観測が 1 件のみのため、断定はできません。

なお、表示されるリセット時刻はアプリの設定画面が 6:59、アナリティクス画面と CLI が 6:57 と、同一アカウントで 2 分ずれていました。実害はありませんが、突き合わせる際は留意してください。

Fast mode はサブスクでは「使用量の増加」として表現されます

7 月 30 日には Fast mode も導入され、従来の Priority Processing を置き換えました。API では Sol について、標準比 2.5 倍の速度を 2 倍の価格で提供し、知能面の変化はないと説明されています。

一方、Codex CLI の起動時ヒントには次のように表示されます。

Tip: Use /fast to enable our fastest inference with increased plan usage.

API では「2 倍の価格」、サブスクでは「プラン使用量の増加」と、同じ仕組みが経路によって異なる言葉で提示されています。 支払い方法が違う以上は自然な表現ですが、両方を読み比べないと同一の機能だと気づきにくい部分です。

AWS Bedrock はリージョンが限定されます

Bedrock 経由の Luna と Terra にも同率の値下げが反映されました。ただし提供リージョンは US East（バージニア北部・オハイオ）と US West（オレゴン）に限られ、東京リージョンは対象外です。データ所在地の要件がある環境では、現時点で選択肢に入らない点に注意が必要です。

検証環境と測定方法

このセクションでは、実測の手順を再現できる形で記載します。同じ手順をご自身のワークロードに置き換えれば、業務に近い条件での比較ができます。

検証環境

API キーではなく ChatGPT アカウントでサインインしています。サブスクリプションの利用枠で動かすことが今回の前提であるため、この選択が測定条件の一部になります。 サインイン時に API キーを選ぶと従量課金へ切り替わり、測定対象が変わります。

Codex CLI の導入

WSL2 が未導入の場合は、管理者権限の PowerShell から導入します。

wsl --install
wsl

WSL のシェルに入ったら、公式のインストーラーを実行します。

curl -fsSL https://chatgpt.com/codex/install.sh | sh

インストール直後にcodexを実行するとcommand not foundになります。 インストーラーが PATH を~/.bashrcへ追記しますが、実行中のシェルには反映されていないためです。新しいターミナルを開くか、次を実行してください。

source ~/.bashrc

作業ディレクトリは Linux 側のホーム配下に置くことをおすすめします。/mnt/c配下は Windows のマウント経由となり、I/O が遅くパーミッションの扱いも異なります。

mkdir -p ~/work/codex-test
cd ~/work/codex-test

測定に使う表示項目

Codex CLI の初期状態では、トークン数がどこにも表示されません。/statuslineで明示的に追加する必要があります。

今回有効化した項目は次のとおりです。

• model-with-reasoning（モデルと推論設定）
• current-dir
• permissions
• context-used
• weekly-limit（週間利用枠の残り）
• used-tokens（セッションの累計トークン）

有効化すると、フッターが次のような表示になります。

gpt-5.6-terra medium · ~/work/codex-test · Workspace · Context 6% used · weekly 99% left · 16.9K used · 59.5K in

設定画面の利用枠ゲージは 1% 刻みで、単発タスクでは数値が動きません。 実測にはこのトークンカウンターが必要になります。

なお、使用量の詳細は/usageでも確認できますが、引数なしで実行しないことをおすすめします。 メニューが開き、そこには獲得済みの利用枠リセットを消費する選択肢が含まれます。誤って選ぶと有効期限付きのリセット権を失います。トークンの推移を見たい場合は/usage cumulativeのように引数を付けてください。

ただし/usage cumulativeが表示するのは 12 か月分の集計であり、単発タスクの消費は読み取れません。累計値もアカウント全体のもので、CLI 単体の数値ではない点に注意が必要です。

対話モードではなくcodex execを使う理由

当初は対話モード（TUI）で測定していましたが、同じセッションで 2 回目を実行すると、対象ファイルの内容が既にコンテキストへ載っており、ファイル読み込みが発生しません。 1 回目とは条件が変わってしまいます。

そこで非対話モードのcodex execを使いました。呼び出しごとに新しいセッションが立つため、条件の独立性が構造的に担保されます。

参考: Non-interactive mode（Codex 公式ドキュメント）
“Codex streams progress to stderr and prints only the final agent message to stdout”
（Codex は進捗を標準エラー出力へ流し、エージェントの最終メッセージのみを標準出力へ書き出す）
https://developers.openai.com/codex/noninteractive

この仕様により、最終回答だけをファイルへ書き出して採点できます。

1 点、公式ドキュメントの記載と実機の挙動が異なりました。 非対話モードは読み取り専用のサンドボックスが既定と説明されていますが、v0.146.0 で実行したところsandbox: workspace-writeと表示されました。今回は-s read-onlyを明示しています。

測定タスクと条件設計

正解が既知でなければ精度を判定できないため、決定論的に生成できるログを使いました。

cd ~/work/codex-test
for i in $(seq 1 300); do
  case $((i % 50)) in
    0) lvl=ERROR; msg='BGP neighbor 10.0.0.2 transitioned to Idle' ;;
    7) lvl=WARN;  msg='interface ge-0/0/3 CRC error count increasing' ;;
    *) lvl=INFO;  msg='keepalive received' ;;
  esac
  printf '2026-07-31T09:%02d:%02d %s [rpd] %s\n' $((i / 60)) $((i % 60)) "$lvl" "$msg"
done > sample.log

生成されるのは 300 行・15,312 バイトのファイルで、正解は ERROR が 6 件、WARN が 6 件、INFO が 288 件です。

プロンプトは 2 種類を用意しました。引用符の扱いで事故が起きないよう、ファイルに保存して読み込ませます。

cat > prompt_base.txt <<'EOF'
sample.log を読み、記録されている事象を重大度順に 3 点へ要約してください。推測は含めず、ログに現れた事実のみを記載してください。
EOF

cat > prompt_full.txt <<'EOF'
sample.log を最後の行まで読み切ってから、記録されている事象を重大度順に 3 点へ要約してください。各事象の件数を必ず数値で示し、推測は含めず、ログに現れた事実のみを記載してください。
EOF

比較したのは次の 4 条件です。各 20 回、合計 80 回を実行しました。

推論設定は 4 条件すべてで明示しました。 既定値に依存すると、ツールの更新で条件が変わる可能性があるためです。

実行スクリプト

cd ~/work/codex-test
mkdir -p results

run_block() {
  tag="$1"; model="$2"; effort="$3"; pfile="$4"; n="$5"
  mkdir -p "results/$tag"
  for i in $(seq 1 "$n"); do
    idx=$(printf '%02d' "$i")
    echo "[$tag] run $idx  $(date +%H:%M:%S)" >&2
    codex exec -m "$model" -c model_reasoning_effort="$effort" \
      -s read-only --skip-git-repo-check --ephemeral \
      -o "results/$tag/run_$idx.md" "$(cat "$pfile")" \
      > "results/$tag/run_$idx.log" 2>&1
    sleep 3
  done
}

run_block A_terra_medium gpt-5.6-terra medium prompt_base.txt 20
run_block B_luna_medium  gpt-5.6-luna  medium prompt_base.txt 20
run_block C_luna_full    gpt-5.6-luna  medium prompt_full.txt 20
run_block D_luna_high    gpt-5.6-luna  high   prompt_base.txt 20

主なオプションの意味は次のとおりです。

• -m: 使用するモデルを指定
• -c model_reasoning_effort: 推論設定を上書き（minimal / low / medium / high / xhigh）
• -s read-only: 読み取り専用のサンドボックスで実行
• --skip-git-repo-check: Git リポジトリ外での実行を許可
• --ephemeral: セッションファイルをディスクへ残さない
• -o: 最終回答をファイルへ書き出す

--jsonを付けるとイベントを JSONL で受け取れますが、今回は最終回答とログの併用で足りました。

測定条件が成立したことの確認

実行ログのヘッダーにはセッション ID が含まれます。80 件を突き合わせたところ、重複はゼロで、すべて独立したセッションでした。

grep -h 'session id:' results/*/run_*.log | awk '{print $3}' | sort | uniq -d

このコマンドが何も出力しなければ、重複がないことになります。セッション ID の一意性を確認する工程を入れておくと、測定条件が崩れたまま集計してしまう事故を防げます。

また、実行ログの末尾にはtokens usedとしてトークン数が出力されるため、手動記録は不要です。

実測結果｜モデル・推論設定・プロンプトの比較

4 条件を各 20 回、合計 80 回実行しました。判定は ERROR 6 件・WARN 6 件・INFO 288 件の 3 項目すべてを正答したかどうかで行っています。

集計結果

条件 B を基準として、それぞれの差を Fisher の正確確率検定で評価しました。

さらに、条件 C と条件 A の比較でも p = 0.00077 でした。プロンプトを修正した Luna は、Terra へ上げた場合より有意に正確です。

消費トークンはほぼ変わりません

各条件の平均消費トークンです。

B を基準にすると、A は 14%、C は 13%、D は 14% の増加です。3 条件ともほぼ同じだけトークンが増えているにもかかわらず、正答率の改善幅は +25 pt、+80 pt、+5 pt と大きく異なりました。

同じコスト増を払うのであれば、モデルや推論設定ではなくプロンプトに投じるほうが、このタスクでは 3 倍以上の効果がありました。

誤答時のほうがトークンが少ない

すべての条件で、誤答した実行のほうが消費トークンが少なくなっています。安く済んだ実行は、仕事を最後まで終えていなかった実行です。

この関係は、次のセクションで扱う原因と直接つながります。

条件 C の出力例

読み切り指示を加えた場合、多くの実行が処理の完了を明示してから回答しています。

sample.log（全 300 行）を末尾まで確認しました。重大度順の要約です。

1. ERROR：6 件 — BGP neighbor 10.0.0.2 が Idle に遷移。
2. WARN：6 件 — インターフェース ge-0/0/3 の CRC エラー件数が増加。
3. INFO：288 件 — [rpd] keepalive received を記録。

一方、条件 B の典型的な誤答は次の形です。

1. ERROR：BGP ネイバー 10.0.0.2 が Idle 状態へ遷移（09:00:50、09:01:40、09:02:30、09:03:20）。
2. WARN：インターフェース ge-0/0/3 の CRC エラー数増加を検知（計 5 回）。
3. INFO：rpd が keepalive を継続的に受信。

誤りであることを申告せず、断定的な形式で回答している点に注意が必要です。 正解を知らなければ、この出力を疑う手がかりはありません。

なぜ差が出たのか｜入力の打ち切りと追加取得

正答率の差がどこから生まれたのかを特定します。

誤答はすべて同じ位置で途切れています

誤答が言及した「最後の事象」を、ログファイル上の位置に変換しました。

一方、欠落していたのは ERROR 09:04:10（250 行目）以降でした。ファイル全体は 300 行・15,312 バイトです。

誤答はいずれも 240 行目から 250 行目のあいだで入力が途切れています。 ランダムな読み落としであれば欠落位置は散らばるはずですが、そうなっていません。

さらに、対話モードで測定していた段階では、誤答した 9 回の入力トークンがすべて 30.6K で完全に一致していました。入力が決定論的であることを示しており、モデル側のばらつきではなく、渡された入力そのものが途中で切れていたと考えられます。

正答した実行は追加の取得を行っています

実行ログに記録されたツール操作を比較すると、対応関係が明確でした。

つまり、ファイル読み取りが途中で打ち切られた結果を受け取ったあと、「足りない」と判断して追加取得へ進むかどうかが分岐点でした。読解力の差ではなく、不足に気づいて動くかどうかの差です。

Luna は基本プロンプトの場合、この追加取得をほとんど行いませんでした。Terra はより高い割合で行いましたが、それでも 20 回中 13 回は 1 回の読み取りで回答しています。

読み切り指示が効いた理由

条件 C のプロンプトには 2 つの要素を加えました。

• 「最後の行まで読み切ってから」という完了条件の明示
• 「各事象の件数を必ず数値で示し」という出力形式の指定

特に後者が効いたと考えられます。 件数を数値で答えるには全件を数える必要があり、部分的な読み取りでは要求を満たせません。結果として、追加の検索や再読み取りが促されました。

これは、モデルに「もっと頑張れ」と指示したのではなく、途中で止まると回答できない形に要求を設計したという違いです。推論設定を上げても改善しなかったのは、問題が推論の深さではなく作業の完了判定にあったためと整理できます。

前提と限界

この結果は 300 行のログ要約という単一タスクでの測定です。次の点にご留意ください。

• ファイルサイズや形式が変われば、打ち切りの発生条件も変わります
• 打ち切りの挙動は Codex CLI のバージョンに依存する可能性があります
• 対話モードと非対話モードでは、同一モデルでも挙動が異なる場合があります
• 各条件 20 回のため、10% と 15% のような小さい差は判別できません

再現手順は前セクションに記載しているため、ご自身のワークロードでの検証を推奨します。 重要なのは今回の数値そのものではなく、正解が既知のデータを用意して測定する枠組みのほうです。

実効コストの再計算と使い分けの指針

正答率と消費トークンが揃ったので、実効コストを算出します。

比較の前提を揃える

コストは、正答した実行どうしで比較します。 誤答した実行が安いのは当然であり、その数値で比べても意味がないためです。

対象は次の 2 つです。

• Terra medium（基本プロンプト）の正答時: 平均 11,786 トークン
• Luna medium（読み切り指示）の正答時: 平均 10,540 トークン

ここで、Terra と Luna は入力・出力ともに単価がちょうど 10 倍の関係にあります（入力 $2 対 $0.20、出力 $12 対 $1.20）。したがって、入力と出力の比率が両者で大きく変わらなければ、コスト比は「10 × トークン比」で求められます。入出力の内訳が分からなくても比較できる形です。

実効コスト比

今回の値下げにより、正しく完遂した実行どうしの比較で、Terra と Luna のコスト差は約 2.8 倍から約 11.2 倍へ広がりました。

金額の目安も示します。入出力の内訳が取得できないため、全量が入力だった場合と全量が出力だった場合の幅で示します。

同じタスクを 1,000 回実行した場合、上限同士の比較で差額は約 $129 になります。大量処理では、この差が運用コストに直接効いてきます。

実務者の指摘との照合

低価格モデルへの切り替えについては、「安いモデルは同じ仕事により多くのトークンを使うため、単価の比較には意味がない」という指摘が実務者の間で繰り返されてきました。

今回の結果は、この指摘を部分的に裏付け、部分的に修正します。

トークン消費量は問題ではありませんでした。 正答時の消費量は Terra 11,786 に対し Luna 10,540 で、むしろ Luna のほうがわずかに少ない結果です。単価差がそのまま効いています。

問題だったのは、作業を最後まで終えるかどうかでした。 基本プロンプトのままでは、Luna は 20 回中 18 回で途中打ち切りに気づかないまま回答しています。安さの裏側にあったのはトークン効率ではなく、完了判定の甘さでした。

もう 1 つ、「モデルを切り替えるなら評価を回すべき」という指摘も広く見られます。今回はこれが正しいことが確認できました。 正解が既知のデータで測定していなければ、10% と 90% の差には気づけません。切り替えの可否は、公表ベンチマークではなく自身のワークロードでの測定で決めることをおすすめします。

なお、こうした価格競争の背景には、中国製のオープンウェイトモデルによる価格圧力があるという見方もあります。この分野の動向については、関連記事『Kimi K3 のセキュリティリスクと対処』もあわせてご覧ください。

ChatGPT Plus のクォータ消費

80 回の実行前後で、週間利用上限の残りは 98% から 97% へ変化しました。80 回で約 1% です。

ただし表示は 1% 刻みのため、実際の消費は 0% 超から 2% 未満の範囲にあります。この粒度では正確な単位あたりの消費量は算出できませんので、目安としてご理解ください。

言えるのは、この規模のログ要約であれば、Plus のクォータを気にせず検証できるということです。実務で使う大きなコードベースやより長い入力では、消費量は大きく変わります。

使い分けの指針

今回の測定から導かれる方針を整理します。

まとめ

2026 年 7 月 30 日の料金改定により、GPT-5.6 Luna の単価は Terra の 10 分の 1 になりました。ただし低価格モデルをそのまま使うと、今回のログ要約タスクでは 20 回中 18 回が入力を読み切らないまま回答しています。安さを活かせるかどうかは、モデルの選択よりも指示の書き方に左右されるというのが実測から得られた結論です。

• Luna は 80% 減、Terra は 20% 減、Sol は据え置き
• サブスクでは請求額ではなく消費クレジットの減少として反映
• 基本プロンプトでの全項目正答は Luna が 20 回中 2 回
• モデルや推論設定の引き上げでは有意な改善が得られず
• 読み切りと件数明示の指示で正答率は 90% へ改善
• 追加コストは 13% で、他の対策と同水準
• 正答した実行どうしの実効コスト差は約 11.2 倍

以上、最後までお読みいただきありがとうございました。