Article by:
エージェントはバグ修正がどんどん得意になっています。ヘッドレスブラウザ、サンドボックス、シミュレーターといった仕組みのおかげで、自分の作業をテストする能力も向上しています。
しかし、本番環境に出荷した瞬間に混入してくるさまざまなブラウザ、言語、拡張機能、通信速度、その他の変数が絡み合って初めて現れるバグはどうでしょうか。あるいは、想定外の操作をする「人間ならではの行動」によって発生するバグは。
自己修復ソフトウェアのボトルネックは、エージェントの知能ではありません。エージェントが「実際に何が壊れたのか」をまったく把握できていないことです。エージェントはソースコードだけを手がかりにデバッグしており、これは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%の修正可能性スコアを持っています。詳細を確認してみましょう。
一見するとシンプルなタイムアウトです。この情報だけを持つエージェントなら、リトライロジックを追加するかタイムアウト値を引き上げるはずです。しかし、sentry issue explain を実行すると、結果は変わります。
根本原因はチェックアウトサービスの中にはありませんでした。トレースを2つ辿った先にあるインベントリサービスで、データベースインデックスが削除されていたのです。payment.ts にどれだけリトライロジックを加えても、この問題は解決しません。
アラートからドラフトPRまで
Sentryアラートが新規または再発したIssueで発生すると、Webhookがワーカーをトリガーし、リポジトリをチェックアウトしたうえで、特定のIssueに基づいたプロンプトを持つコーディングエージェントを起動します。
エージェントはMCP経由でIssueを取得します。分散トレースは、チェックアウトの呼び出しがペイメントサービスを経由してインベントリチェックへ連鎖し、そこで28秒かかっていることを示しています。メトリクスから、インベントリサービスのp99が3時間前に200msから28sへ急騰したことが確認できます。サスペクトコミットは、acme/inventory-service 内で複合インデックスを削除したマイグレーションを指しています。セッションリプレイには、何も起きない中で「支払い」ボタンを連打するユーザーが写り、決済リクエストが重複して送信されていることも分かります。
sentry issue plan CHECKOUT-P1 は修正内容を示します。(product_id, warehouse_id) に対する複合インデックスを復元することです。ドラフトPRが acme/inventory-service にオープンされ、マイグレーション、Sentryのトレースへのリンクを含む根本原因のまとめ、そしてリグレッションテストが添えられます。
Cursor Automations で試す
この正確なワークフロー向けに、Cursorの Automations 機能を使ったクックブックレシピを公開しています。リポジトリをSentryに接続し、MCPサーバーをオートメーションに追加し、再発Issueでトリガーされるアラート Webhook を設定する手順を説明しています。
Sentryはリリースの履歴とサスペクトコミットを把握しているため、エージェントはリポジトリ全体を検索する必要がなく、証拠が指す場所から調査を開始できます。再発Issueに関しては特に、どのコミットがバグを再導入したかを特定し、元の修正を読み込み、2度目に何が問題だったかを理解することができます。
今後の展開
アプリからSentryに送られるテレメトリ（トレース、メトリクス、ログ、セッションリプレイ）が充実するほど、エージェントが対処できるバグの複雑さも増していきます。6ヶ月前はnullチェックが限界でしたが、今日ではサービス間のインデックス欠落のような複雑な問題にも対応できます。その間にAutofix PRのマージ率は41%から46%へ上昇し、診断できる問題の複雑さも着実に上がっています。
もちろん、現実的な限界もあります。プロダクト判断が必要なバグ、エージェントがアクセスできないコードの問題、点と点をつなぐためのテレメトリが不十分な問題は、依然として人が対処する必要があります。しかし、エージェントが修正できる範囲は毎月拡大しています。
Sentry MCP をエディタに接続する、またはCLI をインストールしてください。コードマッピングとトレースのためにリポジトリを連携させ、バックログに積み上がっている何かに対して sentry issue explain を実行し、何が発見されるか試してみてください。
コーディングエージェントから Claude Code や Cursor へのハンドオフについて詳しくは、Seer Autofix ドキュメントをご参照ください。
Original Page: Your agent can’t fix what it can’t see
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談は「お問い合わせ」からお気軽にお問い合わせください。
