AIエージェントのためのデータ設計

AIエージェントに全社の業務を任せる段階で企業がぶつかる「データがつながらない・意味が揃わない・権限を渡せない・知識が個人に閉じる」という4つの壁。その解決の鍵は、モデル選定ではなくデータ設計にあります。
本セッションでは、ナレッジグラフDBによる確定的なデータ統合を軸に、オントロジー設計／全社ガバナンス／ノード・エッジ単位のRBAC／ベクトル検索だけでは精度が出ない理由とハイブリッド検索まで、AIエージェント時代のデータ基盤の考え方を解説します。

Transcript

1. JDMC WEBINAR 2026 AIエージェントのための データ設計 ナレッジグラフDBが実現する確定的データ統合 中嶋 大輔 | DevRev Inc. 2026.08
2. AGENDA 本日のアジェンダ 1 2 3 4 5 AIエージェントが「行動する」ために必要なデータの条件 オントロジー設計 - 確定的にデータを格納する仕組み 全社AIへ拡張するオントロジーとガバナンス RBAC - AIにも同じ権限制御を効かせる ハイブリッド検索 - Vector検索だけでは精度が出ない理由
3. ABOUT DEVREV DevRev 会社概要 創業者 Dheeraj Pandey 設立 資金調達 投資家 従業員 拠点 認証 2020年10月（米国カリフォルニア） $200M調達、ユニコーン（$1.15B評価） Khosla Ventures、Mayfield Fund 750名以上（エンジニア比率70%+） グローバル8拠点 SOC 2 Type II / AWS ISV Accelerate Nutanix共同創業者・元CEO（NYSE上場、$15B+） Forbes 2024 アメリカ最優良スタートアップ選出 エンタープライズ向けインフラ設計の実績20年+ 日本市場へのコミット 日本法人設立済み・日本語サポート提供。東京オフィス （渋谷スクランブルスクエア39F）を拠点に展開。
4. 1 個人のAI活用から、 全社で使えるAIへ チャット・検索・分析・Workflow・AIエージェント
5. CHALLENGE 個人活用から全社AIへ – 4つの壁 個人ならすぐ使えるAIも、組織の業務を任せる段階で壁にぶつかる 1. データがつながらない 2. 意味と文脈が揃わない 例: 顧客の商談・障害・契約を横断して影響を判断できない 例: Salesforceの「顧客」は見込客、Jiraの「顧客」は利用者 3. 権限と責任を渡せない 4. 知識が個人に閉じる 例: 営業には商談を見せたいが、開発の内部調査メモは見せられない 例: 熟練者の障害対応の判断理由が、次の担当者に引き継がれない CRM、ERP、サポート、開発、文書・会話に情報が分散。AIは局所的な 情報しか参照できない。 機密情報の境界、誰が何を見られるか、AIの実行範囲が曖昧なままでは 全社展開できない。 同じ「顧客」「案件」でも部門・システムで意味が異なる。関係性を持 たないためAIが推測で補う。 判断理由や成功・失敗の経験が会話・担当者の頭の中に残り、チームや 全社のAIへ再利用されない。 AI Ready化とは、モデルを導入することではない。データ・意味・権限・組織知を、AIが安全に使える形へ整えることである。
6. WHY MEMORY MATTERS AIに何を渡すかで、AIは推測から判断へ進化する MCPで都度取得するAI DevRevのナレッジグラフを渡すAI 質問のたびに、複数システムへ接続して情報を集める 顧客・商談・障害・手順・判断履歴を、関係性・時系列・権限とともに構造化 業務の事実・関係・履歴・判断 AI Agent 商談 顧客 MCP / API 接続 手順書 Issue CRM 商談 Support Ticket Dev Docs Issue AI Agent 役割別の回答 関係性 · 時系列 · RBAC を保持 手順書 断片を都度収集 → 関係性・最新性・権限をAIが推測 必要な事実と文脈だけを、権限に応じてAIへ渡す AIは推測ではなく、つながった組織知をたどって判断できる 違いは接続の数ではない。AIが毎回データを探しに行くか、事実・関係・履歴・判断理由を備えた業務記憶を受け取るかで、正確さ・安全性・再現性が変わ る。 確定的ルール: 名寄せ・関係性・権限・業務ルール LLM: 意図理解・説明・提案・生成
7. ENTERPRISE-BENCH 構造化した業務記憶は、全社AIの精度・コスト・信頼性を変える 同一モデル（Opus 4.8）・同一データ・同一判定者。差はモデルではなく、顧客・案件・対応履歴などを関係と権限付きで届けるデータアーキテクチャ。 UC Berkeley Dimakis教授が検証。 精度（XLデータセット） トークン効率 vs Claude Code 63.6% 少ない（5,598 vs 24,461/正答） 94.3% 評価する3つの観点 Precision 精度 正しい答えを、正しい出典から。 Efficiency 効率 正答あたりのトークンコスト。 Safety 安全性 権限を守り、監査可能にする。 4.4× スケール時のコスト ほぼ横ばい vs Claude Code +29%増 ベンチマークの条件 CRM・開発・サポートを横断する実タスク。 データ量を1x〜256xへ拡大し、正解は固定。 各タスクを10回試行し、一貫性を測定。 データセット・判定基準・トレースを公開。 github.com/devrev/enterprise-bench
8. 2 オントロジー設計 確定的にデータを格納する仕組み オントロジー = エンタープライズの論理データモデル 概念・関係・制約を定義し、業務イベントに応じてグラフ構造として継続的に更新・運用する仕組み
9. BASICS ナレッジグラフの基本構造 提案中 顧客 Rev User 報告した 商談 Opportunity チケット Ticket プロパティ例（商談） 対象 関連 amount: ¥12,000,000 製品 stage: "Proposal" close_date: 2026-03-31 Product ↑ 各ノード・エッジは属性（プロパティ）を保持 プロパティ例（顧客） プロパティ例（チケット） プロパティ例（エッジ:報告した） name: "田中太郎" title: "ログイン不可" reported_at: 2026-02-14 email: "tanaka@acme..." status: "In Progress" severity: "High" tier: "Enterprise" priority: "P1" channel: "Support" ノード（エンティティ） エッジ（関係性） プロパティ（属性）
10. INTEGRATION なぜグラフで柔軟にデータ統合できるか Salesforce 商談データ FY26商談 ¥12M / 提案中 提案先 サポート 顧客・問い合わせ バグ・課題 共通ノード Account バグ #1234 複数ホップで得られるインサイト 製品X 顧客 ACME 報告 Jira 対象製品 影響する P1 / 未修正 新システム追加時: スキーマ再設計不要、ノードとエッジを継ぎ足すだけ 〔P1バグ #1234〕→ 製品X ←〔FY26商談 ¥12M〕（同一製品） "このP1バグを直さないと ¥12Mの商談が失注する" 単一システムでは決して繋がらない関係
11. PRODUCT · 実画面 Salesforce由来のアカウントが、そのままグラフに 外部システムの正データを取り込み、顧客（Account）ノードとして統合。名前・ドメイン・所有者・取込元タグまで確定的に保持する。
12. PRODUCT · 実画面 アカウントに商談が関係性で紐づく 同一顧客に属する商談を、ステージ付きで横断表示。単一システムでは分断される「顧客 → 商談 → ステージ」が1本の線でたどれる。
13. 3 全社AIへ拡張する オントロジーとガバナンス 全社標準化と部門の自律性は、二者択一ではない
14. ENTERPRISE ONTOLOGY 全社オントロジー = 共通コア + ローカル拡張 Sales Support Opportunity · Forecast Ticket · Incident · SLA Enterprise Core Ontology Account · Person · Product · Contract Document · Team · Event · Case Engineering Issue · Release · Component Finance / Operations Invoice · Asset · Cost Center 全社で共通化するのは、すべての項目ではない。部門を横断してつなぐための識別子・基本概念・関係性を共通コアとして定義する。
15. ONTOLOGY GOVERNANCE 全社化を止めない4つのガバナンス 1. 共通コアの管理 2. ドメイン拡張の自律性 例: 「顧客」の識別子と定義は全社で1つに決める。 例: サポートはSLA、開発はComponentを独自に追加する。 3. 変更の審査と履歴 4. 権限と監査 例: 「契約」と「商談」を結ぶ新しい関係を登録前に確認する。 例: 営業は商談を参照できるが、価格戦略メモは役員限定にする。 Account、Person、Product、Contractなど、全社横断概念の責任者を 置く。 新しい概念・関係性・名寄せルールをレビューし、変更の影響範囲を追 跡する。 部門はドメイン固有オブジェクトや属性を追加。共通コアを直接変更せ ずに進化させる。 データ分類、可視性、AIの実行権限を定義し、参照・変更の履歴を監査 可能にする。 ガバナンスとは、中央で全てを承認することではない。コアは強く統制し、拡張は現場に委譲することで、標準化の速度と柔軟性を両立する。
16. ORGANIZATIONAL MEMORY Memoryを全社・チーム・個人で使い分ける 共有範囲を分けても、すべては同じ業務記憶と権限モデルの上で機能する 全社の共有Memory 顧客・製品・契約・全社手順・横断的な判断履歴 チームの共有Memory サポートの対応基準・開発の運用知・チームの判断 個人のComputer Memory 個人の指示・スキル・接続・会話から得た有用な文脈 役割に応じたAI Agentが、必要なMemoryを活用 全社の経験を共有しながら、チームと個人の文脈も次の判断と行動へ生かす。 Memoryとは、顧客・商談・障害・手順・対応履歴と、その関係・時系列・判断理由を再利用可能にした業務記憶。全社・チーム・個人の各レイヤーで蓄積 され、AIが次の判断と行動に生かす。
17. ONTOLOGY DevRevオントロジーの構造 営業・カスタマーサポート・プロダクト開発の構造化データと、KB・会話などの非構造化データを同じグラフで扱う Sales / Revenue Support / CX 商談・パイプライン管理 Product / Engineering 問い合わせ・チケット対応 開発・バグ管理・リリース Core Objects Account Opportunity Rev User Meeting Ticket KB / 非構造化 Issue Local Objects Conversation Typed Relationships (Edges) Article Conversation Event owns | reports_to | linked_to | created_by | applies_to | part_of | ... Parts (Product Hierarchy) Product Capability Feature 営業・サポート・開発の業務ドメインを横断して関係性がビルトイン Enhancement
18. CORE MECHANISM 確定的格納 - 宣言的マッピング 課題: AIの推測に任せると関係が揺らぐ 解法: 宣言的マッピングで関係を確定 例 Salesforceの「ACME株式会社」とZendeskの「ACME Corp」を、AIが 毎回“同じ顧客らしい”と推測する。 例 メール・ドメイン・外部IDをマッチキーとして定義し、同一顧客へ一意 に統合する。 ルールなしにグラフ化すると、名寄せ・表記揺れ・関係性の判断が都度 変わりうる。 MDMの名寄せ・マスタ統合を含み、スキーマ変換・関係性生成・権限 適用までをルールとして定義する。 具体例: Salesforceの商談レコードを、ノードと関係性へ確定的に変換 入力 商談: FY26 拡張商談 AccountId: 001xx OwnerId: 005xx → 定義済みルール 商談 → Opportunity AccountId → belongs_to OwnerId → owned_by → 確定した関係 FY26 拡張商談 → ACMEに所属 → 田中が担当 結果: 「この商談はどの顧客・担当者に属するか」をAIが推測しない。同じ入力なら常に同じグラフ（確定的）となり、後続の回答・通知・アクションも同じ 根拠で実行できる。
19. DETERMINISTIC GRAPH GROWTH 業務イベントで確定的にグラフが成長する 業務イベントごとに、定義済みのノードと関係性が追加される（クリックで段階表示） belongs_to 佐藤（顧客） Rev User created_by reported_by ACME Corp Account (from Salesforce) TKT-3021 ISS-892 has_opportunity owns Opportunity applies_to affects Issue (from Jira) assigned_to targets Platform v3 Product (Parts) documented_by 仕様書 / FAQ 鈴木（開発） Dev User Dev User FY26 拡張商談 Ticket (from Zendesk) linked_to 田中（営業） Article (KB) Step 1/5: アカウント作成
20. ARCHITECTURE DWH / Lakehouseとナレッジグラフは補完関係にある DWH / Lakehouseは保存・集計・MLを担い、ナレッジグラフとデータカタログは構造・関係・意味・権限を業務文脈としてAIへ提供する DWH / Lakehouse = 外部記憶装置 操作ログ (100億行) ナレッジグラフDB = メインメモリー メタデータを カタログ化 契約 ACME 在庫・部材マスタ 大規模な実データを保管 = CPU 構造・関係・意味を業務文脈として扱う 部材トランザクション (数千万件) 契約・利用履歴 LLM 利用 文脈・パス 部材 製品 障害 - ACME → 契約 → 製品 → 部材 → 障害 - tenant_id / module_id を確定 - 必要なSQLアクセスパスを特定 必要な行をオンデマンドで参照 障害内容を理解 グラフから検索条件を取得 ピンポイントSQLを発行 原因候補・対応案を生成 全データをLLMに渡さない 文脈からアクセスパスを特定 例: ACME社から「部材発注モジュールでシステムエラーが頻発」と連絡 グラフで tenant_id / module_id を確定し、過去24時間の操作ログ・部材トランザクションから該当行だけを参照 原因候補・影響範囲・回避策・担当者への連絡案を作成 グラフが強い: 関係をたどるマルチホップ検索 価値は個々のオブジェクトよりオブジェクト間の関係（リンク）にある。 「顧客→契約→製品→部材→障害」を1本の線でたどれる。 DWH / Lakehouseが強い: 大量データの保存・集計・ML グラフはOLTPで常時大量に書き換わるリンク・属性更新には弱い。だか ら大量トランザクションはDWHが担う。
21. WHY DETERMINISM MATTERS LLMに確定すべき業務事実を任せない LLMは自然言語理解・説明・提案に強い。一方、名寄せ・関係性・権限などの業務事実は、再現性と監査性のあるルールで確定する。 1. 同じ入力でも、関係が変わりうる 2. 誤った関係が後続判断を汚染する 例: 「ABC Corp」と「株式会社ABC」を毎回推測で名寄せする。 例: 別顧客の障害情報を、誤った営業担当へ通知する。 3. 修正・監査の根拠を説明できない DevRev: 関係は宣言的に確定する 例: 監査時に、関係性を作ったルールを示せない。 同じ入力 → 同じグラフ → 同じ根拠で検証・改善できる。 表記ゆれや文脈の解釈により、ある回は同一顧客、別の回は別顧客と判 定される可能性がある。 「なぜこの2件を関連付けたのか」が、プロンプトやモデルの挙動に依 存すると、業務ルールとして検証できない。 一度誤ってTicketとIssue、顧客と商談を結ぶと、その誤りを前提に回 答・通知・アクションが連鎖する。 一次データのID・定義済みマッピング・型付き関係で、ノードとエッジ を一意に決定する。 LLMは構造化された事実を使って判断する。業務の事実と関係性そのものを、毎回LLMに推測させないことが、AI Ready化の設計原則である。
22. 3 Sub-type / Custom Objectで オントロジーを柔軟に拡張 全社オントロジーを、コアを壊さずに現場の業務へ拡張する
23. FLEXIBILITY 1 Sub-type - 型の継承による拡張 Ticket Incident Problem Question 親の属性: title, status, priority, owner ... + Incident固有: severity, impact_scope + Problem固有: root_cause, workaround Task 基本オブジェクトを継承して特化型を作成 親の属性・関係性はそのまま引き継ぐ 子独自の属性を追加可能 既存のグラフ構造を壊さずに拡張できる
24. FLEXIBILITY 2 Custom Object - ドメイン固有ノードの追加 標準オブジェクトのグラフ Opportunity Account 顧客 Custom Objects governed_by 契約 商談 Ticket 問い合わせ applies_to covers 資産 (CMDB) 変更管理 独自ノードも、標準ノードと同じ関係性・検索・RBAC・AIアクションに統合される
25. ARCHITECTURE 固い基盤 + 柔軟な拡張 = 運用しやすいグラフ Typed Edges (型付きエッジ) すべてのレイヤー間を型安全に接続 Extension 1: Sub-types Incident | Problem | Question | Task | ... Extension 2: Custom Objects Contract | Asset | Alert | SLA | Project | ... Base: DevRev Core Ontology Account | Ticket | Issue | Opportunity | Article | Conversation | Meeting | Dev User | Rev User Schema Evolution: コアは全社で統制し、拡張は各部門が担う。Sub-type / Custom Objectを分離することで、ベースのクエリパスを壊さずに全社AIへ接続 できる。
26. 4 RBAC - AIにも同じ権限制御を効かせる
27. PERMISSION-AWARE MEMORY ノード／エッジ単位の権限を、AIにも適用する 外部ソースの権限を引き継ぎ、未設定のデータはDevRev側で補完する。人間が見えないデータは、AIも参照しない 外部ソースの権限 Google Drive / SharePoint 文書の共有相手・グループ フォルダから継承した共有範囲 CRM / 業務システム Owner・担当チーム・レコード種別 権限なし／複雑な共有ルールもありうる DevRevの権限レイヤー 共有設定を反映する 権限がないデータも後から設定 権限付き業務Memory 顧客 商談 文書 グループ・ロール・個人で補完 オブジェクト単位で可視性を確定 外部権限は引き継ぎ、未設定のデータにはDevRev側で可視性を後付する AIは許可された記録だけを参照
28. EXAMPLE グラフ上でのRBAC - 誰が読めて、誰が変更できるか ACME Corp Account TKT-3021 OPP: $2M 拡張商談 ISS-892 (P1 Bug) 価格戦略メモ Ticket (Support: R/W) Sales: R/W | Support: R O O Engineering: R/W | Support: R 佐藤（サポート） TKT: R/W | OPP: R | ISS: R 幹部のみ Executive: R/W 田中（営業） OPP: R/W | TKT: R | ISS: – 鈴木（開発） ISS: R/W | TKT: R | OPP: – 山田（幹部） 全ノード: R/W（価格戦略含む） 同じグラフでも、ロールごとにRead / Writeの範囲が異なる。AIにも同じ権限が適用されるため、参照だけでなく更新・通知などのアクション範囲も統制でき る。
29. FROM ANSWER TO ACTION グラフ化された業務記録が、AIの根拠あるアクションを可能にする AIはグラフの関係性を根拠に、正しい対象・関係者・業務ルールを特定してから、レコードの作成・更新や通知を実行する。 グラフ化された業務記録 顧客 · 商談 · 障害 担当者 · 手順 · 履歴 関係性 · 権限 · 根拠 根拠ある業務アクション AIの判断・提案 正しい対象・関係者を特定 根拠付きで対応を組み立てる 承認が必要な箇所を明確化 自動返信 関係者通知 CRM更新 Human-in-the-loop: 影響の大きい操作は人が承認 業務レコードの作成・更新・通知が、グラフの状態と関係性に反映される 確定的なデータ統合があるから、AIは「誰に」「何を」「どの権限で」実行するかを特定できる。実行結果は業務記録として蓄積・同期され、次の回答・判 断・アクションの根拠になる。
30. CHALLENGE 一般的なグラフDBの課題 設計と運用の壁 Neo4j / Neptune などでゼロから構築する場合、各工程を自前で設計・実装する必要がある オントロジー設計を一から 名寄せ・表記揺れの解消 スキーマ変更の影響範囲 運用中のデータ品質維持 ETLパイプラインの保守 設計例: Customer / Deal / Ticket 等のノード型と OWL/SHACL で属性・制約を定義（数ヶ 月〜数年） 設計例: 「ABC商事」=「ABC Corp」=「KUNNR:0001234」を紐付ける照合ルール／類似 度しきい値を実装 設計例: エッジ型を1つ追加するたびに既存クエリ・下流処理への影響をマニュアル調査 設計例: 孤立ノード・重複・欠損エッジを検知する監視ジョブと修復フローを構築 設計例: システムごとに抽出・変換・ロードのジョブを個別実装し、増分同期・失敗リト ライも自作 では、この5工程をゼロから設計・運用せずに、どう導入するか？
31. DEVREV'S APPROACH DevRevの解法 Pre-designed Ontology スライド前半の5工程を、DevRevは製品として事前実装済み — 自前構築との対比 工程 オントロジー設計 関係性（エッジ） 名寄せ・表記揺れ ETL・同期 拡張性 自前構築なら 型・属性・制約をゼロから定義 エッジ型を都度設計・追加 照合ロジック・しきい値を実装 抽出・変換・増分同期を自作 スキーマ変更の影響を都度調査 DevRevなら エンタープライズ向けの型を標準搭載 業務をまたぐ関係の型を標準搭載 宣言的マッピングで自動解決 AirSyncの双方向同期を標準搭載 Sub-type / Custom Objで柔軟に拡張 導入初日から 使えるグラフ 設計期間 数ヶ月〜数年 → 0日
32. 5 ハイブリッド検索 ベクトル検索だけでは精度が出ない理由
33. HYBRID SEARCH 5つのエンジンを統合したハイブリッド設計 コンポーネント 解決する問い グラフDB 転置インデックス ベクトルDB（セマンティック検索） DWH インメモリー時系列DB 何と何が繋がっているか この用語を含むデータはどれか この意味に近いデータはどれか いくつあるか、合計はいくらか いつ起きたか、推移はどうか SQL・グラフ・セマンティック検索を組み合わせ、対象と意味を正確に捉える
34. EXAMPLE 実例: SQL + セマンティック検索の組み合わせ 「ACV $1M以上で、Platform v3が対象の商談を持つ顧客に、導入手順を案内したい」 SQLで対象と製品を確定し、その製品にひも付くKBだけを意味検索・再ランク付けする 「ACV $1M以上で、Platform v3が対象の商談を持つ顧客に、導入手順を案内したい」 SQLを生成する 1 自然言語の条件を、正確なSQLへ変換。 SELECT a.name, kb.title FROM opportunity o JOIN account a JOIN part p JOIN article kb ON kb.part=p.id WHERE o.acv > 1000000 AND p.name = 'Platform v3' SQLで絞り、グラフでつなぐ 2 対象顧客 → 商談 → 対象製品をたどり、 Platform v3にひも付くKBだけを特定。 顧客 商談 製品 意味検索 + 再ランク付け 3 12件のKBノード（ガイド・FAQ・手順書）を 「導入手順」の意図に合わせて再順位付け。 KB 対象商談 → Platform v3 に関連するKBノード 12件 出力: 対象顧客（Account） 案内するKB（Platform v3・導入手順） ・ACME株式会社（ACV $2.4M） ・Platform v3 導入ガイド / 初期セットアップ ・Northridge電子（ACV $1.3M） ・移行手順 FAQ ほか（再ランク上位） Vector search → Rerank 用途に必要なKB集合をAIへ渡す
35. PRODUCT · 実画面 自然言語の問いに、根拠オブジェクトを添えて回答 「関連する商談を、ステージとSalesforce由来かも含めて列挙し、根拠のオブジェクトも出して」— SQL・グラフ・意味検索を組み合わせ、根拠まで示して答え る。
36. PRODUCT · 実画面 回答の裏側は、実際に発行されたクエリで追える 前ページの回答の実行トレース。AIが生成したSQL・入力・出力（origin_system や根拠オブジェクト）がそのまま記録され、なぜその答えになったかを検証で きる。
37. PLATFORM OVERVIEW 企業のAI化を実装する、DevRevの全体構成 AirSyncによるデータ連携 → Shared Memory（Knowledge Graph） → AI Agent & Workflow DATA SOURCES Salesforce / SAP ServiceNow / Jira Teams / Slack SharePoint / Confluence 業務DB / ERP GitHub / DevOps AirSync 双方向データ同期 スキーマ自動検出 ACL/権限メタ同時抽出 差分検知・増分同期 ベクトル化+グラフ構造化 読み書き双方向 Knowledge Graph エンティティ間の関係性を構造化 Vector DB + Text2SQL ハイブリッド検索エンジン Time Series DB 時系列で事実・イベントを記録 双方向同期 AI Agents & Workflow 目的に応じたエージェント群 CX Agent 問い合わせ自動対応 Search Agent 社内横断検索 Sales Agent 営業支援・提案生成 Custom Agent 業務特化エージェント Workflow Engine Multi-Fence Zones 条件分岐・承認フロー・自動アクション Grounding & Citation ノーコードでエージェント構築・テスト・デプロイ 知識基盤 実行・回答・アクション エンティティ単位ACL / 権限制御 100+ コネクタ対応 既存環境を維持 Computer Memory 全エージェント共有の知識基盤 Agent Studio 根拠付き回答 / ハルシネーション排除 取込・変換
38. SUMMARY まとめ - 3つのキーメッセージ 1 AIの回答品質は、データ設計で決まる 業務の事実・関係・権限は確定的に統合し、LLMにはその事実を使った理解・判断・生成を任せる 2 全社では、共通コアとローカル拡張を両立する 共通概念・関係・権限を統制し、部門固有の業務知識は安全に追加・運用する 3 構造化された業務記憶が、根拠あるAI活用を可能にする 自然言語での検索・分析から、承認可能・監査可能な業務アクションまでを支える
39. ご質問・ディスカッション
40. Let’s connect. ご清聴ありがとうございました。 THANK YOU FOLLOW DevRev / Computer の導入・活用のご相談、デモのご 依頼はこちらへ。最新情報は X・YouTube でも発信し ています。 X @DevrevJapan CONTACT US YOUTUBE @DevRevJapan japan-contact@devrev.ai AIエージェントのためのデータ設計 | JDMC ウェビナー 2026
41. APPENDIX 実装の補足 データ連携と名寄せ
42. AIRSYNC データの確定的リンク AirSync 外部システムの正データを、定義済みのルールで共通の業務記憶へ接続する Salesforce Jira Zendesk Slack, Google... AirSync Knowledge Graph 宣言的マッピングルール 双方向同期 同一エンティティの名寄せ: メール・ドメイン等をキーに自動マッチ 新規エッジも同期時に自動生成 → 人手を介さずグラフが自律的に成長 例: Salesforceで「FY26 拡張商談」が作成されると、商談ノードを作成し、AccountIdで顧客へ、OwnerIdで担当者へ接続する。次にZendeskの問い合わせ やJiraのIssueも同じ顧客・製品との関係で追加される。
43. ENTITY RESOLUTION 名寄せの具体例 - 同一人物の自動マッチ 各システムでの表記 Salesforce Name: 山田 太郎 Role: 決裁者 Email: t.yamada@acme.co.jp Account: ACME株式会社 Email (一致) Domain (一致) 商談 $2M 山田 太郎 Zendesk Rev User (統合済み) Name: Taro Yamada Org: acme.co.jp Email: t.yamada@acme.co.jp 30件のチケット Slack マッチキー Email: t.yamada@acme.co.jp Account: ACME Corp Role: 決裁者 | Tickets: 30 | Messages: 120 Display: yamada-t Channel: #acme-support Email: t.yamada@acme.co.jp 120件のメッセージ 表記が異なっても、Email/Domainをキーに自動統合 → 1人の顧客に全コンテキストが集約 TKT-3021 (P1) 会話履歴 120件
44. APPENDIX · USE CASE ユースケース例 障害連絡を、原因・影響・次アクションへ 製造業ACME社のサポート担当が「部材発注モジュールでシステムエラーが頻発」という連絡を受けた場面。確定的グラフ・マルチホップ・権限制御が1つのタ スクで働く。 ① 担当者がComputerに投げる指示 ② 裏側: グラフを関係でたどる（マルチホップ） ACME 顧客 「ACMEから部材発注モジュールでエラ ー多発と連絡。過去24時間で何が起きて る? 原因の候補と、影響しそうな商談、 担当者への連絡文案まで出して。」 障害 · Issue 契約 · 製品 操作ログ ISS-892 24h / DWH参照 RBACで可視範囲を制御 営業 · サポート 部材発注 module_id 確定 商談 ¥12M 同一製品に依存 担当者 関係をたどり、必要な行だけDWHから参照 · 権限内の情報のみ返す ③ Computerのアウトプット 原因候補 リリース R3.2 以降にエラー急増。ISS-892 と 同一のスタックトレース。 影響範囲 同一製品に依存する FY26拡張商談 ¥12M に失 注リスク。 次アクション（実行可能） 営業担当へのSlack連絡文案 ＋ 顧客への一次 回答ドラフトを生成。 1つの指示が、確定的な関係をたどって（マルチホップ）原因・影響・関係者・アクションへ到達する。AIは推測ではなく、つながった業務記憶を根拠に、権 限の範囲内で答えて動く。