ログ管理・モニタリングとは？発注者が知るべきシステム障害対応の仕組み
本番稼働しているシステムで障害が発生し、ベンダーから「ログを確認中です」「アラートでは検知できませんでした」と報告を受けたとき、その一言で会話が止まってしまった経験はないでしょうか。ログとは何なのか、なぜ検知できなかったのか、発注者としてどこまで追及してよいのか、判断の軸がないまま時間だけが過ぎてしまう状況は、多くの非エンジニアのビジネス担当者が直面する悩みです。
ログ管理・モニタリングは、一見するとインフラエンジニアだけの専門領域に見えます。しかし実際には、「どのログを残すか」「何を監視するか」「どのタイミングで誰に通知するか」といった運用設計上の取り決めで決まる範囲が大きく、これらは本来、発注者側が要件として指定すべき事項です。発注時に握っていない事項は、障害発生時に「想定外」となって跳ね返ってきます。
とはいえ、発注者が自らログを読み解いたり、監視ツールを設定したりする必要はありません。求められるのは「ベンダーが何をしているかを把握し、過不足を指摘できる」レベルの理解です。用語の全体像と、どこに判断のツボがあるかさえ押さえておけば、ベンダーとの打ち合わせで的外れな質問を避け、逆に的確な論点を提示できるようになります。
本記事では、システム開発を外部ベンダーに発注している非エンジニアのビジネスパーソンを対象に、ログ管理・モニタリングの基本的な仕組みから、障害発生時にベンダーへ投げかけるべき具体的な質問、さらに新規発注時や運用委託契約で確認すべきチェックリストまでを、実務で使える粒度で解説します。記事を読み終えたときに、ベンダーに対して「このログはどれくらい保存していますか？」「異常検知のアラートはどう設定していますか？」と自然に質問できる状態になることを目指します。
目次
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
ログ管理・モニタリングとは？発注者が押さえるべき基本の仕組み
ログ管理・モニタリングとは、「システムが何をしているかを記録し（ログ管理）、その記録と稼働状態を継続的に監視して異常にいち早く気づく（モニタリング）」という、一連の運用活動のことです。切り離して議論されることもありますが、発注者の立場では「残す」と「見る」を一連の流れとして理解したほうが、議論がぶれません。
身近な比喩で言えば、防犯カメラの映像を記録し続けるのがログ管理、そのモニター画面を警備員が常時チェックして異常があれば警報を鳴らすのがモニタリングです。どちらか一方だけではシステムは守れません。映像を録りっぱなしで誰も見なければ異常に気づけませんし、監視員がいても録画がなければ、後から「何が起きたか」を検証できません。
ログとは「システムが残す行動記録」
ログとは、システムが動作する過程で自動的に書き出す行動記録のことです。「いつ、誰が、何の操作を行い、結果どうなったか」を時刻付きで残したテキストデータだとイメージしてください。たとえばWebサイトにユーザーがアクセスしたとき、サーバー側には「何時何分に、どのIPアドレスから、どのページへのリクエストがあり、応答ステータスは200（成功）だった」といった1行が記録されます。
ログは事後の検証材料であり、かつ障害発生時の事実確認の唯一の手がかりでもあります。記憶や目撃談ではなく、システム自身が書き出した客観的な記録に基づいて原因を追えることが、ログの最大の価値です。
モニタリング（監視）とは「ログや稼働状態を継続的にチェックする活動」
モニタリングとは、ログや稼働状態を継続的にチェックし、事前に決めた基準から逸脱したときに人間へ通知する仕組みのことです。日本語では「監視」と呼ばれます。人間が24時間画面を見続けるのは非現実的なので、通常は監視ツール（DatadogやZabbix、Amazon CloudWatchなど）が機械的にチェックし、異常時にメールやチャット、電話で担当者へ通知します。
モニタリングの対象は、ログだけではありません。サーバーのCPU使用率やメモリ使用量、ネットワーク疎通、外部から見たWebサイトの応答速度など、複数の観点で「健康状態」を見ています。
ログ管理とモニタリングの関係：残す・見る・気づく・対応する
ログ管理とモニタリングは、次の4ステップの流れとして一続きで理解すると混乱しません。
- 残す（ログ管理）：システムの動作を記録として書き出し、一定期間保存する
- 見る（モニタリング）：記録と稼働状態を継続的にチェックする
- 気づく（アラート）：基準を超えた異常を自動的に検知し、担当者へ通知する
- 対応する（インシデント対応）：通知を受けた担当者が原因を特定し、復旧作業を行う
ベンダーが「ログを確認します」と言うとき、多くの場合はこのステップ4の真っ只中で、過去に残された記録をさかのぼって原因を特定している状態です。一方「アラートで検知しました」は、ステップ3が機能した状態を指します。どのステップの話をしているのか意識すると、ベンダーとの会話が噛み合いやすくなります。
発注者が知っておくべきログの種類と役割
ログと一口に言っても、システムが書き出している種類は実はいくつもあります。全てを覚える必要はありませんが、障害対応の会話でベンダーが「どのログを見ているか」を判別できるレベルで、代表的な4種類を押さえておきましょう。
アクセスログ（誰が・いつ・どこに接続したかの記録）
アクセスログは、Webサーバーが受け取ったリクエストを1件ずつ記録したものです。「何時何分に、どのIPアドレスから、どのURLへのアクセスがあり、どのステータスコードで応答したか」が並びます。
アクセスログは、外部から見た「システムが応答していたか」を検証するのに役立ちます。たとえば「10時15分から10時30分までの間、ページが真っ白だった」というユーザー報告があったとき、その時間帯のアクセスログにステータス500（サーバー内部エラー）が大量に並んでいれば、障害が実際に発生していたことを外形的に裏付けられます。
エラーログ（処理失敗・例外の記録）
エラーログは、システム内部で処理が失敗したときに残される記録です。プログラム内で想定外の事象（外部APIから応答が返ってこない、データベースへの書き込みに失敗した、ファイルが見つからない等）が起きたタイミングで1行ずつ書き出されます。
障害発生時にベンダーが真っ先に確認するのが、このエラーログです。「何が原因で処理が失敗したのか」という問いに対して最も直接的な手がかりを与えてくれます。
アプリケーションログ（業務処理の流れの記録）
アプリケーションログは、業務処理の流れを段階ごとに記録したログです。「ユーザーがログインした」「注文を確定した」「決済APIを呼び出した」「決済が成功した」といった、システムが内部で実行した一連の処理の足取りを追えます。
障害原因の特定において、アプリケーションログは主役といえる存在です。エラーログが「失敗の瞬間」を示すのに対し、アプリケーションログは「失敗に至るまでの経緯」を示してくれるため、根本原因に近づくための材料になります。アプリケーションログの粒度（どの処理をどこまで細かく残すか）は運用設計で決まるため、後述のチェックポイントに直結する重要な観点です。
セキュリティログ（認証・権限操作の記録）
セキュリティログは、ログイン試行・認証の成否・権限変更・機密データへのアクセスなど、セキュリティに関わる操作を記録したものです。障害対応というよりは、不正アクセスの検知や監査対応の文脈で使われるログです。
金融・医療・個人情報を扱うシステムでは、後述する法規制・業界標準により、セキュリティログの取得と保存が義務付けられている場合があります。
発注者として意識すべきこと：どのログを残すかは「運用設計」で決まる
ここで発注者として押さえておきたいのは、「どのログを・どの粒度で・どれだけの期間残すか」はシステムの仕様として運用設計書で決まる、という点です。
ベンダーの判断任せにしておくと、障害発生後に「調べたいログが取られていなかった」「保存期間が短く、既に削除されていた」という事態が起こりえます。アプリケーションログの粒度が粗いと、エラーログで「失敗しました」とだけ出ているのに、その直前に何が起きていたかを追えない、という状況も現実に発生します。運用設計書に目を通し、疑問があればベンダーに確認するというひと手間が、障害対応の質を大きく左右します。
モニタリングとアラートの仕組み：障害にいち早く気づくために
続いて、モニタリングとアラートの仕組みを発注者が理解できるレベルで整理します。ここを押さえておくと、「なぜアラートで検知できなかったのか」という本質的な問いをベンダーに投げかけられるようになります。
モニタリングで見る主な項目（死活・リソース・ログ・外形）
モニタリングで監視する対象は、大きく次の4種類に分類するのが一般的です。
- 死活監視：サーバーやサービスが起動しているか、ネットワーク的に応答するかをチェックする。最低限の生存確認
- リソース監視：CPU使用率・メモリ使用量・ディスク空き容量・ネットワーク帯域などを定期的に計測する。異常な高負荷の予兆検知に使う
- ログ監視：ログファイルの中に特定の文字列（
ERROR、FATAL、例外クラス名など）が出現したらアラートを発報する - 外形監視：外部のネットワークから実際にWebサイトへアクセスし、想定通りのページが想定時間内に返ってくるかをチェックする。ユーザー視点での「サービスが動いているか」を検証
このうちどれが設定されているかはシステムによってまちまちです。「死活監視はあるがログ監視はない」といったケースも実務では珍しくありません。発注者としては、4種類をチェックリストとして頭に置き、運用設計書を読むときに「どれがカバーされているか」を確認する視点を持つとよいでしょう。
アラート設計の基本（しきい値・通知先・夜間休日対応）
アラートとは、モニタリング対象が事前に決めたしきい値を超えたときに、自動的に担当者へ通知を飛ばす仕組みです。アラート設計で発注者が押さえておきたいポイントは次の3点です。
- しきい値：どの水準を超えたらアラートを出すか（例：CPU使用率90%超が5分継続、5分間でエラーログが100件超）
- 通知先と経路：誰に、どの手段で（メール、チャット、電話）届けるか
- 夜間・休日の対応：24時間有人監視なのか、自動通知のみで担当者のオンコール対応なのか
ここで重要なのは、アラートが鳴ったときに「誰が、いつまでに、何をするか」まで合意しておくことです。ここは運用委託のSLA（サービス品質保証）に直結する領域なので、SLAの基本を押さえた上でベンダーと議論することをおすすめします。
アラートが多すぎても少なすぎても運用は破綻する
アラートは「多ければ多いほど安心」ではありません。しきい値を厳しく設定しすぎると、実害のない一時的な負荷増にも大量の通知が飛び、運用担当者が麻痺して本当に重要なアラートを見逃してしまいます。これは「アラート疲れ（alert fatigue）」と呼ばれ、大規模障害の温床になります。
逆に緩くしすぎると、異常が進行していても通知が飛ばず、ユーザーからの問い合わせで初めて気づく、という事態になります。適切なしきい値は、システム特性・トラフィック量・ビジネスの許容停止時間によって変わるため、運用開始後も定期的な見直しが前提です。
システム障害発生時、発注者が確認すべき3つのこと
ここからが本記事の核心です。実際にシステム障害が発生し、ベンダーから報告を受けている場面で、発注者として何を確認すべきかを、そのまま使える質問例とともに整理します。観点は次の3つに絞ります。
①「何が起きたか」をログから特定できているか（事実把握）
障害対応の最初のステップは、「何が」「どのユーザー・機能で」「どこまで」発生したかの事実把握です。このフェーズでベンダーの作業進捗と情報の確度を確認するには、次のような質問が有効です。
- エラーログは事象発生時刻の前後何分まで取得できていますか？
- エラーの件数は何件で、全リクエストに対する割合はどれくらいですか？
- 影響を受けたユーザーは特定できていますか？（例：全ユーザー／特定の機能を使ったユーザーのみ／特定の地域・時間帯のみ）
- アプリケーションログで、エラー発生直前に実行されていた処理は特定できていますか？
- 同種のエラーが過去にも発生していたか、履歴の確認はできていますか？
「調査中です」という回答だけで待つのではなく、これらを順番に聞いていくことで、ベンダーが現状どこまで把握しているかを発注者側でも可視化できます。特に「エラーの件数と割合」は、復旧の優先度判断やユーザー告知の要否を決める重要な材料です。
②「いつから」「どのくらい」影響が出ていたか（影響範囲と検知遅延）
次に確認すべきは、影響が発生した時間帯と、検知までにかかった時間です。これは、復旧後のユーザー対応（返金・お詫び・再処理）の要否や規模を判断する材料になります。
- 事象の発生時刻と終息時刻は特定できていますか？
- 障害が発生してからアラートが鳴るまでに、何分かかりましたか？
- アラートが鳴ってから対応を開始するまでに、何分かかりましたか？
- 対応開始から復旧までにかかった時間（MTTR＝平均修復時間）はどれくらいですか？
- 影響時間中に処理された／処理されなかったリクエストの件数は把握できていますか？
「障害の発生から復旧までの時間」は、ベンダーの運用品質を測る基本指標でもあります。継続的に記録し、月次の運用報告で推移を見ることで、運用改善の余地を可視化できます。
③ なぜアラートで検知できなかったか／できたか（監視設計の妥当性）
最後に、今回の障害において監視設計が適切に機能したかを振り返ります。同じ障害を繰り返さないための最も重要な観点です。
- この事象は、既存の監視項目でアラート対象になっていましたか？
- アラート対象だった場合、しきい値は適切でしたか？（鳴らなかった／鳴ったが遅かった／過剰に鳴ったのいずれか）
- アラート対象外だった場合、今後の監視項目に追加する予定はありますか？
- 外形監視（ユーザー視点での応答チェック）は実施されていましたか？
- 今回の障害を踏まえ、監視設計の見直しはいつ・どの範囲で行いますか？
特に「監視対象外だったために検知できなかった」ケースは、運用設計そのものを見直す契機になります。事後対応だけで終わらせず、次のリリース前に監視項目を追加するところまで約束を取り付けるのが、発注者として取るべきスタンスです。
新規発注・運用設計時に確認すべきログ・モニタリング要件
障害対応の次の話題として、「そもそも発注時点で何を握っておけばこの問題を避けられたか」を考えます。新規システムの発注や運用委託契約の更新のタイミングで、運用設計書とSLAの中に以下の論点を盛り込むよう、ベンダーと握り合いましょう。システム開発におけるシステムの保守と運用の違いを踏まえた上で、「運用」の範囲に含まれる合意事項として整理するのがおすすめです。
残すログの種類と粒度
まず、どの種類のログを（アクセス／エラー／アプリケーション／セキュリティ）、どの粒度で残すかを合意します。特にアプリケーションログの粒度は重要で、主要な業務処理の入力・出力・分岐条件を追えるレベルで残すのが理想です。「最小限しか残さない」設計だと、いざ障害が起きたときに追跡不能になります。
ログの保存期間（法規制・業界要件の観点）
ログの保存期間は、業界標準や法規制で最低基準が決まっている場合があります。たとえばクレジットカード情報を扱うシステムで国際的な標準となっているPCI DSS（v4.0）では、要件10において監査ログを少なくとも12カ月間保持し、そのうち直近3カ月分はすぐに分析可能な状態で利用できるようにすることが求められています（出典：PCI SSC「Payment Card Industry データセキュリティ基準 v4.0」要件10.5.1）。
業界標準がないシステムでも、「障害発生から原因調査を実施するまでのリードタイム（例：3カ月）」を逆算して保存期間を決めるのがセオリーです。保存期間を短くしすぎると、過去の似た事象との比較ができなくなるため、コストとのバランスで決めましょう。
また、事業継続計画（BCP）や災害復旧（DR）の観点では、ログそのものの保全も論点になります。ログがシステムと同じサーバーにしか存在しないと、そのサーバーが障害で失われたときに事後検証ができません。別リージョン・別ストレージへのバックアップ要件まで握り合うのが望ましい姿です。
監視項目としきい値の合意
何を監視し、どのしきい値でアラートを鳴らすかを、運用設計書の監視項目一覧として合意します。前述の4分類（死活・リソース・ログ・外形）を念頭に、主要機能ごとに監視項目を列挙するのが基本です。最初から完璧なしきい値を決めるのは困難なので、「運用開始後3カ月でしきい値をレビューする」といった見直しサイクルもあわせて合意しておきましょう。
アラート通知経路と対応時間（SLA・MTTR・RTO）
アラートが鳴ったあと、誰がいつまでに対応するかをSLAに落とし込みます。押さえておきたい指標は次のとおりです。
- MTTR（Mean Time To Repair／平均修復時間）：障害の発生から復旧完了までの平均時間
- RTO（Recovery Time Objective／目標復旧時間）：障害発生時に「いつまでに復旧させるか」の目標値
- 通知手段と対応時間の対応表：平日日中／夜間／休日ごとに、誰に・どの手段で通知し、何分以内に一次対応を始めるか
「RTO=4時間」「夜間アラートはチャット通知のみで翌営業日対応」といった合意は、発注者のビジネス許容度と整合している必要があります。決済や予約などリアルタイム性が重要な機能ではRTOを短く、社内向けの参照系システムでは長めに設定する、といったメリハリが現実的です。
定期的な運用設計の見直し（アラート調整・棚卸し）
最後に、運用設計は一度決めて終わりではなく、継続的な見直しが必要だという認識を発注者・ベンダーで共有しておきましょう。システムの機能追加やトラフィック変化に応じて、ログ粒度・監視項目・しきい値は陳腐化していきます。最低でも四半期に1回は運用設計書をレビューし、不要になったアラートの廃止、新規機能の監視追加、しきい値の調整を行うサイクルを契約上組み込んでおくのが理想です。
まとめ：ログ管理・モニタリングは「ベンダー任せ」にしないことが重要
ログ管理・モニタリングは、システムが正しく動いているかを継続的に確認し、異常に素早く気づいて対応するための一連の仕組みです。「残す」「見る」「気づく」「対応する」という4ステップの流れで理解すると、ベンダーとの会話が噛み合いやすくなります。
本記事で取り上げた要点は次のとおりです。ログには目的別に複数の種類があり、どれを残すかは運用設計で決まること。モニタリングは死活・リソース・ログ・外形の4分類で全体像を把握できること。障害発生時には「事実把握」「影響範囲と検知遅延」「監視設計の妥当性」の3観点でベンダーに質問することで、対等な議論ができるようになること。そして新規発注時には、ログの種類と粒度・保存期間・監視項目としきい値・アラート対応時間・定期的な見直しサイクルを運用設計書とSLAに織り込んでおくこと。
発注者自身がログを読み解いたり監視ツールを設定したりする必要はありません。ただし、「ベンダーが何をしているかを把握し、過不足を指摘できる」状態を作れるかどうかで、障害発生時のダメージや、同じ障害を繰り返す確率は大きく変わります。ブラックボックスを開き、自分の言葉で監視・ログの話ができるようになる。それが、システムを外部発注するビジネスパーソンにとっての、ログ管理・モニタリング理解の到達点です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
