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