はじめに

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

この記事は、前回公開した以下の続編になります。

tech.legalforce.co.jp

今回の記事では、当時まだ公開されていなかったモデルの性能の検証に加えて、実践的なタスクとしてLegalRikaiに新しく追加したレビュー対象条文特定タスクについて紹介します。

LegalRikaiに含まれるタスク

LegalRikaiは、現在日本語の契約書処理の特定の側面に対応する3つのタスクで構成されています。1つ目と2つ目のタスクは以前の記事で紹介したものと同じであり、タスクの説明については前回の記事から引用します。

条文分類: 契約書内の特定の種類の条文を識別し、分類するタスク
条文修正: 契約書内の潜在的な問題に関するアラートに従った条文の修正を行うタスク
レビュー対象条文特定: 契約書のレビュー指摘事項が与えられ、その指摘事項に対応する条文を特定するタスク

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

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

タスクの詳細

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

【入力】

第３条（完成後の検査）

乙は、甲に対して、本件工事の完成後速やかにこれを甲に報告し、甲の検査を受けるものとする。

【出力】

工事完了時の検査

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

【入力】

第１２条（再委託・譲渡の禁止）

受託者は、委託者の書面による事前の承諾なく、本契約について次の各号に定める行為をしてはならない。

① 本件業務の全部または一部を第三者に再委託すること

② 第三者に対して本契約上の権利を譲渡し、または義務を承継させること

【出力】

再委託

地位の譲渡禁止

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

評価方法

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

実験結果

以下の表は主要なLLMのzero-shot設定での評価結果です。「不正ラベル生成数」は、予測されたラベルの中で、事前定義されたラベルに含まれなかったものをカウントしています。

	F1	precision(適合率)	recall(再現率)	不正ラベル生成数
Gemini 1.5 Flash	26.4	23.2	48.8	6997
Gemini 1.5 Pro	33.0	30.0	53.9	2966
Gemini 2.0 Flash	28.0	23.8	46.0	6468
Claude 3.5 Haiku	33.8	31.3	53.1	4459
Claude 3.5 Sonnet	40.5	35.5	62.4	306
Claude 3.7 Sonnet	41.3	34.8	66.0	771
GPT-4o mini	25.5	27.9	35.8	7913
GPT-4o	33.3	34.1	44.6	2178
GPT-4.1	35.6	33.1	54.7	2011
GPT-4.1-mini	33.0	32.9	46.4	1902
GPT-4.1-nano	18.2	27.4	19.7	4473

下記の傾向があり、前回の記事で見られた傾向は今回の検証でも見られました。

全体を通して、適合率よりも再現率が高い傾向にあります。これは、モデルが該当しないラベルを含めて出力する傾向、すなわち網羅性を優先しつつ誤検出も増える傾向があることを示しています。
同じモデルファミリー同士で比較すると、よりパラメーター数が多いモデルの方がより予測性能が高い傾向が見られます。F1で比較すると、Claude 3.5 SonnetとClaude 3.7 Sonnetで0.8ポイント、Gemini 1.5 FlashとGemini 2.0 Flashで1.6ポイント、GPT-4oとGPT 4.1で2.3ポイントの改善が見られました。不正ラベル生成数も一貫して減少しています。
Claudeモデルの不正ラベル生成数は他のモデルに比べて際立って少ない傾向が見られました。また、バージョンが大きいClaude 3.7 SonnetよりもClaude 3.5 Sonnetの方が不正ラベルの生成数が少ないことがわかりました。再現率では3.7の方が3.5より高く、3.5の場合の一件あたりの平均出力ラベルが2.61であり、3.7の場合の一件あたりの平均出力ラベルが2.85でした。3.5から3.7になったことで全体的にラベルの出力数が増えたのだと解釈できます。
推論コストが大きく異なるGPT-4.1とGPT-4.1-miniは大きい性能の差異が見られませんでした。そのため、推論コストやレイテンシが気になる場合はGPT-4.1-miniを使うのも有効な選択肢だと言えます。

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

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

【入力】

条文：委託者は、受託者に紹介された候補者を選考し、採用を決定した場合には、受託者に対し、速やかに通知する。

アラート：候補者を採用したときに、「書面で」通知する旨が、定められていますか？

ガイダンス：必要に応じて、「書面などにより」通知しなければならない旨の追加を検討

【出力】

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

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

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

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

評価方法

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

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

評価には前回と同様にGPT-4oを使用しました。モデルが生成した条文を分析する方法をステップバイステップで詳細に指示することで評価指標の安定性が向上しました。

実験結果

以下の表は主要なLLMのzero-shot設定での評価結果です。

	アラートへの対応	意味の保持	文法	自然さ	論理の流れ
Gemini 1.5 Flash	42.71	35.54	90.19	68.44	41.64
Gemini 1.5 Pro	50.40	40.05	87.00	68.44	48.01
Gemini 2.0 Flash	53.31	42.71	88.06	66.58	51.72
Claude 3.5 Haiku	50.40	39.79	88.06	68.44	41.64
Claude 3.5 Sonnet	59.68	46.15	87.53	70.82	56.76
Claude 3.7 Sonnet	59.68	48.28	87.00	70.82	55.97
GPT-4o mini	46.68	38.46	87.80	63.93	43.24
GPT-4o	51.46	41.64	89.66	69.76	51.72
GPT-4.1	57.03	45.62	87.80	67.90	54.64
GPT-4.1-mini	50.92	42.71	90.19	65.25	45.89
GPT-4.1-nano	23.34	17.77	87.80	54.38	22.81
Oracle	99.47	99.47	99.47	99.73	99.47

以下の表は8-shot設定での評価結果です。つまり、モデルは条文を修正するときに、8つの修正例を提示されます。

	アラートへの対応	意味の保持	文法	自然さ	論理の流れ
Gemini 1.5 Flash	51.72 (+9.01)	40.58 (+5.04)	88.33 (-1.86)	70.03 (+1.59)	49.34 (+7.70)
Gemini 1.5 Pro	54.64 (+4.24)	41.64 (+1.59)	87.53 (+0.53)	67.37 (-1.07)	49.34 (+1.33)
Gemini 2.0 Flash	59.42 (+6.11)	46.15 (+3.44)	87.00 (-1.06)	72.68 (+6.10)	54.38 (+2.66)
Claude 3.5 Haiku	55.17 (+4.77)	42.18 (+2.39)	87.00 (-1.06)	68.17 (-0.27)	52.52 (+10.88)
Claude 3.5 Sonnet	65.25 (+5.57)	52.25 (+6.10)	85.41 (-2.12)	74.01 (+3.19)	63.40 (+6.64)
Claude 3.7 Sonnet	63.93 (+4.25)	50.66 (+2.38)	87.53 (+0.53)	71.88 (+1.06)	61.54 (+5.57)
GPT-4o mini	50.40 (+3.72)	41.11 (+2.65)	87.80 (±0.00)	67.37 (+3.44)	47.21 (+3.97)
GPT-4o	60.48 (+8.02)	48.01 (+6.37)	89.39 (-0.27)	74.54 (+4.78)	58.36 (+6.64)
GPT-4.1	58.89 (+1.86)	47.48 (+1.86)	88.06 (+0.26)	71.09 (+3.19)	56.76 (+2.12)
GPT-4.1-mini	54.64 (+3.72)	42.71 (±0.00)	89.39 (-0.80)	69.76 (+4.51)	51.72 (+5.83)
GPT-4.1-nano	28.38 (+5.04)	19.63 (+1.86)	88.06 (+0.26)	55.17 (+0.79)	27.85 (+5.04)
Oracle	99.47	99.47	99.47	99.73	99.47

Oracleの行では、モデルが生成した条文として参照条文と全く同じテキストをセットした時の評価指標を示しています。理想的には全ての指標で100を示している必要がありますが、LLMによる評価は完全ではないため、これがある種の上限です。8-shot設定の()内の値はzero-shot設定とのスコア差分です。

下記の傾向があり、前回の記事で見られた傾向は今回の検証でも見られました。

前回と比較して、スコアの低下が見られました。これは、評価に使ったGPT-4oの内部的な性能の変化によるものだと考えられます。
前回の検証と同様に、全体としてどのモデルも「文法」と「自然さ」の観点では概ね良好であり、「アラートへの対応」と「意味の保持」と「論理の流れ」の観点に課題があります。前回検証したモデルの中では、「アラートへの対応」が最も優れていたのは65.25ポイント、「自然さ」が最も優れていたのは74.54ポイント、「論理の流れ」が最も優れていたのは63.40ポイントでした。一方で、今回新たに検証したモデルの中では「アラートへの対応」が最も優れていたのは63.93ポイント、「自然さ」が最も優れていたのは72.68ポイント、「論理の流れ」が最も優れていたのは61.54ポイントであり、改善が見られませんでした。依然として、このタスクはLLMにとって難しいタスクであるようです。
few-shotの導入により、特に「意味の保持」「論理の流れ」など複雑な解釈を伴う観点で性能が顕著に向上しています。これはLLMが具体的な例から推論パターンを学習できたことを示唆しています。

レビュー対象条文特定タスクの詳細と実験結果

レビュー対象条文特定タスクでは、契約書とそれに含まれている可能性があるレビュー事項が与えられたら、そのレビュー事項について言及している条文を特定しなければなりません。

以下の例では、「受託者に提供した資料について、受託者の返還義務についての文言が記載されているか」というレビュー事項についてそれに言及している条文を特定します。

【入力】レビュー事項: 受託者に提供した資料について、受託者の返還義務についての文言が記載されているか

契約書:

第1条（目的）

委託者は、受託者に対し、委託業務として別紙業務仕様書に定める内容の業務（以下「本業務」という）を委託し、受託者はこれを受託する。

第2条（資料および情報の取り扱い）

受託者は、本契約の有効期間中および終了後、委託者から提供を受けたすべての資料、データ、書類、記録媒体その他一切の情報（以下「提供資料等」という）について、委託者の指示があった場合には、遅滞なく返還し、または委託者の指示に従い適切に廃棄するものとする。

第3条（秘密保持）

受託者は、本契約に関連して知り得た委託者の業務上の秘密を第三者に漏洩してはならない。本契約終了後も同様とする。

(以下略)

【出力】

第2条

この出力例では、第2条に「受託者に提供した資料について、受託者の返還義務についての文言が記載されているか」というレビュー事項に関する文言が含まれていることがわかります。

契約書レビューモジュールは、レビューをするべき箇所の特定と、該当箇所の修正案を出す、2つの作業が必要であり、本タスクは前者をタスクとして切り出したものになっています。レビュー対象条文特定タスクと先に紹介した条文修正タスクの2つを見ることで、LLMで契約書レビューモジュールを代替した場合の効果検証をすることができるようになります。このタスクの出力はマルチラベル(ラベル数は0以上)の設定であり、2つ以上の条文を出力するのが正解の場合もあれば、条文を出力しないのが正解の場合もあります。

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

評価方法

評価方法は一般的なマルチラベル分類タスクと同様です。正解ラベルセットに含まれているそれぞれの条番号が出力に含まれている割合をrecall(再現率)とし、出力したラベルセットに含まれているそれぞれの条番号が正解ラベルセットに含まれている割合をprecision(適合率)として、適合率、再現率、F1を計算しました。

実験結果

以下の表は主要なLLMのzero-shot設定での評価結果です。

	F1	precision(適合率)	recall(再現率)
Gemini 1.5 Flash	34.84	67.50	23.48
Gemini 1.5 Pro	36.41	46.31	30.00
Gemini 2.0 Flash	39.11	49.34	32.39
Claude 3.5 Haiku	40.11	51.54	32.83
Claude 3.5 Sonnet	39.34	53.56	31.09
Claude 3.7 Sonnet	40.00	51.72	32.61
GPT-4o mini	30.50	28.00	33.48
GPT-4o	38.84	41.75	36.30
GPT-4.1	42.11	60.91	32.17
GPT-4.1-mini	39.08	47.37	33.26
GPT-4.1-nano	26.84	32.12	23.04

以下の表は10-shot設定での評価結果です。つまり、モデルは推論するときに、10件の例を提示されます。

	F1	precision(適合率)	recall(再現率)
Gemini 1.5 Flash	40.06 (+5.22)	54.92 (-12.58)	31.52 (+8.04)
Gemini 1.5 Pro	42.44 (+6.03)	51.07 (+4.76)	36.30 (+6.30)
Gemini 2.0 Flash	44.07 (+4.96)	55.05 (+5.71)	36.74 (+4.35)
Claude 3.5 Haiku	36.70 (-3.41)	38.83 (-12.71)	34.78 (+1.95)
Claude 3.5 Sonnet	39.44 (+0.10)	56.00 (+2.44)	30.43 (-0.66)
Claude 3.7 Sonnet	43.10 (+3.10)	54.49 (+2.77)	35.65 (+3.04)
GPT-4o mini	35.23 (+4.73)	33.66 (+5.66)	36.96 (+3.48)
GPT-4o	43.09 (+4.25)	50.44 (+8.69)	37.61 (+1.31)
GPT-4.1	47.62 (+5.51)	66.93 (+6.02)	36.96 (+4.79)
GPT-4.1-mini	42.57 (+3.49)	50.60 (+3.23)	36.74 (+3.48)
GPT-4.1-nano	21.93 (-4.91)	24.59 (-7.53)	19.78 (-3.26)

()内の値はzero-shot設定とのスコア差分です。

下記の傾向が見られました。

全体を通して、条文分類タスクとは逆に再現率よりも適合率が高い傾向にあります。つまり、モデルは出力するべき場合でも出力しないケースが多いということを意味しています。評価データ3,200件の中でレビュー事項1種類につき正例は平均10件程度と不均衡なデータセットであるため、モデルが正例を見逃しやすくこのような傾向になったのだと考えられます。
他のタスクと同様に、同じモデルファミリー同士で比較すると、よりパラメーター数が多いモデルの方がより予測性能が高い傾向が見られます。10-shotでのF1についてみると、前回の検証で検証できなかったClaude 3.7 SonnetはClaude 3.5 Sonnetと比較して3.66ポイント改善し、Gemini 2.0 FlashはGemini 1.5 Flashと比較して4.01ポイント改善し、GPT-4.1 はGPT-4oと比較して4.53ポイント改善しています。
他のタスクではClaude Sonnetモデルが最も性能が高い傾向がありますが、このタスクではGPT-4.1が最も高い性能を記録しています。本タスクは、契約書全体の文脈を踏まえて該当条文を特定する必要があるため、従来のタスクとは求められる能力が異なり、その結果としてLLM間の性能傾向にも違いが現れたものと考えられます。

まとめ

本稿では、日本の法務分野NLPのための包括的なベンチマークデータセットLegalRikaiの追加検証について報告しました。実験結果として、前回と比較してLLMの性能は向上していたものの、特に、指示された法的意図の正確な反映（条文修正）や、契約書全体から関連条文を網羅的に見つけ出す能力（レビュー対象条文特定）において、モデルの性能は限定的でした。今後も最新のモデルによる検証やさらなるタスクの追加などのLegalRikaiのアップデートを継続して行っていく予定です。LegalRikaiの継続的なアップデートを通じて、法務分野におけるAIの可能性と限界を明らかにし、NLPならびに法務実務に資する技術の発展に貢献していきます。

謝辞

LegalRikaiの構築にあたっては2024年11月まで株式会社LegalOn Technologiesに在籍していたPrideさんが中心的な役割を果たし、2025年3月まで同社に在籍していた高橋さんにプロジェクトをリードしていただきました。データセットへのアノテーション作業は法務開発の奥村さん、小林さん、轟さん、ブログの校正は小林さん、濱下さん、真鍋さん、楢木さん、後藤さんにご協力いただきました。この場を借りて感謝申し上げます。