【Seer エージェント】答えはすでに Sentry の中に。あとは尋ねるだけ

06/15/2026

要約：Seerエージェントをリリースします。これは、Sentry があなたのアプリについて把握しているあらゆる情報をもとに、質問して答えを得られる機能です。本日より、すべてのユーザー向けにベータ提供を開始します。Sentry 上で Cmd + / を押すか、Slack でメンションするだけで、さまざまな問題の解決に活用できます。どれほど便利か、ぜひ続きを読んでみてください。

これは、あるエンジニアにとって、ひどい夜になっていてもおかしくなかったのに、結果的には……そこまで悪くならなかった、という話です。

数週間前の土曜日、私たちの AI デバッガー Seer が障害を起こし始めました。

右側にある大きくて恐ろしいスパイクに注目してください。

エラーは、LLM 呼び出しに関する一般的な失敗メッセージで、根本原因を示すような情報は何もありませんでした。その週末は、チームの大半がオンコール予定ではなく、たまたま AI 部門責任者の Indragie がオンラインでした。彼はエンジニアたちを呼び出し始めました。

他のメンバーがオンラインになるのを待つ間、彼はここ数か月間、社内でテストしていたツールを開きました。それが Seerエージェントです。Indragie は、現在見えている状況を Seerエージェントに伝え、「何が起きているのか調べてほしい」と依頼しました。すると、数秒で結果が返ってきました。モデル呼び出しは、特定モデルに対して、特定リージョンでレート制限を受けていました。しかも、こちら側ではトラフィックを処理するための十分なスループットを確保していたにもかかわらずです。

最終的にこのレート制限は、プロバイダー側の上流インフラ障害による症状だったことが、インシデント後に確認されました。しかし、その時点ですでに Seerエージェントは、「どのリージョン」「どのモデル」に問題が集中しているかを正確に示しており、問題がプロバイダー側にあることは明らかでした。それ以外の部分は、すべて正常でした。

これは本来であれば、誰かがダッシュボードを開き、リージョンごとにフィルタし、トラフィックとエラー率を突き合わせ、その傾向に気づき、「なぜ特定リージョンだけで問題が起きているのか」を逆算していく、そんな流れで進むタイプの調査です。Indragie は非常に優秀ですが、日々コードベースに直接関わっているわけではありません。彼はマネジメント側です 😉 なので、そこへたどり着くまでには少なくとも30分はかかっていたと思います。正直に言えば、もっと長かったでしょう。

オンコール担当のエンジニアがチャンネルに参加する前には、すでに根本原因まで特定できていました。

それこそが、Seerエージェントの役割です。「Twitter で大騒ぎになるレベルの大規模障害」から、「何か遅いけれど理由が分からない」といった問題まで、アプリケーション内で起きているあらゆる問題を調査するためのツールです。

本日（2026/4/28）、Seerエージェントをオープンベータとして、すべてのユーザー向けに提供開始します。

問題は必ずしも Issue とは限らない

Seer の当初のコンセプトはシンプルでした。Sentry が Issue を検知すると、Seer がスタックトレース、トレースデータ、ログ、リプレイ、コミット履歴、コードを読み取り、「何が問題なのか」を説明する、というものです。これがうまく機能するのは、調査の出発点が明確だからです。つまり、「Issue」が存在し、必要なデータもすでにそこへ紐づいています。

ですが、実際のデバッグは、必ずしもエラーから始まるわけではありません。

ときには、Indragie のケースのように始まります。Issue 自体は存在しているものの、エラーメッセージはあまり役に立たず、本当の問題はスタックトレースでは届かない上流側にある、というケースです。

こうした状況では、「何かがおかしい」という症状は分かっています。ただ、「どこを見ればいいのか」が分からないのです。

そこで、まずは手作業で調査を始めます。Trace Explorer を開き、クエリを書き、環境ごとにフィルタし、リージョン単位でグループ化し、logsへ切り替え、タグを軸に絞り込み、さらに上流サービスのエラー率を確認し、再びトレースへ戻って別の span 属性を試す。まだデバッグをしているわけではありません。デバッグを始める場所を探している段階です。

Seerエージェントは、その「探索」を代わりに行うツールです。あなたが見えている症状を説明すると、Sentry が持つあらゆるコンテキストを横断的にたどり、何が見つかったのかを返してくれます。

テレメトリはすでにグラフになっている

Sentry の Explore 機能を使えば、すでにテレメトリ全体を横断して検索できます。トレースに対してクエリを書き、ログをフィルタし、属性を軸にピボットすることもできます。Explore は非常に強力で、自分の Sentry データ構造を深く理解している人にとっては、特定の疑問へ最短で答えを出せる手段です。

ただ、Explore からデバッグを始める場合には問題があります。質問する前に、自分のデータ構造を理解していなければならないのです。どのサービスが問題のサービスの上流にあるのか分からなければ、そこをフィルタできません。どの span 属性で group-by すべきか分からなければ、group-by も手探りになります。Explore は、すでに地図を持っているオペレーターに有利なツールです。

Seerエージェントは検索ツール付きの汎用 LLM のようにテレメトリを検索しているわけではありません。Sentry のテレメトリはすでにトレースで接続されています。エラーが発生すると、Sentry はそのエラーが発生したトレースを把握しています。そして、そのトレース内の span、その span 中に出力されたログ、その時点でデプロイされていたバージョン、そのデプロイに含まれていたコミットまで認識しています。Seerエージェントは、それらの接続を直接たどります。時間範囲を推測しながらテキスト検索で正しい行が出ることを期待するのではなく、取り込み時点で構築されたグラフを横断しているのです。

具体的に言うと、あるエラーについて質問すると、Seerエージェントは、そのエラーを発生させた正確なトレース、そのトレース内の正確な span、その span から出力された正確なログ、さらにその span の元となった正確なソースコード行まで取得できます。しかも、一度も WHERE timestamp BETWEEN 句を書く必要はありません。そのうえで、同じグラフを逆方向にもたどれます。このエンドポイントへ関与した他サービスは何か、その瞬間にどのサービスが不健全だったか、それらのエラー率はどうだったか、といったことまで追跡できます。

これこそが、Indragie の調査を高速にした理由です。彼は Seerエージェントに「Vertex AI プロバイダーのリージョン別エラー率を見てくれ」とは指示していません。ただ Sentry の Issue を渡しただけです。Seerエージェントはトレースを取得し、失敗した呼び出しがどのリージョンへルーティングされていたかを確認し、同じプロバイダー経由で他モデルへ送られた最近の呼び出しと照合し、「特定のモデルファミリーだけが、特定リージョンで失敗している一方、他は正常」というパターンを発見して提示しました。本来なら4段階の手動ピボットが必要な調査を、一度で完了したのです。

難しい問題を解決する

自分で調査して解決するのが楽しいバグもあります。「このコード行やばいな、誰が書いたんだ……あ、自分だった。」みたいなものです。

ですが、そうではない問題もあります。巨大で、複雑で、厄介で、「どこから見ればいいのか」を理解するだけでも膨大なコンテキストを頭に入れなければならないタイプの問題です。そして、偶然ではなく、そうした問題こそ Seerエージェントが得意とする領域です。

原因が自サービスの上流にある障害
あなたのスタックトレースは自分の呼び出し箇所で終わっていても、本当の原因は別のデータセンターから返ってきた 429 かもしれません。通常なら、プロバイダーのステータスページを確認し、自分が利用しているリージョンに障害が出ているか調べ、自社トラフィックと突き合わせる必要があります。Seerエージェントは、トラフィックを「プロバイダー・モデル・リージョン・時間」というリクエスト形状で相関分析し、別タブを開く前に、「これは上流起因を示すパターンかどうか」を教えてくれます。

明確なアラートを発生させない障害
単一エンドポイントでの緩やかな性能低下、2時間前から始まった1%のエラー率上昇、p99 を見なければ分からないテールレイテンシの悪化。こうした調査は、「これに気づいたけど、本当に問題なのか確認したい」というところから始まります。Seerエージェントはベースラインを取得し、現在の時間帯と比較し、それが統計的に意味のある変化なのか、単なるノイズなのかを教えてくれます。

サービスを横断する障害
service A で Issue が発生しているが、本当の原因は10分前から service B が不正なレスポンスを返し始めていたことにある、というケースです。これをきれいに可視化するには、トレースで接続されたグラフが不可欠です。そして、人間が手作業でそのグラフをたどると、2ホップも進めばコンテキストを見失います。エージェントは見失いません。

ボトルネックは、「どこを見ればいいのか」から、「見つけた問題をどう解決するか」へ移ります。本来、エンジニアが時間を使うべきなのは、まさにそこです。

Slack 上の Multiplayer Mode

Slack 向け Seerエージェントは現在も積極的に開発中ですが、すでにベータ版として利用可能です。インシデント対応中に Sentry UI へ行き来する必要はなく、オンコール担当へ話しかけるように、DM や incident チャンネルでメンションするだけで調査を始められます。これは、私たちが Seerエージェントを開発中に Slack 上で実際に使っていた例です。

さらに興味深いのは、調査そのものがマルチプレイヤー化することです。Sentry UI 上では、Seerエージェントは個人向けのツールです。しかし Slack 上では、チャンネル内の誰でも途中から調査の方向を変えたり、エージェントが持っていなかったコンテキストを追加したり、あるいは単純にその探索過程を見ながらシステム理解を深めたりできます。さらに、調査内容はインシデント解決後もスレッド内に残るため、翌月に同じパターンが発生した際には、最初からやり直すのではなく検索して参照できます。

Slack から直接 Autofix を起動することも可能です。Sentry のアラートには、「Fix with Seer」ボタンと、推定されるエラー内容の初期分析が表示されるようになりました。これをクリックすると、Autofix の完全なワークフローが開始されます。この機能は現在、パブリックベータとして提供中です。詳しくはドキュメントをご覧ください。

セットアップは非常に簡単です。すでに Sentry の Slack integration をインストールしている場合、エラーアラート内の「Fix with Seer」ボタンはすでに有効になっています。まだ導入していない場合は、Settings → Integrations からインストールしてください。Slack 上で Seerエージェントへ DM を送ったり、チャンネル内で @mention したりするには、/sentry link を実行してアカウントを連携します。すでに Sentry アプリをインストール済みであれば、連携時に同じ workspace を選択するだけで、新機能が有効になります。

現在開発しているもの

現在、優先的に進めている項目をリリース予定順に挙げると以下のようになります。

インシデント作成時の自動トリアージ
現在は、Sentry や Slack 上で Seer に対して手動でプロンプトを送る必要があります。しかし理想的なのは、インシデントが作成された時点で自動的に調査を開始し、誰かが質問する前に incident channel へ調査結果を投稿する仕組みです。私たちの内部ではすでに設計が進んでおり、まずは自社のインシデントワークフローから導入を始めています。

プロアクティブなフォローアップ
エージェントは分析完了後、次に聞くべき質問を提案できるべきです。ユーザーが次の質問を考えるのを待つ必要はありません。「このパターンが他サービスにも存在するか確認しますか？」のような提案は、生成コストが低い一方で、長時間に及ぶ調査では大きな利便性向上につながります。

メッセージキューイングと強制割り込み
小さな機能ですが、どちらも非常に頻繁に寄せられる要望です。現在は、エージェントが応答中だと追加の指示をキューできませんし、途中の処理を強制終了して方向転換したくても、セッションを維持したまま実行できません。どちらも短期的な開発項目に入っています。