「本番が遅い・エラーが出ている。でもどのルートが原因か分からない」——可観測性が無いと、障害調査もコスト最適化も勘になります。Vercel は標準で多層の可観測性を備えており、「症状から原因へ」機械的に遡れるようになっています。
この記事は Vercel Observability の公式仕様に忠実に、可観測性の各層と「計測 → 最適化」のワークフローをまとめます。全体像は Vercel 本番運用ガイド を参照してください。
可観測性の地図：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イベント）——これがコストの内訳でもあります（コスト最適化）。
障害調査のワークフロー（推測しない）
①Observability で対象機能（例: Functions）と期間を選ぶ
↓
②Error Rate / Duration のグラフでスパイクを特定、ズームイン
↓
③ルート一覧をエラー率 or 遅延で並べ替え、犯人ルートを特定
↓
④ルートをクリック → Runtime Logs へ直行 → スタックトレース確認
↓
⑤原因を修正（[トラブルシューティング](/blog/vercel-troubleshooting-build-function-errors-timeout-guide) 参照）
「症状（エラー率・遅延）→ ルート → ログ → 原因」と一次情報から遡るのが、SRE の王道です（可観測性・SRE の原則）。
Speed Insights：実ユーザーの Core Web Vitals
合成計測（Lighthouse）ではなく、実ユーザーの体感（LCP/INP/CLS）を計測します。@vercel/speed-insights を入れてコンポーネントを設置するだけ。
// app/layout.tsx（Next.js App Router）
import { SpeedInsights } from "@vercel/speed-insights/next";
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="ja">
<body>
{children}
<SpeedInsights />
</body>
</html>
);
}
CWV はスコアであると同時に SEO ランキング要因でもあります。実ユーザー値を見て、遅いページを CWV 最適化（INP/LCP/CLS）で改善します。
Web Analytics：Cookieレスのアクセス解析
@vercel/analytics で、Cookie に頼らずプライバシーに配慮したアクセス解析を得られます。GDPR 配慮のサイトに向きます。
// app/layout.tsx
import { Analytics } from "@vercel/analytics/next";
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
<html lang="ja">
<body>
{children}
<Analytics />
</body>
</html>
);
}
両パッケージの注意：
@vercel/speed-insightsと@vercel/analyticsは、必ずpackage.jsonの依存に入れます。グローバルに入れて参照すると、特にモノレポでビルドエラー（トラブルシューティング）になります。
Runtime Logs と Log Drains
- Runtime Logs：関数・ミドルウェアの
console.*出力をダッシュボードで確認。障害調査の一次情報。 - Log Drains：ログを Datadog・Grafana・自社の収集基盤などへ転送。長期保管・横断分析・既存APMとの統合に。
構造化ログ：
console.log("text")ではなく、相関ID・ルート・ユーザー（PIIマスキング）を含むJSON 構造化ログを出すと、Log Drains 先での検索・集計が桁違いに楽になります。PII を出さない設計は必須です。
// 構造化ログの最小形（相関IDで追える）
function log(level: string, msg: string, ctx: Record<string, unknown>) {
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 の昇格判断を自前の数字で下せます。
「計測 → 最適化」を回す
可観測性は「入れて終わり」ではなく、改善ループの起点です。
| 目的 | 見る場所 | 次のアクション |
|---|---|---|
| 遅い | Speed Insights（CWV）/ Functions Duration | CWV 最適化、キャッシュ |
| エラー | Error Rate → Runtime Logs | トラブルシューティング |
| 高い | Functions Insights（Invocation/Active CPU） | コスト最適化 |
| bot/攻撃 | Firewall タブ | WAF/BotID |
本番チェックリスト（可観測性）
- Observability で関数・エラー率・遅延をルート別に監視
- Speed Insights で実ユーザー CWV を計測（SEO 直結）
- Web Analytics で Cookieレスのアクセス解析
-
@vercel/speed-insights/@vercel/analyticsを package.json 依存に - **構造化ログ（JSON・相関ID・PIIマスキング）**を出す
- 外部APMへ Log Drains / OpenTelemetry で連携
- Spend Management とアラートで予算・障害を検知
- 「計測 → 最適化」をループとして回す
まとめ
可観測性は「ログを出すこと」ではなく、「止まった処理・遅いページ・高いルートを一目で追える状態」を作ることです。
- Observability で症状（エラー/遅延/コスト）をルート別に特定
- Speed Insights / Web Analytics で実ユーザーの体感と行動
- Runtime Logs / Log Drains で一次情報と外部連携
- OpenTelemetry で分散トレーシング、デプロイIDでカナリア比較
- すべてを「計測 → 最適化」のループに
可観測性の設計（構造化ログ・SLO・アラート・外部APM連携・コスト監視）を、案件として承ります。
本記事は Vercel Observability 公式ドキュメント（2026年6月時点）に基づきます。機能・プラン条件は更新されるため、本番採用時は公式で最新値を確認してください。