
Cloud Run instances登場!AIエージェントを月額6ドル弱で常時稼働
Google Cloudが2026年8月27日、常時稼働するAIエージェント向けの新サービス「Cloud Run instances」をプレビュー公開した。サーバーレスの利便性を保ちながら、単一インスタンスを長期間動かし続けるための専用ランタイムだ。
1vCPU・1GiBメモリの構成なら、30日間連続稼働して月額5.70ドル。従来の専用VMと比較すると運用コストと管理負担を大幅に抑えられる。
パーソナルAIエージェントを自宅のPCや専用サーバーで動かしていた開発者にとって、クラウド移行の有力な選択肢になる。本記事ではCloud Run instancesの特徴、料金構造、実際のデプロイ手順までを解説する。
Cloud Run instancesの基本と既存サービスとの違い

Cloud Run instancesは、Google Cloudのサーバーレスコンテナ基盤であるCloud Runの新しい実行モードだ。既存のCloud Run servicesが高スループットなWebサービス向けに設計されているのに対し、Cloud Run instancesは「1つのインスタンスを確実に動かし続ける」ことに特化している。
主な特徴は次の4つにまとめられる。
- オートスケーリングなしの単一インスタンスのみを実行する
- 最大7日間の連続実行と自動再起動ポリシーを標準で備える
- 更新や再起動後も変わらない固定HTTPS URLが発行される
- 使わないときは停止し、必要なときに再開できる
3つの実行環境の違いを比較した図だ。Cloud Run instancesは既存Cloud Runと専用VMの中間的な位置づけで、サーバーレスの手軽さと常時稼働の確実性を両立している。
既存のCloud Run servicesとの決定的な違い
Cloud Run servicesは、リクエストが途絶えるとインスタンスがスケールゼロになる。これは高トラフィックなWeb APIには効率的だが、常に1つのコピーが動き続けることを期待するAIエージェントには不向きだ。一方、Cloud Run instancesはオートスケーリングを行わず、指定した設定のインスタンスを1つだけ動かし続ける。これが最大の設計上の違いになる。
なぜAIエージェントに最適なのか

OpenClawやHermesといったパーソナルAIエージェントは、継続的に動作し、通常は一度に1人のユーザーにしかサービスしない。これらの特性は、ステートレスな高スループットWebサービスとはインフラ要件が大きく異なる。
OpenClawは、ユーザーの代わりにさまざまなタスクを実行するオープンソースのパーソナルAIエージェントだ。使うほど学習して賢くなる。多くのOpenClawユーザーは最初に自分のノートPCで実行し始めるが、ノートPCがスリープするたびに停止してしまう問題に直面する。ここでクラウド上の常時稼働環境が必要になる。
従来の選択肢の問題点
専用VMを借りる方法もあるが、24時間365日の課金、OSのアップデート管理、ファイアウォールのポート開放、HTTPSエンドポイントの構築といった手間が発生する。Cloud Run instancesはこれらの管理タスクをクラウド側に任せつつ、低コストで常時稼働を実現する。
ここでのポイントは、AIエージェントのワークロードが「バースト型」であることだ。普段は待機状態でCPUをほとんど使わず、ユーザーが指示を出した瞬間だけ計算リソースを消費する。共有vCPUとバーストバジェットによる課金モデルは、このバースト型の特性と相性が良い。常時フルパワーのCPUを確保する必要がないため、価格を抑えられる。
料金とコスト構造の分析

1vCPU・1GiBメモリのCloud Run instanceを30日間連続稼働させた場合のコストは5.70ドル。共有vCPUとvCPUバーストバジェットを利用して、低く予測可能な価格で連続実行を実現している。
従来の専用VMと比べると、クラウド料金に大きな差がある。30日間連続稼働でわずか5.70ドルという価格は、個人開発者が気軽に試せる水準だ。
価格設定の分析
5.70ドルという価格は、パーソナルAIエージェントの利用シーンを想定した戦略的な設定だ。個人開発者がノートPCの代わりにクラウドでAIエージェントを常時稼働させるには、月額10ドル以下という心理的なハードルが大きい。Cloud Run instancesはこの価格帯を実現したことで、パーソナルAIエージェントのクラウド移行を加速する可能性がある。
OpenClawデプロイの実践手順

OpenClawをCloud Run instancesにデプロイする手順はシンプルだ。設定ファイルをCloud Storageバケットにアップロードした後、1つのコマンドを実行するだけでデプロイが完了する。
デプロイ後のOpenClawは、使いたい限り動かし続けられる。メッセージングアプリと接続してタスクを任せることも、必要なツールと連携させることも可能だ。
SSHアクセスと今後のアップデート
Cloud Run instancesとCloud Run servicesの両方で、SSHアクセス機能が近日中に提供される予定だ。これにより、実行中のコンテナに直接ログインしてデバッグや設定変更ができるようになる。詳しい手順はCloud Runのcodelabで公開されている。
ユーザー事例と今後の展望

OffDeal社の導入効果
中小企業向けのAI投資銀行を提供するOffDealは、Cloud Run instancesを長期間稼働するエージェントの主要インフラとして利用している。OffDeal社のLuis Ruiz Morel氏によれば、コールドスタートが88%削減され、実装も非常にシンプルで信頼性が高いとのことだ。
コールドスタート88%削減とは、エージェントが待機状態からタスクを開始するまでの起動時間が大幅に短縮されたことを意味する。AIエージェントの応答性がビジネス成果に直結するユースケースでは、この改善は大きな価値となる。
プレビューからGAへ
Cloud Run instancesは現在プレビュー段階で、パフォーマンスを犠牲にせずに新しい種類のワークロードをコスト効率よく実行する手段として提供されている。今後、GA(一般提供)への移行とともに、より多くのAIエージェントワークロードがこの基盤に集約される可能性がある。
Cloud Run instancesの登場は、サーバーレスコンピューティングの適用範囲を「常時稼働するステートフルなワークロード」にまで広げる動きとして捉えられる。従来のサーバーレスは「イベント駆動・ステートレス・短期実行」が前提だったが、AIエージェントのような新しいワークロードの台頭が、この前提を変えつつある。Google Cloudがこのニーズに素早く応えた形だ。
この記事のポイント
- Cloud Run instancesは常時稼働するAIエージェント向けの新しいサーバーレス実行環境
- 単一インスタンスのみ、オートスケーリングなし、最大7日間連続実行
- 1vCPU・1GiBメモリで30日間連続稼働して月額5.70ドル
- 固定HTTPS URLが提供され、停止・再開も自由
- OpenClawを1コマンドでデプロイ可能
- 近日中にSSHアクセス機能が追加予定

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング
AWSは2026年8月6日、Amazon Bedrock AgentCoreに新たな計算オプション「ランタイムインスタンス」を追加した。AIエージェントのプロトタイプを本番環境に移行する際、長時間の状態維持やマルチエージェント協調、GPUアクセスといった要求に応える、永続的なマネージドインフラだ。
従来のAgentCore Runtimeでは、マイクロVM上で最大8時間のステートフルな呼び出しが可能だったが、日をまたぐワークフローやOSレベルへの直接アクセスが必要なシナリオには限界があった。ランタイムインスタンスは、14日間のセッション永続化とEC2ベースのフルマネージド環境を提供し、本格的なエージェント運用基盤を実現する。
ランタイムインスタンスが解決する本番運用の3つの課題

AIエージェントをプロダクションに投入するとき、開発者はインフラの壁にぶつかる。ランタイムインスタンスはその3つの主要な課題を解消する。
長時間の状態維持とセッション永続化
通常のサーバーレス実行環境では、処理が終わるとメモリやストレージが破棄される。エージェントが数時間〜数日にわたる複数ステップのワークフローを扱う場合、途中結果を外部ストレージに退避させるなどの手間が生まれる。ランタイムインスタンスでは、最大14日間の共有セッションストレージが標準で提供される。セッションは停止・再開が可能で、アイドル期間のコストを抑えながら、必要なときに前回の状態から処理を再開できる。
マルチエージェントの同一ホスト協調
現実の複雑なタスクは、コード生成・レビュー・テスト・デプロイといった複数の専門エージェントが連携して初めて完結する。ランタイムインスタンスでは、複数のエージェントを同一のEC2ホストにデプロイし、共有ファイルシステムを介して直接データをやり取りできる。API呼び出しやネットワーク越しのストレージを挟むオーバーヘッドがなく、シームレスな協調が可能だ。
GPUとOSへの直接アクセス
画像認識や動画解析、重い数値計算を伴うエージェントはGPUを必要とする。ランタイムインスタンスはGPUアクセラレーテッドなインスタンスタイプに対応し、OSレベルへのアクセスも提供する。コードのコンパイル、セキュリティスキャン、GUI自動操作など、コンテナだけでは実現しにくいタスクをエージェントに任せられる。
コードライターとレビュアーの連携を実際に見る

公式デモでは、自然言語でPythonコードを生成する「コードライターエージェント」と、生成されたコードのバグやスタイルをレビューする「コードレビュアーエージェント」を同じランタイムインスタンス上にデプロイし、協調動作させる手順が紹介された。
このデモのポイントは、2つのエージェントが完全に独立したアプリケーションでありながら、セッションIDで紐づく共有ディレクトリを経由してファイルをやり取りする点にある。外部APIを呼び出すことなく、同一ホストのファイルシステム上で完結するため、レイテンシが極めて小さい。
/tmp/agentcore-session/{session_id}/code.py に書き込む各エージェントはStrands Agentsフレームワークと好みのモデル(デモではClaude Sonnet)を使い、単一のPythonファイルに @app.entrypoint デコレータを付けるだけで実装できる。パッケージングもzipまたはコンテナイメージで済み、インフラ管理の負担は大きく軽減される。
セットアップから初回実行までの流れ

ランタイムインスタンスの利用は、大きく3つのステップで完了する。AWSマネジメントコンソールを使う場合の手順を簡潔にまとめた。
- 容量プロバイダの作成 、 エージェントが稼働するEC2インスタンスのスペックとネットワークを定義する。OS(ARM64またはx86_64)、インスタンスタイプ、VPC、サブネット、セキュリティグループを設定。ストレージはgp3ボリュームがデフォルトで用意される。
- ランタイムの作成とエージェントのデプロイ 、 コンピュートタイプに「Instances」を選び、先ほど作成した容量プロバイダを紐づける。エージェントのコードをzipでアップロードし、ランタイム(Python 3.11〜3.14)とエントリポイントを指定。IAMロールもコンソールが自動生成する。
- エージェントの呼び出しと協調 、 デプロイ完了後、コンソールの「Runtime playground」からテスト用のJSONペイロードを送信できる。セッションIDを明示的に指定し、同じIDで別のエージェントを呼び出せば、両者が同一の共有ストレージを使ってシームレスに連携する。
容量プロバイダは一度作成するとOSやインスタンスタイプの変更ができない。本番用と検証用を分けるなど、事前の設計が求められる。
主要スペックと料金モデル

- 対応OS 、 Linux(ARM64、x86_64)。Windowsは現時点ではサポート外
- セッション持続 、 最大14日間。停止・再開が可能で、アイドル中のコスト削減に有効
- ランタイム 、 Python 3.11〜3.14(ネイティブコードに対応)。コンテナイメージのデプロイもサポート
- GPU 、 対応インスタンスタイプを選択すれば、GPUを使った推論や計算が可能
- 統合 、 既存のAgentCore API、IAM、監視機能と完全互換。マイクロVMとのハイブリッド構成も取れる
- 料金 、 使用したEC2インスタンスの標準料金に、AgentCoreオーケストレーションの管理手数料が加算される
- リージョン 、 米国東部(オハイオ、バージニア北部)、米国西部(オレゴン)、アジアパシフィック(ムンバイ、シンガポール、シドニー、東京)、欧州(フランクフルト、アイルランド)
マイクロVMベースの従来のAgentCore Runtimeとランタイムインスタンスは、同じAPIセットで併用できる。軽量なオーケストレーターエージェントをマイクロVM側に置き、重い処理や永続状態が必要なワーカーエージェントをインスタンス側に委譲するハイブリッド構成が、現実的なアーキテクチャパターンとして紹介されている。
始め方と最初の一歩

ランタイムインスタンスを試すには、Amazon Bedrock AgentCoreのドキュメントに掲載されているランタイムインスタンスの公式ガイドを参照し、容量プロバイダの作成から始めるのが近道だ。コンソールの左ナビゲーションから「Runtime」→「Capacity providers」を選び、今回紹介した手順に沿って設定すれば、最初のエージェントデプロイまで数分で到達できる。
この記事のポイント
- ランタイムインスタンスは、最大14日間のセッション永続化とEC2ベースのマネージド環境を提供するAgentCore新オプション
- 同一ホスト上でのマルチエージェントファイル共有により、APIを介さないシームレスな協調が可能
- GPUインスタンスやOS直接アクセスが必要な高度なエージェントワークロードに対応
- 従来のマイクロVMと組み合わせたハイブリッド構成で、軽量なオーケストレーションと重いバックエンド処理を分離できる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

DynamoDBにベクトル検索がGA、リアルタイムな類似検索が可能に
AWSは2026年8月5日、Amazon DynamoDBにベクトル検索機能を正式に追加した。これにより、既存の運用データと同じテーブルに埋め込みベクトルを格納し、類似度にもとづくリアルタイムな検索が可能になる。
従来、ベクトル検索を追加するには専用のベクトルデータベースを用意し、データの同期パイプラインを自前で維持する必要があった。今回の発表によって、DynamoDBだけでミリ秒単位の低レイテンシと99%以上の再現率、トリリオン規模のベクトルに対応するスケーラビリティが手に入る。サーバーやソフトウェアの管理は一切不要で、ゼロダウンタイムのメンテナンスが保証される。
DynamoDBにベクトル検索が一般提供開始

ベクトルインデックスにはストレージ制限がなく、データの増大に合わせて水平スケールする。セマンティックな検索が必要なエージェント向けメモリ、検索拡張生成(RAG)、レコメンデーションエンジン、パーソナライズされた体験、異常検知などのユースケースを、DynamoDBのネイティブ機能として実装できる。
ベクトル検索の機能は、最大4096次元のベクトルに対応し、ユークリッド距離、コサイン類似度、ドット積のいずれかの距離関数を選択可能。また、パーティションキーによるスコープ指定や、インラインフィルタを使った絞り込みにも対応する。
ベクトル検索統合の背景とメリット

DynamoDBをすでに利用しているアプリケーションでは、これまでセマンティック検索を追加するために、専用のベクトルデータベースを別途プロビジョニングし、テーブル間でデータの同期を維持するパイプラインを構築・運用する必要があった。この構成は追加の運用コスト、データ転送料金、ライセンス費用に加え、大規模環境での低レイテンシ維持を難しくする要因だった。
DynamoDBのベクトル検索では、ベクトルと運用データが同一のサーバーレス基盤で管理され、同じ従量課金モデルが適用される。これにより、同期パイプラインや外部ベクトルストアの運用から解放される。
検索の仕組みとAPIの使い方

DynamoDBのベクトル検索は、既存のテーブルに新しいタイプのインデックスを追加する方式で実現する。ユーザーは任意の埋め込みモデル(Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAIの埋め込みモデルなど)を使ってベクトルを生成し、標準のPutItemまたはUpdateItem APIでフロート値のリストとしてテーブルに格納する。その後、対象の属性に対してベクトルインデックスを作成し、次元数と距離関数、オプションのフィルタ属性を指定する。
List型でベクトルを格納検索時はSearchVectors APIを使い、クエリベクトルと返却件数(最大100件)、オプションのフィルタ条件を指定する。結果は類似度順にランキングされて返る。パーティションキーを指定すれば、特定の市場やテナントに対象を絞り込んだ検索も可能だ。インラインフィルタでは完全一致のみサポートしており、範囲条件(BETWEENなど)は利用できない。
距離関数は、コサイン類似度がテキスト埋め込みの意味比較に効果的だが、ユークリッド距離はベクトルの大きさが意味を持つ場合(購入数によるクラスタリングなど)に、ドット積は方向と大きさの両方を評価するレコメンデーションシステムに適する。埋め込みモデルを訓練した際の距離関数と合わせるのが精度を上げる基本になる。
既存テーブルへの追加手順

AWSの公式ブログでは、スポーツ用品のオンラインストアを例に、商品カタログテーブルへのベクトル検索の追加手順が紹介されている。すでにproductId、category、descriptionなどの属性を持つテーブルに、商品説明の埋め込みベクトルを追加していく流れだ。
まず、既存の商品説明テキストから埋め込みモデルを使ってベクトルを生成し、UpdateItem呼び出しでdescriptionEmbeddingという新しい属性として各アイテムに追加する。DynamoDBは既存のListデータ型をそのまま使い、スキーマ変更や新しいデータ型の追加は不要。各要素が埋め込みの1次元に対応するNumber型のリストとして格納される。
次に、DynamoDBコンソールでテーブルの「インデックス」タブを開き、「ベクトルインデックスの作成」を選択する。インデックス名、ベクトル属性(descriptionEmbedding)、次元数(埋め込みモデルに合わせる)、距離関数(ここではコサイン)、パーティションキー(例:marketplace)、インラインフィルタ属性(例:category)を設定する。パーティションキーはオプションだが、大規模データで高スループットを保つために推奨される。
インデックスがアクティブになったら、同じ埋め込みモデルで生成したクエリベクトルを使って検索を実行する。コンソールの「項目の探索」からベクトル検索モードに切り替え、インデックスとクエリベクトル、トップK、パーティションキー値、フィルタ条件を入力する。この例では「US」マーケットプレイスに絞り、カテゴリを「footwear」に限定して「軽量の夏用ランニングシューズ」といった自然言語に近いクエリで類似商品を取得できる。
返却される結果には、類似度スコアと共に商品名や価格などの運用属性が含まれる。コサイン距離とユークリッド距離ではスコアが小さいほど類似度が高く、0は同一ベクトルを示す。ドット積では大きい値が類似度の高さを示す。
想定されるユースケースと拡張性

ベクトル検索がDynamoDBに統合されたことで、セマンティック検索が必要な様々なアプリケーションを単一のデータベースで実現できる。たとえば、エージェントの過去の対話や記憶をベクトル化して素早く参照するエージェントメモリ、大規模言語モデルの回答精度を高めるRAG、ユーザーの行動履歴から類似商品を即座に提示するレコメンデーション、個人の好みに応じたコンテンツのパーソナライズ、過去のパターンとの類似性から異常を検出する監視システムなどが挙げられる。
また、4096次元までのベクトルに対応し、距離関数やフィルタの選択肢も実用的だ。マルチテナントアプリケーションでは、パーティションキーで検索範囲をテナント単位に区切れるため、全データをスキャンすることなく高いスループットを維持できる。あらゆる商用AWSリージョンおよびGovCloudリージョンで利用可能となっている。
この記事のポイント
- DynamoDBのネイティブ機能としてベクトル検索が一般提供開始された
- 運用データと同じテーブルに埋め込みを格納し、ミリ秒単位で類似検索が可能
- 専用ベクトルDBや同期パイプラインが不要になり、サーバーレスでスケールする
- 最大4096次元、コサイン・ユークリッド・ドット積の距離関数をサポート
- RAG、レコメンデーション、エージェントメモリ、異常検知など幅広い用途に対応

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

Cloud Runのマルチリージョン高可用性が強化、障害検知と自動復旧が数秒単位に
発表の概要

Google Cloudは2026年7月20日、Cloud Runにおけるマルチリージョン高可用性の機能強化を発表した。ミッションクリティカルなアプリケーションのダウンタイムは、企業の収益や評判に直結する問題だ。これに対処するため、Cloud Runは単一コマンドで複数リージョンに同一サービスを展開できる設計をとってきたが、今回のアップデートで障害検知と自動復旧の精度が大幅に向上している。
新たに導入された機能は「Readiness Probe」と「Service Health」の2つだ。インスタンスレベルの死活監視とリージョンレベルの健全性評価を組み合わせることで、リージョン障害が発生した際のトラフィック迂回が数秒単位で自動化される。
マルチリージョン高可用性を支える2つの新機能

Readiness Probeの役割は「個々のコンテナが外部リクエストを受け付けられる状態か」を確認することだ。この結果はCloud Runコンソールからもリージョン別に確認でき、どのリージョンでインスタンスが縮退しているかが一目で分かる。
Service Healthはこのプローブ結果をリージョン単位で集約するレイヤーにあたる。複数のヘルスチェック結果を「そのリージョンが正常に稼働しているかどうか」というひとつの評価に落とし込み、グローバルロードバランサがこの評価に基づいてルーティングを切り替える。この仕組みにより、障害発生時の手動オペレーションが原則不要になる。
パブリックとプライベートで異なる自動フェイルオーバーの経路

自動フェイルオーバーを実現するには、トラフィックが流入してくるネットワーク層によってロードバランサの種類を選択する必要がある。Cloud Runは外部向けと内部向けで最適なバランサ構成を用意している。
この構成の利点は、どちらのパターンでもロードバランサ側が自動でService Healthを参照し、異常リージョンをルーティング対象から外してくれる点にある。手動でのDNS切り替えや手作業によるトラフィック操作が不要になるため、復旧までの時間が大幅に短縮される。
設計段階で押さえるべき3つのポイント

Service Healthの活用を前提にマルチリージョン構成を設計する際、見落としやすい検討項目が3つある。いずれも高可用性に直結するため、初期段階で整理しておくことが望ましい。
単一障害点をなくすには、インフラ層だけでなくアプリケーション自体のステートレス設計が前提になる。データ層を別途冗長化し、ロードバランサの背後で自由にインスタンスを入れ替えられる状態を作っておくことが、Cloud Runのマルチリージョン構成を最大限活かす秘訣だ。
利用開始とコスト
Cloud Runのマルチリージョン高可用性に関する一連の機能は、すでに全リージョンで利用可能だ。Service Healthの機能そのものに追加料金は発生しない。Readiness Probeの実行に伴う標準的なCPU・メモリ消費のみが課金対象となる。
導入にあたっては、既存のCloud RunサービスにReadiness Probeを設定し、Service Healthを有効にしたうえで適切なロードバランサに接続するだけでよい。公式ドキュメントにチュートリアルが用意されており、少ないステップでマルチリージョン高可用性の基盤を整えられる。
この記事のポイント
- Readiness Probeがコンテナ単位の死活監視を行い、Service Healthがリージョン単位の健全性を可視化する
- Serverless NEGを通じてグローバルロードバランサに健全性が通知され、障害リージョンを数秒で自動迂回する
- パブリック向けは外部ALB、VPC内向けは内部ALBを選択すれば、どちらも自動フェイルオーバーに対応可能
- DB層を含めた全レイヤーでの冗長化と、データレプリケーションの方針決定が設計の鍵を握る
- 機能追加に伴う追加コストはなく、通常のリソース消費のみで全リージョンですぐに利用を開始できる

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

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最適化の豊富な経験
