# Vercel 可観測性ガイド：Observability・Speed Insights・Web Analytics・Log Drains・OTelで本番を追う > Vercel公式に忠実な可観測性ガイド。Observability（関数/エッジ/ミドルウェア/外部API/ISR等のInsights）、Speed Insights（実ユーザーCWV）、Web Analytics（プライバシー配慮）、Runtime Logs、Log Drains、Monitoring/Notebooks、OpenTelemetry連携を、@vercel/speed-insights・@vercel/analyticsの実装と『計測→最適化』のワークフローで解説します。 - 公開日: 2026-06-28 - 著者: 友田 陽大 - タグ: Vercel, 可観測性, Next.js, パフォーマンス, コスト最適化, TypeScript, SRE - URL: https://tomodahinata.com/blog/vercel-observability-monitoring-speed-insights-log-drains-guide - カテゴリ: Vercel 本番運用 - 総合ガイド: https://tomodahinata.com/blog/vercel-production-platform-guide ## 要点 - Vercelの可観測性は多層——Observability（インフラ/アプリのInsights）、Speed Insights（実ユーザーのCWV）、Web Analytics（Cookieレスのアクセス解析）、Runtime Logs/Log Drains（ログ）、Monitoring/Notebooks（ダッシュボード/クエリ）、OpenTelemetry（外部APM連携） - Observabilityは全プラン無料で、Functions・External APIs・Edge Requests・Middleware・ISR・Image Optimization・AI Gateway等をルート別に可視化。Observability Plus（Pro/Ent）でレイテンシ・パス別内訳・長期保持が付く - Speed InsightsとWeb Analyticsは@vercel/speed-insights・@vercel/analyticsを入れてコンポーネントを設置。実ユーザーのLCP/INP/CLSとアクセスを、Cookieに頼らずプライバシー配慮で計測する。両パッケージはpackage.jsonの依存に入れる - 障害調査はObservabilityで重いルートを特定→Runtime Logsでスタックトレース確認、の順。推測せず一次情報から原因へ遡る。コスト調査も同じくInsightsでInvocation/Active CPUの重いルートを特定する - 外部APM（Datadog/Grafana等）にはLog DrainsとOpenTelemetryで連携。デプロイIDを伝播させればRolling Releasesのカナリア比較も自前メトリクスでできる --- 「本番が遅い・エラーが出ている。でもどのルートが原因か分からない」——可観測性が無いと、障害調査もコスト最適化も**勘**になります。Vercel は標準で多層の可観測性を備えており、**「症状から原因へ」機械的に遡れる**ようになっています。 この記事は [Vercel Observability](https://vercel.com/docs/observability) の公式仕様に忠実に、可観測性の各層と「計測 → 最適化」のワークフローをまとめます。全体像は [Vercel 本番運用ガイド](/blog/vercel-production-platform-guide) を参照してください。 --- ## 可観測性の地図：5つの層 | 層 | 何が分かるか | 有効化 | |---|---|---| | **Observability**（Insights） | 関数/エッジ/ミドルウェア/外部API/ISR/画像最適化等のルート別メトリクス | 標準（全プラン無料） | | **Speed Insights** | 実ユーザーの CWV（LCP/INP/CLS） | `@vercel/speed-insights` | | **Web Analytics** | アクセス解析（Cookieレス・プライバシー配慮） | `@vercel/analytics` | | **Runtime Logs / Log Drains** | 関数のログ・外部転送 | 標準 / Log Drains | | **Monitoring / Notebooks / OTel** | ダッシュボード・アラート・外部APM連携 | Observability Plus / OpenTelemetry | --- ## Observability：ルート別に何が起きているか Observability タブは、リクエストを**アプリの構造に沿って**可視化します。全プランで無料、**Observability Plus**（Pro/Ent）でレイテンシ・パス別内訳・長期保持が付きます。 可視化される Insights（一部）： - **Vercel Functions**：呼び出し数・エラー率・実行時間（ルート別） - **External APIs**：外部API呼び出しの遅延・失敗 - **Edge Requests / Middleware**：エッジ・ミドルウェアの挙動 - **ISR / Image Optimization / Fast Data Transfer / AI Gateway / Queues / Blob**：各機能の使用量 Vercel が追跡するイベント：Edge Requests・Function Invocations・External API Requests・Routing Middleware Invocations・AI Gateway Requests。**1リクエストが複数イベント**になりうる（例：1 Edge Request＋1 Middleware＋1 Function＋2 External API＝5イベント）——これがコストの内訳でもあります（[コスト最適化](/blog/vercel-cost-active-cpu-pricing-optimization-guide)）。 ### 障害調査のワークフロー（推測しない） ``` ①Observability で対象機能（例: Functions）と期間を選ぶ ↓ ②Error Rate / Duration のグラフでスパイクを特定、ズームイン ↓ ③ルート一覧をエラー率 or 遅延で並べ替え、犯人ルートを特定 ↓ ④ルートをクリック → Runtime Logs へ直行 → スタックトレース確認 ↓ ⑤原因を修正（[トラブルシューティング](/blog/vercel-troubleshooting-build-function-errors-timeout-guide) 参照） ``` 「症状（エラー率・遅延）→ ルート → ログ → 原因」と一次情報から遡るのが、SRE の王道です（[可観測性・SRE の原則](/blog/opentelemetry-observability-production-tracing-metrics-logs)）。 --- ## Speed Insights：実ユーザーの Core Web Vitals 合成計測（Lighthouse）ではなく、**実ユーザーの体感**（LCP/INP/CLS）を計測します。`@vercel/speed-insights` を入れてコンポーネントを設置するだけ。 ```tsx // app/layout.tsx（Next.js App Router） import { SpeedInsights } from "@vercel/speed-insights/next"; export default function RootLayout({ children }: { children: React.ReactNode }) { return ( {children} ); } ``` CWV はスコアであると同時に **SEO ランキング要因**でもあります。実ユーザー値を見て、遅いページを [CWV 最適化](/blog/core-web-vitals-nextjs-inp-lcp-cls-optimization-guide)（INP/LCP/CLS）で改善します。 --- ## Web Analytics：Cookieレスのアクセス解析 `@vercel/analytics` で、**Cookie に頼らずプライバシーに配慮した**アクセス解析を得られます。GDPR 配慮のサイトに向きます。 ```tsx // app/layout.tsx import { Analytics } from "@vercel/analytics/next"; export default function RootLayout({ children }: { children: React.ReactNode }) { return ( {children} ); } ``` > **両パッケージの注意**：`@vercel/speed-insights` と `@vercel/analytics` は、必ず **`package.json` の依存**に入れます。グローバルに入れて参照すると、特にモノレポでビルドエラー（[トラブルシューティング](/blog/vercel-troubleshooting-build-function-errors-timeout-guide)）になります。 --- ## Runtime Logs と Log Drains - **Runtime Logs**：関数・ミドルウェアの `console.*` 出力をダッシュボードで確認。障害調査の一次情報。 - **Log Drains**：ログを **Datadog・Grafana・自社の収集基盤**などへ転送。長期保管・横断分析・既存APMとの統合に。 > **構造化ログ**：`console.log("text")` ではなく、相関ID・ルート・ユーザー（PIIマスキング）を含む**JSON 構造化ログ**を出すと、Log Drains 先での検索・集計が桁違いに楽になります。PII を出さない設計は必須です。 ```ts // 構造化ログの最小形（相関IDで追える） function log(level: string, msg: string, ctx: Record) { console.log(JSON.stringify({ level, msg, ts: Date.now(), ...ctx })); } log("info", "order.created", { orderId, region: process.env.VERCEL_REGION }); ``` --- ## Monitoring・Notebooks・OpenTelemetry - **Monitoring**：メトリクスの上にダッシュボードとアラートを構築。 - **Notebooks**：Observability クエリを保存・整理。 - **OpenTelemetry**：OTel コレクタ連携で、トレース・メトリクスを外部APMへ。**分散トレーシング**を入れれば、Vercel 関数 → 外部API → DB の一連を相関できます。 > **Rolling Releases × 外部メトリクス**：自前の APM でカナリア判断したいときは、**デプロイ ID を外部の可観測性システムに伝播**させます。これでカナリアとベースのメトリクスを区別でき、[Rolling Releases](/blog/vercel-deployments-cicd-rollback-rolling-releases-guide) の昇格判断を自前の数字で下せます。 --- ## 「計測 → 最適化」を回す 可観測性は「入れて終わり」ではなく、**改善ループの起点**です。 | 目的 | 見る場所 | 次のアクション | |---|---|---| | **遅い** | Speed Insights（CWV）/ Functions Duration | [CWV 最適化](/blog/core-web-vitals-nextjs-inp-lcp-cls-optimization-guide)、[キャッシュ](/blog/vercel-caching-isr-cache-components-ppr-guide) | | **エラー** | Error Rate → Runtime Logs | [トラブルシューティング](/blog/vercel-troubleshooting-build-function-errors-timeout-guide) | | **高い** | Functions Insights（Invocation/Active CPU） | [コスト最適化](/blog/vercel-cost-active-cpu-pricing-optimization-guide) | | **bot/攻撃** | Firewall タブ | [WAF/BotID](/blog/vercel-firewall-waf-botid-ddos-security-guide) | --- ## 本番チェックリスト（可観測性） - [ ] **Observability** で関数・エラー率・遅延をルート別に監視 - [ ] **Speed Insights** で実ユーザー CWV を計測（SEO 直結） - [ ] **Web Analytics** で Cookieレスのアクセス解析 - [ ] `@vercel/speed-insights` / `@vercel/analytics` を **package.json 依存**に - [ ] **構造化ログ（JSON・相関ID・PIIマスキング）**を出す - [ ] 外部APMへ **Log Drains / OpenTelemetry** で連携 - [ ] **Spend Management** とアラートで予算・障害を検知 - [ ] 「計測 → 最適化」を**ループ**として回す --- ## まとめ 可観測性は「ログを出すこと」ではなく、「**止まった処理・遅いページ・高いルートを一目で追える状態**」を作ることです。 1. **Observability** で症状（エラー/遅延/コスト）をルート別に特定 2. **Speed Insights / Web Analytics** で実ユーザーの体感と行動 3. **Runtime Logs / Log Drains** で一次情報と外部連携 4. **OpenTelemetry** で分散トレーシング、デプロイIDでカナリア比較 5. すべてを「**計測 → 最適化**」のループに 可観測性の設計（構造化ログ・SLO・アラート・外部APM連携・コスト監視）を、案件として承ります。 > 本記事は [Vercel Observability](https://vercel.com/docs/observability) 公式ドキュメント（2026年6月時点）に基づきます。機能・プラン条件は更新されるため、本番採用時は公式で最新値を確認してください。