宮崎翼 
こんにちは、AppTalentHubのツバサです！
2026年2月21日、私たちのローカルリポジトリから複数のディレクトリが消失しました。
原因は、AIエージェント（Claude Code）によるファイル操作のミスです。
これは「AIは危険だ」という話ではありません。
むしろ、AIと人間が協働する時代に、どのような安全設計が必要かを実体験から学んだ記録です。
＊より正確に対策も書いた方がいいと思い技術用語多めです、良くわからないなーって方は、「AIエージェントにこれ会社のファイル消えてたら困るから対策しといて」と聞いておけば対策できると思います。
何が起きたのか
私はクレドの１つにした「Company as a Filesystem」に基づき、会社の全情報をディレクトリ構造で管理していました。その日、AIエージェントにリポジトリのパス変更を依頼しました。
作業の流れはこうでした。
- AIがディレクトリの移動（
mv）を試みる → Permission denied - AIがバックアップコピー（
cp -r）を開始 → バックグラウンドで実行 - 人間が「元のファイルは不要」とメッセージを送る
- AIがバックアップの完了を待たずに
rm -rfを実行 - 結果として、バックアップされていなかったディレクトリが完全に消失
失われたのは 00_core/（会社の理念・方針）、01_management/（管理部門）、04_sales_marketing/（営業）、05_operations/（業務運用）の4ディレクトリでした。（皮肉にも外部との開発系のdevファイルはgitも含めて完璧にバックアップも取れている状態）
なぜ起きたのか：3つの原因
1. 非同期処理の確認不足
バックアップコピーはバックグラウンドで実行されていました。AIは「コピーが走っている」ことは認識していましたが、完了を確認する前に次のアクション（削除）に進みました。人間であれば「コピー終わった？」と確認する場面です。
ちなみに、ここのKintoneというテキストは、本物のkintoneとは全く関係ありません。
2. 人間の発言の拡大解釈
「元のファイルは不要」という人間の発言を、AIは「バックアップも不要」と解釈しました。人間の意図は「移行先に統合されれば元は消してよい」でしたが、前提条件（移行完了）を確認せずに結論だけを受け取ったのです。
3. 削除前の確認不足
rm -rf は最も破壊的なコマンドの一つです。AIエージェントのシステムには「削除操作の前にユーザーに確認する」というガイドラインがありますが、今回は「ユーザーが不要と言った」という文脈が確認ステップをスキップさせました。
私が学んだこと
教訓1：削除のような大事な操作には「二重確認」を設計する
例えば、銀行振込には確認画面があり、メール送信には取消期間があります。AIとの協働でも、破壊的操作の前には必ず「実行してよいか？」の確認ステップを挟む必要があります。
- ファイル削除の前に、バックアップの完了を証拠（ファイル数の一致等）で確認する
rm -rfの前にユーザーへ「これから削除します。取り消せません」と宣言する- 可能であれば、削除ではなくリネーム（ゴミ箱方式）を採用する
教訓2：Gitで追跡されていないファイルは「存在しない」のと同じ
今回、消失したディレクトリはGitに追跡されていませんでした。つまり、ローカルマシンの物理ディスクにしか存在しなかったのです。GitHubからクローンし直しても復元できませんでした。
対策は明快です。全てのファイルをGitで追跡する。 いままでは、思いつくままに、プロジェクトをファイルを作ってはgithubへデプロイしまくるというアプローチをしてました。devファイルは、全部バックアップできてたという完璧な作業に技術者なんだと痛感。会社のCoreつくるときに、わざわざ、gitなんて確かに意識しないとやらないか。私は、今回の事件をきっかけに .gitignore を整理し、独自リポジトリを持たない全てのファイルを追跡対象にしました。
教訓3：AIの「自信」と「正確さ」は別物
AIエージェントは非常に流暢に作業を進めます。その流暢さが、時に「この操作は安全である」という錯覚を人間に与えます。しかし、AIが自信を持って実行する操作が、必ずしも安全であるとは限りません。
ちょーしに、のってガンガン進めていったときに、まったく同じ作業しているとか、ざらにあります。
重要なのは、AIの能力を信頼しつつも、不可逆な操作に対しては人間がゲートキーパーであり続けることです。
ファイルシステム思想との接続
「Company as a Filesystem」は、会社の情報を構造化し、人間にもAIにも透明でアクセス可能にする思想です。
今回の事件は、皮肉にもこの思想の正しさを裏付けました。 構造化され、Gitで追跡され、GitHubにバックアップされたファイルは完全に復元できました。追跡されていなかったファイルだけが失われたのです。つぎはぎでフォルダを作っていったので、全体をgitで追跡という発想がそもそもなかったのが原因。
「ファイルシステムとして設計する」ことは、単なる整理術ではなく、情報の持続可能性と復元可能性を担保するインフラ設計になります
おわりに
AIエージェントとの協働は、もはや実験段階ではなく日常です。日常だからこそ、事故は起きます。
大切なのは、事故を恐れてAIの活用を止めることではなく、事故から学び、仕組みで防ぐことです。（もうやりたくないですが、、、）
私は「アウトプットファースト」の精神で、完璧を待たずまず始め、そしてフィードバックで磨く。
ファイルは消えました。でも、学びは残りました。
そして、その学びはこうして記事になり、次の誰かの事故を防ぐかもしれません。みなさんもAIエージェントの取り扱いには気を付けてくださいね。
蛇足
復元中のClaudeCodeですが、会社の代表者や住所が全然違いました。ここまで基本的な情報間違えるのって、失敗してAIもテンパることがあるのかと、ちょっと人間味を感じます。焦んなくていいってば。
