「IaCコードを書くのはもう古い」 インフラエンジニアの仕事を変える「AI駆動インフラ」の具体像：意図通りに構築、運用できるか

Microsoftは、AIエージェントの台頭がクラウドインフラのプロビジョニングや運用の在り方を根本的に変えつつあることを解説したブログ記事を公開した。

[＠IT]

　Microsoftは2026年3月5日（米国時間）、AIエージェントの台頭がクラウドインフラのプロビジョニングや運用の在り方を根本的に変えつつあることを解説したブログ記事「Platform Engineering for the Agentic AI era」（エージェント型AI時代のプラットフォームエンジニアリング）を公開した。

　記事では、従来のInfrastructure as Code（IaC）中心のアプローチが、AIエージェントによって大きく変革されるとしている。AIエージェントが人間の意図をプラットフォームアクションに直接変換できるようになったことで、CLI（コマンドラインインタフェース）やSDK（ソフトウェア開発キット）、パイプラインといった従来のAPIインタラクション層に取って代わりつつあると指摘している。

従来の多層スタック

　従来のモデルでは、IaCは、人間の意図を実行に移すまでの多層スタックの中に位置している。エンジニアのアーキテクチャ上の意図は、明示的なインタラクション層（CLIコマンド、GitOps/CI《継続的インテグレーション》ワークフロー、プルリクエスト《PR》、UIプロセスなど）を経由して、IaCの抽象化層（「AWS CloudFormation」《※1》、ARM/Bicep《※2》、「Terraform HCL」《※3》など）に変換される。そして最終的に、クラウドプロバイダーのAPI（AWS、Azure、Google Cloud、SaaSプラットフォーム）を駆動する。

※1.AWS（Amazon Web Services）のIaCサービス。
※2.ARMは、「Microsoft Azure」のデプロイおよび管理サービス「Azure Resource Manager」の略。Bicepは、JSON形式のARMテンプレートを大幅に簡素化した専用のIaC言語。Bicepファイル内で、Azureにデプロイするインフラを定義する。
※3.オープンソースのIaCツール「Terraform」の設定言語。Hashicorp Configuration Languageの略。

　この多層構造は、正確性と安全性を確保し、人間の意図をAPI呼び出しに変換するための仕組みだ。だが、構文やツールへの深い習熟が必要であり、往々にして低速で冗長になりがちだった。

従来の抽象化層（提供：Microsoft）

AIエージェントが従来のモデルをどう変えるのか？

　AIエージェントはこの流れを根本的に変える。最新のエージェントは自然言語の意図を受け取り、APIスキーマについてリーズニング（推論を含む）を行い、IaCを生成、検証した上で、ガードレールや承認フローを維持しながら、プロバイダーAPIを通じてクラウドに変更を直接適用できる。

　その結果、複雑なインタラクションスタックは1つのインテリジェントな層に集約される。インタラクション層は依然として存在するが、エージェントがAPI仕様やプロバイダースキーマ、組織の制御を利用して、動的に構築するようになる。

人間の意図→エージェント（リーズニング＋ポリシー）→IaC/API（提供：Microsoft）

現在のIaCの位置付けと将来像

　IaCは現在、エンタープライズプラットフォームにおける「システムオブレコード」（SoR）であり続けている。以下を提供するからだ。

• 決定論的な望ましい状態モデル
• バージョン管理された変更履歴
• レビュー可能な計画
• ドリフト（逸脱）に対する調整メカニズム

　エージェントが支援するワークフローにおいても、IaCは、プラットフォームの状態を検証、修正するための“正しい台帳”として機能する。監査可能性、ロールバック、インシデント対応、規制下の変更管理のために、明示的、宣言的、かつ人間がレビュー可能な状態であり続ける。

　だが、エージェントシステムは長期的に、デリバリーシステムにおける「真実の源泉」を再定義する。エージェントがプロバイダースキーマやAPI仕様についてリーズニングを直接行い、ポリシー適用を伴う変更の実行、完全かつ不変の実行トレースの生成、宣言した意図に対するライブ状態の継続的な調整を行えるようになるにつれて、IaCの役割は変化する。

　IaCは将来、意図の主要な表現手段である必要はなくなる。セキュリティコンプライアンスポリシーやアーキテクチャ決定記録（ADR）、レファレンス図、人間の明示的な意図といった上位入力から生成される、コンパイル済み実行形式の一つになる。権威ある記録は上流に移行し、インフラが「どのように表現されるか」ではなく、「なぜ存在を許可されているか」を示すようになる。

API層のショートカットと新たな台帳

　API層のショートカットは、エージェントがIaCやAPIを不要にするということではない。これらを唯一の真実の源泉ではなく、実装アーティファクト（成果物）として再定義し、APIインタラクション層を省略することを意味する。

　すなわち、人間が意図をAPI呼び出しに変換するために使用してきたAPIインタラクション層（CLIやラッパー、独自ツール、パイプラインの接着剤となるコード）は、暗黙のものになる。代わりにエージェントが制御プレーンの解釈者として、意図を基底のAPI層に継続的にマッピングするようになる。

　これに伴い、エージェントモデルにおける台帳は、ガバナンス文書群になる。その中には、NIST（米国立標準技術研究所）、HIPAA（Health Insurance Portability and Accountability Act）などのセキュリティ標準やアーキテクチャ決定記録、承認済みレファレンスアーキテクチャ、正規の図が、検証可能な証拠としてのエージェントの変更トレースとともに含まれる。従来のIaCツールは、実行形式や互換層の役割を果たすことになる。

　具体例としては、ネットワークセグメンテーションやID境界、データ分類制御などが挙がっている。

プラットフォームエンジニアリングへの影響

　こうした変化は、プラットフォームチームに4つの直接的な影響をもたらす。

1.インタラクションが構文から意図へ

　IaCは実装の詳細を表す部分になり、設計の議論は「どう表現するか」ではなく、「何を望むか」に移行する。

2.ガードレールがエージェントに組み込まれる

　セキュリティやコスト、コンプライアンスのポリシー適用は、エージェントの指示の中に組み込まれ、高リスクな境界では、人間によるチェックポイントが設けられる。

3.モジュールが知識になる

　モジュールは、エージェントが利用できるパターンに進化する。エージェントが自動的に選択するアーキテクチャ標準や推奨のデフォルト（規定）をエンコードするようになる。

4.ドリフト修正が継続的になる

　エージェントがドリフト（逸脱）を検知し、修正案を提案し、計画を生成し、承認を求め、修正を適用する。これにより、オブザーバビリティー（可観測性）とアクションの間のギャップが解消される。

変わらないもの

　原理原則は変わらない。プロバイダーAPIが依然として最終的な真実の源泉であり、承認やリスク判断における人間の責任は不可欠だ。

　変わるのはSoRだ。従来はIaCファイルが主要な実行台帳として機能してきたが、組織はポリシー、セキュリティ基準、アーキテクチャアーティファクト（ADR、レファレンスアーキテクチャ、ダイヤグラム、ランブック《作業指示書や手順書》）をガバナンス台帳として扱える。

3層の強制とセキュリティ

　セキュリティの強制には3つの層がある。

生成時

　AIが生成段階で指示、スキルなどを使用し、組織のパターンを適用する。エージェントは組織の基準、アーキテクチャ文書、承認済みパターンなどを読み込んでから、コードを作成する。

計画時（静的解析）

　例えば、「tflint」「Sentinel」「OPA」（Open Policy Agent）、「Template Analyzer」といったツールが問題を検出する。「Microsoft Defender for DevOps」などのツールがCI/CD（継続的インテグレーション／継続的デプロイ）に直接統合される。基準を満たさないコードはマージ前にブロックされる。

実行時（クラウド強制）

　「Azure Policy」が最終的な強制層として機能し、基準を満たさないリソースをデプロイ時に拒否または監査する。

ワークフローへのコンプライアンスの組み込み

　GitHubプラットフォームが新たな制御プレーンとなり、コンテキスト、指示、エージェント、検証の各層でコンプライアンスを強制する。さらに、マージ後もクラウド強制層で「Azure Poicy」がランタイムガバナンスを提供する。

コードからクラウドへの一貫したセキュリティ

　例えば「Microsoft Defender for Cloud」は、GitHubリポジトリからIaCスキャン結果、デプロイ済みリソース、ランタイムのセキュリティ状態まで、全てを接続し、一元的に可視化する。デプロイ済みリソースの構成ミスを検知すると、それを引き起こしたIoCの行までさかのぼることができ、調査作業は不要だ。つまり、コンプライアンスは、通過すべきゲートではなく、プロセスに内在するものになる。

プロビジョニングを超えて：運用におけるAI

　AIによる変革はプロビジョニングにとどまらない。例えば「Azure SRE Agent」サービスは、インシデント検知や根本原因分析、修正案提示といった「デイ2」運用にまでAIを拡張する。インフラエージェントと同様に、ランブックやアーキテクチャコンテキスト、エスカレーションポリシーを参照する。

　このサービスにより、AIが基準に準拠したインフラを生成し、Defender for Cloudがコードからクラウドまでを監視し、Azure Policyが実行時に強制を行い、AIが運用を支援し、重要な意思決定は人間が行うというループが完成する。

新しい中心的なアーティファクト：エージェント

　モジュールは優れた抽象化を実現するが、静的だった。AIはプラットフォームエンジニアリングにおいて、APIの再現性や多層的なコンプライアンス、生きたドキュメント、シミュレーションといった点で、モジュールレジストリをはるかに上回るメリットを提供する。

　その中心を担う新しいアーティファクトがAIエージェントだ。

• リポジトリレベルのエージェント
  特定のコードベース（パターンや依存関係、デプロイターゲット）を理解し、適したインフラを生成する
• 組織レベルのエージェント
  セキュリティベースライン、命名規則、ネットワークトポロジーなど、組織全体の標準をエンコードする。そのため、全てのリポジトリレベルエージェントが一貫したガードレールをデフォルトで継承する。

エージェントアーキテクチャの概要（提供：Microsoft）

　ポリシーやコンテキストドキュメント、サンプルは、エージェントが利用する入力となる。エージェントはプラットフォームチームが作成し、他のソフトウェアと同様にバージョン管理、テスト、デプロイされる。メンテナンスの苦労は、「50個のモジュールを更新する」ことから「エージェントのコンテキストを更新する」ことへと変わる。

プラットフォームチームが取り組むべき4つのステップ

　Microsoftは、プラットフォームチームが以下の実践的な取り組みを始めることを勧めている。

1. 指示とコンテキストの記述
   「github/copilot-instructions.md」にベースラインルールを作成し、ADRやレファレンス実装、承認済みパターンを「Copilot Space」（仕様書、設計メモ、イシュー、PRといった情報を集約する場所）に追加する。AIは何かを生成する前にこれを参照する
2. 再利用可能なスキルの構築
   CMDB（構成管理データベース）に含まれる環境メタデータの確認、命名規則の検証、コストセンターコードの参照、破壊的変更のチェックなど、エージェントの作業を個別スキルに分解する。スキルはあらゆるチャットやエージェントから呼び出せる
3. カスタムエージェントの作成
   指示やスキル、コンテキストをまとめ、一貫したエージェントを作成する。ユーザーは「Copilot Chat」で「@your-infra-agent」として呼び出せる
4. 「Copilot Coding Agent」への実行委任
   構成が完了すれば、Copilot Coding Agentは自律的に動作する。指示を読み取り、スキルを呼び出し、IaCを生成し、PRを開き、レビューフィードバックに対してイテレーションを行う。

プラットフォームチームの目指す状態（提供：Microsoft）

　プラットフォームチームは「成果物としてモジュールを作成し、エンジニアに提供して、47個の変数を指定して活用することを求める」のではなく、「組織のインフラコンテキストを理解し、基準に準拠したコードをオンデマンドで生成するAIエージェントを作成し、エンジニアに提供する」ようになる。

プラットフォームチームの役割のシフト（提供：Microsoft）

　AIが基準に準拠したインフラをオンデマンドで生成できれば、プラットフォームチームの仕事はIaCの記述から、ガードレールやパターン、エージェントの構築にシフトする。

AI駆動インフラ構築中の様子（提供：Microsoft）