- 「いつもやっていることだから」 という理由で過去の手法を惰性で踏襲する
- FUD（Fear・Uncertainty・Doubt） によりレガシーな監視構成の修正を躊躇する
入門監視
2026年05月28日
regmonkey_index:
title_fontsize: 1.3em
bullet_fontsize: 0.85em
numbering: true
children:
- title: 監視とは何か
description:
- 監視の定義・目的・スコープを整理する
- Issue Finding から Action までを射程に入れる
width: [48, 52]
- title: 監視のアンチパターン
description:
- ツール依存・監視のための監視を避ける
- 「動いている」の定義から始める
width: [48, 52]
- title: 監視のデザインパターン
description:
- 組み合わせ可能な監視・ユーザー視点・SaaS活用
- 可用性とサンプリングの考え方
width: [48, 52]
- title: アラート・オンコール・<br>インシデント管理
description:
- 良いアラートの条件と手順書の骨格
- インシデント管理プロセスと役割分担
width: [48, 52]
- title: ビジネス監視・<br>フロントエンド監視
description:
- Business KPI で観測を経営に接続する
- RUM・Synthetic Monitoring でユーザー体感を測る
width: [48, 52]
- title: Appendix
description:
- 可用性とサンプリング定理
width: [48, 52]監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
監視（Monitoring）
4つのルール
パフォーマンス管理
本番の前提
全員で実施
Action に接続
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
ミッションではなく現状維持がドライバになってはいけない
データサイエンスの現場でよく見られるアンチパターン
record1:
アンチパターン: ツール先行導入
ルール・観点:
- 監視 SaaS や MLOps プラットフォームを<span class="regmonkey-bold">先に決めてから</span>運用設計に入る
発生するペイン:
- ツール機能に合わせた指標しか出せない
- <span class="regmonkey-bold">ビジネス KPI と分離</span>して意思決定に届かない
record2:
アンチパターン: モデル精度<br>だけを監視
ルール・観点:
- 学習時の精度・AUC ばかり追い，<span class="regmonkey-bold">本番のデータ分布</span>を観測しない
発生するペイン:
- <span class="regmonkey-bold">data drift・concept drift</span> に気付けない
- 静かな劣化が長期間放置される
record4:
アンチパターン: 学習パイプライン<br>を目的なく監視
ルール・観点:
- バッチ学習・特徴量生成の<span class="regmonkey-bold">成功/失敗ログ</span>しか取らない
発生するペイン:
- 「動いている」が壊れていないとは限らない
- <span class="regmonkey-bold">特徴量の欠損率</span>急増を見逃す
record5:
アンチパターン: ダッシュボード乱立
ルール・観点:
- 各 PJ が<span class="regmonkey-bold">独自ダッシュボード</span>を作り横断視点がない
発生するペイン:
- 数字の定義が PJ ごとにバラバラ
- 経営報告時に<span class="regmonkey-bold">数字が合わない</span>
record7:
アンチパターン: A/B テスト<br>の事後解析依存
ルール・観点:
- 配信中の指標を観測せず<span class="regmonkey-bold">終了後にまとめて分析</span>する
発生するペイン:
- 致命的な逆効果に気付かず<span class="regmonkey-bold">損失が拡大</span>
- 早期停止判断の機会を逃すツールから業務を組み立てると，ツールの機能と制限がそのまま組織の限界になる
ツール駆動チームに起きること
ミッション駆動チームに切り替える
エージェント常駐の負荷は小さい．観測しないリスクの方が圧倒的に大きい
観察者効果（Observer Effect）への過剰反応
現代インフラでの実態と対処
メトリクスを記録しているが「何が起きたか」が説明できない状態は監視と呼べない
監視のための監視に陥っている症状
パフォーマンス管理・意思決定起点で再設計
CPU 使用率の閾値ではなく，サービスが提供できているかを監視軸にする
「動いている」をオーナーと最初に合意する
よくある誤り：CPU 使用率を主指標にする
正しい扱い：補助指標としての CPU
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
専門ツールの組み合わせ・ユーザー視点・SaaS活用・継続的改善が柱
record1:
デザインパターン: 組み合わせ可能<br>な監視
ルール:
- 専門特化したツールを<span class="regmonkey-bold">疎結合で束ね</span>，監視「プラットフォーム」として運用する
- 一枚岩の万能ツールではなく，<span class="regmonkey-bold">交換可能な部品</span>の集合として設計する
代表アクション:
- UNIX 哲学に倣う
- 収集・蓄積・可視化・通知を分離
- API 連携・標準フォーマット（OpenMetrics 等）
record2:
デザインパターン: ユーザー視点<br>の監視
ルール:
- 実装の内部状態ではなく <span class="regmonkey-bold">サービスが使えるか</span> を測る
- 内部メトリクスは <span class="regmonkey-bold">原因分析の補助</span> として位置付ける
代表アクション:
- HTTP レスポンスコード・レイテンシ
- エラー率・スループット
- RUM / Synthetic で実体感を計測
record3:
デザインパターン: 作るのではなく<br>買う
ルール:
- ユニークな問題以外は <span class="regmonkey-bold">SaaS 監視ツールを購入</span> する
- 自前開発は <span class="regmonkey-bold">人時・逸失利益</span> を含めると割高になりがち
代表アクション:
- Datadog・New Relic・Splunk
- Grafana Cloud・Honeycomb
- 標準は SaaS，差別化要件のみ内製
record4:
デザインパターン: 継続的改善
ルール:
- 監視ニーズの変化に合わせ <span class="regmonkey-bold">柔軟に組み替える</span> 組織を作る
- <span class="regmonkey-bold">アラート・ダッシュボードを定期棚卸し</span>し，陳腐化を防ぐ
代表アクション:
- 毎日アラート一覧をレビュー
- 四半期ごとに SLO・閾値を見直す
- ポストモーテムを次の監視設計に反映UNIX 哲学に倣い，専門ツールを疎結合で束ねる
UNIX 哲学：1つのことを行い，またそれをうまくやるプログラムを書け．協調して動くプログラムを書け．
① データ収集・蓄積系
データ収集
エージェント・Exporter で指標を集める（node_exporter・collectd）
メトリクス
イベントを時系列の数値として符号化（Prometheus・Cloud Monitoring）
データストレージ
時系列 DB・ログ基盤に長期保存（InfluxDB・Loki・Elasticsearch）
② 可視化・通知系
可視化
ダッシュボードで人が読める形に（Grafana・Kibana・Datadog）
分析・レポート
トレンド分析・SLO レポート・キャパシティ計画（BI・Looker）
アラート
閾値・異常検知から Action へ通知（Alertmanager・PagerDuty・Opsgenie）
1つのツールに全機能を背負わせるのは絶対にやってはいけない
アンチパターン
オールインワンで全機能を1製品に集約
収集・蓄積・可視化・通知を1ベンダーに丸投げする
ログとメトリクスを同じツールに無理やり押し込む
保持期間・スキーマ要件が違うのに単一基盤で処理する
独自フォーマットで他ツールと接続できない
標準（OpenMetrics・OTLP）を採用せず内製形式で構築する
発生する不具合
ベンダー Lock-in でツール変更コストが跳ね上がる
データのエクスポート・再構築に数か月単位のプロジェクトが必要になる
不要機能のライセンス費を払い続ける
使わない機能を含めた一括契約で TCO が膨張する
他チーム・他プロダクトとのデータ連携が困難
横断分析・ポストモーテム時にデータを統合できない
時系列イベントを起点に，パース可能性で出力先と用途を切り分ける
ログ：タイムスタンプ付きの連続イベント．監視プラットフォームではメトリクスと並ぶ第2の柱
① 非構造化ログ
テキスト行の連なり
人が読みやすいが機械的な集計には正規表現・パーサが必要
適する用途
人手での障害調査・小規模ツールの一時ログ・既存システムの出力
出力例
2026-05-28 12:00:00 ERROR connection refused from 10.0.0.1
② 構造化ログ
Key-Value ペア（多くは JSON）
集計・検索・フィルタリングが高速．BI・ログ基盤との相性が良い
適する用途
大規模システムの可観測性・SLO 計測・相関 ID によるトレース
出力例
{"ts":"2026-05-28T12:00:00Z","level":"ERROR","msg":"connection refused","src":"10.0.0.1"}
実装ではなく「ユーザーが使えているか」がアラートの起点になる
実装視点の監視で起きる問題
ユーザー視点の監視を起点にする
SaaS 監視ツールは人時と逸失利益を考えると割安になる
代表的な SaaS 監視ツール
監視ツールは日進月歩．構築時点の最適解はすぐに陳腐化する
監視は「作って終わり」ではなく，定期的に棚卸し・チューニング・組み替えを行う運用プロセス
① 改善サイクルの仕組み化
毎日のアラートレビュー
前日のアラート一覧を棚卸しし，削除・チューニング候補をリスト化する
四半期ごとの SLO・閾値見直し
プロダクト成熟・トラフィック増減に応じて許容劣化ラインを更新する
ポストモーテムを監視設計に反映
インシデント後の振り返りから「次は早く気付ける」アラートを追加する
② 組織・文化の前提
監視の棚卸しを業務として認める
新規開発と同等の工数として位置付け，定例タスクに組み込む
ツール変更を恐れない
疎結合な監視プラットフォームの設計（パターン1）が前提．Lock-in を避ける
オンコール担当を改善のオーナーにする
現場の痛みを最も知る人がアラート設計の改善提案を出す
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
緊急通知と参考通知を混ぜると，アラート疲れが起きる
record1:
category: 叩き起こす<br>アラート
rule:
- 緊急の問題に対する<span class="regmonkey-bold">タイムリーな Action 実施</span>を促す
actions:
- ログを残す
- チケットを自動生成
- 手順書（runbook）にリンクする
record2:
category: FYI として<br>のアラート
rule:
- 即対応は不要だが<span class="regmonkey-bold">誰かが確認すべき</span>事象を通知する
actions:
- 例：夜間バックアップの失敗
- チャットでの通知が中心
- 蓄積してレポート化通知・手順書・チューニング・自動化の4観点を総合的に設計する
通知・記録
手順書（Runbook）
閾値・チューニング
自動化
6つの問いに答えられる手順書がオンコールを救う
手順書が必ず答えるべき6つの問い
Tips：書きすぎ・複雑すぎを避ける
各アラートに「発動条件・考えられる原因・Action」をセットで書く
record1:
アラート名: ユーザーサインイン<br>失敗率が高い
When（発動条件）:
- 5分で失敗率 <span class="regmonkey-bold">5% 超過</span>
考えられる原因:
- 不正なデプロイ
- <span class="regmonkey-bold">ブルートフォース</span>攻撃
Then（Action）:
- 直近デプロイを確認
- サインインログで攻撃兆候を確認
record2:
アラート名: ユーザーログイン<br>時間が長すぎる
When（発動条件）:
- ログイン時間が <span class="regmonkey-bold">1秒超過</span>
考えられる原因:
- 不正なデプロイ
- <span class="regmonkey-bold">PostgreSQL 性能</span>劣化
Then（Action）:
- 直近デプロイを確認
- DB のクエリ・接続数を確認
record3:
アラート名: 記事作成時間<br>が長すぎる
When（発動条件）:
- 記事作成時間が <span class="regmonkey-bold">1秒超過</span>
考えられる原因:
- 不正なデプロイ
- <span class="regmonkey-bold">PostgreSQL 性能</span>劣化
Then（Action）:
- 直近デプロイを確認
- DB のクエリ・接続数を確認
record4:
アラート名: コメント作成時間<br>が長すぎる
When（発動条件）:
- コメント作成時間が <span class="regmonkey-bold">1秒超過</span>
考えられる原因:
- 不正なデプロイ
- <span class="regmonkey-bold">PostgreSQL 性能</span>劣化
Then（Action）:
- 直近デプロイを確認
- DB のクエリ・接続数を確認呼び出し対応だけでなく，翌日のアラート整理までが業務範囲
オンコール（On-call）とは
オンコールが毎日回すアラート改善サイクル
アラート一覧化
改善・削除を自問
頻度で分類
システム改善提案
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
record1:
Step: 1. 認識
フェーズ: <span class="regmonkey-bold">Detect</span>
やること:
- 監視・ユーザー報告・自動アラートで<span class="regmonkey-bold">インシデント発生を検知</span>する
成果物・出力:
- 検知トリガ（アラート ID・通報チャネル）
record2:
Step: 2. ロギング
フェーズ: <span class="regmonkey-bold">Detect</span>
やること:
- インシデント ID を発番し，<span class="regmonkey-bold">記録システム</span>に登録する
成果物・出力:
- インシデントチケット
- 発生時刻・初動メンバー記録
record3:
Step: 3. 分類
フェーズ: <span class="regmonkey-bold">Triage</span>
やること:
- 種別（障害／パフォーマンス／セキュリティ等）に<span class="regmonkey-bold">カテゴリ分け</span>する
成果物・出力:
- カテゴリラベル
- 関連サービスタグ
record4:
Step: 4. 優先順位付け
フェーズ: <span class="regmonkey-bold">Triage</span>
やること:
- <span class="regmonkey-bold">影響範囲 × 緊急度</span>で SEV1〜SEV4 を決める
成果物・出力:
- SEV レベル
- 対応 SLA
record5:
Step: 5. 初期診断
フェーズ: <span class="regmonkey-bold">Triage</span>
やること:
- 一次対応者が<span class="regmonkey-bold">原因仮説</span>を立て手順書で復旧を試みる
成果物・出力:
- 初期診断レポート
- 暫定対処の試行ログ
record6:
Step: 6. エスカレーション
フェーズ: <span class="regmonkey-bold">Resolve</span>
やること:
- 一次対応で解決不能なら<span class="regmonkey-bold">Level 2 / SME</span> に引き継ぐ
成果物・出力:
- 引き継ぎノート
- 担当者アサイン記録
record7:
Step: 7. 解決
フェーズ: <span class="regmonkey-bold">Resolve</span>
やること:
- 復旧作業を実施し，<span class="regmonkey-bold">サービス正常性</span>を確認
成果物・出力:
- 復旧時刻
- 適用した修正内容
record8:
Step: 8. クローズ
フェーズ: <span class="regmonkey-bold">Close</span>
やること:
- チケットをクローズし<span class="regmonkey-bold">ポストモーテム</span>をスケジュール
成果物・出力:
- クローズ理由
- ポストモーテム議事録
record9:
Step: 9. コミュニケーション
フェーズ: <span class="regmonkey-bold">All Phases</span>
やること:
- 発生中・解決後にステークホルダー・ユーザーへ<span class="regmonkey-bold">継続的に状況を通知</span>する
成果物・出力:
- ステータスページ更新
- 顧客向けレポート現場指揮官・スクライブ・コミュニケーション・SME に分業して認知負荷を下げる
record1:
役割: ① 現場指揮官<br>(Incident Manager)
主担当:
- <span class="regmonkey-bold">意思決定</span>
責務:
- 対応全体の<span class="regmonkey-bold">意思決定者</span>．方針・優先順位・エスカレーション判断を担う
- 関係者にタスクを割り当て，状況を俯瞰する
成功の判定:
- 復旧の優先順位が明確
- 関係者全員が次のアクションを把握
record2:
役割: ② スクライブ<br>(Scribe)
主担当:
- <span class="regmonkey-bold">記録</span>
責務:
- 発言・判断・実行を<span class="regmonkey-bold">時系列で記録</span>する
- 後のポストモーテム・監査の一次資料となる
成功の判定:
- 5W1H が後追いで再構成できる
- 重要判断と理由が残っている
record3:
役割: ③ コミュニケーション<br>調整役
主担当:
- <span class="regmonkey-bold">対外連絡</span>
責務:
- 利害関係者・顧客に<span class="regmonkey-bold">最新情報を伝える</span>
- 解決チームに<span class="regmonkey-bold">問い合わせを流さない</span>防波堤として動く
成功の判定:
- ステータスページが最新
- SME への問い合わせ流入が抑制
record4:
役割: ④ SME<br>(Subject Matter Expert)
主担当:
- <span class="regmonkey-bold">技術復旧</span>
責務:
- 実際に<span class="regmonkey-bold">インシデント対応する人</span>．技術的な調査・復旧作業を担う
- 仮説検証・修正適用・正常性確認まで
成功の判定:
- 復旧が完了している
- 原因仮説と検証手順が残っている補足：レベル（Tier）の意味
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
システム監視と同じく，Issue Finding → Insight → Action が成立しなければ意味がない
Business KPI の役割
KPI を設定する際の5観点
収益・顧客・コスト・成長の各軸で代表指標を押さえる
record1:
category: Monthly Recurring Revenue (MRR)
actions:
- 顧客からの<span class="regmonkey-bold">月ごとの経常利益</span>
record2:
category: Revenue per Customer
actions:
- 顧客ごとの収益．通常は<span class="regmonkey-bold">年単位</span>で見る
record3:
category: Number of Paying Customer
actions:
- <span class="regmonkey-bold">課金顧客数</span>
record4:
category: NPS (Net Promoter Score)
actions:
- ユーザー満足度．<span class="regmonkey-bold">他人に薦める度合い</span>を測る
record5:
category: LTV (Life Time Value)
actions:
- 顧客の<span class="regmonkey-bold">生涯単位</span>での価値を計測
record6:
category: Cost per Customer / CAC
actions:
- <span class="regmonkey-bold">サービス提供コスト</span>と<span class="regmonkey-bold">獲得費用</span>
record7:
category: Customer Churn
actions:
- 離反顧客数．上昇時は<span class="regmonkey-bold">プロダクト・性能・価格</span>に問題のサイン
record8:
category: Active Users (DAU/WAU/MAU)
actions:
- サービスの<span class="regmonkey-bold">アクティブユーザー数</span>
record9:
category: Burn Rate / Run Rate
actions:
- 月次支出と<span class="regmonkey-bold">資金枯渇までの残り期間</span>
record10:
category: TAM (Total Addressable Market)
actions:
- 特定マーケットの<span class="regmonkey-bold">最大規模</span>を示すコア機能の利用イベントを KPI にすると，プロダクトの健全性が直接見える
record1:
KPI: 検索実行
観測する側面:
- プロダクトの<span class="regmonkey-bold">入口</span>の利用状況
健全性が示すこと:
- 検索数の低下は<span class="regmonkey-bold">集客力の悪化</span>を示唆
record2:
KPI: レビュー投稿
観測する側面:
- UGC（ユーザー生成コンテンツ）の<span class="regmonkey-bold">供給量</span>
健全性が示すこと:
- 投稿減はコンテンツ枯渇 → <span class="regmonkey-bold">検索品質低下</span>に波及
record3:
KPI: ユーザーのサインアップ
観測する側面:
- 新規ユーザーの<span class="regmonkey-bold">流入速度</span>
健全性が示すこと:
- サインアップ減速は<span class="regmonkey-bold">成長鈍化</span>の先行指標
record4:
KPI: ビジネスページの取得
観測する側面:
- <span class="regmonkey-bold">需要側</span>（探す側）のアクション
健全性が示すこと:
- 取得数増加は需要の活性化．広告購入の<span class="regmonkey-bold">先行指標</span>
record5:
KPI: アクティブユーザー・<br>アクティブビジネス
観測する側面:
- 両サイドマーケットの<span class="regmonkey-bold">健全性</span>
健全性が示すこと:
- 片側の減少は<span class="regmonkey-bold">マーケットの偏り</span>を示す
record6:
KPI: 広告購入
観測する側面:
- <span class="regmonkey-bold">収益化</span>指標
健全性が示すこと:
- 収益の直接KPI．需要側のアクションと連動して観測
record7:
KPI: レビューに対する返事
観測する側面:
- エンゲージメント・<span class="regmonkey-bold">コミュニティ活性度</span>
健全性が示すこと:
- 返事率低下は<span class="regmonkey-bold">事業者側の関心離脱</span>の兆候動作確認だけでなく，パフォーマンスを収益インパクトと接続して語る
なぜパフォーマンス評価が重要か
① Navigation Timing API
② Speed Index / Lighthouse
監視とは何か
監視のアンチパターン
監視のデザインパターン
アラート・オンコール・インシデント管理
インシデント管理
ビジネス監視・フロントエンド監視
Appendix
record1:
category: 監視の<br>原則
rule:
- 監視は<span class="regmonkey-bold">ミッションドリブン</span>で設計し，Issue Finding を Action に接続する
actions:
- 「動いている」の定義をオーナーと合意する
- パフォーマンス管理・改善を起点に置く
- 監視は全員で行う
record2:
category: アンチ<br>パターン
rule:
- <span class="regmonkey-bold">ツール依存</span>と<span class="regmonkey-bold">監視のための監視</span>を避ける
actions:
- メトリクス収集は最低 60 秒間隔
- 履歴を保存し，傾向を追えるようにする
- 誤検知の多いアラートは削除・チューニング
record3:
category: デザイン<br>パターン
rule:
- <span class="regmonkey-bold">専門ツールを疎結合</span>で組み，ユーザー視点で測り，SaaS を活用する
actions:
- HTTP コード・レイテンシでサービス品質を測る
- 可用性は依存先の SLA で上限が決まる
- 標準業務は SaaS，固有要件のみ自前開発
record4:
category: アラート・<br>オンコール
rule:
- <span class="regmonkey-bold">手順書とログ</span>でアラートを「対応可能な情報」にする
actions:
- チャット通知＋手順書リンクをセット
- 自動復旧を先に試す
- 毎日アラートを棚卸ししシステム改善提案
record5:
category: ビジネス・<br>フロント
rule:
- <span class="regmonkey-bold">Business KPI と RUM/Synthetic</span> で観測を経営とユーザー体感に接続する
actions:
- コア機能の利用イベントを KPI 化
- Navigation Timing・Speed Index で性能計測
- 改善は収益インパクトで語る「9 の数」で可用性を表し，ナイキスト・シャノン定理で計測間隔を決める
可用性 = 稼働時間 / 総稼働時間．サービスの可用性は下位レイヤの可用性を超えない
① ナイキスト・シャノンのサンプリング定理
② 依存コンポーネントの天井
Regmonkey Presentation. ©Ryo Nakagami. All rights reserved.