「また会社名で検索して、住所と資本金をコピペするのか」。問い合わせが来るたびに、その独り言が漏れる。代表者名も拾っておく。設立年も。同じ作業を新規リードの数だけ繰り返す（これ、営業活動じゃなくて写経では）。
この手入力、法人番号さえ分かれば大部分を自動化できる。経済産業省が運営するgBizINFOは、法人番号や企業名から基本情報を無料で返す公開APIを持っている。取得できるのは住所・資本金・従業員数・設立年月日・代表者名・事業概要・企業URLといった、まさに営業リストの空欄そのものだ。
この記事では、この公開APIを使って企業情報を自動補完する実装と、集めた情報から「この会社はIT投資に積極的か」をAIに仕分けさせる考え方をまとめる。
この記事で扱うこと
- 法人番号1つで企業基本情報を取得する公開API呼び出しの実装
- 社名しか分からないときの「検索 → 候補確認 → 確定」という2段階フローと、なぜ1段階では済まないか
- 集めた情報からIT投資意欲を仕分け、課題仮説を立てる考え方
- サンドボックス環境やCIから外部APIを直接叩いたときにハマった落とし穴
前提：gBizINFOという公開データベース
gBizINFOは、国が保有する法人の実績情報（登記情報・許認可・表彰・補助金・調達実績など）を法人番号単位で公開しているサービスだ。企業側が能動的に登録しなくても、行政保有データをもとに情報が載っている場合がある。
利用にはAPIトークンが要るが、利用申請ページから無料で発行できる。リクエストには発行されたトークンを認証ヘッダーに載せる。
curl -H "X-hojinInfo-api-token: ${GBIZ_API_TOKEN}" \
-H "Accept: application/json" \
"https://info.gbiz.go.jp/hojin/v1/hojin/1234567890123"
1点、書いている時点でのタイミング事情を共有しておく。gBizINFOは2026年1月に次期システムへ更新されており、現行のREST API v1は将来的に提供終了しv2への移行が案内される見込みだが、具体的な終了時期は公式に確認できなかった。エンドポイントの細部は今後変わりうるので、実装前に必ずAPI仕様ページで現在のバージョンと終了予定時期を確認してほしい。この記事のコード例はv1のパス構造に基づいている。
実装1：法人番号が分かっている場合の自動補完
法人番号（13桁の数字）が既に分かっているなら、話は単純だ。パスに法人番号を渡すだけで基本情報がまとめて返ってくる。
curl -H "X-hojinInfo-api-token: ${GBIZ_API_TOKEN}" \
"https://info.gbiz.go.jp/hojin/v1/hojin/{法人番号}"
返ってくるJSONのフィールドを、営業リストの入力項目にそのままマッピングできる。
| gBizINFOのレスポンスフィールド | 営業リストで埋める項目 |
|---|---|
corporate_number | 法人番号 |
location | 所在地 |
capital_stock | 資本金 |
employee_number | 従業員数 |
date_of_establishment | 設立年月日 |
business_summary | 事業概要 |
company_url | 企業HP |
representative_name | 代表者名 |
社内の営業支援ツールでも、これと同じ発想で新規企業を追加した際に自動補完させている。住所と資本金を手打ちしていた時間がそのまま浮いた（コピペ職人からの卒業、正直ちょっと感動した）。ただし実務では取得した候補をそのまま確定はせず、一度人間に見せてから保存する運用にした。理由は次の章で触れる。
さらに、法人番号が分かっていれば同じ番号を使って別のサブリソースも引ける。例えば /hojin/v1/hojin/{法人番号}/subsidy は補助金の交付実績、/hojin/v1/hojin/{法人番号}/workplace は平均年齢・勤続年数・残業時間・女性比率といった職場情報を返す。この2つは実際に後段の「投資意欲の仕分け」で使う材料になる（財務情報や特許・調達実績など他のカテゴリも法人番号ベースの別サブリソースとして提供されているので、必要に応じて仕様ページで確認するとよい）。
実装2：社名しか分からない場合は2段階にする
問い合わせフォーム経由のリードだと、法人番号どころか正式な社名すら怪しいことがある（「株式会社」の有無、旧字体、スペースの有無…）。この場合は名前で検索してから確定させる、2段階のフローが要る。
curl -H "X-hojinInfo-api-token: ${GBIZ_API_TOKEN}" \
"https://info.gbiz.go.jp/hojin/v1/hojin?name=株式会社サンプル物産&limit=5"
ここで即座に先頭の候補を採用してはいけない。同名・類似名の法人は普通に複数存在するし、表記ゆれで的外れな法人がヒットすることもある。だから実装では「候補が見つかったらユーザーに確認（複数候補の場合は選択）」という一手間を挟んでいる。地味だが、これを省くと違う会社の資本金を営業リストに書き込む事故になる（先方に「御社の資本金、隣の会社のを見てました」とはまあ、口が裂けても言えない）。
候補が見つからないときは自動補完を諦めて手入力に戻すだけでいい。無理に近い候補を確定させるくらいなら、空欄のまま「後で埋める」を選んだほうが事故が少ない。
IT投資積極度をAIで仕分ける
企業の基本情報が埋まったら、次にやりたくなるのは「この会社、営業として優先度高い？」の一次判断だ。ここでAIを絡める。
判断材料にするのは、ここまでで取得した補助金交付履歴・職場情報に加えて、企業のニュース掲載状況や採用ページの求人内容。これらを集めた上で、次のようなルールでIT投資への積極度を三段階に仕分ける。
| 判定 | 条件 |
|---|---|
| 高 | 補助金取得履歴あり + IT関連ニュースあり + DX/情シス求人あり（2つ以上該当） |
| 中 | 上記のいずれか1つに該当 |
| 低 | いずれにも該当しない |
判定だけでなく、そこから一歩踏み込んで「どんな課題を抱えていそうか」の仮説まで立てたい。これは単純な条件分岐では書きにくいので、集めたシグナルをまとめてAIに渡し、次のような観点で言語化させている。
- 従業員数・業種・事業概要から、組織規模に応じて起きやすい課題を推定する
- 求人情報からIT人材不足や体制構築の課題を推定する
- ニュースや公開情報から、既に着手している取り組みと手つかずの領域を推定する
数値の条件分岐（積極度の高中低）はコードで確定的に判定し、文章の解釈が要る部分（課題仮説）だけをAIに任せる、という役割分担にしているのがポイントだ。全部をAI任せにすると同じ入力でも判定がぶれるし（気分屋か）、全部を条件分岐にすると求人票やニュース記事の自由文を読み解けない（空気の読めなさもここまでくると清々しい）。
運用でハマった落とし穴：サンドボックスから直接APIを叩くと失敗する
ここからは実装より一段下、実行環境の話。CIやAIエージェントのサンドボックス実行環境から、この手の外部APIを直接呼ぶ構成にすると、コードは正しいのに通信そのものが落ちることがある。
実際に踏んだのは2種類の失敗モードだった。1つは、サンドボックス内の証明書検証がOS側のキーチェーンにアクセスできず、TLSハンドシェイクの時点で失敗するパターン。エラーメッセージだけ見ると「通信が拒否された」ように見えるが、実態は証明書検証の手前でブロックされている。
もう1つは、宛先ドメインが通信許可リストに入っていないケース。この場合はハンドシェイクにすら進まず、fetch failed のような素朴な形でブロックされる。同じ「外部APIが呼べない」でも原因が違うので、エラーメッセージだけで判断せず両方を疑ったほうがいい。
同じ構成のサンドボックス化を進めていたときには、認証情報を読むための設定ファイル自体がアクセス制限で読めず、空のフォールバック先に書き込んでしまうという別の事故も経験した。外部APIを呼ぶスクリプトをサンドボックス環境に持ち込むときは、(1) 通信先ドメインの許可リスト登録、(2) 認証情報ファイルの読み取り許可、(3) TLS証明書検証の可否、の3点を個別にチェックする価値がある。1つ直しても残り2つで詰まる、というのが実際に起きたことだ（モグラ叩き、こちらモグラ3匹。いや、そろそろ勘弁してほしい）。
| 症状 | 疑うべき原因 |
|---|---|
| TLSハンドシェイクの時点でエラー | サンドボックス内から証明書検証（OS keychain）にアクセスできない |
fetch failed で素朴に失敗 | 宛先ドメインが通信許可リストに未登録 |
| APIトークンが空扱いになる | 認証情報を読むファイルがサンドボックスの読み取り制限に引っかかっている |
対処自体は難しくない。通信先ドメインを許可リストに追加し、この種の外部API呼び出しだけサンドボックスの外で実行する設定に切り出せば動く。ただしこれは「サンドボックスを緩める」というより「どの処理が外部ネットワークに依存しているかを明示的に切り分ける」作業に近い。あとから気づくより、外部APIを組み込む設計の最初の段階でチェックリストに入れておいたほうが早い。
まとめ
法人番号は、営業リストの手入力を減らすための最短経路になる。gBizINFOのような公開APIと組み合わせれば、住所・資本金・従業員数といった基礎情報はコードで埋まる領域になり、人間が時間を使うべきは「候補をどれに確定するか」の一手間と、「この会社に何を提案するか」という仮説づくりに絞り込める（コピペに溶けていた時間が、考える時間に化けるだけの話だ）。
自動化できる部分と、人間の判断が要る部分を混ぜたまま実装すると、事故が起きたときにどちらが原因か切り分けづらくなる。今回でいえば「候補確定は人間」「積極度の閾値判定はコード」「課題の言語化はAI」という役割分担がそれに当たる。自分の業務でも、外部データで自動的に埋まる項目と、人が最後に見るべき項目を先に線引きしてから実装に入ると、後から手戻りが少ない。
