要点

Platform の中心課題は Platform を大きくすることではなく、AIの探索空間を小さくし、安全に、検証可能にすることです。
AI Coding Agent はコードだけでなく az、kubectl、Terraform、GitHub Actions まで扱えるようになりました。「人間が難しい操作を覚えなくて済むように隠す」という従来の抽象化の価値は、相対的に下がります。
一方で Platform が不要になるわけではありません。Knowledge、Golden Path、Security & Guardrails、Verification など、AI時代ならではの役割へ広がります。
Security は後段のレビューだけでは足りません。AIの権限そのものを Identity・RBAC・Policy で設計する必要があります。
Platform を厚くしすぎるとかえって認知負荷が増えます。評価すべきは「抽象化の有無」ではなく、減る複雑さと導入・学習・保守にかかる複雑さの差分です。

はじめに

この記事は、AI Coding Agent を業務開発に使い始めているエンジニア・テックリード・Platform チーム向けに書きます。Platform Engineering、Internal Developer Platform、Golden Path といった言葉には既に馴染みがある前提で進めます。Developer Portal を運用中の方や、AI Coding Agent の本格導入を検討している方を想定しています。Kubernetes や Terraform、CI/CD の基礎知識は前提とします。

私自身、複数のサービスを並行して開発する中で、AI Coding Agent に設計・実装・デプロイまで任せる場面が増えました。その結果、従来の Platform Engineering の考え方だけでは説明しきれない課題に直面しました。この記事は、その経験から整理した現時点の考えです。唯一の正解ではなく、2026年9月時点での私の見解として読んでいただければと思います。

Platform Engineering の前提が変わる

従来の Platform Engineering は、クラウド、Kubernetes、CI/CD、監視、セキュリティといった複雑さを Platform 側で吸収することを目指してきました。そのうえで、開発者へセルフサービスな Golden Path を提供することを目的としてきました。

しかし AI Coding Agent は、コードだけでなく az、kubectl、Terraform、GitHub Actions、各種 API まで直接扱えるようになりました。この変化で、状況が変わります。「人間が難しい操作を覚えなくて済むように隠す」という抽象化の価値は、相対的に下がっていきます。

この変化の本質は一言でいえば、Platform の主要ユーザーが AI Coding Agent にもなる、ということです。Platform の利用者はもはや人間の開発者だけではありません。Platform は「人に使いやすいか」だけでなく、「AIが理解・判断・操作しやすいか」でも評価されるようになります。

AI時代の Platform Engineering が担う6つの役割

AI時代の Platform Engineering は、単にクラウドを隠蔽するためのものではありません。むしろ以下の6つの役割へ広がっていきます。

役割	内容
Knowledge Enablement	AIが組織の設計原則、標準構成、禁止事項、過去の判断を理解できる状態を作る
Golden Path	AIが毎回ゼロから技術選定せず、推奨パターンへ短距離で到達できるようにする
Reusable Components	IaC Module、CI/CD Template、共通ライブラリ、MCP などを再利用可能にする
Security & Guardrails	AIが「できること」と「してよいこと」を分離し、危険な操作を技術的に抑止する
Verification & Evaluation	AIが生成したコード・構成・Agent 動作を自動テスト、Eval、Policy で検証する
Runtime Governance	必要な領域に限り、実行環境、Identity、Network、Observability を強制的に統制する

最重要課題は「AIの探索空間を小さくすること」

AIに大量の技術情報を与えれば良い、というわけではありません。AI Coding Agent は選択肢が増えるほど判断に必要なコンテキストが増え、誤った技術選択や過剰設計を起こしやすくなります。

たとえば「この Web API を Azure へデプロイして」という指示だけでは、AIは毎回次のような候補から判断する必要があります。

App Service / Container Apps / AKS / Functions / VM のどれを使うか
Terraform / Bicep / Pulumi / az CLI のどれで書くか
GitHub Actions / Azure DevOps のどちらでデプロイするか
Public 公開か Private 公開か
Managed Identity か Service Principal か
Application Insights、OpenTelemetry、独自監視をどう組み合わせて観測するか

Platform Engineering 側で、以下のように組織標準を明文化しておくことで、AIの探索空間を大幅に削減できます。

領域	標準
Web/API	原則 Container Apps
Kubernetes 要件あり	AKS
IaC	Terraform
Identity	Managed Identity
Secrets	Key Vault
CI/CD	GitHub Actions
Observability	OpenTelemetry + Application Insights
Production 変更	Approval 必須

Platform Engineering の新しい価値は、機能を増やすことではありません。AIが判断しなければならない分岐を減らすことです。

この標準表は、そのまま AI Coding Agent に読ませるルールファイルに落とし込めます。以下は Claude Code や同種のツールが参照できる Markdown の例です。

platform-standards.md

# Platform 標準（AI Coding Agent 用）

新しいサービスをデプロイする際は、以下の標準に従ってください。
理由があって外れる場合のみ、事前にチームへ確認してください。

| 領域 | 標準 |
|---|---|
| Web/API | Container Apps |
| Kubernetes 要件あり | AKS |
| IaC | Terraform（Bicep / Pulumi は使わない） |
| Identity | Managed Identity |
| Secrets | Key Vault 経由（平文で扱わない） |
| CI/CD | GitHub Actions |
| Observability | OpenTelemetry + Application Insights |
| Production 変更 | Approval 必須（自動デプロイしない） |

AI駆動開発基盤を構成する7つのレイヤー

AI駆動開発基盤は、次の7つのレイヤーで整理できます。

#	レイヤー	構成要素
1	Knowledge	Skills / Rules / ADR / Architecture Guideline / Coding Standard
2	Context	Repository / Docs / API Schema / Service Catalog / 依存情報
3	Patterns	Reference Architecture / Golden Path / Technology Decision
4	Components & Tools	Terraform Module / Template / MCP / CLI / API / SDK
5	Security & Guardrails	RBAC / Policy as Code / Approval / Tool Allowlist / Secret / Network Policy
6	Verification & Evaluation	Test / Lint / SAST / IaC Scan / Eval / Regression / Policy Check
7	Runtime & Observability	Cloud / Kubernetes / Logs / Metrics / Traces / Cost / Audit

ポイントは、これらすべてを1つの巨大な Platform 製品に閉じ込める必要はない、ということです。複数の既存サービスを AIが横断して使えるのであれば、それらを薄く束ねるだけでも Platform として成立します。

Security / Guardrails は「後段のチェック」では足りない

AI Coding Agent がコード生成だけでなく Cloud や本番環境を操作する場合、Security はレビュー工程だけでは不十分になります。AIの権限そのものを設計する必要があります。

領域	考え方	例
Identity	AIごとに実行主体を分離する	Managed Identity / Workload Identity
Authorization	必要最小権限にとどめる	RBAC / Scoped Role
Tool Control	使える Tool を制限する	MCP Allowlist / Command Policy
Production	高リスク操作は人間が承認する	Deployment Approval / HITL
Secrets	AIへ平文の Secret を見せない	Key Vault / Secret Reference
Infrastructure	危険な構成を拒否する	OPA（Gatekeeper など）/ Azure Policy / Policy as Code
LLM	Prompt / Output / Tool 利用を制御する	Content Filter / Tool Guardrail

「AIに Skill で禁止事項を教えたから安全」ではありません。Skill は知識であり、Security Boundary ではありません。本番環境では Policy、Identity、RBAC、Approval など技術的な強制機構が必要です。

Verification は従来の CI より広くなる

AIが生成するのはソースコードだけではありません。IaC、Prompt、Agent Workflow、MCP 設定、Model 設定まで生成対象になるため、Verification も多層化する必要があります。

対象	検証
Application Code	Unit / Integration / E2E / Static Analysis
IaC	terraform validate / plan / IaC Security Scan / Policy Check
Container	Image Scan / SBOM / Dependency Check
Agent	Prompt Eval / Tool Call Eval / Regression Test / Safety Eval
Runtime	Health Check / SLO / Metrics / Logs / Trace
Cost	Token / Model / Infrastructure Cost Regression

AI駆動開発では「生成できること」よりも、生成結果を自動的に検証し、問題があれば AI自身が修正できるループのほうが重要になります。

Platform を厚くしすぎるリスク

AI駆動開発だからといって、Platform を何でも共通化すれば良いわけではありません。独自 Platform は便利な一方で、新しい認知負荷と依存関係を生みます。

Humanitec のような Platform Orchestrator や、Crossplane のような Control Plane は、大規模な標準化には有効です。ただし、少数の異なるプロダクトしか扱わない組織では事情が異なります。Platform 固有の概念を AIと人間の双方が理解するコストが、得られる恩恵を上回る可能性があります。

評価すべきは「抽象化の有無」ではなく差分です。Platform によって減る複雑さが、Platform を導入・学習・保守する複雑さを上回るときにだけ、採用する価値があります。

それでも Platform が強く必要になる4つの領域

大量のサービス・Agent を複数チームで運用する

数十から数百のサービスになると、個別最適による差異が運用コストやセキュリティリスクに直結します。この段階では、Golden Path の強制力が重要になります。

AIへ Cloud の強い権限を直接渡したくない

AIが自由に az や kubectl を実行するより、制限された Platform API のみを公開するほうが安全なケースがあります。この場合、Platform は抽象化のためではなく、Security Boundary として機能します。

マルチクラウドや複数 Runtime の差異を継続的に吸収する

Azure、AWS、GCP、オンプレミスといった差異をアプリケーション側へ出したくない場合、Control Plane や Platform API の価値が高くなります。

強い Governance・Audit が必要

誰が、どの AI が、何を変更したかを一元管理し、Policy、Approval、監査証跡を強制したい場合、Platform 層が有効になります。

「AIに優しい Platform」という新しい評価軸

今後の Platform は、ポータル画面が使いやすいだけでは不十分です。API、Schema、CLI、Policy、Docs、Examples が AIから扱いやすいことが重要になります。

評価軸	問い
Context Efficiency	AIが必要とする説明量をどれだけ減らせるか
Decision Reduction	AIが判断する分岐をどれだけ減らせるか
Machine Readability	API / Schema / CLI / Docs が機械可読か
Verification	誤りを自動検出・修正できるか
Guardrail Strength	危険操作を技術的に拒否できるか
Observability	AIの操作・判断・Tool 利用を追跡できるか
Changeability	モデルや Tool の変化へ追随しやすいか
Low Abstraction Tax	独自概念を増やしすぎていないか

現実的な導入ロードマップ

Phase	名称	整備するもの
Phase 1	AI Enablement	Skills / Rules / Architecture Guideline / Repository Context / Coding Agent
Phase 2	Reusable Engineering Assets	Terraform Modules / CI/CD Templates / MCP / Tools / Reference Architecture
Phase 3	Safety and Quality	RBAC / Policy as Code / Approval / Security Scan / Agent Eval / Observability
Phase 4	Shared AI Platform	LLM Gateway / Model Management / Cost・Token Governance / Shared MCP / Evaluation Platform
Phase 5	Platform / Control Plane	必要になった領域だけ、Self-Service API / Runtime Standardization / Multi-team Governance / Cross-cloud Abstraction

重要なのは、Phase 5 から始めないことです。AI Coding Agent、Skills、既存の CLI、IaC で解決できる問題まで Platform 化すると、初期投資と認知負荷だけが増える可能性があります。

Platform Team の役割も変わる

AI駆動開発では、Platform Team の仕事は単に Developer Portal や Kubernetes 基盤を作ることではなくなります。

従来	AI駆動開発
開発者向けドキュメント	AIが利用できる Skills / Rules / Schema
手順書	Executable Template / IaC / Tool
ポータル	API / MCP / CLI を含む Machine Interface
標準構成の推奨	Golden Path + Policy による制御
CI/CD 整備	生成→検証→修正の自動ループ
運用監視	AI操作・LLM・Tool を含む Observability

Platform Team は「Platform を作るチーム」から、AIと人間が安全かつ高速に開発できる環境を設計するチームへ変わっていきます。

まとめ

AI駆動開発における Platform Engineering の中心課題は、Platform そのものを大きくすることではありません。AIが組織の設計原則を理解し、適切な Tool を使い、少ない探索で正しい実装へ到達し、生成結果を自動検証できる環境を作ることが重要です。

そのためには、いくつかの要素を整備する必要があります。Knowledge、Context、Golden Path、Reusable Components、Security & Guardrails、Verification、Observability です。一方で、Platform Orchestrator や Control Plane が不要になるわけではありません。大量のサービス、強い Governance、Self-Service、Security Boundary、マルチクラウド抽象化など、Runtime レベルで統制すべき課題が生じたときに価値を持ちます。

「Platform を作ること」ではなく、「AIが迷わず、安全に、検証可能な形で開発できる環境を作ること」。これが、AI駆動開発時代の Platform Engineering の中心テーマだと考えています。

参考