なぜApolloが最初のソーシング先であるべきか - Clayではなく

誰も語らないボトルネック

すべてのGTMパイプラインは同じところから始まる。人を見つける必要がある。特定の企業の、特定の役職の、特定の人材を。そしてほとんどのチームにとって、そのステップはいまだに手作業だ。LinkedIn Sales Navigatorを開く。スクロール。クリック。エクスポート。インポート。エンリッチメント開始。

下流のステップばかりが注目される。エンリッチメントウォーターフォール。ICPスコアリング。メールのパーソナライゼーション。CRMルーティング。みんながまず自動化するのは、「難しい」パートに感じられるこれらのステップだ。

しかし、それらは難しいパートではない。難しいのはソーシングだ。2億7,500万人の中から適切な500人を見つけること。そしてほとんどのチームはいまだに手作業でやっている。

なぜApolloが先なのか

ApolloはB2B SaaSで最も豊富な人材データベースを持っている。2億7,500万以上のコンタクト。7,300万以上の企業。検証済みメール。直通電話番号。シニオリティレベル。企業のテクノグラフィクス。そしてAPIは月間10,000クレジットまで無料だ。

これがパイプライン全体の経済性を変える。

従来のやり方はこうだ：ApolloのブラウザUIを開く、検索を実行、CSVをエクスポート、Clayにインポート、エンリッチメントウォーターフォールを実行、CRMにプッシュ。アウトリーチが始まる前に4つの手動ステップ。

新しいやり方：1つのAPIコールが人材＋企業データの構造化JSONを返す。スクリプトがSupabaseに書き込む。差分に対してエンリッチメントが走る。CRM同期は自動。ソーシングステップが30分のクリック作業から1つのAPIコールに変わった。そしてカレンダーではなくCronで動く。

ApolloはClayを置き換えるものではない。解決する問題が違う。Apolloが人材検索を担当する。Clayがエンリッチメントとルーティングを担当する。Supabaseがストレージを担当する。各ツールが得意なことをやる。

2つのトラック

テクニカルな快適度に応じて、2つの構築方法がある。

ハッカートラックは完全なコントロールを求めるテクニカルオペレーター向けだ。Supabaseをデータウェアハウスに。Apollo APIでソーシング。Claude Codeでスクリプトの作成と反復。Mac Mini（または任意の常時稼働マシン）でCronジョブを実行。

月額合計コスト：Apollo無料ティア（$0）＋Supabase無料ティア（$0）＋電気代（約$5）。コードはリポジトリにある。データはデータベースにある。パイプラインは寝ている間に動く。

バッチングパターンが重要だ。Apolloですべてを一度に検索してはいけない。ペルソナごとにバッチする。まずVP/Director of Marketing。次にSales。次にRevOps。各バッチが独自のタイトルフィルターパスと、既存コンタクトに対する独自の重複チェックを受ける。これによりクレジットの無駄を防ぎ、最初からデータを整理できる。

SDRイネーブルメントトラックはGTMエンジニアが社内にいないチーム向けだ。Claude Co-workのフォルダーシステムを使う。3つのフォルダー：Raw Data（ApolloのCSVエクスポート）、Research（企業概要、テックスタック分析）、Output（アイスブレーカー、メールシーケンス、CRMインポートファイル）。

ApolloのエクスポートをRaw Dataにドロップする。Claudeに各企業のリサーチを依頼する。タイトル＋企業リサーチに基づいてアイスブレーカーの生成を依頼する。OutputはCRMインポート用のCSVになる。50コンタクトで全体のフローが10分。SDRが手作業でやれば2-3時間かかるところだ。

タイトルリーケージ問題

パイプラインの品質を台無しにする、早期に解決しなければならない問題が1つある。タイトルリーケージだ。「VP of Marketing」で検索すると、HR責任者、マーテック企業のエンジニアリングマネージャー、LinkedInのヘッドラインに「Marketing」が入ったインターンが返ってくる。

Apolloのシニオリティフィルターは役に立つが十分ではない。許可リスト/ブロックリストパターンが必要だ。タイトルには特定の文字列（「marketing」「growth」「demand gen」）が含まれていなければならない。タイトルに別の文字列（「intern」「assistant」「HR」「recruiter」「engineering」）が含まれていてはならない。

許可リストを先に、次にブロックリストを実行する。ドロップをログに記録して、時間とともにリストを調整できるようにする。リストはハードコードではなくコンフィグファイルに置く。こうすれば、非テクニカルなチームメンバーがソーシングスクリプトに触れずにターゲティングを調整できる。

インフラ

これ全体がMac Miniで動いている。常時稼働。$599の一括購入、月$5の電気代。リモート社員にMacBookを送れるなら、常時稼働のGTMサーバーも運用できる。

Cronは毎晩走る。Apolloから新しいコンタクトを取得。タイトルフィルター。Supabaseに対する重複チェック。新しいコンタクトを挿入。差分に対してエンリッチメントを実行。CRMに同期。朝、デスクに着くころには、新しい適格なコンタクトがパイプラインで待っている。

しかし、Mac Miniがポイントではない。ポイントは、インフラが1台のマシンですべてをこなせるほどシンプルだということだ。クラウドオーケストレーションなし。Kubernetesなし。使用量に応じてスケールする月額SaaS費用なし。スケジュールに従ってスクリプトを実行するマシンがあるだけだ。

カンファレンスプロスペクティング

ここでアーキテクチャの真価が発揮される。中規模のSaaSカンファレンスには500-2,000人の参加者がいる。参加者リストはイベントの2-4週間前に公開される。ほとんどの営業チームは手動で20-30人を選別してギブアップする。

全リストをApolloに通す。名前＋企業でマッチング。タイトルフィルター。ICPスコア。結果をティア分けする：Tier 1（必ず会う、事前にスケジュール）、Tier 2（イベント中に見つける）、Tier 3（バッジスキャンしてナーチャリング）。

800人参加のカンファレンスの例：Apolloが620人にマッチ（77%マッチ率）。タイトルフィルターを通過したのが340人。ICPスコアリングでTier 1が85人、Tier 2が120人、Tier 3が135人。事前アウトリーチでイベント開始前に12のミーティングを予約。合計パイプライン：手動選別での前回カンファレンスの3倍。

さらに深く

theGTMOS.aiのApollo Wikiに完全な分解がある。APIアーキテクチャ、タイトルフィルタリングパターン、Supabaseウェアハウススキーマ、両トラックのステップバイステップワークフロー。4カテゴリにわたる8エントリ。すべて本番パイプラインからのパターンだ。

人材検索はステップ1だ。最後ではなく、最初に自動化すべきだ。