ペルソナとは——ソフトウェア設計の歴史から学ぶBtoBでの作り方

ペルソナとは、調査や顧客データをもとに作る典型的な顧客像です。BtoBでは、架空の名前や趣味を細かく設定することが目的ではありません。勤務先の課題、購買での役割、判断基準、情報収集の状況を、企画に使える形で共有します。

ペルソナとは何か

Salesforceの解説は、商品・サービスの典型的なユーザー像としてペルソナを紹介しています。「仮想の人物」と呼んでも、根拠のない事情を事実として足すわけではありません。

BtoBの記事企画では、企業としての条件と、企業内で誰がどんな判断をするかを分けると整理しやすくなります。これは本記事の整理方法であり、「2つの層」という統計値ではありません。

年齢、部署、役職だけでは、その人が何を知りたいかは分かりません。同じ広報部長でも、新しくオウンドメディアを立ち上げる人と、更新が止まったメディアを引き継いだ人では、検索する言葉も必要な情報も変わります。

ペルソナはどこから来たか

ソフトウェア設計者のAlan Cooperによる実践は、現在のペルソナを理解するためによく参照される系譜の一つです。本人の回顧は、顧客像を飾ることよりも、誰の目標に合わせて設計を選ぶかに焦点を当てています。

Cooperの「The origin of personas」は、2008年の本人による回顧記事の保存版です。Kathyをもとに利用場面を演じた段階から、複数の利用者像をチームへ説明する段階への変化が書かれています。これは著者自身の実践の説明で、あらゆるペルソナの起源を一人へ確定するものではありません。

John PruittとJonathan Grudinの「Personas: Practice and Theory」（2003年）は、約3年間の実践を踏まえ、ペルソナを他のユーザビリティ手法を補うものと位置づけています。定性・定量の情報を伝える使い方を述べた論文であり、ペルソナのシートだけで調査を代替できる、という意味ではありません。

BtoBへ応用する際も、人物紹介の詳しさより、「どの資料に基づき、誰のどの判断を助けるか」を共有する道具として考えます。

ターゲットとの違い

ターゲットは、狙う市場や顧客層です。ペルソナは、その対象のなかで典型的な課題と行動を持つ人物像です。

ターゲットを決めずにペルソナだけを作ると、市場として成立するかが見えません。ターゲットだけでは、同じ企業内でも異なる判断の場面を見落とす場合があります。必ず名前付きのシートを作る必要はありませんが、記事ごとの対象者と問いは具体化します。

一つの進め方として、まず自社が価値を出しやすい企業群を選び、その企業内で、誰がどんな状況で判断するかをペルソナとして具体化します。

似た顧客モデルを分ける

「顧客像」と呼ばれる資料には、対象と使い道が異なるものがあります。本記事では、ICP（Ideal Customer Profile）を自社に適合する企業の条件、ペルソナを個人の目標や判断のモデルとして分けます。会社としての優先順位と、個人へ伝える情報を一枚で決めようとすると、用途が曖昧になります。

BtoBでは、製品を日常的に使う人と、契約を推進する人が異なる場合があります。たとえば現場担当者は操作性を重視し、情報システム部門は安全性を確認し、決裁者は投資効果を見ます。一枚の「担当者ペルソナ」へ統合せず、今回の意思決定に必要なモデルを選びます。

BtoBは二層で考える

BtoBでは、個人だけを見ても購買を説明できません。会社としての条件と、その会社内での役割を分けます。

• 企業プロファイル：業界、従業員規模、事業モデル、地域、利用中の仕組み、成長段階など、自社サービスと相性のよい企業条件を示します。
• 業務上の課題：売上停滞、採用難、属人化、更新停止など、会社や部門が解こうとしている問題です。購入のきっかけになります。
• 購買上の役割：利用者、推進担当、専門確認者、決裁者などです。同じ会社でも、役割によって必要な情報が違います。
• 個人の判断状況：目標、評価指標、懸念、決裁権、情報収集方法、期限です。年齢や趣味より企画へ直接使えます。

例えば、記事制作サービスの対象を「従業員300名以上の製造業」と決めても、技術広報担当、マーケティング責任者、事業部長では目的が違います。技術広報担当は専門家の協力を得られるかを気にし、責任者は問い合わせとの関係を見ます。事業部長は投資の優先順位を判断します。

BtoBマーケティングとはで説明した通り、BtoBの購入には複数人が関わる場合があります。ペルソナは一人に絞って書きますが、一人だけで購買が完結する前提にはしません。

想像ではなく情報から作る

ペルソナの精度は、プロフィールの細かさではなく、根拠の質で決まります。社内の思い込みだけで作ると「自社に都合のよい顧客」になります。

一人の印象的な顧客だけで作ると、特殊な事情を一般化する危険があります。複数の顧客と営業記録を比べ、共通する課題と、条件によって変わる点を分けます。まだ顧客が少ない新規事業では、仮説と明記し、商談やインタビューのたびに更新します。

根拠の強さを混ぜない

ペルソナの各項目に、同じ確かさがあるとは限りません。顧客の発言、行動データ、社内の推測を分けて記録すると、議論が「その人物らしいか」ではなく「何を追加調査すべきか」に変わります。

顧客本人から具体的な判断場面を聞き出す方法は、読まれるインタビュー記事の構成と編集の技術で紹介している、仮説・深掘り・具体化の考え方を応用できます。

作成する6ステップ

ペルソナ作成会議だけで項目を埋めないことが重要です。会議は、集めた情報を解釈し、企画に必要な焦点を決める場です。データがない項目は空欄か仮説にし、確認方法を決めます。

Nielsen Norman Groupは、新たな調査を伴わない暫定モデル、定性調査から作るモデル、定性・定量を組み合わせるモデルを区別しています。仮説を整理したシートは調査済みの人物像とは呼ばず、インタビューから得た共通点も、それだけで市場の何割を占めるかは分かりません。アクセス解析だけでは目標や理由を十分に捉えられない点も踏まえ、何を調べ、何がまだ不明かを残します。

BtoBペルソナの項目

氏名、顔写真、趣味は、チームが人物を思い浮かべる助けになる場合だけ入れます。BtoBの記事企画では、決裁権、目標、懸念、情報行動のほうが優先度は高くなります。

架空の取材メモから一枚にする

以下の会社、発言、資料A〜C、顧客像は、説明のために編集部が作った架空の設定です。実際に顧客を取材した結果ではありません。 技術記事の企画を考える担当者が、製造業の広報の困り事を整理する練習として読んでください。

最初から名前や年齢を決めず、同じ問いで資料を比べます。今回の問いは「技術記事の制作が止まるとき、どの判断が残っているか」です。

AとBに共通するのは、書く材料がないことではなく、公開前の確認について解く問いが残っている点です。ただし、Aの図面の公開範囲とBの担当の不明確さは同じ原因とは限りません。まとめるときも両方を残します。Cは取り除かず、「今は別の問いを持つ例」として保管します。3件の架空例から実際の市場の割合は計算しません。

記入済みのペルソナ例

この例で作るのは、記事企画の焦点を選ぶための暫定モデルです。資料から移せること、編集上の解釈、次に聞くことを分けます。実務では、出所IDに加えて確認日・記録箇所も付けます。

この人物像から立てる記事案は、「技術記事の公開範囲と確認担当を整理する方法」です。「製造業の広報は全員、図面を出せず困っている」とは言いません。社内の手順を確認する前に記事を増やすより、確認表を作って関係者と話すほうが先かもしれません。

企画は、実際の追加取材で確認順が原因ではないと分かれば変えます。ペルソナの文章が完成したことと、企画の前提が確かめられたことは別です。記事の問いへ変換する際は、記事の切り口を決める方法も参照できます。

次の取材で聞くこと

理由を誘導する「確認が遅いから困っていますよね」ではなく、直近の一件をたどります。

1. 最後に制作した技術記事は、何を伝える予定でしたか。
2. どこで止まりましたか。その前後に何が起きましたか。
3. 誰に何を確認し、どんな資料を渡しましたか。共有できる範囲で記録も確認できますか。
4. ほかの進め方を試しましたか。その方法を選ばなかった理由は何ですか。
5. 同じ確認をせずに進められた記事はありましたか。今回と何が違いましたか。
6. 次に進むには何を決める必要があり、誰が判断しますか。

質問の狙いと追加で確かめる資料は、インタビュー質問の設計の方法で整理できます。回答を残すときは、取材メモの取り方に沿って、話者の発言、別途確認した事実、編集者の解釈を分けておくと、後からモデルを見直せます。

AIに記録の整理を手伝わせる場合も、共有してよい資料だけを使い、出所IDのない推測は採用しません。AIがもっともらしい人物紹介を出したことは、顧客調査を行った証拠にはなりません。

失敗するペルソナ

特に危険なのは、複数の購買関与者を「平均的な担当者」へまとめることです。推進担当者の課題と決裁者の判断基準が混ざり、誰にも十分に届かないメッセージになります。中心人物を一人選び、他の関与者は関係図として整理します。

ペルソナにも限界がある

ペルソナは現実を圧縮したモデルです。少数の典型へ注目するため、頻度は低くても重大なニーズを持つ人、障害のある利用者、既存分類に当てはまらない人を見落とす危険があります。

• 典型像を性別、年齢、国籍の固定観念で補わない。
• 一つのペルソナを全顧客の代表だと考えない。
• 成約した顧客だけでなく、失注、解約、対象外の理由も確認する。
• アクセシビリティや法的要件を「少数だから」とペルソナ判断だけで外さない。
• 市場規模や優先順位は、ペルソナではなく定量データと企業戦略でも判断する。

ペルソナに書いていない人を無視するのではなく、どの意思決定を単純化するモデルかを明記します。モデルの外側にある重要な条件は、別の要件や調査として管理します。

コンテンツ企画に使う

ペルソナは資料として保管するためではなく、企画の選択肢を絞るために使います。

誰がどの段階で何を知るかを複数の接点へ展開する方法は、次回のカスタマージャーニーとはで説明します。

取材から顧客像を作る

顧客像が社内の想像で割れている場合、資料づくりより取材が先です。既存顧客、営業、カスタマーサクセスの話を同じ質問で集め、共通点と違いを編集します。

まとめ

ペルソナは、架空の人物を精密に作る作業ではありません。顧客に関する証拠を集め、チームが同じ判断をするためのモデルへ編集する作業です。

ソフトウェア設計の実践から学べるのは、目標を持つ利用者の視点で選択理由を説明することです。BtoBへ応用するときも同じです。企業条件、購買上の役割、目標、判断の障害を分け、事実・パターン・仮説の強さを示します。項目を増やすより、「この人の、どの判断を助けるのか」に答えられる状態が重要です。

よくある質問

ペルソナは何人作るべきですか

決まった人数はありません。最初は、重要な商品と意思決定に関わる中心人物を一人選びます。必要な判断基準が明確に違うと確認できた場合だけ分けます。人数を増やすほど、企画の優先順位はつけにくくなります。

実在の顧客一人をペルソナにしてよいですか

出発点にはできますが、その人固有の事情を典型だと誤認する危険があります。複数の取材、商談記録、行動データを比べ、繰り返すパターンを抽出します。実在人物の個人情報をそのまま共有しない配慮も必要です。

名前や顔写真は必要ですか

必須ではありません。チームが目標と状況を思い出す助けになる場合に使います。写真や趣味が先に印象を作り、根拠のない固定観念を強めるなら省きます。

新規事業で顧客がいない場合はどうしますか

まず既存の知見と仮説を暫定モデルにまとめ、未確認の項目、検証する質問と期限を決めます。そのうえで想定利用者や業界の関係者へ話を聞き、何を実際に確認できたかに応じてモデルを作り直します。

ペルソナはいつ更新しますか

新しい顧客層への展開、商品・価格の変更、購買関与者の変化があったときに見直します。定期的には、商談質問、失注理由、利用行動を四半期などの区切りで確認し、判断に使われない項目を減らします。

主な参考資料

• Alan Cooper「The origin of personas」（Cooper Journal掲載記事の保存版）
• John Pruitt, Jonathan Grudin「Personas: Practice and Theory」（2003年、Microsoft Research。公開PDFと掲載ページを確認）
• Salesforce Japan「ペルソナとは？マーケティングにおける活用方法や作り方、具体例」（2026年10月15日確認）
• ワンマーケティング「2025年度版 BtoB購買プロセス白書」（全体n=600、初回面談の設問n=96）
• Nielsen Norman Group「3 Persona Types: Lightweight, Qualitative, and Statistical」（2020年）

※ ペルソナの歴史には、Cooper本人による回顧と後年の研究を用いています。記事内の人物例は、BtoBでの考え方を説明するための仮想例です。実在の顧客事例ではありません。