経理の自動化は、動いている間はとても静かです。銀行明細を取り込み、仕訳候補を作り、スプレッドシートを更新する。毎月の作業が少しずつ消えていきます。
ところが、設定を変更した翌日に気づくことがあります。
「先月まで正しく動いていたルールが、今月の取引に全部適用されている」
こうなると、原因を探しながら手作業で戻すことになります。自動化で減らしたはずの仕事が、きれいに増えて帰ってきます。
経理自動化では、更新前に「元へ戻せる状態」を作っておくことが重要です。バックアップは保存するだけでなく、何を、どの時点に、どの手順で戻せるかまで決めて、初めて役に立ちます。
バックアップは「データのコピー」だけでは足りない
自動化の仕組みを復旧するには、会計データだけを残しても不十分です。仕訳を作っていたルールや、処理対象を決める設定が消えると、同じ状態を再現できません。
最低限、次の単位で分けて保存します。
- 業務データ：取引明細、仕訳、請求・入金管理のデータ
- 設定：勘定科目、部門、税区分、連携先、処理対象の条件
- 自動化ルール：仕訳ルール、スプレッドシートの関数、スクリプト、ワークフロー
- 実行記録：いつ、何件を処理したか、エラーが出ていないか
- 権限情報：誰が操作できるかを確認できる記録
特に忘れやすいのが、ルールと実行記録です。データが残っていても、「なぜこの仕訳になったのか」が追えなければ、復旧後の確認に時間がかかります。
ただし、パスワードやAPIキーをそのままバックアップへ入れるのは避けます。復旧に必要な情報は、保管場所と更新方法を別に管理し、アクセス権も絞ります。
更新前に作る「復旧ポイント」
更新前のバックアップは、ファイルを上書き保存するだけではなく、ひとまとまりの復旧ポイントとして残します。
たとえば、次のような情報を1セットにします。
- 取得日時
- 対象期間
- 変更前の設定やルール
- 変更内容のメモ
- 変更前の処理件数やエラー件数
- 復旧に使うファイルやデータの場所
ファイル名も、後から見て意味が分かる形にします。
2025-04-01_before_rule-update のように、日付と変更内容を含めると、月末に大量のファイルを開いて発掘作業をする必要がありません。
ここで大切なのは、バックアップを更新後の保存先と同じ場所だけに置かないことです。同じアカウントの削除、同期ミス、権限変更が起きると、元データまで一緒に消える可能性があります。別の保管先や、上書きされにくい履歴管理を組み合わせます。
更新作業は「保存してから変更」の順番にする
自動化の更新は、次の順番にすると事故が起きたときに戻しやすくなります。
- 現在の処理を止める、または新しい処理が走らない時間帯を決める
- 業務データと設定・ルールを保存する
- バックアップの件数やファイルを確認する
- 変更内容と更新日時を記録する
- 少量のテストデータで変更後の処理を試す
- 結果を確認してから本番処理へ進む
順番を飛ばして、「とりあえず変更して、ダメなら戻す」は危険です。変更後に保存したバックアップでは、変更前の状態へ戻れないからです。
また、更新直後に全期間を再処理するのも避けます。まずは少数の明細や、影響範囲が限定された期間で結果を見ます。自動化は、呼ばれていない取引まで張り切って処理することがあります。
復旧手順は3段階に分ける
問題が起きたとき、いきなり全データを戻すのではなく、影響範囲に応じて対応します。
1. 自動化を止める
誤ったルールで処理が続くと、復旧対象が増えます。まず、定期実行、連携、インポートなど、追加の処理を止めます。
すでに作成された仕訳や更新データがある場合は、削除や一括修正を急がず、対象件数と処理日時を記録します。先に動かしてしまうと、どこまでが誤処理なのか分からなくなります。
2. 直前の状態へ戻す
更新前の復旧ポイントを使い、設定やルールを元へ戻します。データそのものを戻すのか、ルールだけを戻すのかは、原因によって変わります。
- ルールの条件を間違えた：ルールを戻し、誤処理分を確認する
- 連携先の列や項目が変わった：変換設定を戻し、未処理データを確認する
- データを上書きした：上書き前のデータから差分を調べる
- 重複処理が起きた：処理日時・取引IDなどで重複候補を洗い出す
「全部戻す」は簡単そうに見えますが、正常な処理まで消す可能性があります。復旧範囲は、原因と影響を確認してから決めます。
3. 少量で復旧結果を確認する
元に戻したつもりでも、実行順序や権限、連携先の状態が変わっていると、同じように動かないことがあります。
次のような少量のテストを行います。
- 通常の取引が正しい勘定科目になるか
- 対象外の取引が処理されないか
- 同じ明細を再実行しても重複しないか
- 処理件数とエラー件数が想定どおりか
- 会計ソフト側の残高や明細と大きくずれていないか
復旧できたかどうかは、「エラーが消えた」だけでは判断できません。正常な取引と、処理してはいけない取引の両方を見る必要があります。
復旧できるバックアップか、テストで確かめる
バックアップの存在と、復旧できることは別です。ファイルが開けない、必要な設定が抜けている、権限がなくて戻せない。こうした問題は、本番の事故が起きてから発覚しがちです。
定期的に、実データを壊さない検証環境や複製データを使って、次を試します。
- バックアップファイルが開けるか
- 設定とルールを読み戻せるか
- 処理対象のデータを再現できるか
- テスト実行の結果が、保存時の記録と一致するか
- 復旧作業を担当する人が、手順だけで進められるか
担当者の頭の中にしかない手順は、バックアップではありません。担当者が休みの日に起きる障害ほど、なぜか急ぎます。
更新前チェックリスト
変更ボタンを押す前に、次の項目だけ確認します。
- 変更前のデータを保存した
- 設定・自動化ルールを保存した
- 保存日時と対象期間を記録した
- バックアップを別の場所にも保管した
- 変更内容と担当者を記録した
- テスト用の取引や確認方法を決めた
- 問題が起きた場合に止める処理を把握している
このチェックリストは、毎回立派な文書にする必要はありません。スプレッドシートや作業メモでも構いません。大事なのは、更新前の状態を後から再現できることです。
今日やるなら、まず1つの自動化を選ぶ
すべての仕組みを一度に整えようとすると、バックアップ作業そのものが重くなります。まずは、毎月使っている自動仕訳やCSV加工など、失敗すると影響が大きいものを1つ選びます。
その自動化について、次の3点をメモしてください。
- 何のデータを処理しているか
- どの設定やルールで動いているか
- 問題が起きたら、どの時点へ戻したいか
経理自動化で目指すのは、変更を怖がって何も触らない状態ではありません。試して、問題があれば戻せる状態です。保存は機械に任せても、復旧できるかの判断と最終確認は人間が持つ。この役割分担ができていれば、改善の一歩を踏み出しやすくなります。
