なぜ「console.log」で運用してはいけないのか？：Pinoで実現する構造化ログの極意
こんにちは。現場で開発環境の設計に携わっていると、新人のエンジニアが一生懸命 `console.log` でデバッグしている姿をよく見かけます。その熱意は素晴らしいのですが、残念ながら本番環境の「戦場」では、それは視界を塞ぐ霧のようなものです。
今日は、Node.jsの世界で「なぜ `console.log` を今すぐ捨て、Pinoに乗り換えるべきなのか」という本質的な理由と、プロの現場で必須となる「構造化ログ」の設計思想についてお話しします。
—
1. なぜ console.log は「悪」なのか？
`console.log` は手軽ですが、致命的な欠点が3つあります。
1. 文字列ベースの非構造化データ: 出力されたログはただの「文字列」です。監視ツール（DatadogやLoki等）は、文字列の中から特定のユーザーIDやエラーコードを抽出するために、複雑な正規表現によるパース処理を強いられます。これは計算リソースの無駄です。
2. ブロッキング処理: Node.jsの `console.log` は、実は同期的に動作することがあります。高負荷なアクセスが集中した際、ログ出力そのものがイベントループを止め、アプリケーション全体のパフォーマンスを急落させるリスクがあります。
3. コンテキストの欠如: どのリクエストで起きたエラーなのか？ どのユーザーの操作によるものか？ `console.log` だけでは、後から追跡するための「メタデータ」が圧倒的に足りません。
これらを解決するのが Pino です。
—
2. Pino を選ぶべき理由：圧倒的な速度と JSON 形式
Pino は「Node.jsで最も高速なロガー」として知られています。その秘密は、ログの書き出しを別のプロセスに逃がす設計（Worker Thread活用）と、生成されるログが最初から JSON 形式であることにあります。
ログが JSON であるということは、Datadog や Loki がそのログを読み込んだ瞬間に、「ID」「エラーレベル」「発生時刻」を自動的にインデックス化できることを意味します。これが、監視の精度を劇的に向上させる鍵です。
—
3. 実践：Pino を導入して「構造化ログ」を体感する
まずは、最もシンプルなセットアップから始めましょう。
手順1: インストール
プロジェクトルートで以下のコマンドを叩いてください。
pino本体をインストール
npm install pino
手順2: 基本のセットアップと動作確認
`logger.js` というファイルを作成し、以下のコードを記述してください。
// logger.js
const pino = require(‘pino’);
// ロガーのインスタンスを作成
// level: ‘info’ に設定すると、info以上の重要度のログのみが出力されます
const logger = pino({
level: ‘info’,
// 本番環境では環境名を付与するのが定石です
base: { env: process.env.NODE_ENV || ‘development’ },
});
// 構造化データの出力
logger.info({
userId: 12345,
action: ‘user_login’,
ip: ‘192.168.1.1’
}, ‘ユーザーがログインしました’);
// エラー出力時の作法
try {
throw new Error(‘データベース接続に失敗しました’);
} catch (err) {
logger.error({ err }, ‘致命的なエラーが発生しました’);
}
このコードを実行すると、コンソールには以下のようなJSONが出力されます。
{“level”:30,”time”:1698765432100,”pid”:1234,”hostname”:”dev-machine”,”env”:”development”,”userId”:12345,”action”:”user_login”,”ip”:”192.168.1.1″,”msg”:”ユーザーがログインしました”}
見てください。`msg`（メッセージ）だけでなく、`userId` や `env` が独立したフィールドとして出力されています。これが「構造化ログ」の力です。
—
4. 現場のプロが行う「監視ツール連携」の設計思想
ここからがアーキテクトの腕の見せ所です。Pinoで出力したこの JSON を、どうやって可視化するか。
Datadog や Loki への流し方
1. 標準出力（Stdout）を活用する: コンテナ環境（Docker/Kubernetes）では、アプリケーションはログを標準出力に流すだけに専念します。
2. Fluentd / Promtail の活用: コンテナのサイドカー（あるいはデーモンセット）として動くツールが、標準出力を拾い上げ、Datadog や Loki に転送します。
この設計のメリット:
アプリケーション側は「どこにログを送るか」を知る必要がありません。ただ `logger.info` を叩くだけ。送信先の変更や認証情報は、インフラ層のツールが肩代わりします。これにより、コードの疎結合性が保たれるのです。
—
最後に：この先にある未来
Pinoをマスターすると、デバッグは「ログを眺めて勘で修正する」作業から、「ダッシュボードを見て、発生しているエラーの相関関係を特定し、数クリックで解決する」作業へと進化します。
「ログは開発者のための手紙である」と私はよく言います。未来の自分やチームメイトが、障害の真夜中にパニックにならずに済むよう、読みやすく、機械に処理させやすいログを残す。それが、一流のエンジニアの流儀です。
ぜひ今日から `console.log` を卒業し、Pino で構造化ログの世界へ踏み出してみてください。あなたの開発ライフが、驚くほどクリアに見通せるようになるはずです。