PDFをそのままAIに読ませるな──弁護士が専門書200冊をMarkdown化してClaudeのローカル知識ベースを作った話
はじめに
弁護士業務でAIを使う、という話題は珍しくなくなりました。ChatGPTやClaudeに法律相談の論点整理を手伝ってもらう、という方も多いと思います。
ただ、実務で本気で使い込むと、ある壁にぶつかります。
「自分の本棚にしかない知識に、AIがアクセスできない」 という壁です。
私は弁護士・税理士として、不動産・相続・国際業務(米日クロスボーダー)などを中心に実務を行っています。並行して、自分の事務所運営の中で「弁護士業務とAI/DX」というテーマに継続的に取り組んでおり、自前で案件管理SaaS(LegalFlow)も開発・運用しています。
その中で、最近かなり手応えがあった取り組みが、「専門書を100〜200冊単位でローカルOCRしてMarkdown化し、Claudeから検索可能なローカル知識ベースとして使う」 というものでした。
技術的には地味な話です。が、リーガルリサーチの初動の質と速度がはっきり変わったので、整理して書いておきます。
法律調査の宿命:最後は本棚に戻る
弁護士の法律調査は、ざっくり次のような流れです。
インターネット上の公開情報を確認する
法令・行政機関の公式情報を確認する
ネット記事や解説で論点の手がかりを得る
必要に応じて専門書・実務書にあたる
専門書の記載を踏まえて、実務上の回答や方針を組み立てる
論点が定型的なら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がなくても、日本語の縦書き・横書き混在の書籍テキストを、それなりの精度・速度で処理できるのが大きな利点です。
処理パイプラインは大筋こうしています。
PyMuPDF でPDFをページ画像として展開
NDLOCR Lite でページごとにテキスト抽出
ルールベース で明らかなノイズ(ヘッダ・ノンブル・改ページ由来の改行など)を除去
目次・本文・脚注を可能な範囲で構造的に分離
章立てに沿ったMarkdownとして書き出し
元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
