LangChainを用いた安定的なAIエージェント実装

ツール導入前の課題

LangChain導入前からAWS Bedrock Agents を用いてPoCを進めていましたが、その中で以下の2つの課題がありました。

一つ目は「決定性の欠如」です。 AIエージェントに対して同じリクエストを送ったとしても、その動作が毎回異なってしまうという問題が発生していました。例えば、ある時は詳細なデータまで取得する一方で、別の時にはそうでない、といった具合です。動作が不安定であることで、ユーザー体験や精度も安定しないという問題がありました。

二つ目は「トレーサビリティの不足」です。 Bedrock AgentsはAWSのコンソール上では文字ベースで実行ステップを追うことができましたが、API経由での実行時は、CloudWatch Logsに大量のテキストログが出力されるだけでした。そのため、特定の処理を追跡したり、ボトルネックを分析したりする作業が非常に煩雑で、精度改善のサイクルを回すことが困難な状況でした。

こちらの記事では、PoCの段階ごとにどのような課題があってマネージドなサービスからLangChainに移行したかについて紹介しています。

どのような状態を目指していたか

1. 動作の決定性担保

同じリクエストに対しては、毎回必ず同じ処理フローを実行できるようにすることです。例えば、必要なデータをまず固定的にデータベースから取得し、その後にLLMに要約させるなど、固定化できる部分は決定論的な処理に移行することを目指しました。

2. 継続的改善サイクルの構築

詳細なトレーサビリティを確保し、デバッグや精度向上を容易にすることです。またスコア付きの評価を行うことで定量的に品質を管理し、改善のサイクルを回せるようにすることを目指しました。

• LangChain
• LlamaIndex
• Mastra

• コミュニティの規模と情報量

PoC段階では、技術的な問題で足踏みしたくありません。問題解決の手がかりとなるドキュメント、サンプルが豊富にあるかどうかを重視しました。

• コンポーネントの充実度

RAG、ツール連携、評価など、使用したい機能がコンポーネントとして揃っているか、それによって独自実装の手間をどれだけ減らせるかを考慮しました。

• ワークフロー制御の柔軟性

課題であった「決定性」を担保するため、複雑な処理フローを固定化できるかどうかも重要なポイントでした。

• OSSとしての成熟度

開発が活発であり、問題が発見された場合でも迅速に対応されるかどうかも、将来的な運用を見据えて考慮しました。

各ツールの所感

• Mastra：過去に個人で使用経験があり、シンプルで良いツールだと感じていましたが、LangChainと比較すると自身で実装すべき部分が多い印象でした。
• LlamaIndex：RAGに特化した設計は魅力でしたが、複雑なワークフローの制御やコミュニティの大きさという点では、LangChainに軍配が上がりました。
• LangChain：最終的に、コミュニティの規模、コンポーネント数、開発速度のバランスが最も良いと判断しました。

• コミュニティの圧倒的な大きさ：PoC段階で迅速に機能を提供するため、情報が多く困りづらいツールであることを最優先しました。
• LangGraphの存在：複雑なワークフロー制御、特に状態遷移を固定化する機能があり、最大の課題であった「決定性」を解決できると期待しました。
• コンポーネントの豊富さ：RAGやツール連携など、必要としていた機能がほぼ全て揃っていました。
• OSSとしての開発速度：新機能のリリースや修正が頻繁に行われており、問題解決が早い点も魅力でした。

改善したかった課題はどれくらい解決されたか

• 決定性：LangGraphを採用したことで、同じリクエストに対して常に同じ処理フローを実行できるようになりました。
• トレーサビリティ：実行トレースをLangfuseに送信することで、各リクエストの詳細を視覚的に、そして容易に把握できるようになりました。

どのような成果が得られたか

1. 決定性の確保による品質向上

ワークフローの品質が安定したことで、これまで不安定な動作の対応に割かれていた時間を、他の改善活動に充てることができるようになりました。結果として、AIエージェント全体の精度も向上しました。

2. 継続的改善サイクルの実現

トレーサビリティが確保されたことで、「課題特定 → 修正 → 効果測定」という改善サイクルを高速に回せるようになりました。

それまで使用していたBedrock Agentsはマネージドなサービスだったため、以下のようなトレードオフもありました。

• 実装コストの増加

それまで利用していたAWS Bedrock Agentsと比較すると、当然ながらコードによる実装が必要となるため、初期の実装コストは増加しました。

• インフラ管理の責任拡大

マネージドサービスとは異なり、LangChainを動かすためのサーバーを自前で構築・管理する必要があり、インフラ面の責任範囲が広がりました。

• 学習コスト

LangChainおよびLangGraphのエコシステム全体を理解し、さらにトレーサビリティのためのLangfuseの構築・運用を習得するには、相応の学習時間が必要でした。

私たちの経験としては、PoCの初期段階ではまずAWS Bedrock Agentsのような簡易的なツールでアイデアを素早く検証し、その上で「決定性」と「継続的改善サイクル」の必要性が明確になったタイミングで、LangChainへの移行を検討するのが良いステップだと感じています。 また、導入する際はLangChain単体でだけではなくエコシステムにあるツール群をセットで利用することで、独自実装の部分を減らし、導入効果を最大化できるでしょう。

今後はワークフロー内の各ステップを個別に改善し、過去のバージョンと比較しながら、さらなる精度向上を目指していきます。 また、より多くのユースケースに対応したエージェントやワークフローを構築していきます。