なぜ今Sentryを見直すべきか

エラー監視ツールとして広く使われているSentryは、2025年後半から2026年にかけて大幅な機能拡張を遂げました。 AI機能「Seer」のMCPサーバー対応によるローカル開発連携、Log Drainsによるコード変更なしのログ取り込み、 OpenTelemetryとの統合深化など、単なるエラートラッカーから統合オブザーバビリティプラットフォームへと進化しています。

この記事では、Sentryを最大限に活用するための3つの柱を解説します: アラート設計の最適化AIデバッグエージェントSeerの実践的な活用、 そして2026年Q1の注目アップデートです。

アラート設計の最適化

Sentryのアラートは大きく3種類に分かれます。 それぞれの特性を理解し、適切に組み合わせることがノイズ削減の鍵です。

3種類のアラートを使い分ける

アラート種別 発火条件 主な用途 推奨シーン
Issue Alerts 個別イシューが条件を満たした時 新規エラー検知、リグレッション検出 デプロイ直後の監視、重要イシューの即時通知
Metric Alerts メトリクスが閾値を超えた時 エラー率、レスポンスタイム、Web Vitals SLO監視、パフォーマンス劣化の検出
Uptime Monitoring URLの可用性チェック失敗時 外形監視、エンドポイント死活確認 本番サービスのヘルスチェック

Metric Alertの閾値戦略

Metric Alertには固定閾値動的閾値の2つのアプローチがあります。

実務では、固定閾値を基本とし、動的閾値で補完するのが効果的です。 WarningとCriticalの2段階に加え、自動解決の閾値も設定しましょう。

graph TD
    A[Metric Alert 設定] --> B{閾値タイプ}
    B -->|固定| C[Warning: エラー率 > 1%]
    B -->|固定| D[Critical: エラー率 > 5%]
    B -->|動的| E[前週比 +25% 以上]
    C --> F[Slack通知]
    D --> G[PagerDuty ページング]
    E --> F
    F --> H{自動解決閾値}
    G --> H
    H -->|エラー率 < 0.5%| I[アラート自動解決]

ノイズ削減のベストプラクティス

アラート疲れを防ぐために、以下のフィルタリング戦略を組み合わせます。

  • 優先度フィルタ: 高優先度イシューのみアラート対象にし、低優先度はバッチ処理
  • タグフィルタ: customer_type=enterpriseのように重要セグメントに限定
  • 最小発生回数: 「X回以上発生した場合のみ」で一時的なスパイクを除外
  • 最新リリース限定: The event is from the latest releaseでデプロイ直後の問題に集中
  • アーカイブ活用: 対処済みの繰り返しノイズはアーカイブして除外

アラートルーティングの設計

アラートの通知先は重要度に応じて使い分けるのが定石です。 SentryのOwnership Rulesを設定すれば、コードオーナーシップに基づいた自動ルーティングも実現できます。

# Ownership Rules の設定例
# パスベース
path:src/api/* #backend-team
path:src/components/* #frontend-team
path:src/billing/* #billing-team

# URLベース
url:*/api/payments/* #billing-team
url:*/api/auth/* #security-team

# フォールバック(最後に記述)
*:* #on-call-team
重要度 通知先 レスポンス期待値
Critical PagerDuty / OpsGenie(ページング) 即時対応(15分以内)
Warning Slack チャンネル通知 当日中に確認
Low メール / Sentryダッシュボード 日次レビューで確認

AIデバッグエージェント「Seer」

SentryのAI機能はSeerというブランド名で統合されています。 2026年1月の大幅アップデートにより、本番環境のエラー修正だけでなく ローカル開発・コードレビューまで開発の全段階でAIデバッグを提供するエージェントへと進化しました。

graph LR
    A[Seer AI] --> B[Autofix]
    A --> C[Issue Grouping]
    A --> D[Issue Summary]
    A --> E[Anomaly Detection]
    A --> F[AI Code Review]
    A --> G[MCP Server]
    B --> B1[根本原因分析<br/>精度 94.5%]
    B --> B2[修正コード生成<br/>成功率 53.6%]
    B --> B3[GitHub PR作成<br/>or エージェント委譲]
    C --> C1[セマンティック<br/>フィンガープリント]
    C --> C2[イシュー量<br/>約40%削減]
    G --> G1[Cursor / Claude Code<br/>ローカル連携]
    F --> F1[PR分析<br/>バグ予測]

Autofix — AIによる自動修正

Autofixは3段階のワークフローで動作する、Seerの中核機能です。

  1. Root Cause Analysis: エラーメッセージ、スタックトレース、分散トレース、ログ、プロファイルとコードベースを横断的に分析
  2. Solution Identification: 根本原因に基づく解決策を特定
  3. Code Generation: 修正コードを生成し、GitHub PRの作成またはCursorなどのコーディングエージェントへの委譲が可能

MCP対応 — ローカル開発との連携(2026年1月〜)

2026年1月の最大のアップデートが、Sentry MCPサーバーによるローカル開発環境との連携です。 これにより、CursorやClaude Codeなどのコーディングエージェントから直接Seerの分析結果を活用できるようになりました。

従来はSentryのWeb UIでしかSeerの分析を確認できませんでしたが、MCP対応により:

  • ローカルのエディタから本番エラーの根本原因分析を参照
  • コーディングエージェントにSeerの分析結果を渡して修正を委譲
  • 開発中のコードに対してSentryのコンテキストを活用したデバッグ

AIコードレビュー(2025年9月ベータ開始)

2025年9月にベータ提供が開始され、2026年1月にSeerの統合機能として再発表されました。 GitHubのPRを分析し、本番障害を引き起こしそうな実質的なバグを検出する機能です。 コードスタイルやフォーマットではなく、過去のエラーパターンと本番データに基づいて 「このコードはこういう障害を引き起こす可能性がある」という具体的な警告を提示します。

実際に2026年2月には、SeerのIssue Summary APIで発生した障害(EUリージョンで80-90%のリクエスト失敗、約40,000エラー)を Seer自身が原因特定と修正を支援した事例が公開されています。

セマンティック・フィンガープリント(AI Issue Grouping)

従来のルールベースのフィンガープリントでは、コードリファクタリングや関数再帰によって 同じ原因のエラーが別々のイシューに分かれてしまう問題がありました。

AIによるセマンティック・フィンガープリントは、エラーの文脈と意味を理解して 同一原因のエラーをインテリジェントにグルーピングします。 ベータユーザーではイシュー量が約40%削減されたと報告されています。

比較項目 従来のフィンガープリント セマンティック・フィンガープリント
判定基準 スタックトレースのパターンマッチ エラーの文脈・意味の理解
リファクタリング耐性 関数名変更でグループが崩れる コード変更に追従して正確にグルーピング
イシュー量 ベースライン 約40%削減
対応言語 全言語 JavaScript, Ruby, Python(拡大中)
利用条件 全プラン 全プラン無料で利用可能

異常検知(Anomaly Detection)

Matrix Profilesアルゴリズムを用いて、システムの通常の振る舞いパターンを自動学習します。 手動での閾値設定が不要で、ベースラインの変動にも自動適応するため、 固定閾値では検出しにくい緩やかな劣化異常なパターン変化を捉えられます。

2026年Q1の注目アップデート

Log Drains — コード変更なしのログ取り込み

2026年1月にリリースされたLog Drainsは、プラットフォームのログを コード変更なしでSentryに転送できる機能です。 Supabase、Cloudflareなどのプラットフォームログを直接取り込めます。

  • 全プランで5GB/月のログが含まれる
  • 追加は$0.50/GBとコスト効率が高い
  • SDK導入済みの構造化ログと組み合わせて、より包括的なオブザーバビリティを実現

構造化ログ(Sentry Logs)

2025年9月にGAとなった構造化ログは、Sentryのオブザーバビリティを大幅に拡張する機能です。 すべてのログがデフォルトでtrace_idspan_idに紐付けられ、 エラーやスパンと同じ画面で確認できます。

import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "YOUR_DSN",
  enableLogs: true,
});

// 6段階のログレベル
Sentry.logger.trace("関数に入りました", { fn: "processOrder" });
Sentry.logger.debug("キャッシュ検索", { key: "user:123" });
Sentry.logger.info("注文作成", { orderId: "order_456" });
Sentry.logger.warn("レート制限に接近", { current: 95, max: 100 });
Sentry.logger.error("決済失敗", { reason: "card_declined" });
Sentry.logger.fatal("DBに接続不可", { host: "primary" });

// パラメータ化メッセージ(テンプレートと変数を分離)
Sentry.logger.info(
  Sentry.logger.fmt`User ${userId} purchased ${productName}`
);

beforeSendLogフックを使えば、ログの送信前にフィルタリングや機密情報の除去も可能です。

Sentry.init({
  dsn: "YOUR_DSN",
  enableLogs: true,
  beforeSendLog: (log) => {
    // debugログを本番では除外
    if (log.level === "debug") return null;
    // 機密情報を除去
    if (log.attributes?.password) {
      delete log.attributes.password;
    }
    return log;
  },
});

OpenTelemetry統合の深化

2026年に入ってSentryはOpenTelemetry(OTel)との統合を急速に深化させています。 既存のOTelインストルメンテーションをそのまま活用し、SentryのOTLPエンドポイントに送信可能です。

  • OTLPログルーティング(2026年Q1〜ベータ): 2つの環境変数設定だけでOTLPログをSentryに転送
  • OTLPトレース送信(2026年Q1〜ベータ): 既存のOTelトレースをそのままSentryに送信可能
  • JavaScript SDK v10: OpenTelemetry 2.xに対応し、FIDをINPに置換

Size Analysis GA — モバイルアプリサイズ分析

2025年5月のEmerge Tools買収を経て、2026年2月にSize Analysisが正式リリースされました。 iOS/Androidアプリのサイズをモニタリングし、PRごとにサイズ閾値アラートを設定できます。 重複ファイルや未最適化アセットの自動検出・改善提案も行います。

Next.js SDK Turbopackサポート

2026年1月、Next.js SDKがTurbopackを自動検出・自動対応するようになりました。 Webpack依存を廃止し、コード量を10分の1(164行)に削減。 Next.js 15.4.1以降を使用していれば、設定変更なしで恩恵を受けられます。

XcodeBuildMCP買収 — エージェンティック開発への投資

2026年2月、SentryはGitHub Star 4,000超のオープンソースプロジェクトXcodeBuildMCPを買収しました。 AIエージェントがネイティブiOS/macOSアプリをビルド・テスト・デバッグできるMCPサーバーで、 Cursor、Claude Code、Codex CLIなどのエージェンティック開発環境に対応しています。

Seer MCPサーバーと合わせて、Sentryがエージェンティック開発のインフラとしてのポジションを強化していることが見て取れます。

SDK主要アップデート

SDK バージョン 時期 主な変更
JavaScript v9 → v10系 2026年Q1 OpenTelemetry 2.x対応、FID→INP、ES2020ベースライン
React Native v8.0.0 2026/02 アプリ起動時エラーキャプチャ、Cocoa SDK v9、CLI v3対応
Unity v4.0.0 2026/01 Xbox/PlayStation対応、構造化ログ、ユーザーフィードバック
Elysia Alpha 2026/03 新規SDK。Bun/Node.js対応、自動トレーシング、分散トレーシング

Feature Flags連携

エラーとフィーチャーフラグの相関分析を提供するベータ機能です。 「どのフラグ変更がこのエラーを引き起こしたか」を即座に特定できます。

  • 評価トラッキング: エラーイベント直前の最後100個のフラグ評価を記録し、疑わしいフラグを黄色でハイライト
  • 変更トラッキング: フラグの追加・削除・変更をWebhookで監視し、新エラーの原因となったフラグを「疑わしい」と表示
// React での Feature Flags 連携
import * as Sentry from "@sentry/react";

Sentry.init({
  dsn: "YOUR_DSN",
  integrations: [Sentry.featureFlagsIntegration()],
});

// 対応プロバイダー: Flagsmith, LaunchDarkly, Statsig, Unleash

Cron Monitoring

定期実行ジョブの監視も、SentryのSDKから直接計測できます。 ジョブの未実行(missed)、タイムアウト、エラーを検知し、アラートを発火します。

import * as Sentry from "@sentry/node";
import { CronJob } from "cron";

// cron ライブラリの自動計測
const CronJobWithCheckIn = Sentry.cron.instrumentCron(
  CronJob,
  "daily-report-job"
);

const job = new CronJobWithCheckIn("0 9 * * *", () => {
  // 日次レポート生成処理
  generateDailyReport();
});

// 手動チェックイン(より細かい制御が必要な場合)
const checkInId = Sentry.captureCheckIn({
  monitorSlug: "data-sync",
  status: "in_progress",
});

try {
  await syncData();
  Sentry.captureCheckIn({
    checkInId,
    monitorSlug: "data-sync",
    status: "ok",
  });
} catch (error) {
  Sentry.captureCheckIn({
    checkInId,
    monitorSlug: "data-sync",
    status: "error",
  });
  throw error;
}

アップデートタイムライン

Session Replay モバイルGA

Android / iOS / React Nativeでのセッション再生が一般提供開始

構造化ログ GA

Sentry Logsが一般提供開始。トレース連携されたログが全ユーザーに

Seer AI 大幅拡張

MCPサーバー対応、AIコードレビュー、ローカル開発連携。月額$20で提供開始

Log Drains / Turbopack対応

コード変更なしのログ取り込み、Next.js SDK Turbopack自動対応

Size Analysis GA / XcodeBuildMCP買収

モバイルアプリサイズ分析GA、AIエージェント時代への投資

React Native SDK 8.0 / OTelログルーティング

アプリ起動時エラーキャプチャ、OTLP経由ログ転送

Elysia SDK Alpha

Bun/Node.js対応の新Webフレームワーク向けSDK

OTelトレース送信ガイド公開

既存のOpenTelemetryトレースをSentryに送信する公式ガイドが公開

実務で今日から使える5つのTips

  1. アラート設計: まずユーザー影響ベースのMetric Alert(Crash Free Session Rate < 99%)を1つ設定することから始める
  2. AI活用: Seer MCPサーバーをCursorやClaude Codeに接続し、ローカル開発でもSentryの分析を活用する
  3. ログ統合: enableLogs: trueを設定するだけでトレース連携ログが取得でき、デバッグ効率が飛躍的に向上する
  4. OTel活用: 既存のOpenTelemetry環境がある場合はOTLP経由でSentryに送信し、パイプラインを一本化する
  5. SDK更新: JavaScript SDK v9以降にアップグレードして、構造化ログ・Cronモニター・AI機能の恩恵を受ける

理解度チェック

問題 0 / 50%
Q1

Sentryのアラートで、メトリクスが閾値を超えた時に発火するのはどのアラート種別ですか?

キーボード: 1〜4 で選択、Enter で回答