Google API Gateway、エージェント応答のストリーミングを試験提供

Google API Gateway がパブリック プレビューでストリーミングを追加

Google の 10 月 22 日の開発者発表では、API Gateway でのストリーミング サポートがパブリック プレビューとして利用可能であると述べています。ストリーミング エンドポイントは、増分イベントをクライアントに送信しながら、ゲートウェイ ポリシーの背後に配置できるようになりました。この発表は、特にマネージド Google Cloud API Gateway 製品に関するものです。開発者の既存のゲートウェイの動作が自動的に変更されるとは述べておらず、また、固定日に一般公開されることを約束するものでもありません。プレビューの起動時に、新しいゲートウェイが作成されるとストリーミングが有効になります。既存のゲートウェイを設定を通じてそのまま切り替えすることはできません。この作成時の境界により、チームが導入をどのように段階的に進めるべきか、またどのようにロールバックできるかが決まります。

増分配信によってゲートウェイ パスが変更される理由

多くの API ゲートウェイは、リクエストとそれに続く 1 つの完全なレスポンスを中心に構築されています。代わりに、生成モデルは生成時に出力を出力し、エージェントは中間ステップを報告する場合があります。ゲートウェイが本文全体をバッファリングすると、バックエンドが正しくストリーミングしている場合でも、アプリケーションは初期のフィードバックを失います。 Googleによると、プレビューではブラウザやクライアントSDKへのモデル出力の一般的なパターンであるServer-Sent Eventsがサポートされているという。この情報源では、存続期間の長いエージェントとリモート MCP トラフィックについても説明しています。エンジニアリングの目的は、ポリシーの適用とルーティングを維持しながら、バックエンドが終了する前にイベント配信を開始できるようにすることです。ユーザーが感じる実際の遅延は、モデル、ネットワーク、クライアント レンダリング、ゲートウェイ構成によって異なります。

Googleによると、モデルルーティング機能を使用するゲートウェイは、モデルガーデンを通じて入手可能なGemini、Claude、OpenAIのgpt-ossモデルからストリーミングできるという。モデル ルーティングは、単一の OpenAI 互換エンドポイントを公開し、リクエストのモデル フィールドからバックエンドを選択します。これは、認証、クォータ、およびコスト ポリシーの制御ポイントとしては便利ですが、統合エンドポイントでは、動作、コンテキスト制限、またはデータ条件においてモデルを交換可能にすることはできません。テストでは、どのモデルが実際にリクエストを処理したか、使用状況とエラーが正しく帰属されたかどうか、クライアントの切断リリースがアップストリームで機能するかどうかを記録する必要があります。ブログでは製品の動作について説明しています。この記事では、プロバイダーのストリーミング実装を独自にテストすることはありません。

パブリックプレビューには明確な制約がある

Google は、Serverless NEG と外部 Application Load Balancer を介したカスタムドメイン、Cloud コンソールからの有効化、Terraform 対応について、プレビュー開始時には利用できないものの、プレビュー期間中に追加する予定だと説明しています。これらが必要な運用者は、API Gateway という製品名だけで利用可能と判断すべきではありません。プレビューでは新規ゲートウェイの作成時にオプトインのフラグが必要です。一般提供時にはオプトインなしでストリーミングを標準動作にする計画ですが、これは将来の予定です。既存の非ストリーミングゲートウェイを維持しつつ別のテスト用ゲートウェイを作り、必要な管理機能とクライアントの動作を確認してからトラフィックを移すべきです。

メトリクスには別の解釈が必要です

Googleは、ストリームのリクエストレイテンシー指標は、最初のバイトまでの時間ではなく、接続の存続期間を測定するものであると警告しています。ユーザーが長期間にわたって増分出力を受信するため、そのメトリクスではストリーミング リクエストが遅く見える可能性があります。それはレイテンシーを無視する理由にはなりません。これは、最初のイベント、完了、アイドル ギャップ、切断動作を個別に測定する理由です。エージェント クライアントは、ツールを待っている間、または進行状況を配信している間、接続されたままになる場合があります。ゲートウェイのタイムアウト、クォータ、および請求処理をそのパターンに照らしてチェックする必要があります。そうしないと、アップグレードによって知覚される応答性が向上する一方で、ダッシュボードが正常なストリームを遅いトランザクションとして誤ってラベル付けする可能性があります。

このゲートウェイは、高価な AI エンドポイントにポリシー フロント ドアも提供します。応答が何秒も開いたままになっている場合、コンシューマごとの認証、レート制限、ルーティングがより緊急になる可能性があります。プレビュー ソースは、全面的なコスト削減やパフォーマンスの保証を提供しません。どのようなビジネス ケースにも、ゲートウェイ料金、アップストリーム モデルの使用状況、再試行、切断後の無駄な生成を含める必要があります。サーバーが SSE イベントを発行しても、それをバッファリングするクライアントは、意図した利点を提供していません。テストは、実際のクライアント ライブラリと、いくつかの監視可能なイベントを発行するバックエンドを使用して、エンドツーエンドで拡張する必要があります。

小さな統合テスト

使い捨て環境で新しいプレビュー対応ゲートウェイを作成し、それを既存の SSE テスト バックエンドにポイントします。各イベントが次のイベントが送信される前にクライアントに到達すること、認証とクォータ ルールが引き続き適用されること、および意図的なクライアントのキャンセルにより上流の作業が期待どおりに終了することを確認します。最初のイベントのレイテンシ、合計継続時間、エラー コード、使用状況の属性をキャプチャします。その製品機能が範囲内にある場合にのみ、モデル ルーティングされたリクエストを繰り返し、不正な形式のイベントと遅いバックエンドをテストします。最後に、移行をスケジュールする前に、発表されたプレビューの除外対象と構成を比較します。これらの手順は検証を提案するものであり、この出版物がプレビューを受け入れたと主張するものではありません。

この開発は、API ポリシー境界の内側で進行状況やストリーミングされたモデル出力を必要とするエージェント インターフェイスに役立ちます。これはまだパブリック プレビューであり、作成時にオプトインがあり、管理パスがありません。 10 月 25 日号の日付は、この分析が作成された日付を示しています。 Google の元の投稿の日付は 10 月 22 日です。チームは、ダイジェストをライブの機能ステータス サービスとして扱うのではなく、上流の発表と現在の製品ドキュメントを独自の展開の権威として使用する必要があります。