icp-sequencer-workflow

ICP シーケンサーワークフロー

3 つの連携した成果物を作成します。ネイティブの検索・エンリッチメントワークフロー、保存済みの人物オーディエンスセグメント、そしてアウトリーチ文面と送信者設定を含む、オーディエンスを元にした下書きキャンペーンです。

このワークフローは、条件を満たして検証済みの連絡先をオーディエンスに保存します。セグメントはその連絡先を選択し、キャンペーンはそのセグメントからの登録を処理します。「Enroll in Campaign」ノードは追加しないでください。本番環境での検索とエンリッチメントは、保存済みワークフロー内で行い、ローカルスクリプトや、単独のバッチを実行した後に CSV をインポートする方法は使いません。ローカル設定ファイルや、範囲を限定した診断用プレビューは問題ありません。

このスキルは、1 つの SKILL.md 内で完結させてください。

宣言済みの入力

ユーザーまたはセッションからすでに提供された情報を再利用し、本当に不足している情報だけを、一度に焦点を絞った質問を 1 つずつ尋ねてください。0、false、「パーソナライズなし」は有効な回答であり、不足情報ではありません。

入力	インストーラーが提供する内容	不足している場合
購買担当者の役職と職位	ICP の対象となる職種と職位	最初に質問してください。これがないと検索クエリを作成できません。
企業の条件とシグナル	規模、業界、成長率、技術環境、その他のアカウントフィルター	人物レベルのクエリを作成し、企業条件を適用していないことを明示してください。
人物または企業の所在地	所在地が人物または企業の本社のどちらを指すか、および対象地域	地理的フィルターは適用せず、その旨を伝えてください。推測してはいけません。
除外条件	明示的な対象リスト・除外リスト、および除外するアカウント	何も適用しないでください。件数に合わせるために除外条件を推測したり、ターゲットを広げたりしてはいけません。
販売者、オファー、CTA	販売者、オファー、行動喚起、および主張の裏付けとなる証拠	検索とエンリッチメントを作成し、情報が提供されるまでキャンペーン文面は保留してください。
任意のパーソナライズ	エンリッチする情報と、必要な鮮度	パーソナライズは省略してください。有効な選択です。メールゲートから直接書き戻しに接続してください。
ワークスペース	Workflows、Audiences、キャンペーンがある対象の Clay ワークスペース	対象が曖昧な場合は、何も作成する前に停止してください。
メール検証関数	特定のものが必要な場合、インストール済みのウォーターフォール／検証関数	ワークスペース内で適切な関数を探してください。見つからない場合は、メールアドレスを推測せず、阻害要因として報告してください。
メンバーシップ設計	キャンペーンごとの専用ブール型マーカーフィールド、または既存のメンバーシップ設計の明示的な指定	他のキャンペーンのメンバーシップを上書きしないよう、このキャンペーン専用のブール型フィールドを作成してください。
送信者アカウント	キャンペーンで使用する、接続済みの送信者 ID	送信者の違いが実質的に曖昧な場合に限り質問してください。キャンペーンは下書きのままにしてください。
実行範囲（実行時）	検索全体または結果の上限、および実行ごと・企業ごとの上限	オンデマンドで実行し、対応している制御機能を使って実行時に範囲を決定してください。適用できない上限があれば明示してください。

このスキルが扱う内容

• 読み取り：ワークスペースの識別情報（clay whoami）、重複を避けるためにユーザーが指定した既存のワークフロー、セグメント、キャンペーン、Audiences のフィールド定義、検索トリガーの実行時出力、メール関数の入力・出力・検証契約、接続済みの送信者アカウント、およびユーザーが提供する ICP、オファー、パーソナライズのコンテキスト。
• 書き込み：ドラフトのワークフローを作成する、人々のオーディエンスセグメントを作成または設定する、オーディエンス連携型のドラフトキャンペーン（アウトリーチ文面、送信者設定、セグメントの紐付け）を作成する、連絡先レコードを Audiences にアップサートする（検証済みの主要メールアドレス、名前、一致した企業フィールド、指定されたパーソナライズ） — さらに、適格性確認とメール検証の完了後にのみ書き込まれる、キャンペーンごとのブール値のメンバーシップマーカーを含む。また、要求された構築に必要な互換性のある Audiences フィールドを追加することがある。インストール済みのスキルに割り当てられた ID がある場合は、ワークフローの説明に Marketplace のソース行を追加することがある。
• 決して行わないこと：ユーザーを登録したり、独自にメールを送信したりしない。別途許可がない限り、ワークフローを公開または実行したり、キャンペーンを開始したり、テストを送信したりしない。レコードを削除したり、入力値が空の場合に既存の値を消去したりしない（入力値が空の場合は既存の値を保持する）。共有フィールドに別のキャンペーンのメンバーシップを上書きしない。ドメインやメールアドレスを推測しない。プレビューを埋めるために無関係な連絡先をインポートしない。自身を送信または公開しない。
• 停止する段階：ステップ 4 のサンプルレビュー、ステップ 4 の費用承認、ステップ 4 の送信承認。

検出と成果物のリンク

clay whoami を実行してワークスペースを特定します。ユーザーまたはセッションが明示的に指定した成果物を再利用し、編集前に内容を確認して、重複を作成する前に曖昧な一致を解消します。

必要に応じて、ワークフロー、検索構文、アクションの検出、Audiences、キャンペーンに関する利用可能な Clay スキルを使用します。それ以外の場合は、インストール済みの clay ... --help とライブスキーマを使用します。現在のガイダンスは、以下の例より優先されます。認証、ネットワーク、未対応機能のエラーは、互いに同じものとして扱わず、正確に報告します。

成果物の作成に成功した直後に、その名前とクリック可能な https://app.clay.com のエディターリンクを添えて、簡潔な進捗報告を送信してください。 ワークフロー、オーディエンスセグメント、キャンペーンのそれぞれについて個別に行い、最終報告まで待たないでください。該当する場合は、ドラフトであること、または設定中であることを伝えます。成果物を再利用する場合は、その成果物を特定した時点でリンクを共有します。

Clay から返された URL を優先します。URL が返されない場合は、実際のワークスペース ID と作成されたリソース ID を使用して、次の形式で URL を作成します。

成果物	アプリの URL
ワークフロー	https://app.clay.com/workspaces/<workspaceId>/terracotta/tc-workflows/<workflowId>
人々のセグメント	https://app.clay.com/workspaces/<workspaceId>/people/audience/<segmentId>
キャンペーン	https://app.clay.com/workspaces/<workspaceId>/campaigns/<campaignId>

API エンドポイント、推測した ID、または別のワークスペースのリソースで代用しないでください。最終報告にも、3 つすべてのリンクを記載してください。

1. ICP とオファーを設定する

会話形式のインタビューを通じてユーザーを案内します。**メッセージごとに焦点を絞った質問を1つだけ尋ね、次の質問をする前に回答を待ってください。**質問一覧全体を表示したり、複数の独立した質問を1つのプロンプトにまとめたりしないでください。すでに提供された情報を再利用し、回答済みの質問は省略してください。短い例を示すと、ユーザーが回答しやすくなる場合があります。

まず購入者の役職・職務から始め、次に不足している会社の条件、地域、除外条件、オファー、任意のパーソナライズの順に確認します。必要に応じて、広範なトピックを個別の質問に分けてください。送信者の選定については、接続済みのアカウントを確認した後に質問します。有用であれば、回答を待つ間も独立した情報の確認や下書き作成を続けてください。

以下は内部用の確認項目であり、ユーザーにそのまま提示する質問票ではありません。

• 購入者の役職とシニアリティ、会社の条件とシグナル、本人の所在地と会社の本社所在地、除外条件。
• 販売者、オファー、行動喚起、裏付けのある製品情報または承認済みの実績。
• 任意のパーソナライズ情報と鮮度に関する要件。追加のパーソナライズ情報の調査は有効ではありません。

ICP と重要な前提を簡潔にまとめます。実行頻度が指定されていない場合は、オンデマンドでの設定をデフォルトとします。作成時のインタビューでは、1回あたりのリード数や会社あたりの連絡先数を尋ねず、ユーザーから指定がない限り、検索上限をハードコードしないでください。ワークフローの実行時に、ユーザーが検索全体または結果数の上限を選択します。実行を求められた場合は、その時点でサポートされている実行コントロールを使って実行範囲を確認し、すでに指定された上限を守ってください。3日後のフォローアップを含む2通のメールは、妥当なデフォルトとして提示できますが、成果の保証として扱ってはいけません。件数に達するためにターゲティング範囲を広げたり、明示された包含・除外の指定を覆したりしないでください。

現在のclay searches query-mode referenceを使ってクエリを作成してください。現職と会社の述語は、同じエクスペリエンス式の中に含めます。成長率の単位と会社規模の区分を確認してください。成長率が1.2を超える場合は20％超を意味し、51～1,000の区分は50～1,000を正確には実装しません。このような境界について明示してください。追加のエンリッチメントが必要な条件は、ワークフロー内で確認してください。実装できない条件があれば報告してください。

2. ネイティブワークフローを構築する

インラインの会話作業ではなく、保存済みの Clay ワークフローとして構築します。これにより、ユーザーが再実行できる再利用可能なグラフとして保持されます。以下のノードを作成する前に、まず clay workflows nodes --help を使って、インストール済み CLI のノード構文を確認してください（コマンド形式をハードコードしないでください）。

提案するフローを示してから、現行の予算選択要件に従って、説明的な名前を付けた下書きワークフローを作成します。

flowchart TD
    A([Find leads: ICP search]) --> B(Resolve required company details if missing)
    B --> C(Find and verify work email)
    C --> D{Verified email available?}
    D -->|Yes| E(Optional personalization)
    E --> F(Save contact and membership marker to Audiences)
    F -.-> G[Audience segment]
    G -.-> H[Audience-fed campaign]

破線の接続は別個の成果物を表しており、追加のワークフローノードではありません。必要な詳細がすでに揃っている場合は、企業情報のエンリッチメントを省略します。不要なパーソナライズも省略します。検索フィルターは、適用対象の基準に関する適格性判定を満たします。リードを適格性判定するという一般的な指針だけを理由に、2つ目のノードを追加する必要はありません。検索では表現できない基準に限り、後続の適格性判定を追加します。構造化されたシニアリティの一致を、追加の役職キーワードルールで絞り込まないでください。必須入力の欠落や未検証のメールアドレスは、処理を停止するかレビューに回してください。これらはデータ準備状況の確認であり、ICP の再適格性判定ではありません。

実際の ICP クエリを含むネイティブの Find leads トリガーを使用します。一致した人物 1 人につき、実行を 1 回開始します。既知のソース形式は以下のとおりです。現行のトリガーヘルプで確認してください。

{
  "triggerType": "action_source_scheduled",
  "dataSource": {
    "kind": "cpj_criteria",
    "entityType": "people",
    "dslQuery": "<ICP query>"
  }
}

scheduleConfig がない場合、型名にかかわらずオンデマンドで実行されます。トリガーを作成しても検索は実行されません。出力スキーマを確認するには、トリガーを読み戻してください。保存済みのソース設定では、クエリがそのまま返されず、ソース ID が返される場合があります。ネイティブのソーシングを利用できない場合は、CSV ワークフローに黙って置き換えず、阻害要因を報告してください。

バインディングを確定する前に、既存の実行結果、または承認済みの小規模なソーステストを使用して、このワークフローの検索トリガーから得られる実際の出力の代表例を確認してください。検索プレビュー、宣言されたスキーマ、または別のワークフローのマッピングでは、実行時の値を確認したことにはなりません。必須のメール入力をすべて確認し、値の有無、型、null かどうかをチェックしてください。特に、最新の役職／企業フィールドと Clay の企業 ID が存在していても、matched_experience が null の場合があります。実行時の証拠がない場合、バインディングを準備完了とせず、未検証として示してください。

検索条件を満たした同じ勤務先の役職、企業名、ドメイン、識別子を使用してください。最新の勤務先へ黙ってフォールバックしないでください。一致していることを確認するか、サポートされているエンリッチメントで一致した勤務先を特定するか、解決できないレコードをレビューに回して制約を明示してください。正しい企業識別子が取得できていてドメインが欠けている場合は、その企業をワークフロー内でエンリッチメントし、メール関数に必要な入力を満たしているか確認します。ソースに、エンリッチメントで補えるフィールドがないというだけで、対象者全体を除外しないでください。ドメインやメールアドレスを推測してはいけません。

適切なインストール済みのメールウォーターフォール／関数を特定し、その入力、出力、検証仕様を確認してください。検証済みの業務用メールアドレスのみが返される場合は、検証を重複して行わず、「業務用メールアドレスを検索して検証」とラベル付けします。それ以外の場合は検証を追加し、ドキュメントに記載された受け入れ可能なステータスを条件とします。メールアドレスが空でないことだけでは、検証済みとはいえません。メンバーシップへの書き戻し前に、欠落または未検証のアドレスの処理を停止します。

可能な場合は、適格性判定と検証の後に任意のパーソナライズを配置してください。返された証拠に基づき、関連する場合は情報源や日付を保持し、値が欠けている場合に備えて誠実なフォールバックを用意します。コピーに使う事実だけを購入してください。

検索上限が制限するのは候補者数であり、検証済みメールアドレス数や登録数ではありません。個人単位のコードには実行をまたぐメモリがありません。全体または企業単位の上限は、サポートされているソースまたは永続化の仕組みでのみ適用してください。実行前に、適用できない上限を明示してください。

配線の基本

現在のワークフローデータの受け渡しに関するガイダンスとアクションスキーマを使用します。次の違いを維持してください。

• トリガーが返す workflowNodeId を resourceId ではなく incomingEdges[].sourceNode に接続します。トリガーから直接出るエッジは最大1つです。
• 上流の値は inputSchema.properties.<variable>.sourceNodeId と sourcePath を使って固定し、ツールのパラメーターは tools[].inputMappingConfig を通じてマッピングします。
• トリガーのフィールドはルートにあり、ツール／関数の結果は $.result の下にあります。スペースを含む名前のJSONPathブラケット表記も含め、出力名が正確であることを確認します。
• 条件分岐は実際のルールIDと、サポートされている不一致時の終了処理を使って振り分けます。受信エッジを更新すると、既存のセットが置き換えられます。
• 保存後にノードを読み戻します。スキーマは正規化され、保存時にデフォルトのマッピングが追加される場合があります。

3. Audiences とキャンペーンを接続する

Audiences のフィールド定義を確認します。適切な識別キー、検証済みのプライマリメールアドレス、名前、一致した会社情報、および必要なパーソナライズ項目を使って、連絡先のアップサートを設定します。入力値が空の場合は、入力先に値があればそれを保持します。選択した検索／書き込みフィールドには、それぞれ対応するマッピングが必要です。

このキャンペーン専用のブール型メンバーシップフィールドと、そのフィールドが true であることを条件とする人物セグメントを作成します。ただし、既存のメンバーシップ設計が適切であると明示的に確認できる場合は、それを使用します。適格性の確認とメールアドレスの検証が完了した後にのみ、マーカーを書き込みます。他のキャンペーンのメンバーシップを上書きする共有のスカラー型コホートフィールドは避けてください。

現在サポートされている書き戻しスキーマを使い、recordFields|selectedRecordFields でマーカーを選択し、recordFields|<markerFieldId> をマッピングします。静的な true は「Select a workflow field」で拒否される場合があります。その場合は、検証済みメールアドレスのゲート通過後に、明示的な型付きブール値の出力（たとえば、campaign_member: true を返す小さなコードステップ）を生成し、そのフィールドをバインドします。生成元と永続化されたマッピングをテストします。想定上のツール success フラグで代用したり、マーカーを供給するためだけに冗長な適格性確認を残したりしないでください。保存されたレコードに意図した値が設定され、実際にセグメントに一致することを確認します。セグメントはフィルターであり、保存先ではありません。作成しても内容は追加されません。

ビルド中にキャンペーンを作成し、未公開の前提条件として残さないでください。キャンペーンの現在の作成／更新に関するヘルプを確認します。オーディエンス連携の方法を使い、キャンペーンがドラフトの間に leadBaseSegmentId を通じてセグメントをバインドします。セグメントを削除しても、キャンペーンがワークフロー登録モードに切り替わるわけではありません。このCLIワークフローに、UIのみで行うキャンペーン作成やプレースホルダーの登録ノードを持ち込まないでください。

実際に確認できている販売者とオファーに基づき、簡潔なアウトリーチ文面を作成してレビューします。フォローアップは未返信の相手を対象にします。検証済みのフィールド識別子、読みやすいプレースホルダー、任意のパーソナライズ項目に対するフォールバックを使用します。ワークフローは、キャンペーンの必須フィールドをすべて設定する必要があります。ユーザーの選択または確立済みのコンテキストから送信者アカウントを選択します。送信者の識別情報に重大な曖昧さが残る場合は、確認してください。

サポートされているコマンドを使って、文面と送信者設定を保存します。セグメントが空の場合は連絡先ベースのプレビューができないことがあります。その制約を明示し、無関係な連絡先をインポートしたり、テスト送信したりしないでください。

4. 検証して引き渡す

デフォルトでは下書きを作成します。作成の許可は、依頼された成果物とフィールドを対象とします。それ自体で、ワークフローの公開・実行、キャンペーンの開始、テストの送信が許可されるわけではありません。セッションですでに得ている実行許可は、再度確認せずに従ってください。

ワークフローの実行とキャンペーンの開始は別々です。キャンペーンが下書きの状態でも、リードの準備はできます。アクティブなキャンペーンのセグメントにメンバーを追加する書き込みは、登録ノードがなくてもアウトリーチを引き起こす可能性があるため、実行前に考慮してください。

読み戻して検証します。

成果物	必要な根拠
ワークフロー	ネイティブ検索と入力バインディングが保存されていること。必要な適格性判定、入力準備状況、検証のゲートのみが接続されていること。一致なしのパスは停止すること。正しいアップサートとマーカーが設定されていること。グラフが検証され、キャンバスが整形されていること
セグメント	フィルターが、書き込まれた正確なマーカー／値とユーザー指定の条件に一致すること
キャンペーン	正しいセグメントがバインドされていること。コピー、必須フィールド／フォールバック、送信者の設定が保存されていること。別途許可されていない限り、下書き状態であること

ワークフローをテスト済み、または大規模実行の準備完了と見なす前に、キャンペーンを下書きのままにして、許可された小規模なエンドツーエンドテストを完了してください。実際のトリガー出力、解決されたメール入力、検証済みメール出力、保存された連絡先フィールド、セグメントのメンバーシップを確認します。このソースから実際の候補者を使用してください。合成コード入力やグラフ検証だけでは不十分です。すべてのレコードをスキップして完了した実行では、成功パスが機能することを証明できません。ボリュームを増やす前に、入力がすべて null になる状態や、すべてスキップされる状態を調査してください。

Find leads では、ソースがどの公開済みバージョンを実行するかを検証してください。下書きの修正は、公開されるまでライブグラフに反映されません。より大規模な再実行を推奨する前に、最終設定をテストしてください。単一ノードのテストはそのノードで終了するため、下流の書き戻しやメンバーシップの証明にはなりません。実行承認に従ってください。テストがブロックされた場合は、承認リクエストを一度確認して提示し、結果を「作成済み・未テスト」のままにして、依存する実行を停止してください。ID の抽出やポーリングの前にコマンドエラーを解析してください。承認ゲートを再試行したり、存在しない実行をポーリングしたりしないでください。何も実行されていない場合、処理済みの連絡先があると報告してはいけません。

クリック可能なアプリのリンクを3つ、最終フロー、重要な ICP の前提、設定済みステージ、下書き／ライブの状態、実施したチェック、送信者の選択、公開、開始などの具体的な残作業を提示してください。キャンペーンが開始されていなくても、リードの準備を妨げることはありません。

許可された実行の後は、実際の根拠に基づいて、候補者、適格性判定でスキップされた対象、検証済みメール、保存済みレコード、セグメントメンバー、キャンペーン登録、送信済みメールを区別してください。アップサートの成功は、登録や配信を証明するものではありません。ブロックされた場合は成果物 ID を保持し、独立して実施できる作業を完了したうえで、次に行うべき最小限の具体的な手順を伝えてください。

出力例

架空の例です。実際の実行では、実際のワークスペース ID とリソース ID を使用します。登録も送信もされていません。3つの成果物はすべて下書きとして納品されます。

ビルドの引き継ぎ — 相互に連携する3つのドラフト成果物

米国のシリーズBフィンテック企業のVP／エンジニアリング責任者をICPとして作成しました：

成果物	ステータス	リンク
ワークフロー — ICP Sequencer: VP Eng, fintech	ドラフト、グラフの検証済み	https://app.clay.com/workspaces/12345/terracotta/tc-workflows/wf_abc123
人物セグメント — Fintech VP Eng — campaign member	フィルター fintech_vpeng_member = true	https://app.clay.com/workspaces/12345/people/audience/seg_def456
キャンペーン — Fintech VP Eng outbound	ドラフト、leadBaseSegmentId 経由でセグメントを紐付け済み	https://app.clay.com/workspaces/12345/campaigns/cmp_ghi789

• ICPと前提条件：VP／エンジニアリング責任者、従業員数51～1,000人（要望は50～1,000人でしたが、区分の境界を明記）、米国在住、シリーズBの資金調達済み。成長シグナルは employee_growth_12mo > 1.2 で表現しています。
• 設定したステージ：ネイティブの「見込み客を検索」トリガー（オンデマンド）→不足している場合は企業ドメインをエンリッチメント→勤務先メールを検索して検証→検証済みメールのゲート→Audiences のアップサートで fintech_vpeng_member = true を書き込みます。パーソナライズは依頼されていないため、メールのゲートから書き戻しに直接接続しています。
• エンリッチメント：検証済みの勤務先メールのみを返す、インストール済みの単一ウォーターフォールを使用しているため、別途検証ノードは追加していません。
• メンバーシップ／フィルター：専用のブール値フィールド fintech_vpeng_member を使用しています。セグメントはこれを true に設定されたレコードに絞り込みます。書き込みマッピングとセグメントフィルターを読み戻して、一致することを確認しました。
• ステータス：3つすべてドラフトです。処理済みの連絡先はありません。まだ何も実行されていません。
• 実行前に残っている手順：送信者アカウントを選択し、実行範囲または結果の上限を設定してワークフローを実行し、その後キャンペーンを開始します。各手順は個別であり、明示的な承認が必要です。

適切な状態とは

3つの成果物がドラフトとして存在し、それぞれの紐付けを読み戻して確認でき、3つすべてのリンクが開ける状態です。セグメントのフィルターは、ワークフローが書き込むマーカーフィールドと値に正確に一致しています。セグメントを作成しただけでは、そのフィールドに値は設定されません。必須条件を満たし、検証済みの勤務先メールがある連絡先にのみメンバーシップマーカーを付与します。必須入力や検証済みメールがないレコードは、セグメントに入れるのではなく、処理を停止するか、名前付きのレビュー経路に回します。承認された小規模なエンドツーエンドテストでは、ソース内の実在候補者を使い、実際のトリガー出力、解決されたメール入力、検証済みメール、保存済みフィールド、セグメントメンバーシップをすべて確認します。グラフの検証や合成入力だけでは不十分であり、すべてのレコードをスキップして「完了」した実行も該当しません。候補者数、適格条件でのスキップ数、検証済みメール数、保存済みレコード数、セグメントメンバー数、キャンペーン登録数、送信済みメール数は、実際の根拠に基づく別個の数値として報告します。アップサートの成功を登録や配信として報告してはならず、何も実行していない場合に処理済みとして報告してはなりません。開始が明示的に承認されていない限り、キャンペーンはドラフトのままにします。

このスキルが保証しないこと

明示されているデフォルト設定（メール2通、3日後のフォローアップ）は妥当な出発点であり、測定済みのパフォーマンスを保証するものではありません。検索結果の上限は候補数を制限するものであり、確認済みのメールアドレス数や登録数を制限するものではありません。また、検索結果数から最終的な登録数を保証することもありません。人物ごとのコードノードには実行をまたいだ記憶がないため、全体または企業ごとの上限や企業ごとに1件までというルールは、対応するソースレベルまたは永続的な仕組みを通じてのみ維持されます。強制できない制限がある場合は、隠れたローカルの候補リストでごまかさず、実行前にその旨を明示します。Audiences の upsert が成功しても、セグメントへの所属、キャンペーンへの登録、メールの配信が証明されるわけではありません。これらはそれぞれ別の状態です。グラフの検証や合成入力によって、成功経路が確立されるわけではありません。これを確かめられるのは、許可を得たライブテストだけです。企業規模の区分は、指定範囲を正確に実装できない場合があります（指定が50～1,000の場合、51～1,000など）。その境界は隠さずに明示します。テクノグラフィック情報やフィールドの検索結果が空であっても、その企業が該当する技術を利用していないことの証明にはなりません。このスキルは下書きを作成するだけで、自ら登録や送信を行うことはありません。1回限りの見込み客リスト作成ツールでも、CSV インポートツールでもありません。