NVIDIAがDGX SuperPODのAIファクトリー運用エージェントを解説：NemoClawとOpenShell上に6つのドメインエージェント、Kubernetesの確認には読み取り専用の認証情報を使用；精度値は未公表、イメージにはNGC早期アクセス招待が必要

2026年11月4日、NVIDIAは開発者ブログに「How NVIDIA Uses AI Agents to Streamline AI Factory Operations」を公開しました。著者はKavya G YとRohan Adwankarです。記事はAI Factory Operations Agentを紹介しています。NVIDIAによれば、これは自社内のDGX SuperPODクラスターの運用を効率化し、サイト信頼性エンジニア(SRE)の手作業を減らすために作ったものです。SREは計算、ネットワーク、ハードウェア、スケジューラーのダッシュボードを一つずつ確認する代わりにチャットで質問し、専門のサブエージェントが証拠を集めて突き合わせます。サブエージェント同士はModel Context Protocol(MCP)で通信します。ページにはNVIDIA Nemotronモデルが自動生成した要約もありますが、本稿では使わず、記事本文とGitHubリポジトリを根拠にしました。

アーキテクチャはNVIDIAのNemoClawブループリントを中心にしています。ユーザー向けのエージェントランタイムがSREの質問を受け、ドメインエージェントに振り分けます。エージェントはOpenClawプラグインとMCPサーバー経由でインフラに接続し、各MCPサーバーは承認された少数の運用ツールだけを公開します。フレームワークはNVIDIA OpenShell上に構築され、記事によれば完全にオンプレミスで動かせ、推論にはローカルで提供されるNVIDIA Nemotronのオープンモデルを使います。NVIDIAは、このフレームワークが社内のDGX H100、DGX B200、DGX GB300の本番クラスターで動いていると述べています。これはNVIDIA自身の展開の説明で、他のユーザーに求めるハードウェア要件ではありません。

展開はKubernetesのコントロールプレーンアプリケーションです。Helmがウェブ画面、OpenClawゲートウェイ、MCPツールサーバー、推論エンドポイント、OpenShellランタイムをサービスとして導入します。シェルコマンドの実行では、OpenShellがメインのゲートウェイPodで直接実行する代わりに、セッションごとに別のKubernetesサンドボックスを作ります。Kubernetesの調査は、固定されたkubectlバイナリと登録済みの読み取り専用の認証情報を使うサーバー側のrun_kubectlツールを通り、OpenShellはkubectlもKubernetesの認証情報も受け取りません。記事はエージェント側からkubectl auth can-iを実行した結果を示しています。Podとconfigmapは取得できますが、secretの取得とPodの作成・更新はできません。これは権限境界の分かりやすい一例で、一つの構成から得たものです。

六つのドメインエージェントが挙げられています。ジョブ復旧エージェントは学習ジョブの失敗とグッドプットの低下を検出し、スケジューラー、アプリケーション、ハードウェア、ネットワークの各層で根本原因を分析します。ハードウェアエージェントはPCIe、ECC、GPU、NVMe、熱の異常を個別の部品まで絞り込みます。オブザーバビリティエージェントはPrometheus、テレメトリ、Grafana Lokiのログを照会し、必要に応じてダッシュボードを作ります。リサーチエージェントはNVIDIA Mission Controlのマニュアル、DGX SuperPODのリファレンスアーキテクチャなど事前に読み込んだ文書を検索し、チーム独自のランブックも追加できます。Kubernetesエージェントは、Pod、サービス、デプロイメント、GPUリソース、ノードの状態を読み取り専用で把握します。クラスター管理エージェントは診断用ツールを通じてNVIDIA Base Command ManagerのAPIと連携し、助言的な作業をします。横断的なMCPツールには、ウェブ検索、コード実行、Grafanaダッシュボードがあり、独自のMCPサーバーを接続することもできます。

NVIDIAは本番利用から五つの教訓を挙げています。エージェントの境界を明確にすること。まず読み取り専用で始め、自動化の前に正確な調査で信頼を築くこと。層をまたいで相関を取り、孤立したツールが見逃す原因を見つけること。MCPツールを正確に定義してルーティングを良くすること。ツール呼び出し、証拠、結論を見せ、SREが行動する前に確認できるようにすることです。記事は、根本原因分析の精度を測り、SREの同意を追跡しながらフレームワークを改善していると述べています。ただし、精度の数字も、同意率も、インシデント件数も、削減できた時間も公表されていません。デモ動画は、内部デモ用にDGXクラスターへ注入したインシデントの例とされています。

提供状況は、二つの資料が強調する点が違うため、注意して読む必要があります。記事はこのオーケストレーションフレームワークを実験的なオープンソースソフトウェアと呼び、API、設定、デプロイ要件がリリース間で変わる可能性があるとして、GitHubリポジトリを案内しています。Apache 2.0ライセンスのリポジトリも実験的リリースと述べ、さらに、早期アクセス段階では公開されたHelmチャートとコンテナイメージの取得に非公開のNGCレジストリへの招待が必要で、nvcr.ioにログインするだけではプルできないと付け加えています。要件はKubernetes、kubectl、Helm 3、OpenAI互換のエンドポイントまたはチャートが管理するvLLMで、GPUが必要なのはそのvLLMを展開する場合だけです。別に、記事はNVIDIAの顧客がアカウントマネージャーを通じてNVIDIA開発のクラスター運用エージェントの利用を申請できると述べています。READMEには、記事が挙げていないワークフロー、たとえばSlurmジョブの分析やVictoriaMetricsへの問い合わせもあり、ブラウザーUI、HTTP API、コマンドラインクライアント、コーディングエージェント向けのMCPブリッジという四つのインターフェースも示されています。

マルチテナントのクラスターでは、記事は範囲を絞ったエージェント、ツール、サンドボックス、Kubernetes権限を説明しています。テナントのSREは自分のネームスペース、ジョブ、ノードだけを見られ、中央運用はより広い範囲を保ち、OpenShellがカーネルレベルの制限を強制します。エージェントの推論が学習用GPUを使わないよう、本番クラスターから分離したGPU搭載の専用コントロールプレーンを勧め、小規模な展開ではRTX PRO WorkstationやDGX Sparkにも触れています。

私たちの見方です。これはベンダーが自社の内部ツールを説明するアーキテクチャと教訓の記事です。読み取り専用の認証情報、セッションごとのサンドボックス、狭いMCPツールといった設計判断は具体的で再利用できますが、投資と比べられる測定結果はありません。採用を考えるチームは、コンテナイメージへのアクセス権を最初の関門として扱い、まず非本番クラスターで試すのがよいでしょう。