AIでアイデア出しをする方法｜発散と絞り込みを分ける

AIでアイデアを出すときは、最初から「一番よい案を決めて」と頼まず、発散と絞り込みを分けます。最初に目的と制約を渡して複数の方向を出し、次に似た案をまとめ、選ぶ基準で比較し、最後に弱点と小さな検証方法を決めます。AIの役割は正解を決めることではなく、考える材料を広げて、次の行動に移せる仮説を作ることです。

OpenAIの案内は、promptへ明確で具体的な指示と十分なcontextを含め、出力を見て反復する考え方を説明しています。Googleもpromptを具体化し、複雑な課題を分けたり、連続するpromptに分解したりする方法を紹介しています。Anthropicのガイドは、求める行動を明確に指示することなどを説明します。各社の推奨を同一手法の保証と扱わず、以下の流れはこれらの一般的な指示設計をアイデア検討用に組み直した実務フレームです。

まず課題を一枚にまとめる

「新しいアイデアが欲しい」だけでは、対象者・用途・制約がなく、ありきたりな案へ流れやすくなります。AIへ渡す前に、次の欄を埋めます。まだ分からないことは空欄や未決定と書き、勝手に補わせません。

表は横にスクロールできます

入力欄	書くこと	例
目的	何を改善・実現したいか	新規顧客が初回利用で迷う箇所を減らす
対象	誰のどんな状況か	初めて予約する人
現状	すでに分かっている事実	入力フォームで離脱がある
制約	予算、期間、禁止事項	2週間で試せる、個人情報を増やさない
成功の兆し	次に確認できる変化	問い合わせ内容や操作時間を比較できる
未確認	調査が必要な前提	離脱理由、対象者の範囲

例は考え方を示すための仮定で、実測データではありません。実際に企画を出すときは、社内で分かっている情報と仮説を区別します。課題定義の段階で離脱原因を決めつけると、AIの案もその説明に引っ張られます。「原因はまだ不明」と明記し、複数の原因を考えられるようにします。

発散では候補を評価させない

一度目は、実現性や採算性で選別せず、方向の違う候補を並べます。件数は目的に合わせます。数を増やすほどよいわけではなく、後で一案ずつ読める量に収めます。次のpromptは、そのまま使うための型です。

目的：［一枚の課題定義］

この段階では案の良し悪しを評価しないでください。

次の異なる切り口から、重複を避けて各3案ずつ出してください。

・利用者の最初の一歩を変える

・既存の案内や情報を組み替える

・運用や担当者の流れを変える

案ごとに「誰の何が変わるか」を一文で書いてください。

事実が不足する案には［要調査］を付けてください。

出力を受け取ったら、すぐに「一番よいもの」を選ばせず、切り口が十分に分かれているかを見ます。案が似ていたら、対象者や利用場面を変える追加条件だけを渡します。たとえば「初回利用者だけでなく、何度も使う人・支援する担当者・利用を断念した人の視点から別案を追加」のように視点を指定します。既存案を言い換えただけなら新案として数えないように依頼します。

似た案を束ね、比較できる形へ変える

発散結果は、語感ではなく「解決する困りごと」と「必要な仕組み」でまとめます。名前だけ違って同じ動きをする案は統合し、異なる仕組みなら別案を保ちます。たとえば、案内文の短縮、入力例の表示、相談窓口の追加は、それぞれ情報設計・入力支援・人的対応という異なる案として比較できます。

次に、候補を並べて不足情報を見えるようにします。AIに事実を補わせず、仮説と調査項目を別に書かせてください。

表は横にスクロールできます

案	変えるもの	期待する変化	主な前提	最小の確認
入力例を見せる	フォームの説明	入力方法の迷いが減る可能性	つまずき原因が入力例にある	例の有無で問い合わせ内容を比べる
必要項目を段階表示	入力画面の順序	初回の負担が減る可能性	全項目を最初に見せる必要がない	少人数で完了までの迷いを観察
予約前チェックを追加	事前案内	不足情報による差し戻しが減る可能性	差し戻し理由が案内不足にある	問い合わせ分類を確認してから試す

この例の期待する変化は検証前の仮説です。実際の利用者が迷っている理由が別にあるなら、案そのものを変える必要があります。案の数を減らすために、実装の容易さだけで並べ替えるのも避けます。利用者価値、検証のしやすさ、必要コスト、リスクを分けて比較してください。

絞り込み基準を後から適用する

案の比較軸は、課題ごとに変わります。短期間で検証する企画なら、価値の大きさより「小さく試せるか」が最初の条件かもしれません。安全性や法令が関わるなら、効果より先に満たすべき制約を定めます。評価軸をAIへ委ねず、決定権のある人が先に基準と重みを決めます。

簡単な採点表を使う場合は、各軸の意味を明記します。たとえば「利用者価値 1〜3」「2週間以内の検証可能性 1〜3」「必要コスト 1〜3（小さいほど高得点）」のように向きをそろえます。単純合計は議論の入口であり、合計点が高い案を自動採択する規則ではありません。重大なリスクがある案を、他の点数で帳消しにしないようにします。評価に必要な情報がない項目は0点や中間点へ置き換えず、「未確認」として追加調査へ回します。

有力案へ反対意見を向ける

上位案が決まったら、支持理由だけでなく「どんな条件なら失敗するか」「誰に不利益が出るか」「前提が間違っていたら何が変わるか」を検討します。AIへ反論させる場合も、出力を独立した事実確認として扱いません。理由を課題定義や社内データへ照合し、根拠がない懸念は仮説のまま残します。

候補案：［案］

この案を実行した場合に失敗する条件を、利用者・運用・費用・安全の観点で挙げてください。

各項目を［確認済みの事実］［仮説］［追加調査が必要］に分け、

根拠となる入力がないものは推測と明記してください。

最後に、この案を小さく試す前に確認すべき質問を3つまで出してください。

AIがもっともらしい反対意見を作っても、存在しない利用者の声や数値を根拠にしてはいけません。社内ログや調査結果がなければ、次の作業は「アイデアを採用」ではなく「前提を確かめる」です。案の実現性を判断する責任は、実際の制約を把握している人にあります。

1案に絞らず、次の行動を決める

収束の終点は、常に一つの勝者を決めることではありません。前提が違う案を2〜3個残し、それぞれについて「次に何を調べるか」「誰が決めるか」「いつ見直すか」を決めます。小規模な試行ができる案なら、成功・失敗の判断条件を開始前に設定し、途中で都合よく変更しないようにします。

次の一手は、案を実装することとは限りません。利用者への短い聞き取り、問い合わせの分類、現行画面の観察、費用見積もり、法務確認など、最も大きな不確実性を減らす作業を選びます。確認できない前提が解消するまでは、実装を保留する判断も有効です。候補ごとに調査先が異なるなら、共通の順位表に無理にまとめず、別の検証として扱います。

途中で迷ったときの切り分け

表は横にスクロールできます

困りごと	起きていること	次に行うこと
案が抽象的	誰の何が変わるか書かれていない	対象・利用場面・行動を一文で追加
似た案ばかり	同じ仕組みを言い換えている	別の利用者、情報、運用の切り口を指定
評価が早すぎる	発散中からコストや実現性で案を落としている	まず候補を見える化し、次の段階で評価
点数だけで決まる	前提や重大リスクを確認していない	未確認を分離し、必須条件を別判定
AIが事実を作る	入力にない市場・利用者像を補っている	仮説ラベルを付け、一次データで確かめる
次の行動が曖昧	案が列挙されたまま終わる	担当・確認内容・期限を一つずつ決める

AIものさしの判断

ブレストの質は、候補の多さやAIらしい発想だけでは決まりません。課題の前提が見え、異なる案が比較でき、採用しない理由も説明でき、次の検証へ移れることが重要です。発散と評価を分け、事実・仮説・未確認を混ぜず、AI案を現場のデータへ照合します。結論を出す材料が足りなければ、案を無理に採用せず、不確実性を減らす質問を次のActionとして残してください。

会議やチームで使うときの引き継ぎ

個人のブレストと違い、チームでは「誰が何を決めたか」が残らないと、次の会議で発散へ戻りやすくなります。候補ごとに一枚の案カードを作り、課題、対象者、変える行動、前提、懸念、次の検証を記録します。AIの出力をそのまま議事録として採用せず、担当者が事実と判断を確認してから共有します。

表は横にスクロールできます

案カード	記入する内容
課題	誰のどの場面の困りごとか
提案	変える仕組みや行動は何か
根拠	既知のデータか、まだ仮説か
制約	費用・期間・安全面の条件
懸念	失敗条件、影響を受ける人
次の検証	何を、誰が、いつまでに確認するか

会議の進行役は、発散中に案を評価しない時間と、収束時に判断する時間を分けます。評価を始める前に参加者が案を個別に書く方法もあります。声の大きい人や先に出た案へ議論が引っ張られにくくなるためです。これらは運営上の選択肢で、全てのチームに必ず適する手法ではありません。人数、決裁方法、扱う情報に合わせて調整してください。

また、機密情報や個人情報をpromptへ入れる場合は、使うサービスのデータ利用設定と社内ルールを先に確認します。匿名化しても再識別できる情報が残ることがあります。安全に共有できる要約へ置き換えられない場合は、AIに渡さず人だけで検討する選択を取ります。