ユーザー中心オブザーバビリティ

# ユーザー中心オブザーバビリティ ## 定義ユーザー中心オブザーバビリティは、問題検知の出発点を反転させる手法である。従来のオブザーバビリティはまずアプリ・システム側の技術的異常を検知し、そこからユーザーへの影響を推測する順序を取る。これに対しユーザー中心オブザーバビリティは、まずユーザーの意図と成果を直接モデル化した指標(例: チェックアウト完了率=完了したチェックアウト数/チェックアウト試行数)の変化を検知し、そこから背後にある技術的異常を切り分ける。この順序転換により「検知された変化が本当にユーザーに影響するか」という議論自体が不要になる——ユーザー影響がすでに検知の起点だからである。ユーザーの意図表明から目標達成までの間に生じるあらゆる摩擦(パフォーマンス劣化・バグを含む)がこの成果指標に反映されると仮定し、汎用的な集計指標やベンダー製の「スコア」、感情分析のような曖昧な代理指標ではなく、ユーザーの意図と結果を直接紐づけたイベントを不偏な代理指標として用いる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]] "Quantifying User Experience", "Adapting Existing Approaches") ## 横断的知見 - 「症状(what)から始めて原因(why)を後から調べる」という検知順序の反転は、モバイル領域に限らずサービスレベル目標(SLO)ベースのアラーティングにも共通する設計思想である。第11章はSLOベースのアラートが「何が起きているか」と「なぜ起きているか」を分離し、潜在原因(CPU使用率上昇など)ではなくユーザー体験劣化という症状に基づいてアラートすることで常にアクショナブルになると論じる。第19章のユーザー中心オブザーバビリティは、この「症状駆動」の考え方をアラーティングの文脈から一段深い分析ワークフロー(コホート分析による根本原因の反復的な絞り込み)にまで拡張したものと位置づけられる。両者とも起点をユーザー体験の指標に置く点で一致するが、第11章は主にリアルタイムアラーティングの設計、第19章は事後的な原因究明の反復プロセスに重心を置く違いがある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]], [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]]) - **ユーザー中心の信号だけでは「最後の1マイル」に届かず、事業中心の信号との結合が必要になることを本番事例が示す**: 第19章のユーザー中心オブザーバビリティはユーザーの意図と成果を直接モデル化した指標(チェックアウト完了率など)を検知の起点に置く設計思想を示すが、[[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]](Fin/Intercom)の本番事例は、顧客中心の信号(time to first token)だけを最適化した結果、Finが関与しない対話でも無駄なLLM呼び出しコストが発生し、財務チームの四半期レビューで初めて発覚するという失敗を経験した。著者はこれを踏まえ、顧客中心の信号と事業中心の信号(対話あたりコスト)を同じ低レベルトレーステレメトリに結合することこそオブザーバビリティの「最後の1マイル」だと結論づける。第19章が「ユーザー中心」を提唱する段階で留まるのに対し、第22章は「ユーザー中心だけでは組織のもう一つの安全境界(経済的失敗)を見落とす」という実例により、ユーザー中心指標の限界と拡張の必要性を具体的に示している。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]], [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]]) → [[事故モデル]] - **「症状から始めて原因を後から調べる」検知順序の反転は、オブザーバビリティ設計だけでなく事前の SLI 選定にも独立に現れる**: 第19章が定義する「ユーザーの意図・成果指標の変化を検知の起点に置く」という発想は、[[Alex Hidalgo]] が『SLO サービスレベル目標』3 章で説く「サービスが何を実行すべきかではなく、ユーザーが何を実行する必要があるか」という SLI 設計の起点と同型である。前者は事後的な異常検知(何から調べ始めるか)、後者は事前的な指標選定(何を SLI にするか)に焦点があり、適用フェーズは異なるが「ユーザー起点への転換」という設計思想は独立した文脈で収束している。詳細は [[意味のあるSLI設計]] を参照。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]]) ## 未解決の問い - ユーザー中心オブザーバビリティの成果指標(チェックアウト完了率など)は、第11章が論じるSLI/SLOの形式的な仕組み(エラーバジェット、バーンレートアラート)に落とし込めるか。第19章はアラーティングへの統合を扱っておらず、両者を接続する具体的な設計は示されていない。 - ユーザー中心の信号(第19章)と事業中心の信号(第22章)を「同じトレース基盤に結合する」という設計は具体例(Finの対話あたりコスト)を持つが、汎用的な設計パターン(どの粒度でどの信号を結合すべきか)としてはまだ一般化されていない。モバイル/フロントエンド以外のドメイン(バックエンドAPI、バッチ処理)でも同様の結合パターンは成立するか。 - コホート比較における交絡バイアス(第19章の「早期採用者は高性能端末を持つ」例)を体系的に検出・補正する統計的手法は、本ソースには示されていない。バックエンドのA/Bテスト・因果推論の知見をどこまで転用できるか。 - 「ユーザーの意図」をどう定義・計装するかは業務ドメインごとに異なる(第19章はチェックアウトを例にするが汎用的な設計指針は示されていない)。意図の粒度(画面遷移単位かセッション単位か)をどう選ぶべきかは未解決。 ## 関連 - 概念: [[モバイルオブザーバビリティ]] / [[サービスレベル目標]] / [[アクショナブルアラート]] / [[事故モデル]] / [[GenAI オブザーバビリティ]] / [[意味のあるSLI設計]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 11 Using Service Level Objectives for Reliability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 22 Fin’s Case Study in Modern Engineering]] / [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 3 意味のあるサービスレベル指標の開発]] - エンティティ: [[Hanson Ho]] / [[Matt Klein]] / [[Fin]] / [[Intercom]] / [[Alex Hidalgo]] ## 出典 - Charity Majors, Liz Fong-Jones, George Miranda, with Austin Parker, *Observability Engineering*, 2nd Edition, O'Reilly Media, 2026, Chapter 19・Chapter 11・Chapter 22。 - Alex Hidalgo, 『SLO サービスレベル目標』, オライリー・ジャパン, 2023, 3 章(検知順序の反転という設計思想の独立した収束点)。