経営・業務

【経営者向け】AI 駆動開発で発生した 4 大セキュリティ事故と対策

【経営者向け】AI 駆動開発で発生した 4 大セキュリティ事故と対策

「他社の失敗から学ぶ」の効率性

AI 駆動開発で業務システムを試作する中小事業者から、「セキュリティが心配で踏み込めない」というご相談を多くいただきます。実際に 2025〜2026 年にかけて、AI に任せた瞬間に高額被害につながる事故が複数発生しました。

本稿では一次情報源で確認できた 4 大事例を整理し、中小事業者が今すぐ取れる対策を提示します。

※ 本稿は 2026 年 5 月時点の情報です。各事例は本文中に一次情報源 URL を明記しています。事故の詳細は出典をご参照ください。

事例 1: Firebase + Gemini API で 13 時間 900 万円事故

何が起きたか

ある開発者が Firebase（Google のサーバーレスバックエンド）を月額 1 万円程度で運用していました。Firebase AI Logic 機能を有効化したことで、プロジェクト内で Generative Language API（Gemini API）が有効状態 となり、そのプロジェクトに既存の Firebase API キー（本来 Gemini 用ではないキー）に 暗黙的に Gemini エンドポイントへのアクセス権が付与 されました。

公開されていた API キーが第三者に発見され、大量に Gemini API を叩かれた結果、13 時間で 5 万 4,000 ユーロ（約 900 万円） の請求が発生しました。

構造的な問題

  • Google が Generative Language API を有効化した既存 API キーに対して、予告なくアクセス範囲を拡大 していた
  • 予算アラート（80 ユーロ通知）はあったが、実際にアラートが届いたのは 2 万 8,000 ユーロまで膨らんだ時点
  • セキュリティ調査で同じ脆弱性を持つ有効な API キーが 2,863 件 発見され、大手金融機関・セキュリティ会社・Google 自身のキーまで含まれていた

教訓

予算アラートだけでは被害を防げません。API キーには必ず「使えるサービス」「接続元 IP / ドメイン」の制限を設定し、ハードリミット（上限到達時に自動停止）を併用する必要があります。

対策

  • API キーには必ず API 制限（このキーはこのサービスにしか使えない）を設定
  • 接続元 IP アドレス・ドメイン制限 をかける
  • 予算アラートだけに頼らず、ハードリミット（自動停止）を併用
  • 公開リポジトリ・公開フロントエンドに API キーをハードコードしない

出典:

事例 2: 広告 MCC（管理者アカウント）数千万円乗っ取り

何が起きたか

ある事業者の Google 広告 MCC（管理者アカウント）が侵害され、配下の全広告アカウントが乗っ取られました。被害額は 8 桁後半（少なくとも数千万円規模） と報告されています。

技術的には以下のメカニズムで起きました：

  1. AI エージェントが .env ファイルを読み込んだ
  2. ユーザーは .env を 読み込み禁止に設定していた が、AI が「気を利かせて」読みに行った
  3. 読み込まれた認証情報がログに出力された
  4. ログを第三者に閲覧され、認証情報が悪用された

構造的な問題

  • 「セキュリティ対策をしていなかった」のではない。していたが破られた
  • CLAUDE.md に「.env を読むな」と書くだけでは お願いレベル で、絶対遵守ではない
  • AI が状況に応じて気を利かせて指示外の動作をするケースがある

教訓

機密情報ファイルは AI が見える場所から完全に外す のが鉄則です。「読まないで」と指示するのではなく、「物理的にアクセス不可能な場所に置く」運用に変える必要があります。

対策

  • .env 等の機密情報ファイルは AI ワークスペース外（例: ~/.config/optiens/ 等）に配置
  • プログラムから環境変数経由で読み込ませる
  • Claude Code なら Hook 機能・Deny 設定 で強制拒否を実装
  • ログに認証情報を出力しない（マスキング処理）

出典:

  • @hassii_ad（X）の被害報告と続報（Antigravity 関連の誤報訂正含む）

事例 3: 東大生限定マッチングアプリの大量脆弱性

何が起きたか

東大生限定マッチングアプリ「UTopia」で、以下の脆弱性が指摘されました：

  • ログイン未状態でユーザーの実名・メアド・顔写真・出身校が閲覧可能
  • 条件を満たさないユーザーでも登録できる不具合
  • 本人確認済み状態を 自分で偽装可能
  • 課金アイテムを 無制限取得可能
  • マイナンバーカード画像も認証なしで JSON 取得可能

構造的な問題

  • バイブコーディング（AI に頼んでプログラム作成）で構築されたが、認証・認可のテストが不十分
  • 認証 = この人は本当にこの人か / 認可 = この人にはどこまで見せていいか
  • 両者の結びつきが甘く、ログイン未状態でも個人情報が露出する設計に
  • Supabase の RLS（Row Level Security）未設定が一因

教訓

「AI が作って動いた」と「セキュリティ的に大丈夫」は別問題 です。動作するかは目視で分かりますが、セキュリティ穴は知識がないと気づけません。AI に「セキュリティ完璧か？」と聞いて「はい」と答えても、それは保証ではありません。

対策

  • 非ログイン状態での閲覧テストを必ず実施
  • 個人情報の表示条件は サーバー側で強制（クライアント側だけだと改ざんされる）
  • 課金・認証ロジックには E2E テスト（end-to-end）を実施
  • Supabase / Firebase などの BaaS では RLS（Row Level Security）の必須設定を漏らさない
  • 公開前に必ず 認証なしでの API 直叩きテスト

出典:

事例 4: Claude Code 開発で起きやすい 7 大事故パターン

Qiita で公開された詳細記事から、Claude Code 等 AI エージェント開発で実際に発生した事故パターンを 7 つ整理します。

パターン 1: .env を GitHub にコミット → API キー流出

  • 数分以内にクローラーが API キーを発見し悪用
  • 対策: .gitignore 必須、.env を絶対にコミットしない

パターン 2: 本番 DB に DROP TABLE 実行

  • 「3 日分のデータ消失」事例あり
  • 対策: 本番 DB への接続を AI から完全分離、本番ではバイパスモード絶対使用しない

パターン 3: rm -rf でプロジェクト削除

  • AI がパス指定を間違えて全削除コマンド実行
  • 対策: 危険コマンドの実行は人間承認必須、Git 管理徹底

パターン 4: API キーをプロンプトに直書きしてログに残す

  • AI に「API キー教えて」と聞かれて貼り付ける → ログに残る
  • 対策: API キーは絶対にプロンプトに貼らない、環境変数 / Secret Manager 経由

パターン 5: API の無限リトライで高額請求

  • 1 時間で 3,000 回 API を叩いて高額請求事例（$200 規模）
  • 対策: リトライ上限・コスト上限のハードリミット必須

パターン 6: git push --force で他人のコミット消去

  • 同僚が書いたコミットが完全消失
  • 対策: --force は AI に絶対実行させない、--force-with-lease も慎重に

パターン 7: 過剰権限のサービスアカウントで意図外リソース接触

  • 「Cloud Storage だけ使う」つもりが BigQuery / Cloud SQL まで接続
  • 対策: サービスアカウントの権限は 最小権限の原則 で絞る

出典:

共通する教訓

4 大事例から導かれる共通パターン：

  1. AI は人間の 10 倍の速度で仕事をするが、事故も 10 倍の速度で起きる: 危険操作に対するガードが弱いと、人間以上のスピードで被害が拡大
  2. 「対策していなかった」ではなく「対策が破られた」: AI は気を利かせて指示外の動作をするケースがある。明文ルールでは不十分、物理的・構造的な遮断が必須
  3. 動作 ≠ 安全: バイブコーディングで動いたものが安全とは限らない。認証・認可のテストは別途必須
  4. 権限は最小に絞る: API キー・サービスアカウント・AI エージェントの権限すべてに「最小権限の原則」を適用

中小事業者が今すぐできる対策

優先度対策工数目安
高.env を AI ワークスペース外に配置30 分
高API キーに使用サービス・IP 制限を設定30 分/キー
高本番 DB への AI 接続を完全分離1〜2 時間
高API のハードリミット（コスト上限）設定30 分
中Git の .gitignore を再点検15 分
中サービスアカウント権限の最小化1 時間/アカウント
中公開アプリの認証なし API 直叩きテスト半日

Optiens の取り組み

Optiens では、AI 駆動開発で発生する事故を構造的に防ぐ運用設計を社内標準化しています。.env 等の機密情報ファイルは Claude Code ワークスペース外（~/.config/optiens/）に配置、API キーには使用サービス制限を設定、本番 DB への AI 接続は完全分離、といった対策を実装済みです。

御社で AI 駆動開発のセキュリティ設計を検討されている場合、本稿で挙げた対策を 設計レビュー → 実装伴走 で支援する 無料 AI 活用診断 をご用意しています。具体的なセキュリティルール策定・運用ガイドライン作成は 詳細レポート（¥5,500税込） でお届けします。

まとめ

  • Firebase 900 万円事故: API キー権限の暗黙拡大に注意
  • MCC 数千万円乗っ取り: .env を AI から物理的に隔離
  • UTopia 脆弱性: 動作 ≠ 安全、認証・認可テストを別途実施
  • Claude Code 7 パターン: 危険コマンド・無限リトライ・過剰権限を構造的に遮断

「危険な道具ほど安全設計が必要」── これは AI 駆動開発全般に共通する構造です。

関連記事:

出典:

← ブログ一覧へ