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

by Futoshi Endo

Embed

Start on current slide

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 自己紹介氏名: 遠藤太徳 (Endo Futoshi) 所属: New Relic株式会社(New Relic, K.K.) 役職: Technical Account Manager Webアプリケーションエンジニアとして API開発、既存サービスのリファクタリング、CREとしてユーザー体験改善、チームビルディングを経験。現職では New Relic のTechnical Account Manager として活用支援や、勉強会を行っています。 PHP歴は9年程🐘 趣味: 音楽、料理、ゲーム、個人開発、どんちゃん (豆柴)と散歩

Slide 3

Slide 3 text

3 ref: 【PHPカンファレンス小田原 2025】New RelicのAPMを活用したECサービスにおけるメール遅延解消の舞台裏

Slide 4

Slide 4 text

Goal 4

Slide 5

Slide 5 text

5 (1)オブザーバビリティがどういった概念なのか?を理解できる (2)オブザーバビリティはSRE、インフラエンジニアだけが意識するのではなく、エンジニア含めステークホルダー全員で意識する事で、より開発しやすくなる事が理解できる

Slide 6

Slide 6 text

免責事項 6

Slide 7

Slide 7 text

7 01 スライドの内容は主に自分のこれまでの業務経験で得た知見を元にスライドを作成しています。特定のツールを使った方法論よりも、抽象的な話が多いです。 02 オブザーバビリティの概念が広い為スライドでは説明がしきれてない箇所が出てきます。気になる方は懇親会等で気軽にお話しましょう! 🏯

Slide 8

Slide 8 text

Agenda 8

Slide 9

Slide 9 text

9 (1) オブザーバビリティとはなにか (2) オブザーバビリティを意識した開発について (3) 個人からチーム、組織への広がりについて (4) まとめ

Slide 10

Slide 10 text

オブザーバビリティとは何か 10

Slide 11

Slide 11 text

11 オブザーバビリティ Logs（ログ） Traces（トレース）エラーバジェット MTTR アラート SLI/SLO SLA APM Synthetics Real User Monitoring 分散トレーシングダッシュボード計装 CUJ 構造化ログポストモーテムオブザーバビリティとは何か

Slide 12

Slide 12 text

12 オブザーバビリティ Logs（ログ） Traces（トレース）エラーバジェット MTTR アラート SLI/SLO SLA APM Synthetics Real User Monitoring 分散トレーシングダッシュボード計装 CUJ 構造化ログポストモーテムオブザーバビリティとはどういった概念なの ? オブザーバビリティとは何か

Slide 13

Slide 13 text

13 “Kalmanは1960年の論文で、ある特徴をオブザーバビリティと名付け、数学的制御システムを説明しました。制御理論では、オブザーバビリティとは、外部出力の知識からシステムの内部状態をどれだけうまく推測できるかの尺度として定義されています。” オブザーバビリティとは何か

Slide 14

Slide 14 text

14 オブザーバビリティとは何か “ソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。また、そのような斬新で奇妙な状態に対しても、事前にデバッグの必要性を定義したり予測したりすることなく、システムの状態データのあらゆるディメンションやそれらの組み合わせについてアドホックに調査し、よりデバッグが可能であるようにする必要があります”

Slide 15

Slide 15 text

15 ①障害発生! 原因がわからないのでまずはダッシュボードやログを見る ⚠

Slide 16

Slide 16 text

16 ①障害発生! 原因がわからないのでまずはダッシュボードやログを見る ②ログを見てもどれが該当のログなのかわからない ⚠

Slide 17

Slide 17 text

17 ①障害発生! 原因がわからないのでまずはダッシュボードやログを見る ②ログを見てもどれが該当のログなのかわからない ③仕様に詳しい社歴の長い先輩、また専任のSREチームにメンションして確認してもらう ⚠

Slide 18

Slide 18 text

18 ①障害発生! 原因がわからないのでまずはダッシュボードやログを見る ②ログを見てもどれが該当のログなのかわからない ⚠ これはオブザーバビリティを実践できているでしょうか? ③仕様に詳しい社歴の長い先輩、また専任のSREチームにメンションして確認してもらう

Slide 19

Slide 19 text

19 “ソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。また、そのような斬新で奇妙な状態に対しても、事前にデバッグの必要性を定義したり予測したりすることなく、システムの状態データのあらゆるディメンションやそれらの組み合わせについてアドホックに調査し、よりデバッグが可能であるようにする必要があります” オブザーバビリティとは何か

Slide 20

Slide 20 text

20 ①障害発生! 原因がわからないのでまずはダッシュボードやログを見る ②ログを見てもどれが該当のログなのかわからない ⚠ これはオブザーバビリティを実践できているでしょうか? ③仕様に詳しい社歴の長い先輩、また専任のSREチームにメンションして確認してもらう

Slide 21

Slide 21 text

21 ②ログを見てもどれが該当のログなのかわからない ⚠🖥 「ダッシュボードを見ること」ダッシュボードは結果の表示。重要なのはシステムの状態を「理解・説明できる」ことが本質。 ❌ 誤解 ③仕様に詳しい社歴の長い先輩、また専任のSREチームにメンションして確認してもらう

Slide 22

Slide 22 text

22 ⚠🖥 「ダッシュボードを見ること」ダッシュボードは結果の表示。重要なのはシステムの状態を「理解・説明できる」ことが本質。 ❌ 誤解 🔍 「ログを探せばいい」ログは記録であって、原因に直接つながるとは限らない。事後的な調査では間に合わないことも多い。大事なのは障害につながるエラーを素早く特定する為の情報が過不足なく記載されている事 ❌ 誤解 ③仕様に詳しい社歴の長い先輩、また専任のSREチームにメンションして確認してもらう

Slide 23

Slide 23 text

23 ⚠🖥 「ダッシュボードを見ること」ダッシュボードは結果の表示。重要なのはシステムの状態を「理解・説明できる」ことが本質。 ❌ 誤解 🔍 「ログを探せばいい」ログは記録であって、原因に直接つながるとは限らない。事後的な調査では間に合わないことも多い。大事なのは障害につながるエラーを素早く特定する為の情報が過不足なく記載されている事 ❌ 誤解 📊 「SREやインフラの仕事」特定のチーム、人に依存してしまうのは単一障害点になり、次第にヒロイズムなチームになってしまう。大事なのは、チームの誰もがシステムを理解できる状態を作ること。ヒーローに頼るのではなく、仕組みで解決する。 ❌ 誤解

Slide 24

Slide 24 text

24 ヒロイズムなチームとは? “モノリシックなシステムで、LAMPスタック的な運用をする場合、一般的に最後の砦となるデバッガーはもっとも長くそこにいる人で、つまりゼロからシステムを作り上げた人です... そのようなエンジニアは傷跡を多く残し、多くの障害のカタログを心の在庫に抱え、その日を救う為に必然的に舞い降りるのです”

Slide 25

Slide 25 text

25 “結果として、そのようなヒーローは真の休暇を取ることができません。 ” ヒロイズムなチームとは?

Slide 26

Slide 26 text

26 ● 特定の人だけが障害を解決できる ○ 「〇〇さんに聞けばわかる」状態 ● 問題が再発しても毎回同じ人が手動で対処する（仕組み化されない） ○ ドキュメントがなく、知識が属人の頭の中にしか存在しない ● 新しいメンバーがいつまでも戦力になれない ● 深夜・休日でもその人に連絡が来る（心理的・身体的消耗） ● その人が退職した瞬間、チームが機能不全になるヒロイズムなチームとは?

Slide 27

Slide 27 text

27 ⚠ ①システムで問題が起きる前から、常にAPM等でプロアクティブにモニタリングを行い、どこが原因で発生したか原因がすぐに把握できる ②システムの状態を誰でも把握できるようにシステム化し、特定の誰かに情報が依存しないようにするオブザーバビリティとは何か

Slide 28

Slide 28 text

オブザーバビリティを意識した開発について 28

Slide 29

Slide 29 text

29 オブザーバビリティを意識した開発について ref: https://newsletter.semianalysis.com/p/claude-code-is-the-inﬂection-point

Slide 30

Slide 30 text

30 ● 生成AI時代、全員がAI Agentを活用するのが当たり前でコードの生成量が激増している ● 2026年の年末には「1日のコミットの20％以上がClaude Codeによるもの」になる可能性があるとのこと。 ● エンジニアの作業としては今後「書く」作業よりも、「確かめる」作業が増えることが予想されている (もう既に来ているかも? 🤔) ref: https://newsletter.semianalysis.com/p/claude-code-is-the-inﬂection-point オブザーバビリティを意識した開発について

Slide 31

Slide 31 text

31 生成AI登場前自分でコードを書く → 仕組みを自然に理解している問題が起きる → 書いた本人が追跡できる AI時代 AIがコードを書く → 仕組みを深く理解しなくても動く問題が起きる → ??? オブザーバビリティを意識した開発について「動いているからヨシッ !👈」

Slide 32

Slide 32 text

32 生成AI登場前自分でコードを書く → 仕組みを自然に理解している問題が起きる → 書いた本人が追跡できる AI時代 AIがコードを書く → 仕組みを深く理解しなくても動く問題が起きる → 仕組みを理解してないので原因の特定難しい ⚠ 顕在化してきた問題 • コードの生成量は増えたが、そのコードへの「理解」が追いついていない • バイブコーディングで書かれたコードが仕様曖昧なまま本番に行く • 本番で問題が起きたとき、AIが書いたコードの挙動を誰も追えないオブザーバビリティを意識した開発について

Slide 33

Slide 33 text

33 👷人間が得意なこと • 本番での挙動を観測できる設計 • 適切なコンテキストを記録すること • システムの意図・ドメインを理解すること • いつ誰のリクエストかを追跡する計装オブザーバビリティを意識した開発について調査(デバッグ)に必要なデータを過不足なく収集するには、人間の判断が必要 🤖 AIが得意なこと • 動くコードを速く生成する • 定型処理・ボイラープレートを書く • テストコードを補完する • 既存コードのリファクタリング提案

Slide 34

Slide 34 text

34 オブザーバビリティを意識した開発について Known Unknowns（知っている未知）「DBが遅くなるかもしれない」 → 予測できる → 従来のモニタリングで対処可例: CPU 80% → アラートエラー率 1% → アラート Unknown Unknowns（知らない未知）予測できない問題 → オブザーバビリティが必要例: • このユーザーの組み合わせのときだけ遅い • 特定の時間帯だけ外部APIが失敗する • AIが生成したコードの想定外の挙動 Unknown Unknownsの問題こそ　オブザーバビリティの観点が必要

Slide 35

Slide 35 text

わかること: 特定ユーザーのトレースを絞り込める特定の処理だけを追える → 根本原因まで到達できる user_id = "12345" trace_id = "ABCD12345" service_name = "odawara_prd" ✅ 高いカーディナリティ取り得る値: 特定のユーザに紐づくデータ → ユニーク値が多い 35 オブザーバビリティを意識した開発について ❌ 低いカーディナリティ取り得る値: success / error → 2種類しかないわかること: 「エラーが起きた」しかわからない特定ユーザー？特定条件？ → 絞り込みができない status = "error" ※カーディナリティ(Cardinality): データベースやデータ分析において、特定の列（カラム）に含まれるユニーク（一意）な値の種類の多さ

Slide 36

Slide 36 text

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" }

Slide 37

Slide 37 text

37 オブザーバビリティを意識した開発について ● 生成AI時代だからこそ書いたコードをオブザーバビリティの観点から実装 and レビューする ○ 「本番で失敗したとき、原因を詳細に把握できるか？」を意識する ● コードレビューする際にも「障害が起きた時にこの問題を追えるか？」を問う ○ とりあえず catch して throw するコードよりも、特定の値(user_id、リクエスト内容、エラー種別 )、正しい構造化されたデータでログがでるかを見る

Slide 38

Slide 38 text

個人からチーム、組織への広がりについて 38

Slide 39

Slide 39 text

39 ⚠ ①システムで問題が起きる前から、常にAPM等でプロアクティブにモニタリングを行い、どこが原因で発生したか原因がすぐに把握できる ②システムの状態を誰でも把握できるようにシステム化し、特定の誰かに情報が依存しないようにする個人からチーム、組織への広がりについて

Slide 40

Slide 40 text

40 個人からチーム、組織への広がりについて “オブザーバビリティがあれば、技術的な能力に関係なく、組織全員が快適にデータを操作し、より良い顧客体験を構築するために、十分な情報に基づいた意識決定ができるように、データについて気軽に話せます。言い換えれば、オブザーバビリティデータを民主化する事です。 ”

Slide 41

Slide 41 text

個人からチーム、組織への広がりについて 📞 CS 「クレームが 20件来てます！！」 🔥 障害発生中!! 担当チーム: ??? 原因: ??? 経過時間: ⏱ 〇〇時間... 「状況はわかり次第...」 📋 PdM 「いつ直る？ユーザー影響は？」 💻 フロントエンド「フロントのAPIは全て正常です」「フロントエンド確認して!」 ⚙ バックエンド「BEは正常。インフラ確認して」「バックエンドみてもらっていいですか?」 🖥 SRE 「サーバーは全て正常です」オブザーバビリティがない = 特定するデータがない為「どこに問題があるか ?」がわからず解決まで、時間を費やしてしまう。原因の特定はできますか? 「インフラはどうなっていますか?」 👤 ユーザー「画面が使えません...」

Slide 42

Slide 42 text

個人からチーム、組織への広がりについて 👤 ユーザー「すぐに復旧するなら少し待とうなぁ」 📞 CS 「対応中との連絡ありました 📋 PdM 「影響ユーザー約50件と判明」 💻 フロントエンド「TraceIDでリクエストを追えた」 ⚙ バックエンド「DBクエリ遅延を特定した！」 🖥 SRE 「ダッシュボードで全体を把握中」オブザーバビリティを意識したモニタリングを行う事で全員が同じデータを見て協調でき、すばやく根本原因を特定・解決できる ✅ データで状況を共有中担当チーム: バックエンド ✓ 原因: DBクエリ遅延 ✓ 対応時間: ⏱ 15分で解決！「TraceID共有します」「修正リリース完了」

Slide 43

Slide 43 text

まとめ 43

Slide 44

Slide 44 text

44 まとめ ● オブザーバビリティを意識する事によって、監視するのではなく、システムで問題が起きる前からプロアクティブにモニタリングを行い、どこが原因で発生したか原因がすぐに把握できるようになる ● オブザーバビリティは個人ではなく、チーム全体で、システムの状態を誰でも把握する事で障害が起きても効果的に調査ができる

Slide 45

Slide 45 text

45 オブザーバビリティとは何か “ソフトウェアシステムにオブザーバビリティを持たせるために、特定のツールを採用する必要はないのです。むしろ、オブザーバビリティを実現する為には、効果的なデバッグに必要なデータを収集する為の考えた方を進化させる必要だと、私たちは考えています。”

Slide 46

Slide 46 text

46 ご清聴ありがとうございました ! 🏯

Slide 47

Slide 47 text

参考文献 47

Slide 48

Slide 48 text

48 ● オブザーバビリティ・エンジニアリング ● 入門 Open Telemetry ● 組織で育むオブザーバビリティ ● https://bering.hatenadiary.com/entry/2023/05/28/105852 ● LINEスタンプの実例紹介小さく始める障害検知・対応・振り返りの改善プラクティス ● オブザーバビリティが育むシステム理解と好奇心 ● オブザーバビリティと育てた ID管理・認証認可基盤の歩み