monitoring-alerting-commerce

モニタリングとアラート — コマース

概要

一般的なインフラストラクチャのモニタリング（CPU、メモリ、エラー率）だけでは、eコマースには不十分です。チェックアウトファネルのコンバージョン率、決済ゲートウェイとカード種別ごとの決済成功・失敗の内訳、カート放棄率、在庫切れイベントといった、コマース領域のメトリクスが必要です。このスキルでは、さまざまなプラットフォームでモニタリングを設定する方法、OpenTelemetry を使ってカスタムストアフロントに計測を追加する方法、コマース KPI のダッシュボードを作成する方法、そして売上レポートに影響が現れる前に発報するアラートを設定する方法を説明します。

このスキルを使う場面

• 新しいヘッドレスストアフロントやコマースサービスのオブザーバビリティを設定するとき
• インシデントが発生したものの、早期検知のためのアラートが設定されていなかったとき
• チェックアウトのパフォーマンスや決済失敗をリアルタイムで把握する必要があるとき
• コンバージョン率の低下が技術的な問題に起因する可能性がある場合に、原因を診断するとき
• 大規模セールの前に、チェックアウトフローの SLO（サービスレベル目標）を準備するとき

基本手順

ステップ 1：プラットフォームとモニタリング可能な項目を確認する

プラットフォーム	組み込みのモニタリング	追加できるもの
Shopify	Shopify 管理画面には、注文、コンバージョン率、Core Web Vitals を含むパフォーマンスレポートが表示されます	セッション録画やファネルでの離脱確認には Lucky Orange または Microsoft Clarity をインストールします。詳細なチェックアウトファネルのトラッキングには Shopify を Google Analytics 4 に接続します
WooCommerce	WooCommerce の分析ダッシュボードには注文と売上が表示されますが、パフォーマンスモニタリングは組み込まれていません	MonsterInsights（GA4 連携）、WooFunnels（チェックアウトファネルのトラッキング）をインストールし、可用性アラート用に Uptime Robot（無料プラン：50 モニター）を設定します
BigCommerce	BigCommerce Analytics には注文、コンバージョン率、放棄されたカートが表示されます	BigCommerce を標準連携で GA4 に接続します。チェックアウトページのヒートマップとセッション録画には Lucky Orange を使います
カスタム／ヘッドレス	何もありません。自分で構築します	OpenTelemetry で計測し、Grafana Cloud（無料プラン：10K シリーズ）または Datadog にメトリクスを送信します。PromQL でチェックアウトファネルのダッシュボードを作成します。実装例は以下を参照してください

ステップ 2：プラットフォーム固有のモニタリング設定

---

Shopify

GA4 のチェックアウトファネルのトラッキングを設定する：

1. Shopify 管理画面で、オンラインストア → 設定 → Google アナリティクス に移動します
2. GA4 プロパティを接続します。Shopify は標準のeコマースイベント（page_view、add_to_cart、begin_checkout、purchase）をすべて自動的に送信します
3. Google Analytics → 探索 で、ファネルデータ探索を作成します：
   • ステップ 1：begin_checkout イベント
   • ステップ 2：add_shipping_info イベント
   • ステップ 3：add_payment_info イベント
   • ステップ 4：purchase イベント
   • これにより、チェックアウトのどの段階で購入者が離脱しているかを正確に確認できます

ストアの Core Web Vitals をモニタリングする：

1. オンラインストア → テーマ に移動し、レポートを表示 をクリックします
2. 実際の購入者のデータに基づく LCP、CLS、FID の実測値が表示されます
3. モバイルでの LCP スコアが低い（赤、> 4s）場合、ほぼ確実にヒーロー画像の最適化、または fetchpriority="high" の設定が必要です

可用性とエラーのアラートを設定する：

1. チェックアウトエラー発生時のセッション録画を取得するため、Lucky Orange（月額 $19）または Microsoft Clarity（無料）をインストールします。問題発生時に購入者に何が表示されるかを正確に確認できます
2. 注文失敗の通知を Shopify Email または Slack に設定します。設定 → 通知 に移動し、注文の決済失敗 の通知を有効にします
3. アップタイムのモニタリングには、ストアの URL にアクセスできなくなった場合にアラートを送信する Uptime Robot（無料、5 分間隔のチェック）または Better Uptime を使います

---

WooCommerce

WooCommerce を GA4 に接続する：

1. wordpress.org から MonsterInsights（無料プランあり、Pro は年額 $99 から）をインストールします
2. Insights → Settings → General に移動し、GA4 プロパティを接続します
3. Enhanced eCommerce トラッキングを有効にします。これにより、add_to_cart、begin_checkout、purchase イベントが GA4 に自動的に送信されます

チェックアウトファネルの離脱を追跡する：

1. wordpress.org から WooFunnels（無料プランあり）をインストールします
2. カート、チェックアウト、注文確認ページをステップとしてファネルを作成します
3. WooFunnels で各ステップのコンバージョン率と、購入者が離脱する場所を確認できます

稼働状況とエラーのアラートを設定する：

1. Uptime Robot（無料プラン：50 件のモニター、5 分間隔のチェック）に登録します
2. ホームページ、ショップページ、チェックアウトページ、および /wp-admin/admin-ajax.php（WooCommerce が頻繁に使用します）にモニターを追加します
3. いずれかのモニターがダウンしたときに通知するメールまたは Slack 通知を設定します

サーバーの健全性を監視する：

1. ホスティングのコントロールパネル（cPanel、Cloudways、Kinsta）で、次の項目のメールアラートを有効にします：
   • PHP エラーログ（致命的エラー）
   • ディスク使用率が 80% を超えた場合
   • メモリ使用率が 80% を超えた場合
2. 開発中に遅いデータベースクエリを特定するため、ステージング環境に Query Monitor プラグイン（無料、wordpress.org）をインストールします。本番環境では無効にしてください

---

カスタム／ヘッドレス

カスタムストアフロントでは、OpenTelemetry による計装、メトリクス保存用の Prometheus または Grafana Cloud、ダッシュボード用の Grafana を組み合わせた完全なオブザーバビリティスタックを実装します。

ダッシュボードの構築前にコマースの SLO を定義してください。これらがアラートのしきい値になります：

指標	目標	アラートのしきい値
決済成功率	95%	2 分間にわたり < 90%
チェックアウトの P99 レイテンシ	< 3000ms	3 分間にわたり > 5000ms
チェックアウトの可用性	99.9%	2 分間、開始がゼロ
カタログページの P95	< 1000ms	5 分間にわたり > 2000ms

OpenTelemetry でストアフロントを計装します：

npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-metrics-otlp-http @opentelemetry/exporter-trace-otlp-http \
  @opentelemetry/sdk-metrics

// instrumentation.ts — import before any other module
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { OTLPMetricExporter } from '@opentelemetry/exporter-metrics-otlp-http';
import { PeriodicExportingMetricReader } from '@opentelemetry/sdk-metrics';

const sdk = new NodeSDK({
  serviceName: 'commerce-storefront',
  traceExporter: new OTLPTraceExporter({ url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT }),
  metricReader: new PeriodicExportingMetricReader({
    exporter: new OTLPMetricExporter({ url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT }),
    exportIntervalMillis: 15000,
  }),
  instrumentations: [getNodeAutoInstrumentations({
    '@opentelemetry/instrumentation-http': { enabled: true },
    '@opentelemetry/instrumentation-pg': { enabled: true },
    '@opentelemetry/instrumentation-ioredis': { enabled: true },
  })],
});
sdk.start();

チェックアウトファネルのメトリクスを追跡します：

// lib/metrics/checkout-metrics.ts
import { metrics } from '@opentelemetry/api';

const meter = metrics.getMeter('commerce-checkout');

const checkoutStarted = meter.createCounter('checkout.started');
const checkoutCompleted = meter.createCounter('checkout.completed');
const paymentAttempts = meter.createCounter('payment.attempts');
const paymentSuccesses = meter.createCounter('payment.successes');
const paymentFailures = meter.createCounter('payment.failures');
const orderCreationDuration = meter.createHistogram('order.creation.duration_ms', {
  boundaries: [100, 250, 500, 1000, 2000, 5000, 10000],
});

export const checkoutMetrics = {
  recordCheckoutStart(channel: string) {
    checkoutStarted.add(1, { channel });
  },
  recordCheckoutComplete(channel: string, paymentMethod: string) {
    checkoutCompleted.add(1, { channel, payment_method: paymentMethod });
  },
  recordPaymentAttempt(gateway: string, method: string) {
    paymentAttempts.add(1, { gateway, method });
  },
  recordPaymentSuccess(gateway: string, method: string) {
    paymentSuccesses.add(1, { gateway, method });
  },
  recordPaymentFailure(gateway: string, declineCode: string) {
    paymentFailures.add(1, { gateway, decline_code: declineCode });
  },
  recordOrderCreation(durationMs: number, channel: string) {
    orderCreationDuration.record(durationMs, { channel });
  },
};

Grafana ダッシュボードパネル用の PromQL クエリ：

# Payment success rate (gauge panel — target 95%)
rate(payment_successes_total[5m])
/
(rate(payment_successes_total[5m]) + rate(payment_failures_total[5m]))

# Checkout P99 latency
histogram_quantile(0.99,
  sum(rate(order_creation_duration_ms_bucket[5m])) by (le, channel)
)

# Checkout funnel conversion rate
rate(checkout_completed_total[1h]) / rate(checkout_started_total[1h])

# Payment failures by decline code (top 5)
topk(5, sum(rate(payment_failures_total[5m])) by (decline_code))

Prometheus のアラートルール：

# prometheus/commerce-alerts.yaml
groups:
  - name: commerce-critical
    rules:
      - alert: PaymentSuccessRateLow
        expr: |
          (
            rate(payment_successes_total[5m]) /
            (rate(payment_successes_total[5m]) + rate(payment_failures_total[5m]))
          ) < 0.90
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Payment success rate below 90%"
          description: "Rate is {{ $value | humanizePercentage }}. Check Stripe status page and recent deployments."
          runbook: "https://wiki.mystore.com/runbooks/payment-failures"

      - alert: CheckoutHighLatency
        expr: |
          histogram_quantile(0.99,
            sum(rate(order_creation_duration_ms_bucket[5m])) by (le)
          ) > 5000
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Checkout P99 latency above 5 seconds"
          description: "P99 is {{ $value }}ms. Check database slow query log and Redis connection pool."

      - alert: CheckoutServiceDown
        expr: rate(checkout_started_total[5m]) == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "No checkouts being started — possible service outage"

Core Web Vitals 用のリアルユーザーモニタリングを追加します：

// lib/rum.ts — initialize in root layout
import { onCLS, onINP, onLCP, onFCP, onTTFB } from 'web-vitals';

function sendVital(metric: any) {
  navigator.sendBeacon?.('/api/rum/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    page: window.location.pathname,
  }));
}

export function initRUM() {
  onCLS(sendVital);
  onINP(sendVital);
  onLCP(sendVital);
  onFCP(sendVital);
  onTTFB(sendVital);
}

ベストプラクティス

• 原因ではなく症状に対してアラートを設定する — 「決済成功率 < 90%」（収益に影響する症状）に対してアラートを設定し、「Stripe API のレイテンシ > 500ms」（原因）に対しては設定しません。症状に基づくアラートはより早く発火し、より実用的です
• チェックアウトファネルの各ステップを個別に追跡する — 各ステップ（カート → チェックアウト → 決済 → 確認）を個別に計装し、ユーザーが離脱する場所を正確に特定できるようにします
• 失敗件数だけでなく、拒否コードも監視する — insufficient_funds が大半を占める失敗率 10% と、do_not_honor（不正利用の可能性または発行会社の障害）による失敗率 10% は異なります。それぞれ必要な対応はまったく異なります
• 可用性にはシンセティックモニタリングを使用する — RUM は実際のトラフィックに依存します。スケジュール実行するシンセティックなチェックアウトフロー（Playwright + Lambda）を使えば、顧客が気付く前に午前 3 時の障害を検知できます
• すべてのアラートにランブックへのリンクを付ける — 各アラートの注釈には、その状況の診断方法と解決方法を説明するページを指す runbook URL を含めてください
• アラートのフラッピングを避けるため、for の継続時間を設定する — 30 秒間のレイテンシ急増は正常です。for: 2m を指定したアラートは、条件が継続した場合にのみ発火します

よくある落とし穴

問題	解決策
アラートが多すぎて、シグナル対ノイズ比が低い	まず、価値の高いアラートを3～5個（決済の失敗、チェックアウトのレイテンシ、サービス停止など）設定します。それぞれが適切なしきい値で発火することを確認してから、追加してください
エラー発生時にメトリクスが記録されない	エラーが発生しやすい処理の前後にメトリクス計測を組み込みます。決済が例外をスローして失敗した場合でも、payment.failures はインクリメントする必要があります
ダッシュボードは正常に見えるのに、売上が減少している	技術指標に加えて、ビジネス指標（1分あたりの注文数、1時間あたりの売上など）も追加します。UX の問題によってコンバージョンが低下していても、技術的な SLO は達成されていることがあります
RUM データがボットの影響を受けて偏っている	RUM イベントをユーザーエージェントでフィルタリングします。ボットのトラフィックは Core Web Vitals を歪め、実際のユーザーにおけるパフォーマンスの低下を隠すおそれがあります
Shopify の GA4 ファネルにデータが表示されない	Online Store → Preferences の GA4 測定 ID が GA4 プロパティと一致していることを確認します。GA4 DebugView でイベントが発火していることも確認してください

関連スキル

• @flash-sale-scaling
• @load-testing-commerce
• @database-optimization-commerce
• @edge-commerce