11月3日、Latent Spaceが「Building AI for Lawyers」と題した記事を公開した。法律AIスタートアップLegoraのCTO Jacob Lauritzenが、弁護士向けAIエージェントの設計・評価・組織運営の実態を語った内容だ。「顧客データに一切触れられない」という法律業界特有の制約の中で、どうやってエージェントの品質を継続的に改善するか——その問いへの回答が、リーガルテック領域でAIが普及しにくい根本的な難しさへの向き合い方を示している。
Legoraは2023年にストックホルムの地下室でスタートし、スウェーデン法律データを組み込んだChatGPTベースのツールから始まった。ローンチから18ヶ月以内（2024年4月時点）に年間経常収益（ARR）が1億ドルを突破し、顧客数は1,800社超に達した。その後も成長を続け、2025年3月に約55億ドルの評価額で5億5,000万ドルを調達、同年10月には88億ドル評価額でさらに5億5,000万ドルを追加調達している（※元記事掲載の数字をそのまま転記。評価額・調達額の詳細は元記事を参照）。今年だけで5件のM&Aも実施した。
法律業界でAIが難しい理由は単純だ。弁護士が扱うドキュメントの大半は守秘義務の対象であり、しかも多くはクライアント企業の機密情報だ。医療や金融でも同様の壁はあるが、法律は「ミスが直接、訴訟リスクや顧客の利益喪失につながる」という点で精度要件が特に厳しい。競合他社の多くがこの制約の前で評価・改善のサイクルを回せずにいる中、Legoraがとった設計上の判断が本記事の核心となっている。
顧客データに触れずにEvalをどう回すか
エージェントの品質改善において、多くのチームはトレースログを読んで問題を特定する。しかしLegoraにはそれができない。ユーザーがアップロードするドキュメントはほぼすべて機密であり、しかもその多くは法律事務所ではなくそのクライアントの所有物だ。
そこでLegoraのEvalチームは、顧客が実際に行う業務をシミュレートする環境を自前で構築している。チーム構成はエンジニア3名＋弁護士3名。具体的な例として紹介されているのが、1万ファイルのデータルームを使ったデューデリジェンスシミュレーションだ。エージェントがデータルームを調査してレポートを生成し、適切なリスク項目（レッドフラグ）を検出できているかを検証する。結果はプラクティスエリアとタスクの種類で分類したヒートマップで可視化される。新モデルへの切り替えでは「ある種の法律業務は改善するが、別の種類は劣化する」という現象が起きるため、このマトリクス管理が重要になる。
本番環境では、障害を10〜20の既知の失敗パターンに分類し、フィーチャーフラグの裏でLLMベースの軽量チェックを走らせている。
さらに、Evalが効いた具体的な数字も紹介されている。引用生成の問題が発生した際、次のモデルリリースで引用率が70%から99%へ改善した。Legoraチームは何もしていない。モデルが勝手に直した。
インフラはすべてAzureで動いている。法律事務所がAWSもGCPも承認ベンダーリストに入れておらず、Microsoft 365経由でMicrosoftだけが承認済みだったためだ。
Tabular Review：業界が名前ごとコピーした機能
Legoraのプロダクトの中核は少数のプリミティブで構成されている。ファイルを格納するプロジェクト、エージェント本体、Tabular Review、そしてリストだ。
Tabular Reviewは行がドキュメント、列が質問という構造のスプレッドシート型UIで、雇用契約1万件を一括投入して「解約予告期間は？」「IP譲渡条項は？」「退職金条件は？」を一気に抽出するような使い方ができる。最大100万セルをサポートするが、あえて最初の10行だけで実行させてプロンプトを調整してから全件に展開する設計になっている。
この機能は「業界が名前ごとコピーした」とJacobは語っている。
リストはNotionライクなデータベースで、エージェントがリストを読み書きでき、リストの変更がエージェントの起動トリガーになる。法律業務の受付はSlackボットで行い、リクエストをリストのチケットに変換する。
モデル選定とハルシネーション対策
Legoraはかなり長い間、モデル選択機能の追加を拒んだ。「弁護士が自分でモデルを選ぶべきではない。品質・コスト・レイテンシ・ガバナンス・地域対応の最適なトレードオフを見つけるのはLegoraの仕事だ」という立場だったが、最終的には折れた。
現状の見立てとして、法律業務の約60%はすでにモデルがうまく処理できる。その領域ではコストとレイテンシの問題になっている。百万トークン規模の契約書をまたいだ複雑な分析・編集には、まだより高い知性が必要だという。
ドラフト生成については、Fable（※元記事に登場するモデル名。記事内での位置づけや提供元の明示はなく、AnthropicのClaude系列である可能性が示唆されているが確定的な記述はない）とOpus（Claude Opus／Anthropicが提供するフロンティアモデル）は冗長すぎると評価しており、Astra（※同じく元記事に登場するモデル名。Google DeepMindのProject Astraとの関連性を示唆する文脈で使われているが、元記事内での明示的な説明はない）の方が簡潔だとしている。なお、FableがClaude系列のモデルである可能性も否定できないが、元記事に確定的な記述がないため断定は避ける。
ハルシネーション対策として、エージェントが書いたテキストにはすべて引用が付き、ソースPDFの該当箇所をバウンディングボックスでハイライトする仕組みを複数レイヤーで実装している。
オープンウェイトモデルについては、法律調査などの狭いタスク向けにポストトレーニングを実施している。自社でフロンティアモデルを訓練する計画はない。
法律エンジニアとFDE（前線展開エンジニア）の役割分担
Legoraには約100名の「リーガルエンジニア」というロールが存在する。大手法律事務所で3〜4年の実務経験を持ち、多くはCS学位も持つ弁護士だ。彼らはコードを書かずに、プリミティブ上で新しいプロダクトを設定する。
一方、フォワードデプロイドエンジニア（FDE）はコードを書き、顧客のCRMや文書管理システムへの統合を担う。ニューヨークに最初のFDEを採用したのは9ヶ月前で、MetaでSearch経験を持つ2回のYC創業者だという。FDEも顧客データには触れない。
大口顧客が契約すると、リーガルエンジニアを割り当て、必要に応じてFDEを追加する。1年以内にFDEは数ヶ月単位でクライアントに常駐してローテーションするチーム体制にする計画だ。
「20名で永遠にやる」→ 今は100名でも足りない
Jacob自身、入社6ヶ月でチームに「スパルタ300人」のスライドを見せ、「エンジニアは永遠に20名でいく」と宣言した。現在は100名になり、「それでも少なすぎる」と話している。
彼の現在の仕事は、少数のものを作るだけで顧客が多くを得られたと感じるシステムを構築することだ。
2年後の見通しとして、大企業はClaude Cowork（AnthropicのClaude AIを活用したコラボレーション型ワークスペースツール。企業向けに複数ユーザーが同一のAIアシスタントを共有・活用できる機能を提供するとされている）のようなツール経由でLegoraを使い、法律事務所はLegora上で直接作業するという絵を描いている。コーディング領域で起きたように、モデルラボがLegoraを締め出すことは想定していない。「4億ドルのM&Aディールであれば、Legoraを使いたいはずだ」と言い切った。
詳細はBuilding AI for Lawyersを参照していただきたい。
