Clay（クレイ）とは？GTMオートメーションの機能・料金・導入ポイントを解説

MA（マーケティング自動化ツール）を導入したが、リードの8割は名前とメールアドレスだけ。SFA（営業支援ツール）を入れたが、入力が面倒で半数の営業が使っていない。展示会で名刺を200枚集めたが、帰社して1社ずつLinkedIn、企業HP、ニュース記事を開いてリサーチする——50社で丸3日がデスクワークに消える。

「Clayを入れれば、このリサーチ地獄は自動化される」——そう期待している人は多いはずだ。だが私は、この期待の半分は正しく、半分は的を外していると考えている。Clayの公式事例を読み込むと、成果を分けているのはClayの機能そのものではなく、provider mixとワークフローを誰が設計し、運用し続けるかという組織側の変数だとわかるからだ。製品の話として導入を検討すると、この一番大事な条件を見落とす。

この記事は、公式pricing・FAQ・customer storiesという公開情報を土台にした整理だ。

この記事は、Clayを実際に自社導入して検証した一次データに基づくものではない。公式pricing・FAQ・customer storiesという公開情報だけを土台にした二次分析として、以下は整理される。

$5B valuationや$100M ARRといった派手な数字に流されず、Clayを「入れれば効くのか、それとも入れる側の体制次第なのか」という角度で見るべきだと考える。私の立場は懐疑的だ——国内アカウント中心で、GTM Opsの担い手が社内にいないチームには、Clayを最初の一手に据えることを勧めない。逆に、英語圏アウトバウンドか、あるいはEDINET・gBizINFO・顧問ネットワークのような公開データ層の上にワークフローを積み続けられる体制があるなら、Clayは評価額の派手さとは無関係に強いはずだ。この境界の外——自社ICPでcoverageが出るかまだ検証していない段階——については判断を留保する。覆す事実が出れば朝令暮改すべきだろう。

前提: 「データの箱」ではなく「作業台」

Clayを理解する最初の一歩は、2つの見方を区別することだ。

データの箱 = 買った瞬間に価値が確定する連絡先データベース。ZoomInfoやApollo.ioが近い。 ワークフローの作業台 = 誰がprovider（データ提供元）の順序を組み、検証ステップを設計し、運用し続けるかで価値が変わる基盤。

Clayは後者だと、この記事では定義する。公式FAQでClay自身が明記している通り、Clayは独自のLLMを持たず、OpenAI、Gemini、Claudeを使っている。つまりデータもAIも自前で持っているのではなく、複数のベンダーを束ねる作業台として機能する。この区別を、以降「箱」「作業台」という言葉で通す。

もう一つ、料金を理解する鍵になる区別がある。

• Data Credits: email、phone、company dataなど、Clay marketplace経由で買うデータの代金
• Actions: provider呼び出しやワークフロー実行など、Clayのプラットフォーム処理の代金

公式FAQでは、データが返らなかった検索は Data Credits も Actions も消費しないと明記されている。ここで気にすべきは「失敗検索そのもの」ではなく、成功するまでに何ステップ回す設計かである。この一点だけ押さえれば、以降この論点は繰り返さない。

Waterfall（複数のprovider を順番に試し、条件に合う結果が出た時点で止める仕組み）とClaygent（自然言語でaccount researchや要約、分類を回すAIレイヤー）は、Clayの実オブジェクト名としてこのあとも使う。

全体像: 4層構成

現在のClayは、次の4層で捉えると理解しやすい。

Clayの全体像

公式事例が示す「箱ではなく作業台」の証拠

Clayが公開している顧客事例は、この作業台という見方を裏づけている。

Anthropic: 3倍のcoverageとベンダー統合

Anthropicの公式customer storyで公開されている成果は次の通りだ。

この3倍という数字は英語圏ICPを前提にした公式事例であり、日本企業ICPで同じmatch rateやvalidation段数が再現できるかは、この記事の材料だけでは検証できない。

国内での再現性は、公式事例からは検証できない未確定の論点として残しておく。英語圏ICPと日本企業ICPではデータproviderのカバレッジ自体が異なるため、同じwaterfall段数・validation段数を組んでも同じ倍率が出る保証はないと考えるのが妥当だ。

3倍という数字だけを見ると「Clayが優れたデータを持っている」ように読めるが、そうではない。Anthropicが得たのは、複数ベンダーを束ねる設計と、それを運用し続ける手間をかけた結果だ。Clay自身が魔法のデータを持っているわけではない。

OpenAI: coverageをlow 40%からhigh 80%へ

OpenAIの公式customer storyでは、次の成果が示されている。

• inbound leadのenrichment coverageがlow 40%からhigh 80%へ改善
• sales team全体で8,500件以上のenrichmentを実行
• lead scoring / routingを崩さず、単一sourceから複数sourceのモデルへ移行

spendがwaterfallの何段目、どのAI promptで膨らみやすいかは公開事例からは断定できず、ここでは一般論として「曖昧なpromptと深いwaterfallほど変動価格が効きやすい」という構造だけを指摘するにとどめる。この構造上、どの段でコストが跳ねるかを事前に見積もるのは難しく、pilot段階で実測しながら上限を決めていくアプローチが妥当だと考える。

40%から80%への改善も、Clayが持つデータの質ではなく、単一ベンダー依存を崩すオーケストレーションとOps設計の結果だと私は読んでいる。この読み方が正しければ、同じ設計努力を払わないチームが同じ倍率を得られる保証はない。

ほかの公開事例

• Intercom: outbound pipeline +140%
• Rippling: cold email performance 2倍
• Hex: win-rate +50%

どれも「Clayが勝手に成果を出した」のではなく、data enrichmentとworkflow automationを営業設計に組み込んだ結果だと読むべきだ。

“

関連記事: Anthropicの技術については「Claude Computer Use徹底解説」も参照されたい。

プロダクトと料金の実務ポイント

データエンリッチメント: Waterfallの基本イメージ

1. 1つ目のproviderでemail / phone / company dataを検索
2. 結果がなければ次のproviderへ自動フォールバック
3. 検証ステップで妥当性を確認
4. 条件を満たした時点で後続ステップを止める

単一providerの弱点をワークフロー側で補える設計だ。Clayを導入する本質は、データそのものよりprovider mixを自社で設計できることにある。

Claygent: AIリサーチエージェント

Claygentは、Webや企業情報を基にしたカスタム調査をワークフローに埋め込むAIレイヤーだ。使用例は次のようなものになる。

• 「この会社の最近の資金調達ニュースを教えて」
• 「CEOのLinkedInプロフィールを要約して」
• 「競合他社との差別化ポイントを3つ挙げて」

2026年のpricing改定以降、AI利用は「固定価格」と「token usageベースの変動価格」に分かれている。曖昧なpromptほど変動価格の実行が重くなり、出力もぶれやすい。

• 悪い例: Summarize this company
• 良い例: Find one hiring signal and one business change in the last 90 days, with source links

料金プラン

自分のAPIキーを使うことも可能で、その場合はData Creditsを消費せずActionsのみがかかる。

導入時に見積もるべきは、プランの階層より次の4点だ。

1. 月間のrow数（何件のlead / accountを処理するか）
2. Waterfallの深さ（何providerと何検証ステップを通すか）
3. AI promptの重さ（固定価格で済むか、変動価格が多いか）
4. activationの範囲（CRM、ads、signals、sequencerまで使うか）

主要インテグレーション

“

CRM連携のポイント: ClayはCRMを「置き換える」ツールではなく「強化する」ツールだ。Salesforce/HubSpotにエンリッチされたデータを自動同期し、営業チームが常に最新の情報で活動できるようにする。

成長のタイムライン

Clay公式は自社の伸びを「8-year overnight success」と表現している。初期に長くプロダクトを磨き続けたあと、GTMワークフローに焦点を合わせて一気に拡大した、という要約だ。

総調達額は約$195M以上（1ドル=150円換算で約293億円超）。評価額は2024年3月の$500Mから2025年8月の$3.1Bへ、17ヶ月で6倍以上に上がった。

会社概要としては、本社はニューヨーク、設立は2017年。セキュリティ・コンプライアンス面ではSOC2 Type II、GDPR、CCPA、ISO 27001+、ISO 42001に対応していることが公式サイトで示されている。導入検討時にセキュリティ要件を確認する担当者は、この認証群を出発点にすればよい。

Kareem AminはMcGill大学で電気工学と物理学を学び、Microsoft、Frame、Wall Street Journalを経て2017年にClayを共同創業した。First Round Reviewの公開ストーリーによれば、初期のClayは「営業ツール」より広い構想——魔法のスプレッドシート——として始まり、そこからGTMに焦点を絞ったことでtractionが立ち上がった。

再分類: 事例をコストとOps体制で並べ替える

ここまでの事例をタイムライン順ではなく、動機・コスト構造・Ops体制という別の軸で並べ替えると、Clayが効く条件がはっきりする。

3社に共通するのは、Clayを入れたこと自体ではなく、provider順序を設計し、運用し続けた人がいたことだ。ここから見えるレバーは3つある。

1. provider orchestration: 単一ベンダーでは埋まらないデータの欠損を埋める
2. AI-nativeなワークフロー: researchや分類を同じ表の中で回す
3. community / servicesレイヤー: experts、partners、clubsまで含めて実装知が広がる

裏を返せば、この3つを回す担い手がいないチームでは、同じ倍率の成果は再現されにくいと考えるのが妥当だ。

競合比較: どのレイヤーの問題を解くか

Clayを理解するときは、「どのツールが一番安いか」よりどのレイヤーの問題を解くのかで見る方が正確だ。

競合比較

以下が同時に必要なら、Clayの価値は大きい。

1. 複数のdata providerを組み合わせたい
2. AI research / scoringを表の中で回したい
3. CRM / ads / sequencingまでつなげたい
4. Opsがワークフローを継続改善できる

逆に「営業担当が数人いて、まず連絡先DBとメール送信が欲しい」程度なら、より単純なDB-first / outbound-firstツールの方が早いことも多い。

限界: 設計した分だけコストと運用品質に跳ね返る

Clayの弱点は、2026年のpricing改定後も「失敗検索に課金されるか」ではない。設計したワークフローが、そのままコストと運用品質に跳ね返ることだ。

1. 支出はprovider mixとAI promptの重さに強く依存する。失敗検索には課金されないが、成功したenrichment、検証、AI分析が積み重なれば使用量は当然増える。問題は「不透明な罠」ではなく、設計自由度の高さがそのまま支出のばらつきになることにある。
2. Opsの持ち主がいないと崩れる。Clayは営業個人の便利ツールというより、GTM Opsの作業台だ。誰がワークフローを直し、provider順序を変え、サンプル品質を見て、コストの上限を置くかが曖昧だと、導入効果は出にくい。
3. データ品質はprovider依存。Clay自身は独自データベースを持たない。どのproviderを選ぶか、どこで検証を入れるかで質は変わる。これは弱点であり、柔軟性の裏返しでもある。
4. シンプルな用途には過剰。連絡先DB+メール送信だけで十分なら、Clayは強すぎる。

日本市場への示唆

Clayは日本から使えないツールではない。ただし公開情報を見る限り、プロダクトもドキュメントもエコシステムも英語圏GTMを中心に設計されている。したがって日本チームが見るべき論点は「日本語UIがあるか」より、自社のtarget accountに対して十分なcoverageが出るかである。

国内公開データ層とClayをどう組み合わせるべきかは、実際にwaterfallを回して検証した一次データがまだない以上、ここでは設計上の仮説として提示するにとどめる。手動調査からどこで自動化に切り替えるべきかの見極めも、pilotを通じて検証すべき論点として残る。

国内アカウント中心の営業でEDINET・gBizINFO・顧問ネットワークのような公開データ層をすでに持っているチームには、Clayをその上に載せるworkflow層として位置づける方が現実的だと考えている(詳細は「日本企業のためのGTMエンジニアリング実践」に譲る)。Clayを唯一のsource of truthにするのではなく、次のような役割分担が現実的だ。

国内公開データ / 自社CRM
    ↓
企業サイト・ニュース・人事異動などの追加調査
    ↓
Clayでenrichment / scoring / segmentation / personalized messaging
    ↓
CRM / 広告 / 送信ツールへ連携

日本チームがpilotで確認したい項目は次の4つだ。

1. sample accountでcoverageが出るか
2. 役職 / contact dataの検証を何段入れる必要があるか
3. 英語中心のdocs / supportで運用できるか
4. contact dataの取得・利用フローを社内ポリシーに載せられるか

持ち帰れること

Clayは「データベース」でも「AI copywriter」でもなく、複数のdata source、AI research、activationを1つのワークフローに束ねるレバー（成果を増幅する道具であって、それ自体が競合優位性ではないもの）だと私は考えている。gtm-alpha-explainedで論じた「同じツールを使っても勝てない」というGTM Alphaの議論と重ねると、Clayは成果を増幅する装置ではあっても、競合が真似できない優位性そのものにはならないという整理になる。Anthropicの3倍、OpenAIのcoverage改善は、Clayという箱が魔法のデータを持っているからではなく、複数ベンダーを束ねる設計とOpsの手間をかけた結果だ。だからClayは、成果を作るレバーではあっても、優位性そのものにはならない。

この記事の材料から、私が自分の判断に持ち帰れることは2つある。

1. 評価額やARRの伸びは、自社の導入判断とは無関係の指標だ。$5B valuationも$100M ARRも、自社ICPでcoverageが出るかという問いには何も答えない。
2. 導入前に見るべきは機能一覧ではなく、workflowの担い手の有無だ。誰がprovider順序を決め、コストの上限を置き、運用し続けるかが曖昧なら、Clayを入れても「便利な表」で終わる可能性が高い。

派手な評価額に判断を預けるのではなく、自社のICPでcoverageが実際に出るか、そしてそれを運用し続けるOps ownerが社内にいるか——この2点を、読者自身の判断材料として持ち帰ってもらえたら嬉しい。

関連記事

“

GTM Alphaとは？同じツールを使っても勝てない理由とデータ戦略の作り方

“

日本企業のためのGTMエンジニアリング実践——EDINET・gBizINFO・顧問ネットワークで営業を仕組み化する

“

GTMエンジニアとは？——営業の「仕組み」を作る新職種を徹底解説

参考リソース

• Clay公式サイト / Clay Pricing / Clay FAQ
• Clay About / Clay Blog
• Anthropic customer story / OpenAI customer story
• Clay's Path to Product-Market Fit — First Round Review

本記事はネクサフローのAI研究シリーズの一部です。