トーク

■ 発表カテゴリ

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

■ 発表概要（400字程度）

本発表では、SREエンジニアにとって、技術をビジネス価値に変えることの大切さを説明します。
私たちPanasonicのSREチームは、長年続くサービスにおいて、安定稼働と豊富な機能追加を目指して取り組んでいます。その一環として、可観測性向上についても挑戦を続けています。その結果、メトリクスやログの活用で一定の成果を上げたものの、分散トレーシングにおいてはプロダクションへの導入に至っておらず、一度失敗しています。
技術的な検証はできても、導入には至らない。その原因は、エンジニア自身が、技術をビジネス価値に変換できていないことにありました。私たちは、この壁を突破するために働きかけを行っています。
新しいツールや技術の本番適用、既存システムの改善に苦戦している方は少なくないはずです。本発表では、私たちの現在進行形の挑戦を共有し、同様の課題に取り組む方々のヒントとなることを目指します。

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

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

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

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

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

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の協働というのは最近ではちょこちょこ目にしますが、まだまだ事例としては少ない方だと思うので、是非弊社における事例を聞いていただくことで、お聞きいただいた方々の助けになるのではないかと思った次第です。