Article by: Kush Dubey
Seerはバグを受け取り、Sentryが持つあらゆるコンテキストを使って根本原因を特定し、修正案を提案するAIエージェントです。私たちはこれを日常的に使い、Sentryの改善に役立てています。SeerはSentryを修正します。
最近では、Seerは自分自身の修正にも役立っています。つまりSeerがSeerを修正する、ということです。
ある上流の障害が連鎖的な影響を引き起こし、数か月間潜んでいたバグを露呈させました。修正する段階になったとき、Seerは私たちが見るべき場所を正確に指し示しました。
警報が鳴る
2026年2月21日、SeerのAIによるIssueサマリー機能がEUリージョンで停止しました。
SeerのIssue Summary APIエンドポイントへのリクエストの約80〜90%が失敗しており、その結果、すべての新しいSentry Issueにおいて「AI Summary」カードが壊れた状態になっていました。アクショナビリティスコアは表示されず、自動Autofixの実行も行われませんでした。そして40,000件以上のエラーが流入しました。
このような事態を引き起こすような変更は直近で行っていなかったにも関わらず、なぜ今起きたのでしょうか。
原因は上流の問題でした。SeerのAIサマリーはGoogle Cloud Platform（GCP）のVertex APIを通じて、gemini-2.5-flash-lite上で動作しています。GCPは後に、複数のEUリージョンにおけるgemini-2.5-flash-liteの可用性に関するインシデントを公表しました。
しかし、それは本来であれば軽微な性能低下にとどまるはずでした。なぜなら、Vertex AIでスループットを確保しており、その約12%しか使用していなかったからです。
管理可能な上流の可用性問題を完全な障害へと変えてしまったのは、私たち自身のコードでした。失敗するリージョンをスキップするために構築したレイテンシ最適化により、EU内のすべてのGeminiリージョンがブロックリストに登録されてしまい、保証されたキャパシティを持っていたリージョンまでも含まれてしまいました。
SeerがEUでLLMコールをどのようにルーティングするか
前述のとおり、SeerはGCPのVertex AIを通じてgemini-2.5-flash-liteを実行しています。EUデプロイでは、europe-west1にプロビジョンドスループット（PT）を確保しており、これによりVertex AI全体の需要が急増した場合でも、予約されたキャパシティを利用できます。
その他の複数のEUリージョンでは、Standard pay-as-you-go（Standard PayGo）を使用しています。Standard PayGoはベストエフォート型のキャパシティであり、Googleが過去30日間のVertex AIの総利用額に基づいてクォータを設定しますが、需要が急増した場合の保証はありません。
SeerのLLMクライアントは、一時的なブロックリストを伴うリージョンフォールバックを実装しています。短時間のうちに1つのリージョンで6回の対象となる失敗が発生した場合、そのリージョンは一時的にローテーションから除外されます。この機能はレイテンシに敏感なサービスにとって重要です。というのも、429や504のレスポンスは通常2〜4秒かかって返ってくるためです。50〜100回のLLMコールを行うインタラクティブなAutofixセッションでは、これらの遅延が積み重なります。
このシステムには重要な不変条件があります。PTリージョンを決してブロックリストに登録してはいけない、ということです。ここは保証されたキャパシティであり、これをブロックリストに登録することは、負荷を処理するために料金を支払っている唯一のリージョンを放棄し、処理能力を持たないリージョンにすべての負荷を押し付けることを意味します。
この障害によって、これまで潜んでいたバグが明らかになりました。私たちはこの不変条件をUSデプロイでは適用していましたが、EUデプロイには追加し忘れていました。
連鎖
私たちのPTリージョンであるeurope-west1は、Google側でモデルが断続的に利用できなかったため、504 Deadline Exceededエラーを返し始めました。
短時間に6回の失敗が発生するとブロックリストの閾値を超えるため、europe-west1は頻繁にローテーションから除外されるようになりました。
europe-west1がブロックリストに登録されると、すべてのトラフィックがStandard PayGoリージョンへと移動しましたが、それらは全負荷を処理できるようにはプロビジョニングされていませんでした。europe-west4は429 RESOURCE_EXHAUSTEDを返し始めてブロックリストに登録され、続いてeurope-central2も同様になり……という流れになりました。数分以内に、クライアントはEU内のすべてのリージョンを順にブロックリストに登録し、その後のすべてのコールはLlmNoRegionsToRunErrorを返すようになりました。使用可能なリージョンが一つも残っていなかったのです。
GCPのインシデント中であっても、europe-west1へのコールの大半は成功していました。これは、プロビジョンドスループットが負荷を吸収していたためです。しかしブロックリストは成功率に関係なく6回の失敗で発動するため、大半のリクエストを正常に処理していても、たまたま6回の失敗が集中すれば、そのリージョンは除外されてしまいました。
修正はPTリージョンがブロックリストに登録されないようにするallowlistにeurope-west1を追加することでした。これをデプロイしてから数分以内に、失敗率はベースラインに戻りました。
必要だったもの
USデプロイには、そのPTリージョンに対するハードコードされた例外がありましたが、EUデプロイでスループットをプロビジョニングした際（以前、負荷増加によって429の波が発生したインシデントの後に）、ブロックリストのコードに対応する例外を追加しませんでした。設定は、開発者が別途手動で管理されているリストを更新することに依存しており、これはインフラのプロビジョニングとアプリケーション側の認識との間に生じる典型的なギャップでした。
二次的な問題は、そのヒューリスティック自体にあります。総リクエスト数や成功率に関係なく、6件のエラーという閾値が、数か月前の負荷を基にハードコードされていました。私たちはこれを、エラー率ベースのアプローチに置き換えています。
SeerがSeerをデバッグする
SentryのAIデバッグツールが、SentryのAIデバッグツールの障害をデバッグするために使われるというのは、明らかな皮肉があります。しかし実際には、影響範囲を把握するための最も速い手段でした。
最初の検知は、通常のSentryアラートによるものでした。しかし、実際に何が壊れていたのか、どのユーザー向け機能が影響を受けていたのか、どのリージョンなのか、どのモデルなのか、そしてこれがEU限定なのかグローバルなのかを把握できたのは、SeerがそのLlmNoRegionsToRunErrorのIssueに対して分析を実行した結果でした。
数秒以内に、Seerは約42,000件のエラーの大部分が失敗したIssueサマリーによるものであることを特定し、スパム検知（約1,600件）とAutofix（約850件）にも影響が及んでいることを示しました。また、イベントの99%以上がEUデプロイで発生していることを確認し、breadcrumbのトレイルを通じてブロックリストの連鎖を追跡しました。
分析は自律的に根本原因のほとんどに到達しました。
最後の一歩として、PTリージョンはブロックリストに登録されるべきではなかったという認識は、プロビジョンドスループットの構成に関する人間の知識から得られました。しかしSeerは、原因としてリージョンのブロックリスト機構を直接指し示しており、さらにGCPのインシデント中であってもPTリージョンへのコールの大半が成功していたことを確認していました。これはまさに、エンジニアが修正にたどり着くために必要としていた事実の組み合わせでした。
教訓
レイテンシ最適化には、まったく最適化が存在しない場合よりも悪い結果を招く潜在的な失敗モードがあります。過度に開きやすいサーキットブレーカー、予約されたキャパシティを考慮しないブロックリスト、あるいは障害を増幅させるフォールバックチェーンは、それぞれが上流プロバイダのインシデントを、自分たち自身が引き起こす完全な障害へと変えてしまう可能性があります。
このバグが突いたギャップは、ありふれていてよくあるものです。「GCPにキャパシティをプロビジョニングした」という事実と、「アプリケーションコードがそのプロビジョニングを認識している」という状態との距離です。複数のリージョンにまたがってLLMリクエストをルーティングしているのであれば（AI機能をスケールさせて運用しているなら、おそらくそうしているはずです）、サーキットブレーカーを見直し、どのリージョンが特別に扱われるべきかを認識しているか確認してください。この修正は、わずか6行のコードでした。
Original Page: Seer fixes Seer: How Seer pointed us toward a bug and helped fix an outage
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
