Zenn
😋

CursorにBigQuery SQLを書いてもらう

2025/02/13に公開
SQL
データ分析
BigQuery
Cursor
tech

CursorでBigQuery分析が捗る話

データ分析の現場で、BigQueryを使ってSQLクエリを書く機会が多いと思います。今回は、AI搭載のIDE「Cursor」を使って、BigQueryでの分析作業をより効率的に行う方法についてご紹介します。

プロジェクトの構成

分析用SQLを管理するプロジェクトは、以下のような構成にすることができます：

.
├── .cursor/          # Cursor の設定ディレクトリ
│   └── rules/        # ルール設定
│       └── sql.mdc   # SQL関連の設定
├── analyses/         # 分析用SQLクエリ
│   ├── creator_metrics/*.sql    # クリエイター関連の分析
│   └── service_metrics/*.sql    # サービス関連の分析
├── docs/            # ドキュメント
│   └── schema/      # スキーマ定義
└── README.md

Cursorの主な機能

既存のクエリを活用した分析

Cursorを使えば、「先月行ったユーザーセグメント分析と同じような分析をしたい」といった自然な言葉で、関連するSQLを検索できます。また、既存のSQLを新しい分析用に修正する際も、「このクエリの対象期間を直近3ヶ月に変更して」といった指示を理解し、適切なSQLの修正を提案してくれます。

新規分析の作成

新しい分析を始める際は、「新規登録したユーザーの継続率を分析したい」といった業務目的を伝えることで、SQLの雛形を提案してくれます。例えば：

SELECT
  user_id,
  DATE(created_at) as signup_date,
  MAX(DATE(last_access_at)) as last_access_date
FROM
  `project.dataset.users`
WHERE
  created_at >= '2024-01-01'
GROUP BY
  1, 2

SQLルールの設定と活用

.cursor/rules/sql.mdcにSQLのルールを定義することで、Cursorのコンポーザーがそれらを考慮してクエリを提案します。以下が実際の設定例です：

---
description: SQL
globs: 
---
# Your rule content

- You can @ files here
- You can use markdown, but you don't have to
- You can get the schema with `bq show --format=prettyjson {project-id}:{database}.{table} | jq .schema`
- You should thoroughly research existing queries from the codebase to ensure writing compatible queries for BigQuery and current project details
- You can perform a dry-run and get results with `bq query --dry_run --use_legacy_sql=false --project_id={project-id} "{sql}"`
  - You can do this when writing new queries or debugging existing ones
  - You MUST NOT execute queries without dry-run; this is the most important rule above all else
- You should keep docs/schema, README(s), and comments in .sql files up to date

このように、パーティションテーブルへのクエリ方法や、dry-runの実行方法など、プロジェクト固有のルールを定義できます。Cursorはこれらのルールに従ってクエリを生成し、パフォーマンスやコストを考慮した提案を行います。

分析依頼の実例

実際の分析依頼がどのように進むか、具体例を見てみましょう。

依頼例：クリエイターの継続率分析

例えば、以下のような簡潔な依頼から始まります：

> 新規登録したクリエイターの継続率、初販売までのリードタイムを分析したい。SQLを書いて。

Cursorは、この依頼に対して以下のような多角的な分析を含むSQLを提案してくれます：

  1. 基本的な継続率指標

    • 1/3/6ヶ月後の継続率
    • 各マイルストーン（決済登録、サービス公開、初販売）の達成率

  2. リードタイム分析

    • 決済情報登録までの日数
    • 初回サービス公開までの日数
    • 初回販売までの日数

  3. コホート分析

    • 登録月ごとの継続率推移
    • マイルストーン達成までの平均所要日数
    • 各段階でのドロップアウト率

提案されたSQLに対して、以下のような簡潔なフォローアップで分析を進められます：

> dry runでエラーがないか確認してください。
> では完全なクエリを保存して。

特筆すべきは、最初の依頼では明示的に指定していない分析視点（例：コホート分析、各マイルストーンの達成率など）も含めて、包括的な分析クエリを提案してくれる点です。これまでの分析SQLなどを登録しておくと、それぞれのSQLのアイデアを活用して初期提案が過去クエリを考慮したものになっていく傾向があります。

また、bq showコマンドとbq query --dry-runを組み合わせることで、分析作業の品質も向上します：

  • スキーマの即時確認：必要なフィールドの型や構造が不明な場合、その場でbq showコマンドを実行してスキーマを確認
  • 事前エラーチェック：dry-runによって、実行前に以下のような問題を自動的に検出・修正
    • SQL文法エラー
    • フィールドの型の不一致
    • 存在しないフィールドの参照
    • パーティションフィルターの欠落

このように、Cursorを使うことで、単純な分析依頼から始めて、より深い洞察を得られる多角的な分析まで、効率的に進めることができます。

おわりに

Cursorは、BigQueryでの分析作業を支援する強力なツールです。特に、自然言語での対話によるクエリ作成や、プロジェクト固有のルールに基づいた提案機能は、分析作業の効率化に役立ちます。

Discussion