💻 computer science

Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution

本論文では、静的解析を活用してコンテキスト認識型依存グラフ（CDG）を構築することで、Dockerfileのドリフトを効果的に修復する標的型のパッチを生成する、コンテキスト認識型フレームワークであるCadreを提案し、新たに導入された1,040件の実世界のドリフト事例からなる $D^3$ ベンチマークにおいて、既存のルールベースおよびLLMベースのベースラインを上回る性能を示す。

原著者： Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

公開日 2026-07-15

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

CC BY 4.0

原著者： Chengjie Wang, Jingzheng Wu, Xiang Ling, Tianyue Luo, Chen Zhao

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

ガレージでロボットを作っているところを想像してみてください。あなたは、どの部品を手に取り、どこに配置し、どのように組み立てるかを正確に指示する、完璧な取扱説明書（Dockerfile）を書きました。しかしその後、ロボットの脳（ソースコード）をアップグレードすることに決め、いくつかの配線を入れ替えました。あなたは、新しい部品に合わせて説明書を更新することを忘れてしまいました。

さて、そのロボットを組み立てようとすると、ロボットはガタガタと音を立てて止まってしまいます。説明書自体は「壊れて」はいません。文法的な間違いもありません。しかし、説明書は現実から「ドリフト（乖離）」しているのです。説明書は、もはや存在しない部品を掴もうとしたり、置き換えられた道具を使おうとしたりしています。ソフトウェアの世界では、これをDockerfileドリフトと呼び、コンピュータをサイレントに失敗させ、開発者を何日も頭を抱えさせる原因となります。

旧来の手法：暗闇での推測

以前のツールは、単に説明書とエラーメッセージを読み取ることでこれを修正しようと試みました。それは、エンジンのフードを開けて実際の配線を確認することなく、「エンジンチェックランプ」と「オーナーズマニュアル」だけを見て車のエンジンを修理しようとするようなものです。

あるツールは厳格なルール（チェックリストのようなもの）を使用し、別のツールは超高性能なAI（大規模言語モデル）を使用して修正を推測しました。しかし、ここにある問題があります。これらのAIツールは情報に溺れていたのです。彼らはエラーメッセージとともに、ガレージ全体（すべてのネジ、古いマニュアル、そしてガラクタの箱すべて）を渡されていました。AIは情報のノイズに圧倒され、諦めてしまうか、あるいは機能しないデタラメな修正案を「幻覚（ハルシネーション）」として提示してしまいました。実際、41から58件のトラブルが発生するたびに、これらのAIツールはプロンプト（指示リスト）が長すぎて読み取れず、回答を生成することすらできませんでした。

新しいヒーロー：Cadre（名探偵）

ここで、名探偵のように振る舞う新しいフレームワーク、Cadreが登場します。著者であるChengjie Wang氏とそのチームは、ロボットを直す秘訣は、探偵により多くの資料を読ませることではなく、正しい「地図」を与えることにあると気づきました。

彼らのアイデアはシンプルです。**「量よりも構造が重要である」**ということです。どの特定のワイヤーがどの特定のネジに接続されているかを知ることは、無関係なテキストを1,000ページ読むことよりも遥かに重要です。

Cadreは、以下の3つの魔法のようなステップで行われます：

コンテキスト・プロファイラー（タイムトラベラー）： 何かを修正しようとする前に、Cadreはビルドプロセス全体をステップ・バイ・ステップでシミュレートします。どのファイルがコピーされ、どの変数が設定され、どのツールが呼び出されるのかを正確に監視します。これにより、あらゆる瞬間におけるプロジェクトの「状態」のメンタルモデルを構築します。
CDG（依存関係マップ）： そのシミュレーションを用いて、Cadreは**コンテキスト認識型依存関係グラフ（CDG）**を描きます。これはソフトウェアの地下鉄路線図のようなものです。「FROM」命令（ベース）がどのように「COPY」命令（部品）に繋がり、最終的に「RUN」命令（組み立て）へと繋がるのかを示します。もしファイルが変更されれば、マップはその変更によってどの命令が躓くことになるのかを正確に示します。
2ステップの修正（スマートフィルター）： AIにガレージ全体を丸投げする代わりに、CadreはまずAIに賢い質問を投げかけます。「このマップとエラーに基づくと、実際に必要となるファイルはどれですか？」
- ステップ1： AIは関連するファイルのみ（「キーファイル」）を選別します。
- ステップ2： AIはそれらのファイルだけを読み、修正案を作成します。

これにより、AIの「脳」が溢れるのを防ぎます。他の手法では、プロンプトが巨大すぎて41〜58件のケースでパッチ（修正プログラム）を生成できなかったのに対し、Cadreはすべての試行においてパッチを生成できました。

結果：本当に機能するのか？

チームは、GitHubの履歴から掘り起こした1,040件の実世界の事例（ $D_3$ と名付けられたデータセット）を用いてCadreをテストしました。これらは偽の問題ではなく、実際のソフトウェアプロジェクトで発生した、再現に必要な正確な設定を備えた本物の失敗事例です。

Cadreの結果は以下の通りです：

Cadreは問題の**35.22%**を解決しました。
最も優れた従来のAI手法（このスマートなマッピングを持たないもの）は、**28.48%**を解決しました。
旧来のルールベースのチェックリスト手法は、わずか**9.34%**しか解決できませんでした。

つまり、Cadreは最高のAI競合他社よりも1.24倍優れており、旧来のルールベースのツールよりもほぼ3倍優れているのです。

しかし、本当の魔法は問題が「古くなった（stale）」時に発揮されます。例えば、5、6回のアップデートを経て誰も修正していない壊れたビルドを想像してください。最近のコード変更は、元のエラーとは全く無関係に見えることがあります。ほとんどのツールは混乱して諦めてしまいます。しかし、CadreはCDGマップを使用しているため、たとえ歴史の奥深くに埋もれていても、壊れたワイヤーをその起源まで遡って追跡することができます。5回以上のアップデートを経た問題において、Cadraは**25.9%を解決しましたが、次に優れたツールは19.7%**しか解決できませんでした。問題が古くなるほど、その差は広がっており、マップが耐久性のあるシグナルであることを証明しています。

これは「何ではない」のか

Cadreが「何ではないか」を知っておくことも重要です。これはすべてを解決する魔法の杖ではありません。

インターネットが切断されている、あるいはサーバーのディスク容量が不足しているといった問題は修正できません。
プログラム自体の数学的なエラーのような、実際のコードロジック内のバグは修正できません。これはあくまで「ビルド手順」を修正するものです。
失敗したケースの約**65%**では、プライベートレジストリにあるパッケージの欠如など、説明書を変更するだけでは解決できない複雑なビルドツールの制約が原因でした。

まとめ

著者らは、ソフトウェアメンテナンスの未来において、単にAIに大量のデータを投げ込むのではなく、依存関係の「構造」を理解させる方法を学ぶ必要があると示唆しています。ファイルと命令がどのように接続されているかのマップを構築することで、Cadreは、スマートなコンテキスト（文脈）がどれほど大きな力を持つかを証明しました。それは図書館中の本を読むことではなく、どのページをめくるべきかを正確に知ることなのです。

Cadreのすべてのコードと1,040件の実世界のドリフトのデータセットは、誰でも確認できるように公開されており、これが単なる理論ではなく、現実的で再現可能な証拠に基づいたツールであることを保証しています。

技術要約：Taming the Drift: Context-aware Repair of Dockerfile Drift during Software Evolution（ソフトウェアの進化におけるDockerfileドリフトのコンテキスト認識型修復）

1. 問題定義：Dockerfileのドリフト

現代のソフトウェア開発は、再現可能なビルド環境を確保するためのデファクトスタンダードとしてDockerを活用する、継続的インテグレーションおよび継続的デプロイメント（CI/CD）パイプラインに大きく依存しています。しかし、「Dockerfileドリフト」と呼ばれる重大な問題が、この信頼性を損なっています。ドリフトは、Dockerfileがアプリケーションのソースコードに加えられた変更を吸収できなかったときに発生し、ビルドスクリプトと進化するリポジトリの状態との間に不一致を引き起こします。これは構文エラーとは異なり、修正情報が失敗の原因となったものと同じリポジトリ内に存在する、内部的な共進化の問題です。

ドリフトは、不適切なファイルパス、環境変数の不一致、古い依存関係の指定、またはプラットフォームの変更として現れます。これらの失敗は、以下の3つの核心的な課題があるため、自動修復が特に困難です。

C1 (コンテキスト抽出): ビルド状態（作業ディレクトリ、環境変数、ファイルセット）は、単なるDockerfileのテキストではなく、先行する命令の累積的な実行によって決定されます。既存のルールベースおよびLLMベースの手法は、Dockerfileを孤立した存在として扱うことが多く、これらの動的な相互作用をモデル化できていません。
C2 (命令間の依存関係): 命令は、非自明な方法で先行ステップによって生成されたアーティファクトに依存することがよくあります（例：以前のCOPYによって導入されたファイルに対して操作を行うRUNコマンドや、ARGによって設定された変数など）。これらの依存関係は、単体では構文的に可視ではありません。
C3 (根本原因の特定): エラーログは失敗した命令を指し示すことはあっても、以前のコミットで導入されたコード変更に起因する可能性がある根本原因を特定することは滅多にありません。

2. メソドロジー：Cadreフレームワーク

著者らは、ビルドコンテキストを明示的にモデル化するように設計された、コンテキスト認識型フレームワークであるCadreを提案しています。中心となる設計思想は、**「コンテキストの量よりも、コンテキストの構造が修復の質を決定する」**というものです。Cadreは、以下の4つの統合されたフェーズを通じて、これら3つの課題に対処します。

2.1 Dockerfile ドリフト抽出器 (DodeX)

現実的なベンチマークの欠如に対処するため、著者らはGitHub ActionsのCIログから現実世界のドリフト事例をマイニングするパイプラインであるDodeXを開発しました。静的なスナップショットデータセットとは異なり、DodeXは、動的なビルド引数、ターゲットプラットフォーム、および失敗を引き起こした正確なコード変更の差分を含む、完全なビルド構成をキャプチャします。これにより、抽出されたすべてのインスタンスがローカルで再現可能になります。

2.2 命令レベル・コンテキストプロファイラ

C1を解決するために、CadreはDockerビルドプロセスのステートフルなシミュレーションを実行します。Dockerfileの命令を一つずつ辿りながら、以下の要素を追跡するコンテキスト状態 ( $\sigma$ ) を維持します。

現在の作業ディレクトリ ( $\delta$ )
解決済みの環境変数 ( $\varepsilon$ )
コンテナ内に存在するファイルの集合 ( $\Phi$ )

極めて重要な点は、プロファイラが11の主要なエコシステム（Go、Python、npm、Mavenなど）に対してビルドシステム認識型のパーサを採用していることです。RUNコマンドを単なる不透明な文字列として扱うのではなく、これらのパーサは暗黙的なファイル依存関係を推論します（例：go buildがgo.modおよびディレクトリ内のすべての*.goファイルに依存していることを推論するなど）。これにより、すべての命令を正確なビルド時の状態に結びつける命令コンテキストマップ (ICM) が生成されます。

2.3 コンテキスト認識型依存グラフ (CDG)

C2を解決するために、ICMはコンテキスト認識型依存グラフ (CDG)、すなわち、命令間の依存関係を明示する有向非巡回グラフ ( $G = (V, E)$ ) に変換されます。

頂点 (Vertices): 命令ノード ( $V_I$ ) とファイルノード ( $V_F$ ) を含みます。
エッジ (Edges): 制御フローを表す逐次エッジ ( $E_S$ ) と、ファイルと命令の間の「読み取り元」の依存関係を表すデータフローエッジ ( $E_D$ ) を含みます。
このグラフにより、システムは命令の境界を越えた失敗の伝播経路を追跡し、ソースファイルの変更（例：go.mod）が、中間的なCOPYやARGステップを経由して、特定のRUN命令をどのように無効にするかを特定できます。

2.4 コンテキスト精緻化修復ワークフロー

C3を解決し、トークン制限を管理するために、Cadreはシングルショットのプロンプトではなく、2段階のエージェント型ワークフローを採用しています。

コンテキスト照会 (Context Inquiry): LLMには、エラーログ、コードの差分、および簡略化されたCDGが提示されます。LLMは、修復に必要な最小限の関連ファイルとgrepキーワードを選択するよう求められます。このステップにより、ファイルの内容をロードする前に、無関係なコンテキストがフィルタリングされます。
修復生成 (Repair Generation): システムは選択されたファイルのみを抽出し、ターゲットを絞ったパッチを生成します。
このアプローチは、プロンプトのオーバーフロー（競合するLLM手法における一般的な失敗モード）を防ぎ、モデルが因果関係のある証拠に集中することを保証します。

3. 主な貢献

Cadreフレームワーク: コンテキストの構造が量よりも価値があるという洞察に基づいた、新しい修復フレームワーク。ステートフルなコンテキストプロファイラ、依存グラフ、および2段階のLLMワークフローを統合しています。
DodeX および $D^3$ ベンチマーク: 完全なビルド構成を伴うドリフトインスタンスを抽出するパイプラインであるDodeX、および、元のCI実行の正確なパラメータを使用してすべての1,040インスタンスがローカルで再現可能な、初のDockerfileドリフトベンチマークである $D^3$ の作成。
実証的評価: ルールベースのベースライン (Parfum)、検索ベースのベースライン (FlakiDock)、およびバニラLLMと比較した包括的な評価。

4. 実験結果

フレームワークは、 $D^3$ ベンチマーク（ネットワークタイムアウトによるフィルタリング後、653個の実行可能インスタンス）を用いて評価されました。

修復の有効性: Cadreは35.22%の修復率を達成し、ルールベースのベースライン（Parfum、9.34%）を2.78倍、最高のLLMベースのベースライン（Vanilla-LLM、28.48%）を1.24倍上回りました。
トークン効率と堅牢性: Cadreはプロンプトオーバーフローによる失敗を完全に排除しました（ $|F_r| = 0$ ）。プロンプトの95.25%を30kトークン以内に収めました。対照的に、競合するLLM手法は、コンテキスト制限を超過したために41〜58件のパッチ生成に失敗しました。
古いドリフトに対する堅牢性: ドリフトインスタンスが「古く（stale）」なった場合（複数のコミットを経て残っている場合）、差分のみのアプローチの性能は著しく低下しました。5コミット以上の距離がある場合、Cadredは**25.9%の成功率を維持しましたが、最高のベースラインは19.7%**でした。これは、CDGがコミットの距離に対して頑健な構造的信号を提供していることを示しています。
アブレーション研究: CDGを除去すると修復率が4.29ポイント低下し、2段階のワークフローを除去すると3.67ポイント低下し、プロンプトオーバーフローの失敗が再発しました。各コンポーネントは互いに補強し合っていることが分かりました。

5. 意義と主張

本論文は、明示的な依存関係のモデリングが、耐久性のある修復信号であることを主張しています。著者らは、差分のみの手法や検索ベースの手法と比較して、ドリフトがコミットを通じて経過するにつれて、コンテキスト認識型アプローチの優位性が拡大すると述べています。本研究は、コンテキスト認識型のInfrastructure as Code (IaC) 維持が、将来のツール開発における生産的な方向性であることを示唆しています。

著者らは、限界についても謙虚に述べています。CDGは静的解析に基づいており、パッケージレジストリの状態やネットワーク条件といった、未解決の失敗の一部を説明するランタイム要因を完全には捉えることができません。また、ベンチマークは公開されているGitHubリポジトリに限定されています。しかし、本研究は、ビルドコンテキスト（特に命令間のデータフローと制御フロー）を明示的にモデル化することが、進化するソフトウェア構成の自動修復において極めて重要であることを確立しました。