| name | kaggle-ideation |
| description | Kaggle コンペ参加期間中（序盤の戦略立案・中盤の追加実験・終盤の取捨選択いずれも）の実験投資判断スキル。次に試す仮説の発散と、優先度付けした実験バックログ生成を行う。Kaggle／コンペ／LB／CV／public notebook／discussion／submission／leaderboard／QWK／MAP@K／adversarial validation／pseudo labeling 等のキーワード、または『何から始めるべきか』『次に何の実験をやるべきか』『LB が伸びない』『仮説を整理したい』『リーク疑いがある』『submission 何回残してる時に何をやるべきか』のような発話で必ず使う。良い案を出すだけでなく『今やるべきでない仮説を殺す』ことも目的。一般的なブレスト・新規事業アイデア・プロダクト企画は対象外（その場合は idea-refinement を使う）。HPO（ハイパーパラ最適化の体系的探索）は対象外。 |
Kaggle Ideation
Kaggle コンペ参加期間中の 実験投資判断スキル。次に試す仮説を発散しつつ、優先度付けした実験バックログ Markdown を 1 枚生成する。良い仮説を出すだけでなく、「今やるべきでない仮説を殺す」「壊さずに出せる変更を選ぶ」ことを中心に据える。
汎用ブレスト用の idea-refinement の Double Diamond 4 フェーズ骨格は流用しているが、中身は Kaggle 実装ドリブンな意思決定（実験バックログ生成）に置き換えてある。
When NOT to use
- 一般的なブレスト・新規事業アイデア・プロダクト企画 →
idea-refinement を使う
- ハイパーパラ最適化（Optuna 等の体系的探索） → 対象外。別途 HPO ツールを使う
- コンペ参加検討（どのコンペに出るか）／コンペ後の振り返り → 対象外
- 単に「コードを書いて」「モデルを学習させて」のような実装代行依頼 → 対象外
基本原則
- 発散と収束を分離する: 発散フェーズで批判しない。収束フェーズで肯定だけしない。
- 発散は質より量: 月並みな仮説（「LightGBM で学習する」だけ等の baseline 既知手）は出した上で捨てる。残すのは尖ったもの。
- 収束は批判的に: 各仮説に弱点を必ず 2 つ以上明示する。「素晴らしい」「完璧」「画期的」のような無批判表現は使わない。
- 「やらない仮説」を明示する: 殺した仮説と理由を出力に残す。これが投資判断の中核。
- 「壊さずに出せる」を優先する: 終盤ほど rollback 容易・既存差替えで済む変更を上位に置く。重い新規学習・大規模 NN 構造変更は終盤の Recommended queue 上位に置かない。
- 仮説的（前例なし）根拠にはガード必須: データ観察を欠く「思いつき」は backlog に残さず drop する。残す場合は (a) どの観察から生まれたか (b) 成功条件 (c) 30〜60 分の最小検証手順 (d) 失敗時に学べること、を 1 行ずつ強制。
- フェーズ境界でユーザに確認: Phase 1〜4 の各末で進行可否をユーザに確認する。共感仮説が 0 件なら Phase 1 に戻る。
環境別のユーザ質問ツール
| 環境 | 質問ツール |
|---|
| Claude Code | AskUserQuestionTool |
| Codex | request_user_input |
質問は Phase 1 で 1〜2 回（必須質問＋現状フェーズに応じた追加質問）、Phase 3.1 で 1 回（共感仮説の選択）、各 Phase 末で 1 回（進行確認）を基本とする。
ワークフロー
Phase 1: コンペ理解と現状把握
ユーザの相談内容に対して、以下を取得する。必須質問は 1 回でまとめる。「baseline submit 済み／反復実験中」の場合は追加質問を 2 回目で取得する。
必須質問（全フェーズ共通）
- 現状フェーズ: 3 択
未着手（コンペ理解は済んだがまだ submit していない）baseline submit 済み（最初の提出は終わった、これから本格反復）反復実験中（複数 submit 済み、改善を積んでいる）
- タスク種別・評価指標: 分類／回帰／順序回帰／ランキング／検出／セグメンテーション、評価指標（QWK / MAP@K / AUC / RMSE / etc）
- データ概要・規模: modality（tabular / image / nlp / audio / multi-modal / recsys / time-series）、行数・サンプル数、ラベル分布の特徴
- 残時間: 残日数 or 残時間
- submission 残数: 1 日あたりの上限と、現時点の残り回数
- 計算リソース: ローカル GPU / クラウド / Kaggle Notebook 専用 など
- 発散対象範囲: 特徴量／モデル／前処理／CV／アンサンブル／後処理 のうち何を発散したいか（複数可）
追加質問（baseline submit 済み・反復実験中のみ）
- 現状最高解構成: 単体モデル or アンサンブル、構成詳細（モデル種別／fold 数／blend 方式）
- CV / Public LB スコア
- CV-LB 信頼度:
整合（差が想定内） / 微乖離（0.005〜0.02 程度の乖離） / 大乖離（0.02 超）
- 既試行で効いた／効かなかったこと
回答が曖昧な場合は次のフェーズに進まず、追加質問で確定させる。確定後、ユーザに「この理解で合っているか」を確認してから Phase 2 へ。
未着手の場合: 追加質問はスキップする。「既試行」も聞かない。
Phase 2: 仮説発散（10〜20 件）
references/divergent-techniques.md を読み、8 つの観点を発想のヒントにしながら仮説を生成する。
- データ視点
- モデル視点
- 前処理・特徴量変換
- CV 戦略
- ロス・指標整合
- 上位解法転用
- データ健全性
- 学習戦略・表現学習
提示数は 10〜20 件、中央値は 12〜15 件。観点はあくまで補助線で、何軸使う・何軸にまたがるといった必須制約は設けない。ただし divergent-techniques.md 末尾の「現状フェーズ別の重み・禁止事項」表に従い、フェーズに応じて重点と禁止仮説を意識する。
- 序盤の重点: ⑥上位解法転用・⑦データ健全性（CV 設計確定）・①データ視点
- 中盤の重点: ⑦データ健全性（leak / shift 検証）・③特徴量変換・⑧学習戦略
- 終盤の重点: ②モデル視点（アンサンブル多様性）・⑤後処理。禁止: 重い新規学習・大規模 NN 構造変更
月並みな仮説（既知 baseline 既知手で終わる、HPO だけ等）は捨てる。捨てた候補は提示時に 1 行触れてよいが提示数（10〜20）にはカウントしない。
提示は番号付き箇条書き。各仮説 1〜2 文＋根拠 1 行（過去解法 / 理論的 / データ観察 / 仮説的（前例なし） のいずれか）。
提示後、Phase 3.1 へ進む。
Phase 3: 評価
3.1 共感仮説の聴取
ユーザに「共感した仮説（複数可）」を質問する。0 件、または「どれもピンと来ない」と回答されたときは Phase 1 に戻る。戻り先は 対象範囲＋現状フェーズ＋残時間 の 3 観点に絞って再質問する（タスク種別・評価指標・データ概要は前回確定済みのため再確認しない）。再質問後、Phase 2 をやり直す。
3.2 3 方向クラスタリング
共感仮説を 3 つの方向性（テーマ）にクラスタリングする。クラスタリング軸は 1 つだけ選ぶ（複数軸の混在は禁止）。次の選択肢から、共感仮説の性質に最も合うものを 1 つ採用する。
- 仮説タイプ（特徴量系／モデル系／後処理系 など）
- リスク・コスト軸（low-risk・低コスト群／中コスト・要検証群／高 reward・高リスク群）
- 期待効果軸（score-lift 直接狙い／diagnostic で次手を作る／robustness で守る）
各方向性に「方向性の名前（5〜10 字）」「核心（1〜2 文）」「含まれる元仮説番号」を付ける。
3.3 6 視点で批判的評価
references/evaluation-criteria.md を読み、6 視点で各仮説を評価する。
| 視点 | 概要 |
|---|
| Impact カテゴリ | score-lift / robustness / diagnostic / ensemble-diversity / metric-alignment / submission-strategy から primary 1 つ ＋ 任意 tags ＋ 根拠 1 行 |
| 検証コスト | 30 分以内 / 数時間 / 半日以上 |
| time-to-signal | どれくらい早く良否が分かるか（数分 / 1 fold で判明 / 全 fold 必要） |
| バリデーション堅牢性 | CV-LB 整合維持 / 過学習リスク中 / リーク・分布乖離懸念 |
| 実装コスト | 既存差替え（rollback 容易） / 中規模実装 / 専門知識・外部依存 |
| submission risk | 低（local 検証完結） / 中（submit 必要だが残数余裕） / 高（LB probing / public overfit / 提出枠枯渇懸念） |
- 各仮説に弱点を 2 つ以上 明示する。
- 過度な肯定表現（「素晴らしい」「完璧」「画期的」「最高」「革新的」「圧倒的」）は禁止。
- 評価は表形式が望ましい。
評価後、ユーザに「Phase 4（バックログ生成）へ進んでよいか」を確認する。
Phase 4: 実験バックログ Markdown 生成
references/output-template.md を読み、以下を含むマークダウンを 1 枚生成する。
- コンペ概要（タスク／評価指標／データ規模／残期間／submission 残／計算リソース）
- 現状ベースライン（構成／CV / Public LB／CV-LB 信頼度）※未着手の場合は「未着手」と記載
- 仮説バックログ（10〜20 件、6 視点を含む表）
- Recommended queue: フェーズ別件数（序盤 5〜7／中盤 3〜5／終盤 1〜3／残 24h 未満 1 件 + backup submission 方針）
- やらない仮説（理由 1 行付き）
- 不明点（最低 1 件、空欄禁止）
Recommended queue の選定基準: Impact カテゴリ多様性 × Cost の安さ × 依存なし × time-to-signal の速さ × submission risk の低さ。終盤は重い新規学習・大規模 NN 構造変更を上位に置かないガードを本文中に明記する。
生成後、ユーザに最終確認を取る。修正要望があれば Phase 4 内で再生成する。
運用ルール
- 発散数は 10〜20 の範囲を守る。9 件以下は不足、21 件以上はノイズ。
- 各 Phase 末でユーザに進行確認を取る（特に Phase 1 の理解確定、Phase 3.3 の評価結果、Phase 4 の最終確認）。
- 共感仮説が 0 件のとき、無理に進めず Phase 1 に戻る。
- 不明点欄は必ず最低 1 件埋める。「なし」と書かない。
- 無批判表現（「素晴らしい」「完璧」「画期的」「最高」「革新的」「圧倒的」）を出力に含めない。
- 「仮説的（前例なし）」根拠の仮説には観察由来＋成功条件＋最小検証手順＋失敗時の学びを併記必須。観察由来を書けないなら backlog に残さず drop する。
- HPO（ハイパーパラ体系的探索）は仮説バックログに含めない。やるなら別途 Optuna 等を使う旨を不明点・やらない仮説で言及するに留める。
- 終盤フェーズで Recommended queue の上位に「重い新規学習」「大規模 NN 構造変更」を置かない。
- leak の扱いは「検証・隔離・public/private risk」を扱う。leak を悪用する方向（LB only に効く加工）を煽らない。
参照ファイル
references/divergent-techniques.md — Phase 2 で読む。発散の 8 観点・アンチパターン・現状フェーズ別の重み・禁止事項。references/evaluation-criteria.md — Phase 3.3 で読む。6 視点の評価表テンプレと批判的評価のガード。references/output-template.md — Phase 4 で読む。最終マークダウンの記入指針と完成例。
