AIにvaultを書かせるときのガードレール｜3層の防衛と、それでも防げないもの
MCPでvaultを繋いだところまではよかった。読ませるだけなら安全だ。では、書き込みも任せていいのだろうか。
この記事で分かること
- AIにvaultを書かせたときに起きる事故は、上書きだけではないこと
- Gitによる可逆化、差分承認、書き込み領域の分離という3層の防衛
- 壊れたことに気づく経路は一つではないこと
- 並行書き込みだけは3層でも防げず、フォーマット自体に由来すること
その夜、vaultで起きていたこと
「AIにvaultを書かせると何が壊れるか」を調べ、その調査結果を自分の知識ベースにファイリングしている最中に、まさにその事故が起きた。
作業していたのはObsidianのvaultを兼ねたGitリポジトリで、新しいページを7本追加し、既存のインデックスに項目を書き足したところだった。まだコミットはしていない。そこへ、別に走っていたセッションが自分の作業をコミットした。
結果として、性質の違う2つの事故が同時に起きていた。どちらもエラーにはならず、画面上には何の警告も出ていない。
一つめは、未コミットの追記7行が無関係なコミットメッセージのコミットに巻き込まれたことだ。内容は消えていない。ただ、その変更が「なぜ入ったのか」を履歴から辿る手がかりは失われた。
二つめのほうが重い。インデックスの先頭には、最終更新の内容を1行で書く共有の欄がある。こちらが書いた値を、向こうのセッションが読み込み、書き換え、保存した。差分を見ると、こちらの値は履歴に一度も現れないまま相手の値に置き換わっていた。
いわゆるlost updateである。競合として検出されることもなく、後から書いたほうが静かに勝つ。
なぜエラーにならないのか
Markdownファイルには、トランザクションもロックも競合検出もない。
データベースなら、同じ行を2つの処理が同時に更新しようとすれば待たされるか弾かれる。ファイルにその仕組みは無いので、両方が読んでそれぞれ書き戻せば、あとに書いたほうだけが残る。運用の失敗ではなくフォーマットの性質であり、「気をつける」では対処できない。
あたま正直、事故の当事者になるまでは「複数エージェントの同時書き込みで壊れる」という指摘を、規模の大きなチームの話だと思っていた。実際には、自分ひとりで複数のセッションを動かしているだけで再現する。
壊れたことに、どうやって気づくのか
壊れたことに気づけなければ、どんな防衛策も起動しない。そして気づく経路は一つではない。これまでに起きた消失を振り返ると、発覚の仕方は毎回違っていた。
- 差分を見て気づいた。ページが丸ごと無くなっており、Gitで戻した
- 検索して気づいた。知識ベースに問い合わせたときに、あるはずのページが出てこなかった
- コンフリクトで気づいた。同期しようとして初めて、両側が同じ場所を触っていたと分かった
このうち2つめが一番こわい。差分もコンフリクトも出さずに消えたものは、次にその知識を必要とするまで発覚しない。「無いこと」は目に入らないからだ。
第1層：Gitで壊れてもいい状態を作る
もっとも安価で、もっとも効果が大きい。
vaultをGitリポジトリにしておくと、知識ベース全体が差分の取れる対象になる。何がいつ変わったかを確認でき、間違っていれば戻せる。冒頭の事故を特定できたのも、消えた値が履歴に残っていたからだった。
Obsidian側の実装ではobsidian-gitによる自動コミットが定番になっている。2026年にはAgentic Git Syncのように、同期エラーやコンフリクトをAIが自律的に解決する系統も出てきた。ただしこれは「AIの失敗をAIが復旧する」構成であり、可逆性を人間の手元に残すという目的からはやや外れる。
ここで効いてくるのがコミットの粒度である。冒頭の事故で追記7行が他人のコミットに巻き込まれたのは、一段落した時点でコミットしていなかったからだ。未コミットの変更を長く抱えるほど、巻き込まれる面積が広がる。
そこで記事執筆用のリポジトリでは「一段落したらコミットする」を運用ルールとして明文化し、都度の許可を求めずに実行させている。
第2層：書き込む前に差分を見せる
第1層は事後の巻き戻しであって、事故そのものは防がない。防ぐほうは、書き込みの前に人間が差分を見る関門になる。2026年時点のObsidianのエージェント系プラグインは、おおむねこの形に収束している。
| プラグイン | 承認の方式 |
|---|---|
| Smart Note Agent | 変更をunified diffで提示し、1件ずつ承認または却下してから書き込む |
| AI Co-Editor | ノート上にtracked changes表示（削除は打ち消し線、挿入は緑のゴースト）。フォルダ単位でポリシーを変えられる |
| Codex AI Agent | シェル実行、ファイル変更、権限拡大を承認カードで提示。既定では黙って承認しない |
| Claudian | Plan Modeでファイル操作の前に計画を提示させる |
| Thought Agent | 承認するまでファイルを変更しない。MCPサーバを内蔵 |
このうちAI Co-Editorのフォルダ単位ポリシーは、全面的に承認を必須にするか、スクラッチ用のフォルダでは自動マージするか、指定パスではプラグインごと無効にするかを場所ごとに変えられる。
承認ゲートは安全だが、毎回止まられると使い物にならない。場所によって強度を変えられる設計は、この摩擦を現実的な水準に下げる。
第3層：書き込める場所を絞る
エージェントに開放する領域と、人間が育てる領域を分ける。
チーム運用では、共有のエージェント向けwikiと個人vaultを分け、レビューを通ったものだけ個人ノートに引き込む構成が推奨されている。個人でも同じことはできる。受け皿にあたる層だけを書き込み可能にし、体系化を終えた層は読み取り専用にする、という非対称化だ。
自分の知識ベースでは、この分離を設定で切り替えられるようにしてある。有効にすると、AIは整理済みの層へ直接書き込まず、いったんステージング用のディレクトリにファイルを置く。中身を確認してから本体へ移す。
この設計の利点は、AIの出力品質を信用するかどうかという判断と、書き込みを許すかどうかという判断を切り離せることにある。出力が良くても、置き場所を間違えれば知識ベースは壊れる。
3層でも防げないもの
ここまでの3層で、上書き、誤った場所への書き込み、機微な情報の混入は、かなりの部分まで抑えられる。抑えられないのが、冒頭の事故そのもの、つまり並行書き込みである。
Gitは事後に検知させてくれるが、書き込みの瞬間には介入しない。承認ゲートは自分のセッションの変更しか見せず、同時に走る別のセッションの存在を知らない。領域の分離も、両方が同じ領域を触っていれば効かない。
これを本気で潰すなら、構造化された記憶をSQLiteのような実データストアに逃がす選択肢が出てくる。Markdownを記憶の器として使うことへの批判はこの点を突いており、論者はMarkdownを636行の指示書としてのみ残し、データ本体はSQLiteと組み込みグラフデータベースに置いている。
ただし、その代償としてプレーンテキストの可搬性と人間の閲覧性を失う。Obsidianで開いてリンクを辿れる、という価値と引き換えになる。トレードオフとして扱うほかなく、一般解は無い。
現実的な折衷は、並行して書かせないという運用側の割り切りになる。同じ知識ベースに複数のセッションを同時に走らせないと決めるだけで、この事故は起きない。今回踏んだのは、まさにその決めごとが無かった穴だった。
まとめ
読み取り連携は安全だが、書き込み権限を渡した瞬間から別種のリスクが立ち上がる。
- 第1層：vaultをGit管理下に置き、作業が一段落したらこまめにコミットする
- 第2層：書き込み前に差分を見せる。場所によって承認の強度を変える
- 第3層：書き込み可能な領域を絞り、整理済みの層は読み取り専用にする
- 並行書き込みは3層でも防げない。同時に走らせない運用で回避する
冒頭の事故で消えたのは、更新履歴を1行書いた欄だけだった。被害は軽い。ただ、あれが調査ページ本体で、しかも差分を確認しない運用だったら、消えたことにいつ気づけただろうか。
書かせる前に、気づける状態になっているかを確かめておきたい。
あたまこの記事は、自分の知識ベースを実際に壊しながら書きました。同じ失敗を踏まずに済む人がいれば嬉しいです。
関連記事
コメント