zoominfo

ZoomInfo ユーザーガイド

親となる営業ワークフローで ZoomInfo が選択された後、焦点を絞ったセールスインテリジェンス業務に ZoomInfo を使用します。販売担当者のタスクについては親ワークフローを優先し、このガイドでは ZoomInfo 固有の検索、調査、ID、エンリッチメント、クレジット、結果の品質に関するルールを扱います。

共通スキルの指示

必須：まだコンテキストに含まれていない場合は、plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practices を読み、厳守してください。

ZoomInfo の操作の優先順位

1. ユーザーからの明示的な依頼、指定された会社名または人物名、ドメイン、メールアドレス、ZoomInfo ID、または明示された制約
2. アクティブな営業ワークフローで必要となる、最も範囲を絞った ZoomInfo の機能
3. 確度の高い識別子から解決した正式な会社または連絡先のID
4. エンリッチメント、調査、類似検索、推奨の前に検索して候補を絞り込む
5. 回答を実質的に改善する、クレジット消費が最小限の手順
6. 条件に合う候補、近似候補、情報の欠落を明確に分けた結果

必須条件を黙って緩めたり、IDを推測したり、ZoomInfo の情報を CRM の確定情報として提示したりしないでください。

主な依存関係のカテゴリ

このワークフローでは特に重要です。品質向上のため、必要に応じて他のデータソースも含めることを適切に判断してください。

• ~~営業インテリジェンス。特に、ZoomInfo の検索、エンリッチメント、インテント、類似検索、推奨、調査に対応するコネクターが利用可能で接続されていること
• ~~CRM。アカウントの所有権、顧客の状態、商談の事実、予測の正確な情報を得るため
• カレンダー、会議の文字起こし、メール、社内メッセージ、ナレッジとファイルに関するコンテキストを得るための親となる営業ワークフロー
• コネクターへのアクセスやIDの特定が不完全な場合に備えた、ユーザー提供の名前、ドメイン、メールアドレス、ID、ICP の制約、ビジネスコンテキスト

ZoomInfo が見つからない、利用できない、曖昧である、または公開されているコネクターの機能に制限がある場合は、根拠のない主張で置き換えず、その制限を明示してください。

コネクターの境界

ZoomInfo には複数の異なる機能があります。依頼に合う、最も範囲を絞った機能を選択してください。

• 発見：lookup、search_companies、search_contacts、search_intent
• 構造化エンリッチメント：enrich_companies、enrich_contacts、enrich_intent
• ナラティブ調査：account_research、contact_research
• 類似検索と推奨：find_similar_companies、find_similar_contacts、get_recommended_contacts
• ユーザーから依頼された場合に限るコネクターへのフィードバック：submit_feedback

以下の機能を混同しないでください。

• 候補の発見には search_* を使用します。
• より詳細な構造化フィールドや、詳細情報の検証を求められた場合は enrich_* を使用します。
• ナラティブ形式の概要、会議準備、またはより広範な状況報告を求められた場合は、account_research または contact_research を使用します。
• 「これに似たもの」、アカウントの拡大、関係者の発見には類似検索または推奨アクションを使用します。正確な検索フィルターの代わりには使用しないでください。

ZoomInfo の情報を CRM の確定情報として提示しないでください。調査結果に関係性やエンゲージメントのコンテキストが含まれる場合は、~~CRM または周辺のワークフローで独立して裏付けられていない限り、コネクターが提示したコンテキストとして明示してください。

デフォルトの特定手順

以下の手順を順に実行してください。

1. 対象を分類します。
   • 会社の候補群
   • 連絡先の候補群
   • 特定済みの会社1社
   • 特定済みの人物1人
   • 購買意向のトピック
   • 類似企業または推奨の依頼
2. 検索前に、必須フィルターを正規化します。
   • 地域
   • 管理職レベル
   • 部門または職種グループ
   • 従業員数または売上高の範囲
   • 業種または会社の種類
   • テクノロジーのフィルター
   • インテントのトピック
3. コネクターが標準化された値を必要とする場合は、検索またはインテントの処理の前に lookup を使用します。
4. IDに依存するエンリッチメント、調査、推奨のアクションを行う前に、会社または連絡先の正式なIDを特定します。
5. 返された行がユーザーの必須条件を実際に満たしていることを確認してから、条件に合う候補として要約します。
6. 見つからなかった情報、根拠が弱い情報、コネクターの制限を受ける情報を、曖昧にせず明示します。

ルックアップの規律

コネクター固有のカテゴリを推測せず、lookup を使用してサポートされている値を取得してください。

• 制約に関係する場合は、management-levels、metro-regions、industries、employee-count、departments、job-functions、company-types、revenue-ranges、tech-vendors、tech-products、intent-topics に使用してください。
• 後続のアクションで識別子が必要な場合は、表示用に整えたラベルではなく、lookup が返す標準化された識別子を使用してください。
• テクノロジースタックを検索する場合は、まずベンダーを解決し、次にそのベンダーの製品を解決してから、返された製品識別子を検索に渡してください。
• インテントのワークフローでは、まずサポートされている正確なインテントトピックを取得してください。要求された概念がサポート対象のトピックに明確に対応しない場合、本当に近いときに限って最も近いサポート対象のトピックを提示してください。それ以外の場合は、現在のトピック分類では要求を正確に表現できないと伝えてください。

ルックアップ値をでっち上げたり、隣接するカテゴリに黙って置き換えたりしないでください。

識別子の解決

IDが必要なアクションを実行する前に、エンティティを慎重に解決してください。

企業

• 企業名だけの場合よりも、companyId、ドメイン、ウェブサイト、またはティッカーを優先してください。
• ユーザーが企業名しか提示しておらず、次のステップでエンリッチメント、調査、またはターゲット企業IDが必要な場合、企業が明らかでなければ、まず search_companies を使用して正式な企業レコードを特定してください。
• 候補となる企業が複数残る場合は、ドメイン、本社所在地、業種、またはユーザーの前後の文脈を使って曖昧さを解消してください。それでも曖昧さが重要な場合は、黙って1社を選ばず、候補一覧を提示してください。
• 企業のエンリッチメントでは、利用可能な場合、曖昧な名前だけの入力よりも companyId、domain、または companyWebsite を優先してください。

連絡先

• 名前だけの場合よりも、personId、業務用メールアドレス、または正確な氏名と企業名の組み合わせを優先してください。
• ユーザーが名前を指定して連絡先の調査、類似する連絡先の検索、またはその他の人物IDが必要なワークフローを求めている場合、まず search_contacts を使用して対象者を特定してください。
• 同じ名前に複数の人物が該当する場合は、候補一覧を明示し、単一の一致を捏造しないでください。
• 連絡先のエンリッチメントでは、利用可能な中で最も確実性の高い識別子を使用してください。検索によって人物を特定しやすくできる場合は、範囲の広い名前だけのエンリッチメントを避けてください。

実行時の形式

• コネクターから返された識別子は、アクションが受け付ける実行時互換のプリミティブ型で渡してください。
• コネクターが数値のZoomInfo識別子を返し、実行時に送信先アクションが数値の識別子を要求する場合は、文章に書き換えたり新しい値を推測したりせず、数値のまま保持してください。
• アクションが一見有効な識別子の形式を拒否した場合、対象が明確であれば、対応するコネクター返却値のプリミティブ型を使って1回だけ再試行してください。それでも失敗する場合は、コネクター契約の不一致を報告し、利用可能な低リスクの証拠に基づいてのみ続行してください。

検索の規律

企業検索

• 検索前に、ユーザーのICPを明示的なフィルターに変換してください。
• コネクターがサポートしている場合は、地域、従業員数、売上高、企業タイプ、資金調達、成長、テクノロジーの利用状況について、構造化フィルターを優先してください。
• ユーザーが「米国企業」「カリフォルニア州の企業」など、地理的な条件を厳密に指定した場合は、結果を適合するものとして扱う前に、それぞれが指定地域に該当することを確認してください。
• 検索結果に条件に近いものの完全には一致しないレコードが含まれる場合は、区別を隠さず、Matches と Near Matches に分けてください。
• 上限のある結果ページから、市場を網羅的に調査したと主張しないでください。

連絡先検索

• 精度が向上する場合は、役職レベル、部門、職能、企業、役職のフィルターを組み合わせて使用します。
• 「VP、Director、またはRevOps責任者」のような役職ファミリーのリクエストでは、まず有効である可能性が高い最も絞り込まれた構造化検索から始めます。
• 1件の広範な役職検索で、結果が少ない、明らかに不完全、または的外れな場合は、役職ファミリーを少数の対象を絞った検索に分け、重複を統合し、重複を除いた候補リストを要約します。
• 返された業務関連のフィールドを優先します。個人用メールアドレス、個人の電話番号、または欠落している職務プロフィールを推測してはいけません。

インテント検索

• 正確なインテントトピックを扱う場合は、search_intent または enrich_intent の前に必ず lookup で確認します。
• 実際に何を検索したのかユーザーが確認できるよう、回答ではトピックの意味を明示します。
• 返されたインテントトピックがユーザーの概念より著しく狭い、広い、または隣接する内容の場合は、その旨を伝えます。
• トピックの照会や検索では依頼された概念を忠実に扱えない場合、結果を誇張するのではなく、その制約を伝えます。

エンリッチメントと調査の順序

実用上可能な場合は、コストの低い絞り込み手順を、コストの高い操作や精度の低い操作より先に実施します。

• 対象となるエンティティが不明確な場合は、まず検索を使用します。
• 企業属性フィールド、連絡可否フィールド、または一括処理向けの表形式の出力をユーザーが求めている場合は、構造化エンリッチメントを使用します。
• ユーザーが概要説明、状況把握、または会議準備向けの統合情報を求めている場合は、ナラティブ調査を使用します。
• 上位N件の発見を求められた場合、初期候補すべてをデフォルトでエンリッチメントしてはいけません。まず候補を絞り込み、回答の質を実質的に高める場合に限って、最終候補リストのみをエンリッチメントします。
• 類似検索や推薦のワークフローで人物または企業の詳細情報が少ない場合、ユーザーが実用的な詳細を求めているとき、または周囲のワークフローで必要なときに限り、対象を絞ったエンリッチメントを追加します。

類似検索と推薦のフロー

類似企業

• 競合に似た企業、類似企業、または隣接するアカウントの発見をユーザーが求めている場合は、find_similar_companies を使用します。
• 参照企業が曖昧な場合は、類似検索を行う前に特定します。
• 生の類似検索結果ではなく、実用的な市場リストをユーザーが求めている場合は、ウェブサイト、所在地、従業員数の範囲、または簡潔な説明など、依頼された基本情報を提示できる範囲で最終候補リストをエンリッチメントします。

類似連絡先

• ユーザーが名前を指定した場合は、search_contacts で referencePersonId を特定します。
• 特定のアカウント内で類似する連絡先をユーザーが求めている場合は、search_companies で targetCompanyId を特定します。
• 推薦理由は、類似性の根拠を作り上げるのではなく、返されたメタデータを使って説明します。

推薦連絡先

• まず対象企業を特定します。
• ユーザーの意図に合った推薦ユースケースを選びます。
  • PROSPECTING
  • DEAL_ACCELERATION
  • RENEWAL_AND_GROWTH
• 最終結果の説明では、そのユースケースが解釈に影響する場合、その意味を説明します。
• 推薦スコアは順位付けの指標として扱い、回答確率や成功の保証として扱ってはいけません。

クレジットを考慮した動作

ワークフローで可能な場合は、クレジットを消費するエンリッチメントやAI調査より先に、無料または低コストの検索手順を優先します。

• 適切な場合は、まず lookup、search_companies、search_contacts、search_intent を使用して範囲を絞り込みます。
• ユーザーがこれらの操作によって得られる、より充実した結果を求めている場合は、enrich_companies、enrich_contacts、enrich_intent、account_research、contact_research を使用します。
• 広範な一括リクエストでは、回答で操作の対象範囲を明示し、明らかに有望でない候補への不要なエンリッチメントを避けます。

小規模で依頼内容が明確なエンリッチメント作業に、余計な手間を加えてはいけません。コネクターの結果によって相応のクレジットが消費された可能性がある場合や、範囲を絞った再実行のほうが大幅に低コストになる場合は、明示してください。

失敗時の対応

• コネクターから結果が返されない場合は、根拠のない結果を作り出さず、「ZoomInfo で明確に一致する結果は見つかりませんでした」と伝えてください。
• 結果が必須フィルターに違反する場合は、該当する結果を条件に合う候補から除外し、不一致の内容を伝えてください。
• 必須の検索値を利用できない場合は、どの条件を適切に反映できなかったかを伝えてください。
• 調査結果が乏しい、または一般的な内容にとどまる場合は、有用な部分を残したうえで、網羅性に限りがあると明記してください。
• 推奨または類似性の照会で実用性の高い結果が得られない場合は、どのような追加情報やユーザーの状況が必要かを伝えてください。
• コネクターの動作が自身のアクションの仕様と矛盾しているように見える場合は、網羅性や信頼性に影響するとき、その矛盾を回答内で明確に説明してください。

出力ルール

• 候補リスト、情報補完の結果、類似企業のリスト、連絡先の推奨には、簡潔な表を優先してください。
• 利用できる場合は、コネクターから返されたクリック可能なリンクを優先してください。不透明な ID から推測したリンクを作成してはいけません。
• 以下を分けてください。
  • 条件に合う候補
  • 必要に応じて 近い候補
  • 不足情報／コネクターの制限
• 情報源に基づく事実と 推論： を分けてください。
• メールアドレス、電話番号、正確な意図、コネクターに示されていない信頼度を推測してはいけません。
• 回答がコネクターから返されたフィールドや推奨メタデータに依存する場合は、そのことを明記してください。
• ユーザーが順位付きリストを求めた場合は、モデルの表に出ない選好ではなく、明示されたコネクターのシグナルまたは提示された基準に基づいて順位を付けてください。

出力形式

# [ZoomInfo 検索／情報補完／調査]

## 条件に合う候補

| 企業／人物 | 主な一致の根拠 | 参考情報 | 情報源 |
| --- | --- | --- | --- |
| [結果] | [必須フィルターを満たしていること] | [返されたフィールド] | [リンクまたはコネクターの情報源] |

## 近い候補

- [結果＋正確な不一致点（必要に応じて）]

## 不足情報／コネクターの制限

- [不足フィールド、未対応のフィルター、限定的な網羅性、曖昧さ、またはクレジットを考慮した次の手順]

---

[Limitations and Improvements](../index/SKILL.md#limitations-and-improvements) の指示と出力形式／条件に従ってください。

[Next Steps](../index/SKILL.md#4-next-steps) の指示と出力形式／条件に従ってください。