はじめに
最近「オブザーバビリティ」の相談が増えました。
私の所属する会社が各オブザーバビリティツールのベンダーと提携している影響もあります。
ただ、流行だけで導入検討が進む場面も増えています。
その背景として、AWS や Microsoft のような IT ベンダーが、運用の文脈でオブザーバビリティを強く打ち出しています。
技術的にも OpenTelemetry が広まり、主要サービスで連携前提の設計が一般化してきました。
自分たちの規模で本当にトレースまで要るのか。導入と運用にかかる費用は見合うのか。仮に作ったところで、そのダッシュボードを誰が見るのか。こうした疑問は、現場ではかなり自然な問いです。
この記事では、その疑問にフラットに向き合います。
導入すべき・すべきでないを最初から決めつけず、判断材料を並べる構成です。
最後の章では、LLM エージェントと MCP（Model Context Protocol）を使った、もう一つの運用の選択肢にもつなげます。
検証前提
- 対象読者: 監視運用を設計する開発者 / SRE / 情シス
- 記事タイプ: 解説（ハンズオンなし）
- 検証日: 2026-07-23
第1章 そもそもオブザーバビリティが目指すところ
従来の監視は、しきい値超過や 5xx など「既知の異常」を見つける仕組みでした。
一方でオブザーバビリティは、事前に想定できていない「未知の障害」に、その場で対応するための設計です。
未知の障害では、事前に用意したパネルやアラートは効きません。
そのため、障害時に「どこで・なぜ」を特定し、次の一手を決めるまでの時間そのものがボトルネックになります。
この時間を縮めるほど MTTR（Mean Time To Recovery: 平均復旧時間）は短くなり、事業影響も小さくできます。
つまり、オブザーバビリティは可視化ツールではなく、未知の障害に直面したときの意思決定時間を短縮するための投資です。
ログ・メトリクス・トレースの 3 本柱は、この投資を成立させるための手段にすぎません。
第2章 必要性をフラットに分析する
第 1 章の主張を裏返すと、「未知の障害が発生した時に、意思決定時間の短縮がどれだけ効くか」で必要性が決まると言えます。
この観点で見るべきは、システムの複雑さと障害インパクトの 2 軸です。
複雑さもインパクトも小さいシステムなら、フル装備のオブザーバビリティは過剰投資になります。
判断軸を整理すると次のようになります。
| 観点 | 必要性が低いケース | 必要性が高いケース | 意思決定時間への効き方 |
|---|---|---|---|
| 構成 | モノリス、サービス数が少ない | マイクロサービス、依存関係が複雑 | 原因の切り分け範囲が広いほど、可観測性の投資が効く |
| 障害インパクト | 内部利用、影響範囲が限定的 | 顧客影響が大きい、SLA を持つ | 1 分の短縮が売上や SLA に直接跳ね返る |
| 変更頻度 | リリース頻度が低い | 継続的デプロイで変更が頻繁 | 変更起因の未知障害が増えるほどリターンが大きい |
| チーム体制 | 開発者が全体を把握できる規模 | チームが分かれ、暗黙知が共有されにくい | 属人化の代替として観測データが必要になる |
担当者 1 〜 2 人で全体を把握できる社内ツールなら、詳細トレースよりシンプルなログとアラートの方が費用対効果に優れる場面が多いです。
逆に、複数チームが関わって障害が売上に直結する顧客向けサービスでは、意思決定時間 1 分の短縮が明確な金額換算になり、投資妥当性は高くなります。
もう 1 つ重要なのは、0 か 100 かで考えないことです。
ログ構造化だけで意思決定時間が縮むケースもあれば、分散トレーシングまで踏み込まないと未知障害に対応できないケースもあります。
判断のステップとしては、次の順が現実的です。
- まず、直近の障害で「どこで時間を溶かしたか」を棚卸しする
- その時間を縮められる観測要素（ログ / メトリクス / トレース）を特定する
- 特定した要素に絞って段階的に投資する
このステップで必要性の輪郭が決まると、次章のコスト議論が「機能表の比較」ではなく、縮めたい意思決定時間に対して払える金額はいくらかという具体論に変わります。
第3章 コストという大きな壁
必要性を理解しても、導入を止めるのはだいたいコストです。
ここでは SaaS 型の代表例として Datadog を軸に整理します。
コストは大きく 3 つです。
- 導入コスト（計装工数）: Agent 導入、計装、標準監視設計、運用ルール整備にかかる工数です。
- 運用コスト（従量課金 + 保持）: ログ、トレース、メトリクスの収集量と保持日数に比例して増えます。
- 学習コスト: クエリ、ダッシュボード、アラート設計を使いこなすまでの習熟コストです。
Datadog の強みは、機能が広くて立ち上がりが速いことです。一方で、機能が広いぶん、使わない機能まで契約に乗りやすく、費用が読みにくくなります。
特にコストが跳ねやすいのは、APM とログ取り込みです。ここは先に上限設計をしないと、請求が後追いになります。
導入時の見積もりが妥当に見えても、半年後の請求で驚くケースは珍しくありません。原因の多くは「収集対象の増加」と「保持日数の延伸」です。
ここは単価暗記より、Datadog 公式料金表の課金単位に合わせて試算式を固定した方が外しません。
月額概算
= Infrastructure host 課金（$/host/月）
+ APM host 課金（$/APM host/月）
+ Logs Ingestion 課金（$/GB/月）
+ Indexed Logs / Indexed Spans 課金（保持日数別）
+ その他オプション課金
たとえば、条件を次のように置きます。
- 20 ホスト
- ログ 80 GB/日
- 保持 15 日
- APM 対象 10 サービス
この条件だと、小規模でも月額は「数万円で確実に収まる」より「数十万円帯に入る可能性がある」前提で予算化した方が安全です。
ここは保守的に見積もるべきです。
料金表参照先（Datadog 公式）:
- Datadog Pricing List（取得日: 2026-07-23）
最終的に最も確実なのは、販売会社または Datadog への問い合わせで見積もりを取得することです。ここは迷わず聞くのがベストです。
もう 1 つ重要なのは、本当にこの機能群が必要かを都度問うことです。機能が増えるほど、設定を理解している人しか触れない状態になり、俗人化を押しやすくなります。
第4章 ダッシュボードの必要性と落とし穴
監視でもオブザーバビリティでも、最初に成果として見えるのはダッシュボードです。本来は、状態を俯瞰して次のアクションを決めるための手段です。
ところが実際には、ダッシュボード作成が目的化しやすいです。
- 初期に作り込んだ画面が数か月後に見られない
- メトリクスが増え続けて、何を見るべきか分からない
- アラートにつながらないグラフが並ぶ
- 障害時に結局は担当者の勘で調査が進む
見直しの目安は次のとおりです。
| ありがちな状態 | 本来目指したい状態 |
|---|---|
| メトリクスが増える一方で減らない | 見ないパネルは棚卸しして削除する |
| グラフを眺めるだけで終わる | 異常値が出た時の次アクションが決まっている |
| 障害後にしか開かれない | 平常時から俯瞰の習慣として使われる |
より具体的な見直し基準は、次の 5 つです。
- 30 日間で参照回数 0 のパネルは削除候補にする
- オーナー不明のパネルは「仮オーナー設定」か「削除」を 2 週間以内に決める
- アラートに紐づかない可視化パネルは「意思決定用途」を 1 行で定義できなければ削除する
- 1 つの障害で 3 画面以上横断しないと原因に届かない構成は再設計する
- 月 1 回の棚卸しで、追加パネル数より削除パネル数が少なくとも同数になるよう運用する
ここで、第 3 章の議論を MCP 展開までつなげるために、SaaS の利点と欠点を整理します。
| 観点 | SaaS（Datadog）の利点 | SaaS（Datadog）の欠点 | MCP 展開への示唆 |
|---|---|---|---|
| 導入速度 | 立ち上げが速く、短期で価値を出しやすい | 設計が甘いまま拡張しやすい | 観測基盤は SaaS、調査導線は MCP に分離 |
| 機能の網羅性 | APM、ログ、RUM などを横断しやすい | 不要機能まで抱えやすい | 「使う機能」を固定し、MCP に渡すデータを絞る |
| 運用スキル | GUI で開始しやすい | 高度化すると特定担当者依存になりやすい | 質問テンプレートを MCP 側に持たせ、属人化を下げる |
| ダッシュボード | チーム共有のハブとして強い | パネル乱立で意思決定が遅くなる | 俯瞰用だけ残し、深掘りは MCP 対話に寄せる |
結論として、ダッシュボードは今でも必要です。
ただし、全分析をダッシュボードで完結させる設計は重くなります。
平常時の俯瞰はダッシュボード、深掘り調査は MCP に分ける方が、コストと俗人化を同時に抑えやすいです。
第5章 もうMCPだけでいいのでは？
前章の落とし穴の根っこには、人間が能動的にダッシュボードを見に行かないと情報が活用されないという構造があります。開発者や SRE が忙しいほど、この運用は回りにくくなります。
そこで有効なのが、MCP を通じて LLM エージェントに観測データを問い合わせる運用です。
- 「昨日比で、このサービスのレイテンシはどう変化したか」
- 「エラー率が上がっているサービスはどこか」
こうした問いを自然言語で投げると、ログ・メトリクス・トレースを横断して答えを返せます。
想定外の切り口に即応できる点は、定型パネル中心の運用にない強みです。
さらに、エージェントは定期実行にもできます。能動的に日次・週次で異常傾向を問い合わせる設計にすると、「見に行く運用」から脱却しやすくなります。
私はこの方向性を検証するために、o11y 向け MCP サービスの OSS を公開しました。
詳細紹介は別記事で書きますが、この記事では「SaaS を捨てる」のではなく、「SaaS の強みを残しながら調査体験を MCP で再設計する」ことを主張します。
- OSS 公開先: yuuki-0928 on GitHub
MCP サーバーを使う利点は拡張性です。問い合わせ先を PagerDuty や Azure MCP へ広げることで、観測だけでなく通知・一次切り分けまで連携可能になります。
一方でデメリットもあります。メトリクス可視化を都度エージェント経由で実行すると、通信量やトークン消費が膨らみやすいです。ここは実装前に上限設計が必要です。
この課題に対して、私の OSS では Grafana ダッシュボード作成を組み込んでいます。定常可視化はダッシュボードに寄せ、エージェントは深掘り質問に集中させる狙いです。
ダッシュボードと MCP エージェントの得意領域は次のとおりです。
| 得意な場面 | ダッシュボード | MCP エージェント |
|---|---|---|
| 日常の俯瞰 | ◎ 一目で全体像を把握できる | △ 毎回聞かないと状況が分からない |
| 想定外の質問 | △ 用意された切り口でしか見られない | ◎ 自由な切り口で深掘りできる |
| 違和感への気づき | ◎ グラフの形の変化で直感的に気づける | △ 言語化しないと質問できない |
| チームでの共有 | ◎ 同じ画面で議論しやすい | △ 個別対話になりやすい |
こうして並べると、日常俯瞰はダッシュボード、深掘りは MCPという分担が現実的です。
ここはまだ未解明の論点もあります。
MCP 運用は初動を速めやすい一方で、長期的にはプロンプト設計と権限設計の品質が効きます。
この点は運用データをためて、続編で検証結果を出します。
おわりに
オブザーバビリティツールは、流行っているから入れるものではありません。目指すべきは意思決定を速くすることです。必要性はシステムの複雑さと障害インパクトで変わり、コストは便益と突き合わせて判断すべきです。
ダッシュボードは必要です。
ただし、目的化するとすぐ重くなります。
Datadog などの SaaS を観測基盤として活かしつつ、調査導線を MCP へ分離する設計は、今の現場に合うと私は考えています。
最後は、自分たちの運用で何が本当に必要な投資かを、自分たちで決めるしかありません。この記事がその判断材料になればうれしいです。
参考文献
- OpenTelemetry 公式ドキュメント（取得日: 2026-07-23）
- AWS Distro for OpenTelemetry（取得日: 2026-07-23）
- Azure Monitor OpenTelemetry 概要（取得日: 2026-07-23）
- Model Context Protocol 公式（取得日: 2026-07-23）
- Datadog Pricing（取得日: 2026-07-23）
- Datadog Pricing List（取得日: 2026-07-23）
- DMM Developers Blog: オブザーバビリティ成熟度モデル（取得日: 2026-07-23）