【外形監視】APIテスト vs ブラウザ（UI）テスト

Posted at 2025-11-19

はじめに

さて、外形監視を始めよう！と思ったけど、APIテストとブラウザテストがあってどのように使い分けたらいいか分からない・・・こんな悩みを解決します。

バランスが大事

どちらかでいい、どっちが良いというものではありません。API テストは速く安定して「機能／応答」を監視するのに向いています。一方で、ブラウザ（UI）テストは実ユーザー体験（レンダリング・JS 実行・統合フロー）を検出するのに向いています。どちらにも良し悪しがあるので、両者を組み合わせて目的に応じて適切な頻度とシナリオを設計することが必要となってきます。

以下では、それぞれの特徴を理解していきましょう。

1. 目的と対象の違い

以下にAPIテストとブラウザテストの概要を示します。

API テスト（Synthetic API）
HTTP(S) で直接到達して確認する軽量なテスト手法です。単純にエンドポイントの可用性やレスポンス時間、レスポンス内に含まれる要素の整合性等を確認できます。
ブラウザ（UI）テスト（Synthetic Browser / RUM ではない合成）
実ブラウザで実ユーザーの体験を再現して監視をする比較的従量なテスト手法です。フルレンダリング、ユーザー操作（ログイン・遷移・フォーム送信）や JSの実行結果を監視するのに向いています。

種類	利点	欠点
APIテスト	軽量／高速／安定、コスト低、CI と連携しやすい	フロントエンド依存の問題（レンダリングやJSエラー、実ユーザーの画面表示不具合）は検出できない
ブラウザ（UI）テスト	実ユーザー体験の再現、統合的な不具合を検出	重量／不安定（ネットワーク・リソースでぶれる）、実行コストが高い

2. ユースケース別推奨

ここでは、ユースケース別にどういった監視をしたい時に活用できるか見ていきましょう。

サービスの「基本応答が落ちてないか」を監視したい
→ API テスト（GET /health, /status, 主要 API のサンプル応答確認）
認証後の主要ユースケース（カート追加→決済まで）を監視したい
→ ブラウザテスト（ログイン・セッション・JS 実行を含むフロー）
外部依存（OAuth、決済ゲートウェイ、CDN）稼働監視
→ 組み合わせ：API でエンドポイント確認 + 必要に応じブラウザで連携フロー確認
フロントエンドでの描画崩れ・JS エラーを早期検知したい
→ ブラウザテスト（コンソールエラー、レンダリング差分、重要要素の存在確認）
レイテンシ SLA を厳密に監視したい（例: API P95）
→ API テスト（高頻度で分位数計測）、補助でブラウザの「ページ読み込みタイム」も計測

3. ベストプラクティス（頻度・ロケーション・アラート）

かなり個人的な見解も入ってしまいますが、以下が設計のベストプラクティス（個人的な見解）です。実際の設計は要件やSLAを読み込んで設計してください。

頻度
- 重要なAPI: 1 or 3 or 5 分間隔
- 重要でないAPI: 10 or 15 分間隔
- UI フロー: 10 or 15 分間隔
ロケーション
- グローバルなサービスの場合：ユーザー分布に沿って複数リージョン（国内／海外）で実行
- プライベートなサービスの場合：プライベートロケーション（プライベートネットワーク内の仮想マシン等）で実装
アラート設計
- 「複数ロケーションで連続失敗（N回）」でトリガー　※短時間の単発障害はノイズになるため注意
- しきい値：API 500/タイムアウト、応答スキーマ不整合で即時、遅延は P95 以上が継続で警告

4. 監視でチェックすべき具体項目

具体的には以下のような項目をチェック項目として考えておきましょう。特に重要で要件として実際に私個人としてもよく要件として受け取るものは赤字にしています。

API テスト
- Status code（200/2xx）
- レスポンスタイム（P50/P95/P99）
- 認証（トークン更新）フロー
- レスポンスボディの重要フィールド存在チェック（JSON Schema）
- Header / Cache / CORS（必要に応じ）
ブラウザテスト
- ページ読み込み時間 / Largest Contentful Paint（簡易）
- ネットワークエラー（XHR / Fetch の失敗）
- DOM 要素の存在・テキスト確認
- console.error / JS 例外の有無

5. 実装例と監視ツール連携（Datadog / Dynatrace）

ここでは、Datadogを例として設定例を示していきます。

5.1 Datadog Synthetic Browser Test 設定例

Datadog側での操作を示していきます。

Digital Experience > New Testsを開きます
こんな感じでどのテストを作成するか選択させられるので、作成したいテストを選んでください。

なお、「Multistep API Test」はレスポンスで取得した要素などを使用して遷移していくのに非常に便利です。詳細は、活用例が以下のYoutubeに載っているのでこちらを確認ください。
Youtube| How to configure Multiple API test in DataDog
細かい設定をしていく
少し画面が古いですが、以下富士通のサイトが分かりやすかったのでこちらを参考に設定を進めて下さい
Datadogでアプリケーションパフォーマンスを監視する方法
　⇒「外形監視についても設定してみる」参照
設定画面を以下に示しておきます。
■APIテスト
細かい設定を定義していきます。３省や４章を参考に設計した内容を入力してください。

■ブラウザテスト
Location等の細かい設定を定義します。

プレビューを見ながら操作をRecordingしていきます。