AWS Context Ontology Accelerator (COA) を検証してみた📖

AWS が 2026 年 7 月 31 日に公開した OSS「Context Ontology Accelerator（以下 COA）」を東京リージョンの検証環境に構築し、医療機関向け予約サービスの DB スキーマと仕様書を読ませて検証しました。DB スキーマと仕様書から業務オントロジーを下書きさせ、それを Claude Code から MCP 経由で参照しながら実装するところまでは動きました。導入にあたっては、Amazon Neptune の稼働費用と、生成されたオントロジーを人がレビューする工数を見込んでおく必要があります。この記事では COA の仕組みと、検証で分かった向く用途と前提条件をまとめます。

---

AI が業務判断を誤る理由とオントロジー

COA の話に入る前に、なぜオントロジーが要るのかを検証に使った予約サービスの例で説明します。オントロジーそのものの解説は オントロジーとは？AI時代にデータの意味を揃える設計図 にまとまっているので、ここでは要点だけ書きます。

検証に使った医療機関向けシステムには患者の予約サービスがあり、「予約」のほかに「予約ブロック」（診療を割り当てない枠）という業務上の概念があります。テーブル定義だけを渡した AI に「今月の予約数を出して」と頼むと、appointments と appointment_slots のどちらを見るべきか、キャンセルや予約ブロックを含めるのかが分かりません。数字は出ますが、それが正しいかを誰も言えない状態になります。

AI が誤るのはモデルが賢くないからではなく、会社の言葉と規則を知らないからです。 「予約」が概念として定義され、「予約ブロックは含まない」と決まっていれば、同じ問いには常に同じ答えと根拠が返ります。

用語辞書は「予約枠 = 診療を割り当てる単位」という定義はあるが、概念同士がつながっていません。スキーマは appointment_slots (id, capacity, ...) という構造はあるが、意味がありません。オントロジーは「予約枠は外来枠パターンから導出される」「予約枠と予約ブロックは別物」「予約確定は通知を起動する」のように、点（概念）と線（関係）の両方を持ちます。

線があると辿れます。「保護者が代理同意した患者の、次回予約はいつか」という問いは、保護者 → 同意 → 患者 → 予約 → 予約枠と関係を 4 つ辿れば答えに届きます。線がなければ人が JOIN の経路を推測し、「これを変えたら何が壊れるか」の調査が毎回手作業になります。

この「線をデータとして持つ」のが得意なのがグラフ DB です。RDB で保護者 → 患者 → 予約を引くには JOIN を 3 回書き、段数が可変だと書けません。グラフ DB は関係そのものがデータなので段数が可変でも辿れます。ただし集計は RDB のほうが得意で、実データは RDB に残ります。グラフが持つのは「意味の地図」だけです。COA が Amazon Neptune を中核に置いているのはこの理由からです。

Context Ontology Accelerator とは

COA は、社内データから業務オントロジーを AI に下書きさせ、人が承認し、できた知識グラフを MCP 経由で AI エージェントに渡す、までを一式そろえた AWS 公式の OSS スターターキットです。AWS の発表（2026 年 7 月 31 日）と GitHub リポジトリで公開されています。

名称について補足します。AWS の発表文と README では常に「Context Ontology Accelerator」とフルネームで書かれていますが、公式ドキュメントの認証設定や Cedar ポリシーの章、CloudWatch のメトリクス名前空間（COA/Guardrails）では「COA」という略称が使われています。この記事でも COA と書きます。「Contextual Ontology Accelerator」と表記されることがありますが、正式名は「Context」です。

Scan → Model → Serve の 3 工程

COA の処理は Scan（集める）、Model（意味づける）、Serve（提供する）の 3 工程に分かれます。人が判断するゲートが 2 つあり、ここは自動化されません。

Scan では、JDBC や AWS Glue 経由で DB スキーマを読み、PDF や HTML などの文書を取り込みます。Model では、Bedrock 上の Claude がクラスと関係の候補を下書き（induction）し、既存のオントロジー（FIBO などの基礎オントロジーや、その名前空間で以前に受理された誘導結果）に接続（grounding）します。grounding の既定モード ENHANCED は LLM が同名別義（Dublin Core の Policy と保険の policy など）を弾いてくれます。下書きは proposal として出てきて、人が Validate して Accept するまでオントロジーとして有効になりません。 Serve では、受理済みのオントロジーを Web UI、REST API、MCP の 3 つの窓口から使えます。

COA が短縮してくれる 3 つの工程

オントロジーの内容の正しさは短縮の対象外です。AWS 自身が発表文で「ドメイン専門家がすべての要素をレビュー、編集、承認する」と明記しているとおり、人のレビューを組み込む前提で設計されています。

問いへの回答は Tier 1 → 2 → 3 の 3 段階

Serve の中核である自然言語の問い合わせは、公式ドキュメントの Serve の章にあるとおり 3 段階で解決されます。上の段階で答えられなければ下へ降りていきます。

利用の窓口は 5 つ、MCP は読み取り専用

MCP は公式の Agent Access Guideにあるとおり、エージェント専用の資格情報を持たず、常にユーザーの代理として動きます。ツールは次の 6 つです。

検証した構成

検証用の AWS アカウントの東京リージョン（ap-northeast-1）に、COA が新規作成する専用 VPC でデプロイしました。

役割が重なっているサービスはありません。Bedrock が意図を読んで回答を書き、OpenSearch Serverless が言葉から意味の近い概念を探し、Neptune が概念の線を辿り、VKG（Ontop）が SPARQL を SQL に変換して実データを引きます。CDK はこれらと周辺のリソースを 16 スタックで一括構築します。

実データの DB には個人情報が入っているため接続したくありませんでした。そこで、スキーマだけを複製した RDS を別に立てて COA に読ませています。個人情報を含む DB にオントロジーを引かせるときは、まずスキーマ複製で試すのが安全です。 検証後は日額課金を止めるために環境を撤去したので、この記事に画面のスクリーンショットはありません。

検証で確認できたこと

公式ドキュメントは東京リージョンでの動作を明示していません（既定のモデル ID が米国のクロスリージョン推論プロファイルで、非米国リージョンからは呼べないという注記があります）。それでも 1 行の修正で 6 ツールすべてが応答しました。

いちばんの収穫は Claude Code から MCP で使えたこと

今回いちばんやりたかったのは、開発リポジトリの Claude Code からオントロジーを参照させながら実装させることでした。これは動きました。

• 6 ツールすべてが応答し、Claude Code から直接呼べました
• PKCE 認証のトークンは 24 時間有効で、30 日はリフレッシュで継続するため再認証は不要でした
• --scope user で登録すれば、どのリポジトリからでも同じオントロジーを引けます

オントロジーを参照物として AI エージェントに実装させられるので、用語と関係を実装側でそろえられます。AWS Knowledge MCP でクラウド設計の正確さを上げる話は AWS Knowledge MCP・IaC MCPで実現する、AIDDのAWS設計・構築フロー にありますが、COA はそれを自社の業務知識に対して行う位置づけです。

導入前に見込んでおくこと

費用は稼働日数で管理する

Neptune は日額 $25〜31 かかります。公式ドキュメント（2026 年 9 月 4 日参照）によると、Neptune は db.r8g.large のプロビジョンドインスタンス 1 台で動く構成で、v0.1 時点の CDK コンテキストにはインスタンスサイズを変える項目がありません。そのため、費用は稼働日数で管理することになります。OpenSearch Serverless は aoss_min_ocu=0 で固定費をゼロにできます。

撤去にかかる時間も見込んでおきます。今回は AgentCore Runtime の ENI 解放待ちで撤去の完了に時間がかかり、その間も Neptune の課金は続きました。公式ドキュメントも「テストしていないときはスタックを destroy する」運用を勧めているので、検証の終了日は撤去の時間を含めて計画すると費用の見積がぶれません。

内容の正しさは人が確認する

induction が出すのは proposal であり、人が Accept するまで有効になりません。ここは自動化の対象外です。同名別義の検出は grounding が自動でやってくれますが、「予約ブロックを予約数に含めない」のような業務ルールの正誤は、業務を知る人が判断します。

運用に乗せるには、業務ルールの正誤を判定できる担当を置くことが前提になります。業務が大きいシステムほど生成されるクラスと関係も増えるので、レビューと承認の工数を最初から計画に組み込みます。

リポジトリ内で参照するだけなら別の選択肢もある

今回やりたかったのは、リポジトリ内のソースに対してオントロジーを参照させながら実装させることでした。この用途なら、オントロジーをリポジトリ内に置いておけば AWS リソースなしでも Claude Code は参照して実装してくれます。gaipack ではその方式を gaipack セマンティック APM プラグイン として試作しています。COA の強みが出るのは、実データに自然言語で問い合わせる窓口や、権限と監査つきで AI に社内データを触らせる要件があるときです。

向く用途と前提条件

導入を検討するときは、順に問いを立てると判断しやすいです。

1. 自然言語で「数字」を聞く窓口が業務上必要か。 必要なければ COA の中核機能（Tier 1、Tier 2）は使われないため、別の手段も含めて検討します
2. 内容をレビューして承認できる担当を置けるか。 置けない場合、下書きは出ても有効化できません
3. 一度の棚卸しか、継続的な運用か。 一度の棚卸しなら 1 回 $50〜100 程度で費用対効果が見込めます。継続運用なら日額の費用が続きます

まとめ

COA の価値が出るのは「実データに自然言語で問い、権限と監査つきで数字を返す窓口」です。その窓口が業務上必要かどうかが導入判断の分かれ目になります。

用語や KPI の定義を人と AI が同じ場所で参照できるようにする取り組みは、gaipack でも gaipack BI のセマンティックレイヤー構築として支援しています。業務データに AI を接続したいが、どこから手を付けるべきか迷っている方は、お気軽に KDDIアイレットへお問い合わせください！