こんにちは！開発チームのインフラ周りやオブザーバビリティ（可観測性）の向上、日々お疲れ様です。
システムが巨大化してくると、「パブリックなインターネットからはアクセスできないけれど、社内やVPC（仮想プライベートクラウド）の内部で稼働している重要なAPIやWebアプリが、本当に正しく動いているか」を外側から監視したくなりますよね。
「外部の死活監視ツールを入れたいけど、社内ネットワークの壁がある……」
そんな悩みを一発で、しかも非常にエレガントに解決してくれるのが、今回解説するDatadog合成監視（Synthetics）の「Private Location（プライベートロケーション）」です。
これをマスターすれば、閉域網の奥深くにあるシステムであっても、Datadogの美しいダッシュボードから一元的に、かつセキュアに外形監視できるようになります。毎日の障害対応や接続テストに怯える日々から解放されますよ。さあ、一緒にその仕組みと構築手順を紐解いていきましょう！
—
1. そもそも「Private Location」ってなに？（ツールの役割）
Datadogの合成監視（Synthetics）は、通常、世界中にあるDatadogのマネージドなロケーション（AWSなどのパブリッククラウド）から、あなたのWebサイトやAPIにリクエストを送り、応答速度やステータスコードを監視します。
しかし、社内LANや、外部から直接アクセスできないプライベートVPC内にあるAPIに対しては、パブリックなロケーションからは届きません。
そこで登場するのが Private Location です。
あなたの閉域網（オンプレミス環境やプライベートVPC）の中に、監視を実行する「専用のランナー（コンテナ）」をポツンとデプロイします。このコンテナが、以下のような動きをしてくれます。
1. 内側から外（Datadog）へ：「何かテストの指示はありますか？」とポーリング（定期的な確認）しに行く
2. ローカルで実行：指示されたAPIテストを、閉域網の内側から実行する
3. 外側へ結果を送信：「結果はこうでした！」とDatadogへ送り返す
つまり、ファイアウォールのインバウンド（外部からの侵入）を開ける必要が一切なく、アウトバウンドの通信だけでセキュアに外形監視が成り立つという、セキュリティエンジニアが泣いて喜ぶアーキテクチャになっています。
—
2. 全体像とネットワーク要件（要チェックポイント）
構築に入る前に、ネットワークの要件をしっかり押さえておきましょう。事故を防ぐための最も重要なポイントです。
通信の向き（超重要）
- インバウンド（Datadog ➔ 社内）： 不要（閉じたままでOK）
- アウトバウンド（社内 ➔ Datadog）： 必要
- Private Locationコンテナから、DatadogのAPIエンドポイント（`.datadoghq.com` など）へHTTPS（ポート443）で通信できる必要があります。
- プロキシ環境の場合は、コンテナからプロキシ経由で外に出られる設定が必要です。
必要なもの
- DockerまたはKubernetesが動く環境（今回は最も手軽なDockerをベースに解説します）
- Datadogのアカウントと、Syntheticsを実行できる権限
- Datadogの APIキー と アプリキー
—
3. ステップ・バイ・ステップ構築ガイド
それでは、実際にPrivate Locationを立ち上げ、社内APIのテストを動かすまでの手順をハンズオン形式で解説します。
ステップ1：Datadog上でPrivate Locationを作成する
まずは、管理画面から「俺たちの場所に監視用ランナーを置くぞ」という登録を行います。
1. DatadogのUIにログインし、左メニューの [UX Monitoring] ➔ [Synthetics] ➔ [Settings] ➔ [Private Locations] へ移動します。
2. 画面右上にある [New Private Location] をクリックします。
3. 必要な情報を入力します。
- Name: わかりやすい名前（例: `onpremise-tokyo-office` など）
- Description: 用途の説明
4. 作成を完了すると、画面に `DATADOG_API_KEY` と、そのPrivate Location固有の `SYNTHETICS_PRIVATE_LOCATION_KEY`（設定用キー）が表示されます。この2つをメモしておいてください。
ステップ2：コンテナ起動用の設定ファイル（Docker Compose）の作成
閉域網内のサーバー（または踏み台サーバー）にSSHでログインし、Private LocationのDockerコンテナを動かすための設定ファイルを用意します。
ここでは、管理が最も楽になる `docker-compose.yml` を使います。
version: ‘3.8’
services:
synthetics-private-location:
image: datadog/synthetics-private-location:latest
container_name: datadog-synthetics-pl
restart: always
environment:
# 1. DatadogのAPIキー
- DATADOG_API_KEY=your_datadog_api_key_here
# 2. ステップ1で発行されたPrivate Location用のキー
- SYNTHETICS_PRIVATE_LOCATION_KEY=your_private_location_key_here
# 3. Datadogのサイト（通常は us5.datadoghq.com や ap1.datadoghq.com など。日本リージョンなら datadoghq.com または ap1 等）
- DD_SITE=datadoghq.com
# 4. Private Locationの名前（ステップ1で設定した名前と一致させる）
- PL_NAME=onpremise-tokyo-office
# もし社内プロキシが必要な場合は以下をコメントアウトして設定してください
# and_proxy:
# – http_proxy=http://proxy.example.com:8080
# – https_proxy=http://proxy.example.com:8080
logging:
driver: “json-file”
options:
max-size: “10m”
max-file: “3”
ステップ3：コンテナの起動と疎通確認
設定ファイルを保存したら、いよいよコンテナを起動します。
バックグラウンドでコンテナを起動
docker-compose up -d
ログをリアルタイムで確認し、エラーが出ていないかチェックする
docker-compose logs -f
成功のサイン：
ログの中に、「Successfully registered」や「Polling for tasks…」といった文言が表示されれば大成功です！
DatadogのUI上の Private Location 一覧画面に戻ってみてください。ステータスが緑色（Online）に変わっていれば、無事にDatadogと社内ネットワークのランナーが手をつないだ証拠です。
—
4. 精度高い「HelloWorld」的APIテストの作成
無事にPrivate Locationがオンラインになったら、実際に社内APIをたたく外形監視（APIテスト）を作成しましょう。
今回は例として、社内にある「ユーザー認証API（`http://internal-api.local/healthz`）」を監視するシナリオを作ります。
1. Datadog UIの [Synthetics] ➔ [Tests] ➔ [New Test] ➔ [API Test] を選択します。
2. Requestの定義:
- Request Type: `HTTP`
- URL: `http://internal-api.local/healthz` （※もちろん、このコンテナから名前解決またはIPでアクセスできる必要があります）
- Method: `GET`
3. Locationsの選択（ここが肝心！）:
- ロケーションを選ぶチェックボックス一覧の中に、先ほど作成した Private Location (`onpremise-tokyo-office`) が表示されています。
- パブリックなロケーションのチェックを外し、Private Locationのみにチェックを入れます。
4. Assertions（アテスト・検証条件）の設定:
- APIが正常に動いているかを判定するルールを追加します。
- 例：
- Response Code ➔ `is` ➔ `200`
- Response Time ➔ `is below` ➔ `500 ms`
- Body ➔ `contains` ➔ `”status”:”healthy”`
5. Test Detailsの入力:
- Test Name: `[社内] 認証API ヘルスチェック`
- 実行頻度: `5分ごと` （重要度に応じて1分〜1時間に調整）
最後に [Save and Run] をクリックしてテストを保存します。
—
5. 動作確認と、現場で役立つ「ちょっとしたコツ」
テストが保存されると、数秒〜数分以内にPrivate Locationコンテナがタスクを拾い、社内APIへリクエストを飛ばして結果を持ち帰ってきます。
Syntheticsの detalhes（詳細）画面を開き、グラフやレスポンスタイムが綺麗に緑色で表示されていれば完璧です！
💡 現場で役立つプロの知見：DNSとルーティングの罠
Private Locationを導入したエンジニアが最初によくハマるのが 「DNSの名前解決」 です。
- コンテナが動いているサーバーから、監視対象のAPIのホスト名が正しく引けるか（`nslookup` や `curl` で確認）を必ず事前にテストしてください。
- 社内DNS（Internal DNS）を参照する必要がある場合は、Dockerのコンテナ起動時に `dns:` オプションを追加して、社内DNSサーバーのIPを指定してあげてください。
# 例：社内DNSを指定する場合
dns:
- 10.0.0.53
—
おわりに
いかがでしたでしょうか？
「閉域網だから外形監視は無理だろう」と諦めていた環境でも、Datadogの Private Location を使えば、たった数行のDocker設定とUIからのポチポチ操作だけで、非常に堅牢でモダンな監視網を構築できます。
これを導入しておけば、「社内APIがこっそり落ちていて、朝に出社してきた営業メンバーからクレームの電話で知る……」なんていう冷や汗をかくようなシチュエーションを、華麗に事前検知で防ぎ出すことができます。
あなたのシステムの「見えない死角」をなくす第一歩として、ぜひ今日の業務に取り入れてみてください。毎日の運用が、驚くほど安心で快適になりますよ！