Fanout — 選択的発散的アイデア創出パス
経験的根拠: メンテナによる二段階評価。Fanout は発散的設計タスクにおいて小さいながらも一貫した優位性を与えるが、収束的な根本原因分析にはまったく効果がない。約7倍のトークンコストに見合うのは、タスクがオープンかつ影響が大きい場合のみである。このスキルは、日常業務で自動的に発動することなく、必要なときにいつでも利用できるようにするために存在する。
ステップ 0 — 実行前のゲート確認（必須）
タスクをセレクタと照合する。両方とも真である必要がある:
- オープンエンドか？ 複数の有効な解がある（「Xに対する設計/名前/アプローチ/仮説」）。タスクが「なぜXが壊れたのか」「修正は効いたか」「根本原因は何か」、または一つの確認可能な答えがあるもの → これは収束的である。ユーザーにシングルショットの方が適したツールであることを伝え、実行前にそれでも進めるかどうかを尋ねること。収束的タスクに対して黙って実行してはならない。
- 約7倍のトークンに見合うほど重要か？ 重要なルール/API形状/名前/戦略であり、使い捨てではない。低重要度に見える場合はその旨を伝え、確認を取ること。
ゲートが曖昧な場合は、自身の判断を述べ、ユーザーに確認する。ゲートを通過したら、次に進む。
ステップ 1 — 問題を取得する
問題文を以下のいずれかから受け取る: @言及されたファイル、ファイルパス、またはユーザーメッセージ内の貼り付けテキスト。漠然としたトピックのみが与えられた場合は、まず問題のフレーミングを1〜2文で依頼する — フレームには具体的な何かが必要である。
ステップ 1.5 — 対象がプロジェクトの成果物である場合の方向付け（必須）
/fanout <ファイルパス> は事前に方向付けされているように見えるが、実際にはそうではない: フレームは成果物のみに基づいて推論し、プロジェクトのライブ状態をフィードしなければ、自信満々にそれを矛盾する内容を出力する。ステップ2の前に、問題がプロジェクトフォルダ配下のファイル（仕様書、決定資料、CHECKPOINTスレッド、コードファイルなど）である場合、まずそのプロジェクトの CHECKPOINT.md を最後まで読み（フックが表示しなかった場合は CLAUDE.md も）、次にそのプロジェクトの制約（締め切り、資金/順序付けゲート、確定した決定事項、既に試され/却下されたもの、具体的な数値）を抽出し、成果物のテキストと同様に、すべてのフレームプロンプトと批判エージェントにそのまま貼り付ける。成果物のみを与えられプロジェクトの状態を与えられなかったフレームは、文書化された失敗例がある（実際のファンアウトで、コスト仕様に対して「採算分岐点を過ぎてから実行すべき」というフレームが出力されたが、プロジェクトの CHECKPOINT が直接矛盾していた）。このステップは、問題が純粋にプロジェクトに依存しない場合（貼り付けられた抽象的な質問、ライブ状態のない命名/API形状の演習など）にのみスキップすること。
ステップ 2 — 発散（5つの並列Agent呼び出し、1メッセージ）
5つの general-purpose エージェントを並列に起動する（1メッセージ、5ツールコール）。各エージェントに同じ問題と一つの異なる視点を与える。各エージェントへの指示: 「割り当てられた視点のみから分析せよ。4〜6の明確に異なるアプローチ/アイデアを生成せよ。それぞれについて、それが内包する障害モード（トラップ）とそのメカニズムを述べよ。具体的に、メカニズムに名前を付け、曖昧にせず、順位付けせず、自身のアイデアを評価するな。簡潔にまとめよ（これは批判パスに供給される）。」 出力は直接返す（ユーザーが保存を頼まない限りファイル書き込みは行わない）。
5つの視点（原文ママ）:
- アーキテクチャ/システム — ステートマシン、データフロー、情報が変換または失われる場所について考える。可視動作の下のレイヤーでシステムが行うこと。並行性、障害、スケール下でどのように壊れるか。
- 敵対的/悪魔の代弁者 — すべての選択肢に致命的な欠陥があると仮定し、それを見つける。各選択肢が暗黙に仮定していることは何か。明白な答えが囮である場合、何が真実となるか。
- 第一原理 — 根底にあるメカニズムまで剥ぎ取り、実際の制約から再構築し、慣習を疑う。実際に必要なものと単に慣習的なものの区別。
- 実践者/運用者 — これを本番環境で運用し、午前3時にページングされた経験がある。フィールド障害、エッジケース、運用上の負担、可観測性、設計とオンコールの現実のギャップを重視する。
- ゼネラリスト部外者 — ドメイン知識なし。直感的に理解できるもの。循環論法を隠す専門用語を疑う。専門家が見逃しがちな「後から考えれば明白」な罠。
ステップ 3 — 批判（1 Agent 呼び出し）
5つすべてが返ってきたら、1つの general-purpose エージェントに5つの出力すべて + 問題を与える。指示: 「1) 各アプローチを新規性/実現可能性/適合性でスコアリングせよ（0〜10）。2) 基礎となる戦略でフレーム間をクラスタリングせよ。2つ以上のフレームが収束した箇所を記録せよ（その収束はシグナルである）。3) トラップ統合: 5つのフレームすべてから、重複を除いた、メカニズムが明示的に述べられた個別のトラップの和集合。各トラップにそのメカニズムを添える。4) 上位3案を深堀りせよ: よりシャープなバージョン、メカニズム、避けるべきトラップ、その案が依存する最もリスクの高い仮定、その仮定をコミット前にテストする最も安価な方法、具体的な最初のステップ。出力セクション: ## スコアリング, ## クラスタリング, ## トラップ統合, ## 上位3案の深堀り, ## 総合分析（4〜6文: 最も有力な方向性と、それを最も脅かすトラップ）。」
ステップ 4 — 提示
ユーザーに批判エージェントの**## 上位3案の深堀り**、## トラップ統合、## 総合分析をチャットで表示する。どの方向性に複数のフレームが独立して収束したかを要約する。求められない限り、5つの生のフレーム出力すべてをダンプしてはならない。
デフォルトでは何も永続化しない（残ったスクラッチファイルはそれ自体が混乱のもとである）。ユーザーが完全な記録を望む場合は、批判出力とフレームをユーザーが指定したパスに保存することを提案する。
注意点
- ネイティブの Agent ツールのみを使用すること — フレームのためにネストされた
claude -pにシェルアウトしてはならない（ネストされたCLI起動は権限/セキュリティレイヤーの下で信頼性が低い。Agent ツールがサポートされるパスである）。 - これは呼び出しごとにワンショットである（n=1）。ユーザーがばらつきを確認したい場合は、再度
/fanoutを呼び出すことができるが、効果の大きさが小さいため、めったに正当化されない。 - 決して自動トリガーしないこと。説明に記載された明示的な表出形式のみで動作する。