Claudeに任せてはいけないと学んだ失敗事例
成功事例は世の中に溢れています。でも失敗事例は少ない。なぜなら恥ずかしいから。
私たちも恥ずかしいです。でも、同じ失敗を繰り返してほしくないので、正直に書きます。
失敗事例1: マイグレーションの確認をサボった
Section titled “失敗事例1: マイグレーションの確認をサボった”何が起きたか:
本番データベースのスキーマ変更をClaude Codeに依頼しました。「このカラムをnullableに変更して、マイグレーションも作って」と。
Claudeが書いてくれたマイグレーションを、流し読みしてステージングに流しました。「問題なさそう」と感じて本番に適用。
30分後、本番でエラーが多発。Claudeがマイグレーションに NOT NULL 制約を追加するコードも入れていたことに気づきました。「ついでに整合性を高めようとした」ようです。
被害: 約1時間のダウンタイム、データ修正に2時間
教訓:
- マイグレーションファイルは1行ずつ確認する
- 依頼した以上のことをClaudeがやっていないか確認する
- 本番適用前に必ずステージングで全機能をテストする
「ついでに改善」に注意する
Section titled “「ついでに改善」に注意する”これが最も危険なパターンです。Claudeは善意で「ついでにここも直しました」をやります。依頼した範囲を超えた変更が入っていないかを確認することが大切です。
失敗事例2: 全部書き直してもらった
Section titled “失敗事例2: 全部書き直してもらった”何が起きたか:
「このコンポーネントをリファクタリングして」と頼んだら、Claudeが全部書き直してくれました。見た目はきれい。「完璧だ」と思ってコミット。
2日後、似たようなバグが5箇所から報告。調べてみると、Claudeがリファクタリングの過程で「使われていないように見えた」ロジックを削除していました。実は特定の条件でしか通らないエッジケースのコードでした。
被害: バグ修正に半日、ユーザーへの謝罪
教訓:
- リファクタリングを依頼するときは「動作を変えないこと」を明示する
- テストのないコードをリファクタリングさせない
git diffで変更内容を全部確認してからコミットする
失敗事例3: 設計を丸投げした
Section titled “失敗事例3: 設計を丸投げした”何が起きたか:
新機能の設計を「どう設計するか考えて、実装して」と全部任せました。Claudeが提案した設計は技術的には正しかった。でも3ヶ月後、その設計が我々のビジネス要件にまったく合っていないことが判明。
原因: Claudeはビジネスコンテキスト（将来的にB2B展開する予定、マルチテナント対応が必要）を知らなかった。我々が伝えていなかった。
被害: アーキテクチャの大幅な見直し、約2週間の追加開発
教訓:
- 設計はビジネスコンテキストを含めて伝える
- Claudeの設計案は「最終回答」ではなく「たたき台」として扱う
- 将来の要件・制約はCLAUDE.mdに書いておく
失敗事例4: セキュリティレビューをClaudeだけに任せた
Section titled “失敗事例4: セキュリティレビューをClaudeだけに任せた”何が起きたか:
認証機能を実装する際、「セキュリティ上の問題をチェックして」とClaudeに頼みました。Claudeは「問題ありません」と答えた。
リリース後、セキュリティ研究者から「JWTのsecretが環境変数に入っているが、生成に使っているseedが推測可能」という指摘。
Claudeは「secretが環境変数にある」ことは確認してくれましたが、「seedの推測可能性」という実装の問題は見つけられませんでした。
被害: 緊急パッチリリース、影響範囲の調査に1日
教訓:
- セキュリティの最終チェックは専門家（または自分の目）が必要
- Claudeは「表面的な問題」は見つけられるが「設計レベルの脆弱性」は見逃すことがある
- 認証・決済・個人情報に関わるコードは特に慎重に
失敗事例5: 古いドキュメントを信じた
Section titled “失敗事例5: 古いドキュメントを信じた”何が起きたか:
Stripe APIの実装をClaude Codeに頼んだとき、Claudeが少し古いStripe APIのバージョンのコードを書いてきました。当時の最新ではない。動くけど非推奨のメソッドを使っていた。
半年後、非推奨メソッドが廃止されてエラーが発生。
被害: 緊急対応（しかも半年前にClaudeが書いたコードを読み解く作業が必要）
教訓:
- Claudeのナレッジには学習データのカットオフがある
- 外部APIやライブラリを使う実装は「最新バージョンを使っているか」を必ず確認する
// TODO: バージョン確認のコメントを実装時に残す習慣を付ける
まとめ: 共通のパターン
Section titled “まとめ: 共通のパターン”これらの失敗を振り返ると、共通のパターンがあります。
1. 確認をサボった: Claudeが書いたコードを読まずにコミットした 2. コンテキストを伝えなかった: ビジネス要件・制約をClaudeに伝えていなかった 3. 「任せた」が「確認した」より先になった: Claudeに任せることと確認することはセットです
Claude Codeは強力なツールです。でも「信頼」と「確認」は別のことです。信頼しながら確認する——これが3ヶ月の失敗から学んだ正しい使い方です。
読者へのメッセージ
Section titled “読者へのメッセージ”この記事を書いていて恥ずかしいです。でも、同じ失敗をしないためにシェアします。
「Claudeは間違える」ということを頭に入れて使ってください。完璧ではありません。でも、間違いを前提に使えば、ほとんどの失敗は防げます。
あなたが同じ失敗をしないことを願っています。