【ITニュース解説】LLM Observability: Debugging My Journaling Agent

この解説では、大規模言語モデル（LLM）を活用したAIジャーナリングアシスタントの開発過程で直面した課題と、それを解決するために「オブザーバビリティ」という考え方とツールがいかに役立ったかについて説明する。システムエンジニアを目指す初心者でも理解できるよう、具体的な状況と技術的な概念をわかりやすく解説する。

まず、プロジェクトの動機についてだが、個人的な思索や記憶を様々な形式で記録している中で、それらが散在しているという課題意識があった。そこで、これらの記録を一箇所に統合し、自身の思考や記憶を分析できるプライベートな空間を構築することを目指した。これは、ジャーナリングとデータサイエンスという二つの関心を組み合わせる絶好の機会でもあった。特に重視したのはプライバシーであるため、インターネット上のサービスではなく、自分のコンピューター上で完全に動作するモデルを選定し、フリーでオープンソースのツールを使用することを前提とした。この目的のために、Ollamaというツールを使い、複数の比較的小さなオープンソースモデルで実験を開始した。

開発の初期段階では、選定したモデルの組み込み自体はスムーズに進んだが、すぐに最初の大きな壁にぶつかった。それは、AIエージェントに特定のタスクを実行させるための「ツール」を実装しようとした時だった。エージェントが、期待通りにツールを全く起動してくれなかったのだ。この「シンプルに保つ」という初期の方針から、まずは昔ながらのprint()関数を使って、プログラムの内部で何が起きているかをコンソールに出力し、手動でデバッグを試みた。しかし、これはすぐに限界を迎えた。コンソールは大量のテキストで埋め尽くされ、何がどこで起こっているのかを人間が追跡するのは非常に困難で、もはや不可能に近い状態だった。この経験から、本格的なデバッグには、より洗練された「オブザーバビリティツール」が必要であると痛感した。

そこで、新しいツールに求める条件を定めた。オープンソースであること、ローカルで動くモデルと簡単に連携できること、そして直感的で分かりやすいユーザーインターフェースを持つこと、の三点である。これらの条件を満たすツールを探した結果、「Langfuse」というツールを選択した。Langfuseは、LLMを用いたアプリケーション特有の問題、例えばエージェントが実行する一連の処理（チェーン）を追跡したり、生成された出力の品質を評価したりすることに特化して設計されている点が大きな決め手となった。

Langfuseの導入は非常に簡単だった。Pythonのパッケージ管理ツールであるpipを使ってインストールし、必要なAPIキーを設定するだけで準備が整った。具体的なコードへの組み込み方法としては、まず追跡したい関数に@observeデコレータを付与した。このデコレータを付けることで、関数が実行されるたびに自動的にその処理の記録（トレース）が作成され、実行時間などのパフォーマンスデータが収集される。さらに詳細な情報を記録するために、入力メッセージやエージェントからの応答、そして会話の長さといったカスタムメタデータを明示的にログに記録するコードを追加した。これにより、エージェントがユーザーのメッセージを受け取り、応答を返す一連の流れが、Langfuse上で可視化されるようになった。また、LLMが実際にリクエストを処理し、テキストを生成する部分も、client.start_as_current_generationという機能を使って追跡できるようにした。これにより、どのモデルに、どのような入力が送られ、どのような応答が返されたのかを詳細に把握できるようになった。

これらのオブザーバビリティ設定が完了し、プログラムの内部動作を「見て理解できる」ようになったことで、ようやく問題の根本原因の特定に取り掛かれた。最初に試した比較的小さなモデルでは、やはりツールが全く起動していないことが明確に示された。モデルの能力不足を疑い、より高性能なモデルに切り替えてみたところ、新たな、そしてさらに深刻な問題が発生した。エージェントが特定のツールを繰り返し呼び出し続け、無限ループに陥ってしまったのだ。

当初、この問題はモデルの推論能力の限界か、あるいはエージェントに指示を与えるためのプロンプトに欠陥があるのではないかと考えた。何時間もかけてプロンプトを修正したり、別のモデルを試したりしたが、状況は改善しなかった。そこで、 Langfuseのトレースデータに徹底的に注目することにした。すると、ついに真の原因を発見できた。トレースを見ると、エージェントがツールを正常に実行していることは確認できたが、そのツールが返した「応答」が、エージェント自身のチャット履歴に全く追加されていないことが明らかになったのだ。つまり、エージェントはツールが成功したことを認識しているにもかかわらず、その結果が何であったかを「覚えていない」ため、同じツールを無限に呼び出し続けていたのである。エージェントが頑固だったわけでも、推論能力が低かったわけでもなく、会話履歴の管理方法に単純なバグがあっただけだった。

この問題に対しては、チャット履歴を正しく管理するための数行のコード修正を行うだけで解決した。修正後のLangfuseのトレースは、非常にすっきりと整理され、ツールが一度だけ実行され、その結果に基づいてエージェントが適切な応答を返すという、期待通りの動作を示していた。

この一連の開発とデバッグのプロセスを通じて、いくつかの重要な教訓を得ることができた。一つ目は、安易にモデルを責めないことである。最初のうちは、AIの予測不可能性を疑い、モデルに欠陥があると決めつけがちだった。しかし、最終的に問題の原因はモデルの推論能力ではなく、アプリケーション側のシンプルなチャット履歴管理のバグだった。これは、AIシステム開発において、モデル自体の性能だけでなく、それを囲むアプリケーションロジックの品質がいかに重要であるかを教えてくれた。二つ目は、優れたツールの力を決して過小評価しないことである。最初は、セットアップに時間を「無駄にしたくない」という理由で、簡単なprint()デバッグで済ませようとしていた。しかし、結局は闇雲な試行錯誤に何時間も費やし、時間を浪費することになった。対照的に、オブザーバビリティツールによる明確なトレースがあれば、数分で問題の根本原因を特定し、時間を大幅に節約できたのだ。これは、適切なツールへの初期投資が、結果として大きな効率向上につながるという、システムエンジニアリングにおける普遍的な真理を示している。