Slide 1

Slide 1 text

イ ンフ ラと し ての 「 コ ンテ キス ト ・レ イヤ 」 AIエージェントのための グラフデータ基盤の層構成 何を入れるか / 何を入れないか / どう運用するかを 公開されている事例から読み解く 参照:Microsoft GraphRAG / Google Cloud / operational-ontology / NebulaGraph / OceanBase OSI / Entropositive Ontology 公開資料からの調査メモ

Slide 2

Slide 2 text

自己 紹介 大前 七奈(おおまえ なな) 1 2 3 By Google Photos X @seven7777_77 3 所属 略歴 近況 合同会社デロイトトーマツ Technology & Strategy Transformation Unit Manager ・統計解析からキャリアをスタート ・2020年〜電子部品メーカでデータサイエンティスト ・2023年〜データコンサル+データエンジニア ・最近AI-Agentのデータ基盤、データ利活用や運用戦略に携わる ・つい、先週Google Certification全冠獲得 ・転職したてでやっと一段落づいたので、Jaguer活動再開

Slide 3

Slide 3 text

出典 出典一覧 1 • Google Cloud Architecture Center「GraphRAG infrastructure using Agent Platform and Spanner Graph」 • Microsoft GraphRAG「Knowledge graphs」 • gura105/operational-ontology (GitHub, MIT) • NebulaGraph「Ontology and Graph Databases for Enterprise AI」 • OceanBase「Ontology vs. Semantic Layer」 • Rosho Qaori「The Entropositive Ontology」 • Gartner D&A Summit 2026 の報道記事(Atlan) 3

Slide 4

Slide 4 text

課題 ベクトル検索だけでは、社内知識は扱いきれない 1 2 3 4 関係が辿れない 文脈が持てない 数字が割れる 出典と鮮度が曖昧 「この案件の担当者の上長は誰か」に、類似文書の断片では答えられない 同じ事実でも案件によって重要度は変わるが、検索結果は常に同じ 売上の定義が部門ごとに違い、エージェントは最初に見つけた定義を使う 根拠を追えず、半年前の決定がいまも有効かも区別できない 「同一実体が複数システムに分散」「説明責任が必要」など5つの兆候のうち3つ以上該当すればオントロジーが必要、と整理していました。判断の目安として 参考になりそうです。

Slide 5

Slide 5 text

整理 して みた 形 7つの層に分けて、性質で3グループにまとめてみた 層 何を持つか 所有者 L1 オントロジー層 型・述語・公理(スキーマそのもの) オントロジーオーナー L2 セマンティック層 指標の計算定義 指標オーナー(事業側) L0 観測層 出典そのもの。唯一の真実の源 コネクタ担当 L3 ナレッジグラフ 時間非依存の事実(インスタンス) 導出物 L4 コンテキストグラフ 事実の効き方・状況適用性 導出物 L5 権限・ポリシー層 所有権・決裁経路・許可/要件/禁止 セキュリティ + ドメイン L6 リネージ・品質層 系譜・鮮度・認証状態・カバレッジ 基盤チーム 定義 事実 統制 依存の向き:L1/L2(定義)→ L0(観測)→ L3 → L4。L5・L6 は全層に横断的に付く。 中核原則:L0 と L1・L2・L5 だけが人間が書く層。L3・L4 はすべて導出物で、いつでも作り直せる。

Slide 6

Slide 6 text

層の内容 と運用 ルー ル 1 / 4 L0 観測層 と L1 オントロジー層 L0 観測層 L1 オントロジー層 observations 型・述語・公理の定義 含めるもの 含めるもの • • • • • • 取り込んだ原文(Slack・Notion・議事録・チケット) 出典URI、発生日時、取り込み日時、著者 チャンクと埋め込み、埋め込みモデル名とバージョン クラス:person / team / project / system / decision 述語:owns / depends_on / decided など20〜30個 定義域と値域、公理・制約、別名マッピング、承認履歴 含めないもの 含めないもの • • • • • 抽出結果・要約・正規化後の値(L3以降) 手で編集した内容。原文は書き換えない インスタンス(実際の田中さん)はL3 計算式(売上の定義)はL2 完全なOWL/RDFモデリング 運用ルール • • • • • 冪等性:(source, uri, chunk) に一意制約 不変:更新せず、新しい観測を足して旧版を閉じる 削除は連鎖:観測を消せば導出エッジも消える コネクタは抽出しない。取り込みに徹する 保持期間は元システムの規定に従う 運用ルール • • • • • 決定権は1人。合議制にしない 新述語の申請には3点必須(理由・実例20件・クエリ) 抽出プロンプトに列挙型として強制する 型は絞る。増やすときは1つ削る 定義は値なのでPRで差分レビューできる

Slide 7

Slide 7 text

層の 内容 と運 用ル ール 2 / 4 L2 セマンティック層 と L3 ナレッジグラフ L2 セマンティック層 L3 ナレッジグラフ 指標の計算定義 nodes / edges 含めるもの 含めるもの • • • • • • 指標定義:売上・アクティブ率・リードタイム 物理カラム名と業務用語の対応表 結合・フィルタ規則、ディメンション、所有者と認証状態 ノード:L1の型に属する実体。正規化キーと埋め込み エッジ:主語 — 述語 → 目的語 の三つ組 確信度、有効期間、出典ID、抽出器版、別名テーブル 含めないもの 含めないもの • • • • • 概念間の関係や推論(L1の役割) 実測値そのもの。定義だけを持つ 状況依存の重み(L4) 出典のないエッジ(source_observation_id は NOT NULL) 手動で入れた事実 運用ルール • • • • • 定義は1箇所、消費は複数(BI・AI・監査が同じ定義を読む) 所有者は事業側。売上の定義を決めるのは財務 YAML等でバージョン管理下に置く 未認証の指標はエージェントに渡さない 主要指標10個程度から。L1と並行で最小限に 運用ルール • • • • • 削除せず valid_to で閉じる 冪等な書き込み:三つ組のハッシュに一意制約 extractor_version 単位で捨てて作り直せる verified_at が閾値超過なら減衰か再抽出キューへ 孤立ノードの増加は実体解決の失敗を示す

Slide 8

Slide 8 text

層の内容 と運用 ルー ル 3 / 4 L4 コンテキストグラフ と L5 権限・ポリシー層 L4 コンテキストグラフ L5 権限・ポリシー層 contexts / context_edges 所有権・決裁・許可/要件/禁止 含めるもの 含めるもの • • • • • • session / task / project / thread の入れ子 L3エッジへの参照 + weight + role、参照回数 時間境界を持つ言明(GraphRAG の covariates 相当) 所有権:統制権限を持つチーム・役割・個人 決裁構造:境界を越える変更を誰が承認するか 許可/要件/禁止の3種のポリシーと可視性ポリシー 含めないもの 含めないもの • • • • 独自のノードを作らない。L3のエッジを指すだけ 恒久的に真である事実。それはL3 認証。IDは確立済みのものが渡ってくる前提 事前条件と権限の混同 運用ルール 運用ルール • • • • • • • • • • 参照のたび強化、放置で時間減衰。明示的削除は不要 ホップ展開が爆発する場合は要約文で代替する 文脈が終わったら ended_at を入れて減衰させる 再取り込みで人の入力を消さない 重みを人が手で編集させない。式のほうを見直す 既定は fail-closed。未設定は「見えない」に倒す 可視性はグラフ展開の前、再帰CTEの内側で効かせる 決裁先は名前で返す。キューに投げない 可視性/権限/事前条件を機械可読に区別させる 未登録対象の操作は通さず保留にする

Slide 9

Slide 9 text

層の 内容 と運 用ル ール 4 / 4 L6 リネージ・品質層 と、誰が何を書けるか L6 リネージ・品質層 含めるもの • 系譜:どの観測から、どの抽出器版で生まれたか • 品質シグナル:確信度分布、再検証からの経過、再現率 • 認証状態:誰がいつ確認したか • カバレッジ:オントロジー登録済みの割合 • 検索記録:どのエッジをどのスコアで選んだか 運用ルール • 検索は全件記録し、回答を後から再現できるようにする • カバレッジ100%を待たない。部分カバレッジで始める • 登録を配備パイプラインの必須ステップに組み込む • 不完全さは隠さず記録する • ゴールデンセットはCIで回す。所有者は利用チーム 誰が何を書けるか 層 人が書く 書き手 L0 観測 ○ コネクタ(取り込みのみ) L1 オントロジー ○ オントロジーオーナー L2 セマンティック ○ 指標オーナー(承認制) L3 KG × 抽出パイプライン L4 CG × 検索パイプライン L5 権限・ポリシー ○ セキュリティ + ドメイン L6 リネージ × 基盤(自動記録のみ) 再構築の原則:L3・L4 は全消しして作り直せる。ただし人が明示的に付けた注記と割当だけは、再取り込みで消さない。

Slide 10

Slide 10 text

層をま たぐ 運用 検索時は、この順序で層を通る 1 L5 主体の可視範囲を確定する 展開の前に。後段フィルタでは経路から漏れる 2 L0 埋め込みでシードノードを特定する クエリ埋め込みで上位k件 3 L3 再帰CTEで2〜3ホップ展開する L5の条件を再帰の内側に適用する 4 L4 + L6 重みと鮮度でスコアを付ける 文脈重複度と verified_at からの経過を反映 5 — 上位N件を平文化してプロンプトへ 選んだエッジとスコアを L6 に全件記録する score = 類似度 × 減衰^ホップ数 × confidence × 時間減衰 × 文脈重複度

Slide 11

Slide 11 text

外部 フレ ーム との 対応 Gartner の切り分けとの対応 ナレッジグラフとセマンティック層が what・who を、コンテキストグラフが how・why を担当する。前者は比較的静的な宣言済みスキーマ、後者は変化し 続ける意思決定の痕跡。 WHAT L1 オントロジー層 「顧客とは何か」— 型と述語の定義 L2 セマンティック層 「売上とは何か」— 指標の計算定義 L3 ナレッジグラフ 「実際に何があるか」— インスタンス L3 の person / team ノード 実体としての誰 L5 権限・ポリシー層 決裁権を持つ誰 L4 コンテキストグラフ どの場面でどう効いたか(部分的) L6 リネージ・検索記録 どの根拠で何を選んだか WHO HOW / WHY この what/who・how/why の切り分けはサミット報道(ベンダー系記事)から。引用する場合は原典レポートを確認したほうが良さそうです。 出典: Gartner Data & Analytics Summit 2026 の内容を報じた記事(Atlan)

Slide 12

Slide 12 text

課題 との 対応 冒頭の4つの課題は、どのあたりで解けそうか 1 関係が辿れない L1 L3 述語を型として定義し、三つ組で保持する。再帰CTEで2〜3ホップ辿 れば、担当者から上長へ到達できる 2 文脈が持てない L4 L6 同じエッジに文脈ごとの重みを持たせ、鮮度と併せてスコア化する。 案件が変われば同じ質問でも順位が変わる 3 数字が割れる L2 4 出典と鮮度が曖昧 L0 計算式を1箇所に置き、BI・エージェント・監査が同じ定義を読む。 未認証の指標はエージェントに渡さない L3 L6 出典なしのエッジを作らせず、verified_at で陳腐化を検知する。検 索記録から回答の根拠を再現できる L5 権限・ポリシー層はこの4つのどれにも直接は対応しないが、見せてよい範囲を先に確定する層として、4つすべての前提になりそう。

Slide 13

Slide 13 text

気にな った 点 WHY をどこに置くかが決めきれない L4は「どの場面でどれだけ効いたか」までしか答えない。「なぜそう決めたか」の痕跡を置く場 所が見当たらない。 具体例 「案件Aの見積を10%下げた」という事実はL3に載る。しかし「なぜ下げたか」(競合の存在、上長の判断、過去の類似案件との比較)は、L0に原文と して埋もれるだけで、構造として辿る手段が思いつかなかった。 案1 L3に decision 型ノードを立てる 意思決定を実体として扱い、decided_by / justified_by(根拠エッジ群 )/ superseded_by で繋ぐ。既存スキーマの延長で済みそう。 案2 L4を decision trace 層として再定義する 適用度の管理をL6のスコアリング側に寄せ、L4を判断の痕跡専用にする 。分類には忠実だが設計変更は大きそう。 適用度と意思決定痕跡は更新頻度も所有者も違いそうなので、同じ層に押し込むと両方が中途半端になる気がしています。

Slide 14

Slide 14 text

体制 役割は3つに整理されていた 1 2 3 オントロジーオーナー ドメインオーナー コネクタ担当 1名(兼任可) 利用チームごとに1名 基盤チーム • L1の型と述語の最終決定権 • • • 複数人にしない — 合議制にすると語彙 は増える方向にしか動かない 自チームの知識が正しく載っているか に責任を持つ 外部システムからL0への取り込みに専 念 • ゴールデンセットの所有者をここにす る • 障害の大半はここで起きる。当番を明 示する L2セマンティック層の所有者だけは別で、売上の定義を決めるのは財務など事業側だ、と複数の資料が書いていました。 新しい述語の申請条件として、こうした3点を挙げる例がありました:① 既存の組み合わせで表現できない理由 ② 実データ20件以上の具体例 ③ それ を使う実際のクエリ

Slide 15

Slide 15 text

進め方 着手順序 1 L1を用語集として始める 完全な形式モデリングではなく、20〜30語の述語リストと型定義から 2 L0とL5を同時に立てる 可視性の設計を後付けにしない 3 L3を1領域だけ埋める 高価値な1領域に絞り、その範囲で同義語・多義語を潰す 4 L6を最初から入れる 検索記録がないと、精度の議論が主観になる 5 L4を追加する 単一文脈で動いてから、文脈の切り替えを扱う 6 L2を並行で最小限 主要指標10個程度。数値の食い違いが表面化してからでは遅い 技術では決まらない部分 事実が矛盾したときに誰が調停するか / 誤答が事故になったときの責任分界

Slide 16

Slide 16 text

まとめ 1 7層を定義・事実・統制に分けると、所有者の違いが見えやすい 2 人が書くのは L0・L1・L2・L5 だけで、L3・L4 は作り直せる 3 可視性はグラフ展開の前に効かせる設計が多い 4 Gartner の切り分けで見ると、WHY の置き場所が曖昧 5 WHY は L3 に decision 型ノードを置く案が素直そう 公開資料を読んだ範囲での整理です。実際に組むなら、decision 型ノードの扱いと、最初に扱う1領域の選び方が論点にな りそうです