はじめに
概要
本ドキュメントは、特定のWebサイトやドメインがどのCDN（コンテンツ配信ネットワーク）を使っているかを調べる方法をわかりやすく解説します。IPアドレスやDNS情報の読み方、digコマンドを使った具体的手順、Wappalyzerなどの自動ツールの利用法、導入後の動作確認まで、実務で役立つ手順をまとめています。
対象読者
- サイト運営者や開発者、インフラ担当の方
- CDN導入を検討中の方や、外部サイトの構成を把握したい方
初心者の方でも理解できるよう、専門用語は最小限にして具体例で補足します。
本書の進め方
章ごとに手順と確認ポイントを示します。まずは基本の調査方法（IP・DNS）を学び、次に自動化ツールや実際の検証方法へ進みます。作業は手元の環境で安全に行ってください。
注意点
公開情報を使った調査が中心です。相手のサービスに負荷をかける行為や不正アクセスは行わないでください。
CDNの判定方法：IPアドレスとDNS情報を活用した調査
概要
CDNかどうかを調べる基本は、ホスト名に紐づくAレコード（IPアドレス）とDNSの応答を確認することです。ここでは手順を分かりやすく説明します。
ステップ1：IPアドレスの確認（nslookup）
- コマンド例：nslookup example.com
- 表示されたIPアドレスを控えます。複数のIPが返る場合はCDNである可能性が高いです。
ステップ2：CNAMEとドメインパターンの確認
CNAMEがあればまず確認します。CNAME先に「edgesuite.net」「cloudfront.net」「akamai.net」などCDN特有のドメインがあればほぼCDNです。CNAMEがなくてもIPの所属（AS番号やレンジ）で判定できます。
ステップ3：判定と注意点
- 同一ドメインで頻繁にIPが変わる、TTLが短い、複数の地理的に分散したIPが見える場合はCDN利用の可能性が高いです。
- ただし、負荷分散やリバースプロキシでも似た挙動を示すため、AS情報やwhoisで運営者を確認してください。
digで権威DNSへ問い合わせる方法
権威サーバーを直接問い合わせるにはdigを使います。例：dig @ns1.example.jp example.com +short で公式の応答を確認します。+traceで名前解決の流れも追えます。
DNS名前解決の流れ（簡単）
クライアント→再帰DNS→ルート→TLD→権威DNS→応答、という順です。権威での応答が最終的な正解になります。
IPベース判定が信頼できる理由
IPの所属ネットワークやAS情報は運用側が変えにくい情報です。CNAMEが隠されている場合でも、IPの経路や地理分布からCDNを推測できます。注意点として、プライベートプロキシやWAFで覆われる場合は誤判断の余地があります。
Wappalyzerを使用した自動化された調査
Wappalyzerとは
Wappalyzerはブラウザ拡張やオンラインツールで、訪れたWebサイトが利用する技術を自動で検出します。CloudflareやAkamaiなどのCDNも判別できます。操作は簡単で初めての方にも使いやすいです。
インストールと基本操作
ChromeやFirefoxの拡張機能ストアから追加します。拡張を有効にして対象サイトを開くだけでアイコンが反応し、検出結果を一覧で表示します。結果はポップアップや詳細ページで確認できます。
検出の仕組みと精度
WappalyzerはHTTPレスポンスヘッダ、HTML内のコメント、JavaScriptやURLパターンを照合して判定します。つまり目に見える手がかりから推定する形です。ほとんどの場合正確ですが、カスタム設定やプロキシ経由では見落とすことがあります。
注意点と運用上のポイント
・検出は推定であるため、重要な判断は別手法で裏取りしてください。
・プライベートサイトや認証が必要なページは結果が出ない場合があります。
・定期的に拡張を更新すると精度が向上します。
実際の作業ではWappalyzerで素早く候補を洗い出し、必要に応じてIPやDNS調査を併用すると効率的です。
CDN導入後の動作確認方法
1. StagingサーバーのIP取得
digコマンドでStagingのIPを確認します。例：
dig +short staging.example.com
必要ならDNSサーバーを指定します。戻り値がIPv4/IPv6のアドレスです。
2. hostsファイルへ設定（ローカル向け切替）
管理者権限でhostsを編集します。例：
– Linux/Mac: /etc/hosts
– Windows: C:\Windows\System32\drivers\etc\hosts
行例：
203.0.113.10 www.example.com
保存後、DNSキャッシュをクリアしてください（例：Windows: ipconfig /flushdns、Mac: sudo killall -HUP mDNSResponder）。
3. ブラウザでの確認
ブラウザを開き、該当ドメインへアクセスします。開発者ツールのNetworkタブでステータスコード（200など）とヘッダを確認します。Akamai導入では“X-Cache”や“Server”といったキャッシュ関連ヘッダが出ることが多いので、応答ヘッダをチェックしてください。
4. curlでの詳細確認
curlでホストヘッダやSNIを保ったままIPへ投げるには–resolveが便利です。
curl -I --resolve 'www.example.com:443:203.0.113.10' https://www.example.com/
応答コード、Location、Cache-Control、Age、X-Cacheなどを確認します。
5. 自動テストスクリプト
簡単なBashやCIスクリプトで定期検証します。例：
status=$(curl -s -o /dev/null -w "%{http_code}" --resolve 'www.example.com:443:203.0.113.10' https://www.example.com/)
if [ "$status" != "200" ]; then exit 1; fi
応答ヘッダの有無やレスポンスタイムも収集しておくと安心です。
その他の確認方法
キャッシュルールの確認
CDNのキャッシュ設定を具体的に確認します。URLごとにキャッシュ可否、キャッシュキー（クエリやCookieの扱い）、ファイル拡張子別のTTLを見ます。例えばCSSは長め、HTMLは短めに設定するなど、用途に応じた振り分けを行います。
DNS設定の適正確認
CNAMEやAレコードがCDNプロバイダの推奨値になっているか確認します。DNS伝播後に正しいエンドポイントへ到達するかをnslookupやdigで確かめます。複数のリージョンで照会して一致するかをチェックします。
TTL（有効期限）のチェック
オリジンとCDN側のTTLを比較します。短すぎるとキャッシュ効果が薄まり、長すぎると更新反映が遅れます。目的別に典型値（例：画像は1週間、HTMLは数分〜数時間）を設定します。
コンテンツ一致とヘッダ確認
ブラウザやcurlで実際に取得し、レスポンスヘッダ（Age、Cache-Control、Viaなど）でCDN経由かを確認します。コンテンツの差分も確認し、圧縮や最適化が正しく適用されたかを見ます。
キャッシュ無効化と更新確認
キャッシュのパージやバージョン番号付与で更新が反映されるか試します。即時性が重要な場合はパージ手順を作業手順書に残します。
モニタリングとログ
CDNのリアルタイム統計やアクセスログでヒット率、エラー率、レスポンスタイムを監視します。しきい値を決めてアラートを設定すると安定運用に役立ちます。
実際のユーザー視点での確認
開発環境だけでなく、実際のネットワーク（モバイルや異なる地域）で表示速度や動作を確認します。ユーザーからの報告を受ける窓口を明確にしておくと対応が早くなります。
