Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで

「バグが起きたら Sentry が検知し、AI が分析して修正案を出す」— そんなワークフローが現実になっています。

@riku720720（Rikuo）さんのポストは、この流れを端的にまとめています。

「アプリ開発する上でsentryは必須。sentry APIをskillsにすればユーザーのバグとか不具合とか全部分析できる。claudecodeの新機能/batchで一気に改善してもらう」

この記事では、Sentry の全体像から Claude Code との連携、そして実践的なワークフローまでを解説します。

Sentry とは

Sentry は、開発者ファーストのエラートラッキング＆パフォーマンス監視プラットフォームです。100以上のプラットフォーム・フレームワーク、30以上のプログラミング言語に対応しています。

単なるエラーログではない

Sentry が他のログ監視ツールと異なるのは、エラーの文脈（コンテキスト）を自動収集する点です。スタックトレースだけでなく、ユーザーのセッション情報、パフォーマンスデータ、リリースバージョンなど、デバッグに必要な情報を一元化します。

Sentry の主要機能

1. Error Monitoring（エラー監視）

Sentry の中核機能です。

リアルタイム検知：エラー発生を即座にキャッチ
インテリジェントグルーピング：同じ原因のエラーを自動的に1つの Issue にまとめる
アラート通知：Slack、メール、PagerDuty 等と連携

1
2
3
4
5
6
7
8
# Django での導入例
import sentry_sdk

sentry_sdk.init(
    dsn="https://xxx@xxx.ingest.sentry.io/xxx",
    traces_sample_rate=1.0,
    profiles_sample_rate=1.0,
)

2. Performance Monitoring（パフォーマンス監視）

分散トレーシング：リクエストの流れをフロントエンドからバックエンドまで追跡
トランザクション分析：遅いエンドポイントやクエリを特定
Web Vitals：LCP、FID、CLS などフロントエンドのパフォーマンス指標

3. Session Replay（セッションリプレイ）

ユーザーのセッションをビデオのように再生できる機能です。

エラー発生前後のユーザー操作を視覚的に確認
AI によるリプレイサマリーが自動生成される
Web（ブラウザ）、iOS、Android、React Native に対応
パフォーマンスへの影響は最小限に設計

4. Cron Monitoring（定期ジョブ監視）

スケジュールされたジョブ（cron、バッチ処理等）の稼働状況を監視します。

ジョブの実行漏れを検知
タイムアウトの検出
実行時間の異常を通知

5. Uptime Monitoring（稼働監視）

URL に対して1分ごとのヘルスチェックを実行します。

ステータスコード 200 以外でアラート
10秒以上のレスポンスタイムアウトを検出
ダウンタイムの即時通知

6. Profiling（プロファイリング）

プロダクション環境でのコードレベルのパフォーマンス分析です。

関数単位の実行時間を可視化
ボトルネックとなるコード行を特定
本番環境で動作するため、開発環境では再現しない問題も捕捉

なぜ自前実装ではなく Sentry を使うのか

Sentry が提供する機能の多くは、一見すると共通ライブラリとして自前実装できそうに見えます。try-catch でエラーを捕捉し、ログに書き出し、Slack に通知する — これだけなら数百行のコードで書けるでしょう。

しかし、実用レベルのエラー監視に求められるものは、単純なエラーキャプチャの遥か先にあります。

自前実装で「できること」と Sentry との差

機能	自前実装	Sentry
エラーキャプチャ	`try-catch` + ログ出力	SDK が未処理例外・Promise rejection を自動捕捉
スタックトレース	言語標準の出力	ソースマップ対応でミニファイ済みコードも元のソースで表示
エラー集約	ログの文字列マッチング	インテリジェントグルーピング（後述）
コンテキスト	自前で付与する必要あり	ブレッドクラムで操作履歴を自動収集
通知	Slack/メール連携を自作	100以上のインテグレーション済み
パフォーマンス	別途 APM ツールが必要	分散トレーシング・プロファイリング内蔵
セッション再生	実装困難	Session Replay でビデオライクな再生
AI 分析	実装困難	Seer による根本原因分析・自動修正

差が出るポイント1: インテリジェントグルーピング

自前実装で最も困難なのが、同じ原因のエラーを1つにまとめる処理です。

# 同じバグだが、スタックトレースが微妙に異なる例
TypeError: Cannot read property 'id' of undefined
  at UserProfile.render (app.js:1234)      ← ユーザーA
  at UserProfile.render (app.js:1234)      ← ユーザーB（異なるブラウザ）
  at UserProfile.render (app.js:1238)      ← ユーザーC（異なるバージョン）

Sentry はフィンガープリント（fingerprint）というメカニズムで、これらを同一 Issue として自動集約します。

スタックトレース、例外の型、メッセージを組み合わせてフィンガープリントを生成
アプリケーションコードに関連するフレームのみを考慮し、フレームワーク内部のフレームの差異は無視
カスタムフィンガープリントルールで集約ロジックを調整可能

自前でこのロジックを実装・メンテナンスするコストは、想像以上に大きくなります。集約精度が低いと、同じバグが100個の別 Issue として分散し、逆に精度が粗すぎると異なるバグが1つに混ざります。

差が出るポイント2: ブレッドクラム（操作履歴の自動収集）

Sentry SDK は、エラー発生前のユーザー操作を自動的に記録します。

14:23:01  [UI]     ユーザーが「購入」ボタンをクリック
14:23:01  [HTTP]   POST /api/checkout → 200 OK
14:23:02  [HTTP]   GET /api/payment/status → 500 Error
14:23:02  [Console] Error: Payment gateway timeout
14:23:02  ❌ TypeError: Cannot read property 'transactionId' of undefined

従来のログでは「エラーが起きた」という事実しか分かりませんが、ブレッドクラムにより「何をした結果エラーが起きたか」が分かります。SDK がブラウザの console、DOM イベント、fetch/XHR、ナビゲーション履歴を自動的にフックするため、アプリケーションコードの修正なしにこの情報が得られます。

差が出るポイント3: リリーストラッキング

Sentry はエラーとリリースバージョンを自動的に紐づけます。

v2.3.0  ── エラー率 0.1%（安定）
v2.3.1  ── エラー率 2.3% ⚠️ ← このリリースで何か壊れた
v2.3.2  ── エラー率 0.08%（修正済み）

「このバグはどのリリースで入ったか」「このデプロイでエラー率は改善したか」が一目で分かります。CI/CD パイプラインと連携し、ソースマップのアップロードやリリース情報の自動登録が可能です。

差が出るポイント4: 運用負荷

自前実装の最大の隠れコストは継続的な運用です。

項目	自前実装	Sentry（クラウド版）
インフラ	ログ収集・保存・検索基盤を自前で構築・運用	マネージドサービス
スケーラビリティ	トラフィック増加に応じて自前でスケール	自動スケール
SDK メンテナンス	フレームワーク更新への追従を自前で	公式 SDK が対応
新プラットフォーム対応	言語・フレームワークごとに実装	100以上のプラットフォーム対応済み
セキュリティ	PII マスキング等を自前実装	データスクラビング機能内蔵

参考：Sentry をセルフホストする場合、PostgreSQL、Redis、Kafka、ClickHouse、Snuba、Relay、Symbolicator など12以上のコンポーネントが必要で、推奨メモリは 32GB です。これが「エラー監視を真面目にやる」ために必要なアーキテクチャの規模感です。

CloudWatch との違い — インフラ監視 vs アプリケーション監視

AWS を使っている場合、CloudWatch でのエラー監視と比較されることがあります。両者の違いは明確です。

観点	CloudWatch	Sentry
視点	インフラ（CPU、メモリ、ネットワーク）	アプリケーション（例外、パフォーマンス、ユーザー体験）
エラー情報	「過去1時間に ERROR を含むログが47行」	「この TypeError は v2.3.1 で発生し、342ユーザーに影響、チェックアウト画面で発生、原因コードはここ」
セットアップ	IAM ロール + ログ転送設定	SDK を数行追加
AI 分析	なし	Seer による根本原因分析・自動修正

多くの AWS チームでは、CloudWatch（インフラ）+ Sentry（アプリケーション）の併用が推奨されています。両者は競合ではなく補完関係にあります。

結論：「作れる」と「作るべき」は違う

エラーキャプチャの仕組み自体は自前で作れます。しかし、Sentry が提供する価値の本質は以下にあります。

集約ロジック（インテリジェントグルーピング）の品質と継続的改善
コンテキスト自動収集（ブレッドクラム、セッション情報）の網羅性
100以上のプラットフォーム SDK のメンテナンス
AI デバッグエージェント（Seer） による根本原因分析・自動修正
MCP サーバーによる AI コーディングエージェントとの直接連携

特に 4 と 5 は2026年時点で自前実装が極めて困難な領域です。Sentry は「エラーを捕捉するライブラリ」ではなく、エラー検知から修正までのパイプライン全体を提供するプラットフォームとして捉えるべきです。

Seer — Sentry の AI デバッグエージェント

2026年、Sentry は Seer という AI デバッグエージェントを一般提供（GA）しました。

Seer ができること

機能	説明
根本原因分析	Issue の詳細、トレーシングデータ、ログ、プロファイルから原因を特定
自動修正（Autofix）	原因を特定し、修正案を自動で作成。マージは人間の承認が必要
コードレビュー	PR を分析し、本番障害を引き起こしそうな欠陥を検出
ローカル開発連携	MCP サーバー経由でローカルのコーディングエージェントと連携

Autofix の動作フロー

エラー発生
    │
    ▼
Sentry が Issue を作成
    │
    ▼
Seer が自動で根本原因を分析
    │
    ▼
修正案（コード差分）をドラフト
    │
    ▼
開発者が承認 → マージ

Autofix を有効化（Automated Fixes ON）すると、Seer が修正可能と判断した Issue に対して自動的にこのフローが実行されます。マージには必ず人間の承認が必要なため、安全性は確保されています。

2026年1月の拡張

Sentry は2026年1月に Seer の機能を大幅に拡張しました。

ローカル開発への対応：MCP サーバー経由でローカル環境のコーディングエージェントと接続
コードレビュー機能：PR のスタイルではなく、本番で実際に障害を起こすレベルの欠陥に焦点
定額制の導入：利用回数無制限のフラット料金モデル

Sentry × Claude Code 連携

ここからが本題です。Sentry と Claude Code を連携させることで、エラー検知 → 分析 → 修正のループを AI で加速できます。

MCP サーバーによる接続

Sentry は公式の MCP（Model Context Protocol）サーバーを提供しています。

1
2
# Claude Code に Sentry MCP サーバーを追加
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

設定後、Claude Code 内で /mcp コマンドで Sentry アカウントに認証します。インストール不要で、Sentry がホスティング・管理するリモート MCP サーバーに接続する仕組みです。

何ができるようになるか

MCP 接続後、Claude Code から自然言語で Sentry にアクセスできます。

「過去24時間で最も多いエラーは何？」
「この Issue の根本原因を分析して」
「未解決の Issue で影響ユーザーが多い順に並べて」

具体的には以下の操作が可能です。

エラー検索：ファイル・プロジェクト横断でのエラー検索
Issue 詳細調査：スタックトレース、影響範囲、発生頻度の確認
Seer 分析のトリガー：AI による根本原因分析を起動
修正推奨の取得：AI が生成した修正案の確認
パターン検出：複数の Issue に共通するパターンの自動検出

Skills としての活用

ツイート主が提案しているのは、Sentry API を Claude Code の Skills（動的プロンプト）として設定するアプローチです。

Skills を活用すれば、特定のコマンドやトリガーで Sentry の情報を自動的に取得・分析するワークフローを構築できます。Sentry 公式の Skills テンプレートも提供されています。

sentry-code-review：コードレビュー時の Sentry 連携
sentry-setup-ai-monitoring：AI エージェントのモニタリング設定
sentry-setup-logging：ログ設定
sentry-setup-metrics：メトリクス設定
sentry-setup-tracing：トレーシング設定

/batch による一括改善

ツイートで言及されている Claude Code の /batch は、バッチ API を利用した大量タスクの一括処理機能です。

仕組み

Anthropic の Message Batches API を経由してタスクを非同期実行
**コストが通常の50%**で処理可能
ほとんどのバッチは1時間以内に完了

Sentry × /batch の組み合わせ

Sentry の未解決 Issue リストを取得（MCP 経由）
    │
    ▼
各 Issue の分析・修正タスクをバッチとして投入（/batch）
    │
    ▼
Claude Code が並行して分析・修正案を生成
    │
    ▼
開発者がレビュー → 適用

この組み合わせにより、蓄積されたバグや不具合を一気に分析・修正するワークフローが実現します。個々のエラーを手動で調査する必要がなく、コストも半減します。

料金プラン

プラン	月額	エラー数	主な特徴
Developer	無料	5,000/月	1ユーザー、基本機能
Team	$26	50,000/月	無制限ユーザー、サードパーティ連携、Seer（要サブスクリプション）
Business	$80	100,000/月	専任アカウントマネージャー、優先サポート
Enterprise	要問合せ	カスタム	SLA、カスタム契約

全有料プランでプロジェクト数・チームメンバー数は無制限です。使用量が増えるほど単価が下がるボリュームディスカウントモデルを採用しています。年間契約で10%割引。

AI エージェント監視

Sentry は AI エージェントを使うアプリケーション向けの専用監視機能も提供しています。

SDK を導入すると、以下のメトリクスを自動収集します。

エージェント呼び出し回数
ツール実行の成功/失敗
エージェント間のハンドオフ
トークン使用量

AI エージェントを本番運用する際の可観測性として有用です。

実践ワークフロー：Sentry + Claude Code + /batch

最終的な理想のワークフローをまとめます。

1. アプリに Sentry SDK を導入
      │
2. 本番環境でエラー・パフォーマンス問題を自動検知
      │
3. Seer が自動で根本原因を分析・修正案をドラフト
      │
4. Claude Code から MCP 経由で Sentry に接続
      │
5. 未解決 Issue を一覧取得し、優先度を分析
      │
6. /batch で複数 Issue の修正を一括実行
      │
7. 開発者がレビュー → マージ
      │
8. リリース後、Sentry で再発がないことを確認

エラー監視 → AI 分析 → AI 修正 → 人間のレビュー → リリース。このループが回ることで、バグ対応の速度とコスト効率が劇的に改善します。

まとめ

Sentry は単なるエラーログツールではなく、2026年現在では AI デバッグエージェント（Seer）を内蔵した統合監視プラットフォームに進化しています。

要素	役割
Sentry	エラー検知・文脈収集・パフォーマンス監視
Seer	AI による根本原因分析・自動修正・コードレビュー
MCP サーバー	Claude Code からの Sentry 直接アクセス
Skills	Sentry API をワークフローに組み込む
/batch	複数の修正タスクを一括・低コストで実行

アプリ開発において「エラーが起きてから対応する」のではなく、「エラーを検知した瞬間に AI が分析を始め、修正案まで出す」体制を構築できる。Sentry × Claude Code は、その現実的な第一歩です。

参考リンク:

Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで#

Sentry とは#

単なるエラーログではない#

Sentry の主要機能#

1. Error Monitoring（エラー監視）#

2. Performance Monitoring（パフォーマンス監視）#

3. Session Replay（セッションリプレイ）#

4. Cron Monitoring（定期ジョブ監視）#

5. Uptime Monitoring（稼働監視）#

6. Profiling（プロファイリング）#

なぜ自前実装ではなく Sentry を使うのか#

自前実装で「できること」と Sentry との差#

差が出るポイント1: インテリジェントグルーピング#

差が出るポイント2: ブレッドクラム（操作履歴の自動収集）#

差が出るポイント3: リリーストラッキング#

差が出るポイント4: 運用負荷#

CloudWatch との違い — インフラ監視 vs アプリケーション監視#

結論：「作れる」と「作るべき」は違う#

Seer — Sentry の AI デバッグエージェント#

Seer ができること#

Autofix の動作フロー#

2026年1月の拡張#

Sentry × Claude Code 連携#

MCP サーバーによる接続#

何ができるようになるか#

Skills としての活用#

/batch による一括改善#

仕組み#

Sentry × /batch の組み合わせ#

料金プラン#

AI エージェント監視#

実践ワークフロー：Sentry + Claude Code + /batch#

まとめ#