LLMはテーブルデータの推論ができるのか？4つのベンチマークが示す金融AIの現状
会計士はテーブルで思考します。Beancountの元帳は本質的にテーブルです。勘定科目は行、日付と金額は列、アサーションはセル間の制約です。LLMが自律的な金融エージェントを動かせるかどうかを検討し始めたとき、私は常に同じ先行する疑問に突き当たりました。「そもそもLLMはテーブルを確実に読み取れるのか？」という点です。この点に関する文献は、予想以上に厳しいものでした。
論文の紹介
Fangらは、TMLR 2024 (arXiv:2402.17944) において「Large Language Models(LLMs) on Tabular Data: Prediction, Generation, and Understanding — A Survey」を発表しました。これは、テーブルの特徴からの構造化された結果の予測、合成テーブルデー タの生成、質問に回答できるレベルのテーブル理解という3つのドメインをカバーする41ページのタクソノミーです。理解のトラック、すなわちテーブル質問回答（TableQA）、事実検証、構造的推論こそが、金融AIにとって最も関連性の高い分野です。
併読したSuiらによる「Table Meets LLM: Can Large Language Models Understand Structured Table Data?」(WSDM 2024, arXiv:2305.13062) は、より管理されたアプローチをとっています。彼らは、テーブル分割、サイズ検出、結合セル検出、セル検索、逆引き検索、列取得、行取得という7つの狭いタスクを持つStructural Understanding Capability (SUC) ベンチマークを定義し、GPT-3.5とGPT-4を直接テストしました。推論チェーンも、検索のトリックもありません。単に「モデルは要求されたことができるか？」を問うています。
主な知見
- フォーマットのギャップは現実的であり、驚くほど大きい。 SUCベンチマークでは、HTMLシリアル化が「自然言語＋セパレータ」形式を全体で約6.76%上回りました。HTML > XML > JSON > Markdown > NL+Sep というランキングは、タスク間で一貫しています。Beancountファイルはこのスペクトルの自然言語寄りに位置しており、これは警戒すべき兆候です。
- セル検索は驚くほど難しい。 GPT-3.5は直接的なセル検索（行X、列Yの値を見つける）で44%の正解率しか達成できません。GPT-4は同じタスクで73.34%に達します。表計算ソフトの数式がマイクロ秒で処理する決定論的な操作において、モデル間に26ポイントもの差があることは驚異的です。
- フューショット（Few-shot）の例は極めて重要。 SUCプロンプトから1ショットの例を削除すると、すべてのタスクで全体の正解率が30.38%低下しました。モデルの構造的理解はデモンストレーションによって大きく支えられており、真に内面化されているわけではありません。
- 実際のテーブルQAにおける人間とLLMの差は膨大。 TableBench (arXiv:2408.09174, AAAI 2025) は、事実確認、数値推論、データ分析、可視化にわたる886の質問を評価します。人間の正解率は85.91%ですが、GPT-4-Turboは40.38%、GPT-4oは42.73%です。現在の最高モデルでも、現実世界のテーブルの複雑さを反映するように設計されたベンチマークでは、人間の約半分のレベルのパフォーマンスしか発揮できていません。
- 金融スプレッドシートにおける複雑さの崩壊は深刻。 FinSheet-Bench (arXiv:2603.07316) は、構造的な複雑さが異なるプライベート・エクイティ・ファンドのテンプレートでLLMをテストしています。単純な検索では89.1%の正解率を達成しますが、複雑な集計では19.6%にまで低下します。最大のテストファイル（152社、8ファンド）では、全モデルの平均正解率が48.6%となり、最も単純なファイルの86.2%から大幅に低下しました。
- 長いテーブルはカテゴリ的にモデルを破壊する。 TMLRの調査によると、1000トークンを超えるとGPT-3のパフォーマンスはランダムに近いレベルまで低下します。20万トークンのコンテキストウィンドウを持つモデルであっても、長いシーケンスに対するセルフアテン ションの二次関数的なコストのため、大規模なデータセットには苦労します。
妥当な点とそうでない点
Suiらのベンチマークは慎重に設計されており、数値は信頼できるものです。構造的タスクにおいてHTMLがMarkdownを上回るという発見は直感に反しますが（Markdownの方がコンパクトであり、LLMは学習過程でより多くのMarkdownを見ているため）、HTMLの明示的なタグ付けが、構造を推論することなくナビゲートするためのアンカーをモデルに多く提供するという考え方とは一致します。
私が懐疑的なのは、自己拡張（self-augmentation）技術（回答前に重要な値を特定するようモデルに求める2段階プロンプト）が、TabFactやToTToのようなダウンストリームのベンチマークで0.84〜5.68%の改善をもたらすという点です。これらは実際の実験による実数ですが、わずかな改善に過ぎません。この技術は根本的な問題を解決するものではなく、本質的に脆弱な構造的理解の上に乗せられたプロンプトエンジニアリングによるパッチに過ぎません。
TMLRの調査は、あらゆる調査論文に共通する範囲の問題を抱えています。テーブル予測（XGBoostの領域）から生成的なテーブル合成、QAまで網羅しているため、分析が希薄になっています。私の目的にとって最も実用的なセクションは構造化QAトラックですが、そこでも調査はどの手法が実際に信頼できるかを統合するのではなく、主に手法をカ タログ化するにとどまっています。
複雑な集計の正解率が19.6%であるというFinSheet-Benchの発見は、ここで最も金融特有の警鐘を鳴らしています。ポートフォリオの集計、ファンドレベルのロールアップ、多期間の比較などは、まさに財務報告を些細なものではないものにしている操作であり、LLMが崩壊する場所そのものです。
金融AIにとっての重要性
Beancount元帳はテーブルです。自律型エージェントが元帳を読み取って異常を検知したり、レポートを作成したり、書き戻しの判断を下したりする場合、それはテーブル推論を行っていることになります。証拠によれば、現在のLLMは単純な検索はそれなりにこなしますが（GPT-4でセル取得73%）、最も重要な操作、つまり多段階の集計、大規模な元帳のサイズ推定、構造的なバリエーションにわたる推論では崩壊してしまいます。
シリアル化の発見には、即座に実用的な意味があります。BeancountファイルをLLMにパイプする場合、選択するフォーマットは、エージェントのロジックを1行も書く前から、正解率に数パーセントの影響を与えます。Beancountのネイティブ構文は、フォーマット階層の「NL+Sep」端に近く、人間には読みやすいものの、LLMには最適ではありません。モデルに提供する前に、より構造化された中間形式（JSONやHTMLの取引テーブルなど）に変換することは、前処理のコストに見合う価値があるかもしれません。
規模に応じた複雑さの崩壊は、最も冷静になるべき発見です。小規模ビジネスの実際のBeancount元帳には、数千の取引、数十の勘定科目、そして数年の履歴があるかもしれません。FinSheet-Benchの結果は、テーブルが実際に重要になるサイズまで成長すると、LLMの精度は自律的な書き戻しを行うには安全ではない領域まで低下することを示唆しています。
次に読むべき資料
- TableLLM (arXiv:2311.09206) — 169個のKaggleテーブル（UniPredict）でトレーニングされたファインチューニングモデル。テーブル予測においてGPT-4のゼロショットを大幅に上回ると報告されており、金融特有のテーブルタスクにはドメイン特有のファインチューニングが依然として正しいアプローチであることを示唆しています。
- TAT-QA (arXiv:2105.07624) — ハイブリッドな財務ドキュメント（収益報告書のようなテーブル＋テキスト）に対する離散推論のためのデータセット。付随するTAT-LLMモデルは、金融テーブル推論に特化型モデルを適用する最も直接的な先行事例です。
- ToRR: A Benchmark for Table Reasoning and Robustness (arXiv:2502.19412) — 行の入れ替えや列の並べ替えなどの敵対的な摂動に焦点を当てています。Beancountエージェントが並べ替えに対して堅牢であれば、それは位置ではなく構造を理解しているシグナルになります。
