事務手続きQAの設計実践：オントロジーとGraphRAGを安全につなぐ

1. はじめに

事務手続きQAでは、関連条項を見つけても、本人と代理、適用条件、規程版を誤ると書類の取り寄せ直しや期限超過につながります。これが本記事の背景です。

目的は、第1回の意味の設計と第2回の検索を、実装できる責務・データ・APIへつなぐことです。「どの誤りを、どこで防ぎ、何で確かめるか」を示します。各回へのリンクは末尾にまとめました。

比較対象をベクトル検索だけに固定しません。たとえばAzure AI Searchは、全文・ベクトル検索、フィルター、semantic rankingを組み合わせられます。[^hybrid-search] こうした強い検索を出発点とし、特定製品を必須にしません。

2. 教材規程と、QAが扱う責任範囲を固定する

2.1 共通の架空規程

規程は次の範囲です。以降のID・条項ラベル・登録時刻は本記事の説明用で、規程への追加条件ではありません。

営業日への繰り延べや地域独自の添付などは追加しません。実務で必要なら、業務責任者が別の明示条件として定義します。

2.2 事務手続きの難しさを設計要件へ変える

以下は事務一般の実測結果ではなく、導入対象の確認項目と設計要件です。

似た名称・略称は別名として管理し、手続きIDを誤統合しません。属性の組合せはAND／OR／NOTを明示し、例外・但書と参照条項の適用範囲を出典へ結び付けます。

所管・組織・地域差は検索と判定の両方で制限します。添付の必要性を表すrequiresDocumentと、手順の前後を表すprecedesは別の関係です。

期限では業務日とシステム時刻を分け、権限・個人情報は検索前から保護します。不明・矛盾を断言で埋める損失を避けるため、質問・停止・有人確認も正常な結果にします。

2.3 案内・適否判定・実行を分離する

制度上の案内は、承認済み規程と申告条件に基づく説明です。個別の適否判定は、本人性や証拠書類を確認した判断、申請トランザクションの実行は業務システムへの登録・更新です。

本記事の対象は案内だけです。LLMに決裁・申請をさせません。判定や実行を追加するなら、専用API、実行権限、利用者の明示確認、二重登録防止、実行記録を別途設計します。

委任状は必要書類であって認可トークンではありません。「代理です」という申告から他人の情報を読む権限を付与してはいけません。

3. 意味・根拠・判定・生成を分ける

3.1 最小構成は4つの責務

図1の上段は公開前、下段は回答時です。承認済み根拠と判定結果だけを説明します。

意味・型はオントロジー、版・出典付きの主張はグラフ、適用判定と期限は決定表・計算器、説明はLLMが担当します。業務承認、規程の上書き、例外の補完、ACLの決定をLLMへ任せません。

オントロジーは共通語彙と関係の合意です。OWLではクラス・プロパティ・個体などで知識を記述できます。[^owl-primer] ただし採用は必須ではなく、RDBの型・外部キーやJSONスキーマでも始められます。

Microsoft GraphRAGは、知識グラフの抽出やコミュニティの階層・要約を検索に利用します。[^graphrag-overview] 本記事の承認、時点管理、認可、決定表、証拠パックは提案アプリの設計であり、Microsoft GraphRAGの標準装備として紹介するものではありません。

3.2 オープンワールドと入力検証は別物

OWLのオープンワールドでは、未記載の事実を偽とは扱いません。[^owl-primer] 教材でもrouteChangedの欠落を「経路変更なし」には変換しません。

一方、業務APIには「期限案内には転居日が必要」という検証が必要です。これは操作の完了に必要な入力と根拠の契約です。

SHACLはRDFのデータグラフを条件に対して検証する言語で、件数制約やデータ型を記述できます。[^shacl] 公開するルールの根拠の有無や日付型の検査に使えても、「10日が業務上正しい」と承認するものではありません。

OWL推論に集約せず、構造検証・不足確認・決定表を分けます。推論する場合も前提とルール版を追跡します。

4. 版・根拠・時点をデータモデルへ埋め込む

4.1 関係そのものを、根拠のある主張にする

「住所変更届 → 期限 → 10日」というエッジだけでは、適用時点と出典が消えます。次の要素を区別します。

関係の始点・終点も型で制約します。hasRuleは手続き版からルール、supportedByは主張から根拠、locatedInは根拠から原文条項へ進みます。添付を要するrequiresDocumentと、単なるmentionsは別物です。

以下は主張を表す独自スキーマで、製品設定ではありません。参照先のdeadline-v2には住居変更という条件、翌日起算・10暦日を保持します。原文・ハッシュ・承認記録も参照先に保存し、validTo: nullは終了日未定とします。

{
  "id": "a-deadline-v2",
  "snapshotId": "relocation-s2",
  "subject": "address-change-v2",
  "relationship": "hasRule",
  "object": "deadline-v2",
  "validFrom": "2026-10-01",
  "validTo": null,
  "recordedAt": "2026-09-03T09:00:00+09:00",
  "evidence": {
    "id": "ev-deadline-v2",
    "docVersion": "relocation-v2",
    "section": "s-deadline"
  },
  "approval": { "status": "approved", "recordId": "approval-s2" },
  "authority": "training-policy-owner",
  "acl": { "tenant": "training", "readScope": "relocation-guidance" }
}

参照先のルール・根拠・原文版にも、適用期間、公開集合、承認、ACLの対応が必要です。approvedはLLMではなく承認サービスが実際の記録に基づき設定します。

PROV-OはEntity、Activity、AgentやwasDerivedFromで由来・導出を表せます。[^prov-o] 原本・抽出候補をEntity、抽出・承認をActivity、責任主体をAgentに対応付けられますが、真正性や承認を保証する仕組みではありません。

4.2 業務日付とシステム時刻を混ぜない

適用期間は開始日を含み終了日を含まない区間で表します。v1のvalidToとv2のvalidFromは、ともに2026-10-01です。9月30日を落とさず、境界も重複させません。

公開日は周知の時点、施行・失効は業務上の効力、取込・登録はシステムが知った時刻、回答時刻は案内した時刻です。いずれも、この教材での版選択に使う転居日の代わりにはしません。

9月にv2を登録しても、9月30日の転居にはv1の14暦日を使います。回答が10月2日でも同じです。実務で申請日・受付日が基準なら、規程に従い基準項目を変えます。

recordedAtだけでは履歴再現には不十分です。訂正前を上書きせず、記録版の有効区間や置換関係、回答時のスナップショットを残します。「当時知っていた内容の再現」と「今の承認済み知識で過去の出来事を案内すること」を区別します。

過去再現は誤案内の継続ではありません。現在の案内は訂正し、監査記録とは分けます。過去に読めた人でも履歴アクセスを現在の権限で再評価します。

4.3 スナップショットは版番号の一致以上のもの

ルールだけをv2で絞っても、添付のエッジはv1、引用PDFは差し替え済み、要約は未承認、という混在は残ります。

公開マニフェストに手続き版、全主張・関係、条件表、原文、索引・要約の版を列挙します。回答時には根拠集合全体が同じ公開集合に属し、転居日に適用でき、承認済みで、現在の利用者に許可されることを確認します。

別紙の版も明示し、探索途中で「最新」へ切り替えません。回答中の索引更新では固定集合を維持するか処理をやり直し、権限取消しは出力直前にも反映します。

5. 取り込みは「抽出」と「公開」を分ける

5.1 原文を取り戻せる単位で保存する

分割前に原本、文書版、ページ、条項、表と但書の対応を保存します。OCR文字列から原画像の位置へ戻れるようにし、sourceHashは原本バイト列から計算します。変換後テキストのハッシュとは別です。

但書は、どの行・列にかかるか、どの条項を参照するかまで残します。期限、否定、例外、対象者はOCRスコアだけで承認せず、原文・原画像と照合します。

5.2 LLMの抽出結果は未承認候補

LLMが「転居なら経路も変更」という関係を抽出しても、教材には根拠がないため却下します。抽出結果は未承認候補です。

未記載はunknownとし、未抽出をfalseにしません。似た名前も所管・範囲・版・条件を確認するまで統合せず、重複候補を調査します。未解決の重複、誤統合、矛盾は公開を止めます。

文書間の優先順位は業務責任者が承認します。「新しいFAQだから規程に勝つ」と推測せず、正本同士の矛盾は検索順位で解消しません。

候補は回答用グラフ・索引から分離し、公開サービスが承認記録を確認して採用します。「未承認」の表示だけでは要約へ混入できます。抽出物を承認済み規程の代用にしません。

6. 条件と期限を、決定的に処理する

6.1 「不明」と「該当しない」を別の結果にする

真偽値にはtrue、false、unknownを使い、矛盾は評価前に別状態で返します。これは本アプリの約束で、OWLやDMN全体の評価仕様を置き換えるものではありません。

ANDは全条件、ORはいずれか、NOTは否定です。NOT unknownは真ではなく、true AND unknownも不明です。括弧を含む演算木と評価項目を保存します。

書類ごとに独立して決定し、「一つ必要なら全部必要」と集約しません。

決定モデルの標準にOMG DMNがあります。参照版を1.5に固定します。決定表のhit policyは複数行の一致の扱いを定め、Uniqueではルールが相互に排他的です。[^dmn-spec]

上表全体をUniqueにしてはいけません。住所変更届と委任状は同時に必要になり得るため、出力ごとに分けます。版選択など一意な判定の多重一致はエラーとし、不明・対象外も実装の評価仕様に合わせて明示します。

実務の例外・但書は優先順位も承認対象です。教材に例外を追加するのではありません。「先に見つかった行を採用」では取り込み順が規則になります。

6.2 期限は日付型で計算する

次は教材の暦日期限だけを計算するPython 3.10以降・標準ライブラリの実行例です。確定日を入力し、不正な形式・日付は例外で返します。実装時は承認済みルール版から条件を読み込みます。

import re
from datetime import date, timedelta


def deadline_for(move_date_text: str) -> tuple[str, date]:
    if not re.fullmatch(r"[0-9]{4}-[0-9]{2}-[0-9]{2}", move_date_text):
        raise ValueError("転居日はYYYY-MM-DD形式で指定してください")
    move_date = date.fromisoformat(move_date_text)
    if move_date < date(2026, 10, 1):
        version, days = "v1", 14
    else:
        version, days = "v2", 10
    return version, move_date + timedelta(days=days)


assert deadline_for("2026-09-30") == ("v1", date(2026, 10, 14))
assert deadline_for("2026-10-01") == ("v2", date(2026, 10, 11))
version, due = deadline_for("2026-10-01")
print(version, due.isoformat())

出力はv2 2026-10-11です。翌日の10月2日を1日目と数え、10日目が11日です。転居日へ10日を加えた上で、さらに1日を加算しません。

初日の算入、暦日／営業日、タイムゾーン、休日カレンダー版、例外を契約にします。教材は日付型なので時刻変換は不要です。時刻入力なら業務タイムゾーンで日付を確定し、UTC日付に無断で置き換えません。

営業日計算には承認された休日カレンダーと繰り延べ規則を使います。教材は暦日なので、休日を理由に10月11日をずらしません。未定義の締切時刻や遅延時の扱いも作り足しません。

7. 認可された検索から、証拠付き回答までをつなぐ

7.1 不足確認と停止を、通常の分岐として持つ

図2では不足条件を利用者へ、制度側の矛盾を業務窓口へ戻します。権限外では文書名・件数・存在を示さない共通応答を返します。

入口で認証を確認し、質問から意図・項目を抽出して不足を聞きます。検索前に、外部の認証・認可基盤から利用者・tenant・scopeを受け取り、対象日と制度を確定します。

質問は出力項目の依存関係から選びます。教材では転居日・経路変更・申請主体が分かればよく、住所そのものや氏名・社員番号をLLMへ渡す必要はありません。

認可前の質問は共通項目に限ります。非公開制度の項目名を示さず、制度固有の追加質問も認可された範囲で作ります。

7.2 typed APIで探索の境界を固定する

任意のSQL・Cypher・SPARQLやACLをモデルに作らせず、手続きID、条件型、関係、探索予算を限定するtyped APIを置きます。tenantと認可文脈はサーバーが注入します。

次の疑似コードは独自APIの責務を示し、Microsoft GraphRAGのAPI名ではありません。

guide(question, session):
  identity = auth.verify(session)
  history = loadCurrentAllowedUserFacts(identity, session.conversationId)
  intent, facts = extractTypedFacts(question, history)
  if conflict(facts): return clarify(facts)
  if missing(facts, intent): return askMinimum(facts, intent)
  ctx = auth.authorize(identity, intent, facts.targetDate)
  if denied(ctx): return nonDisclosingResponse()
  snap = pinApproved(ctx, facts.targetDate)
  hits = search.hybrid(ctx, snap, rewrite(intent, facts))
  paths = graph.follow(ctx, snap, hits, allowedTypes, budget)
  sources = originalSections(ctx, snap, paths)
  if not completeAndConsistent(sources, facts): return humanReview(ctx)
  result = evaluateRules(snap, facts, sources)
  pack = evidencePack(ctx, snap, facts, result, sources)
  text = llm.explain(pack)
  return checkedOutput(text, pack, auth.current(identity))

checkedOutputでは権限喪失なら非開示応答、不整合なら生成文を破棄します。根拠と権限を再確認できるときだけ固定文で案内し、失敗の種別を記録します。

query rewrite、hybrid検索、reranker、グラフ探索、追加検索、要約、キャッシュ、引用取得の全経路に同じ認可を適用します。ノードだけでなくエッジ・参照先・原文も制限し、モデルへ渡す前と出力直前に確認します。

関係は許可リストにし、各決定の必須根拠リストで回収漏れを検出します。探索上限で足りなければ不足とし、「検索で出なかったから不要」とは判定しません。

取得文書は情報であり命令ではありません。原文中の不正な指示にも、プロンプトだけでなくAPIの認可・操作制限で対処します。

7.3 LLMへ渡す証拠パック

証拠パックは、確定入力と由来、採用規程とスナップショット、判定・計算、原文範囲と引用ID、未確定項目、案内だけの制約をまとめた構造です。

生成後は書類、不要の理由、日付、規程版、申請主体を照合します。引用IDの実在だけでなく、該当条項がその結論を支えるかを検査します。重要項目は固定文にして、LLMに接続文だけを任せる方法もあります。

不採用理由も、開示可能なものだけをモデルへ渡します。権限で除外したID・題名・件数を送ると存在が漏れます。最後に回答だけをマスクする構成は避けます。

7.4 派生要約・会話履歴・キャッシュも同じ境界に置く

派生要約には全構成根拠の版と権限条件を引き継ぎます。一部の原文が読めるだけで全体要約を許可せず、権限範囲ごとに作るか、許可された根拠だけで再生成します。

キャッシュキーにはtenant、認可scopeとポリシー世代、スナップショット・ルール版、確定属性、基準日を含めます。必要なら休日カレンダー、プロンプト・出力スキーマの版も加え、質問文だけでは共有しません。

権限取消しや規程訂正時は無効化し、再認可します。キーにも生の個人情報を埋めず、必要属性だけを保護して保持します。

会話履歴も例外ではありません。再利用するのは利用者が確認した必要属性に限定し、利用者ID・tenant・会話IDに紐付け、現在もその項目を利用できるか照合します。別の利用者やtenantへ持ち越さず、属性の変更や矛盾があれば再確認します。疑似コードのloadCurrentAllowedUserFactsがこの責務を担います。

過去の回答・引用・会話要約を、そのまま次ターンの根拠やquery rewrite用の入力へ再投入しません。毎ターン、現在の権限と承認済みスナップショットで原文を取り直し、証拠パックを再構築します。要約を使う場合も、再利用可能な利用者属性だけから作り、以前の規程説明や失権情報を混ぜません。訂正・権限取消し後は以前のモデル入力も流用せず、新しい許可済み文脈に置き換えます。

トレースは相関ID、処理段階、版、判断項目、採否理由、計算器、エラー種別へ最小化します。個人情報を含む詳細は別のアクセス制御下へ置き、保持期間と削除責任を決めます。

8. 一つの相談を、根拠と最終回答まで通す

8.1 最初に聞き返すこと

以下は、2026-10-02に相談を受ける架空の会話例です。相談者には教材規程の閲覧権限があるものとします。

利用者: 引っ越しました。会社には何を、いつまでに出せばよいですか。

住居変更は分かりますが、転居日・経路変更・申請主体は不明です。経路変更を推定しません。

QA: ご案内に必要な点を教えてください。転居日はいつですか。通勤経路は変わりましたか。申請はご本人が行いますか、それとも代理の方が行いますか。住所そのものの入力は不要です。

利用者: 2026年10月1日です。通勤経路は変わりません。自分で申請します。

条件は住居変更あり、転居日2026-10-01、経路変更なし、本人です。「昨日」などの相対日付は会話の基準日・タイムゾーンで候補を作り、期限に影響するため確認します。

8.2 何を採用し、何を除外するか

原文位置には説明用のs-address、s-route、s-agent、s-deadlineを付け、画面から原文へリンクします。

「申請不要」は検索で見つからないからではなく、条項と「経路変更なし」からの判定です。v1も古そうだからではなく、適用期間外だから除外します。

未承認候補は診断例であり回答へ渡しません。診断記録も権限で保護します。

8.3 最終回答は、結論・条件・根拠を近づける

QAの回答例

ご申告の「2026年10月1日に転居・通勤経路は変更なし・本人申請」という条件では、住所変更届が必要です。〔教材v2：住所条項〕

通勤経路は変わっていないため、通勤経路変更申請は不要です。本人申請なので、代理申請用の委任状は不要です。〔教材v2：経路条項・代理条項〕

転居日が2026年10月1日以後なのでv2を適用します。翌日の10月2日から10暦日を数え、期限は2026年10月11日です。〔教材v2：期限条項〕

これは教材規程に基づく制度上の案内です。書類の提出や申請の承認は行っていません。

引用ラベルは架空教材内の表記です。実装では証拠パックの原文範囲へ結び付け、申告条件と規程から結論を追えるようにします。

8.4 分からないときの返答も設計する

条件不足には「期限を決めるため、転居日を教えてください」、発言の食い違いには「正しい転居日を確認させてください」と返します。

制度側の根拠不足・矛盾には「確実に案内できる根拠がそろいません。担当窓口で確認してください」と返し、利用者へ同じ質問を繰り返しません。

権限外では「この窓口ではご案内できません。利用可能な窓口をご確認ください」と返します。「特別規程はあるが読めない」と存在を示す返答もしません。

モデルの自信ではなく、必須項目、ルールの一意性、原文、現在の権限、重要項目の整合で分岐します。

9. 段階導入と、誤りに対応する検証

9.1 グラフが必要かを、強い比較対象で判断する

教材規模ならRDB・決定表・定型回答で十分です。文書が多くても根拠が局所的ならhybrid検索＋版・権限フィルター＋rerankerから始めます。条件・例外・添付の多段参照でつなぎ漏れが残る場合に、グラフの保守費用を払う価値を測ります。

原本・版の整理、強い検索、条件の構造化、承認付き関係探索、生成の順に広げます。一つの手続きから有人回答と並行比較し、止めるべきケースで止まれるかを先に確かめます。

9.2 設計を検証可能な仮説へ変える

改善率は未測定です。同じ質問・権限・規程版で強いRAGと比較し、誤り、確認往復、費用を測ります。

9.3 運用責任を決めてから広げる

業務責任者は意味・優先順位・正答を承認し、知識管理担当は原本と版、認可担当は権限、開発担当は探索・判定・生成の境界を維持します。公開停止と訂正案内の責任者も決めます。

NIST AI RMF 1.0は、GOVERN・MAP・MEASURE・MANAGEでAIリスク管理を整理する任意利用の枠組みです。[^nist-rmf] 責任・損失・測定・対応の整理に使えても、QAの精度向上や認証取得の証明ではありません。

改訂では条件表、エッジ、要約、キャッシュ、評価への影響も調べ、承認した公開集合へ切り替えます。過去の監査記録を保ち、現在の案内は訂正します。評価指標、回帰ケース、変更時の切替・復旧は第4回で詳しく扱います。

10. まとめ

意味・根拠・条件判定・言語化を分離し、根拠集合の版・適用日・権限をそろえます。教材では経路変更と申請主体を確認し、転居日2026-10-01ならv2、期限は2026-10-11です。

強いhybrid検索やRDBから始め、残る誤りに関係探索を追加します。質問・停止・有人確認も、誤案内を防ぐ正常な結果として実装します。

11. 参考情報

• Shapes Constraint Language (SHACL) — RDF構造検証の仕様と例
• About the Decision Model and Notation Specification Version 1.5 — 決定モデル仕様への入口
• AI Risk Management Framework — AIリスク管理の学習入口
• オントロジーで事務手続きQAを正確にする：意味・条件・根拠の設計 — 第1回、意味と条件の基礎
• GraphRAGで事務手続きQAを改善する：検索の仕組みと精度向上の条件 — 第2回、検索の仕組みと改善条件
• 事務手続きQAの評価と運用：精度を測り、規程変更に追従する — 第4回、評価と変更運用

[^hybrid-search]: Hybrid search using vectors and full-text search in Azure AI Search — Microsoft Learn（確認日: 2026-09-05）

[^owl-primer]: OWL 2 Web Ontology Language Primer (Second Edition) — W3C（確認日: 2026-09-05）

[^graphrag-overview]: Welcome to GraphRAG — Microsoft（確認日: 2026-09-05）

[^shacl]: Shapes Constraint Language (SHACL) — W3C（確認日: 2026-09-05）

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

[^dmn-spec]: Decision Model and Notation — Object Management Group（確認日: 2026-09-05）

[^nist-rmf]: Artificial Intelligence Risk Management Framework (AI RMF 1.0) — NIST（確認日: 2026-09-05）