- はじめに
- オブザーバビリティの必要性：なぜ「監視」だけでは足りないのか
- AI時代にこそオブザーバビリティが重要
- 現状把握が改善の第一歩
- ツール選定
- 判断基準（個人的な見解）
- まとめ
- (補足)オブザーバビリティを実現するためには
- 宣伝
はじめに
こんにちは、サーバーワークスの福田です。
今回は、昨今のAIブームに伴って改めて重要性が増している「オブザーバビリティ（可観測性）」について、その必要性と導入に向けた考え方を整理してみたいと思います。
オブザーバビリティの必要性：なぜ「監視」だけでは足りないのか
「うちは既に監視を入れているから大丈夫」と思われる方も多いかもしれません。しかし、現代のシステム運用では、オブザーバビリティは万が一の際にビジネスへの影響を最小限に抑えるための重要な要素です。
従来の「監視」と「オブザーバビリティ」の違いは、「異常に気づく」ことと「原因を素早く特定して改善する」ことの違いです。
- 従来の監視（Monitoring）
- 「熱が39度あります」と教えてくれるもの
- 異常が起きたことはわかりますが、「なぜそうなったのか」までは教えてくれません
- オブザーバビリティ（Observability）
- 「喉の炎症が原因で熱が出ています」と、原因と事象を具体的に特定できる状態
シンプルなシステムなら「サーバーが落ちた→再起動」で対処できました。しかし複雑なシステムでは、原因がデータベースなのか、ネットワークなのか、アプリケーションなのか、確認箇所が多いです。
原因特定に長時間かかるのか、数分で特定できるのか。この「復旧スピードの差」こそが、オブザーバビリティに取り組む最大の理由です。
ちなみに以下記事はPagerduty社が公表したシステム障害による損害リスクと対応実態の調査結果になります。
パフォーマンス改善にも効果的
障害対応だけでなく、パフォーマンス改善にも有効です。
システム内部が可視化されていれば、ボトルネックの特定がスムーズになります。「なんとなく重いからスペックを上げよう」ではなく、「このSQLが遅いから修正しよう」と根拠を持って改善でき、無駄なリソース追加しない。リソース効率化等によるコスト改善にもつながります。
AI時代にこそオブザーバビリティが重要
システムへのAI導入を検討されるケースが増えていますが、既存システムを理解せずにAIを導入すると、ブラックボックスを増やすリスクがあります。
既存システムとの依存関係
マイクロサービス化と同様、サービス間の依存関係が複雑になる中で、どこで何が起きているかが見えないと、トラブルシューティングが困難になります。AI導入も同じで、新機能（AI機能）をシステムに組み込むことでブラックボックス箇所が増える原因になります。
AI実行環境の可視化
さらに重要なのが、AIモデル（API）の利用状況を可視化することです。
APIキー流出による不正利用や、予期せぬ大量リクエストによる高額請求といった事例があるかと思います。AIモデルはCPU使用率を見るだけでは異常に気づけません。「誰が」「どのモデルを」「どれくらい」利用しているかの可視化が、AI時代の運用における重要な要件です。
現状把握が改善の第一歩
業務改善を行う際、いきなりツールを導入せず、まず「現在の業務フロー」や「ルール」を理解することから始めるはずです。現状を可視化できてこそ、ボトルネックや改善点が見えてきます。
システムも同じです。現状を理解せずに新しい技術を導入しても、効果的な対策にはなりません。まずは現状を正しく「見る」ことが全てのスタートラインです。
ツール選定
具体的に「何を使って」可視化すればいいのでしょうか。「システムへの導入しやすさ」と「運用体験（調査のしやすさ）」の2軸で選ぶことが重要です。
ここでは、CloudWatchとNew Relic等のSaaSの使い分けについて整理します。
1. Amazon CloudWatch
AWS環境ならCloudWatchが第一候補です。標準機能なので、すぐ利用できる手軽さが大きなメリットです。
詳細な分析には複数機能の組み合わせが必要
CloudWatchで詳細な分析を行う場合、いくつかの機能を組み合わせます。
- CloudWatch Logs Insights：クエリ言語で「特定のエラーコード」や「特定時間帯の集計」などをログから分析
- AWS X-Ray：リクエストのボトルネックを可視化。サービスマップやトレース詳細で「DBクエリに何秒かかったか」を確認
アプリ内部まで見るなら Application Signals
Application Signalsは、これらを統合的に扱える機能です。内部的にX-Rayを活用し、自動でサービスマップを描いたり、トレース分析ができます。
使用言語に注意：
- Java, Python, Node.js, .NET：AWSのディストリビューション（ADOT）で比較的スムーズに導入可能
- Ruby, PHP, Go：標準のOpenTelemetryライブラリ等を使用した計装（Instrumentation）が必要となり、導入・設定のハードルはやや高くなります。
2. New Relic等のSaaS
New RelicなどのSaaSを選ぶ理由は、「情報の繋がりやすさ」です。CloudWatchでも必要なデータは取得できますが、SaaSは「ここを見れば状況が分かる」という導線が整理されています。
私もNew Relicを利用していますが、詳細な分析やドリルダウンが可能で、外部サービスとの連携も充実しています。統合的なオブザーバビリティを実現したい場合に適していると考えています。ただし学習コストはあり、特にNew Relicは自由度が高い反面、習得に時間がかかります。
メリット：
- 導入が簡単：エージェントを入れるだけで「遅いDBクエリ」や「ボトルネックのコード行」まで自動可視化。Ruby/PHPも複雑な設定不要
- レイヤー横断が容易：ブラウザのユーザー体験からバックエンド処理、インフラ負荷まで一連の流れで見える。一つの画面でドリルダウン可能
判断基準（個人的な見解）
システムの規模だけでなく、「どれだけ詳細に分析したいか」「組織として使いこなせるか」かなと思います。
⚠️ コストに関する前提条件
システム構成や要件によってコストは大きく変わります。New Relicにしたほうが高くなる、もしくはAWSの方が高いなど、環境によって様々かと思いますので、そのあたりは事前の検討が必要です。（特にBとCの場合）
A. CloudWatch (基本機能) で十分なケース
- 対象：静的サイト中心、またはシンプルなシステム
- 要件：死活監視とリソース監視ができればOK
- スタンス：障害時は再起動で復旧できるため深い分析は不要
B. CloudWatch Application Signals 含めて追加機能を検討すべきケース
- 対象：AWS環境内でデータを完結させたい
- 要件：言語がJava, Python, Node.js, .NETでAWSの自動計装（ADOT）が適用可能。Ruby/PHP/Goも利用可能だがOpenTelemetry設定が必要
- スタンス：AWS内の複数サービス（Logs InsightsやX-Ray、SNS/Lambda(アラート通知等のカスタム設定) 等）を使いこなすスキルまたは運用を許容できる
C. New Relic を検討すべきケース
- 対象：マルチクラウドやオンプレミス混在環境
- 要件：コードレベル＋ユーザー体験ベースでの詳細分析が必要
- インフラ・アプリだけでなく、「ブラウザ、モバイル、ネットワーク」までを一気通貫で見たい
- スタンス：ダッシュボード作成やアラート通知、分析基盤の設定、構築・維持に工数をかけたくない（エージェント等入れたらだれでもすぐ見れるようにしたい）
より詳しい比較については、New Relic社がCloudWatchとの比較記事を公開しておりました（ちなみにこのブログ書いているときに発見しました）
D. ハイブリッドパターン（CloudWatch + New Relic併用）
- 対象：コストを最適化しながら詳細分析も必要なケース
- 要件
- CloudWatch：インフラメトリクス（EC2、RDS等のAWSリソース監視）、長期保存用のログ（障害対応に必要ではないようなもの）
- New Relic：アプリケーションパフォーマンス、ユーザー体験、トランザクション分析
- スタンス：「全てを一つのツールで」ではなく、用途に応じて使い分けることでコスト効率化
- インフラの基本メトリクスはCloudWatchで対応
- ビジネスクリティカルなアプリなどの分析が必要な情報はNew Relicで対応
まとめ
業務改善と同様、システムも「現状把握」がなければ適切な改善はできません。 まずは「自分たちがどこまで見たいのか」「誰が見て改善するのか」を明確にし、現状のシステム状況をしっかりと把握できているか（可観測性があるか）を見直してみてはいかがでしょうか。
(補足)オブザーバビリティを実現するためには
とはいえオブザーバビリティは、「継続的に改善したい」という組織の方針があって初めて機能します。
なので最終的に何を実現したいかなどゴールがないとオブザーバビリティの実装は難しいと思います。
オブザーバビリティ導入を成功させるためには以下のような具体的な活用イメージをチームで共有することから始めてみるのがいいかと思います。
- 迅速な障害検知と「情報のノイズ」の削減
- ユーザー体験に直結するSLOアラートを即時通知の基準とし、CPU使用率などのリソース状況はダッシュボードでの可視化に留めます。
- 「対応不要なアラート」というノイズを減らし、本当に深刻な異常を即座に特定。障害発生から初動までの時間を最短化し、ダウンタイムを最小限に抑えられます。
- ユーザー体験に直結するSLOアラートを即時通知の基準とし、CPU使用率などのリソース状況はダッシュボードでの可視化に留めます。
- データ駆動による継続的改善（PDCA）の確立
- 可視化されたSLOの達成状況をチーム共通の指標とし、定期的な振り返り（ポストモーテム等）を行います。
- 「なんとなく不安だから改修する」のではなく、客観的なデータに基づいた優先順位付けが可能になります。これにより、システムの信頼性と新機能開発のスピードを両立させるサイクルが生まれます。
- 可視化されたSLOの達成状況をチーム共通の指標とし、定期的な振り返り（ポストモーテム等）を行います。
- パフォーマンスとコストの最適化
- システムの稼働詳細を常に把握し、過剰なリソース配置や非効率な処理を特定します。
- パフォーマンスを維持しながら、コスト改善活動である「FinOps」の視点を持った、システム環境を維持し続けることができます。
- システムの稼働詳細を常に把握し、過剰なリソース配置や非効率な処理を特定します。
宣伝
弊社では、お客様環境のオブザーバビリティを加速するためのNew Relicアカウント開設を含めた伴走型のNew Relic導入支援サービスをご提供しております。
もしご興味をお持ちの方は、こちらのNew Relic導入支援サービスのページよりお問合せ頂けましたら幸いでございます。
・福田 圭(記事一覧)
・マネージドサービス部 所属・X（Twitter）：@soundsoon25
2023 New Relic Partner Trailblazer。New Relic Trailblazer of the Year 2025受賞。New Relic User Group運営。
