経理DX AIエージェント 4層分離設計ガイド 2026：入力/照合/例外処理/承認の自動化

経理業務のDX（デジタルトランスフォーメーション）において、単なるツールの導入は根本的な解決になりません。真の自動化を実現するには、業務プロセスを「入力」「照合」「例外処理」「承認」の4つのレイヤーに分解し、それぞれを独立したAIエージェントやSaaSで機能させる設計思想が不可欠です。本ガイドでは、実務者が直面する「SaaS間のデータ分断」や「例外処理の属人化」を排除し、検索エンジンの上位を占める表面的な解説を超えた、実装レベルのアーキテクチャを詳説します。

1. 経理DXにおける「4層分離」設計の重要性

従来の経理業務が自動化できない最大の理由は、一人の担当者が「入力から承認まで」を一つの流れとして処理していることにあります。これをAIエージェントに置き換えるには、以下の責務分解が必要です。

• 入力レイヤー：OCRやAPIによる構造化データへの変換
• 照合レイヤー：マスタデータや取引条件との自動マッチング
• 例外処理レイヤー：アンマッチデータの差分分析と推論
• 承認レイヤー：内部統制に基づいた最終証跡の記録

この分離により、例えば「入力」の精度が低い場合でも、後続の「照合」ロジックでエラーを検知し、「例外処理」エージェントが過去の履歴から補正案を提示するといった、強靭な自動化ラインが構築できます。

2. 【入力・照合】AI-OCRとSaaSの選定・比較

「入力」の自動化は、領収書や請求書の電子化から始まります。ここでは、単なる文字認識（OCR）ではなく、後続の仕訳連携までを見据えたツール選定が肝要です。

主要経理SaaS・AI-OCR比較表

特に、中堅企業以上の規模では、会計ソフト標準のOCR機能だけでは不十分なケースが多いです。以下の関連記事で詳しく解説している通り、責務を分ける設計が重要になります。

【完全版】「とりあえず電帳法対応」で導入したシステムが経理を殺す。Bill One等の受取SaaSと会計ソフトの正しい責務分解

公式事例とURL

• バクラク（株式会社LayerX）

  【公式URL】 https://bakuraku.jp/

  【導入事例】 株式会社メルカリ：紙の請求書受領を廃止し、月間数千件の請求書処理を効率化。

• Bill One（Sansan株式会社）

  【公式URL】 https://bill-one.com/

  【導入事例】 日本航空株式会社（JAL）：グループ全体での請求書受領をデジタル化し、拠点間の郵送コストと開封作業を撤廃。

3. 【例外処理】AIエージェントによる推論エンジンの構築

自動化が挫折する最大の原因は「1円の端数不一致」や「未登録の勘定科目」といった例外です。これをLLM（大規模言語モデル）を活用したAIエージェントで解決する設計手順を解説します。

ステップバイステップ：AIによる勘定科目推論の実装

1. データの構造化：OCRで抽出したテキスト（支払先、品目、金額）をJSON形式に変換する。
2. 文脈の付与：過去1年分の仕訳日記帳（CSV）から、類似した「支払先名」の仕訳パターンを検索する（ベクトル検索やRAGの活用）。
3. プロンプトエンジニアリング：AIに対し、「以下の請求項目と過去の仕訳履歴を比較し、最も可能性の高い勘定科目と補助科目を提案せよ。また、その確信度を0-1で示せ」と命令する。
4. 人間による確認（Human-in-the-loop）：確信度が0.8以下のもの、または新規の支払先のみを人間にトスアップする。

このプロセスにおいて、特に銀行振込の消込業務では手数料の処理が課題となります。

【完全版】freeeの「自動消込」が効かない？ 振込手数料ズレと合算払いを撲滅する「バーチャル口座」決済アーキテクチャ

4. トラブルシューティング：自動化ラインの「死」を防ぐ

運用開始後に必ず発生するエラーとその解決策を整理しました。

よくあるエラーと解決策

5. 内部統制と承認フローの自動化

AIがどれほど進化しても、最終的な承認責任は人間が負います。しかし、承認のための「資料作成」や「数値の裏取り」はAIが肩代わり可能です。

例えば、Salesforceとfreeeの連携においては、商談の受注状況（SFA）と実際の請求発行（会計）が一致しているかをAIが常時監視し、差異がある場合のみ承認者にアラートを出す仕組みが有効です。

Salesforceとfreeeを繋いでも「サブスク売上」は自動化できない。前受金管理とバクラクを活用した一括請求アーキテクチャ

Claude Code で4層分離設計を実装する：具体的なコード構成とCLAUDE.md設定

経理DXの4層分離（入力/照合/例外処理/承認）をClaude Codeで実装する場合のコード構成と、Claude Codeへの指示ファイル（CLAUDE.md）の設定方法を整理します。

Claude Codeでの4層実装パターン：ディレクトリ構成

Claude Codeプロジェクトとして経理DXシステムを構築する場合の推奨ディレクトリ構成です。

accounting-dx/
├── CLAUDE.md           # Claude Codeへの全体指示・制約ルール
├── layer1_input/       # Layer1: 入力・OCR処理
│   ├── freee_client.py     # freee API クライアント
│   └── ocr_processor.py    # AI-OCR・電帳法対応
├── layer2_matching/    # Layer2: 照合処理
│   ├── invoice_matcher.py  # 請求書と入金の突合
│   └── rules.json          # 照合ルール定義
├── layer3_exception/   # Layer3: 例外処理（Claude API呼び出し）
│   ├── claude_agent.py     # 例外仕訳の科目提案
│   └── escalation.py       # 人間へのエスカレーション
├── layer4_approval/    # Layer4: 承認フロー
│   ├── approver.py         # 承認ワークフロー管理
│   └── audit_log.py        # 監査ログ記録
└── tests/              # テストコード（Claude Codeで自動生成）

CLAUDE.md の設定例：Layer3（例外処理）の制約ルール

Claude Codeが例外処理を行う際の制約ルールをCLAUDE.mdに明記します。制約を明文化することで、AIが勝手に「書き込み」操作を行うリスクを防ぎます。

# 経理DX自動化システム - Claude Code 実行ルール

## Layer3（例外処理）の制約

- freee APIへの書き込み（仕訳登録・取引更新）は、承認フラグ approved=True の場合のみ実行
- 金額が50,000円以上の仕訳は自動実行禁止。必ず layer4_approval に渡す
- 科目候補が1つに絞れない場合は仕訳候補を3つ以内で提示し、担当者の選択を待つ
- 処理した仕訳はすべて audit_log.py に記録する（記録なし実行は禁止）

## エラー時の対処
- freee API が500エラーの場合は3回リトライ後に処理を中断し、Slackに通知
- 認証エラー（401）の場合はトークンをリフレッシュして1回のみ再試行
- リフレッシュ失敗の場合は管理者にメールで通知して処理を停止

Layer3例外処理でClaudeが提案する科目選定のプロンプト設計

例外仕訳（科目が不明な取引）をClaudeに渡すプロンプトの設計例です。

SYSTEM_PROMPT = """
あなたは経理・会計の専門家です。
提示された取引情報をもとに、freee会計の勘定科目候補を最大3つ提示してください。

制約:
- 候補は確信度の高い順に提示する
- 勘定科目名はfreee会計の標準科目名を使用する
- 判断根拠を1文で説明する
- 確信度が低い（50%未満）場合は「要人間確認」と明示する
"""

USER_PROMPT = f"""
以下の取引の勘定科目候補を3つ提示してください。

取引日: {transaction_date}
摘要: {description}
金額: {amount}円
相手先: {counterparty}
過去の類似取引: {similar_transactions}
"""

このプロンプトにより、Claudeは科目候補を構造化して返答します。返答をJSONパースして layer4_approval に渡すことで、担当者が確認・承認するフローに組み込めます。

まとめ：経理を「データ利活用の拠点」へ

本ガイドで提唱した「4層分離」のアーキテクチャは、単なるコスト削減のためのものではありません。手作業をAIエージェントに委ねることで、経理部門は「過去の記録係」から、経営判断を支える「データ利活用の拠点」へと進化します。

まずは、現在のプロセスにおいてどこがボトルネック（例：入力の精度不足、例外処理の多発）になっているかを特定し、本稿で紹介したSaaSやAPI連携を最小単位からテスト導入することをお勧めします。