Slide 1

Slide 1 text

知識の地図を描く ─ オントロジーとは何か? クラスメソッド株式会社 クラウド事業統括本部 石川 覚

Slide 2

Slide 2 text

自己紹介 石川 覚 ISHIKAWA Satoru Sapporo 現職 クラスメソッド クラウド事業統括本部 領域 データ & AI 基盤の設計・構築、技術発信 発信 DevelopersIO ブログ寄稿、登壇活動 関心 Redshift / Athena / Quick / dbt / Claude / Codex 2020-2026 Japan AWS Top Engineers 2021-2026 Japan AWS All Certifications Engineers クラスメソッド データアナリティクス通信 Claude Code 主要アップデート AWSのアナリティクス関連サービス のアップデートを全て解説 2022/11 以降、毎月連載 Claude Codeに関するアップデートを いち早く検証して紹介 2026/5/24 以降、週5日くらいで連載 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 2

Slide 3

Slide 3 text

本日のアジェンダ 4 つのセクションと、最後のまとめでお話しします Section 01 なぜ AI にデータの意味を伝えるのか この 30 分で答える問い SQL は正しく動いたのに、答えは業務上誤りだった Section 02 オントロジーとは何か 1 AI にデータの意味が伝わらないと、 何が起きるか 2 オントロジーは、カタログやナレッジ グラフと何が違うか 3 実際にオントロジーを作ると、何がわ かるか クラス・プロパティ・公理・推論、W3C 標準 Section 03 カタログ・ナレッジグラフ・LLM Wiki との違い 書く内容と、機械にできることで比べる Section 04 AWS Context Ontology Accelerator を動かしてみた Scan → Model → Serve と、3 つの質問の結果 まとめ 役割分担と、描き始め方 LLM・推論器・人の分担 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 3

Slide 4

Slide 4 text

Sect ion 01 Why Meaning Matters なぜ AI にデータの意味を伝えるのか SQL は正しく動いたのに、答えは業務上誤りだった

Slide 5

Slide 5 text

「地域別の売上高を教えて」への回答 検証環境の AI エージェントが返した数字と、正解を並べる AI の回答(LLM が生成した SQL) region 正解(社内規程どおり shipped のみ) 売上高 region 売上高 Kanto 1,172,500 Kanto 902,500 Kansai 546,000 Kansai 546,000 Kyushu 340,000 Kanto が 30% 多い Kyushu・Chubu は本来出てこない Chubu 248,000 SQL はエラーなく実行され、テーブルの結合条件も正しかった。それでも業務上は誤りの数字だった 出典: 石川「AWS Context Ontology Accelerator(COA)で業務オントロジーを構築してみた」DevelopersIO, 2026-08-17 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 5

Slide 6

Slide 6 text

原因:売上高の定義がデータに書かれていない 社内規程に書かれた定義と、テーブルが持っている情報の差 社内規程 SP-2025(業務文書 sales-policy.txt) 「売上高(revenue)」は、状態が shipped(発送済み) である受注の total_amount の合計と定義する。pending および cancelled の受注は売上高に含めない。 orders テーブル(Glue Data Catalog) order_id customer_id product_id quantity total_amount order_date status 値: shipped / pending / cancelled status のどの値が売上高に入るかは、テーブルには書かれていない SELECT c.region, COALESCE(SUM(CAST(o.total_amount AS DOUBLE)), 0) AS total_sales FROM orders o JOIN customers c ON o.customer_id = c.customer_id GROUP BY c.region ORDER BY total_sales DESC -- WHERE status = 'shipped' がない AI が生成して実行された SQL(記事の Compiled artifacts より) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 6

Slide 7

Slide 7 text

人が使う場合と、AI エージェントが使う場合 足りない意味を誰が補い、結果を誰が確かめるか 人(BI・ダッシュボード) AI エージェント 意味を補う 規程を知っているので「売上は出荷済みだけ 」と自分で条件を足す データに書かれた情報だけで意味を解釈する 結果を確かめる 数字を見て「Kanto が多すぎる」と気づける 結果を人が確かめないまま、次の処理に使う 問い合わせ方 決まったレポートを、1 日に数回見る 質問のたびに、複数のテーブルを組み合わせ て何度も問い合わせる AI に任せるなら、人が頭の中で補っていた意味を、データの側に書いておく必要がある 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 7

Slide 8

Slide 8 text

AI とデータをつなぐ 4 つのステップ 検索で取り出したデータに、その意味を添えてエージェントに渡す 01 データ 02 検索(RAG) 03 コンテキストレイヤー 04 AI エージェント データを保管する 質問に必要な情報を探して 取り出す 取り出したデータの意味を AI に 伝える 意味を踏まえて回答・処理 する 業務データベース 例: Amazon Bedrock カタログ 例: Amazon Bedrock DWH Knowledge Bases セマンティックレイヤー AgentCore / Amazon Quick S3 データレイク ナレッジグラフ オントロジー 今日扱うのは 03 のコンテキストレイヤー。先ほどの誤答は、ここが足りないまま 01・02・04 が動いた結果 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 8

Slide 9

Slide 9 text

コンテキストレイヤーを構成する 4 つのレイヤ それぞれが AI のどの問いに答えるか 基本 カタログ 問い テクニカルメタデータ(テーブル名・列名・型)と、ビジ ネスメタデータ(説明・用語・タグ) セマンティックレイヤー 問い 指標の計算式(Metrics)、正解とするクエリ(Golden Query)、データの使い方の手順(skills) ナレッジグラフ 問い データ資産やエンティティどうしの関係。利用状況から関 係を追加・更新する オントロジー 問い 「どこに、どんなデータがあるか」 「その数字を、どう計算するか」 「何と何が、つながっているか」 「それは何で、どの規則に従うか」 業務の概念の定義、概念の階層、関係の種類、制約 発展 上のレイヤほど基本的で整備しやすく、下のレイヤほど書く内容が厳密になり、作る手間がかかる(登壇者の整理) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 9

Slide 10

Slide 10 text

4 つのレイヤに「売上高」を当てはめる 同じ業務用語でも、レイヤごとに書く内容が違う 層 「売上高」について書く内容 AI ができるようになること カタログ orders.status の説明:受注の処理状態。値は shipped / pending / cancelled status 列の意味がわかる セマンティックレイヤー total_revenue = SUM(total_amount) WHERE status = 'shipped' 誰が聞いても同じ式で計算する ナレッジグラフ orders は customer_id で customers に、product_id で products につながる 地域別などの切り口で結合できる オントロジー 「出荷済み受注」は「受注」の一種。売上高の対象は出荷済み受 注 条件を規則として検証・推論できる 先ほどの誤答では、どの層にも「売上高 = shipped のみ」が書かれていなかった 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 10

Slide 11

Slide 11 text

データと業務用語のあいだにある意味 業務用語を、列・値・条件・関係に対応付ける 業務用語 データ(Glue のテーブル) 合計する値 orders.total_amount 売上高 対象の条件 地域 orders.status = 'shipped' 集計の切り口 customers.region 対応するテーブル customers 顧客 受注との関係 orders.customer_id = customers.customer_id この対応は、テーブル定義には書かれていない。書かれていない部分を、AI は推測で埋める 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 11

Slide 12

Slide 12 text

「知識の地図」とは何か 本セッションでの定義 “ 業務の概念、概念どうしの関係、適用され るルールを、データ項目と対応付けて、機 械が読み・検証できる形で書いたもの 書くもの 概念 受注・顧客・売上高 関係 受注は顧客に属する ルール データそのものではなく、データをどう読むかを書いたもの 売上高は出荷済みのみ データとの対応 orders.status この書き方の代表が、オントロジー 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 12

Slide 13

Slide 13 text

Sect ion 02 What is an Ontology オントロジーとは何か 概念・関係・ルールを、機械が扱える形で書く

Slide 14

Slide 14 text

オントロジーの定義 特定の領域の概念と、概念どうしの関係を、形式的に記述したもの 「概念化の明示的な仕様」 an explicit specification of a conceptualization ── T. Gruber, 1993 概念化 明示的 仕様 その領域に何があり、どう関係しているか を決める 暗黙の了解のままにせず、書き出す 機械が処理できる、決まった形式で書く 語源 哲学の「存在論」。何が存在し、それらがどう関係しているか を扱う 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 データベースとの違い データベースは値を保存する。オントロジーは、値が何を意味 し、どう関係するかを定義する 14

Slide 15

Slide 15 text

オントロジーを構成する 3 つの要素 クラス・プロパティ・インスタンス クラス Class 概念や分類 例:受注、顧客、商品 クラス 受注 顧客 商品 orderedProduct プロパティ Property 関係や属性 placedBy rdf:type(種類) 例:placedBy(注文した顧客) インスタンス インスタンス Instance 注文 5001 佐藤商事 商品 101 クラスに属する個々のもの 例:注文 5001、佐藤商事 注文 5001 は顧客 1(佐藤商事)が、商品 101 を注文した受注(検証データの 1 行目) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 15

Slide 16

Slide 16 text

関係と属性を書き分ける プロパティの 2 種類と、クラスどうしの関係 object property(もの と もの を結ぶ) 受注 ── placedBy ── 顧客 datatype property(もの が持つ値) 受注 ── totalAmount ── 数値 例:注文 5001 placedBy 佐藤商事 例:注文 5001 totalAmount 450000 値は別のインスタンス 例:注文 5001 status "shipped" クラスどうしの関係 is-a 上位・下位の関係 出荷済み受注 は 受注 の一種(rdfs:subClassOf) part-of 全体・部分の関係 受注明細 は 受注 の一部 任意の関係 業務で定義する関係 受注 は 顧客 に注文される(placedBy) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 16

Slide 17

Slide 17 text

制約と公理:「必ずそうである」ことを書く 個々のデータではなく、概念に対するルール。公理は「世界はこうなっている」という宣言、制約は「データはこうでなければならない」 というチェック。 書きたいルール 論理式での書き方(記述論理) 受注には、注文した顧客が必ず 1 人いる Order ⊑ =1 placedBy.Customer 出荷済み受注とは、status が shipped の受注である ShippedOrder ≡ Order ⊓ ∃status.{"shipped"} 顧客と商品は互いに素である(同じものが両方に属さない) Customer ⊓ Product ⊑ ⊥ 用語集 公理 言葉の説明を、人が読むために文章で書く 同じ内容を、機械が推論と検証に使える形で書く ※補足: 上記の記号は ⊑(包含)、≡(同値)、⊓(共通部分)、 ∃(存在)、⊥(空概念)を表す。 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 17

Slide 18

Slide 18 text

推論:書いていない事実を導く 公理と個別の事実から、推論器が分類する 書いてある事実 注文 5001 は 受注 である 注文 5001 の status は shipped 公理 出荷済み受注 ≡ 受注 かつ status = shipped 売上高の対象 = 出荷済み受注 推論器が導く 注文 5001 は 出荷済み受注 であ る 注文 5001 は 売上高の対象 に入 る 「注文 5001 は出荷済み受注」とはどこにも書いていない。公理と事実から、推論器が論理で導く 推論器(HermiT など)は確率ではなく論理で結論を出すため、同じ入力からは同じ結論が出る。公理どうしの矛盾も検出できる 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 18

Slide 19

Slide 19 text

TBox と ABox 概念の定義と、個別の事実を分けて持つ TBox(Terminological Box)概念の定義 ABox(Assertional Box)個別の事実 • 受注・顧客・商品というクラスがある • 注文 5001 は受注である • 出荷済み受注 ≡ 受注 かつ status = shipped • 注文 5001 placedBy 佐藤商事 • placedBy の domain は受注、range は顧客 • 注文 5001 の status は "shipped" • 受注には顧客が必ず 1 人いる • 佐藤商事の region は Kanto オントロジーの中心は TBox。ナレッジグラフは主に ABox の事実を大量に持つ(Section 03 で再び扱う) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 19

Slide 20

Slide 20 text

どこまで厳密に書くか 表現できる意味の強さは段階的に変わる 論理理論 概念モデル シソーラス タクソノミー 用語集 用語リスト 公理・制約で推論できる クラス・関係・属性を書 く 同義語・関連語をつなぐ 上位・下位の階層を作る 言葉の定義を文章で書く 使う言葉を並べる 意味が弱い 意味が強い ライトウェイトオントロジー ヘビーウェイトオントロジー 簡易・柔軟で作りやすい。間違いを含むこともあり、高度な推論には 向かない 詳細・厳密で推論に使える。専門家の知識と、作る時間・保守の手間 がかかる Obrst(2003)の ontology spectrum、ANSI/NISO Z39.19 をもとに登壇者が整理 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 20

Slide 21

Slide 21 text

オントロジーを書くための W3C 標準 表現・語彙・推論・検証で役割が分かれている RDF 表現 主語・述語・目的語の 3 つ組(トリプル)でデータを表す 注文5001 RDFS 語彙 クラスの階層(subClassOf)と、プロパティの domain・range を書く ShippedOrder subClassOf OWL 2 推論 同値・互いに素・個数制約などの公理を書き、推論器で分類と矛 盾検出をする ShippedOrder ≡ SKOS 用語体系 用語の階層・同義語・関連語を書く。形式的な推論は目的にしな い 売上 SHACL 検証 データが決めた形(必須・型・値の範囲)を満たすかを検証する placedBy placedBy altLabel 佐藤商事 Order Order ⊓ … 売上高 minCount 1 COA が扱う標準: RDF / OWL 2 / SHACL / R2RML(DB とのマッピング)/ SPARQL 1.1(問い合わせ) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 21

Slide 22

Slide 22 text

Turtle で書くとこうなる OWL のクラス定義と SHACL の制約(説明用に作成した例) OWL(TBox) SHACL(検証ルール) @prefix ex: . @prefix owl: . @prefix rdfs: . @prefix sh: . ex:Order a owl:Class ; rdfs:label "受注" . ex:Customer a owl:Class ; rdfs:label "顧客" . ex:placedBy a owl:ObjectProperty ; rdfs:domain ex:Order ; rdfs:range ex:Customer . ex:status a owl:DatatypeProperty . ex:OrderShape a sh:NodeShape ; sh:targetClass ex:Order ; sh:property [ sh:path ex:placedBy ; sh:class ex:Customer ; sh:minCount 1 ; sh:maxCount 1 ] . ex:ShippedOrder a owl:Class ; rdfs:label "出荷済み受注" ; owl:equivalentClass [ owl:intersectionOf ( ex:Order [ a owl:Restriction ; owl:onProperty ex:status ; owl:hasValue "shipped" ] ) ] . 17 枚目のルールとの対応 出荷済み受注の定義 → owl:equivalentClass 顧客が必ず 1 人 → sh:minCount / sh:maxCount Turtle は RDF をテキストで書く形式の 1 つ。RDF/XML や JSON-LD でも同じ内容を書ける 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 22

Slide 23

Slide 23 text

開世界仮説と閉世界仮説 「書かれていない」ことをどう扱うかが、OWL と SHACL で違う 例:注文 5009 に placedBy(注文した顧客)が書かれていない OWL:開世界仮説(Open World) SHACL・データベース:閉世界仮説(Closed World) • 書かれていないことは「まだわかっていない」と扱う • 書かれていないことは「ない」と扱う • 違反にはならない。推論で導ける事実があれば補う • sh:minCount 1 の違反として報告する • 用途:推論・分類 • 用途:データの検証 推論は OWL、検証は SHACL と使い分ける。COA の検証も、推論器 HermiT による整合性検査と SHACL による検査の両方を含む 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 23

Slide 24

Slide 24 text

Sect ion 03 Catalog, Knowledge Graph, LLM Wiki カタログ・ナレッジグラフ・ LLM Wiki との違い 同じ「知識を整理する仕組み」でも、書く内容と機械にできることが違う

Slide 25

Slide 25 text

比べるための 4 つの軸 製品の名前ではなく、中身で比べる 01 02 03 04 何を書くか 機械に何ができるか 誰が作るか どの形式で持つか 資産の説明 / 計算式 / 事実 の関係 / 概念とルール 探す / 計算する / たどる / 推論・検証する 人が書く / 自動で抽出する / LLM が下書きして人が承 認する 製品ごとの形式 / Markdown / W3C 標準( RDF・OWL・SHACL) 「オントロジー」と名乗る製品でも、中身はナレッジグラフやセマンティックレイヤーのことがある。4 つの軸で確かめる 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 25

Slide 26

Slide 26 text

データカタログ:どこに何があるかを書く データ資産の目録。AWS では AWS Glue Data Catalog が中心 テクニカルメタデータ テーブル名・列名・データ型・格納場所・パー ティション ビジネスメタデータ 業務上の説明・用語・タグ・オーナー・品質 AWS の対応(2026 年 10 月時点の公開情報) Glue Data Catalog テーブル・列などのテクニカルメ タデータ Glue Data Catalog business context glossary terms・custom metadata・skill assets・ semantic search Amazon S3 annotations S3 オブジェクトに業務上の文脈 を付ける(1 オブジェクト最大 1 GB) GA Preview GA 機械にできること: 探す・説明を読む。skill assets には「集計前に必要なフィルタ」などの使い方を書いたファイルを関連付けられる 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 26

Slide 27

Slide 27 text

セマンティックレイヤー:どう計算するかを書く 指標の定義を 1 か所に置き、誰が聞いても同じ式で計算する 指標の定義の例(COA の Metrics 画面に登録した内容) Metrics 指標の計算式を定義する 名前 total_revenue 同義語 売上 / 売上高 / revenue / total revenue / 売上金額 Golden Query 正解とするクエリを資産として管理する 式 SELECT SUM(CAST(total_amount AS BIGINT)) AS total_revenue FROM coa_blog_sample.orders WHERE status = 'shipped' skills AI への説明 売上高は必ず status = 'shipped' の受注のみを対象とす る。pending や cancelled を含めてはならない データの使い方を AI に指示する手順書 機械にできること: 決めた式で決定的に計算する。定義していない切り口には答えられない(例: dbt Semantic Layer) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 27

Slide 28

Slide 28 text

ナレッジグラフ:何と何がつながっているかを書く エンティティをノード、関係をエッジとするグラフ 現実世界の知識を蓄積・伝達するためのデータのグラフ。ノードは 対象のエンティティ、エッジはエンティティ間の関係を表す プロパティグラフ RDF 表し方 ノードとエッジに属性 を持たせる すべてを主語・述語・ 目的語の 3 つ組で表す 問い合わせ openCypher・Gremlin ・ISO GQL SPARQL 意味の定義 製品ごとのスキーマ OWL・SHACL と組み 合わせられる AWS Amazon Neptune Amazon Neptune Hogan et al., Knowledge Graphs, ACM Computing Surveys, 2021(登壇者訳) Kanto status shipped 注文 5001 region placedBy orderedProduct 佐藤商事 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 商品 101 機械にできること: 関係をたどる。2 つの方式は情報を失わず に相互に変換できる(Hogan et al.) 28

Slide 29

Slide 29 text

ナレッジグラフとオントロジーは対立しない オントロジーが型と規則を決め、ナレッジグラフが事実を持つ オントロジー(TBox):型と規則 is-a 受注 オントロジーだけ 出荷済み受注 顧客 規則はあるが、事実がない 出荷済み受注 ≡ 受注 かつ status = shipped / 受注には顧客が必ず 1 人 ナレッジグラフだけ 事実はあるが、型と規則の解釈は LLM の推測に 任される rdf:type ナレッジグラフ(ABox):事実 注文 5001 注文 5004 佐藤商事 注文 5001: shipped / 注文 5004: pending / 注文 5001 placedBy 佐藤商事 組み合わせる 事実が規則に合っているかを検証でき、書いてい ない事実を推論できる COA は、承認したオントロジーを Amazon Neptune のナレッジグラフに格納する 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 29

Slide 30

Slide 30 text

GraphRAG:文書からグラフを自動で作る Microsoft Research の手法(Edge et al., 2024) 文書 LLM が実体と関係を 抽出 グラフ 関連の強いまとまりご とに要約 GraphRAG 要約を使って回答 オントロジー 型と関係の種類 事前に決めない。LLM が抽出したまま使う 事前に決める(クラス・プロパティ) 制約 持たない 公理・SHACL で書く 向いている質問 「文書全体の主なテーマは何か」のような、文書全体を 見渡す質問 「売上高はいくらか」のような、定義に従って答えが 1 つに決まる質問 誤りの検出 抽出結果を人が確かめる 推論器・SHACL で機械的に検出できる COA の文書取り込みも、文書からエンティティを抽出して lexical graph(語彙のグラフ)を作る 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 30

Slide 31

Slide 31 text

LLM Wiki:LLM が書き続ける Markdown の知識ベース Andrej Karpathy が 2026 年 4 月に gist で公開した考え方 3 つの層 3 つの操作 raw/ 元資料(Web 記事・PDF・メモ)。人が集め、 LLM は読むだけで書き換えない ingest 資料を取り込み、要約を書き、関連するページ を更新する wiki/ 要約・エンティティ・概念のページ。LLM が書き 、ページどうしをリンクする query Wiki を読んで答える。良い答えは Wiki に書き 戻す schema CLAUDE.md / AGENTS.md。Wiki の構成と運用 ルールを書く lint 矛盾・古い記述・孤立したページ・リンク漏れ を点検する 質問のたびに行うこと 知識が残る場所 RAG 元資料から関連する部分を探し直す 残らない(毎回探す) LLM Wiki 整理済みの Wiki ページを読む wiki/ のページとして残る 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 31

Slide 32

Slide 32 text

私の LLM Wiki の構成 Claude Code のスキル(llm-wiki)で ingest / query / lint を実行している スキルに書いている運用ルール ディレクトリ構成 / ├── CLAUDE.md ├── raw/ │ └── assets/ └── wiki/ ├── index.md ├── log.md ├── sources/ ├── entities/ ├── concepts/ └── syntheses/ Wiki のスキーマと運用ルール 元資料(人が追加。LLM は書き換えない) ✓ ページは YAML の frontmatter(type・sources・ updated)を持つ LLM が更新する 全ページの一覧 操作の時系列ログ 資料ごとの要約 固有名詞(人・組織・製品) 概念・テーマ 比較・分析のまとめ ✓ ページどうしは [[wikilink]] でつなぐ ✓ 1 つの事実は 1 ページにだけ書き、ほかはリンクする ✓ 矛盾は自動で解決せず、両方を記録して人が判断する ✓ ingest の要点は、Wiki に統合する前に人が確認する ページの種類(source / entity / concept / synthesis)と命名・リンクの規則を、CLAUDE.md に自然言語で書いている 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 32

Slide 33

Slide 33 text

LLM Wiki とオントロジーの比較 どちらも知識を整理するが、誰が読むことを前提にするかが違う LLM Wiki オントロジー 規約 CLAUDE.md に自然言語で書く(ページの種類・命名 ・リンクの規則) OWL のクラス・プロパティ・公理として書く 関係 [[wikilink]]。関係の種類を持たない object property。種類と domain・range を持つ 一覧 index.md クラスの階層 点検 lint。LLM が読んで矛盾やリンク漏れを探す 推論器と SHACL。論理と形で検証する 主な読み手 人(Obsidian などで読む) 機械(推論器・エージェント) LLM Wiki は人が読むための整理、オントロジーは機械が検証するためのモデル。用途で使い分け、組み合わせられる 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 33

Slide 34

Slide 34 text

「オントロジー」という名前の中身は製品ごとに違う 各社の公開ドキュメントでの説明(2026 年 10 月時点) 製品 公開ドキュメントでの説明 Palantir Foundry Ontology オブジェクト型・リンク型・アクション型で、組織のデータと操作を表す Microsoft Fabric IQ ontology(Preview) エンティティ型・プロパティ・関係・ルール(自然言語)・指標を定義。RDF・Turtle・OWL を取り込める Databricks Genie Ontology モデル化した業務定義(Metric View など)と、クエリやダッシュボードから学習したコンテキストを組み 合わせる Snowflake(エンジニアリングブログ) ノードとエッジのテーブルで表したナレッジグラフと用語の対応表で、Cortex Agents の回答を支える例 Google Cloud Knowledge Catalog 「context engine」と説明。製品ページでは ontology という語を使っていない AWS COA(OSS)で OWL・SHACL のオントロジーを作る。AWS Context(Coming soon)はナレッジグラフ 確かめる点: ① 型と制約を明示的に書けるか 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 ② 推論・検証ができるか ③ 標準形式で出し入れできるか 34

Slide 35

Slide 35 text

意味を渡すと、回答の正確さはどう変わるか 公開されているベンチマークの結果(評価条件はそれぞれ異なる) 16% → 54% 72% 64.5% / 72.7% SQL を直接 → ナレッジグラフ経由 オントロジーで問い合わせを検査・修 正 text-to-SQL / セマンティックレイヤ ー Sequeda ら(2023)。保険業界のスキー マで GPT-4 に質問。オントロジーとマッピ ングで業務の文脈を与えた Allemang・Sequeda(2024)。生成した SPARQL をオントロジーで検査(OBQC) 。「わからない」8%、誤答 20% dbt Labs(2026)。同じ保険ベンチマーク 11 問 × 20 回。セマンティックレイヤーは 対象範囲内では 100% 「text-to-SQL では、失敗はもっともらしい誤答として現れる。セマンティックレイヤーでは、失敗はエラーとして現れる」 dbt Labs, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update(登壇者訳) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 35

Slide 36

Slide 36 text

5 つの仕組みの比較 書く内容・機械にできること・作り方・形式 書くもの 機械にできること 主な作り方 形式 AWS での例 データカタログ データ資産の説明・用語 探す 人が書く。AI が下書き 製品ごと Glue Data Catalog S3 annotations セマンティック レイヤー 指標の計算式・正解クエリ 決めた式で計算する 人が定義する 製品ごと COA の Metrics ナレッジグラフ エンティティ間の関係(事実) 関係をたどる 自動で抽出し、人がレビ ュー プロパティグラフ・ RDF Amazon Neptune AWS Context LLM Wiki 要約・概念のページとリンク 人が読む。LLM が読ん で答える LLM が書き、人が方向付 ける Markdown ─ オントロジー 概念・関係の種類・公理・制約 推論・検証する LLM が下書きし、人が承 認 OWL・RDF・ SHACL COA 下の行ほど書く内容が厳密になり、機械が検証できる範囲が広がる。その分、作るときに人の判断が必要になる 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 36

Slide 37

Slide 37 text

Sect ion 04 Hands-on: Context Ontology Accelerator AWS Context Ontology Accelerator を動かしてみた 2026 年 8 月に v0.2.0 と v0.2.2 を us-east-1 で検証した結果

Slide 38

Slide 38 text

AWS のコンテキストレイヤー関連の動き 2026 年 6 月から 10 月までの公開情報と、本日の検証の位置 2026-06-17 2026-07-31 2026-08-17 2026-08-30 2026-10-02 AWS Summit New York City COA を公開 記事 1 本目 記事 2 本目 v0.3.4 Apache 2.0 の OSS として GitHub で公開(v0.1.0) v0.2.0 で業務オントロジー を構築 v0.2.2 で日本語のデータを 検証 10 月 5 日時点の最新リリ ース AWS Context を発表( Coming soon) Glue Data Catalog の business context( Preview) S3 annotations(GA) 本日の内容は v0.2.0 / v0.2.2 での検証結果。COA は 7 月末の公開から 10 月 2 日までに 9 回リリースされている 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 38

Slide 39

Slide 39 text

AWS Context(Coming soon) 既存データの関係をナレッジグラフに自動で対応付けるマネージドサービス 関係の自動対応付けとレビュー 利用からの学習 既存データの関係をナレッジグラフに自動で対応付ける。デ ータスチュワードが推論された関係をレビューして本番に昇 格し、ビジネス定義や利用ルールを付ける エージェントの利用状況から、正しい結果を出したソースや 結合経路を学び、組織内で共有する オープンな形式 ID に基づく統制 主要なメタデータを Apache Iceberg 形式で S3 Tables に出 力する。Athena・Redshift・Spark などから参照できる 呼び出したユーザーの IAM・Lake Formation の権限を引き 継ぐ。アクセスは監査できる エージェントからは agentic search API と MCP ツールで使う。Amazon Quick のナレッジグラフ技術を、組織全体のグラフに広げたもの 出典: AWS Machine Learning Blog「Context intelligence for your data and AI agents at scale」2026-06-17 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 39

Slide 40

Slide 40 text

COA と AWS Context の関係 人が意味を定義する層と、データから関係を見つける層 観点 Context Ontology Accelerator(COA) AWS Context 提供形態 OSS(Apache 2.0)。自分の AWS アカウントにデプ ロイする マネージドサービス(Coming soon) 主な役割 業務オントロジーを、人の承認を経て作る 既存データの関係を、自動でナレッジグラフにする 進め方 トップダウン(人が業務上の意味を定義する) ボトムアップ(データから関係を見つける) 発表日 2026-07-31 2026-06-17 What's New(2026-07-31)より COA のユーザー定義オントロジー機能は、将来 AWS Context のネイティブ機能になる予定。COA で作ったオントロジーを、AWS Context で利用・管理できるようになるとされている(時期と移行手段は未公開) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 40

Slide 41

Slide 41 text

Context Ontology Accelerator(COA)とは AI がオントロジーの下書きを作り、人が承認し、エージェントに提供する OSS SCAN MODEL S E RV E 1 2 3 接続と充実 誘導と定義 問い合わせ データソースを接続し、スキーマを検出 する。AI が説明・同義語・キーを補い 、人がレビューする 承認したソースからオントロジーを誘導 (induction)し、検証する。指標( Metrics)を定義する 自然言語の質問を、指標・SQL・ SPARQL・文書検索で解決し、MCP で エージェントに提供する 標準 RDF / OWL 2 / SHACL / R2RML / SPARQL 1.1 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 ライセンス リポジトリ Apache 2.0 github.com/aws/context-ontology-accelerator 41

Slide 42

Slide 42 text

COA の構成 主なコンポーネントと AWS サービス(v0.2.0 のドキュメントと検証環境より) データソース AWS Glue Data Catalog JDBC (PostgreSQL・Redshift・ MySQL・SQL Server) 利用者・エージェント COA(CDK で 16 スタック) Scan スキャン・AI エンリッチ・人のレビュー Model ontology engine(induction・グラウンディング・検証 )・Metrics Serve Web アプリ (Playground など) REST API (API Gateway) Tier 1 / 2 / 3 の解決・Ontop(VKG)・SQL ファイアウ ォール MCP サーバー (AgentCore Runtime) Amazon S3 の文書 (PDF・DOCX・TXT など) ネームスペースごとに、Amazon DataZone のプロジェクトと Athena のワ ークグループが払い出される 使う AWS サービス Amazon Neptune (グラフ) 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 Amazon OpenSearch Serverless(ベクト ル) 統制 Amazon Bedrock (LLM・埋め込み) Amazon Athena (フェデレーテッド ) Cognito(OIDC)・Cedar・SQL ファイア ウォール・Bedrock ガードレール 42

Slide 43

Slide 43 text

検証環境とコスト v0.2.0 を us-east-1 にデプロイした結果(2026-08-17 の記事) 1h11m 16 make deploy-dev の所要時 間 CloudFormation スタック 公式ドキュメントでは約 1.5 時間 Neptune と OpenSearch Serverless を 作る storage が最も長い 縮小した設定 OpenSearch Serverless の最小 OCU(aoss_min_ocu) Neptune のインスタンスクラス ontology-engine の Fargate(vCPU / メモリ) Neptune のバックアップ保持期間 約 930 約 0.73 USD/月:既定構成のアイドル 時 USD/時:検証用に縮小した構 成 公式ドキュメントのコスト警告 2 時間弱の稼働で 1.5 USD 程度 既定値 検証用 2 0 db.r8g.large db.t4g.medium 8 vCPU / 32 GB 2 vCPU / 8 GB 7日 1日 検証用の設定であり、本番の構成ではない。aoss_min_ocu は infra/cdk.json に直接書く必要があった 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 43

Slide 44

Slide 44 text

検証データ:架空の産業機器商社 FOREIGN KEY 制約を定義していない CSV と、売上の定義を書いた社内規程 orders(8 行・7 列のうち 4 列を表示) order_id customer_id 5001 1 5002 customers(5 行・6 列のうち 3 列を表示) total_amount status customer_id customer_name region 450,000 shipped 1 佐藤商事 Kanto 1 212,500 shipped 2 鈴木物産 Kansai 5003 2 360,000 shipped 3 高橋工業 Chubu 5004 3 248,000 pending 4 田中製作所 Kanto 5005 4 240,000 shipped 5 伊藤流通 Kyushu 5006 4 270,000 cancelled 5007 5 340,000 pending 5008 2 186,000 shipped docs/sales-policy.txt(社内規程 SP-2025 第 3 項) 「売上高」は、状態が shipped である受注の total_amount の合計と定 義する。pending および cancelled の受注は売上高に含めない status で絞ると Kanto 902,500 / Kansai 546,000。絞らないと Kanto 1,172,500 と Kyushu・Chubu が加わる。どちらの SQL も正 しく動く 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 44

Slide 45

Slide 45 text

Scan:AI が補ったメタデータを人がレビューする 3 テーブル 18 カラムのスキャンと AI による補完が 50 秒で完了 REGISTERED SCANNING ENRICHING order_transactions / purchase_orders / sales_orders Tags sales / transaction / customer / order_tracking Glossary terms e-commerce / order management / transaction / fulfillment Keys 主キー 1 本・外部キー 2 本を確信度 0.95 で推論 (AI_INFERRED) APPROVED 確信度 status に AI が付けた説明 order_id 95% Current fulfillment or processing state of the order (e.g., pending, confirmed, shipped, delivered) quantity 94% total_amount 94% order_date 93% product_id 93% customer_id 92% status 91% AI が orders テーブルに付けたもの Synonyms PENDING_REVIEW カラム どの値が売上高に入るかは書かれ ていない テーブルとカラムを承認しないと、次の induction に進めない。人のレビューが API で強制されている 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 45

Slide 46

Slide 46 text

Model:オントロジーを誘導(induction)する Strategy「Table to Ontology」で、2 秒で提案(proposal)が生成された 変換の規則 Proposal graph テーブル OWL のクラス orders customer_id カラム プロパティ customers 推論した外部キー Class product_id products owl:ObjectProperty Origin 関係 属性 customers Novel 0 6 orders Novel 2 5 products Novel 0 5 提案に含まれるもの Prefixes / R2RML Mapping / Ontology Source(Turtle)/ SHACL Constraints(24 件が自動でアクティブ) Turtle と R2RML は画面で直接編集できる 初回はグラウンディング対象がないため、3 クラスすべてが新規(Novel)になった 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 46

Slide 47

Slide 47 text

誰が関係を記録したのか、オントロジー自体に記録する 誰が言い出した関係なのかが、資産として残る scl:fkProvenance "AI_INFERRED" 制約のない CSV から AI が推論した外部キーは owl:ObjectProperty になり、この注釈が付く AI_INFERRED STEWARD_EDITED グラウンディング AI が推論した関係。画面では確信 度とバッジが表示され、スチュワー ドが Edit keys で直せる スチュワードが編集したメタデータ 。最優先で扱われ、再スキャンして も保持される 2 回目以降は、FIBO などの基盤オ ントロジーや承認済みの概念に rdfs:subClassOf・skos:*Match で つなぐ。完了できなければジョブを failed にする 出典: 石川「AWS Context Ontology Accelerator(COA)で業務オントロジーを構築してみた」DevelopersIO, 2026-08-17 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 47

Slide 48

Slide 48 text

Validate:推論器で提案を検証する 読み取り専用の 3 層の検査。提案そのものは変更しない tier1_blocking tier3_review 承認後のオントロジー • OoPSValidator(OOPS! による設 計の誤りの検出) 3 tier2_scoring 止める検査 点数を付ける検査 • ConsistencyValidator(HermiT 推論器) • TaxonomyCycleValidator • LabelCompletenessValidator • ConnectivityValidator • AmbiguousMatchValidator • SHACLValidator • CompetencyQuestionValidator • DatatypeTokenValidator • StructuralMetricsValidator( OntoQA 系の構造メトリクス) 人が見る検査 18 178 Classes Properties Axioms Accept proposal で Neptune・OpenSearch Serverless・S3 にマージされた(所要 6 秒)。LLM の生成物を推論器で機械的に検証でき る 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 48

Slide 49

Slide 49 text

Metrics:売上高の定義を登録する 社内規程 SP-2025 を、ガバナンス済みの指標として登録した total_revenue Source Expression (Athena・TRINO) ✓ 計算式だけでなく、ユーザーがどう呼ぶか(同義 語)と、AI がいつ使うべきか(Instructions)を 書ける blog-sample-glue / orders SELECT SUM(CAST(total_amount AS BIGINT)) AS total_revenue FROM coa_blog_sample.orders WHERE status = 'shipped' Synonyms 売上 / 売上高 / revenue / total revenue / 売上金額 Instructions 売上高は必ず status = 'shipped' の受注のみを対象とする。pending や cancelled を含めてはならない。この定義は社内規程 SP-2025 第 3 項による全社共通定義である。 ✓ Serve の Tier 1 で最優先に照合される ✓ API で作る場合、式は完全な SELECT 文にする( SQL ファイアウォールが SELECT 文しか実行し ない) ✓ 作成リクエストは API Gateway の 29 秒制限で 504 が返ったが、作成自体は完了していた 出典: 石川「AWS Context Ontology Accelerator(COA)で業務オントロジーを構築してみた」DevelopersIO, 2026-08-17 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 49

Slide 50

Slide 50 text

Serve:質問を 3 段階で解決する 精度の高い方法から順に試し、該当しなければ次の段へ Tier 1 SQL を実行する前の統制 メトリクス解決 定義済みメトリクス 1 件だけに一致したら、その SQL をそのまま実行する。2 件以上一致したら推測せず Tier 2 へ Cedar ユーザーに対する認可の判定 Tier 2 構造化クエリ オントロジー経由の NL → SPARQL → SQL(Ontop の VKG)と、カタログの スキーマからの NL → SQL の 2 経路 SQL ファイアウォール SELECT のみ許可。ユーザーごとのテーブル許可 リストとカラム拒否リスト Bedrock ガードレール Tier 3 ナレッジ検索 入出力の内容のフィルタ ベクトル検索とグラフ探索で文書の文脈を集め、Bedrock で回答を合成する どの段で、どの SQL が実行され、何ミリ秒かかったかは、解決トレースとして画面に表示される 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 50

Slide 51

Slide 51 text

同じデータに、聞き方を変えて質問した結果 どの段で解決されたかで、答えの正しさが変わった 質問 解決した段 結果 地域別の売上高を教えてください Tier 2(LLM が SQL を生成) 誤り:status の条件がなく、Kanto が 30% 多い 売上高はいくらですか Tier 2(Tier 1 に一致せず) 誤り:2,306,500(全 8 件の合計) 売上高 Tier 1(登録した指標) 正解:1,448,500(確信度 100%) 売上高は社内規程でどう定義されていますか Tier 3(文書検索) 正しい定義を、sales-policy.txt を引用して回答 応答時間の例(記事での計測) 1.8 秒 8.9 秒 36.2 秒 Tier 1 Tier 2 Tier 3 業務文書を取り込んだ後も、「地域別の売上高」への Tier 2 の回答は、取り込む前とまったく同じだった 出典: 石川「AWS Context Ontology Accelerator(COA)で業務オントロジーを構築してみた」DevelopersIO, 2026-08-17 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 51

Slide 52

Slide 52 text

何が正解を決めたか 関係を推論できることと、業務上正しい答えが返ることは別 AI の推論でできたこと 人の定義が必要だったこと 文書の知識が使われなかった経路 外部キーのない CSV から結合 条件を推論し、JOIN を正しく 書けた 「売上高 = shipped のみ」 は、登録した指標(Tier 1) を通ったときだけ使われた Tier 2 が参照するのはオント ロジーとスキーマで、文書で はない。規程は Tier 3 でだけ 参照された v0.2.2 の検証でも同じ傾向: 文書にしか書いていない「発注点」のルールは、文書を取り込む前は「在庫 0」と解釈され、確信度 0.4 のまま 答えとして返った どこを AI の推論に任せ、どこを人が決めた定義で固定するかを、設計で決める必要がある 補足: Tier 1 は登録した指標(セマンティックレイヤー)を実行したもので、OWL の推論で答えたものではない 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 52

Slide 53

Slide 53 text

日本語のデータで試す(v0.2.2) オフィス用品商社を想定した 3 テーブル(商品マスタ・顧客マスタ・受注明細) 項目 結果 日本語のテーブル名 使える。クラスの rdfs:label が日本語になる 日本語のカラム名 避ける。1 テーブルのカラムが 1 つのプロパティ IRI にまとめられ、18 個が 3 個になった 日本語のカラム説明 有効。スキーマ文脈に日本語の説明として入る 日本語の質問(Tier 2) 通る。初回の SQL で日本語の識別子を引用符で囲み忘れ、2 回目で成功した 日本語の業務文書 通る。抽出される命題は日本語と英語が混在する Tier 1 の指標の同義語 機能しない。\b(単語境界)で照合するため、助詞が付くとマッチしない テーブル詳細 API 非 ASCII のテーブル名では 404(パスパラメータが URL デコードされない) 落としどころ: テーブル名は日本語、カラム名は ASCII、説明は日本語。いずれも v0.2.2 時点の挙動 出典: 石川「AWS Context Ontology Accelerator(COA)で日本語のオントロジーを構築してみた」DevelopersIO, 2026-08-30 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 53

Slide 54

Slide 54 text

エージェントからの接続 MCP サーバーは AgentCore Runtime 上で動き、6 つのツールを公開する ツール 用途 list_metrics 定義済みメトリクスの一覧 describe_schema オントロジーのスキーマ(クラス・プロパティ・テーブル) の説明 認証と認可 • エージェント専用のマシン間クレデンシャルはない 。常にユーザーの代理として動く query 自然言語での問い合わせ • Web アプリと同じ OIDC の 3LO(Authorization Code + PKCE)で取得したトークンを使う translate_sparql 自然言語から SPARQL への変換 • 監査ログの principalId は代理元のユーザー rag_retrieval 意味が近い文書チャンクの取得 graph_traversal エンティティの関係をたどる • MCP の経路は API Gateway を通らないため、Tier 3 の長い問い合わせにも対応できる(120 秒) エージェントは、そのユーザーに許可された範囲でしかオントロジーとデータにアクセスできない 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 54

Slide 55

Slide 55 text

動かしてわかった注意点 2026 年 8 月時点(v0.2.0 / v0.2.2) ✓ リージョン 検証済みは us-east-1 のみ。GovCloud・中国リージョンは非対応。既定のモデル ID は US のクロスリ ージョン推論プロファイル ✓ コスト 既定の構成はアイドル時に約 930 USD/月。使わないときはスタックを削除する ✓ タイムアウト REST API は API Gateway の 29 秒制限がある。Tier 3 まで進む質問は 504 になることがある ✓ 初期管理者 デプロイ前に SSM の initialAdminEmail を設定する。未設定だと [email protected] で作られ、ロ グインできない ✓ 変化の速さ 7 月末の公開から 10 月 2 日までに 9 回リリースされている。動作はバージョンごとに確認する 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 55

Slide 56

Slide 56 text

LLM・推論器・人の役割分担 COA の検証でたどった経路をまとめる 01 02 03 04 LLM が提案する 推論器が検証する 人が承認する 決定的に実行する 説明・同義語・外部キーの候補 ・オントロジーの下書き HermiT・SHACL で、矛盾や制 約の違反を検出する テーブル・カラム・提案を承認 し、業務の定義を指標として登 録する 登録した指標の SQL を、その まま実行する “ LLMs propose candidate knowledge, symbolic reasoners validate and refine it. (LLM が知識の候補を提案し、記号推論器がそれを検証して洗練する)── AWS Prescriptive Guidance「Semantic Layer for Agentic AI using Ontology, Symbolic Reasoning, and Virtual Knowledge Graph 」 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 56

Slide 57

Slide 57 text

知識の地図をどこから描き始めるか 1 つの業務用語から、4 つの層を順に埋める STEP 1 STEP 2 STEP 3 STEP 4 1 2 3 4 カタログに書く 指標を定義する 関係をつなぐ オントロジーで検証する 列の説明と用語を書く 例: status の値の意味 間違えると困る指標を、式として 登録する 例: 売上高 テーブル間・用語間の関係を、レ ビューしてグラフにする 推測が許されない概念とルールを 、公理と制約として書き、推論器 で検証する Glue Data Catalog の business context セマンティックレイヤー・COA の Metrics ナレッジグラフ COA(OWL・SHACL) 最初は「売上高」のように、定義を間違えると困る業務用語を 1 つ選び、その用語について 4 つの層を埋める 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 57

Slide 58

Slide 58 text

まとめ 本日お話しした 3 つのポイント 01 02 03 データの意味は、データ自体には書かれていない 人が頭の中で補っていた意味を AI に任せるなら、機械が読める形でデータの側に書く必要がある オントロジーは、概念・関係・ルールを検証できる形で書く カタログ・セマンティックレイヤー・ナレッジグラフ・LLM Wiki とは、書く内容と機械にできることが違う。対立せず組 み合わせて使う LLM が提案し、推論器が検証し、人が承認する COA ではこの分担が画面と API で強制されていた。業務上の正解を返したのは、人が定義した指標だった 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 58

Slide 59

Slide 59 text

参考資料 本日の内容の出典 石川「AWS Context Ontology Accelerator(COA)で業務オントロジーを構築してみた」 DevelopersIO, 2026-08-17 https://dev.classmethod.jp/articles/20260817-aws-context-v020/ 石川「AWS Context Ontology Accelerator(COA)で日本語のオントロジーを構築してみ た」DevelopersIO, 2026-08-30 https://dev.classmethod.jp/articles/20260830-aws-context-v022/ T. Gruber, A Translation Approach to Portable Ontology Specifications, 1993 https://tomgruber.org/writing/ontolingua-kaj-1993/ A. Hogan et al., Knowledge Graphs, ACM Computing Surveys, 2021 https://arxiv.org/abs/2003.02320 L. Obrst, Ontologies for Semantically Interoperable Systems, CIKM 2003 http://jfsowa.com/ikl/Obrst03.pdf AWS What's New: Context Ontology Accelerator, 2026-07-31 W3C: OWL 2 Primer / SHACL / SKOS Reference https://aws.amazon.com/about-aws/whats-new/2026/07/aws-context--ontology-accelarator-generally-available/ https://www.w3.org/TR/owl2-primer/ / https://www.w3.org/TR/shacl/ / https://www.w3.org/TR/skos-reference/ Context Ontology Accelerator(GitHub / ドキュメント) J. Sequeda et al., A Benchmark to Understand the Role of Knowledge Graphs on LLM's Accuracy, 2023 https://github.com/aws/context-ontology-accelerator / https://aws.github.io/context-ontology-accelerator/ https://arxiv.org/abs/2311.07509 AWS ML Blog「Context intelligence for your data and AI agents at scale」202606-17 https://aws.amazon.com/blogs/machine-learning/context-intelligence-for-your-data-and-ai-agents-at-scale/ D. Allemang, J. Sequeda, Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!, 2024 https://arxiv.org/abs/2405.11706 AWS Glue Developer Guide「Adding business context」 dbt Labs, Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update https://docs.aws.amazon.com/glue/latest/dg/catalog-business-context.html https://docs.getdbt.com/blog/semantic-layer-vs-text-to-sql-2026 A. Karpathy「llm-wiki」gist, 2026-04 D. Edge et al., From Local to Global: A Graph RAG Approach, 2024 https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f https://arxiv.org/abs/2404.16130 AWS Prescriptive Guidance「Semantic Layer for Agentic AI using Ontology, Symbolic Reasoning, and Virtual Knowledge Graph」 https://docs.aws.amazon.com/prescriptive-guidance/latest/semantic-layer-agentic-ai-ontology-reasoning-virtualknowledge-graph/ 知識の地図を描く ─ オントロジーとは何か? | DevelopersIO 2026 Palantir / Microsoft Fabric IQ / Databricks / Snowflake / Google Cloud の各公開ド キュメント(34 枚目) palantir.com/docs / learn.microsoft.com/fabric/iq / databricks.com/blog / snowflake.com/blog / cloud.google.com/blog 59

Slide 60

Slide 60 text

No content