buyer-persona-generator

ICP ペルソナビルダー

企業の購買セグメントを調査し、理想的な顧客をモデル化した詳細な合成ペルソナを作成します。これらのペルソナは再利用可能なクライアント資産になります。一度作成すれば、どのスキルからでも読み込み、買い手の視点でコンテンツ、メッセージング、ウェブサイト、キャンペーンを評価できます。

クイックスタート

Build ICP personas for [company]. Their site is [url].

既知の ICP がある場合：

Build personas for [company]. Their ICPs are: [ICP 1], [ICP 2], [ICP 3].

入力

入力	必須	ソース
企業名	はい	ユーザーが提供
企業 URL	推奨	調査に役立ちます
既知の ICP	いいえ	ユーザーが提供するか、調査で特定
クライアントのコンテキストファイル	いいえ	利用可能な場合、既存の企業コンテキストファイル

プロセス

フェーズ 1：企業調査

企業が何を提供し、誰を対象としているかを把握します。

1. WebFetch でウェブサイトを取得 — ホームページ、製品／ソリューションのページ、料金ページ、「対象者」ページ
2. WebSearch で検索：
   • 「[company] customers」／「[company] case studies」
   • 「[company] reviews」（G2、Capterra、TrustRadius）
   • 「[company] vs」（比較検索から購買セグメントがわかります）
   • 「[company] jobs」（誰に販売／サポートするための人材を採用しているか）
3. 次の情報を抽出：
   • どのような問題を解決していますか？
   • 料金／パッケージはどうなっていますか？（ACV と買い手のタイプを示します）
   • どの業界／業種を対象としていますか？
   • どの規模の企業を対象としていますか？
   • ケーススタディや推薦文にはどのような役職／肩書きが登場しますか？
   • 市場投入の形態はどのようなものですか？（セルフサービス、営業主導、ハイブリッド）

フェーズ 2：ICP セグメントの特定

調査結果から、4〜6 個の異なる購買セグメントを特定します。各セグメントは、役職、企業プロフィール、または購買動機が異なる、意味のある買い手のタイプを表す必要があります。

各セグメントについて、次の項目を定義します。

属性	説明
セグメント名	短い名称（例：「エンタープライズ IT リーダー」「スタートアップ創業者」「代理店運営者」）
役職／肩書き	このセグメントに典型的な職務上の役職
企業プロフィール	規模、成長段階、業界、技術スタック
主な課題	解決策を探すきっかけとなる最も大きな問題
購買のきっかけ	今すぐ検索を始めるきっかけとなる出来事
判断基準	評価時に最も重視すること（重要度順）
知識レベル	問題領域と解決策の選択肢をどの程度理解しているか
代替案	他に検討する可能性のある選択肢（競合他社、DIY、現状維持）
セグメント規模の推定	企業にとってのこのセグメントの規模の概算（主要、二次、新興）

セグメントの多様性に関するルール：

• 少なくとも 1 つは技術系の買い手にする（機能、アーキテクチャ、連携機能を評価する）
• 少なくとも 1 つはビジネス系の買い手にする（ROI、成果、競争優位性を評価する）
• 少なくとも 1 つは懐疑的なプロフィールにする（過去に失敗を経験しており、説得が難しい）
• 少なくとも 1 つは若手／リサーチ担当者にする（意思決定者に代わって初期調査を行う）
• 企業が複数の層を対象としている場合は、さまざまな企業規模を網羅する

フェーズ 3：合成ペルソナの作成

各セグメントについて、詳細な合成ペルソナを作成します。ペルソナはマーケティング上の抽象概念ではなく、実在する特定の人物のように感じられるものにします。

ペルソナの構成：

{
  "id": "persona-slug",
  "name": "Jordan Chen",
  "segment": "Enterprise IT Leader",
  "title": "VP of Engineering",
  "company": {
    "type": "Mid-market SaaS company",
    "size": "200-500 employees",
    "stage": "Series B, scaling fast",
    "industry": "Financial services technology"
  },
  "demographics": {
    "experience_years": 12,
    "reports_to": "CTO",
    "team_size": 35,
    "budget_authority": "$50K-200K without board approval"
  },
  "situation": "Jordan's team is growing faster than their tooling can support. They've been using a patchwork of internal scripts and are losing engineering hours to maintenance. The CTO has asked Jordan to evaluate modern solutions before next quarter's planning cycle.",
  "pain_points": [
    "Team productivity is dropping as they scale",
    "Current tools don't integrate well",
    "Onboarding new engineers takes too long"
  ],
  "buying_trigger": "CTO mandate to evaluate solutions before Q3 planning",
  "decision_criteria_ranked": [
    "Enterprise security and compliance (SOC2, SSO)",
    "Integration with existing stack (GitHub, Jira, Datadog)",
    "Scalability — will this work at 2x team size?",
    "Total cost of ownership, not just sticker price",
    "Implementation timeline — needs to be live in 6 weeks"
  ],
  "skepticism_profile": {
    "trust_level": "Low — has been burned by vendor promises before",
    "research_style": "Deep dive. Reads docs, checks GitHub issues, asks peers in Slack communities",
    "key_objections": [
      "Will this actually scale or will we outgrow it in a year?",
      "What's the real implementation cost beyond the license?",
      "How good is the support when things break at 2am?"
    ]
  },
  "technical_sophistication": "High — understands the technical landscape well, can evaluate architecture decisions, wants to see under the hood",
  "language": {
    "describes_problem_as": "We need to consolidate our toolchain and reduce operational overhead",
    "searches_for": ["engineering productivity platform", "developer tools consolidation", "[competitor] alternative enterprise"],
    "red_flag_words": ["revolutionary", "AI-powered", "seamless" — overpromising triggers skepticism],
    "trust_signals": ["SOC2 badge", "customer logos in their industry", "transparent pricing", "public changelog"]
  },
  "evaluation_behavior": {
    "first_visit": "Scans headline, checks if it's for their company size, looks for enterprise/security page",
    "deep_evaluation": "Reads docs, checks integrations list, looks for case studies from similar companies",
    "social_proof_needs": "Wants to see companies their size in their industry, not just FAANG logos",
    "deal_breakers": ["No SSO/SAML", "No self-hosted option", "Pricing only available via sales call"]
  }
}

フェーズ 4：ペルソナ資産の保存

再利用可能な資産として、クライアントディレクトリに保存します。

personas.json — すべてのペルソナを配列にまとめた機械可読形式です。現在の作業ディレクトリ、またはユーザーが希望する場所に保存します。

{
  "company": "Acme Corp",
  "url": "https://acme.com",
  "created": "2026-02-26",
  "segment_count": 5,
  "personas": [ ... ]
}

personas.md — すべてのペルソナを文章形式で記述した、人が読みやすい Markdown 形式です。確認や共有が簡単です。

segments.md — すべてのセグメントの主要属性をまとめた概要表です。クイックリファレンスとして役立ちます。

出力の概要

作成後、次の内容を提示します。

1. セグメント概要表 — 主要属性を一覧できる、すべてのセグメントの表
2. ペルソナの概要 — 各ペルソナを 2〜3 文で要約
3. 網羅性の確認 — 多様性に関するルール（技術系、ビジネス系、懐疑的、リサーチ担当者）を満たしていることを確認
4. 次のステップ — icp-website-audit や、ペルソナを活用できる他のスキルの実行を提案

ヒント

• 調査の深さが重要です。 フェーズ1には十分な時間をかけてください。企業の実際の顧客をよく理解するほど、ペルソナの現実味が増します。ホームページを読むだけでなく、レビュー、事例、求人情報も詳しく調べてください。
• ペルソナは具体的に設定してください。「マーケティングマネージャー」では漠然としすぎています。「予算削減でSDRチームを失ったばかりの、従業員50人のB2B SaaSスタートアップに勤めるシニア需要創出マネージャーのSarah」なら、ツールをどのように評価するかがはっきりとわかります。
• 言葉の違いも含めてください。 ペルソナが問題を表現する言葉は、ベンダーがソリューションを説明する言葉とはまったく異なることがよくあります。このギャップが、メッセージングがうまく伝わらない原因です。
• 懐疑心が最も重要な特性です。 すべてのペルソナに、明確な懐疑心の傾向を設定してください。どのようなことがあれば購入しないでしょうか。ベンダーについて、どのような先入観を持っているでしょうか。
• このスキルにはコードスクリプトがありません。 WebSearch と WebFetch を使ってエージェントが実行します。上記の体系的なプロセスに沿って、調査とペルソナ作成を進めてください。

依存関係

• ウェブ検索機能（企業とICPの調査用）
• ウェブ取得機能（ウェブサイトのページを読むため）
• APIキーや有料ツールは不要です