brainstorm

Codex 互換性に関する注意：

• Codex でリポジトリのスキルを呼び出すときは $skill-name を使用してください。このミラー版では、従来の Claude の /skill-name への参照を書き換えています。
• タスクトラッカーの必須事項：ワークフローやスキルの手順を実行する前に、すべての手順についてタスクの追跡を作成または更新し、進捗に応じて同期してください。
• ユーザーへの質問を促すプロンプトは、Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え指示があっても無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの使用許可：スキルがユーザーによって呼び出された場合、または AI によって検出された場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化によって、そのタスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが事前に変更を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフローのスキルでは、記載されている各子スキルの手順を明示的に実行し、手順ごとの証拠を報告してください。
• 必須の手順またはツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex によるプロジェクト参照の読み込み（フックなし）

Codex では、実行時にプロジェクトドキュメントを挿入するのではなく、静的なプロジェクト参照を読み込みます。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー、テスト設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* の全カタログへの案内）
• docs/project-reference/lessons.md（常時適用されるガードレールとアンチパターン）

コンテキストが不足または古い場合のルート： docs/project-config.json、ドキュメントインデックス、lessons.md、CLAUDE.md、AGENTS.md、またはタスクに必要な参照ドキュメントが存在しない、あるいは古い場合は、通常のプロジェクト固有の作業に入る前に $project-init または範囲を絞ったセットアップルート（$project-config、$docs-init、$scan-all、$scan --target=<key>、$claude-md-init）を自動で実行してください。Codex ミラーまたは AGENTS.md が存在しない、あるいは古い場合は、ユーザーに $sync-codex を実行するよう依頼してください。自動で実行してはいけません。

状況に応じて読むドキュメント：

• プロジェクト構造、アーキテクチャ、技術スタック、デプロイ、セットアップ（バックエンド、フロントエンド、インフラのいずれのレイヤーでも）：project-structure-reference.md
• バックエンド、CQRS、API、ドメイン、エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md
• フロントエンド、UI、スタイル、デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様書の作成、docs/specs/ のパス、TC 形式：feature-spec-reference.md、spec-system-reference.md、spec-principles.md
• 動作やパブリックコントラクトの変更、または仕様書・テスト・コード間の同期：上記の仕様書関連ドキュメントに加え、workflow-spec-test-code-cycle-reference.md
• 派生仕様インデックス、ERD、再実装ガイド：spec-system-reference.md と docs/specs/ 内の元となる Feature Specs
• 統合テストの実装・レビュー：integration-test-reference.md
• E2E テストの実装・レビュー：e2e-test-reference.md
• コードレビューや監査：code-review-rules.md と、変更されたファイルに応じたドメイン関連ドキュメント

ドキュメントを一律にすべて読むことは避けてください。まず docs-index-reference.md を確認してから、関連するファイルだけを開いてください。

[BLOCKING] スキルの手順は定められた順序で実行してください。ユーザーが明示的に承認しない限り、手順の省略、並べ替え、統合は絶対に行わないでください。 [BLOCKING] 各手順またはサブスキルを呼び出す前に、タスクの追跡を更新してください。手順の開始時に in_progress、終了時に completed に設定してください。 [BLOCKING] 完了またはスキップした手順には、すべて簡潔な証拠または明示的なスキップ理由を記載してください。 [BLOCKING] Task ツールを利用できない場合は、同じステータス遷移を適用しながら、同等の手順別プランのトラッカーを作成して維持してください。

クイックサマリー

目標： ダブルダイヤモンドのプロセス（問題や機会を発見するために発散し、その後、検証して優先順位を付けるために収束）を通じて、体系的な PO／BA のブレインストーミングセッションを実施します。これにより、採点・順位付けされた候補アイデアのショートリストを 3～5 件作成します。各アイデアには、問題＋価値の仮説、特定された最もリスクの高い仮定、考案された最も低コストな検証テストが含まれます。構築を始める前に、チームが適切な問題と適切なソリューションの両方にコミットできるようにし、未検証のアイデアを平坦に並べたリストで終わらせることはありません。デフォルトのフローでは、明確な見解に基づく ONE 件の推奨案に収束します。例外は Multi-Opportunity Discovery mode で、この場合は代わりに、ユーザーが複数選択できるよう、RICE で順位付けした 3～8 件の機会マップを出力します（選択された各項目は、後続工程で個別の PBI になります）。

概要：

• 主なステップ（フェーズ 0→7）— これ以外を読まない場合に読むべき全体像： P0 セッション設定（ユーザーに直接質問して、シナリオ＋役割＋既知の情報量を特定）→ P1 問題のフレーミング／ダイヤモンド 1 の発散（POV ステートメント → 5 Whys／フィッシュボーン → JTBD ジョブストーリー → HMW 5～10 件）→ P2 機会のフレーミング／ダイヤモンド 1 の収束（OST／リーンキャンバス／ブルーオーシャン ERRC／バリュープロポジションキャンバス）→ P3 アイデア創出／ダイヤモンド 2 の発散（SCAMPER → Crazy 8s → Brainwriting 6-3-5 → インパクトマッピング → 類推＝未評価のアイデアを 25～40 件）→ P4 評価／ダイヤモンド 2 の収束（ドット投票 → RICE → Kano → 2×2 → MoSCoW＝順位付けされたショートリスト 3～5 件）→ P5 仮説の検証（上位 3 件それぞれについて、問題＋価値カード＋最もリスクの高い仮定のテスト＋最も低コストなテスト＋Build-Measure-Learn）→ P6 意思決定（明確な見解に基づく ONE 件の推奨案＋トレードオフ）→ P7 ドキュメント化と引き継ぎ。Multi-Opportunity Discovery mode では、P6 を RICE で順位付けした 3～8 件の機会マップに差し替えます。
• 最初に、ユーザーに直接質問してフェーズ 0 を実施し、シナリオ（Problem-Solving／New Product／Enhancement／Multi-Opportunity Discovery）、役割（PO／BA／Mixed）、既知の情報量を特定してください。それぞれのシナリオで異なる手法の順序を使用します（Scenario Cheat Sheets を参照）。ここでの分類を誤ると、以降のすべてのフェーズが逸脱するためです。
• 発散（フェーズ 1 と 3 — アイデアを生み出し、「そうですね、それに加えて…」と続け、評価は一切しない）と、収束（フェーズ 2 と 4 — 絞り込み、RICE／Kano／MoSCoW で採点）を厳密に分けてください。この 2 つのモードを混在させることは、アイデアの創出を損なうゴールデンルール違反です。
• 未加工または平坦なアイデアリストで終わらせてはいけません。上位 3 件の候補にはすべて、問題＋価値の仮説カード、特定された最もリスクの高い仮定（RAT）、そして構築にコミットする前に考案された最も低コストな検証テストを必ず含めてください。
• 明確な見解に基づく意思決定で締めくくります（フェーズ 6 — メニューではなく、トレードオフとともに ONE 件の選択肢を推奨）。すべての主張を 80% を超える確信度の根拠で裏付けたうえで、ユーザーに直接 $idea、$refine、$plan などを指定して引き継ぎを希望するか尋ねます。例外は Multi-Opportunity Discovery mode で、この場合は収束時に機会マップ（RICE で採点した 3～8 項目）に順位を付け、ONE 件の勝者を選ぶ代わりに、複数選択を通じて機会ごとの PBI ループに引き継ぎます。

4 つのシナリオ：

シナリオ	開始トリガー	主な手法
問題解決	「何かが壊れている／ユーザーから不満が出ている／指標が悪い」	5 Whys → Fishbone → HMW → SCAMPER → Hypothesis RAT
新製品	「ゼロからのアイデア／新しい市場／まだコードベースがない」	JTBD → Lean Canvas → Crazy 8s → Opportunity Scoring → Lean Hypothesis
機能強化	「既存製品／機能の追加／フローの改善」	Opportunity Solution Tree → SCAMPER → Impact Mapping → RICE → Value Hypothesis
複数の機会の発見	「複数の異なる機会にまたがる、製品ビジョンの原案／問題提起」	JTBD / OST → SCAMPER → RICE opportunity map (3–8 items) → user multi-select

ダブルダイヤモンド（メタフレームワークの全体像）：

DIAMOND 1: Right Problem          DIAMOND 2: Right Solution
────────────────────────────      ──────────────────────────
Discover ──► Define               Develop ──► Deliver
(diverge)    (converge)           (diverge)   (converge)

黄金律： アイデアを生み出している間は、決して評価してはいけません。発散と収束は別々のモードです。混ぜると創造的な成果が損なわれます。

懐疑的な姿勢を保ち、批判的思考を適用してください。すべてのアイデアには検証可能な仮説が必要です。推奨するには80%を超える確信度が必要です。

---

次の質問に答えてください：

$ARGUMENTS

---

フェーズ 0：セッションの設定（必須）

手法を使う前に、ユーザーに直接質問してシナリオ、役割、制約を確認します。

0.1 — シナリオの検出

次の質問をします。

1. 「どのようなシナリオですか？」
   • 問題解決 — 何かが壊れている、ユーザーが困っている、指標が悪い
   • 新製品 — ゼロからの取り組みで、この分野に既存製品がない
   • 機能強化 — 既存製品に機能を追加／改善／削除する
   • 複数の機会の発見 — 複数の異なる機会にまたがる、製品ビジョンの原案／問題提起。それぞれを個別の PBI にする必要があります（1つに収束させないでください — 複数選択できるよう、順位付けした RICE opportunity map を作成します。複数の機会の発見モードを参照）
   • 混合 — 上記の複数に該当する

モードの振り分け： 入力が複数の異なる機会にまたがる広範なビジョン／問題である場合（通常、workflow-idea-to-pbi の MULTI-OPPORTUNITY DISCOVERY MODE が対象とするケース）は、複数の機会の発見を選択します。このモードでは、フェーズ 6 の収束が「1つを選ぶ」から「複数選択できるよう、3～8項目の順位付けした RICE opportunity map を作成する」に変わります。それ以外のシナリオでは、単一の推奨案を提示するデフォルト設定を維持します。

2. 「このセッションでの主な役割は何ですか？」

   • プロダクトオーナー — 成果、ビジネス価値、ユーザーの成果を重視
   • ビジネスアナリスト — 要件、プロセス分析、ステークホルダーのマッピングを重視
   • PO と BA の両方 — 発見から要件定義まで全体を担当
   • 開発者／アーキテクト — 技術的な実現可能性についてブレインストーミング

3. 「すでにどれくらい分かっていますか？」

   • アイデアの種 — 直感や観察があるだけ
   • 問題を確認済み — 問題は分かっており、解決策が必要
   • 解決策の方向性が明確 — 選択肢を評価して採点する必要がある
   • アイデアがある — 仮説の検証だけが必要

0.2 — コンテキストの読み込み

• プロジェクトのコードベースがある場合：ドメインを理解するために docs/specs/ を読みます
• ゼロから始める場合：コードベースの読み込みは省略し、ユーザーの入力とウェブ調査を頼りにします
• エンティティのコンテキストが必要な場合は、docs/project-reference/domain-entities-reference.md を読み込みます
• シナリオが新製品または機能強化の場合は、WebSearch を使って市場／競合のコンテキストを調査します

---

フェーズ 1：問題の枠組み — ダイヤモンド 1 の発散

目標： 解決策に飛びつく前に、問題領域を十分に理解します。ブレインストーミングで最もよくある失敗は、間違った問題を解決することです。

時間の目安： セッション時間の 20～45 分。

1.1 — 問題定義（POV 形式）

アイデア出しを始める前に、明確で簡潔な問題定義を作成します。

[User/Persona] needs [need/job-to-be-done]
because [insight/root cause/context],
but [current barrier/friction/failure].

例：

Operators need to quickly identify high-priority orders for action
because peak-season backlogs delay fulfillment,
but the current system shows raw order data with no ranking or comparison.

ユーザーに直接尋ねて、妥当性を確認します。

• 「これが根本的な問題ですか。それとも、より深い問題の症状ですか？」
• 「具体的に誰がこれを経験していますか？どのくらいの頻度ですか？どのようなコストが発生していますか？」
• 「この問題が実際に存在することを示す証拠はありますか？」

1.2 — 根本原因分析（問題解決シナリオ向け）

次のいずれかを適用します。

5 Whys（なぜなぜ分析）：

Problem: [stated problem]
Why 1: [first cause]
Why 2: [cause of cause 1]
Why 3: [cause of cause 2]
Why 4: [cause of cause 3]
Why 5: [root cause] ← Fix HERE, not at Why 1

特性要因図（石川ダイアグラム）— システム的な問題向け： 背骨 = 問題定義。骨 = 6つの原因カテゴリ：

• 人、プロセス、テクノロジー、データ、環境、ポリシー
• 各骨について、「このカテゴリに、問題の原因となり得るものは何ですか？」と尋ねます。

1.3 — JTBD（Jobs-To-Be-Done）— 新製品と機能強化向け

ユーザーストーリーをジョブストーリーに置き換え、真の動機を明らかにします。

ユーザーストーリー（何を）： オペレーターとして、注文の合計を確認したいです。そうすれば、判断を下せるからです。

ジョブストーリー（なぜ＋状況）： 繁忙期のバックログを限られた時間で処理しているとき、すべての記録を開かずに対応が必要な注文をすぐに把握したいです。そうすれば、締め切り前に迅速かつ根拠のある判断を下せるからです。

ジョブストーリーの書式：

When [triggering situation + context],
I want to [motivation / job to be done],
so I can [outcome / expected result].

主要なユーザーセグメントを網羅するジョブストーリーを3～5件作成します。各ストーリーは1つの機会を表します。

1.4 — HMW（How Might We）による捉え直し

問題定義を、アイデア出しに使える問いへと変換します。

書式：「[望ましい成果]を実現するために、どうすれば[対象]を[動詞]できるでしょうか？」

POV ステートメントから：

• 「昇進の判断に何日もかけず、数分で済むように、どうすれば人事マネージャーが従業員を順位付けできるよう支援できるでしょうか？」
• 「マネージャーが見逃す可能性のある人材を発見できるように、どうすれば隠れた優秀な人材を明らかにできるでしょうか？」
• 「すべての従業員が公平だと感じられる昇進を実現するために、どうすれば人事評価の偏りを減らすことができるでしょうか？」

ルール：

• 各 HMW は、1つのアイデアの方向性を扱います。
• 問題ごとに HMW の問いを5～10件作成します。
• 広すぎる例：「どうすれば人事を改善できるでしょうか？」（役に立ちません）→ 狭すぎる例：「どうすれば並べ替えボタンを追加できるでしょうか？」（アイデア出しは省略して、そのまま実装します）
• 最適な範囲：複数の解決策を生み出せる、1つの概念に焦点を当てた問いです。

フェーズ1の成果物：

• 問題定義（POV 形式）
• 根本原因（5 Whys または特性要因図）— 問題解決のみ
• ジョブストーリー3～5件
• HMW の問い5～10件

---

フェーズ2：機会の明確化 — ダイヤモンド1の収束

目標： 解決策のアイデア出しを行う前に、問題領域を最も機会の大きい重点領域へ絞り込みます。

2.1 — Opportunity Solution Tree（OST）— 機能強化向け

Teresa Torres のフレームワークです。望ましい成果 → 機会 → 解決策 → 実験を対応付けます。

Desired Outcome (business metric)
├── Opportunity 1 (unmet user need / pain / want)
│   ├── Solution A
│   └── Solution B
├── Opportunity 2
│   ├── Solution C
│   └── Solution D
└── Opportunity 3 (deprioritized)

ステップ1： 望ましい成果を1つ明示します（チームが責任を持つ遅行指標。例：「レビューのプロセスに対するマネージャーの満足度を、CSAT 3.2 から 4.0 に引き上げる」） ステップ2： 調査やインタビューから得られた、既知の機会（不満、ニーズ、要望）をすべて対応付けます。 ステップ3： 有望な機会ごとに、解決策の方向性を作成します（まだ詳細な解決策にはしません）。 ステップ4： フェーズ3でさらに検討する機会を1～2件選びます。

2.2 — Lean Canvas — 新製品向け

新規事業のアイデアを整理する1ページのビジネスモデル（Ash Maurya）：

項目	問い
問題	解決する主な問題3つ
顧客セグメント	誰がこの問題を抱えていますか？アーリーアダプターは誰ですか？
独自の価値提案	説得力のあるメッセージを1つ
解決策	主な機能3つ（仕様書全体ではありません）
チャネル	顧客にどのようにリーチしますか？
収益源	どのように収益を得ますか？
コスト構造	固定費＋変動費
主要指標	成功を測る数値を1つ
競争優位性	簡単には模倣できないものは何ですか？

主要なターゲットセグメントごとにキャンバスを1つ作成します。所要時間は20分以内にします。大切なのはスピードです。

2.3 — ブルーオーシャン ERRC グリッド — 機能強化または新製品向け

Eliminate-Reduce-Raise-Create グリッド（Chan Kim & Mauborgne）：

排除	削減
ユーザーが使わない機能	過剰に作り込まれた機能
高める	創造する
ユーザーがさらに求める機能	競合他社が提供していない機能

ルール： すべてのイノベーションには、Create に少なくとも 1 つ、Eliminate に少なくとも 1 つの項目が必要です。Raise の項目だけの製品は漸進的な改善にとどまり、差別化されていません。

2.4 — バリュープロポジション・キャンバス

顧客プロフィールと製品価値を結び付けます。

顧客プロフィール：

• ジョブ（機能的、社会的、感情的）
• ペイン（不満、障害、リスク）
• ゲイン（便益、願望、成功の尺度）

バリューマップ：

• 製品とサービス（提供するもの）
• ペインリリーバー（ペインを軽減する方法）
• ゲインクリエーター（ゲインを生み出す方法）

適合性 = ペインリリーバーがペインに合致し、ゲインクリエーターがゲインに合致する領域です。

フェーズ 2 の成果物：

• 2 つの選定済み機会を含む OST（機能強化）
• リーンキャンバス（新製品）
• ERRC グリッド（新製品または機能強化）
• バリュープロポジションの適合性評価

---

フェーズ 3：アイデア創出 — ダイヤモンド 2 の発散

目標： 判断を加えずに、解決策のアイデアを最大限に生み出します。品質はフェーズ 4 で高めます。

重要なルール： このフェーズでは評価を一切行いません。すべてのアイデアが有効です。「はい、そして……」で進め、「はい、でも……」とは言いません。

3.1 — SCAMPER

各視点を問題／既存製品に適用し、解決の方向性を生み出します。

文字	問いかけ	注文の優先順位付け機能の例
Substitute（代用）	何を置き換えられますか？	手作業での並べ替えを AI 支援による順位付けに置き換える
Combine（結合）	何を統合できますか？	ステータス、履歴、SLA リスクを 1 つの画面にまとめる
Adapt（応用）	何を借用できますか？	Netflix のレコメンデーションを応用して、優先注文を表示する
Modify（修正）	何を拡大または縮小できますか？	レビューキューを、毎日の優先順位チェックに縮小する
Put to other use（転用）	別の状況で使えますか？	注文履歴を補充の推奨に活用する
Eliminate（排除）	何をなくせますか？	夜間バッチをなくし、継続的なシグナルに置き換える
Reverse（逆転）	プロセスを逆にできますか？	注文を後続段階へプッシュする代わりに、後続段階から注文を取得する

SCAMPER の各文字につき少なくとも 2 つのアイデアを生成します。合計で最低 14 個のアイデアになります。

3.2 — クレイジー 8（迅速な視覚的アイデア創出）

時間制限：8 分。アイデア 8 個。洗練はしません。

手順：

1. 紙を 8 つの区画に折ります（または、頭の中で 8 つの枠を作ります）
2. 各枠にアイデアのコンセプトを 1 つスケッチします。大まかで構いません
3. タイマーを使い、完璧さよりも量を優先します
4. スケッチを共有し、それをもとにアイデアを広げます

AI が進行するセッションの場合：

• AI が 2 分で、互いに異なる解決の方向性を 8 つ生成します
• ユーザーが上位 3 つを選び、さらに掘り下げます
• 各方向性は、1 文と 1 つの主要な差別化要素で構成されます

3.3 — ブレインライティング 6-3-5

複数の関係者が参加するセッション向け（非同期にも適しています）：

• 参加者 6 人、各自がアイデアを 3 つ、5 ラウンド実施します
• 各ラウンドでは、前のアイデアを読み、新しいアイデアを 3 つ追加するか、既存のアイデアを発展させます
• 結果：30 分で最大 108 個のアイデアを創出できます（共有ドキュメントを使えば非同期でも実施できます）

AI が進行するセッションの場合：

• AI が 3 ラウンドにわたり、6 つの役割をすべて担います
• PO、BA、エンドユーザー、開発者、運用担当者、ビジネス担当者の各視点からアイデアを生成します

3.4 — インパクトマッピング

Gojko Adzic の手法です。目標 → アクター → 影響 → 成果物をマッピングします。

GOAL: [business outcome with measurable target]
├── ACTOR: Who can help/hinder?
│   ├── IMPACT: How should behavior change?
│   │   └── DELIVERABLE: What feature produces this impact?
│   └── IMPACT: What negative behavior to prevent?
│       └── DELIVERABLE: What reduces this risk?
└── ACTOR: ...

重要な洞察： 目標から逆算します。成果物がアクターの行動変化につながらない場合、それを構築してはいけません。

3.5 — 類推思考

「[業界 X] では、[類似の課題 Y] をどのように解決していますか？」

類推元	人事への応用
Spotify Discover Weekly	パーソナライズされた学習のおすすめ
Uber surge pricing	ボーナスプールの動的な配分
GitHub PR reviews	根拠に基づく同僚からのスキル推薦
Amazon recommendation engine	次の目標の提案
Netflix "because you watched"	「あなたのような同僚も達成しています…」

フェーズ 3 の成果物：

• 14 個以上のアイデアを含む SCAMPER グリッド
• Crazy 8s — 8 つのソリューションの方向性
• インパクトマップ（上位 2 つの目標）
• 類推から着想を得たアイデア（3～5 個）
• アイデアの総数（未整理）：目標 25～40 個

---

フェーズ 4：評価と収束 — ダイヤモンド 2 の収束

目標： 未整理のアイデア 25～40 個を、仮説検証のための優先順位付き候補 3～5 個に絞り込みます。

4.1 — ドット投票（第 1 ラウンド）

スコアリングの前に、直感で素早くふるいにかけます。

• 各アイデアに ✅（残す）／❌（除外）／🔄（別のアイデアと統合）のいずれかを付けます
• ほぼ同一のアイデアを統合します
• 厳格な制約（予算、技術、法務）に違反するアイデアを除外します
• 目標：候補を 10～15 個に絞ります

4.2 — RICE スコアリング

残りの候補に順位を付けます。

RICE Score = (Reach × Impact × Confidence) / Effort

Reach:      Users affected per quarter (100 / 500 / 1000 / 5000+)
Impact:     0.25 minimal | 0.5 low | 1 medium | 2 high | 3 massive
Confidence: 0.5 low (gut feel) | 0.8 medium (some data) | 1.0 high (validated)
Effort:     Story Points — 1 trivial | 3 small | 5 medium | 8 large | 13 very large

候補 10～15 個すべてにスコアを付け、降順に並べ替えます。上位 5 個を最終候補とします。

4.3 — カノモデルによる分類

最終候補の各アイデアを分類します。

カテゴリ	説明	不在の場合	存在する場合	例
必須品質	基本的な期待	ユーザーは不満を感じる	ユーザーは中立的	ログインが機能する
性能品質	多いほど良い	ユーザーは不満を感じる	ユーザーは満足する	読み込みが速い
魅力品質	予想外の価値	ユーザーは中立的	ユーザーは喜ぶ	スマートな提案
無関心品質	重要ではない	ユーザーは中立的	ユーザーは中立的	アイコンの色
逆品質	欲しい人もいれば、望まない人もいる	一部のユーザーは不満を感じる	一部のユーザーは満足する	自動入力

戦略： 必須品質 → 性能品質 → 魅力品質の順に対応します。必須品質を飛ばして魅力品質に取り組んではいけません。

4.4 — 労力 × インパクトの 2×2 マトリクス

視覚的に素早く分類します。

HIGH IMPACT
    │  Quick Wins ★    │  Major Projects ⚙️
    │  (do first)      │  (schedule carefully)
────┼──────────────────┼────────────────────
    │  Fill-Ins 📋     │  Money Pits ⚠️
    │  (if time)       │  (avoid or cut)
LOW IMPACT
         LOW EFFORT         HIGH EFFORT

最終候補の各アイデアをプロットします。戦略上の必要性がない限り、まずクイックウィンを優先します。

4.5 — リリース範囲の MoSCoW 分類

最終候補の各アイデアに、リリース優先度を割り当てます。

優先度	意味	基準
必須	これがないと MVP が成り立たない	価値の 80％超がこれに依存する場合は含めます
実装すべき	重要だが、なくても MVP は機能する	RICE が中央値を上回る場合は含めます
実装してもよい	あれば望ましいが、除外するリスクは低い	労力が 3 SP 以下の場合は含めます
今回は実装しない	今回のサイクルでは明示的に対象外	将来のために記録します

フェーズ 4 の成果物：

• ドット投票で絞り込んだ候補（10～15 個）
• RICE スコアリング表（順位付き上位 5 個）
• 最終候補それぞれのカノモデル分類
• 2×2 マトリクスへの配置
• 各アイデアの MoSCoW 分類

---

フェーズ 5：仮説の検証

目標： 開発を決定する前に、最もリスクの高い前提を検証します。スタートアップの 42％は市場ニーズがないために失敗します。開発前に検証しましょう。

5.1 — 課題の仮説

**We believe** [target users/persona]
**Experience** [specific problem]
**Because** [root cause]
**We'll know this is true when** [validation metric/observable evidence]

例：

We believe Operators
Experience frustration identifying high-priority orders during peak backlogs
Because order data is fragmented across 3 systems with no unified ranking
We'll know this is true when 3+ operators confirm they spend >2hrs per shift on manual data aggregation

5.2 — 価値の仮説

**We believe** [feature/solution]
**Will deliver** [specific value/outcome]
**To** [target users]
**We'll know we're right when** [measurable success metric]

5.3 — 最もリスクの高い仮説の検証（RAT）

失敗するとアイデアが成り立たなくなる仮説を1つ特定します。

1. すべての仮説を列挙します：ユーザーの行動、技術的な実現可能性、市場の需要、ビジネスモデル
2. 各仮説を評価します：誤っている確率（0–1）× 誤っていた場合の影響（0–1）
3. スコアが最も高いものを、最もリスクの高い仮説とします。
4. 本格的な開発に着手する前に、仮説を検証または否定するための、可能な限り低コストなテストを設計します。
   • ユーザーインタビュー（2～3日）
   • ランディングページ／フェイクドアテスト（1週間）
   • プロトタイプのクリック操作テスト（3～5日）
   • コンシェルジュMVP（1～2週間）
   • スモークテスト／先行販売（2～4週間）

5.4 — 構築・計測・学習のループ

上位の各アイデアについて、ループを定義します。

BUILD: Minimum experiment to test the assumption (not a full product)
MEASURE: One metric that proves/disproves the hypothesis
LEARN: What decision do we make if metric is met / not met?
PIVOT: If hypothesis invalidated — which alternative from Phase 3 do we try next?

フェーズ5の成果物：

• 上位3つのアイデアごとの課題仮説カード
• 上位3つのアイデアごとの価値仮説カード
• 各アイデアで最もリスクの高い仮説を特定
• 最も低コストなテストを設計
• 構築・計測・学習のループを定義

---

フェーズ6：意思決定と推奨事項

目標： トレードオフを示し、明確で確固とした推奨事項を提示します。「選択肢をすべて示す」のではなく、「何を、なぜ推奨するのか」を示します。

6.1 — 上位3つの選択肢の表

最終候補を意思決定表として提示します。

選択肢	RICE	カノモデル	工数	リスク	RATテスト	推奨
選択肢A	320	魅力的品質	5 SP	中	3日間のインタビュー	⭐ 推奨
選択肢B	180	一元的品質	8 SP	低	プロトタイプ	実行可能
選択肢C	90	当たり前品質	13 SP	高	先行販売	保留

6.2 — 推奨事項

RECOMMENDED: [Option Name]

Why: [1–2 sentences on RICE + Kano + strategic fit]
Risk: [Primary risk + mitigation]
First step: [Cheapest test to validate before full commitment]
Time to validation: [Days/weeks]

6.3 — 依存関係と順序の確認

• 選択肢Aは、まだ構築されていない既存の機能／データ／サービスに依存していますか？
• 実験を並行して実施できますか？
• 最初に検証済みの学びを得るまでのクリティカルパスは何ですか？

---

複数機会の発見モード

入力が複数の異なる機会にまたがる、未加工の製品ビジョン／問題提起である場合に、フェーズ 0.1 で選択します。 これは追加モードであり、置き換えではありません。その他のすべてのシナリオでは、フェーズ 6 の単一推奨がデフォルトのままです。

使用する場合： ユーザーから、複数の異なる独立してリリース可能な機会が想定される、幅広いビジョン、問題提起、または「この領域全体を探索してほしい」という概要が渡され、それぞれの機会を後続工程で独自の PBI にする必要がある場合です。これが workflow-idea-to-pbi の 複数機会の発見モード が実現するモードです。

収束の違い（決定的な違い）： デフォルトのフローは、意見を明確にした単一の推奨案（フェーズ 6）に収束します。このモードではそうしません。代わりに、同じ収束手法（フェーズ 4 の RICE／Kano／2×2）を使い、単一の最有力案を選ぶのではなく、3～8 件の異なる機会を順位付けして提示します。その後、ユーザーが開発する機会を複数選択します。ここで最有力案を 1 つ選ぶと、後続ワークフローが作成する他の PBI が失われます。

手法の流れ： フェーズ 1～4 を通常どおり実行します（問題の明確化 → 機会の明確化 → アイデア創出 → 収束）。ただし、フェーズ 2 では JTBD／Opportunity Solution Tree を活用して、単一の重点領域ではなく機会の全体像を明らかにします。また、フェーズ 4 では RICE／Kano／2×2 を使って、最有力の推奨案に絞り込むのではなく、異なる機会をすべて評価して順位付けします。

出力の要件（workflow-idea-to-pbi が消費する内容と一致する必要があります）：

• RICE でスコアを付け、RICE の高い順に並べた、3～8 件の異なる機会の機会マップ。
• plans/{plan-dir}/brainstorm-opportunity-map.md に記録します。
• 各機会には、問題／価値を一行で表す説明、RICE の構成要素（Reach × Impact × Confidence / Effort）と RICE スコア、さらに判明している場合は Kano クラスを記載します。これにより、それぞれを後続の PBI の起点にできます。

# Opportunity Map: [Vision/Problem]

| Rank | Opportunity | Problem/Value (1 line) | Reach | Impact | Confidence | Effort | RICE | Kano      |
| ---- | ----------- | ---------------------- | ----- | ------ | ---------- | ------ | ---- | --------- |
| 1    | ...         | ...                    | 1000  | 2      | 0.8        | 5      | 320  | Delighter |
| 2    | ...         | ...                    | ...   | ...    | ...        | ...    | ...  | ...       |

複数選択での引き継ぎ： multiSelect: true を指定してユーザーに直接「どの機会を PBI に展開しますか？」と尋ね、順位付けしたマップを提示します。選択された機会は、workflow-idea-to-pbi の機会ごとの PBI ループに進みます（選択された各機会について、アイデア → 詳細化 → レビュー → ストーリー → チャレンジ → DoR → モックアップを実施し、最後に PBI を横断して優先順位を付けます）。このスキル内で PBI、仕様、または計画を作成しないでください。発見モードの成果物は、スコア付けされ、複数選択された機会マップのみです。

---

フェーズ 7：ドキュメント作成と引き継ぎ

レポート出力

注入されたコンテキストの ## Naming セクションにある命名パターンを使用します。

Markdown の要約レポートを作成します。

# Brainstorm Session Report: [Topic]

## Session Context

- Scenario: [Problem-Solving / New Product / Enhancement]
- Role: [PO / BA / Mixed]
- Date: [YYYY-MM-DD]
- Input: [Original question/problem]

## Problem Statement

[POV format]

## Root Cause Analysis

[5 Whys or Fishbone — if Problem-Solving]

## Job Stories

1. [Job Story 1]
2. [Job Story 2]
3. [Job Story 3]

## HMW Questions

1. How might we...
2. How might we...

## Opportunity Map

[OST or Lean Canvas — per scenario]

## Raw Ideas Generated

[Total count: XX ideas across SCAMPER / Crazy 8s / Impact Mapping]

## Scored Shortlist (RICE)

| Rank | Idea | RICE | Kano | Effort | Priority    |
| ---- | ---- | ---- | ---- | ------ | ----------- |
| 1    | ...  | ...  | ...  | ...    | Must Have   |
| 2    | ...  | ...  | ...  | ...    | Should Have |

## Hypothesis Cards

### Top Recommendation: [Option Name]

- Problem Hypothesis: ...
- Value Hypothesis: ...
- Riskiest Assumption: ...
- Cheapest Test: ...
- Success Metric: ...

## Decision

[Recommendation + rationale]

## Next Steps

- [ ] [First concrete action]
- [ ] [Validation test]
- [ ] [Stakeholder alignment needed]

---

手法クイックリファレンス

手法	フェーズ	使用するタイミング	時間枠
POV ステートメント	P1	常に	10 分
5 Whys	P1	問題解決のシナリオ	15 分
フィッシュボーン	P1	全体的／複雑な問題	20 分
JTBD／ジョブストーリー	P1	新製品または機能強化	20 分
HMW の問い	P1	常に — 問題からアイデア創出への橋渡し	15 分
オポチュニティ・ソリューション・ツリー	P2	機能強化のシナリオ	30 分
リーンキャンバス	P2	新製品のシナリオ	20 分
ブルー・オーシャン ERRC	P2	差別化が必要な場合	20 分
バリュープロポジションキャンバス	P2	プロダクト・マーケット・フィットが不明確な場合	25 分
SCAMPER	P3	常に — 構造化されたアイデア創出	30 分
Crazy 8s	P3	短時間で多くのアイデアが必要な場合	8 分
ブレインライティング 6-3-5	P3	複数の関係者が参加し、非同期で行う場合	30 分
インパクトマッピング	P3	成果を起点に考える場合	30 分
類推思考	P3	新規性や創造性のある方向性が必要な場合	15 分
ドット投票	P4	最初の候補絞り込み	10 分
RICE スコアリング	P4	優先順位付けでは常に使用	20 分
カノモデル	P4	機能の分類	15 分
2×2 労力／インパクト	P4	視覚的なトリアージ	10 分
MoSCoW	P4	リリース範囲の設定	15 分
問題仮説	P5	コミットする前に常に使用	15 分
価値仮説	P5	コミットする前に常に使用	15 分
最もリスクの高い仮定のテスト	P5	本格的な構築の前	20 分
構築・計測・学習	P5	リーンな検証	20 分

---

役割別ガイダンス

PO モード（成果重視）

• 最初に扱う内容：望ましいビジネス成果 → 機会 → 実験
• 使用する手法：OST、インパクトマッピング、RICE、構築・計測・学習
• 問いかける内容：「ユーザーにどのような行動変容が見られる必要がありますか？」
• 避けること：成果を検証する前に機能の検討へ飛びつくこと

BA モード（要件重視）

• 最初に扱う内容：ステークホルダーのニーズ → プロセスのギャップ → 要件
• 使用する手法：BABOK の引き出し手法（インタビュー、ワークショップ、文書分析）、フィッシュボーン、JTBD
• 問いかける内容：「その行動を可能にするために、システムには何が求められますか？」
• 避けること：PO が機会を検証する前に、仕様を細かく定めすぎること

PO + BA 混合モード

• PO の担当：問題の定義、機会の枠組み設定、優先順位付け、仮説
• BA の担当：要件の引き出し、受け入れ基準、エッジケース、プロセスマッピング
• 引き継ぎのタイミング：フェーズ 4（スコア付け済みの候補リスト）の後 → BA が各アイデアの受け入れ基準を作成

---

コラボレーションツール

• planner エージェント — 特定のドメインにおける業界のベストプラクティスを調査する
• docs-manager エージェント — 既存機能の制約とドメインのコンテキストを把握する
• WebSearch — 新製品のシナリオにおける市場／競合のコンテキストを把握する
• docs-seeker スキル — 外部プラグイン／API の最新ドキュメントを確認する
• visual analysis tooling スキル — ビジュアルモックアップ、スクリーンショット、競合の UI を分析する
• sequential-thinking スキル — 因果関係を構造化して複雑な問題を分解する
• web-research スキル — 新規開拓市場や競合分析に関する詳細な市場調査を行う

---

シナリオ別チートシート

シナリオ A：問題解決

1. POV Statement → 2. 5 Whys / Fishbone → 3. HMW Questions
→ 4. SCAMPER on current solution → 5. RICE scoring
→ 6. Problem Hypothesis + RAT → 7. Recommend + cheapest test

シナリオ B：新製品

1. Job Stories (JTBD) → 2. Lean Canvas → 3. Blue Ocean ERRC
→ 4. HMW Questions → 5. Crazy 8s / Brainwriting
→ 6. Kano Classification → 7. Value Hypothesis + RAT → 8. MVP scope

シナリオ C：機能強化

1. Job Stories (JTBD) → 2. Opportunity Solution Tree
→ 3. HMW Questions → 4. SCAMPER on existing feature
→ 5. Impact Mapping → 6. RICE scoring → 7. 2×2 matrix
→ 8. Value Hypothesis + RAT → 9. Recommend + next experiment

シナリオ D：複数の機会の発見

1. Job Stories (JTBD) → 2. Opportunity Solution Tree (FULL landscape, not one focus)
→ 3. HMW Questions → 4. SCAMPER → 5. RICE-score EVERY opportunity
→ 6. Rank into a 3–8-item opportunity map (do NOT pick ONE)
→ 7. Write plans/{plan-dir}/brainstorm-opportunity-map.md
→ 8. ask the user directly multiSelect → hand selected opportunities to the per-opportunity PBI loop

**A/B/C との主な違い：**複数選択できる、順位付けされたマップに収束させ、単一の推奨案は提示しません。詳しくは複数の機会の発見モードを参照してください。

---

避けるべきアンチパターン

アンチパターン	失敗する理由	より良いアプローチ
問題を定義する前に解決策に飛びつく	間違ったものを作ってしまいます	必ず最初にフェーズ 1 を完了します
アイデアを出しながら評価する	創造的な発想を妨げ、早々に結論を出してしまいます	発散と収束を厳密に分けます
ステークホルダーの視点が 1 つだけ	ジョブ、ペイン、コンテキストを見落とします	6 つの異なる役割からブレインライティングを行います
構築前に仮説を立てない	機能の 42% は失敗します。市場のニーズがないためです	常に仮説と RAT を記述します
信頼度スコアなしで RICE を使う	根拠の乏しいアイデアを過大評価します	必ず信頼度を乗数として含めます
カノー分析を無視し、魅力品質だけを構築する	必須品質が壊れていると、ユーザーは魅力品質を利用できません	必須品質 → 一元的品質 → 魅力品質の順に優先します
検証テストなしで「最良のアイデアが勝つ」とする	HiPPO バイアス（最も給与の高い人の意見）	上位のアイデアにはすべて RAT テストの設計が必要です
アイデア創出でスコープが膨らむ	チームが検証できる範囲を超えてアイデアが膨らみます	各フェーズに厳密な時間制限を設けます
RICE スコアを最終的な真実として扱う	RICE は方向性を示すものであり、正確な指標ではありません	RICE、カノー分析、戦略的コンテキストを組み合わせて使います

---

重要な制約

• 解決策を実装しないでください — ブレインストーミングと助言のみを行います
• アプローチを支持する前に、必ず仮説を検証してください
• 短期的な利便性よりも、長期的な保守性を優先してください
• 技術的な卓越性とビジネス上の現実性の両方を考慮してください
• スコア付きの順位付けされた候補リストを作成してください — 単なるアイデアの一覧にはしません
• 最も低コストの検証テストを必ず設計してください — 詳細仕様の前に RAT を行います

---

ワークフローとの連携

ブレインストーミングセッションが終了したら、ユーザーに直接尋ねて次のステップを提示します。

次のステップ	該当する場合	スキル／ワークフロー
$idea	上位のアイデアをバックログ項目として記録する	idea スキル
$refine	上位のアイデアを AC 付きの実行可能な PBI にする	refine スキル
$web-research	まず市場や競合についてさらに詳しく調査する必要がある	web-research スキル
$plan	問題が明確で、解決策が検証済みであり、実装の準備ができている	plan スキル
$design-spec	UI 主体のアイデアで、仕様作成前にワイヤーフレームが必要	design-spec スキル
$domain-analysis	アイデアがドメインエンティティに関わり、まずモデルが必要	domain-analysis スキル
ブレインストーミングを続ける	さらに検討するシナリオがある	このセッションを続ける

**複数の機会の発見からの引き継ぎ：**発見モードで実行する場合、次のステップを 1 つだけ選んではいけません。代わりに、ユーザーに直接 multiSelect: true を使って尋ね、順位付けされた 3～8 件の RICE 機会マップ（plans/{plan-dir}/brainstorm-opportunity-map.md に書き込まれます）を提示してから、選択された機会を workflow-idea-to-pbi の機会ごとの PBI ループに引き継ぎます。workflow-idea-to-pbi はこの機会マップを直接使用します。

---

［重要］ 作業を始める前に、タスク管理を使ってすべての作業を小さなタスクに分割してください。これにより、長時間のセッションによるコンテキストの喪失を防げます。

---

AI のミス防止 — すべてのタスクで避けるべき失敗パターン：

コンテキストが変わったらファイルを読み直す。 コンテキストの圧縮、中断後の再開、長時間にわたる作業により、記憶が古くなることがあります。作業に取りかかる前に、ファイルの現在の状態を確認してください。 生成した内容をソースの根拠と照合する。 AI は API、名前、主張、文書の事実を幻覚することがあります。文書化または参照する前に、関連するソースを確認してください。 削除や名前変更の前に、下流の参照を確認する。 成果物を削除すると、ドキュメント、生成されたミラー、設定、呼び出し元が古くなることがあります。まず参照関係を把握してください。 編集後は影響範囲全体をたどる。 定義を変更すると、派生出力や利用側への影響を見落とすことがあります。完了と判断する前に、影響を受ける一連の流れを確認してください。 最初の出力だけでなく、影響を受けるすべての出力を確認する。 チェックが1つ成功しても、すべてのチェックが成功したことにはなりません。変更によって影響を受ける可能性のある出力面をすべて検証してください。 既存の値には意図があると考え、変更または不具合として指摘する前に、なぜそうなっているのかを確認する。 定数、上限、フラグ、しきい値、文言、パターンを変更または指摘する前に、周辺のコンテキストと履歴、呼び出し元の処理順序、同じ慣例を使う2つ以上の類似した呼び出し箇所を確認してください。理由を示さずに内容だけを記したドキュメントは、根拠が不足しているのではなく、理由の説明が不足しています。 曖昧さを見つけたら、行動する前に明らかにする。黙って解釈を決めない。 複数の妥当な解釈がある場合は、明示的に質問するか、リスクを添えて前提を示してください。 インフラが管理する中間状態ではなく、システムが担保する結果を検証する。 非同期処理を検証する際は、配信や再試行の記録ではなく、最終的な業務状態を確認してください。こうした記録は共有インフラ上で同時に実行されるどのプロセスからも書き換えられるため、その確認は単独で実行すると成功しても、ほかの処理が同じインフラを共有した途端に不安定になります。 共有ガイダンスは、対象となる役割に関連する内容にする。 共通ガイダンスは、それを受け取るすべてのスキルやエージェントに役立つものでなければなりません。コード固有の要件は、コード固有の手順にのみ記載してください。

批判的思考の姿勢 — 批判的かつ順序立てて考えてください。行動する際は、すべての主張に追跡可能な根拠があり、確信度が80％を超えている必要があります。 幻覚の防止： 推測を事実として示さないでください。すべての主張に出典を示し、不確実性は率直に認め、出力に誤りがないか自ら確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそ、あらゆる幻覚の根源です。 逐次思考プロトコル — 複雑または曖昧な作業に向けた、構造化された多段階の推論です。一度きりの推論では安全でない、計画、レビュー、デバッグ、アイデアの洗練に使用してください。

次の場合に使用: 複雑な問題の分解 · 見直しが必要な適応型計画 · 軌道修正を伴う分析 · 不明確または発展途上の範囲 · 多段階の解決策 · 仮説主導のデバッグ · 分野横断的なトレードオフの評価。

形式（明示モード — 思考の過程を可視化）:

1. Thought N/M: [aspect] — 1つの思考につき1つの側面を扱い、前提や不確実性を明示します
2. Thought N/M [REVISION of Thought K]: ... — 以前の推論が無効になった場合に使用します。元の内容／修正理由／影響を明示します
3. Thought N/M [BRANCH A from Thought K]: ... — 代替案を検討し、判断理由を示して収束させます
4. Thought N/M [HYPOTHESIS]: ... の後に [VERIFICATION]: ... — 実行前に検証します
5. Thought N/N [FINAL] — 検証済みで、重要な側面にすべて対処し、確信度が80%を超えた場合にのみ使用します

必須の締めくくり: 確信度（%）を明記 · 前提を列挙 · 未解決の質問を提示 · 次の具体的なアクションを示す。

停止条件: 重要な判断の確信度が80%未満 → ユーザーに直接質問してエスカレーションする · 同じ思考に対する修正が3回以上 → 問題を再定義する · 分岐が3つを超える → サブタスクに分割する。

暗黙モード: マーカーを付けると回答が煩雑になる場合（推論が精度向上に役立つ定型作業など）は、内部で方法論を適用します。

詳細: $sequential-thinking スキル（.claude/skills/sequential-thinking/SKILL.md）では、実例（API 設計、デバッグ、アーキテクチャ）、高度な手法（段階的な洗練、仮説検証、収束）、メタ戦略（不確実性への対処、修正の連鎖）を確認できます。

必ず注意すること 批判的思考と逐次思考を適用してください — すべての主張には、適切な根拠の追跡情報を付けてください（リポジトリ／コードに関する主張には file:line、調査、製品、コンテンツ、ドキュメントに関する主張にはソース URL または成果物内のセクション）。確信度が80%を超える場合にのみ行動し、60%未満の場合は推奨しないでください。ハルシネーションを防止してください。推測を事実として示さず、不確実性は率直に認め、独立した情報源と照合し、自分の確信度を懐疑的に見直してください。

必ず注意すること 逐次思考を適用してください — 複数段階の Thought N/M、REVISION／BRANCH／HYPOTHESIS マーカー、確信度（%）の締めくくりを使用してください。$sequential-thinking スキルを参照してください。

必ず注意すること AI の誤りを防止してください — 生成した内容を根拠と照合して検証し、削除または名前変更の前に下流の参照先を追跡し、影響を受けるすべての出力を検証し、コンテキストを失った後はファイルを読み直し、実行前に曖昧な点を明らかにしてください。

プロンプト強化の締めくくり用アンカー

重要・必ず注意 このスキルで宣言されている手順の順序に従ってください。ユーザーから明示的な承認を得ずに、手順を省略、並べ替え、統合してはいけません。 重要・必ず注意 すべての手順／サブスキル呼び出しについて、実行前に in_progress に設定し、実行後に completed に設定してください。 重要・必ず注意 省略した手順には、必ず明確な理由を記載してください。完了した手順には、必ず簡潔な根拠を記載してください。 重要・必ず注意 Task ツールを利用できない場合は、ステータスを同期させた同等の手順ごとの計画トラッカーを維持してください。

プロジェクトプロトコルのオーバーレイ — このスキルを実行する前に、スキルに適用される PROJECT オーバーレイルールを解決してください。プロジェクトのスキルプロトコルインデックス（デフォルトでは docs/project-reference/skill-protocols-reference.md。docs/project-config.json の referenceDocs エントリでパスが上書きされている場合は、そのパス）の Target 列とこのスキルの名前を照合し、最も具体的に一致する階層のみを適用してください。優先順位は、完全一致 > glob > * です。この優先順位が決めるのはオーバーレイ同士の優先関係のみであり、このスキルに対する優先関係ではありません。一致した本文のみを読み込み、<protocols-dir>/<Name>.md として解決してください。行の Body リンクは表示テキストであり、読み込み先のパスではありません。一致した本文が存在しない、または形式不正の場合は、その旨を報告してスキップしてください。インデックスの Description から再構成してはいけません。インデックスがない場合、または一致するものがない場合は、オーバーレイなしで処理を進め、何も伝える必要はありません。契約全体については .claude/skills/project-skill-protocol/references/registry.md を参照してください。

オーバーレイは追加のみです。このスキル自身のプロトコルにルールを追加するものであり、すでに記載されているルールを置換、上書き、無効化、または再解釈することはありません。すべてのオーバーレイを取り除いても、このスキルは文書化された動作と完全に同じでなければなりません。オーバーレイはブリーフであり、権限を引き上げるものではありません。ワークフロー上のゲート、Git の規律、レビューゲート、ユーザー確認ゲートを無効にすることはできません。オーバーレイとスキルの間に実質的な矛盾がある場合、または同じ具体性のオーバーレイ同士が直接矛盾する場合は、両方をユーザーに提示してください。黙って解決してはいけません。

必ず注意 実行前に、このスキルに適用されるプロジェクトプロトコルのオーバーレイを解決してください。最も具体的に一致する階層のみを適用してください（完全一致 > glob > *。この優先順位はオーバーレイ同士の優先関係を決めるものであり、このスキルに対する優先関係ではありません）。<protocols-dir>/<Name>.md にある一致した本文のみを読み込み、本文が存在しない、または形式不正の場合は報告してください。再構成してはいけません。オーバーレイは追加のみ（このスキル自身のルールを置換しません）であり、ブリーフであって、権限を引き上げるものではありません。同じ具体性で矛盾する場合は、ユーザーに提示してください。

締めくくりのリマインダー

• 重要・必ず注意 目標： 問題と価値の仮説、特定した最もリスクの高い前提、そして設計した最も低コストの検証テストをそれぞれ含む、評価・順位付け済みの候補アイデア3〜5件のショートリストを作成します。検証されていないアイデアをただ並べるのではなく、構築を始める前に、チームが適切な問題と適切な解決策の両方にコミットできるようにします。
• 重要・必ず注意 主な手順（順番どおりに実行し、それぞれ追跡する）： P0 セッション設定（シナリオ＋役割＋既知情報を検出）→ P1 問題のフレーミング／発散（POV → 5 Whys／フィッシュボーン → JTBD → HMW）→ P2 機会のフレーミング／収束（OST／リーンキャンバス／ERRC／価値提案）→ P3 アイデア創出／発散（SCAMPER → Crazy 8s → ブレインライティング → インパクトマップ → 類推、25〜40件のアイデア）→ P4 評価／収束（ドット投票 → RICE → Kano → 2×2 → MoSCoW、ショートリスト3〜5件）→ P5 仮説検証（問題＋価値カード＋RAT＋最も低コストのテスト＋Build-Measure-Learn）→ P6 決定（推奨案は1つ）→ P7 文書化と引き継ぎ — 理由：このスキル固有のフェーズは、AIが最も忘れやすい手順です。各フェーズの前に、これらを再確認してください。

適用中のプロトコル（このスキルが引き継ぐ SYNC／共有ブロックの簡潔な要約）：

• AI の誤り防止： 生成したコンテンツを根拠と照合し、下流の参照をたどり、影響を受けるすべての出力を確認し、コンテキストを失った後は読み直し、曖昧さを明らかにします。

• 批判的思考： file:line による追跡可能な証拠を示します。行動する際は確信度を 80% 超とし、決して推測しません。

• 段階的思考： REVISION／BRANCH／HYPOTHESIS マーカーと、確信度を示す締めくくりを用いて、複数ステップの Thought N/M を行います。

• 必須・重要・必ず注意： まず Phase 0 でユーザーに直接質問し、シナリオ、役割、既知の情報量を把握します。シナリオごとに異なる手法の手順に進みます。理由：シナリオを誤分類すると、その後のすべてのフェーズが軌道を外れるためです。

• 必須・重要・必ず注意： 発散（Phases 1 & 3。生成、「そうですね、それに加えて…」、判断は一切しない）と収束（Phases 2 & 4。絞り込み＋採点）を分けます。アイデアを生成している間は、決して評価しません。理由：2 つのモードを混同すると、創造的な成果を損なう「黄金律」違反になるためです。

• 必須・重要・必ず注意： 生のアイデアリストや単なるアイデア一覧のままで終わることは決してありません。上位 3 件の候補にはそれぞれ、課題＋価値の仮説カード、特定された最もリスクの高い仮定（RAT）、そして構築に着手する判断をする前に設計した、最も低コストな検証テストを必ず含めます。理由：機能の 42% は市場ニーズがないために失敗するので、構築前に検証する必要があるためです。

• 必須・重要・必ず注意： 作業を小さな todo タスクに分解し、開始前にタスク追跡を使います。各タスクは完了したらすぐに completed と記し、最後にレビュー用 todo を追加します。理由：長時間のブレインストーミングでは、外部のタスク追跡なしにコンテキストを失うためです。

• 必須・重要・必ず注意： まず既存のパターンを 3 件以上検索します。アイデアを出す前に、対象領域がコードベースなら docs/specs/ を読み、市場や競合の状況を把握する場合（グリーンフィールド）なら WebSearch を使います。理由：領域や市場の証拠に根ざしていないアイデアは、適合性ではなく勘で評価されるためです。

• 必須・重要・必ず注意： あらゆる主張に根拠を示し、推奨する際の確信度は 80% 超とします。RICE の Confidence は乗数であり、省略できません。理由：根拠が乏しく Confidence スコアのないアイデアは、過大評価されるためです。

• 必須・重要・必ず注意： Phase 6 では、明確な見解を伴う推奨案を 1 つと、そのトレードオフを示して締めくくります。選択肢を並べるだけで終わってはいけません。理由：選択肢の羅列は判断をチームに押し戻し、HiPPO バイアスを招くためです。例外 — マルチ機会発見モード（Phase 0 で選択）：1 つに絞り込んではいけません。代わりに、3～8 件の項目からなる RICE 機会マップを順位付けして作成し、plans/{plan-dir}/brainstorm-opportunity-map.md に書き込み、ユーザーに直接 multiSelect: true と尋ねて、workflow-idea-to-pbi の機会ごとの PBI ループに引き継ぎます。理由：各機会は後続で個別の PBI になるため、1 つに絞ると、この発見ワークフローが作成するバックログが失われるためです。

• 必須・重要・必ず注意： ユーザーによるすべての意思決定と引き継ぎ先の選択（$idea、$refine、$plan）には、ユーザーに直接尋ねます。自動で決定してはいけません。理由：シナリオ、優先順位、次のステップを決めるのはユーザーだからです。

合理化を防ぐ：

回避策	反論
「シナリオは明らかなので、フェーズ 0 の検出は省略する」	シナリオを誤分類すると、誤った手法の順序に進みます。まずユーザーに直接尋ねてください。
「アイデアを列挙するだけでよい。評価は後回しにできる」	アイデアを羅列するだけでは、成果物として不十分です。上位 3 件を採点し、順位付けして、仮説を検証してください。
「RAT は省略する。アイデアが明らかに優れている」	「明らかに優れている」は HiPPO バイアスです。構築を決定する前に、最も低コストなテストを設計してください。
「時間を節約するため、発散と収束を同時に行う」	モードを混在させると創造的な成果が損なわれます。これは黄金律に反します。フェーズを分けてください。
「Confidence なしの RICE でも十分近い」	Confidence の乗数がないと、根拠の乏しいアイデアが過剰に高く評価されます。必ず Confidence を採点してください。
「この分野はすでに知っているので、コンテキストの読み込みは省略する」	docs/specs/ を読んだこと、または WebSearch の根拠を示してください。証拠がなければ、アイデア創出に根拠がありません。

必ず注意 シナリオ検出を最初に行うこと · 発散と収束を厳密に分けること · 上位 3 件の各アイデアに仮説 + RAT + 最も低コストなテストを含めること――この 3 点は長時間のセッションでも守る必要があります。推奨する前に、この 3 点を再確認してください。

フックレスプロンプトプロトコルミラー（自動同期）

ソース：.claude/.ck.json + .claude/skills/shared/sync-inline-versions.md（:full ブロック）+ .claude/scripts/lib/hookless-prompt-protocol.cjs

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・必ず遵守・重大。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとし、プロジェクト固有の規約は docs/project-config.json と docs/project-reference/ から確認します。共有 AI-SDD は shared/sdd-artifact-contract.md に従って適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクトリファレンスドキュメントを開いてください。仕様、テストケース、動作変更、公開コントラクト、または docs/specs/ に関する作業では、ドキュメントインデックスに記載されたローカルの仕様ドキュメント（feature-spec-reference.md、spec-system-reference.md、spec-principles.md、および仕様・テスト・コードの同期が必要な場合は workflow-spec-test-code-cycle-reference.md）を経由してください。いずれかのファイル、または必須のリファレンスドキュメントが見つからないか古くなっている場合は、通常のプロジェクト固有の作業に進む前に $project-init（または $project-config、$docs-init、$scan-all、$scan --target=<key> などの限定的な下位ルート）を自動実行してください。この共有コンテキストとローカルドキュメントが利用可能であれば、サポート対象の任意の AI ツールで実行できます。

1. 検出： プロンプトが明示的なスラッシュ形式のスキル／ワークフローコマンドで始まる場合は、それを直接実行します。それ以外の場合は、プロンプトをワークフローカタログとスキルリストに照らし合わせます。
2. 分析： 最適な方法を選択します。直接実行、スキルの呼び出し、標準ワークフローの開始、またはカスタムのステップ構成です。
3. 自動選択： 最適な方法を自分で選択します。直接実行、スキル、標準ワークフロー、カスタムワークフローのどれにするか、ユーザーに選択を求めてはいけません。
4. 開始： 選択したワークフローでは $start-workflow <workflowId> を呼び出します。選択したスキルではそのスキルを呼び出します。カスタムワークフローではカスタムステップを順に実行します。直接実行ではタスクに進みます。
5. タスクの作成： 選択した経路に複数のステップがある場合、実行前にすべてのワークフロー／スキル／カスタムステップについてタスクを追跡します。
6. 並列化： タスクリストの実行前に、各タスクに PAR（入力が独立しており、書き込み対象が他のすべての PAR タスクと重複しない）または SEQ（ブロックする依存関係を明記）を付け、PAR タスクをウェーブにグループ化し、ウェーブ計画を宣言して、各ウェーブのサブエージェントを1つのメッセージで起動します。各ウェーブでは全員の完了を待ち、サブエージェント自身の定義でさらなる並列化が認められている場合を除き、ファンアウトは1階層までとします。独立したタスクを逐次処理するのは不備です。共有の書き込み対象、出力を利用するタスク、単純な単一ファイルの作業、スキルやワークフローで順序が明示されている作業、ユーザー承認が必要な段階は並列化しないでください。
7. 実行： コンテキスト指示にある Workflow Step Advancement & Parallel Phases のルールに従って進めます。ステップの進行はモデル主導です。サブエージェントの完了はインライン呼び出しと同様にステップを進めます。並列フェーズのグループは全員の完了を待つバリアです（すべてのメンバーが完了した後にのみ進み、決して逐次化しません）。

共有 AI-SDD プロトコルマーカー

ソース：.claude/skills/shared/sync-inline-versions.md

SYNC:ai-sdd-artifact-contract

AI-SDD 成果物契約 — 共有する仕様駆動開発のルールは、移植可能な状態に保ち、ソース側で管理します。

1. 再利用可能な AI-SDD の原則は .claude に置き、リポジトリ固有のパス、コマンド、担当者、製品、形式はプロジェクト設定または参照ドキュメントに記載します。
2. サイクルを維持します：spec -> plan -> tasks -> implement -> verify -> update spec/docs。
3. すべての要件または不変条件を、判断、タスク、TC／テスト、ソースの根拠、ドキュメント／仕様の更新まで追跡します。
4. コードから仕様への抽出は、正規の仕様オーナーが承認するまでは参照専用として扱います。
5. 同期されたコンテキストがあれば、サポート対象の AI ツールで計画、実装、レビュー、検証を行えます。複数のツールを使うかどうかは任意です。
6. まず .claude のソースを更新してから、生成されたミラーを同期します。.agents、.codex、AGENTS.md を手動で編集しないでください。— 理由：ミラーは生成された成果物であり、次回の同期時に手動編集内容が上書きされます
7. docs/project-config.json、ルートの指示ファイル、または必須のプロジェクト参照ドキュメントが欠落しているか古い場合は、通常のプロジェクト固有の作業を行う前に、$project-init または適切な下位レベルの手順を自動実行します。

有効な参照先： アクティブなスキルルート内の shared/sdd-artifact-contract.md。

---

SYNC:ai-sdd-artifact-contract:reminder

• 必須 shared/sdd-artifact-contract.md を適用し、再利用可能な AI-SDD は .claude に、ローカルルールはプロジェクトのドキュメントに保持します。
• 必須 コードから仕様への抽出は、正規の承認を得るまで参照専用です。サポート対象の AI ツールであれば、同期されたコンテキストを使って実行できます。
• 必須 生成されたミラーを同期する前に .claude のソースを更新します。.agents、.codex、AGENTS.md を手動で編集しないでください。
• 必須 プロジェクト設定、ルートの指示ファイル、または必須の参照ドキュメントが欠落しているか古い場合は、プロジェクト固有の作業を $project-init または適切なセットアップ手順に自動的に振り分けます。 [TASK-PLANNING] [必須] ワークフローまたはスキルの手順を実行する前に、計画したすべての手順についてタスク追跡を作成／更新し、各手順の開始時と完了時に同期してください。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的な改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割して追跡します。最後のタスクに「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみを扱います：

1. 症状ではなく、失敗モード（推論や前提の誤り）を特定します。「間違った enum 値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を確認します。この失敗モードは 3 つ以上の状況／コードベースに当てはまりますか？当てはまらない場合は、もう一段階抽象化します。
3. 普遍的なルールとして記述します。プロジェクト固有の名前、パス、クラスを取り除きます。どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードに起因する複数のミスは、1 つの教訓にまとめます。
5. 再発ゲート：「このリマインダーがなければ、今後のセッションで再発するか？」いいえ → $learn は省略します。
6. 自動修正ゲート：「$code-review／$code-simplifier／$security-review／$lint で検出できるか？」はい → 代わりにレビュー用スキルを改善します。
7. 両方のゲートを通過した場合は、ユーザーに $learn の実行を依頼します。 [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。あらゆる主張に追跡可能な証拠を求め、行動する際は確信度を 80% 超とします。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実性を率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。証拠のない確信が、あらゆるハルシネーションの根本原因です。 AI の注意力の原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、最も重要なルールを上部と下部の両方に 3 つずつ配置し、長いコンテキストでも指示への準拠を維持します。 目標主導の実行： まず成功基準を定め、検証できるまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストは意図を検証します： テストは現在の動作をなぞるだけでなく、ビジネスルールや不変条件を保護し、保護対象の意図が崩れたときに失敗する必要があります。

よくある AI のミスを防ぐ（システムの教訓）

• コンテキスト圧縮後はファイルを再読込してください。 編集するには、同じコンテキスト内で事前に Read している必要があります。圧縮によって読込状態は消去されます。編集前に再読込してください。
• 一括置換後は古い用語を grep してください。 AI は検索・置換の完全性を過信します。一括編集後はリポジトリ全体を grep し、ドキュメント／設定／カタログに参照漏れがないか確認してください。
• 削除前に下流の参照を確認してください。 削除の影響は、ドキュメントやコードの陳腐化へ連鎖します。削除前に参照元ファイルを洗い出してください。
• 記憶を失った後、新しく作成する前に既存の状態を確認してください。 圧縮によってこれまでの作業の記憶が消去されます。作業を再開するときは現在の状態を確認し、決してむやみに重複作成しないでください。
• AI 生成コンテンツは実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントへの記載や参照の前に、grep して実在を確認してください。
• 編集後は依存関係を最後までたどってください。 定義を変更しても、その下流の利用箇所を見落とすことがあります。依存関係をすべてたどってください。
• 名前を変更するときは、利用側の全ファイル形式を grep してください。 ファイル形式によっては、参照先が見つからなくてもエラーなしで無視されます。コード、テンプレート、設定、生成ファイルを検索してください。
• 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することと、実行されることは同じではありません。正常系だけでなく、早期リターン、エラー分岐、条件によるスキップもたどってください。
• ソースが変わったら、正規データを埋め込んでいるドキュメントも更新してください。 派生データ（ワークフロー、スキーマ、設定など）を直接記載しているドキュメントは、気づかないうちに古くなります。ソースと合わせて、該当する埋め込みドキュメントをすべて更新してください。
• コンテキスト復旧後は、サブエージェントの結果を検証してください。 親エージェントが圧縮されている間にバックグラウンドエージェントが完了している場合があります。完了したはずだと信じず、出力を grep して確認してください。
• 対象の全一覧とサブエージェントへの割り当てを照合してください。 カテゴリごとにサブエージェントを並行実行すると、境界上の項目を見落とすことがあります。作業を進める前に、割り当ての和集合を対象一覧と照合してください。
• サブエージェントが引き継ぐ知識は、そのエージェントの .md 定義に書かれた内容だけです。組み込みの Explore ではなく、カスタムエージェント種別を使用してください。 ツールの採用には、権限＋知識＋適用（番号付きワークフロー手順）が必要です。
• サブエージェントの調査結果は最後にまとめてではなく、随時保存してください。 長時間実行されるサブエージェントは、最終書き込み前に打ち切られることがあり、調査結果が失われます。報告ファイルにセクションごとに追記するよう指示してください。
• デバッグ時は修正する前に「どちらの責任か」を確認してください。 呼び出し元（データが誤っている）と呼び出し先（処理が誤っている）をたどり、責任のある層を修正してください。症状が表れる箇所だけを修正してはいけません。
• テスト失敗時は、追跡や編集の前に暫定判定を記録してから調査してください。 次の 5 つの分類をすべて使ってください。SOURCE-WRONG（本番コードが意図に反している）、TEST-WRONG（アサーション／セットアップが古くなっている）、TEST-NOT-OPTIMAL（妥当だが脆弱、または情報量の少ないテスト）、ENVIRONMENT-BLOCKED（外部状態のため判定できない）、AMBIGUOUS（意図や証拠から安全に選べない）。その後、根本原因をたどり、適用される仕様（存在する場合は docs/specs/**）とソースの両方に照らして検証してください。成功を無理に得るために、アサーションを弱めたり、スキップを追加したり、タイムアウトを緩めたり、ソースを変更したりしてはいけません。
• 抽出／リファクタリング後は、削除した名前をすべて grep してください。 主要ファイルの作業完了は、他のファイルもクリーンであることを意味しません。完了を宣言する前に、対象範囲全体で削除したシンボルを一つずつ grep してください。
• 既存の値には意図があると考え、変更したり不具合だと指摘したりする前に、必ず理由を確認してください。 パターンマッチで「誤り」と決めつけると、背景を見落とします。定数／上限／フラグ／しきい値を変更または報告する前に、コメント、git blame、呼び出し元の処理順序（値を正しくする保証は、通常、該当行の直前に実行されるコードにあります）、同じ規約を使っている 2 つ以上の類似した呼び出し箇所を確認してください。理由なしに WHAT（何をするか）だけを記したドキュメントは、根拠が欠けているのではなく、WHY（なぜそうするか）の説明が不足しているということです。検証作業でも、正確な file:line の引用が証明するのは転記が正確であることだけであり、不具合の存在ではありません。
• 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 一つのビルドが成功しても、すべてが成功したとは限りません。複数のスタックにまたがる変更（バックエンド／フロントエンド／テスト／ドキュメント）では、すべての出力を検証してください。
• 近くにあるパターンをコピーする前に、適合性を評価してください。 最も近い例が適合するとは限りません。新しいコンテキストが同じ制約、基底クラス、スコープ、ライフタイムを共有するか確認してください。
• デバッグでは全体を優先し、目についた箇所に飛びつかないでください。 最初に思いついた原因へすぐ飛びつかないでください。前提条件（設定、環境変数、パス、DB、エンドポイント、認証情報、バージョン、DI、データ）をすべて列挙し、それぞれを証拠（推論ではなく grep／クエリ）に照らして検証してください。「何があればこの仮説は否定されるか？」と問い、何も答えられないなら、それは仮説ではありません。最もコストの高い失敗は、バグが一度も疑われていない層にあるのに、「明らか」だと思い込んだ層をさらに深掘りすることです。
• 変更は最小限にし、差分テストを適用してください（コンテキストに合わせて判断）。 2 つのモードがあります。（1）バグ修正 → すべての行がバグに直接関係するようにし、スタイル変更はしないでください。不要になったインポートを削除してよいのは、あなたの変更によって不要になったものだけです。（2）レビュー／機能強化 → 改善を実装し、「主な依頼を超える機能強化：[内容]」と明示してください。黙ってスコープを拡大しないでください。差分テスト：「X を依頼されていなかったとしても、この行は存在していたか？」いいえなら、削除するか明示してください。
• 実装前に曖昧さを明らかにし、黙って解釈を選ばないでください。 複数の妥当な解釈がある場合は、それぞれの工数とともに提示してください。「[依頼] は（1）[N 時間]、（2）[N 時間]のいずれかと解釈できます。どちらが重要ですか？」まずスコープ／形式／量／制約に関する前提を列挙してください。より簡単な方法がある場合は、そのことも伝えてください。黙って選ばないでください。
• [必須の最初のアクション] 応答する前に、必ず適切なスキルまたはワークフローを有効にしてください。 ワークフローカタログとスキル一覧に照らしてタスクを確認し、スキルの呼び出し、または $start-workflow <workflowId> で実行してください。確認する前に回答やコード作成をしてはいけません。省略はプロトコル違反です。
• Why-Review の敵対的な視点は、計画、判断、設計をレビューするときに適用してください。 基本姿勢は VALIDATOR（妥当性を確認する側）ではなく SKEPTIC（懐疑的な側）です。却下された代替案の最も強い論拠を組み立て、述べられた理由を一つずつ逆転させて「何を犠牲にするのか」を問い、上位 2～3 個の前提をストレステストし、プレモーテム（「リリースしたが 3 か月後に失敗した。何が壊れたのか？」）を行い、作成者が見落とした代替案を 1～2 個提示してください。セクションがあるだけでは十分ではありません。重要なのは、因果関係に基づく推論、具体的な軽減策、証拠です。「より良い」や「注意深く監視する」だけでは不十分です。
• 大規模なレビューでは、サブエージェントへのプロンプトで報告書の書き込みを最初に行わせてください。 多数のファイルを扱うサブエージェントは、最終書き込みの前に予算を使い切り、調査結果を失うことがあります。プロンプトは、（1）報告書の書き込みを最初に明示する成果物とする、（2）まとめてではなくファイル／セクションごとに追記する、（3）読み込みで予算を使い切らないようスコープを限定する、という構成にしてください。報告ファイルを残さず文の途中で打ち切られた場合は、同じプロンプトを再試行せず、より狭いスコープで再実行してください。
• コンテキスト圧縮後は、続行する前に以前の各フェーズの結果をすべて再検証してください。 要約が示すのは意図であり、環境の状態（git のインデックス、ファイルシステム、プロセス）ではありません。再開時はまず git status を確認し、変更したファイルを再読込し、ファイルシステムを検証してください。証拠で確認されるまでは、「完了した」という主張もすべて未検証の仮説です。
• OOM／メモリ：行サイズより先に行数を確認してください。 次の順にトリアージします。（1）上限のないクエリ — 条件を設定するトリガーとなる DB フィルターがありませんか？ DB 側にフィルターを移せば、OOM を解消できます。（2）行サイズが大きいですか？ プロジェクションを使えば比例して減らせます。費用対効果では、プロジェクションより行数削減が優先です。
• システムが担う最終結果をアサートし、インフラストラクチャが担う中間状態をアサートしないでください。 非同期処理（キュー／ブローカーへの配信、再試行、バックグラウンドジョブ、キャッシュ、レプリケーション）をテストする場合は、最終的なビジネス／エンティティの状態をアサートしてください。配信の記録、つまり消費／送信ステータス、試行回数、最終エラー、ブローカー、スケジューラー、outbox／inbox テーブル内の行の有無や件数をアサートしてはいけません。この記録は共有インフラストラクチャに存在し、並行して動く任意のプロセス（別のワーカー、2 つ目のレプリカ、残っているローカルコンテナー）から書き込めるうえ、通常は決定的な共有キーが使われます。そのため、こうしたアサーションは気づかないうちにシステムではなく開発者の環境をテストします。単独実行では成功しても、同じブローカー＋データベースをほかの何かが共有した途端に不安定になります。すべてのアサーションで、次の判定の問いを使ってください。「どのプロセスが処理しても、この結果は成り立つか？」いいえなら、代わりに収束後のデータ状態をアサートしてください。系として、プロセスローカルな障害注入やプロセス内テレメトリーを、任意のプロセスが実行する処理のゲートとして使うことはできません。負荷増幅に使ってください（有効化 → 範囲を限定した時間枠 → 無効化 → 収束をアサート）。前提条件として使ってはいけません。
• ドメイン概念を汎用／共有／インフラストラクチャ層に持ち込まないでください。 再利用可能な層（共有ライブラリ、フレームワーク、インフラモジュール）は、利用側に固有のドメイン概念（テナント／顧客／製品 ID、ビジネスエンティティ、機能ルール）を一切参照してはいけません。漏れがコンパイルされ、実行されると、再利用可能なはずの層が一つの利用側と結合していても、レビューで気づかれずに通過してしまいます。共有型からドメイン情報を排除し、サブクラス化／コンポジションを通じて、ドメインフィールド／ロジックを利用側へ移してください。理由：一つの利用側のドメインに結合した層は、もはや再利用可能ではありません。