AIエディタの会話ログでRAMDiskが満杯？直近3日保持とSSD自動退避で空き容量を2倍にした構築録

数週間でRAMDiskを圧迫するAI会話ログの正体

テキストより重いスクショとSQLiteの蓄積

16GB RAMDisk の構築記事 でご紹介した通り、AI エディタは思考ステップやツール実行のたびにログファイル（/brain ディレクトリ）や会話データベース（/conversations/*.db）へ細かい書き込みを繰り返します。これを内蔵 SSD ではなく RAMDisk（毎秒 30GB クラスのメモリ領域）へシンボリックリンクで逃がしておくと、SSD の寿命を守りながらエディタの応答も見違えるほど軽快になります。

ところが、毎日 AI と壁打ちしながらコード改修やブラウザ実機テストを何百回も回していると、ある日思わぬボトルネックが顔を出しました。「純粋なテキスト会話だけなら数千件でも百数十 MB 程度だろう」と高を括っていたのですが、実際のディレクトリの中身はテキストだけではなかったのです。

テキストのやり取りだけなら軽いもんじゃと思うとったけど、AI に画面スクショを撮らせたり調査させたりした分まで全部メモリの上に積み上がっとったんじゃね。

そうなんです！いわば「超高速で作業できる広いデスク（RAMDisk）」の上に、1 か月前に終わった仕事の資料箱まで何百箱も積みっぱなしにしている状態になっていました。

空き容量4GBとファイル数9.8万個の危険水域

実際に整理前の 16GB RAMDisk（/Volumes/RAMDisk/$USER）を df -h で計測したところ、全体で 12GB（使用率 76%） が埋まり、空き容量は残り 4.0GB、さらにファイルシステム上の 使用 inode 数（iused）は約 98,000 個 に達していました。

Chrome の GPU キャッシュや Astro の並列ビルド一時領域、さらには動画ダウンロードの一時受け皿まで同じ 16GB RAMDisk を共有しているため、残り 4.0GB を切ると大きな動画保存や並列ビルドが重なった瞬間に No space left on device（容量不足エラー）を起こしかねない危険水域です。

単純削除はNG！検索速度と容量を両立する3層構造

直近3日だけメモリに残し完了分はSSD倉庫へ

「それなら find /Volumes/RAMDisk/... -mtime +3 -delete の 1 行を定期実行して、3 日より古いログを丸ごと消してしまえばいいのでは？」と思うかもしれません。しかし、エンジニアの実務では 単純な期間削除は絶対にやってはいけない禁じ手 です。

理由は 2 つあります。1 つ目は、週末をまたいで開きっぱなしにしている進行中の会話や、いつでも見返せるようピン留め（★）した重要スレッドまで機械的に虫食い削除してしまい、会話データベースを破損させる恐れがあること。2 つ目は、AI との過去の試行錯誤ログ自体が 「数か月後に同じエラーへ遭遇したときに 0.01 秒で答えを引き出せる最高の一次知識資産」 だからです。

そこで採用したのが、作業頻度に応じて置き場所を自動で変える 「ホット／コールド階層化ストレージ」 の設計です。

検索はSQLiteで即答し再開時のみ1件解凍

前回のクォータ半減＆SQLite 最適化記事 で検証した通り、画像や巨大な中間ログを除いた「純粋な会話テキスト全文」だけであれば、Web 版 Gemini を含む 全 2,199 スレッド分を集めても SQLite ファイル 1 個（約 419MB） に綺麗に収まります。

普段「あのとき書いた設定値なんだったっけ？」と調べる作業はすべてこの conversations.sqlite が 0.01 秒で答えてくれるため、数 GB ある生の /brain フォルダや個別 .db がいつまでも RAMDisk に居座る必要はまったくありません。そして「2 週間前のあの会話の続きをエディタで再開したい！」と思ったときだけ、その 1 件を SSD 保管庫から RAMDisk へ瞬時に自動解凍すれば、普段の省メモリと利便性を 100% 両立できるわけです。

事故ゼロで退避するスクリプトの5重ロック設計

とはいえ、データベースや数万個のファイルをまたぐ移動スクリプトを雑に書くと、「書き込み中のファイルを引き抜いて壊す」「コピー失敗に気づかず元データを消す」といった大事故に直結します。そこで自作した自動退避エンジン（Node.js 標準機能のみで動く archive_cold_brain.mjs）には、古参エンジニアの重箱の隅チェックにも耐える 5 重の安全ロック を組み込みました。

稼働中プロセスを守るlsof終了コード1の罠

実装時に必ず知っておきたい現場の急所が、macOS の /usr/sbin/lsof コマンドが返す 「終了ステータスコードの罠」 です。

一般的な UNIX コマンドは正常終了時にステータス 0 を返し、1 以上はエラーを意味します。ところが lsof は、「指定したディレクトリ配下で現在どのプロセスもファイルを開いていない（該当 0 件）」という正常な状態のときにも終了コード 1（標準エラー出力は空）を返す仕様 になっています。

これを知らずに Node.js の execFileSync をそのまま呼ぶと、エディタを閉じて静かな状態のときに毎回例外が発生してスクリプトが止まってしまいます。以下のように「終了コード 1 かつ stderr が空文字ならオープン中ファイル 0 件の正常終了」と厳密に切り分けるのが鉄則です。

// /usr/sbin/lsof で現在開かれている会話IDを検出（終了コード1の罠を回避）
function detectOpenConvoIds(targetDirs) {
  let stdout = '';
  try {
    stdout = execFileSync('/usr/sbin/lsof', ['-Fn', '--', ...targetDirs], {
      encoding: 'utf8',
      maxBuffer: 32 * 1024 * 1024,
      stdio: ['ignore', 'pipe', 'pipe'],
    });
  } catch (err) {
    const stderrStr = err?.stderr ? String(err.stderr).trim() : '';
    // 該当ファイル0件のとき lsof は status=1 かつ stderr 空で返るため正常扱いとする
    if (err && err.status === 1 && !stderrStr) {
      stdout = err.stdout ? String(err.stdout) : '';
    } else {
      throw new Error(`lsof 検査失敗: ${stderrStr || err.message}`);
    }
  }
  // 出力行（n/Volumes/RAMDisk/...）から開かれている会話IDを抽出して保護セットへ登録
  // ...
}

未統合のWAL結合とコピー後の完全一致検証

もうひとつの急所が SQLite の WAL（Write-Ahead Logging）モードです。AI エディタが生成する .db の横には、直近の書き込み差分を抱えた .db-wal ファイルが残っていることがあります。もし .db 本体だけをアーカイブ先へコピーして .db-wal を消してしまうと、会話の最後の数往復がごっそり欠落したりデータベース破損の原因になります。

そこで退避前に Node.js 標準の DatabaseSync（node:sqlite）で対象 .db を開き、PRAGMA wal_checkpoint(TRUNCATE) を発行して差分を本体へ 100% 書き戻してから単一ファイルとして保管します。このときチェックポイント実行によって .db の更新日時が「今日」に書き換わらないよう、事前に控えておいた元の会話日時を fs.utimesSync で戻しておくことで、時系列ソートも狂いません。

権限エラー時の片側移動防止とDBパス高速更新

さらに「475 件もの会話フォルダが RAMDisk から SSD 保管庫へ移動したら、全文検索用の conversations.sqlite（419MB）が全件を最初から再解析して重くなるのでは？」という点にも先回りして対策を入れました。

差分同期スクリプト側で 「同じ会話 ID でファイルサイズ（file_size）と更新日時（mtime_ms）が一致しており、保存先パス（log_path）だけが /brain から brain_archive へ変わったケース」 を自動判定し、重い JSONL パースや全文検索インデックスの再構築を一切スキップして UPDATE conversations SET log_path = ? の 1 行だけで瞬時に参照先を付け替えるようにしています。

中身は 1 文字も変わっとらんのに、引っ越ししただけで何百冊も最初から読み直しさせたら無駄だもんねぇ。住所録だけ書き換えるなら一瞬だわ！

起動時ゾンビ復活を防ぐ5分周期バックアップ連動

排他ロック内で退避直後にrsync削除を走らせる

自動退避システムを組むうえで最も見落としやすい落とし穴が、「定期バックアップおよび再起動リストアとの競合（ゾンビ復活問題）」 です。

当環境では Mac を再起動しても直近の会話が消えないよう、5 分おきに sync_brain.sh で RAMDisk から SSD 上の brain_backup へ rsync バックアップを取り、次回ログイン時に brain_backup から RAMDisk へ書き戻しています。もし退避スクリプトを別タイマーで動かしたり、バックアップ側の掃除を忘れたりすると、せっかく RAMDisk から 475 件を退避させたのに 次の Mac 再起動時に brain_backup から古い 475 件がそっくりそのまま RAMDisk へゾンビ復活して再び満杯になる という悲劇が起きます。

これを根絶するため、独立した別ジョブは作らず、5 分周期で動く sync_brain.sh の アトミック排他ロック（mkdir ロック）の内側 に退避処理を一本化しました。

実際の sync_brain.sh に組み込んだ連携パートは以下の通りです（個人環境に依存しないよう $USER 形式で記載しています）。

# sync_brain.sh の排他ロック内側（5分周期起動のうち、60分に1回だけ自動退避を実行）
ARCHIVE_STAMP="/tmp/com.user.archive_cold_brain.stamp"
ARCHIVE_SCRIPT="$HOME/Desktop/ai-blog-project/scripts/archive_cold_brain.mjs"

if [ -f "$ARCHIVE_SCRIPT" ]; then
    NEED_ARCHIVE=0
    if [ ! -f "$ARCHIVE_STAMP" ] || [ -n "$(find "$ARCHIVE_STAMP" -maxdepth 0 -mmin +60 2>/dev/null)" ]; then
        NEED_ARCHIVE=1
    fi
    if [ "$NEED_ARCHIVE" -eq 1 ] && [ -x "$NODE_BIN" ]; then
        touch "$ARCHIVE_STAMP"
        "$NODE_BIN" "$ARCHIVE_SCRIPT" --days 3 --inside-sync-lock --quiet 2>/dev/null || true
    fi
fi

# 退避完了直後のスリムな RAMDisk（空でないことを確認）を、起動リストア用バックアップへ差分同期
if [ -d "$RAM_BRAIN" ] && [ -n "$(ls -A "$RAM_BRAIN" 2>/dev/null)" ]; then
    rsync -a --delete "$RAM_BRAIN/" "$BACKUP_BRAIN/"
fi
if [ -d "$RAM_CONV" ] && [ -n "$(ls -A "$RAM_CONV" 2>/dev/null)" ]; then
    rsync -a --delete "$RAM_CONV/" "$BACKUP_CONV/"
fi

この順番にすることで、①まず完了分が永久保管庫（brain_archive）へ 100% 検証保存され、②次に RAMDisk 上から古い分が消え、③その数秒後に起動リストア元（brain_backup）からも rsync --delete で古い控えが綺麗に消去されます。結果として、Mac のログイン時の RAMDisk 復元時間も大幅に短縮される という嬉しい副産物まで得られました。

過去ログを開いた瞬間に3日間再保護する自動解凍

逆に「1 か月前にアーカイブされた過去の会話を、今日またエディタで開いて続きを書きたい！」というときは、自作拡張機能 Convo Mail で「🚀 IDEで開く」ボタンを押すだけです。

裏側のローカルサーバーが対象 1 件だけを SSD 永久保管庫から RAMDisk へ一時ファイル検証付きで即座に呼び戻し、同時に復元したフォルダと .db の更新日時（mtime）を「現在時刻」へタッチ します。これにより、呼び戻した直後の 1 時間タイマーでまたすぐ倉庫へ片付けられてしまうこともなく、そこから再び 丸 3 日間はホット領域として安全に保護される 仕組みになっています。

実測結果：空き容量が4GBから8GBへ一気に倍増

退避前後のRAMDisk使用率と会話件数の変化

実際に手元の母艦 Mac（64GB メモリ搭載・16GB APFS RAMDisk 環境）で初回退避とバックアップ同期を走らせた前後の実測データがこちらです。

空き容量が 4GB から 8GB に倍増して、散らかっていたファイルの数も半分に減ったのに、検索できるお話は 2,199 件のまま 1 個も減ってないでちね！

しかも旧パス（~/.gemini/antigravity/conversations_archive）に分散していた古い .db 365 件（約 1.9GB）も一箇所の永久保管庫へ自動マージできたので、バックアップの管理も一気にシンプルになりました！

余裕ある64GBメモリと高速SSDが快適さの要

今回のように「16GB の RAMDisk を常時確保しつつ、1GB 近い SQLite メモリマップとブラウザ数十タブ、並列ビルドや AI エディタを一切スワップなしで回し切る」には、やはり 物理メモリ 64GB クラスの余裕 と 退避先・Time Machine 用の高速な SSD が快適さの決定打になります。

推論（試算）ですが、たとえば 64GB メモリ環境や高速外付け SSD に追加で 10 万〜 15 万円前後を投資したとしても、毎日使う母艦として 5 年間（約 1,825 日）快適に使えば 1 日あたりの快適コストは約 55 円〜 82 円（缶コーヒー半分以下） です。毎日容量不足を気にして手動でキャッシュ掃除をしたり、内蔵 SSD をスワップ摩耗で縮めたりするストレスが完全にゼロになることを考えれば、これほど費用対効果の高い投資はありません。

これから現行の Apple シリコン搭載機で同じく 64GB クラスの快適母艦を組むなら、後からメモリ増設ができないユニファイドメモリ仕様のため、最初から 64GB 構成を選べる Pro チップ搭載の Mac mini が最もバランスの良い選択肢になります。

Apple Mac mini（Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Amazon 楽天市場 Yahoo!

一方、「27 インチ 5K の広大な画面で作業したい」「初期費用を抑えつつ自分でメモリを 64GB〜 128GB へ増設して RAMDisk 母艦にしたい」という方には、背面のスロット扉から工具なしで DDR4 メモリを差し込める Intel 最終世代の iMac 27 インチ（2020 年モデル）＋ Crucial 製増設メモリの組み合わせが今なお抜群の実用性を発揮してくれます。

【中古・整備済品】Apple iMac 27インチ Retina 5K (2020年モデル / Intel最終世代・メモリ自己増設対応)

Amazon 楽天市場 Yahoo!

【Intel Mac増設用】Crucial iMac 27インチ(2019/2020)・ノートPC用 メモリ DDR4-2666 SO-DIMM (16GB×2 / 32GB×2)

Amazon 楽天市場 Yahoo!

また、数千件に増え続けるコールドアーカイブや Time Machine の多世代バックアップを熱ダレせず毎秒 2,500〜 3,000MB クラスで確実に受け止めるには、アルミ筐体で放熱性に優れた Thunderbolt 3 / USB 両対応のポータブル SSD を 1 台繋いでおくと盤石です。

SanDisk Professional PRO-G40 SSD 4TB / 2TB (Thunderbolt 3 & USB 3.2 Gen 2 両対応)

Amazon 楽天市場 Yahoo!

まとめ：最上位AIに任せて快適環境を自動構築しよう

RAMDisk は「作って終わり」ではなく、日々の運用で蓄積していく AI の生ログやスクリーンショットを 「直近 3 日のホット領域」と「SSD の永久コールド倉庫」へ自動で仕分ける仕組み を入れて初めて、何年使っても息切れしない完成形になります。大切な過去ログを 1 件も捨てずに SQLite で 0.01 秒検索できる状態を保ったまま、メモリ上の空き容量だけを 2 倍に広げるこの 3 層アーキテクチャを、ぜひ手元の開発環境にも取り入れてみてください。

ご自身の Mac 環境に合わせて同様の「直近 3 日ホット保持 ＋ SSD 自動退避 ＋ バックアップ排他連動」を安全に構築したい方は、以下のプロンプトをコピーして AI エディタへ貼り付けてみてください。

以下の記事の設計を参考に、私の Mac 環境でも AI エディタの会話ログ・DBを「直近3日分（＋稼働中・ピン留め）のみ RAMDisk に残し、完了済みは SSD アーカイブへ検証付きで自動退避する仕組み」を構築したいです。
参照URL: https://lab.chihouzakki.com/blog/review/ramdisk-ai-log-3day-hot-cold-auto-archive/

【絶対厳守ルール】
1. いきなりファイルを書き換えたり削除したりせず、まず私の現在の RAMDisk マウント状況（df -h）、AI エディタのログ保存パス、既存の定期バックアップスクリプト（launchd 等）の有無を調査して計画を提示し、私の合意を得てから実装してください。
2. 退避スクリプトには必ず以下5つの安全装置を入れてください：
   - /usr/sbin/lsof によるオープン中ファイルの除外（※該当0件時の終了コード1を正常扱いすること）
   - ピン留め会話および直近3日（--days 3 で変更可能）以内のペア保護
   - SQLite .db-wal が残っている場合の PRAGMA wal_checkpoint(TRUNCATE) 統合と元の mtime 維持
   - 一時ファイル/フォルダへのコピー後、バイト数・ファイル数一致を検証してから元データを削除するアトミック処理
   - まずは1ファイルも消さない確認モード（--dry-run）を実装し、私と一緒にドライラン結果を確認してから本稼働させること
3. 既存の定期バックアップ（rsync --delete 等）がある場合は、再起動時に古い会話がゾンビ復活しないよう、必ず同一の排他ロック内で「退避 → バックアップ同期」の直列順序になるよう統合してください。

一度この自動仕分けパイプラインを仕込んでおけば、もう二度と「RAMDisk がいっぱいになってきたから掃除しなきゃ…」と手を止めることなく、毎朝スッキリ片付いた最高のデスクで創作に没頭できますよ！

▲ 机の上が自動で片付くようになると、スペースに余裕ができてぐっすり安心でちね