曖昧な課題を1文で言語化する問題定義

問題定義プロンプトが必要になるのは、大抵「何かうまくいっていない」ということだけが分かっている段階です。その状態のままAIに聞くと、解決策ばかりが次々と提示されてしまいます。「完走率が低い」と伝えただけなのに、リマインド通知、コミュニティ形成、修了証の付与といったアイデア一覧が返ってくることになります。肝心の「何が問題なのか」をまだ誰も合意していないにもかかわらずです。

そのため、第3段落の逆質問が重要な役割を果たします。メモだけでは、第3回で離脱する理由が時間の長さなのか難易度なのか判断できません。人が情報を補う前にAIから質問させることで、勝手な憶測や思い込みの上に企画が組み立てられるのを防げます。質問を3つに限定しているのは、やり取りが長引いて本来のアウトプットが得られなくなるのを防ぐためです。

第1段落の**文脈（コンテキスト）**で対象者を特定するのも同じ意図です。「受講生」と「仕事終わりに受講する社会人の学習者」では、導き出される課題がまったく異なります。タスク段落で指定した4要素は、問題定義文が満たすべき最低限の構成です。特に「その結果何を失っているか」が抜けると、本当に解決すべき価値のある問題なのかどうかを判断できません。

制約でスコープの異なる3パターンを求めている理由は、問題定義とは本質的に「選択」だからです。狭く捉えれば今月中に対応できますし、広く捉えればサービス方針そのものの見直しになります。各文の下に「何をやらないことになるか」を添えることで、その選択に伴うトレードオフが可視化されます。メモを"""で囲んでいるのは、メモ内の記述がプロンプトへの指示として誤認されるのを防ぐためです。

すぐに改善案が10個ほど提示されます。一つひとつはそれらしく見えますが、どれも「第3回で離脱が集中している」という事実にフォーカスしていません。課題が定義されないまま出されたアイデア一覧には優先順位の基準がなく、結局ミーティングでゼロから議論し直すことになります。不足している前提をAIが聞き返してもくれないため、誤った前提のまま話が進んでしまいます。