エージェント改善ループにおける人間の判断

AIエージェントは、チームが長年にわたって築いてきた知識と判断を反映するときに最も効果的に機能します。しかし、多くの組織では重要な知識は文書化されておらず、従業員の頭の中に存在する暗黙知です。この知恵をエージェントに組み込むためには、ドメイン専門家からの入力を取り入れる改善ループが必要です。

本記事では、金融サービスの企業におけるトレーダー向けコパイロットの構築を例に、人間の判断をエージェント開発の各段階に統合する方法を詳しく説明します。このコパイロットは、トレーダーが市場データに関する質問をすると、自動的にSQLクエリを生成して実行し、結果を返します。従来はデータサイエンティストが手動でクエリを作成していましたが、LLMのSQL生成能力の高さから、このワークフローは自動化の有力な候補です。トレーダーはより迅速な応答を得られ、データサイエンティストはより興味深いプロジェクトに集中できます。ただし、システムを確実に動作させるためには、エージェントに金融ドメインの暗黙のルール（「今日のエクスポージャー」や「最近のボラティリティ」の解釈）とデータベースの実践的な知識（権威あるテーブルと古いテーブルの区別、効率的なクエリパターンなど）の両方を理解させる必要があります。これらの暗黙のコンテキストをエージェントに含めるには、適切な主題専門家との協力が不可欠です。

エージェントは複数のコンポーネントから構成され、それぞれが人間の判断によって改善されます。まず、ワークフロー設計：LLMは自らのアクションを順序付けることに優れていますが、決定論的なコードを使用してワークフローの一部を定義する利点もあります。レイテンシの低下、トークン数の削減、重要なステップの確実な実行が可能です。特に規制やハイリスクの環境では、アクションの順序を厳密に制御するコードが必要です。トレーダーコパイロットでは、LLMがSQLクエリを自律的に生成・実行することを許可しますが、最終的な回答がリスクとコンプライアンス要件を満たすことを検証するコードを追加します。この検証ロジックの作成には、リスクとコンプライアンスの専門家の入力が必要です。また、その情報をエージェントのプリロードコンテキストに含めることで、初回から有効な回答を生成する確率を高められます。

次に、ツール設計：開発者はエージェントが使用できるツールを実装し、LLMが呼び出しを判断するための名前、パラメータ、説明を設定します。ワークフローの段階に応じて使用可能なツールを変えることも有効です。トレーダーコパイロットのツールには、データベーススキーマの確認、クエリの実行、データベースドキュメントの取得などが含まれます。重要なトレードオフは、LLM生成クエリの柔軟性と制御のバランスです。汎用的なexecute_sqlステップは柔軟ですがリスクが高く、パラメータ化されたクエリツールは安全ですが能力が限られます。ビジネス制約を慎重に検討した上で、評価を実施してパフォーマンスとリスクの特性を把握し、すべてのステークホルダーが納得した場合にのみ出荷すべきです。

三つ目に、エージェントコンテキスト：初期のエージェントは単一のシステムプロンプトとツール定義だけを与えていましたが、業界は実行開始時にはるかに豊富なコンテキストを提供する方向に移行しています。AnthropicのSkills（10月にリリース以来急速に普及）はその顕著な例です。チームは事前にドキュメント、例、ドメインルールをキュレーションし、実行時にエージェントが必要なものを取得できるようにします。これにより、システムプロンプトを肥大化させることなく、はるかに多くの知識をエージェントに活用させることができます。効果的なエージェント設計には、どの知識にアクセスさせるかを決定し、適切なタイミングで正しい情報を取得できるように整理することが含まれます。トレーダーコパイロットは最低限、データベースの使用方法とスキーマを理解する必要があります。追加の知識が多ければ、その構造化と段階的な開示方法の決定にも時間を割く必要があります。

エージェントが起動時に利用できる情報の選択と構造化は、コンテキストエンジニアリングの一部です。コンテキストエンジニアリングは、タスクの進行に伴って各LLM呼び出しで提供する情報がどのように進化するかもカバーします。人間のステークホルダーがエージェントの出力や評価スコアをレビューした際のフィードバックは、エンドツーエンドのコンテキストエンジニアリングのアプローチに影響を与える可能性があります。

ここからは、人間の判断をエージェント改善ループにどのように組み込むかを説明します。LangChainでは数百の組織と協力してきましたが、最も成功したチームはタイトなイテレーションループを採用しています。迅速にエージェントを構築し、本番または本番に近い環境にデプロイし、各ステップでデータを収集して改善を導きます。これを「エージェント改善ループ」と呼びます。迅速かつ頻繁な反復が重要である理由は、エージェントの振る舞いを決定するのはコードではなくLLMのリアルタイム推論だからです。AIエージェントが何をするかは、実際に動かすまでわかりません。また、エージェントのインターフェースは自由形式（テキストボックスに何でも入力可能）であることが多く、ユーザーとエージェントの相互作用を予測するのはさらに困難です。エージェントをユーザーの前に置くことこそが、最終的な成功に必要なデータを収集する唯一の方法です。

改善ループの各フェーズを通じて、効果的に人間の入力を組み込む方法を見ていきます。まず、開発フェーズでは、エンジニアはプロジェクト要件の一部として少なくとも少数のユースケースシナリオと期待される動作を持つべきです。初期テストでコアタスクが正しく実行されることを確認します。本番準備が近づいたら、プロダクトマネージャーや主題専門家と協力して、全体的な動作と主要サブコンポーネントの両方を評価する包括的なテストスイートを構築します。トレーダーコパイロットでは、LangSmithのデータセット機能を使用して、自然言語の質問と正しい回答のペアからなるグラウンドトゥルースデータセットを手動で作成します。また、データベースのコンテキストで良いパフォーマンスのSQLの例を含むデータセットも作成します。開発中は、LangSmithの評価機能を使用してこれらのデータセットに対してテストを実行します。LangSmith UIにより、技術者と非技術者のチームメンバーが評価結果を確認し、注釈を付けられるため、全員が開発者の次のステップについて認識を合わせられます。このフェーズでは、手動テストで遭遇した興味深いケースから着想を得た例で初期データセットを拡充することで、ミニフライホイールを作成できます。これによりフィードバックループを徐々に自動化し、v1の出荷時点で包括的なテストスイートを確保できます。

デプロイ後は、自動評価とモニタリングを使用して、人間の注意を最も必要な場所に向けます。エージェントが公開されたら、その信頼性を確保し、問題や改善の機会を迅速に特定する必要があります。ユーザーエクスペリエンスを検証する従来の方法は満足度調査やユーザーインタビューですが、その欠点はユーザーが話すことを測定するだけで、実際の行動を測定しないことです。LLM-as-a-judge評価器はより堅牢な方法を提供します。本番データに対して実行される自動評価は、エージェントを監視し、人間の注意を必要とする状況を浮き彫りにします。例えば、LLM判定器はユーザーが不満を表明したメッセージを自動的に検出し、それらのインタラクションをレビュー用にフラグ付けできます。チームメンバーはトレースを調査し、問題がバグ、エージェントの知識のギャップ、ワークフローの弱点のいずれかを判断できます。

仮想的なトレーダーコパイロットの例では、まずLangSmithトレーシングを設定してエージェントとトレーダーのすべてのインタラクションをキャプチャします。次に、LangSmithのオートメーション機能を使用して、オンライン評価を設定します。具体的には、低速または危険なSQLクエリの自動コードチェックや、ユーザーの不満を検出するLLM-as-a-judge評価器を設定します。これにより、人間の介入が必要なケースを自動的に特定し、効率的な改善サイクルを実現します。

最終的に、人間の時間投資に対する高いリターンの鍵は、専門家の判断を自動評価に変換することです。LangSmithのAlign Evaluator機能を使用すると、厳選された例と主題専門家からのフィードバックを用いてLLM-as-a-judge評価器を調整できます。これにより、大規模な手動レビューに依存せずに、広範かつ継続的なテストが可能になります。この改善ループを繰り返すことで、エージェントはチームの知識と判断を徐々に吸収し、高いパフォーマンスと信頼性を実現します。