自動化が止まっても毎日デプロイを止めない――失敗・権限切れ・仕様変更から人の手順へ戻す方法
前回は、毎日残る作業を「AIや仕組みに任せる」「人が続ける」「やめる」の3つへ分けました。
小さな集計や確認を自動化すると、毎日デプロイの負担は軽くなります。しかし、自動化は一度作れば永遠に動く設備ではありません。
- 認証情報の期限が切れる
- 入力ファイルの書式が変わる
- 画面やAPIの仕様が変わる
- ネットワークが一時的に使えない
- AIが必要な項目を抽出できない
- 自動処理は成功したのに、結果が間違っている
- 担当者が変わり、直せる人がいなくなる
ここで重要なのは、自動化を絶対に止めないことではありません。
異常を早く見つけ、自動処理を止め、人が理解できる手順へ安全に戻すことです。
この記事では、非エンジニアでも扱えるように、自動化を「検知」「停止」「切り替え」「復旧」「再開」の5段階で整理します。AI、GitHub、デプロイナウを使う毎日デプロイでも、異常時に判断を失わない運用を作ります。
自動化には「通常手順」と「戻る手順」が必要
通常時だけを見ると、自動化は次のように見えます。
入力を集める
→ AIが整理する
→ 確認結果を出す
→ 人が承認する
→ 公開する
実際の運用には、別の経路が必要です。
異常を検知する
→ 自動処理を止める
→ 影響範囲を確認する
→ 人の手順へ切り替える
→ 原因を直す
→ 小さく再試験する
この経路がないと、自動化が止まった瞬間に、作業そのものが分からなくなります。
自動化を導入する前に、次の2つを残します。
- 自動化する前の手順
- 自動化が使えないときの最小手順
最小手順は、以前の作業をすべて再現する必要はありません。その日の安全な公開判断に必要な作業だけへ絞ります。
異常を4種類へ分ける
「動かなかった」だけでは、次の行動を決められません。異常を4種類へ分けます。
| 種類 | 例 | 最初の対応 |
|---|---|---|
| 実行失敗 | 接続失敗、時間超過、途中停止 | 再実行せず状態確認 |
| 権限切れ | 認証期限、アクセス拒否 | 権限範囲と期限を確認 |
| 仕様変更 | 項目名、保存場所、応答形式の変更 | 入出力の差分を確認 |
| 結果異常 | 成功表示だが件数や内容が不自然 | 元データと照合 |
実行失敗
処理そのものが完了しない状態です。
接続できない
制限時間を超えた
途中で応答がなくなった
必要なファイルが見つからない
最初に再実行すると、二重登録や二重公開になる場合があります。まず「どこまで実行されたか」を確認します。
権限切れ
昨日まで読めた場所を読めない、書き込めない状態です。
認証期限が切れた
対象リポジトリの許可が外れた
担当者の変更で所有権が変わった
読み取り権限だけになった
権限エラーを見て、すぐに広い権限を与え直してはいけません。必要な対象と操作を確認し、最小範囲だけを戻します。
仕様変更
処理は動いても、入力や出力の形が合わなくなる状態です。
入力項目の名前が変わった
保存フォルダが移動した
必須項目が追加された
応答の並び順が変わった
画面上の操作位置が変わった
仕様変更は、以前の前提と現在の状態を比較しないと見つけにくい異常です。
結果異常
最も注意したいのは、「成功」と表示されているのに結果が正しくない状態です。
5件あるはずが4件しかない
昨日の結果が混ざっている
対象外のファイルを変更している
確認済みの表示だが、実際の公開URLは古い
AIの要約から重要な未確認事項が消えている
終了コードや成功表示だけではなく、件数、更新時刻、対象範囲、期待した内容を確認します。
「動いたか」ではなく「正しく終わったか」を見る
異常検知には、3種類の証拠を使います。
1. 実行の証拠
処理が開始・終了したかを確認します。
開始時刻
終了時刻
成功・失敗
処理した対象
エラー内容
2. 結果の証拠
期待した成果物があるかを確認します。
作成されたファイル
処理件数
最終更新時刻
公開URL
変更された範囲
3. 意味の証拠
結果が目的を満たしているかを人が確認します。
必要な項目が揃っている
対象外を変更していない
未確認事項が隠れていない
利用者が正常に操作できる
戻る地点が記録されている
「実行成功」と「運用成功」を分けることが大切です。
停止条件を先に決める
自動化を安全に運用するには、成功条件より先に停止条件を書きます。
入力が0件なら停止
想定件数との差が1件でもあれば停止
対象外ファイルを1件でも検出したら停止
認証・権限エラーが出たら停止
同じ処理がすでに実行済みなら停止
戻る地点を取得できなければ停止
人の承認がなければ公開しない
停止は失敗ではありません。判断材料が不足した状態で先へ進まないための正常な動作です。
自動再実行を許すもの
- 一時的な読み取り失敗
- 元データを変更しない取得処理
- 重複しても結果が増えない確認処理
自動再実行を避けるもの
- 公開
- 送信
- 削除
- 上書き
- 課金
- 外部サービスへの登録
- 復旧操作
後者は、現在の状態を人が確認してから再開します。
人の手順へ切り替える判断
異常が出たとき、修理を完了するまで毎日の作業を止める必要はありません。安全な最小手順へ切り替えます。
次のどれかに当てはまれば、人の手順へ戻します。
- 原因を10分以内に説明できない
- 自動処理がどこまで進んだか分からない
- 結果件数が期待と合わない
- 権限を広げないと続行できない
- 本番、削除、上書き、外部公開へ影響する
- 同じ異常が2回続いた
- 元データと結果を照合できない
切り替え判断を「担当者の勘」にしないため、操作盤へ固定しておきます。
手動フォールバックカードを作る
異常時に長い手順書を探す余裕はありません。1画面または1枚で読めるカードを用意します。
# 手動フォールバック：毎日デプロイ
## 発動条件
- 自動確認が失敗
- 件数不一致
- 権限エラー
- 対象外変更を検出
## まず止めるもの
- 自動公開
- 自動書き込み
- 自動再実行
## 現在地
- 最後の正常地点：
- 今回の変更：
- 実行済みの範囲：
- 未実行の範囲：
## 人が行う最小手順
1. GitHubで変更ファイルを確認
2. プレビューで主要画面を確認
3. 未確認事項を記録
4. 戻るコミットを記録
5. Human Approval後に公開
6. 公開URLで正常操作を1回確認
## 禁止
- 原因不明のまま再実行しない
- 権限を一括で広げない
- 元データを上書きしない
- 未確認事項を消さない
カードには「何をするか」だけでなく、「何をしないか」も書きます。
切り替え時に状態を固定する
自動から手動へ切り替えるとき、最初に状態を記録します。
異常を検知した時刻
最後に正常だった時刻
実行した処理
変更された対象
まだ変更されていない対象
表示されたエラー
再実行の有無
判断した人
可能なら、ログや画面の記録も残します。ただし、認証情報、秘密情報、個人情報が含まれる場合は、そのまま共有しません。
状態を固定せずに調査を始めると、再操作によって証拠が変わり、原因を追えなくなります。
権限切れから戻す手順
権限エラーでは、次の順で確認します。
- どの操作が拒否されたか
- 読み取り・書き込み・公開のどれか
- 対象はどのリポジトリ、フォルダ、サービスか
- 以前の許可範囲は何だったか
- 期限切れか、設定変更か、所有者変更か
- 最小権限で再接続できるか
- 読み取り専用の試験が成功するか
最初の試験は、一覧取得などの読み取り専用にします。
接続確認
→ 対象一覧を読む
→ 期待する1件が見える
→ 書き込みを伴わない確認
→ 必要なら限定的な書き込み試験
権限を戻した直後に本番公開を試しません。
仕様変更を見つける基準
仕様変更は、日常の確認表に「形の確認」を加えると見つけやすくなります。
| 確認対象 | 保存する基準 |
|---|---|
| 入力 | 必須項目名、件数、書式 |
| 出力 | ファイル名、保存先、列名 |
| 画面 | 主要操作と期待結果 |
| 権限 | 読み取り・書き込みの対象 |
| AI出力 | 必須見出し、出典、未確認表示 |
毎回すべてを比較する必要はありません。処理前に軽い確認を行います。
必須項目が揃っているか
保存先が存在するか
対象件数が0ではないか
期待する見出しがあるか
権限が必要範囲に限定されているか
前提が崩れていれば、処理を始めず停止します。
AIを使う場合の異常検知
AIの出力は、同じ入力でも表現が変わる場合があります。そのため、全文一致ではなく、必要条件を確認します。
必須見出しが5つある
各判断に元記録への参照がある
不明な項目は「不明」と表示する
公開・削除・復旧を自動決定しない
記録にない情報を補っていない
AIへ依頼するときは、異常時の動作も指示します。
入力に必要な項目がない場合は、推測で補完せず停止してください。
不足している項目名を列挙してください。
元記録と対応付けられない内容は「出典なし」と表示してください。
公開、削除、上書き、権限変更、復旧は実行せず、
人の判断が必要な項目として分離してください。
もっともらしい結果を作ることより、分からない状態を見えるようにすることを優先します。
復旧後もすぐ自動運用へ戻さない
原因を直しても、すぐに通常運用へ戻しません。4つの門を通します。
門1：読み取り試験
対象を変更せず、入力を正しく取得できるか確認します。
門2：1件だけの試験
テスト用または影響の小さい1件で、出力を確認します。
門3：人の手順と並行運用
自動結果と手動結果を比較します。
件数
対象
内容
処理時間
未確認事項
門4：再開承認
原因、修正内容、試験結果、停止条件、戻る方法を人が確認します。
4つを通過してから標準運用へ戻します。
日次・週次・月次で見るものを分ける
日次
- 最終実行時刻
- 成功・停止・失敗
- 対象件数
- 期待件数との差
- 人の確認結果
- 手動切り替えの有無
週次
- 同じ異常の再発
- 手動切り替え回数
- 復旧にかかった時間
- 誤検知と見逃し
- 停止条件の不足
月次
- 権限と接続先
- 担当者と連絡先
- 手動フォールバックカード
- 最後の正常地点の記録方法
- 自動化を維持する価値
異常がなくても、月次で手動手順を読み返します。使われない手順ほど古くなりやすいためです。
障害記録を責任追及に使わない
記録の目的は、誰が間違えたかではなく、次に安全に止まれるようにすることです。
# 自動化インシデント記録
- 発生日：
- 検知方法：
- 種類：実行失敗 / 権限切れ / 仕様変更 / 結果異常
- 影響範囲：
- 自動停止できたか：
- 手動へ切り替えた時刻：
- 原因：
- 一時対応：
- 恒久対応：
- 再開試験：
- 次回追加する停止条件：
原因が人の操作だったとしても、「どの確認や停止条件があれば防げたか」を見ます。
よくある失敗
エラーが出るまで監視しない
成功表示でも結果が不正な場合があります。件数、時刻、対象範囲を確認します。
すぐ再実行する
途中まで書き込まれている可能性があります。現在地を確認してから判断します。
権限を広く戻す
原因を調べず一括許可すると、不要な対象まで変更できる状態になります。
修正直後に本番へ戻す
読み取り、1件、並行運用、承認の順で再開します。
手動手順を捨てる
自動化が正常な間に、手動フォールバックカードを更新します。
自動化の停止を失敗扱いする
危険な状態で止まることは、正しい安全動作です。
最初の7日間
1日目
自動化している作業を1つ選び、入力、出力、変更対象を書きます。
2日目
実行失敗、権限切れ、仕様変更、結果異常の例を1つずつ書きます。
3日目
停止条件を3つ決めます。
4日目
人が行う最小手順をカードへまとめます。
5日目
公開や書き込みをせず、手動への切り替えを練習します。
6日目
復旧後の4つの門を確認します。
7日目
操作盤へ、状態、停止条件、手動カード、再開承認を配置します。
まとめ
自動化を標準運用へ入れるなら、正常時の速さと同じくらい、異常時の戻りやすさが重要です。
要点は次のとおりです。
- 自動化前の手順と、異常時の最小手順を残す
- 異常を実行失敗、権限切れ、仕様変更、結果異常へ分ける
- 実行、結果、意味の3種類の証拠を見る
- 成功条件より先に停止条件を書く
- 原因を説明できなければ、人の手順へ切り替える
- 切り替え前に現在の状態を固定する
- 権限は最小範囲から戻す
- 復旧後は読み取り、1件、並行運用、承認を経て再開する
- 手動フォールバックカードを定期的に更新する
- 安全に止まることを正常な動作として扱う
最初の一歩は、自動化している作業を1つ選び、「どの状態になったら止めるか」を3行で書くことです。
次回は、自動化と手動フォールバックを含む毎日デプロイの仕組みを、担当者が変わっても続けられる引き継ぎ資料へまとめる方法を整理します。