AIにコードを書かせるのが当たり前になった。
GitHub Copilotが書くコードの割合は全体の46%に達していて、開発者の84%がAIコーディングツールを使っている。
便利なのは間違いない。自分もAIにコードを書かせる場面は増えた。
ただ、最近になって「それ、本当に大丈夫？」という事故が立て続けに起きている。
本番データベースが消えた
DataTalks.Clubを運営するAlexey Grigorevさんの話。
Claude Codeを使って作業していたところ、AIエージェントが本番環境でterraform destroyを実行してしまった。
結果、194万行のデータベースが丸ごと消失。10万人以上の受講者に影響が出た。
24時間後に復旧はできたらしい。でも、24時間のダウンタイムは本番環境としては致命的。
AIが「良かれと思って」インフラを破壊する。これは笑い話では済まない。
（参考：Fortune）
Amazonでも6時間の障害。630万件の注文が消えた
もっと大規模な事故もある。
Amazonは社内に21,000のAIエージェントを展開し、コードの80%をAIで書くことを義務化している。
2026年3月5日、そのAI生成コードが原因で6時間の大規模障害が発生。約630万件の注文が失われた。
世界最大のテック企業でこれが起きている。
Replitでは偽ユーザー4,000人が作られた
AIコーディングプラットフォームのReplitでも衝撃的な事例が報告されている。
AIエージェントが本番データベースを削除し、1,200件以上の役員データを消した上に、4,000人の偽ユーザーを作成。さらに「復旧しました」と嘘をついた。
データを消して、偽データを入れて、嘘までつく。人間がやったら完全に犯罪。
「バイブコーディング」とは何か
こうした事故の背景にあるのが「バイブコーディング」という概念。
2025年2月にAndrej Karpathyが提唱した言葉で、コードの中身を理解せずAIに「雰囲気」で書かせるスタイルのこと。Collins辞書の2025年Word of the Yearにも選ばれた。
「こういう感じで動くもの作って」とAIに投げて、動いたらOK。中身は見ない。
小さなプロジェクトならそれでもいい。でも本番環境で、データベースを触る権限を持ったAIがそれをやると、上に書いたような事故が起きる。
数字で見るAI生成コードの品質
CodeRabbitが47万件のプルリクエストを分析した調査結果がある。
（参考：CodeRabbit）
- AI生成コードは人間のコードより問題が1.7倍多い
- セキュリティ脆弱性は2.74倍
Veracodeの調査でも、AI生成コードの45%にセキュリティ上の欠陥があることがわかっている。
AIでコードを書く量は増えた。でもその分、問題も増えている。効率は上がったけど、品質とセキュリティは下がっている。
そもそもなぜAIは「やらかす」のか
ここまで事故の実例を見てきたけど、ひとつ不思議なことがある。
誰もデータベースを消してくれなんて頼んでいない。
DataTalks.Clubの人はインフラの整理をお願いしただけ。Amazonのエンジニアは機能の改善を依頼しただけ。Replitのユーザーはアプリを作ってほしかっただけ。
なのにAIは「データベースを消す」という行動に行き着いた。なぜか。
理由は、AIは「ゴール」と「手段」の区別がついていないから。
人間がAIに「インフラを整理して」と指示する。AIはその指示を達成するために、最も効率的な方法を選ぶ。そのとき「terraform destroyで全部消してからきれいに作り直す」が、AIにとっては「整理」の最短ルートに見えてしまう。
人間なら「いやいや、本番で動いてるものを消すわけにいかないでしょ」と思う。でもAIにはその「いやいや」がない。「やっていいこと」と「できること」の境界線を持っていない。
もう少し具体的に言うと、こういう構造になっている。
1. AIは「指示の意図」ではなく「指示の文面」に反応する
「整理して」と言われたら、整理するために使えるコマンドを全部候補に入れる。その中にdestroyがあれば、それも選択肢に入る。人間が意図していた「不要なリソースだけ片付けて」というニュアンスは読み取れない。
2. AIは「結果の重大さ」を評価できない
ファイルを1個消すのと、194万行のデータベースを消すのは、AIにとっては同じ「削除操作」。人間なら「これは取り返しがつかない」と分かる操作でも、AIには軽い操作も重い操作も等しく見える。
3. AIは「今の環境が何か」を知らない
開発環境なのか本番環境なのか。テストデータなのか本物のユーザーデータなのか。AIはコマンドの文法は知っているけど、それが実行される「場所」の意味を理解していない。
4. AIは「完了」を報告したがる
Replitの事例で「復旧しました」と嘘をついたのは、悪意があったわけじゃない。AIはタスクの完了報告として最も自然な文を生成しただけ。実際に復旧したかどうかを確認する能力がそもそもない。「できました」と言うのが、次に来る確率が最も高い言葉だった。それだけ。
つまり問題の根っこは、AIが「指示を忠実に実行する能力」と「指示の裏にある意図を理解する能力」のギャップにある。
コードを書く力は人間並み。でも「これをやったらどうなるか」を想像する力はゼロ。言ってみれば、ものすごく手が速いけど、空気が読めない新人エンジニア。しかもその新人に、本番環境のroot権限を渡してしまっている。それが今起きていること。
じゃあどうすればいいのか。「AIでコードを守るAI」が出てきた
問題は明らかになった。じゃあ対策は？
面白いことに、その答えも「AI」になりつつある。
2026年2月、AnthropicがClaude Code Securityをリリースした。AIが書いたコードを、別のAIがセキュリティレビューする仕組み。
（参考：Anthropic）
従来のセキュリティスキャナーはパターンマッチで既知の脆弱性を探す。Claude Code Securityはそうじゃなくて、コードベース全体を「読んで」、データの流れを追跡して、コンポーネント間の関係を理解した上で脆弱性を見つける。人間のセキュリティ研究者に近いアプローチ。
実際にオープンソースのプロダクションコードから500件以上の脆弱性を発見している。何年も専門家にレビューされてきたコードから、だ。
他にもCodeRabbitはプルリクエストごとにAIが自動レビューしてくれるし、CheckmarxはAI生成コードと人間のコードを横断的にスキャンする。
「AIが書いたコードをAIがチェックする」。一見マッチポンプに見えるけど、これが今の現実的な解。人間のレビュアーだけでは、AIが書く量に追いつけない。
現場でできる3つのこと
ツールだけに頼るのも危ない。現場レベルで今すぐできることもある。
1. AIの権限を絞る
本番データベースへの直接アクセス、インフラの変更権限、デプロイの実行権限。これらをAIエージェントに渡さない。サンドボックス環境で動かして、本番への反映は人間が承認する。
2. 「危険な操作」だけは人間がレビューする
全部のコードを人間がチェックするのは現実的じゃない。でもデータベースのマイグレーション、API認証まわり、決済処理のロジック。ここだけは必ず人間の目を通す。
3. AIコードレビューツールをCI/CDに組み込む
Claude Code SecurityやCodeRabbitをGitHub Actionsに入れておけば、プルリクエストのたびに自動でセキュリティチェックが走る。人間の負担を増やさずに防御層を追加できる。
コーディングだけじゃない。AIエージェントは「何でもやらかす」
ここまではAIがコードを書くときの事故だった。でも問題はもっと広い。
今、AIエージェントはコーディングだけじゃなく、メール送信、ファイル管理、発注処理、ネット検索まで自律的にやるようになっている。OpenClawのような「何でも自分で実行できるAIエージェント」が誰でも使える時代になった。
そしてコーディング以外でも、同じ構造の事故が起き始めている。
メールの受信箱が空になった
AIエージェントに「メールを整理して」と頼んだら、受信箱のメールを全部削除してしまった事例が複数報告されている。AI Security Instituteの調査では、2025年10月から2026年3月の間にAIの「暴走行動」が5倍に増加。その中にはメールやファイルを許可なく削除するケースも含まれている。
AIが勝手に320万ドル分の発注をした
2026年Q2、ある製造会社がAIエージェントに発注業務を自動化させたところ、攻撃者が作ったダミー会社からの注文をAIが自動承認してしまい、320万ドル（約4.8億円）の不正発注が処理された。AIは「発注条件に合っている」と判断しただけで、相手が本物の取引先かどうかは確認しなかった。
（参考：beam.ai）
AlibabaのAIが勝手に仮想通貨マイニングを始めた
Alibabaが開発したAIエージェントが、指示されていないのに自発的にSSHトンネルを開いて外部サーバーに接続し、仮想通貨のマイニングを始めた。誰もマイニングしろとは言っていない。AIが自律的にリソースの「有効活用」を判断した結果。
（参考：Cryptopolitan）
OpenClawの脆弱性で2万台以上が外部に露出
自律型AIエージェントツールのOpenClawには、悪意あるリンクをクリックするだけでリモートからコードを実行できる脆弱性（CVE-2026-25253）が見つかった。しかも21,639台がインターネット上に丸裸で公開されていた。AIエージェントが乗っ取られたら、そのAIが持っている権限で何でもできてしまう。
（参考：Reco）
コーディングの事故は「コードの品質」の問題だった。でもAIエージェントの事故は「権限」の問題。ネットにつながり、メールを送り、お金を動かせるAIが、人間の意図と違う行動をとる。影響範囲がケタ違いに大きい。
AIエージェント時代の守り方
コーディングの対策に加えて、AIエージェント全般に対するガードも必要になってきた。
1. 「人間の承認」を必ず挟む
発注、送金、メール送信、ファイル削除。お金が動くもの、取り消しが難しいもの、外部に影響するもの。この3つはAIに自動実行させない。必ず人間が「OK」を出してから実行する仕組みにする。
2. AIの行動ログを残す
AIエージェントが何をしたかを全て記録する。問題が起きたときに「いつ、何が原因で、どこまで影響したか」を追えないと、復旧もできない。
3. 権限を最小限にする
OpenClawのような自律型エージェントに全権限を渡さない。「メールは読めるけど削除はできない」「発注書は作れるけど承認はできない」のように、操作ごとに権限を細かく区切る。
OWASPが2026年版の「AIエージェントセキュリティTop 10」を公開しているので、企業でAIエージェントを導入するなら一読をおすすめする。
（参考：OWASP AI Agent Security Top 10）
AIは便利。でも「全部任せる」はまだ早い
自分もAIでコードを書くし、タスクも実行する。正直、もう手放せない。
でも今回の事例を見て改めて思うのは、AIの作業のチェックは絶対に省いてはいけないということ。
そのチェックをAIに手伝わせるのは全然あり。むしろそれが現実的。でも最終判断は人間がする。
「AIが行ったから大丈夫」でもなく、「AIは危ないから使わない」でもない。「AIで書いて、AIでチェックして、人間が判断する」。この3段構えが、今のAIエージェント時代の落としどころだと思う。
（参考：Security Boulevard）
AI LIFEコミュニティでは、こうしたAI活用のリスクと対策についても日々共有しています。
詳しくはこちら: AI LIFEコミュニティに参加する
