AIエージェントの正解は証拠にならない｜研究解説

AIエージェントの正解は証拠にならない｜研究解説 研究・論文

AIエージェントに社内業務を任せる話が、実証実験の段階から現実の運用へと移りつつあります。ただし、その評価軸が「正しい結果を出したか」だけになっていると、組織としては危ない——そう指摘する研究がarXivで公開されました。2026年8月13日付のプレプリント（査読前論文）「Correct Is Not Governed: Provenance Integrity in Agentic Workflows」（著者: Jesus Salas）です。

結論を先に言えば、同じ正解にたどり着いたとしても、その正解が「誰の権限に基づくのか」「本当に終わったと言える証拠があるのか」「後から前提が変わったときに気づけるのか」は、まったく別の問題だという主張です。監査やインシデント調査を担う情シスにとって、後回しにできない論点を含んでいます。

この記事でわかること

  • 「正解」と「統制された実行」が別物である理由（3つの失敗パターン）
  • 論文が提案する仕組み「Matrix」が何を記録・検証するのか
  • 実験で示された数値と、うまくいかなかった実験の中身
  • 情シスが自社のAIエージェント導入で最低限おさえるべき観点

この研究は何を言っているのか

一文で言えば、「エージェント型ワークフローの良し悪しを結果の正誤だけで測るのは、組織運用としては不十分である」という研究です。

論文は「統制された実行（governed execution）」を、「意思決定・完了・変更への対応が、検査可能な来歴（provenance）によって裏づけられている作業」と定義します。ここで言う来歴とは、「その判断は誰の承認に基づくのか」「どの版の事実を読んだのか」「終わったと言う根拠は何か」を後から追跡できる記録のことです。

なお本論文はarXivに投稿されたプレプリントであり、査読を経ていません。以下の内容や数値も、今後の査読・追試で変わりうるものとして読んでください。

そもそも「エージェント型ワークフロー」とは何か

エージェント型ワークフローとは、AIが指示を受けて自ら手順を組み立て、社内システムやSaaSを操作しながら一連の業務を完了させる仕組みのことです。チャットで質問に答えるだけの使い方とは異なり、チケットの起票・承認依頼・データ更新・完了報告まで、AIが「作業者」として動きます。

情シスの身近な例で言えば、入退社時のアカウント発行申請の処理、脆弱性情報を読んで自社影響を判定し対応チケットを起票する運用、社内規程を参照した問い合わせ回答の起案などが該当します。すでに一部を自動化している組織も多いはずです。

なぜ「正解」だけでは足りないのか？

結果が正しくても、その正しさを支える根拠が欠けていれば、組織は後から説明も是正もできないからです。論文は具体的に3つの失敗パターンを挙げています。

失敗パターン 何が起きるか 情シスにとっての実害
誤った権限に依拠する
(wrong authority)		 結論は妥当だが、根拠にした規程・承認が本来の決裁権限のものではない 監査で「誰が決めたのか」を説明できない。規程改定前の旧版を根拠にしていた、等
裏づけのない完了宣言
(unsupported completion claim)		 エージェントが「対応完了」と報告するが、完了を示す証拠がない 未対応のまま台帳上は「クローズ」。インシデント時に穴として露出する
後の変更で陳腐化した作業
(stale work)		 前提となる事実や権限が後から変わったのに、既に終えた作業がそのまま残る 古い前提の判定結果が生き続ける。どこまで見直せばよいか分からない

3つ目は特に厄介です。人間の運用でも「規程が変わったので、過去3か月の判定をやり直す」という作業は発生しますが、影響範囲を特定できないと全件やり直しになります。エージェントが大量に処理していれば、その全件が膨大になります。

提案された仕組み「Matrix」は何をするのか

論文が提示するのはMatrixという「決定論的な因果状態層」です。AIモデルの賢さを上げるものではなく、エージェントの作業の外側に置いて、根拠と依存関係を機械的に記録・検証する層だと理解すると分かりやすいでしょう。主な機能は次の4つです。

  1. 権限と事実のバージョン管理：どの版の権限（At）とどの版の事実（Ft）を読んだ／生成したかを、型付きの依存関係として記録する。承認された判断は「明示的な事実」となり、下流の作業に紐づく。
  2. 完了証拠の独立検証：タスクの完了証跡を、あらかじめ定義した完了条件（Definition of Done）に対して別の検証者が評価する。論文は「実行したエージェント自身の『終わりました』という申告は、入力された主張にすぎず、証拠としては不十分」という立場を明確にしています。
  3. 失敗の保存：検証に失敗した証跡も履歴に残し、再試行は新しい証跡を生む。上書きして消さない。
  4. 選択的な無効化：権限や事実の版が更新されたら、依存関係の経路をたどって影響を受ける判断・タスク・証跡だけを特定し、無効化して「やり直し義務」を発行する。

2番目は、実務の感覚としてかなり刺さるところです。人間の運用でも「作業者の自己申告だけで完了扱いにしない」のは内部統制の基本ですが、AIエージェントを入れる際にこの原則が抜け落ちがちだからです。

実験で何が分かったのか

論文は複数の比較実験を行っています。特徴的なのは、「結果の正しさ」ではほとんど差が出なかったという点です。

観点 Matrix（統制あり） 対照（統制なし・直接実行）
期待どおりの行動に到達したか 15/15 15/15（直接RAG）
裏づけのない引用がなかったか 15/15 9/15（直接RAG）
早すぎるクローズ（未完了なのに完了扱い） 0/3 3/3
権限変更後に再実行が必要になったタスク数 3 18
構造的に情報が足りないときのエスカレーション 12/12 0/12

読み取れるのは次の3点です。

  • 正解率は変わらない。到達した行動は両者とも15/15で同じでした。「統制を入れたら賢くなる」という話ではありません。
  • 根拠の質は明確に違う。裏づけのない引用は、統制なしでは15件中6件で発生しました。結果が合っていても、根拠が合っていないケースが4割あったことになります。
  • 変更時の被害範囲が違う。権限が改定された際、統制なしでは18タスクの再実行が必要になったのに対し、Matrixでは依存関係から3タスクに絞り込めました。

そして、統制なしの側は情報が構造的に足りないケースで一度もエスカレーションしませんでした（0/12）。足りないまま何かしらの答えを出してしまう、という挙動です。これは実務では最も怖いパターンでしょう。

うまくいかなかった実験も書かれている

この論文の誠実な点は、失敗した実験を隠していないところです。

著者は「役割を分離した転移テスト」を実施しました。つまり、完了条件を書いた人とは別の文脈で作られたデータに対して、同じ契約（完了条件）が通用するかを試したわけです。結果は明確な失敗でした。

  • 合成データ30件のうち、「不完全」と判定されるべき23件はすべて検知できた（感度1.00）
  • しかし、レビュアーが「完全」と判断した7件も、すべてブロックしてしまった（特異度0.00、正解率0.767）
  • 後続の改善を加えても、特異度は0.15までしか上がらなかった

つまり「とりあえず全部止める」に近い挙動になったということです。著者自身が「仕組みが正しく動くことと、書かれた契約が新しいデータに対して意味的に妥当であることは別だ」と結論づけています。

現場目線：これは「厳しくすれば安全」の話ではない

正直なところ、この失敗実験が本記事で一番役に立つ部分だと感じました。

AIエージェントの統制というと、「承認を挟む」「ログを取る」「条件を満たさなければ止める」という方向に話が進みがちです。しかし論文が示したのは、止める条件を厳密に書くほど、正常な業務まで止まるという当たり前の現実です。特異度0.00は、運用に置き換えれば「正しく処理された申請が7件連続で差し戻された」状態にほかなりません。現場からは即座に「AIを外してくれ」と言われるでしょう。

限られた人数で運用している情シスにとって、過剰ブロックは監視すべきアラートの山を生み、結局は誰も見なくなるという失敗の再来です。WAFやDLPのチューニングで何度も通ってきた道を、AIエージェントの統制でもう一度やることになる、と読めます。

もう一点。この研究の「完了条件を書いた人と、実際のデータを作る人が違うと機能しなくなる」という結果は、統制の設計を情シスだけで完結させてはいけないことを示唆しています。完了条件は業務所管部門と一緒に書かないと、現場のデータに当たった瞬間に破綻します。

情シスは今、何をすべきか

この論文はあくまで研究段階の提案であり、明日から導入できる製品ではありません。ただし、自社でAIエージェントの利用を検討・拡大するときの「問いのリスト」としては十分に使えます。稟議や社内規程の議論で、次の3点を確認するだけでも効果があります。

  • 権限の出所：エージェントが参照した規程・マスタデータの版を、後から特定できますか。
  • 完了の証拠：完了扱いの根拠は、エージェント自身の申告以外にありますか。
  • 変更への追随：規程やマスタが変わったとき、影響を受けた過去の処理を絞り込めますか。

そのうえで、自前で長大なチェックリストを作るより、まずは公的な指針にあたるのが近道です。

この研究の限界

著者自身が限界を明記しています。過大評価しないよう、あわせて押さえておくべき点です。

  • 査読前のプレプリントであり、結果は今後変わりうる。
  • 主要な実験は著者自身が作成した小規模な合成データと、モデルの繰り返し実行によるもの。企業での実際の発生率を示すものではない。
  • 契約への適合度は「設計上そうなる」部分を含むと著者も認めている。
  • 変更の検知は人手で与えられており、自動検出ではない。
  • 精度向上の一般的な保証はない。あくまで監査可能性を担保する層としての位置づけ。

著者は次の検証段階として、「契約を設計していない人たちが権限・事実・完了条件・実行証拠・レビュー判断を用意した、独立に作成された企業タスク」での評価を挙げています。裏を返せば、現時点では実務環境での有効性は未検証ということです。

まとめ

  1. AIエージェントを「正しい結果を出したか」だけで評価すると、誤った権限・裏づけのない完了宣言・前提変更後の陳腐化という3つの穴が残る。実験でも、正解率は同じなのに根拠の質だけが明確に劣った。
  2. 統制を入れる効果は「賢くなる」ことではなく、証跡が残り、根拠のない完了を拒否でき、変更時の影響範囲を絞り込めること。再実行タスクは18件から3件に減った。
  3. ただし厳密な条件を書くほど正常な業務まで止まる（特異度0.00）。統制条件は情シス単独ではなく業務所管部門と共同で設計し、過剰ブロックの調整を運用計画に織り込む必要がある。

関連記事

出典

タイトルとURLをコピーしました