「データベースサービスのSQLでクエリを叩いたことはある。でも、Claude Code は初めて」
「日本語で頼むと、SQLを書いて実行し、グラフやレポートまで返してくれる噂は聞いたが、自分が使いこなせる気がしない」
データ分析チームに新しく加わった方や、SQLは書けるがAIエージェントは未経験という方から、こうした相談をよく受けます。
私はこれまで事業会社・副業先企業のデータサイエンティストとして、分析メンバー向けに Claude Code × MCP Server のオンボーディングを設計・実施しました。
本記事では、そのオンボーディング資料をもとに、はじめての集計案件をひとりで完遂するまでに必要な型を整理して共有します。
読み終える頃には、Claude Code の全体像と、集計案件を「精度を担保したまま効率的に並行で回す」ための実践パターンが、自分の言葉で説明できる状態を目指します。
本記事のターゲット
- データアナリスト・データ分析担当で、Claude Code をこれから使い始める方
- データベースサービスやSQLの経験はあるが、AIエージェントでの分析フローは初めての方
- チーム内で Claude Code を標準ツールとして導入し、オンボーディングの型を探しているリーダーの方
- MCP Server 経由でデータベースに接続する社内ルールのもとで、安全に分析を進めたい方
※本記事は Claude Code のセットアップが完了していることを前提としています。
第1部：基礎・環境 ── 相棒と仲間を知る
Claude Code の全体像：「日本語で頼むと、成果物が返ってくる」
Claude Code の本質はシンプルです。あなたが日本語で依頼を投げると、Claude Code がそれを解釈し、必要な裏方を全部動かして、整った成果物にして返してくる。
内部では、次のようなリレーが起きています。
- Input：あなたが「〜を集計してレポート化して」と日本語で頼む
- Claude Code が依頼を解釈し、処理全体を指揮する（司令塔）
- MCP Server 経由で社内ドキュメントやデータ基盤に接続し、データベースサービスのSQLでクエリを実行してデータを取得する
- 必要に応じてサブエージェント（専門の助手）を自動で起動し、レビューや可視化を分担させる
- 取得した結果をメモリ上で受け取り、加工・可視化・レポート化する
- Output：集計結果・グラフ・レポートとして、あなたの手元に返ってくる
利用者がやるのは「日本語で依頼すること」だけ。 SQLの実行・サブエージェントの起動・結果の整形は、すべて Claude Code が裏側で担い、成果物だけが返ってきます。
だからこそ 「何を・どんな基準で頼むか」が品質を決める。
本記事の後半は、ずっとこの話になります。
Claude Agent と並行実行
集計案件を効率よく回すうえで、複数タスクを並行して処理することが、生産性向上に直結しやすい
——これがまず押さえるべき前提です。
ひとつずつ順番に待つのではなく、独立した作業を同時に走らせることで、クエリ実行の待ち時間やレビューの空き時間を有効活用できます。
そのための核心が、Claude Agent へのタスク振り出しをマスターすることです。
Claude Code は、ひとつのセッションから複数のタスクをそれぞれのエージェントに振り出して、同時に走らせられます。「案件A」「案件B」のように独立した作業を並行で進めたいときに効きます。
タスクの状態は次の2つで管理されます。
| 状態 | 意味 |
|---|---|
| Working（実行中） | 振り出したタスクが処理中。ここに表示される |
| Completed（完了） | タスクが終わるとここへ移動。成果物を回収して次へ |
実行方法
- コマンド
claude agentsを実行し、各エージェントにタスクを割り当てる - 各タスクの状況を見るには、見たいタスクにカーソルを当てて「→」を押すか、直接クリックする
「独立した作業を並行で」が肝です。
互いに依存しない案件を同時に進めれば、待ち時間が大きく減ります。
逆に、前の結果を受けて次を決めるような作業は、無理に並行させず順番に進めた方がよいでしょう。
並行実行の型を身につけることが、Claude Code 活用の効率を大きく左右します。
SQL配置ルール：道具の置き場所
コードと同じで、SQLも置き場所を間り違えると事故を生みます。
意図しないテーブル参照やSQLの取り違えを防ぐため、用途で置き場所を分けて管理するのがチームの約束としています。
以下は一例です。自社のリポジトリ構成に合わせて読み替えてください。
汎用とプロジェクト固有でディレクトリを分けて管理する。
こうしておくと「似た名前の別マートを誤って参照する」事故を未然に防げます。
第2部：はじめての集計案件 ── 4ステップでやり遂げる
集計案件には「型」がある
はじめての集計案件に直面すると、いきなりSQLを書き始めたくなるものです。しかし、現場で回っている集計案件には進め方の型があります。
次の4ステップ、
①要件整理 → ②集計依頼 → ③クエリチェック・修正 → ④レポート依頼・納品————に沿って進めることで、抜け漏れなく品質を保てます。
| # | 名称 | やること |
|---|---|---|
| ① | 要件整理（Requirements） | 依頼背景・抽出条件を整理し、結果の確からしさを判断できる数値・基準も定義する |
| ② | 集計依頼（Request） | 整理した要件を Claude Code に依頼する。確からしさの基準も併せて投げる |
| ③ | クエリチェック・修正（Review） | クエリの誤り（採用テーブル・条件文）を重点確認し、基準と突合して修正する |
| ④ | レポート依頼・納品（Delivery） | 出力行数制限に注意。納品フォーマットがあれば読み込ませて整形を依頼し、納品する |
効率より先に「正しさ」── 結果が間違っていては意味がない
いくら Claude Code で効率的に集計を回しても、結果が間違っていては意味がありません。ここで重要なのは、数字の正しさを判断するのは、データの定義や現場の感覚に詳しい集計者自身だということです。
たとえば、集計上の継続率が 30% と出たとします。一方、現場が日々追っている水準は 20% である
——10ポイントも乖離している。
このとき、単に「SQLの計算ミス」と決めつけるのではなく、SQL上の定義が現場の定義と異なっている可能性を疑うべきです。
「継続」のカウント開始タイミングが違う、対象母数の絞り込みが違う、など定義のズレが数字のズレとして表面化しているケースは珍しくありません。
こうした乖離は、納品直前に気づくのが遅すぎます。
集計の過程で、定義の整合性を考慮できるようにしておく必要があります。
そのための鍵が、要件整理の段階で「確からしさの基準」をしっかりヒアリングし、以降のリクエストに盛り込んでいくことです。
4ステップ共通の「品質の肝」
「集計結果の確からしさ」を集計者自身が認識し、基準をもって依頼・確認を行うこと。この一点を外すと、もっともらしいけれど間違った数字が、そのまま納品されてしまいます。
ステップ① 集計要件整理 ── 「確からしさ」との出会い
手を動かす前に、まず「何が正しいと言えるのか」を決める。
これがこの記事でいちばん大事な場面です。
この作業ですること
- 依頼背景・目的を確認する
- 抽出条件（期間・対象・粒度）を言語化する
- アウトプットイメージ（列・集計軸）を確定する
- 使用しそうなテーブル・パーティションを当たる
- 現場の定義・追跡数値をヒアリングし、「確からしさの基準」を整理する
最大の山場「確からしさの設計」
- 集計結果が正しいかを後で判断できるよう、「合致すべき数値」とその基準を先に整理する（例：全社管理数値 / 各部の責任数値）
- どこまでズレたら NG か（許容範囲）も決めておく
- 指標の定義（分子・分母・対象期間・除外条件）を言語化しておく
この「ものさし」が無いと、出てきた数字の正しさを誰も判断できません。Claude Code が返す数字は、それらしく見えても検証が必要です。
基準があって初めて「合っている」と言えます。
「出力が何と一致していれば正しいと言えるのか」「指標の定義は現場とどう合わせるか」を、集計依頼する前（要件整理の時点）に決め切るのが品質を上げるコツです。
ステップ② 集計依頼 ── 基準と定義を「一緒に」渡す
要件が固まったら、いよいよ Claude Code への依頼です。
ここでのコツは、整理した要件だけでなく「確からしさの基準」と指標定義も一緒に渡すこと。
この作業ですること
- 整理した要件を Claude Code に依頼する
- 使用テーブル候補を明示する
- パーティションを明示する
- 出力先・形式（集計のみ）を明示する
パーティションを明示する2つの理由
- 分析対象の時点を明確にする── 時系列データでは、いつの状態を集計対象とするかで結果が変わります。パーティションを指定することで、「2026年4月時点のデータを見る」といった分析スコープをはっきりさせられます。
- 集計効率・スキャン効率を高め、コストを抑える── パーティション列を指定したクエリは、対象期間のデータだけを読み込みます。指定なしのフルスキャンと比べ、処理時間とコストの両方を大幅に削減できます。
依頼文の例
sql/.../xxx.sql の定期契約人数合計と一致する集計を実施してください。
継続率は現場の追跡数値（約20%）と±2pt以内で一致することを確認してください。
期間は dt = '2026-04'、使用テーブルは xxx_mart、出力は集計結果のみで。基準を渡すと何が変わるか
- 要件整理で決めた「合致数値」「許容範囲」「指標定義」を依頼文に含めることで、Claude 側で件数チェック・検算・定義確認まで実施させられる
- 逆に基準を渡さないと、定義のズレに気づかないまま作業が進んでしまう
確からしさを Claude 側でチェックできるように「SQL ＋ 基準 ＋ 定義 ＋ パーティション」の形で依頼するのがおすすめです。
ステップ③ クエリチェック・修正 ── よくある誤りとの対峙
Claude Code はあっという間にSQLを書き、結果を返してきます。数字も出ている。
——ここからが集計者の腕の見せ所です。
この作業ですること
- 生成されたSQLの内容を読んで確認する
- 集計結果を「確からしさ基準」と突合する
- 現場の追跡数値と大きく乖離していないか、定義のズレがないかを確認する
- 誤りがあれば修正を依頼する／自分で修正する
よくある誤り（重点確認）
| # | 誤りの種類 | 内容 |
|---|---|---|
| ① | 採用テーブルの誤り | 似た名前の別マートを参照しているケースが多い |
| ② | 条件文の誤り | 期間・フラグ・結合キー・絞り込みの取り違え |
| ③ | 指標定義のズレ | SQL上の定義が現場の定義と異なり、数字だけが大きく乖離する |
この3つが特に多い。必ずチェックしてください。
基準値との突合をしつつ、クエリが「正しいテーブルを、正しい条件で、正しい定義で」見ているかを確認する。
ステップ④ レポート依頼・納品 ── そして記録を残す
数字の正しさを確認できたら、最後はレポートに仕上げて納品します。
この作業ですること
- 集計結果をレポート／グラフにまとめる
- 納品フォーマットに整形する
- 最終チェック（数値・体裁・ポリシー遵守）
- 集計結果・グラフ・レポートのみ納品する
- 一連の作業内容を Word 等に出力して残す（推奨）
依頼文の例
ここまでの一連の作業を Word ファイルにまとめてください。納品時の注意
- SQLの出力行数制限に引っかかることが多い → 集計粒度を粗くする／クエリを分割する／SQLは手元で実行する
- 納品フォーマットが決まっていれば、そのファイルを読み込ませて依頼すると整形精度が上がる（例：A.xlsx の数値を埋めて）
- 作業内容を Word で残すと、振り返りやすく、他の人も参照しやすい（＝ノウハウの蓄積）
Claude Code の制約内で依頼できることはしつつ、一連の作業内容は資料化しておくことで、後世の作業者の救いになります。
第3部：実践事例 ── 複数軸の集計を、たたき台から仕上げる
チャネル別・月次コンバージョン率の比較分析
数案件をこなしたある日、こんな依頼が回ってきた。
「流入チャネル別の新規登録数と、登録後30日以内の初回購買率を月次で比較したい」。
チャネル定義の整理、購買判定の条件、パーティション指定
——要素が多く、ゼロから組むと骨が折れます。
Claude Code はこういう「たたき台づくりの相棒」として頼れます。
依頼文の例
流入チャネル別に、2026年1〜3月の新規登録数と
登録後30日以内の初回購買率を月次集計してください。
初回購買率は sql/.../monthly_conversion.sql の定義に合わせ、
現場の追跡値（Organic約15%、Paid約8%）と±3pt以内で確認してください。
パーティション dt は各月を指定、出力は集計結果のみで。返ってきた「たたき台」を、レビューして調整していく
- Paid チャネルの購買率が現場水準より10pt高い → チャネル帰属の定義（ラストクリックかファーストクリックか）を確認し、修正依頼する
- 特定月だけ登録数が異常に多い → パーティション指定とボット除外条件を再確認する
- 表が読みにくい → チャネル上位N件に絞り、残りは「その他」にまとめるよう依頼する
修正依頼の例
Paid チャネルの帰属はラストクリック（登録直前の流入元）で判定してください。
sql/.../channel_attribution.sql を参考に修正してください。
複数条件が絡む集計も「たたき台」から始め、確からしさ基準と定義確認を重ねて磨く。ゼロから完璧を狙わせるのではなく、現場の数字と突合しながら仕上げる。
まとめ：精度よく・効率的に回す4つの要点
最初は不安だらけでも、型さえ身につければ自分の言葉で集計案件を語れるようになります。
最後に要点を4つだけ振り返りましょう。
01 集計案件は4ステップの型で進める
①集計要件整理 → ②集計依頼 → ③クエリチェック・修正 → ④レポート依頼・納品。
型に沿って進めることで、抜け漏れなく品質を保てます。
02 「確からしさの基準」と指標定義を最初に決め、依頼時に一緒に渡す
現場の追跡数値・合致すべき数値・許容範囲・指標定義を要件整理でヒアリングし、集計依頼に含めます。
定義のズレは納品前ではなく集計の過程で突き止めます。
03 Claude Agent で並行実行をマスターする
独立タスクは claude agents で並行実行（Working→Completed）。
複数案件を同時に回すことが、効率向上に直結しやすいです。
04 テーブル候補とパーティションを明示し、作業ログは Word で残す
パーティション指定は分析対象の時点を明確にし、スキャン効率・コスト削減にもつながります。
納品時は一連の作業内容を Word に出力しておくと、振り返り・共有がしやすく、ノウハウとして蓄積されます。
Claude Code は「魔法の箱」ではなく、正しい型と基準をもって使うことで初めて力を発揮する相棒です。
はじめての集計案件こそ、4ステップを意識して進めてみてください。
よくある質問
使えます。Claude Code への依頼は日本語で行い、SQLの実行・結果の整形はすべて裏側で自動処理されます。必要なのはデータベースサービスのSQLの基礎知識と、「何を・どんな基準で頼むか」を整理する力です。集計者としての「確からしさの判断」が品質を決めます。
集計結果が正しいかを後から判断できる「ものさし」です。既存の定期集計SQLの件数と一致するか、現場の追跡数値と合致するか、許容できるズレの範囲はどこまでか、指標の定義（分子・分母・対象期間）は現場とどう合わせるか——を要件整理の段階でヒアリングし決めます。この基準を以降のリクエストに盛り込むことで、集計の過程で定義のズレに気づけます。
まずSQLの計算ミスではなく、指標定義のズレを疑ってください。例えば集計上の継続率が30%なのに現場の追跡値が20%なら、10ptの乖離は「継続」のカウント開始タイミングや母数の絞り込みが現場と異なるサインです。納品前ではなく集計の過程で、確からしさ基準と定義を突合し、修正依頼を出してください。
複数タスクを並行して回すことが、生産性向上に直結しやすいです。互いに依存しない独立した案件であれば、コマンド「claude agents」で各エージェントにタスクを振り出し、並行実行できます。Working（実行中）と Completed（完了）で状態を確認し、完了したタスクから成果物を回収します。Claude Agent への振り出しをマスターすることが、効率化の鍵です。
2つの理由があります。1つ目は、時系列データの中で「どの時点を分析対象とするか」を明確にするためです。2つ目は、パーティション列を指定した集計は対象期間のデータだけをスキャンするため、処理時間とコストの両方を削減できるからです。テーブル候補とあわせて、依頼文に必ず含めてください。
①集計要件整理（背景・条件・確からしさ基準の定義）→ ②集計依頼（基準・定義・テーブル・パーティションを明示して Claude Code に依頼）→ ③クエリチェック・修正（SQL内容と基準値の突合）→ ④レポート依頼・納品、の4段階です。いくら効率的に回しても結果が間違っていては意味がないため、型に沿って「正しさ」を担保しながら進めます。
用途で置き場所を分けます。チーム共通の再利用クエリは queries/shared/ 配下（staging/ と live/ に分離）、案件固有のクエリは queries/cases/{案件名}/ 配下（prep / metrics / explore / validate / deliver など）に置くのが一例です。自社の構成に合わせて読み替えつつ、共通と案件固有を分けて管理することが重要です。
進められます。チャネル別の月次コンバージョン率のように要素が多い集計も、まず「たたき台」を Claude Code に作らせ、現場の追跡数値と突合しながら定義や条件を修正していく進め方が効果的です。確からしさ基準を依頼に含め、ゼロから完璧を狙わず叩いて磨くイメージで進めてください。
いいえ、必ず検証が必要です。Claude Code はあっという間にSQLを書いて数字を返しますが、それらしく見えても間違っていることがあります。採用テーブルの誤り、条件文の取り違え、指標定義のズレ——特に現場の追跡数値との乖離は定義不一致のサインです。③のクエリチェックで確からしさ基準と突合してください。
Claude Code に「ここまでの一連の作業を Word ファイルにまとめてください」と依頼することで、要件・確からしさ基準・依頼内容・修正履歴・最終結果が一つの資料にまとまります。振り返りが容易になり、他のメンバーも参照できます。チーム全体のノウハウ蓄積にもつながるため、納品時の習慣として定着させることをお勧めします。
