hdknr blog
戻る

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線

エラー監視ツール Sentry が提供する機能の多くは、Claude Code のようなAI コーディングエージェントで代替できるのではないか — LLM の分析能力が向上した2026年、この疑問は自然なものです。

結論から言えば、分析レイヤーは Claude Code で代替可能（むしろ得意）であり、データ収集レイヤーもスタックがパターン化されていれば自前の共通ライブラリで実装可能です。この境界線を正しく理解することが、最適なエラー監視体制を組む鍵になります。

エラー監視の3層構造

エラー監視は、以下の3つのレイヤーで構成されています。

エラー監視 = データ収集（ランタイム計装） + データ蓄積（基盤） + 分析（判断）
レイヤーSentryClaude Code で代替した場合
データ収集SDK がランタイムに計装??? （ここが問題）
データ蓄積Sentry のイベント基盤CloudWatch / 自前ログ基盤
分析Seer / ダッシュボードClaude Code（MCP / バッチ）

Claude Code が強力なのは右端の「分析」レイヤーです。しかし、左端の「データ収集」が貧弱だと、分析対象のデータ自体が不足します。

Claude Code で代替できる部分

1. インテリジェントグルーピング → LLM の方が得意

Sentry はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。

Claude Code（LLM）は意味的な類似性を理解できるため、同じ根本原因から派生した異なるスタックトレースを、Sentry のフィンガープリントより正確に集約できる可能性があります。

# Sentry のフィンガープリントでは別 Issue になるケース
TypeError: Cannot read property 'id' of undefined     ← Issue A
TypeError: Cannot read property 'name' of undefined    ← Issue B

# Claude Code なら「同じオブジェクトが null になっている」と判断できる
→ 「fetchUser() の戻り値が null のケースが未処理」という1つの原因に集約

2. リリーストラッキング → git log で十分

# エラー発生時刻とコミット履歴の突き合わせ
git log --after="2026-02-28" --before="2026-03-01" --oneline

# Claude Code に依頼
「2/28 15:00 以降に発生し始めた TypeError について、
 同時刻前後のコミットから原因となった変更を特定して」

Claude Code は git log、git diff、コードの意味理解を組み合わせて、どのコミットがどのバグを引き起こしたかを高精度に特定できます。Sentry のリリーストラッキングダッシュボードより柔軟です。

3. 根本原因分析 → Claude Code の得意分野

Sentry の Seer が行う根本原因分析は、本質的にはコードを読んでエラー原因を推測する作業です。これは Claude Code が最も得意とする領域であり、Seer と同等以上の精度が期待できます。

4. 自動修正 → Claude Code の本業

Sentry の Autofix は修正案をドラフトしますが、Claude Code はそもそもコードを書いて直すためのツールです。分析から修正まで一気通貫で行えます。

Claude Code 単体では代替しにくい部分

以下は Claude Code だけでは対応が難しい領域です。ただし、後述する「スタック固定時の自前共通ライブラリ」で大部分はカバー可能です。

1. ランタイム計装（ブレッドクラム）

Sentry SDK のブレッドクラムは、アプリケーション実行中にブラウザ API をフックして自動記録する仕組みです。

// Sentry SDK が内部でやっていること（簡略化）
// ---- fetch のフック ----
const originalFetch = window.fetch;
window.fetch = function(...args) {
  breadcrumbs.add({
    type: 'http',
    url: args[0],
    timestamp: Date.now()
  });
  return originalFetch.apply(this, args);
};

// ---- DOM クリックのフック ----
document.addEventListener('click', (e) => {
  breadcrumbs.add({
    type: 'ui.click',
    target: describeElement(e.target),
    timestamp: Date.now()
  });
}, true);

// ---- console のフック ----
const originalConsoleError = console.error;
console.error = function(...args) {
  breadcrumbs.add({ type: 'console', level: 'error', message: args });
  return originalConsoleError.apply(this, args);
};

Claude Code はランタイムに介入できないため、何らかのデータ収集の仕組みが必要です。Sentry SDK を使うか、自前で同等のフックを実装するかの選択になります。

2. リアルタイムアラート

Sentry はエラー発生の瞬間に通知します。Claude Code はオンデマンド実行であり、常時監視には向いていません。ただし、CloudWatch Logs + Lambda でリアルタイムアラートは自前構築可能です。

3. 統計情報（影響ユーザー数・エラー率推移）

イベント集計基盤がなければ正確な統計は出せません。ただし、構造化ログ + CloudWatch Logs Insights のクエリで同等の集計は可能です。

4. セッションリプレイ

DOM スナップショット記録の仕組みが必要で、自前実装の範疇を超えます。ただし、ブレッドクラムが十分に詳細であれば、Claude Code が操作履歴を時系列で再構成できるため、多くのケースではセッションリプレイなしでもデバッグ可能です。

実際の情報量の差

同じエラーについて、データ収集レイヤーの違いがどれだけ分析結果に影響するかを比較します。

CloudWatch ログ + Claude Code の場合

[ERROR] 2026-03-01 14:23:02 TypeError: Cannot read property
'transactionId' of undefined
  at CheckoutService.confirmPayment (checkout.py:142)
  at handle_checkout (views.py:87)
  at middleware (auth.py:23)

Claude Code の分析結果：

「confirmPayment メソッドの142行目で transactionId プロパティにアクセスしていますが、対象オブジェクトが undefined です。payment API のレスポンスが期待した形式でない可能性があります。」

→ 原因の推測は可能だが、「なぜそうなったか」の文脈が不足

Sentry + Claude Code（MCP 経由）の場合

[ブレッドクラム]
14:22:55  [UI]      ユーザーが「購入」ボタンをクリック
14:22:56  [HTTP]    POST /api/cart/validate → 200 OK (120ms)
14:22:57  [HTTP]    POST /api/payment/create → 200 OK (340ms)
14:23:01  [HTTP]    GET /api/payment/status/pay_xxx → 500 Error (2,100ms)
14:23:02  [Console] Error: Payment gateway timeout
14:23:02  ❌ TypeError: Cannot read property 'transactionId' of undefined

[コンテキスト]
- ユーザー: user_12345 (iOS 18.2, Safari)
- リリース: v2.3.1 (deployed 2026-02-28 10:00)
- 影響ユーザー: 342名（過去24時間）
- 初回発生: 2026-02-28 10:15（デプロイ直後）
- 発生頻度: 47回/時間（増加傾向）

Claude Code の分析結果：

「GET /api/payment/status が 500 + 2.1秒のタイムアウトを返しており、payment gateway のレスポンスが null になっています。v2.3.1（2/28 デプロイ）で初めて発生しており、iOS Safari の 342 ユーザーに影響。git log を確認すると、2/28 のコミット abc123 で payment status のポーリング間隔を変更しています。タイムアウト時のフォールバック処理が未実装なのが根本原因です。」

→ データが豊富なため、根本原因・影響範囲・修正方針まで一度に特定可能

スタック固定なら計装も自前で実装可能

ここまで「データ収集は Sentry の領域」としてきましたが、技術スタックがパターン化されている場合、この前提は覆ります。

例えば、以下のようにスタックが固定されている環境を考えます。

フロントエンド: React SPA
バックエンド:   Django REST API / Strawberry GraphQL
インフラ:       AWS (ECS Fargate, RDS, CloudWatch)

この場合、Sentry SDK がやっていることは 2つの共通ライブラリ（React 用 + Django 用）で再現できます。

React SPA              Django API              AWS
┌─────────────┐     ┌────────────────┐     ┌────────────┐
│  frontend   │     │   backend      │     │ CloudWatch │
│  tracker    │────▶│   middleware   │────▶│ Logs       │
│  (~100行)   │     │   (~150行)     │     │            │
└─────────────┘     └────────────────┘     └────────────┘
                                                │
                                           Claude Code
                                           (MCP / バッチ分析)

フロントエンド共通ライブラリ（React）

// lib/tracker.ts — React SPA 用の計装ライブラリ

type Breadcrumb = {
  timestamp: string;
  type: 'http' | 'ui.click' | 'navigation' | 'console' | 'error';
  data: Record<string, unknown>;
};

class AppTracker {
  private breadcrumbs: Breadcrumb[] = [];
  private maxBreadcrumbs = 50;
  private endpoint: string;

  constructor(endpoint: string) {
    this.endpoint = endpoint;
    this.hookFetch();
    this.hookClick();
    this.hookNavigation();
    this.hookErrors();
  }

  private add(crumb: Omit<Breadcrumb, 'timestamp'>) {
    this.breadcrumbs.push({
      ...crumb,
      timestamp: new Date().toISOString(),
    });
    if (this.breadcrumbs.length > this.maxBreadcrumbs) {
      this.breadcrumbs.shift();
    }
  }

  // ---- fetch フック ----
  private hookFetch() {
    const original = window.fetch;
    window.fetch = async (input, init) => {
      const url = typeof input === 'string' ? input : input.url;
      const method = init?.method || 'GET';
      const start = performance.now();
      try {
        const res = await original(input, init);
        this.add({
          type: 'http',
          data: { method, url, status: res.status,
                  duration_ms: Math.round(performance.now() - start) },
        });
        return res;
      } catch (err) {
        this.add({
          type: 'http',
          data: { method, url, error: String(err),
                  duration_ms: Math.round(performance.now() - start) },
        });
        throw err;
      }
    };
  }

  // ---- クリックイベント ----
  private hookClick() {
    document.addEventListener('click', (e) => {
      const el = e.target as HTMLElement;
      this.add({
        type: 'ui.click',
        data: {
          tag: el.tagName,
          id: el.id || undefined,
          text: el.textContent?.slice(0, 50) || undefined,
          className: el.className?.toString().slice(0, 80) || undefined,
        },
      });
    }, true);
  }

  // ---- React Router / History API ----
  private hookNavigation() {
    const original = history.pushState.bind(history);
    history.pushState = (...args) => {
      this.add({ type: 'navigation', data: { to: args[2] } });
      return original(...args);
    };
    window.addEventListener('popstate', () => {
      this.add({ type: 'navigation', data: { to: location.pathname } });
    });
  }

  // ---- 未処理エラー / Promise rejection ----
  private hookErrors() {
    window.addEventListener('error', (e) => {
      this.add({
        type: 'error',
        data: { message: e.message, filename: e.filename,
                lineno: e.lineno, colno: e.colno },
      });
      this.flush('error', { message: e.message, stack: e.error?.stack });
    });
    window.addEventListener('unhandledrejection', (e) => {
      this.add({
        type: 'error',
        data: { message: String(e.reason) },
      });
      this.flush('unhandledrejection', { message: String(e.reason) });
    });
  }

  // ---- バックエンドにブレッドクラム付きで送信 ----
  flush(type: string, error: Record<string, unknown>) {
    const payload = {
      type,
      error,
      breadcrumbs: [...this.breadcrumbs],
      context: {
        url: location.href,
        userAgent: navigator.userAgent,
        timestamp: new Date().toISOString(),
      },
    };
    // sendBeacon はページ離脱時でも確実に送信される
    navigator.sendBeacon(this.endpoint, JSON.stringify(payload));
  }
}

export const tracker = new AppTracker('/api/track/error');

約100行で、Sentry SDK がフロントエンドで行っているブレッドクラム収集の中核を再現しています。

バックエンド共通ライブラリ（Django）

# lib/tracker/middleware.py — Django 用の計装ミドルウェア

import json
import logging
import time
import traceback
import os

logger = logging.getLogger('app.tracker')

class RequestTrackingMiddleware:
    """全リクエストのコンテキストを自動記録"""

    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        request._tracker_start = time.time()
        request._tracker_breadcrumbs = []

        response = self.get_response(request)

        duration = time.time() - request._tracker_start
        log_data = {
            'type': 'request',
            'method': request.method,
            'path': request.path,
            'status': response.status_code,
            'duration_ms': int(duration * 1000),
            'user_id': getattr(request.user, 'id', None),
            'release': os.environ.get('APP_VERSION', 'unknown'),
        }

        if response.status_code >= 500:
            logger.error(json.dumps(log_data))
        elif response.status_code >= 400:
            logger.warning(json.dumps(log_data))
        else:
            logger.info(json.dumps(log_data))

        return response

    def process_exception(self, request, exception):
        duration = time.time() - getattr(request, '_tracker_start', time.time())
        logger.error(json.dumps({
            'type': 'exception',
            'exception_class': type(exception).__name__,
            'message': str(exception),
            'stack': traceback.format_exc(),
            'method': request.method,
            'path': request.path,
            'user_id': getattr(request.user, 'id', None),
            'user_agent': request.META.get('HTTP_USER_AGENT'),
            'release': os.environ.get('APP_VERSION', 'unknown'),
            'duration_ms': int(duration * 1000),
            'breadcrumbs': getattr(request, '_tracker_breadcrumbs', []),
        }))
# lib/tracker/graphql.py — Strawberry Django 用の拡張

from strawberry.extensions import SchemaExtension
import logging
import json
import time
import os

logger = logging.getLogger('app.tracker')

class GraphQLTrackingExtension(SchemaExtension):
    """GraphQL リクエストのトラッキング"""

    def on_operation(self):
        start = time.time()
        yield
        duration = time.time() - start

        request = self.execution_context.context.request
        result = self.execution_context.result

        errors = []
        if result and result.errors:
            errors = [{'message': str(e), 'path': e.path} for e in result.errors]

        logger.info(json.dumps({
            'type': 'graphql',
            'operation': self.execution_context.operation_name,
            'duration_ms': int(duration * 1000),
            'user_id': getattr(request.user, 'id', None),
            'has_errors': bool(errors),
            'errors': errors[:5],
            'release': os.environ.get('APP_VERSION', 'unknown'),
        }))
# lib/tracker/views.py — フロントエンドからのエラーレポート受信

import json
import logging
from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST

logger = logging.getLogger('app.tracker')

@csrf_exempt
@require_POST
def receive_frontend_error(request):
    """フロントエンドの AppTracker.flush() からのデータを受信"""
    payload = json.loads(request.body)
    logger.error(json.dumps({
        'type': 'frontend_error',
        'error': payload.get('error'),
        'breadcrumbs': payload.get('breadcrumbs', []),
        'context': payload.get('context', {}),
        'user_id': getattr(request.user, 'id', None),
    }))
    return JsonResponse({'ok': True})

合計約150行で Django ミドルウェア + Strawberry 拡張 + フロントエンドエラー受信を実装できます。

Sentry SDK vs 自前共通ライブラリの正確な比較

スタックが固定されている場合、比較は以下のように変わります。

機能Sentry SDK自前共通ライブラリ差
fetch/XHR フック自動自前で実装可能（上記 tracker.ts）ほぼ同等
クリック/入力イベント記録自動自前で実装可能ほぼ同等
ナビゲーション記録自動自前で実装可能ほぼ同等
未処理例外の捕捉自動自前で実装可能ほぼ同等
Django リクエストコンテキスト自動ミドルウェアで実装可能ほぼ同等
GraphQL オペレーション追跡プラグインExtension で実装可能ほぼ同等
ソースマップ逆変換自動ビルドパイプライン構築が必要（※）Sentry 有利
セッションリプレイ内蔵rrweb 等の別ライブラリが必要Sentry 有利
ダッシュボード内蔵CloudWatch Insights / Grafana好みの問題

※ ソースマップについて：Claude Code はリポジトリのソースコードを直接読めるため、ミニファイ後のエラーメッセージからでも LLM の推論で元のコード位置を特定可能。厳密な行番号マッピングは劣るが、実用上は十分なケースが多い。

自前共通ライブラリ + CloudWatch で得られるデータ

自前実装でも、Sentry と同等レベルの情報を Claude Code に渡せるようになります。

[フロントエンド ブレッドクラム]（自前 tracker.ts が収集）
14:22:55  [ui.click]    tag=BUTTON id=checkout-btn text="購入する"
14:22:56  [http]        POST /api/cart/validate → 200 (120ms)
14:22:57  [http]        POST /api/payment/create → 200 (340ms)
14:23:01  [http]        GET /api/payment/status → 500 (2,100ms)
14:23:02  [error]       TypeError: Cannot read property 'transactionId'

[バックエンド ログ]（自前 middleware が収集）
14:22:56  [request]     POST /api/cart/validate → 200 (115ms) user=12345
14:22:57  [request]     POST /api/payment/create → 200 (335ms) user=12345
14:22:57  [graphql]     mutation CreatePayment (330ms) user=12345
14:23:01  [exception]   TimeoutError: Payment gateway timeout
                         at PaymentService.check_status (payment.py:89)
                         user=12345 release=v2.3.1

[Claude Code 分析に渡せるコンテキスト]
- フロントエンドのユーザー操作履歴（ブレッドクラム）
- バックエンドのリクエスト/例外ログ
- GraphQL オペレーション単位のトレーシング
- ユーザー ID、リリースバージョン、User-Agent
- git log によるリリース相関

→ Sentry + MCP で得られる情報と実質的に同等のデータが、Claude Code の分析対象として揃います。

残る Sentry 固有の優位性

スタック固定 + 自前共通ライブラリの場合、Sentry の優位性は以下に絞られます。

1. セッションリプレイ — DOM の変更を差分記録してビデオライクに再生する機能は、rrweb のような専用ライブラリが必要で、自前共通ライブラリの範疇を超えます。ただし、詳細なブレッドクラムがあれば多くのデバッグケースはカバー可能です。

2. 100+ プラットフォーム SDK — 新しいフレームワークやプラットフォームを追加するたびに計装を書く必要があります。スタックが固定なら問題になりませんが、技術的多様性が高い組織では Sentry の SDK エコシステムの価値が出ます。

3. ゼロ運用 — Sentry クラウド版は完全マネージドです。自前共通ライブラリ + CloudWatch の場合、ログ基盤の運用は AWS の責務ですが、共通ライブラリ自体のメンテナンス（フレームワークの破壊的変更への追従等）は自チームの責務になります。

Sentry を Claude Code で置き換える現実的なアプローチ

スタックが固定されている場合、共通ライブラリの初期構築 + CloudWatch + Claude Code で Sentry を完全に代替できます。段階的に構築するアプローチを示します。

Step 1: 共通ライブラリの構築（データ収集レイヤー）

上記のフロントエンド tracker.ts（~100行）と Django ミドルウェア + Extension（~150行）を共通ライブラリとして構築します。

各プロジェクトでは以下の設定だけで計装が完了します。

# settings.py
MIDDLEWARE = [
    'lib.tracker.middleware.RequestTrackingMiddleware',
    # ...
]
# schema.py
schema = strawberry.Schema(
    query=Query,
    mutation=Mutation,
    extensions=[GraphQLTrackingExtension],
)
// main.tsx
import './lib/tracker';  // import するだけでフックが有効化

Step 2: ログ基盤の構築（データ蓄積レイヤー）

AWS の場合、CloudWatch Logs に集約するのが最もシンプルです。

アプリ → CloudWatch Logs → CloudWatch Logs Insights（検索）
                         → Lambda（アラート）
                         → S3（長期保存）

Step 3: Claude Code による分析（分析レイヤー）

MCP サーバーやスクリプトで CloudWatch Logs に接続し、Claude Code で分析します。

# Claude Code のバッチ処理で直近のエラーを一括分析
claude -p "CloudWatch Logs から過去24時間のエラーを取得し、
  1. エラーを根本原因ごとにグルーピング
  2. 各グループの影響範囲（ユーザー数、発生頻度）を推定
  3. 優先度順に並べて修正案を提示" --batch

Step 4: アラートの設定

# CloudWatch Logs + Lambda でリアルタイムアラート
# サブスクリプションフィルタでエラーログを Lambda に転送
# Lambda から Slack/GitHub Issues に通知

参考: CloudWatch エラー監視の Gist

コスト比較

項目Sentry Team プランCloudWatch + Claude Code
月額固定$26/月（50K エラー）CloudWatch Logs は従量課金
エラー単価超過分は従量課金Claude Code API 利用料
初期構築SDK 導入（数行）ミドルウェア + ログ設計 + 分析スクリプト
運用保守ゼロ（マネージド）ログ基盤の運用 + 分析パイプラインの保守
スケーラビリティ自動自前で設計

少量のエラー（月数千件） であれば CloudWatch + Claude Code の方がコスト効率が良い可能性があります。大量のエラー（月数万件〜） では Sentry のマネージドサービスとしての価値が際立ちます。

判断基準のまとめ

Sentry を使うべきケース

Claude Code で代替できるケース

ハイブリッド（推奨）

最も現実的なのは、Sentry のデータ収集力 + Claude Code の分析力を組み合わせるアプローチです。

Sentry SDK（データ収集・計装）
    │
    ▼
Sentry MCP サーバー
    │
    ▼
Claude Code（分析・グルーピング・修正）

Sentry を「データ収集のインフラ」として使い、分析は Claude Code に任せる。Seer の分析機能と Claude Code の分析は重複しますが、Sentry の SDK が集めるデータの豊かさが Claude Code の分析精度を引き上げます。

結論

Sentry の価値 = データ収集（SDK 計装） + 分析（Seer）

Claude Code で代替可能な部分   → 分析（Seer と同等以上）
データ収集（ランタイム計装）   → スタック固定なら自前共通ライブラリで代替可能

「Sentry を Claude Code で置き換えられるか？」に対する答えは：

技術スタックがパターン化されている環境では、共通ライブラリ（~250行）+ CloudWatch + Claude Code で Sentry の機能を実質的に代替できます。Sentry の $26/月は「共通ライブラリを書く手間」と「CloudWatch の設定」を省くための費用と位置づけられます。

この手間を許容できるチームにとっては、Claude Code の分析力の方が Sentry の Seer より柔軟であり、かつ分析→修正まで一気通貫で行える点で優位性があります。

関連記事:

参考リンク:

前の記事
MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的
次の記事
ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく周辺設計で決まる