本番データベースへの更新SQLとバッチの変更を、実行前に条件の抜け・全件更新・ロールバックの有無で判定し、レビューの指摘を情報システムの担当へ返す

処理の起点を決める

チケットのステータスが「レビュー依頼」になったことを起点にします。 SQLファイルの添付だけを起点にすると、書きかけのファイルを添付し直すたびにレビューが走ります。申請者が「見てください」と意思表示した時点から動かします。

レビューの結果をチケットにコメントしたら、ステータスを「一次レビュー済み」に変えます。人がレビューを始めるのはこのステータスからです。 申請者がSQLを直して再び「レビュー依頼」にすると、もう一度動きます。

実行日時の直前の申請は、別の扱いにします。 申請票の実行日時まで24時間を切っているものは、判定に加えて、レビュー担当へ直接通知します。AIの判定を待つあいだに実行の時刻が来ることを防ぎます。

入力データを集める

質を決めるのは、テーブルの定義とレビューの基準です。 テーブルの定義が無いと、AIは「テナントの列があるのに条件に入っていない」ことに気づけません。主キーと、絞り込みに必ず入れるべき列を、テーブルごとに一覧で持たせます。

レビューの基準は、AIの物差しになります。 「1万件を超える更新は夜間に限る」「DELETE は論理削除で代える」といった決まりが書かれていないと、判定が担当者の暗黙の基準から、AIの一般論に置き換わるだけです。

データの取得方法を決める

検証環境のデータは、本番に近い件数と分布である必要があります。 件数が本番の1割しかない検証環境で数えても、見込み件数との食い違いを見つけられません。 検証環境をいつの時点の本番から作ったかを、判定と一緒に記録します。

結合を含む更新では、更新件数と、条件に当たる対象の行の数を両方取ります。 PostgreSQL の公式の文書は、FROM を使う更新で対象の1行が結合先の複数の行と結び付く場合、どの行で更新されるかは容易に予測できないとし、副問い合わせで参照するほうが安全だとしています。結合の結果の行数が対象の行数より多ければ、その時点で重複があります。

AIへ渡す前に整形する

1. ファイルの確認 … SQLファイルの文字コードと改行をそろえ、複数の文を1文ずつに分けます
2. 構文解析 … 文の種類（UPDATE／DELETE／INSERT／ALTER など）、対象テーブル、WHERE の条件の列、結合、LIMIT を取り出します
3. 機械で決まる指摘 … WHERE の無い UPDATE・DELETE、トランザクションの無い複数文、COMMIT の前に件数の確認が無いことを、この段で指摘にします
4. 検証環境での件数 … 同じ条件で件数を数え、更新はトランザクションの中で流して件数と変更前後の見本を取り、ROLLBACK します
5. テーブルの定義の取り出し … 対象テーブルの主キー、一意の制約、絞り込みに必須の列を一覧から引きます
6. 申請票の正規化 … 見込み件数を数値にし、実行日時を時刻にそろえます
7. 秘密の情報の除去 … SQLの中に会員の氏名や電話番号が直書きされていれば、伏せ字にしてからAIに渡します

3番目をAIの前に置くのが大事です。 WHERE の無い更新は、AIに聞かなくても分かります。機械で決まるものは機械で決め、AIの判定と混ぜません。 混ぜると、AIが見落としたときに一緒に抜けます。

4番目の ROLLBACK は、スクリプトの中で例外が起きても必ず実行されるように書きます。 検証環境とはいえ、流しっぱなしにすると次の申請の件数がずれます。MySQL の検証環境には、--safe-updates の設定も重ねます。 この設定では、キーの条件も LIMIT も無い UPDATE と DELETE が拒否されるので、スクリプトの誤りで全件を書き換える経路を1つ減らせます。

AIに処理させる

させるのは、SQLと申請票と機械の確認結果を読み、7つの観点ごとに問題があるかを判定し、根拠の箇所と直し方を書き出すことだけです。

右端の列が、この構成の安全装置です。 判断がつかないものを「問題なし」にせず、unknown として人に回します。

2行目がいちばん起きやすい失敗です。 件数を渡さずにSQLだけを見せると、AIは「数百件程度と見込まれる」と書きます。もっともらしいだけに、数えた数字と取り違えられます。

指示内容を固定する

あなたは情報システム部で、本番データベースへの変更を実行前にレビューする担当です。
次の材料だけを根拠に、7つの観点ごとに判定してください。SQLを実行した前提で書かないでください。

【観点】
1. missing_condition ... 目的とテーブルの定義に対して、絞り込みの条件が足りない
2. count_mismatch ...... 見込み件数と検証環境の件数の差に、説明がつかない
3. join_duplication .... 結合で、対象の1行に複数の行が当たっている
4. rollback_plan ....... 戻す対象の行・時点・手順が具体的に書かれていない
5. transaction ......... 開始→件数の確認→確定の順になっていない
6. timing .............. 件数と規模に対して、実行の時間帯が基準に合わない
7. batch_change ........ バッチの差分で、対象・条件・時間帯が変わっている

【result の選び方】
- issue ........... 問題がある
- ok .............. 問題がない
- unknown ......... 材料が足りず判断できない
- not_applicable .. その観点が当てはまらない
迷ったときに ok を選ばないでください。

【厳守事項】
- 件数は【検証環境の件数】の値だけを使ってください。件数を推測しないでください。
- 【機械の確認結果】にある指摘を繰り返さないでください。それ以外の点を見てください。
- 条件の抜けは、【テーブルの定義】の「絞り込みに必須の列」と照らしてください。
- 「バックアップから戻す」だけの戻し方は issue です。時点・対象の行・手順が要ります。
- evidence には、根拠にしたSQLの行か申請票の文をそのまま写してください。
- fix には、直し方の方針を書いてください。SQLの全文を書き直さないでください。
- 承認してよいか、実行してよいかは書かないでください。
- 業務上、そのデータを直すべきかどうかは判断しないでください。

【申請票】{request}
【SQL】{sql}
【バッチの差分】{batch_diff}
【機械の確認結果】{static_checks}
【検証環境の件数】{counts}
【テーブルの定義】{table_defs}
【レビューの基準】{review_rules}

「件数を推測しない」を明記しないと、count_mismatch は役に立ちません。 推測した件数と見込み件数を比べて「整合している」と書けば、検証環境で数えた意味がなくなります。

「機械の確認結果を繰り返さない」も効きます。 書かないと、AIは WHERE の有無の話から書き始め、本当に読んでほしい条件の抜けの指摘が短くなります。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "ticket_id": "",
  "statements": 0,
  "checks": [
    { "aspect": "missing_condition",
      "result": "issue | ok | unknown | not_applicable",
      "severity": "high | medium | low",
      "evidence": "", "fix": "" }
  ],
  "questions_for_requester": [""],
  "verdict": "approve_candidate | needs_fix | needs_dba"
}

checks には7つの観点を1つずつ並べます。verdict はAIに出させず、スクリプトが機械の確認結果と checks から規則で埋めます。

1つ目の理由は、機械の指摘とAIの指摘を同じ一覧に並べられることです。 レビュー担当は、チケットのコメントを1か所読めば済みます。

2つ目は、verdict を規則にしておけることです。 レビューの基準が変わっても、直すのは規則だけです。結合を含む更新を必ず詳しい担当へ回す、という決まりも規則で書けます。

3つ目は、questions_for_requester で差し戻しが速くなることです。 「この条件で店舗の区分を絞らないのは意図どおりか」のように、申請者に聞くべきことを先に並べます。 指摘と質問を分けておくと、申請者が答えるだけで済む差し戻しが増えます。

システムへ連携する

本番のデータベースにはつなぎません。 スクリプトが持つのは検証環境の接続情報だけで、検証環境のアカウントにも、本番への経路を与えません。

チケットのSQLファイルも書き換えません。 直し方はコメントに書くだけで、直すのは申請者です。 AIの直し方をそのまま本番に流す経路を作らないためです。

人が確認する

人が全件を見ます。ただし見る深さが変わります。 approve_candidate は指摘が無いことと件数を確かめて承認し、needs_fix と needs_dba は指摘の根拠を読みます。

1. 実行日時の近いものを先に見る … 24時間以内のものから処理します
2. needs_dba を詳しい担当へ回す … 結合を含む更新と、判断できなかったものです
3. needs_fix の根拠を確かめる … evidence を読み、指摘が正しいかを確かめて申請者へ返します
4. approve_candidate を承認する … 件数と戻し方を目で確かめてから承認します
5. 判定を覆したら記録する … どの観点を、どちらに変えたかを残します

4番目の確認は、短くても省きません。 AIが問題なしとした申請を、人が承認せずに流す運用にすると、この構成は承認の仕組みではなく、承認を飛ばす仕組みになります。

目標は、150件をならして1件8分です。 approve_candidate は数分、needs_fix は10分前後、needs_dba はそれ以上かかります。詳しい2名が読むのは needs_dba だけになり、ほかの2名でも残りを回せることが、この構成のもう一つの狙いです。

例外に対処する

上の3行が大半を占めます。 どれもAIの問題ではなく、申請の出し方と検証環境のそろい方の問題です。 検証環境を本番と同じ構造に保つことが、判定の精度を上げるより効きます。

5行目は起きる頻度は低いですが、止め方を決めておきます。 検証環境に流しっぱなしの更新が残ると、次の申請の件数がずれ、正しい申請を食い違いとして返すことになります。

記録を残す

• 申請票、SQLファイル、バッチの差分と、受け取った日時
• 構文解析の結果と、機械で決まった指摘
• 検証環境の件数と変更前後の見本、検証環境を作った時点
• Claude API が返したJSONの全文と、スクリプトが決めた verdict
• 人が判定を覆した記録と、承認した人・承認した日時
• 本番で実行した日時と、実行後に返った件数

3つ目で「検証環境を作った時点」を残すのは、件数の意味が時点で変わるためです。 1か月前の本番から作った検証環境で数えた件数は、本番で流したときの件数と違って当然です。 差が出たときに、どちらが古いのかを後から説明できます。

最後の行は、実行後の照合に使います。 本番で返った件数を検証環境の件数と比べ、大きく違えば、その場で戻し方の手順に入れるかを判断します。