AuditCopilot：複式簿記における不正検知のためのLLM

今週読んでいる論文は、2025年12月にKadir、Macharla Vasu、Nair、およびSonntagによって提出された『AuditCopilot: Leveraging LLMs for Fraud Detection in Double-Entry Bookkeeping』（arXiv:2512.02726）です。これはLLMエージェントの研究と財務コンプライアンスの交差点に位置するもので、基盤モデルを使用して実際の企業の元帳における不正な仕訳を検知する試みです。これまでのBean Labsのリーディングリストにあるすべての論文の中で、これが私たちが関心を持っている生のデータ形式に最も直接的に関連しています。

論文について

PCAOB（公開会社会計監督委員会）の監査基準AS 2401で義務付けられているすべての公開会社監査には、仕訳テスト（JET）を含める必要があります。これは、ルールベースのヒューリスティックに基づいてフラグが立てられたエントリがないか、元帳を体系的にチェックするものです。ルールには、「深夜に投稿されたエントリ」、「キリの良い金額」、「異常な勘定科目の組み合わせ」、「滅多に活動しないユーザーによる投稿」といったものがあります。これらのルールは機能しますが、膨大な量の誤検知（偽陽性）を生成します。監査人は、時間の大部分を明らかなノイズの却下に費やしているのが現状です。

AuditCopilotは、LLMがこれらのルールを置き換え、あるいは補完できるかどうかを問い直しています。このシステムは、転記日、借方・貸方金額、勘定科目ID、税率、および事前に計算されたバイナリ異常フラグのセットを含むJSON形式のテキストスニペットとして構造化された各仕訳を、LLMプロンプトに渡します。LLMはバイナリの異常ラベルと自然言語による説明を返します。著者らは、合成された企業元帳と、単一の匿名化された実世界の税務元帳の両方で、Mistral-8B、Gemma-2B、Gemma-7B、およびLlama-3.1-8Bのベンチマークを行い、従来のJETやIsolation Forestのベースラインと比較しました。

主なアイデア

• 合成データセット（5,000件の転記ID、真の異常率約1%）において、完全なプロンプトを使用したMistral-8Bは、適合率0.90、再現率0.98、F1スコア0.94を達成しました。これに対し、JETベースラインは適合率0.53、再現率0.90、F1スコア0.50であり、特筆すべきは誤検知がJETの942件に対し、わずか12件であったことです。
• 「完全な」AuditCopilotプロンプトには、生の仕訳の特徴だけでなく、データセット全体の統計（平均、中央値、95パーセンタイルおよび99パーセンタイルの金額）と、行ごとの事前計算されたIsolation Forestスコアが含まれています。このコンテキストエンジニアリングが極めて重要な役割を果たしています。
• 実世界のデータセットでは、完全なプロンプトを使用したGemma-7Bが適合率0.89、再現率0.78、F1スコア0.83に達しました。Isolation Forestのヒントを削除すると適合率は0.14まで崩壊しました。つまり、LLM単体で成果を出しているわけではないということです。
• 説明機能は、このシステムの最も強力な貢献です。数値的な異常スコアとは異なり、フラグが立てられた各エントリには、「この金額はこの勘定科目クラスターの99パーセンタイルを超えており、営業時間外に投稿されています」といった散文による正当な理由が付随します。これにより、監査人は迅速に判断を下すことができます。
• ファインチューニングは一切行われていません。すべてがゼロショット、または短いシステムロール・プロンプトで実行されています。これは導入コストの面では有利ですが、結果がプロンプトのテンプレートに強く依存することも意味します。

評価できる点とできない点

誤検知の削減結果は顕著であり、本物です。同じデータで誤検知を942件から12件に減らすというのは、そのツールが実際に現場で使われるかどうかを左右する類の実用的な利得です。私はこの方向性を支持します。

しかし、評価設計については重大な懸念があります。

第一に、合成データセットの正解ラベル（グラウンドトゥルース）自体がJETルールから構築されています。注入された異常は、まさにJETが捉えるように設計されたパターンそのものです。したがって、JETでラベル付けされたテストセットで「LLMがJETを上回る」という結果は、LLMがプロンプト内の統計コンテキストから同じルールを模倣することを学んだだけであり、それを超えた汎化ではない可能性があります。

第二に、実データにおけるIsolation Forestのアブレーション（要素削除）の結果は、論文内での議論が不十分なほど致命的です。IFスコアがないとF1スコアは0.83から0.24に急落します。これは、LLMが主にIFシグナルの上位にある柔軟な閾値として機能しているのであって、独立した異常検知器として機能しているのではないことを示しています。このシステムは、「監査推論を行う基盤モデル」というよりは、自然言語の皮を被った機械学習アンサンブルに近いものです。

第三に、実世界のデータセットが、単一の業界パートナーからの1つしかありません。著者らもこれを認めていますが、企業の規模、会計システム、または業界を越えた汎用性を評価することはできません。

第四に、比較対象がJETと単一のMLベースライン（Isolation Forest）のみです。オートエンコーダーベースの異常検知、特徴量エンジニアリングを施したXGBoost、IFスコアに対する単純なロジスティック回帰などが欠けています。ここで「古典的ML」として扱われている範囲が狭すぎます。

ハルシネーション（幻覚）の問題も扱われていません。著者らは説明機能を主要な貢献としていますが、その説明が事実として正しいか、あるいはバイナリ予測と整合しているかについての評価はありません。

なぜこれが金融AIにとって重要なのか

この論文は、Bean Labsが構築しているものに最も近い既存の研究です。Beancountの元帳は複式簿記システムです。すべてのトランザクションは一連の投稿行（posting lines）です。それらの行に対する異常検知（異常な勘定科目、範囲外の金額、不自然な日付パターン）は、自律型財務アシスタントにとって明らかな最初の機能です。

AuditCopilotの結果は、Beancount監査に対する正しいアプローチが「生のトランザクションをLLMに渡して不審かどうか尋ねる」ことではなく、「軽量な統計的コンテキスト（勘定科目レベルのベースライン、時間分布、Isolation Forestスコア）を計算し、その強化されたコンテキストをLLMに与える」ことであることを示唆しています。LLMの価値は、生の異常スコアリングではなく、統合と説明にあります。

誤検知の削減も直接的に関連しています。1回の実行で942件の異常候補を提示するBeancount監査ツールは無視されます。しかし、説明付きで12件の高確度な候補を提示するツールは活用されるでしょう。これはパフォーマンス指標ではなく、プロダクト指標です。

私が最も関心を寄せている「書き戻しの安全性」に関する懸念は、この論文では扱われていません。AuditCopilotは読み取りとフラグ立てのみを行い、修正の提案や元帳の変更は行いません。これは最初の論文としては適切なスコアですが、Bean Labsにとっての難題は残っています。つまり、異常を検知した後に、会計上の不変条件に違反せずにどう安全に対処するかという問題です。

次に読むべきもの

• Understanding Structured Financial Data with LLMs: A Case Study on Fraud Detection (arXiv:2512.13040, ACL 2026) — FinFRE-RAGを導入し、同じ不正検知問題に検索拡張生成（RAG）によるインコンテキスト例を追加し、4つの公開不正データセットでベンチマークを行っています。AuditCopilotの単一データセットという限界に直接対応しています。
• Anomaly Detection in Double-entry Bookkeeping Data by Federated Learning System with Non-model Sharing Approach (arXiv:2501.12723) — 企業間での元帳データの共有を妨げるプライバシーの制約に対処しています。中央集権化せずにクライアントデータで学習させたいプロダクション環境のBeancount監査サービスには、連合学習のアプローチが必要になるでしょう。
• GuardAgent: Safeguard LLM Agents by a Guard Agent via Knowledge-Enabled Reasoning (arXiv:2406.09187) — AuditCopilotが意図的に避けている安全性の強制問題です。異常が検知された後、書き戻しエージェントが会計上の整合性を損なう変更を行わないようにするにはどうすればよいかを論じています。