「知識の地図を描く ─ オントロジーとは何か？」というタイトルで DevelopersIO 2026 Sapporo に登壇しました #devio2026
クラウド事業統括本部の石川です。2026 年 10 月 9 日に開催された DevelopersIO 2026 Sapporo のチョークトーク枠で、「知識の地図を描く ─ オントロジーとは何か？」というタイトルで登壇しました。
AI エージェントに業務上正しい判断をさせるには、データと業務用語のあいだにある意味を、機械が読める形で渡す必要があります。このチョークトークでは、理論や解説のみならず、OSSとして公開されている AWS Context Ontology Accelerator（以下 COA）や LLM Wiki を実際に動かした結果をもとに、オントロジーとは何か、データカタログやナレッジグラフとどう違うのかを具体例を挙げて紹介しています。
検証の詳細は、以下の 2 本の記事に書いています。
なお、COA はリリースの頻度が高く、記事執筆時点（2026 年 10 月 9 日）の最新は v0.3.5 です。本記事の検証結果は v0.2.0 / v0.2.2 時点のものです。
登壇資料
セッション概要
AWS Context Ontology Accelerator を実際に動かした経験をもとに、ナレッジグラフやデータカタログとの違いを交えながら、知識の地図としてのオントロジーを解説するチョークトークです。
セッションは、次の 4 つのパートとまとめで構成しました。
- なぜ AI にデータの意味を伝えるのか
- オントロジーとは何か
- カタログ・ナレッジグラフ・LLM Wiki との違い
- AWS Context Ontology Accelerator を動かしてみた
- まとめ：役割分担と、描き始め方
なぜ AI にデータの意味を伝えるのか
SQL は正しく動いたのに、答えは業務上誤りだった
COA の検証で、架空の産業機器商社のデータに「地域別の売上高を教えてください」と質問しました。AI エージェントの回答と、事前に Amazon Athena で出した正解は次のとおりです。
| region | AI の回答 | 正解（shipped のみ） |
|---|---|---|
| Kanto | 1,172,500 | 902,500 |
| Kansai | 546,000 | 546,000 |
| Kyushu | 340,000 | ─ |
| Chubu | 248,000 | ─ |
SQL はエラーなく実行され、テーブルの結合条件も正しく書けていました。それでも Kanto が 30% 多く、本来出てこない Kyushu と Chubu が含まれています。
原因は、売上高の定義がデータの側に書かれていないことです。社内規程（sales-policy.txt）には「売上高は、状態が shipped である受注の total_amount の合計」と書かれています。一方、orders テーブルにあるのは status 列とその値（shipped / pending / cancelled）だけです。AI が生成した SQL には WHERE status = 'shipped' がありませんでした。
人が使う場合と、AI エージェントが使う場合
人が BI やダッシュボードを見るときは、規程を知っているので「売上は出荷済みだけ」と自分で条件を足せます。数字を見て「Kanto が多すぎる」と気づくこともできます。
AI エージェントは、データに書かれた情報だけで意味を解釈し、結果を人が確かめないまま次の処理に使います。AI に任せるのであれば、人が頭の中で補っていた意味を、データの側に書いておく必要があります。
コンテキストレイヤーの 4 つのレイヤ
AI とデータをつなぐ仕組みは、データ → 検索（RAG）→ コンテキストレイヤー → AI エージェント、の 4 つのステップで整理できます。今回のテーマは、取り出したデータの意味を AI に伝えるコンテキストレイヤーです。
セッションでは、コンテキストレイヤーを AI のどの問いに答えるかで 4 つのレイヤに分けました（登壇者の整理）。
| レイヤ | 答える問い | 「売上高」について書く内容 |
|---|---|---|
| カタログ | どこに、どんなデータがあるか | orders.status の説明。値は shipped / pending / cancelled |
| セマンティックレイヤー | その数字を、どう計算するか | total_revenue = SUM(total_amount) WHERE status = 'shipped' |
| ナレッジグラフ | 何と何が、つながっているか | orders は customer_id で customers に、product_id で products につながる |
| オントロジー | それは何で、どの規則に従うか | 「出荷済み受注」は「受注」の一種。売上高の対象は出荷済み受注 |
先ほどの誤答では、どのレイヤにも「売上高 = shipped のみ」が書かれていませんでした。
「知識の地図」の定義
セッションでは、タイトルの「知識の地図」を次の意味で使いました。
業務の概念、概念どうしの関係、適用されるルールを、データ項目と対応付けて、機械が読み・検証できる形で書いたもの
書く内容は、概念（受注・顧客・売上高）、関係（受注は顧客に属する）、ルール（売上高は出荷済みのみ）、データとの対応（orders.status）の 4 つです。データそのものではなく、データをどう読むかを書いたもので、この書き方の代表がオントロジーです。
オントロジーとは何か
定義と 3 つの要素
よく引用される定義は、T. Gruber（1993）の「概念化の明示的な仕様（an explicit specification of a conceptualization）」です。その領域に何があり、どう関係しているかを決め、暗黙の了解のままにせず、機械が処理できる決まった形式で書く、という意味です。データベースが値を保存するのに対し、オントロジーは値が何を意味し、どう関係するかを定義します。
オントロジーは、次の 3 つの要素で組み立てます。
- クラス（Class）: 受注・顧客・商品などの概念や分類
- プロパティ（Property）: placedBy（注文した顧客）などの関係や属性
- インスタンス（Instance）: 注文 5001、佐藤商事などの、クラスに属する個々のもの
プロパティには、ものとものを結ぶ object property と、ものが持つ値を表す datatype property があります。
制約・公理と推論
用語集との大きな違いは、制約と公理を書ける点です。
| 書きたいルール | 記述論理での書き方 |
|---|---|
| 受注には、注文した顧客が必ず 1 人いる | Order ⊑ =1 placedBy.Customer |
| 出荷済み受注とは、status が shipped の受注である | ShippedOrder ≡ Order ⊓ ∃status.{"shipped"} |
| 顧客と商品は互いに素である | Customer ⊓ Product ⊑ ⊥ |
公理を書いておくと推論ができます。「注文 5001 は受注である」「注文 5001 の status は shipped」という事実に、「出荷済み受注 ≡ 受注 かつ status = shipped」「売上高の対象 = 出荷済み受注」という公理を加えると、推論器は「注文 5001 は出荷済み受注であり、売上高の対象に入る」と導きます。
HermiT などの推論器は確率ではなく論理で結論を出すため、同じ入力からは同じ結論が出ます。公理どうしの矛盾も検出できます。
なお、概念の定義を TBox、個別の事実を ABox と呼んで分けます。オントロジーの中心は TBox で、ナレッジグラフは主に ABox の事実を大量に持ちます。
W3C 標準と、開世界・閉世界
オントロジーを書くための W3C 標準は、役割で分かれています。
| 標準 | 役割 |
|---|---|
| RDF | 主語・述語・目的語の 3 つ組（トリプル）でデータを表す |
| RDFS | クラスの階層（subClassOf）と、プロパティの domain・range を書く |
| OWL 2 | 同値・互いに素・個数制約などの公理を書き、推論器で分類と矛盾検出をする |
| SKOS | 用語の階層・同義語・関連語を書く。形式的な推論は目的にしない |
| SHACL | データが決めた形（必須・型・値の範囲）を満たすかを検証する |
OWL と SHACL は、書かれていないことの扱いが違います。注文に顧客が書かれていない場合、OWL（開世界仮説）は「まだわかっていない」と扱い、違反にしません。SHACL やデータベース（閉世界仮説）は「ない」と扱い、違反として報告します。そのため、推論は OWL、検証は SHACL と使い分けます。
カタログ・ナレッジグラフ・LLM Wiki との違い
「オントロジー」と名乗る製品でも、中身はナレッジグラフやセマンティックレイヤーのことがあります。セッションでは、何を書くか、機械に何ができるか、誰が作るか、どの形式で持つか、の 4 つの軸で比べました。
| 仕組み | 書くもの | 機械にできること | 主な作り方 | 形式 |
|---|---|---|---|---|
| データカタログ | データ資産の説明・用語 | 探す | 人が書く。AI が下書き | 製品ごと |
| セマンティックレイヤー | 指標の計算式・正解クエリ | 決めた式で計算する | 人が定義する | 製品ごと |
| ナレッジグラフ | エンティティ間の関係（事実） | 関係をたどる | 自動で抽出し、人がレビュー | プロパティグラフ・RDF |
| オントロジー | 概念・関係の種類・公理・制約 | 推論・検証する | LLM が下書きし、人が承認 | OWL・RDF・SHACL |
下の行ほど書く内容が厳密になり、機械が検証できる範囲が広がります。その分、作るときに人の判断が必要になります。
ナレッジグラフとオントロジーは対立しない
オントロジーが型と規則を決め、ナレッジグラフが事実を持ちます。オントロジーだけでは事実がなく、ナレッジグラフだけでは事実の解釈が LLM の推測に任されます。組み合わせると、事実が規則に合っているかを検証でき、書いていない事実を推論できます。COA も、承認したオントロジーを Amazon Neptune のナレッジグラフに格納します。
LLM Wiki とオントロジー
LLM Wikiは、Andrej Karpathy さん（元OpenAI／元Tesla AI責任者） が提唱した、LLMに個人ナレッジベースを作らせて維持させる設計パターンです。自身のXの投稿で紹介しており、誰もがお試しいただけるようにその構築手順（プロンプト）についてもGitHubで公開しています。
LLM Wikiは、RAGの課題意識から生まれたパターンです。一般的なRAGでは、ファイルをアップロードし、質問時にモデルが関連チャンクを検索して回答を生成しますが、LLM WikiではLLMが生の資料を一度読み込み、構造化・整理されたWikiへと「コンパイル」します。Karpathy自身は「ObsidianがIDE、LLMがプログラマー、WikiがコードベースだEという比喩で説明しており、ソフトウェア開発の発想を知識管理に持ち込んでいる点が特徴です。
- 3 層: 人が集めた元資料（raw/）、LLM が書く要約や概念のページ（wiki/）、構成と運用ルールを書いた schema（CLAUDE.md / AGENTS.md）
- 3 つの操作: 資料を取り込む ingest、Wiki を読んで答える query、矛盾や古い記述を点検する lint
一番の違いは「構造の担い手」です。オントロジーは最終的には人間が厳密な枠組みを設計し、そこにデータを当てはめます。LLM WikiはLLMが資料から後追いで緩やかな構造を作り、運用しながら育てます。
LLM Wiki とオントロジーを比べると、次の違いがあります。
| 観点 | LLM Wiki | オントロジー |
|---|---|---|
| 規約 | CLAUDE.md に自然言語で書く | OWL のクラス・プロパティ・公理として書く |
| 関係 | [[wikilink]]。関係の種類を持たない | object property。種類と domain・range を持つ |
| 点検 | lint。LLM が読んで矛盾やリンク漏れを探す | 推論器と SHACL。論理と形で検証する |
| 主な読み手 | 人 | 機械（推論器・エージェント） |
ただし両者は対立するものではなく、組み合わせることも可能です。例えば、LLM Wikiの設定ファイル（スキーマ）に業界の標準オントロジーの概念体系を取り込めば、ページの分類や用語の統一が安定します。逆に、LLM Wikiで蓄積したエンティティや関係をナレッジグラフへ変換し、厳密なオントロジーへ昇格させるというアプローチも考えられます。
選び方の目安としては、システム連携や規制対応のように正確性・検証可能性が最優先ならオントロジー、調査や社内ナレッジ整理のように速く始めて継続的に育てたいならLLM Wiki、という整理がわかりやすいと思います。
意味を渡すと、回答の正確さはどう変わるか
公開されているベンチマークも紹介しました。評価条件はそれぞれ異なります。
- Sequeda ら（2023）: 保険業界のスキーマで GPT-4 に質問。SQL を直接書かせた場合の 16% が、オントロジーとマッピングを使ったナレッジグラフ経由で 54% になった
- Allemang・Sequeda（2024）: 生成した SPARQL をオントロジーで検査・修正（OBQC）して 72%。「わからない」が 8%、誤答が 20%
- dbt Labs（2026）: 同じ保険ベンチマークの 11 問 × 20 回で、text-to-SQL が 64.5%、セマンティックレイヤーが 72.7%（対象範囲内では 100%）
AWS Context Ontology Accelerator を動かしてみた
COA と AWS Context の関係
2026 年 6 月 17 日の AWS Summit New York City で、AWS Context が Coming soon として発表されました。同時に、AWS Glue Data Catalog の business context が Preview に、Amazon S3 annotations が一般提供（GA）になっています。その後、2026 年 7 月 31 日に COA が OSS として公開されました。
| 観点 | COA | AWS Context |
|---|---|---|
| 提供形態 | OSS（Apache 2.0）。自分の AWS アカウントにデプロイする | マネージドサービス（Coming soon） |
| 主な役割 | 業務オントロジーを、人の承認を経て作る | 既存データの関係を、自動でナレッジグラフにする |
| 進め方 | トップダウン（人が業務上の意味を定義する） | ボトムアップ（データから関係を見つける） |
What's New（2026-07-31）では、COA のユーザー定義オントロジー機能は将来 AWS Context のネイティブ機能になる予定で、COA で作ったオントロジーを AWS Context で利用・管理できるようになるとされています。時期と移行手段は公開されていません。
Scan → Model → Serve
検証は 2026 年 8 月に、COA v0.2.0 を us-east-1 にデプロイして行いました。make deploy-dev で 1 時間 11 分かかり、16 のスタックが作られました。既定の構成はアイドル時に約 930 USD/月かかるため、検証用に縮小して約 0.73 USD/時にしています。
- Scan: 3 テーブル 18 カラムのスキャンと AI による補完が 50 秒で完了しました。FOREIGN KEY 制約のない CSV から、主キー 1 本・外部キー 2 本を確信度 0.95 で推論しています。テーブルとカラムを人が承認しないと、次の induction に進めません。
- Model: Table to Ontology の戦略で、2 秒で提案（proposal）が生成されました。3 クラス、関係 2 本、SHACL 制約 24 件です。AI が推論した外部キーには
scl:fkProvenance "AI_INFERRED"の注釈が付きます。Validate では HermiT 推論器による整合性検査を含む 3 層の検査が行われ、承認後のオントロジーはクラス 3・プロパティ 18・公理 178 でした。 - Metrics: 社内規程の売上高を、
WHERE status = 'shipped'を含む total_revenue として登録しました。 - Serve: 質問を Tier 1（定義済みメトリクス）、Tier 2（NL→SQL、または NL→SPARQL→SQL）、Tier 3（文書検索）の 3 段階で解決します。
聞き方によって、答えの正しさが変わった
同じデータに、聞き方を変えて質問した結果です。
| 質問 | 解決した段 | 結果 |
|---|---|---|
| 地域別の売上高を教えてください | 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 を引用して回答 |
応答時間は Tier 1 が 1.8 秒、Tier 2 が 8.9 秒、Tier 3 が 36.2 秒でした。また、業務文書を取り込んだ後も、「地域別の売上高」への Tier 2 の回答は取り込む前とまったく同じでした。
「売上高はいくらですか」が Tier 1 に一致しなかったのは、同義語を \b（単語境界）で照合していて、助詞が付くとマッチしないためです。v0.2.2 で日本語のデータを試すと、日本語のカラム名ではプロパティが 18 個から 3 個にまとめられることもわかりました。v0.2.2 時点では、テーブル名は日本語、カラム名は ASCII、説明は日本語、が落としどころです。
何が正解を決めたか
- AI の推論で、外部キーのない CSV から結合条件を推論し、JOIN を正しく書けた
- 「売上高 = shipped のみ」は、人が登録した指標（Tier 1）を通ったときだけ使われた
- 規程の文書は Tier 3 でだけ参照され、数値を計算する Tier 2 では使われなかった
関係を推論できることと、業務上正しい答えが返ることは別です。どこを AI の推論に任せ、どこを人が決めた定義で固定するかを、設計で決める必要があります。なお、Tier 1 は登録した指標（セマンティックレイヤー）を実行したもので、OWL の推論で答えたものではありません。
役割分担と、描き始め方
COA の検証でたどった経路を、LLM・推論器・人の役割分担としてまとめると次のようになります。
AWS Prescriptive Guidance にも、LLM と記号推論の役割を次のように整理した記述があります。
The architecture orchestrates both: LLMs propose candidate knowledge, symbolic reasoners validate and refine it.
描き始めるときは、1 つの業務用語から 4 つのレイヤを順に埋める進め方を提案しました。
- カタログに書く: 列の説明と用語を書く（例: status の値の意味）。AWS Glue Data Catalog の business context が使えます
- 指標を定義する: 間違えると困る指標を、式として登録する（例: 売上高）
- 関係をつなぐ: テーブル間・用語間の関係を、レビューしてグラフにする
- オントロジーで検証する: 推測が許されない概念とルールを公理と制約として書き、推論器で検証する
最後に
セッションでお話しした内容は、次の 3 点です。
- データの意味は、データ自体には書かれていない。人が頭の中で補っていた意味を AI に任せるなら、機械が読める形でデータの側に書く必要がある
- オントロジーは、概念・関係・ルールを検証できる形で書く。カタログ・セマンティックレイヤー・ナレッジグラフ・LLM Wiki とは、書く内容と機械にできることが違い、組み合わせて使う
- LLM が提案し、推論器が検証し、人が承認する。COA ではこの分担が画面と API で強制されていた。業務上の正解を返したのは、人が定義した指標だった
AI エージェントに社内のデータを使わせるときは、まず「売上高」のように定義を間違えると困る業務用語を選び、その用語の定義がどこに書かれているかを確かめるところから始めてみてはいかがでしょうか。
