ビジネス文書をAIに丸投げすれば、静かに壊れていく。

Microsoftが2026年4月に発表した研究「LLMs Corrupt Your Documents When You Delegate」は、LLMへの文書委任がどれほど信頼できないかを19モデルの大規模実験で示した論文です。この記事では、その仕組みと主な発見、そして実践への示唆を解説します。

この記事でわかること：

  • DELEGATE-52ベンチマークの設計と仕組み
  • フロンティアモデルを含む19のLLMで何が起きたか
  • 劣化を加速させる3つの要因
  • AIへの委任リスクを減らすための考え方

DELEGATE-52とは

https://arxiv.org/abs/2604.15597

DELEGATE-52は、LLMが長期的な文書編集をどれだけ正確にこなせるかを測るベンチマークです。Microsoftの研究者Philippe Laban氏らが設計し、論文とともにGitHub・Hugging Faceでデータセットを公開しています。

「委任（Delegation）」とは、LLMが人間の代わりに文書を編集・管理するワークフローを指します。バイブコーディング（vibe coding）のような指示出しっぱなしのスタイルがその典型で、ユーザーはAIを信頼して細かい確認を省略します。この信頼が成り立つかどうかを、52の専門ドメインにわたって系統的に検証したのがDELEGATE-52です。

検証方法：「やって・元に戻す」を繰り返す

実験の核心は「リバーシブル編集」という手法です。LLMにまず文書を特定の方法で変換させ（前向き編集）、次にそれを元に戻すよう指示します（後ろ向き編集）。完全に正確なモデルなら、この操作を繰り返しても文書は元のまま保たれるはずです。

実験では1ラウンドトリップ（前後1セット）を最大10回繰り返し、20回のやり取りを通じて文書がどう変化するかを追跡しました。ドメインは会計台帳、Pythonコード、楽譜、結晶学ファイルなど52種類に及びます。スコアはテキストの単純な一致ではなく、ドメイン固有の意味的類似度で計測しているため、実際の内容の変質を精度よく捉えられます。

フロンティアモデルでも25%が失われる

19のモデル（OpenAI、Anthropic、Google、Mistral、xAI、Moonshotの各社）を検証した結果、20回のやり取りが終わった時点での全モデル平均スコアは約50%まで低下しました。文書内容の半分が失われるか書き換えられた計算です。

Gemini 3.1 Pro、Claude 4.6 Opus、GPT-5.4といったフロンティアモデルに絞っても、再構成スコアは71.5〜80.9%にとどまり、文書内容の平均25%が失われています。最新・最高性能のモデルでもこの結果です。

elvis（@omarsar0）氏が公開した解説でも、この発見は「bookmark it」と推奨されるほど重要視されています（参考）。

劣化は「まれだが致命的」な形で進む

劣化は均一に起きるわけではありません。全体の劣化量の80%以上は、一握りの「重大ラウンド」に集中しています。文書の大部分は維持されているのに、一部が大きく壊れるという形で進行するため、ユーザーが気づきにくいのが特徴です。

弱いモデルは主に「削除」を引き起こします。一方、強力なモデルは削除より「既存内容の変質」——ハルシネーション、誤分類、構造の崩壊——に傾く傾向があります。どちらの失敗パターンも、長期的な委任には危険です。

ドメインによって大きな差がある

Pythonコードの操作では、大半のモデルが「委任準備完了」の水準（RS@20 ≥ 98%）を達成しています。構造が明確で検証しやすいドメインは比較的安全です。化学式やチェスの棋譜など、高度に構造化されたドメインも同様の傾向があります。

一方、全モデル×ドメインの組み合わせのうち80%では、20%超の壊滅的な劣化が確認されています。自然言語の文書、楽譜、財務レポートなど、構造が曖昧で語彙の多様性が高いドメインほどスコアが落ちます。

エージェントツールも助けにならない

ファイルの読み書きやPython実行などのツールを使えるエージェント構成にした場合、スコアは改善しませんでした。むしろ悪化するケースが多く見られました。ツール使用がトークン処理のオーバーヘッドを生み出し、複雑な編集に失敗しやすくなったと研究者は分析しています。

エージェント化すれば委任の信頼性が上がるという期待は、少なくとも現状では裏付けられていません。

劣化を加速させる3つの要因

研究では、劣化を大きくする要因として3点が確認されています。

ドキュメントの長さは、1,000トークン増えるごとに劣化を加速させます。同じ指示でも、文書が長いほどエラーが積み重なります。

やり取りの回数が増えるにつれて劣化は止まらず悪化し続けます。初期のデモで良く見えても、長期運用で信頼できないモデルは多数存在します。

作業フォルダ内の無関係なファイルも影響します。関係のないファイルが多いほど、モデルは誤った操作を行いやすくなります。

実践への示唆

この研究が示す結論は「現状のLLMは汎用の文書委任に対して信頼できない」というものです。ただし、全否定ではありません。

コードや化学式のような、構造が厳格で自動検証しやすいドメインでは、LLMへの委任は現実的な選択肢です。対して、自然言語の文書や複雑な業務フォーマットでは、作業後の確認ステップを省略できないと考えるべきです。

短い一回のデモでLLMの信頼性を判断することにも注意が必要です。長い作業を通じてどれだけ劣化するかを、実際の文書とドメインで検証することが重要です。DELEGATE-52のデータセットはHugging Faceで公開されており（microsoft/delegate52）、自社のLLM活用ワークフローを評価するための基盤として利用できます。