集計方針の設計・SQL生成・可視化の選択・結果の解釈など、分析の各段階で使える指示文。ChatGPT・Claude・Gemini にそのまま貼り付けて使えます。全文公開・登録不要で、 コピーボタンから1クリックで持ち出せます。
[サービス・想定アナリスト数]に応じたイベント命名規則を設計してください。 ・命名形式（object_action / past tense / 意味的階層） ・必須プロパティ（user_id / session_id / source / version） ・PII の扱い（ハッシュ化／除外） ・互換性破壊時の versioning ・廃止フロー（deprecated タグ／sunset 期間） ・ドキュメンテーションの場所と更新責任 スキーマレジストリ／Tracking Plan ツールの選定基準も。
[扱う主要データセット]に対する品質監査チェックリスト 25 項目： ・完全性（NULL 比率／ 必須フィールドの欠損） ・一貫性（値の表記揺れ／enum 逸脱） ・精度（外部マスタとの突合） ・時系列（重複／抜け／タイムスタンプ整合） ・参照整合性 ・新鮮さ（SLA / フレッシュネス） ・ボリューム異常検知 ・スキーマ変更の追跡 各項目の自動化レベル（手動／週次／継続監視）と、検知時のオンコール責務分担。
[現状運用しているファネル]の定義書を作成してください。 ・各ステップの SQL 上の定義 ・対象（新規 / 全体 / 課金） ・タイムウィンドウ（同一セッション／7 日 等） ・除外条件（社員／テスト／ボット） ・関連する既存ファネルとの差分 ・命名規則（命名衝突を避ける） ・更新責任者 「同じ名前で違う計算」の社内事故を防ぐ運用ルールも併記。
次の dbt モデル群 [貼付] を以下で診断： ・staging → intermediate → marts の責務分担 ・テスト（not_null / unique / relationships）の網羅 ・命名規則（stg_ / int_ / fct_ / dim_） ・パフォーマンス（incremental / materialized の選択） ・ジンジャマクロの濫用 ・依存関係の循環 ・ドキュメント完成度 リファクタの優先度付き 10 件と、PR 分割案。
[組織の主要ダッシュボード読者（経営／部長／現場）]に対する設計指針： ・各ペルソナが知りたい質問 ・更新頻度の期待値 ・誤読しやすい指標 ・ドリルダウンの深さ ・代替表現（テーブル） ・通知／アラートの粒度 ・読まれない指標の整理サイクル 「全員向け 1 枚」の罠を避ける構造論。
[伝えたい主張・データ性質（カテゴリ／時系列／分布／関係）]からチャートを選ぶための意思決定木を作成してください。 ・棒／線／散布／ヒート／箱ひげ／ヴァイオリン／サンキー の選定基準 ・モバイル可読性 ・色覚多様性 ・読み手のリテラシー水準 ・代替表現の併記要否 ・避けるべきチャート（3D 円グラフ等） 主張ごとの『推奨／代替／NG』のテーブル化。
[組織で議論になっている指標（例：MAU / 解約率 / NPS）]について、関係部門の合意形成プロセス： ・現状の差異マッピング（誰がどう計算しているか） ・正準定義の起草 ・移行期間の運用 ・命名衝突の解消 ・ダッシュボードの更新計画 ・新人教育用の用語集 『誰の数字が正しいか』の不毛な議論を終わらせる進め方。
<context> - テーブルスキーマ：[users(id, signed_up_at, ...) / events(user_id, event_name, occurred_at)] - 「アクティブ」の定義：[例: 任意のイベントを 1 回以上 / 特定機能を使用] - 対象 DB：[BigQuery / Snowflake / Postgres] - データ規模：[users 件数 / events 件数 / 期間] </context> <task> N 週コホート × M 週後リテンション率を返す SQL を書く。可視化ツール（Looker / Tableau）に渡す前提の縦持ち（long format）で。 </task> <output_format> 1. SQL（コメント付き） - users と events を結合 - signed_up_at から週コホートを生成 - 各週後のアクティブ率を計算 - ウィンドウ関数の使用方針 2. 出力カラム: cohort_week / weeks_since_signup / cohort_size / active_users / retention_rate 3. 注意点 - タイムゾーン統一（DATE_TRUNC + AT TIME ZONE） - ボット／社員の除外（is_internal フラグ or domain @company） - グレース期間（最後のコホートは未確定なので除外） - 実行計画への配慮（パーティション or サンプリング） 4. ピボット責務：BI ツール側でやる前提（SQL は縦持ち） </output_format> <example> <input> BigQuery、users 500 万、events 50 億行、過去 12 週で「session_started を週 1 回以上」をアクティブ </input> <output> WITH cohort AS ( SELECT id AS user_id, DATE_TRUNC(DATE(signed_up_at, 'Asia/Tokyo'), WEEK(MONDAY)) AS cohort_week FROM users WHERE NOT is_internal ), activity AS ( SELECT user_id, DATE_TRUNC(DATE(occurred_at, 'Asia/Tokyo'), WEEK(MONDAY)) AS active_week FROM events WHERE event_name = 'session_started' GROUP BY 1, 2 ) SELECT c.cohort_week, DATE_DIFF(a.active_week, c.cohort_week, WEEK) AS weeks_since_signup, COUNT(DISTINCT a.user_id) AS active_users, (SELECT COUNT(*) FROM cohort WHERE cohort_week = c.cohort_week) AS cohort_size, ... FROM cohort c LEFT JOIN activity a USING(user_id) WHERE c.cohort_week >= DATE_SUB(CURRENT_DATE(), INTERVAL 13 WEEK) GROUP BY 1, 2 ORDER BY 1, 2; 注意: events はパーティション列（occurred_at）でフィルタ必須、未満コホートは除外 </output> </example>
<context> - ベースライン主要指標：[例: CV 率 5%] - 想定 MDE（最小検出効果量）：[例: 相対 5% 改善] - 有意水準 α：[例: 0.05]、検出力 1-β：[例: 0.8] - トラフィック量：[1 日あたり対象ユーザー数] - 副指標と相関：[テストでガードレールにしたい指標群] </context> <task> 正しいサンプルサイズと所要日数を計算し、実務的な落とし穴も明記する。 </task> <output_format> 1. サンプルサイズ計算式の選択（比率の差 vs 平均の差）と片側／両側 2. 必要 N と所要日数（営業日 / 暦日） 3. 週次変動・季節性の補正（最低 2 週間ルール） 4. SRM（Sample Ratio Mismatch）チェック手順 5. 複数指標の補正（Bonferroni / Holm / FDR） 6. 覗き見問題と Sequential Testing（mSPRT 等）の選択 7. 初期バーンインの除外（初日や告知直後） 8. 「サンプル不足のまま判定」の典型 5 落とし穴 </output_format> <example> <input> ベース CV 5%、MDE +5% 相対（→絶対 0.25pt）、α=0.05 両側、検出力 0.8、対象 5,000/日（50/50 分割） </input> <output> 1. 比率の差、両側 2. n ≈ 60,500/群（標準近似）。両群合計 121,000 → 121,000 ÷ 5,000 ≈ 25 日 3. 25 日は 3 週間 + 4 日。最低 2 週間 + 月次パターンを跨ぐので OK 4. SRM: ピアソン χ² で p < 0.001 なら設定不備を疑う 5. 主要 1 + 副 4 指標 → Bonferroni で α 補正 = 0.01 6. mSPRT: 早期判定したいが副指標で過剰検出するため、主要のみ Sequential 7. バーンイン: Day1 のみ除外（社内告知でバズる） 8. 落とし穴: ① n が 1/3 で打ち切り ② SRM 無視 ③ 季節跨がず ④ 副指標を主要扱い ⑤ 効果量を絶対と相対で混同 </output> </example>
<context> [観察データから推定したい因果関係：X が Y に与える影響／前提となるドメイン知識] </context> <task> 論理的飛躍を視覚化しながら因果モデルを設計し、想像による交絡因子の羅列を防ぐ。 </task> <output_format> 1. **DAG（有向非巡回グラフ）を Mermaid 記法で出力** - X → Y の主因果と、考えうる第三変数（C1, C2, ...）の関係を矢印で - 観測可能変数と観測不能変数を区別 2. **バックドアパスの列挙**（X と Y に共通する祖先：既知 / 未知 / 観測不能） 3. **バイアスのリスク評価**（選択バイアス／合流点バイアス／逆因果） 4. **統制変数の指定**（必ず統制すべき変数 vs 統制してはいけない変数：媒介・コライダー） 5. **因果効果の識別可能性**（観察データで識別可 or 操作変数・差分の差分が必要） </output_format> <constraints> もっともらしいが業務的に的外れな変数は排除し、ドメイン知識に裏付けられた変数のみ採用。識別不能なら『識別不能』と明示。 </constraints> <example> <input> X = ネットワーク広告クリック、Y = 売上。ドメイン知識：過去のキャンペーン期間に広告も売上も季節要因（年末商戦）で同時上昇したことがある。 </input> <output> DAG (Mermaid): graph TD Season[年末商戦] --> Ad[広告クリック] Season --> Sales[売上] Ad --> Sales Competitor[競合キャンペーン] --> Sales バックドアパス: Season → Ad → Sales（既知交絡）／Competitor が Ad を介さず Sales に流入 統制すべき: Season（年末商戦フラグ）、Competitor 出稿量 統制してはいけない: ページビュー数（Ad → Sales の媒介変数。コントロールすると効果が消える） 識別可能性: Season を観測できれば Backdoor Adjustment で識別可。Competitor が観測不能なら操作変数（地域別広告配信差）が必要。 </output> </example>
<context> [業務ドメイン / 主要な分析クエリ / 既存ソースデータ / DWH 基盤（BigQuery / Snowflake / Redshift）] </context> <task> スタースキーマを設計し、dbt / Dataform への落とし方まで提示する。「とりあえず正規化」「とりあえず非正規化」を避ける。 </task> <output_format> 1. Fact テーブルの選定（イベント粒度 / 加算可能性 additive / 半加算） 2. Dimension テーブル（SCD Type 1/2/3 の選択と理由） 3. Conformed Dimensions（部門間で共通化する Dim） 4. Surrogate Key 運用と Natural Key の保持 5. 履歴保持と現時点ビュー（dim_*_current vs dim_*_history） 6. パフォーマンス（パーティション / クラスタリング / マテビュー） 7. 命名規則（fact_ / dim_ / stg_ / int_） 8. 破壊的変更の運用（rename / drop / soft delete） 9. dbt / Dataform への落とし方（staging → marts の分離） </output_format> <example> <input> B2B SaaS、BigQuery、注文データを分析したい。顧客住所が時々変わる、主な分析は月次売上 × 業界 × プラン。 </input> <output> 1. fact_orders（粒度: order_line_item、加算可能 amount / quantity） 2. dim_customer SCD Type 2（住所変更を時系列保持、effective_from/to）、dim_plan SCD Type 1（履歴不要）、dim_industry SCD Type 1 3. Conformed: dim_date / dim_customer は他部門でも共通利用 4. Surrogate Key: bigint シーケンス、Natural Key（customer_external_id）も保持 5. dim_customer_current（最新ビュー）と dim_customer（履歴含む） 6. fact_orders を order_date でパーティション、customer_id でクラスタ 7. 命名: stg_/int_/fact_/dim_、月次マート mart_monthly_revenue 8. 破壊的: rename は 30 日両立、drop は不要列のみ、soft delete でフラグ 9. dbt: staging で source 取り込み → intermediate でビジネスロジック → marts で fact/dim、各テストに not_null/unique/relationships </output> </example>
<context> [監視対象 KPI と現状の変動幅 / 既存アラート基盤（Datadog / Grafana / Looker Alert）/ 受信オンコール体制] </context> <task> 誤検知でオンコールを疲弊させないアノマリ検知を設計する。「3σ で固定」のような単純ルールに逃げない。 </task> <output_format> 1. 季節性／トレンドの分解（STL / Prophet / 移動平均） 2. しきい値ルール vs 統計モデルの選択（KPI 毎） 3. 偽陽性率の許容（業務影響度別） 4. 通知チャネルとエスカレーション（Slack INFO / PagerDuty CRITICAL） 5. 原因切り分けランブック（即時 / 1 時間 / 翌日対応の分岐） 6. 本物の異常 vs 計測異常（パイプライン詰まり等）の区別 7. 最初の 30 日のルール学習運用（ベースライン獲得） 8. KPI ごとの推奨設定例（CV / レイテンシ / エラー率） </output_format> <example> <input> B2C EC、注文数 / レイテンシ / エラー率 を監視。Datadog 既存。週末セールあり、深夜でも受発注あり。 </input> <output> 1. 注文数: STL で週次・日次季節性除去、Prophet で 1 ヶ月先まで予測。レイテンシ: 移動平均 + 3σ。エラー率: しきい値固定 0.5% で十分 2. 注文数: 統計モデル / レイテンシ: 統計 / エラー率: ルール 3. 偽陽性 < 5%（注文数）/ < 1%（レイテンシ・エラー率） 4. Slack INFO（注文数 -10%）/ PagerDuty CRITICAL（エラー率 > 1%）/ オンコール深夜禁止帯あり 5. ランブック: エラー急増 → CDN 確認 → DB 確認 → 直近デプロイ rollback / レイテンシ → DB Slow Log 6. 計測異常識別: ETL 遅延でゼロが続く時は metric_paused フラグ立て、自動的にアラート抑制 7. Day1-30 はベースライン取得のみ（通知抑制）、Day31 から本番アラート、Week 4 で閾値調整 8. CV 率: Prophet + 14 日窓 / レイテンシ: 移動平均 30 分 / エラー率: 5 分 0.5% 固定 </output> </example>
<context> - データセットの種類と取得経路：[例：自社プロダクトのイベントログ / 外部API / 手動入力] - 分析目的：[例：解約予測モデル学習用 / 経営報告KPI算出 / 異常検知] - 列ごとの分布の偏り：[ヒストグラム概要・歪度・サンプル件数] - ビジネス制約：[例：法的にゼロは許されない / 高額顧客は外れ値でも除外不可 / 欠損理由が業務上意味を持つ] - 下流：[線形モデル / 木系 / 単純集計 / 可視化] </context> <task> 教科書的な「平均値補完／中央値補完／削除」を返さず、ビジネス文脈に沿った前処理方針を設計する。情報不足で判断できない列は『情報不足のため判断保留』と明記する。 </task> <output_format> 1. 各列の欠損メカニズム判定（MCAR / MAR / MNAR）と根拠 2. 外れ値検出手法の選択（IQR / Z / 業務閾値 / DBSCAN）と、なぜそれか 3. 各列の処理方針：除外 / 補正（具体的手法）/ 残置 / フラグ付き保持 4. 下流モデル／集計への波及効果（例：木系なら欠損をそのまま使える） 5. 「きれいすぎるデータ」の警戒シグナル（過度に均一・限定的な分布） 6. ドキュメント化フォーマット：閾値・手法・判断根拠を残す表 </output_format> <constraints> ビジネス制約に反する処理は提案しないこと。 </constraints> <example> <input> - 解約予測モデル学習用 / 自社イベントログ / 列：last_login_days_ago - 分布: 0〜30日に集中、30%は NULL（未ログイン継続中）、最大値 9999（システム初期値） - 制約: NULL は『退会してない継続未ログインユーザー』、9999 はシステム由来で意味なし </input> <output> 1. 欠損メカニズム: MAR（特定セグメントに偏る、休眠ユーザー） 2. 外れ値検出: 業務閾値 9999 を NULL に再ラベル（IQR では拾えない） 3. 処理方針: - 9999 → NULL に正規化 - NULL → 「days_since_signup」（在籍日数）でフラグ付き保持。木系モデルなのでそのまま渡す - is_active_login（True/False）の派生列を追加 4. 下流影響: XGBoost なら欠損ハンドリング不要。線形に渡す場合は別途補完が必要 5. 警戒シグナル: ログイン日 0〜1 日に山が立っているのはボット混入の可能性 6. ドキュメント: 閾値 9999 の出所は schema migration 2023-XX、再評価日は 2026-Q3 </output> </example>
<context> [パイプライン全体構成 / 下流の利用者（経営 / 現場 / API 連携）/ 既存基盤 / 過去のインシデント傾向] </context> <task> オンコールの疲弊を避ける現実的な SLA / SLO を設計する。理想を語って守れない目標を立てない。 </task> <output_format> 1. 新鮮さ（Freshness）／完全性／正確性 の各 SLO 候補 2. 各層（取り込み / 変換 / 配信）の目標値 3. 利用者ごとの優先度（経営報告 99.9% / 内部分析 99.0% など） 4. アラートのしきい値とエスカレーション（INFO / WARN / CRITICAL） 5. 違反時のコミュニケーション（誰に / どの粒度で） 6. 運用コストとのバランス（達成のためのコスト試算） 7. 四半期レビューでの再校正手順 8. SLA（外部約束）と SLO（内部目標）の差分 </output_format>
<context> [配信したいデータセット / 想定利用者 / 既存テーブル / 組織のデータ成熟度] </context> <task> データセットを「データプロダクト」として設計する。テーブルを作って終わり、を避ける。 </task> <output_format> 1. 利用者ペルソナとユースケース（誰がどう使うか） 2. データプロダクトの契約（スキーマ / SLA / 例示クエリ） 3. 所有者と SRE 的責任（オンコール） 4. 課金／配賦の設計（社内チャージバック） 5. 廃止戦略（deprecate → 通知 → 削除のサイクル） 6. プロダクト的なディスカバビリティ（カタログ・README） 7. 互換性破壊時の通知プロトコル 8. dbt / Data Mesh の適用可否 9. メトリクス（採用率 / 満足度 / 利用クエリ数） </output_format>