法令RAGはなぜ難しいか — 参照関係を辿るGraph RAGで「準用先まで読む」設計

法令RAGが難しいのは、条文が準用・参照でつながっているからです。準用先の条文は元の条文と意味が似ていないことが多く、意味の近さで探すベクトル検索では拾えないことがあります。エネルギーインフラ事業者（LPガス）の法令ナレッジでは、参照関係を辿るGraph RAGと用語のクエリ拡張を入れ、網羅性を独立に測る4軸評価で確かめながら、回答の合格率を65%から約91%に上げました。

法令や社内規程を相手にしたRAGは、商品マニュアルや議事録のRAGとは難しさの質が違います。いちばんの理由は、条文が単独で完結していないことです。

ある条文を読んでいると「前条の規定を準用する」「第○条に定めるところによる」と書いてある。つまりその条文の意味は、参照先の条文を一緒に読まないと確定しません。人間の専門家は当然それを辿って読みます。ところが、ふつうに作ったRAGはそれをしない。質問に意味的に近い条文を1つ2つ拾って、それだけをLLMに渡す。準用先が抜け落ちたまま、もっともらしい——けれど不正確な——回答が返ってきます。

この記事では、その案件で「参照関係」の問題にどう向き合ったかを書きます。商社の週次レポート検索の事例では「4層設計」で精度を積み上げた話をしましたが、今回はそのうちの検索設計を、法令という"参照でつながった文書"に特化させた話です。

なぜベクトル検索だけでは法令で精度が出ないのか

RAGの検索といえばベクトル検索（意味の近さで探す）が定番です。これは「解約したいときの手続きは」のような曖昧な質問から該当条文にたどり着くのが得意で、法令検索でも入口としては有効です。

問題は、準用・参照でつながった条文は、意味的には似ていないことです。条文Aが条文Bを準用していても、AとBの文面は別の話をしていることが多い。だからベクトル検索でAを拾えても、Bは「意味が遠い」と判断されて拾われない。結果、回答はAの範囲でしか作れず、Bに書かれた肝心の条件が抜けます。法令の世界では、この抜けがそのまま「不正確な回答」になります。

実際、法令QAの研究でも「関連する根拠が階層的にリンクした複数の文書に分散し、通常の検索器ではその"参照のギャップ"を埋めきれない」ことが指摘されています（Beyond Case Law（arXiv preprint, 2026））。私たちが現場で踏んだのも、まさにこの壁でした。

もう一つの壁が用語です。利用者は日常語（通称・略称）で質問しますが、法令側は正式名称で書かれている。この語彙のギャップも、素のベクトル検索では取りこぼしの原因になります。

参照関係を辿るGraph RAG ── 「準用先まで読む」を仕組みにする

そこで採ったのが、検索結果を参照関係のグラフで広げる設計（Graph RAG）です。考え方はシンプルで、人間の専門家が条文を辿って読む動きを、そのまま仕組みにします。文書をグラフとして扱うRAGはMicrosoft Researchが体系化しており（GraphRAG, 2024）、法令分野でも知識グラフを併用して条文・判例・先例の隠れた関係を辿る研究が進んでいます（Bridging Legal Knowledge and AI, 2025）。私たちの実装は、この発想をLPガス法令の実務に落とし込んだものです。

まず前処理として、条文どうしの参照関係（どの条文がどの条文を参照・準用しているか）をLLMで抽出し、「参照先・参照元」として各条文に持たせておきます。検索のときは、ベクトル検索とキーワード検索で見つけた条文を起点に、この参照関係を辿って、準用先・関連条文をコンテキストに追加してからLLMに渡す。辿る深さや件数は調整できるようにして、広げすぎてノイズになるのを防ぎます。

検索そのものは、意味で探すベクトル検索と、正式名称・条番号のような厳密一致に強いキーワード検索（BM25）を、RRF（Reciprocal Rank Fusion／複数の検索結果を順位で統合する古典的手法。Cormack et al., SIGIR 2009）で束ねたハイブリッドにしています。この土台の組み方——役割分担・RRF・リランキングの設計——はハイブリッド検索の設計にまとめており、この点は商社案件と同じ思想です。そのうえに、法令特有の「参照を辿る」層を重ねたのが今回の肝です。

用語のギャップには、クエリ拡張で対応しました。質問を受けたら、通称・略称を法令上の正式名称に展開し、複数の検索クエリに広げてから検索する。これでベクトル・キーワードのどちらでもヒット率が上がります。

「測り方」を先に決める ── 4軸のLLM-as-a-Judge

法令RAGで怖いのは、「なんとなく良くなった気がする」で改善を進めてしまうことです。法令は正誤がはっきりしている分、評価も曖昧にできません。

そこで評価には、LLMを審査員に使う4軸スコアリングを据えました。1つの回答を「正確性／網羅性／根拠との整合性／生成品質」の4観点で各5点、合計20点満点で採点し、16点以上を合格とする。LLMを評価者に使う手法（LLM-as-a-Judge）はMT-Bench / Chatbot Arenaで体系化され、強力なモデルは人間の判断と8割以上一致すると報告されています（Zheng et al., 2023）。一方で位置バイアスや冗長性バイアスといった限界も知られているため、最終的な品質判断はドメイン有識者の人手レビューと併用しています。当たったかどうかの○×ではなく、「正しいか」だけでなく「関連条文を漏れなく拾えているか（網羅性）」「示した根拠と回答が食い違っていないか（整合性）」まで分けて測るのがポイントです。網羅性を独立した軸に置いたのは、まさに今回の主題である"準用先の取りこぼし"を数字で捕まえるためです。

この物差しがあると、改善の効き目が見えます。参照辿りを入れたら網羅性が上がったのか、クエリ拡張で正確性が上がったのか——軸ごとに分かるので、感覚ではなく数字で次の一手を決められます。

結果

初期の評価では、合格率は65%（23問中15問）でした。法令としては実用に届かない水準です。

ここに参照辿りのGraph拡張、用語のクエリ拡張、評価駆動の改善を重ねた結果、最終評価では22問中20問が合格（約91%）、平均スコアは17.9/20点まで上がりました（評価セットは改善の過程で設問を精緻化しているため初期と最終で設問数が一致しませんが、数字はいずれも各時点の実測値です）。回答生成に使うモデルを変えての比較も同じ評価軸で実測し、どちらが法令タスクに向くかを数字で判断しています。

数字を出せたのは、最初に4軸の評価セットという物差しを用意していたからです。これは商社案件と完全に同じ考え方で、ドメインが変わっても「測り方を先に作る」は変わりません。

法令だけの話ではない ── 参照関係を持つ文書すべてに効く

この設計が効くのは、実は法令に限りません。社内規程、契約書、技術標準、各種マニュアル——「ある項が別の項を参照・準用する」構造を持つ文書は、どれも同じ問題を抱えています。単純なベクトル検索では参照先が抜け、回答が不正確になる。

だから今回のGraph RAGは、そのまま他の規程系ドキュメントに横展開できます。規程を含む社内文書の検索全体を「探して一覧」から「調べて答える」へ変える話は、エンタープライズサーチとはとして別記事にまとめました。

法令・規程・契約のRAGで「条文は拾えているのに回答が不正確」「準用先が抜ける」という症状が出ているなら、検索を参照関係まで広げる余地があるかもしれません。

社内規程・契約で使うとき ── 法令との違い

規程や契約書でも、参照を辿る仕組みは法令と同じです。ただ、規程や契約で外れやすい点が3つあり、それぞれに別の手当てが要ります。

版の問題は、参照を辿っても解けません。正しい条文を拾えても、それが改定前の版なら答えは誤りです。いつの版か、現行か、をチャンクに持たせる方法は文書構造に沿ったチャンク設計に書きました。

略語は、法令の通称とは事情が違います。法令の通称は社外でも通じる言葉ですが、社内略語はその会社の中でしか通じません。LLMに言い換えを任せても正式名称は出てこないことが多いので、社内の略語表を辞書として渡します。答えが一意に決まる変換なので、LLMより辞書のほうがぶれません。

文書をまたぐ参照は、参照先の細則・別表・様式や覚書が索引に無いと辿れません。規程本体と同じ索引に入れておきます。

なお、規程を引いて答える検索と、規程に照らして判定する仕組みは分けて考えます。経費精算の明細を経費規程に照らして確認する監査のように判定まで任せたい業務では、条件を書き切れる判断はルールに、文脈が要る判断はAIの仕分けに回し、最終判断は人に残しています。その実例は経費監査をルール・AI・人の3層で組んだ事例にあります。

自社の文書にGraph拡張が要るかの見分け方

Graph拡張は、足せば必ず良くなる部品ではありません。参照構造の無い文書に足しても、構成が複雑になるだけです。次の3点で当たりをつけてください。

1. 外れた回答に足りなかった条件は、どこに書いてあったか。 拾えた条文の中にあったなら、参照を辿っても結果は変わりません。拾えた条文の参照先にあったなら、Graph拡張が効きます。
2. 質問の言葉と文書の言葉がずれていないか。 通称・略称・社内略語で聞かれ、文書は正式名称で書かれているなら、辿る起点になる条文をそもそも拾えていない可能性があります。この場合、先に効くのはクエリ拡張です。
3. 関連する条文を漏れなく示すことが、業務の要件か。 該当しそうな条文が見つかれば足りる用途なら、Graph拡張の手間に見合わないことがあります。準用先まで含めて正しく答える必要がある用途なら、網羅性が合否を分けます。

3点を確かめる材料は、評価セットです。業務で実際に出る質問を集め、いまの構成の回答を正確性・網羅性・根拠との整合性・生成品質の4軸で採点し、網羅性で落ちた設問を数えます。そのうち足りなかった条件が参照先にあった設問が多ければ、Graph拡張を足す価値があります。網羅性以外の軸で落ちているなら、原因は参照とは別のところにあります。評価セットの規模の目安として、この案件の初期評価は23問でした。評価セットの作り方は評価セットの設計にまとめています。

よくある質問

社内規程や契約書にも使えますか。

使えます。条・項で書かれ、「前条」「第○条に定める」のように他の条を参照する文書なら、参照関係を抽出して検索時に辿る仕組みは法令と同じです。規程や契約で要るのは周りの手当てで、改定前の版を根拠にしないよう施行日と現行版かどうかをメタデータで持つこと、社内でしか通じない略語を社内の略語表でクエリ拡張すること、細則や覚書のように別の文書へ飛ぶ参照先も同じ索引に入れることが要ります。逆に、参照構造の無い文書にGraph拡張を足しても、構成が複雑になるだけです。

MicrosoftのGraphRAGとは何が違いますか。

文書をグラフとして扱う点は同じですが、グラフの作り方と得意な問いが違います。Microsoft ResearchのGraphRAG（Edge et al., 2024）は、文書に出てくる人・組織などの関係をLLMでグラフにし、関係の近いまとまりごとに要約を先に作っておく方式です。論文の主眼は、「この文書群全体の主なテーマは何か」のような、全体を問う質問です。この記事の方式は、条文をノード、条文どうしの参照・準用をエッジとするグラフを持ち、検索で当たった条文から参照先を辿って根拠の条文を補います。特定の条件を条文に基づいて答える法令・規程のQAにはこの記事の方式が、文書群全体の論点や傾向をつかむ用途にはMicrosoftのGraphRAGが向きます。

参照関係は人手で作るのですか。

人手で一から書き起こしてはいません。前処理でLLMが条文どうしの参照・準用を抽出し、各条文に「参照先・参照元」として持たせています。検索時はここを辿り、深さと件数で広げすぎを抑えます。抽出で漏れた参照は辿られないため、準用先の取りこぼしとして評価の網羅性に表れます。

合格ラインはどう決めましたか。

改善を始める前に、物差しとして決めました。1つの回答を正確性・網羅性・根拠との整合性・生成品質の4軸で各5点、合計20点満点で採点し、16点以上（1軸あたり平均4点）を合格とします。当たり外れの○×にしなかったのは、関連条文を漏れなく拾えたかを網羅性として別に測り、準用先の取りこぼしを数字で捕まえるためです。採点はLLMを審査員に使い、最終的な品質判断はドメイン有識者の人手レビューと併用しています。この物差しで、合格率は初期の65%（23問中15問）から最終評価の約91%（22問中20問）になりました（設問は改善の途中で精緻化したため、問数は初期と最終で異なります）。

参照構造を持つ文書RAGの要点（まとめ）

• 症状で見分ける — 「条文は拾えているのに回答が不正確」「準用先が抜ける」が出ていれば、検索を参照関係まで広げる余地がある。
• 検索を参照まで広げる — ハイブリッド検索＋参照グラフ辿り＋クエリ拡張で、準用先と用語のゆれを同時に塞ぐ。
• 測り方を先に作る — 網羅性を独立軸に置いた4軸評価で、"取りこぼし"を数字で捕まえてから改善する。

相談を承っています

法令・規程・契約のような参照構造を持つ文書で、RAGの精度が出ずに困っているなら、一度話を聞かせてください。発注を前提とした商談ではなく、30分のオンライン相談です。いまの構成と、どの種類の質問で外しているのかを伺えれば、参照辿り・クエリ拡張・評価設計のどこに伸びしろがありそうか、当たりをつけてお伝えします。

RAG精度設計の全体像は、症状から原因を引くRAG精度の診断ガイドと、4層設計を積み上げた商社の文書検索事例に、サービスの形はAI/RAG精度設計サービスにまとめています。これからRAG全体を組む方は、RAG構築の手順から読むのが近道です。

参考文献

• Edge et al. (2024) From Local to Global: A Graph RAG Approach to Query-Focused Summarization — arXiv:2404.16130
• Chae et al. (2026) Beyond Case Law: Evaluating Structure-Aware Retrieval and Safety in Statute-Centric Legal QA — arXiv:2604.06173
• Barron et al. (2025) Bridging Legal Knowledge and AI: RAG with Vector Stores, Knowledge Graphs, and Hierarchical NMF — arXiv:2502.20364
• Cormack, Clarke & Büttcher (2009) Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods, SIGIR — PDF
• Zheng et al. (2023) Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena — arXiv:2306.05685
• Gao et al. (2023) Retrieval-Augmented Generation for Large Language Models: A Survey — arXiv:2312.10997