PDFをそのままAIに読ませるな──弁護士が専門書200冊をMarkdown化してClaudeのローカル知識ベースを作った話


はじめに

弁護士業務でAIを使う、という話題は珍しくなくなりました。ChatGPTやClaudeに法律相談の論点整理を手伝ってもらう、という方も多いと思います。

ただ、実務で本気で使い込むと、ある壁にぶつかります。

「自分の本棚にしかない知識に、AIがアクセスできない」 という壁です。

私は弁護士・税理士として、不動産・相続・国際業務(米日クロスボーダー)などを中心に実務を行っています。並行して、自分の事務所運営の中で「弁護士業務とAI/DX」というテーマに継続的に取り組んでおり、自前で案件管理SaaS(LegalFlow)も開発・運用しています。

その中で、最近かなり手応えがあった取り組みが、「専門書を100〜200冊単位でローカルOCRしてMarkdown化し、Claudeから検索可能なローカル知識ベースとして使う」 というものでした。

技術的には地味な話です。が、リーガルリサーチの初動の質と速度がはっきり変わったので、整理して書いておきます。


法律調査の宿命:最後は本棚に戻る

弁護士の法律調査は、ざっくり次のような流れです。

  1. インターネット上の公開情報を確認する

  2. 法令・行政機関の公式情報を確認する

  3. ネット記事や解説で論点の手がかりを得る

  4. 必要に応じて専門書・実務書にあたる

  5. 専門書の記載を踏まえて、実務上の回答や方針を組み立てる

論点が定型的なら3で済むこともありますが、少し踏み込んだ判断が必要な場面では、最終的にほぼ必ず4と5が要ります。要件事実、争点ごとの裁判例、実務運用、執行上の論点――こういうものはやはり書籍ベースの専門知識に戻ります。

ここがリーガルリサーチのボトルネックでした。AIがいくら賢くても、私の本棚には入れない。


紙の本をPDF化しただけでは、足りなかった

最初のステップとして、私は専門書を継続的にPDF化していました。

書籍を裁断・スキャンしてPDF化し、原本を廃棄してくれる業者を使って、自分が保有する書籍100〜200冊単位を、ローカル環境にPDFとして整理する。これだけでも紙をめくるよりは速い。フルテキスト検索もできなくはない。

その上で、ファイルシステムMCP(Model Context Protocol)でClaudeにローカルフォルダを参照させ、

「ローカルフォルダ内のPDFから、本件論点に関係しそうな文献を探して、回答のヒントになる記載を抜き出してください」

という運用を試していました。

これが、思ったほど機能しなかったのです。


「ファイルを推測して開く」AIの限界

理由を分解すると、3つありました。

第一に、網羅性が担保できない。
AIはファイル名やフォルダ構成、質問の文脈から「この本に書いてありそうだ」と推測して、関係しそうなPDFを開きにいきます。これは人間が本棚を眺めて当たりをつける作業に近いですが、フォルダ全体を網羅的に検索しているわけではない。「重要な記載が、AIが開かなかった本に書いてある」 というリスクが残ります。

第二に、PDFはAIにとって重い。
特に紙書籍由来の画像PDFは、内部的にはOCR処理が必要で、1冊読むのに時間がかかります。フォルダ全体を舐めるような使い方には、そもそも向いていない。

第三に、出力が「候補提示」にとどまりやすい。
網羅性も読み込みも限界があるので、結果として返ってくるのは、

「ローカルフォルダ内に、この論点に関係しそうなPDFがあります。詳細はそちらを確認してください」

という、人間がやる作業をほぼそのまま戻されるような回答です。これは、調査の代替にはなりません。


発想の転換:PDFをAIに読ませるな、Markdownを読ませろ

ここで方針を変えました。

「PDFのまま読ませるのが悪い。先にOCRしてMarkdownにしておけばよい」

考え方はシンプルです。

  • AIが直接扱うのはPDFではなく、軽量なテキスト/Markdownファイル

  • 元PDFと同じフォルダに、対応する `.md` を置いておく

  • AIには `.md` を全文検索・参照させる

ファイル構成のイメージはこんな感じです。

/legal-books/
  ├─ 民訴_要件事実_類型別.pdf
  ├─ 民訴_要件事実_類型別.md
  ├─ 借地借家_実務.pdf
  ├─ 借地借家_実務.md
  ├─ 相続実務.pdf
  └─ 相続実務.md

ポイントは、PDFはあくまで「人間用の原本」として残し、AI用の検索インデックスをMarkdownで別建てする という発想です。本棚はそのまま、その横にAI用の索引を作るイメージに近い。


実装:NDLOCR Lite + ルールベース整形

OCR処理には、国立国会図書館がOSSで公開している NDLOCR Lite をベースに使いました。専用GPUがなくても、日本語の縦書き・横書き混在の書籍テキストを、それなりの精度・速度で処理できるのが大きな利点です。

処理パイプラインは大筋こうしています。

  1. PyMuPDF でPDFをページ画像として展開

  2. NDLOCR Lite でページごとにテキスト抽出

  3. ルールベース で明らかなノイズ(ヘッダ・ノンブル・改ページ由来の改行など)を除去

  4. 目次・本文・脚注を可能な範囲で構造的に分離

  5. 章立てに沿ったMarkdownとして書き出し

  6. 元PDFと同名・同階層に `.md` として保存

最後の整形パスにはClaudeを噛ませて、見出し階層や引用記号の整え直しもしています。完全に綺麗になるわけではありませんが、「AIが検索・参照する用途」としては十分 な品質になります。重要なのは人間の可読性ではなく、意味検索のヒット率 です。


ビフォー/アフター:賃料増額請求の調査で何が変わったか

具体例として、最近実務で扱った賃料増額請求(借地借家法32条)の検討プロセスで比較してみます。

導入前(PDF直読み運用)

Claudeに「賃料増額請求側が主張・立証すべき要件を整理し、関連文献を当たってほしい」と指示。返ってくるのは、

  • 借地借家法32条の条文構造の整理

  • 一般的な要件のネット情報ベースの整理

  • 「ローカルフォルダ内の◯◯という本に関係しそうな記述があります」

という構成。最後の一行が、結局自分で本を開く必要がある という形で残ります。

導入後(Markdown索引運用)

同じ指示に対して、

  • 検討すべき要件を1〜4で整理

  • 各要件の意味と典型的な争点

  • どの文献の何章のどの部分にどのような議論があるか

  • 第3要件については特定の文献で異説があるので優先確認すべき、という指摘

までが一発で返ってきます。

差は何かというと、「弁護士が次に何をすべきか」が具体的に提示される ようになった、という点です。「関係しそうな本がある」と言われるのと、「第3要件についてはこの本のこの章の議論が中心、ただし反対説あり」と言われるのとでは、初動の意味がまったく違います。


得られた4つの効果

整理しておくと、効果は4つに分解できます。

1. 網羅性が上がった

Markdownはテキストなので、フォルダ全体を全文検索できます。AIが「開きにいく本を選ぶ」というステップが要らなくなり、重要な記述が「見落とされた本」に眠ったままになるリスク が大きく下がりました。

2. レスポンス速度が落ちなかった

処理対象を画像PDFから軽量Markdownに切り替えたので、依頼内容を高度化したにもかかわらず、体感速度はむしろ改善方向です。

3. 回答に根拠がついた

これが一番大きい。AIの回答が「一般論」から、「自分の本棚にある具体的な文献の、具体的な記述」に裏打ちされたもの に変わりました。最終的な確認は弁護士本人が行うのは当然ですが、その「確認すべき場所」が明確になります。

4. リーガルリサーチの初動が圧縮された

論点の構造化、見るべき文献の特定、要件ごとの争点抽出が初動でかなりのところまで進むので、その先の「自分で読み込む・組み立てる」工程に時間を回せるようになりました。最終判断は弁護士、その前段が大幅に短縮、という構図です。


著作権と情報管理:自己利用の範囲で

この種の取り組みでは必ず、著作権と情報管理の話が出ます。私の運用は次の前提です。

  • OCR処理はすべてローカル環境で実行

  • 利用するOCRツール(NDLOCR Lite)もローカルで動作するもの

  • Claudeへの参照も、学習に使われない設定の環境を使う

  • ファイル自体をクラウドにアップして共有することはしない

  • 事務所内で他のメンバーが自由に閲覧できる状態にもしない

  • あくまで自分が購入し保有する書籍を、自分が参照しやすくするための自己利用

「著作権上完全に問題がない」と言うつもりはありません。ただ、少なくともクラウドへの無制限アップロードや第三者共有といった、明らかにリスクの高い形態を避けた上で、私的利用の範囲に収まるよう設計している、という整理です。事務所単位で展開するなら、また別の整理が要ります。


これは「AI活用」ではなく「知識のインフラ整備」だ

最後にひとつだけ、伝えたいことを書いておきます。

弁護士業務でAIを使う、という話の多くは、「どんな質問の仕方をすればAIがいい答えを返してくれるか」 というプロンプトの話に寄りがちです。それも大事ですが、実務で本当に効いてくるのは、もう一段手前の、

「AIが扱える形に、自分の知識資産を整備する」

という工程だと感じています。

専門書をPDFで持っているだけでは、AIにとって「本棚の写真」と大差ありません。Markdown化して初めて、それは検索・参照可能なローカル知識ベースになります。これは弁護士業務だけの話ではなく、税務・不動産・医療など、専門書ベースの判断が中心になる業界全般に共通する論点だと思います。

私自身は、この流れを LegalFlow(自前で開発している案件管理SaaS)と組み合わせて、最終的には「事件単位の知識・履歴」と「分野ごとの専門知識ベース」の両方をAIから扱える状態を目指しています。今回のMarkdown索引はその後者のピースです。

リーガルリサーチのDXは、賢いAIを連れてくる話ではなく、自分の知識を、AIが歩ける道に舗装する話です。

地味ですが、ここが効きます。


太田垣 佳樹(弁護士・税理士)
芝綜合法律事務所/税理士法人Baton One
https://flow.legal-consulting.jp

いいなと思ったら応援しよう!