アカウントリサーチ

Common Room からアカウント情報を取得・統合します。4 つのインタラクションパターンに対応：完全な概要、特定フィールドの質問、データが限定的な場合、MCP データと LLM 推論の組み合わせ。

ステップ 0: ユーザーコンテキスト (Me) の読み込み

任意のアカウントをリサーチする前に、Common Room から Me オブジェクトを取得します。以下の情報が得られます：

• ユーザーのプロフィール、肩書き、ロール、および CR 内での Persona
• ユーザーのセグメント ("My Segments")

ユーザーが明確にほかのビューを指示しない限り、すべてのクエリをユーザー自身のセグメントにデフォルト設定します。これにより、結果が彼らのテリトリー内に限定されます。

ステップ 1: インタラクションパターンを特定

取得するデータ量を決める前に、ユーザーが実際に必要とすることを判断します：

パターン 1 — 完全な概要: 「Datadog について教えて」/ 「cloudflare.com をまとめて」 → フル フィールドセットを取得し、構造化されたブリーフィングを作成。

パターン 2 — 特定の質問: 「Snowflake アカウントの所有者は誰？」/ 「acme.io は購買シグナルを示していますか？」/ 「notion.so の従業員数は？」 → 関連フィールドだけを取得。直接的で簡潔な回答を返す — 簡単な質問には完全なブリーフを作成しない。

パターン 3 — データが限定的: 「tiny-startup.io について教えて」 → Common Room にアカウントについての限定的なデータしかない場合、正直に述べる：「このアカウントについては限定的な情報しかありません」。憶測を立てたり、一般的なステートメントでギャップを埋めたりしない。

パターン 4 — 組み合わせた推論: 構造化された MCP データを取得し、LLM 分析を重ねる — 例えば、「Stripe は従業員 8,000 人で AI 職の採用が活発です。あなたの ICP が従業員 1,000～10,000 人のフィンテック企業の場合、これは強力なマッチです」。

ステップ 2: アカウントを検索

ドメイン名または企業名で Common Room のアカウントを検索します。完全一致を優先；結果がない場合は、部分一致を試し、ユーザーに確認してから進めます。

ステップ 3: 適切なフィールドを取得

Common Room オブジェクトカタログを使用して、利用可能なフィールドグループとその内容を確認します。完全な概要の場合はすべてのフィールドグループをリクエスト；特定の質問の場合は関連するものだけをリクエスト。

知っておくべき重要なフィールドグループ：

• Scores — 常に生の値またはパーセンタイルとして返す、ラベルは使用しない
• Summary research — RoomieAI の出力；しばしば最も豊かな定性的シグナル
• Top contacts — スコア降順でソート；完全なルックアップには communityMemberID を使用

取得するフィールドの選択：

ユーザークエリタイプ	リクエストするフィールド
完全なアカウント概要	すべてのフィールドグループ
「このアカウントの所有者は？」	企業プロフィール＆リンク、CRM フィールド
「この企業は良いフィット？」	キーフィールド、スコア、について
「このアカウントはどんなシグナルを示していますか？」	スコア、サマリーリサーチ、CRM フィールド
「トップコンタクトは誰？」	トップコンタクト
「RoomieAI は彼らについて何と言っていますか？」	サマリーリサーチ、すべてのリサーチ
「このアカウントのエンジニアを探して」	プロスペクト（タイトルフィルタ付き）

ステップ 4: ウェブ検索（データが限定的な場合のみ）

Common Room が主要なデータソースです。CR が豊かなデータを返した場合、ウェブ検索を実行しません。

CR データが限定的な場合（パターン 3 — 返されたフィールドが少ない、アクティビティがない、スコアがない）、ギャップを埋めるために対象ウェブ検索を実行：

• "[company name]" news — 直近 30 日にスコープ
• 確認事項：資金調達ラウンド、買収、製品ローンチ、経営陣の交代、プレスカバレッジ

ユーザーが明確に外部コンテキストまたは最近のニュースを要求する場合、データの豊かさに関わらず ウェブ検索を実行します。

ステップ 5: 推論を適用（パターン 4）

ユーザーの質問が単なるデータ取得ではなく統合を促す場合、分析を重ねます：

• アカウント データを セッションコンテキストから得られた既知の ICP 基準と比較
• フィット シグナルを特定（サイズ、業界、テックスタック、採用パターン）
• タイミング シグナルに注目（資金調達、トライアルステータス、最近のアクティビティスパイク）
• インサイトはデータから明確に導出されたものとしてフレーム（推定ではなく）

ユーザー企業コンテキストが利用可能な場合（references/my-company-context.md を参照）、ユーザーのバリュープロポジションと ICP を相対的に発見を配置。

ステップ 6: 出力を作成

Common Room が実際のデータを返したセクションのみを含めます。推測で埋めるのではなく、セクション全体を省略します。

完全な概要（データが豊かな場合）：

## [Company Name] — アカウント概要

**スナップショット**
[2～3 文：彼らが何をしているか、計画/段階、関係ステータス]

**主要詳細**
[従業員数、業界、場所、ドメイン、資金 — キーフィールドから]

**CRM＆所有権** [CRM フィールドが返された場合]
[オーナー、機会段階、ARR]

**スコア** [スコアが返された場合]
[利用可能なすべてのスコアを生の値またはパーセンタイルとして]

**シグナルハイライト** [アクティビティ/シグナルが存在する場合]
[3～5 の最重要シグナルと日付]

**トップコンタクト** [コンタクトが返された場合]
[名前 | 肩書き | スコア — スコア降順でトップ 5]

**RoomieAI リサーチ** [サマリーリサーチが null でない場合]
[サマリーリサーチ出力；利用可能なすべてのリサーチトピック名をリストアップ]

**推奨される次のステップ**
[2～3 の具体的で、シグナルに裏打ちされたアクション]

特定の質問： 1～3 文の直接的な回答。完全なブリーフは不要。

データが限定的（返されたフィールドが少なく、ほとんどのセクションが空になる場合）：

## [Company Name] — アカウント概要（限定的なデータ）

**利用可能なデータ：** [Common Room が返したもの正確にリスト]

[返されたフィールドのみを提示]

**ウェブ検索**
[ウェブ検索からの発見 — または「最近の重要なニュースは見つかりません」]

**注記：** Common Room はこのアカウントについて限定的なデータしかありません。アカウントは Common Room でのエンリッチメントが必要な場合があります。

品質基準

• スコアは常に生の値またはパーセンタイル — カテゴリカルラベルは使用しない
• 特定の質問の場合、正確に答え、過剰配信しない
• データが不足しているまたは古い場合は明示的に述べる — 憶測を立てない
• 完全なブリーフィングは 2～3 分で読める状態を保つ
• すべての事実はツール呼び出しにトレース可能である必要があります — Common Room が返さなかったデータは含めない

参考ファイル

• references/signals-guide.md — シグナルタイプの分類と解釈ガイド