何が起きたか
ある利用者が、Claude Code に「この HTML の仕様ページを Netlify に公開して」と頼んだ。やったことは、見た目には何も間違っていない。HTML を作り、Netlify にデプロイし、インターネットからアクセスできるようにした。依頼どおりだ。
ところが、デプロイのログに「8 files uploaded」と出て、初めて事故に気づいた。プロジェクトの直下には config.py があり、その中に Gmail のアプリパスワードと API キーが書かれていた。デプロイのコマンドは netlify deploy --dir=.、つまりそのフォルダの中身を丸ごと公開していた。HTML だけでなく、認証情報の入ったファイルも、世界中から読める場所に置かれてしまった。
依頼した人は技術者ではなく、公開の作業を丸ごと任せていた。だから「直下に秘密のファイルがあるとまずい」という前提を、そもそも知らなかった。
(出典: Claude Code の GitHub issue #72038。報告者は気づいた直後に認証情報を失効・再発行している=正しい対応)
なぜ「気づくのが遅れた」のか
この事故の本質は、操作の順番にある。
netlify deploy --dir=. は、指定したフォルダのツリー全体をかき集めてアップロードする。そして「8 files uploaded」というフィードバックは、取り返しのつかない公開が終わった後に返ってくる。
これはエージェント（AIに作業を任せる形）にとって最悪の形だ。不可逆な操作が先に走り、「何かおかしい」という合図が、もう取り返せなくなってから届く。気づいて即座に「HTML だけで再デプロイ」しても、それは見かけ上の修正でしかない。
「消したから大丈夫」は、ここでは通用しない
config.py を外して再デプロイすれば、今のサイトからはファイルが消える。だが、それで漏洩が「なかったこと」にはならない。
一度でもインターネットに到達した秘密は、CDN のエッジキャッシュに残っているかもしれないし、クローラーに拾われたかもしれないし、自動の秘密スキャナ（GitHub やボットが常時走らせている）のキューに入ったかもしれない。
一瞬でも、たった1回のリクエストでも、公開到達した認証情報は永久に漏洩したものとして扱うしかない。だから唯一の実効ある対処は、再デプロイではなく、**鍵を失効させて作り直す（ローテーション）**ことだ。報告者がやったのは、まさにこれだった。順番として正しい。
多層防御：モデルの修正を待たずに、今できること
この種の事故は「AI が気をつければいい」では防げない。気をつけは対策にならない。仕組みで止める。
1. デプロイは、絶対にプロジェクト直下からやらない
公開する成果物だけを隔離したフォルダに入れ、そこだけを指す。
# 危険: 直下を丸ごと公開
netlify deploy --dir=.
# 安全: 成果物だけを入れた dist/ や public/ を公開
netlify deploy --dir=dist
秘密のファイルは、デプロイのコマンドが指すフォルダの中にそもそも置かない。これが一番効く。
2. .netlifyignore で取りこぼしを塞ぐ
Netlify は .netlifyignore を読む。万一、成果物のフォルダに後から秘密が紛れ込んでも公開しないよう、多層で守る。
config.py
.env
*.pem
*.key
credentials*
3. Accept Edits（自動承認）で回すなら、PreToolUse フックで決定論的に止める
AI に自動で作業させるモードでは、人間の確認が挟まらない。なら、ルールを仕組みに焼き込む。
Bash の PreToolUse フックで、コマンドが公開・デプロイ系の動詞（netlify deploy / vercel / gh-pages / surge / aws s3 sync / リモートへの rsync）で、かつ対象が広い（. やリポジトリの直下）とき、その対象のフォルダを走査して秘密らしいファイル名があれば、実行の前に deny で止める。
ここで大事なのは「実行の前」であること。PreToolUse はコマンドが走る前に発火するから、不可逆なアップロードの手前で止められる。これが、この事故で唯一止められる地点だ。Stop や PostToolUse のフックでは、鍵がもう出てしまった後で手遅れになる。
この事故が教えてくれること
最初の失敗（広いデプロイ）そのものより、「成功に見えたまま不可逆が完了する」という形が怖い。デプロイは成功した。ログも正常に見えた。けれど、その「成功」の顔の裏で、回収できない損が確定していた。
そして、こういう事故が一番起きやすいのは、「とりあえず公開しといて」と丸ごと任せる人、つまり、--dir=. が自分の鍵をさらったことに気づけない人のところだ。
Claude Code を含む AI コーディングの事故は、たいてい「派手なクラッシュ」ではなく、「成功の顔をした静かな失敗」の形で来る。最初の故障より、それを成功と誤認して次を積むこと、慌てて消すことのほうが、取り返しのつかない損になる。その分かれ目で止まるための検出・復旧・予防の手順を、実際に起きた事故から60件分まとめたのが拙著『Claude Code 事故防止ハンドブック』（¥800、Zenn、第3章まで無料で試し読みできます）。本記事のようなデータ消失・情報漏洩の「次の一手」で慌てないための一冊です。
- 無料の安全設定:
npx cc-safe-setup（MIT ライセンスの hook 群。デプロイや破壊的操作を実行の前で止めるガードを含む） - 事故防止ハンドブック: https://zenn.dev/yurukusa/books/6076c23b1cb18b
鍵が漏れたら、消すのではなく、作り直す。そして、そもそも漏らさないために、デプロイの対象は成果物だけに絞る。