ログを仕込んだのに、障害時に役立たない。そんな経験はないでしょうか。console.logを10行並べても、本番で欲しい情報はバラバラに散らばり、深夜のトラブルシュートではノイズの山からシグナルを探す作業になりがちです。
evlogは「1リクエストにつき1イベント」というWide Events（ワイドイベント）の設計思想で、この問題を根本から解決するTypeScript向けのログライブラリです。
この記事でわかること：
- evlogが従来のログライブラリと何が違うのか
- Wide Eventsの仕組みとメリット
- Vercel AI SDKとの連携でLLMのコスト・トークンを自動記録する方法
- 導入手順と対応フレームワーク
- PinoやWinstonとの使い分け
従来のログが抱える課題
Node.jsのサーバーサイド開発では、PinoやWinstonが定番のログライブラリとして使われています。どちらも高機能ですが、共通する弱点があります。1つのリクエスト処理で複数のログ行が出力され、障害調査時にはリクエストIDで絞り込んだうえで時系列を追う必要がある点です。
さらに、AIエージェントがコードのデバッグを支援する場面が増えた今、ログの構造はAIにとっても重要です。散在するログ行をgrepで拾い集める形式では、AIエージェントが障害の全体像を把握するのに余計な手間がかかります。
Wide Eventsという設計思想
evlogの中核にあるのがWide Eventsです。リクエストの処理中に集めた情報をすべて1つのJSONオブジェクトにまとめ、レスポンス返却時に1回だけ出力します。
具体的には、useLogger(event)でリクエストスコープのロガーを取得し、処理の各段階でlog.set()を呼んでコンテキストを蓄積します。認証情報、カートの中身、決済結果など、リクエストに関わるすべてのデータが1つのイベントに集約されます。出力されるJSONにはタイムスタンプ、HTTPメソッド、パス、処理時間が自動付与されるため、手動で埋め込む必要はありません。
エラー発生時にはwhy（原因）とfix（修正方法）フィールドを構造化して記録できます。「Something went wrong」で終わるエラーメッセージとは根本的に異なり、AIエージェントがログを読んだだけで原因と対処法を判断できる設計です。
Vercel AI SDKとの連携
evlogはVercel AI SDKとのファーストクラス統合を備えています。モデルの呼び出しを1行でラップするだけで、以下の情報がWide Eventに自動記録されます。
- トークン使用量（入力・出力・推論トークン）
- コスト見積もり
- ツール呼び出しの実行時間
- ストリーミングのパフォーマンス指標
- キャッシュヒット率
- マルチステップエージェントの各ステップ内訳
LLMを組み込んだアプリケーションでは、APIコストの把握が運用上の課題になります。evlogを導入すれば、リクエストごとのLLMコストがログに残るため、コスト異常の検知やモデル選定の判断材料として活用できます。
サイズとパフォーマンス
evlogのバンドルサイズはgzip圧縮後で約5.2 KBです。外部依存はゼロで、1リクエストあたりのオーバーヘッドは約3マイクロ秒に抑えられています。公式ベンチマークでは、Wide Eventのシナリオにおいて高速で知られるPinoの8倍のパフォーマンスを記録しています。
軽量さの理由は明確です。従来のロガーはリクエスト中に何度もI/Oを発行しますが、evlogはコンテキストをメモリ上に蓄積し、最後に1回だけ書き出します。I/O回数の削減がそのまま速度差に表れています。
対応フレームワークと導入方法
npmからインストールできます。
npm install evlog
対応フレームワークはNuxt、Next.js、SvelteKit、Nitro、NestJSなど9種類です。Nuxtではモジュールとして追加するだけで設定が完了します。Nitroベースのフレームワーク（Nuxt、Analog、Vinxi、SolidStart、TanStack Startなど）はすべて同じ機能セットを利用できます。
Cloudflare Workersにも対応しており、v2.14.1ではdefineWorkerFetchとwaitUntilを使った非同期ドレインがサポートされました。
ログの送信先（ドレインアダプター）
収集したWide Eventの送信先として、6種類のドレインアダプターが用意されています。Sentry Logs、Better Stack、ローカルのNDJSONファイルなどに対応しており、既存の監視基盤にそのまま組み込めます。NDJSONファイルへの出力は、AIエージェントがログを直接読み取って障害を分析する用途にも適しています。
サンプリング機能も内蔵されています。本番環境ではinfoログを10%、debugログを0%に設定するといった制御が可能で、ログ量の爆発を防ぎながら重要なイベントは確実に記録できます。
PinoやWinstonとの使い分け
Pinoは高速な構造化ログが必要な場面で実績があり、Winstonは複数の出力先（トランスポート）を柔軟に設定できる強みがあります。
evlogが適しているのは、リクエスト単位で文脈をまとめたい場合です。APIサーバーやLLMを組み込んだアプリケーションのように、1リクエストに複数の処理ステップがあり、障害時にはその全体像を一目で把握したいケースで力を発揮します。逆に、リクエストスコープを持たないバッチ処理やCLIツールのログには、従来のロガーのほうが素直に使えます。
まとめ
evlogはGitHubスター数1,200超、最新バージョンは2.14.1（2026年4月29日リリース）です。直近のアップデートではbetter-auth連携、監査ログ機能、log.forkによるバックグラウンド処理の追跡が追加されています。リクエスト単位のログに不満を感じているなら、Wide Eventsという選択肢を試してみる価値があります。