はじめに
運用環境でSQLを直接実行する場面では、DELETE や DROP TABLE だけでなく、条件付きの大量更新や権限変更にも注意が必要です。
jev-sql-danger-checker は、SQLを実行せず、JevへSQL本文を送って意味的な運用リスクを分類する実験的なCLIです。
結論から言うと、このツールを実行許可・拒否の仕組みには使えません。一方で、直接実行前に人間のレビューを促す補助線としては使いどころがあります。
Jevが返すのは文章ではなく型付きの判断
Jevは、TypeSafe AIが「System One Model」と呼んでいるAIモデルです。同社は、入力した状態と質問に対して、文章ではなくコードで扱える型付きの判断を返すモデルだと説明しています。TypeSafe AIのJev紹介
確率値や判断の校正に関する説明もTypeSafe AIによるものです。この記事で確認できるのは、このCLIがJevへSQLと質問を送り、決められた形式の値を受け取る実装になっていることです。
| 型 | このCLIでの用途 | 返す値 |
|---|---|---|
noul |
広範囲影響、破壊性、レビュー要否 | 質問に対する0から1の確率値 |
choice |
危険度の分類 |
SAFE、CAUTION、DANGEROUS、CRITICAL のいずれか |
構造化された値であっても、SQLの構文妥当性や実行計画、実データに基づく影響を保証するものではありません。
判定しているのは実行計画ではない
CLIはSQL文字列をJevへ渡し、次の4項目を別々に返します。
| 判定項目 | 見ていること |
|---|---|
意味的な広範囲影響リスク（CLI表示は Semantic full scan risk） |
SQL文面から、多数または全行に影響しそうか |
| Destructive risk | データの破壊や復旧困難な変更につながりそうか |
| Production review required | 本番実行前に人間のレビューが必要そうか |
| Danger level | 4段階の総合ラベル |
Semantic full scan risk は物理的なフルスキャンを判定するものではありません。質問文も、全行を scan or affect する可能性を尋ねています。実行計画上のフルスキャンではなく、SQL文面から見た広い影響範囲のシグナルとして扱います。
semanticFullScanRisk: noul(
"Could this SQL potentially scan or affect most or all rows of a table?",
)
実測では、総合ラベルだけで実行可否を決められなかった
リポジトリには、条件のない DELETE の観測値と、Node.js v22.17.0 で代表的なSQLを標準入力から各1回実行した比較結果が記録されています。次は比較しやすい5件です。すべて単一回の観測値であり、モデルや質問文の変更によって変わり得ます。
| SQLの種類 | 広範囲影響 | 破壊的 | レビュー要否 | Danger level |
|---|---|---|---|---|
| 主キーによる1件取得 | 23% | 1% | 24% | SAFE |
LIMIT 付き一覧取得 |
75% | 1% | 31% | SAFE |
主キーで絞った UPDATE
|
10% | 62% | 71% | SAFE |
条件のない DELETE
|
98% | 98% | 98% | CRITICAL |
| 広い条件での権限変更 | 85% | 87% | 97% | CRITICAL |
LIMIT 付き一覧取得は総合ラベルが SAFE でも、広範囲影響リスクは75%でした。主キーで絞った UPDATE も SAFE ですが、破壊的リスク62%、レビュー要否71%です。
この結果からも、Danger level だけを実行可否に使うのは危険です。全10件の入力と実測値は、実行結果と評価用SQL例に記録しています。
直接実行の前に使うなら、判定結果を止める理由にする
自分がこのツールを使うなら、DBコンソールや踏み台からSQLを直接実行する前の確認に置きます。
SAFE を実行許可と読み替えません。判定結果は「SQLを流してよい」という答えではなく、「次に何を確認すべきか」を決めるために使います。
SQL本文を外部へ送ってよいか確認する
このツールは判定対象のSQL本文を外部APIへ送ります。顧客IDなどの個人情報、認証情報、非公開のテーブル名や業務ルールを含む本番SQLは入力しません。
DBに接続しないことは、入力内容を外部へ送ってよいことを意味しません。送信が許可された環境に限定し、必要ならリテラルをダミー値に置き換えます。
実行計画の代わりにはならない
アクセスパスは、DBMSとバージョン、インデックス、統計情報、結合順序、パラメータ、オプティマイザに依存します。性能やロックの影響を確認するなら、対象環境に近い条件で EXPLAIN や EXPLAIN ANALYZE を実行します。
まとめ
- 広範囲に影響しそうか、破壊的か、レビューが必要かを分けて見られる
-
SAFEを実行許可と扱わず、注意を促す補助線として使う - SQL本文を外部APIへ送ってよいかを最初に確認する
- 構文、実行計画、ロック、対象件数、復旧手順は別途確認する
AIによる危険度判定はSQLレビューやDBMSの機能を置き換えません。しかし、急いでいるときほど飛ばされやすい「一度止まって確認する」工程を作るには使えます。