Context Ontology Accelerator (COA) を使ってみる #1： デプロイと動作確認

1. はじめに

• オントロジーの学習を始めた。
• AWSがOSSとして提供している「Context Ontology Accelerator」 (以下、COA)を使ってみるといいよ、という話を聞いたため、まずはデプロイして使えるようにするところまでを確認する。

2. やったこと

• 作業用サーバ(AL2023/Arm)を作成し、ミドルウェア環境を整備した上で、CDKでCOAをデプロイする。
• デプロイされたCOAで初期設定して、ドキュメントの取り込み(Scan)、オントロジー作成(Ontology)、ドキュメントに対するQ&A(Serve)ができることを確認する。

3. Context Ontology Accelerator (COA) とは（自分の理解）

• オントロジーについて正直全く分かっていないが、、、ベクトルDBを用いたRAGの場合、確率論的な回答生成が行われ、それに伴いハルシネーションも発生しうるが、オントロジー・ナレッジグラフを用いて、決定論的な仕組みを併用することにより、比較的回答精度が高められる仕組み、のようにまずは理解している。

4. 構成図

• kiro でソースコードからMarmaidを作成したもの（だいたいのイメージの把握のため掲載）。

5. 手順

• 公式のREADMEなどを見てトライしたが、結構途中で失敗して変にいじったりしてハマってしまった。最終的に成功した手順をまとめておく。補足メモはNote部分を参照。

Step1: 作業用サーバの作成

• 以下仕様のEC2インスタンスを作成する。

項目	値
AMI	Amazon Linux 2023 (ARM) — 今回はal2023-ami-2023.12.20260817.0-kernel-6.18-arm64
インスタンスタイプ	t4g.xlarge（4 vCPU / 16GB RAM）以上
IAM ロール	AdministratorAccess 相当
ストレージ	50GB 以上
セキュリティグループ	インバウンド: SSH(22)、アウトバウンド: 全許可
ネットワーク	インターネットアクセス要（NAT Gateway 等）

• 今回、Armとx86の両方のコンテナをビルドする必要があるが、Armのもののほうが多いため、サーバのOSもArmを選択している。

Step 2: システムパッケージのインストール

sudo dnf install -y docker git java-17-amazon-corretto-devel unzip libatomic make

Step 3: Docker の起動と設定

sudo systemctl start docker && sudo systemctl enable docker
sudo usermod -aG docker ec2-user
exit

• 設定反映のためsshをいったん抜けて再接続する。

Step 4: QEMU のセットアップ（最重要）

• x86_64 コンテナを Arm 上でビルドするために全アーキテクチャのエミュレーションを有効化する。

docker run --rm --privileged --platform linux/arm64 tonistiigi/binfmt --install all

• --install amd64 だと動作しなかったため、--install all とした。
• この設定はDocker 再起動後も有効だが、EC2 の再起動（reboot / stop→start）後は再実行が必要。

動作確認

docker run --rm --platform linux/amd64 public.ecr.aws/docker/library/python:3.12-slim python --version
# → Python 3.12.x と表示されれば成功

Step 5: Node.js 22 + pnpm

curl -fsSL https://rpm.nodesource.com/setup_22.x | sudo bash -
sudo dnf install -y nodejs
sudo npm install -g pnpm

Step 6: uv（Python パッケージマネージャー）

curl -LsSf https://astral.sh/uv/install.sh | sh
source ~/.bashrc

Step 7: AWS リージョン設定

echo 'export AWS_DEFAULT_REGION=us-west-2' >> ~/.bashrc
echo 'export CDK_DEFAULT_REGION=us-west-2' >> ~/.bashrc
source ~/.bashrc

• us-east-1が公式検証済リージョンのようだが、たまたま今回はus-west-2を選択したが、特に問題なくデプロイできた。

Step 8: ここまででいったん確認

[ec2-user@ip-10-0-5-64 ~]$ node --version
v22.23.2
[ec2-user@ip-10-0-5-64 ~]$ pnpm --version
11.23.0
[ec2-user@ip-10-0-5-64 ~]$ uv --version
uv 0.12.5 (aarch64-unknown-linux-gnu)
[ec2-user@ip-10-0-5-64 ~]$ java -version
openjdk version "17.0.20" 2026-07-21 LTS
OpenJDK Runtime Environment Corretto-17.0.20.8.1 (build 17.0.20+8-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.20.8.1 (build 17.0.20+8-LTS, mixed mode, sharing)

Step 9: COAリポジトリクローン

cd ~
git clone --branch v0.2.0 https://github.com/aws/context-ontology-accelerator.git
cd context-ontology-accelerator

• 今回は2026/8時点で最新の v0.2.0 を使用している。定期的に更新されている様子。

Step 10: make setup（デプロイの準備）

make setup

• ここが一番何をしているのかが難しいが、「SmithyというAWS製のAPI仕様定義を元に、GradleでOpenAPI仕様（API Gateway用）を作成し、Python（バックエンド用）とTypeScript（フロントエンド用）を作成している」といったん理解しておく。
• このプロセスに数十分必要（Gradleなどのダウンロードのため）。

Step 11: COAのデプロイ

• SCL_SMUS_ADMIN_ARNS に EC2 のIAMロール ARN を指定して make deploy-dev を実行する（DataZone のデプロイ用にこのように指定する必要あり）。

SCL_SMUS_ADMIN_ARNS=arn:aws:iam::<ACCOUNT_ID>:role/<EC2_ROLE_NAME> make deploy-dev

• ここではTypeScriptのビルド、CDK synth/deploy(CloudFormation 16個のデプロイ)、それに伴うNeptune、OpenSearch、AgentCoreなどのリソース作成、コンテナイメージビルド（ECS/Lambdaに展開）が行われる。
• x86のコンテナをQEMUでビルドするのに時間がかかり、CDK deploy全体の所要時間が4時間30分程度。
• 以下のようなコンテナをビルドしている。

名前	x86/arm	デプロイ先	用途
ContextManagerImage	arm64	ECS Fargate + AgentCore（coa-dev-serve）	クエリのオーケストレーション（Serve層の中核）
VKG OntopContainer	arm64	ECS Fargate（coa-dev-vkg）	仮想ナレッジグラフ（Ontop によるSPARQL⇔SQL変換）
DbEnrichmentContainer	arm64	ECS Fargate（coa-dev-sources）	DBスキャン時のメタデータ強化（Bedrock 呼び出し）
SourcesKgBuildContainer	x86_64	ECS Fargate（coa-dev-sources）	ドキュメントからのナレッジグラフ構築
SourcesPreProcessingFn	x86_64	Lambda（coa-dev-sources）	ドキュメント前処理（PDF解析・PyTorch使用）
OntologyEngineContainer	x86_64	ECS Fargate（coa-dev-ontology）	オントロジー帰納・推論（HermiT/ELK, Java）
MCP Server	arm64	AgentCore Runtime（coa-dev-mcp）	AIエージェント向け MCP ツール提供

6. とりあえず使ってみる

6.1 初期設定

• Webアクセスの入口であるCloudFrontにアクセスしてみると、ログイン画面が表示される。ここにログインできるように、Cognitoでユーザを作成する。

• デプロイ直後のユーザープールには、ダミーのユーザしか存在しないため、自分用のユーザを追加作成する。

• ユーザを作成したら、ユーザプールのグループ「Admin」（デプロイ時に自動作成済）に、「Add user to Group」でユーザを追加する。

• CloudFrontのログイン画面に作成したユーザでログインし、パスワードを変更すると、ついに管理画面が見れる。（AWSマネコンっぽい画面だがAWSマネコンではない）

• Namespace （論理的に作業領域を分割する仕組み）を作成する。

6.2 ソースの登録

• Namespace を作成し、該当のNamespaceを選択した状態で、Source（扱いたいデータソース）を登録する。今回は5つのテキストファイルを画面からのアップロードで投入する。

• 5つのテキストファイルの内容は以下。以前、GraphRAGの検証 「Bedrock Knowledge Base (S3 Vectors vs Neptune Analytics) の比較」の際に使用したデータをそのまま流用。

doc_01_billing_service.txt

Internal Service Architecture: Billing Application
The company's core Customer Billing Service (Service-ID: BILL-PROD) is designed as a microservice to handle all subscription renewals. To process payments and retrieve ledger data in real-time, this Billing Application establishes a persistent, high-throughput connection to the primary transaction database engine, known in our inventory as "DB-Alpha-9".

doc_02_database_hosting.txt

Database Infrastructure Inventory
The transaction database "DB-Alpha-9" is configured with a high-availability active-passive clustering setup. The primary active node of DB-Alpha-9 is hosted on and powered by the physical hardware server labeled "Rack-Host-Mercury" located in our Oregon Data Center (Zone-A).

doc_03_hardware_rack.txt

Data Center Hardware Layout
The physical server "Rack-Host-Mercury" is mounted in Rack 12 of Zone-A. Power delivery to Rack-Host-Mercury is managed by the Intelligent Power Distribution Unit (PDU) identified as "PDU-West-03". Additionally, all network traffic for this server passes through the primary top-of-rack network switch "Switch-Nexus-X".

doc_04_maintenance_schedule.txt

Urgent Infrastructure Maintenance Bulletin
This weekend, the network operations team will perform an urgent hardware replacement. Due to recurring port failures, the top-of-rack network switch "Switch-Nexus-X" will be shut down and replaced with a newer model. This operation is scheduled for Sunday, June 14, at 02:00 AM UTC and will result in a temporary network blackout for all connected hardware under Switch-Nexus-X.

doc_05_unrelated_pdu_info.txt

Facility Power Grid Upgrades
The backup power distribution unit "PDU-West-04" is undergoing routine load testing. Please note that "PDU-West-03" (which powers adjacent server racks) is running at normal capacity and is not scheduled for any maintenance this month.

• 文書リスト内の主要な関係性として以下のようになる。

  • BILL-PRODというサービスはDB-Alpha-9というデータベースに依存。
  • DB-Alpha-9というデータベースは、Rack-Host-Mercuryに収容。
  • Rack-Host-Mercuryは、Oregon Data Center Zone-Aに収容。
  • Rack-Host-Mercuryは、PDU-West-03に依存。
  • Rack-Host-Mercuryは、Switch-Nexus-Xに依存。
  • Switch-Nexus-Xは、June 14にメンテナンス。
  • PDU-West-03は通常稼働。
  • PDU-West-04は負荷試験中。

• 主要なキーワードがどのファイルにあるかは下表のようになる。

• 「June 14 のメンテナンスにより影響を受けるサービスは何ですか？」のような質問に、文書間の関係を理解して、「Maintenance」⇒「Switch-Nexus-X」⇒「Rack-Host-Mercury」⇒「DB-Alpha-9」⇒「BILL-PROD」と関係を辿っていき、結論として「BILL-PRODです」と回答できることを期待する。

6.3 Induction （オントロジーの作成）

• Ontology -> Start induction を選択する。

• Strategyは「Unstructured(Lexical Graph)」、Data sources は前項で作成したものを選択し、「Start induction」する。

• Proposal が生成されるので、「Accept Proposal」する。

• Induced されたことを確認する。

6.4 Serve（利用）

• Serve - Playground から、読み込んだソースに対する問い合わせを行う。5つのソースドキュメントを使用し、正確に回答することができた。

• 動作トレースを見ると、Tier1/2(SPARQL/SQLなどの使用、決定論的なところ)はスキップされ、Tier3(確率論的な検索)のみが使用されており、それがベクトル検索のみなのか、グラフ探索が使用されているのかなどが分からなかった。

7. 所感

• とりあえず今回環境構築はできるようになったので、次回は以下にチャレンジしたい。
  • v0.2.2をデプロイ（日本語対応が進んだようなため）
  • Tier1/Tier2を使うような、構造化データに対する検索

8. 参考