エージェントは「見えていないもの」は修正できない
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 が含まれます。これはルートトランザクションに対してのみ実行されます。 つまり、ヘッドベースサンプリングでは、親トランザクションとは別に […]
【Sentry MCP ＆ Cursor】デバッグをもっとスマートに
Article by: Cody De Arkland 本番の障害を Cursor でデバッグしていますか？ おそらくワークフローはこうです。Alt-Tab で Sentry に切り替え、エラーの詳細をコピーし、IDE に戻って Cursor に貼り付ける。コンテクストスイッチを 3 回もした頃にはフローは途切れ、実際の本番環境やコードベースを理解しているとは言えない… 一般的な提案を眺めることになります。 Cursor と LLM は良いコードを書けますが、本番のエラー、ユーザーの操作フロー、影響指標、デプロイ履歴、さらにはアーキテクチャのことも知りません。そのコンテクストがあるかどうかで、「パターンマッチングと一般的なエラーハンドリングを提案します」と「この API エンドポイントは、隣接するサービスの 1 つにデプロイされた昨日のコミット以降、ユーザーの 47% で失敗しています」という差が生まれます。 Sentry MCP Server を使えば、Cursor は Sentry が持つ、本番（および開発）アプリケーションのパフォーマンス周辺のコンテクストに直接アクセスできます。エラーメッセージやログをコピー＆ペーストしたり、分散トレーシングの構成やスタックトレースをチャットで説明しようとしたりする必要はありません。MCP は実際の問題を調査し、その影響を理解し、実際の本番コンテクストにもとづいて修正案を提案できます。 ただし、アプリケーションのアーキテクチャの複数領域にまたがるような複雑でシステム全体に及ぶ問題に直面したとき、「AI Debugger」として本領を発揮するのは Sentry の Seer です。Cursor 単体でもピンポイントな修正は得意ですが、MCP Server と併用する場合でも、問い合わせたアプリ性能の各要素を手作業で引き出して自分でつなぎ合わせる必要があります。しかも、MCP の結果が一貫しないこともあります。MCP はまだ完璧には程遠いのです。Seer はプロジェクト全体を横断して、自動的にパターンを見つけ、Sentry のコンテクストに対して深い調査を行い、根本原因の特定と実際に使える解決策の構築に取り組みます。 幸い、私たちは Sentry MCP […]
AIシステムを本番で監視するために本当に必要なこと
Article by: Rahul Chhabria 最新の AI エージェントをプロダクトに組み込み、リリースして、あとは寝るだけ。ところが起きてみると、空文字を返していたり、昨日より 5 秒も遅くなっていたり、あるいは「完璧な JSON」の体裁で堂々と嘘を出していたりしています。 当然、ログを確認します。 プロンプトはある。レスポンスもある。……でも、肝心の手がかりが何もない。 驚きますよね。プロンプト入力とレスポンス出力だけでは、オブザーバビリティとは言えません。あれは雰囲気です。 「LLM のオブザーバビリティ」は今かなり話題です。ただ、実態は「要らないチャート」と「そのうち見なくなるダッシュボード」が増えるだけ、というケースも少なくありません。もしあなたが実際に、チャットボットや社内エージェント、検索・取得アプリなど、LLM を組み込んだプロダクトを作って運用しているなら必要なのは観測です。しかも、肝心なところに差し掛かった瞬間に途切れるような観測ではなく、原因まで辿れる観測です。 何を追うべきか。いつ追うべきか。なぜそれが重要なのか。中身のない補完にうっかり 5,000 ドル払う前に、順番に整理していきましょう。 ステージ 1：本番前 （別名：「プロンプト墓場」） 今、プロトタイプを作っている段階だとします。ノートブック、ベクターストア、OpenAI API キー、そして夢もある。必要なのはダッシュボードではなく、壊れたプロンプトを必死に救い出すためのログです。 何をログに残すべきか この段階でデバッグしているのは、ユーザーというより自分自身です。なので、以下をログに残しましょう。 プロンプト全文とレスポンス全文 モデル名、temperature、function schema のバージョン トークン使用量とレイテンシ プロンプトのバージョンを特定できる情報（何でもいいので） プロンプトのバージョン管理に気の利いた仕組みは要りません。コミットハッシュで十分です。付箋でもいい。とにかく、何が変わったのか忘れる前に書き留めておきましょう。 当面はこれで済むツール類 JSON ファイル Postgres のテーブル 構造化ログを使った Sentry Traceloop（そういうのが好きなら） ここでの唯一の目的は「変な挙動」を再現できるようにすることです。何かが爆発しても、5 分以内に説明できるなら勝ちです。 ステージ 2：本番（Production） （いまや「誰か別の人」の問題） […]
【Sentry Seer】法務審査をクリアする方法 Seer をレビューする法務チーム向けガイド
Article by: Virginia Badenhope （本記事は法律の専門家が法律の専門家のために書いたものですが、法務担当者がいないまま Seer の利用を検討している方にとっても、安心材料になるはずです） 自社の法務部門が私たちと同じような状況にあるのであれば、事業側から「もっと多くの AI ツールを使いたい」というリクエストが次々と押し寄せてきているのではないでしょうか。開発チームは Cursor のようなコーディングエージェントを使いたがり、セキュリティチームは AI を活用した調査を導入し、セールスやマーケティングは通話内容のインサイトや競合調査に AI を活用しようとしています。私たちは各チームが試し、購入しようとしているツールに大きな変化が起きていることを目の当たりにしてきました。 サービスの主な機能自体は AI を前提としていない場合でも、いまやほとんどすべてのサービスが何らかの AI 機能を備えています。 ビジネス側も AI の利用には一定のリスクが伴うことは理解していますが、それでも「使わなければ取り残されてしまう」という強いプレッシャーを感じています。あなた自身も同じプレッシャーを感じつつ、自社のデータや知的財産はもちろん、顧客から預かっているデータや知的財産を守るという使命も負っています。 Sentry が Issue Scan や Issue Fix を含む自社の AI／ML 機能を支えるために開発してきた AI エージェントである Seer について法務レビューを依頼されているのであれば、本記事の目的は、Sentry の法務チームである私たちがサードパーティ製の AI ツールを評価する際に用いている基準を、Seer も同じように満たしていることを示すことにあります。 もし Seer の評価を依頼されたとしたら、私たちは承認します。理由は次のとおりです。 では、法務は実際のところ何を気にしているのか？ 私たちおよび顧客データと知的財産を保護しつつ、ビジネスの変化するニーズを引き続き支えていくために、Sentry では AI ツールの利用について次の要件に合意しています。 […]
AIにもっとデバッグをうまくさせるには？重要なのは「コンテキスト」
Article by: Milin Desai AI を活用したコード生成ツールによって、これまでになく大量のコードが次々とリリースされています。いまは開発者にとっての黄金時代と言っていいでしょう。 しかし、ひとつ重要な事実があります。ソフトウェアは依然として本番環境で壊れてしまいます。Microsoft が最近行った調査によると、AI モデルはソフトウェアのデバッグを苦手としていることがわかりました。その理由は、多くのコード生成ツールで、優れた開発者なら誰もが頼りにしているたった1つのもの、「コンテキスト」が欠けているからです。 何かをデバッグしようとするなら、コンテキストが必要です。AI ツールがあっても、この前提は変わりません。AI は学習データを超えて、実際のエラーやトレースデータ、ブレッドクラム、スタックトレース、コードベース全体、コミット履歴などにアクセスできる必要があります。 AI があるかどうかにかかわらず、デバッグにはコンテキストが欠かせないのです。 AI 時代のデバッグに不可欠なのはコンテキスト Sentry はこの10年あまりの間に、13万以上の組織がソフトウェアの不具合をすばやくデバッグできるよう支援してきました。Sentry 独自のコンテキストを提供することで、エンジニアリングチームが本番環境でのデバッグを従来の 10 倍の速さで行うことができるようにしています。 何かが壊れたとき、開発者は次のようなことを知る必要があります。 問題はいつ発生し始めたのか。 壊れる直前に「何が変わった」のか。 影響を受けているのは 1 人のユーザーか、それとも多数なのか。 どのプラットフォーム／デバイス／リリースに影響しているのか。 問題の起点はどこか。自分のコードなのか、それとも依存している外部要因なのか。 Sentry はこれらの問いに答えるだけでなく、次の情報もあわせて提示します。 どの関数やコード片が失敗しているのかを正確に把握するためのスタックトレース エラーの前後で、アプリケーションがエンドツーエンドでどう振る舞っているかを確認するためのトレースとログ フロントエンドでデバッグしている問題に、バックエンドエラーが関係しているかどうかを確認できるようなトレースでつながった関連 Issue 例外の前後でどのようなアクションが行われたかを把握するための Sentry のブレッドクラム 各関数がどのようなパフォーマンス特性を示しているかをよりよく理解するためのプロファイリングデータ こうしたコンテキストのすべてが、長年にわたって Sentry を開発者にとって非常に有用な存在にしてきました。そしてこれは、障害が発生したときに本当に問題を修正するために、他の AI ツールにも必要でありながら、まだ備わっていないまさにそのコンテキストでもあるのです。 Seer：Sentry の […]
分散システムのトラブルシューティングにトレース参照機能を備えた Sentry AI デバッガー
Article by: Rohan Agarwal デバッグは、すべての開発者にとって常に付きまとう課題であり、たとえAIがコードを書くようになったとしても、その負担が増す可能性さえあります。Sentry のようなツールは、長年にわたりエンジニアが問題を追跡し、デバッグを行う際に支援してきましたが、新たなAIツールを活用することで、こうしたプロセスをさらに迅速かつ容易にできる点が魅力です。 もちろん、Sentry から例外のスタックトレースをコピーして ChatGPT に貼り付けることも可能です。しかし、もし本当に賢いものが欲しいとしたら、どうでしょうか。AI が最善の仕事をするために、より多くのコンテキストを持ち、分散システムを深く理解し、本番環境でそれらをデバッグする能力を備えたものがあればどうでしょうか。 本記事では、私たちがどのようにして、トレーシングの力を活用して、Sentry の本番レベルの AI デバッグアシスタント「Seer」を構築したのかを説明します。 AI によるデバッグの欠点はどこにあるのか？ Seer とその Autofix 機能は、Sentry のIssues 詳細とコードベースとの緊密な統合を活用することで、問題の根本原因を突き止め、修正するための優れたツールとなっています。Autofix は開発者と協働しながら、問題の根本をより深く理解し、効果的な解決策を計画し、さらにはそれを修正するプルリクエストの下書きまで作成します。さらに、リグレッションを防ぐための単体テストも含まれます。これまでのところ、その裏側では主に Sentry のスタックトレースやパンくずリスト、そしてコードベース検索に依存して知見を得ていました。実際、Autofix はすでに数多くの開発者を助けており、さまざまなアプリケーションのバグを修正してきました。 Autofix 自身のバグさえもです。 しかし時には、Autofix が的を外してしまうこともありました。たとえば、フロントエンドから報告された「500 Internal Server Error」に対して Autofix を実行しても、バックエンドでの問題を特定することはできません。あるいは、2つのマイクロサービス間で認証の問題が発生した場合、Seer には実際に何が起きているのか把握できませんでした。さらに、複雑なアプリケーション全般においては、エラーの発生源となっているモジュールがどのように、なぜ利用されているのかについて、ほとんど理解できていませんでした。 ここで登場するのがトレースです。トレースを使うことで、Seer はマルチサービスシステム全体のフロー（フロントエンドとバックエンドといった複数階層を持つソリューションや、さまざまなマイクロサービスを利用するものを含む）、関連するエラー、エラー発生前後に実行された正確な処理（さらにプロファイリングを有効にすれば正確な関数呼び出しまで）を明確に把握できます。これにより Seer は、プロジェクトやリポジトリをまたいだ問題を非常に速く分析し、現実世界でエンジニアが直面する最も複雑な問題の一部を自律的にデバッグできるようになります。それに比べて、チャットボットにコピー＆ペーストするだけでは表面をなぞるに過ぎません。 トレースとは何か？どう活用できるのか？ すでに内容をご理解いただいている場合は、このセクションをスキップしていただいて構いません。そうでない場合は、ここで簡単にご説明します。 トレースとは、アプリケーションおよびその関連サービスを通じてリクエストがどのように流れるかを記録し、データの移動経路や潜在的な問題の発生箇所を可視化する仕組みです。トランザクションやリクエストに関与するイベントのシーケンスを追跡することで、分散システムにおけるパフォーマンスのボトルネック、エラー、依存関係などを特定するのに役立ちます。 トレース内の各ステップは「スパン」と呼ばれ、データベースクエリ、API呼び出し、関数の実行などの作業単位を表します。これらのスパンを組み合わせることで、初期リクエストから最終レスポンスまでの全トランザクションの経路を、包括的に視覚化することができます。トレースは複雑なマイクロサービスアーキテクチャのデバッグおよび最適化において、特に高い価値を発揮します。 Sentry を使えば、トレースを簡単に始められます。アプリに Sentry SDK を追加すると、多くの部分が自動的にインスツルメントされ、後からカスタムのスパンや属性を任意でインスツルメントすることもできます。たとえば Python […]