NVIDIAは2026年10月21日、企業向けAIエージェントの開発基盤「NVIDIA Agent Toolkit」を拡張し、社内データを回答や予測に結び付ける「Agent Knowledge Foundation」を発表した。文書検索用のモデルに加え、顧客や注文といった業務上の概念を整理するライブラリと、表形式のデータから予測するKumoを組み合わせる。既存のデータ基盤を生かしながら、社内情報の検索から意思決定の支援までをつなぐ構成だ。ただし、データの意味をどう定め、予測をどの行動に使うかという判断は導入企業に残る。

AD

検索・予測・最適化をつなぐ新基盤

Agent Knowledge Foundationは、モデルとデータ処理ライブラリを組み合わせて使う基盤である。NVIDIAは、データの移動や業務手順の再構築、既存の統制の変更を必要とせずに利用できると説明する。開発者向けページでも、既存のデータ基盤やエージェント開発環境と併用でき、必要な部品を個別に採用できるとしている。

各部品の違いは、社内データから何を取り出すかにある。検索は関連情報の取得、予測は将来やリスクの推定、最適化は制約を踏まえた配分を担う。NVIDIAの開発者ページにある工程説明と製品ごとの機能を対応付けると、次のように分けられる。

業務での役割 主な部品 扱う処理
関連情報を探す Nemotron Retriever、cuVS 文書の内容を読み取り、関連情報を検索して根拠の優先順位を付ける
業務上の意味を定める Auto-Ontology 顧客・製品・注文などの概念と関係の定義案を作る
データを整え、関係を調べる cuDF、cuGraph 表の結合や変換、つながりの分析を行う
将来やリスクを予測する Kumo、cuML 事前学習モデルで予測し、用途に応じて独自の機械学習処理も組む
制約を踏まえて配分する cuOpt 目的や制約に沿って経路、日程、資源配分を最適化する

出典はAgent Knowledge Foundationの開発者ページの工程説明と各製品の記載。2026年10月22日時点の機能を役割別に整理したもので、性能順位や全製品の導入順序を示す表ではない。

例えば、需要を予測する処理と、在庫や供給制約を考慮して配分を決める処理は別になる。Kumoで需要の見通しを得ても、その数値から発注先や発注量が自動的に決まるわけではない。予測に目的と制約を加えることで、最適化へ進める。

その前提を整える新しい部品がAuto-Ontologyだ。オントロジーとは、顧客や注文などの業務概念と、その相互関係を表す定義を指す。同ライブラリは企業のデータや文書から出発点となる定義案を作り、業務の専門家が検証し、修正して認定する。AIがデータを読めることと、業務上の意味が確定していることを分けた設計である。

Kumoはデータの形に応じて使い分ける

Kumoは、構造化データから予測するオープンモデルやライブラリのファミリーだ。単一の表を使う場合と、複数の表にまたがる関係を使う場合では、選ぶモデルが異なる。Kumoの開発者ページは用途を次のように説明している。

モデル 主なデータ 予測・検出する対象
Kumo Tabular 単一の表 ラベル付きの事例を文脈として使う分類・回帰
Kumo Relational 関連付けられた複数の表 レコード間の関係を使った分類・回帰
Kumo Forecast 過去の数値の時系列 需要や処理量などの将来値
Kumo Anomaly 時系列 通常とは異なる動きや異常の兆候

この表はKumo開発者ページの用途別説明に基づく。10月21日の発表ブログには「Kumo Time Series」という列挙もあり、名称は完全には一致していない。上表のモデルがすべて同日に初公開されたという意味には取れない。

Tabularは、ラベル付きの事例を入力時の文脈に置き、個々の予測課題に向けたモデル学習なしで結果を出す仕組みをうたう。Relationalもラベル付きの事例と表同士の関係を使い、顧客離反の予測などを想定している。一方、Forecastは過去の数値から将来を予測し、Anomalyは時系列の異常を検出するため、同じ時系列でも解きたい問いが違う。

実行に使うソフトウェアも分かれる。RelationalとTabularは「Kumo Structured Data Models」、ForecastとAnomalyは「Kumo-TS」を使う構成であり、独自の関係データ予測モデルを構築・学習・評価するためのKumo Engineも用意される。課題ごとの学習を省けるモデルがあっても、導入の準備までなくなるわけではない。NVIDIAはKumo Engineの導入前に、Python環境やローカルストレージ、データへのアクセスを整えるよう案内している。

AD

Palantirの先行連携から既存基盤へ

NVIDIAは今回、自社のサプライチェーン部門がPalantir Foundry、Ontology、AIPを通じてAgent Knowledge Foundationを利用していると紹介した。この取り組みには前段がある。両社は2026年9月10日の発表で、NemotronをPalantirの基盤に組み合わせ、NVIDIA自身の供給網から展開する連携を公表していた。

9月の説明では、部材配分の判断を出発点に、供給上の制約を早く見つけ、代替案を評価する用途を挙げている。調整したNemotronモデルは推奨行動や配分の得失を説明し、cuOptが制約や配分シナリオを扱う。最終判断はサプライチェーンの専門家が担う設計だ。今回の発表は、この先行連携を企業データ基盤の利用例として位置付けている。

ほかのデータ基盤との組み合わせも示された。DatabricksはKumo AnomalyをGenie Ontologyと組み合わせ、SnowflakeはNotebook環境でKumo EngineとKumo Relationalを利用できるようにするとNVIDIAは説明する。各社が扱う機能と実行環境は同じではなく、採用企業の数だけで、全機能を一律に使える段階に達したとは判断できない。

導入企業に残る定義・評価・権限の判断

Auto-Ontologyが生成するのは、業務の専門家が確かめるための定義案である。この工程は、データを既存の場所に置いたまま利用できるという説明と両立する。移行の手間を減らせても、何を同じ顧客や注文として扱うかまで自動的に確定するわけではない。

導入側の検証は、業務定義から予測、その後の行動へと分けて考えられる。まず、概念や関係の定義が実際の業務に合うかを専門家が確かめる。次に、自社のデータと目的で予測を評価し、結果をどの判断に使えるかを決める必要がある。例えば需要の増加予測を出すことと、その予測に基づく発注を許可することは、別々の判断になる。

Agent Toolkitでは、OpenShellがエージェントのアクセス先と行動を制御する実行環境を担い、NemoClawは特定業務向けエージェントを組む参照設計を提供する。データの意味付けや予測に加え、動作範囲を制御する部品も組み合わせる構成だ。ただし、今回の発表で全機能に共通する一般提供日や料金、日本語対応の条件が示されたわけではなく、利用条件は選ぶ部品と連携先ごとに確かめる必要がある。

企業にとっての導入判断は、既存基盤のどこに検索や予測を足し、どの判断を人に残すかにある。業務の定義を確かめ、予測を評価し、行動の範囲を定められれば、社内データを検索で終わらせず、配分や計画の判断に結び付ける道が開ける。