セキュリティ・運用

AIが書いた SQL を本番DBに流す前に絶対やるべき5つの検査

AIが書いたSQLを本番DBに流す前に絶対やるべき5つの検査を網羅解説。2026年版のレビュー方法、自動化ツール、事故事例から学ぶ運用設計をお伝えします。

Noritama AI 編集部

この記事の目次

結論: AIが書いたSQLを本番に流す前に「5検査」を必ず通す

2026年、AIにSQLクエリやマイグレーションを書かせるのは当たり前になりました。しかし、本番DBに流す前の検査を怠ると、テーブル全件UPDATE や ロックによるサービス停止 といった致命的な事故に直結します。本記事では、AI生成SQLを本番に流す前に必ず通すべき5つの検査を解説します。

この記事でわかること

  • AI生成SQLが引き起こす典型的な事故
  • 本番投入前の5検査の詳細
  • 各検査の自動化ツール
  • 事故からの復旧パターン

典型的な事故3パターン

事故1: WHERE抜け

「全ユーザーのメール通知をONにして」とAIに頼んだ結果、UPDATE users SET notify=true が生成され、退会済みユーザーまで通知ONに。1日で5万件の苦情。

事故2: 全件削除

「テストデータを消して」と頼んで DELETE FROM users が実行され、本番ユーザー消失。バックアップから復旧に8時間。

事故3: ロック停止

大量の行を更新するALTER TABLEで テーブルロック が発生、APIが3時間停止。

検査1: 静的解析(SQLLint)

まずSQLそのものの構文・パターン解析を機械的に行います。代表的なツール:

  • SQLFluff: 構文ルール + ベストプラクティス
  • Squawk: PostgreSQL migration linter
  • pgAnalyze: クエリパフォーマンス予測

チェック項目

  • WHERE句なしのUPDATE/DELETE禁止
  • SELECT * の禁止
  • 長時間ロックを引き起こす操作の検出
  • インデックス未利用の検出

検査2: EXPLAIN実行

本番投入前に必ずEXPLAIN(またはEXPLAIN ANALYZE)で 実行計画 を確認します。

確認ポイント

  • Sequential Scanが想定外に発生していないか
  • JOINの推定行数が爆発していないか
  • インデックスが正しく使われているか
  • 推定コストが想定の範囲か

検査3: ステージング環境でのDry Run

本番と同等のデータ量(マスク済み)を持つステージングで 実際に実行 し、結果を確認します。

確認ポイント

  • 更新・削除行数が想定通りか
  • 実行時間が許容範囲か
  • 関連するアプリケーションが正常動作するか
  • ロック時間が許容範囲か

検査4: 影響範囲の手動レビュー

機械チェックだけでは不十分なため、シニアエンジニア or DBAが 意図と実装の一致 を最終確認します。

レビュー観点

  • WHERE句が意図通り絞り込めているか
  • JOINの方向が正しいか
  • NULL扱いが意図通りか
  • トランザクション境界が適切か

検査5: ロールバック計画

万が一の事故に備え、ロールバック計画 を事前に用意します。

準備事項

  • 実行前にバックアップ取得(point-in-time recovery)
  • UPDATE/DELETE時は変更前データをログテーブルに保存
  • ロールバックSQLを別ファイルで用意
  • 復旧手順を文書化

5検査を自動化するパイプライン

1. PR作成時: SQLFluff/Squawkを自動実行
2. ステージング: EXPLAIN ANALYZEを自動取得
3. レビューReady: シニアレビューを必須化
4. 本番投入直前: ロールバック計画を自動生成
5. 実行: トランザクション内で実行 → 結果検証 → COMMIT

大規模変更のベストプラクティス

1. バッチ分割

1000万行のUPDATEは一度にやらず、1万行ずつ に分割。各バッチ後にSLEEPを挟む。

2. オンライン DDL

MySQL/PostgreSQLのオンラインスキーマ変更ツール(pt-online-schema-change, pg_repack等)を活用。

3. 機能フラグ連携

スキーマ変更とアプリ更新を分離。新スキーマ対応コードは機能フラグでオフにし、データ移行完了後にON。

AIプロンプトの工夫

AIに安全なSQLを書かせるプロンプト例:

## 制約
- WHERE句なしのUPDATE/DELETE禁止
- 影響行数を必ず明示
- 実行前のバックアップ手順を含める
- ロールバックSQLも併せて生成
- バッチ処理が必要なら明示

2026年のDBA(データベース管理者)の役割

AI時代のDBAは、SQLを書く人ではなく 「AI生成SQLを評価する人」 へと役割が変化しています。EXPLAIN読解、インデックス設計、パーティション設計など、AIが苦手な領域に注力する形が広がっています。

事故からの復旧

万が一事故が起きたら、次の手順で復旧します。

  1. 即座にトランザクションROLLBACK(可能なら)
  2. サービス停止(影響拡大防止)
  3. バックアップから対象テーブル復旧
  4. 差分データを別経路で復元
  5. ポストモーテム作成・再発防止

まとめ

AIが書いたSQLは 強力だが危険 です。静的解析・EXPLAIN・Dry Run・人間レビュー・ロールバック計画の5検査を必ず通すことで、本番事故を未然に防げます。SQL一行で会社が傾く時代に、油断は禁物。あなたのチームの検査体制、改めて見直してみませんか。

関連タグ

2026年 AI生成 SQL データベース 本番運用