- Agentic AIがもたらすインフラ構築プロセスの激変
- プラットフォームチームの在り方：モジュールの用意から、インフラを管理する仕組みとそれを実行するエージェントの提供へ
- 【考察】Platform Engineeringにおいて、プラットフォーム選定にKubernetes基盤を選定することの優先度は下がるか？
- 終わりに：とはいえ、まだまだ実験段階
こんにちは！ACS事業部の青木です。
みなさん、プラットフォームエンジニアリングしてますか？
2026年03月05日に、Microsoftは「Platform Engineering for the Agentic AI era（エージェントAI時代のプラットフォームエンジニアリング）」という論文を発表しました。
この論文では、「従来のDevOpsにおけるインフラリソースのデプロイ管理フローからAIエージェントによる管理フローにどのように変わるのか」ということや、「それを踏まえてどのようにPlatform Engineeringが変化するか」について述べられています。
ちなみに、上記論文をもとに体系化した成果物として、git-apeというフレームワークがMicrosoft公式から提供されています。
※公式としてはまだ実験的な段階のものとされているので、本格的な基盤での利用はまだ推奨されていません。
git-ape公式サイトはこちら
このブログの内容は、論文の内容についての簡単な紹介と、プラットフォームエンジニアリングにおけるプラットフォーム基盤の選定についてどのような影響が出るかについて考察したものです。
Agentic AIがもたらすインフラ構築プロセスの激変
これまで、私たちがクラウドインフラを構築する際は、CLI、SDK、CI/CDパイプライン、そして各種ラッパーツールといった「人間が機械と会話するための道具（インタラクション層）」を必死に組み合わせてきました。 しかし、AIエージェントの登場によって、この前提が根本から覆ろうとしています。
今後は常に最新バージョンのAPIをエージェントが直接読み込む
これまでのインフラ管理（IaC）では、クラウドプロバイダーが新しい機能をリリースしても、それをインフラコードで使えるようになるまでにはタイムラグがありました。
例えば、新規リソース機能がAzureから公開されても、その機能をTerraformで利用したい場合は、AzureRMプロバイダーのアップデートを待つ必要がありました。
今後、AIエージェントは、クラウドの生のAPI仕様（ライブAPIスペック）を直接読み込んで学習します。そのため、新機能がリリースされたその日（デイゼロ）から、モジュールの更新を待つことなく即座に最新リソースを生成できるようになります。
IaCは「抽象化の道具」から「単なる出力フォーマット」へ格下げされる
私たちがTerraformやBicepを書く最大の理由は、「人間が生のAPIスキーマを読み書きするのは無理だから、扱いやすいコードに抽象化する」ためでした。しかし、AIにとって生のAPIスキーマは最初からそのまま理解できる言語です。
そのため、人間のための「抽象化」が不要になります。AIがインフラを書く世界では、人間が頑張ってTerraformの構文と格闘しながらコードを用意する必要がありません。
変更の記録としてのIaC
ちなみに、「AIが直接APIを叩いてインフラを作れるなら、もうIaCは要らないのでは？」という疑問が湧きますが、論文では「IaCは依然として絶対に必要だ」と結論づけています。
目的は「人間のための表現」から「インフラ環境の変更記録」に変わります。
インフラが今どういう状態にあるのかを検証し、監査し、何かあればロールバックする。そして設定のズレ（ドリフト）を検知して修復するためには、人間がレビューできる「台帳」が必要です。
IaCは、AIの実行結果を記録し、人間が最終チェックするための信頼できる唯一の「台帳」として機能し続けます。
パイプラインやツール操作はエージェントの裏側へ「暗黙化」していく
これまでプラットフォームチームの時間を奪っていたのは、ツールとツールをベタベタと繋ぎ合わせる「パイプラインの接着剤コード」の運用でした。コマンドを叩く、PRを作る、リンター（tflintやOPAなど）を挟む、といった一連のプロセスです。
これらの泥臭いステップが消えるわけではありません。しかし、今後はAIエージェントが「コントロールプレーンインタプリタ（同時通訳機）」として、裏側で自動的にこれらを実行します。
人間から見れば、「やりたいことを言ったら、いつの間にか安全にチェックが行われる」という状態になっていきます。もちろんデプロイタイミングなどの判断を行う役割は残るものの、以前ほどCI/CDパイプラインの運用に注意力が割かれることは少なくなるでしょう。
プラットフォームチームの在り方：モジュールの用意から、インフラを管理する仕組みとそれを実行するエージェントの提供へ
インフラがAIによって自動生成される時代、社内の共通インフラを支える「プラットフォームチーム」の役割も180度変わります。 これからのプラットフォームチームの成果物は、「使い方のドキュメントが膨大なインフラモジュール」ではありません。「自社のルールを完璧に把握し、安全にインフラを生成・運用してくれる『エージェント群』」を開発チームに出荷することになります。
GitHub Organizationレベルのカスタムエージェントとリポジトリレベルのカスタムエージェントの提供
論文では、この新しい仕組みをGitHubのOrganization（組織）とリポジトリの2つの階層に分けて管理するアプローチを提唱しています。
- Organizationレベルのエージェント（全社共通の防衛線） プラットフォームチームが構築・管理し、開発者にも公開されます。セキュリティベースライン、全社共通のネットワークトポロジー、共通の命名規則、必須のコストタグなど、「社内で絶対に破ってはならない共通ガードレール」をエージェントに教え込みます。開発者はこれを使って、新規プロジェクトの立ち上げ（ゴールデンパスの適用）や、全社共通インフラへの接続要求、アーキテクチャの壁打ちを行います。
- リポジトリレベルのエージェント（アプリ独自の最適化） 各開発リポジトリに配置され、そのアプリ固有の文脈を管理します。「このアプリはGoで書かれている」「ステージング環境のリージョンはここ」「過去のTerraformコードの書き方の癖」などをエージェントが学習します。
これにより、開発者がリポジトリレベルのエージェントに「新しくDBを追加して」と頼むだけで、全社レベルのセキュリティを自動で継承した、そのアプリに完璧にフィットするインフラコードがPull Requestとして自律生成される世界が実現します。
GitHub Organizationレベルのエージェントについては以前ブログを書きましたので、よろしければご覧ください。
【考察】Platform Engineeringにおいて、プラットフォーム選定にKubernetes基盤を選定することの優先度は下がるか？
これまでのプラットフォーム選定基準について
これは私個人の意見も含んでいますが、基本的に5システム以上あるような中規模以上のシステム群（開発環境、検証環境、本番環境がシステムごとにある場合、合計して環境が15環境以上あるイメージ）を抱える組織において内部開発プラットフォームを作る場合は、以下の指針を推奨していました。
- コンテナ開発ベースで環境を用意すること
- Container Appsではなく、AKS（Azure Kubernetes Service）にインフラ基盤を集約すること
この結論に至った理由は、「責任分離の難易度」と「環境展開のスピード」という2つの観点に集約されます。
責任分離の難易度
Container AppsでPlatform Engineeringを行う場合は、以下のジレンマに直面します。
- 開発チームに渡すべき領域とプラットフォームチームが握るべき権限の境界を定めるのが難しい
- ネットワークレイヤはプラットフォームチーム、Container Apps以上は開発チームというように分けるとDevOpsのアンチパターンになる
- かといってAzureリソースはすべてプラットフォームチーム側で管理とした場合、開発チームは開発に必要な設定をカスタマイズできない場合がある
- 開発チームにほとんどの権限を渡すとなると、開発チームのノンコア業務が増えたり、プラットフォームチームから見るとセキュリティ上好ましくない設定をされてしまったりする
一方でAKSの場合は以下の利点があります。
- Namespace（名前空間）単位で権限（Kubernetes RBAC）をきれいに分離できるため、開発チームにAzureリソースの管理権限を直接渡さなくても、割り当てられた領域内であればアプリの設定やスケーリングを自由にカスタマイズさせられる
- プラットフォームチームは「クラスター共通の土台（共通Ingress、セキュリティ、ログ収集）」だけを担保し、開発チームは「マニフェスト（HelmやArgoCDなど）」を通じて自分たちの領域を自律的にコントロールできるため、DevOpsのアンチパターンを回避しやすい
環境デプロイまでの手間（スピード）
Container Appsの場合、以下の理由から用意が大変です。
- 各システム環境ごとに、ネットワーク（VNetピアリング、ルートテーブル、Private DNS Zone、WAF等）や運用基盤（Log Analytics、Managed Identity、Key Vault、監視ツール等）を個別に用意する必要がある
- その負荷がプラットフォームチームに集中するため、レバレッジが効かず、開発チームへのレスポンスが遅くなる
一方AKSは以下の通りです。
- 1つの巨大な「箱（クラスター）」を各システムで共有するマルチテナント構成にできるため、新しい環境が必要になった際はNamespaceを切り出すだけで済み、個別のインフラ構築が発生しない
- 共通のHelmテンプレートや構成マニフェストを組織全体で使い回せる（ゴールデンパス化しやすい）ため、プラットフォームチームの作業負荷が大幅に減り、環境の払い出しが圧倒的に速くなる
Agentic AI時代のプラットフォーム選定の考え方
上記の通り、これまでプラットフォームチームがAKSを中心とした基盤を提供することが多かったのは、上記のような「ガバナンスと運用のしやすさ」という側面が大きくあったと思っています。
しかし、Agentic AI時代のプラットフォームエンジニアリングにおいては、上記理由だけでプラットフォームとして無理にKubernetes基盤を選定する理由は減るかもしれません。 開発者はContainer Apps環境を利用したとしても、アプリに最適なアーキテクチャを自由に、かつ安全に選択しやすくなります。
Agentic AI時代の開発チームの動き
- Container Appsを構成するすべてのAzureリソースを管理するときに、アプリに最適なアーキテクチャを自由に、かつ安全に選択できるようになります。
- IaCツールに対する知見を深める必要性は少なくなり、アプリ要件の把握とクラウドリソースに対する適度な知識があれば開発チームでも安全なリソースの運用が行えます。
Agentic AI時代のプラットフォームチームの動き
- AIが開発チームを安全にリードすることによって、開発チームに随時対応する頻度が減る。
- プラットフォームチームは今まで以上にガバナンス設計や全体管理に対処することに時間を割けるようになる。
- より効率的にAzure環境を管理、運用していくためのAIエージェントの作成やカスタマイズを行えるようになる。
結果的に、GitOpsやOSSエコシステムで提供されているような複雑な機能の必要性がなければ、システムが中規模以上に存在していてもKubernetes基盤を選択する必要はなくなるかもしれません。
では、この世界でKubernetesを使う意味とは何でしょうか？
私は、以下のような場合には依然としてAKSを選択する必要性があると考えています。
- システム規模は中規模程度であるものの、基盤がシステムによって通常のCPUだけでなく、AIモデルトレーニングなどの重めの要件でGPUを使う場合
- 大規模環境はコスト最適化の観点で依然AKS基盤に分がある
- 非常に性能要件がシビアなシステムを導入する必要があり、要件達成のためにKubernetesとその周辺のエコシステムを利用する必要がある場合
要は、「よりAKSでしか行えないシステム開発を行う（もしくは将来的に行いたい）場合にAKSを採用する」という機会にシフトしていきそうだなと感じています。
終わりに：とはいえ、まだまだ実験段階
プラットフォームエンジニアの仕事は、コードやクラスターによる物理的な「統治」から、「ガードレール（ポリシー）の整備」と「エージェントの育成」へと完全にシフトしていく過渡期にあります。
とはいえ過渡期ですので、今後もインフラリソースの管理や立場がどのように変わっていくのか、目が離せない状況です。
今後も注意深く動向を追っていきたいと思います。
また、今回は論文の背景と考察を中心にお届けしましたが、今後はこの世界観を実装したMicrosoft公式の実験的プロジェクト「git-ape」の検証結果なども発信していければと思います！
ここまでお読みいただき、ありがとうございました。
ACS事業部のご紹介
私達ACS事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering、AI駆動開発支援などを通して、攻めのDX成功に向けた開発者体験・開発生産性の向上・内製化のご支援をしております。
また、私たちの事業部では、開発生産性向上のためにのマネージドBackstageサービス「PlaTT」を展開しています。
ご興味がある方は是非お問い合わせください。
一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
