【Issue グルーピングの改善】より賢く、より速く、誤判定は半分に
Article by: Kush Dubey , Yuval Mandelboum（読了時間：9分） Sentry の役割は、アプリケーションで問題が発生した際に、それを開発者へ知らせることです。そのために、個々のエラーを Issue としてグループ化しています。まず、フィンガープリントを使ってエラー構造を字句レベルで照合し、一致しない場合は AI モデルが補完します。AI モデルは新しいエラーのスタックトレースを既存の Issue と比較し、意味的に類似していると判断した場合は同じ Issue として統合します。このたびモデルをアップグレードしたことで、重複 Issue の発生を20％多く防ぐとともに、誤った Issue 統合を半減させました。 AI による Issue グルーピングはデフォルトで有効になっており、すべての Sentry ユーザーに適用されています。 グルーピングが難しい理由 AI グルーピングの v1 については、「Transformer ベースのテキスト埋め込みモデルで Sentry アラートを 40% 削減 ー ノイズを突破」で解説しています。 優れたグルーピングアルゴリズムは、アンダーグルーピングとオーバーグルーピングの両方を最小化します。アンダーグルーピングを抑えるとは、同じ根本原因の問題に対して Sentry が新しい Issue を次々と生成しないことを意味します。オーバーグルーピングを抑えるとは、アプリが経験している新しいカテゴリのエラーを Sentry が必ず通知することを意味します。このバランスをうまく取るのは難しく、主観的な判断も伴います。 オーバーグルーピングはより深刻な失敗モードと言えます。Sentry がエラーを誤って Issue に統合してしまうと、本来別のワークフローで対処すべき問題が隠されてしまいます。そのエラーは優先度も根本原因も修正方法も異なる可能性があります。 いかに判断を誤りやすいかを示す実例として、Sentry のリポジトリにあるスタックトレースがほぼ同一でありながら、根本原因が異なる 2 […]
自分の環境では動くのに… AIでバグ再現を自動化する方法
Article by: Neel Shah（読了時間：4分） Sentry の SDK チームは、幅広い言語とフレームワークのエコシステムにわたって SDK を開発・サポートしています。公開パッケージの正確な一覧はリリースレジストリをご覧ください。現在、エコシステム全体で 159 のパッケージを公開しています。あなたが使っているものも、Sentry がサポートしているものかもしれません。 これらの SDK はすべてオープンソースであり、それぞれ独自の GitHub リポジトリ（JavaScript 版はこちら）として日々メンテナンスしています。そしてどのオープンソースプロジェクトとも同様に、大量のバグ報告や Issue が寄せられます。 この記事では、再現フローをスムーズにしてトリアージの時間と疲労を軽減するために活用してきた Claude スキルについてお話しします。 バグのトリアージフロー null チェックの漏れ、条件分岐の見落とし、その他の小さなミスなど、修正が簡単なバグもあります。 しかし、そうではないバグも多く存在します。理由はさまざまです。 環境を整えるだけでも面倒な「ボイラープレート」 難解なコードパス レガシーバージョン 誰も想定しなかったエッジケースの組み合わせ データ競合などの並行処理の問題 異なる契約を持つフォーク済みライブラリ ボイラープレート 特に SDK のバグでは、ボイラープレートコードが多いことが大きな負担です。 最近の例を見てみましょう。このバグを再現するには、以下のセットアップが必要です。 正しいバージョンの Python venv 正しいバージョンの Django ボイラープレートアプリ 正しいバージョンの Sentry SDK HTTPS プロキシ限定の問題を再現・確認できる […]
エージェントは「見えていないもの」は修正できない
Article by: Sergiy Dybskiy （了読時間：5分） エージェントはバグ修正がどんどん得意になっています。ヘッドレスブラウザ、サンドボックス、シミュレーターといった仕組みのおかげで、自分の作業をテストする能力も向上しています。 しかし、本番環境に出荷した瞬間に混入してくるさまざまなブラウザ、言語、拡張機能、通信速度、その他の変数が絡み合って初めて現れるバグはどうでしょうか。あるいは、想定外の操作をする「人間ならではの行動」によって発生するバグは。 自己修復ソフトウェアのボトルネックは、エージェントの知能ではありません。エージェントが「実際に何が壊れたのか」をまったく把握できていないことです。エージェントはソースコードだけを手がかりにデバッグしており、これはREADMEを流し読みしてサーバー障害を診断しようとするのと同じくらい効果がありません。足りないのは、本番コンテキスト、つまりスタックトレース、リクエストのペイロード、実行環境、そして障害に至るまでの一連の出来事です。 エージェントには、本番環境で何が壊れているかを伝え、かつ「なぜ壊れたのか」を理解するために必要なコンテキストを渡す、何らかの仕組みが必要です。 私たちは、そのコンテキストを人間にも、そして人間と同様にますます重要な存在となっているエージェントにも提供するために、Sentry MCP と Sentry CLI を構築しました。今日からでも、「Sentryアラートがエージェントをトリガーし、エージェントが人間と同じ証拠を使って問題を調査し、修正を含むドラフトPRがブラウザを開く前にリポジトリに届く」というシステムを構築できます。 なぜ自動マージではなくドラフトPRなのか 現実的に何が可能かについて、正直に述べます。人間の関与なしに、自らパッチを検出・修正・テスト・デプロイ・監視まで完結させるシステムを今、構築すべきではありません。それは非常に刺激的なインシデントレビューを生むことになります。 有用なのはもっと控えめなものです。本番エラーが発生したら、エージェントが実際のSentryコンテキストを使って調査し、リグレッションテスト付きの小さな修正を書き、ドラフトPRを開く、というものです。人間が必ず確認するステップが残ります。 完全な自律化ではありませんが、意義のある変化です。多くのバグはキューの中で、トリアージされ、優先度付けされ、アサインされ、待機したまま、新機能に押しつぶされています。Seer は2分以内に根本原因を診断し、根本原因分析からPRのオープンまでを含む Autofix の完全な実行は、約6分で完了します。 たとえ最後のマージを人間が行うとしても、エラー発生から6分で修正PRが届く体制は、平均修復時間に確かなインパクトをもたらします。 エージェントに本番コンテキストを渡す2つの方法 Sentry MCP は、Model Context Protocolをサポートするエージェント（Claude Code、Cursor、Codex、Windsurf、VS Code with Copilot）に適した選択肢です。エージェントがホスト型サーバーに接続し、OAuthで認証すると、Issues、イベント、トレース、Seer分析への構造化されたアクセスが得られます。ローカルインストールは不要です。 ワンライナーに対応していないクライアントの場合は、設定を手動で追加してください。 Sentry CLI は、スクリプトによるワークフロー、CIパイプライン、あるいはjqにパイプしたり別のプロセスに渡したりするための構造化された出力が必要な自動化処理に適した選択肢です。 実際の動作例は次のとおりです。 CHECKOUT-P1 がトップに表示されています。チェックアウトサービスでのタイムアウトで、1.8kのイベントと86%の修正可能性スコアを持っています。詳細を確認してみましょう。 […]
【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 が含まれます。これはルートトランザクションに対してのみ実行されます。 つまり、ヘッドベースサンプリングでは、親トランザクションとは別に […]
【AIエージェントのオブザーバビリティ】エージェント監視 開発者ガイド
Article by: Sergiy Dybskiy 「エージェントのオブザーバビリティのベストプラクティス」を謳うコンテンツのほとんどは、2019年のコンプライアンスチェックリストの「マイクロサービス」という部分を「AI」と貼り替えただけのようなものです。「包括的なロギングを実装する」「評価メトリクスを確立する」「ガバナンスフレームワークを構築する」など、コードは一行も出てこず、エージェントが3ターン目にこっそり間違ったツールを選んでしまったとき、なぜそうなったかを突き止める方法にも一切触れていません。 エージェント監視に必要なものは2つです。すべてのエージェントで何が起きているかを示すダッシュボードと、特定の実行でなぜ問題が起きたかを正確に示すトレース。ほとんどのツールはどちらか一方しか提供しません。両方を持っている場合どうなるか、見ていきましょう。 エージェントのオブザーバビリティとは何か エージェントのオブザーバビリティとは、AIエージェントの動作をエンドツーエンドで可視化することです。どのモデルを呼び出しているか、どのツールを実行しているか、各ステップでどんな意思決定をしているか、そしてその決定が最終的な出力にどう影響しているかを把握できます。 従来のアプリケーション監視はリクエスト、エラー、レイテンシを追跡します。各リクエストが独立したステートレスなHTTPサービスではそれで十分です。 しかしAIエージェントは異なります。単一のエージェント実行には、複数のLLM呼び出し、ツールの実行、サブエージェントへのハンドオフ、マルチターンの推論ループが含まれることがあり、これらすべてが互いに依存し合っています。出力が誤っていた場合、その連鎖のどこかに失敗が潜んでいる可能性があります。ツールからの不正なレスポンス、コンテキストウィンドウのオーバーフロー、モデルによる間違った関数の選択、ハンドオフでのステート消失など、原因はさまざまです。 従来の監視がAIエージェントで機能しない理由 標準的なAPMツールは「POST /api/chat が4.2秒で200を返した」とは教えてくれます。しかし、そのリクエストの中でエージェントが5回LLMを呼び出し、3回目に間違ったツールを選択し、そのツールが古いデータを返し、モデルがそのゴミを律儀に要約したというようなことは教えてくれません。 「とにかく全部ログに残して後で考える」という監視方針であれば、カウントと平均値で埋まったダッシュボードができ上がるだけで、深く掘り下げる手段はありません。間違った答えを返したエージェントは、12回LLMを呼び出し、4つのツールを実行し、サブエージェントにハンドオフしてからゴミを生成していたかもしれません。集計メトリクスはエラーレートが上がったことは教えてくれても、推論のどこでおかしくなったかは教えてくれないのです。 必要なのは、標準的な規約に基づいて設計された構造化トレースです。ダッシュボード、トレース、アラートがすべて同じ言語で話せるようになります。 エージェントオブザーバビリティのOpenTelemetry標準 OpenTelemetryの gen_ai セマンティック規約は、AIエージェントシステムのインストゥルメンテーション標準を定義しています。カスタムロギングの代わりに、すべてのAI操作が一貫した属性セットを持つ構造化スパンを生成します。規約で定義されたコアオペレーションは以下の通りです。 スパンオペレーション 何をキャプチャするか gen_ai.request 単一のLLM呼び出し：モデル、プロンプト、レスポンス、トークン数 gen_ai.invoke_agent エージェント実行のフルライフサイクル：タスクから最終出力まで gen_ai.execute_tool ツール/関数呼び出し：名前、入力、出力、実行時間 これらはスパンツリーとして構成されます。 これはプロプライエタリな仕様ではなく、オープン標準です。この規約に従うオブザーバビリティプラットフォームであれば、どれでもこれらのスパンを取り込むことができます。スパンのopは gen_ai.{operation_name} というパターンに従います。手動インストルメンテーションの場合、gen_ai.request がすべてのLLM呼び出しをカバーします。SDKによる自動インストルメンテーションでは、呼び出されるAPIに応じて gen_ai.chat や gen_ai.embeddings といったより具体的なopが生成されることもあります。これらは非構造化ログではなく構造化スパンであるため、ダッシュボードとトレースビューの両方を活用できます。 AIエージェント監視の主要メトリクス ツールの話に入る前に、本番環境のAIエージェントで追跡すべき指標を整理しておきましょう。 信頼性メトリクス エージェントエラー率 — 失敗またはエラーを返したエージェント実行の割合 ツール失敗率 […]
【SeerがSeerを修正】Seerがバグの場所を示し、障害の修復に役立った方法
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を追加することでした。これをデプロイしてから数分以内に、失敗率はベースラインに戻りました。 コードの問題 […]
AI時代における Fair Source Software
Article by: Chad Whitacre, Gavin Zee 最近、AIの存在を感じていますか？ええ、もちろん私たちもです。生成AIはソフトウェアの既存の前提を揺るがしており、それはライセンスにも及びます。そして当然ながら、さまざまな「意見」を生み出しています。 Sentry はソフトウェアライセンスについて長い間、明確な考えを持ってきました。2008年には無ライセンスのサイドプロジェクトとして始まり、その後 BSD、BSL へと移行し、独自ライセンスである FSL を策定しました。 そして直近では2024年、私たちは Fair Source を立ち上げました。これはソース公開型ライセンス（ FSL を含む）の中で「シンプルな非競争条項」と「最終的なオープンソース化」を両立させる、新しい業界ポジションを確立するためのものです。Fair Source の採用は現在拡大しています。 では、AIによって何が起きているのでしょうか。そしてソフトウェアライセンスにはどのような影響があるのでしょうか。特に Fair Source は今でも意図通りに機能しているのでしょうか。また企業にとって安全な選択肢であり続けているのでしょうか。 結論から言えば「はい」なのですが、詳しくご紹介いたします。 新しいAIの転換点 Andrej Karpathy の言葉を借りれば、この変化は「通常の進歩のように徐々に起きたのではなく、まさに昨年12月に起きた」ものです。 2025年の最新世代AIモデル（11月24日の Opus 4.5、12月11日の Codex 5.2）は、初めて「単体のエージェントとして依存可能なレベル」に到達しました。 これにより、VS Code や Cursor のような従来の IDE 内での高度なオートコンプリートではなく、Claude Code や OpenCode のような環境で独立したエージェントとして動作することが可能になりました。 さらに、オープンソースのAIパーソナルアシスタントである OpenClaw が爆発的に普及しました。これは「vibe-coding（コードを読まずに出荷する）」の現実性と、「コードを書く以上のことをエージェントに求める需要」の両方を示しています。 リリースからわずか3ヶ月で、OpenClaw は […]