ClaudeでQBR資料を作る — 利用実績と問い合わせ履歴から顧客別に

QBR(四半期ビジネスレビュー)は、既存顧客に「この3か月で何が起き、次の3か月で何をするか」を見せる定例の資料です。材料は毎回そろっています。利用ログのCSV、営業やCSの案件メモ、サポートの問い合わせ履歴です。

Claudeに任せると、この3種類を1枚の流れに組み直す作業が速くなります。一方で、顧客の前に出る資料なので、数字が一つ違うだけで信用を落とします。この記事では、資料の下書きを作る手順と、数字の出所を残して照合する手順を分けて扱います。

Claudeに任せる範囲と、人が決める範囲

QBR作りの作業を分けると、Claudeが得意なのは「材料を並べ替えて文章にする」部分です。何を約束するかは人が決めます。

最後の2行は、資料の中身というより契約と関係性の話です。Claudeには「提案の選択肢を3つ、根拠とリスクつきで出して」と頼み、採用する案は人が選びます。

渡す材料を3種類に分ける

材料は性質が違うので、混ぜずに別ファイルで渡します。

• 利用データ: 利用ログやアカウント別の指標。CSVかXLSX
• 案件メモ: 導入の経緯、合意した目標、前回QBRで約束した宿題。テキストかドキュメント
• 問い合わせ履歴: サポートのチケット一覧。件名、起票日、カテゴリ、状態、解決日

ファイルの扱いには上限があります。サポート記事によると、チャットへのアップロードは1ファイル500MB、1チャット20ファイルまでです。Projectsのファイルは1ファイル30MBで、ファイル数に制限はないものの全体がコンテキストウィンドウに収まる必要があります。XLSXをアップロードするには、アカウントでコード実行とファイル作成を有効にしておく必要があります。

顧客ごとに資料を作るなら、顧客1社を1つのProjectにする運用が合います。前回までのQBRと案件メモが残り、次の四半期にそのまま続けられるからです。Projectsにファイルを置く考え方は顧客インタビューから導入事例を作る手順でも同じ型で扱っています。

利用データのCSVは列の意味を先に書く

CSVは列名だけ渡すと、Claudeが意味を推測して集計します。列の定義を添えてから渡します。

month,account_id,active_users,licensed_seats,api_calls,errors
2026-07,A-1001,42,60,128400,310
2026-08,A-1001,47,60,141900,254
2026-09,A-1001,51,60,160200,198

# データ定義(Projectsの指示に貼る)
- active_users: その月に1回以上ログインしたユーザー数(重複なし)
- licensed_seats: 月末時点の契約席数
- 利用率 = active_users / licensed_seats
- 四半期 = 7〜9月。前四半期は4〜6月
- 集計結果には必ず「どの列のどの行から算出したか」を併記する

「利用率」の分母が契約席数なのか、招待済みユーザー数なのかは、会社によって違います。定義を書かずに渡した集計は、数字が合っていても意味が顧客の認識とずれることがあります。

手順1: 数字の台帳を先に作らせる

最初に文章を書かせません。資料に載せる数字の候補を、出所つきの表にして出させます。

台帳づくりの依頼は、たとえば次のように書きます。

添付の usage_2026Q3.csv と tickets_2026Q3.csv から、
A-1001 社のQBRに載せうる数字を「数字の台帳」として表にしてください。
 
列: 指標名 / 値 / 前四半期の値 / 算出方法 / 元ファイルと列名 / 対象行数
条件:
- 算出方法は式で書く(例: 9月のactive_users ÷ 9月のlicensed_seats)
- 元データにない数字、推測した数字は台帳に入れない
- 問い合わせは件数、解決までの中央値、カテゴリ別の件数に分ける
- 定義があいまいな指標は、表の下に「確認が必要な点」として列挙する

「対象行数」の列を入れる理由は、集計から行が落ちていないかを後で確かめられるからです。たとえば9月分のデータが途中までしか入っていない場合、行数を見れば気づけます。

台帳に出所を持たせると何が変わるか

出所のない数字は、誰も検算できません。台帳があれば、レビューする人は「この数字はこの列のこの行から出た」と辿れます。QBR資料の信頼性は、文章のうまさよりも、数字を辿れるかどうかで決まります。

手順2: 振り返り・課題・次四半期の三部構成で書かせる

台帳ができたら、本文を書かせます。QBRの標準的な構成は三部です。

1. 成果の振り返り: 目標に対する実績。数字は台帳から
2. 課題: 利用の伸び悩み、問い合わせの多い領域、未解決の宿題
3. 次四半期の提案: 具体策、担当、期日、見込む効果

台帳(上の表)と、案件メモ(notes_A1001.md)だけを根拠に、
QBRの本文を下書きしてください。
 
- 構成: 成果の振り返り / 課題 / 次四半期の提案
- 数字は台帳にあるものだけを使い、文中に(台帳#番号)を付ける
- 案件メモの「前回の約束」ごとに、達成・未達・保留を判定し、根拠の行を示す
- 提案は3案出し、それぞれ根拠・必要な作業・リスクを書く。推奨は付けない
- 顧客の社内事情を推測した記述は書かない

「前回の約束」の判定は、QBRで見落とされやすい箇所です。前回QBRで約束した宿題が今回触れられていないと、顧客は覚えています。案件メモに宿題が箇条書きされていれば、Claudeはそれを一つずつ拾って照合できます。

問い合わせ履歴は件数だけでなく中身を読ませる

チケット履歴は、件数の増減だけ載せても課題が見えません。件名と本文からカテゴリを分け、どの機能に集中しているかを出させます。

tickets_2026Q3.csv の件名と本文を読み、問い合わせを機能別に分類してください。
分類は5つ以内。各分類について、件数・代表的な件名3つ・
解決までの中央値を表にし、前四半期との差があれば示してください。

分類の粒度は人が決めたほうが安定します。Claudeに自由に分類させると、実行のたびにカテゴリ名が変わり、四半期をまたぐ比較ができなくなります。分類の名前は、前回のQBRで使ったものをProjectの指示に貼っておきます。

手順3: スライドにして、数字を照合する

本文が固まったら、ファイルにします。Claudeはコード実行とファイル作成の機能で、PowerPoint(.pptx)、Excel(.xlsx)、Word(.docx)、PDFを作れます。生成したファイルは会話からダウンロードできます。

下書きをもとに、QBR用のスライド(.pptx)を作ってください。
- 1スライド1メッセージ。タイトルは結論を文にする
- 台帳の数字だけを使い、各スライドの下に出所を小さく入れる
- 社内向けの注記(担当者名、社内の評価)は入れない

ファイル作成の機能は、Free・Pro・Max・Team・Enterpriseの各プランでWeb、Desktop、Mobileから使えます。TeamとEnterpriseでは、組織の管理画面の設定(Organization settingsのCapabilities)で、機能の有効・無効を管理者が切り替えます。

顧客に出す前の照合チェック

スライドができても、そのまま顧客に出しません。次の点を人が確かめます。

元データの再集計は、Claudeとは別の経路で行うと検算になります。次のPythonは、上のCSV例の利用率を手元で計算する例です。

import pandas as pd
 
df = pd.read_csv("usage_2026Q3.csv")
q3 = df[df["month"].isin(["2026-07", "2026-08", "2026-09"])]
 
# 月ごとの利用率(定義: active_users / licensed_seats)
q3 = q3.assign(rate=q3["active_users"] / q3["licensed_seats"])
print(q3[["month", "account_id", "rate"]].round(3).to_string(index=False))
print("対象行数:", len(q3))

台帳の「対象行数」とここで出る行数が違えば、集計の元データが違っています。数字そのものが近くても、行数が違うならやり直します。

HubSpotコネクタで案件・チケットを直接引く場合

案件メモやサポート履歴がHubSpotにあるなら、CSVに書き出さず、HubSpotコネクタ経由で引く方法もあります。コネクタのページには、連絡先・会社・取引・チケット・キャンペーンの検索と更新ができると書かれています。ツール一覧には get_crm_objects、query_crm_data、manage_crm_objects などが並び、全部で36ツールです。サインインが必要で、接続先URLは https://mcp.hubspot.com/anthropic です。

QBRの材料としては、会社に紐づくチケットと取引の履歴を読む用途が合います。ただし、使う前に次の点を確かめます。

• 権限は引き継がれる: コネクタは接続した本人の権限で動きます。本人がHubSpotで見られないレコードは、Claudeからも見えません
• 書き込みも可能: manage_crm_objects のように更新系のツールが含まれます。QBR資料づくりは読み取りだけで足りるので、組織のオーナーはツール権限を「読み取りのみ」に絞れます(CustomizeのConnectorsでツールごとにAlways allow / Needs approval / Blockedを選べます)
• TeamとEnterpriseでは先に管理者が有効化: 有効化しても全員に自動で権限が付くわけではなく、各自が認証します

接続の手順や、HubSpot側で必要な権限はClaudeとHubSpotの連携手順に、商談・チケットを聞くプロンプトの例はHubSpot営業分析のプロンプト集にまとめています。

コネクタで引いた数字の出所も台帳に残す

コネクタ経由だと、元データのファイルが手元に残りません。そこで、引いた直後に「どのオブジェクトを、どの条件で、何件引いたか」を台帳の出所欄に書かせます。

HubSpotから、会社「A社」に紐づく2026年7〜9月のチケットを取得してください。
取得後、次を台帳の出所欄に記録してください。
- 使ったツールと検索条件(期間、会社、状態)
- 取得件数
- 件数が上限で切れていないか

件数が上限で切れていないかの確認は、一覧系の取得で見落としやすい点です。切れていれば、期間を分割して取り直します。

顧客に見せる資料に、見せられない情報を混ぜない

QBR資料の事故で多いのは、数字の誤りと並んで、社内向けの情報が混ざることです。案件メモには、顧客に言えない内容が書かれていることがあります。

• 解約リスクの社内判定
• 値引きの許容範囲
• 担当者の主観的な評価
• 他の顧客の名前や事例

解約リスクの洗い出し自体は別の作業です。リスク顧客の抽出はClaudeとGainsightで解約リスクの顧客を洗い出す手順で扱っています。QBR資料にその判定を載せることはありません。

材料を渡す段階で、顧客向けと社内向けを分けておくと混入を防げます。社内向けのメモは別のProjectに置きます。1つのProjectに両方を置くなら、指示に次の一文を入れます。

案件メモのうち、見出しが「社内のみ」のブロックは資料に使わない。
使った箇所には「社内のみ」の文字が含まれないことを、出力前に確認する。

それでも、最終確認は人が行います。指示は守られやすくなりますが、守られたことの保証にはなりません。

データの外部送信に気をつける

コード実行とファイル作成の機能には、ネットワーク接続の設定があります。Team・Enterpriseでは、組織のオーナーが接続先をパッケージマネージャーのみ、または無効に設定できます。ただし、コネクタ(MCP)を有効にしていると、ネットワークの設定にかかわらず、その接続を通じた通信は残ります。顧客データを扱うときは、組織の設定を管理者に確かめ、Claudeの動作を見ながら進めます。

つまずきやすい点

まとめ

QBR資料の下書きは、利用CSV・案件メモ・問い合わせ履歴を別々に渡し、先に出所つきの数字の台帳を作らせると安定します。本文は台帳にある数字だけで書かせ、提案は選択肢で出させて採用は人が決めます。

顧客に出す前の確認は、台帳とスライドの一致、台帳と元データの一致、期間の定義、社内情報の混入の4点です。HubSpotコネクタで直接引く場合も、取得条件と件数を台帳に残す運用は変わりません。