data-analysis

データ分析

このスキルを使う場面

• ユーザーがデータセット、エクスポートデータ、レポートの抜粋、クエリ結果、または整形済みのイベント／テレメトリテーブルを持っていて、根拠に基づく結論を求めている場合。
• 何が変わったのかを把握する、セグメントを比較する、パフォーマンスを要約する、または異常をビジネス上の観点から説明するタスクの場合。
• 依頼にCSV、JSON、SQL テーブル、リテンション、コホート、ファネル、コンバージョン、支出、テレメトリ、イベントエクスポート、KPIが含まれている場合。
• 結論を出す前にデータ品質チェックが必要な場合。
• ユーザーが、生のコードスニペットだけでなく、簡潔な分析の説明を必要としている場合。

次の場合は、このスキルを主なワークフローとして使用しないでください。

• コード／データのアセット全体を対象に、異常やコードパターンを繰り返しスキャンすることが主な目的の場合 → pattern-detection を使用します。
• 特定の BI ダッシュボードや Looker Studio + BigQuery のワークフローの構築／調整が主な目的の場合 → looker-studio-bigquery を使用します。
• データセットの分析ではなく、リポジトリのナビゲーションや呼び出し元の追跡がタスクの場合 → codebase-search を使用します。
• データセット分析ではなく、生ログのトリアージやインシデントの再構成が問題の場合 → log-analysis を使用します。

基本的な考え方

データ分析は、段階的な推論のワークフローです。

1. 判断に必要な問いを明確にする
2. データのプロファイルと信頼性を確認する
3. 問いに答えられる、最もコストの低い分析方法を選ぶ
4. 観察結果と解釈を切り分ける
5. 根拠、注意点、次のアクションを示して終える

チャートやコードにすぐ着手しないでください。目指すのは、意思決定に役立つ分析です。

手順

ステップ 1：分析の問いを定める

データに触れる前に、次の点を定義します。

• 判断に必要なこと — この分析によって、どのようなアクションや判断が左右されますか？
• 主要な指標 — コンバージョン、リテンション、売上、レイテンシー、チャーン、残高、支出効率など
• ディメンション／セグメント — 時間、チャネル、コホート、地域、プラン、デバイス、フィーチャーフラグ、プレイヤーセグメント
• 比較方法 — 前後比較、対照群／処置群、上位と下位のセグメント、予測値と実績値
• 期間 — 日／週／月／リリース／実験期間

依頼が曖昧な場合は、次のように言い換えます。

「[対象期間]における[対象者]向けの[指標／結果]を説明し、最も大きな要因や注意点を特定する必要があります。」

ステップ 2：分析前に信頼性を確認する

必ず最初にデータ品質のトリアージを行います。

最低限の信頼性チェックリスト

• 行数／エクスポートデータのサイズ
• スキーマとデータ型
• 欠損値／null が多い列
• 重複または繰り返し出現する ID
• 時間範囲の網羅性とタイムゾーンの前提
• セグメントの網羅性（チャネル、国、デバイス、ビルド、プレイヤーグループ）
• 明らかな結合／集計の誤り
• 外れ値やあり得ない値

デフォルトのチェックパターン：

import pandas as pd

# df = pd.read_csv(...)
print(df.shape)
print(df.dtypes)
print(df.head())
print(df.isna().sum().sort_values(ascending=False).head(15))
print(df.duplicated().sum())

信頼性が低い場合は、結論を出せると安易に約束せず、出力を次の内容に明示的に切り替えます。

• 信頼できる内容
• 疑わしい内容
• 必要な追加クリーンアップやデータ

ステップ 3：分析方法を選ぶ

方法	使用する場面	主なツール	成功の目安
スプレッドシート規模のトリアージ	小規模なエクスポートデータ、PM／運用チームへの引き継ぎ、KPI の簡易チェック	Sheets / Excel / 簡易的なテーブル確認	全体像をすばやく把握し、明らかな誤りや大きな変動を見つけられる
SQL による切り分け	データがすでに DB／データウェアハウスにある場合、またはグループ化やフィルタリングをすばやく行う必要がある場合	SQL / DuckDB / データウェアハウスのクエリ	整った集計、コホート、ファネル、比較
ノートブック／統計分析	複数の指標、コホートのロジック、実験の分析、テレメトリ、またはより高度な変換を扱う場合	pandas / ノートブック / スクリプト	再現可能な計算と、より深い解釈
関係者向けの要約	答えはほぼ明らかで、追加の切り分けではなく説明が必要な場合	markdown メモ / レポート / ダッシュボードへの引き継ぎ	明確な調査結果、注意点、アクション、未解決の疑問

問いに答えられる中で、最もコストの低い方法を選びます。必要な場合に限り、より高度な方法に切り替えます。

ステップ 4：適切な分析パターンを使う

パターン A — 変化の説明

用途：実験、リリースの影響、KPI の急増・急減、支出の変化、ゲームプレイのバランス調整。

チェックリスト：

1. ベースラインと比較期間を定義する
2. 実験またはロールアウトの比較の場合、分母と割り当ての整合性を確認する
3. 絶対差と相対差を計算する
4. 上位のセグメントまたは要因ごとに変化を分解する
5. 変化が広範囲に及ぶのか、特定の箇所に集中しているのかを検証する
6. 交絡要因（季節性、ローンチ、トラッキングの変更、サンプルサイズ、有意性・信頼性の限界）を明記する

パターン B — セグメント比較

用途：チャネルの品質、ユーザー層、デバイスの種類、地域、プレイヤーのコホート。

チェックリスト：

1. 主な指標に基づいてセグメントを順位付けする
2. サンプルサイズと分母を含める
3. 率とボリュームの両方を比較する
4. シンプソンのパラドックスのような集計上の落とし穴に注意する
5. 上位グループと下位グループを分ける要因として考えられるものを説明する

パターン C — ファネル／リテンション分析

用途：サインアップ、購入、オンボーディング、機能の採用、ライブ運営の進行。

チェックリスト：

1. 各ステージ／イベントを明確に定義する
2. ステージごとの件数とコンバージョン率／離脱率を計算する
3. 獲得元、コホート、プラットフォーム、ビルド、またはプレイヤータイプごとにセグメント化する
4. 最も改善効果の大きい離脱ポイントを特定する
5. 計測の欠落と、実際の行動上の問題を区別する

パターン D — テレメトリ／イベント分析

用途：ゲームプレイのテレメトリ、製品イベントのストリーム、運用データのエクスポート。

チェックリスト：

1. 生イベントを派生指標に対応付ける
2. セッション／ビルド／機能／セグメント／時間ごとにグループ化する
3. 急増、急減、不審なクラスターを特定する
4. 通常の変動と不審な外れ値を区別する
5. 持続的な異常の探索が主な作業になった場合は、pattern-detection に引き継ぐ

ステップ 5：観察結果と解釈を分ける

調査結果を次の 3 つの層に分けて構成します。

1. 観察結果 — データが文字どおり示していること
2. 解釈 — 考えられる意味や要因
3. 注意事項／確信度 — 結論の確かさを損なう可能性のあるもの

良い例：

• 観察結果：コンバージョンが前週比で 6.2％低下し、モバイル Safari のトラフィックに集中しています。
• 解釈：この低下は、最近のチェックアウト UI の変更が小さな画面に与えた影響に関連している可能性が高いです。
• 注意事項：同じ週に 1 つの支払い方法のトラッキングも変更されたため、原因の特定に対する確信度は中程度です。

ステップ 6：意思決定に役立つ出力を返す

デフォルトの出力形式：

## Analysis brief
- Goal: [decision question]
- Data source: [files / tables / export scope]
- Trust level: high | medium | low
- Lane used: spreadsheet triage | SQL slicing | notebook/statistical | summary-only

## Key findings
1. [finding]
2. [finding]
3. [finding]

## Supporting evidence
- [metric / segment / comparison]
- [metric / segment / comparison]

## Caveats
- [missing data / sample bias / instrumentation / seasonality]

## Recommended next actions
- [decision / follow-up slice / dashboard handoff / instrumentation fix]

ユーザーが推奨事項を求めている場合は、各推奨事項を具体的な調査結果に結び付けます。 ユーザーが分析のみを求めている場合は、根拠と注意事項を示したところで終了します。

ステップ 7：分析がボトルネックでなくなったら引き継ぐ

次のステップが別の作業になる場合は引き継ぎます。

• 異常の反復的な探索またはルールベースのスキャン → pattern-detection
• ダッシュボードの構築／BigQuery 接続レポート → looker-studio-bigquery
• データセットを整形する前の生ログのトリアージ → log-analysis
• 計測や指標の定義を見つけるためのリポジトリ／コード調査 → codebase-search

例

例 1：実験分析

プロンプト：

この CSV エクスポートを分析し、価格設定の実験後に何が変わったか教えてください。

良い回答の形式：

• ベースラインと実験期間を定義する
• データのカバレッジとセグメントの網羅性を確認する
• 全体の変化とセグメントごとの内訳を報告する
• 影響が大きいと考えられる要因と注意事項を特定する

例 2：マーケティングと製品の分析

プロンプト：

アプリのイベントログとチャネル別のマーケティング費用があります。リテンションと CAC の主な傾向を見つけてください。

良い回答の形式：

• 獲得指標とリテンション指標を分ける
• チャネル／コホートごとに率とボリュームを比較する
• 結合やアトリビューション期間が不明確な場合は、信頼性の限界を指摘する
• 影響の大きいチャネル間の違いを要約する

例 3：ゲームのテレメトリ分析

プロンプト：

このゲームプレイのテレメトリデータを確認し、バランス上の問題と疑わしい外れ値を要約してください。

望ましい回答の構成：

• イベントをゲームプレイ指標に対応付ける
• プレイヤー／ビルド／武器／レベルのセグメントを比較する
• 全体的なバランスの傾向と疑わしい外れ値を分ける
• 必要に応じて、繰り返し発生する異常の検出を pattern-detection に引き継ぐ

例 4：PM／運用チームによるエクスポートデータのトリアージ

プロンプト：

ダッシュボードを CSV にエクスポートしました。経営陣向けに KPI が低下した理由を説明するのを手伝ってください。

望ましい回答の構成：

• エクスポートデータの信頼性チェックから始める
• 指標、期間、比較対象となるベースラインを特定する
• 根拠と留意点を含む、経営陣向けの簡潔なメモを作成する

ベストプラクティス

1. グラフの種類ではなく、意思決定に関する問いから始めます。
2. 解釈の前に、必ずデータ品質を確認します。
3. セグメントを比較するときは、必ずサンプルサイズ／分母の情報を含めます。
4. 重いノートブックを既定で使うのではなく、必要十分な最小コストの方法を選びます。
5. 分析の誠実さを保つため、観察結果、解釈、留意点を分けます。
6. ダッシュボードの構築や異常検出が実際の作業になった場合は、隣接する専門スキルに引き継ぎます。

参考資料

• Project Jupyter
• Pandas 入門チュートリアル
• DuckDB Jupyter ガイド
• GA4 のレポートの共有とエクスポート

出力形式

信頼度、主な根拠、留意点、明確な次のアクションまたは引き継ぎ事項を含む、簡潔で調査結果を先に示す要約を使用します。