Claudeのvalidate-dataで分析を共有前に点検する手順と使いどころ
Anthropic製dataプラグインのvalidate-dataは、集計ロジックやバイアスを共有前に点検するスキルです。入れ方、8つの手順、7つの落とし穴、判定の3段階と限界を解説します。
validate-dataは、Anthropicがknowledge-work-pluginsリポジトリで公開しているdataプラグインのスキルです。経営会議の前に集計を見直す、SQLの結果が妥当か疑う、グラフの軸が読者を誤解させないか調べる。こうした「共有前の点検」を、決まった手順でClaudeに回させます。
この記事では、入れ方、点検の8手順、チェックリストと落とし穴の中身、判定の読み方を説明します。後半では、このスキルが何をしないのかも書きます。
validate-dataは何を点検するスキルか
SKILL.mdの説明文は「共有前の分析をQAする。方法論、正確性、バイアスの点検」です。使う場面として、利害関係者への発表前のレビュー、計算と集計ロジックの抜き取り検査、SQL結果の妥当性確認、結論がデータで支えられているかの評価が挙がっています。
引数のヒントは<analysis to review>です。点検対象は、次のどれでも構いません。
- 会話内の文書やレポート
- ファイル(Markdown、ノートブック、スプレッドシート)
- SQLクエリとその結果
- グラフと元データ
- 方法論と結果の文章による説明
分析そのものを作るスキルではありません。作った後に疑う側のスキルです。dataプラグインの中では、build-dashboardやdata-context-extractorと並ぶスキルの1つで、READMEは「分析を共有する前に検証する」役割に位置づけています。
入れ方と呼び出し方
READMEのインストール手順は次の2行です。
claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install data@knowledge-work-pluginsdataプラグイン(plugin.jsonのバージョンは1.1.0、作者はAnthropic)は、READMEで主にCoworkのために設計されたと書かれていて、Claude Codeでも動きます。Claude Code側のマーケットプレイスの仕組みはClaudeプラグイン(Plugins)完全ガイドで扱っています。
呼び出しは、スラッシュコマンドに点検したい対象を続けます。SKILL.mdの例は次の3つです。
/validate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]
/validate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window
/validate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]2つ目の例が示すように、疑っている点を先に伝えて構いません。「Q4は測定期間が短い」と書いておけば、期間の比較が点検の中心になります。
点検は8つの手順で進む
SKILL.mdのWorkflowは8段階です。順番に何をするかを見ると、このスキルが「チェックリストの読み上げ」でないことが分かります。
validate-dataの8段階
- 1
方法論と前提を見直す
問いの立て方、データの選び方と期間、母集団の定義、指標の定義、比較の公平さを調べます。
- 2
共有前QAチェックリストを通す
データ品質、計算、妥当性、表示の4群を順に当てます。
- 3
分析でよくある落とし穴と照合する
結合による行の水増しや生存者バイアスなど、7つの典型を一つずつ当てます。
- 4
計算と集計を検算する
主要な数値を独立に再計算し、小計が合計に合うか、前年比・前月比の基準期間が正しいかを見ます。
- 5
可視化を評価する
棒グラフの軸がゼロから始まるか、比較するグラフの目盛が揃っているかを見ます。
- 6
語りと結論を評価する
結論がデータで支えられているか、別の説明が検討されているか、確信度が証拠の強さに見合うかを見ます。
- 7
改善案を出す
追加すべき分析、書くべき注意点、見せ方の代案、足りない文脈を挙げます。
- 8
確信度を3段階で判定する
「共有してよい」「注意点つきで共有」「修正が必要」のいずれかを出します。
注目したいのは4番目です。「主要な数字を独立に再計算する」と書かれているので、点検の入力にSQLと元データを両方渡すほど、検算が具体的になります。数字の結果だけを貼ると、再計算の足場がありません。
チェックリストは4群22項目
手順2のチェックリストは、群ごとに項目数が決まっています。
| 群 | 項目数 | 主な内容 |
|---|---|---|
| データ品質 | 項目数6 | 主な内容ソース、鮮度、欠損の穴、null、重複、フィルタ |
| 計算 | 項目数6 | 主な内容集計の粒度、分母、日付の揃い、JOINの種類、指標定義、小計の合算 |
| 妥当性 | 項目数5 | 主な内容桁の妥当性、傾向の連続性、他ソースとの照合、規模感、境界条件 |
| 表示 | 項目数5 | 主な内容グラフの正確さ、数値の書式、タイトル、注意書き、再現性 |
表示の群にある「タイトルは指標名でなく洞察を述べる」と「他の人が資料から分析を再現できる」は、グラフの見栄えより共有後の運用に効く項目です。後者を満たすために、SKILL.mdは分析文書のひな形も載せています。
7つの落とし穴と、現場で効く検出法
手順3の落とし穴は、SKILL.mdの見出しで7つ挙がっています。結合による行の水増し(join explosion)、生存者バイアス、期間が不完全な比較、分母の途中変更、平均の平均、タイムゾーンのずれ、アウトカムで区切ったセグメント化です。
最初の結合による水増しは、SQLで次のように検出できます。SKILL.mdにある書き方です。
-- 結合の前後で行数を比べる
SELECT COUNT(*) FROM table_a; -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id; -- 3,500結合後に行数が増えていたら、関係が本当に1対1なのかを疑います。エンティティ数を数えるときはCOUNT(*)でなくCOUNT(DISTINCT a.id)を使う、という対処も添えられています。
平均の平均は、手計算で理由が分かります。SKILL.mdの例では、グループAが100人で平均50ドル、グループBが10人で平均200ドルです。単純に平均すると125ドルですが、人数で重みづけすると(100×50+10×200)÷110で約63.64ドルです。グループの大きさが違うと、結論そのものが2倍近く変わります。
このほか「その他の統計的な罠」として、シンプソンのパラドックス、相関と因果の混同、小さい標本、外れ値、多重検定、先読みバイアス、都合のよい期間選びも並びます。
数字の「におい」を見る赤信号
妥当性の確認には、指標の種類ごとの桁感の確認、他ソースとの照合の5手法、調べるべき赤信号の3つが書かれています。
指標の種類ごとの桁感
SKILL.mdは、主要な数字ごとに「そのまま信じてよい桁か」を問う項目を挙げています。
- ユーザー数: 既知のMAU・DAUの数字と合うか
- 売上: 既知のARRと桁が合っているか
- 転換率: 0%から100%の間か、ダッシュボードの数字と合うか
- 成長率: 月次で50%を超える伸びが現実的か、データの問題ではないか
- 平均: 分布を考えて妥当な値か
- 構成比: セグメントごとの割合が合計でおよそ100%になるか
他ソースとの照合は5手法
- 同じ指標を2通りの方法で計算し、一致を確かめる
- 個別のレコードをいくつか選び、データを手で追う
- 公開済みのダッシュボードや経理の報告、過去の分析と見比べる
- 逆算する。総売上がXなら、ユーザー当たり売上×ユーザー数がおよそXになるかを見る
- 1日、1ユーザー、1カテゴリーまで絞って、そのミクロな結果が妥当かを見る
赤信号は5つ
- 明確な理由なく期間比で50%を超えて動いた指標
- 丸い数字になっている件数や合計(フィルタか既定値の問題を示す)
- ちょうど0%または100%の比率(データが途中で切れている可能性)
- 仮説を完璧に裏づける結果
- 期間やセグメントをまたいで同じ値が並ぶ(クエリが次元を無視している)
4つ目は、数値のエラーでなく心理の話です。「うまくいきすぎている」こと自体を疑う項目が、数値チェックと並んで挙がっています。
判定の3段階と出力の形
最後の判定は3段階です。
| 判定 | 意味 |
|---|---|
| 共有してよい | 意味方法論に問題がなく、計算も検証済みで、注意点が記されている |
| 注意点つきで共有 | 意味概ね正しいが、伝えるべき制約や前提がある。必要な注意点を列挙する |
| 修正が必要 | 意味具体的な誤りや方法論の問題がある。優先度順に修正点を挙げる |
SKILL.mdの本文は手順8で「Share with noted caveats」、出力形式の見本では「Share with caveats」と、わずかに表記が違います。判定を機械的に取り込む運用を組む場合は、どちらの表記が出ても拾える作りにしておきます。
出力の見本は、全体評価、方法論レビュー、重大度つきの問題リスト、計算の抜き取り結果、可視化レビュー、改善案、利害関係者に伝える注意点の順です。READMEには、分母から試用ユーザーが外れていて転換率が約5ポイント高く出る恐れがある、という指摘が例示されています。あくまで例示で、実際の出力ではありません。
実際の使いどころ: 渡す材料を決める
点検の質は、渡す材料で決まります。SKILL.mdの手順から逆算すると、次の4点を一緒に渡すのが効率的です。
- 結論の文章または資料(何を主張しているか)
- 使ったSQLか、集計の手順
- 元データの概要(表名、期間、取得日)
- 疑っている点(例: 期間の長さが違う、除外条件を後から足した)
依頼文の例を示します。以下はSKILL.mdの使用例を元にした書き方で、出力ではなく依頼の書き方です。
/validate-data 添付の週次解約率レポートを経営会議前に点検して。
SQLは query.sql、集計期間は10/1〜10/21の3週間、比較対象は9月の4週間。
解約の定義は先月から変えた(休眠90日→60日)。特に分母と期間の揃い方を見て。この依頼で、分母の変更(denominator shifting)と期間の不完全な比較の2つが、点検の最初の対象になります。変更履歴を書いておく効果は、分母の定義が変わったことを、点検の前提として明示できることです。
点検前に自分で済ませるとよいこと
- 元ファイルの行数と合計値を控える。点検結果と突き合わせる基準になります
- 「内部アカウントを除外したか」など、業務上の定義を一文で書く
- 点検結果は元の分析と一緒に残す。SKILL.mdも、検証の出力を分析と並べて共有すると利害関係者の信頼が高まると書いています
ほかのスキルとの切り分け
dataプラグインには、前後工程のスキルがあります。READMEの表では、分析の質問に答える/analyze、データの形を調べる/explore-data、SQLを書く/write-query、グラフを作る/create-viz、ダッシュボードを作る/build-dashboardが並びます。流れとしては、作る側のスキルで出した結果をvalidate-dataに渡す形です。
自分の組織の用語や指標定義をClaudeに覚えさせたいときは、同じプラグインのdata-context-extractorが受け持ちます。点検の前に指標定義を渡しておくほど、「定義が揃っているか」の確認が具体的になります。
Excelの集計を任せて検算するならCoworkのExcel・スプレッドシート分析、チャット添付のCSVだけで済ませるならClaudeのCSV分析が近い使い方です。
限界と、うまく機能しない場面
SKILL.mdやREADMEの記述から読み取れる範囲で、使う前に押さえておくとよい点です。
- 点検は、渡された材料の範囲で行われます。データウェアハウスの接続がなければ、元の表を自分で調べにいくことはできません。dataプラグインのREADMEは、接続なしの場合はSQLの結果を貼るか、CSVやExcelをアップロードする使い方を挙げています
- コネクタの表(CONNECTORS.md)では、SnowflakeとDatabricksは「プレースホルダ — MCPのURLは未設定」と注記されています。「未設定」の注がないのはBigQueryとDefiniteです。ノートブックのHexを例に、接続を揃える手順はHexコネクタの接続手順が参考になります
- 判定は3段階の「確信度」です。SKILL.mdに、判定に使う閾値の数値や機械的な合否基準は書かれていません。同じ分析を2回通したときの判定の一致は保証されません
- 「元のSQLをDBに流し直して照合する」といった実行は、手順に明記されていません。実行の可否は接続しているMCPサーバーと権限に依存します
運用に組み込む小さな型
使い続けるときは、分析の保存ルールに点検を入れると回りやすくなります。SKILL.mdには、再実行可能な分析の記録として、問い、データソース(取得日つき)、定義、方法、前提と限界、主な発見、SQL、注意点の8項目のひな形が載っています。点検用の依頼文と、このひな形を同じファイルにまとめておけば、誰が点検しても同じ観点で読めます。
コード側では、docstringに作成者、日付、データソース、前回の検証日、目的、前提、出力を残す形が示されています。「最後に検証した日 — 結果がダッシュボードと2%以内で一致」のような一行が、次回の見直しの起点になります。
よくある質問
点検にかかる時間はどれくらいですか
SKILL.mdのTipsは「1分で済み、信用を守れることもある」と書くだけで、時間の保証はありません。重要な発表や意思決定の前に通すこと、問題が出たら直して再点検することが挙げられています。
日本語の資料でも点検できますか
SKILL.mdは英語で書かれていますが、点検対象の言語に制限は書かれていません。出力の言語は依頼文で指定すると揃えやすくなります。出力のラベル(High/Medium/Low、判定名)を日本語に置き換えたい場合は、依頼文に対応表を添えます。
まとめ
validate-dataは、分析の「作り手」と「共有先」の間に点検を挟むスキルです。8手順、4群22項目のチェックリスト、7つの落とし穴、3段階の判定が1つにまとまっています。
効き方は、渡す材料で変わります。結論の文章だけでなく、SQL、期間、定義の変更点を一緒に渡し、疑っている点を先に書く。その上で、重要な数字は他のソースとの照合を人が行う。この2点を守ると、共有前の見落としを減らす道具として使えます。