預け先のAIが3日で消えたら——外部脳を「特定AIにロックインしない」設計にした理由

先週、公開からわずか3日で遮断された新モデル騒動が「外国製AI依存の盲点」として報じられた。詳しい経緯はここでは深追いしないが、見出しだけで手が止まった。俺は今、外部脳もワークフローも丸ごとClaude Codeに乗せている。もし明日Claudeが使えなくなったら、俺の「脳」ごと道連れになるんじゃないか。

そう思って、外部脳の作りを棚卸ししてみた。結論から言うと、道連れにはならない設計になっていた。狙って作ったわけじゃない。過去に別の理由で決めたことが、後になって役に立っていただけだ。

何をClaude Codeに乗せているか

改めて数えると、かなりの量を乗せている。Obsidianのvaultを外部記憶にして、セッションの最初に読み書きさせている。意味検索も足した人物像と地図を蒸留するpersona/MOCも作った。ミスの記録も、判断の記録も、全部Claude Codeとのやり取りの中で溜めてきた。

これだけ聞くと、思いっきりロックインしている構図に見える。育てた記憶が全部一つのAIツールに閉じていて、そのツールが消えた瞬間に一緒に凍結する。よくある依存の形だ。

中身を見たら、閉じていなかった

でも実際に何が保存されているかを見ると、様子が違う。

vaultの中身は、ただのMarkdownファイルだ。Claude社のサーバーにもClaude専用のフォーマットにも入っていない。手元のディスクに、テキストファイルとして置いてある。これは最初にvaultを作ったとき、公式のメモリ機能の弱点として「中身が不透明」「他AIに引き継げない」を挙げて、その逆を狙った結果だった。あのときは「透明性」のための選択のつもりだったが、今回の騒動で見ると同じ選択が「乗り換え可能性」そのものだったと分かる。

意味検索も同じだ。vault-search は意味検索とキーワード検索を混ぜるhybrid構成だが、どちらもClaudeのAPIを呼んでいない。embeddingはローカルのOllamaで作っていて、検索処理も手元のPythonとsqliteで完結する。Claude Codeが消えても、vault-search "あの件どうやった" は普通に動く。むしろこのCLI自体、Claude以外のどんなツールからでも叩ける形で公開している。

persona.mdやMOC.mdも、生成する手順(/persona-refresh)はClaude Code側のコマンドだが、生成物そのものは一枚のMarkdownでしかない。仕組みが消えても、最後に生成された一枚は手元に残る。次に読ませるAIが変わっても、そのまま読める。

公式メモリ機能はClaudeの中に記憶が閉じ、中身不透明・基準AI任せ・他AIへ引き継げない。外部脳(vault)はただのMarkdownで、Claude CodeでもAIでも読める。Claude専用なのは読み方のルールだけで、ルールはテキストなので書き写せる

唯一Claude専用なのは「読み方のルール」

じゃあ何がClaude専用かというと、これらをどう読み書きするかのルール、つまりCLAUDE.mdの中身だ。セッション開始時にmistakesとpersonaで全体を掴み、hybrid検索でvaultの詳細を掘り、要確認のラベルは鵜呑みにしない——こういう手順は、今はClaude Codeの設定ファイルにしか書いていない。

ただ、これもテキストだ。移すとしたら、この読み書きの手順を別のAIツールの設定形式に書き写せば、大枠は再現できる。知識そのものを作り直す必要がない。一番時間のかかる「vaultを1000ファイル分育てる」工程はもう終わっていて、残るのは「読み方を教える」という軽い部分になる。

依存先を変える作業のコストが、知識の再構築ではなく設定の書き写しに収まっている。これが、棚卸しして分かった一番の収穫だった。

「AI任せにしない」が二重に効いた

こうなっている理由をたどると、一つの方針に行き着く。最初の記事で「記憶の基準をAI任せにしない」ことを決め、それをpersona/MOCの記事で「何を覚えるかをAI任せにしない」と言葉にした。この方針だ。

これは元々、記憶の中身をブラックボックスにしないための方針だった。何が保存されているか自分で把握できて、基準も自分で決められる状態にしておきたかっただけだ。特定のAIから逃げる算段があったわけじゃない。

でも「AI任せにしない」を徹底すると、必然的に「Claude社の中にしか存在しない形」を避けることになる。中身が見える形で持つということは、その中身を他の場所でも読める形で持つ、ということでもあるからだ。透明性を追ったら、結果的に可搬性がついてきた。

もう一つ、graphifyというツールを評価したときに採用した「確信度ラベル」も、ここで別の意味を持ってくる。vaultに書く主張には「検証済み/推測/要確認」を付けている。これは元々、次のセッションの自分が推測を事実だと誤読しないための仕組みだった。でも仮に読み手が別のAIに変わったとしても、このラベルは同じように働く。新しい読み手が、前の読み手(Claude)の推測を鵜呑みにせずに済む。書いた本人(AI)が変わることへの備えにもなっていた。

断ち切る話ではない

これは「Claudeをやめる準備をしている」という話ではない。今もClaude Codeを毎日使っているし、乗り換える予定もない。今回やったのも、実際に何かを移行する作業ではなく、今ある設計を棚卸しして「詰んでいないか」を確認しただけだ。

大事なのは、依存を断ち切ることじゃなくて、依存したまま移行可能性を残しておくことだと思う。全部を自前で作り直すのは非現実的だし、便利なものは使えばいい。ただ、便利さと引き換えに預けたものの置き場所だけは、自分で選んでおく。パスワードの片付けで「その場で見せられるものを信じず、事前に共有した秘密や別の経路に判断を逃がす」という話を書いたが、あれと発想は同じだ。あちらは人間側の情報の守り方、こちらは依存先のAIそのものの守り方。中央の一点に賭けきらず、いつでも動かせる経路を残しておく。

3日で消えたAIの話は、俺には直接関係のないニュースのはずだった。でも「もし自分のAIが消えたら」で棚卸しをしてみたら、過去の設計判断が思わぬところで保険になっていた。狙って作った防御じゃないぶん、見つけたときに少し得した気分になった。