相談事例 /
東京
弁護士10名の法律事務所、社内文書検索にRAGを自前構築 ─ 月40時間の調査工数を8時間へ圧縮した事例
課題
NASに蓄積した5,200ファイルの契約書・判例が横断検索できず、月40時間以上が「どこに何があるか探す」だけに消えていた。市販SaaSは機密性の問題と日本語対応の弱さで採用できず。
解決策
pgvector + BM25ハイブリッド検索 + Claude 3.5 Haiku によるRAGをWSL2上に自前構築。縦書きPDFのbbox再ソートと800トークンチャンク設計で日本語法律文書の精度問題を解決。
成果
月40時間の調査工数が8時間に圧縮。APIコストは月12,000円以下。原文書は外部に一切出さず弁護士会規程をクリア。IVFFlatインデックスによりp95クエリ応答120ms以内を達成。
## 依頼の背景
東京・池袋に事務所を構える弁護士10名体制の法律事務所。取り扱い分野は企業法務・不動産・相続が中心で、年間受任件数は800件前後だ。問題は事務所の「内部」にあった。
20年近くの業務で蓄積した契約書・覚書・判例メモ・鑑定意見書が、NAS上に計5,200ファイル存在していた。格納ルールは古参の事務員が把握しているが、体系化はされていない。フォルダ構造はある程度整理されているものの、ファイル名が「2019_契約書_最終版_修正2_確定.docx」のような命名が混在していた。NASのGUI検索はファイル名しか見ない。Windowsエクスプローラーでのgrep的な検索も試みたが、日本語漢字混じり文書では文字コード起因の誤検出が多く、実用にならなかった。
担当弁護士が新規案件を受任するたびに「過去の類似案件はどこにあるか」「この条件で処理した前例は」という調査に費やす時間が、月平均40時間を超えていた。弁護士の時間単価を考えると、見えないコストとして月100万円規模が溶けている計算だ。
市販のドキュメント管理SaaSも検討した。CLIO、MiloといったリーガルテックSaaSは日本語対応が弱く、既存5,200ファイルの移行コストが現実的ではなかった。何より、法律文書の機密性を考えると、全文を外部クラウドへアップロードすることへの抵抗が強かった。
## 構成と技術選定
最初の打ち合わせで方針は1時間で固まった。外部サービスには文書原本を出さず、ローカルまたはプライベートなインフラで完結させる。埋め込み生成とベクトル検索はpgvectorで賄い、回答生成だけClaude APIを使う構成だ。
この設計の肝は「何がAnthropicのサーバに送信されるか」だ。原文書は外に出ない。送信されるのは検索クエリと、ローカル検索で取得したチャンクテキストのみ。弁護士会の規程上も、この範囲なら問題ないとの確認が弁護士本人から取れた。
採用した技術スタックは以下のとおり：
- PDFパース：pdfplumber（縦書き処理は後述）
- Wordパース：python-docx
- 埋め込みモデル：text-embedding-3-large（OpenAI、1,536次元）
- ベクトルDB：PostgreSQL 15 + pgvector 0.5.1、IVFFlatインデックス（リスト数256）
- 検索方式：ベクトル検索 + BM25 全文検索のハイブリッド（RRF融合）
- 回答生成：Claude 3.5 Haiku（コスト最適化のため上位モデルは使わない）
- フロントエンド：Streamlit、事務所内LAN限定アクセス
- ホスティング：事務所内の既存Windowsサーバ（WSL2 + Ubuntu 22.04）
## 実装で詰まった縦書きPDF問題
最大の障壁は縦書きPDFだった。昭和・平成初期の判例や古い公正証書のスキャンPDFが、縦書きレイアウトで数百件存在していた。pdfplumberのデフォルト抽出では、縦書きの文字がページ左上から右に向かって列単位で抽出されるため、意味が完全に崩壊する。
対策として取ったのは、mupdf-pythonを使った文字単位のbbox取得からの再ソートだ。各文字のx座標・y座標を取得し、縦書きと判定した場合はy昇順→x降順でソートし直す処理を書いた。完璧ではないが、テキスト抽出の実用精度が60%程度から85%程度に改善し、検索に耐えるレベルになった。
チャンク設計も試行錯誤した。契約書は条文単位で分割するのが論理的だが、正規表現での自動検出が難しい。最終的に、800トークン・オーバーラップ80トークンの固定ウィンドウに、「第X条」「（）」で始まる行を優先分割点として追加する方式に落ち着いた。5,200ファイルのインジェスト処理は約22時間かかった。pgvectorのIVFFlatインデックス構築後、クエリ応答はp95で120ms以内に収まっている。
## ハイブリッド検索の効果
ハイブリッド検索の融合にはReciprocal Rank Fusion（RRF）を使っている。ベクトル検索の上位20件とBM25全文検索の上位20件を取得し、RRFスコアで再ランキングして上位5件をClaudeに渡す。単独のベクトル検索と比較して、テストクエリ50問での適合率が平均15ポイント高くなることを確認した。
法律文書では「損害賠償」「瑕疵担保」のような固有の法律用語が頻出する。こうした専門用語はベクトル空間での意味的距離よりも、BM25の語彙マッチが効く場面が多い。両方を組み合わせることで、意味的な類似案件と語句の完全一致案件を両方拾えるようになった。
## 導入3ヶ月後の数字
月40時間の調査工数が8時間に圧縮された。「過去に類似する相続争いの案件はあるか」「この免責条項の前例は」という問いに対して、秒単位で参照候補が返ってくる。担当弁護士からは「もう戻れない」という言葉をもらった。
コストは月12,000円以下で収まっている。text-embedding-3-largeの埋め込み生成は月約3,000円、回答生成のClaudeはHaikuで月約8,000円、その他インフラは既存サーバの電気代のみだ。市販のリーガルテックSaaSが月額5〜15万円であることを考えると、コストパフォーマンスの差は歴然としている。
残課題もある。スキャン品質が低いOCR起源のPDFは精度が不安定で、フルOCR処理パイプラインの追加を検討中だ。また現状のStreamlit UIはスマートフォン非対応で、外出先での確認に使えない。この2点は次フェーズの対応予定として積み上げている。
法律事務所以外でも、社内文書の量が多く外部クラウドへの全文送信を避けたいケースでは、同じ構成が有効だ。医療法人、会計事務所、製造業の設計部門などで同様の相談が来ている。
東京・池袋に事務所を構える弁護士10名体制の法律事務所。取り扱い分野は企業法務・不動産・相続が中心で、年間受任件数は800件前後だ。問題は事務所の「内部」にあった。
20年近くの業務で蓄積した契約書・覚書・判例メモ・鑑定意見書が、NAS上に計5,200ファイル存在していた。格納ルールは古参の事務員が把握しているが、体系化はされていない。フォルダ構造はある程度整理されているものの、ファイル名が「2019_契約書_最終版_修正2_確定.docx」のような命名が混在していた。NASのGUI検索はファイル名しか見ない。Windowsエクスプローラーでのgrep的な検索も試みたが、日本語漢字混じり文書では文字コード起因の誤検出が多く、実用にならなかった。
担当弁護士が新規案件を受任するたびに「過去の類似案件はどこにあるか」「この条件で処理した前例は」という調査に費やす時間が、月平均40時間を超えていた。弁護士の時間単価を考えると、見えないコストとして月100万円規模が溶けている計算だ。
市販のドキュメント管理SaaSも検討した。CLIO、MiloといったリーガルテックSaaSは日本語対応が弱く、既存5,200ファイルの移行コストが現実的ではなかった。何より、法律文書の機密性を考えると、全文を外部クラウドへアップロードすることへの抵抗が強かった。
## 構成と技術選定
最初の打ち合わせで方針は1時間で固まった。外部サービスには文書原本を出さず、ローカルまたはプライベートなインフラで完結させる。埋め込み生成とベクトル検索はpgvectorで賄い、回答生成だけClaude APIを使う構成だ。
この設計の肝は「何がAnthropicのサーバに送信されるか」だ。原文書は外に出ない。送信されるのは検索クエリと、ローカル検索で取得したチャンクテキストのみ。弁護士会の規程上も、この範囲なら問題ないとの確認が弁護士本人から取れた。
採用した技術スタックは以下のとおり：
- PDFパース：pdfplumber（縦書き処理は後述）
- Wordパース：python-docx
- 埋め込みモデル：text-embedding-3-large（OpenAI、1,536次元）
- ベクトルDB：PostgreSQL 15 + pgvector 0.5.1、IVFFlatインデックス（リスト数256）
- 検索方式：ベクトル検索 + BM25 全文検索のハイブリッド（RRF融合）
- 回答生成：Claude 3.5 Haiku（コスト最適化のため上位モデルは使わない）
- フロントエンド：Streamlit、事務所内LAN限定アクセス
- ホスティング：事務所内の既存Windowsサーバ（WSL2 + Ubuntu 22.04）
## 実装で詰まった縦書きPDF問題
最大の障壁は縦書きPDFだった。昭和・平成初期の判例や古い公正証書のスキャンPDFが、縦書きレイアウトで数百件存在していた。pdfplumberのデフォルト抽出では、縦書きの文字がページ左上から右に向かって列単位で抽出されるため、意味が完全に崩壊する。
対策として取ったのは、mupdf-pythonを使った文字単位のbbox取得からの再ソートだ。各文字のx座標・y座標を取得し、縦書きと判定した場合はy昇順→x降順でソートし直す処理を書いた。完璧ではないが、テキスト抽出の実用精度が60%程度から85%程度に改善し、検索に耐えるレベルになった。
チャンク設計も試行錯誤した。契約書は条文単位で分割するのが論理的だが、正規表現での自動検出が難しい。最終的に、800トークン・オーバーラップ80トークンの固定ウィンドウに、「第X条」「（）」で始まる行を優先分割点として追加する方式に落ち着いた。5,200ファイルのインジェスト処理は約22時間かかった。pgvectorのIVFFlatインデックス構築後、クエリ応答はp95で120ms以内に収まっている。
## ハイブリッド検索の効果
ハイブリッド検索の融合にはReciprocal Rank Fusion（RRF）を使っている。ベクトル検索の上位20件とBM25全文検索の上位20件を取得し、RRFスコアで再ランキングして上位5件をClaudeに渡す。単独のベクトル検索と比較して、テストクエリ50問での適合率が平均15ポイント高くなることを確認した。
法律文書では「損害賠償」「瑕疵担保」のような固有の法律用語が頻出する。こうした専門用語はベクトル空間での意味的距離よりも、BM25の語彙マッチが効く場面が多い。両方を組み合わせることで、意味的な類似案件と語句の完全一致案件を両方拾えるようになった。
## 導入3ヶ月後の数字
月40時間の調査工数が8時間に圧縮された。「過去に類似する相続争いの案件はあるか」「この免責条項の前例は」という問いに対して、秒単位で参照候補が返ってくる。担当弁護士からは「もう戻れない」という言葉をもらった。
コストは月12,000円以下で収まっている。text-embedding-3-largeの埋め込み生成は月約3,000円、回答生成のClaudeはHaikuで月約8,000円、その他インフラは既存サーバの電気代のみだ。市販のリーガルテックSaaSが月額5〜15万円であることを考えると、コストパフォーマンスの差は歴然としている。
残課題もある。スキャン品質が低いOCR起源のPDFは精度が不安定で、フルOCR処理パイプラインの追加を検討中だ。また現状のStreamlit UIはスマートフォン非対応で、外出先での確認に使えない。この2点は次フェーズの対応予定として積み上げている。
法律事務所以外でも、社内文書の量が多く外部クラウドへの全文送信を避けたいケースでは、同じ構成が有効だ。医療法人、会計事務所、製造業の設計部門などで同様の相談が来ている。