仕入先・支払先の適格請求書発行事業者の登録状況を国税庁の公表サイトのWeb-APIで毎月確かめ、登録の取消・失効と名称の変更を支払先台帳と照らして経理へ知らせる

処理の起点を決める

毎月3日の朝8時に、Schedule Trigger で動かします。 支払予定表は前月末の締めで固まり、支払は月の半ばです。3日に照会すれば、支払の前に10日ほど確かめる時間が残ります。

Schedule Trigger は月の何日に動かすかを1から31で指定できます。ワークフローのタイムゾーンが無ければインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動かない点も確かめます。

臨時の支払があるときは、手で動かせるようにしておきます。 同じワークフローを、支払予定表の対象の行だけを指定して動かします。

入力データを集める

質を決めるのは、いちばん下の過去の判定の記録です。 「㈱山田製作所」と「株式会社ヤマダ製作所」を一度人が同じ相手と確かめたら、同じ組み合わせは翌月から判定に回しません。 第3章の（d）は、この記録で解きます。

公表情報の「主たる屋号」と「通称・旧姓」も必ず取ります。 個人の支払先は台帳に屋号で載っていることが多く、公表の側に屋号があれば、名称の比較の材料が1つ増えます。 屋号が空なら、名称だけでは判定できないものとして扱います。

データの取得方法を決める

登録番号は「T」に13桁を付けた形で、カンマ区切りで最大10件まで指定できます。 600社なら60回の照会です。Loop Over Items のバッチの大きさを10にし、1回ごとに10件の番号をまとめて送ります。 応答形式は CSV（01）、XML（11）、JSON（21）から選べ、後段で扱いやすい JSON にします。

JSON の応答には、最終更新年月日（lastUpdateDate）、総件数（count）、分割番号、分割数が先頭に付き、その下に公表情報（announcement）が並びます。 1件ごとに、登録番号（registratedNumber）、事業者処理区分（process）、氏名又は名称（name）、登録・取消・失効の年月日が入ります。送った番号の数と返ってきた番号を突き合わせ、返ってこなかった番号を not_found にします。 総件数だけを見ると、履歴つきの応答では1つの番号に複数の行が返るため数が合いません。

履歴情報要否（history）を「1」にすると、登録・取消・失効に係る履歴も返ります。 指定しなければ「0」として扱われ、リクエスト時点の最新情報だけが返ります。最新履歴（latest）が「1」のものが今の状態、「0」のものが過去の情報です。

2つ目の照会は、登録番号と日付を基準日にして、直近の登録・取消・失効に紐づく情報を返す機能です。 支払予定表の請求書ごとに、取引年月日を基準日（day）にして照会します。月の途中で失効した相手は、月初の取引は登録の期間内、月末の取引は期間外になることがあります。支払先単位ではなく、請求書単位で確かめる理由はここです。

支払先が数万社ある場合は、取得期間の指定（/1/diff）を使います。 期間内に更新年月日が含まれる公表情報を返す機能で、指定できる期間は最大50日、該当が500件を超えると応答が分割され、分割番号を分割数まで増やしながら取り直します。全国の更新が返るため、本記事の規模では登録番号の指定のほうが軽くなります。

AIへ渡す前に整形する

1. 登録番号の書き方をそろえる … 全角・半角、「T」の有無、ハイフンや空白を除き、「T」＋13桁にします。桁数が合わないものは照会せず、台帳の不備として一覧に出します
2. 登録番号が空の支払先を分ける … 免税事業者として取引している相手と、番号の聞き漏れとを、台帳の区分で分けます
3. 同じ番号の重複をまとめる … 1つの事業者に支払先コードが複数あることがあります。照会は番号ごとに1回にします
4. 名称の比較の前に、規則で正規化する … 「㈱」「（株）」を「株式会社」に、全角英数字を半角に、空白を除きます。正規化して一致したものはAIに渡しません
5. 過去に人が同じ相手と判断した組み合わせを外す … 台帳の名称と公表の名称の組が記録にあれば、判定を省きます
6. 支払予定表と台帳を支払先コードで結ぶ … 支払予定表にあって台帳に無い支払先は、照会の前に一覧へ出します。臨時の支払先が台帳の登録を飛ばしていることがあります

4番目と5番目で、AIに渡す件数が大きく減ります。 表記の違いの大半は、規則の正規化で片づきます。AIに残るのは、カナと漢字、旧社名と新社名、屋号と氏名のように、規則では決められない組み合わせだけです。

AIに処理させる

させるのは、台帳の名称と公表の名称の組1件ごとに、同じ事業者と見てよいかを4つに分けて判定し、根拠を書き出すことです。

4行目がいちばん起きやすい失敗です。 名称が合わない番号を渡すと、生成AIは「番号の末尾の2桁が入れ替わっている可能性があります」と、それらしい番号を挙げます。照会もしていない番号を候補として出されると、担当者がそれを台帳に書き写す危険があります。 番号の誤りが疑われるときは different とし、正しい番号は取引先に確かめます。

指示内容を固定する

Basic LLM Chain の System のメッセージに、次のように書きます。

あなたは経理部で、支払先台帳の名称と、国税庁の適格請求書発行事業者
公表システムが返した名称を比べる担当です。入力は、1つの登録番号に
ついての、台帳の情報と公表情報の組です。

【判定の区分】
- notation ..... 表記の違い（カナと漢字、支店名、法人の種類の略し方）で、
                 同じ事業者と見てよい
- renamed ...... 公表情報の履歴に名称の変更があり、商号の変更と考えられる
- different .... 名称の主要な語が共通しない、法人と個人が台帳と逆など、
                 別の事業者を指している疑いがある
- undetermined . 名称だけでは判断できない
迷ったときに notation を選ばないでください。

【厳守事項】
- 判断の根拠は、入力に含まれる台帳の情報と公表情報だけにしてください。
  取引先について知っていることを補わないでください。
- 登録の状態（登録・取消・失効）は判定しないでください。入力の
  status は、すでに決まったものとして読むだけにしてください。
- 正しい登録番号を推測しないでください。番号の誤りが疑われるときは
  different とし、suspected_cause に「番号の誤りの疑い」と書いてください。
- 個人の事業者で、台帳が屋号、公表情報に主たる屋号が無いときは
  undetermined としてください。
- evidence には、比べた語をそのまま書いてください。
- 仕入税額控除の扱いや、取引先への連絡の要否を書かないでください。

【台帳の情報】{ledger}
【公表情報（最新と履歴）】{announcement}

「迷ったときに notation を選ばない」が、この指示の要です。 名称の比較を頼むと、生成AIは同じ相手と見る方向に寄りがちです。同じ相手と判定されたものは人が見ないので、誤りがそのまま残ります。 迷ったら人が見る側へ倒します。

「知っていることを補わない」も同じ考えです。 有名な企業ほど、生成AIは旧社名や合併の経緯を知識から書きます。根拠が公表の履歴に無いものは、確かめようがありません。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "registration_no": "",
  "vendor_code": "",
  "ledger_name": "",
  "published_name": "",
  "published_trade_name": "",
  "kind": "corporate | individual",
  "judgment": "notation | renamed | different | undetermined",
  "evidence": [""],
  "suspected_cause": "",
  "name_history": [ { "name": "", "update_date": "" } ]
}

1つ目の理由は、judgment で人の見る順番を決められることです。 notation は一覧で流し見、renamed は台帳の名称の更新の候補、different と undetermined は取引先や購買に確かめるものです。

2つ目は、登録の状態とAIの判定を別の層に置けることです。 規則で決めた status と、AIの judgment を同じ行に並べ、ワークフローが次の表のとおりに知らせ方を決めます。

3つ目は、name_history で商号の変更を確かめやすくなることです。 公表の履歴に名称の変更があれば、いつ変わったかを担当者が一目で見られます。

システムへ連携する

支払先台帳と会計システムへは書き込みません。 照合の一覧に書くところまでで、台帳を直すのも支払を止めるのも人の仕事です。 書き込みを足すと、AIの判定の誤りが台帳にそのまま残ります。

アプリケーションIDは、ワークフローの資格情報として持ちます。 URLの中に直接書くと、実行の記録にIDが残ります。照会の回数は、毎月の支払先の数を10で割った回数に収まります。

人が確認する

1. 取消・失効を先に見る … 失効・取消の年月日と、それより後の取引年月日の請求書を確かめます。ここは必ず人が見ます
2. not_found を確かめる … 台帳の番号の打ち間違いか、相手がまだ登録していないのかを、取引先に確かめます
3. different と undetermined を確かめる … 過去の請求書の名称と番号を見て、同じ相手かを判断します。 判断したら照合の一覧に理由を残します
4. renamed を台帳に反映するか決める … 取引先から変更の届出が来ているかも確かめます
5. 仕入税額控除の扱いと連絡先を決める … 経理の責任者が、必要に応じて顧問税理士と相談します

3番目で「同じ相手」と判断した記録が、翌月の判定を減らします。 記録を残さないと、毎月同じ組み合わせがAIに回り、同じ確認をくり返します。

notation と判定されたものも、最初の3か月は件数と中身を流し見ます。 別の事業者を表記の違いとした誤りは、人が見ない側に入るので、そのままでは見つかりません。 3か月見て誤りが無ければ、件数を見るだけに切り替えます。

目標は、600件をならして1件0.5分です。 一致したものは件数を見るだけで、取消・失効と別の事業者の疑いだけを詳しく見るという見込みです。

例外に対処する

上の1行目を「登録あり」として流すと、この構成の意味が無くなります。 照会できなかった番号は、照会できなかったことが分かる形で必ず残します。

記録を残す

• 照会ごとの日時、送った登録番号、返った応答の全文と状態コード
• 支払先ごとの登録の状態と、それを決めた区分と年月日
• AIの判定の出力と、そのとき比べた台帳の名称
• 人の判断 … 同じ相手と判断した組み合わせと理由、判断した人と日付
• 取消・失効を知った日と、その相手の最後の取引年月日

最後の行が、この構成の物差しです。 失効の年月日から何日で気づいたかを毎月並べると、支払の前に気づけているかが分かります。

応答の全文を残すのは、後から当時の状態を確かめるためです。 公表情報には訂正が入ることがあり、照会した日に何が返ってきたかが残っていないと、その月の支払の判断の根拠を示せません。保存の期間は、請求書の保存の期間に合わせて決めます。