Google CloudのAPI Gateway（APIゲートウェイ）がストリーミングに対応SSE・WebSocket・gRPCをパブリックプレビューで、gcloudの--enable-streamingで有効化

Googleは2026年10月22日付のGoogle Developers Blogで、API Gateway（APIゲートウェイ）のストリーミング対応をパブリックプレビューとして発表しました。Google Developers Blogの投稿によると、Server-Sent Events（SSE）・WebSocket・gRPCストリーミング・HTTPレスポンスストリーミングを、API仕様（spec）を変えずに同じgatewayへ通せるようになります。有効にするには、gatewayの作成時に --enable-streaming を付けます。

3行まとめ

1. Google Cloud発表（2026年10月22日）：API GatewayがSSE・WebSocket・gRPC・HTTPレスポンスストリーミングに対応（パブリックプレビュー）。ストリームは最長1時間
2. 有効化はgateway作成時の --enable-streaming だけ。既存gatewayは切り替えできず、Terraform・Cloud consoleでの有効化とカスタムドメインはプレビュー開始時点で未対応
3. model routingを使うと、Gemini・Claude・OpenAI gpt-ossのモデルの応答も逐次配信できると同社は説明。プレビュー中はストリーミング対応gatewayのネットワークegressが無課金（ドキュメント記載）

本記事の内容は、日本時間10月23日0時台に公式ページで確認したものです。

何ができるようになったのか

これまでのAPI Gatewayは、リクエストを送って完全な応答を1回で返す「トランザクション型」の通信を前提にしていた、とブログは説明しています。AIモデルがトークンを出しながら応答する場合や、エージェントが途中経過を返す場合は、接続を開いたままにする必要があります。ブログは、従来は「APIの前にAPI Gatewayを置いてストリーミングを諦める」か「ストリーミングだけGatewayを迂回して認証・APIキー・可観測性を諦める」かの二択だった、と書いています。

今回対応したのは次の4種類です（ブログの記載）。

ドキュメント側では、対応方式が「Incremental response delivery（HTTP/2のDATAフレームまたはHTTP/1.1のチャンク転送）」「SSE」「WebSockets」「gRPC bidirectional streaming」と列挙されています。

API仕様については、ブログは「新しい拡張もストリーミング専用のアノテーションも不要で、既存APIを記述するドキュメントがそのままストリーミングAPIも記述する」と説明しています。APIキーの強制、JWT検証（Firebase・Auth0・Okta・Google IDトークン）、バックエンドへのサービスアカウント認証、Cloud LoggingとCloud Monitoringの連携、パステンプレートとルーティングは、従来どおり使えるとされています。

ただしドキュメントを読むと、バックエンドのプロトコルは仕様側で指定する必要があります。gRPCはHTTP/2（h2）、WebSocketはHTTP/1.1、SSEとチャンク転送はどちらでも可で、HTTP/2が推奨と書かれています。「仕様を変えずに」はストリーミング専用の記述が要らないという意味で、バックエンドの設定が不要という意味ではない点に注意が必要です。

どうやって有効にするのか

プレビュー中は、gateway作成時のオプトインです。ブログとドキュメントの両方に、次のコマンドが載っています。

gcloud api-gateway gateways create GATEWAY_ID \
  --api=API_ID \
  --api-config=CONFIG_ID \
  --location=REGION \
  --enable-streaming

ドキュメントによると、ストリーミングのモードは作成時に固定され、後から変更できません。明示的に無効にするフラグもありません。--enable-streaming を付けなくても、API configにModel Routerの設定があれば、必ずストリーミングgatewayになります。有効になったかどうかは、gcloud api-gateway gateways describe の出力にある effectiveStreamingMode で確認できます。

ブログは、GA（一般提供）の時点ではストリーミングがAPI Gatewayの標準の動作になり、オプトインは不要になる予定だと書いています。

時間の上限はどうなっているのか

ブログは「ストリームは最長1時間開いたままにできる」と書き、クライアントには再接続の実装を勧めています。ドキュメントの表では、もう少し細かく分かれています。

ドキュメントの注意書きによると、SSEやチャンク転送の既定15秒は多くのストリームには短すぎます。ストリームはデータを送っている最中でもタイムアウトで切られるため、ストリーミングのエンドポイントごとに deadline を明示するよう書かれています。さらに、バックエンドにも別のタイムアウトがあります。ドキュメントは、Cloud Runの既定300秒のままだと開始5分後にストリームが閉じる、と例を挙げています。

model routingとの関係は

ブログによると、model routingを使うgatewayは、model garden（Geminiプラットフォーム内）のGemini・Claude・OpenAI gpt-ossのモデルの応答を、生成されるそばから流します。model routingは、OpenAI互換のエンドポイントを1つ公開し、リクエストのJSONにある model フィールドでGemini・Claude・gpt-ossに振り分ける機能です。

model routingの概要ページには、ストリーミングについて次の制約があります。

• 対応するのは応答側のストリーミング（SSE）。リクエスト側のストリーミング、gRPC、WebSocket、Gemini Liveには非対応
• 振り分けは、パブリックプレビュー中はJSONの model の値だけが基準
• 1つのrouterで参照するモデルは、同じホスト名（グローバルまたは単一リージョンのエンドポイント）にあるものに限る
• 概要ページには、プレビュー中に model フィールドが欠けたリクエストをエラーにせず誤って処理する、という既知の挙動が書かれている

なお、概要ページでは対象モデルが「Gemini、Anthropic Claude、OpenAI GPTファミリー」と書かれており、ブログの「OpenAI gpt-oss」とは表現が異なります。どのモデルが実際に使えるかは、プレビュー中の公式ページで個別に確認するのが安全です。

ブログは、API Gatewayを「Google CloudのAI gateway機能への軽量な入口」と位置づけ、より広いAIポリシーとライフサイクル管理にはApigee、エージェントの接続の保護にはGeminiプラットフォームのAgent Gatewayを使う、と使い分けも示しています。Apigeeの最近の動きは、ApigeeのMCP対応の記事で扱っています。

ホスト名が変わる点には注意

ブログは、同じタイミングでgatewayの既定のホスト名が GATEWAY_ID-PROJECT_NUMBER.REGION.gateway.dev という予測できる形になる、と紹介しています。従来はハッシュ入りで、作成するまでURLが分からなかった、という説明です。

ドキュメントの「Limitations」を読むと、この形になるのはストリーミング有効のgatewayです。既存の非ストリーミングgatewayは従来の形式（{gateway_id}-{base36_project_number}.{shard_hash}.gateway.dev）のままで、ストリーミングを有効にした新しいgatewayは別のホスト名になるため、クライアントやDNSの更新が必要だと書かれています。ドキュメントによると、gateway IDとプロジェクト番号をつないだ最初のラベルは63文字のDNS制限に収める必要があり、gateway IDは49文字までです。

料金は

ドキュメントの「Pricing」の記載は次のとおりです。

During the Public Preview of streaming, customers are not charged for network egress on streaming-enabled gateways. However, Service Control billing still applies at the API level regardless of the release phase.

（ストリーミングのパブリックプレビュー中は、ストリーミング有効のgatewayのネットワークegressは課金されません。ただし、APIレベルのService Control課金は、リリース段階にかかわらず引き続き適用されます。）

GA後の料金は、今回取得した3ページには載っていません。

日本でも使えるのか

今回取得した3ページには、日本を含む提供リージョンや日本向けの案内は書かれていません。ドキュメントは、--location に指定できるリージョンについて「Deploy an API to a gatewayを参照」とだけ書いています。日本のリージョンで使えるかは、このリンク先で確認が必要です。

筆者の観測

日本時間10月23日0時5分ごろにこの3ページを取得して読みました。ドキュメントの2ページは言語メニューに日本語がありましたが、取得できた本文は英語で、最終更新は「2026-10-20 UTC」と表示されていました。ブログの公開日（10月22日）より2日前の日付です。なお、私は実際にgatewayを作ってストリーミングを動かしてはいません。本記事の内容はすべて公式ページの記載にもとづきます。

発表だけでは判断できないこと

• 性能：レイテンシやスループットの数字は、今回確認したページには載っていません。ドキュメントには、ストリーミング接続のリクエストレイテンシが「最初のバイトまでの時間」ではなくストリームが続いた時間を測る、と書かれており、グラフの見え方が変わります
• プレビュー中に使えない機能：ブログは、Cloud consoleからの有効化、Terraform、Serverless NEGと外部アプリケーションロードバランサ経由のカスタムドメインを「プレビュー期間中に追加予定」としています。ドキュメントは、ストリーミング有効のgatewayがHTTP(S)ロードバランシングやServerless NEGと互換性がないため、カスタムドメインも未対応と書いています
• MCP：ブログは、ストリーミング・model routing・MCP対応をAPI Gatewayの機能として並べていますが、ドキュメントによると、--enable-streaming を付けてもMCPのエンドポイントはストリーミングになりません。MCPの応答は単一の application/json のままです
• サポート水準：ドキュメントは、パブリックプレビューの機能はPre-GA Offerings Termsの対象で、「現状のまま」提供され、サポートが限定的な場合がある、と書いています
• セキュリティ：ドキュメントのLLM配信の例には、IDトークンがあれば誰でも（そのaudienceのトークンを発行できるGoogle IDなら）モデルにリクエストを送れてしまい、GPUインスタンスの費用が自分にかかるという注意があります。APIキーの併用やクォータの設定が案内されています

出典と確認時刻

• Streaming comes to API Gateway: real-time and AI-ready APIs, without changing your spec — Google Developers Blog（2026年10月22日付、日本時間10月23日0時5分に確認）
• Configure streaming for LLM responses and other traffic — Google Cloud Documentation（最終更新2026-10-20 UTC、日本時間0時5分に確認）
• Overview of model routing — Google Cloud Documentation（最終更新2026-10-20 UTC、日本時間0時5分に確認）

本記事は続報があり次第更新します。