Cloud Run Sandboxesがパブリックプレビュー、AI生成コードを安全に隔離実行
Cloud Run Sandboxesがパブリックプレビューに。AI生成コードを隔離実行
Google Cloudは2026年7月9日、Cloud Run上で信頼できないコードを安全に実行するサンドボックス機能をパブリックプレビューとして公開した。AIが生成したプログラムや、エンドユーザーがアップロードしたスクリプトを、ホスト環境やクラウドの認証情報から完全に分離した状態で動かせる。
起動はミリ秒単位で、既存のCloud RunインスタンスのCPUやメモリを共有する。追加のVMや専用のサンドボックスホスティングプラットフォームを使う必要はなく、追加料金も発生しない。この発表はベルリンで開催中のWeAreDevelopers World Congressで行われた。
これまで開発者は、AIが動的に生成したコードを安全に実行するために、コンテナクラスタを組んだり、サードパーティのmicroVMランタイムを契約したりする必要があった。Cloud Run Sandboxesは、その複雑さを取り除くサーバーレスネイティブの仕組みだ。
サンドボックスとは何か、なぜ必要なのか
サンドボックスとは、プログラムを隔離された領域で実行する仕組みのことだ。子供が砂場（サンドボックス）の中で自由に遊んでも、砂が外に散らばらないのと同じで、中で何が起きても外側のシステムには影響を与えない。
AIエージェントやLLM（大規模言語モデル）がコードを生成する時代では、この隔離が極めて重要になる。モデルが書いたPythonスクリプトに意図しないファイル削除やネットワーク経由のデータ流出が含まれていたとしても、サンドボックス内で止められるからだ。
Cloud Run Sandboxesは、既存のCloud Runサービスインスタンス内でほぼ瞬時に生成できる軽量な隔離実行境界だ。専用のVMを立ち上げる必要がなく、サーバーレス環境を離れずにすべてが完結する。
サンドボックスの仕組みとセキュリティ設計
シンプルな有効化とネイティブな呼び出し
利用開始は驚くほど簡単だ。Cloud Runサービスをデプロイする際に、gcloudコマンドまたはYAML設定でサンドボックスランチャーを有効にするフラグを1つ追加するだけでよい。有効化すると、軽量なサンドボックスCLIバイナリが実行環境に自動でマウントされ、標準的なサブプロセス呼び出しでプログラムからサンドボックスを生成できる。
実際の動作例として、LLMが動的に生成したPythonコードを安全に実行するデモが公開されている。1000個のサンドボックスを起動し、それぞれの処理を実行して停止するまでの平均レイテンシは500ミリ秒だ。
ゼロトラストを前提とした3層のセキュリティ境界
Cloud Run Sandboxesは、悪意あるコードや誤ったコードからホストアプリケーションとクラウドリソースを守るために、3つの重要なセキュリティ境界を強制する。
この3層構造によって、AIが生成したコードがどれほど予測不能な動作をしても、ホスト側への影響は生じない。セキュリティを理由にAIコード実行を諦めていた開発者にとって、大きな転換点になる。
3つの主要ユースケース
Cloud Run Sandboxesは特に以下の3つの用途で力を発揮する。いずれも「信頼できないコードを隔離実行する」という共通の要件を持つシナリオだ。
ADKとComputeSDKとの統合
Cloud Run Sandboxesは、Googleのエージェント開発キットであるADK（Agent Development Kit）の次期バージョンでネイティブサポートされる。新しいCloudRunSandboxCodeExecutorを使うと、ADKエージェントがわずか1行のコードでサンドボックス内のコード実行を指示できる。
また、ベンダーに依存しないサンドボックス実行用SDKであるComputeSDKにも対応が追加された。このSDKを使えば、Cloud Runサービスの外部からリモートでサンドボックスを呼び出すことも、サービス上のローカルツールとして直接使うこともできる。既存のツールチェーンにスムーズに組み込める設計だ。
コスト面の利点と実運用への影響
Cloud Run Sandboxesの大きな特長は、追加コストが一切かからないことだ。オンデマンドのVMに対して高いプレミアムを課金する専用サンドボックスホスティングプラットフォームとは異なり、既存のCloud Runインスタンスに割り当てられたCPUとメモリを直接共有する。
起動時間がミリ秒単位であることも実運用上の利点だ。従来のVMベースの隔離環境では、新しいVMを立ち上げるたびに数秒から数十秒の待ち時間が発生していた。Cloud Run Sandboxesなら、ユーザーからのリクエストに対してほぼ待ち時間なく応答できる。
Google Cloud Blogの記事で紹介されたデモでは、1000個のサンドボックスを起動してコードを実行し、終了するまでの平均レイテンシが500ミリ秒だった。これは「AIが生成したコードをリアルタイムで安全に実行する」という要件に対して十分実用的な数値だ。
この記事のポイント
- Cloud Run SandboxesはAI生成コードや信頼できないバイナリを安全に実行する隔離環境で、パブリックプレビューとして公開された
- 起動はミリ秒単位で、既存のCloud Runインスタンスのリソースを共有するため追加コストは発生しない
- 環境変数の隔離、ネットワーク通信のデフォルト遮断、安全なファイルシステムオーバーレイの3層でセキュリティを確保
- LLMコードインタプリタ、ヘッドレスブラウザ、ユーザー提出コードの実行が主要ユースケース
- ADKとComputeSDKに組み込み対応し、開発者は1行のコードでサンドボックス実行を指示できる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AWS Lambda MicroVMs発表、Firecrackerで隔離サンドボックスを即時起動
AWS Lambda MicroVMs発表、Firecrackerで隔離サンドボックスを即時起動する新サーバーレス
AWSが2026年6月22日、Lambdaファミリーの新たなコンピュートサービス「Lambda MicroVMs」を発表した。Firecrackerを基盤に、VMレベルの強固な隔離とスナップショットからの即時起動を両立する。AIが生成したコードやユーザー提供のスクリプトを安全に実行したいマルチテナントアプリケーション向けに設計されている。
この新サービスは、従来の仮想マシンとコンテナ、FaaS（Function as a Service）の間にあった溝を埋める。強い隔離が必要だが起動速度も妥協できない、さらにセッション中の状態も保持したい。そうした要件を単一のサービスで満たす選択肢がついに登場した。
Lambda MicroVMsとは何か
Lambda MicroVMsはAWS Lambdaの一部として提供される新しいサーバーレスコンピュートだ。最大の特徴は、エンドユーザーごと、あるいはセッションごとに専用の隔離実行環境を割り当てられる点にある。基盤技術にはFirecrackerを採用しており、この技術はすでに月間15兆回以上のLambda関数呼び出しを支える実績を持つ。
従来の選択肢との違い
従来、隔離されたコード実行環境を構築するには3つの選択肢があった。それぞれにトレードオフが存在する。仮想マシン（VM）は隔離性能に優れるが起動に数分かかる。コンテナは数秒で起動するが、カーネルを共有するため信頼できないコードを安全に実行するには追加の堅牢化が必須だ。FaaSはイベント駆動のリクエスト-レスポンス型ワークロードに最適だが、長時間の対話セッションや状態保持には向いていない。
Lambda MicroVMsはこの3つの間隙を埋める。VMレベルの隔離を持ちながら、スナップショットからの即時起動で高速なレスポンスを実現し、セッション中の状態も保持できる。さらにアイドル時には自動サスペンドでコストを抑えつつ、トラフィック受信時に自動レジュームする仕組みを備えている。
この比較図が示すように、Lambda MicroVMsは3つの要件を単一サービスで満たす。開発者はインフラ管理から解放され、アプリケーションの構築に専念できる。
なぜ今MicroVMsが必要なのか
ここ数年で、アプリケーション開発者が書いていないコードをエンドユーザーごとに安全に実行する必要があるマルチテナントアプリケーションが急増している。AIコーディングアシスタント、対話型コード実行環境、データ分析プラットフォーム、脆弱性スキャナ、ユーザースクリプトを実行するゲームサーバーなどがその代表例だ。
市場が求める新たな実行環境
こうしたアプリケーションに共通する要件は明確だ。強い隔離で安全性を担保しつつ、エンドユーザーが待たされない起動速度を実現し、対話セッション中は状態を保持し続けること。しかし従来のサービス群では、このすべてを満たす選択肢が存在しなかった。開発者は性能と隔離のトレードオフを受け入れるか、独自の仮想化基盤を構築するために多大なエンジニアリングリソースを投じるかの二者択一を迫られていた。
Firecrackerが支える信頼性
Lambda MicroVMsの基盤となるFirecrackerは、AWSがオープンソースで提供する軽量仮想化技術だ。すでにLambda FunctionsとFargateで運用実績があり、月間15兆回の呼び出しを支える実績は、この新サービスの信頼性を裏付ける。各MicroVMは独立したカーネルで動作し、ユーザー間のリソース共有は一切ない。あるユーザーが実行した信頼できないコードが、他の環境や基盤システムにアクセスすることはない。
技術的な仕組み
Lambda MicroVMsの中核には3つの技術要素がある。VMレベルの隔離、スナップショットベースの高速起動とレジューム、そしてステートフルな実行だ。これらが組み合わさることで、従来にない実行環境が実現されている。
イメージ作成から起動までの流れ
MicroVMsのライフサイクルは「イメージ作成→起動→実行→サスペンド→レジューム」という流れをたどる。まずDockerfileとアプリケーションコードをzipアーティファクトとしてS3にアップロードし、MicroVM Imageを作成する。AWS LambdaがDockerfileを実行し、アプリケーションを初期化したあと、実行環境のメモリとディスク状態のFirecrackerスナップショットを取得する。以降のMicroVM起動はすべて、このスナップショットからレジュームされるため、コールドスタートが発生しない。
このフローにより、数ギガバイト規模の対話セッションでもエンドユーザーが体感できるレスポンス速度でレジュームされる。アプリケーションはスナップショット時点で完全に初期化済みのため、起動完了と同時にリクエストを受け付けられる状態になる。
サスペンドとレジュームの自動化
Lambda MicroVMsにはアイドルポリシーが設定できる。設定可能な最大アイドル時間を超過すると自動的にサスペンドされ、メモリとディスク状態がスナップショットとして保存される。サスペンド中は実行コストが大幅に低減し、次のリクエストが到着すると自動的にレジュームされる。クライアント側からはサスペンドの発生を意識することなく、一貫した対話セッションが維持される。1MicroVMあたり最大8時間の連続実行が可能で、vCPUは最大16基、メモリは32GB、ディスクも32GBまでサポートする。
実際の利用シーン
発表時点で対応リージョンは米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、欧州（アイルランド）、アジア太平洋（東京）だ。アーキテクチャはARM64で、価格はAWS Lambdaの料金ページで公開されている。
想定されるユースケース
AIコーディングアシスタントは最も直接的なユースケースだ。ユーザーがAIに生成させたコードを、安全な隔離環境で即座に実行し結果を返す。データ分析プラットフォームでは、ユーザーごとに専用の分析環境を割り当て、ノートブック形式の対話セッションを長時間維持できる。脆弱性スキャナでは、疑わしいコードを隔離環境で安全に実行し、その振る舞いを観察するといった使い方が考えられる。
Lambda Functionsとの共存
Lambda FunctionsとLambda MicroVMsは競合ではなく補完関係にある。イベント駆動のバックボーンにはLambda Functionsを使い、信頼できないコードを隔離実行する必要がある処理だけをMicroVMsに委ねる構成が自然だ。両者は異なるAPIサーフェスを持ち、それぞれの得意領域で使い分ける設計になっている。
クラウド実行環境の新たな選択肢
Lambda MicroVMsの登場は、サーバーレスコンピュートの概念を一歩拡張するものだ。従来のサーバーレスが「インフラ管理からの解放」を旗印にしてきたのに対し、MicroVMsは「隔離実行環境の構築からの解放」を目指している。開発者は仮想化の専門知識を持たずとも、VMレベルの隔離と高速な起動を両立した環境を手に入れられる。
コスト設計のポイント
サスペンド機能の活用がコスト最適化の鍵を握る。対話型アプリケーションでは、ユーザーが考え込んでいる時間や離席中の時間が少なくない。こうしたアイドル時間に自動サスペンドを適用すれば、状態を保持したまま実行コストを抑えられる。アイドルポリシーの設定値はアプリケーションの特性に合わせて調整する必要がある。短すぎると頻繁なサスペンドとレジュームが発生し、長すぎると不要な実行コストが蓄積する。
今後の展望
初期リリースではARM64アーキテクチャのみのサポートだが、今後のアップデートでx86対応やリージョン拡大が期待される。また、スナップショット作成時にネットワーク接続を確立するアプリケーションや、エフェメラルデータを読み込むアプリケーションでは、サービス提供のフックとの統合が必要になる点にも注意が必要だ。
この記事のポイント
- Lambda MicroVMsはFirecrackerベースでVMレベルの隔離とスナップショット即時起動を両立する新サーバーレス
- AIコーディング支援やデータ分析など、ユーザー提供コードを安全実行するマルチテナントアプリに最適
- アイドル時の自動サスペンドとレジュームで、状態を保持したままコストを最適化できる
- Lambda Functionsとは補完関係にあり、イベント駆動処理と隔離実行を使い分ける設計が推奨される
- 東京リージョン含む5リージョンで即日利用可能、最大8時間の連続実行に対応
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Neon、有料プランのデータ転送量を5倍に増量。500GBで実質エグレスフリー
サーバーレスPostgreSQLサービスのNeonは2026年6月1日、全有料プランに含まれる月間データ転送量を従来の100GBから500GBへと5倍に引き上げた。この変更は自動的に適用され、利用者側での設定変更は不要だ。
500GBという上限は、ほとんどの一般的なワークロードにおける全データ転送（エグレス）コストを実質的にゼロにする水準だ。Neonのブログによれば、チャットボットのバックフィル処理や設定ミスによる超過リスクも、この増量によって大幅に緩和される。
本記事では、増量の具体的な内容と背景、利用者が知っておくべきポイントを整理する。
月間500GBへの増量。その具体的な内容
今回の変更の核心はシンプルだ。Neonの全有料プラン（Launch、Scale、Enterprise）において、月間のパブリックデータ転送（エグレス）の無料枠が100GBから500GBに拡大された。
500GBを超過した場合の追加課金体系に変更はない。超過分はこれまでと同一の従量課金レートで計算される。Neonの記事では「データ転送の計測方法や料金体系に変更は一切ない」と明言されている。
変更は自動適用。請求書にも即時反映
この増量は2026年6月1日からユーザー側の操作なしで自動適用される。Neonのコンソール（管理画面）で利用状況を確認可能で、6月分の請求書には新たな500GBの枠が反映される。
なぜNeonは5倍への増量を決断したのか
Neonのブログ記事は、意思決定の背景を率直に説明している。最大の動機は「予期せぬエグレス課金の排除」だ。
エグレス課金のストレスを根本から減らす
クラウドデータベースにおけるデータ転送料金は、しばしば利用者にとっての「見えないコスト」となる。チャットボットが想定以上にデータを取得したケース、分析ジョブが大量の履歴データを読み込んだケース、設定ミスでループ接続が発生したケースなど、原因は多岐にわたる。
これらの超過は後になってから請求書で気づくことが多く、事後対応が難しい。Neonの著者Carlo Daniele氏は「請求書に届いてからでは遅すぎる」と指摘している。500GBへの増量は、この「事後ショック」をほとんどのユーザーから無くす狙いがある。
競合との差別化とサーバーレスの信頼性向上
サーバーレスデータベース市場では、Vercel PostgresやSupabaseなどもデータ転送枠を設けている。500GBという閾値は、これらのサービスと比較しても実質的な「エグレスフリー」を実現する水準だ。
Neonにとって、この変更はプラットフォームの信頼性向上と、サーバーレスアーキテクチャへの移行障壁を下げる施策といえる。特にスタートアップや個人開発者にとって、突発的なコスト増はサービス継続のリスクになりうる。その不安を軽減する効果は大きい。
利用者に求められる対応と確認方法
必要な対応は一切なし
繰り返しになるが、利用者が実施すべき設定変更や申し込みは存在しない。Neonの全有料プラン契約者に対し、2026年6月1日以降の月間データ転送量が自動的に500GBへと引き上げられている。
利用状況の確認方法
自身のデータ転送量を把握したい場合は、Neon Consoleにログインし、請求および利用状況のダッシュボードでエグレス使用量を追跡できる。不明点はNeon公式Discordコミュニティで質問することも可能だ。
今後のデータ転送戦略とユーザーへの影響
今回の増量は、Neonが「データ転送をコスト障壁にしない」という姿勢を明確に打ち出したものと捉えられる。サーバーレスデータベースの利点である「従量課金の柔軟性」は、往々にして「予測不能なコスト」と紙一重だ。
500GBの無料枠は、その両面を切り離す試みだ。実際の利用データにもとづきNeonが「ほとんどのワークロードでエグレス課金が発生しなくなる」と明言している点は、単なるマーケティングではなくユーザー利用統計に裏付けられた判断といえる。
将来的にNeonがさらなるデータ転送枠の拡大や、完全なエグレスフリー化に踏み切る可能性もあるが、現時点ではこの変更が最大のハードルを解消したと評価できる。
この記事のポイント
- Neonは2026年6月1日より、全有料プランの月間データ転送量を100GBから500GBに増量
- 変更は完全自動適用。利用者による操作や設定変更は不要
- 500GB超過分の従量課金体系に変更はなく、データ転送の計測方法も据え置き
- 大半の一般的なワークロードがエグレス課金の対象外に。実質的なコスト障壁が大幅に低下
- 予期せぬエグレス課金への不安を解消し、サーバーレスデータベースの信頼性を強化
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Amazon OpenSearch Serverless次世代版、AIエージェント構築向けに発表
AWSが2026年5月28日、Amazon OpenSearch Serverlessの次世代版を一般提供開始した。AIエージェントアプリケーションの構築に特化したフルマネージド検索・ベクトルエンジンであり、スケールゼロからピーク時までシームレスに拡縮する。
従来のプロビジョニング型クラスタと比較して最大60%のコスト削減が可能とされる。リソース作成は数秒、スケーリング速度は前世代比で最大20倍に向上した。VercelやKiroといったAI開発プラットフォームとのネイティブ統合も備え、インフラ管理を意識せずに本番対応のバックエンドを数分で立ち上げられる。
この記事では、次世代OpenSearch Serverlessの主要な特徴、アーキテクチャ上の進化、AIエージェント開発への実践的な活用法を詳しく見ていく。
OpenSearch Serverless次世代版の概要
OpenSearchはElasticsearchからフォークしたオープンソースの分散型検索・分析エンジンだ。Amazon OpenSearch Serviceはそのマネージド版であり、サーバーレスオプションは2022年に導入された。今回の次世代版は、そのサーバーレスアーキテクチャを根本から刷新したものである。
AWS News Blogの記事によると、次世代版は「AIエージェントを構築する顧客向けに設計された」と位置づけられている。フルマネージドである点は変わらないが、スケーリングの速度とコスト効率が大幅に向上した。
主な改良点はスケールゼロと高速スケーリング
特筆すべきはスケールゼロへの対応だ。利用が途絶えると自動的にリソースが解放され、アイドル状態のコストがほぼゼロになる。リクエストが発生すると数秒でリソースが再作成され、前世代比で最大20倍速いスケールアップを実現する。
つまり、開発中の本番前ステージング環境や、トラフィックが断続的なAIエージェントのバックエンドで、大幅な無駄を省けるということだ。
このデモは、従来型と次世代版のリソース管理モデルの違いを概念的に示したものだ。実際の環境では、数秒単位でプロビジョニングが動的に切り替わる。
コレクションタイプは全文検索とベクトル検索に限定
今回のリリース時点では、対応するコレクションタイプは全文検索（SEARCH）とベクトル検索（VECTORSEARCH）の2種類である。既存のOpenSearch Serverlessにあった時系列データやログ分析向けのタイプは、現時点では次世代版で選択できない。
これは、まずAIエージェント向けの検索基盤として最適化された領域に集中した戦略と見られる。今後のアップデートで順次拡張される可能性は高い。
スケールゼロと高速スケーリングの仕組み
次世代版のアーキテクチャを理解するには、従来のサーバーレス版との違いを押さえておくとよい。前世代のOpenSearch Serverlessは、あらかじめ設定された最小キャパシティユニット（OCU）を常に確保するモデルだった。利用がゼロになっても、その最小ユニット分のコストは発生し続けたのである。
OCUの最小値をゼロに設定可能
次世代版では、インデックス用と検索用それぞれの最小OCUをゼロに指定できるようになった。CLIコマンドを見ると、minIndexingCapacityInOCUとminSearchCapacityInOCUに0が設定されているのがわかる。
この仕組みにより、トラフィックが完全に途絶えた時間帯はコンピューティングリソースが解放され、ストレージのみの課金になる。実質的に「寝ている間は課金されない検索エンジン」として振る舞うわけだ。
リソース作成が数秒で完了する理由
従来のサーバーレス版でコレクションを作成すると、数分かかることもあった。次世代版では、内部的なリソースプロビジョニングのパイプラインが刷新されており、数秒で利用可能になる。
これはAIエージェントの開発フローにおいて非常に重要だ。たとえばVercel上で新しいプロジェクトを作成し、そこにベクトルデータベースを接続する場合、即座にプロビジョニングが完了しなければ開発テンポが落ちてしまう。数秒で立ち上がるという体験は、プロトタイピングの高速化に直結する。
このフローはVercel統合を活用した典型的なAIエージェントのセットアップ手順を図示したものだ。実際の操作はVercelの管理画面から数クリックで完了する。
VercelやKiroとの統合でAIエージェント構築を加速
次世代OpenSearch Serverlessの重要な価値は、AIエージェント開発プラットフォームとのシームレスな連携にある。Vercelの管理画面から直接OpenSearchコレクションを作成・接続できるようになったのがその典型だ。
Vercel統合の実用性
Vercelユーザーは、フロントエンド（Next.js等）のデプロイに加え、検索やベクトルストアをバックエンドインフラとして簡単に追加できる。従来であれば、別途Elasticsearch互換のDBを用意し、VPCネットワークを設定し、認証情報を安全に管理する手間が発生した。
これが管理画面上で完結するということは、開発者がインフラの設定に費やす時間を劇的に減らせる。特にAIエージェントのように試行錯誤を重ねるプロジェクトでは、この迅速さが競争力に直結する。
OpenSearch Agent SkillsとKiro Powers
AWS News Blogの記事では、Claude CodeやCursor、Kiroといった開発ツールとの連携も紹介されている。GitHub上のOpenSearch Agent Skillsというリポジトリには、特定のワークフロー向けのドメイン知識やベストプラクティスがスキルとしてパッケージ化されている。
たとえば「あるテーマに関する最新の技術ドキュメントを検索し、その結果を要約する」といった複数ステップのタスクを、エージェントがOpenSearchのスキルを呼び出すだけで実行できる。エージェントは単に検索結果を受け取るだけでなく、その検索がどのように実行されたかのプロセスも理解できるようになる。
このインラインフローは、開発者がAIエージェントに指示を出してからOpenSearchが検索を実行し、結果が返るまでの一連の流れを色分けで示している。OpenSearch Agent Skillsによって、エージェントは適切なスキルを自動選択できる。
一方、Kiro Powersで提供されるOpenSearch Launchpadは、エンドツーエンドのアーキテクチャ計画をガイド付きで進められるツールだ。検索アプリケーションの全体設計をAIが支援することで、開発の初期段階から生産性を高められる。
導入方法、コンソールとCLI
次世代OpenSearch Serverlessの利用開始は簡単だ。マネジメントコンソールから「Serverless」メニューを選び、「Create collection」をクリックする。次の画面で「NextGen」を選択し、Express createを選べばデフォルト設定で即座にコレクションが作成される。
Express createで手間を省く
Express createは設定不要のクイック作成機能だ。セキュリティポリシーやネットワーク設定は自動で適用され、後から一部の設定を変更できる。プロトタイピングや検証用途では、まずExpress createで立ち上げ、必要に応じて細かな設定を詰めるアプローチが現実的だろう。
CLIからの作成手順
AWS CLIを使う場合は、まずコレクショングループを作成し、その中にコレクションを作る2段階の手順になる。以下はAWS公式ブログに掲載されたコマンド例を、実際の利用に即して整理したものだ。
# コレクショングループの作成（生成世代をNEXTGENに指定）
aws opensearchserverless create-collection-group \
--name my-nextgen-group \
--standby-replicas ENABLED \
--generation NEXTGEN \
--description "My NextGen collection group" \
--capacity-limits '{
"maxIndexingCapacityInOCU": 96,
"maxSearchCapacityInOCU": 96,
"minIndexingCapacityInOCU": 0,
"minSearchCapacityInOCU": 0
}' \
--region "us-east-1"
# コレクションの作成（SEARCHまたはVECTORSEARCH）
aws opensearchserverless create-collection \
--name my-nextgen-collection \
--type SEARCH \
--collection-group-name my-nextgen-group \
--standby-replicas ENABLED \
--description "My collection in NextGen group" \
--region "us-east-1"なお、ブログ公開時のCLIコマンドには最大OCUのデフォルト値に誤りがあり、後日修正された点には注意が必要だ。実際に使う場合は最新のドキュメントを参照してほしい。
AIエージェント時代のデータバックエンドの在り方
OpenSearch Serverless次世代版の登場は、単なる新バージョン発表以上の意味を持つ。AIエージェントが自律的に情報を取得し、判断し、行動する時代において、「検索とベクトル演算のバックエンドをいかに手軽に、安く、速く用意できるか」が開発の成否を分けるからだ。
スケールゼロがもたらす開発文化の変化
従来、検索バックエンドの構築には「とりあえず動かす」だけでもある程度の初期コストが発生した。そのため、プロトタイプ段階では簡易的なインメモリ検索で代用し、後から本格的な検索エンジンに切り替えるパターンが一般的だった。
スケールゼロで最小OCUゼロが可能になったことで、最初から本番同様のOpenSearchを組み込んで開発を進められる。切り替えの手戻りがなくなり、より忠実な検証が可能になる。これはAIエージェントの品質を高める上で、見過ごせない利点だ。
マルチプラットフォーム連携の拡大予測
AWSはVercelとKiroに加え、今後さらに多くのAI開発プラットフォームとの統合を進めると見られる。GitHub CodespacesやReplit、Bolt.newなど、ブラウザベースの開発環境で動作するAIエージェントが増えれば、それらと連携する検索バックエンドの需要は右肩上がりだ。
OpenSearchがこの領域で競争力を発揮するためには、統合の容易さだけでなく、GPUアクセラレーションを活用したベクトル検索のパフォーマンスも鍵を握る。今回の次世代版ではGPU対応が明記されており、大量の埋め込みベクトルを扱う大規模AIエージェントのワークロードにも耐えられる設計が示されている。
コスト構造の変革と注意点
最大60%のコスト削減というインパクトは大きいが、これは「ピークキャパシティに合わせて常時プロビジョニングしていたクラスタ」との比較である。利用が常に一定水準以上あるサービスでは、スケールゼロの恩恵は限定的だ。
OCU単位の従量課金は、予測不能なトラフィックパターンを持つAIエージェントと相性が良い。一方、安定的に高いトラフィックが続く場合は、従来のプロビジョニング型OpenSearch Serviceの方がコストパフォーマンスに優れるケースもある。慎重な見積もりが求められる。
この記事のポイント
- OpenSearch Serverless次世代版はAIエージェント構築に特化し、スケールゼロと高速スケーリングを実現
- ピークプロビジョニング対比で最大60%のコスト削減、リソース作成は数秒で完了
- VercelやKiroとのネイティブ統合で、数分で検索バックエンドをデプロイ可能
- OCUの最小値をゼロに設定できるため、アイドルコストを極小化できる
- 全商用リージョンで一般提供開始、導入はコンソールのExpress createまたはCLIで
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CloudflareがClaude Managed Agentsと統合、エージェントの実行基盤を刷新
CloudflareがAnthropicと連携し、Claude Managed AgentsをCloudflareのサンドボックス環境と統合した。この新たな統合により、エージェントのコード実行からブラウザ操作、プライベートサービスへの接続までを、Cloudflareのプラットフォーム上でより柔軟に制御できる。
従来、Claude Managed AgentsはAnthropic側のインフラに完全に依存していた。今回の発表で「頭脳」であるClaudeの推論ループと「手足」であるコード実行基盤が分離され、後者をCloudflare上で運用できるようになった。
開発者は数分でテンプレートをデプロイし、セキュリティ強化やミリ秒単位のサンドボックス起動、内部サービスへの安全な接続といったメリットを得られる。この記事では、統合の仕組みと実務への影響を具体的に掘り下げる。
Claude Managed AgentsとCloudflareが目指すもの
この構成で得られるのは単なる「場所の変更」ではない。インフラをCloudflareに移すことで、エージェントの振る舞いを細かく監視し、内部サービスとの通信を暗号化し、必要なリソースだけを動的に割り当てられるようになる。
Cloudflare Blogの記事では、この仕組みを「頭脳から手足を切り離す」と表現している。開発者はClaudeの高い推論能力をそのまま活かしつつ、実行環境だけを自社ポリシーに合わせてカスタマイズできるわけだ。
Cloudflare環境の仕組み
統合をデプロイすると、Cloudflare上にWorkersベースのコントロールプレーンが立ち上がる。Claude Agentがセッションを開始するたび、このコントロールプレーンがサンドボックス環境を割り当て、コード実行やCLIツールの操作、ブラウザ操作などを代行する。
サンドボックスはセッションがスリープしても状態を自動的に保持する。コンテナイメージのカスタマイズやインスタンスサイズの調整もオプションで指定でき、既存の監視ツール（DatadogやSplunk）へのログ連携にも対応している。
特筆すべきは、Cloudflareのダッシュボードからエージェントの状態を可視化し、必要に応じてSSHでサンドボックス内部に入れる点だ。大規模なエージェント運用では、トラブルシューティングのしやすさが運用コストを大きく左右する。この設計は現場の要求をよく踏まえている。
インターネット規模のエージェント実行基盤
エージェントが本格的に普及すると、企業は1人のユーザーに対して複数のエージェントを同時に動かす必要が出てくる。従来のマイクロVM方式では、エージェントの数だけVMを起動し続けるため、リソースとコストが線形に増加してしまう。
Cloudflareはこの課題に対し、V8 Isolateを使った軽量サンドボックスを提供する。Dynamic WorkersとCodemodeを組み合わせることで、ミリ秒単位でサンドボックスを起動し、フルVMよりはるかに少ないリソースで任意のコードを実行できる。
エージェントのセットアップ時にバックエンドタイプとして「isolate」を選択するだけで、この軽量モードに切り替えられる。数万規模の同時エージェントを扱うユースケースでは、コスト効率が数十倍変わる可能性がある。
もちろん、Linuxツールをフル活用する開発エージェントには、引き続きマイクロVMベースのCloudflare Containersを使える。用途に応じて2種類の実行環境を選択できる点が、この統合の実用的な強みだ。
エージェントワークロードのセキュリティ
エージェントが組織の内部データやサービスにアクセスするとき、最大のリスクは認証情報の漏洩だ。Cloudflareの統合では、アウトバウンドプロキシを使い、サンドボックスから外部へ出る通信に対して動的に認証情報を注入する仕組みを備えている。
この設計のポイントは、エージェント自身はクレデンシャルを知らないことだ。プロキシがゼロトラストベースでリクエストに署名やトークンを付与するため、万が一サンドボックスが侵害されても、認証情報そのものが盗まれるリスクを抑えられる。
また、Cloudflare MeshとWorkers VPCを使えば、インターネットに一切公開していない内部サービスにも、ポスト量子暗号で保護されたトンネル経由で接続できる。VPNや踏み台サーバーなしでプライベートサービスと通信できる点は、インフラ担当者にとって大きな利点だろう。
プロキシはテナント単位やエージェント単位でポリシーを適用できる。特定のエンドポイントだけを許可リスト化し、それ以外の通信を遮断するといった細かな制御も、コード数行で実装可能だ。
エージェントに必要なツール群
ブラウザ操作の完全な制御
エージェントがウェブと対話する際、単純なHTTPリクエストでは不十分な場面が多い。JavaScriptを多用するモダンなウェブアプリケーションの操作や、QA用のスクリーンショット取得、フォーム入力の自動化には、実際のブラウザが必要になる。
CloudflareのBrowser Runは、エージェントにプログラム可能なブラウザを与える仕組みだ。検索、実行、スクリーンショット、ページのMarkdown変換など、複数のツールがデフォルトで利用できる。
セッションの録画機能も備わっており、エージェントがブラウザ上で何をしたかを後から完全に監査できる。許可リストや拒否リストを使ったアクセス制御も可能で、野放図なウェブアクセスを防げる。
メール送受信とプライベート接続
エージェントにメールアドレスを割り当て、送受信を自律的に行わせる機能も統合済みだ。Cloudflare Email Serviceと連携し、任意のドメインでエージェントがメールを送信できる。顧客対応の自動化や、転送されたメールへの返信といったユースケースに適している。
内部サービスへの接続にはcall_serviceツールが用意されており、Cloudflare MeshやWorkers VPC経由でプライベートAPIを安全に呼び出せる。Workers AIを使った画像生成ツールも標準で組み込まれており、Claudeのテキスト推論と組み合わせたマルチモーダルなワークフローを構築できる。
カスタムツールの追加
リポジトリをフォークし、独自のツールを追加するのも容易だ。例えばCloudflare R2にファイルをアップロードし、公開URLを返すツールを数行のコードで定義できる。以下はCloudflare Blogで示されたコード例を簡略化したものだ。
defineTool({
name: "r2_host_file",
description: "サンドボックスからR2にアップロードし公開URLを取得",
inputSchema: z.object({
key: z.string(),
content: z.string(),
contentType: z.string()
}),
run: async ({ key, content, contentType }, { env }) => {
await env.PUBLIC_BUCKET.put(key, content, { httpMetadata: { contentType }});
return `${env.PUB_R2_URL}/${encodeURI(key)}`;
}
})Workers AIを使ったエッジ推論や、Dynamic Workersによる動的なアプリケーションホスティング、Artifactsを使ったGit管理の追加など、Cloudflare Developer Platform全体をエージェントの拡張に活用できる。インフラ管理を意識せず、関数を書いてデプロイするだけで機能追加が完了する設計だ。
この記事のポイント
- Claude Managed Agentsの実行基盤をCloudflare上に構築できるようになった
- 「頭脳（Claude）」と「手足（Cloudflareサンドボックス）」の分離で、インフラ選択の自由度が向上した
- V8 Isolateを使った軽量サンドボックスで、ミリ秒起動と低コストの大規模実行が可能
- アウトバウンドプロキシによるゼロトラスト認証で、エージェントのセキュリティを強化
- ブラウザ操作、メール送受信、内部サービス接続などのツールが標準装備されている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが提唱するエージェント指向クラウド。Agents Week 2026の全発表まとめ
AIエージェントが自律的にコードを書き、顧客サポートを完結させ、複雑なリサーチを数分でこなす時代が到来した。これまでのクラウドは「1つのアプリケーションが多くのユーザーにサービスを提供する」というモデルで設計されていたが、その前提が根底から覆されようとしている。
Cloudflareは2026年4月、AIエージェントが主役となる新しいインフラ「Agentic Cloud（エージェント指向クラウド）」の構築に向けた大規模なアップデート「Agents Week」を実施した。数千万のエージェントが並列稼働する世界を支えるため、計算資源からセキュリティ、開発ツールまで、全レイヤーにわたる新機能が公開された。
本記事では、Cloudflareが目指す「Cloud 2.0」の全容と、発表された膨大な新機能のポイントを整理して解説する。開発者がプロトタイプから本番環境へとエージェントをスケールさせるための、具体的な武器が揃ったと言える。
エージェントのための新しい計算基盤と実行環境
エージェントは人間とは異なり、24時間365日、膨大な数で並列に動作する。そのため、従来の仮想マシンやコンテナよりも軽量で、かつ持続性のある計算資源が必要だ。Cloudflareは、エージェントが自由にコードを書き、実行できる専用の環境を整備した。
Git互換ストレージ「Artifacts」と隔離環境「Sandboxes」
「Artifacts（アーティファクツ）」は、エージェントが生成したコードやデータを保存するための、Git互換のバージョン管理ストレージだ。エージェントは数千万のリポジトリを動的に作成し、既存のリモート環境からフォーク（複製）して作業を進めることができる。これにより、エージェントが書いたコードを即座にGitクライアントで引き継ぐことが可能になった。
また、エージェントが実際にコマンドを実行し、パッケージをインストールするための環境として「Cloudflare Sandboxes」が正式リリース（GA）された。これは、ファイルシステムやシェルを備えた本物のコンピュータのような環境でありながら、ミリ秒単位で起動し、必要に応じて状態を保存・再開できる。エージェントごとに「専用のパソコン」を割り当てるイメージだ。
Durable Objectsによるエージェント専用データベース
「Durable Objects（デュラブル・オブジェクト）」は、特定の状態を保持できるサーバーレスの仕組みだ。今回のアップデートでは、Durable ObjectsにSQLiteデータベースを内蔵できる「Facets」という機能が追加された。これにより、エージェントが動的に生成したアプリケーションごとに、完全に隔離された専用のデータベースを持たせることが可能になる。
エージェントごとの隔離が難しく、管理が複雑。
エージェント B ➔ 専用SQLite DB
個別に隔離され、ミリ秒で起動・破棄が可能。
この仕組みにより、開発者は数万人のユーザーに対して、それぞれ専用のAIエージェントと専用のDBを瞬時に提供するプラットフォームを構築できる。スケーラビリティの概念が、ユーザー単位からエージェント単位へとシフトしている。
自律動作を支えるセキュリティとネットワーク
エージェントが社内ネットワークにアクセスしたり、ユーザーに代わって決済を行ったりする場合、セキュリティが最大の懸念となる。Cloudflareは、エージェントを「非人間（Non-human）のアイデンティティ」として定義し、その行動を厳密に制御する仕組みを導入した。
プライベート接続を簡素化する「Cloudflare Mesh」
「Cloudflare Mesh（クラウドフレア・メッシュ）」は、ユーザー、デバイス、そしてAIエージェントを安全につなぐプライベートネットワーク機能だ。これまでは、エージェントが社内のデータベースにアクセスするためには複雑なトンネル設定が必要だったが、Meshを使えば、エージェントに最小限の権限（最小特権原則）を与えて直接接続させることができる。
ユーザーに代わって認証する「Managed OAuth」
エージェントがユーザーの代わりにSaaSツールを操作する場合、これまではセキュリティ的に危うい「サービスアカウント」が使われることが多かった。今回発表された「Managed OAuth for Access」は、RFC 9728という新しい規格を採用し、エージェントがユーザーの権限を安全に借用して認証を行う仕組みを提供する。これにより、エージェントが何をしたかの監査ログも正確に残るようになる。
エージェントを「知能」に変えるツールボックス
計算資源があるだけではエージェントは動けない。適切なモデル（脳）、記憶（メモリー）、そして外部世界を認識する手段（ブラウザや音声）が必要だ。Cloudflareはこれらを「Agents SDK」として統合し、数行のコードで実装可能にした。
長期記憶と高度な検索機能
エージェントが過去の会話や作業内容を忘れないようにするための「Agent Memory」が導入された。これは、エージェントに必要な情報を記憶させ、不要な情報を忘れさせるマネージドサービスだ。また、「AI Search」という新しい検索プリミティブ（基本要素）を使えば、エージェントが膨大な文書の中から必要な情報をハイブリッド検索（キーワードと意味の両方で検索）して取り出せるようになる。
ブラウザ操作とマルチモーダル対応
「Browser Run（旧Browser Rendering）」は、エージェントにブラウザを与える機能だ。エージェントはウェブサイトを閲覧し、フォームを入力し、スクリーンショットを撮ることができる。新機能の「Human in the Loop」を使えば、エージェントが判断に迷ったときだけ人間に確認を求めるフローも構築可能だ。
さらに、音声認識（STT）と音声合成（TTS）をリアルタイムで行うパイプラインも追加された。WebSocket（ウェブソケット：双方向通信を行うための規格）を使い、わずか30行程度のコードで「声で会話するエージェント」を実装できる。メールの送受信も「Cloudflare Email Service」を通じてネイティブにサポートされた。
開発効率を最大化するインターフェースの進化
Cloudflareそのものの使い勝手も、エージェント時代に合わせて変化している。開発者が管理画面でポチポチと設定を変えるのではなく、エージェントがAPIを通じてインフラを操作するシーンが増えるからだ。
統一CLI「cf」と管理画面AI「Agent Lee」
約3,000ものAPI操作を統合した新しいCLI（コマンドライン・インターフェース）「cf」が登場した。これは人間だけでなく、エージェントがインフラを操作する際の一貫性を保つために設計されている。また、Cloudflareのダッシュボード内には「Agent Lee」というAIアシスタントが常駐するようになった。ユーザーはプロンプトを入力するだけで、複雑なスタックのトラブルシューティングや設定変更を行える。
ドメイン登録もAPIから可能に
「Cloudflare Registrar API」がベータ版として公開された。これにより、エージェントが自らドメインを検索し、空き状況を確認して登録するまでを完全に自動化できる。エージェントが新しいサービスを立ち上げ、ドメインを取得し、デプロイするまでの全工程がプログラム可能になったことを意味する。
ウェブ全体をエージェント対応へアップデートする
現在のインターネットは人間が読むことを前提に作られているが、これからはエージェントが読みやすい「Agentic Web」への適応が求められる。Cloudflareは、サイト運営者がこの変化に対応するためのツールも提供開始した。
Agent Readiness ScoreとAIトレーニング用リダイレクト
自分のサイトがどれだけAIエージェントにとって読みやすいかを測定する「Agent Readiness Score」が導入された。構造化データが適切か、ボットのアクセスを過度に制限していないかなどを評価する。また、古いコンテンツをAIが学習しないように、検証済みのクローラーを最新のページへ自動で誘導する「Redirects for AI Training」機能も追加された。これにより、古い情報に基づいたAIの回答（ハルシネーション）を防ぐことができる。
独自の分析：Cloudflareが描く「Cloud 2.0」の正体
今回のAgents Weekを通じて見えてきたのは、Cloudflareが「エッジコンピューティング」の強みを最大限に活かし、他社とは異なるアプローチでAIインフラを構築しようとしている点だ。AWSやGoogle Cloudが巨大なGPUセンターに注力する一方で、Cloudflareは「エージェントの実行場所（推論と実行の融合）」という独自のポジションを狙っている。
筆者の見解では、Cloudflareが提唱する「Cloud 2.0」の核心は、ステート（状態）とコンピューティングの極限までの近接にある。Durable Objectsによる超低遅延な状態管理と、ミリ秒で起動するSandboxesの組み合わせは、数千万という単位で増殖するエージェントを効率よく捌くための唯一の解かもしれない。中央集権的なクラウドでは、これほど大量の独立したセッションを低コストで維持するのは困難だからだ。
また、セキュリティを「後付け」ではなく「デフォルト」に置いている点も重要だ。エージェントが自律的に動く世界では、一度の権限設定ミスが致命的な被害を招く。MeshやManaged OAuthをインフラ層で提供することで、開発者はセキュリティの専門知識がなくても「安全なエージェント」を構築できるようになる。これはエージェントの普及を加速させる大きな要因になるだろう。
この記事のポイント
- Cloudflareは、AIエージェントが主役となる「Agentic Cloud（Cloud 2.0）」への進化を宣言した。
- Git互換ストレージ「Artifacts」や隔離環境「Sandboxes」により、エージェント専用の計算基盤が整った。
- 「Cloudflare Mesh」や「Managed OAuth」により、非人間（エージェント）の安全な認証とアクセス制御が可能になった。
- 「Agents SDK」に記憶、検索、ブラウザ操作、音声、メール機能が統合され、開発効率が飛躍的に向上した。
- サイトのエージェント親和性を測る「Agent Readiness Score」など、ウェブ自体をエージェント向けに最適化するツールが登場した。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Cloudflareが新CMS「EmDash」発表。プラグインのセキュリティ問題を隔離技術で解決
Cloudflare（クラウドフレア）は、WordPressの精神的な後継を謳う新しいオープンソースCMS「EmDash（エムダッシュ）」を発表した。これは現在のWeb環境に合わせてゼロから設計されたもので、TypeScriptをベースに構築されている。
EmDashは、WordPressが長年抱えてきたプラグインに起因するセキュリティ脆弱性を、独自の隔離技術によって根本から解決することを目指している。さらに、最新のフロントエンドフレームワークであるAstro（アストロ）をエンジンに採用し、圧倒的なパフォーマンスを実現した。
現在はプレビュー版であるv0.1.0が公開されており、GitHubからコードを入手できる。Cloudflareのインフラだけでなく、Node.jsが動作する環境であればどこでもデプロイ可能だ。なぜ今、新しいCMSが必要なのか、その詳細を解説する。
プラグインのセキュリティ問題を隔離技術で解決する
WordPressのサイトで発生するセキュリティ問題の約96％は、プラグインが原因だと言われている。従来の仕組みでは、プラグインはPHPスクリプトとして動作し、サイトのデータベースやファイルシステムに直接アクセスできてしまう。これが、一つの脆弱性がサイト全体の崩壊を招く要因だった。
EmDashはこの問題を「Dynamic Workers（ダイナミック・ワーカーズ）」と呼ばれる隔離環境（サンドボックス）で解決した。各プラグインは「Isolate（アイソレート）」という独立した実行単位で動作するため、他のプログラムやシステムの中核に勝手に干渉することができない。
プラグインが何らかの操作を行うには、マニフェストファイルで必要な権限（ケイパビリティ）を明示的に宣言する必要がある。例えば、コンテンツを読み取る権限やメールを送信する権限など、許可された範囲内でのみ動作が保証される仕組みだ。これはスマートフォンのアプリがカメラや位置情報へのアクセス許可を求める挙動に近い。
import { definePlugin } from "emdash";
export default () =>
definePlugin({
id: "notify-on-publish",
version: "1.0.0",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "posts" || event.content.status !== "published") return;
await ctx.email!.send({
to: "editor@example.com",
subject: `新着記事：${event.content.title}`,
text: `「${event.content.title}」が公開されました。`,
});
ctx.log.info(`エディターに通知を送信しました：${event.content.id}`);
},
},
});上記のコード例では、コンテンツの読み取りとメール送信の権限のみを要求している。このプラグインが許可なく外部のネットワークと通信したり、データベースを直接書き換えたりすることは物理的に不可能だ。管理者はインストール時に、そのプラグインが何をしようとしているのかを正確に把握できる。
このデモは、従来のCMSとEmDashにおけるセキュリティ構造の違いを視覚化したものだ。
Astroとサーバーレスがもたらす圧倒的なパフォーマンス
EmDashの内部エンジンには、コンテンツ主導のWebサイト向けフレームワークとして評価の高い「Astro」が採用されている。Astroは必要な部分だけをJavaScriptで動かす「アイランドアーキテクチャ」を得意としており、ブラウザでの読み込み速度を極限まで高めることができる。
また、EmDashはサーバーレス環境での動作を前提に設計されている。具体的にはCloudflare Workers（クラウドフレア・ワーカーズ）のランタイムである「workerd」上で動作し、リクエストがあった瞬間にプログラムが起動する仕組みだ。これにより、アクセスがないときはリソースを消費せず、急激なトラフィック増にも即座に対応できる。
従来のWordPressのように、常にサーバーを起動させておく必要がないため、運用コストの大幅な削減が期待できる。Cloudflareによれば、CPUの計算時間に対してのみ課金されるモデルのため、小規模なサイトから大規模なプラットフォームまで効率的にスケールさせることが可能だという。
テーマ制作も現代的だ。開発者はAstroのコンポーネントやスタイル（Tailwind CSSなど）を使って、使い慣れたモダンな手法でサイトのデザインを構築できる。従来のWordPressテーマのように複雑なPHPの作法を覚える必要はなく、フロントエンドエンジニアにとって親和性の高い環境が整っている。
AI時代を見据えた新しい収益化モデルと開発体験
EmDashが他のCMSと一線を画すのが、AIエージェントによる管理を標準でサポートしている点だ。MCP（Model Context Protocol）サーバーを内蔵しており、AIがサイトのコンテンツ構造を理解したり、プラグインを生成したりするためのコンテキストを直接提供できる。
例えば、CLI（コマンドラインインターフェース）を通じてAIエージェントに指示を出し、メディアのアップロードやスキーマの変更、さらにはWordPressテーマの移植ガイドを生成させることも可能だ。これは「人間が管理画面をポチポチ操作する」という従来のCMSのあり方を、根本から変える可能性を秘めている。
さらに、コンテンツの収益化についても新しい提案がなされている。「x402」というインターネットネイティブな決済プロトコルを内蔵しているのだ。これはHTTP 402エラー（支払いが必要）を活用した仕組みで、AIエージェントなどがコンテンツにアクセスする際、都度少額の支払いを行う「ペイ・パー・ユース」のモデルを簡単に導入できる。
広告収益に頼る従来のWebビジネスモデルが、AIによるスクレイピングなどで脅かされている現状に対し、EmDashは技術的な解決策を提示している。管理画面でコンテンツごとの価格を設定し、ウォレットアドレスを登録するだけで、サブスクリプションに頼らない新しい収益源を構築できるのだ。
WordPressからのスムーズな移行とモダンな認証機能
既存のWordPressユーザーを置き去りにしないための工夫も凝らされている。専用のインポータープラグインを使用することで、記事データやメディアライブラリを数分でEmDashへ移行できる仕組みが用意された。
カスタム投稿タイプについても、EmDashでは管理画面から直接スキーマ（データの構造）を定義できる。WordPressでACF（Advanced Custom Fields）などの外部プラグインを駆使して実現していたような複雑なデータ構造も、標準機能としてよりクリーンに管理することが可能だ。
セキュリティ面では、パスワードを廃止し「パスキー（Passkeys）」による認証をデフォルトとしている。これにより、パスワードの漏洩や総当たり攻撃のリスクを事実上ゼロにできる。もちろん、既存のSSO（シングルサインオン）プロバイダーとの連携も可能だ。
CloudflareはEmDashを単なるWordPressの代替品ではなく、これからの20年を見据えた「Webの新しいOS」のような存在として位置づけている。MITライセンスで公開されているため、特定のプラットフォームに縛られることなく、誰もが自由に拡張や開発に参加できる点も大きな魅力だ。
独自の分析：EmDashがWeb制作の現場に与える影響
EmDashの登場は、Web制作のワークフローを劇的に変える可能性がある。特に注目すべきは、プラグインのライセンス問題からの解放だ。WordPressのプラグインは、その構造上GPLライセンスを継承せざるを得ないケースが多かったが、EmDashではプラグインが完全に独立して動作するため、作者が自由にライセンスを選択できる。
これは、高品質な商用プラグインのエコシステムがより健全に発展することを意味する。また、セキュリティが「信頼」ではなく「技術的な制約」によって担保されるため、マーケットプレイスによる中央集権的な審査を待たずとも、安全に新しい機能を導入できるようになるだろう。
一方で、これまでのPHPベースのスキルセットを持つ開発者にとっては、TypeScriptやAstroへの移行という学習コストが発生する。しかし、サーバー管理の苦労から解放され、AIを活用した高速な開発が可能になるメリットは、そのコストを補って余りあるものになるはずだ。まずはプレビュー版を自身の環境で試し、そのスピードと安全性を体感してみることをお勧めする。
この記事のポイント
- EmDashはCloudflareが開発した、TypeScriptベースの新しいオープンソースCMSだ。
- プラグインを独自のサンドボックスで実行することで、WordPressの脆弱性問題を根本的に解決する。
- Astroとサーバーレス技術を採用し、高い表示速度とスケーラビリティを両立している。
- AIエージェントによる管理や、x402プロトコルによる新しい収益化モデルを標準搭載している。
- パスキーによる認証や、WordPressからの簡単なデータ移行機能も備えている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AIエージェント実行を100倍高速化。Cloudflare Dynamic Worker Loaderの革新性
AIエージェントが自らコードを書き、それを実行してタスクを完結させる「コード実行型」のワークフローが注目を集めている。しかし、AIが生成したコードを安全に動かすには、メインのシステムから隔離された「サンドボックス」が不可欠だ。
Cloudflareは2026年3月24日、このサンドボックスをオンデマンドで、かつ従来のコンテナ技術より100倍高速に起動できる「Dynamic Worker Loader」のオープンベータ公開を発表した。V8 Isolate技術を基盤とすることで、ミリ秒単位の起動と圧倒的なリソース効率を実現している。
この記事では、Dynamic Worker LoaderがなぜAIエージェントのスケールにおいて重要なのか、そしてエンジニアがどのようにこれを活用できるのかを詳しく解説する。
AIエージェントの安全性を支える「サンドボックス」の課題
AIエージェントがAPIを呼び出す際、単なる「ツール呼び出し（Tool Calling）」ではなく、コードを生成して実行させる手法は、トークン消費量を大幅に削減できることが分かっている。記事によれば、TypeScript APIを使用することで、トークン使用量を最大81%削減できた例もあるという。
なぜAI生成コードの直接実行は危険なのか
AIが生成したコードをアプリケーション内で直接実行（evalなど）することは、セキュリティ上の致命的なリスクとなる。悪意のあるユーザーがプロンプトを通じて脆弱性を注入し、システムの機密情報にアクセスしたり、不正な操作を行ったりする可能性があるからだ。
そのため、コードを実行する場所は、アプリケーションや他の環境から完全に隔離された「サンドボックス（砂場）」でなければならない。サンドボックスとは、特定の権限やリソースのみにアクセスを制限した実行環境のことだ。
既存のコンテナ技術が抱える「重さ」の壁
これまで、サンドボックスの構築にはDockerなどのLinuxコンテナが一般的に使われてきた。しかし、コンテナには大きな弱点がある。起動に数百ミリ秒から数秒かかり、メモリ消費量も数百MB単位と「重い」ことだ。
数百万人のユーザーがそれぞれAIエージェントを動かすようなコンシューマー規模のサービスでは、コンテナを都度立ち上げるコストは無視できない。かといって、セキュリティのためにコンテナを使い回さず、リクエストごとにクリーンな環境を用意しようとすると、パフォーマンスとコストの両面で限界に突き当たる。
Dynamic Worker Loader：V8 Isolateによる100倍速の革新
Cloudflareが提供する「Dynamic Worker Loader」は、この「重さ」の問題を根本から解決する。その鍵となるのが、Google Chromeでも採用されているJavaScript実行エンジン「V8」の「Isolate（アイソレート）」という仕組みだ。
起動時間は数ミリ秒、メモリ消費も最小限
Isolateは、OSレベルの仮想化であるコンテナとは異なり、プロセス内でメモリを論理的に分離する。これにより、起動時間はわずか数ミリ秒、メモリ消費も数MB程度に抑えられる。著者のKenton Varda氏らは、これが一般的なコンテナと比較して「100倍高速で、10〜100倍メモリ効率が良い」と指摘している。
この軽量さにより、1つのリクエストごとに新しいサンドボックスを生成し、実行が終わったら即座に破棄するという運用が現実的になる。同時並行で数百万のリクエストが発生しても、Cloudflareのインフラ上でシームレスにスケール可能だ。
世界数百拠点でのゼロレイテンシ実行
Dynamic Worker Loaderで生成されたワーカーは、通常、それを作成した親ワーカーと同じマシン、あるいは同じスレッド上で動作する。そのため、遠くのサーバーにある「ウォーム状態のコンテナ」を探しに行く必要がない。
Cloudflareが世界中に持つ数百の拠点すべてで動作するため、ユーザーに最も近い場所で、遅延（レイテンシ）をほぼ感じさせることなくAIコードを実行できるのが強みだ。
TypeScript RPCによる効率的なAPI連携
AIエージェントが外部のAPIと通信する際、従来はOpenAPI（REST）などの定義ファイルが使われてきた。しかし、Dynamic Worker Loaderでは、より簡潔な「TypeScript」による定義を推奨している。
OpenAPIより優れたトークン効率
OpenAPIの定義ファイルは冗長になりがちで、LLM（大規模言語モデル）に読み込ませる際のトークン消費が激しい。一方、TypeScriptのインターフェース定義は非常にコンパクトだ。AIにとっても理解しやすく、少ないトークン数でAPIの仕様を正確に伝えられる。
Dynamic Worker Loaderは「Cap’n Web RPC」という技術を使って、サンドボックス内のエージェントと親ワーカーの間で高速な通信を行う。エージェント側からは、あたかもローカルライブラリを使っているかのように、型安全なメソッド呼び出しが可能になる。
認証情報の注入とセキュアな外部接続
セキュリティ面でも、このRPCモデルは有利に働く。例えば、外部サービスへの認証トークンをエージェントに直接教える必要はない。エージェントがHTTPリクエストを送る際、親ワーカー側でリクエストをインターセプト（傍受）し、そこで認証ヘッダーを付与する「Credential Injection（認証情報の注入）」が可能だからだ。
これにより、万が一AIが生成したコードに悪意があったとしても、生の認証情報がエージェント側に漏洩するリスクを最小限に抑えられる。
AI開発を加速させる3つの公式ヘルパーライブラリ
Cloudflareは、Dynamic Worker Loaderをより使いやすくするために、3つの強力なヘルパーライブラリを提供している。これらを組み合わせることで、高度なAIエージェント環境を短期間で構築できる。
コード実行を簡略化する「Code Mode」
@cloudflare/codemodeは、LLMが生成したコードの実行を管理するライブラリだ。コードの正規化（フォーマットエラーの修正）や、fetch()の挙動制御を簡単に行える。完全に隔離された状態（ネットワークアクセス禁止）から、特定のプロキシ経由の通信まで、柔軟に設定可能だ。
ランタイムでのバンドルを可能にする「Worker Bundler」
Dynamic Workerは、依存関係が解決された「バンドル済み」のモジュールを必要とする。@cloudflare/worker-bundlerを使えば、実行時にnpmパッケージを含むソースコードをバンドルできる。例えば、Honoなどの軽量フレームワークをAIエージェントに使わせることも容易だ。
仮想ファイルシステムを提供する「Shell」
@cloudflare/shellは、サンドボックス内に仮想的なファイルシステムを提供する。エージェントはファイルの読み書き、検索、置換、diffの取得などが可能になる。ストレージの実体はSQLiteやR2（Cloudflareのオブジェクトストレージ）に保存されるため、実行を跨いでファイルを永続化させることもできる。
実務への応用とコストパフォーマンスの分析
Dynamic Worker Loaderの導入は、AIアプリケーションのアーキテクチャに大きな変革をもたらす。筆者の分析によれば、特に以下の3つの分野で大きなメリットがある。
第一に、「Tool Calling」のオーバーヘッド削減だ。従来のように、AIが1つずつツールを呼び出して結果を待ち、次のアクションを決めるループを繰り返すと、その都度コンテキストが膨らみ、レイテンシも増大する。Dynamic Workerを使えば、AIが「一連の処理をまとめたスクリプト」を一度に書き、それを実行するだけで済む。これは、大規模なAPIセットを持つシステムほど効果が高い。
第二に、コスト効率の劇的な向上だ。Dynamic Workerの料金は、ロード1回につき0.002ドル（ベータ期間中は無料）に、通常のCPU使用料が加算される仕組みだ。これはLLMの推論コストと比較すれば微々たるものだ。重いコンテナを常時起動させておく「ウォームスタンバイ」のコストから解放される意味は大きい。
第三に、プロトタイピングの高速化だ。Ziteなどの企業がすでに導入しているように、ユーザーの要望に応じてその場でCRUDアプリや自動化ロジックを生成し、即座にデプロイして動かすような「AIネイティブなPaaS」の構築が容易になる。
この記事のポイント
- 100倍の高速化: V8 Isolateにより、コンテナより圧倒的に速く軽量なサンドボックスを実現。
- セキュアな隔離: AI生成コードをメインシステムから分離し、安全にオンデマンド実行できる。
- 高いトークン効率: TypeScript RPCを活用し、冗長なOpenAPI定義を避けてコストを削減。
- 充実のライブラリ: コード実行、バンドル、ファイル操作を支援する公式ツールが提供されている。
- スケーラビリティ: Cloudflareのグローバルネットワーク上で、数百万のリクエストに即座に対応可能。
出典
- Cloudflare Blog「Sandboxing AI agents, 100x faster」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
my.WordPress.net登場——サーバー不要でブラウザが自分専用のWordPressになる
WordPress.orgは、ブラウザ上でWordPressを永続的に実行できる新サービス「my.WordPress.net」を公開した。
WordPress Playground技術を基盤とし、サーバーの契約やドメインの取得といった従来の手順を一切省いた環境を提供する。
これはWebサイト公開のためのツールから、個人の主権を守るワークスペースへの転換を意味しているとの見方が強い。
my.WordPress.netの概要と技術的背景
my.WordPress.netは、WebブラウザそのものをWordPressのサーバーとして機能させるプロジェクトだ。
ユーザーがサイトにアクセスした瞬間、ブラウザ内に独立したWordPress環境が構築される。従来のホスティングサービスとは異なり、サインアップや月額費用の支払いは発生しない。この即時性は、これまでの「5分間インストール」という象徴的な概念を塗り替えるものだ。
WordPress Playgroundによる仮想化技術
この仕組みの核となるのが「WordPress Playground（ワードプレス・プレイグラウンド）」という技術である。
通常、WordPressを動かすにはPHPというプログラミング言語を実行するサーバーと、データを保存するMySQLというデータベースが必要になる。Playgroundでは、これらをWebAssembly（Wasm）という技術を用いてブラウザ上で直接実行できるようにした。
WebAssemblyとは、ブラウザ上で高速なプログラムを動かすためのバイナリ形式のデータだ。これにより、パソコンやスマートフォンのブラウザさえあれば、外部サーバーに頼らずにフル機能のWordPressを稼働させることが可能になった。
「デジタル主権」の民主化
WordPressの共同創設者らは、このプロジェクトが「デジタル主権の民主化」を推し進めると指摘している。
デジタル主権とは、自分のデータや使用するソフトウェアを自分自身でコントロールできる権利を指す。my.WordPress.netでは、データはユーザーのブラウザ内にのみ保存される。特定の企業が運営するクラウドサービスに依存せず、自分だけの閉じた環境で情報を管理できる点が、既存のブログサービスとの決定的な違いだ。
「プライベートな空間」としてのWordPress
my.WordPress.netで作成されたサイトは、デフォルトで外部のインターネットからはアクセスできない非公開設定となっている。
これは、WordPressを「他人に情報を発信する場所」ではなく、「自分のための作業場」として定義し直す試みだ。アクセス数やSEO（検索エンジン最適化）を意識する必要がないため、より自由な試行錯誤が可能になる。
思考の整理とプロトタイピング
公開を前提としないため、my.WordPress.netはメモ帳や研究用のスクラップブックとして機能する。アイデアをドラフトとして書き溜めたり、複雑な情報を整理したりする用途に適している。また、新しいプラグインやテーマの挙動を確認するためのテスト環境としても最適だ。
プロトタイピング（試作）の場として活用すれば、本番のWebサイトに影響を与えることなく、新しいデザインや機能を試すことができる。失敗してもブラウザのデータをリセットするだけで済むため、学習コストや心理的ハードルが大幅に下がる効果が期待される。
学習ツールとしての役割
初心者にとって、サーバーのセットアップはWordPress学習における最大の障壁の一つだった。my.WordPress.netを使えば、その工程をスキップして即座にブロックエディタやサイトエディタの操作を学べる。
専門用語や複雑な設定に悩まされることなく、実際に手を動かしながら機能を体験できる。この「習うより慣れろ」を体現した環境は、Web制作の教育現場においても大きな変革をもたらすと予測されている。
App Catalogによる実務的な活用シーン
my.WordPress.netには、特定の用途に合わせて事前設定された「App Catalog（アプリカタログ）」が用意されている。
これらはWordPressのプラグインを組み合わせたパッケージであり、ワンクリックで特定の機能を持ったワークスペースを構築できる。単なるブログシステムを超えた、実務的なツールとしての側面を強調している。
個人用CRM（顧客関係管理）
CRM（Customer Relationship Management）とは、顧客や知人との連絡履歴や属性を管理するためのシステムだ。
my.WordPress.netでは、自分専用の連絡先管理ツールとしてWordPressを利用できる。チャットデータのインポート機能や、再連絡のリマインダー機能を備えた環境が提供される。すべてのデータがローカルに保存されるため、機密性の高い個人情報を外部サーバーに預けるリスクを回避できるのが利点だ。
アルゴリズムに依存しないRSSリーダー
「Friends」プラグインを活用することで、WordPressを自分だけのRSSリーダーとして機能させることができる。
RSSリーダーとは、お気に入りのWebサイトの更新情報を一括で受け取るためのツールだ。SNSのようなアルゴリズムによる情報の取捨選択が行われないため、自分のペースで必要な情報だけを追跡できる。広告や不要な通知に邪魔されない、静かな読書環境が手に入る。
AI連携とナレッジベースの構築
AIアシスタントを統合したワークスペースも提供されている。AIがWordPress内のデータを理解し、プラグインのカスタマイズや新しいブロックの作成をサポートする。
蓄積された情報を基にAIと対話することで、WordPressを自分だけのナレッジベース（知識ベース）へと進化させることが可能だ。AIによるコード生成やコンテンツの要約機能を、安全なローカル環境で活用できるメリットは大きい。
導入前に知っておくべき技術的制約と運用ルール
my.WordPress.netは画期的なツールだが、ブラウザ上で動作するという性質上、いくつかの重要な制約が存在する。
これらは従来のサーバー型WordPressとの大きな違いであり、運用にあたっては正しく理解しておく必要がある。特にデータの永続性とリソースの制限については注意が必要だ。
ストレージ容量と初回起動の負荷
初期状態でのストレージ容量は約100MBに制限されている。大量の高解像度画像や動画をアップロードする用途には向いていない。あくまでテキストベースのメモや、小規模なツールの構築を想定した設計となっている。
また、初回の起動時にはWordPress本体や必要なプログラムをダウンロードするため、表示までに数十秒程度の時間を要する場合がある。一度読み込まれればブラウザにキャッシュされるが、ネットワーク環境によっては待ち時間が発生することを考慮すべきだ。
データの保存場所とバックアップの重要性
データはすべてブラウザの「IndexedDB」という領域に保存される。サーバーに送信されないためプライバシーは守られるが、ブラウザのキャッシュを削除したり、デバイスを紛失したりするとデータは消失する。
そのため、重要な作業を行った後は定期的にバックアップファイルをダウンロードする必要がある。デバイス間での同期機能も現時点では提供されていないため、別のパソコンで同じ環境を使いたい場合は、エクスポートとインポートの作業が必須となる。
ブラウザの互換性とパフォーマンス
WebAssemblyを利用するため、最新のWebブラウザ（Chrome, Firefox, Safari, Edgeなど）を使用することが前提となる。古いブラウザや、極端にスペックの低いデバイスでは動作が不安定になる可能性がある。
ブラウザのメモリを消費して動作するため、多数のタブを開いた状態で重いプラグインを動かすと、動作が重くなることがある。快適な利用には、ある程度のシステムリソースが必要とされる点は留意しておきたい。
ウェブ制作現場における活用の可能性
Web制作会社やエンジニアにとって、my.WordPress.netは業務効率化の強力な武器になり得る。
これまでローカル開発環境の構築には、専用のソフトウェアのインストールや設定が必要だった。my.WordPress.netは、これらの手間を一切排除し、URLを共有するだけで共通の検証環境を立ち上げられる可能性を秘めている。
クライアントへのデモンストレーション
新しい機能やデザインの提案時に、一時的なプレビュー環境として活用できる。サーバーを契約する前の段階で、実際の管理画面を見せながら操作説明を行うことが可能だ。クライアントは自分のブラウザ上で実際にブロックを動かす体験ができ、導入後のイメージを具体化しやすくなる。
プラグイン・テーマの安全な検証
本番環境に影響を与えずに、特定のプラグインが自分のサイト構成で正しく動作するかをテストできる。特に、メジャーアップデート前の挙動確認において、手軽なサンドボックス（隔離された実験場）として機能する。エンジニアは、環境構築の時間を節約し、本来の検証作業に集中できるだろう。
この記事のポイント
- my.WordPress.netは、サーバー不要でブラウザ上で完結する新しいWordPress環境である
- WordPress Playground技術（Wasm）により、高速かつプライベートな動作を実現している
- 個人用CRMやRSSリーダーなど、公開を前提としない「ワークスペース」としての活用が期待される
- データはブラウザ内に保存されるため、定期的な手動バックアップが不可欠である
- Web制作の現場では、手軽なデモ環境やプラグイン検証用のサンドボックスとして有用である
出典
- WordPress.org News「Your Browser Becomes Your WordPress」（2026年3月11日）
- WordPress Playground「Documentation」（2026年3月時点）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験