プラットフォームエンジニアリングはAI時代の開発者をどう救うのか

SoftBank Tech Night #18で登壇した資料です
https://techplay.jp/event/992449

Transcript

1. プラットフォーム エンジニアリングは AI時代の開発者をどう救うのか
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan 理事 @一般社団法人SREコネクト 代表理事 @一般社団法人クラウドネイティブイノベーターズ協会
3. 90 % 2025年現在、90%の組織が少なくと も1つの内部プラットフォームを採用。 組織の76%が少なくとも 1つの専任プ ラットフォームチームを擁する 出典: 2025 DORA Report: State of AI-Assisted Software Development
4. Platform Engineeringとは この定義に該当するプラットフォームを設計・構築する分野
5. クラウドの登場とDevOps Dev Ops Configure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるよ うにするアプローチ。 このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登 場した
6. 真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行する ただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerfile Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が 高すぎる これをやり切れ る人材は少ない
7. アプリを作っていて思うこと この開発したアプリをAWSに デプロイしないといけないけど･･･ クラウドめんどくさい！ こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア
8. • クラウドやコンテナの知識は持ち合わせている • でも、アプリを書いているときは、頭の中は開発モード • 開発モードからクラウドエンジニアモードに頭を切り替えるのはめ んどくさい • クラウドエンジニアモードから開発モードに戻すのも とてもめんどくさい アプリを作っているときは
9. めんどくさい！
10. • デプロイするためのDockerfile書き、imageづくり • Manifest書き • CI/CDパイプライン作成 • 認証基盤との連携 ◦ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ • ロギング、モニタリングの設定 • セキュリティスキャン • etc… アプリをデプロイしたいだけなのにやるべきことが多い！ みなさんも、めんどくさい 経験ありませんか？
11. めんどくさい！ の表現を専門用語にすると 認知負荷
12. https://www.infoq.com/articles/platform-engineering-primer/ より引用 認知負荷の増大が問題に クラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、 エンジニアの責任範囲の拡大により認知負荷が大変なことに
13. 認知負荷の増大による生産性の低下が 無視出来なくなりつつある
14. じゃあ、どうすればいいのか
15. めんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい
16. めんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい その道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering めちゃくちゃ平たくいうとこんな感じの理解で良いです
17. めんどくさい対策 • 自分で無理に頑張るより、その道のプロにお願いしたい • 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。 適切な情報提供をお願いしたい どうお願いするのか。その任せ方、関わり方 教えを請う？ 手伝って貰う？ それとも･･･
18. Team Topologiesから考える、チームの関わり方 開発チーム その道のプロ 開発チーム その道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を 開いたり、Slackで情報提供 その道のプロが開発チームにジョインし Manifest書くのを担う 開発チーム その道のプロ XaaS その道のプロが用意したプラットフォームの レールの上で開発
19. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安 全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと • 開発者の認知負荷を減らす • セキュリティやコンプライアンスを自然と担保する • 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • 新規サービス生成時に使えるテンプレート • テストやCI/CDパイプラインのセットアップスクリプト • モニタリングやログ収集などの運用機能のガイド
20. 1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションか らはじめる Stream-aligned Teamと1:1になり、クラウド 回りの構築・自動化を行ったり、支援ツールを 作ったりする。 そのStream-alignedが必要とするものを理解し て作れるので、誰得なものを作り込んでしまう ことを防げる 開発チーム その道のプロ Collaboration
21. そのうえで、プラットフォーム(XaaS)を作る コラボレーションモードだと、同時に関われ るStream-aligned Teamは限られる。 ある段階でコラボは終了し、その知見をもと により多くのチームを助けられる疎結合な形 を模索する。それがXaaSモード 開発チーム その道のプロ XaaS
22. が、これまでのPlatform Engineering
23. AIやばい 特にこの1年がやばい コーディングエージェントを使わない開発はあり得な くなってしまった • Claude Code • Codex • Cursor • OpenCode • Antigravity • Kiro • etc..
24. ゴールデンパス ベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安 全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと • 開発者の認知負荷を減らす • セキュリティやコンプライアンスを自然と担保する • 開発チームがビジネス価値の創出に集中できるよう支援する 例えば • 新規サービス生成時に使えるテンプレート • テストやCI/CDパイプラインのセットアップスクリプト • モニタリングやログ収集などの運用機能のガイド
25. それ、AIで出来るよ
26. 抽象化レイヤー • プロビジョニング抽象化 ◦ Terraformモジュールとかサービスカタログとか • ランタイム抽象化 ◦ Kubernetes + tools ◦ Application Platform • デプロイメント抽象化 ◦ CI/CDテンプレート ◦ アプリケーションマニフェストテンプレート • 運用抽象化 ◦ Runbook as code ◦ SLOテンプレート ◦ アラートポリシーセット
27. それ、AIで出来るよ • AI時代だと、面倒なコーディングの多くをAIが代行してくれるため、独自抽 象化レイヤーの需要が減る • むしろ独自の抽象化レイヤーが、AIによる自動生成の妨げになってしまう可 能性も
28. つまり、AI時代において Platform Engineeringは 従来のやり方が通用しなくなってくる
29. 今後起こりうること
30. 開発チームのダウンサイジング • 従来のTwo-pizza ruleが当てはまらなくなる可能性 ◦ 2つのピザを分け合える、7人から8人くらいのチームがいいというやつ • 2，3人による精鋭が、AIを駆使して高速に開発してくほうが効率がいい • 従業員数が変わらなくても構成できるチーム数が増える=多くの開発ができ るようになる ⇨ そうやって登場したたくさんのチームが、AIを活用して好き勝手なスタックで開 発を始めたら・・・？ 短期的には効率が上がるかもしれないが、中長期には大き な技術負債になってしまう可能性が高い。 アーキテクチャの整合性や人材の育成、セキュリティ、インシデント管理いずれの 面においても課題あり
31. フルサービスオーナーシップの普及 • 運用だけを担うチームが成立しづらくなってくる ◦ AIによって高速に、大量に生み出されるアプリケーションを全て引き受けるのは困難 ◦ 単にインシデントをディスパッチするだけの存在になりかねない • 開発した人が運用まで責任を負う、You build it, you run itのスタイルが主流と なっていく • AIの支援を受けながら or AIが主導権を握る形で、少人数でも運用出来るような 仕組みが必要不可欠になる
32. AIの進化が早すぎる問題 • Clineすげえ！ • もうCursorだけあればいい • なんだこれClaude Codeやっば • Devin神では • これからの時代MCP • 着実に開発するならKiroでしょ • Codexすっげぇ • Cursor 2.0で弱点がなくなった • Antigravityやば • MCP辛いけどSkill使えば最強よ • GitHub Copilot結構いいな？ • やっぱClaude Codeよ ↑ここ1年半くらいの気持ちの移り変わり
33. AIの進化が早すぎる問題 結局どうすればええんや問題 AIツールの進化が新たな認知負荷に 個人の趣味ならそれでもいいが、組織とし て取り組むには選択肢がコロコロ変わるこ とは普及の阻害要因になる
34. ガバナンスがより重要に • 悪気なくミスをするAIに備えるため、よりガードレールの重要性が増す • 情報セキュリティや法規制の観点でも、AIを適切にコントロールしてルール を逸脱しないようにする
35. AI時代だからこそ Platform Engineeringが重要
36. Self-ServiceからSelf-Drivingへ • これまでIDPに求められていたのは、Self-Service要素だった ◦ ポータルから必要なものをクリックしてパラメータを入れると セルフサービスでリソースを調達できる ◦ 提供されるテンプレートを元にカスタマイズ ◦ 抽象化により、対象への知識がなくても自身で調達ができるようになる • AIに「ボタンは要らない」 ◦ 多少コードの記述量が多くてもAIは苦にしない ◦ 汎用的な知識は豊富に持ち合わせているため、抽象化を行わなくても スムーズに動ける ◦ むしろ十分なコンテキストが共有されない独自の抽象化のほうがAIにとって難しい ⇨ AI時代に求められるのは、Self-ServiceなPlatformではなく、AIが自ら判断して 自由に動けるSelf-DrivingなPlatform
37. Policy-first Guardrail • AIが自由に動けるようにしたいからこそ、しっかりとしたガードレールを作 る ◦ ガードレールの中であれば好きにやっていいよという形にする • Azure Policy • Open Policy Agent • Sentinel / OPA with HCP Terraform
38. コンテキストの供給 • AIがSelf-Drivingするのに必要なコンテキストを適宜供給、および利用しや すいインターフェースを提供 • たとえばMCP ◦ Azure MCP Server ◦ Terraform MCP Server ◦ etc… • たとえばAgent Skill • 何を提供していくか、Platform Teamが主導してまとめる
39. for 人　から for AI に • 人がカスタマイズするためのテンプレートから、AIが活用するためのテンプ レートへ ◦ AIによるハルシネーション、ポリシー逸脱を防ぐ補助線としてのテンプレート • 人のためのドキュメントから、AIのためのドキュメントへ ◦ AGENTS.mdやCLAUDE.mdのようなAIに指示をだすためのドキュメントの共有・ ナレッジ共有 ◦ とはいえ引き続き人へのドキュメントも重要
40. AI Integrated IDP • Internal Developer PlatformにAIの機能が統合される • MCP Serverを提供するなど。独自の抽象化を取り入れる場合は、セットで提 供すると良い • ただしやり過ぎ注意。あくまでも必要とされる機能から提供していくこと
41. Platform Engineering = AI成功の基盤 • AI採用成熟度が上がるほどPRスループットが向上するというデータ ◦ Medium: 1.58倍 / High: 1.8倍 / Very High: 2.2倍 • IDPはAIツールの選定・コード提案の採否判断を楽にし、採用を加速させる • 注意点: AI採用が進むとPR Revert率（ロールバック）が微増する傾向がある → ガードレールの整備が必要 • Golden Pathに沿った開発はAIトークンの無駄遣い（試行錯誤の繰り返し） を防ぎ、コスト最適化にも寄与する Platform engineering makes a difference. Here's how to prove it https://platformengineering.org/blog/platform-engineering-makes-a-differ ence-here-s-how-to-prove-it
42. DORA AI Capabilities Model
43. Platform Team / Engineerは何をやるのか
45. 人間とAIの棲み分け • Platform as a Productは人間が中心でなければ回らない ◦ 顧客(開発者)が求めているものを吸い上げ、プラットフォームに反映する ◦ AIがレコメンドすることはできるが、信用されるものにはならない ◦ Platform Teamが信用を積み上げていくアクティビティが、今後より重要に
46. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー ここにちゃんとフォーカスすること これを継続的に回せること Platform Engineeringの図
47. 誰に 何を どうやって プラットフォーム の利用者 ◦◦という価値を 技術 ツールチェーン ワークフロー 人間が中心 これを継続的に回せること AI時代だとこうなる AIが中心
48. 社内でAIにもっとも精通した人間になる • 今後AIの要素を一切入れないPlatform Engineeringは存在しなくなる • AI CoEの要素をPlatform Teamが担う ◦ これまでのPlatform EngineeringもCCoEに近い要素があった • アプリケーションの開発からインフラの構築・運用、ガバナンスまですべて の領域においてAIを活用していく選択肢を持つこと。それに必要な情報を追 うこと
49. 今すぐにでもやるべきこと • ChatGPTと会話したことくらいしかありません・・・じゃダメ • AIを活用してアプリケーションの開発からデプロイまで通しでやること ◦ まずは自分でやってみないと感覚がつかめない ◦ 個人的にお勧めはClaude Codeだが、CursorでもCodexでもGemini CLIでも何で もOK ◦ デプロイ先も、AzureでもいいしCloudflareでもVercelでもなんでもいい • 触っているとあれこれ足りないところ、気になるところが見えてくるはず。 じゃあそこをPlatformがどうカバー出来るか考える
51. Platform Engineering史上最大のカンファレンス CloudNative Days × Platform Engineering Kaigi × SRE Kaigi 国内最前線の3大カンファレンスが、名古屋に集結。 2026年 5月14日(木)・15日(金) 中日ホール&カンファレンス 一般参加申し込み受付中！