事業担当者がKPIを自分で集計するためのSQLは、思っているほど多くを覚える必要はありません。「どの表から（FROM）」「どの行を（WHERE）」「どの単位でまとめて（GROUP BY）」「何を数えるか（SELECT と COUNT・SUM）」の四つを組み立てられれば、売上、利用者数、継続率といった日常のKPIの多くは集計できます。これに、表同士をつなぐ JOIN と、日付の扱いを加えれば、分析担当者に依頼して何日も待つ必要はかなり減ります。
ただし、SQLの書き方そのものより大切なのは、集計の前に「何をどう数えるか」を日本語で決めることです。「アクティブユーザー」とは何回使った人のことか、「売上」はキャンセルを含むのか、といった定義があいまいなまま書き始めると、正しく動くSQLでも間違った数字が出ます。
この記事は、プログラミングの経験がない事業担当者、企画職、マーケティング担当者に向けて書いています。SQLの基本的な考え方、KPI集計でよく使う書き方、事業データでの具体的な使い方、間違えやすい点と安全な使い方までを、例を交えて解説します。なお、ここでの例は一般的なSQLの書き方で、使っているデータベースによって細かな書き方が異なる場合があります。
SQLとは何か：事業担当者が覚える意味
SQLは、データベースに保存されたデータを取り出したり、集計したりするための言語です。多くの業務システムやWebサービスは、顧客、注文、利用履歴などのデータを表の形で保存するRDB（リレーショナルデータベース）を使っており、SQLを使うとそこから必要な数字を直接取り出せます。
事業担当者がSQLを覚える意味は、主に三つあります。
- 速さ：知りたいことが浮かんだときに、その場で数字を確かめられる
- 正確さ：集計の条件を自分で書くため、依頼の行き違いによる誤りが減る
- 仮説の数：一回の確認にかかる手間が小さくなり、多くの仮説を試せる
分析の専門家になる必要はありません。日々のKPIを確認し、気になったことを少し掘り下げられる程度の力があれば、仕事の進め方は大きく変わります。
SQLを書く前に知っておく「表」の考え方
データベースのデータは、スプレッドシートのような表で保存されています。たとえば、ECサイトなら次のような表があるのが一般的です。
| 表の名前（例） | 1行が表すもの | 主な列（例） |
|---|---|---|
| users（顧客） | 一人の顧客 | 顧客ID、登録日、地域、会員ランク |
| orders（注文） | 一回の注文 | 注文ID、顧客ID、注文日時、合計金額、状態 |
| order_items（注文明細） | 注文の中の一つの商品 | 注文ID、商品ID、数量、金額 |
| products（商品） | 一つの商品 | 商品ID、商品名、カテゴリ、価格 |
ポイントは「1行が何を表すか」を常に意識することです。注文の表は1行が一回の注文なので、行を数えれば注文数になります。顧客の数を知りたいのに注文の表の行を数えてしまうと、何度も注文した顧客が重複して数えられます。SQLの間違いの多くは、この「1行の意味」の取り違えから生まれます。
KPI集計に必要な基本の書き方
ここからは、KPIの集計でよく使う書き方を順に説明します。例では、上の表のような架空のECサイトのデータを使います。
1. 表から列を取り出す：SELECT と FROM
最も基本の形は、どの表から、どの列を取り出すかを指定するものです。
SELECT order_id, user_id, total_amount FROM orders
これは「orders の表から、注文ID、顧客ID、合計金額の列を取り出す」という意味です。最初は、表の中身を確かめるために、行数を制限して数行だけ表示してみるとよいでしょう（多くのデータベースでは末尾に LIMIT 10 のように書きます）。
2. 条件で行を絞る：WHERE
特定の期間や状態の行だけを対象にするには WHERE を使います。
SELECT order_id, total_amount FROM orders WHERE status = 'completed' AND ordered_at >= '2026-09-01' AND ordered_at < '2026-10-01'
これは「9月中に完了した注文」だけを取り出します。日付の範囲は「以上」と「未満」で指定するのが安全です。「9月30日以下」と書くと、データベースによっては9月30日の0時ちょうどまでしか含まれず、その日の注文がほとんど抜けることがあります。
3. 数える・合計する：COUNT と SUM
KPIの多くは、行を数えるか、数値を合計することで求められます。
SELECT COUNT(*) AS order_count, SUM(total_amount) AS sales FROM orders WHERE status = 'completed' AND ordered_at >= '2026-09-01' AND ordered_at < '2026-10-01'
これで9月の注文数と売上が一度に出ます。AS は結果の列に名前を付ける書き方です。平均を出す AVG、最大・最小を出す MAX・MIN も同じように使えます。
購入した人の数を知りたいときは、重複を除いて数える COUNT(DISTINCT user_id) を使います。注文数と購入者数の違いを意識することが、正しい集計の第一歩です。
4. 単位ごとにまとめる：GROUP BY
日別、月別、カテゴリ別のように、何かの単位ごとに集計するには GROUP BY を使います。
SELECT DATE(ordered_at) AS order_date, COUNT(*) AS order_count, SUM(total_amount) AS sales FROM orders WHERE status = 'completed' GROUP BY DATE(ordered_at) ORDER BY order_date
これで日ごとの注文数と売上が並びます。ORDER BY は並べ替えの指定です。月ごとにまとめたい場合は、日付から年と月を取り出す関数を使いますが、関数の名前はデータベースによって異なるため、使っている製品の書き方を確認してください。
まとめた結果に条件を付けたいときは、WHERE ではなく HAVING を使います。たとえば「注文が一定件数以上の日だけ」を表示する場合です。WHERE はまとめる前の行に、HAVING はまとめた後の結果に条件を付ける、と覚えておくと混乱しません。
5. 表をつなぐ：JOIN
別々の表にある情報を組み合わせるには JOIN を使います。たとえば、注文の表に顧客の地域の情報を加えて、地域別の売上を出す場合です。
SELECT u.region, COUNT(DISTINCT o.user_id) AS buyers, SUM(o.total_amount) AS sales FROM orders o JOIN users u ON o.user_id = u.user_id WHERE o.status = 'completed' GROUP BY u.region
ON の後ろには、二つの表をどの列で結びつけるかを書きます。ここでは、注文の顧客IDと顧客の表の顧客IDが一致する行同士をつないでいます。
JOIN には、両方の表に対応する行があるものだけを残す内部結合と、片方の表の行をすべて残す外部結合（LEFT JOIN など）があります。「注文したことのない顧客も含めて数えたい」ときは、顧客の表を基準にした LEFT JOIN を使います。どちらを使うかで結果の件数が変わるため、目的に合わせて選びます。
事業データでよく使う集計の例
基本の書き方を組み合わせると、よく使うKPIの多くを集計できます。代表的なものを、考え方とともに紹介します。
| 知りたいこと | 集計の考え方 | 使う主な書き方 |
|---|---|---|
| 月別の売上と注文数 | 完了した注文を月ごとにまとめて合計・件数を出す | WHERE、GROUP BY、SUM、COUNT |
| 月別の購入者数 | 月ごとに顧客IDの重複を除いて数える | COUNT(DISTINCT) |
| 客単価 | 売上 ÷ 注文数 | SUM、COUNT |
| 新規とリピートの購入者数 | 顧客ごとの初回注文日を求め、その月が初回かどうかで分ける | MIN、JOIN または副問い合わせ |
| カテゴリ別の売上 | 注文明細と商品の表をつなぎ、カテゴリごとに合計する | JOIN、GROUP BY |
| 登録月別の継続状況 | 登録月ごとに顧客をまとめ、その後の各月に利用したかを数える | JOIN、GROUP BY、COUNT(DISTINCT) |
新規とリピートを分ける考え方
新規顧客とリピート顧客を分けて数えるには、まず顧客ごとの初回注文日を求めます。
SELECT user_id, MIN(ordered_at) AS first_order_at FROM orders WHERE status = 'completed' GROUP BY user_id
この結果を一つの表のように扱い、元の注文の表とつなげれば、各注文が「その顧客の初回の月の注文か、それ以降か」を判定できます。結果を表のように使う書き方には、副問い合わせや WITH 句（共通テーブル式）があります。WITH 句を使うと、処理の段階ごとに名前を付けて上から順に書けるため、後から読み返したときに理解しやすくなります。
継続率の表を作る考え方
登録した月ごとに顧客をまとめ、その後の各月に何人が利用を続けているかを並べた表は、サービスの定着を見るうえで重要です。SQLでは、顧客ごとの登録月と、利用した月の組み合わせを作り、登録月と経過月数ごとに顧客数を数えます。表の読み方と改善への活かし方はコホート分析のやり方で解説しています。
SQLでKPIを集計する手順
実際にKPIを集計するときは、次の手順で進めると間違いが減ります。
- 知りたいことを日本語の一文で書く（例：9月に初めて購入した顧客の数）
- 使う言葉の定義を確認する（「購入」はキャンセルを除くか、「9月」は日本時間か）
- 必要なデータがどの表のどの列にあるかを確認し、各表の「1行の意味」を確かめる
- 表の中身を数行だけ取り出して、データの形を目で確認する
- 条件の少ない簡単な形から書き始め、結果を確認しながら条件を足していく
- 結果の数字を、管理画面や過去の報告など別の情報源と照らし合わせて確かめる
- 正しいと確認できたSQLは、目的と定義のメモを付けて保存し、次回から使い回す
手順2の定義の確認は特に大切です。社内で指標の定義が文書になっていれば、それに従ってSQLを書きます。定義がそろっていない場合は、KPI定義書の作り方を参考に、まず定義を決めることをおすすめします。
手順6の照合も省かないでください。初めて書いたSQLの結果は、何かが間違っている前提で確認するくらいでちょうどよいものです。管理画面の売上と大きく違う場合は、キャンセルや返品の扱い、時間帯、テスト用のデータの混入などを疑います。
よくある間違いとその避け方
SQLの集計で事業担当者がつまずきやすい点をまとめます。
JOIN で行が増える。 注文の表と注文明細の表をつないでから注文の合計金額を足すと、一つの注文に複数の明細があるため、金額が明細の数だけ重複して合計されます。JOIN の後は、結果の件数が想定どおりかを必ず確認し、合計する列がどの表の「1行の意味」に属しているかを意識します。
空の値（NULL）の扱いを忘れる。 値が入っていない欄は NULL という特別な扱いになり、「等しい」「等しくない」の比較で思った結果になりません。たとえば「地域が東京ではない顧客」を数えると、地域が未入力の顧客は含まれません。未入力の扱いを決め、必要なら IS NULL を使って明示します。
時間帯のずれ。 データベースの日時が世界標準時で保存されていると、日本時間の日付とずれることがあります。日別や月別の集計が管理画面と合わないときは、まず時間帯を確認します。
テストデータや社内アカウントの混入。 開発や動作確認のために作られたデータが本番のデータベースに残っていることがあります。社内の利用者を除外する条件を決めておき、毎回付け忘れないようにします。
割り算で整数になる。 データベースによっては、整数同士の割り算で小数点以下が切り捨てられます。率を計算するときは、片方を小数として扱う書き方にするか、件数だけをSQLで出して、割り算は表計算ソフトで行うと安全です。
安全にSQLを使うための環境とルール
事業担当者がSQLを使うときは、データを壊したり、システムに負荷をかけたりしないための環境づくりが欠かせません。
- 読み取り専用の権限で使う：データの変更や削除ができない権限のアカウントを用意してもらう
- 本番のデータベースに直接つながない：可能であれば、分析用に複製したデータベースやデータウェアハウスを使う
- 個人情報の列を見せない：氏名や連絡先など、集計に不要な個人情報は見られない設定にする
- 重い処理に注意する：大きな表同士を条件なしでつなぐと、処理に長い時間がかかることがある
- 保存したSQLを共有する：よく使う集計は共有の場所に置き、誰が書いても同じ数字が出るようにする
分析用のデータの置き場所としては、BigQueryのようなクラウドのデータウェアハウスを使う方法があります。業務システムの本番データベースとは別の場所で集計できるため、システムへの影響を気にせずに試行錯誤できます。費用は処理するデータ量などで決まる仕組みのものが多いため、利用の前に料金体系を確認し、必要な列だけを取り出す書き方を心がけてください。
架空の例：SaaSの企画担当者が継続率を自分で出す
架空の例として、小規模なSaaSの企画担当者を考えます。この担当者は、新機能を出した後に利用者の継続が改善したかを知りたいと思っていましたが、毎回開発者に集計を依頼していたため、結果が出るまでに時間がかかり、依頼の回数も遠慮しがちでした。
開発者に相談して、分析用に複製されたデータベースへの読み取り専用のアクセスをもらい、まずは月別の利用者数を出すSQLを書くところから始めました。最初は JOIN で数字が重複する間違いもありましたが、管理画面の数字と照らし合わせることで原因に気づきました。
数週間後には、登録月ごとの継続状況の表を自分で作れるようになり、新機能のリリース前後で登録した顧客の継続を比べられるようになりました。開発者にとっても、集計の依頼が減ったことで開発に集中できるようになりました。SQLを覚えたことで、担当者と開発者の両方の時間の使い方が変わった例です。
SQL集計を始める前のチェックリスト
- 知りたいことを日本語の一文で書いたか
- 使う指標の定義（キャンセルの扱い、期間、時間帯）を確認したか
- 使う表の「1行が何を表すか」を確認したか
- 読み取り専用の権限で、分析用の環境を使っているか
- 社内アカウントやテストデータを除外する条件を入れたか
- JOIN の後の件数が想定どおりか確認したか
- 結果を管理画面や過去の数字と照合したか
- 正しいと確認したSQLを、目的と定義のメモ付きで保存したか
よくある質問
Q. SQLを覚えるのにどのくらい時間がかかりますか？
SELECT、WHERE、GROUP BY、COUNT・SUM の基本は、実際の業務データで手を動かしながらであれば、数日から数週間で使えるようになる人が多い内容です。JOIN や副問い合わせは、必要になったときに一つずつ覚えれば十分です。教科書を最初から読むより、自分が知りたい数字を出すことを目標に学ぶ方が身につきやすくなります。
Q. 生成AIにSQLを書いてもらってもよいですか？
下書きを作ってもらうのは有効な使い方です。表の名前や列の意味、知りたいことを伝えれば、基本的なSQLは書いてくれます。ただし、定義の解釈や JOIN による重複などの誤りが含まれることがあるため、結果は必ず別の情報源と照らし合わせて確認してください。また、社外のサービスに表の構造や実際のデータを入力してよいかは、社内のルールを確認してからにしましょう。
Q. スプレッドシートの集計とSQLは、どう使い分ければよいですか？
データの量が少なく、一度きりの集計であればスプレッドシートで十分です。データが大きくなって動作が重くなってきた、同じ集計を毎週繰り返している、複数の表を組み合わせる必要がある、といった場合はSQLの方が向いています。判断の目安はスプレッドシートでのKPI管理の限界も参考にしてください。
Q. データベースにアクセスする権限をもらえません。
まずは、何のためにどのデータを見たいのか、データの変更はしないこと、個人情報は見ないことを開発チームや情報システムの担当者に伝え、読み取り専用で分析用の環境を用意できないか相談してみてください。すぐに難しい場合は、必要なデータを定期的に書き出してもらい、それを集計する形から始める方法もあります。
Otsumuに相談できること
分析用の環境と読み取り専用の権限を用意でき、指標の定義がある程度そろっているなら、この記事の手順で事業担当者が自分でSQLを書き、KPIを集計できるようになるのは十分に現実的です。最初は一つの指標を自分で出してみて、既存の数字と照合するところから始めてください。
一方で、データが複数のシステムに分かれていて一か所で集計できない、本番のデータベースしかなく安全に分析できる環境がない、表の構造が複雑で何をどうつなげばよいか分からない、といった状況では、データの置き場所や集計の仕組みから整える必要があり、外部の力を借りた方が早いことがあります。
OtsumuはKPI改善コンサルティングとして、指標の定義づくりから、よく使う集計の整備、事業担当者が自分で数字を確認できる運用づくりまでを支援します。分析用のデータの集約や、自動で更新される画面が必要な場合は、ダッシュボード開発として、必要な範囲に絞って仕組みを作ることもできます。支援の範囲は状況に応じて個別にお見積もりします。
どの数字をどう集計すればよいかの相談だけでもかまいません。まずは30分の無料相談で、現在のデータと集計の状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01