「バズワード」の印象が変わった1日。SREリーダーがクラウドネイティブ会議 Day2で決意したアラート改善と障害訓練

こんにちは、株式会社メンバーズのDevOps Leadカンパニー 加藤です。

2026年5月15日に開催されたクラウドネイティブ会議 Day2に参加してきました。Platform EngineeringとSREを中心に6セッション聴講したので、参加レポートとしてまとめます。「次回参加しようかな」と思っている方の参考になれば嬉しいです。

簡単に自己紹介をしておくと、私はSREチームのリーダーを初めてまだ3年の未熟者です。世の中で提唱されているSREのベストプラクティスを自社の実情とすり合わせながら、悪戦苦闘し、実践しています。最近ようやくSREっぽいことができてきた実感が湧いてきました。
業務ではAWSとKubernetesを触っています。一方でPlatform Engineeringについては、正直なところ「なんとなく概念は知っている」「ちょっとしたバズワードだなぁ」くらいの浅い理解で参加しました。
本レポートは、Platform Engineeringの専門家ではなく、SRE側から越境して聞きに行った人間の視点だと思って読んでもらえればと思います。

6つのセッションは扱うテーマこそバラバラでしたが、聴き終えてみると、その根底に流れている価値観にはっきりとした共通点を感じました。この記事では、各セッションの内容を簡単に振り返りつつ、その共通点が何だったのかを言葉にしてみます。

クラウドネイティブ会議 のスポンサー企業の皆様。いずれは自社のロゴも載せられたらいいなと。

ホワイトボードにメンバーが書いてくれました（Typo）

なぜ参加したか

DevOps LeadカンパニーのLab活動※の一環というよりは普段、直接顔を合わせる機会が少ないメンバー同士のオフ会も兼ねて参加してきました。

あとから聞いてみると、他のグループでも同じような話が出ていたようで、最終的に自社からは合計8名が現地参加していました。Platform EngineeringやSREまわりの課題意識が、社内のあちこちで同時多発的に芽生えていたことが分かったのも、今回の収穫の一つです。
※Lab活動とは、DevOps Leadカンパニーが「両利きの経営」を実践するために設けている、週の就業時間の約12%を研究開発・組織づくりに充てる社内R&D制度（DevOpsLab）です。次世代インフラ・AIOps・生成AI活用・セキュリティ・人材育成など複数のLabが並走しており、エンジニア自身がテーマを選んで探求・実装します。日々の案件で得た知見を未来の技術・サービス・組織文化へ還元し、エンジニアが「使う側」から「創る側」へ回ることを目指す取り組みです。

自分自身としても、ちょうど業務で似たような課題感を抱えていて、他社がこのあたりをどう捌いているのか知りたかった、という動機がありました。結果的に、悩みのいくつかについては解消のためのアクションを計画することができました。

セッションダイジェスト

個人的に響いたセッションをいくつか紹介します。各セッションの詳細やアーカイブはクラウドネイティブ会議のタイムテーブルから辿れます。

AI 時代の Platform Engineering: 攻めと守りの開発手法を両立するガードレール設計のプラクティス

Platform Engineeringの目的は昔も今も「利用者の生産性を上げる」ことです。従来はGolden Path、つまり頻出する作業経路を舗装することで生産性向上を実現してきた、という導入から講演は始まりました。ではAI時代に何が変わったのか。変更プロセスが圧縮されたことで暗黙知が失われ、人間の認知範囲を超える領域が拡大したのが論点で、その答えとして提示されたのがGuardrailsという考え方でした。

特に印象的だったのは、影響範囲に応じて「構造」と「プロセス」を非対称に設計するという原則です。広域に影響が及ぶ基盤層と、AIによる高頻度・大量の変更が起きるアプリ層とでCIテストの粒度にグラデーションを持たせ、人間の認知の限界を認めつつも、マージや本番反映には必ず人間のゲートを残す。AIに何でも任せるのではなく、任せていい境界を明確に言語化していた点に感銘を受けました。

また、Shift LeftとShift Rightを二刀流で組み合わせるアプローチも興味深く、事前に機械的に検知できる欠陥は左側で潰し、難しいものは本番トラフィックで検証する考え方でした。これはカナリアリリースやA/Bテストといった安全なリリース手法が確立されているからこそ成立する芸当で、見習うべき点だと感じました。

〜備えあれば憂いなし〜とりあえず障害訓練やろ？デジタル/フィジカル横断プロダクトを24365で維持するための戦略

「障害訓練をやったことない人向け」と冒頭で対象を絞ったセッション。まさに自分向けでした。

なぜ訓練が必要なのか。冗長化やバックアップをやっていても、本番環境は常に変化していて、設計時の前提と実行時の現実は必ずズレる。訓練しないとそのズレに気づかない。
語られた障害の実例が強烈で、技術的な切り分けの末に真因が「ビルのオーナー変更による回線契約の更新漏れ」でした。技術障害の真因が契約という、ログをいくら見ても出てこないケースです。

訓練の効能は6つに整理されていましたが、自分が一番持ち帰りたいと思ったのは「多すぎるアラートは障害を霧の中に隠す」「改善とは追加だけでなく、消す・変えるも含む」という指摘。反省しました。
訓練の日を決めて時間を決めないやり方は自分もやりたいってなりました。会議の調整とかどうしよう、みたいな悩みもありアクションはできてないです。

Terraformモジュールはなぜ「魔境」化するのか

移動の都合で部分聴講でしたが、核は掴めました。Platform Engineeringは複雑さのブラックボックス化が本質、でも意思決定が必要な値は抽象化してはいけない、という話です。
「どう実現するか」は隠していい。でも「何を実現したいか」「要求は何か」は利用者が決めるべきで、Platform 側が勝手に決めてはいけない。抽象化の境界は「専門性vs業務固有性」で引く。

一人SREが歩んだ Platform Engineering スモールスタート実践録

大企業の話になりがちなPlatform Engineeringを、少人数・一人体制でどうやるか、という切り口。

刺さったところが2箇所あって、ひとつはPlatform EngineeringとSREはどちらも「トイル削減」は似た性質を持つという整理、その観点が前者は開発者の認知負荷を上げるトイル、後者は信頼性のトイルというところ。もうひとつは、Platform EngineeringとSREはどちらも推進に必要だったのは技術力ではなく「対話」と協力体制だった、という振り返りでした。

通知再考 ~ 最高のアラート通知を今改めて考える ~

「夜中にアラートで起こされたけど起きる必要はなかった」「大量の通知で疲弊した」という、SRE全員が頷くケースから始まるセッション。冒頭のつかみがうまくて一気に引き込まれました。

通知を3タイプに整理してくれます。Event-based（コードの異常）、Metric-based（リソースの異常）、Symptom-based（ユーザーの困りごと）。視点がコード→システム→ユーザーと外に広がっていく。検知メソッドの系譜（OK/WARNからSLOバーンレート、Beyond SLOまで）も同じ方向に進化してきた、という歴史の整理も良かったです。
2023年にSLO導入を検討して中止した判断を「妥当だった」と振り替えっていたのが印象的でした。SLOは現代SREの花形ですが、組織の流動性や運用コストに合わなければ形骸化する。ベストプラクティスからではなく本当に困っていたことから逆算していた話。
通知改善に特効薬はない、耳が痛かったです。

で、自分はどう動くか

まず、通知・アラートを作り直したい。既存通知を3タイプ（Event/Metric/Symptom）で棚卸して、Event-basedに偏っていないか整理してみます。今は「未知のエラーログ＝とりあえず緊急対応」にしているのですが、未知だから重要とは限らない。重要機能を定義して、そこのエラーだけ緊急扱いにする方向で再設計したいです。「育てる運用（定期的にノイズを発見）」と「ポストモーテム改善（検知漏れを発見）」の両輪も回したいです。

AIを通知の一次調査に組み込むこと。アラートを人間に届ける前に、AIが関連ログ・メトリクス・デプロイ履歴を集約して影響範囲を評価する。フィックスターズのマルチエージェント構成を通知に応用するイメージです。ただし判断材料の整理までがAIの仕事で、最終判断する人間がみやすいレポートを届けさせます。

障害訓練、やります。

参加して感じたこと（余談）

本題から少し外れますが、カンファレンスに現地で・丸一日参加したこと自体についても書き残しておきます。
精神論的な話になりますが、やっぱり色んな人と会えるのが良いです。普段フルリモートで働いているので、同僚と顔を合わせられたこと自体が良かったし、それ以上に登壇者の方たちの熱量がヒリヒリ伝わってきたのが効きました。こういうのはモチベーションが上がります。会場には「こういうことで困ってます」と課題感を持って参加している人も大勢いたはずです。直接話したわけではないけれど、同じところで悩んでいる人がこれだけいるんだ、と思えてちょっと救われた気持ちになりました。

丸一日、特定ジャンルに浸れたのも良かった点です。普段のインプットは、RSSで流れてくる記事のうち、目についたものを読んだり、Twitterのおすすめに流れてくるものをなんとなく見たり、散発的なものが主でした。今回のように特定ジャンルに絞って丸一日インプットすると、セッション同士のつながりが見えて、これをどう紐づけて自分の業務に活かすかどうかまで考えられる。散発的に記事を読むのとは比べものにならないくらい有意義でした。一方で、正直に言うとAI関連のセッションが多く、Kubernetesそのものの話をもっと聞きたかった気持ちもゼロではないです。KubeConにも行ってみたくなりました。

書いたそばから矛盾するようですが、AI関連のセッションからの学びもちゃんとありました。自分はAIを使う側であると同時に、周囲の開発者のAI活用を推進・サポートしていく立場でもあります。正直なところ「AIなんて、みんな勝手に使いたいように使うでしょ」と思っている節があります（実際には全員がそうではないのですが）。ただ今回、AIのスピードに開発を追いつかせるためにガードレールを敷く、という仕事のイメージがかなり具体的になりました。Guardrails設計の話などはまさにそれで、こういう「速さを引き出すために枠を作る」仕事は自分の性に合っているとも感じます。AI推進という役回りに対して前向きな手触りを持って帰れたのは、地味ですが収穫でした。

まとめ

クラウドネイティブ会議 Day2、Kubernetesやオブザーバビリティの話をしているはずなのに、聴き終えてみると6つのセッションの根っこには同じ価値観が流れていました。手段と目的を取り違えない、利用者を起点に置く、銀の弾丸を期待せず改善し続ける。

今回は、特定の技術のスキルアップというより、自分の仕事の向き合い方そのもの、マインドセットを更新する価値の方が大きかったな、と感じています。腹落ちしたのは、Platform EngineeringやAIという新しい概念を追いかけた先で、結局「利用者起点」「手段を目的化しない」といった昔ながらの価値観に戻ってきたこと。手法は次々と新しくなるけれど、その下で大事にすべきものは変わらない。むしろ、新しい文脈でこそその価値観が試されるんだろうな、と思います。

Platform Engineeringを「バズワードかな」と思って聞きに行った人間としても、その印象は良い方向に裏切られました。言葉は新しくても、中身はちゃんと地に足のついた話だった。ここで受け取った軸を、明日からの仕事の判断基準にしていきます。良い一日でした。