warm-path-workspace

ウォームパス・ディールワークスペース

「この会社と、LinkedIn でのつながりはこちらです」から、アカウントチームが実際に知りたい 2 つの問い、つまり誰が意思決定するのか、そしてその相手につないでくれる知り合いがすでにいるかに答える、自己完結型で共有可能な HTML ワークスペースを作成します。

ステークホルダーマップの多くは、最初の問いに答えたところで終わります。商談の成否を分けるのは 2 つ目の問いです。そしてここは、人々が実態を偽りがちな部分でもあります。すべてのつながりから買い手へ直結する線を引いてしまうため、インターンが VP と同じくらい価値があるように見えてしまいます。このスキルは代わりにすべての経路を評価するので、担当者は最も限られたリソース（チームメイトが紹介を頼む意思）を、実際に成果につながる経路に使えます。

作成されるもの

Artifact ツールで公開する HTML ファイル 1 つです。アカウントごとにタブがあり、複数のアカウントがある場合は上部にアカウント切り替え機能があります。

タブ	内容
Overview	アカウント概要、従業員数と資金調達状況のタイル、採用シグナルのグラフ、最近のアクティビティ
Stakeholders	商談上の役割ごとにグループ化された購買グループ。各カードを開くと、アクティビティの詳細、優先事項、話のポイント、異論、コピーして使える切り出し文、注目の投稿、職歴が表示され、すべての主張の根拠はドロップダウンで確認できます
Relationship Map	YOU → ウォームなつながり → 名前のわかる仲介者 → 意思決定者。経路の強さに応じて色と太さを変え、経路の一覧を順位付けして表示します
Signals	採用の急増、転職、意向を示す投稿、資金調達。新しいものから順に表示します
Plays	優先順位を付けた施策 3～6 件。各施策には根拠となるシグナルまたは経路を示します

入力

不足しているものだけを尋ねます。

入力	必須	既定値
ターゲットアカウント	はい	-
LinkedIn のつながりのエクスポート	いいえ。ただし、このスキルの要です	ウォームパスをスキップし、その旨を伝えます
販売元の会社名と製品の一行説明	いいえ	コンテキストから推測します
商談ステージ	いいえ	"Prospecting"
詳細度	いいえ	アカウントごとにステークホルダー 6～8 人

エクスポートは、展開済みの Connections.csv、展開済みの Basic_LinkedInDataExport_* フォルダー、または未展開の .zip のいずれでも受け取れます。どれも使用できます。エクスポートに Profile.csv が含まれている場合、所有者の名前はそこから自動的に読み取られます。ファイルにすでに記載されている場合は、各ファイルが誰のものかユーザーに尋ねないでください。検出した名前はユーザーに伝えて確認します。つながりを別のチームメイトのものと誤って特定すると、紹介依頼を間違った相手に送ることになるためです。

フェーズ 0 - 事前確認と分離された作業ディレクトリ

実行単位ごとに作業ディレクトリを作成し、すべての処理に使用します。

WORK="$(mktemp -d -t wpw)"   # or <somewhere>/wpw-<account>-<timestamp>
mkdir -p "$WORK"

これは見た目以上に重要です。2 つの実行で同じ一時パスを共有すると、互いの connections.json を上書きしてしまいますが、その失敗は表面化しません。テストでは、あるアカウントで所有者につながりが 1 万件あったにもかかわらず、一時的に 0 件と報告されたことがあります。所有者間のデータ混入は、このツールが起こしうる最悪の破損です。担当者が、実際に会ったこともない相手への紹介を、間違ったチームメイトに頼むことになるためです。常に実行ごとに 1 つのディレクトリを使います。

続いて、Crustdata に接続できることを確認し、クレジット残高を 1 行で示します。このスキル内の Crustdata 呼び出しはすべて Code Mode MCP（install.crustdata.com/mcp）を通じて実行します。つまり、await callTool(name, params) を呼び出すプレーンな JavaScript の execute({ code }) スクリプトを使います。すべてのスクリプトは // user query: ... または // model query: ... のコメントで始まり、r.ok に応じて分岐し、必要なコンパクトな結果だけを返します（fields はレスポンスのホワイトリストで、指定したグループだけが結果に含まれます）。事前確認には無料の account_credits を使用します。

// model query: preflight - Crustdata reachable + credit balance
const r = await callTool("account_credits", {});
return r.ok ? r.data : { error: r.message };

フェーズ 1 - アカウント概要（アカウントごと）

company_identify（無料）で会社を特定します。これはあいまい検索のため、1つの識別子が複数の会社に一致することがあります。最上位の confidence_score の一致を選び、crustdata_company_ids と exact_match: true を指定して company_enrich を1回実行します。fields: ["basic_info", "headcount", "funding", "competitors", "people", "news", "hiring", "followers", "taxonomy"] を指定します（people グループには意思決定者とCXOの概要が含まれます。読み取ったグループはすべて記載してください）。次に job_search を2回実行します。まず、集計用に job_details.category で group_by 集計を行い、limit: 0 を指定します。その後、注目すべき職種を確認するため、metadata.date_added の降順でソートし、limit: 15 を指定します。続いて、会社を対象に social_post_list_live を実行します（投稿ごとに1クレジットが必要なので、limit は慎重に設定してください。概要には約10件で十分です）。

アカウントが現在も独立した会社として存続しているか確認してください。 買収によって、予算の保有者や人々が記載するブランドが変わります。最近の買収案件は概要とエイリアスリストに含めてください。テスト中、実行途中でConfluentがIBM傘下の会社だと判明し、購買プロセス全体が変わりました。

3〜4文の brief を作成します。会社の事業内容、規模、変化していること、今このタイミングである理由を記載してください。数値はすべて、直前に取得したペイロードに基づいてください。

ついでにロゴも取得してください。 basic_info.logo_permalink は無料の company_identify 呼び出し（および上記のエンリッチ）で、追加クレジットなしで取得できます。ダウンロードしてbase64に変換し、account.logo_url に data:image/jpeg;base64,... URIとして書き込みます。メディアCDNはこれらを binary/octet-stream として配信するため、リモートの <img src> は何も表示されません。ワークスペースのヘッダーとアカウント切り替え画面にロゴが表示されます。設定しない場合はモノグラムが表示されます。

フェーズ 2 - 購買グループ

ユーザーが指定した連絡先と、フェーズ1の people グループから候補を選び、experience.employment_details.current.company_id と上級の experience.employment_details.current.seniority_level で絞り込んだ person_search で候補を見つけます。販売先の職能に合わせて絞り込みます。まず person_autocomplete で列挙値を確認してください。誤った列挙値を指定すると、エラーなく0件が返されます（seniorityの語彙は限定されたセットです：CXO、Vice President、Director、Experienced Manager、Strategic、……）。

次に、役職ではなく、技術スタックの所有者に着目して2回目の検索を行います。 seniorityは権限の目安にすぎません。実際に重要なのは、予算とツールを所有していることです。関連システム（ops、platform、systems、enablement、tooling、「GTM systems」、「talent operations」）の所有者であることを役職名やプロフィールの見出しに記載している人を検索します。テストでは、あるアカウントで最も適した買い手は18個のツールと500万ドルの予算を所有する Senior Manager でしたが、director以上に絞った検索では完全に見逃していました。

6〜8人に絞り込みます。暫定的な deal_role と influence（1〜5）を割り当てます。買収されたサブブランドに所属する人には entity を設定します。これにより、そのサブブランドでのつながりから本人に直接たどり着けます。

買収企業には、つながりの糸口が隠れていることがあります。 買収された会社の人々は元のブランド名を記載し続けていることが多いため、「Red Hat」でのつながりは「IBM」で検索しても一致しません。ウェブ検索で買収の履歴を調べ、エイリアスの完全なリストを aliases.json に書き込みます。

{"IBM": ["ibm", "red hat", "hashicorp", "apptio", "nordcloud"]}

複数単語のエイリアスはフレーズとして一致し、1単語のエイリアスは単語全体で一致するため、「edge」のような断片によって無関係な会社が含まれることはありません。本当に同名の会社がないか確認してください。「Observe.AI」はSnowflakeが買収した「Observe, Inc.」とは別の会社で、検索結果には両方が表示されます。

フェーズ 3 - ステークホルダーの詳細調査

references/stakeholder-agent.md を使用し、1 回のメッセージでステークホルダーごとにサブエージェントを 1 つ起動します。生の投稿ダンプはメインコンテキストに含めないでください。references/dossier-schema.md に従って $WORK/<slug>/dossier.json にまとめます。

各人の写真（basic_profile.profile_picture_permalink）は、サブエージェントがリクエストする basic_profile グループにすでに含まれています。追加料金はかかりません。ロゴと同じ binary/octet-stream のルールに従って Base64 に変換し、ステークホルダーの photo_url に設定します。カードやドロワーが、イニシャルだけの一覧ではなく、実際の購買グループのように見えるようになります。

フェーズ 4 - コネクション、ベンチ、検証

python3 scripts/parse_connections.py --out "$WORK/connections.json" \
  --input "/path/Connections.csv" \
  --input "/path/Basic_LinkedInDataExport_2026.zip"     # append ':Name' to override the owner

オーナーごとの合計をユーザーに報告します。その後、ベンチを実際の経路として提示する前に**必ず検証してください。**エクスポートにはエクスポート当日時点の雇用先が記録されますが、古くなっても通知されません。テストでは、ベンチのメンバー 1 人がすでに対象企業を退職していました。person_enrich（fields: ["basic_profile", "experience"]）で該当する行をスポットチェックし、退職した人は除外するか、その旨を明記してください。

構造上の見落としが 2 つあります。簡単に説明でき、完全に見えるだけのマップを出すよりも、明記する価値があります。

• 会社フィールドが空欄のコネクションは、どのエイリアスにも一致せず、表示されません
• 元従業員は表示されません - エクスポートには現在の雇用先しか記録されないため、対象企業に 10 年勤めた後に退職した人は、理想的な仲介者であっても表示されません

フェーズ 5 - 経路の解決

モデルと誠実さを保つための制約については、references/chain-scoring.md を読んでください。経路は優先順に 3 種類あり、ビルダーは最初の 2 種類を自動的に検出します。

1. ホップなし - コネクションが購買グループのメンバーその人です。これに勝るものはありません。ベンチと購買グループは異なるフェーズで作られるため、見落としやすい経路です。ビルダーは LinkedIn URL、次に名前で照合するため、追加作業は不要です。
2. 日付で検証された共通の職歴 - コネクションとステークホルダーが、在籍期間の重なる時期に同じ会社で働いていました。これは最も強力な、証拠に基づく橋渡しですが、実際に在籍期間が重なっている場合に限ります。テストでは、「同じ会社 X で働いていた」という一見妥当なつながりが 13 件ありましたが、日付チェックを通過したのは 3 件のみでした。残りは、対象者の退職後に加入していました。有効にするには、ベンチメンバーの職歴を補完し、careers.json を作成します。

   {"https://www.linkedin.com/in/someone": [{"company": "Red Hat", "start": "2021-03", "end": "2023-08"}]}
   

   LinkedIn URL または小文字の名前をキーにします。ビルダーが日付を計算し、期間が重ならない組み合わせは、誰かが再発見しないよう、記録された行き止まりとして記録します。
3. 組織階層の橋渡し - それ以外のすべての人です。ベンチに含まれる各機能の上級リーダーを特定します。コネクションごとではなく、（アカウント、機能）ごとに person_search を 1 回実行し、intermediaries.json を作成します。

   {"Acme": {"Engineering": [{"name": "...", "title": "VP, Platform Engineering",
                              "linkedin_url": "...",
                              "basis": "most senior Engineering leader at Acme (person_search, seniority=VP)"}]}}
   

   basis には、どのように見つけたか、適任と判断した理由を必ず記入してください。データには報告系統が含まれていないため、確認済みの上司・部下関係であるかのように basis を記述しないでください。

フェーズ 6 - シグナルと施策

採用急増、サブエージェントが見つけた購買シグナル、転職、資金調達、最近のニュースから signals[] をまとめ、重要度を付けて新しい順に並べます。次に、コネクション、仲介者、意思決定者を挙げ、今が好機であることを示すシグナルを引用した plays[] を 3～6 件作成します。「チームに連絡する」は施策ではありません。

フェーズ 7 - ビルドして公開する

python3 scripts/build_workspace.py \
  --dossier "Acme=$WORK/acme/dossier.json" \
  --dossier "Globex=$WORK/globex/dossier.json" \
  --connections "$WORK/connections.json" \
  --aliases "$WORK/aliases.json" \
  --intermediaries "$WORK/intermediaries.json" \
  --careers "$WORK/careers.json" \
  --template assets/workspace-template.html \
  --title "Acme + Globex Deal Workspaces" \
  --out "$WORK/workspace.html"

ビルダーは、接続とアカウントの照合、ゼロホップ経路と共有履歴経路の検出、すべてのチェーンのスコアリングと順位付け、中間担当者の組み込み、行き止まりの記録、データの挿入といった決定論的な処理をすべて行います。公開する前に、出力された概要を確認してください。ウォームチェーン数、強力なチェーン数、ゼロホップ、元同僚であることが確認済みの人数、組織レイヤーの名前を確認します。

続いて、公開します。Artifact の最初の呼び出しの前に必須の artifact-design スキルを読み込み、file_path に $WORK/workspace.html、固定のタイトル、1 文の説明、ファビコンを指定して Artifact を呼び出します。成果物こそが納品物です。ワークスペースをディスク上に残しても、誰の役にも立ちません。同じファイルパスで再公開すれば同じ URL に再デプロイされるため、手軽に反復できます。

主要な数値を報告します。マッピングしたステークホルダー数、分析した投稿数、ウォームチェーン数とそのうち強力なものの数、ゼロホップ経路数、シグナル数、プレイ数です。

フェーズ 8 - 反復する

よくある追加作業には、チームメイトのエクスポートデータを追加して再ビルドする、ステークホルダーを追加または再実行する、案件での役割を変更する、購買グループを広げる、といったものがあります。変更のたびに入力を編集し、フェーズ 7 を再実行して同じ URL に公開します。

守るべきガードレール

捏造は絶対にせず、成果物で裏付けてください。 すべての主張には、根拠となるペイロードを引用した証拠を添え、証拠のない主張はgapsに記載します。証拠のドロップダウンがあるからこそ、誰もがこのページを信頼できます。自信たっぷりの捏造をひとつ加えるだけで、その信頼はすべて損なわれます。

「有力なつながりがない」ことは失敗ではなく、成功です。 チームのネットワークが購買機能につながっていないなら、そのことを明確に伝え、そのアカウントを「支援を受けたアウトバウンド」として温めておきます。弱いつながりを4つ、突破口のように見せかけても、貴重な人的つながりを無駄にするだけです。テストでは、支援なしの実行とスキルを使った実行の両方が、同じアカウントについて独立して同じ結論に達しました。これこそ、システムが正しく機能している証拠です。

名前の取り違えに注意してください。 企業名は重複することがあり、人名も同じ場合があります。候補を検討対象に加える前に、正しい組織や人物であることを確認してください。また、人材の採用経路を探しているときは、調達部門の「戦略的ソーシング」職を除外します。

送信可能なコンテンツのハウススタイル。 書き出しや要点は実際のメールに貼り付けられるため、em ダッシュや en ダッシュは使わず、企業名に法人格の接尾辞を付けないでください。

コンテンツに合わせてレイアウトを調整し、決して隠さないでください。 以下のブランドシステムは固定ですが、レイアウトは固定ではありません。実際のコンテンツが収まらない場合（長い企業名や人名、12語のタイトル、40人のステークホルダー、グラフで表示しきれない数のつながりなど）は、コンテンツではなくレイアウトを変更します。カードを広げる、省略せずに折り返す、1列にする、列幅を広げる、上限を引き上げる、または幅の広い要素を独立したスクロールコンテナーに配置します。カードを切り取る、名前を省略記号で終わらせる、行を黙って削除するといった方法で、表示上の問題を解決してはいけません。どうしても上限が避けられない場合は、「34件中、有力な18件のルートを表示」のようにUIに明記し、読者に非表示の情報があると伝えてください。レンダリングされたページを確認し（Phase 7のセルフレビュー）、切れている箇所を修正してから引き渡してください。

レンダリングする成果物へのCrustdataブランディング。 同梱のワークスペーステンプレートには、実際のCrustdataブランドシステムが組み込まれています。これを維持し、テンプレートの編集時にも絶対に取り除かないでください。

• ワードマーク：公式の2種類の画像は、このスキルのassets/に含まれています。crustdata-logo-light.png（明るい背景用の濃い文字）とcrustdata-logo-dark.png（暗い背景用の白い文字）で、app.crustdata.comのヘッダーに表示されるものと同じです。テーマに合った画像をBase64でインライン化し、高さを約17pxにしてcrustdata.comへのリンクを設定します。テンプレートでは両方を表示し、CSSで切り替えます。ロゴをホットリンクしてはいけません。レンダリングされた成果物では、外部の画像を取得できないためです。
• 色：アクセントにはブランドの紫#5547E2（製品のプライマリカラー）、ダークテーマのアクセントには#8387FF（製品独自の明るい紫）を使います。
• 書体：製品のフォントであるGeistを、システムフォントスタックをフォールバックとするデータURIの@font-faceとして埋め込みます。
• アイコン：ダッシュボードのアイコンセットであるLucideを、currentColorのストロークを使ったSVGとしてインライン化します（パスデータはテンプレートのlicon()ヘルパーにあります）。成果物のUIでは絵文字を使いません。

このスキルでレンダリングするその他のページやドキュメント（単発の概要ページやエクスポートしたレポートなど）にも、同じシステムを適用します。assets/のワードマーク2種をBase64でインライン化して「Powered by」の上に配置し、assets/workspace-template.htmlから@font-face、アクセント変数、licon()アイコンヘルパーをコピーします。ただし、これは条件付きです。チャット出力とデータファイルにはブランディングを適用せず、ロゴを載せるためだけに成果物をレンダリングすることもありません。

ツールの依存関係

• Crustdata MCP server (install.crustdata.com/mcp): list_tools、get_schema、executeを公開する単一のCode Mode MCPです。Crustdataのすべてのデータツールには、await callTool(name, params)を使ってexecute({ code })のプレーンなJavaScriptスクリプト内からアクセスします。get_schemaの型付きインターフェースに基づいて作成しますが、本文には型注釈を一切記述しません。ここで使用するツール：company_identify、 company_enrich、person_search、person_autocomplete、person_enrich、 person_contact_enrich、job_search、social_post_list_live、web_search_live（別名 research）、account_credits
• scripts/parse_connections.pyとscripts/build_workspace.py用のPython 3（純粋なローカル処理で、ネットワーク呼び出しはありません）
• ワークスペースHTMLの公開に使用するArtifactツール

同梱リソース

• scripts/parse_connections.py - LinkedInエクスポートを正規化し、Profile.csvから所有者を自動検出します
• scripts/build_workspace.py - ベンチマッチング、ゼロホップと共有履歴の検出、チェーンのスコアリング、HTMLへの埋め込みを行います
• assets/workspace-template.html - 複数アカウントに対応した、自己完結型のワークスペースレンダラー
• references/dossier-schema.md - アカウントごとのドシエ仕様。作成前にお読みください
• references/stakeholder-agent.md - 詳細調査用サブエージェントのプロンプト。Phase 3の前にお読みください
• references/chain-scoring.md - 経路のスコアリングと誠実な解決方法。Phase 5の前にお読みください