Environment as Code：信頼できるフィードバックの基盤としての再現性

前述の3つのフィードバック層（静的解析、CI/CD、Observability）はすべて、暗黙の前提を共有している：Agentがコードを実行する環境が予測可能であること。同じコードがAgent Aの環境では正常に動作するのにAgent Bの環境では失敗するなら、すべてのフィードバックシグナルは意味を失う。問題がコードにあるのか環境にあるのか判別できないからだ。

この問題は人間の開発にも存在する --- 「私のマシンでは動く」は古典的なジョークだ。しかしMulti-Agent並列シナリオでは、桁違いに増幅される。5つのAgentが同時に作業し、それぞれのランタイム環境が微妙に異なる（依存関係のバージョン違い、環境変数の欠落、システムライブラリの不整合）と、組み合わせ爆発的な問題が発生し、デバッグが極めて困難になる。

Infrastructure as Codeの核心的価値は、このコンテキストで明確になる：環境をバージョン管理され、再現可能で、監査可能なアーティファクトに変えることだ。Dockerfile、Terraform設定、docker-compose定義 --- これらのファイルはビジネスコードとともにリポジトリに置かれ、Agentはそれらを読み、理解し、修正できる。

Agent駆動開発にとって、IaCはいくつかの具体的な目的を果たす。

再現性はフィードバックの一貫性を保証する。CIが精密に定義されたコンテナ内でテストを実行するとき、テスト結果はコード自体の状態を反映し、特定のマシンの偶発的な設定を反映しない。Agentがテスト失敗のシグナルを受け取ったとき、環境を疑う必要なく、失敗がコードによって引き起こされたと確信できる。

環境の隔離はAgentの並列作業をサポートする。各Agentが独立したコンテナで実行され、互いに干渉しない。あるAgentが実験的な依存関係をインストールしても、別のAgentのビルドには影響しない。これは前述のgitブランチ隔離と同じ原則が、異なるレイヤーで適用されたものだ：コードレベルの隔離はブランチで、環境レベルの隔離はコンテナで。

環境変更が監査可能になる。AgentがDockerfileやTerraformファイルを変更したとき、その変更はビジネスコードの変更と並んでコードレビューに現れる。環境の変更はもはや運用スタッフがサーバー上で手動で行う不透明な操作ではなくなり、diff、レビュー、ロールバック機能を持つ通常のコード変更となる。

実務上の考慮事項もある。多くのチームのAgentワークフローは、すでにAgent CLIをDockerコンテナ内でヘッドレスモードで実行し、インタラクティブな許可プロンプトをスキップし、ファイルシステムを通じてプロセス間通信を行う形態に進化している。このパターンは本質的に環境定義のコード化を要求する：各コンテナの環境を手動で設定することはできず、宣言的な設定ファイルで定義しなければならない。ここでのIaCは「ベストプラクティス」の推奨ではなく、Agentを大規模に実行するための必須前提条件だ。

ただし、デモと本番のギャップには注意が必要だ。ローカルのDocker環境ですべてが動くからといって、実際の本番環境で動くとは限らない。外部システムの振る舞いは制御外だ：銀行インターフェースのタイムアウトポリシー、サードパーティAPIのレート制限ルール、ネットワーク分断時の障害モード。分散コンピューティングの8つの誤謬はAgent時代にも完全に当てはまる。IaCは自分が制御する環境の再現性問題を解決する。制御できない外部依存に対しては、Observabilityとフォールトトレラント設計への投資が依然として必要だ。