公開範囲もひかえめではありません。仕訳の取得、作成、更新、削除ができて、試算表、マスター、証憑まで扱えます。freee会計のほうには、OAuth 2.0で取引や振替伝票などを読み書きできるPublic APIが以前からあります。「APIが使えるのは片方だけ」という前提は、もう成り立たないわけです。

比較の結論は、こうやってこちらに知らせもなく古びていきます。だから私は、会計ソフトを「APIあり」の1項目で選ぶのは危ういと思うようになりました。確かめたいのは有無ではなく、いまの契約と権限で必要なデータを読み書きできて、その結果まで検証できるかです。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制をどう設計する？作業・責任・監査証跡の分け方
2. 新規取引先チェックをAIで自動化｜閉鎖・合併済み法人を検知した方法
3. 経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準（この記事）

振り返ると、この連載の3つの実践も、申請の取得、公式情報との照合、証憑の取得、結果の整理を、全部APIでつないでいました。裏を返せば、接続先からデータを取り出せなかったら、AIがどれだけ賢くても、同じ流れは作れなかったはずです。

AIは会計データまで自力では届かない

生成AIは、会計ソフトの中のデータへ勝手にアクセスできるわけではありません。APIやMCP、許可された画面操作といった、外部システムとつながる手段が別に要ります。

ただ、APIが公開されているだけでは、まだ足りません。認証したユーザーに必要な権限がなければ、取得も更新もできないからです。会社として利用を認めるのか、誰の権限で動かすのか、書き込みをどこまで許すのか——このあたりは、製品を選ぶより先に決めておく話です。

NetSuiteやSAPのような大手ERPにも、APIそのものはあります。それでも、現場ですぐ使えるとは限りません。契約や権限、連携基盤、SIerとの役割分担まで整えて、ようやく使える状態になることもあります。

会計ソフトのAPIを比べる4つの基準

接続と権限まで含めて考えていくと、比べる項目はだいたい絞れてきます。私が確認しているのは、この4つです。

機能表の丸印を数えても、自社で使えるかどうかは分からないんですよね。なので、自動化したい業務を1つ選んで、この4つに当てはめてみます。仕訳を任せたいなら、「仕訳APIあり」で止めないことです。対象年度の仕訳を取得できるか、作成や更新に対応しているか、必要な補助科目を扱えるか、誰の権限で認証するか、更新後に再取得して確かめられるか。そこまで見て、やっと比較と呼べる状態になります。

freee会計APIは契約プランで使える範囲が変わる

freeeで見落としやすいのは、使えるAPIや項目が契約プランで変わる点です。認証はOAuth 2.0で、会計APIには取引、振替伝票、取引先、勘定科目、経費精算、支払依頼など、取得と更新の両方に対応したエンドポイントがそろっています。

上限も契約で違います。公式リファレンスに載っている事業所とアプリケーションごとの1日上限は、法人エンタープライズが10,000回、法人アドバンスが5,000回、それ以外は3,000回です。総勘定元帳APIのように、対象プラン自体が限られる機能もあります。

つまり「freeeなら全部使える」という話ではなくて、必要なエンドポイントをいまの契約で使えるかどうかを、1本ずつ見ていくことになります。一方で、一般の開発者でも公式リファレンスとアプリ登録から検証を始められるので、自分で試すハードルは低いほうだと思います。

いつの間にか一般公開になっていたマネーフォワード会計API

私の整理をひっくり返した側の、マネーフォワード クラウド会計です。いまの公式案内では、クラウド会計や確定申告の利用者なら、士業でも個人事業主でも法人でも、APIを利用できます。追加料金もかかりません。

操作の範囲もかなり広いです。仕訳の取得、作成、更新、削除のほか、取引明細の作成や証憑の保存と添付ができます。貸借対照表、損益計算書、月次推移、勘定科目、部門、取引先といったマスターまで扱えます。認証はOAuth 2.0とAPIキーによる方法が、開発者サイトで案内されています。

それと、AIツールから会計データを扱えるMCPサーバーも用意されています。APIとMCPは向いている用途が同じではないので、定期バッチや他システムとの連携にはAPI、AIと対話しながら確認する場面にはMCP、という使い分けになると思います。

NetSuiteは同時実行の上限がライセンスと連動する

大手ERPの例としてNetSuiteを見ておくと、こちらはWebサービスの同時実行の上限が、サービス階層とSuiteCloud Plusのライセンス数に連動しています。必要なAPIがそろっていても、大量処理や複数の連携を同時に動かすつもりなら、アカウント全体の上限と割り当てを確かめてからでないと始められません。

これは「大手ERPは使えない」という意味ではありません。権限管理や同時実行の制御が細かいぶん、現場で小さく試すまでの調整も増える、ということです。処理量の多い企業では、むしろその統制や拡張性のほうが必要になります。

製品名ではなく、業務を1つ通した結果で決める

freeeもマネーフォワードも会計APIを公開しているいま、製品名だけで「AI経理に向いているのはこちら」と決めるやり方は、もう成り立ちません。私が候補を比べるなら、1つの業務を次の順で通してみます。

1. 自動化したい業務を1つ選ぶ
2. 必要な取得項目と書き込み項目を洗い出す
3. 検証環境または読み取り専用でAPIを試す
4. 件数上限、権限、追加費用、更新後の確認方法を記録する
5. 例外時に止まり、人の確認に戻せることを確かめる

この5つは、APIの公開状況がまた変わっても、そのまま使えます。冒頭の「一般利用できない」という整理がひっくり返ったように、比較表の中身はこれからも動くはずです。でも、業務を1つ通して確かめる手順のほうは動きません。AIに任せられる範囲を決めるのは、モデルの性能だけではなくて、接続先がどこまで公開されていて、自社がどの権限を与えられるか、なんです。

ただし、APIで処理できることと、AIに承認の責任まで渡してよいことは、別の話です。作業と証跡をどう残すか、例外や人の承認をどう扱うかは、連載の最初の記事に書いています。

経理経理AIの内部統制はどう設計する？作業と責任、証跡の分け方経理業務をAIに任せても、承認する人の責任まで移るわけではありません。新規取引先と経費精算の実例から、入…→

2026年7月17日に確認した公式情報

• freee：Public API／会計APIリファレンス
• マネーフォワード：クラウド会計API／開発者ドキュメント／MCPサーバー
• NetSuite：Concurrency Governance Limits

合計そのものは合っています。レシートの合計と申請全体を見比べるだけの確認なら、まず素通りする組み合わせです。ただ、この仕組みが突合するのは合計ではなく、明細ごとの金額です。明細を1行ずつレシート内の文字から探しに行くので、「金額が見つからない」という根拠付きで、申請は自動的に要確認へ回ってきました。

で、この照合の仕組みなんですが、レシートを全部AI-OCRに読ませているわけではありません。文字を取り出せるPDFはPythonで照合して、画像やスキャンだけをClaudeに読ませています。分割計上や税率の混在、適格請求書に当たらない証憑が引っかかったら、最後は人が確認する流れです。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制をどう設計する？作業・責任・監査証跡の分け方
2. 新規取引先チェックをAIで自動化｜閉鎖・合併済み法人を検知した方法
3. 経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知（この記事）
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

前回の新規取引先チェックでは、公式情報との照合が中心でした。全件を確認するのは今回も同じなんですが、経費精算では、文字を扱う機械処理と画像を読むAIを使い分けています。

経費精算の明細とレシートは何を突合するか

仕組みの中身は、聞いてしまえば単純です。申請明細と添付された証憑を1件ずつ対応させて、次の4項目を突合します。

• 税込金額
• 利用日または発行日
• 税区分と税率
• 適格請求書発行事業者の登録番号

件数が増えてくると、1枚ずつ「それらしい」と眺める確認では、この4つのどこかに不一致が紛れやすくなります。だったら、すべての明細に同じ条件を当てて、引っかかったものだけを人へ返すほうが確実だろうと考えて、この形にしました。

AI-OCRの前に、Pythonでテキスト層を読む

取り出したレシートを、いきなりAIへは渡しません。テキスト層が残っていればPythonで文字を取れるので、AI-OCRに回すのはそのあとです。

処理の入口はバクラクです。申請中の経費精算を取得して、明細ごとに金額、日付、税区分と、添付されたレシートを取り出します。ベンダーAPIに関わる部分なので、コードは擬似コードにしています。

# バクラクAPIで「申請中の経費精算」を取得し、明細ごとに
# 金額・日付・税区分・レシート（添付ファイル）を取り出してDLする
applications = bakuraku.fetch_requests(status="IN_PROGRESS", form="経費精算申請")
receipt_bytes = bakuraku.download(f"/workflow/user_upload_files/{file_id}/file")

PDFにテキスト層が残っていれば、PyMuPDFで文字をそのまま取れます。文字を取得できない画像やスキャンは空文字を返しておいて、後段のAI-OCRへ回します。

import fitz  # PyMuPDF

def extract_text(path: str) -> str:
    """PDF/画像からテキストを抽出する。テキスト層が無ければ空文字。"""
    try:
        with fitz.open(path) as doc:
            return "".join(page.get_text() for page in doc)
    except Exception:
        return ""

文字が取れたら、申請明細の税込金額がその中にあるかを探します。ここで効いてくるのが、レシートの数字の癖です。桁の間に空白や改行が入っていることがあるんです。なので、空白とカンマを除いてから突合しています。

import re

def amount_in_text(amount: int, text: str) -> bool:
    """金額がテキストに出現するか（空白・カンマ・改行を吸収）。"""
    if not amount:
        return None
    flat = re.sub(r"[\s,，]", "", text)      # 空白とカンマを全除去
    return str(abs(int(amount))) in flat

この突合で分かるのは、あくまで「金額の文字列があるか」までです。証憑全体が妥当だと保証してくれるわけではありません。それでも、取得できる文字を毎回AIに解釈させるより、同じ条件で速く再実行できます。

ClaudeのOCRに回すのは、文字を取れない画像だけ

肝心の分岐は、if文がひとつあるだけです。テキスト層があればPythonで金額を探して、なければ「要OCR」としてClaudeへ渡します。

if has_text_layer:
    verdict = "OK" if amount_in_text(amount, text) else "要確認(金額不一致)"
else:
    verdict = "要OCR(Claude)"     # ← 画像はここでAIに回す

AIの仕事として残したのは、画像から文字を読むことと、証憑の種類や税率の混在を文脈から整理することです。逆に、テキスト層のある証憑まで同じ流れに乗せると、判定がぶれやすくなるうえに、AIの利用量も増えます。読ませる範囲を絞ったのは、そのためです。

全件突合で引っかかった3つの要確認パターン

この仕組みを実際の申請に当てたところ、目視では見落としやすいパターンが3つ見つかりました。申請者や金額などの内容は伏せています。

合計は合っているのに、明細の金額がない分割計上

1つめが、冒頭のレシートです。1枚の合計を複数の明細に分けてあるので、合計額は正しいのに、明細単位で突合すると金額不一致になります。ただ、この不一致がそのまま不正や誤りを意味するわけではありません。機械にできるのは不一致を指摘するところまでで、按分の理由や申請方法が妥当かどうかは、人が確認します。

申請は10%、レシートには8%が混ざる税率

2つめは税率の混在です。申請明細は課税10%なのに、レシートには軽減8%や対象外が含まれているパターンです。レシートに何が書かれているかを文脈から読み取って整理する部分は、AIに任せられます。整理した税区分の候補は、要確認の根拠として申請に添えて返します。

登録番号のない予約確認書やフリマの画面

3つめは、適格請求書に当たらない証憑です。予約確認書やフリマの取引画面など、登録番号のない証憑が添付されていると、番号の有無で引っかかります。ただ、そういう証憑しかない申請をどう扱うかは、会社の規程の話です。なので仕組みの側は、読み取った証憑の種類と、登録番号がないという事実を添えて申請を返すところまでにしています。

Python、AI、人の担当と止める条件

担当の線引きでは、「誰が何をやるか」だけでなく、「どこで止めるか」もあわせて決めてあります。

機械とAIに任せたのは、すべての明細を同じ条件で確認して、要確認の根拠を添えて人へ返すところまでです。その先の承認と差し戻しは、人が会社の規程と責任に基づいて決めます。さっきの3パターンで最後の判断がどれも人に残っているのは、この線引きのとおりに動いた結果です。

同じ例外を2度書かないためのコード側の決めごと

経費精算と支払申請に共通する取得、文字抽出、正規化は、共通ヘルパーへ切り出して使い回しています。それから、同じ例外が繰り返されたときは、AI向けの注意書きを足して済ませず、判定コードを直してテストも追加するようにしています。

これから同じ照合を組むなら、最初からAI-OCRを全件に当てる必要はありません。まずはテキスト層のあるPDFだけを対象に、金額の突合をif文ひとつで動かしてみてください。それだけでも、明細単位の不一致は拾えます。文字を取れない証憑が実際にどれくらい混ざるかを見てから、AIに読ませる範囲を決めても遅くありません。

この実践で見えてきた会計ソフト選びの条件は、連載最終回のAPI比較で整理しています。

AI会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準会計ソフトをAPIで比較するときに見たいのは、利用条件、読み書きの範囲、制限と料金、検証と統制の4点です…→

この「残り半分」で引っかかった申請が、実際にありました。新規取引先の登録申請をAIにチェックさせていたときのことです。申請された商号は登記上の商号と一致しています。それなのに、入力されていた法人番号は合併で閉鎖された法人のもので、存続会社には別の法人番号がありました。商号だけを見ていたら、そのまま通していたかもしれません。

この不一致を見つけたのはAIです。バクラクの申請内容と国税庁の情報を照合させて、法人番号の形式を確かめたうえで、商号、インボイス番号、閉鎖年月日、承継先を調べ、問題のある申請だけを「要確認」に振り分けてもらいました。

といっても、会社が実在するかどうかをAIの知識だけで推測させたわけではありません。法人番号は計算式で検算し、会社情報は国税庁の公式Web-APIから取得します。そして、最後に承認するか差し戻すかを決めるのは人です。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制はどう設計する？作業と責任、証跡の分け方
2. 新規取引先チェックをAIで自動化｜合併で閉鎖された法人番号を見つけた方法（この記事）
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

この実例でAIに任せたのは、公式情報を集めて不一致を見つけるところまでです。引っかかった申請をどう扱うかは、人が根拠を見て決めました。

新規取引先チェックで見ている4つの項目

そもそも新規取引先の登録申請で私が確認しているのは、少なくとも次の4つです。

• 法人が実在するか
• 申請された商号と登記上の商号が一致するか
• インボイス登録番号と法人番号が整合するか
• 法人番号が正しい形式で、その法人が閉鎖または合併済みではないか

13桁がそろって見えても、入力ミスはあり得ます。それに今回のように、商号は合っているのに中の番号だけが古い、というケースも実際にあるわけです。だから、番号の形式を検算する工程と、公式情報と照合する工程を分けることにしました。

申請の取得と、法人番号13桁の検算

この工程で確かめるのは、番号の形式だけです。流れの最初は、バクラクから申請中の新規取引先申請を取ってくるところ。ベンダーAPIに関わる部分は、公開できる範囲に絞った擬似コードにしています。

# バクラクAPIで「申請中の新規取引先申請」を取得し、
# 各申請から 法人番号・取引先名・インボイス番号 を取り出す
applications = bakuraku.fetch_requests(status="IN_PROGRESS", form="新規取引先申請")

取り出した法人番号は、まず手元で検算します。法人番号は、12桁の基礎番号の前にチェックディジット1桁を付けた13桁で、計算方法は国税庁が公開しています。つまり、番号が形式どおりかどうかは、APIに聞くまでもなく確かめられます。

def validate_corporate_number(number: str) -> bool:
    """法人番号13桁のチェックディジットを検証する。"""
    if not number or len(number) != 13 or not number.isdigit():
        return False
    check_digit = int(number[0])
    base = number[1:]                      # 下位12桁が基礎番号
    total = 0
    for i, ch in enumerate(reversed(base)):
        weight = 2 if i % 2 == 1 else 1    # 右から 奇数桁=1, 偶数桁=2
        total += int(ch) * weight
    return (9 - (total % 9)) == check_digit

ただ、この検算で分かるのは「番号が計算式に合っているか」だけなんです。その法人が実在するのか、いまも同じ番号が有効なのかは、ここでは何も分かりません。

実在と閉鎖状態は、国税庁の法人番号Web-APIで照合する

法人の実在と商号、閉鎖状態は、国税庁の法人番号Web-APIに問い合わせます。Web-API Ver.4はCSV（Unicode）を指定して法人情報を取得でき、利用には無料で発行されるアプリIDが必要です。

import csv, requests

NTA_API = "https://api.houjin-bangou.nta.go.jp"

def nta_lookup(numbers: list[str], app_id: str, version: str = "4") -> dict:
    """国税庁 法人番号Web-APIで 実在・商号・閉鎖 を照会する。"""
    resp = requests.get(
        f"{NTA_API}/{version}/num",
        params={
            "id": app_id,                 # 無料発行のアプリID
            "number": ",".join(numbers),  # 最大10件まとめて
            "type": "02",                 # CSV(Unicode)で受け取る
            "history": "0",               # 最新の登記のみ
        },
    )
    resp.raise_for_status()
    records = {}
    for row in csv.reader(resp.content.decode("utf-8").splitlines()):
        if len(row) <= 20:
            continue                      # ヘッダー行などをskip
        records[row[1]] = {               # row[1] = 法人番号
            "name":      row[6],          # 商号
            "closeDate": row[18],         # 閉鎖年月日（合併・解散など）
            "successor": row[20],         # 承継先の法人番号
        }
    return records

今回の件で効いたのは、このうち閉鎖年月日と承継先の項目でした。商号が一致するかだけでなく、「その番号がいまも生きているか」まで同じ照会で確認できます。あとは取得した情報と申請内容を比べて、問題がなければOK、条件に1つでも当てはまれば要確認、という判定にしました。

issues = []
if not validate_corporate_number(corp):
    issues.append("法人番号CD不正")
if invoice and invoice != "T" + corp:
    issues.append("インボイス番号不整合")
if record is None:
    issues.append("国税庁に該当なし")
elif record["closeDate"]:                       # ← ここが効いた
    issues.append("閉鎖/合併（承継先: " + (record["successor"] or "不明") + "）")
elif normalize(client_name) != normalize(record["name"]):
    issues.append("商号不一致")

verdict = "要確認" if issues else "OK"

見てのとおり、法人番号や会社情報をAIの知識で判定させている箇所はありません。判定材料は、計算結果とAPIのレスポンスだけです。それでも、商号の表記をそろえる方法や例外条件が間違っていれば、誤判定は起きます。だから、コードが動いたかどうかだけでなく、出てきた判定結果まで確かめるようにしています。

商号は合っていた。それでも閉鎖年月日が返ってきた

で、冒頭の申請です。APIの応答には閉鎖年月日が入っていて、合併後の承継先として別の法人番号も返ってきました。申請された商号と登記上の商号を見比べても、違和感はどこにもありません。番号の中身だけが古かったわけです。

この申請は自動承認せず、閉鎖年月日と承継先を根拠に「要確認」で止めました。申請者へ差し戻したのは私です。AIに任せたのは、全件を同じ条件で調べて、人が見るべき申請を絞り込むところまででした。

アプリIDがない間はWeb検索で暫定確認

国税庁のWeb-APIには、1つ前提があります。無料とはいえ、アプリIDが発行されるまでは使えないことです。発行を待つ間など、すぐにAPIを使えない場合のために、法人番号データベースの houjin.info やhoujin.jpをAIに検索させて、商号や所在地、閉鎖状態、承継先を確認する手順も用意しました。

• 番号から商号、所在地、登記状態、承継先を確認する
• 申請された商号や住所と照合し、不一致があれば「要確認」にする
• 参照URLと確認日を残し、番号をAIに生成させない
• 重要な判断は国税庁の公表サイトまたは公式APIで再確認する

この手順はプロジェクトのREADMEに置いて、AIが作業を始めるときに読める場所にしています。とはいえ、第三者サイトの更新時点や表示内容が、公式情報と同じとは限りません。なので位置づけは、あくまで暫定確認と根拠集めです。APIの代わりにずっと使うつもりはありません。

照合コードもAIに書いてもらった

ここまで載せたコードを、私がすべて手で書いたわけではありません。確認したい項目と正常例、異常例、出力形式をAIに渡して、初稿と修正案を作ってもらいました。私がやったのは、チェックディジットの計算式とAPIのレスポンス、実際の判定結果を確かめることです。

実装を一から書けない私でも、業務の要件を説明して結果を確かめることで、こういう確認ツールを作れるようになりました。もっとも、コードが動いたからといって、そのまま会社の承認ルールに使えるとは限りません。

同じ考え方は経費精算にも広げていて、レシートと申請明細は全件突合し、画像しかない証憑だけをAI-OCRに回しています。

経理経費精算のレシート照合をAI-OCRで自動化｜分割計上も検知経費精算のレシートと申請明細を全件突合しました。文字を取り出せるPDFはPythonで照合し、画像だけを…→

振り返ると、商号が合っていた閉鎖法人の申請を止められたのは、AIの推測が当たったからではありません。13桁の検算と国税庁の情報を根拠に「要確認」で止め、最後は人が差し戻すという流れを、先に作っておいたからです。

実装時に確認した公式情報

• 国税庁：法人番号システムWeb-API Ver.4
• 国税庁：チェックディジットの計算

この申請を差し戻すと決めたのは、AIではなく私です。判定を鵜呑みにしたわけではなく、閉鎖年月日と承継先を確かめたうえで決めました。根拠を集めて異常を見つける仕事と、会社として承認するかどうかを決める仕事は、分けて考えています。

経理にAIを入れる話は、「任せられるか、任せられないか」の二択で語られがちです。ただ、内部統制まで含めて考えると、この二択では足りません。繰り返し作業を誰に任せ、判断材料をどうそろえ、誰が承認し、どんな記録を残すか。そこまで決めて、ようやく運用に乗ります。

連載「経理をAIに任せる」（全4回）

1. 経理AIの内部統制はどう設計する？作業と責任、証跡の分け方（この記事）
2. 新規取引先チェックをAIで自動化｜合併で閉鎖された法人番号を見つけた方法
3. 経費精算のレシートと明細を、AIに全部突合させてみた
4. 会計ソフトのAPI比較｜AI経理で確認したい4つの選定基準

この連載で書いた3つの実務は、どれも「根拠を集めて不一致を探す」ところまでは自動化できました。それでも、承認と差し戻しだけは人の仕事として残っています。

「経理はAIに任せられない」の中身

「経理はAIに任せられない」という声に、私は反論しません。仕訳や申告、承認、内部統制には責任が伴いますから、全部をまるごと自動化する前提なら、私も同じ判断をします。

ただ、1件の処理をほどいてみると、承認責任とは別に、毎回同じことを繰り返している作業がかなり詰まっています。

• 証憑から金額、日付、登録番号を読む
• 法人番号やインボイス番号の形式を検査する
• 申請内容をマスタ、規程、過去実績と突合する
• 不一致と低確信の対象だけを一覧にする

冒頭の閉鎖法人を拾ったのも、この種の突合と抽出の組み合わせです。決められたルールにAPI、OCR、AIを組み合わせれば、このあたりは自動化するか、判断の補助へ回せます。

一方で、業務の要件を決める仕事、例外を承認する仕事、処理結果に責任を持つ仕事は、人に残ります。金融庁が公表している財務報告に係る内部統制の枠組みでも、内部統制を整備して運用し、その有効性を評価する責任は経営者にあるとされています。AIを使ったからといって、この責任までAIへ移るわけではありません。

入力、判定、証跡、承認の4層

どう分けるか。私が先に手を入れたのは、AIモデルの精度ではありませんでした。入口のデータがばらばらなままでは、モデルだけ賢くしても処理は安定しません。直したのは、業務をAIへ渡すときの形でした。

自由記述を選択式に変える、取引先名や科目の表記をマスタに寄せる、読み取れない証憑は例外としてそこで止める。どれも地味な準備です。ただ、これがあると、あとから「なぜこの判定になったのか」をずっと追いやすくなります。

要確認だけが人へ戻ってくる流れ

実際の運用では、金額そのものをAIに考えさせていません。金額の計算や番号の検算は、答えが1つに決まるルールで処理します。AIへ回すのは、画像の読み取りや分類、複数資料の照合、例外理由の整理といった、曖昧さの残る仕事です。

新規取引先のチェックでは、法人番号と商号、インボイス番号、閉鎖状態を照合し、合併で閉鎖された法人番号を「要確認」にしました。経費精算では、テキスト層のある証憑なら機械でそのまま金額を突合します。画像しかない証憑だけをAI-OCRへ回し、分割計上や税率が混在するものは人が確認する流れです。

こうしておくと、人が全件を最初から読み直す必要はなくなります。根拠と一緒に上がってきた例外の確認に集中できるわけです。ただ、正直に言うと、手放しにはできません。確信度を「低い」と判断する基準は適切か。見逃しているパターンはないか。この2点は、運用が回り始めたあとも確認し続けます。

AI前提の内部統制と監査は、まだ読めない

ここから先は、制度の解説ではなく、実務でAIを使っている立場からの見立てとして読んでください。

上場企業のように統制要件が厳しい組織では、機密情報の扱いや職務分掌、監査人への説明、利用モデルの変更管理まで考えることになります。その分、AIの利用をすぐ全社へ広げにくい場面もあるはずです。逆に、統制する範囲が小さめの組織なら、業務を限定して試しやすいこともあります。規模や区分だけで一律に決まる話ではありませんが、どこまで説明し、誰が承認するかは、導入の速さに響きます。

制度の側も動いてはいます。2026年3月末に経済産業省が公表したAI事業者ガイドライン第1.2版には、AIガバナンスを継続して見直すためのチェックリストやワークシートも付いています。ただし、現行の内部統制や監査の制度で、承認責任がAIへ移ったわけではありません。

将来は、AIが残した証跡をどう評価するか、継続的にどう監視するか、AIそのものをどう統制するか、というところまで実務に組み込まれる可能性があると見ています。いつ、どんな制度になるかは断定できません。それでも、入力をそろえ、根拠とログを残し、例外のときに誰が承認するかを決めておく準備は、制度が変わらなくても役に立ちます。

全社方針より先に、業務1つの棚卸し

経理AIの内部統制を、いきなり全社方針から考え始めると、対象が広すぎて動きにくくなります。私なら、件数が多くて、いまの確認手順を説明できる業務を1つ選ぶところから始めます。

1. 入力データと参照元を列挙する
2. 計算、形式検査、マスタ突合を定型処理へ分ける
3. AIに任せる作業を、分類、OCR、例外調査に分ける
4. 必ず人へ戻す条件と承認者を決める
5. 入力、参照元、判定、承認結果を記録する

冒頭の閉鎖法人に戻ると、あのとき役に立ったのは「AIが見つけた」という結果だけではありませんでした。国税庁の情報で閉鎖年月日と承継先を確かめて根拠を記録し、申請を「要確認」でいったん止め、最後に人が差し戻す。この一連の流れが切れずにつながっていたから、実務で使えたんです。

作業をAIに任せても、誰が決めたのかは曖昧にしません。内部統制はAIを使わないための仕組みではなく、根拠を残しながら使うための仕組みです。

制度とガバナンスの参考資料

• 金融庁：財務報告に係る内部統制の評価及び監査の基準
• 経済産業省：AI事業者ガイドライン第1.2版