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

by Kazuto Kusama

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan 理事 @一般社団法人SREコネクト代表理事 @一般社団法人クラウドネイティブイノベーターズ協会

Slide 3

Slide 3 text

90 % 2025年現在、90%の組織が少なくとも1つの内部プラットフォームを採用。組織の76%が少なくとも 1つの専任プラットフォームチームを擁する出典: 2025 DORA Report: State of AI-Assisted Software Development

Slide 4

Slide 4 text

Platform Engineeringとはこの定義に該当するプラットフォームを設計・構築する分野

Slide 5

Slide 5 text

クラウドの登場とDevOps Dev Ops Conﬁgure Verify Package Plan Monitor Release Create Plan DevとOpsの垣根をなくし、ソフトウェアの開発とデリバリーを継続して行えるようにするアプローチ。このプロセスの中にセキュリティ対策を組み込むDevSecOpsというパターンも登場した

Slide 6

Slide 6 text

真のDevOps 開発者が、アプリをエンドツーエンドでデプロイし、実行するただし、多くの組織にとって現実的ではない Kubernetes Buildkit Helm Dockerﬁle Grafana Prometheus GitHub Actions React Next.js Security Node.js Terraform ArgoCD APM Compliance 認知負荷が高すぎるこれをやり切れる人材は少ない

Slide 7

Slide 7 text

アプリを作っていて思うことこの開発したアプリをAWSにデプロイしないといけないけど･･･クラウドめんどくさい！こんな作業やりたくない！ ▲ 一応クラウド系のエンジニア

Slide 8

Slide 8 text

● クラウドやコンテナの知識は持ち合わせている ● でも、アプリを書いているときは、頭の中は開発モード ● 開発モードからクラウドエンジニアモードに頭を切り替えるのはめんどくさい ● クラウドエンジニアモードから開発モードに戻すのもとてもめんどくさいアプリを作っているときは

Slide 9

Slide 9 text

めんどくさい！

Slide 10

Slide 10 text

● デプロイするためのDockerﬁle書き、imageづくり ● Manifest書き ● CI/CDパイプライン作成 ● 認証基盤との連携 ○ OIDCのフローとか何回勉強しても忘れちゃうんだけど･･･ ● ロギング、モニタリングの設定 ● セキュリティスキャン ● etc… アプリをデプロイしたいだけなのにやるべきことが多い！みなさんも、めんどくさい経験ありませんか？

Slide 11

Slide 11 text

めんどくさい！の表現を専門用語にすると認知負荷

Slide 12

Slide 12 text

https://www.infoq.com/articles/platform-engineering-primer/ より引用認知負荷の増大が問題にクラウドの浸透、クラウドネイティブ技術の登場、マイクロサービス化の流れ、エンジニアの責任範囲の拡大により認知負荷が大変なことに

Slide 13

Slide 13 text

認知負荷の増大による生産性の低下が無視出来なくなりつつある

Slide 14

Slide 14 text

じゃあ、どうすればいいのか

Slide 15

Slide 15 text

めんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたい

Slide 16

Slide 16 text

めんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいその道のプロ = Platform Team その道のプロを体系だって作っていく取り組み = Platform Engineering めちゃくちゃ平たくいうとこんな感じの理解で良いです

Slide 17

Slide 17 text

めんどくさい対策 ● 自分で無理に頑張るより、その道のプロにお願いしたい ● 全部任せたいけど、難しい場合はせめて相談に乗って欲しい。適切な情報提供をお願いしたいどうお願いするのか。その任せ方、関わり方教えを請う？手伝って貰う？それとも･･･

Slide 18

Slide 18 text

Team Topologiesから考える、チームの関わり方開発チームその道のプロ開発チームその道のプロ Collaboration Facilitating その道のプロが開発チームに勉強会を開いたり、Slackで情報提供その道のプロが開発チームにジョインし Manifest書くのを担う開発チームその道のプロ XaaS その道のプロが用意したプラットフォームのレールの上で開発

Slide 19

Slide 19 text

ゴールデンパスベストプラクティスや標準化されたプロセスにより、開発チームが迷わず素早く安全にアプリケーションを開発・運用できるようにした一連のルートや仕組みのこと ● 開発者の認知負荷を減らす ● セキュリティやコンプライアンスを自然と担保する ● 開発チームがビジネス価値の創出に集中できるよう支援する例えば ● 新規サービス生成時に使えるテンプレート ● テストやCI/CDパイプラインのセットアップスクリプト ● モニタリングやログ収集などの運用機能のガイド

Slide 20

Slide 20 text

1:1で、コラボレーションをする Platform Teamは、まずはコラボレーションからはじめる Stream-aligned Teamと1:1になり、クラウド回りの構築・自動化を行ったり、支援ツールを作ったりする。そのStream-alignedが必要とするものを理解して作れるので、誰得なものを作り込んでしまうことを防げる開発チームその道のプロ Collaboration

Slide 21

Slide 21 text

そのうえで、プラットフォーム(XaaS)を作るコラボレーションモードだと、同時に関われるStream-aligned Teamは限られる。ある段階でコラボは終了し、その知見をもとにより多くのチームを助けられる疎結合な形を模索する。それがXaaSモード開発チームその道のプロ XaaS

Slide 22

Slide 22 text

が、これまでのPlatform Engineering

Slide 23

Slide 23 text

AIやばい特にこの1年がやばいコーディングエージェントを使わない開発はあり得なくなってしまった ● Claude Code ● Codex ● Cursor ● OpenCode ● Antigravity ● Kiro ● etc..

Slide 24

Slide 24 text

Slide 25

Slide 25 text

それ、AIで出来るよ

Slide 26

Slide 26 text

抽象化レイヤー ● プロビジョニング抽象化 ○ Terraformモジュールとかサービスカタログとか ● ランタイム抽象化 ○ Kubernetes + tools ○ Application Platform ● デプロイメント抽象化 ○ CI/CDテンプレート ○ アプリケーションマニフェストテンプレート ● 運用抽象化 ○ Runbook as code ○ SLOテンプレート ○ アラートポリシーセット

Slide 27

Slide 27 text

それ、AIで出来るよ ● AI時代だと、面倒なコーディングの多くをAIが代行してくれるため、独自抽象化レイヤーの需要が減る ● むしろ独自の抽象化レイヤーが、AIによる自動生成の妨げになってしまう可能性も

Slide 28

Slide 28 text

つまり、AI時代において Platform Engineeringは従来のやり方が通用しなくなってくる

Slide 29

Slide 29 text

今後起こりうること

Slide 30

Slide 30 text

開発チームのダウンサイジング ● 従来のTwo-pizza ruleが当てはまらなくなる可能性 ○ 2つのピザを分け合える、7人から8人くらいのチームがいいというやつ ● 2，3人による精鋭が、AIを駆使して高速に開発してくほうが効率がいい ● 従業員数が変わらなくても構成できるチーム数が増える=多くの開発ができるようになる ⇨ そうやって登場したたくさんのチームが、AIを活用して好き勝手なスタックで開発を始めたら・・・？短期的には効率が上がるかもしれないが、中長期には大きな技術負債になってしまう可能性が高い。アーキテクチャの整合性や人材の育成、セキュリティ、インシデント管理いずれの面においても課題あり

Slide 31

Slide 31 text

フルサービスオーナーシップの普及 ● 運用だけを担うチームが成立しづらくなってくる ○ AIによって高速に、大量に生み出されるアプリケーションを全て引き受けるのは困難 ○ 単にインシデントをディスパッチするだけの存在になりかねない ● 開発した人が運用まで責任を負う、You build it, you run itのスタイルが主流となっていく ● AIの支援を受けながら or AIが主導権を握る形で、少人数でも運用出来るような仕組みが必要不可欠になる

Slide 32

Slide 32 text

AIの進化が早すぎる問題 ● Clineすげえ！ ● もうCursorだけあればいい ● なんだこれClaude Codeやっば ● Devin神では ● これからの時代MCP ● 着実に開発するならKiroでしょ ● Codexすっげぇ ● Cursor 2.0で弱点がなくなった ● Antigravityやば ● MCP辛いけどSkill使えば最強よ ● GitHub Copilot結構いいな？ ● やっぱClaude Codeよ ↑ここ1年半くらいの気持ちの移り変わり

Slide 33

Slide 33 text

AIの進化が早すぎる問題結局どうすればええんや問題 AIツールの進化が新たな認知負荷に個人の趣味ならそれでもいいが、組織として取り組むには選択肢がコロコロ変わることは普及の阻害要因になる

Slide 34

Slide 34 text

ガバナンスがより重要に ● 悪気なくミスをするAIに備えるため、よりガードレールの重要性が増す ● 情報セキュリティや法規制の観点でも、AIを適切にコントロールしてルールを逸脱しないようにする

Slide 35

Slide 35 text

AI時代だからこそ Platform Engineeringが重要

Slide 36

Slide 36 text

Self-ServiceからSelf-Drivingへ ● これまでIDPに求められていたのは、Self-Service要素だった ○ ポータルから必要なものをクリックしてパラメータを入れるとセルフサービスでリソースを調達できる ○ 提供されるテンプレートを元にカスタマイズ ○ 抽象化により、対象への知識がなくても自身で調達ができるようになる ● AIに「ボタンは要らない」 ○ 多少コードの記述量が多くてもAIは苦にしない ○ 汎用的な知識は豊富に持ち合わせているため、抽象化を行わなくてもスムーズに動ける ○ むしろ十分なコンテキストが共有されない独自の抽象化のほうがAIにとって難しい ⇨ AI時代に求められるのは、Self-ServiceなPlatformではなく、AIが自ら判断して自由に動けるSelf-DrivingなPlatform

Slide 37

Slide 37 text

Policy-ﬁrst Guardrail ● AIが自由に動けるようにしたいからこそ、しっかりとしたガードレールを作る ○ ガードレールの中であれば好きにやっていいよという形にする ● Azure Policy ● Open Policy Agent ● Sentinel / OPA with HCP Terraform

Slide 38

Slide 38 text

コンテキストの供給 ● AIがSelf-Drivingするのに必要なコンテキストを適宜供給、および利用しやすいインターフェースを提供 ● たとえばMCP ○ Azure MCP Server ○ Terraform MCP Server ○ etc… ● たとえばAgent Skill ● 何を提供していくか、Platform Teamが主導してまとめる

Slide 39

Slide 39 text

for 人　から for AI に ● 人がカスタマイズするためのテンプレートから、AIが活用するためのテンプレートへ ○ AIによるハルシネーション、ポリシー逸脱を防ぐ補助線としてのテンプレート ● 人のためのドキュメントから、AIのためのドキュメントへ ○ AGENTS.mdやCLAUDE.mdのようなAIに指示をだすためのドキュメントの共有・ナレッジ共有 ○ とはいえ引き続き人へのドキュメントも重要

Slide 40

Slide 40 text

AI Integrated IDP ● Internal Developer PlatformにAIの機能が統合される ● MCP Serverを提供するなど。独自の抽象化を取り入れる場合は、セットで提供すると良い ● ただしやり過ぎ注意。あくまでも必要とされる機能から提供していくこと

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

DORA AI Capabilities Model

Slide 43

Slide 43 text

Platform Team / Engineerは何をやるのか

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

人間とAIの棲み分け ● Platform as a Productは人間が中心でなければ回らない ○ 顧客(開発者)が求めているものを吸い上げ、プラットフォームに反映する ○ AIがレコメンドすることはできるが、信用されるものにはならない ○ Platform Teamが信用を積み上げていくアクティビティが、今後より重要に

Slide 46

Slide 46 text

誰に何をどうやってプラットフォームの利用者 ○○という価値を技術ツールチェーンワークフローここにちゃんとフォーカスすることこれを継続的に回せること Platform Engineeringの図

Slide 47

Slide 47 text

誰に何をどうやってプラットフォームの利用者 ○○という価値を技術ツールチェーンワークフロー人間が中心これを継続的に回せること AI時代だとこうなる AIが中心

Slide 48

Slide 48 text

社内でAIにもっとも精通した人間になる ● 今後AIの要素を一切入れないPlatform Engineeringは存在しなくなる ● AI CoEの要素をPlatform Teamが担う ○ これまでのPlatform EngineeringもCCoEに近い要素があった ● アプリケーションの開発からインフラの構築・運用、ガバナンスまですべての領域においてAIを活用していく選択肢を持つこと。それに必要な情報を追うこと

Slide 49

Slide 49 text

今すぐにでもやるべきこと ● ChatGPTと会話したことくらいしかありません・・・じゃダメ ● AIを活用してアプリケーションの開発からデプロイまで通しでやること ○ まずは自分でやってみないと感覚がつかめない ○ 個人的にお勧めはClaude Codeだが、CursorでもCodexでもGemini CLIでも何でもOK ○ デプロイ先も、AzureでもいいしCloudﬂareでもVercelでもなんでもいい ● 触っているとあれこれ足りないところ、気になるところが見えてくるはず。じゃあそこをPlatformがどうカバー出来るか考える

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Platform Engineering史上最大のカンファレンス CloudNative Days × Platform Engineering Kaigi × SRE Kaigi 国内最前線の3大カンファレンスが、名古屋に集結。 2026年 5月14日(木)・15日(金) 中日ホール&カンファレンス一般参加申し込み受付中！