AI2026-11-11約15分で読めます

NVIDIA Auto Ontology とは

社内DBからAIエージェント用の意味グラフを自動生成するOSSの使い方

NVIDIA Auto Ontologyは社内DBのメタデータから意味グラフを自動生成し、人が認証してAIエージェントが参照するApache-2.0のOSS。MCP・REST対応、docker compose起動、GraphRAG・dbtとの違いやデータ送信範囲の注意まで整理した2026年11月版。

NVIDIA AIエージェント MCP RAG オープンソース Nemotron 構造化データ

NVIDIA Auto Ontology は、社内データベースのメタデータから「ビジネス用語とテーブル・列の対応表（意味のグラフ層）」を自動で作り、人が確認・認証（certify）したうえで、AIエージェントがその層を通じて質問に答えるようにする Apache-2.0 の Python フレームワークである。NVIDIA は2026年10月21日に発表した「Agent Knowledge Foundation」の一部としてこれを紹介しており、GitHub の NVIDIA/auto-ontology で公開されている。

エージェントとのつなぎ口は MCP サーバー、REST API（POST /api/chat/completions）などで、docker compose で一式を起動して Web UI（localhost:3000）から試せる。本稿は GitHub の README と docs、NVIDIA の公式ブログ・開発者ページを一次情報として、仕組み・使い方・既存手法との違い・導入時の注意を整理する（2026年11月時点）。確認できなかった事項は末尾に分けて記す。

セマンティックレイヤーとオントロジーとは — 一言で

- セマンティックレイヤー: 「売上」「顧客」といった業務の言葉と、データベースの実際のテーブル・列・計算式を結びつける翻訳表。AI に生のテーブルを読ませる代わりに、この表を先に読ませる
- オントロジー: 業務上の概念（顧客・商品・注文など）と、その関係（顧客は注文を出す、など）を整理した構造。Auto Ontology ではグラフとして保持する
- 認証（certify）: 自動生成された定義を、業務を知る人が確認して「正」と認める手順

3行でわかる要点

- 何か: メタデータから意味のグラフ層を自動生成し、エージェントが自然言語の質問を SQL に変換して答えるときに、その層で定義の整合を確かめる OSS（Apache-2.0）
- 使い方: docker compose で起動し、Web UI・MCP・REST API から利用する。NVIDIA API キー（build.nvidia.com で取得）が必要
- 注意点: 既定ではモデル推論が NVIDIA の API カタログに送られる。自己ホストの NIM などへの切り替えも設定上は可能。認証の運用は人手が前提

なぜ必要か — 生のテーブルを LLM に渡すと起きること

LLM に社内データベースのスキーマをそのまま渡して SQL を書かせる方式（Text-to-SQL）は、手軽な反面、列名やテーブル名だけでは業務上の意味が分からない。たとえば amount が税込か税抜か、status = 3 が出荷済みか、複数の売上テーブルのどれが正か、といった点を推測で埋めることになり、文法的には正しいが意味の違う SQL を返すことがある。しかも誤りが実行エラーにならないため、数字だけがもっともらしく出てしまう。

Auto Ontology はこの問題に対して、先に業務用語・指標・関係を定義した層を作り、SQL の生成と検証をその層に紐づける。README は、その働きを「発見（Discover）」「接地（Ground）」「検証（Validate）」「公開（Expose）」の4つで説明している。

仕組み — メタデータから回答までの流れ

- Discover: 接続したデータベースのメタデータからオントロジーを見つけ、ナレッジグラフを作る
- Ground: 指標・エンティティ・関係を業務上の意味に結びつけ、食い違う定義を整理する
- Validate: 生成されたクエリを、認証済みの定義と系統（lineage）に照らして検証し、回答に根拠（provenance）を添える
- Expose: 作った文脈を MCP・CLI・API で公開し、認証済みの修正をオントロジーに反映する

NVIDIA の開発者ページは、生成物を「出発点となるオントロジー」と位置づけ、業務の専門家がテスト・修正・認証するものと説明している。つまり完全自動ではなく、人の認証を前提にした半自動の設計である。NVIDIA は「オントロジー作成時間を NVIDIA のテストで90%削減した」と述べているが、これは自社計測の値で、条件の詳細は確認できていない。

README によると、処理には役割別の4つのモデルが使われ、それぞれ endpoint・API キー・モデル名を設定できる。

役割	既定のモデル（README）	用途
REASONING	`nvidia/nemotron-3.5-lightning-30b-a3b`	オントロジー構築、SQL 生成、回答可否の判定
NON_REASONING	`nvidia/nemotron-3.5-lightning-30b-a3b`	意図・エンティティ抽出、SQL の検査と修復
EMBED	`nvidia/nemotron-3.5-embed-1b`	pgvector による索引と検索
RERANK	`nvidia/nemotron-3.5-rerank-8b`	橋渡しテーブル候補の順位付け

なお README の別の節（Software Components）には埋め込み・再ランク用に別名のモデルが書かれており、記述が一致していない。実際に使う前に .env.example の値を確認したい。また、埋め込みモデルは取り込みと検索で同じものを使い続ける必要がある、と README は注意している。

対応データソースと必要なもの

README と docs/connections.md によれば、対応するデータベースエンジンは次の10種類である。

接続方法	対応エンジン
Web UI から追加	PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB
環境変数 `CONNECTION_STRINGS` のみ	DuckDB、SQLite

- Docker（Compose v2）と uv
- NVIDIA API キー（nvapi-...、build.nvidia.com で取得）
- バックエンドと取り込みサービスは Python 3.12 以上、フロントエンドは Next.js 16（Better Auth、Prisma）
- 接続元は schema の許可リストや、テーブル名の許可・拒否の正規表現（table_allow_regex / table_deny_regex）で絞れる。拒否ルールが優先される

クイックスタート — Wide World Importers サンプルで動かす

README の手順は、サンプルの Postgres データベース（Wide World Importers）を用意して一式を起動する流れである。以下は README のコマンドのままで、<...> は自分で決める値に置き換える。

git clone https://github.com/NVIDIA/auto-ontology.git && cd auto-ontology
cp .env.example .env

.env には次の値を設定する。.env.example にはモデルの役割ごとに nvapi-your-api-key-here が並んでいるため、それぞれ置き換えるか、行を削除する必要がある。

DEFAULT_MODELS_API_KEY=nvapi-...
AUTH_SECRET=<a long random string, e.g. from openssl rand -base64 32>
APP_URL=http://localhost:3000
POSTGRES_PASSWORD=<a new password>
CONNECTION_STRINGS=postgresql://postgres:<the same password>@postgres:5432/wideworldimporters
AUTO_ONTOLOGY_ADMIN_PASSWORD=<a new password>
PGADMIN_PASSWORD=<a new password>

次に Postgres を起動し、サンプルデータを投入する。

docker compose up -d --wait postgres
git clone https://github.com/NVIDIA/auto-ontology-eval.git ../auto-ontology-eval
(cd ../auto-ontology-eval && uv sync && cp .env.example .env && \
  POSTGRES_PASSWORD='<the same password>' \
  uv run python scripts/seed/seed_wwi.py --database-name wideworldimporters --drop)

最後にスタック全体をビルドして起動する。

docker compose up -d --build

起動後は http://localhost:3000 を開き、AUTO_ONTOLOGY_ADMIN_EMAIL と AUTO_ONTOLOGY_ADMIN_PASSWORD でサインインする。Settings → Semantic Compilation を有効にしてから、Chat 画面で README にあるサンプル質問を試す、という手順である。自己登録はできず、最初のアカウントが管理者になる（docs/authentication.md）。

MCP で Claude Desktop・Cursor から使う

MCP サーバーは Auto Ontology の公開 API を呼ぶ HTTP クライアントとして動き、データベースの認証情報やモデル設定は持たない。権限の確認は API 側で行われ、呼び出しはログインしたユーザーの権限で実行される。既定のポートは 3003 で、エンドポイントは /mcp である。稼働中の環境に対しては、README の次のコマンドで起動できる。

AUTO_ONTOLOGY_API_URL=http://localhost:3000 \
  uvx --from "git+https://github.com/NVIDIA/auto-ontology.git#subdirectory=mcp" auto-ontology-mcp

Cursor では ~/.cursor/mcp.json に次のように書く。

{
  "mcpServers": {
    "auto-ontology": { "url": "http://localhost:3003/mcp" }
  }
}

Claude Desktop は claude_desktop_config.json で、mcp-remote を橋渡しに使う形が README に示されている。

{
  "mcpServers": {
    "auto-ontology": {
      "command": "npx",
      "args": ["mcp-remote", "http://localhost:3003/mcp"]
    }
  }
}

MCP のツールはすべて読み取り専用で、check_readiness、search_terms、get_term、get_term_columns、get_term_sql_attributes、get_sql_attribute、describe_table、check_answerable、ask_question の9つである。docs によれば、生のスキーマを自由に閲覧するツールは意図的に用意されておらず、エージェントは意味層を経由してデータに近づく設計になっている。主力は ask_question で、回答・SQL・行を返すが、多数のモデル呼び出しを行うため数十秒かかることがあり、行数は100件が上限である。MCP 自体の基礎はClaude Code MCP連携ガイド、最新仕様の変更点はMCP 2026-07-28 仕様の解説を参照してほしい。

REST API は、Web UI の「API Tokens」で発行したトークンを使う。応答は server-sent events のストリームで、data: [DONE] で終わる。

curl -N http://localhost:3000/api/chat/completions \
  -H "x-api-key: $AUTO_ONTOLOGY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question": "How many orders shipped last week?"}'

README は「MCP、CLI、API」で公開すると書いているが、独立した CLI コマンドの説明は確認できなかった。

既存手法との違い

似た目的のツールは多いが、役割はかなり違う。下表は各ツールの一般的な位置づけを、Auto Ontology の README の説明と並べたものである。

手法	主な対象	意味の層をどう作るか	人の関与	向く用途
NVIDIA Auto Ontology	構造化データ（SQL データベース）	メタデータから自動生成し、人が認証	認証が前提	社内 DB への自然言語質問を、定義に沿って答えさせる
素の LLM による Text-to-SQL	構造化データ	作らない。スキーマを直接読ませる	なし	小さく単純なスキーマの試作
dbt Semantic Layer	構造化データ（dbt で管理する指標）	人が YAML で指標・ディメンションを定義	定義作成が中心	BI・分析で指標を統一する
Microsoft GraphRAG	文書（非構造化テキスト）	文書から LLM がエンティティ・関係を抽出してグラフ化	少ない	文書群全体の要約・俯瞰的な質問
LightRAG	文書（非構造化テキスト）	文書からグラフを作り、検索に使う軽量な RAG	少ない	文書検索の精度向上を手軽に試す
graphify	コード・ドキュメント・PDF	ファイルからナレッジグラフを作る	少ない	コーディングエージェントに資料を引かせる

要点は対象のデータの違いである。GraphRAG や LightRAG、graphify は文章やコードからグラフを作るもので、「売上の定義」を表の列に結びつけて SQL を検証する用途は想定していない。逆に Auto Ontology は、SQL データベースの業務定義を整えることに集中しており、文書検索は主題ではない。dbt Semantic Layer とは目的が近いが、指標を人が書き起こす点が異なる。なお README によれば、Auto Ontology は Apache Ossie 形式の YAML でモデルをインポート・エクスポートできるため、既存の意味モデルとの行き来も想定されている。文書側の RAG 基盤はWeKnora の解説も参考になる。

Apache Ossie 互換とは

Apache Ossie は、意味モデル（指標・ディメンション・関係）を JSON/YAML で表す中立の仕様で、Open Semantic Interchange（OSI）が2026年7月10日に Apache Incubator に入って改名されたものである（改名時に仕様自体は変わっていない）。Auto Ontology は Ossie のコンバーターを使い、Settings → Import / Export、または POST /api/model/import と POST /api/model/export で入出力できる。ただし、他社ツールが Ossie ファイルをそのまま取り込めるとは限らない。往復で欠落がないかは、自分の環境で試して確かめたい。

導入時の注意 — データの送信範囲・権限・運用負荷

- 推論先: 既定では推論が NVIDIA API カタログ（integrate.api.nvidia.com、ai.api.nvidia.com）に送られ、各提供元とモデルの利用条件に従う。自己ホストの NIM や、他の OpenAI 互換エンドポイントに切り替えることも設定上は可能。何が送られるか（メタデータのみか、行データも含むか）は、利用前にコードと設定で確認すべきで、本稿では特定できていない
- KumoRFM（任意）: KUMO_RFM_API_KEY を設定した場合に限り、予測系の質問のため接続したテーブルが外部のホスト型サービスにアップロードされる。README は送信内容の確認と、組織のデータレビューの完了を求めている
- ネットワーク: ポート 3001・3002（取り込み用）は認証がないため、閉じたネットワークに置くこと
- 接続情報の保管: Vault を設定しない場合、パスワードを含む接続情報は Postgres に平文の JSON で保存される。本番利用では Vault の設定が前提になる
- 権限: 最小権限の読み取り専用アカウントを使うことは、docs には書かれていない。自分で用意するのが無難
- 認証の運用負荷: 業務を知る人が定義を確認する工程が必要で、列やテーブルが増えるほど工数は増える。スキーマ変更のたびの再確認も見込む
- 成熟度: 本稿の確認時点で外部からのコントリビュートは受け付けておらず、README も「現状有姿（AS IS）」で提供するとしている。回答の正しさは検証してから使うこと

向いている組織

- 業務データが Postgres・MySQL・Snowflake・Databricks などの SQL データベースにまとまっており、「売上」「顧客」の定義が部署ごとにずれている
- 自然言語で数字を引ける社内エージェントを作りたいが、誤った集計を出すリスクが気になる
- 定義を確認する担当者（データ管理者・業務の分かる人）を置ける
- 一方、データが主にドキュメントや PDF の場合や、DB が小さく単純な場合は、この仕組みは過剰になりやすい

出典

- NVIDIA/auto-ontology（GitHub） — README、docs/mcp.md、docs/connections.md、docs/authentication.md
- Building an Agent Knowledge Foundation（NVIDIA Developer）
- NVIDIA Blog（2026年10月21日、Agent Toolkit）
- Apache Ossie（Incubator 提案）

Auto Ontology はいつ発表されたのか。

NVIDIA の公式ブログによると、2026年10月21日付の記事で、Agent Toolkit の「Agent Knowledge Foundation」の一部としてライブラリが紹介されている。GitHub の最新コミットは2026年11月6日だった。リポジトリの公開日そのものは確認できていない。

完全に自動でオントロジーができるのか。

できない。NVIDIA は生成物を「出発点となるオントロジー」と説明しており、業務の専門家がテスト・修正・認証する前提である。90%の作成時間削減も NVIDIA 自社のテストでの値で、第三者の検証は確認できていない。

NVIDIA の API キーなしで動かせるか。

README のクイックスタートは NVIDIA API キーを前提にしている。モデルの endpoint は設定で変えられ、自己ホストの NIM や OpenAI 互換のエンドポイントも使えると書かれているが、その手順や動作確認の詳細までは確認していない。

社内データは NVIDIA に送られるのか。

既定の設定では、モデル推論が NVIDIA API カタログに送られる。何が送信されるかは構成によるため、機密データを扱う場合は、送信内容を確認するか、自己ホストのモデルへの切り替えを検討する。KumoRFM は API キーを設定した場合のみ、テーブルを外部にアップロードする。

文書（PDF や社内Wiki）の検索には使えるか。

主な対象は SQL データベースで、文書検索は主題ではない。文書側の知識は GraphRAG、LightRAG、各種 RAG 基盤など別の手段が向く。構造化データと文書の両方を使うなら、役割を分けて組み合わせる形になる。

ライセンスと商用利用は。

リポジトリのライセンスは Apache-2.0。ただしモデルや外部サービスには各提供元の別の利用条件があるため、商用で使う場合はモデルの条件も確認すること。

お気軽にご相談ください

お問い合わせ