個人RAGの健全性を、意志でなく仕組みで毎週点検する — 多角ヘルスチェックと、その実行を強制する時限ゲート
はじめに
個人で、外付けの長期記憶のような仕組みを運用している。日々の作業ログや判断を放り込むと、意味の近いものを検索で引き出してくれる RAG（過去の記録をベクトル検索で呼び出す仕組み）だ。前提はこの記事に譲る。
AI に5回訂正された夜 — 個人 RAG を5年付き合える相棒にする設計思想
作って動かすまでは、誰でも一度はやる。難しいのは「それが今も正しく動いているかを、毎週きちんと確かめ続ける」ことだ。この記事は二つのことを扱う。ひとつは、記憶が健全かを多角的に点検する中身。もうひとつは、その点検を「気が向いたら」「気づいたら」ではなく、仕組みで毎週強制するようにした話だ。
何をもって「健全」とするかを、先に決めた
「なんとなく動いている」では点検にならない。何がどうなっていたら健全で、何が起きていたら異常か、観点を先に定義した。5つの軸に分けている。
| 軸 | 何を見るか | どの異常を捕まえるか |
|---|---|---|
| 稼働・破損 | DBに件数照会・取得・検索を投げて、即クラッシュしないか | ファイルを直接開く形式のDBの索引（検索を速くする内部の目次）の破損 |
| 整合性 | 二系統に分けて持つ記録の件数差が、一定に保たれているか | 片方だけ壊れる・欠ける不整合 |
| 取り込み | 日々の自動取り込み処理のログにエラーが無いか | 記録が静かに入らなくなる詰まり |
| 検索 | 関連クエリで妥当な結果、無関係な入力で暴発しないか | 誤った高確信ヒット・クラッシュ |
| バックアップ | 多層のバックアップがすべて最新日付か | 復元できないバックアップ（後述の別記事） |
「相棒の記憶は健全か？」
│
┌──────────┬─────────┼──────────┬────────────┐
▼ ▼ ▼ ▼ ▼
稼働/破損 整合性 取り込み 検索 バックアップ
│ (件数差) (エラー0) (正常+異常) (多層が最新)
│ │
└─ 触った瞬間に └─ 無意味語・空入力で
クラッシュ＝破損の兆候 高確信の誤ヒットを出さない
軸①の「索引破損」は、過去に二度この記憶を全損させかけた壊れ方だ。その顛末と根治は別記事にある。
「ファイルを直接開くDB」を複数プロセスで触って、二度壊した — 書き手を一つに絞って根治するまで
正常系だけの点検は、「壊れない」を示さない
点検で一番手を抜きやすいのが、④の検索だ。「関連する言葉で引いて、それらしい結果が出た。OK」——これは**正常系（うまくいく入力）**しか見ていない。正常系の合格は「正しく動く」を示すだけで、「壊れない」は示さない。
だから点検には、わざと**異常系（境界・不正・敵対的な入力）**を混ぜる。
正常クエリ「撤回マーカーの仕組み」 → 近い記録が上位（関連度：高） … 期待どおり
無意味語 「qwzxlkjhgfd」 → クラッシュせず・関連度は明確に低い … 暴発しない
空クエリ 「 」 → クラッシュせず・低関連で返す … 暴発しない
見たいのは「無関係な入力に対して、もっともらしい誤ったヒットを高確信で返さないか」だ。検索は、当てにいくときより、外すべきときに正しく外せるかで質が分かる。正常系で満足した点検を「多角的に確認した」とは呼ばない。
ここまでは中身の話。問題は、点検を「やらなかった」ことだった
観点も手順も揃っていた。にもかかわらず、この点検は定期的に実行されていなかった。実際に回したのは、「ちゃんと動いてる？」と外から問われたときだった。決めごととしては「毎週点検する」と思っていた。だが、それは頭の中の決意でしかなく、実行を保証する関門が無かった。
これは既視感のある失敗だ。以前、「破壊的操作の前にバックアップを取る」と決めていたのに、実体を作らないまま進めて記憶を壊したことがある。構造はまったく同じ——「やると決めた」と「やった」の間に、何の強制も無い。
「バックアップを取る」と決めただけで実行せず、記憶用のベクトルDBを二度壊した話
規律を「意志」や「記憶」に預けると、抜ける。人間でも、手を動かすAIアシスタントでも同じだ。だから今回は、意志に頼るのをやめた。
解決 ― 意志でなく、時限ゲートに載せる
やったことは単純だ。前回の点検完了日を1つのファイルに記録し、そこから一定期間（7日）経ったら、セッションを開いた瞬間に「点検の期限だ」と自動で差し込む。差し込まれた側は、その場で点検を実行し、終えたら完了日を今日に更新する。次の7日まで、もう催促は来ない。
セッション開始
│
▼
完了印の日付を読む ──(無い/壊れ/空)──┐ ← 安全側：とにかく「期限」扱い
│ 正常な日付 │
▼ │
今日 − 前回 ≥ 7日 ? ──いいえ──▶ 何もしない（黙って通す）
│ はい │
▼ ◀─────────────────────────────┘
「点検の期限」をセッション冒頭に注入
│
▼
点検を実行 → 結果を報告 → 完了印を今日に更新
│（更新し忘れたら）
└──────────────▶ 次回また催促（＝取りこぼしに強い）
肝は二つある。ひとつは、完了印が壊れていたり空だったり無かったりしたら、安全側に倒して「期限」とみなすこと。点検し忘れる方向にではなく、余計に催促する方向に倒す。もうひとつは、完了印の更新を忘れても、次のセッションでまた催促が来ること。取りこぼしても、いずれ必ず引っかかる。
期限が来ていれば、セッションを開いた瞬間に、こういう催促がそのまま冒頭に差し込まれる（パスや内部名は伏せた実出力）。
[週次ゲート] 個人RAGの週次ヘルスチェックの期限です。前回=2026-07-01 / 27 日経過。
この手元のセッションで点検を実施すること（クラウドからは手元のDBに届かない）:
(1)稼働/破損 (2)整合性 (3)取り込み (4)検索(正常+異常) (5)バックアップ鮮度
実施後、完了印を今日の日付に更新する。
期限内なら、この催促は出ずに黙って素通りする。出るか出ないかだけの差だが、これで点検は「気が向いたらやる」から「期限が来たら必ず目に入る」に変わる。
この「助言を強制に引き上げる」という考え方そのものは、別の場面で一度作り込んでいる。原則の議論はそちらへ譲る。
AIコーディングアシスタントに「やらせない」仕組みを作る — 助言から強制へ、そして関門に空いていた横穴
仕組みが「動く場所」を取り違えない
このゲートを作るとき、危うく踏みかけた罠がある。点検の対象は、手元のPCで動いているDBと、手元にしか無いログだ。もしこの点検を、手元を離れた環境（クラウド上の実行など）で回そうとすると、そこからは手元のDBにもログにも届かない。
厄介なのは、届かないときの壊れ方だ。到達できずに点検できなくても、「エラー無しで終わった」ように見えてしまう——失敗が、無言のまま成功に化ける（サイレント・フォールス・ネガティブ）。ヘルスチェックにとってこれは最悪で、「点検しているつもりで、実は何も見ていなかった」を生む。
だから、催促の文面にも仕組みの前提にも、「この点検は必ず手元のセッションで行う」を明記した。定時に自動で回すこと自体が目的ではない。確かに見たという事実が目的だ。届かない場所で空回りするより、届く場所で確実に一度見るほうがいい。
関門そのものを、多角的にテストした
点検の実行を強制する関門を作ったなら、その関門自身が正しく働くかも、正常系だけでなく確かめる必要がある。ここでも同じ規律を自分に課した。
- 正常系：前回から十分経っていれば催促が出る／まだなら黙って通す。
- 境界：ちょうど期限の日にどう振る舞うか。
- 異常系：完了印が壊れている・空・そもそも無い——このとき「安全側（催促する）」に倒れるか。
異常系まで通して初めて、「この関門は迂回されない」と言える。関門を作って正常系だけ試すのは、鍵を付けて「閉まる」ことだけ確認し、「こじ開けられないか」を試さないのと同じだ。（内部の正確な手順や設定値は、ここでは伏せる。仕組みの考え方が伝われば足りる。）
決めた規律を、「続く形」にする
作ったのは大げさな監視基盤ではない。点検の観点を多角に定義し、その実行を意志でなく期限に紐づけただけだ。それでも効果ははっきりしている。「毎週やる」という決意は、放っておけば必ず風化する。風化しても、来週にはまた同じ場所で引っかかる——その一点で、決意は「続く規律」に変わった。
反復する保守は、真面目さでは続かない。続くように構造へ落として、はじめて続く。記憶を壊れないように保ち、汚れないように正し、測れるようにする話は、対になる三本に書いた。この記事は、それらをこの先も健全なまま保ち続けるための、点検の仕組みの話だ。
AWS S3 + restic で相棒の脳を暗号化オフサイトバックアップ — 記憶を”平文のままクラウドに上げず”に遠隔退避する