技術要約：マルチサービス環境における仕様駆動型DevOps

問題提起

リポジトリのアーティファクトから実行可能なソフトウェア環境を生成するために大規模言語モデル（LLM）を採用する動きが加速しているが、これに伴い、**「機能的な実行可能性は、デプロイメント・インテント（デプロイの意図）への適合を保証しない」**という重大なギャップが明らかになった。LLMは、DockerfileやDocker Composeの設定を合成し、ビルドおよび実行に成功することは多いが、開発者の意図に含まれる暗黙的なアーキテクチャ、セキュリティ、ワークフロー、および本番環境の制約を再構築することには頻繁に失敗する。

既存の研究は、単一コンテナの環境に焦点を当てるか、あるいはインフラストラクチャの意図が明示的に提供されている（例：自然言語によるプロンプト）ことを前提としている。しかし、マルチサービス環境においては、ネットワークセグメンテーション、ポート露出ポリシー、ビルド戦略（例：マルチステージビルド）、シークレット管理メカニズム、および本番用対開発用モードといった重要な決定事項が、ソースコード内に明示的にエンコードされていないことが多い。本研究では、最先端のLLMが、リポジトリのアーティファクトのみから、これらの「意図のみ」の制約を信頼性高く推論できるかどうかを調査し、観察可能な実行時の事実と明示的なデプロイメント・ポリシーの間のギャップを埋めるための**「仕様駆動型DevOps（Specification-Driven DevOps）」**アプローチを提案する。

手法

本研究では、3つの異種混合マルチサービス・アプリケーションを用いたリポジトリ駆動型の生成実験を採用している：

1. example-voting-app: Python、Node.js、.NETからなるヘテロジニアスなスタック（RedisおよびPostgreSQLを含む）。
2. react-rust-postgres: React、Rust、PostgreSQLのスタックであり、隠れたプロキシ構成と入力に含まれない認証情報を備えている。
3. react-java-mysql: React、Java、MariaDBのスタックであり、ファイルベースのシークレットメカニズム（db/password.txt）を特徴とする。

実験的制約:

• 入力: ソースコード、依存関係のマニフェスト、設定ファイル、および補助的なアーティファクトのみ。既存のDockerfileおよびdocker-compose.ymlファイルは明示的に除外した。
• モデル: GitHub Copilot経由のGPT Codex 5.3。
• プラットフォーム: Apple M1 Pro (ARM64)。
• 検証:
  • 機能的オラクル（Functional Oracle）: 完全なマルチサービス・パイプライン（例：投票の送信からワーカーを経由したデータベースへの伝播）を検証する、決定論的なエンドツーエンドのHTTPリクエスト。
  • 構造的比較: 生成されたアーティファクトを、開発者が作成したグラウンドトゥルース（正解）と比較する手動分析を行い、セキュリティ、ワークフロー、および本番環境への準備態勢における忠実度を評価する。

形式的フレームワーク:
本研究では、変換 $T_M: R \to E$ を定式化する。ここで、$R$ はリポジトリ、$E$ は生成された環境である。以下を区別する：

• 機能的正当性 ($E_G \equiv_F E_D$): 環境が動作し、オラクルをパスすること。
• デプロイメント・インテントの忠実度: 構造が開発者のアーキテクチャおよびポリシーの決定にどの程度一致しているか。

主な貢献

1. 経験的境界の定義: 本研究は、DevOpsの知識を以下のカテゴリに分類するタクソノミーを確立した：
   • 観察可能／派生可能: サービス・トポロジー、ポート、依存関係、およびバックグラウンド・ワーカー（正常に推論された）。
   • 未決定（Underdetermined）: 特定の認証情報、または互換性のあるイメージバージョン（推論されるが、グラウンドトゥルースと不一致になる可能性がある）。
   • 意図のみ（Intent-Only）: ネットワークセグメンテーション、ポート露出ポリシー、ビルド戦略、および本番用サービングモード（一貫して欠落、またはデフォルト値に設定された）。
2. 仕様駆動型DevOpsモデル: 本論文は、ハイブリッド生成モデル $E = G(R, S_{min})$ を提案する。ここで、$S_{min}$ は最小限の明示的デプロイメント仕様である。この仕様には、リポジトリから信頼性高く推論できない、不可逆的な意図のみが含まれ、ソースコードに既に存在する情報の重複を避ける。
3. 評価フレームワーク: 「実行可能な正当性」と「構造的忠実度」の区別を行い、機能的な実行とは別に、セキュリティ、ワークフロー、ポータビリティ、および本番環境への準備態勢を個別に評価する多次元評価モデルを導入した。
4. 最小仕様テンプレート: 観察された欠落に対処するため、デプロイメント・コンテキスト（dev/prod）、ネットワークセグメンテーション、ビルド戦略（マルチステージ）、シークレットメカニズム、およびプラットフォームの制約をカバーする概念的なYAMLテンプレートを導出した。

結果

機能的成功:

• 生成されたすべての環境は、1つのベースイメージのバージョン競合（Rust 1.85から1.88へ）を解決した後、機能的な運用ステータス（成功率100%）を達成した。
• LLMは、バックグラウンド・ワーカー、隠れたプロキシ構成、およびファイルベースのシークレットメカニズムを含む、複雑なサービス・トポロジーを正常に再構築した。

構造的および意図の欠陥:
機能的な成功にもかかわらず、生成された環境にはデプロイメント・インテントに関する系統的な欠落が見られた：

• ネットワークセグメンテーション: すべての環境がフラットなネットワークとして生成され（0/3）、バックエンドサービスをパブリックアクセスから隔離することに失敗した。
• ポート露出: 適用可能な2ケースのうち2ケースにおいて、バックエンドのポートが不必要にホストに露出しており、制限的なセキュリティポリシーに違反していた。
• ビルド戦略: マルチステージビルドや最適化された依存関係レイヤーのキャッシュは生成されなかった（0/3）。
• 本番用サービング: フロントエンド・サービスは、本番環境に適したNginx構成ではなく、開発用サーバーを利用していた（適用可能な2ケース中0/2）。
• ワークフロー: 開発用のライブリロード用ボリュームマウントが存在しなかった（0/3）。

トレーサビリティ:
本研究は、ランタイムの依存関係は観察可能であるが、負の制約（例：「このポートを露出させない」）やポリシー決定（例：「Docker secretsを使用する」）は、ソースコードのみからは信頼性高く推論できないことを示した。

意義および主張

本論文は、リポジトリのアーティファクトから推論できることと、明示的に指定しなければならないことの間の実用的な境界を特定したと控えめに主張している。

• 普遍的な解決策ではない: 著者らは、結果が評価された3つのリポジリアリポジトリに適用されるものであり、任意のマイクロサービス・エコシステムに対する普遍的な信頼性を主張するものではないと明言している。サンプルサイズは小さく、リポジトリは明快さを目的として選択されており、馴染みによるバイアスが生じている可能性がある。
• 分析的導出: 提案された最小仕様およびハイブリッド生成モデル ($G(R, S_{min})$) は、分析的に導出されたものである。本研究は、仕様を用いて生成を再実行することでその有効性を実験的に検証したものではなく、フレームワークを提案するにとどまっている。
• 核心的な洞察: 主要な貢献は、「シグナルのギャップ」の定式化である。本研究は、リポジトリのエビデンスはランタイム要件を再構築するには十分であるが、デプロイメント・インテントを再構築するには不十分であると結論付けている。したがって、生成された環境が単に実行可能であるだけでなく、安全で、保守可能であり、かつ本番環境のポリシーに沿ったものであることを保証するためには、仕様駆動型のアプローチが必要である。

本論文は、DevOpsの文脈におけるLLM駆動型のコード生成を補完するために、明示的かつ機械処理可能な仕様の必要性を動機付ける、探索的な実現可能性調査として位置づけられている。