【PHPカンファレンス小田原2026】Webアプリケーションエンジニアにも知ってほしい オブザーバビリティ の本質

PHPカンファレンス小田原2026で発表した「Webアプリケーションエンジニアにも知ってほしい オブザーバビリティ の本質」のスライドです。

__

「障害が起きたらログを見る」、「メトリクスを眺めて原因を探す」
果たしてそういった活動を日頃から意識するのが オブザーバビリティ でしょうか？

オブザーバビリティはSREやインフラエンジニアだけのものではありません。
Webアプリケーションの設計・実装段階から オブザーバビリティ を意識することで、障害調査が速くなったり、チームの運用負荷が下がる、といった効果を得ることができます。
本セッションでは、アプリケーションエンジニア、特にバックエンドエンジニアに向けて
オブザーバビリティの本質を実際の現場の経験を元にご紹介します。

Transcript

1. Webアプリケーションエンジニアにも 知ってほしい オブザーバビリティの本質 2026/04/11 PHPカンファレンス小田原 2026
2. 2 自己紹介 氏名: 遠藤太徳 (Endo Futoshi) 所属: New Relic株式会社(New Relic, K.K.) 役職: Technical Account Manager Webアプリケーションエンジニアとして API開発、既存サービスのリファクタリ ング、CREとしてユーザー体験改善、チームビルディングを経験。現職では New Relic のTechnical Account Manager として活用支援や、勉強会 を行っています。 PHP歴は9年程🐘 趣味: 音楽、料理、ゲーム、個人開発、どんちゃん (豆柴)と散歩
3. 3 ref: 【PHPカンファレンス小田原 2025】New RelicのAPMを活用したECサービスにおけるメール 遅延解消の舞台裏
4. Goal 4
5. 5 (1)オブザーバビリティ がどういった概念なのか?を理解できる (2) オブザーバビリティ はSRE、インフラエンジニアだけが意識 するのではなく、エンジニア含めステークホルダー全員で意 識する事で、より開発しやすくなる事 が理解できる
6. 免責事項 6
7. 7 01 スライドの内容は主に自分のこれまでの業務経験で得た知 見を元にスライドを作成しています。特定のツールを使った 方法論よりも、抽象的な話が多いです。 02 オブザーバビリティの概念が広い為スライドでは説明がしき れてない箇所が出てきます。気になる方は懇親会等で気軽 にお話しましょう! 🏯
8. Agenda 8
9. 9 (1) オブザーバビリティ とはなにか (2) オブザーバビリティ を意識した開発について (3) 個人からチーム、組織への広がりについて (4) まとめ
10. オブザーバビリティ とは何か 10
11. 11 オブザーバビリティ Logs（ログ） Traces（トレース） エラー バジェット MTTR アラート SLI/SLO SLA APM Synthetics Real User Monitoring 分散 トレーシング ダッシュ ボード 計装 CUJ 構造化 ログ ポスト モーテム オブザーバビリティとは何か
12. 12 オブザーバビリティ Logs（ログ） Traces（トレース） エラー バジェット MTTR アラート SLI/SLO SLA APM Synthetics Real User Monitoring 分散 トレーシング ダッシュ ボード 計装 CUJ 構造化 ログ ポスト モーテム オブザーバビリティ とは どういった概念なの ? オブザーバビリティとは何か
13. 13 “Kalmanは1960年の論文で、ある特徴を オブザーバビリティと名付け、数学的制御 システムを説明しました。制御理論では、 オブザーバビリティとは 、外部出力の知 識からシステムの内部状態をどれだけう まく推測できるかの尺度 として定義されて います。” オブザーバビリティとは何か
14. 14 オブザーバビリティとは何か “ソフトウェアシステムの「オブザーバビリティ」と は、システムがどのような状態になったとして も、それがどんなに斬新で奇妙なものであっ ても、どれだけ理解し説明できるかを示す尺 度です。 また、そのような斬新で奇妙な状態に対しても、 事前にデバッグの必要性を定義したり予測した りすることなく、システムの状態データのあらゆ るディメンションやそれらの組み合わせについ てアドホックに調査し、よりデバッグが可能 で あるようにする必要があります”
15. 15 ①障害発生! 原因がわからな いのでまずはダッシュボードや ログを見る ⚠
16. 16 ①障害発生! 原因がわからな いのでまずはダッシュボードや ログを見る ②ログを見てもどれが該当 のログなのかわからない ⚠
17. 17 ①障害発生! 原因がわからな いのでまずはダッシュボードや ログを見る ②ログを見てもどれが該当 のログなのかわからない ③仕様に詳しい社歴の長い先 輩、また専任のSREチームにメ ンションして確認してもらう ⚠
18. 18 ①障害発生! 原因がわからな いのでまずはダッシュボードや ログを見る ②ログを見てもどれが該当 のログなのかわからない ⚠ これは オブザーバビリティ を実践できているでしょうか? ③仕様に詳しい社歴の長い先 輩、また専任のSREチームにメ ンションして確認してもらう
19. 19 “ソフトウェアシステムの「オブザーバビリティ」と は、システムがどのような状態になったとして も、それがどんなに斬新で奇妙なものであっ ても、どれだけ理解し説明できるかを示す尺 度です。 また、そのような斬新で奇妙な状態に対しても、 事前にデバッグの必要性を定義したり予測した りすることなく、システムの状態データのあらゆ るディメンションやそれらの組み合わせについ てアドホックに調査し、よりデバッグが可能 で あるようにする必要があります” オブザーバビリティとは何か
20. 20 ①障害発生! 原因がわからな いのでまずはダッシュボードや ログを見る ②ログを見てもどれが該当 のログなのかわからない ⚠ これは オブザーバビリティ を実践できているでしょうか? ③仕様に詳しい社歴の長い先 輩、また専任のSREチームにメ ンションして確認してもらう
21. 21 ②ログを見てもどれが該当 のログなのかわからない ⚠🖥 「ダッシュボードを見ること」 ダッシュボードは結果の表示。 重要なのはシステムの状態を 「理解・説明できる」 ことが本質。 ❌ 誤解 ③仕様に詳しい社歴の長い先 輩、また専任のSREチームにメ ンションして確認してもらう
22. 22 ⚠🖥 「ダッシュボードを見ること」 ダッシュボードは結果の表示。 重要なのはシステムの状態を 「理解・説明できる」 ことが本質。 ❌ 誤解 🔍 「ログを探せばいい」 ログは記録であって、原因に直接つながる とは限らない。事後的な調査では間に合 わないことも多い。 大事なのは障害につながる エラーを素早 く特定する為の情報が過不足なく記載 さ れている事 ❌ 誤解 ③仕様に詳しい社歴の長い先 輩、また専任のSREチームにメ ンションして確認してもらう
23. 23 ⚠🖥 「ダッシュボードを見ること」 ダッシュボードは結果の表示。 重要なのはシステムの状態を 「理解・説明できる」 ことが本質。 ❌ 誤解 🔍 「ログを探せばいい」 ログは記録であって、原因に直接つながる とは限らない。事後的な調査では間に合 わないことも多い。 大事なのは障害につながる エラーを素早 く特定する為の情報が過不足なく記載 さ れている事 ❌ 誤解 📊 「SREやインフラの仕事」 特定のチーム、人に依存してしまうのは単一障 害点になり、次第にヒロイズムなチームになって しまう。大事なのは、 チームの誰もがシステムを 理解できる状態を作ること。ヒーローに頼るの ではなく、仕組みで解決する。 ❌ 誤解
24. 24 ヒロイズムなチームとは? “ソフトウェア業界における、このようなヒーロカ ルチャーの側面を強調させてください。モノリ シックなシステムで、LAMPスタック的な運用を する場合、一般的に最後の砦となるデバッ ガーはもっとも長くそこにいる人で、つまりゼ ロからシステムを作り上げた人 です... そのようなエンジニアは傷跡を多く残し、多くの 障害のカタログを心の在庫に抱え、その日を救 う為に必然的に舞い降りるのです”
25. 25 “結果として、そのようなヒーローは真の休暇を 取ることができません。” ヒロイズムなチームとは?
26. 26 • 特定の人だけが障害を解決できる ◦ 「〇〇さんに聞けばわかる」状態 • 問題が再発しても毎回同じ人が手動で対処する（仕組み化されない） ◦ ドキュメントがなく、知識が属人の頭の中にしか存在しない • 新しいメンバーがいつまでも戦力になれない • 深夜・休日でもその人に連絡が来る（心理的・身体的消耗） • その人が退職した瞬間、チームが機能不全になる ヒロイズムなチームとは?
27. 27 ⚠ ①システムで問題が起きる前か ら、常にAPM等でプロアクティブ にモニタリングを行い、どこが原因 で発生したか原因がすぐに把握で きる ②システムの状態を誰でも把握で きるようにシステム化し、特定の誰 かに情報が依存しないようにする オブザーバビリティとは何か
28. オブザーバビリティを意識し た開発について 28
29. 29 オブザーバビリティを意識した開発について ref: https://newsletter.semianalysis.com/p/claude-code-is-the-inflection-point
30. 30 • 生成AI時代、全員がAI Agentを活用する のが当たり前でコードの生成量が激増し ている • 2026年の年末には「1日のコミットの20％ 以上がClaude Codeによるもの」になる 可能性があるとのこと。 • エンジニアの作業としては今後「書く」作業 よりも、「確かめる」作業 が増えることが予 想されている (もう既に来ている..? 🤔) ref: https://newsletter.semianalysis.com/p/claude-code-is-the-inflection-point オブザーバビリティを意識した開発について
31. 31 生成AI登場前 自分でコードを書く → 仕組みを自然に理解している 問題が起きる → 書いた本人が追跡できる AI時代 AIがコードを書く → 仕組みを深く理解しなくても動く 問題が起きる → ??? オブザーバビリティを意識した開発について 「動いているからヨシッ !👈」
32. 32 生成AI登場前 自分でコードを書く → 仕組みを自然に理解している 問題が起きる → 書いた本人が追跡できる AI時代 AIがコードを書く → 仕組みを深く理解しなくても動く 問題が起きる → 仕組みを理解してないので原因の 特定難しい ⚠ 顕在化してきた問題 • コードの生成量は増えたが、そのコードへの「理解」が追いついていない • バイブコーディングで書かれたコードが仕様曖昧なまま本番 に行く • 本番で問題が起きたとき、AIが書いたコードの挙動を誰も追えない オブザーバビリティを意識した開発について
33. 33 👷人間が得意なこと • 本番での挙動を観測できる設計 • 適切なコンテキストを記録すること • システムの意図・ドメインを理解すること • いつ誰のリクエストかを追跡する計装 オブザーバビリティを意識した開発について 調査(デバッグ)に必要なデータを過不足なく収集するには、人間の判断が必要 🤖 AIが得意なこと • 動くコードを速く生成する • 定型処理・ボイラープレートを書く • テストコードを補完する • 既存コードのリファクタリング提案
34. 34 オブザーバビリティを意識した開発について Known Unknowns（知っている未知） 「DBが遅くなるかもしれない」 → 予測できる → 従来のモニタリングで対処可 例: CPU 80% → アラート エラー率 1% → アラート Unknown Unknowns（知らない未知） 予測できない問題 → オブザーバビリティが必要 例: • このユーザーの組み合わせのときだけ遅い • 特定の時間帯だけ外部APIが失敗する • AIが生成したコードの想定外の挙動 Unknown Unknownsの問題こそ　オブザーバビリティの観点が必要
35. わかること: 特定ユーザーのトレースを絞り込める 特定の処理だけを追える → 根本原因まで到達できる user_id = "12345" trace_id = "ABCD12345" service_name = "odawara_prd" ✅ 高いカーディナリティ 取り得る値: 特定のユーザに紐づくデータ → ユニーク値が多い 35 オブザーバビリティを意識した開発について ❌ 低いカーディナリティ 取り得る値: success / error → 2種類しかない わかること: 「エラーが起きた」しかわからない 特定ユーザー？特定条件？ → 絞り込みができない status = "error" ※カーディナリティ(Cardinality): データベースやデータ分析において、特定の列（カラム）に含まれるユ ニーク（一意）な値の種類の多さ
36. 36 オブザーバビリティを意識した開発について 構造化データを用意する事で絞り込み・集計・ツール連携がすべて可能でより、早く原因が特定ができる ❌ 非構造化ログ（プレーンテキスト） "Error: user 12345 failed to process order abc at 03:00" 問題点 • 人間が目で読むしかない • フィールドで絞り込もうにも曖昧検索で無駄な データも収集してしまう structured_log.json { "level": "error", "user_id": 12345, "order_id": "abc-789", "error_type": "TimeoutException", "db_ms": 5320, "trace_id": "abc...xyz", "timestamp": "2025-01-01T03:00Z" }
37. 37 オブザーバビリティを意識した開発について • 生成AI時代だからこそ書いたコードを オブザーバビリティの観点から実装 and レビューする ◦ 「本番で失敗したとき、原因を詳細に把握できるか？ 」を意識する • コードレビューする際にも「障害が起きた時にこの問題を追えるか？」を問う ◦ とりあえず catch して throw するコードよりも、特定の値(user_id、リクエス ト内容、エラー種別 )、正しい構造化されたデータ でログがでるかを見る
38. 個人からチーム、組織へ の広がりについて 38
39. 39 ⚠ ①システムで問題が起きる前か ら、常にAPM等でプロアクティブ にモニタリングを行い、どこが原因 で発生したか原因がすぐに把握で きる ②システムの状態を誰でも把握で きるようにシステム化し、特定の誰 かに情報が依存しないようにする 個人からチーム、組織への広がりについて
40. 40 個人からチーム、組織への広がりについて “オブザーバビリティがあれば、技術的な能力に 関係なく、組織全員が快適にデータを操作し、 より良い顧客体験を構築するために、十分な情 報に基づいた意識決定ができるように、データ について気軽に話せます。 言い換えれば、オブザーバビリティデータを民 主化する事です。 ”
41. 個人からチーム、組織への広がりについて 👤 ユーザー 「画面が 使えません...」 📞 CS 「クレームが 20件来てます！！」 🔥 障害発生中!! 担当チーム: ??? 原因: ??? 経過時間: ⏱ 〇〇時間... 「状況はわかり次第...」 📋 PdM 「いつ直る？ ユーザー影響は？」 💻 フロントエンド 「フロントのAPIは 全て正常です」 「Backend確認して」 ⚙ バックエンド 「BEは正常。 インフラ確認して」 「インフラ確認して」 🖥 SRE 「サーバーは 全て正常ですよ🤷」 オブザーバビリティがない = 特定するデータがない為「どこに問題があるか ?」 がわからず解決まで、時間を費やしてしまう
42. 個人からチーム、組織への広がりについて 👤 ユーザー 「対応中との 連絡ありました」 📞 CS 「クレームが 20件来てます！！」 📋 PdM 「影響ユーザー 約50件と判明」 💻 フロントエンド 「TraceIDで リクエストを追えた」 ⚙ バックエンド 「DBクエリ遅延 を特定した！」 🖥 SRE 「ダッシュボードで 全体を把握中」 オブザーバビリティを意識したモニタリングを行う事で 全員が同じデータを見て協調でき、すばやく根本原因を特定・解決できる ✅ データで状況を共有中 担当チーム: バックエンド ✓ 原因: DBクエリ遅延 ✓ 対応時間: ⏱ 15分で解決！ 「TraceID共有します」 「50名、対応中と連絡」 「修正リリース完了✓」
43. まとめ 43
44. 44 まとめ • オブザーバビリティを意識する事によって、監視するのでは なく、システムで問題が起きる前からプロアクティブにモニタ リングを行い、どこが原因で発生したか原因がすぐに把握 できるようになる • オブザーバビリティは個人ではなく、チーム全体で、システ ムの状態を誰でも把握する事で障害が起きても効果的に 調査ができる
45. 45 オブザーバビリティとは何か “ソフトウェアシステムにオブザーバビリティ を持たせるために、特定のツールを採用す る必要はないのです。むしろ、オブザーバ ビリティを実現する為には、効果的なデ バッグに必要なデータを収集する為の考 えた方を進化させる必要だと、私たちは 考えています 。”
46. 46 コード増え 問いかける目を 人が持つ
47. 47 ご清聴ありがとうございました ! 🏯
48. 参考文献 48
49. 49 • オブザーバビリティ・エンジニアリング • 入門 Open Telemetry • 組織で育むオブザーバビリティ • https://bering.hatenadiary.com/entry/2023/05/28/105852 • LINEスタンプの実例紹介 小さく始める障害検知・対応・振り返りの 改善プラクティス • オブザーバビリティが育むシステム理解と好奇心 • オブザーバビリティと育てた ID管理・認証認可基盤の歩み