AIエージェントのトークン節約とSQLite直結術｜仕様書1コール化とCarbon並列監査で週間枠1%の実測録

AI エディタ（Antigravity / VS Code）で大規模なブログやシステムを開発していると、「AI が仕様書を確認するたびに検索とファイル読み込みの 2 往復を繰り返してトークンを浪費する」「上位モデルで一括監査を回すとあっという間に利用枠（クォータ）が溶ける」 という最大の障壁（ボトルネック）に直面します。

今回、週間枠のリセットまで残り 7 時間 42 分の時点で Google AI Ultra（20x）の週間残量が 19% 残っていたため、「リセットで消える前に、計算単価が 2 倍重い最上位モデル Gemini 4 Carbon (High) で重い一括監査を回して使い切ろう」と着手しました。その過程で発見した「1 手目の抜粋検索に約 3秒、続く AI の再推論と read_file に 11〜14秒（計 14〜17秒）を費やす 2 往復の無駄」を根絶すべく、1,049 行の詳細仕様書を SQLite から約 2.31ms（ツール実行全体でも約 1〜2秒）・1 ツールコールで章節ごと生行全文取得する Rust 改修（kb-search Rev. 2.7.0） を実装しました。

結論からお伝えすると、この Rust エンジン改修に加え、Gemini 4 Carbon (High) の 5 班並列サブエージェントによる未監査 22 記事の深層監査、計 20 記事のピンポイント修正、外部出典 105 本の死活照合、Playwright 実機検証、本番ビルド＆デプロイ（公開総数 747記事）までを 1 時間 6 分で完遂 したにもかかわらず、週間枠の消費はわずか 1%（19% → 18%）、5 時間枠の消費もわずか 7%（89% → 82%） で済んでしまいました。さらに直後の追試（第 2 弾）として Swarm 7 体並列（Carbon High ＋ Argon High）で計 51 記事の一斉強化・新規執筆・デプロイ を連続実行しても、週間枠の消費はわずか 2%（18% → 16%） に収まりました。本記事では、なぜ最重量モデルを並列稼働させても利用枠がほとんど減らなかったのか、その物理的な裏付け（エビデンス）と実装の全貌を公開します。

• AI自律開発の最適化7層総括｜設計書3層分離・SQLite・Rust・Swarmの全設計図 : 公開 747記事・設計書合算 1,345行 規模の環境を週間枠数%で回すための、設計書 3 層分離や単方向 SQLite 同期を含む 7 層アーキテクチャの全体像を解説しています。

• Google AI Ultraの5時間制限と週間制限の比率｜577記事監査で週間4%・5時間18%消費の実測録 : Google AI Ultra における「5 時間枠」と「週間枠」の容量比率（約 4.5 倍の法則）を、577 記事の一斉監査ログから実測した基準データです。

• Gemini Decision 1とRust・Carbonの3層検問｜1記事0.02円と4msの高速化実測 : ローカルの Pure Rust ゲート（4ms）と軽量判定 API Gemini Decision 1、そして最上位 Carbon を組み合わせた 3 層検問パイプラインの設計録です。

• AIのコード丸読みを防ぐSQLite構文木｜Astro・TS・Rustの関数行番号を2msで引く方法 : プログラムコード（.astro / .ts / .rs）の関数や構造体の行番号を SQLite から 2ms で引き当て、AI の無駄なファイル丸読みを塞いだ先行検証です。

• SQLiteはなぜMySQLより速い？WAL・FTS5とAstroで記事探索をミリ秒化した実装録 : 外部サーバー不要のローカル SQLite（WAL モード＋FTS5 全文検索）が、なぜ Astro 静的サイトと AI 知識ベースで圧倒的な速度を出すのかを解説しています。

• ChatGPT WalletとGoogle Wallet×Geminiの違い｜AI決済の仕組みと安全設定 : AI エージェントに決済や家計分析を繋ぐ最新機能の仕組みと、口頭の指示ではなくプログラム・物理キーで資産を守る安全設計を比較しています。

• AI エディタに読ませるルールや詳細仕様書（GEMINI.md / CLAUDE.md 等）が 1,000 行を超え、参照のたびにツール呼び出しが増えて困っている方

• 最上位推論モデル Gemini 4 Carbon (High) を使って複数記事や複数ファイルの厳密なファクト監査・修正を回したいが、利用枠の急減が怖い方

• Google AI Ultra（5x / 20x） の実践的な省燃費チューニングと、自分の開発環境へそのまま導入できる具体的な設計手順を知りたい方

1. 1 手目（スニペット検索：ツール実行 約 3秒 ／ SQLite 内部 11.31〜24.11ms） : ./scripts/run_kb_search.sh docs "1.3." や "2.3." を実行。SQLite 内部の検索自体は十数ミリ秒ですが、シェル起動を含めたツール完了までに 約 3秒 かかり、しかも開始行番号と 先頭 135 文字の抜粋 しか返りません。

2. 2 手目（AI の再推論＋read_file：追加で 11〜14秒 消費 ／ ローカル読込は数ミリ秒） : read_file によるローカル SSD / RAMDisk からのファイル読み込み自体は数ミリ秒（1 秒未満）で終わりますが、抜粋を受け取った AI（Gemini 4 Carbon）がサーバー側で「135 文字では規定の全文が分からないため、docs/GEMINI_MANUAL.md の該当行範囲を read_file しよう」と再推論して 2 手目を完了するまでに、実測で 11秒（1.3 節参照時：01:50:39 → 01:50:50）〜14秒（2.3 節参照時：01:52:55 → 01:53:09） が溶けていました。

• manual "<節番号|語句>" [--full] サブコマンドの新設 : 仕様書の章節番号（例：1.3 や 2.3）またはキーワードを指定すると、docs/GEMINI_MANUAL.md 等から該当セクションの 行番号付き生行全文 を切り詰めゼロで即座に出力する専用コマンドを追加しました。

• 既存コマンド（docs / rule / tree --full）の自動全文化 : AI が既存の ./scripts/run_kb_search.sh docs "1.3." や rule "2.3" を呼んだ場合でも、引数が章節番号パターンに一致した瞬間にスニペット表示から SQLite doc_sections の生行全文直結モード へ自動切り替えするスマート分岐を実装しました。

• SQLite 抽出は 2.31ms〜2.42ms、ツール実行全体でも約 1〜2秒 で完結 : 1,049 行の仕様書から特定章節の全文（19〜71 行・行番号付き）を抽出する処理が SQLite 内部でわずか 2〜3 ミリ秒（シェル起動込みの 1 ツールコール全体でも 約 1〜2秒）で完結するようになり、旧方式で毎回発生していた 2 手目の AI 再推論＋read_file の 11〜14秒（計 14〜17秒）が丸ごと 0秒 に消滅 しました。

1. Rust製 kb-search Rev. 2.7.0 の5ファイル実装と全129件の自己診断PASS : SQLite 1 コール生行全文直結機能の実装・ビルドに加え、Pure Rust 検問所 gemini-gate の自己診断テスト 76 件 と kb-search の自己診断テスト 53 件（計 129 件）をすべて一発 PASS させました。

2. 未監査差分22記事＋サイト全体注意3件の「Carbon 5班並列」深層監査 : 直近の未監査差分 22 記事 とサイト全体の注意項目 3 件 に対し、Carbon (High) の research サブエージェントを 5 班並列 で起動。5 大ハルシネーション類型（公的機関への虚偽帰属、指数・単位換算、法改正・統計年次、型番・年号の 1 文字違い、過去実測値の時点ロック）および独自試算への「推論」明記漏れを徹底監査しました。

3. 摘出10記事＋数値連動7記事＋注意3件＝計20記事のピンポイント修正 : 監査で摘出された 10 記事、SQLite impact 検索で芋づる式に特定した数値連動 7 記事、および注意 3 件 の 計 20 記事 をピンポイント改修しました。事実誤認ゼロと判定された無謬の 12 記事 は 1 文字も触れずに完全温存し、段落分割を行った記事は正規化 SHA-256 ハッシュの完全一致証明を実施しました。

4. 外部出典URL 105本のライブ死活照合＋Decision 1検品（キャッシュ35件ヒット） : 対象記事に含まれる外部出典 URL 105 本 の実ページ疎通・リダイレクト先検証を実行。さらに Gemini Decision 1 による画像 20 枚・記事 20 本 の自動検品を実施しました（ローカル SHA-256 キャッシュが 35 件ヒット したため、ライブ API の入出力トークンは 実質 0 トークン で通過！）。

5. Playwright 1コール統合検証と本番ビルド・SFTPデプロイ完遂 : browser_run_code_unsafe の 単一コール統合 により、通常の HTTP 取得では HTTP 403 に阻まれる外部サイトの隠れ 404 摘出と、本番公開 6 ページ の実機レンダリング検証（H1・目次・画像自然幅・横はみ出しゼロ）を実行。最終的な Astro 本番ビルドと Xserver への SFTP 転送まで完走し、監査時点の公開 744 記事（本記事を含めた現在の公開総数は 747記事）すべてで エラー 0 件・注意 0 件 を達成しました。

1. SQLite doc_sections 1コール直結（抽出2.31ms／2手目の11〜14秒をゼロ化） : 1,049 行の仕様書から必要な節だけを 1 ツールコール（シェル起動込み約 1〜2 秒）で取得し、従来 2 手目で発生していた AI 再推論＋read_file（11〜14秒 の待ち時間と約 7 万〜10 万トークンの再送信）を完全にゼロ化しました。

2. research サブエージェント5班の独立小コンテキスト分離 : 親エージェントが 22 記事の本文や 105 本の出典ページを直接読み込むと、親の会話履歴が雪だるま式（$O(N^2)$）に膨れ上がります。これを 5 班の research 子エージェントに 4〜5 記事ずつ排他分担させ、「生原稿と外部 URL の読み込みログは子エージェントの終了とともにメモリから破棄し、親には数百文字の構造化監査レポートだけを返す」 ことで、親コンテキストの KV キャッシュ効率を高水準に維持しました。

3. Pure Rust gemini-gate の4ms機械検問とSHA-256キャッシュ（35件ヒット） : 文字数・見出し・リンク整合のチェックをすべて 4 ミリ秒のローカル Rust バイナリへ肩代わりさせ、さらに Gemini Decision 1 の意味検品でも SHA-256 ハッシュキャッシュが 35 件ヒット したことで、ライブ API の入出力トークンを 0 トークン に抑え込みました。

4. Playwright browser_run_code_unsafe 単一コール統合 : 従来の「navigate → evaluate → close」の 3 分割呼び出し（毎ステップで巨大な DOM スナップショットがコンテキストへ流れ込む現象）を廃止し、1 つの非同期関数内でページ遷移から DOM 検査・クローズまで完結させる 1 コール統合を徹底しました。

1. Search Console 未登録 31 記事の Carbon 4 班並列強化 : Search Console APIによる非開示クエリ・インデックス自動診断基盤 で抽出した「クロール済み - インデックス未登録」12 件および「検出 - インデックス未登録」19 件の計 31 記事 を、Gemini 4 Carbon (High) の 4 ワーカーでファイル排他分割。既存の強みを 100% 温存したまま、検索意図の補強と一次出典インラインリンクの追加を完遂しました（なお、単純なローカル整形や事前マスキングには macOS 27標準のオンデバイスAIコマンド fm のような API 代 0 円ツールとの役割分担も有効です）。

2. 主力エース・ハブ 19 記事からの双方向内部リンク結線 : 未登録記事へのクローラー導線を太くするため、流入上位のエース記事および各部ハブ記事 19 本 に対し、テーマ整合性の高い双方向内部リンクを結線しました（ここまでで既存 50 記事 を改修）。

3. Swarm Argon High による新規記事執筆＋親 Carbon 監査（51記事目） : 第 1 弾の実測データをまとめた本記事の初稿（図解・グラフ・比較表を含む約 410 行）を長文執筆に強い Gemini 4 Argon (High) ワーカーに書き下ろさせ、親 Carbon (High) で一次事実の裏取り監査を実施しました。

4. 全公開記事の一斉ゲート検問・本番デプロイ・Playwright 実機検証 : 進行監視の monitor ワーカーを含む計 7 体体制で全工程を走り切り、全記事エラー 0 件での Astro 本番ビルド、SFTP 転送、Playwright browser_run_code_unsafe 単一コールでの本番表示検証まで完遂しました。

• Google AI Ultra 20x（月額 32,000 円目安）の場合 : 1 ヶ月（30 日）で割ると 1 日あたり約 1,067 円。毎日 8 時間、AI エージェントに開発・執筆・全記事監査を自律稼働させる場合、1 時間あたりの快適コストは約 133 円（推論・時間単価試算） です。今回の 1 時間 6 分の重労働（週間枠 1% 消費分）を金額換算すれば、わずか 約 80〜150 円相当（推論） のコストで人間なら丸 2〜3 日かかる 22 記事のファクト監査とシステム改修が終わった計算になります。

• Google AI Ultra 5x（月額 14,500 円目安）の場合 : 30 日換算で 1 日あたり約 483 円、1 日 8 時間稼働なら 1 時間あたり約 60 円（推論・時間単価試算） です。壁打ちや中規模のブログ・システム開発であれば、本記事の省燃費設計を取り入れることで 5x プランでも十分お釣りが来る強靱性（レジリエンス）を発揮します。

• 実行ログの直視による「2往復・計14〜17秒の無駄」の発見 : AI に性能を尋ねると「十分出ている」と答えがちですが、実際にチャット内のツール実行ログ（事実）を観察したことで、135 文字スニペットの不足分を補うために裏で禁止していた read_file が呼ばれ、1 手目（約 3秒）＋ 2 手目の AI 再推論・read_file（11〜14秒）で 合計 14〜17秒 を浪費していた構造を突き止めました。

• SQLite 1コール生行全文直結（kb-search Rev. 2.7.0） : 章節番号やキーワード指定時に SQLite の doc_sections テーブル等から行番号付き全文を SQLite 抽出 2.31ms〜2.42ms（ツール全体でも約 1〜2秒）・1 コール で直接返すよう改修し、2 手目の 11〜14秒 を丸ごとゼロ化するとともに未編集時の直接 read_file をフックで自動抑止しました。

• 1時間6分の重労働で週間1%・5時間7%消費 : 最上位モデル Gemini 4 Carbon (High) を用い、Rust 5 ファイル改修、22 記事の 5 班並列監査、20 記事修正、出典 105 本照合、Playwright 1 コール検証、本番デプロイまで完遂して 週間枠 19% → 18%（-1%）・5 時間枠 89% → 82%（-7%） という驚異の低燃費を実証しました。

• 追試のSwarm 7体・51記事改修でも週間2%消費 : 直後に実施した第 2 弾ストレステスト（未登録 31 記事強化＋ハブ 19 記事結線＋新規 1 記事執筆の計 51 記事処理）でも 週間枠 18% → 16%（-2%）・リセット後 5 時間枠 100% → 99%（-1%） に収まり、延べ 73 記事処理で累計わずか 3% という高い再現性を確認しました。

あなたは私の熟練した開発パートナーです。
まず以下の実機検証記事URL（またはその設計内容）を読み込み、当プロジェクトの現在のファイル構成・ルールファイル（GEMINI.md / CLAUDE.md / docs等）・スクリプト環境を事前調査してください。

【参照記事】
https://lab.chihouzakki.com/blog/review/sqlite-1call-manual-carbon-audit-1percent-quota-guide/

【実現したいゴール】
1. 長大な仕様書・ルールファイルを参照する際、「1手目の検索スニペット取得（約3秒） → AI再推論と2手目の read_file（11〜14秒）」という2往復が発生しないよう、SQLite（doc_sectionsテーブル等）から章節番号または見出し指定で「行番号付きの生行全文」を1ツールコール（数ミリ秒）で直接返す検索コマンドを整備すること。
2. 複数ファイルや複数記事の監査・調査を行う際は、親エージェントが直接ファイルを抱え込んでコンテキストを O(N^2) 膨張させるのを防ぎ、サブエージェント（3〜5班並列）に排他分担させて構造化要約のみを親へ返させる運用ルールを定義すること。
3. ブラウザ検証（Playwright等）や定型チェックを行う際は、複数回のツール分割呼び出しを避け、1コール統合またはローカルスクリプトへオフロードすること。

※いきなりファイルを書き換えず、また局所的な数値だけを見て「すでに十分性能が出ている」と自己判断せず、実際の検索コマンドの出力仕様とAIのツール呼び出し挙動という「事実」を調査した上で、裏で無駄な read_file や2往復が起きない実装計画（Implementation Plan）を提示し、私の合意を得てから実装を開始してください。