こんにちは、株式会社LegalOn Technologiesでソフトウェアエンジニアをしている高橋です。

LegalOn Technologiesでは、日本の法務分野における自然言語処理（NLP）のための包括的なベンチマークデータセット、LegalRikaiを作成しています。LegalRikaiは日本法に特化したさまざまなタスクを含むベンチマークデータセットで、法務NLPベンチマークデータセットの現状における重要なギャップを埋めることを目的としています。

LegalRikai作成の背景と目的

近年、大規模言語モデル（LLM）の登場により、リーガルテックを含む様々な分野が大きく前進しました。しかし、これらのモデルは主に英語の一般知識を評価するために設計されたベンチマークデータセットを用いて評価されることが多く、英語で高い性能を発揮すれば、他の言語や分野でも高い能力を発揮できるという前提につながっています。この前提は、文脈特有のニュアンスや専門用語が重要な役割を果たす法律分野では特に問題となる可能性があります。

日本の法律の文脈においては、このギャップはさらに顕著です。LawBench、LegalBench、LexGLUEなどのベンチマークデータセットは、中国、米国、EUなどの法域における研究を進歩させてきましたが、日本の法的な文書に合わせたベンチマークデータセットは存在しません。この標準化されたリソースの欠如は、日本語の法的文脈におけるモデルの能力を正確に測定することを妨げ、この領域における学術研究の発展にも影響を与えています。

そこで私たちは、LegalRikaiを通じて、LLMが特に日本法に基づいて法的なタスクを解決する能力をどれだけ持っているかをよりよく理解できるようにする基盤を作り、法務NLP分野の学術研究の発展に寄与したいと考えています。

LegalRikai作成のもう一つの重要な動機は、より良い法務タスク解決能力を持つLLMを、私たちのサービスの基盤となるモデルとして採用したいという点にあります。これは、私たちが目指す高品質なリーガルテックサービス提供を実現するための重要な要素です。法務関連のタスクは、高い精度と信頼性が求められるため、LLMの性能向上は不可欠です。LegalRikaiを通じてLLMの評価・改善を促進することで、より効率的で正確な法務サービスの提供を目指しています。

弊社が今年10月、500名の法務担当者を対象に実施した法務業務における生成AIの活用に関する調査では、生成AIの利用意向が6割超と高いものの、回答者の半数以上がハルシネーション（AIが事実と異なる内容を生成すること）に対する懸念を持っていることが分かりました。

法務関連の誤りは企業やビジネスに対して重大な結果を招く可能性があるため、LLMには高い精度が求められます。LLMのハルシネーションの原因の一つとして、事前学習コーパスにおける法務分野の知識不足が考えられます¹。判例、契約書などの専門的な法務文書は、一般的にLLMの学習データに十分に含まれていません。LLMの知識不足を補う方法として、Retrieval-Augmented Generation (RAG) がありますが、検索結果のノイズや不正確な情報の影響を受けやすいという課題があります²。もしLLM自身が十分な法的知識と法的推論能力を持っていれば、RAGのような外部知識に頼る方法よりも、より高品質なサービスを提供できると考えています。LegalRikaiは、そのようなLLMを選定するための評価基盤となります。

LegalRikaiに含まれるタスク

LegalRikaiは、日本語の契約書処理の特定の側面に対応する2つのタスクで構成されています。（2025年2月時点）

1. 条文分類: 契約書内の特定の種類の条文³を識別し、分類するタスク。
2. 条文修正: 契約書内の潜在的な問題に関するアラートに従った条文の修正を行うタスク。

以下では、これらのタスクの詳細と予備的な実験結果を紹介します。

条文分類タスクの詳細と実験結果

タスクの詳細

条文分類タスクでは、モデルはあらかじめ定義された法的条項カテゴリーのセットに基づいて条文の主たるテーマを識別し、ラベル付けしなければなりません。以下の例では、工事が完成した時の検査について書かれた条文に対し、「工事完了時の検査」というラベルを付与します⁴。

【入力】
第３条（完成後の検査）
乙は、甲に対して、本件工事の完成後速やかにこれを甲に報告し、甲の検査を受けるものとする。

【出力】
- 工事完了時の検査

条文分類ではラベルを複数つけなければならない場合もあります。言い換えれば、条文分類はマルチラベルテキスト分類タスクです。以下の例では、合意のない再委託と地位の譲渡を禁止する条文に対し、「再委託」と「地位の譲渡禁止」というラベルを付与します。

【入力】
第１２条（再委託・譲渡の禁止）
受託者は、委託者の書面による事前の承諾なく、本契約について次の各号に定める行為をしてはならない。
① 本件業務の全部または一部を第三者に再委託すること
② 第三者に対して本契約上の権利を譲渡し、または義務を承継させること

【出力】
- 再委託
- 地位の譲渡禁止

条文分類のデータセットは契約書の自動レビューサービスのためのデータセットから転用して構築されました。インスタンス（条文）数は評価セットで12,876件、開発セットで46,477件です。開発セットはfew-shot examplesまたはモデルの微調整のために訓練用と評価用に分割されることを想定しています。全体でユニークなラベル数は492個で、マルチラベルテキスト分類タスクとしては十分に挑戦的なタスクです。

生成方法

LLMは条文を入力に取り、約500個のラベルの中からその条文として適切なラベルを複数出力します。LLMへのプロンプトでは出力が期待される約500個のラベルを列挙し、出力に関する要件を説明します。以下が実際のプロンプトのJinjaテンプレートです。

# Clause Detection Task

## Instructions

1. **Analyze the Legal Article:**
   - Carefully read and analyze the provided legal article.
   - Identify the types of clauses present in the article based on the provided list of "## Valid Legal Clauses" list.
2. **Generating the Output:**
   - Format your output according to the "## Expected Output Format".
   - List each identified clause type on a separate line under the heading **Legal Clauses:**.
3. **Handling No Valid Clauses:**
   - If no valid clause types from the "## Valid Legal Clauses" list are found in the article, output: "No valid legal clauses found."
4. **Avoid Duplicates:**
   - If valid clause types are found, include each clause type only once, even if it appears multiple times in the article.

## Expected Output Format

**Legal Clauses:**
- Clause1
- Clause2
- ...

If no clauses match, output: "No valid legal clauses found."

## Valid Legal Clauses

These are the only clauses you should use when identifying clauses in the legal article:

{% for label in candidate_labels -%}
- {{ label }}
{% endfor %}

## Legal Article to Analyze

Here is the legal article you need to analyze:

{{ text }}

このテンプレートの変数は candidate_labels と text です。 candidate_labels には全てのラベルが文字列のリストとして格納され⁵、 text には入力としての条文が格納されています。

評価方法

評価方法は通常のマルチラベル分類のものと同等です。LLMはラベルを選択するのではなく生成しますが、正解と判定されるためにはラベルは正解ラベルと完全一致していなければなりません。

実験結果

以下の表は主要なLLMのゼロショット設定での評価結果です。「ハルシネーション数」は、予測されたラベルの中で、事前定義されたラベルに含まれなかったものをカウントしています。

Model	F1	適合率	再現率	ハルシネーション数
Gemini 1.5 Flash 002	25.4	21.2	48.6	7373
GPT-4o mini	21.5	18.6	36.1	7024
Claude 3.5 Haiku	33.8	31.2	53.2	4298
Gemini 1.5 Pro	33.1	29.9	54.0	3104
GPT-4o	30.0	27.0	44.3	2395
Claude 3.5 Sonnet	40.9	36.3	61.4	284

この表から以下の点がわかります。

• どのモデルも、適合率よりも再現率が高い傾向にあります。これは、モデルは正解のラベルを正しく予測できているが、一方で誤ったラベルを出力し過ぎてしまう傾向があると言えます。例えば、以下のような条文を考えます：

  第11条 （完全合意）
  本契約は、本契約に関する当事者間の完全なる合意を構成するものであり、本株式譲渡に関して当事者の間で本契約締結前になされた一切の合意、約定その他の約束（書面によると口頭によるとを問わない。）は、本契約の締結をもって失効する。

  この条文の正解ラベルは「完全合意」ですが、GPT-4oとGemini 1.5 Proの出力はそれぞれ次の通りでした：

  • GPT-4o：「完全合意」「株式の譲渡」
  • Gemini-1.5-pro：「契約書の保管」「完全合意」「株式の譲渡」

  どちらも正解ラベルである「完全合意」を正しく出力できていますが、GPT-4oは「株式の譲渡」、Gemini-1.5-proは「契約書の保管」と「株式の譲渡」という余計なラベルも出力しています⁶。

• 同じモデルファミリー同士で比較すると、よりパラメーター数が多いモデルの方がより予測性能が高いことが分かります。Gemini 1.5 ProとFlashとのF1スコアの比較で7.7、GPT-4oとminiとの比較で8.5、Claude 3.5 SonnetとHaikuの比較で7.1ポイントの差があります。ハルシネーションの数も一貫して改善されています。パラメーター数が多いほど複雑なインストラクションに従う能力が高いという定説に基づけば、この結果には納得できます。

• Claude 3.5 Sonnetのハルシネーション数は他のモデルに比べて際立って少ないです。つまり、Claude 3.5 Sonnetは他のモデルに比べてプロンプトに列挙されていないラベルを勝手に生成することに抑制的である傾向を示しています。
• 最も予測精度が高いモデルはClaude 3.5 Sonnetで、F1スコアで40.9です。約500種類のマルチラベル分類かつゼロショット設定であることを鑑みるとそれほど悪いスコアではないです。一方で社内では似たようなより困難な分類タスクで伝統的な機械学習モデルを使ってより良い予測精度を達成しているので、このタスクにおけるモデルの予測をLLMで置き換えるには依然として様々な追加の工夫が必要でしょう。

条文修正タスクの詳細と実験結果

条文修正タスクでは、モデルは条文とそれに含まれる潜在的な問題に関するアラートと修正のガイダンスが与えられたら、そのアラートとガイダンスに従って条文を修正しなければなりません。以下の例では、「候補者の採用を決定したら人材紹介会社に速やかに通知しなければならない」旨の条文に対し、「（採用の決定を）書面で」通知する旨が定められていないというアラートが発せられ、「書面などにより」という記述を追加することをガイダンスとして提示しています。

【入力】
- 条文：委託者は、受託者に紹介された候補者を選考し、採用を決定した場合には、受託者に対し、速やかに通知する。
- アラート：候補者を採用したときに、「書面で」通知する旨が、定められていますか？
- ガイダンス：必要に応じて、「書面などにより」通知しなければならない旨の追加を検討

【出力】
委託者は、受託者に紹介された候補者を選考し、採用を決定した場合には、受託者に対し、書面交付等の方法により速やかに通知する。

この出力例では、「書面交付等の方法により」速やかに通知する旨が追加されています。

条文修正タスクでは弊社のAI契約書レビューシステムをベンチマークタスクに転用しています。このタスクにおけるアラートは実際にはAI契約書レビューシステムの予測です。予測されたアラートとそれに対応するガイダンスに基づいて条文を修正することは法務の専門家の仕事ですが、それをLLMがどれほど精緻に実行できるかを評価・分析することを狙いとしています。

正解データは弊社の法務開発部門の専門家によって人手で作成されました。インスタンス数はテストセットで378件、開発セットで8件です。開発セットはfew-shot examplesで利用されることを想定しています。

生成方法

LLMは条文とアラートとガイダンスを入力に取り、適切な修正を加えた条文を出力します。以下が実際のプロンプトのJinjaテンプレートです。

# Clause Revision Task

## Instructions:
1. Review the given clause in the "## Original Clause" section below based on the AI Alert ("## AI Alert") provided.
2. Ensure that the issue highlighted by the AI Alert is adequately addressed. If the original clause already addresses the AI Alert, no changes are necessary.
3. Use the provided guidelines ("## Guidelines") as a reference to help you make revisions, but only if they are relevant and necessary for addressing the AI Alert.
4. If changes are made based on the AI Alert, ensure that the revised clause is:
   - Grammatically correct
   - Natural and easy to understand
   - Coherent and logically consistent
5. Respond with the revised clause directly, without explanation or any extra text, even if no changes have been made.

{% if n_demonstrations > 0 %}

## Examples (for reference):

{% for example in demonstrations %}
### Example {{ loop.index }}:

**AI Alert:**  
{{ example.ai_alert }}

**Guidelines:**  
{{ example.guidelines }}

**Original Clause:**
{{ example.text }}

**Expected Output:**
{{ example.reference_revision }}

{% endfor %}

{% endif %}

## AI Alert:
{{ai_alert}}

## Guidelines:
{{guidelines}}

## Original Clause:
{{text}}

このプロンプトの基本的な入力は条文text、アラートai_alert、ガイドラインguidelines です。few-shot examples (demonstrations) が利用可能なときにだけ、それらをプロンプトに含めます。

評価方法

このタスクの評価では、人間が書いた参照修正とLLMが生成した修正との整合性を、観点ごとにLLMを使って測定します⁷。また、その形式が人間による参照と正確に一致していない場合でも、LLMが生成した修正がアラートに対応しているかどうかについても評価します。具体的には以下の観点を用います。

• アラートへの対応: LLMが生成した条文がアラートに効果的に対応し、弁護士が作成した参照条文と一致しているか。これには、変更が必要な箇所を特定し、適切に変更を加えること、または変更が必要ないことを認識することが含まれる。
• 意味の保持: LLMが作成した条文が、弁護士が作成した参照条文で表現された意図および法的ニュアンスを保持しているか。
• 文法: LLMが作成した条文が、弁護士が作成した参照条文と文法上の正確性で一致しているか。
• 自然さ: LLMが作成した条文が、弁護士が作成した参照条文と同等に自然な文章であるか⁸。
• 論理の流れ: LLMが作成した条文が、弁護士が作成した参照条文の論理的な展開と順序を反映し、一貫した流れを維持しているか。

評価にはGPT-4oを使用しました。LLMが生成した条文を分析する方法をステップバイステップで詳細に指示することで評価指標の安定性が向上しました。プロンプトは非常に長くなったためここでは割愛します。

実験結果

以下の表は主要なLLMのゼロショット設定での評価結果です。

Model	アラートへの対応	意味の保持	文法	自然さ	論理の流れ
Gemini 1.5 Flash 001	46.20	43.60	92.20	83.30	49.30
GPT-4o mini	56.00	49.90	93.50	78.70	54.60
Claude 3.5 Haiku	57.80	50.10	91.90	83.00	60.90
Gemini 1.5 Pro	56.50	46.10	91.60	78.50	54.50
GPT-4o	61.70	53.90	90.00	81.70	62.50
Claude 3.5 Sonnet	65.30	57.60	90.90	81.40	61.90
Oracle	99.10	98.50	99.80	99.10	98.30

以下の表は8ショット設定での評価結果です。つまり、LLMは条文を修正するときに、8つの修正例を提示されます。

Model	アラートへの対応	意味の保持	文法	自然さ	論理の流れ
Gemini 1.5 Flash 001	59.20	48.70	89.30	81.00	57.40
GPT-4o mini	59.20	56.40	89.90	81.80	61.30
Claude 3.5 Haiku	62.60	47.70	92.10	80.00	60.80
Gemini 1.5 Pro	61.20	50.20	88.30	81.60	59.70
GPT-4o	68.90	59.70	92.40	85.30	67.20
Claude 3.5 Sonnet	70.90	61.70	92.20	83.80	70.70
Oracle	99.10	98.50	99.80	99.10	98.30

Oracleの行では、LLMが生成した条文として参照条文と全く同じテキストをセットした時の評価指標を示しています。理想的には全ての指標で100を示している必要がありますが、LLMによる評価は完全ではないためこれがある種の上限です。

これらの表から以下の点がわかります。

• 全体として、どのモデルも「文法」と「自然さ」の観点では概ね良好ですが、「アラートへの対応」と「意味の保持」と「論理の流れ」の観点で困難さを示しています。これは、LLMはアラートやガイドラインの指示に従って何かしら流暢な修正をするものの、法務の専門家がするような適切な条文の修正との間にはギャップがあることを示唆します。
• ゼロショットから8ショットに修正例を増加させると、どのモデルもほとんどの観点で性能を改善しています。今回few-shot examplesとして使った条文はどの評価対象の条文においても同じであるため、評価対象の条文と似た条文例を使うなどによってさらに性能を改善できる可能性はあります。
• 条文分類タスクと同様、Claude 3.5ベースのモデルが比較的優れた性能を示しています。条文分類タスクにおけるハルシネーション数のような明確な違いが現れる指標を見出せるかどうかは今後の課題です。

まとめと今後の展望

本稿では、日本の法務分野NLPのための包括的なベンチマークデータセットLegalRikaiの構築について紹介し、その中の2つのタスクについて詳細と予備的な実験結果について説明しました。実験結果は、現時点での最先端のLLMでさえ、法務の専門家が直面するような専門的な法務タスクを解くのに依然として困難さを抱えることを示唆しています。

今後の展望としては、以下の点が挙げられます。

• プロンプトの精緻化: 例えば条文分類タスクでは、LLMはラベルの字面からそのラベルの意図を推論しなければならず、LLMにとってミスリーディングな設定になっています。各ラベルがどのような条文に付与されるべきなのかを説明する文言を追加することで、LLMの法的推論能力がより正確に評価できると考えられます。
• タスクの追加: 本稿ではLegalRikaiで現在構想している2つのタスクについて紹介しました。私たちは更なるタスクの追加を予定しており、例えば「契約書中に潜在的な問題が含まれているかどうかを識別するタスク」や「2つの法的な記述間の含意関係を識別するタスク」などについて検討しています。これらのタスクは、契約書のレビュー、法的アドバイスの生成、法的文書の検索など、幅広い法務アプリケーションに役立つ可能性があります。
• リーダーボードの公開: LegalRikaiの目的の一つは法務NLP分野の学術研究の発展に寄与することです。評価方法をオープンにし、公開されたリーダーボードで様々なLLMを包括的に評価し、評価結果に誰もがアクセスできるようにすることがその目的に叶うと確信しています。リーダーボードは、研究者や開発者がLLMの性能を比較し、改善のためのアイデアを得るための貴重なリソースとなるでしょう。

謝辞

LegalRikaiの構築にあたっては2024年11月まで株式会社LegalOn Technologiesに在籍していたPrideさんが中心的な役割を果たしました。データセットへのアノテーション作業は法務開発の奥村さん、小林さん、轟さんにご協力いただきました。この場を借りて感謝申し上げます。

仲間募集

株式会社LegalOn Technologiesでは、複数のポジションでエンジニアを募集しています。気軽にご応募ください。