オントロジーについて

オントロジー

Last updated at 2026-08-17Posted at 2026-08-17

AI時代のオントロジー入門

文書検索を「組織の意味と行動の基盤」へ変える実装ガイド

生成AIを社内文書へ接続すると、最初のデモはたいていうまくいく。

規程を要約し、議事録を探し、過去の提案書から似た事例を見つけられるからだ。

ところが、利用者が「この顧客に適用される契約と例外は何か」「この設備の停止が、どの納期と担当部署へ影響するか」「この申請を承認できるのは誰か」と尋ねると、単純な文書検索は急に不安定になる。

これらは文章の類似性を探す問いではない。

組織内の対象、関係、規則、責任、時間をたどる問いである。

オントロジーは、この「組織にとって何が存在し、それらがどう関係し、何が許されるか」を、人と機械が共有できる形で定義する。

検索精度を少し上げるための付加機能にとどまらない。

データ、業務ルール、AIエージェント、意思決定を同じ意味体系へ接続する設計資産である。

オントロジーとは何か

「組織が認識する世界」を明示したモデル

W3Cはオントロジーを、特定領域を扱うことが多い「形式化された用語の語彙」と説明し、用語間の関係によって定義を与えるものとしている。

OWL 2の公式概要では、その定義を機械が処理し、Web上で共有できるようにする言語としてOWLが位置づけられている。

実務では、次の五要素を持つモデルと捉えると扱いやすい。

要素	答える問い	例
クラス	どの種類のものが存在するか	顧客、契約、製品、設備、申請、従業員
インスタンス	具体的にどの対象か	顧客A、契約C-104、設備M-12
プロパティ	その対象はどんな値を持つか	契約開始日、設備状態、担当部署
関係	対象同士がどう結びつくか	顧客が契約を結ぶ、設備が工場に属する
制約	何が満たされなければならないか	EU顧客の個人情報は外部送信前に匿名化する

オントロジーの効用は、とりわけ関係と制約に現れる。

タグで顧客と契約の両方に#salesを付けても、両者がどう結びつくかは分からない。

顧客A has_contract 契約C-104と型付きの関係を置けば、機械は契約から適用ポリシーへ進み、そのポリシーから必要な承認へたどれる。

タクソノミー、データモデル、知識グラフとの違い

オントロジー周辺の用語は混同されやすい。

2026年に公開されたMedium記事にも、タクソノミー、オントロジー、知識グラフを区別する解説が複数ある。

たとえば「Why Ontology Is Becoming the Missing Layer in Enterprise RAG and Agentic AI」は、タクソノミーを階層的な分類、オントロジーを概念、関係、規則、制約の定義、知識グラフを具体的な事実の集合として整理している。

用語	主な役割	例
用語集	語の説明をそろえる	「有効顧客」の定義文
タクソノミー	上位概念と下位概念で分類する	製品からSaaS、業務支援SaaSへ分類
データモデル	保存と処理の構造を定める	テーブル、列、主キー、外部キー
オントロジー	対象、関係、規則、制約の意味を定める	顧客、契約、適用地域、承認条件
知識グラフ	オントロジーに沿って実体と事実を格納する	顧客Aが契約C-104を保有する
セマンティックレイヤー	利用者やアプリへ一貫した業務意味を提供する	売上、顧客、地域の共通定義と問い合わせ面

オントロジーと知識グラフの関係は、文法と文にたとえられる。

オントロジーが「顧客は契約を持てる」「契約には適用地域がある」と定め、知識グラフが「顧客Aは契約C-104を持ち、その適用地域は日本である」と記録する。

倉庫管理エージェントを題材にしたMedium記事も、抽象的な構造と具体的な業務事実をこのように分けている。

ただし、製品が「Ontology」と呼ぶ対象は必ずしもOWLオントロジーと同じではない。

Palantirは、オブジェクト、プロパティ、リンクに加え、アクション、関数、動的セキュリティを統合した業務運用層をOntologyと呼ぶ。

Microsoft Fabric IQも、エンティティ、関係、データバインディング、規則、問い合わせを含む共有業務モデルとしてOntologyを提供している。

両者は形式的意味論だけでなく、データを読み、判断し、業務システムへ書き戻す範囲まで拡張した「運用オントロジー」である。

製品比較では、この語義の違いを確認しなければならない。

RAGだけでは扱いにくい問いがある

一般的なRAGは、質問と意味が近い文書断片をベクトル検索し、その断片を言語モデルへ渡す。

規程の要約や似た記述の発見には有効だが、離れた文書にまたがる関係や、厳密な集計、例外条件を自動では保証しない。

X上では、PuppyGraphが複数テーブルをまたぐText-to-SQLで結合やフィルターをモデルが推測する危険を指摘し、関係を共有マップとして明示する必要性を述べている。

GraphRAGの解説投稿は、類似チャンクだけでは欠落する経路を、エンティティリンクと複数ホップの探索で取得する例を示している。

一方、グラフを使えば常に良くなるわけではない。

Memgraphの投稿が述べるように、件数を求める構造化された問いは、埋め込み検索よりText-to-Cypherのような決定的な問い合わせが適している。

さらに、Nikunj Kothariの実装経験では、構築に一か月かけた知識グラフより、frontmatter付きMarkdownファイルの方が正確だったという。

この投稿は比較条件を公開したベンチマークではないため一般化できないが、導入判断には有用な反証である。

関係探索が不要な小規模コーパスへ複雑なグラフを置くと、抽出誤り、保守費用、検索経路の増加が便益を上回ることがある。

判断基準は技術の新しさではなく、繰り返し発生する問いが関係、制約、時間、責任を必要とするかである。

なぜ今、オントロジーが再び注目されているのか

言語モデルは一般知識を持つが、自社の意味を知らない

言語モデルは「顧客」という語を理解できる。

しかし、自社が有効顧客を「過去12か月に有償契約があり、解約処理が完了していない法人」と定めていることは、明示的な文脈がなければ分からない。

営業部門の顧客、会計上の取引先、サポート対象の契約主体が異なる場合、モデルはもっともらしい一つの意味へ寄せてしまう可能性がある。

AnythingGraphのMedium記事は、オントロジーを、散らかった現実と構造化問い合わせの間の契約として説明する。

AIエージェント向けの実装記事も、完全なグラフを丸ごとエージェントへ渡すのではなく、意思決定の範囲に合わせた小さな実行時コンテキストグラフを組み立てる設計を提案している。

これはオントロジーの役割を「知識を大量に詰め込むこと」から「今回の判断に必要な対象と関係を選ぶこと」へ変える。

組織の意味がSQL、資料、担当者の頭へ分散している

多くの企業では、業務意味が一か所に存在しない。

顧客区分はCRM、粗利計算はBIの式、例外処理は手順書、実際の承認ルートは担当者の経験へ埋め込まれている。

SnowflakeのMedium記事は、この状態を、各パイプライン、ダッシュボード、AIシステムで業務ロジックを作り直す問題として扱い、事実、意味、利用時の抽象化を分離する構成を示している。

同記事はSnowflake上の提案であり、中立的な比較研究ではない。

それでも、意味をSQLやETLから切り離し、変更可能なメタデータとして管理する考え方は、製品に依存しない設計原則として採用できる。

AIエージェントには名詞だけでなく動詞と権限が要る

検索エージェントは、情報を読むだけでよい。

業務エージェントは、申請を作成し、在庫を引き当て、担当者へ通知し、外部APIを呼ぶ。

そのため「何が存在するか」に加えて、「誰が、どの状態で、どの操作を実行できるか」を定義しなければならない。

Palantirの公式ドキュメントは、データ、ロジック、アクション、セキュリティを一体としてモデル化する。

PalantirのMedium記事では、設備、技術者、作業指示、検査イベントという名詞と、検査記録、欠陥報告、作業完了という動詞を同じ業務モデルへ置いている。

この拡張により、オントロジーは「回答の根拠」だけでなく、「許可された行動の境界」になり得る。

オントロジーを利用できるサービス

2026年8月時点の主要な選択肢を、導入目的で分類する。

製品名に「グラフ」が含まれていても、オントロジー設計、推論、制約検証、業務アクションを同じ深さで扱うとは限らない。

サービス	得意な範囲	標準と実装方式	導入時の注意
Palantir Foundry / AIP Ontology	データ、モデル、アクション、権限を結ぶ閉ループ業務運用	独自のオブジェクト、リンク、アクション、関数、OSDK	業務運用まで一体化できる一方、W3C準拠のオントロジー管理製品と同一ではない
Microsoft Fabric IQ Ontology	OneLake上のデータを共有業務モデルへ結び、AIエージェントやリアルタイム運用へ提供	エンティティ、プロパティ、関係、バインディング、Graph、NL2Ontology	2026年8月時点でプレビュー。公式FAQではバージョン管理未対応とされる
Stardog	分散データの仮想統合、セマンティックレイヤー、推論、制約	RDF、OWL、SPARQL、GraphQL、SHACL、Virtual Graph	既存データを移動せず統合しやすい。運用設計とモデル品質は別途必要
Ontotext GraphDB	RDF知識グラフ、意味検索、推論、GraphRAG	RDF 1.1、SPARQL 1.1、RDFS、OWL 2 RL / QL、RDF-star	GraphDB 11以降はFree版もライセンス取得が必要。エディション差を確認する
TopBraid EDG	オントロジー、用語集、参照データ、リネージ、ポリシーを結ぶデータガバナンス	SHACL中心、RDFSとOWLの入出力	データガバナンス資産全体を関係づけたい組織向け
PoolParty Semantic Suite	タクソノミー、シソーラス、オントロジー、文書分類、意味検索	SKOS、RDF、URI、カスタムオントロジー	コンテンツ分類や用語管理から段階導入しやすい
data.world	知識グラフ型データカタログとガバナンス	プラットフォームのシステムオントロジー、RDF、TTL出力	業務アクション実行より、データ発見、意味、ガバナンスが中心
Cambridge Semantics Anzo	複数データセットの意味モデルによる統合と分析	RDF、OWL、SPARQL、Named Graph	エンタープライズデータ統合とモデル運用を一体化したい場合に向く
Amazon Neptune	マネージドなRDFグラフとプロパティグラフの実行基盤	RDF / SPARQL、openCypher、Gremlin	グラフDBであり、業務オントロジーの共同編集や承認プロセスは別途組み合わせる
Neo4j + neosemantics	プロパティグラフへRDF、OWL、SKOSを取り込み、SHACL検証や基本推論を加える	Cypher、RDF、OWL、RDFS、SKOS、SHACL	neosemanticsはself-hosted向けでAuraでは利用できないという公式記載がある
Protégé / WebProtégé	無料のオントロジー設計、推論、問い合わせ、共同編集	OWL 2	オントロジー編集環境であり、本番のデータ統合、配信、業務実行基盤は別に必要
metaphactory	オントロジーモデリング、探索、検索、低コードの知識グラフUI	OWL、SHACL、SPARQL	Neptuneなどのグラフ基盤と組み合わせる選択肢になる

サービスの選び方は、次の三つの質問から始められる。

必要なのは用語とデータの意味統一か、業務アクションまで含む運用基盤か。
W3C標準による可搬性と形式推論が必要か、既存データ基盤との統合速度を優先するか。
オントロジーを誰が日常的に変更し、誰が承認し、過去の判断をどう再現するか。

RDFとOWLを使わなければオントロジーではない、という整理は実務上狭すぎる。

一方、テーブルに分かりやすい表示名を付けただけでオントロジーと呼ぶのも広すぎる。

製品選定では、少なくとも型付きの対象、関係、制約、証拠、変更管理があるかを確認し、必要に応じて推論、権限、アクションを追加要件にする。

オントロジーの実装方法

技術選定より先に「答えたい問い」を決める

Stanfordの古典的なOntology Development 101は、オントロジーの利用領域と目的を定め、答えるべき質問を洗い出す方法を示している。

この質問はコンピテンシー質問と呼ばれる。

たとえば設備保全なら、次のように置く。

この設備が停止したとき、どの製品、受注、納期が影響を受けるか。
この設備を修理できる資格を持ち、現在稼働可能な技術者は誰か。
同型設備で過去90日に発生した故障と対処は何か。
交換部品の在庫が不足するとき、誰の承認が必要か。

これらの問いが、必要なクラス、関係、時間情報、制約を決める。

「会社全体をモデル化する」は目的にならない。

最初の対象は、意思決定一つ、業務フロー一つ、5から10種類の関係でよい。

ステップ1：一つの意思決定と責任者を定める

実装単位はデータソースではなく、繰り返される意思決定にする。

たとえば「欠品リスクのある受注に対し、代替在庫を割り当てるか」を対象にする。

意思決定の責任者、入力、出力、許容時間、例外、失敗時の影響を記録する。

責任者が不在のオントロジーは、意味の対立が起きたときに更新できない。

ステップ2：クラス、インスタンス、プロパティ、関係、制約へ分ける

業務資料やインタビューから名詞を抽出しただけでは、語彙一覧にしかならない。

各候補を次の基準で分類する。

再利用可能な種類ならクラスにする。
固有の対象ならインスタンスにする。
値を答えるものならプロパティにする。
他の対象との結び方を答えるものなら関係にする。
満たすべき条件なら制約にする。

「担当」は曖昧な語である。

営業責任を示すowned_by、作業実行を示すassigned_to、承認義務を示すapproved_byへ分ければ、問い合わせと権限判定が安定する。

ステップ3：識別子、証拠、時間を最初から持たせる

複数システムを結ぶとき、同じ顧客や設備を同一の対象と判定できなければ関係探索は崩れる。

そのため、各中核エンティティに安定した識別子を与え、CRM、ERP、契約管理などのローカルIDとの対応表を作る。

各エッジには、少なくとも出典、信頼度、最終確認日時を付ける。

変化する事実には、有効期間と記録時刻を分けて持たせる。

たとえば「4月1日から担当者がBへ変わった」という現実世界の有効時刻と、「4月3日にCRMへ登録された」というシステム記録時刻は異なる。

過去の意思決定を監査するには、当時何が真実だったかと、当時システムが何を知っていたかの両方が要る。

ステップ4：軽量モデルか形式オントロジーかを選ぶ

最初からOWLの高い表現力が必要とは限らない。

必要性	選択肢
AIへ関係の近傍を渡し、影響範囲をたどりたい	YAML / JSONの型付きノードとエッジ、プロパティグラフ
部門をまたぐ語彙の再利用と相互運用が必要	RDF、RDFS、SKOS
同値関係、包含関係、推論を形式的に扱いたい	OWL 2の適切なプロファイル
データ品質と入力条件を検証したい	SHACL
業務担当者が概念を共同編集したい	WebProtégé、PoolParty、TopBraid EDGなど
読み取りから業務更新まで一体化したい	Palantir Ontology、Fabric IQとActivatorなど

RDFは、主語、述語、目的語のトリプルでグラフを表す標準である。

RDF 1.1 Conceptsは、RDFグラフをトリプルの集合として定義する。

OWLは語彙の意味と推論可能な公理を表し、SHACLはRDFグラフの構造と制約を検証する。

W3CのSHACL勧告は、SHACLをRDFグラフを記述し検証する言語と定めている。

ステップ5：最小モデルをコードにする

次は、顧客、契約、地域を表す最小のTurtle例である。

@prefix ex:  <https://example.com/ontology/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs:<http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:Customer a rdfs:Class .
ex:Contract a rdfs:Class .
ex:Region   a rdfs:Class .

ex:hasContract a rdf:Property ;
  rdfs:domain ex:Customer ;
  rdfs:range ex:Contract .

ex:appliesToRegion a rdf:Property ;
  rdfs:domain ex:Contract ;
  rdfs:range ex:Region .

ex:customerA a ex:Customer ;
  ex:hasContract ex:contractC104 .

ex:contractC104 a ex:Contract ;
  ex:contractId "C-104" ;
  ex:validFrom "2026-04-01"^^xsd:date ;
  ex:appliesToRegion ex:Japan .

ex:Japan a ex:Region .

SHACLで「契約には契約IDが一つ必要」と検証できる。

@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ContractShape a sh:NodeShape ;
  sh:targetClass ex:Contract ;
  sh:property [
    sh:path ex:contractId ;
    sh:minCount 1 ;
    sh:maxCount 1 ;
    sh:datatype xsd:string
  ] .

SPARQLでは、顧客Aへ適用される契約と地域を関係に沿って取得できる。

PREFIX ex: <https://example.com/ontology/>

SELECT ?contract ?region
WHERE {
  ex:customerA ex:hasContract ?contract .
  ?contract ex:appliesToRegion ?region .
}

この例の価値は、ファイル形式ではなく、業務上の関係と検証条件が実行可能な形になっている点にある。

ステップ6：ベクトル検索とグラフ探索を組み合わせる

オントロジーとRAGは競合しない。

曖昧な自然言語から関連文書や候補エンティティを見つける処理は、ベクトル検索が得意である。

候補が見つかった後で、契約、責任、依存関係、例外をたどる処理はグラフが得意である。

実行時の流れは次のようになる。

質問
  ↓
意図分類とエンティティ抽出
  ↓
ベクトル検索で候補ノードと根拠文書を発見
  ↓
許可された関係だけを1から2ホップ探索
  ↓
制約、出典、時点を含む小さなコンテキストグラフを生成
  ↓
言語モデルが回答または行動案を作成
  ↓
SHACL、業務ルール、権限、承認で検証
  ↓
回答、または人の承認を経たアクション

探索ホップを無制限にすると、関連の薄いノードと機密情報が混入しやすい。

質問種別ごとに許可する関係、最大ホップ数、時点、アクセス権を定める。

ステップ7：回答精度ではなく業務結果まで評価する

評価セットには、正常例だけでなく反例と変更例を含める。

同名だが別の顧客を混同しないか。
契約終了後の規則を現在の回答へ使わないか。
部門ごとに定義が違う語を、無断で一つへ統合しないか。
権限のない利用者へ機密ノードの存在を示さないか。
出典がない推定関係を事実として扱わないか。
関係を一つ削除したとき、影響範囲が期待どおり変わるか。

技術指標には、エンティティリンク精度、関係精度、制約違反率、根拠到達率、検索レイテンシ、アクセス制御違反を置ける。

業務指標には、判断時間、手戻り率、エスカレーション率、監査証跡の作成時間、新任者の立ち上がり時間を置く。

オントロジーのノード数やトリプル数は作業量を示すが、価値を示さない。

オントロジーを活かした組織課題の解決

課題1：部門ごとに言葉と数字が違う

「顧客」「売上」「障害」「完了」などの基礎語が部門ごとに違うと、会議は数字の検証から始まり、意思決定へ進まない。

オントロジーは、一つの定義を強制するためだけに使うものではない。

営業顧客、請求先、契約主体を別クラスとして定義し、それらの対応関係と利用条件を示せる。

この設計により、違いを消さず、どの問いでどの定義を使うかを計算可能にする。

解決の単位は「全社共通語彙の完成」ではなく、月次売上会議や顧客リスク判定など、対立が実際にコストを生む意思決定にする。

課題2：データサイロの結合が案件ごとに作り直される

CRMの顧客、ERPの取引先、サポートの契約IDが接続されていなければ、案件ごとに分析担当者が結合ロジックを再作成する。

オントロジーへ標準エンティティ、識別子対応、関係、出典を置くと、複数のアプリとAIが同じ結合の意味を再利用できる。

これはデータを一つの巨大DBへ移すことと同じではない。

StardogのVirtual Graphや、Snowflake上のコントロールプレーン構想のように、データを元の場所へ残し、意味と問い合わせ面を重ねる方式もある。

課題3：担当者の暗黙知へ業務が依存する

熟練者は、手順書に書かれていない例外、担当部署、過去の失敗、実行順序を知っている。

文書化だけでは、例外がどの条件で、どの対象へ、なぜ適用されるかが埋もれやすい。

例外をapplies_to、overrides、requires_approval_from、supported_byなどの関係として記録し、根拠と有効期間を付けると、新任者とAIが判断経路をたどれる。

ただし、インタビューで抽出したモデルは候補にすぎない。

実際の作業、引き継ぎ、例外処理を観察し、責任者が確認して初めて運用知識になる。

課題4：変更の影響範囲が見えない

「顧客」の定義変更が、どのデータセット、ダッシュボード、機械学習特徴量、API、契約、テストへ影響するかを文書検索だけで網羅するのは難しい。

Ontology-Driven Enterprise ArchitectureのMedium記事は、業務概念からデータ、サービス、モデル、配備までの型付き関係と証拠を持たせ、変更影響を計算可能にする構成を示す。

実装では、defined_by、implemented_by、consumed_by、tested_by、deployed_asを1から2ホップたどる。

結果を自動で真実とせず、出典ファイル、最終確認日、関係の信頼度とともにレビュー対象へ出す。

課題5：AIエージェントの行動範囲が曖昧

AIエージェントへAPIを渡すだけでは、「技術的に呼べる操作」と「業務上許される操作」が一致しない。

オントロジーに役割、対象、状態、許可アクション、禁止条件、承認者を結びつけると、実行前に意味レベルの判定ができる。

たとえば、RefundRequestがHighValueCaseに分類され、amount > 100000を満たす場合、requires_approval_from FinanceManagerを適用する。

エージェントは返金案を作成できても、承認ノードがない限り実行できない。

この方式はプロンプト内の注意書きより監査しやすいが、基盤側の認証、認可、トランザクション制御を置き換えない。

オントロジーは業務上の許可を表現し、実際の強制はAPIゲートウェイや権限基盤が担う。

課題6：部門間で正当な見解差がある

組織の意味は常に一意ではない。

法務、営業、財務が同じ取引を異なる目的で分類することがある。

Connected Dataが紹介したX投稿は、どの版の記録が正しいか、部門間の正当な不一致をどう保持するか、AIの出力時にシステムが何を信じたかをどう示すかという問いを挙げている。

この問題には、単一の「正解ノード」より、文脈、観測者、目的、有効期間、根拠を持つ記述が必要になる。

部門差を誤差として削除せず、「誰にとって、どの業務で、いつ有効か」を関係へ含める。

90日で始める導入計画

1週目から2週目：意思決定と評価基準を固定する

対象業務を一つ選び、意思決定責任者、利用者、現行時間、誤りの種類、コンピテンシー質問を定める。

データ基盤刷新や全社用語集の完成を前提条件にしない。

現行プロセスの基準値を測り、導入後に比較できるようにする。

3週目から4週目：最小オントロジーを共同設計する

業務担当、データ担当、セキュリティ担当で、10から20のクラス、5から10の関係、重要な制約を設計する。

各用語に定義、責任者、出典、例、反例を付ける。

業務担当が読める表と、機械が扱えるRDF、YAML、グラフスキーマの両方を同じリポジトリで管理する。

5週目から8週目：データを結び、検索経路を作る

対象となる2から3のシステムだけを接続し、識別子対応、関係、出典、有効期間を作る。

曖昧検索はベクトル、関係探索はグラフ、集計はSQL、規則検証はSHACLまたはルールエンジンへ分担する。

利用者の権限に応じて、取得可能なノード、エッジ、プロパティを制限する。

9週目から10週目：反例を含む業務評価を行う

実際の過去案件から、正常例、例外、欠損、矛盾、権限違反を含むテストセットを作る。

単純RAG、オントロジー併用、熟練者の現行手順を同じ問いで比較する。

精度が上がっても、回答時間と保守工数が許容範囲を超えるなら採用しない。

11週目から12週目：拡張か撤退かを判断する

次の条件がそろえば、隣接する一つの意思決定へ拡張する。

判断時間または手戻りが測定可能に減った。
誤りの原因を出典、関係、規則まで追跡できる。
業務責任者が変更を承認できる。
自動更新と人のレビューの境界が定義されている。
運用費用が得られた便益に見合う。

条件を満たさない場合は、ベクトル検索、用語集、Markdown索引、SQLセマンティックモデルへ戻す。

撤退可能性を残すため、原本データと文書をグラフから分離し、グラフを再構築可能な投影として扱う。

実装で起きやすい失敗

世界全体をモデル化しようとする

最大の失敗は、利用する問いを決めずに全社オントロジーを作り始めることだ。

「Ontology Tax」は、設計、投入、検証、保守、ガバナンスに継続的な人件費がかかる点を指摘する。

記事内の市場規模や費用推計は二次情報であり、そのまま予算根拠には使えない。

ただし、ライセンス費より意味の合意と保守が支配的になり得るという警告は妥当である。

一つの資金化された問いから始め、次の問いが生じたときだけ関係を増やす。

LLMが抽出した関係を事実として登録する

言語モデルは、文書から候補エンティティと候補関係を高速に抽出できる。

しかし、文章に明記されていない因果や責任を補完することがある。

自動抽出したエッジにはproposed状態、出典、抜粋、信頼度を付け、重要な関係は責任者の承認後にapprovedへ変える。

オントロジーを固定的な真実にする

組織の意味は、制度変更、商品変更、例外、責任移管で変わる。

変更提案、影響分析、代表例と反例のテスト、人の承認、バージョン、廃止関係を管理する。

過去の意思決定を再現できるよう、古い版を上書きせずsuperseded_byで新しい版へ結ぶ。

グラフを毎回すべてLLMへ渡す

グラフ全体をプロンプトへ入れると、トークン費用が増え、関係の薄い情報が判断を乱し、アクセス制御も難しくなる。

質問の起点を同定し、許可された関係だけを1から2ホップたどり、根拠文書の必要箇所とともに渡す。

オントロジーで認可を代替する

「この役割はこの情報を見られる」という関係をモデル化しても、グラフDB、検索インデックス、APIが同じ制約を強制しなければ情報は漏れる。

意味モデル、ID基盤、行や列やノードのアクセス制御、ツール実行権限、監査ログを一つのテストシナリオで検証する。

オントロジー導入の判断基準

次の問いへ三つ以上「はい」と答える組織では、小さな実証を行う価値がある。

同じ業務語が部門やシステムによって異なる意味を持つか。
問いの答えに、複数文書や複数システムをまたぐ関係探索が必要か。
規則、例外、権限、有効期間を回答へ反映する必要があるか。
変更の影響範囲をデータ、業務、システムへ横断して追う必要があるか。
AIエージェントに情報検索だけでなく業務操作を任せる予定があるか。
判断の根拠と、判断時点で利用した知識を監査できる必要があるか。

反対に、対象が数十の安定した文書で、問いが要約と単純検索に限られ、関係や制約をたどらないなら、Markdown、全文検索、ベクトル検索、既存のセマンティックモデルで十分な可能性が高い。

オントロジーは、データ量が多いから必要になるのではない。

意味の不一致と関係の複雑さが、繰り返し意思決定を遅らせているときに必要になる。

結論

オントロジーは、組織内の名詞を整理する辞書ではない。

対象、関係、規則、責任、時間、証拠を共有し、機械がたどり、人が検証できるようにする意味の基盤である。

生成AIとの組み合わせでは、言語モデルが候補を見つけて説明し、オントロジーと知識グラフが関係を限定し、規則と権限基盤が行動を制御する。

この分担が成立すると、社内AIは「関連しそうな文章を返すシステム」から、「組織の定義と責任に沿って判断を支援するシステム」へ進める。

導入は全社モデルから始めない。

コストの高い意思決定を一つ選び、答えるべき問いを定め、最小の対象と関係を作り、業務結果で評価する。

価値が確認できた範囲だけを、証拠、権限、変更管理とともに拡張する。

オントロジーを完成品ではなく、組織が自分たちの意味を検証し続けるための運用資産として扱うことが、実装を長持ちさせる。

調査ソース一覧

以下は本稿の作成にあたり確認した主要情報である。

MediumとXの投稿は、実践上の論点と市場の関心を把握するために用い、標準、製品機能、制限は可能な限り公式資料で確認した。