この記事のポイント

  • エラーログ・通知設計のレビュー観点を体系化
  • 「障害解析可能なログか？」をレビューアーが読み取る訓練
  • 障害発生時の診断性・監視性をレビューで実務指摘可能にする

そもそも「エラーログ・通知方針」とは何か

エラーログ・通知設計とは単なるlogger.error()の羅列ではなく、
障害原因調査の材料を未来の解析者に残すための設計責任そのものである。

対象 目的 影響
エラーログ 原因特定・再現支援 開発/運用が障害を追跡
監視通知 早期検知・影響可視化 インフラ・SREがアラート対応

レビューアーは「発生原因まで特定可能なログ粒度か？」
を読み取れることがレビュー技術の中核になる。

なぜこれをレビューするのか

  • 「原因不明障害」がレビュー未対応のログ設計から量産される
  • ログ基準が未統一 → 診断不能
  • 監視通知が未整理 → 重大障害でも無通知化
  • 再現条件不明 → 運用負担が肥大化

レビュー段階でログ責任の設計段階での固定化が極めて重要となる。

レビューアー視点

  • 誰がこのログを読むのか？（役割読み）
  • 障害原因を追える情報粒度か？（入力＋環境＋文脈）
  • 同系障害を横断調査できる形式化がなされているか？
  • 監視アラートの優先順位設計が組み込まれているか？
  • 個人情報・セキュア情報のマスキングが施されているか？

開発者視点

  • 操作入力は極力埋め込む
  • 環境情報（ホスト、接続先）を付加
  • 処理系層名・機能名はログ行に必ず含める
  • 例外what()は埋め込み統一
  • 監視通知用コードパスはビジネス重要度分類に連動させる

良い実装例

例1：入力パラメータ埋込

入力パラメータ明示 
void saveUser(int userId) {
    try {
        repository.save(userId);
    } catch (const std::exception& e) {
        logger.error("User save failed: userId={}, reason={}", userId, e.what());
    }
}
  • 診断性向上 → 入力情報即取得可能

例2：監視通知統合

監視通知統合型 
void processPayment(int orderId) {
    try {
        gateway.charge(orderId);
    } catch (const PaymentGatewayException& e) {
        logger.error("Payment failed: orderId={}, reason={}", orderId, e.what());
        monitoring.notify("PAYMENT_FAILURE", fmt::format("orderId={}, reason={}", orderId, e.what()));
    }
}
  • 通知設計と障害粒度設計を統一

例3：環境情報埋込

環境情報統合型 
void connectDatabase(const std::string& dbHost) {
    try {
        db.connect(dbHost);
    } catch (const std::exception& e) {
        logger.error("DB connection failed: host={}, error={}", dbHost, e.what());
    }
}
  • 接続先情報で即時特定可能

レビュー観点

  • 入力値・環境依存情報が含まれているか
  • 層名（処理責務名）がログ行内に含まれているか
  • what()情報が統合出力されているか
  • ログ行は機械検索可能な形式整備されているか
  • 監視通知が設計に統合されているか
  • 情報漏洩（個人情報埋込）が防止されているか

良くない実装例: ケース1（抽象ログ）

抽象ログ型 
void saveUser(int userId) {
    try {
        repository.save(userId);
    } catch (const std::exception& e) {
        logger.error("Save failed");

@Reviewer
抽象ログでは再現不能です。userIdや例外情報を埋め込んでください。
    }
}

改善例

改善例（詳細情報付加） 
logger.error("Save failed: userId={}, reason={}", userId, e.what());

良くない実装例: ケース2（通知分離未統合）

通知不在型 
void processOrder(int orderId) {
    try {
        payment.charge(orderId);
    } catch (const std::exception& e) {
        logger.error("Order failed: {}", e.what());

@Reviewer
監視通知経路を統合してください。障害監視で検知できなくなります。
    }
}

改善例

改善例（通知統合） 
monitoring.notify("ORDER_FAILURE", fmt::format("orderId={}, reason={}", orderId, e.what()));

良くない実装例: ケース3（マスキング不備）

情報漏洩危険型 
void paymentError(const std::string& cardNumber) {
    logger.error("Payment failed for card={}", cardNumber);

@Reviewer
個人情報直接埋込は避け、末尾マスキング処理を入れてください。
}

改善例

改善例（マスキング適用） 
auto maskCard = [](const std::string& card) {
    return "****" + card.substr(card.size() - 4);
};
logger.error("Payment failed for card={}", maskCard(cardNumber));

良くない実装例: ケース4（層責務情報消失）

責務層名消失型 
logger.error("Failure detected");

@Reviewer
ログ行に層名・機能名を埋め込んでください。障害経路特定不能になります。

改善例

改善例（層責務情報統合） 
logger.error("[OrderService] Failure detected: orderId={}, reason={}", orderId, e.what());

PlantUML：ログ・通知責務整理フロー

UML Diagram

ログメッセージ構造統一指針

要素 内容
層名 [OrderService]
操作対象 userId, orderId
失敗理由 what()文字列
影響区分 PAYMENT_FAILURE, DB_FAILURE など分類

レビューアーはログ構造テンプレート統一が守られているかを確認対象に含める。

ログ粒度の分類

粒度区分 目的
DEBUG 開発時詳細追跡
INFO 業務正常進捗
WARN 異常だが影響限定
ERROR 要調査障害候補
FATAL 即運用対応障害

レビューはERROR以上の運用ログ品質を重点確認対象とする。

監視通知の運用影響整理

通知粒度 目的 対象層
SERVICE_FAILURE 業務処理失敗 サービス層
SUBSYSTEM_FAILURE 外部依存失敗 インフラ層
FATAL_SHUTDOWN 異常終了 プロセス層

レビューアーは通知分類設計が運用役割分担に沿っているかを確認する。

ログ行検索性の形式整理

  • orderId=123
  • userId=456
  • host=web01
  • reason=DB timeout

レビューは人力だけでなく自動監査を前提に形式統一されているかを確認する。

ロギング統合例（完全統合）

総合統合型ログ 
void registerUser(int userId) {
    try {
        repository.save(userId);
    } catch (const std::exception& e) {
        const auto msg = fmt::format("[UserService] Registration failed: userId={}, reason={}", userId, e.what());
        logger.error(msg);
        monitoring.notify("USER_REGISTRATION_FAILURE", msg);
    }
}

観点チェックリスト

まとめ

レビューアーがエラーログ・通知設計で常に問うべきは
「このログ行は未来の障害現場で原因特定を支援できるか？」
です。

  • 入力情報は埋め込む
  • 障害分類は整理する
  • 層名・責務名は常に埋め込む
  • 通知設計は監視設計と統合する

レビュー現場では
「このログ設計で障害調査現場がどれだけ救われるか？」
を問い続けるレビュー文化が品質と運用コストを決定づけます。