AI時代だからこそ真価が問われるPlatform Engineering (&本を書きました！という話)
AI時代にPlatform Engineeringは不要！？
こんにちは、PEK2025 Chairのjacopenです！
先日、Gartnerから「日本におけるクラウドとAIのハイプ・サイクル：2025年」が発表されました。それによると、プラットフォームエンジニアリングが幻滅期に入ったということです。
Gartner、「日本におけるクラウドとAIのハイプ・サイクル：2025年」を発表
ハイプ・サイクルとは、新しい技術やトレンドが登場してから社会に定着するまでの過程を、期待値の変化で表したモデルです。
- 黎明期
- 過度な期待のピーク期
- 幻滅期
- 啓発期
- 生産性の安定期
という5つのフェーズに分かれています。最初は注目を集めて期待が高まりますが、やがて現実とのギャップから期待が下がり（幻滅期）、その後、実用的な活用方法が見出されて徐々に定着してく、という流れです。
昨年のハイプ・サイクルにおいて、Platform Engineeringはちょうど過度な期待のピーク期に位置していたので、ついにピークを越えたといえるでしょう。
完全に私見ですが。幻滅期入りした理由はいくつか考えられます。
プラットフォームを作るだけではダメだと気づき始めた
これは自分もずっと言っていることなのですが、プラットフォームエンジニアリングで大事なことはプラットフォームを作ることではありません。それは二の次なのです。
大事なのは開発者が求めるものを理解した上で、素早く、なるべく小さく提供していくことです。そのためには、単に機能を揃えるだけでなく、プロダクトマネジメントの知見も取り入れながら体系的に取り組んでいく必要があります。これは一般的に想像されるよりも大変で、「思ったよりもなんか大変だぞ？」と気づく人が増えてきた可能性があります。
実際やってみると思った通りにはいかなかった
プラットフォームエンジニアリングの話をすると、「認知負荷を下げれば開発者の生産も上がるしガバナンスも向上するし皆ハッピー！」と理想を抱いてしまいがちですが、そうは上手くいかないのが世の常。一つ目に述べたように、本当に役に立つプラットフォームを作っていくには技術だけでなくプロダクトに目を向ける必要がありますし、人間的な関係性を深めて開発者からの信頼を得ていくというコミュニケーション要素も大事です。
技術・プロダクト・コミュニケーション、どれか一つ欠けてもプラットフォームエンジニアリングは上手く行きません。成功のためには、優秀な人材とプラットフォームに対する熱意がなければいけないのです。
頭ではそれを理解していたとしても、実行に移せるかというとまた話は別。欠けたまま取り組んで、結果として上手くいかないというケースが顕在化しているのかもしれません。
AIに全部もっていかれた
個人的に一番大きい理由がこれだと思っています。AIという、全てをひっくり返す存在が登場した。これによって人々の関心が移ってしまったように思います。
これまでのプラットフォームエンジニアリングとは
プラットフォームエンジニアリングのプラクティスとして提唱されたものをいくつか振り返ってみましょう。
ゴールデンパス (Golden Path)
プラットフォームエンジニアリングにおけるゴールデンパスとは、開発者が安全かつ効率的にプロダクト開発を進められるよう、推奨される最適な手順やツール、設定などをあらかじめ整備し、誰もが迷わずに価値提供へ集中できるようにした「成功への道筋」のことです。これにより、複雑な選択や環境構築に悩むことなく、開発者体験を大きく向上させることができます。
抽象化
プラットフォームエンジニアリングにおける抽象化とは、複雑なインフラや運用の詳細を開発者から隠蔽し、よりシンプルで分かりやすいインターフェースやサービスとして提供することを指します。例えば、Kubernetesのようなコンテナオーケストレーション基盤の複雑な設定や運用を、社内向けのセルフサービス型ポータルやCLIツールを通じて簡単に利用できるようにする、といった取り組みが挙げられます。これにより、開発者はインフラの専門知識がなくても、必要なリソースや機能を迅速に利用できるようになり、本来のプロダクト開発に集中できるようになります。
ドキュメンテーション
プラットフォームエンジニアリングにおいては、ドキュメンテーションも重要です。 たとえばプラットフォームの使い方や設計思想、運用ルール、トラブルシューティング方法などを体系的にまとめて記録・共有するといったものです。 これにより、開発者がプラットフォームの機能や利用方法をすぐに理解できるようになり、自己解決力が高まります。また、属人化の防止やナレッジの蓄積にもつながり、組織全体の生産性向上やスムーズなオンボーディングにも寄与します。
さて、これら3点がAI時代になってどうなったか。
そう、それ、全部AIで出来ちゃうんです
AIが置き換えるプラットフォームエンジニアリング
AIが全部やってくれるゴールデンパス
プラットフォームチームが提供するテンプレート、手順やツール。いまだと、AIが自動で良い感じにやってくれます。
Kubernetesのマニフェスト、Terraformのコードといったものを一から自力で書くのはとても大変でしたが、AIに「EKSのクラスタ1つ、ノードはXXのサイズ、クラスタが出来たらArgoCDセットアップして」のように自然文で指示をすれば、95％くらいは正確なものを自動で生成してくれます。その精度は今後さらに上がっていくでしょう。
手順についても迷ったら都度AIに聞けば教えてくれます。つまり、プラットフォームチームに求められていたゴールデンパス作りの多くはAIで代替できてしまうのです。
独自抽象化がAIの妨げに
複雑な手順を開発者から隔離するのが抽象化でしたが、AIによってバンバンコードを生成できる時代においては、多少手順が複雑であったとしても苦痛を感じることなく実行ができる可能性があります。それどころか、AIがあまり知見を持ち合わせていない独自の抽象化を増やしてしまうと、むしろAIによる自動化を妨げてしまう可能性すらあります。過度な抽象化は考え物かもしれません。
ドキュメンテーションはフルオートで
ドキュメントの作成は生成AIの独壇場です。文章を書くのが苦手というエンジニアも多いですが、AIに任せればとても美しい日本語で、分かりやすく文章を書いてくれます。十分なコンテキストを与えておけば、とても分かりやすく、しかも一瞬で整理してドキュメントを生成してくれます。これはとても素晴らしいことですが、これまでのプラットフォームエンジニアの仕事は置き換えられてしまいますね。良いことなんですけどね。
このように、AI時代になり、従来プラットフォームチームに求められたものがごっそりAIに置き換わってしまいました。
今後起こりうる変化
このようなAIの普及によって、今後開発現場にはどのような変化が考えられるのでしょうか。様々な変化が予測されますが、例えば以下のような変化が発生すると考えられます。
開発チームのダウンサイジング
従来、アプリケーション開発では「Two-pizza rule」と呼ばれる、2枚のピザを分け合える程度、つまり7〜8人ほどの少人数チームが最適とされてきました。この人数は「ダンバー数」とも呼ばれ、コミュニケーションロスが少なく、かつ適切に分業できる規模として長らく定説となっていました。
AI時代には、開発チームの最適な人数にも変化が生じる可能性があります。従来は、分業による効率とコミュニケーションコストのバランスから、7〜8人程度が理想とされてきました。なぜなら、人数が増えるほど人間同士のコミュニケーションが増え、時間的なロスが大きくなるためです。
しかし、AIとのやり取りは人間同士のコミュニケーションに比べて圧倒的に速く、効率的です。たとえばChatGPTのようなLLMは、すぐに回答を返してくれるため、コミュニケーションコストが大幅に削減されます。
このため、AIを活用できる少人数のチーム、例えば2〜3人でも十分に高い生産性を発揮できる可能性があります。少人数で開発が回せれば、余った人員で新たなチームを作り、より多くの機能開発に着手することも可能です。結果として、チーム数が増え、開発全体のスピードや幅が広がることが期待できます。
ただし、すべてがうまくいくとは限りません。例えば2〜3人のチームでは、新人が先輩から学ぶ機会が減るなど、人材育成の観点で課題が残る場合もあります。そのため、必ずしも少人数が最適とは言い切れませんが、AIの普及によってチーム構成に変化が生じる可能性は十分にあるでしょう。
フルサービスオーナーシップの普及
前述の通り、チームやアプリケーションの数が増えていくと、従来のように「Dev（開発）」と「Ops（運用）」で分かれ、運用だけを担当するチームを作るのは難しくなってきます。運用チームはアプリケーションの詳細を把握していないことが多く、さらに担当するアプリケーションが増えると、トラブル発生時に適切な対応を取るのが困難になります。その結果、エラーが発生しても開発チームにエスカレーションするだけの存在になりがちです。繰り返しになりますが、生産性を下げる最大の要因は人間同士のコミュニケーションの多さです。単にエスカレーションするだけの役割は、言い換えればコストの無駄になってしまいます。
では、どうすればよいのでしょうか。それは「フルサービスオーナーシップ」という考え方を取り入れることです。かつてAWSのCTOであるWerner Vogels氏は “You build it, you run it”（自分で作ったものは自分で運用する）という考え方を提唱し、開発者がサービスのライフサイクル全体に責任を持つことの重要性を説きました。つまり、開発した人が運用まで一貫して担当するということです。
AI時代はこのようなスタイルを取るチームが増えるでしょう。
ガバナンスがより重要に
AIは悪気なくミスをします。 AIコーディングエージェントがユーザーのホームディレクトリを丸ごと削除してしまうというトラブルがSNS上でも話題となったように思いもよらない行動を起こすことがしばしばあります。 開発者のローカル環境であればまだ良いのですが、それが本番環境でも起こってしまったとすると大変です。 大きなインシデントとならないように、よりしっかりとしたガードレールを構築することが重要となります。
情報セキュリティや法規制の観点でも、AIを適切にコントロールすることが重要となってくるでしょうか。
AI時代だからこそ必要になるプラットフォームエンジニアリング
さて、このような大きな変化を迎える中で、プラットフォームエンジニアリングはどうなっていくのでしょうか。AIでごっそり置き換わることで不要になるのでしょうか。自分はそうは思いません。
むしろ、AI時代だからこそ、プラットフォームエンジニアリングが重要になると考えています。
繰り返しとなってしまいますが、プラットフォームエンジニアリングの本質は何か。それはプラットフォームを作ることではなく、認知負荷を下げ、開発者体験を向上させるという点にあります。 これまでは独自の抽象化でそれを実現していましたが、別にAIにとって変わっても良いわけです。
もしAIが開発者体験に大きく寄与するのであれば、プラットフォームチームはより良いAIを提供していく役割に変化していくということになります。 つまりこれからのプラットフォームエンジニアは 社内で最もAIに精通し、全社に普及させる役割を担う 必要があります。
Self-ServiceからSelf-Drivingへ
これまでInternal Developer Platformに求められてきたのは、Self-Serviceの仕組みでした。たとえば、開発者がポータル画面から必要なリソースをクリック操作とパラメータ入力だけで簡単に調達できる、といったものです。プラットフォームチームが用意したテンプレートを使い、カスタマイズしながらIaCを導入できることで、認知負荷を下げる工夫もされてきました。また、独自の抽象化によって、専門知識がなくても開発者自身でリソースを用意できるようになっていました。
しかし、AIにとってはこうした「ボタン」や「抽象化」は必ずしも必要ありません。多少コードの記述量が増えてもAIは苦にしませんし、一般的な技術知識も豊富に持っています。そのため、特別な抽象化がなくてもスムーズに作業できます。むしろ、十分なコンテキストが共有されていない独自の抽象化の方が、AIにとっては理解しづらくなる場合もあります。
AI時代に求められるのは、従来のSelf-Serviceなプラットフォームではありません。これからは、AIが自律的に判断し、自由に動けるSelf-Driving(自動運転)を支援するプラットフォームが重要となります。
自動運転の車については、皆さんもご存知かと思います。現在、さまざまな企業が開発を進めている分野です。
自動運転には「レベル分け」があり、たとえばレベル2はアクセルやブレーキの操作が自動化されているものの、運転者が常にハンドルを握っていなければなりません。レベル3になると、緊急時を除いて運転操作が自動化されます。そしてレベル4では、基本的に運転者の介入が不要になります。
多くのメーカーはレベル3までの自動運転を実現していますが、レベル4以上を本格的に実現できているメーカーはまだ少数です。その理由は、実際の道路にはさまざまな予期せぬ状況が発生するためです。たとえば、道路標識が消えかかっていたり、裏返っていたりすることもありますし、突然歩行者が飛び出してくることもあります。こうしたイレギュラーな事態に対応できる車を作るのは非常に難しいのです。
一方で、道路のように自由に変えられない環境とは異なり、プラットフォームは自分たちの手で柔軟に変化させることができます。自動運転のための目印やセンサー、さまざまな情報を用意することで、AIがより正確に判断しやすい環境を整えることが可能です。つまり、こうした環境を整備するのがプラットフォームチームの役割なのです。
Policy-first Guardrail
AIを安全かつ効果的に活用するためには、「ガードレール」 を作ることが不可欠です。
「ガードレール」と聞くと、AIの動作を制限する窮屈なものだと考えてしまうかもしれません。しかし、それは誤解です。むしろ、AIをもっと自由に、安心して動かせるようにするためにガードレールは存在します。
例えるなら、車での山道走行です。もしガードレールがなく、すぐ横が崖だったらどうでしょうか？怖くてスピードを出すことはできず、目的地まで恐る恐る進むしかありません。しかし、そこに頑丈なガードレールがあれば、万が一の時も安心です。自信を持って運転に集中でき、結果として安全かつスピーディーに目的地にたどり着くことができます。
AIやクラウド利用におけるガードレールもこれと同じで、不適切な操作や意図しない構成といった事態を未然に防ぎ、開発者や利用者が安心してその能力を最大限に引き出すための安全装置なのです。
主要なクラウドサービスは既にこのようなガードレールの機能を提供しています。AWSであればService Control PoliciesやIAM Policy、AzureであればAzure Policy、Google CloudであればOrganization Policy Serviceといった具合です。
Kubernetesの分野では、ポリシーベースの制御を実現するためにOpen Policy Agent（OPA）が広く利用されています。OPAはKubernetesのAdmission Controllerとして組み込むことで、Regoという独自言語で柔軟なポリシーを記述し、リソースの作成・更新時にセキュリティや運用ルールを強制できます。さらに、Gatekeeperという拡張プロジェクトを利用することで、Kubernetesクラスター全体に対して一元的なポリシー管理や監査も可能となります。
Terraformであれば、HashiCorp社のHCP Terraformを利用することで、SentinelもしくはOPAでポリシーを記述することができます。
このように、各社が提供するポリシーベースのガードレールを整備することで、ガバナンスを効かせながら、安全かつ効率的にAI活用を進めることができるようになります。
プラットフォームエンジニアリングの神髄は、AIにはマネが出来ない
以前から存在した、いわゆる「共通基盤」の取り組みとプラットフォームエンジニアリングは何が異なるのか。もっとも大きな違いは、「プロダクトマインドセットがあるかど うか」です。
Platform as a Productの重要性
かつて多くの大企業で「共通基盤」と呼ばれる取り組みが行われてきましたが、効率化を目指して導入されたはずの基盤が、実際には使われずに消えていく。そんな失敗例が後を絶ちませんでした。
この反省を踏まえ、プラットフォームエンジニアリングでは「Platform as a Product」という考え方が生まれました。これは、プラットフォームの利用者を「顧客」として捉え、顧客が本当に必要とする価値をプロダクトとして提供するというアプローチです。SaaSビジネスのように、顧客のニーズを的確に捉え、求められていないものは作らない。これが成功の鍵となります。
そのためには、顧客がどんな課題（ペイン）を抱えているのかを深く理解し、ニーズを引き出したうえで、優先順位をつけて機能を実装していく必要があります。こうした一連の流れが、まさにプロダクトマネジメントの実践です。
AI時代では、プラットフォームチームがMCPやAIエージェントをまとめたり提供したりといった取り組みが必要となります。それも同様で、顧客に求められていないAIエージェントを作っても意味がありません。また、外部のMCPを持ち込むにも、無闇にもってくるのではなく本当に重要なものにフォーカスして取り込んでいくことが重要です。この際にも、Platform as a Productのアプローチが重要となります。
信頼を築くということ
プラットフォームを多くの人に使ってもらうためには、「信頼」が不可欠です。技術力だけでなく、運用チームや担当者との人間的なつながりも含めて、「あのチームなら安心して任せられる」と思ってもらえることが大切です。
信頼は一朝一夕には築けません。顧客の期待に応え続けることはもちろん、継続的な運用と改善を怠らず、長く寄り添い続けることが重要です。最初は物足りなくても、地道な積み重ねによって「居心地のよいプラットフォーム」と認識されれば、自然と利用が広がっていきます。
AIには難しい、人間ならではの価値
顧客の本音を引き出したり、信頼関係を築いたりすることは、現時点ではAIには難しい領域です。AIは入力されたデータからしか判断できませんが、顧客の本当のニーズは、何気ない会話や雑談、飲み会の場など、データ化されないところから生まれることも多いものです。
また、どれだけAIが進化しても、「信頼している人からのひとこと」には敵いません。人間同士の信頼関係は、理屈や情報量だけでは築けない、本能的なものだからです。
今後、共通基盤としての機能や便利なサービスはAIに置き換えられていくかもしれません。しかし、「Platform as a Product」や「信頼の醸成」といった、人間ならではの価値は、AI時代にこそより重要になっていくのです。
･･･という内容の本を、書きました！
AI x Platform Engineeringに関しては、語っても語りきれないほどです。なので、有志で本を書きました。
その名も AI Native Platform Engineering です！
- jacopen
- もりはや
- ハリネズミ
- れにゃ
の4名で執筆しています。
- 第1章 AI 時代におけるプラットフォームエンジニアリング
- 第2章 書籍『Team Topologies』から再考するAI ネイティブなPlatform Engineering
- 第3章 Platform Engineering とAI Agent
- 第4章 AI エージェントプラットフォームの構築- ガードレールとツール統合
本書は、明日9/18開催の Platform Engineering Kaigi 2025の会場で頒布を行います！
この機会を逃すと、次に入手できるのは数ヶ月後だったりします。
是非会場にお越し頂き、お手にとって頂ければ嬉しいです。
キーノートも AIxPE
そしてPlatform Engineering Kaigi 2025の目玉であるキーノート。ご登壇いただくNicki Wattさんも、次のタイトルでお話いただきます。
Engineering Tomorrow’s Platforms: Staying Relevant in the Age of AI
As AI continues to evolve at an unprecedented pace—sparking excitement, disruption, and even existential questions about the future of software engineering—what does it take to build a platform that truly stands the test of time? In this keynote, we’ll explore what it takes to design and operate platforms that not only deliver tangible value today but also remain adaptable and resilient in a rapidly changing landscape. Drawing on real-world experiences and lessons learned, we’ll examine what makes a platform great—from developer experience to maintainability and scalability. Most importantly, we’ll ask: how can we ensure the platforms we build today continue to empower engineers—not replace them—in the years to come?
AIが前例のないペースで進化を続ける中で、興奮、破壊的変化、そしてソフトウェアエンジニアリングの未来についての実存的な問いさえも引き起こしています。—真に時代の試練に耐えうるプラットフォームを構築するには何が必要でしょうか？この基調講演では、今日において具体的な価値を提供するだけでなく、急速に変化する環境においても適応性と回復力を保ち続けるプラットフォームを設計・運用するために必要なことを探求します。実世界での経験と学んだ教訓を基に、開発者体験から保守性、スケーラビリティまで、優れたプラットフォームを作る要素を検証します。そして最も重要なことは、今日構築するプラットフォームが、これからの年月においてエンジニアを置き換えるのではなく、エンジニアに力を与え続けることをどのように保証できるか、という問いかけです。
まさに！といった講演内容で、とても楽しみです。
さあ、そんなPlatform Engineering Kaigi 2025は9/18開催です！ お申し込み期限まであと少し。この機会をお見逃し無く！