海外GTMのブログを読むと、職務DBから買い手を特定し、エンリッチメントツールで企業情報を補い、個別メールを送る流れがよく出てくる。Clayのようなツールを使い、データ取得から文面生成までを組み合わせる設計だ。
日本のBtoB市場で同じ設計を直輸入すると、最初のリスト作成で詰まりやすい。職務DBに載る人が偏り、企業単位の課題は見えても、誰へどの文脈で渡すかが曖昧になる。結果として、営業チームは「いいリストに見えるが、動かせない」案件を抱える。
この問題は、GTMエンジニアリングの考え方そのものではなく、入力データと営業への受け渡しを日本市場向けに翻訳できていないことにある。
本記事では、EDINET、gBizINFO、顧問ネットワークを使い、日本企業向けのGTMエンジニアリングを設計する。狙いは、売れる企業名を占うことではない。公開データで仮説を作り、営業が確認すべき順番と文脈をそろえることだ。
本記事の前提
| 項目 | 内容 |
|---|---|
| 設計テーマ | 日本企業向けGTMエンジニアリング |
| 主な入力 | EDINET、gBizINFO、適時開示、求人、既存顧客データ |
| 主な出力 | 優先ターゲット、仮説メモ、営業への確認依頼 |
| 必要なスキル | Python基礎、API連携、営業プロセス設計 |
| 向いている読者 | BtoB営業企画、RevOps、GTMエンジニア、事業責任者 |
GTMエンジニアリングの本質は、適切な相手に、適切なタイミングで、適切なメッセージを届ける仕組みを設計することだ。この原則は日本でも使える。
ただし、実装の前提は市場ごとに違う。海外のGTM記事でよく見る「職務データを起点に個人を特定し、自動メールで検証する」流れは、日本では次の3点でつまずきやすい。
海外では、職務データ、メール推定、採用情報、SNS投稿を組み合わせて、個人単位の接点を作る設計が多い。日本では、同じ粒度の個人データを安定して集めにくい。
そのため、いきなり「誰に送るか」から始めるより、まず「どの企業に、なぜ今話すのか」を企業単位で固める方が実務に乗せやすい。
エンリッチメントツールの情報は便利だが、日本企業の部門構造、決裁経路、稟議文脈までは外から見えにくい。担当者名が見つかっても、営業が使える仮説がなければ会話は始まらない。
EDINETやgBizINFOのような公開データは、個人名簿ではない。その代わり、企業が開示した課題、受けた支援、持っている認定、調達や事業活動の痕跡を確認できる。GTMでは、この「企業が外に出した事実」を仮説の根にする。
日本の大企業・中堅企業では、初回接点がメールだけで完結しないことが多い。紹介、セミナー、既存顧客経由、顧問経由、問い合わせ、電話など、入口が複数ある。
GTMエンジニアリングの役割は、営業を自動化で置き換えることではない。営業が動く前に、なぜその企業に話すのか、どの資料を渡すのか、誰に確認すべきかを整理することだ。
日本向けに設計するなら、GTMエンジニアリングを次の3層に分けると扱いやすい。
| レイヤー | 役割 | 代表的な入力 |
|---|---|---|
| データレイヤー | 企業が外に出した事実を集める | EDINET、gBizINFO、適時開示、求人、公開IR |
| 分析レイヤー | 自社商材に関係する変化を抽出する | キーワード辞書、前年差分、LLM要約、スコア |
| 受け渡しレイヤー | 営業が確認できる形へ変換する | CRM、Slack、顧問DB、仮説メモ |
海外型が「個人データ -> 自動メール」に寄りやすいのに対し、日本型は「企業シグナル -> 営業仮説 -> 接点探索」に寄せる。
最初に、入力データを性質ごとに分ける。ひとつの万能データベースを探すのではなく、複数の弱いシグナルを重ねる前提で設計する。
| データソース | 読み取れること | 注意点 |
|---|---|---|
| EDINET | 有価証券報告書、事業リスク、経営方針、役員情報 | 開示文書なので営業意向そのものではない |
| gBizINFO | 企業基本情報、補助金、認定、調達など | 項目や収録範囲は公式仕様で確認する |
| 適時開示 | M&A、業績修正、新規事業、組織再編 | テキストの解釈に人の確認が必要 |
| 求人情報 | 採用強化領域、職種、拠点 | 採用需要と購買需要を混同しない |
| 既存顧客データ | 受注企業の共通点、勝ち筋 | 社内データの品質に左右される |
GTMエンジニアリングでは、公開データを「営業リスト」ではなく「仮説生成の材料」として扱う。たとえば、セキュリティSaaSなら、EDINETの事業リスクに出てくるセキュリティ関連記述を読み、gBizINFOや求人で投資・採用の動きを補助的に見る。
Data Waterfallは、複数のデータソースを順番に重ね、ターゲット候補を絞る設計だ。日本向けには、次のような順番が扱いやすい。
重要なのは、スコアを絶対視しないことだ。スコアは「営業が確認する順番」を作るための道具であり、受注確率を保証するものではない。
GTMエンジニアリングの成果物は、企業名のリストだけでは弱い。営業が動ける形にするには、最低限次の4点をセットで渡す。
| 項目 | 内容 |
|---|---|
| なぜ今か | 公開データで見つけた変化 |
| 何を聞くか | 初回面談で検証すべき仮説 |
| 誰から入るか | 顧問、既存顧客、パートナー、問い合わせなどの入口 |
| 何を残すか | CRMに残す結果、次回の改善に使う情報 |
この4点がないと、GTMエンジニアリングは「精度の高そうなリスト作り」で止まる。
EDINETは、金融庁が運営する開示システムだ。APIの詳細、利用条件、取得手順はEDINET API公式ガイドで確認する。
ここでは、有価証券報告書から「事業等のリスク」を抽出し、前年との差分を見るPoCを示す。
特定日に提出された書類を取得し、有価証券報告書に該当する文書だけを残す。
import os
import requests
EDINET_BASE_URL = "https://api.edinet-fsa.go.jp/api/v2"
EDINET_API_KEY = os.environ["EDINET_API_KEY"]
def get_annual_reports(date_str: str) -> list[dict]:
"""指定日の有価証券報告書候補を取得する。"""
resp = requests.get(
f"{EDINET_BASE_URL}/documents.json",
params={
"date": date_str,
"type": 2,
"Subscription-Key": EDINET_API_KEY,
},
timeout=60,
)
resp.raise_for_status()
payload = resp.json()
if payload.get("metadata", {}).get("status") != "200":
raise RuntimeError(f"EDINET API error: {payload}")
return [
doc
for doc in payload.get("results", [])
if doc.get("docTypeCode") == "120"
and doc.get("xbrlFlag") == "1"
]
実運用では、対象期間を日次で走査し、取得済み文書IDを保存して二重取得を避ける。APIの呼び出し間隔やエラー時の扱いは、公式ガイドと自社の運用要件に合わせる。
有価証券報告書のXBRLをダウンロードし、事業等のリスク本文を取り出す。
import io
import re
import zipfile
from lxml import etree
def download_xbrl(doc_id: str) -> bytes:
"""EDINET文書IDからXBRL ZIPを取得する。"""
resp = requests.get(
f"{EDINET_BASE_URL}/documents/{doc_id}",
params={
"type": 1,
"Subscription-Key": EDINET_API_KEY,
},
timeout=120,
)
resp.raise_for_status()
return resp.content
def extract_business_risks(xbrl_zip: bytes) -> str | None:
"""XBRL ZIPから事業等のリスク本文を抽出する。"""
with zipfile.ZipFile(io.BytesIO(xbrl_zip)) as archive:
xbrl_files = [
name
for name in archive.namelist()
if name.startswith("XBRL/PublicDoc/")
and name.endswith(".xbrl")
]
if not xbrl_files:
return None
with archive.open(xbrl_files[0]) as file:
tree = etree.parse(file)
root = tree.getroot()
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
elements = root.findall(f".//{{{jpcrp_ns}}}BusinessRisksTextBlock")
if not elements:
return None
raw_text = etree.tostring(elements[0], encoding="unicode", method="text")
return re.sub(r"\s+", " ", raw_text).strip()
XBRLタグは文書様式によって差が出ることがある。空振りした文書は、手動レビュー用のキューに回す方がよい。
単にキーワードが含まれる企業を拾うだけでは、毎年同じ文章を書いている企業も混ざる。GTMで見たいのは、課題としての重みが増えた可能性だ。
RISK_KEYWORDS = {
"security_saas": [
"サイバーセキュリティ",
"情報漏えい",
"不正アクセス",
"ランサムウェア",
"個人情報",
"サイバー攻撃",
],
"hr_saas": [
"人材確保",
"人的資本",
"離職",
"人材育成",
"働き方",
"人手不足",
],
"manufacturing_dx": [
"サプライチェーン",
"デジタルトランスフォーメーション",
"生産性",
"設備老朽化",
"カーボンニュートラル",
],
}
def find_new_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 not previous_text:
return current_hits
previous_hits = [kw for kw in keywords if kw in previous_text]
return [kw for kw in current_hits if kw not in previous_hits]
def score_risk_change(
current_text: str,
previous_text: str | None,
category: str,
) -> dict:
"""営業仮説用の簡易スコアを作る。"""
new_keywords = find_new_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_keywords,
"keyword_count": len(new_keywords),
"volume_change_rate": round(volume_change, 3),
"needs_human_review": len(new_keywords) > 0 or volume_change > 0.2,
}
ここで得た結果は「購入意欲」ではない。あくまで、営業が「この課題をどう捉えていますか」と確認するための入口だ。
gBizINFOは、経済産業省が提供する企業情報サービスだ。APIのエンドポイント、認証、収録項目はgBizINFO公式サイトで確認する。
EDINETが開示文書を読む入口だとすれば、gBizINFOは企業の属性や公的支援・認定などのシグナルを足す入口になる。
import os
import requests
GBIZINFO_BASE_URL = "https://info.gbiz.go.jp/hojin/v1"
GBIZINFO_API_TOKEN = os.environ["GBIZINFO_API_TOKEN"]
def get_company_profile(corporate_number: str) -> dict | None:
"""企業番号からgBizINFOの基本情報を取得する。"""
resp = requests.get(
f"{GBIZINFO_BASE_URL}/hojin/{corporate_number}",
headers={"X-hojinInfo-api-token": GBIZINFO_API_TOKEN},
timeout=30,
)
if resp.status_code != 200:
return None
payload = resp.json()
records = payload.get("hojin-infos", [])
return records[0] if records else None
補助金を受けているから買う、認定を持っていないから困っている、と短絡しない。各データは、営業が確認すべき問いに変換する。
def get_gbiz_records(corporate_number: str, resource: str) -> list[dict]:
"""gBizINFOのサブリソースを取得する共通関数。"""
resp = requests.get(
f"{GBIZINFO_BASE_URL}/hojin/{corporate_number}/{resource}",
headers={"X-hojinInfo-api-token": GBIZINFO_API_TOKEN},
timeout=30,
)
if resp.status_code != 200:
return []
payload = resp.json()
key = f"{resource}-infos"
return payload.get(key, [])
def build_activity_signals(corporate_number: str) -> dict:
"""営業仮説に使う企業活動シグナルを作る。"""
subsidies = get_gbiz_records(corporate_number, "subsidy")
certifications = get_gbiz_records(corporate_number, "certification")
procurements = get_gbiz_records(corporate_number, "procurement")
return {
"has_subsidy_records": len(subsidies) > 0,
"has_certification_records": len(certifications) > 0,
"has_procurement_records": len(procurements) > 0,
"review_questions": [
"直近の投資テーマと自社商材の接点はあるか",
"認定や調達の履歴から担当部門を推測できるか",
"初回接点で確認すべき公開事実は何か",
],
}
gBizINFOの値は、営業リストの正解ではなく、会話の下準備に使う。CRMへは、元データのURL、取得日、解釈メモをセットで残す。
EDINETとgBizINFOを別々に見ても、営業は動きにくい。Data Waterfallでは、複数のシグナルを重ねて「確認順」を作る。
def calculate_gtm_signal_score(
risk_result: dict,
activity_signals: dict,
has_customer_similarity: bool,
has_relationship_path: bool,
) -> dict:
"""営業確認の優先順位を作るための簡易スコア。"""
score = 0
reasons = []
if risk_result.get("new_keywords"):
score += 3
reasons.append("事業リスクに新しい関連語がある")
if risk_result.get("volume_change_rate", 0) > 0.2:
score += 1
reasons.append("事業リスクの記述量が増えている")
if activity_signals.get("has_subsidy_records"):
score += 1
reasons.append("公的支援の履歴がある")
if activity_signals.get("has_certification_records"):
score += 1
reasons.append("認定の履歴がある")
if has_customer_similarity:
score += 2
reasons.append("既存顧客と似た属性がある")
if has_relationship_path:
score += 2
reasons.append("紹介・顧問・パートナー接点がある")
return {
"score": score,
"priority": "A" if score >= 6 else "B" if score >= 3 else "C",
"reasons": reasons,
}
スコアは営業の判断を置き換えない。Aは「すぐ確認する」、Bは「今週レビューする」、Cは「キーワードや条件を見直す」という運用ラベルにする。
Data Waterfallを回すなら、CRMには次の項目を追加する。
| フィールド | 目的 |
|---|---|
| signal_source | EDINET、gBizINFO、求人、紹介など |
| signal_observed_at | 取得日 |
| signal_summary | 営業が読める短い仮説 |
| source_url | 元データへの参照 |
| review_status | 未確認、確認済み、保留、対象外 |
| review_note | 営業の確認結果 |
この設計にしておくと、スコアが外れた理由も蓄積できる。GTMエンジニアリングで最も価値があるのは、当たりリストを一度作ることではなく、外れた仮説を次のルール改善へ戻すことだ。
ここからは、架空のケースでData Waterfallの使い方を示す。数字は実績値ではなく、設計例として読む。
課題: 情報システム部門だけに営業しており、経営課題との接続が弱い。
| 層 | データ | 見るポイント |
|---|---|---|
| 課題 | EDINET | サイバー攻撃、情報漏えい、委託先管理などの記述変化 |
| 行動 | gBizINFO / 求人 | セキュリティ関連投資、IT人材採用、拠点拡大 |
| フィット | 既存顧客データ | 導入済み企業と似た業種・システム構成 |
| 接点 | 顧問 / パートナー | CIO、監査、リスク管理部門への入口 |
営業への受け渡しは、「御社は危ないです」ではなく、「公開資料ではこのリスク項目の記述が変わっています。社内ではどの部門が検討していますか」とする。
課題: 人事課題を広く訴求しているが、初回面談で話がぼやける。
| 層 | データ | 見るポイント |
|---|---|---|
| 課題 | EDINET | 人材確保、人的資本、人材育成、離職に関する記述変化 |
| 行動 | 求人 / gBizINFO | 採用職種、認定、補助金、研修関連の動き |
| フィット | 既存顧客データ | 拠点数、雇用形態、導入部門の近さ |
| 接点 | 既存顧客 / イベント | 人事責任者、経営企画、事業部門への入口 |
ここでは、認定の有無を単純な良し悪しにしない。制度整備、採用、育成、定着のどこが面談テーマになりそうかを分けて渡す。
課題: 「DXに関心がある企業」を広く追い、営業の優先順位がつかない。
| 層 | データ | 見るポイント |
|---|---|---|
| 課題 | EDINET / 適時開示 | サプライチェーン、設備投資、品質、生産性の記述変化 |
| 行動 | gBizINFO / 求人 | 製造、IT、データ人材の採用や投資履歴 |
| フィット | 既存顧客データ | 工場数、対象工程、基幹システムとの接続難度 |
| 接点 | 顧問 / 業界団体 | 工場長、製造企画、情報システム部門への入口 |
製造業では、課題があっても導入タイミングや既存設備の制約が大きい。GTMエンジニアは、営業へ「何を売るか」だけでなく「どの制約を先に聞くか」も渡す。
日本型GTMエンジニアリングでは、顧問ネットワークを「何となく紹介してもらう仕組み」にしない。Data Waterfallの結果と、関係性データを別々に管理し、必要なときだけ接続する。
紹介者に渡すメモは短い方がよい。
対象企業: 株式会社サンプル
見つけた公開シグナル: 有価証券報告書の事業リスクでサイバー対策の記述が増加
確認したい仮説: 監査・委託先管理を含むセキュリティ体制の見直しが進んでいるか
紹介してほしい相手: 情報システム、監査、リスク管理の責任者
お願いしたいこと: 初回15分の課題確認
「営業したいので紹介してください」ではなく、「この公開情報を見て、この問いを確認したい」と渡す。これにより、紹介者の信用を守りやすくなる。
顧問ネットワークは強いが、個人や関係性に関する情報を含む。管理ルールなしにスプレッドシートへ蓄積すると、後から使えなくなる。
最低限、次を決める。
| 項目 | 決めること |
|---|---|
| 利用目的 | 営業紹介、業界知見、イベント登壇など |
| 保管項目 | 氏名、元役職、得意領域、接点企業、利用可否 |
| 閲覧権限 | 営業全員か、担当者限定か |
| 更新責任 | 誰が接点の鮮度を確認するか |
| 削除手順 | 退任、辞退、利用停止時にどう削除するか |
GTMエンジニアリングでは、関係性データもプロダクトデータと同じく、権限と履歴を持って扱う。
一度に全てを作る必要はない。まず既存顧客で検証し、その後に自動化する。
やること:
ゴール: スコアを作る前に、公開データが営業会話に使えるかを確認する。
やること:
ゴール: 毎週の営業会議で、仮説リストを短くレビューできる状態を作る。
やること:
ゴール: 「データで仮説を作る -> 関係性で入口を探す -> 営業が確認する -> 結果を戻す」の循環を作る。
A. まずEDINET API公式ガイドで利用手順、認証、制限を確認する。PoCでは、対象企業を数社に絞り、有価証券報告書の取得と事業リスク抽出だけを試す。
A. gBizINFOは強い入力だが、それ単体で営業先を決めるのは危うい。補助金や認定の履歴は、購買意欲ではなく企業活動の痕跡として扱う。EDINET、求人、既存顧客データ、営業の確認結果と重ねる。
A. 最初は手作業でもよい。既存顧客を数社選び、公開資料から課題シグナルを読み、営業が使えたかを確認する。自動化は、シグナルが営業会話に使えると分かってからで十分だ。
A. EDINETの有価証券報告書を使う部分は、対象企業が限られる。未上場企業では、gBizINFO、求人、公式サイト、導入事例、イベント登壇、調達情報などを組み合わせる。ただし、データが薄い企業ほど、人の確認を増やす。
A. EDINETやgBizINFOの公開データを企業単位で読むだけなら、個人データを大量収集する設計とは異なる。ただし、顧問、紹介者、担当者名、接点履歴を保存する場合は、利用目的、閲覧権限、保管期間、削除手順を社内ルールとして定める。
A. 最初は売上ではなく、営業プロセスの手前で測る。たとえば、仮説リストの面談化率、初回面談で仮説が当たった割合、紹介依頼の承諾率、営業が「使える」と判断したシグナルの割合を見る。受注まで追うのは、その後でよい。
日本向けのGTMエンジニアリングは、海外ツールをそのまま真似ることではない。企業単位の公開データを読み、営業が確認できる仮説へ変換し、顧問や既存接点を含む入口へ受け渡す設計だ。
手順はシンプルでよい。
最初の一歩は、自動化ではない。既存顧客を数社選び、受注前に公開データで見えていたシグナルを読み直すことだ。そこで営業が使える仮説が見つかるなら、日本型GTMエンジニアリングは小さく始められる。
この記事の著者

代表取締役
早稲田大学卒業後、ソフトバンク株式会社にてAI活用やCEO直下案件のプロジェクトマネージャーに従事。その後、不動産スタートアップPit in株式会社の創業、他スタートアップでの業務改善・データ活用を経験後、2023年10月、株式会社ネクサフローを創業し代表取締役CEO就任。
次に読む

GTMを、売上を生む仕組みの設計図として整理。シグナル起点の営業、GTMエンジニアリング、紹介チャネルをどう組み合わせるか、日本で使える公開データ、改善サイクルの設計ポイントをまとめる。

GTMエンジニアを、営業 workflow を設計し続ける役割として読み解く。data foundation、signal 設計、activation、日本で使うデータ層の置き換え先を整理する。

GTM Alpha(GTMアルファ)とは、競合が持たないデータを活用し、競合ができない施策を実行することで得られる営業上の競争優位性である。金融用語のα(超過リターン)から転用されたこの概念を、GTMの3法則・日本市場のデータソース・実装ロードマップとともに解説する。