---

GitへPushした20秒後に起きた500KiB切断事件

異変に気づいたきっかけは、新しいチャットセッションを立ち上げた直後に VS Code のソース管理パネル に表示された、身に覚えのない 2 件の変更マーク（M）でした。対象ファイルはプロジェクトの憲法である GEMINI.md と、サイト全体の規模定数を管理している src/consts.ts です。

前日の最終デプロイが途中でコケたのかと思い、Git のコミット履歴（git log）とファイルシステムの更新時刻（mtime）、さらに差分（git diff）を突き合わせたところ、予想外のタイムラインが浮かび上がりました。

正常コミットから20秒後に上書きされたタイムライン

実際のタイムスタンプとバイト数の変化を時系列で並べたものが以下のフローです。

正常 Push の 20 秒後に発生したサイレント切断と連鎖汚染の全時系列

Git へ完全な状態で Push 成功

コミット c3a08286 にて、全 1,272 行・515,618 バイト（503.5 KiB）の正常な GEMINI.md が origin/main へ完全保存される。

20秒後

Diff プレビュー終了時に上書き切断

エディタ拡張の変更承認・バッファ書き戻し処理が走り、ディスク上の GEMINI.md が 512,033 バイト（1,270 行）へ無警告で縮小上書きされる。

約14分後

SessionStart フックが破損値を同期

次セッション開始時の自動同期フックが「1,272 行 → 1,270 行に減った」と正直に読み取り、src/consts.ts の行数・容量定数まで書き換える。

発覚！

次回デプロイ直前で破損コミット阻止

未コミット変更の違和感から git diff を精査して切断を特定。Git 履歴の正常オブジェクトから 1 バイト完全一致で無傷復元を達成。

なんと、Git のリモートリポジトリ（origin/main）には 100% 無傷の GEMINI.md（515,618 バイト） がしっかり保存されていました。ところがその わずか 20 秒後（00:47:52）、AI の編集差分プレビューを閉じて確定するタイミングで、手元のディスク上の GEMINI.md だけが 512,033 バイト の切り詰められたデータで上書きされていたのです。

きっちり512,000バイトと33バイトの切り詰め文字列

「なぜ 512,033 バイトという中途半端な数字になったのか？」――ここを電卓で引き算した瞬間、すべての謎が一本の線でつながりました。実際に git diff GEMINI.md で検出されたファイル末尾の差分を見てみましょう。

--- a/GEMINI.md (HEAD: 515,618 bytes / 1,272 lines)
+++ b/GEMINI.md (Working Tree: 512,033 bytes / 1,270 lines)
@@ -1266,7 +1266,5 @@
-  - 1269行目の途中で日本語の文章が続いていた本来のルール記述（以降も末尾まで約 3.6 KB の重要仕様が続く）...
+  - 1269行目の途中で日本語の文章が続いていた本来のルー
+... [truncated for diff preview]

末尾に勝手に挿入されていた見慣れない英語の 1 行 \n... [truncated for diff preview] のバイト数を数えると、改行コード（\n：1 バイト）を含めて きっちり 33 バイト です。

さらに厄介なのは、この切り詰め処理が「UTF-8 の文字境界」だけは壊さないようにスライスした上で改行と ... [truncated for diff preview] を付け足している点です。文字化け（不正バイト列）や YAML の構文エラーが一切発生しないため、エディタも OS も Git も「人間が末尾を削って英語のメモを 1 行書き足した正常なテキスト編集」と誤認してしまい、エラー画面ひとつ出さずに通過してしまう のです。

気づかずに次回デプロイしていたら起きていた時限爆弾

もしこの小さな異変に気づかないまま、「次の記事を書いたからいつも通り自動デプロイ（git add . && git commit && git push）を回そう」と実行していたらどうなっていたでしょうか。

当サイトの自動同期フックは GEMINI.md の物理行数と容量を計測して src/consts.ts へ反映する仕組みだったため、1,272行（約504KB） → 1,270行（約500KB） への減少すら「正常なスリム化」として処理していました。そのまま次回コミットを実行していれば、せっかく c3a08286 で無事だった Git 履歴の上に「末尾 3.6 KB が吹き飛んだ破損版 GEMINI.md」が正式な最新コミットとして上書き記録される時限爆弾 だったのです。

なお、AI エージェントのターミナルサンドボックス内から急いで git restore GEMINI.md を叩くと、.git/index.lock の作成権限が制限されていて Operation not permitted で弾かれる場合があります。そのような環境でも、Git 公式の git show コマンド を使えば .git/ ディレクトリへロックファイルを一切作らずに、最新コミット（HEAD）の無傷な中身だけを標準出力経由で 1 バイト違わず救出できます。

# サンドボックス内で .git/index.lock を作らずに HEAD から無傷復元する安全コマンド
git show HEAD:GEMINI.md > GEMINI.md
git show HEAD:src/consts.ts > src/consts.ts

---

AIルール定義に立ちはだかる3つの容量上限と正体

Google Antigravity の VS Code 拡張機能 や Cursor、Claude Code などの AI コーディング環境を使い込んでいると、プロジェクトの成長に合わせて 段階的にまったく別の容量制限（ハードリミット） にぶつかります。

当サイトが公開 85 本の時代から現在の公開 707記事（総文字数 565 万字超）へ育て上げる過程で、実際に正面衝突して突破してきた「3 つの壁」を一覧表にまとめました。

段階	壁の種類と上限値	発生する現象・症状	当ラボで実装した突破アーキテクチャ
第1の壁	単一ルール注入上限 約 24,000 バイト（24 KB）	日本語で約 8,000 文字を超えると後半がプロンプト注入時に切り捨てられ、末尾のルールだけ AI に毎回無視される	常時必須のコア原則だけを 24 KB 未満のファイルへ自動抽出してインライン注入
第2の壁	常時注入の共通予算 合計約 20,000 トークン	分割ファイルを全部 always_on にすると予算超過で除外され、条件付き分割も目次ポインタだけで毎回約 3,000 tok を浪費する	条件付き分割ファイルを全廃し、常時コア 4本 以外は手元の Rust 検問と SQLite 検索へ完全オフロード
第3の壁 （今回）	Diff プレビュー上限 きっちり 512,000 バイト（500 KiB）	AI が 500 KiB 超の単一ファイルを編集した際、差分プレビュー用の省略文字列（... [truncated for diff preview]）が実ファイルへ逆流上書きされる	マスターを役割別に 2 冊分離 して上限から遠ざけつつ、Pure Rust ゲートで切断文字列と 500 KB 接近を物理検問

24KB上限と2万トークン予算に続く第3の500KiB壁

前回の 24KB 壁・2 万トークン予算の検証記事 で解説した通り、「AI に毎回送りつけるルール（.agents/rules/ 配下）」を合計約 43 KB（常時コア 4本）に絞り込み、残りの膨大な仕様は手元の Mac 側の SQLite 全文検索（kb-search）で必要な数十行だけピンポイント抽出する構成に変えたことで、「人間が管理するマスター GEMINI.md 自体は 200 KB でも 400 KB でも 1 ファイルのまま育てられる」 はずでした。

実際、499 KiB（511,999 バイト）までは何ひとつ問題は起きませんでした。ところが日々の仕様永続化によって単一ファイルのサイズが 500 KiB（512,000 バイト：日本語の Markdown で約 17 万〜 18 万文字相当） の一線をわずか 3.5 KiB 超えた瞬間、今度はプロンプト注入ではなく エディタ UI の差分プレビュー層 が牙を剥いたのです。

表示用の省略テキストが実ファイルへ逆流する構造欠陥

ソフトウェア工学の視点で見ると、今回の現象は典型的な 「View（画面表示用の軽量データ）と Model（ディスクへ永続化する実データ）の境界破壊バグ」 です。

500 KiB を超える巨大なテキストファイルの変更差分（Diff）を Webview やエディタパネル上で全行シンタックスハイライト描画しようとすると、UI スレッドが固まって画面がフリーズしやすくなります。そのため、プレビュー表示用のテキストを先頭 500 KiB で打ち切り、末尾に ... [truncated for diff preview]（差分プレビューのため省略）という案内ラベルを添える設計自体は理にかなっています。

どれだけクラウド上の AI モデル（Gemini 4 Argon 等）が正確にファイルを編集できても、手元のエディタ拡張が最後に上からハサミを入れてしまえば防ぎようがありません。だからこそ、「エディタ側のバグがいつか直るのを待つ」のではなく、自分のローカル環境側で物理的に踏み抜けない防波堤を築くこと が重要になります。

---

二度と再発させない2冊分離とPure Rust二重検問

原因が 512,000 バイトの閾値と特定できた以上、場当たり的な手動復旧で終わらせず、以下の 2 段構えで 「そもそも上限に近づけない構造改革」と「万一混入しても 0.1 ミリ秒で叩き落とす機械検問」 を同時に実装しました。

500KiB 切断バグに対する旧運用と恒久防衛アーキテクチャの比較

500KiB 超過によるサイレント破損リスク

• 共通システム仕様と分野別の専門公理をすべて 1 つの GEMINI.md（503.5 KiB）へ詰め込み、Diff 上限を突破

• プレビュー切断文字列（... [truncated for diff preview]）が混入しても構文エラーにならず素通り

• 自動同期フックが「行数が減った正常な更新」と勘違いし、consts.ts まで書き換えて汚染が拡大

180KiB 以上の安全余白＋即時ブロック

• 本編 GEMINI.md（約 326 KiB）と公理編 GEMINI_AXIOMS.md（約 179 KiB）へ無劣化で 2 冊分離

• コード枠外に切断文字列が 1 行でも混入したら、同期を緊急停止してデプロイを exit 1 で物理遮断

• 単一ファイル 450 KiB 到達で事前分割 Warning、500 KB（500,000 バイト）超過で強制 Error ロック

本編326KiBと公理編179KiBへの無劣化2冊分離

まず考えたのは、「500 KiB を避けるために、昔のように 20 個の細かいファイルへバラバラに分割すべきか？」という点です。しかしファイルを細切れにすると、人間が全体像を読むときにファイル間を行ったり来たりする羽目になり、「唯一の真実（Single Source of Truth）」としての見通しが悪化してしまいます。

そこで GEMINI.md の章別バイト数を計測したところ、驚くほどきれいな境界線が見つかりました。

なお、500 KiB 超の日本語ファイルをエディタ上で手動カット＆ペーストして分割しようとすると、今度は読み取りチャンク境界でのマルチバイト文字欠けや改行コードのズレを招く恐れがあります。そのため、Pure Rust ゲートキーパー自身に Rust 標準の UTF-8 文字列スライス保証 を使った --split-axioms サブコマンドを組み込み、抽出前後の公理テキストが 1 バイトの狂いもなく完全一致することを機械検証した上で分割を実行しました。

さらに続編として、こうして 2 冊に分離した GEMINI.md・GEMINI_AXIOMS.md や進捗管理 TODO 群を見出し階層ツリー・構造化台帳として SQLite へ分解し、参照・追記時のファイル読込量を最大約 99% 削減した実装記録は『CLAUDE.md・GEMINI.md・TODO丸読みの罠｜SQLite階層目次で読込99%減の実測録』にまとめています。

コード枠内の解説例示を誤検知しないRust検問ロジック

2 冊に分けて容量に余裕ができても、「将来また別の長大ファイルや記事で 500 KiB に近づいたらどうするのか」「もし別のタイミングで ... [truncated for diff preview] が混入したらどう止めるのか」という機械的な防波堤が欠かせません。

ここで 1 つ、実装上の重要な落とし穴（エッジケース）があります。もし検問プログラムを単純な部分一致（content.contains("... [truncated for diff preview]")）で書いてしまうと、今まさにあなたが読んでいるこの解説記事のコードブロック（差分例示）まで「破損ファイルだ！」と誤検知してデプロイを止めてしまう（偽陽性バグ） のです。

そこで tools/gemini-gate/src/rules_sync.rs および scanner.rs には、CommonMark 仕様のコードフェンス（``` および ~~~）の開閉状態を正確に追跡し、「コードブロックの外側に独立行として出現した本物の Diff 切り詰め行」だけを 100% 狙い撃ちする状態機械関数 を実装しました。

pub const DIFF_PREVIEW_TRUNCATION_LINE: &str = "... [truncated for diff preview]";
pub const SINGLE_RULE_FILE_WARN_BYTES: usize = 460_800; // 450 KiB で事前分割警告
pub const SINGLE_RULE_FILE_MAX_BYTES: usize = 500_000;  // 512,000 bytes 到達前に物理遮断

/// フェンスコードブロック内の解説例示を除き、本物の Diff 切断行だけを検知して行番号を返す
pub fn detect_diff_preview_truncation(content: &str) -> Option<usize> {
    let mut in_fence: Option<(char, usize)> = None;
    for (idx, raw_line) in content.lines().enumerate() {
        let line = raw_line.trim_end_matches('\r');
        let trimmed_start = line.trim_start_matches(' ');
        let leading_spaces = line.len() - trimmed_start.len();

        if let Some((fch, flen)) = in_fence {
            let cnt = trimmed_start.chars().take_while(|&c| c == fch).count();
            if leading_spaces <= 3
                && cnt >= flen
                && trimmed_start[cnt * fch.len_utf8()..].trim().is_empty()
            {
                in_fence = None;
            }
            continue;
        }
        if leading_spaces <= 3
            && (trimmed_start.starts_with("```") || trimmed_start.starts_with("~~~"))
        {
            let fch = trimmed_start.chars().next().unwrap_or('`');
            let cnt = trimmed_start.chars().take_while(|&c| c == fch).count();
            let info = trimmed_start[cnt..].trim();
            if !info.contains(fch) {
                in_fence = Some((fch, cnt));
                continue;
            }
        }
        if trimmed_start.trim_end() == DIFF_PREVIEW_TRUNCATION_LINE {
            return Some(idx + 1);
        }
    }
    None
}

この関数を軸として、以下の 3 重の物理フェイルセーフ を gemini-gate の自己診断テスト（全 59 項目・実行時間 約 250 ミリ秒）へ組み込みました。

AI にツールや自動検問ゲートを作らせるとき、Python や JavaScript のような動的スクリプトではなく、最初から文字境界・メモリ安全性・高速性をコンパイラが保証してくれる Rust を選んでおくと、こうした状態機械ガードも外部ライブラリ依存ゼロ・数ミリ秒で動く一生モノの資産になります。AI が出力した Rust コードの所有権やスライス境界の仕組みを手元で体系的に辞書引きしたい方には、定番の決定版である オライリー・ジャパン『プログラミングRust 第2版』 が 1 冊あると非常に心強いです。

---

まとめ：AI任せの自動化こそ機械の防波堤で守ろう

AI エディタと最上位モデルの進化によって、個人でも数百万字規模のメディアや何万行ものシステムを驚くようなスピードで育てられる時代になりました。しかしその裏側では、今回のような 「24 KB の単体ルール上限」「20,000 トークンの常時予算」「500 KiB（512,000 バイト）の Diff プレビュー書き戻し切断」 といった、ドキュメントの片隅にも大きく書かれていないツール側の物理上限が思わぬタイミングで顔を出します。

1日約131円の母艦投資で守る565万字の知識資産

当サイトのように、RAM ディスク上に常駐させた Pure Rust の検問バイナリ（gemini-gate）と 1GB 超の SQLite 知識・会話履歴データベース（kb-search）を毎ターン数ミリ秒で連携させ、クラウド AI のトークン消費を抑えながら無事故で高速運用し続けるには、手元の Mac 母艦のメモリ余裕がそのまま快適さに直結します。

推論（試算）として、たとえば約 24 万円クラスの 64GB ユニファイドメモリ搭載機を導入して 5 年間（1,825 日）毎日開発や執筆に使い倒した場合、1 日あたりの快適コストは約 131 円（缶コーヒー 1 本分） です。スワップ発生による動作のもたつきや SSD 摩耗を気にせず、ローカル検問ゲートと AI エディタを余裕たっぷりに常駐させる母艦としては、好きな大画面モニターと組み合わせられる Apple Mac mini（Pro系チップ・64GBユニファイドメモリ構成） が抜群のコストパフォーマンスを発揮してくれます。

自分のルール定義を500KiB罠から守る診断プロンプト

最後に、ご自身のプロジェクトで育てている GEMINI.md や AGENTS.md、CLAUDE.md、あるいは長大な仕様書ファイルが「3 つの容量上限（24 KB / 20,000 tok / 500 KiB）」に引っかかっていないかを一発で点検し、安全なガードを組み込ませるためのコピペ用プロンプトを用意しました。

モデルの思考力不足による誤判定や雑なファイル分割事故を防ぐため、必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル（Thinking / High 設定） を選択し、以下の枠内をコピーして貼り付けてみてください。

私のプロジェクトにある AI ルール定義ファイル（GEMINI.md / AGENTS.md / CLAUDE.md / .cursorrules / .agents/rules/* 等）および長大な Markdown・仕様書ファイルが、エディタ側の容量上限や Diff プレビュー切り詰めバグのリスクを抱えていないか診断・防衛設計を行いたいです。

まず以下の実測検証記事を読み込み、3つの容量の壁（①単一ルール24,000バイト上限、②常時注入20,000トークン予算、③単一ファイル512,000バイト［500 KiB］超過による `... [truncated for diff preview]` 書き戻し切断バグ）と対策構造を正確に把握してください。
https://lab.chihouzakki.com/blog/review/ai-editor-500kb-diff-truncation-trap-rust-guard/

【厳守してほしい手順】
1. いきなり既存ファイルを分割・書き換えせず、まずワークスペース内のルールファイル・仕様書・記事ファイルの UTF-8 バイト数一覧と、ワークスペース内に `... [truncated for diff preview]` の混入残骸が1件もないかを調査して報告してください。
2. 450 KiB（460,800 バイト）に近づいている単一ファイルがある場合は、人間の可読性を損なわない「役割境界での2冊分離案」を提示してください。
3. デプロイや Git コミット前に「コードフェンス内の例示を除いた切り詰め文字列混入」および「単一ファイルの 500,000 バイト超過」を機械的にブロックする軽量チェックの実装計画を提示し、私と合意してから実装に入ってください。

せっかく何ヶ月もかけて AI 相棒と一緒に育て上げた「プロジェクトの憲法」が、ある日こっそり尻切れトンボになってしまわないよう、ぜひファイルサイズが 500 KiB の壁に届く前に機械の防波堤を整えておいてくださいね！