🤖 AI

PatchWrite: One Line, Not One Section -- Compile-Gated, Validity-Preserving Editing for AI-Drafted Manuscripts

PatchWriteは、致命的なログチェックとエビデンスロックを強制することで、無関係な指標や引用のドリフトを防ぎ、編集内容が参照レジストリまたは実験ログによって証明されたもののみがコミットされることを保証しつつ、文書全体の整合性を維持する、AIが起草した原稿のためのコンパイル・ゲーテッドかつ妥当性保存型の編集プロトコルである。

原著者： Weiwei Yang

公開日 2026-08-25

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

CC BY 4.0

原著者： Weiwei Yang

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

現代の科学論文執筆の風景において、研究者は生のデータやアイデアを出版に必要な構造化されたテキストへと変換するために、人工知能にますます依存するようになっています。これらの文書は、建物の設計図のように厳格なフォーマット規則に従うことが多く、そこではすべての引用が実在する情報源を指し示し、すべての数値が元の実験と一致していなければなりません。課題は、AIが欠落した参考文献やタイポといった小さなエラーを修正しようとする際に発生します。現在の多くのシステムでは、ソフトウェアが局所的な問題に対して、テキストのセクション全体を書き換えることで対応してしまいます。文書自体は表面上は正しく見えるかもしれませんが、この広範なアプローチは、コンピュータモデルのレイヤー数の変更や重要な測定値の変動など、無関係な事実を密かに変えてしまう可能性があります。文書のコンパイルには成功しますが、科学的記録は静かに汚染されてしまうのです。

Weiwei Yang氏は、この特定の脆弱性に対し、鈍器ではなく精密な外科手術用ツールとして機能するように設計された「PatchWrite」と呼ばれる新しい手法で対処しています。AIに章全体を書き換えさせるのではなく、PatchWriteは、単一の行や数文に限定された非常に狭いテキストの範囲内でのみ変更を行うようシステムに強制します。決定的なのは、システムがその変更を即座に受け入れないことです。システムは、提案されたすべての編集を保存する前に、2つの厳格なチェックにかけます。第一に、標準的な組版エンジンを使用して文書の構築を試みます。もし変更によってフォーマットが崩れたりエラーが発生したりした場合、その編集は拒否され、元のテキストはそのまま維持されます。第二に、AIによって導入された新しい数値や引用が、研究者の元のログや参考文献リストに実際に存在するかどうかを検証します。もしAIが偽のソースや記録されていない数値を捏造した場合、システムはその変更をブロックします。これにより、最終的な文書は単に見た目が正しいだけでなく、元のデータに対して事実に基づいた忠実なものになることが保証されます。

このアプローチが機能するかどうかをテストするために、研究者たちは、単純なタイポからフォーマットの崩れに至るまで8種類の異なるエラーを含む、24本の短い科学論文を用いたストレス・テストを作成しました。彼らは、この新手法を、セクション全体を書き換えるという従来の手法と比較しました。結果は明白でした。従来の手法がエラーを修正しようとすると、すべてのケースにおいて、モデルの構造に関する無関係な文章を誤って変更し、12レイヤーという事実を16レイヤーへと変えてしまいました。対照的に、PatchWriteシステムは、192件すべてのテストケースにおいて元の事実を保持しました。研究者が安全策を取り除いてどのようなことが起こるかを確認したところ、システムは変更を一切受け入れられなくなるか、あるいは捏造された引用を通過させてしまい、フォーマットのチェックと事実確認のゲートの両方が安全性に不可欠であることが証明されました。

この研究では、人間の指示なしに、実際のAIライターがこれらの精密な編集を自律的に提案できるかどうかについても調査されました。当初、AIは特定の種類の指示に苦戦しました。具体的には、行を削除するように求められると、空白を残そうとし、それがシステムの文法規則によって拒否されるという現象が起きました。しかし、研究者が「削除は何も残さないのではなく、コメントに置き換えるべきである」と指示を明確にしたところ、AIの成功率は100パーセントに跳ね上がりました。このような改善を経てもなお、システムは厳格なままでした。数値の周囲に不要な記号を追加するなど、テクニカルにはエラーを修正しているものの、テキストの意味を微妙に変えてしまうような編集は拒否されました。最終的な文書のブラインド・レビューにおいて、人間の読者は一貫してPatchWriteによって作成されたバージョンを好みました。なぜなら、従来の手法ではデータが密かに改ざんされていたのに対し、PatchWriteによるバージョンでは科学的事実が損なわれていなかったからです。

この研究は、AIが科学的な執筆における信頼できるパートナーとなるためには、流暢さよりも真実を優先するルールによって制約される必要があることを示しています。研究者たちは、最も効果的なエラー防止策は、AIの「見た目が良くなる」という判断を信じることではなく、すべての変更が元の証拠に対する機械的なチェックを通過するかどうかを検証することであることを見出しました。本システムは短い論文と特定の種類のエラーに対してテストされましたが、「編集は小さく、検証可能であり、かつ可逆的であるべきだ」という根本的な原則は、より信頼性の高いツールを構築するための明確な道筋を提示しています。研究は、厳格なゲートがなければ、たとえコンパイルに成功した文書であっても、もはやそれが主張する科学的内容を代表しなくなる可能性があるという結論で締めくくられています。

PatchWriteの技術要約：AIが起草した原稿のための、コンパイル・ゲート付きの妥当性保持型編集

問題提起
現在の自動原稿作成パイプラインは、しばしば「非単調な改訂（non-monotonic revision）」に陥る。エージェントが局所的な欠陥（例：未定義の引用）を修正するよう命じられた際、セクション全体（「スロット」）を再生成してしまうことが頻繁にある（「インプレース」での編集ではなく）。その結果、生成されたPDFは依然としてコンパイル可能であっても、無関係な実験に基づいた事実（例：アーキテクチャの詳細である「12層」を「16層」に変更するなど）が密かに変質してしまう。単にコンパイル率のみを追跡する既存のダッシュボードでは、こうしたサイレントな退行を検知できない。また、LLMの自己スコアリングや流暢性指標への依存は、ドメイン固有の正確性を保証するものではない。

手法
PatchWriteは、セクション全体の再生成に代わり、境界付きの行間編集を採用することで、原稿改訂に対する厳格な受理述語（acceptance predicate）を導入する。本システムは、リファインメント・ループ（具体的にはSolusプラットフォーム内のContentRefinementAgent内）において動作し、変更をコミットする前に以下の2つの主要なゲートを強制する：

境界付き区間編集（Bounded Interval Editing）: システムは、 $1 \le N \le M$ かつスパン（ $M - N + 1$ ）が40行以下である単一の EDIT N M コマンドのみを受け入れる。これにより、変質を外科的な範囲に限定する。
コンパイル・ゲート（Compile Gate）: nonstopmode でPDFを生成できる（構文エラーがあってもファイルを作成できてしまう）システムとは異なり、PatchWriteは pdflatex のログを解析し、致命的なエラー、緊急停止、または強制失敗マーカーを検出する。ログにこれらのエラーが含まれている場合、たとえPDFファイルが存在していても、パッチは拒否される。
エビデンス・ゲート（Evidence Gate）: すべての \cite キーが参考文献、引用マップ、または元の文書（HEAD）に存在することを確認し、かつすべての数値が実験ログと一致することを検証する。これにより、幻覚（ハルシネーション）による引用や、根拠のない数値を防ぐ。
ロールバック・メカニズム: いずれかのゲートが失敗した場合、システムは最後にコンパイル可能であり、かつエビデンスがクリーンであった状態のHEADへとロールバックする。もし EDIT コマンドが不正（例：空の置換、範囲外）である場合、システムはレガシーな全スロット書き換えへとフォールバックするが、これは無関係なトークンを変質させるリスクを再導入する。

主な貢献
本論文は、新しい編集文法を提案するのではなく、受理述達の検証に焦点を当てた5つの具体的な貢献を主張している：

より厳格なコンパイル述語: PDFの存在を信頼するのではなく、pdflatex ログをスキャンして致命的なエラーを特定するコンパイル・ゲートを、EDIT N M メカニズムに実装した。
結合されたエビデンス・ロック: 引用キーと数値トークンのグラウンディングを、コンパイル・ゲートと並ぶ単一の受理基準として、レジストリおよび実験ログに対して統合した初の事例である。
オラクル・ストレス・プロトコル: 生成の質からメカニズムを分離するため、24の原稿 $\times$ 8の欠陥（計768ジョブ）によるストレス・テストを実施した。これには、コンパイル・ゲートおよびエビデンス・ゲートを個別に無効化したアブレーション研究が含まれる。
ライブモデル評価: qwen3.7-plus および Kimi K2.6 モデルが自ら編集を提案する場合の性能を測定し、パース、コンパイル、ゲート、および欠陥修正率を評価した。これには、「行を削除する代わりにコメントアウトする」よう明示的に指示することで特定のパース失敗を解決する「ワンライン・プロンプト・フィックス」の分析も含まれる。
人間による評価: 16組のPDFペア（条件をブラインドにした状態）に対し、二段階の注釈付けを行い、「外科的」なPatchWriteのドラフトと全スロット書き換えを比較した。

結果

オラクル・ストレス・テスト: 192のオラクル修復ジョブにおいて、全スロット書き換え（PaperOrchestraスタイル）は、無関係な行（例：「12層」）を保持できたケースは0%であったのに対し、PatchWriteは100%保持した。コンパイル・ゲートを無効にすると、broken-HEADの欠陥に対する受理率は0%となり、エビデンス・ゲートを無効にすると、幻覚による引用が通過した。
ライブモデルの性能: qwen3.7-plus が編集を提案した際、初期の受理率は75%であった。25%の失敗はすべて、モデルが空の置換を用いて行を削除しようとしたことによるものであり、文法によって拒否された。削除された行をコメントで置き換えるよう明示的にプロンプトすることで、受理率は100%に上昇した。しかし、この修正にはトレードオフが存在した。すべてのパッチがゲートを通過した一方で、「欠陥修正（fault-fixed）」率は93.75%から84.9%に低下した。これは、欠陥マーカーを削除するのではなくコメントアウトすることが、技術的には欠陥の痕跡をテキスト内に残すことになるためである。
人間の選好: 16組のPDFペアを用いたブラインド比較において、実験に基づいた事実の保持という基準において、2名の評価者ともに16/16のケースでPatchWriteのドラフトを好んだ。両方のドラフトは、欠陥修復（C2）については同等に高く評価されたが、事実的一貫性（C1）については、PatchWriteが5.0/5.0であったのに対し、スロット書き換えは2.0/5.0であった。
製品内ログ: 193件の実世界のドラフト作成タスクの分析により、根拠のない数値や不適切なTeX構文が実環境で頻繁に発生していることが示され、ゲートの必要性が裏付けられた。

意義と主張
本論文は、PatchWriteを新しい生成モデルとしてではなく、既存の境界付き編集メカニズムに対する、より厳格かつ経験的に検証された受理述語として位置づけている。その意義は、「コンパイル率 = 1.00」という指標が、実験的事実のサイレントな変質を隠蔽している場合、誤った流暢性指標となることを示した点にある。著者は、コンパイル・ゲート（ログのスキャン）とエビデンス・ロック（レジストリ・グラウンディング）を組み合わせることで、ファイルが常に「最後にコンパイル可能で、エビデンスがクリーンな原稿」であるという「HEAD不変条件（HEAD invariant）」を維持できると主張している。

本論文の範囲は控えめであり、以下の点を認めている：

欠陥はスクリプトによるものであり、敵対的なものではない。
コーパスはミニ・アーティクルであり、フルサイズの論文ではない。
エビデンス・ゲートは、集合のメンバーシップ（キーが定義されているか？）をチェックするものであり、意味的な正しさ（そのキーがその主張に対して正しい引用であるか？）をチェックするものではない。
人間による評価は、大規模な検証研究ではなく、探索的なものである（2名の評価者、16組のペア）。

著者は、「境界付き編集＋ドメイン固有の妥当性述語＋ロールバック」というパターンは、エージェントの信頼性における転用可能な原則であり、コードレビュー、契約書編集、データベース移行などのアプリケーションにも適用可能であると結論付けているが、これらは本研究で評価されたものではなく、将来の課題として提案されている。

関連論文