ユーザージャーニー監視：インフラ監視をやめよう

多くのSaaSチームはCPUやメモリを監視しているが、チェックアウトのエンドポイントがダウンしていれば、それらの数字は何の意味も持たない。

サーバーのCPU使用率が12%で安定している間も、新規サインアップはすべて静かに失敗し続けることがある。メモリのグラフが完璧に見える裏で、パスワードリセットのフローがすべてのユーザーに500エラーを返しているかもしれない。インフラのメトリクスが教えてくれるのはマシンの健全性だけだ。プロダクトが実際に動いているかどうかについては、ほとんど何も教えてくれない。

このギャップこそが、SaaS企業の収益を蝕む原因だ。

インフラ優先監視の問題点

サーバーメトリクスは収集しやすく、可視化もしやすい。しかしSaaSプロダクトを運営する上では、それらに固執するのはほぼ的外れだ。

アカウント作成、決済処理、API認証、サブスクリプションのアップグレードといった収益を生み出すワークフローは、個別のステップが順番に連なる繊細な構造を持っており、CPUのグラフからはその脆さが見えてこない。チェックアウトのエンドポイントは、ロードバランサーのルール設定ミス、サードパーティの決済ゲートウェイのタイムアウト、デプロイ後の環境変数の破損といった理由で失敗することがある。これらはどれもインフラのダッシュボードにスパイクとして現れない。

その結果、チームが障害を知るのは監視ツールからではなく、カスタマーサポートへのチケット、SNSのクレーム、営業チームからの怒りのSlackメッセージからになってしまう。

ユーザージャーニー監視とは何か

ユーザージャーニー監視は、観察の単位をリソースからワークフローへとシフトさせる。「このサーバーは正常か？」と問う代わりに、「今この瞬間、ユーザーはこの重要なパスを完了できるか？」と問うのだ。

具体的には、次のようなシーケンスを計測することを意味する：

サインアップフロー：POST /api/auth/register → メール認証 → 初回ログイン
チェックアウトフロー：商品選択 → POST /api/payments/charge → 確認ページ
コアプロダクトループ：ログイン → 主要機能の操作 → データの保存

各ステップが潜在的な障害ポイントになる。個別のサーバーリソースではなく、エンドツーエンドのトランザクションとしてこれらのビジネスクリティカルなワークフローを監視することで、ユーザーと収益に実際に影響する障害を早期に検知できる。

ジャーニーの各ステップで追うべきメトリクス

重要なパスの各エンドポイントについて、以下を確認したい：

可用性：2xxを返しているか？期待される箇所で3xxが返っているか？
レイテンシ：P50、P95、P99の応答時間（平均値だけでは不十分）
正確性：レスポンスボディに期待されるフィールドやトークンが含まれているか？
依存関係の健全性：Stripe、Auth0、SendGridなどのサードパーティ連携は応答しているか？

これは、メモリ使用率95%のアラートとは根本的に異なるアプローチだ。

インシデント対応は、何を監視するかによって決まる

監視戦略とインシデント解決速度の間には、直接的な相関関係がある。インフラのメトリクスでアラートを設定しているチームは、障害発生から最初の20〜40分を「ユーザーへの影響があるかどうか」の確認に費やしてしまう。一方、ユーザージャーニーを監視しているチームは即座に把握でき、どのワークフローが壊れているかまで分かる。

インシデント対応プレイブックは、標準化されたロールベースの手順を提供することで解決時間を短縮する。プレッシャー下でのアドリブが不要になるからだ。しかし、これらのプレイブックが機能するのは、それをトリガーするアラートが正しく設定されている場合に限られる。「チェックアウトがダウンしているか確認する」から始まるプレイブックは役に立つ。「CPUが80%を超えているか確認する」から始まるプレイブックは、誰かがユーザーへの影響を確認するまでに15分を無駄にする。

監視をジャーニー優先にすれば、プレイブックも同様に作れる。

SLAコンプライアンスにはビジネスレベルの可視性が必要だ

多くのSaaSのSLAはサーバーの稼働率ではなく、プロダクトの可用性を基準に書かれている。99.9%のアップタイムSLAが意味するのは、プロダクトが年間約8.7時間以上利用不能になってはならないということだ。プロダクトレベルの可用性、つまり実際のエンドポイントへの到達可能性とレスポンスの正確性を監視していなければ、SLAの遵守状況を正確に把握する術はなく、顧客に数字を説明することもできない。

これは複数のクライアントや環境を管理するチームにとって特に重要だ。PulseGuardは、SSL・DNS・セキュリティ監視と並行して30秒ごとのアップタイムチェックを行い、顧客と直接共有できるステータスページを提供することでこの課題に対応している。フリーランサー、エージェンシー、小規模チーム向けのAI対応監視ツールとして、インシデントのトリアージやレポーティングにChatGPT/Claude形式のワークフローを組み込めるMCPアクセスも備えている。

今すぐ実践できること

今週、現在のアラートを棚卸しする。 すべてのアクティブなアラートをリストアップし、それぞれについて「これが発火したとき、ユーザーへの影響があると分かるか？」と問いかける。答えがノーなら、それはせいぜい二次的なアラートに過ぎない。

収益上位の2〜3つのワークフローをマッピングする。 多くのSaaSプロダクトでは、サインアップ・ログイン・コアトランザクションがこれにあたる。これらを主要な監視対象とする。

SLAの計算に合ったチェック間隔を設定する。 5分間隔のチェックでは、壊れたチェックアウトが最大5分間検知されないまま放置される可能性がある。30秒チェックならそのウィンドウを大幅に縮小でき、99.9%の可用性コミットメントに対してより説得力のある数字を示せる。

プレイブックをリソースメトリクスではなく、ジャーニーのステップから構築する。 重要なパスの各ステップに対応するランブックエントリを用意する。何が壊れたか、誰が担当するか、ロールバックやエスカレーションのパスはどうなるかを明記する。

ステータスコードだけでなく、正確性チェックを追加する。 {"error": "payment_failed"} を返す200レスポンスは、健全なチェックアウトではない。レスポンスボディを期待されるスキーマと照合して検証する。

インフラ監視が無意味なわけではない。ただ、それだけでは不十分なのだ。収益に影響するアウテージを数時間ではなく数秒で検知できるチームは、ユーザーが実際に行うことを監視すると決断したチームだ。