Datadog Syntheticsの実装手順：APIテストとブラウザテストの作り分けと頻度設計

Datadog Syntheticsは、利用者と同じ経路でリクエストを投げ、応答が期待どおりかを外側から確かめる機能です。1本作るだけなら数分で終わりますが、そのまま増やしていくと請求と通知の両方が膨らみます。2026年8月時点の公式ドキュメントを実測しながら、テスト種別の選び分け、ロケーションと頻度の設計、CIへの組み込みまでを実装の順序で整理します。

まとめ：Synthetics実装で先に決める4点

着手前に確定させるのは4点です。どの種別のテストを作るか、どこから叩くか、何分間隔で回すか、そして失敗をどの条件でアラートにするか。この4点は独立ではなく、後ろの2つが課金実行数と夜間の呼び出し回数を決めます。

種別は、まずHTTPテストを1本。到達性と応答時間と状態コードを見るだけなら、ブラウザテストを持ち出す必要はありません。ログイン後の画面まで確かめたい段階になって初めて、ブラウザテストかマルチステップAPIテストを検討します。

ロケーションは、監視対象が公開エンドポイントならマネージドロケーションから2〜3か所。社内ネットワーク内のAPIを叩くなら、プライベートロケーションのワーカーを自前で置く構成になります。ここでロケーション数を増やすと、実行数がそのまま倍数で増える点に注意してください。

頻度は、許容できる停止時間の長さから逆算します。5分以内に気づきたいなら1分間隔、翌朝までに把握できればよい社内向け管理画面なら15分や30分間隔で足ります。そして通知は、1回の失敗では鳴らさない設定を初期段階から入れておく。この判断の根拠は各章で条件付きに書きます。

Datadog Syntheticsで作成できるテスト種別と選び分けの順序

Syntheticsの下には複数のテスト種別があり、名前が似ているため最初に混乱しやすい部分です。製品全体の中でSyntheticsがどの位置にあるかを掴んでいない場合は、Datadogの機能構成と導入の背景を先に押さえると、以降の話が接続します。

APIテスト8種のプロトコルとHTTPテストから着手する理由

APIテストは、公式ドキュメント上で8つのサブタイプに分かれています。HTTP、SSL、DNS、WebSocket、TCP、UDP、ICMP、gRPC。それぞれ独立したテストとして作成し、同じ画面から結果を追えます。

この中で最初に作るべきはHTTPテストです。理由は単純で、利用者が実際に踏む経路と一致するから。DNSテストやTCPテストは、HTTPテストが落ちたときに原因を切り分けるための補助として後から足すほうが効きます。証明書の期限切れを別立てで拾いたい場合だけ、SSLテストを早い段階で1本置く価値があります。

加えて、TCP・UDP・ICMPのチェックで経路を可視化するネットワークパステストも用意されています。ネットワーク機器をまたぐ構成でどこが遅いのかを追う段階になったら候補に入ります。

マルチステップAPIテストで業務フロー全体を連結する判断基準

単発のHTTPテストで足りなくなるのは、認証トークンを取ってから別のエンドポイントを叩くような連続した処理を確かめたいときです。マルチステップAPIテストは、複数のリクエストを連結し、前のステップの応答から変数を取り出して次へ渡せます。

実測した仕様では、既定で作成できるステップ数は10まで（上限の引き上げはサポート窓口経由）。変数の抽出は1ステップあたり10個までで、レスポンスのヘッダーやボディから正規表現・JSONPath・XPathで取り出します。取り出した変数は{{ VARIABLE_NAME }}の形で後続ステップから参照でき、urlEncodeやbase64Encodeといったフィルターを挟めます。

判断基準はこうです。ステップが3つ以内で収まり、UI操作を伴わないなら、マルチステップAPIテストが軽くて安い。画面のレンダリングやJavaScriptの動作まで確かめたいならブラウザテストに寄せる。ステップが10近くまで伸びる設計になったら、それはテストではなくE2Eの領域なので、監視から切り離すことをすすめます。

ブラウザテストとモバイルアプリテストを使い分ける場面と注意点

ブラウザテストは、Datadog Record Test拡張機能（ChromeとEdgeで利用可）で操作を記録して作ります。実行時に選べるブラウザはChrome・Firefox・Edge、デバイスは1440×1100のラージノートPC、768×1020のタブレット、320×550のモバイルという3区分です。

ステップにはクリック、テキスト入力、要素の存在確認、ページ内容のアサーション、変数の抽出、待機、APIテストの埋め込み、JavaScriptの実行などが並びます。ただしメール関連のステップとファイルアップロードは、ステップ再生の対象外という記載がありました。ログイン後の画面を毎回踏むシナリオを組む場合、この制約に当たらないかを先に確かめてください。

モバイルアプリテストはiOSとAndroidのアプリを対象にした種別で、Webの監視とは別物です。アプリのバイナリを登録して回す前提なので、Web側の監視設計とは切り離して検討してください。なお、実ユーザーの体感を測る目的ならSyntheticsではなくブラウザSDKで実際のセッションを収集するRUMの領分です。合成監視は「決まったシナリオが通るか」、RUMは「実際の利用者に何が起きたか」と役割が分かれます。

実行ロケーションの設計：マネージドとプライベートの切り分け方

どこからリクエストを投げるかは、検知できる障害の範囲と請求額の両方を決めます。外形監視という監視手法そのものの位置づけは内部監視との違いと監視項目の整理で扱ったので、ここでは配置の設計に絞ります。

マネージドロケーションを何か所選ぶかは課金実行数から逆算する

マネージドロケーションはDatadog側が世界各地に用意している実行地点で、選ぶだけで使えます。国内向けサービスなら東京と大阪といった近い地点を選ぶのが基本で、海外からの到達性を売りにしていないサービスで欧米の地点を並べる意味は薄い。

数の決め方は、実行数の掛け算から入ります。課金はAPIテストが1万実行あたり、ブラウザテストが1,000実行あたりという単位。ここに「ロケーション数×1日の実行回数×日数」がそのまま乗ります。1分間隔で3ロケーションなら1日4,320実行、月におよそ13万実行。同じテストを5分間隔の2ロケーションにすれば月およそ1.7万実行まで落ちます。

2〜3か所をすすめるのは、1か所だと実行地点側の一時的な不調を障害と誤認するためです。逆に5か所以上並べても検知できる障害は増えず、実行数だけが積み上がります。課金単位の全体像は費用が膨らむ課金単位の整理に寄せてあります。

内部向けエンドポイントを叩くプライベートロケーションの構成要件

社内ネットワークからしか到達できないAPIや管理画面を監視するには、プライベートロケーションのワーカーを自社側に配置します。配布形態はDocker Hubのコンテナイメージ、Kubernetes向けの公式Helmチャート、WindowsサービスとしてのMSIインストーラー（1.72系）。ECS・Fargate・EKSでの構成手順も用意されています。

Windowsサービス版の要件として、対応OSはWindows Server 2025・2022・2019・2016およびWindows 11・10、メモリは最低4GB（8GB推奨）、64bitのIntelまたはAMDプロセッサで2.8GHz以上が推奨、.NET 4.7.2以上が必要という記載でした。ネットワーク要件は、Syntheticsのインテークに対する443番の外向きHTTPS通信です。

制約も把握しておいてください。AWS Fargateでは、予約済みIPアドレスをブロックするファイアウォール機能が使えません。FIPS準拠が求められる環境では、Linux版1.32.0以降・Windows版1.63.0以降という条件が付きます。ワーカーは設定をHTTPSで取得してテストを実行し、結果をDatadog側へ返す仕組みなので、常時稼働する実行基盤を1つ増やす前提で見積もってください。

実行頻度とアサーション設計で検知力と誤報のつり合いを決める手順

実行頻度は許容できる停止時間の長さと課金実行数から逆算して決める

ブラウザテストで選べる実行間隔は、1分ごとから週1回までという範囲でした。この幅の中でどこに置くかは、感覚ではなく「気づくまでに何分かかってよいか」から決めます。決済のように止まると即座に売上が消える経路は1分間隔、社内の申請システムは15分間隔、月次でしか使わない管理画面なら1時間間隔でも運用は回ります。

間隔を詰めるほど検知は早くなりますが、費用は線形に増える。ここで効くのが種別の置き換えです。ブラウザテストは1,000実行あたりの課金なので、APIテストと比べて実行1回の単価が重い。ログイン後の画面確認を1分間隔で回すより、到達性はAPIテストの1分間隔で拾い、画面遷移のブラウザテストは15分間隔に落とす。この組み合わせで検知力をほぼ保ったまま費用を下げられます。

1テストのアサーションは20個まで・踏み込む深さをどう決めるか

APIテストのアサーションは1テストにつき20個まで作れます。設定できるのは、ボディ（contains・is・matches・jsonpath・xpath・jsonschema など）、ボディのハッシュ（md5・sha1・sha256）、ヘッダー、応答時間（ミリ秒未満であること）、状態コードの各種。

ただし20個まで作れることと、20個作るべきことは別です。監視のアサーションは、増やすほど「仕様変更で落ちる」確率が上がります。実装として推奨できるのは3つ。状態コードが200であること、応答時間が想定の上限を下回ること、そしてレスポンスボディに業務上の意味がある文字列が含まれていること。この3つで「落ちている」「遅い」「中身が空になった」を拾えます。

JSONスキーマの全項目検証のような深い検証は、監視ではなくテストの仕事です。それをSyntheticsに載せると、リリースのたびに監視が赤くなり、やがて誰もアラートを見なくなります。

リトライと複数ロケーション同時失敗の条件で夜間の誤報を止める

誤報を止める設定は2段構えです。1段目がリトライで、テストは失敗時にYミリ秒後からX回まで再試行できます。ネットワークの一瞬の揺らぎはここで吸収されます。

2段目がアラート条件。公式の記述は「N個のロケーションのうち任意のn個から、X分間いずれかのアサーションが失敗した場合にアラートを発報する」という形で、時間の継続とロケーションの同時性という2条件を同時に満たしたときだけ鳴ります。3ロケーションで運用しているなら、n=2以上に設定するだけで、実行地点1か所の不調による夜間の呼び出しはほぼ消えます。

初期設定のまま1回の失敗で鳴らす運用にすると、最初の1か月で担当者がアラートを無視し始めます。監視を入れる目的は通知を増やすことではないので、鳴らす条件は導入と同時に決めてください。

CI/CDパイプラインからの実行とアラート通知連携の実装手順

datadog-ci synthetics run-testsで既存テストを呼び出す

Syntheticsのテストは、スケジュール実行だけでなくCI/CDパイプラインの中からも起動できます。使うのは公式CLIで、NPMパッケージ@datadog/datadog-ciをdevDependenciesへ入れ、datadog-ci plugin install syntheticsでプラグインを明示的に導入してからdatadog-ci synthetics run-testsを叩く流れです。5系ではsyntheticsがプラグインとして分離されているため、この明示インストールを飛ばすと実行時に自動取得が走ります。配布形態やバージョン固定の考え方は3つの配布形態とプラグイン方式の整理に書いたとおりです。

どのテストを走らせるかは、テスト一覧の検索クエリで指定できます。--search 'team:unicorn tag:e2e-tests'のようにタグで束ねる形。テストIDを直接列挙する方式より、タグ運用にしておくほうがテストを増やしたときにパイプライン側の修正が要りません。デプロイ直後にこれを走らせ、失敗したらロールバックする構成が素直な使い方でしょう。

Continuous Testingのトンネルで社内環境のテストを通す

ステージング環境が社内ネットワーク内にある場合、マネージドロケーションからは到達できません。ここで使えるのが--tunnelオプションで、Continuous Testingのトンネル経由でCIジョブ側から内部環境に対してテストを実行できます。プライベートロケーションのワーカーを常設せずに済むぶん、公開前の検証にはこちらが向きます。

もう1つ押さえておきたいのが--failOnCriticalErrorsです。レート制限や認証失敗、Datadog側の基盤起因といった一過性のエラーでCIジョブを落とすかどうかを切り替えます。デプロイを止める判断に使うパイプラインなら有効にし、参考情報として流すだけなら無効のまま。ここを決めずに入れると、監視起因でリリースが止まる事故につながります。

アラートの通知先と計画停止時のダウンタイム設定で運用に載せる

Syntheticsのテストは、作成した時点でモニターとして扱われます。通知先はモニター側の設定と同じ仕組みで、メールやチャットツールの宛先を本文に書き込む形。テストごとに宛先を変えられるので、決済経路は電話呼び出しまで、社内システムはチャット通知まで、と段差を付けられます。

計画停止の扱いも、事前に決める項目です。ブラウザテストにはスケジュールダウンタイムの指定があり、定期メンテナンスの時間帯を除外できます。深夜のバッチ処理でアプリケーションを再起動する運用なら、その時間帯を外しておかないと毎晩アラートが飛びます。

Synthetics導入を決める条件と、見送るほうがよい3つの場面

Syntheticsの採用に踏み切ってよい条件を対象システムから示す

採用を推せるのは3条件がそろう場合です。第1に、対象が利用者から直接アクセスされるWebシステムかAPIであること。第2に、止まったときの影響が金額か信用で説明でき、1分あたりの損失を言語化できること。第3に、アラートを受け取って動く担当が決まっていること。

この3つがそろうなら、Datadogを既に他の用途で使っているかどうかにかかわらず投資に見合います。特に、AgentやAPMを既に入れている環境では、同じダッシュボードとタグ体系の上に外形監視が乗るため、障害時に「利用者から見えなくなった時刻」と「内部で何が起きたか」を1画面で突き合わせられます。この突き合わせの速さが、別サービスで外形監視だけ持つ構成との実質的な差です。

監視の設計と運用を自社だけで抱えきれない場合は、体制ごと組み立て直すほうが早い場面もあります。当社では保守運用・内製化支援として、監視設計から通知経路の整備、運用の内製化までを支援しています。

見送るべき3つの場面と、その前に整えるべき監視体制の前提条件

1つ目は、アラートを受け取る担当が決まっていない場合。通知の先に動く人がいない監視は、請求書だけが届く設定です。先に当番と一次対応の手順を決め、それからテストを作ってください。

2つ目は、監視対象が社内向けの管理画面だけで、業務時間内に人が使って気づける規模の場合。1日数回しか使われない画面に1分間隔の監視を置く合理性は乏しく、30分間隔か、そもそも見送りが妥当です。

3つ目は、AWSだけで完結していて監視の要件も到達性の確認に閉じている場合。同種の機能はAWS側にもあり、CanaryによるAWS外形監視の実装で足りるなら、そちらのほうが構成要素を増やさずに済みます。Datadogを選ぶ理由は、複数クラウドやオンプレミスを横断する監視、あるいはAPMやログとの突き合わせにあります。

他の外形監視サービスから乗り換えるかを費用と運用体制で比べる

既に別の外形監視サービスを使っている場合、乗り換えの判断は単価の比較では決まりません。比べるべきは3点。障害時に見る画面が1つに減るか、テストの管理をコードに寄せられるか、そして年間の実行数を見積もったときの総額です。

実行数の見積もりは、現行サービスの設定をそのまま移す前提で計算しないでください。前述のとおり、ロケーション数と頻度の掛け算が効きます。移行を機に「1分間隔が本当に要るテスト」を選別すると、実行数が半分以下になることは珍しくありません。逆に、監視対象が数本で、障害対応もチャット通知だけで回っているなら、乗り換えの手間に見合う効果は出にくい。

よくある質問

APIテストとブラウザテストはどちらから作るべきですか？

APIテストのHTTPテストからです。到達性・応答時間・状態コードという障害の大半を占める事象を、低い実行単価で拾えます。ブラウザテストは、ログイン後の画面や複数ページの遷移まで確かめる段階になってから追加してください。

プライベートロケーションは必ず用意する必要がありますか？

監視対象が公開エンドポイントだけなら不要です。マネージドロケーションから叩けます。社内ネットワーク内のAPIや管理画面を対象にする場合だけ、ワーカーを配置してください。公開前のステージング環境をCIから検証する用途なら、常設せずトンネル経由で済ませる選択肢もあります。

実行頻度を上げると費用はどれくらい変わりますか？

実行数に比例します。課金単位はAPIテストが1万実行あたり、ブラウザテストが1,000実行あたりで、実行数はロケーション数と間隔の掛け算です。5分間隔・2ロケーションから1分間隔・3ロケーションへ変えると、実行数はおよそ7.5倍になります。金額は契約形態で変わるため、公式の料金ページで時点を確かめてください。

テスト作成はUIとコードのどちらで管理すべきですか？

数本ならUIで足ります。10本を超えたあたりから、Terraformなどでの宣言的管理に寄せる価値が出ます。判断の目安は、テストの設定変更が誰の手でも起きうる状態を許容できるかどうか。監視の設定変更を履歴に残したい規模なら、コード管理へ移してください。

アラートが多すぎる場合はどこから直せばよいですか？

アラート条件の見直しが先です。リトライ回数を入れ、複数ロケーションの同時失敗を条件に加えるだけで、実行地点由来の誤報は大きく減ります。それでも残る場合は、アサーションを絞り込む。応答時間の閾値が実測の分布と合っていないケースが多く見られます。

関連記事

• 外形監視とは？内部監視との違いと監視項目・実装：製品を問わず外形監視という手法そのものを整理しています。監視項目の決め方から入る場合はこちらから。
• Datadogの使い方：アカウント作成からAgent導入、最初の監視を置くまでの手順です。Datadog自体がこれからならこちらが先です。
• Datadogの料金体系と費用が膨らむ課金単位：Synthetics以外も含めた課金単位の全体像と、費用を抑える設計を扱っています。
• Datadog運用のベストプラクティス：タグ設計と監視対象の絞り込み、アラート運用の型をまとめています。
• Datadog Agent導入の実装手順：内側からの計測を担うAgentの配置方法です。外形監視と組み合わせる前提の設計に使えます。