インボイス登録番号の一括確認をClaude Codeで仕組み化する実装

受領請求書のインボイス登録番号の確認を、国税庁公表サイトの全件・差分データとWeb-APIで一括化する実装パターン。形式チェック・名称突合・失効検知・証跡保存まで、経理の定常業務として回す設計をコード例つきで解説。

結論：受領した請求書のインボイス登録番号の確認は、新規取引のたびに国税庁の公表サイトを手で検索する仕事ではなく、「形式チェック→公表データとの突合→例外だけ人が確認」の3段パイプラインとして、Claude Codeで仕組み化できます。国税庁は適格請求書発行事業者の公表情報を全件データ・差分データ・Web-APIの3ルートで機械可読提供しており、経理側にローカルの照合基盤を持てば、登録番号の確認は月次・日次で回る定常バッチになります。

要点1：登録番号は「T＋数字13桁」。法人は「T＋法人番号」なので、法人相手なら法人番号公表サイトの情報から機械的に照合キーを組み立てられる（国税庁公表サイト「登録番号とは」より）
要点2：確認ルートは公表サイトの画面検索・Web-API（要アプリケーションID・無料）・全件/差分データのダウンロード（CSV/XML/JSON）の3つ。大量照合の本命は「月次全件＋日次差分でローカルミラーを育てる」構成で、Web-APIはスポット確認に回す
要点3：照合そのものより大事なのは証跡。「どの基準日の公表データに対して・いつ・どの請求書の番号を照合し・結果がどうだったか」をログに残す設計にしないと、あとから確認状況を説明できない

対象読者：経理・購買部門とAI活用を進める開発者・PM。受領請求書の件数が月数百件を超え、登録番号の確認が目視と手作業のWeb検索で回らなくなっている会社

今日やること：会計ソフトから受領請求書（仕入先）の一覧をCSVで出し、登録番号列の充足率を数える。空欄と「T」なし13桁の件数が、自社の照合パイプラインが最初に処理すべき在庫です

先に断っておくと、本記事は複数の支援経験をもとに一般化した実装パターン解説です。登場する工数や効果はいずれも想定モデルケースの目安で、特定企業の実測値ではありません。また、消費税の仕入税額控除の適用可否や経過措置の扱いは個社の状況で変わるため、税務判断は必ず顧問税理士に確認してください。本記事が扱うのは、その手前にある「確認作業を仕組みとして回す」部分です。

バックオフィスのAI活用支援で経理チームと話すと、インボイス制度対応の「その後」の悩みをよく聞きます。制度開始時に取引先へ登録番号を一斉照会したところまでは多くの会社がやり切っている。問題はそこから先で、新規取引先が増えるたびに公表サイトを開いて1件ずつ検索し、スクリーンショットをフォルダに保存する運用が、誰の担当とも決まらないまま続いている——そして繁忙月には飛ぶ。登録番号は一度確認して終わりではなく、登録の取消や失効が起きうる生き物なのに、手元のマスタは制度開始時のスナップショットのまま、というケースが目立ちます。

この記事では、受領請求書の登録番号確認を「一度きりの大掃除」ではなく「公表データのローカルミラーを育てながら回す定常バッチ」として実装する方法を、コードと運用の両面から解説します。請求書突合（3点照合）・取引先マスタの名寄せで扱った「取引先まわりのデータ整備」の続編にあたり、名寄せ記事で整備した法人番号列がそのまま照合キーとして効いてきます。

なぜ登録番号の確認は経理の定常業務になるのか

前提を短く整理します。令和5年（2023年）10月1日に始まった適格請求書等保存方式（インボイス制度）では、仕入税額控除の適用に、一定の事項を記載した帳簿と適格請求書（インボイス）等の保存が要件になりました。適格請求書を交付できるのは、税務署長の登録を受けた適格請求書発行事業者だけです（国税庁タックスアンサーNo.6498）。

つまり買手である経理側から見ると、受け取った請求書に書かれている登録番号が「実在し、その取引先のもので、取引時点で有効」であることは、税額計算の前提を支える事実確認になります。ここで実務を難しくするのが次の3点です。

登録は動く — 適格請求書発行事業者の登録には取消や失効があり、国税庁の公表情報も日々更新されます。制度開始時に一度確認したきりでは、現在の状態を反映しません
件数が多い — 確認対象は新規取引先だけでなく、既存の全仕入先の継続的な状態確認まで含みます。公表サイトの画面検索で1件ずつ追う運用は、件数に対して線形に人手を食います
証跡が要る — 「確認した」という事実は、いつ・何に対して・どう確認したかの記録があって初めて説明可能になります。スクリーンショットの散在フォルダは、件数が増えた時点で証跡として機能しなくなります

なお、適格請求書発行事業者以外からの課税仕入れについては、一定割合を仕入税額とみなして控除できる経過措置が令和13年（2031年）9月末までの期間で設けられています（国税庁インボイス制度特設サイト・2026年8月時点）。控除割合や適用条件は税制改正で見直されることがあるため、判定は最新の公式情報と顧問税理士への確認を前提にしてください。本記事のパイプラインは「相手が登録事業者かどうかを機械的に把握し続ける」部分を担い、その先の税務処理の判断材料を揃える位置づけです。

確認ルートは3つ——画面検索・Web-API・全件/差分データ

国税庁の「適格請求書発行事業者公表サイト」は、確認手段を3系統提供しています。それぞれ性格が違うので、用途で使い分けます。

ルート	概要	向いている用途
公表サイトの画面検索	登録番号を入力して1件ずつ照会	単発のスポット確認。大量処理には不向き
Web-API（REST・Ver.1）	登録番号を指定した情報取得や、期間を指定した更新（差分）情報の取得。利用にはアプリケーションIDの発行申請が必要（発行費用は無料）	自社システムからのオンライン照会。少〜中量のリアルタイム確認
公表情報ダウンロード（全件・差分）	前月末時点の全件データ（毎月初日作成）と日次の差分データ（過去40日分）をCSV/XML/JSON形式で取得。登録の新規追加・変更・取消失効などの情報を含む	大量照合の本命。ローカルに照合用ミラーを構築して突合する

月数百件以上の受領請求書を扱う規模なら、アーキテクチャは「月次で全件データを取り込み、日次で差分データを重ねてローカルミラーを最新化し、受領請求書はミラーに対してオフライン突合する」構成が安定します。照合のたびに外部へ問い合わせないため件数が増えても速度が落ちず、国税庁側の負荷にもなりません。Web-APIは、ミラー更新の隙間で今日登録されたばかりの事業者を確認したいといったスポット用途に回します。

なお全件データは法人（h_all_）・人格のない社団等（j_all_）・個人（k_all_）のファイルに分かれ、Zip圧縮で提供されます。圧縮ファイルには国税庁が作成したファイルであることを検証するためのOpenPGP署名検証用ファイルが同梱されており、取り込みバッチの冒頭で署名検証を挟めるようになっています。また、個人の氏名など一部項目は値を削除した形で提供されるため、「データに名前が入っていない＝異常」ではありません。この仕様はダウンロードページのリソース定義書で必ず確認してください。

設計原則——照合は機械、判定の確定と例外処理は人

実装に入る前に、権限の線引きを決めます。取引先マスタの名寄せと同じ思想です。

機械がやること — 登録番号の形式チェック、公表データミラーとの突合、名称の照合、失効・取消の検知、例外一覧と根拠資料の生成、照合ログの記録
人がやること — 例外（未登録・失効・名称不一致）が出た取引先への対応判断、取引先マスタの登録番号の修正確定、税務処理の判断（顧問税理士と連携）

照合結果が「未登録」と出ても、それは「相手が免税事業者」「番号の転記ミス」「登録直後でミラー未反映」のどれなのか、データだけでは確定できません。機械が確定してよいのは「公表データ上こう見える」という事実までで、取引先への確認連絡や仕入税額控除の扱いといったアクションは人が決める。この線を最初に引いておくと、後述のCLAUDE.mdへの焼き込みまで一直線に進めます。

実装1：登録番号の形式チェックと正規化

最初の関門は突合以前の問題、つまり「マスタや請求書データに入っている登録番号の表記が汚い」ことです。全角のＴ、ハイフンやスペース入り、Tなしの13桁、法人番号との混同——このあたりを決定的なコードで正規化します。登録番号の構成は「T＋数字13桁」（法人は「T＋法人番号」、個人事業者等はマイナンバーとは無関係の固有番号）と公表されているので、形式チェックは単純です。

# invoice_number_check.py — 形式チェックと正規化（決定的処理のみ）
import re
import unicodedata

RE_TOROKU = re.compile(r"^T\d{13}$")

def normalize_toroku_number(raw: str) -> str:
    """全角・空白・ハイフンを除去してT+13桁の形式に正規化する"""
    s = unicodedata.normalize("NFKC", (raw or "").strip())
    s = re.sub(r"[\s\-ー－]", "", s).upper()
    return s

def classify_format(s: str) -> str:
    if not s:
        return "EMPTY"          # 未入力
    if RE_TOROKU.match(s):
        return "OK"             # T+13桁
    if re.fullmatch(r"\d{13}", s):
        return "MISSING_T"      # 13桁のみ（Tの付け忘れ or 法人番号の可能性）
    return "INVALID"            # その他（桁数違い・記号混入など）

「MISSING_T」を独立させているのがポイントです。法人の登録番号はT＋法人番号なので、13桁だけ入っている場合は法人番号を書いた可能性が高く、Tを補えば照合候補になります。ただし自動でTを付けて「OK」に昇格させることはしません。候補として提示し、突合の結果とあわせて人が確定します。

この層をClaude Codeに作らせるときの指示はこうです。

> 受領請求書CSVの「登録番号」列を検査するスクリプトを書いて。
> 仕様: NFKC正規化→空白・ハイフン除去→「T+数字13桁」の形式判定。
> 結果はEMPTY/OK/MISSING_T/INVALIDの4分類で、元の値と正規化後の値を
> 両方残すこと。判定ロジックにLLM呼び出しは使わず、決定的な処理だけで
> 書くこと。不足している情報があれば、最初に質問してから作業を開始して
> ください。

実装2：公表データのローカルミラーをSQLiteで持つ

本命の照合基盤です。前月末時点の全件データを月次で取り込み、日次の差分データ（新規追加・変更・取消失効など）を重ねて最新化します。数百万件規模でもSQLiteで十分に引けますし、経理部門のPCでもサーバでも同じファイル1個で動くのが実務的です。

# mirror_update.py — 公表データ取り込みの骨格（列名はリソース定義書で確認）
import sqlite3
import zipfile
import csv
from pathlib import Path

DB = "invoice_kohyo_mirror.db"

DDL = """
CREATE TABLE IF NOT EXISTS kohyo (
    toroku_no   TEXT PRIMARY KEY,   -- 登録番号（T+13桁）
    name        TEXT,               -- 氏名又は名称（個人は削除項目あり）
    status      TEXT,               -- 登録/取消/失効などの区分
    update_date TEXT,               -- 公表データ上の更新年月日
    source_file TEXT                -- 取り込み元ファイル名（証跡）
);
CREATE TABLE IF NOT EXISTS import_log (
    imported_at TEXT,               -- 取り込み実行日時
    source_file TEXT,               -- 全件 or 差分ファイル名
    row_count   INTEGER,
    base_date   TEXT                -- このデータの基準日
);
"""

def import_zip(zip_path: str, conn: sqlite3.Connection) -> int:
    """全件・差分共通の取り込み。UPSERTで最新状態に収束させる"""
    n = 0
    with zipfile.ZipFile(zip_path) as z:
        for name in z.namelist():
            if not name.endswith(".csv"):
                continue  # 署名検証用ファイル等はスキップ（検証は前段で実施）
            with z.open(name) as f:
                for row in csv.reader(
                    line.decode("utf-8") for line in f
                ):
                    rec = parse_row(row)          # 列位置はリソース定義書に従う
                    upsert(conn, rec, source=name)
                    n += 1
    return n

実際の列構成（登録番号・氏名又は名称・登録年月日・取消/失効の情報など）は、公表サイトのダウンロードページにある「リソース定義書」に定義されています。ここを推測で書くとサイレントにずれるので、Claude Codeへの発注でも定義書を渡すところから始めます。

> 国税庁の適格請求書発行事業者公表サイトからダウンロードした
> 全件データ（CSV版Zip）をSQLiteに取り込むスクリプトを書いて。
> 列定義は手元の「リソース定義書」PDFの内容を正とし、列位置を
> 推測で書かないこと。取り込みごとにimport_logへファイル名・件数・
> 基準日を記録し、同じファイルの二重取り込みは冪等になるようにする。
> 仮定した点は必ず"仮定"と明記してください。

運用サイクルは「毎月初日以降に全件データで基準を張り直し、平日は差分データを追いかける」が基本です。全件データは毎月初日（休日を除く）に前月末時点のものが作成され、原則として作成日の翌日午前6時以降に公開、差分データは日次作成で過去40日分が取得できます。差分が40日分しか遡れない仕様なので、ミラー更新のcronが1か月以上沈黙すると穴が埋められなくなり、全件からの再構築になります。更新ジョブには必ず失敗通知を付けてください。

実装3：受領請求書データとの突合とステータス分類

ミラーができれば、突合そのものは単純なJOINです。要になるのは結果の分類設計で、「OKか否か」の2値にせず、次に取るべきアクションが決まる粒度に分けます。

# verify_batch.py — 突合とステータス分類（骨格）
STATUSES = [
    "OK",              # 番号が公表データに存在し、名称も一致
    "OK_NAME_DIFF",    # 番号は存在するが、名称の照合が不一致（要確認）
    "REVOKED",         # 取消・失効の区分が立っている（要確認・最優先）
    "NOT_FOUND",       # 公表データに存在しない（転記ミス/免税事業者/未反映）
    "FORMAT_NG",       # そもそもT+13桁の形式でない（実装1で検出）
]

def verify(row, mirror):
    fmt = classify_format(normalize_toroku_number(row["登録番号"]))
    if fmt != "OK":
        return "FORMAT_NG"
    hit = mirror.lookup(row["登録番号"])
    if hit is None:
        return "NOT_FOUND"
    if hit.is_revoked():
        return "REVOKED"
    if not name_matches(row["取引先名"], hit.name):
        return "OK_NAME_DIFF"
    return "OK"

名称照合（name_matches）には、名寄せ記事で作った正規化関数と表記揺れ辞書をそのまま流用します。「株式会社の位置違い」「㈱と（株）」で不一致を量産しないためです。個人事業者は公表データ側の氏名が削除されている場合があるため、名称照合はスキップして番号の存在と状態だけを見る、という分岐も必要になります。

突合バッチの発注プロンプトはこうなります。

> 受領請求書CSV（正規化済み）とSQLiteミラーを突合するバッチを書いて。
> 結果はOK/OK_NAME_DIFF/REVOKED/NOT_FOUND/FORMAT_NGの5分類。
> 実行ごとに「照合日時・ミラーの基準日・対象件数・分類別件数」を
> verify_log.csvへ追記し、OK以外の明細は exceptions.csv に書き出すこと。
> 明細行の削除や書き換えは一切しないこと。数字と固有名詞は、根拠
> （出典/計算式）を添えてください。

例外一覧が出たら、人がレビューしやすい形に整えるところまでをClaude Codeに任せます。ここは判定をさせない書き方が重要です。

> exceptions.csv の各行について、レビュー用の判断材料をMarkdownの表に
> まとめて。列は「取引先名/登録番号/ステータス/公表データ側の名称と
> 状態/直近の取引年月と金額/考えられる原因の候補」。原因は「転記ミス・
> 免税事業者・ミラー未反映・失効」の4候補を機械的条件で並べるだけに
> 留め、どれであるかの断定はしないこと。仮定した点は必ず"仮定"と
> 明記してください。

運用設計——証跡・基準日・CLAUDE.mdの停止線

支援先との会話で必ず出るのが「そもそも、いつ時点の情報で確認したことにするのか」という問いです。公表データは日々動くので、照合結果は「ミラーの基準日」とセットでなければ意味を持ちません。verify_logに基準日を必ず残すのはこのためです。請求書等の保存期間（受領した日の属する課税期間の末日の翌日から2か月を経過した日から7年間・国税庁タックスアンサーNo.6496）を考えると、照合ログも同じ時間軸で残す設計が自然です。ログはCSVの追記型で十分ですが、消せる場所に置かないこと。電子帳簿保存法対応の記事で扱った保存フォルダの規律と同じ考え方で、書き込み権限を絞った場所に置きます。

そして運用の規律はCLAUDE.mdに焼き込み、セッションをまたいでも守られるようにします。

# CLAUDE.md（抜粋）
## インボイス照合の停止線
- verify_log.csv / exceptions.csv は追記のみ。編集・削除するコードを書かない
- ミラーの更新は mirror_update.py 経由のみ。kohyoテーブルへの直接UPDATE禁止
- NOT_FOUND / REVOKED の取引先への対応判断はツールの外（人）で行う
- 税額計算・控除可否の判断をコードやコメントに書かない（税理士の領分）
- 突合結果の報告では、必ずミラーの基準日を併記する

定期実行まで進める場合は、差分取り込みと突合をスケジューラに載せ、REVOKEDが1件でも出た日だけ経理担当へ通知する構成が組めます（Claude Code公式ドキュメント: Headless mode）。発注プロンプトの例です。

> mirror_update.py（差分取り込み）と verify_batch.py（突合）を平日朝に
> 順番に実行するジョブを組んで。どちらかが失敗したら後続を止めて
> エラー内容を通知すること。REVOKEDが新規に出た場合のみ、対象取引先の
> 一覧を添えて経理チャンネルへ通知する。通知の宛先や実行時刻など
> 不足している情報があれば、最初に質問してから作業を開始してください。

失敗パターンと回避策

❌ 失敗1：制度開始時の一斉確認で「済んだこと」にする
登録には取消・失効があり、公表データの差分ファイルにはまさにその情報が日々流れています。スナップショット運用では、失効後の番号で受け取り続けても気づけません。
⭕ 回避策：月次全件＋日次差分のミラー更新を止めない。差分は過去40日分しか取れないため、更新ジョブの失敗通知を必ず付ける。

❌ 失敗2：「番号が実在する」ことと「その取引先の番号である」ことの混同
形式が正しく公表データにも存在する番号でも、別の会社の番号が転記されているケースは検出できません。番号の存在確認だけで照合を終えると、この取り違えが素通りします。
⭕ 回避策：突合は必ず名称照合とセットにする。名称の正規化・表記揺れ辞書は名寄せ基盤と共通化し、不一致はOK_NAME_DIFFとして人のレビューに回す。

❌ 失敗3：照合結果に基準日と証跡を残さない
「確認しました」と言えるのは記録があるときだけです。基準日のないOK判定は、あとから「いつ時点の話か」を説明できません。
⭕ 回避策：verify_logに照合日時・ミラー基準日・分類別件数を必ず記録し、追記型で保存する。スクリーンショット運用からログ運用へ移行する。

❌ 失敗4：控除割合や制度の期日をコードにハードコードする
経過措置の割合や期間は税制改正で見直されることがあります。コードに焼き込むと、改正のたびに「動いているが答えが古い」状態になります。
⭕ 回避策：ツールの守備範囲を「登録状態の事実確認」までに限定し、税額計算側の判断はコードに持ち込まない。制度の数値が必要な場合も設定ファイルに出し、参照日と出典をコメントで残す。

想定モデルケースの目安

効果は請求書の件数と取引先マスタの整備状況に大きく依存します。支援経験を一般化した想定モデルケース（月間受領請求書1,000件・仕入先800社・経理3名）での目安を示します。いずれも保証値ではなく、設計判断の相場観としてお読みください。

項目	手作業の場合	本パターン導入後
新規取引先の登録番号確認	公表サイトを1件ずつ検索し、スクリーンショットを保存	マスタ更新時のバッチで自動照合。人は例外だけを見る
既存仕入先の失効検知	実質的に未実施（気づいた時に発覚）	日次差分の取り込みでREVOKED検知→当日通知
確認状況の説明	フォルダとメールを掘り返して再構成	verify_logの提示で完結（基準日つき）
初期構築	—	形式チェック＋ミラー＋突合で1〜2週間、運用定着まで1〜2か月が目安

よくある質問

Q. インボイスの登録番号はどこで確認できますか？

国税庁の「適格請求書発行事業者公表サイト」で、登録番号を入力して照会できます。件数が多い場合は、本記事で解説した全件・差分データのダウンロードやWeb-APIによる機械照合が現実的です。いずれも国税庁が公式に提供している手段です。

Q. 登録番号は何桁ですか？法人番号と同じものですか？

登録番号は「T＋数字13桁」です。法人番号を持つ課税事業者は「T＋法人番号」なので、法人の場合は法人番号の先頭にTを付けた形になります。個人事業者や人格のない社団等は、マイナンバーとも法人番号とも重複しない13桁の固有番号が割り当てられます（国税庁公表サイト「登録番号とは」）。

Q. 取引先の名前から登録番号を検索できますか？

公表サイトの検索は登録番号を入力して照会する方式が基本です。法人の場合は、法人番号公表サイトで商号から法人番号を調べ、先頭にTを付けた番号を公表サイトで照合する、という2段の手順で実質的な名前からの逆引きができます。この手順自体もスクリプト化できます。

Q. 登録番号のない請求書を受け取ったらどうすればよいですか？

相手が適格請求書発行事業者でない（免税事業者など）可能性と、単なる記載漏れの可能性があります。仕入税額控除の扱いには適格請求書発行事業者以外からの課税仕入れに係る経過措置（令和13年9月末までの期間・2026年8月時点）もあるため、機械的に「控除不可」と断定せず、取引先への確認とあわせて顧問税理士に相談してください。

Q. Web-APIの利用は有料ですか？

無料です。ただし利用にはアプリケーションIDの発行申請と国税庁の承認が必要です（適格請求書発行事業者公表システムWeb-API機能のページから申請できます）。承認済みのIDは法人番号システムWeb-APIと共用できます。

Q. 照合はどのくらいの頻度で回すべきですか？

ミラー更新は「月次で全件、平日は日次差分」が公表データの提供サイクルに沿った形です。突合は受領請求書の処理サイクルに合わせ、月次の支払バッチ前に必ず1回、可能なら請求書の取り込み時に都度、が目安です。差分データは過去40日分しか取得できないため、更新を止めないことが最優先です。

まとめ：今日から始める3つのアクション

今日やること：受領請求書と仕入先マスタの登録番号列をCSVで出し、充足率と形式NG件数を数える。これが照合パイプラインの処理在庫です
今週中：公表サイトから全件データ（CSV版）とリソース定義書を取得し、SQLiteへの取り込みを最初のClaude Codeタスクにする。形式チェックの4分類まで動けば上出来です
今月中：突合バッチとverify_logを整備し、例外レビューの担当と頻度を決める。CLAUDE.mdに停止線を焼き込んでから日次差分の定期実行に進む

登録番号の照合は、請求書突合や月次決算の残高照合と同じく「揺らぐ入力を正規化し、確定できる事実だけ機械が確定し、例外を人に回す」型の仕事です。一度パイプラインを組めば、経理の突合業務の中で最も外部データ依存が強いこの作業が、最も再現性の高い定常バッチに変わります。

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。

参考・出典

国税庁適格請求書発行事業者公表サイト「登録番号とは」（参照日: 2026-08-05）
国税庁適格請求書発行事業者公表サイト「公表情報ダウンロード」（参照日: 2026-08-05）
国税庁適格請求書発行事業者公表システムWeb-API機能（参照日: 2026-08-05）
国税庁タックスアンサーNo.6498 適格請求書等保存方式（インボイス制度）（参照日: 2026-08-05）
国税庁タックスアンサーNo.6496 仕入税額控除をするための帳簿及び請求書等の保存（参照日: 2026-08-05）
Claude Code公式ドキュメント: Headless mode（参照日: 2026-08-05）

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。