こんにちは、ネットワールドの海野です。
3月27日(金)に弊社主催の Web セミナーで NVIDIA GTC 2026 についてお話をさせていただきました。
多くの皆様にご参加いただきまして、感謝申し上げます。ありがとうございました。
さて、前回の記事では GTC 2026 で参加した「Open Models: Where We Are and Where We're Headed [S82480]」をもとに、「AI = LLM」という見方だけではもう最近の流れを追い切れなくなってきた、という話をお伝えしました。
OpenClaw、オープンモデル、そしてそれらを現実に回すためのハーネスエンジニアリング。前回はそこまで追ってきたのですが、読み返してみると「では、その先のエージェントは実際に何でできているのか」という肝心の部分が少し宙に浮いているかもしれません。
そこで今回は、GTC 最終日に聴講した「Agentic AI 101 [S82432]」をもとに、その続きとして記事にしてみます。タイトルは 101 とありますが、単なる入門ではなく、GTC 全体を理解するためのセッションでした。
オンデマンド視聴はこちらです。
今回のテーマ
このセッションを通じて私がいちばん腹落ちしたのは AI エージェントは、高性能なモデルをひとつ置けば成立するものではない ということです。
必要なのは Memory、複数モデルの役割分担、Skills & Tools、データアクセス、そしてそれらをつないで回すオーケストレーションです。要するに、主役は「モデル単体」ではなく「役割分担されたシステム」でした。
これを踏まえると GTC で取り上げられたトピックが一本の線でつながって見えてくるのではないでしょうか。
1. 「Agentic AI 101」は何の入門だったのか
セッションの冒頭で強く感じたのは、これは「エージェントとは何か」の定義だけを話す場ではない、ということでした。むしろここ数年の AI の変化を踏まえて、なぜいま、エージェントという形が必要になっているのかを理解するための基礎、という位置付けだったように思えます。
チャット型の AI が急速に一般化し、質問に答えるだけならとても自然に応答できるようになりました。その次の段階として、最近は「答える」だけではなく「実際に作業する」方向に軸足が移っています。OpenClaw のようなソリューションが象徴的ですが、コードを書き、情報を集め、ツールを呼び、途中で方針を変える、といった一連の流れを AI が持ち始めています。
個人的には、このセッションは GTC の中で出てきた Agentic AI という言葉を、ふわっとした流行語のままにしないためのセッションだったと捉えています。
2. チャットボットとエージェントは何が違うのか
ここはかなり分かりやすく解説されていました。
シンプルなチャットボットは、聞かれたことに素早く返すのが得意です。「今日の天気は？」のような問いに対して、10 分後に長いレポートが返ってきても困るわけで、こういう場面では速くて軽い応答が正義です。
一方で、推論型のチャットボットになると、少し複雑な問題を分解しながら答えを組み立てることができます。ただ、それでも基本は「問いに答える」までです。
その先にある AI エージェントは、目標に向かって複数ステップで動きます。必要ならツールを使い、途中で結果を見直し、次の行動を決める。さらに一段進むと、複数のエージェントが協力するマルチエージェント構成や、自分に足りない能力をスキルなどで補いながら作業する形態もあり得ます。スキルについては後述します。
ざっくり表にすると、違いは以下のように表現できます。
| チャットボット | AI エージェント | |
|---|---|---|
| 基本動作 | 質問に答える | 目標に向けて動く |
| 処理単位 | 1ターン中心 | 複数ステップ |
| 外部連携 | 限定的 | ツールや API を積極利用 |
| 判断 | 応答生成が中心 | 計画、再評価、方針変更を含む |
| 終了条件 | 人が会話を止める | タスク完了を見ながら進む |
前回の記事で触れたハーネスエンジニアリングという言い方は、まさにこの差を表しているのだと思います。モデルの賢さそのものより、どうつなぎ、どう走らせるかがテーマになってきています。
3. エージェントを成り立たせる4つの主要コンポーネント
セッションでは、エージェントの中身をいくつかのコンポーネントに分けて説明していました。ここが今回いちばん興味深いポイントでした。
Memory
エージェントは、その場限りの応答だけで完結しません。会話履歴や過去の文脈、場合によっては画像や文書から得た情報も含めて、継続的に扱う必要があります。
最近のエージェント体験が「少し前に話したことを覚えている」方向に進んでいるのは、この Memory が前提になっているからです。単に便利というだけではなく、パーソナライズや継続タスクの品質を支える土台でもあります。
System of Models
ここも重要でした。エージェントの中に、何でもひとつの巨大モデルだけを置けばよいわけではありません。
音声理解が得意なモデル、意図判定に向くモデル、画像やチャートを読むモデル、重い推論に向くモデル。こうした異なる役割のモデルを組み合わせたほうが、精度、速度、コストのバランスがよくなる、という知見が共有されていました。
個人的にはこの話はかなり現実的だと感じました。全部を ChaatGPT や Claude のようなフロンティアモデルで押し切るより、重い判断が必要なところだけ大きいモデルを使い、周辺は小さく速いモデルに分担させるほうがコストの観点でもエンタープライズでは有効な場面が出てくるはずです。
(とは言え、私はまだ GPT-5.4-Codex でしか試せていませんが。)
Skills & Tools
このセッションでは、スキルとツールを分けて考えるというフレーズも印象的でした。
スキルは「何が得意か」です。要約が得意、特定領域の理解が深い、ある形式の文章生成がうまい、といった能力です。
一方でツールは「何に触れられるか」です。API、CLI、検索、ドキュメント、場合によっては GUI 操作まで含まれます。人間がブラウザをクリックして情報を取りにいくように、エージェントも UI を操作できる、という話は個人的に非常に興味深く感じました。
Data Access
最後はデータアクセスです。構造化データだけでなく、PDF やドキュメントのような非構造化データも扱えないと、エージェントは現場で使える知識を持てません。
RAG が引き続き重要なのもここが理由です。外の一般知識だけでなく、組織固有の知識や手元の情報にアクセスできるようになって、初めて「その現場で使える」エージェントになります。
NeMo、NIM、Nemotron といった NVIDIA の各レイヤーをこの観点で見直すと、モデル単体というより、エージェントを作るためのコンポーネントとして配置されていることが分かりやすくなるのではないでしょうか。
4. Deep Research Agent が示していた実装パターン
セッションの中で具体例として紹介されていたのが、Deep Research Agent 的な構成でした。ここで「エージェントがエージェントを使う」とはどういうことが、非常に見えやすくなりました。個人的にも以前からふわっと抱えていた疑問が解消された部分でもあります。
まず、ユーザーの問い合わせはそのまま 1 つのモデルに投げ込まれるわけではありません。簡単な問いなら軽く返す。重い問いなら深い調査フローに回す。最初にルーティングが入ります。
そのうえで、指揮役となるオーケストレータが、必要な作業を複数の Worker に振り分けます。Web を見に行く役、ローカルデータを見る役、画像や文書を読む役など、それぞれが専門を持って動き、結果を持ち帰る。この流れは、いわゆるマルチエージェント構成のかなり分かりやすい例でした。
重要なのはここでも「ひとつの万能モデル」ではなく、役割ごとに向いた構成を選んでいることです。GTC 全体で見えていた設計思想が、この Deep Research 系の例でそのまま具体化されていたように感じました。
NVIDIA は build.nvidia.com やブログで Blueprint を継続的に公開していますが、こうした research / agent 系の実装例を見ると、「まずは参考実装として全体像を学び、必要なパーツだけ自分の構成に取り込む」という使い方がしやすいように示されています。このあたりも単なるデモではなく、実際に手を動かす人を意識しているような印象です。
5. 個人用エージェントは、もう「未来の話」ではない
後半で面白かったのは、企業向けの話だけでなく、個人用エージェントの話までちゃんと降りてきたことです。
Build-a-Claw の分かりやすさ
GTC 会場では Build-a-Claw という体験型の取り組みも紹介されていました。NemoClaw や Build a Claw といった導線が前面に出ていて、エージェントを「開発者やマニアだけのもの」にしない意図が感じられます。
個人的には、ここは NVIDIA のうまいところだと思いました。難しいアーキテクチャの話をする一方で、「まず自分のエージェントを作ってみる」という入口も用意しているわけです。雰囲気だけで終わらせないぞ、という姿勢が見えます。(現場で DGX Spark も販売してくれたら買うひともいたんじゃないかなｗ)
DGX Spark とローカルエージェント
さらに DGX Spark 上で自分専用のエージェントを常時動かす、という話もかなり具体的でした。ローカルに近い場所で手元のデータや自分向けの作業・コンテキストを扱える環境を持つことで、パーソナルエージェントの実用性はかなり上がります。
ここで重要なのは、「ローカルで動くからすべて安心」という単純な話ではないことです。何にアクセスさせるのか、どこまで権限を渡すのか、どの順番で任せるのか。この設計がむしろ本題です。
権限はベイビーステップで渡す
セッションでは、メールやファイルへのアクセスをいきなり全面開放するのではなく、専用のメールアドレスや読み取り専用アクセスから始める、という考え方も紹介されていました。
この感覚はかなり大事だと思います。エージェント導入の論点は「賢いかどうか」だけではなく、「どの権限をどの順番で渡すか」に移っています。企業導入でも個人利用でも、最初からフル権限で任せるより、段階的に広げるほうが現実的です。
6. まとめ
今回の「Agentic AI 101」を通じて理解できたのは、Agentic AI の本質は高性能モデル競争だけではない、ということでした。
Memory、System of Models、Skills & Tools、Data Access、そしてオーケストレーション。この組み合わせがあって初めて、エージェントは「計画し、行動し、継続し、完了を判断する」存在になります。
GTC のキーノートで語られていた AI Factory という話も、見方を変えるとかなり近い構図です。GPU やモデルが重要なのはもちろんですが、最終的に差が出るのは、それらをどう束ねてシステムとして成立させるかです。
私としては、このセッションは「エージェント時代の基礎講座」というより、「いま何を設計対象として見るべきか」を教えてくれるセッションでした。モデル単体を見る時代から、役割分担された AI システム全体を見る時代へ。GTC 2026 のメッセージは、それを示唆しているのではないでしょうか。
関連する前回記事はこちらです。
今回のセッション自体はオンデマンドでも追えるので、気になる方は冒頭でご紹介した URL をあわせてご覧ください。(いまのところYouTubeでは見れないようですが。)
特に「チャットボットの延長としてエージェントを見る」のではなく、「複数の役割が連携するシステムとして見る」という視点で見ると、GTC 全体の話がかなり理解しやすくなるはずです。
7. あとがき
ホントは現地で投稿したかったです；；
フィードバックセミナーご参加ありがとうございました。
アーカイブ配信もする予定と聞いています。公開されましたらぜひご覧ください。
