依存関係の更新で修正エージェントを呼ぶべき時を判定する
When Should Dependency Updates Invoke Repair Agents? A Lightweight Routing Study
この論文をやさしく読む
ひとことで言うと
依存関係の更新が本当に互換性修正を要しそうな場合だけ、診断エージェントへ回すための軽量な判定法。
何に役立つ？
考えられる用途は、更新プルリクエストの処理でLLM呼び出しとトークン消費を抑えること。60件の診断試行では両方が約3分の2減った。
この研究の面白いところ
作成時点で使える情報だけの性能と、後で蓄積した履歴を使った性能を分け、後者の改善が情報漏れによるものと示した。
どこまで分かった？
497件中72件が修正を要したデータでの判定と、60件での診断試行である。修正パッチの生成や成功率は測っていない。
v1のアブストラクトに基づくAI解説。日本語訳とは別に、用途の解釈を含みます。
アブストラクトの日本語訳
依存関係の更新を行うプルリクエストは頻繁で、大半は定型的だが、一部には容易でない互換性修正が必要になる。近年のリポジトリ単位のコーディングエージェントなら修正できる可能性が高まっている一方、すべての更新で呼び出すと、モデルの呼び出し、CI時間、リポジトリの文脈、レビューの注意を浪費する。著者らはこれを、後続の診断や修正を試みる前に、どの依存関係更新プルリクエストをエスカレーションするか決める問題として扱う。そして、作成時点で利用できる文章とメタデータから、過去の互換性修正の必要性に基づいて更新の順位を付ける軽量な振り分け器DepFixRouterを導入する。ラベル付きのGitHub依存関係更新候補497件のうち、実質的な修正が必要だったのは72件だけだった。プルリクエストの題名とボット・依存関係フラグだけを使う、作成時点で利用可能なLinearSVCは、修正判定のF1値0.488を達成し、上位20％のプルリクエストを振り分けると必要な修正の51.4％を捕捉した。捕捉した修正1件当たりの呼び出し数は、全件振り分けまたは無作為振り分けの6.90から2.68に減った。事後的な履歴全体の情報を使うと上位20％での再現率は65.3％に上がるが、これは運用時の振り分け性能ではなく、プルリクエスト履歴に事後情報が大きく漏れ込むことを示す。60件の診断エージェント試行では、振り分け器を通した診断により、実際のLLM呼び出し数が66.7％、トークン数が66.1％減った。この試行で測ったのはパッチ生成ではなく診断である。DepFixRouterは、定型的な依存関係更新の自動化と高コストのリポジトリ単位エージェントの間に置く軽量な振り分け層になり、運用時に使えない事後的な修正証拠に依存せずに、予算を意識した保守を可能にする。
v1の要旨から自動生成。本文の精読・人による確認は未実施。
- 初稿
- 2026-09-22（UTC）
- 最新改訂
- 2026-09-22 · v1
- 査読・掲載
- 査読状況未確認
更新履歴
- v1 2026-09-22 この版を読む
取得できた版を表示。版の更新は査読済みを意味しません。過去版の本文差分は未解析です。
原文の要旨
Dependency-update pull requests are frequent and mostly routine, but a small subset requires non-trivial compatibility repair. Recent repository-level coding agents make such repair increasingly plausible, yet invoking them on every dependency update wastes model calls, CI time, repository context, and review attention. We frame this as a pre-agent routing problem: deciding which dependency-update pull requests should be escalated before downstream diagnosis or repair attempts. We introduce DepFixRouter, a lightweight router that ranks dependency updates by historical compatibility-repair likelihood using creation-time textual and metadata signals. On 497 labeled GitHub dependency-update candidates, only 72 require substantive repair. A creation-time-safe LinearSVC using only PR titles and bot/dependency flags reaches 0.488 repair F1 and captures 51.4% of repairs within the top 20% routed pull requests, improving calls per captured repair from 6.90 under route-all or random policies to 2.68. Retrospective full-history signals improve top-20% recall to 65.3%, revealing substantial hindsight leakage in pull-request histories rather than deployment-time routing utility. In a 60-case diagnosis-agent pilot, router-gated diagnosis reduces actual LLM calls by 66.7% and tokens by 66.1%, suggesting budgetaware escalation while measuring diagnosis rather than patch generation. DepFixRouter can serve as a lightweight escalation layer between routine dependency-update automation and expensive repository-level agents, enabling budget-aware maintenance without relying on retrospective repair evidence for deployment-time routing.
arXiv ID: 2609.25911 ／ 要約の誤りについて