Cloudflare Agents Week 2026が告げるCloud 2.0時代: エンタープライズの主戦場が移る

Cloudflareは2026年4月13日〜17日に「Agents Week 2026」を開催して、10個以上の新機能を一気に発表しました。新機能の多くが、LLMエージェント(Claude Codeのような「目的を与えられたら、自律的に考え道具を使いタスクを完遂するLLMを使った仕組み」)に関連したものです。

Cloudflareがエージェント向けプラットフォームのロードマップを一気に開示しきった印象的な5日間でした。

Cloud 2.0の時代

今回の発表をまとめて眺めると、Cloudの変遷は次のように整理できます。「Cloud x.0」という言い回しが使い古されているのは承知の上で、それでも今回の地殻変動を端的に表すのに「Cloud 2.0」はちょうど良い言葉だと感じています。

3つの世代を「場所→構造→意思」の流れで並べると、世代が進むごとに操作主体が一段上のレイヤーへ移っていくことが見えてきます。Cloud 0.5でインフラ担当者がVMを操作し、Cloud 1.0で開発者がAPIやIaC越しにマネージドサービスを操作してきたところに、Cloud 2.0ではLLMエージェント自身がインフラを叩く側に立ちます。今のエンタープライズが向き合っているのは、「LLMエージェントをいかに効率よく稼働させるか」を中心に据えた新しいITインフラストラクチャーの設計です。

ひとつ前提を強調しておきます。Cloud 2.0はCloud 1.0を置き換えるものではありません。銀行の勘定系、ECのバックエンド、SaaSの基盤といった既存のワークロードは、引き続きCloud 1.0のプリミティブの上で動き続けます。Cloud 2.0はその上に積み上がる新しいレイヤーとして立ち上がり、エージェントが必要に応じて下のCloud 1.0のアプリを呼び出すこともある、という関係です。

LLMエージェントとは

LLMエージェントとは、目的を与えられたら自分で考え道具を使いタスクを完遂するLLMを用いた仕組みです。聞かれたことに答えるだけのチャットボットと違い、ゴールに向かって自分で手を動かしていきます。具体的にはAnthropicのClaude CodeやClaude Coworkのようなサービスです。

より正確に整理すると、エージェントは主に以下の4つの要素で構成されるシステムと定義されることが多いです。

脳 (Brain / Planning)

LLM本体です。与えられた大きな目標を、実行可能な小さなステップ(サブタスク)に分解します。過去の失敗から学び、計画を修正する能力もここに含まれます。

記憶 (Memory)

会話の文脈や現在の作業手順を保持する短期記憶と、外部データベース(RAGなど)を活用して膨大な情報を必要に応じて取り出す長期記憶の二段構えです。

道具の使用 (Tool Use / Action)

エージェントの大きな特徴です。LLMはテキストを生成するだけでなく、Web検索で最新情報を取得し、コード実行で計算やデータ分析を行ない、API連携でメール送信・カレンダー予約・ファイル操作といった外部ツールを呼び出します。

認識と判断 (Perception & Reflection)

実行した結果が正しかったか、目標に近づいているかを自己評価し、次の行動を決定します。

この4要素は、計画→実行→評価のループを回しながら、共通の記憶を参照・更新する形で連動します。

ChatGPTをはじめとするLLMが登場したとき、企業はいかにこれを業務システム(アプリケーション)に取り込むかを検討しました。RAGによる社内ナレッジ検索、お問い合わせの自動応答、議事録の要約など、LLMをアプリケーションの中の一機能として組み込む方向です。

しかしその方向での検討は正しい解ではありませんでした。LLMがアプリケーションを含めたさまざまな道具を使い、人間に成り代わって判断しながら業務を行なう。そういう世界が見えてきたのです。LLMを部品として埋め込む構図から、LLMが部品を使う側に立つ構図への反転です。

この転換の背景には、Anthropicが2024年11月に公開したMCP (Model Context Protocol) で得られた「LLMを外と繋げば爆発的に生産性が上がる」という体験があります。Claude Codeはこの延長線上で、もっとカジュアルにLLMに外の道具を使わせればMCPより更に効果的であるということを実証してみせました。

つまり、既存の業務システムは無くなりません。LLMエージェントから利用される対象になります。アプリケーションは引き続きそこに存在しますが、操作する主体が人間からエージェントに移る、という関係です。前節の表で操作主体をAIエージェントに置いたのは、まさにこの転換を指しています。

使われ方の面でも構造が変わります。Cloud 1.0までのアプリケーションは「1つのアプリが多数のユーザを捌く」one-to-manyの前提で設計されてきました。コードは共通で、水平スケールでスループットを上げ、コストはユーザ数に対してサブリニアに伸びる構造です。エージェントはこれを反転させ、1ユーザ(あるいは1タスク)に対して専用の実行環境を割り当てるone-to-oneのモデルになります。

この「1ユーザに専用環境」という前提が、次節で見るインフラ要件の起点になります。

Cloud 2.0で必要なインフラ機能

前節で整理したLLMエージェントの4要素と、ユーザ1人に1つの実行環境を割り当てるone-to-oneのモデル。この2つを起点にすると、Cloud 2.0レイヤーが要求するインフラ機能は素直に導けます。

エージェントが実行時に取る活動を一段ずつ分解していくと、それぞれに対応するインフラ機能が見えてきます。

ここで効いてくるのがone-to-oneのモデルです。1ユーザに1つの専用実行環境を割り当てるため、表に並べた各機能は「同時に大量に立ち上げ、短時間で捨てる」パターンに耐える必要があります。Cloudflareがブログ「Welcome to Agents Week」で示した試算が分かりやすい例です。米国だけで1億人を超えるナレッジワーカーがそれぞれ数個のエージェントを15%の同時実行率で動かすと、同時セッション数は約2400万、CPU 1基あたり25〜50ユーザを想定すると米国分だけで50万〜100万CPU相当の容量が必要になる、という見積もりです。one-to-many前提の最適化のままでは、この規模には到底届きません。

つまりCloud 2.0レイヤーで必要なのは、上の表に並べたプリミティブを、one-to-oneでも破綻しないコスト構造で提供できるインフラです。次節では、このレイヤーで誰がどう動いているかを見ていきます。

Cloud 2.0で変わる力関係

CloudflareはAgents Week 2026の発表で、前節で挙げたCloud 2.0要件のすべてに対応するサービスを揃えました。

7要件すべてが新規発表・GA昇格・拡張のいずれかに該当します。Agents Week 2026は、Cloudflareがこのレイヤーへの準備を一気に完了させたイベントとして位置づけられます。

次に、Cloud 1.0を制覇した3強(AWS、Google Cloud、Microsoft Azure)にCloudflareを加えて、同じ7要件のものさしで判定します。判定の3条件は次のとおりです。

1. GA: 一般提供されており、誰でも利用できる(プライベートベータや「未公開」は除外)
2. エージェント特化: 汎用クラウドサービスの流用ではなく、エージェント向けに設計されている
3. 統合プラットフォーム配下: 各社の「エージェントクラウド」ブランドや統合プラットフォームの一部として提供されている

3条件すべてを満たせば○、preview/beta段階なら△、該当サービスなし・汎用流用・受付終了なら×、と判定します。

判定の根拠とした各社のエージェント特化プラットフォーム/主要サービスは次のとおりです。

7要件のものさしで眺めると、Google Cloudはエージェント特化のサービスを最も成熟させています。CloudflareはAgents Week 2026で全領域を埋め、×は出していません。Microsoft Azureはエージェント特化の統合プラットフォームとしてはpreview段階のサービスが多い印象です。AWSはBedrock AgentCoreファミリー(Runtime / Memory / Code Interpreter / Browser / Gateway / Identity / Policy / Evaluations / Observability)でレイヤー横断のサービスを揃えています。特に2026年4月にAgentCore BrowserがOS-levelアクションを追加したことで、ブラウザ自動化は他社と並ぶ水準に到達しています。一方で、エージェント単位のプライベートネットワークとGit互換の版管理ストレージという2領域では、AgentCoreファミリーに対応するプリミティブが現時点で確認できません。

Cloudflareがone-to-one前提の課金モデル(Dynamic Workersのper-load課金、Sandboxesのactive CPU pricing)とisolateベースのms起動を統合的に提供しているのに対し、AWSはAgentCore側で個別プリミティブを揃える方向で追いついている段階です。Cloud 1.0期に確立した汎用プリミティブ(EC2、Lambda、VPC、IAM)はone-to-many前提で設計されていたため、one-to-oneのワークロードに対しては個別最適の積み上げで対応している、と位置づけられます。

Cloud 1.0時代、CDNとセキュリティのベンダーとして3強の外側に置かれていたCloudflareが、Cloud 2.0レイヤーでは3強と肩を並べる側へ上がってきました。Cloud 1.0はAWSが制覇したレイヤーでしたが、Cloud 2.0ではプレイヤーの力関係がリセットされるステージです。

主戦場は業務リエンジニアリングへ

エンタープライズはCloud 1.0の世界を捨てる必要はありません。基幹システムやSaaSバックエンドはAWS中心の運用を続ければよく、その領域でのインフラ・アーキテクチャの設計力はこれからも継続して必要です。

ただしCloud 2.0レイヤーは別の判断軸で組む必要があります。Cloud 1.0期に確立したベンダー選定の前提がそのままでは通じないからです。前節で見たとおり、Cloud 2.0ではGCPが先行、Cloudflareが追いつき、AzureとAWSは個別サービスを揃えつつも統合プラットフォームとしては道半ばです。「Cloud 1.0と同じベンダーで揃える」という発想を出発点にすると、コスト構造とプリミティブの噛み合わせで不利な選択を踏みやすくなります。

そしてCloud 2.0レイヤーで主戦場になるのは、インフラ・アーキテクチャではありません。プラットフォーム側がプリミティブを統合提供している以上、何をどう組み合わせるかが大きな差別化要因にはなりません。

ここで主戦場となるのは、業務プロセスをエージェント向けに再設計し、エージェントのスキルとして実装できる人材です。Cloud 1.0時代に「AWS特化のインフラ設計者」が握っていた価値の中心は、Cloud 2.0では「業務とエージェントの間を設計できる人」に移ります。

エンタープライズが今着手すべきは、エージェントが代替・補強できる業務プロセスの棚卸しと、それをエージェントに落とし込むケイパビリティの社内構築です。Cloud 2.0プラットフォームの選定は、その準備の一部であって目的ではありません。

References