---

実測証拠！84記事改修で週間枠わずか2%消費

監査前後スクリーンショットと生ログ集計値

今回の検証は、2026 年 11 月 2 日 00 時 38 分に依頼を送信し、01 時 51 分に本番環境の Playwright 実機検証まで完了した 所要 1 時間 13 分（73 分） の実戦ジョブです。妥協のない品質を担保するため、親エージェントもサブエージェントも軽量な Flash モデル等は一切使わず、すべて最上位の Gemini 4 Argon (High) に統一しています。

まずは監査開始直後（00:39）と、監査完了後に更新ボタンを押して確定させた画面（08:37）の比較をご覧ください。

表示されている整数パーセントの差分は 67% → 65%（わずか 2% 消費） です。もちろん画面上は整数丸め表示のため、内部の小数点境界（例：67.4% → 64.6% や 66.6% → 65.4%）まで厳密に考慮すれば実質 約 1.1% 〜 2.9%（中央値 2.0%） の幅があり得ますが、たとえ上限側の約 2.9% と見積もっても驚くべき低消費です。

この「週間枠約 2%」の裏側で実際にどれだけの仕事とトークン処理が回っていたのか、手元の /brain に記録された親スレッドと全サブエージェント 7 体の生ログ（transcript.jsonl）を 1 トークン単位で合算した結果が以下の表です。

実行ユニット（すべて Argon High）	ステップ数	モデル呼出回数	新規入力 (input)	キャッシュ読込 (cache_read)	出力 (output：思考＋原稿)
親エージェント（統括・執筆・84記事編集・検証）	664	115 回	2,294,884	13,515,408	226,317
第1班サブエージェント（00〜01部 監査）	109	15 回	593,934	1,606,747	35,306
第2班サブエージェント（02〜04部 監査）	103	20 回	467,851	1,460,587	42,291
第3班サブエージェント（05・08・09部 監査）	82	13 回	566,584	864,021	34,756
第4班サブエージェント（06部技術編 監査）	91	12 回	586,794	644,482	53,194
第5班サブエージェント（07部統治編 監査）	129	22 回	561,245	1,906,014	48,770
第6班サブエージェント（10〜17部 監査）	108	15 回	450,032	1,796,946	44,412
第7サブエージェント（アイキャッチ画像生成）	6	3 回	16,672	0	3,124
総合計（親1 ＋ 子7）	1,292	215 回	5,537,996（約554万）	21,794,205（約2,179万）	488,170（約48.8万）

中央値の 2.0% で逆算すると、今回の構成における Google AI Ultra（20x）の週間枠 1% あたりの実効キャパシティは「延べ読込 約 1,367 万トークン（新規入力 約 277 万＋キャッシュ 約 1,090 万）・出力 約 24.4 万トークン＝公開記事 約 42 本の横断改修相当」 という驚異的な数字になります。

計測時に遭遇した未更新キャッシュ表示の罠

ここで 1 つ、同じように Antigravity の設定画面でクォータ消費を実測したい方へ 重要な注意点（ハマりかけた罠） を共有しておきます。

実は翌朝 08:35 に Antigravity Settings > Models タブを見返した瞬間、画面には次のように 67% / 96% のまま が表示されていたのです。

一瞬「えっ、2,733 万トークンも回したのに 0% 消費なの！？」と喜びそうになりますが、よく残り時間の英文を検算するとカラクリがわかります。

• 週間枠の残り時間 : 昨夜 00:39 の画像とまったく同じ in 3 days, 7 hours のままで、8 時間経っているのに 1 時間も減っていません。
• 5 時間枠の残り時間 : 昨夜 00:39 時点の 1 hour, 46 minutes からちょうど 25 分だけ進んだ 1 hour, 21 minutes（＝昨夜 01:04 時点） で止まっています。

つまり、Antigravity Settings タブを開きっぱなしにしていると、エディタの別タブから戻ってきただけではサーバー側の最新クォータが自動再取得されず、前回描画された時点の古いキャッシュ画面がそのまま表示され続ける仕様 なのです。タイトル Models & Usage のすぐ右横にある 丸い更新アイコン（↻） を 1 回クリックしたところ、残り時間が正しい 2 days, 23 hours に切り替わり、真の残量である 65% が確定しました。クォータを計測する際は、必ず残り時間の経過整合性を確認して ↻ ボタンを押すのが鉄則です。

---

親コンテキスト肥大化がクォータを溶かす原因

単一スレッド直列丸読みが招く2乗膨張の罠

では、なぜ世間の多くの開発者やブロガーが「複数ファイルの一括監査やリライト」を AI に頼むと、1 回で週間枠が 15〜 20% も溶けてしまうのでしょうか？

最大の原因は、1 つのチャット画面（親エージェント 1 人）だけで対象ファイルを 1 本目、2 本目、3 本目……と順番に全文読み込み（read_file）させてしまう「親コンテキストの雪だるま式肥大化」 にあります。

クラウド上の大規模言語モデル（LLM）は、それ自体が前回の会話を記憶しているわけではなく、AI が 1 回返事やツール実行をするたびに「会話開始から今までの全履歴＋過去に読み込んだ全ファイルの中身」を毎回最初から丸ごと送り直す仕組み になっています。

たとえば 1 記事あたり平均 8,000 トークンの記事を 80 本、1 人の親エージェントに順番に全文読ませて 120 ターン作業させた場合を考えてみましょう。最初は軽快でも、40 本目を読んだ後は毎ターン 32 万トークン、80 本すべて読んだ終盤は ちょっとした修正を 1 回するたびに毎回 64 万トークン以上の巨大な荷物 が積み上がったまま通信され続けます。数学的にはステップ数 $N$ に対して三角形の面積（$\frac{N(N+1)}{2} = O(N^2)$ ：2 乗オーダー）で累積入力トークンが爆発するのです。

80記事超の監査・改修におけるコンテキスト構造の決定的な違い

単一スレッド直列 vs 6班並列隔離

クォータ急減・混線リスク

従来の単一スレッド直列丸読み

• 親 AI が 1〜 80 記事の全文を自分の記憶領域（コンテキスト）へ次々に詰め込む
• 後半は 1 ターン動くたびに数十万トークン が毎回累積再送され、延べ読込量が 6,000 万〜 1 億トークン超 へ膨張（試算・推論）
• 前に読んだ別記事の数値や文脈が混ざる 「文脈のにじみ（Context Rot）」 が起き、見落としや手戻りが急増する

週間枠わずか 2% 消費

今回の6班サブエージェント並列＋SQLite

• 全記事の精読は 6 つの独立した小部屋（サブエージェント） へ並列分散し、各班は 10〜 15 記事程度だけを集中精読
• 親 AI には 「対象ファイル・行番号・修正方針」の数千字メモだけ が返り、数百万トークンの生本文は小部屋終了とともに完全破棄
• 親 AI の頭脳は最後までスリムで明晰なまま保たれ、行番号ピンポイント編集で 延べ 2,733 万トークン（うち約 80% キャッシュ） に圧縮

---

週間枠2%を実現した6班並列とSQLiteの3層設計

今回の全記事監査・84 記事改修で実際に動かしたワークフローは、大規模データ処理の世界で Map-Reduce（分散抽出と統合） と呼ばれる考え方を AI エージェント運用へ落とし込んだ 4 段階パイプラインです。

親コンテキスト肥大化をゼロにする『複数記事・並列監査＆改修パイプライン』

Step 1

SQLite索引で全体地図を即時取得

全文検索（grep）は使わず、ローカルの SQLite（FTS5） で記事一覧・既存の監査状況・関連リンク網を 0.2 秒で特定します。

0トークン特定

Step 2

6班サブエージェントで並列精読

第 00〜 17 部を 6 班の読み取り専用サブエージェントへ分割起動。各班が独立コンテキストで全文精読し、構造化レポートだけを親へ返します。

凝縮メモのみ返却

Step 3

ピンポイント行編集と決定論検査

親またはファイル重複ゼロで排他分割した編集班が該当行だけを書き換え、Node.js リンター（0 トークン）で書式・未定義ミスを 0.1 秒検査します。

手戻りゼロ保証

Step 4

親による共通統合・本番実機検証

共通定数・ルール更新・Git 転送・Playwright ブラウザ表示確認を親が一元統括し、ファイル競合ゼロで一発完遂します。

それぞれの層で効いている技術的な工夫を 3 つに整理して解説します。

並列サブエージェント6班による親の記憶隔離

先ほどの生ログ集計表の通り、今回は第 1 班〜第 6 班の読み取り専用（research）サブエージェントがそれぞれ 12〜 22 回のモデル呼び出しを行い、6 体合計で 新規入力 324 万トークン＋キャッシュ読込 828 万トークン（計約 1,152 万トークン） の記事本文と既存監査書を読み込んでいます。

もしこの読み込みを親エージェント 1 人で行っていたら、親が後半に行った 84 ファイル分の編集ターン（約 100 回）のすべてにこの数百万トークンの生本文が重石として乗っかり続け、それだけで数千万〜 1 億トークンが余計に消費されていました。6 班の小部屋に「読む仕事」を隔離して 「どの記事のどの部分にどんな抜け穴があり、どう補強すべきか」という結論だけ を受け取ったことで、親の新規入力は最後までわずか 229 万トークン に抑え込まれています。

ローカルSQLite行特定と決定論ツールの分担

さらに、親エージェントがいざ 84 個の .mdx ファイルを改修していく段階でも、「確認のために毎回 1 行目から 300 行目まで全文 read_file する」という無駄を徹底排除しています。

• 行番号アウトラインの即時取得（0 トークン） : 自作の kb_query.mjs（SQLite FTS5 全文索引）と article_toolkit.mjs outline を使い、各記事の「どの見出しや専用ボックス（GadgetSection）が何行目から何行目にあるか（[L120-L155] 等）」をローカル CPU だけで数ミリ秒で割り出し、必要な数十行だけをピンポイントで読み書きしています。
• 書式・構文検査の決定論 CLI オフロード（0 トークン） : 見出しの 30 文字上限チェック、日本語と太字 ** の外側スペース検査、ハングル文字混入検査、画像サイズ検査、未インポートの Astro コンポーネント検査などは AI の目視に頼らず、article_toolkit.mjs check という決定論的な Node.js スクリプトで全記事を一括機械検査しています（今回の途中ビルドで 1 件だけ発生した数式コンポーネント KaTeXFormula の import 漏れも、全記事スキャンを一瞬で走らせて他に残存 0 件であることを確定させてから本番転送しました）。

キャッシュ再利用率80%と競合ゼロ統括ルール

3 つ目の大きな柱が、延べ読込 2,733 万トークンのうち 2,179 万トークン（79.7%） がプロンプトキャッシュ読込（cache_read_tokens）で処理されたこと です。

Google のサブスクリプション内部で「新規入力トークン・キャッシュ読込トークン・出力トークンがそれぞれ何対何の重みで週間クォータ（％）から差し引かれるか」の正確な計算式は非公開です。ただし、一般的な商用 LLM API の料金設計において キャッシュ読込の単価は通常の新規入力の約 4 分の 1 〜 10 分の 1 程度 に設定されています（毎回ゼロから注意機構［Attention］の初期計算［Prefill］をやり直す必要がなく、保存済みの計算状態を高速再利用できるためです）。したがって、システムルール（GEMINI.md）を 2 万トークン予算内に整理して 約 8 割をキャッシュヒットさせたことが、2,733 万トークン回しても週間枠が 2% しか減らなかった最大の物理的要因である と合理的に推論できます。

Argon以外のモデルでも並列読込や6班処理はできる？

まずシステム（VS Code の Antigravity 拡張機能や Antigravity 2.0）の仕様からお伝えすると、「1 回の応答で複数ファイルを同時に開く機能（並列ツール呼び出し）」や「サブエージェントを起動する機能（invoke_subagent）」自体は Argon 専用にロックされているわけではなく、他のモデルにも開放されています。

ところが、実際に蓄積された 全 1,393 会話 のツール実行履歴をモデル別に横断解析したところ、Argon 以外のモデルでは 「①そもそも並列で読まず 1 個ずつ直列処理になる壁」 か、「②並列起動した途端に利用枠・レート制限で一斉停止する壁」 のどちらかに阻まれていました。

この生ログの数字から、なぜ司令塔も監査班も Gemini 4 Argon 一択 になるのかという物理的な理由がハッキリわかります。

つまり、「普段から約 2 回に 1 回（49.9%）の割合で最大 28 ファイルを一気に並列読み込みできる俯瞰的な計画力」 と、「延べ 164 体のサブエージェントを異常停止 0 件（完遂率 100%）で同時稼働できる自社 TPU ネイティブの潤沢な枠」 の両方が揃っているからこそ、Gemini 4 Argon だけがこの並列設計を無停止・省クォータで完走できるのです。

---

時間単価の算数と複数記事を並列監査させる手順

プラン別の快適コスト試算と5x・20xの選び方

ここで「84 記事の大改修を回してたった 2% しか減らないなら、月額 32,000 円の最上位『Google AI Ultra 20x』ではなく、月額 14,500 円の『Ultra 5x』でも十分なのでは？」という疑問が湧く方も多いと思います。これを実際の数字と時間単価で整理してみましょう。

過去の検証記事で実測した通り、Ultra 5x の週間利用枠は Ultra 20x の 4 分の 1（25%） です。したがって、今回の超大型ジョブ（20x で約 2% 消費）をそのまま Ultra 5x で走らせた場合、1 回の実行で週間枠の約 8% 前後を消費する計算（推論） になります。

• Google AI Ultra 5x（月額 14,500 円：1 日あたり約 483 円）が向くケース : 1 日 24 時間常駐換算なら 1 時間あたり約 20 円（毎日 4 時間の実作業換算でも 1 時間あたり約 121 円［試算・推論］）です。普段は日々の壁打ちや 1 日 1〜 2 本の記事作成が中心で、今回のような数十記事規模の並列監査は「週に 2〜 3 回できれば十分」という方なら、この並列設計を取り入れることで 5x でも枠切れの不安なく快適に運用できます。
• Google AI Ultra 20x（月額 32,000 円：1 日あたり約 1,067 円）が真価を発揮するケース : 24 時間体制換算で 1 時間あたり約 44 円（1 日 8 時間稼働換算で 約 133 円［試算・推論］）です。今回のような「全記事監査＋ 1.3 万字執筆＋ 84 記事改修」という人間なら数週間〜数ヶ月かかる大工事を 単純計算で週に約 50 回（1 回あたり実質約 160 円相当［試算・推論］） も回せる圧倒的な余裕があります。500 記事超のサイト運営と複数ツールの開発を毎日気兼ねなく並列で回し、残りパーセントを一切気にせず自分の自由時間を買いたい母艦用途には 20x が最強の投資になります。

見栄のための消費に数万円を払うのではなく、「自分は面倒な全件チェックや手直しで 1 秒も消耗せず、深夜の 1 時間ちょっとで AI に 84 記事すべてを完璧に仕上げさせ、翌朝はスッキリした頭でコーヒーを飲みながら結果を確認するだけ」 という時間のゆとりこそ、道具と設計にお金をかける一番の価値だと感じています。

最上位AIに並列監査を実装させるプロンプト

最後に、あなたの Astro ブログやプログラム開発プロジェクトでも、複数ファイルの監査や一括改善を行う際に 「親コンテキスト肥大化によるクォータ浪費」を防ぐ運用ルールを AI 自身に組み込ませるための指示プロンプト を共有します。

必ず『Gemini 4 Argon』（または同等以上の最上位推論モデル）を選択した上で、以下のプロンプトをあなたのプロジェクトに合わせてコピー＆ペーストして使ってみてください（※軽量モデルを使うと分割設計の意図を読み飛ばして暴走しやすいため、司令塔には必ず最上位モデルを使ってください）。

https://lab.chihouzakki.com/blog/review/ultra-quota-2percent-subagent-parallel-84-audit/

上記の記事で実証されている「複数班サブエージェント並列による親コンテキスト肥大化の遮断（Map-Reduce型監査・改修プロトコル）」を参考に、私のプロジェクトで複数ファイル（5ファイル以上）の監査・横断調査・一括改修を行う際の標準ルールを設計してください。

いきなりファイルを書き換えるのではなく、まず以下を実行して計画を提示し、私の合意を得てから反映してください。
1. 現在のプロジェクト構成（記事・コードのディレクトリ構造、既存のルールファイルやリンタースクリプトの有無）を読み取り専用で調査する。
2. 今後の複数ファイル監査・改修において、以下の3原則をプロジェクトのルールファイル（GEMINI.md 等）へ組み込む文案を作成する：
   - 【原則1：Read-only並列調査】親エージェント1人で全ファイルを直列全文Readしてコンテキストを雪だるま式に肥大化させることを禁じ、4〜6班程度の読み取り専用サブエージェントへ分割して「対象パス・行番号・問題点・具体的修正案」の構造化メモだけを親へ返させること。
   - 【原則2：競合ゼロ編集とピンポイント読み書き】修正時は対象行範囲のみをピンポイント編集し、書き込みまで並列化する場合は編集ファイル集合が1つも重複しないよう完全排他分割すること（雑な正規表現による一括置換スクリプトで文脈を壊さないこと）。
   - 【原則3：親による共通統合と機械検査】複数ファイルから共有される設定・定数・目次ファイルの更新と、最終の構文・ビルド検証は必ず親エージェント1人が最後に一括実行すること。

AI の利用枠は「モデルのランクを落としてケチる」のではなく、「最上位モデルの頭脳をスリムなまま働かせる仕事の渡し方（アーキテクチャ）」 を整えるだけで驚くほど長持ちします。複数ファイルの監査でクォータ消費に悩んでいた方は、ぜひ「小部屋への並列分担」を試してみてくださいね！