結論：Rust化すべき処理と残すべき処理の境界線

「Rust は速い」と聞くと、つい手元のスクリプトを端から端まで書き直したくなります。しかし実際に当サイトの scripts/ 配下にある全スクリプトの実行時間と内訳を計測してみると、「Rust 化すると 5〜40 倍速くなる処理」と「苦労して Rust 化しても 1% も速くならない処理」が真っ二つに分かれる ことがわかりました。

まずは実測にもとづく仕分け基準を一覧表で整理します。

処理カテゴリー	当サイトでの具体例	Rust化の判定	理由と損益分岐点
① 毎ターン走るエディタ Hooks	kb_hook_bridge.mjs（編集検知・連鎖ガイド）	◎ 最優先	AI の思考前後やファイル保存のたびに何十回も起動するため、V8 起動税の削減効果 が最も大きい領域です
② 高頻度の短命 CLI サブコマンド	kb_query.mjs の未移植 8 コマンド（card / impact 等）	◎ 最優先	処理本体が 10ms でも Node.js 起動に約 78ms かかると、体感速度が 4〜5 倍遅くなります
③ 巨大 SQLite 同期・並列テキスト解剖	sync_knowledge_db.mjs（572 記事＋2,361 会話同期）	◎ 最優先	シングルスレッドの JS ループを 12 スレッド並列＋FFI 直結 に変えることで桁違いの差が出ます
④ 全記事スキャン・定型構造操作	監査マップ生成・見出し行番号抽出・太字スペース整形	○ 中優先	既存の監査バイナリに相乗り統合すれば、568 記事走査や文字境界判定が数ミリ秒〜0.2 秒で終わります
⑤ 定期 LaunchAgent のファイル退避	archive_cold_brain.mjs（RAMDisk 会話整理）	○ 中優先	インプロセスで SQLite パス同期まで完結でき、バックグラウンド常駐ジョブの負荷が最小化します
⑥ 外部 Web API の通信待ち処理	Search Console API 取得・Gemini API 日報生成	× 不要	実行時間の 99% 以上がネットワーク応答待ち（数秒〜数十秒） のため、言語を変えても速くなりません
⑦ 内部がすでに C/C++ ネイティブの処理	sharp による WebP 画像変換・EXIF 回転補正	× 不要	Node.js は薄い窓口にすぎず、実際の画素計算はすでに C++ 製 libvips が SIMD 並列で実行しています
⑧ 起動しっぱなしの常駐サーバー	Convo Mail ローカル閲覧サーバー・Astro 開発サーバー	× 不要	起動が 1 回きりなので V8 起動税が問題にならず、JIT 最適化が効いた後は数ミリ秒で応答します

---

数百行のNode.jsが毎回待たされる3つの真因

では、なぜ数百行程度のシンプルな Node.js スクリプトなのに、実行するたびに 100ms〜1,060ms もの待ち時間が発生していたのでしょうか。プロファイリングで浮かび上がった真犯人は以下の 3 つ でした。

空スクリプトでも発生するV8起動税78ミリ秒

1 つ目の真犯人は、スクリプトの中身を 1 行も実行する前から発生する 「Node.js（V8 JavaScript エンジン）のプロセス起動税」 です。

当サイトの母艦である iMac（Core i5-10600 / 64GB RAM / Node.js v24）で、文字通り「何もしない空っぽのコマンド」を計測した結果がこちらです。

# 何もしない空スクリプトの起動〜終了時間を実測（5回ウォーム計測の中央値）
$ node -e ""
# -> 実測中央値: 78.1 ms

Node.js は起動するたびに、巨大な実行バイナリの動的リンク解決、V8 ヒープ領域と Isolate（独立実行空間）の初期化、組み込みモジュールのブートストラップを行います。常駐 Web サーバーなら最初の 1 回だけで済みますが、AI エージェントが 1 つのタスクの中で検索コマンドや Hooks を 30 回呼び出せば、中身が 0 秒でも 78.1ms × 30回 ＝ 約 2.3 秒 の純粋な待ち時間 が積み上がります。

なお、Node.js v22 以降にはバイトコードを保存して起動を助ける --compile-cache オプションもありますが、実際に試しても V8 自体の初期化とモジュール解決の土台コストは残るため、ネイティブ機械語バイナリ（起動〜終了まで 5ms 台）との 10 倍以上の差は埋まりませんでした。

静的import連鎖が招く9,000行の事前読込

2 つ目の真犯人は、ECMAScript Modules（ESM）の仕様による 「静的 import グラフの芋づる式ロード」 です。

たとえば Antigravity エディタでAIが思考を始める直前に毎回呼ばれる kb_hook_bridge.mjs（pre-invocation モード）は、本来なら「直前に編集されたファイルの通知キューが無ければ、ただ {} を出力して終わるだけ」の 実質 5 行の処理 です。ところが実際の所要時間を測ると 毎回 94.1ms もかかっていました。

原因をたどると、ファイルの先頭に書かれた import 文の連鎖に行き当たりました。

FTS5仮想表の結合走査で消えていた1秒の正体

3 つ目の真犯人は、654.5MB（2,361 会話スレッド）に育ったチャット履歴データベース conversations.sqlite の差分同期（sync_knowledge_db.mjs --convos）に潜んでいました。

新しい会話が 1 件も増えていない（差分 0 件）にもかかわらず、実行するたびに 1,063.3ms（約 1.06 秒） もかかっていたのです。原因を分解すると、以下の 2 つの重い処理が毎回フル回転していました。

1. 12MB 超の threads_index.json パースと数千回の stat 発行 : Google Takeout 由来の Web 版 Gemini スレッド（846 件）に変更がないか確かめるため、毎回 12MB 以上の JSON インデックスを丸ごと読み込み、個別ファイルの更新日時をシステムコールで確認していました。

2. FTS5 仮想テーブルに対する LEFT JOIN フルスキャン : 1〜2 文字検索用の補助索引（conversations_short_fts）に漏れがないか確認する際、FROM conversations_fts f LEFT JOIN convo_short_fts_tracker tr ON tr.fts_rowid = f.rowid という SQL を実行していました。SQLite の FTS5 は「仮想テーブル」であるため、主キーのように見えても通常の B-Tree インデックス結合が効かず、毎回 2,361 件（数百 MB 分）の仮想テーブル全行を端からなめていた のが 1 秒超えの正体でした。

---

外部依存ゼロ！2バイナリ集約のPure Rust設計

原因が完全に特定できたところで、次は「どうやって保守性を下げずに高速化するか」です。スクリプトごとにバラバラの Rust プロジェクト（8 個の Cargo.toml と 8 個のビルドフォルダ）を作ってしまうと、管理が煩雑になるだけでなく SSD や RAM ディスクの容量も無駄に食ってしまいます。

そこで今回は、既存の 2 つのコアバイナリに役割ごと相乗りさせる 「2 バイナリ完全集約アーキテクチャ」 を採用しました。

全18スクリプトのボトルネックを吸収した『Pure Rust 2バイナリ』集約構造

バイナリ ①：憲法監査＆執筆支援エンジン

gemini-gate（全47項目の自己診断テスト内蔵）

従来の憲法監査に加えて、--sync-rules（GEMINI.md 自動分割）、--audit-map、--outline、--fix（無改変 SHA-256 証明付き整形）を 1 本のバイナリへ統合しました。

デプロイ検問・ルール25分割・568記事監査マップ・見出し抽出・太字整形を担当

バイナリ ②：知識検索＆DB同期＆Hooksエンジン

kb-search（AVX2 SIMD × 12スレッド並列 × libsqlite3 直結）

残っていた 8 つの検索サブコマンド（stats / card / impact / axiom / affiliate 等）に加え、sync、hook（3 モード）、archive-cold-brain をインプロセスで直結しました。

全18検索コマンド・知識/会話DB並列同期・エディタHooks・RAMDisk会話退避を担当

共通足回り：SSD摩耗ゼロ＆依存パッケージゼロ

16GB RAMDisk 常駐バイナリ × macOS標準 libsqlite3.dylib FFI

外部クレート（crates.io）を 1 つも使わず、rustc --edition 2021 -O 単体で RAMDisk 上へ直接コンパイル。変更がない普段の呼び出しは exec で即座に機械語が走ります。

外部クレート0個とRAMDisk常駐の超速ビルド

Rust で CLI ツールを作るとき、一般的には serde・rusqlite・clap・regex・sha1 といった外部クレートをたくさん追加します。しかし個人開発やブログ基盤で外部クレートを何十個も抱え込むと、初回ビルドに何分もかかり、target/ ディレクトリが数 GB に膨れ上がるほか、外部パッケージの更新追従やサプライチェーン汚染のリスクも生まれます。

そこで今回は 「外部クレート依存 0 個（Rust 標準ライブラリ std ＋ macOS 標準搭載の /usr/lib/libsqlite3.dylib のみ）」 を貫きました。

• ビルドが数秒で終わり、target/ 肥大化もゼロ : Cargo すら介さず、起動ラッパー（run_kb_search.sh / run_gemini_gate.sh）が .rs ソースの更新日時を見て、変更があった時だけ rustc --edition 2021 -O -C target-cpu=native -C strip=symbols で RAM ディスク（/Volumes/RAMDisk/$USER/tmp/）へ直接バイナリを出力します。SSD やハードディスク（記憶装置）への書き込みは 1 バイトも発生しません。

• インプロセス連携で「子プロセス起動リレー」を根絶 : これまで kb_hook_bridge.mjs が編集通知を受けた際は、内部でさらに別のモジュールや DB 接続を張り直していました。統合後の kb-search hook は、自身のメモリ空間内にある sync_knowledge_db 関数や compute_article_impact（連鎖波及計算）を プロセス再起動なしで直接呼び出す ため、無駄なオーバーヘッドが一切ありません。

シャドウ表と署名キャッシュによるO(1)スキップ

先ほど「差分 0 件でも 1.06 秒かかっていた」会話履歴 DB の同期（kb-search sync --convos）には、SQLite の内部構造を活かした 2 段の O(1)（データ量が増えても一瞬で終わる定数時間）ショートカット を組み込みました。

-- FTS5 仮想表本体ではなく、裏側の実 B-Tree シャドウ表 (*_docsize) を使った高速整合判定
SELECT COUNT(*), COALESCE(MAX(id), 0) FROM conversations_fts_docsize;
SELECT COUNT(*), COALESCE(MAX(fts_rowid), 0) FROM convo_short_fts_tracker WHERE convo_id != '';

SQLite の FTS5（通常のコンテンツ保持型）を作ると、データベース内部には conversations_fts_docsize という通常の B-Tree 構造を持つシャドウテーブル（実表） が自動的に作られ、各行の id（rowid と 1 対 1 対応）が綺麗に並んでいます。

仮想テーブル本体（conversations_fts）を LEFT JOIN すると全件展開が走ってしまいますが、この _docsize 実テーブルの件数・最大 ID とトラッカー表を比較するだけなら、B-Tree の端を見るだけなので 0.1ms 以下で完了 します。不一致が見つかった時だけ差分行を拾いに行く二段構えにしたことで、普段の整合チェック負荷がほぼゼロになりました。

さらに 12MB ある threads_index.json と threads/ フォルダの更新日時・ファイルサイズを文字列署名（sync_meta.takeout_sig）として記録し、Takeout の取り込みが起きていない通常時は JSON パース自体を丸ごとスキップする仕組みも加えました。

移植中に実機で踏んだUTF-8文字境界の落とし穴

ここで、今回の実装テスト中に実際に踏んだ 「Rust ならではの落とし穴」 も包み隠さず共有しておきます。

全モジュールのコードを一通り書き終えて、いざ本番と同じ 572 記事のデータで最初の kb-search sync --quick を走らせた瞬間、画面に次のようなパニック（強制停止）が表示されました。

thread 'main' panicked at tools/kb-search/src/mdx_dissect.rs:1648:16:
start byte index 5 is not a char boundary; it is inside '知' (bytes 4..7 of string)

JavaScript の文字列スライスは UTF-16 コード単位なので途中で落ちることは滅多にありませんが、Rust の文字列（&str）は UTF-8 バイト列であり、日本語 1 文字（3 バイト）の真ん中のバイト位置で &text[i..] と切り出そうとすると、メモリ安全を守るために即座にパニックを起こして止まります。

原因は、ドキュメント内の記事パス（review/...）を探す高速ループで添字 i を 1 バイトずつ進めながら、うっかり文字列スライス text[i..].starts_with("review/") を呼んでいたことでした。すぐに全モジュールのスライス箇所を総点検し、バイト列のまま判定する bytes[i..].starts_with(b"review/") や境界安全な .get(start..end) へ統一した上で、日本語と数式・リンクが混在する回帰テストを --self-test に組み込みました。

---

実測比較：全CLIとHooksが最大43倍速に激変

すべての配線（.agents/hooks.json の Node.js 撤廃、package.json の各コマンド切替、既存 .mjs スクリプトからの自動委譲）を終えた状態で、移行前と同じ条件（5 回ウォーム実行の中央値）で計測した Before / After 実測ベンチマーク結果 がこちらです。

ミリ秒比較でわかった各処理の高速化インパクト

エディタHooks・DB同期における『Node.js旧構成 vs Pure Rust新構成』の違い

移行前（Node.js v24）

毎回V8起動 ＋ 9,000行読込 ＋ 仮想表走査

空の PreInvocation でも毎回 V8 初期化と 4 ファイル連鎖 import で 94.1ms 消費。ファイル編集直後の PostToolUse は 235〜300ms、会話 DB の差分確認には 1,063.3ms かかっていました。

移行後（Pure Rust 2バイナリ）

RAMDisk機械語直起動 ＋ インプロセスDB連携

ネイティブ直起動なら空ターン 5.94ms（ラッパー経由でも 18.03ms）。編集直後の PostToolUse もインプロセス同期で 109.5ms、654MB 会話 DB の差分同期は 24.7ms（43倍速） で完了します。

処理カテゴリ・実行コマンド	移行前（Node.js v24）	移行後（Pure Rust 統合版）	高速化倍率・主な改善点
会話DB差分同期 sync --convos（654MB・差分0件）	1,063.3 ms	24.7 ms（--quiet 42.4ms）	約 43.0 倍速（_docsize O(1) 判定＋署名キャッシュ）
Hooks pre-invocation（未編集の通常ターン）	94.1 ms	5.94 ms（ラッパー込 18.0 ms）	最大 15.8 倍速（9,000 行 ESM 読込を完全撤廃）
公理ピンポイント取得 axiom 7.5	102.8 ms	22.0 ms	約 4.7 倍速（V8 起動税ゼロ＋即座に行範囲出力）
記事統計サマリー stats	111.9 ms	27.7 ms（内部 9.09 ms）	約 4.0 倍速（知識 DB＋会話 DB の 2 庫同時集計）
セクション全文検索 search "特別会計"	103.5 ms	25.5 ms	約 4.1 倍速（FTS5 trigram ＋ SIMD スニペット）
Hooks session-start（起動時ルール＆DB同期）	376.8 ms	108.3 ms	約 3.5 倍速（gemini-gate 直起動＋インプロセス同期）
見出し・枠の物理行番号抽出 --outline	87.3 ms	25.3 ms（内部 1.28 ms）	約 3.5 倍速（単体記事の構造解剖は内部 1 ミリ秒台）
アフィリエイト辞書検索 affiliate garmin	94.4 ms	28.9 ms（内部 2.81 ms）	約 3.3 倍速（406 商品の ASIN・検索語を即座に照合）
記事カルテ表示 card total-investment-roadmap	130.4 ms	41.0 ms（内部 23.6 ms）	約 3.2 倍速（11 セクション統合カルテを一瞬で生成）
連鎖波及解析 impact ... --check "200兆"	120.9 ms	43.3 ms（内部 25.4 ms）	約 2.8 倍速（多軸スコアリング＋生 MDX 行番号照合）
Hooks post-tool（ファイル編集直後の自動同期）	235.9〜300.5 ms	109.6 ms	約 2.2〜2.7 倍速（ルール分割と知識 DB 更新を同時実行）
全568公開記事の監査マップ生成 --audit-map	546.4 ms	219.4 ms（内部 190.9 ms）	約 2.5 倍速（RAMDisk ミラー出力まで 0.2 秒で完結）
GEMINI.md 分割ルール25本生成 --sync-rules	71.1 ms	34.0 ms	約 2.1 倍速（24KB 予算検査＋差分書込）
知識DB差分同期 sync --quick --quiet	219.4 ms	76.6〜106.7 ms	約 2.1〜2.9 倍速（さらに VACUUM で DB 容量 215.4MB へ圧縮）

全572記事と分割ルール25本の完全一致を機械証明

速度が何十倍になっても、元の Node.js 版と出力結果が 1 文字でもズレてしまったら本末転倒です。今回の移行では「たぶん合っているだろう」という目視確認を一切排し、以下の 3 段階の機械証明 をすべてクリアしてから切り替えを行いました。

---

まとめ：64GB母艦の快適コストとAI段階移行手順

今回の「Node.js スクリプト群の仕分けと Pure Rust 2 バイナリ統合」で得られた結論をもう一度整理します。

• 何でも Rust 化しないのがプロの流儀 : 外部 API 通信待ち、C++ 製 libvips で動く sharp 画像変換、起動しっぱなしの常駐サーバーは Node.js のまま残すのが正解です。

• 短命 CLI・Hooks・並列 DB 同期に集中投下する : 毎回約 78ms かかる V8 起動税と約 9,000 行の ESM 連鎖読込を断ち切り、_docsize シャドウ表で FTS5 仮想表スキャンをなくすことで、Hooks 最大 15.8 倍速・会話 DB 差分同期 43.0 倍速 という別次元のレスポンスが手に入ります。

毎日使えば缶コーヒー1本分で回る64GB母艦構成

なお、今回のように 「16GB の RAM ディスク上に Rust バイナリとビルド一時領域を常駐」＋「合計約 870MB の SQLite 2 庫を OS メモリマップでオンメモリ保持」＋「12 スレッド並列コンパイル＆AI エディタ稼働」 を SSD スワップ（記憶装置への退避による速度低下）ゼロで回し続けるには、やはり 64GB メモリを搭載した母艦 Mac が最高の土台になります。

推論（試算）になりますが、たとえば約 22万〜25 万円クラスの 64GB メモリ搭載 Mac 母艦を 5 年間（1,825 日）毎日開発やブログ執筆の拠点として使った場合、1 日あたりの快適コストは約 120〜137 円（缶コーヒー 1 本分、1 日 4 時間作業なら 1 時間あたり約 30 円強） です。コマンドを叩くたびの「コンマ数秒〜1 秒の待ち時間」と SSD の書き込み摩耗を同時にゼロにできる投資として、これほどストレスを減らしてくれる環境はありません。

これから現行の Apple シリコン世代で 64GB 母艦を組むなら、購入後のメモリ増設ができない設計を踏まえ、最初から 64GB ユニファイドメモリ構成を選べる Apple Mac mini（Pro系チップ・64GB構成） が長く使える本命機になります。

また、広大な 27 インチ 5K Retina 画面と 64GB メモリを手頃な予算で揃えたい方には、今回の全ベンチマークを叩き出した現役母艦 iMac 27インチ Retina 5K（2020年モデル） に、背面のメモリスロットへ工具なしで装着できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を組み合わせる構成も非常に優秀です（※ DDR4 SO-DIMM は Intel Mac 専用のため、Apple シリコン搭載機には使用できません）。

そして、AI が書いた Rust コードの「所有権」「UTF-8 文字列境界」「スレッド並列」「C 言語 FFI（libsqlite3 直結）」の仕組みを手元でしっかり理解・査読したい方には、体系的な解説で定評のある定番技術書 オライリー・ジャパン『プログラミングRust 第2版』 を 1 冊デスクに置いておくと、先ほどの文字境界パニックのような場面でも迷わず原因を見抜けるようになります。

最上位AIに計測と段階的Rust化を任せる手順

最後に、ご自身のプロジェクトでも「遅くなっている Node.js や Python のスクリプトを見極めて、効果が高いものだけ安全に Rust 化したい」という方へ実践手順をお伝えします。

今回途中で遭遇した UTF-8 マルチバイト文字境界の安全性 や SQLite シャドウ表の扱い、既存スクリプトとの 100% 出力互換テスト は、軽量モデルに「全部 Rust にして！」と丸投げすると事故が起きやすいポイントです。必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下のプロンプトをコピー＆ペーストして「まず実測による仕分けと計画合意」からスタートしてみてください。