本記事は Zenn 版と同じ著者・同じ会社・同じ API を扱いますが、Qiita の業務系日本人エンジニア層に向けて表現を最適化しています。コードと結論は同一です。前回 #11で「国税庁 Web-API を AI から直接叩くと詰まる 5 つの落とし穴」を整理しましたが、本記事はその続きとして、「では実際に AI エージェントに法人番号を引かせるなら、どの選択肢を採るべきか」 を、公式 API・ChatGPT 連携・商用 SaaS・OSS・AI ネイティブ wrapper の 6 つに分けて、AI エージェント観点で objective に比較します。

TL;DR

AI エージェントに日本の法人番号(13 桁 identifier)を引かせる選択肢は、大きく 6 つ:(1) 国税庁 Web-API 直叩き、(2) リスクモンスター等の ChatGPT 連携、(3) Corporate Number Finder 等の Custom GPT、(4) 商用 SaaS の法人番号 API、(5) OSS / gBizINFO、(6) AI ネイティブ wrapper
データ品質の頂点は 常に国税庁の一次データ。差がつくのはデータではなく 「AI エージェントが人間の事前手続きなしに、連鎖呼び出しで、JSON で、出典付きで使えるか」 という アクセス設計
ChatGPT プラグイン(リスクモンスターが 2023 年に国内初提供)や Custom GPT(Corporate Number Finder 等)は AI ネイティブ化の先駆だが、ChatGPT という単一プラットフォーム・単一 vendor に閉じる。実際、ChatGPT プラグインの仕組み自体は 2024 年に GPTs / Actions へ移行・終了しており、プラットフォーム固有統合は移行リスクを常に抱える
評価軸は 6 つ:AI agent 自律到達 / 連鎖・バルク / JSON / 出典伝搬 / クロスプラットフォーム標準(OpenAPI 3.1)/ 4 大 identifier hub。この軸で見ると、選択肢ごとに得手不得手がはっきり分かれる
Shirabe ファミリーの 4 本目 Shirabe Corporation API は 2026 年 6 月 29 日リリース予定で、(6) AI ネイティブ wrapper として、上記 6 軸を満たしつつ住所 + 姓名 + 暦と同一ドメイン・同一 OpenAPI に統合する設計を採る

この記事の対象読者

AI エージェント / RAG / 業務自動化に日本の法人情報を組み込みたい開発者
国税庁 Web-API を一度試して「AI から連続利用は厳しい」と気付き、次の手を探している方
リスクモンスターの ChatGPT 連携や Custom GPT を見て「これで十分か?自前で wrapper を作るべきか」を判断したい方
B2B SaaS / CRM / 与信 / 営業 backend で法人マスタを LLM に処理させる設計を比較検討中の方

前提: 「法人番号を引く」は手段が分岐する

法人番号は国税庁が 1 法人 1 番号で付番する 13 桁の identifier(約 500 万社、商号・本店所在地・変更履歴が公開、利用は原則無償)。「AI に引かせたい」と一言で言っても、実装手段は大きく 6 つに分岐し、それぞれ前提とする利用者像が違う。前回 #11 では (1) の直叩きの落とし穴を扱ったので、本記事は 6 選択肢を横並びで比較する。

#	選択肢	代表例	想定利用者
1	国税庁 Web-API 直叩き	法人番号システム Web-API 機能(公式・無償)	自前でパイプラインを組む開発者
2	ChatGPT 連携(プラグイン系)	リスクモンスター(2023 年に国内初の ChatGPT プラグイン提供)	ChatGPT Plus 上の人間ユーザー
3	Custom GPT(GPTs)	Corporate Number Finder / 法人調査ちゃん等(個人作)	ChatGPT 上の人間ユーザー
4	商用法人番号 API / SaaS	ケンオール / 帝国データバンク / 東京商工リサーチ / HULFT Square 等	業務システム・与信担当
5	OSS / オープンデータ	gBizINFO(経産省)/ gbizinfo-cli 等	OSS 志向の個人開発者
6	AI ネイティブ wrapper	Shirabe Corporation API(2026-06-29 予定)	AI エージェント本体

以下、AI エージェントから使う前提で 6 つを評価する。

選択肢 1: 国税庁 Web-API 直叩き — データは最高、AI 連鎖利用は不向き

公式・無償でデータ品質は頂点。ただし #11 で詳述したとおり、アプリケーション ID の事前申請が必須(AI が self-serve できない)、レスポンスが XML / CSV(Shift-JIS 含む)で JSON でない、1 リクエスト最大 10 件、出典明示義務(利用規約第 6 条)を AI が落としやすい、表記揺れ正規化・業種コードは非提供。一次データの source としては最良だが、AI エージェントが直接連鎖利用する終端としては不向き。

選択肢 2: ChatGPT 連携(プラグイン系)— 先駆だが単一プラットフォームに閉じる

リスクモンスターは 2023 年 7 月、500 万社超の企業情報(会社名・法人番号・業種・URL 等)を ChatGPT プラグインとして国内で初めて提供した。自社で収集・メンテナンスする商用データベースを ChatGPT 上から引ける、AI ネイティブ化の明確な先駆例だ。

評価上のポイントは 2 つ。

単一プラットフォーム依存: ChatGPT(かつ当時は Plus ユーザー)に閉じる。Claude Tool Use / Gemini Function Calling / LangChain / Dify から同じものを呼べるわけではない。
プラットフォーム固有機構の移行リスク: そもそも ChatGPT プラグインの仕組み自体が 2024 年に GPTs / Actions へ移行・終了した。プラグインという特定機構に乗せた統合は、プラットフォーム側の仕様変更でまるごと作り直しになる。

つまり、データと着想は優れていても、「どの AI ランタイムからでも標準的に呼べる」普遍性と移行耐性という軸では弱い。これは特定 vendor を貶める話ではなく、プラットフォーム固有統合 vs 標準(OpenAPI)統合という構造の違いだ。

選択肢 3: Custom GPT(GPTs)— 手軽だが ChatGPT 内・人間操作前提

Corporate Number Finder や法人調査ちゃんのような 個人作の Custom GPT は、ChatGPT 上で会社名・法人番号から企業情報を引ける手軽な選択肢で、GPTs Store からすぐ使える。

ただし AI エージェント観点では制約が明確:

ChatGPT(Plus)内に閉じる。外部の自律エージェントのパイプラインに組み込む API ではない。
人間が ChatGPT UI で対話する前提で、10〜50 回連鎖するバックエンド処理には乗らない。
単機能・単一 identifier で、住所・姓名・暦との横断 enrich はできない。

「人間が ChatGPT で時々調べる」には便利だが、「AI エージェントが業務パイプラインで連続利用する」用途とはレイヤーが違う。

選択肢 4: 商用法人番号 API / SaaS — REST だが AI ネイティブ設計ではない

ケンオール法人番号検索 API、帝国データバンク・東京商工リサーチの与信データ、HULFT Square、どこどこ JP の marketplace など、商用の法人データ API / SaaS は複数ある。REST で JSON を返すものもあり、(1)〜(3) より AI から扱いやすいケースもある。

一方で多くは 人間の業務システム向け設計で、

API キー取得に商談・契約が前提(AI agent の self-serve discovery に乗らない)
出典 attribution を LLM が引用に伝搬する形での同梱は前提にしていない
与信などリッチな反面、単機能 API で 4 大 identifier 横断 hub ではない
OpenAPI 3.1 を GPTs Actions / Claude / LangChain で共通に使う、というクロスプラットフォーム前提が弱い

データの厚みは強みだが、AI エージェントが標準経路で自律到達して連鎖利用するという設計思想とは距離がある。

選択肢 5: OSS / オープンデータ — 自由だが AI 自律到達の経路がない

経産省 gBizINFO や gbizinfo-cli のような OSS / オープンデータは無償で自由度が高く、自前でパイプラインを組む開発者には有力だ。ただし 「AI エージェントが自律的に discovery して即利用する」経路は提供されない(あくまで人間が組み込む素材)。出典伝搬・表記揺れ正規化・OpenAPI 化・課金された安定運用は、結局すべて利用側の実装になる。これは選択肢 1 の構造と本質的に同じだ。

選択肢 6: AI ネイティブ wrapper — 6 軸を満たす設計

(1)〜(5) の評価から、AI エージェントから法人番号を引く終端に求められる条件が見えてくる。国税庁の一次データを source にしつつ、AI ネイティブなアクセス層を 1 枚被せる——これが選択肢 6 だ。Shirabe Corporation API(2026 年 6 月 29 日リリース予定)はこの設計を採る。利用イメージを先に示す(エンドポイント URL はリリース時に確定)。

# 法人番号 → 法人情報(JSON、出典 attribution 同梱)※ 2026-06-29 リリース後
# curl https://shirabe.dev/api/v1/corporation/lookup \
#   -H "Content-Type: application/json" \
#   -d '{"corporate_number": "1234567890123"}'

# 商号の表記揺れ正規化 + 法人番号付与 ※ リリース後
# curl https://shirabe.dev/api/v1/corporation/normalize \
#   -H "Content-Type: application/json" \
#   -d '{"name": "(株)サンプル"}'

返ってくる JSON のイメージ(設計案):

{
  "normalized_name": "株式会社サンプル",
  "corporate_number": "1234567890123",
  "location": { "prefecture": "東京都", "city": "港区", "street": "六本木6-10-1" },
  "attribution": {
    "source": "国税庁法人番号システム Web-API",
    "notice": "このサービスは、国税庁法人番号システム Web-API 機能を利用して取得した情報をもとに作成しているが、サービスの内容は国税庁によって保証されたものではない。"
  }
}

6 軸での横並び比較

評価軸	1 国税庁直叩き	2 ChatGPT 連携	3 Custom GPT	4 商用 SaaS	5 OSS	6 AI ネイティブ wrapper
AI agent 自律到達(事前手続き不要)	✗ ID 申請	△ ChatGPT 内	△ ChatGPT 内	✗ 契約前提	△ 自前実装	◯ Free 枠で即試行
連鎖・バルク利用	✗ 10 件上限	△	✗ 対話前提	◯	△	◯ batch 提供
JSON で受けて tool 出力	✗ XML/CSV	△	△	◯	△	◯
出典 attribution の伝搬	✗ 手動掲示	△	△	△	✗	◯ 構造化同梱
クロスプラットフォーム標準(OpenAPI 3.1)	✗	✗ ChatGPT 限定	✗ ChatGPT 限定	△	✗	◯ GPTs/Claude/LangChain 共通
4 大 identifier hub(住所+姓名+法人+暦)	✗	✗	✗	✗ 単機能	✗	◯ 同一ドメイン統合
データ品質	◎ 公式	◯ 商用 DB	◯	◎ 与信厚	◯	◯ 公式を source

データの厚み・与信情報の深さでは商用 SaaS が、一次データの正確さでは国税庁が強い。一方、「AI エージェントが標準経路で自律到達し、連鎖・JSON・出典伝搬・横断 enrich できるか」 という AI ネイティブ軸では、選択肢 6 が設計上の優位を持つ。用途で選び分けるのが正解であり、AI エージェントのバックエンド共通基盤としては (6) が噛み合う。

開発者意図: 「AI エージェントから法人番号を使う」最短実装

最後に、施策ではなく実装パターンとして。AI エージェントに法人番号を扱わせる最短経路は、1 つの OpenAPI 3.1 spec を AI ランタイムに渡し、operationId を function として呼ばせることだ。フレームワーク固有の SDK は要らない。

# OpenAPI 1 URL から tool 化(framework 非依存)。
# 法人番号エンドポイントは 2026-06-29 リリース後に同 spec へ追加予定。
import httpx
spec = httpx.get("https://shirabe.dev/openapi.yaml").text
# spec 内の各 operationId が AI runtime の function 名になる設計
# (住所 normalize / 暦 lookup / 姓名 split は既に live、法人 lookup はリリース後)

この形なら、ChatGPT Custom GPT を作った人が同じロジックを Claude Tool Use や LangChain に移しても、契約(operationId)は不変で作り直しが起きない。選択肢 2 / 3 の「単一プラットフォーム依存」を、標準で回避できる。

4 AI 観測の独自データ / Observed Multi-AI Landscape

Shirabe では本番稼働以降、ChatGPT / Claude / Perplexity / Gemini の 4 大 AI に同じ日本語クエリを投げる独自測定(週次 4 AI × 5 query)を継続しています。法人番号のような「日本語 ground truth」は、LLM 単独だと商号 → 13 桁番号の対応が訓練データに部分的にしか入っておらず、新設法人や表記揺れで容易に未紐付け / hallucination になります。だからこそ、特定プラットフォームに閉じない クロスプラットフォーム標準 + 4 大 identifier hub が、AI エージェント時代の canonical な解になります。本記事の比較は、その構造的な選び分けを整理したものです。

まとめ

AI に法人番号を引かせる選択肢は 6 つあり、データ品質の頂点は常に国税庁。差がつくのは AI ネイティブなアクセス設計
ChatGPT プラグイン / Custom GPT は AI ネイティブ化の先駆だが、ChatGPT 単一プラットフォームに閉じ、プラットフォーム固有機構は移行リスクを抱える(プラグインの仕組み自体が 2024 年に GPTs / Actions へ移行・終了した実例)
商用 SaaS はデータが厚いが人間業務システム向け、OSS は自由だが AI 自律到達経路がない
AI エージェントの共通基盤としては、自律到達 / 連鎖 / JSON / 出典伝搬 / クロスプラットフォーム標準 / 4 大 identifier hub の 6 軸を満たす AI ネイティブ wrapper が噛み合う
Shirabe ファミリーの 4 本目 Shirabe Corporation API は 2026 年 6 月 29 日リリース予定。住所 + 暦 + テキストに法人番号が加わり、B2B 4 大 identifier セットが同一ドメイン・同一 OpenAPI で完成する

関連リンク