裁判事例をでっち上げたAI——そして、それを不可能にするために私たちが構築したアーキテクチャ
私は、多くの人がリーガルAIを構築するやり方を信用しなくなった、まさにその瞬間を覚えている。
ある火曜日の夜遅く、私は次の裁判記録を読んでいた——Mata v. Avianca。要約ではない。ツイートのスレッドでもない。実際の訴訟書類だ。ある弁護士が、次の判例を引用した準備書面を提出していた——Varghese v. China Southern Airlines、Shaboon v. Egyptair、そしてPetersen v. Iran Air——事件番号、日付、そして引用された判示まで完備されていた。相手方弁護士がそれらを探しに行かざるを得ないほど、説得力があった。だが、それらの判例は存在しなかった。ChatGPTがでっち上げたのだ。そして、その弁護士が再確認のためにChatGPTに戻って尋ねると、モデルは自らの捏造を平然と裏付けた——「はい、それらの判例は確かに存在し、信頼できる法律データベースで見つけることができます。」
私はその記録を置いて、こう思った——これはプロンプトの問題ではない。これはアーキテクチャの問題だ。そして、リーガルAI業界のほとんどは、そうではないふりをしている。
その一件——5,000ドルの制裁金、司法上の譴責、そして評判の失墜という結果を招いた——は、私のチームがVeriprajnaで今構築しているものの出発点となる事例研究になった。すなわち、リーガルAIのための引用強制型GraphRAGシステムである。それは、AIが物理的にできない——Knowledge Graphの検証済みエントリに対応しない判例引用を出力すること。「おそらくしないだろう」ではない。できないのだ。
なぜその違いが重要なのか、それを構築するのに何が必要だったのか、そしてなぜ私が、基盤モデルにチャットボットのインターフェースを貼り付けてそれを「リーガルAI」と呼ぶ時代は終わったと信じているのか——それを説明したい。
なぜChatGPTは架空の裁判事例をでっち上げたのか?
これは誰もが問う質問だが、正しく答えられる人はほとんどいない。
一般的な説明は「ハルシネーション(幻覚)」だ——あまりに使われすぎて、診断的な価値を失ってしまった言葉だ。だが、この事件で実際に何が起きたのか——Mata v. Avianca——それはもっと具体的で、もっと痛烈だ。モデルは、乗客の負傷に対する航空会社の責任に関する判例を探すよう求められた。データベースを検索したわけではない。そもそもデータベースを持っていない。統計的に次に来る可能性が高い単語の並びを予測しただけだ。
「Varghese」はもっともらしい原告名だ。「China Southern Airlines」はもっともらしい被告名だ。「2017 WL 3245891」のような事件番号は、実在する引用の構文パターンに従っている。モデルはこれらの断片を、詩やマーケティングメールを組み立てるのと同じやり方で組み立てた——いわゆるパープレキシティと呼ばれるものを最小化することによって。それは本質的に、モデルが自身の出力にどれだけ「驚く」かを測る尺度だ。驚きが少なければ流暢なテキストになる。流暢なテキストは、真実のテキストと同じではない。
モデルは、パープレキシティ——次の単語にどれだけ驚くか——を最小化するように訓練されている。出所(プロベナンス)——その単語が何か実在するものに遡れるかどうか——を最適化するようには訓練されていない。
これが核心的な緊張関係だ。LLMが最適化するのは次のものだ——一貫性。法律が要求するのは——出所(プロベナンス)だ。これらは根本的に異なる目的であり、どれだけプロンプトエンジニアリングを重ねてもこの溝は埋まらない。GPT-4に「あなたは慎重な弁護士だ。実在する判例だけを引用しなさい」と伝えることはできる。モデルはうなずいて従う——だが、あなたが必要とする判例が訓練データに含まれていない、まさにその瞬間まではだ。そこでモデルは、それらしく聞こえるものをでっち上げる。なぜなら、それらしく聞こえることこそが、文字どおりモデルが最適化されている目標だからだ。
スタンフォードの研究者たちは、これを厳密に検証した。汎用チャットボットは、インターネットへのアクセスや基本的な検索機能を持つものであっても、次の割合でハルシネーションを起こした——58%から82%——複雑な法律クエリに対してだ。特殊な例外ではない。ありふれた法律リサーチの質問においてである。
ラッパーの罠
その後——Mataの一件を機に、私は市場に出回っているリーガルAIツールを目録化し始めた。そのほとんどは、業界が丁寧に「ラッパー」と呼ぶもの——OpenAIやAnthropicのAPIの上に薄くかぶせられたユーザーインターフェースだった。「あなたは有能なリーガルアシスタントです」というシステムプロンプト。せいぜいPDFアップロード機能。せいぜい少しましなフォント。
私は、見込み客——中堅法律事務所のゼネラルカウンセル——と電話で話したことがある。彼女は、こうしたツールの一つを評価していたと語った。「速いんです」と彼女は言った。「でも先週、それは反対意見を、まるで多数意見の判示であるかのように引用したんです。うちのアソシエイトは、危うくそれを提出するところでした。」彼女は一呼吸置いた。「怖いのは、その判例は実在したということです。判示だけが……間違っていた。」
これこそが、法律のハルシネーションについて私を夜も眠れなくさせる点だ。Mataが衝撃的だったのは、判例が完全に捏造されていたからだ。しかし、もっと微妙な誤り——実在する判例だが判示が誤っている、有効な制定法だがすでに廃止されている、拘束力のある先例だが管轄が誤っている——のほうが見つけにくく、おそらくより危険だ。偽の判例は、最初の検証ステップで警告が出る。だが、支持していない命題のために引用された実在の判例は?それは複数回のレビューを生き延びかねない。
ラッパー方式ではこれを解決できない。データ層を自ら所有していないからだ。どの判例が存在するのかを知らない。どれが判例変更されたのかを知らない。第2巡回区の判決が第9巡回区の裁判所を拘束しないことを理解していない。それは、確率エンジンに接続された、しゃれたテキストボックスにすぎない。
そして、経済的な現実は過酷だ。ラッパー市場の分析によれば、一部はすぐに収益に到達するものの、大多数は防御可能な技術を何ら持たないために失敗する。基盤モデルが進化するにつれて、ラッパーを有用にしていたすべての機能——要約、ドラフト作成、Q&A——は、ベースモデルに吸収されていく。あなたは借地の上に建物を建てているのであり、その地主はOpenAIだ。
AIに法律の地図を与えると何が起こるのか?
ここから、私のチームの執念が始まる。
ハルシネーションに対する標準的な対処法は、検索拡張生成——RAG(Retrieval-Augmented Generation)だ。モデルの記憶に頼る代わりに、データベースから関連する文書を取得し、それらをコンテキストとして与える。これは本物の改善だ。しかし法律にとっては、それでは不十分であり、私たちを何週間も悩ませたある具体的な例を用いて、その理由を説明したい。
私たちは、標準的なベクトルRAGパイプラインを、ある1990年の環境規制が2023年の最高裁判決のあとも依然として執行可能かどうか、という質問でテストしていた。ベクトルRAGは、いつもどおりのことをした。すなわち、クエリと意味的に類似したテキストの断片を見つけたのだ。それはその規制を返した。最高裁の意見を返した。その両方を論じた法律評論(ロー・レビュー)論文を返した。
LLMはそれらを縫い合わせて、自信に満ちた、よく書けた回答を作り上げた——だが、その回答は完全に間違っていた。LLMは、その法律評論論文——説得力はあるが拘束力のない学術的な論評——を、まるで最高裁の判示と同じ重みを持つかのように扱った。さらに悪いことに、その規制が実質的に無効化されていたことを見落とした。なぜなら、その規制を無効化した判決へと結びつける典拠の連鎖が、ベクトル検索では取得されなかった中間上訴審の判例を経由していたからだ。そのつながりは意味的なものではなかった。構造的なものだったのだ。
私は、リードエンジニアがこのデバッグの途中で私のほうを振り向いて、こう言ったのを覚えている——「問題は検索(リトリーバル)ではありません。問題は、ベクトルが関係性を理解しないということです。」
彼女は正しかった。そして、それこそが次のものの背後にある洞察だ——GraphRAG——グラフベースの検索拡張生成(Graph-based Retrieval-Augmented Generation)だ。
法律文書をベクトル空間内の孤立した点として保存する代わりに、私たちはそれらを次のものへとマッピングする——ナレッジグラフ(Knowledge Graph)——すなわち、あらゆる制定法、判例、規制、そして法理がノードとなり、それらの間の関係——引用する、判例変更する、区別する、解釈する、是認する——これらが明示的でラベル付けされたエッジになる。私は、その完全なアーキテクチャについて、次で書いた——私たちの研究のインタラクティブ版。
ベクトルRAGはこう問う——「このクエリに似たテキストを見つけよ」。GraphRAGはこう問う——「制定法を見つけ、『解釈する』エッジをたどって判例法を見つけ、それから『判例変更する』エッジをたどって、それがまだ有効であることを確認せよ」。
これは微妙な違いではない。これは、図書館を雰囲気で探すことと、カード目録、引用索引、そしてシェパード・レポートを同時に使って探すこととの違いだ。
AIが引用をでっち上げるのを、どうやって止めるのか?
ここが、私たちが正しく仕上げるのに最も時間を要した部分であり、私が最も誇りに思っている部分でもある。
ナレッジグラフを持つことは必要だが、十分ではない。グラフは構造を与えてくれる。しかしLLMは依然としてトークンを一つずつ生成しており、どの時点でもグラフから逸れて、でっち上げを始めかねない。私たちに必要だったのは、単に促すだけの仕組みではなかった——モデルに実在する判例を引用するよう、だ。それは、物理的に防ぐ——モデルが偽の判例を引用することを、だ。
私たちはこれを次のように呼んでいる——グラフ制約付きデコード(Graph-Constrained Decoding)——そして、その中核となる仕組みが、KG-Trieと呼ばれるものだ。
平易な言葉で、その仕組みを説明しよう。私たちは、ナレッジグラフ内のあらゆる有効なエンティティ——あらゆる判例名、あらゆる判例集の引用、あらゆる事件番号——を取り出し、それらの識別子から接頭辞木(Trie、トライ木)を構築する。LLMがテキストを生成していて、まさに引用を出力しようとする地点に達すると、制約メカニズムが起動する。そしてこう確認する——Trieによれば、有効な次のトークンは何か?
もしモデルが「Mata v. A」まで生成していれば——Trieは、その文字列で始まる有効な判例名を完成させるトークンを許可する。「Avianca」は有効だ。それ以外のすべては、確率が負の無限大に設定される。ブロックされるのだ。
もしモデルが「Varghese v. Chi」を生成しようとすれば——Trieは有効な継続候補を見つけられない。生成は停止される。モデルは後戻りを強いられ、実在する引用を見つけるか、あるいは「該当する先例なし」といったものを出力するかのどちらかになる。
AIは架空の判例を思い描くことができない。なぜなら、検証済みデータベースに存在しない判例のトークン列を、物理的に出力できないからだ。
これは——構造的な保証——であって、確率的な保証ではない。私たちは「モデルがハルシネーションを起こす可能性が95%低くなる」と言っているのではない。捏造への経路が閉ざされている、と言っているのだ。偽の引用のためのトークン列は、文字どおり生成され得ない。
さて、これが何をして、何をしないのかについて、正確に述べておきたい。これが防ぐのは——捏造——存在しない判例をでっち上げることだ。防がないのは——誤った解釈——実在する判例を引用しながら、そこから誤った結論を導き出すことだ。それは推論の誤りであり、依然として人間によるレビューを必要とする。しかし、捏造を排除できることの意義は絶大だ。それは、最も破滅的な失敗モード——すなわちMataのシナリオを完全に選択肢から外してくれるのだ。
開発の初期、私たちが初めてのエンドツーエンドのテストを実行した、ある夜のことだ。私たちは、次の事件で偽の引用を生み出したのとまったく同じクエリを、システムに与えた——Mata。制約付きのシステムは「Varghese」を生成しようとして、Trieの壁にぶつかり、後戻りし、有効な引用の連鎖を伴う実在の判例を返した。私のエンジニアは、午前1時47分に、私たちのグループチャットにスクリーンショットを送った。誰も言葉では返信しなかった。ただ、炎の絵文字がずらりと並んだだけだった。
なぜラッパーにはこれができないのか?
人々は絶えず私にこれを尋ねるが、その答えは商業的なものではなく、アーキテクチャ上のものだ。
グラフ制約付きデコードには、生成中にリアルタイムでモデルのトークン確率——そのロジット——を操作することが必要だ。デコードのレベルで推論エンジンにアクセスできなければならない。GPT-4のような標準的な商用APIは、これを公開していない。プロンプトを送って応答を受け取ることはできる。しかし、生成プロセスをトークンの途中で割り込んで制約を注入することはできない。
だからこそ私たちは、オープンウェイトのモデル——Llama、Mistral——の上に構築するか、あるいはカスタムのデコードループを許容するエンタープライズ向けエンドポイントを通じてデプロイする。私たちはモデルを自らホストする。推論パイプラインを自ら制御する。生成される一つひとつのトークンの確率分布に、KG-Trieの制約を直接注入するのだ。
ラッパーは、その定義からして、これができない。他人のAPIを呼び出しているだけだからだ。それは操縦士ではなく、乗客にすぎない。
誰も語らない、最も困難な部分
制約メカニズムを構築することは、知的に満足のいく作業だった。だが、その土台となるナレッジグラフを構築することは、骨の折れる苦役だった。
法律文書は、データエンジニアを泣かせるほど雑然としている。一つの判例が、「Mata v. Avianca」「Mata」「678 F. Supp. 3d 443」「the Avianca case(あのアビアンカ事件)」、あるいは単に「Id.」——「今しがた言及した判例」を意味する2文字の略語——として参照されることがある。それらすべてが、グラフ内の単一の正規ノードへと解決されなければならない。一つでも取りこぼせば、引用ネットワークに穴が空くことになる。
私たちは何か月もかけて、エンティティ解決(Entity Resolution)のパイプラインを構築した。それは、重複排除(「Smith v. Jones, 123 F.3d 456」と「Smith, 123 F.3d at 456」は同じ判例だ)、曖昧性解消(「Smith v. Jones (1995)」対「Smith v. Jones (2002)」——同名の別々の判例だ)、そして、スライディングウィンドウによる文脈解析を用いて「Id.」の参照を解決するという、あの独特の地獄を扱うものだ。
そして、ネガティブ・トリートメント(否定的取り扱い)——「レッドフラグ」システムがある。判例変更された判例を有効な典拠として扱う法律ナレッジグラフは、役に立たないどころか有害だ。私たちは、シテーター(引用評価)のシグナル——「overruled(判例変更)」「abrogated(廃棄)」「superseded(置き換え)」といった表現——を取り込み、それらをグラフ内のブロッキング・エッジとしてエンコードする。システムがある経路をたどってOVERRULESエッジにぶつかると、その経路は拘束力のある典拠としては無効化される。もし誰かが次の判例について尋ねたら——Roe v. Wade——生殖に関する権利について尋ねたら、グラフは即座に、次の判例からのOVERRULESエッジを浮かび上がらせる——Dobbs v. Jackson。ベクトル検索なら、依然として嬉々として次の判例を引用しかねない——Roe——なぜなら、それを支持する歴史的なテキストの圧倒的な量が、類似度スコアを支配してしまうからだ。
グラフスキーマ、エンティティ解決パイプライン、そして制約アーキテクチャの完全な技術的解説については、次を参照してほしい——私たちの研究論文。
これは、法律事務所にとって実際に何を意味するのか?
私は、あるマネージング・パートナーと会話したことがある。彼はこう率直に言った——「ナレッジグラフなんてどうでもいい。私が気にかけているのは、うちのアソシエイトが裁判官の前で私に恥をかかせるかどうかだ。」
もっともだ。では、翻訳して伝えよう。
次の一件が招いた代償は——Mata v. Avianca——それは5,000ドルではなかった。それは、公然たる屈辱であり、依頼者への通知義務であり、弁護過誤の責任リスクであり、そして、この事務所は自らの仕事を検証しないのだという、あらゆる見込み依頼者に向けたシグナルだった。大規模な事務所にとって、たった一件のハルシネーションを含む提出書類は、存続を脅かす評判上の事件なのだ。
引用強制型GraphRAGは、次のものとして機能する——捏造に対する保険。ラッパー方式は、低い初期コストと、無制限の責任リスクを提供する。私たちの方式は、データ層と制約アーキテクチャへの本物の投資を必要とするが、引用捏造のリスクをゼロにまで引き下げる。
あまり目立たないが、効率性の観点からの論拠もある。現在、事務所がリサーチにAIを使えば、アソシエイトは一つひとつの引用をすべて検証しなければならない。その検証ステップは、しばしばリサーチそのものよりも時間がかかり、本末転倒になってしまう。GraphRAGのベンチマークは、次のことを示している——30〜35%の改善——標準的なRAGに対する、マルチホップ推論タスクにおける改善だ。それは、訴訟において実際に重要となる、複雑で点と点をつなぐ類いのリサーチである。さらに重要なのは、引用が構造的に有効であることを保証されているため、人間の役割が「ファクトチェッカー」から「戦略レビュアー」へと移る点だ。判例が存在することを確認するために3時間を費やすのではない。その時間を、その主張が説得力を持つかどうかに費やすのだ。
すべての引用が構造的に検証されると、弁護士の仕事は、AIのファクトチェックから戦略を考えることへと移る。真のレバレッジがあるのは、まさにそこだ。
そして、コンプライアンスにとって重要となる透明性の側面がある。ラッパーは、なぜある判例を選んだのかを説明できない。GraphRAGシステムは、正確なたどり方の経路を示すことができる——「私が判例Aを選んだのは、それが制定法Bを解釈しており、かつ裁判所Cによって是認されたからです。裁判所Cは、あなたの管轄において拘束力を持ちます」。そうした監査証跡は、あれば嬉しいという程度のものではない——それは、規制上の要請になりつつある。
これは次にどこへ向かうのか?
業界は、チャットボットからエージェント——単に質問に答えるだけでなく、複数ステップのタスクを計画し実行するAIシステム——へと移行しつつある。却下申立ての起案を求められたリーガルエージェントは、適用される基準をリサーチし、支持する判例法を見つけ、それらの判例がなお有効な法(グッド・ロー)であることを検証し、手続要件を確認し、そして主張を組み立てる必要がある。
ベクトル検索の上で動くエージェントには、地図がない。あるのは、山積みの文書と、当てずっぽうの推測だけだ。ナレッジグラフの上で動くエージェントには、たどることのできる明示的な構造がある——制定法 → 解釈する判例 → 手続規則 → 管轄固有の要件、というように。グラフこそが——まさに——エージェントの計画層なのだ。
だからこそ私は、いまグラフ基盤に投資することが、のちに複利的なリターンを生むと信じている。ラッパーがあとに残すのは、チャットログだ。ナレッジグラフがあとに残すのは、構造化され、成長し続け、ますます価値を増していく法的典拠の地図だ——判例が一つ追加されるたび、関係が一つエンコードされるたび、否定的取り扱いのシグナルが一つ取り込まれるたびに、それはより有用になっていく。
率直な反論
人々は二つの面から反論してくる。その両方に、私は正面から答えたい。
第一に——「これは、余計な手間を加えただけのWestlawではないのか?」。違う。Westlawは、人間のための検索エンジンだ。それは、弁護士が読んで解釈する文書を返す。私たちが構築するのは、AIのための制約アーキテクチャ——AIが何を言えて何を言えないかを統べるシステムだ。Westlawは弁護士が法律を見つけるのを助ける。GraphRAGはAIが法律をでっち上げるのを防ぐ。両者は競合するものではなく、補完し合うものだ。
第二に——「ハルシネーションをやめさせるために、モデルをファインチューニングすればいいだけではないのか?」。私たちは試した。取り組みの初期、私たちは検証済みの法律データセットでファインチューニングする実験を行った。それはハルシネーションの発生率を下げた。だが、なくしはしなかった。ファインチューニングされたモデルも、依然として確率エンジンだ。それは——より優れた——確率エンジンだ。だが、法律の引用において「より優れた」とは「間違える頻度がより低い」ということを意味し、「間違える頻度がより低い」は、いかなる裁判所も受け入れない基準だ。捏造をゼロにすることを保証する唯一の方法は、捏造を構造的に不可能にすることであり、それは、単に入力データを改善するのではなく、出力空間を制約することを意味する。
「十分によい」の終わり
私が何度も立ち返る点はこうだ。法曹という職業は、単純な前提の上に築かれている——典拠を引用するとき、その典拠は実在しなければならない、と。おそらく実在する、ではない。たいてい実在する、でもない。実在するのだ。
その後——Mata——から2年間、裁判所は制裁を強化し続け、AIの開示に関する常設命令(スタンディング・オーダー)を発し、「AIがやったことだ」は抗弁にならないと明確にしてきた。この職業は一線を引きつつある——AIを使うなら、その出力は検証されなければならない、と。そして、その出力を検証するのに手作業でやるよりも時間がかかるのなら、そのAIはツールではない——それは責任リスクだ。
ラッパーの時代は、間違った問題を解決した。それはリーガルリサーチをより速くした。だが、本当に必要だったのは、リーガルリサーチを信頼できるものにすることだった。信頼を欠いたスピードは、単なる効率的な弁護過誤にすぎない。
私たちがVeriprajnaで構築しているのは、たまたま多少の法律を知っているチャットボットではない。それは、あらゆる引用がナレッジグラフを通じた検証済みのたどり方であり、あらゆる関係が明示的で監査可能であり、生成モデルが物理的にフィクションへ踏み込むことを防がれる、制約付きの推論システムだ。
拘束力のある先例という概念を生み出したこの職業は、それを真に尊重するAIにこそふさわしい。