2025年5月13日から5月14日にかけてサンフランシスコで開催されたAIエージェント開発のテックイベント「LangChain Interrupt」。Day 2では、リーガルAIエージェントの分野で注目を集めるHarvey社でエンジニアリングを率いるBen Liebald氏が登壇。
「Building Reliable Agents: Raising the Bar（信頼性の高いエージェントの構築：基準の引き上げ）」と題し、同社がどのようにリーガルAIエージェントを構築し、その品質を評価しているかについて語られました。
Harveyとは：リーガル・プロフェッショナルサービス向けドメイン特化AI
Harveyは、リーガルおよびプロフェッショナルサービス向けのドメイン特化型AIプラットフォームです。Ben Liebald氏は、Harveyが提供する製品群を以下のように紹介しました。
- 文書のドラフト作成や要約のための汎用アシスタント
- 大規模な文書抽出ツール
- 多数のドメイン特化型エージェントやワークフロー
Harveyのビジョンは2つあります。1つは「ユーザーの全ての作業をHarveyで行えるようにすること」、もう1つは「ユーザーが作業する場所ならどこでもHarveyを利用できるようにすること」です。ここで言う「ユーザー」とは、弁護士、リーガルプロフェッショナル、そしてプロフェッショナルサービスプロバイダーを指します。
例えば、企業内部のナレッジベースやテンプレートといった企業特有の情報を活用してアウトプットをカスタマイズしたり、何十万もの文書を一度に分析し、その結果を表形式で出力したり要約したりすることで、膨大な作業時間を節約できると説明しました。また、レッドライン分析や特定種類の文書ドラフト作成など、複雑なタスクを達成するためのワークフローも提供しています。
さらに、マルチステップエンジン、検索機能、パーソナライゼーションとメモリの強化、長時間実行タスクの処理能力など、エージェント機能も製品に組み込んでいるとのことです。Harveyは世界中の法律事務所や大企業から信頼を得ており、米国では上位100法律事務所の3分の1、上位10法律事務所のうち8社がHarveyを利用している実績も紹介されました。
リーガル分野における品質の課題
Ben Liebald氏は、リーガル分野で高品質な製品を構築し評価することがなぜ難しいのか、その理由をいくつか挙げました。
まず、弁護士が扱う文書は非常に多く、複雑で、数百から数千ページに及ぶことも珍しくありません。これらの文書は判例法や立法など、大規模なコーパスの一部であり、相互に広範な参照を含んでいます。文書自体も、手書き文字、スキャンされたコピー、複数列レイアウト、埋め込み表など、形式が多様で複雑です。
生成するアウトプットも同様に複雑です。長文のテキストに加え、複雑な表やレポート用の図、そしてリーガルプロフェッショナル特有の専門用語や言い回しが求められます。
「間違いは文字通りキャリアに影響を与える可能性があります。そのため、検証が鍵となります。」 (Mistakes can literally be career impacting. So verification is key.)
Ben Liebald氏は、単なるハルシネーション（完全なでっち上げ）だけでなく、わずかな誤解や誤った解釈による不正確な記述も問題となると指摘。Harveyでは、全ての記述を検証可能なソースに紐付ける引用機能を備え、AIが提供した情報の正確性をユーザーが検証できるようにしています。
さらに重要な点として、リーガル分野における品質は非常にニュアンスに富み、主観的な概念であると強調しました。同じ質問に対する2つの正しい回答があったとしても、弁護士は記述のニュアンスや定義の詳細さによって一方を強く好むことがあります。Ben Liebald氏は、契約書のある条項（「Materiality scrape and indemnification」と呼ばれるもの）に関する2つの回答例を挙げ、どちらも事実に即して正しいものの、社内弁護士はよりニュアンスに富み詳細な定義を含む回答を明確に好んだと説明しました。
「ポイントは、どちらが良いか、あるいは品質が何を意味するのかを自動的に評価するのは非常に難しいということです。」 (The point is, it's really difficult to assess automatically which of these is better or what quality means.)
最後に、顧客データの機密性の高さから、信頼できるデータセットや製品フィードバック、バグレポートの入手が困難であることも、リーガルAIプロダクト開発の課題として挙げられました。
Harveyにおける製品開発と評価
このような課題に対し、Harveyはどのように製品開発と評価を行っているのでしょうか。Ben Liebald氏は、最高の評価（Evals）は製品開発プロセスに緊密に統合されており、最高のチームは評価に全体論的にアプローチすると述べました。
製品開発の原則
Harveyが重要視する製品開発の原則は以下の3つです。
応用AI企業であること (Applied AI Company) 「最先端のAIとクラス最高のUIを組み合わせる必要があります。単に最高のAIを持つだけでなく、顧客がいる場所で顧客に対応し、彼らの実際の問題解決を助けるような形でパッケージ化された最高のAIを持つことが重要です。」 (First off, we're an applied AI company. So what this really means is that we need to combine the state of the art, AI, with best in class, UI. It's really not just about having the best AI, but really about having the best AI that's packaged up in such a way that it meets our customers where they are, it helps them solve their real problems.)
『弁護士』がプロセスに組み込まれること (Lawyer-in-the-Loop) 製品開発プロセスのあらゆる段階に弁護士を参加させています。リーガル分野の複雑さとノイズを理解するために、弁護士のドメイン専門知識とユーザーへの共感が不可欠です。弁護士はエンジニア、デザイナー、プロダクトマネージャーと協力し、ユースケースの特定からデータセット収集、評価基準作成、UIイテレーション、エンドツーエンドテストまで、製品構築のあらゆる側面に関与します。
PRDよりプロトタイプ (Prototype over PRD) 製品要求仕様書（Product Requirement Document）よりも、頻繁なプロトタイピングとイテレーションを重視します。プロトタイプはアイデアを具体化し、理解を助けます。Harveyは、プロンプト、アルゴリズム、UIのイテレーションを行うための独自のAIプロトタイピングスタック構築に多大な投資をしています。
Ben Liebald氏は、これらの原則に基づき、例えばクライアントアラート作成支援ワークフローを構築するプロセスを紹介しました。弁護士が初期コンテキストを提供し、エンジニアやプロダクトチームと協力してアルゴリズムと評価データセットを構築。エンジニアがプロトタイプを作成し、専門家チームが満足するまでイテレーションを繰り返す、という流れです。
評価 (Evaluations)
評価については、主に3つのアプローチを取っていると説明しました。
人間による嗜好判断の効率的な収集 リーガル分野のニュアンスと複雑さを考慮すると、人間による嗜好判断と評価が依然として最高品質のシグナルです。Harveyでは、スループット向上と運用改善に注力し、より多くの評価を迅速かつ低コストで実行できるようにしています。 古典的な手法として、標準化されたクエリデータセットに対し、同じクエリに対する2つの応答を評価者（弁護士など）に比較してもらう「サイドバイサイド比較」を紹介。評価者は「どちらを好むか」「各応答をどう評価するか（1～7のスケール）」「定性的なフィードバック」を提供します。この結果は、新しいモデルやプロンプト、アルゴリズムをリリースする際の判断材料となります。
モデルベースの監査評価 (LLM as a judge) 人間によるレビューの品質に近似するモデルベースの評価、いわゆる「LLM as a judge」の構築を目指しています。学術的なベンチマーク（例: LegalBench）は単純化されすぎているため、Harveyは独自の評価ベンチマーク「BigLaw Bench」を構築。これは、弁護士の実際の業務に近い、主観的な回答を伴う複雑でオープンエンドなタスクを含みます。 LLMに評価させるためには、評価基準（rubric）を作成し、構造、スタイル、内容、ハルシネーションの有無などのカテゴリに分類します。これらの評価基準は、社内のドメイン専門家である弁護士によって作成され、クエリと応答のペアごとに異なります。
問題の分解 複雑なマルチステップのワークフローやエージェントについては、問題をコンポーネントに分解し、各ステップを個別に評価できるようにします。これにより、問題がより扱いやすくなります。 例えばRAG（Retrieval Augmented Generation）では、クエリ書き換え、検索、回答生成、引用作成といった各ステップが個別の評価対象となり得ます。
GPT-4.1リリースの事例
これらの評価アプローチを具体的に示すため、OpenAIがGPT-4.1をリリースした際の事例が紹介されました。
まず、BigLaw Benchで初期評価を行い、有望な結果を得ました。次に、人間による評価（サイドバイサイド比較）を実施し、ベースラインシステムと比較して新システムが大幅に高品質であることを確認しました。
※ システムのチューニングなしに、モデルのアップグレードによってベースラインよりも品質が向上するというのが、まさにLLM時代のアプリケーションという感じです。
しかし、これで終わりではなく、さらに製品固有のデータセットで追加テストを行い、社内チームからの定性的なフィードバックを収集（ドッグフーディング）。その結果、例えばGPT-4.1が全ての応答を「Certainly!」で始める傾向があるといったリグレッション（意図しない品質低下）を発見し、顧客に展開する前に対処したとのことです。
学びと今後の展望（Hot Takes）
Ben Liebald氏は、Harveyでの経験から得られた3つの重要な学びと、少し「ホットな見解（Hot Takes）」を含む今後の展望を共有しました。
学び1：ツールを磨く (Sharpen Your Axe)
「結局のところ、私の考えでは、評価の多くは実際にはエンジニアリングの問題です。したがって、強力なツール、優れたプロセス、そしてドキュメンテーションの構築に時間を投資すればするほど、それはすぐに報われます。」 (At the end of the day, a lot of evaluation is, in my mind, really an engineering problem. So the more time we invest in building on strong tooling, great processes and documentation, the more it will pay back quickly.)
評価の実行が容易になれば、より多くのチームが評価を頻繁に利用するようになり、結果としてイテレーション速度と製品品質、そして製品品質への自信が向上すると述べました。Harveyでは、LangChain Smith（LangSmith）を開発者向け評価の一部で広範囲に活用しつつ、人間による評価者中心の評価については独自のツールも構築しているとのことです。「恐れずに組み合わせて、評価し、自分にとって最適なものを見つけることをお勧めします」と付け加えました。
学び2：評価と「テイスト」のバランス
厳密で再現可能な評価は不可欠ですが、それだけでは不十分だとBen Liebald氏は指摘します。
「評価は重要ですが、『テイスト』もまた重要だということです。…人間の判断、定性的なフィードバック、そしてテイストもまた重要です。」 (Evals matter, but taste really does too. ...human judgment and qualitative feedback and taste really matter too.)
評価者、社内ドッグフーディング、顧客からの定性的なフィードバックから多くを学び、評価指標には大きな影響を与えないものの、製品をより速く、より一貫性があり、より使いやすくするなど、実際に製品を良くする改善も行っていると語りました。
学び3：データ、特に「まだ存在しない最も重要なデータ」
最後に、エージェントの将来を見据えた「ホットな見解」として、データに関する考察が述べられました。
「最も重要なデータはまだ存在しない、ということです。」 (The take here is the most important data doesn't exist yet.)
過去のAIの進歩は、公開されているデータを取り込み、より大きなモデルを作ることで達成されてきました。しかし、現実世界のタスクのためのドメイン特化型エージェントワークフローを構築するためには、「より多くのプロセスデータ、つまり、それらの企業内で今日どのように物事が進められているかに関するデータが必要だ」と主張しました。 (But I would argue that to build domain specific agentic workflows for real world tasks, we actually need more process data, the kind of data that tells you how things get done inside of those firms today.)
例えば、企業間のM&A取引のような複雑なプロセスは、通常、明文化されたプレイブックが存在せず、口頭でのやり取りや文書の余白のメモなどに暗黙知として存在します。
「もし私たちがそのようなデータ、そのようなプロセスデータを抽出し、それをモデルに適用できれば、それはエージェントシステムを構築する上での次のブレークスルーに本当につながる可能性があると私は考えています。」 (And so if we can extract that kind of data, that kind of process data, and I think it has the apply that to models, it has the potential to really lead to the next breakthroughs when it comes to building agentic systems.)
この「プロセスデータ」の活用が、今後のエージェントシステムにおけるブレークスルーの鍵になるかもしれないという、刺激的な視点でセッションは締めくくられました。
まとめ
HarveyのBen Liebald氏によるセッションは、特にリーガルという専門性と正確性が極めて高度に要求されるドメインにおいて、いかにして信頼性の高いAIエージェントを構築し、その品質を担保していくかという課題に対する、実践的かつ深い洞察に満ちたものでした。
「Lawyer-in-the-Loop」という専門家を巻き込むためのアプローチ、人間による評価とモデルベース評価を組み合わせた多角的な評価戦略、そして「プロセスデータ」という新たなデータソースへの着目は、AIエージェント開発に携わる多くの開発者や研究者にとって、示唆に富む内容なのではないでしょうか。
