Google Cloud API Gatewayのストリーミング対応とは？
API GatewayはバックエンドAPIの前段で認証、経路制御、ログ記録などを担うサービスです。従来はストリーミングを扱えず、AIの逐次応答やWebSocketだけ別経路に置く必要がありました。[1]
Public Previewでは、次の4方式をゲートウェイの内側に置けます。[2]
| 方式 | 通信の向き | 主な用途 |
|---|---|---|
| SSE | サーバーからクライアント | AIの回答、処理状況、通知 |
| HTTP chunked response | サーバーからクライアント | NDJSON、大きな結果の逐次配信 |
| WebSocket | 双方向 | チャット、共同編集、ライブ画面 |
| gRPC streaming | サーバー配信・双方向 | マイクロサービス間の連続通信 |
AIアプリでよく使われるSSEだけでなく、WebSocketとgRPC双方向ストリーミングまで含まれます。ただし、MCPの応答は単一のJSONのままで、ゲートウェイを有効化してもストリーミングにはなりません。[2]
何が変わる？API仕様を分けずに認証とログを保てる
今回の変更で大きいのは、ストリーミング専用のAPI仕様を新しく書く必要がない点です。既存のOpenAPI定義を使いながら、APIキー、JWT検証、バックエンド認証、Cloud Logging、Cloud Monitoring、ルーティングを引き続き利用できます。通常のAPIとSSEで認証や監査ログを二重実装せずに済みます。[1]
ただし、ストリーミングモードはゲートウェイ作成時に固定されます。既存ゲートウェイは更新できないため、gcloud api-gateway gateways createへ--enable-streamingを付けて新規作成し、接続先を切り替えます。[2]
Model Routerを使うゲートウェイではストリーミングが自動で有効になります。Google CloudのModel Gardenで扱うモデルの提供条件は、TechCreateの「OpenAIはGoogle Cloudで使える？対象モデルと条件」で整理しています。
料金はいくら？Preview中もAPI呼び出しとバックエンドは課金対象
追加単価は示されていません。Preview中はネットワークegressに課金しませんが、Service ControlによるAPI呼び出しの課金は続きます。[2]
API Gatewayの通常料金は、1請求先アカウントあたり月200万呼び出しまで無料、200万超から10億呼び出しまで100万回あたり3ドル、10億回超は100万回あたり1.50ドルです。[3]
| 費用項目 | Preview中の扱い |
|---|---|
| API Gatewayの呼び出し | 通常のService Control料金が適用 |
| ストリーミングゲートウェイのnetwork egress | Preview中は課金なし |
| Cloud Run、GKE、Vertex AIなどのバックエンド | 各サービスの料金が別途必要 |
| ログ、監視、保存 | 利用量と各サービスの料金に応じる |
「ストリーミングが無料」という意味ではありません。AIモデルの推論料金も含まれないため、ゲートウェイの呼び出し回数とバックエンドの実行時間、同時接続、ログ量を分けて見積もります。
タイムアウトは？既定15秒のままではAI応答が途中で切れる
ストリームは最大1時間維持できますが、SSEやchunked responseの既定deadlineは15秒です。ストリーミングを有効にしても自動で延長されません。長いAI応答やバッチ処理では、エンドポイントごとにdeadlineを設定する必要があります。設定できる上限は3,600秒です。[2]
| 接続方式 | 既定 | 上限・注意 |
|---|---|---|
| SSE・chunked response | 15秒 | deadlineを最大3,600秒へ設定可能 |
| WebSocket・gRPC | idle 300秒 | 接続全体は3,600秒。メッセージ間隔にも注意 |
| バックエンド | サービスごと | API Gatewayのdeadlineを延ばしても別途終了する |
Cloud Runのタイムアウトが300秒なら、API Gatewayを3,600秒にしても5分で接続が閉じます。クライアントも通信断を前提にし、最後のイベントから再接続できるようにします。
Preview時点のrequest latencyは、最初のデータまでの時間ではなく、ストリームが開いていた全時間を表します。初回データ到着、接続時間、切断率、再接続成功率を分けて計測します。[1]
導入前の制約は？既存ゲートウェイを直接置き換えない
Public Previewでは、機能より移行条件が判断材料になります。制約は次の通りです。[2] [4]
- 既存ゲートウェイのストリーミングモードは変更できず、新規作成が必要
- ストリーミング用のホスト名が変わるため、DNSまたはクライアント設定の切り替えが必要
- 外部Application Load BalancerとServerless NEGを経由するカスタムドメインは未対応
- Cloud ConsoleとTerraformからの有効化は未対応
- Preview機能として提供され、サポート条件はGA機能と異なる
- 1時間を超える接続には、アプリ側の再接続処理が必要
カスタムドメインを本番APIで使っている場合、Previewのゲートウェイへ同じ入口を載せ替えられません。本番を停止せず、検証用ホスト名で認証、CORS、接続維持、障害時の戻し方を確認します。
GoogleはGA時に標準動作にする計画を示していますが、提供日は未定です。Terraformやカスタムドメインが必須なら、要件検証だけ済ませてGAを待つ選択が現実的です。[1]
どんなチームが今試すべき？
SSEやWebSocketだけがAPI管理の外にあり、認証やログを二重実装しているチームに向きます。新しいホスト名で並行検証できること、CLIで構成を管理できることが前提です。固定カスタムドメインやTerraformが必須ならGAを待ちます。
低リスクの1エンドポイントを移し、初回データまでの時間、接続維持、切断後の再接続、認証切れ、ログの追跡性を確認します。API GatewayはAIモデルを速くする機能ではありません。逐次応答を管理対象の経路へ戻し、通信品質と統制の両方が改善するかで採否を決めます。
まとめ
- Google Cloud API GatewayはSSE、WebSocket、chunked response、gRPCストリーミングをPublic Previewで扱えるようになり、認証とログを通常APIと同じ経路へ戻せる
- API呼び出しとバックエンドは課金対象で、既定15秒のdeadline、最大1時間、バックエンド側タイムアウトを別々に設計する必要がある
- 既存ゲートウェイは更新できず、カスタムドメインとTerraformにも制約があるため、新しいホスト名で小さく並行検証できるチームに向く
出典・参考
- Google Developers Blog「Streaming comes to API Gateway: real-time and AI-ready APIs, without changing your spec」（2026年10月22日）
- Google Cloud Documentation「Configure streaming for LLM responses and other traffic」
- Google Cloud「API Gateway pricing」
- Google Cloud Documentation「API Gateway release notes」（2026年9月29日）
読者のコメント (0)
コメントを残す