llms.txt による法令QAタスクのための JIT コンテキスト取得

02 Dec, 2025

概要

本稿では、 LLM による法令 QA タスクにおいて、専門家がキュレーションしたコンテキストデータに代わる手法として、llms.txt 形式による JIT 方式のコンテキスト取得を提案する。e-gov 法令検索の法令データを llms.txt 形式で配信する実験サイトを構築し、金融商品取引法に関する設問320件で検証した結果、GPT-5.1 (reasoning_effort: high)において正答率91.2%を示し、専門家によりキュレーションされたコンテキストデータに近い性能が得られることを確認した。​​​​​​​​​​​​​​​​

法令 QA タスクとデジタル庁「法令 QA データセット」

法令に関する質問応答 (QA) タスクは、法律分野で LLM に期待されるタスクの一つである。日本の法令に関する QA タスクについての性能評価手法の先行事例は、デジタル庁による『日本の法令に関する多岐選択式QAデータセット』（以下「法令 QA データセット」）がある¹。

「法令 QA データセット」では、法令に関する問題文と、多岐選択式の回答の候補が与えられる。それに加えて、問題の解答に必要と考えられる前提知識をテキスト形式で与える「コンテキスト用データ」も含まれる。「コンテキスト用データ」には、問題文で直接言及されている条文の内容だけでなく、その条文から参照される別の法令・政令やガイドラインも含まれる。 LLM の性能を評価する際には、「コンテキスト用データ」を渡す場合と渡さない場合とを比較することで、モデル自体が事前学習等で得た能力と、渡した「コンテキスト用データ」の有効性とを評価することができる。

『複数の LLM を用いた法令 QA タスクの Ground Truth Curation』²では、 GPT-4 を用いた 1-shot での評価が紹介されており、 GPT-4 ではコンテキストなしで 49.3%、コンテキストありで 86.1% の正解率となっている。専門家がキュレーションしたコンテキストを与えることが法令 QA タスクの向上に寄与することがわかる。

(植松, 2025)² でも示されているとおり、このような「コンテキスト」情報の作成には「高い専門性が求められるため複数の弁護士に作成を依頼する必要があるため非常にコストがかかる」。とはいえ、キュレーションせずにすべての条文を与えることは、現在の LLM の最新のコンテキストウィンドウでも効率が良いとはいえない。現在の基盤モデルのコンテキストウィンドウは GPT-5.1 が 128,000 トークン³、 Claude Opus が200,000 トークン⁴であるところ、日本の刑法の条文全体をすべてエンコードすると、それだけで約420,000 トークンを要し、コンテキストウィンドウに収まらない。1,000,000 トークンのコンテキストウィンドウ⁵を持つ Gemini 2.5 Pro でも4割近くを占めてしまい、性能に悪影響がある⁶。さらに、法令が参照する政令等は事前に特定することができないため、これらも入力コンテキストとしてすべて与えるとすれば、100万トークンでも不足する。

llms.txt による法令・政令データの JIT コンテキスト取得

そこで、すべての条文情報を事前に与えて 1-shot で回答させるのではなく、最初に法令の概要や関連する別の法令・政令の一覧のみを与え、各条文の内容や関連法令・政令の詳細は、必要に応じて取得し、必要な情報が揃った時点で回答することにより、実際に必要な情報だけをコンテキストに読み込む方法が考えられる。このような "just-in-time" 方式のコンテキスト情報の取得は、 LLM エージェント（以下、単に「エージェント」）では一般的である⁷。エージェントは、典型的には「ツール呼び出し機能を備えた LLM による推論のループ」として実現される⁸。ここで「ツール」とは、 LLM が必要と判断したときに呼び出すことができる関数であり、ループ内でタスクを分析した LLM は「ツール呼び出しリクエスト」を推論結果として出力することができ、 LLM がリクエストで指定したパラメータで関数が呼び出されると、今度はその返り値がそれまでのメッセージの履歴に付け加えられて、再度 LLM に入力される。以降、 LLM がもうツールの呼び出しは必要がないと判断して最終的な推論結果となるメッセージを返すと、エージェントがタスクの実行を完了したことになる。ツールは、外部の API を呼び出すこともできるほか、 Model Context Protocol 標準に対応した MCP サーバが提供するツールをインポートして使うこともできる。

法令データを提供する API として、 e-gov 法令検索⁹ API がある。また、 e-gov 法令検索を LLM に簡単に使わせるための MCP サーバの実装も複数存在する。しかし、 MCP サーバをホストしたり、ローカル環境で利用できるようセットアップすることは、多くのユーザにとって簡単ではない。

別のアプローチとして、 llms.txt¹⁰がある。一般に Web サイトは人間が閲覧することを想定して作成されているため、視覚的な表現やマーケティングライティング的な要素も含み、LLM から見て必要な情報に辿り着きやすい構成になっていないことが多い。そこで、 各サイトが その内容を LLM にとって解釈しやすいように、 Markdown 形式のテキストでまとめたファイルを所定の場所に配置することで、ユーザから指示を受けた LLM がそのサイトの情報を利用してタスクの遂行がしやすくなることを期待し、仕様を策定・推奨しているのが llms.txt である。 llms.txt では、サイトのタイトル、概要、詳細（任意）を Markdown 形式でまとめることとなっており、詳細の中には見出し記法を使ってセクションを設けることも可能である。 llms.txt はあくまで大きな枠組みを提供するものであり、各項目に何を書くべきかこと細かに指定するものではない。 Markdown のリンク記法を用いて、サイト内の別の情報へのハイパーリンクを示すこともできる。 llms.txt は、そのサイトのルートパスに配置してサイト全体についての概要を与えるのみでなく、サイト内の各ページについて配置することもできる。この場合には、ファイル名は llms.txt ではなく、例えば foo/bar/example.html であれば foo/bar/example.md に配置する。内容の構成はサイト全体の場合と同様となる。

そこで、e-gov 法令検索サイトの llms.txt に、ある法令の (1) 名前、 (2) その概要と詳細説明、 (3) 条文一覧、 (4) 関連する別の法令・政令の一覧を記載しておく方法が考えられる。LLM エージェントがその法令についての QA タスクを与えられた際には、 llms.txt を使ってその法令の情報にアクセスし、問題文の内容に応じた条文や関連法令・政令を JIT 方式で取得することによって、専門家がキュレーションした「コンテキスト用データ」を使った場合に近い性能を達成できると考える。

法令情報を llms.txt 形式で配信するサイトの構築

実際には e-gov 法令検索サイトは llms.txt を提供していないので、 e-gov 法令検索で掲載されている法令に対して、擬似的に llms.txt を作成するサイト（laws.e-gov.aiを作成した。例えば、 e-gov 法令検索サイトで金融商品取引法を掲載する https://laws.e-gov.go.jp/law/323AC0000000025 に対して、トップレベルドメインの .go.jp を .ai に置き換えることで、金融商品取引法を紹介する llms.txt を持つページ https://laws.e-gov.ai/law/323AC0000000025.md にアクセスすることができる。 LLM エージェントはこの中からタスクの遂行に必要な条文や関連法令・政令のリンクを見つけてアクセスし、必要な情報が揃い次第最終的な回答を返すという仕組みを想定する。

ここでは、「法令 QA データセット」のうち金融商品取引法に関する問題320件のみを抽出し、「コンテキスト用データ」なし、「コンテキスト用データ」あり、 llms.txt ありの場合での性能を比較した。基盤モデルとしては GPT-5.1 を使って検証した。 GPT-5.1 では分析の程度（reasoning_effort）を4段階で設定できるので、なし（none), 低（low), 高 (high)の場合で比較した。ベースラインとして、(植松, 2025)²と同じモデルである GPT-4 でも検証した。

実験結果

GPT-5.1 の分析の程度を「高」とする設定では、そもそも「コンテキスト」なしでも GPT-4 の「コンテキスト」ありに迫る性能を示し、事前学習において GPT-4 よりも多くの法令データにより訓練されていることが想像できる。llms.txt 使用の場合の正解率は91.2%に達し、「分析なし・コンテキストあり」と概ね同水準となった。これは、JIT 方式のコンテキスト取得が専門家のキュレーションした「コンテキスト」の代替として活用できることを示している。 分析の程度が同じ設定の場合では「コンテキストあり」にはわずかに及ばなかった。両設定で正解・不正解が分かれた問題を見ると、専門家がキュレーションした「コンテキスト用データ」には法令・政令だけではなく、金融庁適時開示ガイドラインなどの法令ではない規則の情報が含まれており、こうした点で差がついたと考えられる。

分析の程度を「低」に下げると、llms.txt ありの正答率は80.6%となり、依然として GPT-4（コンテキストなし）を大きく上回るものの、「コンテキストあり」との差は拡大した。

分析なしの場合、「コンテキスト」・llms.txt の有無に関わらず GPT-4 を上回ったが、llms.txt を使った場合は「コンテキスト」なしの場合と大差なく、「コンテキスト」ありの場合からは大きく劣った。別の実験により、分析なしでは、法令データを問題文より後に置いた場合では正答率が上がらず、システムメッセージ（問題文より前）に置いた場合には正答率が上がることが確認できた。この性質は、ツールによる JIT コンテキスト取得ではその仕組み上ツール呼び出し結果が後に入ることになることと相性が悪い。一方で、最初の推論に先立ってコンテキストをロードする場合には性能向上が期待でき、そうであれば RAG のような仕組みと相性が良いモデルということになる。

ベースラインとして検証した GPT-4 では、(植松, 2025)² と大きく変わらない結果となった。前世代のモデルである GPT-4 はコンテキスト幅が 8,192 ととりわけ狭く、簡素な内容のみを含む llms.txt ですらコンテキスト幅に収まらなかった。

以上の結果から、 llms.txt による JIT 方式のコンテキスト取得の効果は分析の程度を高く設定した場合に最大化され、その場合には専門家によるキュレーションに近い性能を達成できることが確認された。​​​​​​​​​​​​​​​​

参考文献