フォーム営業の与信情報活用｜送信先の質を高める4層データ設計

「送信件数を伸ばしたいのに、送ってはいけない相手に送ってしまい、自社の名前を毀損する」。フォーム営業を内製化して数ヶ月経ったチームの多くが、この壁にぶつかります。業種・エリアで絞り込んでも、同じ業種のなかには財務が健全な企業と、解散・清算予定の企業が同居しており、リストの見た目だけでは判別できません。

とりわけ厄介なのは、「反応があった案件を営業が追いかけた結果、着手金の入金が遅れる」タイプの失敗です。フォーム営業の入口段階では、企業規模や業種は絞れても、支払能力までは見えていません。反応率という単一の KPI で走ると、成約後のトラブルが後追いで発生します。

上長からの「与信を絡めて送信先を絞れ」という指示は的確ですが、実務に落とし込もうとすると別の壁に当たります。帝国データバンクや東京商工リサーチに 1 件ずつ照会すると 1 件数千円単位のコストが発生し、営業リスト全件に適用するのは現実的ではありません。かといって業種・エリアだけの絞り込みに戻ると、冒頭の問題が再燃します。

本記事では、フォーム営業における与信情報活用を「無料一次データ → 無料補足データ → 商用データベース → 有償与信精査」の 4 層構造で設計する方法を解説します。全件を有償情報で精査するのではなく、無料ソースで大半をスクリーニングし、絞り込んだ上位候補だけに有償情報を投入する段階運用が現実解です。あわせて、稟議・社内合意で使える判定閾値の設計例と、送信除外リスト・リードスコアリング・SFA との接続点までを扱います。

想定読者は、フォーム営業を内製化して送信数の拡張フェーズに入った、従業員 30〜150 名規模のインサイドセールス責任者・マーケティング責任者です。読み終えた時点で、「無料ソースでここまで、有償はこの部分だけ」という運用イメージを描き、上長への稟議に添付できる判定観点を整理できる状態を目指します。

フォーム営業に与信情報を持ち込む理由

送信件数を月数千件規模まで伸ばした段階のチームには、必ずと言ってよいほど 2 種類のインシデントが発生します。上流フィルタとしての「フォーム営業 与信情報 活用」を検討する動機は、この 2 種類のリスクを送信前に減らすことにあります。

送信数最大化フェーズの次に発生する 2 つのインシデント

1 つ目は、レピュテーション毀損型のインシデントです。解散手続き中の企業、破綻直前の企業、実質的に活動を停止した休眠企業に対して営業メッセージを送信し、その事実がクレーム・SNS 投稿・業界内での共有を通じて自社に返ってくるパターンです。フォーム営業は「自社の名前で送る」チャネルであり、代行会社を挟んでいてもクレームは発注元の企業名で届きます。

2 つ目は、回収不能型のインシデントです。反応があった案件を営業が追いかけ、契約書を締結したものの、着手金の入金が遅れる・分割支払いを希望される・請求書送付後に音信不通になる、といった事象です。反応率が高い案件は必ずしも支払能力が高い案件ではありません。むしろ、資金繰りに窮している企業ほど「藁にもすがる」姿勢で反応率が上がるケースが観察されます。

どちらのインシデントも、送信「後」に発生する事象を営業側で吸収する構造になっており、負荷が営業と経理に集中します。上流のリスト段階で除外できていれば発生しなかった、というのが両者に共通する構造です。

業種・エリア絞り込みでは防げない理由

営業リストを業種・エリアで絞り込むアプローチは古典的で機能する部分もありますが、財務健全性は業種内で大きく分散します。同じ「Web 制作会社」「システム受託開発会社」というタグの下に、成長中の企業も債務超過寸前の企業も同居します。エリア軸も同様で、都心の一等地に登記があっても実体はバーチャルオフィスというケースは珍しくありません。

つまり、業種・エリアは「対象顧客層に合っているか」を判定する軸として有効ですが、「送っても大丈夫な相手か」を判定する軸としては解像度が足りません。この解像度を補うのが与信情報です。

上流フィルタとしての「与信情報」の位置づけ

ここで扱う「与信情報」は、狭義の TDB / TSR 評点だけを指しません。企業の実在性・活動継続性・財務規模・取引実績を推測できる材料の総称として使います。設立年月日、資本金、従業員数、法人格・所在地の整合性、行政との取引実績、補助金採択、そして最上位に位置する有償与信評点までを含みます。

これらは反応後のリードスコアリングとは目的が異なります。リードスコアリングは「反応した相手のうち、どの案件に営業リソースを厚く割くか」を判定するもので、送信より下流の工程です。上流の与信情報フィルタは「そもそも送るかどうか」を判定する工程で、両者は補完関係にあります。関連する下流の設計は、リードスコアリング設計にまとめています。

フォーム営業で使う「営業リスト 与信」データの全体像

与信情報を全件・有償ソースで精査するのは非現実的です。代わりに、コスト・網羅性・粒度の異なる複数のデータソースを組み合わせ、段階的にフィルタする設計が現実解になります。ここでは、実務で参照される主要な企業データを 4 層に整理します。

4 層構造（無料一次データ／無料補足データ／商用データベース／有償与信精査）

各層は下に行くほど 1 件あたりのコストが高く、代わりに得られる情報の粒度が細かくなります。「営業リスト 与信」という切り口で全件を精査しようとすると 4 層目のコストが跳ね上がるため、1〜3 層で対象を絞り込んでから 4 層に投入するのが基本設計になります。

4 層を通す「送信可否判定パイプライン」の設計イメージ

段階運用の流れをパイプラインとして整理すると、次のようになります。

1. 法人番号公表サイトから対象業種・エリアの法人リストを取得し、法人番号をキーとする一次マスタを作る
2. gBizINFO の API または CSV で資本金・従業員数・許認可などを付与し、活動継続性の一次スクリーニングを行う
3. 商用データベースで業種・キーマン・売上規模を補強し、送信対象を「送信候補」として確定する
4. 想定商談金額が大きい案件・反応があった案件など、上位クラスターのみ有償与信精査に回す

このパイプラインが機能すると、全件を有償で照会する必要がなくなり、コストと精度のバランスが取れます。1〜3 層は事前バッチ処理として組み、4 層は反応後・受注前の局所処理として組む、というのが現実的な運用形態です。

無料で使える一次情報（法人番号公表サイト・gBizINFO の実務活用）

有償ソースに課金する前に、無料の一次情報でどこまでスクリーニングできるかを把握しておくと、稟議・予算計画の精度が上がります。ここでは国税庁の法人番号公表サイトと経済産業省の gBizINFO を実務でどう使うかを整理します。

「法人番号 営業リスト」の起点は法人番号公表サイト

国税庁の法人番号公表サイトは、日本国内の全法人について、商号・所在地・法人番号・変更履歴を公開しています。CSV での一括ダウンロードにも対応しており、月次で差分ファイル（新規登記・所在地変更・清算等）が提供されます（法人番号公表サイト・ダウンロード仕様）。

営業リスト運用の起点として活用する場合、次の 3 つの効果があります。

• 営業リスト内の「実在確認」ができる。登記が確認できない、または「清算結了」記録がある企業を送信対象から除外できます
• 「法人番号」を営業リスト・SFA・与信情報の共通キーとして採用できる。商号は表記揺れが発生しやすい（株式会社 vs （株）、旧商号 vs 新商号）ため、法人番号を主キーに置くとデータ結合が安定します
• 所在地変更・商号変更などの差分イベントをトリガに、リストの鮮度を保てる

法人番号は 13 桁の一意な番号で、法人設立時に付与されます。「営業リスト 与信」の運用を長期化するのであれば、まずはこの法人番号を全レコードに付与する仕組みを作ることが第一歩になります。

「gBizINFO 営業 活用」で得られる項目と紐付け方

経済産業省のgBizINFOは、法人番号を主キーとした行政保有の企業情報を、Web UI と API で提供しています。営業リスト観点で有用な項目は次のとおりです。

• 基本情報: 商号・所在地・法人番号・法人格
• 規模情報: 資本金・従業員数（届出値・公表値ベース）
• 活動実績: 補助金採択、公共調達（入札）実績、特許出願、経営革新等の認定
• 許認可: 建設業許可・一般労働者派遣事業許可などの業許可

「gBizINFO 営業 活用」の観点で特に有効なのは、資本金・従業員数と、補助金・入札・認定の「活動継続性シグナル」を組み合わせる使い方です。休眠に近い企業は、資本金・従業員数の登録値が更新されていない、あるいは活動実績がまったく記録されていない傾向があります（もちろん例外はあるため、あくまで一次スクリーニングとしての用途です）。

API は事前申請制で、認証キーの発行後に利用できます（gBizINFO API 概要）。バッチで営業リスト全件に付与するのは無料の範囲で実行可能なため、コストゼロで実現できる「与信情報」の一次データとして最有力です。

無料ソースだけで作れる「一次スクリーニング」の判定例

法人番号公表サイトと gBizINFO の情報だけでも、次のような一次スクリーニングを設計できます。

• 法人番号が取得できない登記情報の欠落レコードは、リストから除外する
• 資本金が極端に小さい（例: 100 万円未満）レコードは、慎重送信区分に分類する
• 設立から一定年数（例: 3 年）未満で、gBizINFO 上の活動実績がゼロのレコードは、慎重送信区分に分類する
• 商号・所在地の変更履歴が過去 1 年に集中しているレコードは、精査対象としてフラグを立てる

これらは「絶対に送らない」ラインではなく、「送信前にもう 1 段階チェックを挟む」ラインとして設計します。上長への稟議では、この一次スクリーニングだけで営業リストの何割が除外／慎重送信区分に分類されるかを事前計測しておくと、有償ソースの投入判断がしやすくなります。

有償与信情報（帝国データバンク・東京商工リサーチ）の使いどころ

無料ソースで一次スクリーニングを終えた後、有償ソースに何を任せるかを設計します。全件課金を避け、部分適用で費用対効果を出す発想が中心です。

「帝国データバンク 営業」観点での評点の読み方

帝国データバンク（以下、TDB）は、企業の与信調査を業として営む代表的な信用調査会社です。TDB の企業概要ファイルには「評点」と呼ばれる 100 点満点のスコアが付与されており、業歴・資本構成・規模・損益・資金現況の定量 5 項目と、経営者・企業活力の定性 2 項目、合計 7 項目を総合評価した数値です（帝国データバンク・企業評価）。

営業アプローチの判断に翻訳する場合、評点そのものを閾値として使うよりは、「一次スクリーニングを通過した候補のうち、想定商談金額が大きい上位クラスターだけを TDB で精査する」という部分適用のほうが実務に馴染みます。営業リスト全件を TDB 評点で足切りしようとすると、コストが跳ね上がるためです。

全件課金せずに済ませる「精査対象の絞り込み方」

TDB / TSR の全件課金を回避しつつ、必要な場面で使うためのフレームとして、「見込み金額 × 与信リスク」のマトリクスが実用的です。

このマトリクスに沿うと、有償精査を「送信前」に投入するのは左下（大金額・高リスク）の局所ケースのみに絞れます。それ以外は反応後の受注前段階で精査すれば十分で、フォーム営業リスト全件への課金は発生しません。

「東京商工リサーチ 営業リスト」観点での TDB との使い分けと G-Search 経由の横断検索

東京商工リサーチ（以下、TSR）は TDB と並ぶ代表的な信用調査会社で、TSR 評点は 100 点満点で経営者・成長性・安定性・公開性の各項目を評価するスコアです（東京商工リサーチ・企業情報）。TDB との比較では、TSR のほうが数値評点・財務データの重み付けが高く、TDB は定性コメント（経営者評、業界動向、取材メモ）に厚みがある、というのが実務での使い分け観点です。

両社の情報を横断的に検索したい場合、G-Search（大宅壮一文庫データベースサービス）の企業情報検索を経由すると、TDB・TSR の企業概要ファイルを 1 件単位で購入できます（G-Search 企業情報検索）。年間契約なしで小口購入できるため、まず数十社だけ精査してみる、という導入検証には有効です。

「東京商工リサーチ 営業リスト」という切り口で TSR の企業データそのものを購入する形式もありますが、これは営業リスト全件購入に近い運用となり、フォーム営業の上流フィルタとしては過剰投資になりがちです。前節のマトリクスで「送信前に精査すべき局所ケース」に絞って G-Search 経由の 1 件購入から始める運用が、実務的な入口として現実的です。

与信情報を「送信可否判定」に翻訳する判定ルール設計

与信情報を単なる参照値で終わらせず、送信可否の分岐条件に落とし込む設計を扱います。フォーム営業ツールに実装できる粒度で判定ルールを言語化し、稟議・社内合意で使える形にするのがゴールです。より上位の判定フレームは送信可否判定の AI ロジックにまとめています。

「与信スコア 送信除外」に使う 5 指標と閾値例

判定に使う主要な 5 指標と閾値例を整理します。閾値は業種・商材・想定単価により調整が必要な相対値であり、以下はあくまで叩き台として提示します。

「与信スコア 送信除外」という運用は、5 指標をそれぞれ独立に評価し、除外／慎重送信／通常送信の 3 段階ラベリングに集約する形が最もシンプルです。稟議の説明もしやすく、上長からの「なぜこの企業は送らなかったのか」という質問に対して指標単位で答えられます。

「除外／慎重送信／通常送信」3 段階ラベリング運用

3 段階ラベリングは、以下のように運用します。

• 除外: 送信対象から完全に外す。送信除外リストに追加し、以後のバッチでも自動除外する。判定根拠を必ず記録する
• 慎重送信: 送信するが、送信文面を汎用テンプレートではなく、リスク回避型（前払い前提・小規模案件推奨など）に切り替える。または、有償精査を経てから送信する
• 通常送信: 標準の送信フローに乗せる

3 段階運用の利点は、白黒の 2 段階（送る／送らない）に比べて、営業チームと経理チームの認識合わせがしやすい点です。「慎重送信」ラベルがあることで、反応があった際の営業側の初動（見積提示前に信用調査を回すか否か）が事前に決まります。除外判定のうち送信禁止対象は、そのまま送信除外リストへ流し込みます。除外リストの運用は送信除外リスト設計ガイドにまとめています。

判定ルールを稟議・社内合意に載せるチェックリスト

判定ルールは、作った瞬間から陳腐化が始まります。稟議・社内合意の段階で、以下のチェックリストを添えておくと運用が続きます。

• 各指標の閾値を承認する責任者は誰か（営業責任者 / 経理責任者 / CEO）
• 閾値の見直しサイクルはいつか（四半期／半期／年次）
• 除外判定の記録はどこに残すか（SFA / 送信除外リスト / Excel）
• 慎重送信ラベルの送信文面テンプレートを誰が管理するか
• 「除外を解除する」条件と手続き（設立からの年数経過・追加与信情報の入手など）

これらは実装レベルの細目に見えますが、稟議承認後の運用で最初に議論になるポイントです。稟議書に添付しておくと、承認後の摩擦を減らせます。

与信情報活用の運用体制と、周辺プロセスとの接続

与信情報活用は「一度設計すれば終わり」ではなく、継続運用のプロセスです。ここでは更新頻度・担当者責任範囲・周辺プロセスとの接続点を整理します。

与信情報の更新頻度（月次全件洗い替え／四半期精査／取引開始前随時）

更新頻度は、データ層と用途によって使い分けます。

• 月次全件洗い替え: 法人番号公表サイトと gBizINFO の情報をバッチで更新する。清算結了・所在地変更などの差分を営業リストに反映する
• 四半期精査: 商用データベースの契約更新タイミングと合わせて、業種・規模情報の再取得と整合性チェックを行う
• 取引開始前随時: 反応があった案件のうち、契約書締結前・見積提示前など特定の意思決定タイミングで、TDB / TSR の精査を実施する

月次全件洗い替えを止めると、休眠化した企業への誤送信が徐々に増えるため、この頻度は最低限維持する設計が推奨されます。四半期精査と随時精査は、業界・商材の特性に応じて頻度を調整します。

送信除外リスト・リードスコアリング・SFA との接続点

与信情報活用は、単独で完結するプロセスではなく、周辺プロセスとの接続で価値が最大化されます。

• 送信除外リスト: 与信判定で「除外」となったレコードは、送信除外リストに自動追記する。手動リストとの重複排除・出所メモの記録を含めて設計する
• リードスコアリング: 反応があったリードには、与信情報を追加スコアとして加点する（例: TDB 評点 60 点以上 → +10）。営業リソースの優先配分に使う
• SFA / CRM: 案件レコードに与信情報のスナップショットを保存し、営業活動の履歴と紐付ける。契約締結時点の与信状態が後日追跡できるようになる

これらの接続を後付けで組もうとすると、既存の SFA スキーマや自動化フローに干渉して痛みを伴います。稟議段階で、どのプロセスに与信情報のどの項目を渡すかを併記しておくと、実装がスムーズになります。

与信情報活用を止めないための担当者・レビュー体制設計

継続運用で最も詰まりやすいのは、担当者の異動・退職に伴うノウハウ散逸です。以下の 3 点を初期設計に組み込んでおくと、運用が止まりにくくなります。

• 一次担当者と二次担当者を必ず 2 名以上置く。営業チームとオペレーションチームから 1 名ずつが理想です
• 判定ロジック・閾値・除外判定履歴を Git やスプレッドシートで版管理する。誰がいつ変更したかの追跡ができる形にしておく
• 四半期ごとにレビュー会議を開き、閾値の妥当性と誤除外・誤送信の実績を振り返る。反応率だけでなく、除外率・慎重送信率も同時に追う

継続運用の設計は地味な作業ですが、フォーム営業の「送信数」を伸ばすフェーズから「送信の質」を安定させるフェーズに移る際の分水嶺になります。

まとめ

フォーム営業の与信情報活用は、TDB・TSR に全件課金する道ではなく、無料一次データ・無料補足データ・商用データベース・有償与信精査の 4 層で段階運用する道が現実解です。

• 無料一次データ（法人番号公表サイト）で全法人マスタと差分イベントを取る
• 無料補足データ（gBizINFO）で資本金・従業員数・活動実績を付与する
• 商用データベースで業種・キーマン・売上規模を補強する
• 有償与信精査（TDB / TSR）は、想定商談金額が大きい案件と反応後の局所適用に絞る
• 判定ルールは 5 指標（設立年・資本金・従業員数・所在地整合性・与信評点）と 3 段階ラベリング（除外／慎重送信／通常送信）で稟議に載せる
• 月次全件洗い替え・四半期精査・取引開始前随時の 3 サイクルで継続運用する

この設計が回り始めると、「送信数を伸ばしたいが送ってはいけない相手に送りたくない」というフォーム営業運用のジレンマが緩みます。上長への稟議には、無料ソースだけで営業リストの何割を除外／慎重送信区分に振り分けられるかの試算と、有償精査を投入する局所ケースの定義を添えると、承認が通りやすくなります。

関連情報

フォーム営業の送信先の質を仕組みとして担保したい場合は、Form Pilot の設計思想もご確認ください。Form Pilot は、他社（取引先・別チャネル）が接触済みの企業ドメイン一覧を外部 API から取得し送信リストと突合する、「判断できないなら送らない」を基本とする設計（fail-closed）を採用しています。CAPTCHA については「受信側の意思表示を尊重する」方針で突破は行わず、CAPTCHA 付きフォームでは入力までを自動化し送信ボタンは人が押すセミオート運用を組み合わせます。

フォーム営業の与信情報活用フロー設計・送信除外リスト運用・SFA 連携などをご検討中の方は、お問い合わせフォーム からご相談ください。要件の整理段階からご相談いただけます。