【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 server に、これらの情報を簡単に問い合わせるためのツールと、Seer の Issue Fix 機能を呼び出すためのツールを組み込みました。ウィンドウ間でエラーログをやりくりするより、使うのはずっと簡単です。Cursor の設定で数回クリックするだけで、リアルタイムの本番データをコピー＆ペーストなしでエディタに直接取り込むことができます。

設定を保存すると、そのまま OAuth による認証を求める画面が表示されるはずです。

クリックして Sentry アカウントで認証すれば完了です。

MCP の設定が完了

すべてが機能していることを確認するには、新しいチャットを開いて次の操作を試してください。

 

Cursor が find_organizations ツールを呼び出し、あなたの Sentry 組織を返すはずです。認証エラーが出る場合は、Sentry アカウントに適切な権限が付与されているか、そして OAuth が正常に完了しているかを再確認してください。

 

Cursor で Sentry の本番データを扱う

これで、Cursor から本番データに直接話しかけられるようになりました。まずはシンプルに始めましょう。

 

Cursor での Sentry MCP による最近の Issue

 

Cursor は裏側で 3 つの MCP ツールを呼び出しています。アカウントを見つけるための find_organizations、適切なプロジェクトを見つけるための find_projects、そして実際のエラーデータを取得するための search_issues です。最新の Issue は、説明、原因箇所、タイムスタンプ、Sentry への直接リンクを含んだ形でチャットに表示されます。

search_issues の自然言語インターフェースのおかげで、Sentry のクエリ構文を覚えておく必要はありません。たとえば、特定の期間を指定したり、ユーザー影響度で並べ替えたり、エラー種別でフィルタしたりできます。

例えば以下です。

または

 

ユーザー影響度で並べ替えた Issue

 

各 Issue は、該当ファイルと行番号を示すスタックトレース、ユーザー影響の指標、エラー頻度、そして Sentry の画面で見られるのと同じ完全なコンテクスト付きで返されます。違いは、それらのデータが「修正作業をしている開発環境の中」にそのまま出てくることです。

 

 

高度な Sentry MCP クエリ

基本的なクエリに慣れてきたら、より踏み込んだ使い方もできます。Sentry のクエリ構文は複雑なフィルタリングに対応していますが、MCP インターフェースなら、正確な演算子を覚える代わりに自然言語で指定できます。

時間ベースのフィルタは直感的に動きます。

 

ユーザー影響の分析は、優先順位付けに役立ちます。

MCP ツールは、これらの自然言語クエリを適切なフィルタリング、ソート、ページネーションを伴う正しい Sentry API 呼び出しへ変換します。

実運用における Sentry MCP エラーハンドリング

Sentry MCP のコンテクストで実際の問題をデバッグする

実際の問題をデバッグしてみましょう。

本番環境で SyntaxError が発生した場合です。

 

Syntax Error ログ

 

Sentry MCP の get_issue_details ツールは、正確な発生箇所（./app/dashboard/weather-widget.tsx:60:41）を特定し、スタックトレース全体も表示します。原因は、weather insights API が JSON を返していなかったのに、コード側がそれでも response.json() を呼び出していたことでした。

Cursor はこのエラーコンテクストを使って、より堅牢なエラーハンドリングを提案します。具体的には、Content-Type の確認、200 以外のレスポンスの扱い、意味のあるエラーメッセージの提示といった対応です。

 

この新しいエラーハンドリングにより、リクエストは穏当な形で失敗し、エラーメッセージにもより多くの情報を含められるようになります。

この SyntaxError のようなピンポイントなデバッグこそ、Sentry MCP と Cursor が最も相性よく機能する領域です。スタックトレースが明確な単一ファイルの問題であれば、素早く対処できます。本番のコンテクストが IDE に直接届き、Cursor はエラーパターンを理解し、エディタから離れずに問題を解決できます。

 

足りなかったコンテクスト

Cursor はエラーハンドリングの実装自体はうまくやりましたが、その解決策は「修正」とは呼べません。私たちは意図的に作ったエラーで Cursor を評価するためにこのテストを用意しました。実際の問題は、呼び出している API ルートがそもそも存在しないことです。

Cursor はファイル内の問題にはうまく対応できた一方で、エラーとプロジェクト構造との関係を認識できませんでした。しかし Seer は本当のエラーを検知しました。

 

Seer の Root Cause UI で成功

 

次は、Cursor の限界と Seer の能力について、もう少し深掘りしていきます。ただその前に、自分の環境で試してみたい方は、Seer の 14 日間無料トライアルを使うのも良いかもしれません。Issue の詳細ページにある Find Root Cause ボタンをクリックすれば利用できます。

 

Sentry UI で Seer を起動

Cursor の限界

次は、Cursor がより複雑な問題をどう扱うかを試します。たとえば、メモリリークが引き金になって、別々のコンポーネントにまたがる関連エラーが連鎖的に発生している状況を考えてみましょう。

同じデバッグ手順を試してみてください。

Cursor は Sentry MCP を使って activity-chart.tsx 内のエラー箇所を特定し、そのうえで制限（limit）とクリーンアップロジックを追加する修正案を提示します。

ただし、他の類似するエラーについても聞いてみると、Cursor は単一ファイル思考のまま抜け出せません。1 つのファイルを見てピンポイントの修正を当て、次の似ているエラーに移って、また同じことを繰り返します。Cursor にできないのは、一歩引いて「なぜまったく別のコンポーネントでメモリリークやオーバーフローのエラーが起きているのか。ここには体系的な問題があるのでは？」と問うことです。

アプリケーション全体に広がっていたメモリリークの原因は、複数の React コンポーネントで useEffect のクリーンアップ関数が欠けていたことでした。各コンポーネントに必要だったのは、同じ基本パターンです。

アプリケーションの別の箇所でも似たオーバーフローエラーが出ているのに、Cursor はそれぞれを別問題として扱ってしまい、提案も根本原因の修正ではなく「制限を増やす」方向に偏る傾向があります。

Cursor を擁護するなら、これは Cursor が得意とする領域そのものでもあります。つまり、狙いを定めた調査と、局所的な修正です。ですが、体系的な問題には、より深い分析が必要になります。

根本原因分析のために Seer へエスカレーションする

同じ問題に対して Seer がどうアプローチするかを見てみましょう。作業場所は引き続き IDE の中です。

Seer に助けを求めると begin_seer_issue_fix ツールが起動し、数分後に修正のステータスを確認できると案内されます。

その修正の状況を確認します。

 

Cursor での Seer 修正ステータス

begin_seer_issue_fix ツールは、まったく別の分析プロセスを開始します。

Seer は Issue の履歴全体にまたがるパターンを分析し、エラーがデプロイとどう相関しているかを調べ、システム内の異なる部分同士の関係を理解し、複数のファイルやリポジトリにまたがる根本原因を特定します。

ここでは Seer が複数のリソースに適切なクリーンアップが必要だと突き止めました。タイマー、イベントリスナー、オブザーバー、そしてバックグラウンド処理です。

Cursor と Seer では、アプローチの違いがはっきり表れます。今回の例では、Cursor は人工的な制約を追加してエラーを「覆い隠す」だけでしたが、Seer はコードにおけるリソース管理の不備に気づき、問題そのものを未然に防ぐための解決策を提案しました。

Seer の強みは、このコンポーネントだけに閉じない分析にあります。Sentry のエラーシーケンスデータを使うことで、エラーが時間の中でどのように相関しているかを理解し、どのエラーが別のエラーに先行して発生しているかを特定し、Issue をまたいだ因果関係を明らかにすることができます。

適材適所のツール選び

ここでは、ツールを 3 つのレイヤーとして捉えると分かりやすいです。

Cursor

Cursor 単体は、新しいコードを書くときや、何をどう直すべきかが明確な場合の構文エラー修正に向いています。単純な開発タスクなら、速くて手早く進められます。

Cursor + Sentry MCP

Sentry MCP と組み合わせた Cursor は、特定の本番障害を調査するときに力を発揮します。正確なエラー位置、スタックトレース、ユーザー影響データが手に入ります。問題箇所を特定して狙い撃ちでデバッグしたいときに最適です。

Seer

Sentry MCP と Seer を併用した Cursor は、システム全体を対象にした包括的な根本原因分析を担います。パターンやアーキテクチャ上の問題、複数ファイルにまたがる不具合が疑われる場合に、この深い分析を持ち込めます。

コンテクストを自分の手に取り戻す

一般的な AI 支援と強力なデバッグワークフローの違いは、突き詰めるとコンテクストです。Cursor 単体でも、コードの作成や構文エラーの修正はできますが、Sentry MCP のコンテクストが加わると、実際の本番障害を調査し、ユーザー影響を把握し、エラーをコードの特定行まで辿ることができます。さらに Seer を加えれば、システムアーキテクチャ全体にまたがる包括的な根本原因分析が可能になります。

コンテクストのレイヤーが 1 つ増えるごとに、できることが変わります。本番のエラーデータは曖昧な不具合報告を精密なスタックトレースへ変え、Issue の相関は、人手では数時間かかるパターン特定を可視化します。そしてリポジトリを横断した分析は、単一ファイルの調査では見落としてしまう体系的な問題を掘り起こします。

コンテクストこそが、一般的な AI 支援を「本当に役に立つデバッグワークフロー」に変えます。ツールに実際の本番環境へのアクセスを与えれば、どれだけ有用性が増すかが分かるはずです。

Original Page: Smarter debugging with Sentry MCP and Cursor

IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。導入に関するご相談がございましたら、どうぞお気軽にお問い合わせください。