【ITニュース解説】From Fragile to Production-Ready: Reliable LLM Agents with Bedrock + Handit

システムエンジニアを目指す初心者が、大規模言語モデル（LLM）を使ったシステムを開発する際に直面するであろう「本番環境での信頼性」という重要な課題について解説する。

デモンストレーションでLLMエージェントが素晴らしい性能を見せても、実際に多くのユーザーが使う本番環境に投入すると、様々な問題が発生することが多い。LLMエージェントとは、人間のように計画を立て、推論し、ツール（外部システムやデータベースなど）を呼び出し、複雑なタスクをこなすプログラムのことである。デモではまるで魔法のようにスムーズに動くエージェントも、本番環境では思わぬ落とし穴がある。

例えば、エージェントがツールを呼び出す際に、その呼び出しが静かに失敗してしまうことがある。システムエラーが表示されるわけでもなく、エージェントは何も問題がないかのように振る舞い続けるため、ユーザーは期待した結果が得られずに困惑する。また、エージェントが情報検索を行う際に、関連性の低い情報を拾ってきたり、ひどい場合には完全に誤った情報（これを「ハルシネーション」と呼ぶ。モデルが事実に基づかない情報を生成すること）を生成してしまうこともある。さらに、同じ入力を与えても、エージェントが毎回異なる計画を立て、異なる結果を出すといった不安定な挙動を示すことも珍しくない。

このような問題の厄介な点は、多くの場合、エージェントが「静かに壊れる」ことにある。つまり、システム全体が停止するような大々的なエラーではなく、細かな不具合が潜み、それが積み重なってユーザーエクスペリエンスを損ねていく。開発者が問題に気づく頃には、すでに多くのユーザーが不満を抱えている状態になりかねない。

こうした状況を解決するために、AWS BedrockとHanditという二つの技術が注目されている。AWS Bedrockは、AnthropicのClaudeやMetaのLlama、Cohere、AmazonのTitanといった世界トップクラスのLLMを、企業向け機能（セキュリティ対策のGuardrails、知識ベースのKnowledge Bases、エージェントの構築機能）と共に提供する優れた基盤である。しかし、どんなに高性能なモデルや基盤があっても、それだけでシステムの信頼性が保証されるわけではない。

システムの信頼性は、単にモデルの性能だけでなく、システム全体の特性として考慮する必要がある。具体的には、「可観測性（observability）」、「評価（evaluation）」、「継続的な改善（continuous improvement）」という3つの要素が不可欠となる。Handitは、この信頼性を確保するためのソリューションである。

Handitを導入すると、わずか3行のコードで以下のことが可能になる。まず、エージェントが実行するすべてのステップ（LLMへの入力や出力、ツールの呼び出しなど）を詳細に「トレース（追跡）」する。次に、エージェントの出力が、あらかじめ設定したルール（正確性、事実との整合性、明瞭さ、コンプライアンス、応答速度など）に照らして「評価」される。そして、問題が検出された場合、プロンプトの内容やモデルのパラメーター設定を「自動的に改善」するための提案を行う。さらに、システムの挙動に異常な変化が見られた際には、即座に「アラート」を出す。これにより、ユーザーが不満を感じる前に問題を検知し、対処できる体制が整う。

Handitが提供するこの一連の流れは、「信頼性ループ」と呼ばれている。信頼性ループは、LLMが呼び出されるたびに機能し、Bedrock上で動作するエージェントをより堅牢にする。

信頼性ループの具体的な仕組みは以下の通りである。

1. トレース（Trace）: エージェントがBedrockのLLMを呼び出すたびに、その入力内容、LLMからの出力結果、使用されたトークン数、応答にかかった時間など、すべての情報が詳細に記録される。これにより、エージェント内部で何が起きているのかが完全に可視化され、ブラックボックスではなくなる。

2. 評価（Evaluate）: 記録されたLLMの出力は、開発者が定義したルールに基づいてテストされる。例えば、顧客サポートのエージェントであれば、回答の正確性、提示された情報が事実に基づいているか（根拠性）、回答が明確か、会社のポリシーに違反していないか、応答速度は適切か、といった多岐にわたる項目が評価される。ビジネスの具体的なニーズに合わせて、カスタムの評価基準を設定することも可能である。

3. アラート（Alert）: 評価の結果、エージェントの回答の正確性が低下したり、応答時間が急激に長くなったりといった異常が検出された場合、システムはすぐにアラートを生成する。この仕組みにより、ユーザーからの苦情を待つことなく、開発チームが問題に早期に気づき、対応を開始できる。

4. 改善（Improve）: 問題が検出された際に、Handitは単にアラートを出すだけでなく、その問題の原因となっている可能性のあるプロンプトやモデルのパラメーター設定に対して、自動的に修正案を提案する。開発者はHanditのダッシュボード上でこれらの修正案を確認し、適用することもできるし、場合によってはGitHubのプルリクエストとして自動的に生成・提出させることも可能である。これにより、継続的な品質向上が自動化される。

Handitの導入は非常に簡単で、既存のエージェントコードを大きく変更する必要はない。Handitは、エージェントのロジックを直接置き換えたり、Bedrockそのものを置き換えたりするのではなく、エージェントの主要な関数（エントリーポイント）を「ラップ（包み込む）」する形で機能する。

例えば、ユーザーからのメッセージを処理するエージェントが、まずユーザーの意図を分類し、次に知識ベースを検索し、最後に最終的な応答を生成するという一連の処理を行っているとする。これらの各ステップでBedrockを呼び出す場合、Handitはこれらの処理をまとめる最上位の関数に、@tracingというHanditのデコレータ（特定の関数に機能を追加するための特別な記法）をたった1行追加するだけでよい。

@tracing(agent="customer-service-agent") async def process_customer_request(user_message: str): intent = await classify_intent(user_message) context = await search_knowledge(intent) response = await generate_response(context) return response

このようにすることで、元のエージェントロジック（意図分類、情報検索、応答生成）は一切変更せず、すべてのLLM呼び出しがHanditによってトレースされ、自動評価が実行され、問題があれば修正案が提案されるようになる。これにより、わずか数行の追加コードで、エージェントが行うBedrockへのすべてのリクエストが信頼性ループの一部となる。

HanditをBedrockベースのエージェントに組み込んだ後、開発環境であっても本番環境であっても、エージェントのすべての実行は信頼性ループを通る。その結果、開発者は以下の恩恵を受けることができる。

まず、「完全な可視性」が得られる。エージェントへの入力、出力、各ステップでの応答時間、使用されたトークン数など、すべての実行データがトレースとして捕捉されるため、エージェントの内部で何が起こっているのかを正確に把握でき、推測に頼る必要がなくなる。

次に、「自動評価」が実行される。エージェントの各応答は、正確性、根拠の有無、回答の安定性、社内ポリシーとの合致、トーン（口調）など、開発者が定義したルールやカスタム基準に基づいて自動的にチェックされる。これにより、品質管理のプロセスが自動化される。

そして、「継続的な改善」が実現される。Handitは単に問題を検出するだけでなく、改善策を生成する。具体的には、より良い結果を生み出すためのプロンプトの更新案や、モデルのパラメーター調整案が提示される。これらの修正案はダッシュボードから簡単に適用できるほか、GitHubのプルリクエストとして提案し、コードレビュープロセスを通じて本番環境にデプロイすることも可能である。

このように、わずかな設定を行うだけで、Bedrockを基盤としたLLMエージェントは盲目的に実行されることがなくなる。すべての呼び出しが追跡され、評価され、自動的に改善されるため、デモンストレーションで期待通りの動きをしたエージェントが、実際のユーザーが利用する本番環境でも確実に機能するという大きな自信を得られる。Handitは、エージェントを監視し、修正案を提案し、信頼性管理を自動化する、まさにチームの一員となるような存在であり、開発者がより重要な「構築」というタスクに集中できるよう支援する。