AI の記憶に「健康診断」ツールを作った——診断はするが、手は出さない
目次
前回は、いくつかのプロジェクトの AI 記憶ライブラリを体系的に「除草」し、記憶が劣化する六種類の「雑草」を整理しました。ですが除草を進めるほど確信が強まりました——手作業の除草は対症療法にすぎない、と。記憶システム自体に「自己点検」の仕組みがない限り、雑草は抜いてもまた生えてきます。そこで前回の最後に、自分への宿題を残しました——「自動で健康診断してくれる記憶ツールを作る」。この記事は、その宿題の提出です。
まず、このツールが何をするものかを話させてください。話はそこからです。
記憶ライブラリ専属の医者、とイメージしてください。あるプロジェクトの記憶ライブラリを指定すると、頭から末尾までスキャンし、見つけた問題を一つずつ目の前に並べます——このリンクは切れている、その記憶はフォルダを間違えている、この二つは矛盾して見える……。そしてそこで止まり、一件ずつ「どうするか」をあなたが決めるのを待ちます。
この「あなたが決めるのを待つ」を最初に置いたのには理由があります。それがツール全体の性格を決めているからです——見ることと伝えることだけを担い、手は出さない。
🩺 「見る」だけ——あなたの代わりに手は出さない
なぜこう設計したのか。前回の一番痛い教訓に戻ります——記憶を削除するようなことは、AI に丸ごと委ねてはいけない。どれを削るか、どれを統合するかを提案するのは構いませんが、最後に判を押すのは人でなければなりません。削られるのは往々にして履歴の記録で、AI は勢いのまま、大事なものまで一緒に消してしまいがちです。
そこでツールを作るとき、この教訓を一つの絶対ルールにしました——プログラムのどこにも、記憶ファイルを自分から書き換えたり削除したりするコードパスは存在しない。スキャンし、問題ごとに重みづけし、直し方まで用意して並べることはできます。ですが実際に「変更」や「削除」を押す一手は、あなた自身のものです。
こう言うと損に聞こえます——ツールを作っておいて、一番働ける部分を切り落としたのですから。ですが、まさにこの抑制があるからこそ、毎日つけっぱなしで使えるのです。勝手に記憶へ手を出すツールに替えたら、私は一度も使う気になれません。
🔍 機械は「明白な傷」を、Claude は「意味」を読む
手を出さない話をしたので、次は何を見つけられるかです。ツールが拾う問題は、実は二種類あり、扱いがまるで違います。
一つは、機械が一目で判定できる明白な傷です——リンクの指すファイルが存在しない、記憶がフォルダを間違えている、命名が規約に反している……。これらは内容の理解を要さず、ルール照合で決着がつき、見誤りません。
もう一つは、ずっと厄介です。たとえば「この二つの記憶は互いに矛盾しているか」は、表面の文字だけでは判定できず、それぞれが何を言っているのかを本当に読む必要があります。この種の仕事には、言語を理解できるモデルが欠かせません。好都合なことに、このツールはもともと Claude Code のプラグインです。実行時にはすぐ隣に Claude がいる——意味を読める、出来合いのモデルがそこにいるのです。わざわざもう一つ外付けする必要はありません。
そこで、明白な傷はローカルの小さなエンジンへ——ネットにつながず、どんなモデルも呼ばず、同じライブラリなら毎回まったく同じ結果を返します。意味の理解を要する判断は、ホストの Claude——まさに今あなたと一緒に作業しているモデルへ渡します。こう分けると、ツールは API key を一切必要とせず、外部サービスにも依存せず、記憶の内容は一文字も端末の外へ出ません。
この考え方に沿って、チェックを三層に並べました。最も確実なものから、最も頭を使うものへ。
- 静的チェック（明白な傷）：エンジンの主力で、速く正確です——デッドリンク（命名がハイフンからアンダースコアへずれ、リンクが静かに切れる）、宙に浮いた索引（索引には載っているのにファイルが無い）、孤立した記憶（ファイルはあるのに索引に載っていない）、フィールド欠落、命名不備、フォルダ間違い。どれも機械が一目で見抜き、誤判定しない傷です。
- 当て推量（手がかり）：たとえば「開発中」「承認待ち」と書かれたまま長く更新のない記憶は、たいてい用事はとうに済み、ステータスだけが凍りついています。この層が出すのは手がかりで、断定ではありません。
- 意味を読む（セマンティクス）：前回の一番厄介な二つの「雑草」——プロジェクトがグローバルなルールをもう一度写した「ゴーストコピー」と、逆に見えて実はそれぞれ別の場面を担当している「偽の矛盾」——は、内容を読み込まないと判定できません。この層はホストの Claude へ。読んで提案し、判断は私が下します。
三層を通し終えると、ツールは問題を赤・黄・緑で重みづけし、一件ずつ一緒に確認していきます——このデッドリンクは直す？ この孤立記憶は索引に足す？ この凍りついたステータスはもう終わっている？ あなたが「直す」と言ったものだけを直し、飛ばしたものには一切触れません。
⏰ 時が来たら知らせる——でも、うるさくしない
健康診断だけでは足りません。記憶メンテナンスの最大の敵は「直し方が分からない」ことではなく、そもそも直すのを忘れることだからです。前回、記憶は定期的な手入れが要ると書きましたが、「定期的」を気合いに任せると、実質ゼロです。
そこでツールにリマインドを付けました——作業を始めるたび、今のプロジェクトの記憶ライブラリが長く点検されていなければ、そっと一言「🩺 前回の点検から N 日」と告げます。
ですがリマインドは、多すぎればノイズになり、ノイズは無視されます。そこで二つの制約をかけました——一日にせいぜい一度、セッションごとに飛び出したりはしない。そして本当に煩わしければ、コマンド一つで止められる。
📌 今できること、できないこと
正直に言います。
できること：六つの検出器、旧フォーマット記憶の移行提案、日英バイリンガル出力——今はすべて動きます。自分の九つのプロジェクトの記憶ライブラリを一つずつ点検し、デッドリンク・古い命名・凍りついたステータスを一気に片づけました。
できないこと（これも意図して引いた線です）：
- 意味の理解を要する判断は、最後に人の一頷きが要る。ツールは助言するだけ。
- あなたの代わりに、勝手に何かを書き換えることは決してしない。
- 小さなライブラリや新しいライブラリでは効果は限られる。本当に元が取れるのは、長く積み上がった大きなライブラリです。
記憶を扱うツールが最もやってはいけないのは、独断で動くことです。
ツール自体は今のところ自分用ですが、最初の一行からオープンソース基準で書いています——テスト完備、きれいな履歴、日英両方のドキュメント。いつ、どう公開するかは、自分が十分に使い込んで信頼できてから決めます。ですのでこの記事にはリンクを載せません。クリックして空振りさせないためです。
💡 振り返って、三つの学び
- 「手を出す」ツールには、まず境界を先に決める。 操作が不可逆なほど、有能なツールは危険になります。「決して独断で動かない」を絶対ルールにしたからこそ、安心して使えるのです。
- リマインドや通知を作るなら、「止められるスイッチ」を残すのを忘れない。 メッセージをどうユーザーの目に届けるかばかり考え、つい忘れます——しつこいリマインドは、最後には無視される。止められるリマインドこそ、本当に読まれるのです。
- 自分の作ったツールは、自分がまず厳しい最初のユーザーになる。 形だけ動かして済まさず、本当に仕事に使ってこそ、誤判定や見落としが一つずつ表に出てきます。
次回：loop の話をしよう
記憶については——構築から、除草、そして今回の健康診断ツールまで——ここで一区切りです。次回は話題を変えて、loop の話を。AI を一定のリズムで自分で走らせ、繰り返しの仕事を、私が見張らずとも続けさせる、その方法についてです。
あなたも AI の記憶ライブラリを育てているなら、あるいは自分のツールに「この線は越えない」というルールをいくつか設けようとしているなら、この記事が少しでも助けになれば幸いです。役に立ったと感じたら、いいねや、AI 記憶に同じく取り組む誰かへのシェアが、何よりの励みになります——あなたの一回のシェアが、書き続ける力になります。
コメント