Column

「法務文書を外部APIに送れない」問題は、オープンウェイトLLMで突破できるか——COLIEE 2026での実証が示すリーガルAI導入の現実解

「外部クラウドに契約書を送るのはセキュリティ的にNG」という壁で、法務AIの導入が止まっている企業は多い。COLIEE 2026で条文含意タスク1位を記録したこの研究は、クローズドAPIを一切使わずオープンウェイトモデルだけで競合水準の精度を実証した。さらに「プロンプト形式を変えるだけでF1が0.34→0.56」という結果は、モデル投資より先に見直すべきPoC設計のポイントを教えてくれる。

2026 / 07 / 14 5 分で読める English version →

オンプレミスのサーバーラック上で複数のオープンウェイトLLMが法律文書を処理し、条文含意・判例検索・判決予測の各タスクへ振り分けられていく法務AIパイプラインのフラットイラスト

こんにちは。Affectosphere Group の三浦です。

法務部門でAI活用を検討したことのある方なら、この壁に一度はぶつかったはずです。

「契約書をLLMに貼り付けて要約させたい。でも機密情報をクラウドのAPIサーバーに送っていいのか?」「外部送信をセキュリティ部門に相談したら、やはりNGと言われた」「結局、法務AIの話は情報セキュリティ審査のところで止まっている」——。

リーガルAI導入の障壁として、技術の前にデータの機密性問題が来る。これは多くの企業が経験していることです。

arXivに公開された研究（Alshehri, Bencomo & Atapour-Abarghouei, arXiv:2607.11400）は、この問題に対して一つの現実的な答えを出しています。クローズドAPIを一切使わず、すべてオープンウェイトモデルだけで法情報処理コンペ COLIEE 2026 の全5タスクに挑んだ実戦報告です。

今日はビジネス応用の視点から、この研究がリーガルAI導入の現場にどう使えるかを考えてみます。

今日の3点

COLIEE 2026 の条文含意タスクで11チーム33投稿中1位を記録。クローズドAPIに頼らずオープンウェイトモデルのアンサンブルだけで、法律タスクの競合水準に達できることを実証した。機密性の高い法務文書をオンプレやVPC内で処理する構成の技術的妥当性を裏付ける結果として読める。
プロンプト形式を単一選択から複数選択に変えるだけでF1が0.343から0.555に跳ね上がり、モデルをQwen3-235Bに替えてリーガル推論プロンプトを加えるだけで精度が79.3%から91.5%へ。モデル投資の前に、プロンプト設計とタスク定義の見直しでROIが高い局面があることを示している。
これらの知見は、リーガルAIのPoC設計チェックリストとして転用できる。「どのタスクにどのアプローチが効くか」を実戦データで整理した論文として、AI導入前の設計レビューに参照価値がある。

① なぜ法務AIはクラウドAPIに頼りにくいのか

まず前提を整理します。

法務部門が扱う文書には、契約書、社内規程、訴訟資料、M&Aに関わる情報、規制当局への提出物など、外部に出せないものが多い。これらをクラウドAPIに送ることは、多くの企業でリスク管理上NGとされています。

結果として、「精度は高いが使えない商用モデル」と「使えるが精度が追いつかないオンプレ構成」の間で判断が止まる。リーガルAI導入がPoC以降に進まない組織には、この構図がよく見られます。

では、オープンウェイトモデルを自社のオンプレやVPC内にデプロイする構成で、実用に耐える精度が出るのか。ここが、今回の研究が直接的に答えにいった問いです。

対象となった COLIEE 2026 は、判例検索・判例含意・条文検索・条文含意・判決予測という法律処理の核心的なタスクを扱うコンペです。コンペ環境と自社業務は当然異なります。ただ、ここで競合水準の精度を出せた実績は、「オープンウェイトモデルで法律タスクがどこまで行けるか」を社内で議論するときの現実的な参照点になると思っています。

もう一点、私が特に注目したのは、アンサンブルの構成です。3系統9モデルを組み合わせるクロスアーキテクチャ・アンサンブルで、特定の1モデルへの依存を避けている。複数のオープンウェイトモデルを組み合わせることで、特定ベンダーのAPIに縛られない設計が成立することを示した形でもあります。

② 論文が示したこと:数値と、それが意味すること

具体的に何が起きたかを、論文の記述に沿って追います。

条文含意タスク（Task 4）では、3系統9モデルのクロスアーキテクチャ・アンサンブルで精度96.3%を達成し、11チーム33投稿の中で1位でした。使われたのはすべてオープンウェイトのモデルです。

不法行為予測と根拠抽出を扱うPilot Taskでも、TP精度73.1%・RE F1 68.2%と公式トップ級の水準を記録しています。

ただし私が特に興味深いと感じたのは、精度の高さそのものではなく、変化のパターンです。

Task 2では、プロンプトを「1つだけ選べ」という単一選択形式から「当てはまるものをすべて選べ」という複数選択形式に変えた。それだけでF1スコアが0.343から0.555に跳ね上がっています。モデルは変えていません。

Task 3では、含意モデルをQwen3-235Bに替えて、構造化されたリーガル推論プロンプトを加えた。その結果、精度が79.3%から91.5%に上がっています。

つまり、タスクの定義の仕方とプロンプトの設計が、精度に対して非常に大きく効いている。同じモデルを使っていても、問いの立て方で出力の質は大きく変わる。

この結果は、リーガルAIの導入を検討している組織に直接刺さる話だと思います。「モデルをグレードアップする前に、タスク定義とプロンプトを見直したか?」というチェックは、PoC設計の入口で一度必ず通る価値があります。

論文はまた、タスクごとに「効く帰納バイアスが異なる」ことも示しています。判例検索に効いた手法が、条文含意でそのまま効くとは限らない。これは実務的に重要な示唆で、自社のユースケースをまず特定し、そのタスクに合った設計を選ぶ、という順序が大事だということです。

③ 現場でどう試すか:部署とKPIの具体案

では、この研究の知見を現場にどう落とすか。私なりの導入シナリオを書きます。

まず前提として、この論文はコンペ参加の実戦報告です。自社の法務業務とそのまま一致するわけではありません。でも「オープンウェイトモデルで法律タスクがどこまで行けるか」の実例として、PoC設計の参照点に十分なると思っています。

想定する部署と使い方を書きます。

法務部門は、この研究を「自社の機密文書を外部に出さずに法務AIを動かす構成を社内に説明するときの技術的根拠」として使えます。「オープンウェイトモデルだけでこの水準の精度が実証されている実例がある」というのは、情報セキュリティ部門やIT統制部門を説得するときの一つの論拠になります。ただし、コンペの精度がそのまま自社で再現されるという保証ではありません。あくまで「技術的に可能性があることを示す参考資料」として使うのが適切です。

リーガルテック企業・特許事務所は、顧客への提案時に参照できます。「データを持ち出さない構成で、ここまでの精度が見えてきている」という示し方ができます。

コンプライアンス部門・RegTech担当は、規制文書の照合・含意判定のPoC設計で参照できます。条文含意タスクで96.3%という数値は、規制遵守チェックの自動化を検討するとき、ベースライン設定の参照点として頭に入れておく価値があります。

PoC設計で私がまず試してほしいのは、次のシーケンスです。

最初に、自社の法務タスクを「判例検索・含意・条文照合・予測」のどれに近いかで分類する。COLIEEの5タスクは、多くの法務業務の核心をカバーしています。

次に、タスクごとに「どのプロンプト形式が合うか」を実験する。Task 2のように、選択形式を変えるだけで大きく変わる可能性があります。この実験は、高価なモデルを調達する前にできます。コストをほとんどかけずに、設計の精度を上げる余地を先に探る。これが最初の一歩として現実的です。

測定するKPIは、次を提案します。

第一に、法務タスクの自動処理率。人手で処理していた判例照合・条文確認のうち、AIが正確に処理できる割合。第二に、レビュー時間の短縮率。法務担当者が文書確認に使う時間が、AI補助でどれだけ減ったか。第三に、データ外部送信ゼロの維持率。クラウドAPIへの外部送信なしでどこまで業務を回せているかのセキュリティ指標で、情報セキュリティ部門への報告材料にもなります。第四に、PoCから次フェーズ移行までの期間。プロンプト設計のチューニングサイクルがどれだけ速く回せているかの指標です。

進め方として、最初からフル自動化を狙わないことをすすめます。まずは法務担当者のレビュー補助として動かし、判断の最終確認は人間が行う構成から始める。そこで積み上がった正解データが、次フェーズのモデル調整に使えます。また、最初の対象タスクは一つに絞ることをすすめます。「条文含意だけ」「判例検索だけ」と範囲を限ったPoC設計のほうが、何が効いたか・何が効かなかったかの判断がつきやすくなります。

モデルを替える前に、プロンプトを疑う

この論文を読んで一番持ち帰れると思ったのは、精度の数値よりも「変化のトリガーが何だったか」でした。

Task 2でF1が0.343から0.555に上がったのは、モデルを替えたからではありません。プロンプトの選択形式を変えたからです。Task 3で精度が79.3%から91.5%に上がったのは、リーガル推論を明示的に促す構造を加えたからです。

これは法務AIに限らず、AI活用全般に言えることだと思っています。「精度が出ない」という状況に対して、最初に手を動かすべきはモデルのグレードアップではなく、タスク定義とプロンプトの見直しかもしれない。

もちろん、コンペ環境と自社業務は違います。この数値がそのまま再現されるとは限りません。ただ、「プロンプト設計の変更がこのスケールで効くことがある」という実例として、PoCを設計する前に読んでおく価値のある論文だと感じました。

では!

参考論文

Alshehri, Amal Saad, Bencomo, Nelly, & Atapour-Abarghouei, Amir (2026). Cross-Architecture LLM Ensembles, Feature-Based Reranking and Retrieval-Augmented Prompting for Legal Information Processing. arXiv preprint. https://arxiv.org/abs/2607.11400

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。