cargo-gtm

Cargo GTM — Meta Skill

見込み顧客の開拓、アカウント調査、連絡先情報の補完、検証、リードスコアリング、パーソナライズ、シグナルのモニタリング、キャンペーンの実施には、このスキルを使用してください。

適切な利用 — 人に関わる操作の前に必須

完全な仕様は references/acceptable-use.md を参照してください。以下は、ここに記載するすべての手順に適用される要約です。

• B2B の業務用アイデンティティのみを、provider-playbooks/ に記載されたライセンス取得済みプロバイダーから取得してください。消費者をターゲットにすること、購入したリストを使うこと、プラットフォームの利用規約に違反して取得したデータを使うことは禁止です。
• アウトリーチを行う前に、次の3点を確認してください。根拠（顧客、オプトイン済みの連絡先、イベント参加者、または文書化された正当な利益の根拠）、配信除外（補完や送信の前に、配信停止／連絡拒否（DNC）／恒久的なバウンスをフィルタリングすること）、関連性（メッセージを受け取る相手ごとに、その人に送る理由が明確であること）。確認項目を満たさない場合は、警告ではなく停止して確認を求めてください。
• 拒否し、その理由を伝えてください。区別なく一斉送信すること（「<industry> の全員にメールする」）、配信除外対象のレコードへの連絡、フィルターの回避や送信者アイデンティティの偽装、自動ダイヤルや SMS の一斉送信、LinkedIn でのエンゲージメント操作の一括実行、ユーザーの X アカウント（xAccount）からの投稿／返信／いいね／DM の一括または自動実行は禁止です。準拠した方法を一度だけ提示してください。説教はせず、方法を伝えてください。
• このスキルは送信を行いません。 アウトリーチの手順は、送信可能な変数を準備した時点で終了し、シーケンサー独自の制限、ドメイン、アイデンティティの範囲内で、ユーザー自身のシーケンサーに引き継ぎます。作成する文面には、正確な送信者名と件名、機能する配信停止手段、管轄区域で必要な場合は郵送先住所を含めてください。

初期設定

すでにサインイン済みで、cargo-ai whoami がワークスペースを返す場合は、次のセクションに進んでください。

npm install -g @cargo-ai/cli            # no global install? prefix every command with `npx @cargo-ai/cli`
cargo-ai login --email [email protected]  # emailed code, no browser; creates the account on first use
                                        # alternatives: --oauth (browser) · --token <api-token> (CI)
cargo-ai whoami                         # confirm the active workspace before any write

すべてのコマンドは JSON を標準出力に出力し、失敗時は {"errorMessage": "..."} を返してゼロ以外の終了コードで終了します。実行またはバッチを作成する操作はすべて非同期です。--wait-until-finished を渡すか、対応する get をポーリングしてください。スキルバンドル全体をインストールすると、../cargo/references/prerequisites.md に CLI のバージョン固定、トークンのスコープ、管理者専用の操作範囲が追加されます。

1) このスキルの適用範囲

• 実行の前に、GTM の判断、安全性のゲート、プロバイダー／品質に関する既定値を適用します。
• 長いコマンドチェーンやツールの詳細はサブドキュメントに、プロバイダー固有の実装の詳細は provider-playbooks/*.md に記載します。
• 手順では、クレジットを消費するアクション（価値の高いアクション呼び出し）を中心に扱います。無料の CRUD（createLead、getLead、deleteRecords）にはこのスキルは不要です。エージェントは必要に応じてこれらを組み合わせて使用できます。

プロセス／目標

ユーザーは通常、「ICP がある」状態から「メールアドレスとパーソナライズされたシグナルを確認済みの見込み顧客リストがある」状態を目指しています。このプロセスのどの段階にいる場合でも、先へ進めるよう案内してください。

発見の順序は、まず企業、次に人です。 ポートフォリオ、ICP、採用シグナルなどの条件に合う企業で連絡先を探す場合は、まず企業の集合を特定し、その後、各企業で人を探してください。最初に広範な人材検索クエリを使わないでください。

ドキュメントの階層

• レベル 1 — SKILL.md（このファイル）：判断モデル、ガードレール、ルーティング表、サブドキュメントへのリンク。
• レベル 2 — フェーズ別ドキュメント：guides/finding-companies-and-contacts.md、guides/enriching-and-researching.md、guides/writing-outreach.md。
• レベル 2.5 — レシピ：recipes/*.md — 特定のシナリオ向けの、手順を追ったプレイブック。
• レベル 3 — プロバイダー別プレイブック：provider-playbooks/<slug>.md — プロバイダー固有の注意点、コスト、フォールバック動作。

2) 読み取り動作 — 実行前に必ず行うこと

停止してください。タスクに適したサブドキュメントを開くまでは、プロバイダーへの呼び出し、cargo-ai orchestration action execute コマンドの実行、検索クエリの作成を行わないでください。

これらのドキュメントには、機能すること、失敗すること、その理由が記載されています。検証済みのパラメータースキーマ、最安プロバイダーの対応表、並列実行パターン、ペイロード例、既知の落とし穴が含まれています。適切なドキュメントを10秒読むだけで、失敗するアクション呼び出しを10回減らし、クレジットの無駄遣いや質の低い出力を避けられます。

振り分けルール — タスクに合うドキュメントを選んで読みます

タスクに含まれる内容	最初に必ず読むドキュメント	得られる情報
企業の検索、人材の検索、見込み顧客リストの作成、プロスペクティング、ポートフォリオ／VC ソーシング、既知企業の連絡先検索	guides/finding-companies-and-contacts.md	プロバイダーのフィルタースキーマ、最安ソースの判断ツリー、並列実行パターン、役職ベースの検索ルール、ポートフォリオ／VC のショートカット、連絡先検索パターン。
企業または連絡先のエンリッチメント、メールアドレス／電話番号／LinkedIn の検索、ウォーターフォールエンリッチメント、シグナル検索（転職、資金調達、技術スタック）、データの統合	guides/enriching-and-researching.md	フォールバックチェーンを備えたウォーターフォールパターン、aiArk と waterfall、FullEnrich、peopleDataLabs の使い分け、メールアドレス／電話番号／LinkedIn のフォールバック順序、シグナルセグメント、run download-outputs による出力取得。
初回のアプローチメッセージの作成、メッセージのパーソナライズ、見込み顧客のスコアリング、適格性評価、シーケンス設計、キャンペーン文面の作成	guides/writing-outreach.md + references/acceptable-use.md（§3 のチェック、ブロック条件）	LLM プロバイダーの振り分け（openAi/anthropic/perplexity/gemini）、プロンプトテンプレート、スコアリング基準、メールの長さ／トーンのルール、パーソナライズパターン — 適切な根拠、抑制リストの確認、受信者ごとの関連性が前提です。
Cargo が所有するメールボックスから、作成済みの文面を実際に送信する場合（ユーザー自身のシーケンサーに引き渡すのではなく）	../cargo-mailbox-management/SKILL.md + references/acceptable-use.md（§3 のチェック、ブロック条件）	メールボックスのプロビジョニングとウォームアップ、送信量に上限を設ける5→40件／日の送信ランプ、sendEmail アクション（送信1件あたり0.1クレジット）、ワークスペースの抑制リスト、イベントとしての返信／開封／クリック。
定期実行するワークフローの構築または変更（cron／webhook／スケジュールされたツール／プレイ）、ステップシーケンス、トリガー、デプロイ／検証サイクルの設計	../cargo-orchestration/SKILL.md（機能）+ このスキルのレシピから該当するパターンを適用 + すべての有料ノードのプロバイダープレイブック（§11、特に定期実行のセクション）	ツール／プレイのワークフロー用スキーマ、ノードグラフの構文、ポーリング戦略、出力取得、プロバイダーごとの既定実行間隔と再課金の条件。

レシピ：手順を追ったプレイブック（実行前に確認）

この一覧を確認し、タスクに合ったレシピを読んでください。該当するレシピがある場合は、実行計画として手順どおりに進めてください。

レシピ	次の場合に使用します……
recipes/source-planning.md	情報源が明らかでない場合は、まずお読みください。 質問をフィールドに変換し、候補となる情報源を2～3件、5～10行で検証して、ファンアウトを行う前にヒットあたりのコストを提示します
recipes/prospecting.md	検索 → 情報付加 → 検証 → 同期をエンドツーエンドで実行します（P1／P2／P3のバリエーション）
recipes/build-tam.md	対象市場全体（TAM）のリストを大規模に作成する場合（企業100～10,000社）
recipes/linkedin-url-lookup.md	名前と会社名から個人のLinkedInプロフィールURLを特定し、厳格な本人確認を行う場合
recipes/portfolio-prospecting.md	投資家／アクセラレーター → 投資先企業 → 担当者
recipes/job-change-monitoring.md	連絡先セグメントに対して waterfall.detectJobChange（cargo独自）を実行する場合
recipes/funding-watch.md	最近資金調達を行った企業を追跡する場合
recipes/tech-intent.md	技術スタックや採用意向のシグナルから企業を見つける場合
recipes/icp-discovery.md	Closed-WonとClosed-Lostのセグメントを比較し、ICPのシグナルを見つける場合
recipes/custom-datapoints.md	営業担当者のICPについて、収集するカスタム属性とリアルタイムシグナルを設計する場合。カタログに基づいて実現可能性を確認したうえで、列、スコアリング、セグメント、更新頻度に組み込みます
recipes/outreach-activation.md	シグナルセグメントを送信可能なアウトリーチに変換する場合（情報付加 → 検証 → パーソナライズ → シーケンサーへの引き渡し）
recipes/ads-audience-activation.md	セグメントを有料メディアに送信する場合 — Google Ads Customer MatchまたはLinkedIn Matched Audiencesを使用し、マッチ率を確認します
recipes/review-and-iterate.md	人間によるレビューが必要な判断結果を扱う場合 — シートへの引き渡し、修正のグループ化、恒久的な修正、評価セットとしての保持
recipes/re-engagement.md	新しいシグナル（転職、資金調達、技術意向）が発生した場合に限り、接点が途絶えた連絡先に再アプローチする場合
recipes/lost-deal-revival.md	lost_reason（社内推進者の退職、予算、時期）に基づいて分岐し、CRMのClosed-Lost案件を再活性化する場合
recipes/account-expansion.md	既存顧客のアカウントで複数の関係者との接点を構築する場合 — 新規購入者を見つけ、ワークスペースのContactsモデルと照合して重複を除外します
recipes/save-as-play.md	成功した単発の実行を、永続的なスケジュール済みプレイまたはcronツールに変換する場合 — 繰り返し可能な情報取得を行った後に提案します
recipes/import-gtm-data.md	既存のGTMデータ（あらゆるツールのCSV／CRMエクスポート）をモデルにインポートして品質監査を行い、定期的なロジックを選択的にプレイとして再構築し、同等性を確認する場合
recipes/clay-to-cargo.md	Clay専用：CSVではなく列の設定を取り出す方法、列ファミリーからアクションへの対応表、1対1で対応しないClayの4つの概念（ウォーターフォール、実行条件、自動更新、部分実行）、およびClay独自の出力との同等性確認

該当するものがない場合は、上記のフェーズ別ドキュメントから最も近いパターンを探して応用するか、agents/execution-plan-creator.mdを呼び出して、プロバイダー／アクションのスラッグとコスト見積もりを含むカスタムチェーンを作成してください。広範な情報源調査をファンアウトして実施する場合（業界別、地域別など）は、承認済みの範囲をagents/list-builder.mdに委任してください。各範囲で事前承認されたアクションを1つだけ実行し、行データをメインコンテキストに含めずに、結果の行をファイルに返します。（プラグインを使用するClaude Codeでは、どちらもネイティブサブエージェントとしてインストールされています：cargo-execution-plannerとcargo-list-builder。）

3) コスト管理 — 必須ゲート

完全な仕様は references/cost-discipline.md を参照してください。すべてのタスクで守るべき要点は以下のとおりです。

1. サンプル → 承認 → 本実行の順に進めます。 まず、実際の入力から一部を実行します。1つのアクションの設定を確認するには1～3行、バッチ処理の前には10～20件のレコードを使います（1行ではヒット率を確認できません）。その後、4つのセクションからなる承認メッセージ（前提・サンプル結果の原文・クレジット／範囲／上限 — 本実行で登録するレコード数と費用を必ず明記し、実際の残高と照合・調整する・選択肢を3つに絞って提示）を提示します。ユーザーが選択するまで AWAIT_APPROVAL の状態を維持してください。未承認または費用が不明なアクションを一斉に実行してはなりません。また、サンプルの承認を本登録全体の承認と見なしてはなりません。
2. 有料アクションの後は毎回、実績を報告します：消費クレジット数、残高、ヒット率（「40件中34件のメールアドレスを発見」など）、見積もりと実績の差、および差がある場合はその理由です。独自に計算するより、billing usage get-metrics を優先してください。
3. 1.4×N件を多めに取得してから絞り込みます — カバー範囲は企業に左右されます。追加のプロバイダーで補おうとするのではなく、不完全な行を除外してください。
4. まず件数を数え、支払いはその後です — 検索は返された行数に応じて課金されます。limit を厳守し、本取得の前に1行のプローブを使ってプールの規模を決めてください。
5. 電話番号の取得は慎重に扱います — ユーザーが明示的に依頼した場合に限り、条件を満たす見込み顧客のみ対象とします。安価な方法でもこの原則は変わりません。aiArk.findMobilePhone（0.5クレジット、携帯電話番号のみ）は最初の手段で、見つからなければ課金は0です。しかし、その後のエスカレーションには3～7クレジット（メールアドレス取得のおよそ10倍）がかかるため、リスト全体の電話番号を調べる場合も、ほかの有料一斉実行と同じ承認が必要です。

4) 実行後は毎回、実績報告を行い、データに基づく次のステップを提示します

完了した実行の最後に、上記の実績報告を行い、続いてデータから導き出した次のステップを最大2～3件提案します。一般的な選択肢を並べてはなりません。 必ず以下の形式にします。

1. 継続性 — このセッションで作成した成果物をもとにします（「この70社のうち67社に RevOps チームがあります。見込み顧客を探しますか？」など）。一般的なアイデアを新たに持ち出してはなりません。
2. 予算を考慮 — 残高に照らして提案します（「残り約9クレジットなら、検証済みメールアドレスを約5件取得できます」など）。
3. 単位あたりの費用を明記 — 「メールアドレス取得のウォーターフォールは1件あたり約1.4クレジットです」など。
4. 選びやすい既定の判断基準を提示 — 1語で答えられるようにします（「既定では、資金調達データがあり、RevOps が2人以上いて、求人掲載が最近の企業を選びます」など）。
5. 別の希望にも対応 — 必ず「または、まったく別のことでも構いません」で締めくくります。

実行によって長期的に再利用できる結果が得られた場合は、提案の1つとして体系化を含めてください。詳細は recipes/save-as-play.md を参照してください。

実行またはバッチ処理で問題が起きた場合（エラー、後続の値の欠落、想定外の費用など）は、cargo-diagnostics スキル（../cargo-diagnostics/SKILL.md）に引き継ぎます。有料の処理を再実行する前に、バッチを調べて根本原因を特定してください。計画の承認ゲート、選択肢の提示、結果の共有に関する対話の既定値は、../cargo/references/interaction.md を参照してください。

5) 優先プロバイダースタック（レシピではこの7つを最初に使用）

この7つのクレジット制プロバイダーは、カタログ内で最も低いクレジット費用で、見込み顧客の特定 → エンリッチメント → 検証 → シグナルのパイプライン全体をカバーします。このスキルの recipes/ にあるすべてのレシピでは、このスタックを最初に使用します。

プロバイダー	役割	主なアクション（クレジット単位のコスト）
salesNavigator	ソーシング	searchLeads（0.2）、searchAccounts（0.2）、findCompanyInsights/Metrics/EmployeesCount/Distribution（各0.25）
aiArk	LinkedIn を基盤とするエンリッチメント＋最安の検索	enrichCompany（0.01 — カタログ内で最安の企業属性情報）、searchCompanies（0.01/レコード、類似企業のシード）、searchPeople / reverseLookup / analyzePersonality（0.05）、enrichPerson（0.1 — プロフィール ＋認証済みメールアドレス）、findMobilePhone（0.5）
waterfall	複数ソースによるエンリッチメント＋シグナル	enrichContact（2）、enrichCompany（1）、verifyEmail（0.1）、detectJobChange（3）、searchProspects（3）、findPhone（7）
FullEnrich	プレミアムな連絡先検索＋無料のソーシング	searchPeople / searchCompanies / lookupPerson / lookupCompany（0）、fetchPeople / fetchCompanies 抽出ツール（0）、findEmail（1）、findPhone（6）、findPhoneAndEmail（7）、reverseEmailLookup（1）
apolloio	ニッチな領域をカバーするエンリッチメント	enrichPerson（1、revealPhoneNumber を指定すると 9）、enrichOrganization（1）。searchPeople（0、または shouldEnrich を指定すると1/人）と searchOrganizations（0.01/レコード）もクレジットで実行できます。その他7つのアクションには独自の Apollo API キーが必要です
theirStack	テックスタック＋採用意欲	searchTechnologies（0.5）、searchJobs（0.5）、searchCompanies（0.5）
peopleDataLabs	大規模なバックフィル	enrichPerson（3）、enrichCompany（3）、searchPeople（3）、searchCompanies（3）、queryPeople/Companies（3）

aiArk と apolloio はエンリッチメント層の両端に位置し、好みではなく 手持ちの情報 に応じて選びます。LinkedIn URL があれば常に aiArk が最適です（プロフィール＋認証済みメールアドレスは0.1、携帯電話番号は0.5、見つからなければどちらも課金なし）。apolloio は 1クレジットのニッチ領域カバー段階 として、パイロットで aiArk（0.1）と waterfall（2）が見つけられなかった Apollo のヒットが確認できた場合に、バッチ単位で追加します。特に投資家の支援を受けた企業やポートフォリオ関連のニッチで有効です。どちらも、通常の大規模ソーシングでは salesNavigator（0.2/リード）に取って代わるものではありません。

3つのシグナル群はスタックの対象外であり、タスクごとに references/stage-action-map.md から選びます。aiArk.enrichCompany を超える 企業属性情報の詳細化 → companyEnrich.enrichByDomain（0.25）、資金調達／買収 → enrichCrm.getFunding（1。カタログ内でクレジット課金される唯一の資金調達アクション）、既知のドメインの テックスタック → builtwith.getDomainSummary（無料）を先に実行し、その後 builtwith.enrichDomain（1）を実行します。

プロバイダーごとの詳しい説明は provider-playbooks/ を参照してください。各プロバイダーの 継続利用 セクションでは、単発ではなく、監視、プレイ、またはスケジュール実行を行う場合について説明しています。136の統合カタログ全体を対象に、各ステージで最も安価なアクションをまとめた表は references/stage-action-map.md を参照してください。

識別子はすでにありますか（ソーシングは不要ですか）？ 上記のスタックは、ソーシングを優先する基本フローです。LinkedIn URL がすでにある場合、最も安価なエンリッチメントは aiArk.enrichPerson です（0.1 — 完全なプロフィール に加えて 認証済みメールアドレス。メールアドレスが見つからない場合は課金なし）。メールアドレスが不要なら linkedin.enrichProfile / enrichCompany（0.25）に切り替え、waterfall.enrichContact は避けてください。こちらも linkedin URL を受け付けますが、2クレジットで20倍の価格です。電話番号 が必要ですか？ まずは aiArk.findMobilePhone（0.5）を使い、3～7クレジットの段階には進まないでください。LinkedIn イベント URL がありますか？ linkedin.extractEventAttendees で参加者リストを直接ソーシングできます。メールアドレス がありますか？ aiArk.reverseLookup（0.05）の後に leadMagic / contactOut を使います。入力タイプから最安アクションを選ぶ完全な対応表は references/stage-action-map.md を参照してください。

6) レシピの基本チェーン（デフォルト）

1. SOURCE   → salesNavigator.searchLeads / searchAccounts            (0.2/record)
              lookalike seeds, or filters SN can't express (skills,
              education, tenure)? aiArk.searchCompanies / searchPeople (0.01–0.05/record)
              free first pass on plain title/industry/size/geo filters?
              FullEnrich.searchPeople / searchCompanies                (0/record)
2. DEDUPE   → match against the workspace's own Companies / Contacts models
              on domain / linkedin_url (storage SQL or a segment filter)  (free)
3. ENRICH   → LinkedIn URL in hand? aiArk.enrichPerson (0.1) FIRST — profile + verified
              email in one call; linkedin.enrichProfile/enrichCompany (0.25) if no email needed
              aiArk.enrichCompany (0.01) for firmographics; companyEnrich.enrichByDomain
              (0.25) on the rows that come back thin
              + waterfall.enrichContact / enrichCompany              (1–2/record)
              + apolloio.enrichPerson / enrichOrganization on the niche residue (1/record)
4. SIGNAL   → enrichCrm.getFunding                                   (1/record)
              + theirStack.searchJobs / builtwith.getDomainSummary   (0–0.5/record)
              + waterfall.detectJobChange                            (3/record)
5. CONTACT  → FullEnrich.findEmail — only on rows step 3 left without
              an email (fallback peopleDataLabs)                     (1–3/record)
6. VERIFY   → waterfall.verifyEmail                                  (0.1/record)
7. BACKFILL → peopleDataLabs.enrichPerson (only if step 5 missed)    (3/record)
8. QA       → scripts/contact-accuracy-audit.ts                      (free, local)

8プロバイダーのスタックにおける基本チェーンについて、2点注意してください。ステップ3のaiArk.enrichPersonはすでに検証済みのメールアドレスを返すため、ステップ5は残りのデータに対してのみ実行します。メールアドレスがすでにある行に対してFullEnrich.findEmail（1）に費用をかけないでください。また、目的に電話番号が含まれる場合は、prospeo（3）／FullEnrich（6）／waterfall（7）の前に、aiArk.findMobilePhone（0.5、携帯電話のみを対象とし、見つからない場合は請求額0）が最初の段階となります。§3の慎重に使うべき手段に関するルールは、引き続き4つすべてに適用されます。

フェーズに合わせて調整してください。ユーザーの目的に関係のないステップは省きます。データのソーシングのみを行う場合は、ステップ1だけを実行します。「すでに持っているリストをエンリッチする」場合は、ステップ2～7を実行します。

7) 出力の取得 — run downloadではなくrun download-outputsを使用する

エージェントがアクションによって生成された実際のデータ（エンリッチされたフィールド、見つかったメールアドレス、検索結果）を必要とする場合は、次を使用します。

cargo-ai orchestration run download-outputs \
  --workflow-uuid <uuid> \
  --output-node-slug <slug> \
  --format json

{"url": "..."}を返します。これは、出力ノードのデータのみを含むCSV／JSONへの署名付きURLです。実行全体のレコードを取得するrun downloadよりも高速で、低コストです。references/output-retrieval.mdと../cargo-analytics/SKILL.mdを参照してください。

直接のaction execute-batchには参照先となるワークフローがなく、--wait-until-finishedは行ではなくバッチオブジェクトを出力します。行を取得するには、cargo-ai orchestration batch download --uuid <batch-uuid>を実行します。{"url": "<signed CSV URL>"}を返し、CSVでは各トップレベルの出力キーがcargo_<key>列として追加されます（検索結果の配列は1つのcargo列に格納されます）。

8) 連絡先の正確性 — 目視で判断せず、QAスクリプトを実行する

scripts/にある、決定論的なTypeScriptスクリプト4つ（Node ≥ 22.18、依存関係なし、CIでフィクスチャテスト済み）が、コンテキスト内での行チェックに代わります。スクリプトを実行してください。行を見ながら推論して、そのロジックを再現しないでください。 詳細な方針、パイプラインの順序、SEND／VERIFY／REVIEW／REMOVEの判定の意味については、references/contact-accuracy.mdを参照してください。

• scripts/validate-emails.ts — 有料のverifyEmailを実行する前に、構文・リスク・重複を無料で除外します。
• scripts/select-current-role.ts — 経歴の配列から実際の現職を選びます（転職した人を検出します）。
• scripts/validate-linkedin-names.ts — 氏名とプロフィールの一致を確認します（同姓同名の別人を検出します）。recipes/linkedin-url-lookup.mdと組み合わせて使用します。
• scripts/contact-accuracy-audit.ts — 統合後の出力に、行ごとの最終的なaudit_actionスタンプを付与します。結果の概要件数をレシートに記載してください。ファイル、または完了済みの実行（@cargo-ai/api経由の--workflow-uuid）を直接読み取ります。

9) アクションの形式ルール（すべてのレシピ）

このスキル内のすべてのアクション JSON は、../cargo-orchestration/references/examples/actions.md のルールに従います。

• kind: "connector" アクションの形式：{"kind":"connector","integrationSlug":"<slug>","actionSlug":"<slug>"}。connectorUuid は config に含めません。プラットフォームが integrationSlug から、ワークスペースで認証済みのコネクタを自動的に解決します。
• トップレベルのアクションに config はありません。省略してください。 入力は --data / --records に指定し、このファイル内のすべてのレシピではアクションにこのキーを含めません。これは action execute、execute-batch、get-output-schema のすべてに当てはまります。action list が返すオブジェクトは、そのままこの3つすべてに貼り付けて使えます。入力を誤って config に入れると、config が原因だと示すエラーなしに除去されます。そのため、最初の必須フィールドがないとして呼び出しが拒否されるか、必須フィールドがなければ何も行われずに実行されます。呼び出しが空の結果を返す場合や、理由が分からないまま失敗する場合は、まずここを確認してください。入力キーのスペルミスは実行前に拒否されます（Unknown field: <key>）。ただし、これはトップレベルのアクションに限られます。ワークフローノード内では、引き続き何も通知されずに破棄されます。
• 確信のないスラッグを手入力したり、カタログを延々と探したりしないでください。 cargo-ai orchestration action list <keywords> [--integration-slug <slug>] は無料で、すべてのインテグレーションに加え、ネイティブアクション、ツール、エージェントも検索し、アクションのクレジットコストとともに、そのまま貼り付けられるアクションオブジェクトを返します。有料呼び出しの前に、スラッグと価格の両方を手軽に確認できます。「これに使える有料アクションはどれか」を調べる場合は、cargo-ai connection action search <keywords> --credits-only を使うと、有料のものに絞り込めます。どちらも、以下のプロバイダープレイブックの代わりにはなりません。入力の注意点、ヒット率、繰り返し使用時の落とし穴は、プレイブックに記載されています。
• 複数ステップのノードグラフの場合：connectorUuid は config ではなく、ノードのトップレベルに置きます。ノード間の補間には {{nodes.<slug>.<field>}} を使用します。エージェントノードの出力は .answer の下にラップされます（{{nodes.<slug>.answer.<field>}} として読み取ります）。

10) 行き詰まった場合 — ワークスペースレポートを送信する

レシピが繰り返し失敗し、原因が明らかでない場合は、cargo-ai workspaceManagement report create でエスカレーションしてください。../cargo-workspace-management/SKILL.md の「レポート」セクションを参照してください。

11) プロバイダープレイブック — 呼び出し前に読む（単発・継続利用を問わず）

停止 — 下記のプロバイダーに対して有料アクションを実行したり、プロバイダーを定期実行するプレイ／ツールノードグラフに組み込んだりする前に、必ずプレイブックを開いてください。 各プレイブックには、正確なアクションスラッグ、設定の形式、入力時の注意点、コストの落とし穴が記載されています。5秒かけて読むほうが、有料呼び出しを1回失敗させるよりも安く済みます。また、バッチを失敗させると有料呼び出しが100回分失敗します。プロバイダーを定期実行ワークフローに組み込む場合は、リスクがさらに高くなります。設定に誤りがあるとスケジュール実行のたびに繰り返され、実行間隔を間違えると同じ行に対して延々と再課金されます。まさにこのため、各プレイブックの末尾には（スケジュールへの適合性、既定の実行間隔、再課金の条件、抽出ツールをまとめた）定期利用セクションがあります。呼び出し可能なアクションを持つクレジットベースのプロバイダーにはすべてプレイブックが用意されていますが、例外は明記された2つです。openRouter はクレジットベースのアクションではなくモデル一覧表示機能を提供しているため、記載すべき内容がありません。xAccount のアクションは、ユーザー本人のXアカウントとして投稿、返信、「いいね」、DM送信を行うため、プレイブックではなく references/acceptable-use.md §2 に拒否の説明があります。記載対象となる見込み客開拓の用途がないためです。brightData と proxycurl には、一覧に載せないままにせず、プレイブックを追加しました。文書化されていないプロバイダーもコスト表には表示されるため、許容される利用方法を明示しないままにするのは望ましくありませんでした。provider-playbooks/brightData.md では、消費者ターゲティングへの拒否を冒頭で明示しています。独自キーを使うインテグレーションについては、references/alternatives.md と references/stage-action-map.md を参照してください。

優先順位（レシピでは以下を先に取り上げます）：

• provider-playbooks/salesNavigator.md — LinkedIn ネイティブのリードおよびアカウントの情報源（レコードあたり0.2）。
• provider-playbooks/aiArk.md — LinkedIn を基盤とする人物／企業データ：enrichPerson はプロフィールと確認済みメールアドレスを0.1で返し、findMobilePhone（0.5）は最安の電話番号取得手段です。searchCompanies（レコードあたり0.01）では類似企業を検索でき、analyzePersonality（0.05）はカタログ内で唯一の機能です。すべてのアクションは管理対象の接続で実行されます。
• provider-playbooks/waterfall.md — 便利な万能ツール：エンリッチメント、検証、cargoでのみ利用できるdetectJobChangeシグナル。
• provider-playbooks/FullEnrich.md — プレミアムな連絡先検索。reverseEmailLookup は独自機能です。searchPeople／searchCompanies と fetch* 抽出ツールは無料です。
• provider-playbooks/apolloio.md — ニッチ分野のカバー範囲を補う1クレジットのエンリッチメント手段（人物＋組織）。Apollo が利用できると思い込む前に、必ず読んでください。11個のアクションのうちクレジットベースなのは2つだけで、残りには独自の Apollo API キーが必要です。
• provider-playbooks/theirStack.md — 技術スタックと採用意欲のシグナル。
• provider-playbooks/peopleDataLabs.md — 一律3クレジットで行う大規模なバックフィル。 ソーシングと企業データの専門ツール：
• provider-playbooks/linkedin.md — ネイティブの LinkedIn 統合のアクションセット（プロフィール、企業、投稿、求人）。
• provider-playbooks/oceanio.md — シードドメインから類似企業を検索します。aiArk.searchCompanies（0.01）では指定できない、テクノグラフィック／ウェブトラフィックのフィルターに対応しています。
• provider-playbooks/datagma.md — 軽量な人物／企業データのエンリッチメント代替ツール。
• provider-playbooks/companyEnrich.md — ドメイン単位のより詳細な企業属性データ（0.25）と、アイテムごとに課金される類似企業検索。
• provider-playbooks/enrichCrm.md — CRM レコードのエンリッチメント。getFunding は資金調達シグナルのフォールバックです。
• provider-playbooks/societeInfo.md — フランスの登記簿に基づく企業／連絡先データ（SIREN/SIRET）。
• provider-playbooks/snitcher.md — ウェブサイト訪問者の特定。定期実行される抽出機能は、コストがかさむ要因です。
• provider-playbooks/piloterr.md — 超低コストの一括企業データ抽出機能と G2 の製品情報。
• provider-playbooks/g2.md — ソフトウェアレビューとカテゴリーのシグナルデータ。
• provider-playbooks/theSwarm.md — ターゲット企業／人物へのウォームイントロネットワークのマッピング。
• provider-playbooks/mixrank.md — プレミアムな人物／企業データの補完（検索ごとに 4、電話番号のみの逆引き検索）。
• provider-playbooks/storeleads.md — ドメインごとに 0.01 で EC ストアのデータ（プラットフォーム、アプリ、トラフィック、売上）を取得します。TAM 抽出機能は同期のたびに再課金されます。
• provider-playbooks/cargoSignals.md — インテントシグナルのフィード（旧 rodz）。提供されたリードごとに課金されます。ウォームイントロのデータ補完と Company Followers の自動開始が、コストがかさむ要因です。
• provider-playbooks/explorium.md — ビジネス／見込み客データ、イベント、Bombora のインテントデータを独自のキーで取得します。廃止された cargo のエンリッチメントスラッグを引き継いでいます。 メールと連絡先に特化したプロバイダー（すべて VERIFY ステップにデータを提供します。references/waterfall-strategy.md を参照）：
• provider-playbooks/hunter.md — ドメイン検索によるメールアドレスの検索と検証。
• provider-playbooks/prospeo.md — メールアドレス／電話番号の検索。LinkedIn URL を入力する方法もあります。
• provider-playbooks/icypeas.md — 低予算でのメールアドレスの検索／検証。
• provider-playbooks/findyMail.md — メールアドレス検索の代替手段。
• provider-playbooks/leadMagic.md — メールアドレスと携帯電話番号の検索の代替手段。
• provider-playbooks/contactOut.md — LinkedIn プロフィールから連絡先情報を取得。
• provider-playbooks/zeroBounce.md — waterfall.verifyEmail に対するメールアドレス検証のセカンドオピニオン。
• provider-playbooks/bouncer.md ／ neverBounce.md ／ kitt.md ／ enrichley.md — 検証のロングテール（0.3 ／ 0.2 ／ 0.05 ／ 0.1。enrichley のスラッグは verify であり、verifyEmail ではありません）。
• provider-playbooks/bounceban.md — デフォルトの検証では判定できない残余のアドレスを対象とした、全メール受信設定および SEG 保護付きの検証（0.1）。
• provider-playbooks/dropcontact.md — フランス／EU の登記情報を幅広く利用したメールアドレス検索。email の出力は配列です。
• provider-playbooks/enrowio.md — メールアドレス検索（1）と検証（0.1）。fullName のみを受け取ります。
• provider-playbooks/reverseContact.md — LinkedIn から会社を検索（クレジット制）。プロフィール検索には独自のキーが必要です。
• provider-playbooks/rocketreach.md — 人物検索（1）。医療／NPI に特化しています。スキーマキー currrentEmployer に注意してください。
• provider-playbooks/forager.md — LinkedIn URL から個人用メールアドレスと電話番号を取得。
• provider-playbooks/pipecorn.md — 独自キーを使った連絡先のウォーターフォール（仕事用メールアドレス、電話番号、企業の従業員）。個人用メールアドレスのアクションは利用規約に準拠する場合に限られます。
• provider-playbooks/cleon1.md — 電話番号検索の最終段（1 回の検索につき 15）。明示的なユーザーリクエストがある場合に限ります。 調査・スクレイピング：
• provider-playbooks/firecrawl.md — 調査／パーソナライズ段階でのウェブスクレイピング。
• provider-playbooks/serper.md — 調査とURL発見のためのGoogle SERPクエリ。
• provider-playbooks/linkup.md — ウェブ検索（通常0.5／詳細2）と、出典付き／構造化された回答。
• provider-playbooks/parallel.md — カタログで最も安価なページ読み取り（extract、URLあたり0.025）に加え、呼び出し元が指定した出力スキーマを埋める唯一のアクションであるcreateTask。
• provider-playbooks/exa.md — ドキュメントタイプのcategoryフィルターと公開日の範囲指定に対応したセマンティック検索。
• provider-playbooks/builtwith.md — ドメインのテクノロジースタック。getDomainSummaryは無料で、有料段階より先に実行されます。
• provider-playbooks/x.md — 1アクションあたり0.02で公開X投稿とプロフィールを取得します。利用許容基準を満たす場合に限られるシグナル段階です。
• provider-playbooks/sillage.md — モデルから読み戻すインバウンドシグナルの検出結果。無料のため、シグナルに関する質問では最初に実行されます。
• provider-playbooks/brightData.md — URLでInstagram／TikTok／Facebook／YouTubeのプロフィールを取得します（1アクションあたり0.1）。カタログで唯一の、LinkedInでもXでもないソーシャルメディア対応です。プレイブックは、利用を制限する消費者ターゲティングの拒否事項から始まります。
• provider-playbooks/proxycurl.md — 独自のキーを使ったLinkedInプロフィール／企業の検索。

LLMプロバイダー（すべて、instructアクションを1つ提供し、1,000トークンパッケージあたりの料金はモデルごとに異なります。プロンプトはreferences/prompt-library/index.mdから取得します）：

• provider-playbooks/anthropic.md — 判断タスク向けのデフォルト（Haiku 0.05、Sonnet 0.2、Opus 2）。temperatureはadvancedSettings内に設定し、maxTokensの指定が必須です。
• provider-playbooks/openAi.md — 最も安価な一括処理向けモデル（gpt-5-nano 0.006）と、ネイティブのJSONスキーマ出力。
• provider-playbooks/gemini.md — 低価格で高スループット（Flash 0.01、15,000／分）と、検索グラウンディング。
• provider-playbooks/perplexity.md — ウェブ情報に基づく調査回答。デフォルトモデルは高価なsonar-deep-researchです。必ずmodelを明示してください。

型付き判定（instructではなく、質問を受け取り確率を返します）：

• provider-playbooks/typesafe.md — はい／いいえ、選択、スコアの回答を、入力1,000トークンあたり0.01で確率とともに返します。ネイティブのclassifyアクションも同じ入力を受け取ります。

12) 参考資料

• references/cost-discipline.md — 必須の支出ルール：パイロット → 承認ゲート、実行ごとの領収記録、1.4×N の過剰プロビジョニング、件数優先の規模設定、プロバイダーの課金ルール。
• references/contact-accuracy.md — 決定論的な QA スクリプト（メールの除外、現職確認、名前の照合、最終監査）と SEND/VERIFY/REVIEW/REMOVE の判定。
• references/prompt-library/index.md — 名前付きでパラメーター化された LLM プロンプト約 40 件（パーソナライズ、スコアリング、リサーチ、適格性確認、シグナル分析、抽出）。エンリッチメントやスコアリングのプロンプトを一から作成する前に、このインデックスを grep してください。再発明するより再利用するほうがよく、各エントリーにはテスト済みの出力コントラクトが含まれています。必要なシャードだけを読み込み、すべてを読み込まないでください。
• references/stage-action-map.md — 全 136 件のインテグレーションカタログを対象に、ステージごとの最も安価なクレジットベースのアクションを示します。
• references/credits-cost-table.md — クレジットベースの全 180 件のアクションの自動生成コスト表。
• references/waterfall-strategy.md — エンリッチメントの目的別の標準ウォーターフォールチェーン（各レシピの「フォールバック」はこれに従います）。
• references/alternatives.md — 優先スタックで対応できない場合に利用する、ロングテールのプロバイダー差し替え候補。
• references/output-retrieval.md — アクションデータを取得するための run download-outputs パターン。