エラー時の通知とログの設計（誰が・いつ・何を見て対応するか）

気づかれないエラーがいちばん危ない

ロボットが夜間に止まっていても、誰も気づかなければ、翌日の業務が進まないまま時間が過ぎます。逆に、毎回大量のエラー通知が届くと、そのうち誰も読まなくなります。通知とログは、「必要な人に、必要なときだけ、対応に必要な情報を届ける」ことが目的です。

通知の種類を分ける

通知は、内容によって宛先と緊急度を分けます。

• 処理完了の報告：業務の担当者へ。処理件数・エラー件数と結果ファイルの場所
• 一部の件のエラー：業務の担当者へ。どの件が・なぜエラーかの一覧
• ロボットの停止（ログイン失敗、システム停止など）：ロボットの管理者へ。すぐ対応が必要
• 予定の時刻に動かなかった：管理者へ。スケジュールやサーバーの問題の可能性

通知に入れる内容

通知を受け取った人が、ログを探しに行かなくても次の行動を決められる内容にします。

［エラー通知メールの例］
件名：【RPA】請求登録ロボット　エラーあり（3件／全120件）
本文：
  実行日時　：2026/10/05 08:30〜08:52
  処理結果　：完了 117件、エラー 3件
  結果ファイル：\\共有\RPA\請求登録\出力\2026\10\請求登録結果_20261005_0830.xlsx
  エラーの内容：
    ・行12　顧客コード 100234：システムに顧客が見つかりません
    ・行57　金額が空欄です
    ・行98　金額が空欄です
  対応：結果ファイルの「エラー」の行を修正し、入力フォルダに置き直してください

ログに残す内容

通知とは別に、ロボットの実行の記録（ログ）を残しておくと、あとから問題を調べるときの手がかりになります。BizRobo! の Management Console でも実行結果やエラーを確認できますが、業務の観点での記録（どのデータをどう処理したか）は、結果ファイルや専用のログファイルに残すと分かりやすくなります。

• 実行の開始・終了日時と処理件数
• 1件ごとの処理結果とエラーの内容
• 止まったときのステップ名と、そのときの画面の状態

通知のルールを運用で見直す

通知の宛先や条件は、運用を始めてから調整するのが現実的です。「この通知は毎回同じ内容で役に立っていない」「この種類のエラーは担当者ではなく管理者に送るべき」といった声を集めて、定期的に見直します。対応した内容を記録しておくと、よく起きるエラーの対策をロボット側に組み込むきっかけにもなります。

ほかの記事