ClaudeとTombaでメール探索・検証する前の確認点と課金の落とし穴
Tomba MCP ServerをClaudeにつなぐと、ドメインや氏名からメールアドレスを探し、検証できます。探索結果を営業に使う前に見る、データの出どころ・検証結果の読み方・クレジット消費を順に見ます。
Tomba MCP Serverは、会社のドメインや人物の氏名からメールアドレスを探し、届くかどうかを検証するコネクタです。使い始める前に見ておく点は3つあります。どこから来たアドレスか、検証結果が何を保証するか、1回の呼び出しで何クレジット減るかです。
「valid」と返ってきたアドレスは、メールボックスが存在するという意味に留まります。そのアドレスに営業メールを送ってよいかは、別の問題です。
Tomba MCP Serverは何ができるか
コネクタ紹介ページには、Anthropic verifiedの表示があります。提供元はTomba technology web service LLCで、掲載は2025年11月です。説明は、メールアドレスの探索と検証、連絡先情報の補完、電話番号の探索をTomba.io APIで行うMCPサーバー、というものです。
紹介ページが挙げるツールは11本です。
紹介ページに並ぶ11ツールの系統
メールの探索
domain_search(会社単位)、email_finder(人物単位)、author_finder(記事の著者)、linkedin_finder(LinkedInのプロフィール)検証と補完
email_verifier(届くかの判定)、email_enrichment(アドレスから人物と会社の情報)電話番号
phone_finder(探索)、phone_validator(番号の検証)会社の周辺情報
email_count(ドメインごとの件数)、similar_finder(似た会社)、technology_finder(使用技術)
ツール名ごとの説明文は、紹介ページにありません。挙動を知るには、提供元のドキュメントを引きます。
紹介ページの11本と、提供元の28本
ここに食い違いがあります。提供元のドキュメントでは、リモートMCPサーバーは28ツール、プロンプト12、リソース3を持つと説明されています。ローカル版(@tomba-io/tomba-mcp-server)も同じ28ツールです。紹介ページの11本には、アカウントのデータを書き換えるツールが含まれていません。
28本のうち、データを変更するのは create_lead と create_flag の2本です。ほかのツールには readOnlyHint: true の注釈が付きます。紹介ページの接続先がリモート版かローカル版かの記載はないので、実際に接続したあと、クライアントに表示されるツール一覧で本数と名前を見ます。書き込み系が出てきたら、Claudeに許可を求められた時点で何が変わるのかを読んでから進めます。
接続方式は、リモート版なら https://mcp.tomba.io/mcp にStreamable HTTPで接続します。認証はOAuth 2.0、APIキーをBase64にしたBearerトークン、X-Tomba-Key と X-Tomba-Secret ヘッダーの3通りです。OAuthでは usage_info と get_logs が使えず、この2つにはキーとシークレットが要ります。
探索したアドレスはどこから来るのか
営業に使う前に最も効くのが、この確認です。提供元のデータ説明によると、Tombaの連絡先は大きく2つの経路で生まれます。
- 公開ウェブページから収集したもの: 企業サイト、公開されたプロフィール、記事、プレスリリース、公開ディレクトリ、求人などが元です。見つけたページは
sourcesとして返ります - 生成されたもの: Tombaが人物のアドレスを持っていないとき、
email_finderはそのドメインでよく使われる形式から候補を作り、メールサーバーで確認して、最も確からしいものを検証状態つきで返します
2つ目が肝心です。email_finder が返したアドレスは、本人がどこかで公開したものとは限りません。形式から組み立てて、サーバーで確認が通ったものである場合があります。同じ氏名とドメインの組み合わせで候補が全滅すると、Tombaは30日間その組み合わせを再検索しません。
見分ける材料は sources です。各エントリは、アドレスが載っているページのURL、最初に見つけた日(extracted_on)、最後に見た日(last_seen_on)、いまもそのページにあるか(still_on_page)を持ちます。1アドレスにつき最大20件です。
ただし、公開ページの根拠がないアドレスにも sources が付くことがあります。
sources の中身 | 意味 |
|---|---|
| 企業サイトなどの実在ページ | 意味その公開ページにアドレスが載っていた |
tomba.io のアドレスページ | 意味公開ページはなく、検証で有効と判定された |
google.com の検索リンク | 意味LinkedInのプロフィールと照合された |
後ろの2つは、本人が公開した証拠にはなりません。email_verifier の結果でも、有効なアドレスに公開ページがないときは、Tombaのアドレスページを指すエントリが1件入ります。Claudeに結果を整理させるときは、uri が実在ページか、それとも tomba.io や google.com かを区別して出させます。
Claudeへの依頼文に入れておく
探索結果の表を作らせるとき、出どころの列を必須にしておくと、あとで見直せます。次は依頼文の一例です。
example.co.jp のマーケティング部門の担当者を domain_search で探してください。
結果は表にして、各アドレスについて次の列を必ず付けてください。
- verification.status
- sources の uri(tomba.io と google.com は「公開根拠なし」と書く)
- last_seen_on と still_on_page
sources が空のアドレスは、別の表に分けてください。出力はツールが返したJSONの転記になるので、列の値が空ならそのまま空と書かせます。値をClaudeに推測で埋めさせない指定を添えておきます。
検証結果は何を保証するか
email_verifier は status と result の2段で結果を返します。
status | result | 意味 |
|---|---|---|
| valid | resultdeliverable | 意味メールボックスが存在し、メールを受け取る |
| accept_all | resultrisky | 意味サーバーがどのアドレス宛でも受け取るため、個別のボックスは確認できない |
| invalid | resultundeliverable | 意味メールボックスが存在しない |
| unknown | resultrisky | 意味サーバーが検査を拒否した、または応答がなく、判定できない |
| disposable | result空 | 意味使い捨てメールのドメイン。email と result も空文字列 |
読むときの注意が4つあります。
validは「届く」であり、「送ってよい」ではない。配信可能性の判定だけです。送信の根拠となる同意や取引関係は、この値のどこにも含まれませんaccept_allを「ほぼ届く」と読まない。キャッチオールのドメインでは、存在しない人物宛でも受け付けるため、ボックスの存在が確認できませんstatusは大文字小文字を区別せずに比較する。レスポンスによってValidと返る場合がありますsmtp_checkはボックスの有無を示さない。ドメインにMXレコードがあるときにtrueになる項目で、mx_checkと同じ値です。判定にはstatusを使います
gibberish(@の前がランダム生成に見える)、disposable、webmail といった真偽値も返ります。ドメイン検索は、無料メール(GmailやOutlookなど)や使い捨てドメインに対してはアドレスを返しません。
検索で返る一覧には、直近の確認で無効だったものや、確認できなかったものも混ざります。有効なものだけが欲しいときは、verification.status で絞るよう依頼文に書きます。
呼び出すたびにクレジットが減る
Tombaの探索系ツールは、1回の呼び出しがAPIの1リクエストになり、クレジットを消費します。Claudeが一度の依頼で何回も呼ぶ前に、費用の見当をつけておきます。
新しいアカウントは無料プランで、検索クレジットは使用期間ごとに25です。有料プランは、検索クレジットと検証クレジットが同数で、Basicが各2,500、Growthが各5,000、Proが各20,000、Pro Plusが各50,000です。ほかに、メール件数用とソース用の残高が別にあります。
主なツールの消費は次のとおりです。
| ツール(エンドポイント) | 消費 | 課金される条件 |
|---|---|---|
domain_search | 消費limit 10件ごとに検索1(既定の10件で1)。電話番号つきは返ったアドレス1件ごとに5を加算 | 課金される条件1件以上アドレスが返った |
email_finder | 消費検索1、電話番号つきは6 | 課金される条件検証状態が unknown 以外のアドレスが返った |
email_verifier | 消費検証1。電話番号つきは返った番号1つにつき5を加算 | 課金される条件disposable と unknown 以外 |
phone_finder | 消費検索5、domain を付けた場合は1 | 課金される条件有効な番号が返った |
email_count | 消費メール件数1 | 課金される条件呼ぶたび |
technology_finder | 消費課金なし(検索残高が正であることは必要) | 課金される条件— |
成功しなかった呼び出し、429、451は課金されません。クレジットが足りないときは、処理の前に 402 quota_exceeded で失敗します。
ここで落とし穴になるのは、電話番号の追加取得です。enrich_mobile はAPI側では電話番号を同じレスポンスで返すオプションで、検索1のところが6になります。依頼文に「電話番号も」と書き足しただけで、アドレス1件あたりの消費が6倍になります。domain_search で limit を50にして電話番号つきにすると、検索5と、返ったアドレスごとの5が重なります。
もう1点。MCPのスキーマ上は domain_search にも enrich_mobile の引数がありますが、提供元の説明では「受け付けるがAPIには渡されず、効果はない」とされています。ローカル版(1.2.0)の enrichMobile も同様です。ツールの引数一覧にあることと、実際に効くことは別なので、課金の見積もりはエンドポイントの課金表で行います。
件数を決めてから呼ぶ
探索の範囲を先に決める依頼文にしておくと、予期しない消費を避けられます。
まず email_count で example.co.jp のアドレス件数だけを確認してください。
件数を報告したら、いったん止まってください。
domain_search は、私が件数を見て指示してから、limit を 10 にして呼びます。
電話番号は取得しないでください。email_count はメール件数用の別残高から1減ります。検索用の残高を使わずに、見込み件数を先に知る方法として使えます。
検索結果を使う前に残る確認
Tombaは、探索した相手から見て「どこから自分のアドレスを知ったのか」に答えられるように、取得元を返す作りです。同時に、個人のメールアドレス、自宅住所、個人の電話番号、ログインや有料の壁の内側にあるデータは収集しないと説明しています。
削除の窓口もあります。本人は、Claimツールまたは privacy@tomba.io への連絡で、アドレス、電話番号、LinkedInプロフィールを削除できます。削除された項目はAPIが返さなくなり、名指しでリクエストすると451が返ります。451は、本人が処理の停止を求めたことを示す応答で、ドキュメントは「自分で処理しないこと」と書いています。削除は、削除依頼より前に顧客がエクスポートしたコピーには及びません。
また、APIの利用規約は、保存した連絡先データを少なくとも12か月ごとに更新または消去するよう求めています。Claudeに探索結果をスプレッドシートやCRMへ書き出させると、そのコピーは更新の対象になります。
ここまでが、ツール側の事実です。日本で営業メールを送るかどうかは、次の2つの確認が別に要ります。
- 見つけた個人の連絡先を、Claudeに渡して扱う段階の個人情報保護法の論点は、ClaudeとLushaを連携して連絡先を調べる前の確認点で条文単位に整理しています。Tombaの連絡先にも同じ論点が当てはまります
- 送信先が特定電子メール法のどの類型に当たるか、同意の記録をどう持つかは、特定電子メール法の同意を営業メールの送信前にClaudeで点検するに手順があります
Tombaの valid と sources は、これらの判断を置き換えません。sources に公開ページが載っていれば、公表されたアドレスかを見る材料にはなりますが、結論を出すのは送信側です。
送信前に見る3つの問い
探索したアドレスを営業に回すまでの切り分け
- Qsources に、企業サイトなど実在する公開ページがあるか?答えがない答えがはい
生成や照合の結果にとどまるので、営業リストに入れる前に、別の根拠(名刺、問い合わせ、取引関係)を探します。
- Qstatus が valid で、result が deliverable か?答えがそうではない答えがはい
accept_allやunknownは判定できていません。無効や使い捨ては除外します。 - Qlast_seen_on が新しく、still_on_page が true か?答えが古い、または false答えがはい
すでにページから消えたアドレスは、本人が公開をやめた可能性があります。
送信根拠の確認へ進める
ここまで通ったものだけを、特定電子メール法の4類型と社内の個人情報の扱いに当てはめます。
通らないアドレスが出たときの扱いも、あらかじめ決めておきます。誤りが見つかったアドレスは、create_flag で報告できます。ハードバウンスしたアドレスなど、Tombaが確認した報告には、クレジットが戻る仕組みがあります。ただし create_flag はデータを書き換える側のツールです。Claudeに実行を任せず、報告内容を読んでから承認します。
運用に落とす
チームで使うときは、判断を人に残す設計にします。プロジェクトの指示欄(Claude Codeで使うならCLAUDE.md)に、次のような規約を置けます。自社の法務の判断に置き換えて使います。
## Tomba の扱い
- 探索結果は、sources の uri が実在ページか tomba.io / google.com かを必ず分けて示す
- status が valid 以外のアドレスは「送信候補」に入れない
- enrich_mobile や phone_finder は、私が明示したときだけ使う
- create_lead / create_flag は実行前に、書き込む内容を表で示す
- 探索結果をファイルに書き出すときは、取得日の列を付ける営業支援のコネクタごとの違いは、ClaudeとZoomInfoの連携で見られます。メールの送信側を整える作業なら、Claude CodeでMailtrap MCPを使い、メール送信とテンプレートを管理するが、配信テストの側を扱っています。