自動化が止まった時に、何から確認するか分からないと、小さなエラーでも時間がかかります。最初に止め方と戻し方を決めておくと、原因調査を急がず普段の仕事を続けられます。

このページは、特定サービスの設定手順ではなく、小さな業務自動化へ共通して使える運用メモです。APIやサーバーを使わない、手動の下書き作成にも応用できます。

最初に実行範囲を一文にする

「毎朝メールを処理する」より、「未処理の問い合わせを分類し、返信案を下書きフォルダに保存する。送信はしない」の方が、何が起きるか確認しやすくなります。

対象、作るもの、外部へ送るか、元データを変えるかを一文に含めます。範囲が曖昧だと、エラーの時に何が未完了か判断できません。業務全体ではなく、一つの工程を単位にしてください。

停止・復旧・再開を分ける

問題があったら、まず新しい実行を止めます。次に、完了・未処理・状態不明を区別します。状態が確認できた未処理分を人が処理し、原因と影響を確認してから小さなテストで再開します。

同じ依頼を再実行する際は、「前の実行がどこまで終わったか」を確認します。画面に結果がないことだけでは、実行されていないと断定できません。重複らしい下書きも、内容や人の修正を比べる前に削除しないでください。送信や支払いなど元に戻せない処理は、初期の自動化範囲から外す判断も有効です。

停止操作と、すでに開始した処理が終わったかの確認も別です。定期実行を止めた後、進行中の実行や外部サービス側の予約が残っていないか、使っているサービスの実行履歴で確かめます。分からなければ「停止確認待ち」として新しい実行を重ねません。

実習：返信の下書き4件をどう扱うか

ここからは、送信機能を持たず下書きだけを保存する仕組みの架空例です。実際の障害記録や、特定サービスの画面操作ではありません。完成物は「どの入力を処理し直すか、どれを保留するか」が分かる台帳です。

入力をまとめてやり直す前に、次の記録を読んで判断してください。IDは人やメールアドレスではなく、作業単位の識別子です。

入力ID最後に確認できた記録保存先で確認できたもの現時点の判断
Q101下書き保存完了。出力ID D101D101。まだ人の確認前下書き生成は完了
Q102開始の記録だけ。結果の記録なし未照合状態不明
Q103まだ実行していないことを確認出力なし未処理
Q104入力検証で停止。生成処理は未開始と確認出力なし入力不足による保留

先に考える：そのまま再実行してよいのはどれ？

答え合わせ：4件をまとめて再実行しない
  • Q101は生成済み。人の確認前でも「生成失敗」ではないので再生成しません。
  • Q102は結果不明。実行履歴と保存先を入力IDで照合し、既存の出力がないか確認するまで保留します。
  • Q103は未処理。新しい自動実行を止めたことを確認してから、手作業で進められます。処理後は「手作業で完了」を台帳に残します。
  • Q104は不足情報が解決するまで保留します。同じ入力の再実行では、不足は解決しません。

この時点で、そのまま一括再実行してよい組み合わせはありません。Q103を手で済ませた場合は、再開後の処理対象から外す確認も必要です。

復旧メモの記入例：何を、どの順に確かめるか

次の運用例は、この教材のために置き場所と状態名を定義したものです。実在のサービスのボタン名ではありません。自分の環境では、設定画面や記録場所を実際に確認して置き換えます。

仕組み：問い合わせの返信下書き作成（送信はしない）
版：指示文v1／FAQ v3
台帳：「問い合わせ処理メモ」。入力IDを1件ずつ記録する。
保存先：「返信下書き」。下書きに入力IDと出力IDを残す。

1. 新規受付の自動実行を停止する。
   停止操作をした時刻と、進行中の実行の有無を別々に記録する。
2. 対象の入力ID一覧、実行履歴、出力を保存・照合する。
   パスワードや顧客本文を復旧メモへ複製しない。
3. Q101のD101を確認待ちとして残す。再生成はしない。
4. Q102を入力IDで照合する。出力や終了状態を特定できなければ保留する。
5. Q103を手作業で処理し、作業者・時刻・出力ID・確認状態を記録する。
6. Q104は不足している資料を確認する。入力がそろうまで実行しない。
7. 修正した手順はテスト用の入力だけで試す。本番4件をテストに使わない。
8. 再開前に、Q101・手で完了したQ103を対象から外せることを確かめる。
   Q102・Q104は問題が解消していなければ保留のまま残す。

台帳の「完了」だけでは、生成が終わったのか、人の確認まで終わったのか分かりません。この例なら「未処理／実行中／生成済み・確認待ち／確認済み／保留／状態不明」のように段階を分けます。送信をしない仕組みなので、確認済みを「送信済み」に読み替えてはいけません。

復旧後に残す一行

入力ID：Q103
対応：新規自動実行の停止確認後、手作業で下書きを作成
出力ID：D103-manual
現在の状態：生成済み・人の確認待ち
作業者／作業時刻：［記入］
自動化再開時の扱い：再生成しない対象として登録・照合する
残る確認：内容の照合、宛先確認。送信は別工程

「対応済み」ではなく、何まで終わり、何が残っているかを記録します。これなら手作業と自動化の両方で同じ問い合わせを処理する事故を点検できます。

よくある変化と最初の対応

症状最初に確認すること作業を続ける方法
出力がない入力IDで履歴と保存先を照合。未処理か状態不明か未処理を確認できた分だけ手作業へ
同じ内容が二つある同じ入力を二回実行していないか実行済みの印を照合する
認証エラー利用権限や接続期限が変わっていないか接続を直す前に通常作業で対応
出力の形が違う項目名・入力形式・指示が変わったか旧版と小さな例を比較する
確認時間が増えた修正が必要な種類が変わったか対象を通常例に絞る

原因を断定する一覧ではありません。症状から最初の確認を選ぶための表です。ログに顧客の全文を残す必要はなく、日時、入力の識別子、成功・失敗、処理済み範囲を中心に残します。

再開前に確認する3つのテスト

テスト期待する結果通らない場合
通常のテスト用入力を1件渡す下書きが1件だけでき、入力IDから追える本番を再開せず、手順を見直す
同じテスト用IDをもう一度対象にする既存の処理として除外または明示的に保留される自動実行を使わず、実行前に台帳で人が除外する
FAQが欠けたテスト用入力を渡す回答を創作せず、資料不足で保留する入力確認の工程を直す

同じ入力の重複実行を防ぐ仕組みがないのに、「多分二回動かない」と扱わないでください。手動チェックを挟んでも運用負担が大きいなら、自動実行そのものをやめる選択ができます。この3テストは最低限の教材上の条件で、障害が再発しない保証ではありません。

コピーして使える運用メモ

仕組みの名前：
実行する範囲：
実行のきっかけ：
入力と出力の置き場所：
実行済みを見分ける印：
「生成済み」「確認済み」など、状態の定義：
止める操作・場所：
新規停止の確認／進行中の実行を確認する場所：
止める条件：
状態不明の入力IDと調査先：
未処理分を手作業で処理する手順：
手作業で完了した分を再実行から外す方法：
元データと旧版の保存場所：
再開前のテスト例：
利用サービス・契約を確認する場所：
最終確認日：

パスワードやAPIキーそのものはメモへ貼り付けず、管理している場所だけ記します。引き継ぐ人がいなくても、数か月後の自分が実行範囲を理解できるかが基準です。

点検の頻度は影響で決める

すべてを年一回でよいとは限りません。外部サービスへ接続する処理や、毎日顧客へ影響する処理は、失敗に早く気づける必要があります。一方、外部接続のない計算式や、必要な時に開くテンプレートは変更の機会が少ない構成にできます。

点検を軽くしたい場合は、頻度だけを下げず、接続先を減らし、自動実行の範囲を狭くします。重要な障害や規約変更の通知は、通常の点検日まで待たずに扱います。

追加するより、止める候補を見つける

月に一度しか使わないのに接続を頻繁に直しているなら、その仕組みは手作業へ戻した方が楽かもしれません。「削減時間−確認と保守の時間」が小さくなったら、維持する理由を見直します。

停止した仕組みについては、不要な自動実行と有料契約が残っていないかを確認します。元データや復元用の記録まで一緒に消さず、必要なものを分けて保管してください。

新しい仕組みを追加する前には、費用対効果の計算へ保守時間も含めて戻ると、運用の負担を見積もれます。