◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- サーバーの起動だけを見る死活監視では、サイトは開くのに発注だけ通らない状態を検知できないため、発注操作をなぞる外形監視を軸に据える
- 監視の範囲を決めないまま当番表を作っても、当番が見る画面に異常が出ないため検知は早まらない
- 委託を検討するときは、機器の台数と外形監視でなぞる経路を分けて数え、検知後どこまでが契約範囲かを確認してから見積もりを比べる
- 通知は経路を複数持ち、一定時間応答がなければ次の手段へ進む段階を決めておく
- 稼働率は何をもって稼働とみなすかを先に決め、外形監視の記録と照らして取引先へ説明できる形にする
目次
深夜・休日の障害に気づけないと何が起きるか
金曜の夕方に取引先の購買担当者が発注しようとしたら、確定ボタンを押した先でエラーが返る。
連絡しようにも営業時間外で、こちらがそれを知るのは月曜の朝に届いた問い合わせの電話から——。
こうした検知の遅れは担当者の注意不足ではなく、サーバーが起動しているかどうかだけを見る監視では「動いているのに注文できない」状態を拾えないところから生まれます。
見直しの起点になるのは、実際の発注操作をなぞって外側から確認する外形監視を軸に据えることです。
そのうえで、自社の人員で応答できない時間帯だけを通知の自動化や監視代行で埋めれば、検知の遅れと体制の負担に折り合いを付けられます。
営業時間外の障害が取引先に与える影響
取引先の購買担当者が金曜の夕方、翌週月曜の入荷に間に合わせるために発注画面を開いたとします。
商品をカートに入れるところまでは進めたのに、発注を確定した先でエラー画面が返ってくる。
電話をかけても営業時間外で、問い合わせフォームも同じサイトの中にあるため送信できない。
その担当者に残る選択肢は、月曜まで待つか、いつも併用している別の仕入先に切り替えるかのどちらかになります。
売り手側から見ると、この間に起きたことは何も見えていません。
月曜の朝に「金曜から発注できないのですが」と連絡を受けて、はじめて週末のあいだサイトが止まっていたと分かる。
このとき失われているのは一件の注文だけではなく、「思い立ったときに発注できる」という前提そのものです。
BtoB通販は定期的な補充発注や、購買担当者が自分の手の空いた時間に入力する使われ方が多く、営業時間外の利用が相手の業務に組み込まれているほど、止まっていた時間の長さがそのまま取引先の段取りの狂いに変わります。
監視の必要性は、一般にビジネス継続性、セキュリティ、可用性の維持という三つの観点から説明されます2。
このうちビジネス継続性は、システムが止まったときの営業機会の損失と企業の信頼低下を防ぐという意味で、いま見た場面と直接つながります2。
ただしこれはクラウド環境でシステムを運用する事業者に広く当てはまる一般的なリスクの整理であり、BtoB通販サイトで障害がどれくらいの頻度で起き、一回あたりいくらの損失になるかを示すものではありません。
自社にとってこの重さがどの程度かは、取引先の発注がどの時間帯に集中しているか、そして電話やFAX、営業担当経由といった代替の発注手段がどれだけ残っているかで変わります。
代替経路が生きていて、取引先も日中しか発注しない運用なら、夜間の停止は翌朝までに直せば実害が出にくい。
逆に、紙の発注を廃止してサイトに一本化している取引先が多いほど、止まっている時間がそのまま相手の作業停止になります。
監視の範囲を考える前に、この前提を自社の取引条件に当てはめておくと、どこまで手を掛けるかの判断がぶれにくくなります。
「気づく仕組み」が最初の論点になる理由
障害への対応にかかる時間は、発生してから復旧するまでの一本の線ではなく、「発生してから誰かが気づくまで」と「気づいてから直すまで」に分かれます。
手順書を整えて復旧作業そのものを三十分で終えられるようにしても、気づくまでに二日かかっていれば、取引先から見た停止時間は二日と三十分です。
体制の見直しで効き方が大きいのは、たいていの場合この前半部分のほうです。
外形監視を持たない場合、問題に気づくきっかけは利用者からの「遅い」「アクセスできない」という報告になり、そのぶん対応が遅れます3。
加えて、稼働率などのSLAをどれだけ守れているかも正確に評価できなくなると指摘されています3。
取引先から「先週どれくらい止まっていたのか」と聞かれても、手元に記録がなく「たぶん数時間です」としか答えられない状態になる、ということです。
気づく仕組みは、異常を見つける部分と、見つけた事実を人に届ける部分の二つでできています。
当番表や連絡網は後者にあたりますが、前者が「サーバーが起動していること」しか見ていなければ、当番の人が見る画面には異常が表示されません。
夜通し待機していても通知が来ないのですから、当番を増やしても検知は早まりません。
だから体制づくりの順番としては、どこまで見れば気づけるのかという監視の範囲を先に決め、そのうえで届け方と担当を決めることになります。
次に必要なのは、監視の方式ごとに何が見えて何が見えないのかという整理です。
出典：JBCC株式会社「死活監視とは？外形監視との違いや必要な理由」／クラウド環境でシステムを運用する事業者一般に向けた整理
死活監視・外形監視・APMで検知できる障害の範囲はどう違うか
死活監視が捉えられる範囲と捉えられない範囲
死活監視は、サーバーやアプリケーションが正常に動作しているかをリアルタイムで継続的にチェックする仕組みで、Ping監視やポート監視が具体例として挙げられます2。
一定の間隔で信号を送り、応答が返るかどうかを見る。
応答が途切れれば異常と判断する、という分かりやすい仕組みです。
サーバーが落ちた、ネットワークが切れた、プロセスが停止したといった「止まった」障害には確実に反応します。
この監視が見ているのはシステムの内部側の視点です2。
言い換えると、サイトを提供している側の構成要素が生きているかどうかを確認しているのであって、取引先が発注できるかどうかを確認しているわけではありません。
この差が問題になるのは、機器は動いているのに業務が通らない状態のときです。
たとえば、Webサーバーは応答を返し続けているのに、データベースへの接続が枯渇していて発注の確定処理だけがエラーになる。
在庫の引き当てを担う内部の連携先がタイムアウトし、カートには入るが確定できない。
ログイン認証の期限切れで、取引先ごとの価格が出る画面だけが見られない。
こうした状態では、死活監視の画面はすべて正常のまま緑色で並びます。
BtoB通販で取引先が困るのはまさにこの型の障害で、サイトは開くのに注文だけが通らないという形で現れます。
つまり死活監視は不要ではなく、担当している範囲が違います。
止まったことは死活監視で確実に拾えるので、これは土台として残したうえで、業務が通るかどうかを見る手段を足す、という形になります。
外形監視で発注操作の異常を検知する仕組み
外形監視は、システムが稼働するネットワークの外側からアクセスし、利用者の視点で利用可能な状態にあるかを機械的に監視する手法です1。
内部からの確認では気づきにくい問題を早期に見つけられる点が、この方式の役割になります3。
取引先が使うのと同じ入口から入り、同じ操作をたどって、どこまで進めるかを一定間隔で試す、と考えると分かりやすいと思います。
BtoB通販サイトに当てはめるなら、確認したい操作はログインから発注の確定までの一連の流れです。
トップページが表示できるかだけでは、先ほどの「カートには入るが確定できない」状態を拾えません。
発注の送信まで含めて初めて、取引先が実際に困る地点を機械が代わりに踏んでくれることになります。
ここで実務として決めておく必要があるのが、監視が送った発注をどう扱うかです。
本物の発注画面を最後まで操作すれば、そのデータは受注として記録され、後続の出荷や請求の処理に流れる可能性があります。
監視専用の取引先アカウントと監視用の商品を用意する、監視から来た注文を受注処理の対象外にする、といった扱いを受注業務の側と合わせて決めておかないと、毎日届く架空の注文を人が手で取り消す作業が増えてしまいます。
どこまでなぞるかは、この運用をどこまで整えられるかとセットで決まります。
なお、ここで対象にしているのはWebの画面やAPI経由の発注です。
電話やFAX、営業担当が受ける発注は別の経路なので、その分が止まったかどうかは外形監視では分かりません。
取引先ごとに発注経路が違う場合は、サイトが止まったときに何割の取引先が影響を受けるのかも合わせて把握しておくと、監視にかける手間の判断がしやすくなります。
APMが補う性能面の監視
外形監視は、内部監視、つまりサービス監視やリソース監視と組み合わせて運用することが前提とされています1。
理由は役割の違いにあります。
外形監視が教えてくれるのは「利用者から見て使えない、あるいは遅い」という結果で、その原因がどこにあるのかまでは外側からは見えないからです。
APMはアプリケーション性能監視を指す言い方で、内部側からアプリケーションの処理を見る種類の監視の総称として使われます。
どの処理に時間がかかっているのか、どの機能でエラーが出ているのかといった、内部の動きに沿った情報を扱う位置づけです。
外形監視が「発注の確定で三十秒かかっている」と知らせ、内部側の監視が「その時間の大半がどの処理で費やされているか」を絞り込む、という分担になります。
導入の順番を考えるなら、まず気づく手段を確保し、次に原因を絞る手段を足す、という順が自然です。
原因を細かく追える仕組みがあっても、障害が起きたことに気づいていなければ使われませんし、逆に気づく手段だけあれば、原因の切り分けは時間をかければ人の手でも追えます。
ただし、深夜に呼び出された当番が短時間で状況を判断するには、どこで詰まっているかを示す情報があるかどうかが効いてきます。
体制の負担を下げたい場合ほど、後から内部側の監視を厚くする意味が出てきます。
監視方式ごとの視点と確認内容は、記事の後半に置いた早見の一覧でまとめて見比べられます。
24時間365日の監視体制は自社運用と外部委託のどちらで作るか
自社運用に必要な当番体制
二十四時間三百六十五日の監視というと仕組みの話に聞こえますが、実際に足りなくなるのは人の側です。
異常を検知する仕組みは設定すれば夜も休日も動き続けますが、通知を受け取って判断する人がいなければ、通知は朝まで端末の中に溜まったままになります。
自社で当番を組むというのは、その通知に応答する人を時間帯ごとに置くということです。
当番を置くときに先に決まっていないと、夜中に誰も動けない項目がいくつかあります。
一つは、通知を受けてから何分以内に応答するのかという目安です。
もう一つは、当番の人が自分の判断でどこまで手を出してよいかという範囲で、たとえばアプリケーションの再起動は独断で行ってよいのか、データベースに関わる操作は責任者の許可を待つのか、という線引きになります。
この線引きがないと、当番は状況を確認したところで止まり、結局は責任者が起きる時間まで何も進みません。
三つ目は、上げる先です。
自社で直せない種類の障害、たとえばクラウド基盤側の障害やサイトを構築した事業者の領域に関わる不具合は、夜間でもどこへ連絡するのかが決まっていないと動けません。
契約している事業者の受付時間が日中だけであれば、夜間に分かるのは「自社では直せない」という事実までで、そこから先は朝を待つことになります。
この場合、夜間に当番を置く目的は復旧ではなく、取引先へ状況を伝えられる状態を作ることに変わります。
目的が変われば、必要な人数も求められる技術の幅も変わります。
もう一つ見落とされやすいのが、代わりの人の確保です。
人数の少ない体制では同じ人が毎晩の通知を受ける形になりがちで、その状態が続くと、通知そのものを見なくなっていきます。
誤検知が多い設定のままだと、この摩耗はさらに早く進みます。
当番表を作る前に、何人でどう回すのか、その人が休んだ日は誰が受けるのかを確かめておくと、体制が続くかどうかの見通しが立ちます。
監視代行を使う場合の料金体系の考え方
夜間や休日を自社の人員で埋められない場合、その時間帯を外部の監視代行サービスに任せる選択肢があります。
費用の見え方を一例で示すと、ある事業者の二十四時間三百六十五日の監視・通報プランでは、監視対象四台までが月額21,000円（税抜）、五台目以降は一台につき5,300円が加算される料金体系が公開されています4。
これは同社の当該プランについて掲載時点で確認できる価格であり、他社を含めた相場を示すものではありません。
それでも料金の形からは、見積もりが「何を何個見るか」で動くという構造が読み取れます。
ここで気をつけたいのは、この金額を自社で当番を組んだ場合の費用と単純に並べられない点です。
夜間の待機手当をいくらにするか、呼び出しに対応した翌日の勤務をどう扱うかは会社ごとに違い、今回扱った材料の中にその比較はありません。
比べられるのは金額そのものではなく、「自社の人員でその時間帯に応答できるか」という可否のほうです。
応答できない時間帯が確実にあるなら、問いは「委託すべきか」ではなく「その時間帯をどう埋めるか」に変わり、委託はその答えの一つになります。
もう一点、委託すれば対応まで終わるとは限りません。
監視と通報までを請け負う形と、一次対応や復旧作業まで含む形では、契約の範囲が違います。
見積もりを取るときは、金額の比較と同時に「検知したあと、誰が何をするところまでが契約に入っているか」を確かめる必要があります。
通報までの契約であれば、夜間に呼び出される人を自社に置く必要は残りますが、その人は異常を探す役ではなく、知らせを受けて判断する役になります。
この違いは、当番に求める技術の幅と負担に効いてきます。
監視対象数の数え方が比較の起点になる
見積もりを比べようとして最初に止まるのが、自社の監視対象をどう数えるかというところです。
サーバーの台数は把握できても、外形監視は台数ではなく「どの操作を、どの経路で確認するか」という単位で増えていきます。
見積もりの条件をそろえるには、この二つを別々に数えておく必要があります。
BtoB通販サイトでとくに抜けやすいのが、ログインした先の画面と、基幹システムとの連携部分です。
ログインしていない状態で見えるページだけを監視していても、取引先が実際に使うのは取引先ごとの価格や掛け条件が反映されたログイン後の画面です。
また、サイト上では発注が完了していても、受注データが基幹システムへ渡る処理が止まっていれば、出荷は進みません。
取引先には正常に見えているぶん、この型の不具合は気づくのがさらに遅れます。
数え上げた対象には、全部を同じ頻度で見る必要があるものと、そうでないものが混ざります。
発注の一連の操作は短い間隔で確認したい一方、夜間に一度だけ動く連携バッチは、実行される時間帯に結果を確認できれば足りる場合もあります。
この整理をしてから見積もりを依頼すると、各社の提案を同じ条件で読み比べられるようになります。
逆にここが曖昧なままだと、安く見えた提案が公開ページの表示確認だけだった、といった食い違いが後から出てきます。
障害を検知した後、誰にどう通知し復旧につなげるか
複数の通知チャネルを持つ理由
検知の仕組みが整っても、通知が届かなければ気づいた人はいないのと同じです。
実際の監視代行サービスでは、障害を検出した際にメールやSlack、ChatWork、LINE、自動音声電話といった手段で通報する形が取られています4。
これは同社の当該プランの仕様例で、他社では対応する手段が異なりますが、複数の経路を用意するという考え方自体は自社で仕組みを組む場合にも当てはまります。
経路を複数持つ理由は、時間帯によって人が見ている場所が違うからです。
日中ならチャットに流れれば誰かが気づきますが、深夜の通知は通知音を切った端末に届き、朝まで見られないことがあります。
音声での呼び出しは、寝ている人を起こせる数少ない手段として位置づけられます。
逆に日中の軽微な異常まで電話で鳴らすと、今度は電話そのものが無視されるようになります。
設計としては、まず全員が見る場所へ流し、一定時間応答がなければ次の手段へ進む、という段階を決めておく形が扱いやすくなります。
最初からすべての経路を同時に鳴らすと、誰が対応しているのか分からず、同じ確認作業が二重に走ることがあります。
応答したことを共有する場所も同じ経路の中に作っておくと、この重複を減らせます。
もう一つ、通知先を個人の連絡先で持つと、異動や退職のたびに経路が切れます。
当番という役割に対して通知先を割り当て、その役割に誰が入るかを別で管理しておくと、担当が替わっても設定を触らずに済みます。
連絡先の棚卸しをいつ行うかまで決めておくと、いざというときに「その番号はもう使われていない」という事態を避けられます。
SLAの遵守状況を外形監視で確認する
外形監視は障害に気づくためだけのものではなく、使えていたことを示す記録にもなります。
外形監視がない場合、SLAの遵守状況を正確に評価できなくなると指摘されています3。
これはSLAを設定しているシステムの運用を前提にした指摘ですが、利用者の側から見て使えていたかどうかを測る手段がなければ、稼働率という数字の根拠が作れないという意味で、目標値を社内で持っている場合にも同じことが言えます。
稼働率を扱うときに最初に決めておかないと食い違うのが、何をもって稼働していたとみなすかです。
トップページが表示できれば稼働とするのか、ログインして発注を確定できる状態まで含めるのか。
前者の基準で計算した稼働率は高く出ますが、取引先が「先週は発注できない時間があった」と感じている期間と重なりません。
報告した数字と相手の体感がずれると、数字そのものが信用されなくなります。
取引先との契約でSLAを定めている場合、外形監視のシナリオ単位の記録は、その確認の材料になります。
いつからいつまで、どの操作ができなかったのかが残っていれば、障害の報告が推測ではなくなります。
復旧の報告でも「◯時◯分に発注の確認が再び通るようになりました」と伝えられるのと、「たぶん直っていると思います」と伝えるのとでは、受け取る側の安心感がまるで違います。
こうして見ると、監視の範囲を決める作業と、通知や報告の形を決める作業は別々のものではありません。
発注の確定まで外形監視でなぞると決めたなら、その記録がそのまま稼働の証跡になり、取引先への説明にも使えます。
逆に表示の確認だけに留めるなら、稼働率の定義もその範囲に合わせておかないと、後から数字の意味を説明できなくなります。
監視の方式ごとに、どの視点で何を確認しているのかを並べて見ると、自社にいま足りていない視点が絞り込みやすくなります。
どこまで監視すれば気づけるかは、自社のサイトのどの画面と連携が止まると取引先の発注が通らなくなるのかによって変わります。この切り分けは、監視方式の一般的な説明だけでは決まりません。
現在のサイト構成と受注の流れをもとに、外形監視でなぞるべき操作の範囲と、監視対象として数えるURLや連携の一覧を一緒に整理できます。無料相談で要件を整理する
死活監視・外形監視・APMの視点と確認内容の早見
システムの内側から見るか、利用者と同じ外側から見るかという視点の違いで整理しています。
- 死活監視：サーバーやアプリケーションが動いているかを、Pingやポートの応答などシステムの内部側の視点で継続的に確認する。止まった障害は確実に拾えるが、動いたまま注文だけ失敗する状態は正常として扱われる
- 外形監視：ネットワークの外側から利用者と同じようにアクセスし、ログインから発注の確定までが最後まで通るかを機械的に確認する。取引先が困る地点をそのまま検知でき、稼働していた記録としても使える
- APM（アプリケーション性能監視）：内部監視の側から、処理のどこで時間がかかり、どの機能でエラーが出ているかを見る。気づいた後に原因を絞り込む役割で、外形監視と組み合わせて使う
どれから手を付けるかは、いま気づけていない障害が「止まる」型か、「開くのに発注できない」型かで変わります。
要点の整理
| 軸 | 基準 |
|---|---|
| 監視の範囲 | 発注の確定まで外形監視でなぞり、死活監視や内部監視と組み合わせて残す |
| 時間帯の分担 | 自社の人員で応答できない時間帯を洗い出し、その時間帯だけを通知の自動化や委託で埋める |
| 委託の見積もり | 機器の台数と外形監視の経路を分けて数え、検知後どこまでが契約範囲かを確認する |
| 通知の設計 | 複数の経路を段階的に使い、通知先は個人ではなく当番という役割に割り当てる |
| 稼働率の確認 | 何をもって稼働とみなすかを先に決め、外形監視の記録と照らして報告する |
夜間や休日の分担は、サイト側の作りと、社内で誰がどこまで対応できるかの両方に関わります。どちらか一方だけを見て決めると、通知は届くのに動けない体制になりがちです。 自社で対応する範囲と外部に任せる範囲の切り分け案、そして見積もりを依頼する前に社内で確認しておくべき項目を整理して持ち帰れます。
よくある質問
外形監視を導入すれば死活監視は不要になりますか
不要にはなりません。
外形監視は内部監視、つまりサービス監視やリソース監視と組み合わせて運用することが前提とされています1。
両者は視点が異なり、死活監視はシステムの内部側から、外形監視は利用者の側から状態を確認します2。
外形監視だけにすると、発注が通らなくなった事実は分かっても、原因がサーバーの停止なのか個別の処理の不具合なのかを切り分ける手掛かりが減ります。
夜間に呼び出された人が短時間で判断するには、両方の情報がそろっているほうが動きやすくなります。
監視代行サービスは何台の監視対象から契約すべきですか
台数の多さで決めるより、自社の人員で応答できない時間帯があるかどうかで判断するほうが筋が通ります。
委託の費用は監視対象の数に応じて加算される料金体系が公開されている例があり4、対象が少なければ費用も小さくなりますが、一台しか監視していなくても、その一台が夜間に止まったときに誰も気づけないのであれば委託を検討する意味があります。
見積もりを依頼する前に、機器の台数と、外形監視でなぞる操作の経路を分けて数えておくと、各社の提案を同じ条件で比べられます。
通知はメールだけで足りますか、複数のチャネルを用意すべき理由は何ですか
日中だけの運用ならメールでも回りますが、夜間や休日を含めるなら足りなくなります。
理由は、時間帯によって人が見ている場所が違うためです。
実際の監視代行サービスでは、メールに加えてチャットツールや自動音声電話など複数の手段で通報する形が取られています4。
用意するときは同時にすべてを鳴らすのではなく、まず全員が見る場所へ流し、一定時間応答がなければ電話へ進む、という段階を決めておくと、誰が対応しているか分からないまま作業が重複する事態を避けられます。
SLAの稼働率はどの監視結果をもとに確認すればよいですか
利用者の側から使えていたかどうかを測る必要があるため、外形監視の結果が材料になります。
外形監視がないとSLAの遵守状況を正確に評価できなくなるとされています3。
そのうえで、何をもって稼働とみなすかを先に決めてください。
トップページの表示を基準にするか、ログインして発注を確定できる状態までを基準にするかで数字は変わり、後者に寄せるほど取引先の体感と近くなります。
基準を決めずに算出した稼働率は、報告しても相手の認識と食い違い、数字そのものが信用されにくくなります。
自社で24時間の当番体制を組む場合、何を先に決めるべきですか
当番表より先に、三つの点を決めておくと夜間に動けるようになります。
通知を受けてから何分以内に応答するかという目安、当番が独断でどこまで復旧作業をしてよいかという範囲、そして自社で直せない障害をどこへ上げるかという連絡先です。
とくに三つ目は、契約している事業者の受付が日中のみであれば、夜間にできるのは状況の把握と取引先への案内までになります。
その場合、夜間の当番の目的は復旧ではなく説明できる状態を作ることに変わるため、必要な人数も求める技術の幅も変わってきます。
- 1 出典：New Relic「外形監視(Synthetic Monitoring)とは？内部監視との違い」（2026年）
- 2 出典：JBCC株式会社「死活監視とは？外形監視との違いや必要な理由」（2026年）
- 3 出典：インターネットイニシアティブ「外形監視とは？死活監視との違いや必要性を解説」（2026年）
- 4 出典：株式会社アールワークス「システム監視・通報プラン(24時間365日)」（2026年）
