クラウド / システム
実際のブラウザーでサイトがどう動いているのか、もう少し知りたいと思っていました。サーバーログからはリクエストを確認でき、人による閲覧と思われるページビュー数を推定できます。ただし、訪問者の端末での体験をすべて把握できるわけではありません。
そこで、Amazon CloudWatch Real User Monitoring（RUM）の導入を準備しました。名前から受ける印象ほどデータは確かなものではありません。この仕組みで分かることと分からないことを、きちんと説明しておきます。
小さく、同意した人だけのデータ
予定しているブラウザー連携は、意図的に機能を絞っています。まずサイトが同意を尋ね、訪問者が「許可」を選んだ場合にだけAWSクライアントを読み込みます。拒否した場合、RUMデータは送信されません。選択内容はブラウザーに保存され、後から同意を撤回できます。
同意したセッションのうち、選ばれるのは5％だけです。これはサンプリングの設定であり、利用者の5％が必ず集計されるという意味ではありません。サンプリングは確率的に行われ、同意しなかった人はRUMのデータには一切含まれません。
設定の対象はページビューとセッションのイベントです。セッションリプレイ、RUM Cookie、X-Ray、エラー・HTTP・パフォーマンスの各コレクターは無効にしています。AWSはイベントを米国東部（バージニア北部）リージョンで30日間保持します。ネットワークリクエストではIPアドレスが必然的に公開されます。イベントデータには、ページのパス、時刻、ブラウザーや端末の技術情報、仮名化されたセッションまたはCognitoの識別子が含まれる場合もあります。ページのパスにクエリパラメーターは含まれません。
データは人数のカウントではない
5％のサンプリングと任意の同意を組み合わせると、得られるデータは少なく、対象にも偏りがあります。すべての訪問者を表すものではなく、サイトを使う人の実人数も分かりません。ブラウザーのセッション、サーバー側のページビュー、CDNへのリクエストは、それぞれ異なる測定方法で、見えない部分も異なります。
これらの数値は分けて扱います。RUMは、サンプルに選ばれたブラウザー上の動きを見る手がかりになります。既存のサーバー側カウンターは、リクエストをフィルタリングして求める推定値であり、本人確認済みの人数ではありません。CDNのリクエスト総数には、サイトのファイルへのアクセスや自動化された通信も含まれます。これらを一つの「訪問者数」にまとめても、役に立つ数字にはならず、かえって実態から遠ざかります。
コスト対策にも限界がある
RUMのイベントや、それを支えるAWSサービスには料金がかかることがあります。セッションの5％をサンプリングすることで予想されるデータ量は減りますが、上限が設けられるわけではありません。認可されたクライアントは直接呼び出せますし、攻撃者がブラウザーのサンプリング処理を通さずにイベントを送る可能性もあります。
この構成では、取り込まれたイベントの急増を監視するアラームと、ゲストロールに明示的なIAM拒否を追加するLambda関数を用意しています。アラームが作動し、IAMの変更が反映された後は、追加の取り込みを止められます。すでに受け付けられたイベントは取り消せません。また、監視や停止の反映には時間差があります。これは安全対策の一つであり、支出額の上限を保証するものではありません。
AWS全体を対象にした既存の月次変更停止も維持し、AWSに変更を加える前には毎回コストを見直します。どちらも役立つ対策ですが、リアルタイムの請求額を正確に保証することはできません。急なイベント増加があれば、アラームが反応する前に費用が膨らむ可能性があります。この残るリスクも判断の一部です。安心できそうなダッシュボードを見ても、リスクはなくなりません。
有効化済み、確認すべき実データはこれから
同意を尋ねるクライアントと、各言語のプライバシー通知はすでにサイトに組み込まれています。クライアントはまず同意を尋ね、訪問者が「許可」を選んだ後にだけAWS SDKを読み込みます。アクティベーション手順書には、RUMの取り込みに必要な範囲限定の権限を2026年11月11日に有効化したと記録されています。セッションの5％というサンプリングは同意後にだけ適用され、訪問者全体の数を示すものではありません。
これでデータ収集の経路が開いたことは分かりますが、実際のデータがどのようなものかはまだ分かりません。実際のブラウザーイベントは確認できておらず、発生した請求額も検証していません。アラームのしきい値を実際に試すテストも行っていません。設定した検知条件は、60秒間に少なくとも20件のイベントが取り込まれると、Lambda関数にゲストロールへのIAM拒否追加を依頼します。すでに受け付けられたイベントは削除できず、監視、通知、IAM変更の反映には時間がかかります。停止が有効になる前に、急増したイベントによって費用が膨らむ可能性があります。
この検知条件は有用な対応手段ですが、支出額に厳密な上限を設けるものではありません。アカウントの月次安全停止は、しきい値に達したときにエージェントによる追加変更を止めますが、請求額を正確に保証するものでも、稼働中のサービスを停止するものでもありません。特に実際のイベント量と費用が未確認の間は、RUMの結果とあわせてこうした限界も伝える必要があります。
測定は控えめで分かりやすいものに保ちたいと思います。まず同意を尋ね、同意したセッションの一部だけをサンプリングし、既存のサーバーやCDNの数値とは分けて扱い、データと安全対策で保証できないことを率直に伝えます。