データエンジニアこそ組織のオントロジーに向き合うべき — 問いに答えるAIから、事業を動かすAIへ

第66回 MLOps/LLMOps/AgentOps 勉強会

https://mlops.connpass.com/event/400451/

Transcript

1. データエンジニアこそ 組織のオントロジーに向き合うべき harry (@gappy50) クラシル株式会社
2. 自己紹介 harry (@gappy50) クラシルのデータ基盤構築と全社アーキテクチャ設計、データのAI活用を担当 いまはAI事業部で新規事業を推進 Snowflake Data Superheroes（2022〜） 2
3. Kurashiru AI OS メーカー・卸・小売向けの外部サービス（情報 / オントロジー / AIエージェントの三層） 既存の基幹システムやERPと連携 出典: クラシル株式会社プレスリリース（2026-05-07） 3
4. これまでのデータ×AI活用
5. クラシルの現在地 データ品質をボトムアップで育て、AI活用につなげる Tier 1 2 3 4 5 用途 監査・外部公表 経営KPI 部門意思決定 アドホック分析 個人試行 責任者 データエンジニア データオーナー データオーナー アナリスト 個人 品質 全テスト・完全ドキュメント 全テスト・完全ドキュメント 基本テスト・メタデータ完備 dbtモデル化 SQL直書き TTL AI 永続 永続 永続 90日 30日 ✓ ✓ ✓ ✗ ✗ アドホック分析のデータモデルにTierとクラスを定義し、品質と捨てやすさを両立するDataOpsを運用している Tier 3以上はAIが同じ答えを返しやすい セマンティックレイヤーも定義の延長で揃う 参考: dely Tech Blog「AI-Ready DataOpsの実装：Tier定義による段階的なデータガバナンス」 5
6. 一般的なデータ活用 数字が揃っても、業務は現場に残る セマンティックレイヤーの整備で、「欠品率は何％か」という問いにはAIが正しく答えやすくなった それでも、数字が揃ったあとの業務は現場に残る 数字をExcelへ貼り、チャットで承認し、ERPへ手入力する 誰が何を決め、結果どうなったかがデータに残らない Claude Codeなどで作業が速くなっても、問いを立てるだけのAI活用では、基盤モデルの費用が運用費になる 6
7. 一般的なデータ活用 業務全体を見ると、データ活用には隙間が残る ビジネスアーキテクチャ（BA）で業務全体を一連の流れとして見ると、データアーキテクチャのカバレッジはまだ 限られている 工数不足で未連携のシステム、部門ごとのサイロ、メール・電話・紙など構造化されていないやり取りを、Excel・ チャットと人の運用がつないでいる 業務全体を一気通貫で扱うには、散在する情報と判断・操作を同じ業務モデルに位置づける必要がある 7
8. Ontologyとは
9. オントロジーとは？ もとは哲学の「存在論」。情報系では、RDFで関係を表し、OWLで語彙と意味を定義する系譜がある この資料では、業務の対象・関係・状態・操作を、共通の意味と権限で扱うモデルをオントロジーと呼ぶ AI活用では、読むための定義に加えて、業務を動かすモデルまで扱う セマンティックレイヤーは「先週の欠品率は何％か」という読むための定義を揃える 発注対象、承認者、更新先、結果は、いまも人の頭とExcelやスプシに分散している 9
10. Ontologyが担うのは、業務の状態とAction AIに何を渡すか、どう探すか、業務をどう表して動かすかは、別の設計論です。 仕組み 主な役割 Ontologyとの関係 コンテキストレイヤー 文書・メタデータ・ルール LLMへ背景・根拠・制約を渡す 通常は、業務の現在状態や更新履歴の正本で はない ナレッジグラフ エンティティと関係をグラフで表す セマンティック部分を表現できる。Action・ 権限まで含むとは限らない RAG / Agent RAG 必要な情報を検索し、LLMへ渡す Ontologyを検索先にできる。検索・生成の 方式であり、業務モデルではない Ontology 対象・関係・状態・Action・権限を共 人とAIが同じ業務を読み、管理された操作で 通モデルにする 更新する この資料での意味 参考: W3C OWL 2 Overview / Lewis et al., Retrieval-Augmented Generation (2020) / Palantir Ontology overview 10
11. オントロジーで業務の分断をつなぐ 理想 現実 基幹システムやSaaSが業務を覆い、 業務の変化に仕組みが追いつかず、 プロセスを自動化する サイロや隙間を人がつなぐ 目的ではなく、手段としてのオントロジー 手段 対象・関係・状態・操作を、 共通の業務モデルへ結び直す 目指すのは、ビジネスアーキテクチャ（BA）全体をデジタル上で扱い、AIが業務をまたいで動き、改善を続けられる状態です。 オントロジーは、その実現に必要なら使う手段です。 11
12. Palantirで見るOntology
13. Palantirのオントロジー Object Type 店舗・商品などの業務対象 Action Type 操作を定義する ← Link Type Object Type Object同士を関係づける → 提案・発注などの業務対象 状態・関係を変更 Object / Link → 作成・更新・削除 権限 Objectの閲覧とActionの実行を横断して制御する Object Typeの裏側は普通のデータセットで、テーブルとの違いは、取りうる状態と操作・権限まで宣言する点 権限があるので、提案までは自由にさせつつ、金額上限や人の承認という境界を発注Actionの制約としてモデル側に 引ける 出典: Palantir “The Ontology system” 13
14. Foundry Pipeline Builder 基幹・SaaSのデータを 変換・結合 出口にObject / Linkを直接 指定 Ontology → Objectの裏は普通のデータセット 書き込みはAction経由のみ Action / Webhook → ActionからERPを更新 成功後にOntologyへ反映 Vertex Object同士の関係をグラフで探索し、業務の状態や影響を確認する Foundryは、基幹・SaaS・ファイルを接続・変換し、分析・機械学習・Ontologyで使うデータを整える Actionに設定したWriteback Webhookから業務システムを更新する。権限と実行条件はOntologyで管理する 出典: Palantir Foundry / Pipeline Builder / Vertex overview / Explore object relationships / Scenarios documentation 14
15. AIP AIモデル LLM・マルチモーダルモデル ↔ AIP Logic・Chatbot Studio・Evals ↔ 業務の状態と操作 Object・Linkを読み、 Actionを実行 AIPは、LLMなどのAIモデルをFoundryのデータと業務へ安全に接続するための製品群 AIP LogicでFunctionを組み、Chatbot Studioで対話型のAgentを作り、AIP Evalsで品質を評価する AIに任せる範囲は用途ごとに選ぶ。回答・提案だけ、人の承認後にAction、自動実行まで段階を分けられる 出典: Palantir AIP overview / AIP Logic / AIP Evals documentation 15
16. 防衛領域の公開事例
17. Gotham 防衛・情報機関向けの意思決定基盤。複数システムの人物・車両・出来事を同じ対象として検索・分析できる状態へ 揃える 別々の記録 システムごとに登録された同じ 人物・車両・出来事 → 一つのObjectへ統合 共通の識別子へ寄せ、各ソースの履歴 を保持する → 同じ対象を追える 地図・検索・分析から、関係・ 履歴・元の記録へ戻れる 目指すのは、地図と報告書で見た車両が同じObjectとしてつながり、別々に扱われない状態 権限によって見える情報が異なっても、対象の識別子とソースごとの履歴は共有できる 出典: Palantir Gotham API “Object resolution basics” / RevDB documentation 17
18. Maven Smart System 監視データを統合 衛星・偵察機・既存システムを 共通状況図へ集める → AIが対象を検出 候補を画面へ出し、人が別の情報源と 照合する → 人が判断する 確認した情報を指揮統制の意思 決定へ使う Maven Smart Systemは、センサーデータとアルゴリズムを使い、対象の識別と指揮系統の判断を支援する意思決定 システム PalantirはDefense Ontology用のOntology SDK（OSDK）を案内しているが、Maven固有のObject・Link・Action 設計は公開していない。Ontologyの利用箇所は公開情報だけでは断定できない 出典: Palantir Defense / Gotham API “Defense OSDK” / 米国防総省 Maven Smart System公開情報 18
19. 周辺製品との比較
20. 営業対象の情報管理から業務オントロジーまで 比較軸 位置づけ Clay Rox Palantir 営業対象の継続プロファイル 汎用的な業務オントロジー 対象と関係 企業・人物の属性 Agentの操作 情報を補完・調査し、 CRMへ同期 営業領域のナレッジグラフ 企業・人物・商談・活動を グラフ化 調査・提案を行い、 営業業務を実行 モデルの範囲 対象の情報が中心 対象・関係・Agentの操作 Object / Linkを型として定義 権限・実行条件に沿って Actionを実行 対象・関係・状態 操作・権限 Clayは対象の情報を持ち、Roxは関係と業務をつなぎ、Palantirは操作と権限まで共通モデルにする。 注: 3製品の位置づけは、業務対象・関係・操作の範囲を比較するための発表者の整理 20
21. Rox 業務対象をつなぐ System of Context 企業・人物・商談を統合 調査・提案を分担 → Agent Swarm 案件ごとに必要な処理を行う 業務ツールへ反映 → System of Actions CRM更新・メール作成 重要な操作は人が確認 企業・人物・商談のナレッジグラフ（Knowledge Graph）を継続的に更新し、Agentが調査・提案を分担する PalantirのObject / Link / Actionとの対応は、同じ設計軸で見るための発表者の整理 出典: Rox公式ドキュメント “System of Context” / “Agent Swarm” / “System of Actions” 21
22. Clay Audiences Audiencesは、営業対象となる企業・人物の情報を集め、最新の状態で持ち続ける機能です。 企業・人物を集める 情報を調べて補う 営業活動に戻す CRM・データウェアハウス・ → データ補完・調査Agent 最新情報をCRMへ同期 → 外部データ 属性やシグナルを更新 Agentの更新は人が承認 同じ営業対象としてまとめる Clayは企業・人物の営業調査とCRM連携が中心です。LinkやAction権限の扱いはPalantirと異なります 出典: Clay University “Audiences” / “Account Research Agents” 22
23. 具体例：オントロジーで在庫補充を つなぐ
24. 店舗Xでは、週末までに飲料Aが16ケース足りない 週末までの需要 − 需要予測20ケース 現在庫 4 ERP ケース 不足 ＝ 20 − 416ケース 24
25. 不足16ケースの提案・承認・発注がつながっていない 順番 1 2 3 4 現場の動き 「16ケース補充しよう」と決める 店長へチャットで確認する OKをもらってERPへ手入力する 納品できたか、欠品したかを見る 記録の状態 判断の根拠は記録されない 承認はチャットに残る 発注結果だけがERPに残る 結果は提案・承認と結びつかない 提案の根拠、承認、発注、納品結果が、担当者の記憶、チャット、ERPなどに分散している 個々の記録が一連の判断として結びついていないため、次の改善に使いにくい 25
26. 補充提案を作る 実行する人 Agent / 発注担当 実行条件 店舗・商品・在庫・需要予測が揃う 対象 現在庫 需要予測 補充提案を1件作る Object Type：補充提案 Object Type：店舗別商品 ST-X-A 結果 RP-001 店舗X × 飲料A 4ケース 20ケース 補充を提案する 提案数 16ケース Action 理由 週末イベントで来店増（店舗メモ） 状態 承認待ち 作成日時 7月26日 10:00 Link：対象商品 ST-X-A → RP-001は提案数と理由を持ち、「承認待ち」で作成する。対象商品LinkでST-X-Aと結ぶ 提案数は在庫と需要予測から計算し、理由は店舗メモや納品条件などから残す 参考: Palantir Object types / Link types documentation 26
27. 店長が補充提案を承認する 実行する人 店長 実行条件 RP-001が承認待ち 承認前：補充提案 RP-001 結果 提案数 16ケース 理由 週末イベントで来店増（店舗メモ） 状態 承認待ち Link：対象商品 ST-X-A 同じObjectの状態を更新 承認後：補充提案 承認する Action → RP-001 提案数 16ケース 理由 週末イベントで来店増（店舗メモ） 状態 承認済み Link：対象商品 ST-X-A 承認後もObject IDはRP-001のまま。提案数と理由は残し、承認Actionが状態だけを「承認済み」へ変える 却下した場合は状態を「却下」へ変え、発注明細は作らない 参考: Palantir Action permissions / Submission criteria 27
28. 承認済みの提案から発注する 実行する人 システム / 発注担当 実行条件 RP-001が承認済み Object Type：補充提案 RP-001 結果 提案数 16ケース 理由 週末イベントで来店増（店舗メモ） 状態 承認済み Link：対象商品 ST-X-A 発注明細Objectを1件作る Object Type：発注明細 発注する Action → PO-123-01 発注数 納品予定 状態 Link：元の提案 16ケース 7月28日 発注済み RP-001 発注ActionはPO-123-01を新しく作り、「元の提案」LinkでRP-001と結ぶ 必要ならERPへ書き戻す。発注明細から、元の提案と対象商品までたどれる 参考: Palantir Object types / Link types / Action types documentation 28
29. 補充エージェントの設計
30. 補充エージェントに任せる範囲 業務の状態を読む 在庫4・需要20 店舗メモ・納品条件 補充を提案する → 提案数16と理由を作る RP-001を承認待ちで作る 店長へ渡す → Agentは承認しない 承認前には発注しない 不足16の計算はFunctionで足りる。LLMは店舗メモや納品条件から提案理由を組み立てる場合に使う Palantirでは、この処理をAIP LogicでLLM・Function・Actionとして構成できる 出典: Palantir AIP Logic overview / Getting started “Make Ontology edits using Logic functions” 30
31. 提案から結果までを一つの履歴として残す # 1 2 3 4 5 現場で起きること 在庫4、需要20を読む 16ケースを提案する 店長が承認 / 却下する 承認済みの提案から発注する 納品と在庫結果を記録する 残るデータ 店舗別商品 ST-X-A 補充提案 RP-001（提案数・理由） / Action Log RP-001の状態 / Action Log 発注明細 PO-123-01 / 元の提案Link 納品状態 / 欠品・適正在庫・過剰在庫 ObjectとLinkに現在の状態と関係を持ち、Action Logや編集履歴に誰が・いつ・何を変えたかを残す LinkとIDをたどると、判断時点の入力から提案、人の判断、発注、業務結果まで確認できる 参考: Palantir Action Log documentation 31
32. 正常系と例外を状態として管理する 補充提案 RP-001 承認待ち 発注明細 発注済み PO-123-01 納品後の業務結果 → 承認済み → 納品済み 却下 承認期限切れ 遅延 納品不可 承認済みのとき ↓ 欠品 ／ 適正在庫 ／ 過剰在庫 承認待ちで止まった提案や、納品されていない発注を現在の状態から確認できる 例外もObjectの状態として残すため、スプレッドシートへ戻って履歴が途切れない 32
33. 発注判断を学習データとして残す 判断時点の状態 在庫・需要予測・納期 発注制約 実行したAction ＋ 提案数・人の修正・承認・発注数 実際の結果 → 納品日・欠品数・期末在庫・ 廃棄 1件の判断として、Linkで結ぶ 判断時点の店舗別商品 → 補充提案 → 承認・発注 → 納品後の在庫結果 現在値で上書きせず、判断した時点の在庫・需要予測・制約をスナップショットとして残す Action Logだけでは納品後の結果まで結びつかないため、発注明細から納品・欠品・在庫結果をLinkでたどれるよう にする 参考: Palantir Action Log / Model integration 33
34. 同じ在庫条件で、発注量だけを変えて比べる × 飲料A ｜ 在庫4ケース ｜ 需要予測20ケース ｜ 納期・最小発注量 現在の状態を固定 店舗X などの制約 8ケース 16ケース 24ケース 予測：欠品・期末在庫・コスト 予測：欠品・期末在庫・コスト 予測：欠品・期末在庫・コスト 候補として入力 現在の提案 候補として入力 過去の「状態＋実行した発注量＋結果」でモデルを学習し、現在は発注量だけを変えて各候補の結果を予測する 欠品、過剰在庫、発注コスト、業務上の制約を並べ、Agentまたは担当者が発注量を選ぶ 実行しなかった発注量は観測できない。履歴の偏りは、因果推論や段階的な実験で補う 34
35. 補充判断の履歴を、次の業務に使い直す 次回の補充提案 提案数、人の修正、発注後の欠品・過剰在庫を並べ、候補を比べます。 店長の確認 在庫、需要、承認理由が一続きに残り、確認と転記の手間が減ります。 発注条件の見直し 欠品・過剰在庫が続く条件を拾い、提案数や承認条件を見直します。 35
36. データエンジニアが、 オントロジーに向き合う理由
37. 判断と結果の履歴が、企業固有のMoatになる 業務の状態 在庫・需要 取引条件 Agentの提案 → 根拠・モデル 提案数 人の判断とAction → 修正・承認・発注 業務結果 → 納品・欠品 過剰在庫 同じ履歴として残す 提案の根拠 ／ 人の修正・承認 ／ 実行したAction ／ 業務結果 業務モデルと履歴がそろうほど、企業固有の判断基準が複利で効いてくる 37
38. データアーキテクチャをつなぎ、業務を動かす セマンティック レイヤー 指標・切り口・意味・品質 人とAIが同じ数字を読む → 業務をデータにする Object・Link・Action 状態・権限 業務のデジタルツインをつくる BAを組み替える 役割・プロセス・Agent・統制 → 人とAIが動く業務を設計する セマンティックレイヤーを土台に、業務対象、関係、Action、結果を一つのデータアーキテクチャとしてつなぐ AIが安全に動ける境界とBAを設計し、業務の変化に合わせて育て続ける 38
39. Kurashiru AI OSで仲間を募集しています メーカー・卸・小売をつなぐAI基盤とプロダクトを、事業と一緒につくります。 01 AIフルスタックエンジニア 02 AI Platform Engineer / SRE https://herp.careers/v1/kurashiru/pzTZk3tSh7bs https://herp.careers/v1/kurashiru/3sRVGl8z1LTf 興味がある方は、上記の応募ページか、X（@gappy50）からでも問題ありません。 ご清聴ありがとうございました。