Skip to content
Affectosphere Group Kansai University, Keito Inoshita Laboratory
EN

Column

契約書を全部AIに読ませるのをやめる——法務文書のAPIコストを最大56分の1にする「注入か誘導か」

大量の取引契約をLLMに読ませて質問応答させるとき、全文を丸ごと注入するのがいちばん自然な発想です。でもそれはトークン課金の観点では最も高くつくやり方でもあります。20問ベンチマークで、リランキング付き意味検索は同等の精度を保ったまま文脈トークンを17.3分の1に、LLMナビゲーション型のNAVINDEXは文脈サイズを約56分の1に圧縮しました。契約審査・法令調査AIのAPIコストを構造から下げる実装指針を、リーガルテックの現場目線で考えます。

6 分で読める English version →
左側に大量の取引契約書コーパス、そこから全文注入・NAVEMBED・NAVINDEXの3経路が伸び、トークン削減率が1倍・17.3倍・56倍と表示され、右側にキャッシュ付き注入の損益分岐を示すコスト交点グラフが並ぶフラットイラスト

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

法務の現場でLLMを使い始めた人が、最初にぶつかる壁があります。請求書ではなく、APIの請求書のほうです。

契約書や規約をAIに読ませて「この条項の解除要件は？」「表明保証の範囲は？」と聞く。やり方としてはシンプルで、契約書の全文をプロンプトに貼り付けて、質問と一緒に投げるだけ。これがいちばん素直な発想です。ところが、取引契約は数十ページ規模がざらで、それを何百・何千件と回すと、トークン課金がじわじわ、ときに一気に効いてきます。全文注入は精度は出るのですが、コスト面では最も贅沢なやり方でもあります。

arXiv に公開された研究（Mahmoud Hany, Mourad ElSheraey, Mahmoud Said, Peter Naoum、arXiv:2607.05764）は、この「大量の取引法的文書をLLMにどう読ませるか」を、コスト効率の観点から正面から比較しています。全文をそのまま渡す「注入（inject）」か、必要な箇所だけ取りに行く「誘導（navigate）」か。今日はこの問いを、リーガルテックのAPIコスト最適化という実務の視点で読み解きます。

今日の3点

  1. 全文注入は精度こそ出るがトークンコストが最も高い。研究は代わりに2種類の構造化検索——埋め込みベースのNAVEMBEDと、LLMに文書を辿らせるNAVINDEX——を20問ベンチマークで比較した。
  2. リランキング付きの意味検索は、注入と同等の性能を保ったまま文脈トークンを17.3分の1に削減。NAVINDEXは全18問で同等性能を維持しながら、総トークンフットプリントを1.61倍小さくし、文脈サイズを約56分の1まで圧縮した。
  3. さらに「コーパスサイズが検索ペイロードの約10倍以下の場合にのみ、キャッシュ付きの全文注入が費用対効果を持つ」という閉形式のクロスオーバールールを導出。案件規模に応じて注入と検索のどちらを選ぶかを、勘ではなく数式で判断できる。

① なぜ全文注入は「高くつく」のか

まず、なぜ全文注入がコスト的に厳しいのかを整理します。

LLMのAPIは、入力トークンの量に応じて課金されます。契約書の全文をプロンプトに詰め込むということは、質問のたびに文書全部の分だけトークン代を払うということ。1件なら気になりませんが、法令調査やM&Aのデューデリのように数百・数千の文書を横断する業務では、この「毎回全部払う」構造がそのまま運用コストに乗ってきます。

しかも、質問に本当に必要なのは文書のごく一部であることがほとんどです。解除条項について聞きたいのに、契約書の前文から定義条項から全部を毎回読ませている。人間の弁護士なら該当ページだけ開いて確認するのに、素朴なLLM運用は「毎回、頭から全部読む」を強いているわけです。

ここに、注入をやめて「必要な箇所だけ取りに行く」検索アプローチの余地が生まれます。研究が比較したのは、この取りに行き方の2つの流派でした。

② NAVEMBEDとNAVINDEX：取りに行き方の2流派

研究が全文注入の対抗馬として立てたのは、性格の違う2つの構造化検索です。

ひとつめが NAVEMBED、埋め込みベースの意味検索です。文書をあらかじめ細かく分割してベクトル化しておき、質問に意味的に近い断片だけを引っ張ってくる。いわゆるRAG（検索拡張生成）の王道ですね。ここにリランキング（取ってきた候補を精度良く並べ替える工程）を足すと、注入と同等の性能を保ったまま、質問に渡す文脈トークンを17.3分の1にまで削れたと報告されています。精度を落とさずにトークンを一桁以上圧縮できるなら、それだけで運用コストの景色は変わります。

ふたつめが NAVINDEX、LLM自身に文書構造を辿らせるナビゲーション型です。目次やインデックスをLLMに見せて「この質問なら、どの節を開けばいい？」と判断させ、必要な部分だけを段階的に開いていく。人間が分厚い契約書のインデックスから該当箇所へジャンプするのに近い動きです。このNAVINDEXは、ベンチマークの全18問で注入と同等の性能を保ちながら、総トークンフットプリント（全処理でやりとりするトークンの合計）を1.61倍小さくし、質問に渡す文脈サイズは約56分の1まで圧縮したと報告されています。

面白いのは、この2つが削っている場所が違うことです。NAVEMBEDは「質問時に渡す文脈」を薄くする。NAVINDEXはそれに加えて、辿り方そのものを賢くして全体のトークン収支まで軽くする。どちらが効くかは、扱う文書の量や構造によって変わってきます。

③ 「注入か検索か」を数式で決める——閉形式クロスオーバールール

この研究がとりわけ実務に効くと感じたのは、「じゃあ結局どっちを使えばいいの？」に数式で答えている点です。

検索は万能ではありません。文書が少ないうちは、検索の仕組みを組む手間のほうが割高になり、素朴に全文を注入したほうが安いケースもあります。特に、同じ文書を繰り返し使う場面ではプロンプトキャッシュ（一度渡した文脈を再利用してコストを抑える仕組み）が効くので、なおさら注入が有利になりうる。

研究はこの損益分岐を、閉形式のクロスオーバールールとして導いています。ざっくり言うと「コーパスサイズが、検索で取ってくるペイロードの約10倍以下のときにだけ、キャッシュ付きの全文注入が費用対効果を持つ」。つまり、扱う文書コーパスがそのくらい小さいなら注入で十分、それを超えて大きくなるなら検索に切り替えたほうが得、という分岐点が数字で引けるわけです。

これは設計判断の武器になります。「なんとなくRAGにしておこう」でも「とりあえず全部貼っておこう」でもなく、案件のコーパス規模と1問あたりの検索ペイロードを見積もれば、注入と検索のどちらが安いかをあらかじめ計算できる。システムをどちらで組むかを、勘ではなくルールで決められるのは、コストを説明する立場の人間にとってありがたい話です。

④ 現場でどう試すか：部署とKPI

では、これを自社のリーガルテックにどう落とすか。私なりの導入シナリオを一つ、具体的に置いてみます。

想定するのは、数百〜数千件の取引契約を扱う法律事務所や企業法務部門のAI契約審査システムです。狙いはシンプルで、既存の「全文注入型」の質問応答パイプラインを、NAVINDEX型の構造化検索に載せ替えること。回答精度は同等に保ちながら、1問あたりのAPIコストを構造から下げにいきます。

部署と用途のイメージはこうです。M&Aのデューデリ担当なら、大量の対象契約から解除条項・チェンジオブコントロール条項だけを狙って引く。金融機関の法務・コンプライアンス部門なら、規約や約款の横断チェックを、全文を毎回読ませずに該当箇所ナビゲーションで回す。企業法務のAPIコスト最適化担当なら、まず自社のコーパス規模を測り、例のクロスオーバールールに当てはめて「この案件は注入、あの案件は検索」と振り分ける運用ルールを作る。いずれも「大量文書・繰り返し質問・でも必要なのは一部だけ」という同じ構造を抱えています。

測定KPIは、効果を数字で語れるように次を提案します。第一に、いちばんわかりやすいAPIコスト削減率。全文注入をベースラインに、NAVINDEX化で1問あたりのトークン課金が何%減ったか。研究の文脈サイズ約56分の1という数字は、そのまま「同じ精度でここまで軽くできる余地がある」という目安になります。第二に回答精度の維持——コストを下げても正答率が落ちていないことの担保（研究では18問で同等性能でした）。第三に処理スループット、つまり同じ予算で1日に何件の契約を捌けるようになったか。

進め方としては、まず一部の案件タイプで注入版と検索版を並走させ、精度が本当に同等かを自分たちのデータで確かめるのが安全だと思います。そのうえでクロスオーバールールに沿って、コーパスが大きい業務から検索へ寄せていく。小さく測って、効いた領域から広げる。この順番なら、コスト削減を精度の犠牲なしに積み上げられます。

「全部読ませない」という上品なコスト削減

この研究を読んで私が気持ちよかったのは、コスト削減の作法が上品なことです。

安いモデルに乗り換える、精度を諦める、といった消耗戦ではない。必要な箇所だけを賢く取りに行くことで、精度を保ったままトークンを一桁も二桁も削る。「全部読ませる」という素朴さを手放すだけで、これだけの余地が生まれる。しかもいつ注入・いつ検索かは数式で決まる。派手さはないけれど、大量文書を毎日回す現場ほど、この差はボディブローのように効いてくるはずです。

最後に感情AIの視点から一言。私たちが扱う大規模な感情コーパスも、実は同じ問題を抱えています。膨大なテキストに感情ラベルを付ける作業は、素朴にやれば「全部を毎回処理する」高コスト構造になりがちです。必要な箇所だけを取りに行くトークン効率の設計思想は、スケーラブルな感情アノテーションのコスト設計にもそのまま効いてくる予感があります。契約書でも感情データでも、「全部読ませない賢さ」は共通の武器になりそうです。

では！

参考論文

  1. Hany, Mahmoud, ElSheraey, Mourad, Said, Mahmoud, & Naoum, Peter (2026). Inject or Navigate? Token-Efficient Retrieval for LLM Analysis of Transactional Legal Documents. arXiv preprint. https://arxiv.org/abs/2607.05764

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