ce:ideate

改善アイデアの生成

注：現在の年は2026年です。 アイデア創出ドキュメントの日付を記入する際や、最近のアイデア創出の成果物を確認する際に使用してください。

ce:ideate は ce:brainstorm に先行します。

• ce:ideate が答えるのは、「検討する価値のある、最も有望なアイデアは何か」です。
• ce:brainstorm が答えるのは、「選んだアイデアが具体的に何を意味するのか」です。
• ce:plan が答えるのは、「どのように構築するか」です。

このワークフローでは、docs/ideation/ に優先順位を付けたアイデア創出ドキュメントを作成します。要件、計画、コードは作成しません。

対話方法

利用可能な場合は、プラットフォームのブロッキング質問ツール（Claude Code の AskUserQuestion、Codex の request_user_input、Gemini の ask_user）を使用してください。それ以外の場合は、チャットで番号付きの選択肢を提示し、先に進む前にユーザーの回答を待ってください。

質問は一度に1つずつ行ってください。自然な選択肢がある場合は、簡潔な単一選択式を優先してください。

焦点のヒント

<focus_hint> #$ARGUMENTS </focus_hint>

指定された引数は、任意のコンテキストとして解釈してください。次のようなものが考えられます。

• DX improvements のような概念
• plugins/compound-engineering/skills/ のようなパス
• low-complexity quick wins のような制約
• top 3、100 ideas、raise the bar のような件数のヒント

引数が指定されていない場合は、自由なテーマでアイデア創出を進めてください。

基本原則

1. アイデアを出す前に実態を把握する — まず実際のコードベースを調査してください。リポジトリから切り離された抽象的な製品アドバイスを生成しないでください。
2. 多数の案を出す → すべて批評する → 生き残った案のみ説明する — 品質を高める仕組みは、楽観的な順位付けではなく、理由を明示した却下です。このパターンが余分なプロセスに埋もれないようにしてください。
3. 実行に向けてブレインストーミングへ導く — アイデア創出では有望な方向性を特定し、ce:brainstorm では選んだ案を計画できるだけの具体性まで定義します。アイデア創出の結果から、計画へ直接進まないでください。

実行フロー

フェーズ0：再開と対象範囲

0.1 最近のアイデア創出作業を確認する

docs/ideation/ を調べ、過去30日以内に作成されたアイデア創出ドキュメントを確認してください。

以前のアイデア創出ドキュメントが関連すると見なす条件：

• トピックが依頼された焦点と一致する
• パスまたはサブシステムが依頼された焦点と重なる
• 依頼が自由形式で、明らかに関連する最近の未完了ドキュメントがある
• 課題に基づくかどうかが一致する：現在の引数が課題トラッカーを意図している場合、課題に基づかないアイデア創出を再開する提案はしない。その逆も同様とし、それぞれを別のトピックとして扱う

関連するドキュメントがある場合は、次のどちらにするか尋ねてください。

1. 続きから始める
2. 新たに始める

続きから始める場合：

• ドキュメントを読む
• すでに検討した内容を要約する
• 以前のアイデアのステータスを保持する
• 重複するファイルを作成せず、既存のファイルを更新する

0.2 対象モードを分類する

環境ではなく、アイデア創出の対象（ユーザーがアイデアを求めているテーマ）を分類してください。どのリポジトリ内にいても、そのリポジトリと無関係なテーマについてアイデアを出すことがあります。また、/tmp にいても、頭の中にあるコードについてアイデアを出すことがあります。

次の2つの二者択一の判断を順番に行い、それぞれで否定的なシグナルを列挙してください。

判断1 — リポジトリに基づくか、それ以外か。 まずプロンプトの内容を重視し、次にテーマとリポジトリの整合性を考慮してください。現在の作業ディレクトリにリポジトリがあるかどうかは、補助的な根拠としてのみ扱ってください。

• リポジトリに基づくと判断する肯定的なシグナル：プロンプトがリポジトリのファイル、コード、アーキテクチャ、モジュール、テスト、ワークフローに言及している。テーマが現在のコードベースに明確に限定されている。
• それ以外に判断する否定的なシグナル：プロンプトで、リポジトリに存在しないもの（価格設定、命名、ナラティブ、ビジネスモデル、個人的な意思決定、ブランド、コンテンツ、市場でのポジショニング）に言及している。コード上の対象がなく、創作、ビジネス、または個人的なテーマである。 Decision 2（Decision 1 = elsewhere の場合のみ実行）— ソフトウェアか、ソフトウェア以外か。 個々のアイデアが最終的にどこに反映されるかではなく、アイデアを出す対象がソフトウェアの成果物またはシステムかどうかで分類します。話題が製品、アプリ、SaaS、Web／モバイル UI、機能、ページ、サービスに関するものであれば、アイデア自体がそのソフトウェア製品のコピー、UX、CRO、価格設定、オンボーディング、ビジュアルデザイン、ポジショニングに関するものであっても、elsewhere-software です。Elsewhere-non-software は、ソフトウェアの要素がまったくない話題に限ります。会社やブランドの命名（製品とは独立したもの）、物語や創作、個人的な決断、デジタル以外の事業戦略、物理的な製品のデザインなどです。

分類例：

• 「サインアップページのコンバージョンを改善する」→ elsewhere-software（対象はページです）
• 「オンボーディングフローを再設計する」→ elsewhere-software（対象はフローです）
• 「価格ページの A/B テストのアイデア」→ elsewhere-software（対象はページです）
• 「メモアプリに追加する機能」→ elsewhere-software
• 「新しいコーヒーショップの名前を考える」→ elsewhere-non-software（対象はブランドです）
• 「短編小説のプロットのアイデア」→ elsewhere-non-software（対象は物語です）
• 「次のキャリア選択肢」→ elsewhere-non-software（対象は個人的な決断です）

推測したアプローチを、ユーザーが理解できる平易な言葉で、冒頭に一文で示してください。内部の分類ラベル（repo-grounded、elsewhere-software、elsewhere-non-software）はユーザーに絶対に表示しないでください。これらの名前はルーティング専用です。以下のテンプレートを実際の話題に合わせて調整し、モード名ではなく、話題そのものから分野を表す言葉（例：「ランディングページ」「オンボーディングフロー」「命名」「キャリア選択」）を選んでください。

• Repo-grounded：「このコードベースの話題、つまり X として扱います。切り替えるには『実際にはリポジトリ外の話題です』と言ってください。」
• Elsewhere-software：「このリポジトリ外の製品／ソフトウェアの話題、つまり X として扱います。切り替えるには『実際にはこのリポジトリについてです』または『実際にはソフトウェアとは関係のない話題です』と言ってください。」
• Elsewhere-non-software：「[命名 | 物語 | ビジネス | 個人的な事柄]の話題、つまり X として扱います。切り替えるには『実際にはソフトウェア製品についてです』または『実際にはこのリポジトリについてです』と言ってください。」

修正のための案内も、「実際にはリポジトリ外の話題です」「実際にはこのリポジトリについてです」のような平易な言葉にしてください。「実際には elsewhere-software」のような内部ラベルは使わないでください。

曖昧な場合は能動的に確認する（V16）。 分類の確信度が低い場合（/ce:ideate ideas や /ce:ideate ideas for the docs のように、単一のキーワードや短いプロンプトがどちらのモードにも明確に当てはまる場合、現在の作業ディレクトリとプロンプトのシグナルが矛盾する場合、リポジトリ内部と外部の両方に関わる対象が話題に含まれる場合）は、Phase 1 のグラウンディングを開始する前に、プラットフォームのブロッキング質問ツール（Claude Code では AskUserQuestion、Codex では request_user_input、Gemini では ask_user）を使って確認の質問を一つしてください。明確な場合は、推測したモードを示す一文で十分です。質問はしないでください。

質問の例（プロンプトに合わせて調整してください。プラグインの AGENTS.md にある Interactive Question Tool Design のルールに従ってください。ラベルだけで意味が伝わること、最大 4 つ、三人称、区別する語を先頭に置くこと、内部モード名を出さないこと）：

• 質問：「エージェントは何についてアイデアを出せばよいですか？」
• 選択肢：
  • 「このリポジトリのコード — 機能、リファクタリング、アーキテクチャ」
  • 「このリポジトリ外の話題 — ビジネス、デザイン、コンテンツ、個人的な決断」
  • 「キャンセル — プロンプトを書き直す」

ユーザーが「リポジトリ外」を確認または選択した場合も、Decision 2 を実行して、elsewhere-software と elsewhere-non-software のどちらかを判定してください。 ルーティングルール。 Decision 2 が non-software の場合も、Phase 1 Elsewhere-mode のグラウンディング（ユーザーコンテキストの統合＋デフォルトでのウェブ調査）を実行してください（スキップの指示があれば従います）。このモードでは、learn-researcher はデフォルトでスキップします。CWD の docs/solutions/ は、ネーミング、ナラティブ、個人的な話題、デジタル以外のビジネストピックにはほとんど活用できません。詳しくは Phase 1 を参照してください。続いて references/universal-ideation.md を読み込み、Phase 2 のソフトウェア用フレーム振り分けと Phase 6 のメニュー説明に代えて、その内容に従ってください。このファイルの読み込みは必須です。このファイルには、このモードで Phase 2 とアイデア創出後のメニューに代わる、ドメインに依存しない生成フレーム、批評の評価基準、締めくくりのメニューが記載されており、これらの詳細はメイン本文にはありません。記憶を頼りに即興で進めると、ソフトウェア以外のトピックに適したファシリテーションになりません。どの段階でも、リポジトリ固有のコードベーススキャンは実行しないでください。references/post-ideation-workflow.md の §6.5 Proof Failure Ladder は引き続き適用されます。Proof の保存（elsewhere-mode では Save and end のデフォルト）が失敗した場合は必ず読み込んで従い、ソフトウェア以外の elsewhere の実行でもローカル保存へのフォールバック経路を確保してください。

プロンプトの範囲拡大またはインテークの手順（以下の 0.4）がトピックを実質的に変えた場合は、Phase 1 に進む前にモードの記述を再評価してください。最初に読んだ時点の範囲ではなく、実際に扱う範囲に基づいて分類してください。

0.3 Focus と Volume の解釈

引数から次の 3 点を推測します。

• Focus context - コンセプト、パス、制約、または自由形式
• Volume override - 候補数または残すアイデア数を変えるヒント
• Issue-tracker intent - ユーザーが入力ソースとして issue／バグデータを求めているかどうか。Repo-mode 専用です。elsewhere mode ではトリガーしないでください。

Issue-tracker intent は、引数の主な意図が issue のパターン分析である場合にトリガーします。対象となる語句は bugs、github issues、open issues、issue patterns、what users are reporting、bug reports、issue themes です。

単にバグを焦点として挙げているだけの引数ではトリガーしないでください。例：bug in auth、fix the login issue、the signup bug。これらは焦点のヒントであり、issue トラッカーの分析依頼ではありません。

複数の指示が組み合わさっている場合（例：top 3 bugs in authentication）は、まず issue-tracker intent を検出し、次に volume override を検出します。残りは focus hint です。Focus は重要な issue を絞り込み、volume override は残すアイデアの数を指定します。

デフォルトの数：

• 各アイデア創出サブエージェントは約 6～8 件のアイデアを生成します（デフォルトの経路では 6 フレームで合計約 36～48 件、issue-tracker mode では 4 フレームで約 24～32 件の生のアイデアとなり、重複排除後に残るのは 6 フレームの経路で約 25～30 件、4 フレームの経路ではそれより少なくなります）
• 上位 5～7 件を残します

次のような明確な指定には従ってください。

• top 3
• 100 ideas
• go deep
• raise the bar

厳密な構文解析ではなく、妥当な解釈をしてください。

0.4 コンテキストの簡易インテーク（Elsewhere Mode、ソフトウェアのトピックのみ）

Repo mode ではこの手順をスキップしてください（Phase 1 のグラウンディングエージェントが対応します）。ソフトウェア以外のトピックを扱う elsewhere mode でもスキップしてください（インテークはユニバーサルなファシリテーションのリファレンスに従います）。

質問する前に、識別可能性テストを適用してください。ユーザーが示したコンテキストの一部を、対照的な別のものに置き換えることで、残るアイデアが大きく変わるでしょうか。変わる場合、そのコンテキストは重要なので、質問せずに進めてください。変わらない場合は、テンプレートから始めるのではなく、ユーザーがすでに提供した情報を踏まえて、的を絞った質問を 1～3 件してください。デフォルトでは自由回答形式の質問を使い、回答の選択肢が少なく明確に分かれている場合（ジャンル、トーンなど）に限り、単一選択式を使ってください。回答を得るたびに、次の質問をする前にテストを再適用してください。消極的な返答（「わからない、適当に進めて」など）があれば終了し、「制約はない」という回答もそのまま有効な回答として扱ってください。

ユーザーが最初から豊富なコンテキスト（貼り付けた資料、ブリーフ、既存の草稿など）を提供している場合は、1 行で理解した内容を確認し、インテークを完全にスキップしてください。

0.5 コストの透明性に関する通知

フェーズ 1 を開始する前に、複数エージェントのコストが見えなくならないよう、推定モードでのエージェント数を短い一文で提示します。実際のディスパッチ判断に基づいて数を計算します。基準は、グラウンディング用コンテキストエージェント 1 つ（repo モードではコードベースのスキャン、それ以外ではユーザーコンテキストの統合）＋学習事項 1 つ（elsewhere-non-software ではスキップ）＋ウェブリサーチャー 1 つ＋アイデア創出エージェント 6 つで、repo モードと elsewhere-software では合計 9 つ、elsewhere-non-software では 8 つです。課題トラッカーに関する意図がある場合（repo モードのみ）は、課題インテリジェンスエージェントを 1 つ追加し、アイデア創出エージェントを 6 つから 4 つに減らすため、合計は 1 つ減ります。ユーザーが Slack リサーチを選択した場合は 1 つ追加します。ユーザーがウェブリサーチのスキップフレーズを指定した場合、または V15 の再利用が行われる場合は 1 つ減らします。

例（デフォルト、スキップやオプトインなし）：

• Repo モード：「約 9 個のエージェントをディスパッチします：コードベースのスキャン＋学習事項＋ウェブリサーチ＋アイデア創出サブエージェント 6 つ。スキップフレーズ：'no external research'、'no slack'。」
• Repo モード、課題トラッカーに関する意図あり：「約 8 個のエージェントをディスパッチします：コードベースのスキャン＋学習事項＋ウェブリサーチ＋課題インテリジェンス＋アイデア創出サブエージェント 4 つ。スキップフレーズ：'no external research'、'no slack'。」これはテーマの特定に成功した場合の経路を示しています。課題インテリジェンスから十分なシグナルが得られない場合（フェーズ 1 を参照）、アイデア創出はサブエージェント 6 つに戻り、合計は約 9 個になります。
• Elsewhere-software：「約 9 個のエージェントをディスパッチします：コンテキストの統合＋学習事項＋ウェブリサーチ＋アイデア創出サブエージェント 6 つ。スキップフレーズ：'no external research'。」
• Elsewhere-non-software：「約 8 個のエージェントをディスパッチします：コンテキストの統合＋ウェブリサーチ＋アイデア創出サブエージェント 6 つ。スキップフレーズ：'no external research'。」

この一文は情報提供のみを目的としています。ユーザーが確認する必要はありません。

フェーズ 1：モードに応じたグラウンディング

アイデアを生成する前に、グラウンディング情報を収集します。ディスパッチするエージェントの構成は、フェーズ 0.2 で選択したモードによって異なります。ウェブリサーチはすべてのモードで実行します（スキップフレーズは適用されます）。学習事項の収集は repo モードと elsewhere-software で実行し、elsewhere-non-software ではデフォルトでスキップします。CWD の repo にある docs/solutions/ には、エンジニアリングのパターンがほぼ常に含まれており、命名、物語、個人的な話題、デジタル以外のビジネスに関する話題には転用できないためです。

フェーズ 1 の開始時に <run-id> を 1 回生成します（16 進数 8 文字）。V15 キャッシュファイル（このフェーズ）と V17 チェックポイント（フェーズ 2 と 4）で再利用し、実行ごとの一時ディレクトリを共有します。

一時ディレクトリのパスを事前に解決してください。 repo Scratch Space 規約の呼び出しをまたいで再利用可能なルールに従い、一時ファイルは OS の一時ディレクトリに置きます（.context/ には置きません）。アイデア創出のトピックが CWD の repo に関連することはめったにないため（特に elsewhere モードでは）、一時ファイルを repo ツリーの外に置くのが適切なデフォルトです。ディレクトリを作成し、以降のすべての用途に使う絶対パスを取得するため、bash コマンドを 1 つ実行します。${TMPDIR:-/tmp} を文字列のままシェル以外のツール（Write、Read、Glob）に渡してはいけません。これらのツールはシェル展開を行いません。

SCRATCH_DIR="${TMPDIR:-/tmp}/compound-engineering/ce-ideate/<run-id>"
mkdir -p "$SCRATCH_DIR"
echo "$SCRATCH_DIR"

エコーされた絶対パス（macOS では /var/folders/.../T/compound-engineering/ce-ideate/a3f7c2e1、Linux では /tmp/compound-engineering/ce-ideate/a3f7c2e1 など）を <scratch-dir> として、この実行で以降に行うすべてのチェックポイントの書き込みとキャッシュの読み込みに使用します。フェーズ 6 の完了後も実行ディレクトリは削除されません。V15 キャッシュはセッション単位で、実行 ID をまたいで再利用されます。また、チェックポイントは呼び出しをまたいで再利用可能な規約に従い、後続の呼び出しで見つけられるよう、セッション単位のアーティファクトを残します。

グラウンディングエージェントはフォアグラウンドで並列実行します（結果がフェーズ 2 の前に必要なため、バックグラウンドでは実行しません）。

Repo モードのディスパッチ：

1. 簡易コンテキストスキャン — プラットフォームで利用可能な、能力を満たす最も安価なモデル（Claude Code の model: "haiku" など）を使用して汎用サブエージェントをディスパッチし、次のプロンプトを渡します：

   プロジェクトの AGENTS.md を読み（互換性のためのフォールバックとしてのみ CLAUDE.md、どちらも存在しない場合は README.md を読み）、次にネイティブのファイル検索/glob ツール（例: Claude Code ではパターン * または */* を指定した Glob）を使ってトップレベルのディレクトリ構成を把握します。以下を網羅した簡潔な要約（30 行未満）を返してください:

   • プロジェクトの形状（言語、フレームワーク、トップレベルのディレクトリ構成）
   • 注目すべきパターンや規約
   • 明らかなペインポイントやギャップ
   • 改善に向けた有力なてこのポイント

   スキャンは浅く保ってください — トップレベルのドキュメントとディレクトリ構造のみを読みます。GitHub の issue、テンプレート、コントリビューションガイドラインは分析しないでください。深いコード検索は行わないでください。

   フォーカスヒント: {focus_hint}

2. 学びの検索 — compound-engineering:research:learnings-researcher を、アイデア出しのフォーカスの簡単な要約とともにディスパッチします。

3. Web リサーチ（常時オン。スキップフレーズと V15 キャッシュの扱いについては、以下の「Web リサーチ」サブセクションを参照してください）。

4. Issue インテリジェンス（条件付き） — フェーズ 0.3 で issue トラッカーの意図が検出された場合、compound-engineering:research:issue-intelligence-analyst をフォーカスヒントとともにディスパッチします。他のエージェントと並行して実行します。

   エージェントがエラーを返した場合（gh がインストールされていない、リモートがない、認証失敗）、ユーザーに警告をログ出力し（「Issue 分析は利用できません: {reason}。標準のアイデア出しを続行します。」）、残りのグラウンディングを続行します。

   エージェントが報告した issue の総数が 5 件未満の場合、「テーマ分析には issue シグナルが不十分です」と記録し、フェーズ 2 のデフォルトのアイデア出しフレームで続行します。

Elsewhere モードのディスパッチ（コードベーススキャンをスキップ。ユーザー提供のコンテキストが主要なグラウンディングです）:

1. ユーザーコンテキストの統合 — 汎用サブエージェント（利用可能な中で最も低コストのモデル）をディスパッチし、フェーズ 0.4 のインプットでユーザーが提供したコンテキストと、あればリッチプロンプトの素材を読ませ、コードベースコンテキストの形を反映した構造化されたグラウンディング要約を返させます（プロジェクトの形状 → トピックの形状、注目すべきパターン → 明示された制約、ペインポイント → ユーザーが挙げたペインポイント、てこのポイント → コンテキストが示唆する機会のフック）。これにより、フェーズ 2 のサブエージェントはグラウンディングのソースに依存しなくなります。

2. 学びの検索 （elsewhere-software のみ。elsewhere-non-software ではデフォルトでスキップ） — 関連する組織的な知識（スキル設計のパターン、類似の形状の過去のソリューション）が存在する可能性に備え、トピックの要約とともに compound-engineering:research:learnings-researcher をディスパッチします。elsewhere-non-software ではスキップします。CWD の docs/solutions/ が非デジタルのトピックにトピック的に関連する可能性は低く、実行すると無関係なエンジニアリングパターンで生成を汚染するリスクがあるためです。

3. Web リサーチ — リポジトリモードと同じです（以下のサブセクションを参照してください）。

Issue インテリジェンスは elsewhere モードには適用されません。Slack リサーチは両モードでオプトインです（以下の「Slack コンテキスト」を参照してください）。

Web リサーチ（V5、V15）

両モードで常時オンです。ユーザーがプロンプトまたは以前の回答で「外部リサーチなし」、「Web リサーチをスキップ」、または同等のことを述べた場合はスキップします。その場合、ディスパッチから compound-engineering:research:web-researcher を省き、統合されたグラウンディング要約にスキップを記録します。

セッション内で以前の Web リサーチをサイドカーキャッシュ経由で再利用します — キャッシュファイルの形状、再利用チェック、追記の挙動、プラットフォーム劣化のルールについては references/web-research-cache.md を参照してください。この実行で最初に compound-engineering:research:web-researcher をディスパッチするときに読み（そしてキャッシュが適用される可能性がある以降のすべてのディスパッチ時にも読み）ます。

compound-engineering:research:web-researcher をディスパッチするときは、フォーカスヒント、計画コンテキストの簡単な要約（1、2 文）、モードを渡します。コードベースの内容は渡さないでください — このエージェントは外部で動作します。

統合されたグラウンディングの要約

ディスパッチされたすべての結果を統合し、次のセクションを使って短いグラウンディングの要約を作成します（内容がないセクションは省略します）。

• コードベースのコンテキスト（リポジトリモード）または トピックのコンテキスト（その他のモード）— プロジェクト／トピックの概要、注目すべきパターンや明示された制約、課題、活用の手がかり
• 過去の学び — docs/solutions/ にある、関連する組織的な知見
• イシューに関する情報（存在する場合、リポジトリモードのみ）— タイトル、説明、イシュー数、トレンドの方向を含むテーマの要約
• 外部コンテキスト（ウェブ調査を実施した場合）— 先行事例、関連ソリューション、市場の動向、異分野の類似例。V15 の再利用が行われた場合は「（以前のディスパッチから再利用）」と記載します
• Slack のコンテキスト（存在する場合）— 組織的なコンテキスト

失敗時の処理。 グラウンディングエージェントの失敗は「警告して続行」に従います。グラウンディングの失敗によって処理を止めてはいけません。compound-engineering:research:web-researcher が失敗した場合（ネットワーク障害、ツールが利用できない場合）は、警告（「外部調査を利用できません：{reason}。内部グラウンディングのみで続行します。」）を記録して続行します。その他のモードでのインテークから有用なコンテキストが得られなかった場合は、グラウンディングの要約にコンテキストが限られていることを記載し、フェーズ 2 のサブエージェントがより広範な生成で補えるようにします。

Slack のコンテキスト（オプトイン、両モード）— 自動ディスパッチは決して行いません。ユーザーが Slack のコンテキストを求め、Slack ツールが利用可能な場合（現在の環境で slack-researcher エージェントまたは slack MCP ツールを探します）、フォーカスヒントを指定して compound-engineering:research:slack-researcher を他のフェーズ 1 エージェントと並行してディスパッチします。ツールが存在するものの、ユーザーが求めていない場合は、オプトインできるよう、その利用可能性をグラウンディングの要約に記載します。ユーザーが求めているにもかかわらず Slack ツールにアクセスできない場合は、インストール方法を案内します。

フェーズ 2：発散的なアイデア創出

アイデアを批評する前に、候補をすべて列挙します。

継承したモデルを使用して、アイデア創出を並行して行うサブエージェントをディスパッチします（段階を下げないでください。創造的なアイデア創出には、オーケストレーターと同じレベルの推論が必要です）。ユーザーが設定した権限を適用するため、mode パラメーターは省略します。ディスパッチ数はモードに応じて決まります。フェーズ 0.3 でイシュートラッカーに関する意図が検出され、かつイシュー情報エージェントから有用なテーマが返された場合に限り、サブエージェントは 4 つです（以下の例外を参照。クラスターから導出したフレームは最大 4 つです）。それ以外は、フェーズ 1 で意図は検出されたもののテーマが返されなかった場合の、イシュー情報が不十分なケースも含め、サブエージェントは 6 つです。各エージェントは約 6～8 個のアイデアを目指します（6 つのフレームで約 36～48 個、4 つのフレームで約 24～32 個の未整理のアイデアが得られます。重複を除いた後は、6 フレームの場合に約 25～30 個、4 フレームの場合はそれより少なくなります）。量に関する指定がある場合は、エージェントごとの目標数を調整します（例：「100 個のアイデア」なら増やし、「上位 3 件」なら最終候補数を減らすことができます）。

各サブエージェントには、グラウンディングの要約、フォーカスヒント、エージェントごとの目標数、および批評せずに候補のみを生成する指示を渡します。各エージェントが最初に挙げるアイデアはありきたりになりがちなので、その先まで考えるよう促します。すべてのアイデアを、フェーズ 1 のグラウンディングの要約に基づいて作成します。

各サブエージェントには、それぞれ異なるアイデア創出のフレームを制約ではなく出発点となる視点として割り当てます。まず割り当てられた視点から始めるよう促しつつ、有望な方向があればそれを追うよう指示します。複数のフレームを横断するアイデアも有用です。

フレームの選択（モード間で共通 — リポジトリモードとその他のモードで同じ 6 つのフレームを使用）：

1. 課題と摩擦 — ユーザー、運用担当者、またはトピックレベルの課題。常に遅い、壊れている、または煩わしいことは何か。
2. 反転、除去、自動化 — 痛みを伴うステップを反転させる、完全に取り除く、または自動化してなくす。
3. 前提を崩して捉え直す — 固定事項として扱われているが、実際には選択肢にすぎないものは何か。視点を一段上げるか、横にずらして捉え直す。
4. レバレッジと複利効果 — 一度選べば、その後の多くの施策をより低コスト、またはより効果的にできる選択肢。二次的な効果。
5. 異分野との類推 — 構造的に類似した問題をまったく異なる分野がどう解決しているかを考えて、アイデアを生み出す。基盤となる分野はユーザーのトピックで、類推先は別の業界、生物学、ゲーム、インフラ、歴史など、どこでも構いません。明白な類推にとどまらず、意外性のあるものまで掘り下げます。
6. 制約の反転 — 明白な制約を、その正反対または極端な状態に反転させます。予算が10倍、あるいはゼロだったらどうなるか。チームが100人、あるいは1人だったらどうなるか。ユーザーがゼロ、あるいは100万人だったらどうなるか。制約の反転自体が現実的でなくても、そこから導かれた設計を候補として使います。

課題追跡モードの上書き（リポジトリモードのみ）。 課題追跡の意図が有効で、課題インテリジェンスエージェントからテーマが返された場合は、信頼度が高または中のテーマをそれぞれ1つのフレームとします。クラスタ由来のフレームが3つ未満の場合は、上記の順序で6つのデフォルトフレームから補います。合計は最大4つとします。課題追跡モードでは、意図的に、より小規模なディスパッチを維持します。

各サブエージェントには、アイデアごとに簡潔な構造で返すよう依頼します。項目は、タイトル、概要、重要性、根拠となる情報や検証の手がかり、任意の大胆さまたはフォーカス適合度のシグナルです。

すべてのサブエージェントからの応答後：

1. 統合と重複排除を行い、候補のマスターリストを作成します。
2. フレームをまたいだ組み合わせを考案します。異なるフレームのアイデアが組み合わさることで、より強力なものにならないかを調べます（追加は最大3～5件を想定）。
3. フォーカスが指定されている場合は、より優れた隣接アイデアを除外せずに、統合後のリストをそのフォーカスに重み付けします。
4. 妥当な場合は、ワークフロー／DX、信頼性、拡張性、不足している機能、ドキュメント／ナレッジの複利効果、品質／保守性、今後の作業へのレバレッジなど、複数の側面にアイデアを広げます。

チェックポイントA（V17）。 横断的な統合ステップが完了し、候補リストの生データがまとまった直後に、Phase 1で記録した絶対パスを使って<scratch-dir>/raw-candidates.mdに全候補リストをサブエージェントの帰属情報とともに書き込みます。これにより、Phase 3の批評でコンテキストが圧縮される前に、最もコストの高い出力（6件の並列サブエージェントへのディスパッチと重複排除）を保護できます。ベストエフォートで実施します。書き込みに失敗した場合（ディスク容量不足、権限など）は警告を記録して処理を続行します。このチェックポイントは処理の成否を左右するものではありません。実行終了時に削除しないでください。実行ディレクトリは保持され、同じセッション内で実行IDをまたいでV15キャッシュを再利用できます（Phase 6を参照）。

統合とアイデアの統合処理の後、候補を提示する前に、references/post-ideation-workflow.mdを読み込みます。この読み込みは必須です。このファイルには、敵対的フィルタリングの評価基準、成果物テンプレート、品質基準、正規のPhase 6引き継ぎメニュー（絞り込み、Proofで開いて反復、ブレインストーミング、保存して終了）が含まれています。これらの選択肢は、この本文のほかの場所には記載されていません。読み込みを省略すると、その後のすべてのステップの質がひそかに低下します。エージェントはドキュメントに記載された選択肢を提示せず、記憶を頼りにメニューを即興で作ることになります。「手早く」とは、Phase 2のサブエージェントを減らすことであり、リファレンスの読み込みを省略することではありません。Phase 2のエージェントへのディスパッチが完了する前に、このファイルを読み込まないでください。