PMの仕事でSQLを使う場面は意外と多いです。月次のKPI集計、施策の効果検証、レポート用のデータ抽出。私自身でクエリが書けるとエンジニアに依頼するリードタイムがゼロになるし、「ちょっとこの切り口でも見たいな」という深掘りもすぐできます。ただ、SQLを「書ける」と「スラスラ書ける」の間には結構な距離があって、WITH句の入れ子やLEFT JOINの条件指定で毎回手が止まっていました。
PMがクエリを書くタイミングは大きく2つです。先々のロードマップを検討するにあたりKPIやユーザー行動に変化が無いか、課題を抽出するために網羅的に分析すること。次に、日々リリースする機能や改善施策に効果があったかの分析に利用すること。プロダクトフェーズによりクエリを触る頻度も変わりますが、少なくとも週に1回は集計・抽出に利用しています。慣れている条件や抽出であれば時間はかかりませんが、新しく課題を見つける際には「こういう分析ってどうすればよいのか」と迷うこともしばしばです。
Claude Codeを使い始めてから、この「手が止まる時間」が一気に減りました。この記事では、PM業務でSQLを書く際にClaude Codeをどう使っているかを書いていきます。
PMがSQLを書く現実 -- 「書けるけど遅い」問題
PMがSQLを触るシーンを挙げてみると、こんな感じになります。
- 月次KPIの集計（MAU、コンバージョン率、継続率など）
- A/Bテストの結果集計
- ユーザー行動の深掘り分析
- 経営会議やレビュー用のデータ抽出
SELECT * FROM ... WHERE ... くらいは問題なく書けます。でもWITH句を使って中間テーブルを組んだり、複数テーブルをJOINして集計するクエリになると途端にスピードが落ちる。書き始めてから動くクエリが完成するまでに30分、下手すると1時間かかることもありました。
何をしていたかというと、StackOverflowで似たクエリを探して、自分のテーブル名やカラム名に書き換えて、実行してエラーが出て、またStackOverflowに戻って...という往復です。WITH句の書き方は以前の記事にまとめたのですが、書くたびに「あれ、この書き順で合ってたっけ」と手が止まる。これがPMのSQLあるあるなんですよね。
エンジニアに依頼する選択肢もあるけれど、「月次の数字をもうひとつの軸でも見たい」程度のことで毎回依頼するのは心理的ハードルが高いです。相手も忙しいし、自分で書けたほうがいいのは分かっている。分かっているけど遅い。これがPMのSQLあるあるだと思います。
Claude CodeでSQLを書く3つのパターン
Claude Codeを使い始めてから、SQLの書き方が3パターンに整理されました。
パターン1: 日本語で要件を伝えてクエリを生成する
一番よく使うパターンです。ターミナルでClaude Codeを立ち上げて、こんなふうに頼みます。
「月別のアクティブユーザー数を集計するクエリを書いて。テーブルはuser_actionsで、action_dateとuser_idカラムがある」
すると、こういうクエリが返ってきます。
WITH monthly_active AS ( SELECT FORMAT_DATE('%Y-%m', action_date) AS month, COUNT(DISTINCT user_id) AS active_users FROM user_actions WHERE action_type = 'login' GROUP BY month ) SELECT * FROM monthly_active ORDER BY month
自分でゼロから書くと5分はかかるクエリが、10秒で出てきます。しかも生成されたクエリを読むこと自体が学びになる。「そうか、FORMAT_DATEでこう書くのか」「WITH句はこの粒度で切るのか」と、毎回ちょっとずつ知識が増えていく感覚があります。
複数テーブルのJOINが必要なときも同様で、テーブル構造を伝えればLEFT JOINの条件も正しく組んでくれます。
パターン2: 既存クエリのリファクタリング・解説
引き継いだダッシュボードに数百行のクエリが入っていて、何をやっているか分からない。こういう場面は意外と多いですよね。
Claude Codeにクエリを貼り付けて「このクエリを解説して」と頼むと、ブロックごとに日本語で何をしているか説明してくれます。さらに「WITH句を使ってリファクタリングして」と続ければ、可読性の高い形に書き直してくれます。
このパターンの副次的な効果として、自分が書いたクエリでも「もっと効率的な書き方ある？」と聞く習慣がつきました。冗長なサブクエリをWITH句に書き直す提案をもらって、「こっちのほうが読みやすいな」と納得することが多いです。
パターン3: エラーのデバッグ
SQLを実行してエラーが出たら、エラーメッセージをそのままClaude Codeに貼ります。これだけで解決することがかなりあります。
「カラム名のtypo」「GROUP BYに集計キーを入れ忘れている」「JOINの結合条件が逆」など、自分で探すと地味に時間がかかる原因を即座に指摘してくれます。特にGROUP BYの漏れは頻繁にやらかしていたので、これだけでもかなり時間を節約できました。
CLAUDE.mdにSQL業務のコンテキストを書く効果
3つのパターンはClaude Code単体でも使えますが、真価が出るのはCLAUDE.mdとの組み合わせだと感じています。CLAUDE.mdの書き方については別の記事に詳しくまとめたので、ここではSQL業務に特化した話を書きます。
CLAUDE.mdに「よく使うテーブル名とカラム構成」「集計ルール」を書いておくと、毎回の説明コストがゼロになります。たとえばこんな記述を追加しておきます。
## SQL環境 - 使用DB: BigQuery - 主要テーブル: - user_actions(user_id, action_type, action_date) - users(user_id, plan, created_at) - 集計ルール: - 月次集計は月末締め - アクティブユーザー = 当月にloginアクションがあるuser_id
これを書いてから「今月のアクティブユーザー数を出して」と頼むだけで、テーブル名も条件も正しいクエリが返ってくるようになりました。書く前は毎回「テーブルはuser_actionsで、カラムはuser_idとaction_typeと...」と説明していたので、地味だけど大きな改善でした。
SQLの方言（BigQuery、PostgreSQL、MySQL等）もCLAUDE.mdに書いておくと効きます。BigQueryの FORMAT_DATE とPostgreSQLの TO_CHAR は同じことをする関数ですが構文が違います。CLAUDE.mdに「使用DB: BigQuery」と一行書いておくだけで、最初からBigQuery構文で生成してくれます。
SQLの「学習ツール」としてのClaude Code
Claude CodeはSQLを書くだけでなく、学ぶツールとしても使えています。
たとえば「WITH句とサブクエリの違いを具体例で教えて」と聞くと、同じ結果を返す2つのクエリを並べて解説してくれます。CASE WHENやGROUP BYの使い分けについても同様で、たとえばマッチングアプリの例で解説した記事で扱っているGROUP BYやJOINの組み合わせのように、自分の業務に合わせた質問を投げると、メリット・デメリットを説明してもらえます。
書籍で基礎文法を学び、実務のクエリをClaude Codeと一緒に書きながら覚えるサイクルが回るようになってからは、SQLの理解が前より速くなった実感があります。
SQL入門の定番として「スッキリわかるSQL入門」{{AMAZON_LINK_PLACEHOLDER}}は手元に置いておくと基礎の確認に便利で、実務に入ってからは「達人に学ぶSQL徹底指南書」
がWITH句やウィンドウ関数の理解を深めるのに役立ちました。ただ、書籍だけだと「自分の業務テーブルでどう書くか」の変換に苦労するので、Claude Codeで実際のテーブル構造を渡して練習する組み合わせがちょうどいいです。
書き方が分からない・とっかかりが無いクエリを出してくれて楽だということもありますが、なによりクエリを書いている時のエラーの原因と改善策を提示してくれるのは、業務ストレスが減ってかなり楽になりました。また、人から共有を受けたクエリでなんとなく実行していたものも、知らなかった部分を説明してくれるため、自分の中の理解も深まりました。
注意点 -- AIが生成したSQLをそのまま実行しない
ここまでClaude Codeの便利さを書いてきましたが、注意点もあります。
Claude Codeが生成したクエリは、必ず自分で読んでから実行します。SELECT中心の運用だとしても、集計結果が「それっぽい数字」に見えるだけで実は条件が間違っていることがあります。特に集計対象が絞られているか（WHERE句の条件が想定通りか、JOINで意図しない重複が出ていないか）は慎重に確認すべきだと思います。サンプルデータで検算する習慣はつけたほうがいいです。
テーブル名やカラム名をClaude Codeが推測で埋めてしまうケースも経験しました。CLAUDE.mdにテーブル構造を書いておけばかなり防げますが、実際のスキーマと照合する手間は省かないほうが安全だと思います。
CLAUDE.mdの禁止事項に「推測でテーブル名・カラム名を補完しない。不明な場合はユーザーに確認する」と書いておくのも有効で、追加してからは勝手な推測が減りました。これはSQL固有の話ではなく、Claude Codeとの付き合い方全般に言えることかもしれません。
PMにとってSQLは「書ければ武器、書けなくても回るが遅くなる」スキルだと思っています。Claude Codeを使えば「書けるけど遅い」の壁を越えられるし、自分で全部覚えなくても、要件を伝えて生成し、結果を読んで学ぶサイクルで実力がついてきます。
まずは日常の集計クエリ1つをClaude Codeに頼んでみてほしいです。「こういうテーブルがあって、こういう集計がしたい」と日本語で伝えるだけでいい。返ってきたクエリを読んで「なるほど」と思えたら、それがスタートラインになります。
