経理業務をAIエージェントに任せる範囲 ― 証憑・請求・照合と人間承認ゲートの設計

経理の作業は、AIエージェントに向いているように見えます。PDFを読み、日付と金額を拾い、決まった形式に並べる。どれも言語モデルが得意な処理です。それでも導入の検討が止まりやすいのは、技術より先に「間違えたとき、誰が何を失うか」という問題があるからです。

仕訳を間違えても、気づけば修正仕訳で直せます。振込先を間違えた送金は、相手の協力がなければ戻りません。同じ「経理のミス」でも、取り返せるかどうかがまったく違います。だから、全部をAIに任せる設計はうまくいきにくく、AIが処理し、人間が承認する設計のほうが現実的です。

この記事では、個人から小規模の事業（自社SaaSと受託開発）を前提に、証憑の仕訳ドラフト、請求書の作成と送付、入金照合と督促の3つの業務について、エージェントにどこまで任せ、どこで人間が止めるかを設計します。前回のキャッシュフローをカレンダーで管理する記事で作ったledger.csvを、請求と照合で使い回す続編でもあります。

※2026年10月9日時点の公開情報に基づきます。本文は設計の検討内容で、正解率などの実測値は載せていません。代わりに測り方を書いています。設定例・データ例は説明用の架空のもので、動作検証はしていません。勘定科目や税務の判断は、使っている会計ソフトの仕様と税理士の確認を優先してください。

誤記帳は直せる。誤送金は戻らない

経理をAIに任せる話は、「全部自動」か「使わない」かの二択になりがちです。実際には、操作によって取り返せる度合いが違います。線は業務単位ではなく、操作単位で引きます。

表の下に行くほど、間違いの影響が事業の外へ出ていきます。この記事の設計では、上の2行をエージェントに任せ、3行目以降は必ず人間の判断を挟みます。出金はエージェントの権限から外し、ネットバンキングの操作も人間が行う前提です。

権限で線を引くのには理由があります。会計ソフトのAPIは、読み取りだけでなく書き込みもできるからです。たとえばfreee会計のAPIには、取引（収入・支出）を作成するPOST /api/1/dealsや、ファイルボックスへ証憑をアップロードするPOST /api/1/receiptsがあります。エージェントに渡したトークンが書き込める権限を持っていれば、プロンプトでいくら「登録しないで」と頼んでも、登録できる状態は残ります。できることは、指示ではなく権限で制限します。

もう一つ、承認したという記録を残すことも原則に入れます。後から「この請求書は誰が送ってよいと判断したか」を説明できなければ、AIが処理したのか人間が判断したのかが曖昧になります。

証憑は仕訳案まで。記帳はしない

1つ目は、領収書や請求書から仕訳の下書きを作る業務です。エージェントの仕事は、仕訳案を作るところまで。会計ソフトへの登録はしません。

1. 集める：メールの添付やダウンロードしたPDFを受信フォルダに集める。原本は書き換えず、ファイルのハッシュ値を控える
2. 読む：PDFからテキストを取り出す。画像だけのPDFや、撮影した紙の領収書はOCRにかける
3. 項目に分ける：言語モデルに、決めた項目のJSONで返させる
4. 科目の候補を付ける：過去の確定仕訳から、同じ取引先や似た品名の科目を引いて候補にする
5. 渡す：仕訳案のCSVと、どこから読んだかの根拠を人間に渡す

項目に分けた結果は、たとえば次のような形にします（値はすべて架空です）。

{
  "source_file": "inbox/2026-10/receipt_0012.pdf",
  "source_sha256": "9f2c…（原本のハッシュ値）",
  "issuer": "株式会社サンプル商事",
  "registration_number": "T1234567890123",
  "transaction_date": "2026-10-03",
  "total_amount": 13200,
  "tax_breakdown": [
    {"rate": 10, "amount_incl_tax": 13200, "tax": 1200}
  ],
  "account_candidates": [
    {"account": "消耗品費", "reason": "同じ取引先の過去仕訳3件が消耗品費"},
    {"account": "工具器具備品", "reason": "品名にモニターを含む"}
  ],
  "needs_review": ["品名だけでは資産計上の要否を判断できない"]
}

項目は、国税庁が示している適格請求書（インボイス）の記載事項に合わせておくと使いやすくなります。記載事項は、交付を受ける相手の氏名または名称、発行者の氏名または名称と登録番号、取引年月日、取引内容（軽減税率の対象品目である旨を含む）、税率ごとに区分した対価の合計額と適用税率、税率ごとの消費税額等です。項目がそろっていれば、「登録番号がない」「税率ごとの区分がない」といった不足を、読み取った時点で指摘できます。指摘まではエージェントの仕事で、仕入税額控除をどう扱うかを決めるのは人間です。

外れやすいのは、証憑の外にある情報で決まる科目

勘定科目の候補は、日付や金額の読み取りより外れやすい部分です。証憑に書かれた文字だけでは決まらず、何のために使ったかという、紙の外の事情で決まるからです。確認対象に入れておきたい組み合わせを挙げます。実測した間違いのランキングではなく、決め手が証憑の外にあるものを選んでいます。

どれも、モデルの性能より「その事業での決め方」で答えが決まります。過去の確定仕訳を候補に使うのはそのためです。ただし、過去の判断が間違っていれば、その間違いも引き継ぎます。候補には必ず根拠を付けさせ、人間が根拠ごと見て判断できるようにします。

記帳しないほうが、レビューは楽になる

仕訳案で止める理由は、慎重さだけではありません。会計ソフトへ直接登録させると、人間の作業は「登録済みの取引の中から、間違っているものを探して直す」になります。仕訳案のCSVで受け取れば、まだ確定していない行だけを上から順に見て、直してから取り込めます。確定した行を会計ソフトへ取り込む操作は人間が行います。

精度は、人間が確定した値と仕訳案を項目ごとに比べて測ります。日付、金額、登録番号、科目の一致率を別々に出す。科目だけが外れているなら過去仕訳の引き方を、金額が外れているならOCRを見直す、と原因を分けられます。全体の正解率を1つの数字にまとめると、どこを直せばよいかがわからなくなります。

原本はエージェントの書き込み対象から外す

電子データで受け取った請求書や領収書は、電子帳簿保存法により、一定の要件を満たした形でデータのまま保存する必要があります。エージェントにPDFのリネームや加工までさせると、どれが受け取ったときのままの原本なのかがわからなくなります。読み取りは原本のコピーに対して行い、原本の保存場所はエージェントが書き込めない場所にしておきます。保存要件の詳細は、国税庁の「電子取引データ保存要件チェックシート」で確認してください。

請求書は作るまでAI、送るのは承認の後

2つ目は請求です。受託開発の請求は、作業ログから明細を起こすところに手間がかかります。gitのコミット履歴やタイムシートを読み、案件ごとの作業内容を並べる処理はエージェントに任せられます。

ただし、コミットの数や作業時間が、そのまま請求額になるとは限りません。月額固定の保守契約なら作業量に関係なく同じ額ですし、時間精算でも、上限や請求しない作業が契約で決まっていることがあります。単価と精算方法は、エージェントに推測させず、契約マスタから読ませます。契約マスタは、取引先ごとの単価、精算方法、締め日、支払期日、請求書の送付先を書いた表です。マスタにない取引先は、それだけで承認に回します。

承認で見るのは4点と、その差分

金額・件数・単価に宛先を加えたのは、送付の誤りがいちばん取り返しにくいからです。別の取引先に請求書が届けば、金額の誤りとは別に、取引情報の漏えいになります。

承認画面には、この4点と、前月や契約マスタとの差分だけを出します。全明細を毎回読ませる承認は、続けるうちに読まずに押す承認になりやすい。差分がない月は短く、差分がある月だけ詳しく見せる形にします。

承認した請求書と、送る請求書を一致させる

承認した後で請求書が書き換わると、承認した意味がなくなります。承認の時点で請求書PDFのハッシュ値を記録し、送付処理は同じハッシュ値のファイルだけを送るようにします。MCPでデプロイ承認を実装したMCPサーバー実装の後編で、実行内容を署名付きトークンに固めてから承認を求めたのと同じ考え方です。計画を作る処理と実行する処理を分け、その間に人間を置きます。

送った後は、台帳と入金予定に1行ずつ

送付したら、送付済みの台帳に請求番号、送付日時、承認者を記録します。あわせて、前回の記事のledger.csvに入金予定の行を1行追加します。区分は「予定入金」、備考には請求番号を入れ、入金を確認したら同じ識別子の行を実績に置き換えます。請求と資金繰りが同じ識別子でつながるので、次の照合で使えます。

照合は任せる。消し込みの確定と督促は人間

3つ目は、銀行の明細CSVと請求台帳を突き合わせる照合です。読むだけの処理なので、任せやすい業務です。確実なものから順に当てていきます。

1. 完全一致：金額、振込名義、期日前後の日付がそろっている
2. 差額つきの一致：振込手数料を差し引いた金額で一致する（手数料をどちらが負担するかは契約で確認する）
3. あいまいな一致：名義のカナ表記の揺れ、複数の請求をまとめた入金、分割での入金

自動で消し込んでよいのは1だけ、というのがこの設計の線です。2と3は候補として出し、人間が確定します。同じ金額の請求が複数あるとき、金額だけでひも付けると別の請求を消し込んでしまいます。前回の記事でも書いたとおり、銀行の取引IDや請求番号を照合のキーにします。

未入金の一覧と、督促文の候補を3つ

期日を過ぎた請求は、超過日数と金額で並べた一覧にします。エージェントは、それぞれに督促文の候補を3つのトーンで作ります。

どれを送るかは人間が決めます。入金が遅れた理由は、明細だけではわかりません。先方の支払処理の都合かもしれないし、こちらの請求書に不備があったのかもしれない。理由がわからない段階で強い文面を送ると、取引関係そのものに傷がつきます。そのリスクをエージェントに負わせない、というのが督促を承認に通す理由です。

承認の条件は、AIの外にルールで書く

3つの業務に共通するのは、「いつ人間が必ず見るか」を先にルールとして書いておくことです。AIに「危なそうなら聞いて」と頼む設計だと、危ないかどうかの判断がAIに残ります。条件は、言語モデルの判断とは別のコードで評価します。

# approval_rules.yaml（説明用の例。値は仮で、動作検証はしていない）
always_require_approval:
  - action: send_invoice          # 請求書の送付
  - action: send_reminder         # 督促メールの送信
  - action: confirm_reconcile     # あいまい一致の消し込み確定
extra_review_when:
  - amount_jpy > 300000           # 金額の上限
  - first_transaction == true     # 初めての取引先
  - destination_changed == true   # 送付先・振込先の変更
  - change_vs_last_month > 0.3    # 前月比30%超の増減
  - outside_business_hours == true
  - model_flagged_uncertain == true
deny:
  - action: execute_payment       # 出金はエージェントの権限外
  - action: post_to_accounting    # 会計ソフトへの登録は人間が行う

金額の上限や前月比の値は仮のものです。事業の規模と、間違えたときに耐えられる額から決めます。営業時間外を条件に入れているのは、すぐに相手へ確認できない時間帯の処理を、翌営業日の人間の目に回すためです。

送付先・振込先の変更は、特に重く扱う

IPAは、取引先になりすまして、攻撃者の口座に差し替えた偽の請求書を送り、振り込ませる手口をビジネスメール詐欺（BEC）のパターンとして挙げています。対策としては、急な振込先や決済手段の変更があった場合に、取引先へメール以外の方法で確認することを示しています。

エージェントがメールを読んで取引先マスタを更新する設計にすると、偽の変更依頼がそのままマスタに入りかねません。メールから読み取った変更は「変更依頼があった」という通知に留め、マスタの書き換えは、登録済みの電話番号などメール以外の経路で確認してから人間が行います。

承認の手段は何でもよい。残す項目はそろえる

承認はSlackのボタンでもメールでも構いません。ただし、記録に残す項目はそろえます。誰が、いつ、何を（対象ファイルのハッシュ値）、どの条件で承認に回ってきたものを、承認したか却下したか。コメントがあればそれも残します。

ボタンを押しやすくしすぎると、内容を見ずに押す習慣がつきます。金額の上限を超えたものだけは、ボタンではなく内容を開いて確認する画面に誘導するなど、条件によって承認の手間を変える方法もあります。

この記録が効いてくるのは、たいてい数か月後です。取引先との行き違いや、申告内容の確認で「この請求はどういう判断で送ったのか」を説明する必要が出たとき、承認ログがあれば、AIが作り、誰がいつ確認して送ったかを順に示せます。

導入は、外に何も出ない業務から

始める順番は、取り返しのつかない操作が出てくるのが遅い順にします。

1. 証憑の仕訳案：外には何も出ない。まず項目ごとの一致率を測る
2. 請求書の下書き：作成はエージェント、送付はこれまでどおり人間が手で行う。差分の出し方が固まってから、承認つきの送付をエージェントに任せる
3. 照合と督促の候補：照合は読むだけ。督促の送信は承認を通す

決済や送金そのものをエージェントに実行させる設計は、この記事では扱いません。出金の権限を渡さないことが、ここまでの設計の前提です。

動かす前に、次の点を確認しておきます。

• エージェントのトークンから、会計ソフトへの書き込みと出金に関わる権限を外した
• 原本の保存場所を、エージェントの書き込み対象から外した
• 承認の条件を、言語モデルとは別のコードで評価している
• 承認した内容のハッシュ値と、実際に送った内容が一致することを確かめている
• 誰が、いつ、何を承認したかのログが残る
• 送付先・振込先の変更は、メール以外の経路で確認する手順がある

エージェントが速くなるのは処理の部分です。判断と責任は人間の側に残る。その境界を、権限とルールと記録で目に見える形にしておけば、経理をAIに渡す範囲は少しずつ広げられます。

確認した公式資料

• 国税庁：インボイス制度について — 適格請求書の記載事項。
• 国税庁：電子帳簿保存法 電子取引関係 — 電子取引データの保存、保存要件チェックシート、令和7年度改正の概要。
• freee Developers Community：会計APIリファレンス — 取引の作成（POST /api/1/deals）、ファイルボックスへのアップロード（POST /api/1/receipts）。公開されているOpenAPIスキーマ（freee/freee-api-schema）でも確認。
• IPA：ビジネスメール詐欺のパターンとは と ビジネスメール詐欺の対策について知る — 偽の請求書による振込先の差し替えと、メール以外での確認。