要点
- 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 標準（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 の中心テーマだと考えています。