実測結論：週間枠4%と5時間枠18%が示した天井比率

開始時と終了時のクォータ画面2枚と稼働2時間40分

前回の 84 記事改修の検証 では、深夜から翌朝にかけて計測したため途中で「5 時間枠（Five Hour Limit）」の自然回復をまたいでしまい、週間枠の減少（2%）は測れたものの、「同じ作業量で 5 時間枠と週間枠が同時に何パーセントずつ減るのか」 までは直接比較できませんでした。

そこで今回は、5 時間枠のリセット残り時間がたっぷり 3 時間 47 分 残っている午前 09:14 時点からスタートし、一度もリセットを挟まずに午前 11:54 までの 2 時間 40 分一本勝負 で全 577 記事の 6 大監査・改修・本番デプロイまでを走り切りました。その開始時と終了時（更新アイコン ↻ クリック後）の実際の画面がこちらです。

まず画面内の「全回復までの残り時間（refresh timer）」を検算すると、未更新キャッシュではなくリアルタイムの確定値であることが 1 分単位でわかります。

クォータ指標	開始時 (09:14)	完了時 (11:54)	実測消費量	リセット残り時間の変化
Gemini 週間枠 (Weekly Limit)	36%	32%	-4%	22h 35m → 19h 56m（2 時間 39 分経過）
Gemini 5 時間枠 (Five Hour Limit)	96%	78%	-18%	3h 47m → 1h 07m（2 時間 40 分経過）
Claude & GPT 枠（週間 / 5 時間）	47% / 100%	47% / 100%	0%	純粋に Gemini 4 Argon のみで 100% 完遂

週間枠は5時間枠の約4.5倍！丸め誤差込みの厳密検算

同一のジョブに対して 5 時間枠が 18% 減り、週間枠が 4% 減ったということは、単純な中央値どうしの割り算で 「週間枠（100% 分）の総容量は、5 時間枠（100% 分）の 4.5 倍 に相当する」 計算になります。

もちろん、設定画面のパーセント表示は整数に丸められているため、厳密なデータ検証として 「小数点以下の丸め誤差（最大 ±0.5% 未満）」 まで考慮した理論区間も検算しておきましょう。5 時間枠の真の消費量を $\Delta F \in (17.0\%, 19.0\%)$ 、週間枠の真の消費量を $\Delta W \in (3.0\%, 5.0\%)$ と置くと、両者の容量倍率 $R$ は次の範囲に収まります。

両端の極端な丸めが同時に重なる確率は低いため、実態としては 「週間枠の総タンク容量は、5 時間枠のおよそ 4〜 5 倍（中央値で約 4.5 倍）で設計されている（推論・実測区間推定）」 と見るのが最も合理的です。この 2 階建て構造の意味を整理すると、Google 側の非常に巧妙な設計意図が見えてきます。

Google AI Ultra（Gemini枠）の2階建てクォータ設計

基準容量：1.0×

⏱️ 5時間枠（Five Hour Limit）＝ 短距離の安全弁

• 役割 : 無限ループ暴走や極端な短期集中負荷でデータセンターを占有し続けないための 5 時間ごとのペースメーカー。
• 今回の減り方 : 2 時間 40 分で延べ 7,716 万トークンを回して 18% 消費（1 回の 5 時間枠の中で今回の全サイト大改修を 約 5.5 回転 できる計算）。
• 回復速度 : 5 時間周期で 100% 全回復 するため、一息ついてコーヒーを飲んだり別作業をしている間にすぐ元通りになります。

総容量：約4.5×（中央値）

📅 週間枠（Weekly Limit）＝ 1週間の総タンク

• 役割 : 1 週間（168 時間）トータルで使える基礎体力。「5 時間枠を 100% 使い切る全力スプリントを週に約 4.5 回（平日ほぼ毎日 1 回ずつ）」 行うとちょうど 100% に達する絶妙な天井比率。
• 今回の減り方 : 全 577 記事監査・343 記事改修という超大型工事でも わずか 4% 消費。
• 実用上の余裕 : 単純計算で同じ規模の全サイト横断改修を 週に約 25 回 回せる圧倒的な余裕があります。

つまり、「普段の作業では 5 時間枠が先に底をつくことはまずなく、もし超大型の一括処理を半日で何連発も回して 5 時間枠が先に減っても、数時間休めば週間枠を温存したまま復活する」という非常に使いやすいバランスになっています。

---

延べ7,716万トークン！全577記事6大監査の全内訳

親1体と子16体で計598回呼び出した生ログ集計表

では、この「週間枠 4% ・ 5 時間枠 18%」の裏側で、実際にどれだけの AI エージェントが動き、何トークンを読み書きしていたのでしょうか。ローカルの /brain ディレクトリに保存されている親エージェント 1 体とサブエージェント 16 体（計 17 スレッド）の実行ログ（transcript.jsonl）から、完了スクリーンショット撮影時点（11:54 JST）までの全推論ステップを 1 トークン単位で合算した結果がこちらです。

実行グループ（すべて Gemini 4 Argon）	稼働数	総ステップ	モデル呼出	新規入力 (input)	キャッシュ読込 (cache_read)	出力 (output：思考＋編集)	キャッシュ率
親エージェント（全体統括・SEO/URL/画像・本番検証）	1 体	684	221 回	2,375,288	29,578,690	213,022	92.6%
Phase 1：文字の壁・無改変整形班（self）	5 体	808	133 回	1,568,822	14,765,511	419,979	90.4%
Phase 4：アフィ＆旧記事調査班（research）	3 体	327	73 回	1,178,545	6,847,713	104,302	85.3%
Phase 4：アフィTS＆2026鮮度注記班（self）	3 体	269	62 回	588,449	7,891,251	98,704	93.1%
Phase 5：AI国家定型句・定数統一班（self）	5 体	692	109 回	1,709,618	9,563,803	258,965	84.8%
総合計（親 1 体 ＋ 子 16 体 ＝ 17 体）	17 体	2,780	598 回	7,420,722（約742万）	68,646,968（約6,865万）	1,094,972（約109.5万）	90.2%

延べプロンプト読込量は 76,067,690 トークン（約 7,607 万）、AI が生成した思考・編集出力トークンだけでも 1,094,972 トークン（約 109.5 万）、入出力を合わせた延べ処理総量はなんと 約 7,716 万 トークン に達しています。しかも 16 体のサブエージェントは 1 体も途中エラーを起こすことなく 完遂率 100% で仕事を終えました。

わずか2時間40分で完遂した6大監査と343記事改修

「トークンがたくさん回ったのはわかったけれど、具体的にどんな中身を直したの？」という方のために、この 2 時間 40 分で実際に片付けた 6 つの監査・改修項目を整理します。単なる機械的な一括置換ではなく、1 記事ずつの文脈判断と厳格な機械証明を組み合わせた実務フルコースです。

---

前回より1.4倍省燃費化！キャッシュ90.2%を生んだ3技術

ここで前回の検証記録（84 記事改修）と今回の数字を並べて比較すると、非常に興味深い進化が浮かび上がります。

比較項目	前回（84記事改修）	今回（全577記事監査・343記事改修）	倍率・変化
実変更した公開記事数	84 記事	343 記事（＋TS 34件・画像110枚）	約 4.1 倍
総モデル呼出回数（Argon）	215 回（親1＋子7）	598 回（親1＋子16）	約 2.78 倍
新規入力トークン (input)	約 554 万	約 742 万	わずか 1.34 倍に抑制！
キャッシュ読込 (cache_read)	約 2,179 万	約 6,865 万	約 3.15 倍フル活用
キャッシュ再利用率	79.7%	90.2%	+10.5 ポイント向上！
Ultra 週間枠の消費量	2%（1%あたり約108回）	4%（1%あたり約150回）	呼出あたり約 1.4 倍長持ち！

仕事量（変更記事数）は 4.1 倍、モデル呼出回数も 2.78 倍 に増えているのに、クォータを一番削る「新規入力トークン（input）」は 1.34 倍 にしか増えておらず、結果として 週間枠 1% あたりで回せるモデル呼出回数が約 108 回から約 150 回へと約 1.4 倍も省燃費化 しています。この劇的な改善を生んだ技術的理由は大きく 3 つあります。

常時注入ルールの圧縮で毎回の基礎コストを大幅削減

1 つ目の勝因は、別記事で詳しく解説した Progressive Disclosure（段階的開示） によって、すべての親・サブエージェントが起動時に毎回読み込む常時ルール（GEMINI.md 分割群）を極限までダイエットしたことです。

以前は 20KB 単位の分割ルールや詳細な第 7 章公理をまとめて読み込ませていたため、サブエージェントを 1 体立ち上げるたびに初期プロンプトが大きくなっていました。現在は「全タスク共通の最小骨格と公理の目次（1 行インデックス）だけ」を常時注入し、詳細が必要なときだけローカル SQLite（kb_query.mjs）から該当節をピンポイントで引く構造に統一しています。その結果、17 エージェント・598 回の推論すべてでベースラインの入力コストが軽くなり、変更のない共通プレフィックスが 90.2% という極めて高い確率でキャッシュヒット しました。

Rust検問へのオフロードとShift_JISの罠

2 つ目の勝因は、「文字数を数える」「1 文字も変わっていないか照合する」「1,794 件の URL が生きているか調べる」といった 決定論的な検査を AI の脳（トークン）にやらせず、外部依存ゼロの Pure Rust 製ゲート（gemini-gate） へ完全にオフロードしたこと です。変更 343 記事と全 577 記事のリンク網・書式・無改変ハッシュ照合は、RAM ディスク上でわずか 約 2.1 秒 で完了します。

なお、今回 1,794 件の外部 URL をライブ通信検問にかけた際、実務ならではの 「日本の官公庁サイト特有の Shift_JIS 誤判定トラップ」 に遭遇し、その場で Rust 側のデコーダを改良する一幕がありました。

従来の高速デコード処理では、「全体の 95% 以上が有効な UTF-8 バイト列なら、通信切り詰め等で末尾だけ欠けた UTF-8 ページとみなしてそのまま読む」という近道判定を入れていました。ところが先頭 95% が ASCII だけの Shift_JIS ページがこの条件に引っかかり、iconv による CP932（Shift_JIS）変換ルートへ進む前に文字化け（“ 混入）として弾かれてしまったのです。

そこで Rust 側の decode_html_bytes 関数に以下の 3 重ガード を実装してセルフテスト（全 48 項目・約 62ms）へ組み込んだところ、全官公庁 URL の誤検知が一発で 0 件 になりました。

1. 文字コード宣言の最優先判定 : HTML 先頭ヘッダーに Shift_JIS / CP932 / Windows-31J / EUC-JP 等のレガシー宣言がある場合は、UTF-8 有効比率に関わらず無条件で iconv 変換ルートへ送る。
2. マルチバイト UTF-8 実在チェック : 宣言がない場合も、ASCII ではなく 「有効な非 ASCII マルチバイト UTF-8 文字が 12 バイト以上実在する場合のみ」 部分破損 UTF-8 と判定する。
3. 切り詰め境界の安全フラグ : 256KB 上限で HTML を切り詰めた際に末尾の 2 バイト文字が真っ二つに分断されても変換全体が失敗しないよう、iconv -c フラグで境界バイトを安全に保護する。

このように「AI が同じエラーで何度もリトライしてトークンを溶かす前」にローカルの Rust 検問器を賢くしていくことが、大規模運用でクォータを減らさない最大の秘訣です。

調査3班と編集13班を分けた多段階パイプライン並列

3 つ目の勝因は、16 体のサブエージェントを闇雲に同時起動するのではなく、フェーズごとに役割と対象ファイルを完全分離した多段階パイプライン で回したことです。

全577記事6大監査を2時間40分・週間4%で完走した4段階パイプライン

Stage 1

親による全体計測

SQLiteとRust検問で全577記事の警告739件をミリ秒特定し、重複ゼロの担当表を作成。

排他リスト配付

Stage 2

調査3班＋整形5班

読み取り専用の調査3班と、文字の壁5班が独立コンテキストで精読・SHA-256無改変分割。

構造化要点のみ返却

Stage 3

専門改修8班の並列

アフィ改修・2026鮮度注記3班と定型句統一5班が、担当記事だけをピンポイント編集。

全班完了後に統合

Stage 4

親の最終検問と転送

親1人で共通ファイル・画像WebP変換・Rust全件検問（違反0件）・本番転送・実機検証を完遂。

もし親エージェント 1 人だけで 343 記事を順番に開いて直していたら、後半には親の会話履歴が数百万トークンに膨れ上がり、1 回ツールを呼ぶたびに入力クォータが雪だるま式（$O(N^2)$ ）に溶けていたはずです。それを「1 班あたり 20〜 30 ファイル前後の小部屋」に切り分けたことで、各サブエージェントが常に軽快なコンテキストサイズ（キャッシュ率 85〜 93%）のまま走り切ることができました。

---

まとめ：5x・20xの快適コスト試算と全件監査プロンプト

5時間枠が先に減るケースと時間単価から見るプラン選び

今回の「5 時間枠 -18% ／ 週間枠 -4%（容量比 約 4.5 倍）」という実測値を使うと、月額 14,500 円の『Google AI Ultra 5x』と月額 32,000 円の『Ultra 20x』のどちらを選ぶべきか も、当て推量ではなく具体的な算数で見積もることができます。

過去の比較検証 の通り、Ultra 5x の利用枠は Ultra 20x の 約 4 分の 1（25%） です。したがって、今回の「全 577 記事 6 大監査・343 記事改修（延べ 7,716 万トークン）」という超大型ジョブをそのまま Ultra 5x で実行した場合の消費量は次のように推計できます。

• Ultra 5x（月額 14,500 円）で今回の 577 記事大改修を回した場合（推論） : 週間枠は 約 16% 消費、そして 5 時間枠は 約 72%（18% × 4）消費 する計算になります。つまり 5x でも 1 回で途中停止せず完走可能 ですが、同じ 5 時間以内に 2 回連続で回そうとすると「週間枠は 8 割残っているのに 5 時間枠が先に 100% 天井に当たる」という現象が起きます。逆に言えば、「こうした数百記事の大工事は 1 日 1 回まで（5 時間以上空ける）」というペースなら、月額 14,500 円（24 時間常駐換算で 1 時間あたり約 20 円・1 日あたり約 483 円［試算・推論］）の 5x でも十分に戦えます。
• Ultra 20x（月額 32,000 円）で運用する場合（実測＋試算） : 24 時間体制換算で 1 時間あたり約 44 円（1 日 8 時間の実働換算でも 1 時間あたり約 133 円［試算・推論］）です。今回のように人間が手作業で行えば丸 2〜 3 週間はかかる「343 記事の整形・1,794 リンクの通信確認・110 枚の画像最適化・本番実機検証」を、わずか 2 時間 40 分・実質クォータコスト約 1,280 円相当（32,000 円 × 4%［試算・推論］） で終わらせ、しかも直後にまだ 5 時間枠が 78% も残っているため、息継ぎなしで次の開発や執筆へ進めます。

誰かに見栄を張るための消費ではなく、「面倒でミスの許されない全件メンテナンスを 100% 自動検問付きで AI 軍団に任せ、自分はコーヒーを飲みながら方針を決める時間と自由を買う」 という使い方において、これほど費用対効果の高い投資はなかなかないと実感しています。

最上位AIに6大監査と無改変改修を任せるプロンプト

最後に、あなたの Astro ブログや Web サイトでも、記事数が増えてきたタイミングで 「クォータを浪費せず、かつ元の文章を 1 文字も壊さずにサイト全体の健全性を一括監査させるための指示プロンプト」 を共有します。

軽量モデル（Flash 系など）では排他分割や無改変ハッシュ照合の制約を読み飛ばす恐れがあるため、必ず『Gemini 4 Argon』（または同等以上の最上位推論モデル）を選択した上で、以下のプロンプトをコピー＆ペーストして使ってみてください。

https://lab.chihouzakki.com/blog/review/ultra-5hour-weekly-quota-ratio-577-audit/

上記の記事で実証されている「多段階サブエージェント排他並列 × ローカル決定論スクリプト検問」の設計を参考に、私のサイトの全公開記事に対する健全性監査と改善計画を作成してください。

【絶対条件：いきなり記事を書き換えず、まず読み取り専用で現状件数を計測して計画を提示すること】
1. ローカルスクリプトまたは読み取り専用サブエージェントを使い、親コンテキストを肥大化させずに以下の6項目を全件スキャンして該当件数を集計してください：
   - ① 外部出典・外部リンクの404エラーおよび「総合トップページURL逃げ」の件数
   - ② 被リンクが少ない孤立・準孤立記事（inbound 2本以下）の件数
   - ③ 商品リンクやアフィリエイト枠の検索ソート不備（安い順ソートによる互換品混入等）・設置漏れの有無
   - ④ スマホで読みづらい長文1段落（「文字の壁」：500文字超目安）の件数
   - ⑤ 過去に執筆した古い記事のうち、現在の料金・後継機種・制度変更の注記を添えるべき記事の件数
   - ⑥ 見出し書式崩れおよび未最適化（大容量・非WebP）画像の枚数
2. 改修を実行する際は、元の一次情報・文章表現を勝手に削らない「正規化ハッシュ一致確認（無改変分割）」と「編集対象ファイルの完全排他分割（競合ゼロ）」を組み込んだ段階的スケジュールを提示し、私の合意を得てから開始してください。

Google AI Ultra の 「5 時間枠と週間枠の約 4.5 倍の天井バランス」 を理解し、定型検問のローカルオフロードと排他並列パイプライン を組み合わせれば、500 記事を超える大規模サイトでもたった数パーセントのクォータでいつでも新築同様に磨き直せます。クォータの減り方が気になって大型メンテナンスをためらっていた方は、ぜひこの設計で快適な一括監査を体験してみてくださいね！