Sentry × Claude Codeで本番エラー対応を自動化｜検知→原因調査→修正PRまで【2026年版】

Preview環境でE2Eテストを実行し、CIが失敗したらAIが原因を調査して修正する。

ここまで自動化しても、まだ一つ大きな領域が残っています。

本番環境で実際のユーザーが使ったときに初めて発生するエラーです。

そこで次に組み込みたいのが、SentryによるProduction監視です。

Sentryで本番エラーを検知し、GitHub Issueへつなぎ、そのIssueを起点にClaude Codeが原因調査・修正・テストへ進む仕組みを作れば、AI開発のループをProductionまで広げられます。

今回作るProduction Error Repair Loop

今回目指す構成は次のようなものです。

Production
↓
User Action
↓
Runtime Error
↓
Sentry
↓
Issue Detection
↓
GitHub Issue
↓
Claude Code
↓
Root Cause Analysis
↓
Minimal Fix
↓
Feature Branch
↓
Vercel Preview
↓
Playwright E2E
↓
GitHub Actions
↓
PASS
↓
Human Review
↓
Merge
↓
Production
↓
Sentry Monitoring

これまで作ってきたPreview・Playwright・GitHub Actionsの仕組みに、Production監視を追加するイメージです。

CIだけでは本番エラーをすべて防げない

Lint、Typecheck、Build、Unit Test、E2EをすべてPASSしても、本番で問題が発生する可能性は残ります。

テストでは再現できなかったユーザー操作やデータ、外部APIとの組み合わせ、特定ブラウザでの挙動など、本番環境で初めて表面化する問題があるためです。

つまり、CIとSentryはどちらか一方を選ぶものではなく、守るタイミングが異なります。

SentryからGitHub Issueへつなぐ

SentryはGitHubと連携し、Sentry上で検知した問題をGitHub側の開発フローへつなげられます。

これを利用すれば、Productionで発生した問題を単なる通知で終わらせず、修正対象の開発タスクへ変換できます。

Sentry Issue
↓
Alert Condition
↓
GitHub Integration
↓
GitHub Issue

Issue Body
├── Error
├── Stack Trace
├── Environment
├── Release
├── Sentry Issue
└── Impact

GitHub Issue側に原因調査へ必要な情報をまとめておけば、その後のClaude Codeによる分析も進めやすくなります。

すべてのSentryエラーをAIへ渡さない

ここで重要なのが、発生したすべてのエラーを自動的にClaude Codeへ送らないことです。

軽微なエラーや一時的な外部サービス障害まで修正対象にすると、不要なIssueやPRが大量に作られる可能性があります。

AIへ渡したいエラーの条件

逆に、ネットワークの一時障害や外部APIの瞬断などは、コード修正より監視継続が適切な場合があります。

GitHub IssueをClaude Codeの入口にする

GitHub Issueまで作成できれば、そのIssueを起点としてClaude Codeへ原因調査を依頼できます。

最初から「修正して」と指示するより、まずコードを変更せず原因調査だけをさせる方が安全です。

@claude

このIssueはSentryで検知されたProductionエラーです。

まずコードを変更せず、原因を調査してください。

確認項目：

- Issue本文のエラー情報
- Stack Trace
- 発生Environment
- 関連するコード
- 最近のgit diff
- 関連Release
- 既存テスト
- 同様の処理

次を報告してください。

1. 推定原因
2. 根拠
3. 影響範囲
4. 再現方法
5. 最小修正案
6. 必要な回帰テスト
7. Productionへのリスク

この段階ではまだコードへ変更を入れず、人間が分析内容を確認できる状態にしておきます。

原因が明確なら最小修正へ進む

原因分析に問題がなければ、そのIssueを引き継いでClaude Codeへ修正を任せます。

@claude

先ほどの原因分析をもとに修正してください。

進める範囲：

原因確認
↓
再現テスト追加
↓
最小修正
↓
関連テスト
↓
lint
↓
typecheck
↓
build
↓
Preview
↓
Playwright E2E
↓
diff report

ルール：

・本番仕様を勝手に変更しない
・無関係なコードを変更しない
・テストを弱めてPASSさせない
・失敗テストをskipしない
・根拠のないtimeout延長をしない
・秘密情報をログへ追加しない
・DB Migrationが必要なら停止して報告する
・Auth / Billing / Permission変更は停止して報告する
・修正後は回帰テストを実行する

「エラーを消すこと」ではなく、「仕様を維持したまま根本原因を最小修正すること」を目的にします。

本番で直接修正させない

Sentryで見つかったエラーだからといって、Claude CodeからProductionへ直接変更を入れる構成にはしません。

修正後は、これまで構築してきたPreview環境へ一度戻します。

Production Error
↓
Sentry
↓
GitHub Issue
↓
Claude Code
↓
Feature Branch
↓
Vercel Preview
↓
QA Database
↓
Playwright
↓
GitHub Actions
↓
PASS
↓
Human Approval
↓
Merge
↓
Production

再現テストを先に作る

本番バグを直すときは、修正コードより先に「その不具合を再現するテスト」を追加できると強力です。

1. 1

   Sentryで原因候補を確認

   Stack Traceや発生条件から問題を絞ります。

2. 2

   再現テストを作る

   現在のコードでFAILするテストを追加します。

3. 3

   最小修正する

   根本原因に関係する部分だけ変更します。

4. 4

   テストを再実行

   再現テストと既存回帰テストの両方を確認します。

これにより、同じバグが将来再び入り込んだ場合もCIで検出できるようになります。

Sentryの情報をそのままGitHubへ貼らない

Productionのエラー情報には、開発環境より慎重な扱いが必要です。

ユーザー情報、Request情報、Cookie、Token、個人情報などが含まれる可能性があるためです。

Claude Codeへ渡したい情報

Claude Codeがコードベースを調べるために必要な情報と、Sentryが持つProduction上の状況を組み合わせるのがポイントです。

SentryにはSeerというAIもある

Sentry自身にもAIによる障害調査・修正を支援するSeerがあります。

Seerを利用すると、Sentryが持つエラー情報やTelemetry、コードベースなどをもとに、原因分析から修正案の生成まで進められます。

そのため、「本番エラーのAI修正＝必ずClaude Code」というわけではありません。

SeerとClaude Codeはどちらを使う？

どちらかが常に優れているというより、現在の開発フローによって選び方が変わります。

Sentryを中心に障害対応を完結したい場合は、Seerを利用する構成がシンプルです。

一方で、普段からClaude Codeで仕様確認、実装、テスト、GitHub Actions、Preview QAまで運用している場合は、Sentryを「Productionエラーを検知する入口」として利用し、修正作業をClaude Codeへ戻す構成も考えられます。

高リスク変更は人間へ戻す

本番障害ほど、AIによる無制限な自動修正は危険です。

こうしたケースでは、AIが無理に修正を続けるのではなく、原因と必要な変更内容をまとめて人間へエスカレーションする方が安全です。

自動化レベルは段階的に上げる

最初からProduction障害対応を完全自動化する必要はありません。

次のように段階を分けて、自動化範囲を広げていく方法が現実的です。

1. 1

   検知だけ

   Sentryから人間へ通知します。

2. 2

   Issue化

   対象エラーをGitHub Issueへ変換します。

3. 3

   AI原因調査

   Claude Codeがコード変更なしで原因分析します。

4. 4

   AI修正

   低リスクな問題だけFeature Branch上で修正します。

5. 5

   自動検証

   Preview・Playwright・CIへ戻します。

6. 6

   Human Approval

   Production反映の最後だけ人間が承認します。

AI開発ループがProductionまでつながる

これまでの記事で作ってきた仕組みをすべてつなぐと、開発フローは次のようになります。

Specification
↓
Claude Code
↓
Implementation
↓
Feature Branch
↓
GitHub
↓
Vercel Preview
↓
QA Database
↓
Playwright
↓
GitHub Actions
↓
PASS
↓
Human Review
↓
Production
↓
Sentry
↓
Error Detection

NO ERROR ─────────────→ Monitoring

ERROR
↓
GitHub Issue
↓
Claude Code
↓
Root Cause Analysis
↓
Regression Test
↓
Minimal Fix
↓
Preview
↓
E2E / CI
↓
Human Approval
↓
Production

ここまでつながると、AIは単に新しい機能を書く存在ではありません。

実装 → テスト → リリース → 監視 → 障害分析 → 修正 → 再検証というSoftware Development Lifecycle全体へ参加するようになります。

目指すのは「自動修正」ではなく「自動回復できる開発工程」

本当に重要なのは、AIが勝手にバグを直すことではありません。

問題が起きたときに必要な情報が集まり、安全な環境へ戻り、再現し、原因を特定し、最小修正し、テストして、人間へ判断材料を渡せることです。

次はAI自動開発ループ全体を1本につなぐ

ここまでで、仕様作成から実装、Preview、QA、CI、Production監視、本番エラー修正までの部品がそろってきました。

次の記事では、これらを個別のツールとして見るのではなく、Claude Codeを中心としたAI自動開発システム全体として整理します。

出典：Sentry公式ドキュメント / Anthropic Claude Code公式ドキュメント / GitHub Actions公式ドキュメント