AWSのオントロジーとは：Context Ontology Accelerator入門
この記事で学べること
- 業務用語の意味を決める設計、データの並べ方、関係の記録、関連文書検索が担う役割の違い
- Context Ontology AcceleratorのScan・Model・ServeとAWSサービスの関係
- 1つの業務上の問いから導入を始め、承認・権限・費用・保守の責任を決める方法
AWSのオントロジーは、ばらばらの情報に業務上のつながりを与える
オントロジーは、異なる名前のデータへ共通の業務上の意味・関係・ルールを与える設計です。AWSのContext Ontology Acceleratorは、その関係を調べ、モデル化し、AIへ渡す公開実装です。通常のRAGとの違いとScan・Model・Serveの流れをたどると、導入前に人が決める承認、権限、保守の責任を分けられます。
この記事では、「通常のRAGではなくオントロジーを加える条件は何か」という問いに焦点を当て、公開情報から確認できる役割、作業の流れ、導入時の判断材料を扱います。
最後まで読むと、「通常のRAGではなくオントロジーを加える条件は何か」という問いを、自分の状況に照らして判断するための材料を持ち帰れます。
Context Ontology AcceleratorとAWS Contextは提供形態が異なる
AWSが現在公開しているのは、企業データの意味と関係をAIへ提供する、誰でも内容を確認・利用できるContext Ontology Acceleratorです。自社で設置・運用するこの公開版と、将来AWSが運用を担う予定のAWS Contextは分けて理解する必要があります。
Context Ontology Acceleratorは利用可能なオープンソース実装である
AWSは2026年7月31日、Context Ontology AcceleratorをApache License 2.0で公開しました。AWSはオントロジーを、製品、顧客、ポリシー、業務ルールなどを機械が読める形で表した企業モデルと説明しています。[1]
Acceleratorは、表の形に整理されたデータと、文書のように形が一定でないデータへ接続し、AIが意味と関係の初稿を作ります。ただし、生成された内容をそのまま正式な知識にはしません。業務分野の担当者が確認、編集、承認し、承認後の内容を「どの対象が何と関係するか」をたどれる形で保存します。公開版は複数製品で扱える共通規格で表現し、AIが外部のツールやデータへ接続する共通窓口であるMCPから利用できます。[1]
初期リリースの主な構成は次の3サービスです。[1]
- Amazon Neptune：顧客や契約などの対象と、その関係を保存する場所
- Amazon OpenSearch Serverless：質問と意味が近い情報を探す場所
- Amazon Bedrock：意味や関係の候補作成と検索支援に使うAIサービス
これはAWSが運用を引き受ける完成済みサービスではなく、自社のAWSアカウントへ展開するAcceleratorです。データ接続、アクセス制御、モデル設定、監視、費用管理は導入側の設計範囲に含まれます。
AWS Contextは今後のマネージド機能として位置づけられている
AWSは2026年6月、既存データの関係をナレッジグラフへ自動的にマッピングし、AIエージェントへ管理されたデータ関係、ビジネスルール、ドメイン知識を提供する新サービスとしてAWS Contextを発表しました。この発表では、今後提供するサービスと位置づけています。[2]
7月31日の発表では、Acceleratorのユーザー定義オントロジー機能が、将来AWS Contextのネイティブなマネージド機能になる予定だと説明されています。Acceleratorで作成したオントロジーをAWS Contextで利用、管理できる計画も示されました。[1]
導入計画では、現在使える公開実装と将来のマネージド機能を次のように分けます。
| 区分 | 現在の位置づけ | 導入側の責任 |
|---|---|---|
| Context Ontology Accelerator | 誰でも利用・改変でき、自社で設置する公開版 | AWS環境への設置、更新、監視、費用、業務用語と関係の保守 |
| AWS Context | 今後AWSが運用を担って提供する予定のサービス | 正式な提供範囲、料金、移行条件を公開後に確認 |
オントロジー・スキーマ・ナレッジグラフ・RAGは役割が異なる
オントロジーとは、データの保存場所ではなく、現実の業務にある概念、関係、ルールの意味を定義する設計です。データベースの構造や検索方式とは役割が異なります。
| 要素 | 定義するもの | 例 |
|---|---|---|
| データベース | 実際のデータの保存場所 | 顧客テーブル、契約テーブル |
| データの設計図（スキーマ） | 表、項目、文字か数字かといったデータの並べ方 | account_idは文字列 |
| 業務上の意味の設計（オントロジー） | 顧客や契約などの意味、関係、制約、ルール | 顧客は契約を保有する |
| 関係をたどれる記録（ナレッジグラフ） | 定義に沿って接続した実際の対象と関係 | A社 → 保有する → 契約123 |
| 関連文書検索（RAG） | 質問に関係する情報を検索し、AIの回答材料として渡す処理 | 規程文書を検索して回答する |
たとえば、営業システムのAccountと基幹システムのCustomerが同じ「顧客」を指していても、名前だけではAIエージェントは判断できません。オントロジーに共通概念と対応関係を置くことで、システムごとの名称を業務上の意味へ変換できます。
オントロジーが「顧客は契約を保有できる」という定義なら、ナレッジグラフは「A社が契約123を保有している」という事実を保持します。この区別が曖昧だと、AIが提案した関係と、組織が承認した関係を同じ信頼度で扱う問題が生じます。
既存データを「見つける・確かめる・渡す」の流れ
Context Ontology Acceleratorの公式リポジトリは、全体をScan、Model、Serveの3段階で説明しています。[4]
Scanで既存データから候補を見つける
Scanは、接続したデータの並び方を確認し、名前や説明などの基本情報を補い、形式が一定でない文書も取り込みます。AWSの技術記事では、理想の全体像から細部へ進む方法だけでなく、既存データの構造や値から関係候補を見つけ、全体像を組み立てる方法も説明されています。[3]
ボトムアップ方式の利点は、実在するデータから設計を始められることです。一方、似たカラム名や値が同じ業務概念を表すとは限りません。自動抽出は完成形ではなく、レビュー対象を作る工程と位置づける必要があります。
Modelで意味とルールを承認可能な形にする
Modelでは、AIが業務上の対象、同じ意味の言葉、関係、測定項目などを提案し、その業務に詳しい担当者が確認します。公開版は、意味と関係の候補作成・管理、測定項目の定義、複数データを意味で結んだ関係図の構築をこの段階に置いています。[4]
LLMの生成品質だけでなく、誰が何を承認したかも追跡します。概念の所有者、根拠データ、信頼度、承認状態、廃止状態を記録すれば、後から誤った関係を修正できます。
Serveで質問に必要な文脈だけを渡す
Serveは、複数の関係データをまとめて検索し、関係をたどり、質問に必要な情報だけをMCP経由でAIへ渡します。[4] 利用者の質問に意味が近い対象を探し、そこから明示された関係をたどる構成が可能です。
AIエージェントへ全データを渡すのではなく、質問に関係する概念、関係、ルール、根拠へ範囲を絞れます。これにより、回答の根拠となった経路を記録しやすくなります。
通常のRAGとは検索対象と答え方が異なる
通常のベクトルRAGは、質問と意味が近い文章を探す用途に適しています。オントロジーとグラフ検索は、複数の実体間にある明示的な関係やルールをたどる用途に適しています。両者は置き換えではなく、組み合わせる対象です。
AWSは、ベクトル検索を「意味が近い情報の発見」、グラフ検索を「情報の接続関係の探索」と整理しています。GraphRAG（グラフを検索対象に含めるRAG）では、ベクトル検索とグラフ探索を組み合わせてLLMへ文脈を渡します。[5]
| 質問・要件 | ベクトルRAGを優先 | オントロジーとグラフを検討 |
|---|---|---|
| 規程やマニュアルを要約したい | 適している | 必須ではない |
| 類似する文書を探したい | 適している | 補助的に使える |
| 顧客と契約、製品、障害の関係をたどりたい | 文書だけでは不足しやすい | 適している |
| システムごとの業務用語を統一したい | 検索辞書だけでは管理しにくい | 適している |
| ビジネスルールに照らして候補を絞りたい | ルールを別に実装する必要がある | オントロジーへ明示できる |
| 複数のAIエージェントで同じ意味定義を共有したい | RAGごとに分散しやすい | 共通層として検討できる |
文書の要約だけが目的なら、先に通常のRAGを評価する方が構成を小さくできます。複数システムを横断し、関係をたどる質問が中心なら、オントロジーを加える理由が明確になります。
研修対象を探す例で、関係のたどり方を見る
ここからは公式の導入事例ではなく、本記事で作成した仮想例です。研修、AIツール申請、ユースケース、リスク、成果が別々のシステムにある組織を想定します。
これはプログラムの命令ではなく、オントロジーで業務概念同士のつながりを定義した一覧です。次の表は、「誰が・何が」「どのような関係で」「何とつながるか」を左から順に示しています。たとえば1行目は、「従業員は部署に所属する」と読みます。括弧内はシステム上の概念名と関係名です。
| 誰が・何が（起点） | どのような関係か | 何とつながるか（対象） |
|---|---|---|
従業員（Employee） | 所属する（belongsTo） | 部署（Department） |
従業員（Employee） | 受講した（attended） | 研修（Training） |
従業員（Employee） | 作成した（created） | AIユースケース（AIUseCase） |
AIユースケース（AIUseCase） | 利用する（uses） | AIツール（AITool） |
AIツール（AITool） | 適用ポリシーがある（governedBy） | ポリシー（Policy） |
AIユースケース（AIUseCase） | リスクに分類される（hasRisk） | リスク分類（RiskCategory） |
AIユースケース（AIUseCase） | 生み出す（creates） | 業務価値（BusinessValue） |
この構造があると、次のような問いを関係の経路へ分解できます。
生成AI研修の受講者はいるが、ユースケースをまだ登録していない部署はどこか。
Training
→ 受講したEmployee
→ 所属するDepartment
→ AIUseCaseを作成したEmployee
→ 部署ごとの差分を確認ベクトルRAGでも関連文書は探せますが、「受講」「所属」「作成」の関係を正確に比較するには、識別子と関係の定義が必要です。オントロジーを使う価値は、回答文を長くすることではなく、この比較条件を再利用可能な業務知識として管理できる点にあります。
企業導入は具体的な業務質問から始める
本記事での私の提案は、全社オントロジーを最初から作るのではなく、関係検索が必要な1つの業務質問から始める方法です。次の順序なら、技術検証とガバナンス設計を同じ範囲で確認できます。
- 代表質問を決める：文書検索では答えにくく、関係をたどる必要がある問いを選ぶ
- 主要概念と関係を絞る：質問へ必要な顧客、契約、部署、申請などだけを定義する
- 根拠データを対応づける：各概念と関係が、どのシステムのどの項目に基づくか記録する
- 承認状態を設計する：AIの提案、レビュー中、承認済み、廃止済みを分ける
- 評価質問を用意する：正答だけでなく、根拠経路、権限、更新後の再現性を確認する
- 有効な範囲だけ広げる：評価で価値を確認できた概念とデータソースを追加する
成功条件には回答精度だけでなく、誤った関係を検出できるか、元データの権限を引き継げるか、回答根拠を人が確認できるかを含めます。オントロジーの品質は、概念数の多さよりも、承認済みの関係を継続的に保守できるかで判断する方が実務的です。
導入前にガバナンスと運用負荷を確認する
Context Ontology Acceleratorの導入判断では、検索精度の期待だけでなく、誤った関係、推論による情報露出、セルフホスト運用を評価する必要があります。
AIが提案した関係を正式な知識と分ける
customer_id、account_id、user_idは似ていますが、同じ個人や法人を示すとは限りません。AIが提案した関係には、根拠、信頼度、レビュー担当者、有効期限を持たせます。承認前の候補を本番エージェントが参照しない状態分離も必要です。
元データだけでなく関係経路を認可する
元システムで個別に閲覧できる情報でも、複数の関係を結ぶと新しい情報を推測できる場合があります。たとえば、案件、担当者、所属、異動情報を連結すると、元の画面にはない組織情報が導かれる可能性があります。
そのため、行や列の権限だけでなく、名前空間、概念、関係、質問結果の単位でアクセス制御を検討します。公式リポジトリも、名前空間による分離と役割ベースのアクセス制御を設計に含めています。[4]
セルフホストの費用と保守担当を決める
Acceleratorは、Neptune、OpenSearch Serverless、Bedrockに加え、データ取り込み、認証、実行環境などを組み合わせる構成です。クラウド利用料だけでなく、次の運用担当を決める必要があります。
- データソースとスキーマ変更の追跡
- オントロジーのレビューと版管理
- モデル出力と検索品質の評価
- 権限、監査ログ、インシデント対応
- AWS Context提供後の移行可否の再評価
通常のRAGで要件を満たせる場合、この運用負荷を追加する必要はありません。複雑な関係検索と共通の業務定義が継続的に必要な場合に、投資対象として比較します。
Palantir Ontologyとは公開範囲を分けて比較する
AWSの取り組みを「AWS版Palantir Ontology」と呼ぶと、現時点の公開範囲を広く見積もる可能性があります。PalantirはFoundry Ontologyを組織のオペレーショナルレイヤーと位置づけ、オブジェクト、プロパティ、リンクに加え、アクション、関数、動的なセキュリティを含むと説明しています。[6]
一方、Context Ontology Acceleratorは、現在は自社環境へ展開するセマンティックコンテキスト層であり、Scan、Model、ServeとMCP経由のエージェント利用が公開の中心です。将来のAWS Contextがどこまで業務アクションと運用機能を含むかは、正式なサービス仕様を確認して判断する必要があります。
比較するときは、製品名の対応ではなく、次の要件をPoC（Proof of Concept：限定範囲で実現性を確認する検証）で確認します。
- 意味と関係を管理したいのか、業務更新まで同じ基盤で実行したいのか
- 既存のAWSデータ基盤と権限設計をどこまで再利用できるか
- オントロジーの変更を誰が承認し、どのアプリへ反映するか
- ベンダー管理と自社運用のどちらへ責任を置くか
まとめ：オントロジーは文書検索で足りない業務質問から検証する
AWSのオントロジーは、企業データへ業務上の意味、関係、ルールを与え、AIエージェントが必要な文脈を検索できるようにする仕組みです。現在利用できるContext Ontology Acceleratorと、今後のマネージドサービスであるAWS Contextは分けて計画します。
- AcceleratorはApache 2.0で公開され、自社AWS環境へ展開する
- Neptuneで関係、OpenSearch Serverlessで意味検索、BedrockでAI処理を支える
- AIの提案をドメイン専門家がレビューし、承認済み知識として管理する
- 通常のRAGは文章検索、オントロジーとグラフは明示的な関係やルールの探索に向く
- 導入前に、関係の承認、推論結果の権限、運用担当、費用を決める
最初の確認項目は、「自社の質問が文書検索で答えられるか、それとも複数システムの関係をたどる必要があるか」です。後者が継続的に発生する業務を1つ選び、少数の概念と評価質問から検証すると、オントロジーを追加する価値を判断しやすくなります。
本記事は一般的な情報整理であり、法的助言ではありません。実務判断は専門家に確認してください。
参考文献
- Amazon Web Services, Amazon Web Services now introduces Context Ontology Accelerator, 2026年7月31日
- Amazon Web Services, Context intelligence for your data and AI agents at scale, 2026年6月17日
- Amazon Web Services, Build a semantic ontology to power AI assistants on AWS – Part 1, 2026年7月14日
- Amazon Web Services, Context Ontology Accelerator, 2026年
- Amazon Web Services, Improving generative AI accuracy with vector and graph search hybrid queries, 2026年5月18日
- Palantir, Ontology architecture
最新のリリースやアップデートの詳細は、公式サイト・公式ドキュメントを確認してください。