月間7,500万人が利用する国内最大級のメディア群において、数十のプロダクトを共通基盤上で安全かつ効率的に運用するため、Platformの整備を進めてきました。しかし、プロダクトの急増と多様化に伴い、特に認証・決済などセキュリティ要件の高いサービスは同一環境での運用が難しくなり、やむを得ず環境を分離するケースが増えています。それにより、開発者の認知負荷が高まり、設定ミスや運用トラブルのリスクも顕在化してきました。こうした課題を受けて、セキュリティ要件に応じた分離を前提としつつ、開発者にも運用者にも扱いやすい統一的なPlatformの実現を目指して再設計を行いました。本発表では、Identity、クラウドリソース、ネットワーク、CI/CD、開発者ツールなどの各レイヤーにおけるマルチテナント化の設計方針、共通化と分離の判断基準、安全性と開発体験の両立を実現するための具体的な工夫を紹介します。

プラットフォームエンジニアリングにおいて抜本的な進化をもたらす大規模マイグレーションは、技術的挑戦に加え組織全体のステークホルダーとの合意形成と協力獲得が不可欠です。LegalOn Technologiesでは、単一プロダクト・単一リージョン向けプラットフォームをマルチリージョン・マルチプロダクト向けにリアーキテクチャする際、50以上のマイクロサービスを含む大規模システム移行を半年以上の準備と2日間の計画メンテナンスを経て成功させました。本セッションでは、この高難易度な移行プロジェクトにおいて学んだ、プロダクトチーム・ビジネス責任者・サポートチーム、経理財務など多様なステークホルダーから理解と協力を獲得するための具体的戦略、周到なリスク管理手法、移行プロセスで直面した課題と解決策、そして今後同様のプロジェクトをより効率的に進めるための実践的な教訓をお伝えします。

インシデント対応に利用するSaaSが提供するAIは賢くなり、インシデントの原因分析や事後対応の多くのプロセスをそれらに任せることもできる時代になりました。では、インシデント対応の全てをそれらに任せるだけで良いのでしょうか？ 我々の答えは「No」です。 我々のSaaS AI x 内製AI AgentによるハイブリットAIOps戦略の全貌を解説します。 SaaSの力と自社の知を融合させ、知的生産性とレジリエンスを最大化するAI時代の新たなプラットフォーム運用の実践知をお持ち帰りください。 本セッションで得られること： - 「作る/任せる」の判断基準と費用対効果の考え方 - LangGraphやLLMとNLPを活用したアーキテクチャと運用ノウハウ

本セッションでは、小規模開発組織からでも実践可能なPlatform Engineeringの具体的事例をご紹介します。 株式会社hacomonoでは開発組織が15名程の頃からPlatformチームを組成し、約85名になった現在でも組織の成長に合わせた「開発者体験の向上」に挑戦しています。 当初はGithub Acitonsなどを活用した軽量なプラットフォームで価値を提供し、組織の成熟が進みk8sを用いたPlatform Engineeringに挑戦している状況です。 ここでは、組織規模を軸に「何を」「なぜ」「どのように」実践したかを解説し、各フェーズで得られた成果と直面した課題を共有します。 これからPlatform Engineeringに取り組む方々が、自組織の状況に最適な手法を選択するための判断基準と、段階的な成長戦略を持ち帰ることができる実践的なセッションを目指します。

金融系SIerのCCoEとして、従来的な開発手法・技術による非効率的な開発の実態を改善すべく、開発者の生産性向上と品質確保の両立を目指したプラットフォームエンジニアリングを開始しました。具体的には、WebIDEの提供やCI/CD環境の整備による、リードタイムの削減やガバナンス向上、開発プロセスの変革などを初期施策として取り組んでいます。 本セッションでは上記施策の概要と共に、従来取り組みのようなシーズ起点のアプローチではなく、開発者の課題やニーズを起点としたプロダクトマネジメントによるアプローチを共有します。 また、金融業界特有の規制環境下や、クラウドへの移行途上にあるエンタープライズにおける、現場の新しい技術採用への負担・抵抗感への対応やマネジメント層の巻き込みなどの苦労話についてもお話します。

SRE専任もPlatformチームもない中、CI/CDのつらみやインフラの属人化をきっかけに、ひとりで始めたPlatform Engineering。小さな改善の積み重ねが、やがて開発者体験の底上げにつながりました。 本セッションでは、遊撃部隊として活動を開始してから3年間で実践したPlatform Engineeringの実例を紹介します。リソースが限られている中で、CI/CDプロセスの効率化、k8sの整備、開発生産性向上の様々な取り組み、AI導入など取り組んできたことを、成功・失敗を交えて”リアルな現場”でのお話をお届けします。「まず何から始めればいいのか？」に悩んでいる方のヒントになれば幸いです。

私たちは、多くのプラットフォームチームと呼ばれる組織が持つようなワークロードを処理するソフトウェア（サービス）を持たないような方針で運営しています。ここでいうソフトウェア（サービス）とは、社内開発者向けに提供するタスクランナーやKubernetesやDBなどのことです。 こういった利用者のワークロードを処理するプラットフォームは、一度提供を開始すると下記の対応に非常に多くの工数を必要とします。 - 移行やアップグレード対応 - 問い合わせサポート対応 またリリースから時間が経つと、開発者体験のパラダイムシフトが発生し、例えばリリース当時には一般的ではなかったX as Codeの考え方などにプラットフォームとして追従する必要も出てきます。 これらの活動はワークロードを処理するプラットフォームでは最も重要で本質的な活動ですが、これらの活動に時間を取られるあまり、開発者との接点に投資する余裕が不足しがちという課題があります。 そこで私たちEmbedded SREチームでは、そういったプラットフォームチームを支援するため、ワークロードを持たないプラットフォーム活動を行うようにしてきました。 例えば、プラットフォームチームが提供するツールに対して直接コードコントリビューションしたり、ドキュメントにコントリビューションしたり、開発者向けに正しい使い方をハンズオンするなど、開発者たちと多くの接点を持ち、かつ多様なプラットフォームチームに貢献するようにしています。 こういった活動の中で行っている工夫や悩みを共有するセッションです。プラットフォームチームを運営している方で、特に開発者との接点に悩んでいる方に見ていただきたいです。

「生成AIのおかげでコードは10倍速で書けるようになったのに、レビューとセキュリティチェックで結局リリースが遅い」―そんな現代エンジニアリングの新たなボトルネックを解決する方法を提案します。 Copilot、Cursor、Claude Code等、次々に出てくるコーディング支援AIにより、エンジニアの生産性は飛躍的に向上しています。しかし皮肉なことに、大量生産されるコードに対して、レビュー・テスト・セキュリティ検証が追いつかず、新たなボトルネックが生まれています。 本セッションでは、この「AIがコード書きすぎ問題」に対し、DevSecOpsプロセス全体にAIを適用する実装パターンを紹介します。具体的には、AIによる自動コードレビュー、脆弱性検出と修正提案の自動化、インフラ設定の継続的検証、さらにはAI同士の相互チェック機構まで、実践的なアプローチを解説します。

人数が限られたスタートアップでコンパウンド戦略をとり、複数プロダクトを支え続けるには、インフラや開発フローの「ある程度の道のり」を決めておく必要があります。私たちは認証の共通基盤化、ネットワーク統合、Terraformのモノレポ化、CI/CDの標準化、Preview環境など、Platformチームとして機能開発、集約を進めてきました。そのなかで見えてきたのは、プロダクトごとの事情や、開発チームの興味関心の温度差にどう向き合うかが、標準化の成否を左右するということでした。 Platformチームとしての責務をどこまで担い、どこから委ねるべきか、その線引きを実際のプロジェクトを通じてすり合わせ続けてきました。共通化と柔軟性のあいだで、ちょうどいい塩梅を探りながら走り続ける、スタートアップのPlatform運営のリアルをお届けします。

Platform Engineeringの目的のひとつは、適切な抽象化レイヤーを提供し、利用者の認知負荷を減らして開発効率を向上させることです。しかし、単純な隠蔽（カプセル化）による負荷軽減は、過度な認知的オフローディングによって学習を阻害したり、抽象化の過不足により逆に認知負荷を上げてしまう場合があります。 本セッションでは、まず前提となる認知心理学における認知負荷やスキーマ（知識体系）の構築に関する基礎的な理論を紹介します。その理論を踏まえ、Platform Engineeringの運用課題を体系的に捉え直し、単純に認知負荷を下げるだけでなく、開発者が段階的にプラットフォームのスキーマを獲得する方法を考察します。また具体的な実践例として、サイボウズにおいて200名以上の開発者が利用しているKubernetesベースのプラットフォームでの取り組みを紹介します。

これまで私たちは、プラットフォームが抱える不必要な複雑さから生まれる「認知負荷を軽減」し「開発生産性」を向上させるための一環として「プラットフォームのシンプル化」、いかにして TVP を作り上げるかに力を入れてきました。 そんな中、 AI Agent の登場により、開発者がこれまで認知できなかったものが認知できるようになり、「開発生産性」の向上や「運用高度化」が実現できるようになりました。 また最近では、人が認知しているのは明確なゴールだけで手段は Agentic AI が自律的に意思決定を行うといったようなやり方も浸透してきています。 このような状況下で、ビジネスの存続そのものを危ぶむ個人情報漏洩などの「一発アウト」をどのように防ぐのか。 20以上のサービスを支えるマルチテナントプラットフォームの構成を元に、プラットフォームが備えるべきガードレールを再考します。

プラットフォームエンジニアリングでは「プロダクト開発とデリバリーを加速すること」を重要なミッションとして位置付けています。 LINEヤフーのプライベートクラウドFlavaではプラットフォームの企画段階からユーザー（開発者）体験の向上を最重要項目の１つとして企画・設計を行うことで、このミッションを達成しようとしています。 本セッションでは、特にFlava のKubernetes基盤である Flava Kubernetes Engineを題材として、ユーザーにとって使いやすく、 体験の良いプラットフォームの作り方を説明します。

大規模なKubernetesクラスタを運用する中で、実行時のセキュリティを確保しつつ、開発体験を損なわない仕組みを整えることは、運用の安定性と開発スピードを両立させるための重要な課題です。AmebaではFalcoを導入し、Auditログに基づく独自ルールの整備や、Slack通知・Talonによる初動対応の自動化を含む、SOARプラットフォーム連携を見据えた継続的なセキュリティインシデント対応基盤を構築してきました。 本セッションでは、サイバーエージェントでの導入当初に直面した課題や運用に定着させるまでの工夫、検知と対応のバランスの取り方など、現場での具体的な取り組みをもとに、現実的なDevSecOpsの進め方を共有します。SysdigからはFalco検知ルールの継続的アップデートが可能になるFalco Feedsや商用版Sysdigならではの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?

急成長するサービス基盤では、開発者が安心して機能追加できるプラットフォームが欠かせません。 hacomonoでは異なる可用性が要求されるサービスを個別のマイクロサービスに切り出すことで、開発速度と可用性の両方を満たしています。 マイクロサービス化を行うためには個々のサービスが疎結合で、登録されたスキーマのイベントだけがやり取りされるイベントバスが必要でした。 hacomonoでは「スキーマ駆動イベントバス」を設計しました。Protocol Buffersを信頼の基点とし、Fire-and-Forgetで送信側と受信側の依存を排除しています。 CIでスキーマの互換性破壊を検知し、破壊的変更のデプロイの防止。 不正なイベントの発行や、開発者の考慮漏れによるループイベントを署名とバリデーションで遮断してカスケード障害を防止します。 本セッションでは、その設計思想と段階的導入プロセスを共有します。

CNAPPは、開発者が安全なアプリケーションを迅速に構築・デプロイするための「ガードレール」です。 Platform engineeringの目標は、開発者がコア業務に集中できる安全な基盤（IDP）を提供すること。CNAPPは、この基盤のセキュリティ層として機能します。 1. セキュリティの自動化 コード段階からランタイムまで、脆弱性や設定ミスを自動的に検出し、修正を促します。これにより、開発者はセキュリティ専門家でなくても、常に安全な開発プロセスを維持できます。 2. DevSecOpsの加速 開発者とセキュリティチームが共通のプラットフォームで連携し、セキュリティの問題を早期に解決することで、開発速度を落とさず、セキュリティ品質を向上させます。 このセッションでは、Tenableが提供する CNAPP をご紹介し、開発者が安全にアプリケーションを提供するための道筋を示します。

2400万点以上の商品を取り扱う大規模BtoB ECサイトMonotaROでは、事業の急成長に伴い、既存システムの変更容易性やメンテナンス性が低下。「出荷目安アイコンの変更に9ヶ月もかかる」ほどの開発速度の低下や、APIの乱立といった課題が深刻化していました。 この状況を打開すべく全社的なモダナイゼーションを進める中で、同じ課題が再生産されることを防ぐため、我々は優れたソフトウェア設計の原則を組織の協働プロセスに応用するアプローチを試みています。 本発表では、このアプローチを支えるプラットフォームエンジニアリングの取り組み、特に開発者の認知負荷低減を目指す内部開発者ポータル(IDP)の実践例を紹介。インナーソース文化を育む取り組みの先にある、AIエージェントを活用した今後の展望についても触れます。

本セッションでは、AI駆動型開発を“最小の手間”で始められるマルチクラスタ対応のAI駆動開発環境の構築デモをお見せします。開発チームがUIから操作するだけで、Kubernetesクラスタの立ち上げからGitLabリポジトリの自動生成、DevContainer設定、VSCodeによる開発開始までを一気通貫で実行します。 さらに、GitLab Duo や Duo Agent などのAIツールを活用した最新のAI駆動開発支援機能、そして本番環境（Kubernetes）へのデプロイまでの流れも紹介します。 以下のような課題をお持ちの方に特におすすめです： ・Kubernetesのクラスタが大きくなり管理を効率化したい ・様々なプラットフォーム上のKubernetesマルチクラスタの管理を効率化したい ・AIを使ったDevSecOpsやAI駆動開発をはじめとしたAI支援機能に関心がある

Platform Engineeringチームとして開発生産性向上に取り組み、Four Keysをエリートレベルまで改善することに成功しました。しかし、エンジニアからは「生産性が上がった実感がない」という予想外の声が。ここから、数値改善と現場の実感のギャップを埋める新たな挑戦が始まりました。 アプリケーションエンジニアとの対話を通じて、私たちは「機能リリース数」という新指標にたどり着きました。企画からリリースまでの全工程を見直し、真のボトルネックを特定。その解消に向けて組織全体で取り組んでいきました。 本セッションでは、Four Keysという確かな土台の上に、さらなる生産性向上を実現するための進化のプロセスをお話しします。優れた指標であるFour Keysを達成した後、私たちがどのような課題に直面し、どう乗り越えたか。その試行錯誤と学びを共有します。

スタートアップ創業期は、プロダクト開発の速度を優先するあまり、基盤づくりや運用設計を後回しにしがちです。しかしその選択は、成長フェーズで大きな負債となって跳ね返ります。本セッションでは、「創業期から全員でPlatform Engineeringに取り組む」という一つの解を提示します。PdMやデザイナも巻き込みながら、理想から考える"引き算思考"で基盤を形にしていくアプローチや、独自のADR（Any Decision Record）活用など、少人数チームだからこそ可能なやり方を紹介。創業期における速度と持続性の両立について持ち帰れるヒントがあれば幸いです。

プラットフォームエンジニアリングを導入したくても、「上司に投資対効果をうまく伝えられず、予算がとれない」--そんな悩みをよく耳にします。 新しい仕組みを社内に取り入れるのは簡単ではありません。どれだけ技術的に先進的な取り組みでも、組織内の壁や文化の「境界」にも向き合い、理解を広めなければ導入は進まないでしょう。 例えば、開発者なら実感が湧く「開発者体験の向上」も、経営層にはイメージしづらく、理解を得るのは容易ではありません。 本セッションでは、弊社が内製化支援で得た知見をもとに、プラットフォームエンジニアリングを導入する「トップダウン」、「ボトムアップ」のアプローチを実例とともに紹介します。 「どんなポイントを押さえれば社内が動くのか」「成果をどのように見える化すればよいのか」など、すぐに使えるヒントをお届けします。

本発表では、社内のいくつかのプラットフォーム運用管理に従事する中で培った、エコシステム導入における実践的なアプローチを共有します。プラットフォームにエコシステムを導入する際は、運用負荷を最小化する明確な判断基準が重要です。導入前の評価軸（学習コスト、保守性、チーム習熟度、既存システムとの親和性）から実際の導入事例まで体系的に紹介します。特に運用フェーズでは、Design Docによる設計思想の文書化、段階的なバージョン管理戦略、チーム間の知識共有プロセスなどが持続可能性の鍵となってきます。導入判断のフレームワークから日常運用で得られた知見や失敗経験まで、現場目線での実践的なノウハウを共有し、長期的に保守可能なプラットフォーム構築の指針を共有します。

マルイユナイトは、丸井グループの大企業DXを目的に立ち上がったテックカンパニーです。私たちが任されたのは、将来的に会社の中核を担うプロダクトの完全内製開発でした。 とはいえ、立ち上げ期の少人数体制。エンジニアは数人、開発基盤もノウハウもない──そんな状況で私たちが選んだのは、AI活用を前提とした開発の仕組みづくりです。AIと協働する中で私たちが向き合ったのは、要件定義から設計、実装に至るまで、曖昧な知識を少しずつ「制約された知識」へと落とし込むこと。“人が考え、AIが手を動かす”体制を支えるための、知識の磨き込みが開発の核となりました。 この取り組みの中で私たちが強く実感したのは、「知識がプラットフォームになる」ということです。本セッションでは、ゼロから知識を整え、AIに任せられる土台を築いていく過程と、その中で得られた学びを、大きな企業の中の小さなチームのリアルな視点からお届けします。