AIと壁打ちして企画を整理する方法｜質問役・反論役として使う

AIとの壁打ちで持ち帰るものを先に決める

AIと企画を壁打ちするときの目的は、AIに企画の正解を決めてもらうことではありません。頭の中の曖昧な案を言葉にし、前提や抜けを見つけ、反対の視点や複数案を並べたうえで、自分が次に確かめることを決める作業です。会話を長く続けても、判断材料や次の行動が増えなければ壁打ちの成果とは言いにくいでしょう。

進め方は、背景共有、質問、要約、反論、選択肢、検証計画の順です。最初から「企画を完成させて」と頼むと、情報不足を一般論で埋められることがあります。まずAIを質問役にし、自分が答えた情報を要約させてから、別の役割へ切り替えると、どの前提に基づく提案なのかを追いやすくなります。

壁打ちの入力メモ

会話を始める前に、完璧な企画書を作る必要はありません。次の項目を短く埋めます。分からないところは「未確認」と書けば、AIが事実のように穴埋めするのを防ぎやすくなります。

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

項目	書く内容	例
目的	何を変えたいか	既存顧客の継続利用を増やしたい
相手	誰のどの状況か	月次レポートを作る小規模チーム
現状	今どうしているか	表計算から手作業で資料化
困りごと	どこで止まるか	集計後の説明に時間がかかる
制約	期間・人・予算・情報	2週間、担当1人、機密データは外部送信不可
仮説	いま考えている解決案	要約の下書きをAIに作らせる
未確認	追加で調べる事実	利用者が困る工程、利用可能なデータ

この表は思考の入口であり、顧客調査や市場データの代わりではありません。個人情報、顧客名、契約情報、社内機密はそのまま入力せず、組織の利用ルールに従って匿名化または要約します。

まず質問役として情報不足を洗い出す

入力メモを渡したら、すぐに案を出させず「提案はまだせず、判断に必要な質問を一度に5つ以内で出してください。回答がない項目は不明のまま残してください」と伝えます。数を制限するのは、質問が増えすぎて回答前に疲れるのを避けるためです。対象者、利用頻度、現行の代替手段、成功条件、実行制約など、企画の判断を変えそうな質問から答えます。

質問への回答は、事実、本人の観察、仮説を区別します。たとえば「顧客は月次報告を嫌がっている」は、顧客本人から聞いたのか、担当者の推測なのかを明示します。曖昧な答えしかない場合、AIに自信ありげな前提へ変換させず「この項目は仮説」とラベルを付けます。AIが質問の意味を取り違えたときは、すべてに回答する前に質問を言い換えます。

要約で認識ずれを止める

質問に答えたあと、会話を続ける前に要約を依頼します。出力は、目的、対象者、現状、制約、確認済み事実、仮説、未確認事項に分けます。AIの文章が滑らかでも、ここで自分の意図とずれていたら、その要約を直してから先へ進みます。間違った前提のまま反論やアイデアを増やすと、会話量だけが増えて修正が難しくなります。

壁打ち中に前提が更新された場合は、古い要約を参照し続けないよう、新しい情報と変更前の情報を分けて記録します。複数人で読むメモなら、誰が確認した事実か、いつの情報かも残すと後から検証できます。特に市場規模、価格、競合機能、法規制のような変動情報は、AIの記憶を根拠に決めず一次情報へ戻ります。

反論役を「否定役」で終わらせない

次に、AIへ企画に反対する立場を与えます。ただし「批判して」だけでは、根拠のない欠点や一般的なリスクが並ぶことがあります。「この企画を採用しない担当者の立場で、失敗条件を3つ挙げ、それぞれ根拠となる入力情報と、まだ分からないことを分けてください」と依頼します。

返ってきた指摘は、事実に照らして分類します。入力から直接言えること、追加調査が必要なこと、仮説に過ぎないことを分け、もっともらしい表現だけで優先度を上げません。懸念が実在するかを確かめる質問や、小さく試せる検証を続けて出させます。反論の目的は企画を潰すことではなく、採用条件をはっきりさせることです。

選択肢を同じ物差しで比べる

複数案を出してもらうときは、同じ観点で表にします。案ごとに評価軸が変わると、見栄えのよい提案が有利になるためです。

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

案	期待する変化	必要な作業	主なリスク	未確認の前提	最小検証
A：既存手順を改善	手戻りを減らす	現行資料の整理	効果が限定的	時間がかかる箇所	1案件で手順比較
B：AIで下書き	初稿作成を補助	入力形式とレビュー設計	誤りの確認が必要	入力情報の品質	匿名データで試す
C：工程自体を変更	作業を短縮する可能性	関係者調整	導入負荷が大きい	受け入れられるか	担当者へ聞く

この表は検討方法の例で、特定の施策が有効だと示すデータではありません。「効果が大きい」とAIが書いた場合、その予測を支える実測や根拠があるかを別に確認します。実測がない段階では、予測を確定値のように比較せず、「期待」「仮説」と明記します。

会話を次の検証へつなぐPrompt

次のPromptは、壁打ちの終盤で使う枠組みです。AIに案を選ばせるのではなく、何を確かめれば判断が進むかを整理させます。

ここまでの会話から、確認済み事実・仮説・未確認事項を分けてください。選択肢を最大3案に整理し、各案について期待する変化、必要作業、主要リスク、採用をやめる条件を同じ表にしてください。最終案を決めつけず、判断を変える未確認事項を上位3つに絞ってください。各項目を確かめる最小の行動と、結果がどうなら次へ進むかも提案してください。入力にない事実は追加せず、不明は不明と記載してください。

回答に根拠のない統計や市場情報が混ざった場合は削除し、必要なら調査先を別途決めます。検証計画は、担当者、期限、観察する指標、停止条件を含めます。実験できない場合は、その理由と判断に残る不確実性を記録します。

企画のサイズに合わせて検証を選ぶ

次の行動は、大きなPoCやシステム開発である必要はありません。相手に5分聞く、手作業の既存データを1件だけ分類する、紙の画面案を見せる、料金表を公式情報で照合するなど、いちばん不確実な前提に直接触れる小さな方法を選びます。顧客や市場の事実を確かめたいのに、AIへ追加でブレインストーミングさせるだけでは根拠は増えません。

検証の前に「何が分かれば仮説を残すか」「何が起きたら案を止めるか」を書きます。条件を先に決めれば、結果を見てから都合よく成功と解釈しにくくなります。関係者への聞き取りでは誘導質問を避け、まず現在の行動や困っている場面を聞きます。数人の回答は探索の手がかりにはなりますが、市場全体の割合を示す調査と同じではありません。

壁打ちが空回りするとき

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

症状	起きやすい原因	修正
一般論ばかり返る	対象・現状・制約が不足	一つの具体的な場面を追加
AIがすぐ結論を出す	質問工程を飛ばしている	「提案前に質問」と役割を指定
どの案も魅力的に見える	同じ基準で比較していない	費用・作業・リスク・撤退条件を揃える
会話が長くなる	要約と終了条件がない	途中要約と次の一手を決める
反論が的外れ	入力の前提が誤っている	事実と仮説を再確認して要約を直す
実行へ進めない	検証が大きすぎる	一番不確かな前提を小さく確かめる

AIは利用者の言い方や提供した情報に引きずられることがあります。賛成案を出した後に反論を依頼しても、十分に独立した検討になる保証はありません。重要な企画では、関係者や対象ユーザーなど別の情報源で確認します。Promptを工夫するだけで判断の偏りが消えるとは考えないでください。

AIものさしの判断

壁打ちの成果は、AIが選んだ企画案ではなく、本人が前提と判断材料を説明でき、次に試すことを決められた状態です。背景を渡す、質問させる、要約を確認する、反論を分ける、選択肢を揃える、最小の検証へ進む、という順で使います。

企画の中身がまだ曖昧なら、まず質問と要約で整理します。前提は揃ったが方向が複数あるなら、案ごとの制約・リスク・撤退条件を比較します。市場や顧客に関する事実が不明なら、AIが出した説明を事実扱いせず、その情報を確認する行動へ進みます。個人情報や機密情報を扱う場合は、入力前に利用環境のデータ取扱条件を確認します。

AIものさしでは、会話の回数や案の数より、未確認事項が見えることと、次のactionが具体化することを重視します。企画の採否を最終決定するのは、制約や責任を引き受ける人です。

会話ログを意思決定メモへ変える

壁打ちの内容をそのまま企画書へ貼るのではなく、最後に短い意思決定メモへ変換します。最低限、決めたこと、まだ決めていないこと、根拠として確認できたこと、次の検証、担当と期限を分けます。AIが提案した表現と、本人やチームが合意した内容を混同しないよう、決定者が確認してから共有します。

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

記録欄	書く内容
現時点の判断	採用・保留・見送りと、その理由
根拠	直接確認した資料・聞き取り・数値
仮説	まだ確かめていない見立て
次の検証	誰が、いつまでに、何を確かめるか
見直し条件	どの結果なら判断を変えるか

これを残すと、別の日に会話を再開したときも、AIの直近回答を「前回の決定」と誤認しにくくなります。