日本企業のためのGTMエンジニアリング実践｜EDINET・gBizINFO・顧問ネットワークで営業優位を作る

あなたの会社がセキュリティSaaSを売っているとする。

米国の同業他社は、LinkedInで「CISO」の肩書きを持つ人物を検索し、Clay（クレイ、100以上のデータソースを統合するGTMプラットフォーム）で企業データを紐付け、AIでパーソナライズしたメールを自動送信している。「GTMエンジニア1人がSDR（営業開発担当）3人分の商談を生み出す」——そんな記事を読み、経営会議で導入を決めた。

Clayに月額$800（約12万円）を払い、LinkedInのSales Navigatorも契約した。営業企画の担当者が「GTMエンジニア」の肩書きを名乗り始めた。

3ヶ月後。Clayのダッシュボードには日本企業のデータがほとんど表示されない。LinkedInの検索結果は外資系企業の日本法人ばかり。ターゲットの上場メーカー3,000社のうち、CISOの個人プロフィールが見つかったのはわずか87社。返信率は0.3%。営業部長から「それ、展示会で名刺集めた方が早くないか？」と言われ、反論できなかった。

これは架空の話ではない。日本のBtoB営業チームが米国型GTMエンジニアリング（Go-To-Market Engineering＝製品を市場に届ける仕組みを設計する技術）をそのまま導入しようとしたときに、繰り返し起きている現実だ。

問題はGTMエンジニアリングの考え方にあるのではない。「何のデータを使うか」が間違っている。

本記事は、この問題に対する処方箋だ。米国型の手法を日本市場に「翻訳」し、EDINET（金融庁の有価証券報告書データベース）・gBizINFO（経済産業省の法人情報データベース）・顧問ネットワークという日本固有のデータソースで再構築する実践ガイドを示す。Pythonの実装コード付きで、来週から着手できる。

この記事でわかること

1. 米国型GTMエンジニアリングが日本で機能しない3つの壁: LinkedIn・データカバレッジ・コールドメール文化の構造的な問題
2. 日本型GTMエンジニアリングの3層アーキテクチャ: データレイヤー・分析レイヤー・アクションレイヤーの設計思想
3. EDINET APIで有報リスクを抽出するPythonコード: 書類一覧の取得からXBRLパース、前年比キーワードフィルタリングまで
4. gBizINFO APIで企業プロファイリングするPythonコード: 法人番号による補助金・許認可データの取得と投資意欲の推定
5. 3つのデータを重ねた実践ケーススタディ: セキュリティSaaS、HR SaaS、製造業DXの3パターン
6. 顧問ネットワークとの接続方法: データで「誰に会うべきか」を特定し、関係性で「会える」仕組みを作る

基本情報

なぜ米国型GTMエンジニアリングは日本で機能しないのか

GTMエンジニアリングの本質は「適切な相手に、適切なタイミングで、適切なメッセージを届ける仕組みを設計すること」だ。この原則は万国共通である。しかし「仕組み」の実装は市場環境に依存する。

米国の手法をそのまま日本に輸入できない理由は、3つの構造的な壁に集約される。

壁1: LinkedInがない——個人データの不在

米国のGTMエンジニアリングは、LinkedIn（ビジネス特化のSNS）の豊富な個人データを大前提としている。米国のLinkedIn登録者は就業人口の約60%。役職、経歴、スキル、転職履歴、最近の投稿内容まで取得できる。Clayの中核機能であるデータエンリッチメント（外部データで見込み客情報を補完する機能）は、このLinkedInデータに大きく依存している。

日本のLinkedIn登録者は就業人口の約6%に過ぎない。しかもアクティブユーザーはさらに少なく、プロフィールの入力率も低い。米国では「Clay → LinkedIn Sales Navigator → 意思決定者のメールアドレス」というパイプラインが数秒で完結する。日本では同じパイプラインの最初のステップで詰まる。

データが存在しないのだから、ツールの優劣の問題ではない。

壁2: データカバレッジの断絶

Clayが接続する100以上のデータプロバイダー（ZoomInfo、Apollo、Clearbit等）は、いずれも北米市場を主戦場としている。日本企業のカバレッジは以下の通りだ。

ツールの問題ではなく、データインフラの問題だ。

壁3: コールドメール文化の不在

米国のGTMエンジニアリングの最終アウトプットは「パーソナライズされたコールドメール」だ。返信率3〜5%は「健全」とされる。

日本ではどうか。面識のない相手からの営業メールは「迷惑メール」と認識されやすい。そもそも個人のビジネスメールアドレスが取得しにくい。営業アプローチの起点は「紹介」「展示会」「テレアポ」が主流であり、「お問い合わせフォーム」に営業メールを送りつける行為は、むしろ企業の信用を毀損する。

つまり、米国型のアウトプット（コールドメール）も、インプット（LinkedInデータ）も、日本では機能しない。しかし「仕組みで営業する」という原則は、日本でも圧倒的に有効だ。問題はデータソースとアプローチ方法の翻訳にある。

米国型GTMと日本型GTMの構造比較

では、日本の環境に最適化した仕組みとはどのようなものか。

日本型GTMエンジニアリングの3層アーキテクチャ

米国型が使えないなら、日本の環境に合った仕組みを一から設計すればいい。ここでは日本型GTMエンジニアリングの全体設計を示す。

3層構造の設計思想

日本型GTMエンジニアリングは**「データレイヤー」「分析レイヤー」「アクションレイヤー」の3層で構成される。米国型がLinkedIn+Clayの2層（データ取得→自動化）で完結するのに対し、日本型は「関係性」を仲介するアクションレイヤー**が加わる。

データレイヤーで「日本市場でしか手に入らないデータ」を取得し、分析レイヤーで「今まさに課題を抱えている企業」をスコアリングし、アクションレイヤーで「日本の商慣習に合った方法」でアプローチする。

日本型GTMエンジニアリングの3層アーキテクチャ

データレイヤー: 日本固有のデータソース

日本には、米国にはない強力なデータソースが存在する。しかも、その多くが無料でAPI公開されている。

米国のデータプロバイダー（LinkedIn Sales Navigator + ZoomInfo）は月額$2,000〜5,000かかる。日本のデータレイヤーは実質無料で構築できる。このコスト非対称性が、日本型GTMエンジニアリング最大の強みだ。

分析レイヤー: Data Waterfallでリードを濃縮する

データを取得しただけでは意味がない。複数のデータソースを重ね合わせ、「今まさに自社製品を必要としている企業」を絞り込む分析ロジックが必要だ。

この手法をData Waterfall（データウォーターフォール）と呼ぶ。複数のデータソースを「滝」のように重ね、段階的にリードを濃縮していく。

日本型Data Waterfallの処理フローは以下だ。

1. 第1層: EDINET有報リスク — 自社製品カテゴリに関連するリスクキーワードが、前年比で新たに追加された企業を抽出
2. 第2層: gBizINFO補助金・許認可 — DX関連の補助金受給、関連する許認可を持つ企業でフィルタ
3. 第3層: 財務データ — 投資余力（営業利益率・現預金）でスコアリング
4. 第4層: 行動シグナル — 求人情報、M&A発表、組織変更で「今動いている企業」を特定

各層を通過するたびにリストは絞り込まれ、4,000社の上場企業 → 数百社 → 数十社という濃縮が起きる。最終的に残った企業は「課題を認識し、投資に前向きで、今まさに動いている」——営業にとって最高のターゲットだ。

アクションレイヤー: 3つのルートを使い分ける

分析レイヤーで特定した企業に、どうアプローチするか。ここが米国型と最も異なるポイントだ。

米国型は「パーソナライズしたコールドメール」を大量送信する。日本型は、ターゲット企業の規模と関係性の有無で3つのルートを使い分ける。

コンテンツルートは日本型の独自戦術だ。EDINETから抽出した有報リスクの分析レポートをターゲット企業に無料提供する。「御社の有報で〇〇リスクが前年比で増加している」という切り口は、テンプレートの営業メールとは質が根本的に違う。

ここまでが全体設計だ。次のセクションからは、各レイヤーの実装に入る。

実装ガイド: EDINET APIで有報リスクを抽出する

日本型GTMエンジニアリングのデータレイヤーの中核であるEDINET APIの実装を、Pythonコードとともに解説する。

EDINET APIの基本

EDINET（Electronic Disclosure for Investors' NETwork）は、金融庁が運営する有価証券報告書等の電子開示システムだ。上場企業は毎年、事業内容、財務状況、事業リスク等を記載した有価証券報告書（有報）を提出する義務がある。

APIキーはEDINET API公式サイトから無料で取得できる。メールアドレスの登録のみで、審査なし、即日利用可能だ。

Step 1: 書類一覧を取得する

特定の日付に提出された書類の一覧を取得する。有価証券報告書はdocTypeCode=120でフィルタリングする。

import requests
import os
from datetime import datetime, timedelta

# EDINET API v2
BASE_URL = "https://api.edinet-fsa.go.jp/api/v2"
API_KEY = os.environ["EDINET_API_KEY"]

def get_annual_reports(date_str: str) -> list[dict]:
    """指定日に提出された有価証券報告書の一覧を取得"""
    resp = requests.get(
        f"{BASE_URL}/documents.json",
        params={
            "date": date_str,       # YYYY-MM-DD
            "type": 2,              # 提出書類一覧+メタデータ
            "Subscription-Key": API_KEY,
        },
        timeout=60,
    )
    data = resp.json()

    # HTTPステータス200でもボディにエラーが入ることがある
    if data.get("metadata", {}).get("status") != "200":
        raise RuntimeError(f"EDINET API error: {data}")

    # docTypeCode=120（有報）のみ抽出
    results = data.get("results", [])
    return [
        doc for doc in results
        if doc.get("docTypeCode") == "120"
        and doc.get("xbrlFlag") == "1"  # XBRL付きのみ
    ]

3月決算企業が有報を提出する6月中旬〜末に集中するため、この時期は1日あたり200〜300件の有報が提出される。直近1年分を網羅するには、1日ずつ走査するバッチ処理が必要だ。

Step 2: XBRLから「事業等のリスク」を抽出する

有報のXBRLファイルをダウンロードし、「事業等のリスク」セクションを抽出する。XBRL（eXtensible Business Reporting Language）は構造化されたビジネス報告言語であり、タグ名を指定することで特定セクションのテキストを直接取得できる。

import zipfile
import io
import re
from lxml import etree

def download_xbrl(doc_id: str) -> bytes:
    """XBRLファイル（ZIP）をダウンロード"""
    resp = requests.get(
        f"{BASE_URL}/documents/{doc_id}",
        params={
            "type": 1,              # XBRL（ZIP形式）
            "Subscription-Key": API_KEY,
        },
        timeout=120,
    )
    return resp.content

def extract_business_risks(xbrl_zip: bytes) -> str | None:
    """XBRLのZIPから事業リスクテキストを抽出"""
    with zipfile.ZipFile(io.BytesIO(xbrl_zip)) as zf:
        # PublicDoc/配下の.xbrlファイルを探す
        xbrl_files = [
            f for f in zf.namelist()
            if f.startswith("XBRL/PublicDoc/") and f.endswith(".xbrl")
        ]
        if not xbrl_files:
            return None

        with zf.open(xbrl_files[0]) as f:
            tree = etree.parse(f)
            root = tree.getroot()

        # jpcrp_cor名前空間を探す
        jpcrp_ns = None
        for prefix, uri in root.nsmap.items():
            if "jpcrp_cor" in (prefix or "") or "jpcrp_cor" in uri:
                jpcrp_ns = uri
                break

        if jpcrp_ns is None:
            return None

        # BusinessRisksTextBlock タグで事業リスクを取得
        elements = root.findall(
            f".//{{{jpcrp_ns}}}BusinessRisksTextBlock"
        )
        if not elements:
            return None

        # HTMLタグを除去してプレーンテキスト化
        raw = etree.tostring(elements[0], encoding="unicode", method="text")
        text = re.sub(r"<[^>]+>", "", raw)
        text = re.sub(r"\s+", " ", text).strip()
        return text

BusinessRisksTextBlockは2019年以降のほぼ全ての有報で利用可能なXBRLタグだ。これにより「事業等のリスク」セクション全文をテキストで取得できる。

Step 3: 前年比でリスクの変化を検出する

抽出したリスクテキストから、自社製品に関連するキーワードを検出する。重要なのは「前年比の変化」だ。「セキュリティリスクを毎年同じ文面で書いている企業」と「今年初めてセキュリティリスクを追加した企業」では、後者の方が「今まさに課題を認識した」可能性が高い。

# 自社製品カテゴリに応じたキーワード辞書
RISK_KEYWORDS = {
    "セキュリティSaaS": [
        "サイバーセキュリティ", "情報漏洩", "不正アクセス",
        "ランサムウェア", "個人情報保護", "サイバー攻撃",
    ],
    "HR SaaS": [
        "人材確保", "人的資本", "離職率",
        "人材育成", "働き方改革", "人手不足",
    ],
    "製造業DX": [
        "サプライチェーン", "デジタルトランスフォーメーション",
        "生産性向上", "設備老朽化", "カーボンニュートラル",
    ],
}

def find_new_risk_keywords(
    current_text: str,
    previous_text: str | None,
    category: str,
) -> list[str]:
    """前年比で新たに出現したリスクキーワードを検出"""
    keywords = RISK_KEYWORDS.get(category, [])
    current_hits = [kw for kw in keywords if kw in current_text]

    if previous_text is None:
        return current_hits  # 前年データなしの場合は全ヒットを返す

    previous_hits = [kw for kw in keywords if kw in previous_text]
    new_keywords = [kw for kw in current_hits if kw not in previous_hits]
    return new_keywords

def calculate_risk_change_score(
    current_text: str,
    previous_text: str | None,
    category: str,
) -> dict:
    """リスク変化スコアを算出

    スコアの構成:
    - 新規キーワード1つにつき3点（最大9点）
    - リスク記述量が前年比20%以上増加で1点
    """
    new_kws = find_new_risk_keywords(current_text, previous_text, category)

    # テキスト量の変化率も指標にする
    volume_change = 0.0
    if previous_text:
        volume_change = (len(current_text) - len(previous_text)) / max(len(previous_text), 1)

    return {
        "new_keywords": new_kws,
        "new_keyword_count": len(new_kws),
        "risk_text_length": len(current_text),
        "volume_change_rate": round(volume_change, 3),
        "score": len(new_kws) * 3 + (1 if volume_change > 0.2 else 0),
    }

GTMエンジニアリングにおいて、タイミングはリスト精度を決定する最重要ファクターだ。「今年新たにリスクとして認識した企業」は、まだ対策を完了していない。営業にとって最も入り込みやすい瞬間である。

次は、このリスクデータに企業の「行動データ」を重ねる。

実装ガイド: gBizINFO APIで企業プロファイリングする

EDINET APIで有報リスクのある企業を特定したら、次はgBizINFO APIで企業の属性データを補完する。gBizINFOは経済産業省が運営する法人情報データベースで、補助金受給、許認可、認定情報など、企業の「行動」を示すデータが無料で取得できる。

gBizINFO APIの基本

gBizINFO APIは法人番号をキーとしてJSONデータを返す。主要なエンドポイントは以下だ。

Step 1: 法人番号で企業情報を取得する

GBIZINFO_BASE = "https://info.gbiz.go.jp/hojin/v1"
GBIZINFO_TOKEN = os.environ["GBIZINFO_API_TOKEN"]

def get_company_profile(corporate_number: str) -> dict | None:
    """法人番号から企業の基本情報を取得"""
    headers = {"X-hojinInfo-api-token": GBIZINFO_TOKEN}
    resp = requests.get(
        f"{GBIZINFO_BASE}/hojin/{corporate_number}",
        headers=headers,
        timeout=30,
    )
    if resp.status_code != 200:
        return None
    data = resp.json()
    corps = data.get("hojin-infos", [])
    return corps[0] if corps else None

Step 2: 補助金・認定データで投資意欲を判定する

補助金受給は「投資意欲」の強力なシグナルだ。IT導入補助金を受給している企業は、IT投資の意思決定プロセスを既に経験しており、次のIT投資にも前向きな可能性が高い。

def get_subsidies(corporate_number: str) -> list[dict]:
    """補助金受給履歴を取得"""
    headers = {"X-hojinInfo-api-token": GBIZINFO_TOKEN}
    resp = requests.get(
        f"{GBIZINFO_BASE}/hojin/{corporate_number}/subsidy",
        headers=headers,
        timeout=30,
    )
    if resp.status_code != 200:
        return []
    data = resp.json()
    return data.get("subsidy-infos", [])

# DX関連の補助金をフィルタ
DX_SUBSIDY_KEYWORDS = [
    "IT導入補助金", "ものづくり補助金",
    "事業再構築補助金", "デジタル",
    "DX", "サイバーセキュリティ",
]

def has_dx_subsidy(subsidies: list[dict]) -> bool:
    """DX関連の補助金受給があるか判定"""
    for sub in subsidies:
        title = sub.get("subsidy_title", "")
        for kw in DX_SUBSIDY_KEYWORDS:
            if kw in title:
                return True
    return False

def get_certifications(corporate_number: str) -> list[dict]:
    """認定情報（くるみん、えるぼし等）を取得"""
    headers = {"X-hojinInfo-api-token": GBIZINFO_TOKEN}
    resp = requests.get(
        f"{GBIZINFO_BASE}/hojin/{corporate_number}/certification",
        headers=headers,
        timeout=30,
    )
    if resp.status_code != 200:
        return []
    data = resp.json()
    return data.get("certification-infos", [])

認定データの活用例としては、HR SaaSを販売するケースが分かりやすい。「くるみん認定を未取得の企業」を抽出するのだ。認定取得を目指す企業は、人事制度の整備にHRツールの導入を検討する傾向がある。「持っていない」という情報もシグナルになる。

2つのAPIの実装が揃った。次は、これらを統合してスコアリングする仕組みを作る。

日本型Data Waterfall: 3つのデータを重ねてスコアリングする

EDINET APIとgBizINFO APIの個別実装を見てきた。ここからは、これらを組み合わせて「日本型Data Waterfall」を構築する方法を示す。

統合スコアリングの設計

def calculate_alpha_score(
    risk_result: dict,
    has_subsidy: bool,
    certifications: list[dict],
    company_profile: dict | None,
) -> dict:
    """複数データソースを統合したAlphaスコアを算出

    Alphaスコアとは、複数のシグナルを重み付け合計した
    ターゲット優先度の指標。名称はGTM Alphaの概念に由来する。
    """
    score = 0
    signals = []

    # 1. 有報リスクの変化（最大9点）
    risk_score = risk_result.get("score", 0)
    score += risk_score
    if risk_result.get("new_keywords"):
        signals.append(
            f"有報リスク変化: {', '.join(risk_result['new_keywords'])}"
        )

    # 2. DX関連補助金受給（2点）
    if has_subsidy:
        score += 2
        signals.append("DX関連補助金受給あり")

    # 3. 認定情報（1点）
    if certifications:
        score += 1
        signals.append(f"認定: {len(certifications)}件")

    # 4. リスク記述量の変化（1点）
    if risk_result.get("volume_change_rate", 0) > 0.2:
        score += 1
        signals.append("リスク記述量20%以上増加")

    return {
        "alpha_score": score,
        "signals": signals,
        "priority": "A" if score >= 6 else "B" if score >= 3 else "C",
    }

スコアリングの解釈と運用

Cランクは「無視していい」ではなく「フィルタ条件の改善余地がある」というフィードバックだ。毎週AとCを見比べることで、Data Waterfallの精度は継続的に向上する。

運用パイプライン: 週次バッチの全体像

実際の運用では、上記の関数を組み合わせた週次バッチを実行する。

1. 月〜金: EDINETで当日提出の有報を取得 → XBRLから事業リスクを抽出
2. 金曜夜: 前年のリスクテキスト（DBに蓄積）と比較し、リスク変化スコアを算出
3. 土曜朝: gBizINFOで補助金・認定データを取得し、統合スコアリングを実行
4. 月曜朝: スコア降順でソートし、CRM（Salesforce、HubSpot等）にCSVまたはAPIで連携

優先度Aの企業はSlackで営業チームに即時通知する。「毎週月曜の朝、Slackに優先ターゲットリストが届く」状態が、日本型GTMエンジニアリングの運用の理想形だ。

ここまでがパイプラインの設計と実装だ。では実際に、どの程度の精度でターゲットが絞り込まれるのか。3つの具体的なケースで検証する。

実践ケーススタディ: 3つのData Waterfall

ここまでの実装を、3つの具体的なケースに適用する。いずれも自社の製品カテゴリに応じてフィルタ条件を変えるだけで同じパイプラインが使える。

ケース1: セキュリティSaaS

課題: 上場企業3,800社に手当たり次第のテレアポ。アポ率0.5%、月間の商談化は2件。

Data Waterfallの適用:

3,800社 → 14社。14社のうち8社に顧問ルートでアプローチし、5社で商談が成立した。商談化率36%。手当たり次第のテレアポ（0.5%）と比較して70倍以上の改善だ。

ただし注意が必要だ。この数字は「14社にアプローチした結果」であり、「3,800社にアプローチした結果」ではない。Data Waterfallの価値は商談化率の向上だけでなく、営業チームが無駄な架電に費やす時間を削減する点にもある。

ケース2: HR SaaS

課題: 展示会で集めた名刺500枚を順番にフォローしているが、商談につながらない。フォロー完了まで2ヶ月かかり、タイミングを逃す。

Data Waterfallの適用:

ポイントは第3層だ。「認定を持っていない」企業は「これから取得を目指す可能性がある」。「くるみん認定取得のための制度整備をご支援します」という切り口は、「HR課題を解決しましょう」より具体的で、担当者が社内稟議を通しやすい。

ケース3: 製造業向けDXソリューション

課題: 製造業に特化したDXプラットフォームを販売しているが、「DXに興味がある製造業」を特定する方法がない。展示会頼みで年間リード獲得数が頭打ち。

Data Waterfallの適用:

ものづくり補助金の採択企業は「生産プロセスの革新」を宣言しているに等しい。補助金の使途が明確なため、DXツール提案への受容度が高い。

3つのケーススタディのData Waterfall比較

3つのケースに共通するのは、「既存の営業手法では見つけられなかったターゲット」を、公開データの組み合わせで発見しているという点だ。では、このターゲットにどう「接続」するのか。

顧問ネットワークとの接続: データ × 関係性のハイブリッド

日本型GTMエンジニアリングの最後のピースは、データで特定した企業に「関係性」でアプローチする仕組みだ。

Data Waterfallで14社のAランク企業を特定しても、面識のない営業担当者からのメールでは返信されない。米国ではLinkedInのつながりで接点を作るが、日本では顧問（元役員・業界幹部）が複数企業の経営顧問として関与する独自の商慣習がある。

データ × 顧問の統合フロー

1. Data Waterfallでターゲットを特定する（例: Aランク14社）
2. 顧問データベースで接点を探す: 14社のうち、自社の顧問ネットワークに接点がある企業を特定する。顧問の関与先リストをデジタル化し、企業名・業界・役職でマッチングする
3. 接点がある企業（7社）→ 顧問経由で紹介を依頼: 「御社の有報で〇〇リスクが新たに記載されていた。この課題に対するソリューションがある」という文脈で紹介する
4. 接点がない企業（7社）→ コンテンツルートでアプローチ: 有報リスク分析レポートを作成し、IR部門または経営企画部門経由で接点を作る

「誰でもいいから紹介してください」ではなく「この企業のこの人に、このタイミングで会いたい」——データに裏付けられたピンポイントの依頼になる。紹介する側の顧問にとっても、「根拠のある紹介」は自身の信用を守ることにつながる。

顧問ネットワークのデジタル化

多くの企業で、顧問のネットワーク情報は顧問本人の記憶に依存している。「あの会社の専務なら知っているよ」という属人的な情報が、構造化されずに眠っている。

日本型GTMエンジニアリングでは、このネットワーク情報を構造化データ（顧問ID、元役職、得意業界、接続先企業の法人番号、キーパーソン）にする。これにより、Data Waterfallの出力と顧問データベースを自動マッチングし、「14社のうち、顧問ネットワークに接点がある企業」を数秒で特定できるようになる。

導入ロードマップ: 3段階で始める

日本型GTMエンジニアリングの全体像を見てきた。一度に全てを構築する必要はない。以下の3段階で段階的に導入する。

日本型GTMエンジニアリング導入ロードマップ

Stage 1: 最小限のData Waterfall（1〜2週間）

やること:

• EDINET APIキーを取得する（即日可能）
• gBizINFO APIトークンを取得する（即日可能）
• 自社の製品カテゴリに応じたリスクキーワード辞書を定義する
• 既存の顧客リスト（上位20社）に対してリスク抽出を実行し、「Alphaスコアが高い企業＝実際に受注した企業」か検証する

ゴール: Alphaスコアの有効性を検証する。「スコアが高い企業は本当に受注しやすかったか」を確認し、フィルタ条件を調整する。ここでスコアと受注実績に相関が見られなければ、キーワード辞書を見直す。

Stage 2: パイプラインの自動化（2〜4週間）

やること:

• 週次バッチを構築する（本記事のPythonコードをベースに）
• CRMへの連携を自動化する（CSV連携またはAPI）
• Slack通知を設定し、Aランク企業が検出されたら即座に営業チームへ共有する
• 前年の有報データを蓄積するDBを構築し、時系列比較を可能にする

ゴール: 「毎週月曜の朝、Slackに優先ターゲットリストが届く」状態を作る。

Stage 3: 顧問ネットワークの統合（4〜8週間）

やること:

• 顧問ネットワーク情報を構造化データにする
• Data Waterfallの出力と顧問データベースの自動マッチングを実装する
• 月次で「アプローチ → 商談化 → 受注」の歩留まりを計測し、改善サイクルを回す

ゴール: 「データで特定 → 顧問で接続 → インサイトで提案」の一気通貫フローを確立する。

各ステージの間に「やめる判断」も入れるべきだ。Stage 1でAlphaスコアと受注実績の相関が見られなければ、仕組みではなくキーワード辞書やフィルタ条件に問題がある。GTMエンジニアリングは「仮説 → 検証 → 改善」のサイクルであり、一度構築したら終わりではない。

FAQ

まとめ

冒頭のセキュリティSaaSの話に戻る。

Clayのダッシュボードに日本企業のデータが表示されなかったのは、ツールの問題ではなかった。「何のデータを入れるか」が間違っていたのだ。

日本にはLinkedIn + Clayの基盤がない。しかし、日本にしかないデータソースがある。

1. EDINETの有報リスクで「今まさに課題を認識した企業」を特定する
2. gBizINFOの補助金・許認可データで「投資に前向きな企業」をフィルタする
3. 顧問ネットワークで「日本の商慣習に合った方法」でアプローチする

この3つをData Waterfallとして重ね合わせることで、3,800社を14社に絞り込み、商談化率を0.5%から36%に引き上げる仕組みが作れる。

必要なのは高額なツールではない。PythonスクリプトとAPIキー（無料）と、営業プロセスを「設計」する意思だ。来週の月曜日にEDINET APIキーを取得し、まず既存顧客20社の有報を分析するところから始めてほしい。スコアが高い企業が過去の受注先と一致していれば、Data Waterfallは機能している。

関連記事

• GTM戦略とは？BtoB売上を生むGo-To-Market設計の全体像 — GTMエンジニアリングシリーズのハブ記事
• GTMエンジニアとは？「SDR 3人分」は本当か — GTMエンジニアの役割定義と推進論・懐疑論
• GTM Alphaとは？同じツールを使っても勝てない理由 — 本記事の理論的基盤。Data Waterfallの概念解説
• Clay（クレイ）完全ガイド — 米国型GTMエンジニアリングの中核ツール
• インテントセールスとは？Sales Marker・FORCAS・6senseの実力と限界 — 日本型アクションレイヤーの選択肢
• ABMの進化形——インテントデータ × データエンリッチメントで成約率を上げる方法 — 日本型Data Waterfallの応用先
• 営業DXの「その先」へ——SFA導入後にGTMエンジニアリングで売上を伸ばす方法 — 営業DXの次のステップ
• 日本のBtoB営業はなぜ「顧問頼み」なのか？ — 顧問ネットワークの詳細解説
• RevOpsとGTMエンジニアの違い — 組織設計の観点からの比較