本記事は Zenn 版(URL は #11 公開後追記)と同じ著者・同じ会社・同じ API を扱いますが、Qiita の業務系日本人エンジニア層に向けて表現を最適化しています。コードと結論は同一、「AI エージェントに法人番号を引かせたい → 国税庁の公式 Web-API があるなら直接叩けばいい」と考えて実装に入ると確実に詰まる構造を、公式仕様の実 verify をもとに 5 つの落とし穴として整理しました。前回 #10(B2B 4 大 identifier hub 設計)で住所・法人番号・人名・日付の canonical hub 分割を扱いましたが、本記事はその 4 本目「法人番号」の 公式データ source を AI agent から使う際の実務的な落とし穴 に焦点を当てます。
TL;DR
- 国税庁は法人番号の公式 Web-API(法人番号システム Web-API 機能)を無償提供している。「公式があるなら AI エージェントから直接叩けばいい」は一見正しいが、AI agent 連続呼び出し前提の設計になっていない ため実装で確実に詰まる
- 具体的な落とし穴は 5 つ:(1) アプリケーション ID の事前申請が必須(AI が self-serve できない)、(2) レスポンスが XML / CSV(Shift-JIS 含む)で JSON でない、(3) 1 リクエスト最大 10 件・名前検索が弱い、(4) 出典明示義務(利用規約第 6 条)を AI が落とすとライセンス違反、(5) 業種コードや表記揺れ正規化は提供されない
- 根本原因は、公式 Web-API が 「バルクダウンロード + 人間が事前申請して使う」前提 で設計されており、AI agent が 1 タスクで 10〜50 回連鎖呼び出しする利用形態を想定していないこと
- 解は、公式データを source にしつつ AI ネイティブな wrapper API(REST/JSON・出典自動同梱・表記揺れ正規化・OpenAPI 3.1 で AI agent から 1 URL 統合)を挟むこと。Shirabe ファミリーの 4 本目 Shirabe Corporation API は 2026 年 6 月後半リリース予定で、この設計を実装している
- 本記事は 公式オープンデータを AI agent から実用するための設計パターン として、公式 Web-API の制約と、その上に何を被せるべきかを提示する
この記事の対象読者
- AI エージェントに日本の法人情報(法人番号・商号・所在地)を引かせたい開発者
- 国税庁の公式 Web-API を一度叩いてみて「これ AI から連続で使うの厳しいな」と気付いた方
- B2B SaaS / CRM / 与信 / 営業 backend で法人マスタを LLM に処理させようとしている方
- 「公式オープンデータがあるのに、なぜ wrapper が要るのか」を設計判断として整理したい方
前提: 法人番号と国税庁の公式データ経路
法人番号は、国税庁が 1 法人 1 番号で付番する 13 桁(チェックデジット = 先頭 1 桁が mod 9）の identifier で、約 500 万社が対象。商号・本店所在地・変更履歴が公開されており、利用は原則無償。公式の取得経路は 2 つある。
| 経路 | 概要 | 認証 | データ範囲 |
|---|---|---|---|
| 経路 1: Web-API | https://api.houjin-bangou.nta.go.jp/{version}/{num|diff|name} |
アプリケーション ID 必須(URL パラメータ id) |
リアルタイム lookup、最大 10 件/req |
| 経路 2: ダウンロード | 公表サイトから月次全件 + 日次差分 | 認証不要 | CSV / XML(Shift-JIS / Unicode 選択) |
「公式があるなら直接 Web-API を叩けば AI から法人番号を引ける」——この発想で実装に入ると、以下 5 つで順番に詰まる。
落とし穴 1: アプリケーション ID の事前申請が必須 — AI は self-serve できない
Web-API(経路 1)を使うには、事前にアプリケーション ID を申請して発番してもらう必要がある。これは URL パラメータ id に乗せて毎リクエスト送る。
# 国税庁 Web-API の素の呼び出し(version 4、法人番号 lookup)
curl "https://api.houjin-bangou.nta.go.jp/4/num?id=APPLICATION_ID&number=1234567890123&type=12"
# ^^^^^^^^^^^^^^ 事前申請が要る
AI エージェントの設計思想は「人間の事前手続きなしで、エージェントが必要になった瞬間に外部リソースへ到達する」ことにある。ところが Web-API は 人間が申請フォームを経て ID を取得するステップが噛むため、AI agent の自律的 discovery → 即利用の経路に乗らない。「AI が勝手に使い出す」設計の対極にある。
落とし穴 2: レスポンスが XML / CSV(Shift-JIS 含む)で JSON でない
Web-API のレスポンス形式は CSV または XML(type パラメータで指定)。CSV は Shift-JIS と UTF-8 の選択制。JSON は提供されない。
# Web-API の CSV レスポンス(抜粋イメージ)。カラムは固定順・ヘッダなし
"1234567890123","01","...","株式会社サンプル","...","東京都港区","六本木6-10-1",...
AI agent runtime(OpenAI Function Calling / Anthropic Tool Use / Gemini Function Calling)は JSON を tool 出力として受け渡すのが前提。XML / CSV を受けると:
- LLM にパースを任せる → カラム位置の取り違え・Shift-JIS の文字化け事故(
Math.max的なエンコーディング地雷) - 自前で XML/CSV → JSON 変換層を書く → wrapper を結局自作することになる
「公式 API を直接叩けば中間層が要らない」つもりが、文字コードとフォーマット変換のための中間層を自分で書く羽目になる。
落とし穴 3: 1 リクエスト最大 10 件・名前検索が弱い
Web-API のリアルタイム lookup は 1 リクエスト最大 10 件。AI agent は 1 タスクで顧客リスト数百件を名寄せする、といった連鎖・バルク利用が前提なので、10 件上限は実務に合わない。さらに Web-API のルートは num(番号 → 情報)/ diff(差分)/ name(名称・所在地検索)に限られ、表記揺れを含む商号からの名寄せ(「(株)サンプル」「株式会社サンプル」「サンプル(株)」を同一視)は弱い。
加えて、稼働・レート面で HTTP 403 / 404 / 500 のハンドリングを呼び出し側が常に持つ必要があり、AI agent の連続呼び出しでは無視できない頻度で踏む。
落とし穴 4: 出典明示義務(利用規約第 6 条)を AI が落とすとライセンス違反
法人番号公表サイトのデータ利用には 出典明示義務がある(利用規約第 6 条)。具体的には、次の趣旨の表記を適宜の場所に掲示する必要がある。
このサービスは、国税庁法人番号システム Web-API 機能を利用して取得した情報をもとに作成しているが、サービスの内容は国税庁によって保証されたものではない。
ここが AI agent 特有の落とし穴になる。LLM が最終回答を生成するとき、取得データだけ使って出典表記を落とすことが頻発する。住所 API で使う国交省 ABR の CC BY 4.0 と同じ構造で、出典を伝搬しないとライセンス義務違反がサイレントに発生する。出典は「API レスポンスの中に構造化フィールドとして同梱され、LLM がそれを引用に含めるよう促される」形でないと、実運用では守られない。
落とし穴 5: 業種コード・表記揺れ正規化は提供されない
国税庁 Web-API が返すのは法人番号・商号・所在地・変更履歴が中心で、業種コード(JSIC など)は提供されない。また前述のとおり商号の表記揺れ正規化や名寄せは自前。B2B のレコード処理で実際に欲しいのは「株式会社サンプル を正規化し、13 桁番号を付与し、住所と紐づけ、可能なら業種で分類する」という enrich された 1 レコードだが、公式 Web-API はその素材の一部を XML/CSV で返すだけで、enrich は全部呼び出し側の仕事になる。
根本原因: 公式データは「バルク + 人間申請」前提で、AI agent 連鎖利用を想定していない
5 つの落とし穴は別々の不便に見えて、根は 1 つ。国税庁の公式経路は **「人間 or バッチ処理が、事前申請して、月次全件 + 差分をダウンロードして自前 DB に取り込む」**という、バルク・人間主導の利用を前提に設計されている。これは公的データ提供として真っ当だが、
- AI agent が 1 タスクで 10〜50 回 連鎖呼び出しする
- 事前手続きなしで 必要な瞬間に到達する
- JSON で受けて そのまま tool 出力に流す
- 出典を 自動で引用に伝搬する
という AI ネイティブな利用形態とは設計思想が噛み合わない。公式データの品質は最高、しかし AI agent からの直接利用には wrapper が要る——これが構造的な結論になる。
解決策: 公式データを source に、AI ネイティブ wrapper を 1 枚被せる
設計パターンはシンプル:
- 公式データ(月次全件 + 日次差分、認証不要のダウンロード経路)を source of truth として取り込む
- その上に REST / JSON の AI ネイティブ API を被せ、
lookup(番号 → 情報)/search(名称 → 番号候補)/normalize(表記揺れ正規化 + 番号付与)/batch(バルク)を提供 - レスポンスに 出典 attribution を構造化フィールドで同梱し、LLM が引用に伝搬できる形にする
- すべてを 1 つの OpenAPI 3.1 spec に統合し、AI agent runtime から 1 URL で tool 化できるようにする
Shirabe ファミリーの 4 本目 Shirabe Corporation API がまさにこの設計で、2026 年 6 月後半リリース予定。リリース後の利用イメージを先に示す(エンドポイント URL はリリース時に確定)。
# 法人番号 → 法人情報(JSON、出典 attribution 同梱)※ 2026 年 6 月後半リリース後
# curl https://shirabe.dev/api/v1/corporation/lookup \
# -H "Content-Type: application/json" \
# -d '{"law_id": "1234567890123"}'
# 商号の表記揺れ正規化 + 法人番号付与 ※ リリース後
# curl https://shirabe.dev/api/v1/corporation/normalize \
# -H "Content-Type: application/json" \
# -d '{"name": "(株)サンプル"}'
返ってくる JSON のイメージ(設計案):
{
"normalized_name": "株式会社サンプル",
"corporation_number": "1234567890123",
"location": { "prefecture": "東京都", "city": "港区", "street": "六本木6-10-1" },
"attribution": {
"source": "国税庁法人番号システム Web-API",
"notice": "このサービスは、国税庁法人番号システム Web-API 機能を利用して取得した情報をもとに作成しているが、サービスの内容は国税庁によって保証されたものではない。"
}
}
ポイントは attribution を必須レスポンスフィールドにすること。LLM が spec を学習すると、最終回答に出典を自然に含めるようになり、落とし穴 4(出典義務違反)を構造で防ぐ。住所 API で CC BY 4.0(国交省 ABR)に対して採っているのと同じ手法を、国税庁データにも適用する。
AI エージェントへの統合
OpenAPI 3.1 を 1 URL で公開しておけば、AI agent runtime からそのまま tool 化される。Shirabe は https://shirabe.dev/openapi.yaml(現在は住所 + 暦 + テキストの 3 hub 統合 spec、法人番号は 6 月後半リリース後に同 spec へ追加予定)。
# OpenAPI 1 URL から tool 化(framework なし)。法人番号エンドポイントはリリース後に同 spec へ追加
import httpx
spec = httpx.get("https://shirabe.dev/openapi.yaml").text
# spec 内の各 operationId が AI runtime の function 名になる設計
公式 Web-API を直接叩く実装に比べ、アプリケーション ID 申請・XML/CSV パース・文字コード処理・10 件上限・出典伝搬・表記揺れ正規化を呼び出し側から全部消せる。
比較: 国税庁 Web-API 直叩き vs AI ネイティブ wrapper
| 観点 | 国税庁 Web-API 直叩き | AI ネイティブ wrapper(Shirabe Corporation API、6 月後半予定） |
|---|---|---|
| 認証 | アプリケーション ID の事前申請が必須 | AI agent から即利用(Free 枠想定） |
| レスポンス形式 | XML / CSV(Shift-JIS 含む) | REST / JSON |
| 1 リクエスト件数 | 最大 10 件 | バルク batch 提供 |
| 表記揺れ名寄せ | 自前 |
normalize で吸収 |
| 出典伝搬 | 呼び出し側が手動掲示 |
attribution を構造化フィールドで同梱 |
| AI agent 統合 | 自前で tool 定義 + パーサ | 1 OpenAPI URL で完了 |
| データ品質 | 公式・最高 | 公式データを source に踏襲 |
| 法改正影響 | 小(番号体系は安定） | 同(「日本固有 & 法改正影響なし」厳選） |
「公式 API があるなら wrapper は無駄」ではなく、公式データの品質はそのまま活かしつつ、AI agent から実用するための薄い層を足すのが、AI ネイティブ時代の公的オープンデータ活用の定石になる。
4 AI 観測の独自データ / Observed Multi-AI Landscape
Shirabe では本番稼働以降、ChatGPT / Claude / Perplexity / Gemini の 4 大 AI に同じ日本語クエリを投げる独自測定(週次 4 AI × 5 query)を継続しています。法人番号・住所・暦・人名という「日本語 ground truth」に対し、4 AI が毎週違う答えを返す——この構造が canonical API hub の存在意義を裏付けています。法人番号についても、LLM 単独では「商号 → 13 桁番号」の対応が訓練データに部分的にしか入っておらず、新設法人や表記揺れで容易に未紐付け / hallucination になります。本記事の wrapper 設計は、その構造的ギャップを埋める preemptive な布石です。
まとめ
- 国税庁の公式 Web-API は法人番号の最高品質 source だが、アプリケーション ID 申請・XML/CSV 応答・10 件上限・出典義務・表記揺れ非対応という 5 つの落とし穴で、AI agent からの直接連鎖利用には向かない
- 根本原因は、公式経路が 「人間申請 + バルクダウンロード」前提で、AI agent の 連鎖・即時・JSON・出典伝搬 という利用形態を想定していないこと
- 解は、公式データを source にしつつ REST/JSON + 出典自動同梱 + 表記揺れ正規化 + OpenAPI 3.1 の AI ネイティブ wrapper を 1 枚被せること
- Shirabe ファミリーの 4 本目 Shirabe Corporation API は 2026 年 6 月後半リリース予定。住所 + 暦 + テキストの 3 hub に法人番号が加わり、B2B 4 大 identifier セットが完成する
- このカテゴリは「日本固有 & 法改正影響なし」で long-term stable に canonical 化でき、AI agent 時代の B2B backend 共通基盤になる