【実測】ChatGPT Codexのモデル別使用量比較 ― 同じプロンプトで6倍差が出た

はじめに

AIエージェントを使いまくっているけど、最近ChatGPT（Codex）の使用量の消費スピードが異常に速くなっている気がする。

軽いモデルに入れ替えたらすこしはマシになるかな？

実際に同じプロンプトを複数モデルで実行し、使用量画面の残量を前後で記録するという力技で実測してみた。合わせて、安いモデルで品質に問題が出ないかも確認した。

測定方法

• ChatGPTアプリのアカウントメニュー →「残り使用量」に出る 5時間枠 と 週枠 の残量（%表示）を、実行の直前・直後でスクリーンショットして差分を取る。

• 同一のプロンプトを、新規タスク（会話履歴を持ち越さない状態）として3モデルに順番に投げる。

  • GPT-5.6 Terra（思考量：軽）
  • GPT-6 Astra（思考量：軽）
  • GPT-6 Astra（思考量：極高）※Astraの思考量スライダーは5段階あり、今回はその4段階目

• 表示は整数%なので、差は「概算」であり、1pt未満の差やキャッシュ挙動までは追えていない。

使ったプロンプト（3モデル共通）

/tmp/xxx フォルダを新規作成し、その中で次を行ってください。
(1) 架空の売上CSV（日付・商品名・金額、100行程度）を生成するPythonスクリプトを作成する。
(2) そのCSVを月別・商品別に集計してmatplotlibで棒グラフを1枚PNG出力するPythonスクリプトを作成する。
(3) 両方のスクリプトを実際に実行し、CSVとグラフ画像が正しく生成されることを確認する。
エラーが出たら修正して再実行する。vault内（Obsidianフォルダ以下）のファイルは一切作成・変更しないでください。

単純な一問一答ではなく、「ファイル作成 → 集計ロジック → 可視化 → 実行して検証 → 必要なら自己修正」まで含む、実務でよくある“重め”のタスクにした。

結果

モデル	5時間枠消費	週枠消費	処理時間	変更行数
Terra（軽）	2pt	0pt	1分58秒	+91 -5
Astra（軽）	6pt	1pt	1分14秒	+80 -0
Astra（極高）	12pt	2pt	3分8秒	+128 -0

同じタスクなのに、5時間枠の消費は Terra軽の6倍がAstra極高 という結果になった。週枠も同じ順序（0→1→2pt）で動いている。

消費は「時間」や「行数」に単純比例しない

Astra軽はTerra軽より速く（74秒 vs 118秒）、変更行数も少なかった（+80 vs +91）のに、消費は3倍だった。処理時間や生成量ではなく、モデルそのものの単価（トークン単価・内部の思考量）が消費の主要因になっていると考えられる。「速く終わった＝安かった」わけではない。

以前、単純な計算問題や短い実務分析で同様の比較をしたときは、モデル間の差はほぼ誤差程度（1〜3pt）だった。モデル選択のコスト差は、タスクが重くなるほど大きく効いてくる。

品質に差はあったのか

安いモデルで済ませて、成果物の質が落ちるのでは意味がない。3モデルが実際に生成したコードを読み比べてみた。

結論から言うと、3つとも正しく動くコードを出力しており、致命的な品質差はなかった。 ただし、堅牢さ・丁寧さには段階的な違いが見えた。

Terra軽：シンプルで実用十分、ただし1回だけ手直しが必要だった

pandasを使った素直な実装。型ヒントもあり読みやすい。ただし商品名に日本語（「コーヒー豆」「紅茶セット」など）を使ったため、matplotlibの日本語フォント警告が発生し、Codex自身がそれに気づいて1往復だけ修正・再実行していた。最終的な出力（グラフの日本語表示）は正しく直っている。

# Terra軽が最初に生成したコードの一部（集計スクリプト）
def main() -> None:
    if not CSV_PATH.exists():
        raise FileNotFoundError(f"Run generate_sales_csv.py first: {CSV_PATH}")
    sales = pd.read_csv(CSV_PATH, encoding="utf-8-sig")
    ...

Astra軽：日本語フォント問題を「そもそも踏まない」設計、バリデーションも追加

商品名を最初から英語（Notebook, Pen, Mug...）にすることで、日本語フォント警告そのものを回避していた。CSVの列名チェックや異常値（金額がマイナス、商品名が空など）の検証を自発的に追加しており、一発でエラーなく完走している。

# Astra軽の集計スクリプトより
if reader.fieldnames != ["日付", "商品名", "金額"]:
    raise ValueError("Unexpected CSV columns: ...")
...
if not product or amount < 0:
    raise ValueError("Invalid sales record: ...")

Astra極高：さらに踏み込んだ堅牢性とグラフの仕上がり

データ生成の時点で「6ヶ月×4商品の全組合せに最低1件を割り当てる」よう明示的に設計しており、乱数任せにしていない。エラー処理も行番号付き（CSVの{line_number}行目...）で、実務でデバッグしやすい形になっていた。グラフも独自カラーパレット・不要な枠線の除去・凡例位置の調整など、見た目の仕上げが他の2つより丁寧だった。

# Astra極高の集計スクリプトより（行番号付きのエラーメッセージ）
try:
    ...
except (TypeError, ValueError, AttributeError):
    raise ValueError(f"CSVの{line_number}行目: ...")

まとめると

モデル	正しく動くか	堅牢性（異常系対応）	仕上げ	コスト
Terra軽	○（1回自己修正）	最小限	標準	1x
Astra軽	○（一発完走）	入力検証あり	標準	3x
Astra極高	○（一発完走）	行番号付きエラー等、最も丁寧	配色・体裁まで作り込み	6x

「動くコードが手に入るか」だけならTerra軽で十分。**Astra系が買っているのは、主に“異常系への備え”と“仕上げの丁寧さ”**という印象で、少なくとも今回程度のタスクでは、コストに比例するほどの劇的な品質差ではなかった。

実務での使い分け

• 定型の読取・比較・短い生成作業は、素直にコストの低いモデル（Terra軽）でよい。
• コード作成のような重いタスクでは、モデル選択のコスト差が数倍単位で効いてくるので、「まず軽いモデルで試し、力不足なら上げる」進め方が合理的。
• 高い思考量（Astra極高など）を使うべきなのは、堅牢性や仕上げの質が明確に求められる場面（人に渡す成果物、異常系の考慮が重要な処理など）に絞るのがよさそう。

---

まとめ

同じタスクをモデルだけ変えて回すと、使用量にもアウトプットの質にも、思ったよりはっきり差が出た。「なんとなく重い」を実測に変えると、モデルの使い分け方針が立てやすくなる、という話でした。