icp-persona-builder

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	いいえ	ユーザーが指定、または調査で発見
クライアントコンテキストファイル	いいえ	利用可能な場合は clients/<client>/context.md

プロセス

フェーズ 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 リーダー」「スタートアップ創業者」「代理店運営者」）
役職／肩書き	このセグメントに典型的な職種名
企業プロフィール	規模、成長段階、業界、技術スタック
主な課題	解決策を探し始めるきっかけとなる最大の課題
購買のきっかけ	今すぐ検索を始めるきっかけとなる出来事
意思決定の基準	評価時に最も重視する項目（重要度順）
知識レベル	課題領域やソリューションの状況をどの程度理解しているか
代替案	ほかに検討する選択肢（競合製品、自社開発、現状維持）
セグメント規模の推定	企業にとってこのセグメントがどの程度の規模かの概算（主要、二次、新興）

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

• 少なくとも 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：ペルソナ資産の保存

再利用できる資産として、クライアントのディレクトリに保存します。

clients/<client>/personas/personas.json — 機械可読形式で、すべてのペルソナを配列に格納：

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

clients/<client>/personas/personas.md — すべてのペルソナを文章形式で記述した、人が読みやすい Markdown ファイル。レビューや共有が簡単です。

clients/<client>/personas/segments.md — 主要属性を含む全セグメントのサマリーテーブル。クイックリファレンスとして便利です。

出力の概要

作成後、以下を提示します。

1. セグメント概要表 — 主な属性をひと目で確認できる、すべてのセグメント
2. ペルソナの概要 — 各ペルソナについて2～3文でまとめた概要
3. カバレッジの確認 — 多様性のルール（技術、ビジネス、懐疑的な視点、研究者）が満たされていることの確認
4. 次のステップ — icp-website-review や、ペルソナを活用できるその他のスキルの実行を提案します

ヒント

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

依存関係

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