Synthetics

外形監視が拾う、内側の監視では見えない故障

サーバーの CPU もエラーログも正常なのに、利用者からはサイトに到達できない。DNS の設定ミス、証明書の期限切れ、CDN やロードバランサの不調など、「自分の外側」で起きる故障は内側の監視だけでは拾えません。外形監視 (Synthetic Monitoring) はこの死角を埋める仕組みで、Datadog では世界各地のロケーションからシミュレートされたリクエストと操作を送り、Web ページと API の挙動を安定した条件で検証し続けます。対象にできるネットワーク層は幅広く、HTTP・SSL・DNS・WebSocket・TCP・UDP・ICMP・gRPC が並びます (2026 年 8 月時点・出典: Synthetic Testing and Monitoring)。検証結果は主要エンドポイントやユーザージャーニーの SLO の計算にもつなげられるため、「うちのログイン導線は 99.9% 通る」を口約束ではなく計測値として持てるようになります。テストの作成は画面上のほか API や Terraform でも行え、監視をコードで管理したいチームにも道が用意されています。

最初の一歩は API テストから

導入の起点として公式が用意しているのが API テストです。単発のリクエストを送る形式と、複数のリクエストを連鎖させる multistep 形式があり、HTTP テストなら「このエンドポイントに GET して、ステータス 200 が 500 ミリ秒以内に返り、レスポンスボディに特定の文字列が含まれる」といった検証を数分で組めます (2026 年 8 月時点・出典: API Tests)。SSL テストは証明書の有効性を、DNS テストは名前解決の正しさをそれぞれ見張ります。実務では、まずヘルスチェック用エンドポイントへの HTTP テストと、本番ドメインの SSL テストの 2 本から始めるのが定石です。この 2 本だけで「サイトが完全に落ちている」「証明書が切れかけている」という最も恥ずかしい 2 大事故の目撃者が利用者から機械に変わります。multistep は認証トークンを取得してから本命の API を叩くような、単発では表現できない検証に進むときの次の一手です。

ブラウザテストの作りやすさと壊れやすさは表裏

ブラウザテストは実際のブラウザで Web アプリを操作するシナリオを世界各地・複数ブラウザ・複数デバイスで定期実行するもので、レコーダーで実際に操作しながら手順を記録して作ります。あらかじめ用意されたテンプレートから始めることもできます (2026 年 8 月時点・出典: Browser Tests)。記録だけで作れる手軽さの裏返しとして、ブラウザテストは UI の変更で壊れやすいという宿命を持ちます。壊れにくく保つ実務の工夫は 4 つあります。第一に、シナリオを「事業が止まる導線」だけに絞ること。網羅を狙った 30 本より、決済導線の 3 本の方が保守が続きます。第二に、検証 (アサーション) を本質的な成功条件に限定すること。文言の一字一句を検証すると文言修正のたびに壊れます。第三に、URL や認証情報を変数化して環境変更に強くすること。第四に、計画メンテナンス時はダウンタイム設定と連動させることです。テストはダウンタイムの時間帯に自動で一時停止するため、深夜メンテのたびに偽アラートで人を起こす運用から抜けられます。

実行回数の課金は頻度とロケーションの掛け算で見積もる

Synthetics の課金単位はテストの実行回数です。2026 年 8 月時点の公式料金ページでは、API テストが 1 万実行あたり月 5 ドル、ブラウザテストが 1,000 実行あたり月 12 ドル (いずれも年契約) と、単価の桁がひとつ違います。さらにブラウザテストには 25 ステップごとに 1 実行と換算する規則があり、50 ステップのテストは毎回 2 実行分として数えられます。事故はこの掛け算の見落としから起きます。公式の例示に沿って数えてみます。

1 本のテストとしては何も派手なことをしていないのに、この規模になります。見積もりの手順は「実行間隔・ロケーション数・デバイス数・ステップ数を掛けて月間実行数を出してから単価表に当てる」の一手だけで、逆にこの一手を飛ばすと確実に驚くことになります。守りとしては、実行間隔をテストの重要度で分ける (死活は 1 分・導線確認は 15 分・網羅確認は 1 時間)、ロケーションは利用者の実在地域に絞る、の 2 つが効きます。なお本記事の価格は各時点の実例であり、執筆後の価格改定を反映するものではありません。料金全体の構造は料金の読み解きで扱っています。

Private Location - 社内システムにも覆面調査員を

公開インターネットから届かない社内アプリやプライベートなエンドポイントには、Private Location を使います。自社ネットワーク内に Docker コンテナ・Windows サービス・Kubernetes (Helm) として worker を設置すると、worker が Datadog 側へ HTTPS でテスト設定を取りに行き、ネットワーク内でテストを実行して結果を返します (2026 年 8 月時点・出典: Private Locations)。worker 側から外へ取りに行く方式なので、社外から社内への通信経路を新たに開ける必要がない設計です。公式が挙げる用途は、社内向けアプリの監視のほか、事業上重要な地域に独自ロケーションを立てる、本番リリース前に CI 環境でアプリの動作を検証する、社内ネットワークの内と外で性能を比較する、というものです。実務でありがたいのは最後の比較で、「社内からは速いのに社外から遅い」が数字で見えると、問題がアプリ側かネットワーク経路側かの切り分けが会話ではなくデータで進みます。管理された既製ロケーションと Private Location はテスト側から見ると同じように扱えるため、運用の型は変わりません。

どこまで Synthetics でやるか、E2E テストとの線引き

ブラウザテストを組めるなら、リリース前の UI テストも全部 Synthetics でやればよいのでは、という発想が出てきます。線引きの基準は「そのテストが落ちたとき、誰かを呼び出すか」です。本番の死活・重要導線・証明書のような、落ちたら即対応が必要なものは Synthetics の領分で、モニター経由の通知体制とセットで運用します。一方、開発中の機能の網羅的な UI 検証は、コードと同じリポジトリで管理される CI の E2E テストの領分です。テストコードと製品コードが一緒に変更・レビューされる方が、UI 変更への追随コストが安く済みます。Datadog にはこの中間に Continuous Testing という CI/CD 連携の仕組みもありますが、まずは「本番監視 = Synthetics・開発時検証 = CI」という単純な線から始めて困ってから考えれば十分です。また Synthetics は疑似アクセスである以上、実ユーザーの体験そのものは見えません。実客の観察は RUM の領分で、「誰もいない時間の見張りは Synthetics、いる時間の実態把握は RUM」という補完関係で捉えると、両者への投資判断がすっきり整理できます。