結論：文字列検索はGPUよりCPUのSIMD並列が速い

まず検証に使った母艦環境は、64GB メモリ（うち 16GB を RAMDisk 運用）を搭載した 27 インチ 5K iMac（iMac20,1：6 コア 12 スレッド Intel Core i5 ／ GPU：AMD Radeon Pro 5300 VRAM 4GB）です。

ここに格納されている 知識 DB（559 記事・6,359 セクション・コード 289 件・ルールや下書き 856 件） と 会話履歴 DB（2,313 スレッド・元ログ総額約 360MB） を対象に、「GPU オフロード」と「CPU 極限チューニング」のどちらが本当に速いのかを突き詰めた結論がこちらです。

全文キーワード検索における『GPUオフロード』と『CPU SIMD並列』の対比

逆効果ルート

独立GPUへ転送して文字列検索

メインメモリから PCIe バス経由で数百 MB のテキストを VRAM（4GB）へコピーし、結果を戻す往復だけで数十ミリ秒をロス。さらに可変長 UTF-8 文字の境界判定やエスケープ分岐で GPU スレッドが足並みを乱し、CPU 単体より遅くなります。

今回の採用ルート

CPU内蔵AVX2 × Rust 12並列 × short_fts

OS メモリマップ（mmap）上のデータを 1 ミリもコピーせず、CPU 内蔵の 256-bit ベクトル命令（AVX2）で 1 命令 32 バイトずつ一括照合。1〜2 文字専用索引と裏同期も組み合わせ、待ちゼロ・数十ミリ秒で完結します。

実際に今回の 3 大チューニングを導入する前後で計測した、コマンド別の実行速度とデータベース容量の比較表をご覧ください。

検証項目・実行コマンド	導入前（Node.js / 旧ハイブリッド）	導入後（Pure Rust AVX2 ＋ short_fts）	実測の改善効果
検索直前の差分同期待ち	50〜2,000 ms 停止	0.00 ms（待ちゼロ）	裏プロセス非同期化で引っかかりが完全消滅
全1,700件横断 grep "特別会計|RAMDisk"	223.55 ms（※記事50件で打切）	48.82 ms（内部 43.91 ms）	約4.6倍高速 ＆ 上限撤廃で 全199記事を完全網羅
短語3条件検索 search "税|靴|3%"	全セクション LIKE 総なめ	24.40 ms（内部 19.45 ms）	1〜2文字語句のフルスキャンを根絶
コード行番号検索 code "encodeShortTermForFts"	約 150〜210 ms	8.07 ms（内部 4.26 ms）	瞬き以下でファイルと物理行番号を特定
全2,313会話の短語検索 convos "AI|DB"	150MB本文 LIKE 総なめ	65.06 ms（内部 57.68 ms）	超頻出の2文字複合検索でも一瞬で抜粋
2つのSQLite合計ファイル容量	979.2 MB	717.3 MB	索引を追加しつつ VACUUM 等で −261.9 MB 軽量化

---

なぜSQLiteの全文検索にGPUを使うと遅くなるのか

「GPU で SQLite を高速化できないか？」というアイデアが壁にぶつかる理由は、ソフトウェアの工夫不足ではなく ハードウェアの物理構造そのもの にあります。

検索本体より重いPCIeデータ転送の往復ロス

現在、私たちの SQLite データベースは mmap_size（OS メモリマップ）によって、64GB あるメインメモリ（RAM）の上に丸ごと常駐しています。CPU から見れば、すでに自分の目の前の机の上にすべての本が開いて並んでいる状態です。

ところが、独立型の GPU（今回の Radeon Pro 5300 など）にこの文字列を探させようとすると、まずメインメモリから PCIe バスという連絡通路を通って、GPU 専用のメモリ（VRAM）へ数百 MB のテキストデータを丸ごと引っ越し（コピー） させなければなりません。

たとえば 300MB のテキストを PCIe 3.0 経由で GPU へ送り、シェーダー（計算プログラム）を起動し、一致した位置リストをまた CPU 側へ送り返すだけで、準備と片付けに 25〜50 ミリ秒前後 が吹き飛びます。その時間があれば、CPU が手元のメインメモリ上で検索から表示まで全部終わらせてお釣りが来てしまうのです。しかも VRAM が 4GB しかない環境では、画面描画（5K ディスプレイ）の領域と取り合いになり、かえってシステム全体の動作を重くしてしまいます。

条件分岐に弱いGPUと意味検索との明確な境界線

ここで詳しい方なら、きっとこう思うはずです。「じゃあ PCIe コピーが不要な Apple シリコン（M4 Pro などのユニファイドメモリ搭載 Mac）なら、GPU で全文検索した方が速いのでは？」 と。

実は、ユニファイドメモリ環境であっても 「厳密なキーワード一致検索や行番号カウント」には CPU の方が向いています。理由は GPU の計算方式（SIMT：単一命令・複数スレッド）にあります。

GPU は「32 個や 64 個のスレッドが一糸乱れず全員まったく同じ掛け算・足し算を繰り返す処理（3D グラフィックスや AI の行列計算）」では無敵の速さを発揮します。しかし、日本語を含む UTF-8 テキストの検索では、「このバイトは 1 バイト文字か 3 バイト文字か？」「大文字と小文字のどちらか？」「改行コードは何番目か？」といった 細かな条件分岐（IF 文）が 1 文字ごとに発生 します。グループ内の 1 人でも違う分岐に入ると、他のメンバー全員が待ちぼうけになる「分岐ストール」が起き、GPU の並列パワーが激減してしまうのです。

AI エージェントが記事やコードを正確に編集する場面では、「なんとなく似ている場所」ではなく 「正確な語句と物理行番号」 が不可欠です。だからこそ、GPU に無理やり文字列をなぞらせるのではなく、CPU の中に眠っている潜在能力を 100% 引き出すルート が大正解になります。

---

CPUの潜在能力を解放した3つの高速化アーキテクチャ

では、これまで Node.js（kb_query.mjs）単体で動かしていた SQLite 検索のどこに伸びしろが残っていたのか。ボトルネックを解剖し、既存のコマンド体系は 1 ミリも変えないまま裏側に組み込んだのが以下の 3 段ロケット構造 です。

検索待ち0ms・横断48msを実現した『CPU極限チューニング』3層構造

高速化 ③：待ち時間の完全分離

裏プロセス非同期差分同期（Stale-While-Revalidate）

クールダウン経過時も検索応答を一切止めず、排他ロック付きのデタッチド子プロセスが裏側で静かに DB を最新化します。

検索直前の 50〜2,000ms フリーズを 0.00ms へ解消

高速化 ②：1〜2文字フルスキャン根絶

超軽量コンテンツレス索引（short_fts）× 遅延取得

AI・DB・税・靴・3% などの短語を 36 進トークン化して圧縮行番号リストに格納。150MB 会話本文の総なめ LIKE を廃止しました。

候補を数ミリ秒で絞り込み、上位件のみ本文デコード

高速化 ①：ネイティブ並列エンジン

Pure Rust × CPU内蔵 AVX2（32バイト一括）× 12スレッド並列

外部クレート依存ゼロで libsqlite3 に直結。RAMDisk 常駐バイナリ（kb-search）が全候補と生 MDX を一斉スキャンします。

CPU内蔵AVX2とRust並列による32バイト一括照合

1 つ目の柱は、現代の CPU の中に標準搭載されている SIMD（Single Instruction, Multiple Data：1 回の命令で複数データを同時処理する仕組み） の解放です。

通常のプログラム（スカラ処理）は、文字列を探すときに端から 1 バイトずつ順番に比較していきます。しかし Intel / AMD の x86_64 CPU が持つ AVX2 命令（256-bit ベクトルレジスタ） を使えば、たった 1 回の CPU 命令で「32 バイト（半角 32 文字分）」を横並びで一気に比較し、一致した位置をビットマスクとして瞬時に取り出す ことができます（Apple シリコン等の ARM64 環境でも同種の NEON 命令や高速フォールバックで安全に動作するよう分岐させています）。

今回は外部パッケージへの依存が一切ない Pure Rust で検索専用エンジン（kb-search）を書き起こし、以下の 3 点を徹底しました。

前回作成した憲法ゲート（gemini-gate）と同様、バイナリ本体は RAM ディスク（/Volumes/RAMDisk/$USER/tmp/kb-search-bin/kb-search）へ自動コンパイルされるため、内蔵 SSD を 1 バイトも削らず 0 ミリ秒で直接起動します。しかも従来の JavaScript 版横断 grep では速度維持のために「記事ヒット上限 50 件」で打ち切っていた制限を撤廃し、全 199 件のヒット記事を 1 件残らず網羅した上で、実行時間は 223.5ms から 48.8ms へ約 4.6 倍速く なりました。

日本語1〜2文字の総なめを消す軽量short_fts

2 つ目の柱は、SQLite の日本語全文検索における最大の弱点だった 「1〜2 文字キーワード問題」の根本解決 です。

前回の SQLite 解説記事 でも触れた通り、日本語の部分一致に便利な FTS5 (tokenize='trigram') は 3 文字単位で索引を作るため、『AI』『DB』『税』『靴』『3%』といった 1〜2 文字の言葉ではインデックスがまったく使えません。そのため従来は、1〜2 文字が含まれるときだけ LIKE '%AI%' のような全文総なめ検索へ切り替えていました。

記事数が数百本のうちはそれでも動きますが、2,313 スレッド（純粋テキストだけで約 150MB〜360MB 規模）のチャット履歴 DB で LIKE フルスキャンが走ると、毎回すべての会話本文を端から展開して調べるため約 200 ミリ秒以上の負荷がかかっていました。

そこで今回導入したのが、1〜2 文字専用の超軽量コンテンツレス FTS5 索引（short_fts） と 遅延取得（Late Materialization） の組み合わせです。

-- 1〜2文字トークン専用の超軽量コンテンツレス FTS5 テーブル定義例
-- content='' で本文の重複保存をゼロにし、detail='none' で行番号リストのみを最小圧縮保持
CREATE VIRTUAL TABLE IF NOT EXISTS conversations_short_fts USING fts5(
  tok,
  content='',
  contentless_delete=1,
  detail='none',
  tokenize='ascii'
);

仕組みはとてもシンプルです。文章を登録するときに、文字コードポイントを 36 進数の短い英数字トークン（1 文字なら u<36進>、隣り合う 2 文字ペアなら b<文字1>x<文字2>）へ決定論的に変換して short_fts に登録しておきます。

さらに重要な工夫が 「本文を最後まで読まない遅延取得（Late Materialization）」 です。たとえば『AI』という超頻出ワードで 1,200 件の会話がヒットしたとき、いきなり 1,200 件すべての長大な会話本文（計百 MB 超）をデータベースから引き出すと、そのページ展開だけで遅くなります。そこで、まずは軽量な管理テーブルと結合して 「更新日時が新しい順の ID リスト」だけを数ミリ秒で確定させ、画面に抜粋を表示する上位件だけ WHERE rowid = ? でピンポイントに本文を取り出す 構造にしました。これにより、最も過酷な超頻出 2 文字検索でも引っかかりなく即答できるようになりました。

検索待ち0秒を実現する裏プロセス非同期差分同期

3 つ目の柱は、体感速度に一番直結していた 「検索する瞬間の差分同期ブロック」の解消 です。

これまでは「検索コマンドを叩いたとき、前回の同期から 5 秒（会話 DB は 20 秒）以上経っていたら、まずその場で差分同期を実行してから検索結果を返す」という直列の仕組みになっていました。変更がない普段は 30 ミリ秒程度で終わるのですが、ちょうど会話ログが伸びている最中に検索すると、検索結果が出る前に 1.5〜2.0 秒ほどの「同期完了待ち」が割り込んでいた のです。

具体的には、クールダウン時間を過ぎていたら 「今の検索自体は既存の DB で 0 ミリ秒の待ちもなく即座に実行して結果を返し、同時に切り離された裏プロセス（デタッチド子プロセス）を起動して次回の検索までに差分同期を済ませておく」 ように分離しました。連続で検索したときに裏プロセスが何個も多重起動してぶつからないよう、プロセス ID（PID）とタイムスタンプ付きの排他ロックファイル（.bg_sync_*.lock）でしっかりガードしています。

---

実機で踏んだ罠とDB容量が逆に262MB減ったカラクリ

今回の実装とテストを進める中で、机上の理論だけでは絶対に気づけない 「macOS 特有の罠」 と、嬉しい誤算だった 「データベース容量の大幅ダイエット結果」 が得られたので共有します。

macOS標準SQLiteのWAL共有メモリ未作成の罠

Pure Rust 製の検索エンジン（kb-search）をビルドし、データベースを破壊しないよう安全第一で C 言語 API の SQLITE_OPEN_READONLY（完全読み取り専用フラグ） を指定してテストしていたときのことです。

データベースの最適化（VACUUM）を終えて接続を閉じた直後に検索コマンドを走らせた瞬間、なんと unable to open database file（データベースファイルを開けません） というエラーが出て止まってしまいました！ファイルは目の前に実在し、権限も問題ないのになぜ開けないのか。

原因を掘り下げると、SQLite 公式ドキュメントにも記されている WAL モードと共有メモリファイル（-shm）の仕様 に辿り着きました。

1. SQLite の WAL モードでは、通常の同期処理が終わって最後の接続が正常に閉じられる（close）と、一時ファイルである .sqlite-wal と .sqlite-shm がきれいに自動削除されます。
2. その直後、-shm ファイルが存在しない状態で macOS 標準の libsqlite3.dylib に SQLITE_OPEN_READONLY を渡して開こうとすると、読み取り専用モードゆえに新しい -shm 共有メモリファイルを作成（O_CREAT）できず、エラー（SQLITE_CANTOPEN）を返してしまうのです。

この罠を 100% 安全に突破するため、Rust 側の接続ラッパー（sqlite_ffi.rs）に以下の 「二段構えオープン＋即座の書き込み物理遮断」 を実装しました。

// macOS 標準 libsqlite3 における WAL `-shm` 未作成時の CANTOPEN 回避パターン
// 1. 通常環境では READWRITE フラグで開いて `-shm` のマップ生成をOSに許可し、
//    クエリを1行も実行する前に `PRAGMA query_only = ON` でデータ変更を100%物理遮断する。
// 2. 読み取り専用サンドボックス環境で READWRITE オープン自体が拒否された場合のみ、
//    自動的に SQLITE_OPEN_READONLY へフォールバックする。
let mut rc = unsafe {
    sqlite3_open_v2(
        c_path.as_ptr(),
        &mut db_ptr,
        SQLITE_OPEN_READWRITE | SQLITE_OPEN_NOMUTEX,
        std::ptr::null(),
    )
};
if rc != SQLITE_OK || db_ptr.is_null() {
    if !db_ptr.is_null() {
        unsafe { sqlite3_close_v2(db_ptr) };
        db_ptr = std::ptr::null_mut();
    }
    rc = unsafe {
        sqlite3_open_v2(
            c_path.as_ptr(),
            &mut db_ptr,
            SQLITE_OPEN_READONLY | SQLITE_OPEN_NOMUTEX,
            std::ptr::null(),
        )
    };
}
// 直後に query_only = ON を適用（INSERT / UPDATE / DELETE 等はエンジン層で完全拒否）
conn.exec_batch("PRAGMA query_only = ON; PRAGMA temp_store = MEMORY;")?;

あわせて、macOS の隔離サンドボックス内では標準の一時フォルダ（/var/folders/...）への書き込みが拒否されて SQLite のソート処理が転ぶことがあるため、起動時に TMPDIR の書き込み可否をプローブし、不可なら自動で /tmp へ退避する処理も組み込みました。この修正を入れた瞬間、どんなタイミング・どんな並列実行でもエラーゼロで安定稼働するようになりました。

索引を増やしたのに979MBから717MBへ縮んだ理由

もう 1 つ気になるのが、「1〜2 文字用の新しいインデックスを全記事・全会話に追加して、データベースの容量は膨らまなかったのか？」 という点です。

結論から言うと、新しい索引（short_fts）を追加したにもかかわらず、最適化コマンド（node ./scripts/sync_knowledge_db.mjs --optimize）を実行した結果、導入前より合計 261.9MB（− 26.7%）も逆に小さくなりました。

対象データベース・ストレージ	導入前のサイズ	short_fts 追加＆最適化後	容量の増減とメモリ収容率
知識DB（knowledge.sqlite）	388.1 MB	213.6 MB（空き 0.0 MB）	−174.5 MB（512MB mmap 枠の 41.7%）
会話履歴DB（conversations.sqlite）	591.1 MB	503.7 MB（空き 0.0 MB）	−87.4 MB（1GB mmap 枠の 49.2%）
2つのDB合計サイズ	979.2 MB	717.3 MB	合計 −261.9 MB の軽量化に成功
母艦の内蔵SSD空き容量	—	440 GiB / 932 GiB	DB合計はSSD空き容量の 約 0.16% のみ

なぜインデックスを増やしたのにこれほど劇的に縮んだのでしょうか。カラクリは以下の 2 点にあります。

結果として、知識 DB（213.6MB）も会話履歴 DB（503.7MB）も、割り当てている OS メモリマップ枠（512MB と 1GB）の 半分以下のサイズ にすっぽり収まりました。SSD の空き容量（440GiB）を圧迫する心配も、メモリから溢れる心配もまったくありません。

---

まとめ：64GBメモリ母艦の快適単価とAI自動構築手順

今回の検証を通じて改めて実感したのは、「高価な GPU を無理に振り回すより、データの通り道（メモリと索引構造）を整えて CPU 本来のベクトル命令を引き出す方が、シンプルで圧倒的に速い」 というシステム設計の原則でした。

毎日使えば缶コーヒー1本分で手に入るミリ秒開発環境

なお、このように 「16GB の RAM ディスク」＋「計 1.5GB 枠の SQLite メモリマップ常駐」＋「Rust のオンデマンド並列コンパイル」＋「ブラウザと AI エディタの同時稼働」 をスワップ（SSD への退避による速度低下）なしで涼しい顔で回し切るには、やはり 64GB メモリを積んだ母艦 Mac が圧倒的な安心感をもたらしてくれます（32GB 以下のユニファイドメモリ機では、RAM ディスクとメモリマップだけで半分以上が埋まり、並列ビルド時にメモリ圧縮やスワップが発生しやすくなります）。

一見すると 64GB メモリ構成は贅沢に見えるかもしれませんが、使用期間で割った「1 日あたりの快適コスト」を試算してみると見え方が変わります。推論（試算）ですが、たとえば約 22万〜25 万円クラスの 64GB メモリ搭載 Mac mini（または中古の 27 インチ 5K iMac 本体＋自己増設 64GB メモリ構成）を 5 年間（1,825 日）毎日開発や執筆の相棒として使い倒した場合、1 日あたりのコストは約 120〜137 円（缶コーヒー 1 本分、1 日 4 時間作業なら 1 時間あたり約 30 円強） にしかなりません。自分が手を汚さず AI と Rust エンジンに一瞬で探し物を片付けさせる「タイム・イズ・マネー」の投資として、これほど費用対効果の高い足回りはありません。

これから新しく Apple シリコン世代で 64GB 環境を組むなら、後からメモリ増設ができない構造を踏まえ、最初から Pro 系チップ・64GB ユニファイドメモリ構成を選べるコンパクト母艦 Apple Mac mini（Pro系チップ・64GB構成） が本命になります。

一方、広大な 5K ディスプレイ（5,120×2,880）と大容量 64GB メモリを最もコストパフォーマンス良く手に入れたい方には、当サイトでも現役バリバリで今回の AVX2 ベンチマークを叩き出した Intel 最終世代の名機 iMac 27インチ Retina 5K（2020年モデル） に、背面の扉から工具なしで増設できる 【Intel Mac増設用】Crucial DDR4-2666 SO-DIMM メモリ を組み合わせるルートもまだまだ現役で輝きます（※ DDR4 SO-DIMM は Intel Mac 専用であり、Apple シリコン搭載 Mac には装着できないためご注意ください）。

また、717MB に引き締まった大切な SQLite データベースと Time Machine バックアップを外付けで高速保護する用途には、APFS フォーマット済みで箱から出してすぐ使える超小型ポータブル SSD Crucial X9 Pro For Mac を 1 台繋いでおくと万全です。

最上位AIに記事URLを見せて安全に段階構築する手順

最後に、ご自身のブログや個人開発プロジェクトに今回の「SQLite × Rust SIMD 並列検索 × 短語 short_fts × 非同期同期」を取り入れたい方へ大切なポイントをお伝えします。

今回解説した WAL の -shm 未作成時のオープン順序 や コンテンツレス FTS5 の旧 rowid 削除漏れ防止、CPU アーキテクチャ（x86_64 の AVX2 か、Apple シリコン ARM64 の NEON か）の自動判別 は、軽量な AI モデルに雑に丸投げすると安全境界線を読み飛ばしてバグを混ぜ込みやすい領域です。

導入する際は、必ず 『Gemini 4 Argon』または同等以上の最上位推論モデル を選び、いきなりコードを書かせるのではなく以下のプロンプトをコピー＆ペーストして「手元環境の事前調査と実装計画のすり合わせ」から始めてみてください。