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

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

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

この記事では、あるエネルギーインフラ事業者（LPガス）の法令ナレッジで、この「参照関係」の問題にどう向き合い、回答の合格率をどう引き上げたかを書きます。商社の週次レポート検索の事例では「4層設計」で精度を積み上げた話をしましたが、今回はそのうちの検索設計を、法令という"参照でつながった文書"に特化させた話です。

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

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

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

実際、法令QAの研究でも「関連する根拠が階層的にリンクした複数の文書に分散し、通常の検索器ではその"参照のギャップ"を埋めきれない」ことが指摘されています（Beyond Case Law（ACL 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）で束ねたハイブリッドにしています。この点は商社案件と同じ思想です。そのうえに、法令特有の「参照を辿る」層を重ねたのが今回の肝です。

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

「測り方」を先に決める ── 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で「条文は拾えているのに回答が不正確」「準用先が抜ける」という症状が出ているなら、検索を参照関係まで広げる余地があるかもしれません。

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

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

相談を承っています

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

RAG精度設計の全体像（4層設計）は商社の文書検索事例に、サービスの形はAI/RAG精度設計サービスにまとめています。

30分のオンライン相談を申し込む

参考文献

• Edge et al. (2024) From Local to Global: A Graph RAG Approach to Query-Focused Summarization — arXiv:2404.16130
• Chae et al. (2026, ACL) Beyond Case Law: 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