「週次の利用枠」と聞くと、なんとなく一週間じわじわ使える気がする。
ところが高負荷なAIエージェントでは、そうとは限らない。数時間しっかり動かしただけで週枠が大きく減り、画面には次のリセットまで何日も残っている。体感はほぼ、遊園地の週パスを買ったのに2時間遊んだところで『今週はここまでです。また来週』と言われる状態だ。
結論から言うと、Astraを含むWork/Codexの利用枠は「何時間アプリを開いたか」ではなく、モデル、タスク、入力と出力の大きさ、推論設定、多段処理などで消費が変わる。 しかも5時間枠と週枠の両方があり、両方に残量が必要だ。
ただし、短時間で大きく減ったからといって全部を「仕様」で片づけるのも危ない。2026年9月には、Pro 20xで残量が異常に急減したという複数のユーザー報告があり、後から残量が補正された例もある。 つまり、本当に重い処理だった場合と、表示・計上異常の可能性は分けて考える必要がある。
1. 「2時間しか使っていない」は、AI側では軽いとは限らない
OpenAIは、WorkとCodexの利用量について、同じタスクでもモデルによって消費量が違い、さらに大きな入力、大きな出力、高い推論設定、Fast mode、多段の仕事で消費が増えうると説明している。
つまり人間の時計で2時間でも、その間に巨大なリポジトリを読み、検索し、複数ファイルを直し、テストし、失敗ログを読み、また修正していれば、計算側ではかなりの仕事量になる。
Codex Pricingの現行目安では、5時間あたりのローカルメッセージ数はPro 5xでAstraが25〜225、Solが50〜500、Terraが125〜1,000、Lunaが1,250〜10,000。Pro 20xでは順に100〜900、200〜2,000、500〜4,000、5,000〜40,000だ。 これは固定回数ではなく目安で、週次制限も別に適用される。
この差を見ると、「推論を少し軽くする」だけでなく、そもそもどのモデルへ仕事を渡すかが大きなレバーなのが分かる。
Astraくん、頭はいい。だが燃費も高級車である。
2. 5時間枠と週枠が重なると、「週パスなのに即閉園」が起きる
WorkとCodexには、プランによって5時間単位の枠と週次枠がある。5時間枠は、前の窓が終わったあと最初のリクエストを送った時点から新しい窓が始まる。一方、週枠はその週全体の利用量を制御する。
重要なのは、5時間経つまで使える保証ではないことだ。OpenAI自身、「5時間が経過する前に5時間枠へ到達することがある」と説明している。
同じことが週枠の体感にも効く。高負荷作業を短時間へ詰め込めば、経過時間は短くても週枠が大きく減る。
ここでUX上の違和感が出る。
週100%という数字は「7日分の燃料」に見える。でも実際には「7日間の中で使える総計算量」に近い。だから月曜に全力疾走すると、火曜から日曜まで「次のリセットをお待ちください」が発生しうる。
利用者側からすると、せめて毎日少し戻る方式やローリング回復のほうが自然に感じる。これは現行仕様ではなく、週次一括型に対するUX上の評価だ。
3. Pro 20xの新規受付停止は本当。ただし「廃止」ではない
2026年9月10日、OpenAIは月額200ドルのChatGPT Pro 20xについて、新規契約と既存の下位プランからのアップグレードを一時停止した。
既存のPro 20x契約者は影響を受けず、継続更新できる。Pro 100ドルは引き続き新規契約できる。 つまり「20xプラン終了」ではなく、新規受付の一時停止だ。
公式FAQそのものは停止理由を詳述していない。一方TechCrunchは、OpenAIのプロダクト責任者Thibault Sottiaux氏の投稿を引用し、Pro 20x利用者がシステムへ最も大きな負荷をかけるため、新規受付を止めることにしたと報じた。またAstra需要を「前例がない」規模と説明したとしている。
なので、ここは二段に分けるのが正確だ。
- 公式に確認できる事実：Pro 20xの新規契約・アップグレードは2026年9月10日から一時停止。
- 停止理由についての報道：Astra需要とシステム容量への負荷が背景だと、OpenAI幹部の発言を引用して報じられている。
GPUが物理的に火を吹いているわけではない。たぶん。でも「高負荷プランをこれ以上増やさない」という判断自体は、計算資源が無限ではないことをかなり分かりやすく示している。
4. ただし、異常な減り方まで「Astraは重いから」で済ませない
2026年9月9〜10日のOpenAI Developer Communityでは、「Pro 20xの週枠85%が2時間半で減った」「Astra Lightでも短時間で20%減った」など、急激な消費について複数の報告が出た。
ここで面白いのは、85%消費を報告したユーザーが、その後「残量が81%まで戻った」と追記していることだ。
つまり少なくとも一部では、表示や計上の補正が起きた可能性がある。
また9月10日には、ChatGPT Workで一部ユーザーにサーバーエラーが出る障害もOpenAI Statusで記録された。 これは利用枠の計上異常と同一原因だと確認されたわけではないので、直接結びつけてはいけない。
実務上はこう考えるといい。
なだらかに減る → 重いタスクの可能性が高い。
突然ワープするように減る → 使用履歴、モデル、Fast mode、残量表示を保存して、計上異常も候補に入れる。
「高性能モデルだから仕方ない」でメーターの瞬間移動まで神格化する必要はない。
5. Lightにしても劇的に伸びないことがあるのはなぜか
OpenAIは、低い推論設定は利用枠を長持ちさせる出発点になりうる一方、推論レベルがタスクごとの固定消費量を決めるわけではなく、高くすれば必ず良い結果になるわけでもないと説明している。
ここが重要だ。
推論設定を下げても、読むファイルが巨大なら入力は巨大なまま。何十個もツールを動かせば多段処理も残る。大量の差分やログを返せば出力も残る。
だからLight化は無意味ではないが、Astraそのものを安いモデルへ変身させるスイッチではない。
F1マシンのアクセルを少し緩めても、軽自動車の燃費にはならない。
公式の5時間目安でも、AstraからSol、Terra、Lunaへ下げるほど利用可能量のレンジは大きく増える。 ルーチン作業では、推論設定をいじるよりモデル選択のほうが効く場合がある。
6. 目的が「利用時間」ではなく「成果物」なら、見る指標を変える
AIを使う目的が「高級モデルを長時間回すこと」なら、週枠の短さはそのまま不満になる。
でも本当の目的がコード、記事、調査、修正済み成果物なら、KPIは別だ。
見るべきなのは例えば次のようなものだ。
- 一発で要求を満たした割合
- バグや見落としの残り方
- テスト通過率
- 手戻り回数
- 人間が直した時間
- 最終成果物までの総時間
ここでAstraとSolの最終成果物がほとんど変わらないなら、Astraを常用する理由は弱くなる。逆に、難しい原因究明でAstraだけが一発で核心へ届き、他モデルだと3回やり直すなら、短時間でもAstraの価値は高い。
時間単価ではなく、完成物1個あたりの計算コストを見る。
これが一番実務的だ。
7. Astraは「全部やる作業員」より「難所の専門家」にすると使いやすい
現行の公式説明でも、Astraは難しいバグ、未知の問題、複雑な分析向け、Solは機能実装や調査統合、Terraは日常的な変更、Lunaは抽出・分類・短い編集のような反復仕事向けという位置づけだ。
なので、成果物ベースで組むなら次の分業が分かりやすい。
- Luna / Terra：検索、抽出、整形、定型修正、単純なファイル編集、反復処理。
- Sol：普通の実装、調査統合、そこそこ難しいデバッグ、長めの実務タスク。
- Astra：根本原因が見えない不具合、設計判断、複数システムをまたぐ問題、失敗コストが高い最終判断。
Astraを「常時最高設定」にするのではなく、詰まった瞬間だけエースを出す。
野球で毎回クローザーを1回から投げさせたら、そりゃ週末まで持たない。
8. 本当の問題は「枠が少ない」だけでなく、リセット周期と消費速度のミスマッチ
Astraのように短時間で大量の計算を使えるモデルと、週次リセットは相性が悪い。
高負荷作業を一気に片付けたい人ほど、週の前半で枠を使い切りやすい。その後に別の難題が来ても、「次のリセットまで待つ」が発生する。
だから利用者が感じる不満は、単純な総量不足だけではない。
「一週間分の権利なのに、消費だけは数時間で可能」という時間設計の非対称性が大きい。
OpenAIは現在、アカウントによって保存済みリセットや購入リセットなどを提供する場合があると説明しているが、恒常的な日次回復へ変更したとは説明していない。
週パスを2時間で使い切れるなら、「毎日ちょっとゲージ戻してくれ」と言いたくなるのは自然だ。
それでも成果物が目的なら、現時点の現実解はかなり単純になる。
軽い仕事は軽いモデルへ。難所だけAstraへ。成果物が変わらないなら、燃費のいい方を使う。
Astraくんは遊園地そのものではない。ジェットコースターだ。乗るべき場所で乗れば強い。でも朝から閉園までジェットコースターだけ乗り続ける必要はない。
