ここ最近、自社独自の生成AIを持つ企業が確実に増えています。社内規程を検索するAI、過去案件を分析するAI、問い合わせに答えるAI——市販のサービスをそのまま使うのではなく、自社のデータを読ませた「うちのAI」を作る動きです。

私も、その一人です。1年以上前からローカルAIを自分で構築し、法律問題の検索・分析システムを作ってきました。そして、その過程で数多くの壁にぶつかりました。ハルシネーション。パラメータ数の限界。コンテキスト長の限界。どれも、実際に手を動かさなければ実感できないものでした。

今回は、その試行錯誤の中身を率直にお話しします。これから独自の生成AIを導入しようとお考えの企業にとって、実際にやってみた人間の失敗談ほど役に立つものはないと思うからです。

この記事の要点(30秒まとめ)

• 1年以上ローカルAIを構築し、ハルシネーション・パラメータ数・コンテキスト長という三つの壁に直面した。
• 実際に起きた症状は6つ。無関係な法律の引用、実在しない法律の引用、学習させた判例を参照しない、大量投入しても反映されない、質問と無関係な回答、当たらずとも遠からずだが的確でない回答。
• 重要なのは、すべてがRAGの作り方の問題ではなかったこと。「大量に入れたのに反映されない」の原因はembeddingからEC2に送る情報の個数の不足だった（10件→20件に変更して改善）。原因がどの層にあるかの切り分けが要る。
• 性能とセキュリティを両立させる方法として、AWSを選択した。
• 独自AIの成否を決めるのは、現在の技術水準ではRAGの作り方である。
• 自社独自のプログラムを作成し、PDFなど各種フォーマットの資料をAIが最も読みやすい形でRAG化することに成功した。具体的には資料の種類・状態に応じて12種類のPythonスクリプトを使い分け、NDLOCR-liteでのOCR → JSON → 階層構造の復元 → Markdown化を自動化している。
• その際の原則は「原本を変更しない・AIに内容を創作させない・読めなかった箇所は補わずに報告する」の三つ。法律文書では、見た目を整えるためにAIに埋めさせた瞬間、そのデータは使えなくなる。
• その結果、AWS版の法律検索・分析システムは回答に誤りがなく、的確に答える水準に到達。しかし同じRAGをローカルAIに載せるとハルシネーションが発生した——ローカルAIの限界はまだ突破できていない。
• この経験から、企業が独自AIを導入する際の問題点・ポイント・留意点と解決策を相当程度アドバイスできる。そして独自AIの導入・運用は、企業のコンプライアンスと不可分である。

1. ローカルAIで1年以上格闘して分かったこと

最初に選んだのはローカルAIでした。理由は明快で、情報漏洩を絶対に避けたかったからです。弁護士は依頼者の秘密を守る義務があります。契約書や事件記録を外部のクラウドAIに投げるという選択肢は、私にはありませんでした。

自作のパソコンにAIモデルを入れ、インターネットにつながずに動かす。理屈のうえでは完璧です。ところが、実際に業務で使おうとすると、三つの壁が次々に現れました。

この三つは独立した問題ではなく、絡み合っています。賢いモデルを使いたい、しかし長い文書も読ませたい——その両方を満たそうとすると、VRAMが足りなくなる。ローカルAIの制約については「なぜ大企業の社内AIは正しく回答できないのか」でも詳しく書きました。

実際に起きた「うまくいかない」の中身

「精度が出ない」と一言でまとめてしまうと伝わりませんので、実際に私が直面した症状を具体的に挙げます。おそらく、自社でAIを組んだ方なら見覚えのあるものばかりだと思います。

実際に起きた症状	私の経験上の原因	打ち手の方向性
① 質問とまったく関係のない法律を引用してくる	RAGの作り方	チャンクの区切り方と、検索キーの持たせ方を見直す
② 実在しない法律を引用してくる	RAGの作り方	参照すべき資料が拾えていない状態を解消する。根拠が無ければ答えさせない設計にする
③ ピンポイントで答えられる判例を学習させているのに参照しない	④の原因とRAGの整理の仕方の合わせ技	渡す件数を増やしたうえで、その判例が埋もれない粒度に整理し直す
④ 大量に情報を入れたのに反映されない	embeddingからEC2に送る情報の個数が不足していた	渡す件数を増やす（当事務所では10件→20件に変更）
⑤ 質問とは関係のないことを答える	RAGの作り方	質問の意図と参照文書がずれる原因を、チャンク設計から潰す
⑥ 「当たらずとも遠からず」のことを答えるが、的確な答えになっていない	RAGの作り方	最も根が深い。関連文書に辿り着いていても核心を掴めない状態を解消する

見落としがちな原因──「渡す情報の個数」

この表で強調したいのは、六つの症状のすべてがRAGの作り方に起因していたわけではない、という点です。

①②⑤⑥はRAGの作り方の問題でした。しかし④の原因は違いました。embedding（文書をベクトル化して検索できるようにする仕組み）から、実際に処理を行うサーバ（EC2）へ送る情報の個数が不足していたのです。

ここは非常に見落としやすい落とし穴です。RAGは「大量の資料の中から、質問に関連しそうなものを検索して、AIに渡す」仕組みですが、この「渡す個数」には設定値があります。いくら大量の資料を整備しても、渡す個数が絞られていれば、必要な資料はAIの手元に届きません。届いていない資料を、AIが回答に反映できるはずがないのです。

当事務所の場合、当初は10件に設定していました。これでは足りず、現在は20件に変更しています。たったこれだけのことで、回答の質は明確に変わりました。

「大量に情報を入れたのに反映されない」という症状に直面すると、つい「RAGの作り方が悪いのか」「モデルの能力が足りないのか」と考えてしまいます。しかし実際の原因は、もっと手前にある、渡す件数という地味な設定値でした。膨大な資料を整備した労力が、たった一つの数字で無駄になっていたわけです。

そして③は、この二つの合わせ技でした。ピンポイントで答えられる判例を学習させているのに参照しない——これは、渡す件数が足りずにその判例がそもそも届いていなかったことと、RAGの整理の仕方が最適でなかったことが重なって起きていました。片方だけ直しても解決しません。だからこそ原因の切り分けに時間がかかりました。

いちばん怖いのは②ではなく⑥

もう一つ、六つを並べて見えてきたことがあります。②のような派手なハルシネーションよりも、⑥のほうが実は厄介だということです。

存在しない法律を引用してくれば、専門家ならすぐ気づきます。しかし「当たらずとも遠からず」だが的確ではない回答は、一見すると正しく見えてしまう。関連する話をしているので、読み流せば通ってしまうのです。これが業務判断に使われたら、と考えるとぞっとします。気づけるのは、その分野を分かっている人間だけです。

2. なぜAWSを選んだのか──性能とセキュリティの両立

ローカルAIの限界を数字で理解したとき、選択を迫られました。性能を諦めるか、セキュリティを諦めるか。

どちらも諦めたくありませんでした。そこで出した答えがAWSの活用です。

ポイントは、一般消費者向けのクラウドAIサービスと、AWSのような商用利用向けの基盤は規約も設計も別物だという点です。消費者向けサービスでは入力が学習に使われる設定が初期状態のこともありますが、商用基盤では入力が基盤モデルの学習に使われない設計になっています。そのうえで、データを自社の管理下に置く構成を重ねれば、高性能なモデルを使いながら、情報を外に出さないという両立が可能になります。

観点	ローカルAI（オンプレミス）	AWS等の商用クラウド基盤
情報の所在	完全に手元。外部に出ない	自社管理下の環境に置ける（設計次第）
使えるモデルの性能	機材のVRAMに制約される	大規模モデルを利用できる
コンテキスト長	KVキャッシュがVRAMを圧迫し制限が厳しい	はるかに長い文書を扱える
初期コスト	GPU等の機材購入が必要	従量課金で始められる
精度（実体験）	同じRAGでもハルシネーションが発生	誤りのない回答に到達

3. 独自AIの成否を決めるのは「RAGの作り方」

ここが、今回いちばんお伝えしたい点です。

現在のAI技術で自社独自のAIを組む場合、成否を分けるのはモデル選びよりも「RAGの作り方」です。

RAG（Retrieval-Augmented Generation／検索拡張生成）とは、AIが回答する際に、あらかじめ用意した自社の文書を検索して参照させる仕組みです。社内規程や判例をAIに「読ませる」というとき、実際に行われているのはこの処理です。

そして実務の世界では、RAGの精度は前処理とチャンク分割（文書をどう区切るか）で大部分が決まると言われています。実際、「前処理×チャンクで精度の7〜8割が決まる」と整理する解説もあるほどです。元の資料に誤記や重複、古い情報が混ざっていれば、どんな高度な手法を使っても精度は上がりません。

逆に言えば、ここを丁寧にやれば精度は劇的に変わるということです。多くの企業が「AIを導入したのに使えない」と感じる原因の大半は、モデルではなくこの工程にあると私は考えています。データの作り方については「AIに読ませる「データの作り方」」でも詳述しました。

4. 自社開発プログラムで、RAG化を最適化した

この一年余りの試行錯誤で、RAGを作成する技術はかなり上達しました。

当事務所では、自社独自のプログラムを作成し、PDFをはじめとするさまざまなフォーマットの資料を、AIに学習させるうえで最適な状態に変換することに成功しています。

言葉にすると簡単ですが、実際は地道な作業の積み重ねです。PDFからテキストを抜き出せば、改行は崩れ、ヘッダーやページ番号が混ざり、表は原型をとどめません。それを人間が読んで意味が通る形に組み直し、意味の切れ目で適切に区切り、必要な注記を付ける。判例であれば「第一審と控訴審で判断が分かれた」といった文脈情報も持たせる。この工程を、資料の形式を問わず安定して行えるようにプログラム化しました。

具体的にどう処理しているか

もう少し具体的にお話しします。当事務所では、まず手元の資料をすべてPDFに統一します。そのうえで、その資料がどういう種類・状態なのかによって、処理を振り分けています。

ここが重要です。ひとくちにPDFと言っても、中身はまったく違います。文字データがそのまま埋め込まれているPDFもあれば、紙をスキャンしただけで実質は画像でしかないPDFもある。さらに法律資料の場合、判例・法令の逐条解説・契約書では文書の構造そのものが違います。これらを同じ処理にかけても、まともなデータにはなりません。

画像データのPDFについては、国立国会図書館が公開している「NDLOCR-lite」という無料のアプリを使ってOCR（文字の読み取り）を行い、いったんJSON形式に変換します。そのJSONをAIで整えたうえで、最終的にMarkdown形式に落とし込む。この一連の流れを、資料の種類と状態に応じた12種類のPythonスクリプトを作成して自動化しています。

素材タイプ	見分け方	出力の形
判例（判決書）	判例IDのメタ表紙＋「主文」「事実及び理由」	1判例＝1ファイル＋索引
法令の逐条解説	「第N条」＋法文＋解説番号＋参考判例	章・条単位でファイル化
契約書	前文＋「第N条（見出し）」の連続＋記名押印欄	1契約書＝1ファイル＋索引

いちばん手強いのは「階層の復元」

この工程で最も難しいのは、実は文字の読み取りそのものではありません。失われた文書の階層構造を復元することです。

法律文書は「第1 → 1 → (1) → ア」といった項番で階層が作られています。ところがOCRを通すと、項番と本文の間のスペースが失われます。たとえば「4 1審原告」が「41審原告」という一つの文字列になってしまう。人間なら文脈で分かりますが、機械には「41」という数字にしか見えません。

当事務所のスクリプトでは、これを三つの手がかりで解いています。第一にマーカーの種別（「第N」なら大見出し、算用数字なら中見出し、というルール）。第二に座標の字下げ（OCRが返す行の位置情報を見て、本文より外に出ている数字は項番と判断する）。第三に連番の期待値追跡（「次に来るべきは4のはず」と予測しながら読み、「41審原告」を項番4＋本文「1審原告」に分割する）。

さらに、縦書き資料に多い2文字の反転（「主文」が「文主」と読まれる）の補正、PDFの物理的な改行を論理段落へつなぎ直すリフロー処理、ページ重複による見出しの二重出力の除去なども組み込んでいます。判例については、同じ判例が二重登録されることがあるため、判例IDで重複を排除する仕組みも入れました。

法律文書だからこそ譲れない三つの原則

技術的な工夫以上に大事にしているのが、次の三つの原則です。法律文書を扱う以上、ここは絶対に譲れません。

この三つ目が、特に重要だと考えています。「分からなかったことを、分からなかったと記録する」。これは弁護士の仕事の作法そのものです。技術的にはAIに補完させることも可能ですが、それをやった瞬間、そのデータは法律業務に使えないものになります。

あわせて、変換後には必ず検証を行います。判例の件数が想定どおりか、見出しレベルの分布は適切か、そして内容保全率——OCR原文の文字数と出力の文字数の比が1.0〜1.1に収まっているか。大きく欠けていれば、読み順や結合を間違えているサインです。

なぜMarkdownなのか、にも触れておきます。見出しの階層や箇条書きといった文書の構造を、記号で明示できるからです。AIにとって「どこからどこまでが一つのまとまりなのか」が分かりやすくなり、チャンク分割の精度も上がります。前処理の質がRAGの精度を左右する以上、最終的にどの形式で持たせるかは決して些細な問題ではありません。

正直なところ、ここまでやる必要があるのかと思われるかもしれません。しかし、スキャンしただけの判例PDFをそのまま投入しても、AIはまともに読めません。「資料を入れたのに精度が出ない」という悩みの一因は、この入口の処理にあることが少なくないと考えています。

5. 結果──到達点と、まだ超えられていない壁

その結果、AWSを活用した当事務所の法律問題検索・分析システムは、回答に全く誤りがなく、質問に対して的確に回答する水準に到達しました。実務で使えるレベル、という意味です。

ところが、ここからが本題です。

まったく同じRAGをローカルAIに搭載して同じシステムを作ったところ、ハルシネーションが起こりました。

これは重要な示唆を含んでいます。RAGを完璧に作り込んでも、それを動かすモデルの能力が足りなければ、正確な回答は得られないということです。RAGはハルシネーションを抑える有効な手段ですが、完全になくせるわけではない——この点は一般にも指摘されているとおりでした。

この「うまくいかなかった話」こそ、これから導入を検討する企業にとって最も価値のある情報だと思っています。成功例だけを聞いて同じ構成を真似ても、同じ結果にはなりません。

6. だから、企業の独自AI導入をアドバイスできる

こうした経験とノウハウの蓄積から、企業が独自の生成AIシステムを導入する際の問題点・ポイント・留意点、そしてそれらの解決方法について、かなりの部分をアドバイスできると自負しています。

たとえば、次のような論点です。

検討事項	実務上の勘所
オンプレかクラウドか	「安全だからオンプレ」と即断しない。必要な精度が出るかを先に検証する
使うモデルの選定	パラメータ数だけでなく、扱いたい文書量からコンテキスト長の要件を逆算する
RAGの設計	ここに最も投資する。前処理とチャンク分割の質が精度を左右する
検索して渡す件数	見落とされやすい。いくら資料を整備しても、渡す個数が足りなければ回答に反映されない
不具合の切り分け	精度が出ないとき、RAG・渡す件数・モデル能力のどの層の問題かを分けて検証する
元データの整備	誤記・重複・古い情報を放置したまま入れない。誰が判断して整えるかを決める
読めなかった箇所の扱い	AIに補完させない。不明箇所は不明のまま記録する。見た目を整えると検証できなくなる
入力データの扱い	学習に使われない設計か、保持期間はどうか、契約と技術の両面で担保する
出力の検証体制	誰がAIの回答を検証するか。検証できる専門知識のある人がいるか

7. 独自AIの導入・運用は、コンプライアンスと不可分である

最後に、いちばん強調したい点です。

企業が独自の生成AIをどのように導入し、運用していくのかは、その企業のコンプライアンスと密接に結びついています。

これは大げさな話ではありません。設計段階の選択が、そのまま法的リスクの大小を決めるからです。

入力したデータが学習に使われる設定になっていないか。取引先から預かった営業秘密を、秘密管理性を損なう形で外部に出していないか。顧客の個人情報を扱うなら、その処理は適法か。AIの誤った回答が業務判断に使われた場合、誰が責任を負うのか。従業員が勝手に外部のAIサービスに社内資料を貼っていないか。

これらはすべて、「AIをどう作り、どう運用するか」という技術的な設計と、法務的な検討が地続きになっている領域です。技術者だけで設計すれば法的リスクが見落とされ、法務だけで検討すれば実装できない要求になる。両方が分かる立場から設計する必要があります。

AIの利用が広がるほど、社内規程の整備、従業員教育、取引先との契約条項の見直しといったコンプライアンス面の課題も増えていきます。独自AIの導入は、単なるIT投資ではなく、ガバナンスの問題として扱うべきテーマだと考えています。

おわりに

独自の生成AIを持つことは、もはや大企業だけの話ではなくなりました。しかし、作れば使えるようになるわけではありません。私自身、1年以上かけて壁にぶつかり続け、いまだにローカルAIの限界は超えられていません。

だからこそ、実際に手を動かした人間だからこそ言えることがあると思っています。どこでつまずくのか。何に投資すべきか。そして、その選択が法的にどんな意味を持つのか。

自社での生成AI導入をご検討中で、「技術面と法務面の両方から相談できる相手がほしい」とお考えの企業の方は、ぜひ一度ご相談ください。