ソフトウェアが世界を飲み込み始めると言われてから10年以上が経ち、今度はAIがソフトウェアを食い尽くそうとしています。AIは、人間社会における役割や人類への貢献のあり方など、ソフトウェアの本質そのものを変容させつつあります。この変化による影響は計り知れず、人々の活動のほぼすべての側面に波及しています。本記事では、インフラストラクチャ、とりわけ「クラウド」にもたらされる影響に焦点を当てます。
AIがソフトウェアを貪り食う時代に、クラウドはその「最後の一皿」となってしまうのでしょうか。
端的に言えば、答えは「イエス」です。ただし、AIがクラウドを消滅させるからではありません。AIがクラウドを劇的かつ不可逆的に変容させるからです。具体的には、大規模言語モデル（LLM）、画像・動画生成モデル、そしてそれらを自律型エージェント内でオーケストレーションする生成AI（GenAI）こそが、クラウドインフラにとって最も重大な意味を持つAIの形です。
生成AIは、電力を食う、計算能力を食う、そしてストレージを食う、と膨大なリソースを必要とすることは誰もが知っています。AIが私たちのあらゆる行動の一部となる中で、この「大食漢」の食欲をどう満たせばよいのでしょうか。
現在の主流なアプローチは、莫大な資金を投じて、巨大なAIモデルをホストする大規模な集中型データセンターを構築するというものです。しかし、この力技のアプローチは経済的に持続不可能であり、環境にも大きな影響を与えます。さらに致命的なことに、差し迫る需要を満たすアーキテクチャの拡張性がありません。
私たちは、新たな「World Wide Wait」を受け入れるわけにはいきません。業界は、超集中型インフラという幻想から脱却する必要があります。ユースケースに適したインフラを選び、技術を最適化し、エージェントが実際に動作する場所に合わせて処理能力を提供しなければなりません。クラウドは適応し、分散し、進化する必要があります。
幸いなことに、この課題にはより良い解決策があります。力技ではなく、インテリジェンスをもって解決する道です。
ウェブ黎明期の失敗から学ぶべき教訓
1998年、World Wide Web（ウェブ）がインターネットを飲み込みつつありました。それまでのインターネットの用途は、主に電子メール、Telnet（リモートアクセスプロトコル）、FTP（ファイル転送プロトコル）、Usenet（現在のforumsやSubredditに似たトピック別の掲示板）程度でした。ストリーミングメディアやライブのビデオ会議、オンラインショッピング、旅行の予約、ネットバンキング、オンライン診療などは存在しません。
そのため、インターネットを利用するのは、ほとんどが学術機関やコンピューターサイエンティスト、軍や政府関係者に限られていました。しかし、ウェブがそのすべてを変えました。現在私たちが毎日利用しているウェブ機能の中には登場まで時間がかかったものもありますが、ウェブが利用可能になってからわずか7年後の1998年にはウェブサイトが雨後の筍のように出現し、誰もが注目するようになりました。
初期ウェブが直面した集中型モデルの限界
その爆発的な成功は膨大な需要を生み出しました。しかし、それが結果的に広く知られるシステム障害を引き起こし、WWWは「World Wide Wait」の略だと揶揄されるようになりました。一部の専門家は、ウェブがインターネットを崩壊させるとまで予測しました。
問題は、ウェブサイトが集中型のハブ＆スポークモデルで構築および展開されており、すべてのユーザーリクエストを遠く離れた中央のオリジンサーバーまでルーティングしなければならないことでした。力技の解決策、つまり大量の集中型インフラを構築することは莫大なコストがかかります。しかも、それでうまくいく保証すらありませんでした。
そこで立ち上がったのが、Tom Leighton教授と彼の研究室の大学院生Danny Lewinであり、彼らはAkamai Technologiesを設立しました。彼らは力技の解決策に代わるものとして、数学、アルゴリズム、分散システムを用いたインテリジェントなソリューションを提案しました。
そのソリューションは現在コンテンツ・デリバリー・ネットワーク（CDN）として知られており、ストレージと処理能力をインターネットのエッジに分散させます。これにより、ウェブアプリケーションを、それらを利用する人、デバイス、モノの近くから配信できるようになりました。
それから約10年後、Akamaiはこれと同じインテリジェントなアプローチをサイバーセキュリティの課題にも適用し、成功を収めました。後知恵ではありますが、力技ではこれらの問題を決して解決できなかったと断言できます。
そして現在。ウェブがインターネットを変えたのと同じ、あるいはそれ以上に根本的にAIがウェブを変革しつつあります。それなのになぜ、力技が解決策になり得るでしょうか。巨大なAIモデルをホストする大規模な集中型データセンターへの莫大な投資が、どうして答えになるのでしょうか。
どれだけ巨額の資金を投じたところで、地理的な距離という制約は消えず、通信遅延という物理法則をお金で解決することはできません。生成AIモデルを呼び出すたびに、ネットワーク上で数千キロの距離を通信し、さらにAIモデル内の何兆ものパラメータを処理しなければならないとしたら、その結果は「World Wide Wait」よりもさらに悲惨なものになるでしょう。必然的に、私たちが警告してきた構造的な停滞、すなわち「Large Language Molasses（大規模言語モデルによる動作の極端な遅延）」に陥ることになります。しかし、これは私たちが賢明な選択をすれば避けることができる課題です。
生成AIの真の価値は「ツール」にある
私たちの多くにとって、生成AIとの最初の接点はChatGPTのようなチャットボットでした。これはLLMの上にシンプルなチャットインターフェースを被せたものに過ぎませんでしたが、歴史上の他のイノベーションには見られないほど人々の想像力を掻き立てました。それはほんの数年前の出来事ですが、生成AIはすでにチャットボットの領域をはるかに超えています。私たちは、「AIそのものがアプリケーションである」状態から、「AIがアプリケーションを駆動する」状態へと急速に移行しました。
AIがアプリケーションの一部に組み込まれると、自律型の「AIエージェント」が生まれます。エージェントはコードを書き、リサーチを行い、メールを要約して返信の下書きを作成します。素晴らしいレストランを探してディナーの予約してくれます。旅行を計画し、ホテルや航空券、レンタカーを手配し、レンタカーセンターからホテルまでの経路を道なりに案内してくれます。さらに、お気に入りのパンツに合う素敵なシャツを選ぶ手助けまでしてくれます。
今日、私たちがウェブページを操作し、フォームに入力し、リンクをクリックして行っているほぼすべての作業は、エージェントに置き換え可能であり、実際に置き換えられていくでしょう。
AIエージェントを構成する要素を分解して考える
しかし、AIエージェントは、高度な推論能力を備えた単なる超強力なLLMではありません。エージェントは多くのコンポーネントからなるシステムであり、LLMはその1つに過ぎません。通常、LLMは中心的な役割を果たし、自然言語によるコミュニケーションを管理し、会話を導き手順を決めるための意思決定を行います。しかし、AIエージェントは他の多くのAIモデルを搭載している場合もあります。
たとえば、ファッションコンサルタントのAIエージェントなら、画像生成や動画生成を利用して、服を着たときのイメージを見せてくれるかもしれません。また、エージェントはツール（非AIコンポーネント）を備えており、これによってウェブ検索、ファイルの読み書き、コマンドラインでのプログラム実行、APIの呼び出しを行います。先ほどのファッション用のAIエージェントであれば、ツールを使ってユーザーの過去の購入履歴や好みにアクセスし、最近買ったパンツに合うお気に入りカラーのシャツを提案してくれます。
アーキテクチャのインテリジェンスは、ある明確なルールを示しています。それは、「AIエージェントを構築する際、非AIのツールにできる限り多くの機能を持たせるべきだ」ということです。私たちは、「何にでもAIを使おう」という発想を捨てる必要があります。現代のAIは非常に強力ですが万能ではありません。また、できることであっても実はAIに任せると著しく非効率になることがほとんどです。
算術計算を例に考えてみましょう。LLMが計算問題に対して正しい答えを出せること自体は驚異的ですが、時には間違えることもあります。さらに、正しい答えを出せた場合でも、電卓に比べて何桁も多くのコンピュートリソースと電力を消費しています。
他の例も同様です。正規表現で完全に機能するテキスト検索に1兆パラメータのモデルは必要ありませんし、すでに最適化されている最短経路アルゴリズムで済むルート案内にディープラーニングを使う必要もありません。
これこそが、現代の生成AIの真のスーパーパワーです。つまり、LLMはツールを呼び出して使えるのです。もしそれができなければ、業界は「Agentic」という言葉を知らないまま過ごしていたでしょう。私たちはLLMに必要なツールを与え、LLMにしかできないことだけに専念させるべきです。ミリワットで解決できる問題にメガワットもの電力を浪費するのはもうやめなければなりません。
AIインフラにおけるコンピュートリソースのミスマッチ
インフラに関して言えば、消費電力をメガワットからミリワットへと最適化すべく、インフラをユースケースに賢く適合させる必要があります。昨今のAIブームは、高密度な巨大GPUクラスターで巨大なモデルをホストする大規模な集中型データセンターへの巨額の投資を煽っています。
近年のクラウド投資はGPUに集中しており、AI向けGPUインフラにほぼ特化した「ネオクラウド（neo-cloud）」と呼ばれる新しいタイプのクラウドさえ登場しています。しかし、すべての処理に高密度なGPUクラスターが必要なわけではありません。
高密度GPUクラスターが理にかなっていたのは、主なAIユースケースがトレーニング（学習）、特に基盤モデルの事前学習であり、現在でもその用途には適しています。もちろん、これは今日の生成AIで起きているすべての出来事の前提条件であり、今後もそうあり続けます。
では、モデルを実際に使用するフェーズ、いわゆる「推論（Inference）」についてはどうでしょうか。これこそがAIの現実世界における価値を実現する方法です。しかし、推論の多くのユースケースにとって、高密度で集中型のGPUクラスターはアーキテクチャ的にミスマッチです。
たしかに、巨大な生成AIモデルで推論を行う場合、高密度GPUクラスターが最も効率的であり、許容できるパフォーマンスを得る唯一の手段かもしれません。しかし、すべてのワークロードに巨大なモデルが必要なわけではありません。多くのワークロードは、「何でも答えてくれる」汎用モデルよりも、はるかに小規模で特化型のモデルを用いたほうが最適に機能します。
たとえば、車内でエアコンやエンターテインメントシステムを管理するAIアプリケーションに、理論物理学を理解する能力は必要ありません。同様に、患者の歯科予約をサポートすることだけを目的としてクラウド上で稼働するAIエージェントに、ソネットを創作したり、テレビドラマの全エピソードのあらすじを要約したりする機能は無用です。
こうした限定的なタスクに1兆パラメータのモデルを使用するのは、極めて無駄が多いと言えます。より安価なGPU、あるいは標準的なCPUでも効率的に動作する、小規模な特化型モデルをデプロイするほうがはるかに賢明です。
AIエージェントのインフラ要件が本質的にハイブリッドになる理由
さらに、AIエージェントはLLMとツールを統合したものであるため、そのインフラストラクチャの構成は本質的にハイブリッドになります。中心となるLLMにはGPUによる高速処理が必要かもしれませんが、呼び出されるツールは数値演算を大量に行う処理ではないためGPUは必要ありません。
再びファッションコンサルタントのAIエージェントを例に考えてみましょう。服を着たイメージを見せるために高度な画像生成や動画生成を活用するかもしれませんが、過去の購入履歴の取得、ユーザーの好みの参照、在庫データベースの検索などは従来のツールに大きく依存しています。これらのツールはCPU上で動作し、大容量のストレージを必要とし、外部サービスと絶えず通信しています。
AIエージェントのインフラ要件は、万能型の単一のインフラだけで対応することはできません。GPU、CPU、ストレージ、および通信を状況に応じて動的に組み合わせることができるハイブリッド環境が必要なのです。
クラウドが常に成功を収めてきた理由は、柔軟かつハイブリッドなコンピュートとネットワーキングの組み合わせとして構築されてきたからです。私たちがすべてのタスクにAIを使わないのと同じように、すべてのワークロードにGPUを押し付けるのはやめるべきです。ハードウェアをユースケースに合わせるべきであり、その逆であってはなりません。
「AIエージェントだけの理想郷」という幻想
AIエージェントたちが「Agentlandia（エージェントだけの理想郷）」とでも呼ぶべき隔離された領域に存在し、エージェント同士で通信しながら、人間と直接やり取りすることなく物事を処理していく姿を想像するのは魅力的かもしれません。この幻想の中では、エージェントは少数の超集中型データセンターにある巨大なGPUクラスター上で稼働する巨大なLLMとして描かれます。
しかし、現実はどうでしょうか。OpenClaw、Hermes Agent、Claude Cowork、Claude Codeといった現在最も人気のあるエージェントフレームワークは、デスクトップに直接インストールされて実行されるのが一般的です。これらは集中型クラウド上で稼働する基盤モデルにクエリを投げるかもしれませんが、その他のコンポーネントはデスクトップ上で動作しています。
さらに、デスクトップ上で動作する代替となる大規模言語モデルを使用することもますます一般的になってきています。これらのAIエージェントは任意のクラウド環境で実行することも可能であり、ユーザーに近いクラウドロケーションが強く好まれる傾向にあります。
企業においても、これと並行するトレンドが展開されています。
企業は、従業員や顧客が利用するためのAIエージェントを、LangChain、Pydantic AI、n8n、CrewAIなどのエージェントフレームワークを活用して構築し、展開しています。これらのエージェントも任意のクラウドで実行でき、基盤モデルのプロバイダーの中央ホスト型巨大LLMを使用するように設定することも可能です。しかしここでも同様に、特定のユースケースに特化し、自社が選んだクラウド上で稼働する代替LLMを利用するアプローチが普及しつつあります。
現実世界から隔離された「Agentlandia」など存在しません。AIエージェントは、エッジデバイス、車の中、デスクトップ、そしてユーザーとの近接性に基づいて選ばれた高度に分散されたクラウド環境など、あらゆる場所で稼働するようになるでしょう。
新たな分散型通信ネットワークの全貌
タスクを実行するために、これらのAIエージェントは分散されたサービス群と常にやり取りする必要があります。リモートのウェブサイトを検索し、ローカルデータベースにクエリを投げ、リモートのAPIを呼び出します。たった1つのユーザーリクエストが、LLM、ローカルツール、リモートサービスの間で大量の通信を引き起こす可能性があります。
さらにAIエージェントは、人間とのリッチでマルチモーダルな会話ループを維持しながら、異なるクラウドエコシステムを越えて他のAIエージェントともやり取りしなければなりません。その全体像は、地球規模で広がり、高度に相互接続され、高い頻度で利用される、大規模分散型の通信チャネルそのものです。
業界の課題：AIエージェントが稼働する現場へのインフラ適応
インフラは、AIエージェントが機能する現場に適合させなければなりません。それはつまり、あらゆる場所に対応するということです。私たちは、エージェントのエコシステムを集中型のクラスターに無理やり押し込めることはできません。モデルが実行され、ツールが動作し、ユーザーがやり取りするまさにその場所に分散型インフラを構築して、エコシステムを支える必要があります。そして、システム全体を円滑に動かし続けるために、これらの拠点には低遅延かつ高帯域幅のネットワーク接続が提供されなければなりません。
これは、集中型データセンターが要らなくなるという意味ではありません。負荷の高いトレーニングワークロードや、特定の大規模な推論タスクにおいては、高密度GPUクラスターが依然として最適なソリューションです。しかし、その集中型ハブに加えて、高度に分散されたエッジインフラを組み合わせる必要があるということです。クラウドの未来は、中央のコアから末端のエッジに至るまで、インフラが途切れることなくシームレスに繋がり、状況に応じて柔軟にリソースを配置できる環境へと進化していくのです。
超集中型の巨大な施設を力技で増やし続けるアプローチは、現代の生成AIの運用実態にまったく適合していません。無駄が多く、拡張性にも乏しく、「Large Language Molasses（大規模言語モデルによる動作の極端な遅延）」に陥って進歩を停滞させるのは必至です。
業界に向けた私たちの挑戦は、AI時代に向けたよりスマートで、適応力が高く、極めて柔軟なクラウドを構築することです。私たちは、流動的で連続したロケーション全体に展開される、CPU、GPU、ストレージ、そして接続性を組み合わせた、高い柔軟性を持つハイブリッド環境を求めていく必要があります。クラウドは、AIの分散化という現実に適応して進化するか、あるいは完全に飲み込まれるリスクを負うかの二択を迫られているのです。
Tags
