トーク

■ 発表カテゴリ
・Architecture: SREの視点からのシステム設計
・Culture: SRE文化の醸成と組織変革
・Future: SREの未来と新しいトレンド

■ 発表概要（400字程度）
生成AIを用いたシステム開発・運用が急速に普及してきましたが、一方で生成AIとの共存が課題となっています。本セッションでは、生成AIを用いたシステム開発・運用において、なぜこれまで以上にSREのプラクティスが重要になってくるのか、その理由を述べ、その対策として求められるSREのプラクティスを振り返ります。また同時に、生成AIがあるからこそ、よりその価値が高まるプラクティスについても解説します。本セッションを聞くことで、今後のシステム開発・運用において、生成AIとSREが両輪となって、開発者、運用担当者、さらには他の多くの部署の人々にとって大きな価値をもたらす枠組みを理解できます。

■ 発表の詳細（1000字程度）
2025年10月現在の生成AIツールは大規模言語モデル（LLM）ベースのものです。LLMベースの生成AIは、指示に対してもっともらしい出力を生成する一方で、注意深く利用しないと人間が期待しない結果を混入させるなど、まだまだその利用において課題が多い状況です。現在の生成AIツールの利用に関しての議論は、特に個人〜小規模チームでの開発（機能の実装）の話を中心としたものがほとんどで、その成果物をどのように安全に本番環境に導入し、そして安定して運用していくかについては多く語られていません。

本セッションでは、SREで挙げられている継続的インテグレーション（CI）、Infrastructure as Code、カナリアリリース、オブザーバビリティ、インシデントレスポンス、ポストモーテムといった各種プラクティスが、なぜ生成AIを前提とした開発・運用プロセスにおいて重要なのかを「生成」「分析・調査」「要約」の3つの点から解説します。

まず「生成」に関して。生成されたコードの安全性に大きく寄与するのはテストです。CIによって機能要件だけでなく、非機能要件（特に性能品質）にまで及んでテストを行うことが今後ますます重要となります。またIaCの設定も生成AIで行う事例が増えていますが、これも必ずテストが必要です。危険な設定項目が変更されていないかなど、SREにおいて推奨されている事前チェックが活きてきます。テスト後のリリースでも障害範囲を最小限に抑えるためにカナリアリリースといったSREが推奨するリリース戦略が効果を発揮します。

次に「分析・調査」です。先にも述べたように生成AIは、多くを出力することに目が向きがちですが、その結果の精度を上げるためには適切なコンテキストが必要です。その観点では、実は運用こそ有効に活用できます。IaCはまさにシステムの設計・仕様と実際をつなぐ重要なコンテキストです。IaCが静的なコンテキストとすれば、オブザーバビリティは動的なコンテキストです。何が起きているかを理解する上で、オブザーバビリティは障害の原因究明のための大きなヒントとなります。

最後に「要約」です。生成AIによりインシデントレスポンスやポストモーテムにおいて、雑多にメモされ、かつ様々な場所に置かれた情報を整理して要約することで、SREに必要な文書生成の効率が大きく向上します。

このようなさまざまなSREプラクティスが生成AIを前提とした開発・運用で、効果を発揮し、また効率を上げられるということを一つ一つ解説していきます。

■ 対象聴衆とその人たちが得られるもの
実際にSREをいま実践している人々も、SREを実践していない人も、また生成AIの活用を積極的に行っている人も、これから導入を検討している人も、すべての人々が生成AIが普及した新しい時代のシステム開発や運用において、SREの価値がより高まることを理解できるようになります。

■ なぜこのトピックについて話したいのか（モチベーション）
私は日本においてSREが普及しはじめるころから、その啓蒙を積極的に行い、そのために日本のSREコミュニティにとって普及する価値があると考える多くの英語版の関連技術書籍を翻訳してきました。そんな中、技術者は生成AIという新たな道具を手に入れ、その普及が広まる中で、開発者・運用者不要論を唱えるような人まで出てきました。しかし、実際にはそのためには生成AIを正しく振る舞わせるためのコンテキストが重要で、そのための活動は実はSREで言われているようなプラクティスそのものが意味をなすということはあまり知られていないように感じます。

このような背景から、SREを知っている人には改めて新たな価値を認識してもらい、SREを知らなかった人にも新たに関心を持ってもらいたいと考えて本セッションを応募しました。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
多くのSRE組織が、サービス信頼性の向上に注力する一方で、「社内情報システム」や「セキュリティ」という隣接領域との連携不足に課題を感じていませんか？
私は「重複したタスクを対応する」などの課題を実感しています。

SRE・社内情報システム・セキュリティ3領域を同時にマネジメントする中でSREの考え方やプラクティスを活用することでシナジーを創出しました。
・SLO/SLIの設定と計測 → ヘルプデスク対応の期待値設定とコントロール
・サービスの信頼性向上 → プロアクティブなセキュリティ対策
・エラーバジェットの運用 → 経営イシューとなるセキュリティリスク管理と意思決定

本セッションでは、SREからキャリアを広げたい方、社内情報システムやセキュリティを主務としていてSREに興味がある方に「次のキャリアに向けたTips」「SREのプラクティスがいかに汎用的かという学び」を提供します。

■ 発表の詳細（1000字程度）
以下のアジェンダでお話します。

1. SRE / 社内情報システム / セキュリティの課題（6分）
   ・現代の多くの組織で、SRE・情報システム・セキュリティが分断されて運営されていることによる課題がある。
   　・重複する作業領域や兼務による非効率
   　　・「サービスの信頼性を高める」という目的は一緒だが、手段が異なるので重複する
   　・インシデント対応時の責任範囲の曖昧さ
   　　・組織的に縦割りになってしまう or どちらもボールを取りに行ってしまい、効率的に動きにくい
   　・技術選定における最適化の困難さ
   　　・ナレッジの相互共有やスキルトランスファーがされにくい

2. SRE / 社内情報システム / セキュリティで統合型マネジメントをやってみた（8分）
   ・最初は責任範囲の対立やコミュニケーションコストの多さでうまく行かなかったので、以下を推進した。
   　・各領域の責任範囲定義 / 相互依存関係の設計
   　・コミュニケーション手法、意思決定プロセス
   　・KPI設計
   ・限られた時間とリソースの中で「何をやり、何をやらないか」を判断し、リソースをどう配分するか？の組織戦略。
   ・「攻めのSRE」を体現するためのTips。

3. SREのプラクティスをどう適用したか？（8分）
   ・「事業成長を支える部門」という切り口で共通しているので、以下を対応した。
   　・SLO/SLIの設定と計測 → ヘルプデスク対応の期待値設定とコントロール
   　・サービスの信頼性向上 → プロアクティブなセキュリティ対策
   　・エラーバジェットの運用 → 経営イシューとなるセキュリティリスク管理と意思決定
   ・これらの推進がシナジー創出に繋がり、結果としてエンジニアリングマネージャーが取り組むべき「組織の成果の最大化」に寄与した。

4. 適材適所を実現する人材マネジメント（5分）
   ・SREが「組織成果の最大化」を実現するために工夫したこと。
   　・人のReliabilityの見極め方
   　・キャリアパス設計
   　・モチベーション管理
   ・SREの次のキャリアとしてエンジニアリングマネージャーを目指すことの優位性。

5. 持ち帰ってほしいこと（3分）
   ・SREのプラクティスはさまざまな領域に活かすことができるし、次のキャリアに必ず役に立つ。
   ・SREはぜひ社内情報システムやセキュリティにもチャレンジしてほしい。

■ 対象聴衆とその人たちが得られるもの
■対象聴衆

1. SRE組織のマネージャー・リーダー
   ・組織拡張や体制変更を検討している方
   ・他部署との連携課題を抱えている方
   ・チームの価値創造を向上させたい方
2. 事業にもっと貢献したいSRE
   ・部門横断的な効率化を模索している方
   ・限られたリソースで最大効果を求められている方
3. 急成長企業のエンジニアリングマネージャー
   ・急速な組織拡張に直面している方
   ・上場準備やガバナンス強化を求められている方
   ・事業成長とシステム信頼性の両立を目指している方

■聴衆が得られるもの

1. SREのプラクティスを中心とした実践可能な組織運営手法
   ・3領域統合の具体的なフレームワークと実装手順
   ・緊急時の組織拡張戦略とタイムライン設計
   ・効果的な責任範囲定義とコミュニケーション手法
2. 人材マネジメントのノウハウ
   ・多様なスキルセットを持つエンジニアの適材適所配置手法
   ・クロスファンクショナルな人材育成アプローチ
   ・モチベーション管理と継続的成長を促す仕組み
3. 文化変革の実践手法
   ・SRE文化の他部署への浸透方法
   ・継続的改善を促進する組織風土の醸成
4. キャリアパスの拡張
   ・SREと◯◯を掛け合わせたキャリア設計
   ・組織横断的なリーダーシップの発揮方法

■ なぜこのトピックについて話したいのか（モチベーション）
■個人的な体験と学び
私自身がSRE・社内情報システム・セキュリティの3領域を同時にマネジメントするという、そこまで同じロールの方が多くない珍しい経験をしている。
この経験を通じて、従来の縦割り組織では実現できない大きなシナジー効果と価値創造の可能性を実感し、また「SREのプラクティスの汎用性と可能性」について論じたいと考えた。

■SREコミュニティへの貢献意識
SRE NEXTで登壇者やコアスタッフを務める中で、SREコミュニティの発展に貢献したいという想いがあり、多くのSRE組織が組織運営や他部署との連携で課題を抱えている現状を見る中で、私の実践経験が同じような課題を持つ方々の参考になればと考えている。
特に、SREの枠を超えた統合的なアプローチは、まだ体系化されていない分野であり、実践例を共有することで業界全体の発展に寄与できると信じている。
また、この挑戦を通じてSREのキャリアの可能性を実感した。

■組織変革への情熱
「組織の成果の最大化」という目標に向けて、常に新しい組織運営手法にチャレンジしている。
3領域統合マネジメントも、その挑戦の一つ。このチャレンジが成功体験となったことで、他の組織でも同様の価値創造が可能であると考えおり、SRE Kaigi 2026のテーマである「Challenge SRE !」にまさに合致する、組織変革への挑戦を共有することで、聴講する方にきっかけや熱量を提供したい。

総じて理論的な話ではなく、実際に現場で使える知識とノウハウと明日からすぐに活用できる実践的な手法を届けたい。

■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください

・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
本発表では、2021年頃からSREのプラクティスをサイトに導入し、サイトから基幹システム含めてモダナイゼーションの過渡期にある現在に至るまで、モノタロウにおけるSREの軌跡と現状、今後の展望を共有します。
3,4 年に渡り運用してきた SLO ベースでのサイト運用で見えてきた課題、当初の想定とのギャップ、サイトとは異なる基幹システム特有のSLI/SLO設計と実装の困難さ、SRE のプラクティスだけだと届かないオブザーバビリティの重要性についての話、プラットフォームエンジニアリング部門の組成に伴う SRE のあり方の変化、数値に基づく運用の過程で見えてきた開発生産性に関わる話に至るまで、今まであまり公開されていなかった取り組みについて赤裸々に紹介します。
SREが取り巻く環境の変化に立ち向かっている方々へ、実践的な示唆を提供します。

■ 発表の詳細（1000字程度）

◯SRE導入の背景と変遷
モノタロウが2021年頃にSREプラクティスを導入した背景、当時のシステム構成と課題を説明します。
SLI/SLOベースの運用を通じて見えた課題についても掘り下げていきます。

• SLOからシステムのボトルネックが特定できない話
• SLOの見直し = ただ目標値を緩めるだけになってしまっている話
• バックエンドAPIやバッチシステムに対して SLI/SLO 運用があまりフィットしない話

◯SRE導入効果と想定とのギャップ
当初の想定

• サービスレベルを代表するアラートが確かなものならば、その他不要なアラートは削減できるのではないか
• エラーバジェットポリシーに基づく運用が進めば、リリース頻度の改善やユーザ体験の話に議論が広がるのではないか
• ビジネス側とのやり取りとの共通言語になりうるのではないか

それらの想定に対して、達成できた部分とそうでない部分があるのでそこを紹介します。

◯オブザーバビリティの重要性
SLO展開を進める中で見えてきた技術的な課題、特にオブザーバビリティの重要性について言及します。
サービスの異常を知らせるフロントサイドに近い部分でのバーンレートのアラートから、バックエンドやインフラ側のボトルネックを特定するために足りていなかった部分を掘り下げて、オブザーバビリティ向上にどう取り組んだかを Datadog の利用実績をベースに話します。

◯部門横断的なSLO展開の課題とアプローチ
モダナイゼーションが普及する中で、組織もプラットフォームエンジニアリング部門が組成されました。
プラットフォームエンジニアリング部門という開発部門では中立的な立場にある中で、複数の開発部門にまたがってどのように SRE のプラクティスを適用していったかについて紹介します。

特に、SRE のプラクティスが展開しにくい基幹システム側へのアプローチについて深掘りをします。
レガシーシステム故の計装の困難さ、業務の複雑さからくる CUJ の策定のハードル、バッチシステムを多く含むアーキテクチャに対する SLO の設計の難易度など、多くの課題を紹介したのち、我々が取り組んでいることを話します。

◯数値に基づく運用から開発生産性の議論に発展した話
サービスの信頼性について数値での議論をしていく中で、DevOps Four Keys を代表とする開発生産性指標に話が発展していきました。
開発と運用のバランスの議論の中で、どのように開発生産性指標が活用されていったか、現在はどのような指標を見ているのかについて紹介します。

◯今後のSREプラクティスの展望
モダナイゼーションの過渡期にある我々が、これからSREのプラクティスをどのように進化させていくか、その展望を共有します。

■ 対象聴衆とその人たちが得られるもの
◯対象聴衆

• 規模の大きい組織でSREを推進している方や、複数の部門を横断する形でSLO展開に課題を感じている方
• サイトから遠い部分（基幹システムやバッチシステム）での SLI/SLO 設計と実装に苦しんでいる方
• 数年にわたるSLOベースでの運用が組織にどのような変化をもたらすのかを知りたい方

◯得られるもの

• 大規模組織におけるSREプラクティスの導入から運用、そして継続的な改善に至るまでの具体的な事例
• 複数部門・多様なシステムへのSLO展開における課題と、それらを乗り越えるための実践的な知見
• SRE推進における技術的・組織的な課題へのアプローチと、成功・失敗から得られる教訓
• SREの現在地を把握し、自身の組織でのSREプラクティスをさらに発展させるためのヒント

■ なぜこのトピックについて話したいのか（モチベーション）
昨今の目まぐるしい環境の変化に伴って、SRE のあり方は常に考えないといけないテーマになっていると思います。

弊社も、システムモダナイゼーションの過程で組織が変化し、プラットフォームエンジニアリング、オブザーバビリティ、AI駆動開発、開発生産性、様々なテーマで取り巻く関心毎が変わり続けています。私自身、様々な場面で SRE とはなんなんだろう、どうあるべきなんだろうと常に頭を悩ませてきました。今もそうです。

弊社は、2022年のテックブログにてSREに関する記事が公開されて以降、徐々に知見が蓄積されてきているにも関わらず、あまり公の場で話す機会がありませんでした。
https://tech-blog.monotaro.com/entry/2022/09/13/090000

モノタロウは「SRE は価値のある取り組み」と考えた上で数年に渡り継続して実践しています。そのことを皆さんに知っていただきたいです。

SRE じゃ無くてもいいんじゃないか、別のアプローチがあるんじゃないか、SREに取り組んでいる方々で悩まれている方はいると思います。
我々の事例の共有を通じて、SREの奥深さと、それがもたらす可能性について、共に議論を深めたいという強いモチベーションがあります。

■ スポンサー企業名
Dress Code株式会社

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）
世の中的にセキュリティ規制や設計判断の難しさが増す中、「どこまで守れば十分なのか」「結論が出ずに進まない」といった意思決定の迷いは多くのエンジニアが抱える課題だと感じています。今回、約1ヶ月でマイナンバー管理システムの設計・実装を行うにあたって、個人情報保護委員会のガイドラインを設計判断の"制約"として捉えることで、データ分類に応じた暗号化方針、取扱範囲を限定するアクセス制御、組織単位でのリソース分離など、信頼性と運用性を重視した迅速でブレない設計判断を実現しました。本発表では、法的制約下での具体的な設計プロセスを紹介しながら、SRE の現場でも頻発する判断基準のブレ、場当たり的な設計、記録不在による手戻りにいかに対処してきたかを話し、現場に存在する制約を改めて正面から見つめ直すことが、設計品質と開発スピードの両立への鍵となるという気づきを共有します。自分たちでサービスの信頼性を担保したいエンジニアや、日々の設計判断・意思決定に悩んでいる方々に、持ち帰れるヒントがあれば幸いです。

■ スポンサー企業名
株式会社MIXI

■ 発表カテゴリ
募集要項（ https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2 ） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法
・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
当セッションでは、MIXI GROUP全体のIaaS/SaaS管理におけるSRE実践のリアルを紹介します。
少人数チームながら、プロジェクトの自律的な開発文化を活かしつつ、徹底した自動化と標準化で「ちょうど良い統制」を実現。
IaaSではTerraformによる組織管理、SaaSでは資産棚卸しツールの自動化でコスト最適化に挑戦しました。
SREの手法をどのように組織全体に対して適用し、信頼性と効率を高めたのか――その実践知をお伝えします。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
創業時、当社のインフラはさくらのクラウド上へマネージドサービスをほぼ使わず構築していましたが、その後AWSの移管や、複数プロダクトの立ち上げ、SRE専任チームの立ち上げなどの変遷を紹介します。

会社設立半年でテックリードが退職し、一人でSaaSの信頼性・セキュリティを支える日々が始まりました。当時MariaDBのGalera Clusterを4台マルチマスター構成で運用していましたが、利用者増加に伴いデッドロックやノード障害が頻発。夜も眠れない状況を脱するため、AWSへの全面移行を決断し、将来の複数プロダクト展開やSRE組織立ち上げを見据えてEKSでの構築やTerraformを導入しました。
本発表では、この移行と並行した複数プロダクト立ち上げ、ID基盤統合、SRE専任組織の立ち上げ、SLI/SLO策定、コスト最適化・セキュリティ強化までの道のりを共有します。

■ 発表の詳細（1000字程度）
創業時、当社のインフラはさくらのクラウド上に、マネージドサービスをほぼ使わず構築していました。インフラ担当は当初テックリードと私の2名でしたが、会社設立から半年でテックリードが退職。以後、一人で全運用を担うことになりました。
エンタープライズ企業も利用するSaaSとして求められるセキュリティ・可用性水準は高く、日々の負担は大きく、障害対応やセキュリティ施策、キャパシティプランニングなど基本的に一人で抱えていました。

1. 創業初期に直面した課題
   ・当時のDBはMariaDBのGalera Cluster（4台マルチマスター構成）
   ・利用者増によりデッドロックが頻発し、パフォーマンスが不安定に
   ・1台がダウン → 再構築してクラスタに組み込むも膨大なデータ同期が間に合わず、4台→3台に
   ・さらに障害が起こればサービス停止リスクが増大
   ・不安から精神的負担も日々増加

2. AWSへの全面移行と基盤再構築
   ・このままでは持続的運用は困難と判断し、 AWSへの全面移行を決断
   ・将来の複数プロダクト展開やSRE組織立ち上げを見据え
   　- EKSベースで再構築
   　- Terraform によるIaC導入
   　- モジュール設計やCI/CD統合などスケールを見越した構成を整備

3. 複数プロダクト化とID基盤統合
   ・移行と並行して新規プロダクト開発が開始
   ・スピードを優先し、別AWSアカウント上にECSで構築・リリースすることに
   ・その後、既存プロダクトをEKSに移植
   ・複数プロダクトを以下で統合
   　- Amazon Cognito＋Amazon API GatewayによるID基盤
   　- 共通管理画面アプリケーションも新規開発

4. SREチームの立ち上げと運用高度化
   ・初のSRE専任正社員を採用し、SREチームを立ち上げ
   ・以下の取り組みを少人数で並行して実施
   ・SLI/SLO策定とモニタリング体制の整備
   ・インフラコスト最適化とセキュリティ強化
   ・新規プロダクト立ち上げも継続

5. 現在と本発表の目的
   ・現在はDB基盤の再構築やAI基盤の検討など、新たな挑戦を継続中
   ・一人で始めたSRE活動がどのようにチームへと発展していったかを時系列で共有
   ・限られた人員で複数プロダクトを支えるための実践知と学びを提供

■ 対象聴衆とその人たちが得られるもの
【対象聴衆】
・急成長企業の技術責任者（1人で抱え込んでいらっしゃる方）
・これから限られた人員の中でSRE立ち上げを検討されている方
・複数のプロダクトを限られた人員で運用しているSREの方

【聴講者が得られるもの】
・少人数・人的制約下でのSRE活動の始め方
・アーキテクチャの見直しやSREの立ち上げといった、技術的・組織的な決断をする意思決定プロセスにおいて重視するべき事柄

■ なぜこのトピックについて話したいのか（モチベーション）
一人での運用から始まり、限られたリソースの中でSRE組織を立ち上げ、複数プロダクトを支えるまでの道のりは試行錯誤の連続でした。同じように一人で責任を追っている技術責任者や、これからSRE組織を立ち上げようとしている方々に、実体験に基づくリアルな学びを届けたいと考えています。

■ 発表カテゴリ
・ Case Studies: 実際の導入事例や失敗談
・ Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）
Sansanの経理DXサービス「Bill One」では、2023年に外部IDaaSからAmazon Cognitoと自前OIDCサーバーを組み合わせた認証基盤へ無停止移行を行い、インフラコストを大幅に削減しました。
この取り組みは急速なユーザー増加によって顕在化したコスト課題の解決を出発点としましたが、最終的には「セキュリティと利便性」を両立する認証基盤として全社展開を進めるプロジェクトへと発展しています。AI契約データベース「Contract One」への導入を皮切りに、今後はSansan全体の社内標準として広がっていく予定です。
本発表では、当時40万人規模のユーザーを抱える環境での無停止でのシステム移行のノウハウ、少数体制でも運用可能なシステム構成とコスト最適化の工夫、さらに横展開での課題や社内標準化に向けたロードマップを共有します。

■ 発表の詳細（1000字程度）
○ 少数精鋭で運用可能な認証基盤のシステム構成
Bill Oneの認証基盤は、開発チーム3〜4名という少人数体制で開発・運用を行ってきました。限られたリソースでも高い信頼性を維持するため、ECS FargateやAurora Serverless v2、ElastiCache Serverlessなどのマネージドサービスを積極的に活用し、運用負荷を最小化しました。特にAurora ServerlessのオートスケーリングはBill One特有の「月末月初にアクセスが集中する」という特性への対応で非常に役立っています。また、Aurora Serverlessではクエリのパフォーマンスがコストに直結しますが、運用開始後もクエリの改善を継続的に行うことでコストの最適化を実践しています。

○ 無停止で基盤移行をするためのノウハウ
認証基盤の移行は、サービス影響を最小限に抑えるため「無停止」で実施しました。
そのために重要だったのは以下の点です。

• OpenID Connectの採用によりIdPを切り替えるだけで移行を実現できる構成
• 段階的リリースとロールバック可能な仕組みを組み合わせたリスクコントロール
• 新基盤へのログイン情報の自動移行によるユーザー影響の最小化

この仕組みにより、ユーザー体験を損なうことなく基盤の全面切替に成功しました。

○ 認証基盤内製化の成果と課題

• コスト削減：従来のIDaaS利用時と比較してインフラコストを大幅に削減
• 内製化による自由度の向上：内製化により独自の機能が実装しやすくなりログイン体験の改善がスムーズに
• 横展開による効果：Contract Oneへの導入でさらにコスト削減、プロダクト横断で統一したログイン体験を提供
• 新たな課題：マルチテナント構成でのデータ偏りによる性能悪化などの問題が顕在化。これを契機にテナントごとのオブザーバビリティの整備やDBチューニングの重要性を再認識
• プロダクトセキュリティへの貢献：WAF運用や不正ログイン対策を共通基盤で集中管理することで、個別対応の運用負荷を削減

○ 社内標準化に向けたロードマップ
従来、Sansanの各プロダクトは独自に認証基盤を構築しており、セキュリティレベルやUXにばらつきがありました。今回の内製認証基盤を社内標準とすることで、以下のメリットを目指しています。

• 開発者にとっての効率性：共通基盤により認証機能実装の重複を排除しプロダクトの開発に集中できる環境へ
• エンドユーザーにとっての利便性：共通のログイン体験を提供
• セキュリティ強化：共通基盤として継続的に運用改善を行うことで最新の脅威に対応

認証基盤は一度作ると塩漬けにされがちですが、実際には攻撃の巧妙化や新しい要件に日々対応する必要があります。本取り組みを通じ、認証を「維持コストのかかる仕組み」ではなく「セキュリティと利便性を両立する社内プラットフォーム」へと進化させていきます。

■ 対象聴衆とその人たちが得られるもの
対象聴衆

• 認証・認可基盤を担当するプラットフォームエンジニア
• サービス開発側で認証基盤やプラットフォームとの連携責任を持つエンジニア
• SRE・インフラ担当者で信頼性・コスト最適化をテーマとする技術者
• システム移行や基盤横展開の実例を知りたい技術者

得られるもの

• 認証基盤を内製する際に直面する設計判断やトレードオフ・コスト最適化
• 大規模ユーザー向けシステムを無停止で移行する実践ノウハウ
• 認証基盤を横展開・標準化するための戦略と実際の課題

■ なぜこのトピックについて話したいのか（モチベーション）
認証・認可は多くのWebサービスにとって欠かせない仕組みでありながら、“作って終わり” になりがちです。しかし実際には、セキュリティ・利便性・コストのすべてに継続的な改善が求められる領域です。
Bill Oneの認証基盤の内製化に深く関わる中で多くの苦労や工夫を経験し、そこから得た知見を「成功体験」だけでなく「失敗や学び」も含めて共有し、Webサービスがより良い仕組みを整えていく上での参考になればと思っています。
また、この取り組みは単なるプロダクト内の改善にとどまらず、社内の複数プロダクトへの横展開・ひいては社内標準へと発展しようとしています。SREの視点から見れば、信頼性・コスト・運用性が交錯する非常に挑戦的な事例であり、「Challenge SRE!」という本カンファレンスのテーマにも直結しています。
この発表を通じて、認証という地味だが本質的に重い領域に挑戦する仲間に、新しい視点と実践的な知見を提供したいと考えています。

■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください

・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）
伝えたいことの結論：SRE とプロダクトエンジニアの分断を防ぐにはプロダクトエンジニアが SRE 観点を持つことが重要である。プロダクトエンジニアも SRE の観点を持つことで、分断を超え、信頼性向上の重要な推進力となり得る。

このセッションでは、「SRE とプロダクトエンジニアは何故分断されてしまうのか」というテーマで、元 SRE で現在プロダクトエンジニアとして両者の分断の原因を掘り下げ、解決策を紹介します。プロダクトエンジニアが SRE の観点を持つことで、信頼性向上とプロダクト開発のバランスを取る重要性を実体験を交えて解説します。

■ 発表の詳細（1000字程度）
私自身、以前は SRE チームに所属していましたが、当時はプロダクトチームに対して「何故 SLO 達成に向けて時間を割いて動いてくれないのか」「データベースのバージョンアップに対してオーナーシップを持とうとする人が何故こんなにも少ないのか」と感じることがありました。

しかし、いざプロダクトチームに所属し、エンジニアとして機能開発に携わるようになってみると、分断が発生する理由が明確化しました。

【なぜ分断は起きるのか？〜3 つの原因〜】

1. SRE チーム → プロダクトチームという依頼構造が固定化しやすい
2. 「SRE チーム 対 プロダクトチーム」 = 「1 対 多」 の構造になりがちなため、SRE が各プロダクトチームの内情を把握する難易度が高い
3. 共にユーザーに対する価値提供を目的としているが、重視する観点が異なる

【分断をなくすための 2 つのアプローチ】
上述した 3 つの理由を踏まえると、分断を改善するためのアプローチは以下のようになります。

1. 「依頼待ち」から「自発的実行」へ: プロダクトチームが SRE 関連タスクを自ら発見し、実施する
   一方向での依頼関係を解消し、プロダクトチームに対して SRE チームがリスペクトを感じるシーンが増えますし、プロダクトチームの状況を踏まえて SRE チームに関わるタスクを余裕を持って進めることができます。
   一方で、この構造では「SRE チームは不要なのでは？」という疑念を抱きがちになるため、SRE チームとしては、プロダクトチームが自発的に SRE 関連のタスクを進めやすいようなプラットフォームづくりを行うことが大切です。

2. 「共通の目標」を持つ: SLO やデプロイ回数など共通する目標を設定し、優先順位のズレをなくす 重視する観点が異なるのは、基本的には目標に由来することです。
   プロダクトチームも SRE チームも、SLO やデプロイ回数のような目標をお互いに部分的に持つことにより、観点が統一され、優先順位の決め方も統一化されていくことになります。

【成果】
プロダクトチーム主導で以下の活動に取り組み、SRE チームを巻き込みながら以下のことを達成することができました。

• SLO の自律的監視と改善: 10 秒以上かかっていた API を 1 秒以下に短縮し、エラーバジェットを回復
• デプロイフローの高速化: GitHub Actions のワークフローを改善したり変更をこまめにリリースできる仕組みを作り、リリース起因のインシデントの影響を削減

■ 対象聴衆とその人たちが得られるもの
【対象聴衆】

• プロダクト開発エンジニア
• SRE
• 開発チームリーダー

【このセッションで得られるもの】

• SRE とプロダクト開発の分断を解消する具体的なアプローチ
• 信頼性向上と開発効率のバランスを取るための実践的手法
• SRE の観点をチームに浸透させ、変化を生み出すためのヒント

■ なぜこのトピックについて話したいのか（モチベーション）
SRE とプロダクト開発チーム間の「分断」は、多くの組織が直面する共通の課題で、私自身 SRE として活動する中でプロダクトチームとの連携の難しさを痛感しました。このセッションでは SRE の専門知識がプロダクト開発に浸透し、チーム間の自律的な連携が生まれる文化を醸成したことにより、「分断」を解消できた経験をお話します。そして、参加者の皆様にこの普遍的な課題への具体的な解決策と信頼性向上への新たな視点を提供できればと思います。

■ 発表カテゴリ
Architecture: SREの視点からのシステム設計
Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
Web アプリケーションとバッチ処理で構築された金融機関向けプロダクトを、本番稼働を止めることなく大規模にリアーキテクチャした実践事例を紹介します。成長に伴い複雑化する顧客要件に対応するため、DB スキーマレベルから再設計することを決断しました。SRE としては、信頼性を高める設計と、顧客影響を最小化する移行戦略の両面に取り組みました。

信頼性を高めるシステム設計

• DB パフォーマンスの改善
• 異常時に再実行で修正可能なバッチ実装
• ドライランモードの導入
• 処理時間 SLO を守るための監視と運用

顧客影響を最小限に抑える移行戦略

• 本番相当データを用いた性能検証と QA
• 新旧バッチ並行稼働して差分を確認

また、バッチ処理に ETL ライクな段階的データフローを導入することで拡張性を高めることにも成功しました。設計・移行・運用の各局面で、SRE がどのように信頼性を担保し、移行を成功に導いたのかを余すことなく共有します。

■ 発表の詳細（1000字程度）
以下の内容でお話します。

イントロダクション

• 法人のあらゆるリスク情報の変化を追跡するプロダクト、「SimpleMonitor」について
• モニタリングしたい法人を登録するとリスク評価に関わる重要な情報・属性に変化が生じた際にアラートを上げる
• シンプルフォーム社が収集した独自データを元に様々な検知項目でアラートを上げることができる
• 金融機関を中心に導入が進む中、より複雑な条件や複数の検知項目を組み合わせたアラート設定のニーズが高まっていた

既存アーキテクチャが機能開発のボトルネックに

• DB スキーマ的に検知項目 x 顧客毎に細かいパラメータを設定することができず、複雑な検知条件を記述できない
• 検知項目毎にクラスを切ってロジックを実装しており、複数の検知項目を組み合わせたアラートの実装が非常に困難
• アプリケーションはデータの流れに応じて 3 層構造で実装されており、検知項目を新規で追加する場合は 3 層分のロジックを新規実装する必要があり、拡張性が低かった
• 1 週間スプリントで毎週リリースする体制にも関わらず、新規の検知項目を実装するのに 1 ヶ月かかることもあった

新アーキテクチャの設計

• 顧客毎に使いたい検知項目とパラメータを自由に設定できる DB スキーマを導入
• バッチ処理を「イベントの抽出」と「検知条件に応じたイベントのフィルタリング」の二段構えの ETL 型のデータフローに変更
• バッチ基盤に ECS、Ruby on Rails、Sidekiq を選んだ理由

信頼性を高めるための設計・運用

• 新アーキテクチャのパフォーマンス上の利点
• 異常発生時のロールバック及び再実行をやり易くするバッチ構成
• dry-run モードを実装してリハーサル実行を行う
• バッチの処理時間に SLO を設けて監視を導入

顧客影響を最小限に抑える移行戦略

• できるだけ本番環境に近づけた検証環境を用意し、より精緻な QA や負荷検証を実施
• 過渡期は新旧バッチを並行稼働させ、作成されたアラートの差分を確認してバグを検知
• 旧基盤からのデータ移行

リアーキテクチャ後の成果、まとめ

• 移行の経緯と結果
• 移行前と比べて拡張性がどう改善したか
• 失敗談、得られた教訓

■ 対象聴衆とその人たちが得られるもの

• プロダクトの設計レベルから信頼性を高めていきたい SRE エンジニア
• バッチ処理の運用や設計に携わっているエンジニア
• プロダクトのリアーキテクチャを検討しているエンジニア

聴講者は具体的な事例から以下のような知見を持ち帰ることができます。

• SRE 観点でのバッチ処理の設計・運用の工夫
• 拡張性の高い ETL ライクなデータ処理フローの設計事例
• 稼働を止めずにデータやシステムを移行したノウハウ

■ なぜこのトピックについて話したいのか（モチベーション）
一般的に、SRE がインフラや非機能面に関わることはあっても、アプリケーション設計にまで踏み込む機会はそれほど多くないかもしれません。実際、多くの開発組織では SWE と SRE の役割がある程度分かれており、アプリケーションレイヤーを SWE が主導するのは自然なことだと私も考えています。
一方で、もし設計段階から SRE が積極的に関与できれば、アジリティと信頼性の両立が可能になるのではないかとも思います。
本セッションでは、プロダクトのリアーキテクチャを契機として、SRE が設計レベルから参画することで得られた成果を紹介します。SRE が自らのコンフォートゾーンを越えて挑戦することの価値について、ぜひ具体的な事例を元にお伝えできればと考えています！

■ 発表カテゴリ
・Culture: SRE文化の醸成と組織変革

■ 発表概要（400字程度）
「いつまで私たちはここに関わり続けるのか？」Embedded SREとして開発チームに伴走する中で生まれた問いが、計画的なExit戦略の策定につながりました。本発表では、従来の「なんとなく関わり、なんとなく分業する」SREサポートから脱却し、明確な目標と期限を持った知識移転プログラムへと転換した経緯と実践を共有します。Knowledge Transfer MatrixとConfidence Scoreという定量的な手法を用いて、OpenTelemetry、Terraform、Kubernetesなどの技術スタックにおける知識移転の進捗を可視化。単なる技術移転ではなく、開発者がSREマインドセットを内在化し、自らオーナーシップを持って運用できる文化醸成までの道のりを共有します。Embedded SREという役割の「成功」が自らの役割の終焉を意味するパラドックスと、その先にあるSREの在り方について、実体験に基づいた考察と提言を行います。

■ 発表の詳細（1000字程度）

問題の本質：「なんとなく」の関係性

Embedded SREとして日々プロダクトの課題に向き合う中で、ふと疑問が湧きました。「いつまで私たちはこのチームに関わり続けるのだろうか？」振り返ってみれば、これまでのSREサポートは「なんとなく関わり、なんとなく分業する」状態でした。明確なゴールもなく、終わりも見えない。これでは開発チームはいつまでもSREに依存し、SREは限られたリソースを特定チームに固定し続けることになります。
社内を見渡せば、同様のサポートを必要としている開発組織が複数存在します。この状況を打破するには、Embedded SREという役割に明確な「終わり」を設計する必要がありました。

Exit戦略への転換点

転換点は、開発者との直接対話でした。「Exitに向かって協業していきましょう」という提案に対し、開発者から前向きな合意を得られたことで、両者の意識が大きく変わったように感じます。これまでの「サポートする側／される側」という関係から、「共通の目標に向かって並走するパートナー」へ。目標を共有し、期限を設定することで、両者の行動に明確な意図と責任が生まれることを期待しています。

Knowledge Transfer Matrixによる可視化

知識移転を「なんとなく」ではなく、計画的に進めるため、Knowledge Transfer Matrixという仕組みを利用しました。
このマトリックスは、縦軸に技術領域（OpenTelemetry Collector設定、Terraform管理、Kubernetes運用、GCPサービス活用など）を配置し、横軸に開発メンバーを並べ、各交点に1から10のConfidence Scoreを自己評価で記入する形式です。
自己評価方式を採用することで、開発者自身が「何を知らないか」を自覚し、主体的な学習意欲を引き出す効果も狙っています。さらに、スコアの推移を可視化することで、個人とチーム全体の成長を実感できる仕組みとしました。この定量化により、感覚的だった「知識移転」が、測定可能で改善可能なプロセスへと変わりました。

ロードマップの設計思想

Exit戦略は大きく基盤構築期と自立移行期の2つのフェーズで設計しています。
基盤構築期では、まず現状の可視化と課題の洗い出しから始め、自動化可能な領域を特定して実装を進めます。この期間はペアワークを通じた基礎的な知識移転に重点を置き、開発者がSREの視点や考え方を理解する土台を作ります。
続く自立移行期では、開発者主導での運用タスク実行へと段階的に移行し、SREの役割はメンタリングとレビューへと徐々にシフトしていきます。最終的にはオフィスアワーでの相談役として、必要な時にサポートする形を目指します。
両フェーズを通じて協働とペアリングを重視し、一度にすべてを引き渡すのではなく、小さな成功体験を積み重ねながら徐々に責任と権限を移譲していくことが、このロードマップの核となる思想です。

パラドックスが示すEmbedded SREの価値

Embedded SREの「成功」とは、自らが不要になることです。この一見矛盾した目標設定こそが、Embedded SREの本質的価値を体現しています。特定チームに固定されることなく、より多くの開発組織に価値を提供し、組織全体のレジリエンスを向上させる。
この実践で得られた知識移転の方法論やツールは、他の開発チームにも適用可能な形で標準化し、全社的なSREプラクティスとして展開することを視野に入れています。一つのチームでの「終わり」が、より大きなスケールでの「始まり」となる。それがEmbedded SREのExit戦略が目指す姿です。

期待される効果と課題

このアプローチでは次のような効果を期待しています。開発者の主体性向上として、自己評価を通じた学習意欲の醸成。SREリソースの最適化により、より多くのチームへの支援が可能に。そして知識の民主化として、特定個人への依存から組織的な能力への転換です。
一方で、開発者の負荷増加への配慮、適切なペースの見極め、モチベーション維持など、実践を通じて解決すべき課題も想定されます。発表時点での実際の成果と課題を、包み隠さず共有する予定です。

■ 対象聴衆とその人たちが得られるもの

対象聴衆：

• 複数の開発チームを限られたリソースでサポートしているSREチーム
• 開発チームへの知識移転に課題を感じているSRE/DevOpsエンジニア
• SREプラクティスの標準化・展開を推進する立場の方
• 開発チームとSREチームの協業方法を模索している方

得られるもの：

• 「なんとなく」の関係から脱却し、明確な目標を持った協業への転換方法
• Knowledge Transfer MatrixとConfidence Scoreによる知識移転の定量化手法
• 開発者との合意形成と段階的な責任移譲のアプローチ
• 計画的なExit戦略の設計思想と実践的なヒント

■ なぜこのトピックについて話したいのか（モチベーション）
「いつまで関わり続けるのか」という個人的な疑問から始まったこの取り組みは、SREという役割の在り方そのものを再考する機会となりました。
限られたSREリソースで増え続けるサービスの信頼性を担保するには、従来のサポートモデルでは限界があります。開発チーム自身がSREとしてのスキルと考え方を獲得し、自律的に高い信頼性を維持できる組織を作ることが、持続可能な解決策だと考えています。
Embedded SREは、永続的な役割ではなく、開発チームが自立するまでの期間限定のミッションであるべきです。そしてその「終わり」を意図的に設計することこそが、プロフェッショナルとしての責任だと考えています。
この発表を通じて、同じように「なんとなく」のサポートを続けている方々に、計画的なExit戦略という選択肢があることを伝えたいと思います。それは決して無責任な撤退ではなく、チームの成長を信じ、より多くの価値を組織全体に提供するための、戦略的で前向きな決断なのです。
まだ実践の途中ですが、だからこそ生々しい課題や発見を共有できると考えています。SREの在り方について考える機会になれば幸いです。

■ 発表カテゴリ
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
BCP（事業継続計画）は企業存続のために中長期的に必要な施策です。SmartHRではSREチームがプロダクト観点でのBCPを担当しており、主にリージョン障害時のDR（ディザスタリカバリ）戦略を検討しています。

通常、BCPではRTO（目標復旧時間）、RPO（目標復旧時点）といった復旧目標を先に設定し、それに基づいてDR戦略を検討するのがセオリーです。しかし、この復旧目標設定では「事業を止めたくない」という要求と「コストを抑えたい」という相反する要求の間でトレードオフが発生します。このバランス調整が難しく、BCPを進める上での大きな障壁となっています。

私たちは、このセオリーをあえて覆し、復旧目標を先に決めず、最小限のコストで実現できるDR戦略から着手する「小さく始めるBCP」を実践しました。これは挑戦的なアプローチでしたが、多プロダクトを抱える私たちにとっては、最短でBCPを進めるための最善策となりました。

BCPを策定する方々が直面する課題を解決する一つのアプローチとして、私たちの実践から得た学びをご紹介します。

■ 発表の詳細（1000字程度）
アジェンダは以下を想定しています。

1. BCPとは
   • BCPが企業にとって必要である理由
     • 緊急時でもサービスを提供ができるようにする
     • BCPを策定していることでお客様から信頼を得られる
   • BCPにおけるDR戦略の標準的なアプローチ
     • 一般的にRTO（目標復旧時間）とRPO（目標復旧時点）などの復旧目標を最初に設定し、それに基づいてDR戦略を立てていく
   • BCPの普及を妨げる現実的な課題
     • BCPは企業にとって重要な施策であるにもかかわらずスキルや人材の不足により、全体の企業の約20%しか対策を立てられていない
2. SmartHRのプロダクトの現状とBCPにおける課題
   • SmartHRの多数のプロダクトと相互依存関係
   • リージョン障害に対する対策が万全ではない状況
3. 復旧目標（RTO・RPO）を決めないという選択
   • 多プロダクトにおける復旧目標設定における課題
     • 課題1: 理想的な復旧目標と技術コストのトレードオフ
     • 課題2: 各プロダクトで必要な復旧レベルが異なる
     • その結果、DR戦略の方針やどの程度のコストをかけるべきか判断できない
   • 「最小限のコスト」で始める方針
     • 理想的な復旧目標は誰も正解を知らないため、復旧目標は決めず「最小限のコスト」で対策を考えていくことから始めた
     • セオリーに反して挑戦的なアプローチではあったが、小さく始めることでDR戦略も考えやすくなった
4. 最小限のコストで実現できるDR戦略
   • 最優先で行うべきプロダクトを選定
     • 全てのプロダクトに復旧対策を行うのは費用対効果が低い
     • プロダクト間の依存関係を整理し、すべてのプロダクトに影響を与えるコアプロダクトを特定して最優先で対応
     • 最終的に最優先と判断されたプロダクトを直近の対応スコープとして設定
   • 現状のアーキテクチャでマルチリージョンに対応をしていない箇所を特定
   • 最小限のコストで行うため、全体の方針としては「コールドスタンバイ」を採用
     • アプリケーションサーバー（Cloud Run）はTerraformを利用した別リージョンへの復旧
     • データベース（AlloyDB）は定期バックアップを取得しておき障害時にリストアを実行
   • 復旧手順書の作成
   • 復旧手順書に基づいた机上訓練の実施
5. 今後について
   • 現実的なDR戦略をベースにした復旧目標の設定
   • 優先度の高い次プロダクトに対するDR戦略の段階的検討

■ 対象聴衆とその人たちが得られるもの

対象聴衆

• BCPの構築を検討している方
• DR戦略について考えている方

得られるもの

• 小さくBCPを始めるためのヒント
• 最小限のコストでDR戦略を立てる時のアプローチ

■ なぜこのトピックについて話したいのか（モチベーション）
BCPは企業の成長フェーズによって必要な対策が様々に変化します。また、プロダクトの特性によってもDR戦略も異なります。このような様々な変数がある中でBCPを構築するのは非常に困難で、参考情報も限られています。そのため、小さく始めるための最初の一歩として何をすべきかを実体験ベースで共有することで、今後BCPを検討する方々に少しでも役立つヒントを提供できればと考え、このトピックを選びました。

■ 発表カテゴリ
・Tech: SREを支える具体的な技術や手法
・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計
・Future: SREの未来と新しいトレンド
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
AI/LLMの可能性を知り、従来のやり方に疑問を感じました。AIの普及は開発・拡張速度を向上させるため、SREの考え方である「仕組み化・自動化によるスケール」をAIで実現する「AI-Nativeな次世代SRE」を目指すべきだと確信しました。

そのために、昨年10月から内製AI Agent「IBIS」(Incident Buddy and Insight System)の開発を開始。IBISは、インシデント対応の相棒となるAI Agentです。

本発表では、このIBISを軸とした我々の挑戦と得た経験、そしてSREの未来像についてお話しします。

■ 発表の詳細（1000字程度）
AI/LLMが世界を変えたこと、そしてこれからも変えていくことは、もはや多くの人にとって共通の認識だと思います。
では、我々SREは、このパラダイムシフトにどう向き合うべきでしょうか？クラウドの台頭やSREの誕生がそうであったように、今、新たな時代の幕が開けようとしています。

我々の答えは、AIの力を最大限に活用し、SREのあり方を再定義することでした。その挑戦から生まれたのが、内製AI Agent「IBIS」(Incident Buddy and Insight System)です。

インシデント対応中、ログの海に溺れ、原因究明に時間を浪費していませんか？
属人化問題や、オンコール対応およびインシデント管理にコストが増え続けているといった課題を抱えていませんか？
IBISは、まさにその課題を解決するために誕生しました。人間のSREsの相棒となり、様々なインシデント対応をサポートしていくことを目指しています。

本発表では、私たちがIBISの開発を通じて得た知見や、AI-Nativeなインシデント管理の全体像について、惜しみなく共有します。
2025年2月にIBISの存在を公表して以来、私たちは着実に開発を進めてきました。これまで伝えきれなかった、AI-Native化の最新の現状や、具体的な事例もご紹介します。
そしてメルカリグループが推進する「AI-Native Incident Managementプロジェクト」の全容もお話しします。

IBISを知っている方も、まだ知らない方も、AIと共に切り拓くSREの未来に関心を持っていただける内容になると思います。

■ 対象聴衆とその人たちが得られるもの

• これからSREに必要な知識、技術
• AI Agentの基礎知識と開発方法
• AI Agent開発で得た知見
• 周辺技術の基礎知識
  • e.g., Vector search, RAG, etc
• 失敗事例
• 成功事例
• メルカリグループのAI-Native インシデント管理プロジェクトの内容を知れる

■ なぜこのトピックについて話したいのか（モチベーション）

• 社外に対して： IBISの技術と運用ノウハウを公開することで、AI Agent開発に関心を持つエンジニアコミュニティに貢献し、オープンな議論を促したいと考えています。これは、AI技術の発展と業界全体のレベルアップにつながると信じています。
• 社内に対して： 開発の背景や成果を社内外に発信することで、社内ユーザーがIBISの価値を深く理解できるようになります。これにより、よりスムーズな導入やオンボーディングが可能となり、社内での活用がさらに加速することを期待しています。

■ 発表カテゴリ

• Tech: SREを支える具体的な技術や手法
• Practices: SREの実践例と得られた教訓
• Architecture: SREの視点からのシステム設計
• Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

10年稼働するプロダクトの月間数億レコードのアクセスログが、プロダクト間共有RDB運用の限界に達し、無停止移行が急務となりました。この移行は組織・技術における領域横断的な能力が求められ、単一領域だけでは解決困難でした。そこでアプリケーションエンジニアの筆者がSRE精神を発揮し、自身のケイパビリティを拡張してこの困難な移行プロジェクトにチャレンジしました。

本セッションでは2つのトピックをお話しします。

1. 月間数億レコードのアクセスログ移行における技術的知見

CloudWatch Logs エージェント、Amazon Data Firehose、Athena、AWS Glueを駆使したParquet形式+Snappy圧縮による月間数億レコードの無停止移行設計と、データ重複・欠損問題の解決策。

2. 領域を超えたSRE精神の発揮

既存の役割を超えたSREマインドの実践と、組織を巻き込む信頼性向上の方法論を紹介します。

■ 発表の詳細（1000字程度）

1. 背景：アクセスログのRDB運用の限界

筆者は10年稼働するプロダクトのテックリードとして、月間数億レコードを超えるアクセスログをプロダクト間共有RDBで運用していました。このログは開発者の障害調査だけでなく、カスタマーサービスの顧客対応などでも利用される重要なデータです。しかし運用が限界に達しており、さらに組織的な事情により数ヶ月以内での移行が求められる状況でした。

2. 挑戦：アプリケーションエンジニアのSREチャレンジ

この課題解決には組織の領域横断的なスキルが求められ、単一領域だけでは解決困難でした。筆者はSRE領域のケイパビリティが不足していましたが、「システムの信頼性に重要なアクセスログが失われる」という危機感からSRE精神を発揮し、自身のケイパビリティを拡張してこの移行プロジェクトにチャレンジしました。

2-1. アクセスログ移行の技術的詳細

• CloudWatch Logs エージェント、Amazon Data Firehose、Athena、リアルタイムログ収集・閲覧設計
• AWS Glueを駆使したParquet形式+Snappy圧縮によるデータ量・コスト削減
• 管理画面を維持するためk8s上のRailsアプリケーションからAthenaを使う
• 最難関のデータ重複・欠損問題への対策
  • 初めてのAWSサポートケース起票
  • Amazon Data Firehoseを用いたログ収集設計における見落としと教訓
  • k8s上のSidekiq運用におけるpreStop戦略

2-2. 領域を超えたSRE精神の発揮

• ステークホルダー分析と要件の可視化（共有RDB利用の他プロダクト、データチーム、インフラチーム）
• SREチームとの協業で足りないケイパビリティを補う
  • インフラ設計
  • 慣れないk8s/terraformを用いたインフラ構築
• 技術的な制約をビジネス要件に翻訳して関係者調整
• 段階的リリース戦略による無停止移行
• 既存の役割を超えて誰でもSREマインドで行動できること
• 組織を巻き込んで信頼性向上を実現する方法論
  • 普段から領域を横断して関係性を築くこと

本セッションでは、これらの技術実装の詳細と、アプリケーションエンジニアが領域を横断し、組織と協力して信頼性向上に取り組んだプロセスとプラクティスを実体験ベースでお話しします。

■ 対象聴衆とその人たちが得られるもの

1. 技術的知見
   • 月間数億レコード規模のアクセスログを無停止で移行する具体的な戦略とアーキテクチャ
   • CloudWatch Logs エージェント、Amazon Data Firehose、Athena、AWS Glue を駆使したParquet形式+Snappy圧縮の実践的な活用法
   • Rails + Athena を用いたアクセスログ検索システムの構築
   • データ重複・欠損問題の対策
2. SRE実践のプラクティス
   • アプリケーションエンジニアでも、自身のケイパビリティを拡張してSRE精神を発揮できるという実例
   • 組織横断的なプロジェクトを推進するためのステークホルダーの巻き込み方、調整の仕方
   • 専門チームと連携して自身に足りないケイパビリティを拡張する方法

■ なぜこのトピックについて話したいのか（モチベーション）

この移行プロジェクトで得られた技術的知見は、類似の課題に直面するエンジニアの参考になると考えています。月間数億レコード規模のアクセスログ基盤のアーキテクチャ移行という課題への実践的なアプローチを共有することで、コミュニティに貢献したいと思います。

また、筆者は「SREは役職ではなく、魂」だと考えています。
組織においてSREの役職ではない筆者が、信頼性の高いシステム構築・運用における課題に Challenge し、実際に解決した経験をお話しすることで、SREが役職に縛られない、より自由なものであるということをお伝えしたいです。

■ 発表カテゴリ
・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
SREの現場では、障害を防ぐだけではなく、避けられないエラーや過負荷にどう向き合うかが重要です。多数のクライアントが多様なサービスとリアルタイムに通信するLINEでは、停止か稼働かの二択ではなく、段階的に劣化しながら体験を守る「グレースフル」な設計を重視しています。

1. 障害の連鎖を防ぎ、全体影響を局所化する サーキットブレイカー
2. リトライや瞬間的な高負荷を適応的に抑制する アダプティブレイトリミッター
3. ユーザー体験を優先度付けして守る コンテキストアウェアなロードシェディング
4. 鮮度が求められる情報のための クライアント側エラーハンドリング
5. 安全に進めるための カナリーリリースとトラフィック制御
6. 開発段階から健全性を確認する カジュアルな負荷試験

これらを通じて「なめらかに劣化しても信頼性を維持する」LINEの実践を共有します。本発表では導入したプラクティスだけではなく、これらの仕様に決定した際のチームでの議論も含めてお話します。

■ 発表の詳細（1000字程度）

本発表では、LINEにおけるSRE実践を「なぜその仕様に至ったか」という議論の経緯も交えながら紹介します。

まずは、 障害の連鎖を防ぐサーキットブレイカー 。複数サービスと連携する際、上流が応答せずタイムアウトすると、アプリ全体の表示が遅延する課題がありました。異常を検知すると一定時間リクエストを遮断する仕組みを導入し、障害の連鎖を防いでいます。

次に、 上流サービスを守るアダプティブレイトリミッター 。リトライや瞬間的なアクセス集中で想定外の負荷が生じ、上流をダウンさせる恐れがあります。単純なRPS上限設定では柔軟性に欠けるため、上流から返されるエラー率や種類に応じて制御を動的に調整する仕組みを導入しました。

続いて、 過負荷時の体験を守るロードシェディング 。LINEアプリは多くをキャッシュするため、過負荷時には全リクエストを処理する必要はありません。リフレッシュ要求を後回しにし、新規コンテンツ取得を優先する「コンテキストアウェア」な仕組みによって、限られたリソースでもユーザー体験を守ります。

一方で古い情報が表示されるリスクも生じます。そこで、 応答不能時のエラーハンドリング として、鮮度が重要な情報に対してはクライアント側で追加の仕組みを実装。サーバー側に依存しないアプローチで、ユーザーが古い情報から誤った判断をしにくくしました。

さらに、 カナリーリリースとトラフィック制御 。一般的な10%先行リリースでは、単純なラウンドロビンだと不具合が全ユーザーに影響する恐れがあります。そこで影響範囲を明確に制御できる仕組みを取り入れ、安全にリリースできるようにしました。

最後に、 開発段階から健全性を確認するカジュアルな負荷試験 。従来のQAは機能検証が中心で、高負荷時の問題を事前に見つけにくい課題がありました。そのため、開発段階から簡易に負荷試験を実施できる環境を整備し、非機能要件の健全性を自然にチェックできる文化を育てています。

これらの取り組みを通じて、どのように「想定外を前提とする」設計を実現し、議論を経て現場に落とし込んできたかをお話しします。実例と背景を交えて紹介することで、皆さんの現場でも応用できるヒントを持ち帰っていただけるはずです。

■ 対象聴衆とその人たちが得られるもの

本発表は、ユーザー視点での信頼性向上を目指すSWEやSREを対象としています。クライアントサイドとサーバーサイドといった境界を越え、どのようにしてエンドツーエンドの信頼性を確保できるのか。その具体的な事例を持ち帰り、自らの現場に活かしていただけます。

■ なぜこのトピックについて話したいのか（モチベーション）

開発の現場では、エラー発生時の挙動に十分な配慮がなされないことが少なくありません。特にスケジュールに余裕がない場合や、再現の難しい障害への備えは後回しになりがちです。私自身も日々、優先度の判断に悩みながら、今取り組むべきことと後に回すことを天秤にかけつつ、チームと共にさまざまなプラクティスを導入してきました。その際のチームとの議論、どんな会話があったのかも含めてお話出来ることは貴重だと考えています。
同じような課題に直面しているSREの方も多いと考えています。本発表を通じて、そうした悩みを共有し、実践のヒントを提供できれば幸いです。

■ 発表カテゴリ

• Tech: SREを支える具体的な技術や手法
• Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）
皆さんの組織では、全体におけるSREの割合はどのくらいでしょうか？SmartHRでは現在4名のSREエンジニアがいます（2025/10現在）。一方で、プロダクト開発エンジニアは約200人、比率は1:50にもなり、チーム数は40以上にも及びます。さらに2025年5月にARR200億円に達し、5年後には売上1000億円を目指して急成長中です。

このような急成長環境の中で、SREチームのミッションは「日々増え続ける膨大なプロダクトチームが、信頼性に関する知識や経験を通して、適切な機能開発と信頼性への投資ができるようになること」であり、これが売上1000億円到達の鍵だと考えています。

しかしながら、SREはわずか4名です。個々のチームを丁寧に支援していくには時間が足りません。かといって、全体に薄く広く関わっても本質的な成果は得られないでしょう。

本発表では、このような課題を抱えながらもミッション達成に向けて行った「オブザーバビリティの導入」と「SLI/SLOの導入」のChallenge！と成果をご紹介します。

■ 発表の詳細（1000字程度）
概要でもお伝えした通り、SREチームは少人数のため、200名・38プロダクト規模のチームにJoinする形では時間も人も足りません。そのため、基本的にはEnabling（※1）として活動することになりますが、オブザーバビリティ基盤やSLI/SLOの導入・運用を各チームに任せきりにすると、プロダクトエンジニアの認知負荷が拡大し、本来事業を前に進めるための機能開発にリソースを割けなくなります。

また、SREチームはPlatformチーム（※2）としての役割も兼務しており、開発者がセルフサービスで高品質な開発・運用を行える環境（Paved Road / 舗装された道）を提供する必要があります。

このような状況の中で、Enabling/Platformチームとして活動しながら、50倍規模のチーム群の認知負荷を上げずにどのようにミッション達成をしていくのか。SREチームの立ち位置を前提に、オブザーバビリティとSLO導入の観点からお話します。

※1 チームトポロジーにおける「Enablingチーム」を指す。ここではSREの知見を複数のプロダクトチームに横断的に共有・支援する形態を「Enabling」と呼ぶ。
※2 チームトポロジーにおける「Platformチーム」を指す。具体的には開発・運用のための共通基盤（CI/CD、モニタリング、IaCなど）の設計、構築、提供などを指す。

1. 前提：組織体制とSREチームの立ち位置
   • SREチームはまだ始まったばかり！Enabling/Platformチームとしての役割
   • 急成長する"スケールアップ企業"におけるSREチームのミッションと課題
2. 高品質かつ効率的なオブザーバビリティ実現へのChallenge！
   • 本末転倒！？モニタリングが引き起こす認知/運用負荷の問題とその解決法
     • 自前でオブザーバビリティプラットフォームを構築する際の認知/運用負荷の問題
       • 独自実装によるプラットフォーム構築は専任チームによる運用が必須
       • 「OSS + マネージドサービス」でも保守作業が残り、トイルが発生する
     • 「オブザーバビリティプラットフォームSaaS」の活用という選択肢と決断
       • 「何でも作る」思考から「あえて作らない」選択へ — 事業の業務ドメインに集中する重要性
       • SaaS費用と認知/運用負荷軽減効果の比較、開発スピード維持のためのSaaS活用決断
   • SaaSを活用したオブザーバビリティ環境の構築
     • プロダクト開発チームが「すぐに」「わかりやすく」使えるダッシュボードの設計
       • SLO違反時に原因をすぐ特定できる「レスポンス劣化率」「パーセンタイル比較」「スローレスポンス履歴」の表示
       • 「SLOダッシュボードの歩き方」の策定と活用
     • 認知/運用負荷を最小化するプロダクトチームへの展開
       • レバレッジを効かせるダッシュボード構築のIaC化
       • 共通部分の部品化による構築工数の短縮
3. 少人数のSREチームによる全プロダクトチームへのSLO導入へのChallenge！
   • Enablingを開始する前の準備
     • SREチームとプロダクト開発チームの責任分界点の明確化
       • SRE：SLO計測の仕組みや運用環境の提供
       • プロダクト開発チーム：アプリケーション固有のSLO目標値の設定と達成
     • 自社文化に適したコミュニケーション方法の確立
       • 横断的な活動を促進するチャットツールの効果的な活用
       • SRE活動の可視化と定期的なロードマップ振り返り/共有の仕組み
   • 効果的なEnablingプラクティス
     • 「社内向けSLO導入ガイド」の策定と活用
       • CUJ（クリティカルユーザージャーニー）を軸としたSLI/SLO設計方法
       • 適切なSLOしきい値設定のために蓄積されたQ&A
     • 共通言語：「SLO星取表」による方向性の統一と進捗の可視化
       • Step毎に定義されたSLO運用の成熟レベルの可視化と事業目線でのメリット
       • 各プロダクトのSLO運用会議で星取表を見直し方向性を統一、SREチームのマネジメント負荷を軽減

■ 対象聴衆とその人たちが得られるもの
対象：拡大する組織で新しくSREチームを立ち上げたい方、少人数のSREチームでレバレッジの効かせ方に悩んでいる方、SREをまだ導入していないが開発チームに小規模に取り入れてみたい方
得られるもの：SREを小規模に始める際の実践的なアプローチ、機能開発のスピードを維持しながら（＝認知負荷を増やさずに）オブザーバビリティとSLOを導入する方法、そしてこれらの取り組みを支えるコミュニケーション方法の例

■ なぜこのトピックについて話したいのか（モチベーション）
現代の多くの組織がDevOpsを採用していますが、ほぼ確実に直面するのが認知負荷と運用負荷の増大です。また、IT人材不足によりSREに割けるリソースは限られており、「SREチームを立ち上げたものの、効果的な施策を実行できず失敗した」という事例もよく耳にします。こうした状況から、潤沢な人材リソースや高度な専門知識がなければSREは始められないという印象を持つ方も少なくありません。

しかし、SREはまだ発展途上の分野です。認知負荷と運用負荷を上げない形でSREのプラクティスを導入した実践例を共有することで、少人数でもSREのプラクティスを組織に効果的に取り入れることができます。これが信頼性を維持しながら事業成長を促進する第一歩となるため、本会議に参加する皆様と共に試行錯誤しながら前進していけることを願っています。

■ 発表カテゴリ

・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

医療分野のSaaSでは、サービス提供者、顧客、そして何よりも患者にとって、セキュリティと可用性が最重要です。

私たちカケハシは、4つ以上の薬局向けSaaSを開発・運用する中で、厳しい医療要件とマルチプロダクト展開の課題に直面しました。私たちの組織規模や事業フェーズでは、イネイブリングを担うSREチームのみならず、基盤システムを開発・運用する開発チーム自身が信頼性へのオーナーシップを持つことが最も効果的だと考えました。

このセッションでは、共通基盤の開発チームが主体となり、以下の課題にアーキテクチャレベルで取り組んだ事例を紹介します。

• 品質要求の相反
  高い可用性とセキュリティ要件を満たしつつ、データの整合性・一貫性も確保する必要がある
• 顧客データのトレーサビリティ欠如
  障害発生時の原因調査やコンプライアンス対応が困難

これらの取り組みにより、新プロダクト開発時の認証実装コストを大幅に削減し、障害発生時の原因特定にかかる時間を短縮することに成功しました。

本セッションを通じて、SREという役割を持たない開発チームが、いかにしてサービスの信頼性を向上させられるか、具体的な方法を提案します。

■ 発表の詳細（1000字程度）

背景

医療業界の特性

カケハシが提供するプロダクトのほとんどは医療情報システムとして患者情報を取り扱うため、セキュリティ要件が非常に厳しいことが特徴です。
例えば、厚労省・経産省・総務省が策定する通称「3省2ガイドライン」では、多要素認証の必須化、各種データの長期保存、パスワードポリシーの厳格化、監査ログの記録などが求められています。また、薬機法や個人情報保護法などの法令遵守も必要です。

加えて、可用性の高いシステム設計も求められます。医療機関は24時間365日稼働しており、システム障害が業務に与える影響は非常に大きいためです。
また、患者情報は非常にセンシティブな情報であるため、情報漏洩や不正アクセスを防止するための厳格なセキュリティ対策も不可欠です。一方で、薬局業界は法人間の薬局グループの統廃合が頻繁に発生するため、堅牢なテナント分離と柔軟な組織管理の両立が求められます。

マルチプロダクト展開

カケハシでは複数のプロダクトを展開している一方で、各プロダクトは独立した開発チームが担当しています。これにより、各チームは自律的にプロダクトの開発・運用を行うことができますが、同時に共通の課題として以下の点が挙げられます。

• 品質のばらつき
  各チームが独自に共通機能を実装しているため、セキュリティ要件の解釈や実装方法にばらつきが生じ、全体としての品質が低下するリスクがあります。
• 開発コストの増大
  各チームが同じような機能をゼロから実装するため、開発リソースが分散し、効率的な開発が難しくなります。

課題

品質要求の相反

認証基盤の刷新プロジェクトでは高い稼働率とセキュリティ要件を満たす必要がある一方で、ユーザー・店舗・組織などのディレクトリサービスでは稼働率に加えデータの整合性・一貫性が求められます。これらを両立するために、インフラアーキテクチャとアプリケーションアーキテクチャの両面で工夫が必要でした。

トレーサビリティの欠如

既存の顧客基盤では、最新のデータのみが保存され、過去に顧客がどのようなユーザー・店舗・端末・ライセンスなどを保持していたかの履歴が保存されていませんでした。そのため、障害発生時の原因調査や、顧客のコンプライアンス要件への対応が困難でした。

解決策

インフラレイヤ - データの永続化と配信

• PostgreSQLの行レベルセキュリティ
  顧客データを他の顧客から参照・変更できないようにするため、PostgreSQLの行レベルセキュリティを活用し、テーブルの行ごとに権限を制御しています。
• DynamoDBとOutboxパターン
  認証基盤では、高い稼働率と障害時の復旧容易性を実現するため、セッション情報などをDynamoDBに保存しています。また、ログイン履歴などの変更データを他プロダクトに配信するためのOutboxパターンについても解説します。
• Delta Lake形式によるデータ配信
  頻繁な変更が少ない顧客データ（ユーザー・店舗・組織など）はDelta Lake形式でS3に保存し、データ基盤や他プロダクトから参照できるようにしています。これにより、データの整合性を保ちながら、可用性とスケーラビリティを確保しています。さらに、Delta Lakeのタイムトラベル機能を活用することで、過去の状態を容易に再現できるようにしています。

アプリケーションレイヤ - データの整合性・一貫性とトレーサビリティの担保

• ドメインイベントの永続化
  顧客のユーザー・店舗・端末・ライセンスなどの変更履歴をドメインイベントとして保存し、過去の状態を再現できるようにしています。これにより、障害発生時の原因調査やコンプライアンス要件への対応が容易になります。また、既存の顧客基盤に対してはデータ基盤を経由してスナップショットからドメインイベントを生成し、システムのフルリプレイスを避けつつ、トレーサビリティを確保しました。
• マイクロサービスではなくサービスベースアーキテクチャの採用
  共通基盤が抱える顧客データは相互に強く関連し、強い整合性が求められます。そのため、マイクロサービスではなく、サービスベースアーキテクチャを採用し、単一のデータベースを共有することでデータの整合性を確保しています。加えて、各サービスではサービス間通信を原則禁止し、必要な場合は読み込み専用のDBユーザーを介してデータを参照する設計としています。

結果と教訓

結果

• 開発効率の向上
  認証・認可基盤を共通化したことで、新規プロダクト開発時にセキュリティ要件をゼロから考慮する必要がなくなり、開発者は本来のビジネスロジックに集中できるようになりました。
• 基盤の品質向上
  テナント分離とデータの整合性・一貫性、そして開発効率を両立するアーキテクチャを採用したことで、基盤全体の品質向上へ寄与しました。
• 障害調査時間の短縮
  顧客データの変更履歴をドメインイベントとして完全に追跡できるようにした結果、データ不整合や意図しない変更が発生した際の調査が容易になり、原因特定までの時間が大幅に短縮されました。

教訓

• RLSのマイグレーションとパフォーマンス
  誤った権限を適用するとデータ漏洩や欠損のリスクが生じます。
• スナップショットからのイベント生成の課題
  既存システムのデータをドメインイベントに変換する際、データの一貫性を保つために、イベント生成の順序やタイミングに注意が必要です。
• サービスベースアーキテクチャにおける共通ライブラリの危険性
  安易に共通ライブラリを導入すると、サービス間の結合度が高まり、独立したデプロイやスケーリングが困難になるリスクがあります。
• 即時性とのトレードオフ
  顧客データの変更を即時に他プロダクトに反映する必要がある場合、Delta Lake形式での保存は適さないことがあります。

関連する過去の公開資料:

• https://findy-tools.io/companies/kakehashi/91/97
• https://speakerdeck.com/kakehashi/building-an-authentication-platform-using-authlete-and-aws
• https://kakehashi-dev.hatenablog.com/entry/2024/09/19/110000

■ 対象聴衆とその人たちが得られるもの

• 非SREチームであっても主体的にサービスの信頼性を高めたいと考えている開発者、テックリード
  具体的なアーキテクチャ設計や実装例を通じて、信頼性向上のための実践的な手法を学べます。
• ミッションクリティカルなサービスにおいて、開発チームがどのようにセキュリティや可用性の向上に貢献できるかを知りたい方
  医療分野に限らず、厳しいセキュリティ要件や高可用性が求められるサービスにおいて、開発チームが果たすべき役割と具体的なアプローチを理解できます。

■ なぜこのトピックについて話したいのか（モチベーション）

マルチプロダクトSaaS企業に限らず、プロダクト同士が相互に連携するコンパウンドスタートアップでは、共通基盤の重要性が増しています。

しかし、多くの共通基盤チームはあくまでアプリケーションの開発者から構成されているため、SREのような専門的な役割を持たないことが一般的です。

そのような状況下で、限られたリソースしか持たない組織においても、開発チームが主体的にサービスの信頼性を高めることが可能であることを広く伝えたいと考えています。

医療業界に限らず、ミッションクリティカルな領域で日本や世界を支える開発者が、自らの手でサービスの信頼性を向上させ、ひいては人々の暮らしへ安寧をもたらすための一助となれば幸いです。

■ 発表カテゴリ

Tech: SREを支える具体的な技術や手法

■ 発表概要（400字程度）

「SLI/SLOは設定したが、運用に活かしきれていない。」「可観測性の重要性は理解しているが、経営陣にそのビジネス価値を説明できない。」—— そんな悩みを抱えるSREエンジニアは多いのではないでしょうか？

SREのミッションは、SLOを満たしながら開発速度と運用効率を高めることです。
我々は、運用効率向上には可観測性の最適化が最も効果的であると考えます。

一方で、ログやメトリクスの収集はしているが、その活用や、トレースの収集・活用は、個人の検証止まりでプロダクションへの導入に至っていないケースが少なくないと思います。
これらの根本原因は主に、①可観測性がもたらす具体的なビジネスインパクトを定量化できていない ②トレーシングが可観測性にどれほど貢献するかの見積もりができていない ③社内規約やコストが足かせになっている、であると考えています。

本セッションでは、SREエンジニアとして社内でトレーシング導入を検討している実例を基に、可観測性の向上を明確なビジネス価値へと結びつけるための実践的なアプローチをご紹介します。

■ 発表の詳細（1000字程度）

本セッションでは、可観測性向上をビジネス価値につなげる具体的な手法について、弊社のサービスとそのシステムを例に、5つのステップに分けてお話しします。

1: 現状の可観測性を把握する
まずは、可観測性を構成する3つの要素（ログ、メトリクス、トレース）のうち、今運用しているシステムで収集している要素、活用している要素を把握することが重要だと考えます。
また、トレーシングがどれだけそのシステムの可観測性に貢献できそうなのかを見積もることも重要です。
このステップでは、ステップ2以降に必要なこれらの内容を確認します。

2: ビジネスケースとしてあるべき形・効果を定義する
サービスに対してトレーシングは必須ではありませんが、サービスを提供するシステムが複雑している昨において、適切に考慮することで、ビジネスへの貢献が期待できると考えています。
このステップでは、ビジネス的な観点からトレーシングのあるべき姿を考えてみます。

3: コストに向き合う
コストは、計装方法やプロジェクトの成熟度合い、サンプリング戦略に大きく依存し、これらによって採算がとれるかが変わります。
このステップでは、初期コスト・ランニングコストの２つについて、具体的に見積もってみます。

4: 段階的導入戦略を考える
トレーシングに関わらず、新しい技術やツールの導入には、「社内規約やコストにより、SaaSの導入に時間がかかる」、「影響範囲や導入工数が見えづらく、導入が進まない」などのブロッカーが存在します。
このステップでは、我々が直面したこのような課題に対するアプローチについて考えてみます。

5: 合意形成に臨む
ステップ4まで検討が完了すれば、あとは関係者との合意形成を残すのみです。
弊社の組織構造を例に、合意形成に至るまでの作戦についてお話しします。

■ 対象

・前提知識：分散システム、可観測性に対する基本的な理解
・対象レベル：中級者向け
・プライマリターゲット：SREエンジニア、インフラエンジニア
・セカンダリターゲット：技術リードやマネージャー、CTOレベルの方

■ 得られるもの

・可観測性向上をビジネス価値につなげる具体例
・プロジェクトの成熟度に応じた段階的導入戦略
・経営陣との合意形成に使える具体例

■ なぜこのトピックについて話したいのか（モチベーション）

「技術的関心から○○を導入したいけど、お金を出してもらうためには経営陣（決裁者）の承認が必要…。でも、どのように納得していただくか…。」という経験をされたエンジニアの方々は多いのではないでしょうか。
我々も今まさに、トレーシングの導入に至る合意形成で奮闘中です。
SRE Kaigiを通じて、分散トレースに限らず、新たな技術・ツールを導入したい場合の提案手法の例を共有し、参加者の皆様から様々なご意見をいただきたいと思っています。

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓

■ 発表概要（400字程度）

アプリケーションのリリース起因の不具合や、クラウドサービスの設定ミスによって、本来不必要なコストが急増することがあります。このようなコストの急増（弊社では「コスト障害」と定義）への迅速な対応および再発防止には、過去のナレッジを開発組織内で共有することが重要です。

発表者は、コスト障害に関するナレッジの共有のため、SREのプラクティスであるポストモーテムをFinOpsに適用した「コスト版ポストモーテム」を提案・導入しました。そして、これを実際のコスト障害で試した結果、ポストモーテムだけでなく、その前後のワークフローもFinOpsに適用する必要があることに気づきました。

本セッションでは、コスト版ポストモーテムの導入に至った背景と、導入後に気づいた課題を、実際の事例に基づいて紹介します。そして、この課題を解決するために導入したコスト障害発生時のワークフローを紹介します。

■ 発表の詳細（1000字程度）

自分たちの現場でも本セッションのプラクティスを採用すべきか判断していただくために、はじめにコスト版ポストモーテムの提案に至った背景を説明します。

そして、コスト版ポストモーテムの提案と導入、およびその後の改善（コスト障害発生時のワークフローの整備）を、具体的な実例を交えて紹介します。

• 背景：インフラコスト削減の取り組み
  • 多数の開発チームによるマルチプロダクト開発
  • SREチーム単独でのインフラコスト削減の取り組みの限界
  • インフラコスト削減のため、2024年6月にSREとソフトウェア開発者の合同チームを結成
  • アーキテクチャ改善を含むコスト削減を実施し、目標を達成
• コスト版ポストモーテムの提案
  • コスト削減にもポストモーテムが必要と考えた理由
  • コスト版ポストモーテムの提案
  • アーキテクチャ改善によるコスト削減の実例
  • 実例に基づくプロトタイプ版の執筆
  • 開発本部内での共有およびアンケートの実施
• コスト版ポストモーテムの導入
  • コスト版ポストモーテムを書く2つのパターン
  • パターン1. アーキテクチャ改善後
  • パターン2. 予期せぬコストの急増への対応後
  • 予期せぬコストの急増の例：アプリの不具合によるインフラコストの急増
  • 導入してわかったこと1. ポストモーテムを書く以前の問題として、コスト障害に対する開発チームの優先度が上がらない
  • 導入してわかったこと2. ポストモーテムを書いたあとに、誰かが再発防止策を徹底させる役割を持つ必要がある
• コスト障害発生時のワークフローの整備
  • 基本的なアイディア：予期せぬコストの急増を障害のように扱う。通常の障害とは別に「コスト障害」を定義する
  • CREチームを中心としたアンドパッドの障害対応の体制
  • 従来の障害対応のワークフロー
  • コスト障害対応のワークフロー
  • 従来の障害対応のワークフローを踏襲した部分
  • 従来の障害対応のワークフローとは変えた部分
• まとめ

■ 対象聴衆とその人たちが得られるもの

対象聴衆

• インフラコスト削減に取り組むエンジニア（主にSRE、FinOpsエンジニア）

その人たちが得られるもの

• 開発組織を、予期せぬインフラコストの急増に対応できるようにするためのプラクティス（コスト版ポストモーテム、コスト障害対応のワークフロー）

■ なぜこのトピックについて話したいのか（モチベーション）

SREはインフラに精通しているため、インフラコスト削減の主導・実施を求められがちです。その一方、コストに関する取り組みは社外発表しづらいこともあり、なかなか他社の事例を聞く機会がありません。この発表が、SREのFinOps的な活動の共有を促すきっかけになることを期待しています。

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

クレジットカード決済を扱う企業に要求されるPCI DSSというセキュリティ基準をご存知でしょうか。年1回の更新審査、監査ログのレビュー、多段の承認フローなど、厳格なコンプライアンス要件が課されます。

当社では、私たちSREがこれらの監査対応と準拠環境の運用を担当しています。監査証跡の取得やログレビューを手作業で対応すれば、SREが疲弊することになります。

私たちはこの課題に対して、SRE自身の運用負荷を最小化しつつ、セキュリティ要件をインフラ基盤で吸収するアプローチを取りました。AWSアカウント分離によるスコープ最小化、ECS FargateやCognitoなどマネージドサービスのフル活用、CI/CDへのセキュリティチェック組み込みなど、基本的なセキュリティ対策の積み重ねにより、開発速度を損なわずに堅牢なインフラ基盤を構築しています。

本セッションでは、当社のAI家計簿サービスでのSRE実践を通じて、クレジットカード決済基盤で実践してきた具体的なアプローチを共有します。PCI DSSという厳格な制約から学んだ、セキュリティ要件を設計要素として扱うインフラ設計の考え方を紹介します。

■ 発表の詳細（1000字程度）

クレジットカード決済を扱う当社では、PCI DSS準拠が事業継続の必須要件です。年1回の更新審査では、審査月の1ヶ月は対応にかかりきりになります。監査ログのレビュー、承認フロー管理、監査証跡の収集など、SREが担う作業は多岐にわたります。

本セッションでは、私たちが実践してきた「セキュリティ要件をインフラ基盤で吸収する」アプローチを共有します。マネージドサービスの活用、自動化の徹底、環境分離によるスコープ最小化などにより、SRE自身の運用負荷を最小化しつつ堅牢なインフラ基盤を構築してきた方法をお話しします。

具体的な内容については以下を想定しております。

1. はじめに

• 当社のサービス紹介
  • AI家計簿プリカを提供
  • クレジットカード決済を取り扱うため、PCI DSS準拠が必須
• PCI DSSの具体的な厳しさ
  • 年1回の更新審査（審査月の1ヶ月は対応にかかりきり）
  • 監査証跡の取得、ログレビュー、承認フロー管理
  • 要件文書の解釈とセキュリティ社内規定の作成
• 当社でのSREの役割
  • 監査対応と準拠環境の運用を担当
  • これらをすべて手作業で対応すればSREが疲弊する
• セキュリティ要件をインフラで吸収するアプローチの必要性

2. アプローチ: セキュリティ要件をインフラで吸収する

• SRE自身の運用負荷を最小化する必要性
• パブリッククラウドの活用
  • AWSなどが公開しているホワイトペーパー、コンプライアンス準拠状況を参考に
  • 責任共有モデルの理解
• 基本方針の3つの柱
  • スコープの最小化
  • マネージドサービスの活用
  • 自動化の徹底
• これは一般的なクラウドネイティブなインフラ構築の考え方そのもの
  • 特別なことではなく、基本的なセキュリティ対策の積み重ね

3. 実践例

スコープの最小化

• AWSアカウント分離で準拠環境と非準拠環境を明確に分割
  • セキュリティリスクの分離
  • コンプライアンス対応コストの最小化
• 準拠環境・非準拠環境をまたぐバッチ処理の実装方法

マネージドサービスの活用

• PCI DSS準拠のマネージドサービスを積極的に活用
• コンテナ技術（ECS Fargate）
  • readonlyRootFilesystemを有効化し、マルウェア対策を実現
  • EC2と比較して、セキュリティ設定の管理工数を大幅に削減
• 認証基盤（Cognito）
  • 社内管理画面のログイン認証に活用
  • 多要素認証（MFA）の強化が要求されるPCI DSS v4.0準拠に役立った
• 暗号化管理（KMS）
  • 機密情報を暗号化、キーローテーション

自動化の徹底

• CI/CDパイプラインへのセキュリティチェック組み込み（ECRスキャン、Trivy）
• GuardDutyとLambdaによる異常検知の自動化
• 監査証跡の収集とレビューの省力化（セキュリティエリア入退室ログなど）
• PAN（カード番号）が非準拠環境で見つかった際に備えた自動検知機構
• 定期タスクのGitHub Issue自動作成で手作業を削減

4. 得られた知見

• PCI DSSの厳しさは確かにある
• しかし、SRE自身の運用負荷を減らす工夫を積み重ねることで対応できた
• セキュリティ要件は「制約」ではなく「基盤の設計要素」
• この考え方は一般的なWebアプリケーションでも応用可能

5. まとめ

• セキュリティ要件をインフラで吸収することで、SREの運用負荷を削減しつつ、開発速度を損なわない堅牢な基盤を構築できる

■ 対象聴衆とその人たちが得られるもの

対象聴衆

• クレジットカード決済を扱う企業がどういう制約や運用を求められるか気になるエンジニア
• SREとして運用負荷を抑えつつセキュリティを向上させたいエンジニア
• コンプライアンス対応に不安を感じているSRE

聴衆が得られるもの

• 体系的なコンプライアンス対応のアプローチ（SREの日常活動として実現する方法）
• 実践的なインフラ設計パターン（環境分離、マネージドサービス活用、自動化）
• セキュリティ要件を「制約」ではなく「基盤の設計要素」として扱う設計思想
• SRE運用負荷を削減しつつ、堅牢なインフラを構築する方法論

■ なぜこのトピックについて話したいのか（モチベーション）

私自身、FinTechスタートアップに入社するまでは「厳格なコンプライアンスに準拠したサービスのインフラってどんなものなんだろう。ガチガチで身動きが取れないんじゃないかな」と考えていました。

PCI DSSのような厳格な規制への対応は、たしかに企業に大きな負担をもたらします。しかし、適切なインフラ設計と自動化によってその影響を最小限に抑え、SRE自身の運用負荷を削減しつつセキュリティ向上を実現できることが分かってきました。それは自分が他業界のSREとしてやってきたものと同様の、基本的な取り組みの積み重ねによるものでした。

私たちがやっている日常的な業務は一般的なWebアプリケーション開発でも応用可能なプラクティスだと考えています。「コンプライアンス対応は特別なことではなく、SREの日常的な活動で実現できる」という視点を通じて、コンプライアンス対応やサービスのセキュリティレベル向上に取り組んでいる皆さんの実践を後押しできれば嬉しいです。

■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください

・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）
我々の組織は急成長を遂げている一方、最近になって障害が目立つようになってきました。そこで、我々は社内にSRE practiceを浸透させるべく奮闘していたのですが、様々な壁にぶち当たりうまくいきませんでした。そうした反省を踏まえて、我々は今Platform Engineeringの力を借りてこの壁を乗り越えようとしています。SRE Enablingにおけるの我々の苦悩、SREとPlatform Engineeringの結実など、有意義なトピックが豊富にあると思いますので、是非お聞きください！

以下お話しするトピックになります。

1. 我々の組織を取り巻く現在の状況
2. 我々はなぜこれまで”SRE”できてこれずにいたのか？
3. まずはやれるところから！Postmortemの運用刷新
4. Observability基盤の刷新
5. SREの日の出：準備はできた、さあ、Enablingやっていきましょう

■ 発表の詳細（1000字程度）

1. 我々の組織を取り巻く現在の状況
   私が所属するLegalOnTechnologiesを取り巻く最近の状況と、SREチームがSRE practiceを推進していくmotivationについて話します。ここで話す内容としては、以下のトピックになります。
   ・ 大型プロダクトローンチ以後機能開発を優先してきた結果、SLOなどのSRE practiceを導入してこれなかった(= SREチームは「インフラ屋」としてしか機能できていなかった)という現状
   ・ 最近になって障害が多発してきて、社内的にもこれをどうにかしないといけないという風潮
   ・ これを追い風として、今こそSRE practiceを社内に浸透させようという機運

2. 我々はなぜこれまで”SRE”できてこれずにいたのか？
   実はこれまで全くSREのpracticeの導入を試みてこなかったというわけではなく、機能開発に忙殺されながらも色々試みましたが、どれもうまくいきませんでした。ここでは、その失敗談を話したいと思います。
   ・ 適当なSLI/SLOを設定してしまったことによるAlert Storm
   ・ 開発者のObservabilityに対する感度
   ・ 形骸化してしまったPostmortem

3. まずはやれるところから！Postmortemの運用刷新
   現状のままではいけない、SREせねば！、ということでまずは手をつけやすそうなPostmortemの運用から見直すことにしました。具体的には以下のような取り組みについてお話しします。
   ・ 現状分析：「うわっ…私のPostmortem、分析足りなすぎ…？」
   ・ 運用方法＆テンプレート見直し
   ・ Postmortemをもう一度！開発者全員にPostmortemの重要性を説いた話

4. Observability基盤の刷新
   Observability周りを効率的に推進していくには、Platform Engineeringの力を駆使していくのが良いと判断しました。幸い、我々の組織では全社共通基盤のPlatformがあります。ここでは、このPlatformにObservabilityの要素を組み込んだ話をします
   ・ self-serviceを推進するアプリケーションプラットフォーム”Akupara”
   ・ ObservabilityツールをDatadogに移行した話
   ・ observability-kit / slo-kit：Platformを通した「人類皆SRE計画」

5. SREの日の出：準備はできた、さあ、Enablingやっていきましょう
   最後に、今後どのようにSREのEnablingを進めていくかについてお話しします。
   ・ Postmortemの推進
   ・ Observabilityの推進
   ・ SLO駆動開発

■ 対象聴衆とその人たちが得られるもの
対象聴衆
・ 組織にSRE practiceを浸透させることに苦戦されている方
・ SREの教科書にはない実際の経験談を聞きたい方
・ SREとPlatform Engineeringの協働の仕方に興味のある方

その人たちが得られるもの
・ SRE practiceを浸透させる際に踏んではいけないNGポイント
・ SRE practiceを浸透させるための一つの事例
・ ObservabilityをPlatform Engineeringの一部として扱う方法

■ なぜこのトピックについて話したいのか（モチベーション）
Site Reliability Engineeringに関する本はたくさんあれど、実際にそれをやっていこうと思うと様々な困難に出くわします。そうした話というのは、本では得ることのできない知識なので、是非登壇という形で多くの人に共有したいと思いました。また、SREとPlatform Engineeringの協働というのは最近ではちょこちょこ目にしますが、まだまだ事例としては少ない方だと思うので、是非弊社における事例を聞いていただくことで、お聞きいただいた方々の助けになるのではないかと思った次第です。