NVIDIAが16社と作った"オープンAIエージェント基盤"。開発者が今週コードに入れるべき3つの実装変化

⚡ この記事はシリーズ第2回です。第1回 “バイブコーディングは序章だった。「エージェンティックエンジニアリング」で開発者が指揮者になる日” をまだ読んでいない方は、先にそちらをどうぞ。

16社が同じ土俵に立った。GTC 2026で何が起きたのか

前回の記事で「開発者は指揮者になる」と書いた。AIエージェントに指示を出し、コードの品質と方向性を人間が握る時代が来ると。

その記事を書いた翌週、指揮者の手元に”共通楽譜”が届いた形になる。

2026年3月16日、NVIDIAのGTC（GPU Technology Conference）。プレスリリースのタイトルが目に飛び込んできた。

「NVIDIA Ignites the Next Industrial Revolution in Knowledge Work With Open Agent Development Platform」

直訳すると「オープンなエージェント開発基盤で、ナレッジワークの産業革命に火をつける」（NVIDIA Newsroom）。

採用を表明した企業名を見て驚いた（VentureBeat）。

Adobe（アドビ）、Atlassian（アトラシアン）、SAP、Salesforce（セールスフォース）。Cisco（シスコ）、CrowdStrike（クラウドストライク）、ServiceNow（サービスナウ）、Siemens（シーメンス）。ほかにもAmdocs、Box、Cadence、Cohesity。Dassault Systèmes（ダッソー・システムズ）、IQVIA、Red Hat、Synopsys（シノプシス）。合計16社だ。

SalesforceとSAPって、CRMで真正面からぶつかっている2社じゃないか。その両社が同じツールキットを使うと宣言している。

これは技術の話だけじゃない。“エージェント開発の共通言語が決まった”というシグナルだ。

開発者にとって実装面で押さえるべきポイントは3つある。NeMo Agent Toolkit（ネモ・エージェント・ツールキット）、A2Aプロトコル、OpenShell（オープンシェル）。1つずつ見ていこう。

NeMo Agent Toolkit。既存コードをエージェント化する最短ルート

私が最初にやったのは、NeMo Agent ToolkitのGitHubリポジトリを開くことだった（GitHub）。

このツールキットの売りは”フレームワーク非依存”だ。LangChain（ラングチェーン）を使っていてもいい。LlamaIndex（ラマインデックス）でもCrewAI（クルーエーアイ）でも動く。Microsoft Semantic Kernel（セマンティックカーネル）やGoogle ADK（エージェント開発キット）にも対応している。既存のコードをそのまま持ち込める設計がポイントだ。

具体的な手順はこうなる。ツールキットのworkflow createコマンドを叩くと、プロジェクトの雛形が生成される。核になるのはpyproject.tomlとconfig.yamlの2ファイルだ。エージェントの構成要素をYAMLで定義する。

# config.yaml の構成イメージ（簡略版）
# NeMo Agent Toolkit でエージェントのスキルを定義する
workflow:
  name: my-first-agent
  description: "社内ナレッジを検索するエージェント"

  # 使用するフレームワークを指定
  framework: langchain

  # スキル（エージェントができること）を列挙
  skills:
    - name: search_docs
      type: retrieval   # RAG検索
    - name: summarize
      type: generation  # 要約生成

ここがバイブコーディング出身の私に刺さったポイントになる。YAMLを書くだけでエージェントの骨格ができるから、コードのアーキテクチャ設計で何日も悩む必要がない。

NVIDIAが用意した”AI-Qブループリント”にも注目してほしい。これは検索エージェントのリファレンス実装だ。DeepResearch Benchという精度ベンチマークでトップを記録している（NVIDIA Developer Blog）。「まず動くものを見て、そこからカスタマイズする」のが私の開発スタイル。このブループリントはその入口として最適だと感じた。

Google Colabでセットアップなしに動かせるノートブックも公開されている（NVIDIA Developer）。環境構築でハマる心配がないのはありがたい。

ハマりポイントを先に共有しておく。NeMo Agent Toolkitはv1.5が最新だが、ドキュメントの一部がv1.4のまま更新されていない箇所がある。config.yamlのスキーマが微妙に変わっているケースがあるので、必ず公式ドキュメント最新版を参照してほしい。READMEだけ読んで進めると、私のように30分溶かすことになる。

DeepLearning.AIにはNVIDIAのソリューションアーキテクトが教える無料コースも出ている（DeepLearning.AI）。「エージェントを本番で信頼性高く動かすには」というテーマで、Toolkit導入後に必ず直面する問題を扱っている。週末にAI-Qブループリントを動かした後に受講する流れがおすすめだ。

A2Aプロトコル。エージェント同士が会話する共通言語

NeMo Agent Toolkitで作ったエージェントは、単体でも機能する。ただ本当に面白いのは、複数エージェントを連携させた時だ。

ここで登場するのがA2A（Agent-to-Agent）プロトコルになる。もともとGoogleが開発し、現在はLinux Foundationに寄贈されたオープン標準だ（A2A Protocol公式）。

A2Aが解決する問題は明確。「違うフレームワークで作られたエージェント同士が、どうやって情報をやり取りするか」という疑問に答えを出している。

MCP（Model Context Protocol）との違いが気になる人もいるはず。MCPはAIモデルが外部ツールにアクセスするための規格だ。整理するとこうなる。

• MCP: エージェントが外部ツールやデータソースにアクセスするための規格。“道具箱を開ける鍵”
• A2A: エージェント同士がタスクを委任し合うための規格。“同僚に仕事を頼む時の共通語”

NeMo Agent Toolkit v1.4以降ではA2Aが標準サポートされている（NVIDIA NeMo A2Aドキュメント）。公式ドキュメントによると、既存のLangGraphエージェントを最小限のコード変更でA2A対応にできるそうだ。

バージョン0.3ではgRPC対応やセキュリティカード署名の機能が追加された（Google Cloud Blog）。150を超える組織がすでにA2Aへの対応を表明している。

「うちのエージェントは他と繋がりません」は、もう通用しなくなりつつある。

実装イメージを示しておこう。既存のLangGraphエージェントにA2Aサーバー機能を追加するコードは、このくらいシンプルになる。

# A2A対応の最小構成（NeMo Agent Toolkit）
# 既存のLangGraphワークフローをA2A公開するイメージ
from nemo_agent_toolkit.a2a import A2AServer

# 自分のエージェントをA2Aサーバーとして公開
server = A2AServer(
    agent=my_langgraph_agent,  # 既存エージェントをそのまま渡す
    name="doc-search-agent",
    description="社内ドキュメントを検索して要約する"
)
server.start(port=8080)
# これだけで他のA2A対応エージェントから呼び出せるようになる

MCPでツールを繋ぎ、A2Aでエージェント同士を繋ぐ。この二層構造が2026年のマルチエージェント開発の基本形になりそうだ。

OpenShell。自律エージェントを野放しにしない安全装置

正直に言う。自律型エージェントの話を聞くたびに、少し怖い。

「AIが勝手にAPIを叩いて、勝手にデプロイして、勝手に課金が発生する」。そんなシナリオが頭をよぎる。CS出身だからこそわかるけど、ユーザーが「想定外の動きをされた」と感じた瞬間に信頼は崩壊する。

NVIDIAはここに”OpenShell”というオープンソースのランタイムをぶつけてきた。セキュリティ、ネットワーク制御、プライバシーのガードレールをポリシーベースで強制する仕組みだ（VentureBeat）。

要するに「エージェントが動ける範囲をあらかじめ決めておく箱」だと思ってほしい。エージェントがどれだけ賢くなっても、OpenShellが許可した範囲外のAPIは叩けない。

前回の記事で「エージェントを止めるタイミングの見極めが大事」と書いた。OpenShellは、その”止める基準”をコードで定義できるツールになる。

個人開発でも意味がある場面は多い。業務ツールを自分で作っている時、「このBotが暴走したらどうしよう」という不安は常についてくる。OpenShellがあれば、「やっていいこと」と「やってはいけないこと」の境界線をポリシーファイルで明示的に書けるわけだ。

「動けばOK」の精神でやってきた私にとって、安全装置が標準装備される時代はむしろ歓迎すべき変化だと感じている。

前回の記事でも触れたCurXecute（カーゼキュート）を思い出してほしい。バイブコーディングツールでゼロクリック脆弱性が発見された直後の発表だ。自由に動けるエージェントと安全に動くエージェントの両立が、実装可能な現実になりつつある。

16社が同時に動いた背景。Gartner「40%」予測の重み

なぜ16社が同時に動いたのか。背景にあるのは業界アナリストの予測だ。「2026年末までにエンタープライズアプリの40%がタスク別AIエージェントを組み込む」という数字が浮かび上がっている。2025年時点では5%未満だったから、1年で8倍という計算になる。

各社の動きを見ると、その切迫感が伝わってくる。

Salesforceは”Agentforce”というサービスでNeMo Agent Toolkitを採用した。営業・マーケ・カスタマーサービス向けのAIエージェントを構築する方針だ。会話インターフェースとしてSlackを使う設計になっている。

SAPは”Joule Studio”というプラットフォームにAgent Toolkitを統合する。SAP BTP（Business Technology Platform）上でAIエージェントを動かす構想になっている。

Adobeはクリエイティビティ、生産性、マーケティングの長時間実行エージェントにToolkitを採用すると表明した。

つまり、開発者がこれらの製品を扱っている場合、裏側にNeMo Agent Toolkitが動いている可能性が出てきた。直接触れなくても、エコシステムとして知っておく価値は十分にある。

前回紹介したPragmatic Engineer（プラグマティック・エンジニア）調査を思い出してほしい。Claude Codeが最愛用ツール46%を記録した調査だ。エージェント開発の主戦場が”どのLLMを使うか”から”どの基盤でエージェントを組むか”に移りつつある。NVIDIAの動きは、その転換を象徴している。

まとめ。この週末にやれること3つ

前回の記事では「エージェンティックエンジニアリングで開発者は指揮者になる」と書いた。今日伝えたいのは「指揮者の楽譜が、オープンソースで手に入るようになった」ということになる。

NeMo Agent Toolkit、A2Aプロトコル、OpenShell。この3つが揃ったことで、エージェント開発の入口が一気に広がった。

この週末にやれることを3つ挙げておく。

1. NeMo Agent ToolkitのGitHubリポジトリ（github.com/NVIDIA/NeMo-Agent-Toolkit）をクローンして、AI-Qブループリントを動かしてみる。Google Colabでもいけるから、環境構築でハマる心配はない
2. A2Aプロトコルの仕様書（a2a-protocol.org）を読む。MCPとの違いを理解しておくだけで、来週の設計判断が変わるはずだ
3. DeepLearning.AIの無料コース（deeplearning.ai）でハンズオンを試す。NVIDIAのソリューションアーキテクトが直接教えてくれる内容になっている

挫折エンジニアの私が言えることは1つ。「エージェント開発は、もうプロだけのものじゃない」。YAMLを書いて、ブループリントを動かして、A2Aで繋ぐ。その一歩目が、今週末に踏み出せる状態になった。

“エージェンティックエンジニアリング”の概念がNVIDIAの実装基盤と結びついた。「概念」から「コードを書ける状態」への転換が起きている。凄腕エンジニアが自分に宿る感覚を、もう一段階深く味わえる時が来た。

連続特集 第3回では「Gartner予測の40%を実現するアーキテクチャ設計3パターン」を扱う予定だ。「どの基盤を選ぶか」の次に直面する「どう設計するか」の問いに答えていく。

---

---