Astraくんから利用枠の過剰消費を抑制する施策

Astraは優秀。しかし燃費がわるい。車に例えると1km/㍑くらいしか走れないのでは、、と思うようなセッションがかなり発生しています。

小さな修正を頼んだだけなのに、意図のわからない検証が多数実行される。サブエージェントに任せた範囲をメインエージェント（Astra）が再調査、作業をする等。

私の環境で月額利用枠が過剰に消費されたセッションをAstra自身に分析させたところ、Astra には「正しさや整合性を取りこぼさない」ことを強く優先する傾向があるのでは、という仮説が出てきました。これはAstra自身の分析結果であり、仕様を示すものではありませんが、実際の挙動やログから私自身もそのような感覚をもっています。

上記を人間に例えると「超優秀だが神経質な人」と言う感じで、必要以上の検証や再確認へ進みやすくなっているように見えました。

また安価なサブエージェントに作業を委譲しても、部下の作業を細部まで確認したいマイクロマネジメント上司のような振る舞いが見受けられました。

この記事で共有したいのは、調査結果そのものではなく、一番効果があった AGENTS.md へ追加した指示です。

前提とする設定

追加設定の前提として、実装・ファイル変更・テスト実行はサブエージェントで実行する設定を入れています。

AGENTS.md

- 実装・ファイル変更・テスト実行を伴う作業は、主エージェントが要件整理・実装計画・結果確認を担当し、原則として`.codex/agents/implementer.toml`の`implementer`サブエージェントへ委譲する。主エージェントは、サブエージェントへ全体設計の変更を指示しない限り、最小限の実装計画を渡す。
- `implementer`へ委譲するとき、起動機構が`fork_turns`を指定できる場合は原則`"none"`を指定する。対象ファイル、必要な背景、制約、完了条件、実行する検証を起動メッセージに記載する。親の会話履歴そのものが作業に必要な場合だけ、必要なターン数を指定する。

fork_turnsはimplementer.tomlの設定項目ではなく、対応するspawn_agentの起動引数です。AGENTS.mdには起動時に"none"を指定する運用指示を書きます。実際に指定されたかは、起動時のツール呼び出しで確認します。

implementer.toml

私の作業ではAWS CLIなどを利用することが多いため、network_access = trueにしています。これはAWS CLIだけに通信を限定する設定ではなく、workspace-writeサンドボックス内からの外向き通信を許可します。必要性に応じて設定してください。

以下は私が使用したgpt-5.6-terraのhigh設定です。今なら gpt-6-sol light やgpt-6-luna xhigh も候補だと思います。

name = "implementer"
description = "Implementation and test execution agent."

model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"

developer_instructions = """
Act only as the implementation worker.

Follow the implementation plan from the parent agent.
Modify code, run commands, run tests, and report results.

Do not change the overall architecture unless explicitly requested
by the parent agent.
"""

[sandbox_workspace_write]
network_access = true

AGENTS.md に追加した指示

以下の指示を AGENTS.md に入れるとテストが薄くなります。プロダクトレベルのアウトプットには利用しないでください。バイブコーディングで良いもの、初回モック、個人利用の低リスクな試作を対象にご利用ください

以下が追加した内容です。

この記載には批判も多く出ると思います。正しく対処を考えるなら、テストや評価の仕組みである「ハーネスをしっかり整える」に尽きます。ただ個人的な低リスク試作で毎回ハーネスを整えるというのも不毛な作業なので、ここでご紹介している対策は AGENTS.md で雑に月額利用枠の消費を抑えたい場合の対処方法となります。

このため以下の記載をお試しになる場合は、自分が権限を持っているリポジトリ、かつ壊れてもよいものでお試しください。

## 検証の最小化と必要な対処

- 検証は変更の可逆性、影響範囲、正本への影響、外部状態への影響に応じて選ぶ。安心のためだけの全件検査、全履歴の再読、全同期、全再構築は行わない。
- 文書・設定・データだけの変更では、対象差分と形式を確認する。コードを変更していない限り、テストを実行しない。
- コード変更では、まず変更箇所に対応するテストを 1 回実行する。共有処理を変更した場合、または人が明示した場合だけ、全テストを実行する。
- 生成・一覧更新・整合性検査は、必要な一巡を各 1 回だけ実行する。同じ成功結果を別の担当者が再実行しない。
- 外部 DB、MCP、検索インデックス、外部サービスへの書き込みを伴う作業には、この節を適用しない。別途、対象・復元手段・実行後の確認を完了条件として決める。
- 既存の検証が目的の状態を確認できない場合は、目的に直接対応する最小の確認を追加する。形式検証の成功を外部反映の成功として扱わない。
- エラー、想定外の差分、書き込み失敗が起きたら、直ちに停止する。原因、影響したファイル、復旧元を報告し、別方式での試行や最初からの再実行は行わない。修正後は影響した確認だけを 1 回再実行する。
- 完了報告には、変更内容、実行した確認、未解決事項だけを簡潔に記載する。全文、巨大な差分、反復した経過報告は出さない。

上記の記載の骨子

AGENTS.md への追加記載の骨子は以下です。

• 複数回の同じような検証を抑える
• サブエージェントへの過干渉を抑える

実行タスクによって効果は変わると思いますが、2つめは、サブエージェントに gpt-5.6-terra を使っているのに月額利用枠の消費が収まらない施策レベルのタスクに合っていると思います。

私の環境では、「前提とする設定」の委譲ルールと、この検証を絞る指示を組み合わせたところ、Astraのマイクロマネジメントが抑制できました。

適用しない場面

本記事の指示は、個人の試作、モデルケース、失敗の影響を自分だけに限定できる用途のためのものです。次の作業では、そのまま適用しないでください。テストが抑制されることで悲しいことになる可能性が高まりますのでご注意ください。

• 本番環境への反映
• チーム、顧客、第三者へ渡す成果物
• 認証、権限、個人情報、課金、セキュリティに関わる変更
• データ削除、移行、外部サービスへの書き込み
• 継続利用するツールや、障害が自分以外に影響する変更

参考資料

• Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220（利用者報告。参照日: 2026-09-22）
• Subagents | OpenAI（参照日: 2026-09-22）