金曜の夕方、サイトが3時間止まっていたことに気づいたのは月曜だった
ある製造業の会社で、実際にあった話です。社員60名ほどの企業で、数年前にリニューアルしたコーポレートサイトを運用していました。金曜の夕方にサーバーの問題でサイトが表示されなくなり、復旧したのは月曜の朝。情報システム担当が出社して初めて気づいたそうです。
その週末、展示会の出展案内ページを見ようとしたお客様が何人いたのか。問い合わせフォームから連絡しようとした取引先がいたのか。正確な数はわかりません。でも「ゼロではなかった」ことだけは確かです。
こうした事態を防ぐのが死活監視（しかつかんし）です。「サイトが正常に動いているか」を自動で定期的にチェックし、異常があればすぐに通知する仕組みのことです。
この記事では、ITの専門家でなくても理解できるように、死活監視の仕組みからツール選び、アラート設定の考え方まで、実務で使える知識をまとめました。
死活監視とは何をしているのか
死活監視は、やっていることは非常にシンプルです。外部のサーバーから、あなたのWebサイトに定期的にアクセスして、ちゃんと応答があるかを確認しているだけです。
たとえば、1分おきに「https://あなたのサイト.co.jp」にリクエストを送って、正常なレスポンス（HTTPステータスコード200）が返ってくるかを見ています。返ってこなければ「異常あり」としてアラートを飛ばします。
チェックする項目は主に4つあります。
HTTP応答の確認
最も基本的な監視です。Webサイトにアクセスして、正常なHTTPステータスコード（200番台）が返ってくるかを確認します。サーバーがダウンしている場合はもちろん、設定ミスで500エラーが出ている場合も検知できます。
応答時間の計測
サイトが表示されるとしても、表示に10秒かかっていたら実質的にはダウンしているのと変わりません。応答時間が一定のしきい値（たとえば3秒）を超えたら警告を出す設定が一般的です。
サイトの表示速度が遅いと、ユーザーの離脱率が大幅に上がります。表示速度の改善方法については、テックビルドの表示速度改善ガイドで詳しく解説しています。
SSL証明書の有効期限
SSL証明書の期限が切れると、ブラウザに「この接続は安全ではありません」という警告が表示され、ほとんどのユーザーがサイトから離脱します。証明書の有効期限を監視して、切れる前に更新できるようにしておくことが重要です。
DNS応答の確認
DNSが正常に機能しているかの確認です。DNSに問題があると、ドメイン名からサーバーのIPアドレスを解決できず、サイトにたどり着くことすらできません。サーバー自体は正常なのにサイトが見られない、という厄介な状況になります。
ダウンタイムのビジネスインパクトを数字で理解する
「うちのサイトが数時間止まっても、そんなに影響ないのでは」と思われるかもしれません。しかし、実際のところダウンタイムのコストは想像以上です。
情報処理推進機構（IPA）のセキュリティ関連調査でも、システム障害による事業への影響は重要な課題として指摘されています。
直接的な損失
ECサイトやお問い合わせフォーム経由で商談につながるBtoBサイトの場合、サイトが止まっている時間は文字どおり機会損失です。月間の問い合わせ件数を営業日で割れば、1日あたりの件数が出ます。1時間のダウンタイムがどれだけの問い合わせを逃すかは、簡単に試算できます。
信頼性の低下
取引先や顧客がサイトにアクセスした際に表示されないと、「この会社は大丈夫だろうか」という不安を与えます。特に新規取引を検討している相手にとって、サイトの信頼性はそのまま会社の信頼性と結びつきます。
SEOへの影響
Googleのクローラーがサイトにアクセスしたタイミングでダウンしていると、検索順位に悪影響を及ぼす可能性があります。Google検索セントラルの公式ドキュメントでも、サーバーエラーが続くとクロール頻度が下がることが説明されています。
監視ツールの選び方と主要サービスの比較
死活監視ツールは無料のものから有料のものまで数多くあります。中小企業がまず導入するなら、以下の3つの観点で選ぶのがおすすめです。
監視間隔がどれくらい細かいか。無料プランだと5分間隔、有料プランだと1分間隔が一般的です。ECサイトのように即時性が求められる場合は1分間隔が望ましいですが、コーポレートサイトであれば5分間隔でも十分です。
監視拠点がどこにあるか。日本国内からの監視に対応しているかは重要なポイントです。海外拠点のみだと、日本のユーザーにだけ発生している問題を見逃す可能性があります。
通知手段が自社に合っているか。メール、Slack、Microsoft Teams、SMS、電話など、どのチャネルで通知を受け取れるかを確認してください。
代表的な監視サービス
UptimeRobotは、無料プランでも50サイトまで5分間隔で監視できる定番のサービスです。設定が非常に簡単で、URLを入力するだけで監視が始められます。ダッシュボードで稼働率の履歴も確認できるため、初めて死活監視を導入する方に最適です。
Cloudflare Health Checksは、Cloudflareを利用しているサイトなら追加料金なしで使える監視機能です。Cloudflareの無料プランでも基本的なヘルスチェックが利用可能で、CDNやDNSの管理と一元化できるメリットがあります。Cloudflare無料プランの活用法と合わせて導入すると、コストを抑えながら堅牢な監視体制を構築できます。
Better Stack（旧Better Uptime）は、監視だけでなくインシデント管理やステータスページの作成まで一気通貫でできるサービスです。無料プランでも基本的な監視機能が使え、有料プランではオンコール管理（誰が何時に対応するか）の設定もできます。
Cloudflare Health Checksを使った監視の設定手順
Cloudflareをすでに利用している場合、最も手軽に始められるのがHealth Checks機能です。Cloudflareのダッシュボードから数クリックで設定できます。
ステップ1：ダッシュボードで対象を設定する
Cloudflareのダッシュボードにログインし、対象のドメインを選択します。左メニューから「Traffic」→「Health Checks」に進み、「Create」をクリックします。
監視対象のURLは、トップページだけでなく、問い合わせフォームや主要な商品ページなど、ビジネス上重要なページを指定してください。「/」だけだとトップページしか見ていないので、アプリケーション層の問題を見逃すことがあります。
ステップ2：チェック間隔と判定条件を決める
チェック間隔は60秒がおすすめです。判定条件として、以下を設定します。
- 期待するステータスコードは200に設定します
- タイムアウトは5秒にします。5秒以内に応答がなければ異常と判定されます
- リトライ回数は2回にします。1回の失敗で即アラートにせず、2回連続で失敗した場合にアラートを発します
リトライ回数を設定するのは誤報を防ぐためです。ネットワークの一時的な揺らぎでアラートが飛ぶと、オオカミ少年になってしまい、本当の障害時に反応が鈍くなります。
ステップ3：通知先を設定する
Cloudflareの通知設定（Notifications）で、Health CheckのアラートをメールやWebhookで受け取れるようにします。Cloudflare公式のNotifications設定ドキュメントに詳しい手順が載っています。Webhookを使えば、SlackやMicrosoft Teamsに直接通知を飛ばすことも可能です。
通知先は最低2名に設定してください。1名だけだと、その人が休暇中や移動中に気づけません。情報システム担当とその上長、あるいはWeb担当者と総務担当など、2名以上がアラートを受け取れるようにしておくことが大切です。
アラート設計で失敗しないための3つの原則
監視ツールを入れただけでは、実は十分ではありません。「アラートが来たけど誰も対応しなかった」「アラートが多すぎて無視するようになった」というのは非常によくある失敗パターンです。
原則1：アラートの重要度を分ける
すべてのアラートを同じ緊急度で扱うと、本当に重要なアラートが埋もれます。最低でも2段階に分けましょう。
緊急（Critical） はサイトが完全にダウンしている、またはSSL証明書が切れている場合です。即座に対応が必要なので、SMSや電話で通知します。
警告（Warning） は応答時間が通常より遅い、エラー率がわずかに上昇している場合です。翌営業日までに確認すればよいので、メールやSlackで通知します。
原則2：対応者と手順を事前に決めておく
アラートが来てから「誰が対応するんだっけ」と相談しているようでは遅すぎます。以下を事前に決めて、ドキュメント化しておいてください。
- 第一対応者として、最初にアラートを受けて状況を確認する人を決めます
- エスカレーション先として、第一対応者が対応できない場合の連絡先を明確にします
- 外部ベンダーの連絡先として、サーバーやインフラを外部に委託している場合の緊急連絡先を控えておきます
Cloudflareサービスの障害復旧ガイドも合わせて読んでおくと、いざというときの対応がスムーズになります。
原則3：定期的にアラートをテストする
監視ツールを設定したら、意図的にアラートを発生させて、本当に通知が届くかを確認してください。メールがスパムフォルダに入っていた、Slackの通知がオフになっていた、というのは意外とよくある話です。
月に1回、「テスト障害」としてアラートの到達確認をすることをおすすめします。消防訓練と同じで、実際にやってみないとわからない問題が必ず見つかります。
監視データを活用してサイトの品質を改善する
死活監視のもう一つの価値は、蓄積された監視データにあります。単に「落ちたかどうか」だけでなく、応答時間の推移を見ることで、サイトのパフォーマンス劣化を早期に発見できます。
応答時間のトレンドを見る
先月は平均200ミリ秒だったのに、今月は500ミリ秒に悪化している。このような変化は、日々のアクセスでは気づきにくいですが、監視データのグラフを見れば一目瞭然です。
応答時間が徐々に悪化している場合の主な原因は、データベースの肥大化、画像ファイルの増加、プラグインの追加などです。原因を特定して対処すれば、ユーザー体験の改善につながります。
稼働率をSLAの根拠にする
社内の他部門や経営層にインフラの品質を報告する際、「99.9%の稼働率を維持しています」という数字は非常にわかりやすい指標になります。月次で稼働率レポートを作成し、関係者に共有する習慣をつけると、インフラ投資の妥当性を説明する材料にもなります。
ちなみに、99.9%の稼働率とは月間で約43分のダウンタイムを意味します。99.5%なら約3.6時間です。この数字を知っておくと、自社のサイトにどの水準を求めるかを具体的に議論できます。
Google Search Consoleと合わせて確認する
Google Search Consoleの「カバレッジ」レポートには、Googleがサイトをクロールした際にエラーになったページの情報が記録されています。監視ツールのデータと突き合わせると、「あのときのダウンタイムがクロールエラーにつながったのか」という因果関係が見えてきます。
監視運用でよくある落とし穴とその対策
落とし穴1：監視対象がトップページだけになっている
トップページは正常でも、問い合わせフォームだけエラーが出ている、特定の商品ページだけ500エラーになっている、ということは珍しくありません。ビジネス上のクリティカルパスを洗い出して、そのすべてを監視対象に加えてください。
最低限、以下のページは監視対象にすべきです。
- トップページ
- 問い合わせフォーム（またはカートページ）
- 主要なランディングページ
- APIエンドポイント（外部連携がある場合）
落とし穴2：社内ネットワークからしか監視していない
社内のサーバーから自社サイトを監視している場合、社内ネットワークの問題とサイトの問題を区別できません。また、社内からはアクセスできるのに外部からはアクセスできない、という状況を検知できません。
死活監視は必ず外部のサービスを使ってください。前述のUptimeRobotやCloudflare Health Checksは、すべて外部からの監視です。
落とし穴3：アラート疲れで通知を無視してしまう
監視項目を増やしすぎたり、しきい値を厳しくしすぎたりすると、毎日のようにアラートが飛んできます。その結果、アラートが来ても「またいつものやつか」と思って無視するようになります。
これは非常に危険な状態です。対策として、以下を心がけてください。
- アクションが必要なものだけをアラートにする
- 情報として見ておきたいだけのものは、ダッシュボードで確認する運用にする
- 3日連続で無視されたアラートがあれば、しきい値を見直すか監視対象から外す
まとめ
死活監視は、特別な技術知識がなくても始められるインフラ管理の第一歩です。
この記事の要点を振り返ります。
- 死活監視とは、外部からサイトの応答を定期的にチェックする仕組みである
- ダウンタイムには、機会損失・信頼性低下・SEO悪化という3つのビジネスリスクがある
- 無料ツールでも十分に実用的な監視体制を構築できる
- 監視を入れるだけでなく、アラート設計と対応手順の整備がセットで必要になる
- 蓄積された監視データは、サイト品質の継続的な改善に活用できる
まずは来週、UptimeRobotの無料アカウントを作って、自社サイトのトップページを1つ登録してみてください。設定は5分もかかりません。「自分のサイトの稼働率が何%なのか」を知ることが、インフラ管理の最初の一歩になります。