1. はじめに
「規程は検索できるのに、回答が業務上は間違っている」。事務手続きQAには、検索の関連性だけでは解決できない問題があります。
RAG（Retrieval-Augmented Generation、検索拡張生成）は、検索した情報を材料に回答を生成する構成です。[^rag-paper] しかし、関連する文章が見つかっても、「誰について」「どの条件で」「いつの規程を使うか」は未確定かもしれません。本記事の目的は、その判断に必要な意味を整理することです。
例として、次の相談を考えます。
10月1日に引っ越しました。住所の手続きは何が必要ですか。代理人に提出してもらう予定です。
本連載では、 架空の「社内転居・通勤経路変更」 を共通の教材にします。法令や実在組織の規程ではありません。氏名・住所などの実在個人情報も使いません。
| 教材で確認できたこと | 必要な手続き・対応 |
|---|---|
| 住居が変わった | 住所変更届が必要 |
| 通勤経路も変わった | 別の通勤経路変更申請が必要 |
| 通勤経路が変わっていない | 通勤経路変更申請は不要 |
| 通勤経路が変わったか不明 | 追加質問する |
| 代理人が提出する | 委任状も必要 |
住所変更と通勤経路変更は関連しますが、同じ出来事ではありません。また、代理提出に委任状が必要でも、それだけで受付可能だとまでは決まりません。
冒頭の「10月1日」は年も未確定です。勝手に補わず確認します。後の例は転居日が 2026-10-01と確認済みの案件です。
2. オントロジーを5つの要素で理解する
2.1 概念・クラス、個体、属性、関係、公理
オントロジーは、何を区別し、関係をどう解釈するかを明示したものです。業務担当者と実装者が共有する「意味の設計」と考えてください。
OWLは、この知識をクラス・プロパティ・個体・公理で表し推論する言語です。[^owl-primer] オントロジーという設計と、OWLという言語は同じではありません。
| 要素 | 意味 | 教材での例 |
|---|---|---|
| 概念・クラス | 意味の単位・個体を分類する種類 | 案件、手続き、提出物種別、人 |
| 個体 | 識別する具体的な対象 | 相談001、台帳上の住所変更手続き |
| 属性 | 日付・文字列・数値などの値 | 案件の転居日 |
| 関係 | 対象同士の結び付き | 案件の対象者、ルールの根拠条項 |
| 公理 | 成立すると明示する論理的主張 | 住所変更案件は案件の一種 |
個体はインスタンスとも呼びます。「委任状という提出物種別」は台帳上の個体として表せますが、「相談001で提出された委任状ファイル」とは別です。書類の種類の定義と、提出済みという事実を混ぜないことが重要です。
属性と関係をまとめてプロパティと呼ぶことがあります。OWLでは、個体から値へのデータプロパティと、個体同士を結ぶオブジェクトプロパティを区別します。[^owl-primer]
概念をすべてOWLのクラスにする必要はありません。用語集の見出しとしての概念と、案件を分類するクラスでは用途が違います。
2.2 用語辞書・タクソノミー・DBスキーマ・ナレッジグラフとの違い
これらは対立する選択肢ではなく、重なりを持つ設計・表現です。
| 仕組み | 主に明示するもの | 教材での用途 |
|---|---|---|
| 用語辞書 | 語の説明・別名・利用範囲 | 転居と引越しの用語を整理 |
| タクソノミー | 分類の階層 | 社内手続きの中に人事手続きを分類 |
| DBスキーマ | 項目・型・キー・整合性制約 | 案件や規程版の保存 |
| ナレッジグラフ | 対象と関係を結んだ知識 | 案件・ルール・根拠を結ぶ |
| オントロジー | 概念・関係の意味や公理 | 案件と手続きの区別を共有 |
階層図では「種類」「所属」「部分」のどれを結んだ線かを明記します。所属や部分の関係を、クラスの継承へ置き換えると意味が変わります。
本記事のナレッジグラフは、実体データやルールを関係で結んだ表現を指します。厳密なOWLオントロジーは必須ではありません。
RDBでも、案件・手続き・規程版・根拠条項をキーで結合して同じ情報を取得できます。 既存のスキーマと業務仕様に意味が定義されていれば活用できます。グラフDBへの移行だけで意味は増えません。採用理由は、意味の共有や変更管理のしやすさ、運用可能性です。
2.3 意味モデル、実体データ、判定を分ける
図は住居と経路の判定を抜粋しています。上段は意味の定義、中段は相談001の記録、下段は事実と承認済みルールの照合です。関係があることと、申請条件を満たすことは別です。
これは責務の区別であり、データベースを3台置く意味ではありません。OWLでも個体の事実を表せます。
3. 質問から逆算して意味を設計する
3.1 Competency questionsで必要な範囲を決める
先に「この知識で答えたい質問」を書きます。これが competency questions です。質問から範囲を定め、後で情報が十分かを確かめる方法で、不要な概念の作り込みを避ける助けになります。[^ontology-development]
| 質問 | 必要な区別 | 不足時の対応 |
|---|---|---|
| 引越しで何が必要か | 住居変更と経路変更 | 経路変更を確認 |
| 代理提出だと何が増えるか | 対象者・提出者・役割 | 提出者の役割を確認 |
| いつまでに出すか | 転居日・適用版・起算方法 | 年月日を確認 |
| なぜ委任状が必要か | 条件付きルールと原文 | 根拠なしで断定しない |
| この規程を使えるか | 対象範囲と閲覧権限 | 権限外の根拠を除外 |
入力、期待する結論、根拠、不足時の振る舞いを一緒に記録すれば、検索設計と評価問題の原型になります。
「本人」「代理人」は恒久的な人の分類ではなく、その案件の対象者・提出者との関係として表します。同じ人でも、別の案件では役割が変わります。
3.2 同義語をまとめ、同じ名前の別物を分ける
語義の正規化では、質問中の表現を業務上の識別子に結び付けます。単なる文字列置換ではありません。
| 表現 | 扱い | 理由 |
|---|---|---|
| 引越しと転居 | 社内手続きでの別名候補 | 同じ住居変更を指す |
| 組織の異なる住所変更届 | 別の識別子 | 提出先・条件・根拠が違う |
| 住所変更と通勤経路変更 | 関連する別概念 | 一方から他方は決まらない |
識別子は urn:aqa:procedure-address-change のように表示名から独立させます。ただし、名称変更か手続きの廃止・新設かは業務担当者が判断します。曖昧な表現は組織や目的を確認し、別名を他制度まで無条件に広げません。
似た名称を owl:sameAs で統合するのも危険です。これは「似ている」ではなく同一の個体だという主張で、別の対象の情報まで同一のものとして扱われ得ます。[^owl-primer]
4. RDF・OWL・SKOS・SHACLの役割を混同しない
4.1 表現、意味、語彙、検証は別の役割
各技術を、何を担当するかで分けます。
| 技術 | 主な役割 | 担当しないこと |
|---|---|---|
| RDF | 主語・述語・目的語の三つ組[^rdf-concepts] | 業務意味の自動決定 |
| RDFS | クラス階層・domain/range[^rdf-schema] | 必須入力の検査 |
| OWL | 公理・含意・整合性[^owl-primer] | 対話や業務の実行許可 |
| SKOS | ラベル・概念の階層・関連[^skos-primer] | 文脈による自動曖昧性解消 |
| SHACL | データとshapeの照合[^shacl] | 原文の真偽の保証 |
SKOSの prefLabel は優先ラベル、altLabel は別名、broader はより広い概念との関係です。概念間の階層と、OWL/RDFSのクラス包含は別です。[^skos-primer]
次は案件と手続きの関係をTurtle形式で表す例です。a は所属を表す rdf:type の省略記法です。[^rdf-turtle] urn:aqa: は教材用の識別子です。
@prefix ex: <urn:aqa:> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
ex:Case a owl:Class .
ex:AddressChangeCase a owl:Class ;
rdfs:subClassOf ex:Case .
ex:Procedure a owl:Class .
ex:targetsProcedure a owl:ObjectProperty ;
rdfs:domain ex:Case ;
rdfs:range ex:Procedure .
ex:procedure-address-change a ex:Procedure .
ex:case-demo-001 a ex:AddressChangeCase ;
ex:targetsProcedure ex:procedure-address-change .
相談001は住所変更案件なので、案件でもあると解釈できます。しかし、期限や委任状の条件は書いていません。未定義の業務条件が自動的に発見されるわけではありません。
4.2 Open-worldでは「未知」は「偽」ではない
OWLの open-world assumption（開世界仮定） では、未記述の事実を一律に偽と見なしません。[^owl-primer] 経路変更の記録がなくても、変更あり・なしの両方があり得ます。検索漏れ、未入力、権限による非表示を「変更なし」に変換してはいけません。
「案件には対象者が少なくとも1人存在する」と表しても、名前が未入力ならただちに矛盾、とはなりません。存在するが未記録と解釈できるためです。必須入力チェックとは違います。[^owl-primer]
OWLは明示的な否定や排他関係も表せますが、未記述から否定を作ることとは別です。[^owl-primer] 「許可が見つからない」も「禁止されている」ではありません。アプリが権限確認まで操作を許可しないのは、安全方針であって規程の禁止を推論したことではありません。
4.3 domain/rangeと非単一名仮定の落とし穴
targetsProcedure のdomainが Case、rangeが Procedure なら、その関係の主語は案件、目的語は手続きと推論され得ます。型が未記載だから拒否する入力検証ではありません。 他の公理と衝突すれば不整合になる場合はありますが、それは必須入力チェックとは違います。[^owl-primer]
OWLは unique-name assumption（単一名仮定）を採りません。別々のIDが同じ個体を指す可能性を排除しないため、必ず別人だと主張するなら異なる個体であることを明示します。[^owl-primer] 逆に、別人と分からないから同一人物だ、とも決まりません。
本人・代理人の確認は、識別子の違いやOWLの同一性推論に代行させず、信頼できる本人確認・委任確認の結果を案件に結び付けます。
4.4 SHACLとアプリで、検査する範囲を閉じる
SHACLでは、データグラフを、満たすべき条件を記述したshapeに照らして検査します。件数は sh:minCount・sh:maxCount、型は sh:datatype、値の集合は sh:in などで指定します。[^shacl]
| 対象 | 検査する条件の例 |
|---|---|
| 転居日 | 必須、値は1つ、日付型 |
| 経路変更の有無 | 値は最大1つ、真偽値型 |
| 提出者の役割 | 定めた区分のいずれか |
| ルールの根拠 | 根拠への関係が1つ以上ある |
経路変更を必須にしないのは、未確認のまま対話を続けるためです。アプリが追加質問し、「検査に通ったが回答には情報不足」という状態を扱います。
閉世界的な検査は、対象の入力・グラフ・条件を限定して不足や違反を検出することです。世界全体の未知を偽に変える意味ではありません。sh:closed も、指定外のプロパティを制限する機能であり、欠落を否定に変換するスイッチではありません。[^shacl]
推論結果を検査に使うかは実装・設定にも関係します。対象ノード、グラフ、推論設定を固定します。[^shacl] RDBならDB制約やアプリ検証も選択肢ですが、どの方式でも形式検査と業務判断は別です。
5. 業務条件は決定表で明示する
5.1 「必要」「不要」「情報不足」を分ける
住居変更が確認できた案件について、条件ごとの結論を定めます。
| 判定項目 | 条件 | 結論 |
|---|---|---|
| 住所変更届 | 住居変更あり | 必要 |
| 通勤経路変更申請 | 経路変更あり | 必要 |
| 通勤経路変更申請 | 経路変更なし | 不要 |
| 通勤経路変更申請 | 経路変更が未確認 | 追加質問 |
| 委任状 | 代理提出 | 必要 |
| 委任状 | 本人提出 | 教材の代理ルールでは不要 |
| 委任状 | 役割が未確認 | 追加質問 |
「不要」は条件を確認した結論であり、検索結果が空だから返す値ではありません。
「変更あり」と「変更なし」の両方が登録された状態は、未確認でなく矛盾として確認へ回します。真・偽・未確認・矛盾を分けるのは本記事のアプリ設計案であり、OWLやSHACLが自動でこの4状態のUIを提供するわけではありません。
5.2 適用する版は「回答した日」ではなく「転居日」で選ぶ
教材の期限は、次のように定めます。
| 版 | 対象となる転居日 | 届出期限 | 境界日の例 |
|---|---|---|---|
| v1 | 2026-09-30以前 | 翌日から14暦日以内 | 9/30転居なら10/14まで |
| v2 | 2026-10-01以後 | 翌日から10暦日以内 | 10/1転居なら10/11まで |
「暦日」はカレンダーの日数です。教材に休日繰越は設定していません。実在規程では、起算日・時刻・休日・例外を別途確認してください。
適用基準日は転居日で、システムの取得時刻や回答時刻ではありません。10月以降に9月30日の転居を質問されてもv1を選びます。最新文書だけの検索では対応できません。
次はPython 3.10以降、標準ライブラリだけで動く期限計算の例です。deadline.py に保存し python deadline.py で実行できます。入力の年月日を確認して date に変換した後に呼び出します。
from datetime import date, timedelta
def deadline_for_move(move_date: date) -> tuple[str, date]:
if type(move_date) is not date:
raise TypeError("move_date must be a calendar date")
version, days = (
("v1", 14)
if move_date <= date(2026, 9, 30)
else ("v2", 10)
)
return version, move_date + timedelta(days=days)
print(deadline_for_move(date(2026, 9, 30)))
print(deadline_for_move(date(2026, 10, 1)))
結果は v1 / 2026-10-14、v2 / 2026-10-11 です。翌日が1日目なので14日または10日を足します。必要書類・代理権・受付可否・期限後の扱いは判定しません。版の選択と計算を生成から分離する例で、本番の多数の規程をコードに埋め込む推奨ではありません。
5.3 優先順位・否定・例外を「暗黙」にしない
LLMへルールを渡すだけでは優先順位は決まりません。意思決定を表す標準のDMN（Decision Model and Notation）や、業務担当者が読める決定表を使えます。[^dmn] 以下は設計方針で、実行可能なDMNモデルではありません。
| 論点 | 明示する方針 |
|---|---|
| 適用版 | 転居日で選択し、複数一致・空白期間は保留 |
| 否定 | 確認済みの「経路変更なし」に不要ルールを適用 |
| 未確認 | 不足条件だけを質問し、確定部分は答える |
| 複数の義務 | 独立した必要物を集め、最初の1件で終えない |
| 例外 | 条件・上書き対象・適用期間・根拠を指定 |
| 矛盾 | 担当者確認へ回し、LLMに選ばせない |
教材には上書き例外は設定していません。将来例外を追加する際は、承認された例外が、どの原則ルールのどの結論に優先するかを明記します。OWLに公理を足しただけで「新版が旧版を無効化する」「特例が自動的に勝つ」という業務方針は得られません。
6. 条件・版・根拠を持つ知識として管理する
6.1 単純な関係だけでは条件が落ちる
「住所変更には委任状が必要」という無条件の関係では、本人提出にも誤適用されます。条件と結論を一まとまりのルールノードにする設計例を示します。
| 項目 | 教材用の値・内容 |
|---|---|
| ルールID | rule-delegation-v2 |
| 対象手続き | 社内の住所変更 |
| 条件 | その案件の提出者の役割が代理人 |
| 結論 | 委任状が必要 |
| 規程版・適用期間 | v2、転居日が2026-10-01以後 |
| 根拠 | 教材規程v2の代理提出を定めた原文箇所 |
| 承認・責任 | 承認状態、承認記録、保守責任者 |
| 権限 | そのルールと根拠を閲覧できる範囲 |
ルールIDから文書ID・版・原文位置まで辿れるようにします。条件を実行するのはアプリやルールエンジンです。ノードの保存だけでOWLの推論規則になるわけではありません。
個別の事実には、誰から得たか、どの案件か、いつ確認したかを結び付け、assertion（主張）ノードとして管理する方法があります。利用者の申告、確認済み事実、規程の一般条件を混ぜません。
PROV-Oでは prov:wasDerivedFrom で派生元を表せ、生成や責任に関わる主体も記述できます。[^prov-o] ただし、出所の記録は、内容の正しさ・業務承認・閲覧許可の証明ではありません。
適用期間・取得時刻・承認・権限は別々に管理します。規程の生成時刻を、対象となる転居日の開始日として使わないでください。
6.2 LLMの抽出結果は未承認候補に留める
図の未承認候補は、回答用の検索対象に混ぜません。原文の位置と否定・条件・例外を保持し、「代理人の場合に限り」を落としていないか、業務担当者が確認します。
抽出の確信度やSHACL適合は、正しい解釈の証明ではありません。 「委任状が不要」を「必要」と抽出しても、項目が揃っていれば形式検査には通り得ます。
承認後はモデル・ルール・原文対応の版を管理します。誤りは回答利用から外し、検索用データやキャッシュにも反映します。一方、過去の転居日に必要なv1は、新版の登場だけで削除しません。
権限は文書名を隠すだけでなく、検索・探索・要約・生成の各段階で守ります。権限外の関係を経由した結論の露出も確認対象です。
6.3 回答には結論だけでなく、条件と根拠を渡す
相談001について、転居日・住居変更・代理提出が確認済み、経路変更が未確認なら、アプリはその区別と適用ルール・根拠を生成側へ渡します。
転居日が2026年10月1日で、代理提出を予定しているため、教材規程v2では住所変更届と委任状が必要です。届出期限は2026年10月11日です。通勤経路変更申請は経路が変わる場合に必要ですが、まだ確認できていません。今回の転居で通勤経路は変わりますか。
各結論に対応する原文箇所を表示します。引用が一つあるだけで全結論の裏付けにはなりません。GraphRAGで関係を検索する場合も、適用条件と根拠の確認は必要です。
7. なぜ誤りを減らせるのか、何を評価すべきか
7.1 仕組みから説明できることと、実測が必要なこと
期待する効果を誤りの種類に分けます。
| 減らしたい誤り | 設計が効く仕組み | 残る失敗 |
|---|---|---|
| 語義の混同 | 別名を識別子に結び、同名別物を分離 | 誤った名寄せ、検索漏れ |
| 関係の結合ミス | 案件・役割・ルール・根拠を結ぶ | 関係の誤登録・未登録 |
| 条件の欠落 | 未確認を明示して質問 | 否定の脱落、例外漏れ |
| 版・根拠の誤り | 適用日で版を選び原文へ戻る | 期間や原文対応の誤り |
これは誤りを減らす因果の仮説です。W3C規格が定めるのは表現や検証の意味で、このQAの正答率が何ポイント上がるかではありません。
誤った関係を定義すれば誤りが広がり、作り込みすぎれば保守漏れも増えます。生成が判定結果を無視する可能性もあるため、知識と回答の正しさは別々に確かめます。
7.2 導入前後を同じ問題で比較する
導入前後で文書・質問・閲覧権限・適用日・LLMを揃えます。語義の正規化だけを加えた場合と、関係・条件まで加えた場合を段階的に比べれば、改善の理由を調べやすくなります。
評価には、正常に答えられる問題だけでなく、次の対になる質問を含めます。
- 転居日は同じで、経路変更が「あり／なし／未確認」の3通り。
- それ以外の条件は同じで、提出者が「本人／代理人」の2通り。
- 転居日だけが「2026-09-30／2026-10-01」で異なる境界の2通り。
- 用語は同じでも組織が異なる質問と、用語が違っても同じ手続きを指す質問。
手続き・必要物・期限・規程版・根拠を分けて採点します。条件不明時の適切な追加質問を一律に減点せず、逆に何でも保留する回答も高評価にしません。答えられる問題の完答と、情報不足時の対応を両方測ります。具体的な指標と回帰評価は第4回で扱います。
8. 小さく始め、保守できる範囲に留める
8.1 最初は一つの業務と少数の質問で始める
最初に作るのは巨大なグラフでなく、合意した用語・条件表・根拠・評価用の質問です。
| 手順 | 成果物 | 次へ進む条件 |
|---|---|---|
| 対象を絞る | 小さな業務範囲と質問 | 解決する疑問が明確 |
| 意味を揃える | 用語・識別子・関係 | 業務担当者の合意 |
| 条件を表す | 決定表・期間・根拠 | 未知・否定・例外が明確 |
| 実装して比べる | 検索・判定・回答 | 改善と悪化を把握 |
RDBと決定表で十分なら維持し、用語共有や関係探索の必要性を確認してから技術を追加します。少数の規程を案内するだけならFAQ改善、単一フォームで完結するなら入力検証と決定表が先です。
原文の矛盾を業務担当者が解決できない場合や、保守担当を置けない場合は、オントロジーで解決したことにせず自動回答の範囲を縮めます。
8.2 意味の責任者と、実装の責任者を決める
業務担当者は意味・条件と原文対応を承認し、モデル担当者は識別子と関係を保ち、アプリ担当者は権限・判定・回答への反映を担います。
変更時は条項から関連ルール・根拠・評価問題へ影響を辿ります。v2を導入しても、9月30日以前の案件には14日が残り、旧版の根拠を引ける必要があります。適用範囲の重複や空白は保留します。
意味を承認し、変更後の回答まで責任を持つ人を決めます。責任者のいないモデルは、古い規程を整然と返す仕組みになり得ます。
9. まとめ
オントロジーは魔法ではなく、区別する対象・関係・根拠を明示する設計です。意味、語彙、入力検証、業務判定の責務を分け、未知を偽にしません。
誤りが減ったかは、条件違い・境界日・情報不足を含む質問で確かめます。次回のGraphRAGで事務手続きQAを改善する：検索の仕組みと精度向上の条件では、この意味と根拠を検索へ活かす方法を扱います。
10. 参考情報
- Ontology Development 101: A Guide to Creating Your First Ontology — 質問から範囲を定め、段階的にモデルを育てるための入門
- OWL 2 Web Ontology Language Primer (Second Edition) — 公理・推論・開世界仮定を例から理解するための主要な学習入口
- GraphRAGで事務手続きQAを改善する：検索の仕組みと精度向上の条件 — 第2回、グラフを検索に使う仕組みと適用条件
- 事務手続きQAの設計実践：オントロジーとGraphRAGを安全につなぐ — 第3回、検索・判定・回答をつなぐシステム設計
- 事務手続きQAの評価と運用：精度を測り、規程変更に追従する — 第4回、評価問題と規程変更時の更新・回帰評価
[^owl-primer]: OWL 2 Web Ontology Language Primer (Second Edition) — W3C（確認日: 2026-09-05）
[^ontology-development]: Ontology Development 101: A Guide to Creating Your First Ontology — Stanford University（確認日: 2026-09-05）
[^rdf-concepts]: RDF 1.1 Concepts and Abstract Syntax — W3C（確認日: 2026-09-05）
[^rdf-schema]: RDF Schema 1.1 — W3C（確認日: 2026-09-05）
[^skos-primer]: SKOS Simple Knowledge Organization System Primer — W3C（確認日: 2026-09-05）
[^shacl]: Shapes Constraint Language (SHACL) — W3C（確認日: 2026-09-05）
[^dmn]: About the Decision Model and Notation Specification Version 1.5 — Object Management Group（確認日: 2026-09-05）
[^prov-o]: PROV-O: The PROV Ontology — W3C（確認日: 2026-09-05）
[^rag-paper]: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — arXiv（確認日: 2026-09-05）
[^rdf-turtle]: RDF 1.1 Turtle — W3C（確認日: 2026-09-05）
