validate-data

/validate-data - 共有前の分析検証

見慣れないプレースホルダーが表示された場合や、接続されているツールを確認する必要がある場合は、CONNECTORS.md をご覧ください。

ステークホルダーと共有する前に、分析の正確性、手法、潜在的なバイアスを確認します。信頼度の評価と改善案を作成します。

使用方法

/validate-data <analysis to review>

分析には、次のようなものがあります。

• 会話内の文書またはレポート
• ファイル（Markdown、ノートブック、スプレッドシート）
• SQL クエリとその結果
• グラフとその基礎データ
• 手法と調査結果の説明

ワークフロー

1. 手法と前提条件を確認する

次の項目を検証します。

• 問いの設定：分析は適切な問いに答えていますか？ 問いは別の意味にも解釈できますか？
• データの選定：適切なテーブル／データセットが使われていますか？ 期間は適切ですか？
• 母集団の定義：分析対象の母集団は正しく定義されていますか？ 意図しない除外はありませんか？
• 指標の定義：指標は明確かつ一貫して定義されていますか？ ステークホルダーの理解と一致していますか？
• ベースラインと比較：比較は公平ですか？ 期間、コホートの規模、状況は比較可能ですか？

2. 提出前の QA チェックリストを実施する

以下のチェックリストに沿って、データ品質、計算、妥当性、表示を確認します。

3. よくある分析上の落とし穴を確認する

以下の詳細な落とし穴の一覧（結合による行数の爆発、生存者バイアス、不完全な期間比較、分母の変動、平均の平均、タイムゾーンの不一致、選択バイアス）を体系的に確認します。

4. 計算と集計を検証する

可能な範囲で、次の項目を抜き取り確認します。

• 主要な数値をいくつか独立して再計算する
• 小計の合計が総計と一致することを確認する
• 想定される箇所では、割合の合計が 100％（またはそれに近い値）になることを確認する
• 前年比／前月比の比較で正しい基準期間が使われていることを確認する
• すべての指標にフィルターが一貫して適用されていることを検証する

以下の結果の妥当性確認手法（規模の確認、相互検証、危険信号の検出）を適用します。

5. 可視化を評価する

分析にグラフが含まれている場合は、次の項目を確認します。

• 軸の開始値は適切ですか（棒グラフではゼロですか）？
• 比較用のグラフ間で縮尺は統一されていますか？
• グラフのタイトルは表示内容を正確に表していますか？
• ざっと見た読者に誤解を与える可能性はありませんか？
• 知覚をゆがめる、途中で切れた軸、不統一な間隔、3D 効果はありませんか？

6. 説明と結論を評価する

次の点を確認します。

• 結論は提示されたデータによって裏付けられていますか？
• 別の説明の可能性にも触れていますか？
• 不確実性は適切に伝えられていますか？
• 推奨事項は調査結果から論理的に導かれていますか？
• 信頼度は証拠の強さに見合っていますか？

7. 改善案を提案する

具体的で実行可能な提案を提示します。

• 結論を補強する追加分析
• 明記すべき注意事項や制約
• 重要なポイントに適した、より良い可視化や説明の仕方
• ステークホルダーが必要とする不足している背景情報

8. 信頼度の評価を作成する

分析を 3 段階で評価します。

共有可能 — 手法は妥当で、計算は検証済みであり、注意事項も明記されています。改善の提案は軽微で、共有を妨げるものはありません。

注意事項を明記して共有 — 分析は概ね正確ですが、ステークホルダーに伝えるべき具体的な制約や前提条件があります。必要な注意事項を列挙してください。

修正が必要 — 共有前に対処すべき具体的な誤り、手法上の問題、または不足している分析が見つかりました。必要な修正を優先順位順に列挙してください。

出力形式

## Validation Report

### Overall Assessment: [Ready to share | Share with caveats | Needs revision]

### Methodology Review
[Findings about approach, data selection, definitions]

### Issues Found
1. [Severity: High/Medium/Low] [Issue description and impact]
2. ...

### Calculation Spot-Checks
- [Metric]: [Verified / Discrepancy found]
- ...

### Visualization Review
[Any issues with charts or visual presentation]

### Suggested Improvements
1. [Improvement and why it matters]
2. ...

### Required Caveats for Stakeholders
- [Caveat that must be communicated]
- ...

---

提出前の QA チェックリスト

ステークホルダーと分析を共有する前に、このチェックリストを確認してください。

データ品質チェックリスト

• データソースの確認：使用したテーブル／データソースを確認しました。この質問に適したものですか？
• 鮮度：分析に十分な最新データです。「基準日」を記録しました。
• 完全性：時系列に予期しない空白や、欠落した区間はありません。
• NULL の処理：主要な列の NULL 率を確認しました。NULL は適切に処理されています（除外、補完、またはフラグ付け）。
• 重複排除：不適切な結合やソースレコードの重複による二重計上がないことを確認しました。
• フィルターの確認：すべての WHERE 句とフィルターは正しく設定されています。意図しない除外はありません。

計算チェック

• 集計ロジック：GROUP BY に集計対象外の列がすべて含まれています。集計レベルは分析の粒度と一致しています。
• 分母の正確性：比率やパーセンテージの計算には正しい分母を使用しています。分母はゼロではありません。
• 日付の整合性：比較対象の期間の長さは同じです。不完全な期間は除外するか、注記しています。
• 結合の正確性：JOIN の種類（INNER と LEFT）は適切です。多対多結合によって件数が水増しされていません。
• 指標の定義：指標はステークホルダーの定義と一致しています。相違点があれば注記しています。
• 小計の合計：想定される範囲で、各部分の合計が全体と一致しています。一致しない場合は、その理由（重複など）を説明しています。

妥当性チェック

• 数値の規模：数値は妥当な範囲内です。売上がマイナスになっていません。パーセンテージは 0～100％の範囲内です。
• 傾向の連続性：時系列に説明のつかない急増や急減はありません。
• 相互参照：主要な数値は、既知の他のデータソース（ダッシュボード、過去のレポート、財務データ）と一致しています。
• 桁の妥当性：総売上は妥当な範囲です。ユーザー数は既知の数値と一致しています。
• 境界事例：境界ではどのようになりますか？空のセグメント、活動のない期間、新しいエンティティを確認します。

プレゼンテーションのチェック

• グラフの正確性：棒グラフの軸はゼロから始まっています。軸にはラベルが付いています。パネル間で縮尺は統一されています。
• 数値の書式：精度は適切です。通貨とパーセンテージの書式は統一されています。必要に応じて桁区切りを使用しています。
• タイトルの明確さ：タイトルには指標だけでなく、得られた知見が示されています。日付範囲が明記されています。
• 注意事項の明示：既知の制約と前提を明確に記載しています。
• 再現性：提供されたドキュメントをもとに、他の人がこの分析を再現できます。

データ分析でよくある落とし穴

結合による行数の爆発的増加

問題：多対多結合によって行数が気付かないうちに増え、件数や合計が水増しされます。

検出方法：

-- Check row count before and after join
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 (uh oh)

防止方法：

• 結合後は必ず行数を確認します
• 件数が増加した場合は、結合の関係（本当に 1 対 1 または 1 対多なのか）を調査します
• 結合を通じてエンティティ数を数える場合は、COUNT(*) ではなく COUNT(DISTINCT a.id) を使用します

生存者バイアス

問題：現在存在するエンティティのみを分析し、削除されたエンティティ、解約したエンティティ、失敗したエンティティを無視します。

例：

• 「現在のユーザー」の行動を分析すると、解約したユーザーが抜け落ちます
• 「自社の製品を利用している企業」に注目すると、評価した後に利用をやめた企業が無視されます
• 「成功した」結果の特性を調べる際、「失敗した」結果を対象から除外します

防止方法：結論を出す前に「このデータセットに含まれていないのは誰か？」と問いかけます。

不完全な期間の比較

問題：一部しか経過していない期間と、全期間を比較します。

例：

• 「1 月の売上は 50 万ドルで、12 月の 80 万ドルを下回っています」――ただし、1 月はまだ終わっていません
• 「今週の登録数は減少しています」――水曜日に確認し、前週全体と比較しています

防止方法：必ず完了した期間に絞るか、同じ日付同士または同じ日数同士を比較します。

分母のシフト

問題点：期間によって分母が変わるため、率を比較できなくなります。

例：

• 「対象」とするユーザーの数え方を変更したことで、コンバージョン率が改善する
• 「アクティブ」の定義が更新されたことで、解約率が変化する

防止方法：比較するすべての期間で、一貫した定義を使用してください。定義を変更した場合は記録してください。

平均値の平均

問題点：グループの規模が異なる場合、事前に計算された平均値の平均を取ると、誤った結果になります。

例：

• グループ A：ユーザー 100 人、平均収益 $50
• グループ B：ユーザー 10 人、平均収益 $200
• 誤り：平均値の平均 = ($50 + $200) / 2 = $125
• 正解：加重平均 = (100*$50 + 10*$200) / 110 = $63.64

防止方法：必ず生データから集計してください。事前に集計された平均値の平均を取らないでください。

タイムゾーンの不一致

問題点：データソースごとにタイムゾーンが異なるため、データの位置がずれます。

例：

• イベントのタイムスタンプは UTC で、ユーザー向けの日付は現地時間で記録されている
• 日次の集計で、異なる締め切り時刻が使用されている

防止方法：分析前に、すべてのタイムスタンプを単一のタイムゾーン（UTC を推奨）に統一してください。使用したタイムゾーンを記録してください。

セグメンテーションにおける選択バイアス

問題点：測定対象の結果に基づいてセグメントを定義すると、循環論法になります。

例：

• 「オンボーディングを完了したユーザーは定着率が高い」――当然ながら、自ら選択した結果です
• 「パワーユーザーはより多くの収益を生み出す」――収益を生み出すことでパワーユーザーになったのです

防止方法：結果ではなく、処置前の特性に基づいてセグメントを定義してください。

その他の統計上の落とし穴

• シンプソンのパラドックス：データを集計した場合とセグメント化した場合で、傾向が逆転する
• 裏付けとなる証拠なしに、相関を因果関係として提示する
• サンプルサイズが小さく、結論の信頼性が低くなる
• 外れ値が平均値に過度な影響を与える（代わりに中央値を使うべきでしょうか？）
• 有意な結果の多重検定／都合のよい結果の選別
• 先読みバイアス：過去の出来事を説明するために、未来の情報を使用する
• 特定の見方に都合のよい期間の選別

結果の妥当性チェック

桁数のチェック

分析における重要な数値について、「違和感がないか」を確認してください。

指標の種類	妥当性チェック
ユーザー数	既知の MAU/DAU の数値と一致していますか？
収益	既知の ARR と比べて、妥当な桁数ですか？
コンバージョン率	0% から 100% の範囲内ですか？ダッシュボードの数値と一致していますか？
成長率	前月比 50% 以上の成長は現実的ですか？それともデータに問題がありますか？
平均値	分布について把握している内容を踏まえて、妥当な平均値ですか？
割合	セグメントの割合の合計は約 100% ですか？

相互検証の手法

1. 同じ指標を異なる 2 つの方法で計算し、一致することを確認する
2. 個々のレコードを抜き取り確認する――具体的なエンティティをいくつか選び、データを手作業で追跡する
3. 既知のベンチマークと比較する――公開済みのダッシュボード、財務レポート、または過去の分析と照合する
4. 逆算する――総収益が X の場合、ユーザーあたりの収益にユーザー数を掛けた値は、おおよそ X と等しくなりますか？
5. 境界値をチェックする――1 日、1 人のユーザー、または 1 つのカテゴリに絞り込むとどうなりますか？そのような細かな結果は妥当ですか？

調査が必要な警告サイン

• 明確な原因がないのに、期間ごとに 50% を超えて変化した指標
• ちょうど切りのよい数値になっている件数や合計値（フィルターやデフォルト値の問題を示唆します）
• ちょうど 0% または 100% の率（データが不完全な可能性があります）
• 仮説を完璧に裏付ける結果（現実はたいていもっと複雑です）
• 期間やセグメントをまたいで同じ値が続く（クエリがディメンションを無視している可能性を示唆します）

再現性のためのドキュメント作成基準

分析ドキュメントのテンプレート

重要な分析には、必ず以下を含めてください。

## Analysis: [Title]

### Question
[The specific question being answered]

### Data Sources
- Table: [schema.table_name] (as of [date])
- Table: [schema.other_table] (as of [date])
- File: [filename] (source: [where it came from])

### Definitions
- [Metric A]: [Exactly how it's calculated]
- [Segment X]: [Exactly how membership is determined]
- [Time period]: [Start date] to [end date], [timezone]

### Methodology
1. [Step 1 of the analysis approach]
2. [Step 2]
3. [Step 3]

### Assumptions and Limitations
- [Assumption 1 and why it's reasonable]
- [Limitation 1 and its potential impact on conclusions]

### Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]

### SQL Queries
[All queries used, with comments]

### Caveats
- [Things the reader should know before acting on this]

コードのドキュメント

再利用される可能性のあるコード（SQL、Python）には、以下を含めてください。

"""
Analysis: Monthly Cohort Retention
Author: [Name]
Date: [Date]
Data Source: events table, users table
Last Validated: [Date] -- results matched dashboard within 2%

Purpose:
    Calculate monthly user retention cohorts based on first activity date.

Assumptions:
    - "Active" means at least one event in the month
    - Excludes test/internal accounts (user_type != 'internal')
    - Uses UTC dates throughout

Output:
    Cohort retention matrix with cohort_month rows and months_since_signup columns.
    Values are retention rates (0-100%).
"""

分析のバージョン管理

• クエリとコードをバージョン管理（git）または共有ドキュメントシステムに保存します
• 使用したデータスナップショットの日付を記録します
• 最新のデータで分析を再実行した場合は、変更点とその理由を記録します
• 傾向を比較できるよう、定期的に実施する分析の過去のバージョンへのリンクを記載します

例

/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]

ヒント

• 重要なプレゼンテーションや意思決定の前には、必ず /validate-data を実行します
• 簡単な分析でも、妥当性チェックを行うと役立ちます。1分で済み、信頼を損なわずに済みます
• 検証で問題が見つかった場合は、修正して再検証します
• ステークホルダーの信頼を高めるため、検証結果を分析と併せて共有します