CloudWatch Synthetics/RUM本番運用Vol1｜2025新機能

1. フロントエンド可観測性の課題とCloudWatch Synthetics/RUMの全体像

バックエンドのメトリクスやログが正常でも、ユーザーが体感する画面表示の遅さ・操作の引っかかり・特定地域からの接続失敗は見逃されがちです。こうしたフロントエンド/デジタルエクスペリエンスの品質を、合成監視（Synthetics）と実ユーザー監視（RUM）の両面から捉えるのがCloudWatch Synthetics/RUMです。

フロントエンド可観測性はバックエンド可観測性と並んで、AWSのサービス品質保証の両輪をなします。バックエンドでサーバー側の問題を検知し、Synthetics/RUMでクライアント側の問題を検知することで、ユーザー体験の劣化を網羅的に把握できます。

Syntheticsは「ユーザーが到達できるか」を能動的に確認し、RUMは「実際のユーザーが何を体感しているか」を受動的に収集します。この2つの視点を組み合わせることが、フロントエンド可観測性の基本的な設計思想です。

本セクションでは、フロントエンド可観測性の本番課題を整理したうえで、Synthetics/RUMの全体像・既存バックエンド可観測性との違い・本記事全体の構成を説明します。

1-1. フロントエンド可観測性の本番課題

バックエンドのCPU使用率・エラー率・レスポンスタイムがすべて正常であっても、ユーザーが体感する画面表示の速度や操作の快適さが損なわれているケースは珍しくありません。これがフロントエンド可観測性の本質的な課題です。

本番環境で頻発するフロントエンド固有の課題を整理します。

地域・CDNエッジによる品質差

APIサーバーのヘルスチェックは正常でも、特定のCDNエッジポイントのキャッシュ失効やルーティング異常で、日本国内の特定地域やアジアのユーザーにのみ遅延が発生します。バックエンドのメトリクスだけを確認していると、こうした局所的な問題は見逃されます。複数リージョンから実行する合成監視カナリアを使うと、地域別の到達性を継続的に把握できます。

デバイス・ブラウザ環境による体験差

サーバー側のレスポンスタイムが100ms以下であっても、モバイルデバイスの低速回線やメモリ制約下では、JavaScriptの解析・実行やDOMのレンダリングに数秒を要することがあります。開発チームがハイエンド端末でテストしていても、エンドユーザーのミッドレンジ端末や3G回線では全く異なる体験が届いています。実ユーザー監視（RUM）は、こうしたデバイス別・回線別の品質差を実データで把握する手段です。

JavaScriptエラーの局所的発生

特定ブラウザバージョンや特定のユーザー操作フローでのみ再現するJavaScriptエラーは、サーバーのエラーログには記録されません。HTTPステータスは200を返していても、クライアント側でJavaScriptエラーを起こして機能不全な画面が長期間表示されます。RUMのJavaScriptエラー追跡機能は、こうした問題を早期に可視化します。

Core Web Vitalsの継続的な劣化

LCP（最大コンテンツ描画）・CLS（累積レイアウトシフト）・INP（操作応答性）の劣化はGoogleの検索ランキングに直接影響します。これらはクライアント側でのみ計測できる指標であり、サーバーメトリクスでは把握できません。特にINPは2024年にFIDの後継としてCore Web Vitalsの1つとなった指標で、ユーザーのクリック・タップ・キー入力から次の画面更新までの応答時間を計測します。INPのスコアが200ms以上になると「Poor」と判定され、SEOへの影響が出始めます。

サードパーティスクリプトの影響

広告タグ・アクセス解析ツール・チャットウィジェットなど、外部CDNから読み込まれるスクリプトがタイムアウトや読み込み失敗を起こしても、自社バックエンドのメトリクスには現れません。これらはページのレンダリングをブロックするとLCP/INPが劣化し、ユーザーに操作不能な状態をもたらします。RUMのリソースタイミング収集でサードパーティスクリプトの遅延を特定し、async/defer属性の見直しやサードパーティ依存の削減を判断できます。

2025年の新機能がもたらす変化

CloudWatch Synthetics/RUMは2025年に、これらの課題に対応する機能が追加されました。Syntheticsのmulti-checkカナリアでは、1つのカナリアで複数エンドポイント（HTTP/DNS/SSL証明書/TCPポート）を束ねて監視でき、管理コストを削減しながら監視範囲を拡大できます。RUMでは2025年にINP計測が加わりCore Web Vitalsの全指標をカバーできるようになり、モバイルRUM（iOS/Android）によりネイティブアプリの実ユーザー体験も計測対象となりました。

SyntheticsとRUMは、フロントエンドの品質課題に対して異なる角度からアプローチします。合成監視はユーザーの代わりに定期的にアクセスして問題を事前に検知し、実ユーザー監視は実際のユーザー体験を後から集計して実影響を把握します。両者を組み合わせることで、フロントエンド品質の全体像を把握できます。

バックエンド可観測性との協調

Synthetics/RUMはバックエンド可観測性（X-Ray・Application Signals・CloudWatch Logs）と独立して機能しますが、組み合わせることで調査効率が大きく向上します。RUMが捉えたユーザー体感の劣化を起点に、Application SignalsのService Mapで原因サービスを絞り込み、X-Rayのトレースでボトルネックのスパンを特定するドリルダウンが実現します。フロントエンドとバックエンドの可観測性を統合した運用パターンは、本記事の後半のセクションで解説します。

1-2. 読者像

本記事は、AWSのバックエンド可観測性（CloudWatch Logs/X-Ray/Application Signals/AMP+AMG）を既に整備済みで、フロントエンド・デジタルエクスペリエンスの品質監視に課題を感じているエンジニア・SREを主な対象としています。

特に次のような状況で判断が止まる場面の解決を目指します。

• SPAやSSRアプリケーションのバックエンドメトリクスは正常なのに、ユーザーから「遅い」「エラーになる」というクレームが継続している
• 複数のCDNリージョンで配信しており、地域別のフロントエンド品質を一元把握できていない
• iOS/Androidネイティブアプリのユーザー体験をサーバーのエラーログだけで判断しており、画面ロード時間やクラッシュの実態が不明
• Core Web Vitalsの改善を求められているが、INP計測の仕組みから悩んでいる
• Syntheticsカナリアを運用中ですが、設定更新のたびに誤設定リスクがあり、safe updatesを活用した安全な運用への移行を検討している

本記事では、Synthetics/RUMの基礎的なセットアップ・概念の解説は既存記事に委ねます。2025年の新機能と本番環境における実践的な設計判断に集中します。

なお、AWS以外のSaaS型フロントエンド監視ツール（Datadog RUM・New Relic Browser・Dynatrace）との比較は本記事の対象外です。AWSに統一された環境でCloudWatch Synthetics/RUMを活用する方に向けた内容となっています。IAM・VPC・CloudWatchの基本概念は前提知識として扱い、AWSアカウントでの実際の運用経験がある読者を想定しています。

1-3. Synthetics（合成監視）とRUM（実ユーザー監視）の使い分け

SyntheticsとRUMは異なるアプローチでフロントエンド品質を監視します。両者の特性を理解したうえで使い分け・組み合わせることが、効果的なフロントエンド可観測性の設計の出発点となります。

競合関係ではなく、相互補完の関係にあります。

合成監視が先行検知する役割

定期実行のカナリアがエンドポイント異常を検知し、実際のユーザー影響が始まる前にアラートを発報します。深夜のメンテナンス後やリリース直後に特に有効で、ユーザーがサービスを利用していない時間帯でも継続的に監視できます。

実ユーザー監視が実影響を可視化する役割

合成監視がアラートを発報した際に、実際のユーザーへの影響範囲と深刻度を確認するのがRUMです。地域別・デバイス別・ブラウザ別の分布データを使って、対応の優先順位を判断できます。また、合成監視では再現しないサードパーティスクリプトの影響やデバイス固有の問題も、RUMの実データから発見できます。

SLO設計での組み合わせ

Syntheticsの外形チェック成功率（到達性）を可用性SLOの計算に使い、RUMのCore Web Vitals（LCP・INP・CLS）を体感品質SLOに対応付けることで、フロントエンドの品質を二重の指標で定量的に保証します。

実際の障害対応シナリオ

SyntheticsとRUMの使い分けが最も際立つのは、本番障害の対応シーンです。

典型的な対応フローの例を示します。

1. Syntheticsがアラート発報: 深夜2時、東京リージョンのカナリアが特定のAPIエンドポイントで応答タイムアウトを検知し、CloudWatch Alarmがオンコールへ通知します
2. RUMで実影響を確認: オンコール担当がRUMのダッシュボードを確認し、東京および関東のユーザーセッションでエラー率が上昇していることを特定します
3. Application Signalsへドリルダウン: 問題のあるAPIの依存サービスをService Mapで確認し、データベースの接続タイムアウトが原因と判明します
4. 復旧後の確認: Syntheticsカナリアが成功状態に戻り、RUMのエラー率が正常値へ回復したことを確認して対応完了とします

このフローでは、Syntheticsが「何かがおかしい」という能動的な最初の警告を発し、RUMが「どのユーザーが実際に影響を受けているか」という実態を補完します。どちらか一方だけでは得られない情報が、組み合わせによって初めて揃います。

Synthetics/RUMの基礎的なセットアップ・カナリアの概念・SLO統合の設計については、Application Signals SLO本番運用の記事で詳しく解説しています。

2. CloudWatch Synthetics 2025 — multi-checkカナリア × safe updates

CloudWatch Synthetics（合成監視）は2025年に運用効率と安全性を高める機能が追加されました。本セクションでは、multi-checkカナリアとsafe updatesを中心に2025新機能を解説します。基礎的なカナリア概念は既存のApplication Signals SLO記事を参照してください。

2-1. multi-checkカナリア（2025-10）

multi-checkカナリアは、1つのカナリアで最大10種類の監視チェックを束ねられる機能です。2025年10月にリリースされました。従来は複数エンドポイントの監視に対してカナリアを個別に作成する必要がありましたが、multi-checkカナリアによって監視コストと管理オーバーヘッドを大幅に削減できます。

サポートされるチェック種別

multi-checkカナリアは、以下の4種類のチェックを1つのカナリアに混在させられます。

JSON設定によるチェック定義

multi-checkカナリアはJSON設定ファイルでチェック内容を定義します。以下はHTTP・SSL・DNS・TCPの4種類を1つのカナリアに束ねた設定例です。

{
  "checks": [
 {
"type": "HTTP",
"name": "api-health",
"endpoint": "https://api.example.com/health",
"method": "GET",
"expectedStatus": 200,
"timeout": 5000
 },
 {
"type": "SSL",
"name": "ssl-expiry",
"hostname": "api.example.com",
"daysBeforeExpiry": 30
 },
 {
"type": "DNS",
"name": "dns-resolution",
"hostname": "api.example.com"
 },
 {
"type": "TCP",
"name": "tcp-port",
"host": "db.internal.example.com",
"port": 5432
 }
  ]
}

各チェックは独立して合否を判定します。いずれか1つでも失敗するとカナリア全体が失敗ステータスになります。チェック名（name フィールド）はCloudWatchメトリクスのディメンションとして利用されるため、後からダッシュボードやアラートで絞り込めるよう意味のある名前を付けてください。

Secrets Manager連携

APIキーやBasic認証情報など、スクリプトにハードコードしたくない認証情報はSecrets Managerと連携して管理できます。カナリアのJSON設定に secretsManagerArn を指定し、カナリア実行ロールにSecrets Managerの読み取り権限（secretsmanager:GetSecretValue）を付与することで、実行時に動的に取得できます。

認証情報をコードリポジトリへ含めずに運用でき、ローテーションもSecrets Manager側で完結します。マルチリージョン展開の場合は各リージョンのSecrets Managerにシークレットを作成し、カナリアの実行ロールを適切に設定してください。

コスト効率の改善

multi-checkカナリア導入前は、4種類の外形監視を5分間隔で実施する場合に4つのカナリアが必要でした。月間実行回数は4つで合計34,560回（8,640回×4）になります。

multi-checkカナリアで統合すると1つのカナリアで同様の監視が実現できるため、月間実行回数は8,640回に抑えられます。Lambda実行時間の課金も1回分になるため、最大75%のコスト削減効果が期待できます。

ただし、1回の実行で全チェックを直列実行するため、チェック数が増えると実行時間が長くなります。Lambda関数のタイムアウト設定（デフォルト3分・最大15分）を、チェック数と各チェックのタイムアウト設定の合計時間に合わせて適切に調整してください。チェック数が多くタイムアウト超過の懸念がある場合は、チェックを複数のカナリアに分割することを検討してください。

2-2. カナリアsafe updates・自動リトライ（2025-05）

safe updatesは、既存カナリアの定義を本番へ反映する前に安全なテスト実行を挟む機能です。2025年5月にリリースされました。カナリア定義の変更（スクリプト更新・スケジュール変更・ランタイムバージョン更新など）に起因する誤検知や監視の中断を防ぎます。

safe updatesの動作フロー

safe updatesを有効にしたカナリアの更新は、以下の順序で処理されます。

1. コンソール・CLI・IaCでカナリアの変更を指定します
2. Syntheticsが変更内容を一時的なstaging環境で先行実行します
3. stagingの実行が成功した場合のみ本番カナリアへ変更が反映されます
4. stagingの実行が失敗した場合は変更が破棄され、カナリアは従来の定義で稼働を継続します

スクリプトのバグや設定ミスで本番監視が停止するリスクを排除できます。CloudFormationやTerraformで管理するIaC構成でも有効で、パイプライン上でのカナリア定義更新を安全に自動化できます。

自動一時停止と復旧

safe updatesが有効な状態で本番適用が失敗した場合、カナリアは自動的に一時停止（Stopped）状態へ遷移します。「壊れた定義が監視を継続し、誤った正常シグナルを出し続ける」状態を防ぐ設計です。

一時停止後は修正した定義を再投入することで再開できます。停止したカナリアはCloudWatchアラーム（カナリア状態変化）で検知できるため、監視の空白期間が生じる前に気づけます。停止中のカナリアは実行されないため、停止期間中にエラーバジェットを消費しないよう注意してください。

スケジュール失敗時の自動リトライ

スケジュール実行が一時的なネットワーク障害などで失敗した場合、Syntheticsは自動リトライを実行します。リトライ回数（デフォルト2回）と間隔（デフォルト60秒）は設定で調整できます。

自動リトライが特に効果を発揮するシナリオは以下の通りです。

• CloudFrontの一時的な503エラーによる誤検知
• ALBのヘルスチェック猶予期間中のデプロイ後の瞬断
• 外部依存サービスのレート制限や瞬断が原因の失敗

リトライ後も失敗が継続する場合は「継続的失敗」として扱われ、CloudWatchアラームを通じてチームへ通知されます。全リトライが成功した場合はアラームが発生しないため、オンコール対応の負担を減らせます。

IaC管理との組み合わせ

safe updatesはCloudFormationやTerraformによるIaC管理と高い親和性を持ちます。UpdateCanary APIを呼び出す際に SafeUpdatesConfig を設定することで、パイプライン上でカナリアの定義更新を安全に自動化できます。

{
  "SafeUpdatesConfig": {
 "Enabled": true
  }
}

カナリアの定義をGitで管理し、pull requestのマージをトリガーにパイプラインでsafe updatesを実行する構成は、GitOpsとの組み合わせとして効果的です。

2-3. ブループリントと高度なカナリア設計

CloudWatch Syntheticsには標準の監視パターンをすぐに利用できるブループリントが複数用意されています。2025年時点の主要ブループリントと選択基準を整理します。

主要ブループリント

Heartbeat Monitorは最もシンプルなブループリントです。HTTPエンドポイントに定期的にリクエストを送り、ステータスコードとレスポンスタイムを記録します。外形監視の起点として最初に設定することを推奨します。

API Canaryはレスポンスボディのパターンマッチングやヘッダー確認が可能なため、APIの正常性確認に適しています。認証が必要なエンドポイントはSecrets Manager連携でトークンを動的に取得して実行できます。

Broken Link Checkerはページ内リンクを再帰的にたどるため実行時間が長くなりがちです。スケジュール間隔を長め（1時間〜日次）に設定し、Lambda関数のタイムアウトを十分に確保してください。

スケジュール間隔の設計指針

スケジュール間隔の選択は、SLO目標と検知遅延の許容範囲で決まります。可用性SLO 99.9%（月間ダウンタイム上限43分）を設定している場合、1回の未検知が5分を超えるとSLOへの影響が生じます。目標SLOに合わせて以下を参考にしてください。

• 可用性SLO 99.9%以上: 1〜5分間隔
• 可用性SLO 99.5〜99.9%: 5〜15分間隔
• SSL証明書の有効期限監視: 1時間間隔（30日前アラーム設定と組み合わせ）
• リンク切れチェック: 日次〜週次

SLOのエラーバジェット消費速度とカナリア実行コストのバランスを考慮してください。重要なエンドポイントは短い間隔、補助的な確認は長い間隔に設定することでコストを最適化できます。

Lambdaランタイムの選択と更新

カナリアはNode.js・Pythonランタイムで実行されます。AWS推奨の最新ランタイムバージョン（2025年時点ではsyn-nodejs-puppeteer-9.x）を使用してください。古いランタイムバージョンはセキュリティ修正を受けられなくなる場合があります。

ランタイムバージョンの更新にはsafe updatesが有効です。更新後の動作確認をstaging実行で事前に検証してから本番へ反映できるため、ランタイム更新に伴う誤検知のリスクを最小化できます。ランタイムのEOL（サポート終了）日付をAWSのドキュメントで定期的に確認し、計画的な更新スケジュールを組んでください。

3. CloudWatch RUM 2025 — Core Web Vitals(INP) × モバイルRUM

CloudWatch RUM（実ユーザー監視）は2025年にWeb Vitalsの拡充とモバイル対応で大きく進化しました。本セクションでは、INP対応とモバイルRUMを中心に解説します。RUMの基礎セットアップは既存記事を参照してください。

3-1. Core Web VitalsとINP（2025-05）

Core Web Vitalsは、Googleがユーザー体感品質の標準指標として定めた3つのメトリクスです。CloudWatch RUMは2025年5月のアップデートで、FIDに替わる新指標「INP（Interaction to Next Paint）」の計測とパーセンタイル集計に対応しました。

Core Web Vitals 3指標の比較

INP（Interaction to Next Paint）とはなにか

INPはページ内の全インタラクション（クリック・キーボード入力・タップ）に対して、次のフレームが描画されるまでの遅延を計測します。FID（First Input Delay）が「最初の操作の入力処理遅延」だけを見ていたのに対し、INPはページ滞在中のすべての操作を対象とするため、ユーザーが実際に感じる応答性をより正確に反映します。2024年3月にGoogle検索のランキング指標としても採用されており、Web担当者が優先して改善すべき指標となっています。

CloudWatch RUMはRUMアプリケーションモニターで設定されたページごとにINPを自動収集します。コンソールのMetrics画面から「InteractionToNextPaint」ディメンションを選択すると、p50・p75・p95のパーセンタイルが参照できます。

パーセンタイル集計によるINP評価

Google推奨のINP評価はp75（75パーセンタイル）です。100人のユーザーがいたとき、上から75番目の遅い値を指標として採用することで、外れ値の影響を排除しながら広範なユーザー体験を評価できます。CloudWatch RUMのダッシュボードでは、以下のパーセンタイルを確認できます。

• p50：中央値。半数のユーザーがこの値以下を体感している
• p75：Googleのランキング評価基準。200ミリ秒以下を目標とする
• p95：最悪クラスのユーザー体験。500ミリ秒を超えるとfrustratingと判定される

RUMコンソールでは、INPが高いページURLをランキング表示できます。「frustrated」判定が多いページに絞り込み、JavaScriptの長時間タスクやレンダリングブロックを特定するデバッグ起点として活用します。

INP改善のデバッグ手法

INPが高い根本原因を特定するには、以下のアプローチが有効です。

まず、CloudWatch RUMの「Session Detail」から問題のあるセッションを特定します。セッション単位でどのインタラクションがINPに影響しているかを確認できます。次に、ChromeのDevTools「Performance」パネルでLong Tasks（50ミリ秒超のJavaScript処理）を特定します。Long Tasksが操作のイベントハンドラに含まれていると、入力処理が待機状態となりINPが上昇します。

代表的な改善パターンは次のとおりです。

• Long Tasksの分割：scheduler.yield() APIを用いてブラウザのメインスレッドに制御を返す
• イベントハンドラの軽量化：重い処理をWeb WorkerやWeb Assembllyへオフロードする
• React/Vue等のフレームワーク最適化：レンダリングのバッチ処理・仮想化リストの導入
• サードパーティスクリプトの遅延読み込み：defer/async属性やIntersection Observerを活用

CloudWatch RUMでのINP設定と確認手順

RUMアプリケーションモニターを作成または更新する際、JavaScriptスニペット（rum.js）が最新バージョンであることを確認します。INP収集はrum.jsのバージョン1.17以降で有効になります。

// RUM JavaScriptスニペットの例（最小構成）
import { AwsRum } from 'aws-rum-web';

const awsRum = new AwsRum(
  '<APPLICATION_ID>',
  '<APPLICATION_VERSION>',
  '<REGION>',
  {
 sessionSampleRate: 1,
 guestRoleArn: '<COGNITO_GUEST_ROLE_ARN>',
 identityPoolId: '<IDENTITY_POOL_ID>',
 endpoint: 'https://dataplane.rum.<REGION>.amazonaws.com',
 telemetries: ['performance', 'errors', 'http'],
 allowCookies: true,
 enableXRay: true
  }
);

telemetries に 'performance' を含めることで、LCP・CLS・INPが自動収集されます。収集データはCloudWatch Metricsに書き込まれ、カスタムメトリクス WebVitals 名前空間から参照できます。

INPのCloudWatchアラーム設定例

INPのp75値が200ミリ秒（positive閾値）を超えた場合に通知するアラームを設定します。

{
  "AlarmName": "RUM-INP-p75-Degradation",
  "MetricName": "InteractionToNextPaint",
  "Namespace": "AWS/RUM",
  "Statistic": "p75",
  "Period": 300,
  "EvaluationPeriods": 3,
  "Threshold": 200,
  "ComparisonOperator": "GreaterThanThreshold",
  "Dimensions": [
 {"Name": "applicationName", "Value": "<YOUR_APP_NAME>"}
  ]
}

3-2. モバイルRUM iOS/Android（2025-11）

CloudWatch RUMは2025年11月のアップデートで、iOSおよびAndroidのネイティブアプリへの実ユーザー監視を拡張しました。これまでWebアプリ（ブラウザ）のみ対応していたRUMが、モバイルアプリにも展開されたことで、Web/モバイルを横断したデジタルエクスペリエンスの統合監視が可能になりました。

モバイルRUMで計測できる指標

iOSへのSDK統合（CocoaPods）

Podfile に AWS RUM SDKを追加します。

# Podfile
platform :ios, '13.0'

target 'YourApp' do
  use_frameworks!
  pod 'AWSRUMClient', '~> 1.0'
end

pod install の後、AppDelegateまたはSwiftのApp初期化コードでRUMクライアントを設定します。

import AWSRUMClient

@main
struct YourApp: App {
 init() {
  let config = AWSRUMClientConfig(
appMonitorName: "<MONITOR_NAME>",
appMonitorVersion: "1.0.0",
region: "ap-northeast-1",
identityPoolId: "<IDENTITY_POOL_ID>",
guestRoleArn: "<GUEST_ROLE_ARN>"
  )
  AWSRUMClient.initialize(configuration: config)
 }

 var body: some Scene {
  WindowGroup { ContentView() }
 }
}

初期化後は、画面遷移・ネットワークリクエスト・クラッシュ・AppHangが自動的に収集されます。カスタムイベントを記録したい場合は AWSRUMClient.shared().recordEvent(name:attributes:) を呼び出します。

AndroidへのSDK統合（Gradle）

build.gradle (Module: app) に依存関係を追加します。

// build.gradle
dependencies {
 implementation 'com.amazonaws:aws-android-sdk-rum:2.+'
}

Applicationクラスの onCreate() でSDKを初期化します。

class MyApplication : Application() {
 override fun onCreate() {
  super.onCreate()

  val config = AWSRumConfig.Builder()
.appMonitorName("<MONITOR_NAME>")
.appVersion("1.0.0")
.region("ap-northeast-1")
.identityPoolId("<IDENTITY_POOL_ID>")
.guestRoleArn("<GUEST_ROLE_ARN>")
.build()

  AWSRum.initialize(this, config)
 }
}

Android SDKは画面ロード時間・クラッシュ・ANR・HTTPリクエストを自動収集します。Activity/Fragmentの遷移は ActivityLifecycleCallbacks を通じて自動計装されます。

モバイルRUMの活用例：ANRの特定と対処

ANR（Application Not Responding）はAndroidのシステムがアプリに対してメインスレッドが5秒以上応答していないと判断した場合に発生します。RUMのANR計測は以下のワークフローで活用できます。

1. RUMダッシュボードでANR発生率の高いスクリーン名を特定する
2. ANRが多い時間帯・デバイス・Androidバージョンを絞り込む
3. CloudWatch Logsに送信されたANRのスタックトレースを確認する
4. 該当スクリーンのonCreate/onResume等でブロッキング処理（DBアクセス・ネットワーク呼び出し）が実行されていないか確認する
5. 処理をCoroutinesのIOディスパッチャーやWorkManagerに移動して改善する

3-3. セッション分析とJSエラー追跡

セッション単位の体感品質分析

CloudWatch RUMはユーザーセッションを単位として体感品質を記録します。セッションとは、ユーザーがアプリを開いてから30分間無操作または閉じるまでの一連の操作です。RUMコンソールの「Sessions」タブでは、以下の情報を確認できます。

• セッションID・開始時刻・継続時間・ページビュー数
• 地域・デバイス種別（デスクトップ/モバイル/タブレット）・ブラウザ名
• セッション内で発生したCore Web Vitalsの値（LCP/CLS/INP）
• HTTPエラー・JavaScriptエラーの発生タイミング

特定のセッションを選択すると「Session Detail」ページが開き、ユーザーが辿ったページ遷移タイムラインを時系列で確認できます。どのページでINPが悪化したか・どのAPIコールで503エラーが発生したかを文脈とともに把握できるため、再現しにくいパフォーマンス問題の調査に有効です。

JavaScriptエラー追跡

RUMスニペットの telemetries に 'errors' を含めることで、ページ内で発生した未処理のJavaScript例外が自動収集されます。収集される情報は次のとおりです。

• エラーメッセージ（Error.message）
• スタックトレース（ソースマップ適用済みの場合は元ファイル・行番号）
• 発生URL・ユーザーエージェント・タイムスタンプ
• 同じエラーのセッション内発生回数

RUMコンソールの「Errors」タブでは、エラーを件数・URL・エラータイプ別に集計したビューが利用できます。新規デプロイ後にエラーが急増していないかを確認するウォッチポイントとして活用します。

ユーザージャーニーの可視化

RUMの「User journeys」機能では、ページ間のフロー（どのページからどのページへ遷移したか）をサンキー図で可視化します。コンバージョン率の低いページや離脱率の高いページを特定し、UX改善の優先度判断に活用できます。

フロントエンドエラーが多発しているセッションに絞り込む場合は、「Filter by errors」でフィルタリングし、エラーが発生するユーザージャーニーのパターンを確認します。エラーが特定の遷移パスに集中している場合、そのルート固有のJavaScriptバグが疑われます。

4. SLO・アラート設計 — Application Signals統合

合成監視と実ユーザー監視のメトリクスは、SLOとして目標化することで運用判断に直結します。本セクションでは、Application Signals統合とSLO・アラート設計を解説します。

4-1. Application Signalsへの集約

Syntheticsカナリアは実行結果を AWS/CloudWatchSynthetics 名前空間にメトリクスとして出力します。Application Signalsはこれらを統合し、サービスレベルのSLO定義・サービスマップ表示・依存関係の可視化を一元的に提供します。

Syntheticsカナリアのメトリクス集約

カナリアが生成する主要メトリクスは以下のとおりです。

Application Signalsにカナリアのサービスを登録するには、カナリア設定でApplication Signalsとの統合を有効化します。コンソールの「Synthetics」→「カナリア」→「カナリア名」→「Application Signals設定」から、対象サービスエントリを指定します。統合後、Application Signalsのサービスマップ上にカナリアが外形監視ノードとして表示され、実際のサービス依存グラフと並べて確認できます。

RUMのメトリクス集約

RUMは AWS/RUM 名前空間にWebメトリクスを出力します。Application SignalsへのRUM統合は、RUMアプリモニター設定の「Application Signals」欄でサービス名を指定します。

RUMが集約する主要メトリクスは以下のとおりです。

統合後のApplication Signalsダッシュボードでは、Syntheticsが検知した外形的な到達不能と、RUMが示す実ユーザーの体感劣化を同一画面で比較できます。「外形監視は正常でも実ユーザーのLCPが悪化している」という状況を即座に把握できます。

サービス依存関係の可視化

Application Signalsのサービスマップは、フロントエンドからバックエンドAPIへの依存関係を自動検出します。RUMが計測したAPIコール成功率をマップ上に重ね合わせることで、どのバックエンドサービスがフロントエンド体感に影響しているかを特定できます。

サービスマップ表示はX-Rayトレースと連携します。RUMがブラウザ側でトレースIDを生成し、バックエンドAPIへのリクエストヘッダに付与することで、フロントエンドからバックエンドまでのエンドツーエンドトレースが実現します。この設定はRUMアプリモニターの「X-Rayトレース」有効化によって適用できます。

統合設定の留意点

RUMとSyntheticsのメトリクスをApplication Signalsに集約する際は、サービス名の統一が重要です。サービス名が不一致の場合、Syntheticsの可用性データとRUMの体感データが別サービスとして表示されます。コンソールまたはCloudFormationでサービス名を明示的に指定し、両者を同じサービスエントリに紐付けます。

Application Signalsには評価期間（Rolling window）の設定があります。SLO計算に使う期間として28日・7日・1日が選択でき、長期トレンドと直近の品質悪化の両方を監視できます。フロントエンドのSLOは通常28日窓で安定性を評価し、アラートは短期窓で素早く検知するという使い分けが有効です。

4-2. フロントエンドSLOとBurn Rateアラート

フロントエンドのSLOは大きく「可用性SLO」と「パフォーマンスSLO」の2種類に分けて定義します。可用性SLOはカナリアの成功率を基準とし、パフォーマンスSLOはCore Web Vitalsの目標値との比較で評価します。

可用性SLOの設計

カナリアを用いた可用性SLOは、一定期間内での成功率目標として定義します。一般的な設計例は以下のとおりです。

Application SignalsでSLOを作成する手順は以下のとおりです。

1. Application Signalsコンソール→「SLOs」→「SLO作成」
2. サービスを選択（カナリア統合済みのサービス名）
3. SLI（指標）に SuccessPercent を選択
4. 目標値（例: 99.9%）と評価期間（28日）を設定
5. アラートポリシーとして通知先SNSトピックを設定

パフォーマンスSLOの設計

Core Web VitalsによるパフォーマンスSLOは、Googleが定義する「Good」閾値を基準として設定します。

Application SignalsのパフォーマンスSLOは、Good状態にあるセッションの比率を目標として定義します。例えば「LCPがGood（≤2.5秒）であるセッション比率を75%以上に保つ」という形式です。

Burn Rate Alarmの設定

エラーバジェットの消費速度（Burn Rate）に基づくアラームは、SLO達成期間の終わりより大幅に早い段階で問題を検知するために有効です。Application SignalsはBurn Rate Alarmを自動生成しますが、手動設定する場合の基本方針は以下のとおりです。

一般的に採用される2段階アラームの構成は以下のとおりです。

SNS・PagerDutyへの通知連携

Burn Rate Alarmの通知先として、SNSトピックを経由してPagerDuty・Slackへ転送できます。

# CloudFormation例（Burn Rateアラーム）
BurnRateAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
 AlarmName: frontend-slo-burnrate-critical
 Namespace: AWS/CloudWatchSynthetics
 MetricName: SuccessPercent
 Threshold: 99.9
 ComparisonOperator: LessThanThreshold
 EvaluationPeriods: 5
 DatapointsToAlarm: 3
 AlarmActions:
- !Ref AlertSNSTopic
 OKActions:
- !Ref AlertSNSTopic

RUMのWebVitals劣化検知アラーム

RUMのCore Web Vitalsアラームは、AWS/RUM 名前空間のメトリクスを対象に設定します。LCPの劣化検知アラームの設定例は以下のとおりです。

aws cloudwatch put-metric-alarm \
  --alarm-name rum-lcp-degradation \
  --namespace AWS/RUM \
  --metric-name LargestContentfulPaintAllPages \
  --dimensions Name=AppMonitorName,Value=MyAppMonitor \
  --threshold 4.0 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2 \
  --period 300 \
  --statistic p75 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:frontend-alert

パーセンタイル集計（p75・p95）を使うことで、一部のユーザーが体験している悪化を、平均値では見えにくい状況でも検知できます。

エラーバジェット管理

エラーバジェットは「SLO期間内にどれだけの失敗を許容できるか」を定量化したものです。

• 99.9% SLO・28日期間の場合: 許容ダウンタイム = 28 × 24 × 60 × (1 – 0.999) ≈ 約40分
• バジェット残量を週次でレビューし、残量が50%を切った段階でリリースペースを落とす判断が有効です
• Application SignalsのSLOレポートでバジェット消費グラフを確認できます

4-3. ダッシュボード設計

Synthetics/RUM統合のダッシュボードは、「フロントエンド全体健全性の一覧」「個別ページ・エンドポイントのドリルダウン」「地域・デバイス別のセグメント分析」という3層構成が実践的です。

統合ダッシュボードの構成

CloudWatch Dashboardでウィジェットを配置する際は、JSONソースを直接編集することで複数メトリクスの重ね合わせや算術演算を表現できます。

地域別・デバイス別セグメント

RUMはJavaScript SDKが収集したユーザー属性に基づき、地域・ブラウザ・デバイスタイプ別のセグメントを提供します。ダッシュボードに地域別フィルターウィジェットを追加することで、特定リージョンでの体感劣化を素早く特定できます。

地域別ビューの実装には、RUMコンソールの「エクスプローラー」機能を活用します。エクスプローラーで絞り込んだクエリをダッシュボードに固定表示することで、定常的な地域別監視が実現します。

{
  "type": "explorer",
  "properties": {
 "metrics": [
["AWS/RUM", "LargestContentfulPaintAllPages",
 "AppMonitorName", "MyAppMonitor"]
 ],
 "labels": [{"key": "CountryCode", "value": "JP"}],
 "period": 300,
 "title": "日本ユーザーのLCP"
  }
}

デバイス別分析では、RUMが収集するUser-Agent情報からデスクトップ・スマートフォン・タブレットを自動分類します。スマートフォンのLCPがデスクトップより著しく劣化している場合は、画像最適化やフォント読み込みの改善が効果的です。

経営層向けサマリビュー

技術指標を経営層が理解しやすい形式で提示するには、「可用性%」「ページ表示の体感評価（Good率%）」という2指標への集約が有効です。

CloudWatch DashboardのTextウィジェットにMarkdownで補足説明を追加し、週次・月次のスナップショットをPDF出力する運用が採用されています。SLOレポートのページ（Application Signals→SLOs→レポート）からCSVエクスポートも可能で、データウェアハウスへの取り込みやExcelレポートへの貼り付けに活用できます。

アラート統合設計のまとめ

SLO・アラート設計において重要なのは、「閾値の羅列」ではなく「誰がどのアラームを受け取り何を確認するか」というオーナーシップ設計です。

アラート数が多すぎるとアラート疲れ（Alert Fatigue）が発生し、重要な通知が見逃されます。初期段階ではP1・P2の2段階だけ設定し、運用しながら閾値を調整するアプローチを推奨します。

5. CI/CD連携・運用 — カナリアパイプライン統合

カナリアをCI/CDパイプラインに組み込むことで、フロントエンド品質を継続的に保証できます。本セクションでは、カナリアのパイプライン統合とsafe updates運用を解説します。

5-1. デプロイパイプラインへのカナリア統合

SyntheticsカナリアをCI/CDパイプラインの「デプロイゲート」として機能させることで、フロントエンドの外形監視をリリースプロセスに組み込めます。本サブセクションではCodePipelineとGitHub Actionsの代表的な統合パターンを解説します。

CodePipelineへのカナリア統合パターン

CodePipelineでは、Invokeアクション（AWS Lambda呼び出し）を使ってSyntheticsカナリアの実行と結果取得をパイプラインに組み込みます。カナリアはデプロイステージの前後に配置し、終了ステータスがSUCCEEDED以外であればパイプラインを自動停止します。

代表的なパイプライン構成は以下の通りです。

1. Source（CodeCommit/S3/GitHub）
2. Build（CodeBuild — フロントエンドビルドとステージング環境へのデプロイ）
3. Canary_Staging（Invokeアクション — ステージングに対してカナリアを実行）
4. ManualApproval（オプション — 承認ゲート）
5. Deploy_Production（本番デプロイ）
6. Canary_Production（本番デプロイ後のカナリア実行）

カナリアを起動するLambda関数の実装例を示します。

import boto3
import time

def lambda_handler(event, context):
 client = boto3.client('synthetics')
 canary_name = event.get('canary_name', 'frontend-health-canary')

 client.start_canary(Name=canary_name)

 for _ in range(30):
  time.sleep(10)
  runs = client.get_canary_runs(Name=canary_name, MaxResults=1)
  if runs['CanaryRuns']:
run_status = runs['CanaryRuns'][0]['Status']['State']
if run_status == 'PASSED':
 return {'status': 'SUCCEEDED', 'canary': canary_name}
elif run_status == 'FAILED':
 raise Exception(f'Canary {canary_name} failed')

 raise Exception('Canary execution timed out')

このLambda関数をCodePipelineのInvokeアクションに指定することで、失敗時はパイプラインが自動停止します。外形監視を通過した変更のみが本番環境へ到達する仕組みが整います。

GitHub Actionsへのカナリア統合パターン

GitHub ActionsのCI/CDワークフローでは、AWS CLIとSynthetics APIを組み合わせてカナリアを実行します。ステージングデプロイ後と本番デプロイ後の2箇所に検証ステップを挿入するのが基本パターンです。

jobs:
  deploy-and-verify:
 runs-on: ubuntu-latest
 steps:
- name: Deploy to staging
  run: |
 aws s3 sync ./dist s3://$STAGING_BUCKET
 aws cloudfront create-invalidation \
--distribution-id $STAGING_CF_ID --paths '/*'

- name: Wait for CloudFront propagation
  run: sleep 30

- name: Run canary on staging
  id: canary-staging
  run: |
 aws synthetics start-canary --name frontend-staging-canary
 for i in $(seq 1 18); do
sleep 10
RESULT=$(aws synthetics get-canary-runs \
  --name frontend-staging-canary \
  --max-results 1 \
  --query 'CanaryRuns[0].Status.State' \
  --output text)
if [ "$RESULT" = "PASSED" ]; then exit 0; fi
if [ "$RESULT" = "FAILED" ]; then exit 1; fi
 done
 exit 1

- name: Deploy to production
  if: success()
  run: |
 aws s3 sync ./dist s3://$PRODUCTION_BUCKET
 aws cloudfront create-invalidation \
--distribution-id $PROD_CF_ID --paths '/*'

if: success() の指定により、前のステップが成功した場合のみ本番デプロイが実行されます。カナリアが失敗した時点でワークフローは停止し、本番環境への変更は届きません。

リリース前後の外形監視実行フロー

運用上の推奨は、デプロイ前・直後・一定時間後の3点でカナリアを実行することです。

• デプロイ前（Pre-deploy）: 現在の本番状態をベースラインとして記録し、問題なしを確認します
• デプロイ直後（Post-deploy）: デプロイした変更でエンドポイントが正常に応答するかを即座に検証します
• デプロイ10〜15分後（Stabilization）: キャッシュ反映・DNS伝播後の安定性を確認します

三点計測により、デプロイ起因の劣化を即座に検知できます。特にCloudFrontを挟む構成では、キャッシュ無効化の完了を待ってからPost-deployカナリアを実行することが重要です。

失敗時のロールバック自動化

パイプライン内のカナリアが失敗した場合、前のデプロイバージョンへの自動ロールバックを組み込めます。

- name: Rollback on canary failure
  if: failure() && steps.canary-staging.outcome == 'failure'
  run: |
 echo "Canary failed — rolling back"
 PREVIOUS_VERSION=$(aws s3api list-object-versions \
--bucket $PRODUCTION_BUCKET \
--query 'Versions[?IsLatest==\`false\`] | [0].VersionId' \
--output text)
 aws s3api restore-object \
--bucket $PRODUCTION_BUCKET \
--version-id "$PREVIOUS_VERSION"
 aws cloudfront create-invalidation \
--distribution-id $PROD_CF_ID --paths '/*'

S3バージョニングと組み合わせることで、ロールバック対象バージョンを明示的に指定できます。ECSやLambdaへのデプロイであれば、CodeDeployのBlue/Greenロールバック機能と組み合わせるのが効率的です。

段階デプロイとSyntheticsの統合

Blue/Greenデプロイ中にSyntheticsカナリアを活用することで、Greenスタックのフロントエンド品質を切り替え前に検証できます。CodeDeployのフック（BeforeAllowTraffic/AfterAllowTraffic）にカナリア実行Lambdaを組み込む構成が代表的です。

• BeforeAllowTrafficフック: Greenスタックのエンドポイントに対してカナリアを実行します
• 失敗時: デプロイを自動ロールバックし、Blueスタックを維持します
• 成功時: AllowTrafficの実行後、トラフィックがGreenへ切り替わります
• AfterAllowTrafficフック: 切り替え後の本番カナリアで最終確認します

カナリアリリース（段階的トラフィック移行）の場合は、各ステップ後にSyntheticsカナリアを実行し、エラー率・レスポンスタイムが閾値内であることを確認してから次のステップへ進むフローを組み込みます。

5-2. safe updatesによる安全なカナリア更新運用

カナリアを長期運用すると、ランタイムバージョン・監視ロジック・スクリプトの更新が発生します。このカナリア自体の更新にsafe updatesを適用することで、誤ったカナリア定義が本番監視に紛れ込むリスクを低減できます。

safe updatesの仕組みと動作

safe updatesはSyntheticsのカナリア定義を更新する際に以下の保護を提供します。

1. 更新後の定義でテスト実行を行います（本番適用前に1回テストラン）
2. テスト実行が失敗した場合、更新を自動的に一時停止し既存定義を維持します
3. テスト実行が成功した場合のみ、更新内容が本番スケジュールに適用されます

この挙動により「スクリプトの文法エラー」「依存ライブラリの削除」「エンドポイントURL変更ミス」といった単純なミスでカナリアが停止することを防ぎます。従来はカナリアのランタイム更新が即座に本番反映されていたため、誤ったスクリプトも動き続けるリスクがありました。safe updatesによってこのリスクを解消できます。

IaC（CloudFormation/Terraform）での管理

カナリアをIaCで管理することで、定義変更の履歴追跡とレビュープロセスを組み込めます。

CloudFormationでのカナリア定義例を示します。

FrontendHealthCanary:
  Type: AWS::Synthetics::Canary
  Properties:
 Name: frontend-health-canary
 RuntimeVersion: syn-nodejs-puppeteer-9.0
 Schedule:
Expression: rate(5 minutes)
 Code:
Handler: pageLoadBlueprint.handler
S3Bucket: !Ref CanaryCodeBucket
S3Key: canary-scripts/frontend-health.zip
 ExecutionRoleArn: !GetAtt CanaryExecutionRole.Arn
 SuccessRetentionPeriod: 31
 FailureRetentionPeriod: 31
 Tags:
- Key: Environment
  Value: production
- Key: ManagedBy
  Value: CloudFormation

CloudFormationスタック更新時にsafe updatesが自動で発動し、テスト通過後に本番カナリアへ反映します。

Terraformを使う場合の定義例を示します。

resource "aws_synthetics_canary" "frontend_health" {
  name  = "frontend-health-canary"
  artifact_s3_location = "s3://${aws_s3_bucket.canary_artifacts.bucket}/artifacts/"
  execution_role_arn= aws_iam_role.canary_execution.arn
  handler  = "pageLoadBlueprint.handler"
  runtime_version= "syn-nodejs-puppeteer-9.0"

  schedule {
 expression = "rate(5 minutes)"
  }

  s3_bucket = aws_s3_bucket.canary_code.bucket
  s3_key = "canary-scripts/frontend-health.zip"

  success_retention_period = 31
  failure_retention_period = 31

  tags = {
 Environment = "production"
 ManagedBy= "Terraform"
  }
}

success_retention_period と failure_retention_period はアーティファクトの保持日数です。運用コストと調査ニーズのバランスで31〜90日を設定します。

バージョン管理とレビュープロセス

カナリアスクリプト（Node.js/Pythonファイル）はGitリポジトリで管理し、プルリクエストレビューを経てからIaCを更新します。推奨フローは以下の通りです。

1. カナリアスクリプトの修正 → プルリクエスト作成
2. レビューとテスト環境でのカナリアスクリプト動作確認
3. マージ後、CI/CDパイプラインが自動的にS3へスクリプトをアップロード
4. IaC（CloudFormation/Terraform）の更新を適用
5. safe updatesによるテスト実行 → 成功で本番反映、失敗でアラート通知

この運用により、カナリア定義の変更を通常のコード変更と同等のレビュー水準で管理できます。スクリプトのZipアーカイブをCI/CDで自動生成してS3へ配置する構成にすると、手動アップロードによるバージョン混在を防げます。

5-3. 運用の自動化

カナリアパイプラインを本番運用として継続するには、失敗通知・棚卸し・コスト最適化の自動化が不可欠です。

EventBridgeによる失敗通知

SyntheticsカナリアはCloudWatchメトリクスとしてSuccessPercent・FailedCount・Durationを発行します。CloudWatchアラームとEventBridgeルールを組み合わせることで、失敗時の通知を自動化できます。

カナリア失敗アラームのCloudFormation定義例を示します。

CanaryFailureAlarm:
  Type: AWS::CloudWatch::Alarm
  Properties:
 AlarmName: !Sub '${FrontendHealthCanary}-failure'
 AlarmDescription: 'Synthetics canary failure detected'
 MetricName: FailedCount
 Namespace: CloudWatchSynthetics
 Statistic: Sum
 Period: 300
 EvaluationPeriods: 1
 Threshold: 1
 ComparisonOperator: GreaterThanOrEqualToThreshold
 Dimensions:
- Name: CanaryName
  Value: frontend-health-canary
 AlarmActions:
- !Ref AlertSNSTopic
 TreatMissingData: notBreaching

EventBridgeルールで synthetics:CanaryStatusChanged イベントをキャッチし、失敗時にSlack Webhook呼び出しLambdaをトリガーするパターンも広く使われます。

{
  "source": ["aws.synthetics"],
  "detail-type": ["CloudWatch Synthetics Canary Status Change"],
  "detail": {
 "canary-name": ["frontend-health-canary"],
 "new-status": ["ALARM"]
  }
}

このルールに対してSlack通知Lambdaをターゲットとして設定し、失敗内容（スクリーンショットのS3 URL・エラーメッセージ）を通知本文に含めると、現場対応が迅速になります。

カナリアの棚卸しと最適化

本番環境で長期運用していると、不要なカナリアや実行コストの高いカナリアが蓄積します。月次の棚卸しでは以下を確認します。

• SuccessPercentが90%未満でアラートも上がっていないカナリア（誤検知が多く無視されているもの）
• Durationが閾値（例：30秒）を常に超えているカナリア（タイムアウトリスクあり）
• 対象エンドポイントが廃止・移動したカナリア
• 実行間隔が5分以下で大量のアーティファクトを蓄積しているカナリア

棚卸し用のAWS CLIコマンドを示します。

# 全カナリアの最終実行結果を一覧表示
aws synthetics describe-canaries \
  --query 'Canaries[*].{Name:Name,Status:Status.State,Success:Statistics.SuccessPercent}' \
  --output table

# SuccessPercentが低いカナリアをフィルタ
aws synthetics describe-canaries \
  --query 'Canaries[?Statistics.SuccessPercent < \`90\`].[Name,Statistics.SuccessPercent]' \
  --output table

不要なカナリアを定期的に削除することで、Synthetics実行課金とS3アーティファクトのストレージコストを最適化できます。

エンドツーエンド可観測性パイプラインとしての活用

CI/CDパイプラインにカナリアとRUMを組み込んだエンドツーエンドのフローは以下の通りです。

1. コードコミット → パイプライン起動
2. ビルド → ステージング環境へデプロイ
3. Syntheticsカナリア（ステージング）→ エンドポイント到達性と応答時間を検証
4. 本番デプロイ → CloudFrontキャッシュ無効化
5. Syntheticsカナリア（本番・デプロイ直後）→ 本番外形監視を即実行
6. RUMダッシュボード → 実ユーザーへのINP・LCP影響を5〜10分後に確認
7. SLOバーンレート → デプロイ起因のエラーバジェット消費を検知

このフローにより、「カナリアが通っても実ユーザー体感が悪化する」ケースをRUMで補完し、SLOバーンレートで早期検知できます。パイプラインの最終段階でSLOステータスを確認するステップを追加することで、より堅牢なリリース品質保証が実現します。

6. セキュリティ・コスト

Synthetics/RUMは外形監視と実ユーザーデータを扱うため、セキュリティとコストの設計が運用品質を左右します。本セクションでは、IAM・データプライバシー・コスト構造を解説します。

6-1. IAMとデータプライバシー

Synthetics実行ロールの最小権限設計

CloudWatch Syntheticsのカナリアは、実行時にIAMロールを使用してAWSリソースへアクセスします。最小権限の原則を守るため、カナリアの実行ロールには必要最小限の権限のみを付与します。

基本的なカナリア実行ロールに必要な権限の構成です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": ["s3:PutObject", "s3:GetObject"],
"Resource": "arn:aws:s3:::canary-results-bucket/*"
 },
 {
"Effect": "Allow",
"Action": ["cloudwatch:PutMetricData"],
"Resource": "*",
"Condition": {
  "StringEquals": {"cloudwatch:namespace": "CloudWatchSynthetics"}
}
 },
 {
"Effect": "Allow",
"Action": [
  "logs:CreateLogGroup",
  "logs:CreateLogStream",
  "logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:log-group:/aws/lambda/cwsyn-*"
 }
  ]
}

カナリアがSecrets Managerで管理するAPIキーやパスワードを参照する場合は、特定のシークレットARNへのsecretsmanager:GetSecretValue権限のみを追加します。ワイルドカードでシークレット全体へのアクセスを許可せず、カナリアが使用するシークレットのみを明示的に指定してください。

RUM AppMonitorのIAM権限設計

RUMのデータを送信するには、ブラウザやモバイルアプリからAWSのrum:PutRumEvents APIを呼び出す権限が必要です。この権限は、aws-rum-webクライアントライブラリが取得する一時的な認証情報（CognitoのIdentity Pool経由）によって付与されます。

AppMonitorに関連付けるCognitoの未認証IDロールには、次の権限のみを許可します。

{
  "Effect": "Allow",
  "Action": "rum:PutRumEvents",
  "Resource": "arn:aws:rum:ap-northeast-1:ACCOUNT_ID:appmonitor/YOUR-MONITOR-NAME"
}

AppMonitor ARNをリソースで明示することで、意図しないモニターへのデータ送信を防ぎます。ワイルドカード（*）でリソースを指定すると、同一AWSアカウント内の全AppMonitorへの書き込みが可能になるため、本番環境では避けます。

RUMによるユーザーデータの収集とプライバシー設計

RUMはユーザーのブラウザセッションデータを収集するため、個人情報保護の観点から適切な設計が必要です。RUMのデータ収集でプライバシーに関わる主な項目を確認します。

• URLのクエリパラメータ: URLに含まれるユーザーIDや検索キーワードは記録の対象となる場合があります。機密性の高いパラメータを含むURLはパターンで除外します
• HTTPリクエスト: デフォルトではリクエストURLのみを記録します。カスタムヘッダーや認証トークンが含まれる場合は収集を無効化します
• ユーザー操作: クリック・スクロール等のインタラクションイベントが収集されます

マスキング設定の例（RUM JavaScriptクライアント）です。

new AwsRum(applicationId, applicationVersion, applicationRegion, {
  // 機密情報を含むURLパターンを除外
  urlsToExclude: [/\/api\/auth\/.*/, /\/profile\/.*\/private/],
  // リソースリクエスト詳細の収集を無効化
  recordResourceRequests: false,
  // 収集するセッションの割合（50%のサンプリング）
  sessionSampleRate: 0.5
});

GDPRやPIPA等の法的要件に対応するには、ユーザーの同意後にのみRUMデータの収集を開始する設計が求められます。コンセント管理プラットフォーム（CMP）と連携し、同意を得た場合のみAwsRumを初期化するパターンが一般的です。

ネットワークセキュリティ — カナリアのVPC内実行

カナリアをVPC内で実行することで、パブリックインターネットを経由しない安全な監視が可能になります。内部API・プライベートエンドポイントへのアクセスも可能になります。

VPC内カナリアの設計で考慮すべき点です。

• サブネット選択: カナリア実行はプライベートサブネットを使います。S3/CloudWatch/Secrets ManagerへのアウトバウンドはNATゲートウェイまたはVPCエンドポイント経由で確保します
• VPCエンドポイントの活用: インターネット経由をなくすため、次のVPCエンドポイントを設定します
• com.amazonaws.{region}.monitoring（CloudWatch）
• com.amazonaws.{region}.logs（CloudWatch Logs）
• com.amazonaws.{region}.s3（アーティファクト保存）
• com.amazonaws.{region}.secretsmanager（シークレット参照）

CloudTrailによるカナリア操作の監査

カナリアの作成・更新・削除・起動・停止はすべてAWS CloudTrailに記録されます。本番環境では、CloudTrailを有効にしてS3バケットへ保存し、操作ログを長期保持することでセキュリティ監査・コンプライアンス要件を満たします。

特に重要な監査対象イベントです。

• synthetics:CreateCanary: カナリアの新規作成
• synthetics:UpdateCanary: カナリアの設定変更（safe updates含む）
• synthetics:DeleteCanary: カナリアの削除
• synthetics:StartCanary / synthetics:StopCanary: カナリアの手動起動・停止

予期しないカナリア変更を即座に把握するため、CloudWatch Alarmでこれらのイベントに対するアラートを設定します。停止イベントが夜間に発生した場合など、不審な操作を早期に把握できます。

6-2. コスト構造

Syntheticsのコスト構造

CloudWatch Syntheticsのコストは主にカナリア実行回数に基づいて課金されます。1回の実行に対して固定の課金が発生し、実行時間（カナリアが消費するコンピューティングリソース）にも別途課金があります。

multi-checkカナリア（2025年新機能）のコスト効率が特に注目されます。1カナリアで最大10チェックを束ねた場合でも、実行は1回分の課金です。個別に10カナリアを作成した場合と比較して、最大1/10のコストで同等の監視範囲をカバーできます。

代表的なコスト試算（月間）の目安です。

監視の重要度に応じて実行間隔を調整することが、コスト最適化の基本です。クリティカルなエンドポイントは1〜5分間隔、非クリティカルなものは15〜30分間隔に設定することで、合計コストを抑制できます。

SSL証明書の有効期限監視やリンク切れチェックなど、リアルタイム性が不要なチェックは1時間〜日次間隔に設定することで、頻繁な実行を避けられます。

RUMのコスト構造

RUMはユーザーセッション数・イベント数に基づいて課金されます。

• セッション単位の課金: ユーザーがRUMを有効化したページを訪れると1セッションとしてカウントされます
• イベント単位の課金: ページビュー・JavaScriptエラー・HTTPリクエスト・Core Web Vitalsなどの各イベントが課金対象になります

トラフィックが多いサービスでは、サンプリングレートを調整することでコストを大幅に削減できます。

ポーリング間隔の最適化

RUMはセッション中に定期的にデータをAWSへ送信します。ポーリング間隔を適切に設定することで、APIコール数を削減してコストを最適化できます。ユーザーがページを離脱する前にデータが確実に送信されるよう、セッション終了時のバッチ送信設定も確認します。

6-3. データ保持と最適化

CloudWatch Logsの保持期間設定

RUMとSyntheticsが生成するCloudWatch Logsのデータには、デフォルトでは無期限保持が設定されています。保持期間を設定しないと、ログデータが蓄積してコストが増加し続けます。次のロググループに対して適切な保持期間を設定します。

• /aws/lambda/cwsyn-{カナリア名}: Syntheticsカナリアの実行ログ（推奨: 30〜90日）
• /aws/rum/{AppMonitorID}: RUMの詳細ログ（推奨: 30日）

保持期間はAWSコンソール・CLI・CloudFormationで設定できます。大量のカナリアを運用している場合は、AWS CLIのスクリプトで一括設定することを推奨します。

S3アーティファクトのライフサイクル管理

Syntheticsのカナリアは実行のたびにスクリーンショット・HARファイル・ログをS3バケットへ保存します。アーティファクトが蓄積するとS3のコストが増加するため、S3ライフサイクルポリシーを設定します。

推奨のS3ライフサイクル設定です。

• 作成から30日後: Standard → Intelligent-Tieringへ移行
• 作成から90日後: Intelligent-Tiering → Glacier Instant Retrievalへ移行
• 作成から180日後: 削除（コンプライアンス要件に応じて調整）

サンプリング設計の最適化

RUMのサンプリングレートは、sessionSampleRateパラメータで0〜1の範囲で指定します。

new AwsRum(applicationId, applicationVersion, applicationRegion, {
  // 10%のサンプリング（月間PVが多い場合の推奨スタート）
  sessionSampleRate: 0.1
});

サンプリングレートは次の観点で設計します。

• 統計的有意性: Core Web VitalsのP75パーセンタイルを正確に計算するためには、最低でも月間数千セッションのデータが必要です
• コストとのバランス: 月間PV100万以上のサービスでは10〜20%のサンプリングでも十分なデータ量が確保できます
• 新機能リリース時の一時的引き上げ: 新機能のリリース直後は一時的にサンプリングレートを上げて詳細なデータを収集し、安定後に下げます

不要カナリアの定期棚卸し

廃止されたエンドポイントに対するカナリアは停止・削除します。停止状態のカナリアも定義が残っている限り管理コストが発生します。カナリアの棚卸しは四半期ごとに実施し、不要なカナリアをsynthetics:DeleteCanary APIで削除します。

IaCで管理している場合は、CloudFormation/TerraformのスタックからもカナリアリソースのDefinitionを削除してドリフトを防ぎます。棚卸し作業をAWS Configルールと組み合わせて自動化し、長期間未実行・停止状態のカナリアをレポートする仕組みを構築するとメンテナンス負荷を継続的に抑制できます。

7. 実戦統合パターン — バックエンド可観測性との統合

フロントエンドの異常をバックエンドの根本原因まで追跡できてこそ、可観測性は完成します。本セクションでは、既存のバックエンド可観測性と組み合わせる統合パターンを解説します。

7-1. RUM起点のドリルダウン

フロントエンドとバックエンドの可観測性を統合する核心は「ユーザーが感じた体験の劣化を起点に、根本原因のあるバックエンドコンポーネントまで辿り着く」ことです。CloudWatch RUM・Application Signals・X-Ray・CloudWatch Logsを連携させることで、フロントからバックまでの一気通貫調査が可能になります。

ドリルダウンの全体フロー

RUM（ユーザー体感）
  → INP悪化 / HTTPエラー検知
↓ RUMセッション詳細 → 問題のAPIエンドポイント特定
Application Signals（サービスマップ）
↓ そのAPIを提供するサービスの依存グラフ確認
X-Ray（分散トレース）
↓ 問題のトレースID → スパン詳細 → ボトルネックのコンポーネント特定
CloudWatch Logs（詳細ログ）
↓ エラーログ・スロークエリ → 根本原因の特定
AMP+AMG（長期メトリクス）
↓ 傾向分析・キャパシティ判断

RUMからApplication Signalsへの橋渡し

RUMスニペットで enableXRay: true を設定すると、ブラウザからのHTTPリクエストにX-Rayトレースヘッダー（X-Amzn-Trace-Id）が付与されます。これにより、ブラウザリクエストとサーバー側のX-Rayトレースが同一トレースIDで連携します。

RUMセッション詳細画面の「HTTP requests」タブで、エラーまたは遅延が発生したリクエストを選択すると、関連するX-Rayトレースへのリンクが表示されます。トレースIDをクリックするとX-Rayコンソールのトレース詳細に遷移し、どのマイクロサービスのどのスパンで遅延が発生しているかを確認できます。

Application Signalsのサービスマップ活用

Application SignalsのService MapはRUMとバックエンドサービスを同一ビューで表示します。ブラウザが呼び出すAPIのサービスが赤くなっている場合、そのサービスのP99レイテンシーまたはエラー率がSLO閾値を超えていることを示します。

Service Mapから対象サービスを選択すると、そのサービスへの依存（データベース・外部API・Lambdaなど）が展開表示されます。下流コンポーネントのボトルネックを視覚的に絞り込めるため、RUM起点の3段階調査（体感劣化確認→原因サービス特定→原因スパン特定）が数分で完了します。

CloudWatch Logsへのドリルダウン

X-Rayトレースの問題スパンにはログ相関が組み込まれています。Lambda関数や ECS タスクが構造化ログ（JSON形式）でX-RayトレースIDをログフィールドに出力している場合、CloudWatch Logs Insightsで以下のクエリを実行することで問題のあるログエントリを直接抽出できます。

fields @timestamp, @message
| filter traceId = "1-xxxxxxxx-xxxxxxxxxxxxxxxxxxxx"
| sort @timestamp asc
| limit 200

エラーログが特定できたら、スタックトレースの内容からコード修正の方針を判断します。このトレースIDによるログの直引きが「フロントエンドのユーザー体験から1本のトレースIDを使ってバックエンドの根本原因ログまで辿れる」ことの実体です。

AMP+AMGとの長期分析連携

X-Rayのリアルタイム調査だけでなく、RUMのINP・LCPのパーセンタイル値を Amazon Managed Service for Prometheus（AMP）に転送することで、長期的なWebパフォーマンストレンドを Amazon Managed Grafana（AMG）で可視化できます。

CloudWatchメトリクスをAMPに転送するには、CloudWatch Metrics StreamsとFirehoseを組み合わせてAMPのリモートライトエンドポイントに送信します。AMGダッシュボードでは、RUMのCore Web Vitalsメトリクスをデプロイイベント（Annotations）と重ねて表示することで、特定のリリースがフロントエンド品質に与えた影響を視覚化できます。

マルチリージョン可観測性でのSynthetics活用

グローバルサービスでは、特定地域からの到達性をSyntheticsカナリアで定期検証します。東京・バージニア・フランクフルトにカナリアを配置し、地域別の可用性SLOを設定することで、CDNやエッジキャッシュのルーティング異常を早期に検知できます。

RUMは実ユーザーの地域情報も収集するため、「カナリアでフランクフルトリージョンのレスポンスが遅化 → RUMでドイツユーザーのLCPが実際に悪化していることを確認」という能動検知から実影響確認までの一連の確認が可能です。

7-2. 合成監視と実ユーザー監視の組合せ

Syntheticsとの補完的運用

SyntheticsカナリアとRUMは異なる観点で品質を捉えます。両者を組み合わせた運用パターンを整理します。

アラート発火の優先度設計

Syntheticsカナリアが失敗した場合、RUMのエラー率・エラーセッション数と照合することで、アラートの影響度を素早く判断できます。

Syntheticsカナリア失敗（Severity: Warning）
  ↓ RUMでエラーセッション数が閾値超過？
Yes → 実ユーザーへの実害あり（Severity: Critical）→ インシデント即時対応
No  → 実ユーザーへの影響は限定的 → 調査は優先度中（業務時間内対応）

このフローにより、深夜のカナリア失敗で即時起動をかけるべきか・翌朝対応で良いかを判断する基準を持てます。

Syntheticsカナリアのシナリオ設計

SPA（Single Page Application）では、初期ロードだけでなくユーザー操作後のページ遷移・APIコールも外形監視の対象です。synthetics.executeStep() を用いて多段シナリオを定義します。

const synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const pageLoadTest = async function () {
  const page = await synthetics.getPage();

  await synthetics.executeStep('ホームページ読み込み', async function () {
 await page.goto('https://example.com/', { waitUntil: 'networkidle0', timeout: 30000 });
  });

  await synthetics.executeStep('ログインフォーム操作', async function () {
 await page.click('#login-button');
 await page.waitForSelector('#email-input', { timeout: 10000 });
 await page.type('#email-input', process.env.TEST_USER_EMAIL);
 await page.type('#password-input', process.env.TEST_PASSWORD);
 await page.click('#submit-button');
 await page.waitForNavigation({ waitUntil: 'networkidle0', timeout: 30000 });
  });

  await synthetics.executeStep('ダッシュボード表示確認', async function () {
 await page.waitForSelector('#dashboard-widget', { timeout: 15000 });
 const title = await page.title();
 if (!title.includes('ダッシュボード')) {
throw new Error(`予期しないページタイトル: ${title}`);
 }
  });
};

exports.handler = async () => {
  return await pageLoadTest();
};

テスト用の認証情報はSecrets Managerに格納し、カナリア実行ロールからのみ読み出せるポリシーを設定します。

外形監視と実ユーザー監視の補完運用例

日次のSLAレポートにはSyntheticsの可用性データを、月次のUX改善レポートにはRUMのCore Web Vitals推移データを使用します。SyntheticsはSLA根拠として契約・監査目的に適しており、RUMはユーザー体験の実態把握とA/Bテストの評価に適しています。

7-3. デジタルエクスペリエンス運用への発展

SLOベースのデジタルエクスペリエンス管理

Application SignalsのSLO機能を活用することで、フロントエンド品質をService Level Objective（SLO）として管理できます。フロントエンド向けのSLO設計例を示します。

SLO例：検索ページINP
  目標: 月次でINP p75 ≤ 200ms の割合 ≥ 95%
  エラーバジェット: 5%（720時間 × 5% = 36時間分の劣化を許容）
  Burn Rateアラート: 1時間でバジェットの5%消費でWarning / 10%消費でCritical

エラーバジェットが残り10%を切った場合、新機能リリースを一時停止してパフォーマンス改善スプリントに切り替えるルールを開発チームと合意します。このルールが「開発速度とユーザー体験品質のバランスを客観的指標で判断する」仕組みとなります。

ビジネスKPIとの接続

フロントエンドのパフォーマンス指標はビジネスKPIと直結します。代表的な関係性は次のとおりです。

RUMのメトリクスとビジネスKPIのグラフを同一ダッシュボードに並べることで、パフォーマンス改善の投資対効果を可視化できます。「INPをp75で200ms以下に改善した後、決済コンバージョン率が3%向上した」という形で、エンジニアリング施策の経営インパクトを示すことができます。

継続的改善サイクルの設計

デジタルエクスペリエンスの継続的改善には、以下のサイクルが有効です。

1. 計測：RUMのCore Web Vitals・クラッシュ率を毎週レポート
2. 分析：ワースト上位ページ・セッション・デバイス種別を特定
3. 改善：特定した問題箇所のコード修正・インフラ最適化
4. 検証：改善デプロイ後のRUMメトリクス変化を確認（A/Bテスト or Before-After比較）
5. フィードバック：改善効果をビジネスKPIと対照してチームに共有

このサイクルを月次または四半期で回すことで、フロントエンド品質の長期的な向上と、チーム内でのパフォーマンス文化の醸成が実現します。

既存可観測性記事との連携ポイント

本記事で扱うフロントエンド可観測性は、既存のバックエンド可観測性記事と組み合わせることで全体像が完成します。

• Application Signals・SLO統合の詳細はApplication Signals SLO本番運用記事を参照してください
• X-Rayによる分散トレースの詳細はX-Ray本番運用記事を参照してください
• AMP+AMGによるメトリクス長期管理は Observability OSS統合 Vol1 記事を参照してください
• ネットワーク到達性監視はNetwork可観測性 Vol1 記事を参照してください

8. 詰まりポイントとアンチパターン・まとめ

Synthetics/RUMの本番運用では、フロントエンド監視ならではの落とし穴があります。本セクションでは、現場で頻出する詰まりポイントとアンチパターン、そして次のステップを示します。

8-1. よくある詰まりポイント

詰まりポイント1: multi-checkカナリアの1チェック失敗でアラームが頻発する

multi-checkカナリアはいずれか1つのチェックが失敗するとカナリア全体が失敗と判定します。チェックの重要度に差がある場合（例: TCPポート監視は補助的な確認で、HTTPの死活監視ほど緊急度が高くない）、全チェックを1つのカナリアに束ねると副次的なチェックの失敗が重要なアラームと同等に扱われます。

対処法: 重要度が異なるチェックは別カナリアに分けるか、CloudWatchアラームの閾値や通知先で区別してください。死活監視と補助監視でアラームの優先度を変えることで、不必要なオンコール呼び出しを防げます。

詰まりポイント2: safe updates未設定でランタイム更新後に監視が停止する

safe updatesを有効にしないままランタイムバージョンを更新した場合、スクリプトとの非互換で本番カナリアが即座に失敗し、結果として監視も止まります。PuppeteerのAPIバージョンが上がると操作メソッドの挙動が変わるため、UIシナリオ系のカナリアで特に発生しやすい問題です。

対処法: ランタイム更新の前にsafe updatesを有効にしてください。staging実行で非互換を検知できるため、本番への影響を防げます。本番への影響ゼロでランタイムを最新化できます。

詰まりポイント3: RUMのINPとFIDを混同した古いSLO定義

2024年3月にCore Web VitalsからFID（First Input Delay）が廃止され、INP（Interaction to Next Paint）に移行しました。古いSLO定義でFIDを参照している場合、INPの収集データが増えてもSLO計算に反映されず、ユーザー体感の改善が見えなくなります。

対処法: CloudWatch RUMのメトリクス定義でFIDの参照をINPに更新してください。INPの良好な閾値はGoogle推奨の200ms以下が目安です。200〜500msはImprovement needed（改善要）、500ms超はPoor（不良）とされます。既存のCloudWatchアラームやダッシュボードのメトリクス参照も合わせて更新が必要です。INPはFIDと異なり最初のインタラクションだけでなく、ページ滞在中のあらゆる操作の応答性を測定する点も確認してください。

詰まりポイント4: モバイルRUMのSDKアップデートでセッション分析の継続性が失われる

CloudWatch RUMのiOS/Android SDKをメジャーバージョンアップした際、セッションIDの生成ロジックが変わり、セッション分析の継続性を失いかねません。リリース直後に「セッション数が急減」と見える誤認もこの原因で発生します。

対処法: SDKのリリースノートを確認し、セッション管理に関する変更が含まれる場合はアップデート前後でメトリクスの連続性を確認してください。RUMアプリモニターのバージョンタグ付けで新旧SDKのデータを区別することで、アップデート前後の比較が容易になります。

詰まりポイント5: カナリアの実行コストが想定より高くなる

短いスケジュール間隔（例: 1分間隔）で複数のBroken Link Checkerを設定すると、Lambda実行時間の課金が想定外に膨らむことがあります。Broken Link Checkerはページ内の全リンクを再帰的にたどるため、1回の実行時間が長くなりがちです。

対処法: Broken Link Checkerのスケジュールは実行時間の実績値を確認してから設定してください。Lambda最大実行時間を超えたカナリアはTimeoutエラーになるため、再帰数とタイムアウト設定の整合性を確認することが重要です。コスト見積もりはLambda実行時間（ms単位）×実行回数で計算し、月次のコスト試算を事前に実施することを推奨します。

詰まりポイント6: RUMのサンプリング設計ミスでデータが偏る

CloudWatch RUMはデフォルトで全セッションを収集しますが、高トラフィックサイトではコストと転送量を抑えるためにサンプリングを設定します。サンプリング率が低すぎると、レアなデバイスや地域のデータが収集されず、体感品質の偏りが生じます。

対処法: サンプリング率は最低でも10〜20%を確保してください。地域別や端末別の体感品質を把握したい場合は、CloudWatch RUMのカスタム属性（custom events）で端末情報を付与してセグメント分析できます。ビジネス上重要なユーザー属性（有料プランユーザーなど）は高いサンプリング率を設定することも有効です。

詰まりポイント7: フロントエンドだけ見てバックエンドへドリルダウンできない

RUMでCore Web VitalsのLCPが悪化していても、バックエンドの何が原因かわからないとアクションが取れません。Application Signals・X-Ray・CloudWatch Logsを連携させていない場合、フロントエンドとバックエンドの可観測性がサイロ化します。

対処法: RUMのカスタムイベントにX-RayのトレースIDを付与してください。ユーザーの体感劣化を起点にX-Rayのトレースへジャンプできるようになり、根本原因の特定が大幅に速くなります。Application Signalsのサービスマップと組み合わせることで、依存サービスのどこでレイテンシが増加しているかを視覚的に確認できます。

詰まりポイント8: Visual Monitoringのベースライン老朽化で誤アラームが続く

Visual Monitoringブループリントはページのスクリーンショットをベースラインと比較します。UIデザインの変更やA/Bテストのバリアントが増えるたびに「差分あり」として誤アラームが発生し、やがてアラームを無視するようになります。

対処法: UIリリース時にベースラインのスクリーンショットを意図的に更新するワークフローを設けてください。CI/CDパイプラインにベースライン更新ステップを組み込み、デザイン変更のたびに自動更新する構成が理想的です。比較感度（pixelDifference閾値）を適切に設定することで、微細な差分による誤アラームも減らせます。

詰まりポイント9: カナリアのIAMロールに過剰な権限を付与する

カナリアは内部ネットワークやAWSリソースにアクセスできるLambda関数として実行されます。調査の便宜上、AdministratorAccessなど過剰な権限を付与したIAMロールをカナリアに割り当てると、カナリアスクリプトが侵害された際のブラストラジアスが大きくなります。

対処法: カナリアのIAMロールには最小権限の原則を適用してください。以下のIAMポリシーが外形監視専用カナリアの最小構成です。

• s3:PutObject — カナリアのアーティファクト保存バケットへの書き込み
• cloudwatch:PutMetricData — カナリア実行結果のメトリクス書き込み
• logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents — ログ出力
• xray:PutTraceSegments, xray:PutTelemetryRecords — X-Rayトレース（必要な場合のみ）

VPC内リソースへのアクセスが必要な場合はSecurityGroupを絞り込んでください。Secrets Managerを使用する場合は secretsmanager:GetSecretValue の追加も必要です。AdministratorAccessは絶対に付与しないでください。

詰まりポイント10: マルチリージョンのカナリア設定が一部リージョンで漏れる

可用性SLOをリージョン横断で担保するためにマルチリージョンでカナリアを展開する際、Infrastructure as Codeの管理ミスで一部リージョンへの反映漏れが起きるケースもあります。特に新機能追加時にメインリージョンのみ更新してサブリージョンの更新を忘れることで、リージョン間の監視設定に乖離が生じます。

対処法: カナリアの定義はTerraform・CloudFormation StackSetsを使用してマルチリージョンへ一括適用することを推奨します。リージョンごとに手動で管理すると設定ドリフトが避けられません。またテスト環境と本番環境のカナリア設定を別々のコードで管理するのではなく、パラメータ化した共通モジュールにまとめるとリージョン間の差異を防げます。

8-2. SyntheticsとRUMの使い分けチェックリスト

Syntheticsと RUMはどちらもフロントエンド可観測性の手段ですが、用途が異なります。以下の観点で使い分けてください。

Syntheticsを選ぶ場面

• 本番トラフィックがない時間帯（夜間・低トラフィック時）の障害を事前検知したい
• 特定エンドポイントの可用性・レスポンスタイムをSLO計算に使いたい
• SSL証明書の有効期限や外部からのDNS解決結果を継続監視したい
• ユーザーがアクセスする前にリリースの影響を確認したい（pre-release canary）
• 競合製品や自社サービスを外部拠点から比較監視したい

RUMを選ぶ場面

• 実際のユーザーが感じる体験（LCP/CLS/INP）を計測したい
• 特定の地域・ブラウザ・端末での体感品質を把握したい
• JavaScriptエラーの発生頻度やユーザーセッションへの影響を分析したい
• A/Bテストや機能フラグの影響をユーザー体感で測定したい
• モバイルアプリ（iOS/Android）のクラッシュや起動遅延を検知したい

両方を組み合わせるパターン

Syntheticsで「エンドポイントの到達性」を確認し、RUMで「ユーザーの体感品質」を測定することで、インフラ障害とユーザー影響の両面を把握できます。Syntheticsが正常でもRUMのINPが悪化している場合は、サーバー側でなくフロントエンドのJavaScript実行に問題があると判断できます。逆にSyntheticsが失敗しているのにRUMのエラーが少ない場合は、特定の監視拠点からのみ到達できないネットワーク問題の可能性があります。

8-3. アンチパターン → 正解

8-3. コスト最適化と運用の継続的改善

Synthetics/RUMの月次コストを適切に管理するためには、定期的な棚卸しと最適化が重要です。以下のポイントを参考に、運用コストの継続的改善を実践してください。

カナリア棚卸しの定期実施

本番サービスのエンドポイントが廃止されてもカナリアが残存し、永続的に失敗アラームを出し続けるケースがあります。月次でカナリアの実行ログを確認し、廃止済みエンドポイントや不要になったチェックを削除してください。CloudWatch Dashboardにカナリア一覧と最終成功時刻を表示することで、棚卸しの効率が向上します。

RUMのコスト管理

CloudWatch RUMは収集イベント数に応じた課金モデルです。高トラフィックサイトでは月間のイベント数が急増しがちです。コスト管理のポイントは以下の通りです。

• サンプリング率の最適化: 全セッション収集から10〜20%サンプリングへの切り替えで最大80〜90%の削減が可能です
• カスタムイベントの絞り込み: 必要なユーザーインタラクションのみをカスタムイベントとして収集する設計にしてください
• データ保持期間の見直し: RUMのデータ保持期間はデフォルト30日です。分析頻度に合わせて保持期間を調整することで、ストレージコストを最適化できます

アラームの定期見直し

カナリアの結果に連動するCloudWatchアラームは、サービスの変化に合わせて閾値を定期的に見直してください。例えばレスポンスタイムの許容上限が変わった場合や、リトライ設定を変更した場合はアラームの評価期間も合わせて更新してください。アラームの見直しを怠ると、チームが「このアラームは毎回鳴るから無視してよい」という誤った習慣を持つようになります。

8-4. セキュリティとプライバシーの設計ポイント

Synthetics/RUMはエンドユーザーのブラウザ・モバイルアプリ動作を収集するため、セキュリティとプライバシーへの配慮が不可欠です。

カナリアのVPC配置とネットワークセキュリティ

内部APIやプライベートエンドポイントを監視するカナリアはVPC内に配置する必要があります。VPC内に配置する場合のネットワーク設計上の注意点は以下の通りです。

• カナリアをプライベートサブネットに配置し、NATゲートウェイ経由でインターネットへアクセスできる構成にしてください
• セキュリティグループはカナリアが接続するエンドポイントへのポートのみ開放し、最小権限の原則を適用してください
• VPCフローログを有効化し、カナリアの通信パターンを可視化することでセキュリティ異常を検知できます

RUMとユーザープライバシー

CloudWatch RUMのJavaScriptスニペットはユーザーのブラウザで実行され、URLパスやユーザー操作のタイミングデータを収集します。個人情報保護の観点から以下の点を確認してください。

• フォーム入力フィールドのデータは収集対象外です。ただし、URLにメールアドレスや個人情報が含まれる設計の場合はURLマスキングを設定してください
• GDPRやPIIPL等の適用法令に従い、プライバシーポリシーにRUMのデータ収集について明記してください
• モバイルRUM（iOS/Android）ではアプリのプライバシーマニフェストへの記載が必要なケースもあります。各OSのガイドラインを確認してください
• データ保持期間を設定し、不要になったRUMセッションデータを定期的に削除してください

Synthetics実行結果のS3ログ保管

カナリアの実行結果（スクリーンショット・HAR形式のネットワーク記録）はS3バケットに保存されます。このS3バケットには監視対象サービスへのリクエスト内容が含まれるため、適切なアクセス制御が必要です。

• S3バケットポリシーでカナリアサービスプリンシパルからの書き込みのみ許可してください
• バケットのパブリックアクセスブロックを有効化してください
• 保存データには機密情報（APIキーの応答など）を含む可能性があるため、SSE-S3またはSSE-KMSによる暗号化を設定してください
• ライフサイクルポリシーで古いログを自動削除することでストレージコストを最適化できます

8-5. まとめと次のステップ

本記事では、CloudWatch Synthetics/RUMの2025年新機能を中心に、フロントエンド可観測性の本番運用を解説しました。以下に本記事の要点を整理します。

Synthetics 2025 — 効率と安全性の強化

multi-checkカナリアによって、1つのカナリアで最大10種類の外形監視チェックを束ねられるようになりました。HTTP・DNS・SSL証明書・TCPポートを組み合わせることで、監視コストと管理オーバーヘッドを大幅に削減できます。関連するチェックをJSON設定でまとめ、Secrets Manager連携で認証情報を安全に管理することで、スケーラブルな外形監視基盤を構築できます。

safe updatesによって、カナリア定義の更新を本番適用前にstaging環境でテストできるようになりました。ランタイムバージョンの更新やスクリプト変更に伴う本番監視の停止リスクを排除でき、IaC管理との組み合わせでカナリアのライフサイクル管理を自動化できます。スケジュール失敗時の自動リトライと組み合わせることで、一過性の障害による誤アラームを大幅に削減できます。

RUM 2025 — Web + モバイルの統合体験監視

CloudWatch RUMはCore Web VitalsへのINP追加とモバイルRUM（iOS/Android）対応により、Webとモバイルネイティブアプリのユーザーエクスペリエンスを統合的に把握できるようになりました。FIDからINPへの移行を完了させ、最新のインタラクション品質指標に基づいたSLO管理を実現してください。サンプリング設計とカスタム属性の活用でコストを最適化しながら、体感品質の全体像を捉えられます。

フロントエンドとバックエンドの一気通貫可観測性

フロントエンドの可観測性は、バックエンドのメトリクス・ログ・トレースと組み合わせることで真価を発揮します。Application Signals・X-Ray・CloudWatch Logsとの統合により、ユーザーの体感劣化を起点にバックエンドの根本原因まで一気通貫で追跡できます。RUMのカスタムイベントとX-RayのトレースIDを紐付けることで、フロントエンドとバックエンドのシグナルを統合した真のエンドツーエンド可観測性を実現できます。

運用品質の継続的向上

セキュリティとプライバシーの設計も忘れてはなりません。カナリアのIAMロールへの最小権限付与、RUMのデータプライバシー配慮、S3ログバケットへのアクセス制御を適切に設計することで、監視基盤自体がセキュリティリスクになることを防げます。

定期的なカナリアの棚卸し、サンプリング率の見直し、不要なアラームの削除により、監視品質を維持しながらコストを最適化し続けてください。監視は一度設定して終わりではなく、サービスの進化と共に継続的に改善するものです。SRE文化の根幹にある「信頼性を数値で管理する」姿勢をフロントエンドにも適用し、エラーバジェットベースの意思決定を組織全体に広げてください。

Vol2では、CI/CDパイプラインへのカナリア統合と自動ロールバック、セキュリティとコスト最適化の実践的な設計パターンをさらに深掘りします。フロントエンドとバックエンドの可観測性を統合したデジタルエクスペリエンス管理の完成形を目指してください。

以下の関連記事も合わせて参照することで、CloudWatch Synthetics/RUMをより効果的に活用できます。Application Signalsでのバックエンド統合、Grafana+PrometheusによるOSS可観測性基盤との連携、ネットワーク観測との組み合わせ、Logsによるログ分析まで、可観測性スタック全体を俯瞰した設計が本番環境での安定運用に繋がります。

本記事で解説した詰まりポイントとアンチパターンを組織内のナレッジとして共有し、チーム全体のSynthetics/RUM活用レベルを底上げしてください。フロントエンド可観測性の成熟度を高めることで、ユーザー体験の継続的な改善サイクルが回り、ビジネスKPIへの直接的な貢献につながります。

合成監視と実ユーザー監視の両輪をうまく組み合わせることで、フロントエンドサービスの品質を多面的に把握できます。Vol1で学んだ2025年新機能の理解を土台に、Vol2ではさらに実践的な運用パターンへとステップアップしてください。