エンジニアは数百のAIエージェントを率いるのか NVIDIAの予測と現実の課題

NVIDIAのジェンスン・フアンCEOは、ソフトウェアエンジニアが数百ものAIエージェントを管理するようになると見ています。エンジニアはコードを1行ずつ自分で書くのではなく、仕事を割り振り、その結果を判断する役割を担うという見立てです。これはあくまで将来の予測であり、現在の平均的なエンジニアの仕事を表したものではありません。既存のエージェントツールはすでにソフトウェアをまたいでタスクをこなせますが、その成果を信頼できるものにするには、事前の準備、的確な指示、人によるレビューが今も欠かせません。

コードを書く仕事から、仕事を指揮する役割へ

フアン氏が描くワークフローでは、エンジニアがアーキテクチャを定め、仕様を書き、プロジェクトをタスクに分け、品質基準を設定します。エージェントは任された作業をこなし、エンジニアは各部分が計画に合っているかを確認します。変化の本質はエンジニアを不要にすることではなく、エンジニアが注意を向ける先が変わることにあります。つまり、アイデア、ツール同士のつなぎ方、そして完成した成果物に対する判断です。

フアン氏は、組織がエンジニア1人にどれだけのAIコンピューティングを割り当て得るかを示すため、年間予算の仮定を用いています。トークンとはAIモデルが処理するテキストの単位で、トークンへの支出はそのコンピューティングの対価を払う方法の一つです。

これらはフアン氏のシナリオ上の数字であり、あらゆるエンジニアリングチームに必要だと実証された予算ではありません。同氏のより大きな主張は、エージェント向けのコンピューティングが潤沢になれば、実現できそうだと考えられるプロジェクトの範囲が変わり得るというものです。ただ実際には、コンピューティングを増やすだけでは、しっかりした仕様も、成果物を評価する確かな方法も手に入りません。

▲ タスクの委任と結果の確認

現在のエージェントが示すこと、示さないこと

OpenClawは、AIアシスタントを日常業務につなぐ既存の方法の一例です。macOS、Windows、Linuxで動くオープンソースのローカル型アシスタントで、セッションをまたいで記憶を保持し、メッセージングサービスとも連携します。OSを操作してファイル、フォーム、コマンド、複数ステップのタスクを扱うこともできます。こうした機能は、エージェントがチャット画面の外で行動できることを示しています。しかし、数百のエージェントが監督なしで複雑なエンジニアリングプロジェクトを回せることを裏付けるものではありません。

ある起業家は、Claudeとエージェントを使い、企業向けソフトウェアスタックとそれに伴う業務を90分のセッションで置き換えたと語っています。とはいえ、実行時間はこうしたプロジェクトの一部にすぎません。データの準備、API(アプリケーション・プログラミング・インターフェース)の設定、そしてデータを移動・加工する仕組みであるパイプライン基盤の構築には、自動実行を始める前に数週間から数か月かかることがあります。さらに開発者は、本番環境で使える状態にするまでに、指示を練り直し、反復の待ち時間に耐え、エッジケースをデバッグし、生成されたコードを修正する必要があるかもしれません。

エージェントの導入を検討するチームにとって役立つのは、自動タスクの実行にかかる時間と、そのタスクを可能にし、結果を確認するまでにかかる時間を区別する視点です。短い実行時間を、エンジニアリング作業の全体像と取り違えてはいけません。

使い慣れたソフトウェアがレビューの場になる

フアン氏は、エージェントは既存のソフトウェアを置き換えるのではなく、むしろその利用を増やす可能性があると主張しています。現在、多くのツールの利用頻度は人間のユーザー数に縛られていますが、エージェントの群れが人に代わってデータベースに問い合わせたり、設計アプリケーションの中で作業したりできるようになります。こうしたソフトウェア利用の拡大はあくまで予測です。エンジニアリング上の目下の課題は、人がすでに使っているツールにエージェントをどうつなぎ、戻ってきた成果物をどう検査するかです。

例えば、設計作業を担うエージェントが専門アプリケーションを使い、エンジニアがその同じ場所で結果をレビューする、という形が考えられます。フアン氏は、Synopsys、Cadence、Blenderといったツールを、エージェントの成果物が既存の専門的なワークフローと出合う場として挙げています。データベースへの問い合わせに使う言語であるSQLも、エージェントが既存の情報を扱うもう一つの経路になります。

Model Context Protocol(MCP)は、AIモデルを外部ツールにつなぐための仕組みです。Blender、Unreal Engine、Godot、Unityとの連携は、エージェントが使い慣れた作業環境の中で3Dアセットや環境を作成・変更する方向を示しています。重要なのは、生成された結果をプロジェクトの要件に照らして検査できる人に、最終的に引き渡すことです。

▲ 設計環境でのレビュー

ツールを軸にワークフローを組み立てる

モデルの選択は、このシステムの一部にすぎません。汎用的なタスクにはプロプライエタリなモデルが使える一方、重みが公開され他者が利用・調整できるオープンウェイトモデルは、専門的な作業に向けたもう一つの選択肢になります。ルーティングの仕組みを使えば、タスクごとに異なるモデルへ振り分けることもできます。長時間動くバックグラウンドのエージェントは、GitHub Actionsの実行時間や専用ハードウェアといったサーバー資源を使えますが、その基盤にもテストと監督が必要です。

現実的な出発点は、エージェントの目標数ではなく、明確に定義されたタスクです。アーキテクチャと成功基準を定め、データとツールの接続を準備し、そのうえで反復のための時間を確保しましょう。成果物は、実際にその仕事が使われるアプリケーションの中でレビューします。フアン氏のビジョンは、エンジニアがはるかに多くの自動化された作業を調整する未来を指しています。今日のツールでそのビジョンの一部はすでに実現できますが、方向づけと品質に対する責任は引き続きエンジニアにあります。