7月6日、Pankaj Gupta（VMware by Broadcom シニアディレクター）が「Evolving platform engineering for AI-native workloads」と題した記事を公開した。AIネイティブなワークロードへの対応を迫られるなか、既存のプラットフォームエンジニアリングの前提が根本から崩れつつあるという問題意識のもと、「Platform Engineering 2.0」という枠組みで進化の方向性を整理した論考だ。
Platform Engineering 1.0 の何が足りないか
ゴールデンパス、IDP（Internal Developer Platform）、セルフサービスインフラ、シフトレフトセキュリティ——Platform Engineering 1.0 が提供した価値は本物だ。多くの組織はいまもこの段階にある。
しかし、AIの急速な普及が既存のプラットフォーム設計の前提を崩しつつある。Guptaは現在のプラットフォームチームが直面する課題を5つに整理している。
- AIコーディング支援による開発加速：コード生成速度が上がるにつれ、ソフトウェアデリバリーパイプライン自体がボトルネックになりつつある
- エージェント化の進行：アプリケーションに自律型AIエージェントが組み込まれ始めている。既存のプラットフォームはGPUプロビジョニング、モデルライフサイクル管理、MCP（Model Context Protocol）統合を前提に設計されていない（※MCPについては後述）
- データ主権とコンプライアンス：データレジデンシー規制や継続的コンプライアンス要求は後付けでは対応できない
- マルチペルソナ化：MLエンジニア、データサイエンティスト、FinOps担当者、さらにAIエージェント自体がプラットフォームの利用者になっている
- FinOpsの現実：AIインフラ特有の消費パターンにより、クラウドコスト管理の重要性が増している
5つの柱で定義する「Platform Engineering 2.0」
Guptaが提示する Platform Engineering 2.0 のコア原則（Platform as Product、開発者生産性、ゴールデンパス、シフトレフトセキュリティ）は 1.0 から変わらない。変わるのは「誰に」「何を」「どう」提供するかだ。その進化を5つの柱で整理している。
1. AIネイティブプラットフォーム
GPU/TPU割り当て、モデルサービング、MCPゲートウェイ、エージェント向けガードレールをファーストクラスでサポートする。AIシステム自体がプラットフォームのコンシューマーになる以上、人間ユーザーと同様のアクセス制御とガバナンスが必要になる。
※ MCP（Model Context Protocol）とは、AIエージェントが外部ツールやデータソースと標準化された方法でやり取りするためのプロトコルだ。Anthropicが提唱し、エージェントとプラットフォームの統合において急速に普及しつつある。プラットフォームが「MCPゲートウェイ」を提供することで、エージェントが安全かつ一貫した形で内部APIやデータにアクセスできる構造を実現する。
2. マルチペルソナ対応
開発者とプラットフォームエンジニアだけを対象にしていた 1.0 から拡張し、以下に対応する：
- データサイエンティスト・MLエンジニア：セルフサービスGPUプロビジョニング、モデルレジストリ、実験トラッキング
- エンジニアリング・ビジネスリーダー：リアルタイムのFinOpsダッシュボードとDORAメトリクス
- セキュリティ・コンプライアンスチーム：Policy-as-Codeによる自動強制
- AIエージェント：非人間コンシューマーとして独自のアクセス権限とガバナンスを付与
3. 埋め込みFinOps
コスト管理を事後のレポートからプロビジョニング時の意思決定へ移行する。リアルタイムのコスト帰属情報とデプロイ前のコストゲートにより、開発者・運用者が日常的にコストを意識した判断を下せる構造にする。
4. セキュリティの「さらなる左シフト」
シフトレフトを補完しつつ、プラットフォームとランタイム層にセキュリティを埋め込む。AI固有の攻撃ベクタ——シャドーAIの乱立、プロンプトインジェクション、モデルポイズニング、推論データの漏洩——にはモデルレジストリのガバナンス、データ分離、プロンプトセキュリティ、推論監査で対処する。
5. コンポーザブル設計
プラットフォーム機能をモジュール化し、APIファーストの独立デプロイ可能なビルディングブロックとして提供する。CNCFランドスケープの200以上のプロジェクト（graduated / incubating / sandbox）が、このコンポーザビリティを支えるエコシステムとして機能する。あるCNCFツールを同等機能の別ツールに差し替えても、連鎖的な変更が発生しない構造が目標だ。
インフラは「配管」ではなく戦略レイヤー
Guptaが強調するのは、インフラを運用上の後付けではなく戦略的優先事項として扱うことだ。静的・人間ペースのプロビジョニングから、AIネイティブで動的な基盤への移行が Platform Engineering 2.0 の前提になる。
この移行は一足飛びには実現しない。Guptaは段階的なアプローチを念頭に置いており、まず現行プラットフォームのAIワークロード対応状況をペルソナ別に棚卸しし、コスト帰属・セキュリティポリシー・エージェントアクセス制御の各領域でギャップを特定することが出発点になると示唆している。その上でコンポーザブルな設計への移行を段階的に進め、各ステップでDORAメトリクスやFinOpsダッシュボードを指標として活用することで、投資対効果を可視化しながら前進できると論じている。
成熟度モデルと CNCF の役割
Platform Engineering 1.0 の成熟度モデルはCNCFが公式ホワイトペーパーとして整備した。2.0 への移行も段階的な旅であり、CNCF Platform Engineering Technical Community Group がすでに次のフェーズに向けた議論を進めている。
同コミュニティグループの共同オーガナイザーを務めるAtulpriya Sharmaはこう述べている。
「開発者生産性の機能として始まったものが、いまやコスト規律・セキュリティ姿勢・AI対応をすべてのチームに横断的に強制する、エンタープライズの中央ガバナンスレイヤーになった。その広さを構造的負債なく吸収できるプラットフォームは、固定アーキテクチャではなく、最初からコンポーザブルに設計されたものだ。」
なお、本記事タイトルおよび本文中で用いている「Platform Engineering 1.0 / 2.0」という表記は、元記事の議論の流れを整理する目的でTechFeed編集部が便宜的に付したフレーミングであり、元記事が明示的にこの用語を定義しているわけではない点をお断りしておく。
詳細はEvolving platform engineering for AI-native workloadsを参照していただきたい。
