write-query

/write-query - 最適化された SQL を作成

見慣れないプレースホルダーがある場合や、接続されているツールを確認する必要がある場合は、CONNECTORS.md をご覧ください。

自然言語による説明から、使用する SQL 方言に合わせて最適化され、ベストプラクティスに従った SQL クエリを作成します。

使い方

/write-query <description of what data you need>

ワークフロー

1. リクエストを理解する

ユーザーの説明を解析し、次の項目を特定します。

• 出力列：結果に含めるフィールドは何ですか？
• フィルター：データを絞り込む条件（期間、セグメント、ステータスなど）は何ですか？
• 集計：GROUP BY、カウント、合計、平均などの処理はありますか？
• 結合：複数のテーブルを組み合わせる必要がありますか？
• 並べ替え：結果をどのように並べ替えますか？
• 制限：上位 N 件やサンプル数の指定はありますか？

2. SQL 方言を特定する

ユーザーが使用する SQL 方言がまだ分からない場合は、どれを使用しているか尋ねます。

• PostgreSQL（Aurora、RDS、Supabase、Neon を含む）
• Snowflake
• BigQuery（Google Cloud）
• Redshift（Amazon）
• Databricks SQL
• MySQL（Aurora MySQL、PlanetScale を含む）
• SQL Server（Microsoft）
• DuckDB
• SQLite
• その他（具体的に尋ねます）

同じセッション内の今後のクエリでも、その方言を使用します。

3. スキーマを調べる（データウェアハウスに接続されている場合）

データウェアハウスの MCP サーバーが接続されている場合：

1. ユーザーの説明に基づいて、関連するテーブルを検索します
2. 列名、型、リレーションシップを調べます
3. パフォーマンスに影響するパーティションキーやクラスタリングキーを確認します
4. クエリを簡潔にできる、事前構築済みのビューやマテリアライズドビューを探します

4. クエリを作成する

次のベストプラクティスに従います。

構成：

• 複数の論理的な手順があるクエリでは、読みやすさのために CTE（WITH 句）を使用します
• 論理的な変換またはデータソースごとに CTE を 1 つ使用します
• CTE には内容が分かる名前を付けます（例：daily_signups、active_users、revenue_by_product）

パフォーマンス：

• 本番環境のクエリでは SELECT * を決して使用せず、必要な列だけを指定します
• 早い段階でフィルターを適用します（WHERE 句を可能な限りベーステーブルに近づけます）
• 利用可能な場合はパーティションフィルターを使用します（特に日付パーティション）
• 大きな結果セットを返すサブクエリでは、IN より EXISTS を優先します
• 適切な JOIN の種類を使用します（INNER JOIN が適切な場合に LEFT JOIN を使用しないでください）
• JOIN またはウィンドウ関数で代替できる場合は、相関サブクエリを避けます
• JOIN による行数の急増（多対多）に注意します

読みやすさ：

• 明白でないロジックについては、「理由」を説明するコメントを追加します
• 一貫したインデントと書式を使用します
• テーブルには意味のある短いエイリアスを付けます（a、b、c だけにしないでください）
• 主要な句はそれぞれ別の行に記述します

方言固有の最適化：

• 方言固有の構文と関数を適用します（詳細は sql-queries スキルを参照してください）
• 方言に適した日付関数、文字列関数、ウィンドウ構文を使用します
• 方言固有のパフォーマンス機能（例：Snowflake のクラスタリング、BigQuery のパーティショニング）に注意します

5. クエリを提示する

次の内容を提示します。

1. 完全なクエリ：シンタックスハイライト付きの SQL コードブロックに記載します
2. 簡単な説明：各 CTE またはセクションの役割を説明します
3. パフォーマンスに関する注意点：関連する場合は、予想コスト、パーティションの使用状況、ボトルネックの可能性を記載します
4. 変更案：一般的なバリエーション（期間の変更、粒度の変更、フィルターの追加）への調整方法を示します

6. 実行を提案する

データウェアハウスに接続されている場合は、クエリを実行して結果を分析することを提案します。ユーザーが自分で実行する場合は、そのままコピーして貼り付けられる状態にします。

例

シンプルな集計：

/write-query Count of orders by status for the last 30 days

複雑な分析：

/write-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup

パフォーマンスが重要な場合：

/write-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.

ヒント

• すぐに適切な構文を使えるよう、最初に SQL 方言を伝えてください
• テーブル名が分かっている場合は記載してください。不明な場合は Claude が探すのを手伝います
• クエリを冪等（安全に再実行可能）にする必要があるか、1 回限りの実行かを指定してください
• 定期実行するクエリの場合は、日付範囲をパラメーター化する必要があるかを伝えてください