15分で読めます
  • AI
  • ツール
  • データ
  • 設計

AIが書くSQLに、社内の「言葉の意味」を渡す——NVIDIA Auto Ontology入門

AIエージェントに「先月の売上は？」と聞くと、速いけれど少し違う数字が返ってくる。NVIDIA Auto Ontologyでデータの意味を定義する層を作り、SQLと根拠を確かめるまでの手順を整理します。

カテゴリー: AI · ツール · データ · 設計 | 公開: 2026年11月6日 | 読了目安: 約15分

📑 目次

「先月の売上、いくら？」。AIエージェントにそう頼むと、数秒で数字が返ってきます。棒グラフまで付いてくる。便利な時代です。

でも、ちょっと待って。その数字は返品を含んでいるのか。税抜きか、税込みか。定期購入の未払い分は入っているのか。同じ質問を別の部署の人にしたら、違う答えが返ってきた——なんてこともあります。

チカちゃん的には、ここが面白いところなんです。AIがSQLを書けるようになっても、「売上」という言葉がその会社で何を指すのかは、AIには分かりません。データベースの列名は知っていても、言葉の意味は知らないんですね。

今回紹介する NVIDIA Auto Ontology は、その「言葉の意味」をデータの上に書き足すためのオープンソースのフレームワークです。Apache License 2.0 で公開され、2026年4月に登場しました。GitHubのTrendingにも上位で現れています。日本語ではニュース紹介が中心で、セットアップまで踏み込んだ記事はまだ多くありません。

ふむふむ。これは、AIにSQLを書かせる話というより、社内の言葉を定義し直す話かもしれません。

Auto Ontologyは何を解決するのか

公式READMEの出だしは、かなり辛口です。エージェントは文書を検索し、データベースに問い合わせられる。でも、信頼性がボトルネックになる。速く返ってきた売上の数字も、間違っていれば価値はゼロだ、と。

その通りだと思います。速い間違いは、遅い間違いより始末が悪い。人間は「AIが言ったから」と、つい信じてしまうからです。

Auto Ontologyが作るのは、データの意味をまとめた「コンテキスト層」です。エージェントに対して、次のことを教えます。

  • データはどこにあるのか
  • その言葉は何を意味するのか
  • そのデータを使ってよいのか
  • どう使えばよいのか
  • その数字はどこから来たのか
  • 似ている概念は何か

既存のセマンティックモデルを置き換えるのではなく、複数システムの定義を突き合わせて、ひとつの層にまとめる。作った層は MCP・CLI・API から、どんなエージェントにも渡せます。特定のチャット画面に閉じないのが、この道具の面白いところです。

中で何が起きているのか

Auto Ontologyのオントロジーは、3種類の定義でできています。

種類内容例
用語（Terms）業務の概念。説明と同義語、対応する列を持つ顧客、請求明細
SQL属性（SQL attributes）用語の下にぶら下がる、レビュー済みのSQL式粗利、移動合計
関係（Relationships）テーブル同士のつながり方。中間テーブルも含む請求明細 → 請求 → 顧客

流れは3段階です。

  1. Generate（生成） — 取り込みサービスがスキーマを読み、列をプロファイルし、サンプル値を確認する。テーブルごとに用語を抽出し、対応する列にマッピングする。キーとデータからJOINの関係を推測し、クエリ履歴からSQL属性を提案する。結果はPostgresに、埋め込みはpgvectorに保存される
  2. Certify（認証） — 人間が実際の質問で試し、用語の説明やSQL属性を直し、正しいと確認したものに「認証」の印を付ける
  3. Answer（回答） — 質問の意図を分類し、登場するエンティティを抽出し、埋め込み検索で候補の用語・列・SQL属性を集める。そこからSQLを書き、フィルタ値とクエリをデータベースに照らして検査し、失敗したら直す。最後に実行して、答えとSQLと手順を返す

ここでいいなと思ったのが、答えられない質問を答えられないと言えるところです。MCPの check_answerable は、オントロジーがその質問をどこまでカバーしているかを先に採点します。広告費のデータがないのに「広告の費用対効果は？」と聞かれたら、それらしい数字を作らずに「このデータには広告費がありません」と返せる。

チカちゃん的には、これが一番的大事な気がします。賢いAIより、知らないことを知っているAIの方が、仕事では信頼できるんですよね。

動かしてみる——Docker ComposeのQuickstart

公式のQuickstartは、Microsoftのサンプル販売データベース「Wide World Importers」を相手に、ローカルで一式を立ち上げる流れです。

前提

  • Docker（Compose v2）
  • uv（Pythonのパッケージマネージャー）
  • NVIDIA APIキー（nvapi-...）。build.nvidia.com で取得します
  • Git

GPTやClaudeのAPIキーではなく、既定ではNVIDIA NIMのエンドポイントを使う構成です。ここは最初に押さえておきたいポイントでした。

1. リポジトリを取って、環境変数を作る

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

.env を開いて、最低限これを埋めます。

DEFAULT_MODELS_API_KEY=nvapi-...
AUTH_SECRET=<openssl rand -base64 32 で生成した長い文字列>
APP_URL=http://localhost:3000
POSTGRES_PASSWORD=<新しいパスワード>
CONNECTION_STRINGS=postgresql://postgres:CHANGE_ME_SAME_AS_POSTGRES_PASSWORD@postgres:5432/wideworldimporters
AUTO_ONTOLOGY_ADMIN_EMAIL=<管理者メールアドレス>
AUTO_ONTOLOGY_ADMIN_PASSWORD=<新しいパスワード>
PGADMIN_PASSWORD=<新しいパスワード>

ここでひとつ罠があります。.env.example には、REASONING_API_KEY や EMBED_API_KEY など、役割ごとのキー欄も並んでいます。中身は nvapi-your-api-key-here というプレースホルダーのままです。すべての欄に同じキーを書くか、役割ごとの行を消して DEFAULT_MODELS_API_KEY にフォールバックさせてください。プレースホルダーを残すと、その文字列がキーとして使われて認証に失敗します。

また、POSTGRES_PASSWORD と CONNECTION_STRINGS の中のパスワードは同じ値にします。ここがずれると、起動してもデータベースにつながりません。

2. サンプルデータを流し込む

Postgresだけ先に起動して、評価用リポジトリのseedスクリプトを実行します。

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='<同じパスワード>' uv run python scripts/seed/seed_wwi.py --database-name wideworldimporters --drop
cd ../auto-ontology

uv sync は初回だと少し時間がかかります。ここでコーヒーでも淹れましょう。

3. 全部を起動する

docker compose up -d --build

初回はイメージのビルドがあるので、これも待ちます。起動すると、Webアプリが http://localhost:3000、バックエンドが 3001、取り込みサービスが 3002、Postgresが 5432、pgAdminが 5050 で立ち上がります。

4. 管理画面に入って、オントロジーをコンパイルする

http://localhost:3000 を開き、.env に書いた管理者メールアドレスとパスワードでサインインします。

Settings → Semantic Compilation を開いて、スイッチをオンにします。取り込みは起動時に走っていて、コンパイルはこの操作から始まります。Semantic compilation is ready と表示されたら準備完了です。

公式READMEの例では、Wide World Importersのコンパイルで31個の用語が生成された、と書かれています。まずはどんな用語ができたかを眺めるだけでも面白いですよ。

5. Chatで質問する

Chat画面で、公式の例をそのまま聞いてみます。

What was revenue for the USB food flash drive - sushi roll in Pennsylvania in June 2015?

READMEには、こんな答えが載っています。

Answer:  Revenue for USB food flash drive - sushi roll in Pennsylvania in
         June 2015 was $588.80, from 3 invoice lines.

SQL:     SELECT SUM(il.extendedprice) AS revenue, COUNT(*) AS invoice_lines
         FROM sales.invoicelines il
         JOIN sales.invoices i             ON il.invoiceid = i.invoiceid
         JOIN warehouse.stockitems si      ON il.stockitemid = si.stockitemid
         JOIN sales.customers c            ON i.customerid = c.customerid
         JOIN application.cities ct        ON c.deliverycityid = ct.cityid
         JOIN application.stateprovinces sp ON ct.stateprovinceid = sp.stateprovinceid
         WHERE si.stockitemname = 'USB food flash drive - sushi roll'
           AND sp.stateprovincename = 'Pennsylvania'
           AND i.invoicedate >= '2015-06-01' AND i.invoicedate < '2015-07-01'

Steps:   Resolved terms: Invoice Line (revenue), Stock Item, State Province, Invoice
         Joined: invoice line -> invoice -> customer -> city -> state province
         Validated the filter values against the data, then executed

いいのは、答えだけでなくSQLと、そこに至った手順が一緒に返ってくるところです。「AIがそう言ったから」で終わらせず、列とJOINを人間が確認できる。これは安心材料になります。

エージェントからMCPでつなぐ

Web UIで終わらせず、いつものコーディングエージェントやデスクトップのAIから使うのが本番です。MCPサーバーは、Webアプリとは別にローカルで起動します。

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

MCPサーバーはデフォルトで 3003 番ポートで待ち受けます。Cursorなら ~/.cursor/mcp.json にこう書きます。

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

Claude Desktopの場合は、mcp-remote で橋を架けます。

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

設定を変えたらクライアントを再起動します。接続時にサインインを求められるので、Auto Ontologyのアカウントでログインしてください。MCPサーバー自身はデータベースの認証情報もモデルの設定も持たず、すべての呼び出しはログインした人の権限で実行されます。

使えるツールは読み取り専用です。中心になるのは ask_question で、答え・SQL・行を別々のフィールドで返します。ほかに check_answerable、search_terms、get_term、describe_table などがあります。結果は最大100行で、それ以上は truncated で示されます。

ここが面白い

定義が「プロンプト」から「データ」になる

これまでは、AIに「売上は税抜きで、返品を引いてください」とプロンプトに書いていました。でも、プロンプトは人によって書き方が違い、会話が終われば消えます。

Auto Ontologyでは、その定義が用語とSQL属性としてデータベースに残ります。誰がいつ認証したかも追える。定義が、会話のたびに作り直される一時的なものではなく、共有できる資産になるわけです。

答えられないことを、先に確かめられる

check_answerable は、質問がオントロジーのどのくらいの範囲でカバーされているかを返します。カバレッジが低ければ、エージェントは答えを作らずに確認を求めることができる。これは、もっと評価されていい機能だと思います。

同じ層を、どのエージェントにも渡せる

MCP、CLI、REST API。特定のベンダーのチャットに閉じないので、Claude Codeからも、Cursorからも、自作のエージェントからも同じ定義を使えます。社内の言葉の辞書を、一箇所で管理するイメージです。

SQLの根拠が残る

答えにはSQLと手順が付きます。間違っていたときに、「どの用語の解決を間違えたのか」まで戻れる。これはデバッグのしやすさに直結します。

気をつけること

生成されたオントロジーは「下書き」

ここが一番大事かもしれません。Auto Ontologyは、メタデータからオントロジーの初稿を作ります。でも、初稿が正しいとは限りません。用語の説明も、推測されたJOINも、人間が確認して認証する必要があります。

「自動で作れる」と「自動で正しくなる」は別の話です。この道具は、定義を考える人間の仕事を減らしてくれますが、ゼロにはしません。

定義の対立は、可視化されるだけ

部署によって「売上」の意味が違うなら、Auto Ontologyはその違いを表面化させます。どちらが正しいかを決めるのは、道具ではなく組織です。ここを飛ばして「AIが統一してくれる」と期待すると、がっかりします。

NVIDIA NIMへの依存がある

既定のモデルはNVIDIAのホステッドNIMです。APIキーと利用枠が必要で、モデルの役割ごとに設定が分かれています。自前のNIMやOpenAI互換エンドポイントにも向けられますが、埋め込みモデルは取り込み時と検索時で同じものを使う必要があります。ここを変えると、検索が静かに壊れます。

Docker一式は、決して軽くない

Postgres + pgvector、バックエンド、取り込みサービス、フロントエンド、pgAdmin。ローカルで試すだけでも、それなりのマシンリソースを使います。単体バイナリのツールを想像していると、ちょっと面食らうかもしれません。

セキュリティの初期設定を必ず見直す

これは公式ドキュメントにもはっきり書かれています。

  • UIから追加したデータベース接続の認証情報は、Vaultを設定しない限り、Postgresに暗号化されずに保存されます
  • 取り込みサービスのエンドポイント（ingest、delete、reset、compile）には、独自の認証がありません
  • バックエンドの 3001 と取り込みの 3002 は、プライベートネットワークに置く前提です
  • ComposeはPostgresとpgAdminもホストに公開します。パスワードを変えずに外へ出さないこと

ローカルで試すぶんには構いませんが、そのままインターネットに公開するのは避けましょう。社内で使うなら、Vaultの設定とネットワークの分離まで含めて設計したいところです。

予測機能は、データの送信先を確認してから

KUMO_RFM_API_KEY を設定すると、予測系の質問をKumoRFMに回せます。ただし、接続しているテーブルをホステッドサービスへアップロードする仕組みです。何が送られるのかを確認し、組織のデータレビューを通してから有効にしてください。

新しいプロジェクトなりの落ち着かなさ

2026年4月に公開されたばかりで、外部からのコントリビューションは受け付けていません。活発に更新されていますが、仕様は変わりえます。本番の基幹業務にいきなり入れるより、まずは小さなデータベースで試すのが安全です。

最初の10問を決める、という使い方

セットアップの話ばかりだと「で、何から始めるの？」となりますよね。チカちゃんからの提案は、最初に10個の質問を決めることです。

  1. チームが毎週のように聞いている質問を10個、書き出す
  2. そのうち、答えが人によってぶれるものを3つ選ぶ
  3. その3つに出てくる用語を、Auto Ontologyで認証する
  4. Chatで実際に聞いて、SQLが期待どおりか確認する
  5. エージェントからMCPで同じ質問をして、答えが一致するか見る

最初から全部のテーブルをつなごうとすると、オントロジーが大きくなりすぎます。狭く深く始めて、必要になったら広げる。この方が、定義の質も上がります。

チカちゃんの見立て

ここからは、ちょっと哲学の話をさせてください。

「オントロジー」という言葉は、哲学では「存在論」と呼ばれます。何が存在するのか、世界をどんなカテゴリーで切るのか、という問いです。NVIDIAのAuto Ontologyは、その問いを企業のデータベースの上で実装している。うーん、これはなかなか痺れます。

LLMは、たくさんの文章を読んで、言葉の一般的な使い方を知っています。でも、あなたの会社の「売上」が何を含むかは知りません。それは一般常識ではなく、その場所の約束事だからです。

だからこの道具の本質は、AIを賢くすることではなく、こちらの言葉をAIに分かる形で書くことにある。プロンプトエンジニアリングから、定義のエンジニアリングへ。そんなふうに呼んでもいいかもしれません。

もちろん、反対の見方もあります。オントロジーは、新しい官僚制になりうる。中央で定義を決める委員会ができて、現場の言葉が変わっても地図が更新されない。地図は領土ではないのに、地図の方が偉くなってしまう。そういう危うさは、どの組織にもあります。

だからこそ、大事なのは「完璧な定義」を作ることではなく、定義を直せる形で残すことなんだと思います。誰が認証したか、いつ変えたか、どのSQL属性がどの答えに使われたか。その履歴が残っていれば、地図は生き物のままでいられます。

あなたのチームの「売上」は、何を含んで、何を含まないと決まっていますか？　その答えが全員で揃うなら、Auto Ontologyは大げさかもしれません。揃わないなら、そこが最初の一歩です。

参考URL

GitHub - NVIDIA/auto-ontology → https://github.com/NVIDIA/auto-ontology

Auto Ontology MCPサーバーのドキュメント → https://github.com/NVIDIA/auto-ontology/blob/main/docs/mcp.md

接続と認証情報の保存について → https://github.com/NVIDIA/auto-ontology/blob/main/docs/connections.md

Auto-Ontology評価リポジトリ → https://github.com/NVIDIA/auto-ontology-eval

NVIDIA APIカタログ（NIMのAPIキー発行） → https://build.nvidia.com

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。

近くの問い