SQL クエリ生成
普通の言葉で要件を言う、AI が SQL を書く
SQL を書くときのトラブル
JOIN が壊れてる、サブクエリが複雑でくらくら
3 つのテーブル JOIN、実行したら出力行数が想定の 10 倍——どの JOIN がバグった？30 分掘ってやっと多対多関係の処理がまずいことに気づいた。
サブクエリが 3 層、自分でも見ても意味わからん。同僚が「このクエリなに」と聞く、2 分考えてから「ちょっと待ってね」。
さらに最悪なのは性能問題：クエリが 30 秒掛かった、EXPLAIN 見てもわからん。索引を足したら逆にもっと遅くなった。どこが駄目なんだ？
OpenClaw：ビジネスロジックを理解して、大丈夫な SQL を書く
「ユーザーごとの過去 30 日消費額を見つけて、金額順に大きい方から並べて」と言ったら、OpenClaw が正規の SQL を直生成。
ただの翻訳じゃなく：テーブル関連を考慮、データ規模を考慮、索引を考慮して、正確なだけじゃなく、性能も悪くない SQL を出力。
遅いクエリに当たった？SQL と EXPLAIN 結果を一緒に放り込めば、ボトルネックはどこか、どの索引を足すか、もっと速く書き換えられないか、全部教えてくれる。DBA がそばにいてアドバイスくれる感じ。
SQL Prompt 3 本、日常シーン 90% をカバー
日常の取データから性能最適化まで、必要に応じて使い分け。
日常取データ：過去 30 日新規ユーザーをチャネル別グループ
ゴールデンコマンド
データベースに以下のテーブルがある：
- users（id, name, email, channel, created_at, status）
- user_profiles（user_id, age, gender, city）
SQL を書いてほしい：
1. 過去 30 日の日別新規ユーザー数
2. 登録チャネル（channel）別にグループ化
3. 同時に各チャネルの翌日留存率を統計
4. 結果を日付逆順で並べる
データベースは MySQL 8.0、users テーブルは約 500 万行。
合わせて推奨索引も出して。日常取データは最もありふれたパターン。AI に言う時は、DB タイプと data size を言うことを忘れずに、データベース毎に SQL の書き方が違う（日付関数とか）、data size が query 戦略に影響する。
遅いクエリの改善：30 秒の SQL を救う
上級テク
このクエリが 30 秒掛かった、最適化してほしい：
[ここに遅い SQL を貼り付け]
EXPLAIN 結果：
[ここに EXPLAIN アウトプット貼り付け]
分析してほしい：
1. ボトルネックはどこ（テーブルスキャン？一時テーブル？ファイルソート？）
2. どんな索引を足すか（CREATE INDEX 文で）
3. SQL をどう書き換えたらもっと速い（同等だけど効率的な別の書き方）
4. 最適化後の実行時間予想
データベース：PostgreSQL 15、テーブルデータ約 2000 万行。遅いクエリを最適化する時は EXPLAIN 結果を必ずつける、SQL だけ見てはボトルネック判定しにくい。同時にデータ量も言うこと——100 行と 2000 万行では最適化戦略がぜんぜん違う。
複雑なビジネスクエリ：ユーザー消費分析
ゴールデンコマンド
データベースに 3 つのテーブル：
- users（id, name, registered_at）
- orders（id, user_id, product_id, amount, created_at, status）
- products（id, name, category, brand）
クエリを書いてほしい：
1. 各ユーザーの総消費額（完了した注文だけ）
2. 各ユーザーが最も買った商品カテゴリ（同票なら最初の 1 つ）
3. 各ユーザーの初回と最終購入日時
4. 過去 1 年に消費したユーザーだけ
5. 総消費額で大きい順に並べ、Top 100 取得
データベース：MySQL 8.0。CTE で SQL を書いて可読性を上げてほしい。マルチテーブル関連＋集計＋ランク、手書きするとバグやすい。AI に CTE で書かせると、読みやすいし、後から要件変更する時も楽。
データベース接続設定
OpenClaw に直接データベースに繋がせる設定（オプション、設定なしでも SQL 生成できる）。
データベース接続設定（.openclaw.yml）
# DB 接続（設定したら AI が直接クエリ実行できる）
database:
type: mysql # mysql / postgresql / sqlite
host: localhost
port: 3306
database: my_app
user: readonly_user # 強く読み取り専用ユーザーをすすめる！
password_env: DB_PASSWORD # 環境変数から密码を読む、明文は禁止
# 安全制限
read_only: true # SELECT のみ、データ修正禁止
max_rows: 10000 # 1 回のクエリ最大行数
timeout: 30 # クエリ timeout（秒）
# DB を設定しなくても OK、AI はテーブル構造の説明から SQL を生成
# ただ直実行して結果を検証できないだけ
本番 DB につなぐ時は、必ず読み取り専用ユーザーを使う。OpenClaw に安全制限があっても、セキュリティは多層防御。読み取り専用レプリカに繋ぐのが最適、主 DB には繋がないで。
SQL 作成：OpenClaw vs ChatGPT
両方 SQL を生成できるけど、細部の差は大きい。
OpenClaw
- あなたの DB schema を読み込める、出力 SQL は実テーブル構造と完全一致
- DB に直繋できる（読み取り専用設定後）、クエリ結果を検証
- コンテキスト理解：前のクエリ、テーブル関連を覚えてる、追問時に重複説明不要
- ローカル実行、テーブル構造とビジネスロジックは漏れない
VS
ChatGPT
- テーブル構造を自分で説明して SQL 生成、推測が多め
- SQL を直実行して検証できない、文法が正しいか自分で試す
- コンテキストウインドウに限度あり、複雑なビジネスロジック、話してる途中で忘れる
- SQL 出力は文法は正しいかもしれないけど、ロジックが違うことあり、原因がわかりにくい
リアルシーン
データ分析官：上司が急に要件追加
午後 3 時、上司からメッセージ：「近 3 ヶ月の各チャネル ROI を見てよ、週単位で統計、5 時までに」。このテーブル関連について、あんまり詳しくない、SQL を手書きする自信ない。
OpenClaw ソリューション
テーブル構造を OpenClaw に言う、ビジネス要件を普通の言葉で説明、2 分で SQL ゲット。DB に繋いで一度実行、結果 OK なら、AI にロジック説明させて自分も勉強。4 時に交付、まだ早い。
自力で書く
ドキュメント見てテーブル構造確認、SQL 書く、JOIN ミスで出力データがおかしい、1 時間掛けて調べた。やっと直した、また日付関数が違う。5 時までに交付できない、上司に「あと 30 分」。
SQL 作成のコツ
AI に SQL 生成させる時、必ず言うこと：DB タイプ（MySQL / PostgreSQL / SQLite）、テーブルデータのおおよそのサイズ、既存の索引。この 3 つが出力 SQL の品質を直接左右する。
複雑なクエリは AI に CTE（WITH 句）で書かせて、ネストしたサブクエリはダメ。CTE のほうが読みやすい遥かに、要件変えるときも層階から引っぺがさなくていい。
習慣つけること：AI に SQL 生成させたら、先に LIMIT 100 つけて試行、結果正しいか見る、全量クエリは直実行禁止。とくに複数テーブル JOIN の時、もし笛卡爾積になったら、DB が直ダウン。