そのログ・メトリクス、その先を見据えていますか？

はじめに

こんにちは、Rinchokuです。第1回の「SRE Kaigi 2025」からコアスタッフを務めています。今回はその縁で寄稿の機会をいただきました。

ここ数年で、オブザーバビリティ環境やインシデント対応の流れが大きく変化しました。AIエージェントがログやメトリクスを読み、日々のモニタリングを代行したり、サービスの異常の原因を調査したりします。テレメトリの収集もOpenTelemetryや各社SaaSのエージェントを導入するだけで、広い範囲をカバーできるようになりました。

サービス・プロダクトに向き合うエンジニアとして、定常業務や属人化しやすい作業などが便利になったことはとてもありがたいことです。一方で「自分たちのプロダクトが何を集めているのか」「このメトリクスは何を意味しているのか」といったことを分からずに使っているという状況も増えた気がします。

前回の髙石さんの回では、AIエージェントが一次調査を担うようになったことで、インシデント対応の経験や判断力をどう獲得するかが記述されていました。

第3回となる本記事では、判断材料となる計測データで気に掛けることをテーマにしたいと思います。

監視対応は驚くほど楽になった

まず、個人的にここ数年で便利・楽になったことはログ・メトリクスの「収集」と「調査」だと思います。

収集に関しては、OpenTelemetryの登場が大きく寄与しています。OpenTelemetryはトレース、メトリクス、ログを扱うベンダー中立の仕様とツール群です。Java、Python、Go、JavaScriptなど主要な言語向けのAPIやSDKがプロジェクト公式で提供されています^*1。言語ごとの計装(instrumentation)や各ベンダーのエージェントを入れれば、HTTPリクエストの処理時間やエラー、データベースへの問い合わせなどを、アプリケーションのコードをほとんど書き換えずに取得できるようになりました。

調査に関しては、Model Context Protocol（MCP）^*3によるAIツールとの連携が大きいです。MCPの登場で、外部ツールやデータをAIにつなぐ仕組みが急速に広がりました。オブザーバビリティ領域でも各社SaaSでMCPサーバーの提供・開発が進み、ログ、メトリクス、トレースをAIエージェントが直接読み込めます。「今○○が起きているので原因を調べて」と指示すれば、数分後には関係するログやメトリクスを自動で横断して調べ、原因の候補が挙がってきます。場合によっては、コード上のどこを直すべきかも示してくれます。

*1： 「Language APIs & SDKs」 (OpenTelemetry)
*2： 「Introducing the Model Context Protocol」 (Anthropic, 2024年11月25日)

便利になった先での課題

こうして便利になった一方で、次のような4つの課題があると思っています。

【課題1】どんなログやメトリクスが存在するのか

計装用のツールやエージェントは、導入した時点で大量のメトリクスを収集します。エンジニアがどんなメトリクスを取るべきかを気にしなくても、ある程度必要となるメトリクスが取れます。

しかし、数百、数千のメトリクスの中から、「自分のサービスにとって重要な指標がどれか」「実際は取れてない指標が何か」を認知してる人はどれくらいいるでしょうか。調査をAIエージェントに任せていると、この「地図」を自分で描く機会がありません。地図がなければ、AIの報告に対して「なぜこのメトリクスは見なかったのか」と疑問に思うこともできませんし、その報告の妥当性の判断もできません。

【課題2】そのメトリクスは何を示しているのか

1つのメトリクスをとっても、計測方法は様々です。レイテンシは平均値なのか、p99なのか。CPU使用率はノード全体に対する値なのか、コンテナに割り当てた上限に対する値なのか。この数値はサービスの状態として何を示しているのか。こうした定義を知らずに数字を読むと、正常と異常の判断を間違えます。

皆さんも経験があると思いますが、AIエージェントは数字の定義を取り違えたまま、正しそうな結論を出すこともあります。そういった時に誤りに気づけるのは、定義を調べて知った人だけです。

【課題3】それが見えると、サービスの何が分かるのか

GoogleのSRE本は、モニタリングが答えるべき問いを「何が壊れているのか（what's broken）」と「なぜ壊れたのか（why）」の2つとしています。そのうえで、ユーザー向けシステムで4つしか測れないなら「レイテンシ」「トラフィック」「エラー」「サチュレーション」の4つ（Four Golden Signals）に着目するよう述べています^*3。裏を返せば、メトリクスは「ユーザーから見てサービスがどういう状態か」と結びついて初めて意味を持ちます。

このメトリクスが悪化すると、ユーザーには何が起きるのか、あるいはサービスがどんな状態を示すのか。逆に、ユーザーが困っているとき、それはどのメトリクスに表れるのか。この対応関係を説明できないメトリクスは、ダッシュボードに並んでいても判断の材料にはなりません。「取れたことで何が嬉しいのか」を言えないメトリクスは、ただの飾りになってしまいます。

*3： 「Monitoring Distributed Systems」 (Chapter 6 - Monitoring Distributed Systems)  

【課題4】そのログに、見せてはいけない情報が混ざっていないか

4つめは、ほかの3つと性質が異なる課題です。これは次節で詳しく扱います。

知らないうちに記録され、知らないうちに読まれる

「AIにどんな情報を渡すべきか」は、作業をAIに任せるうえで非常に重要です。一方で、調査には役立つものの、渡すことで会社にリスクが生じる情報も少なくありません。その代表が、個人情報や認証情報を含む会社の機密情報です。

例えば、2018年にはTwitter（現：X）が、バグによってユーザーのパスワードがハッシュ化される前に社内のログへ書き込まれていたと公表し、利用者にパスワードの変更を呼びかけました^*4。外部に漏れた形跡はないとされていますが、「ログに残るべきでないものが、誰も意図しないまま残っていた」典型的な事例です。

この種のリスクは、自動化が進んだ今のほうがむしろ見えにくいです。OpenTelemetryの公式ドキュメントでは、テレメトリの収集には意図せず機密情報や個人情報を取り込むリスクが常にあると述べ、何が機密かを判断するのはOpenTelemetryではなく導入する側の責任だとしています。さらに、利用する計装ライブラリが出力するデータを理解し、確認することも導入者の責任だと明記しています^*5。自動計装は便利ですが、「何を取るか」を私たちが1つずつ判断しなくなったことで、「何が取られているか」を誰も認識できてない状態が起こりやすくなります。

加えて、近年の2つの変化がこのリスクを広げています。1つはテレメトリの保管先がSaaSになったことです。ログは自社の外にあるサービスへ送られ、誰が見られるかはサービス側の権限設定に左右されます。

もう1つは、そのデータをAIエージェントに自由に調べさせる流れができたことです。MCP経由でAIがログを読むということは、ログの中身がプロンプトの一部としてAIサービスに渡るということでもあります。そのため、利用するAIサービスの扱い次第でログに含まれる個人情報を第三者が触れる恐れがあります。

また「社内メンバーしかアクセスできないから安全」とも言い切れません。近年のサプライチェーン攻撃では、エンジニア自身が狙われています。2025年8月には、改ざんされたnpmパッケージ（Nx）が開発者の端末からGitHubのトークンやクラウドの認証情報を盗み出し、その探索に端末上のAI CLIまで悪用しました^*6。エンジニアのアカウントが乗っ取られれば、その人が見られるログは攻撃者も見られます。社内限定であることを理由に、ログに機密情報を残してよいことにはなりません。

対策の基本は、なるべく上流で止めることです。OWASPのLogging Cheat Sheetは、パスワード、アクセストークン、セッションID、データベースの接続文字列、機微な個人情報などを、ログに直接記録せず削除やマスクをすべきものとして挙げています^*7。

まずアプリケーションで出力しないこと。次に、OpenTelemetry Collectorのredaction processorのように、許可した属性以外を送信前に削除する仕組みを挟むこと^*8。そのうえで、SaaS側の閲覧権限、AIエージェントに許可するデータの範囲、AIサービスの利用条件（入力が学習に使われるかどうか）を確認する、という順で考えるとよいでしょう。どこか1か所で完全に防ぐのは難しいため、複数の地点で止める設計を心がけることが大切です。

*4： 「You should change your Twitter password right now」 （TechCrunch, 2018年5月3日) 
*5： 「Handling sensitive data」（OpenTelemetry）
*6： 「Malicious Nx Packages in 's1ngularity' Attack Leaked 2,349 GitHub, Cloud, and AI Credentials」(The Hacker News, 2025年8月)
*7： 「Logging Cheat Sheet」 (OWASP Cheat Sheet Series)
*8： 「Redaction Processor」 (opentelemetry-collector-contrib)

 「その先」を見直すために

では、明日から何ができるでしょうか。大がかりな取り組みでなくても、次のようなことから始められます。

1つめは、重要なログとメトリクスの棚卸しです。全データを対象にする必要はありません。ログであれば個人情報などの第三者に見られたら困る情報が出力またはマスクされているかを見ましょう。メトリクスなら、まずはSLOやアラートに使っているものから理解を始めていき、他にどんなメトリクスが溜まっているかを眺めてみましょう（きっとこの部分はAIを活用すると理解も早まるでしょう）。

2つめは、AIエージェントの調査結果を、自分がちゃんと理解できたか振り返ることです。報告に出てきたメトリクスやログを自分で開き、定義や前後の値を確かめます。毎回でもなくても、気になったときや週に1度でも構いません。一次情報をたどり、その情報が正しいかを自分で判断することは、エンジニアがこれまでも大切にしてきた力の1つです。

3つめは、「今」だけでなく「数歩先」を見据えることです。ログやメトリクスを追加するとき、「今の調査に必要か」「あれば便利だろう」という基準で判断しやすいです。しかし、出力されたデータは、SaaSに保管され、AIエージェントに読まれ、ときには様々な誰かの目に触れます。プロダクトが成長したときにそのデータがサービスやユーザー体験の変化をいち早く教えてくれるかもしれません。「このデータはこの先どこへ渡り、誰に見られるのか」「この先、プロダクトの何を判断するために使うのか」。この2つを数歩先まで想像しておくことが、セキュリティを守ることにも、プロダクトに向き合い続けることにもつながります。

おわりに

AIやOpenTelemetryをはじめとするツールのおかげで、ログやメトリクスを集め、調べる作業は大きく楽になりました。その一方で、以前なら運用の中で自然と身に付いていた「どこに何があり、それが何を意味するのか」という知識の獲得は減っています。

ログやメトリクスは集めること自体が目的ではありません。それが見えることでサービスの何が分かり、何が嬉しいのか。その先を改めて見直してみてください。

また、便利さとセキュリティのバランスを考えるのは難しいです。本記事が今一度見直す機会となれば幸いです。