取引先登録で入力候補の法人番号を確認する場面を考えます。以下は国税庁法人番号Web-APIの公開項目だけを使った机上例で、実際の申請やAPI応答を記録したものではありません。
候補の法人番号をAPIへ照会すると、指定した番号の基本3情報、付随情報、条件に応じた変更履歴を取得できます。期間指定による取得では、登記記録の閉鎖に関する情報も対象です。応答に閉鎖年月日、閉鎖事由、承継先法人番号が含まれる場合は、それらを確認項目として扱います。返却内容は照会条件に応じ、すべての項目が毎回返るとは限りません。
ただし、応答項目だけでは、申請された取引先と応答先法人の同一性や、登録内容を更新するかどうかまでは決まりません。設計例では、閉鎖に関する情報が応答に含まれたところで処理を止め、人が申請情報と照合して判断します。
経理業務でAIを使うときは、任せる作業だけでなく、人が判断する例外と承認の流れも分けて考えます。入力、判定、証跡、承認を業務の順に並べると、どこで処理を止め、何を記録するかを設計できます。
APIの応答と、人が決める判断を分ける
法人番号Web-APIから取得できる項目と、申請情報の同一性・更新要否の判断を分けます。応答だけで判断が決まらない場合は人へ戻し、入力、取得元、応答項目、判断、承認結果を記録する設計案を示します。
関連する記事
「経理はAIに任せられない」の中身
経理の作業をすべて自動化するかどうかで考えると、反復処理と業務判断の責任が混ざります。処理から定型作業を分け、要件設定や例外承認を誰が担うかを決めると、AIに任せる範囲を検討しやすくなります。
設計上は、計算、形式検査、公式情報の取得、ルールに沿った照合、不一致の抽出を、承認判断から切り分けて考えられます。
- 入力項目の形式を検査する
- 法人番号をWeb-APIで照会する
- 業務ルールに沿ってデータを照合する
- 確認が必要な不一致を例外として抽出する
APIが返すのは登録情報です。取得項目に閉鎖情報が含まれても、申請内容との同一性や更新の要否を自動で確定させず、人が判断する条件を設計しておきます。
業務要件、例外の扱い、最終承認をどの役割が担うかは、設計時に決めます。金融庁資料が扱うのは財務報告に係る内部統制で、その範囲では経営者が内部統制の整備・運用と有効性評価を担うとされています。同資料はすべての企業の全業務に同じ統制設計を義務付ける根拠ではなく、AIを使うと責任がAIへ移ると示すものでもありません。
入力、判定、証跡、承認の4層
この記事では、業務の確認項目を入力、判定、証跡、承認の4層に分けて棚卸しします。この4層は公式資料の固定分類ではありません。金融庁資料のIT統制・モニタリングと、経済産業省ガイドラインの責任・記録・継続的改善を参考にした、記事上の整理です。
この整理では、どの入力を使い、何で判定し、何を記録し、例外時に誰が承認するかを同じ業務の流れで確認します。
| 層 | 設計する内容 | 確認すること |
|---|---|---|
| 入力 | 必須項目、候補法人番号、コード | 表記ゆれや欠落を入口で減らせるか |
| 判定 | 形式検査、計算、API照会、照合規則 | 決定的処理と曖昧な判断を分けたか |
| 証跡 | 入力値、照会時点、取得元、応答項目、判断、結果 | あとから同じ判断を説明できるか |
| 承認 | 例外条件、人へ戻す地点、承認者、差し戻し | 例外時に誰へ戻るか決まっているか |
法人番号の机上例なら、入力候補の番号、照会先、API応答と申請情報の違いを見ます。API応答をそのまま更新判断にせず、応答だけでは決められない点を例外として人へ戻す流れを設計します。
API応答から人へ戻す判断を設計する
申請に入力された候補の法人番号を照会し、条件に応じて閉鎖関連の情報が返る場合を考えます。基本情報、変更履歴、閉鎖関連の応答は判断材料になりますが、応答だけで登録更新の要否を確定させる設計にはしません。
仮に応答に閉鎖年月日、閉鎖事由、承継先法人番号が含まれていても、それだけで申請先との同一性や登録を更新するかは決まりません。設計例では、同一性または更新要否が判断できない地点で自動処理を止め、人へ戻します。
人へ戻した後の記録案には、入力候補の法人番号、照会時点、取得元、応答項目、人の同一性・更新判断、承認または差戻し結果を残します。これは一つの業務を説明するための記事上の提案であり、公式資料が一律に指定する記録項目ではありません。
例外を人へ戻す条件を設計する
設計例では、金額不一致、登録番号なし、API応答に閉鎖情報が含まれる場合、未定義の税区分を人へ戻す条件として置きます。ここに挙げたのは一つの業務を想定した提案で、全社共通の公式基準ではありません。
AI前提の内部統制と監査は、まだ読めない
制度資料の適用範囲と、ここで示す業務設計の例は分けて読みます。
金融庁資料は、具体的な内部統制の設計が組織の環境や特性に応じるとしています。4層や停止条件、記録案は全業務に共通する基準ではなく、対象業務を棚卸しするための例です。
経済産業省は2026年3月31日にAI事業者ガイドライン第1.2版と、チェックリスト・ワークシートなどの付属資料を公表しています。これらはAIガバナンスを検討するための資料であり、特定の経理業務や内部統制監査への適合を保証するものではありません。金融庁資料は財務報告に係る内部統制を対象としており、全業務に共通するAI承認制度を示すものではありません。
経済産業省のガイドラインは、AI出力の誤りを受け付ける機会、作業記録、定期的で客観的なモニタリング、評価と継続的改善を扱います。これらを業務の責任者や例外時の確認経路へ結び付けることができます。保存期間や停止条件を同資料が一律に指定しているわけではありません。
全社方針より先に、業務1つの棚卸し
設計例として、確認手順を説明できる業務を一つ選び、入力から承認までを棚卸しします。次の項目を、その業務に合わせて並べます。
- 入力データと参照元を列挙する
- 計算・形式検査・API照会など、規則に沿う処理を分ける
- API応答だけでは決まらない同一性・更新判断を特定する
- 例外として人へ戻す条件と、判断・承認者を決める
- 入力、照会時点、取得元、応答項目、判断、承認結果の記録案を作る
法人番号Web-APIの机上例では、APIで得られる項目を判断材料として扱い、申請との同一性や更新要否が決められない地点で人へ戻します。入力から応答、人の判断、承認結果までを分けて記録することが、ここで示した業務設計の提案です。
処理の一部を機械に任せても、誰が何を根拠に判断したかを記録から追えるようにします。内部統制はAIを使わないためだけの仕組みではなく、業務上の責任と証跡を設計する考え方です。
