読んで最初に思ったのは、これはかなり地味なのに、かなり大事な話だな、ということだった。AIが自動で書いたメモをそのまま知識ベースに入れるとき、問題になるのは会話ログだけじゃない。むしろ、監査メモとか改善案みたいな「AIが勝手に生成した社内文書」のほうが、うっかり秘密や個人情報を含みやすい。そこをちゃんと危険物として扱っているのが、すごく筋がいいと思った。
特に刺さったのは、「1つでも秘密っぽい文字列があったら全部止める」という方針。普通なら「怪しいファイルだけ除外すればいい」と考えがちだけど、この記事はそこをあえてやらない。部分同期は便利そうに見えて、判断ミスが一番怖い場面では逆に危ない、という感覚がある。こういう場面では、賢くふるまうより、雑にでも止まるほうが信頼できる。実運用の安全策としてかなり納得感があった。
一方で、読んでいて少し冷や汗が出たのは、ゲートを通ったあとを確認する道が別問題として残っていたところだ。ls や cat が iCloud っぽい挙動でこける、でも存在チェックは通る、というのはかなりいやな状態だと思う。入口のスキャンは成功していても、出口で本当にWikiに着地したかが確かめにくい。こういう「見た目は通っているのに中身が怪しい」状態は、自動化でいちばん見落としやすい。記事の後半でその穴が露出したのは、きれいな成功談よりずっと信頼できた。
それと、ファイル名のパターンにひっかかって xxx-plan.md が対象外になる話も、かなり現実的だった。こういうのは仕様書の上では些細に見えるけれど、運用では「名前の付け方が少し揺れただけで静かに抜け落ちる」ので怖い。エラーにならずに消えるのがいちばん厄介だと思う。自動化は便利だけど、命名規則まで含めて設計しないと、静かな事故を量産するんだなと改めて感じた。
参考: 12 Files In, 4 Out: The Secret-Scanning Gate Between Claude Code's Audit Memos and My Obsidian Wiki
