TL;DR
本論文は、API/ランタイム移行後のLLMコード修復が「実行は通るが結果が違う」まま出荷される問題を、73タスク・60の文書化変更で事前登録実験した。典型入力だけの全アサーションゲートは誤修復の0.410をリリースし、リリースノートから作る端入力1個で0.065まで下がった（未見クラスタ0.471→0.061）。盲検LLMライターの3入力も近い性能（0.070、記述的）だが、宣言ラベルを使うガードは0.157で事前登録テスト不通過。実務では典型テストや自己テストだけで合格させず、変更ノート由来の端入力をリリースゲートに足すのが第一手。
既存手法との違い
既存研究には、依存更新後のクライアント修復（Fruntke & Krinke、Byam、DepRepair）、旧版と新版の実行差分を修復根拠にするBBCFixer/Gilesi、LLM生成テストを選別に使うCodeTや自己デバッグがある。本論文はBBCFixer等と相補的で、BBCBenchはオフライン・インストール不可の制約で評価せず、代わりに修復器の情報を固定してリリースゲートだけを変え、有限の全修復空間とモデル生成修復の両方で偽受入・偽拒否を測る。Byamのコンパイルエラー+API差分は本論文のruntime/schemaゲートと差分ビューの類似物として扱い、Java固有パイプラインは移植しない。比較条件は、同じ修復候補・同じ実行コストで可視入力の構成だけを変える点にある。RAGに関する比較・評価は提示本文からは確認できない。
使える条件
原論文の評価対象は、CPython 3.9→3.12、Node.js 20→24、SQLiteシェル3.51→3.54の文書化された変更を含む73タスク（66の影響タスク、60の変更クラスタ、18は新規）である。修復は文書化断片の選択に限定された有限メニューで、隠し契約はモデルに見せず、実ランタイム上でオフライン実行する。4モデルファミリに等しい情報を与え、期待出力は旧プログラム・旧ランタイムから取得する。自由形式のモデル生成コードは実行しておらず、サンドボックス未構築のため未実施。RAG固有の前提や外部依存プロジェクトへの適用は提示本文からは確認できない。
限界と未検証の範囲
修復は著者が用意した文書化断片の選択に限定され、自由形式のコード修復は未検証である。第2段階でメニューを1491断片に広げたが、25タスクは15未満の選択肢にとどまる。第3段階の233個の硬いディストラクタ下でも、硬い誤プログラムの0.168/0.153が通過した。盲検ライターの結果は1ライター・記述的で、ガードはラベル誤りにより事前登録テスト不通過。自己テストの改善はHolm補正後は有意でない。契約監査はAI監査であり人間のサインオフではなく、クラスラベルの異議は未解決。モデル生成コードは一切実行していない。
解説
ねえ智也くん、この論文さ「API移行後のLLM修復」って、実行は通るのに結果が違うまま出荷されるって話？ なんか怖いんだけど。
そう。古い関数が消えてエラーになるのはまだ気づける。問題は呼び出しは成功するのに値だけ変わる沈黙系。列挙が3になったり、floatの合計が変わったり、Buffer.poolSizeが増えたり。
え、それテスト通っちゃうやつじゃん。
通る。典型入力だけの全アサーションゲートだと、誤修復の0.410をリリースしてた。合格しても誤り、ってやつ。
どうやって調べたの？
73タスク、60の文書化変更。CPython 3.9→3.12、Node.js 20→24、SQLite shell 3.51→3.54。事前登録で、隠し契約はモデルに見せず、実ランタイムで実行。修復候補は文書化断片の有限メニューから選ぶ設計。
ゲートの入力だけ変えるの？
そう。典型入力T、リリースノートから作る端入力E、盲検LLMライターの3入力W、宣言ラベルだけ使うガードG、修復モデル自身の自己テストS。期待出力は旧プログラムと旧ランタイムから取る。
端入力1個でどれくらい下がるの？
典型だけが0.410で、リリースノート由来の端入力1個を足すと0.065。未見の15クラスタでも0.471→0.061。偽拒否は0.010のまま。
じゃあリリースノート最強じゃん。
盲検ライターの3入力も0.070まで来た。でもこれは記述的で、1ライターだけ。宣言ラベルを使うガードは0.157で事前登録テストは通らなかった。モデルは変更を露呈する入力を非拘束と誤ラベルしがち、って話。
自己テストは？
どのファミリでも下がる方向だけど、Holm補正後は有意じゃない。あと硬いディストラクタを233個足した段階でも、端入力0.058、GPT-5.6-lunaライター0.058は事前登録テスト通過。でも硬い誤プログラムの0.168と0.153はまだ通った。
まだ穴あるんだ。
ある。でもオープンウェイト3ファミリ・3メニューで、端入力は試行あたりの誤リリースを全部下げた。例は0.233→0.057。正しい完了は下げてない。
既存研究との違いは？
BBCFixerやGilesiは旧版と新版の実行差分を修復根拠にする。ByamはコンパイルエラーとAPI差分。本論文は修復器の情報を固定して、リリースゲートだけを変え、全修復空間とモデル生成修復の両方で偽受入・偽拒否を測る。BBCBenchはオフライン・インストール不可の制約で評価してない。RAG比較は提示本文から確認できない。
制限もちゃんとある？
修復は著者が用意した断片の選択に限定。自由形式コードは未検証で、サンドボックス未構築だからモデル生成コードは一切実行してない。第2段階でも25タスクは15未満の選択肢。契約監査はAI監査で人間のサインオフじゃないし、クラスラベルの異議は未解決。
実務の第一手は、変更ノート由来の端入力をリリースゲートに足す、だね。
そう。典型テストや自己テストだけで合格させない。入力の構成がゲートの妥当性を決める。
じゃあ明日から「リリースノートの端っこつつき係」名乗るね。
その係名でチケット切るなよ。