ハクソク

世界を動かす技術を、日本語で。

LLMに委任すると文書が破損する

2026年5月9日原文(arxiv.org)

概要

  • Large Language Models（LLMs） による知識労働の変革可能性
  • 委任作業 における信頼性の重要性
  • DELEGATE-52 ベンチマークによるLLMの性能評価
  • 長期作業での 文書劣化 の深刻さ
  • 現行LLMの 信頼性課題 の明確化

LLMによる委任作業と信頼性の課題

  • LLMs は知識労働を変革する可能性を持つAI技術
  • 委任作業（delegated work） は、LLMに業務を任せる新たなインタラクションパラダイム
  • 委任には、 LLMがタスクを正確に実行し、文書に誤りを持ち込まない という信頼が不可欠
  • DELEGATE-52 は52の専門分野（プログラミング、結晶学、音楽記譜など）にわたる長期文書編集タスクをシミュレートするベンチマーク
  • 19種類のLLMを用いた大規模実験を実施

DELEGATE-52ベンチマークの主な発見

  • 最先端モデル（ Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4）でも、長期作業の末に 平均25%の文書内容が破損
  • 他のモデルではさらに深刻な劣化が観察
  • エージェント的ツール利用 （agentic tool use）はDELEGATE-52の性能向上に寄与せず
  • 文書サイズ、 インタラクションの長さ、 気を散らすファイルの存在 が劣化の深刻化要因
  • LLMは まばらだが重大な誤り を静かに文書へ導入し、やがて累積的な破損につながる

現行LLMの限界と今後の課題

  • 現在のLLMは 信頼できる代理人 としては不十分
  • 長期的な作業や複雑な文書編集では 重大なエラー が発生しやすい
  • 人間とAIの協働 における品質保証や監督の重要性
  • 今後は エラー検出・修正能力 や 信頼性向上 への技術開発が求められる

Hackerたちの意見

ここの評価方法がすごく良かった。可逆的なステップのチェーンを通じてテストすることで、忠実度を測るって感じ。最先端のモデルでも、コンピュータに優しいタスクでエラーが蓄積されるのが印象的だった。Pythonでの結果がPython特有の評価の影響だけじゃなくて、他の一般的なプログラミング言語にも適用できるのか、またトレーニングプロセスの何か特別な要因が関係しているのか、知りたいな。

うん、前から言ってるけど、AIでテキストを加工すると、どんどん劣化していくよね。毎回やるごとにどんどんひどくなる。「意味の切除」っていうのが俺のお気に入りの表現なんだ： https://www.theregister.com/software/2026/02/16/semantic-abl...

└

「毎回やるごとに」って、同じセッション内のことを言ってるの？それとも毎回新しいセッション（コンテキストウィンドウ）でのこと？

└

俺はそれを「ミーンウィットの逆戻り」って呼んでる。

最近読んだLLMに関する中で、一番衝撃が少なかったことだね。要するに、JPEGのあのミームみたいなもので、JPEGとして保存するたびに少しずつ品質が劣化して、最後には全然わからなくなるって感じ。ただLLMの場合、出発点は意図なんだ。LLMが一回通るたびに意図が劣化していく。例えば、正確な科学論文の場合、ちょっとしたニュアンスや精度が言い換えのたびに失われていく。LLMはミーンリバージョンの機械で、トレーニングから「外れた」コンテキストや作業負荷に対しては、どんどん均質な抽象的な平衡に引き寄せられる傾向があるんだ。

└

同僚がLLMを「クソ」レイヤーって言ってた。完全に否定してるわけじゃないけど、LLMに何かを通すたびに出てくるものが期待したり欲しいものとは限らないって強調してた。まるでパブで数杯飲んだ後に、どこかで見たことを話してる人みたいな感じ。正確なこともあるけど、そうじゃないリスクもかなりある。だから、例えば、LLMを使ってAPIからデータを集めてレポートを作るのはやめた方がいい。決定論的なデータを「クソ」レイヤーに通すことになるから、出てくるものを信頼できなくなる。むしろ、LLMを使って決定論的なデータから決定論的な出力を生成するコードを書く手助けをさせる方がいいよ。共働者がLLMを使ってAPIからの決定論的なデータを要約してるのを見たけど、正確なこともあれば、全然外れてることもあった。見てるものによっては、致命的なリスクがあるかもしれないね。

└

LLMがやったのと同じタスクを人間がやると、文書がさらに劣化するってことだよ。LLMが25%劣化するなら、人間は同じ手法を使ったら80%ぐらい劣化すると思う。単一のパスの話ね。実際のところ、人間は論文のように編集しないし、Claudeみたいなコーディングエージェントも同じ。考えてみて：論文全体を取り込んで、一回のターゲット編集でその論文を吐き出すなんてことはしないよね…コーディングエージェントも同じ。あと、よく考えてみて。25%の劣化率は業界では受け入れられない。ソフトウェア開発を支配しているAIの変化は、もし25%の劣化があったら実際には存在しないよ…それは多すぎる。

└

この結果が本当に面白くて関連性があるのは、コーディングエージェントが大きなソースファイルを複数の小さなファイルに分割する時だね。Opus + Claude Codeは、人間がやるようなコピー＆ペースト操作ではなく、長いソースコードのセクションを記憶から各新しいファイルに再現しようとする。ファイルを移動するのはちょっと簡単だね。LLMは時々ファイルを記憶から再現しようとするけど、「git mv」を使ってコンパイラエラーを直すように指示すれば、ほとんどの場合うまくいくよ。普通の編集は、合理的なモデルやツールのセットアップで一般的にうまくいく。Qwen3.6 27Bでも大丈夫だし、インプレース編集の場合は「git diff」を見てサプライズを確認できるよ。

└

これを示す子供のゲームもあるよね： https://en.wikipedia.org/wiki/Telephone_game

└

LLMは人類が作った最も精巧な推測マシンだよ。それが使う目的によって、役に立つこともあれば無駄になることもある。それだけのこと。すべてをこのレンズで見ると、すべてが理解できる - 特に推論や創造性の根底にある理解がないってことがね。ブースターが何を言おうと、気にしないよ。

└

昨日、スレッドでこのことについて話してたんだ。だから、LLM生成だけのブログは好きじゃない。どんなに良いと思っても、あなたが自分のコピーのようなものを良いと考えても、私は気にしない。もし退屈なLLMの返答が欲しいなら、自分でプロンプトを出すよ。人間が生成したコンテンツだと思って読んでるブログを読んで、誰かにプロンプトの結果を読ませようとされるのは、うんざりだ。あなたのブログを読みに来たのに、あなたが書くつもりもないなら、なんでブログを書いてるの？

└

LLMを使ってコーディングしていると、これを実感することがある。結構注意して速く進めているつもりでも、後で小さなコードの一部をじっくり見て「うわ、やばい」と思うことがある。そしたら、数時間かけて全体を見直して、思った通りにいかなかった部分や、曖昧だったところ、LLMの「脳の虫」が出てきたところを丁寧に修正しなきゃいけない。品質は自分にとってすごく大事なんだけど、正確に言うとこの「繰り返し圧縮」の問題が心配なんだ。コードベースがきれいで、最新のメンタルモデルがあれば、LLMはすぐに機能を作る手助けをしてくれるけど、LLMがコードベースを汚していくと、過去のミスや誤解が重なって、どんどん失敗する可能性が高くなる。だから、またLLMを使う前に、正しい状態に「復元」しなきゃ安心できないんだよね。

Hacker Newsで議論の続きを見る