前回は、AppSheet・スプレッドシート・Backlogをつないだ社内システムの全体像を紹介しました。今回はその裏側、自動化して初めて起きた事故の話です。
業務の自動化を検討されている方に一番お伝えしたいのは、「自動化すれば楽になる」ではなく、「自動化すると、事故も自動で広がる」ということです。だからこそ、どんな事故が起きるのかと、どう設計を変えたのかを、実際の数字で残しておきます。
事故1：自動処理が64件の案件を「削除済み」にした
何が起きたか
2026年6月のことです。AppSheetのボタンから、Backlogの課題のステータスを更新する処理を実行しました。ところが、AppSheet側の関数（LOOKUP）の書き方に誤りがあり、どの案件を選んでも、対応表の先頭1行しか返さない状態になっていました。
存在しない課題番号にBacklogへ更新をかけると、Backlogは「見つかりません（404）」を返します。ここで、当時のGASには「404が返ったら、その課題はBacklog側で消されたのだろう」と判断して、シート側の案件を自動で「削除済み」にする処理が入っていました。
結果、98件の案件のうち64件が、実際にはBacklogに残っているのに「削除済み」扱いになりました。
復旧
Claude Codeに、Backlogの実データとシートを突き合わせて「本当は生きている案件」を洗い出させ、復旧処理を作りました。1回目は60件が成功、4件が失敗。失敗した4件は、Backlog側で「ステータス変更時はコメント必須」という設定がされていたプロジェクトで、コメントなしの更新が拒否されたためでした。コメント付きで再実行し、64件すべてを戻しました。
変えたこと
復旧よりも大事なのは、「404が返ったら削除」という自動処理そのものを廃止したことです。
今は、削除はBacklog側で人が行い、Backlogから届く「削除された」という通知だけをきっかけにシートを更新します。逆方向（シート側が勝手に削除と判断する）は持ちません。
自動処理に「消す」権限を持たせるときは、必ず二重の根拠を要求する。 「見つからない」は「消された」とは限りません。通信の不調でも、こちらの指定ミスでも404は返ります。破壊的な操作は、相手側の明示的な通知だけを根拠にする、というのがこの事故から得た原則です。
事故2：期限超過の通知が、14日を過ぎると沈黙する
何が起きたか
期限を過ぎたタスクを担当者に知らせる仕組みは、最初「凝った」設計でした。超過3日目・7日目・14日目に1回ずつ通知して、それ以外の日は静かにする、という段階エスカレーションです。「毎日同じ通知が来ると誰も見なくなる」という配慮からでした。
ところが運用してみると、14日を過ぎたタスクは、その後どこにも出てこないという穴がありました。一番放置されているタスクほど、一番静かになる設計になっていたわけです。
変えたこと
2026年7月に、段階式をやめて毎日・全件を通知する方式に戻しました。通知の量は増えましたが、「昨日も出ていたタスクが今日も出ている」ことが、そのまま放置の可視化になります。
「賢い仕組み」を作りたくなったときほど、一番単純な方式で何が困るのかを先に確かめるべきでした。
事故3：顧問先の判定が、107件中46件ズレていた
何が起きたか
Backlogは本来、顧問先ごとに1プロジェクトを作って運用しています。しかし歴史的な経緯で、1つのプロジェクトに複数の会社が同居しているケースが残っていました。
システムは「プロジェクト→会社」を対応表で引きます。同居しているプロジェクトでは、対応表の後に登録された会社が勝ってしまい、そのプロジェクトの課題がすべてその会社のものとして扱われました。
週次の整合性チェックで数えたところ、手動で起票された課題107件のうち46件で、Backlog上のカテゴリとシート上の顧問先が食い違っていました。
変えたこと
同居していたプロジェクトを会社ごとに分離しました。あわせて、週次のヘルスチェックに「1つのプロジェクトに複数の会社が紐づいていないか」の検査を足し、再発したらその週の月曜朝に分かるようにしました。
事故未満の「地味な改善」も残しておく
大きな事故ではないものの、運用して初めて分かった調整も記録しています。
- 安全網の頻度を下げた：Backlogの変更をシートに取り込む定期処理を、5分ごとから60分ごとに変えました。頻繁すぎて、リアルタイムの通知処理とロックが競合し、本来のリアルタイム更新のほうが失敗することがあったためです。「安全網は網であって本線ではない」と割り切りました
- 削除の作法を文書化した：テスト用の案件を消したときに、関連データ57件が孤立して残り、整合性チェックで59件の違反として検出されました。「案件を消すときは何をセットで消すか」を規約にしました
- AIが生む作業ファイルを隔離した：ブラウザを自動操作させると、スクリーンショットや途中の記録が大量に残ります。数えたら456件・約86MBあり、専用フォルダに退避するルールにしました
Claude Codeと事故対応をして分かったこと
事故対応そのものも、Claude Codeと一緒にやっています。やり方として定着したのは次の3つです。
1. 事故は「インシデントメモ」として残す
何が起きたか、影響件数、復旧の手順と結果、再発防止策を1つの文書にします。この文書はそのままClaude Codeのルールブック（CLAUDE.md）から参照され、次に似た機能を作るときに「前にこれで事故った」と先回りしてくれます。
2. 「壊してはいけない前提」をコードの説明に書く たとえば「削除はBacklogからの通知だけを根拠にする」は、コメントとしてコードの横にも書いてあります。半年後の自分やAIが「ここ簡略化できそう」と思ったときの歯止めです。
3. 復旧処理は必ず試運転から 64件の復旧のときも、まず「戻す予定の一覧」だけを出させ、人が目で見てから実行しました。復旧処理で二次事故を起こすのが一番つらいからです。
自動化を検討している方へ
3つの事故に共通するのは、コードのバグそのものより、「その状況で自動処理に何をさせるか」の判断が甘かったことです。
- 見つからない → 消す（事故1）
- 通知しすぎない → 一番古いものが沈黙（事故2）
- 対応表は最後の登録が正しい → 同居していると全部ズレる（事故3）
どれも、作っているときは合理的に見えました。自動化の設計では「うまくいくとき」より、「入力が想定と違ったとき、自動処理は何をするか」に時間を使う価値があります。
当法人がお客様のバックオフィスDXを支援するときも、この視点を必ず持ち込みます。承認フローの分岐、例外時の差し戻し、消していいデータの範囲。ツールの機能説明より、そこに時間をかけます。
次回：月次監査・決算監査ツール
最終回は、当法人の中でいちばん規模の大きい仕組み、マネーフォワード クラウド会計と連携して月次・決算のチェックを行うスプレッドシート群と、その結果をAIが判断して報告書の下書きを作る2階建ての仕組みを紹介します。
シリーズ
- e-Taxの控えを共有ドライブへ自動振り分けし、Backlogで報告する仕組み
- AppSheet（スプレッドシート）×GAS×Backlogで顧問先管理とタスク起票を自動化した話
- 自動化で起きた3つの事故と、壊れにくい設計に変えるまで（本記事）
- 月次監査・決算監査ツール：マネーフォワード連携スプレッドシート＋AIの2階建て