結論と実測検証盤：データ急増でも通信は減らせる

まずは百聞は一見にしかずということで、連続 32 日間・全 33,658 回の API コールと Git 全 1,003 コミットの実測データをそのまま閉じ込めた インタラクティブ検証盤 をご覧ください。上部の 4 つのタブやグラフ内のモード切替ボタンを押したり、日別の折れ線グラフにカーソル（スマホではタップ）を合わせたりすると、各日にどんな仕組みを導入して数値がどう動いたかを直接確認できます。

実測期間: 2026/10/05 〜 2026/11/05（連続32日間・欠損ゼロ）

Macローカルオフロード機構・1ヶ月実測インタラクティブ検証盤

全 849 会話・33,658 回の TPU API コール（会話DB Protobuf ＆ トランスクリプト生ログ）＋ Git 全 1,003 コミット完全集計

総プロンプト処理量:37.84 億 tok

うちKVキャッシュ再利用:34.10 億 tok (90.1%)

うち新規TPU送信(inTok):3.74 億 tok (9.9%)

① Macが抱える総知識データ規模

約 330 倍 (3.3MB → 1.09GB)

記事 313→633本(5.55倍MB)、GEMINI.md 19.2→436.3KB(22.7倍)＋SQLite索引 1,090MB をローカル保持。

② 毎ターン新規TPU送信量 (同一モデル)

▲37.9% 削減 P90は ▲53.0%

親会話2ターン目以降の平均新規送信が 15,060→9,353 tok（11/05単日は 7,361 tok）、P90が 40,502→19,017 tok へ半減。

③ 1ターン平均処理時間 (同一モデル)

▲39.6% 短縮 (31.5秒 → 19.0秒)

4万tok超の丸読み(平均61.4秒)を潰し、Rustミリ秒検索で 2k〜5k tok帯(平均18.8秒)に収めたことでTPU応答自体が高速化。

④ 記事1タッチあたり新規トークン燃費

約 1/3 に圧縮 (98k → 27k〜36k)

分割ルール丸読みも ▲94.9%消滅(6.87→0.35回/100call)。計測時の公開626記事(現在627記事)検問はRust 337.5ms・出力50tok(99.999%オフロード)。

📈 1. データ膨張 vs TPU送信量（32日間） ⚙️ 2. 導入6フェーズ前後比較 ⚡ 3. 処理時間の物理構造（Mac × TPU） 📋 4. 全32日間・日別実測データ表

「扱うデータ量」の急膨張と「TPU新規送信データ量」の逆転（デカップリング）

グラフ上の各日をタップ／ホバーすると、その日の実測値と導入イベントを確認できます。

GEMINI.md容量 vs 新規送信tok KVキャッシュ率 vs サイクル秒数 ローカル検索 & Rust検問数

10/16〜10/19: 16GB RAMDisk全面化 ＆ 大型推論モデル(Argon)へ移行

10/22: sync_gemini_rules.mjs（2万tok常時注入予算の自動分割）導入

10/27: SQLite kb_query.mjs ＋ Hooks ＋ article_toolkit 導入

11/02〜11/04: Pure Rust gemini-gate ＆ SIMD kb-search ＋ 丸読み完全廃止

仕組み導入6ステージ精密比較（モデル切替バイアスを分離した純粋評価）

※10/17以前は旧モデル（Gemini 3.1 Pro / Flash系）中心、10/18以降は大型推論モデル（Gemini 4 Argon High）へ一本化されています。同一モデル（S1 → S5）で比較することで、Mac側オフロードの純粋な効果が明確になります。

① なぜMacで絞るとTPU自体が速くなるのか？（実測 13,442 コール）

同一モデル（Argon High）のProtobufナノ秒記録から算出した新規送信トークン帯域別のTPU総推論時間です。丸読み（4万tok超）を排除して 2,000〜5,000 tok 帯に収めるだけで、平均待ち時間が 61.4秒 → 18.8秒（約 1/3）に短縮されています。

② Macローカル側（16GB RAMDisk × Pure Rust）の実測速度と圧縮率

決定論的な検索・文字数計算・書式検査・リンク網グラフ照合をネイティブ機械語バイナリへ委託し、数十〜数千トークンの結論だけをTPUへ渡しています。

🛡️ Pure Rust 憲法ゲート（計測時の公開626記事［現在627記事］＋5,209リンク検問）337.5 ms

対象 16.04 MB（約500万tok相当） → 正常時のTPU出力: 177 bytes（約50 tok = 99.999%オフロード）

⚡ Pure Rust 憲法ゲート（編集直後 Hook 単一記事検問）68.1 ms

見出し文字数・太字境界・ハングル混入・商品ID・画像寸法まで即時判定し、手戻り再送ループを遮断。

🔍 Pure Rust SIMD 検索（知識DB 353.5 MB 横断セクション検索）14.0 ms

全 7,382 セクションから該当行番号と前後スニペットのみ抽出（約 2,500 tok のみ TPU へ供給）。

💬 Pure Rust 会話履歴検索（対話DB 736.4 MB / 2,501会話全文検索）41.6 ms

数億トークン規模の過去ログから必要箇所（約 1,800 tok）だけを 0.04 秒でピンポイント抽出。

全32日間・日別実測ログ一覧（2026/10/05 〜 2026/11/05）

※列見出しをクリックすると昇順・降順で並び替えできます

日付 ▾	APIコール	新規送信合計	親・平均新規/call	KVキャッシュ率	ターン中央値	記事数	GEMINI.md	kb検索	Rust検問	主な出来事・フェーズ

仕組み導入前後で逆転した主要実測スコア

検証盤のデータをひと目で振り返れるよう、大型推論モデル 『Gemini 4 Argon (High)』 に一本化した後の「素のファイル丸読み期（S1：10/18〜10/22）」と、「SQLite 索引・Pure Rust 検問・分割丸読み廃止まで完了した後（S3〜S5：10/27〜11/05）」の主要指標を比較表にまとめます。

実測評価項目	導入前：素の丸読み期（10/18〜10/22）	導入後：ローカルオフロード完成期	変化率・物理的な意味
手元の総知識データ規模	記事 392〜446 本 / DB なし	記事 633 本 ＋ SQLite 1.09GB	10/05 初期（3.3MB）比で 約 330 倍に拡大
設計書 GEMINI.md 容量	79.4 KB 〜 141.6 KB	436.3 KB（10/05 初期は 19.2 KB）	初期比 22.7 倍 の知見を蓄積しつつ常時注入は固定
親会話 2 ターン目以降の新規送信	平均 15,060 tok / 回	平均 9,295〜9,353 tok（11/05 は 7,361 tok）	毎ターンの新規 TPU 送信を ▲37.9〜38.3% 削減
大量読込スパイク（Step2+ P90）	40,502 tok（10/21 は 41,220 tok）	19,017 tok（11/05 単日は 12,276 tok）	クォータを溶かす巨大丸読みが ▲53.0% 半減
分割ルール手動丸読み頻度	6.87 回 / 100 コール（S3 期）	0.35 回 / 100 コール（S5 期）	20KB 分割チャンクの無駄読みが ▲94.9% 消滅
1 ターン平均サイクル時間	31.46 秒	19.00 秒（S3 期）／ 20.75 秒（S5 期）	待ち時間を ▲34.0〜39.6% 短縮（約 11〜12 秒減）
記事 1 タッチあたり新規トークン	約 98,000 tok（初期平均）	約 27,000〜36,000 tok	同じ 1 記事を直す燃料消費を 約 1/3 に圧縮

なお、32 日間の累計プロンプト処理量は 37.84 億トークン（3,783,841,000 tok） に達していましたが、そのうち 90.12% にあたる 34.10 億トークンはクラウド側の KV キャッシュ再利用 で賄われており、実際に Mac から新しく送り込んで計算させた新規トークン（input_tokens）は 3.74 億トークン（9.88%） に抑え込まれていました。

---

どうやって測ったか：会話DBのバイナリ生ログ解剖

「1 ヶ月前の古い会話まで、どうやって 1 トークン単位で正確に測れたの？文字数からの推測じゃないの？」と疑問に思われたエンジニアの方もいらっしゃるかもしれません。実は今回の調査でも、最初は大きな壁にぶつかりました。

古い会話ログの欠損を突破したバイナリ解析

AI エディタが出力するテキスト形式の会話記録（transcript.jsonl）を確認したところ、2026 年 10 月 18 日より前の古いログには input_tokens などのトークン統計欄が書き出されていなかった のです。これでは仕組みを入れる前の初期状態と比較できません。

そこで諦めずに、SSD 側へ自動退避していた会話アーカイブ（_gemini_history/conversations_archive/*.db）の中身を SQLite で直接解剖しました。すると、steps テーブルの metadata 列に保存されている Protocol Buffers（Google 開発の高速バイナリ直列化形式、以下 Protobuf）の生のバイト列（BLOB） の中に、初期から現在まですべての API コールの正確な計測値が刻まれていることを突き止めました。

さらにこの input_tokens が本当に「差分送信量」なのかを裏付けるため、連続するステップ間で検算を行ったところ、あるターンで input_tokens: 25,777 ＋ cache_read_tokens: 34,236 ＝ 合計 60,013 だった直後のターンで、cache_read_tokens がピタリ 60,014（制御境界 1 トークン加算） になるという数学的な完全一致を確認できました。つまり本記事の数値は、文字数からの概算や推論を 1 ミリも含まない 100% 実測の確定値 です。

モデル切替の罠を分離した純粋な前後比較

もうひとつ、データ分析で絶対にやってはいけないのが 「途中で AI モデル自体が変わった影響」と「手元の仕組みを変えた影響」をごちゃ混ぜにしてしまうこと です。

生ログのモデル識別番号（modelId）を時系列で追跡すると、10 月 17 日までは軽量・旧世代モデル（1016：Gemini 3.1 Pro 系 ／ 1318：Flash 系）が中心でしたが、10 月 18 日から大型推論モデル『Gemini 4 Argon (High)』（modelId = 1417）へ全面移行 していました。

• 旧モデル期（S0：10/05〜10/17） : 1 ターン平均 14.37 秒 と軽快ですが、複雑な複数ファイル改修では見落としが出やすい時期でした。

• Argon 移行直後の丸読み期（S1：10/18〜10/22） : 深い内部思考（Thinking）を行う大型モデルに切り替えた直後、手元の検索基盤がまだ無かったためファイルを次々丸読みし、1 ターン平均 31.46 秒、親会話 2 ターン目以降の平均新規送信も 15,060 tok まで跳ね上がりました。

• オフロード完成期（S3〜S5：10/27〜11/05） : 同じ modelId = 1417（Argon High）のまま、手元の SQLite 索引と Pure Rust 検問を整えた結果、高い推論品質を維持したまま 1 ターン平均 19.00〜20.75 秒、新規送信 9,295〜9,353 tok（11/05 単日は 7,361 tok） へと劇的に改善しました。

---

なぜ速くなるのか：TPUプリフィル演算と手元検索の差

では、なぜ手元の Mac でデータを絞り込むと、光回線の向こう側にある Google のクラウド TPU の処理時間まで 10 秒以上も速くなるのでしょうか。「どうせ 2 ターン目以降は KV キャッシュが 90% 効くんだから、ファイルを丸読みしても同じでは？」という疑問に対する物理的な答えがここにあります。

新規送信4万トークン超で待ち時間が3倍に跳ねる理由

大規模言語モデル（LLM）が返答を作る工程は、大きく分けて ①プリフィル（Prefill：新しく届いた入力トークン全員の相互関係を一斉に行列計算して KV キャッシュを作る初期工程） と、②デコード（Decode：1 トークンずつ順番に言葉を紡ぎ出す生成工程） の 2 段階で構成されています。

既読の会話履歴はクラウド TPU の超高速メモリ（HBM）上の KV キャッシュから一瞬で読み出せますが、そのターンに新しく read_file 等で読み込んだ生テキスト（未キャッシュの input_tokens）だけは、必ず TPU の演算器を総動員してゼロからプリフィル演算を行わなければなりません。

実際に同一モデル（modelId = 1417）の全 13,442 コール を「そのターンに新規送信したトークン数」の帯域ごとに分類し、クラウド TPU の総推論時間を集計した結果がこちらです。

新規送信トークン帯（input_tokens）	実測コール数	TPU 平均総推論時間	TPU 中央値	最初の応答待ち（TTFT 中央値）	現場で起きている典型パターン
2,001 〜 5,000 tok（ピンポイント帯）	7,959 回	18.79 秒	11.29 秒	9.21 秒	kb-search で該当 30 行だけ抜粋した理想状態
5,001 〜 15,000 tok（中規模読込帯）	3,184 回	25.44 秒	13.66 秒	9.57 秒	記事 1 本または中規模コードの編集ターン
15,001 〜 40,000 tok（丸読み 1〜2 本帯）	1,631 回	36.40 秒	13.91 秒	10.67 秒	20KB 分割ルールや長文記事を丸読みした状態
40,001 tok 以上（大量スパイク帯）	667 回	61.42 秒	21.88 秒	11.06 秒	複数記事の全文読込や巨大ログが流入した状態

ファイルを丸読みさせる開発 vs Mac手元で絞ってからTPUへ届ける開発

改善前（S1期）

素のファイル丸読み（40,000 tok 超スパイク頻発）

探している記述を見つけるために AI が 20KB のルールや長文記事を何本も全文読み込み。そのターンに 平均 61.42 秒 待たされるだけでなく、読み込んだハズレ全文が以降の全ターンで文脈に居座り続け、キャッシュ期限切れのたびに再計算コストが爆発します。

改善後（S3〜S5期）

Macミリ秒検索＋差分送信（2,000〜5,000 tok 帯）

手元の SQLite 索引と Pure Rust CLI が 14〜42 ミリ秒 で該当行だけを特定し、必要な数十行のみを TPU へ送信。プリフィル演算が最小化されるため、同じ Argon High でも 平均 18.79 秒（約 3.27 分の 1 の待ち時間） でサクサク返答が戻ってきます。

つまり、4 万トークン超の丸読みスパイクを潰して 2,000〜5,000 トークンのピンポイント帯に収めるだけで、クラウド TPU の平均待ち時間は 61.42 秒から 18.79 秒へと約 3 分の 1 に激減 するのです。

クラウドへ送る前に絞るMac側の4層オフロード

この「知識データは 330 倍に増やしながら、TPU への新規送信は最小限に抑え込む」状態を作るため、手元の Mac（64GB メモリ搭載母艦）に構築したのが以下の 4 層ローカルオフロード構造 です。

Mac母艦（64GBメモリ）上で稼働する4層ローカルオフロード構造

第 1 層：記憶装置の高速化（10/16〜）

16GB APFS RAMディスク常駐 ＆ 3日自動アーカイブ

ビルド一時領域・キャッシュ・Rust 実行バイナリ・直近 3 日分の会話ログをすべてメインメモリ上の仮想ドライブ（/Volumes/RAMDisk）に配置。SSD への細かな読み書き待ちを物理的にゼロにしています。

SSD摩耗ゼロ・I/O待ちゼロ

第 2 層：常時注入予算の固定（10/22〜11/05）

約445KBの『GEMINI.md』常時コア抽出と分割送信廃止

22.7 倍（11/05 計測時 436.3KB、現在は約445KB）に育った設計書のうち、毎ターン自動注入するコア原則だけを4本のファイルへ自動抽出し、残りの公理・技術仕様は条件付き分割ファイルの出力自体も全廃（0本）して索引からの行範囲取得のみへ切り替えました。結果として分割ファイルの手動丸読みは 94.9% 消滅 し、毎セッション約 3,000 トークンの隠れポインタ送信もゼロになりました。

毎ターンの固定枠を厳格保護

第 3 層：ミリ秒ピンポイント検索（10/27〜11/03）

SQLite FTS5 全文索引 × Pure Rust『kb-search』

全 633 記事ファイル（計測時の下書き含む総 MDX 数・現在公開627記事、7,382 セクション・内部リンク 5,209 本）を収めた knowledge.sqlite（353.5MB）を 実測 14.02 ミリ秒、過去 2,501 会話を収めた conversations.sqlite（736.4MB）を 実測 41.55 ミリ秒 で横断検索。AI には「何行目から何行目を読めばよいか」の座標だけを返します。

1.09GBから該当行だけ抽出

第 4 層：機械検問の完全オフロード（11/02〜）

Pure Rust 憲法遵守ゲートキーパー『gemini-gate』

文字数上限・太字スペース・リンク切れ・孤立記事・SHA-256 無改変証明など、AI が目視暗算すると膨大なトークンを食う検査をすべて Rust ネイティブバイナリへ移管。計測時点の全公開 626 記事（現在は公開627記事・約 500 万トークン相当）の一括検問を 337.5 ミリ秒 で終え、正常時は わずか 177 バイト（約 50 トークン＝99.999% オフロード） の合格証だけを AI に返します。

---

個人Macから見えた本質：末端と中央の役割分担

今回作成したトークン集計＆ダッシュボード出力ツール（scripts/generate_token_dashboard.mjs）は、一度きりの実験で終わらせず、いつでも npm run トークン集計:表示 の 1 コマンドで最新 32 日間の推移を更新・監査できるよう常設 CLI として組み込みました。実際に毎日回してみて分かった「手元オフロードでも残る注意点」も正直に整理しておきます。

手元オフロードでも残る3つの注意点と限界

社会インフラ全体に広げたときの通信と電力の未来

ここで少し視座を広げてみると、今回の 1 ヶ月・33,658 コールの実測データは、個人の開発環境にとどまらない非常に大きな示唆を含んでいます。

いま世の中では「AI 時代には巨大なデータセンターと原発何基分もの電力、そして際限のない海外クラウド課金が避けられない」とよく語られます。しかし今回の実測が証明した通り、末端（エッジ側）の端末に「正確な索引」と「決定論的な機械検問」を持たせ、中央の巨大 TPU には「高度に圧縮された本質的な推論だけ」を送る構造 を組めば、扱う知識量が 330 倍に増えてもクラウド通信量は約 4 割減り、推論待ち時間も約 3 分の 1 に縮まります。

個人の Mac 1 台ですらこれだけの差が出るのなら、もし自治体・医療・物流・行政といった社会全体のシステムで「何でもかんでも生データのまま中央クラウドへ丸投げする無駄」をやめ、手元の軽量推論チップ（LPU 等）と中央の大型基盤を階層的に連携させたら、国全体の通信帯域・電力消費・海外クラウドへの富の流出はどれほど劇的に改善できるでしょうか。

こうした「個人環境の実測から見えた、末端エッジと中央クラウドの最適な役割分担」を国家スケールの通信・計算インフラ設計へそのまま昇華させた構想については、別記事の ハイブリッド推論メッシュとLPU分散基盤の設計書 で詳しく掘り下げていますので、技術と社会のつながりに興味がある方はぜひあわせて覗いてみてください。

---

まとめ：64GB母艦の快適コストとAI自動計測手順

連続 32 日間・全 33,658 回の API コール生ログから判明した結論を改めて整理します。

缶コーヒー1本分で24時間AIを働かせる投資価値

今回のように 「16GB の RAM ディスク」＋「1.09GB の SQLite 全文検索 DB のオンメモリ保持」＋「Pure Rust の並列コンパイルと毎ターンミリ秒検問」 をスワップ知らずで涼しい顔をして回し続けるには、やはり 64GB メモリを搭載した Mac 母艦 と 高速な Thunderbolt 外付け SSD（コールドアーカイブ退避用） の組み合わせが抜群の安定感を発揮します。

一見すると 64GB メモリ構成の母艦や上位の AI プランは初期費用・月額費用が大きく見えるかもしれません。しかし推論（試算）として、たとえば約 24 万円クラスの 64GB メモリ搭載 Mac を 5 年間（1,825 日）毎日相棒として使い倒した場合、1 日あたりの機材コストは約 131 円（缶コーヒー 1 本分、1 日 4 時間作業なら 1 時間あたり約 33 円） に過ぎません。また、自分は手を動かさず設計判断だけに集中し、実務や検証を 24 時間 AI に働かせるタイム・イズ・マネーの視点で見れば、1 ターンごとに 12 秒ずつ奪われていた待ち時間とクォータ切れのストレスを根絶できるリターンは計り知れません（日々の壁打ち中心なら 5x 枠、本格的な開発や大規模サイト運用なら最上位の Ultra 20x 枠と組み合わせるとまさに鬼に金棒です）。

現行の Apple シリコン世代は購入後のメモリ増設ができないため、これから長く戦える新母艦を導入するなら、最初から大容量ユニファイドメモリを搭載した Apple Mac mini（Pro系チップ・64GBメモリ構成） が最もコストパフォーマンスに優れた本命機になります。

一方で、「広くて見やすい 27 インチ 5K Retina ディスプレイ一体型で、予算を抑えて 64GB 環境を組みたい」という方には、今回の 32 日間・33,658 コールの全実測を安定完走した現役母艦 Apple iMac 27インチ Retina 5K（2020年モデル・整備済／中古良品） に、背面パネルから工具なしで増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を挿す構成も現役で非常に頼もしい選択肢です（※ DDR4 SO-DIMM は Intel Mac 専用のため、Apple シリコン搭載機には装着できません）。

また、RAM ディスクから 3 日経過した会話アーカイブ（数 GB〜数十 GB の .db 群）を無劣化で高速退避・全文検索させる保管庫には、最大 3,000MB/s クラスの転送速度と高い放熱性を備えた SanDisk Professional PRO-G40 SSD（Thunderbolt 3 対応） を組み合わせるとバックアップ待ちが一瞬で終わります。そして手元の高速検索・検問ツールを自前で育てる際の心強い辞書として オライリー・ジャパン『プログラミングRust 第2版』 が 1 冊手元にあると、バイナリ解析やメモリ安全性の理解が一段と深まります。

最上位AIに自分の環境のトークン推移を測らせる手順

最後に、「自分の PC に溜まっている AI エディタの会話ログからも、トークン消費量や待ち時間の推移を可視化してみたい！」という方へ、安全かつ確実に構築するための実践手順をお伝えします。

会話アーカイブ内の SQLite や Protobuf バイナリの解析、そしてモデル切替時期の分離集計は、軽量な AI モデルに曖昧な指示で丸投げすると、文字数からの適当な推計でごまかされたり、本番ファイルを誤って触られたりするリスクがあります。必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選択し、以下のプロンプトをそのままコピー＆ペーストして「まずログ構造の事前調査と計画の合意」から進めてみてください。