2026-04-12 • Rita Kozlov, Dane Knecht • 8分で読む

Agents Weekへようこそ

Cloudflareのミッションは常に「より良いインターネットを作る」ことでした。時には既存のインターネットのために作り、時にはこれから来るインターネットのために作ります。本日から始まるAgents Weekは、次に来るもののためのインターネット構築に捧げられています。

インターネットとクラウドはAI時代のために作られていなかった

クラウドが現在の形になったのは、スマートフォンという以前の技術パラダイムシフトの結果です。スマートフォンがインターネットを誰もがポケットに持つものにしたとき、単にユーザーが増えただけではなく、「オンラインであること」の性質自体が変わりました。常に接続され、瞬時の応答を期待する。アプリケーションは桁違いに多くのユーザーを扱う必要が生じ、裏側のインフラは進化しました。

業界が収束したアプローチはシンプルでした: ユーザーが増えれば、アプリケーションのコピーを増やす。アプリが複雑になるにつれ、チームはそれらをマイクロサービスのような小さな単位に分割しましたが、核となる原理は同じままです。有限の数のアプリケーションが多くのユーザーにサービスを提供する。スケールはコピーを増やすことで実現されました。Kubernetesやcontainersがデフォルトになり、インスタンスの起動、ロードバランス、不要時の破棄が容易になりました。この「1対多」モデルの下では、単一インスタンスが多くのユーザーにサービスを提供でき、ユーザー数が数十億になっても管理すべき対象の数は有限に保たれます。

Agentsはこれを壊す

1ユーザー、1エージェント、1タスク

従来のアプリケーションと異なり、agentsは1対1です。各エージェントはユニークなインスタンスであり、1人のユーザーに仕え、1つのタスクを実行します。従来のアプリケーションが誰が使っても同じ実行パスをたどるのに対し、エージェントは独自の実行環境を必要とします。LLMがコードパスを決定し、動的にツールを呼び出し、アプローチを調整し、タスクが完了するまで永続化するような環境です。

例えるなら、レストランとプライベートシェフの違いです。レストランにはメニューがあり、大量に回すために最適化されたキッチンがあります。これは現在の大多数のアプリケーションです。エージェントは「何を食べたいですか？」と聞くプライベートシェフに近く、その都度まったく異なる材料や器具、技術を必要とするかもしれません。同じキッチン設計でプライベートシェフサービスを運営することはできません。

過去1年で、開発者が早期導入者となってコーディングエージェントが台頭しました。多くのコーディングエージェントは現在、LLMに必要なものを与えるためにコンテナをスピンアップします: ファイルシステム、git、bash、任意バイナリの実行能力。しかし、コーディングエージェントは始まりに過ぎません。Claude Coworkのようなツールは、より技術的でないユーザーにもエージェントを届け始めています。管理アシスタント、リサーチアナリスト、顧客サポート担当、パーソナルプランナーなど、誰もが扱うようになると、スケールの計算は急速に厳しくなります。

マススケールの計算

米国の1億人を超えるナレッジワーカーがそれぞれエージェントを使い、約15%の同時利用率を想定すると、同時セッションは約2400万が必要になります。CPUあたり25～50ユーザーとすると、必要なサーバCPUはおおよそ50万〜100万台になります — これは米国だけ、しかも1人1エージェントの場合です。さらに複数のエージェントを並列に走らせることや、世界中の10億人超のナレッジワーカーを想像すると、我々は計算資源が「少ない」ではなく桁違いで足りていません。

では、このギャップをどう埋めるか。

エージェント向けに作られたインフラ

8年前、我々はWorkersを立ち上げました — 開発者プラットフォームの始まりであり、コンテナレスなサーバレスコンピュートへの賭けでした。当時の動機は実用的でした: Cloudflareの速度に依存する顧客のため、コールドスタートのない軽量なコンピュートが必要でした。WorkersはコンテナではなくV8 isolates上に構築され、結果として桁違いに効率的でした — 起動が速く、運用コストが低く、スピンアップ／実行／破棄のパターンに本質的に適していました。

我々が予期していなかったのは、このモデルがエージェント時代に非常に適合するということです。コンテナが一つのエージェントに対してフル装備の商業キッチンを与える一方（固定式の機器、ウォークイン冷蔵庫等）、isolatesはプライベートシェフにその時に必要なカウンタースペース、バーナー、ナイフだけを与えます。ミリ秒でプロビジョニングされ、料理が出された瞬間に片付けられます。

数千の長時間稼働アプリケーションではなく、数十億のエフェメラルな単目的実行環境を支える世界では、isolatesが正しいプリミティブです。各isolateはミリ秒で立ち上がり、厳密にサンドボックス化され、同じハードウェア上でコンテナと比較して桁違いに多く動かせます。

数週間前、我々はこれをさらに進め、Dynamic Workers open betaを発表しました: ランタイムでオンデマンドにスピンアップする実行環境。isolateは起動に数ミリ秒、メモリ消費は数メガバイトです。これはコンテナより約100倍高速で、メモリ効率も最大100倍に達します。リクエストごとに新しいものを立ち上げ、コードスニペットを実行して捨てる — 1秒間に何百万というスケールで可能です。

エージェントが早期採用者の手を離れて全員の手に渡るには、価格的にも現実的である必要があります。各エージェントをコンテナで動かすのはコストが高く、現在のエージェントツールの多くがエンジニア向けコーディングアシスタントに限られている理由の一つです。isolatesが桁違いに効率的に動くことで、エージェントが必要とするスケールでの単位当たり経済性が成り立ちます。

無馬車（horseless carriage）期

正しい基盤を作ることは重要ですが、まだそこに至っていません。どのパラダイムシフトにも、新しいものを古いモデル内で動かそうとする期間があります。最初の車は "horseless carriages" と呼ばれ、最初のウェブサイトはデジタルパンフレット、最初のモバイルアプリは縮小版のデスクトップUIでした。今、我々はエージェントでも同じ過渡期にいます。

至る所でその痕跡が見えます: 人間の目向けに作られたウェブサイトをナビゲートさせるためにheadless browsersをエージェントに与えている一方で、本当に必要なのはMCPのような構造化されたプロトコルでサービスを直接発見・呼び出すことだったりします。多くの初期のMCPサーバーは既存のREST APIの薄いラッパーに過ぎず — CRUD操作は同じでプロトコルだけ新しくなっている、というケースがあり、LLMはシーケンシャルなツール呼び出しをするよりもコードを書く方が得意な場合が多いです。

我々はリクエストの相手が人間かどうかを確かめるためにCAPTCHAsや行動フィンガープリンティングを使っていますが、相手が誰かの代理で動くエージェントであることが増えると、正しい問いは "あなたは人間か?" ではなく "どのエージェントか、誰に許可されているか、何ができるか?" になります。

また、少数のAPI呼び出しと結果返却だけで十分なエージェントに対してフルコンテナを立ち上げていることもあります。これらは移行期の典型的な例であり驚くべきことではありません。

両方のために構築する

インターネットは常に二つの時代の間にあります。IPv6は明らかにIPv4より良いですが、IPv4を切ればインターネットの半分が動かなくなります。HTTP/2とHTTP/3は共存し、TLS 1.2はまだ完全に1.3に置き換わっていません。より良い技術は存在しますが、古い技術は残り、インフラの役割は両者を橋渡しすることです。Cloudflareは常にこうした移行の橋渡しをしてきました。エージェントへの移行も例外ではありません。

コーディングエージェントは本当にコンテナを必要とします — ファイルシステム、git、bash、任意バイナリ実行。これは消えません。今週、我々のコンテナベースのサンドボックス環境はGAになります。これを最高にすることにコミットしています。また、長い間MCPを話さないサービスのロングテールが存在するため、エージェントのためのブラウザレンダリングにも深く取り組んでいます。これらは一時しのぎではなく、完全なプラットフォームの一部です。

同時に、我々は次に来るもの、つまりエージェントが実際に必要とするisolates、プロトコル、アイデンティティモデルを構築しています。今日動くものと明日に正しいものの間で選択を強いられないようにするのが我々の仕事です。

モデル内のセキュリティ、周辺のセキュリティではない

もしエージェントがメールを読み、コードを操作し、金融サービスとやり取りするなら、セキュリティは後から重ねるものではなく、実行モデルに組み込まれていなければなりません。CISOは最初にこの課題に直面しています。エージェントを全員に配る生産性の向上は現実的ですが、現在の多くのエージェント導入はリスクを孕んでいます: prompt injection、データ持ち出し、認可されていないAPIアクセス、不透明なツール使用など。

開発者のコード志向のエージェントはリポジトリやデプロイパイプラインへのアクセスが必要です。企業のCSエージェントは内部APIやユーザーデータへのアクセスが必要です。今日これらの環境を安全にするには、従来は自律ソフトウェア向けに設計されていなかった認証情報、ネットワークポリシー、アクセス制御を継ぎ接ぎにする必要があります。

Cloudflareは並行して二つのプラットフォームを構築してきました: アプリケーションを作る人のための開発者プラットフォームと、アクセスを安全にする必要がある組織のためのゼロトラストプラットフォーム。しばらくは別々の対象にサービスしてきましたが、「このエージェントをどう作るか」と「どう安全にするか」はますます同じ問いになっています。我々はこれらのプラットフォームを結合し、エージェントの実行にネイティブに組み込まれるようにしています。別途取り付ける層ではありません。

ルールに従うエージェント

エージェント時代には、コンピュートやセキュリティを超えた次元、つまり経済とガバナンスがあります。エージェントが我々に代わってインターネットとやり取りする（記事を読む、APIを消費する、サービスにアクセスする）際に、コンテンツを作る人やサービスを運営する組織が利用条件を設定し、対価を得られる仕組みが必要です。

今日のウェブの経済モデルは人間の注意を中心に構築されています: 広告、ペイウォール、サブスクリプション。しかしエージェントは（その種の）注意を持ちません。広告を見ず、クッキーバナーをクリックしません。エージェントが自由に動け、かつ出版社やコンテンツ制作者、サービス提供者が公正に報われるインターネットにしたいなら、新しいインフラが必要です。

我々は出版社やコンテンツ所有者が、エージェントがどのようにコンテンツとやり取りするかを設定・施行できるツールを構築しています。より良いインターネットを作るということは、技術を作る人々だけでなく、その仕事や創造性によってインターネットが価値あるものになっている人々全員にとって機能することを意味します。エージェント時代でもそれは変わらず、むしろ重要性は増します。

開発者とエージェントのためのプラットフォーム

我々の開発者プラットフォームのビジョンは、実験からMVP、そして数百万ユーザーへのスケーリングまで「そのまま動く」包括的なプラットフォームを提供することでした。しかしプリミティブを提供するだけでは不十分です。優れたプラットフォームはすべてがどのように連携するか、そして開発フローにどう統合されるかを考えます。その役割は進化しています。

かつては純粋に開発者体験に関するもので、人間が作り、テストし、出荷することを簡単にすることが中心でした。これからは、エージェントが人間を助けることを助けること、すなわちプラットフォームがエージェント自体にも機能するようにすることも重要です。

• エージェントは最新のベストプラクティスをどれだけ見つけられるか？
• 必要なツールやCLIをどれだけ簡単に発見・呼び出せるか？
• コードを書くところからデプロイまでをどれだけシームレスに移行できるか？

今週、我々はこれら両面での改善を提供します — Cloudflareをそれを構築する人間にも、それ上で動くエージェントにもより良くします。