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

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

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

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

1
2

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

01 まず結論

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

1. 5時間制限 と 週次制限 は同時に有効であり、順番に消費されるものではありません。
2. 週次制限を使い切ると、5時間枠が残っていても同じサブスクリプション枠では通常続けて使えません。
3. 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 つのゲートとして考えるとわかりやすいです。

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 に換算されます。

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

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

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 が大きく減る場合、よくある理由は次の通りです。

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

/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 を長持ちさせるには、次のように使います。

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

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

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

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

08 auth.json で利用枠ウィンドウをローカル確認する

UI に割合しか表示されず、ウィンドウの長さやリセット時刻を確認したい場合は、ローカルの ~/.codex/auth.json を読み、ChatGPT が現在使用している利用枠エンドポイントへ問い合わせられます。これは非公開の内部エンドポイントであり、安定した API ではありません。パス、フィールド、アクセス条件は変更される可能性があるため、本番処理には組み込まないでください。

実行前の注意点：

• 自分のコンピューターだけで実行し、auth.json をアップロード、貼り付け、共有しないでください。
• スクリプトは token を表示しませんが、ターミナルログ、デバッグプロキシ、例外レポートから認証情報が漏れる可能性があります。
• HTTP 401 は通常 access token の期限切れ、403 はアカウントまたはエンドポイントへの権限不足です。403 だけでアカウント停止とは判断できません。
• フィールドが変わった場合は raw JSON を保存し、limit_window_seconds、percent_left、reset_at からウィンドウを判断します。

依存パッケージをインストールします：

1

python -m pip install requests

次の内容を codex_usage.py として保存します：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

import json
from pathlib import Path

import requests


auth_path = Path.home() / ".codex" / "auth.json"
auth = json.loads(auth_path.read_text(encoding="utf-8"))
tokens = auth.get("tokens", auth)
access_token = tokens.get("access_token")
account_id = tokens.get("account_id")

if not access_token or not account_id:
    raise SystemExit("auth.json に access_token または account_id がありません")

response = requests.get(
    "https://chatgpt.com/backend-api/wham/usage",
    headers={
        "Authorization": f"Bearer {access_token}",
        "ChatGPT-Account-Id": account_id,
        "Accept": "application/json",
        "Origin": "https://chatgpt.com",
        "Referer": "https://chatgpt.com/",
    },
    timeout=30,
)

if response.status_code in (401, 403):
    raise SystemExit(
        f"HTTP {response.status_code}: 認証情報の期限切れ、またはアクセス権がありません"
    )

response.raise_for_status()
data = response.json()
print(json.dumps(data.get("rate_limit", data), ensure_ascii=False, indent=2))

実行します：

1

python codex_usage.py

HTTP 200 が返るだけでは検証完了ではありません。出力にウィンドウ長、残り割合、リセット時刻があり、Codex UI とおおむね一致することを確認します。フィールドがない場合はラベルを推測しないでください。内部エンドポイントを利用できない場合は、製品 UI と OpenAI の公式説明を優先します。

関連リンク

• Using Codex with your ChatGPT plan - OpenAI Help Center
• ChatGPT Rate Card - OpenAI Help Center
• Codex rate card - OpenAI Help Center
• Using Credits for Flexible Usage in ChatGPT - OpenAI Help Center

2026年8月時点の上限とリセットの読み方

OpenAI が示すのは利用回数の目安であり、すべてのアカウントで固定されたメッセージ数ではありません。local messages と cloud chats は5時間枠を共有し、追加の週次上限が適用される場合があります。モデル、コンテキスト、推論、ツール、検索、キャッシュによって消費量は変わります。

調査では、モデル、local/cloud、表示された reset 時刻、実行前後の残量を記録します。アカウントや時間帯で結果が違うだけでは、計算エラーの証拠になりません。

キャンペーンのリセット、紹介特典、障害補償は一時的で、恒久的なプラン条件ではありません。資格と期限は製品画面で確認してください。credits の購入も、すべてのサブスクリプション枠を恒久的に拡大するものではありません。

Fast mode は対応モデルを高速化する一方、credits も速く消費します。1メッセージではなく、成功した1タスクあたりの総費用で比較してください。