30秒でわかるまとめ#

モニタリング: システムは動作していますか?(Yes/No)
オブザーバビリティ: なぜシステムが壊れたのですか?(根本原因の分析)
ロギング: 何が起きましたか?(イベントの記録)

モニタリングはYES/NOの質問に答えます。オブザーバビリティではシステムに関するあらゆる質問ができます。ロギングはデータ収集であり、モニタリングとオブザーバビリティはその分析です。

多くのチームはこれらの用語を区別せずに使っています。その結果、混乱・予算の肥大化、そして最悪の場合は緊急時の盲点を生み出してしまいます。

なぜ重要なのか(混同による本当のコスト)

エンジニアリングチームが新しいコードをデプロイしました。30分後、決済処理が遅くなり始めます。次のような流れが起こります。

オブザーバビリティがない場合(従来のやり方):

アラートが発火:「Payment APIのレスポンスタイムが3秒超」
オンコールエンジニアがダッシュボードを開く:レスポンスタイムのグラフが見えるだけ
エンジニアは推測を始める:「データベースの問題?ネットワーク?最近のデプロイ?」
エンジニアがログを手動で確認:30分で50万行のログ。どこを見れば?
45分のデバッグの末:新しいコードが遅いSQLクエリを追加していた
インシデント時間:1時間。売上ロス:約$7,000

オブザーバビリティがある場合(モダンなやり方):

アラートが発火:「Payment APIのレスポンスタイムが3秒超」
オンコールエンジニアがオブザーバビリティのダッシュボードを開く
ダッシュボードが自動で示唆:「新しいコードがpayment_verificationテーブルに対するN+1クエリを追加」
エンジニアは直接そのクエリに飛んで最適化
インシデント時間:5分。売上ロス:約$600

違い: 1件のインシデントで55分の節約 + $6,400の売上を救えました。

月に2〜3件のインシデントが起きる企業なら、オブザーバビリティのROIは年間$100K+を簡単に超えます。

モニタリングとは(古くからの基盤)

モニタリングは次の問いに答えます: 今、システムはちゃんと動いていますか?

モニタリング = ブール値(Yes/No)の問い#

サーバーはリクエストに応答していますか?(Yes/No)
レスポンスタイムは2秒未満ですか?(Yes/No)
データベースのCPUは80%未満ですか?(Yes/No)
エラー率は1%未満ですか?(Yes/No)
この合成テストはパスしましたか?(Yes/No)

モニタリングの仕組み

メトリクスを収集: 60秒ごとにレスポンスタイムをチェック
しきい値と比較: レスポンスタイムが2秒を超えたらアラート発火
違反したらアラート: オンコールエンジニアにページ通知

モニタリングはバイナリ(二値)です。 ルールを定義し、システムがそれを強制します。ルールが破られるとページ通知が来る。それがモニタリングです。

モニタリングの限界

モニタリングは何かが間違っていることは教えてくれますが、なぜ間違っているかは教えてくれません。

例:

アラート:「データベースCPUが95%」
モニタリングが示すもの:CPUグラフが急上昇
しかし分からないこと:なぜCPUが高いのか?どのクエリ?どのユーザー?新しいコード?突発的なトラフィック急増?

調べるためには手作業で深掘りするしかありません。ここでオブザーバビリティの出番です。

オブザーバビリティとは(モダンなアプローチ)

オブザーバビリティは次の問いに答えます: なぜシステムが動いていないのですか?

オブザーバビリティ = 無限の問い

「Xは真ですか?」と尋ねるのではなく、システムについて任意の質問ができます。

「どのクエリがCPUの急上昇を引き起こしたのか?」
「このデプロイ後になぜレスポンスタイムが増えたのか?」
「どのユーザーが影響を受けたのか?」
「アラート発火の2分前にシステムで何が変わったのか?」
「過去1時間で5秒以上かかったリクエストは?」
「今日のエラー率は先週の同じ時間と比べてどうか?」

オブザーバビリティがあれば、システムの挙動に関するあらゆる質問に答えられます。

オブザーバビリティの3本柱#

柱1:メトリクス(何が起きたかを数値で)

レスポンスタイム:1.2秒
エラー率:0.5%
1秒あたりのデータベースクエリ数:1,200
メモリ使用量:4.2GB
これらは集計・要約されたデータポイントです

柱2:ログ(何が起きたかを詳細に)

「ユーザーjohn@example.comがログイン」
「決済検証クエリに1.2秒かかった」
「タイムアウトによりデータベース接続がクローズ」
詳細で粒度の細かいイベント。データ量は膨大です。

柱3:トレース(リクエストがシステム内をどう流れたか)

ユーザーが決済を送信 → APIハンドラ → データベースクエリ → 決済ゲートウェイ呼び出し → メールサービス
リクエストがたどった完全な経路と、どこで時間を費やしたかを示す
サービス横断の分散トレーシング

オブザーバビリティの仕組み

すべてを計装: すべてのコードパスにロギングを追加
データを収集: メトリクス、ログ、トレースを取得
データを保存: 長期保存(数週間〜数ヶ月の履歴)
自由にクエリ: システム挙動について任意の質問
自動で相関: 「このCPU急上昇はこのコードパスと相関」「このエラーはこのユーザー操作と相関」

モニタリング vs オブザーバビリティ:横並び比較#

観点	モニタリング	オブザーバビリティ
質問の種類	Xは真か?	なぜXが起きているのか?
データポイント数	10〜50のメトリクス	数百万のデータポイント
セットアップ時間	短い(1時間)	長い(1〜2週間)
学習コスト	シンプル(ダッシュボード)	急峻(クエリ言語)
MTTR(平均修復時間)	30〜60分	5〜10分
コスト	$100〜500/月	$1,000〜5,000/月
適した用途	「システムは稼働中?」	「なぜシステムが壊れた?」
限界に達するタイミング	サービス5以上、アラート10以上	スケールしても通用

3レイヤー構成(多くのチームの実態)#

レイヤー1:モニタリング(基本 — 必ず必要)#

すべての人にとって標準的なアップタイムモニタリング:

ウェブサイトの可用性:ホームページは2秒未満で応答するか?
APIヘルス:重要なエンドポイントは応答するか?
サードパーティ依存:Stripeに到達できるか?
インフラの基本:CPU、メモリ、ディスク容量

ツール例: UptimeRobot、Pingdom、Hyperping、Datadog(基本ティア)

コスト: $20〜100/月

セットアップ時間: 1〜2時間

必要になるタイミング: 1日目、サービス1〜2個の小規模スタートアップ

レイヤー2:基本的なロギング(詳細 — おそらく必要)#

モニタリングが「何かおかしい」と教えてくれたとき、どこを見ますか?

ログは何が起きたかを示します:

エラーメッセージ:「データベース接続タイムアウト」
リクエストの詳細:ユーザーID、リクエストパス、レスポンスコード
ビジネスイベント:「ユーザーが商品を購入」「決済失敗」
システムイベント:「サーバー起動」「メモリ圧迫を検知」

ツール例: Datadog、New Relic、Better Stack、ELK Stack

コスト: $100〜500/月

セットアップ時間: 2〜4時間(基本)、1〜2週間(包括的)

必要になるタイミング: モニタリングのアラートが日に5回以上発生し、根本原因が見つけられないとき

レイヤー3:本格的なオブザーバビリティ(理解 — スケール時に必要)#

ログを取り始めると、メトリクスとトレースとの相関を取りたくなります。

オブザーバビリティで以下が可能になります:

どのコードパスがアラートを引き起こしたかが分かる
リクエストが10サービスをどう流れたかを理解できる
ユーザー行動 → アプリケーション挙動 → インフラへの影響を相関させられる

ツール例: Datadog(フルスタック)、Dynatrace、New Relic、Splunk

コスト: $1,000〜10,000+/月

セットアップ時間: 2〜4週間(包括的)

必要になるタイミング: マイクロサービス10個以上、エンジニア5人以上、複雑な分散システム

実例:APIレスポンスタイムのアラート#

シナリオ: 決済APIのレスポンスタイムが3秒に急上昇(通常:500ミリ秒)

モニタリングだけの場合

アラート発火:「Payment APIレスポンスタイム3000ms」
見えるもの:レスポンスタイム急上昇のグラフ
考えること:「データベースの問題?負荷急増?バグ?」
確認:サーバーCPU(正常)、メモリ(正常)、コネクション数(正常)
確認:最近のデプロイ(直近2時間でなし)
確認:トラフィックログ(トラフィックが2倍)
確認:データベースログ(payment_verification関連クエリが大量)
ようやく:ログから遅いクエリを発見
経過時間:45分

オブザーバビリティがある場合

アラート発火:「Payment APIレスポンスタイム3000ms」
見えるもの:オブザーバビリティのダッシュボードが自動で表示:
  - 遅いコードパス:payment_verification
  - クエリ:SELECT * FROM users ...(N+1クエリを検出)
  - トリガーしたユーザー:john@example.com
  - 開始時刻:新コードがデプロイされたまさにその時
  - 影響を受けたリクエスト:2,000件中150件
見えるもの:遅いコードの正確なスタックトレース
修正:クエリを最適化
経過時間:5分

違い:

オブザーバビリティなし:根本原因まで45分
オブザーバビリティあり:根本原因まで5分
1インシデントで救った売上:約$6,500

ロギング:基盤(ただしモニタリングでもオブザーバビリティでもない)

ロギングはデータ収集です。モニタリングとオブザーバビリティはデータ分析です。

ロギングとは

イベントを中央のロケーションに書き出すこと:

// アプリケーション内で
logger.info("User logged in", {
  user_id: "12345",
  timestamp: "2026-02-20T14:23:45Z",
  ip_address: "203.0.113.42"
})

logger.error("Payment verification failed", {
  user_id: "12345",
  amount: 99.99,
  error: "Stripe API timeout",
  duration_ms: 5000
})

ログは書き込まれ、保存され、検索可能になります。

ロギングの限界

データが多すぎる: 一般的なウェブアプリは1秒あたり1,000行以上のログを生成します。1時間で100万行を検索するのは苦痛です。

コンテキストがない: 「決済失敗」と書かれていても、それが攻撃の一部なのか、システム全体の問題なのか、孤立した事象なのかは分かりません。

相関がない: 1件の決済失敗ログを見ても、同時に発生している500件の類似失敗は見えません。

ロギングはオブザーバビリティの基盤

オブザーバビリティを構築するには良いロギングが必要です。しかしロギング単体ではオブザーバビリティになりません。

どれをいつ使うか(ディシジョンツリー)

始めたばかりですか?
├─ Yes → モニタリングだけ使う
│       (UptimeRobot、Hyperping)
│       焦点:システムは稼働中か?
│       コスト:$20〜50/月
│       セットアップ:1時間

月に5件以上のインシデントをデバッグしていますか?
├─ Yes → ロギングを追加
│       (Datadog、Better Stack)
│       焦点:何が起きたか?
│       コスト:追加$100〜300/月
│       セットアップ:基本2〜4時間、包括1〜2週間

マイクロサービスを5つ以上、またはエンジニアが10人以上ですか?
├─ Yes → オブザーバビリティへ移行
│       (Datadogフルスタック、Dynatrace、Splunk)
│       焦点:なぜ起きたか?
│       コスト:$1,000+/月
│       セットアップ:2〜4週間

エンタープライズ規模(エンジニア100人以上)?
└─ Yes → すべて必要
        (本格的なオブザーバビリティ + 専門ツール)
        コスト:$5,000+/月
        セットアップ:継続的、専任1〜2名

よくある誤解

誤解1:「オブザーバビリティは派手なロギングに過ぎない」#

現実: オブザーバビリティはメトリクス + ログ + トレースの組み合わせであり、それらを自動的に相関させる能力です。

ロギングはオブザーバビリティの一部ですが、すべてではありません。メトリクス(レスポンスタイム、エラー率)とトレース(分散トレーシング)も必要です。

誤解2:「ログが多いほどオブザーバビリティが高い」#

現実: 100万行のログも検索できなければ無意味です。質 > 量です。

戦略的にログを取りましょう:

エラーは必ずログ
ビジネスイベント(購入、ログイン、決済)
パフォーマンス問題(遅いクエリ、タイムアウト)
関数呼び出しすべてをログには残さない(ノイズになる)

誤解3:「モニタリングはどんな問題も検知できる」#

現実: モニタリングはルールに合致した問題だけを検知します。ルール外の問題は検知されません。

例:「レスポンスタイムが3秒を超えたらアラート」というルールがあるとします。しかし通常1.5秒のレスポンスタイムが、デプロイ後に2.5秒になった場合、67%の増加でもしきい値は超えません。モニタリングはアラートを出しません。オブザーバビリティなら出せます。

誤解4:「オブザーバビリティはモニタリングを置き換える」#

現実: オブザーバビリティはモニタリングを基盤として必要とします。

重要な問題のためのアラートはやはり必要です。同時に調査する能力も必要です。

誤解5:「オブザーバビリティは高価なはず」#

現実: オープンソースのオブザーバビリティツールはたくさんあります。自前で構築することも可能です。

ただし保守にエンジニアリング工数が必要です。多くのチームにとって、SaaS型オブザーバビリティ($1,000〜5,000/月)はインフラ保守の人件費より安く済みます。

オブザーバビリティ戦略の構築

フェーズ1:モニタリングの基盤(1ヶ月目)#

コアとなるアップタイムモニタリングを設定
重要なエンドポイントを監視
3リージョン検証(誤検知を排除)
アラートのルーティング(critical = ページ通知、warning = Slack)

コスト: $50/月 ツール: UptimeRobot、Hyperping、または Nova Uptime

フェーズ2:ロギングを追加(2〜3ヶ月目)#

構造化ロギングでコードを計装
エラー、ビジネスイベント、パフォーマンスメトリクスをログ
ログ集約をセットアップ
ログ検索用のダッシュボードを構築

コスト: 追加$100〜200/月 ツール: Datadog、Better Stack、ELK Stack

フェーズ3:分散トレーシング(4〜6ヶ月目)#

サービス横断のリクエストをトレース
トレースとログを相関
リクエストフロー内のボトルネックを特定

コスト: 追加$200〜500/月 ツール: Datadog、New Relic、Jaeger

フェーズ4:本格的なオブザーバビリティ(6ヶ月目以降)#

メトリクス + ログ + トレースを統合
異常検知ベースの自動アラート
ML駆動の根本原因分析
履歴分析とトレンド検知

コスト: $1,000〜5,000+/月 ツール: Datadog、Dynatrace、Splunk

オブザーバビリティツール比較(2026年)#

ツール	モニタリング	ロギング	トレーシング	価格	適した用途
UptimeRobot	優秀	なし	なし	$10/月	シンプルなウェブサイト
Hyperping	優秀	限定的	なし	$24/月	SaaS、APIチーム
Datadog	優秀	優秀	優秀	$100+	エンタープライズ、オールインワン
Better Stack	優秀	優秀	限定的	$50/月	中堅市場
New Relic	優秀	優秀	優秀	$100+	エンタープライズAPM
Splunk	限定的	優秀	優秀	$200+	エンタープライズ、データ分析
ELK Stack	なし	優秀(自前ホスト)	限定的	自前ホスト	コスト重視のチーム
Dynatrace	優秀	優秀	優秀	$500+	大企業
Grafana	優秀	限定的	限定的	$50+(自前ホスト)	オープンソース重視

まとめ:モニタリング vs オブザーバビリティ#

モニタリング = 「システムはちゃんと動いていますか?」(Yes/No)

10〜50のメトリクス
ルールベースのアラート
シンプルなダッシュボード
ウェブサイトやシンプルなアプリに最適
コスト:$20〜100/月

オブザーバビリティ = 「なぜシステムが壊れているのか?」(根本原因)

数百万のデータポイント
自由形式のクエリ
複雑なダッシュボード
マイクロサービスには必須
コスト:$1,000〜5,000+/月

ロギング = 「何が起きましたか?」(データ収集)

生のイベント
検索可能な履歴
オブザーバビリティの基盤
デバッグに必須

多くのチームに必要なもの:基盤としてモニタリング + ロギング、スケールに応じてオブザーバビリティを追加。

アップグレードのタイミング:

モニタリング単体:サービス1〜2個まで通用
- ロギング:サービス3〜5個、エンジニア2〜3人まで通用
- オブザーバビリティ:サービス10個以上、エンジニア5人以上、複雑な依存関係には必須

オブザーバビリティに早期投資しすぎないこと(高価で複雑)。同時に投資が遅すぎてもいけません(複雑性が増すほどMTTRが悪化します)。

次のステップ

モニタリングしか持っていない場合: 今週中に構造化ロギングを追加してください。低コストで効果大です。
ログがある場合: エラーとデプロイを相関させるダッシュボードを構築してください。根本原因の理解を始めましょう。
スケールに達している場合: 分散トレーシングに投資してください。複雑なシステムをデバッグする鍵です。

モニタリングからオブザーバビリティへ移行する準備ができましたか? 基盤としてNova Uptimeのアップタイムモニタリングから始めて、成長に合わせてロギングとトレーシングを重ねていきましょう。