Codex の利用枠の考え方：5時間制限、週次制限、Credit 消費

Codex の利用枠を見ると、最初は 5時間制限 が短期の残高で、それを使い切ってから 週次制限 が減り始めるように見えます。

しかし実際は違います。Codex は複数の制限ウィンドウを同時に確認している、と考える方が自然です。短いウィンドウは短時間の大量利用を防ぎ、週次ウィンドウは一週間の総量を制御します。1 回の Codex 利用は通常、その両方に反映されます。

そのため、次のような状態は一般的には正常です。

1
2


5時間枠はまだ多く残っている
しかし weekly 枠はすでに減っている

01 まず結論

Codex の利用枠は、まず次の 3 点で理解できます。

5時間制限 と 週次制限 は同時に有効であり、順番に消費されるものではありません。
週次制限を使い切ると、5時間枠が残っていても同じサブスクリプション枠では通常続けて使えません。
Codex は単純なメッセージ数ではなく、モデル、tokens、タスクの複雑さ、コンテキスト、実行場所に影響されます。

疑似コードで書くとこうです。

1
2
3
4


can_use_codex =
    five_hour_remaining > 0
    && weekly_remaining > 0
    && 他の製品ポリシー制限に触れていない

5時間ウィンドウがリセットされても、戻るのは 5時間枠だけです。weekly 枠は戻りません。weekly は自分の reset を待つか、対応プランで追加 credits を購入する必要があります。

02 なぜ両方のウィンドウが減るのか

Codex の利用枠は 2 つのゲートとして考えるとわかりやすいです。

ウィンドウ	役割
5時間ウィンドウ	短時間の高頻度利用を防ぐ
週次ウィンドウ	一週間の総使用量を制御する

Codex タスクごとに実際の消費が発生し、その消費が関連する rate limit ウィンドウに反映されます。

つまり、こうではありません。

1
2
3


先に 5時間枠を使う
5時間枠を使い切ったら
週次枠を使う

より近いのはこうです。

1
2
3


1 回の Codex リクエスト
=> 5時間ウィンドウに計上
=> 同時に週次ウィンドウにも計上

これが「5時間枠が残っているのに weekly も減る」理由です。

03 今は token-based credits を見る

OpenAI は、ユーザーが完全に再計算できる Codex の課金式を公開していません。公開されているのは rate card、影響要因、モデル別の credit 単価です。

2026-04-15 時点では、Codex rate card の主な考え方は token-based credits です。入力 tokens、キャッシュ入力 tokens、出力 tokens から credits に換算されます。

公式の価格例は次の通りです。

モデル	入力 / 1M tokens	キャッシュ入力 / 1M tokens	出力 / 1M tokens
GPT-5.4	62.50 credits	6.250 credits	375 credits
GPT-5.4-Mini	18.75 credits	1.875 credits	113 credits
GPT-5.3-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.2-Codex	43.75 credits	4.375 credits	350 credits
GPT-5.1-Codex-Max	31.25 credits	3.125 credits	250 credits
GPT-5.1-Codex-mini	6.25 credits	0.625 credits	50 credits

ざっくりした見積もりは次のようになります。

1
2
3
4


今回の消費
≈ 入力 tokens / 1,000,000 × モデルの入力単価
+ キャッシュ入力 tokens / 1,000,000 × モデルのキャッシュ入力単価
+ 出力 tokens / 1,000,000 × モデルの出力単価

これは正確な請求式ではありませんが、傾向の説明には十分です。出力は高く、長いコンテキストも高く、高性能モデルほど高くなります。公式 rate card では、Fast mode は 2 倍の credits を消費し、Code review は GPT-5.3-Codex の価格を使うとも説明されています。

04 メッセージ数だけで見ない

同じ 10 回の Codex メッセージでも、消費量は大きく変わります。

軽いタスクは通常少なめです。

小さな関数を修正する
短いコードを説明する
短い文章を書く
明確なファイル内で局所的に変更する

重いタスクは高くなります。

大きなコードベースをスキャンする
長時間 agent を動かす
読み取り、編集、テスト、修正を何度も繰り返す
大量のコードや長いレポートを生成する
cloud task を使う
fast mode を有効にする

そのため、メッセージ数 はかなり粗い目安にすぎません。実際の消費量を判断するには不十分です。

05 local task と cloud task の違い

消費量の差が出やすいのは実行場所です。

local task は、ローカルのワークスペースでファイルを読み、コードを編集し、コマンドを実行するものです。cloud task は、タスクをクラウド環境に任せて実行するもので、長く自動化された処理に向いています。

cloud task は多くの場合、より高くなります。理由は単純です。

クラウド実行環境が必要
タスクが長くなりやすい
ツール呼び出しが多い
コンテキストが大きい
自動化の流れがより完全

通常のコード編集、記事整理、小さな修正なら local task の方が節約しやすいです。cloud task は本当にクラウド実行が必要なときに使うのがよいです。

06 weekly が早く減る理由

5時間枠はあまり減っていないのに weekly が大きく減る場合、よくある理由は次の通りです。

cloud task を使った。
高いモデルを使った。
fast mode を有効にした。
コンテキストが大きく、多くのファイルや長い会話を扱った。
出力が長かった。大量のコード、長いレポート、ログ分析など。
タスクチェーンが長かった。検索、編集、テスト、修正、再テストなど。
自作の利用枠スクリプトがウィンドウ名を誤って解釈した。

/backend-api/wham/usage のようなフィールドをスクリプトで読んでいる場合、加工後の five_hour% や weekly% だけを信用しない方が安全です。raw JSON で次の値を確認します。

limit_window_seconds
percent_left
reset_at
bucket / feature 名

典型的なウィンドウは次のように判断できます。

1
2
3
4
5


limit_window_seconds = 18000
=> 約 5 時間

limit_window_seconds = 604800
=> 約 7 日

スクリプトが 2 つのウィンドウを逆にラベル付けしていると、利用枠表示は誤解を招きます。

07 利用枠を節約する使い方

weekly を長持ちさせるには、次のように使います。

大きなタスクを小さく分ける。
可能なら local task を優先する。
関連パスを明確に伝え、不要なスキャンを減らす。
巨大なログ、長いファイル、無関係なコンテキストを一度に入れない。
軽い作業には安い mini モデルを使う。
長い作業の前に、まず計画を出してもらう。
長いレポートが不要なら、簡潔に答えるよう指定する。

覚えやすいモデルはこれです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


続けて使えるか
= 短いウィンドウに残量がある
&& 週次ウィンドウに残量がある

消費の速さ
= モデル価格
× tokens
× 出力の長さ
× タスクの複雑さ
× 実行場所

これは正確な請求計算ではありませんが、ほとんどの Codex 利用枠の挙動を説明できます。