なぜLLMを組み込むと運用が難しくなるのか？
LLMを既存のアプリケーションに組み込んだ後の運用フェーズを想像してほしい。
さっきまで問題なく動いていたのに、“なぜか”突然レスポンスが跳ね上がった。同じ入力を投げているのに、“なぜか”違う結果が返ってくる。コードも設定も変更しておらず、デプロイもしていないのに、“なぜか”挙動が揺らいでしまう。
このような“なぜか”が積み重なり、バグだとも障害だとも言い切れない状態に直面する。結果、「LLMの挙動によるものと思われます」と、思わず自分でもツッコミを入れたくなるような報告をするしかなくなり、エンジニアは窮地に立たされるのだ。
では、なぜLLMをシステムに組み込んだ途端に、障害対応が難しくなるのだろうか。
「まだ触り始めたばかりだから」「うちのチームにはAIの専門家がいないから」「もっと勉強してAIに対する理解を深めれば解決するはずだ」などと思いたくなるかもしれないが、「それは大きな誤解であり、従来のシステムとLLMでは、前提となるルールが異なるからだ」と萩野氏は断言する。
従来のシステムでは、入力が同じであれば出力も必ず同じだった。処理はコードで書かれており、ロジックは決定的。挙動は必ず再現できた。だからこそ、何かしらの障害が発生したときには「再現し、原因を特定し、修正する」という戦い方が通用した。
だが、LLMでは、そうはいかない。挙動は確率的で、出力には揺らぎがあり、モデルの内部は外から見えないブラックボックスだ。従来のシステムとは前提が異なる以上、「再現し、原因を特定し、修正する」というこれまでの戦い方は、通用しなくなる。だから難しいのだ。
「現場では、『ログはあるけれど、意味がわからない』『トレースはあるけれど、LLMの中が見えない』といった声がよく聞こえてくる。これは障害対応で一番怖い“あるけれど、わからない”状態だ。そうなると、『まぁ、LLMだから……』と報告せざるを得ないが、これはただの敗北でしかない」と語る萩野氏は、次にAI時代のオブザーバビリティのあり方に言及した。
AI時代のオブザーバビリティはどうあるべきか
LLMを組み込んだシステムの運用には、従来の障害対応とは異なる戦い方が必要だとわかった。とはいえ、挙動は確率的で再現性がなく、出力にも揺らぎがあり、モデルの内部はブラックボックスというLLMの特性を鑑みると、もはやあきらめるしかないようにも思えてくる。
けれども萩野氏は、「対処法は意外とシンプルで、見るもの（＝観測対象）を変えればいいだけだ」と強調する。
AI時代のオブザーバビリティは、「壊れたら気づく」「障害が起きたら気づく」といった単純な話ではない。なぜそうなっているのか、「“説明できる状態”をつくること」がゴールとなる。
さらに言えば、LLMを組み込んだシステムでは、従来システムのように「壊れたor壊れていない」という二元論で捉えることはできない。より複合的なものとして、障害という概念そのものを再定義する必要があるのだ。
そのうえで萩野氏は、LLMを組み込んだシステムの場合、最低限見るべきシグナルとして、次の4つを挙げた。
レイテンシ
どのくらい遅いのか。その遅さは、毎回コンスタントなのか、それとも揺らぎがあるのか。LLMは、外部APIのようにクラウド経由で呼び出されるものであり、膨大な計算を行う推論エンジンでもある。そのため、応答時間の遅延が発生しやすいコンポーネントだと言える。したがってLLMを組み込んだ時点でレイテンシは主要な観測対象になる。
エラー
タイムアウトやレート制限といった従来のシステムでも生じていたエラーに加え、トークン超過やポリシー違反など、LLMの利用に伴って顕在化しやすいエラーも増えてくる。これらを監視し、発生の有無を観測する必要がある。
入出力の関係
これも従来のシステムとは大きく異なる点だ。同じ入力に対して出力が揺らいでいないか、揺らいでいるならどの程度揺らいでいるのか。入力の細微な変化に対して、出力が過度に変わっていないか。こうしたふるまいを観測しなければならない。
コスト
サービスの提供形態上、LLMは使用量が増えれば増えるほど、コストが増えていく。そのため、従来のシステムでいうところの障害や不具合、エラーや性能劣化によって、想定外にトークンが増加するとコストがかさみ、運用ダメージとして着実に蓄積されていく。
LLMを組み込んだシステムでは、CPUやメモリだけを見ていても、その変化に気づけない場面が増えている。もはや問題の中心は、インフラのような物理的・技術的レイヤーから、ふるまいや出力に影響を与える“意味のレイヤー”へと移ってきているからだ。
「LLM Observability」で観測可能になるものとは
続いて萩野氏は、DatadogのLLM Observabilityの有用性へと、話を進めた。
従来のオブザーバビリティは、CPU・メモリ・エラー率・レスポンスタイムといったものを見ることで、多くの障害原因を特定し、解決策を導いてきた。
だが、LLMが組み込まれると、APIは正常でインフラも問題なく、エラー率も上がっていないにもかかわらず、「なぜか変な回答が返ってきてしまう」という事象が起きる。
つまり、「壊れているかどうか」ではなく、「期待通りにふるまっているかどうか」へと問題が変わってきているのだ。「その判断材料が、従来のオブザーバビリティには存在しない」と萩野氏は指摘する。
そこで有効なのがDatadogのLLM Observabilityだ。これは単なるログ拡張ではなく、LLMを“観測可能なコンポーネント”として取り扱うための仕組みである。Overview・Traces・Experiment・Playground・Evaluationsといった項目が並び、LLMを評価・分析・改善できる対象として設計していることがわかる。
LLM Observabilityで見えるようになるものとしては、「Prompt：どんなプロンプトを投げたのか」「Completion：どんなレスポンスがあったのか」「Tokens：トークンがいくつ使われたのか」「Latency／Errors：どこで遅くなったのか」が挙げられる。特長的なのは、これらが紐づき、“1つのコンテキストを持った観測データ”として見られる点だ。
「LLMの挙動は再現できない。この事実は受け入れるしかない。だからこそ、再現実験に時間をかけるのではなく、そのとき何が起きていたのかを正確に記録しておくという発想に切り替えることが重要だ」と語る萩野氏。
たとえば、DatadogのTracesを見てみると、漠然とLLMが遅いのではなく、「どのモデルで呼び出した、どのプロンプトの処理が重いのか」「どの外部ツールからの呼び出しがボトルネックになっているのか」といった部分を特定できる。
また、LLMは壊れていなくても知らぬ間に品質が落ちていることもあるが、DatadogのEvaluationsを見れば、回答の正確性、一貫性、ポリシー準拠といった観点から、LLMの出力品質を定量的に評価することができる。
さらに、DatadogのTokensでは、トークンの使用量をトレース単位やプロンプト単位で把握できるため、「どの機能が金食い虫なのか」が一目瞭然になる。
このように、DatadogのLLM Observabilityを活用して、再現性ではなく説明可能性の観点から情報を記録・収集しておくことで、障害対応のストレスを大きく低減できるだけでなく、経営の観点から次の一手を考えるうえでも大いに役立てられるという。
「DatadogのLLM Observabilityを正しく活用すれば、LLMを観測対象とすることができる。障害対応も勘に頼るのではなく、分解・分析したうえで具体的な説明に落とし込むことが可能だ。見えないAIは怖いが、見えるAIなら、効率的に運用できるシステムになる」と語り、萩野氏はセッションを締めくくった。
Datadog Japanからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
