パイプラインは『動いている』のに、証拠は壊れている──多段LLMパイプラインの『Evidence-State Reliability』

決定→監査→エスカレーションのように複数の段階を経るLLMパイプラインは、各段階の出力が「構文的に正しい形式」で通っていれば、一見問題なく動作しているように見える。だが、その形式の裏で運ばれている「証拠」自体が劣化していたら——この見えない乖離を測る枠組みを提案した論文が、2026年8月21日にarXivで公開された。

3行まとめ

• 単著論文が提案する「Evidence-State Reliability（ESR）」は、パイプラインの出力が構文的に正しいこと（パーサー妥当性）と、運ばれる証拠が実務上健全なこととを別々に測る評価レイヤー。GLM-5.2による720件の実験で、構造は改善する一方、証拠に敏感な段階の成功率は9条件すべてでマイナスだった
• GitHubリポジトリのREADMEを読むと、60件のベースケースは米国消費者金融保護局（CFPB）の公開苦情データを無害化して作った実験用素材で、「代表的な統計サンプルや企業不正の確定事実として扱ってはいない」と著者自身が明記している
• 同じREADMEには「Full submission-readiness audit: Not yet completed（提出可否の完全監査は未完了）」「Journal-specific formatting and submission package: Not yet completed（学術誌向けの体裁・提出パッケージは未完了）」とあり、この論文は査読誌への投稿が完了した論文ではなく、著者自身が「advanced research draft（上級段階の研究ドラフト）」と位置づけている

「構文は正しい」と「証拠は健全」は別問題

論文はまず新しい評価レイヤーを定義する。

"This paper introduces and operationalizes Evidence-State Reliability (ESR), an evaluation layer concerned with whether intermediate evidence remains sufficiently complete, grounded, internally consistent, and usable for a stage's assigned function. ESR is evaluated separately from parser validity, which measures structural conformance."

この論文は「Evidence-State Reliability(ESR、証拠状態の信頼性)」という評価レイヤーを導入し、運用可能にする。中間的な証拠が、各段階に割り当てられた機能にとって十分に完全・根拠づけられている・内部で一貫している・使用可能であるかどうかを扱うレイヤーだ。ESRは、構造的な適合性(パイプラインの出力形式が仕様通りかどうか)を測る「パーサー妥当性」とは別に評価される。

GLM-5.2を使った統制実験

論文はこの枠組みを、GLM-5.2を使い、60の無害化されたベースケースを、4つの証拠条件(クリーン・圧縮による損失・部分的な欠落・矛盾を含むノイズ)のもとで検証している。各条件は、決定・監査・エスカレーションという3つの段階を経て処理され、計画上720件、記録・整理された720件の呼び出しのうち713件が最終的に無害化された実行データとして保持された。ベースとなったCFPB（米国消費者金融保護局）の苦情データベースは、2026年7月7日にダウンロードしたものだと論文本文（4.3節）に明記されている。

論文全文（4.4節）には、4つの証拠条件それぞれの定義がある。

（出典：論文全文 4.4節「Evidence conditions」）

この開発プログラムには、720件の主実験に加えて、750行のシミュレーション研究、60チェーンのGLM-5.2パイロット、より小規模なClaude Opus 4.8との比較サブセット、72チェーンの決定論的な別ドメイン研究が含まれていたと論文は述べている（4.2節）。ただし論文はこれらの派生研究を主実験のデータと合算しておらず、独立した再現実験としても、サンプルサイズの水増しとしても扱っていないと明記している。GitHubリポジトリのreportsディレクトリを確認すると、実際に"pilot_03_glm_vs_claude_comparison"のようなディレクトリ名が存在し、この比較研究が実在したことが裏付けられる。以下では、論文の主軸である720件のGLM-5.2実験の結果を見ていく。

GitHubリポジトリのREADMEには、この統制実験（Pilot 05）の設計が要旨より詳しく書かれている。

（出典：NaimurRahmanR/evidence-state-reliability README）

数字:構造は改善するのに、証拠に敏感な成功率は悪化する

"Across nine matched degraded-minus-clean condition-stage comparisons, all operational stage-success estimates were negative, and all 95% bootstrap intervals remained below zero."

9つの「劣化条件からクリーン条件を差し引いた」条件×段階の比較すべてで、運用上の段階成功率の推定値はすべてマイナスであり、95%ブートストラップ区間もすべてゼロを下回った。つまり、証拠が劣化した条件では、パイプラインの各段階の実務的な成功率が一貫して悪化している。

一方で、パーサー妥当性(構造的な正しさ)の点推定値は9つすべてでプラスだった(ただし部分的欠落条件の3つの区間はゼロを含んでいた)。これは、構造上は「正常に動いている」ように見えながら、実務上の成功率は悪化するという乖離を示している。さらに細かく見ると、次のことが分かった。

"Among parser-valid degraded audit outputs, degradation detection was 1.0 in each degraded condition, while false-assurance rates remained non-zero; among parser-valid degraded escalation outputs, recovery was 0.0 in every degraded condition."

構造的に妥当な劣化条件下の監査出力では、劣化の検出率はどの劣化条件でも1.0(常に検出できている)だった一方、誤った安心感(false-assurance、実際には問題があるのに「問題なし」と判定してしまう率)はゼロではなかった。さらに、構造的に妥当な劣化条件下のエスカレーション出力では、回復率はどの劣化条件でも0.0——つまり、いったん劣化を検出しても、そこから立て直す(エスカレーションが機能する)ことはできていなかった。論文はこれを「検出はできるが回復はできない」という切り分けとして整理している。

論文本文（5.4節・5.5節）の具体的な件数は次の通り。

（出典：論文全文 5.4節「Audit detection and false assurance」、5.5節「Escalation recovery」）

論文は5.6節で、さらに一段上の「一連の処理全体が最終的にうまくいったか」という視点でも集計している。60ベースケース×4条件＝240グループのうち、234グループで決定・監査・エスカレーションの3段階すべてのデータが揃い、そのうち223グループ（92.9%）が論文の定義する「カスケード失敗」に該当した。注意すべきは、劣化を加えていないクリーン条件だけを見ても、60グループ中43グループ（71.7%）がカスケード失敗に分類されている点だ。論文はこの内訳を次のように示している。

（出典：論文全文 Table 6「Sequence-level reliability-cascade composition」）

つまりクリーン条件での失敗の主因は「証拠の劣化」ではなく「パーサー（構造）の失敗」であり、劣化条件下での失敗は「検出したのに回復できない」パターンが主因という、失敗の質そのものが条件によって異なることが、この内訳から読み取れる。論文自身も「この集計値は、クリーンと劣化の両条件を含んでおり、劣化条件による処置効果や、実運用での失敗発生率の推定値として解釈すべきではない」と注記している。

多段パイプラインの「動いている」を疑う

複数のLLM呼び出しを段階的につなぐパイプライン(要約→検証→承認など)を運用している場合、この論文は「各段階の出力が形式的には正しく通っている」ことを、パイプライン全体の信頼性の証拠として扱う危うさを指摘している。特に、上流の情報が圧縮・部分的欠落・矛盾を含んだ状態で下流に渡っても、パーサーレベルのチェックだけでは検知できない可能性がある。証拠の完全性・根拠づけ・一貫性・使用可能性を個別に評価する仕組みを、構造チェックとは別に組み込む価値がある。ハルシネーションの原因と対策全般はLLMのハルシネーション(幻覚)とはを、エージェントへの情報の持たせ方はコンテキストエンジニアリングとはを参照してほしい。

この研究はまだ査読誌に載った論文ではない

GitHubリポジトリのREADMEを確認したことで、60のベースケースの出所（CFPB公開苦情データ）は判明したが、「GLM-5.2」というモデル名の詳細な仕様（バージョン・提供元・パラメータ規模）や、4つの証拠条件それぞれの具体的な生成手順（圧縮・部分的欠落・矛盾をどうプログラム的に作り出したか）までは、README・arXiv本文いずれからも本記事の範囲では確認できなかった（本文PDF32ページの図表本体までは読み込んでいない）。より重要なのは、リポジトリ自身が明記している通り、この研究はまだ「査読誌に投稿できる状態の完全な監査」を経ていない段階のドラフトだという点だ。単著論文であり、著者名はNaimur Rahman氏1名。結論の一般化可能性についても、論文自身が「評価対象のモデル構成・パイプライン設計・選定された無害化事例・採点手順・単一のスケールされた実行に限定される」と明記しており、本記事もその範囲を超えて一般化していない。Zenn記事検索(2026年8月27日実施)では該当する日本語記事は見つからなかった。