11月5日、NVIDIA Developerが「How NVIDIA Uses AI Agents to Streamline AI Factory Operations」と題した記事を公開した。コンピュート・ネットワーク・ハードウェア・スケジューラーと複数の層にまたがるGPUクラスター障害を、SREがチャット一本で根本原因まで掘り下げられる——NVIDIAはそのような仕組みを自社の大規模クラスター運用に実際に投入しており、本記事でその詳細を公開している。
複数ダッシュボードを渡り歩く運用から、チャット一本への移行
GPUクラスターが大規模化すると、障害調査はコンピュート、ネットワーク、ハードウェア、スケジューラーと複数の層にまたがる。SREはトレーニングジョブのパフォーマンス低下の原因を探すために複数のダッシュボードを行き来することになるが、NVIDIAはこの問題をAIエージェントで解決しようとしている。
NVIDIAが開発したAI Factory Operations Agentは、自社内のNVIDIA DGX SuperPODクラスターの運用に実際に投入されているシステムだ。SREはチャットインターフェース一つで複数のドメイン専門エージェントに自然言語で問い合わせ、調査を切り替え、すべての操作履歴を監査ログとして追跡できる。エージェント間の通信にはMCP（Model Context Protocol）——Anthropicが提唱したLLMと外部ツールを標準的に連携させるプロトコル——を使用しており、任意の組織が採用できる構成になっている。
アーキテクチャ：オンプレミス完結、読み取り専用から始める設計
システムの中核にはNVIDIA NemoClawブループリントを使ったエージェントランタイムがある。SREのクエリを受け取り、適切なドメインエージェントにルーティングする。エージェント推論には**NVIDIA Nemotronのオープンモデル**をローカルで実行。フレームワーク全体がNVIDIA OpenClaw上で動き、オンプレミスのみでの運用が可能で、データの外部送信が発生しない設計だ。
実行環境はKubernetesで、HelmがUI・OpenClawゲートウェイ・MCPツールサーバー・推論エンドポイント・NemoClawランタイムをサービスとしてデプロイする。
Figure 1. AI Factory Operations Agentのアーキテクチャ：NemoClawエージェントがGPUクラスターインフラ全体のドメイン固有エージェントをオーケストレーションする
セキュリティ設計で特徴的なのは「読み取り専用ファースト」の原則だ。Kubernetesの操作はrun_kubectlツールを通じてサーバーサイドで実行されるが、クレデンシャルはNemoClawに渡さず、RBACで権限を明示的に制限する。実際の権限チェックはこうなる：
(agent) $ kubectl auth can-i get pods
yes
(agent) $ kubectl auth can-i get configmaps
yes
(agent) $ kubectl auth can-i get secrets
no
(agent) $ kubectl auth can-i create pods
no
(agent) $ kubectl auth can-i update pods
no
シェル実行時はメインのゲートウェイポッドではなく、セッションごとに独立したKubernetesサンドボックスを生成する。既存のサービスや本番ワークロードを変更しない設計で、SREの信頼を獲得してから自動化を進めるという段階的アプローチを取っている。
6種のドメインエージェントとその役割
現在のNVIDIA社内デプロイでは、以下のエージェントが稼働している：
- Job Recovery Agent：トレーニングジョブの失敗とグッドプット（有効スループット）の低下を検出し、スケジューラー・アプリ・ハードウェア・ネットワークの各層にまたがる根本原因分析を実施
- Hardware Agent：PCIeエラー、ECCエラー、GPU障害、NVMe障害、熱異常をデバイスレベルでトリアージし、特定コンポーネントまで症状を追跡
- Observability Agent：PrometheusやGrafana Lokiのログを照会し、ダッシュボードをその場で生成してWeb UI上に表示
- Research Agent：NVIDIA Mission ControlマニュアルやDGX SuperPODリファレンスアーキテクチャを検索。自社のランブックや手順書もアップロードして参照させられる
- Kubernetes Agent：ポッド、サービス、デプロイ、GPUリソース、ノード状態、スケジューリング状態を読み取り専用で把握
- Cluster Management Agent：NVIDIA Base Command Manager APIと連携し、クラスター管理と障害調査を支援
本番運用から得た5つの教訓
RCA（根本原因分析）精度の計測とSREの同意率トラッキングを続ける中で、NVIDIAが得た知見を以下にまとめる：
- エージェントの境界を明確に：管轄の重複はシグナルではなくノイズを生む
- 読み取り専用から始める：正確な調査がSREの信頼を築いてから、自動化を進める
- クロスレイヤー相関：ワークロード・ハードウェア・ネットワークの信号を横断的に結びつけることで、個別ツールでは見つけられない根本原因に到達できる
- MCPツールの定義を精密に：ツール定義が明確なほど、ルーティング精度が上がり誤選択が減る
- 推論の透明性：SREがアクションを取る前に、ツール呼び出し・証拠・結論を確認できる必要がある
導入規模とデプロイモデル
大規模AI factoryでの推奨構成は、本番クラスターから分離した専用GPU高速化コントロールプレーンだ。コントロールプレーンがエージェントのオーケストレーションと推論を担い、本番クラスターはテレメトリーを提供するだけに留める。トレーニングGPUを消費せず、ワークロードにも干渉しない。
小規模な環境ではRTX PRO WorkstationやDGX Sparkでローカル推論エンドポイントを立てることも想定されている。
マルチテナント構成では、OpenClawがカーネルレベルの制約を持つ独立サンドボックスでテナントごとのエージェントとツールを実行し、テナントSREには自分のnamespace・ジョブ・ノードのみが見える状態を保証する。
オーケストレーションフレームワークはGitHubで実験的なオープンソースソフトウェアとして公開されており、APIや設定はリリース間で変わる可能性がある。
詳細はHow NVIDIA Uses AI Agents to Streamline AI Factory Operationsを参照していただきたい。
