セッション一覧

パナソニックの老舗クラウドIoTサービス「HEMS」は、2012年から稼働し、巨大なモノリスシステムとして運営されてきました。 本セッションでは、そこからGit導入からKubernetes本番稼働、クラウドネイティブ文化の醸成へ至るまでの軌跡を、失敗談とともにお話しします。 また、IoTの企業としてeBPF×分散トレースでIoTデバイスのEnd-to-End可観測性に挑んだ話もご紹介します。 レガシーだから、製造業だから、と足踏みしている方の背中を押せるセッションにしたいと思います。

本講演では、データと文化の主権を守る「ソブリンAI」の実現に向けたソブリンなインフラ構築を主題とします。先行する欧州の事例を引き合いに、特定のプラットフォームに依存しない「ソブリンクラウド」エコシステムの重要性を提示します。その上で、ソブリンクラウドの確立には、それらを操る「人」の力が不可欠です。結論として、日本の競争力を左右するのはクラウドネイティブ技術者の育成の重要性を聴講者の皆様に訴えかけたいと思います

株式会社ispecは、医療機関様向け/医療システムベンダー様向けに、既存の病院システムのクラウド化を推進するプラットフォーム『CloudSail』を開発・提供しています。このプラットフォームでは、自社でセットアップをした小型のサーバーを医療機関様にお配りをし、その上でクラウドと連携をするためのコンテナアプリケーションを動かせるようにすることで、オンプレミスとクラウドのハイブリッドな環境の橋渡しをしています。 本講演では、病院システムというセキュリティやネットワークの要件に制約がある中で、どのような技術を組み合わせてハイブリッド環境における可用性や安定性を維持しているか、についてお話をします。 特に、ハイブリッド環境においてクラウド・ネイティブ技術の活用の実例としてエッジ版kubernetesであるk3sとHelm を活用したアプリケーション実行基盤、OpenTelemetryを用いたオブザーバビリティ・パイプラインについて深掘りをし、クラウド・ネイティブ技術のこれまでになかったユースケースと実運用から見えてきたリアルな課題についてご紹介します。

多数の OSS で構成されているコンテナイメージは、近年急増する脆弱性を狙ったサプライチェーン攻撃の主要な標的となっています。 一方で、イメージスキャンやアラートを導入しても、脆弱性や依存関係の多さから対応が後回しになってしまったり、修正対応が開発者の大きな負荷となっているケースも少なくありません。 このような課題に対し、脆弱性や依存関係を最小化したデフォルトで安全なコンテナイメージ「Hardened Container Images」の採用が注目を集めています。 本セッションでは、Docker が 2025 年 12 月に Apache 2.0 ライセンスのオープンソースとして無償提供を始めた「Docker Hardened Images (DHI)」を一つの実践例として、コンテナイメージにおける脆弱性がなぜ削減しづらいのか、そして Hardened Container Images がどのように「後追いではない」サプライチェーンセキュリティを実現できるのかを解説します。

サービスを継続的に運用するにあたり、定期的な負荷検証はとても大事です。例えばあるリリースで、あるエンドポイントにN+1クエリが含まれてしまった場合、たった数行のコードがサービスダウンを起こしてしまうこともあります。 しかし、継続開発されているサービスは常に新しいコードが生まれ、その新しいコードに対してのシナリオを開発し続けることは容易なことではありません。 上記の課題に対して、AIを用いて課題解決を行い、継続的に負荷検証をできる状態にした事例を共有します。

AI エージェントにも従来のアプリと同様、堅牢なセキュリティや可観測性が不可欠です。本セッションでは、Platform Engineering を Agentic Application 向けに適用していく方法を解説します。AI ゲートウェイ、MCP の統合や様々なコントロールプレーンを IDP に組み込み、ガバナンスと開発速度を両立しつつ本番運用に乗せるためのアーキテクチャ設計を考えていきます。

AIコーディングで生産性は大きく伸びました。ただ、恩恵を受ける人と、コストを払っている人は同じではありません。AIが生み出すコードの量は、オンコール担当者の睡眠と引き換えになっていきます。 書く側は確かに速くラクになっています。でも、深夜に叩き起こされるのはいつも同じ人たちです。本番で火を噴いたコードの責任は、結局どこかの人間が背負うことになります。この不均衡の根本原因は、ツールではなく組織のあり方にあります。生産性は個人に閉じてスケールしますが、障害の影響は組織全体に広がる。このレバレッジ範囲のミスマッチが放置されたまま、AI活用だけが先に進んでいるのが今の現場です。 ITにおけるボトルネックは開発から運用に移りました。そんないまこそ、運用担当が不幸せにならないよう、運用体制を根本から見直してみませんか。現場のリアルを踏まえながら、これからの運用の在り方をお話しします。

DXの加速により、開発スピードとセキュリティ強化の両立がこれまで以上に求められています。しかし、従来の開発終盤でまとめて実施する診断では、手戻りやリリース遅延が発生しがちです。本セッションでは、AIを活用した脆弱性診断の自動化・仕組み化により、専門知識に依存せず開発プロセスへセキュリティを組み込む方法を解説。DXを推進しながら、開発基盤に自然に組み込めるシフトレフトの具体像を、デモを交えてご紹介します。

「クラウドネイティブ＝Kubernetes」という風潮の一方、物理サーバーやVMを運用し続けなければならない環境は数多く存在します。そうした環境では、SSHによる手作業やプッシュ型スクリプトによるデプロイが蔓延し、運用負荷とアタックサーフェス拡大が課題となっています。 本セッションでは、Non-Kubernetes環境で「宣言的」かつ「ゼロダウンタイム」な継続的デプロイを実現するOSS「Dewy」を紹介します。Dewyはプル型アーキテクチャにより各ホストが自律的にレジストリを監視し、Kubernetesのエッセンスを既存サーバー環境にもたらします。 さくらのクラウドでの実用事例として、プル型移行によるアタックサーフェスの最小化、フック機能を活用したDBマイグレーションの自動化、コンテナモードによるランタイム管理の抽象化という課題解決を深掘りします。 Kubernetesを導入せずとも、自律性・宣言的・セキュアというクラウドネイティブの原則を既存インフラへ適用できる、その実践知を共有します。

組み込み製品のアーキテクチャは長らく、ハードウェアとソフトウェアが密結合した姿が一般的でした。しかし、AIの活用や継続的なアップデート要求が高まる現在、その変革が急務となっています。 本講演では、制約の多い産業エッジに「なぜKubernetesが必要なのか？」という背景と現在地を紐解きます。さらに、Linux Foundationで始動した産業エッジの相互運用性を確保する新プロジェクト「Margo」を解説。 「産業エッジ×Kubernetes」がもたらすハードとソフトの分離、そして新たな開発者体験の全貌を語ります。 【対象者】 ・エッジコンピューティングの最新動向を調査している方 ・組み込み製品のエンジニア ・多数のエッジ機器の統合管理に悩むインフラ担当者 ・OT/IT融合の最新動向を知りたいアーキテクト 【得られる知見】 ・エッジコンピューティングの最新技術動向 ・産業エッジ×Kubernetesの必然性と、エッジ特有の課題に対する現在地 ・新標準「Margo」が目指すベンダーフリーな連携の仕組み ・クラウドのアジリティを産業エッジに持ち込む次世代の開発方法

閉域ネットワークなどセキュリティ要件を吸収するエンタープライズのクラウド共通基盤の上で、アプリの開発導線を整えることが私たちのミッションでした。 私たちはCDKカスタムコンストラクトで基盤の制約を吸収しセキュリティ基準も担保。 GitHub Packagesでの組織内配布、GitHub Actions Reusable WorkflowsによるCI/CD共通化により、開発者はアプリを書くだけで済む仕組みを構築しました。 設計で最も苦労したのは疎結合性の設計です。 共通基盤との接続やVPCの扱いなど基盤固有の制約はコンストラクトが吸収し、開発者は意識不要。 それでいて案件固有のカスタマイズにも対応できる柔軟性を維持しました。 TypeScriptの型補完で何が設定できるか一目で分かるだけでなく、ドキュメントやSkills・MCPによるAIコンテキスト配布も整備。 クローン時点でAIがベストプラクティスを理解済みの状態に。環境構築は2〜3週間から約2時間に短縮。 「誰もが躓く部分が取り除かれ、開発に集中できる」という声が届いています。 どのように開発者体験を高めたかを共有します。

分散トレースは本番環境の可視化に不可欠ですが、データ量増大に伴うコストや基盤負荷が大きな課題となります。解決策としてテイルベースサンプリングが有効ですが、自前運用には特有の技術的難所が存在します。本セッションでは、OpenTelemetry Collectorを用いた「実運用に耐えうる」サンプリング構成を解説します。gRPCの負荷分散制約を考慮したルーティング設定や、KubernetesでのStatefulSet活用など、具体的な実装パターンとデモを交えて詳しく解説します。 一方で、オブザーバビリティ基盤自体の運用保守が、本来の「サービス改善」の時間を圧迫するという側面も無視できません。そこで、DIY構成の知見を整理した上で、本番環境におけるもう一つの有力な選択肢として、マネージドサービスによるサンプリングアプローチについても考察します。サンプリングを自ら「作り込む」苦労と、機能として「利用」する利便性の双方を比較検証し、変化の激しいクラウドネイティブ環境において、自社に最適な基盤を選択するための判断材料を共有します。

クラウドネイティブ時代において、開発者の認知負荷低減は急務です。ソフトバンクでは、GitOpsによる自動化でセルフサービス化を実現する共通基盤『CNAP』を通じて、クラウドネイティブな開発・運用の標準化を進めてきました。一方、開発者体験の向上には、実行基盤だけでなく、申請業務や情報導線を直感的につなぐGUIとしての開発者ポータルも不可欠です。本セッションでは、その入口として1年間運用してきたBackstageの成果と課題を共有するとともに、CNAP×Backstageで実現する「共通基盤とポータルの両輪による開発者体験向上」をお伝えします。 さらに、この構想をより高いレベルで実装・展開させるため、ソフトバンクはエーピーコミュニケーションズと強固なタッグを組みました。セッション後半では、マネージドBackstageサービス『PlaTT』の実績と高い技術力を有する同社と共に、既存エコシステムを統合する開発者ポータルの具現化プロセスを詳解します。 両社が戦略を描き、現在進行形で突き進むプラットフォームエンジニアリングの最前線から、「認知負荷低減」の実践的ヒントを持ち帰っていただけます。

AIの進化により、機能開発や実装のスピードは大きく向上しました。一方で、サービスの成長とともにシステムは分散・複雑化し、パフォーマンス改善は依然として人手に依存しています。その結果、開発速度に対して改善が追いつかず、「速く作れるのに遅くなる」という状況が生まれています。 本セッションでは、この問題を「改善のリードタイム」という観点から捉え直します。従来のパフォーマンス改善は、トレースやログをもとに原因を調査し、修正と検証を行うプロセスでした。しかしクラウドネイティブ環境では、分散システムや非同期処理によりボトルネックの特定が難しく、このプロセスがスケールしません。 そこで本セッションでは、AIを活用してボトルネックの特定から改善までの流れをどのように高速化できるか、またそれをPlatform Engineeringの観点でどのように仕組み化できるかを、具体例とともに紹介します。

ペアーズは日本・韓国・台湾に展開する中で、日本向けと海外向けの二重開発により仕様差分が拡大し、保守面で非常に課題を感じていました。その結果、開発速度と品質の両立が難しくなっていました。 本セッションでは、グローバル展開戦略を推進する1 Application 化を軸にした Re:Architect の戦略と実践知を紹介します。 Applicationやデプロイ基盤は統一する一方、データは国・リージョン単位で分離するといった、データストア、国際化、キャッシュ設計の具体例を通じて、グローバル展開で速度と信頼性を両立するための設計判断と実装のポイントを共有します。

「OSSがあるなら自作するな」——CNCFを中心に成熟したエコシステムがこの常識を支え、多くの現場に恩恵をもたらしてきました。しかし採用したOSSの一部しか使っていなかったり、誰も面倒を見ず負債になったりするケースは少なくありません。さらにingress-nginxの廃止やKubeSphereのOSS版撤退のように、OSSの存続も約束されていません。 それでもOSSに頼るしかありませんでした。しかしAIコーディングが急速に発展し、書いた仕様が動くことが日々現実になっています。私自身も、AIコーディングでKubernetes Operatorをわずか4時間で実環境のテストまで完成させ、実運用に至りました。必要な機能だけをAIで実装し、CLAUDE.mdとSpecを残せば、誰も面倒を見なくなっても次の人がメンテできます。以前は自作がアンチパターンでしたが、今は自作しないことがアンチパターンかもしれません。 ではいつ自作し、いつOSSを使うべきか。本セッションでは「使う機能は何割か」「コミュニティは生きているか」「チームでメンテできるか」の3軸で、現場で使える判断フローと基準を共有します。

docker build したイメージを push したあとにコンテナレジストリの中身を覗いたことはありますか？ 実はあなたが何も設定しなくても「誰が・いつ・どうビルドしたか」を記録する Provenance が自動でイメージに同梱されていて、更にCI に数行足すだけで、SBOM や暗号署名も追加することができます。 これらを活用すれば、本番障害時に「このイメージはどの commit からビルドされたか」を CI ログを遡ることなく即座に特定でき、新たな CVE が公表された際には SBOM で影響するイメージを一括で把握できます。署名があれば「正規の CI を通っていないイメージはデプロイさせない」という運用も実現できます。 本セッションでは、イメージの内部構造の読み方、CI への署名導入手順、レジストリ内のメタデータ確認方法を実演を交えて解説します。 「自分の構築したイメージの安全性を自分の手で確認・強化できるようにしてコンテナイメージの運用をよりセキュアにしたい」という人にオススメです。

Observabilityは本番だけの話ではありません。サンエーでは、開発フェーズからDatadogを組み込み、“作りながら観測する”モダン開発を実践しています。 本セッションでは： • Datadog選定時に重視した技術要件 • Vibeコーディング時にパフォーマンス問題を即検知できた事例 • 小売特有のドメイン設計を反映したタグ戦略 をテーマに、リアルな知見をファイアーサイドチャット形式でお届けします。 SRE、Platform Engineer、アプリケーションエンジニア必見のセッションです。

自律実行AIエージェントがもたらす価値の裏で、新たなセキュリティリスクが生まれています。それは、エージェントに与えられた「ユーザー代理権限」の悪用です。 権限昇格されたAIエージェントは、もはやあなたの忠実な部下ではありません。組織の機密情報を盗み、内部システムを破壊する、最悪の侵入経路となり得ます。これは、AIエージェントを本番デプロイする全組織が直面する、避けては通れない課題です。 本セッションでは、Excessive Agencyというリスクに対し、AIエージェント開発において見逃されがちな「権限と認可」に焦点を当て、不適切なアクセスコントロールがもたらす脅威について取り上げます。 また、具体的な防御アーキテクチャとして、ReBAC（関係ベースのアクセス制御）による動的な権限管理やAIエージェントのための動的認可についてデモを交えて紹介します。

社内のナレッジマネジメントシステムをクラウドネイティブなコンテナ基盤へ移行した実践事例を公開！ 共有の心理的障壁を下げるリアクション機能や検索性を高めるタグ付け機能、生成AI連携による自動要約機能など、現場が「使いたくなる」工夫を紹介します。 インフラ組織の生産性を変える攻めのシステム刷新の全貌と、グローバルでノウハウを共有できる機能などさらなる発展を見据えた構想を開発の裏側と共にお届けします。

弊社組織では社内共通基盤のプラットフォームを構築しており、100個ほどのマイクロサービスが稼働しています。そしてこれらを200人のエンジニアで日々開発していて、弊社SREは15名でこのマイクロサービスの運用・問い合わせに対応していますが、こうした日々のタスクに追われて本来の目的あるSRE Enablingがなかなか進んでいません。その時間を捻出するため、我々はTry&Errorを繰り返しながら運用にAIを実装してきました。今回はそういった泥臭い実装例をお話したいと思います。 本セッションでは、以下のトピックについてお話します。AI活用に悩まれているSREの方に是非きいていただきたいです！ - Linear x Codex/Devinで全microserviceのTerraform Module updateを効率よく行う - AIによるレビューで200 PR/dayの50%は自動化 - 問い合わせ・トラブルシューティングをAIにやってもらうために必要なskills - Production Readiness Check(PRC)のEvidence確認もAIにやってもらおう

システムの疎結合化や重い処理の負荷分散などの目的で、ジョブキューが用いられます。ここで、素朴にキューサービスの前後のアプリケーションにトレースを計装するだけでは、トレースがキューサービスを跨げず途切れてしまうことがあります。 SLI/SLOの設計では、ユーザ体験に即したものであることが重要視されます。ユーザー目線で期待するレイテンシーで操作が行われているかを知るには、キュー内に滞留している時間も含めEnd-to-endで計測できる状態になっている必要があります。 今回は題材としてAmazon SQSを介した非同期処理・バッチ処理を取り挙げ、一連の処理を観測しやすくするOpenTelemetryトレースの計装方法をご紹介します。 - コンテキスト伝搬の仕組み - カスタムプロパゲーターの実装 - トレースのスパンリンクの活用 またこれを発展させ、End-to-endのレイテンシーをメトリックとして計測できるようにする手法も解説します。 ジョブキューやマイクロサービスを含むアーキテクチャにおいて、サービスを跨いだトレーシングやSLI計測に課題があると考える人向けのセッションです。

「PRのに応じて検証環境を柔軟に増やしたりしたいな」「検証環境アクセスまでのリードタイムが開発のボトルネックになる」このようなもどかしい経験を持ったことはないでしょうか？特に我々のように500名超規模の開発体制やAIでのコーディングスピードの上昇によって、結果的に検証環境がボトルネックになると感じることがしばしばあります。この課題を解決するため、PR単位でephemeralな検証環境を払い出す仕組みをArgoCD ApplicationSet とGithub Actions等を活用して構築しました。 構築の中で、開発者が本当に必要としているのか使ってもらえるのかを見極めるためにDBのスキーマ変更やWorkerの検証機能はスコープから外し、それ以外のWebアプリケーション機能だけに絞る意思決定をし、フィードバックを重視した開発を行いました。 本セッションではArgoCD ApplicationSetを活用したApplication生成パターン、PR作成のライフサイクルに連動して作られる検証環境のライフサイクル管理の実装、そして必要なものを作るための取捨選択についてお話しします。

「Cattle, not Pets」はKubernetesアプリ設計の常識ですが、その前提となる高可用性サービスに頼れないステートフルアプリ(Git/P4、CI・開発環境、レガシー等)は多くの組織に残っており、それらをVMから脱却させるにはK8sのReadWriteOnce(RWO) PV+シングルレプリカPodで「飼う」しかないケースがあります。 本講演ではこのトピックを掘り下げた次の内容をお話します。 ・Kompoxの紹介: マルチクラウドK8sアプリ運用ツール https://docs.kompox.dev/edge/ja/ ・K8sの宣言的管理・自動復旧・API駆動インフラを活用したcompose.yml中心のアプリ開発ワークフロー ・HPAやローリングアップデートと無縁なRPO≈0・SLO 99.9%の割り切った可用性設計 ・AKSにおけるRWOのAZ制約・デタッチ・スナップショット挙動の現実 ・CRD/Operator化とPaaS展開構想 K8sの能力をあえて使わないことがステートフルアプリ設計の現実解になり得ることを、汎用的な設計パターンとして持ち帰りいただけます。

Pairsチームでは、本番運用中のGoサービスにおいて、非cgroup-awareなコンテナ挙動に起因するCPUスロットリングの課題に継続的に向き合ってきました。Goランタイム・Linux・Kubernetesそれぞれのスケジューラの関係を踏まえつつ、NginxやHAProxyなど周辺ミドルウェアの特性も含めて検証と改善を重ねた結果、CPUスロットリングを大幅に低減し、コンテナの安定性とパフォーマンス、監視運用の精度を向上させました。 本セッションでは、GOMAXPROCS設定時にHAProxyがボトルネック化して障害が発生した実例、その解消プロセス、監視と設定強化、そしてGo 1.25のContainer-aware GOMAXPROCSを踏まえた安全な運用方針までを、実際の意思決定とトレードオフとともに共有します。 参加者が自環境で活用できるよう、CPUスロットリング関連メトリクスの見方と改善の進め方を具体的に持ち帰れる内容にします。

本セッションでは認証認可サーバー開発をユースケースに、クライアントサーバー間の複雑なリクエスト／レスポンスを再現するモックを実装し統合テストを自動化する、CI/CD実現に向けた取り組みを共有します。 クラウドネイティブな開発プロセスではテストを自動化し、CI/CDパイプラインへ組み込むことが重要です。中でも統合テストでは外部接続を検証するためにモックサーバーを使用するケースがありますが、一般的なオープンソースのモックサーバーはリクエストを受けてレスポンスを返す用途が中心で、モック自身がリクエストを送信するケースは少なく、認証認可のようにサーバー間で複数回の通信が発生するシナリオを十分に再現できないことがあります。 そこで、SpringBootを用いてステートフルな通信を再現し、テスト可能なモックを実装。テストシナリオはOpenAPIライクなYAML形式で定義し、生成AIを活用した高速なテストコード作成とも親和性の高い仕組みを実現しました。 デモンストレーションとして生成AIを用いたテストコード作成から、Dockerでの環境構築とテスト実施まで紹介します。

クラウドネイティブなデータベースへの進化の歴史は、そのまま「分散システムにおける物理制約との戦い」であり、スケーラブルなシステム設計の最高の教科書です。 従来のRDBMSはコンピュートとストレージの密結合が限界を生んでいました。これを打開したAmazon Auroraは、「THE LOG IS THE DATABASE」の思想で分離でスケーラビリティを、 Google SpannerやNewSQLは、TrueTime APIやPaxos/Raftの分散合意アルゴリズムで分散環境の強整合性を獲得し、トレードオフとしてレイテンシーを犠牲にしました。 個別の要素技術や論文は知られていても、「どのような課題を乗り越え、結果としてどのようなトレードオフを選び現在に至ったのか」という全体像は意外にも体系化されていません。 本セッションでは点在する論文や技術仕様を線で繋ぎ合わせ、巨大な分散システムがいかに物理制約を克服してきたかDeep Diveします。「なぜスケールし、何を犠牲にするのか」この理解はDB選定の枠を超え、マイクロサービス等あらゆる分散システム設計の指針となるはずです。

「またコンテナの話、しようか」——2018年に『コンテナ・ベース・オーケストレーション』（翔泳社）を共著してから8年、一人はIBMでObservabilityを、もう一人は雪国でGPUデータセンターを作っていた。2025年に再会した2人は、本物のコンテナ（型データセンター）の中にいた。 新潟県湯沢町のコンテナ型データセンターにNVIDIA H100（空冷）、H200・B200各8基（液冷）を収容し、Rancher K8sでGPUクラスターを構成。地下水（井水）による液冷で業界最高水準のエネルギー効率を目指します。 NVIDIA DCGMとOpenTelemetryを使ってGPUの可視化はInstanaで本番運用稼働中。Schneider Electric in-row冷却のSNMP MIBから風量を取得しGPU温度とOpenTelemetry Collectorで繋ぐことに挑戦中。液冷はPoC準備中。実績と途中経過を正直に共有。DCGM・SNMP×OTelの設計判断と失敗を持ち帰れます。登壇資料は公開予定。 SRE・インフラエンジニア・Platform Engineerを対象。

CloudNative の普及により、Kubernetes をはじめとするコンテナ基盤を本番環境で運用するチームが増えてきました。しかしその一方で、従来の境界防御を前提としたセキュリティ設計はこうした環境ではうまく機能しません。 ワークロードは動的に生成・破棄され、内部通信も信頼できず、どこから守るべきかを判断できない状態に陥りがちです。その結果、対策は増えていくのに設計だけが複雑化していきます。 本セッションでは、SaaS アーキテクチャを例に Kubernetes 環境の脅威モデリングを段階的に実践します。STRIDE フレームワークによる脅威の洗い出し、リスクアセスメントによる対策の優先順位決定、そしてその結果を具体的な設計にどう落とし込むかまでの一連のプロセスを紹介します。

生成AIは驚異的な速度でコードを書きます。しかし同時に、驚異的な速度で車輪を再発明してもいます。重複したロジック、冗長なインフラ、散在するナレッジ ― 生産性が上がるほど、組織のどこかに静かに積み上がるものがあります。それを技術的負債にするか、共創の起点にするかは仕組みと文化の問題です。世界中の企業のInnerSource導入から見えてきた、AI時代に「増やさない力」を育てるためのヒントをお伝えします。

イオングループのDXをリードする役割を持つイオンスマートテクノロジーでは、iAEONアプリやネットスーパーを通じたお客様のお買い物体験の向上や店舗業務のDXを推進・展開しております。 そんな当社で私は1人目SREとして入社して以来SREを組織にインストールすることを続けています。その取り組みの先にあったのは、開発組織のトポロジーそのものの変化です。従来存在していた横断的な運用チームは役割を終え、開発組織の構造が書き換えられていきました。 本セッションでは、その変化がどのように起きたのかを振り返り、得た実践知をみなさまと共有し解説します。 本セッションが、これからSREを立ち上げる方や取り組みに悩まれている方々への参考になれば幸いです。

インフラエンジニア、DevOpsエンジニア、SREなど呼び方は様々ですが、サイボウズにも、製品開発が利用する開発環境や、お客様に提供する本番環境の基盤を支えるチームがあります。私たちは、その基盤の、開発、運用、保守、そして信頼性向上に力を注いできました。基盤の安定性や運用には長年の経験がありましたが、組織全体の取り組みや事業インパクトの高い活動に対して、組織として十分に接続できていませんでした。 サイボウズの開発は、2024年から組織全体でよりインパクトの高い活動ができるよう、「アラインメント強化」というテーマを掲げてきました。我々のチームも、従来の受け身な体制から、役割を再定義してより社内利用者や事業への意識を持てるように、「プラットフォームエンジニアリング部」を立ち上げました。 このセッションでは、サイボウズの開発組織とプラットフォームエンジニアリング部の立ち上げについて紹介します。EMの立場から、事業・組織とプラットフォームエンジニアリング部のアラインメントをどのように強化したか、その具体的な取り組みと成果について共有します。

生成AIの活用により、コードやIaCの生成は加速し、変更量は増加しています。しかし変更が増えるほど、信頼性を安定的に維持する難易度も高まります。レビューやチェックリストに基づく確認は人の認知やコミュニケーションに依存しやすく、変更が継続的に増える環境では確認コストの増大やレビューの集中につながり、信頼性リスクが埋もれやすくなります。 本セッションでは、Production Readiness ChecklistやSecurity Checklistなどの組織ポリシーのうち静的に評価可能な項目を抽出し、Policy as CodeとしてCIや実環境に組み込むことで、信頼性を人の認知に過度に依存せず保ち続ける設計と、その実践の現在地を共有します。開発者が常にポリシーを強く意識しなくても、自然と組織ポリシーを満たす状態に近づく構造をどのように設計してきたのか。ConftestやKyvernoを用いた実装例に加え、誤検知との向き合い方、ポリシーの強度設計、既存リソースの是正方針など、形骸化せず機能し続けるガードレールを実現するための工夫を紹介します。

プラットフォームエンジニアリングは、2022年ごろからDevOpsの次のアプローチとして注目を集めてきました。調査では、2026年までに大企業の80%がプラットフォームエンジニアリングの取り組みを開始すると予測されています。しかし実際には、「プラットフォームチームを作ったが誰も使わない」「ツールを導入したが定着しない」といった失敗が後を絶ちません。 失敗の多くは、本質を理解しないまま取り組みを始めてしまうことが原因です。プラットフォームエンジニアリングとは単なるツール導入ではなく、開発者の認知負荷を下げ、組織全体の能力を高める仕組みづくりです。その考え方は、Webサービス企業だけのものではありません。製造業をはじめとする日本全国の企業においても、DXの推進や内製化の加速に不可欠なアプローチとして広がっています。 本セッションでは、プラットフォームエンジニアリングとは何か、なぜ今あらゆる業種・規模の組織に必要なのかを基礎から解説します。小さく始めるための具体的なステップや、AI時代における重要性の変化についてもお話しします。これから取り組みたい方にとって最初の一歩となるセッションです。

自律化が進む現代でSREとして現場に向き合う中で、私はSREの価値は「壊れないシステムを作ること」だけでは不十分になりつつあると感じるようになりました。 では、いまSREの価値はどこにあるのでしょうか。 本セッションでは、CloudNativeを「変化と劣化を前提とした設計思想」と捉え直し、SREがどの立場で関わり、どこまで責任を引き受けるべきかを考えます。 AIによってシステムの自律化が進む時代に、人が引き受けるべき「責任」と「判断」とは何か。 実体験をもとに、AI時代におけるSREの価値を考えます。

「将来必要だが、今作るべきか？」——。Platform Engineeringの立ち上げにおいて、開発者ポータルの導入時期は常に議論の的となります。特にリソースやスキルセットに制約がある日本のエンタープライズ環境では、その構築・運用コストが大きな懸念となりがちです。 しかし、複雑な組織構造やサイロ化したプロセスを抱える大企業こそ、初期から「プラットフォームの顔」を定義することに真の価値があります。本セッションではBackstageなどの導入事例を交えつつ、開発者ポータルを単なる「ツール」ではなく「変革の旗印」として活用する方法を語ります。 ・認知負荷の削減: 散在するExcel申請やWikiを統合し、開発者の迷いを消す ・セルフサービスへの転換: 組織の壁を越え、ボタン一つで「標準」を手に入れる体験 ・現実的な導入ステップ: 運用不安を解消し、スモールスタートから波及させる戦略 日本企業ならではの地に足のついた組織変革と、開発者ポータルが果たすべき真の役割を明確にします。

Coding Agentの普及により開発速度が向上する一方、Platform側にはAI特有の「予測不能かつ大量の変更」を受容する強力なガードレール設計が求められています。 本セッションでは、データアプリケーション開発向けIDPの実例から、攻め（生産性）と守り（統制）を両立する実践的プラクティスを解説します。 ・Repo,CI/CD: アプリ/基盤層分離と、自律的変更を安全に届けるGitOpsパイプライン ・Test: 欠陥予防（Shift Left）と本番実トラフィックでの検証（Shift Right）の統合 ・Observability: AIによる副作用の早期検知と根本原因特定を担うFull-stack Observability しかしこれだけ強固に実装しても...障害は発生します！Agentもガードレールも銀の弾丸ではありません。実際の障害事例を交え、完璧な統制を盲信するのではなく「Platform as a Product」の思想のもと、Human in the LoopによるAIとの協調やガードレール自体の継続的改善にどう向き合うべきか、リアルな運用知見を共有します。

我々のプロダクトではジムや介護施設などの現場にカメラとエッジデバイスを設置し、AIによる混雑分析や危険検知ソリューションを提供しています。 事業急拡大に伴うデバイス台数の増加に対し、従来のエッジ環境の監視・運用手法では限界が見えていました。 そこで、クラウド環境で活用を検討していたNew Relicをエッジデバイスへと展開しました。 ネットワーク不安定化によるデータ欠損や、デバイス停止といったエッジデバイス特有の課題に対し、監視の徹底による早期検知と自動リカバリの仕組みを段階的に構築しました。 現在は、1,700台を超えるエッジデバイスを安定運用しながら、開発チームが本来の責務である新機能開発に集中できる体制を実現しています。 本講演では、この半年間の試行錯誤の軌跡と、監視強化/運用自動化によってチームの働き方がどう進化したかをお話しします。

「わたしがやっていることは、果たしてSREと呼べることなのだろうか？」 インフラのコード化やサーバーの構築・運用を日々こなしながらも、どこかアプリ開発やプロダクトの信頼性から切り離されているような感覚を、わたしは抱いていました。 そんな折、わたしたちのチームでは、突発的なDBの高負荷をきっかけに、負荷試験・速度改善の取り組みを始めることに。 エンタープライズ向けの監視ツールはありませんでしたが、そこは「あるものでやる。ないものは作る。」 Pythonライブラリの「Locust」でテストを作り、Google Cloud APIを叩く独自のスクリプトを書いてメトリクスとログを抽出する、自前の試験実行・結果確認の仕組みを構築しました。 生成AIの力も借りつつ結果を分析する中で、オブザーバビリティが上がっていき、アプリ開発やプロダクトの信頼性(SRE)との距離も縮まりました。 本セッションでは、負荷試験を通じて「積み上げ式」にオブザーバビリティを構築し、システムの「コンテキスト」をエンジニアリングし続ける、その活動から得られた知見とノウハウを共有します。

「挑戦するエンジニアのプラットフォームをつくる」をビジョンに掲げるファインディでは、2025年以降の急激なプロダクト増加に伴い、Enablingの実践や、複数サービスを横断するログ管理と運用のスケールが急務となりました。 本セッションでは、複数サービス間に散在するログを統一・集約するために実施したアーキテクチャ選定の裏側を公開。AWS OrganizationsとCloudWatch LogsのCentralizationを活用した統制の取れたログ集約設計に加え、CloudWatch Unified Data Managementを用いてAmazon S3 Tablesへログを統合し、Grafanaで可視化するモダンなログ分析基盤の構築について解説します。 「マルチプロダクト環境におけるログ基盤のアーキテクチャをどう設計すべきか」とお悩みの方に、明日からのシステム構築や組織づくりに活かせるヒントをご紹介します。

検出・調査・修復を自動化するAI SREの考え方は、パフォーマンスエンジニアリングにも有効です。AIワークロードは、予測不能なリクエストと巨大な計算コストが直結する推論、パラメータの組み合わせ爆発が性能を支配する学習、いずれも従来のSREの常識が通用しない課題を抱えています。本セッションではこれらの課題を概観した上で、自動プロファイリング・ボトルネック検出・改善・検証のサイクルを自律的に回すパフォーマンスエンジニアリングの実践アプローチをデモを交えて紹介します。

「Backstageの準備は万端。認証はKeycloakでバッチリ…って、BackstageにKeycloak用のプロバイダーがない！？」 そんな驚きから、私のコントリビュート物語は始まりました。 プラットフォームエンジニアリングの中核を担うBackstageと、クラウドネイティブなIAM標準であるKeycloak。共にCNCF Incubatingであり、この組み合わせは定石ですが、標準連携機能がないことで現場は個別の実装を強いられてきました。両者がシームレスに繋がれば、CNCFエコシステムの自然な連携が促進されるのは勿論、プラットフォームチームは煩雑な認証実装から解放され、本質的な価値提供に専念できます。 本講演では、この溝を埋めるべく開発した「Keycloak Auth Providerプラグイン」を題材に、Backstage拡張の技術的知見はもちろん、コントリビュートに興味はあるが一歩踏み出せずにいる皆さんにその意義や実践的なTipsを共有します。日々の業務課題をコミュニティ貢献へと繋げ、最初の一歩を踏み出すためのヒントをお届けします。

「セキュリティ更新を急いで適用したい。でも、勝手に変えて本番環境を壊したくない。」 エンタープライズのプラットフォーム運用では、「強制アップデート」と「チームの自律」の衝突が避けられません。統制が厳しい環境では影響確認・メンテナンス調整により「変更しづらい／変更できない期間」が発生し、更新の待ち行列が生まれます。これは単なる自動化で解決できる問題ではなく、環境ごとに変更可能タイミングが異なるという構造の問題です。 当社ではAWS Control Tower環境でセキュリティ共通製品をService Catalogで提供しています。当初はフルサービス型で一括更新していましたが、テナント数の増加に伴い待ち行列が膨らみ、改善サイクルも停滞しました。そこで「世代管理と責任分界」を上乗せし、管理アカウントへの強制アップデートとテナントのセルフサービス更新を使い分ける「ハイブリッド運用」に辿り着きました。 本セッションでは、運用モデルの意思決定、更新を回すCI/CDとカタログ運用の仕組み、そして単一世代提供の失敗から得た教訓を共有します。

# 概要 障害訓練やってますか？ やりたいですか？ やりましょう。メリットしかないです。 弊社ではHWを扱ったプロダクトを提供している関係で、障害発生時のトラブルシューティングは困難を極めます。 どれだけ時間をかけて設計しても穴はあります。想定外のことは発生します。 メンバーのスキル差は様々です。いつ何時なにが発生するかわかりません。 物理からクラウド、そして人災まで、あらゆる障害や問題に対処するための訓練を日頃から行っています。 まだまだ試行錯誤の最中ではありますが、おおむね1年以上の運用における現在の整理とこれからについてご紹介します。 # 対象者 ・複数のプロダクト/複数カテゴリにまたがるサービスを提供しているスタートアップのエンジニア ・Opsを意識し出したエンジニア # ざっくり内容 ・ビットキーでなぜ障害訓練が必要であったか / そのキッカケや理由 ・障害訓練とは？ 障害訓練の効能 ・ビットキーにおける障害訓練の運用例 ・便利なツール群 / なぜ我々はそれを使わなかったか

工場IoT管制センターは、デンソー全拠点が使うIoT基盤・アプリ・仮想インフラ・NW（VM払い出し120件/年）を一元運用する組織です。これまで、開発チームが「付加価値のない作業だけでも自動化して渡そう」としてきた結果、Ansible＋GitLab CIやTerraform＋手動SSH Applyと自動/手動のまだら作業が雪だるま式に増え、理解・維持が属人化、増え続ける申請対応に苦しんでいました。 私たちは、若手4名中心のクロスチームで、MVPとして「VM払い出しフローをE2E棚卸し→GitLab CI＋Terraform/Ansibleへ統一」から取組み、手動SSHゼロ化とリードタイム40％短縮の成功を足がかりに、残り50超のアイテムを「開発チームからの依頼を集約・対応する“セルフサービスの運用プラットフォーム”」として開発するロードマップを策定。再び属人化させないため、アジャイル＋ペアプロを“仕事の型”として、スキル移転が自ずと進む開発の進め方を徹底。 半年でMVP本番ローンチ、3か月後には若手自走し、課題形成から技術習得・横展開できるマインドへ転換させたステップを共有します。

開発チームが開発に集中できる基盤を提供するPlatform Engineeringにおいて、基盤を支える「情報レイヤー」の存在は欠かせません。当社ではこの情報レイヤーをCMDBとしてスクラッチで開発しています。 スクラッチ開発の柔軟性を活かし、プロダクト情報やAWSリソースの構成情報、チーム・ドメイン・GitHubリポジトリの管理に加え、ECR・VMDR・WASの脆弱性管理、SBOM、EOL管理、開発環境の起動停止スケジューリング、AWS Sandbox環境の自動構築など、組織に必要な情報と機能を一元的に集約しています。 さらにCMDBは単体で完結せず、PEチームが提供する他システムへの情報連携の起点となっています。生成AIを活用した根本原因分析ツール（RCA）にはシステムのARN情報やログ基盤情報、担当チームの通知先を提供し、インシデント管理ツールにはシステム構成情報を連携してトポロジー表示に活用しています。 本セッションでは、Platform Engineeringを支える情報基盤としてのCMDBの紹介と、各システムにおける情報の活用事例、そして今後の展望をお話しします。

市場にはDatadogをはじめ優れたインシデント管理ツールが数多く存在します。しかし現場の真のボトルネックはツールではなく、複数インシデントを同時にさばく多忙なマネージャー、チームに埋もれた暗黙知、属人的な意思決定プロセスといった「人間系のダイナミクス」にあります。 SIGQが構築したIncident Lakeは、エンジニアを置き換えるのではなく、組織に散在する暗黙知を構造化し、分散したオペレーションシグナルを統合することで、マネージャーの一貫性ある意思決定を支援するインテリジェンスレイヤーです。LLM推論とRAGを活用した組織メモリにより、認知負荷を大幅に軽減します。 本セッションでは、既存ワークフローへのAIエージェント統合手法、運用知識を捕捉するアーキテクチャパターン、LLMハルシネーション対策、MTTR改善の実績を紹介します。AIを「ICのツール」ではなく「組織の意思決定を増幅する仕組み」として活用するアプローチを持ち帰っていただけます。

様々なAIツールが群雄割拠する昨今、GMOペパボ社内でも Gemini や Claude を始めとする AI ツールが急速に普及しています。講演者も AI エージェントを活用して業務を行っていますが、AI をさらに活用できないかと日々考えています。 昨今、Ambient Agent という概念が知られ始めました。これは「AI が人間の指示を待つことなく自律的に稼働する」という性質のものです。 この Ambient Agent を実現するためのピースを、自作のプラットフォームを構築することにより実現しました。 本講演では、Ambient Agentic Workflow を実現するために必要な要素の分解と、それぞれの要素を実現する手法の提案、さらに手法を実装したプラットフォームの具体的な技術要素と社内へのプラットフォーム普及事例をすべて紹介いたします。 以下のような方々に聞いていただけると幸いです。 - AI エージェント活用による生産性を一段階上げたいと考えている - 全社的なエージェントの普及ができず困っている - 個々人のAI活用レベルに差ができて困っている

「コピペを減らそう」という善意で作り始めたTerraformモジュールが、数ヶ月後には「誰も触りたくない魔境」に変わっていませんか？大量の variable や複雑な count ブロック。私たちは「将来の変更を楽にする」はずが、実際には「実装を理解するための重いコンテキスト」を未来に強いているだけかもしれません。 本セッションでは、魔境化の主因を「テンプレート（共通化）」と「カプセル化（隠蔽）」の混同にあると定義し、以下の設計指針を提示します。 ホワイトボックス・テンプレート（共通化）： 透過性を重視し、クラウド仕様を隠さない設計 ブラックボックス・コンポーネント（隠蔽）： 異なるチームの利用者に「意図」のみを伝える設計 「トポロジーを動的に変えてはいけない」など、明日からチームで使える論理的な設計判断を提供します。 【ターゲット】 - 自作モジュールのメンテに疲弊している方 - dynamic や countの乱用に論理的な「待った」をかけたい方

「問い合わせ対応だけじゃなく、信頼性にも関わりたい！」 これはマネーフォワードのCREが直面した切実な思いです。 問い合わせフローの整備や自動化といった日々の「守り」を極める一方で、システム根幹の信頼性を高めていきたいと思うようになりました。 現在はSRE活動を取り入れた「NEXT CRE」へ進化するべく、泥臭い挑戦の真っ只中です。 SLO/CUJの策定やDatadogでの可観測性標準化に加え、注力したのが「パフォーマンスチューニングの民主化」です。 高度な専門性が求められ属人化しがちなボトルネックに対し、AIとRSpecを掛け合わせたアプローチを導入。誰もが容易にパフォーマンス改善に取り組める環境を構築しました。 同時に、AIを活用した問い合わせ対応の効率化も推し進め、SRE活動へ注力するためのリソースを自ら創出しています。 運用中心のチームがゼロからSREに踏み出すとき、何から着手し、どんな壁にぶつかるのか？「今の枠を越えて面白いことがしたい」とくすぶるエンジニアの皆様へ、明日からの実践のヒントになるリアルな軌跡を持ち帰っていただければと思います。

Platform Engineeringの取り組みは増えていますが、実際には小規模な改善活動に留まり、組織全体の変革にまで至らないケースも少なくありません。規模が大きくなるほど、プラットフォームチームは各部署から様々な期待や課題を引き受ける存在となり、スコープが拡散してしまうリスクがあります。本セッションでは、複数のモダナイゼーション支援事例をもとに、Platform Engineeringが組織に飲み込まれる構造を整理します。その上で、プラットフォーム実装、アーキテクチャ戦略、レガシー刷新の責任境界を明確に分離するスコープ設計思想を紹介し、プラットフォームを組織の資産として残すための実践的な方法を共有します。Platform Engineeringをスケールさせたいエンジニア、アーキテクト、技術リーダーにとって、ゴール設計と責任境界を見直すための視点を提供します。

デプロイ時にPodがUnhealthyとなり、一時的にサービスが利用不可となる障害が発生しました。原因はオンラインDDLと長時間SQLの競合によるMySQLメタデータロック待機です。 本セッションでは、障害の再発防止に向けたアプリ側との対話とガードレール構築の取り組みを解説します。 対話では、安全重視のlock_wait_timeoutを提案するSREと、マイグレーションの成功率を重視する開発者の議論を経て、着地点を見出す過程を説明します。また高負荷プロダクトの有識者を交え、リスクの高い変更を判定するための基準を定量化した背景も共有します。 こうした基準を定めても、知見が点在し風化しては再発を防げません。そこで、AIで情報を整理しBackstageへ集約することで、開発者が迷わずにルールを参照できる環境を整えました。さらにGitHub Actionsを活用し、スキーマ変更が検知された際にプルリクエストへ自動で警告を掲示するガードレールを実装しました。 開発者に過度な意識を強いることなく、安全な道へ自然に誘導する開発者体験と信頼性を両立させるための実践的な仕組みを共有します。

マイクロサービスアーキテクチャは各サービスの独立性によりスピーディな開発を可能にします。 しかし現実には、言語ランタイムEoL対応やCVEセキュリティ対応、リリース承認取得などがサービスの数だけ繰り返し発生し、本質的な新規開発の工数を逼迫させることがあります。筆者もクラウドネイティブ開発の支援で、この何度も発生する重たい定型作業によってやりたい開発がしにくくなる状況に何度も直面しもどかしい思いをしてきました。 この課題こそPlatform Engineeringが解決すべき領域です。 「SREで自動化すればいいのでは？」と思うかもしれませんが、SREはエンドユーザー目線で信頼性を担う活動であり、開発者目線で開発体験を向上させるPEの方が効果的なことがあります。 また「PEってk8sありきでしょ？GAFAのような先進的な大企業やイケてるメガベンチャーの話では？」と思われがちですが、k8sがなくても同じ考え方を適用できます。 本セッションでは、「PEは自分たちとは違う世界の話だ」と思っている方にPEをより身近に感じてもらえるよう、今日から始められる初歩的なアプローチや考え方を共有します。

現在hacomonoはアプリ量産によって事業拡大を狙っており、私のチームではKubernetesを利用したGitOpsベースのSelf-service基盤を構築することでアプリ開発支援に挑戦しています。 しかしGitOpsで扱いづらいマネージドサービスの扱いに課題を感じていました。 そこでCrossplaneを採用し、あらゆるリソースをカスタムリソースに抽象化することでGitOpsで完結する基盤を目指しました。 これにより複数のIaCを使って数百行記述する必要のあったリソースが数~数十行のmanifestで扱えるようになりました。 一方、Crossplaneの運用負荷/学習コストが高いことや、抽象化に時間がかかること、抽象化による柔軟性の低下等の新たな課題も感じています。 本セッションではCrossplaneを採用するに至った背景や、実際に運用して感じたメリデメ、抽象化によって得られるものと失うもの等を実体験に基づいて共有します。 Kubernetesとマネージドサービスとの連携に課題を感じている方やCrossplaneの導入を検討している方等に知見を提供します。

我々は必要のないことに時間をかけてないか？と疑問を持ったのは、CSに「解約の原因はエラーレートではなく機能不足です」と言われたときでした。 SREもDevも時間は有限です。Devチーム数がSRE数を超えると、SREが平等にリソースを割くのは難しくなります。 GoogleのProduct-Focused Reliability for SREでは「ビジネスやユーザーにとって最も重要なことに焦点を当て、優先順位を付ける」と提唱しています。精度の高いSLOは優先度を決定でき、それがリソース最適化に寄与します。 この理論に加え、SREとDevが別々のSLOに責任を持つことで同じ目標を共有する組織設計論を話します。組織が大きくなると発生する、受託のような関係を回避しつつ、SREもDevも互いに本番環境に対してバランスを取れる状態が、今後求められる姿です。 本セッションでは、理論について話しつつ ・精度の高いSLOとは ・複数SLOでSREもDevも責任共有する状態とは ・SREが支援係になりすぎないようにするには 3年以上にわたり運用してきたCUJテンプレートと実際のSLO例も共有します。

「夜寝ているとき、アラートで起こされたけど一瞬閾値を越えただけで特に起きる必要はなかった」 「とにかく大量のアラート通知・エラー通知が届いて疲れてしまった」 開発・運用していてこのような経験はありますか？スピーカーはあります。本セッションでは改めて「アラート通知」について考えます。 1.通知の進化を振り返る 何を監視し何を通知するか、進化の系譜について整理します。また、それぞれの監視・通知手法をどう使うかについても触れます。 2.通知、難しい スピーカーが関わっているシステムを例に挙げ、通知の難しさについて整理します。例えば、マルチテナントSaaSにおける通知であったり、多すぎる通知について紹介します。 3.通知を再設計する アラート通知に疲れている聴講者が持ち帰って活用できそうなアクションについて整理します。例えば、通知からログやダッシュボードへの切り替えであったり、通知に含める内容、通知の掃除について紹介します。 現代では「アラート通知」はエンジニアにとって身近であることが多いものだと思います。通知について改めて学ぶことで、自分やチームの負荷を減らし、システムを健康