トーク

■ 発表カテゴリ

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

■ 発表概要（400字程度）

私たちPanasonicのSREチームは、長年続くサービスにおいて、安定稼働と豊富な機能追加を目指して取り組んでいます。
その一環として、可観測性の向上についても挑戦を続けており、メトリクスやログの活用で一定の成果を上げることができた一方で、分散トレーシングにおいてはプロダクションへの導入まで至ることができず、一度挫折しています。
技術的な検証はできても、プロダクションへの導入には至らない。
その原因の1つは、エンジニア自身が技術をビジネス価値に変換できていないことにあると考え、新たなアプローチで、分散トレーシングの導入に再挑戦しているところです。
本発表では、分散トレーシングの導入に向けた私たちの現在進行形の挑戦を例に、技術をビジネス価値に変換する方法をご紹介します。
新しいツールや技術の新規導入に苦戦している方々は少なくないと思います。
同様の課題に悩まれている方々のヒントとなれば幸いです。

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

1: 現状の可観測性を把握する
可観測性を構成する3つの要素（ログ、メトリクス、トレース）のうち、今運用しているシステムで収集・活用している要素を把握することが重要です。
また、トレーシングがどれだけそのシステムの可観測性に貢献できるのかを見積もりも必要になります。
「そもそも可観測性とは？」といった基礎の整理から、SREとしてなぜ可観測性向上に向き合う必要があるのかまでを扱います。

2: ビジネスケースとしてあるべき形を定義する
「事業における課題は何か？」「その課題の解決に、どれだけの利益が生まれるのか？」「技術がどう課題解決につながるのか？」
基本的なこの３軸を中心に、分散トレーシング導入をビジネス価値に変換するストーリーを描きます。
そして、ビジネス的な観点からトレーシングのあるべき姿を考えてみます。

3: コストに向き合う
分散トレーシングに関わらず、新たな技術を既存システムに導入する際のコスト予測は難しいです。
私たちが一度失敗した際にどこで見積もりが崩れたのか、どの部分がコストを膨らませやすいのかを具体的に紹介します。そのうえで、導入コストを組み立てる際の観点やリスクの扱い方を共有します。

■ 対象

・対象レベル：初〜中級者向け
・プライマリターゲット：新たなツールや技術の導入に挑戦・苦戦しているエンジニアの方々

■ 得られるもの

・技術をビジネス価値に変える考え方
・SRE視点で可観測性を高める実践例
・分散トレーシング導入で躓きがちなポイントと失敗ケース

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

「技術的な必然性はあるけど、本番導入に至らない」、「この技術の導入が、どのようなビジネス価値につながるのか、うまく説明できない」という経験をされたエンジニアの方々は少なくないのではないでしょうか。
私たちも今まさに、トレーシングの導入に至る合意形成と導入で奮闘中です。
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の協働というのは最近ではちょこちょこ目にしますが、まだまだ事例としては少ない方だと思うので、是非弊社における事例を聞いていただくことで、お聞きいただいた方々の助けになるのではないかと思った次第です。