ペルソナ×AI｜作成プロンプトと合成ユーザーの使い方・危険性

来週の企画会議までにペルソナを固めたいと考えて生成AIに指示を出すと、名前も年齢も情報収集経路も揃った人物像が、数十秒で返ってきます。資料としては、よくできて見えます。困るのはその先です。

入力した資料のどこにも書いていない記述が、いつのまにか「顧客はこう考えている」という前提に変わっていきます。読みやすさが、確からしさに見えてしまうからです。

AIでペルソナをつくる目的は、精巧な架空人物を描くことではありません。チームの頭の中に散らばった顧客情報を並べ直し、まだ分かっていない点と、次のインタビューで壊すべき仮説を見える形にすることです。

この記事では、AIペルソナと合成ユーザーの違い、渡すべき入力情報、実務で使えるプロンプト、実在顧客での検証手順、そして危険な使い方までを扱います。

AIで作るペルソナとは｜完成品ではなく顧客仮説

AIペルソナとは、入力した顧客情報を一人の人物像へ再構成し、検証すべき仮説をチームで共有するための作業用モデルです。入力資料から根拠をたどれない属性や発言は、一次情報に入れません。実在顧客へ確認する前の推定として扱います。

そもそもペルソナは、対象顧客を「30代会社員」のような属性だけで捉えないための道具です。どの場面で困り、いまは何で代わりを済ませ、誰の影響を受けて決めているのでしょうか。そこまで具体化するから、企画と営業と開発がそれぞれ別の顧客を思い浮かべている状態に気づけます。

生成AIへ任せるのは、議事録やインタビュー記録に含まれる行動の分類、人物像の初稿、そして不明点の列挙までです。購買の決裁者、困りごとの発生頻度、既存のやり方を変えない理由。これらが資料にないなら、埋めさせずに空欄のまま出させます。

反対に、入力資料から追跡できない名前、趣味、発言、商品への期待が出力に混じっていたら、観察結果としては採用しません。AIペルソナの品質は、描写の細かさではなく、「入力から確認できる事実」「事実から置いた仮説」「まだ不明な点」が分かれているかで見ます。

属性より、行動と意思決定を中心に置く

年齢、性別、居住地といった属性は、利用場面や意思決定に効くと確認できた場合だけ使います。BtoBなら、役職名を並べるより、担当業務、評価指標、現在の手順、関係部署、予算の持ち方、導入時の障壁を書くほうが、判断にずっと近づきます。

AIペルソナと合成ユーザーの違い

顧客仮説を記述した資料をAIペルソナ、その仮説を条件として対話や反応を模擬するAIを合成ユーザーと呼びます。どちらの出力も、実在顧客の回答欄には入れません。静的な人物像と、応答を生成する仕組みは分けて管理します。

実務上の役割で並べると、両者の違いははっきりします。

合成ユーザーへ商品案を見せ、「買いますか」と尋ねた結果は、需要の証拠に数えません。その回答から、実在顧客の支払い、社内調整、継続利用を観察した事実へはさかのぼれないからです。実在顧客の代わりではなく、調査者の準備を助ける相手だと捉えてください。

合成ユーザーが役立つのは調査の予行演習

用途は、インタビュー前の質問案の点検に限ります。「不足している前提は何か」「賛成しやすい聞き方になっていないか」という観点で反応候補を出させ、質問票を直します。それだけでも、当日の一時間の使い方が変わります。回答は「AIが生成した反応候補」と明記し、顧客発話とは別の欄に置きます。

なお、AIとの対話を実在の回答者へ実施する場合は、設計も限界も別の話になります。同意の取り方、回答の記録方法、AIが誘導していないかの確認まで、事前に決めておく必要があります。

ペルソナ作成前にAIへ渡す情報

AIペルソナの質を決めるのは、プロンプトの技巧ではありません。入力する顧客事実の範囲と、AIに補完させない項目を先に決められているかどうかです。入力が社内の思い込みだけなら、出力も思い込みを読みやすく整えたものになります。

まず、ペルソナ作成の用途を一文にします。「営業資料を作る」では広すぎます。「顧客インタビューの募集条件と質問項目を決める」「試作品で確かめる利用場面を一つ選ぶ」。ペルソナを見た後に何を決めるのかまで書いてください。

次に、材料を情報源ごとに分けます。顧客インタビューの原文、問い合わせ記録、商談記録、利用ログ。これらを混ぜて要約すると、顧客が述べたことと担当者が解釈したことの境界が消えます。各材料には、どの資料か、いつ取得したか、対象者はどんな条件の人か、該当箇所はどこかを付けます。利用目的や社内規程に照らして、生成AIへ入力してよい情報かどうかも先に確認します。

入力情報を6項目に分ける

AIへ渡す材料は、次の項目で整理すると不足が見つけやすくなります。

1. 今回の意思決定：ペルソナを使って何を決めるか
2. 確認済みの行動：顧客が実際に行った作業、選択、回避
3. 顧客の発話：原文、発話者の識別子、質問、前後の文脈
4. 利用状況：発生場面、関係者、現在の代替手段
5. 事業側の仮説：まだ顧客へ確認していない想定
6. 不明点：頻度、決裁、予算、切り替え条件など未取得の情報

顧客の発話を入力するときは、個人名、企業名、連絡先をそのまま渡さないでください。氏名を消しただけで入力可能とは判断せず、所属、役職、地域、案件内容まで含めて社内基準で確認します。利用するAIについても、提供元が示す契約条件、データ保持、学習利用、アクセス権限を確認し、扱えない情報は入力対象から外します。

入力がない項目は空欄にする

「すべて埋めて」と指示してはいけません。入力資料に根拠のない趣味、休日の過ごし方、好きな媒体が出てきたら採用しません。意思決定に不要なら項目自体を削り、必要なのに情報がないなら「不明」と表示させて、次の質問に変換します。

AIでペルソナを作成するプロンプトと手順

ペルソナ作成のプロンプトで指定すべきなのは、役割演技ではありません。利用可能な資料、事実と推定の分離、空欄の扱い、根拠の示し方、そして次の検証質問です。長い人物紹介を求めるのではなく、検証へ進める出力形式を固定します。

以下は、確認済み資料をもとに初稿を作るためのひな型です。角括弧の中を、自社の案件に合わせて置き換えてください。

目的：
［このペルソナを使って決めたいこと］

使用可能な情報：
［資料の識別情報、取得日、対象者条件、該当する発話・行動］

事業側の仮説：
［未検証であることを明記した仮説］

禁止事項：
- 入力にない年齢、社名、役職、発言、頻度、金額を補わない
- 顧客の発話と、あなたの推定を混ぜない
- 商品への好意や購入意向を創作しない
- 不明な項目は「不明」と書く

出力形式：
1. 対象者条件
2. 確認済みの行動事実（根拠となる資料の識別情報付き）
3. 現在の代替手段
4. 意思決定に関わる人物・条件
5. 仮説（各項目に反証条件を付ける）
6. 不明点
7. 次回インタビューで聞く質問
8. このペルソナを採用しない条件

このひな型の要点は、ペルソナを一枚の完成資料として出させないところにあります。事実、仮説、不明点、反証条件が分かれていれば、会議で「それは誰が言ったのか」と聞かれたときに、元の資料へ戻れます。

手順1｜複数の顧客をすぐ一人にまとめない

入力した複数人の発話に共通点があっても、利用場面や意思決定の構造が違えば別のセグメントかもしれません。AIにはまず、共通点だけでなく相違点と分類できなかった情報も出させます。都合のよい平均像を一人つくる前に、分けるべき顧客群がないかを見てください。

手順2｜根拠をたどれる形で人物像を組み立てる

「課題」「代替手段」「導入障壁」といった記述には、根拠になった発話や資料の識別情報を付けます。根拠が複数あるなら、ひとまとめにせず列挙します。根拠がない項目は仮説欄へ移します。

手順3｜反対のペルソナも出す

事業案に合う顧客だけを描くと、検証が確認作業に変わります。「同じ状況でもこの商品を選ばない人」「課題はあるが既存手段を変えない人」の条件も生成させてください。合成ユーザーに反論させる場合も、その回答は反証候補であって証拠ではありません。

手順4｜会議の前に人が原文を確認する

AIの要約だけを配らないことです。重要な記述は担当者が元の発話と突き合わせます。削るのは、原文が主張を支えていない場合、前後を読むと意味が違う場合、対象者条件が外れている場合です。インタビュー記録をAIで分類する工程そのものは、それだけで一本の手順書になる作業です。

模擬例｜AIの出力を顧客確認で更新・棄却する

AIペルソナは、確認済み事実、AIが生成した仮説、不明点、顧客への確認結果を同じ表で管理すると、残す記述と捨てる記述を判断しやすくなります。以下は手順を説明するために組み立てた架空の例です。

想定したのは、法人向け申請管理ツールの企画チームが、次回の顧客インタビュー条件と質問を決める場面です。入力資料にあるのは三つだけとします。担当者が会議後に申請内容を表計算ソフトへ転記していること、転記後に上長が確認していること、ツール変更時には情報システム部門との調整が必要だという発話です。

この例で大事なのは、最初のペルソナを詳しくすることではありません。「転記が面倒」という入力から「自動化を望む顧客」まで一気に飛ばず、どこをAIが補ったのかを残すことです。確認結果が予想と違ったなら、人物像に例外を書き足すのではなく、課題仮説そのものを棄却します。

同じ形式を使えば、顧客確認の後に変わった箇所が見えます。会議で確認するのは、完成した人物紹介ではありません。仮説ごとの根拠、反証条件、更新履歴です。これが、AIの出力を後から確かめられる作業資料として扱うための最小単位になります。

AIペルソナを実在顧客で検証する方法

検証で聞くのは、人物像全体への賛否ではありません。課題が起きた場面、現在の代替行動、意思決定の経路、切り替えない理由を、実在顧客の過去の行動から確かめます。「このペルソナは正しいですか」と尋ねても、事業判断に使える証拠は増えません。

進め方は次の順です。

1. 重要仮説を選ぶ。 間違っていたら企画を変える記述を優先し、装飾的な属性は後回しにします。
2. 反証条件を書く。 どんな発話や行動が出たら仮説を棄却するかを、面談の前に決めます。
3. 対象者条件を行動で定義する。 興味や自己申告ではなく、直近の業務経験、使った代替手段、意思決定への関与で募集条件を作ります。
4. 過去の場面を聞く。 理想や意向より、最後に課題が起きた日時、実際の手順、関係者、結果をたどります。
5. 発話と解釈を分けて記録する。 顧客の言葉、観察した事実、調査者の解釈、次の仮説を別の欄に置きます。
6. ペルソナを更新・分割・破棄する。 合わない事実を例外として消さず、別セグメントの可能性や企画側の前提を見直します。

検証結果は更新履歴として残す

ペルソナを上書きするだけでは、どの前提が崩れたのか分からなくなります。版ごとに「残した仮説」「修正した仮説」「棄却した仮説」「証拠が足りない仮説」を記録してください。差分の整理はAIに任せられますが、採否は担当者が原文を読んで決めます。

一次情報と二次情報の分け方と、AIが作った主張を原資料へ戻して確認する手順。この二つは、ペルソナ運用と並行して整えておきたい論点です。更新回数を成果にせず、次の仕様、募集条件、販売仮説がどう変わったかまで残しましょう。

AIによるペルソナ作成の危険性と対策

最も危険なのは、架空情報が混じった詳細な人物像を一次情報のように扱い、会う顧客と聞く質問をその人物像に合わせて狭めてしまうことです。見るべきは出力の流暢さではありません。根拠へたどれるか、反証があるかです。

危険1｜細かい設定が確度に見える

名前、年齢、趣味、好きなメディア、口癖まで出力されても、入力に根拠がなければ全て仮説欄へ移します。意思決定に影響しない項目は削り、必要な項目には根拠となる資料を紐づけます。

危険2｜チームの思い込みが増幅される

事業側が書いた課題だけを入力すれば、出力はその課題の言い換えにしかなりません。ペルソナを企画の正しさの証拠にはしないこと。反対材料、未分類の発話、既存手段を変えない理由も、同時に入力します。

危険3｜少数の違いが平均像に消える

複数人を一人へ統合する前に、顧客ごとの発話を識別できる状態にし、共通点と相違点を先に出します。統合後の記述を特定の顧客の原文へ戻せないなら、確認済み事実からは外します。購買経路や利用場面に異なる記録があるなら、最初から平均化せず、別の仮説として検証してください。

危険4｜合成ユーザーの賛成を需要と誤認する

合成ユーザーに商品案を評価させても、その出力から実在顧客の予算執行、社内説明、継続利用は確認できません。「好意的だった」「購入すると答えた」を需要検証の結果に入れません。用途は質問の予行演習と反論候補の発散に限ります。

危険5｜機密情報や個人情報を入力する

商談記録や顧客インタビューを、便利だからと一括で貼り付けないでください。入力前に、個人名、所属、未公開計画、取引条件が含まれていないかを確認します。利用環境についても、提供元の契約条件と自社の規程に照らし、入力可否、匿名化、保存、削除、権限を決めます。判断できない情報は入力しません。

公開・社内共有前のチェックリスト

• 各記述が「確認済み事実」「仮説」「不明」に分かれている
• 確認済み事実から、元の資料や発話原文へ戻れる
• 入力にない属性、発言、頻度、金額をAIが補っていない
• 事業案を選ばない条件と、仮説に反する材料が残っている
• 合成ユーザーの回答を顧客の声として扱っていない
• 実在顧客へ確認する質問と対象者条件が書かれている
• AIへ入力した情報の取り扱いを社内基準で確認した
• 最終判断者と更新責任者が決まっている

まとめ｜AIペルソナは顧客に会うための仮説として使う

AIで作るペルソナは、顧客情報を整理し、不明点と反証条件を共有するための仮説です。実在顧客の行動や発話そのものではありません。AIペルソナと合成ユーザーを使うなら、根拠を持つ事実、AIが補った推定、未確認事項を分けたうえで、顧客インタビューへつなぎます。

生成AIへ任せる範囲は、散らばった記録の分類、人物像の初稿、反対仮説、質問案の作成まで。細部まで埋まった架空人物を作り、その人物が商品を買うと出力されても、需要の証拠には数えません。決めるべきは、どの記述が間違っていたら企画を変えるかです。それを、実在顧客の過去の行動から確かめます。

顧客情報はあるものの、仮説と事実が混ざっています。AIで作ったペルソナを、どの対象者へどう検証すべきかも決まりません。インタビュー結果からペルソナを更新する運用もないままです。こうした状態で必要なのは、ペルソナ資料をさらに精緻にすることではありません。対象者条件、質問、反証条件、更新判断を、一つの検証計画へ落とす作業です。