ブログ1記事の修正でAIは何回ファイルを読む？68回のDB照会と丸読み破産の実測録

人間の感覚からすれば、「公開済みのレビュー記事に、あとから撮影した実測写真を 1 枚追加して数行の解説を足すだけ」 というのは、ほんの 3 分で終わりそうなごく小さな修正作業に見えます。しかし、数百本の記事と厳格な表記ルール・商品辞書・内部リンク網を抱えるブログ環境において、AI エージェントが「過去記事や型番、システム設計と 1 bit も矛盾を起こさずに」その 1 枚の写真を組み込もうとしたとき、裏側では一体何回ファイルが読み書きされているのでしょうか。

今回、サーモス「真空断熱コーヒーサーバー TTF-720」実機レビュー に「朝 8 時頃にドリップしたコーヒーが、約 8 時間半後の 16 時 38 分でも 48.6℃ を維持していた温度実測写真 1 枚」を追記し、その過程で見つかった SQLite 未対応の抜け穴 2 箇所まで改修したセッション（会話 ID 71d216f4）の稼働トランスクリプト（transcript.jsonl）を完全解剖しました。

結論からお伝えすると、このセッション（AI 純稼働 38.1分・Planner 推論 57回）の裏側で、AI エージェントは 合計 124回 のツール呼び出し（うち Pure Rust 製 kb-search による SQLite 照会が延べ 68件） を実行していました。もし SQLite によるミリ秒単位のピンポイント抽出が無く、一般的な AI 開発環境のように毎回ファイルを直接 grep や read_file で丸読みしていた場合、直接参照した管理文書・商品辞書・主要 Rust コードの原寸合計だけでも 約 2,380KB（約 2.3MB）、公開記事 756記事 の横断検索まで含めれば 約 12MB 超 の生テキストがコンテキストへ雪だるま式に流れ込み、深刻な速度低下と利用枠（クォータ）枯渇――すなわち 「見えない I/O 破産」 を引き起こしていたことが判明しました。本記事では、延べ 68 件の DB 照会の全内訳と、その場で塞いだ「最後の 2 つの丸読みの抜け穴（公開 MDX 全文格納＋飛び地複数範囲 1 コール抽出：8.90ms）」の実測データをすべて公開します。

• サーモス「真空断熱コーヒーサーバー TTF-720」実機レビュー｜内面セラミック加工とHARIOアームスタンド適合検証 : 今回の「8 時間半後 48.6℃ の温度実測写真 1 枚追記」の舞台となった、内面セラミック加工サーバーの実機検証記事です。

• AI開発のファイル丸読みをゼロにするSQLite構造化術｜コード・GSC・SKILL全統合の実測録 : 記事原稿だけでなくシステムコード・環境変数・Search Console生JSON・外部SKILL・MCPまで全資産をSQLiteへ直結した基盤設計の全体像です。

• AIエージェントのトークン節約とSQLite直結術｜仕様書1コール化とCarbon並列監査で週間枠1%の実測録 : 1,051 行の詳細仕様書を SQLite から 1 コール・数ミリ秒で引き当て、最上位モデル並列稼働でも週間枠消費を 1〜2% に抑え込んだ設計録です。

• CLAUDE.md・GEMINI.md・TODO丸読みの罠｜SQLite階層目次で読込99%減の実測録 : 肥大化したルールファイルや未執筆 TODO 台帳を AI が毎回丸読みする無駄を、SQLite の階層インデックスで 99% 削減した検証記録です。

• 「ちょっとした記事修正やコード変更を頼んだだけなのに、AI の応答がだんだん遅くなり、利用枠（クォータ）が急減する」と悩んでいる方

• AI エージェントが裏側で 「何回ファイルを読み、何キロバイトのテキストをコンテキストへ積んでいるのか」 を実測ログで知りたい方

• ルールファイル、商品辞書、プログラムコード、そして 公開記事の Markdown / MDX 全文 までを SQLite に一元化し、ミリ秒単位で飛び地抽出する具体的な設計を知りたい方

• セッション所要時間と推論ステップ : 壁時計 40.8分（AI 純稼働時間 38.1分） ／ ユーザー入力 6ターン ／ Planner 推論ステップ 57回

• ツール呼び出し総数（計 124回）の内訳 :

  1. kb-search（SQLite 知識ベース照会・検索・カルテ生成） : 延べ 68件（全体の約 55%）
  2. gemini-gate（4ms 機械検問・EXIF 解析・WebP 画像変換） : 9回
  3. read_file（ファイル・画像の直接読み込み） : 9回（うち実機写真・回転確認画像の目視チェックが 5回、初期ルール・記事読込等が 4回）
  4. edit_file / ビルド・本番転送・Playwright 検証等 : 残り 38回

• API トークン消費量とキャッシュ効率（実測） :

  • 新規入力（Fresh Input） : 832,264 トークン
  • キャッシュ読込（Cached Input） : 6,891,184 トークン（キャッシュヒット率 89.2%）
  • AI 出力（Output） : 51,246 トークン

1. 過去記事での記述・型番の裏取り : 追記対象である サーモス「真空断熱コーヒーサーバー TTF-720」実機レビュー をはじめ、過去に同じ温度計（TT-508N）が登場したコーヒー検証記事群で、センサーの更新間隔（0.5 秒）や防水規格（IPX7）をどう記述していたかを横断検索します。もし全 756記事 の生 MDX ファイル（合計 約 10MB 超）を直接全文走査すれば巨大な負荷になりますが、SQLite FTS5 Extension 公式ドキュメント に基づく全文検索テーブルを使えば、実測 6.93〜7.73ms で該当する数行（約 3〜4KB）だけを抽出できます。

2. アフィリエイト商品辞書（257商品）の ID 照合 : 記事内で <AffiliateCard> を呼び出す際、既存の TypeScript 定義ファイル群（全 257 本・合計 1,351.4KB）の中に tanita-thermometer-tt508n や thermos-coffee-server-ttf720 がすでに登録されているか、表記揺れや重複が無いかを確認します。これもファイルを grep するのではなく、SQLite の affiliates テーブルを引くことで実測 1.60〜3.41ms・わずか 約 0.8KB の出力で即座に確定します。

• フル仕様書・投稿ルールのピンポイント抽出 : フル仕様書 docs/GEMINI_MANUAL.md（1,051行・436.6KB）とレビュー記事規定 REVIEW_POST_RULES.md（233行・46.2KB）を丸読みすれば約 483KB になりますが、SQLite の manual サブコマンドなら実測 2.89〜18.54ms で必要な 1 節（約 3KB）だけを取り出せます。

• 対象記事の構造＆逆リンク空き枠の一括カルテ生成（prep edit） : 編集対象の thermos-ttf720 記事（追記前 359行 → 追記後 392行・10,306字）の見出し構造、物理行番号マップ、さらに強関連 6 記事の「合わせて読みたい枠」の現在の本数と挿入可能な行番号を、./scripts/run_kb_search.sh prep edit の 1 コール（実測 183.95ms）で一括算出しています。

• Pure Rust システムコード（55本・計3,522.7KB）の関数行範囲抽出 : 後半の抜け穴改修で触った主要 Rust ファイル4本――db_sync.rs（4,571行・168.0KB）、workflow_prep.rs（4,302行・160.1KB）、doc_nav.rs（4,136行・152.8KB）、mdx_dissect.rs（2,015行・71.2KB）――も、ファイルを丸ごと read_file せず、SQLite の tree <file> L開始-L終了 --full を使うことで実測 3.31〜5.14ms で指定の 50〜100 行（約 2〜4KB）だけを取得しました。

• 問題の本質 : trigger: model_decision の別ファイルが存在すると、AI は律儀にそのファイル全体を read_file で読み込み、毎セッション 13.1KB の固定コンテキスト枠を消費してしまいます。

• 実装した恒久対策 : .agents/rules/review_post_rules.md を物理削除して廃止し、常時読み込まれるコア憲法（GEMINI.md）には わずか 2 行の要点 だけを残しました。そして詳細が必要な時だけ、SQLite の ./scripts/run_kb_search.sh manual "<節番号|語句>" から数ミリ秒で該当節を引く設計へ完全一本化しました。

1. SQLite スキーマ 4.4 で articles.raw_mdx カラムを新設 : 全 756記事 の公開 MDX ファイルの生テキスト全文を articles.raw_mdx に格納し、import 文の行番号一覧も kb-search tree <slug> imports で即座に引けるようにしました。

2. カンマ区切りの飛び地行範囲（L40-L55,L278-L320）の 1 コール同時抽出 : ./scripts/run_kb_search.sh tree thermos-ttf720 L40-L55,L278-L320 のように、離れた複数の行範囲をカンマ（,）で繋いで指定すると、1 回のツール呼び出しで両方の行範囲を同時に抽出する機能 を実装しました。

3. 実測わずか 8.90ms で edit_file の Target 文字列が完全確定 : 実際にこのコマンドを実行したところ、392 行の記事から「冒頭の import 行群」と「後半の保温テスト記述」の 2 箇所（計 58 行分）が 実測 8.90ms・1 ツールコール で出力され、index.mdx を 1 度も read_file せずに edit_file へ直行できるようになりました。

• 写真1枚の追記の裏で124ツールコール・68回のDB照会 : 過去記事の型番裏取り、257 商品のアフィリエイト辞書照合、1,051 行の仕様書確認、逆リンク枠の算出、システムコード確認など、1 bit の矛盾も防ぐために AI は裏側で 延べ 68件 の SQLite 照会 を行っていました。

• 丸読み換算約2.3MB（全記事含め約12MB超）を数KBへ圧縮 : 直接関わった管理文書・辞書・主要 Rust コードだけでも原寸合計は 約 2,380KB（約 2.3MB） に達しますが、SQLite 抽出により 1 回あたり 約 0.8〜4KB・実測 1.60〜18.54ms へ 99% 以上圧縮し、キャッシュヒット率 89.2% を達成しました。

• 最後の2つの抜け穴（条件付きルール＆MDX複数範囲抽出）を完全解消 : 毎回 13.1KB の read_file を誘発していた条件付きルールファイルを廃止して SQLite manual へ一本化し、さらに公開記事全文（articles.raw_mdx）の格納と L40-L55,L278-L320 のようなカンマ区切り飛び地行範囲の 1 コール抽出（実測 8.90ms） を実装しました。

あなたは私の熟練した開発パートナーです。
まず以下の実機検証記事URLを読み込み、そこで解説されている「AIエージェントの見えないI/O破産（ファイル丸読み）の防止」と「SQLiteによるミリ秒単位のピンポイント抽出＆カンマ区切り複数行範囲の1コール抽出」の設計思想を完全に理解してください。

【参照記事】
https://lab.chihouzakki.com/blog/review/ai-blog-single-edit-hidden-file-io-sqlite-anatomy/

【あなたに実行してほしい手順】
1. いきなりコードを書き換えたりファイルを生成したりせず、まず当プロジェクトの現在のディレクトリ構成、記事やドキュメントの形式（Markdown / MDX / コード等）、ルール設定ファイル（.agents/rules や CLAUDE.md / GEMINI.md 等）、および既存の検索スクリプトやDBの有無を事前調査してください。
2. 調査結果に基づき、以下の3点を当プロジェクトの環境に合わせて導入するための「具体的な実装計画（Implementation Plan）」を日本語で提示し、私の合意を得てください：
   - 毎回不要な read_file（Analyzed）を誘発する条件付きルールや巨大ファイルの丸読み箇所の特定とスリム化
   - 仕様書・商品/設定辞書・ソースコード・記事本文（raw_mdx等）をSQLiteへ同期し、数ミリ秒で検索できる仕組み
   - 1つのファイル内の離れた複数箇所（例：冒頭のimport群と後半の編集対象セクション）を「L40-L55,L278-L320」のようなカンマ区切り指定によって1ツールコールで同時抽出できるCLI機能の実装
3. 私の承認後、バックアップを取りながら安全に実装と動作テストを行ってください。