【「SRE NEXT 2026」レポート】信頼性をビジネス価値へ変える「3つの実践」
2026年7月10日・11日、東京・有明にて「SRE NEXT 2026」が開催されました。本イベントは、信頼性に関するプラクティスや組織作りに深い関心を持つエンジニアが一堂に会する一大カンファレンスです。Qiitaは本イベントのメディアスポンサーとして協賛しました。
本記事では、全セッションの中から「信頼性の問い直し」「デザイン思考に基づくユーザー理解」「金融機関における先進的なクラウドシフト」をテーマとした注目の3セッションをピックアップし、その内容をレポートします。
イベント公式サイトはこちら：https://sre-next.dev/2026/
目次
SREにおける「より良い質問」の重ね方― 信頼性、根本原因、そしてAIとレジリエンスの未来
David氏は本イベントにて「Reliability is a Question」というテーマで、SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）の本質に迫るセッションを行いました。一見シンプルに見える問いを紐解き、問い自体を洗練させていくアプローチを通して、信頼性（Reliability）への理解を深めるための実践的な知見が語られました。そのセッションの様子をお届けします。
なお本セッションは全編英語で進められましたが、本記事では日本語に翻訳してご紹介します。
信頼性は「顧客の視点」で測定される
Photo by SRE NEXT Staff
「システムの信頼性をどのように保っているか」という問いがあります。「稼働率(Availability)」はSREが関心を寄せるもっとも普遍的な指標ですが、SREはレイテンシーやスループット、正確性、忠実度といった指標にも責任を持ちます。
例えば「100台のサーバーのうち14台が障害を起こした状況」は、「A 大したことない」「B 今すぐデスクに戻って修理に取りかかるべき」「C 超大ピンチ」のいずれでしょうか。そのようなクイズが出されました。
その答えは「It depends（状況による）」。モニタリングシステムは単に「86台稼働、14台ダウン」と伝えてきます。しかし重要なのはコンポーネントの数値ではなく「顧客がどのような影響を受けているか」であり、「信頼性はコンポーネントの視点ではなく、顧客の視点から測定されるべきものである」というSREの根幹原則が強調されました。
「根本原因（Root Cause）」の罠とシグナルとしての障害
続いて「障害やエラーをすべて排除するには？」という問いに対し、SREに必要なのは「好奇心」であるとDavid氏は言います。「障害」は単に排除される対象ではなく、「システムがプロダクション環境でどう動いているか」を知るための貴重なシグナルとして捉えるマインドセットが求められるとのことです。
また、「根本原因（Root Cause）」という言葉を使うことへの警告も発せられました。複雑なシステムにおいて何かしらの障害が発生した場合、唯一の根本原因が存在することは極めて稀です。例えばECサイトにおいて、データセンターで足の引っかかりによるケーブル抜去が起き、DB停止からフロントエンドの遅延、エラーレスポンスの乱発へと至る障害が発生したとします。複雑なシステムにおける障害は、誰か1人のミスの問題なのではなく、システム全体の問題なのです。
また「根本原因」の代わりに以下の言葉を使うことで、障害から学ぶためのより良いフレームワークを確立できます。
- トリガー（引き金）： 何が問題を起動させたか
- 寄与要因（Contributing Factors）： どのような要因が複合的に重なり合ったか
組織におけるSREの役割と売り込み方
SREの「成熟度モデル」を追い求める姿勢に対しても疑問が呈されました。SREは「障害対応（消火活動）」から始まることが多く、迅速に復旧させることをめざします。そして障害対応が終わると、もう二度と同じことを繰り返さないように事故を防ごうと制限ばかりかける「門番（ゲートキーパー）」になろうとするかもしれませんが、この役割にとどまりつづけるのは良くありません。めざすべきは信頼性を社内に広める「提唱者（アドボケイト）」、そして開発チームと一緒にロードマップを描く「パートナー」です。
ただし、この成長は一方通行ではありません。新システムの導入などで、いつでも障害対応に戻る可能性があります。大切なのは、戻るたびに成長していることと、プラットフォーム構築などで再発を防ぐ仕組みを作っていくことです。
また、「予算が欲しい」「もっと人員を増やしてほしい」など様々な理由によって社内でSREを推進する際、以下のアンチパターンに陥らないよう注意が呼びかけられました。
- 「保険屋」になるな： 「SREにお金を払えば、高いダウンタイムを防げますよ」という脅しのような売り込み。「良いシステムですね、事故が起きたら大変ですね」と言ってお金を巻き上げようとしてはいけません。
- 「おとぎ話」を売るな： 経営陣は「ジュークボックスにコインを入れれば信頼性が買える」という物語が大好きです。しかし、そんな簡単なものではありません。
- 「税金」にするな： 「セキュリティや信頼性は、開発の上に上乗せする税金のようなものです」として後から付け加えようとしても機能しません。信頼性は、機能（Feature）そのものです。
- 「痛みが伴わない」と偽るな： 「SREを導入しても何も変わりません、裏で静かにやっておきます」は嘘です。ジムに行くのと同じで、やり方を変えるには痛みと変化が伴います。
- 「専門用語（例：SLI/SLO）」で話すな： ビジネス層はレジ（売上）が回っているかを気にしています。
AI活用（トイルの自動化）への問いと、レジリエンスの未来
Photo by SRE NEXT Staff
セッション後半では、AI活用とレジリエンス（Resilience）の概念について整理がなされました。
AIを導入する際は、「『AI』とは具体的に何を指しているのか」「誰が使っているのか」「AIによる成功と失敗をどう見分けるのか」「AIと人はそれぞれどのような強みを持つのか」「学習データはどれくらい正しいか」「SREとして、私たちは自動化について何を学んできたのか」を注視する必要があります。
最後に、日本語でもしばしば混同されがちな、「リライアビリティ」と「レジリエンス」の違いが説明されました。David氏の経験では、人々が「レジリエント（resilient）」と言うときは、「障害に対する耐性（Fault-tolerant）」「冗長性（Redundant）」「未然に防ぐよう計画された（Preventatively designed）」「高可用性（Highly available）」「自己修復（Self-healing）」などを意味しているとのことです。
しかし「冗長性（Redundant）」と「レジリエンス」には違いがあると、以下の例えを用いて説明がなされました。
- 冗長性（Redundancy）： スペアタイヤを積んでいる状態（予備がある）
- レジリエンス（Resilience）： 車が動かなくなった際に、タクシーを手配するなどして目的を遂行する適応能力（Adaptive Capacity）
つまり、予期せぬ事態（サプライズ）が起きた際に柔軟に適応できる組織やシステムの能力こそがレジリエンスであり、適応能力を理解することが未来の信頼性を保つための鍵の1つであると締めくくられました。
「誰のためのリライアビリティ？」― デザインの視点から紐解くSREとユーザー理解
アンカーデザイン株式会社代表の木浦氏によるセッション「誰のためのリライアビリティ？」では、エンジニアリングとデザインの領域を横断してきた独自のキャリアを背景に、SREにおける「本当のユーザー理解」についてお話しいただきました。
「デザイン」の領域は、インターフェースから組織・社会へと拡大
Photo by SRE NEXT Staff
キヤノンでの新規事業開発や、デンマーク発のデザインスクールCIID（Copenhagen Institute of Interaction Design）への留学を経て現職に至る木浦氏。元々はソフトウェアエンジニアをめざしていましたが、様々なキャリアや経験を経て、現在はデザインリサーチを専門にしています。
一般の人が「デザイン」と聞いて思い浮かべるものとして、「企業やブランドのロゴ」「ポスター・広告」「Webサイト」「スマホアプリの画面」「家具」「家電」「建築・インテリア」が例に挙がりましたが、実際にはもっと広い領域をデザインでは扱っているとのことです。
また「デザインの対象」は歴史とともに変遷していることも説明されました。19世紀はサインや印刷、20世紀にはインダストリアル、1980年代はインターフェース。さらに2000年代以降の「体験の設計」、そして現代の「ビジネス・組織・システム全体の設計」へと、有形・無形を問わず、領域を拡張しつづけています。
また「デザインリサーチ」についても説明されました。デザインの世界では、デザインリサーチとはプロダクトをデザインするためのリサーチであり、「新しい何かを作るため」や「現状をよくするために人々を理解して、本質的なニーズを探し出すこと」であるという共通認識が持たれているとのことです。
具体的な例として、世界的に有名な椅子「Wassily Chair」と「Egg Chair」を用いて説明がされました。単に「良い椅子はどちらか」というだけの質問に対しては「どちらも良い」となってしまいますが、シチュエーションやニーズなどを設定してきちんと問いを立てれば、どちらが良いかを判断できます。「軽い」「より多くの人に届けたい」「公共スペースでもプライベート空間を提供したい」などの背景や文脈が正しく定義されて初めて、良いデザインかどうかが決まるということです。
SREにおける「ユーザー」像への違和感と、デザイン的アプローチ
デザインの世界では、「誰のためのデザインか」という問いがあります。「ユーザーとは、そもそも誰か」を考えるときには、ユーザーを単なる「属性（年齢や職種）」だけでなく、「文脈（利用時の状況）」や「目的（何を達成したいか）」の3つの組み合わせで捉えるとのことです。
さらに、ペルソナを用いてチーム全体でユーザー像を共有し、ジャーニーマップをシステム内部の挙動だけでなく「サービス利用の前後の行動」まで広げて設計します。すると信頼性を確保するときにどこが重要かを把握でき、局所最適になっていないかを検討できるということです。
何より重要なのは、「ユーザーを妄想で決めつけず、インタビューや行動観察で必ず検証すること」。具体的には、ペルソナやジャーニーを用いて仮説を作り、インタビューやログなどで確かめ、再度ペルソナやジャーニーで分析して更新することが必要です。
ここでデザインの世界からSREを見て感じた違和感についての話にうつりました。「『SLO（サービスレベル目標）の数字は、何を守るためにあるのか』を考えたことがあるか」「例えばAPIのレスポンスのミリ秒など出てくるが、ユーザーの価値との結びつきをどれくらい意識しているか」という問いが投げかけられました。それに対して医療画像分析の例を用いて、「妥当な根拠なしに数値を追い求めるのではなく、ユーザーがどのような文脈で何を求めているか、に立ち返ること」の重要性が強調されました。
SREとデザイナーが手を組み、最適な「価値と信頼性」を模索
デザイナーもSREも、ユーザーに良い体験や価値を届けたいと思っていることは同じです。最後に、SREとデザイナーがコラボレーションする具体的なアプローチが提案されました。
- 「ユーザー」ではなく、活動として捉えて議論する
- 抽象的な言葉を避け、「どんな状況の誰が、何のために使うのか」を明確にする
- SREも直接ユーザーに触れる
- SREが持つシステム観測データ（ログ、メトリクス、障害履歴）と、デザイン側が持つ定性データ（インタビュー、問い合わせ内容）を持ち寄り、双方の視点でユーザーの動向を読み解く
- 理想と運用負荷の最適なバランスを探る
- デザイナーが描く「理想の体験」と、システムを維持管理するSREの「運用の現実」を突き合わせ、持続可能なベストバランスを共に模索する
社内のデザイナーやUXリサーチャーに「一緒にユーザー理解をやってみませんか」と声をかけることが、より本質的なシステム信頼性の構築に向けた第一歩となりそうです。
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
本セッションでは、ソニー銀行の福嶋達也氏が登壇し、10年以上の歳月をかけて推進してきた「フルクラウド化」の道のりについて語られました。金融業界における先進的なクラウドシフト戦略と、その基盤を活かした最新の取り組みについてレポートします。
背景と目的：守りのITから「攻めのIT」への転換
Photo by SRE NEXT Staff
多くの伝統的な銀行では、メインフレームや旧世代のプログラミング言語で構築されたレガシーな勘定系システムが今も稼働しています。IT予算や人的資源の大半がシステムを維持・運用するための「守りのIT」に消えてしまい、新サービスの迅速な投入を阻む要因となってしまっていることが多いのが現状です。
ソニー銀行はこの構造的課題を打破すべく、「ビジネスアジリティ（俊敏性）の向上」を目標に掲げました。変化が激しく予測困難な時代のなかで、市場の新たなチャンスへスピーディに対応し、社外サービスとも柔軟に連携するためには、IT基盤そのものの刷新が不可欠とのこと。クラウド化は単なる技術導入ではなく、守りのコストを抑えて「攻めのIT」へとリソースを再配分するための重要な手段として位置づけられたのです。
計画的なロードマップと慎重なリスクアセスメント
Photo by SRE NEXT Staff
ソニー銀行のクラウドシフトは、オンプレミスシステムの更新時期や業務パッケージの入れ替えといったタイミングを見極めながら、約10年の歳月をかけて段階的に進められました。
- 周辺系からの着手（2013年〜）： まずはリスクを抑えやすい周辺系システムからAWSの活用を開始
- 中核機能の切り出し（2017年〜）：財務会計システム（総勘定元帳）でAWS採用を決定し、2019年に移行完了
- 本丸の刷新（2025年5月）： 本丸である「勘定系システム」をAWS上で本番稼働させ、全方位でのフルクラウド化が完了
移行にあたっては、積極的な情報開示や専門家の支援などによって、金融機関としての安全性を担保するため万全を期しています。FISC（金融情報システムセンター）のガイドラインなどを踏まえた独自のアセスメントを実施し、現在も社会情勢やセキュリティ動向に合わせた毎年の点検を継続しているとのことです。
さらに2013年当時、国内に「第2リージョン」が存在しなかったことがクラウド移行の大きな障壁であったため、同行はAWSの米国本社や国内幹部へ直接アプローチを行い、国内複数リージョンの必要性を強力に訴えつづけたそうです。これが後の「AWS大阪リージョン」の開設へと大きく寄与することとなりました。
クラウドネイティブな新勘定系のアーキテクチャ
刷新された新勘定系システムは、従来の「モノリス（一枚岩）」な構造から脱却し、最新のクラウドネイティブ技術を取り入れた設計へと生まれ変わりました。
金融基盤のモダン化において、同社は240を超えるAWSサービスを活用した先進的なシステムを構築しています。仮想サーバー（EC2）は極力使用せず、コンテナ基盤にはAWS Fargate（Amazon ECS）を採用。BFF（Backend For Frontend）をはじめ、振込や預金などの主要な業務機能もこの環境上で稼働させているとのことです。また、Webコンテンツや画像はS3で管理し、開発・デプロイはAWS Codeシリーズで自動化するなど、AWSのサービスが最大限に活用されています。
銀行業務において極めて重要となる業務継続性を確保するため、通常運用を行う東京リージョンのほか、大阪リージョンへもデータベースを常時同期させています。想定はしがたいものの、万一の場合にはそのままシステムを再開できる堅牢さを誇ります。
アーキテクチャの検討段階では「一般的なマイクロサービス構成」も議論されましたが、データ整合性を保つための仕組みが複雑化するという課題があったとのことです。そこで「なぜマイクロサービス化するのか」に立ち返り、「教科書通りの構成をとることではなく、開発生産性の向上」を本来の目的と再定義。結果として、業務整合性やトランザクション保証を考慮したやや大きめの粒度を選択し、高い開発生産性を実現しました。
移行にあたっては、大型連休を利用して本番停止を伴う切り替えリハーサルを4回繰り返し、経営層による判定ポイントを10段階設けるなど、極めて慎重かつ安全なプロセスで切り替えを遂行したとのことです。
今後の展望：基盤完成の先にある「AI活用」への挑戦
保守的になりがちな勘定系システムを国内トップクラスの先進的な基盤へと進化させたソニー銀行は、すでにその先にある「AIを活用した開発・運用」のステージへと足を踏み出しています。
最先端の環境が整ったことで、現在はClaude CodeやAWS Kiroなどの生成AIツールを取り入れ、設計やテスト工程の大幅な効率化を実践しています。今後は運用領域におけるDevOps Agentの導入による障害対応の迅速化や、セキュリティ領域でのAIエージェント活用など、実務への適用範囲をさらに拡大させていく方針とのことです。
編集後記
「SRE」というテーマで繰り広げられた今回のセッション。専門的なテクノロジーの話題でありながら、語られていたのは「エラーの裏にある背景に好奇心を持つこと」や「使う人がどんな状況で困っているかを想像すること」、そして「目的のためにあえて教科書通りのやり方にこだわらない柔軟さ」といった、とても人間味のあるアプローチでした。
単に障害を防ぐためだけでなく、開発チームが安心して新しい挑戦をし、ユーザーに良い体験を届けるために、現場でいかに「問い」を重ねながら仕組みを整えているのか。テクノロジーの先にある「使う人」や「ビジネス」へ目を向ける登壇者の皆さまの姿勢は、職種を問わず多くの働く人にとって学びがあると感じます。本レポートを通して、その熱量と視点の面白さを少しでも感じていただければ幸いです。
文：Qiita Zine編集部
提供：SRE Lounge