はじめに
こんにちは！グロービス・デジタルプラットフォーム部門(GDP) SREチームの松井です。
グロービスでは複数プロダクトを横断する共通インフラ基盤をプラットフォームとして提供していいますが、SRE チームとしてシステム信頼性を担保すると同時に、Platform Engineering的な観点から開発者体験を向上するためのPlatform改善に日々取り組んでいます。
昨今では特にAIを利用した開発者体験の向上がテーマとして挙げられることが多いですが、これに関連したPlatform Engineeringの知見のキャッチアップや、最新のトレンド、実践知を得たいと考え、先日開催されたPlatform Engineering Kaigi 2025 に現地参加してきました。
参加した内容に対する感想を交えながら、特に印象に残ったセッションに関して紹介していければと思います。
特に学びが深かった５つのセッション
当日はHall、roomA、roomBとセッションルームが3つに分かれていた為、どれも魅力的なセッションでしたが、実際の業務のヒントになりそうな内容や、個人的に気になった内容に絞ってピックアップしています。
紹介していない内容に関しても良質なセッション内容で、後からアーカイブ視聴で見直したい内容が非常に多くありました。
1. Engineering Tomorrow’s Platforms: Staying Relevant in the Age of AI
Platform EngineeringにおけるAI活用の現在地と未来像について、包括的な観点から語られたNicki Wattさんによるセッションでした。前半部ではプラットフォームの成熟度（Maturity Model）とPlatform Engineeringの具体的なプラクティスについて包括的に触れつつ、後半ではベストプラクティスの実践に関して、AIでどのように変わっていくのか具体的なビジョンが語られていました。
認知負荷を低減し、よりユーザーファーストとなるAI活用
セッションでは、これまでのリアクティブなプラットフォーム運用からの脱却が強調されていました。問題が発生してからチケットや問い合わせで対応するのではなく、AIを活用してプロアクティブ、さらには適応的（Adaptive）な運用を目指すという考え方です。
以下のような具体的な実践ビジョンが語られていました。
- 従来はアンケートやフィードバックに頼っていたユーザーの課題把握を、LiveデータをAIで解析することで、ユーザーが不満を表明する前に改善サイクルを回す運用
- BackstageのようなテンプレートベースのIDPから一歩進み、Slack Botのような対話形式のインターフェースを通じて、ユーザー自身がAIの支援を受けながら問題を解決できる世界観の提示
- プラットフォーム基盤のシグナルをAIが常時監視し、問題発生時にはAIエージェントを通じて、自然言語ベースで一次障害対応を行う。信頼性の向上に関する複雑性緩和をAIが支援し、問題の特定と対処の効率化や、対応の複雑性に対する認知負荷の低減を図る
Platform Engineering領域におけるAI導入のリアルな課題と「ガードレール」の重要性
一方で、AI活用の難しさ、特に「Enabling」領域での課題にも言及がありました。例えば、AIにインフラ操作（Kubernetesなど）を直接任せることのリスクです。
この点については「ガードレールを設けたAI（Guarded AI）」の以下のようなコンセプトがやるべき事として提示されました。
- 決定論的なoutcomeを得るためのチューニング（Spec Driven AI Coding等のプロンプトエンジニアリングの実践）
- クリティカルな操作は必ず人間が承認するワークフローを組む
- AIエージェントには、タスク遂行に必要な最小限の権限しか与えない（最小権限の原則）
感想：変化を受け入れ、実験的試みを継続する
これらのAIによる変化は急激ですが、知見を蓄え、Platform Engineeringの実践として昇華させるためには継続的な試行が不可欠といった形で締められていました。
このセッションを聴いて改めて感じたのは、AIの変化の速さに追従するためには、私たち自身が「未知の体験」に対して寛容になり、信頼性をベースとした実験やチャレンジを積極的に行っていく必要があるということです。
現在進行形でこのようなAIを用いたユーザー体験の向上に取り組んでいますが、非常に示唆的なセッション内容でした。
2. 「小さく壊す」は許し「一発アウト」は防ぐ Agentic AI 時代のプラットフォームが備えるべきガードレールを再考する
こちらはCAの岡さんからの発表内容でした。来る「AI Agent時代」を見据えたガードレールのあり方が語られました。開発のあらゆるフローにAIが介在する未来において、私たちはどのようにシステムの安全性を確保していくべきか。その問いに対する具体的なアプローチが示された、実践的なセッションでした。
AI Agentがもたらす新たなリスク
SREチームとしてプラットフォームの複雑性の緩和と認知負荷低減の取り組みの振り返りからセッション内容が始まり、Tiltを利用したLocal開発環境の整備等から始まる様々な取り組み等が紹介されました。
従来のガードレールでは守りきれない、AI Agentがもたらす新たなリスク
セッションではまず、AI Agentがコード開発やレビュー、インフラ操作まで行うようになった世界での新たなリスクが提示されました。開発、運用のほぼ全てにAIが介在することは組織の生産性の向上をもたらしていますが、同時にAIの非決定論的な振る舞いに起因する意図せぬ挙動が招く「一発アウト」が起きうるリスクについて述べられてます。
これまでのドキュメント、ポリシーをベースとした人間の開発者を想定したガードレールでは、こうした動的で予測不能なリスクを防ぎきるのは困難であるという問題提起は非常に示唆的でした。
これからのガードレール：ビジネスインパクトを基準に、リスクを言語化して「小さく壊す」を許容する
この課題に対し、これからのガードレールはより「システムベース」な対策が必要になってくると提言。これからのガードレール設計思想の根幹は、まず最悪のインシデント、脅威シナリオを具体的に想定し、そこからビジネスインパクトを逆算して組織として「一発アウト」のラインを明確に定義することにあります。
これら「一発アウト」の対策は言語化によって明確になり、各リスクに対し適切なセキュリティ対策の実践が提示されていました。
そしてその上で、許容ラインの内側であれば小さな失敗は許容し、小さな失敗においてAIが検知・調査、修復をサポートし、開発者の疲弊を防止する取り組みの実践が提示されました。これにより安全性を確保しつつ、開発スピードを損なわないバランスを取ることが可能になります。
感想：抽象化レイヤと「AIへのコンテキスト注入」の重要性
個人的な気づきとしては、プラットフォームにおける「抽象化レイヤ」と「AI」の関係性についての言及です。開発者に提供する抽象化レイヤも、その背景にある設計思想や制約事項といった「コンテキスト」をAIが理解できなければ、正しく活用されず、かえってリスクになり得ます。
今後、MCPなどを通じてAIに適した形でドキュメントや仕様を提供し、コンテキストを注入していく取り組みは、システムベースのガードレールを機能させる上で不可欠だと実感しました。ただ禁止するのではなく、AIが「安全に自律走行できる道路」を整備してあげるようなイメージですね。非常に学びの多いセッションでした。
3 一人SREが歩んだPlatform Engineeringスモールスタート実践録
こちらはMIXI 井上さんの発表でした。SREの主な責務は「信頼性」の担保ですが、このセッションでは、それに加えて「開発生産性」の向上にも踏み込んだSREチームの取り組みが紹介されました。開発者5〜6人に対しSREが1人という少数精鋭の「遊撃部隊」が、いかにして開発者が本来の価値創造に集中できる環境を整えていったのか、その実践が語られました。
「点から面へ」ー 雑事をなくすためのセルフサービス基盤
発表の中で語られていたのは、開発者がインフラ関連の「雑事」に囚われず、推奨ルートである「ゴールデンパス」を快適に進める状態です。そのために、個別のToil削減（点）から、開発者体験全体を向上させる（面）への意識改革を行ったとのことです。
具体的な取り組みは多岐にわたり、TerraformとGitHub ActionsによるIaCの徹底はもちろん、特に印象的だったのがSlackbotを活用したセルフサービス化です。IAMやKubernetesの権限付与をSlack上の対話で行える「Permission as Code」の仕組みは、裏側でOpenAI APIを活用しているとのことで、GLOBISでも同様の取り組みが実践できるのではと可能性を感じました。
他にも、プレビュー環境の自動整備、PR状況に連動したダッシュボードによる開発環境の利用状況管理等、開発サイクルの随所に生産性を高める工夫が凝らされていました。
密な対話が生んだ成果と、これからの挑戦
このような多岐にわたる改善が実現できた背景には、開発チーム（Stream-aligned team）との密なコミュニケーションがあったと強調されています。SREが1人という体制だからこそ、開発者の隣で課題をヒアリングし、素早く解決策を提供するという、密な連携が可能であったとのことでした。
もちろん、良いことばかりではありません。改善を進めるほどにバックログは増え、その優先度付けに悩むという現実的な課題も共有されました。この点は、我々のSREチームも抱える共通の悩みであり、非常に共感できる部分でした。今後は、AIを壁打ち相手に意思決定を早めたり、開発リソースを補ったりといった活用も進めているとのことで、非常に参考になるセッションでした。
4. Platformに“ちょうどいい”責務ってどこ？ 関心の熱さにあわせて考える、責務分担のプラクティス
Platform Engineeringを推進する中で、「この機能はどこまでプラットフォーム側が対応すべきか？」という問いは、我々の組織でもしばしば直面する悩みです。このセッションでは、estie社の徳原氏が、複数プロダクトを同時展開するコンパウンドスタートアップという環境下で、いかにしてプラットフォームチームとプロダクトチームの「“ちょうどいい”責務」を見出していったか、その実践的なプラクティスが語られました。
機能への関心で変わる、プロダクトチームとの理想的な距離感
セッションで提示された最も核心的なメッセージは、「責務の線引きは固定ではなく、プロダクトを取り巻く状況に合わせて柔軟に変えていくべき」というものでした。 当初は、機能や基盤単位で責任分界点は一律に引けると考えていたそうですが、実際はそうではなかったと言います。
その具体例として、2つの対照的な事例が紹介されました。全社に関わる「データアクセス基盤」の構築時は、SPOFへの懸念などから各プロダクトチームの関心が非常に高く、活発な議論が交わされた一方で、コスト増や運用負荷の課題解決を目的とした「VPC統合・インフラモノレポ化」の際は、プロダクトチームからの反応は「よしなに」という一言。 これは、元々プラットフォームチームが様々な支援をしていたため、信頼のもとに一任されていたからです。
このように、提供する機能のレイヤーや各チームの開発状況によって、関心の温度差は大きく異なるとのことでした。
プラットフォームは「育てる」もの。状況に応じて関わり方を変える
最終的にestie社のPlatformチームは、相手チームの状況に応じて関わり方を柔軟に変えるアプローチを提唱していました。 例えば、あるチームは「ビジネスロジックに集中したいので実装までお願いしたい」、別のチームは「欲しい機能は自分たちで実装してPull Requestを出すので、整合性の担保をお願いしたい」といったように、同じプラットフォーム機能に対しても求める関わり方は様々でした。
Platformチームが必ず責務を握るべきなのは、認証認可基盤やインフラ監査設定といった「守るべき要件」がある領域と、開発フローのように「組織で共通化することで価値に直結する」領域であると強調されていました。 それ以外の大部分については、プロダクトチームを適切に巻き込み、対話を通じて協働しながら、まさに「プラットフォームをみんなで育てていく」ことが重要だと結論づけられました。
このセッションは、静的な責務分担図を描くのではなく、動的な関係性の中で最適解を探し続けることの大切さを教えてくれるものでした。
感想
このセッションは、「どこまで作り込み、どこで線引きすべきか」という問いに、力強い示唆を与えてくれるものでした。「責務はチーム状況に応じて柔軟に変える」という考え方は、頭では理解しつつも実践の難しさを感じていた点です。
また、データアクセス基盤の事例のように、Design Docを作成して丁寧に対話を重ねるプロセスや、インフラ基盤のように信頼関係から「よしなに」で進められる関係性の対比は、日々の業務におけるコミュニケーションの重要性を再認識させてくれます。
また、質疑応答では組織規模の拡大に対し、現在の仕組みはプラットフォーム側の運等負荷が高いのではないかといった質問もあり、このような取り組みを実践する場合の組織のスケーラビリティとプラットフォームのボトルネック化に対する考慮も併せて考えていければと思いました。
5. 組織を巻き込む大規模プラットフォーム移行戦略 〜50+サービスのマルチリージョン・マルチプロダクト化で学んだステークホルダー協働の実践〜
本カンファレンスで最も個人的に貴重な知見だと思えたセッションが、このLegalOn Technologies社杉田さんのセッションでした。50を超えるマイクロサービス群を、US進出という事業戦略を機に、マルチリージョン・マルチプロダクト対応の新プラットフォームへと移行させる。約1年に及ぶこの巨大プロジェクトを、技術的な課題だけでなく、複雑に絡み合うステークホルダーとの協働を通じていかにして成し遂げたのか、そのリアルな軌跡が語られました。
「勝ち筋が見えない」状態からのスタート
プロジェクトの始動時、最大の課題は「誰も移行の勝ち筋が見えていない」状況だったようです。マルチリージョンの知見は乏しく、JP/USで倍増するマイクロサービスの開発・運用負荷、そしてCTO、USプロジェクト責任者、経理財務といった多様なステークホルダーとの合意形成など、問題は山積みだったとのことです。
この混沌とした状況を乗り越えるため、プラットフォームチームがまず着手したのは、徹底的な「可視化」。全コンポーネントの依存関係を洗い出し、巨大なマップを作成。データ移行の現実的な方法を複数案出し、それぞれのメリット・デメリットを比較検討していました。こうした地道な作業を通じて、チーム内外の目線合わせを丁寧に行っていったそうです。特に、請求単位が複雑化する課題に対しては、経理財務チームを早期に巻き込み、アーキテクチャ図を元にコストの按分方式を議論・合意形成したというエピソードは、技術とビジネスを繋ぐ重要な活動だと感じられました。
覚悟を生んだビジョンと、成功に導いた自動化ツール
複雑で困難なこのプロジェクトを推進する原動力となったのは、明確なビジョンステートメント。「開発者が1日で開発を開始でき、認知負荷低く自律的に開発・運用できる世界を夢見ている」という強いメッセージが、関係者の覚悟を生み、困難な意思決定を支えたとのことでした。
また、移行を技術的に支えたのは、標準化と自動化。50サービスを超える移行先インフラの構築を人手で行うのは不可能であるため、新しいサービスを払い出すためのstarter-kitや、標準化されたKubernetesマニフェストを生成するk8s-genといった内製ツールが大きな力を発揮。これにより、移行作業の属人化を防ぎ、セキュアな状態をデフォルトで実現できたと発表されていました。
感想：何よりもまず「全体像の洗い出し」から始める
このセッションは、技術的な学びもさることながら、大規模プロジェクトを推進する上でのマインドセットとして、非常に多くの学びがありました。
「明確なビジョンは、困難なプロジェクトへの覚悟を生む」という言葉が非常に刺さりました。
また、移行リハーサルで「DB内のデータに、旧環境のGCSパスがハードコードされていた」という問題が発覚した話は、他人事とは思えません。
技術的な見通しを立てることも重要ですが、それ以上に、関係者全員で「全体像を洗い出し、依存関係を整理する」というチームを巻き込んでの活動が、プロジェクトの成否を分けるのだと痛感しました。まさに圧巻のセッションでした。
まとめ
今回のPlatform Engineering Kaigi 2025は、この分野のベストプラクティスが確立されつつある「成熟」を感じさせると同時に、次の大きな変革の波を予感させる、非常に刺激的な場でした。特に、今回聴講したセッション全体を通じて、大きな潮流が見えてきました。
一つは、AIというゲームチェンジャーとの向き合い方です。各セッションで語られていたように、AIはもはや単なる効率化ツールではなく、プラットフォームのあり方そのものを再定義する可能性を秘めています。これまで私たちが積み上げてきた開発プロセスやガードレールを、いかにAIの能力を最大限に引き出す形で最適化していくか。これは、Platform Engineeringというトピックに突きつけられた、刺激的で新しい問いだと感じています。
個人的に重要だと考えているのは、より一層の「組織論への回帰」 です。Platform Engineeringに関わる最新のツールや技術を画一的に導入すれば良いという時代は終わり、いかにして自分たちの組織規模や事業フェーズ、チームの成熟度に合わせたプラットフォームをデザインしていくか、という点が強く問われていると感じています。
estie社の「責務の柔軟な変更」や、LegalOn社の「ステークホルダーとの協働」の事例にも見られるように、技術的な正しさ以上に、チーム間の対話を重ね、組織全体の課題に真摯に向き合うことの重要性が、今回のカンファレンスの通奏低音だったように思います。
私たちも、これらの潮流と課題に真摯に向き合い、学び続ける組織として、開発者体験の向上に努めていきたいと改めて決意を固めました。この参加レポートが、同じように日々奮闘されているSREやプラットフォームエンジニアの皆様にとって、現場での次の一歩を踏み出すためのヒントとなれば幸いです。
Discussion