ログには、ほとんどのインシデントに対する答えが既に含まれています。問題はデータの不足ではありません。問題は、人間が何千行ものログを読み、それらをメトリクスのスパイクと関連付け、実際に何が壊れたのかを突き止めるのにかかる時間です。
大規模言語モデルは、この方程式の両側を変えます。LLMは代わりに読み込みを行い、生のテレメトリデータを人間よりも速く答えに変換します。そしてLLMは、ますます直接監視が必要な対象にもなっています。チームはClaudeやChatGPTのようなツールを毎日使用しており、その利用状況によって独自のテレメトリ、API呼び出し、データアクセスなどが生成されますが、ほとんどの組織はそれらをまったく把握できていません。
LLMの可観測性は、LLMを使ってシステムを監視およびトラブルシューティングし、自社がLLMを実際にどのように利用しているかを正確に把握できるようにします。
本当のボトルネックは、収集ではなく解釈です
ほとんどのオブザーバビリティスタックは、データ収集には優れています。あらゆるサービスから、メトリクス、イベント、ログ、トレースが流れ込んできます。ボトルネックは下流工程で発生します。オンコールのエンジニアが午前2時に、その生のテレメトリデータを答えへと変換しなければならない場面です。
そこでLLMが、スタックの中で存在意義を発揮します。LLMは、エンジニアの時間を消費するまさにその作業、つまり非構造化テキストを読み取り、パターンを見つけ出し、それを平易な言葉で説明することを得意としています。
実際のユースケース
ノイズを信号へと凝縮する。 Sumo LogicのLogReduceは、類似のログメッセージをクラスタリングし、何千行ものメッセージを、実際にスキャンできる少数のパターンに集約します。その上にLLMを追加すると、それらのパターンは正規表現のようなクラスターではなく、平易な言葉による要約になります。
質問をクエリに変換する。知りたいことは分かっていても、クエリ構文を正確に覚えているとは限りません。Sumo LogicのQuery Agentは、自然言語の質問を正確なクエリに直接変換するため、構文のデバッグではなく結果の解釈に時間を使えます。
インシデントの経緯を記述する。アラートが発生しても、単にグラフにスパイクが表示されるだけではありません。Sumo LogicのMobotは、断片的なアラートを、何が起こったのか、何に影響があったのか、次に何を確認すべきかという物語へと凝縮します。ダッシュボードをただ眺めるのと、ブリーフィングを読むのとでは、その違いは大きいのです。
ポストモーテムのドラフトを作成する。インシデントが解決した後も、誰かが内容を文書化する必要があります。LLMはタイムラインを作成し、講じた対策を要約し、予防策を提案できるため、チームは書類作成ではなく、修正作業に時間を費やすことができます。
Sumo Logicは、これらのエージェントを、セキュリティとオブザーバビリティのワークフロー向けに構築されたマルチエージェントプラットフォームであるDojo AIの下に統合しました。各エージェントにはそれぞれ役割があります。エージェント同士が連携し、あらゆる段階で人間が関与することで、問題を迅速に検知・調査・解決します。
問題のもう半分：組織がLLMをどのように利用しているかにも、可観測性が必要です
チームはおそらくLLMで開発しているだけでなく、ClaudeやChatGPTのようなツールを通じて、毎日LLMを利用しています。その利用状況は独自のテレメトリを生成しますが、ほとんどの組織はそれをまったく把握していません。
Claude Compliance Appは、Claude EnterpriseおよびClaude Platformのアクティビティログを取り込み、APIの使用状況、認証、課金、データアクセス、統合、SSO、ポリシー変更を一元的に可視化します。さらに、事前構築済みのダッシュボードと、すぐに使用できる検出機能が用意されています。
ChatGPT Compliance AppはOpenAIのツールに対しても同様の機能を提供し、インシデントになる前に、インタラクションパターンを可視化し、ポリシーに違反するデータ共有行動にフラグを立てます。どちらも検索可能なタイムスタンプ付きの監査証跡を提供するため、チームがこれらのツールを実際にどのように使用しているかを尋ねられた際に、推測ではなく明確な答えを示すことができます。
こうした可視性が重要なのは、サービステレメトリが重要な理由と同じです。見えないものは管理できません。エンジニアが独自のコードを管理されていないAIツールに貼り付けることは、監視されていないサービスと同様に、盲点になります。1つはインフラストラクチャダッシュボードに表示されます。もう一方は、どこにも表示されません。
この利用状況の上に独自のLLM対応アプリケーションを構築するチーム向けに、Sumo Logicはそのレイヤーもカバーしています。カスタムAIアプリケーション向けのOpenLLMetryなどのアプリを提供しており、LLM呼び出し、ベクトルデータベース、およびAIエージェントからのトレース、メトリクス、ログを、標準のOpenTelemetryフォーマットでキャプチャします。また、マルチモデルプロキシ経由でトラフィックをルーティングするチーム向けに、100以上のモデルにわたるリクエスト量、レイテンシ、トークン消費量、コストを追跡するマルチモデルルーティング用のLiteLLMも提供しています。
これがあなたのチームにとって何を意味するのか
システムを観測するためにAIを使用することと、組織がAIツールをどのように利用しているかを観測することのどちらか一方を選ぶ必要はありません。どちらも同じ分野であり、モデルやそれらにプロンプトを入力する人々、そしてサービスを含むスタック全体に適用されます。
まずは、今日もっともコストがかかっているギャップから着手しましょう。アラート疲れが問題なのであれば、LLMがトリアージをどう変えられるかを検討してください。組織全体でClaudeやChatGPTがどのように利用されているかが見えていないのであれば、まずその可視性のギャップを埋める必要があります。
データの量が減ることはありません。変化しているのは、AIツールの可視性をどのように高めるかと、問題をどれだけ迅速に答えへと変えられるかという点です。
Sumo LogicのAIを活用したオブザーバビリティ機能を確認するか、Sumo Logicのエキスパートにスタックについて相談してください。
