やまやまブログDEVELOPMENT & BUSINESS JOURNAL
お問い合わせ

IT技術ブログ

中小企業の社内システムのログ監視とアラート設計。何を見張るか、通知の宛先と夜間の扱い、誤報を減らす設定をAWS CloudWatchの例で

中小企業の社内システムのログ監視とアラート設計の進め方です。使う人が困ることから見張る項目を決める方法、通知を3段に分ける考え方、夜間の扱い、誤報を減らす設定をAWS CloudWatchの例で整理します。

公開日 最終更新日 by 津嘉山 洸

この記事の結論：中小企業の社内システムのログ監視とアラート設計は、まず「使う人が困ること」を書き出し、そこから見張る項目を逆算します。アラートは「すぐ人を起こす」「翌朝に見る」「記録だけ残す」の3段に分け、通知の宛先は個人ではなく段ごとの窓口にします。夜間に起こすのは業務が止まるものだけに絞り、ほかは朝にまとめて見ます。誤報は、何回のうち何回超えたら鳴らすか、欠けたデータをどう扱うか、複数のアラームを組み合わせて鳴らすか、の3つの設定で減らします。AWSなら、CloudWatchのログ、メトリクスフィルター、アラーム、Synthetics で一通りを組めます。

株式会社bundlyzeでは動いている業務システムの保守運用を、要件定義の段階から続けて受け持っていて、稼働した後に何を見張るかは保守の取り決めと一緒に決めることにしています。この記事は、社内向けの業務システムを持つ中小企業の担当者と、保守を受け持つ開発者に向けて、監視とアラートの決め方を順に整理したものです。誰がいつ何を操作したかを残す操作ログ（監査ログ）は目的が違うため、ログイン・権限・操作ログの記事に分けています。

ログ監視は「使う人が困ること」から見張る項目を決める

ログ監視で最初に決めるのは、CPUやメモリの数字ではなく、システムを使う社員や取引先が「何が起きたら困るか」です。困りごとから逆にたどると、見張る項目が少なく、鳴ったときに何をすればよいかがはっきりした監視になります。

使う人が困ること 見張るもの AWSでの見張り方の例
ログインできない、画面が開かない 外から画面を開けるか CloudWatch Synthetics で決まった間隔で画面を開く
画面が遅くて仕事にならない 応答にかかる時間 ロードバランサーやAPIの応答時間の指標
保存したはずのデータが残っていない アプリのエラーの件数 アプリのログからメトリクスフィルターでエラーを数える
夜の集計や連携の処理が終わっていない 処理が成功した記録が届いたか 成功したときだけ記録を送り、届かなければ鳴らす
請求書や通知のメールが届かない メール送信の失敗 送信サービスのはね返り（バウンス）の件数
突然使えなくなる ディスクやデータベースの容量、証明書の期限 容量の指標、ACM の DaysToExpiry（証明書の期限までの日数）

表の右の列は、AWSで作る場合の一例です。ほかのクラウドやサーバーでも、「困りごと → 見張るもの」の左の2列は同じように書けます。最初はこの表を発注者と保守の担当で一緒に埋め、業務が止まる行から優先して始めると、鳴ったときに読み切れない量のアラートにならずに済みます。

外から開く監視と、中のログを数える監視の両方を置く

監視は、利用者と同じように外から画面を開いて確かめるものと、システムの中に残るログを数えるものの2種類を組み合わせます。片方だけでは、見えない止まり方が残るからです。

種類 気づけること 気づけないこと
外から開く監視 画面が開かない、ログイン画面までたどり着けない、応答が遅い 画面は開くが、保存の処理だけ失敗している
中のログを数える監視 保存の失敗、外部の連携の失敗、夜間の処理の失敗 サーバーごと止まって、ログ自体が出ていない

外から開く監視には、CloudWatch Synthetics のカナリアが使えます。カナリアは決まった間隔で動くスクリプトで、利用者と同じ道筋と操作をたどってエンドポイントやAPIを見張るものだとAWSは説明しています。社内システムなら、ログイン画面が開くか、テスト用のアカウントでログインして一覧の画面まで進めるか、の2点を見るだけでも出発点として十分です。

中のログを数えるには、まずアプリのログを数えやすい形で出すことが前提になります。1行ごとに、時刻、重さの段階（ERROR・WARN・INFO）、どの処理か、要求ごとの番号を、JSONのような決まった形で出しておくと、あとから件数を数えたり、同じ要求のログを探したりできます。ログに社員や顧客の名前、メールアドレス、パスワードを書き出さないことも、ここで決めておきます。

アラートは「すぐ起こす」「翌朝見る」「記録だけ」の3段に分ける

アラートは、鳴ったら誰がいつ動くかで3段に分け、段ごとに通知の経路を変えます。すべてを同じ経路に流すと、急ぎでない通知に埋もれて、本当に急ぐものを見落とすからです。

段 鳴らす条件の例 通知の経路 受けた人がすること
すぐ起こす 画面が外から開けない状態が続く、データベースに書き込めない 当番の携帯、チャットの緊急用の場所 手順書に沿って切り分け、必要なら利用者に知らせる
翌朝見る エラーの件数が普段より多い、応答が遅い時間帯がある チャットの通常の場所、メール 始業時に原因を調べ、直すかどうかを決める
記録だけ 1件ごとのエラー、ログインの失敗 通知せず、ログとダッシュボードに残す 週に1回まとめて眺め、増えていないかを見る

段を決めるときの目安は、「朝まで待ったら、何が失われるか」です。朝まで待つと受注が取れない、データが壊れる、取引先への約束に間に合わない、のいずれかに当たるものだけを「すぐ起こす」に入れます。

通知の宛先は個人ではなく窓口にし、夜間は起こす条件を絞る

アラートの通知先は、担当者個人のメールアドレスではなく、段ごとの窓口（通知のトピックやチャットの場所）にして、窓口から誰に届くかを別に管理します。個人の宛先に直接送ると、担当が休んだり辞めたりしたときに、誰にも届かない状態が生まれるからです。

AWSでは、段ごとに Amazon SNS のトピックを1つずつ作り、アラームの通知先にはトピックを指定します。トピックの購読者として、当番のメールやチャットへの連携をつなぎ、担当が変わったら購読者だけを入れ替えます。

夜間や休日については、次のように決めておきます。

  • 夜間に起こす相手と、その時間帯を保守の取り決めに書く：取り決めのない時間帯に「すぐ起こす」アラートが鳴っても、受ける人がいなければ意味がありません
  • 夜間は「翌朝見る」の通知を止める：CloudWatchのアラームのミュートルール（Alarm Mute Rules）では、繰り返しの時間帯を決めて、その間のアラームの動作だけを止められます。アラームの評価は続き、時間帯が終わった時点でまだ異常が続いていれば、止めていた動作がもう一度実行されます
  • 夜間の処理と重なる時間は、関係するアラートを止める：夜のバックアップや集計で一時的に負荷が上がる時間に、応答時間のアラートが鳴らないようにします

誤報は「何回のうち何回」「欠けたデータの扱い」「組み合わせ」の3つで減らす

アラートの誤報は、鳴らす条件を1回の超過にしないこと、データが届かない時間の扱いを決めること、複数のアラームを組み合わせて鳴らすことの3つで減らします。誤報が続くと、通知そのものが読まれなくなり、本当の異常に気づけなくなります。

1つ目は、何回のうち何回超えたら鳴らすか、です。CloudWatchのアラームでは、1回分のデータの長さ（Period）、直近の何回分を見るか（Evaluation Periods）、そのうち何回超えたら鳴らすか（Datapoints to Alarm）を別々に決められます。たとえば「直近3回のうち2回」のようにすると、1回だけの跳ね上がりでは鳴らず、続いている異常には反応します。

2つ目は、データが届かない時間の扱いです。CloudWatchでは、欠けたデータの扱いを次の4つから選べます。何も選ばない場合の既定は missing です。

設定 欠けたデータを 向いている指標の例
notBreaching 基準内（問題なし）として扱う エラーが出たときだけ記録されるエラーの件数
breaching 基準超え（問題あり）として扱う 成功したときに必ず届くはずの、処理の成功の記録
ignore 今の状態を保つ 届く間隔がまちまちな指標
missing 評価する範囲のすべてが欠けたら「データ不足」にする 常に届くはずの、サーバーやサービスの指標

3つ目は、組み合わせです。複合アラーム（composite alarm）を使うと、「外から画面が開けない」かつ「データベースのアラームも鳴っている」のように、複数のアラームの状態を AND・OR・NOT でまとめた条件で鳴らせます。また複合アラームには、別のアラームが鳴っている間は通知を出さない「抑止」の設定があり、計画したメンテナンスの間の通知を止めるのに使えます。

CloudWatchでの設定の例

ここでは、アプリのログに出したエラーを数えて「翌朝見る」の窓口へ通知する設定と、夜間の処理が成功した記録が届かなければ鳴らす設定を、AWS CLI で書いた例を示します。名前、数値、アカウントIDはすべて例で、基準の値は実際のエラーの件数を見ながら調整するものです。

アプリのログがJSONで出ている前提で、level が ERROR の行を数える指標を作ります。

bash
aws logs put-metric-filter \
  --log-group-name /internal-app/web \
  --filter-name app-error-count \
  --filter-pattern '{ $.level = "ERROR" }' \
  --metric-transformations \
    metricName=AppErrorCount,metricNamespace=InternalApp,metricValue=1,defaultValue=0

メトリクスフィルターは、作った後に取り込まれたログにだけ当てはまり、作る前のログをさかのぼって数えることはありません。設定した直後のグラフが空でも、異常ではありません。

この指標に、「5分ごとの件数が、直近3回のうち2回で基準を超えたら鳴らす」アラームを付けます。エラーがない時間はデータが欠けることがあるので、欠けたデータは問題なしとして扱います。

bash
aws cloudwatch put-metric-alarm \
  --alarm-name internal-app-error-burst \
  --alarm-description "手順書: 社内Wikiの『エラー増加時の確認』を参照" \
  --namespace InternalApp \
  --metric-name AppErrorCount \
  --statistic Sum \
  --period 300 \
  --evaluation-periods 3 \
  --datapoints-to-alarm 2 \
  --threshold 5 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alert-next-morning

夜間の処理は、成功したときだけ記録を送り、1日分の記録が届かなければ鳴らす形にします。処理が途中で止まってエラーのログすら出ない場合にも気づけるのが、この形の利点です。

bash
# 夜間の処理の最後（成功したときだけ）に実行する
aws cloudwatch put-metric-data \
  --namespace InternalApp \
  --metric-name NightlyJobSucceeded \
  --value 1

# 24時間のあいだに成功の記録が1件もなければ鳴らす
aws cloudwatch put-metric-alarm \
  --alarm-name internal-app-nightly-job-missing \
  --namespace InternalApp \
  --metric-name NightlyJobSucceeded \
  --statistic Sum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --treat-missing-data breaching \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alert-next-morning

この2つ目のアラームでは、欠けたデータを問題ありとして扱う breaching を選んでいるのが要点です。成功の記録が届かないこと自体が、異常のしるしだからです。

アラームごとに、鳴ったときの手順書を1枚用意する

アラームを作るときは、鳴ったときに受けた人が最初の数分で何をするかを書いた手順書を、アラーム1つにつき1枚用意します。手順書のないアラームは、鳴っても受けた人が判断できず、結局は詳しい1人に電話が集まります。

手順書には、次の5つを書きます。

  1. このアラームが何を意味するか：どの困りごとにつながっているか
  2. 最初に見る画面：ダッシュボード、ログの検索の条件
  3. よくある原因と、それぞれの確かめ方
  4. 自分で戻してよい操作と、してはいけない操作：再起動してよいか、データに触れてよいか
  5. 誰に、いつ知らせるか：利用者への周知が要る場合の文面の置き場所

CloudWatchのアラームの説明欄には、手順書の場所を書いておけます。複合アラームの作り方のページでも、説明欄に手順書（runbook）などへのリンクを書いておく使い方が案内されています。通知を受けた人がアラームの詳細を開けば、そこから手順書にたどり着けます。

月に一度、鳴ったアラートを振り返って設定を直す

アラートの設定は一度作って終わりではなく、月に一度、その月に鳴ったものを一覧にして、設定を直す場を持ちます。システムの使われ方が変わると、最初に決めた基準が合わなくなるからです。

振り返りで見ること 直し方
鳴ったが、何もしなかったアラート 段を下げる、基準を上げる、何回のうち何回を厳しくする
鳴らなかったが、利用者から問い合わせがあった不具合 見張る項目の表に行を足す
夜間に鳴って人を起こしたアラート 本当に朝まで待てなかったかを確かめ、段を見直す
手順書どおりに戻せなかったアラート 手順書を直す

振り返りの記録を残しておくと、保守を引き継ぐときにも、なぜこの基準になっているかを説明できます。

ログ監視とアラートを始める順番

最初から全部をそろえず、困りごとの表から始めて、段階的に増やします。

  1. 使う人が困ることの表を作る：発注者と保守の担当で一緒に埋める
  2. アプリのログを、数えられる形で出す：時刻・重さの段階・処理の名前・要求の番号。個人情報は出さない
  3. 外から開く監視を1つ置く：ログイン画面が開くかから始める
  4. 3段の窓口を作る：段ごとの通知先と、夜間に起こす相手を決める
  5. アラームを作り、欠けたデータの扱いと何回のうち何回を決める
  6. アラームごとの手順書を書く
  7. 月に一度の振り返りを予定に入れる

監視の項目の洗い出しから、CloudWatchの設定、手順書づくり、稼働後の振り返りまでを一緒に進める場合は、私たちのクラウド構築・運用整備のページに相談の窓口があります。

出典

以下のAWSのページは、すべて2026年10月3日に中身を確かめています。CloudWatchは機能の追加や名称の変更が多いので、設定の前に今のページを開き直してください。

よくある質問

ログ監視は、エラーが1件出たらすぐに通知する設定でよいですか？

1件ごとの通知は、利用者の入力ミスや一時的な通信の途切れでも鳴るため、すぐに誰も見なくなります。一定の時間の中で何件出たか、何回続けて基準を超えたかで鳴らす設定にし、1件ごとのエラーは記録として残して翌朝に見る形をおすすめします。CloudWatchでは、評価する期間の数と、そのうち何回超えたら鳴らすかを分けて決められます。

社員が少なく、夜間に対応できる人がいません。夜のアラートはどうすればよいですか？

夜に人を起こすのは、朝まで待つと業務が止まるか、データが失われるものだけに絞ります。それ以外は夜間は通知を止め、朝の始業時にまとめて見る形にします。夜間に起こすアラートが残る場合は、誰が受けて何をするかを保守の契約や当番の表で決めておき、決まっていない時間帯に鳴らさないようにします。

CloudWatchのアラームが「データ不足」の状態になるのは、異常ですか？

必ずしも異常ではありません。アラームを作った直後や、エラーが出たときだけ記録される指標では、データが届かない時間があるのは普通のことです。CloudWatchでは、欠けたデータを「問題なし」「問題あり」「状態を保つ」「欠けたまま」のどれとして扱うかを、アラームごとに選べます。見張る指標の性質に合わせて選びます。