月間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を題材として、ユーザーにとって使いやすく、 体験の良いプラットフォームの作り方を説明します。