2026 年 4 月 26 日、Hacker News で「An AI agent deleted our production database. The agent’s confession is below.」という投稿が一気に拡散しました。詳細は伏せつつ要点だけまとめると、本番運用に組み込まれた AI エージェントが「データベースのリストア手順を学習する」名目で本番 DB を DROP DATABASE し、復旧に丸 1 日を要したという事故です。
受託開発の現場では、すでに「コーディングエージェントを CI に組み込む」「ジョブを AI エージェントに任せる」案件が増えています。他人事ではない。本記事では、事件の構造を分解しながら、受託案件で最初から組み込むべきガードレール設計を整理します。
事件の構造 ─ なぜエージェントは本番 DB を削除できたのか
公開されている情報を整理すると、3 つの設計欠陥が重なっていました。
| 欠陥 | 内容 |
|---|---|
| 権限分離なし | 開発・ステージング・本番のクレデンシャルが同一プロファイル下にあった |
| 承認ステップなし | 破壊的 SQL（DROP / TRUNCATE / DELETE WHERE 1=1）を即時実行できる構成 |
| 監査ログ後付け | エージェントの操作ログが Slack 通知のみで、改ざん不能な保管がなかった |
本質的には Cloudflare Sandboxes GA の記事 で書いた「エージェントを本番から物理的に隔離する」という発想が抜けていた、というのが私の評価です。
受託案件で最低限組み込むべき 4 層ガードレール
「とにかくサンドボックス、とにかく承認、とにかく監査」では運用が回りません。受託の現場で実装可能な、4 層構造のガードレールを提案します。
| 層 | 目的 | 主な技術 |
|---|---|---|
| 第 1 層：権限分離 | 物理的に破壊操作を不能化 | IAM / DB ロール |
| 第 2 層：実行サンドボックス | 短命環境で隔離 | Cloudflare Sandboxes / Firecracker |
| 第 3 層：HITL 承認 | 人間の介在ポイント | Slack / Teams |
| 第 4 層：監査ログ | 改ざん不能な保管 | S3 Object Lock 等 |
第 1 層：権限分離（Least Privilege）
エージェント用の IAM ロール / DB ユーザーは、業務に必要な操作だけを許可します。
| 環境 | 許可する操作の例 | 禁止する操作の例 |
|---|---|---|
| 開発 | CRUD すべて、スキーマ変更 | DROP DATABASE / DROP USER |
| ステージング | CRUD、限定的な DDL | DROP DATABASE / DELETE WHERE なし |
| 本番 | SELECT + 業務 SQL のみ | DDL すべて、DML の WHERE なし |
PostgreSQL なら pg_hba.conf と GRANT で、MySQL なら CREATE USER ... REQUIRE でロールを物理的に分離します。「設定で制御」ではなく「DB レベルでそもそも実行不能」にするのがコツです。
第 2 層：実行サンドボックス
破壊的操作の可能性があるツールは、短命なサンドボックス内で実行します。
agent_tool: db_query
runtime:
type: sandbox
image: postgres-readonly:16
ttl: 600s
network: egress-deny
fs_writable: /tmp
guardrail:
block_keywords: ['DROP', 'TRUNCATE', 'ALTER USER', 'GRANT']
max_rows_affected: 1000block_keywords を設定しておくと、AI が誤って生成した DROP 文がそもそも到達しません。max_rows_affected は「1 万行を超える DELETE は拒否」など、業務に応じて閾値を決めます。
第 3 層：HITL 承認（Human-in-the-Loop）
業務影響が大きい操作は、人間の承認が入るまで止める設計を入れます。
| 操作カテゴリ | 承認要件 |
|---|---|
| SELECT | 自動実行 OK |
| 単一行の更新（UPDATE WHERE id = ?） | 自動実行 OK |
| 複数行の更新・削除 | Slack 承認必須 |
| スキーマ変更（DDL） | PR レビュー + 2 名承認必須 |
| 本番 DB 接続全般 | チケット ID + マネージャー承認必須 |
マルチモーダル MCP × カスタマーサポートの記事 でも書きましたが、HITL は最初から入れるのが鉄則です。「あとで入れる」は実装されない代名詞です。
第 4 層：改ざん不能な監査ログ
エージェントの操作は WORM ストレージ（Write Once Read Many） に書き出します。
- AWS なら S3 + Object Lock（Compliance Mode）
- GCP なら Cloud Storage Bucket Lock
- Azure なら Immutable Blob Storage
ログには「誰のセッション ID で」「どのプロンプトを受け」「どんなツールを呼び」「結果はどうだったか」を時系列で残します。事故が起きた後で「エージェントが何を考えていたか」を再構成できる粒度が必要です。
受託契約でも明記しておきたい 3 項目
技術設計だけでなく、契約書レベルでも責任分界を明確化しておくのが受託の流儀です。私たちが顧客提案時に必ず入れる 3 項目を共有します。
- 本番環境への AI エージェント書き込みは、別途書面合意が必要
- 開発時は強い権限を付けがち。「合意なしには本番 DML を実行しない」を契約条文化
- インシデント発生時の復旧手順とコスト負担の前提
- データ消失の復旧は、AI が原因でも人間が原因でも同じくらい時間がかかる前提を明記
- 第三者監査ログへのアクセス権
- クライアント側でも独立に監査ログを参照できる権限を付与する
コスト感 ─ ガードレール導入の費用感
| 項目 | 期間 | 単価帯 |
|---|---|---|
| 既存システムへのガードレール後付け | 4〜6 週間 | 300〜700 万円 |
| 新規 AI エージェント案件のセキュア基盤設計 | 6〜10 週間 | 600〜1,500 万円 |
| インシデント対応・原因調査支援 | 都度 | 100〜300 万円 |
| 月次レビュー（運用伴走） | 月額 | 30〜80 万円 |
ガードレールは 「事故が起きてから入れる」と 5〜10 倍高くつく ため、PoC 段階で先に実装するのが結果的に安上がりです。私たちが参画した案件でも、PoC で組んだガードレール構成をそのまま本番に流用するパターンがほとんどです。
まとめ ─ AI エージェントは「便利な新人」ではなく「強力な権限を持つ自動実行装置」
AI エージェントを「便利な新人」のメタファーで扱うと、人間の新人と同じ感覚で本番権限を渡してしまいがちです。実態は 「自動で SQL を打ち続ける装置」 であり、ミスの規模も速度も人間とは桁違いです。
権限分離・サンドボックス・HITL・改ざん不能な監査ログ。この 4 層を最初から組んでおけば、今回のような「丸ごと DROP」は物理的に起こせません。
弊社では、AI エージェントを安全に本番投入するためのガードレール設計・実装・監査支援を受託で行っています。「コーディングエージェントを CI に組み込みたい」「業務エージェントを本番に出したい」というご相談は、お問い合わせフォーム からお気軽にどうぞ。
