GPT-6 Astraのトークン節約｜サブエージェントと設定を見直す6つの方法

「トークン効率」は、短い回答にすることだけではない

トークンはAIが文章やコードを処理する単位です。入力した指示、読ませたファイル、AIの回答、内部の推論などが消費に関わります。短い回答だけを指定しても、裏で同じ調査を繰り返していれば、仕事全体の効率はよくなりません。

僕が知りたいのは、必要な品質の成果物まで、どれくらいの消費で到達できるかです。最初の回答だけなら安くても、修正を何度も頼めば合計は増えます。反対に、少し深く考えさせてやり直しを減らせる仕事もあるはずです。

OpenAIもAstraについて、いくつかの評価では少ない出力トークンでよい結果を出し、単価が高くてもタスク当たりの推定API費用を抑えた、と説明しています。あくまで評価条件のある結果で、全員のサブスク残量が同じ割合で減りにくくなるという意味ではありません。

• 出典：Astraの公式ガイド（新しいタブ）

公式から「利用枠の消費を抑える改善」が発表されている

OpenAIのTibo氏は、米国時間9月6日、日本時間9月7日の投稿で、ChatGPTアカウントで使うAstraのパワーユーザー向けに改善を行ったと説明しています。品質を変えず、特に消費が大きくなる一部のケースでは、サブスクリプションから引かれる利用量を最大3〜4分の1にできる、という内容です。

大切なのは「一部のケース」という条件です。投稿にあるlong tailは、ここでは典型的な処理から外れた、消費が大きくなりやすい側のケースを指すと読めます。すべての人が常に4倍長く使える、とまでは書かれていません。具体的にどの処理が対象かも、この短い投稿では詳しく公表されていません。

また、これはAPI単価の値下げの発表とは別です。「公式が改善した」と「自分の環境で、同じ仕事の消費が下がった」は分けて確認したいところです。利用画面とクライアントを更新し、比較するなら改善後の同じ環境で記録を取り直す方が筋が通ります。

• 出典：発表投稿（新しいタブ）

「サブエージェントを止める」は、一つの対処であって結論ではない

サブエージェントは、親のAIから仕事の一部を渡される別の作業担当です。たとえば「公式資料の調査」「テストの確認」「別案の検討」を分担できます。人間のチームと同じで、同時に進められるのは利点です。

一方、担当を増やせば説明、引き継ぎ、結果の確認も増えます。5人に同じ資料を最初から読ませ、似た調査をさせれば、消費が膨らんでも不思議ではありません。ただし、これだけで特定の利用者の急減原因が証明されたわけではありません。

「止めると減った」という観察は参考になります。しかし、停止によって何が減ったのかは、子の人数なのか、渡す文脈なのか、待機中の往復なのか、分けて考える必要があります。更新や設定変更の内容を追わず、永久に全部止めるのが正解とするのは早いと思います。

待っているだけなのに、なぜ消費が増えるのか

開発者コミュニティで興味深かったのは、子の完了を待つ親が、短い間隔で何度もモデル処理に戻っていた、という調査です。

あるRedditの報告では、Astraを親にして作業させたログに、結果のない待機が47回ありました。投稿者は、それに伴う入力が総入力の大きな部分を占め、多くがキャッシュ済みだったと説明しています。これは一つの環境の自己調査です。

人間なら「終わったら呼んで」で済むところを、AIが「終わった？」「まだです」を繰り返して、そのたびに会話を読み直すイメージです。待つ時間そのものが課金される、という意味ではありません。待機の前後にモデル処理が何度発生するかが問題になります。

同種の挙動はCodexのGitHubにも報告されています。ただし、Issueがあることは、OpenAIが原因や修正を正式認定したことと同じではありません。

ここから僕が取り入れたいのは、結果が届いたら続ける仕組みがある場合、それを使い、短い間隔で状態だけを確認し続けないことです。待機を長くする設定が使えるかはクライアント次第。「この秒数にすれば全員解決」というコピペ設定にはしません。

• 出典：ログを調べた投稿（新しいタブ）
• 出典：待機・状態確認に関するIssue（新しいタブ）

キャッシュ済みの入力も、ゼロ円ではない

キャッシュは、共通する入力を再利用して負担を減らす仕組みです。Astraの公式API標準料金では、通常の入力10ドルに対し、キャッシュ済み入力は100万トークン当たり1ドルです。同じ分量なら割安ですが、繰り返す回数が多ければ合計は増えます。

ログを読むときは、総入力にキャッシュ済み入力が含まれているかも確認が必要です。両方をそのまま足すと二重に数えてしまうことがあります。トークン数からの換算値と、実際のサブスク利用量も同一ではありません。

「700万トークンを無駄にした」という見出しだけでは、通常入力が700万なのか、キャッシュを含むのか、重複した集計なのか分かりません。大きな数字に驚いたときほど、元のログの数え方まで戻る価値があります。

• 出典：API料金表（新しいタブ）

1．最初に「どこまでで終わりか」を決める

「全体をいい感じに直して」では、調べる範囲もテストの終点も広がります。対象の画面や不具合、期待する動作、今回は触らない箇所を書いておく。これはAIの能力を制限するためではなく、不要な探索を減らすためです。

たとえば、「設定画面の保存エラーを直す。再現するケースと関連する回帰確認まで行い、関係のないUI変更はしない」。ここまで書けば、完了の判断も一緒に渡せます。逆に原因が不明なら、最初は調査だけで区切り、原因が分かってから実装を頼む方法もあります。

2．サブエージェントには、独立した仕事だけを渡す

僕なら小さな修正は一つの担当で始めます。並行して調べられるテーマが複数ある場合や、別の視点で確認したい場合に、担当を追加します。

渡すものも、会話全部が必要なのか、対象ファイルと目的と判断基準だけで足りるのかを考えます。ただし、文脈を削りすぎて重要な前提を落とせば、やり直しになります。人数を減らすことと、品質を守ることはセットで見たいです。

3．小さな変更に、毎回大きな検証を重ねない

OpenAIのAstra向けガイドには、小さい変更でも検証が広くなりすぎる場合があることと、変更に合う確認範囲を指定する考え方が示されています。

ここは「テストを省く」と読まない方がよいと思います。不具合修正なら再現ケースと影響範囲を確かめる。その後、新しい変更や失敗、未解決の懸念がないのに、同じ大きな検証を何度も繰り返さない。安全に終わるための確認と、惰性の繰り返しを分ける話です。

• 出典：テストに関する公式の説明（新しいタブ）

4．長い会話や指示ファイルを、抱え込ませすぎない

終了した仕事の経緯が大量に残った会話で、次の全く別の仕事を始めると、必要な前提を見つけにくくなります。目的が変わるなら、決定事項、対象、未解決点を短くまとめて新しい作業に引き継ぐ方が扱いやすい場面があります。

AGENTS.mdやスキルにも、古い方針と新しい方針が混在していないか確認します。「必ず何度も確認」と「確認せず進める」が同時に残っていれば、判断に迷う原因になります。公式ガイドも、こうしたファイルの指示を点検することを勧めています。

5．推論レベルは、一段ずつ変えて比べる

「全部High以上」が自分に必要かは、実際の仕事で確かめる余地があります。簡単な質問や範囲の狭い作業からMediumなどを試し、足りなかったときに上げる。僕自身の現状はHigh以上が中心ですが、これは節約の最適解を検証済みという意味ではありません。

比較する日は、推論レベルと並列数を一度に変えない方が、何が効いたか分かりやすいです。変更前後の残量だけでなく、完了までの時間、修正回数、検証結果も残します。

6．Fastが必要な仕事かを確認する

Fastは速く処理するための設定で、節約モードではありません。Work／Codexの公式料金ページでは、AstraのFastにStandardの2.5倍の係数が示されています。急ぎでない仕事なら標準速度を選ぶ、という見直しもできます。これは推論レベルとは別の設定で、API側のFast料金の倍率とも混同しないようにしてください。

• 出典：速度と利用量の公式説明（新しいタブ）

新機能もある。ただし、設定名だけを真似しない

公式のモデル案内には、実験的なコンテキスト管理があります。会話の扱いを調整する機能ですが、利用できるプランやクライアント、新しいタスクでの有効化などに条件があります。実験的という扱いも含めて、現在の画面と資料を確認してから使いたい機能です。

API側には、会話の途中で推論設定を変えてもキャッシュを保ちやすくするconfiguration_updateという仕組みも案内されています。簡単に言えば、毎回最初の指示を書き直さず、次の処理から考え方の設定を変える方法です。対応条件のあるAPI機能なので、CodexやOpenClawで設定名を書けば必ず同じように働く、とは限りません。

節約のための設定が増えすぎて、何を変えたか分からなくなるのも避けたいところです。まずは標準の環境で基準を取り、一つずつ変更して、戻せるようにする。地味ですが、再現できる知見が残ります。

• 出典：公式の案内（新しいタブ）
• 出典：推論設定を途中で変える公式説明（新しいタブ）

まず減らしたいのは、「考える価値のない往復」

調べてみると、利用者の声には、不要な委任を減らす、待機の仕方を変える、推論レベルを下げる、という違う対処がありました。どれも一つの万能な節約法ではありません。

公式は消費の大きいケースへの改善を発表し、委任の条件や検証範囲を明確にする指針も出しています。僕はそこを土台に、小さい仕事は小さく始める、分担するときは重複を減らす、必要な検証を終えたら終える、という運用から試したいと思います。

Astraに深く考えてほしい場面は、これからもあります。そのための枠を残すには、能力を一律に下げるより先に、無駄な確認や同じ調査の繰り返しを見つける。皆さんも、まず一つの仕事で条件をそろえて比較してみてはいかがでしょうか。劇的な削減率より、自分の仕事で続けられる方法を見つけたいところです。