SRE NEXT 2025では初の試みとしてアンカンファレンスが開催されました。

わたしはオブザーバビリティについて話すグループに参加し、そのうちのサブグループのひとつで色々と議論させてもらいました。このエントリーはそのwrite upです。

登場した話題1：オブザーバビリティの獲得から普及・浸透へ

わたしたちは「オブザーバビリティの獲得」というテーマでディスカッションしました。

オブザーバビリティには様々な定義がありますが、よく引用されるのは「システム内部の状態を、外部からどれだけ理解できるか」という能力、あるいは「本番環境をデバッグできる能力の程度」といったものです。これは単にツールがあるかないかだけでなく、実践的な・あるいは組織的な能力という側面があります。

というわけで、まずはこのトピックを話しました。

「この『本番環境をデバッグできる能力』、皆さんの現場では実際に獲得・発揮されていますか？」

感度の高いキーパーソンが牽引するケース

「開発チームの中にオブザーバビリティに対する感度の高い人がいて、その人が中心となってツール活用や文化醸成をリードしている」というケースです。

その人が「なぜ、いつから感度が高いのか」という理由はよくわかっていないとのこと。ぜひ知りたいところです。

こうしたキーパーソンがいるチームでは、能力獲得や定着がスムーズに進む傾向があるようです。

またその他に、仕込みとして・具体的な事例が共有されました。

ツールベンダーが提供するトレーニングや、社内でのオンボーディングセッションを積極的に活用し、チーム全体の知識レベルを底上げする
ツールのクエリー言語を直接書かなくても済むように、ドロップダウンリストで条件を選択するだけで必要な情報にたどり着ける、作り込まれたダッシュボードを用意する

ダッシュボードの作り込み

特にダッシュボードの作り込みに関する話は印象的でした。ある参加者からは、「デザイナーと協力して、単に情報が並んでいるだけでなく、『心に響く』デザインや情報設計を行ったところ、効果があった」という経験が共有されました。

色使いのような見た目のデザインもさることながら、ユーザーが本当に知りたい情報は何か、それをどういう順番、どういう粒度で見せれば直感的に理解できるか、心に響くか（アラートならば心に刺さるか）という「情報デザイン」の観点が極めて重要になります。

わたしたちはつい情報を盛り込みすぎてしまいがちですが、それだと結局「無」になったりするわけです。それぞれに専門性がありますね。

ダッシュボードの思わぬ波及効果

オブザーバビリティの取り組みが、当初の想定を超えて組織全体に良い影響を与えたという報告もありました。

ある参加者のチームはTail-based Samplingを活用してユーザーが遭遇したエラーを重点的に追跡できるような仕組みを構築していました。これは開発者がエラーを発見・分析するのによく利用します。

しかしいつの間にかこの仕組みを、カスタマーサクセス部門のメンバーが日常的に活用するようになっていたというのです。顧客から問い合わせがあった際に、そのユーザーがどの画面で、どんな操作をして、どんなエラーに遭遇したのかを即座に特定し、より迅速で的確なサポートを提供するのに役立てていたそうです。

提供するダッシュボードやデータは、特定の目的のためだけのものではなく、組織全体の資産になりうるのですね。

活用状況が見えないという課題

多くの参加者が共通して抱えていたのが「ダッシュボードのアクセス解析」に関する課題です。

自分たちが作ったダッシュボードが活用されているのかを計測する手段がなくて困っているということです。

「このダッシュボード、すごく使ってもらえて嬉しい！」とか、「あのダッシュボードが、まさかあの部署で活用されていたなんて！」といった発見が、人づての噂話ではなく、客観的なデータとして可視化できない
ものすごく活用されているように見えるが、実はそのダッシュボードのクエリーが複雑怪奇で、もはや誰もメンテナンスできない困った状態になっているものがある。本当は消したいのに、どうにも影響が大きそうで消せない…

など悩ましい問題が挙げられました。これは多くのオブザーバビリティツールが、ダッシュボードの「閲覧ログ」を詳細に分析する機能を提供していないことに起因します。

自分たちの仕事の成果を計測できないというのは、改善のサイクルを回す上で大きな障壁となります。

牽引者がおらず、普及が進まないケース

感度の高いキーパーソンがいるチームの話とは対照的に、「牽引役がおらず、なかなかオブザーバビリティの文化が根付かない」という悩みも深刻です。

開発者向けのオンボーディングは実施しており、知識としては皆持っているはず
マネージャー層からも「障害発生時やアラート発報時には、ダッシュボードを見て主体的に対応するように」という通達は出ているはず

それにもかかわらず、実際に行動に移すメンバーはごく一部に限られてしまう。なぜなのか…。

ディスカッションの中では「又聞きで状況を判断して、あの人はやる気がない、などと邪推するのは良くないですよね」意見も出ました。もしかしたら、その人なりに別の方法で問題解決を図っているのかもしれないし、あるいは日々の開発業務に追われて、そこまで手が回らないのかもしれません。指示と受け取りは文化に大きく影響を受けますから。

「できれば極力対応してね」が最大値を示すのか最小値を示すのかなどなど。難しいですね。

これは個人の意識の問題という側面と、組織の仕組みの問題という側面がありそうです。オブザーバビリティのツールを使いこなし、システムの安定性に貢献した人が、その人の評価や報酬に適切にフィードバックされるような仕組みがあると、文化・習慣としても定着できる確率が高くなりそうです。

「自負」や「おせっかい」が自立を阻害する可能性

「SREやインフラチームが親切にフォローしすぎることが、かえって開発者の自立を妨げているのではないか？」という話題も出ました。

わたしたちは良かれと思って、あるいは開発者が困らないように、あるいはユーザーに迷惑がかからないように、と先回りして準備や切り分けをしたり、詳細な分析レポートを用意してあげたりします。しかしその親切が「自分がやらなくても、あのひとたちがやってくれる」という依存関係を生み出し、結果として開発者自身がシステムの状態を自分ごととして捉える機会を奪ってしまっているのではないかということです。

ある参加者からは「最初はチームみんなでアラートに対応していたのに、自分が頑張って対応し続けていたら、いつの間にか自分しか対応しない状況になっていた」という経験談も語られました。

これはシステムのオーナーシップや責務の所在が曖昧なときに起きがちですが、しかしハッキリしていたとしても実態が誰か頼みなのであれば、現場ではこのように自立する理由も機会もなくなります。オブザーバビリティの文化を浸透・定着させるためには、時には「やり過ぎない」ことも重要なのかもしれません。定着・自走を目指すなら、SREはあくまで開発チームの支援者であるべき、と再認識させられました。SREにヒロイズムはアンマッチですね。

「自分ごと化」のメカニズム

ではどうすれば開発者それぞれが、オブザーバビリティを「自分ごと」として捉えてくれるようになるのでしょうか。

ひとつの仮説は「その人が、オブザーバビリティがないことで本当に困らない限り、自分ごとにはならないのではないか」というものです。

必要性を強く感じるのはどんな時か？ → やはり、システムが「炎上」した時、つまり大規模な障害が発生した時ですよね
では、炎上した時にオブザーバビリティがなくて困るか？ → もし困らないのであれば、その人やそのチームにとっては、現状のオブザーバビリティで十分、ということになります
つまり「燃えても困らない」のであれば、それ以上のオブザーバビリティは「過剰品質」であり、実は不要なのかもしれない（それで責任を負うべきひとが困らないなどミスマッチがあれば、それは組織の構造や力学の問題）

これはある意味で非常にドライで、しかし的を射た結論だと思います。わたしたちは、なまじリテラシーがあるがゆえに「このままいくと将来燃えるかもしれない」というリスクを先回りして、対策してしまいがちです。

しかしチームの能力獲得を含めた持続性の観点では、火種を自分たちで発見し自分たちの手で消火できる能力を、チーム全体で体験的に身につけることなのかもしれません。そのためには、SREが火消し役を担うのではなく、あえて開発者にその役割を委ねる、というアプローチも時と場合によっては有効かもしれませんね。

登場した話題2：データ読解力の獲得とLLM活用の可能性

次のトピックは以下でした。

「実際のところ、データを読むのって難しくないですか？皆さんはどうやってトレーニングしていますか？そして、そのあたりを生成AI、特にLLMで何とかすることはできないでしょうか？何か取り組みをされていませんか？」

オブザーバビリティにはデータ読解力が欠かせません。経験的には、データ読解力の獲得は一朝一夕にはいきません。グラフやログの中からインサイトを見つけ出すのは、熟練のエンジニアにとっても骨の折れる作業です。

夢のLLM：傾向分析と原因究明

まず挙がったのは「夢のLLM」の話です。

「これまで蓄積してきた膨大なメトリクスやログ、トレースのデータをLLMにすべて読み込ませて、普段とは違う振る舞いの傾向を自動で分析し、障害の予兆や、発生した障害の根本原因特定までできたらいいのに」

これはオブザーバビリティに関わる誰もが一度は夢見る世界ですよね。しかし、現状の技術では、まだこの夢の実現にはいくつかのハードルがあるようです。

コンテキスト長の制約: 現在のLLMが一度に処理できる情報量（コンテキスト長）には限りがあり、数週間、数ヶ月にわたる膨大な時系列データをすべて一度に読み込ませて分析するのは困難です
ハルシネーションのリスク: 特に、過去に事例の少ない未知の障害パターンに対して、LLMがもっともらしい嘘（ハルシネーション）をついてしまう懸念があります。原因究明のようなクリティカルな場面で、実際の事象ではなくよくあるパターンを提示されても当てずっぽうと変わりません

こうした課題を解決するためにMCP活用への期待が語られました。

LLMによるクエリー生成への期待

夢物語の一方で、より現実的ですぐにでも実用化が期待される活用法が「LLMによるクエリー生成」です。

DatadogのLogs Query、New RelicのNRQL、PrometheusのPromQLなど、オブザーバビリティツールにはそれぞれ独自の強力なクエリー言語が備わっています。しかし、これらは概して難解で、使いこなすには相応の学習コストがかかります。

もし「こういう情報が見たい」と自然言語で指示するだけでLLMが適切なクエリーを自動で生成してくれるようになれば、データ活用のハードルは劇的に下がるはずです。

自然言語での指示から適切なクエリーが生成されるようになると、より多くの開発者が専門家の助けを借りずに、自らデータにアクセスして問題を調査できるようになります。これはオブザーバビリティの「民主化」を大きく前進させる可能性を秘めていると言えるでしょう。

LLMによるダッシュボード自動生成

クエリー生成からさらに一歩進んだ活用法として「LLMによるダッシュボードの自動生成」も話題に登りました。

これは単一のクエリーを生成するだけでなく、「決済サービスの健全性をモニタリングするためのダッシュボードを作って」といった「抽象的な意図」を伝えるだけで、関連する複数のメトリクス（リクエスト数、エラーレート、レイテンシー、カート投入数など）を組み合わせた、適切なダッシュボードをLLMが提案・生成してくれるというものです。

このダッシュボード生成は、すでにGrafanaのMCPで動作するらしいです。

もしこれが発達・普及すれば、前述した「情報デザイン」の課題を解決する一助になるかもしれません。人間がゼロから考えるよりも、ベストプラクティスを学習したLLMが叩き台を生成してくれた方が、より効果的で分かりやすいダッシュボードを、短時間で作成できる可能性がありますね。

もちろん誤ったデータで意思決定するのはリスクですから、最終的な確認や調整は人間の手で行わなければなりません。しかしデータ活用の最初のステップを大きく簡略化してくれるという意味で、非常に期待の持てる分野です。

まとめ

SRE NEXT 2025のアンカンファレンス、オブザーバビリティセッションでの議論を振り返ってみました。

改めて感じたのは、オブザーバビリティの獲得と普及は、単なるツール導入の問題では決してない、ということです。それは、感度の高いキーパーソンという「属人性」から始まり、情報デザイン、組織をまたいだ価値の波及、成果の計測、評価制度、そして「おせっかい」や「過剰品質」といった組織文化や個人のマインドセットに至るまで、非常に多岐にわたる、複雑で人間的な課題を含むのだと再認識しました。

そしてLLMがこの領域に大きな変革をもたらそうとしています。クエリー生成やダッシュボード生成といった実用的な応用は、データ活用のハードルを下げ、オブザーバビリティの民主化を加速させるでしょう。

しかしこれらを支えるのは、データを活用する意思と習慣、適切なデータの収集や扱い方など、エンジニアリングの基礎能力だと考えます。

この write up が、読者の皆さんの現場で、新たな対話や試みを生み出すきっかけになると幸いです。

最後に、このような素晴らしい議論の場を設けていただいたSRE NEXT運営の皆さま、そして、活発な議論に参加してくださった皆さまに、改めて感謝申し上げます。ありがとうございました。

宣伝：『バックエンドエンジニアのためのインフラ・クラウド大全』発売中

単にインフラ・クラウドの知識を獲得できるだけでなく、バックエンドエンジニアはじめ情報システムに関わるエンジニアはなぜこのような構成にしなければならないのか、そのために何を利用するのかといった足元を固めるWhy・Whatを獲得できます。

物理本：書店やAmazonにて
PDF：翔泳社のSEShopにて
Kindle(固定レイアウト)：出るらしいけどわたしは未確認
Kindle(リフロー)：Amazonにて

Event

SRE NEXT 2025 アンカンファレンスオブザーバビリティセッション write up #srenext