この記事には楽天アフィリエイトの広告が含まれます。リンク経由で購入されると、運営者に報酬が入ることがあります。本文の判断と広告は分けて記載しています。 Amazonのアソシエイトとして、PROBEFOLIOは適格販売により収入を得ています。
「サブエージェントを止めたら、利用枠が長持ちした」。Astraの使い方を調べていると、こうした話が目に入ります。枠を早く使い切った経験があると、すぐ同じ設定にしたくなる気持ちはよく分かります。
ただ、調べていて気になったのは、その後の投稿でした。停止を報告していた人自身が、後から「設定で解決済み」と補足しています。最初の投稿だけを読めば、受け取る結論が変わってしまいます。
今回はGPT-6 Astraに絞り、公式の改善、利用者の調査、僕たちが実際に見直せる運用を整理しました。Astraの能力を使いながら、同じことを考え直す回数や、不要な往復を減らす。そこから始めるのがよさそうです。
この記事の目次
トークン効率とは、仕事の完了までに使う量と成果の関係
トークンはAIが文章やコードを処理する単位です。入力した指示、読ませたファイル、AIの回答、内部の推論などが消費に関わります。短い回答だけを指定しても、裏で同じ調査を繰り返していれば、仕事全体の効率はよくなりません。
僕が知りたいのは、必要な品質の成果物まで、どれくらいの消費で到達できるかです。最初の回答だけなら安くても、修正を何度も頼めば合計は増えます。反対に、少し深く考えさせてやり直しを減らせる仕事もあるはずです。
OpenAIもAstraについて、いくつかの評価では少ない出力トークンでよい結果を出し、単価が高くてもタスク当たりの推定API費用を抑えた、と説明しています。あくまで評価条件のある結果で、全員のサブスク残量が同じ割合で減りにくくなるという意味ではありません。
公式から「利用枠の消費を抑える改善」が発表されている
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が原因や修正を正式認定したことと同じではありません。
ここから僕が取り入れたいのは、結果が届いたら続ける仕組みがある場合、それを使い、短い間隔で状態だけを確認し続けないことです。待機を長くする設定が使えるかはクライアント次第。「この秒数にすれば全員解決」というコピペ設定にはしません。
キャッシュ済みの入力も、ゼロ円ではない
キャッシュは、共通する入力を再利用して負担を減らす仕組みです。Astraの公式API料金（標準速度・短いコンテキスト）では、通常の入力10ドルに対し、キャッシュ済み入力は100万トークン当たり1ドルです。同じ分量なら割安ですが、繰り返す回数が多ければ合計は増えます。
ログを読むときは、総入力にキャッシュ済み入力が含まれているかも確認が必要です。両方をそのまま足すと二重に数えてしまうことがあります。トークン数からの換算値と、実際のサブスク利用量も同一ではありません。
「700万トークンを無駄にした」という見出しだけでは、通常入力が700万なのか、キャッシュを含むのか、重複した集計なのか分かりません。大きな数字に驚いたときほど、元のログの数え方まで戻る価値があります。
通常入力とキャッシュ済み入力では、APIの単価も違います。AstraとSolの入力・出力の料金表で内訳を見ると、大きなトークン数をそのまま高額な請求だと受け取らずに済みます。
1．最初に「どこまでで終わりか」を決める
依頼の最初に、対象の画面や不具合、期待する動作、変更してよい範囲、完了を確かめる方法を書きます。例えば「保存ボタンを押すと入力内容が失われる」という不具合なら、どの入力で起きるかと、保存後に残るべき内容を伝えます。調査の範囲と終点が具体的になります。
たとえば、「設定画面の保存エラーを直す。再現するケースと関連する回帰確認まで行い、関係のないUI変更はしない」。ここまで書けば、完了の判断も一緒に渡せます。逆に原因が不明なら、最初は調査だけで区切り、原因が分かってから実装を頼む方法もあります。
2．サブエージェントには、独立した仕事だけを渡す
僕なら小さな修正は一つの担当で始めます。並行して調べられるテーマが複数ある場合や、別の視点で確認したい場合に、担当を追加します。
渡すものも、会話全部が必要なのか、対象ファイルと目的と判断基準だけで足りるのかを考えます。ただし、文脈を削りすぎて重要な前提を落とせば、やり直しになります。人数を減らすことと、品質を守ることはセットで見たいです。
たとえば、同じ不具合を3人に最初から調べさせる代わりに、「再現手順を確かめる」「関連する変更を読む」「直した後の確認項目をまとめる」と分けます。それぞれに対象と返してほしい結果を渡し、最後は主担当が食い違いを確かめます。これは分担の説明例で、消費量を測った結果ではありません。
まずはこの分け方を手元の仕事で試してみてください。Codexのタスク設計から順に学びたい方には、下の参考書が候補です。出版社の目次に、サブエージェントへ依頼する基準・分割する軸・人数の設定が並んでいます。最新の不具合や料金を調べる資料とは使い分けてください。
3．修正した不具合と影響する範囲をテストする
OpenAIのAstra向けガイドは、変更に合った検証範囲を指定する考え方を案内しています。合計金額の計算を直したなら、元の誤計算、0個の入力、負数や小数、個数の上限など、その関数が受け取る条件を確かめます。関係する呼び出し元へ影響がある場合は、そちらも対象です。
コードレビューの具体例では、同じ8条件を使い、修正前1件成功・7件失敗、修正後8件成功を確認しています。この結果は小さな自作コードの検証です。テストを一つ通せばすべてのシステムが安全、という意味ではありません。
必要な確認が通り、新しい変更・失敗・未解決の懸念がなければ、その結果を残して作業を完了します。追加の修正が入った場合は、影響する確認を再実行します。これで、必要な検証を確保しながら同じ作業の重複を減らせます。
4．次の仕事へ、必要な条件と確認結果を引き継ぐ
終了した仕事の経緯が大量に残った会話で、次の全く別の仕事を始めると、必要な前提を見つけにくくなります。目的が変わるなら、決定事項、対象、未解決点を短くまとめて新しい作業に引き継ぐ方が扱いやすい場面があります。
AGENTS.mdやスキルにも、古い方針と新しい方針が混在していないか確認します。「必ず何度も確認」と「確認せず進める」が同時に残っていれば、判断に迷う原因になります。公式ガイドも、こうしたファイルの指示を点検することを勧めています。
引き継ぐ情報は、目的、対象ファイル、現在の差分、実行したテスト、未確認事項の五つです。例えば「計算式を修正、8条件が成功、割引と送料は対象外」と残せば、次の担当が確認すべき範囲が分かります。CodexとClaude Codeを併用する手順に、そのまま使えるメモの例を載せています。
5．推論レベルは、一段ずつ変えて比べる
「全部High以上」が自分に必要かは、実際の仕事で確かめる余地があります。簡単な質問や範囲の狭い作業からMediumなどを試し、足りなかったときに上げる。僕自身の現状はHigh以上が中心ですが、これは節約の最適解を検証済みという意味ではありません。
比較する日は、推論レベルと並列数を一度に変えない方が、何が効いたか分かりやすいです。変更前後の残量だけでなく、完了までの時間、修正回数、検証結果も残します。
設定ごとの違いがまだつかめない場合は、仕事に合わせた推論レベルの選び方から、試す設定を一つ決めてみてください。
6．Fastが必要な仕事かを確認する
Fastは速く処理するための設定で、節約モードではありません。Work／Codexの公式料金ページでは、AstraのFastにStandardの2.5倍の係数が示されています。急ぎでない仕事なら標準速度を選ぶ、という見直しもできます。これは推論レベルとは別の設定で、API側のFast料金の倍率とも混同しないようにしてください。
推論設定を途中で変える機能は、APIの対応条件を確認する
API側には、会話の途中で推論設定を変えてもキャッシュを保ちやすくするconfiguration_updateという仕組みが案内されています。GPT-6系の標準・単一エージェントのリクエストで、変更できるのは推論の深さです。最初の指示文やリクエスト側のreasoning.effortを保ち、次の処理から設定を変えます。対応条件のあるAPI機能なので、CodexやOpenClawで設定名を書けば必ず同じように働く、とは限りません。
節約のための設定が増えすぎて、何を変えたか分からなくなるのも避けたいところです。まずは標準の環境で基準を取り、一つずつ変更して、戻せるようにする。地味ですが、再現できる知見が残ります。
まず減らしたいのは、「考える価値のない往復」
調べてみると、利用者の声には、不要な委任を減らす、待機の仕方を変える、推論レベルを下げる、という違う対処がありました。どれも一つの万能な節約法ではありません。
公式は消費の大きいケースへの改善を発表し、委任の条件や検証範囲を明確にする指針も出しています。僕はそこを土台に、小さい仕事は小さく始める、分担するときは重複を減らす、必要な検証を終えたら終える、という運用から試したいと思います。
Astraに深く考えてほしい場面は、これからもあります。そのための枠を残すには、能力を一律に下げるより先に、無駄な確認や同じ調査の繰り返しを見つける。皆さんも、まず一つの仕事で条件をそろえて比較してみてはいかがでしょうか。劇的な削減率より、自分の仕事で続けられる方法を見つけたいところです。
よくある疑問を、ここで。
使い始める前に、気になるところから。
サブエージェントを増やすと、必ず安くなりますか？
必ずではありません。共有する説明や確認、結果をまとめる処理も増えます。作業時間が短くなったことと、合計の消費が減ったことを分けて確認してください。
どんな作業なら分担しやすいですか？
別々の資料の確認など、独立して進められ、結果の形式が決まっている仕事が候補です。直前の結果を待つ作業や同じファイルを頻繁に書き換える作業は、調整の負担も考えます。
何を記録すれば節約できたか分かりますか？
同じ完成条件で、親と子の処理を含めた入力・出力、料金、所要時間、やり直し回数を比べます。月額枠とAPI従量課金は、同じ数字として混ぜないようにします。
この記事を共有する
商品情報の提供：Supported by Rakuten Developers
出典と、この記事について
公式資料や、記事で参照した発表・報道をまとめています。仕様や料金は、利用する前に最新の案内をご確認ください。
- Astraの公式ガイド（新しいタブで開きます）
- 発表投稿（新しいタブで開きます）
- ログを調べた投稿（新しいタブで開きます）
- 待機・状態確認に関するIssue（新しいタブで開きます）
- API料金表（新しいタブで開きます）
- テストに関する公式の説明（新しいタブで開きます）
- 速度と利用量の公式説明（新しいタブで開きます）
- 推論設定を途中で変える公式説明（新しいタブで開きます）
- 運営者のDuke note原記事（掲載時の記録）（新しいタブで開きます）
- 技術評論社：Codexではじめるエージェンティックコーディング（内容・目次）（新しいタブで開きます）
確認した内容と条件は本文に記載しています。結果や使い勝手は、資料や環境によって異なります。編集方針を読む
ぜひコメントください