はじめに

AWS Lambdaで開発をしていると、とりあえず console.log() や print() を使ってログを出力する機会が多いと思います。
（実際自分の現場では多用されてます。。泣）
しかし、それらのログ、本当に後から役立っていますか？

「誰が読むの？」と言いたくなるような、読まれない・検索されない・使われないログになってしまっていないでしょうか。

この記事では、ログ（CloudWatch Logs）を 「見やすい」「後から使えるデータ」 に昇華するための設計・運用のベストプラクティスについてご紹介します。
「そろそろログ、ちゃんと考えたい」と感じている方に読んでいただけたら嬉しいです。

よくあるログ

以下のようなログ設計・運用になっていませんか？

console.log() print() で文字列だけを吐いている
必要な情報が入っておらず、あとから追えない
ログに一貫性がなく、検索や集計ができない
"〇〇成功" などの固定文言

# よくあるダメなログ例（Python）
print("ログイン成功")

このようなログは、トラブル時に役に立たないことはないですが、

ログインが成功した。
この部分まで処理が実行された。
ということしかわかりません。

ログの秘めた可能性

ログは単なる「出力」ではありません。
適切に設計されていれば、それは強力な “システムの観測データ” になります。

バグや障害時の根本原因の特定
ユーザー行動の分析
異常値の自動検出とアラートのトリガー
セキュリティ監査やリスク検知
モニタリング基盤（CloudWatch Logs Insights や Datadogなど）との連携

そして今、AI時代においては「ログ」は単なる調査ツールではなく、学習や最適化の源泉でもあります。
ログに蓄積されたデータは、将来のパフォーマンス予測やインテリジェントな障害回避、ユーザー体験のパーソナライズなど、
データ駆動型の意思決定や自動化の基盤になります。

つまり、ログは 未来のトラブルを防ぎ、現在のプロダクトの健康状態を映し出す “資産” であると同時に、
AIが価値を生み出すための「燃料」でもあるのです。

設計で差がつく！ログのベストプラクティス

ではどうすればいいのか。
ここからは、Lambdaログを「読まれる」「使える」「価値のある」ものにするためのベストプラクティスをご紹介します。

✅ 1. 構造化ログを使う

JSON形式で出力することで、CloudWatch Logs Insights や外部ツールとの連携が容易になります。

{
  "level": "info",
  "timestamp": "2025-05-30T12:00:00Z",
  "message": "User login successful",
  "userId": "123456",
  "method": "email"
}

✅ 2. ログレベルを使い分ける

ログにはレベルを持たせ、状況に応じて出力内容を制御できるようにしましょう。

DEBUG：詳細なデバッグ情報（開発・検証環境向け）
INFO：正常系の処理（通常の運用ログ）
WARN：警告（リトライで回復できた、など）
ERROR：明らかな異常や例外発生
FATAL：システム停止レベルの深刻なエラー

✅ 3. 必要十分なメタ情報を含める

ログには「何が起きたか」だけでなく、「誰が・いつ・どのリクエストで」というメタ情報を含めましょう。

{
  "level": "error",
  "timestamp": "2025-05-30T12:01:05Z",
  "message": "Database connection failed",
  "requestId": "abc-123-xyz",
  "userId": "guest",
  "region": "ap-northeast-1"
}

実際の使用例

それでは実際にどのようにログを活用するのか、具体的なコード例を見てみましょう。
ここでは Python を使って、基本的なログの出力から、構造化ログ、モニタリング基盤と連携しやすい形式への応用までを紹介します。

1. 基本的なログ出力（`logging`モジュール）

import logging

logging.basicConfig(level=logging.INFO)
logging.info("アプリケーションを起動しました")

2. 構造化ログ（JSON形式で出力）

モニタリング基盤（DatadogやCloudWatch Logsなど）との親和性を高めるには、ログを構造化しておくと便利です。

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info(json.dumps(event))

まとめ

Lambda関数のログは、工夫次第でシステムを“観測可能”にする力を持ちます。

「とりあえずログ」から、「使えるログ」へ。

ぜひ、以下のポイントを押さえて、今日からログ設計を見直してみてください。

構造化ログで出力する
ログレベルを使い分ける
必要なメタ情報を含める

おわりに

「誰が読むの？」から、「これがあって助かった！」と思えるログを一緒に目指していきましょう。

ログは書くものではなく、“活かす”ものです。

補足

具体的な Lambdaのログ出力ほうｈについてもまとめてみたので、ぜひ良ければ読んでいってください！
https://qiita.com/sagong_ryung/items/1b5b643782afd846b73a