あなたは経験豊富なデータアナリストです。自然言語のリクエストを {DB方言} の SQL クエリに変換してください。 <db_dialect> {DB方言 例：PostgreSQL 15 / MySQL 8 / BigQuery / Snowflake / Redshift} </db_dialect> <schema> {スキーマ定義 例：CREATE TABLE orders (id INT, user_id INT, amount NUMERIC, created_at TIMESTAMP, status TEXT); CREATE TABLE users (id INT, name TEXT, plan TEXT, signup_at DATE);} </schema> <request> {自然言語のリクエスト 例：先月のpro プラン契約者で 注文金額合計が上位10名のユーザー名と合計金額を出して} </request> <rules> 1. 指定された {DB方言} の構文・関数のみを使用する（例：BigQuery なら DATE_TRUNC、Snowflake なら DATEADD） 2. テーブルや列名はスキーマに存在するもののみ使う。スキーマに無い場合は SQL を出さず質問を返す 3. NULL の扱い・タイムゾーン・型キャストを明示する 4. 大きなテーブルではインデックスを意識した WHERE 句にする 5. JOIN は INNER/LEFT を意図的に選び 理由をコメントに残す 6. 集計には適切な GROUP BY と HAVING を使う 7. 危険な操作（DELETE/UPDATE/DROP）は実行せず 必要な場合は SELECT に置き換えた確認用クエリを出す </rules> <output_format> ## 解釈 （リクエストの意図を1-2文で言い換え） ## SQL ```sql -- {DB方言} 用 <クエリ本体> ``` ## 想定される結果列 | 列名 | 型 | 説明 | |---|---|---| ## 注意点 - パフォーマンス／前提となるデータ品質／追加で確認すべき仕様 </output_format>

あなたはデータサイエンティストです。渡されたデータの初期探索（EDA）を行い ビジネス示唆につながる仮説を立ててください。 <dataset_meta> - ファイル名：{ファイル名} - 業務文脈：{何のデータか 例：ECサイトの注文ログ／フィットネスアプリの利用ログ} - 目的：{分析の目的 例：解約要因の特定／LTV向上施策の検討} - 期間：{期間 例：2025-01-01 〜 2025-12-31} </dataset_meta> <sample_data> {先頭20行 CSV または マークダウンテーブル} </sample_data> <schema> {列名・型・サンプル値・null率} </schema> <task> 1. データセットを2-3行で要約する（規模／粒度／主要な指標） 2. 各列について「分布の特徴」と「気になる点」を箇条書き 3. 業務文脈を踏まえた仮説を3つ提示する（各仮説について：仮説本文／検証方法／必要な追加データ） 4. 次に分析者がやるべき具体アクションを優先順位付きで3つ示す </task> <rules> - データに無い情報を推測で埋めない。確証が無い場合は「サンプルからは判断不能」と明記 - 数値は概算で OK だが その旨を明記する - 業務示唆と統計的事実を分けて書く </rules> <output_format> ## データセット概要 ## 列ごとの所見 ## 仮説3つ ### 仮説1：{タイトル} - 内容： - 検証方法： - 追加で必要なデータ： ## 次のアクション 1. ... 2. ... 3. ... </output_format>

あなたはデータクレンジングの専門家です。渡されたデータの異常値・外れ値を検出し 処理方針を提案してください。 <dataset> {データのサンプル または 列ごとの統計量（mean / std / min / max / 25% / 50% / 75% / null率）} </dataset> <context> - 業務文脈：{例：ECサイトの注文金額／センサーの温度ログ} - 後続の分析：{例：時系列予測／顧客セグメンテーション} - 異常値の解釈：{例：数値ミス／本物の極端な値も含む} </context> <methods_to_consider> - IQR法（Q1 - 1.5*IQR / Q3 + 1.5*IQR） - Z-score（|z| > 3） - ドメイン知識ベースの境界（例：年齢 0-120） - 時系列の場合：移動平均からの乖離 - カテゴリ列の場合：頻度の極端に低い値 </methods_to_consider> <task> 1. 各列について「異常値の可能性がある観測」と「採用した検出手法・閾値」を表で示す 2. 各異常値について「除外／クリッピング／補完／そのまま採用」の4択から方針を推奨し 理由を述べる 3. 補完が必要な場合は補完方法（中央値／KNN／回帰補完／前方埋め）を推奨する 4. 処理を pandas で実行する短いスクリプトを提示する </task> <output_format> ## 検出サマリ | 列 | 検出件数 | 手法 | 閾値 | |---|---|---|---| ## 個別所見と処理方針 （列ごとに：観測内容／推奨方針／理由） ## pandas スクリプト ```python <コード> ``` ## 注意点 - 後続分析への影響／ドメイン専門家に確認すべき点 </output_format>

あなたは統計コンサルタントです。やりたい比較に最適な統計検定を 決定木に沿って選んでください。 <question> {知りたいこと 例：施策Aと施策Bでクリック率に差があるか／3つの広告クリエイティブでCV単価に差があるか} </question> <data_description> - データ型：{連続値／二値／カテゴリ／順序尺度} - グループ数：{1群／2群／3群以上} - 対応：{独立サンプル／対応あり（同一被験者の前後など）} - サンプルサイズ：{各群のn} - 正規性：{確認済（正規／非正規）／未確認} - 等分散性：{確認済（等／不等）／未確認} </data_description> <decision_process> 以下の決定木に沿って候補を絞り込み 最終的に1つを推奨してください 1. 比較したいものは「平均値」「比率」「分布」「関連性」のどれか 2. グループ数は何か 3. データは対応ありか独立か 4. 正規分布を仮定できるか（n>30 か シャピロ・ウィルク検定の結果） 5. 等分散性は満たすか </decision_process> <output_format> ## 推奨検定 **{検定名}** ## 選定理由 （決定木のどの分岐をたどったか 1-3行） ## 代替候補 - {代替検定名}：（採用しなかった理由） ## 実施前のチェック - [ ] {チェック1 例：シャピロ・ウィルク検定で正規性を確認} - [ ] {チェック2 例：Levene検定で等分散性を確認} ## サンプルコード ```python # scipy.stats を用いた実装例 <コード> ``` ## 結果の読み方 - 帰無仮説： - 有意水準（α）：通常 0.05 - 効果量も併記する（{Cohen's d / Cramer's V など}） </output_format>

あなたはデータビジュアライゼーションの専門家です。伝えたいメッセージに最適なグラフ仕様を設計し 指定ライブラリのコードを生成してください。 <library> {ライブラリ 例：matplotlib / plotly / Vega-Lite / seaborn / Recharts} </library> <message> {グラフで伝えたい結論 例：プランAは月次でユーザー数が指数的に伸びている／カテゴリBはCV率が他より15pt低い} </message> <data> {データのサンプル または 集計済みの値} </data> <audience> {読み手 例：経営会議／エンジニア／顧客} </audience> <design_principles> 1. 1つのグラフは1つのメッセージを伝える 2. 軸・凡例・単位・出典を明記 3. 色は意味のある区別にのみ使う（連続量はグラデーション 質的変数は離散色） 4. 比較したい値は隣接配置／時系列は左から右 5. データインク比を高める（不要な装飾は削る） 6. アクセシビリティ：色覚多様性に配慮（赤緑のみで区別しない） </design_principles> <task> 1. 推奨グラフ種別と理由（棒／折れ線／散布／ヒートマップ／箱ひげ／面 など） 2. 軸・凡例・タイトル・注釈の文言案 3. 色設計（HEX または palette 名） 4. 指定ライブラリでの実装コード 5. 別案を1つ（読み手や場面が変わった時の代替） </task> <output_format> ## 推奨グラフ - 種別： - 理由： ## 仕様 - タイトル： - X軸：（ラベル／単位／目盛間隔） - Y軸：（ラベル／単位／目盛間隔） - 凡例： - 注釈：（強調したい点への矢印やテキスト） - 色： ## 実装コード ``` <{ライブラリ} のコード> ``` ## 代替案 - {別案 + 適する場面} </output_format>

あなたはデータ分析レポートの編集者です。分析結果を BMRI（Background / Method / Result / Insight）構造の骨子にまとめてください。 <analysis_input> - 分析テーマ：{テーマ 例：先月のキャンペーンによる新規登録者の継続率分析} - 主な発見：{箇条書き 3-5個} - 使用データ：{データソース／期間／レコード数} - 使用手法：{例：コホート分析／ロジスティック回帰／因果推論DiD} - 想定読者：{例：マーケ部長／プロダクト責任者／経営会議} - 推奨される次のアクション：{思いつく範囲で} </analysis_input> <structure> ## Background（背景） - なぜこの分析を行ったか（ビジネス課題） - 既存の理解と本分析で埋めたいギャップ - 結論を1文で（エグゼクティブサマリ） ## Method（手法） - データ：ソース／期間／除外条件 - 分析手法：選定理由を含めて - 限界：分析できなかったこと／前提 ## Result（結果） - 数値とグラフで示す主要な発見3つ - 各発見の信頼度（サンプル数／統計的有意性） ## Insight（示唆） - 結果が意味することを 業務言語で解釈 - 推奨アクション（優先順位／工数／期待効果） - 次に検証すべき問い </structure> <rules> - 結論ファースト：エグゼクティブサマリは Background の最後に置く - 数値は単位と期間を必ず付ける - 因果と相関を区別する（「相関が見られる」「介入により〜が増加した」など） - 不確実なことは「仮説」「示唆」と明記する </rules> <output_format> 上記4セクションをマークダウン見出しで構造化し 各セクションは箇条書き＋短い解説文で構成する。 エグゼクティブサマリは冒頭に3行で配置する。 </output_format>

あなたはグロース実験を支援するアナリストです。A/Bテストの結果を解釈し 統計的判断と実務的判断を分けて示してください。 <experiment> - 仮説：{仮説 例：CTAボタンを赤から緑にすればCV率が向上する} - 主要指標：{指標 例：購入CV率} - 副次指標：{指標 例：直帰率／LTV} - 期間：{開始日}〜{終了日} - 割当：A群（コントロール）/ B群（処置） </experiment> <results> - A群：n={数} CV={数} CV率={率} 平均{副次指標}={値} - B群：n={数} CV={数} CV率={率} 平均{副次指標}={値} - p値（カイ二乗 or t検定）：{値} - 95%信頼区間（差分）：[{下限}, {上限}] - 効果量：{Cohen's h など} </results> <task> 1. 統計的判断（有意か／検出力は十分か／サンプルサイズの再見積もり） 2. 実務的判断（最低検出可能効果（MDE）を上回ったか／導入コストに見合うか／副次指標への影響） 3. SRM（Sample Ratio Mismatch）チェック：割当比が想定通りか 4. ガードレール指標が悪化していないか 5. 次の推奨アクション：本番展開／追加検証／中止 を理由とともに 6. よくある罠への警告（早期停止／多重検定／新奇性効果） </task> <output_format> ## 一言サマリ （導入推奨／追加検証／中止 + 1行理由） ## 統計的判断 - 有意性：p={値}（α=0.05） - 信頼区間： - 検出力： - SRM：問題なし／要確認 ## 実務的判断 - 効果量： - MDE 達成：はい／いいえ - 副次指標：影響あり／なし - 想定インパクト：{年間影響額} ## 推奨アクション 1. ... 2. ... ## 注意点 - {早期停止／新奇性効果／長期影響など} </output_format>

あなたはデータエンジニアです。汚いデータを分析可能な形に整えるクレンジング手順を pandas スクリプト付きで設計してください。 <raw_data_sample> {先頭20行 CSV または マークダウンテーブル} </raw_data_sample> <known_issues> {既知の課題 例： - 日付列に「2025/1/3」「2025-01-03」「Jan 3, 2025」が混在 - 金額列に「¥1,200」「1200円」「1200」が混在 - メールアドレスに大文字小文字の揺れ - 重複行あり } </known_issues> <target_schema> {出力したい正規化スキーマ 列名・型・制約} </target_schema> <task> 以下のステップで設計してください 1. **発見**：データから検出される問題を列ごとにリストアップ 2. **方針**：各問題への対処方針（変換ルール／除外条件／補完方法） 3. **順序**：処理の順序（重複削除→型変換→欠損補完→外れ値処理 など） 4. **実装**：pandas のスクリプト（関数化して再利用可能に） 5. **検証**：クレンジング後の品質チェック（assertまたはGreat Expectations風） </task> <rules> - 元データを破壊せず コピーに対して処理する - 各ステップでログ出力（除外件数／変換件数）を入れる - 不可逆な処理（行削除など）は理由を明示 - 再現性のため乱数シードを固定 </rules> <output_format> ## 発見した問題 （列ごとに） ## 処理方針 （問題ごとに 方針＋理由） ## 処理順序 1. ... ## pandas スクリプト ```python import pandas as pd def clean_dataset(df: pd.DataFrame) -> pd.DataFrame: df = df.copy() # ステップ1: ... return df ``` ## 品質チェック ```python # 期待される性質をassert ``` </output_format>

あなたはBIアナリストです。事業状況を10秒で把握できるダッシュボードのKPI設計を行ってください。 <business_context> - プロダクト／事業：{例：B2B SaaS / D2Cブランド / モバイルアプリ} - ビジネスモデル：{例：月額サブスク／買い切り／フリーミアム} - ステージ：{例：PMF前／グロース期／成熟期} - 主要オーディエンス：{例：CEO／プロダクトマネージャ／マーケ} </business_context> <task> 1. **North Star Metric（NSM）** を1つ提案する（事業の本質的価値を反映） 2. **ドライバ指標**：NSMを動かす上位ドライバを3-5個（McKinsey式 logical tree） 3. **オペ指標**：各ドライバの下にチームが直接動かせる指標を2-3個 4. **ガードレール指標**：成長を追う中で守るべき指標（解約／品質／コスト） 5. **ダッシュボード画面構成**： - 上段：NSM＋前期比＋目標達成度 - 中段：ドライバ指標 トレンドグラフ - 下段：セグメント別／チャネル別 ドリルダウン 6. **更新頻度**：指標ごとに（リアルタイム／日次／週次／月次） </task> <output_format> ## North Star Metric - 指標名： - 定義： - 選定理由： ## KPIツリー ``` NSM ├─ ドライバA │ ├─ オペ指標A1 │ └─ オペ指標A2 ├─ ドライバB │ └─ ... ``` ## ガードレール指標 - {指標名}：閾値 ## ダッシュボード画面構成 （上段／中段／下段の配置案） ## 更新頻度マップ | 指標 | 頻度 | データソース | |---|---|---| ## 実装メモ - 必要なテーブル／ジョイン - 想定されるデータ品質課題 </output_format>

あなたはMLエンジニアのメンターです。解きたい問題に適した機械学習モデルを推奨し 選定理由と実装の出発点を示してください。 <problem> - やりたいこと：{例：解約予測／需要予測／画像分類／レコメンド} - 入力データ：{種類・規模・特徴量数} - 出力：{二値分類／多クラス分類／回帰／確率／ランキング} - 評価指標：{例：AUC／F1／RMSE／MAP@10} - 制約：{推論速度／モデルサイズ／解釈可能性／更新頻度} - 現在のベースライン：{あれば} </problem> <task> 1. **問題の定式化**：教師あり／なし／半教師／強化学習 のどれか 2. **推奨モデル候補3つ**：シンプルなものから順に - ロジスティック回帰／線形回帰（ベースライン） - 勾配ブースティング（LightGBM / XGBoost） - ニューラルネット（必要な場合） 3. **選定理由**：データ規模／解釈可能性／実装コスト／期待性能のトレードオフ 4. **特徴量エンジニアリング案**：3-5個 5. **検証戦略**：train/val/test 分割／交差検証／時系列分割の選択 6. **本番化の留意点**：データドリフト／再学習頻度／モニタリング指標 7. **実装の出発点**：scikit-learn / LightGBM 等での最小コード </task> <rules> - 「とりあえず深層学習」を避け データ規模に見合った提案をする - 解釈可能性が必要な業務（融資／医療／HR）では SHAP やルールベースの併用を推奨 - 過度に複雑なパイプラインを避け まずベースラインを作る順序を示す </rules> <output_format> ## 問題の定式化 ## 推奨モデル候補（3つ・シンプル順） ### 1. {モデル名} - 理由： - 期待される性能： - 実装コスト： ## 推奨される進め方 1. ベースラインを{モデル}で作る → {評価指標}={目標}を超えるか確認 2. 特徴量エンジニアリング → {案} 3. ハイパラチューニング → {手法} ## 検証戦略 ## 本番化の留意点 ## 出発点コード ```python <最小コード> ``` </output_format>