icp

手順

セットアップ状態。 2026年6月8日に、ウェブサイト／導入事例の情報をもとに設定済みです（Path B — CRM は未接続）。3つのセグメント：クラウドネイティブな B2B SaaS エンジニアリングチーム（従業員数100～1,000人、B2B SaaS、AWS を優先、シリーズ B 以降）、フィンテックおよび決済インフラ（従業員数50～500人、フィンテック／決済、クラウドネイティブ、コンプライアンス重視）、デジタルメディア、ストリーミング、ゲーム（従業員数200～2,000人、大規模トラフィックのコンシューマープラットフォーム）。4つのペルソナ：SRE／プラットフォームエンジニア（推進者）、エンジニアリング担当 VP／ディレクター（経済的意思決定者）、DevOps 責任者／インフラストラクチャリード（推進者／評価者）、エンジニアリング担当 COO／CTO（経済的意思決定者、フィンテックセグメント）。次の改善点：CRM を接続し、実際の受注／失注データと照合して検証します。

このスキルでできること

日常的な業務は2つです。

1. 改善 — 実際に受注につながっている要素を抽出し、現在の ICP で見落としているパターンや過大評価しているパターンを見つけ、ユーザーの承認を得てから保存する変更案を提示します。
2. セグメントの追加 — 独自のアプローチが生まれたとき、現在のセグメントに加えて ICP セグメントを定義します。

初回のディスカバリーは Setup で行います。状態チェックで指示された場合は、読み込んでください。

---

改善の流れ

ステップ 1 — 定義済みの内容を読み込み、表示する

現在のセグメント、ペルソナ、ターゲット市場、バリュープロポジションを取得します。改善対象を思い出せるよう、それぞれ1～2行でユーザーに提示します。「特に違和感のある点はありますか？それとも、最近の案件を幅広くスキャンしましょうか？」と尋ねます。

ステップ 2 — 最近のクローズ済み案件を取得する

まずは直近6か月の受注および失注案件に絞ります。CRM が接続されている場合は CRM を確認し、案件ステージの履歴、関連する企業、クローズ日、入力済みであれば受注／失注理由を取得します。ページサイズは20です。

期間内にクローズ済み案件が60件を超える場合は、swan-execute-code に切り替えます。案件のクエリ結果をファイルに出力し、そこで集計します。200件の案件レコードをコンテキストに読み込まないでください。

CRM が接続されていない場合は、直近の受注案件と失注案件をそれぞれ5～10件、ユーザーに挙げてもらいます。挙げられない場合は、まだ改善できません。CRM の接続、または案件がさらにクローズした後に再度実施することを勧めてください。

ステップ 3 — 各案件の企業について企業属性を取得する

まず Swan の企業レコードを検索します。従業員数、業種、または企業ステージが欠落しているレコードが20％を超える場合は、その不足を明示します。補うためにすべてをエンリッチしないでください。データがなければ分析は不完全になるため、その旨を伝えます。

ステップ 4 — パターンを見つける

swan-execute-code で（または案件が20件以下なら手作業で）、受注と失注を次の項目ごとに分類します。

• 業種 — どの業種で受注の割合が高いか？
• 従業員数の範囲（1-50、51-200、201-1000、1000+）— どの範囲で受注率が最も高いか？
• 資金調達ステージ／企業ステージ — 同様に確認します。
• 地域 — 同様に確認します。
• 受注／失注理由が入力されている場合は、それぞれで最も多い理由を5つ挙げます。

項目ごとに簡潔な表を出力します。案件の生データを貼り付けないでください。

ステップ 5 — 改善案を提示する

パターンを現在の ICP と比較し、次の点を確認します。

• 範囲が広すぎる — セグメントの条件より狭い範囲に受注が集中している。
• 範囲が狭すぎる — 受注が指定範囲の外にも広がっている。
• 除外条件が不足している — 失注が集中している一方で受注がない項目（「ヘルスケア分野で失注が続いています。対象外にすべきでしょうか？」など）。
• 新しいセグメント — 受注が集中するまとまりが、現在のどのセグメントにも当てはまらない。
• ペルソナのずれ — 受注案件の実際の署名者／推進者が、保存済みのペルソナと一致しない。

変更案ごとに1行で記述します。「従業員数の範囲を50～300人に絞ります（現在：50～1,000人）。受注は50～300人に集中し、500人を超えると失注が急増しています。」

変更案は3～5件提示します。それ以上ある場合は、ICP に対して本格的なディスカバリーが必要です。Setup に誘導してください。

Step 6 — 確認して保存する

適用する変更をユーザーに尋ねます。確認された変更ごとに、以下を実行します。

• セグメント境界の変更 → 既存のセグメントに対して swan-update-knowledge-segment を実行します。
• 新しいセグメント → swan-create-icp-segment を実行します。
• 新しいペルソナまたは明確化したペルソナ → swan-create-knowledge-persona または swan-update-knowledge-persona を実行します。
• 改善作業の途中でユーザーが明確にした価値提案 → swan-update-knowledge-value-prop を実行します。

保存した内容を確認します。改善内容を検証するため、次に未スコアのアカウントをスコアリングすることを推奨します。

---

望ましい状態

優れた改善作業では、以下を満たします。

• まず矛盾を見つけます。 最も重要な成果は、実際の受注と、提示された ICP が食い違っている箇所です。最初にそれを示します。
• 見落とされている点を明らかにします。 失注は、現在の ICP がまったく触れていない要素に集中しています。件数だけでなく、その要素を明らかにします。
• 実際の商談に基づきます。 提案する変更にはすべて、具体的なパターンを示します（「受注 12 件中 8 件が従業員数 200 人未満、失注 7 件中 5 件が 500 人以上」など）。根拠のない意見は提案に含めません。
• いつ終えるべきかを判断します。 現在の ICP が正しいというデータがあるなら、適切な結論は「意味のある乖離はなく、ICP は妥当です」です。成果を出しているように見せるために変更を捏造することは、最も避けるべき失敗です。
• ペルソナを別の作業ではなく ICP の一部として扱います。 受注案件の署名者は、同じ改善作業でペルソナの見直しに反映します。ペルソナを別のスキルに先送りしてはいけません。

避けるべき失敗：

• データにノイズがあるからといって、8 件の変更を提案すること。ユーザーが実行できるのは 8 件ではありません。重要な 3 件を選びます。
• 反対傾向を示す四半期が 1 回あっただけで、全面的な書き換えを推奨すること。乖離は複数の切り口にわたるパターンである必要があります。
• 保存前の内容確認を省略すること。ユーザーは変更ごとに承認する必要があります。
• 「新しい ICP がある」というユーザーの発言を、古い ICP を削除する許可として扱うこと。既存の状態を削除する前に確認します。

---

ルール

• 提案する変更はすべて、意見ではなく商談データに基づかせる必要があります。具体的なパターンを示してください。
• 提案する変更は 3～5 件に抑える必要があります。より大規模な見直しは Setup で行います。
• 保存前にユーザーの確認を得る必要があります。
• 確認対象となるクローズ済み商談が 10 件に満たない場合は、改善してはいけません。それ未満ではシグナルがノイズになります。
• 自動保存してはいけません。ユーザーが変更ごとに承認します。
• ペルソナを別のスキルとして扱ってはいけません。ペルソナは /icp に含まれます。

---

このスキルで今後追加する詳細ページ

組織の GTM の進め方が明確になるにつれて、以下を追加します。

• SegmentDeepDive.md — 組織に実質的に異なる進め方をするセグメントが 2 つ以上ある場合に、セグメントごとの改善手順をまとめます（そのセグメントで最も重要な要素、ノイズとなる失注など）。
• PersonaSharpening.md — ペルソナの作業が役職や責任範囲にとどまらず、キャリア段階のシグナル、活動のシグナル、除外条件にまで及ぶ場合に使用します（かつての ideal-buyer-profile の領域）。
• Drift.md — 組織に 4 四半期以上の履歴がある場合の乖離レポートの手順をまとめます（統合する場合は icp-evolution から取り込みます）。
• SegmentBirth.md — ある受注グループが他とは実質的に異なる場合に、新しいセグメントを立ち上げる手順をまとめます。