Googleのエージェント型AIによるCPU需要、遊休コンピュートに注目集まる
Googleは、実行環境が長時間待機状態にあっても、AIエージェントが新たなCPU需要を生み出すと述べている。そのため、Googleのエージェント型AIによるCPU需要は、単にプロセッサーを追加するより難しい問題を伴う。遊休ハードウェアを確保したままにせず、永続的なソフトウェアワーカーを利用可能な状態に保つことだ。アプリケーションコードを実行する汎用プロセッサーであるCPUは、エージェントが回答の生成を超え、ソフトウェアを操作し始める際に中心的な役割を担う。
10月30日のEE Timesのインタビューで、Google Cloudの幹部Mark Lohmeyer氏は、エージェントがサービスを呼び出し、Webサイトを閲覧し、コードを実行する様子を説明した。これらの活動は、モデルの周辺に必要な計算処理を拡大する。並列計算に最適化されたプロセッサーであるGPUと、Googleの専用機械学習チップであるTPUは、依然としてモデル計算の多くを担う。一方で、その周辺アプリケーションには独自の実行能力が必要となる。
これはクラウドプラットフォームと企業のインフラチームに圧力をかける。モデル提供速度を中心に設計されたシステムでも、エージェントがワークスペースを待ち、セッション状態を失い、または不要にリソースを確保すれば、期待を裏切る可能性がある。AWSも同様の実行サービスを追求しており、購入者に競争上の比較対象を提供している。中心となる競争は、継続的に確保される環境と、非アクティブなコンピュートを解放しつつエージェントの作業を保持するインフラとの間にある。
Googleのエージェント型AIによるCPU需要はモデル提供の枠を超える
Googleの主張は、専用AIプロセッサーの代替ではなく、AIモデルを取り巻くインフラに関するものだ。
AIおよびコンピューティングインフラ担当バイスプレジデント兼ゼネラルマネージャーを務めるLohmeyer氏は、この区別についてエージェントワークロードに関する議論で説明した。EE Timesによると、エージェントはユーザーの要求を、通常のソフトウェア実行を伴うサブタスクに分解する。その結果として生じるワークロードは断続的であり、プロセッサー、ストレージ、リソース管理に異なる要件をもたらす。
重要なのは、モデルがアクションを選択した後に何が起きるかだ。もっともらしい指示を生成することと、指示された作業を完了することでは、消費するリソースが異なる。ブラウザーはページを読み込み、プログラムは実行され、アプリケーションは結果を返さなければならない。意思決定に知能を加えても、こうした処理が不要になるわけではない。
エージェントとは、目標に向けてアクションを選択し実行するためにモデルを利用するソフトウェアを指し、これらの段階をつなぐ。その有用性は、全体の一連の流れに依存する。次の実行環境が利用可能になるまで時間がかかるなら、モデルからの高速な応答の利点は限られる。
これは、モデル提供能力と並行してCPU要件に注目すべき理由を説明する。モデル提供とは、学習済みモデルを実行して出力を生成することを意味する。エージェントの全体的な実行にはこの処理も含まれるが、その周辺にあるコードやサービスも含まれる。モデルだけを測定しても、アプリケーションの一部はパフォーマンスの対象から外れてしまう。
また、このインタビューは、あらゆる場面で優位となるプロセッサーを示すものでもない。Lohmeyer氏は、Google CloudがArmベースのAxionチップとともにIntelおよびAMDのプロセッサーを使用していると説明した。Armとx86は、ソフトウェアが実行する機械命令を決めるプロセッサー命令セットのファミリーである。異なるエージェントワークロードでは、コア性能、コア数、接続ストレージの異なる組み合わせが有利になり得る。
この区別は見出しを解釈する上で重要だ。エージェントの活動が増えたからといって、すべてのCPUカテゴリーが同程度に恩恵を受けるとは限らない。プログラム実行が中心のワークロードと、外部サービスの待機が中心のワークロードは異なる。購入者は依然として、実際に稼働させる処理を理解する必要がある。
Googleのエージェントインフラは今、その主張をより具体的なものにしている。Googleは10月22日、Geminiの業務タスクをすでに支援しているサービスとしてAgent Compute Engineを発表した。この発表では、今後数カ月以内に顧客向けプレビューを提供する予定だとしている。11月1日時点で、この表現を一般提供と解釈すべきではない。
この流れは、インタビューに具体的な文脈を与える。Googleは、この問題への対応を意図した商用サービスを準備しながら、実行上の課題を説明している。そのため、そのエンジニアリング上の説明には意味がある一方、読者には文書化されたアーキテクチャと期待される顧客メリットを区別する理由もある。
インフラチームは待機コストを引き継ぐ
当面の負担は、有用な作業が断続的に発生する間もエージェント環境を利用可能に保つチームにかかる。
永続的な環境は、やり取りの合間にも作業用のデータを保持する。そこにはファイル、インストール済みソフトウェア、アプリケーション状態などが含まれる。永続性によってエージェントは長期的なタスクで役立つが、リソース管理は複雑になる。情報を利用可能に保つことと、プロセッサーを割り当て続けることは別の要件である。
リポジトリーの変更に取り組むコーディングアシスタントを考えてみよう。ファイルを読み、プログラムを実行し、モデルの出力を待ち、開発者に承認を求める。こうした停止中も、ワークスペースは引き続き重要である。しかし、同じ期間ずっとプロセッサーを確保しておく必要があるとは限らない。
これは計測された顧客環境ではなく、例示的なワークロードである。経過セッション時間が実際の実行需要を誤って示し得る理由を示している。セッションは非アクティブでも価値を保ち得る。開いているすべてのセッションを常に稼働中として扱うと、この違いが見えなくなる。
その影響はアプリケーションのビジネスモデルにも及ぶ。エージェント体験を購入する顧客が求めるのは、完了した作業と信頼できる継続性だ。インフラプロバイダーは、どれだけのハードウェアを確保するかを判断しながら、これらの成果を提供しなければならない。不適切な割り当ては、ユーザーの成果を改善せずに運用費用を増大させる可能性がある。
ここで重要になるのが、利用可能なプロセッサー能力のうち実行作業に使われる割合であるエージェントのCPU使用率だ。ただし、平均使用率の数値だけでは体験全体を説明できない。多くの待機中エージェントが同時にアクティブになったとき、プラットフォームは平均使用率が低くても苦戦する可能性がある。
これにより、相反する運用要件が生まれる。プロバイダーは効率的に容量を共有したい一方で、ユーザーは作業再開時の即時アクセスを期待する。環境を密に詰め込むことが有効なのは、システムが再び活発になる活動を処理できる場合に限られる。繁忙期の遅延は、セッションを利用可能に保つ利点を損なう可能性がある。
Googleが9月15日に示したAgent Substrateの説明は、遊休状態の実行環境と活動の急増を明示的に扱っている。同社は、エージェントの実行を基盤となるマシン管理から分離するソフトウェアを説明している。また、ワークロードが同一のセキュリティ要件を共有しないことを反映し、異なる分離アプローチも提供している。
この圧力は企業の調達にも及ぶ。容量に関する議論には、エージェントがどのように停止し、作業を保持し、再開するかを含める必要がある。プロセッサーの仕様だけでは、これらの質問に答えられない。実行の断続的な間にサービスがどのように振る舞うかが、購入される製品の一部となる。
これは社内の責任分担も変える。アプリケーションチームはエージェントフレームワークを選択し、プラットフォームチームはそのランタイム、すなわちソフトウェアを実行する環境を管理できる。どちらのチームも非アクティブなリソース割り当てを測定しなければ、不必要な消費が責任の隙間に落ち込む可能性がある。その結果としての問題は、モデル評価ではなくインフラの請求額に現れる。
開発者にとって実務上の意味は、アーキテクチャにある。長期間にわたるユーザー体験が、同じだけ長いプロセッサー予約を自動的に必要とするべきではない。プラットフォームがこれらのライフタイムを分離できるかどうかが、有用なプロトタイプをサービスへと無理なく拡張できるかを左右する。
永続的なワークスペースは継続確保型コンピュートに課題を突き付ける
中心となる設計上の問いは、エージェントが一時的に不要なハードウェアを手放しながら、作業環境を保持できるかどうかだ。
従来のアプリケーションもすでにアイドル期間を扱っており、この根本的な問題には前例がある。エージェントワークロードは、信頼できない可能性のあるコードと、個別化され継続するワークスペースを組み合わせることで、この問題を先鋭化させる。環境は中断をまたいで有用であり続ける必要がある一方、不必要な恒久的割り当てになってはならない。
microVMは、ハードウェア仮想化を用いて実行環境を分離する、簡素化された仮想マシンである。サンドボックスは、コードを封じ込めアクセスを制限するための制約付き環境を指す。エージェントプラットフォームではこれらの概念は重なり合うが、実装の仕組みとセキュリティ上の目的という、異なるものを表している。
この仕組みだけで経済性が決まるわけではない。小規模な分離マシンであっても、何もしていない間にリソースを確保し続ける可能性がある。効率性は、サービスがそのライフサイクル全体をどのように管理するかに依存する。環境の起動、停止、保存、復元、削除はすべて重要な操作となる。
実行状態を保存した表現であるスナップショットは、継続性を維持する手段を提供する。その状態を復元すれば、環境を最初から再構築せずに済む可能性がある。ただし、保存と復元にはストレージとデータ移動も関わる。ワークロードをアクティブメモリーから移すと、要件は別の場所へ移転する。
そのため、CPU計画はストレージ計画と切り離せない。環境の復元に長い遅延が生じるなら、プロセッサーを解放しても効果は限定的になる。同様に、すべてを無期限に保持すれば、ストレージの負担が増大する可能性がある。完全な設計には、アクティブな実行だけでなく、保持状態に関するポリシーも必要だ。
Googleによる永続的なエージェント環境の技術的説明では、ファイルとメモリーを保持しながら非アクティブなセッションをチェックポイントする仕組みが記されている。チェックポイントとは、復元可能な実行状態を保存することを意味する。Googleはまた、長期利用の認証情報をゲスト環境の外部に保持し、制御されたゲートウェイ経由でリクエストをルーティングすると説明している。これらは独立したセキュリティ評価ではなく、同社による設計の説明である。
より広い分析上の要点は、継続性がシステムの特性になるということだ。ユーザーはエージェントを継続中のタスクとして体験する一方、その下でインフラは異なるリソース状態を移行できる。成功する実装は、作業を失ったりアクセス制御を弱めたりせずに、こうした移行を隠蔽する。
AWSは、6月22日に発表したLambda MicroVMsを通じて有用な比較対象を提供している。AWSは、ユーザー作成またはAI生成コード向けの分離環境を説明し、直接的なライフサイクル制御と状態保持を提供している。その実装は、同社の軽量仮想化技術であるFirecrackerを基盤とする。
この比較は、共通するインフラ課題の存在を裏付ける。ただし、GoogleとAWSのサービスが同等の性能を持つこと、同一のワークロードをサポートすること、あるいは等しい運用上の制約を課すことを示すものではない。公開された説明は、完成された比較ではなく、評価の出発点を提供する。
したがって、Googleのエージェント向けインフラは、実行環境の管理をエージェントアプリケーションの一部として捉える、より大きな移行の中に位置づけられる。重要な競争は、どのプロバイダーがより多くのプロセッサコアを提供するかだけではない。有用な作業を保持し、再開された活動を処理し、リソース消費を理解しやすくするサービスがどれかという点にある。
買い手にとって、この違いは評価すべき問いを変える。空の環境がどれほど速く起動するかを尋ねるだけでは不十分だ。より示唆的なのは、依存関係と保持された作業を含む実際のワークスペースが、中断後にどのようにサービスへ復帰するかという問いである。
エージェント密度の向上はCPU需要予測を裏付けない
追加のCPU処理が必要になるもっともらしい説明と、市場がどれほど追加ハードウェアを必要とするかを示す証拠は異なる。
Googleのエージェント型AIにおけるCPU需要には、相反する力が働く。エージェントタスクが増えれば、実行処理も増加する。一方で、リソース共有の改善は、一定数のエージェントを支えるために必要なハードウェアを減らす。最終的な結果は、導入状況、ワークロードの強度、インフラ改善の有効性に左右される。
Google自身のエンジニアリング資料は、この区別が重要である理由を示している。7月30日のエージェント密度ベンチマークで、同社は固定されたマシン構成上でOpenClawワークロードをテストした。実行とリソース管理の変更によって、より多くのエージェントをサポートできたと報告している。これらの結果は、特定のワークロードと設定に関するものである。
これを本番環境への展開全般に適用できる倍率として扱うべきではない。エージェントごとに保持するメモリ量、実行するソフトウェア、待機時間は異なる。セキュリティ設定も、アプリケーションが利用できるリソースに影響する。密度に関する結果は、意味を保つためにその前提条件を伴う必要がある。
同じ注意は逆方向にも当てはまる。CPU処理の拡大予測があっても、すべてのエージェントでプロセッサが制約要因になるとは限らない。一部のアプリケーションは、モデルの応答を待つ時間のほうが長い。他のアプリケーションでは、外部サービスの制限やストレージ遅延に直面する可能性がある。
したがって、エージェントのCPU使用率は、より広範な測定指標の一部として有用である。高い数値は生産的な実行を示す場合がある一方、競合やタスク遅延を伴うこともある。低い数値は無駄を示す場合もあるが、意図的な予備容量を反映していることもある。解釈には、アプリケーションの性能および信頼性データが必要となる。
商業上の単位も重要である。起動したエージェント数を数えると、ほとんど有用な作業を完了していないサービスを実態以上によく見せる可能性がある。アクティブセッション数を数えると、繰り返される失敗や放棄されたタスクが見えにくくなる。完了し、受け入れられた成果は、インフラ改善が顧客に利益をもたらすかを評価するための、より厳しい基準となる。
「エージェント」という言葉にも別の不確実性がある。短時間のコード実行リクエストと継続的なブラウザワークスペースは、どちらもその名称で呼ばれうる。両者では、プロセッサと永続性に関する要件が異なる。それらを区別のない需要カテゴリに集約すると、実際のリソース要件を決めるワークロード構成が見えなくなる。
このため、CPUをめぐる議論では、あるアーキテクチャを勝者と断定すべきではない。Intel、AMD、Armベースの設計は、より広範なサービス構成の中で競争している。ソフトウェア互換性、メモリ容量、ストレージアクセスは、プロセッサの実行速度と並んで結果に影響しうる。アプリケーションレベルの比較では、成功基準を一貫させる必要がある。
裏付けられる最も強い結論は、市場予測よりも限定的である。Googleは、通常の実行処理をエージェントサービスの重要な構成要素として特定している。同社の製品方針は、継続的なセッションと断続的な活動の間にある隔たりに対応するものだ。そこから生じるハードウェア需要の規模は、依然として実証的に検証すべき問題である。
これは、導入拡大と効率改善の両方が起こる余地を残す。より多くのワークフローでエージェントが有用になれば、リソース共有が改善されても総実行量は拡大しうる。導入が期待を下回れば、インフラ改善だけで持続的な需要は生まれない。技術的な仕組みは機会を説明するが、その最終的な規模を立証するものではない。
分離は利用効率向上の要求に耐えなければならない
アイドル状態のリソースを回収することは、プラットフォームが顧客に必要なセキュリティ境界と作業状態を維持できる場合にのみ価値を生む。
エージェントは、モデル出力や外部情報の影響を受けたコードを実行する可能性がある。これは、アプリケーション開発者が作成・レビューしたソフトウェアだけを実行する場合とは異なる信頼関係を生む。ランタイムは、運用者が明示的に作成していないアクションを考慮しなければならない。
分離は、実行環境が到達できる範囲を制限する。認可は、IDに許可されるアクションを決定する。これらの制御は関連しているが、異なる問題を解決する。分離された環境でも、システムから正当に付与されたアクセス権を悪用する可能性はある。
この区別は、よくあるカテゴリ上の誤りを防ぐ。安全な実行境界があっても、エージェントがリクエストを正しく理解していることは保証されない。また、許可されたすべてのアクションがユーザーの意図に沿うことも保証しない。インフラ制御は実行を封じ込め、アプリケーション制御はタスクを統制する。
効率に関する議論では、両方の層を維持しなければならない。共有ハードウェアにより多くの作業を集約するほど、信頼できる分離の重要性は増す。セッションを保持するなら、保持データとアクセス期限に関する問題も生じる。ワークスペースの再開によって、もはや適切でない権限が暗黙のうちに復元されるべきではない。
社内文書を読み、ブリーフィングを作成する企業向けリサーチエージェントを考えてみよう。エージェントには進捗を保持するために十分な継続性が必要である。しかし、そのアクセス権は現在のユーザー権限を反映し続けなければならない。保存されたワークスペースと認可判断を、交換可能な記録として扱うべきではない。
この例は、インフラ設計と情報品質も結び付ける。プロセスを保持することが役立つのは、システムが適切なソースと作業資料を保持する場合に限られる。検索可能なナレッジベースを構築するチームも、継続中の作業全体で技術的な証拠を検索・参照可能な状態に保つという、関連する組織的課題に直面している。この懸念は、ランタイムの永続性を補完するが、それに置き換わるものではない。
運用上のレジリエンスにも同等の注意が必要である。通常条件下で正しく再開する環境でも、書き込みの中断や接続障害の後には異なる動作をする可能性がある。買い手は、停止後に何が残り、アプリケーションが何を再作成しなければならないかを理解する必要がある。そうでなければ、見かけ上の継続性が不完全な復旧を隠してしまう可能性がある。
同じ原則はクリーンアップにも当てはまる。作業を停止したエージェントは、明示的な保持ポリシーに従って最終的にリソースを解放すべきである。すべてを無期限に保持すると不要な責務が生じる。削除を急ぎすぎれば、インフラが支えるために構築された継続的な体験を損なう。
これらは、基盤となる設計を退けることなく、Googleの主張を慎重に検討すべき理由である。企業のドキュメントは、意図された境界と動作を説明する。独立したテストと運用経験は、それらの機能が実際のアプリケーション条件下でどのように動作するかを明らかにする。どちらかをもう一方の代わりに用いるべきではない。
購入における示唆は具体的だ。分離、継続性、リソース効率を一体として評価すること。ある次元を最適化しながら他の次元を不明確なままにするサービスは、インフラ全体の問題を解決しない。重要な成果は、許容可能なセキュリティと運用モデルの範囲内で有用な作業を提供することである。
次の証拠はアクセス、ワークロード、成果から得られるべきだ
この話の次の段階は、エージェントにCPUが必要だという追加の主張ではなく、顧客から見える実行動作にかかっている。
最初のシグナルは、Agent Compute Engineへの実用的なアクセスである。Googleの10月の発表は、今後数か月におけるプレビュー提供を示唆している。今後数か月で公開されるアクセス条件、対応構成、運用上の制限により、顧客がそのアーキテクチャをどのように評価できるかが明らかになるだろう。
プレビューは、議論を観測可能なサービス動作へ移すことで、この見解を強めるだろう。限定的なアクセスでも有用な証拠は得られるが、比較には制約がある。ドキュメントは、読者がGoogle社内での利用に関する説明から推測せずに済むよう、これらの境界を明確にすべきである。
2つ目のシグナルは、代表的なワークロードのテストである。有用な比較には、同一タスク内でのアクティブな実行、待機、中断、復旧を含めるべきだ。起動は速くても再開が不十分な環境は、一貫した継続性を提供しない。同様に、遷移を繰り返すことで作業が中断されるなら、効率的なアイドル状態の重要性は下がる。
このようなテストでは、ワークロードとその周辺条件を開示すべきである。メモリ要件、保持ファイル、同時実行性、分離設定はいずれも解釈に影響する。AWSやその他の関連する実行サービスを、同等のアプリケーション要件のもとで含めることで、比較の情報価値は高まる。
リソース管理の改善が完了率と応答性を維持するなら、この証拠はGoogleの主張を強めるだろう。節約のために許容できない遅延や、より狭いアプリケーション互換性が必要になるなら、商業的な根拠は弱まる。いずれの結果も、単独のプロセッサベンチマークより多くの情報をもたらす。
3つ目のシグナルは、完了した作業に関する顧客報告である。企業導入の事例は、モデル選定後も実行インフラが重要な制約であり続けるかを明らかにできる。また、永続的な環境が、運用上の複雑さを正当化するほどタスク完了を改善するかも示しうる。
そうした報告では、モデルの問題とランタイムの問題を区別すべきである。誤ったアクションを選ぶエージェントの失敗と、再開できない環境の失敗は異なる。両方を単一の成功指標にまとめると、インフラを評価しにくくなる。分離することで、どの改善が重要なのかを買い手が理解しやすくなる。
これらのシグナルが揃えば、Googleのエージェント型AIにおけるCPU需要は評価しやすくなる。サービスへのアクセスは顧客が利用できるものを示す。代表的なテストは実行がどのように振る舞うかを示す。顧客成果は、結果として生じるシステムが継続的な展開を支えるだけの価値を生むかを示す。
現時点で、この報道は重点の明確な変化を裏付けている。エージェントアプリケーションには、その実行が停止している期間も含め、モデルを取り巻くソフトウェア実行への注意が必要である。CPUはその作業に不可欠であり続ける一方、永続性とリソース管理が、プラットフォームがそれをどれほど効率的に提供できるかを決める。
まず、自組織が実際にエージェントに完了させたいワークフローから始める。どの段階でコードを実行し、どの段階で待機し、どの段階でファイルまたは権限の保持が必要かを特定する。候補となるプロバイダーに対し、同じタスクと受け入れ基準を使って、それらの遷移を実演するよう求める。評価の焦点を、完了した作業、復旧可能な状態、理解しやすいリソース消費に置く。このアプローチにより、開発者と買い手は、新サービスが利用可能になるにつれてGoogleの主張を実践的に評価できる。重要なのは、幅広いCPU需要予測を受け入れることではなく、プラットフォームが継続的なエージェント体験を経済的に支えられるかを確認することだ。エージェントに何もすることがないとき、そのコンピュータでは何が起きるのだろうか。
