Vertex AI で復元力の高い LLM アプリケーションを構築し、429 エラーを減らす

※この投稿は米国時間 2026 年 3 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Vertex AI で大規模言語モデル（LLM）を活用したアプリケーションを構築するのは楽しいことですが、429 エラーが発生すると、イライラの原因になることがあります。これらのエラーは、リクエストの受信速度が、その時点でサービスが処理できる量を上回っていることを示しています。

昨年、Google はこれらの 429 エラーの処理に関するガイドを公開しました。この記事では、Vertex AI の使用量モデルについて詳しく掘り下げ、リクエスト フローを管理するためのアーキテクチャのベスト プラクティスについて説明します。これにより、スムーズで復元力が高く、真にスケーラブルな AI アプリケーションを構築できます。

適切な使用量オプションの選択

Vertex AI は、さまざまなタイプとボリュームの API トラフィックに対応するように設計された、幅広い使用量モデルが用意されています。429 エラーを最小限に抑えるための主な戦略は、アプリケーション固有のトラフィック パターンに最も適した使用量モデルを選択することです。

デフォルト オプション: Vertex AI の Gemini におけるデフォルト オプションは、Standard 従量制（Paygo）です。Standard 従量制（Paygo）トラフィックの場合、Vertex AI は使用量ティアシステムを使用します。この動的なアプローチでは、共有プールからリソースが割り当てられ、組織の過去の費用に基づいて使用量ティアとベースライン スループット（TPM）が決まります。このベースラインにより、一般的なワークロードの予測可能なパフォーマンスの下限が決まるものの、アプリケーションは引き続きベスト エフォート ベースでそれ以上のパフォーマンスを発揮できます。

予測不可能で、Standard Paygo よりも高い信頼性を必要とする、重要なユーザー向けトラフィックをアプリケーションが生成する場合は、Priority Paygo が適しています。リクエストに優先度ヘッダーを追加することで、そのトラフィックを優先すべきであることを示し、スロットリングされる可能性を減らします。

リアルタイム トラフィックの量が常に多いアプリケーションの場合、共有 PayGo プールから分離できる使用量オプションはプロビジョンド スループット（PT）だけであり、PayGo における競合が激しい場合でもエクスペリエンスが安定します。PT では、保証されたスループットを予約して料金を支払うことで、重要なトラフィックがスムーズに流れるようにします。Vertex AI での PT について詳しくは、こちらのガイドをご覧ください。

費用対効果の高いオプション: Vertex AI には、レイテンシの影響を受けにくいトラフィック向けに、費用対効果の高いオプションが用意されています。Flex PayGo は、レイテンシが許容されるトラフィックに適しており、リクエストを低料金で処理します。オフライン分析や一括データ拡充などの大規模な非同期ジョブは、Batch で処理するのが最適です。このサービスは、スケーリングや再試行を含むワークフロー全体をより長い期間（約 24 時間）にわたって管理し、メインのアプリケーションをこの高い負荷から保護します。

複雑なアプリケーションとハイブリッド アプローチ: 複雑なアプリケーションでは、ハイブリッド アプローチがよく利用されます。PT は最も重要なリアルタイム トラフィック、Priority Paygo は変動するトラフィック、Standard Paygo は一般的なリクエスト、Batch / Flex はレイテンシが許容されるオフラインのリクエスト フローに使用されます。

Vertex AI で 429 エラーを減らす 5 つの方法

1. スマート再試行の実装

アプリケーションで 429（リソース不足）や 503（サービス利用不可）などの一時的なオーバーロード エラーが発生した場合、すぐに再試行することは推奨されません。ベスト プラクティスとして、ジッターを伴う指数バックオフと呼ばれる再試行戦略を実装できます。指数バックオフとは、再試行の間隔が指数関数的に長くなり、通常は事前定義された上限まで長くなることを意味します。これにより、サービスが過負荷状態から回復する時間を確保できます。

• SDK とライブラリ: Google Gen AI SDK には、クライアント パラメータの HttpRetryOptions を使用して構成できるネイティブの再試行動作が含まれています。ただし、Tenacity（Python 用）などの専用ライブラリを活用したり、カスタム ソリューションを構築したりすることもできます。詳しくは、こちらのブログ投稿をご覧ください。

• エージェント ワークフロー: エージェントを開発するために、Agent Development Kit（ADK）には Reflect and Retry プラグインが用意されています。このプラグインは、429 エラーを自動的にインターセプトすることで、AI ワークフローに復元力を組み込みます。

• インフラストラクチャとゲートウェイ: Apigee によるサーキット ブレーキングも、復元力を高めるためのもう一つの堅牢なオプションです。これにより、トラフィックの分散を管理し、正常な障害処理を実装できます。

2. グローバル モデル ルーティングの活用

Vertex AI のインフラストラクチャは複数のリージョンに分散されています。デフォルトでは、特定のリージョン エンドポイントをターゲットにした場合、リクエストはそのリージョンから処理されます。これは、その単一リージョンの容量に基づいてアプリケーションの可用性が決まることを意味します。そして、グローバル エンドポイントが、可用性と復元力を高めるための効果的なツールとなります。グローバル エンドポイントは、1 つのリージョンに限定されるのではなく、可用性がより高い可能性のあるリージョン フリート全体にトラフィックをルーティングし、潜在的なエラー率を低減します。

3. コンテキスト キャッシュによるペイロードの削減

Vertex AI の負荷を軽減する効果的な方法として、繰り返しクエリの呼び出しを避けることができます。多くの本番環境アプリケーション、特に chatbot やサポートシステムでは、似たような質問が頻繁に寄せられます。それらの質問を再処理する代わりに、コンテキスト キャッシュを実装できます。コンテキスト キャッシュ保存を使用すると、Gemini は事前に計算されたキャッシュ トークンを再利用するため、API トラフィックとスループットを削減できます。これにより、費用を節約できるだけでなく、プロンプト内の繰り返しコンテンツのレイテンシも短縮されます。

4. プロンプトの最適化

各リクエストのトークン数を減らすと、TPM の使用量と費用が直接削減されます。

• Flash-Lite による要約: Gemini Pro などのモデルに長い会話履歴を送信する前に、Gemini 2.5 Flash-Lite などの軽量モデルを使用してコンテキストを要約します。

• エージェント メモリ最適化: エージェント ワークロードでは、Vertex AI Agent Engine Memory Bank を活用できます。メモリーの抽出と統合などの機能により、会話から意味のある事実を抽出できるため、エージェントは未加工のチャット履歴がなくてもコンテキスト アウェアな状態を維持できます。

• プロンプトの衛生: プロンプトを確認し、詳細すぎる JSON スキーマの説明（モデルがすでに精通している場合）を減らし、過剰な空白や冗長な書式設定を削除します。

5. トラフィックのシェイプ

リクエストの急激なバーストは、429 エラーの主な原因です。平均トラフィック レートが低くても、急激に増加するとリソースに負荷がかかる可能性があります。目標は、トラフィックを平滑化し、長期間にわたってリクエストを分散することです。

使ってみる

ご紹介したパターンを実際に使用される場合は、 GitHub の Vertex AI サンプルを確認するか、Google Cloud 初心者向けガイドの Vertex AI クイックスタートを使用して次のプロジェクトをすぐに開始するか、Agent Development Kit（ADK）で次の AI エージェントの構築を開始してください。

- Google Cloud シニア プロダクト マネージャー、Richard Liu

- Cloud AI テクニカル エバンジェリスト、Pedro Melendez