Sentryのアラートから修正PRまで——Claude Code × Sentry MCPで本番エラー対応を変える

はじめに

OpenTelemetryの計装設定の話（observability記事）でも、インシデント後の振り返りの話（postmortem記事）でもない。本番でエラーが起きたその瞬間から、修正PRができるまでをClaude Codeが担う話だ。

本番エラー対応の典型的な流れはこうだ。Sentryからアラートが来る。エラーログをコピーしてターミナルに貼り付ける。コードを読んで原因を探る（30分から数時間）。修正して、テストして、PRを出す。

Sentry MCPとClaude Codeを組み合わせると、このフローの「ログをコピーして貼り付ける」という手作業がなくなる。Claude CodeがSentryに直接アクセスし、エラーの根本原因分析から修正提案まで担えるようになる。

Sentry MCP × Claude Codeの設定と基本ワークフロー

SentryはアプリケーションエラーモニタリングのMCPサーバー（getsentry/sentry-mcp）を公式リリースしている。Claude CodeからSentryのissue・trace・span・Seer分析に直接アクセスできる。

設定はCLI一行から始まる。

claude mcp add sentry

設定後、Claude Code内で `/mcp` コマンドから認証を行う。read-onlyアクセスで、SentryのデータをClaude Codeが読める状態になる。Sentryへのissue作成・削除はMCPからは行えない（2026年4月時点）。

エラー対応のワークフローはこう変わる。

1. Sentryでエラー検知（本番環境）
   ↓
2. Claude Codeに「最新の重大エラーを確認してPRを作って」と依頼
   ↓
3. Claude CodeがSentry MCPでissue一覧を取得
   ↓
4. SentryのAI機能「Seer」の根本原因分析を読んでコードベースの該当箇所を特定
   ↓
5. 修正コードを生成 → テスト → PR作成

SentryのSeerは本番エラーの根本原因分析と修正提案を生成するAIデバッグ機能だ。Claude CodeはこのSeer分析を読み取り、実際のコードベースと照合して修正を実装する。Sentryが「何が問題か」を分析し、Claude Codeが「どう直すか」を実装する役割分担になる。

ただし、自動生成された修正コードは根本原因の分析精度が100%ではない。マージ前のコードレビューは必須だ。また、SentryのエラーデータにPII（個人情報）が含まれていないかを確認してからClaude Codeに渡すことも必要だ。

週次パフォーマンストリアージの自動化——先手型の品質管理

Sentryの公式レシピサイト（sentry.io/cookbook）に「Automate weekly performance triage with Claude Code + Sentry MCP」が公開されている。毎週月曜9AMにCronジョブを設定して、以下を自動実行するパターンだ。

毎週月曜9AMにSentryのワースト5パフォーマンス問題を取得
→ 根本原因分析
→ 修正提案付きのGitHub PRsを自動作成

ユーザーが問題を報告する前に、チームが先手を打てる体制だ。「エラーが来たから対応する」後手型から「問題が深刻になる前に修正する」先手型への移行が実現できる。

複数のissueを並列分析するエージェントパターンも活用できる。エラータイプをまたいだパターン検出、根本原因の調査と実行可能な修正提案、担当者・優先度の自動割り当て提案といった機能を組み合わせることで、週次のエラートリアージを自動化できる。

SentryのAPIをClaude CodeのSkillsとして定義しておくと、`/batch` コマンドで複数の不具合を一度に処理・修正提案する使い方も可能になる。Sentry以外にも、ログ分析・パフォーマンス計測・デプロイ管理など各種開発ツールに同じ「APIレベルで統合する」パターンを応用できる。

CLAUDE.mdで「検知より先に防ぐ」——事前防止策

SentryのMCPは本番エラーの事後対応を効率化するが、CLAUDE.mdへのルール定義は発生前に防ぐ予防的なアプローチだ。コードを変更するたびにClaude Codeがエラー監視の観点から警告を出すように設定できる。

# CLAUDE.md（エラーモニタリングルール）
## Error Monitoring Rules
When writing or reviewing code, always flag:
- Unhandled promise rejections (potential silent failures)
- Missing error boundaries in React components
- Database operations without error handling fallback
- API calls without timeout configuration
- Memory leaks: event listeners without cleanup

## Sentry Integration
- New error types should have Sentry.captureException() instrumentation
- Sensitive data (PII, tokens) must never appear in Sentry payloads

## Error Handling Patterns
When writing async operations, always verify:
- try/catch blocks for external API calls
- Explicit timeout settings for HTTP requests
- Error boundaries in UI components

このCLAUDE.mdで特に効くのがSentryの計装漏れ防止だ。新しいエラータイプを実装したのに `Sentry.captureException()` の計装が抜けているケースは、コーディング段階で発見するのが難しい。CLAUDE.mdに書いておくと、コードを書く段階でClaudeが「この新しいエラータイプにはSentryの計装が必要です」と指摘するようになる。

PIIがSentryペイロードに混入するリスクも、コーディング段階でブロックできる。後から「センシティブなデータがSentryに送られていた」ことを発見するよりずっと安全だ。

段階的な自動化の進め方——EMへの示唆

一気に全自動化を目指すのではなく、段階的に進めることでリスクを管理できる。

`claude mcp add sentry` を設定してClaudeがSentryを把握できる状態を作るところから始める。そこから「修正提案を受け取り、人間が判断して実装する」段階へ移り、慣れてきたら「週次Cronで修正PRを自動作成し、人間がレビューしてマージする」流れに持っていく。

どの段階でも、承認フローを必ず挟む設計が前提だ。自動生成されたPRをレビューなしにマージする運用は避ける。Claude Codeは「正しそうな修正を速く提案する」ツールであり、「正しい修正を保証する」ツールではない。

エラー対応に費やしていた時間が短縮されると、エンジニアの時間配分が変わる。手作業のエラー調査から解放された分を機能開発に使えるようになる。Sentryとの連携は「エラー対応が楽になる」というより「エラー対応に頭を使わなくて済むようになる」という変化だ。

まとめ

`claude mcp add sentry` 一行でClaude CodeがSentryに直接アクセスできるようになる。ここから始めて、実際の使用感を見ながら週次自動化・バッチ処理へと段階を進めていくのが現実的だ。

CLAUDE.mdのエラーモニタリングルールと組み合わせることで、事後対応の効率化と事前防止の両方が揃う。エラーが起きてから動くのではなく、起きにくい状態を作りながら起きたら素早く直す、という体制に変わる。

コメント

タイトルとURLをコピーしました