目次
Google Cloud Gatewayで、の応答を途中からクライアントへ届けるストリーミングがパブリックプレビューとして利用できるようになりました。SSE、/1.1のチャンク転送、HTTP/2の増分配信、WebSocket、gRPC双方向ストリーミングを同じAPI管理基盤で扱えます。生成が終わるまで待ってから全文を返す構成に比べ、利用者が最初の回答を目にするまでの待ち時間を短くできる機能です。
ただし、既存ゲートウェイのスイッチを切り替えるだけの移行ではありません。ストリーミングモードは作成時に固定され、既定の期限はSSEやチャンク転送では15秒です。新しいホスト名への切り替え、バックエンドのプロトコル、Cloud Runなど上流側のタイムアウト、切断後の再試行まで一緒に設計する必要があります。本稿は2026年10月29日にGoogle Cloudの公式ドキュメントとリリースノートを確認した実装解説です。性能値は独自に実測していません。
スポンサーリンク
最初に決めるのは通信方式と終了条件
文章生成をブラウザーへ一方向に流すだけなら、SSEか増分HTTP応答が扱いやすい選択です。クライアントから途中で追加指示を送りたい場合はWebSocket、サービス間で型付きの双方向通信を行うならgRPCが候補になります。方式ごとにAPI Gatewayからバックエンドへ使うプロトコルが異なります。
| 方式 | 向いている用途 | バックエンド設定 | 期限の意味 |
|---|---|---|---|
| SSE／チャンク転送 | 回答を一方向に順次表示 | HTTP/1.1またはh2。公式はh2を推奨 | 接続全体の最長時間 |
| WebSocket | 途中入力、音声や対話の双方向通信 | HTTP/1.1 | メッセージ間の無通信時間 |
| gRPC双方向 | 内部サービス間の型付きストリーム | h2 | メッセージ間の無通信時間 |
OpenAPIのバックエンド定義でSSEを使う例は次のようになります。実際のアドレス、認証、パスは環境に合わせてください。API Gatewayでストリーミングを有効にしても、バックエンドが応答をバッファーしていればトークンはまとめて届きます。アプリ、ASGI／WSGIサーバー、Cloud Run、利用するLLM の各段で、チャンクを生成直後にフラッシュできることを先に確認します。
x-google-api-management:
backends:
llm:
address: https://example-service.run.app
protocol: h2
deadline: 120.0
x-google-backend: llm15秒の既定値を放置しない
SSEとチャンク転送では、deadlineは最後のチャンクが届くまでの総時間を制限します。途中でデータが流れ続けていても期限に達すれば切断されます。既定は15秒、ストリーミング対応ゲートウェイでは最大3,600秒です。30秒以上かかる回答を想定するのに設定を省略すると、「最初の数行は表示されたが途中で止まる」という障害になります。
WebSocketとgRPCでは意味が変わり、既定300秒のアイドル期限として働きます。WebSocketに300秒未満を指定しても300秒が最小です。接続全体は常に最大3,600秒で、変更できません。期限は長ければよいわけではなく、同時接続数、モデルの最大生成時間、利用者が画面を閉じた後の処理停止、課金上限を合わせて決めます。
- 通常の回答が収まる時間に、ネットワークの揺らぎを加えて期限を決める
- モデル側の最大実行時間とCloud Runなどバックエンドのタイムアウトを同時に確認する
- クライアント切断を検知したら、不要になった生成をキャンセルできるか試験する
- 最大時間まで開いた接続が増えた場合の同時実行数と費用を負荷試験する
公式ドキュメントは、Cloud Runのタイムアウトが300秒のままならストリームが5分で閉じる例も示しています。API Gatewayだけを3,600秒にしても、上流の短い期限は延長されません。ブラウザー、、企業、ゲートウェイ、バックエンド、モデルAPIのうち最も短い期限が実際の上限になります。
スポンサーリンク
既存ゲートウェイは更新できず、新規作成が必要
ストリーミングモードはゲートウェイ作成時に決まり、後から有効・無効を変更できません。既存APIを移すときは、同じAPI構成を参照する新しいゲートウェイを作り、動作確認後にクライアントを切り替えます。作成コマンドの基本形は次の通りです。
gcloud api-gateway gateways create stream-gateway \
--api=example-api \
--api-config=example-config \
--location=asia-northeast1 \
--enable-streaming作成後は出力専用のeffectiveStreamingModeがEFFECTIVE_STREAMING_MODE_ENABLEDかを確認します。Model Router Gatewayは自動的にストリーミングが有効になりますが、通常の構成では作成結果を推測せず読み戻すことが重要です。
切り替え単位は利用者全体ではなく、検証用クライアント、社内利用者、少数の本番利用者の順に分けます。旧ゲートウェイをすぐ削除せず、接続先を設定値で戻せるようにしておけば、期限切れや中間プロキシとの相性が判明した際に復旧できます。新旧で方式やの検証が変わっていないことも確認し、ストリーミング化を理由に認証を省略しないでください。
新しいゲートウェイは非ストリーミング版とホスト名の形式が異なります。さらにプレビュー期間中はServerless NEGや外部Application Load Balancerの背後へ置けず、その仕組みに依存するカスタムも利用できません。既存URLを維持する前提で着手すると切り替え段階で詰まります。新ホスト名を許容できるクライアント、、、許可リスト、監視先を先に洗い出します。Terraformからのストリーミング有効化も現時点では未対応です。
段階移行は同じ入力を二つの経路で比較する
切り替え前に、非ストリーミングと新しいストリーミングの両経路を残します。評価では最終回答の一致だけでなく、最初のチャンクまでの時間、チャンク間隔、完了率、期限切れ、利用者キャンセル後のバックエンド停止を記録します。生成AIの確率的な差を経路の不具合と混同しないため、可能なら同じモデル、パラメーター、固定した評価入力で比較します。AI機能の回帰試験は、既存の評価データと回帰テストの始め方も参考になります。
- 短い回答、長い回答、モデルがエラーを返す入力を用意する
- 15秒、設定した期限の直前、期限超過の三つで切断位置を確認する
- 途中でブラウザーを閉じ、モデル処理や課金が継続しないか観測する
- 再接続時に同じ回答を重複表示しない識別子と再開方針を決める
- 段階配信した内容を保存するなら、未完了と完了を区別して記録する
SSEはブラウザーが再接続する場合があります。POSTした生成要求をそのまま再実行すると二重課金や重複保存につながるため、要求IDで生成ジョブを識別し、既存ジョブへ再接続するか、最初からやり直すかを明示します。回答の途中経過を正式な記録として扱わない場合は、完了イベントを受けるまで確定保存しない設計が分かりやすいでしょう。
スポンサーリンク
ログでは完了と切断を分けて見る
API Gatewayのプラットフォームログには、HTTPステータス、遅延、応答理由、要求・応答サイズなどが記録されます。ストリーミングでは200応答の開始だけを成功とみなさず、アプリ側で開始、最初のチャンク、完了、クライアント切断、期限切れ、モデル側エラーを別イベントとして残します。要求本文や生成結果を無条件にログへ保存すると個人情報や機密情報が残るため、要求ID、モデル、経過時間、チャンク数、終了理由を中心にします。
resource.type="apigateway.googleapis.com/Gateway"
resource.labels.gateway_id="stream-gateway"
resource.labels.location="asia-northeast1"
log_name="projects/PROJECT_ID/logs/apigateway.googleapis.com%2Frequests"切り分けでは、15秒付近で毎回終わるならdeadline、300秒付近ならCloud Runなど上流の既定値、最初からまとまって届くならバックエンドのバッファリングを疑います。特定ネットワークだけで止まる場合は企業プロキシや中間装置も確認します。API Gatewayの32MB応答上限はストリーミング／チャンク応答には適用されませんが、要求は32MBのままです。大きな添付を送れる根拠にはなりません。
MCPは有効化だけではストリーミングにならない
API Gatewayをストリーミング対応で作成しても、の応答は単一のapplication/json本文のままです。LLMのチャット応答をSSEにできることと、MCPのツール呼び出しを自動的に逐次配信できることを混同しないでください。構造化出力と外部処理の境界は、構造化出力とツール呼び出しの違いで整理しています。
パブリックプレビュー中は、ネットワーク下り料金はストリーミング対応ゲートウェイに対して請求されない一方、Service Controlの課金は継続します。料金や制限は一般提供までに変わり得ます。本番採用は、カスタムドメインとが使えない条件、新ホスト名、IaC未対応、最大1時間の接続を受け入れられるかで判断してください。まず別ゲートウェイで評価し、失敗時に旧経路へ戻せる状態を保つのが安全です。
