AI・機械学習

LangChainエージェントが2週間サイレント障害!本番運用で絶対に入れたいモニタリング実装パターン

「エラーも出てないのに、なんかおかしい…」そんな最悪のシナリオ、想像したことありますか?🤔

海外の開発チームが体験した話が話題になっています。LangChainエージェントを本番環境にデプロイしたところ、約30%のセッションで静かに失敗し続けたというんですよね。しかも2週間も気づかなかった。

例外は出ない。500エラーも出ない。ログも正常。エージェントはちゃんと動いているように見える。でも実際には、クライアントのビジネスデータがずっとおかしくなっていた…。発覚したのはクライアントから「数字がおかしい」と連絡が来てから。その時点で約2,400ドル(約36万円)分のLLM費用が無駄になっていたそうです。

これ、対岸の火事じゃないですよね。LLMを使った自動化ツールやエージェントを作っているなら、同じ落とし穴にハマる可能性は十分あります。

🔍 なぜ「サイレント障害」が起きるのか

AI monitoring dashboard
AI monitoring dashboard / Photo by Tima Miroshnichenko via Pexels

従来のWebアプリとLLMエージェントでは、障害の見え方がまったく違います

普通のAPIなら「例外が出る=エラーだとわかる」ですよね。でもLLMエージェントの場合、こんなことが起きます。

  • ツール呼び出しの結果をLLMが自分で解釈して「成功した」と判断してしまう
  • エラーメッセージをそのままユーザーに返す代わりに、それっぽい回答を生成してしまう
  • 途中のステップが失敗していても、最終的なレスポンスだけは返ってくる

つまり「レスポンスが返ってくること」と「正しく動いていること」がイコールじゃないんですよね。これがLLMエージェント特有の難しさです。

🛠️ 本番で使えるモニタリング実装パターン

では実際にどう対策すればいいか。ポイントは「アウトカムの検証」を自前で実装することです。

以下は、エージェントの各ステップ結果を記録・検証するシンプルなラッパーの例です。

from langchain.callbacks.base import BaseCallbackHandler
import logging
import time

# ステップごとの結果を記録するカスタムコールバック
class AgentMonitoringCallback(BaseCallbackHandler):
    def __init__(self, session_id: str):
        self.session_id = session_id
        self.tool_calls = []
        self.start_time = time.time()

    def on_tool_start(self, serialized, input_str, **kwargs):
        # ツール呼び出し開始をログに記録
        logging.info(f"[{self.session_id}] Tool start: {serialized.get('name')} | input: {input_str}")

    def on_tool_end(self, output, **kwargs):
        # ツールの出力を記録し、空や異常な結果を検知
        self.tool_calls.append(output)
        if not output or "error" in str(output).lower():
            logging.warning(f"[{self.session_id}] ⚠️ 疑わしいツール出力: {output}")

    def on_agent_finish(self, finish, **kwargs):
        elapsed = time.time() - self.start_time
        # 実行時間が異常に短い場合はスキップされた可能性あり
        if elapsed < 0.5:
            logging.warning(f"[{self.session_id}] ⚠️ 実行時間が短すぎます: {elapsed:.2f}s")
        logging.info(f"[{self.session_id}] ✅ 完了 | ツール呼び出し数: {len(self.tool_calls)}")

ポイントをまとめるとこんな感じです。

  • on_tool_end でツールの出力内容を毎回チェック
  • 空文字・エラー文字列が含まれていたら即座に警告ログを出す
  • 実行時間を計測し、異常に短いセッションを検出する
  • セッションIDをつけることで後から追跡しやすくなる

📊 モニタリングで見るべき3つの指標


ログを取るだけじゃなく、何を監視するかも重要です。

  • ツール呼び出し成功率:期待するツールが呼ばれているか
  • 空レスポンス率:意味のない回答が返っていないか
  • セッションあたりのLLMトークン数:急に減った場合は処理がスキップされている可能性あり

まとめ

LLMエージェントの「見た目は正常、でも中身はおかしい」という障害は、従来の監視ツールでは検知できません。アウトカムを自分でバリデーションする仕組みを最初から組み込むことが、本番運用の必須条件になってきています。

2週間・36万円の損失、これはひとごとではないですよね。ぜひ自分のエージェント実装にモニタリングを追加してみてください💪

📚 関連商品・おすすめ書籍

スッキリわかるPython入門 第2版 (スッキリわかる入門シリーズ)

もしも

スッキリわかるPython入門 第2版 (スッキリわかる入門シリーズ)

初心者に定番のPython入門書

Amazonで見る

実践Claude Code入門―現場で活用するためのAIコーディングの思考法

もしも

実践Claude Code入門―現場で活用するためのAIコーディングの思考法

AIコーディングの現場活用法を学ぶ一冊

Amazonで見る

Python Web開発実践入門 ―― FastAPIによるWebAPI開発と非同期処理

もしも

Python Web開発実践入門 ―― FastAPIによるWebAPI開発と非同期処理

FastAPIでWebAPI開発を実践的に学ぶ

Amazonで見る

※本記事にはアフィリエイトリンクが含まれます。

ABOUT ME
やまちゃん
これまで学生と社会人を合わせて5000人以上にプログラミング学習を指導。 ゼロからイチをわかりやすく解説する専門家として活動しており、本業ではArduinoを用いたIoT開発とロボットプログラミングが専門。 Pythonを用いたアプリ開発、ウェブアプリケーションの開発で業務の効率化をサポートしています。

COMMENT

メールアドレスが公開されることはありません。 が付いている欄は必須項目です