インフラとしての「コンテキスト・レイヤ」- AIエージェントのための グラフデータ基盤の層構成

Transcript

1. イ ンフ ラと し ての 「 コ ンテ キス ト ・レ イヤ 」 AIエージェントのための グラフデータ基盤の層構成 何を入れるか / 何を入れないか / どう運用するかを 公開されている事例から読み解く 参照：Microsoft GraphRAG / Google Cloud / operational-ontology / NebulaGraph / OceanBase OSI / Entropositive Ontology 公開資料からの調査メモ
2. 自己 紹介 大前 七奈（おおまえ なな） 1 2 3 By Google Photos X @seven7777_77 ３ 所属 略歴 近況 合同会社デロイトトーマツ Technology & Strategy Transformation Unit Manager ・統計解析からキャリアをスタート ・2020年〜電子部品メーカでデータサイエンティスト ・2023年〜データコンサル＋データエンジニア ・最近AI-Agentのデータ基盤、データ利活用や運用戦略に携わる ・つい、先週Google Certification全冠獲得 ・転職したてでやっと一段落づいたので、Jaguer活動再開
3. 出典 出典一覧 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
4. 課題 ベクトル検索だけでは、社内知識は扱いきれない 1 2 3 4 関係が辿れない 文脈が持てない 数字が割れる 出典と鮮度が曖昧 「この案件の担当者の上長は誰か」に、類似文書の断片では答えられない 同じ事実でも案件によって重要度は変わるが、検索結果は常に同じ 売上の定義が部門ごとに違い、エージェントは最初に見つけた定義を使う 根拠を追えず、半年前の決定がいまも有効かも区別できない 「同一実体が複数システムに分散」「説明責任が必要」など5つの兆候のうち3つ以上該当すればオントロジーが必要、と整理していました。判断の目安として 参考になりそうです。
5. 整理 して みた 形 7つの層に分けて、性質で3グループにまとめてみた 層 何を持つか 所有者 L1 オントロジー層 型・述語・公理（スキーマそのもの） オントロジーオーナー L2 セマンティック層 指標の計算定義 指標オーナー（事業側） L0 観測層 出典そのもの。唯一の真実の源 コネクタ担当 L3 ナレッジグラフ 時間非依存の事実（インスタンス） 導出物 L4 コンテキストグラフ 事実の効き方・状況適用性 導出物 L5 権限・ポリシー層 所有権・決裁経路・許可/要件/禁止 セキュリティ + ドメイン L6 リネージ・品質層 系譜・鮮度・認証状態・カバレッジ 基盤チーム 定義 事実 統制 依存の向き：L1/L2（定義）→ L0（観測）→ L3 → L4。L5・L6 は全層に横断的に付く。 中核原則：L0 と L1・L2・L5 だけが人間が書く層。L3・L4 はすべて導出物で、いつでも作り直せる。
6. 層の内容 と運用 ルー ル 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で差分レビューできる
7. 層の 内容 と運 用ル ール 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 が閾値超過なら減衰か再抽出キューへ 孤立ノードの増加は実体解決の失敗を示す
8. 層の内容 と運用 ルー ル 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の内側で効かせる 決裁先は名前で返す。キューに投げない 可視性／権限／事前条件を機械可読に区別させる 未登録対象の操作は通さず保留にする
9. 層の 内容 と運 用ル ール 4 / 4 L6 リネージ・品質層 と、誰が何を書けるか L6 リネージ・品質層 含めるもの • 系譜：どの観測から、どの抽出器版で生まれたか • 品質シグナル：確信度分布、再検証からの経過、再現率 • 認証状態：誰がいつ確認したか • カバレッジ：オントロジー登録済みの割合 • 検索記録：どのエッジをどのスコアで選んだか 運用ルール • 検索は全件記録し、回答を後から再現できるようにする • カバレッジ100%を待たない。部分カバレッジで始める • 登録を配備パイプラインの必須ステップに組み込む • 不完全さは隠さず記録する • ゴールデンセットはCIで回す。所有者は利用チーム 誰が何を書けるか 層 人が書く 書き手 L0 観測 ◦ コネクタ（取り込みのみ） L1 オントロジー ◦ オントロジーオーナー L2 セマンティック ◦ 指標オーナー（承認制） L3 KG × 抽出パイプライン L4 CG × 検索パイプライン L5 権限・ポリシー ◦ セキュリティ + ドメイン L6 リネージ × 基盤（自動記録のみ） 再構築の原則：L3・L4 は全消しして作り直せる。ただし人が明示的に付けた注記と割当だけは、再取り込みで消さない。
10. 層をま たぐ 運用 検索時は、この順序で層を通る 1 L5 主体の可視範囲を確定する 展開の前に。後段フィルタでは経路から漏れる 2 L0 埋め込みでシードノードを特定する クエリ埋め込みで上位k件 3 L3 再帰CTEで2〜3ホップ展開する L5の条件を再帰の内側に適用する 4 L4 + L6 重みと鮮度でスコアを付ける 文脈重複度と verified_at からの経過を反映 5 — 上位N件を平文化してプロンプトへ 選んだエッジとスコアを L6 に全件記録する score = 類似度 × 減衰^ホップ数 × confidence × 時間減衰 × 文脈重複度
11. 外部 フレ ーム との 対応 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）
12. 課題 との 対応 冒頭の4つの課題は、どのあたりで解けそうか 1 関係が辿れない L1 L3 述語を型として定義し、三つ組で保持する。再帰CTEで2〜3ホップ辿 れば、担当者から上長へ到達できる 2 文脈が持てない L4 L6 同じエッジに文脈ごとの重みを持たせ、鮮度と併せてスコア化する。 案件が変われば同じ質問でも順位が変わる 3 数字が割れる L2 4 出典と鮮度が曖昧 L0 計算式を1箇所に置き、BI・エージェント・監査が同じ定義を読む。 未認証の指標はエージェントに渡さない L3 L6 出典なしのエッジを作らせず、verified_at で陳腐化を検知する。検 索記録から回答の根拠を再現できる L5 権限・ポリシー層はこの4つのどれにも直接は対応しないが、見せてよい範囲を先に確定する層として、4つすべての前提になりそう。
13. 気にな った 点 WHY をどこに置くかが決めきれない L4は「どの場面でどれだけ効いたか」までしか答えない。「なぜそう決めたか」の痕跡を置く場 所が見当たらない。 具体例 「案件Aの見積を10%下げた」という事実はL3に載る。しかし「なぜ下げたか」（競合の存在、上長の判断、過去の類似案件との比較）は、L0に原文と して埋もれるだけで、構造として辿る手段が思いつかなかった。 案1 L3に decision 型ノードを立てる 意思決定を実体として扱い、decided_by / justified_by（根拠エッジ群 ）/ superseded_by で繋ぐ。既存スキーマの延長で済みそう。 案2 L4を decision trace 層として再定義する 適用度の管理をL6のスコアリング側に寄せ、L4を判断の痕跡専用にする 。分類には忠実だが設計変更は大きそう。 適用度と意思決定痕跡は更新頻度も所有者も違いそうなので、同じ層に押し込むと両方が中途半端になる気がしています。
14. 体制 役割は3つに整理されていた 1 2 3 オントロジーオーナー ドメインオーナー コネクタ担当 1名（兼任可） 利用チームごとに1名 基盤チーム • L1の型と述語の最終決定権 • • • 複数人にしない — 合議制にすると語彙 は増える方向にしか動かない 自チームの知識が正しく載っているか に責任を持つ 外部システムからL0への取り込みに専 念 • ゴールデンセットの所有者をここにす る • 障害の大半はここで起きる。当番を明 示する L2セマンティック層の所有者だけは別で、売上の定義を決めるのは財務など事業側だ、と複数の資料が書いていました。 新しい述語の申請条件として、こうした3点を挙げる例がありました：① 既存の組み合わせで表現できない理由 ② 実データ20件以上の具体例 ③ それ を使う実際のクエリ
15. 進め方 着手順序 1 L1を用語集として始める 完全な形式モデリングではなく、20〜30語の述語リストと型定義から 2 L0とL5を同時に立てる 可視性の設計を後付けにしない 3 L3を1領域だけ埋める 高価値な1領域に絞り、その範囲で同義語・多義語を潰す 4 L6を最初から入れる 検索記録がないと、精度の議論が主観になる 5 L4を追加する 単一文脈で動いてから、文脈の切り替えを扱う 6 L2を並行で最小限 主要指標10個程度。数値の食い違いが表面化してからでは遅い 技術では決まらない部分 事実が矛盾したときに誰が調停するか / 誤答が事故になったときの責任分界
16. まとめ 1 7層を定義・事実・統制に分けると、所有者の違いが見えやすい 2 人が書くのは L0・L1・L2・L5 だけで、L3・L4 は作り直せる 3 可視性はグラフ展開の前に効かせる設計が多い 4 Gartner の切り分けで見ると、WHY の置き場所が曖昧 5 WHY は L3 に decision 型ノードを置く案が素直そう 公開資料を読んだ範囲での整理です。実際に組むなら、decision 型ノードの扱いと、最初に扱う1領域の選び方が論点にな りそうです