はじめに
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