EPAM Systems に所属する 4 人の著者による本論文は、アプリケーションのリポジトリにあるデータだけで LLM が動作するマルチサービス環境をデプロイできるのか、そしてリポジトリからは何が伝わらないのかを問う。環境の自動構築に関する先行研究の多くはテスト向けの単一コンテナを対象としており、LLM ベースの Infrastructure as Code 生成は通常、専門家が書いた目的のインフラストラクチャの記述から出発する、と本論文は指摘する。これに対して本研究では、リポジトリ自身の Dockerfile と Compose ファイルを伏せたうえで、モデルがソースコード、マニフェスト、設定からデプロイを復元しなければならない。
実験では、Apple M1 Pro（ARM64）ホスト上で GitHub Copilot を通じて GPT Codex 5.3 を使用し、Docker のサンプル集から 3 つの公開リポジトリを用いた。example-voting-app（Redis と PostgreSQL を伴う Python、Node.js、.NET のサービス）、react-rust-postgres（React、Rust/Actix Web、PostgreSQL）、react-java-mysql（React、Java Spring Boot、MariaDB/MySQL データベース）である。生成された各環境は、構文、イメージのビルド、テキストの類似度ではなく、サービスのパイプライン全体を通る決定論的なエンドツーエンドの HTTP リクエストによって判定され、その後、開発者が作成した成果物と手作業で比較された。
要点
- 生成された 3 つの環境はすべて機能的に動作可能になった。2 つは最初のビルドで、Rust の環境は現行の Actix Web の依存関係を満たすためにベースイメージを Rust 1.85 から 1.88 に変更した後に動作し、初回ビルドの成功率は 2/3、最終的な成功率は 3/3 となった。
- モデルは 3 つのケースすべてで、言語エコシステム、アプリケーションのポート、インフラストラクチャサービス、ホスト名、
depends_onの関係を正しく再構築した。また、HTTP エンドポイントを持たない .NET のバックグラウンドワーカーを特定し、setupProxy.jsで設定されたフロントエンドのプロキシを発見し、単独のdb/password.txtファイルから Docker のシークレット機構を推論した。 - 認証情報が伏せられた Compose ファイルにしか存在しない場合、モデルは別の値を作り出したが、それを一貫して伝播させたため、環境はテストに合格した。著者らは、未確定の値については、開発者が書いた値をそのまま再現することよりも内部的な一貫性のほうが重要かもしれないと結論づけている。
- モデルはデプロイ意図を一貫して欠落させた。ネットワークの分離（0/3、毎回フラットなネットワーク）、マルチステージの Dockerfile、依存関係レイヤーのキャッシュ、ライブリロード用のマウント（いずれも 0/3）、Nginx による本番用のフロントエンド配信（0/2）、制限的なバックエンドポートの公開（0/2、バックエンドのポートはホストに公開されていた）、クロスプラットフォームのビルドロジック（0/3）である。著者らは、デプロイに必要な知識とリポジトリから読み取れる情報との間のこのギャップを「シグナルギャップ（signal gap）」と呼んでいる。
- 著者らは DevOps の知識を、直接観察可能、導出可能、未確定、意図のみの 4 つに分類し、観察可能・導出可能な知識は概ね再構築できた一方、未確定の知識と意図のみの知識には明示的な仕様か管理されたデフォルト値が必要だと論じる。
- これに基づいて著者らは 仕様駆動 DevOps を提案する。これは、観察可能な情報はリポジトリのエビデンスが提供し、残りは最小限の明示的なデプロイ仕様が提供するというもので、そのフィールド、競合解決の原則、検証ルール、トレーサビリティモデルの概略を示している。この仕様は分析的に導出されたものであり、再生成によるテストは行われていない。
補足
本論文は、LLM ベースの Dockerfile および環境合成の研究、IaC 生成のベンチマーク、そしてコード–テキスト–コードの再エンジニアリングやアーキテクチャのメタモデルといった仕様駆動のアプローチ（その一部は同じ著者らの先行研究）の間に自らを位置づけている。著者らは本研究を探索的な実現可能性の実験と位置づけ、その限界として次の点を挙げている。モデルが訓練中に接した可能性のある、比較的単純で公開されている 3 つのリポジトリしか用いていないこと。単一のモデルを用い、リポジトリごとに 1 回しか生成を試みておらず、やり取りの記録が十分に文書化されていないこと。リポジトリごとに HTTP オラクルが 1 つだけで、セキュリティ、パフォーマンス、障害のテストを行っていないこと。著者ら自身が正式な評価基準なしに手作業で構造比較を行ったこと。Rust のバージョンの修正が LLM ではなく手作業で行われたこと。そして提案した仕様の実験的な検証が行われていないことである。