Legoraが顧客データを見ずに法的AIエージェントを構築する方法

LegoraのCTOであるJacob Lauritzen氏は、同社の評価額が88億ドルに達したことを踏まえ、法務分野におけるエージェント型ワークフローの構築に関する技術的な洞察を最近共有しました。Latent Spaceとの対談の中で彼は、顧客データへの直接アクセスを禁止する厳格なプライバシー制約を守りながら、ドキュメント中心の領域で信頼できるAIシステムをチームがどのように構築しているかを詳細に説明しました。

何が起きたか

Legoraはストックホルムの地下で設立されて以来、急速に成長し、単純な検索ツールから文書作成や契約レビューを行う包括的なプラットフォームへと進化しました。同社は3月に5.55億ドルの評価額で5億5,000万ドルを調達し、10月にはさらに5億5,000万ドルを確保して評価額を88億ドルまで引き上げました。4月の時点で顧客数は1,800社を超え、年間経常収益（ARR）は1億ドル以上となり、現在このプラットフォームは弁護士、クライアント、自律エージェント間の作業を調整しています。

この採用を推進しているビジネスモデルの変化は重要です。従来、弁護士は時間課金を行っており、効率化ツールに対するインセンティブがありませんでしたが、市場圧力により定型的な業務は固定プロジェクト料金へ移行しつつあります。これにより、法律事務所は収益を失うことなくAIを活用してスピードを向上させ、高付加価値な人的リソースを複雑な訴訟やクライアント関係の構築に振り向けることが可能になります。AIがジュニアスタッフを置き換えるという懸念とは裏腹に、Lauritzen氏はこれらのツールを使ってより多くの仕事をこなせる熟練したジュニア弁護士の価値が高まっていると指摘しています。

仕組み

法テックにおけるAIエージェントの評価は、データの機密性という独自の課題を提起します。Legoraはユーザーのトレースやクライアントファイルを読むことができず、モデル改善に利用できません。代わりに同社は、現実世界の法的タスクをシミュレートする強化学習環境を構築するために、3人のエンジニアと3人の弁護士を雇用しています。例えば、数千のファイルを含む合成データルームを作成し、エージェントがデューデリジェンスを実行して特定のレッドフラグ（危険信号）を識別できるようにします。新しいモデルが導入された際の性能変化を検出するため、結果はプラクティスエリア別にヒートマップでマッピングされます。

モデル選択を管理するために、Legoraはユーザーに選択させるのではなく、内部のルーティングシステムを使用しています。このシステムは品質、コスト、レイテンシ、ガバナンス要件を自動的にバランスさせます。シンプルなタスクには安価で高速なモデルを使用しますが、数百万トークンのコンテキストにわたる複雑な分析にはより高度な知能が必要です。同社はリーガルリサーチなどの狭いタスク向けにオープンウェイトモデルの後訓練を行いますが、フロンティアモデルの訓練は避けています。ハルシネーションに対処するため、すべての出力にはソースPDF内の具体的なバウンディングボックスにリンクする引用が含まれます。

主要な詳細

• Legoraは完全にAzure上で稼働しています。法律事務所はOffice 365を通じてMicrosoftベンダー承認を得ていましたが、AWSやGCPは制限されることが多かったためです。
• エンジニアリングチームは、コードを書かずに製品を設定する「リーガルエンジニア」と、統合用の本番コードを書く「フォワードデプロイドエンジニア」を区別しています。
• コアな製品プリミティブには、プロジェクト、エージェント、大量文書分析用のTabular Review、自動化をトリガーするリストが含まれます。
• 本番環境での障害モードは10〜20の既知のカテゴリーに分類され、機能フラグの背後で安価なLLMベースのチェックが実行されています。
• 同社は、仕事のシミュレーションとエージェント評価を支援するために、コンピュータサイエンスの学位を持つ弁護士など約100名のリーガルエンジニアのプールを維持しています。
• Tabular Reviewでは、ユーザーは最大100万セルを分析でき、小バッチから始めてプロンプトを改良してからスケールアップできます。

なぜ重要なのか

規制産業でエージェントを開発する開発者にとって、Legoraのアプローチは、パフォーマンス向上のためにライブの顧客データへのアクセスが必要ないことを示しています。合成評価環境とシミュレーションへの多大な投資により、チームは安全に反復作業を行えます。この手法は、ユーザー入力による直接的なモデル訓練をプライバシー法が禁止しているヘルスケアや金融などのセクターにとって極めて重要です。また、評価ループにおいてドメイン固有の専門知識がいかに重要かを示しており、法的知識とエンジニアリングの厳密さを融合させています。

インフラストラクチャの選択も、エンタープライズセールスにおける実用的な制約を明らかにしています。Azureの選択は技術的な好みではなくコンプライアンス上の必要性であり、ベンダー承認ステータスがアーキテクチャを早期に決定づける可能性があることを示しています。さらに、設定をコードから分離することで、非エンジニアが新機能をリリースできるようになります。この構造により、コアエンジニアリングチームを肥大化させることなく、大手クライアント向けの迅速なカスタマイズが可能になり、従来のプロフェッショナルサービスモデルよりも優れたスケーラビリティを実現します。

あなたができること

• ライブのデータトレースに依存するのではなく、最も複雑なユーザーワークフローを模倣する合成評価データセットを構築してください。
• コストと品質のバランスを取る自動モデルルーティングを実装し、エンドユーザーからの意思決定負担を取り除いてください。
• エンジニアリングロールを、コア製品ビルダーと、クライアント固有の統合を扱うデプロイメントスペシャリストに分割してください。
• 新しいコードを書かなくても異なるユースケースに合わせて再構成できる、リストやテーブルのような柔軟なプリミティブを中心に製品を設計してください。
• ユーザーの信頼を築くために、すべてのAI生成出力に検証可能な引用またはソース資料へのリンクを含めてください。
• 単なる技術的優位性だけでなく、ターゲット業界における既存のエンタープライズ承認に基づいてクラウドプロバイダーを選択してください。