オントロジーって 結局なにもの？ AI エージェントに「意味」を渡す知識設計の話

生成AIやRAGの文脈で「オントロジー」という言葉を耳にする機会が増えてきました。一方で、「タクソノミーと何が違うのか」「DBのスキーマやナレッジグラフとは別物なのか」と聞かれると、説明に詰まる方も多いのではないでしょうか。本セッションでは、オントロジーを「モノ・関係・ルールを機械が扱える形で記述した、業務の地図」と捉え直し、よくある誤解を整理しながら基礎から解説します。そのうえで、LLMがどれだけ賢くなっても現場で答えられない質問が残る理由、そしてRAGが「文書を探す」のに対してオントロジーが「意味を辿る」ことで何が可能になるのかを、AIエージェント設計の観点からお話しします。後半では、オントロジーを組み込んだエージェントで実際に直面する課題と、それに対して私たちが現在取り組んでいる多層構造のオントロジー設計の構想をご紹介します。

Transcript

1. DevFest 2026 in Kansai オントロジーって 結局なにもの？ AI エージェントに「意味」を渡す知識設計の話 村上 智之 株式会社データラーニング 代表 ／ SOBO プロジェクト
2. 自己紹介 REPRESENTATIVE PROFILE 代表取締役 村上 智之 データサイエンス領域に 12 年以上。大企業からスタートアップまで、データ分析チームの立ち上げを支援。 CEO / FOUNDER 村上 智之 Tomoyuki Murakami ROLES ・データラーニング 代表取締役 ・データラーニングギルド 代表 ・SOBO CDO （Chief Data Officer） CAREER HISTORY 株式会社 ALBERT データサイエンティストとして、AI 活用の基礎を習得 2014–2015 株式会社 イノーバ Web エンジニア。マーケティング自動化ツールの開発・サービス企画 2016–2017 澪標アナリティクス 株式会社 トヨタコネクティッドの分析チーム立ち上げ 株式会社 データラーニング 設立 2018.05 AI エージェント実装支援、研修事業を提供中 〜2013 AUTHORED BOOKS EXPERTISE データサイエンス歴 12 年以上 働き方のデジタルシフト データ × AI 人材キャリア大全 500 名以上のデータ × AI 人材を育成 技術評論社 ／ 2021 翔泳社 ／ 2022 AI エージェント実装・データ基盤・研修 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 2
3. 自己紹介 COMMUNITY データラーニングギルド — データ × AI 人材のコミュニティ 1,200名 データ × AI の実務者・学習者が参加 200名以上 経産省認定の育成プログラムの修了生 現場の知識を、現場の人同士で共有する場 今日の話のような「作ってみて困ったこと」を、会社をまたいで持ち寄る 学ぶ人と、育てる側が同じ場所にいる 育成プログラムの修了生も参加し、学んだ先の現場とつながる オンライン・オフラインのハイブリッド 関東・関西・東海・オンラインを中心に活動中 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 3
4. 今日の流れ AGENDA 潮流から中身へ、中身から現場へ 01 02 03 いま起きていること なぜ今、オントロジーか オントロジーとは何か Palantir、データ基盤各社、 オントロジーが必要とされる、時代の背景 「オントロジー」や「グラフ」と 大手コンサルが、こぞって 呼ばれるものは具体的にどんなものか？ 「オントロジー」「FDE」と言い始めた 04 05 06 これから起こる変化 導入の課題と解決策 SOBO が目指すサービス 意味の定義が各社の基盤に付き、 企業に導入するときの 6 つの課題と、 ここまでの話を 1 つの基盤に 作る人（FDE）が不足する 一般的な解決策 組み込むと、どんな形になるか オントロジーって結局なにもの？ — DevFest 2026 in Kansai 4
5. 01 いま起きていること Palantir、データ基盤各社、大手コンサルが、 こぞって「オントロジー」「FDE」と言い始めた
6. いま起きていること 01 THE WAVE この 1 年半、みんなが「オントロジー」と言い始めた Palantir データ基盤各社 大手コンサル・調査会社 2026.08 2025.09 2026.03 Q2 売上 +93%、米国商用 +149%。 CTO「FDE がいるのは Palantir だけ」 Snowflake・Salesforce・dbt らが Open Semantic Interchange を提唱 （意味モデルの共通仕様） Gartner「文脈は新しい重要インフラ」。 90 日計画として、1 つの業務領域で セマンティックレイヤー・オントロジー・ ナレッジグラフを作るよう推奨 2026.05 決算説明で Ontology を 「AI という頭脳の身体」と説明 2025.03 / 2026.09 Databricks と製品提携。 富士通と FDE 分野で提携を強化 2025.11 Microsoft が、AI に業務データを渡す 仕組みとして Fabric IQ を発表 2026.04 / 05 Google は Looker＋ Knowledge Catalog、 SAP は Knowledge Graph を提供 2026.08 デロイト トーマツが、 社内の集合知をオントロジーとして 整備・実装するサービスを提供開始 Palantir、データ基盤各社、大手コンサル・調査会社が、「AI に文脈を与える仕組み」を重視している。 ※ FDE（Forward Deployed Engineer）＝ 顧客企業に入り、AI を業務に導入するエンジニア オントロジーって結局なにもの？ — DevFest 2026 in Kansai 6
7. いま起きていること 01 THE WAVE 「FDE」領域は、1 年で数十億ドル規模に Accenture×Microsoft が FDE プラクティスを設立し、 数千人の AI 人材を顧客側に AWS は FDE 組織に 10 億ドルを投資。 数千人の専門家を顧客側に配置 2026.03 2025.01 – 09 FDE 系の求人が +800%（Indeed）。 OpenAI・Anthropic も FDE チームを拡大 富士通が Palantir の Global FDE Partner に。 国内でも FDE 求人が増加中 2026.06 2026.05 OpenAI Deployment Company （40 億ドル超、Tomoro 買収へ）。 Anthropic も投資会社と AI サービス会社を設立 2026.09 2026.08 Palantir Q2 売上 +93%、米国商用 +149% 強みは AIP（AI 基盤）と FDE FDE の需要が、AI の普及とともに急速に拡大している。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 7
8. 02 なぜ今、オントロジーか オントロジーが必要とされる、時代の背景
9. なぜ今、オントロジーか 02 WHY NOW なぜ今か — LLM の次の段階は「業務を任せる」こと 1 2 3 「動く」から「任せる」へ つなぐだけでは、失敗する LLM（大規模言語モデル）を使い、 データはあるが、 AI が使える形になっていない 自律的に動くエージェントは既にある。 基幹システムのデータを見ても、 接続しても、データの意味が 業務を任せるには、エージェントが AI にはデータの意味が分からない。 分からなければ、分析は誤る。 売上の定義・承認者・業務手順を AI は名前から意味を推測するため、 Gartner の予測：接続だけで意味を 知っている必要がある。 推測を外すと、もっともらしい 定義しない AI 分析プロジェクトの 間違った結果を返す。 60% が、2028 年までに失敗する。 MCP（AI とツールをつなぐ方式）で AI が推測せずに済むよう、業務の意味とルールを書き出したもの。それがオントロジー。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 9
10. なぜ今、オントロジーか 02 WHY NOW LLM が賢くなっても、現場で答えられない質問が残る 当社の「売上」は返品控除後？ 案件 AN-001 の承認者は誰？ 先月の計算を、もう一度お願い 「売上」の意味は会社や部門、集計の 文脈によって変わる 組織・権限・条件は刻々と変わる。 人の頭と人事システムの中にある データの鮮度と再現性を、確率的な 生成では保証できない 足りないのは知能ではなく、「この会社の意味」をAIが確実に扱える形。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 10
11. なぜ今、オントロジーか 02 WHY NOW 「佐藤さんに確認して」が、AI には分からない 人間 AI いま話しているのは AN-001。その担当は佐藤さん。 従業員一覧に「佐藤」が 2 人。 昨日の会議にいたのも佐藤さん。だから迷わない。 文字列「佐藤」だけでは決まらない。文脈を知らない。 AN-001 担当 佐藤 所属 営業部 昨日の会議 参加 佐藤 人間が使っている「文脈」＝ 人・案件・部門・会議・文書のつながり このつながりを AI に渡すのが、実体（＝個々の人・案件・会議）のグラフ。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 11
12. なぜ今、オントロジーか 02 WHY NOW RAG は「文書を探す」。オントロジーは「意味をたどる」 質問：「営業部の案件で、遅れているものは？」 RAG（＝検索した文書を LLM に渡す方式） オントロジー 「営業部」「案件」「遅れ」に似た文章を返す。 営業部→案件とたどり、「遅れの基準」で判定する。 最新か、網羅しているか、遅れの基準は考慮しない。 根拠（どの行・どの版・どの時点）も返す。 関連する文書を探すのは、RAG で足りる。条件で判定し、関係をたどるには、オントロジーが要る。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 12
13. なぜ今、オントロジーか 02 WHY NOW オントロジーがあると、何が変わるか 用語の意味が 1 つに決まる AI が人や案件のつながりを把握できる 「顧客」「売上」が何を指すかを 1 つに定義し、人も AI も 「佐藤さん」がどの佐藤さんかを、担当案件や参加した 同じ定義を使う。部門ごとの定義の違いも可視化される。 会議から特定できる。人が頭の中でしている判断に近づく。 AI の判断理由と権限を確認できる 定義を、どの仕組みでも使える AI がどのデータとどのルールで判断したかを、後から チャット、ダッシュボード、AI エージェントのどれも、 説明できる。そのデータを見てよいか、変更してよいかも、 同じ定義を参照する。定義を変えるときも、直す場所は AI が実行する前に確認できる。 1 か所で済む。 オントロジーがないと起きること：部門ごとに数字が違う「売上」、別の人に届く承認依頼、理由を説明できない AI の判断 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 13
14. 03 オントロジーとは何か 定義と来歴、似た言葉、型と実体、グラフ DB、全体の構成
15. オントロジーとは何か — この章の構成 03 WHAT IT IS この章の構成 小見出し 扱う内容 03-1 オントロジーの定義と来歴 4 回の登場、4 つの部品、社内オントロジーの例、制約でできること 03-2 似た言葉との違い タクソノミー、スキーマ、ナレッジグラフ、 GraphRAG、セマンティックレイヤー 03-3 型のグラフと実体のグラフ 2 つのグラフの違い、両方が必要な理由、作り方 03-4 グラフ DB とたどり方 保存先の選択肢、型を書く形式、グラフ DB とは、 グラフ DB が選ばれる 3 つの理由 03-5 全体の構成と実装の選び方 全体の構成、作るときと使うときの流れ、 部品と技術、実装の選び方 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 15
16. 03-1 オントロジーの定義と来歴 4 回の登場、4 つの部品、社内オントロジーの例、制約でできること
17. オントロジーとは何か — 定義と来歴 03 WHAT IT IS 「オントロジー」は、目的を変えながら 4 回登場した 1990 年代 2000 年代 2010 年代 2024 〜 AI・知識表現 Semantic Web ナレッジグラフ LLM 時代 知識ベースを共有するための 「概念化の明示的な仕様」 （Gruber, 1993） Web 上で機械が意味を 共有する。RDF・OWL・ SPARQL が標準になる 検索や企業データで、 単語ではなく「モノ」と その関係を扱う仕組みが 広がった データ基盤各社の オントロジー機能として、 エージェントに 「業務の意味」を渡す 仕組みが再登場 どの時代にも共通すること：概念と関係を、人と機械が共有できる形で書き出す RDF ＝ データを「主語・関係・相手」の三つ組で書く形式。OWL ＝ クラス・プロパティ・制約を書く言語。 SPARQL ＝ RDF で書いたデータへの問い合わせ言語。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 17
18. オントロジーとは何か — 定義と来歴 03 WHAT IT IS オントロジーを作る 4 つの部品 クラス プロパティ 制約 インスタンス Class — 種類 Property — 関係と属性 Axiom — 決まり Individual — 実際のモノ 従業員・部門・案件 所属する・担当する・ 上長は 「部長は従業員の一種」 「上長は 1 人まで」 佐藤・営業部・ 案件 AN-001 定義：オントロジーは「共有された概念化の、形式的で明示的な仕様」。 Gruber（1993）の定義に、Borst（1997）が「形式的」「共有された」を加え、Studer ら（1998）がまとめた。 記述には RDF と OWL、問い合わせには SPARQL を使う。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 18
19. オントロジーとは何か — 定義と来歴 03 WHAT IT IS 小さな社内オントロジーの例 従業員 所属する （佐藤） 定義（型） 部門 主語 関係 相手 （営業部） 従業員 所属する 部門 従業員 担当する 案件 案件 属する 部門 従業員 上長は 従業員 上長は： 従業員 → 従業員 担当する 属する インスタンス（実際のモノ＝実体） 案件 （AN-001） 色付きの行（種類は）が、インスタンスと定義（型）をつなぐ オントロジーって結局なにもの？ — DevFest 2026 in Kansai 主語 関係 相手 佐藤 種類は 従業員 営業部 種類は 部門 AN-001 種類は 案件 佐藤 所属する 営業部 佐藤 担当する AN-001 AN-001 属する 営業部 19
20. オントロジーとは何か — 定義と来歴 03 WHAT IT IS オントロジーの有無で変わる LLM の判断 依頼 「案件 AN-001 の見積を承認に回して」 1 書いていないことを導く 2 データの誤りを見つける 3 未記入を「無い」としない データ データ データ AN-001 の担当は佐藤。 佐藤の上長は田中 佐藤の上長が、田中と山本の 2 人登録されている AN-001 の金額が どこにも書かれていない オントロジーがない場合 オントロジーがない場合 オントロジーがない場合 承認者がどこにも書かれていないので、 送り先が分からない 先に見つかった田中にだけ送る 金額なしとみなし、 上長の承認だけで進める オントロジーがある場合 オントロジーがある場合 オントロジーがある場合 「見積の承認者は担当者の上長」 というルールから、田中に送る 「上長は 1 人まで」に反するので、 送る前に正しい上長を確認する 「500 万円超は部長も承認」を 判断できないので、金額を確認する 企業向けツールの多くは OWL の推論を使わず、ルールを製品独自の形式で書く。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 20
21. 03-2 似た言葉との違い 5 つの似た言葉と、オントロジーの関係
22. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS オントロジーと似た言葉 — よく受ける 5 つの質問 Q1 Q2 Q3 Q4 Q5 タクソノミー DB スキーマ ナレッジグラフと GraphRAG で セマンティック （分類）と （表の設計）と 何が違うのか？ 作るグラフと レイヤーと 何が違うのか？ 何が違うのか？ 何が違うのか？ 何が違うのか？ 分かりにくいのは、話す人や製品によって「オントロジー」が指すものが違うため。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 22
23. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS タクソノミーは、上下関係だけのオントロジー タクソノミー：上下関係だけ 家電 オントロジー：種類の違う関係と、ルール 電子レンジ 部品 マグネトロン 仕入先 C社 ルール：リコール対象の部品を含む商品は、出荷を止める キッチン家電 「電子レンジは家電の一種」という is-a も、関係の 1 つとして書ける。 電子レンジ 分類・タグ付け・ナビゲーションに使う 分類だけでは、「リコール対象の部品を含む商品」のように、種類の違う関係をまたぐ質問に答えられない。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 23
24. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS スキーマはシステムごと、オントロジーは会社共通 スキーマ：同じ A社が、 システムごとに別の形で保存されている CRM（顧客管理）の顧客表 customer_id name C-0192 (株)A社 会計システムの取引先表 vendor_cd 名称 V-77 A社 機械には、この 2 行が 同じ会社かどうか判断できない オントロジーって結局なにもの？ — DevFest 2026 in Kansai オントロジー：2 つの表を「取引先」という 1 つの概念に対応づける CRM の顧客表 取引先 会計の取引先表 ・customer_id と vendor_cd は、どちらも取引先の番号 ・「(株)A社」と「A社」は、同じ取引先の別名 「A社との取引額は？」と聞かれたとき、 AI は 2 つのシステムのデータを合わせて答えられる 24
25. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS ナレッジグラフとオントロジーの呼び方は、各社で違う 提供元・文脈 全体を指す言葉 もう一方の位置づけ 研究（Hogan ら, 2021） ナレッジグラフ オントロジーは、データに加える型やルールの 1 つ Neo4j（グラフ DB） ナレッジグラフ データ ＋ 整理の原則（オントロジー）＝ ナレッジグラフ Palantir Foundry オントロジー 型・実際のデータ・操作をまとめてオントロジーと呼ぶ Microsoft Fabric IQ オントロジー 型・関係・ルールを実データに結びつける。グラフはその一部 GraphRAG ナレッジグラフ 文書から実体と関係の説明文を抜き出す。関係に型はない 中身はほぼ同じで、提供元によって呼び方と包含関係が変わる。 傾向として、オントロジーは型・構造寄り、ナレッジグラフは実際のデータ寄りの言葉。 ただし、関係の型を決めずに文書から作るグラフ（GraphRAG など）は、オントロジーとは別と考える。 出典：Hogan et al. (2021) ／ Neo4j Blog ／ Palantir Foundry Docs ／ Microsoft Learn（Fabric IQ）／ Microsoft GraphRAG オントロジーって結局なにもの？ — DevFest 2026 in Kansai 25
26. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS GraphRAG：文書から作ったグラフで答える仕組み 作るとき 1 文書を分ける 文書を、チャンク （短い断片）に分ける 2 実体と関係を抜き出す → 実体（名前・種類）と、 関係の説明文を LLM が書き出す 4 塊ごとに要約する 3 同じ実体をまとめる → 同じ名前・種類の実体を 1 つにし、説明を要約する → よくつながった塊を見つけ、 塊ごとに要約を作る 使うとき ローカル検索 グローバル検索 質問に出た実体の周りのつながりと、元の文を集めて答える 例：「佐藤さんと AN-001 の関係は？」 塊ごとの要約を集めて答える 例：「今期の案件全体で、何が問題だったか？」 オントロジーとの違い：関係の種類を決めず、説明文で書く。「担当する」のように種類を指定してはたどれない。 軽量版（FastGraphRAG）は LLM を使わず、名詞を抜き出して、同じチャンクに出た語どうしをつなぐ。 出典：Edge et al., From Local to Global (Microsoft Research, 2024) ／ Microsoft GraphRAG Docs オントロジーって結局なにもの？ — DevFest 2026 in Kansai 26
27. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS セマンティックレイヤーとオントロジーの重なり セマンティックレイヤーで書くもの 両方にある部分 業務の概念（案件、部門）と、概念どうしのつながり 指標：売上 = SUM(受注金額) WHERE 状態 = '受注' 次元：部門、月 結合：案件 → 部門（部門コードで結合） 製品例：dbt Semantic Layer、 Snowflake Semantic Views、 Databricks Metric Views、LookML セマンティックレイヤーにだけある部分 指標の計算式。同じ問いに、毎回同じ数字を返すための定義 （例：売上＝「受注」状態の受注金額の合計） オントロジーにだけある部分 種類の階層、制約、推論 （例：部長は従業員の一種、上長は 1 人まで） 概念とつながりは共通。 数字の集計にはセマンティックレイヤー、意味の判断にはオントロジーを使い、組み合わせる。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 27
28. オントロジーとは何か — 似た言葉との違い 03 WHAT IT IS 似た言葉とオントロジーの関係 言葉 何を書くか オントロジーとの関係 オントロジー 業務の概念、つながり、制約 複数のシステムをまたいで、 業務の意味を定義する タクソノミー 種類の上下関係（分類の木） オントロジーの一部。 上下関係だけを書く DB スキーマ／ER 図 1 つのシステムの表と列 （図にしたものが ER 図） スキーマはシステムごとの定義。 オントロジーは、それらを共通の意味で対応づける ナレッジグラフ 実際のデータどうしのつながり ほぼ同じもの。オントロジーは型寄り、 ナレッジグラフはデータ寄りの呼び方 GraphRAG 文書から抜き出した実体と、 関係の説明文 実体のグラフに見えるが、関係に型がない。 型に対応づけてから使う セマンティックレイヤー 指標の計算式、次元、結合 概念とつながりは共通。 集計の数字を揃えるための定義を書く RAG 検索した文書を AI に渡す仕組み RAG が渡すのは文書。 文書に書かれていない業務の意味は渡せない オントロジーって結局なにもの？ — DevFest 2026 in Kansai 28
29. 03-3 型のグラフと実体のグラフ 2 つのグラフの違い、両方が必要な理由、作り方
30. オントロジーとは何か — 型のグラフと実体のグラフ 03 WHAT IT IS 型のグラフと実体のグラフ 型のグラフ ER 図に近い 部門 所属する 従業員 担当する 案件 どんな種類があり、 どうつながってよいか 点線＝下の実体は、 上の型の実例 実体のグラフ 表の行に近い 型のグラフ 実体のグラフ 営業部 所属する 佐藤 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 担当する AN-001 いま、誰が何と つながっているか 30
31. オントロジーとは何か — 型のグラフと実体のグラフ 03 WHAT IT IS 型と実体の両方が必要な理由 依頼 「佐藤さんが担当している案件の取引先は？」 1 型だけ 2 実体だけ 3 型と実体の両方 ER 図に近い GraphRAG に近い 型に沿ってデータを登録 AI が持っている情報 AI が持っている情報 AI が持っている情報 従業員が案件を担当し、 案件に取引先がつく、 という型だけ 議事録から抜き出した、 佐藤と AN-001、AN-002 の つながり（関係の種類は不明） 「担当する」という関係の型と、 その型に沿ったデータ （佐藤 担当する AN-001） AI の答え AI の答え AI の答え たどり方は分かるが、 実際のデータがないので、 取引先を答えられない 担当と、会議で話題に 出ただけの案件を区別できず、 「A社と B社」と答える 担当は AN-001 だけと分かり、 「A社」と答える オントロジーって結局なにもの？ — DevFest 2026 in Kansai 31
32. オントロジーとは何か — 型のグラフと実体のグラフ 03 WHAT IT IS 型と実体の作り方 型を作る 実体を作る 入力 入力 入力 業務の聞き取り、 既存の ER 図、帳票や規程 案件表の 1 行（AN-001） 担当者 ID：E-01 取引先 ID：C-0192 議事録「佐藤さんから、AN-001 の 件は A社の窓口に確認すると 報告があった」 変換 変換 変換 人が、種類・関係・制約を決める。 LLM に下書きさせることもある 型に沿って、列を関係に対応づける （担当者 ID の列 →「担当する」） LLM が実体を抜き出し、関係を 説明文で書く（種類は決めない） できるもの できるもの できるもの 従業員 ─担当する→ 案件 案件 ─取引先は→ 取引先 佐藤 ─担当する→ AN-001 AN-001 ─取引先は→ A社 佐藤 ─ AN-001 関係：「A社の窓口に確認」 業務システムから 実体を作る 文書から 型は、人が業務の聞き取りや既存の資料から決める。業務システムからは、型どおりのつながりができる。 文書からは、関係を説明文で書いたつながり（型との紐づけなし）ができる。GraphRAG もこの方法を使う。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 32
33. オントロジーとは何か — 型のグラフと実体のグラフ 03 WHAT IT IS 業務データ由来と文書由来のつながりの違い 業務データから作ったつながり 担当する 佐藤 文書から作ったつながり 窓口に確認 取引先は AN-001 A社に確認 佐藤 AN-001 A社 佐藤（営業） A社 会議で発言 つながり＝各システムの ID で確定した事実 つながり＝LLM が文書から読み取った関係（説明文） ・関係の種類は型で決まり、表記が揺れない ・関係の種類が決まっておらず、説明文で書く ・同じ人は 1 つの実体にまとまる ・型と結びつかないので、決まりで正しさを確かめられない ・値は元のシステムにあり、更新も反映される ・つながりの多さや近さは分かるが、組織の構造は捉えにくい ・判断の根拠や、権限の確認に使える ・文脈の材料や、仮説出しには向く 文書由来のつながりは、型と結びついていない。そのままでは、組織の構造や決まりを使って判断できない。 今後は、抜き出すときに型と実体へ結びつける技術（型に沿った抽出、既存の実体への紐づけ）が重要になる。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 33
34. 03-4 グラフ DB とたどり方 オントロジーとナレッジグラフを、どこに、どんな形で保存するか
35. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS どこに、どんな形で保存するか — 3 つの選択肢 ファイル RDB グラフ DB • OWL・RDF・YAML などの 形式で、型を書く • 表と列で保存し、つながりは 外部キー（ID の列）で表す • ノードとエッジで、 つながりをそのまま保存する • 型の受け渡しや、版の管理に向く • 確定値の読み書きと、集計が得意 • • 実体が増えると、つながりを たどる問い合わせには向かない • 何段もたどるには、JOIN を重ねる Neo4j（プロパティグラフ）、 トリプルストア（RDF）など • つながりを何段もたどる 問い合わせが得意 保存先には、多ホップ（つながりを何段もたどる）の問い合わせに強いグラフ DB が選ばれることが多い。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 35
36. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS 型を書く形式 — RDF・OWL・YAML RDF OWL YAML 主語・関係・相手の三つ組で書く。 RDF の上で、型と制約を書く言語。 人が読み書きしやすい汎用の形式。 型も実際のデータも、同じ形で書ける 決まりから、推論と検査ができる 書き方と検査は、自分たちで決める 佐藤 種類は 従業員 営業部 種類は 部門 佐藤 所属する 営業部 部長：従業員の一種 所属する：従業員 → 部門 上長は：1 人まで # 1 行が「主語・関係・相手」の 1 組 # RDF の三つ組に、決まりを足す 従業員: 所属する: 部門 上長は: 相手: 従業員 最大: 1 書く内容は同じ。RDF と OWL は標準の形式で、推論や検査の道具がそろっている。 YAML は読み書きしやすいが、意味の決まりと検査は自分で用意する。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 36
37. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS グラフ DB：つながりをそのまま保存するデータベース RDB（リレーショナル DB）：表で保存する 従業員 ID E-01 名前 佐藤 部門 ID D-10 部門 ID D-10 グラフ DB：つながりで保存する 部門名 営業部 佐藤 所属する 営業部 つながりは、外部キー（部門 ID）の値として保存する。 問い合わせのたびに、ID の一致で表を結合する（JOIN） つながり（エッジ）そのものを保存する。 問い合わせでは、つながりをたどって取り出す プロパティグラフ型 ノードとエッジに属性を持たせる。Neo4j など。 問い合わせ言語は Cypher RDF 型（トリプルストア） 「主語・関係・相手」の三つ組で保存する。 問い合わせ言語は SPARQL オントロジーは RDB の上にも作れる。つながりを何段もたどる問い合わせには、グラフ DB が向いている。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 37
38. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS 理由 1：多ホップの問い合わせが多い オントロジーを使う問い合わせには、つながりを何段もたどる（多ホップの）処理が多い。 承認ルートを組み立てる 3〜5 ホップ。人によって段数が違う 定義の変更の影響を調べる 5 ホップ。逆向きに、種類をまたぐ リコール部品の影響を追う 6 ホップ。上流から下流へ 「佐藤さん」が誰かを決める 3〜4 ホップ。複数の経路を合わせる 申請者 → 上長 → 上長の上長 → 500 万円超なら部長 → 不在なら代理人 売上の定義 → 派生指標 → ダッシュボード → 会議資料 → KPI目標 → 持ち主に通知 仕入先C社 → ロット → 部品 → 製品 → 出荷先 → 案件 → 担当営業 今のチャット → AN-001 → 担当者 → 佐藤A ＋ 昨日の会議 → 参加者 → 佐藤A 共通点：種類をまたぐ、長さが事前に決まらない、逆向きにもたどる。 RDB では JOIN の段数を事前に決められず、書きにくい。データが大きく段数が深いと、速さにも差が出る。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 38
39. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS 理由 2：再帰的な関係に強い 佐藤さんが、蓄電池の安全規格に詳しい人に相談したい。社内で一緒に案件をした人のつながりをたどり、 いちばん近い詳しい人と、誰に紹介を頼めばよいかを求める。 1 出発点を決める 佐藤（営業 1 課） 2 1 段目：一緒に案件をした人 田中・伊藤・山本の 3 人。詳しい人はいない 3 2 段目：その人たちが一緒に案件をした人 12 人。佐藤や、すでに見た人に戻るつながりは除く 4 「詳しい人」の条件で止める 高橋（蓄電池の安全規格の案件で 3 件の実績） 5 経路を根拠に、紹介ルートを返す 佐藤 → 田中（AN-014 で一緒）→ 高橋 RDB で書く場合 ・何段で見つかるか決まらないので、再帰 CTE （結合を繰り返す SQL）で書く。長く複雑になる ・つながりはネットワークで、同じ人に何度も戻る。 一度たどった人を除く処理が必要 ・段が増えるごとに候補が何倍にも増え、 結合が積み重なって遅くなりやすい グラフ DB で書く場合 ・条件に合う人までたどる 1 文で書け、 最短の経路がそのまま返る 人のつながりは、木ではなくネットワーク。何段目で見つかるか、どこで同じ人に戻るかは、データを見るまで分からない。 そのため、つながりを 1 か所にまとめ、最短の経路を返せる形で保存する。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 39
40. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS 理由 3：経路が、そのまま根拠になる 1 質問 2 LLM：型を参照する 3 グラフ DB：たどる 4 プログラム：判定する C社の部品が納期遅れ。 影響を受ける案件と 担当者は？ 仕入先 → 部品 → 製品 → 案件 のつながりを選び、 問い合わせを組み立てる C社から 4 段たどり、 結果を経路のまま返す 納期と案件の期限を比べ、 経路を根拠に付けて返す グラフ DB が返す結果：経路 仕入先 AI の答え（根拠つき） 部品 製品 案件 担当者 影響を受ける案件は 2 件。 C社 → P-12 → X-3 → AN-001 → 佐藤 ・AN-001（担当：佐藤） 根拠：C社 → P-12 → X-3 → AN-001 C社 → P-12 → X-5 → AN-007 → 鈴木 ・AN-007（担当：鈴木） 根拠：C社 → P-12 → X-5 → AN-007 結果は表の行ではなく、たどったノードとつながりの並び（経路）で返る オントロジーって結局なにもの？ — DevFest 2026 in Kansai 40
41. オントロジーとは何か — グラフ DB とたどり方 03 WHAT IT IS グラフ DB が選ばれる 3 つの理由 1 2 3 多ホップの問い合わせが多い 再帰的な関係に強い 経路が、そのまま根拠になる 承認ルート・影響分析・リコールの 人のつながりのようなネットワークを、 たどった経路を返せるので、 追跡は、種類をまたいで何段もたどる。 何段で終わるか決めずにたどれる。 AI の答えに「どのつながりから 同じ人に戻る経路も扱える。 判断したか」を添えられる。 必要なのは、つながりを 1 か所にまとめて保存すること。グラフ DB は、それをたどりやすくする。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 41
42. 03-5 全体の構成と実装の選び方 型・業務データ・文書を 1 つのグラフにつなぐ構成と、保存先の選び方
43. オントロジーとは何か — 全体の構成と実装の選び方 03 WHAT IT IS 全体の構成 — 型・業務データ・文書を 1 つのグラフに オントロジーで社内の知識基盤を作るときは、次のような手順で作り、使う。 グラフの保存先 作るとき 業務の聞き取り 既存の資料 人が型を決める （LLM は下書き） 業務システム （基幹・CRM） 型に従い、 ID で結ぶ（確定） 文書・議事録 LLM が実体と 関係を抜き出す 型のグラフ （クラス・関係・制約） 型に対応づけ・名寄せ 人が確認して入れる チャンクに分け、 ベクトル化 実体のグラフ （ノードとエッジ） ベクトル DB 色の意味 薄い青：グラフ 薄い緑：ベクトル検索 濃い青：LLM 灰：プログラムと人 白：元データ 業務データの値は 接続先に残し、 ID だけを結ぶ 使うとき（1 回の応答ごと） 発話 LLM が型を見て 問い合わせを組む ベクトル検索で 出発点を選ぶ グラフで つながりをたどる プログラムが 定義どおり判定 経路を根拠に 答えを書く 答え 型が、業務データと文書を 1 つのグラフにつなぐ。文書由来のつながりは、型に結びつけ、確認してから入れる。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 43
44. オントロジーとは何か — 全体の構成と実装の選び方 03 WHAT IT IS 作るとき — 文書を、型と実体に結びつける 業務データは型どおりに ID で結べる。文書から作るつながりは、次の 4 段を経てから実体のグラフに入れる。 1 抜き出す 2 型に対応づける 3 既存の実体に結ぶ 4 確認して入れる 担当：LLM 担当：LLM ＋ プログラム 担当：プログラム 担当：人 議事録の一文から、 「佐藤」「AN-001」と、 関係「窓口に確認」を 抜き出す 説明文「窓口に確認」を、 型の関係に当てはめる。 「担当する」か 「言及した」か。 型にない関係は保留する 「佐藤」を、業務データの 従業員 E-01（営業 1 課）に 対応づける。 候補が 2 人いれば、人が選ぶ 確定したものだけを、 出典（文書 ID・位置）を 付けて実体のグラフに入れる 使える技術 結びつかなかったもの • 型に沿った抽出：抜き出す実体と関係の種類を先に指定する • 型に当てはまらない関係は、実体のグラフに入れない • エンティティリンキング：名前を、既存の実体の ID に結ぶ • 文書のまま、ベクトル検索で文脈の材料に使う 業務データは ID で確定する。文書は、型と既存の実体に結びつけ、人が確認したものだけを入れる。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 44
45. オントロジーとは何か — 全体の構成と実装の選び方 03 WHAT IT IS 使うとき — 1 回の応答の中の分担 質問「佐藤さんが担当する案件で、遅れているものは？」に答えるまでの流れ。段ごとに、担当と保存先が変わる。 段 担当 使う保存先 返すもの（例） 1 発話から実体を取り出す LLM ― 「佐藤さん」「遅れ」 2 出発点を決める ベクトル検索・名寄せ ベクトル DB、実体のグラフ 佐藤 ＝ 従業員 E-01 3 問い合わせを組む LLM 型のグラフ 「担当する」→ 案件 をたどる問い合わせ 4 つながりをたどる グラフ DB 実体のグラフ E-01 → AN-001、AN-005（経路） 5 値を読む SQL・API 接続先（RDB・DWH） 期限・進捗率の現在の値 6 判定する プログラム 定義（型） AN-005 は「遅れ」に当たる 7 答える LLM ― 経路と値を根拠にした答え LLM は、読む・選ぶ・書く。たどるのはグラフ、値は接続先、判定はプログラム。 保存先は 1 つに決めず、段ごとに得意なものを使う。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 45
46. オントロジーとは何か — 全体の構成と実装の選び方 03 WHAT IT IS 部品ごとの、データ構造・処理・技術 部品 データ構造（何を持つか） 処理（何をするか） 技術（何で動くか） チャンクと エンベディング 文書を分割した断片。本文と、 出典（文書 ID・位置）、ベクトル 分割、ベクトル化、 質問に近い上位 k 件の検索 エンベディングモデル、 ベクトル DB（pgvector など）、 全文検索 ノードとエッジ ノード（ID、型、名前、説明文） エッジ（元 ID、先 ID、種類、 出典の ID） 隣を取る、経路をたどる、 n ホップ広げる、本数を数える RDB のエッジ表 ＋ 再帰 CTE、 またはグラフ DB。 小さければメモリ上（NetworkX） 型（オントロジー） クラス、プロパティ、制約。 ノードとエッジの「許される形」 問い合わせの組み立て、 入れる前の検査、ID の対応 OWL・SHACL（制約の検査言語）、 または YAML・JSON のスキーマ。 検査はプログラムで行う 業務データ 表の行（ID と列）。 データは接続先に残す ID で読む、ノードに結ぶ、 集計、確定値を書く RDB・DWH、API、コネクタ LLM 入出力はテキスト。 状態は持たない 実体と関係の抽出、 問い合わせの作成、 文脈を読んで答える LLM の API。検索・たどり・SQL を ツール（関数）として渡す オントロジーって結局なにもの？ — DevFest 2026 in Kansai 46
47. オントロジーとは何か — 全体の構成と実装の選び方 03 WHAT IT IS 実装の選び方 — 業務の表・エッジ表・グラフ DB 業務の表のままの RDB RDB のエッジ表 グラフ DB 保存の形 関係が表ごとに散らばる。 担当は案件表の列、 参加は会議参加表 全部の関係を、 1 つのエッジ表に入れる （元 ID、先 ID、種類、属性） ノードとエッジを、 そのまま保存する （Neo4j、Amazon Neptune など） 向くとき 決まった 1〜2 段の結合と、 集計が処理の中心のとき エッジが数十万、 深さ 10 段程度のとき。 既存の RDB に同居させたいとき エッジが数千万を超え、 深さが決まらず分岐が多いとき。 経路を返したいとき つらいところ 関係を足すと SQL も増える。 横断して隣をたどりにくい 深く分岐が多い探索は 遅くなりやすい。 経路の SQL が長い 運用と学習のコスト。 集計は RDB が得意。 元データとの二重管理 必要なのは、エッジを 1 か所にまとめるデータモデル。 まずエッジ表で小さく始め、規模と探索の深さに合わせてグラフ DB に移す選び方もある。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 47
48. 03 オントロジーとは何か — まとめ
49. オントロジーとは何か — まとめ 03 WHAT IT IS 03 のまとめ — オントロジーとは何か 03-1 定義と来歴 03-2 似た言葉との違い 03-3 型のグラフと実体のグラフ 03-4 グラフ DB とたどり方 03-5 全体の構成と実装の選び方 概念と関係を、人と機械が共有できる形で書き出したもの。 クラス・プロパティ・制約・インスタンスの 4 つでできている タクソノミーは上下関係だけ。スキーマはシステムごとの定義。 ナレッジグラフはほぼ同じでデータ寄り。GraphRAG は関係に型がない 型（どうつながってよいか）と実体（誰が何とつながっているか）の両方が要る。 文書由来のつながりは、型と実体に結びつけてから使う 多ホップの問い合わせ、ネットワークの再帰的な探索、経路を根拠として返すこと。 この 3 つが得意なので、保存先にグラフ DB が選ばれる 型が、業務データと文書を 1 つのグラフにつなぐ。保存先は役割で使い分ける。 必要なのはエッジを 1 か所にまとめること。エッジ表から始める選択もある オントロジーは、業務の意味を機械が扱える形で書いたもの。型を決め、データと文書をその型でつなぐと、AI が意味をたどれる。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 49
50. 04 これから起こる変化 意味の定義が各社の基盤に付き、作る人が不足する — 求められる人材、FDE
51. これから起こる変化 04 WHAT'S NEXT 意味の定義をめぐる、これからの 4 つの変化 1 3 どの基盤にも、意味の定義機能が付く 2 仕様の共通化が始まる Microsoft・Snowflake・Google・SAP が Open Semantic Interchange（2025.09）。 それぞれ提供を始めた。機能では差がつかなくなり、 意味モデルをツール間で持ち運べることが当たり前になり、 差は「自社の定義をどれだけ書けたか」に移る 1社の製品でしか使えない定義は選ばれにくくなる 「読む」から「動く」へ。 意味の定義に、権限とルールが加わる 4 作る側が、ボトルネックになる モデルも基盤も買えば手に入るが、「自社の意味を Palantir の Action、Fabric IQ の Operations Agent。 書き出す人と時間」については、簡単に調達できない。 「何があるか」に「誰が何をしてよいか」が付く 各社が FDE 組織に投資している理由はここ 差がつくのは製品ではなく、「自社の定義を、どこまで AI が扱える形で書けたか」。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 51
52. これから起こる変化 04 WHAT'S NEXT FDE — 現場に入って、意味と業務を一緒に作る人 FDE とは なぜ重要になるか Palantir が広めた職種。 顧客の現場で、要件が決まる前から関与。 課題発見から定義・実装・定着までを担う。 • • 求められる力 用語・例外・承認ルートは文書に無く、 聞き取らないと書けない • 業務を聞き取り、型にする • データにつなぐ 自社の情報をAIが扱える形にしないと、 AI を業務に導入できない • LLM に任せる範囲を決める • どの定義を正式とするか、合意を取る 聞き取りで確かめること オントロジーの材料：モノ・関係・値・条件 ワークフローの材料：手順・担当・完了 • 業務オーナーは誰か（会社が決めた値を変える部門） • 誰が・何を・どの順で • 会社が決めた値（率・基準・休日）と、その持ち主 • 承認者と、承認者が変わる条件（金額・部門） • 計算の例：入力 → 期待する結果 • 完了をどう見つけるか（報告・データの変化・文書） • 守るべき条件と、破ったら止めてよいか • LLM に下書きさせたい文書と、その項目 聞き取りは、オントロジーとワークフローに分けて行う。計算の例を答えられない決まりは、社内でまだ決まっていない。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 52
53. これから起こる変化 04 WHAT'S NEXT オントロジーを作る 6 ステップ ステップ やること 1 AI に答えさせたい質問を決める 業務の担当者に聞いて、「AI に答えさせたい質問」を 10 個ほど書き出す。 2 今ある資料から下書きを作る システムの項目名・用語集・マニュアルから、データの種類の下書きを作る。 下書きは LLM に作らせてよい 3 言葉をそろえる 「得意先」と「顧客」のように、同じものの別名を 1 つにまとめる。 言葉ごとに、定義を決める担当者を決める 4 つながりを書く 「誰が担当か」「どこに所属するか」などのつながりを書く。 数値は元のシステムに置いたまま、会社で決めた率や基準だけを登録する 5 ルールを書いて、例で確かめる ルールごとに「この入力なら、この結果になる」というテストケースを用意する。 実際に実行して、全部のケースが合うまで直す 6 実際のデータとつなぎ、承認 取引先や案件を元のシステムの ID でつなぎ、文書をどこまで取り込むかを決める。 担当者が承認してから使い始める。変更するときも同じ流れで進める データはコピーせず、元のシステムに置いたまま使う。ルールにはテストケースを付け、変更は承認してから反映する。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 53
54. 05 導入の課題と解決策 企業に導入するときの 6 つの課題と、一般的な解決策
55. 導入の課題と解決策 05 CHALLENGES & SOLUTIONS 導入の 6 つの課題と、一般的な解決策 課題 何が起きるか 一般的な解決策 キーワード 1 言葉が揃わない 「売上」「顧客」の定義が部門ごとに 違い、正式な定義が決まらない 用語を ID 付きの用語集で管理する。 定義ごとに持ち主と承認手続きを決める 用語集・持ち主 2 元データがどれか分からない 同じ事実が、基幹システム・シート・ メールに別の ID で散らばる データは元のシステムに残し、ID だけ持つ。 名寄せは手続きにして記録する 名寄せ・マスタ管理 3 作ったのに、業務が進まない 意味は書けたが、進行・集計・承認は オントロジーの外にある 意味・手順・集計を、別の仕組みに分け、 ID で参照し合う 役割の分離 4 更新が止まる 作った人が離れると定義が古くなり、 何が壊れるか分からない 定義を版で管理し、変更は 提案 → 検査 → 承認 の手続きにする 版管理・影響分析 5 LLM に任せる範囲が 決まらない どこまで自動で確定させるか、 誤ったとき誰が責任を持つか LLM は抽出・候補出し・下書きまで。 確定・計算・書き込みはプログラムと人 任せる範囲 業務・データ・LLM が分かる人が いない。外に頼むと知識が残らない FDE が聞き取りから定義までを担い、 社内に移す。定義はテキストで残す FDE・内製化 6 書ける人がいない 課題の多くは、技術ではなく「誰が決め、どう更新するか」の問題。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 55
56. 導入の課題と解決策 05 CHALLENGES & SOLUTIONS オントロジーに全部を入れない — 意味・手順・集計を分ける オントロジー ワークフロー セマンティックレイヤー 何があり、どうつながるか 誰が、何を、どの順で進めるか 数字をどう数えるか 取引先・案件・担当者と、その関係。 会社で決めたルール 作業の順番・担当・期限 売上・件数などの指標の定義。 集計の単位と、除外する条件 更新：業務オーナーが承認して変える 更新：現場で頻繁に変わる 更新：分析チームが変える オントロジーだけでは足りないことと、補う仕組み 業務の進み具合 → ワークフロー 誰が数えても同じ集計 → セマンティックレイヤー 毎回同じ計算結果 → LLM を使わない計算プログラム 承認と変更の記録 → 提案 → 検査 → 承認 → 新しい版 最新のデータ → 元のシステムに接続して読む 同じ相手の名寄せ → 候補 → 人が選ぶ → 記録 3 つは、更新する人も頻度も違う。そのため保存先を分け、それぞれ別に更新する。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 56
57. 導入の課題と解決策 05 CHALLENGES & SOLUTIONS 困りごとと技術の対応 色の付いた 3 行が、オントロジー（型のグラフと実体のグラフ）を使って解く困りごと。 困りごと 使う技術 例 モノと関係の意味を、システム間で揃える オントロジー（型のグラフ） CRM と会計の「A社」を 1 つの取引先に 文脈で「どれのことか」を決める 実体のグラフ（業務データ由来） 担当案件・会議・部門から「佐藤さん」を特定する 変える前に、影響と承認者を知る 実体のグラフをさかのぼる 定義 → 利用先 → 進行中のもの → 持ち主 集計の定義が、人によってぶれる セマンティックレイヤー 「売上」＝ 返品控除後、部門別・月別 文書にしかない根拠を探す RAG（ベクトル ＋ 全文検索） 議事録の「値引きの経緯」 業務を順番どおりに進める ワークフロー 案件ごとに、手順・担当・期限・状態を記録する 計算と判定を、毎回同じ結果にする ルールと計算ロジック （LLM を使わない）＋ 版・承認 粗利率 19% 以上、資本コストの式 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 57
58. 06 SOBO が目指すサービス
59. SOBO が目指すサービス 06 SOBO SOBO が解決したいこと AI エージェントを、部署をまたぐ業務で使えるようにするために、次の 3 つの困りごとを解決したい。 現場の困りごと AI だけでは解けない理由 SOBO の解き方 部署をまたぐ業務が、人の確認待ちで止まる 例：仕様変更のたびに、設計・購買・製造・ 営業が個別に確認する AI が見られるのは、 各部署のシステムの中だけ L1 の型で部署をまたいでデータをつなぎ、 エージェントが影響範囲をまとめて出す 顧客別・案件別の個別ルールや例外が、 ベテランの頭の中にしかない どの文書にもデータにもない。 LLM は知りようがない FDE が聞き取り、L3の決まりとしてデータ化し、 AIが判断するデータとして、加えられる ルールが変わっても、システムに反映されない 例：会議で決まった変更が、システムに 反映されず、古いルールのまま運用される 定義の更新は、システム改修や データチームの手作業待ちになる L4 の議事録やメールから更新案を作り、 人が承認して反映する 個別受注型の業務で、部署をまたぐ判断の準備を AI エージェントに任せ、 人は判断と合意に集中できるようにする。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 59
60. SOBO が目指すサービス 06 SOBO SOBO AI LOOM の 4 層構造 SOBO AI LOOM：部署をまたぐ業務で、AI エージェントを動かすための基盤（特許出願中） 4 層構造で、変わり続けるオントロジーを実現し、日本の複雑な合意形成などに対応する 静的 L1 意味 セマンティックオントロジー L2 手順 動的 業務で使う名詞とその関係を保持する Object Type 例：案件、発注 Property 例：案件の詳細 Link Type 例：案件と発注の関係 Category Type 例：案件を使う場面 業務手順や集計方法など、会社として大きく変わらないプロセスと汎用ルールを保持する キネティックオントロジー Function 例：案件予算の集計処理 L3 決まり 日々の個別処理、部署別・顧客別・例外の処理など、業務の暗黙知を保持する ビジネスルールコンポーネント SOBO 独自 Rule 例：5 千万円以上は社長決裁 L4 文書 オントロジーを変えるきっかけになる情報を保持し、L2〜L4 の更新案を自動で作る ナレッジコンポーネント SOBO 独自 議事録 オントロジーって結局なにもの？ — DevFest 2026 in Kansai Action 例：案件予算報告の集計手順（データ収集〜資料作成） Logic 例：一定額以上は法務確認を追加 メール マニュアル Exception 例：海外案件はリスク 10% 加算 Excel の注釈 60
61. SOBO が目指すサービス 06 SOBO SOBO が目指すこと — 共通の土台に 2 つを加える Fabric IQ などと同じ土台を備えたうえで、業務の暗黙知と、文書による更新を加える。 他のサービスと同じく備えるもの • 業務の型（モノ・関係・属性） • 操作と手順（Action・Function） • 既存システムのデータへの接続 • オントロジーを参照するエージェント • 権限・版・承認の管理 ＋1 業務の暗黙知を、独立した層で持つ（L3） 顧客別・部署別の特別対応など、日本企業に多い個別の カスタマイズルールを、型や操作を変えずに部品として足せる。 版と承認で変更し、稟議や金額別の承認者にも合わせやすい。 ＋2 文書から、つながりと定義を更新し続ける（L4） 議事録やメールの内容を、業務データの人・案件に 型付きで結びつける。そこから L2〜L4 の更新案を作り、 影響範囲を示して、人が承認してから反映する。 ベースは他のサービスと同じ。個別のルールと文書による更新を加えて、変わり続ける業務に合わせることが可能な仕組みを構築。 オントロジーって結局なにもの？ — DevFest 2026 in Kansai 61
62. SOBO が目指すサービス JOIN US 一緒に取り組む仲間を探しています FDE として一緒に働く人、協業パートナー、AI の導入を考えている企業を探しています。 オントロジーを組み込んだ AI エージェントを、業務で使える形にしていきたい FDE として 協業パートナーとして 導入企業として • 業務の意味と決まりを定義し、 エージェントを現場に定着させたい方 • 導入支援・開発・データ基盤の 分野で、一緒に提案や導入をしたい • 製造業・建設業などの業務で、 エージェントを一緒に試したい • オントロジー・グラフ・LLM を、 業務で使えるところまで作りたい方 • オントロジーやグラフの技術を 持っている企業・研究者 • 部署をまたぐ業務の課題や、 AI の導入について相談したい 興味のある方は、終了後に気軽にお声がけください オントロジーって結局なにもの？ — DevFest 2026 in Kansai 62
63. DevFest 2026 in Kansai ご清聴ありがとうございました 村上 智之 ／ 株式会社データラーニング ／ データラーニングギルド