brainstorming

ブレインストーミング：アイデア創出スキル

あらゆる分野（ソフトウェア、ビジネス、クリエイティブなプロジェクト、個人的な決断など）で、人々がアイデアを広げ、収束的思考から抜け出せるよう支援します。

基本原則

**アイデアが育つには、広がる余地とぶつかり合うものが必要です。**行き詰まっていて、マンネリから抜け出したいこともあります。種となるアイデアがあり、それを広げたいこともあります。どちらも、出発点が異なるアイデア創出の課題です。

2つのモードに、1つの目標があります。最初に思いついた選択肢に落ち着くのではなく、可能性の空間を探ることです。

最初の状況を診断する

始める前に、どこからスタートするのかを特定します。

出発点	状況を示すサイン	モード
行き詰まり	同じアイデアばかり浮かびます。選択肢はすべて、既存案のバリエーションに感じられます。「もうあらゆる手を試しました」。探索する前に評価しています。	→ 脱出速度プロトコル
種となるアイデア	何かの出発点があります。それがどんな形に発展するのかを知りたいと思っています。関連する方向性や、足りない要素を探しています。	→ 種の拡張プロトコル
不明確	行き詰まっているのか、まだ初期段階なのかがわかりません。何かはありますが、それが良いものかは確信がありません。	→ まず種の拡張から始め、収束を感じたら脱出速度に切り替えます

**重要な問い：**何かから抜け出そうとしているのか（行き詰まり）、それとも何かを育てようとしているのか（種となるアイデア）？

---

収束の問題（行き詰まりモード）

アイデアは、複数の面で期待されるパターンに一致するため、似通っていきます。明らかな「誰」が、明らかな「何」を、明らかな「規模」で、明らかな「方法」によって実現する解決策を使っているなら、それが予測可能に感じられる理由です。

**重要なテスト：**3人の異なる人が、それぞれ独立にブレインストーミングしても同じリストを作るでしょうか？そうなら、まだ発散できていません。

状態

状態 B1：収束への盲目

症状：

• 最初のアイデアが、すぐに「正しい」と感じられます
• すべてのアイデアが同じアプローチに集中します
• セッションで、1つのテーマのバリエーションばかりが生まれます
• 「何をすべきかはもうわかっていて、あとは選ぶだけです」

重要な質問：

• 最も明白な解決策は何ですか？明示的に挙げましたか？
• 3人の異なる人が、同じリストを作るでしょうか？
• 可能性の空間を探っていますか、それとも直感を裏付けていますか？
• 検討対象にあるのは、バリエーションではなく、根本的に異なるアプローチがいくつですか？

**介入策：**デフォルト列挙（フェーズ 1）を実行します。そこから抜け出そうとする前に、アイデアの集中先を明らかにします。見える形にしていないデフォルトからは抜け出せません。

---

状態 B2：機能への固執

症状：

• アイデアがすべて同じ形を取ります
• 議論が解決策の種類を前提にしています（「必要なのは、こういうアプリです……」）
• 解決策の形が前提になっているため、別の案が見えません
• 「Yを達成する必要がある」ではなく、「Xが必要だ」と考えています

重要な質問：

• 何を達成する必要がありますか？（どんな形にすべきか、ではありません）
• まったく異なるものでも、同じ結果を実現できますか？
• 実際に解決しようとしている問題は何ですか？執着している解決策は何ですか？
• 実際に存在する制約と、思い込みによる制約は何ですか？

**介入策：**機能抽出（フェーズ 2）を実行します。「何を」と「どのように」を切り分けます。解決策ごとではなく、機能ごとに代替案を5つ作ります。

---

状態 B3：軸の崩壊

症状：

• アイデアは表面的に異なっていても、根底にある構造は共通しています
• 「同じアイデアが、別の服を着ているだけです」
• 「誰」だけが異なり、「何／いつ／どのように」は同じです
• すべてのアイデアを1つの分類にまとめられます

重要な質問：

• これに関して、明らかな「誰」は誰ですか？まったく異なる人物を試しましたか？
• 明らかな「いつ」はいつですか？10倍遅かったらどうですか？即時なら？繰り返しと一度きりなら？
• 明らかな「規模」はどれくらいですか？10倍大きかったら？10倍小さかったら？
• 明らかな「方法」は何ですか？まったく異なるアプローチには何がありますか？

**介入策：**軸のマッピング（フェーズ 3）を実行します。デフォルトの解決策を4つの軸でマッピングします。少なくとも1つの軸を変えて、パターンを崩します。

---

State B4：ドメインへの閉じこもり

症状：

• すべてのアイデアが同じ参照クラスから生まれる
• 「いつもこうしている」または「業界ではこうしている」
• その分野の人なら誰でも思いつく解決策である
• 隣接分野や遠い分野からのアイデアがない

重要な問い：

• このアイデアはどの分野／業界から生まれたものですか？
• 類似の問題を確実に解決しているのはどのドメインですか？
• まったく異なる職業の人なら、どのように取り組むでしょうか？
• どの業界にとって、この問題は簡単なものでしょうか？

介入： ドメインの持ち込み（フェーズ 4）を実行します。互いに無関係な 3 つ以上の分野のロジックを適用して、アイデアを生み出します。domains カテゴリーで constraint-entropy.ts を使用します。

---

State B5：生産的な発散

症状：

• アイデアが形式、規模、関係者、時間枠の面で多様である
• 生成の問題ではなく、評価の問題（選択肢が多すぎる）である
• しっくりこなかったり、意外に感じたりするアイデアがある
• すべてのアイデアを 1 つのクラスターにまとめるのが難しい

重要な問い：

• これらを絞り込むには、どの基準を使うべきですか？
• 有力候補を試すための最小限の実験は何ですか？
• どのアイデアを組み合わせられますか？
• どのアイデアが異なるユーザー層に役立ちますか？

介入： 評価フレームワークに移ります。アプローチごとにクラスター化し、各クラスターから代表的なアイデアを選んでプロトタイプを作成／テストします。

---

エスケープ・ベロシティ・プロトコル

収束的なブレインストーミングから抜け出すための、体系化されたプロセスです。行き詰まったセッションでは 5 つのフェーズすべてを使用し、問題が明確な場合は該当するフェーズに進みます。

フェーズ 1：デフォルトの列挙（必須）

「本当の」アイデアを生み出す前に、デフォルトを明示的に列挙します。

• 「誰でも」提案しそうなことは何ですか？
• この問題に対する、そのジャンル／業界のデフォルトは何ですか？
• 前回、あなた／チームはどのような提案をしましたか？
• 最初の検索結果には何が書かれているでしょうか？

出力： デフォルトであることを明記した、明白なアイデアのリスト（5～10 個）。

目的： アトラクターを可視化します。名前を付けていないものから抜け出すことはできません。

---

フェーズ 2：機能の抽出

要件ごとに、WHAT と HOW を分けます。

• 何を達成しなければなりませんか？（機能）
• どのような方法で達成するかについて、何を前提としていますか？（形式）
• どの制約が実際に存在し、どの制約が想定上のものですか？

捉え直し： 「[形式] が必要です」を「[機能] を実現する必要があり、[形式] はその方法の 1 つです」にします。

出力： 形式に依存せず、解決策が実現しなければならない中核機能のリスト（3～5 個）。

例：

• 「モバイルアプリが必要です」→「ユーザーが外出先で X を実行できる必要があり、モバイルアプリはそのための形式の 1 つです」
• 「毎週の会議が必要です」→「チーム間で情報を共有できる必要があり、会議はその手段の 1 つです」

---

フェーズ 3：軸のマッピング

デフォルトの解決策を 4 つの軸でマッピングします。

軸	問い	デフォルト	代替案
誰	誰が実行／使用／所有しますか？	[明白な関係者]	可能性の低い関係者 3 人
いつ	どのような時間枠／頻度ですか？	[明白なタイミング]	異なる周期／タイミング
規模	どのような大きさ／範囲ですか？	[明白な規模]	10 倍大きくする？ 10 分の 1 にする？
方法	どのようなアプローチ／仕組みですか？	[明白なアプローチ]	まったく異なるアプローチ

重要なポイント： アイデアが 4 つの軸すべてで「ありそうな」ものに合致すると、予測可能に感じられます。どの軸でも 1 つ変えるだけで、アイデアは明白でなくなります。

出力： 各軸に少なくとも 2 つの代替案を含む、完成した軸マップ。

---

フェーズ 4：エントロピーの注入

探索を促すため、ランダムな制約を導入します。

エントロピーの種類：

• ランダムな関係者（異なるドメインから選ぶ）
• ランダムな制約（時間、リソース、能力の上限）
• ランダムな組み合わせ（これと無関係な別のことを同時に解決する）
• 反転（これを「妨げる」ものは何か？ それを前提に設計する）
• ドメインの持ち込み（[ランダムな分野] ならどのように解決するか？）

ツール： constraint-entropy.ts を使用して、ランダムな制約を生成します。

deno run --allow-read constraint-entropy.ts --combo
deno run --allow-read constraint-entropy.ts domains --count 3
deno run --allow-read constraint-entropy.ts inversions

出力： 変わった制約のもとで生み出されたアイデア（3～5 個）。

目的： 隣接していない可能性の空間を探索するよう促します。違和感があっても、制約を受け入れます。

フェーズ 5：直交性の監査

有望なアイデアについて、次の点を確認します。

• このアイデアは、それが明白な解決策だと「自覚」していますか？（「期待されるアプローチだ」と自ら説明できるなら、それは収束的です）
• ジャンルの定番を予想している人を驚かせますか？
• 実際にどの軸を回転させましたか？
• 期待される形式を破りながら、その機能を果たしますか？

テスト： アイデアが直交しているのは、期待される方法で問題に役立つのではなく、独自の論理を持ち、問題と衝突するときです。

出力： 真に異質なアイデアと、表面的に異なるだけのアイデアを分類します。

---

シード拡張プロトコル

最初のシードからアイデアを発展させるための体系的なプロセスです。優れたアイデアがどこから生まれるかについての Steven Johnson の研究に基づいています。逃れたいものではなく、拡張したいものがあるときに使います。

Johnson の原則

これらはインスピレーションを与えるものではなく、診断に使うものです。それぞれ、アイデアが実際にどのように発展するかを示す仕組みを説明します。

原則	仕組み	診断の質問
隣接可能性	「新しい」アイデアのほとんどは、既存のものから次に到達可能な一歩です。瞬間移動ではなく、階段です。	このシードから一歩進んだところには何がありますか？これが存在すると、何が可能になりますか？
液体ネットワーク	部分的な思考がぶつかり合うとアイデアが生まれます。人、成果物、過去の仕事、無関係な分野などです。	このシードを何とぶつけるべきですか？つながる可能性のあるものが周囲にありますか？
ゆっくりとした直感	多くの優れたアイデアは未完成の状態から始まります。足りない要素と出会うまで時間が必要です。	このシードに足りないものは何ですか？何があれば完成しますか？
セレンディピティ	幸運と、それに気づく力です。役立つ異変が現れたとき、それに気づきます。	最近遭遇した予想外のことで、つながる可能性のあるものは何ですか？
エラー	失敗は情報です。フィードバックによって、さまよいが収束へと変わります。	これを最もばかげた形にするとどうなりますか？どこで破綻しますか？
外適応	ある目的のために作られたものを、別の目的に転用します。再利用を発明に変えます。	このシードでまったく別の問題を解決できますか？別の目的で作られたもので、ここに使えるものはありますか？
プラットフォーム	安定したプリミティブがあれば、より速く安全に構築できます。	これを土台にできる安定したものは何ですか？他のアイデアのプラットフォームにするには何が必要ですか？

---

シードの状態を診断する

拡張する前に、どのようなシードがあるのかを把握します。

状態 S1：隣接への準備完了

兆候：

• シードが具体的で明確です
• 何をするかは明らかですが、次に何があるかは不明です
• 何か大きなものの「最初の一歩」のように感じられます

主な質問：

• これが存在すると、今は不可能なことで何が可能になりますか？
• 誰かが次に自然と望むのは何ですか？
• これを土台に何を構築しますか？

拡張： 隣接可能性をマッピングします。このシードから到達可能になるものを 3～5 個挙げます。最も興味深いものを選び、同じことを繰り返します。

---

状態 S2：衝突を求めている

兆候：

• シードだけでは不完全に感じられます
• 「何かほかのもの」が必要だと感じます
• ある文脈では機能しますが、別の文脈では機能しません

主な質問：

• このアイデアにまだ出会ったことのない分野は何ですか？
• どの過去の仕事を思い起こさせますか？
• 誰にとっては自明ですか？誰にとっては異質ですか？

拡張： 強制的に衝突を起こします。分野、制約、成果物をシードにぶつけます。必要であれば、Escape Velocity Protocol のエントロピー注入を使います。

---

状態 S3：未完成の直感

兆候：

• アイデアをまだ十分に説明できません
• 重要に感じますが、漠然としています
• 「何かがあるけれど、名前をつけられない」と感じます

主な質問：

• 明確に説明できる部分は何ですか？
• 完成していたら、このアイデアはどんな問いに答えますか？
• 欠けているのは何ですか。仕組みですか？例ですか？ユースケースですか？

拡張： 無理に完成させようとしないでください。今あるものを言葉にします。足りないものに名前をつけます。書き留めて直感を保ち、その後、時間をかけて不足を埋める可能性のある衝突を探します。

---

状態 S4：エラーから学ぶ

兆候：

• シードを試したが、うまくいかなかった
• 何がうまくいかないかがわかっている
• 失敗は終わりではなく、有益な情報だと感じられる

主な問い：

• 具体的に何が壊れたのか？（仕組み、コンテキスト、実行？）
• 失敗によって、問題の構造について何が明らかになったか？
• これを機能させるには、何を変える必要があるか？

発展： 失敗を掘り下げましょう。エラーには、解決策の形を示す情報が含まれています。学んだことを列挙し、失敗の要因を避けられる隣接するシードを探しましょう。

---

状態 S5：転用候補

兆候：

• シードは本来の目的にうまく機能している
• まったく別のことにも使えそうだと感じる
• 関係のないものを指して「これは X を思い出させる」と感じる

主な問い：

• このシードはどんな用途のために作られたのか？
• どんな別の用途に、似た構造があるか？
• このシードを移植すると、意外だが現実味のある結果が得られるのはどこか？

発展： 意図的に移植しましょう。まったく異なるコンテキストを 5 つ挙げ、それぞれでシードを試してください。何が変わり、何が残るかを記録しましょう。

---

シード展開のフェーズ

順番に進める Escape Velocity とは異なり、シードの状態に応じて必要なフェーズを使いましょう。

フェーズ S1：シードの明確化

展開する前に、手元にあるものを記録しましょう。

• このシードの核は何か？（1 文で）
• 何に向いているか？何に向いていないか？
• どこから生まれたか？（衝突、隣接ステップ、直感、失敗、転用？）
• 現時点で、このシードについて何が不確かか？

出力： シードの内容と、その種類を明確に記述します。

---

フェーズ S2：隣接領域のマッピング

このシードから到達できる範囲をマッピングしましょう。

• 1 ステップ先に何があるか？
• これまでできなかったことで、何が可能になるか？
• これが成功したら、自然に何が続くか？
• 誰かがこれを土台に、何を作るだろうか？

出力： 隣接する可能性を 3～5 個挙げ、そのうち 1 つに「最も興味深い」と印を付けます。

---

フェーズ S3：衝突の生成

シードをほかの素材と意図的に衝突させましょう。

• 分野の衝突：［無関係な分野］はこのシードをどう捉えるか？
• 成果物の衝突： 過去の成果（自分または他者のもの）で、関連するものは何か？
• 制約の衝突： 通常とは異なる制約のもとで、何が起きるか？
• 反転の衝突： その反対は何か？反転すると、何が壊れるか？

ツール： constraint-entropy.ts domains --count 5 を使って、衝突させる分野をランダムに生成します。

出力： 衝突の結果を 3～5 個挙げ、興味深いものが生まれた結果を記録します。

---

フェーズ S4：ギャップの特定

不完全なシードについて、欠けているものを明確にしましょう。

• 完成した場合、このシードはどんな問いに答えるか？
• 言葉にできない仕組みは何か？
• これが機能することを証明するには、どんな例が必要か？
• これを信じてもらうには、何を見せる必要があるか？

出力： ギャップを明確に記述します。今後の衝突で探すのはこれです。

---

フェーズ S5：移植のテスト

ほかの場所でも機能する可能性のあるシードについて、次の手順を行いましょう。

• まったく異なるコンテキストを 5 つ挙げる
• それぞれについて、何が変わるか、何が残るか、何が得られるかを確認する
• 移植によって、これまで気づかなかったシードの性質が明らかになるかを確認する

出力： それぞれから何が明らかになったかを記した、移植の結果。

---

フェーズ S6：ストレステスト

シードが機能しなくなる状況を見つけましょう。

• 最悪の用途は何か？
• どの前提が間違っていると、これが成り立たなくなるか？
• 可能な限りまずい実装はどんなものか？
• これを嫌うのは誰か？なぜか？

出力： 失敗の要因と、シードの実際の構造についてそれらが明らかにすること。

---

モードの切り替え

あるモードで始めても、切り替えが必要になることがあります。

シード → 行き詰まり： シードを展開しても収束（すべての展開が同じもののバリエーションになる）が起きる場合は、Escape Velocity に切り替えましょう。収束に達しています。

行き詰まり → シード： Escape Velocity で有望な発散アイデアが生まれた場合は、Seed Expansion に切り替えて発展させましょう。育てる価値のあるシードが見つかっています。

引き継ぎ： Escape Velocity は候補を生み出します。Seed Expansion は有望な候補を発展させます。これらは、同じアイデア創出プロセスにおける異なるフェーズです。

---

アンチパターン

数量の錯覚

問題： 50個のアイデアを出しても、そのすべてが同じ3つのアプローチのバリエーションになっています。

症状： 数は多いものの、広がりがありません。アイデアをマッピングすると、視覚的にまとまってしまいます。簡単に少数のグループに分類できます。

対策： 数を数えるのはやめて、軸に沿ってマッピングしましょう。アイデアを追加する前に、各象限に少なくとも1つずつアイデアを出すようにします。量ではなく、広がりを測りましょう。

---

逆転の罠

問題： 「反対のことをしたらどうなるでしょうか？」という問いは、安易な発散です。反対のものは同じ軸を共有しているため、依然として収束しています。

症状： 「速くする代わりに、遅くする。」「自動化する代わりに、手動にする。」「高価にする代わりに、無料にする。」

対策： 逆転で変わるのは大きさであり、次元ではありません。同じ軸の反対側ではなく、本当に直交する別の軸を見つけましょう。「そもそも速度が関係する次元ではないとしたら？」

---

評価の早すぎるループ

問題： アイデアを出しながら評価してしまいます。「それはうまくいかないでしょう。なぜなら……」という言葉が発散を止めます。

症状： アイデアが文の途中で途絶えます。グループは「現実的な」アイデアに引き寄せられます。非現実的な提案に対して抵抗感が生まれます。

対策： フェーズを厳密に分けましょう。生成は評価ではありません。フィルタリングを始める前に、すべてのアイデアを書き留めます。非現実的なアイデアに、実用的なアイデアの種が含まれていることもあります。

---

専門家のアンカー

問題： 質の高さではなく、権威によって、分野の専門家が最初に出したアイデアが支配的になります。

症状： 最初に発言した人のアイデアが基準点になります。その後のアイデアはすべて、そのバリエーションか反応になります。経験に対する遠慮が生まれます。

対策： まず匿名でアイデアを出します。または、専門家は最後に発言します。または、フェーズ1で専門家の定番案を明示的に列挙し、その後の検討対象から除外します。

---

新規性の追求

問題： それ自体が目的になった発散です。実際の機能に役立たない奇抜なアイデアを追い求めています。

症状： アイデアは意外性がありますが、役に立ちません。機能を果たさず、巧妙なだけです。「創造的ですが、問題は解決できません。」

対策： フェーズ2（機能の抽出）に戻ります。その奇抜なアイデアは、必要な機能を実際に果たしていますか？ そうでなければ、それは発散ではなく、無関係なアイデアです。直交性は機能に役立つものでなければなりません。

---

調査の回避

問題： 既存の先行事例があるのに、ゼロからブレインストーミングしています。既存の解決策を一から作り直しています。

症状： 「これを試した人はいるのでしょうか？」（実際には、すでに試されています）。グループにとっては新しいアイデアでも、ほかの場所には存在しています。

対策： アイデア出しの前に調査しましょう。既存のアプローチを5つ以上見つけ、フェーズ1で定番案として列挙してから、発散します。車輪の再発明ではなく、先人の知恵を土台にしましょう。

---

状態別の主要な質問

収束の診断（すべての状態）

• バリエーションではなく、根本的に異なるアプローチをいくつ出しましたか？
• アイデアをクラスターにまとめると、いくつに分かれますか？
• 不快に感じるアイデアはありましたか？（不快感は、実際に発散している兆候であることがよくあります）
• 別の分野の人が同じリストを出すでしょうか？

機能の固定（B2）

• 「明白な解決策」が存在しなかったら、どうなりますか？
• リソースが10倍あったら、何をしますか？ リソースが10分の1だったら、何をしますか？
• ［想定しているアプローチ］を使えないとしたら、ほかにどんな方法で機能を実現できますか？
• その方法とは切り離して、実際に必要な成果は何ですか？

分野の拡張（B4）

• 似たような問題を確実に解決している業界はどこですか？
• この問題を簡単だと感じる業界はどこですか？
• ［無作為に選んだ分野］の人なら、あなたが見落としている何に気づくでしょうか？
• 自然はこの問題をどのように解決していますか？ 軍隊はどうでしょうか？ 幼稚園の先生はどうでしょうか？

軸の監査（B3）

• 「明白な」ユーザー／担当者は誰ですか？ ほかに誰が考えられますか？
• 「明白な」時間枠はどのくらいですか？ 10倍遅かったらどうでしょうか？ 即時だったらどうでしょうか？
• 「明白な」規模はどのくらいですか？ 1人向けだったらどうでしょうか？ 100万人向けだったらどうでしょうか？
• 「明白な」方法は何ですか？ まったく異なる方法は何ですか？

---

利用可能なツール

constraint-entropy.ts

多様な探索を促すため、ランダムな制約を生成します。

# Generate random constraints
deno run --allow-read constraint-entropy.ts --count 3

# Get domain-import prompts
deno run --allow-read constraint-entropy.ts domains --count 5

# Generate constraint combo (one from each category)
deno run --allow-read constraint-entropy.ts --combo

# Specific categories
deno run --allow-read constraint-entropy.ts actors
deno run --allow-read constraint-entropy.ts resources
deno run --allow-read constraint-entropy.ts inversions
deno run --allow-read constraint-entropy.ts combinations

# JSON output
deno run --allow-read constraint-entropy.ts --combo --json

カテゴリ：

• actors - 誰に関する制約（「10歳の子どもが使わなければならない」「これに敵意を持つ人」）
• resources - リソースに関する制約（「予算は10分の1」「ありきたりな技術は使えない」）
• combinations - 強制的な組み合わせ（「Xも解決しなければならない」「期待されることをしてはならない」）
• inversions - 視点の反転（「失敗が目標だとしたら？」「制約が機能だとしたら？」）
• domains - 他分野の知見を取り入れるプロンプト（「軍事物流なら、これをどう解決するか？」）

スクリプトを使う理由： 真のランダム性によって、人間やLLMが通常なら避ける探索を促します。実際に有用な発散を生み出すよう厳選された制約です。

---

対話例

ユーザー：「チーム内のコミュニケーションを改善するアイデアが必要です。同じアイデアばかり出てきます。Slack チャンネル、会議の増加、ドキュメント化などです。」

診断の進め方：

1. 状態を特定する： B1（収束による盲点）+ B4（領域への閉じ込め）。アイデアはコミュニケーションツールや会議の形式に集中しています。この問題領域でわかりやすい定番の選択肢です。

2. フェーズ 1 - 定番の列挙： 定番の選択肢を明示しましょう。

   • Slack／Teams の使い方を改善する、または新しいツールを導入する
   • 会議を増やす／減らす
   • ドキュメント用のウィキ
   • 毎日のスタンドアップ
   • チームビルディング活動
   • オフィスのレイアウト変更

   これらはこのジャンルの定番です。有効ですが、予測しやすい案です。

3. フェーズ 2 - 機能の抽出： チーム内のコミュニケーションで実現すべきことは何でしょうか？

   • F1： 情報を必要とする人に届ける
   • F2： 作業を止めずに質問への回答を得る
   • F3： 時間が経ってもコンテキストを維持する
   • F4： 難しい話し合いを可能にする信頼関係を築く
   • F5： シグナル対ノイズ比を管理可能な状態に保つ

4. フェーズ 3 - 軸のマッピング（「毎日のスタンドアップ」の場合）：

   軸	定番	代替案
   誰	チーム全体	ペアを交代する？ 他のチームと？ 顧客も含める？
   いつ	毎朝	毎週？ 必要に応じて？ 障害発生後？
   規模	15 分	上限 2 分？ 月 1 回、2 時間の深掘り？
   方法	口頭での同期	非同期のテキスト？ 動画の録画？ 歩きながらの会話？

5. フェーズ 4 - エントロピーの注入： constraint-entropy.ts --combo を実行します。

   • 行為者：「これに敵意を持つ人にもメリットがなければならない」
   • 反転：「過剰なコミュニケーションが失敗の原因だとしたら？」

   これにより、次の問いが生まれます。会議が嫌いな人にも情報が届くようにするには？ 効果を高めるために、コミュニケーションを減らす設計にしたらどうでしょうか？

6. 発散によって生まれたアイデア：

   • ペアの交代： チーム会議は行いません。ペアを交代しながら、毎日同期します。情報は一斉配信ではなくネットワーク全体に広がります。内向的な人にも向いています。
   • 意思決定の記録： すべての決定をコンテキストとともに記録します。コミュニケーションは「もう一度聞く」ではなく「記録を読む」形になります。非同期を優先します。
   • 沈黙の予算： 各メンバーが週ごとに使える「割り込み」トークンを限定します。何を伝える価値があるか、優先順位をつけざるを得なくなります。
   • おばあちゃんテスト： お知らせはすべて、技術に詳しくない家族にも理解できるものでなければなりません。専門用語に気づき、明快さを促します。
   • コンテキスト優先： 更新内容はすべて、「今日参加した人が戸惑うのはどんな点か？」から始めなければなりません。

   これらのアイデアは互いに独立しています。「会議ツール」のバリエーションではなく、異なる軸に基づいています。

---

すること

1. 状態を診断する - B1～B5のうち、現在の状況に当てはまるものを判断します。
2. 適切なプロトコルフェーズを実行する - 状態に合った介入を選びます。
3. ランダムな制約を生成する - 行き詰まったらエントロピーツールを使います。
4. 直交性を監査する - アイデアが真に発散しているか確認します。
5. 数ではなく広がりをマッピングする - 可能性空間をどれだけ広くカバーしているか測定します。

出力の永続化

このスキルは、作業をセッションをまたいで保持するため、主な出力をファイルに書き込みます。

出力先の確認

ほかの作業を始める前に：

1. プロジェクト内に context/output-config.md があるか確認します
2. ファイルがあれば、このスキルのエントリーを探します
3. ファイルがない場合、またはこのスキルのエントリーがない場合は、まずユーザーに確認します：
   • 「このブレインストーミングセッションの出力はどこに保存すればよいですか？」
   • 次の場所を提案します：explorations/brainstorming/ またはプロジェクトに適した場所
4. ユーザーの希望を保存します：
   • コンテキストネットワークがある場合は context/output-config.md に保存します
   • それ以外の場合は、プロジェクトルートの .brainstorming-output.md に保存します

主な出力

このスキルでは、次の内容を保存します：

• 列挙したデフォルト設定（フェーズ1の出力）
• 機能の抽出結果（フェーズ2）
• 検討した代替案を含む軸のマッピング（フェーズ3）
• エントロピーの制約と、それによって生み出したアイデア（フェーズ4）
• 直交性の監査結果：真に多様なアイデアの特定（フェーズ5）
• 選定した有望なアイデアと、その根拠

会話とファイルの使い分け

ファイルに保存	会話に残す
列挙したデフォルト設定	どのデフォルト設定に固執しがちかについての議論
軸のマップとその転換	制約の選択に関する反復
生成した多様なアイデア	アイデアへのリアルタイムのフィードバック
直交性の評価	確認の質問
有望な組み合わせ	却下した選択肢

ファイル名

パターン：{topic}-{date}.md 例：product-naming-2025-01-15.md

行わないこと

• ユーザーに代わってアイデアを生成する（内容ではなく、プロセスを提供します）
• アイデアの生成中に評価する（フェーズを分けます）
• デフォルト設定の列挙を省略する（意識されていないデフォルト設定からは抜け出せません）
• 機能性を考慮せず、新奇性だけを追い求める（奇抜さは有用性とは異なります）
• 分野の専門知識を置き換える（知識の代わりではなく、知識とともに取り組みます）
• 優れたアイデアを保証する（可能性の領域を探索することを保証します）
• 「もうすべて試しました」という言葉を受け入れる（おそらく同じアプローチのバリエーションにすぎません）