AIが作ったSQLを確認する｜結果の正しさ・件数・実行計画を点検する

欲しい結果を表の形で決める

「月の売上を集計する」なら、何を売上とするか、どの日時を使うか、取消をどう扱うかを先に決めます。出力一行が日、商品、顧客のどれなのかも明記してください。架空の見本データから手計算できる期待値を用意すると、SQLの見た目ではなく結果で確認できます。型や列名が正しいことだけでは不十分で、依頼した業務上の定義と集計対象が一致しているかを確認します。

結合前後の件数を確かめる

注文と明細を結合すると、一つの注文が複数行になります。注文単位の金額をそのまま合計すると重複する場合があるため、結合のキーと想定する関係を確認します。欠けた関連行を落としてよいか、左結合が必要かも見ます。件数が多いほど正しいとは限りません。二明細を持つ注文、関連情報がない注文、同じ名前の別レコードを見本へ入れ、想定した一意性を満たすかを結果で調べてください。

空値・期間の境界・並び順を見る

空値を除外する条件と、空値をゼロとして扱う条件は結果が異なります。月の初日・末日、タイムゾーン、境界時刻の扱いを確認し、文字列で日付を比較するような曖昧な処理を避けます。ページ分割があるなら、同じ値の行が並ぶ場合の順序も考えます。見本を増やす時は無作為に件数だけ増やさず、境界直前・境界上・境界直後という意味のある条件を追加すると、SQLの解釈の違いを見つけやすくなります。

利用者が読める範囲を保つ

管理者用の接続で結果が出ても、通常の利用者が同じ結果を読んでよいとは限りません。対象ユーザーや組織の条件、実行する権限、返す列を確認します。必要のないメールアドレスや内部メモを取得しないよう、全列選択を避ける理由も説明してください。権限エラーを解消するためだけに強い接続や権限の広い関数へ変えず、求めるアクセス範囲を実際の役割で確かめることが重要です。

まず実行計画から処理の形を読む

PostgreSQLのEXPLAINは、プランナーが選ぶ処理計画を示します。どの表を読み、どこで結合・絞り込み・並べ替えをするかを確認してください。推定コストはそのままミリ秒の実測値ではありません。小さい表の順次走査を見ただけで必ず悪いと判断せず、対象件数や条件を踏まえます。インデックスの追加は保存容量や書き込みにも影響するため、計画の一行だけで本番へ追加せず、別の変更として必要性を検討します。

実測を伴う操作を区別する

EXPLAIN ANALYZEは実際に文を実行して測定するため、通常のEXPLAINと同じ感覚で使わないでください。更新系の文や負荷の大きな処理では特に、対象環境と影響を確認します。まず読み取り用の検証環境で、データ量と条件を記録して比較する方法を検討します。キャッシュや統計、並行処理の違いも結果へ影響し得るので、一回の速さだけで製品やSQLの一般的な性能差を断定しません。

採用理由を期待値と一緒に残す

採用するSQLには、出力の定義、見本データ、期待値、確認した権限、実行計画を添えます。性能のために書き換える場合も、同じ期待値を満たすかを再確認してください。未確認の本番件数や権限条件を「動作確認済み」に含めないことも大切です。次の担当者が同じ小さな見本から判断を再現できれば、AIとの会話がなくても修正を続けやすくなります。スキーマを変える必要が出た場合は、移行と復旧の計画へ作業を切り替えます。

• AIが作るDB変更を確認する｜既存データ・制約・復旧の点検
• AIでユニットテストを作る｜正解の根拠と境界値を確認する
• 開発エージェントの権限設計｜読み取り・編集・公開を分ける