目次
はじめに
この記事は「第四回：ログ分析基盤の実践活用 ～可観測性・セキュリティ・ビジネス分析～」に続く、連載の最終回になります。
これまでの連載では、第一回でログ分析基盤とAPMの違いを整理し、第二回でその土台となるMELTの考え方を確認しました。
そして第三回ではAPMの活用事例を、第四回ではログ分析基盤の活用事例を、それぞれ単体で深掘りしてきました。
- 第一回：ログ分析基盤とAPMの違いとは？ ～目的・機能・製品を比較～
- 第二回：MELTで理解するログと監視の世界 ～Metrics・Events・Logs・Traces～
- 第三回：APM活用事例で見るアプリ品質向上と開発者支援
- 第四回：ログ分析基盤の実践活用 ～可観測性・セキュリティ・ビジネス分析～
最終回となる今回は、いよいよこの2つを組み合わせた際の**「うまみ」**を見ていきます。
第一回では「両者は相互補完的な関係にある」と述べました。
では、その相互補完は実際の現場でどのように効いてくるのでしょうか。
今回は、組み合わせによるメリットを整理したうえで、3つのソリューション事例を通じて具体的にご紹介します。
1. 両者の組み合わせによるメリット
1.1 なぜ「組み合わせる」のか
第三回・第四回で見てきたように、APMとログ分析基盤は、それぞれ得意な「見る角度」が異なります。
-
APMは、アプリケーション内部やトランザクションを追跡し、
「どこで・なぜ遅いのか、壊れたのか」を深く掘り下げる（＝ 深掘り）ツールでした。 -
ログ分析基盤は、多様なデータを横断的に集約し、
「全体で今何が起きているのか」を俯瞰する（＝ 俯瞰）ハブでした。
現場で発生する問題は、たいていの場合、「技術的な事象」と「業務・ビジネスへの影響」が表裏一体になっています。
たとえば、
あるAPIのレイテンシが悪化している
という技術的な事象は、裏を返せば、
特定の業務処理が滞り、ユーザーからの問い合わせが増えている
というビジネス上の事象でもあります。
APM単体では、前者のような技術的な問題の中身は把握できても、それが業務全体にどのように波及しているのかまでは見えにくい場合があります。
一方、ログ分析基盤単体では、全体の異変や影響範囲は把握できても、その技術的な根本原因までは辿りきれないケースがあります。
この「片方だけでは見えない部分を互いに補い合えること」が、APMとログ分析基盤を組み合わせる最大の価値です。
1.2 2つの観点を掛け合わせる
このあと紹介する3つのソリューション事例は、いずれも次の2つの観点の掛け合わせで構成されています。
まずこの軸を押さえておくと、それぞれの事例を同じフレームで読み解けるようになります。
| 観点 | 担うツール | 答える問い | 主な利用者 |
|---|---|---|---|
| システム観点（深掘り） | APM | 「どこで・なぜ遅い／壊れたのか」「技術的な原因はどこか」 | 開発者、SRE、アプリチーム |
| ビジネス／プロセス観点（俯瞰） | ログ分析基盤 | 「全体で何が起きているのか」「業務・ユーザーへの影響はどうか」 | 運用担当、業務部門、上位層、関連部門 |
APMが縦方向に「深く」掘り下げ、ログ分析基盤が横方向に「広く」見渡す。
この「広く見る × 深く掘る」という組み合わせによって、単体では得られなかった気づきを得られるようになります。
1.3 組み合わせで得られる4つのメリット
2つの観点を掛け合わせることで、具体的には次のようなメリットが期待できます。
| メリット | 内容 |
|---|---|
| ① 技術と業務を同時に把握できる | 「技術的な異常（APM）」と「業務・ビジネスへの影響（ログ分析基盤）」をつなげて確認できます。原因と影響を突き合わせながら判断できるようになります。 |
| ② 検知から再発防止まで一気通貫で対応できる | ログ分析基盤で全体の異変を検知・相関分析し、APMで技術的な原因を特定します。さらにログ分析基盤で影響範囲を確認し、再発防止につなげるという一連のプロセスを実現できます。 |
| ③ 関係者が同じ情報を見ながら対話できる | 開発・運用・業務部門・上位層など、立場の異なる関係者が同じ情報基盤を見ながら会話できます。属人化やチーム間の情報格差を減らし、意思決定やエスカレーションを迅速化できます。 |
| ④ データが相互に補完される | APMが持つ構造化されたテレメトリ（メトリクス・トレース）と、ログ分析基盤が扱う非構造化ログ・チケット・SNSなどの多様なデータを結び付けることで、片方だけでは描けなかった状況を再構築できます。 |
ポイント
ポイントは、APM＝「システム観点での深掘り」、ログ分析基盤＝「ビジネス／プロセス観点での俯瞰」 という2つの見る角度を、1つの基盤の上で掛け合わせることにあります。
これにより、技術的な原因究明と業務・ビジネスへの影響把握を同じ土俵で行えるようになります。
とはいえ、メリットだけを並べてもイメージは湧きにくいかと思います。
次章では、この**「システム観点 × ビジネス／プロセス観点」**という軸で、実際の現場を想定した3つのソリューション事例を見ていきます。
2. ソリューション事例
2.1 大規模なシステム処理の管理効率化
製造業における、設計から製造へのBOM（Bill of Materials：部品表）変換など、短期間で大規模なシステム処理が繰り返される場面を考えてみます。
このような業務では、単にITコンポーネントの稼働状況を管理するだけでは十分ではありません。
処理そのものの進捗を把握し、問題が発生した際には、影響度に応じて適切なリソースや要員を投入することが、業務レベルでの課題になります。
ログ分析基盤とAPMを組み合わせることで、システムの状態と業務処理の進捗を両面から把握できるようになります。
ビジネス観点：ログ分析基盤
-
処理の推移を可視化（DBとの連携）
-
問題発生状況を把握（チケット管理ツールと連携）
-
要員配置の判断 上位層・関連部門での情報共有
システム観点：APM
-
リソースの最適化（バッチ処理のサーバ割振等）
-
ボトルネック確認 障害原因の確認と対応 バージョンによる影響把握
下図にソリューションのイメージを示します。
図：大規模システム処理の管理効率化におけるソリューションイメージ
2.2 共通サービスの利用やシステム間連携における運用効率化
グループ会社で共通のITインフラやサービスをまとめて提供・利用するシェアード・サービスの形態では、次のような関係が生まれます。
- 共通サービスを提供する側
- 共通サービスを利用し、自社のアプリケーションを開発・運用する側
このとき課題となるのが、提供側と利用側のコミュニケーションをいかに効率化するかです。
共通サービスの状態、各システムへの影響、マスター情報の更新予定などを複数チームが個別に確認していると、情報共有の負担が大きくなります。
ログ分析基盤とAPMを組み合わせることで、プロセス上必要な情報と、システムの実際の稼働状況を同時に可視化できます。
プロセス観点：ログ分析基盤
-
各システムにデプロイされているリソース状況の提供（DBテーブルなど）（DB管理ツールとの連携）
-
共通マスターの内容や更新予定の可視化（アプリテスト時などに更新タイミングを確認）（DB管理ツールとの連携）
システム観点：APM
- 共通サービス全体の状況を可視化
- アプリケーションとインフラ各コンポーネントの相互連携を可視化
- アプリケーションとインフラ各コンポーネントの個別稼働状況を可視化
これにより、共通サービスの提供側・利用側が、それぞれ別の情報を確認するのではなく、同じ情報をもとに状況を判断できる環境を作ることができます。
下図にソリューションのイメージを示します。
図：共通サービス・システム間連携におけるソリューションイメージ
2.3 サービスデスク業務の効率化
サービスデスクは、ユーザーに対する単一窓口として、ユーザーが抱えている問題を迅速に切り分け、適切な担当部署へエスカレーションすることが求められます。
そのためには、
- 「個々のユーザーに対して今何が起きているのか」
- 「サービス全体では今どのような状況になっているのか」
という2つの視点を同時に把握することが課題です。
ログ分析基盤とAPMを組み合わせることで、この課題を解決する例を以下に示します。
ビジネス観点：ログ分析基盤
-
問い合わせ状況の可視化（チケット管理ツールとの連携）
-
サービス利用状況の可視化 要員配置の判断
-
上位層・関連部門での情報共有
-
SNS上の状況を可視化
システム観点：外形監視／RUM（APM）
- ユーザーセッションの監視
- アプリケーションエラー箇所の把握
- バージョンによる影響把握
たとえばサービスデスクで問い合わせを受けた際に、問い合わせ内容だけを見るのではなく、対象ユーザーのセッションやエラー情報まで確認できれば、問題の切り分けやエスカレーションを迅速化できます。
同時に、ログ分析基盤で問い合わせ件数やSNS、サービス利用状況を確認することで、「個別ユーザーの問題なのか、サービス全体で発生している問題なのか」を判断しやすくなります。
下図にソリューションのイメージを示します。
図：サービスデスク業務効率化におけるソリューションイメージ
3. まとめ：可観測性の未来と展望
システムを取り巻く環境が日々複雑化する中で、システムの状況を的確に把握するための**可観測性（Observability）**は、ますます重要になっています。
そして今後の可観測性を考えるうえでは、AIとの関係も重要なテーマになります。
3.1 AIと可観測性
可観測性の未来を考える際、AIは外すことのできない要素の1つです。
AIの進化により、これまで紹介してきたような、
- 障害対応
- セキュリティインシデント対応
- 原因分析
- レポート作成
といった業務をAIが支援する、あるいはAIエージェントが実行する機能をうたう製品も登場しています。
たとえば、
- ログ分析基盤で分析した結果をAIが判断し、障害対応のアドバイスを提供する
- ログ分析基盤の分析結果をAIへ連携し、ほかのデータと組み合わせて解析する
- 収集された情報をもとにAIがレポートを作成する
といった活用も可能になりつつあります。
一方で、AIそのものをモニタリングするための可観測性も必要になっています。
従来のITシステムでは、処理が成功したか失敗したかを、エラー情報などから比較的明確に判断できました。
しかしAIでは、単純なエラーとして表れない問題も発生します。
たとえば、
- 出力結果の品質が低下する
- レスポンスのレイテンシーが増加する
- トークン消費量が増加し、コストが上昇する
- モデルやプロンプトの変更によって回答品質が変化する
といった問題です。
そのため、AIシステムにおいては、
- トークン数
- レイテンシー
- モデルの呼び出し状況
- トレース
- 出力品質
など、AI特有の情報を監視する必要があります。
さらに、AIの出力品質を別のLLMによって評価するLLM-as-a-Judgeと呼ばれる仕組みも登場しています。
AIの世界においても、Metrics・Events・Logs・TracesといったMELTを活用した可観測性の考え方は引き続き重要になると考えられます。
AIと可観測性がどのように発展していくのか、今後も注視していきたいところです。
3.2 可観測性が抱える課題
AIの進化に伴ってシステムのあり方や業務が変化していく一方で、足元では、従来システムにおける可観測性を高めるためのツールや機能を十分に使いこなせていないという声もあります。
クラウドをベースとしたモダンなアプリケーションや開発環境では、可観測性の考え方を比較的取り入れやすくなっています。
一方で、
- 従来型のエンタープライズシステム
- オンプレミス環境
- 多数のシステムや部門を持つ大規模組織
において、可観測性をどのように取り入れていくかは、今後も大きな課題になると考えています。
たとえば、
- オンプレミス環境からSaaSへのデータ連携が難しい
- システムやデータが複数部門に分散している
- 組織が縦割りで、可観測性の価値が部門間で共有されない
- 収集したデータが、ビジネス価値の向上まで活用されていない
といった課題があります。
そのため、単に新しいツールを導入するだけではなく、
- どのユースケースを実現したいのか
- そのために必要なデータは何か
- ダッシュボードは利用者の要件に合っているか
- 可観測性を日々の業務プロセスにどう組み込むか
といったことを一つずつ整理し、地道に積み重ねていくことが重要なのかもしれません。
AIや新しい技術による高度化だけではなく、こうした地に足のついた可観測性のあり方についても、引き続き考えていきたいと思います。