複数のWebサイトを運用していると、「どのサイトを監視しているか」「異常が出たら誰が確認するか」「サーバーやドメインの契約先はどこか」が別々の資料に散らばりがちです。複数サイトの死活監視を一元管理するには、監視結果を一覧にするだけでなく、サイトごとの正式URL・運用担当者・管理先・対応状況を一つの管理台帳で結び付けることが重要です。
まず「1サイトを1つの管理対象として識別する」ルールを決め、代表となる監視URL、一次担当と代替担当、サーバー・ドメイン管理先、サイトの運用状態を揃えます。そのうえで、監視結果が異常・監視不可・未計測になったときに、管理台帳から担当者と確認先をたどれるようにします。複数サイトが同時に失敗した場合は、共通サーバーやDNS事業者などの依存関係を見ると調査をまとめやすくなります。
この記事では、5サイト程度から数十サイト、さらに多数のサイトへ管理対象が増えた場合を想定し、サイト管理台帳の項目、URLの重複防止、担当分担、追加・変更・終了時の運用、複数サイトの異常を整理する手順を具体例と比較表で解説します。URLを個別に選ぶ細かな判断は監視URLの選び方、異常時の通知条件と連絡順はWebサイト監視のアラート設計で扱い、本記事は複数サイトの管理体制に集中します。
複数Webサイトの死活監視を一元管理するための基本設計
監視ツールを導入する前に、サイトをどの単位で登録し、誰の責任で管理するか決めます。管理対象を曖昧にしたまま登録を増やすと、同じサイトが二重に並ぶ、テスト環境が本番と混ざる、担当者の分からない警告が残る、といった問題が起こります。
「Webサイト」と「監視するURL」を分ける
例えば企業サイトhttps://example.com/には、トップページのほかに/contact/、/recruit/など多数のページがあります。URLが3つあるからといって、必ずしも管理すべきWebサイトが3件あるわけではありません。反対に、採用サイトが別ドメインに存在し、保守担当やサーバーが異なる場合は、管理上は別サイトとして扱う方が分かりやすいことがあります。
管理台帳では「サイトID・サイト名」を親にして、その下に代表URLと確認したい重要URLを列挙します。利用する監視サービスが同一サイト内の複数URLを個別監視できるかは、別途機能と契約単位を確認してください。管理台帳上のURL件数をそのままサービスの登録可能サイト数と同一視しないことが大切です。
本番・検証・休止中のサイトを区別する
公開中の本番サイトとステージング環境を同じ名前で登録すると、検証中の計画停止を本番障害と誤認することがあります。サイト名に「本番」「検証」などの区分を付け、一般公開の有無、監視の目的、運用責任者を管理します。テスト環境が非公開なら、外部から接続できないことが正常な場合もあります。
休止したサイトは、監視を止めるのか、利用者向けの告知ページだけ確認するのかを明確にします。監視失敗が続いている理由を知らない担当者が不要な調査を始めないよう、休止理由、承認者、再開予定日を残すと安全です。
管理画面の一元化と責任の一元化は別
複数サイトの状態が一つのダッシュボードに表示されても、すべてのサイトの復旧権限が一人に集まるとは限りません。サイトごとに開発会社、社内担当部署、ホスティング事業者が異なる場合、必要なのは「異常を見つける場所をまとめること」と「適切な担当者へ引き継げること」の両方です。
AWS Well-Architected Frameworkでも、アプリケーションやインフラなどの所有者と、その運用手順の責任者を明確にする考え方が示されています。単に監視対象の件数を増やすより、誰がどこまで対応できるかを記録しておく方が、障害時に役立ちます。
管理台帳に入れるべき10項目と記入例
複数サイトを見失わないための台帳は、複雑な資産管理システムから始める必要はありません。まず「サイトを特定する情報」「管理・連絡先」「現在の監視状態」の3つに分け、最低限の項目を共通化します。以下は説明用の例であり、実際の顧客サイトの情報ではありません。
| 管理項目 | 記入例 | 管理する理由 |
|---|---|---|
| 1．サイトID | SITE-001 | サイト名やURLが変わっても同じ管理対象を追跡 |
| 2．サイト名・用途 | 企業サイト・問い合わせ受付 | 利用者への影響を判断する |
| 3．正式URL | https://example.com/ |
監視する代表の入口を特定 |
| 4．追加の確認URL | /contact/ |
重要機能の入口を補助情報として整理 |
| 5．運用状態・環境 | 本番・公開中 | 検証や休止の誤認を防ぐ |
| 6．一次担当・代替担当 | Web運用担当・保守窓口 | 異常を誰が確認するか明確にする |
| 7．管理会社・契約先 | サーバー会社A・ドメイン会社B | 障害時の確認先と契約管理先を探せる |
| 8．共通基盤・グループ | サーバー共通群A | 同時異常の関連を調べる |
| 9．監視状態・直近確認日 | 監視中・最終確認日 | 未計測や設定放置に気づく |
| 10．手順書・変更履歴 | 社内手順書の参照先 | 担当交代と設定変更の根拠を残す |
サイトIDと正式URLを別々に持つ
サイトの正式URLはリニューアルやドメイン変更で変わることがあります。URLそのものを唯一の識別子にすると、旧URLの記録と新URLの記録が切れてしまう場合があります。台帳には変更されにくいサイトIDを持たせ、旧URLと新URLの変更履歴を対応づけると、過去の障害記録をたどりやすくなります。
ただしサイトIDは管理台帳上の便宜的な識別子です。エンリンクの管理画面で任意の独自IDを登録する機能があると断定するものではありません。まずは利用しているツールにあるサイト名やメモと、必要なら別の台帳を組み合わせてください。
サーバーとドメインの管理会社は分けて記載する
Webサイトの公開先サーバーと、ドメインの契約会社は異なることがあります。さらにDNSの管理事業者、CDN、メールの運用先が別の場合もあります。「管理会社」という一項目へ全部書いてしまうと、障害時に問い合わせ先を間違えやすくなります。
最初はサーバー契約先とドメイン管理会社を分け、複雑なサイトではDNS・CDNなども補足します。契約番号や管理パスワードなどの秘密情報を、閲覧者が多い台帳へそのまま記載しないでください。必要な担当者だけが権限に応じて参照できる保管先を別に用意する方が安全です。
担当者と連絡先には代替担当を設定する
一次担当が退職・異動したとき、アラートが誰にも確認されなくなることがあります。台帳には個人名だけでなく、「Web運用担当」「アプリ保守担当」などの役割と、実際に連絡を受ける担当者を対応づけておくと変更に強くなります。
営業時間、休日の扱い、委託契約の範囲も必要に応じて記録します。ただしアラート配信と自動エスカレーションは監視サービスの実装によります。役割表があるだけで次の担当者へ通知が自動送信されるわけではありません。
運用メモは短く、確認手順へたどれるようにする
メモ欄に長い障害対応マニュアルを貼り付けると、重要な情報が埋もれます。管理台帳には「担当部署」「管理会社」「重要な確認先」「手順書の保存場所」「最近の変更」を簡潔に記し、詳しい内容は適切な権限で管理する手順書へつなげる方が見つけやすくなります。
メモには作業に必要な事実を残し、個人のログイン情報・アクセストークン・顧客の機密データは書かないようにします。複数人で台帳を閲覧する場合は、誰がどの範囲を参照できるかも定期的に確認してください。
同じサイトやURLを二重に登録しないルール
管理対象が増えるほど、似たURLや旧ドメインが重複しやすくなります。監視一覧の数だけが増えても、同じ接続先を繰り返し確認しているだけなら管理品質は上がりません。新しいサイトを登録する前に、既存の台帳と照合するルールを作ります。
wwwあり・なしとHTTP・HTTPSを確認する
https://example.com/とhttps://www.example.com/が同じ公開ページへ転送されるサイトもあれば、別の用途で運用されるサイトもあります。http://からhttps://への転送も一般的です。文字列が違うだけで別サイトと数える前に、運営上の管理対象が同じか、最終的にどこへ到達するかを確認します。
どのURLを監視すべきかは、利用者へ正式に案内する公開URLと監視の目的によります。転送元の動作も重要なら別の確認対象として管理しますが、登録枠の単位や複数URLの扱いは製品によって異なります。重複と必要な多点監視を混同しないことが大切です。
リダイレクト・旧URL・キャンペーンURLを分類する
サイト移転後も旧ドメインが新ドメインへ転送されている場合、両方を同じ「本番サイト」として登録していると、異常の件数や対応担当が重複する場合があります。旧URLは「移転前URL」「転送の確認対象」のように目的を付け、正式な代表URLと区別します。
期間限定のキャンペーンや採用募集の終了後は、そのURLが404になることが正常な場合もあります。終了日と見直し担当を記録しておけば、公開終了後も古いURLを監視して不要なアラートを出し続ける問題を防ぎやすくなります。
管理権限のないURLを無断で監視しない
制作会社や保守担当者が複数の顧客サイトを扱うときは、監視対象に登録してよいか、契約や管理権限を確認します。一般公開されているURLでも、委託契約の範囲外で継続的なチェックや結果の共有を行ってよいとは限りません。
また、ログイン必須の管理画面や一時トークンを含むURLは、単純な公開HTTP監視に不向きです。外部アクセスだけでデータが更新・送信されるURLがないかも確認してください。対象選定の詳細は監視URLの選び方で解説しています。
サイト登録前に3項目で重複チェックする
追加する前に、①正式ドメイン、②最終到達URL、③運営上のサイト所有者を既存台帳と比較します。同じドメインでもサブドメインで別のサービスを提供するなら、運用責任や障害の影響に応じて別サイトとして扱うことができます。
逆に別ドメインでも運用実態が一体なら、同じグループに紐づける方法があります。大切なのはURL文字列だけで機械的に統合せず、利用者と運用担当者の目線で管理単位を決めることです。
複数サイトの監視一覧は「異常」「要確認」「停止中」で見る
一元管理のダッシュボードでは、サイトを名前順に並べるだけでなく、今どの状態にあるかを区別して確認することが重要です。特に監視不可や未計測を「正常」と混同すると、実際には把握できていないサイトを見逃します。
表示状態は監視の観測結果と運用状態で分ける
「正常応答」「障害の可能性」「監視不可」「監視停止中」などの表示は、別の意味を持ちます。正常応答は取得した検査が条件を満たしたこと、監視不可は確認できないこと、停止中は意図して監視を休んでいる可能性があることを表します。実際の表示名称と判定基準はツールごとに確認してください。
監視対象が正常に応答したとしても、ログインや申し込みなどの機能がすべて正常とは限りません。反対に「監視不可」だけでサイト全体がダウンしたとも断定できません。状態の意味を運用担当者全員で共有しておきましょう。
最初に確認する順番を揃える
多数のサイトを運用する場合、まず「利用者への影響が疑われるサイト」、次に「監視できていないサイト」、その後に「復旧の確認が必要なサイト」「正常なサイト」を見る順番が考えられます。事業への影響が大きいURLは、異常の件数が少なくても優先して確認します。
ただし一覧の自動ソートや高度な優先順位フィルターがエンリンクにあるとは、公開機能一覧だけでは断定できません。必要なら自社のチェック手順書に確認順序を記し、管理画面の状態別一覧から対象を探す方法で運用します。
未計測・確認待ちを正常欄に混ぜない
サイトが登録されていても、監視自体がまだ実行されていない、認証やアクセス制限で判定できない、監視処理が停止中といった理由で、実際の健康状態を評価できない場合があります。これらを正常件数に含めると、管理対象全体の状況を誤認します。
「監視した範囲で正常」「異常が疑われる」「取得できなかった」「計画的に停止」の区分を持ち、一覧と報告書で区別します。特に管理サイト全体の成功率を出すときは、観測できなかった区間を機械的に100％成功へ変換しないことが重要です。
色だけに頼らない状態表示にする
ダッシュボードで緑・赤などの色が使われていても、色だけで状態を区別すると、見間違えやすくなります。サイト名、取得時刻、正常・異常などの状態テキスト、HTTPコード、確認先を組み合わせると、担当者が根拠を把握しやすくなります。
数十サイトをまとめて見る場合は、アラートの最新日時や直近の状況を開いて確認し、古い検査結果を「現在の正常」と誤解しないようにします。ステータスの更新時刻がいつかを確認する習慣も大切です。
担当者・役割・編集権限を整理する方法
監視対象サイトが同じ管理画面にあると、担当者を追加して共同運用したくなることがあります。しかし閲覧できる範囲、サイト情報を編集してよい範囲、サーバー設定を変更する権限は別です。運用表とアカウント権限の両方で管理しましょう。
| 担当区分 | 主な確認内容 | 必要な権限の考え方 | 対応できない場合 |
|---|---|---|---|
| 一次確認・Web運用 | 監視結果・URL・発生時刻・画面の再確認 | まず閲覧権限を検討 | 保守担当へ事実を引き継ぐ |
| サイト情報の更新担当 | URL・運用メモ・サイト状態の更新 | 必要な範囲の編集権限 | オーナーへ編集依頼 |
| サーバー・アプリ保守 | ログ・構成・設定変更・復旧対応 | 別システムで承認された管理権限 | 基盤・開発の責任者へ |
| 事業責任者・契約担当 | 重要度・障害公表・契約先への判断 | 監視結果の閲覧と承認ルール | 定めた代理決裁先へ |
サイト担当とシステム管理者を混同しない
サイトの広報担当者が日常的に監視結果を確認していても、VPSを再起動したりDNSを変更したりする権限を持つとは限りません。運用台帳には、一次確認担当と復旧操作を行える担当を分けて記録します。
必要な管理権限は各サービス・契約の条件で決められます。監視結果を閲覧できることを理由に、サーバー認証情報を共有したり、外部へ代理連絡したりしない運用にしてください。
メンバーの編集・閲覧権限は最小限から考える
エンリンクの現行機能一覧には、メンバーを招待し、編集者または閲覧者の権限を設定する機能が案内されています。閲覧だけで足りる担当者には、その用途に合う権限を検討し、URLやメモの更新が必要な人だけを編集担当にする考え方が役立ちます。
ただし公開説明からは「担当者ごとに特定のサイトだけを見せる」などの細かなサイト単位アクセス制限を確認できません。複数の顧客サイトが同じ管理スペースにある場合は、閲覧範囲を実際の管理画面で確認する必要があります。顧客ごとに情報を分離したいときは、アクセス権限と契約条件を先に確認してください。
担当変更のときは台帳と権限を同時に更新する
担当者が異動したとき、台帳の担当者だけを変更しても、旧担当者のアカウント権限が残っている場合があります。担当変更では一次担当、代替担当、連絡先、作業手順書、サービスの閲覧・編集権限を一緒に確認します。
引継ぎの時点で未対応の障害や停止中のサイトがないか確認し、残件の担当も明確にします。招待を再送しただけで権限移行が完了したと見なさず、実際に新担当者が必要な情報を参照できることを確認しましょう。
複数サイトが同時に異常になったときの切り分け
異なるWebサイトで同時に失敗が出た場合、それぞれを独立した障害として調べる前に、サーバー・DNS・CDNなどの共通依存先を確認すると効率的です。ただし同じ時刻に失敗したことだけで、原因が同じだと断定してはいけません。
まずサイト別の時刻とエラーを並べる
例えば企業サイトA、採用サイトB、サービスサイトCが同時刻にタイムアウトした場合、各サイトの監視日時、HTTPコード、エラー種別、最後に正常だった時刻を並べます。時刻が数分ずれる場合は監視頻度やチェック実行時刻の違いも考慮します。
三つのサイトが同じ監視拠点から同時に失敗していたのなら、監視地点の通信経路や共通の名前解決基盤が関係している可能性もあります。監視結果は事実として保存し、原因候補は別に記録します。
共通サーバー・DNS・CDNでグループ分けする
台帳で共通のサーバー会社、ホスト、DNS管理先、CDNなどを記録しておくと、同時障害の関連性を確認しやすくなります。例えばサーバー群Aだけで異常が起きていれば、その群の公開状態や公式障害情報を優先的に確認できます。
一方で、同じDNS管理会社でも利用するゾーンや設定が異なれば、全サイトへ同じ影響が出るとは限りません。グループ分けは調査の入口であり、因果関係を自動で確定するものではありません。
公式障害情報とログを照合してから判断する
サーバー事業者やCDN事業者が障害・メンテナンス情報を公表している場合は、発生時刻と対象サービスを照合します。告知が出ていることだけで自社サイトが確実に影響を受けたとは断定せず、該当する契約やホストの情報まで確認します。
エンリンクの機能一覧には、対応するサーバー事業者の公式障害情報やメンテナンス情報を参照し、登録したホスト識別情報と照合する機能が説明されています。取得できない場合もあるため、一次情報の元ページや担当者の記録と突き合わせて判断してください。
一つの障害を複数担当で二重対応しない
複数サイトで同時に警告が出たとき、サイトごとに担当者が別々の設定変更や再起動を始めると、かえって復旧を難しくする場合があります。共通基盤での原因が疑われるときは、調査の取りまとめ役を決め、何を確認したかを一つの事象記録へ集約する方法が役立ちます。
ただし実際には別々の問題が同時に起きている可能性もあるため、影響したサイトと復旧確認は個別に行います。誰が確認し、誰が変更し、何を根拠に復旧と判断したかを残しましょう。
サイト追加・URL変更・休止・廃止の運用フロー
一元管理は初期登録よりも、その後の更新で品質が決まります。サイトが追加・移転・休止・廃止されるたびに管理台帳と監視設定の両方を見直し、使われなくなったURLが残らない仕組みを作ります。
追加：登録前の権限とURLを確認する
新しく管理するサイトが増えたら、運営者の許可、正式URL、管理会社、一次担当と代替担当を確認します。既存台帳で重複がないことを確かめたうえで、監視対象として追加します。サイト名が似ている場合も、ドメインと運用責任者を確認してから登録しましょう。
登録後は実際に監視が実行され、結果が取得できているかを確認します。「登録済み」と「監視結果を確認済み」は別の状態です。サイト追加時のチェック欄に、初回の応答確認日と担当者を記録すると後から追跡しやすくなります。
変更：旧URLと新URLの対応を残す
リニューアルやドメイン変更では、正式URL、サーバー契約先、担当者、監視対象などが同時に変わる場合があります。変更前の情報を消すのではなく、旧URLから新URLへの対応、変更日、作業担当、確認結果を記録しましょう。
新URLへ監視対象を変更したら、期待したHTTP応答が返るか、旧URLのリダイレクトが必要なら正しく機能するかを確認します。DNS反映やSSL証明書の問題がないかも重要ですが、それぞれの技術的な設定方法は別の専門記事で詳しく扱う方が混乱を避けられます。
休止：監視停止の理由と再開条件を残す
計画メンテナンスや長期間の事業休止では、定期監視を一時停止する運用が考えられます。ただし監視を停止した期間は結果が取得できなくなるため、その期間を「稼働率100％」と扱ってはいけません。開始日時、停止理由、承認者、再開予定を記録します。
エンリンクにはサイト別の監視停止・再開が案内されています。休止する際は監視機能の停止と、サイト自体の公開停止を混同しないでください。監視を再開した後は、取得結果を確認してから管理台帳の状態を更新します。
廃止：削除する前に保存・引継ぎの必要性を判断する
サイトを閉鎖する際、監視対象をそのまま放置すると404や接続失敗が繰り返し記録されることがあります。一方、すぐ削除すると過去の障害・契約・管理情報を振り返るための手掛かりを失う可能性があります。必要な情報の保存と、契約終了・ドメイン期限などの確認を済ませてから廃止を決めましょう。
エンリンクの機能一覧にはサイト情報をアーカイブへ移し、必要になれば復元できる機能が案内されています。ただしアーカイブしたときの監視停止やデータ保持期間などの細部は、実際の画面・利用規約・機能説明で確認してください。アーカイブ＝永続保存やバックアップの保証とみなさないことが重要です。
5サイト・20サイト・50サイト以上で変わる管理方法
管理するサイトの件数が増えた場合、最初に増やすべきなのは監視の機能よりも、管理単位と運用のルールです。5サイトでは個別に把握できても、数十サイトでは担当者・サーバー・顧客別の整理が必要になりやすくなります。以下は運用体制の例であり、法的な必須ルールや特定サービスの推奨体制を意味しません。
| 管理規模の例 | 優先したい整備 | よく起こる混乱 | 見直しの例 |
|---|---|---|---|
| 1〜5サイト | 正式URL・担当・サーバー契約先を明確にする | 担当者の記憶頼り | 月1回の台帳確認 |
| 6〜20サイト | 顧客・部署・公開環境で区分し、代替担当を決める | 担当未設定、重複URL | 追加・変更時のチェックを標準化 |
| 21〜50サイト | 共通サーバーや管理会社との対応、障害記録を集約 | 同時障害の二重対応 | 定期的な棚卸しと権限監査 |
| 51サイト以上 | 管理責任者・承認ルール・廃止フローを統一 | 顧客間の情報混在、属人化 | 役割と台帳の更新を継続運用 |
5サイトまでなら正しい台帳を先に整える
小規模な運用では、サービスの登録上限いっぱいにURLを埋めることより、正式な管理対象を漏れなく記録することを優先します。一次担当と代替担当、サーバー会社、ドメイン管理会社、監視状態が分かれば、障害が起きたときに確認先を探す時間を減らせます。
監視が正常な日も、最後の実行時刻やサイトの運用状態を確認する習慣を作りましょう。小規模の段階で「追加・変更・廃止時に必ず台帳を更新する」ルールを決めておくと、対象が増えても同じ方法を継続しやすくなります。
20サイト規模ではサイトの分類と代替担当が重要
同じ運営者が企業サイト、採用サイト、メディアを持つ場合や、制作会社が複数顧客を管理する場合、同じ担当者がすべての障害を処理できないことがあります。サイト用途、顧客、保守契約、運用責任者で分類し、誰が一次確認するかを明確にします。
顧客情報を共同管理する場合は、メンバーがどこまで閲覧できるかを確認してください。監視サービスの「サイト数上限」と「顧客ごとの完全なアクセス分離」が同時に提供されるとは限りません。情報共有の安全性を確認したうえで運用しましょう。
50サイト以上では共通基盤と変更管理を組み合わせる
数十サイトを監視していると、同じサーバーやDNS管理先を利用するサイトが複数ある場合があります。これらを管理台帳上でグループ化し、共通の障害時にまとめて確認できるようにすると、調査の重複を避けやすくなります。
また、サイトの移管、担当交代、URL変更が増えるため、変更日時・承認者・確認済みの内容を記録する方法が重要になります。運用手順に所有者を置き、定期的に見直す考え方はAWSの運用品質ガイドでも示されています。
規模が大きくなっても「一元管理＝自動復旧」ではない
監視情報を同じ画面へ集約しても、障害の原因を自動的に特定してサーバーを修正できるわけではありません。正しい監視結果を得られることと、その結果を見て担当者が安全に対応できることは別の運用です。
管理対象が増えるほど、全サイトへ同じ設定を機械的に適用するより、重要度、利用者影響、監視頻度、担当者の権限に応じて運用ルールを整理することが大切です。全サイトを一度に変更するような操作には、影響範囲の確認が必要です。
監視結果と「対応中・対応済み」の記録を分ける
監視一覧が正常表示へ戻っても、調査や報告が終わったとは限りません。逆に、担当者が対応を開始したとしてもサイトが復旧したとは言えません。複数サイトの運用では、機械が取得した監視状態と、人が対応した作業状態を別に記録します。
監視状態と作業状態を混同しない
例えば監視システムが「障害の可能性」と記録した事象について、一次担当が確認中なのか、二次担当へ引き継いだのか、復旧が確認できたのかを別に管理します。監視の失敗を記録した瞬間に「対応中」と自動表示される必要はありません。
エンリンクの管理画面内アラートには既読・未読の管理が案内されています。ただし、既読にしたことが復旧作業への着手・担当割当・自動エスカレーションを意味するわけではありません。作業状況が必要なら、対応記録や社内の管理表で補います。
障害記録はサイト別と事象別の両方からたどる
一つの障害で複数サイトへ影響した場合、各サイトの検査結果を個別に残しながら、共通の事象として調査記録をまとめると振り返りやすくなります。例えば事象番号INC-001へ、サイトA・B・Cの影響と個別復旧確認結果を紐づける方法です。
事象番号の付与やチケット管理がエンリンクに標準搭載されているとは確認できません。こうした方法は管理台帳側の運用例です。監視サービスが保持するチェック履歴と、担当者の作業記録を相互に参照できれば、調査の説明をしやすくなります。
管理画面での確認と外部連絡は分ける
複数サイトを扱う制作会社では、障害が起きたとき顧客へ連絡する必要があるか判断する場面があります。管理画面の状態を確認することと、顧客へ通知・謝罪・契約上の説明を行うことは別の権限に基づく行為です。
外部連絡が必要な場合は、契約上の対応範囲、責任者の承認、説明できる事実を確認してください。監視の一回の失敗だけから「サイト全体が完全停止した」と断定しないことも大切です。通知条件や連絡順の詳細はアラート設計の記事で扱っています。
複数サイトの管理で起こりやすい失敗と改善策
一元管理を始めた後も、URLの変更や担当交代が反映されなければ台帳は古くなります。特にサイト数が多い場合は、管理システムに登録されていることそのものではなく、実際に正しい情報で運用されているかを定期的に確認します。
サイトが重複登録され、アラートが二重に見える
wwwあり・なし、旧ドメインと新ドメイン、別の部署で管理していた同一URLなどが重複する場合があります。正式URLと管理IDを照合し、なぜ別々に登録しているのかを確認します。異なる目的で同じサイトを監視しているなら、その理由を台帳に記録してください。
重複を見つけたからといって、証拠を確認せず監視対象を削除しないようにしましょう。別の監視地点や別の重要機能を検査している可能性もあります。削除や統合の前に担当者と目的を確認することが大切です。
担当者不明のサイトだけ異常が放置される
管理画面に異常が表示されていても、誰の担当か分からなければ対応が進みません。サイトごとの一次担当、二次担当、代替担当、保守契約先を見直し、担当が決まっていないサイトを一覧化します。
担当不明の対象を「正常」として処理するのではなく、管理上の要確認項目として扱います。異動時のチェックリストに台帳更新と権限変更を入れるだけでも、属人化を減らすきっかけになります。
URL変更後の古い監視設定が残る
新しいWebサイトを公開したのに、監視対象が旧URLのままだと、旧URLの転送が成功しているだけで監視が正常に見えることがあります。あるいは旧URLが404となり、不要な異常が続くこともあります。正式URLと最終到達先を確認し、監視対象を変更してください。
変更した日は管理台帳に残し、実際の初回チェックが成功したことまで確認します。公開URL、監視URL、内部リンク、サーバー契約先のどれが変わったのかを明確にしておくと、次の調査が楽になります。
監視停止やアーカイブが放置される
メンテナンスで停止した監視を再開し忘れると、利用者に影響する障害が起きても新しい結果を取得できません。停止理由、開始日、再開予定、確認担当をセットで記録してください。
アーカイブしたサイトも、必要な管理情報を誰がいつ確認するか決めておくと、長期間の放置を防げます。サイトをアーカイブしただけでドメイン契約やホスティング契約が停止するわけではないので、別の手続きを忘れないようにしましょう。
エンリンクで複数サイトを一元管理する場合の機能と注意点
エンリンクの公開機能一覧には、Webサイトの登録・一覧管理、サイト名とURL、運用メモ、サーバー・ドメイン管理会社の情報、HTTP/HTTPSの定期監視、SSL証明書期限、監視履歴、管理画面内アラートなどが案内されています。ここでは実際に公表されている範囲を中心に、複数サイト運用での利用方法を整理します。
一覧からサイト別の監視状態を確認する
登録サイトごとに正常応答・障害の可能性・監視不可・停止中などの状態を一覧で確認し、気になるサイトの履歴や詳細を開くことができます。HTTPステータスや応答時間、SSL証明書の期限をサイト別に見られるため、異常の手掛かりを複数サイトの管理画面から探せます。
ただし、特定のURLを確認した結果はその観測地点・観測時刻・判定条件に限られます。トップページのHTTP監視が正常でも、問い合わせ送信やログイン成功まで保証するものではありません。必要な機能は別の確認方法と組み合わせてください。
サイト情報の整理・アーカイブ・担当者の閲覧権限
エンリンクでは、サイト種別やジャンル、サーバーサービスとホスト識別情報、ドメイン管理会社、運用メモなどを管理する機能が説明されています。またサイトのアーカイブ・復元、メンバーの招待、編集者・閲覧者権限の設定も案内されています。
ただし、記事中で提案したサイトID、顧客別の担当者自動割当、細かなサイト単位アクセス制限、障害チケット、外部連絡の自動エスカレーションを、エンリンクが実装済みと断定することはできません。現行の機能一覧を確認し、不足する管理項目は社内台帳や既存の運用手順で補ってください。
5・20・50・100サイトの料金プランを比較する
2026年10月23日時点の公式料金ページでは、無料プランは最大5サイト・1日2回、スタンダードは最大20サイト・15分ごと、ビジネスは最大50サイト・5分ごと、プロは最大100サイト・1分ごとと案内されています。定期監視の間隔はプランごとの最短値であり、実行時刻や障害検知までの時間を保証するものではありません。
| プラン | 登録サイト上限 | 定期監視の最短間隔 | 月額（税込） |
|---|---|---|---|
| 無料 | 5サイト | 1日2回 | 0円 |
| スタンダード | 20サイト | 15分ごと | 980円 |
| ビジネス | 50サイト | 5分ごと | 2,480円 |
| プロ | 100サイト | 1分ごと | 4,980円 |
ここでの「5サイト」「20サイト」などはエンリンクの登録サイト上限です。記事で例に出した「1サイトにある複数の重要URLを管理台帳に記すこと」と同じ意味ではありません。複数のページURLを個別の監視対象として登録できるか、契約や登録単位を確認したうえで使ってください。料金・機能は変更される可能性があります。
無料登録から小さく始め、台帳の運用を固める
まず公開中の代表サイトを登録し、サイト名・運用メモ・管理会社などの情報を整理します。定期チェックの結果が取得されているか、異常時にどの担当者が確認するか、サイト情報を変更したときの手順はどうするかを決めると、管理対象が増えても対応しやすくなります。
エンリンクは最大5サイトまで無料登録でき、利用期限なし・カード登録不要と案内されています。まずは実際の管理画面で、必要なサイト数・情報項目・権限の範囲が運用目的に合うか確認してください。高度な社内承認や顧客ごとの情報分離が必要な場合は、既存の業務ツールと組み合わせて設計することが重要です。
複数Webサイトの死活監視管理についてよくある質問
複数サイトをまとめて監視するときに、登録件数、URLの単位、担当者、アカウント共有などで迷いやすい点を整理します。細かな機能名や権限の設定方法は利用サービスによって変わるため、一般的な運用ルールと製品固有の機能を区別してください。
5サイトを一元管理する場合、トップページを5件登録すれば十分ですか？
最初の代表URLとしては考えられますが、それだけで問い合わせ・申込・ログインなどの動作がすべて確認できるわけではありません。どの重要な機能を確認したいかを台帳に記し、通常のURL監視で確認できない処理は別の安全な検査方法で補います。
複数サイトを同じ管理画面に登録すると担当者ごとに自動分配されますか？
すべての監視サービスがそうなるわけではありません。エンリンクの現行公開機能では、メンバー招待と編集者・閲覧者権限は案内されていますが、サイトごとの担当者自動割当や自動エスカレーションは確認できません。運用表で一次担当・代替担当を指定し、必要なら別のチケット管理を使います。
同じ会社が複数ドメインを持つ場合は一つのサイトにまとめますか？
運用上の責任、監視対象、利用者への影響に応じて判断します。企業サイトと採用サイトで管理先や担当者が違うなら、別の管理対象として区別した方が分かりやすい場合があります。同じ会社のサイトを顧客・部署というグループにまとめることと、監視対象を一件に統合することは別です。
一つのサイトにURLが複数ある場合、登録上限はどう数えますか？
監視ツールの課金・登録単位によって異なります。エンリンクの公式料金表は「登録できるサイト数」の上限を表示していますが、同じサイト内の追加URLがどう扱われるかは実際の利用条件を確認してください。台帳に多くのURLを記録することと、それらをすべて自動監視することを混同しないようにしましょう。
監視中のサイトを廃止する場合、すぐ削除しても大丈夫ですか？
必要な障害履歴や契約情報を確認したうえで判断します。監視を停止すること、サイトをアーカイブすること、契約を終了すること、ドメインを失効させることは別の手続きです。担当者と保存・削除の方針を決め、不要な監視や費用が残らないようにします。
全サイトの稼働率を単純平均してよいですか？
単純平均は計算できますが、サイトごとの監視間隔、観測対象、未計測の時間、利用者への影響が異なると誤解を招きます。まずはサイト別の成功率と停止記録を示し、何を集計した数字なのか明記してください。時間ベースの稼働率とチェック成功率の違いは稼働率の計算方法で解説しています。
制作会社が顧客サイトをまとめて監視するときの注意点は？
顧客ごとに監視の許可、情報の閲覧範囲、保守契約、障害時の連絡・作業権限を確認します。同じ管理スペースに登録できることと、顧客間の情報を安全に分離できることは別です。アカウントの閲覧権限、運用メモの内容、契約上の責任範囲を事前に確かめてください。
まとめ：複数サイトの監視はURL・担当・管理会社を一緒に管理する
複数Webサイトの死活監視を一元管理するには、監視結果を一覧で見るだけでなく、サイトごとの正式URL、運用状態、一次・代替担当者、サーバーとドメインの管理会社、共通基盤、変更履歴を結びつけることが大切です。監視で異常が見つかったとき、確認すべき対象と担当者を迷わず特定できる状態が管理の目標です。
新しいサイトの追加、URL変更、監視の休止・再開、廃止のたびに台帳を更新し、同じ監視対象の重複、担当不明、未計測、古いURLの放置を防ぎます。監視状態と人の対応状況を分け、共通基盤の障害が疑われるときは調査をまとめても、復旧確認はサイト別に行いましょう。
エンリンクでは複数サイトの一覧管理、HTTP監視、SSL証明書の期限、運用メモ、サーバー・ドメイン管理先などをまとめて確認できます。5サイトまで無料でエンリンクを始める場合も、まず登録対象と担当者を整理してから運用すると、監視結果を実際の対応へつなげやすくなります。
参考にした公式資料：AWS Well-Architected「運用プロセスの責任者」、AWS Well-Architected「リソースの所有者と責任分担」、Google Cloud「Cloud Monitoringのリソース分類」、Google Cloud「Dashboards overview」、Google SRE Workbook「Monitoring」（確認日：2026年10月23日）。
