はじめに

先日、Platform Engineering Kaigi(PEK) 2025へ行ってきた。

今回はその参加レポートを書いていく。

普段の業務ではSREチームに所属しているが、Platform Engineeringにも関心があり今回で色々事例を知ろうとして参加。

ちなみに、SREとPlatform Engineeringの違いはざっとこんな感じ。

• SRE: システムの信頼性、可用性を担保
• Platform Engineering: 開発者の開発効率を上げるプラットフォームを提供

より開発者の開発体験を向上させるという点にフォーカスしている。

会場の様子

会場は中野セントラルパークカンファレンス。大きい会場だった。SRE Kaigiぶりの参加かな。

スポンサーさんのブースも色々あり、スタンプラリーで10枚シールを集めると景品ゲットできるとのことで10ブース回ってみた。

いろいろなブースの方たちと話せて楽しかったし、勉強になった。

書籍販売のコーナーもあり、今回の同人販売で新刊として販売されていた「AI NATIVE PLATFORM ENGINEERING」とまだ買えてなかった「SREの知識地図」を買った。

これから読むのが楽しみ。

NOC部屋、わいわい見学お待ちしております #PEK2025
場所は受付曲がって右手奥のほうの部屋です！！ pic.twitter.com/bHPaiXtQNa

— Platform Engineering Kaigi / クラウドネイティブイノベーターズ協会 (@cnia_pfem) September 18, 2025

会場のWi-Fiを構築したNOCの部屋もあった。

Kubernetesで動いていてたり、なかなかリッチな構成だった。

お弁当ありがたい！！#PEK2025 pic.twitter.com/AkbdknRATH

— こうじゅん@SRE (@kouzyunJa) September 18, 2025

ランチセッションではお弁当が配られていて、なかなかありがたかった。

ローストビーフサンド美味しかった。

参加したセッション

ここからは参加したセッションについていくつか書いていく。

キーノート「Engineering Tomorrow’s Platforms: Staying Relevant in the Age of AI」

Trifork UKにてCTO兼Business Unit LeadをされているNickiさんのキーノート。

AI時代においてプラットフォームの未来はどうあるべきかという内容だった。

Platform Engineering Maturity Model (PEMM)

PEMMとはCNCFが出しているプラットフォームエンジニアリングの成熟度モデルのこと。

Maturity Model Matrixで自分たちの組織でどれだけPlatform Engineeringが浸透しているかを測ることができる。

まずは、このような指標で自分たちの組織がどれくらい成熟しているのか現在地を知ることが大事だという。

Platformのあるべき姿

Platformのあるべき姿として3つの柱を強調されていた。

1. Platform as a Product
   • 開発者をユーザと見立て、ユーザ体験を重視する
   • リクエストや不満をAIが先読みし、リアルタイムでサポート

2. Reliability（信頼性）
   • ポリシー、Runbook、ゴールデンパスを提供
   • ダッシュボードやAPMで問題を可視化し、自然言語で調査可能（例: Datadog Bits AI）
   • 過剰なIAMポリシーの利用は避け、プラットフォーム側でガイドする

3. Self-Service（セルフサービス）
   • 開発者が自分で使えるポータルを提供
   • 自然言語で質問・操作可能
   • CLIショートカットやオンボーディング支援、ドキュメント検索

ユーザのリクエストや不満を拾う方法を「明に・暗に」という言い方で話されていたのは印象的だった。

• 明示的: アンケートなどで直接ヒアリング
• 暗黙的: チャットの質問履歴や利用メトリクスからAIで抽出

チャットの履歴からどこに不満やストレスがあるのかを探ることができる暗のアプローチは個人的に新鮮だった。

AIの3つのインパクト

AIが普及していくことで3つの観点でPlatformに変化がある。

1. Supporting Platform Consumers（利用者支援）
   • 自然言語インターフェースで利用を容易にする
     
2. Empowering Platform Builders（構築者支援）
   • AI Coding Assistantでプラットフォームを「製品」として構築可能
   • ドキュメントやADR（Architecture Decision Records）の自動生成
   • トラブルシューティングやポストモーテムをAI Opsで支援
   • 例: kubectl-ai, k8sgpt, kagent, Claude Code

3. Democratizing AI Native Offerings（AI文化の浸透）
   • AIの普及と文化形成
   • 安心して利用できるガードレールの提供（Guarded AI）

いろんなインターフェイスが自然言語で扱えるようになるのはこの先当たり前になっていくのかな。

一人SREが歩んだ Platform Engineering スモールスタートアップ実践論

Platform Engineeringの必要性に気づき、その実践をスモールチームでされている話のセッション。

Platform EngineeringとSREの2つにある交差点

• Platform Engineering: ストリームアラインドチームを支援する方向を向いている
• SRE: プロダクトの信頼性を担保する方向を向いている
• 共通点: 「トイルをなくす」という名目でどちらも重なる部分が多い

「開発者の生産性を下げるトイル」、「信頼性を脅かすトイル」というトイルの名目で両者の間に重なりがあるとのこと。

Platform Engineeringの視点と思考

SREの信頼性を担保するというのみの考え方から、よりPlatform Engineeringを意識した活動の視点へのシフトという話が印象的でした。

たとえば、CI/CDパイプラインやリリースプロセスの自動化においても、「ストリームアラインドチームが”価値”を届けるまで迷わず進めるように道を整備する」という観点を持つ。

その上で、「開発者体験」と「信頼性」を軸にゴールデンパスの各要素を改良していくというアプローチは、仕事の視え方や思考が変わる視点だなと感じました。

創業期から全員でつくるPlatform Engineering — スピードと持続性を両立する文化の作り方

スタートアップならではの課題として、手動や秘伝のスクリプトでの環境構築や、技術選定/意思決定のロジックの喪失、属人化というものがあり、これを解決するためのPlatform Engineeringの考え方でのアプローチのセッション。

「開発者がコードを書く時間を最大化し、本質的な価値提供に集中できる環境をつくること」という視点で、チームの課題に関する課題を解決するプロセスにフォーカスされていた。

スタートアップでのPlatform Engineering視点での取り組み

スタートアップでの取り組みとして以下を上げられていた。

• 引き算思考による意思決定
  • 将来負債になりそうな領域を先回りして回避
  • アンチパターンを避け、ベストプラクティスに乗る
  • 非機能要件（IaC / CI / CD / Observability）に早期投資

• ADR（Architecture Decision Record）の導入
  • 設計・開発に関するあらゆる意思決定を文書化
  • あえて雑多にしてハードルを下げる
  • LLMを活用し、書きやすさ・読みやすさを支援
    • Cursorで文脈を共有しつつ支援
    • Notion AIで要約
    • Slackスタンプで「ADRがきたよ」と通知

• チーム横断での課題解決「巻物」
  • 困っていること / 困りそうなこと / 理想をNotionで管理
  • チーム全体で課題を可視化し、解決を議論できる場に
  • 安心して課題を表明できる心理的安全性を確保

ADRの取り組みがとてもいいなと思い、ぜひ自分のチームでもやりたいと思った。

Notionにナレッジを蓄積してAIで検索できるようにして属人化をさけれるようにしたい。

ワークロードを処理しないプラットフォームに専念する

組織の構造や働き方の観点からプラットフォームチームの事例についてのセッション。

プラットフォームを支援する Embedded / Enabling型のそれぞれのアプローチやその効果を紹介。

主にチームトポロジーの用語に沿って説明されていた。

• コラボレーション: 相手チームと綿密に協力する。1つのチームのように振る舞う。
• ファシリテーション: 相手チームが持っていない知見や技術を導入・支援する。コンサルタントやエヴァンジェリストに近い。
• XaaS: サービス・責任境界を明確にし、複数チームに低コストで横横断する。

横断チームやPlatform側だとこのチームトポロジーの観点から考えるのは大事だなと思った。

Embedded + Enablingのアプローチ

プロダクト開発を支援するSREとしてEmbeddedとEnablingの2つを組み合わせて取り組まれていた。

• コラボレーション(Embedded）
  • 期間: 無期限
  • チームに入り込み、チーム文化・プロダクト改善をしつつ、小さな成功事例をつくる

• ファシリテーション(Enabling)
  • 期間: 2~4週間
  • コラボレーションで生まれた成功事例を横展開。同じIssueを抱える外チームへサポート。

役割を分けるだけでなく、期間を設けて支援しているのが印象的だった。

成功事例からPlatform化へ

先程のEmbedded→Enablingの流れからさらにPlatformまで落とし込む仕組みを作られていた。

• Embeddedで成功事例をつくり → Enablingで展開 → Platformで仕組みに落とし込む
• PoC → Embedded → Enabling → Platform化 → 再びPoC …という循環で強化

このサイクルを意識してプロダクト改善されているのはとても勉強になった。

まとめ

はじめてのPlatform Engineering関連のイベントに参加したが今までになかった視点でのアプローチがたくさんあった。

自分が日頃やっている業務もPlatform Engineeringの観点で改善できそうだと感じた。

学びは日々の業務に落とし込んでいく！！