第7章 運用：コスト・品質・ガバナンス
7-1 データクレジットとアクション：2つの単位でコストを見積もる
ClayClay企業やパーソンについて外にある情報を集め、AIで判断し、文面を作り、MA・SFAに書き戻す、営業・マーケティング向けのデータ処理ツール。画面は表計算ソフトに似ており、1行が1社または1人、1列が1つの問いに対応する。米国のClay Labs社が提供する。用語集で見る →の利用料は、月額のプラン料金の中に、2種類の単位が含まれる形になっている。データクレジットデータクレジット／アクションClayの利用料に含まれる2種類の単位。データクレジットは外部のデータベンダーから情報を取得するたびに、アクションは列の実行・条件分岐・他システムへの書き込みなど、Clayの中で処理を1つ動かすたびに消費する。2つは別々に減り、どちらかが先に尽きる。用語集で見る →（Data Credits）とアクション（Actions）である。2026年3月の料金改定で、それまで1つだった単位が2つに分かれた。見積もりの前に、この2つの違いを押さえておく。
データクレジットは、外部のデータベンダーデータベンダー企業・パーソンの属性情報（業種、規模、所在地、法人番号、役職、連絡先など）を持ち、提供する事業者。得意な地域・業種・企業規模がそれぞれ異なる。Clayは情報そのものを持たず、複数のベンダーから取り出して組み合わせる。用語集で見る →から情報を買うときに消費する。企業の属性、パーソンの連絡先、技術情報など、ウォーターフォールウォーターフォールWaterfall1つの問いに対して、複数のデータベンダーを順番に当てるデータ取得の方式。最初のベンダーで答えが見つかればそこで止まり、見つからなければ次へ進む。単一のベンダーより取得率が上がり、見つかった時点で止まるため後続のベンダーの利用料もかからない。用語集で見る →の各ベンダーが返した分だけ減る。消費量はベンダーごとに異なり、Clayの画面上で列ごとに表示される。ベンダーに払う対価をClayが取りまとめている、と考えると分かりやすい。
アクションは、Clayの中で処理を1つ実行するたびに消費する。列の実行、条件分岐、他のテーブルへの参照、MAMAマーケティングオートメーションマーケティングの実行と管理のための業務アプリケーション。用語集で見る →・SFASFAセールスフォースオートメーション営業の実行と管理のための業務アプリケーション。用語集で見る →への書き込み、Webhookの送信、ワークフローの各ステップ。データを買わない処理でも、動かせばアクションを使う。Clayのモデルで動かすClaygentClaygentクレイジェントClayの機能の一つで、利用者が書いたプロンプト（自然文の指示）に対して、Webサイトを読んで答えを返すAIエージェント。データベンダーには載っていない「この企業が今何に取り組んでいるか」を企業ごとに調べ、根拠となるURLも返す。用語集で見る →の調査と文面生成は、アクションとデータクレジットの両方を消費する。自社のAPIキーで動かす場合はアクションのみ消費する（第3章3-4）。アクションはClay自体の処理に払う対価であり、月ごとに上限がリセットされ、繰り越しはない。データクレジットは、セルフサーブのプランでは月間割当の2倍を上限に翌月へ繰り越せる。エンタープライズ契約では契約条件による。
2つの単位は別々に減り、どちらかが先に尽きる。データを多く買う使い方（属性の補完、パーソン探索が中心）ではデータクレジットが先に尽き、処理の多い使い方（条件分岐が多い、Claygentの列が多い、書き戻しが頻繁）ではアクションが先に尽きる。本書で扱うシグナルシグナル顧客企業に起きた変化を示す情報。経営方針・組織・キーパーソン・採用・投資と業績・事業・導入ツールと体制・外部環境の変化があり、多くは公開されている情報から得られる。用語集で見る →検知と文面生成の用途は後者に寄るため、アクションの消費を見ておく必要がある。
見積もりの式は、単位ごとに同じ形になる。
月あたりの消費 ＝ 列ごとに「1行あたり消費量 かける 実行する行数 かける 月の実行回数」を求め、全列で合計する
これをデータクレジットとアクションの両方で計算する。決めるべき変数は4つある。
- 対象社数とパーソン数：企業500社、1社あたり対象パーソン3人なら、パーソンの列は1,500行
- 列の種類と数：属性の補完（データクレジットが主）、パーソン探索（両方）、Claygentの調査（両方。アクションの比重が大きい）、条件分岐と書き戻し（アクションのみ）
- 実行条件で絞られる行数：第3章で述べたとおり、条件を満たす行にだけ次の列を実行する。属性の補完は全行、シグナル調査は条件に合った200社、文面生成はシグナルが出た50社、というように、列が進むほど行数は減る
- 実行の頻度：属性の補完は初回と四半期ごと、シグナルの調査は週次、文面生成はシグナルが出たとき
この4つを並べると、消費の大半がどの列で起きるかが分かる。多くの場合、全行に対して毎週実行するシグナル調査が、アクションとデータクレジットの両方で最も大きい。ここを抑えるには、調査の対象を重要度の高い企業に絞る、頻度を月次に落とす、複数の問いを1つのClaygentの列にまとめる（列の数がそのままアクションの数になる）、といった方法がある。
もう1つ、消費を抑える方法がある。第3章3-4で述べたとおり、自社で契約しているAIのAPIキーをClayに登録すれば、Webリサーチと文面生成のAI利用料は自社の契約側で払い、Clay側のデータクレジットは消費しない。アクションは消費する。対象社数が多く、Webリサーチの列が多い運用では、この差は大きい。
初月は見積もりの半分の対象社数で始め、実際の消費を見てから対象を広げる。Clayの管理画面で両方の消費は列ごとに確認できるため、見積もりと実績の差はすぐに分かる。プランの選択は、データクレジットとアクションのどちらが先に尽きるかを見てから決める。
7-2 精度の検証：Claygentの回答を疑って読む
Claygentは、Webを読んで答えを返す。便利だが、間違える。古い情報を取ってくる、別の会社の情報を取ってくる、根拠が薄いのに断定する、見つからないときに答えを作る。この4つが典型的な誤りである。
精度の検証は、本番の対象に流す前と、運用に入ってからの2回行う。
運用前の検証
対象企業から30〜50社を抜き出し、Claygentの回答と根拠URLを人が全件読む。誤りを4つの型に分類し、どの型が多いかを見る。古い情報が多ければ期間の指定を強くする。別の会社を取ってくるなら、企業の特定（ドメインの確定）を先に済ませる。断定が多ければ「根拠が1つしかない場合は『要確認』と答えよ」と指示を足す。答えを作るなら「見つからなければ『不明』」を明記する。問いを直して再実行し、誤りが1割を下回ったら本番に進む。
運用中の検証
週次で、新しく出たシグナルから10件程度を抜き出し、根拠URLを開いて事実を確かめる。誤検知があれば、その型を記録し、月に1回まとめて問いを見直す。営業・インサイドセールスインサイドセールス訪問せずに電話やメールで見込み客と接点を持つ営業機能。聞き取りで得た情報は、フォームからは分からない購買グループの手がかりになる。用語集で見る →から「このシグナルは違った」という報告が来る経路（SFAの項目に「誤検知」のチェックを置く、Slackに報告先を作る）を用意し、報告を検証の対象に加える。
検証で確かめるのは、Claygentの回答が「正しいか」だけでなく、「自社の対応表対応表自社の商材にとって、どのシグナルが、どの課題を示し、何を提案できるかを定めた表。シグナル（事実）をWhy You Nowの3要素（課題・ニーズ、タイミング、提案できる要素）に置き換えるルールであり、業種や商材で答えが変わるため自社ごとに作る。Clayの判定と文面生成はこれに従って動かす。用語集で見る →の定義に合っているか」である。「新拠点の開設」を取りたいのに、既存拠点の移転を検知している場合、Claygentは事実として正しいが、シグナルとしては誤りになる。この種の食い違いは、問いの文言より、第6章6-2で決めたシグナルの定義を直すことで解消する。
7-3 人が確認する箇所：自動で流さない場所を決める
Clayは、調査から文面生成までを自動で行える。しかし、全部を自動で流すと、誤りがそのまま相手に届く。どこで人が見るかを、運用の設計として決める。
第5章の各ユースケースで「人が確認する箇所」を示した。運用でまとめると、確認が必要な場所は3つに分かれる。
送信前の確認
1to1メール（5-10）、お手紙（5-11）など、相手に直接届く文面は、送信前に人が読む。確認するのは、事実の誤り（存在しない発表への言及）、相手の名前・役職の誤り、自社の商材の説明の誤りである。最初は全件を確認し、修正率が下がったら（目安として修正が2割を切ったら）、サンプリングに切り替える。修正した内容は記録し、文面生成の指示に反映する。
シグナルの真偽確認
通知を受けた担当者が、動く前に根拠URLを開く。これは担当者の手順として決めておく。根拠を確認せずに「御社の新工場について」と電話をかけ、事実が違っていた場合、取り返しがつかない。
判定の確認
事業部アサイン（5-12）のように、判定結果が社内の担当割りを変える場合、複数の事業部に該当した案件は自動で割り当てず、マーケティング部門が判断する。ターゲットリスト作成（5-2）のスコア上位も、最初の数回は人が一覧を見て、計算が意図どおりかを確かめる。
人の確認は、運用の負荷になる。負荷を減らすには、確認の対象を「相手に届くもの」と「社内の割り当てを変えるもの」に限定し、SFAへの書き戻しや通知のような社内で完結する処理は自動で流す。確認の記録（何を直したか）は、7-2の精度検証と7-5の改善サイクルの入力になる。
7-4 個人情報と利用規約
Clayで扱う情報には、企業情報とパーソンの情報が混在する。パーソンの情報は個人情報であり、取得・保持・利用のそれぞれで守るべきことがある。
取得して良い情報
Clayのデータベンダーが提供するパーソンの情報は、ベンダーが各国の法令に従って収集したものである。しかし、日本国内で利用する場合は、個人情報保護法に基づき、自社が取得する個人情報として扱う必要がある。取得の目的（営業活動のための連絡先の把握）を自社のプライバシーポリシーに明記し、取得した情報はその目的の範囲で使う。
Webリサーチで取る情報
Claygentが公開情報から取るパーソンの情報（役員一覧、インタビュー記事の発言）は、公開されているが、収集して保持すれば個人情報の取得になる。業務上の役職と公表された発言に限り、私的な情報は取らない。問いの中で「個人の私生活に関する情報は取得しない」と指示する。
保持期間と削除
Clayのテーブルに残る中間データには、対象外になった企業のパーソン情報も含まれる。対象外になった行は定期的に削除し、Clayに個人情報を長期間保持しない。これは第6章6-1の「Clayにデータを残さない」と同じ方針である。MA・SFAに書き戻した情報は、MA・SFA側の保持ルールに従う。
同意と配信
メールの送信は、特定電子メール法の規制を受ける。取得したメールアドレスに対して、同意なく広告・宣伝のメールを送ることはできない。1to1メールであっても例外ではない。既に取引や問い合わせの関係がある相手か、名刺交換などで通知した相手に限る、送信者の表示と受信拒否の方法を明記する、といった運用を守る。新規の相手には、メールより手紙（5-11）や、電話での最初の接触を選ぶ理由はここにもある。
データベンダーの利用規約
各ベンダーには、取得した情報の再配布や保持に関する規約がある。Clayを通じて取得した情報を、別のシステムに大量に書き出して保持することを制限しているベンダーもある。MA・SFAへの書き戻しがその範囲に収まるかは、導入時に確認する。
この節は法的助言ではない。自社の法務部門と確認したうえで運用を決める。
7-5 目標と改善サイクル
Clayを使うと、リストの件数は簡単に増やせる。しかし件数を目標にすると、件数を増やすための運用になり、質が下がる。目標は、シグナルを検知したあとに相手との関係がどれだけ進んだかで置く。
見る数値
シグナルを検知した企業のうち、接触できた割合（接触率）。接触した企業のうち、面談に至った割合（面談化率）。面談した企業のうち、商談になった割合（商談化商談化リードが営業の対応する案件になること。ここで購買グループの関心・懸念が一人分に縮むと、以降の設計が効かなくなる。用語集で見る →率）。この3つを、シグナルの種類ごと、文面の型ごとに見る。
比較で見る
初期の目標は比較で置く。従来の架電リストからの面談化率と、シグナル起点の面談化率を同じ期間で比べる。シグナルの種類Aと種類Bで、どちらの返信率が高いか比べる。この比較が、何を増やし何をやめるかの判断になる。
時間の使い方を見る
もう1つ見るべきは、営業・インサイドセールスの時間の使い方の変化である。架電前の調査に使っていた時間、文面を書いていた時間が、どれだけ減ったか。減った時間が面談と提案に使われているかを、月次で確認する。この変化は第8章で述べる効果の測り方になる。
改善の順番
数値が出たら、見直す順番は、①シグナルの定義（取るべきシグナルを取れているか。誤検知が多い種類は定義を直すか外す）、②対応表（シグナルからBecause3要素への変換が合っているか。返信率の低い型は提案できる要素の読みを直す）、③文面（構成と表現）、④対象の範囲（重要度の判定基準を広げるか絞るか）。文面から直し始めると、定義が間違っているのに文面だけが直され続ける。
この改善は、当社のGTMGTMGo-To-Market製品・サービスを市場に届けて収益化するまでの一連の設計。日本語圏では Google Tag Manager と略称が重なるため、文脈に注意が要る。用語集で見る →の7工程の「07 運用・改善」にあたる。月次で数値を見て、四半期でシグナルの定義と対応表を見直す。Clayのテーブルは、見直しのたびに列を足し、消し、作り直してよい。第2章で述べた試行の進め方は、運用に入ってからも続く。
次章では、この仕組みが営業とマーケティングの動き方をどう変えるかを扱う。
