Category Archive クラウド・インフラ

Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング

Amazon Bedrock AgentCoreにランタイムインスタンス発表、本番AIエージェント向け永続コンピューティング

AWSは2026年8月6日、Amazon Bedrock AgentCoreに新たな計算オプション「ランタイムインスタンス」を追加した。AIエージェントのプロトタイプを本番環境に移行する際、長時間の状態維持やマルチエージェント協調、GPUアクセスといった要求に応える、永続的なマネージドインフラだ。

従来のAgentCore Runtimeでは、マイクロVM上で最大8時間のステートフルな呼び出しが可能だったが、日をまたぐワークフローやOSレベルへの直接アクセスが必要なシナリオには限界があった。ランタイムインスタンスは、14日間のセッション永続化とEC2ベースのフルマネージド環境を提供し、本格的なエージェント運用基盤を実現する。

ランタイムインスタンスが解決する本番運用の3つの課題

ランタイムインスタンスが解決する本番運用の3つの課題

AIエージェントをプロダクションに投入するとき、開発者はインフラの壁にぶつかる。ランタイムインスタンスはその3つの主要な課題を解消する。

長時間の状態維持とセッション永続化

通常のサーバーレス実行環境では、処理が終わるとメモリやストレージが破棄される。エージェントが数時間〜数日にわたる複数ステップのワークフローを扱う場合、途中結果を外部ストレージに退避させるなどの手間が生まれる。ランタイムインスタンスでは、最大14日間の共有セッションストレージが標準で提供される。セッションは停止・再開が可能で、アイドル期間のコストを抑えながら、必要なときに前回の状態から処理を再開できる。

マルチエージェントの同一ホスト協調

現実の複雑なタスクは、コード生成・レビュー・テスト・デプロイといった複数の専門エージェントが連携して初めて完結する。ランタイムインスタンスでは、複数のエージェントを同一のEC2ホストにデプロイし、共有ファイルシステムを介して直接データをやり取りできる。API呼び出しやネットワーク越しのストレージを挟むオーバーヘッドがなく、シームレスな協調が可能だ。

GPUとOSへの直接アクセス

画像認識や動画解析、重い数値計算を伴うエージェントはGPUを必要とする。ランタイムインスタンスはGPUアクセラレーテッドなインスタンスタイプに対応し、OSレベルへのアクセスも提供する。コードのコンパイル、セキュリティスキャン、GUI自動操作など、コンテナだけでは実現しにくいタスクをエージェントに任せられる。

コードライターとレビュアーの連携を実際に見る

コードライターとレビュアーの連携を実際に見る

公式デモでは、自然言語でPythonコードを生成する「コードライターエージェント」と、生成されたコードのバグやスタイルをレビューする「コードレビュアーエージェント」を同じランタイムインスタンス上にデプロイし、協調動作させる手順が紹介された。

このデモのポイントは、2つのエージェントが完全に独立したアプリケーションでありながら、セッションIDで紐づく共有ディレクトリを経由してファイルをやり取りする点にある。外部APIを呼び出すことなく、同一ホストのファイルシステム上で完結するため、レイテンシが極めて小さい。

STEP 1 コードライターエージェントが自然言語プロンプトを受け取る
STEP 2 生成したコードを /tmp/agentcore-session/{session_id}/code.py に書き込む
STEP 3 同じセッションIDで起動したコードレビュアーエージェントがファイルを読み込む
STEP 4 バグやスタイルの問題を指摘したレビュー結果を返す
ライターエージェント  共有セッションストレージ  レビュアーエージェント

各エージェントは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と組み合わせたハイブリッド構成で、軽量なオーケストレーションと重いバックエンド処理を分離できる
DynamoDBにベクトル検索がGA、リアルタイムな類似検索が可能に

DynamoDBにベクトル検索がGA、リアルタイムな類似検索が可能に

AWSは2026年8月5日、Amazon DynamoDBにベクトル検索機能を正式に追加した。これにより、既存の運用データと同じテーブルに埋め込みベクトルを格納し、類似度にもとづくリアルタイムな検索が可能になる。

従来、ベクトル検索を追加するには専用のベクトルデータベースを用意し、データの同期パイプラインを自前で維持する必要があった。今回の発表によって、DynamoDBだけでミリ秒単位の低レイテンシと99%以上の再現率、トリリオン規模のベクトルに対応するスケーラビリティが手に入る。サーバーやソフトウェアの管理は一切不要で、ゼロダウンタイムのメンテナンスが保証される。

DynamoDBにベクトル検索が一般提供開始

DynamoDBにベクトル検索が一般提供開始

ベクトルインデックスにはストレージ制限がなく、データの増大に合わせて水平スケールする。セマンティックな検索が必要なエージェント向けメモリ、検索拡張生成(RAG)、レコメンデーションエンジン、パーソナライズされた体験、異常検知などのユースケースを、DynamoDBのネイティブ機能として実装できる。

ベクトル検索の機能は、最大4096次元のベクトルに対応し、ユークリッド距離、コサイン類似度、ドット積のいずれかの距離関数を選択可能。また、パーティションキーによるスコープ指定や、インラインフィルタを使った絞り込みにも対応する。

ベクトル検索統合の背景とメリット

ベクトル検索統合の背景とメリット

DynamoDBをすでに利用しているアプリケーションでは、これまでセマンティック検索を追加するために、専用のベクトルデータベースを別途プロビジョニングし、テーブル間でデータの同期を維持するパイプラインを構築・運用する必要があった。この構成は追加の運用コスト、データ転送料金、ライセンス費用に加え、大規模環境での低レイテンシ維持を難しくする要因だった。

従来の構成(Before)
DynamoDB 運用データ
同期パイプライン リアルタイム同期が必須
専用ベクトルDB メンテナンスと追加コスト
統合後の構成(After)
DynamoDB 運用データ+ベクトル埋め込み
サーバーレス、単一の従量課金モデル

DynamoDBのベクトル検索では、ベクトルと運用データが同一のサーバーレス基盤で管理され、同じ従量課金モデルが適用される。これにより、同期パイプラインや外部ベクトルストアの運用から解放される。

検索の仕組みとAPIの使い方

検索の仕組みとAPIの使い方

DynamoDBのベクトル検索は、既存のテーブルに新しいタイプのインデックスを追加する方式で実現する。ユーザーは任意の埋め込みモデル(Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAIの埋め込みモデルなど)を使ってベクトルを生成し、標準のPutItemまたはUpdateItem APIでフロート値のリストとしてテーブルに格納する。その後、対象の属性に対してベクトルインデックスを作成し、次元数と距離関数、オプションのフィルタ属性を指定する。

STEP 1 埋め込みモデルでテキストをベクトル化
STEP 2 DynamoDBテーブルにList型でベクトルを格納
STEP 3 ベクトル属性にインデックスを作成
STEP 4 SearchVectors APIで類似検索を実行

検索時はSearchVectors APIを使い、クエリベクトルと返却件数(最大100件)、オプションのフィルタ条件を指定する。結果は類似度順にランキングされて返る。パーティションキーを指定すれば、特定の市場やテナントに対象を絞り込んだ検索も可能だ。インラインフィルタでは完全一致のみサポートしており、範囲条件(BETWEENなど)は利用できない。

距離関数は、コサイン類似度がテキスト埋め込みの意味比較に効果的だが、ユークリッド距離はベクトルの大きさが意味を持つ場合(購入数によるクラスタリングなど)に、ドット積は方向と大きさの両方を評価するレコメンデーションシステムに適する。埋め込みモデルを訓練した際の距離関数と合わせるのが精度を上げる基本になる。

既存テーブルへの追加手順

既存テーブルへの追加手順

AWSの公式ブログでは、スポーツ用品のオンラインストアを例に、商品カタログテーブルへのベクトル検索の追加手順が紹介されている。すでにproductIdcategorydescriptionなどの属性を持つテーブルに、商品説明の埋め込みベクトルを追加していく流れだ。

まず、既存の商品説明テキストから埋め込みモデルを使ってベクトルを生成し、UpdateItem呼び出しでdescriptionEmbeddingという新しい属性として各アイテムに追加する。DynamoDBは既存のListデータ型をそのまま使い、スキーマ変更や新しいデータ型の追加は不要。各要素が埋め込みの1次元に対応するNumber型のリストとして格納される。

次に、DynamoDBコンソールでテーブルの「インデックス」タブを開き、「ベクトルインデックスの作成」を選択する。インデックス名、ベクトル属性(descriptionEmbedding)、次元数(埋め込みモデルに合わせる)、距離関数(ここではコサイン)、パーティションキー(例:marketplace)、インラインフィルタ属性(例:category)を設定する。パーティションキーはオプションだが、大規模データで高スループットを保つために推奨される。

ベクトルインデックス設定の要点
インデックス名任意の名前(例:ProductDescriptionIndex)
ベクトル属性埋め込みを格納したリスト属性
次元数埋め込みモデルの出力に合わせる(最大4096)
距離関数コサイン / ユークリッド / ドット積
フィルタ属性検索時に完全一致で絞り込む属性(オプション)

インデックスがアクティブになったら、同じ埋め込みモデルで生成したクエリベクトルを使って検索を実行する。コンソールの「項目の探索」からベクトル検索モードに切り替え、インデックスとクエリベクトル、トップK、パーティションキー値、フィルタ条件を入力する。この例では「US」マーケットプレイスに絞り、カテゴリを「footwear」に限定して「軽量の夏用ランニングシューズ」といった自然言語に近いクエリで類似商品を取得できる。

返却される結果には、類似度スコアと共に商品名や価格などの運用属性が含まれる。コサイン距離とユークリッド距離ではスコアが小さいほど類似度が高く、0は同一ベクトルを示す。ドット積では大きい値が類似度の高さを示す。

想定されるユースケースと拡張性

想定されるユースケースと拡張性

ベクトル検索がDynamoDBに統合されたことで、セマンティック検索が必要な様々なアプリケーションを単一のデータベースで実現できる。たとえば、エージェントの過去の対話や記憶をベクトル化して素早く参照するエージェントメモリ、大規模言語モデルの回答精度を高めるRAG、ユーザーの行動履歴から類似商品を即座に提示するレコメンデーション、個人の好みに応じたコンテンツのパーソナライズ、過去のパターンとの類似性から異常を検出する監視システムなどが挙げられる。

ユースケース RAGやエージェントメモリ
外部ベクトルDB不要で意味検索を組み込み
データ規模 トリリオンオーダーのベクトルに対応
水平スケール、ストレージ制限なし
パフォーマンス 単一桁ミリ秒、99%以上の再現率
サーバーレスで自動スケール、ダウンタイムゼロ
フィルタリング パーティションキー+インラインフィルタ
マルチテナントやカテゴリ別の絞り込みが高速

また、4096次元までのベクトルに対応し、距離関数やフィルタの選択肢も実用的だ。マルチテナントアプリケーションでは、パーティションキーで検索範囲をテナント単位に区切れるため、全データをスキャンすることなく高いスループットを維持できる。あらゆる商用AWSリージョンおよびGovCloudリージョンで利用可能となっている。

この記事のポイント

  • DynamoDBのネイティブ機能としてベクトル検索が一般提供開始された
  • 運用データと同じテーブルに埋め込みを格納し、ミリ秒単位で類似検索が可能
  • 専用ベクトルDBや同期パイプラインが不要になり、サーバーレスでスケールする
  • 最大4096次元、コサイン・ユークリッド・ドット積の距離関数をサポート
  • RAG、レコメンデーション、エージェントメモリ、異常検知など幅広い用途に対応
Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflare AI Searchがエージェント検索を簡素化、公開エンドポイントと価格プレビュー発表

Cloudflareは2026年8月6日、AI Searchに大規模な機能拡張を発表した。従来はWorkers AIやVectorize、R2、Browser Runといった複数のプリミティブを組み合わせて独自の検索パイプラインを構築する必要があった。今回のアップデートによりAI Searchがこれらの処理を自動化し、開発者やエージェントが、まるで自前の検索エンジンを持っているかのような感覚で扱えるようになった。

新機能として、複数のWebサイトやファイルを横断して検索できる公開エンドポイントの提供、サイトマップ不要のクロール機能、カスタムドメインによるブランディング、EmDash CMS向けの検索プラグインなどが追加された。さらにプレビュー価格モデルも発表され、デフォルトの埋め込み・リランキングモデルを利用すれば、これらの処理が無料になる予測可能な料金体系が示されている。エージェントが信頼できる情報源から回答を引き出せるインフラが、これまでより格段に手軽になった。

AI Searchの主な機能強化点

AI Searchの主な機能強化点
従来の構成(Before)
開発者 手動組み合わせ Workers AI Vectorize R2 Browser Run
それぞれの設定を個別に管理し、データパイプラインを自前で構築する必要があった
AI Searchで統合(After)
開発者 データソース指定 AI Search が自動処理
クローリング 埋め込み リランキング 検索API
1コマンドでセットアップし、即座に検索エンドポイントが利用可能

AI Searchを導入する前は、ベクトル化したデータの格納先やクローリングの仕組み、リランキングのパイプラインなどを開発者が自前で組み上げる必要があった。しかし今回の強化により、それらの低レベルなサービスを意識せずに済む。結果としてエージェントが信頼できる最新情報を引き出せるインフラが、数分で立ち上がるようになった。

インデックス作成の簡素化

これまでAI SearchでWebサイトをインデックスに追加する際は、サイトマップが必須だった。しかし新たに追加された「Discover」パースオプションを使えば、サイトマップがなくてもページ内のリンクを辿って自動的にコンテンツを収集できる。Cloudflareアカウントに登録されたゾーンであれば、特定のページから始まる全サイトデータを取り込めるようになった。

さらに、HTMLやPDFなどの非構造化データから構造化データまで、幅広いファイル形式に対応した取り込みが可能になった。これにより社内Wikiや製品マニュアルといった多様なデータソースをエージェントの検索対象に加えやすくなっている。

公開検索/MCPエンドポイント

ネームスペースに対して公開URLを有効化すると、/search/mcp のエンドポイントが即座に利用できるようになる。/search は通常のREST APIとして、/mcp はモデルコンテキストプロトコル(MCP)に対応した形で提供される。どちらも認証不要で、複数のインスタンスにまたがる横断検索を1つのリクエストで実行できる。

外部のエージェントやアプリケーションに検索機能を提供したい場合、このエンドポイントをそのまま公開するだけで済む。Cloudflare以外の顧客に自社データへアクセスしてもらうシナリオでも、認証が不要で、URLを渡すだけのシンプルな共有が可能になっている。

EmDashとの統合とbotポリシー

Cloudflareが公開しているOSSのCMS「EmDash」向けに、AI Searchプラグインが提供された。これを導入すると、EmDashで構築したサイト内にセマンティック検索を組み込める。実際にCloudflare BlogやDeveloper Docsもこの仕組みで動いている。

また、AI Searchのクローラは独自のユーザーエージェント「Cloudflare-AI-Search」を使い、各サイトのrobots.txtに従う。ブラウザベースのクローリング機能を使う場合でも、このポリシーは変わらない。サイト運営者がクロールを拒否すれば収集が停止されるため、著作権や利用規約上の配慮が十分になされている。

Cloudflare Dev Stack MCPの実装事例

Cloudflare Dev Stack MCPの実装事例

Cloudflare自身がAI Searchをどう活用しているかを示す好例が、新しく公開された「Cloudflare Dev Stack MCP」だ。これはCloudflareのエコシステム全体(ドキュメント、ブログ、APIリファレンス、コミュニティなど)を横断検索し、コーディングエージェントへ最新の引用付き回答を返す仕組みである。古いトレーニングデータではなく、常にフレッシュな情報を基にコードを生成できる。

インスタンス作成とクロール

CloudflareはDocs、Blog、API Docs、コミュニティ、Astro、Viteなど計10以上のサイトに対して、それぞれ個別のAI Searchインスタンスを作成した。各インスタンスはドメインが異なるが、Cloudflareが所有するサイトデータであるため、統一的な方法でクロールできる。

npx wrangler ai-search instance create cloudflare-community \
  --namespace dev-stack \
  --source https://community.cloudflare.com \
  --type web-crawler \
  --parse-type discover

上記のコマンドでは、--parse-type discover を指定することでサイトマップなしにページを発見するクロールを実行している。この内部ではBrowser Runの/crawl機能が使用され、リンクを辿って再帰的にページを見つけ出す。

Workerを使ったマルチインスタンス統合

10個のインスタンスにまたがる横断検索を実現するため、CloudflareはWorkerを用いたMCPサーバを構築した。wrangler.jsonにAI Searchネームスペースのバインディングを追加し、1つのツール呼び出しで全インスタンスを同時に検索する。

{
  "ai_search_namespaces": [
    { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" }
  ]
}
context.registerTool(
  'search_dev_stack',
  {
    description: 'Search current docs across the Cloudflare stack.',
    inputSchema: z.object({ query: z.string() }),
  },
  async ({ query }) => {
    const res = await context.env.AI_SEARCH.search({
      query,
      ai_search_options: {
        instance_ids: ['developers-cloudflare-com', 'astro', /* ... */],
        retrieval: { max_num_results: 10 },
        reranking: { enabled: true },
      },
    })
    return { content: [{ type: 'text', text: format(res.chunks) }] }
  }
)

この方式により、エージェントが単一のツール呼び出しで全ドキュメントを検索でき、結果にはどのインスタンスから取得されたかのメタデータが付与される。複数の検索先を順に叩く必要がなく、応答速度も一括で処理される。

コード不要の公開エンドポイントも選択可能

Workerを書かずに済ませたい場合、ネームスペースの公開URLを有効化するだけで、すべてのインスタンスにクエリを投げる/searchおよび/mcpエンドポイントが得られる。設定画面からワンクリックで有効化でき、即座に利用を開始できる。Cloudflare自身のMCPサーバもこの公開エンドポイントを活用している。

Workerを使う場合(カスタム制御)
開発者 Worker実装 MCPサーバ 経由で検索
既存アプリやエージェントに検索を組み込む場合に適する
公開エンドポイント(ノーコード)
管理者 ワンクリック有効化 /search /mcp エンドポイント公開
すぐにURLを共有でき、ブラウザやエージェントから直接呼び出せる

コードを書く場合は細かいチューニングやMCPツールとしての統合が可能で、コードを書かない場合は設定画面上の操作だけで外部共有が完了する。どちらの選択肢も提供されている点が、利用者のスキルや要件に応じた柔軟な導入を後押しする。

公開エンドポイントとカスタムドメインで検索を共有

公開エンドポイントとカスタムドメインで検索を共有

AI Searchでは、公開エンドポイントに独自のカスタムドメインを割り当てられる。デフォルトのCloudflare管理URLではなく、search.example.com/mcpといったブランド化されたエンドポイントを用意できるため、サービス提供時の信頼感が高まる。

さらに、検索を限定公開したいケースではCloudflare Accessを介した認証ゲートを追加できる。これによりエンドポイントへのアクセスを許可された人物やエージェントだけに制限し、認証情報を持たない第三者からの不正なクエリを防げる。社内データや顧客限定の検索サービスを安全に運用できる設計になっている。

デフォルト公開URL(無設定)
https://xxx.ai-search.cloudflare.com/search 認証なし
短時間の試験や内部検証には十分だが、ブランド観点では不十分
カスタムドメイン + Access制御(推奨)
search.example.com/mcp Cloudflare Access でログイン必須
ブランド力とセキュリティを両立し、顧客向け公開に最適

このカスタムドメイン機能は、SaaSプロダクトやエージェントサービスを展開する事業者にとってとくに有用だ。自社ブランドのURLで検索APIを提供することで、サービス全体の統一感が生まれ、導入先からの信頼獲得につながる。

プレビュー価格モデルでコストを予測可能に

プレビュー価格モデルでコストを予測可能に

AI Searchは現在ベータ版として無料提供されているが、正式版に向けたプレビュー価格が公開された。課金開始前には十分な通知が行われる予定だ。料金設計の中心にある考え方は「予測可能でスケーラブル」であり、埋め込みとリランキングをデフォルトモデル利用時に無料化することで、トークン数の見積もりに頭を悩ませる必要をなくしている。

料金の主な内訳

  • インジェスト(テキスト): $0.75 / 1Mトークン。月間無料枠5Mトークン。
  • 画像処理アドオン: +$0.50 / 1Mトークン。画像の埋め込みに使用される。
  • ストレージ: $2.00 / GB・月。月間無料枠10GB。
  • セマンティック検索(ハイブリッド+ベクトル): $0.75 / 1,000クエリ。無料枠2,000クエリ。
  • 全文検索: $0.10 / 1,000クエリ。同上の無料枠と共有。
  • 埋め込みとリランキング: 指定モデル利用時は無料。それ以外はWorkers AIの従量課金。

無料枠はインジェスト5Mトークンと検索2,000クエリがそれぞれ一つのプールとしてまとめられており、用途を気にせず使い切れる。埋め込みやリランキングのコストが気にならないため、データ更新や再インデックスの頻度を高めやすい。これは頻繁に情報が変わるナレッジベースをエージェントに与えたい開発者にとって大きなメリットだ。

2万ドキュメント規模の試算例

以下は、2万件の文書(約2,000万トークン)と1,000枚の画像をインジェストし、月間3万回のセマンティッククエリを実行した場合の想定コストである。ワーカーズ有料プランが前提で、埋め込みとリランキングにはデフォルトモデルを使用する。

  • インジェスト(テキスト): 18.1Mトークン × $0.75/1M = $13.58
  • 画像アドオン: 1.1Mトークン × $0.50/1M = $0.55
  • ストレージ: 約1.2GB → 無料枠内で$0
  • 検索: 28,000クエリ × $0.75/1k = $21.00
  • 埋め込み・リランキング: $0
  • 合計: 約$35.13

初月にインジェスト費用がかかるが、2か月目以降は主に検索クエリ分だけ(この例では約$21)で運用できる。ドキュメントの大幅な増加がなければ、ランニングコストを低く抑えられる構造だ。

初月のコスト内訳イメージ
インジェスト $13.58 + $0.55 検索$21
埋め込み・リランキングは無料
2か月目以降の月額
検索のみ 約$21.00
インジェスト費用が不要で、クエリ数に応じた変動

このように、AI Searchのコストは初回のデータ登録が大部分を占め、その後は利用量に比例した検索料金のみになる。大規模なデータベースを抱える場合でも、固定費ではなく使った分だけ支払うモデルのため、予算計画が立てやすい。

AI Searchの導入方法

AI Searchの導入方法

AI SearchはCloudflareダッシュボードから有効化し、すぐに使い始められる。もっとも簡単な導入は、次のwranglerコマンドでインスタンスを作成する方法だ。

npx wrangler ai-search create my-search \
  --namespace my-namespace \
  --source https://my-website.com \
  --type web-crawler \
  --hybrid-search

この1行でWebクローラー型のインスタンスが立ち上がり、ハイブリッド検索(セマンティック+キーワード)が有効になる。クロールが完了すれば、/searchエンドポイントで検索APIとして利用できる。さらに/mcpエンドポイントを使えば、ChatGPTやClaudeなどのモデルが直接ツールとして呼び出せる。

既存のアプリに組み込む場合はWorker経由でバインドし、エージェントと連携させればよい。カスタムドメインやCloudflare Accessを設定すれば、プライベートな検索サービスとしても公開できる。詳しい手順は公式ドキュメントを参照してほしい。

この記事のポイント

  • Cloudflare AI Searchは、複数サービスの組み合わせを自動化し、データ検索基盤をワンストップで提供する。
  • 公開/MCPエンドポイントやカスタムドメインにより、エージェントへの組み込みや外部共有が容易になった。
  • サイトマップ不要のクロールやEmDash CMSとの統合で、あらゆるデータソースを取り込める。
  • プレビュー価格ではデフォルトモデルの埋め込み・リランキングが無料で、予測しやすいコスト構造が示された。
  • wranglerコマンド1行でセットアップが完了し、すぐにエージェント向け検索エンジンとして利用開始できる。
エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

エージェント開発ライフサイクル(ADLC)がCloudflareで始動。SDLCを超える新たな枠組み

ソフトウェア開発のライフサイクル(SDLC)が、AIエージェントの登場によって根本から再定義されようとしている。Cloudflareは2026年8月4日、エージェント中心の新たな開発モデル「Agent Development Lifecycle(ADLC)」の構想と、それを支える具体的なツールセットを発表した。

従来のSDLCは「計画→設計→実装→テスト→デプロイ→保守」という人間中心の工程だった。しかしAIエージェントがコード生成の速度を劇的に高めた結果、周辺の工程がボトルネック化している。ADLCはこの課題を解決し、エージェントがライフサイクル全体を自律的に管理できる環境を提供する。

ADLC(エージェント開発ライフサイクル)とは何か

ADLC(エージェント開発ライフサイクル)とは何か

ADLCは、従来のSDLC(Software Development Lifecycle)をエージェント時代に合わせて再設計した概念だ。SDLCは1975年にランド研究所が提唱した「Systems Development Lifecycle」を起源とし、長年にわたりソフトウェア開発プロセスの標準だった。しかし、AIエージェントがコードを実装する速度は人間の比ではなく、テストやレビュー、デプロイといった他の工程が追いつかなくなっている。

Cloudflare Blogの著者Carlo Daniele氏によると、AIによって「実装」が最速かつ最安になった一方で、他の工程に携わる人々が膨大なプルリクエストやイシューに圧倒されるという逆説的な状況が生まれている。オープンソースメンテナの疲弊や本番環境の不安定化は、まさにこの非対称性の表れだ。

ADLCは、エージェントが実装だけでなく、テスト・デプロイ・監視・改善までを一貫して担うことを前提とする。そのために必要な要件は、プログラムによる操作が可能(Programmatic)、水平スケーラブル、再現可能、リアルタイムのプッシュ型イベント対応、アトミックな変更管理、適切な権限制御、そして自己改善能力の7つに整理されている。

従来のSDLC(人間主導)
計画 設計 実装(人間) テスト デプロイ 保守
ボトルネック: 実装だけが高速化し、他工程が逼迫
ADLC(エージェント主導)
計画 設計 実装 テスト デプロイ 保守・改善
全工程をエージェントが自律的に駆動。人間は監視と方針決定に集中

ADLCへの移行は、単にエージェントにタスクを委譲するだけでは実現しない。Cloudflareが提唱する7要件は、いずれも人間向けに設計された既存の開発基盤では満たせないものだ。次のセクションでは、なぜこのタイミングでパラダイムシフトが必要なのかを掘り下げる。

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

SDLCからADLCへ なぜ今パラダイムシフトが必要なのか

エージェント時代の「人間ボトルネック」

ChatGPTやClaude、GitHub CopilotといったAIツールの普及により、コード生成のスピードは飛躍的に向上した。ところが開発現場の実態を見ると、生成されたコードのレビューやテスト、本番デプロイは依然として人間が担っている。結果として、プルリクエストの滞留が慢性化し、オープンソースプロジェクトではメンテナが数千件のイシューに対処しきれずに疲弊する事例が相次いでいる。

Cloudflareの見解では、これは「エージェントを部分的にしか使えていない」ことに起因する。実装だけをエージェントに任せ、他の工程を人間が管理するという中途半端な状態が、かえって現場の負荷を増大させているのだ。

自律走行車に学ぶ「全体最適」の視点

Cloudflare Blogの記事では、ADLCの必要性を自律走行車に例えて説明している。人間向けの車にAIを載せただけでは、80%の性能は出せても、残りの20%が致命的な事故を引き起こす。安全に走行するには、LiDARや高性能コンピュータ、遠隔制御システムといった専用設計の技術が必要だ。

ソフトウェア開発でも同じで、エージェントが安全にコードをマージし、本番にデプロイするには、人間向けのCI/CDパイプラインでは不十分だ。エージェント専用のインフラ、トレーシング、権限管理、自己修復の仕組みが求められる。

ここで鍵となるのが、Cloudflare Workflowsとエージェントの組み合わせだ。従来のGitHub Actionsのような線形のパイプラインではなく、動的に分岐し、コンテナやブラウザを立ち上げ、ログを解析しながら自律的にソフトウェアを出荷する「ワークフロー」がADLCの中核を担う。

自律走行車とソフトウェアファクトリーの比較
人間用の車+AI
80%の走行は可能だが、緊急時の判断に限界。専用センサーなしでは安全性を担保できない。
自律走行専用車
LiDARや遠隔制御で99%以上の安全性を実現。専用設計が信頼を生む。
ソフトウェア開発も同じ。人間用パイプライン+AIでは限界があり、ADLC専用基盤が必要。

Cloudflareが提供するADLC基盤の全容

Cloudflareが提供するADLC基盤の全容

Workflowsが実現する動的なCI/CD

Cloudflare Workflowsは、複数のステップをチェーンし、失敗したタスクを自動リトライし、数時間から数週間にわたって状態を保持できるサービスだ。従来のCI/CDパイプラインが静的なYAML定義だったのに対し、WorkflowsはTypeScriptで動的にワークフローを定義できる。

さらにWorkflowsは、エージェントや別のWorkflowを子プロセスとして起動できる。たとえば、毎晩収集したデータをエージェントにレビューさせ、その結果を元に次のステップを動的に決定する、といった高度なオーケストレーションが可能だ。

import { CIWorkflow } from '@cloudflare/ci'

// CIパイプラインの例: 依存関係インストール後、lint/test/typecheck/buildを並列実行
const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});
await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);
await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: { accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID },
});

このコードは、依存関係のインストールをキャッシュしつつ、後続のlintやテスト、ビルドを並列で実行するパイプラインを簡潔に表現している。Workflowsによって、エージェントが生成したコードを安全に検証し、本番へデプロイするまでの一連の流れを自動化できる。

エージェントの可観測性と自己改善

ADLCにおいて、エージェントの動作を監視し、改善につなげる仕組みは欠かせない。Cloudflareは、OpenTelemetryベースのトレーシングをローカル開発環境(WranglerやViteプラグイン)に組み込み、本番環境と同等の可観測性を提供する。また、Agent Tracesによってエージェントのセッション全体をキャプチャし、パフォーマンス向上に活用できる。

さらに、Feature Flag管理のFlagshipや、段階的デプロイメント(Gradual Deployments)、Browser Runによるヘッドレスブラウザのプログラム操作など、エージェントが自律的にソフトウェアをテストし、リリースするためのプリミティブが一通り揃っている。

ADLCを支えるCloudflareの主要プリミティブ
Workflows 動的なオーケストレーションとエージェント起動
Agent Traces エージェントセッションの完全な記録と分析
Browser Run ヘッドレスブラウザを用いたE2Eテストのプログラム実行
Gradual Deployments トラフィックを徐々に切り替える安全なリリース
Cloudflare MCP Server API駆動のインフラ管理。エージェントが直接リソースを操作可能

エージェントが主導するソフトウェアファクトリーの実践例

エージェントが主導するソフトウェアファクトリーの実践例

Cloudflare自身のエンジニアリング標準化

Cloudflareは自社の全プロダクトとシステムリポジトリにわたり、AIを用いてエンジニアリング標準の遵守を強制している。具体的には、コードレビューや仕様チェックをエージェントが補助し、人間のレビュアーの負荷を軽減する仕組みだ。

これにより、コーディング規約の違反やセキュリティパターンの逸脱を自動検出し、修正案まで提示できる。人間はより創造的な設計判断や顧客との対話に時間を割けるようになったという。

Astroプロジェクトにおけるイシューゼロへの挑戦

また、CloudflareはAstroというオープンソースプロジェクトにおいて、イシューの自動トリアージ、再現、修正を行うシステムを構築した。この「ソフトウェアファクトリー」により、GitHub上のイシュー件数をゼロに近づける試みが行われている。

エージェントがバグレポートを受け取り、自動で再現環境をセットアップし、修正PRを作成する。Workflowsがこれらのステップをオーケストレーションし、テストと検証を経てマージする流れだ。この事例は、ADLCが現実のプロジェクトで有効に機能することを示している。

STEP 1 ユーザーがGitHubにバグレポートを作成
STEP 2 エージェントがイシューをトリアージし、再現環境をセットアップ
STEP 3 修正コードを生成し、PRを作成
STEP 4 Workflowsがテスト・検証を実行し、安全にマージ
Astroプロジェクトにおけるイシュー解決フロー。エージェントとWorkflowsの連携で、手動プロセスを大幅に削減している。

ADLCがもたらす開発現場の未来と課題

ADLCがもたらす開発現場の未来と課題

ソフトウェアファクトリーの民主化

現在、最先端の企業だけがソフトウェアファクトリーを構築できているのが実情だ。Cloudflareは、WorkflowsやAgent Traces、Browser Runといったプリミティブを誰でも使える形で提供することで、この格差を埋めようとしている。小規模なスタートアップでも、ADLCの恩恵を受けられるようにする狙いだ。

具体的には、@cloudflare/ciパッケージによるCI/CDの簡素化や、Flueエージェントフレームワークとの統合によって、複雑なオーケストレーションを少ないコードで実装できるようになっている。

残る課題と人間の役割

ただし、ADLCへの移行には越えるべきハードルもある。エージェントが本番環境に直接変更を加えることへの心理的な抵抗感は依然として強い。Cloudflare自身も、権限の段階的な委譲(エスカレーション)の仕組みや、監査証跡の確保が不可欠だと認識している。

また、エージェントが生成するコードの品質をどう担保するか、未知のエッジケースにどう対応するかは、自律走行車と同じく「99%の壁」をどう突破するかの問題だ。CloudflareはAgent Tracesを通じてエージェントの経験値を蓄積し、時間とともにパフォーマンスが向上する仕組みを描いているが、実運用でのデータ蓄積がこれから本格化する。

それでも、コードを書くだけのエージェントから、ソフトウェアのライフサイクル全体を駆動するエージェントへの進化は、もはや避けられない流れだろう。ADLCは、そのための地図と道路を提供するものだ。

この記事のポイント

  • ADLC(Agent Development Lifecycle)は、従来のSDLCをエージェント中心に再設計した新しい開発モデルである。
  • AIエージェントの実装速度に他の工程が追いつかない「人間ボトルネック」の解決を目指す。
  • Cloudflare Workflowsを中核に、動的でスケーラブルなCI/CDとエージェントオーケストレーションを実現する。
  • Agent TracesやBrowser Runなどのプリミティブが、エージェントの自己改善と安全な本番運用を支える。
  • ソフトウェアファクトリーの民主化により、スタートアップから大企業までADLCの恩恵を受けられる時代が近づいている。
GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み

GKE Agent Sandboxがエージェント1台あたりのコストを75%削減する仕組み

AIエージェントを本番環境でスケールさせようとすると、すぐにコストとリソースの壁にぶつかる。Google Cloudが2026年7月30日に公開したブログ記事では、Google Kubernetes Engine(GKE)の新機能「GKE Agent Sandbox」とオーケストレーションを組み合わせることで、同一の仮想マシン上で動かせるエージェント数を最大3.5倍に増やし、エージェント1台あたりのコストを最大75%削減できるという検証結果が示された。

エージェントは要求に応じて動作するバースト型のワークロードであり、何もしない待機時間が長い。従来のように固定的なコンピュートリソースを割り当てる方法では、遊休状態のエージェントが貴重なCPUやメモリを消費し続けてしまう。この問題に対するGKEのアプローチを詳しく見ていく。

マイクロVM方式の限界とGKE Agent Sandboxの登場

マイクロVM方式の限界とGKE Agent Sandboxの登場

マルチエージェントを安全に動かすための一般的な方法として、各エージェントを専用のマイクロVM(Kata Containersなど)で隔離するやり方がある。ハードウェアレベルの隔離によってセキュリティを確保する狙いだ。しかしこの方式には大きな落とし穴がある。

マイクロVMはエージェントごとにゲストOSを起動するため、メモリとCPUに無視できないオーバーヘッドが生じる。実際にGoogle CloudのチームがOpenClawプロファイルを使い、48vCPUの標準VMインスタンス(n2-standard-48)上でテストしたところ、61個のエージェントを起動した時点で信頼性が低下し、ヘルスチェックの失敗が頻発し始めたという。

従来のマイクロVM方式(Before)
VMインスタンス 各エージェントに専用のゲストOS
61エージェントで上限 (信頼性低下・ヘルスチェック失敗)
オーバーヘッド大 / 固定リソース割当
GKE Agent Sandbox 利用時(After)
VMインスタンス 軽量サンドボックス(gVisor)で共有
88エージェントで動作 (約44%増加)
オーバーヘッド削減 / 同一VM内で高密度化

これに対してGKE Agent Sandboxは、gVisorというオープンソースのセキュアコンテナサンドボックスを土台にしている。gVisorはユーザー空間カーネル(Sentry)でシステムコールを捕捉・フィルタリングし、ハードウェア隔離に近いセキュリティを実現しつつ、ゲストOSを丸ごと動かす必要をなくした。

結果として、同一VM上で動作可能なエージェント数は88個まで増加。これはベースライン比で44%の密度向上であり、エージェント1台あたりのコストは30%以上削減された計算になる。しかも性能プロファイルはほぼ維持できると報告されている。

この方式が評価を得たのは早く、2026年5月の一般提供開始から4週間足らずで利用量が7倍以上に急増した事実が、その実用性を裏付けている。

遊休エージェントを「凍結」するオーケストレーションの威力

遊休エージェントを「凍結」するオーケストレーションの威力

GKE Agent Sandboxは稼働中のワークロードを効率化するが、遊休状態のエージェントがリソースを占有し続ける問題は残る。そこでカギを握るのが、Kubernetes本来のオーケストレーション機能とGKE Podスナップショットを組み合わせた「凍結・再開」パターンだ。

具体的には、エージェントが待機状態に入ったタイミングでPodスナップショットを作成し、永続ストレージにチェックポイント(凍結)として保存する。これにより物理的なCPUとメモリが解放され、クラスタに返却される。新しいトリガーが届くと、軽量なコントローラやイベントゲートウェイがリクエストを捕捉し、ミリ秒単位でスナップショットからエージェントを再開する。

STEP 1 エージェントが待機状態になる
STEP 2 Podスナップショットを永続ストレージに保存(凍結)
STEP 3 CPU・メモリを解放し、クラスタに返却
STEP 4 トリガー検知でスナップショットから即座に再開(ミリ秒単位)
エージェントのライフサイクルに合わせ、リソースを動的に割り当てる

この仕組みによって、物理リソースをワークロードの実態に基づいて「オーバーサブスクライブ(超過割り当て)」できるようになる。つまり、実際の瞬間的な需要以上のエージェントを同じノードに詰め込めるわけだ。その結果、間欠的にしか動かないエージェントであれば、ベースラインの3.5倍にあたる274個のエージェントを単一ノードで動作させることが可能になった。

ただし、やみくもに詰め込めばよいわけではない。エージェントの種類によって求められる起動時間やレイテンシは大きく異なるからだ。

エージェントの特性に合わせた3つのデプロイ戦略

エージェントの特性に合わせた3つのデプロイ戦略

GKEでは、すべてのエージェントに一律の戦略を強制するのではなく、ノードプールやワークロード設定ごとに異なる挙動を共存させられる。Google Cloudのブログでは、レイテンシ要件に応じた3つの典型例が紹介されている。

リアルタイムコーディングアシスタント(レイテンシ重視)

開発者向けの対話型エージェントでは、起動時間が1秒未満であることと、待ち行列が一切発生しないことが絶対条件だ。このケースでは、GKE Podスナップショットと「Agent Sandboxウォームプール」を組み合わせる。事前にウォームアップされた隔離サンドボックスを常時待機させておくことで、ほぼ瞬時に実行を開始できる。この構成で同一ノード上に133個のエージェントを収容できたと報告されている。

自律的なチームメイト型エージェント(バランス型)

バックグラウンドで対話的に動くエージェントは、平均的な起動時間(数秒)を許容できる。サスペンド&レジューム機能を利用し、遊休時にはリソースを解放、必要時にオンデマンドで復元する。待機中のコンピュートコストを支払う必要はない。

ヘッドレスなバックグラウンドエージェント(レイテンシ許容型)

日次レポートの生成や調査タスクのような定期ジョブは、多少の待ち時間があってもビジネス成果に支障をきたさない。こうしたエージェントには最大限のリソース超過割り当てを適用し、クラスタに空きが出るまで1時間ほど待つ戦略も有効だ。

リアルタイムアシスタント
起動 <1秒 / 待ち行列ゼロ
ウォームプール活用 / 133エージェント
自律的チームメイト
起動 数秒 / サスペンド&レジューム
遊休時リソース解放 / 柔軟な密度
ヘッドレスバックグラウンド
レイテンシ許容 / 最大超過割当
274エージェント(3.5倍)/ コスト75%削減
レイテンシ重視  バランス型  コスト重視

このように、ワークロードの性質に合わせて「パフォーマンス最適化」と「コスト最適化」のバランスをチューニングできるのがGKEの強みだ。サンダリングハード(多数のエージェントが一斉に起動してコンピュートを要求する問題)に対しても、ウォームプールやサスペンド&レジュームの設定で自由度の高い制御が可能になる。

コスト削減を実現するための実践的なアプローチ

コスト削減を実現するための実践的なアプローチ

GKE Agent Sandboxとオーケストレーションの組み合わせによって、エージェントの台数に比例してインフラ予算が増えていく構図を抜本的に変えられる。Google Cloudの検証では、パフォーマンスを重視する構成でも133個のエージェント(ベースライン比約2.2倍)、コスト最適化を突き詰めた構成では274個(同3.5倍)のエージェントを同一ノードで動作させることに成功した。

実務に落とし込む際のポイントは3つある。第一に、セキュリティを保ったままオーバーヘッドを削減するGKE Agent Sandboxへの移行を検討すること。第二に、Podスナップショットによる「凍結・再開」をアーキテクチャに組み込み、遊休リソースを徹底的に活用すること。第三に、すべてのエージェントを同じ扱いにせず、レイテンシ要件に応じてデプロイ設定を変えることだ。

なお、GKE Agent Sandboxの詳細な設定やウォームプール、サスペンド&レジュームの具体的な手順は、Google Cloudの公式ドキュメントで公開されている。まずは既存のエージェントワークロードを対象に、小規模なPoCから始めてみるとよいだろう。

この記事のポイント

  • GKE Agent SandboxはgVisorベースの軽量サンドボックスで、マイクロVMに比べてエージェント密度を44%向上させ、1台あたりのコストを30%以上削減する
  • Podスナップショットとサスペンド&レジュームの組み合わせにより、遊休エージェントを凍結して物理リソースを解放し、理論上3.5倍の密度(最大75%のコスト削減)を達成可能
  • ワークロードのレイテンシ要件に応じて「リアルタイム型」「バランス型」「コスト最適化型」の3戦略を使い分けることで、無理なくスケールできる
Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジン接続でポスト量子認証をサポート開始

Cloudflareがオリジンサーバーとの接続に対するポスト量子(PQ)認証のサポートを開始した。Authenticated Origin Pulls(AOP)とCustom Origin Trust Store(COTS)の2製品で、格子ベースのデジタル署名アルゴリズムML-DSAを導入する。これにより、Cloudflareと顧客オリジン間の相互TLS接続を完全に量子耐性化できるようになった。

今回の対応は、Cloudflareが掲げる2029年の完全ポスト量子セキュリティ達成に向けたマイルストーンの第一歩だ。量子コンピュータによるなりすまし攻撃の脅威が現実味を増すなか、暗号化だけでなく認証のレベルでも対策を打てる段階に入ったことを意味する。

量子コンピュータに備える認証のアップグレード

量子コンピュータに備える認証のアップグレード

Harvest-Now/Decrypt-Laterだけでは足りない

これまで量子耐性の議論は「Harvest-Now/Decrypt-Later」と呼ばれる攻撃への対策が中心だった。攻撃者が現在の暗号化通信を蓄積しておき、将来の量子コンピュータで解読するというシナリオだ。Cloudflareも2022年から来訪者との接続、2023年からはオリジン接続でポスト量子暗号化をサポートし、広く使われてきた。

しかし、近年の量子コンピュータと暗号解読のブレークスルーにより、スケジュールが前倒しされている。問題は暗号化にとどまらない。量子コンピュータは古典的な認証情報も破ることができるため、攻撃者が正規のサーバーになりすます「なりすまし攻撃」の脅威が高まっている。そこで認証にもポスト量子の仕組みを導入する必要が出てきた。

オリジン接続だからこそ先行できる理由

訪れるユーザーとCloudflareの間の接続(コネクション1)では、Web PKIの制約があり、ポスト量子証明書の普及には時間がかかる。一方、Cloudflareと顧客オリジンサーバー間の接続(コネクション2)は、あらかじめ信頼関係が確立された閉じた環境だ。このため、公開インターネット向けの証明書基盤を待たずに、独自のPKIでML-DSA署名を導入できる。

また、Cloudflareがクライアント側になるため、接続プーリングによって多数のリクエストを少数の接続に集約できる。これにより、ポスト量子署名の処理負荷をならすことが可能だ。クラウドサービスならではの制御性を活かし、Web PKIが同様の対応をするよりも早く、実際に運用できる段階までこぎつけた。

従来のTLS接続(Before)
ユーザー Cloudflare オリジン
認証はRSA/ECDSAベース → 量子攻撃で危殆化の可能性
ポスト量子mTLS接続(After)
ユーザー Cloudflare オリジン
双方向でML-DSA署名を使用。オリジンはCloudflareのクライアント証明書を検証

この接続構成では、Cloudflareがクライアント証明書を提示し、オリジン側でそれを検証することで、なりすましを阻止する。両者とも量子耐性のある署名アルゴリズムだけを信頼するよう設定すれば、ダウングレード攻撃も防げる。

AOPとCOTSの設定手順

AOPとCOTSの設定手順

ポスト量子認証を有効にするには、Custom Origin Trust Store(COTS)にML-DSAのCA証明書をアップロードし、Authenticated Origin Pulls(AOP)にはクライアント証明書と秘密鍵を登録する。以下にCloudflare APIを使った手順を示す。すべての鍵生成にはOpenSSL 3.5.0以降が必要で、秘密鍵はFIPS 204 seed-only形式を利用する。

COTS:オリジン証明書チェーンのML-DSA化

COTSは、デフォルトの公開CAに代えて顧客が指定したCAだけを信頼する仕組みだ。ML-DSA対応により、オリジンに接続する際のサーバー証明書をポスト量子化できる。まず、ML-DSA-44のプライベートCAを作成し、そのCAでオリジンサーバー証明書に署名する。

# プライベートML-DSA-44 CAの作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-ca.key

openssl req -new -x509 -key origin-ca.key \
  -out origin-ca.crt -days 10950 \
  -subj "/CN=Origin Server CA"

# オリジンサーバー証明書の生成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out origin-server.key

openssl req -new -key origin-server.key \
  -out origin-server.csr \
  -subj "/CN=origin.example.com"

openssl x509 -req -in origin-server.csr \
  -CA origin-ca.crt -CAkey origin-ca.key -CAcreateserial \
  -out origin-server.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\nsubjectAltName=DNS:origin.example.com\n")

生成したCA証明書をCOTSにアップロードし、SSL/TLSモードをFull(strict)に設定する。これでCloudflareは、アップロードされたCAからチェーンする証明書を持つオリジンとのみ接続するようになる。

AOP:Cloudflare側のクライアント証明書

オリジンサーバーがCloudflareからの接続だけを受け付けるようにするには、AOPでクライアント証明書を設定する。ML-DSA証明書とseed形式の秘密鍵をAPI経由で登録すれば、Cloudflareがオリジンに対して自らの身元を証明するようになる。

# AOP用CAとクライアント証明書の作成
openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-ca.key

openssl req -new -x509 -key aop-ca.key \
  -out aop-ca.crt -days 10950 \
  -subj "/CN=Authenticated Origin Pull CA"

openssl genpkey -algorithm mldsa44 \
  -provparam ml-dsa.output_formats=seed-only \
  -out aop-client.key

openssl req -new -key aop-client.key \
  -out aop-client.csr \
  -subj "/CN=cloudflare-aop-client"

openssl x509 -req -in aop-client.csr \
  -CA aop-ca.crt -CAkey aop-ca.key -CAcreateserial \
  -out aop-client.crt -days 5475 \
  -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=digitalSignature\n")

AOPはゾーン単位またはホスト名単位で有効化できる。グローバル設定のML-DSA対応は、より大規模な変更が必要なため後日対応予定だ。

ダウングレード対策と接続確認

ポスト量子署名を導入しても、検証側が従来のRSAやECDSAを引き続き信頼していれば、経路上の攻撃者によるダウングレード攻撃を受ける可能性が残る。完全な量子耐性を確保するには、オリジン側で量子脆弱な認証方式を無効化し、ML-DSAのみを信頼する設定にしなければならない。

設定後は、openssl s_clientで署名タイプを確認したり、nginxのログにクライアント証明書のシリアル番号を出力させたりして、CloudflareがML-DSA証明書を提示していることを検証する。鍵合意でもX25519MLKEM768がネゴシエートされていることをあわせて確認したい。

STEP 1 ML-DSA鍵と証明書をOpenSSLで生成
STEP 2 CA証明書をCOTSに、クライアント証明書をAOPにアップロード
STEP 3 オリジンサーバーでnginxのssl_verify_clientをonに設定
STEP 4 Full(strict)で接続し、ログでML-DSA署名を確認

これらの手順を踏むことで、Cloudflareとオリジン間の通信が暗号化と認証の両面でポスト量子化される。

実装の舞台裏と教訓

実装の舞台裏と教訓

制御プレーンはGoの壁をCIRCLで突破

CloudflareのSSL/TLS設定を管理するサービスはGoで書かれている。ML-DSA対応にあたり、Goの標準ライブラリがまだ同アルゴリズムをサポートしていないという課題があった。そこでCloudflareは自社の暗号ライブラリCIRCLに必要な機能を実装し、標準ライブラリの不足を補った。

ただし、このアドホックな対応は一時的なもので、2026年8月にリリース予定のGo 1.27ではML-DSAがネイティブサポートされる。バージョンアップのみで多くのサービスがポスト量子認証に対応できるようになるため、エコシステム全体にとっての追い風となる見込みだ。

BoringSSL更新の遅れとインシデント

データプレーン側では、プロキシフレームワークPingoraのオリジン接続サービスがBoringSSLに依存している。同ライブラリには4年間ものアップデートが行われておらず、Cloudflareは内部フォークをメンテナンスして機能を追加していた。ML-DSAサポートがBoringSSL本体に取り込まれたことを機に、ついにアップデートを決断した。

しかし、4年分の変更にはKeyUsageルールの厳格化が含まれており、一部の顧客証明書がRFC準拠でないと判定されてしまった。慎重にテストを重ねたにもかかわらず、2026年6月10日に小規模な接続障害が発生し、ロールバックを余儀なくされた。その後、RSA証明書向けの緩和パッチを当てて再開し、現在は安定稼働している。長期間アップデートを控えることのリスクを改めて浮き彫りにした出来事だったといえる。

完全ポスト量子化へのロードマップ

完全ポスト量子化へのロードマップ

Cloudflareは2029年の完全ポスト量子セキュリティ達成を目標に掲げている。今回のAOP/COTS対応は最初のマイルストーンに過ぎない。ユーザーとCloudflare間の認証については、IETFで策定が進むMerkle Tree Certificates(MTC)による高速なポスト量子証明書の実験を経て、2027年をめどに初期展開を予定している。

Go 1.27の登場やブラウザベンダーの取り組みが進むにつれ、ポスト量子認証は急速に普及すると予想される。ひとまず、オリジンとの相互接続でML-DSAによる完全な量子耐性を確保できるようになったことは、インフラを預かる技術者にとって心強い前進だ。Cloudflareの製品別ポスト量子対応状況は、公式ドキュメントで継続的に更新されているため、導入の際は参照してほしい。

この記事のポイント

  • CloudflareがAOPとCOTSでML-DSA署名をサポートし、オリジン接続の相互TLSをポスト量子化
  • 量子コンピュータによるなりすまし攻撃に備え、暗号化だけでなく認証の強化が急務に
  • OpenSSL 3.5.0+で鍵生成し、API経由で証明書をアップロード。ダウングレード防止には従来署名の信頼解除が必須
  • Go 1.27のネイティブML-DSAサポートなど、エコシステム整備が加速中
Shopify×Vercel、Hydrogenフレームワークを再構築。マルチフレームワーク対応とAIエージェント導入

Shopify×Vercel、Hydrogenフレームワークを再構築。マルチフレームワーク対応とAIエージェント導入

ShopifyとVercelが、ヘッドレスコマースフレームワーク「Hydrogen」の全面的な再構築に着手した。2026年7月30日にVercel Blogが発表した内容によると、新バージョンはオープンソース化され、Next.js以外のフレームワークでも動作するランタイム非依存型へと生まれ変わる。

この刷新により、開発者は型安全なAPIクライアントやカート状態管理をワンインポートで利用でき、ストアフロントの構築が大幅に効率化される。さらに「Standard Actions」と呼ばれるエージェント型コマース機能が追加され、AIが購入支援や在庫確認などを自律的に処理する仕組みが提供される。

Hydrogenとは何か?

Hydrogenとは何か?

HydrogenはShopifyが提供するヘッドレスコマース専用のフロントエンドフレームワークだ。従来のShopifyストアはテーマで構築するが、Hydrogenを使うとReactコンポーネントで自由にカスタマイズした店舗を開発し、Shopifyのバックエンドとシームレスに連携できる。つまり「自由な画面デザイン」と「Shopifyの堅牢なバックエンド」を両立させる架け橋と言ってよい。

これまでHydrogenはNext.jsに最適化された形で展開されていたため、開発者はReact/Next.jsのエコシステムに縛られていた。NuxtやSvelteなど別のフレームワークを使う場合は、独自にAPI連携や状態管理を実装する必要があり、それが導入障壁になっていた。

何が変わるのか?

何が変わるのか?

今回の再構築では、Hydrogenの根本的な設計が刷新される。具体的には以下の3つの大きな変化がある。

従来のHydrogen(Before)
フレームワーク Next.js のみ対応
APIクライアント カスタム実装が必要
カート状態 独自の状態管理が必須
AI機能 なし
新しいHydrogen(After)
フレームワーク Next.js / Nuxt / Svelte 等に対応
開発者 型安全APIクライアントをインポート 1行
開発者 カート状態管理を標準提供
AI エージェントが購入支援・在庫確認

この比較から分かる通り、新しいHydrogenではフレームワークの選択肢が広がり、面倒な共通処理はフレームワークが肩代わりしてくれる。結果として、開発者はビジネスロジックに集中できる。

オープンソース化とランタイム非依存

最大の変更点は、Hydrogenが完全オープンソースになり、ランタイムにも依存しなくなったことだ。旧バージョンは実質的にNext.jsアプリとして動作する設計だったが、新しいHydrogenは@shopify/hydrogenパッケージをブラウザ用JavaScriptで動作するように再実装し、@shopify/storefront-api-clientと共に利用する形になる。

これにより、開発者はNext.jsはもちろん、Nuxt、SvelteKit、あるいは純粋なViteアプリケーションなど、好みのフレームワーク上でHydrogenストアフロントを構築できる。Vercelの発表ブログでは「cart.query()cart.lineItems()といったAPIをインポートするだけで、カートの操作や状態管理が完了する」と説明されており、従来のようにフレームワークごとに接着コードを書く手間が不要になる。

標準Actionsとエージェントコマース

もうひとつの目玉は「Standard Actions」の導入だ。これはAIエージェントがショッピング行動を自立支援するための統一インターフェースであり、店舗の様々な操作(検索、商品詳細の取得、カート追加、購入)をアクションとして定義する。

ユーザーが自然言語で要望を伝えると、AIエージェントが最適なアクションを選択して結果を返す。この仕組みを利用すれば、「オススメの夏用ジャケットを見せて」「先週買おうとした商品をカートに戻して」といった会話型の購買体験をストアフロントに組み込める。

STEP 1 顧客が自然言語で商品を検索・質問
STEP 2 AIエージェントが意図を解析しアクションを選択
STEP 3 在庫確認・カート追加・決済支援を自動実行
STEP 4 結果を顧客に返す(購入完了など)

Standard Actionsは、AIモデルが商品データや在庫情報にアクセスしやすい形で提供されるため、自前で複雑なAIパイプラインを構築する必要がない。ChatGPTやClaudeといった外部AIと統合する場合も、アクション定義を合わせるだけで済む設計だ。

なぜこのパートナーシップが重要なのか

なぜこのパートナーシップが重要なのか

ShopifyとVercelの連携強化は、単なるコードのリファクタリングではない。ここには二つの大きな戦略的意義があると考えられる。

一つは「Shopifyのバックエンドをあらゆるフロントエンドから利用可能にする」という方向性だ。ヘッドレスコマース市場では、各ブランドが独自のデザインシステムや技術スタックを持つことが当たり前になってきた。Hydrogenがランタイム非依存になることで、React以外のスタックを使っている企業も無理なくShopifyに移行できるようになる。

もう一つは「AI時代のコマース体験の標準化」だ。Standard Actionsは、AIエージェントが安全かつ一貫した方法で店舗操作を行えるプロトコルを定義する。これが広く採用されれば、どんなストアフロントでも同じ仕組みでAIアシスタントを動かせるようになるため、エコシステム全体のAI対応速度が上がる。

さらに、オープンソース化によってコミュニティの貢献が期待でき、Hydrogen自体の開発スピードも加速する。プラットフォームに閉じない設計は、長期的なベンダーロックインの回避にもつながる。

実務への影響と開発スピード

実務への影響と開発スピード

Vercel Blogの記事では、ファッションブランド「Paige」の事例が紹介されている。新しいHydrogenを採用した結果、それまで数か月かかっていた新機能の開発が1週間に短縮されたという。これは単にコード量が減っただけでなく、標準化されたAPIクライアントと状態管理によって、チームが細かい実装に悩まなくなり、ビジネスロジックの試行錯誤に集中できるようになった成果だ。

中小規模のECサイト運営者にとっては、これまで「ヘッドレス」と聞くだけで専門のReactエンジニアが必要だと思われていた壁が下がる。HydrogenがNuxtやSvelteでも動くため、社内のフロントエンドチームが使い慣れたフレームワークをそのまま活かせる。さらに型安全なクライアントが用意されているため、APIの仕様変更に伴う不具合もコンパイル時に検出しやすくなる。

パフォーマンス面でも、ランタイムの最適化が進んだことで、ストアフロントの表示速度が向上する。Vercelのエッジネットワークとの組み合わせにより、世界中のユーザーに高速な体験を提供できるのも大きな強みだ。

この記事のポイント

  • Hydrogenがオープンソースかつランタイム非依存となり、Next.js以外のフレームワークでも動作する
  • 型安全なAPIクライアントとカート状態管理が標準提供され、開発効率が飛躍的に向上する
  • Standard Actionsによって、AIエージェントが自然言語でショッピングを支援する仕組みが組み込まれる
  • ファッションブランド「Paige」では開発期間が数か月から1週間に短縮された事例が報告されている
  • 中小規模のECサイトでも、ヘッドレスコマースの導入ハードルが大きく下がる
Google Cloud、OKF v0.2でエージェント間の信頼問題に挑む

Google Cloud、OKF v0.2でエージェント間の信頼問題に挑む

Google Cloudは2026年7月24日、エージェントやAIが生成・共有する知識の信頼を体系的に扱えるフォーマット「Open Knowledge Format(OKF)」のバージョン0.2を発表した。OKF v0.2では、来歴・信頼レベル・鮮度・ライフサイクル・計算結果の証明という5つの問いにファイルのメタデータで直接答えられるようになる。

エージェント同士が大量の知識を自動生成してやり取りする世界では「誰がいつ作り、本当に確認済みで、今も正しいのか」という情報抜きに安心して使えない。OKF v0.2はこの課題に、マークダウンとYAMLフロントマターというシンプルな仕組みで応えるものだ。

すべての新フィールドはオプションであり、v0.1からの後方互換性も保たれている。ただし、これらの信頼信号が「ない」こと自体が「未検証」として識別可能になる点が重要である。

エージェント間知識共有で失われる「暗黙の信頼」を補う

エージェント間知識共有で失われる「暗黙の信頼」を補う

OKFは、テーブルスキーマやメトリクス定義、運用ルールブックといったエージェントが必要とするコンテキストを、特定プロプライエタリなサービスではなく、標準的なフォーマット上に保持することを目指して登場した。2026年6月のv0.1では、マークダウン本体とYAMLのフロントマター、少数の規約という最低限の構成だった。

今回のv0.2は、コミュニティからのフィードバックを踏まえたものである。多くの拡張提案やエコシステムツールのカタログ化が進む一方、最も大きな懸念として浮上していたのが「エージェントが書き込んだ知識を信用できるのか」という問いだった。

人が手書きしたWikiページには、作成者の責任という暗黙の保証がある。しかし、エージェントが一晩で数千もの概念を生成する世界では、その保証は機能しない。消費者(これも別のエージェントであることが多い)は、明示的な信号だけを頼りに概念を評価しなければならず、具体的には次の5つの問いに答える必要がある。

  • 何から作られたのか(来歴)
  • どれだけ信頼できるのか(信頼)
  • まだ正しいのか(鮮度)
  • 現在のバージョンはどれか(ライフサイクル)
  • その数値は規定の方法で算出されたか(証明)

OKF v0.2では、これらすべての問いにフロントマターのフィールド群で答えられ、しかもフォーマットとしての意見の少なさは維持される。

記述から判断へ、信頼をフィルタリングするメタデータ

記述から判断へ、信頼をフィルタリングするメタデータ

v0.1のフロントマターには、概念のタイプやタイトル、説明、リソース、タグといった「その概念が何か」を示す情報が含まれていた。v0.2ではこれに加え、「読む前にその概念について決断するための情報」、すなわち誰が作り、検証済みか、鮮度はどうか、値がどう計算されるべきかといったフィールドが追加されている。

これらの信号をフロントマターに置く理由は明確だ。エージェントが検索・探索する際、最初に行うのは「この概念がそもそも関連性があるか」の判断であり、多くの場合、ファイル本文にまでアクセスする必要はない。本文に含まれる情報は簡潔であるべきだが、フロントマターは信頼性と関連性の判断だけを支援する信号を凝縮して提供する。トークン消費を抑えつつ、高頻度で安価にチェックできるためだ。

これにより、信頼は「読み始める前にフィルタリングできる」ものになる。

来歴(Provenance)で素材と信頼信号を記録する

来歴(Provenance)で素材と信頼信号を記録する

新しい sources フィールドは、概念が派生した素材を記録する。外部ドキュメント、バンドル内の相対パス、あるいは「プロジェクトXの全クエリ」といったスコープ記述子まで格段に表現できる。同時に、各エントリは authorusage_countlast_modified といった客観的なクレジビリティ信号を持てる。

ここであえて「信頼スコア」を導入しなかった点がOKFの設計思想を表している。スコアは主観的で、消費者ごとに通用せず、付けられた瞬間から陳腐化しやすい。OKFは信号を記録し、信頼度の推論は消費者側に委ねる。利用頻度が高く、最近更新され、信頼できる作成者がいる素材ほど信頼されるのは人の判断と変わらず、必要に応じて動的にスコアリングも可能だ。

本文中で特定の素材を引用する場合は、通常のマークダウンの脚注記法([^export-schema])を使い、末尾に追いやるのではなく主張単位で出典を結びつける。

信頼の階層を generatedverified で分離する

信頼の階層を generated と verified で分離する

信頼は2つの独立したフィールドで確立される。何かを作った者とそれを確認した者は必ずしも同一ではないからだ。

  • generated { by, at } 現在のコンテンツが誰によって、いつ最後に意味的な変更を加えられたかを記す
  • verified [ { by, at } ] 素材や元リソースに対する独立した確認のリスト。人間の承認、定期的な財務プロセス、あるいは両方を含む

verified の有無と内容から、消費者は「信頼ティア」を導出できる。未入力なら未検証、機械のアクターだけならマシン確認済み、human:<id> が含まれれば人間レビュー済みとなる。これはあくまで助言信号であり、アクセス制御ではない。しかし、エグゼクティブ向けダッシュボードでは「人間レビュー済みのメトリクスだけを表示する」といったフィルタリングがフロントマターだけで可能になる。

従来のOKF v0.1(Before)
type: metric
title: 売上高
description: 当四半期の純売上
(信頼信号は皆無 / エージェントにとって不透明)
メタデータに生成元や検証情報がないため、消費者は内容の真偽を判断できない
改善後のOKF v0.2(After)
type: metric
title: 売上高
generated:
by: reference_agent
at: 2026-07-20
verified:
– by: human:vp_finance
at: 2026-07-23
stale_after: 2026-12-31
status: stable
財務責任者の確認済みかつ期限付きの鮮度情報があるため、ダッシュボードでも安全に表示可能

このように、v0.2のフロントマターは「読まずに判断する」ための情報を一箇所にまとめる。概念の本文を開く前に、信頼性でフィルタリングできるため、大量のエージェント生成知識を効率よく扱える。

鮮度とライフサイクルを stale_afterstatus で宣言する

鮮度とライフサイクルを stale_after と status で宣言する

知識が「今も正しいか」を機械的に判断するために、OKF v0.2は stale_afterstatus を使う。status は概念を draft → stable → deprecated と遷移させ(省略時は stable)、stale_after は絶対日付で鮮度切れを表す。相対TTL(Time to Live)ではなく絶対日付を採用したのは、非LLMの決定論的な消費者が単純な日付比較で陳腐化を判定できるようにするためだ。

たとえば、ある小売企業の財務チームが毎年1月にポリシーを再承認する場合、関連メトリクスには stale_after: 2026-12-31 を付与する。2027年1月1日以降、これらの概念は再検証を経なければ利用させない、といったルールをコード化できる。また、status: deprecated を設定すれば、古い計算式で定義されたメトリクスを履歴再現用に保存しつつ、新しい作業では表示させないことも簡単だ。

計算の正当性を検証するAttested Computation

計算の正当性を検証するAttested Computation

来歴は「主張がどこから来たか」を答えるが、エージェントが実際にドル換算の数字を報告する瞬間には、より厳しい問いが必要になる。「その数値は規定された方法で算出されたのか、それともエージェントが勝手にSQLをでっち上げたのか」である。

OKF v0.2は Attested Computation という新しい概念タイプを導入した。これは値の意味だけでなく、認可された計算方法と、それが実際に実行されたことを検査する手段を併せ持つ。エージェントは宣言されたパラメータを埋めるだけで、計算式そのものを編集してはならない。消費者は、指定されたエグゼキューターで計算を実行し、レシート(実行されたSQLやジョブID、結果)を取得し、決定論的なアテスター(LLM不要の検証プロセス)でレシートを検査する。

アテスターは、承認済みの計算定義と実行されたクエリが等価であるか、表示された値がレシートの情報源と一致するかを機械的に確認する。SQLを正規化し、コメントや空白を除去して比較するといった方法で、テーブル名の差し替えやフィルタの追加、JOINの欠落を検出する。検証に失敗すれば、消費者はその値を表示しない。

Attested Computationの流れ
エージェント パラメータを埋める(計算式は編集不可) エグゼキューター 計算実行
レシート(ジョブID / 実行SQL / 結果) アテスター(決定論的)
OK(検証成功) → 値を表示    NG(不一致) → 値を表示しない
アテスターはSQLの正規化等でテーブルの差し替えやJOIN欠落を検出

この仕組みによって、定義の検証(verified)と実行時の証明(アテステーション)が分離される。定義が古くても実行時の証明は通る可能性があり、定義が最新でも毎回の実行で証明を取らなければならない。両者が必要だからこそ、OKF v0.2は双方を備えている。

v0.2の互換性とエコシステム

v0.2の互換性とエコシステム

v0.2はマイナーバージョンアップであり、v0.1のバンドルは無変更でそのまま読み込める。意図的な名称変更として、timestampgenerated.at に、本文末尾の引用リストが sources フィールドに置き換わっているが、いずれもv0.2の消費者がv0.1の形式にフォールバックできる。

GitHub上のリファレンス実装もv0.2対応が進められており、サンプルバンドル(GA4 eコマース、Stack Overflow、Bitcoin、本稿で紹介された小売の例)はv0.2のフィールドを備える。また、Google CloudのKnowledge Catalog(旧Dataplex)を用いたデモでは、OKFの信頼信号をカタログ往復後も維持できることが示されている。

この記事のポイント

  • OKF v0.2は来歴・信頼・鮮度・ライフサイクル・計算結果の証明をフロントマターで表現し、エージェント間知識の信頼を形式化する
  • generatedverified の分離により、作成と確認の責任を切り分け、人間レビュー済みなどのティア別フィルタリングが可能
  • stale_afterstatus で機械的な鮮度管理とライフサイクル制御を実現
  • Attested Computationでは計算式の改ざんを検出し、結果の証明を決定論的に行う
  • 後方互換性を保ちつつ、信号の不在が「未検証」として区別されることで、暗黙の信頼から脱却できる
Cloud Runのマルチリージョン高可用性が強化、障害検知と自動復旧が数秒単位に

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

発表の概要

発表の概要

Google Cloudは2026年7月20日、Cloud Runにおけるマルチリージョン高可用性の機能強化を発表した。ミッションクリティカルなアプリケーションのダウンタイムは、企業の収益や評判に直結する問題だ。これに対処するため、Cloud Runは単一コマンドで複数リージョンに同一サービスを展開できる設計をとってきたが、今回のアップデートで障害検知と自動復旧の精度が大幅に向上している。

新たに導入された機能は「Readiness Probe」と「Service Health」の2つだ。インスタンスレベルの死活監視とリージョンレベルの健全性評価を組み合わせることで、リージョン障害が発生した際のトラフィック迂回が数秒単位で自動化される。

マルチリージョン高可用性を支える2つの新機能

マルチリージョン高可用性を支える2つの新機能
Readiness Probe(準備状況プローブ)
コンテナがトラフィックを処理できる状態かを検証するヘルスチェック。Cloud Runサービス内の各インスタンスの稼働状況を可視化し、異常があれば速やかに検知する。
Service Health(サービス健全性)
Readiness Probeの結果を集約し、リージョン単位でサービスの健全性を評価する。この情報はサーバーレスNEG(ネットワークエンドポイントグループ)を通じてグローバルロードバランサに公開され、異常が確認されたリージョンへのトラフィックが自動的に停止される。
Readiness Probe  Service Health

Readiness Probeの役割は「個々のコンテナが外部リクエストを受け付けられる状態か」を確認することだ。この結果はCloud Runコンソールからもリージョン別に確認でき、どのリージョンでインスタンスが縮退しているかが一目で分かる。

Service Healthはこのプローブ結果をリージョン単位で集約するレイヤーにあたる。複数のヘルスチェック結果を「そのリージョンが正常に稼働しているかどうか」というひとつの評価に落とし込み、グローバルロードバランサがこの評価に基づいてルーティングを切り替える。この仕組みにより、障害発生時の手動オペレーションが原則不要になる。

パブリックとプライベートで異なる自動フェイルオーバーの経路

パブリックとプライベートで異なる自動フェイルオーバーの経路

自動フェイルオーバーを実現するには、トラフィックが流入してくるネットワーク層によってロードバランサの種類を選択する必要がある。Cloud Runは外部向けと内部向けで最適なバランサ構成を用意している。

パブリックインターネットアプリケーション
ユーザー グローバル外部ALB リージョンA NEG(正常)
ユーザー グローバル外部ALB リージョンB NEG(異常) ※自動迂回
ウェブサイトや一般公開API向け。グローバルな外部ロードバランサがトラフィックを受け、障害リージョンを除外してルーティングする。
プライベートネットワークアプリケーション
内部VPC クロスリージョン内部ALB リージョンA NEG(正常)
内部VPC クロスリージョン内部ALB リージョンB NEG(異常) ※自動迂回
社内システムやマイクロサービス間通信向け。VPC内に閉じた内部ロードバランサが同じ自動フェイルオーバー機能を提供する。
リクエスト元  外部ALB  内部ALB  正常リージョン  障害リージョン

この構成の利点は、どちらのパターンでもロードバランサ側が自動でService Healthを参照し、異常リージョンをルーティング対象から外してくれる点にある。手動でのDNS切り替えや手作業によるトラフィック操作が不要になるため、復旧までの時間が大幅に短縮される。

設計段階で押さえるべき3つのポイント

設計段階で押さえるべき3つのポイント

Service Healthの活用を前提にマルチリージョン構成を設計する際、見落としやすい検討項目が3つある。いずれも高可用性に直結するため、初期段階で整理しておくことが望ましい。

1 単一障害点の排除 全レイヤー(Web・アプリ・DB)を対象とする。3層アーキテクチャであればWeb層は外部ALB、アプリ層は内部ALBでそれぞれマルチリージョン化し、DB層にも冗長構成が求められる。
2 データレプリケーション リカバリポイント目標(RPO)の要件を明確にしたうえで、リージョン間でのデータ複製方針を決める。書き込みの多いワークロードはアクティブ-アクティブ同期が効果的だが、ゼロデータロスが必須かを先に判断する必要がある。
3 データレジデンシー 特定の国や地域にデータを置く必要がある場合、Firestore、Spanner、Cloud Storage、Cloud SQLなどGoogle Cloudのマルチリージョン対応データベースを選定する。これらはCloud Runとの相性がよく、厳格なデータ主権要件にも対応しやすい。

単一障害点をなくすには、インフラ層だけでなくアプリケーション自体のステートレス設計が前提になる。データ層を別途冗長化し、ロードバランサの背後で自由にインスタンスを入れ替えられる状態を作っておくことが、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層を含めた全レイヤーでの冗長化と、データレプリケーションの方針決定が設計の鍵を握る
  • 機能追加に伴う追加コストはなく、通常のリソース消費のみで全リージョンですぐに利用を開始できる
VercelがNode.js 20を非推奨化、10月1日から新規デプロイ不可に

VercelがNode.js 20を非推奨化、10月1日から新規デプロイ不可に

VercelにおけるNode.js 20非推奨の概要

VercelにおけるNode.js 20非推奨の概要

Vercelは2026年10月1日をもって、ビルドおよびFunctionsにおけるNode.js 20のサポートを終了する。これは2026年4月30日にNode.js 20がEOL(End of Life / サポート終了)を迎えたことを受けた動きだ。

Node.jsの各バージョンにはライフサイクルが定められている。長期サポート(LTS)が終了すると、セキュリティパッチの提供も停止される。Vercelがプラットフォームとして非推奨とするのは、ユーザーに安全で最新の実行環境を提供し続けるための当然の判断といえる。

この変更で影響を受けるのは、Node.js 20を指定している新規デプロイメントだ。既にデプロイ済みのサーバーレス関数は、その後も問題なく動作し続ける。

2026年10月1日以降
Node.js 20 使用不可
新規デプロイメント作成時にエラーが発生する
推奨される対応
Node.js 22 または Node.js 24 へ移行
package.json の engines フィールドで指定する
廃止されるバージョン  移行先の選択肢  移行対象

上図の通り、Node.js 20を指定したプロジェクトは、10月1日を境に新規デプロイができなくなる。Node.js 22または24への移行が必須だ。

なぜNode.js 20は非推奨となるのか

Node.js 20のLTSは2026年4月30日に終了した。LTS終了後は重大な脆弱性が見つかっても公式の修正は行われない。VercelのようなPaaS(サービスとしてのプラットフォーム)がEOLバージョンをサポートし続けることは、プラットフォーム全体のセキュリティリスクを高める。

実際、Node.jsのEOL後も古いバージョンを使い続けると、依存パッケージの互換性問題やパフォーマンス低下にもつながる。Vercelのこの方針は、ユーザーに対して積極的なアップグレードを促すための健全な措置だ。

影響を受けるプロジェクトの確認方法

影響を受けるプロジェクトの確認方法

まず最初に、自分が管理するVercelプロジェクトのうち、どれが今回の非推奨の影響を受けるかを確認する必要がある。Vercel CLIを使えば、コマンド一発で該当プロジェクトの一覧を取得できる。

最新のVercel CLIをインストールし、以下のコマンドを実行するだけだ。

npm i -g vercel@latest
vercel project ls --update-required

このコマンドは、非推奨のNode.jsバージョンをターゲットにしているプロジェクトの一覧を表示する。出力結果にプロジェクトが表示された場合、早急な対応が必要だ。

📋 確認のステップ
STEP 1 Vercel CLI を最新版にアップデート
STEP 2 vercel project ls –update-required を実行
STEP 3 該当プロジェクトをリストアップして対応計画を立てる

このフローで影響範囲を可視化できる。チームで複数のプロジェクトを運用している場合、全メンバーがこの確認を共有しておくとスムーズだ。

既存のデプロイメントは安全

ここで一つ重要なポイントがある。2026年10月1日以降も、既にデプロイ済みのサーバーレス関数は影響を受けない。すでに本番環境で稼働している関数への呼び出しは、これまで通り正常に動作する。

非推奨の影響が出るのは、あくまで新しいデプロイメントを作成するときだ。既存の環境が突然停止することはないため、慌てて不完全な状態でアップグレードする必要はない。計画的に移行を進められる。

Node.jsバージョンのアップグレード手順

Node.jsバージョンのアップグレード手順

Node.jsのバージョンを変更する方法は大きく2つある。プロジェクト設定のGUIから変更する方法と、package.jsonのenginesフィールドで指定する方法だ。

package.jsonで指定する場合は、以下のように記述する。

{
  "engines": {
    "node": "24.x"
  }
}

この設定がデプロイ時に読み取られ、Node.js 24が使用される。プロジェクト設定の値よりもpackage.jsonの指定が優先されるため、リポジトリにこの設定を含めておけば、デプロイのたびにGUIで変更する手間が省ける。

また、Vercelの公式ブログでは、コーディングエージェントにアップグレードを依頼する際のプロンプトも紹介されている。

Upgrade this Vercel project from Node.js 20 to 24.
Set the engines field in package.json to { "node": "24.x" },
which overrides the Project Settings version on the next deployment.
Update any Node 20 pins in .nvmrc, .node-version, or CI configs.
Switch the local runtime to Node 24, reinstall dependencies,
run the build and tests, and fix any breaking changes.
After deploying, confirm the version by logging process.version.

このプロンプトをClaudeやChatGPTなどのコーディングエージェントに渡せば、Node.jsバージョンの変更に伴う一連の作業をある程度自動化できる。

従来の手動アップグレード(Before)
作業者 .nvmrc を手動で編集
作業者 package.jsonのenginesフィールドを手動更新
作業者 CI設定ファイルのNodeバージョン指定を書き換え
作業者 依存関係の再インストールとテスト
※複数ファイルの修正漏れやビルドエラーが発生しやすい
コーディングエージェントを活用したアップグレード(After)
作業者 プロンプトを1回送信 AIエージェント が全ファイルを一括修正
※.nvmrc、package.json、CI設定の全箇所が同時に更新される
人間の作業者  AI・自動化ツール

上記の対比の通り、コーディングエージェントを活用すれば複数ファイルの一括更新が可能で、変更漏れのリスクを減らせる。

アップグレード時に気をつけるべき破壊的変更

Node.js 20から22、あるいは24へ移行する際、APIの破壊的変更がいくつか存在する。特に注意すべきなのは、以下の点だ。

  • 廃止されたAPI(fs.rmdirのコールバック形式など)が完全に削除されている可能性
  • ESM(ECMAScript Modules)の取り扱いに関するデフォルト挙動の変更
  • ネイティブアドオンのABI互換性(再ビルドが必要になるケース)
  • V8エンジンのバージョンアップに伴うパフォーマンス特性の変化

移行前に必ずローカル環境でNode.jsのバージョンを切り替え、依存関係を再インストールした上で、ビルドとテストを実行してほしい。CIパイプラインでNode.jsのマトリクステストを実施している場合は、テスト対象に新しいバージョンを追加しておくと安全だ。

アップグレードが間に合わない場合の緊急回避策

アップグレードが間に合わない場合の緊急回避策

どうしても10月1日までにNode.jsのバージョンアップが完了できないプロジェクトが出てくるかもしれない。大規模なコードベースや、多数の依存パッケージとの互換性確認に時間がかかるケースだ。

そうした状況のために、Vercelはコンテナイメージとしてデプロイする代替手段を用意している。

プロジェクトのルートにDockerfile.vercelを作成し、Node.js 20をベースイメージとして指定するだけでよい。

FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
# サーバーは $PORT をリッスンする必要がある
CMD ["node", "server.js"]

この方法を使えば、プロジェクト設定のNode.jsバージョンはコンテナに適用されない。つまり、プラットフォーム側のNode.js 20非推奨の影響を受けずにデプロイを継続できる。

コンテナデプロイを使用する場合の注意点(Before)
⚠️ Node.jsバージョンの管理はユーザー自身の責任になる セキュリティパッチの適用を自分で行う必要がある ベースイメージの定期的な更新が必須
推奨される方針(After)
✅ Node.js 22または24へのアップグレードを計画的に実施する コンテナは一時的な回避策としてのみ使用 アップグレード後に通常のFunctionsデプロイに戻す

コンテナデプロイはあくまで一時的な回避策だ。Node.js 20のセキュリティサポートはすでに終了している。長期的に見れば、Node.jsのバージョンアップこそが唯一の正しい解決策である。

この記事のポイント

  • Vercelは2026年10月1日にNode.js 20を非推奨とする。既存デプロイメントは影響を受けない
  • vercel project ls –update-required で影響を受けるプロジェクトを特定できる
  • package.jsonのenginesフィールドでNode.js 22または24を指定して移行する
  • コーディングエージェント用のプロンプトを使うと、複数ファイルの一括更新が効率的
  • どうしても間に合わない場合はコンテナデプロイ(Dockerfile.vercel)で緊急回避が可能