NVIDIA Auto Ontology: エージェント分析を信頼性の高いものにするオープンソースのセマンティックレイヤー

NVIDIA Auto Ontologyは、Apache-2.0ライセンスのPythonフレームワークで、エンタープライズデータの上にセマンティックでグラフベースのオントロジーレイヤーを構築し、LLMおよびエージェントのワークフローが、推測ではなく、来歴（プロvenance）を伴う決定的で検証済みのSQLクエリを生成できるようにします。NVIDIAはこれをオープンソースリポジトリgithub.com/NVIDIA/auto-ontologyとして公開しており、Hacker Newsで206ポイント、70コメントを獲得しました。

このリポジトリは、スピードではなく信頼性に動機を置いています。「エージェントはドキュメントを取得し、データベースにクエリを実行できますが、エージェント分析を制限するのは信頼性です。数値が間違っていれば、高速に回答された収益メトリクスには価値がありません。」Auto Ontologyは、データがどこにあるか、何を意味するか、使用すべきか、どのように使用するか、どこから来たか、何に類似しているかをエージェントに回答するコンテキストレイヤーとして位置づけられています。NVIDIAは、顧客がすでに所有しているセマンティックモデルを置き換えるのではなく、補完すると述べています。

オントロジーレイヤーが解決する問題

中核となる主張は、エージェントにはデータベースへのアクセスだけでなく、認定されたビジネス上の意味が必要であるということです。Auto Ontologyは、既存のエンタープライズメタデータからレイヤーを構築し、システム間で定義を調整し、MCP、CLI、HTTP APIを通じて結果を任意のエージェントハーネスに公開します。

リポジトリには5つの機能がリストされています。

発見（Discover）: メタデータからエンタープライズオントロジーを生成し、既存のオントロジーとセマンティックモデルを接続し、AI対応の知識グラフを構築します。
接地（Ground）: メトリクス、エンティティ、リレーションシップに対して、エージェントに信頼できるビジネス上の意味を与え、システム間で矛盾する定義を調整します。
検証（Validate）: 生成されたクエリを認定された定義と来歴に対してチェックし、すべての回答に来歴を添えて返します。
公開（Expose）: MCP、CLI、APIを通じて、任意のエージェントハーネスにコンテキストを提供します。
学習（Learn）: 認定された修正と使用状況をオントロジーに反映し、共有コンテキストが質問のたびに改善されるようにします。

ソフトウェアコンポーネントとデフォルトポート

Auto Ontologyはマルチサービススタックとして提供されます。フロントエンドはNext.js 16アプリケーション（React 19、TypeScript、Tailwind CSS 4）で、Better AuthとPrismaを使用し、ポート3000でWeb UI、認証、APIゲートウェイを提供します。バックエンドはPython 3.12+上のFastAPIでLangChainを使用し、ポート3001でチャット、自然言語からSQLへの変換、カタログ、データソースAPIを処理します。別のFastAPI取り込みワーカーが表形式データを取り込み、ポート3002でエンベディングを書き込みます。pgvectorを備えたPostgresがポート5432で、アプリケーションメタデータ、カタログとオントロジー、ベクターストアを保存します。HashiCorp Vaultはオプションであり、コンポーネントテーブルにはポートが割り当てられていません。

Web UIは、チャット、分析、データカタログ、分析、設定をカバーしています。デプロイは、Kubernetes用のHelmチャートまたはローカルスタック用のDocker Composeのいずれかを介してサポートされています。

推論はNVIDIA NIMとモデルトリプレットを通じて構成されます

Auto Ontologyは推論にNVIDIA NIMエンドポイントを使用します。ホスト型NVIDIA APIカタログ（integrate.api.nvidia.com）または自己ホスト型NIMのいずれかです。リポジトリの.env.exampleのデフォルトは次のとおりです。

LLM: nvidia/nemotron-3-nano-30b-a3b
エンベディング: nvidia/nemotron-3-embed-1b
再ランキング: nvidia/llama-nemotron-rerank-vl-1b-v2

各モデルロールは、PREFIX_ENDPOINT URL、PREFIX_API_KEY、PREFIX_MODELの3つの環境変数のトリプレットによって構成されます。ロールは、DEFAULT_MODELS（他のすべてがフォールバックする共有デフォルト）、REASONING（メインのチャットおよびNLからSQLへのモデル）、NON_REASONING（エンティティ抽出に使用される軽量モデル）、EMBED（テキスト埋め込みモデル。取り込みとクエリで一致する必要があります）、RERANK（検索フローで使用される再ランカー）です。設定されていないフィールドは、対応するDEFAULT_MODELS_フィールドにフォールバックし、*_API_KEYも後方互換性のためにレガシーのNVIDIA_API_KEY変数にフォールバックします。

デプロイの前提条件

ローカルスタックには、Docker Compose v2を備えたDocker、build.nvidia.comから取得したnvapi-...形式のNVIDIA APIキー、およびクエリ対象のソースデータベースの接続詳細が必要です。リポジトリで指定されているサポート対象のソースシステムは、Databricks、Postgres、Snowflake、DuckDBです。

インストールは、リポジトリのクローン、.env.exampleを.envにコピーしてPostgresの資格情報、DEFAULT_MODELS_API_KEY、CONNECTION_STRINGSなどの値を入力し、docker compose up -d --buildを実行します。このビルドにより、バックエンド（auto_ontology）とフロントエンド（auto-ontology-frontend）のイメージが生成され、PostgresとpgAdminが起動し、データベーススキーマを同期するためのワンショットのfrontend-migrateジョブが実行され、アプリが起動します。UIはhttp://localhost:3000で提供され、バックエンドAPIはポート3001、pgAdminはポート5050で提供されます。

リポジトリは2つの構成上の落とし穴にフラグを立てています。AUTH_SECRETとAPP_URLは必須であり、これらがないと、すべてのページでBetter Authの「デフォルトシークレット」エラーが発生します。POSTGRES_PORTはホスト側のポートマッピングのみを変更します。コンテナは常に内部ネットワークポートでPostgresに到達するためです。また、再起動後にブラウザが古いセッションCookieを保持しているために、UIが左側のナビゲーションパネルなしで読み込まれるというトラブルシューティングのケースも文書化されています。これは、AUTH_SECRETが変更された場合やデータベースがリセットされた場合に発生します。localhost:3000のサイトデータをクリアするか、better-auth.session_token Cookieを削除すると解決します。

資格情報ストレージは、Vaultが構成されていない限り、デフォルトでプレーンテキストになります

これは、リポジトリ内で最も運用上重要なセキュリティ詳細です。UIを通じて追加された接続は、Vaultが構成されていない限り、資格情報がPostgresにプレーンテキストで保存されます。Vaultがない場合、パスワードを含む完全な接続オブジェクトはJSONシリアライズされ、カタログのデータベース行に暗号化されずに保存されます。Vaultがある場合、資格情報はデータベース名をキーとしてVaultに書き込まれ、カタログ行には資格情報が保存されません。データベース名自体がルックアップキーであり、個別の参照フィールドがないためです。

Vaultは、VAULT_ADDR、VAULT_NAMESPACE、VAULT_ROLE_ID、VAULT_SECRET_IDの4つすべてが設定されている場合にのみ有効になります。VAULT_AUTH_MOUNTとVAULT_KV_MOUNTはオプションのオーバーライドです。デフォルトではオフであり、部分的な構成は警告とともに無視され、プレーンテキストストレージにフォールバックします。

接続定義の2番目のソースは、CONNECTION_STRINGS環境変数です。これは、デプロイ時に提供されるカンマ区切りのリストで、たとえばHelmの--set connectionStrings=フラグを使用します。このパスは明示的にフォールバックです。UIで追加された接続がない場合にのみ使用されます。

エージェントAPI、APIトークン、FastAPIの信頼境界

パブリッククライアントは、認証されたNext.jsゲートウェイをPOST /api/chat/completionsで呼び出します。応答は、step、result、errorイベントとそれに続く[DONE]を運ぶSSEストリームです。conversation_idフィールドはオプションです。ステートレスなワンショットリクエストの場合は省略するか、クライアント生成のUUIDを指定して会話を作成または継続し、すべてのターンで同じUUIDを再利用します。呼び出し元は、次のターンを送信する前に[DONE]を待つ必要があります。1つの会話に対する重複するリクエストは409 Conversation in progressを返すためです。

会話リクエストの場合、FastAPIは最大5つの最近完了したターンを読み込み、12,000文字に制限し、「8月はどうですか？」などのコンテキスト入力を、既存のテキストからSQLへのグラフを実行する前に、スタンドアロンの質問に書き換えます。独立した質問は変更されずに通過します。内部のエージェント思考、チャートペイロード、エラー、生のSQL結果セットはコンテキストとして再利用されません。会話履歴は、認証されたAuto Ontologyユーザーにスコープされます。

リポジトリは、FastAPIの周りに明示的なセキュリティ境界を描いています。FastAPIポートは信頼された内部サービス境界であり、公開してはならないと述べています。FastAPIは、Next.jsゲートウェイが転送する内部のx-auto-ontology-user-idヘッダーを独立して検証しないためです。conversation_idなしの直接のFastAPIリクエストはステートレスのままです。conversation_idを使用した直接リクエストには、信頼されたIDヘッダーが必要です。APIで作成された会話は、署名済みユーザーに属している場合、/chat?focus=でUIで開くことができます。

APIトークンは、ブラウザのセッションCookieを保持できないスクリプト、ノートブック、スケジュールされたジョブのために存在します。これらはユーザーメニューのAPIトークンから発行され、Auto OntologyはSHA-256ハッシュのみを保存するため、トークンは正確に1回だけ表示され、紛失した場合は新しいものを発行する必要があります。トークンは、任意の/api/...呼び出しでx-api-keyヘッダーとして送信され、Authorization: Bearer も機能します。

4つのトークン動作が文書化されています。

トークンは所有者として動作し、それ自体の権限は持ちません。したがって、すべての呼び出しは、ブラウザの場合とまったく同じように所有者のロールに対して承認され、ビューアのトークンは管理者アクションを実行できません。
APIサーフェス全体がトークンを受け入れます。認証はすべてのルートで1か所（frontend/auth/resolve-user.ts）で解決されるため、docs/openapi/auto-ontology-api.jsonでwithPublicとマークされていないエンドポイントはすべてトークンで機能します。
失効は即時です。UIでトークンを削除するか、所有ユーザーを削除または禁止すると、次にそのトークンを使用したリクエストは401を受け取ります。
トークンはトークンを管理できません。トークンの作成と失効には署名済みセッションが必要なため、漏洩したトークンはそれ自体の後継を発行できません。

認証ではSSOがサポートされており、リダイレクトURIはIDプロバイダーでAPP_URL/api/auth/sso/callbackとして構成されます。

MCPサーバーとコーディングエージェントスキル

CursorやClaude Desktopなどのエージェントハーネスは、Auto OntologyのMCPサーバー（mcp/ディレクトリとdocs/mcp.mdに文書化）を通じてデータを照会できます。コーディングエージェントはAGENTS.mdから開始するように指示され、skills/ディレクトリには3つのスキルが同梱されています：nvidia-ontology-setup、nvidia-ontology-management、nvidia-ontology-query。プロジェクトのメンテナーは引き続きCLAUDE.mdを使用しています。

ベンチマークは参照されていますが、リポジトリには公開されていません

リポジトリは開発者に、BIRDなどのテキストからSQLへのベンチマークを実行するための別のオントロジーSQL評価リポジトリgithub.com/NVIDIA/ontology-sql-evalを指し示しています。Auto Ontology自身のREADMEには、精度、レイテンシ、コストの数値は公開されていないため、プロジェクトに関するパフォーマンスの主張は、リポジトリから引用するのではなく、その評価ハーネスに対して再現する必要があります。

ライセンス、貢献、外部依存関係

Auto OntologyはApache License、Version 2.0の下でライセンスされており、SPDX識別子はApache-2.0です。NVIDIAが作成したソースファイルには、「SPDX-FileCopyrightText: Copyright (c) 2024-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.」というSPDXヘッダーと「SPDX-License-Identifier: Apache-2.0」が含まれています。サードパーティのオープンソースコンポーネントは、THIRD_PARTY_NOTICES.mdに上流のライセンスとプロジェクトURLとともに列挙され、コンテナイメージによって追加されたコンポーネントはCONTAINER_THIRD_PARTY_NOTICES.mdに個別にリストされています。

オープンソースライセンスにもかかわらず、プロジェクトは現在外部からの貢献を受け付けていません。「Auto Ontologyメンテナーチームの外部から送信された問題、プルリクエスト、パッチはレビューまたはマージされません。」セキュリティ関連のレポートはSECURITY.mdを通じてルーティングされ、メンテナーのワークフローはCONTRIBUTING.mdにあります。

リポジトリには、ソフトウェアが外部のマテリアルを取得して対話するという通知も含まれており、これらのマテリアルはソフトウェアとともに配布されておらず、別の条件に準拠しています。リストされているランタイム外部マテリアルは、チャット、取り込み、セマンティックコンパイル中のLLM、エンベディング、再ランキングのためのbuild.nvidia.comおよびintegrate.api.nvidia.comのNVIDIAホスト型モデルAPI、ユーザーが*_ENDPOINTおよび*_MODEL変数を通じて構成するその他のOpenAI互換モデルエンドポイント、KUMO_RFM_API_KEYが設定されている場合にのみ使用されるKumoの条件に基づくKumoRFM予測クエリサービス、および取り込み、プロファイリング、クエリ実行中のユーザー自身のソースデータベースです。

Hacker Newsの議論の反応

反応は、エンタープライズオントロジー作業をAIの真のボトルネックと見る人々と、別のLLM駆動レイヤーを追加することがエージェントの信頼性の問題を修正するかどうかに懐疑的な人々に分かれました。

最も鋭い技術的異議はgrey-areaからで、アーキテクチャが不確実性を除去するのではなく追加していると主張しました。

信頼性の低いエージェントを、さらに信頼性の低いエージェントを追加することで修正する。LLMが、分析しているデータよりも自身の重みに重点を置く傾向に対して何かできないのは残念だ。結局、彼らは世界について学習したデータ、指示、分析中のデータを明確に区別していないということに帰着する。目の前の5つの事実だけを考慮するように頼むことはできるが、彼らはそうしないし、そうすることもできない。

HexDecOctBinは、オントロジーフレーミングが招くシンボリックAIの疑問を提起しました：データに適合するために必要なだけのシンボリックルールをLLMに書かせ、ルールセットをレビュー可能で保守可能に保つのはどうか。この疑問は、Auto Ontologyの設計における緊張を直接指し示しています。この設計では、LLM（NIM経由）を使用して、質問に直接回答するのではなく、シンボリックでレビュー可能なカタログを生成および維持します。

何人かのコメンテーターは、製品がどこで終わり、周囲の複雑さがどこから始まるのかを疑問視しました。podocarpは、これがエンタープライズのAPIとCLIを収集するメモリシステムとスキルのセットと何が違うのかと尋ねました。bborは、READMEがエンタープライズプロジェクトマネージャー向けに書かれていると感じ、プロジェクトがどの哲学または学術的なオントロジー研究に結びついているのかを尋ね、詳細は追いにくいと述べました。dstuは冒頭の文の「ゲート」という言葉に本能的な反応を示し、構築する価値のあるツールは、作者自身の平易な言葉で説明する価値があると主張しました。

採用の摩擦が実際的な異議として提起されました。igleriaは興味を示しましたが、プロジェクトがNVIDIA APIキーを必要とすることに気づいてがっかりしました。これはリポジトリと一致しており、NVIDIA APIキーは前提条件としてリストされ、デフォルトのモデルエンドポイントはbuild.nvidia.comを指しています。

需要側では、monkeydustは、エンタープライズAIの実際の成功に不可欠であるため、オントロジーを正しくするために大金を費やしたと述べ、これが役立つかどうか興味があると述べました。元の投稿者であるcampervansは、価値提案を率直に要約しました：「エンタープライズ（技術的）負債のゲームチェンジャー」。

別の懐疑的なスレッドは、NVIDIAのオープンソースの姿勢をより広く標的にしました。einpoklumは次のように書いています。

オープンソース？まずNVIDIAのユーザースペースライブラリ、libcuda、libcudart、libOpenCL、libnvtx、そしてnvidia-smiとCUDAおよびOpenCLプロファイラーをオープンソース化することから始めたらどうか。

その批判は、上流のドライバーとツールチェーンコンポーネントに関するものであり、Apache-2.0であるAuto Ontology自体のライセンスに関するものではありません。

Auto Ontologyを採用する前に確認すべきこと

リポジトリ内の3つの点は、特定のデプロイに対して確認する価値があります。まず、資格情報ストレージは、UIで追加された接続の場合、4つのVault変数がすべて設定されていない限り、Postgresにプレーンテキストで保存されるため、本番データベースのパスワードを扱うデプロイではVault構成はオプションではありません。次に、FastAPIポートは公開してはなりません。IDヘッダーはその境界で検証されるのではなく信頼されるためです。第三に、プロジェクトは独自のベンチマーク結果を公開していません。READMEは、BIRDなどのテキストからSQLへのベンチマークを実行するために、別のontology-sql-evalリポジトリを読者に指示しているだけです。潜在的な採用者は、外部からの貢献が現在閉じられているため、ロードマップが完全にNVIDIAのメンテナーチームによって管理されていることも考慮する必要があります。