新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

Agents Weekへようこそ

2026-04-12

8分で読了
この投稿はEnglish繁體中文FrançaisDeutschItaliano한국어Español (Latinoamérica)Español简体中文でも表示されます。

Cloudflareの使命は、常に「より良いインターネットを築くこと」です。それは、現状のインターネットのためのみならず、これから到来するインターネットのための意味も含みます。

本日より、次の時代のインターネットを作ることに焦点を当てた「Agents Week」が開始されます。

インターネットは元々、AI時代を想定してつくられていません。クラウドも同様です。

私たちが知っているクラウドは、前回の大きな技術のパラダイムシフトであるスマートフォンの登場によって生まれました。

スマートフォンにより誰もがインターネットを手にするようになりました。それは単に利用者が増えただけではなく、「オンラインであること」の意味そのものを変えました。常に接続され、すぐに応答が返ってくることが当たり前になったのです。その結果、アプリケーションはこれまでの何倍ものユーザーに対応する必要があり、それらを支えるインフラストラクチャも進化しなければなりませんでした。

業界がたどり着いた解決策はシンプルです。「ユーザーが増えた分だけ、アプリのコピーを増やせば良い」という考え方です。アプリケーションの複雑化という問題に対しては小さな断片(マイクロサービス)に分割してそれぞれのチームが独立して管理できるようにするという手法を手にしましたが、「限られた数のアプリが、多くのユーザーにサービスを提供する」という基本原則は変わらず、処理能力を拡大することは、単にコピーを増やすことを意味していました。

その結果、Kubernetesやコンテナが標準になりました。これにより、インスタンスの起動や負荷分散、不要になったものの削除が簡単にできるようになりました。この1対多モデルでは、単一のインスタンスで多数のユーザーに対応でき、ユーザー数が数十億に達しても、管理すべきリソースの数は有限のままでした。

しかし、エージェントはこの前提を崩します。

1人のユーザーに、1つのエージェント、1つのタスク

これまでのアプリケーションとは異なり、エージェントは1対1です。それぞれのエージェントが、1人のユーザーのための専用インスタンスになります。従来のアプリは、誰が使っても同じ処理の流れを辿る一方、エージェントはLLM(大規模言語モデル)が処理の流れを決め、必要に応じてツールを呼び出し、アプローチを調整し、タスクが終わるまで動き続けるため、それぞれ専用の実行環境が必要になります。

これは、レストランと専属シェフの違いに例えられます。レストランには、決まったメニュー(選択肢)があり、それらを大量に提供できるよう最適化されたキッチンがあります。これが現在のほとんどのアプリケーションです。一方でエージェントは、専属シェフのようなもので、都度「何をお召し上がりになりますか?」と尋ねるため、それぞれにまったく異なる材料、調理器具、または技術が必要になる可能性があります。そのため、レストランと同じキッチン設備ではこのサービスは成り立ちません。

この1年で、エージェントは急速に広まりました。特にコーディング支援のエージェントが先行しています。これは、開発者が新しい技術をいち早く取り入れる傾向があるため、自然な流れです。現在の多くのコーディングエージェントは、LLMが必要とする環境(ファイルシステム、Git、bash、任意のプログラムを実行できる環境)を提供するためにコンテナを起動します。

しかし、コーディングエージェントはまだ始まりに過ぎません。Claude Coworkのようなツールにより、技術に詳しくない人でもエージェントを使えるようになりつつあります。今後エージェントが開発者だけでなく、一般の人々(事務スタッフ、リサーチ担当者、カスタマーサポート、個人のスケジューラーなど)に広がったとき、その規模の問題は一気に大きくなります。

エージェントを大規模化する上での計算

アメリカには1億人以上のナレッジワーカーがいます。その一人ひとりが、同時利用率約15%でエージェント型アシスタントを使用した場合、同時に約2,400万セッションを処理できる能力が必要になります。CPUあたり25~50人のユーザーを処理できるとすると、必要なサーバーCPUは約50万〜100万台になります(アメリカだけで、1人あたり1エージェントの場合)。

さらに、1人が複数のエージェントを並行して実行した場合はどうでしょうか。そして、世界全体には10億人以上のナレッジワーカーがいます。計算資源の不足は少しどころか、桁違いに不足しているのです。

では、この差を埋める方法はあるでしょうか?

エージェントのために構築されたインフラストラクチャ

8年前、私たちはWorkersを立ち上げました。これは開発者向けプラットフォームの始まりであり、コンテナを使わないサーバーレスコンピューティングへの挑戦でした。当時の目的はシンプルでした。Cloudflareを高速化目的で使用するユーザーに、コールドスタートのない軽量な処理環境を提供することです。コンテナではなくV8 Isolatesに構築されたWorkersは、桁違いに効率的で、すぐに起動し、安価で稼働し、「起動→実行→終了」のパターンにネイティブに適していました。

そして後から分かったのは、この仕組みがエージェント時代に非常に合っているということでした。

コンテナは、すべてのエージェントにフル装備の業務用キッチンを与えます。固定された設備、ウォークイン冷蔵庫など、必要かどうかに関係なく全部が用意されます。一方でisolateは、専属シェフに調理スペース、熱源、包丁など、今回の料理に必要な最小限の道具だけを与えます。ミリ秒単位で準備され、料理が終わればすぐに片付けられます。

BLOG-3238 2

長期間実行される何千ものアプリケーションではなく、数十億の短時間、単一目的の実行環境を扱う世界では、isolateこそが適した基本単位です。

それぞれがミリ秒で起動し、安全なサンドボックスとして動作します。さらに、同じハードウェア上でコンテナよりも桁違いに多く動かすことができます。

数週間前には、これをさらに進めたDynamic Workersのオープンベータも開始しました。これは、実行環境を実行時にオンデマンドで立ち上げる仕組みです。Isolateは起動に要する時間はわずか数ミリで、使用メモリも数MB程度です。これは、コンテナより約100倍速く、最大100倍メモリ効率が良いことを意味します。

リクエストごとの起動→実行→破棄のサイクルを毎秒数百万回の規模で行えます。

エージェントがアーリーアダプターの枠を超えて、誰もが手に入れられるようになるためには、手頃な価格であることも必要です。各エージェントを個別のコンテナで実行するにはコストがかさむため、現在のエージェント型ツールは主にエンジニア向けのコーディング支援に限られています。しかし、isolateのように桁違いに効率的な仕組みであれば、エージェントに必要な規模でも現実的なコストで運用できます。

BLOG-3238 3

「馬のない馬車」の段階

未来に向けた基盤を作ることは重要なミッションですが、私たちはまだその途中にいます。どのような技術のパラダイムシフトにも、新しい仕組みを古い仕組みに当てはめて考える時期があります。初期の車は「馬のない馬車」と呼ばれていました。初期のWebサイトはデジタルパンフレットでした。初期のモバイルアプリは、デスクトップ画面を小さくしたものでした。現在、エージェントもまさにその段階にいます。

その例は様々な場所で見ることができます。

人間向けに作られたWebサイトを操作させるために、エージェントにヘッドレスブラウザを使わせています。しかし本来必要なのは、MCPのような構造化されたプロトコルで、サービスを直接見つけて呼び出すことです。

多くの初期のMCPサーバーは、既存のREST APIをそのまま包んだだけのものに過ぎず、同じCRUD操作を新しいプロトコルで行っているに過ぎません。しかし実際には、LLMはツールを順番に呼び出すよりも、コードを書く方がはるかに得意です。

また、CAPTCHAや行動分析によって、相手が人間かどうかを確認していますが、これからはその相手は人間ではなく「エージェント」であることが増えていきます。重要なのは「人間かどうか」ではなく、「どのエージェントなのか、誰の許可を受けているのか、何をすることが許されているのか」です。

さらに、数回API呼び出しを行って結果を返すだけのエージェントのために、完全なコンテナを立ち上げているケースもあります。

これらはほんの一例に過ぎませんが、これらは特別な事ではなく、技術の移行期には、往々にしてこのような事が起こります。

両方に対応する構築

インターネットには常に、2つの時代が共存しています。IPv6はIPv4より明らかに優れていますが、IPv4サポートを廃止すれば、インターネットの半分が機能を失うでしょう。HTTP/2とHTTP/3は共存しています。TLS 1.2はまだ、1.3へ完全に移行していません。このように、より良いテクノロジーの定着後も古いテクノロジーは継続して使用されるため、インフラにはその両方の橋渡しをする役目があります。

Cloudflareはこれまでも、こうした移行をつなぐ役割を担ってきました。エージェントへのシフトも例外ではありません。

コーディングエージェントは、ファイルシステム、git、bash、任意のバイナリ実行といったコンテナを必要とします。これらは今後も必要です。そのため今週、私たちはコンテナベースのサンドボックス環境を正式版として提供開始します。また、MCPにまだ対応していないサービスも多く存在するため、エージェントがそれらとやり取りできるように、ブラウザ操作機能も強化しています。これらは一時的な対策ではなく、完全なプラットフォームの一部です。

同時に、次の時代に向けた構築も進めています。エージェントに本当に必要な、isolate、プロトコル、アイデンティティモデルです。私たちの役割は、お客様が、現在有効なものと将来適しているものを選ぶ必要がないようにすることです。

周辺ではなく、モデルの中に組み込まれたセキュリティ

エージェントが私たちの業務上および個人的なタスク(メール確認、コードの操作、金融サービスの利用)を処理するのであれば、セキュリティは後付けではなく、実行モデルそのものに直接組み込まれている必要があります。

この課題に最初に直面したのはCISO(最高情報セキュリティ責任者)です。エージェントを誰もが利用できるようになることで生産性は向上しますが、現在、ほとんどのエージェントには、プロンプトインジェクション、データ流出、不正なAPIアクセス、不透明なツールの使用などのリスクが伴います。

開発者用バイブコーディングエージェントは、リポジトリとデプロイメントパイプラインへのアクセスを必要とします。企業のカスタマーサービスエージェントは、内部APIおよびユーザーデータにアクセスする必要があります。どちらの場合も、現在のセキュリティ対策は、認証情報、ネットワークポリシー、アクセス制御を組み合わせて対応していますが、これらはもともと自律的に動くソフトウェア向けに設計されたものではありません。

Cloudflareはこれまで、2つのプラットフォームを並行して構築してきました。1つはアプリケーションを作る開発者向けプラットフォーム、もう1つはアクセスを安全に管理するゼロトラストプラットフォームです。これまでは別々の対象に提供されてきました。

しかし、「どのようにこのエージェントを構築するか」と「どのように安全性を確保するか」は今や同じ問題になりつつあります。そこで私たちはこれらを統合し、セキュリティが後付けではなく、エージェントの実行の一部として自然に組み込まれるようにしています。

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

エージェント時代には、計算能力やセキュリティだけでなく、収益やガバナンスの問題も重要になります。

エージェントが私たちの代わりにインターネットを利用し、記事を読み、APIを使い、サービスにアクセスするようになると、これらを提供する組織が、条件を設定したり、対価を得られるようにできる仕組みが必要です。現在のWebの収益モデルは、広告、ペイウォール、サブスクリプションなど、人間目線での注視(インプレッション数)をもとに構築されています。

エージェントにはこのような注視の考えはありません。広告を見ることもなければ、Cookieバナーをクリックすることもありません。

エージェントを自由に活動させながら、出版業者、コンテンツクリエイター、サービスプロバイダーが公平に報酬を受け取るインターネットを目指すのであれば、そのための新しい仕組みが必要になります。私たちは現在、出版業者やコンテンツ所有者が、エージェントとコンテンツとのインタラクションに関するポリシーを簡単に設定・適用できるツールを構築しています。

より良いインターネットを作るとは、技術を作る人だけでなく、その価値を生み出すすべての人にとって機能することを意味します。それはエージェント時代でも変わりません。むしろ、より重要になります。

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

開発者プラットフォームに対する当社のビジョンは、常に、実験段階からMVP、そして数百万人のユーザーへの拡張まで対応できる、とにかく使える包括的なプラットフォームを提供することでした。しかし、プリミティブを提供することは、取り組みの一部に過ぎません。優れたプラットフォームは、それらがどう連携し、開発の流れにどう組み込まれるかまで考える必要があります。

そしてその役割は変わりつつあります。これまでは、人間の開発者が作りやすく、テストしやすく、公開しやすいことが中心でした。しかしこれからは、エージェントが人間を支援すること、そしてプラットフォームがエージェントを構築する人々だけでなく、エージェント自身にとっても使いやすいものであることが重要になっています。エージェントは最新のベストプラクティスを見つけることが可能か?必要なツールやCLIをどれだけ簡単に発見し、呼び出せるか?コードの記述からデプロイまで、どの程度シームレスに移行できるか?

今週、私たちはこれら両方の面で改善を進め、Cloudflareを、人間の開発者にとっても、エージェントにとっても、より使いやすいものにしていきます。

未来に向けた構築はチームスポーツ

未来に向けた構築は、私たちだけでできるものではありません。HTTP/1.1からHTTP/2、HTTP/3への移行や、TLS 1.2から1.3への移行など、インターネットの大きな変化はすべて、業界全体で共通の標準を作ることで実現してきました。エージェントへのシフトも例外ではありません。

Cloudflareはこれまで、インターネットを支える標準の策定と普及に積極的に関わってきました。当社は10年以上前からIETFに深く関与し、QUIC、TLS 1.3、Encrypted Client Helloなどのプロトコルの開発と実装に貢献しています。また、当社は、JavaScriptランタイム相互運用性に関するECMA技術委員会であるWinterTCの創設メンバーでもあります。さらに、Workersのランタイムをオープンソースとして公開しました。これは、基盤はオープン化すべきだと考えているためです。

この姿勢を、エージェントの時代にも持ち込んでいます。Cloudflareは、Linux FoundationやAAIFへの参加、そしてエージェント時代の基盤となるMCPのような標準の推進にも積極的に関わっています。AnthropicがMCPを発表して以来、私たちは同社と緊密に連携し、リモートMCPサーバーの基盤構築や、自社実装のオープンソース化、実運用に耐える仕組みづくりに取り組んできました。

また昨年には、Coinbaseとともにx402 Foundationを共同設立しました。これは、長らく休止状態だったHTTP 402ステータスコードを復活させ、エージェントが利用するサービスやコンテンツのネイティブな支払い方法を提供する、オープンでニュートラルな標準です。

エージェントのアイデンティティ、認可、支払い、安全性、これらにはすべて、単一の企業だけでは定義できないオープンスタンダードが必要です。

今後にご期待ください

今週は、エージェントに関わるあらゆる分野(コンピューティング、接続性、セキュリティ、アイデンティティ、収益、開発者体験など)について発表を行います。

インターネットは元々、AIを想定して構築されたわけではありません。クラウドもエージェントのために構築されていません。しかし、Cloudflareは常により良いインターネットの構築を支援してきました。また、「より良い」の意味は時代ごとに変化します。今は、エージェントの時代です。今週、私たちをフォローして、どのようなものを作っているのか、ぜひ注目してください。

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
Agents WeekエージェントCloudflare WorkersWorkers AIAI開発者プラットフォーム開発者サーバーレス

Xでフォロー

Rita Kozlov|@ritakozlov_
Dane Knecht|@dok2001
Cloudflare|@cloudflare

関連ブログ投稿

2026年4月30日

Agents can now create Cloudflare accounts, buy domains, and deploy

Starting today, agents can now be Cloudflare customers. They can create a Cloudflare account, start a paid subscription, register a domain, and get back an API token to deploy code right away. Humans can be in the loop to grant permission, but there’s no need to go to the dashboard, copy and paste API tokens, or enter credit card details. ...

2026年4月22日

Rust Workersを信頼性を高める:Wasm-bindgenでのパニックと回復を中断する

Rust Workersのパニックは以前は致命的で、インスタンス全体が汚染されていました。Rust Workersは、Wasm-bindgenプロジェクトでアップストリームと共同作業することによって、WebAssembly Integration 全体を使用したパニックからの解消を含む、回復力のある重大なエラーの復旧をサポートするようになりました。...

2026年4月21日

過去のボット対人間

AIアシスタントやプライバシープロキシが従来のボット検出能力を難しくしているため、Webには責任を果たすための新しいモデルが必要です。私たちは、制御はクライアントに委ねられるべきであり、匿名認証情報のオープンなエコシステムが、ユーザーのプライバシーを守りながら、オリジンを悪用から保護するための鍵だと考えています。...