FinSheet-Bench: From Simple Lookups to Complex Reasoning, Where LLMs Break on Financial Spreadsheets

この論文は、実業界の機密データに代わる合成データを用いたベンチマーク「FinSheet-Bench」を提案し、主要な大規模言語モデル（LLM）が複雑な財務スプレッドシートからの情報抽出や数値推論において依然として高い誤り率を示しており、専門的な金融用途での自律的な利用には文書理解と確定的な計算を分離するアーキテクチャの導入が必要であると結論付けています。

要約

この論文は、**「AI（大規模言語モデル）が、複雑な財務の Excel スプレッドシートをどれだけ正しく読めるか」**をテストした報告書です。

タイトルは『FinSheet-Bench』。まるで「AI による財務スプレッドシートテスト」のようなものです。

以下に、専門用語を排し、わかりやすい比喩を使って解説します。

---

🏠 1. 背景：AI は「文章」は得意だが、「表」は苦手？

最近の AI（GPT-5 や Gemini など）は、本やメールを読むのが非常に上手になりました。しかし、「投資判断」をするために必要な、複雑な Excel ファイルになると話は別です。

• 現実の課題: 投資家（LP）は、私募ファンド（PE）のポートフォリオを評価するために、何百もの Excel ファイルをチェックする必要があります。
• 問題: これらのファイルは、会社によって形がバラバラです。結合セルがあったり、見出しが何行にもまたがっていたり、色や太字で意味を伝えています。
• AI の現状: 現在の AI は、これらの「ごちゃごちゃした表」から数字を正確に読み取り、計算する能力がまだ十分ではありません。

🧪 2. 実験：「FinSheet-Bench」というテスト

なぜ AI の能力が測れていないのか？それは、**「本物の投資データは機密情報だから、公開できないから」**です。

そこで著者たちは、**「本物の財務データと同じ構造（レイアウト）を持った、人工的に作られた（合成）データ」**を作成しました。これを「FinSheet-Bench」と呼びます。

• 比喩: 本物の銀行の金庫（機密データ）は開けられませんが、その金庫の**「中身と全く同じ形をした、おもちゃの金庫」**を 24 個作って、AI に解かせました。
• 内容: 24 種類のファイル（シンプルなものから、152 社ものデータが入った巨大なものまで）を用意し、10 種類の最新 AI モデルに質問させました。

📊 3. 結果：AI は「単純な検索」は得意だが、「計算」は苦手

実験の結果、面白い傾向が浮かび上がりました。

✅ 得意なこと：「どこに何があるか探す」

• 例: 「ファンドは何個ある？」「A 社の投資金額はいくら？」
• 結果: 最も得意な AI でも、約 90% 正解しました。これは「辞書を引く」ような作業なので、AI は得意です。

❌ 苦手なこと：「計算して答えを出す」

• 例: 「各ファンドの平均投資額を計算して」「最も高い EBITDA の会社を順位付けして」
• 結果: 難易度が上がると、正解率は急落します。最も複雑な計算問題では、正解率が 20〜30% 台まで落ち込みました。

📉 最大の発見：「ファイルが大きいと AI は混乱する」

• 小さなファイルでは 86% 正解しても、152 社ものデータが入った巨大なファイルになると、どの AI も48% 程度まで精度が落ちました。
• 比喩: 小さな部屋なら AI は綺麗に片付けられますが、倉庫いっぱいに荷物が積み上がると、AI は「どこに何があるか」見失ってしまいます。

🏆 4. どの AI が一番？

10 種類のモデルを比較した結果、Google の「Gemini 3.1 Pro」が最も優秀でした（正解率 82.4%）。
しかし、「82% 正解」でも、プロの金融の世界では「不合格」です。

• 金融の基準: 100 個の質問で 3 個くらい間違えれば、数百万ドルの損失につながる可能性があります。業界では97% 以上の精度が求められます。
• 現状: 最高の AI でも「6 問に 1 問」間違えるレベルです。これでは、AI だけで任せる（無人運転）ことはできません。

💡 5. なぜ AI は失敗するのか？（3 つの理由）

1. 文字列にすると「形」が消える:
   Excel をテキスト（文字の羅列）に変換して AI に見せています。しかし、**「太字」「色」「枠線」**といった、人間には「ここが重要だ」とわかる手がかりが、AI には見えなくなります。

   • 比喩: 料理のレシピを「材料と手順のリスト」だけで渡されたらわかりますが、「写真付きのレシピ本」なら、火加減や盛り付けのニュアンスが伝わるのと同じです。AI は今のところ「リスト」しか見ていません。

2. 位置関係の理解が弱い:
   Excel では「この数字は、上の行の『売上』という列にある」という**「位置関係」**で意味が決まります。しかし、AI は文章を左から右へ読むだけなので、この「2 次元の広がり」を理解するのが苦手です。

3. 計算が苦手:
   AI は「推測」で数字を出そうとします。しかし、財務計算は「厳密な計算」が必要です。AI は「たぶん 100 くらいかな？」と推測して、実際に 98 だった場合、それが「間違い」となります。

🔮 6. 未来への提言：「AI 単体」ではなく「チームワーク」を

この論文の結論は、**「もっと賢い AI を待つだけではダメ」**というものです。

• 解決策: 「AI に計算させる」のではなく、**「AI にデータを読み取らせ、計算は人間（またはプログラム）に任せる」**という仕組みが必要です。
• 新しいアプローチ:
  1. AI: 「このセルは『売上』、このセルは『コスト』だね」と、データの意味を解釈する（ここは得意）。
  2. プログラム: 解釈されたデータを Excel の計算式のように、厳密に足し算・引き算する（ここは人間がやる）。
  3. 人間: 最終チェックをする。

📝 まとめ

この論文は、**「AI は財務スプレッドシートの『翻訳者』にはなれるが、まだ『会計士』にはなれない」**と伝えています。

• 現状: AI は進歩が速く、2 年前に比べれば劇的に良くなりました。
• 課題: しかし、複雑な計算や巨大なデータ処理では、まだ人間がチェックしないと危険です。
• 未来: 「AI がすべてやる」のではなく、「AI が下準備をし、人間が最終判断をする」という**「人間と AI のチームワーク」**が、金融業界の正解のようです。

つまり、**「AI に任せて安心する」のではなく、「AI を賢く使いこなす」**ための新しいルール作りが始まった、というのがこの論文のメッセージです。

技術概要

FinSheet-Bench: 金融スプレッドシートにおける LLM の限界と複雑な推論の課題

技術的サマリー（日本語）

本論文は、代替投資（プライベート・エクイティ等）のデューデリジェンスにおいて、大規模言語モデル（LLM）が構造化された財務スプレッドシートからのデータ抽出と推論を行う際の能力と限界を評価した研究「FinSheet-Bench」を報告するものです。

1. 背景と課題 (Problem)

金融サービス業界、特に代替投資のデューデリジェンスでは、LLM が契約書の分析や要約などのテキスト中心のタスクで人間を上回る性能を示しつつあります。しかし、構造化された財務データ（Excel スプレッドシート）からの正確な抽出と数値推論において、LLM の能力には依然として大きなギャップが存在します。

主な課題は以下の通りです：

• データの複雑さ: 実際の財務モデルは、複数のシート、マージセル、階層的なヘッダー、埋め込み数式、視覚的なフォーマット（太字、色分けなど）が混在しており、標準化された CSV データとは異なり非常に複雑です。
• エラー許容度の低さ: 金融分野では、評価指標の 5% の誤差が数百万ドルの投資判断ミスにつながるため、自動化には極めて高い精度（97% 以上）が求められます。
• ベンチマークの欠如: プライベート・エクイティのポートフォリオデータは機密性が高いため、実世界のデータを用いた公開ベンチマークが存在せず、研究の進展が阻害されていました。

2. 手法とデータセット (Methodology)

2.1 FinSheet-Bench データセットの構築

実世界の機密データを直接使用できないため、著者らは**「実在の構造テンプレートに基づく合成データ」**を構築しました。

• 構造テンプレート: 8 社の一般パートナー（GP）から提供された実際のポートフォリオ監視スプレッドシートの構造（シート構成、列名、ヘッダー配置、ファンドの区切りなど）を模倣しました。
• セル値の生成: 元の値を特定できないよう、以下の処理を施して完全に再生成しました。
  • 企業名、日付、数値（エントリー/エグジット値）を擬似データに置換。
  • 数値にはスケーリング係数と摂動（ノイズ）を加え、元の値との関係を不明瞭化。
  • 会計上の恒等式（資産＝負債＋資本など）は、合成データでは厳密に一致しない場合があることを許容（現実のデータにも不整合があるため）。
• バリエーション: 8 種類の基本ファイル（Version A）に対し、行の削除、列の結合・分割、区切り文字の変更などの構造的変更を加えた Version B と C を作成し、合計 24 ファイルのベンチマークセットを構築しました。

2.2 評価プロトコル

• 対象モデル: OpenAI, Google, Anthropic の 3 社から提供される 10 種類のモデル構成（GPT-5.2, Gemini 3.1 Pro, Claude Opus 4.6 など）を評価。
• 入力形式: Excel ファイルをテキスト（CSV 形式）にシリアライズして LLM に提示。これは現在の業界標準の実装方法（RAG パイプライン等）を反映しています。
  • 注: マージセルのフラット化、視覚的フォーマット（太字、色）の欠落など、情報損失が発生します。
• 質問カテゴリ: 単純な検索から複雑な集計まで、7 つのカテゴリと 4 つの複雑度レベル（Low, Medium, High, Very High）で 16 種類の質問テンプレートを設計。
• 評価基準: 正解率（Accuracy）を主指標とし、自動検証（厳密一致、曖昧一致）と LLM による裁定（LLM Adjudication）の 3 段階システムで評価しました。

3. 主要な結果 (Key Results)

3.1 全体性能

• 最高精度: 最も高性能なモデル（Google の Gemini 3.1 Pro）でも、全 24 ファイルでの平均正解率は82.4%（約 6 問に 1 問の誤り）にとどまりました。
• 無監督利用の不可能性: どのモデルも、金融プロフェッショナルが求める「無人運用（Unsupervised use）」に必要な 97% 以上の精度を達成できませんでした。
• 複雑度による性能低下:
  • 単純な検索タスク（Low）: 約 89-94% の精度。
  • 複雑な集計・推論タスク（Very High）: 約 20-33% に急落。
  • 最大のファイル（152 社、8 ファンド）では、全モデルの平均精度が**48.6%**まで低下しました。

3.2 推論機能の影響

• 「推論（Reasoning）」や「思考（Thinking）」機能を有効にしたモデル（GPT-5.2, Claude Opus 4.6）は、無効な場合と比較して大幅な精度向上（+13〜23 ポイント）を示しましたが、それでも複雑なタスクでは限界がありました。
• 推論機能の有効化は、トークン消費量と応答時間の増加を伴います。

3.3 失敗要因の分析

• 構造的な限界: LLM は 2 次元の表構造を 1 次元のトークン列として処理するため、列ヘッダーと値の関係、行の境界認識が困難です。
• 数値計算の欠如: LLM は確定的な計算エンジンではなく、複雑な数値集計や中央値の計算などで誤りを犯しやすいことが判明しました。
• シリアライゼーションの影響: テキスト化による視覚的手がかり（太字、罫線）の欠如が、行の誤認識や列の選択ミスの一因となっています。

4. 主要な貢献 (Key Contributions)

1. FinSheet-Bench の公開: 機密性が高い金融データの問題を解決し、実世界の複雑な構造を反映した合成データセットとベンチマークを初めて提供しました。
2. LLM の限界の定量化: 最先端の LLM でも、金融スプレッドシートからの複雑な数値推論タスクにおいて、無人運用には程遠い精度であることを実証しました。
3. アーキテクチャへの示唆: 「ドキュメント理解」と「確定的な計算」を分離するアプローチの必要性を提唱しました。

5. 意義と今後の展望 (Significance & Future Work)

• 業界へのインパクト: 代替投資業界において、LLM をデューデリジェンスに導入する際の現実的な期待値とリスクを明確にしました。現在の技術では、LLM は「機械的な作業の軽減」には寄与しますが、最終的な検証は人間が行う必要があります。
• 解決策の提案:
  • ブルートフォース抽出の限界: 1 値ずつ問い合わせる手法は精度は上がるが、コストとレイテンシが現実的ではありません。
  • 段階的パイプラインの提案:
    1. LLM でスキーマ（列名、ファンド境界）を特定。
    2. LLM で行単位（企業単位）のデータ抽出を行う。
    3. 抽出された表に対して、プログラム（Python など）で確定的な計算（集計、ソート、比率計算）を行う。
       この「LLM による抽出＋プログラムによる計算」という分離アーキテクチャが、高精度な自動化への鍵であると結論付けています。

結論:
LLM の能力は急速に進化していますが、金融スプレッドシートのような複雑な構造化データにおける数値推論タスクにおいては、単体のモデルに依存するのではなく、文書理解と数値計算を分離したアーキテクチャを採用することが、実用化への必須条件であることが示されました。