ヘルスチェックとは？システム監視の仕組みと保守契約の確認点

「監視では異常を検知していません」。障害の報告書にこの一文を見つけたとき、多くの発注担当者は言葉に詰まります。同じ時間帯に利用者からは「画面が開かない」「ログインできない」という問い合わせが何十件も届いていたのに、監視上は正常だった。この食い違いをどう理解すればよいのか、そしてベンダーにどう問いただせばよいのか、判断の手がかりがないからです。

この状況がやっかいなのは、ベンダーが嘘をついているわけでも、手を抜いているわけでもないことが多い点にあります。ヘルスチェックは「設定された範囲で」正常応答を確認していただけであり、その範囲の外側で起きた障害は原理的に検知できません。つまり問題は監視の実行ではなく、監視の設計と、その設計を誰も合意していなかったことにあります。

そして設計に踏み込むには、ヘルスチェックが何をどこまで確認している仕組みなのかを、発注者側も自分の言葉で説明できる必要があります。実装できる必要はありません。「どの階層まで検査していますか」「異常と判定するまで何秒かかりますか」と質問し、返ってきた答えの妥当性を自分で評価できれば十分です。

本記事では、ヘルスチェックとは何かという定義から出発し、死活監視・外形監視との違い、ヘルスチェックの「深さ」による検知範囲の差、監視間隔としきい値の決め方、そして保守契約で確認すべき 7 つのポイントまでを、発注者が判断できる粒度で整理します。読み終えたときに、次の契約更新協議で提示すべき論点が手元に残る状態を目指します。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ヘルスチェックとは？システム監視における役割と基本の仕組み

ヘルスチェックの定義｜外部から定期的に問いかけて正常性を判定する

ヘルスチェックとは、システムが正常に稼働しているかどうかを、外部から定期的に問いかけて確認する仕組みです。監視する側が対象のサーバーやアプリケーションに一定間隔でリクエストを送り、返ってきた応答の内容と、あらかじめ決めた判定条件を突き合わせて「正常」「異常」を機械的に判断します。

人間の健康診断に例えられることがありますが、実態はもう少し単純です。健康診断が全身をくまなく調べるのに対し、ヘルスチェックは「決められた質問を投げて、決められた答えが返ってくるか」だけを見ています。質問の内容が浅ければ、返ってきた答えが正常でも、体調が悪いことは分かりません。この単純さこそが、後述する「監視は正常なのに障害が起きる」現象の根本原因です。

システム監視の全体像のなかでヘルスチェックが担うのは、一次検知の役割です。異常が起きたことに最初に気づき、アラートを鳴らす、あるいは異常なサーバーを自動的に切り離すという判断のトリガーになります。原因の特定や性能の分析は別の仕組みが担当します。

ヘルスチェックが動く4つのステップ

ヘルスチェックは、次の 4 ステップを繰り返しています。ベンダーの構成図に出てくる矢印の意味を理解するうえで、この流れを押さえておくと役に立ちます。

1. 問いかける：監視する側（ロードバランサー・監視サーバー・コンテナ基盤など）が、対象に対して一定間隔でリクエストを送ります。この間隔が「チェック間隔」です
2. 応答を受け取る：対象が決められた時間内に応答を返せば成功、返せなければ失敗と記録します。この待ち時間が「タイムアウト」です
3. しきい値で判定する：1 回の失敗で異常と決めつけると誤検知が増えるため、「何回連続で失敗したら異常とみなすか」という基準（異常しきい値）で判定します。復帰の判定にも同様に「何回連続で成功したら正常に戻すか」という基準（正常しきい値）を使います
4. 除外するか、通知する：異常と判定された対象を振り分け先から外す、コンテナを再起動する、担当者へアラートを送る、といったアクションを実行します

Google Cloud の公式ドキュメントでも、チェック間隔・タイムアウト・正常しきい値・異常しきい値の 4 つがヘルスチェックの基本パラメータとして定義されており、タイムアウトはチェック間隔以下の値にする必要があると明記されています（ヘルスチェックの概要 | Cloud Load Balancing）。用語や既定値はクラウド事業者ごとに多少異なりますが、この 4 パラメータの構造はほぼ共通です。

発注者がヘルスチェックを理解しておくべき理由

運用保守を外部に委託している場合、監視の設定はベンダーが行い、発注者が設定画面を触ることはまずありません。それでもヘルスチェックの仕組みを理解しておく価値があるのは、次の 2 つの理由からです。

ひとつは、ヘルスチェックが障害検知の起点であるためです。ヘルスチェックが異常を検知しなければ、アラートは鳴らず、担当者は動きません。「気づくのが遅かった」という障害の多くは、対応体制の問題ではなく検知設計の問題です。検知の設計に合意していなければ、対応の速さを契約で約束しても効果は限定的になります。

もうひとつは、稼働率 SLA の算定根拠になるためです。「稼働率 99.9% を保証します」という条項があっても、何をもって「停止」とカウントするかはヘルスチェックの判定結果に依存することが一般的です。ヘルスチェックが浅ければ、利用者から見て使えない状態が続いていても、記録上は稼働中として集計されます。SLA の数値だけを見て安心できない理由がここにあります。

ヘルスチェック・死活監視・外形監視の違いを整理する

ヘルスチェックについて調べていると、死活監視・外形監視という似た用語に必ず出会います。これらは排他的な分類ではなく、視点の違う言葉が混在しているため混乱しやすいところです。ベンダーが「監視しています」と言うとき、どの層を指しているのかを聞き分けられるよう、ここで整理しておきます。

死活監視とは｜Ping・ポート接続・プロセス確認で「生きているか」を見る

死活監視とは、対象が生きているかどうかだけを機械的に確認する監視です。代表的な手法は次の 3 つです。

• Ping 監視：サーバーに ICMP パケットを送り、応答が返るかを確認します。ネットワーク的に到達できるかだけを見ます
• ポート監視：指定したポート（Web なら 443 番など）に TCP 接続できるかを確認します。サービスが待ち受けているかまでは分かります
• プロセス監視：サーバー内部で特定のプロセスが起動しているかを確認します

死活監視は軽量で、設定も容易です。そのため運用保守の基本メニューとして必ず含まれています。一方で確認しているのは「電源が入っていて、ネットワークにつながっている」というレベルであり、アプリケーションが利用者にとって意味のある応答を返せているかは対象外です。

外形監視とは｜利用者と同じ経路から「使えるか」を見る

外形監視（合成監視・Synthetic Monitoring とも呼ばれます）は、インターネット上の外部拠点から、利用者と同じ経路でサービスにアクセスして確認する監視です。トップページが表示されるかを見るだけのものから、ログイン・検索・カート投入といった一連の操作を自動で再現し、想定どおりの画面遷移になるかまで確認するものまで幅があります。

外形監視の強みは、サーバーが正常でも利用者から使えない状態を検知できる点にあります。DNS の設定ミス、SSL 証明書の期限切れ、CDN の障害、社内からは見えるが社外からは到達できないネットワーク設定など、サーバー内部の監視では見えない問題を捉えられます。

一方で、外部から実行するため実行頻度を上げるとコストがかさみ、シナリオを作り込むほど画面改修のたびにメンテナンスが必要になるという運用上の負担があります。

3つの関係を1枚で整理する早見表

ヘルスチェックは、死活監視・外形監視と並列の概念ではありません。死活監視や外形監視で用いる手法を使って正常性を判定し、その結果を自動的な判断（振り分けからの除外・再起動・通知）に使う仕組みの総称がヘルスチェックです。つまり手法ではなく、目的と使われ方による呼び方の違いだと捉えると整理しやすくなります。

「監視は正常でした」という報告を受けたとき、最初にすべき質問は「どの監視の話ですか」です。死活監視しか実施していなければ、アプリケーション層の障害が見逃されるのは設計どおりの結果であり、責任を追及しても再発は防げません。防ぐには設計そのものを変える必要があります。

ヘルスチェックの「深さ」4段階｜どこまで見れば異常に気づけるのか

ここからが本記事の中心です。「監視は正常・サービスは異常」というギャップの正体は、多くの場合ヘルスチェックの深さの不足にあります。深さとは、どの階層まで検査しているかということです。

深さの4段階と、それぞれが見逃す障害

ヘルスチェックの深さは、おおむね次の 4 段階に整理できます。下に行くほど深く、検知できる範囲が広がります。

多くの障害報告で登場する「ヘルスチェックは正常応答を返していた」という状況は、第 2 段階または第 3 段階の設定で運用していたときに起こります。とりわけ第 3 段階は誤解を招きやすく、「HTTP で 200 が返っているのだから、アプリは正常に動いている」と受け取られがちです。しかし多くの実装では、ヘルスチェック用の URL は固定文字列を返すだけの軽い処理になっており、データベースに一切アクセスしません。結果として、データベースが落ちていても 200 が返り続けます。

Microsoft の設計パターン集でも、正常性チェックのパスはアプリケーションの重要なコンポーネントを確認すべきであり、アプリケーションがデータベースやメッセージングシステムに依存している場合は、正常性チェックのエンドポイントからそれらのコンポーネントに接続する必要があると明記されています（正常性エンドポイントの監視パターン | Microsoft Learn）。深さを上げることは、実装者の裁量ではなく設計上の要件だという位置づけです。

ヘルスチェックエンドポイントとは｜アプリに自己申告させる仕組み

第 3 段階以降を実現するために使われるのが、ヘルスチェックエンドポイント（正常性エンドポイント）です。これは監視されるためだけに用意された専用の URL で、アクセスされると自分自身の状態を点検して結果を返します。/health や /healthz といったパスが慣例的に使われます。

実務では、深さの異なるエンドポイントを 2 種類用意する構成がよく採られます。

• 浅いエンドポイント（例：/health）：アプリケーションのプロセスが応答できることだけを確認します。処理が軽いため、ロードバランサーが数十秒おきに高頻度で叩いても負荷になりません
• 深いエンドポイント（例：/health/deep）：データベースへの接続確認、外部 API への疎通確認、ストレージへの書き込み確認などを実行し、依存先を含めた総合的な状態を返します。処理が重いため、実行頻度を落として監視ツールから利用します

この 2 段構えは、負荷と検知範囲のバランスを取るための設計です。ベンダーの説明に「ヘルスチェック用のエンドポイントを用意しています」という言葉が出てきたら、そのエンドポイントが依存先まで検査しているのか、それとも応答を返すだけなのかを確認してください。ここが分岐点になります。

なお、深いエンドポイントには注意点もあります。依存先を厳密に検査しすぎると、外部 API の一時的な不調でアプリケーション全体が異常と判定され、正常に動いている機能まで停止させてしまうことがあります。「どの依存先が落ちたら全体停止とみなすか」は、業務上の重要度に応じて切り分ける必要があり、これは技術判断であると同時に業務判断でもあります。

アクティブ型とパッシブ型｜問いかけるか、結果から判断するか

ヘルスチェックには、判定の材料をどこから得るかによる 2 つの型があります。

アクティブ型は、監視する側が定期的にリクエストを送って応答を確認する方式です。一般に「ヘルスチェック」と言われて想像されるのはこちらで、利用者のアクセスがない時間帯でも異常を検知できるという利点があります。

パッシブ型は、実際の利用者トラフィックの処理結果を観察し、エラーが一定割合を超えたら異常とみなす方式です。専用のリクエストを送らないため負荷が増えず、しかも「実際の利用者が受け取っている結果」を直接見ているため、判定の現実味が高いという利点があります。一方で、利用者のアクセスが少ない時間帯には判定材料が集まらず、検知が遅れます。

両者は排他ではなく、組み合わせて使うのが一般的です。契約協議では「アクティブ型は何秒間隔で、どの深さで実施しているか」に加えて、「エラー率の上昇を検知する仕組みはあるか」を確認しておくと、深さの不足を別の角度から補えているかどうかが見えてきます。

「正常応答なのに障害」が起きる3つの典型パターン

深さの話を、具体的な障害の形に落とし込んでおきます。次の 3 パターンは、監視上は正常のまま利用者が困る典型例です。

パターン1：ステータスコードは 200 だが、画面の中身が壊れている

サーバーサイドは正常に HTML を返しているものの、参照している JavaScript や CSS の配信が失敗し、利用者の画面は真っ白になっている、というケースです。ステータスコードだけを見るヘルスチェックは正常と判定します。これを検知するには、応答本文に特定の文字列が含まれているかを確認する設定や、ブラウザ上で描画まで再現する外形監視が必要です。

パターン2：ヘルスチェック用の URL だけが軽く、業務処理は失敗している

ヘルスチェック用の URL が固定文字列を返すだけの実装になっており、データベース接続が切れていても 200 を返し続けるケースです。利用者は一覧画面を開いた瞬間にエラーになりますが、監視は最後まで正常のままです。前述の深いエンドポイントを用意していない場合に起こります。

パターン3：一部のサーバーだけが異常で、全体としては応答している

複数台構成で 1 台だけが異常な状態に陥り、ロードバランサーがそれを検知できずに振り分けを続けているケースです。利用者から見ると「たまにエラーになる」「再読み込みすると直る」という再現性の低い症状になり、問い合わせを受けても再現できず、監視上も全体では正常に見えます。ヘルスチェックの深さが浅く、異常なサーバーが「生きている」と判定され続けることが原因です。

いずれのパターンも、ベンダーに投げるべき質問はひとつに集約できます。「ヘルスチェックはどの階層まで検査していますか。データベースや外部 API の状態は判定に含まれていますか」です。

ヘルスチェックが使われる3つの場面

同じ「ヘルスチェック」という言葉でも、実施しているのが何かによって目的が変わります。ベンダーの構成図や説明資料に出てくる用語を読み替えられるよう、代表的な 3 つの場面を整理します。

ロードバランサーのヘルスチェック｜異常なサーバーを振り分けから外す

複数台のサーバーにアクセスを振り分けるロードバランサーは、振り分け先が正常かどうかを常時確認しています。異常と判定したサーバーには新しいアクセスを送らなくなり、正常に戻れば振り分けを再開します。目的は利用者を壊れたサーバーに当てないことです。

AWS の Application Load Balancer では、指定した間隔ごとに各ターゲットへヘルスチェックのリクエストを送り、連続失敗が異常しきい値に達したターゲットをサービスから外し、連続成功が正常しきい値に達したら復帰させるという動作が公式に定義されています（Health checks for Application Load Balancer target groups |…）。Google Cloud も同じ 4 パラメータの構造を採っています。

ここで重要なのは、ロードバランサーのヘルスチェックはアラートを鳴らすための仕組みではないという点です。1 台を切り離して残りで処理を続けられていれば、利用者への影響が出ないまま静かに縮退運転していることもあります。逆に全台が異常と判定されると、振り分け先がなくなり全面停止になります。「異常なサーバーが切り離されたとき、誰かに通知は飛びますか」は確認しておきたい論点です。

Kubernetesの3つのプローブ｜起動・投入・再起動で判定を分ける

コンテナ基盤である Kubernetes は、ヘルスチェックを目的別に 3 種類に分けています。ベンダーの説明で「プローブ」という語が出てきたら、この 3 つのどれかを指しています。Kubernetes 公式ドキュメントの定義は次のとおりです（Liveness, Readiness, and Startup Probes | Kubernetes）。

分けている理由は、対処が違うからです。一時的に処理が混み合って応答できないだけなら、アクセスを止めて待てば回復します。ここで再起動してしまうと、処理中のリクエストが失われ、復旧はかえって遅くなります。逆に内部で行き詰まって自力で回復できない状態なら、待っても意味がなく再起動が必要です。

起動に時間のかかるアプリケーションで Startup Probe を設定していないと、起動途中に「応答しない」と判定されて再起動され、また起動途中で再起動される、という無限ループに陥ることがあります。コンテナ基盤を採用しているシステムでは、「3 つのプローブを目的別に分けて設定していますか」という質問がそのまま設計の成熟度を測る指標になります。

監視ツール・監視サービスによるヘルスチェック｜通知とレポートが目的

3 つ目は、監視ツールや外形監視サービスによるヘルスチェックです。ロードバランサーやコンテナ基盤のヘルスチェックが自動的な処理判断のために動くのに対し、こちらは人に知らせ、記録に残すことが目的です。

具体的には、異常を検知したときにメール・チャット・電話などで担当者へ通知する、稼働率を集計してレポートにする、障害の発生時刻と復旧時刻を記録する、といった役割を担います。稼働率 SLA の根拠データは通常この層で集計されるため、保守契約の観点ではもっとも直接的に関わる部分です。

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

監視間隔・タイムアウト・しきい値の考え方｜誤検知と検知漏れのトレードオフ

「何分おきに監視していますか」という質問は、発注者からよく出るものです。しかし返ってきた数字が妥当かどうかは、間隔だけを見ても判断できません。判断するには、4 つのパラメータの関係を理解する必要があります。

4つのパラメータが意味すること

前述のとおり、ヘルスチェックの挙動は次の 4 つで決まります。

この表から分かるとおり、すべてのパラメータに「早く気づく」と「間違えない」のトレードオフがあります。「監視間隔は短ければ短いほどよい」という単純な話ではないことが、数字の妥当性を判断するうえでの出発点です。

検知までの最長時間を概算する｜自社の許容ダウンタイムと突き合わせる

パラメータの妥当性を評価するには、それらを合成して検知までの最長時間に変換します。障害が発生した直後にはチェックが走っていない可能性があるため、最悪のケースでは次のような時間がかかります。

検知までの最長時間 ≒ チェック間隔 × 異常しきい値 ＋ タイムアウト

たとえばチェック間隔 30 秒、異常しきい値 3 回、タイムアウト 5 秒という設定であれば、30 × 3 ＋ 5 で約 95 秒、およそ 1 分半かかる計算になります。これはあくまで概算で、製品によって細部の挙動は異なりますが、桁数の感覚をつかむには十分です。

そして人が動き出すまでには、ここにさらに時間が加わります。

利用者が困り始めてから対応が始まるまで ＝ 検知までの最長時間 ＋ 通知が届くまでの時間 ＋ 担当者が着手するまでの時間

検知に 1 分半、通知に 1 分、担当者の着手までに夜間で 30 分かかるなら、合計で 30 分以上です。これを自社が許容できるダウンタイムと突き合わせます。判断の目安として、稼働率と月間の停止許容時間の対応を挙げておきます（30 日換算）。

稼働率 99.9% を約束しているのに、夜間の一次対応着手が 30 分後という体制であれば、障害が 1 回起きただけで月間の許容時間の大半を消費します。SLA の数値と、検知・通知・着手の実時間が整合しているかを確認することが、契約協議での実質的な論点になります。

短すぎる設定と長すぎる設定、それぞれの副作用

パラメータを詰める方向に振り切ると、別の問題が出てきます。

短すぎる設定の副作用として代表的なのが、正常と異常の判定が短時間で行き来する状態（フラッピング）です。負荷が高まった瞬間に応答が遅れて異常と判定され、切り離された結果として負荷が下がり正常に戻り、振り分けが再開されてまた高負荷になる、という振動が起こります。振り分け先が入れ替わり続けるため、利用者から見ると断続的にエラーが出ます。

また、通知が過剰になることも実害を生みます。誤検知のアラートが日常的に届くようになると、担当者は次第にアラートを読まなくなり、本物の障害を見落とすようになります。監視の質は、通知の量ではなく通知の的中率で測るべきものです。

長すぎる設定の副作用は単純で、検知が遅れます。チェック間隔 5 分・異常しきい値 3 回という設定であれば、最悪で 15 分以上気づけません。加えて、間隔が長いほど「一瞬だけ落ちて復旧した」という短時間の障害はチェックの合間に収まってしまい、記録にすら残りません。利用者からの問い合わせが数件あったのに監視ログには何も残っていない、という状況はここから生まれます。

適切な値は、システムの性質と許容ダウンタイムによって変わります。発注者として持つべき問いは「何秒が正解か」ではなく、「なぜその値にしているのか、根拠を説明できるか」です。

保守契約でヘルスチェックについて確認すべき7つのポイント

ここまでの内容を、契約協議で使える形に落とし込みます。以下の 7 項目は、保守契約や運用委託契約の監視条項で確認・明記しておきたい論点です。なお請負・準委任といった契約類型そのものの選び方については、システム保守契約の種類と内容で扱っています。本記事では監視条項の中身に絞ります。

監視対象の範囲｜サーバー単位か、画面・API単位か

まず確認すべきは、何を監視対象としているかです。「サーバー 3 台」という台数ベースの記載しかない契約は少なくありませんが、利用者が使うのは画面や機能であり、サーバーではありません。

• 質問文例：「監視対象はサーバー単位ですか、それとも利用者が使う画面や API の単位ですか。ログイン機能や決済機能は個別に監視されていますか」
• 合意しておきたい粒度：監視対象を「サーバー名」ではなく「対象の URL・エンドポイントの一覧」として別紙に列挙する。機能追加時に監視対象を追加する手続きも明記する

チェック方式と深さ｜依存先まで検査するか

本記事の中心論点です。深さが浅ければ、他をどれだけ整えても「監視は正常・サービスは異常」は再発します。

• 質問文例：「ヘルスチェックは Ping・TCP・HTTP・依存先込みのどの階層で実施していますか。データベースや外部 API の状態は判定に含まれますか」
• 合意しておきたい粒度：監視対象ごとに検査階層を明記する。深いエンドポイントを用意する場合は、どの依存先を検査対象に含めるかを一覧化する

監視間隔・しきい値と、検知までの最長時間

数値そのものより、数値から導かれる検知時間を合意することが実質的です。

• 質問文例：「チェック間隔・タイムアウト・異常しきい値の設定値はいくつですか。その設定だと、障害発生から異常と判定されるまで最長で何分かかりますか」
• 合意しておきたい粒度：パラメータの設定値と、そこから算出される検知までの最長時間を数値で記載する。変更する場合の通知義務も定める

検知後の通知フローと一次対応｜誰に・いつ・どの時間帯まで

検知しても人が動かなければ復旧は始まりません。ここは監視の話というより体制の話ですが、監視条項とセットで確認する必要があります。

• 質問文例：「異常を検知したあと、誰に何分以内に通知されますか。夜間や休日も同じですか。一次対応として何を実施していただけますか。発注者側への連絡はどのタイミングですか」
• 合意しておきたい粒度：対応時間帯（平日日中のみか、24 時間 365 日か）、通知先と通知手段、一次対応の着手目標時間、実施する対応の範囲（再起動までか、原因調査まで含むか）を明記する

稼働率SLAの計測方法｜何をもって「停止」とカウントするか

稼働率の数値だけを見ても意味がなく、計測方法とセットで初めて評価できます。

• 質問文例：「稼働率はどの監視結果を根拠に算出していますか。どの状態から停止とカウントされますか。計測の単位時間は何分ですか。目標を下回った場合の措置はありますか」
• 合意しておきたい粒度：計測に用いる監視の種類と対象、停止と判定する条件、集計の単位（分単位か時間単位か）、計測期間、目標未達時の取り扱いを記載する

計画メンテナンス時の監視除外の扱い

計画的な作業中に監視を止めることは通常の運用ですが、除外の手続きが曖昧だと、戻し忘れて監視が止まったままになる事故につながります。

• 質問文例：「メンテナンス時に監視を除外する手順はどうなっていますか。除外の開始と解除はどのように記録されますか。稼働率の集計から除外される時間はどう扱われますか」
• 合意しておきたい粒度：除外の申請・承認・解除確認の手順、除外時間の稼働率への反映方法、事前通知の期限を定める

監視レポートの提供頻度と内容

監視は実施していても、結果が発注者に共有されていないケースは珍しくありません。共有されて初めて、設定の見直しという議論が成立します。

• 質問文例：「監視結果のレポートはどの頻度で提供されますか。アラートの発生件数や誤検知の件数も含まれますか。設定変更の履歴は残りますか」
• 合意しておきたい粒度：提供頻度（月次など）、レポートに含める項目（稼働率・障害件数・アラート件数・誤検知件数・対応時間の実績・設定変更履歴）を明記する

契約協議用チェックリスト

以上の 7 項目を、協議の場で確認できる形にまとめます。

すべてを一度に契約へ盛り込む必要はありません。過去に発生した障害の性質を振り返り、どの項目が欠けていたために検知できなかったのかを特定し、優先順位をつけて協議に臨むのが現実的です。

ヘルスチェックだけでは足りない領域と、次に検討すべきこと

最後に、ヘルスチェックの限界を明確にしておきます。深さを上げれば何でも解決するわけではなく、投資の順序を誤ると効果が出ません。

ヘルスチェックが検知できない3種類の異常

ヘルスチェックは「異常が起きたことに気づく」仕組みであり、「なぜ起きたかを説明する」仕組みではありません。そして次の 3 種類は、深さを上げても捉えにくい領域です。

性能劣化：応答は返っているものの、表示までに 10 秒かかるといった状態です。タイムアウトの設定値を超えなければ正常と判定されます。利用者にとっては実質的に使えない状態でも、稼働率の集計上は稼働中です。

部分的なエラー率の上昇：全体の 5% のリクエストだけが失敗している状態です。ヘルスチェックのリクエストがたまたま成功する側に入れば、正常と判定され続けます。パッシブ型の仕組みやエラー率の監視がなければ気づけません。

特定の条件下だけで起きる障害：特定のブラウザ、特定の権限のユーザー、特定のデータを持つアカウントだけで発生する不具合です。ヘルスチェックは決まった条件で決まった検査をするため、条件から外れた事象は原理的に対象外になります。

ログ・メトリクス・トレースとの役割分担

これらの領域をカバーするのが、ログ・メトリクス・トレースといった仕組みです。ヘルスチェックが「異常が起きた」という一次検知を担い、ログやメトリクスが「いつ・どこで・何が起きたか」を記録し、トレースが「どの処理のどの区間で時間がかかったか」を追跡します。

投資の順序としては、まず一次検知を確実にし、そのうえで原因究明の仕組みを整えるのが合理的です。検知できていないシステムに詳細な分析基盤を導入しても、そもそも調査の起点が生まれません。逆に、検知だけできて調査手段がなければ、復旧のたびに手探りになります。

障害発生時の確認手順やアラート設計を含む監視全体の考え方はログ管理・モニタリングで整理しています。一次検知の先にある原因究明の仕組みと、それを保守契約にどう組み込むかについてはオブザーバビリティと監視の違いを参照してください。

監視する側が落ちるリスクへの備え

見落とされやすいのが、監視する仕組み自体の可用性です。監視サーバーが停止していれば、対象がどれだけ壊れていてもアラートは鳴りません。そして「アラートが鳴らない」ことは「正常である」ことと区別がつきにくいため、発覚が遅れます。

Microsoft の設計パターンでも、監視エージェントが正しく動作していることを確認する手法として、検査用の値を返すエンドポイントを公開し、監視システム自体をテストできるようにする方法が挙げられています（正常性エンドポイントの監視パターン | Microsoft Learn）。

契約協議では、「監視サーバー自体が停止した場合、それはどうやって検知されますか」という質問を加えておくと安心です。定期的に監視の生存を知らせる通知を送る、監視基盤を冗長化する、外部サービスと自社基盤の二重構成にするなど、備え方はいくつかあります。

まとめ｜契約更新前に確認したい3つの論点

ヘルスチェックとは、システムが正常に稼働しているかを外部から定期的に問いかけて確認する仕組みであり、システム監視における一次検知を担う役割です。そして「監視は正常なのにサービスは使えない」というギャップの多くは、監視の実行ではなく監視の設計に起因します。

契約更新の協議に持ち込むべき論点は、次の 3 点に集約できます。

1. 深さ：ヘルスチェックはどの階層まで検査しているか。データベースや外部 API といった依存先の状態は判定に含まれているか。ここが浅いままでは、他をどれだけ整えても同じ見逃しが再発します。

2. 検知までの時間：チェック間隔・タイムアウト・異常しきい値から算出される検知までの最長時間は何分か。その数値は自社が約束されている稼働率と整合しているか。

3. 検知後の一次対応：誰に何分以内に通知され、どの時間帯まで、どこまでの対応が実施されるか。発注者側への連絡はどのタイミングか。

次のアクションとして、まず手元の保守契約書を開き、監視に関する条項がこの 3 点に触れているかを確認してみてください。触れていない項目があれば、それが次の協議で埋めるべき空白です。そのうえで本記事のチェックリストをもとに質問状を作成すれば、ベンダーとの議論は「監視をもっと手厚くしてほしい」という漠然とした要望ではなく、項目ごとの具体的な合意形成に変わります。追加費用が提示された場合も、どの項目の対価なのかが明確であれば、投資対効果を自分で判断できるようになります。

関連情報

システムの運用保守や外部委託の進め方について、体系的に整理した資料をご用意しています。社内での検討や稟議の資料としてお使いいただける内容です。お役立ち資料の一覧からご覧いただけます。

監視と保守契約について、さらに詳しく知りたい方は以下の記事もあわせてご覧ください。

• システム保守契約の種類と内容
• ログ管理・モニタリングとは
• オブザーバビリティとは

—Free Download / 資料ダウンロード

失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること

システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。

こんな方におすすめです

• 現在の保守会社のサービスに不満を感じている方
• 保守会社の変更を検討しているが、何から始めればよいか分からない方
• 引継ぎ作業でトラブルを避けたい方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。