はじめに
本番でトラブルが起きたとき、いちばん信頼できるのはコードでも仕様書でもなく、ログです。
でも、そのログ、ちゃんと「未来の自分が読める」ようになってますか？
この記事では、私がGMO決済やAWS SES、Webhook周りのトラブルを何度も経験した中で、思ったことを共有します。
結論
ログは誰かのためじゃなく、自分の未来のため。
「誰かのためにログを残す」と思うと、抽象的で形式的になります。
- 例）「リクエスト受信」「エラー発生」「処理完了」みたいなテンプレだけ
- でも、未来の自分はそれだけじゃ絶対にわからない
あのときの通知、何が届いて、何をしたのか。
なぜこの状態になっているのか。
ログがなければ再現も検証もできません。
ログに残して助かったこと
1. 外部APIから受け取ったbody全文（特に決済やWebhook）
「このとき本当にCANCEL来てた？」が後から100%出てくる。
保存してなければ「こうだったかも」でしか話ができず、詰む。
2. 通知の時系列
同じOrderIDに対して、
- 通知1回目 → 正常に処理
- 通知2回目（再送）→ スキップ
- 通知3回目 → 例外発生
みたいな流れは決済やメール送信でよくある。
でも「それがあった」とわかるのは、すべての通知を時系列で残していたから。
よくないログ
-
console.log('通知来た')→ 何が来たのか全くわからない -
logger.log('開始')→ どこで？どのIDで？なにが？ -
logger.log(body.OrderID)→ それだけじゃ判断できない
こういうログは、未来の自分からすると存在しないのと同じ。
ここから特定できることもあるとは思いますが綺麗に残したいですね。
💡 未来の自分に優しいログとは？
- 構造化されている（JSONでもOK）
- どの処理の、何をして、どうなったかが一目でわかる
1週間後、1ヶ月後に見返してすぐ状況がつかめるかを基準に設計する。
まとめ
- ログは「他人のため」ではなく「未来の自分のため」
- トラブルは「原因がわからないこと」が最大のストレス
- 未来の自分が再現・検証・修正できるように残しておく
- 「そのときの自分にしかわからない情報」ほど、ログに残すべき