Context Ontology Accelerator 入門 (業務データの意味を、AI エージェントに渡す)

AWS がオープンソース (Apache 2.0) で公開する Context Ontology Accelerator (COA) の入門資料です。COA は、データベースと文書から AI がオントロジーの案を作り、人が確かめて受け入れたものを、メトリクス、構造化クエリ、知識の検索の 3 つの Tier と MCP で AI エージェントに渡します。オントロジーの基礎 (IRI、RDF のトリプル、知識グラフ、RDFS と OWL、推論、SPARQL)、Scan、Model、Serve の流れ、名前空間と問い合わせの守り、AWS の構成、R2RML と仮想知識グラフなどの仕組み、自分の AWS アカウントでの始め方を、公開ワークショップの架空のデータと画面で説明します。v0.3.9 時点 (2026 年 11 月) の公開情報をもとにしています。

Transcript

1. オープンソース (Apache 2.0) Context Ontology Accelerator ⼊⾨ 業務データの意味を、AI エージェントに渡す 2026 年 11 ⽉ 稲⽥ ⼤陸 アマゾン ウェブ サービス ジャパン v0.3.9 時点の公開情報 (2026 年 11 ⽉) 仕⼊先 顧客 商品 営業所 受注 社員 売上合計は︖ 町丁⽬ 配送業者 みどり⻘果商事 業務のデータ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1
2. はじめに この資料で分かること COA は、データから意味のモデルを作り、⼈が確かめ、AI エージェントに渡す 1 AI エージェントが業務のデータの意味を取り違える問題と、COA の解き⽅ 2 オントロジーの基礎: IRI、トリプル、知識グラフ、RDFS と OWL、推論、SPARQL 3 Scan、Model、Serve の 3 つの段階で何をするか 4 問い合わせの守り、AWS の構成、裏側の仕組みと、⾃分の AWS アカウントでの始め⽅ 1 Scan データをつなぐ 2 Model 意味のモデルを作る 3 Serve エージェントに答える COA は Context Ontology Accelerator の略。事実は GitHub の aws/context-ontology-accelerator の v0.3.9 と、公開ドキュメントから取った。 画⾯は公開ワークショップの例 (架空の⾷品卸のデータ)。図の⾊: ⻘は表とデータベース、⻩は⽂書、紫はオントロジーと知識グラフ、緑は⼈が確かめた所 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2
3. はじめに 通しの例: みどり⻘果商事 公開ワークショップの架空の⾷品卸のデータで、最後まで説明する Aurora PostgreSQL (11 テーブル) 顧客 300、商品 72、受注 3,000、受注明細 8,927 件 問い合わせ記録 (⽂書) 同じ顧客コード、受注番号、商品コードを含む みどり⻘果商事 東京都練⾺区の飲⾷店、⼩売店、給⾷施設に、⻘果や⾷品を卸す架空の会社 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 飲⾷店 ⼩売店 3
4. はじめに AI エージェントが困ること 表と列の名前だけでは、「売上」の意味が決まらない 式A 売上合計は︖ SUM(単価 × 数量) 値引きの前の⾦額 単価 数量 値引率 式B SUM(単価 × 数量 × (1 − 値引率)) 値引きの後の⾦額 受注明細 (表) AI エージェント 式 A の答え ??? ≠ 式 B の答え ??? イメージ図 定義が無いと、エージェントは毎回式を組み⽴て直し、同じ⾔葉に違う数字を返すことがある。 COA は、⾔葉とつながりをオントロジーに、決まった計算をメトリクス (名前の付いた SQL の式) に持ち、エージェントに渡す。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
5. はじめに Context Ontology Accelerator 業務の意味をオントロジーにまとめ、エージェントと⼈が使えるようにする Context Ontology Accelerator ⾃分の AWS アカウントで動く AI エージェント MCP でつなぐ AI が案を作る オントロジーと知識グラフ ⼈が確かめる ⼈ Playground、 REST API データベースと⽂書 AWS が GitHub で公開するオープンソース (Apache 2.0)。W3C の標準 (RDF、OWL 2、SHACL、R2RML、SPARQL 1.1) と MCP の上に作られている © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5
6. はじめに 3 つの段階 データをつなぎ (Scan)、意味のモデルを作り (Model)、エージェントに答える (Serve) 売上合計は︖ 1 Scan データをつなぐ 2 Model 意味のモデルを作る 3 Serve エージェントに答える • スキーマを⾒つける • AI がオントロジーの案を作る • Playground、REST、MCP • AI が説明と同義語を付ける • 既存のオントロジーに結ぶ • 3 つの⽅法 (Tier) を順に試す • ⼈が⾒直して承認する • ⼈が⾒直して受け⼊れる • 毎回、権限を判定する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
7. 第1部 オントロジーの基礎 COA の画⾯と出⼒を読むのに必要な範囲を、下の層から順に積み上げる SPARQL 問い合わせ 推論 暗黙の事実 オントロジー RDFS、OWL 知識グラフ つながり トリプル RDF 識別⼦ IRI 下の層の上に、次の層が乗る。COA の画⾯と出⼒を読むのに要る範囲だけを扱う © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
8. オントロジーの基礎 識別⼦ (IRI) ものと概念に、1 つのものだけを指す名前 (IRI) を付ける IRI で名前を付ける (例) http://example.org/midori/顧客 顧客という種類 (クラス) http://example.org/midori/受注 受注システム 顧客 取引先の店 会計システム ? 顧客 請求先かもしれない 問い合わせの⽂書 ? 顧客 ⼀般の⾔葉 受注という種類 (クラス) http://example.org/midori/発注元 受注と顧客の関係 (プロパティ) http://example.org/midori/顧客/C00155 ある 1 つの顧客 (ひまわり弁当) ⽂字列の「顧客」は、システムによって意味が違うことがある。IRI は 1 つのものだけを指す名前で、Web ページは無くてよい © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
9. オントロジーの基礎 RDF のトリプル 事実を「主語・述語・⽬的語」の 3 つ組で書く データベースの⾏ (公開ワークショップのデータ) 受注 受注番号 顧客コード 102835 C00155 外部キー 顧客 顧客コード 顧客名 業態 C00155 ひまわり弁当 飲⾷店 主語 受注102835 受注102835 顧客C00155 述語 発注元 含む商品 業態 ⽬的語 顧客C00155 商品P0020「いちご」 "飲⾷店" ⽬的語は、IRI で指すもの (丸) か、値のリテラル (⻩)。述語の名前は説明⽤ RDF 1.1 では、主語は IRI か空⽩ノード、述語は IRI、⽬的語は IRI、リテラル、空⽩ノードのどれか。実際のデータでは、受注から商品へは受注明細を通る。 図では受注明細を省いた © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
10. オントロジーの基礎 知識グラフ トリプルが同じノードでつながり、グラフになる 受注102835 イメージ図 発注元 業態 "飲⾷店" 顧客C00155 含む商品 発注元 商品P0020 受注102836 業態 "⼩売店" 顧客C00286 同じ主語や⽬的語を持つトリプルがつながり、ノードとエッジの網 (RDF グラフ、知識グラフ) になる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
11. オントロジーの基礎 クラスと個体 (RDFS、OWL) 定義の層 (T-Box) でクラスと階層を決め、個体をクラスに結ぶ 定義の層 (T-Box): クラスとプロパティ 法⼈顧客 rdfs:subClassOf rdf:type 顧客 発注元 rdf:type 受注 rdf:type 事実の層 (A-Box): 個体と、1 件ずつの事実 イメージ図 発注元 顧客C00001 顧客C00155 (ひまわり弁当) 受注102835 rdf:type で個体をクラスに結ぶ。法⼈顧客は階層を説明する例で、ワークショップのデータには無い © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
12. オントロジーの基礎 プロパティと domain、range つながりはオブジェクトプロパティ、値はデータ型プロパティで書く オブジェクトプロパティ Turtle で書く (例) リソースとリソースを結ぶ 受注 発注元 domain (主語の側) 顧客 range (⽬的語の側) データ型プロパティ 業態 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. md:業態 a owl:DatatypeProperty ; rdfs:domain md:顧客 . md: は例の語彙の略、a は rdf:type の略。 リソースと値 (リテラル) を結ぶ 顧客 md:発注元 a owl:ObjectProperty ; rdfs:domain md:受注 ; rdfs:range md:顧客 . domain と range は⼊⼒の検査ではない。 "飲⾷店" 「X 発注元 Y」と書くと、X は受注、Y は顧客と導かれる 12
13. オントロジーの基礎 ラベルと⾔語タグ IRI は変えずに、⾔語ごとの名前と同義語を付ける rdfs:label rdfs:label "顧客"@ja "Customer"@en ⽇本語の名前 英語の名前 md:顧客 skos:altLabel rdfs:comment "取引先"@ja "商品を発注する取引先"@ja ⽇本語の同義語 説明 1 つの IRI に、⾔語タグ付きの名前と同義語をいくつでも付けられる。skos: は W3C の⽤語集の語彙 SKOS © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
14. オントロジーの基礎 推論 公理と事実から、書いていない事実を導く 書いた公理 (定義) md:法⼈顧客 rdfs:subClassOf md:顧客 . 導かれる事実 (どこにも書いていない) 顧客C00001 a md:顧客 . 書いた事実 (説明⽤の例) 顧客C00001 a md:法⼈顧客 . 法⼈顧客は顧客の⼀種なので、顧客でもある 推論器 (reasoner) ほかの導き⽅ (RDFS、OWL) rdfs:domain / range owl:inverseOf owl:sameAs X 発注元 Y から、X は受注、Y は顧客 「X 発注元 Y」から「Y 発注した X」 同じと宣⾔した個体どうしで事実を共有 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
15. オントロジーの基礎 SPARQL グラフにパターンを重ね、合う所を取り出す 飲⾷店の顧客が発注した受注 (SPARQL) PREFIX md: <http://example.org/midori/> SELECT ?order ?customer WHERE { ?order a md:受注 ; md:発注元 ?customer . 発注元 受注102835 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 顧客C00155 発注元 } SQL と違い JOIN の条件は書かず、同じ変数でつなぐ "飲⾷店" ⼀致: ?order = 受注102835、?customer = 顧客C00155 ?customer md:業態 "飲⾷店" . パターンをグラフに重ねて、合う所を探す。 業態 受注102836 業態 "⼩売店" 顧客C00286 業態が違うので⼀致しない 15
16. オントロジーの基礎 ER 図、⽤語集、知識グラフとの違い オントロジーは意味のモデル、知識グラフはその⾔葉で書いた事実 ER 図、外部キー カタログの説明 ⽤語集 オントロジー 知識グラフ どの列が、どの表の 表と列の説明、 ⾔葉、同義語、 クラス、プロパティ、 トリプルの集まり ⾏を参照するか 同義語、タグ 上位語と下位語 階層、公理 (1 件ずつの事実) 物理の参照。 COA の Scan で SKOS で書ける 意味のモデル (T-Box)。 オントロジーの⾔葉で 意味の名前は無い 作って⾒直す (skos:broader) 推論に使える 事実をつなぐ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
17. オントロジーの基礎 エージェントに効く理由と、COA での使い所 意味を推測させず、⼈が確かめた定義として渡す 「売上」はどの列︖ 町名はどの表︖ Scan Model Serve 表と列の説明、 クラス、プロパティ、 SQL と SPARQL を 同義語、キーを 表との対応を 書くときの⽂脈と、 ⼈が確かめて残す ⼈が確かめて受け⼊れる ⽂書の検索 置き場所 置き場所 置き場所 カタログの Amazon Neptune の 検索の索引と メタデータ 名前付きグラフ グラフ 売上は受注明細から計算する。 町名は町丁⽬にある © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17
18. 第2部 Scan: データをつなぐ データベースと⽂書をつなぎ、AI が付けた説明を⼈が確かめる 確かめて承認 COA Scan みどり⻘果商事 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18
19. Scan: データをつなぐ つなげるデータ データベース、データカタログ、⽂書、グラフをつなぐ Glue Data Catalog JDBC Athena のコネクタ グラフ ⽂書 Athena で引ける PostgreSQL、MySQL Databricks SQL RDF / SPARQL .pdf、.docx Glue のデータベース Amazon Redshift Warehouse ⾃分で作るコネクタ (Amazon Neptune) 既定では無効 .txt、.md SQL Server Oracle、Snowflake アップロードか S3 データベースは、データベースへ直接の SQL か、Amazon Athena の federated catalog で引く (Oracle と Snowflake は Athena だけ)。 SAP や⾃社の API などは、Athena Query Federation SDK でコネクタを作ってつなぐ。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 19
20. Scan: データをつなぐ スキャンとレビュー AI が説明と同義語を付け、⼈が確かめて承認したものだけを使う 1 検出する テーブル、列、制約 2 AI で補う 説明、同義語、キー 3 ⼈が⾒直す 直して、承認か却下 4 承認する 承認したものだけ次へ テーブルの詳細 (公開ワークショップの例)。説明、同義語、タグ、⽤語集の⽤語を確かめ、直してから承認する © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20
21. Scan: データをつなぐ ⽂書の取り込み ⽂書から概念とつながりを取り出し、知識グラフと検索の索引に⼊れる 1 前処理 2 抽出 3 知識グラフ 4 テキストを取り出して 概念とつながりを Amazon Neptune に チャンク (区切り) にする 取り出す (Bedrock) ノードとエッジを作る 埋め込み OpenSearch Serverless にベクトルで置く ⽂書は .pdf、.docx、.txt、 .md。画⾯から 100 件まで アップロードするか、S3 の バケットを指す。 ⽂書のデータソースを作る画⾯の⼀部 取り出すエンティティの クラスは、⽂書から推定するか (推奨、画⾯の表記は「⽂書から © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 推論」)、⾃分で決める。 21
22. 第3部 Model: 意味のモデルを作る AI がオントロジーの案を描き、⼈が⾒直して受け⼊れる オントロジーの案 AI が案を描く ⼈が⾒直す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 参照のオントロジー 22
23. Model: 意味のモデルを作る オントロジーの誘導 (induction) 承認したデータソースから、AI がオントロジーの案を作る オントロジーの案 ⾒直し待ち 承認した表 ⼈が⾒直し、 検証して、 受け⼊れる AI (Bedrock) 取り込んだ⽂書 クラス プロパティ R2RML 表からの誘導はマッピング (R2RML) も作り、SQL で引ける。⽂書からの誘導はマッピングを持たない どちらの⽅法も、Amazon Bedrock がクラスの説明を書き、次のページのグラウンディングで結んでよいかも確かめる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 23
24. Model: 意味のモデルを作る グラウンディング 新しいクラスを既存のオントロジーに結び、同じ概念が増えないようにする 参照するオントロジー 誘導した新しいクラス 受注 Dublin Core の Policy ⽅針 Schema.org FIBO 受け⼊れ済みの案 rdfs:subClassOf skos:exactMatch など 保険の policy 保険証券 名前が同じでも、意味が違えば結ばない (既定の ENHANCED は LLM で分野を確かめる) 参照先は誘導を始めるときに選ぶ (API では groundingOntologyIds)。画⾯では、同じ名前空間で受け⼊れ済みのオントロジーが最初から選ばれている © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 24
25. Model: 意味のモデルを作る 案の⾒直しと受け⼊れ 案は⼈が⾒直して検証し、受け⼊れたものだけを Serve で使う 1 案を作る 誘導 (AI) 2 ⼈が⾒直す クラス、つながり 3 検証する 整合性、型の名前 4 受け⼊れる Serve で使われる 検証は、 推論器 (HermiT) に よる整合性、孤⽴した クラス、データ型の 名前を⾒る。 受け⼊れたものは 案の検証の結果 (公開ワークショップの例) 書き換えず、 誘導し直して 受け⼊れ直す。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 25
26. Model: 意味のモデルを作る メトリクス よく使う計算は、名前と SQL の式で決めておく メトリクス total_revenue 同義語 売上合計、総売上 データソース midori-aurora の 受注明細 説明 値引き後の売上の合計 SQL 式 (PostgreSQL) 「売上合計」 名前か同義語だけの質問 Tier 1 この SQL をそのまま流す SELECT SUM("単価" * "数量" * (1 - "値引率")) AS "売上合計" FROM "受注明細" SQL Firewall が流す前に確かめる メトリクスは 1 つのデータソースの 1 つのテーブルに結び付く。図の値は公開ワークショップの例。Tier 1 は第 4 部、SQL Firewall は第 5 部で説明する。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 26
27. Model: 意味のモデルを作る どこに書くか 決まった計算はメトリクス、⾔葉とつながりはオントロジー、理由は⽂書に置く メトリクス オントロジー Tier 1 ⽂書 Tier 2 決まった計算を、 概念、⾔葉、つながり、 ⽅針、理由、⼿順、 毎回同じ式で流す 列と業務の意味の対応 例外の扱い 例 例 例 total_revenue = SUM(単価 × 数量 受注、顧客、発注元、業態 いつ注⽂を売上に 受注と顧客のつながり 数えるかの⽅針 Tier 3 × (1 − 値引率)) 3 つは置き換えではなく、互いに補う © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27
28. 第4部 Serve: エージェントに答える 質問に確かな⽅法から順に答え、根拠を返す 答えと根拠が戻る 売上合計は︖ Tier 1 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Tier 2 Tier 3 28
29. Serve: エージェントに答える 3 つの Tier メトリクス、構造化クエリ、知識の検索の順に、確かな⽅法から答えを探す Tier 1 メトリクス 質問 Tier 2 構造化クエリ Tier 3 知識の検索 決めた SQL を オントロジーで ⽂書とグラフを そのまま流す SQL や SPARQL 探してまとめる を作る 「売上合計」 名前か同義語だけの質問 「町名別の売上合計」 絞り込みや切り⼝がある なければ次へ 「受注 102835 の問い合わせ」 表だけでは答えられない なければ次へ 確かな⽅法から順に試し、答えが出た Tier で⽌まる。どの Tier が答えたかは根拠のパネル (トレース) に残る © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29
30. Serve: エージェントに答える Tier 1 と Tier 2 の例 メトリクスに当たれば決めた SQL を流し、絞り込みがあれば Tier 2 に回す 質問「売上合計」 「売上合計」は、メトリクス total_revenue の 同義語に当たり、決めた SQL をそのまま 流した。 「町名別」はメトリクスの式では扱えない。 質問「町名別の売上合計を教えて」 Tier 1 は理由を書いて⾶ばし、Tier 2 が SQL を 作った。 Tier 1 が⾶ばしたときも、メトリクスの式は Tier 2 に渡され、Tier 2 はその式をもとに SQL を作る。 Playground の根拠のパネル (公開ワークショップの例) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 30
31. Serve: エージェントに答える 知識の検索 (Tier 3) 表で答えられない質問は、⽂書と知識グラフを探して答える 質問「受注番号 102835 の問い合わせ内容と対応状況を教えて」 ベクトル検索で関連する⽂書とエンティティを ⾒つけ、グラフをたどり、Amazon Bedrock で 答えをまとめる。 答えには、参考にした⽂書が付く 答えの⼀部と、根拠のパネルの解決⽅法 (公開ワークショップの例) (この例では 5 件)。 20〜90 秒かかることがある。REST は 29 秒で 切れるので、ストリーミングで受ける。 出典: 公開ドキュメント「Serve」(Tier 3 — Knowledge Retrieval、REST API) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 31
32. Serve: エージェントに答える 深い推論 (Deep Reasoning) 表の数字と⽂書の両⽅が要る質問は、深い推論のモードで答える 標準 (既定) 深い推論 進め⽅ Tier 1 → 2 → 3 の順。最初に確かな答えを 出した Tier で終わる LLM が計画を⽴て、SQL の⽣成、グラフを たどる、⽂書の検索を選んで組み合わせる 根拠 答えた Tier の根拠だけ 表の数字と⽂書を 1 つの答えにまとめられる (両⽅を使う保証は無い) メトリクス Tier 1 で使う Tier 1 のメトリクスを通らずに始める 時間 構造化の質問ではいちばん短い 何度もモデルを呼ぶ。数⼗秒かかる Playground の切り替え (標準 / 深い推論)。深い推論は LLM の進め⽅の名前で、第 1 部の 推論器とは別 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 32
33. Serve: エージェントに答える エージェントからの使い⽅ (MCP) エージェントは MCP でつなぎ、使う⼈の権限のまま動く ⾒つける list_metrics Streamable HTTP 使う⼈の MCP サーバー Amazon Bedrock AgentCore Runtime describe_schema 動かす ID トークン query translate_sparql rag_retrieval MCP クライアント Kiro、Claude Desktop、Cursor など graph_traversal どのツールも、使う⼈の権限で判定する エージェントは⾃分の ID を持たず、使う⼈がサインインして得たトークンで動く (OIDC の 3LO、認可コードと PKCE)。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 33
34. 第5部 守りと構成 名前空間と役割でデータを分け、問い合わせごとに権限を判定する 名前空間: 販売 名前空間: 物流 名前空間: 経理 名前空間: ⼈事 使う⼈のトークン ⼊⼝の判定 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. owner 34
35. 守りと構成 名前空間と役割 名前空間ごとにデータを分け、役割で操作を絞る platform-admin と platform-viewer は、すべての名前空間にまたがる役割 名前空間: 販売 名前空間: 物流 Σ データソース owner オントロジー maintainer data-steward メトリクス data-analyst Σ データソース owner オントロジー maintainer data-steward メトリクス data-analyst owner と maintainer (正式名は namespace-owner、namespace-maintainer) は名前空間の管理と権限の付与。data-steward はデータソース、オントロジー、 メトリクスの管理と問い合わせ。data-analyst は問い合わせと閲覧だけ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 35
36. 守りと構成 問い合わせの守り ⼊⼝の判定 (Cedar) と SQL Firewall で、許された範囲だけを読む ⼊⼝の判定 Cedar: この名前空間に query してよいか Tier 1、2: SQL を流す Tier 2 は質問の個⼈情報を伏せる SQL Firewall データベース SELECT だけ。許された テーブルと列だけ Tier 3: ⽂書とグラフ SQL の無い経路も⼊⼝で判定 質問 権限の情報が読めないときは断る。許可外のテーブルは根拠のパネルにも出さない。メトリクスの許可リスト、グラフへの SPARQL Firewall もある © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 36
37. 守りと構成 AWS の構成 ⾃分の AWS アカウントに、17 の CloudFormation スタックとコネクタを⽴てる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 37
38. 守りと構成 名前空間の⾔語 名前空間を⽇本語で作ると、COA が作る説明とラベルが⽇本語になる ⽇本語になるもの: 説明、同義語、 ⽤語集の⽤語、タグ、⽂書から 取り出す概念とつながり、誘導した クラスの説明。 そのまま残るもの: テーブル名、 列名、⽂書の本⽂、型番や 製品名などの識別⼦。 COA が⽇本語だけで書いた ラベルには、⾔語タグ (@ja) が付く。 名前空間を作るときの⾔語の確認 (公開ワークショップの例) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ⾔語はあとから変えられない。 38
39. 第6部 仕組み マッピング、仮想知識グラフ、Tier の振り分け、取り込み、誘導の中⾝ RDF © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. R2RML SPARQL Ontop 39
40. 仕組み 表と知識グラフの対応 (R2RML) 表の⾏と列を、オントロジーの IRI とプロパティに写す R2RML のマッピング (Turtle) # base IRI: http://example.org/midori/ <#受注Map> a rr:TriplesMap ; rr:logicalTable [ rr:tableName "受注" ] ; rr:subjectMap [ rr:template "受注/{受注番号}" ; rr:class md:受注 ] ; rr:predicateObjectMap [ rr:predicate md:発注元 ; rr:objectMap [ rr:template "顧客/{顧客コード}" ] ] . rr:class に書かれたクラスが「マップ済み」。 NL→SQL と Ontop は、マップ済みのクラスだけを使う © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 表「受注」の 1 ⾏ 受注番号 顧客コード 102835 C00155 イメージ図 この⾏からできるトリプル rdf:type md:受注 …/受注/102835 md:発注元 …/顧客/C00155 40
41. 仕組み 仮想知識グラフ (VKG) オントロジーの⾔葉で書いた SPARQL を、Ontop が SQL に直して流す 1 質問 2 SPARQL を作る 3 Ontop 4 SQL Firewall 5 データベース 業態別の オントロジーの R2RML で SELECT だけ、 SQL を流して 受注件数は︖ ⾔葉で書く (LLM) SQL に直す 許された表と列 ⾏を返す SPARQL (オントロジーの⾔葉) SQL (表と列の名前) SELECT ?type (COUNT(?order) AS ?n) WHERE { ?order md:発注元 ?cust . ?cust md:業態 ?type . } GROUP BY ?type SELECT c."業態", COUNT(*) AS n FROM "受注" o JOIN "顧客" c ON o."顧客コード" = c."顧客コード" GROUP BY c."業態" イメージ図 VKG (仮想知識グラフ) はデータを RDF に写さず、SPARQL をその場で SQL に直して元のデータベースで流す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 41
42. 仕組み Tier 2 のエンジンと実⾏の経路 3 つのエンジンを順に試し、SQL は使える中で速い経路で流す Tier 2 のエンジン (既定 nl_to_sql_first の順。NL は⾃然⾔語) 1 NL→SQL 2 NL→SPARQL 3 確かな答えを出したエンジンで⽌まる。 Ontop strategy で 1 つに固定もできる。 カタログのスキーマ グラフのソースに SPARQL を R2RML から SQL を書く SPARQL を流す で SQL に直す 要る物: マップ済みクラス 要る物: RDF のグラフ 要る物: 受け⼊れた R2RML グラフのソースは既定でオフ SQL を流す経路 (Tier 1 と Tier 2、⾃動で選ぶ) データベースへ直接 Athena の federated catalog 通常 20〜50 ms ほど 通常 500〜800 ms ほど 1 つのソースで、直接の SQL が使えるとき ソースをまたぐか、直接の経路が無いとき 時間は公開ドキュメント「Serve」(Structured Query execution paths) の⽬安 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 42
43. 仕組み Tier 1 の振り分け メトリクスが質問をすべて受け⽌めたときだけ、決めた SQL を流す 「売上合計は︖」 質問に、メトリクスの名前か同義語があるか 当たるメトリクスは、ちょうど 1 つか 質問に、扱えない⾔葉が残っていないか 無ければ綴りの近さで探す (0.88 以上、⾔い換えは不可) 2 つ以上なら Tier 2 へ Tier 2 「町名別」は式を添えて Tier 2 へ 決めた SQL をそのまま流す © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 43
44. 仕組み ⽂書から作るグラフ 既定の Tier 3 は、⽂書のグラフを本⽂からエンティティへたどる Source Chunk Topic Statement Fact Entity ⽂書 本⽂の 話題 ⽂ 事実 名前の付いたもの かたまり 既定の Tier 3 は、Amazon Neptune にある⽂書のグラフを この順にたどり、Amazon OpenSearch Serverless の索引も読む。 Topic と Entity は、取り込みのときに⽂書から取り出したもの。受け⼊れたオントロジーとは別 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 44
45. 仕組み ⽂書の取り込みの中⾝ 分割し、取り出し、グラフと索引に置いて、⽂書を探せる形にする 知識グラフ 埋め込み 前処理と分割 取り出し 置き場所 重なり 25 トークン。 Bedrock のバッチ処理 (既定) OpenSearch Serverless に ⽇本語は 1024 を推奨。 で取り出す チャンクの埋め込み 既定は 256 トークン、 概念とつながりを、Amazon Amazon Neptune にノードとエッジ、 表の PDF は Textract (任意) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 45
46. 仕組み 誘導とグラウンディングの中⾝ グラウンディングを終えられない誘導は、⽋けた案を返さず失敗にする 誘導のジョブの状態 pending fetching_metadata matching building_ontology storing completed グラウンディングを終えられないときは failed にし、⽋けた案を返さない STANDARD の判定 (名前が完全に⼀致しないとき、埋め込みの似ている度合いで) 似ている度合い 0.80 (既定) 0.50 新しいクラス ambiguous high_confidence NONE STANDARD ENHANCED (既定) 結ばない。すべて新しい LLM を使わない。名前の LLM が分野の⼀致を クラスとして扱う ⼀致と上の⽬盛りで決める 確かめてから結ぶ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 0.95 exact 46
47. 始め⽅ 始め⽅ リリースのタグから取得し、make deploy-dev で⾃分のアカウントに⽴てる 前提の道具 1 リリースのタグで取得 git clone --branch v0.3.9 <URL> 2 依存を⼊れる make setup 3 デプロイする make deploy-dev 4 使い始める Web アプリにサインイン 5 ⽚付ける make destroy-dev main ではなくタグを使う Python と CDK の依存 17 のスタックとコネクタ、約 40 分 名前空間を作り、データをつなぐ 使わないときは消す 前提: Python 3.12、Node.js 22.23.4 以上、Docker か Finch、pnpm、Java 17〜24、Gradle、Maven、uv、AWS CLI v2 初回は AdministratorAccess 相当の権限が要り、試されたのは us-east-1 だけ。既定の構成は、使っていなくても⽉に約 1,600 ドル (us-east-1、2026 年 10 ⽉ の⼀覧価格での⽬安)。 出典: 公開ドキュメント「Getting Started」「Deploying」 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 47
48. COA の全体像 まとめ 業務の意味を、⼈が確かめたオントロジーとしてエージェントに渡す 1 AI がデータベースと⽂書からオントロジー案を作り、⼈が確かめる 2 メトリクス、構造化クエリ、知識の検索の順に、確かな⽅法から答える 3 MCP でつないだエージェントも、使う⼈の権限と同じ守りの中で動く 次に読む GitHub ドキュメント ワークショップ github.com/aws/ aws.github.io/ catalog.workshops.aws の context-ontology-accelerator context-ontology-accelerator Context Ontology Accelerator Workshop © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 48
49. 付録 ⽤語 オントロジー 業務の概念、属性、つながり、決まりを、機械が読める形で書いたもの (RDFS、OWL) 知識グラフ トリプルの集まり。COA はオントロジーと⽂書のグラフを Amazon Neptune に置く IRI ものや概念を⼀意に指す名前。例: http://example.org/midori/顧客 トリプル 主語・述語・⽬的語の 3 つ組。RDF で 1 つの事実を書く単位 SPARQL RDF のグラフに問い合わせる W3C の⾔語 名前空間 データソース、オントロジー、メトリクス、権限をまとめる単位 誘導 (induction) データソースから、AI がオントロジーの案を作ること グラウンディング 新しいクラスを、既存のオントロジーの概念に結ぶこと メトリクス 名前と SQL の式で決めた、業務の計算 Tier 質問に答える 3 段の⽅法 (メトリクス、構造化クエリ、知識の検索) R2RML データベースの表とオントロジーの対応を書く W3C の標準 VKG (仮想知識グラフ) データを写さず、SPARQL を SQL に直して元のデータベースで流す仕組み (Ontop) MCP AI エージェントが外の道具を呼ぶための決まり (Model Context Protocol) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 49
50. 付録 参考 GitHub: aws/context-ontology-accelerator https://github.com/aws/context-ontology-accelerator リリース v0.3.9 https://github.com/aws/context-ontology-accelerator/releases/tag/v0.3.9 公開ドキュメント https://aws.github.io/context-ontology-accelerator/ 公開ドキュメント「Serve」(3 つの Tier、問い合わせの守り) https://github.com/aws/context-ontology-accelerator/blob/v0.3.9/external-docs/content/serve.md 公開ドキュメント「Ontologies」(誘導、グラウンディング、受け⼊れ) https://github.com/aws/context-ontology-accelerator/blob/v0.3.9/external-docs/content/ontologies.md W3C の仕様 (RDF 1.1、RDF Schema 1.1、OWL 2、SKOS、SPARQL 1.1、R2RML) https://www.w3.org/TR/ ワークショップ「Context Ontology Accelerator Workshop」(⽇本語) https://catalog.workshops.aws/workshops/e0e3b306-f3cb-423a-b25c-8ee2c6a54b33/ja-JP この資料の内容は v0.3.9 の公開情報にもとづく。新しい版では画⾯や挙動が変わることがある。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 50