# クリティカルユーザージャーニー ## 定義 クリティカルユーザージャーニー(Critical User Journey, CUJ)は、ユーザーが重要な作業を達成するための一連の手順であり、多くの場合は複数のサービスにまたがる (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]])。Google SRE は CUJ を、ユーザーの目標(友人と連絡する)→ タスク(メールを送る)→ 操作(作成をクリック)の階層に分け、操作単位の critical user interaction(CUI)を計装と SLO の構成単位とする。対話を伴わない挙動は機能要件・非機能要件で補う (Source: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]])。CUJ は [[サービスレベル目標]] の SLI を選ぶ起点であり、計装・変更監督・テスト・障害診断の単位にも使われる。 ## 定義の単位と粒度 - **CUJ はユーザーの目標を単位にサービス横断で定義するものであり、サービス側から見て自明な操作の列挙では足りない。** - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]] — CUJ はユーザー視点でシステム横断に定義すべきとする - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] — 目標 → タスク → CUI の階層。CUJ は狭すぎず広すぎず単純に定義する - 根拠: [[@2024__SRENext2024__Enabling Client-side SLO]] — Luup は「施錠・解錠・ライド開始・ライド終了」という自明な CUJ を、PdM・SWE・SRE の議論でユーザージャーニーマトリクスへ作り直した - **CUJ の違いを無視して単一の SLO に潰すと、SLO という考え方そのものが形骸化する。** - 根拠: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]] — CUJ ごとの SLO の代わりに全体へ可用性 99.95% を宣言した企業の失敗例 - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 4 The Cultural Context of SRE]] — ブラウンフィールドの初期 SLO は CUJ に結びつく重要な SLI 2〜3 個に絞り、現状の実績に基づいて置く - **CUJ の「ユーザー」はエンドユーザーに限らず、対象に合わせて置き換えられる。** - 根拠: [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]] — IoT では CUJ の代わりに CMC(Critical Machine Communication)を起点に、機械が期待どおり動ける状態を SLI にする - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 17 Designing for Resilience]] — インシデント対応者自身の CUJ を comms / imag / dash / reach / doc / priv / dbg / fix の 8 カテゴリに分け、通常系と緊急時のフォールバックを対応づける ## 計測と SLI 化 - **CUJ の計測はサーバー側の時系列だけでは足りず、クライアント側の計装と合成監視を組み合わせる必要がある。** - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] — サーバー側時系列由来の SLO は、顧客が重要タスクを完了できない状態でも健全を示しうる - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]] — CUJ の SLO はフロントエンドを通したトレースで測り、クライアント側 SLI と、CUJ の全コードパスを通す合成リクエストで補う - 根拠: [[@2024__SRENext2024__Enabling Client-side SLO]] — API だけを測ると BLE 操作や Firestore 直接通信が漏れる。CUJ の実行時間の p75 をレイテンシ SLI にした - 関連: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] — 「サンプルワークフローが成功するか」という粗い全体 SLI が個別 SLI の盲点を補う - **CUJ を直接測れないときは、代理指標やプローバで「測れるもの」と「測りたいもの」の差を縮める。** - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 4 The Cultural Context of SRE]] — CUJ を直接計測できないときは代理指標で差を最小化する - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]] — 単独 SRE は最重要のユーザー向け部分に絞り、CUJ をプローバで測る - 根拠: [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]] — プローバによる能動的計測を SLO 導入の起点にする - **CUJ は計装設計の出発点であり、トレースコンテキストで伝播させれば観測データを切る一次元になる。** - 根拠: [[@2026__OReilly__Observability Engineering 2E - Chapter 4 Getting Started with Instrumentation]] — カスタム計装の出発点はユーザー登録・商品検索・チェックアウトのような CUJ の特定で、次にドメイン固有のエラー条件を捉える - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] — CUI/CUJ をトレースコンテキストでスタック全体へ伝播させる ## 合意形成と組織への定着 - **CUJ の選定は SRE 単独の作業ではなくプロダクト側との合意形成であり、SLO 導入で最も時間のかかる段階になりやすい。** - 根拠: [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]] — 定義の難しさとして、CUJ から SLO までの合意形成と追加計装に時間がかかりすぎることを挙げる - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]] — SRE だけが主導する SLO プロセスはバックエンドに偏り、フロントエンド SLO の欠落が典型的な欠陥になる - 根拠: [[@2024__SRENext2024__Enabling Client-side SLO]] — PdM が Figma でユーザージャーニー一覧を作り、CUJ ごとに iOS/Android のグラフを並べたダッシュボードを週次で確認した ## 変更監督・テスト・障害診断への展開 - **CUJ は SLO の単位を超えて、変更の監督・テスト・障害診断に共通する単位として使われ始めている。** - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] — CUJ テレメトリでバイナリ・設定・機能ランプ・データ更新などの変更を自動監督し、ロールアウト停止やロールバックにつなげる - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 14 Testing]] — スモークテストで CUJ が通ることを検査する - 根拠: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]] — CUJ の障害診断をブラウザ可視の証拠とバックエンドのテレメトリの突き合わせとして評価する - **ユーザーに見える症状から始める診断は、バックエンドのテレメトリだけを見る評価では測れない難しさを持つ。** - 根拠: [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]] — 既存の AIOps ベンチマークはバックエンドのテレメトリだけで評価する。6 モデルの全体 A@1 は 19.7% で、ブラウザ限定のエージェント(28%)が全ツールのエージェント(19.9%)を上回った - 根拠: [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]] — サーバー側の健全性と顧客のタスク完了は一致しない ## 未解決の問い - CUJBench ではツールを増やしたエージェントの方が正答率が下がった。CUJ をトレースコンテキストの次元として伝播させる設計(第2版第9章)は、エージェントの探索を CUJ に絞る手掛かりとして効くか。 - ログインやセッション維持を伴う動的・ステートフルな CUJ の障害を、スナップショット方式のベンチマークでどう評価するか。 - 正否が確率的な AI 出力を含む CUJ(エージェント製品など)で、「重要な作業を達成できた」をどう判定し SLI にするか。第2版第8章は SLO モデルの前提が揺らぐ例として AI 出力を挙げるが、CUJ 側の定義は示していない。 - CMC や対応 CUJ のように「ユーザー」を置き換える拡張は、どこまで CUJ と同じ設計手順(目標 → タスク → 操作)で扱えるか。 ## 未編纂の観察 ## 関連 - 概念: [[サービスレベル目標]] / [[意味のあるSLI設計]] / [[オブザーバビリティ]] / [[分散トレーシング]] / [[エラーバジェット]] - エンティティ: [[Site Reliability Engineering 2nd Edition]] / [[CUJBench]] / [[Luup]] / [[Google]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 8 Service Level Objectives]](Beyer, B., Jones, C., Leng, C., Huska, D., Petoff, J., Murphy, N. R.(編), *Site Reliability Engineering*, 2nd ed., O'Reilly, 2026, Chapter 8。CUJ の定義、フロントエンド SLO の欠落、合成監視) - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 9 Observability and Monitoring]](同 Chapter 9。CUJ/CUI の階層、顧客中心の SLO、CUJ による変更監督) - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 4 The Cultural Context of SRE]](同 Chapter 4。ブラウンフィールドの初期 SLO と代理指標) - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 14 Testing]](同 Chapter 14。スモークテスト) - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 17 Designing for Resilience]](同 Chapter 17。対応 CUJ) - [[@2026__OReilly__Site Reliability Engineering 2E - Chapter 22 SRE in Diverse Environments]](同 Chapter 22。単独 SRE のプローバ計測) - [[@2024__SRENext2024__Enabling Client-side SLO]](Wataru Tsuda, SRE NEXT 2024。CUJ 再設定とクライアントサイド SLO) - [[@2023__SRENext2023__電動マイクロモビリティのシェアサービス「LUUP」におけるEnabling SLOの実践]](Wataru Tsuda, SRE NEXT 2023。CMC) - [[@2026__Road to SRE NEXT 2026 神戸__小さくはじめるSLI-SLO 育てながら組織に定着させる実践知]](Narimichi Takamura。SLI/SLO 定義の難しさ) - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 6 Googleを超えて]](単一 SLO への単純化の失敗例) - [[@2026__OReilly__Observability Engineering 2E - Chapter 4 Getting Started with Instrumentation]](計装戦略の起点としての CUJ) - [[@2026__arXiv__CUJBench - Benchmarking LLM-Agent on Cross-Modal Failure Diagnosis from Browser to Backend]](CUJ 障害のクロスモーダル診断ベンチマーク) - [[@2018__SREcon18Americas__SLOs and SLIs in the Real World - A Deep Dive]](プローバと全体 SLI)