1. はじめに
「転居したので必要な書類を教えてください」。住所変更届は検索できても、代理時の委任状、経路変更時だけ必要な申請、転居日で切り替わる期限が別の条項にあれば、根拠を集めきれないかもしれません。
本記事の背景は、関連文書を見つけることと、その人に必要な根拠をそろえることは違うという問題です。目的は、関係データで根拠の集め方がどう変わり、どの条件で改善につながるかを理解することです。
名称を固定します。一般的な graph-augmented RAGを「グラフ利用RAG」、Microsoft Research発のライブラリとその方式を 「Microsoft GraphRAG」 と呼びます。後者は原文からグラフを抽出し、関係の密な集まりを階層化・要約して検索に使います。すべてのグラフ利用RAGが同じ構成になるわけではありません。[^graphrag-home]
連載第1回のオントロジーで事務手続きQAを正確にする：意味・条件・根拠の設計を受け、第2回では検索への生かし方を扱います。公式情報の確認基準日は2026-09-05です。業務例は設計用の教材であり、実測した精度改善の報告ではありません。
2. RAGは「取り込み・検索・根拠付き生成」の組み合わせ
2.1 取り込みでは、原文を検索可能な単位に整える
RAGはRetrieval-Augmented Generationの略で、外部情報を検索し、大規模言語モデル（LLM）へ渡して回答を生成する方式です。質問と検索結果を入れるコンテキストには大きさの上限があるため、必要な情報を選びます。[^graphrag-paper]
取り込みではPDFや社内ページから文字・表・見出しを取り出し、チャンクという文章のまとまりに分けます。意味の近さを数値で比較するベクトルや、キーワード検索の索引も用意します。
本連載では、文書ID、版、条項、適用条件、閲覧権限と原文への参照を保ちます。「代理の場合」と「委任状を添付する」を切り離さないため、必要なら見出し単位の大きな親チャンクも回収します。表の行列や条件節を壊す取り込みは、グラフ以前に直す問題です。
2.2 検索結果を、そのまま答えにしない
検索では許可された範囲から原文を集め、LLMが説明文を作ります。ただし、引用があることと、引用が結論を支えることは別です。版違い、条件節の欠落、例外の取り落としを確認します。
図1は本連載のアプリ構成案で、Microsoft GraphRAGの内部フローではありません。取り込み後、質問に応じて通常検索と関係検索を使い、原文回収へ合流します。
各結論と条項を対応させた入力を根拠パックと呼びます。「住所変更届が必要」と「代理なら委任状も必要」にそれぞれ根拠を付け、条件不足は追加質問や保留にします。
2.3 比較相手は、十分に整えた通常RAG
比較対象を「ベクトル検索の上位数件だけ」にすると、通常検索の改善までグラフの手柄にしてしまいます。本記事の**ベースライン（比較基準）**には、次の対策をそろえます。
| 対策 | 狙うこと |
|---|---|
| キーワード検索 | 届出名や規程番号の正確な一致 |
| ベクトルとのハイブリッド | 「引っ越し」「住居変更」の言い換え対応 |
| メタデータで絞り込み | 業務・版・適用時点・権限の限定 |
| 親チャンクの回収 | 条件節・ただし書き・表見出しの復元 |
| リランカーの再順位付け | 候補を質問との関連性で並べ直す |
たとえばAzure AI Searchは全文・ベクトル検索の結果を統合でき、semantic rankerで初期結果を再順位付けできます。グラフなしでも使える仕組みです。[^hybrid-search][^semantic-ranking]
ただし、既存候補の再順位付けだけでは、候補に入らなかった条項は救えません。[^semantic-ranking] 通常検索を整えても別条項へつながらない失敗が残るかが、グラフ利用の出発点です。
3. 意味の近さと、明示的な関係は何が違うか
3.1 オントロジー・ナレッジグラフ・検索方式を分ける
この連載では、三つの役割を次のように分けます。
| 要素 | 役割 | 転居手続きでの例 |
|---|---|---|
| オントロジー | 用語・関係・条件の意味を定義 | 住居変更と経路変更を区別 |
| ナレッジグラフ | 対象と関係をデータとして保持 | 届出・委任状・条項を結ぶ |
| グラフ利用RAG | 検索して回答の文脈を構成 | 代理時の書類の根拠を回収 |
対象をノード、関係をエッジと呼びます。「似ている」「参照する」「条件を満たすと必要」は別の関係なので、適用条件と原文参照を一緒に保持します。意味の定義が正しくても関係データがなければ検索できず、関係が多くても意味が曖昧なら誤った候補が増えます。
3.2 架空の「社内転居・通勤経路変更」を固定する
以下は架空の教材規程であり、法令や実在の社内規程ではありません。本記事の説明用文書IDはMOVEです。対象社員の転居手続きについて、第1〜3条は両版で同じ、第4条の期限だけが変わる設定にします。
| 教材の条項 | ルール |
|---|---|
| 第1条：住所変更 | 住居変更があれば、住所変更届が必要 |
| 第2条：通勤経路 | 通勤経路変更申請は、経路が変わった場合のみ必要 |
| 第3条：代理申請 | 本人が行う場合と代理人が行う場合を区別し、代理なら委任状も必要 |
| 第4条：旧v1の期限 | 転居日が2026-09-30以前なら、転居日の翌日から14暦日以内 |
| 第4条：新v2の期限 | 転居日が2026-10-01以後なら、転居日の翌日から10暦日以内 |
暦日は土日・祝日も数えます。翌日を1日目として、2026-09-30の転居はv1で2026-10-14まで、2026-10-01の転居はv2で2026-10-11までです。教材にない休日繰り延べは加えません。
適用版を決めるのは転居日であり、回答日や取り込み日時ではありません。 新版が登録済みでも、9月30日の転居へ10日以内の期限を適用しません。
「2026-10-01に転居し、代理人が提出する。経路変更は不明」なら、住所変更届と委任状は必要ですが、通勤経路変更申請は未確定です。転居から経路変更を推論しません。
3.3 関係をたどって、別の原文を集める
類似検索は「質問に近い文章」を探します。明示的な関係検索では、手続きIDや条件IDで結んだデータをたどれます。質問に「委任状」がなくても、代理条件と追加書類の関係から、その根拠条項へ進めます。
図2では、住居変更と代理申請の根拠を回収し、未確認の経路変更申請は保留します。線をたどった事実ではなく、条件に合う原文が回収できたことが回答の支えです。
たとえば住所変更届の申請方法、代理条件、追加書類、根拠条項を順に結ぶと、質問にない委任状の原文も回収できます。例外が別条項にある場合も、例外が修正する原則と適用条件を一緒に集めます。本教材にない例外を創作するわけではありません。
この結合はRDBのJOINでも可能です。SQLの結合も複数の表を条件で組み合わせ、連鎖させられます。[^relational-joins] 重要なのはグラフDBの採用ではなく、関係を明示して根拠を集められることです。既存RDBで扱いやすければ、保守負担も踏まえてそのまま使う選択があります。
4. Microsoft GraphRAGは何を作り、どう検索するか
4.1 インデックスはグラフと要約を段階的に作る
Microsoft GraphRAGの標準的なインデックス処理は、原文から対象と関係を抽出し、構造を要約へ展開します。[^index-dataflow][^index-outputs]
| 成果物 | 平易な説明 |
|---|---|
| TextUnits | 原文を分割した分析・参照単位 |
| Entities | 抽出された人・組織・出来事などと説明 |
| Relationships | 対象間の関係と説明 |
| Communities | 関係の密な対象の階層的な集まり |
| Community Reports | 集まりをLLMが要約したレポート |
TextUnitsからentitiesとrelationshipsを抽出し、グラフを階層的なLeidenアルゴリズムでコミュニティに分け、reportsと検索用の埋め込みを作ります。[^index-dataflow]
コミュニティはつながり方から得られる集まりで、部署や権限区分ではありません。「関係が密」という性質は、「同じ社員に適用できる」という業務判断を代行しません。
entitiesやrelationshipsのtext_unit_idsなどで原文に接続できますが、業務用の文書版・条項・適用期間を一貫して使う設計はアプリ側で補います。[^index-outputs]
claimsの抽出は任意かつ既定で無効です。[^index-dataflow] 抽出された主張に日時が付くことと、厳格な時点管理や業務ルールの承認は別です。
4.2 Local・Global・DRIFT・Basicの役割
公式の四つのモードは、コンテキストの集め方で区別できます。[^query-overview]
| モード | 文脈の集め方 | 検討する用途 |
|---|---|---|
| Local | entity中心に関連データと原文を回収 | 特定対象の調査 |
| Global | コミュニティレポートをmap-reduce | 全体傾向の整理 |
| DRIFT | コミュニティ情報から追質問・Localへ | 観点を広げる調査 |
| Basic | ベクトル検索の上位TextUnits | 単純な検索との比較 |
Localは、固定k-hopの経路探索と同義ではありません。 hopはエッジを一つ進む単位です。Localは、質問と意味的に関連するentityを入口に、関連entity、relationships、community reports、原文チャンクなどを集め、順位付け・絞り込みで入力上限へ収めます。[^local-search]
つまり、entity中心の検索とraw textの組み合わせです。後述する「承認済みの関係だけをたどる」「転居日を厳密に判定する」という本連載の設計とは区別します。
Globalは、指定階層のcommunity reportsから分担して部分回答を作るmapと、それを集約するreduceで答えます。[^global-search] 「規程群の共通テーマ」のような問いに検討価値があります。
community summaryだけを、個別規程の確定回答の法的・業務的根拠にしません。 転居と通勤申請がよく関連するという要約があっても、経路が変わらない人へ申請を要求する根拠にはならないためです。
DRIFTはDynamic Reasoning and Inference with Flexible Traversalの略です。コミュニティレポートから初期回答・追質問を作り、Local検索で掘り下げます。[^drift-search] 検索の追質問生成は、法的推論の保証や、利用者へ不足属性を確認する業務フローとは別です。
Basicは比較用の基本的なベクトルRAGです。[^query-overview] Basicに勝つことと、2.3節の強いベースラインに勝つことは別です。
4.3 自動抽出グラフと、承認済み業務モデルは同じではない
標準データフローでは、同じtitleとtypeのentityの説明をまとめます。[^index-dataflow] しかし、同名の「住所変更」が社員向けと取引先向けで別手続きなら、その統合は不適切です。
「Bring Your Own Graph」では既存グラフを所定の表へ変換し、コミュニティ生成などを利用できます。[^bring-your-own-graph] 承認済みオントロジーの意味や決定表が自動実行されるという意味ではありません。
本連載では自動抽出を下書きとし、原文照合、名寄せ、条件確認、業務担当者の承認を経て、確定判断に使える関係を管理します。
5. なぜ精度が改善し得るのか
以下は研究で確定した業務効果ではなく、本連載の設計仮説です。
| 失敗 | 変えること | 改善に必要な条件 |
|---|---|---|
| 代理申請の条項の欠落 | 代理条件から書類の根拠へ接続 | 正しい条件付き関係 |
| 同名の別手続きの混入 | 対象・業務範囲を含むIDで区別 | 正しい名寄せと質問属性 |
| 必要書類の列挙漏れ | 複数の根拠条項を回収 | 必須根拠を残す入力予算 |
| 例外と原則の分断 | 例外を対応する原則へ接続 | 適用条件と原文参照 |
因果の仮説は、「グラフが賢いから」ではありません。取り落としていた代理申請の原文を回収し、条件を確認して根拠パックに残すことで、委任状の列挙漏れを減らせる可能性があります。
根拠の取り落としの改善は回収率で確認します。回収率が同じでも、無関係な根拠の混入削減や順位の改善は別に評価します。必要な根拠がそろっても誤答するなら、混入した文脈、条件判定、生成も調べます。また、ID・版・条件の整備だけで通常RAGも改善する場合があります。データ整備の効果とグラフの効果を分けます。
6. 原論文は、どこまで確かめているか
6.1 対象は文書群全体の意味を捉える質問
原論文は、グラフ由来のコミュニティ要約で文書群全体の質問に答える方式を評価しています。2025-02-19改訂のarXiv v2では、「Behind the Tech with Kevin Scott」の公開対談書き起こしと、複数分野のニュース記事を使っています。[^graphrag-paper]
| 観点 | 論文の設定 |
|---|---|
| 規模 | 対談：約100万、ニュース：約170万トークン |
| 質問 | 想定利用者・タスクからLLMで各125問を生成 |
| C0〜C3 | 異なるコミュニティ階層の要約を利用 |
| TS | 原文を直接map-reduceで要約 |
| SS | ベクトル検索の原文を入力上限まで投入 |
論文の3.2節、4.1節の条件です。[^graphrag-paper] global sensemakingは文書群全体のテーマ・つながり・観点を把握することです。「この社員の期限は何日か」という一点の確定とは違います。
比較対象に、グラフなしで全体を要約するTSも含む点は重要です。一方、ハイブリッド・メタデータ・親文脈・リランカーを備えた事務QA向けベースラインとの比較は、この論文で済んでいません。
6.2 網羅性・多様性と、業務上の正答は別の指標
実験1は一意な正解文のない質問について、LLMを評価者にするLLM-as-judgeで二つの回答を比較しています。[^graphrag-paper]
| 論文の観点 | 見ているもの | 事務QAで追加する確認 |
|---|---|---|
| Comprehensiveness | 側面・詳細の網羅性 | 書類の過不足 |
| Diversity | 観点・洞察の多様性 | 対象外制度の非混入 |
| Empowerment | 理解・判断への支援 | 条件と根拠の追跡 |
| Directness | 具体的・明確な回答 | 期限・版・保留の正しさ |
実験1ではグラフを用いる全体検索がSSより網羅性・多様性で優位でしたが、empowermentの結果は混在し、directnessではSSが優位でした。全品質軸での勝利ではありません。[^graphrag-paper]
v2の実験2は、Claimifyで抽出した主張数を網羅性、主張のクラスタ数を多様性として追加検討しています。SSとの比較は概ね同じ方向ですが、ニュースの多様性はクラスタ化の閾値などで有意差が変わります。この追加指標では全体検索の条件同士やTSとの間に有意差は認められていません。[^graphrag-paper]
検証可能な主張の抽出は、原文と照合して正しいと確認することではありません。 主張数だけでは期限、適格性、申請先の正答や、不要な申請の非混入を保証できません。
6.3 本連載が引き継ぐものと、引き継がないもの
引き継ぐのは、構造を使って異なる文脈を作る発想です。論文自身も、他領域への一般化や捏造率比較などに追加検討が必要としています。[^graphrag-paper] 事務QAの正答率も、現在のLocal・DRIFTを含む全モードの優位性も、この結果だけでは主張できません。
7. 事務手続きQAへつなぐアプリ設計
7.1 質問に応じて検索経路を選ぶ
以降は標準機能の一覧ではなく、本連載のアプリ設計です。質問の種類に応じた経路選択をquery routingと呼びます。
| 質問 | 最初に検討する経路 |
|---|---|
| 届出の説明・様式 | 絞り込み付き通常RAG |
| 必要書類の連鎖 | 通常検索＋制約付き関係探索 |
| 規程群の共通テーマ | 許可範囲のGlobal型要約 |
| 条件不明で要否未確定 | 条件確認を先に行う |
「概要と私の締切」を求められた場合も、全体の説明と個別の確定判断を分けます。
7.2 許可済みの候補から、範囲を限定して探索する
次の制約を、通常検索・要約・追加検索を含む全経路に適用します。
- 許可済み候補集合：認証情報からACL（誰が何を閲覧できるか）と業務範囲を適用します。転居日で版を絞り、不明なら回答日で代用せず確認します。
- 対象の区別：entity disambiguationとして同名の別対象を区別します。社員向けと取引先向けの住所変更を混ぜません。
- 制約付き探索：bounded/typed traversalとして関係種別、条件、深さ、件数、時間を限定します。最短経路を正解とみなしません。
- 原文回収：関係の参照から同じ版・条項と前後の文脈へ戻ります。ここにもACLと時点制約を適用します。
- 再順位付け・根拠パック：要件、例外、期限の根拠をそろえます。長い一般説明のために必須条件を落としません。
- 追加質問・生成後の照合：不足条件を尋ね、確定部分だけを生成します。各主張、根拠、版、日付計算を照合し、矛盾は保留します。
トークンはLLMが処理するテキスト量の単位です。途中の要約・追質問にもトークンと呼び出し回数の予算を設け、予算超過で根拠が不足したら「該当なし」ではなく未確認とします。
最後の伏字だけでは、権限外の内容を読んだ要約やentityの説明からの漏えいを防げません。グラフ、要約、埋め込み、キャッシュにも制約を引き継ぎ、権限・適用版をまたぐ要約を安全に分離できなければ、許可された適用原文だけで作り直します。
7.3 根拠は「回答全体」ではなく「各結論」に対応させる
例の根拠パックを示します。document-versionは文書と版、sectionは条項です。本連載の説明用の列で、Microsoft GraphRAGの設定仕様ではありません。
| 結論・状態 | document-version / section | 確認した条件 |
|---|---|---|
| 住所変更届が必要 | MOVE/v2 / 第1条 | 対象社員の住居変更あり |
| 委任状も必要 | MOVE/v2 / 第3条 | 提出は代理人が行う |
| 期限は2026-10-11 | MOVE/v2 / 第4条 | 転居日2026-10-01、翌日から10暦日 |
| 通勤経路変更申請は未確定 | MOVE/v2 / 第2条 | 経路が変わったかは未確認 |
回答は「住所変更届と委任状が必要で、教材の期限は10月11日です。通勤経路変更申請の要否を確認するため、経路が変わったか教えてください」となります。各文の直近に対応する版・条項への出典を表示します。
「経路は変わっていない」と確認できれば、第2条の変更時のみというルールと確認済み属性から不要と判断できます。一方、エッジが見つからないだけでは不要・禁止・対象外としません。文書欠落、抽出漏れ、権限、探索打ち切りを区別し、権限外情報は漏らさず未確定と伝えます。
7.4 条件判定や期限計算を、経路発見と分離する
グラフの到達経路だけでは、提出義務は確定しません。業務担当者が入力条件と結論を確認できる決定表、必要ならルールエンジン、確定的な暦日計算を検索の外側に置きます。LLMには期限を推測させず、承認した条件で選んだ版と計算結果を説明させます。
同じ対象・適用期間の条項が衝突したら、新しそうな方を選ばず担当者へ戻します。グラフは矛盾を集める助けにはなっても、正式な規程を決める権限にはなりません。
8. 導入判断は、失敗分析と小さな比較実験から
8.1 改善しないケースと、新たに増える失敗
次は想定リスクであり、発生率の実測結果ではありません。
| 状況・失敗 | 起き得る問題 | 先に行う対策 |
|---|---|---|
| 一条項で答えられる | 構築・保守が利益に見合わない | 通常RAGを優先 |
| 表・条件節の取り込み不良 | ノイズをグラフで増幅 | 原文と取り込みを修正 |
| 誤ったentity merge | 別業務の書類や期限を混合 | IDと承認で区別 |
| エッジ欠落 | 必要書類が不要に見える | 根拠不在と要否を分離 |
| 過探索 | 無関係な候補が必須根拠を排除 | 型・条件・予算を制限 |
| 旧版・権限外情報の要約混入 | 原文の絞り込みだけでは残る | 派生成果物を再生成 |
| LLM処理・探索段階の増加 | 費用・待ち時間の増加 | 経路選択と総費用計測 |
接続数や登場頻度の高さは、例外の業務的重要性とは別です。よく現れる関係だけを優先して例外を落とさないようにします。
8.2 同じ条件で、グラフの追加価値を測る
この教材の範囲から、業務担当者が正解と根拠を確認した質問を作ります。本人・代理、経路変更、不明属性、版の境界日、権限を組み合わせて比較します。
| 構成 | 役割 |
|---|---|
| A：強い通常RAG | 2.3節の対策をそろえた基準 |
| B：Aに関係検索を追加 | 根拠の取り落としを測る |
| C：Bから特定の関係だけを外す | どの関係が改善に寄与したかを見る |
要素を外して寄与を測る比較がアブレーションです。原文、LLM、プロンプト、条件判定、権限、最終入力予算をそろえ、総トークン・途中の呼び出し・構築費用は別途計測します。
根拠の回収率、書類の過不足、期限・版の一致、出典の裏付け、追加質問・保留の妥当性を分けて測ります。事前に定めた質問全体を分母とし、保留増加で正答率をよく見せないようにします。権限外情報の露出、遅い応答、探索打ち切りも別に記録します。
8.3 規程変更後も、同じ根拠に戻れるか
v2の登録だけでは更新は終わりません。原文からチャンク、関係、entityの説明、reports、埋め込み、キャッシュへの依存関係追跡は本連載で追加する運用責務です。
| 変更時の対象 | 確認すること |
|---|---|
| 版の登録 | 転居日でv1・v2を選べるか |
| 派生成果物 | v2用の成果物に旧期限が混じらないか |
| 根拠参照 | 再生成後も版・条項へ戻れるか |
| 回帰確認 | 9月30日・10月1日の境界を守るか |
過去の転居にはv1が必要なので旧版を全削除しません。採用基準は、取り落としを減らし、誤断定を増やさず、費用・待ち時間・更新負担を引き受けられるかです。
9. まとめ
グラフ利用RAGの価値は、条件付きの関係から必要な原文を集めることです。Microsoft GraphRAGの研究結果を事務QAの正答率保証にせず、強い通常RAGとの差を測ります。時点・ACL・決定表・原文参照を整え、不明条件は質問して確認します。
次回の事務手続きQAの設計実践：オントロジーとGraphRAGを安全につなぐでは責務の分離と接続を具体化し、第4回の事務手続きQAの評価と運用：精度を測り、規程変更に追従するでは評価と変更管理を掘り下げます。
10. 参考情報
- Welcome to GraphRAG — インデックス・検索・プロンプト調整の公式入口
- From Local to Global: A Graph RAG Approach to Query-Focused Summarization — 評価条件と限界まで追える原論文
- Bring Your Own Graph — 既存グラフを接続する際の入力と前提
[^graphrag-home]: Welcome to GraphRAG — Microsoft（確認日: 2026-09-05）
[^graphrag-paper]: From Local to Global: A Graph RAG Approach to Query-Focused Summarization — arXiv（著者: Darren Edgeほか）（確認日: 2026-09-05）
[^hybrid-search]: Hybrid search using vectors and full-text search in Azure AI Search — Microsoft Learn（確認日: 2026-09-05）
[^semantic-ranking]: Semantic ranking in Azure AI Search — Microsoft Learn（確認日: 2026-09-05）
[^relational-joins]: 7.2. Table Expressions — PostgreSQL Global Development Group（確認日: 2026-09-05）
[^index-dataflow]: Indexing Dataflow — Microsoft（確認日: 2026-09-05）
[^index-outputs]: Outputs — Microsoft（確認日: 2026-09-05）
[^query-overview]: Query Engine 🔎 — Microsoft（確認日: 2026-09-05）
[^local-search]: Local Search 🔎 — Microsoft（確認日: 2026-09-05）
[^global-search]: Global Search 🔎 — Microsoft（確認日: 2026-09-05）
[^drift-search]: DRIFT Search 🔎 — Microsoft（確認日: 2026-09-05）
[^bring-your-own-graph]: Bring Your Own Graph — Microsoft（確認日: 2026-09-05）
