Astraの利用枠が20分で消える AIの消費量が読めない理由と減らし方

仕事から帰って、さあ趣味の開発をやろう。30分後、ほとんど進まないまま利用枠が尽きる。GPT-6 Astraを使っている方から、そういう声が続いています。

9月4日の記事でAstraの登場を扱ったとき、料金についてはこう書きました。ChatGPTのプランでは使用量が既存の契約枠に含まれます、と。その枠が、思ったより早く尽きる。 発表から数日で、そういう声が相次いでいます。

ただ、この話は「Astraが重い」で終わりません。AIの利用量がなぜ見積もれないのかという、もう少し長持ちする話につながります。

公式の目安には、9倍の幅がある

まず何が起きているか。OpenAIのCodexのリポジトリに、9月6日に立った報告があります。bug と rate-limits のラベルが付いていて、同じ趣旨の重複が3件挙がっています。

報告されている数字を並べます。

契約	消費
Plus	100%の状態から20分で上限
Business(低い推論設定)	2タスクで98%から0%
Plus(高い推論設定)	1タスク11分31秒で5時間の枠が100%から0%、週の枠も100%から83%へ

では、これは異常なのか。判断する材料として、公式の料金ドキュメントに5時間あたりに送れるメッセージ数の目安が載っています。

モデル	Plus	Pro(20倍)
GPT-6 Astra	5〜45	100〜900
GPT-5.6 Sol	10〜100	200〜2,000
GPT-5.6 Luna	250〜2,000	5,000〜40,000

Astraは5回から45回。 幅が9倍あります。下限に近い側に当たれば、20分で尽きること自体は公式の目安の内側で起こりえます。ただし報告には送信回数が書かれていないので、この報告が想定内なのか不具合なのかは、まだ分かりません。 issueは開いたままです。

一番軽いLunaと比べると、下限どうしで50倍の開きがあります。

ほかにも倍率が効く場所があります。Fast modeは標準の2.5倍、画像生成は平均で3〜5倍速く枠を減らすと明記されています。

消費を決めるのは、プロンプトの長さではない

「短く聞けば安く済む」と思いがちですが、公式は否定しています。

見た目が似たタスクでも、消費する量は異なります。モデル、コンテキスト、推論、ツールの利用、検索、キャッシュのすべてが消費に影響するため、プロンプトの長さだけでは当てになる見積もりになりません。

入力欄に打った文字数は、減り方とほとんど関係がない。 これが読めなさの正体です。

ここで言う消費は、月額料金そのものではありません。同じ契約で、どれだけの仕事を処理できるかの話です。固定料金のプランなら、枠を早く使い切っても請求額がその場で増えるわけではなく、代わりに待たされるか、追加のクレジットを買うか、上位プランに移るかの判断が出てきます。単位はトークンで、文章を細かく区切ったかたまりだと思ってください。

心当たりがあるかもしれません。9月5日にMEMORY.mdの記事で、AIの記憶を整理する話を書きました。索引が長いほどコンテキストを食い、指示への追従性が下がる、と。あれと同じ仕組みが、今度は利用枠の側に出ています。 読み込む量が増えれば、精度も枠も同じ方向に動きます。

つまり短く聞いても、AIが裏で大量のファイルを読み、ツールを何度も呼び、長い履歴を抱えていれば、消費はそのぶん膨らみます。見えているのは氷山の一角です。

分けるほど安くなる、とは限らない

ここが今回いちばん意外だったところです。

9月1日の記事で、サブエージェントの話を書きました。設計する担当と手を動かす担当を分けて、AIにAIを呼ばせる。あのとき「担当を増やすほど、消費は増えます」と注意を添えましたが、理由までは書けていませんでしたので、ここで埋めます。

まず、公式が認めています。 サブエージェントのドキュメントにこうあります。

各サブエージェントが自前でモデルとツールの処理を行うため、サブエージェントのワークフローは、同等の単一エージェントの実行よりも多くのトークンを消費します。

次に、その内訳が課題として登録されています。 Codexのリポジトリに「サブエージェントのファンアウトは、各エージェントが固定のコンテキスト・ツール・スキルの負担を払うため、利用量を増やしうる」という報告があり、subagent と rate-limits のラベルが付いています。

ここからは起票者の分析です。 サブエージェントは1体ごとに新しい文脈で立ち上がるため、毎回ほぼ同じものを読み直すことになる、という見立てです。システムの指示、AGENTS.md などリポジトリの指示、使えるツールの定義一覧、スキルの一覧、環境の探索結果。設定によっては親の履歴も引き継ぎます。この固定の負担が、サブエージェントの数だけ重なるという説明です。

新しい担当者を増やすたびに、同じ分厚い業務マニュアルを最初から渡し直している。そう考えると分かりやすいと思います。

起票者はこう書いています。

節約のために小さなタスクを安いモデルへ委ねるつもりの構成が、裏目に出ることがある。

「分ければ安くなる」の逆が起きうるという指摘です。5体に分けた調査が、それぞれほぼ同じ前提を読み込んでから、少しずつしか働かない。この分析自体はOpenAIが認めたものではなく、課題として登録されている段階です。

ここから先は利用者の推測なので、そのつもりで読んでください。Xでは、親エージェントが30秒ごとに起きてサブエージェントの完了を確認しており、その空の確認のたびに親の文脈を丸ごと読み直しているのではないか、という見方が出ています。投稿者本人が「バグかもしれない」「そう見える」と留保したうえで、OpenAIに確認を求める形で書いています。裏は取れていません。

そして、サブエージェントだけが原因でもありません。 Xには「サブエージェントをほとんど使わず、Astraの中程度の設定で普通に1日働いて、週の枠の25%」という報告もあります。原因を1つに決めつけないほうがよさそうです。

対策は打たれたが、更新情報に載っていない

OpenAIは動いています。ただ、告知の場所に癖があります。

Codexとdesktopアプリを担当するTibo氏が、9月7日にこう書きました。

ChatGPTアカウントでログインした状態でAstraを多用する方について、裾野の重い使い方での利用量を改善しました。品質の変更はなく、純粋な改善です。裾野の重い使い方では、契約から引かれる利用量が最大で3〜4分の1になりえます。

さらに翌日、全有料プランの利用枠を一斉にリセットすると予告しました。これは実施されています。私たちのアカウントでも、実際に枠が戻りました。

問題は、この2つが公式の更新情報に見当たらないことです。ChatGPTとCodexの変更履歴にも、ChatGPTのリリースノートにも、9月分を見た限りでは利用量の改善もリセットも出てきません。並んでいるのはCLIのバージョンとアプリの更新です。

他の場所で告知されている可能性は残りますが、枠の減り方が変わったのに、更新情報を追っていても気づけない状態ではあります。古い感覚のまま見積もりを立てることになるので、Codexを業務で使っているなら、変更履歴に加えて担当者の発信も見ておくほうが安全だと思います。

減らし方は、いくつか分かっている

対処は用意されています。公式が勧めているものと、報告から考えられるものを分けて並べます。

1つ目、公式の推奨。モデルを下げる。 公式が「上限に近づいたら、より小さいモデルに切り替えると枠が長持ちします」と明記しています。Astraは最上位です。調査や下書きなら、SolやTerraで足ります。

2つ目、公式の推奨とその応用。サブエージェントの使いどころを絞る。 公式は、並列で使うなら探索・テスト・要約といった読み取り中心の作業から始めるよう勧めています。書き込みを伴う並列は、衝突の調整でも手数が増えるためです。ここに先ほどの固定費の話を重ねると、小さい仕事を細かく分けるより、まとめて1体に渡すほうが枠を節約できる場面がある、という見方になります。

3つ目、利用者の報告。持たせる荷物を減らす。 これは公式の推奨ではありません。先ほどのissueのコメントに、プラグインを全部有効にしてスキルを53個抱え、頻繁にサブエージェントを立てていた状態をやめたところ4時間で1%程度の消費に落ちた、という報告があります。投稿者自身が「統制された比較ではない」と断っており、どの要素が効いたかも分けられていません。ただ、使っていないスキルとプラグインを切ること自体は今日できて、失うものもありません。

4つ目、公式の数字からの判断。倍率のかかる設定を避ける。 Fast modeは2.5倍、画像生成は3〜5倍と明記されています。速さや画像が要らない場面では外します。

5つ目、公式の推奨。測る。 Codexのセッション中なら /status で残量が見えます。公式は「1〜2週間ごとにダッシュボードを見て、自分のペースと残りを把握してください」と書いています。

なお、作業の途中で上限に達しても、そのターンは最後まで走らせてもらえます。中断されて成果物が消える、という設計にはなっていません。

見積もれないものを、どう予算に置くか

今回の件で見えたのは、AIの利用量は使う前に精度よく見積もれないということです。公式が9倍の幅で目安を出し、プロンプトの長さは当てにならないと書いている。これは不親切なのではなく、正直な表示だと思います。

だとすれば、やることは1つに絞られます。測ってから決める。

新しいモデルが出たら、まず普段の仕事を1週間そのまま流して、枠がどう減るかを見る。そのうえで、上位プランや追加クレジットにいくらまで出すかを決める。目安の幅が9倍もある以上、カタログの数字から積み上げた見積もりは当てになりません。

私たちも広告運用をAIに渡したときに同じ順序を踏みました。先に上限を決めるのではなく、実際に7週間動かしてから、人が握るものと渡すものを分けています。費用も同じで、動かす前に決めた予算は、たいてい根拠がありません。

もう1つ。モデルは1つに絞らないほうが安全です。最上位のモデルほど枠の減りは速く、今回のように使い勝手が話題になることもあります。調査はSol、実装はAstra、繰り返し作業はLuna。そういう使い分けを普段からしておくと、片方が詰まったときに仕事が止まりません。

Astraは実際に賢いモデルです。Xでも「めちゃくちゃ優秀だけど消費もえぐい」という言い方をよく見ます。賢さと安さが別の軸である以上、どちらを買っているのかを意識して使う。 それが、いまのところ一番現実的な付き合い方だと思います。