結論：AIの1msは360万クロック！3大泥棒の実測表

人間の目にとって、1 ミリ秒（1,000 分の 1 秒）や 10 ミリ秒の違いは瞬き（約 100〜150 ミリ秒）よりはるかに短く、単発のコマンドを手打ちしている限りほとんど気になりません。

しかし、今回の改修の引き金になったのは、開発中のチャットで交わした 「人間と AI の時間感覚の決定的なギャップ」 についてのやり取りでした。

「そんな大げさな、クラウド側の AI 推論に数秒かかるなら手元の 10ms なんて誤差では？」と思われるかもしれません。ところが実際の自律型 AI エージェント環境では、1 つの作業を完遂する間に PreInvocation（思考前フック）、知識 DB 検索（10〜30 回）、ファイル編集ごとの PostToolUse（即時書式検問・連鎖波及解析）、Stop（完了前ゲート）が 合計 40〜80 回以上も直列で起動 します。さらにサブエージェントを並列で走らせると、無駄な子プロセス生成（fork）や数 MB のメモリ再確保が CPU キャッシュや OS のプロセス管理ロックを奪い合い、全体の回転テンポをじわじわと重くしていたのです。

実際に 3 つの「ミリ秒泥棒」を特定し、すべて駆除した前後の 7 回ウォーム計測・中央値ベンチマーク がこちらです。

Pure Rust化の後になお残っていた『隠れたミリ秒泥棒』駆除前後の比較

改修前（隠れた泥棒3箇所あり）

本体3.6ms＋ラッパー10.5ms＋全文コピー

dirname・pwd・mkdir -p の子プロセス起動でラッパーだけで +10.45ms を浪費。会話検索も 140 字の抜粋を作るために数 MB の全文を毎回コピーし、内部処理に 19.3〜30.3ms かかっていました。

改修後（Zero-Fork＋ゼロコピー）

シェル組み込み展開＋借用参照＋窓抜粋

子プロセス fork を完全ゼロ化してラッパー込み起動を 6.55ms（Hooks 直叩き 8.66ms）へ半減。SQLite ゼロコピー借用と双方向窓切り出しにより、会話検索の内部処理は 5.34〜5.65ms で完了します。

計測対象・実行コマンド	改修前（中央値）	改修後（中央値）	短縮倍率・解消したボトルネック
run_kb_search.sh --help（ラッパー経由起動）	14.05 ms	6.55 ms	約 2.1 倍速（ラッパー付加コスト +10.45ms → +3.12ms）
run_gemini_gate.sh --help（監査ゲート起動）	14.24 ms	6.62 ms	約 2.2 倍速（子プロセス fork ゼロ化＋AVX2 命令解禁）
毎ターン Hooks（PreInvocation / Stop）	約 18〜20 ms	8.66〜8.79 ms	約 2.2 倍速（サブシェル廃止＋RAMDisk バイナリ直叩き）
convos "全公開記事"（3文字以上・内部処理）	19.27 ms	5.34 ms	約 3.6 倍速（ラッパー込み全体でも 12.92ms で完結）
convos "あいう"（2文字 short_fts・内部処理）	30.30 ms	5.65 ms	約 5.3 倍速（ゼロコピー借用＋limit 到達時の早期打切）
kb-search --self-test（自己診断テスト一式）	11.57 ms	10.50 ms	224 通り総当たり＆500KB 負荷テストを追加しつつ高速維持

---

泥棒①：Rust本体の3倍遅いシェルのfork税を撤廃

最初のミリ秒泥棒は、Rust バイナリを RAM ディスク上で自動ビルド・起動するために挟んでいた 2 本のシェルスクリプト（run_kb_search.sh と run_gemini_gate.sh）および .agents/hooks.json の中に潜んでいました。

dirnameとpwdが毎回10ms奪う仕組み

シェルスクリプトを書くとき、多くのエンジニアが手癖のように書く「スクリプト自身の親フォルダ（プロジェクトルート）を取得する定番イディオム」があります。改修前のラッパーにも、まさに次の 3 行が書かれていました。

# 【改修前】何気ない定番イディオムだが、毎回 4〜5 回の fork/exec を引き起こす
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
mkdir -p "/Volumes/RAMDisk/$(id -un)/tmp/kb-search-bin"

一見すると何の変哲もないコードですが、OS（macOS カーネル）の裏側では毎回とんでもない重労働が走っていました。

1. $(...)（コマンド置換）によるサブシェル fork() の連鎖 : $(...) を書くたびに、現在の bash プロセスを丸ごと複製するシステムコール（fork / posix_spawn）が発生します。入れ子になっているため、わずか 2 行で複数回のサブシェル複製が走っていました。

2. 外部バイナリ dirname・mkdir・id の毎回起動 : cd や pwd はシェルの組み込みコマンドですが、dirname・mkdir・id は /usr/bin/ 等にある独立した外部プログラムです。すでに RAM ディスク上のフォルダが存在している 99.9% の通常時でさえ、毎回わざわざ外部バイナリを探して起動し、動的リンクを解決して終了させていました。

その結果、RAM ディスク上の kb-search --help を直接叩けば 3.60ms で終わるのに、run_kb_search.sh --help を通しただけで 14.05ms（差し引き +10.45ms の純粋ロス） に膨れ上がっていたのです。

組み込み変数展開とHooks直叩きによる高速化

「でも、dirname や pwd を消したら、シンボリックリンク経由やサブフォルダから相対パスで呼ばれた時にパス解決が壊れない？」という疑問が湧きますよね。

そこで今回は、「日常の 99% を占める呼び出しパターンだけを外部コマンドゼロの高速レーンに通し、変則的な呼び出し時だけ従来の dirname / pwd へ安全にフォールバックする二段構え」 に書き換えました。

# 【改修後】通常時はサブシェルも外部コマンドも一切起動しない Zero-Fork 実装
SRC_SELF="${BASH_SOURCE[0]}"
case "$SRC_SELF" in
    ./scripts/run_kb_search.sh|scripts/run_kb_search.sh)
        if [ ! -L "$SRC_SELF" ]; then
            PROJECT_ROOT="$PWD"
        else
            SCRIPT_DIR="$(cd "$(dirname "$SRC_SELF")" && pwd)"
            PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
        fi
        ;;
    /*)
        SCRIPT_DIR="${SRC_SELF%/*}"
        if [ ! -L "$SRC_SELF" ] && [[ "$SCRIPT_DIR" != *"/.."* ]] && [[ "$SCRIPT_DIR" != *"/./"* ]]; then
            PROJECT_ROOT="${SCRIPT_DIR%/*}"
        else
            SCRIPT_DIR="$(cd "$(dirname "$SRC_SELF")" && pwd)"
            PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
        fi
        ;;
    *)
        SCRIPT_DIR="$(cd "$(dirname "$SRC_SELF")" && pwd)"
        PROJECT_ROOT="$(cd "$SCRIPT_DIR/.." && pwd)"
        ;;
esac

# ユーザー名も環境変数 $USER / $LOGNAME を優先し、空の時だけ id -un を呼ぶ
CURRENT_USER="${USER:-${LOGNAME:-}}"
[ -z "$CURRENT_USER" ] && CURRENT_USER="$(id -un)"

# 既存ディレクトリの存在・書込確認は組み込み [ -d ] [ -w ] で行い、無い初回だけ mkdir -p
RAM_TARGET="/Volumes/RAMDisk/$CURRENT_USER/tmp/kb-search-bin"
if [ -d "$RAM_TARGET" ] && [ -w "$RAM_TARGET" ]; then
    export TMPDIR="/Volumes/RAMDisk/$CURRENT_USER/tmp"
    BIN_DIR="$RAM_TARGET"
fi

あわせて以下の 2 点も同時に仕上げました。

• .agents/hooks.json のサブシェル撤廃＆RAMDisk バイナリ直叩き : エディタが /bin/sh で毎ターン起動する PreInvocation と Stop において、子プロセスを作る丸括弧 (...) を同一シェル内で動く { ...; }（グループコマンド）へ変更しました。さらに ./tools/kb-search/src/*.rs 全ファイルの更新時刻（-nt）を純粋なビルトインループで検査し、再ビルド不要な通常時は .sh ラッパーすら経由せず RAM ディスク上のバイナリを直接叩く高速経路（実測 8.66ms）を設けています。

• 監査ゲート側の AVX2 ネイティブ命令解禁 : run_gemini_gate.sh のコンパイルフラグにも -C target-cpu=native を追加し、600 本超の MDX 走査で CPU 内蔵の 256-bit SIMD（AVX2）命令がフル稼働するよう統一しました。

---

泥棒②③：SQLiteゼロコピー借用と窓切り出し抜粋

玄関口のシェル税を片付けたところで、次は Rust バイナリ内部（kb-search convos：650MB 超・2,360 スレッドの会話履歴全文検索）に潜んでいた 2 つ目・3 つ目のミリ秒泥棒 です。

ライフタイムで守るSQLiteのゼロコピー借用

プロファイリングの結果、SQLite（macOS 標準の /usr/lib/libsqlite3.dylib FFI 直結）の足回りで 2 つの無駄が見つかりました。

1 つ目は、隔離サンドボックス内での一時領域エラーを防ぐために書いた ensure_writable_tmpdir() が、DB 接続を開くたびに毎回実ファイル（.kb_tmp_probe_<PID>）を作成して削除していたことです。これを std::sync::Once（プロセス内で初回 1 回のみ実行）＋ POSIX の access(c_dir, W_OK | X_OK) システムコールへ置き換え、ディスク・RAM ディスクへの無駄な inode 更新 I/O を完全にゼロにしました。

2 つ目がさらに大きな本丸で、「検索候補スレッドの巨大本文（1 件あたり数百 KB〜数 MB）を、列取得のたびに毎回 Rust の String へ丸ごとヒープコピーしていた問題」 です。

C 言語や C++ で SQLite の sqlite3_column_text() が返す内部バッファポインタをそのまま持ち回ると、次に sqlite3_step() や sqlite3_reset() を呼んだ瞬間に SQLite 側でページメモリが解放・上書きされ、深刻なメモリ破壊（Use-After-Free）を起こします。そのため安全策として毎回 .to_string() でコピーしていたのですが、Rust の所有権・ライフタイム（生存期間）システムを使えば、コピーゼロと 100% のメモリ安全を両立 できます。

impl<'a> Stmt<'a> {
    /// SQLite の内部ページバッファをヒープコピーせずゼロコピー `&str` のまま借用する。
    /// `&self` 借用中は `&mut self` を要する `step()` / `reset()` が型システム上呼べないため 100% 安全。
    #[inline]
    pub fn with_col_str<R>(&self, col_0based: i32, f: impl FnOnce(&str) -> R) -> R {
        unsafe {
            // SQLite C API 公式仕様どおり、型変換による再確保を防ぐため先に text ポインタを取得してから bytes 長を読む
            let ptr = sqlite3_column_text(self.raw, col_0based);
            if ptr.is_null() {
                return f("");
            }
            let n = sqlite3_column_bytes(self.raw, col_0based);
            if n <= 0 {
                return f("");
            }
            let slice = std::slice::from_raw_parts(ptr, n as usize);
            match std::str::from_utf8(slice) {
                Ok(s) => f(s),
                Err(_) => {
                    let lossy = String::from_utf8_lossy(slice);
                    f(&lossy)
                }
            }
        }
    }
}

イメージとしては 「図書館の分厚い資料（SQLite 内部ページ）をコピー機で全ページ複写するのをやめ、机の上で開いている間（&self 借用クロージャの中）だけは司書がページをめくれない（&mut self の step() がコンパイルエラーになる）よう鍵をかけた状態」 です。また SQLite 公式 C API 仕様の鉄則に従い、必ず先に sqlite3_column_text で UTF-8 表現を確定させてから sqlite3_column_bytes でバイト長を取得することで、暗黙のエンコーディング変換によるポインタ無効化も防いでいます。

数MB全文コピーを廃止した双方向ストリーム抜粋

3 つ目のミリ秒泥棒は、検索結果一覧に表示する 「前後わずか 140 文字のスニペット（一致箇所の抜粋）」 を作る make_snippet 関数にありました。

改修前のコードは、連続する改行やスペースを綺麗な半角スペース 1 個に揃えるために、まず数 MB ある会話本文全体を先頭から末尾までなめて正規化用の String を新規確保し、さらに全文字を Vec<char>（1 文字 4 バイトの配列）へ展開してから 140 文字を切り出す O(N)（全文長比例）の処理 を毎行繰り返していました。100 万文字のスレッドなら、たった 140 文字を切り出すために数 MB のメモリ確保と解放を毎回行っていた計算です。

これを全文コピー一切なしの O(max_chars)（抜粋文字数だけに比例する定数時間）窓切り出しアルゴリズム へ全面刷新し、さらに cmd_convos 側の早期打ち切りと組み合わせました。

全文コピーを全廃した『ゼロコピー照合 × 双方向ストリーム窓抜粋』の3ステップ

Step 1

ゼロコピーAVX2位置特定

with_col_str で借用した生テキスト上を AVX2 find_fast で走査し、一致開始の正確な UTF-8 バイト位置だけを瞬時に特定します。

文字境界特定

Step 2

前後窓の双方向ストリーム圧縮

一致位置から逆方向へ最大 lead 文字、順方向へ残り文字数だけをイテレータで走査し、空白を 1 個に圧縮しながら抜粋を組み立てます。

limit件で即終了

Step 3

オーバーフロー読込の即時打切

単一条件検索では更新日時降順で候補が並んでいるため、表示上限（limit 件）に達した瞬間に残り候補の巨大本文読込を即終了します。

なお、「検索ワード自体にスペースが含まれていて、本文側ではちょうど改行をまたいで書かれているケース（例："複合スペース語句\nテスト"）」だけは生テキストへの単純一致では拾えないため、検索語に空白が含まれる場合のみ従来の全文正規化関数（make_snippet_full_normalize）へ自動フォールバックする安全弁を残しています。この結果、2 文字 short_fts 検索（convos "あいう"）の内部処理時間は 30.30ms → 5.65ms（約 5.3 倍速） まで一気に短縮されました。

---

高速化の裏で踏んだ文字境界罠と224通り自動検証

ここまで読むと順風満帆に見えますが、実はこの一連の改修と日本語クエリ検証の過程で、Rust 特有のヒヤッとする実行時パニックをもう 1 箇所あぶり出して修正 しています。

日本語検索で起きた8バイト固定スライスパニック

日本語の検索語を入れて kb-search convos "全公開記事" をテスト実行した際、検索処理に入る手前の「入力が会話 ID（UUID 等）かどうかを判定する補助関数 looks_like_convo_id」で、次のパニックが発生しました。

thread 'main' panicked at tools/kb-search/src/main.rs:711:
byte index 8 is not a char boundary; it is inside '開' (bytes 6..9 of `全公開記事`)

なぜ "全公開記事" という 5 文字の日本語が、8〜40 文字の UUID 判定分岐に入り込んで落ちたのでしょうか。原因は str::len() の意味の取り違えと、生 &str に対する固定バイトスライスでした。

• パニックの仕組み : Rust の clean.len() は「文字数（5 文字）」ではなく 「UTF-8 バイト数（3 バイト × 5 文字 ＝ 15 バイト）」 を返します。そのため clean.len() >= 8 && clean.len() <= 40 という長さ条件をそのまま通過してしまい、続く &clean[..8]（先頭 8 バイトの切り出し）が 3 文字目である '開'（6〜9 バイト目）のど真ん中を切断して即座にパニックを起こしたのです。

• 1 ナノ秒で終わる根本対策 : 会話 ID（6432b2ba-... や gemweb_...）は定義上 100% ASCII 文字しか含みません。関数冒頭に if !clean.is_ascii() { return false; } の 1 行を入れ、内部判定もすべてバイトスライス（clean.as_bytes()）へ統一しました。同時に kb-search と gemini-gate の全ソースファイルを横断監査し、マルチバイト文字が混入し得る箇所での固定添字スライスが 0 件であることを確認しています。

約10.5msで回る224通り総当たり自己テスト

今回の高速化では、抜粋アルゴリズム（make_snippet）や SQLite のゼロコピー借用（with_col_str）、フックの更新検知をすべて手直ししたため、「本当にどんな境界入力でも元の実装と 1 文字も違わない結果になるか？」を証明する必要があります。

そこで kb-search --self-test の内部に、以下の 3 重の自動回帰テスト を常設しました。

---

まとめ：64GB母艦の快適単価とAIミリ秒監査手順

今回の「AI にとっての 1ms ＝ 360 万クロック」から始まったミリ秒泥棒退治のポイントを整理します。

• ネイティブバイナリの外側にある『シェル税』を疑う : 本体を Rust で 3ms 台にしても、ラッパーの $(dirname ...) や mkdir -p が毎回走ると、それだけで本体の 3 倍にあたる 10ms 以上が消えてしまいます。Bash 組み込み変数展開と Hooks 直叩きで fork をゼロにする効果は絶大です。

• 巨大テキストは『借りて、窓だけ切る』 : SQLite の内部ページをライフタイム付きクロージャ（with_col_str）でゼロコピー借用し、抜粋も一致箇所の前後だけを双方向ストリームで切り出すことで、会話全文検索の内部処理は最大 5.3 倍速（5ms 台） まで軽くなります。

缶コーヒー1本分で回るRAMDisk×64GB母艦

なお、今回のように 「16GB の RAM ディスク上に AVX2 最適化済みの Rust バイナリを常駐させて 6〜8ms で即起動」＋「合計 700MB 超の SQLite データベースを OS メモリマップ（mmap）でオンメモリ保持して SSD やハードディスク（記憶装置）へのアクセスをゼロ化」 という環境をスワップなしで維持できるのは、母艦に 64GB の潤沢なメモリ があるおかげです。

推論（試算）になりますが、約 22万〜25 万円クラスの 64GB メモリ搭載 Mac 母艦を 5 年間（1,825 日）毎日開発や執筆の拠点として使い倒した場合、1 日あたりの快適コストは約 120〜137 円（缶コーヒー 1 本分、1 日 4 時間作業なら 1 時間あたり約 30 円強） です。AI エージェントが 1 日に何百回と検索や検問を回す時代において、手元のローカル基盤がミリ秒で即答してくれる気持ちよさと SSD 延命効果は、価格以上のリターンをもたらしてくれます。

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

また、広々とした 27 インチ 5K Retina 画面と 64GB メモリを高いコストパフォーマンスで手に入れたい方には、今回の全実測データを叩き出した現役母艦 iMac 27インチ Retina 5K（2020年モデル） に、背面スロットへ工具なしで増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を組み合わせる構成もまだまだ第一線で活躍します（※ DDR4 SO-DIMM は Intel Mac 専用のため、Apple シリコン搭載機には装着できません）。

そして、今回活躍した Rust の「借用チェッカーとライフタイム（&self vs &mut self）」「UTF-8 文字列スライスの安全性」「C 言語 FFI 連携」を基礎からしっかり自分の武器にしたい方には、定番の名著 オライリー・ジャパン『プログラミングRust 第2版』 を手元に置いておくのがおすすめです。AI が書いた高速化コードの急所を自分の目で監査できるようになります。

最上位AIに隠れたミリ秒泥棒を探させる手順

最後に、ご自身の開発環境でも「すでに高速化したはずの CLI ラッパーや Hooks、データベース検索にまだ隠れている 10ms 単位の無駄を安全に削りたい」という方へ、そのまま使えるプロンプトを用意しました。

シェルのシンボリックリンク境界や、Rust FFI のライフタイム設計、UTF-8 マルチバイト文字境界の扱いは、軽量モデルに丸投げすると微妙な退行バグを生みやすい領域です。必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、以下のプロンプトを貼り付けて「ナノ秒計測による犯人特定と総当たり一致テスト」から進めてみてください。