Zenn
🔍

CursorにSentryのMCPサーバーを連携してIssueをサクッと調査する検証例

に公開
6
AI
Sentry
Model Context Protocol
Cursor
debugging
tech

マナリンクCTOの名人です。
今回は、CursorにSentryのMCPサーバーを連携してIssueをサクッと調査する検証例について紹介します。

はじめに

エラー監視ツールとして広く使われているSentryですが、エラーが発生した際の原因調査は時に手間がかかります。特に、コードベースが大きくなってくると、エラーの原因を特定するために多くのファイルを調査する必要があります。

そこで今回は、Cursor IDEのMCP（Model Context Protocol）サーバーを使って、Sentryのエラーを効率的に調査する方法を紹介します。MCPサーバーを使うことで、AIにコードベースを調査させ、エラーの原因を特定することができます。

MCPとは何か

MCPとは「Model Context Protocol」の略で、AIモデルが外部ツールやAPIと連携するためのプロトコルです。Cursorでは、このMCPを使って様々なサービスと連携することができます。

今回使用するのは、Sentryのエラー情報を取得するためのMCPサーバーです。このサーバーを使うことで、CursorからSentryのIssueを直接参照し、関連するコードを調査することができます。

環境準備

必要なもの

  • Cursor IDE
  • Sentryアカウントとプロジェクト
  • Sentry MCPサーバー

Sentry MCPサーバーの設定

今回は、Sentryのエンジニアが開発・公開しているMCPサーバーを利用します。このリポジトリはStarが少ないですが、作者のXアカウントを確認し、ローカルにコードをPullして内容を確認した上で使用しました。実務でSentryを使う場合は、セキュリティの観点からローカルにコードをPullしてから利用することをお勧めします。

CursorのSettingsからMCPサーバーを設定します。

設定が完了すると、CursorにMCPサーバーが表示されます。今回の例では「mcp-sentry-test-maker」という名前で表示しておきました。

実際の調査例

それでは、実際にSentryで報告されたIssueを調査してみましょう。今回は個人開発している テストメーカー というサービスで検証しました。あくまで検証目的の利用であることをご了承ください。

Step 1: Issueの特定

まず、SentryからIssueのURLを取得します。今回は以下のようなURLを例として使用します（秘匿情報のため一部伏せています）：

https://example.sentry.io/issues/123456789/?project=9876543&query=&stream_index=10

Step 2: CursorでIssueを調査

Cursorを開き、MCPサーバーを使ってIssueを調査します。以下のようにプロンプトを入力します：

Sentryで報告されている以下のIssueの原因を特定し、ソースコードは修正せずに原因を案内せよ
@https://example.sentry.io/issues/123456789/?project=9876543&query=&stream_index=10

驚くべきことに、このシンプルなプロンプトだけで十分なのです！複雑な指示や詳細な説明は必要ありません。MCPサーバーがSentryからデータを取得し、AIがコードベースを調査するために必要な情報はすべてこの短いプロンプトに含まれています。これこそがMCPの強みであり、専門的なツールとAIを組み合わせることで、最小限の指示で最大限の効果を得ることができるのです。

Step 3: AIによる調査

プロンプトを送信すると、MCPサーバーがSentryからIssueの情報を取得し、AIがコードベースを調査します。

調査の過程では、以下のようなツールが使用されます：

  1. get_sentry_issue: Sentryからエラー情報を取得
  2. list_issue_events: エラーに関連するイベントを一覧表示
  3. get_sentry_event: 特定のイベントの詳細を取得
  4. コードベース検索: エラーに関連するコードを検索

調査結果の例

今回の例では、「Error: authAPI failed: Request failed with status code 401」というエラーが発生していました。AIによる調査の結果、以下のような原因が特定されました。

【AIからのレスポンス開始】

問題の概要

Sentryで報告されているエラー「Error: authAPI failed: Request failed with status code 401」は、ユーザーが試験に回答した後、その回答をサーバーに保存しようとした際に発生しています。

原因

コードを分析した結果、以下の原因が特定できました：

  1. 認証の問題:

    • ステータスコード401は「Unauthorized（未認証）」を意味します。
    • ユーザーが認証されていても、APIサーバー側での認証セッションが無効になっている可能性があります。

  2. エラーハンドリングの実装:

    • TestAnswer.tsxのsubmitTest関数内では、ユーザーがログインしている場合、認証付きAPIを使用して回答を保存しようとします。
    • このAPI呼び出しが401エラーで失敗した場合、コードはcatchブロックで別のAPIにフォールバックしようとします。
    • しかし、test.enableAnonymousSaveがfalseの場合、このフォールバックは実行されません。

  3. クッキーベースの認証:

    • apiClient.tsではaxios.defaults.withCredentials = trueが設定されており、APIリクエストにクッキーが含まれることを示しています。
    • クッキーが期限切れになっているか、無効になっている可能性があります。

発生パターン

このエラーは以下のような状況で発生する可能性があります：

  1. ユーザーが認証されているが、APIサーバー側のセッションが期限切れになっている
  2. ブラウザのクッキーが削除されたか破損している
  3. ユーザーが長時間アクティブでなかった後に試験に回答しようとした
  4. 異なるデバイスやブラウザでログインした後、元のセッションが無効になった

重要な点

このエラーは実際のところ、コードに問題があるわけではありません。コードは意図的に設計されており、認証エラー（401）が発生した場合、test.enableAnonymousSaveがtrueであれば匿名APIを使用してフォールバックします。

しかし、test.enableAnonymousSaveがfalseの場合、フォールバックは行われず、エラーが発生します。これは設計上の選択であり、バグではありません。

解決策（ソースコード修正なし）

ソースコードを修正せずに対応する方法としては、以下が考えられます：

  1. ユーザーへの通知改善:

    • 現在のコードでは、エラーが発生した場合、「回答結果の提出に失敗しました。再度回答いただくか、出題者に連絡してください」というメッセージが表示されます。
    • このメッセージは適切であり、ユーザーに問題を通知し、取るべきアクションを示しています。

  2. ユーザー教育:

    • ユーザーに長時間の不活動後にはセッションが期限切れになる可能性があることを通知する
    • 重要な試験を受ける前に再ログインすることを推奨する

  3. モニタリング:

    • このエラーの発生頻度を監視し、特定のパターンがあるかどうかを確認する
    • 特定のユーザーやブラウザで頻繁に発生する場合は、より詳細な調査が必要かもしれません

このエラーは認証の仕組み上、完全に排除することは難しいですが、上記の対策によって影響を最小限に抑えることができます。

【AIからのレスポンス終了】

こういったレスポンスがCursorのChat上に数分後には表示されています。今後、もうちょっと複雑なIssueなどでも調査したり、場合によっては初期対応まで進めたいです。

MCPサーバーを使った調査のメリット

今回の例では、MCPサーバーを使ってSentryのIssueを調査することで、以下のようなメリットがありました：

  1. 迅速な原因特定: AIがコードベースを素早く検索し、関連するコードを特定することで、調査時間を大幅に短縮できました。
  2. コンテキスト理解: エラーの発生状況や関連するコードの流れを包括的に理解することができました。
  3. 解決策の提案: 原因特定だけでなく、解決策も提案してくれるため、対応の方向性を決めやすくなりました。

もちろん、これらの調査は自分でも行うことができます。大半のエラーは調べれば原因がわかるものです。しかし、MCPサーバーを使うことの本当の価値は、認知負荷の軽減にあります。エラー調査という面倒な作業に自分の認知リソースを取られないことで、より創造的な作業に集中できるようになります。

特に個人開発では、面倒なことを後回しにしてしまいがちです。Sentryのようなエラー監視ツールを導入しても、実際にエラーが発生したときに調査する時間や労力がネックとなり、放置されてしまうことがあります。MCPサーバーを使えば、「とりあえずAIに調査させてみよう」という低い心理的ハードルで対応を始められます。

また、実務においても大きなメリットがあります。AIが調査結果からDraft PRまで作成できれば、CI/CDとの連携も視野に入ってきます。例えば：

  1. Sentryで新しいIssueが検出される
  2. MCPサーバーを使ってAIがコードを調査
  3. 修正案を含むDraft PRを自動生成
  4. 自動テストを実行して修正の妥当性を検証
  5. 開発者はレビューのみを行う

このようなワークフローが実現すれば、Issue解決のプロセスが大幅に効率化されます。

Sentryのような運用系の仕組みは、「やってもやらなくてもいいもの」として後回しにされがちです。しかし、こういった領域こそ、現在のAIが最も活躍できる場所ではないでしょうか。定型的だが重要な作業をAIに任せることで、開発者はより価値の高い創造的な作業に集中できるようになります。

まとめ

CursorのMCPサーバーを使ってSentryのIssueを調査する方法を紹介しました。この方法を使うことで、エラーの原因特定が効率化され、開発チームの負担を軽減することができます。

今回は非常に簡単な例でしたが、実際の運用ではより複雑なケースでも活用できるでしょう。実際に運用してみた結果については、別の記事で書きたいと思います。

現在はCursorがMCPランナーとしてはメジャーですが、将来的にはSentryで新規Issueが出たら、それをフックにCI上でコード生成が動作して、Draft PRを生成する時代がすぐに来そうです。

Sentry AIが公式が提供する機能としてその世界線に近いですが、Sentry以外のツールも駆使している開発時には、自分たちが使い慣れているAgentにMCPを統合するほうがいいケースもあるかもしれません。

皆さんもぜひ、CursorのMCPサーバーを活用して、効率的なデバッグを試してみてください。

本記事はCursorでZenn記事のリポジトリを開いたうえで、調査結果の概要をMarkdown形式でAgentに投げて、大半の文章を生成することで執筆しました。主張や検証内容は私の意図通りですが、細かい文章やアウトラインはAI生成によるものです🧠

6

Discussion

ログインするとコメントできます