🤖 machine learning

Statistically Indistinguishable, Operationally Distinct: A Formal Barrier for Tabular Foundation Models

本論文は、高度な推論能力を備えていても、データの背後にある運用規則へのアクセスがなければ、法的に適正なデータベースの状態と規則に違反した状態を区別できないことを示すことで、テーブル型基盤モデルにおける形式的な障壁を確立しており、これは、規則に基づいた監査のみが完全な精度を達成するという「運用的チューリングテスト」の通過失敗によって裏付けられている。

原著者： Tassilo Klein, Johannes Hoffart

公開日 2026-06-30

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Tassilo Klein, Johannes Hoffart

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

以下は、この論文の解説を、平易な言葉と日常的な例えを用いて説明したものです。

大きな理念：「魔法の台帳」問題

想像してみてください。あなたには銀行の台帳があります。それは、誰がいくら持っているか、どのような取引が行われたか、誰が何を所有しているかを示す巨大なスプレッドシートです。

ここで、超高性能なAI（「テーブル型基盤モデル」）に、そのスプレッドシートのコピーを渡したとします。そして、AIにこう問いかけます。「このページにある台帳は適法ですか？それとも、誰かが改ざんしたものですか？」

この論文は、AIは失敗すると主張しています。たとえそのAIが世界で最も賢かったとしても、もしそのページに書かれた「数字」だけを見ているのであれば、本物のページと、本物に見えるように巧妙に書き換えられた偽物のページを見分けることはできないのです。

論文ではこれを**「オペレーショナル・チューリング・テスト（運用のチューリング・テスト）」**と呼んでいます。AIは、銀行が台帳を記録するために使用している「ルール」を知らなければ、数学的に特定の種類の不正を見抜くことができないことを、この論文は証明しています。

例え話：「完璧に偽造されたレシート」

なぜAIが失敗するのかを理解するために、研究者がどのように「偽の」データを作成したかを見てみましょう。

コーヒーショップのレシートを想像してください。

本物のレシート： コーヒーを2杯、 $5ずつで購入。10%割引を適用。合計は$ 9.00。
偽のレシート（改ざん）： 誰かが計算を書き換えました。彼らは「コーヒーを2杯買った」としていますが、合計金額は$9.05になっています。これを隠すために、彼らはその日売れた「他のすべてのコーヒー」の価格を、ほんのわずかな端数分だけ下げました。

結果：

数字の見え方は同じ： その日の「平均価格」や「総売上」といった統計量を見ると、偽のレシートは本物のレシートと統計的に全く同一です。「1次統計（平均など）」も「2次統計（数値のペアなど）」も、完璧に一致しています。
ロジックが壊れている： しかし、この特定のレシートにおける計算は間違っています。コーヒー2杯で10%引きなら、 $5 +$ 5 - 10% は $9.00 になるはずであり、$ 9.05 にはなりません。

AIのジレンマ：
AIは、レシートに記載された最終的な数字だけを見ている探偵のようなものです。AIは平均価格や総売上を見ます。偽のレシートがこれらの統計量と完全に一致しているため、AIにはそれが偽造品であると判断する方法がありません。AIは推測することしかできず、その的中率はコイン投げと同じ50%程度に留まります。

「アクセスの梯子」：AIはどこまで高く登れるのか？

研究者たちは、AIが異なるレベルの「アクセス権」を持っている状態でテストを行いました。これは、梯子を登っていくようなものです。

レベル1：「盲目の」AI（値のみ）
- 見ているもの： 単なる数字のリスト（平均、カウント、標準偏差など）。
- 結果： 完全に失敗します。本物と偽物の区別がつきません。的中率は50/50です。
- 例え： パズルのピースが作る絵を見るのではなく、ピースの色だけを見てパズルを解こうとしている状態です。
レベル2：「リレーショナルな」AI（つながりを見る）
- 見ているもの： テーブル同士がどのように接続されているかを見ることができます（例：「この注文は顧客Xによるものである」）。顧客が存在するかどうか、注文数が妥当かどうかをチェックします。
- 結果： いくつかのエラー（例：存在しない顧客による注文など）を見つける能力は向上しますが、依然として計算ミス（「値の変換」ロジック）を見抜くことには失敗します。
- 例え： AIは顧客が実在することは確認できますが、割引が正しく適用されているかを計算して知ることは依然としてできません。
レベル3：「ルールを読む」AI（オラクル／神託）
- 見ているもの： 数字を見るだけでなく、ソースコードとルール（例：「合計＝価格 × 数量 × (1 －割引率）」）を見ることができます。自ら計算を実行して、数学的な整合性を再検証します。
- 結果： 100%の正確性を発揮します。計算をやり直してエラーを見つけられるため、即座に偽のレシートを特定できます。
- 例え： これはオリジナルのレシピ本を持っている探偵です。彼らはスープを味わい、「色合いは合っているが、砂糖ではなく塩を使っているから間違いだ」と言うことができます。

衝撃的な発見：たとえ「超天才」でも失敗する

研究者たちは、現在利用可能な最も高度なAIモデル（GPT-5.5やKimi-K2.6など）を取り上げ、彼らにすべてを与えました。

スプレッドシートのデータ
データベースの構造（スキーマ）
ルールを記述している実際のコード
トリガースクリプト

結果： これらすべての情報を与えても、AIモデルは依然として失敗しました。

彼らは、適法な状態と不法な状態を確実に判別できませんでした。
本来は適法な状態を「偽物」として誤って拒絶することがよくありました。
ルールが目の前にあるにもかかわらず、計算を確認するための正しいSQLクエリを書くことができませんでした。

なぜか？ 論文は、問題はAIの「知能」が足りないことや、データの量が足りないことではないと示唆しています。問題は**「識別可能性（Identifiability）」**にあります。もし、偽造者が巧妙に工作しており、データが統計的に本物と区別がつかない場合、AIが明示的に特定のルールチェックを実行するようにプログラムされていない限り、どれほど「推論」を重ねても解決できないのです。

結論：必要なのは「ルールブック」である

この論文は、AIが現実世界のビジネスデータ（銀行業務や販売データなど）で機能するためには、単にデータを「読む」だけでは不十分であると結論付けています。AIは**運用のルールに基づいている（grounded in the operational rules）**必要があります。

現在のAI： 数字を見て、推測する。（失敗する）
未来のAI： ルールを定義する実際のコードに接続され、自ら計算を実行できる必要がある。（成功する）

要するに： 何百万ものスプレッドシートを見せるだけでは、AIに優れた監査官を教えることはできません。計算を行うための「計算機」と「ルールブック」を与えなければなりません。それなしでは、AIはただ推測しているに過ぎないのです。

技術要約：統計的に区別不能、運用上は別物

問題提起
本論文は、表形式の基盤モデル（Tabular Foundation Models）における根本的な限界、すなわち、データの生成を司る運用ルールへのアクセスなしには、エンタープライズ・システムから生成されたデータを推論できないという問題を取り上げている。これらのモデルは、単一かつ自己完結的なテーブルに対しては優れた性能を発揮するが、実稼働中のテーブルは複雑なシステムの投影であり、アプリケーションコードが行を書き込み、宣言的な制約が値を制限し、手続き型のトリガーが遷移を強制するものである。その結果、モデルが利用可能な訓練データには、値の生成に関与した「運用ロジック（ルール、トリガー、コード）」が欠落していることが多い。著者らは、この「運用の接地性（Operational Grounding）」へのアクセスがない限り、モデルは、リーガル（正当）なデータベース状態とイレガル（不正）なデータベース状態が、値の分布のみに基づくと統計的に区別不能になるという形式的な障壁に直面すると断じている。

手法：オペレーショナル・チューリング・テスト (OTT)
この障壁を反証可能にするため、著者らは「リーガル」な状態と「ルール違反」の状態のデータベース状態を判別する二値分類タスクである「オペレーショナル・チューリング・テスト（OTT）」を構築した。

構成: テストには、3つのテーブル（顧客、注文、注文明細）からなるオーダー・トゥ・キャッシュ・スキーマを利用する。ここでは、1次および2次の列値周辺分布（Marginals）の全変動（Total Variation; TV）距離を $\tau < 0.02$ 以内に抑えつつ、特定のルールを違反させた「イレガル」な状態のペアを生成する。
汚染の種類: 以下の4つの運用ルール・ファミリーをテストする。
1. リレーショナル値の一貫性: 外部キー制約の破壊（例：IDを未確認の値に置き換える）。
2. カーディナリティの一致: 集計境界の違反（例：注文あたりのアイテム数）。個々の行の値は保持される。
3. 値の変換ロジック: 手続き型数式の違反（例： $total = \sum line\_items \times (1 + tax)$ ）。列全体で相殺されるオフセットを加えることで、ヒストグラムを変更せずに実行する。
4. 値の状態遷移: 状態遷移ルールの違反（例：pending $\to$ shipped）。ステータス値の周辺分布は保持される。
理論的境界: 著者らは、ル・カンの補題（Le Cam's lemma）を援用し、「値のみ」の分類器（列値の周辺分布に限定されたもの）に対するベイズ誤差の下限を確立する。リーガルな分布とイレガルな分布の間のTV距離が $\le \tau$ である場合、誤差は $\frac{1}{2} - \frac{\tau}{2}$ で抑えられる。 $\tau < 0.02$ の場合、最小誤差は $\ge 0.49$ となり、精度は約 0.50（偶然レベル）を超えることができない。

実験設定
本研究では、何の情報があればこの障壁を越えられるかを判断するために、モデルを「アクセス・ラダー（アクセスの梯子）」に沿って評価する。

値のみのベースライン: 列統計量（平均、標準偏差、四分位数など）の35次元の要約のみをモデルに提供する。アーキテクチャには XGBoost、TabICL、TabPFN を含む。
行レベルのアクセス: ルールに関するコンテキストを与えずに、生の行データのみをモデルに提供する。
リレーショナル・アクセス: 結合（Join）、外部キーのカバレッジ、グループカウントを含む特徴量を与える。
運用の接地性（Operational Grounding）: 7つの実行可能なルール由来の監査（例：整合性をチェックするために明細から合計を再計算する）のスカラ出力を付加したモデル。
フロンティアLLM: スキーマ、トリガーのソースコード、ルールテーブル、および状態ファイルをプロンプトに含めて提供された大規模言語モデル（GPT-5.5, Kimi-K2.6）。SQL実行能力の有無についてもテストを行う。

主な結果

値のみによる失敗: すべての値のみのベースライン（XGBoost, TabICL, TabPFN）は、偶然と同等の精度（ $\approx 0.50$ ）しか達成できなかった。事前登録された2つの片側検定（TOST）により、これらがリーガルな状態とイレガルな状態を区別できていないことが確認された（ $p < 0.002$ ）。これは、訓練データが増加した場合（最大5,000ペア）や、生の行レベルのアクセスがある場合でも同様であった。
リレーショナル情報の不十分性: リレーショナル・モデル（HistGB, RDB-PFN）は大幅に改善し、0.89 の精度に達した。これらは外部キーの破壊、カーディナリティの違反、および状態遷移のエラーを検出することに成功した。しかし、値の変換ロジックについては完全に失敗した（再現率 $\le 0.02$ ）。これは、結合情報だけでは、税金や割引の計算のような実行可能な数式を再構成できないためである。
運用の接地性の成功: 7つの実行可能なルール由来の監査を付加した分類器は、1.00 の精度を達成し、ギャップを完全に埋めた。これは、障壁がモデルの容量不足ではなく、実行可能なロジックへのアクセスの欠如によるものであることを裏付けている。
LLMの限界: ソース・アーティファクト（スキーマ、コード、ルール）をプロンプトに含めたフロンティアLLMも、テストに失敗した。GPT-5.5 は50個のリーガルな状態のうち0個を「LEGAL」と分類し、Kimi-K2.6 はわずか2個しか分類できなかった。高度な推論努力やSQL実行を用いても、LLMはソース・アーティファクトを決定論的なリーガリティ・チェックへと確実にコンパイルできず、述語を誤解したり、変換チェックを見落としたりすることが頻発した。

意義と主張
本論文は、表形式の基盤モデルが、運用のルールなしにシステム生成データについて推論できないことは、容量の問題ではなく、識別可能性（Identifiability）の問題であると主張している。

形式的障壁: 統計的な周辺分布が高度に一致している場合、支配的なルールへのアクセスを持たないモデルは、ランダムな選択よりも優れた性能を発揮できないことを著者らは確立している。
独立性: この障壁は、モデルのアーキテクチャ、規模、または特徴量の豊富さとは無関係である。スケーリング則（Scaling Laws）をもってしても、運用の接地性の欠如を克服することはできない。
進展への示唆: 著者らは、表形式の基盤モデルの進展には、宣言的および手続き的なルールを、単に検索されたテキストとしてではなく、モデルが評価すべき「実行可能なロジック」として第一級の入力として扱う必要があると主張している。現在のベンチマーク（TabArenaなど）はこの失敗モードを見逃しており、アクセスの梯子に対してテストを行う運用ベンチマークのみが、現在のモデルの真の限界を明らかにすることができる。

結論として、稼働中のシステムによって生成されるデータに対しては、運用の検証（どのルールを評価すべきかを知ること）が信頼の前提条件であり、現在の基盤モデルは、たとってフルコンテキストを与えられたとしても、明示的かつ実行可能なルール導出なしに、この検証を確実に実行するメカニズムを備えていない。