事務手続きQAの評価と運用：精度を測り、規程変更に追従する

1. はじめに

試作が数問に正しく答えても、本番の品質は保証できません。事務手続きでは、書類の抜け、旧版の期限、代理申請の条件漏れが実際の手戻りにつながります。

この記事の目的は、オントロジーとGraphRAGによる改善を測定可能な仮説にし、規程が変わった後もその品質を維持する方法を示すことです。オントロジーは用語と関係の意味を定義するもの、GraphRAGはグラフを検索や回答用の文脈構成に利用する方式です。どちらも、それだけで正しさを保証するものではありません。

ここでは3種類の根拠を分けます。RAG評価研究が示す知見、事務手続きに合わせた本記事の設計提案、そして実行可能な小さな回帰テストです。実組織の文書・質問ログ・稼働システムは用いていないため、業務QAの正答率が何ポイント上がったという実測値は示しません。その数値を取得するための比較方法を説明します。

2. 何をもって「精度が高い」とするか

2.1 正しい回答は、文章ではなく複数の条件で決まる

連載共通の題材は、架空の「社内転居・通勤経路変更」です。以下は教材用の規程であり、法令や実在組織の規程ではありません。

「2026-10-01に転居した。通勤経路は変わらず、代理人が住所変更を申請する」という質問なら、少なくとも住所変更届、委任状、住所変更の期限2026-10-11、新版v2、通勤経路変更申請が不要である理由が整合しなければなりません。最後の「不要」は、経路が変わっていないという確認済み条件から導きます。検索で関連文書が見つからなかったから不要、ではありません。

一方、「引っ越しました。必要な手続きを教えてください」には、転居日・経路の変更有無・本人申請かどうかがありません。一般案内と必要最小限の追加質問が適切であり、特定の期限を断定する回答は不正解です。

2.2 検索成功と回答成功を別々に測る

RAGAsは、検索された文脈の関連性、文脈への回答の忠実性、生成された回答の品質を分ける評価を提案しています。ARESもcontext relevance、answer faithfulness、answer relevanceを分けて扱います。つまり、検索と回答を一つの平均点だけで評価しない考え方には研究上の裏付けがあります。[^ragas][^ares]

図の各段階には異なる正解があります。グラフに正しく登録されていても検索で落とすことがあり、必要な原文を取得していても条件判定や文章化で誤ることがあります。最初に壊れた段階を特定すると、プロンプト調整だけを繰り返す遠回りを減らせます。

事務手続き向けには、次の4層に分解する設計を推奨します。

これは本記事の評価設計です。Microsoft GraphRAGに事務規程用の判定器や公開判定機能が標準搭載されている、という説明ではありません。

3. 正解データを業務の境界から作る

3.1 正解は「模範回答の文章」だけにしない

業務担当者が、承認済みの原文を基に期待結果を作ります。LLMで質問候補を増やすことはできますが、生成された回答をそのまま正解にはしません。とくに、評価対象システムが作ったグラフから正解を生成すると、グラフの誤りを正解側へ複製してしまいます。

1ケースには、質問、確認済みの利用者属性、適用基準日、対象組織、認可コンテキスト、期待する動作、重要項目、必要根拠、許容する表現差を保存します。例えば次はデータ構造の例です。IDは教材用で、実在文書への参照ではありません。

{
  "case_id": "move-new-rule-proxy",
  "question": "10月1日に転居。経路は同じで、代理申請です。何が必要ですか",
  "confirmed_facts": {
    "move_date": "2026-10-01",
    "route_changed": false,
    "applicant_role": "proxy"
  },
  "expected_action": "answer",
  "critical_fields": {
    "address_form_required": true,
    "authorization_letter_required": true,
    "commute_application_required": false,
    "address_deadline": "2026-10-11",
    "policy_version": "v2"
  },
  "required_evidence": [
    "address-v2#requirement",
    "address-v2#deadline",
    "address-v2#proxy",
    "commute-policy#condition"
  ],
  "risk": "high"
}

ここでは年が既に会話で確認済みという前提です。年が未確認なら、質問文の「10月1日」を勝手に2026年と補うケースではなく、年の確認を期待する別ケースにします。認可情報も利用者の自己申告文ではなく、認証済みセッションから与えます。

原文に同等の根拠箇所が複数あるなら、唯一のチャンクIDだけを正解にせず、許容する根拠集合を定義します。そうしないと、チャンク分割を変えただけで正解が不正解になってしまいます。

3.2 多数の言い換えより、誤りやすい境界を優先する

「経路が変わる」から「変わらない」へ一語だけ変える対照例は、システムが条件を読んでいるかを観察するのに有用です。個人情報を評価用に複製せず、匿名化した実問と架空属性を組み合わせます。

3.3 学習・調整用と最終判定用を分離する

同じFAQの言い換えが調整用と最終判定用へ混ざらないよう、手続き・条項・質問テンプレートの系列単位で分割します。最終判定用のケースを見てプロンプトや同義語を調整しません。

改訂前のデータで調整し、改訂後の境界ケースで評価する「時間をまたぐ評価」も用意します。隠すのは正解ラベルであり、最新版の規程文書は比較する全システムへ提供します。

実際の問い合わせ分布を反映する集合と、低頻度でも危険な例外の集合は別々に報告します。「日常で役立つか」と「例外で壊れないか」を混ぜないためです。

4. どの設計が効いたかを比較実験で分離する

4.1 弱い検索だけを比較対象にしない

比較の出発点は、キーワード検索とベクトル検索を組み合わせ、版・組織・認可のフィルター、適切なチャンク、再ランキングを備えた構成にします。アクセス制御や適用版の選択は、安全な比較の共通前提です。GraphRAG側だけにそれらを追加し、差をすべてグラフの効果と呼ばないでください。

まずは次のような段階比較が実務的です。

段階比較だけでは相互作用を分離できません。詳しく調べるなら、語義定義あり／なしと関係探索あり／なしの4構成を、他の条件を固定して比較します。

また、運用で必須の認可や版整合を無効にする実験は行いません。外してよいのは改善要素であり、安全上の最低条件ではありません。

4.2 追加の人手と計算量も「差」として記録する

原文、質問、生成モデル、プロンプト、生成パラメーター、評価基準を固定します。検索結果に渡せるトークン数や待ち時間も合わせた比較と、各方式を実運用向けに調整した比較を分けます。前者は同じ予算内での効果、後者は品質と費用の選択肢を示すからです。

オントロジーやグラフを作る際に、人手で原文の矛盾を解消したり不足情報を補ったりしたなら、その作業も条件差です。同じ修正済み情報をB0へ与えた対照実験を行うか、「知識整備と検索方式を合わせた改善」と明記します。

記録するものは推論時の費用だけではありません。初回の抽出・承認、索引構築、関係の修正、改訂時の再構築、問い合わせの有人対応まで含めます。検索精度がわずかに改善しても、維持できない構成では本番品質を保てません。

4.3 グラフの品質は質問への影響で重み付けする

抽出されたエンティティや関係の適合率・再現率は、原文から人手で付与したラベルと比較します。ただし、すべての関係が同じ重要度ではありません。期限の適用条件を結ぶ辺の欠落と、補足用語の関連辺の欠落を同じ1件としてしか扱わないと、業務上の危険度が見えません。

「重要質問に必要な関係がすべてあるか」「異なる手続きを誤って同一化していないか」「各主張から承認済み原文へ戻れるか」を別指標にします。ある質問の必要根拠が3箇所なら、2箇所取得できてもそのまま確定回答してよいとは限りません。

5. 点数の定義と読み方

5.1 単一の総合点に隠さない

次の定義は、本記事で提案する評価指標です。ライブラリの同名指標と必ず同じ計算になるわけではないため、実装時には分母・対象・集計単位を固定します。

分母が0の指標は100%にせず「対象なし」とします。確認後に回答する複数ターンの評価では、最初の確認の適切さ、完了までのターン数、最終回答を別に記録します。

実質的な回答を返す割合と、その回答が誤る割合は併せて見ます。自信の低い質問を保留にすれば誤答率は下がりやすい一方、何も答えないシステムにもできてしまうためです。保留のしきい値は調整用データで選び、固定したしきい値を最終判定用データへ適用します。

5.2 原文への忠実性と、業務上の正しさは異なる

旧版の「14日以内」を忠実に要約した回答は、取得原文に対しては忠実でも、新版対象の利用者には誤りです。したがって、自動評価でfaithfulnessが高いだけでは採用できません。適用版、原文の権威、本人の条件も評価します。

ARESは、自動採点器の誤りを補正するため、人手ラベルを用いたprediction-powered inferenceを取り入れています。これは「LLM採点だけで十分」という研究ではありません。[^ares]

本設計では、期限・必須書類・版などの構造化項目は機械比較し、引用が主張を支えるか、説明が誤解を誘わないかを自動採点と人手確認で補います。業務担当者と別の評価者が独立に採点し、不一致は原文と判断基準に戻って解消します。採点者には可能な範囲で方式名を伏せ、長く流暢な回答を高く評価する偏りを抑えます。

採点モデル、採点プロンプト、基準例、判定不能の扱いも版管理します。同じ採点器でもモデル更新で点数が変わり得るため、システム改善による差と採点器変更による差を混ぜません。

5.3 少数の成功から安全性を断定しない

同じ質問に対するB0とB2の成否を対応付け、「どちらも正解」「B0だけ正解」「B2だけ正解」「どちらも不正解」を残します。方式間の差は、対応を保った再標本化などで不確かさも評価します。同一手続きの言い換えが多い場合は質問を独立とみなさず、手続きや条項の系列単位で扱う設計が必要です。

失敗0件も、真の失敗確率0を意味しません。独立・同分布の試行を仮定し、失敗0件を観測した場合、失敗率の片側95%信頼上限は 1 - 0.05^(1/n) です。これは二項分布に基づく区間の考え方から、失敗0件となる確率 (1-p)^n を0.05に置いて求められます。n=100なら約2.95%、n=1,000なら約0.30%です。[^binomial-interval]

都合よく選んだ質問や、ほぼ同じ言い換えへこの計算を機械的に適用してはいけません。認可の攻撃テストも、頻度推定ではなく禁止経路を止められるかの確認です。

6. 実行できる評価例：規程の境界と期限をテストする

6.1 実験の対象と、対象外を明示する

検索やLLMを外し、取得済みの規程に対する期限判定を切り出します。

入力は確認済みの転居日、出力は「回答」「日付の確認」「規程の確認が必要」のいずれかです。版の期間は開始日を含み終了日を含まない半開区間にします。v1の終了を2026-10-01にすると、9月30日はv1、10月1日はv2になります。

期限は「翌日を1日目としてN暦日以内」なので、転居日へN日を加算します。日付だけを扱う例としてUTCを計算上の固定基準に使い、端末のタイムゾーンによる日付のずれを避けます。実際の受付締切時刻、休日繰越、営業日、遡及適用、申請完了状態はこの例の対象外です。これらが規程にあれば別ルールと別ケースが必要です。

6.2 依存ライブラリなしの回帰テスト

次のコードを qa-deadline-regression.mjs として保存し、node qa-deadline-regression.mjs で実行できます。日付が不明・不正なら確認要求を返し、該当版が0件または複数なら推測で選ばず有人確認へ回します。

import assert from "node:assert/strict";

const rules = [
  { id: "v1", from: null, to: "2026-10-01", days: 14 },
  { id: "v2", from: "2026-10-01", to: null, days: 10 }
];

function decideDeadline(raw, policy = rules) {
  if (raw === null || raw === undefined || raw === "") {
    return { action: "clarify", reason: "missing_date" };
  }
  if (typeof raw !== "string" || !/^\d{4}-\d{2}-\d{2}$/.test(raw)) {
    return { action: "clarify", reason: "invalid_date" };
  }
  const date = new Date(`${raw}T00:00:00Z`);
  if (!Number.isFinite(date.getTime()) || date.toISOString().slice(0, 10) !== raw) {
    return { action: "clarify", reason: "invalid_date" };
  }
  const active = policy.filter(
    (r) => (r.from === null || r.from <= raw) && (r.to === null || raw < r.to)
  );
  if (active.length !== 1) {
    return { action: "escalate", reason: "policy_not_unique" };
  }
  const rule = active[0];
  date.setUTCDate(date.getUTCDate() + rule.days);
  return {
    action: "answer",
    version: rule.id,
    deadline: date.toISOString().slice(0, 10)
  };
}

const answer = (version, deadline) => ({ action: "answer", version, deadline });
const missing = { action: "clarify", reason: "missing_date" };
const invalid = { action: "clarify", reason: "invalid_date" };
const escalate = { action: "escalate", reason: "policy_not_unique" };
const overlapping = [...rules, { id: "bad", from: null, to: null, days: 12 }];

const cases = [
  ["old-boundary", "2026-09-30", answer("v1", "2026-10-14")],
  ["new-boundary", "2026-10-01", answer("v2", "2026-10-11")],
  ["month-end", "2026-10-25", answer("v2", "2026-11-04")],
  ["year-end", "2026-12-25", answer("v2", "2027-01-04")],
  ["leap-year", "2028-02-20", answer("v2", "2028-03-01")],
  ["missing", null, missing],
  ["empty", "", missing],
  ["wrong-format", "2026/10/01", invalid],
  ["impossible-date", "2026-02-30", invalid],
  ["wrong-type", 20261001, invalid],
  ["policy-gap", "2026-10-01", escalate, []],
  ["policy-overlap", "2026-10-01", escalate, overlapping]
];

for (const [id, input, expected, policy = rules] of cases) {
  assert.deepStrictEqual(decideDeadline(input, policy), expected, id);
}
console.log(`Regression: ${cases.length}/${cases.length} passed`);

const obsolete = rules.map((r) => (r.id === "v2" ? { ...r, days: 14 } : r));
assert.notDeepStrictEqual(decideDeadline("2026-10-01", obsolete), answer("v2", "2026-10-11"));
console.log("Mutation: obsolete v2 deadline detected");

これは承認済みでスキーマ検証済みの規程設定を入力する教材です。本番では設定自体の型・日数範囲・期間整合の検査、認可、監査記録も必要です。型が正しいことと業務内容が正しいことは別なので、期待期限はこの関数で作らず、原文から独立に用意します。

2026-09-05にNode.js 24.2.0で実行した出力は次のとおりです。

Regression: 12/12 passed
Mutation: obsolete v2 deadline detected

最後の確認では、意図的にv2の日数を旧版と同じ14日へ壊しています。単に正常ケースが通るだけでなく、少なくともこの誤りを期待値との比較で検出できることを確かめています。

12/12は期限判定部品の、この12ケースに対する結果です。 自然言語からの日付抽出、グラフ検索、引用、委任状、経路変更、権限分離、回答文の品質は測っていません。したがって「GraphRAGの正答率100%」と読み替えることはできません。

6.3 実際のRAG評価へ接続する

実システムでは、ケースを同じAPIへ入力し、回答文だけでなく、検索された原文ID、採用した規程版、判定結果、引用対応を保存します。上のような期待値との比較を重要項目に適用し、回答文が構造化結果から逸脱していないかも確認します。

原因を切り分けるため、正解の原文集合を直接生成器に渡す評価も追加します。それで正しく回答できるなら検索側、正解の判定結果まで渡しても期限を書き換えるなら言語化側に問題がある、と調査を絞れます。ただし、この「正解を与えた評価」の点数を通常運転の精度として報告しません。

最終的には同じケース集合でB0〜B3を実行し、5章の指標、遅延、費用、重大失敗の内訳を比較します。ユーザー満足度は補助指標であり、利用者自身が気付けない誤った期限の検出には代わりません。

7. 規程変更は「更新日時」一つでは扱えない

7.1 公開、適用、取得、回答の時刻を分ける

例えば、v2を9月に事前登録し、10月1日の転居から適用するとします。以下はすべて架空の運用例です。

10月に質問された9月30日の転居には、教材ではv1を適用します。新しい文書だからv2を選ぶ、という検索順では不十分です。逆に、v2が取得済みでも、その転居日への適用条件を満たしていなければ採用しません。

適用期間とシステム記録期間を別々に保存する設計なら、「現在の正しい規程で、当時の事案を判断する」と「当時システムが知っていた内容で、過去の案内を再現する」を区別できます。訂正が入っても、過去の版を上書き消去しないことが重要です。

7.2 変更の種類によって、影響範囲を変える

オントロジーの語義変更は、文書1件の修正より影響が広くなります。「代理人」の定義を変えれば、同じ概念に結び付く複数手続きの条件が変わり得るからです。データの内容、意味の定義、処理プログラムを別々の版で追跡します。

8. 原文から派生物まで依存関係を追う

8.1 変更された文書の埋め込みだけを更新しない

グラフ検索には、文書から抽出した主張、関係、エンティティの説明、要約などの派生物があります。Microsoft GraphRAGの索引処理でも、チャンクからグラフを抽出し、コミュニティ検出、レポート生成、埋め込みへ進む依存関係があります。[^graphrag-index]

元の期限が14日から10日へ変わったのに、コミュニティ要約や回答キャッシュに14日が残れば、更新済み文書を持つシステムでも誤案内します。

図の要点は、変更された文書と同じファイル名だけを探すのではなく、その内容を利用した成果物を追うことです。依存範囲が判断できない場合は、対象領域の再構築を選びます。

W3CのPROV-Oは、生成・利用・派生・責任者などの来歴を表現する語彙を定義しています。これを参考に、原文から抽出結果や要約への由来を保存できます。ただしPROV-Oを採用しただけで更新が自動伝播するわけではなく、影響分析と再構築処理は実装が必要です。[^prov-o]

8.2 依存関係の完全性が、差分更新の前提になる

例えば各成果物に、入力の文書版・ハッシュ、条項ID、生成処理の版、承認状態、適用条件、権限を対応させます。変更された条項から逆向きに依存先をたどり、失効させるものと再生成するものを決めます。

一つのエンティティ説明が複数文書を集約している場合、文書Aの削除に合わせてエンティティ全体を消すのも、何も変えないのも不適切です。残った承認済みの根拠から説明と関係を再計算します。

コミュニティ分割や上位要約を使う構成では、小さな辺の変更が広い範囲へ影響することがあります。「変更ノードの1-hopだけを更新すれば十分」とは決めません。利用する実装・設定で影響範囲を確認し、依存の追跡が完全でなければ、その領域のグラフ・要約を再構築して文書検索との整合を取り直します。

廃止・削除・権限剥奪は追加と同じくらい重要です。元文書の権限を変えても、以前の要約、埋め込み由来の検索結果、会話履歴、引用表示、共有キャッシュから内容が見えてはなりません。過去の案内を再現する監査でも、現在の監査権限でアクセスを判断します。

9. 公開、切替、失敗時対応を手順化する

9.1 新旧規程を含む、一貫したリリースを作る

変更時の推奨手順は次のとおりです。これは本記事の運用提案であり、特定製品がこの全工程を自動化するという意味ではありません。

1. 原文の差分を取得し、意味・適用日・対象・承認・権限の変更を業務担当者が分類する。
2. 未承認領域で語義、ルール、関係、来歴を更新し、矛盾や期間の重複・空白を検査する。
3. 依存先の文脈、要約、索引を再構築し、キャッシュ失効計画を作る。
4. 改訂前後、境界日、不明条件、権限違いを含む回帰評価を行う。
5. 未解決の重大失敗がないことと、品質・遅延・費用の採用条件を責任者が承認する。
6. 同じリリースIDに結び付いた成果物を公開し、限定した範囲で監視する。
7. 異常時は影響のある手続きの確定回答を止め、確認窓口へ切り替える。

リリースには新旧規程が共存します。新リリース＝全事案へ新規程適用ではなく、同じリリース内で転居日ごとに版を選びます。

文書索引、グラフ、ルール、要約を一つのリリースマニフェストで対応付け、処理開始時に使うスナップショットを固定します。ベクトル索引は新版、ルールは旧版という混在を防ぐためです。権限剥奪は別で、処理中でも最終出力前に現在の認可を再確認する設計にします。

9.2 キャッシュ失効と切替競合もテストする

キャッシュのキーには、質問文だけでなく、組織・認可スコープ・認可ポリシー版・確認済み属性・適用基準日・知識リリースIDなど、答えを変える要素を含めます。個人情報をそのままキーへ露出させず、必要な範囲を識別できる形にします。

それでもキー設計だけでは十分ではありません。権限変更や誤情報の撤回では、古いキーの結果が参照されないよう失効させます。会話が切替前に始まり切替後に続いた場合、必要な条件と根拠を取り直すか、旧応答が使えないことを明示する方針を決めます。

一斉失効時の負荷、再構築が失敗した状態、片方の索引だけ更新された状態も試します。失敗したときに古い回答を無条件で返す「成功に見えるフォールバック」は、事務手続きでは危険です。

9.3 規程を巻き戻せない場合の停止策を用意する

ソフトウェアの不具合なら、正しい現行規程を使える以前の実装へ戻せる場合があります。しかし10月1日以後の転居に新版が必要なのに、システムを戻して旧版14日の回答を再開するのは、業務的にはロールバックではなく誤案内です。

現行規程で正しく案内できる構成がなければ、該当手続きの確定回答を一時停止します。原文の閲覧権限を確認したうえで正しい参照先と担当窓口を示し、対象外の手続きは継続できます。停止する単位と責任者を、障害前に決めておくことが重要です。

10. 本番で品質を維持するための観測と責任

10.1 数字と失敗の中身を両方見る

本番では、回答可能率、確認の回数、有人引継ぎ、訂正報告、原文取得失敗、適用版の不一致、更新から公開までの時間、遅延の中央値・上位パーセンタイル、費用を追います。問い合わせが減っただけで成功とは判断しません。利用者が諦めて別経路へ移った可能性もあるためです。

高リスクな手続き、改訂直後、代理申請、不明条件の多い質問を重点的に点検します。出力全体を無期限に保存せず、調査に必要な質問ID、使用版、根拠ID、判定経路を中心に保存し、アクセス権と保存期間を設定します。

誤案内を見つけたら、同じ根拠やキャッシュを使った応答を調べ、必要なら利用者へ訂正を伝えます。影響分析のための来歴を持つことは、回答に引用を付ける以上の意味があります。

10.2 承認責任をモデルへ移さない

採用条件は評価後に都合よく緩めず、事前に決めます。例えば認可違反と既知の重大誤案内は未解決のまま公開しないことを必須にし、正答到達率・不確かさ・遅延・維持費については業務の許容水準を定めます。「観測0件」は、その評価範囲での結果として扱います。

NIST AI RMF Playbookは、Govern、Map、Measure、Manageの4機能に沿ったリスク管理の提案をまとめています。ただし全項目を機械的に実施するチェックリストではなく、用途に応じて選ぶ任意のガイダンスです。本記事の責任分担や公開判定も、自組織の損失・権限・運用能力に合わせて具体化してください。[^nist-playbook]

11. まとめ

オントロジーとGraphRAGの価値は、用語の混同、必要根拠の取りこぼし、条件の誤結合など、どの誤りを減らせたかで判断します。そのためには、業務担当者が承認した正解データ、強い比較対象、段階別の評価、重大項目と引用の検査が必要です。

本記事の12ケースは、規程版と期限判定を検査する最小の出発点です。実システムの精度を主張するには、検索・生成・認可を含む同一条件での評価を追加しなければなりません。

そして、規程変更後の正しさも設計の一部です。原文から派生物への来歴、新旧版の適用条件、一貫したリリース、キャッシュ失効、誤回答を止める判断を用意して初めて、「初日に正しい」から「変更後も正しい」QAへ進めます。

12. 参考情報

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems — 自動採点を人手ラベルで補正する評価設計
• NIST AI RMF Playbook — 用途とリスクに応じた評価・運用責任の整理
• オントロジーで事務手続きQAを正確にする：意味・条件・根拠の設計 — 連載第1回、語義・関係・条件の基礎
• GraphRAGで事務手続きQAを改善する：検索の仕組みと精度向上の条件 — 連載第2回、検索方式と研究結果の読み方
• 事務手続きQAの設計実践：オントロジーとGraphRAGを安全につなぐ — 連載第3回、評価対象となるシステムの責務分担

[^ragas]: RAGAs: Automated Evaluation of Retrieval Augmented Generation — Association for Computational Linguistics（確認日: 2026-09-05）

[^ares]: ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems — Association for Computational Linguistics（確認日: 2026-09-05）

[^binomial-interval]: 7.2.4.1. Confidence intervals — NIST/SEMATECH（確認日: 2026-09-05）

[^graphrag-index]: Indexing Architecture — Microsoft（確認日: 2026-09-05）

[^prov-o]: PROV-O: The PROV Ontology — W3C（確認日: 2026-09-05）

[^nist-playbook]: NIST AI RMF Playbook — NIST（確認日: 2026-09-05）