BUILD VS BUY
国税庁APIを自作する場合と、Bango APIを使う場合の責務比較
国税庁の法人番号Web-APIとインボイスWeb-APIは、申請すれば無料で利用できます。自分で組み込むこともできます。
判断が要るのは「作れるかどうか」ではありません。統合・差分同期・データ品質・名寄せ・仕様変更への追従を、この先も自社で持ち続けるかどうかです。
このページでは、自作したときに利用側が持つ責務と、Bango APIが引き受ける範囲を並べます。料金の大小ではなく、誰が何を持ち続けるかで比べてください。
WHEN TO BUILD
国税庁APIを直接使うのが合理的なケース
次のような使い方なら、国税庁のWeb-APIをそのまま使うのが素直な選択です。間にBango APIを挟む必要はありません。
- 法人情報とインボイス登録情報の、どちらか一方だけあれば足りる
- 扱う件数が少なく、その都度の単発取得で足りる
- 継続的な変更検知や、自社DBへの同期が要らない
- アプリケーションIDの申請と発行を待てる
- 国税庁の利用規約・利用条件の範囲で完結する
- 加工前の一次情報をそのまま扱いたい
この範囲であれば、外部サービスを足すほうが手数は増えます。以降は、これに当てはまらない場合の話です。
WHAT YOU OWN
自作する場合に必要になること
最初の1コールを通すところまでは、公開されている手順のとおりに進みます。責務として残るのは、そのあと継続して運用に載せる段階です。以下は実際に組み込んで運用した過程で必要になった作業です。
アプリケーションIDを申請する
国税庁のWeb-APIを呼ぶには、まずアプリケーションIDの取得が要ります。必要な手続きは、どのWeb-APIをどの順で使うかで変わります。法人番号Web-API用に取得したIDでインボイスWeb-APIも使いたい場合は、機能の追加申請と承認をもう一度挟みます。発行までの目安は国税庁の案内に示されていますが、実際にかかる期間はケースによって変わります。開発の着手時期を、この待ち時間から逆算する必要があります。
出典: curlで試した記録
2つのAPIを統合する
法人情報は法人番号Web-API、インボイス登録情報はインボイスWeb-APIと、取得先が分かれています。1つの企業について両方を返したいなら、2回呼び出して結果を突き合わせる処理が要ります。T番号は、法人であれば「T + 法人番号13桁」ですが、個人事業者や人格のない社団等の13桁は法人番号ではありません。Tを外せば必ず法人番号になる、という前提では処理できないケースがあります。
出典: curlで試した記録
XMLとJSONの差異を吸収する
法人番号Web-API（Ver.4）が返せるのはCSVとXMLで、JSONはありません。インボイスWeb-API（Ver.1）ではJSONを選べます。2026-08-27に実測した際のContent-Typeは、それぞれ application/xml;charset=UTF-8 と application/json;charset=UTF-8 でした。フィールドの持ち方も違います。登録番号のキーは registratedNumber、値のない項目は null ではなく空文字で返り、住所は分割されたフィールドと1つの文字列に分かれます。同じ企業でも updateDate の値は両APIで一致しません。これらを1つのデータモデルへ揃える変換層が要ります。
出典: curlで試した記録
差分を同期し続ける
両APIとも期間を指定した差分取得を備えているため、全企業を1件ずつ再取得する必要はありません。ただし差分は件数が多いと分割されて返ります。2026-08-26の1日分を取得したところ、法人番号側は2,257件で2分割（1レスポンスあたり最大2,000件）、インボイス側は法人に絞っても644件で2分割（同 最大500件）でした。分割の有無を確認して全ページを取り切り、取り切ってから同期位置を進める。途中で失敗したときの再開位置と、二重適用を避ける仕組みも要ります。
出典: curlで試した記録
遅れて掲載されたデータを回収する
差分に載った日付と、その変更が効力を持つ日付は別です。更新日が当日でも、失効日には将来の日付が入っていることがあります。差分にいったん現れず、後から掲載されるデータもあります。同期位置を進めたあとで過去日にさかのぼり、取りこぼしを拾い直す経路が要ります。
出典: 統合後の運用記録
データ品質を監査する
同期処理が成功で終わっても、DBが実際には更新されていないことがあります。処理件数やエラー数だけを見ていると、この状態には気づけません。500万件規模になると、本番でしか現れない不整合も出ます。同期の成否とは別に、公表データと自社DBを突き合わせる定期監査が要ります。
出典: 統合後の運用記録
企業名から名寄せする
手元にあるのが企業名だけ、という場面は避けられません。㈱ /（株）/ 株式会社、全角と半角、スペース、長音符といった表記の揺れを正規化したうえで候補を突き合わせます。突き合わせで出るスコアは確率ではないため、どこから自動処理に流し、どこから目視に回すかの線引きを自分で決める必要があります。Bango APIでは confident / review / unmatched の3段階で返し、その判定基準を公開しています。
出典: 統合後の運用記録
仕様変更に追従し続ける
公表データの仕様やコード値の意味は更新されることがあります。差分の処理区分は単独では意味が定まらず、訂正区分や複数の日付と組み合わせて読む必要があります。いったん解釈を実装へ落としたあとも、公表資料の更新を追い、変わったときに変換処理を直す当番が残ります。
出典: curlで試した記録
RESPONSIBILITY
どちらが何を持つか
同じ結果を得るために、利用側が持つ責務がどう変わるかを並べます。Bango APIを使っても消えない責務は、次の節に分けて書きます。
| 項目 | 自作した場合（利用側が持つ） | Bango APIを使う場合 |
|---|---|---|
| 認証情報の取得 | 国税庁へアプリケーションIDを申請する（使うWeb-APIの組み合わせによっては追加の申請と承認が要る） | ダッシュボードでAPIキーを発行する（国税庁への申請は不要） |
| 呼び出し回数 | 法人情報とインボイス情報を別々に呼び出し、結果を突き合わせる | 1回のリクエストで統合したJSONを受け取る |
| レスポンス形式 | XMLとJSONの両方を解析し、1つのデータモデルへ揃える | 統一したJSONで受け取る |
| T番号しかない場合 | 法人番号との対応規則を自前で持ち、個人事業者のケースを切り分ける | T番号のまま照会でき、法人／個人事業者等を区別して受け取る |
| 過去日付での有効性 | 登録日・取消日・失効日から判定ロジックを自作する | 日付を指定して判定結果を受け取る |
| 表記ゆれの名寄せ | 正規化とスコアリングを実装し、自動処理の閾値を自分で決める | 信頼度つきの一括名寄せを呼び出す（判定基準は公開） |
| 差分同期 | 分割取得・同期位置の管理・再実行時の二重適用対策を実装し、運用する | 日次で同期した結果を使う（出典と、取得できる場合の国税庁レコード更新日は meta.source で確認） |
| データ品質の監査 | 公表データと自社DBの突き合わせを定期実行し、ずれを直す | 監査はBango API側で継続する |
| 仕様変更への追従 | 公表資料の更新を追い、変換処理を改修する | 追従はBango API側で行い、変更はドキュメントで告知する |
| 稼働の監視 | 自作した同期基盤とAPI呼び出しの異常を、自分で検知して復旧する | 公開のステータスページで状態を確認する |
| 利用料 | 国税庁Web-APIの利用料は無料。かかるのは実装・保守の時間と、要件に応じた運用基盤の費用 | 月額のプラン利用料。無料枠あり |
どちらが持つかを決める前に、返ってくるJSONを実際に見比べられます。 実際のレスポンスを見比べる
STILL YOURS
Bango APIを使っても利用側に残ること
肩代わりできない責務もあります。導入を検討する段階で見えているほうがよいため、先に書いておきます。
- APIキーの発行・保管・失効の管理
- プラン上限に合わせた呼び出し設計と、失敗したときのリトライ
- 返ってきた判定を、いつ時点で有効とみなすかという自社の業務要件へ落とし込むこと
- 取得できる場合の meta.source の更新日と、稼働状況ページを見て、必要な鮮度を満たしているか判断すること
- 国税庁の公表データを出典として表示すること
- 重要な判断では、国税庁の公表サイトで最終確認する運用を残すこと
- Bango API側が応答しないときに、自社サービスをどう振る舞わせるか決めておくこと
TOTAL COST
料金ではなく、保守の総コストで比べる
国税庁Web-API自体の利用料は無料です。比べるのは月額ではなく、実装と保守にかかる時間と、要件に応じて必要になる運用基盤を含めた総コストです。
| コスト項目 | 一度きり | 運用している限り続く |
|---|---|---|
| 初期実装 | 2つのAPIの統合・形式変換・データモデルの設計 | 実装後の改修は、以下の各項目として現れる |
| 仕様変更への追従 | 公表資料を読み解いて実装へ落とす | 更新のたびに調査と改修が発生する |
| 利用条件とエラーへの対応 | リトライとキャッシュの設計 | 想定外の応答が出るたびに調査が要る |
| 表記ゆれの名寄せ | 正規化と突き合わせの実装 | 精度の改善と閾値の見直しが続く |
| 差分同期 | 分割取得・同期位置の管理・二重適用対策の実装 | 日次の監視と、失敗したときの再実行が続く |
| データ品質の監査 | 公表データとDBを突き合わせる仕組みの構築 | 定期監査と、見つかった差異の復旧が続く |
| 実行基盤・データ保管 | DB・バッチ実行基盤・監視の設計と構築 | ストレージ・コンピュート・監視などの利用料と、その運用 |
| 障害対応 | 検知と通知の整備 | 自社の可用性要件に応じた検知と復旧の対応が続く |
この表に金額は入れていません。工数も単価もチームによって変わり、こちらが代わりに決められるものではないためです。自社の値と、各項目に月あたりどれだけ見込むかを当てはめて計算してください。Bango APIの月額は料金ページで確認できます。
PRIMARY RECORDS
このページの根拠にした開発記録
上に挙げた事実は、国税庁のWeb-APIを実際に呼び出し、統合して運用した過程の記録に基づいています。手順とレスポンスは記事側に残しています。
- 国税庁の法人番号APIとインボイスAPIをcurlで使ってみた
申請の経過、curlでの取得、差分取得と分割の実測までの記録。
- 法人番号APIとインボイスAPIを統合して分かった、実装より保守が難しい理由
統合したあとの同期・データ品質・名寄せで何が起きたかの開発記録。
FAQ
よくある質問
Build vs Buy の判断でよく聞かれる点をまとめます。
- 国税庁のAPIは使わないほうがよい、ということですか？
- いいえ。このページの冒頭に挙げたケースに当てはまるなら、国税庁のWeb-APIを直接使うのが合理的です。自作をやめるべきだという主張ではなく、自作したときに何を持ち続けることになるかを整理したものです。
- 自作とBango APIでは、どちらが安く済みますか？
- 月額だけでは決まりません。国税庁Web-API自体の利用料は無料です。ただし自社DBへの継続同期や監査まで行うなら、実装・保守の時間に加えて、要件に応じたDB・バッチ・監視などの運用基盤も比較の対象になります。コスト項目の表に自社の値を当てはめて比べてください。Bango APIには無料枠があるため、比較のために先に実際のレスポンスを見ることもできます。
- Bango APIは国税庁のサービスですか？
- いいえ。Bango APIは国税庁とは独立した第三者のサービスです。国税庁が公表しているデータを編集・加工して提供しており、国税庁との間に特別な関係はありません。
- いまの自作実装から、段階的に移行できますか？
- できます。まずPlaygroundで、いま使っている法人番号やT番号をそのまま投げて、返るJSONを見比べてください。既存の実装を止めずに、1エンドポイントずつ置き換えられます。
- データがいつ時点のものか分かりますか？
- 国税庁の公表データを日次で差分同期しています。レスポンスの meta.source では、データの出典と、取得できる場合は更新日を確認できます。稼働状況とメンテナンス情報は公開のステータスページで確認できます。
- 名寄せの精度はどれくらいですか？
- カバレッジと、confidentと判定した分の精度を2軸で計測し、方法論と再現手順とあわせてベンチマークページで公開しています。1つの数字で語れるものではないため、どこまでを自動処理に流せるかという観点で確認してください。
NEXT STEP
まずレスポンスを見比べてください
移行を決める前に、いま自作で扱っている番号をそのまま投げて、返るJSONを見るところから始められます。
- Playgroundで試す
いま使っている法人番号やT番号を、登録なしでそのまま投げられます。
- ドキュメントを見る
エンドポイント・認証・エラー・レート制限の仕様を確認できます。
- 名寄せ精度を確認する
カバレッジとconfident精度の2軸を、方法論とあわせて公開しています。
- 料金を見る
プランと無料枠、それぞれの上限を確認できます。
- 無料でAPIキーを取得する
Freeプランはクレジットカードの登録なしで始められます。