Schedule

7/10 11:35 - 12:05

GitHub Actions runnerの運用から見るニンテンドーシステムズのチーム体制

ニンテンドーシステムズでは、社内向けに共有の GitHub Actions self-hosted runner 基盤を運用しています。社内の GitHub Enterprise Server と連携し、コードのビルドはもちろん、PR の AI レビュー、Confluence, Jiraの自動更新、Terraform の PR コメントなど多岐にわたる用途で日々利用されており、平日1日あたり約2万ジョブ、月間で50万ジョブを超える規模で稼働しています。 しかしこの基盤を運用しているのは、専任の CI/CD プラットフォームチームではありません。 それぞれが別のサービスをメインで担当する3名のメンバーが、 SRE 職と開発職の垣根を越えて兼務で運用してきました。 さらに特徴的なのは、その成り立ちです。 トップダウンで設計された基盤ではなく、各プロダクトチームの現場で生まれた「より良い CI/CD 基盤がほしい」という要望に有志が応える形で立ち上がり、結果としてニンテンドーシステムズ全体で使われる横断基盤に育ちました。 本セッションでは、Actions Runner Controller(scale-set), EKS, Karpenter, Datadog, HCP Terraform で構成されるこの基盤の概要に手短に触れたあと、3名で月50万ジョブ規模を捌くために採っている「細く長く」の運用ポリシーについてお話しします。 あわせて、この体制で得られているメリットと避けられないデメリットの両面を、運用エピソードを交えて紹介します。 専任チームを立てるべきか悩んでいる方、少人数で CI/CD 基盤を回している方、現場発のプラットフォーム活動をどう持続させるか考えている方のご参考になれば幸いです。

7/10 12:20 - 12:35

何でも屋からの脱却。SREとCTO室の役割を再定義し、本来のSRE業務を取り戻すまでの道のり

元々、社内唯一の技術横断チームだったSREチームは、本来のインフラ・信頼性領域を超え、機能開発チームからこぼれるあらゆるタスクを引き受け、いつしか何でも屋となっていました。その後、アプリケーション領域の技術的負債解消を目的にCTO室が設立されました。しかし、両チームの役割は「インフラ寄りはSRE、アプリ寄りはCTO室」という暗黙の分担にとどまっており、以下のような課題が解消されないままになっていました。・SREが本来注力すべき信頼性向上やインフラ基盤整備にリソースを割けない ・機能開発チームから見て、誰に何を相談すれば良いかがわからない ・改善活動が個別最適に留まってしまう 本セッションでは、この状況を打開するために行った役割再定義の実践を共有します。具体的にお話しするトピックは以下の通りです。 ・両チームのミッションとやらないことの言語化 ・機能開発チームから見た、依頼先判断基準の明確化 ・既存タスクの移管プロセスと、体制が整うまでの暫定対応の設計 ・SREの注力プロジェクトの再定義 気づけばSREが何でも屋になっているという多くの組織が抱える課題に対し、別の技術横断組織とどう健全な役割分担を築いていくかについてお話します。

7/10 12:20 - 12:35

Embedded SREに共に達成した会員管理システムのAWS移行

2025年4月から約9か月の期間をかけて、ニフティの会員管理システム・認証システムへのAWS移行を実施いたしました。本プロジェクトの特徴として、新設された社内SREチームから1名をプロジェクトに迎え入れたことが挙げられます。大規模システムのAWS移行に関する知見が限られていた中、インフラ設計やオブザーバビリティ整備をSREエンジニアに担ってもらうで、アプリケーション部分の移行に集中しながらプロジェクトを推進することができました。本セッションでは、具体的にどのような形でSREエンジニアに参画してもらって、プロジェクトを進めていったかを振り返りながらお話しいたします。 こんな方におすすめ ・開発チームがSREエンジニアに期待する振る舞いに興味がある方 ・SREエンジニアに参画してもらうか悩んでいるアプリケーションチームの方 ・大規模移行にSREエンジニアが参画することによる効果を知りたい方 こんなことが知れます ・インフラ・オブザーバビリティ整備をアプリ移行と並走させるための進め方 ・大規模AWS移行においてSREエンジニアが介在することで防げた課題・リスク ・開発チームとSREチームが連携する上でぶつかった壁とその乗り越え方

7/10 12:20 - 12:35

SREチームのリビルドと信頼性を広げる中長期戦略

ABEMA の SRE チームでは、2025年10月に体制を見直し、ミッション・ビジョン・バリューを再定義した。背景には、SRE の担当領域が限定的になり、他チームとの接点や組織内で残せる価値が小さくなっていたという課題がある。一方で、OTT サービスにおいて「見たいコンテンツをいつでも、どこでも楽しめること」は重要な価値であり、それを支える信頼性はサービスの競争力そのものでもある。本発表では、SRE チームのリビルドと、中長期の信頼性戦略について紹介する。リビルド後の半年間では、まず信頼性を改善するための土台としてオブザーバビリティの推進に取り組み、Datadog をバックエンド領域に浸透させた。ここでは具体的にどのようにイネーブリングしたか、また、30時間テレビに向けた負荷対策においても、可観測性を活用してボトルネックの把握や改善につなげた事例を紹介する。 加えて、SLI/SLO の導入や RUM を起点としたクライアント領域への拡大など、現在進行形の取り組みにも触れる。これらを通じて見えてきたマイクロサービスにおける信頼性課題を踏まえ、最終的に各チームが自律的に適切な信頼性を実現できる組織を目指すための今後の戦略を共有する。

7/10 13:00 - 13:30

AI-native時代の信頼性を育てる、インシデント学習と改善ループの実践

生成AIの導入によって開発速度とリリース回数が大きく増える中、サービスにはこれまで以上に多くの変更が加わり、インシデントが発生するリスクも高まっています。こうした環境では、インシデントを適切に収束させるだけでなく、そこから得た学びを継続的に改善へつなげることがこれまで以上に重要になります。しかし現実には、改善の必要性が見えていても優先度が上がらず、機能実装が先に進むことで、同種の問題が繰り返されやすいという課題があります。 本発表では、メルカリで進めている AI Native Incident Management の実践をもとに、インシデント対応、ポストモーテム、リスク評価、改善への反映をひとつのフィードバックループとして捉え直す取り組みを扱います。具体的には、AI を用いた状況整理、レポーティング、ポストモーテム作成、類似事例分析を通じて、対応中と収束後の知見をどう蓄積し、バグ修正、アーキテクチャ改善、運用ルールや監視の見直し、優先度判断への反映などにつなげているかをお話しします。 この発表で伝えたいのは、AI がすべてを自動化してくれる未来像ではありません。むしろ AI-native 時代だからこそ、インシデントから学び、何が本当にリスクなのかを評価し、その学びを次の変更と改善に活かすという“当たり前のこと”を、より速く、より継続的に、そして必要に応じて丁寧に深掘りできる形で回していくことが重要だという点です。実際の取り組みと現場の実体験を通じて、AI-native 時代の信頼性を支えるフィードバックループをどう設計し、どう育てていくかをお話しします。

7/10 13:00 - 13:30

事業価値を生み出すSREへ ー SREが担うべき意思決定の5層

AIがコードを書き、トイルを解消していく。ソフトウェアエンジニアとしてのSREの仕事はなくなるのか。そう感じている人は多いはずです。しかし、実際のデータはもっと厄介なことを示しています。SRE Report 2026では51%がトイル削減を実感できておらず、Faros AIの実測ではAI高採用チームのPR数が倍増する一方、業績との相関は見られません。つまり、AIのアウトプットは会社の価値に直結していないと言えます。なぜそうなるのか、どうAIを扱っていくべきなのか——それがSREのキャリアの問いでもあります。このセッションは、その問いを抱えているSREとそのリーダーに向けています。 私はSRE組織を支援する会社の経営に携わり、多くの商談で顧客の課題を聞き続けてきました。その中で気づいたことが、SREへの投資が続くケースと続かないケースの違いです。 その違いは、経営の要求を言語化し、自分たちの活動と接続できているかどうかです。AIが実行コストを下げるほど、技術的な活動量による価値証明は通じにくくなります。この変化は現場からは見えにくく、経営側と直接向き合う立場から見えてきたことでもあります。 その変化に対応するための5層の意思決定フレームワークを紹介します。経営目標を理解し、達成指標を設定し、施策を判断・決定し、AIの実行を監視・承認し、経営にコミットし続ける。技術指標は実行の証明に過ぎず、達成指標があって初めて経営言語に翻訳できます。各層について、支援現場から見えてきた実践の一端も共有します。

7/10 13:00 - 13:30

テクニカルプロジェクトマネージャーとSREが協働して構築する信頼性

SREというと「SREエンジニアが技術的に整備するもの」というイメージを持たれがちです。しかし、組織として信頼性を継続的に高めていくには、SRE以外の力が必要な場面が数多くあります。 私は LayerX でテクニカルプロジェクトマネージャー（TPM）を担っており、エンタープライズ向けAIプラットフォーム「Ai Workforce」をお客様に提供する際の、技術的なプロジェクト責任者として運用に携わっていますがSREとも協働してお客様とのクライアントフェーシングな業務やサービスの安定運用のための活動をしています。 本セッションでは、サービスレベル設計へのTPMの関与、トイル削減のプロジェクト、SWEも交えた運用全体での協働を通じて、『SREを組織でやる』とはどういうことかを具体的にお伝えします。

7/10 13:45 - 14:10

AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用

Claude Code を始めとする AI Agent は、私たちの日々の業務に欠かせない当たり前の存在となりました。では、そのような AI Agent を「Devin」のように自社サービスとして提供していくためには、どのような課題があるのでしょうか。様々な観点がありますが、私は「実行環境の構築と運用」が大きな鍵を握ると考えています。 GMO Flatt Security株式会社では、2025年3月よりセキュリティ特化の AI Agent「Takumi」を提供しています。サービス立ち上げ当初は Kubernetes を活用していましたが、事業がスケールするにつれて、インフラの維持費や複雑な運用コストが無視できない壁として立ちはだかりました。 そこで弊社は、AI Agent 特有の要件と運用上の課題を根本から解決すべく、独自の仮想化基盤「Sunaba」をフルスクラッチで開発し、2026年1月より本番環境での運用を開始しました。 本セッションでは、AI Agent SaaS の裏側で何がサービス提供の障壁となったのか、そしてそれを乗り越えるために、なぜ「自社基盤の開発」という選択をしたのかを解説します。Kubernetesからの移行の意思決定や、実運用を通して得られたリアルな学びを共有します。

7/10 13:45 - 14:10

最適な自走を最小限の支援で ── M&Aで拡大する組織で少人数SREが挑んだ1年 (13:45 ~ 14:00)

GENDAは「世界一のエンタメ企業」を目指し、M&Aによってグループ企業とプロダクトを急速に拡大しています。新しい企業がグループインし、新規事業が立ち上がり、共通基盤も広がっていきます。その一方で、SREチームはグループ規模の急拡大に対して、少人数で向き合っています。プロダクトが拡大していく環境において、すべてのプロダクトに専任SREを置くのは現実的ではありません。 そこで私たちは「最適な自走を最小限の支援で実現する」ことを掲げ、開発チームに任せる範囲・SREが入り込む範囲・全体施策に昇華する範囲を意識的に分けて活動してきました。その戦略を1年間運用してきた現場の学びを本セッションで共有します。チームが現場で何を学び、信頼性と組織をどう進化させてきたのかをお伝えします。 扱うトピックは次の二つです。 1. 信頼性への取り組み： 守る範囲が広がり続ける中、オブザーバビリティやセキュリティガバナンスを通じて信頼性をどのように底上げしてきたか。「現状の可視化」や「プロダクトへの入り込み」「AIエージェントの活用」など、現場で効いた打ち手・効かなかった打ち手とそこで得た学びを率直に振り返ります。 2. 組織としての進化： 増え続けるグループ会社・プロダクトに対し、少人数SREチームがどう関わり方を変えてきたか。グループインした企業へのオンボーディング、開発チームへの入り込み方、属人化の解消、知見の横展開の仕組み、タスクの選択基準など、プロダクトとの距離感を調整してきた試行錯誤と現在地を共有します。 少人数SREでスケールに挑むチームにとって、戦略とは現場で進化させ続けるものです。増え続けるプロダクトと向き合う皆さんにとって、何かひとつでも持ち帰れるヒントになれば幸いです。

7/10 13:45 - 14:10

PR単位で使い捨てるカイポケコネクトのpreview環境の設計と運用 (13:45 ~ 14:00)

弊社のプロジェクト（カイポケコネクト）で品質保証や検証作業のボトルネックを解消するために、PR/ブランチ単位でDBごと使い捨てできるpreview環境を構築・運用してきました。本発表では、その設計と運用のリアルをお伝えします。技術スタックは、フロントエンドにCloudFront + S3、バックエンドにmirage-ecs、DBにNeon、インターフェースにGitHub Actionsを採用しています。 使い方はシンプルで、PRに preview ラベルを付けるだけで環境が立ち上がり、ラベルを外すかPRをcloseすると自動で環境が削除されます。 開発者がPRから離れずに操作を行い、品質保証担当者にスムーズに検証作業を移譲できる体験を重視して設計しました。 導入当時は不確実性が高い状況の中で仮説ベースでシステムの要件を決めて設計・導入しました。仮説の中にはうまく機能したものもあればそうでないものもありました。引き続き課題として残っているものもあります。 実際に仕組みを導入してから一年ほど経過して得られた運用知見や実施した改善施策、今後の課題について紹介します。

7/10 14:10 - 14:30

AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用

Claude Code を始めとする AI Agent は、私たちの日々の業務に欠かせない当たり前の存在となりました。では、そのような AI Agent を「Devin」のように自社サービスとして提供していくためには、どのような課題があるのでしょうか。様々な観点がありますが、私は「実行環境の構築と運用」が大きな鍵を握ると考えています。 GMO Flatt Security株式会社では、2025年3月よりセキュリティ特化の AI Agent「Takumi」を提供しています。サービス立ち上げ当初は Kubernetes を活用していましたが、事業がスケールするにつれて、インフラの維持費や複雑な運用コストが無視できない壁として立ちはだかりました。 そこで弊社は、AI Agent 特有の要件と運用上の課題を根本から解決すべく、独自の仮想化基盤「Sunaba」をフルスクラッチで開発し、2026年1月より本番環境での運用を開始しました。 本セッションでは、AI Agent SaaS の裏側で何がサービス提供の障壁となったのか、そしてそれを乗り越えるために、なぜ「自社基盤の開発」という選択をしたのかを解説します。Kubernetesからの移行の意思決定や、実運用を通して得られたリアルな学びを共有します。

7/10 14:10 - 14:30

"正しいはずの依頼"が届かなかった理由 ― 依頼設計を見直す

SRE活動を始めた当初、最初に取り組んだのはSecurity Hub Criticalアラート対応の開発チームへの依頼でした。重要度は明確、対応手順も用意、MTGでも全体に伝えた――そんな丁寧な準備をしたつもりでした。それでも、思ったように対応は進みません。当時の私は、開発チーム側に原因があると感じていました。しかし振り返ると、当初自分が「正しい」と思っていた依頼そのものが、間違っていたのです。問題は開発チームではなく、自分の依頼設計にありました。 SRE領域には、担当が見えづらい・認知コストが高い・通常業務より優先度が低くなりやすい、といった構造的な要因があります。それを踏まえないまま依頼を出しても、依頼は届きません。 本セッションでは、Security Hub Critical対応を題材に、SRE活動初期の試行錯誤を事実ベースで共有しながら、依頼設計の3つの盲点と「対応につながる依頼」を設計する視点をお話しします。「正しいはずの依頼」を出しているのに対応が進まないと感じたことがある方への、ひとつの問いかけになれば幸いです。

7/10 14:10 - 14:30

Terraform CI/CDに潜む権限昇格リスクと対策 〜金融システムにおける権限分離と制御事例〜

インフラ管理において、IaCとCI/CDはトイル撲滅、作業ミスの軽減、作業証跡の保全といった観点で欠かせません。特にTerraformとCI/CDを組み合わせた運用は多くの現場で採用されています。しかし、CI/CDは強力な権限を前提として動作するため、その設計を誤るとセキュリティリスクを生み出します。適切な制御がなければ、本来は権限を持たない開発者であっても、Pull Requestを起点にCI実行環境の権限を悪用し、秘匿情報の取得や意図しない権限昇格を引き起こすことが可能になります。 本発表の前半では、Terraformを用いたIaC運用を前提に、CI/CD上でのTerraform実行に潜む具体的なリスクを解説します。 後半では、これらのリスクを踏まえ、金融システムであるDatachain Walletにおける実践として、Terraform実行基盤としてAtlantisを用いながら、どのようにリスクを制御しているかを紹介します。具体的には、planとapplyの権限分離を軸に、tfstateに保存される内容まで意識した運用や、PIMを用いた一時的な権限昇格によるCI/CD外でのオペレーション設計について解説します。 本発表が、Terraform CI/CDにおける権限設計や運用の改善に向けた実践的なヒントとなれば幸いです。

7/10 14:40 - 15:10

環境凍結というToilを倒す——セルフサービス型Ephemeralテスト環境の設計と実践

マイクロサービスアーキテクチャを採用する組織では、結合テストのために複数のSTG環境を運用し、チーム間で環境を共有するのが一般的です。しかし環境数が増えるほど、あるチームがテスト中は他チームがデプロイできない「環境凍結」が常態化し、リリースリードタイムの増大・環境コストの肥大化・チーム間調整コストの増加といった問題に陥りがちです。SREの観点から見れば、これは典型的なToilであり、DORA指標におけるLead Time for ChangesとDeploy Frequencyを著しく悪化させます。 私たちも最大6つのSTG環境を運用していましたが、環境を増やすアプローチでは根本的な解決に至りませんでした。環境を追加するたびにコストは線形に増加し、構築に約2〜3週間を要し、ゴミデータの蓄積によりテストデータの品質も低下していました。 私たちはKTC全体の組織横断タスクフォースとして、「必要な時に作り、不要になったら消す」Ephemeral Environmentの実現に取り組みました。DBREチームによる本番データマスキング基盤の構築、本番に近いSTG環境のIaCを同期するセルフサービス型インフラプロビジョニング、テスト専用AWSアカウントによる環境分離の3つの柱により、環境構築リードタイムを劇的に削減し、環境凍結というToilを構造的に排除しました。 本セッションでは、マスキング基盤のアーキテクチャ設計、IaC同期によるテスト環境の再現手法、テスト専用AWSアカウント戦略を中心に、マイクロサービス構成でテスト環境の運用やToil削減に課題を抱えるSRE・クラウドインフラエンジニアが、自組織で検討を始められる実践的な知見を共有します。

7/10 14:40 - 15:10

SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践例

AI駆動開発ではコード生成の速度が飛躍的に上がります。しかし速度が上がった分だけ、テスト・CI/CD・アクセス制御といった仕組みが整っていなければ、人間のレビュー負荷が膨らみ、速度のメリットは相殺されます。AIへの投資とDevOpsへの投資は、セットで初めて効果を発揮する。これが私たちの実感です。 本セッションでは、KDDIアジャイル開発センターでバックエンドAPIサービスを開発するチームが、Claude Codeを全面導入した現場で実践している7つの取り組みを紹介します。 1. 仕様駆動開発（Spec-Driven Development）によるAIへのインプット品質向上 2. TDDによるAI生成コードの検証と「1テスト=1論理分岐」のテスト設計原則 3. コーディング前に設計する受け入れ試験 4. Newmanによる自動リグレッションテストとCI/CDへの組み込み 5. k6とECS Fargateによる性能試験基盤 6. JIT-PAMによる本番環境アクセスの時限制御 7. AI時代のモブプログラミング いずれもSREとして積み重ねてきたプラクティスですが、AI駆動開発の文脈でその価値が一層増しています。AIが走り続けるためのガードレールをどう整備し、どう運用しているか。現場の試行錯誤をお伝えします。

7/10 14:40 - 15:10

クラウド上のデータ復旧で見落としがちな制約: 医療系 SaaS の BCP 設計から得た教訓

BCP対応において、バックアップの取得は出発点にすぎません。実際に復旧できる状態を維持し続けることこそが難しく、計画と実践の間には大きなギャップが存在します。 既に稼働中のシステムに後追いでBCP対応を組み込んでいくためには、顧客業務の優先度を整理したうえで復旧手段に応じたサービス復旧目標（RTO / RPO）を設計し、アプリケーションのアーキテクチャや技術的制約を加味した復旧戦略を策定する必要があります。 さらに、カケハシではAWS上にサービスを構築しているため、各種データストアサービスの特性や制約を理解したうえでの設計判断も求められます。 マネージドサービスを利用している場合、バックアップの取得は比較的容易です。しかし、いざ復旧しようとすると、計画段階では見えなかった技術的な困難が次々と現れます。 加えて、医療系SaaSでは厚労省ガイドラインへの準拠やデータの国内保持要件といった規制対応、本番相当データでの訓練コスト、関係者との合意形成など、ドメイン固有の難しさも重なります。 本セッションでは、医療系SaaSのSREとしてマルチリージョンDR構成の設計やデータ復旧戦略の策定に取り組む中で直面した技術的課題と、その対処の考え方を具体的にお話しします。 これからBCP対応に取り組むSREチームのメンバーやリーダー、既存の復旧設計を見直したいインフラエンジニア、医療や金融など高い可用性が求められる領域でサービス運用に携わる方にとって、復旧設計の勘所や判断軸を考えるきっかけとしてお役立ていただければ幸いです。

7/10 15:25 - 15:55

Grafana Loki 再入門 〜ログ分析基盤の進化〜

クラウドネイティブ化が進む中で、ログコストが想像以上に増え続けていると感じている方も多いのではないでしょうか。また、ログは大量に記録されているものの、十分に活用しきれていないと感じている方もいらっしゃると思います。特に、障害の原因分析などに備えてできる限り多くのログを残したい一方で、保存・検索コストとのバランスに悩むケースも増えているのではないでしょうか。本セッションでは、こうした課題に対する選択肢の一つとして、Grafana Labs が開発する Grafana Loki を取り上げます。Grafana Loki は 2019 年に最初のリリースが公開されており、一度は名前を聞いたことがある方も多いと思います。一方で、Prometheus と比べると、実際に触れたことがある方はまだ多くなく、その価値やユースケースは十分に知られていないのではないでしょうか。近年では、大規模環境での採用やアーキテクチャの進化も進んでおり、あらためて Loki を見直すタイミングが来ています。 小さなインデックスを特徴とする Loki のアーキテクチャが、なぜ大量ログの低コストな保存に適しているのか、柔軟なクエリ言語である LogQL によってログの探索・集計・可視化をどのように実現できるのかを解説します。さらに、Grafana と組み合わせた場合の便利な使い方や、Adaptive Logs のようなログコスト削減機能、近年進化している Loki のアーキテクチャ変化にも触れながら、単なる「低コストなログ分析基盤」ではない Loki の魅力を紹介します。

7/10 15:25 - 15:55

ポストモーテム！DDoSからサイトは守れた。でもビジネスは守れなかった。

私たちが大規模なDDoS攻撃に遭遇したときのポストモーテムを共有します。 弊社では大規模なDDoS攻撃を受けましたが、AWS WAFをはじめとした対策が功を奏し、幸いにもダウンタイムゼロでサイトを守ることができました。 しかし安堵したのも束の間、WAFのリクエスト数課金によるインフラコストが急増し、平常時の千倍を超えるコストが発生する事態に陥りました。 「サイトは守れた。でもビジネスは守れなかった。」 これが私たちの直面した現実です。 さらに苦い教訓もありました。攻撃初日にAWSの予算アラートが届いていたにもかかわらず、月末に届く月額予算アラートと金額が似ていたため、「月末のいつものアラートだ」と判断してしまい、対応が遅れました。 残念ながら、いつDDoS攻撃が来てもおかしくない時代です。 本セッションでは、「WAFを外せばサイトが落ちる、WAFを続ければ費用がかさむ」という答えのないジレンマに直面した経緯、ポストモーテムで明らかになった構造的な問題点、そしてAWS Shield Advanced導入までのプロセスをお話しします。 技術的な対策だけでなく、アラートの見逃しという人間的な失敗や、コストと可用性のジレンマにおける意思決定プロセスまで、リアルな運用の話を包み隠さずお伝えします。 DDoS攻撃が来てから慌てて対応するのではなく、平常時からアクセス数に比例して利用料金が増加する部分を把握し、システム構成の見直しや予算アラート設計の改善に取り組むための実践的な知見を共有します。 私たちの経験が、翌営業日にチーム全員で話し合い、DDoS対策の検討を始めるきっかけになれば幸いです。

7/10 15:25 - 15:55

なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜

SLOを設定した。ポストモーテムも始めた。On-callも回している。でもなぜか組織に根付かない。改善のループに乗らない。もしかしてみんな忘れてる？ そんな感覚を持ったことはありませんか。 私はこれまで一人目SREや、SREプラクティスが未成熟なチームに参画し、文化醸成を担う役割を複数の現場で担ってきました。 その中で、SRE本を参考にしながらも機能しなかったり、形骸化していたりするケースを見てきました。 なぜ本の通りに実施しても、なかなかうまくいかないのでしょうか？ ここで思い出してほしいのは、SREはGoogleという組織の中で定義され、実行されたものだということです。 彼らの組織には、DevOps的な協働文化Blamelessな振る舞いなど、SREという役割が機能するための「土台」がすでに備わっています。 私たちの組織はどうでしょうか。Googleとはサービスも、文化も、人の構成も違います。 だからこそ、SRE本のプラクティスをいきなり実践する前に、組織そのものを「見立てる」必要があります。 本セッションでは、SREプラクティスを実践しているが「なかなかうまく機能していない」と感じている方に向けて、なぜシステムより先に組織を見るのか、組織を見るときに何をチェックすればよいのかを、例とともに共有します。

7/10 16:10 - 16:40

OSINT for SRE: 学術論文とポストモーテムから探るシステム障害の共通パターン

私はソフトウェアエンジニア(DBRE)として実務におけるシステム運用に関わりながら、博士後期課程でシステム障害原因の分析を研究しています。研究活動で学術論文やポストモーテムの記事を読むうちに、システム障害の事例や分析結果が十分に運用で活用されていないことに気づきました。こうしたシステム障害の知見が活用しきれていない要因の一つは、システム障害の事例を包括的に分析した日本語の資料の不足にあると考えます。本セッションではインターネットに公開されている20以上の英語で書かれた論文やポストモーテムを使い障害原因の傾向の分析(OSINT for SRE)を行います。セッションでは、まずMicrosoftやeBayのエンジニアによるものを含む5件の論文を分析し、その中から主要な4種類の共通した障害原因を紹介します。さらに、それら4種類の主要な障害原因をポストモーテムや論文、具体的な事例とともに詳細に分析します。4種類の主要な障害原因の1つには連鎖障害があります。マイクロサービスアーキテクチャで設計されたシステムでの連鎖障害は、あるマイクロサービスで起きた障害が別のマイクロサービスへ連鎖して障害が発生することです。システムの運用で連鎖障害を知っていても、いくつのマイクロサービスに連鎖するケースが最も多いか、どんな種類のシステムから連鎖障害が発生しやすいかを把握しきれていない状況にあると考えています。本セッションでは運用経験にもとづく感覚的な認識ではなく、データを使った定量的な分析を行います。本セッションを通じてシステム障害の原因の傾向を具体的なデータをもとに定量的に把握できます。またデータを把握することにより、自社でのシステム障害の対策において対象や優先度の決定を正確に行えます。

7/10 16:10 - 16:40

インフラ寄りSREでも開発に踏み出せる ~境界を越えて信頼性に向き合いたい~

信頼性に向き合うために開発にも踏み出したいインフラ寄りSREの皆さん、頑張れば意外といけます。この発表を事例にマネージャーに相談してみてください。 私はインフラ寄りSREとし lて、決済基盤の設計構築やSLO導入、IaC推進、ポストモーテム導入、オブザーバビリティの向上などに取り組んできました。しかし、信頼性に向き合う中でアプリケーションを読めない・変更できないと解決できない課題が増えていると感じていました。クラウドによりインフラが抽象化される中、ユーザー体験に直結するパフォーマンス課題などはアプリケーションを含めたアプローチも必要になります。 本セッションでは、インフラ寄りSREだった自分が開発領域に踏み出し、SWEとして働く中で見えた景色をお伝えします。 SWEになるまでに「開発をやりたい」と言い続け、自己学習を重ねる日々を過ごしました。反対意見もある中で組織が挑戦させてくれたこと、そこに至るまでの背景もお話しします。実際に開発チームで働いてみると、インフラで培った経験が意外と活きました。ユーザー体験を起点にして仕様レベルから複雑さを落とす提案など、インフラだけでは辿り着けなかったアプローチができるようになりました。また、AI活用によって経験不足も補うことができ、今後さらに開発に踏み出すハードルは下がっていくと感じています。 一方で、この選択が正解かはわかりません。王道のキャリア戦略ではないですし、AI時代にジュニアSWEから始めるリスクも感じています。正直ビビっています。それでも、ユーザー視点の信頼性に向き合えている実感は確実にあります。 インフラ・開発の境界を越えてSREに取り組む選択肢を、一つの生き様としてお伝えします。皆さん自身の選択を考えるきっかけになれば嬉しいです。

7/10 16:10 - 16:40

TBD

TBD

7/10 16:55 - 17:25

分散システム、なんですぐ死んでしまうん？耐障害性を高めたいあなたのためのレジリエンスパターン入門

マイクロサービスやクラウドネイティブなアーキテクチャが主流となる中、分散システムは常に障害のリスクと隣り合わせです。一つの障害がシステム全体に波及し、ビジネスに甚大な影響を与えることも少なくありません。本セッションは、まさにその課題に直面するSREの皆様へ向けた、分散システムにおける信頼性向上と障害耐性強化のための「レジリエンスパターン」への入門です。 Retry、Circuit Breaker、Rate Limiting, Request Hedging、Graceful Degradationといった主要なパターンについて、その基本的な考え方から、現場で役立つ実践的な「勘所」までを体系的に解説します。単なる手法に留まらず、それぞれのパターンがどのような課題を解決し、どのような点に注意して導入すべきかを掘り下げます。 さらに、これらのレジリエンスパターンを実装する際の選択肢として、Service Meshとアプリケーションレベルのライブラリそれぞれのメリット・デメリットや、選択の考慮事項についても検討します。 セッションの後半では、具体的な事例として、メルカリにおけるレジリエンス実践の経験をお話しします。過去にリトライの連鎖がシステムに過負荷を与え、サービスに影響が出た実例や、それを踏まえそのようなパターンがどのように適用されているのかを紹介します。皆様が明日から自社のシステムに適用できる具体的なヒントと、より強固なシステムを構築するためのヒントになるはずです。 本セッションを通じて、分散システムの信頼性向上に取り組む全てのエンジニアが、障害に強いサービス設計と運用を実現するための第一歩を踏み出せることを目指します。

7/10 16:55 - 17:25

SREはどこまでやるのか？セキュリティの民主化時代の運用再設計ライフサイクル

SREの役割は従来、可用性やパフォーマンスの維持にフォーカスされてきました。しかしクラウドネイティブ化やDevOpsの進展により、セキュリティは特定の専門チームだけで完結するものではなくなり、SREもその一端を担うことが求められています。 一方で「どこまでSREがやるべきなのか」という問いに対しては明確な答えがなく、現場では責任の曖昧化や運用負荷の増大といった課題が顕在化しています。すべてをカバーしようとするほど、運用は破綻しやすくなるという現実もあります。 本セッションでは、セキュリティの民主化が進む現代において、SREが担うべき役割を再定義し、「全部やる」のではなく「回る仕組みを設計する」という観点から運用を再設計するアプローチを提示します。 Runtime検知、脆弱性対応、Agentless運用などの実例を交えながら、現場で実際に起きている課題とその解決策を整理し、SREとセキュリティの境界をどのように設計すべきかを具体的に解説します。 最終的には、検知・優先順位付け・自動化・フィードバックのループを中心とした新しい運用ライフサイクルを提示し、持続可能なセキュリティ運用の実現方法を共有します。

7/10 16:55 - 17:25

AIと共生する開発者プラットフォーム：バクラクのモノレポ×マイクロサービス基盤

マイクロサービスが増えるにつれ、サービスの状態把握やリリース管理の複雑さは増し、開発者の認知負荷は高まっていきます。バクラクではそれが100以上のマイクロサービスをモノレポで運用するという環境でより顕著になり、内製のInternal Developer Portal（IDP）「ServiceConsole」を開発しました。 このモノレポ運用において、私たちは主に3つの課題に直面しました。 1つ目は、マイクロサービスの状態が複数のプラットフォームに分断されているという問題です。1つの変更をマージして動作確認するだけでも、GitHub・AWS・Datadogなど複数のプラットフォームを横断する必要があります。さらに100以上のサービスがモノレポで管理されているため、各プラットフォームで正しいリソースを見つけるのも困難な場合があります。そのため各マイクロサービスの状況把握が困難となっており、日々の開発フロー全体を一元管理できる仕組みが必要でした。 2つ目は、本番環境へのリリースの複雑性という問題です。バクラクはSaaSとして全体での定期リリースを行っており、マイクロサービスが増えるにつれ一回あたりのリリースにかかる時間も増大し、安全かつ確実なオーケストレーションや自動化の実現が急務でした。 3つ目は、AI活用が十分に行えていなかったことです。モノレポの構造・依存関係・デプロイ状態といった独自基盤のコンテキストをAIに提供できる基盤が必要でしたが、既存の仕組みでは実現できていませんでした。 Backstageのような既存ツールは我々のモノレポエコシステムにフィットせず、生成AIの活用により開発コストを抑えながら内製化しました。ServiceConsoleはAWSとGitHubをデータソースとして、バクラクのすべてのマイクロサービスに関する情報を集約するプラットフォームです。人間向けにはダッシュボードUIによる直感的な状況把握・操作を、AIエージェント向けにはリリース操作や障害時の状況収集に必要な構造化されたコンテキストの提供を実現しています。本発表では、その設計思想・実装の工夫・運用を通じて得た知見を共有します。

7/10 17:40 - 18:20

Engも、Bizも、CSも。組織横断タスクフォースで実現したライブ配信サービスの信頼性向上 (17:40 ~ 18:10)

エムスリーは、医師の9割が登録するプラットフォームを展開している会社です。 私たちはその中で、医療学会のライブ配信サービス「Web講演会」を提供しています。 医療業界最大手のライブ配信という特性から、配信中のバースト耐性や可用性の担保はもちろん、障害復旧の速度も強く求められるサービスです。 本発表では、この高いサービスレベルを支えるためにエンジニア、ビジネス部門、カスタマーサポートなど複数の部署が一丸となって取り組んできた信頼性向上の実践をご紹介します。 発表の前半ではエンジニアリング観点からの取り組みをお話しします。 サービスのアーキテクチャやスケーリングの仕組みに加えて、サービス全体を落とさずに重要な機能を提供し続けるための工夫や、アラートやモニタリングの設計についてご紹介します。 後半では複数の関連部署のメンバーでタスクフォースを組んで安定運用に取り組んでいる実践例をご紹介します。 こちらでは、そもそも組織横断で取り組んでいる理由から始まり、実際の体制と各メンバーの役割であったり具体的な障害対応のフローについてご紹介します。

7/10 17:40 - 18:20

グローバルSREの最前線：3社が語る、国境を越えた「システム信頼性」と組織の動かし方

7/10 17:40 - 18:20

「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ (17:40 ~ 18:10)

SRE NEXT 2025にて、弊社ログラスはSRE不在の開発チームがインシデント対応体制をゼロから構築した経験を発表しました。教科書的なベストプラクティスに沿い、インシデントコマンダーの専任化、障害レベル定義の整備、対応フローの刷新、ツールによる可視化を進め、MTTRの改善という数値的な成果も手にしました。「ちゃんとやれている」という手応えを感じていました。 しかしそれは独りよがりでした。数ヶ月後、CS・Salesなど顧客最前線の部門から「うまく回っているとは思えない」という声が上がります。MTTRは縮んでいました。でも、その裏でCS担当者は顧客に伝えるべき情報が届かないまま問い合わせに応じ続けていたのです。インシデントのレベル定義は顧客影響の視点が欠けていた。復旧に向けた対応は動いていても、顧客と向き合うチームの手元には何もなかった。私たちは「速く直す」という数値を追うあまり、「誰のために、何のためにやるのか」を見失っていました。 なぜそうなったのか。根本にあったのは、開発部門と事業部門の間に対話がなかったこと、そしてそもそも対話できる関係性が築けていなかったことでした。お互いが何を大切にし、何に困っているのかを知らないまま、開発チームだけでプロセスを作り上げていたのです。 本セッションでは、この気づきから関係性を再構築し、事業部門と対話しながらインシデント対応を作り直した道のりをお話しします。合同の振り返り、お互いの思い・期待の共有、そして協業の中で具体的に何を決め、何が変わったのか。起票から数時間連絡がないこともあった状態から30分以内の全体周知へ、情報共有スタイルの変革、事業部門の満足度向上に至るまでの四苦八苦をリアルにお伝えします。 MTTRを改善したのに現場から「変わっていない」と言われた経験がある方、開発と事業部門の連携に課題を抱えている方へ。プロセスの前にある「対話」と「関係性」の話をお届けします。

7/11 10:40 - 11:20

TBD

7/11 11:35 - 12:05

サンプリングは統計学である: 数理的根拠に基づき、オブザーバビリティのコストと精度を両立する

分散トレーシングの導入において、SREが直面する大きな抵抗の一つは「データを捨てたら、SLIの計測精度が下がるのではないか」という懸念です。P99レイテンシの算出やエラー率の監視において、サンプリングがどのような誤差をもたらすのかを定量的に説明できないまま、不安を解消するために高額なストレージ費用を支払い続けているケースは少なくありません。 本セッションでは、サンプリングを「統計学」の視点から再定義し、数学的根拠に基づいたオブザーバビリティ設計の手法を提示します。SRE本などの既存のプラクティスを一歩超え、中心極限定理や信頼区間の考え方をテレメトリーデータに適用することで、どの程度のサンプリング率であれば必要な精度を維持できるのかを論理的に導き出します。 具体的には、以下の3点にフォーカスします。 1.サンプリングの数学的モデル化：サンプリング率と推計誤差の関係をシミュレーションし、サービス規模に応じた「適正なサンプリング率」の算出方法を提示します。 2.OpenTelemetryによる「重み付け」の管理：サンプリングされたデータから元の全量を推定するための「Adjusted Count（調整済みカウント）」の仕組みと、バックエンドでの正しい統計処理 3.精度を担保したコスト最適化の実践：全件収集を前提としない、新しいSLOモニタリングのあり方を示します 「なんとなく1%」という意思決定を卒業し、数理的なバックボーンを持って、コスト効率が高く、かつ信頼できるオブザーバビリティ基盤を設計するための知見を共有します。

7/11 11:35 - 12:05

生成AIに「技術」を任せ、「非技術」で仲間を集める〜一人目SREが採用・組織化を最大化した軌跡〜

スタートアップの一人目SREとして入社すると、膨大なシステムのキャッチアップや構築に追われ、「何でも自分一人で解決しなければ」という孤独やプレッシャーを抱えがちです。SRE界隈では「高い技術力で負債をなぎ倒す」スーパーマンが求められがちですが、そのアプローチでは属人化が進み、開発チームへの価値提供やSRE組織の拡大（採用）まで手が回りません。 私はそんな「一人で全てを解決しなければ」という思い込みを手放し、インフラ構築の手足を生成AI（Claude Code等）に委ねました。AIを相棒にブラックボックスだったインフラの技術課題を次々と乗り越える中で、誰も触れなかった負債が徹底的に整理され、インフラからアプリ層に至る「システム全体の課題」が可視化されていきました。 その結果、インフラ専任の領域を越えてバックエンド開発チームの負債回収にも自ら参画し、非技術的な強みであるコミュニケーションで開発者を巻き込む越境的な立ち回りが可能になりました。 さらに、技術的負債を一人で全て解決しようとせず、結果的に残った「明確化された課題」を"次の仲間が活躍できる余白"として提示した結果、採用のカジュアル面談からの選考移行率が「0%」から「80%」へと劇的に向上。新規で入社したメンバーも爆速でオンボーディングを完了させ、さっそく組織の課題解決に貢献してくれています。 本セッションでは、この2024年10月から現在までの軌跡を通じ、「生成AI」を武器にして採用・チーム組成という「非技術的な要素」を磨き上げた事例から、これからの時代における新しいInclusive SREの体現方法を共有します。

7/11 11:35 - 12:05

SRE依存からの脱却 — 運用を開発チームへ移すフルサイクル開発体制の実践

システム数・サービス数が増えることによって運用チームがボトルネックになるという現象は多くの組織が経験していたり、危惧していることかと思います。 弊社が運用するサービスはリリース直後から急速に成長していきました。 SREの採用の難易度とサービスの成長速度を鑑みて、早い段階から開発者がシステム運用も担う「フルサイクル開発体制」を理想と考え、SREのプラクティスであるSLI / SLOの整備、Runbookの作成、ポストモーテムの実施などを行って来ました。 しかし、チームが少人数のときには「開発者が運用もやろう」でなんとなく回っていた状態が、 - チームメンバーの増加 - チーム数の増加 - 関連サービスの増加 等によりシステム運用は再びSREのロールを持つメンバーに暗黙的に集約されていきました。 結果的に、開発時に運用面が十分に考慮されず対応が後追いになる、運用の属人化、運用負担の集中や認知負荷の増大が発生してしまいました。 そこで、チームやサービスが大きくなっても開発メンバーが運用も担うという文化を醸成するために、組織と責任に対してアプローチし、改めて文化の定着を目指しました。 組織との合意形成、評価制度や責任の明文化、ガードレール付きの権限設計などを通じて、責任と権限を開発チームに移譲していきました。さらに、AllHandsやプロダクト開発に関わるチーム全体での継続的な発信や開発者との対話を通じて認識を揃えること、運用に対する学習のフィードバックサイクルの構築などを実施しました。 結果として、アプリケーション起因のインフラコストの削減や、SLOの改善、障害対応、キャパシティプランニングなど多くのシステム運用項目において開発者が自律的にアクションを取り、運用のフィードバックサイクルが回る組織へと変化してきました。 本セッションは、SREがボトルネックになっている、または運用の移譲に課題を感じている、今後課題になりそうななチームを持つ方を対象とし、運用の移譲を「SREとしての仕組み」だけではなく「責任 / 組織構造と文化の醸成」として捉え実践した知見を共有します。

7/11 12:20 - 12:35

一人目専任SREの立ち上げを加速する ― AIと進めたオンボーディングで2分を0.04秒にした話

PKSHA Technologyでは、各プロダクトにEmbedded SREを配置する体制を取っています。社内ヘルプデスク業務をAIで自動化するSaaS「AI Helpdesk」では、これまでSWEがSRE業務を兼務する形で運用されてきましたが、事業規模の拡大に合わせ、専任SREの一人目として、ゼロからSREというポジションを立ち上げる形で私が着任しました。 頼れる同僚も新規機能開発で多忙な時期。プロダクト固有のドメイン知識も、SLO違反の原因調査に必要なシステムの経緯も、自分で掘り起こす必要がありました。そこで選んだのが、「AIとの対話で自分の解像度を先に上げ、限られた同僚の時間を最大限活かす」という進め方です。 本セッションでは、一人目SREとして入社してから2か月でプロダクトのパフォーマンス改善をリードした事例を取り上げながら、どのように早期にオンボーディングを行い、なぜ成果を出せたのか、その背景にあるDevinやClaudeといったAIエージェントの活用についてお話しします。Notionに蓄積されたADRなど過去ドキュメントを横断的に探索したアプローチや、同僚への質問をどう高密度な対話へ転換していったかにも触れる予定です。 本セッションで一番お持ち帰りいただきたいのは、次の気づきです。 - Embedded SREは体制上、少数精鋭になりやすい。その制約下でも、コンテキストが整備されたAgentによるオンボーディングは一定の効果をもたらす - Slack上でのDevin利用により、他メンバーのプロンプトと対話の流れまで可視化され、誰がどう働いているかが見え、他人の仕事から学びを得られる（副次的に、PRやLinearチケットとも自動で紐づき、トレーサビリティも高まります） 「チームが小さい」「気軽にpingできる相手が限られる」——そんな立場のSRE・プラットフォームエンジニアの方に、コンテキストを整えてAgentで自由に索引・探索できるインターフェースを用意するだけで、オンボーディング体験は大きく変わるという実感を持ち帰っていただければ嬉しいです。

7/11 12:20 - 12:35

プロダクトだけじゃない、社内プロセスにおける自動化・省力化ノススメ

トイルの削減といえば、皆さん普段の業務の中で行われていることだと思います。プロダクト運営においては、普段からどうしたら減らせるか、色々知恵を割かれているのではないでしょうか。今日はそんなプロダクトの現場から少し視線をそらしてもらって、社内で行われいるプロセスなんかでも、トイルって転がっているものですよというお話をさせてもらい、社内での取り組みの一部をご紹介できればと思います。

7/11 12:20 - 12:35

Terraform共通モジュールをチーム横断で“変えられる”運用へ ― リリースと適用の分離

Terraformをモノレポで運用し、複数プロダクト／複数環境（development/staging/production）を支える構成では、共通モジュールが多くのルートモジュールから参照されがちです。その結果、共通モジュールの変更が広範囲に波及し、破壊的変更のリスクや全環境への影響を恐れて「直したいのに直せない」状態に陥ります。さらに provider の更新が進まず、新機能を取り込めない／個別実装が増えるなど、運用コストも増大します。 本セッションでは、この状況から脱却するために「共通モジュール側の変更（リリース）」と「各プロダクト側の適用（取り込み）」を分離し、SREチームだけでなく開発チームも安全に更新を回せるようにした運用を紹介します。 具体的には、(1) 共通モジュールを Git タグ参照に切り替えてバージョニングし、(2) 運用マニュアルを整備して変更手順を標準化、(3) Renovate による更新PRの自動配布で各プロダクトへの適用を低コスト化しました。 視聴後は、複数ルートモジュールが存在する環境でも「共通モジュールを変えられる状態」を維持するための設計・運用方法を持ち帰れます。

7/11 13:00 - 13:40

SREの未来予想図：スペシャリスト、マネジメント、外部支援──3つの視点から紐解くエンジニアの成長戦略

7/11 13:00 - 13:40

しぶいSRE: サーバから見えない障害にどう向き合うか。ラストワンマイルのデバッグ実践 (13:00 ~ 13:30)

サーバは正常、メトリクスも問題なし、アラートもない。それでもお客様からは「使えない」という声が…このような “観測できない障害” に遭遇したことはありませんか？ 本セッションでは、企業向けプロダクトの運用に携わるエンジニアを主な対象として、ユーザー環境に起因する問題に対して実践的に切り分け・調査を行うための具体的なアプローチを解説します。 プロダクトとユーザーの間には、ブラウザ、メーラー、プリンター、ネットワーク機器といった無数のソフトウェア、そしてデバイスが存在します。とりわけ企業ネットワークにおいては、環境の差異やセキュリティへの取り組みによって「サーバサイドから見ているだけでは気づかない」問題が起こりやすい傾向があります。 こうした問題が起こると、どこに原因があろうとユーザーから見れば「使えないプロダクト」と感じられてしまいます。サービスの信頼性に責任を持つSREとしては、こうした問題にも踏み込んでいくことが求められます。 本セッションでは、発表者が企業向けプロダクトの運用において実際に遭遇した「ページが表示されない」「表示が遅い」「メールが届かない」といったトラブルを題材に、調査から解消に至るまでのプロセスを具体的に紹介します。業務効率化AIエージェントサービス「バクラク」の事例をもとに、HARファイルの読み解きによるパフォーマンス問題の特定、SMTPやメール仕様に起因する配送トラブル、DNSリゾルバと長大なレコードによる問題など、現代でも発生する“ラストワンマイル”の障害に対する実践的なデバッグ手法を解説します。 これらの知見を通じて、サーバサイドの観測だけでは捉えきれない問題に対して、再現性のある調査・切り分けを行い、ユーザー環境に踏み込んで解決できるようになるための視点と具体的な手法を提供します。

7/11 13:00 - 13:40

Lightning Talk

『「念のためのログ保存」を組織全体でやめるためのポリシーと仕組み作り』:大野 一樹 サービスのログを「念のため保存」し続けることは簡単です。しかし、保存期間や削除基準が曖昧なまま運用され、長期にわたってサービスが運用されるとコストとリスクが積み上がっていきます。問題の背景には技術的な要件ではなく、法務・セキュリティ・事業部門などのステークホルダーが関わる中で、誰が何を根拠に保存期間を決めるのかが整理されていない組織の課題がありました。ログ保管の考え方を組織横断で言語化し、合意形成を進め、継続的に運用できるポリシー作りとツールによる統制へつなげた過程をお話しします。 『カルチャーを仕組みに変える ─ IVRyのオンコール制度設計の裏側』:近藤 圭太 IVRy で SREのオンコール制度を0から設計した実体験をお話しします。 PagerDuty の導入を皮切りに、「自由と責任」という会社のカルチャーコンセプトを制度にどう落とし込むかを模索したプロセスを紹介します。 労務・人事・顧問社労士との対話を通じ、管理監督者性リスクへの対応や待機時間の労働時間該当性を整理しながら、法的に持続可能な設計を実現しました。 手当を金銭ではなく「半休（0.5日）」とした理由、1st/2nd ローテーションの運用実態、"お金のためではなく仲間の自由を守るための制度"というコンセプト設計など、各社で悩みやすいポイントを具体的にお伝えします。 オンコール制度の導入・改善を検討している SRE / Platform エンジニア・EM の方に参考にしていただける内容です。 『RACIで比較するDBAとDBREの思想の違い〜データベース運用をプラットフォーム化する責任設計〜』:粟田 啓介 本発表では、従来の DBA と DBRE の違いを、RACI（Responsible / Accountable / Consulted / Informed）のフレームワークを用いて比較し、データベース運用における責任構造の違いを整理します。特に、プロダクトチーム、DBRE、クラウドインフラという3つのレイヤーに責任を分離することで、データの責任とデータベース基盤の責任をどのように整理できるのかを解説します。 さらに、DBREが担う役割として、データベースアクセスのガードレール設計、運用のセルフサービス化、可観測性の整備、自動化など、データベースを安全に利用するためのプラットフォーム設計の考え方について紹介します。 本発表を通じて、DBA 中心の運用モデルから、データベースをプラットフォームとして扱う DBRE への移行において重要となる責任設計と思想を共有します。 『ガバナンスの「ちょうどいい落とし所」を探れ！開発スピードを妨げない運用判断の勘所』:木村 奈美 「この設定は非推奨なので承認できません」。ルールを盾に突っぱねるのは簡単ですが、それは開発の勢いや士気を削ぐことにもつながります。ガバナンスの遵守とスピードの両立は、多くの組織が直面する永遠の課題です。 GENDAのSREチームでは、このトレードオフに対し「まずは目的の遂行を優先し、後からより良い形に整備する」という、ソフトウェアのリファクタリングと同じアプローチをとっています。本LTでは「インフラ構成をどこまでベストプラクティスに沿わせるか」「AWSやGitHub等で強い権限の付与を認めるか」といった具体的な葛藤の事例を取り上げ、どのような戦略で統制を効かせているかの実例を紹介します。 利用者からの相談に対し、承認可否を判定する審判者としてではなく、共に環境を整える伴走者として動く。そのための現実的かつ効率的な運用マインドセットをお伝えします。 『あなたの「Site」はどこですか？ — xREという考え方』:miyamu SREはSite Reliability Engineeringの略です。この Site は「サービス全体」や「IT システム全体」などを指す広範な概念です。 私は組織上のロールとしては CRE (Customer Reliability Engineer) からスタートし、現在はテックリードとして活動しつつ、SRE系のカンファレンスに登壇したり、コミュニティに参加したりしています。 「CREなのに、テックリードなのに、なぜSREを？」とよく聞かれますが、実はこれらはSiteをどこに置くかの違いでしかありません。 CREなら顧客体験全体を、テックリードならプロダクト・開発組織全体を、それぞれSiteとして信頼性を守る——そう考えれば誰でも「xRE」になれるのです！ 本発表では実際にCREとテックリードとしてどのようにSREプラクティスを活用したかを紹介します。あなたも自分なりのSiteを見つけてみませんか？ 『ZOZOTOWNの進化と信頼性を両立する負荷試験 — 年十数回、現場の課題と効率化』:Yuki Matsuishi ZOZOTOWNの会員ID基盤では、年十数回の負荷試験を実施しています。 新機能の追加やリプレイスなどプロダクトの進化が続く中で、信頼性をどう担保し続けるか — その要が負荷試験運用です。 しかし実施要否の検討・シナリオ作成・mock準備・想定RPSの見積もりなど、試験前に積み重なる判断と調整が、見えないコミュニケーションコストを生み、運用を試験を回すだけで精一杯の状態にしていました。 本LTでは、要否判定の属人化解消・シナリオ資産の使い回し・分析工程の仕組み化、結果のテンプレート化など、現場で有効だった運用改善と、これから取り組みたい効率化の方向性を共有します。同じ負荷試験運用に悩む方々、これから基盤を整えていきたい方々の参考になれば幸いです。

7/11 13:55 - 14:20

Control Plane で育てる、BtoB SaaS の認証基盤

Dress Code は、人事・採用・総務・情シス・プロジェクト・コーポレートガバナンスの 6 領域を 1 つの基盤で扱うマルチテナント BtoB SaaS『DRESS CODE』を、アジア 5 カ国・多言語で展開しています。認証基盤は『DRESS CODE』の全機能から共通で呼ばれる土台に位置しています。本セッションでは、BtoB SaaS のマルチテナント認証基盤をどう設計し、それを Control Plane という設計思想でどう束ね、これからどう育てていくかをお話しします。 創業期に採用したマネージド認証サービスから、ヘッドレスな OSS 認証基盤群である Ory の組み合わせへ移行した背景を共有します。グローバル展開・データレジデンシー・ポータビリティといった事業要件と、認証 UI を自社で握りたいという狙いから、「必要な機能を必要なときに足せる土台」を選んだ意図を紐解きます。 その上で、全テナントを横断する Control Plane を、インフラ・BFF・バックエンドの 3 層でどう多層防御しているかを共有します。 最後に、AI エージェント時代に向けて業界各社が示している方向性を踏まえ、Dress Code がその先にどう進んでいくかを共有します。私たちは全テナントの操作を Business Operation Event として体系的に蓄積する仕組みを Platform Capabilities として備えており、データの土台はすでに積み上がっている状態です。その上に、人間用に組んだ多層防御の哲学を地続きで拡張し、『DRESS CODE』を IdP として育てていくロードマップを構成図とともに示します。

7/11 13:55 - 14:20

信頼性をひろげる ― SRE × Securityの実践 (13:55 ~ 14:10)

SREは「システムの信頼性を、適切なレベルで、持続的に保つための取り組み」と語られることがあります。その実践は可用性やレイテンシを軸に発展してきましたが、セキュリティインシデントは別軸で扱われがちです。しかしユーザーから見れば、サービスが落ちることも侵害されることも等しく「信頼を損なう瞬間」にほかなりません。 本セッションでは、SREとセキュリティが同じ視点で向き合うための考え方と実践を、簡単なデモを交えて紹介します。膨大なシグナルの中から異変を捉え、人とAIが協働して判断・対処する運用の一例を共有できる機会になれば幸いです。  ― "Realtime AI-Powered Cloud Defense"

7/11 13:55 - 14:20

電子カルテSaaSを支えるオブザーバビリティ活用と開発者の実践 (13:55 ~ 14:10)

株式会社ヘンリーでは、レセコン一体型電子カルテ「Henry」を医療機関に提供しています。電子カルテという領域は、患者の症状や処方の記録といった機能のほかに、業務のワークフローや患者データ管理のようなCRMの役割も担っています。 加えてHenryは、保険の負担額計算といったレセコン領域も担っています。 このようにHenryは、医療機関のコア業務を1つのプロダクトで支えるSaaSです。 Henryが提供する機能の多くはミッションクリティカルであり、平常時の高い可用性とインシデント発生時の迅速な対応が求められます。 ヘンリーでは、これに対応するためオブザーバビリティの向上に取り組んできました。 その結果、開発・運用のさまざまな場面でオブザーバビリティを活用できるようになりました。 具体的には、定常監視によるパフォーマンス分析、重要機能に関わる機能のトレース監視整備、トレースベースのアラート設定、障害対応時におけるトレース・ログ・メトリクスを横断した調査、トレースを用いたデバッグなどを実践しています。 これらの取り組みにより、インシデント発生時に迅速に原因特定を行えるようになり、平時から可用性を継続的に改善できる状態が整いました。 本セッションでは、ヘンリーのインフラおよびオブザーバビリティ構成と、それらをどのように活用して可用性向上に取り組んできたかについてお話しします。

7/11 14:20 - 14:40

Control Plane で育てる、BtoB SaaS の認証基盤

Dress Code は、人事・採用・総務・情シス・プロジェクト・コーポレートガバナンスの 6 領域を 1 つの基盤で扱うマルチテナント BtoB SaaS『DRESS CODE』を、アジア 5 カ国・多言語で展開しています。認証基盤は『DRESS CODE』の全機能から共通で呼ばれる土台に位置しています。本セッションでは、BtoB SaaS のマルチテナント認証基盤をどう設計し、それを Control Plane という設計思想でどう束ね、これからどう育てていくかをお話しします。 創業期に採用したマネージド認証サービスから、ヘッドレスな OSS 認証基盤群である Ory の組み合わせへ移行した背景を共有します。グローバル展開・データレジデンシー・ポータビリティといった事業要件と、認証 UI を自社で握りたいという狙いから、「必要な機能を必要なときに足せる土台」を選んだ意図を紐解きます。 その上で、全テナントを横断する Control Plane を、インフラ・BFF・バックエンドの 3 層でどう多層防御しているかを共有します。 最後に、AI エージェント時代に向けて業界各社が示している方向性を踏まえ、Dress Code がその先にどう進んでいくかを共有します。私たちは全テナントの操作を Business Operation Event として体系的に蓄積する仕組みを Platform Capabilities として備えており、データの土台はすでに積み上がっている状態です。その上に、人間用に組んだ多層防御の哲学を地続きで拡張し、『DRESS CODE』を IdP として育てていくロードマップを構成図とともに示します。

7/11 14:20 - 14:40

TBD

TBD

7/11 14:20 - 14:40

泥臭く始める一人目SREの生存戦略、戦略的属人化による運用肥大化からの脱却

SRE において「SLI/SLO の策定」や「開発チームへのイネーブリング」は、よく挙がる代表的な取り組みです。しかし、急成長を遂げるスケールアップ期のスタートアップの現場に1人目の正社員SREとして加わった際、現実に立ちはだかるのは、最優先されてきた事業成長の裏側にある技術負債や専任不在によるインフラ運用の肥大化、それらに伴うリソースの枯渇といった組織が進化する過程で割けては通れない制約です。こうした理想と現実のギャップを埋め、いかにしてイネーブリングが機能し得る土台を築き、自身が目の前の運用に忙殺される状態から脱却し、本来のSRE活動へと組織をシフトさせていくのか。それが、1人目SREに課せられた真のミッションとなります。本セッションでは、入社から約半年で SRE 活動に踏み込める土台が整うまでの軌跡を「組織的な合意形成」「信頼の獲得」「運用の仕組み化」という3つのステップに分けてご紹介します。 具体的には、まずスタートアップにおけるSREの役割定義と、初期フェーズにおいてあえて泥臭い課題に飛び込むことの戦略的意義について触れます。その上で、発生する運用工数を他チームの負担を増やすことなく最小化し、インフラ屋になりすぎずに本来の活動へシフトするためのアプローチとその実践の軌跡をお話しします。 また、このアプローチを経て土台が整ったからこそ見えてきた、次のフェーズにおけるリアルな組織課題とこれからの展望についても共有します。泥臭い行動を戦略的な成果へ繋げ、組織に真のSREプラクティスを根付かせるための一歩を、皆さんと共に考える機会にできれば幸いです。

7/11 14:50 - 15:20

End-to-Endで考える信頼性 — LINEアプリにおけるクライアント開発×SRE連携の実践

LINEアプリでは、「アプリを開くと画面が正しく表示される」という当たり前の体験を、当たり前に届け続けることが求められます。しかしその裏側では、クライアント実装だけでも、サーバ運用だけでも語りきれない、多くの設計判断や運用上の工夫が積み重なっています。 本セッションは、実際に協業しているLINEアプリのクライアントエンジニアとSREによる共同登壇です。 ユーザーがLINEアプリを起動してから画面が表示されるまでの一連の体験をEnd-to-Endで捉え、信頼性を支えるために何を見て、どう設計し、障害時にどう切り分け、どう改善しているのかを、クライアント視点・SRE視点の両面から紹介します。 クライアントとサーバーの境界を越えて連携することで見えてきた課題や学び、そして「ユーザー体験としての信頼性」をどう実践しているのかを、具体例を交えて共有します。

7/11 14:50 - 15:20

SREとQA、二人三脚で進めるSLO運用

SREとQAは、どちらもプロダクトの安定性に関わる重要な役割でありながら、その視点やアプローチは異なります。estieでは、プロダクト数や機能数が増加する中で、SREとQAはそれぞれの視点からプロダクトの安定性という課題に向き合ってきました。今回、この二つのチームで協力し、それぞれの持つ強みを掛け合わせることで、新たな価値を実現することができました。 この発表では、SLO制定の取り組みを題材に、SREとQAがどのように連携し、価値を生み出してきたのかを紹介します。具体的には、QAによるテスト設計と自動化、SREによるCUJおよびSLIの定義を結びつけることで、ユーザ体験に基づいた品質と信頼性の確保を実現しました。この発表を通じ、異なる専門性を持つチームが協働することで単独では到達できない水準の安定性に近づけること、そのプロセスと学びについて共有します。

7/11 14:50 - 15:20

グローバル基準のSREは、運用現場でどう機能したか：成熟度アセスメントの実践

SREを任命し活動を始めたものの、実践の全体像が組織として見えにくい——こうした課題はエンタープライズ領域で広く見られます。SLA優先・障害ゼロ志向・責任分界・契約モデルといった構造が、個々のSREの活動を埋もれさせやすくするためです。各デリバリー部門でも、グローバル標準に基づきSREが任命されましたが、同じ課題に直面していました。さらに、エンタープライズ企業のミッションクリティカルなシステムを預かる立場では、複雑なマルチベンダー環境・厳格な変更管理プロセス・外部承認の多段階化が重なり、改善のサイクルを回すにはより多くの工夫が求められます。 私たちはこの課題に対し、社内のSRE実践基準に基づく成熟度アセスメントを組織横断に実施しました。可観測性、インシデント対応、自動化、改善活動、役割認識といった観点で評価した結果、"隠れたSRE実践"が体系的に可視化され、SRE本人に「自分は既にSREとして価値を発揮していた」という気づきと自信をもたらしました。他組織の実践も見えるようになり、学び合いと横展開が始まっています。 実施を通じて得られた気づきとして、評価軸を現在地に合わせて段階適用できるよう刻む余地があることが分かりました。これはアセスメント結果から見えた今後の検討課題であり、日本固有にとどまらず、外から来た原則を自組織の文脈で読み解く場面であれば同様に機能する可能性があると考えています。 このセッションでは、任命されたSREがなぜつまずきやすいのか、成熟度アセスメントをどう進め、何が変わったのかを、再現可能な形でお話しします。原則を自組織の文脈で読み解くプロセスそのものが、SREを前に進める力になります。

7/11 15:35 - 16:05

依頼文化をやめる日ーーEM視点で語るPlatformEngineeringとInclusiveSRE

300人規模・マルチプロダクト戦略推進という会社の転換期に、2名体制のPlatformチームのMgrであった私は日に日に不安が大きくなっていました。なぜなら当時のPlatformチームは新プロダクトが増えるたびにインフラ・監視・CI/CDの設定依頼が集中するという構造だったからです。 Platformチームが事業成長のボトルネックになる日は刻々と近づいていると感じていました。 チームメンバーから初めてEKS移行を提案されたとき、私は「リソースが限られたチームのEMとして、この投資判断は正しいのか」という迷いから決断ができませんでした。 本セッションでは、そんな状況の中で他チームのEMへのデモを通じて合意を取り付け、ようやくEKS移行にGoを出すまでの葛藤や、何を整理するべきだったのかという判断軸について実体験とともに語ります。 またGoを出した後も開発チームから上がり続けた「なぜ今やる必要があるのか？」という声にどのように対応していったのかや、転機となった出来事についても共有します。 Platformチームだけが信頼性を担う構造を変え、開発チームが自ら動ける状態へ。 EMという視点からInclusive SREの実践をお話しします。

7/11 15:35 - 16:05

TBD

GitHub Actions の self-hosted runner は、CI 基盤をセルフホストする上で強力な選択肢の1つです。一方で利用が拡大すると、プラットフォームチームにとって未知の多様なワークロードを大量に捌く必要が生まれ、さまざまな課題に直面します。そしてその課題の原因がユーザー起因／プラットフォーム起因／外部起因にまたがることで、改善の焦点が定まらない状態に陥りがちです。本セッションでは、弊社における self-hosted runner 基盤の改善の歴史を信頼性を軸に振り返り、今後の展望についてお話します。

7/11 15:35 - 16:05

SREプラクティスを複数のプロダクト・組織で自律的に回し続けるための仕組みづくり

KINTOテクノロジーズでは、SREをはじめ、クラウドインフラ、Platform Engineering、DBRE、CCoE、Security、QAなど、複数の横断組織が独立して活動しています。 私たちが関わるプロダクトはBtoBからBtoCまで大小さまざまあり、技術スタックや組織の成熟度、現場が優先すべき課題はプロダクトごとに大きく異なります。 そのため、SREのプラクティスを横断的に展開しようとすると、各プロダクトの事情に合わせた対応が難しい状況がありました。 こうした環境の中で私たちは、Central SREとして汎用的なSREプラクティスの実践や実装を進め、Embedded SREで各プロダクトの現場に合わせて適用・改善してきました。現在はこの形で複数プロダクトを支えており、そこで得た仕組みや知見をグループ会社への支援・展開にもつなげていくことを目指しています。 しかし対象が広がるほど、メンバーが毎回現場に伴走して知見を移植するだけでは時間も人手も足りなくなります。 限られたリソースで運用モデルをどうスケールさせるか。この問いに向き合う中で、運用の一部をagentとして補助する取り組みを始めました。 本セッションでは、この実践と試行錯誤の途中経過を共有します。 Central SREで作った仕組みやプラクティスをEmbedded SREで現場の文脈に合わせて適用・改善し、その知見を再利用可能な形に整えて、複数プロダクトやグループ会社への支援・展開につなげる。 この循環を人手だけに頼らず回し続けるにはどうすればよいか。その問いを軸に話を進めます。 まだ完成した形があるわけではありませんが、実際に試しながら見えてきた、人が担うべき責務とagentに任せられる補助の境界、そして両者が協業するための設計をどう考えるかについて、現時点の学びとして共有します。

7/11 16:20 - 16:50

CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則

こんな壁にぶつかった経験はないでしょうか。 CSに「SLO」と言っても「何それ？」と返される。経営層に「SLO 99.95%」と報告しても「ほぼ100%で問題ないよね」で終わる。SREのプラクティスは優れた仕組みですが、エンジニアの外に出た途端、言葉も温度感も通じなくなります。 私はSRE・情報システム・セキュリティの3領域を同時に統括するEMです。エンジニア側と非エンジニア側の両方を日常的に見ている立場だからこそ、「SREが届かない構造的な理由」と「届ける具体的な方法」が見えてきました。 本セッションでは、CS・経営層を含む非エンジニア部門にSREをIncludeする過程で直面した3つの壁──①専門用語の壁、②温度差の壁、③完璧主義の壁──と、それぞれを「翻訳レイヤー設計」「ビジネスインパクト変換」「役割別Include設計」で乗り越えた方法を共有します。 成果として、CS初期回答は30分から30%短縮、信頼性投資の承認は2ヶ月から60%改善。ただし、この道のりは一度の大きな失敗──全員に同じ理解を求めた完璧主義──から始まりました。重要なのは、全員に同じ理解を求めるのではなく「役割に応じた関わり方」を設計したこと。どの組織でも応用できるフレームワークとして、明日から使える設計テンプレートとともにお届けします。 --- SREの導入は進んだ。SLOもエラーバジェットも定着した。でも、それはエンジニア組織の中だけの話だった。 昨年のSRE NEXTで「管理職への翻訳」を確かめた後に残った問いが、「エンジニア以外の全員に、SREはどう届けられるか？」だ。 登壇後には「他の職種や領域へのスキル転用はどうするか」という問いが複数届いた。PMとの共通言語化を実践した後も、参加者から「他部門への展開は？」「持ち帰って実践できた」という声があった。本セッションは、その次の答えだ。

7/11 16:20 - 16:50

オブザーバビリティ、本当に活用できてる？―MCP×AIで成熟度を自動評価

「オブザーバビリティツールを導入したけど、チームによって活用度がバラバラ…」「セルフアセスメントをやってみたけど、主観的で形骸化してしまった…」。本セッションでは、こうした課題に対し、MCP Server（New Relic / Datadog）と生成AI（Claude）を組み合わせてデータ駆動型の成熟度評価を構築・展開した実践事例を紹介します。 評価基準には特定のツールに依存しない6軸×5段階の成熟度モデルを採用し、MCP経由で収集した実データをこのモデルに照らすことで、成熟度レベルの判定から具体的な改善アクションの生成までを自動化しています。 12以上のサービスチームへのオブザーバビリティ改善支援を進める中で、New Relic利用チームではMCPによる自動アセスメントも実施しており、対象は現在も拡大中です。Datadogへの展開も進行中です。全社展開で得た、チーム間の成熟度ギャップの傾向や評価精度向上の知見と、「生成AIの評価結果が実行ごとに異なる問題にプロンプト設計と評価基準の構造化でどう再現性を高めたか」「レポートをチームに読んでもらえる形にするまでの試行錯誤」といった失敗談もお伝えします。 SRE / Platform Engineeringチームでオブザーバビリティの全社推進を担当する方が対象です。成熟度モデルはOSS公開済みのため、セッション後すぐに自社での評価を始められます。

7/11 16:20 - 16:50

xREとの連携による「SREの一日」と組織的協業の実際

本発表では、外部からアンドパッドへ中途でジョインしたSREの視点から、その組織構造がいかに、成長する事業会社の課題解決に有効かを解説します。具体的に示すため、まず「弊社のSREのある１日」の姿をビフォー/アフターで対比します。 【ビフォー】 日々の依頼の優先順位をコントロールが難しい「便利屋SRE」の姿。 【アフター】 事業インパクトに基づき優先順位をコントロールし、サイト信頼性や Observability、トイル改善、Platform Engineeringなどのコアミッションに集中するSREの姿。 この変化は、SREのコアミッション以外をDBRE、CRE、FinOpsといった専門チーム（xRE）へ戦略的に「移譲」し、組織全体で信頼性やコスト最適化の責任に集中した結果です。 発表では、この組織的包摂を実現するためのアンドパッド独自のワークフローを「仕事の仕方全部見せ」として詳細に解説します。特に、インシデント対応、コストコントロール、DBチューニングなどのミッションを、各xREチームがどのように担い、SREとどのような具体的な連携メカニズムで協調しているのかを解説します。 この実践事例は、「SREプラクティスを組織全体で支える」ことで、マルチプロダクト環境の成長を加速させるための、具体的かつ実践的なヒントを参加者の皆様に提供します。

7/11 17:05 - 17:45

ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略

ソニー銀行では、ビジネスアジリティ向上を目指し、2013年からAWSを活用したクラウドシフト戦略を推進。 周辺系から移行に着手し、2019年には財務会計システム（総勘定元帳）をAWS上で稼働。 その上で、昨年クラウドネイティブな勘定系システムの構築を実現しました。 本セッションでは、こうした当社のクラウドシフト戦略について、事例を交えてご紹介します。