IaCは「なくなる」のではなく「脇に回る」
Microsoftが2026年3月5日に公開したブログ記事「Platform Engineering for the Agentic AI era」は、インフラエンジニアにとってかなり刺激的なタイトルで始まる。「IaCコードを書くのはもう古い」──。
ただし、内容を読むと「IaCが不要になる」とは言っていない。TerraformやBicepが消えるわけではなく、それらは「主要な意図の表現手段」から「コンパイル済みの実行形式の一つ」に降格する、というのが正確な主張だ。この微妙な差は、実は大きい。
従来の多層スタックのどこが問題だったか
従来のモデルを整理するとこうなる。エンジニアの「こういうインフラを作りたい」という意図は、まずCLIコマンドやGitOps/CIワークフロー、プルリクエストといったインタラクション層を通り、次にAWS CloudFormation・ARM/Bicep・Terraform HCLなどのIaC抽象化層に変換され、そこからようやくクラウドプロバイダーのAPIを叩く。
少なくとも3層を経由する構造だ。Microsoftはこれを「正確性と安全性を確保するための仕組みではあるが、構文やツールへの深い習熟が必要で、往々にして低速で冗長」と評している。批判は控えめだが、実務者なら刺さる表現だと思う。
AIエージェントが何を省略するのか
最新のAIエージェントは、自然言語で書かれた意図を受け取り、APIスキーマについて推論を行い、IaCを生成・検証した上で、ガードレールや承認フローを維持しながらクラウドに変更を直接適用できる。
つまり、あの3層スタックが「1つのインテリジェントな層」に集約される。CLIラッパーや独自ツール、パイプラインの接着剤コードといった「人間がAPIを叩くために書いてきた雑用仕事」が、暗黙のものになる。
この変化がプラットフォームチームに与える影響として、Microsoftは4点を挙げている。
- インタラクションが構文から意図へ：設計の議論が「どう書くか」ではなく「何が欲しいか」になる。
- ガードレールがエージェントに組み込まれる：セキュリティ・コスト・コンプライアンスのポリシーがエージェントの指示の中に入り、高リスクな操作にだけ人間のチェックポイントが残る。
- モジュールが知識になる：静的なTerraformモジュールが、エージェントが動的に参照するアーキテクチャパターンへと進化する。
- ドリフト修正が継続的になる：エージェントが逸脱を検知し、修正案を提案し、承認を求め、自動適用する。可観測性と対応のギャップが埋まる。
「台帳」がIaCからガバナンス文書に移る、というのが本質
ここが、この記事で一番面白い視点だと思っている。
従来、IaCファイルはインフラの「システムオブレコード（SoR）」だった。何がどう構成されているかの正しい台帳がTerraformのコードであり、それが真実だった。
Microsoftはこれが変わると言っている。将来の台帳は、NISTやHIPAAなどのセキュリティ標準、アーキテクチャ決定記録（ADR）、承認済みレファレンスアーキテクチャ、ランブック（作業指示書）といったガバナンス文書群になる。IaCはそこから生成される「コンパイル結果」に過ぎなくなる。
言い換えると、「インフラがどのように表現されるか」より「なぜ存在を許可されているか」が主役になる。これはセキュリティやコンプライアンスの観点から見ると、むしろ健全な方向への転換だ。
もう一点付け加えると、セキュリティの強制は「生成時・計画時・実行時」の3層構造になる。tflintやSentinel、OPAが計画時に問題を検出し、Azure Policyが実行時の最終防衛ラインとして機能する。Microsoft Defender for CloudはGitHubリポジトリからIaCスキャン結果、デプロイ済みリソース、ランタイムのセキュリティ状態まで一元可視化し、構成ミスをそれを引き起こしたIaCの行まで追跡できる。コンプライアンスは「通過すべきゲート」ではなくプロセスに内在するものになる、という表現は実務に近い感覚だ。
実務的に何をすべきか──Microsoftが示した4ステップ
Microsoftはプラットフォームチームが今から取り組める具体的な4ステップを示している。
1. 指示とコンテキストの記述：github/copilot-instructions.mdにベースラインルールを作成し、ADRやレファレンス実装、承認済みパターンをCopilot Spaceに追加する。AIはコードを生成する前にここを参照する。
2. 再利用可能なスキルの構築：命名規則の検証、コストセンターコードの参照、破壊的変更のチェックといった作業を個別スキルに分解する。スキルはどのチャットやエージェントからも呼び出せる。
3. カスタムエージェントの作成：指示・スキル・コンテキストをまとめた組織固有のエージェントを作り、@your-infra-agentとしてCopilot Chatから呼び出せるようにする。
4. Copilot Coding Agentへの実行委任：設定が整えば、エージェントが自律的に動作する。指示を読み取り、スキルを呼び出し、IaCを生成し、PRを開き、レビューフィードバックに対してイテレーションを回す。
「50個のモジュールを更新する」という保守作業が、「エージェントのコンテキストを更新する」に変わる──これは誇張ではなく、実際のメンテナンスコストの話だ。
インフラエンジニアに求められるものが変わる
この話は「AIがインフラエンジニアの仕事を奪う」という文脈で読むより、「求められるスキルセットが変わる」と読む方が実態に近い。
Terraformの構文を書ける人よりも、組織のアーキテクチャ上の意思決定を文書化し、セキュリティポリシーをエージェントに食わせられる形に整理し、ガードレールを設計できる人の方が価値を持つ時代になる。
ただし留保も必要だ。この記事はMicrosoftが自社サービス（GitHub Copilot、Azure Policy、Defender for Cloud）の文脈で書いたものであり、ベンダー中立な視点とは言えない。エージェントが本当に「ガードレールを維持しながら」安全に動くかどうかは、実運用での検証が必要だ。プロバイダーAPIが最終的な真実の源泉であり、承認やリスク判断における人間の責任は不可欠だ──この一文はMicrosoft自身も明記している。
とはいえ、方向性としての「IaCは脇役になり、ガバナンス文書が主役になる」という転換は、一読の価値がある視点だと思う。
