【Seer エージェント】答えはすでに Sentry の中に。あとは尋ねるだけ
Article by: Rahul Chhabria 要約：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 自体は存在しているものの、エラーメッセージはあまり役に立たず、本当の問題はスタックトレースでは届かない上流側にある、というケースです。 […]
エージェントがエージェントをオーケストレーションする時、誰が監視するのか？
Article by: Paul Jaffre かつて、あなたが監視していたのはサービスでした。 その後、サービス内部で動く AI 呼び出しを監視するようになりました。 そして今では、AI エージェント自身がタスクを完了するために別の AI エージェントを立ち上げるようになっています。これまでの監視に対する感覚は、もはや通用しなくなりつつあります。 これは仮定の話ではありません。エージェント型アーキテクチャは、すでに本番環境で動いています。コーディングエージェントが検索エージェントを呼び出し、オーケストレーターが検索、計画、実行のための専門サブエージェントを生成しています。チームは、それらをどう監視するかを理解するよりも早いスピードで、こうしたシステムを出荷しています。 問題はエージェントが失敗することではありません。問題なのは、失敗した時にどのエージェントが原因だったのか、あるいはそもそも技術的に「失敗」と呼べるものが起きていたのかすら分からないことです。 従来のトレーシングはこの世界のために作られていない 従来のスタックでは、リクエストをデバッグするとは、エントリーポイントからデータベースまで、1本の流れを追跡することを意味していました。1つのサービス、1人の責任者、1か所の調査対象です。 しかしマルチエージェントシステムでは、1回のユーザー操作によって、プランナーエージェント、3つのツール呼び出しエージェント、検証エージェント、書き込みエージェントが動作するかもしれません。つまり5つのアクターが関与し、それぞれ異なるモデル、異なるプロンプト、そして大きく異なるレイテンシ要件を持っている可能性があります。 しかも、エラーは必ずしも例外として表面化しません。サブエージェントによる不適切な出力は、エラーを投げることなく、単に問題の連鎖を始めるだけかもしれません。その破損したコンテキストは、後続のチェーンへと伝播していきます。オーケストレーターは成功したと思っている。しかしユーザーはおかしな結果を見る。そしてログを開いても、明らかに壊れているものは何も見つからないのです。 これが実際にどのようなものかを見たいなら、実際のマルチエージェントデバッグセッションを分解した事例を見るとよいでしょう。2段階上流で発生した静かなツール障害が、1つのエラーも発生させないまま最終出力を破壊していく様子が示されています。「ログを読めば分かる」という感覚が、このレベルの複雑さでは通用しなくなる理由をよく表しています。この世界では、小さなズレが積み重なり、やがて雪崩のように広がっていくのです。 この投稿では、チーム横断かつエンタープライズレベルの信頼性が求められる大規模運用環境において、その複雑さがどのように現れるのかに焦点を当てます。 可視性の問題はスケールとともに増幅していく 1つのエージェントなら把握できます。2つでも管理可能でしょう。しかし、5つのエージェントが条件分岐しながら互いを呼び出し、コンテキストを共有している状態になると、それはもはやまったく別の種類の問題になります。 あなたがデバッグしているのは、もはやコード実行ではありません。分散した意思決定グラフ全体にわたる、創発的な振る舞いです。かつてマイクロサービスによって、「スタックのどこかが遅い」という言葉が、トレースなしでは意味を持たなくなったように、マルチエージェントシステムでは、適切なインストルメンテーションなしに「AI が何かおかしなことをした」と言われても、ほとんど対処不能になります。 多くのチームは、それを痛みを伴って学びます。たとえば、原因不明のユーザー離脱率の急増かもしれません。あるいは、チェーンの3段階下流で、LLM が静かに誤ったデータを返しているケースかもしれません。ある日突然、トークンコストが3倍になっていることもあるでしょう。しかし、単一コンポーネントとして閾値を超えていないため、アラートは何も発火しません。 分散トレーシングは、マイクロサービスにおいて、まさにこの問題を解決してきました。今問われているのは、あなたの AI パイプラインが、その次の世代の問題に対応できるようインストルメントされているかどうかです。 実際に役立つマルチエージェント監視とは マルチエージェントシステムの可視化は、新しい製品カテゴリの話ではありません。重要なのは、適切な粒度で、適切な基本要素を適用することです。Sentry の AI オブザーバビリティ機能は、分散トレーシングと同じ基盤の上に構築されています。そのため、複雑さが増しても、基本的な考え方は変わりません。実際には、次のようなものが必要になります。 エージェント間ハンドオフをまたぐトレース継続性 トレース ID は、エージェント呼び出しごとにリセットされるのではなく、タスク全体を通して引き継がれる必要があります。必要なのは、誰が何を、どの順番で、どの入力と出力を伴って呼び出したのかを示す完全なツリー構造です。すべてのスパンが同じ親を持つフラットな一覧では、チェーン途中のどのエージェントが不正な状態を生み出したのかを理解するには不十分です。 エージェント単位でのスパン属性付け レイテンシ、トークン使用量、モデルバージョン、プロンプトハッシュ、出力シグナルなどは、トップレベル呼び出しへまとめるのではなく、各エージェント単位で把握できる必要があります。「オーケストレーターが 4.2 秒かかった」という情報だけでは、ほとんど意味がありません。しかし、「低信頼度の結果を返した検索サブエージェントを 3.8 秒待っていた」と分かれば、調査箇所は明確になります。このレベルの属性付けは、モデルバージョン、トークン数、プロンプト識別子などのメタデータを、インストルメンテーション時に各スパンへ付与することで実現できます。 障害モードの区別 エージェントのタイムアウト、不正なツール出力、コンテキストウィンドウのオーバーフロー、モデル拒否、技術的には正常な応答の下流で発生するハルシネーション。これらはすべて異なる問題であり、必要な対処法もまったく異なります。それらをすべて「AI エラー」と一括りにするのは、すべての 500 […]
【マルチエージェントAI – デバッグ】障害がエージェント間の「隙間」で発生するとき
Article by: Sergiy Dybskiy 私は最近、マルチエージェント型のリサーチシステムを構築していました。アイデア自体はシンプルです。「PythonバックエンドをRustへ書き換えるべきか？」のような議論の分かれる技術トピックを与えると、3つのエージェントがそれぞれ役割を担います。Advocate は賛成側を主張し、Skeptic は反対側を主張し、Synthesizer は両者のブリーフを先入観なしに読み込んで、バランスの取れた分析を生成します。各エージェントはそれぞれ異なるモデル、異なるツール、異なるシステムプロンプトを持っています。 テストではうまく動いていました。しかし、そのうち Synthesizer が片側に強く寄った分析を繰り返し生成していることに気づきました。間違っているわけではないのですが、明らかに偏っていたのです。たしかに Sentry のモノレポをRustへ書き換えるのは悪いアイデアかもしれませんが、本来なら賛成になるべきだと明確に分かっているケースでも反対寄りの結論になっていました。 最終的に原因をたどると、Skeptic 側の web_search ツールに行き着きました。Advocate はクエリごとに3〜4件のしっかりしたデータポイントを返していました。一方 Skeptic は、データとうまく一致しない別の検索語を使っており、結果として汎用的な検索結果を1件返しているだけでした。そのため、Advocate のブリーフには引用付きの十分な根拠がありましたが、Skeptic のブリーフは……雰囲気だけになっていました。 Synthesizer は、合理的な読み手なら当然するであろう判断をしただけです。より根拠が揃った側の主張を、より重く扱ったのです。 問題は、ある1つのエージェント内のツール呼び出しにありました。そしてその問題が、2段階後にまったく別のエージェントへ渡される入力品質を静かに劣化させていたのです。私がそれを発見できたのは、トレースをクリックしながら各ステップのツール出力を順番に読み進めたからでした。 マルチエージェントのオブザーバビリティとは？ マルチエージェントのオブザーバビリティとは、複数のAIエージェントがどのように協調し、作業を引き継ぎ合い、互いの意思決定へ影響を与えているかを可視化することです。 おそらく、単一エージェントのオブザーバビリティについてはすでにご存じでしょう。1本の推論チェーンがあり、いくつかのツール呼び出しがあり、最終的なレスポンスが返る、というものです。マルチエージェント版では、1つのエージェントの出力が別のエージェントの入力になる、相互接続された推論チェーンのグラフ全体を追跡します。このグラフのどこか1か所で失敗が起きると、その後段すべてを静かに壊してしまう可能性があります。 もし、いくつかのツールを持つ単一エージェントを動かしているだけなら、通常のエージェントオブザーバビリティで十分です。しかし、エージェント同士が他のエージェントを呼び出したり、サブタスクを委譲したり、並列実行した結果を後から統合したりし始めた瞬間、必要になる可視性のレベルは別物になります。 なぜ単一エージェント向け監視では不十分なのか 既存のエージェント監視では、「Skeptic が3.1秒で実行され、2,400トークン消費した」ということは分かります。しかし、それだけでは、Skeptic の web_search が弱い検索結果しか返していなかったこと、その結果生成されたブリーフが Advocate に比べて薄かったこと、そして Synthesizer が片方の入力品質の低さによって偏った分析を生成したことまでは分かりません。 これが破綻する理由は、主に3つあります。 まず、責任の所在が分散していることです。最終出力が間違っていたとしても、単一のエージェントだけを責めることはできません。Advocate はツールから得た情報を元に合理的な主張を組み立てていましたし、Synthesizer も受け取った情報を合理的に統合していました。問題は両者の相互作用の中にあり、単一エージェントのログだけを見ても発見できません。 次に、最悪の失敗ほど一見正常に見えることです。従来のソフトウェアでは、問題が起きればエラーが投げられます。しかしマルチエージェントAIでは、あるエージェントが「もっともらしいが薄い結果」を返し、次のエージェントがそれを疑わず取り込み、最終出力が返る頃には、弱いデータが何段階もの推論を経て自信満々に要約されています。生の入力同士を比較しない限り、その問題には気づけません。 さらに、すべての経路をテストできないという問題があります。5つのツールを持つ単一エージェントであれば、各ステップで取り得る行動は5通りです。しかし、5つのツールを持つ3つのエージェントが並列実行され、後で結果を統合する場合、可能な実行経路の数は膨大になります。すべての組み合わせを事前テストすることはできないため、本番環境で実際に何が起きているかを観測する必要があります。 多くの「マルチエージェント」は実際には単一エージェント 先へ進む前に、正直に言っておきたいことがあります。私は最初、この実験環境でマルチエージェント型のスタートアップアイデア検証システムを作りました。しかし途中で気づきました。これは偽物のマルチエージェントだったのです。 「Market […]
すべてをサンプリングせず、AIトレースを100%取得する
Article by: Sergiy Dybskiy 少し前、エージェントたちが「あなたは完全に正しいです！」と言っていた頃、私はwebvitals.comを作っていました。URLを入力すると、Next.jsのAPIルートへのAPIリクエストが開始され、いくつかのツールを持つエージェントが呼び出されてそれをスキャンし、あなたの……そう、想像どおり……Web Vitalsを改善するためのAI生成の提案を提供します。今もこれを気にする必要はあるのでしょうか？ 開発環境ではtraceSampleRateを100%に設定していましたが、本番環境ではそれを10%まで下げていました。なぜなら……まあ、それが私たちのインストルメンテーションで推奨されているからですが。 Kyleは「【Sentry サンプリング戦略】すべてを見ようとすると結局なにも見えなくなる」と説明する優れたブログ記事を書いています。しかし、AIは非決定的です。そしてツールコールのエラーをデバッグしていたとき、そのサンプリング戦略のせいで、Vercel AI SDKから出力される非常に重要なスパンを見逃していることに気づきました。 7回のツールコールを伴うエージェントの実行は、部分的にサンプリングされることはありません。スパンツリー全体を取得するか、完全に失うかのどちらかです。これがヘッドベースサンプリングの仕組みです。 私は幻を追いかけていたわけです。 エージェントの実行はスパンツリーであり、サンプリングは全取得かゼロかのどちらか 一般的なエージェントの実行は、Sentryのトレースビューでは次のように表示されます。 1回の実行で11個のスパンがあり、サンプリングの判断はルートで一度だけ行われます。それは POST /api/chat のHTTPトランザクションです。すべての子スパンはその判断を引き継ぎ、ルートが破棄されれば、9個すべてのスパンが消えます。 これはHTTPリクエストのサンプリングとは本質的に異なります。GET /api/users を1つ捨てたとしても、次のリクエストはほぼ同じなので大きな問題にはなりません。 エージェントの実行は同一ではありません。それぞれが異なる判断を行い、異なるツールを呼び出し、異なるデータを処理します。67回目の実行でハルシネーションを起こしたエージェントが、420回目では完全に正常に動作するかもしれません。もしサンプルレートによって67回目が捨てられていたら、何が問題だったのかを知ることはできません。 ヘッドベースサンプリングが実際にどのように動作するのか（そしてここでなぜ重要なのか） SentryのJavaScriptおよびPython SDKはいずれもヘッドベースサンプリングを使用しています。判断はトレースの開始時、まだ子スパンが存在しない段階で行われます。 JavaScript SDKでは、SentrySampler.shouldSample() がこの点を明確に示しています。 ルートでないスパンには決定権はありません。ルートスパンが破棄された場合、gen_ai.request や gen_ai.execute_tool を含むすべての子スパンについて tracesSampler が呼び出されることはありません。子スパンは親の運命を引き継ぎます。 Pythonでも同じロジックは Transaction._set_initial_sampling_decision() にあります。traces_sampler コールバックには sampling_context の辞書が渡され、その中には transaction_context（op と name を含む）と parent_sampled が含まれます。これはルートトランザクションに対してのみ実行されます。 つまり、ヘッドベースサンプリングでは、親トランザクションとは別に […]
【Autofix】AIを使ってプログラムを簡単にデバッグ＆修正する方法
Sentryはアプリケーションのコードベースの内部構造について多くのことを知っています。 そこで私たちは、この豊富なデータセットを使って、デバッグをさらに高速化するにはどうすればいいかを考えました。 多くのジェネレーティブAI（GenAI）ツール（GitHub Copilotなど）は、開発環境における開発者の生産性を向上させますが、Sentryのような本番環境でのエラー修正を支援するコンテキストデータを持つものはほとんどありません。 私たちの新しい『AI対応Autofix機能』は、エラーが発生したときにユーザーが何をしているかを理解し、エラーを分析し、修正を生成し、さらにあなたのレビューのためにプルリクエストを開きます。 これは、オンデマンドで支援する準備ができているジュニア開発者を持つようなものです。 Autofixは本番環境でのエラーのデバッグを支援するためのものですが、もし開発中にそのような支援が必要だと感じたら、Codecovの新しいAIコードレビューをお試しください。 AIを搭載したAutofixの仕組み Autofixはエージェントベースのアーキテクチャを使用し、Sentryの問題を評価し修正するプロセスを管理可能な作業単位に分割します。 まず初めに、問題発見エージェントで、問題の予備評価を行い、コード変更で修正可能かどうかを判断します。 次に、プランニングエージェントが、エラーメッセージとお客様のコードベースから関連するコンテキスト情報を使用して、根本的な問題を解決するための実行プランを構築します。 このプランは、修正と付随する単体テストの生成を担当するAutofixの実行エージェントに渡されます。 最後に、PRを生成する前に、すべての変更を最終的にレビューします。 このプロセスは、反復的で透明性があるように設計されています。 システムは、積極的にコンテキストとフィードバックを求めながら進み、各ステップの結果は、開発者にとってなじみのあるCIライクなインターフェイスで表示されることも特徴的です。 IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。