はじめに：数値は出せても「で、どうする？」の考察が書けない課題

月次のKPIレポート作り、面倒ですよね。

売上、注文数、客単価、リピート率。BigQuery（以下BQ）でクエリを叩けば数値はすぐ出ます。表にして並べるところまでは、もう自動化できている方も多いと思います。

でも、本当にしんどいのはそこから先です。

  • 「売上が前月比で12%落ちた」→ で、なぜ？ どうする？
  • 「客単価は上がったのに注文数が減った」→ これは良い兆候？ 悪い兆候？
  • 「リピート率が改善した」→ どの施策が効いたと考えられる？

数値の横に書くべき「考察」のセクション。ここで毎回手が止まる、という相談をよくいただきます。数字を眺めても、その意味を言語化するのは別のスキルだからです。

この記事では、BQで集計した数値をClaude Codeに渡し、「考察」のドラフトまで書かせるためのプロンプト設計を紹介します。中小ECや個人事業主の方が、月次レポートの「考える時間」を圧縮することを想定しています。

Claude CodeからBQを直接参照する仕組みについては、MCPでBigQueryをClaude Codeにつなぐ社内分析の作り方で扱っています。本記事は「数値を渡した後」の話に絞ります。

全体の流れ：BQ集計 → 数値＋文脈をClaude Codeへ

まず処理の流れを整理しておきます。

  1. BQで月次のKPIを集計する（前月比・前年比を含む形で）
  2. 集計結果を、人間が読める形（表やJSON）に整える
  3. そこに「数値だけでは分からない文脈」を添える
  4. Claude Codeに考察を書かせる
  5. 出てきた考察を人間が裏取り・修正する

ポイントは3番です。数値だけ渡しても、AIは一般論しか書けません。「先月セールをやった」「主力商品が一時的に欠品した」といった文脈を一緒に渡すことで、考察の精度が一気に変わります。

集計の例として、前月比・前年比を同時に出すクエリのイメージはこんな形です。

WITH monthly AS (
  SELECT
    DATE_TRUNC(order_date, MONTH) AS month,
    COUNT(DISTINCT order_id)      AS orders,
    SUM(amount)                   AS revenue,
    SUM(amount) / COUNT(DISTINCT order_id) AS aov
  FROM `myshop.sales.orders`
  WHERE order_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 14 MONTH)
  GROUP BY month
)
SELECT
  month,
  orders,
  revenue,
  ROUND(aov) AS aov,
  ROUND(SAFE_DIVIDE(revenue, LAG(revenue) OVER (ORDER BY month)) - 1, 3) AS mom_growth,
  ROUND(SAFE_DIVIDE(revenue, LAG(revenue, 12) OVER (ORDER BY month)) - 1, 3) AS yoy_growth
FROM monthly
ORDER BY month DESC

mom_growth（前月比）と yoy_growth（前年比）を最初から列に持たせておくと、後でClaude Codeに「比較軸」を伝えやすくなります。

考察を引き出すプロンプト設計

ここからが本題です。考察を引き出すには、プロンプトに「考える枠組み」を明示します。投げっぱなしの「考察して」ではなく、軸を指定するのがコツです。

設計の3つの柱

考察を構造化するために、私は次の3点を必ずプロンプトに入れます。

  1. 比較軸 — 前月比・前年比・目標差。どの基準で良し悪しを判断するか
  2. 原因仮説 — なぜその変化が起きたのか、考えられる要因
  3. 打ち手の提案 — 来月、何を試すべきか

プロンプト例1：基本形

あなたはECの分析担当です。以下の月次KPIについて考察を書いてください。

# データ
| 指標 | 当月 | 前月 | 前月比 | 前年同月 | 前年比 | 目標 |
|------|------|------|--------|----------|--------|------|
| 売上 | 320万 | 364万 | -12% | 298万 | +7% | 350万 |
| 注文数 | 1,050 | 1,180 | -11% | 990 | +6% | 1,200 |
| 客単価 | 3,048円 | 3,085円 | -1% | 3,010円 | +1% | 2,917円 |

# 文脈（数値に表れない情報）
- 前月は季節セールを実施。当月は通常販売。
- 主力商品Aが月の後半1週間ほど欠品していた。

# 出力ルール
- 「比較軸ごとの評価」「原因仮説」「来月の打ち手」の3見出しで書く
- 各項目で、確かな事実と、推測・仮説を明確に分ける

文脈に「前月はセール」「商品Aが欠品」と書いてあるだけで、Claude Codeは「前月比のマイナスはセール反動と欠品で説明がつき、前年比はプラスなので基調は悪くない」といった、解像度の高い考察を返してきます。

プロンプト例2：仮説に優先順位をつけさせる

原因が複数考えられるとき、列挙だけだと使いづらいので、確からしさの順に並べさせます。

売上前月比 -12% の原因について、考えられる仮説を「確からしさの高い順」に
3つ挙げてください。各仮説には次を添えてください。
- 根拠（渡したデータ・文脈のどこから導いたか）
- 検証方法（その仮説を確かめるために次に見るべき数値）

「検証方法」を一緒に出させるのが地味に効きます。考察が次のアクション（追加クエリ）に直結するからです。

プロンプト例3：目標差にフォーカスする

経営判断では前月比より「目標に届いたか」が重要なこともあります。その場合は軸を絞ります。

今月の最優先KPIは「売上目標350万の達成」です。
未達（320万、達成率91%）の要因を、注文数と客単価に分解して説明してください。
注文数と客単価のどちらを来月優先して改善すべきか、理由とともに1つに絞ってください。

「1つに絞って」と指示すると、玉虫色の結論を避けられます。

事実と仮説を分けて書かせる工夫

考察で一番危ないのは、AIが推測をさも事実のように書いてしまうことです。これを防ぐため、出力フォーマットで事実と仮説を物理的に分けさせます。

具体的には、Markdownのblockquote（引用記法）を「仮説マーカー」として使わせる方法が分かりやすいです。

# 表記ルール
- データから直接読み取れる事実は、通常の文で書く。
- 推測・仮説・解釈は、必ず行頭に「> 仮説：」を付けて引用形式で書く。
- 文脈情報にも数値にも根拠がない推測は書かない。書く場合は「> 要確認：」を付ける。

このルールを入れると、出力はこういう形になります。

仮説：売上の前月比マイナスは、前月のセール反動と商品Aの欠品が主因と考えられます。前年比がプラスであることから、需要そのものは縮小していない可能性が高いです。

要確認：商品Aの欠品がなければ売上はいくらだったか。欠品期間の前後の日次売上を比較すると概算できます。

見た目で「これは事実」「これは仮説」「これは未確認」が一目で区別できます。レポートを上長やクライアントに見せるとき、この区別があるかないかで信頼性が大きく変わります。

補足：blockquoteを使うのはあくまで一例です。【事実】/【仮説】のようなタグでも構いません。大事なのは「断定と推測を機械的に分離する」ルールを最初に与えることです。

注意：考察は鵜呑みにせず裏取り

便利な仕組みですが、出てきた考察をそのまま提出するのは危険です。理由は3つあります。

1. もっともらしい嘘を書くことがある

AIは文脈が薄いと、一般論や「ありそうな話」で空白を埋めます。「梅雨で来店が減った」のような、データに根拠のない季節要因をしれっと書くことがあります。前述の「要確認」マーカーは、こうした推測を炙り出すための仕掛けでもあります。

2. 渡した数値が間違っていれば考察も間違う

考察の質は入力データの質に縛られます。BQのクエリで集計期間がずれていたり、テスト注文が混ざっていたりすると、考察は的外れになります。まずは数値そのものを疑ってください。

3. 因果と相関を混同しやすい

「施策Xをやった月に売上が伸びた」と「施策Xが売上を伸ばした」は別の話です。Claude Codeの考察はあくまで仮説の提示と捉え、本当に効いたかは別途の検証（A/Bや時系列比較）で確かめましょう。

裏取りのコツは、考察の中の「> 仮説：」と「> 要確認：」の行だけを抜き出して、一つずつ「これは本当か？」と確認することです。事実の行はデータと突き合わせ、仮説の行は別データで検証します。

どのAIに考察を任せるかで得意・不得意も変わります。ツール選びの観点はChatGPT・Claude・Geminiをデータ分析で比較した話にまとめています。

まとめ

月次KPIレポートの「考察」を、Claude Codeに下書きさせるためのポイントを整理します。

  • 数値だけでなく文脈を渡す — セール・欠品・キャンペーンなど、数字に表れない情報が考察の精度を決める
  • 考える枠組みを指定する — 比較軸（前月比/前年比/目標差）、原因仮説、打ち手の3点を明示する
  • 事実と仮説を分けさせる — blockquoteなどで断定と推測を機械的に分離し、信頼性を担保する
  • 必ず裏取りする — もっともらしい嘘・入力ミス・因果の混同を、人間がチェックする

考察は「人間が考える」プロセスを丸ごと置き換えるものではありません。あくまで、白紙から書き始める負担を減らし、人間が検証・判断に集中できるようにするための下書き役です。

毎月のレポート作成で、数値を並べた後に手が止まってしまう方は、まず文脈付きのプロンプトを一つ試してみてください。考察の最初の一行が出てくるだけで、ぐっと楽になります。