AIと共有するリポジトリの直下に、認証トークンが転がっていた

AIに日々の仕事を任せるようになると、個人情報がチャット履歴、共有リポジトリ、作業ログのあちこちへジワジワ染み込んでいく。ある日の定例チェックで、AIと共有しているprivateリポジトリの直下に、まだgitの管理外の状態で認証トークンがぽつんと落ちていた。すぐに隔離したが、もし放置していれば、自動でコミットされる運用設定によって、そのトークンがgit履歴に焼き込まれていたはずだ。

事件そのものより怖いのは、事故の構造である。著者も指摘するように「気をつける」には再現性がない。良い仕組み同士（前のセッションの未コミット変更を自動回収する機能）が、機密の扱いという別の文脈では悪い方向に噛み合う。この問題は、AIを信頼するか信頼しないかではなく、「仕組みとしてどう線引きするか」という設計の問題だ。

著者が示す解答は「気をつける」ではなく「三層の線引き」である。最深層は「どこにも書かない物」（パスワード、カード番号）。中層が「書くけど公開しない物」（privateリポジトリの個人記録）。表層が「公開する物」（公開前に機密チェック）。加えて重要なのは、自動で即コミットされる経路には機密を流さないという、経路そのものの設計である。gitignoreを防壁にし、公開前は機械と目視の二段チェック、そしてAIに報告させる際は「中身をチャットに書くな」と指示する。すべて「完全ではなく、同じ形の事故を減らす」ための積み重ねだ。

これは個人開発者の工夫だが、中小企業がAIを本格運用するときの警告でもある。社内の意思決定記録、取引先との個別条件、給与・会計情報をAIに預けるなら、預ける前に「本当にこの情報を預けて大丈夫か」を層別に問い直す必要がある。「AIサービスのセキュリティ」ではなく「自分たちの情報設計」が先である。