担当者が変わっても毎日デプロイを続ける――自動化と手動復旧を引き継ぐ運用資料の作り方

前回は、自動化に異常が起きたとき、処理を止めて人の手順へ安全に戻す方法を整理しました。

停止条件と手動フォールバックがあっても、その内容を一人しか理解していなければ、運用はまだ安定していません。

• 作った人だけが正常な状態を知っている
• 認証が切れたときの確認先が分からない
• 自動化を止めたあと、どこから手動で再開するか分からない
• どの記録が正本なのか担当者ごとに違う
• 引き継ぎ資料はあるが、長すぎて異常時に読めない
• 資料の手順が現在の画面やフォルダと合っていない

引き継ぎで渡すべきものは、操作の一覧だけではありません。

正常を判断する基準、止める条件、人の手順へ戻る入口、再開を承認する境界まで渡す必要があります。

この記事では、AI、GitHub、デプロイサービスを使う毎日デプロイを題材に、担当者が変わっても判断を失わない引き継ぎ資料を作ります。長い説明書を1冊作るのではなく、役割の異なる5つの資料へ分け、実際に交代できるかを確認します。

引き継ぐのは「操作」ではなく「判断できる状態」

操作だけを渡す資料は、正常時には使えます。

1. フォルダを開く
2. AIへ依頼する
3. プレビューを確認する
4. 公開ボタンを押す

しかし、次のような日には止まります。

AIが対象外のファイルを変更した
プレビューが古いように見える
認証エラーが出た
自動確認は成功だが件数が合わない
公開後に主要画面が開かない

新しい担当者が必要なのは、ボタンの位置ではなく、次の判断材料です。

今日の正常とは何か
何を証拠として確認するか
どこまでなら続行できるか
どの状態なら止めるか
止めたあと誰へ連絡するか
手動で何をすれば最低限の運用を続けられるか
誰が再開を承認するか

引き継ぎ完了の基準を「説明した」ではなく、新しい担当者が資料だけで正常・停止・手動切り替えを判断できたにします。

引き継ぎ資料を5つへ分ける

すべてを1つの長い文書へ入れると、日常の確認と障害対応が混ざります。目的ごとに5つへ分けます。

資料	答える質問	主に使う場面
運用の地図	何がどこにあり、誰が判断するか	初日、全体確認
日次カード	今日何をどの順で確認するか	毎日の作業
異常時カード	何が起きたら止めるか	エラー、違和感
復旧・再開カード	どう戻し、誰が再開を決めるか	修正後
変更履歴	いつ、なぜ、何を変えたか	更新、監査、引き継ぎ

この5つは同じ情報を重複して書くためではありません。

• 地図から各カードへ移動できる
• 日次カードから異常時カードへ移動できる
• 異常時カードから復旧・再開カードへ移動できる
• すべての変更理由を変更履歴へ残す

という導線を作るためです。

1. 運用の地図を1ページで作る

運用の地図は、新しい担当者が最初に読むページです。実装の細部ではなく、全体の境界を書きます。

# 毎日デプロイ 運用の地図

## 目的
- 小さな変更を、安全に確認して毎日公開できる状態を保つ

## 正本
- ソースと変更履歴：GitHub
- 日次記録：docs/operations/daily/
- 手順：docs/operations/runbook/
- 本番状態：デプロイサービスの本番URL

## 通常の流れ
依頼 → AIが下書き → 差分確認 → プレビュー → Human Approval → 公開後確認

## 役割
- AI：収集、整理、下書き、確認候補
- 担当者：差分とプレビューの確認
- 承認者：本番反映、復旧、再開の判断
- GitHub：正本と履歴

## 絶対に自動化しない判断
- 本番公開
- 削除、上書き、復旧
- 権限拡大
- 未確認事項を許容する判断

## 入口
- 今日の作業：日次カード
- 異常がある：異常時カード
- 修正後：復旧・再開カード

地図には、内部構造をすべて書きません。「どこを見れば次の判断ができるか」を優先します。

2. 日次カードは10分以内で読める長さにする

日次カードは、毎日使う最短の手順です。

# 日次カード

## 作業前
- [ ] 今日の目的を1文で書いた
- [ ] 変更対象を3つ以内にした
- [ ] 戻るコミットを確認した
- [ ] 未確認事項を記録する場所を開いた

## 作業中
- [ ] AIの変更対象が依頼範囲内
- [ ] テストまたは確認結果がある
- [ ] 秘密情報と個人情報を含まない
- [ ] プレビューで主要3画面を確認した

## 公開判断
- [ ] 変更内容を説明できる
- [ ] 戻す方法を説明できる
- [ ] 未確認事項を承認者へ示した
- [ ] Human Approvalを得た

## 公開後
- [ ] 本番URLを開いた
- [ ] 主要操作を1回確認した
- [ ] 日次記録を保存した

詳しい説明が必要な項目には、別資料へのリンクを付けます。日次カード自体を長くしません。

チェック項目は「気をつける」ではなく、観察できる文にします。

悪い例：表示に注意する
良い例：スマートフォン幅で見出しとボタンが重ならない

悪い例：差分を確認する
良い例：変更ファイルが事前に決めた3つ以内である

3. 異常時カードは「止める」から始める

異常時は、長い原因調査より先に影響を広げないことが必要です。

# 異常時カード

## 発動条件
- 認証または権限エラー
- 期待件数との不一致
- 対象外ファイルの変更
- 実行済み範囲が不明
- 本番の主要操作が失敗
- 原因を10分以内に説明できない

## 最初に止める
1. 自動公開
2. 自動再実行
3. 上書き、削除、権限変更

## 状態を固定する
- 検知時刻：
- 最後の正常時刻：
- 実行済み：
- 未実行：
- 変更対象：
- エラー：
- 再実行：有 / 無

## 手動へ切り替える
1. GitHubで差分を確認
2. プレビューを人が確認
3. 未確認事項を残す
4. 戻る地点を記録
5. 承認後に限定公開
6. 本番URLを確認

## 連絡
- 一次担当：
- 承認者：
- サービス管理者：

異常時カードには、原因を断定する文章より、現在地を保存する項目を多くします。

4. 復旧と再開を別の判断にする

「直った」と「標準運用へ戻せる」は別です。

復旧・再開カードには、次の門を書きます。

# 復旧・再開カード

## 原因と修正
- 発生したこと：
- 影響範囲：
- 原因：
- 修正内容：
- 変更していない範囲：

## 再開試験
- [ ] 読み取り専用で入力を取得できる
- [ ] テスト用1件で期待結果になる
- [ ] 手動結果と自動結果が一致する
- [ ] 停止条件が働く
- [ ] 元へ戻す方法を確認した

## 再開判断
- 未確認事項：
- 制限付きで再開する範囲：
- 承認者：
- 承認日時：
- 次回確認日：

修正した本人だけで再開を決めない運用にするなら、承認者を先に決めておきます。

小さなチームで同じ人が複数の役割を持つ場合も、「修正作業」と「再開判断」を時間と記録で分けます。一人で運用していても、確認項目を飛ばさないためです。

5. 変更履歴に「理由」と「影響」を残す

手順書は、更新日だけでは変化を追えません。

# 運用資料 変更履歴

## 2026-11-13
- 対象：異常時カード
- 変更：件数不一致を停止条件へ追加
- 理由：成功表示でも対象が1件不足したため
- 影響：自動処理は停止し、手動照合へ切り替える
- 確認：空入力と1件不足で停止することを試験
- 承認：運用担当
- 次回確認：2026-12-13

残す項目は次の7つです。

1. 日付
2. 対象資料
3. 変更内容
4. 変更理由
5. 運用への影響
6. 確認結果
7. 次回確認日

「最新の手順」だけでなく、「なぜそうなったか」が分かると、新しい担当者が安全項目を不要と判断して削除しにくくなります。

正本を1つに決める

引き継ぎ資料が次の場所へ分散すると、どれが最新か判断できません。

担当者のPC
チャットの過去ログ
共有ドライブ
GitHub
デプロイサービスのメモ
AIとの会話

正本を1つ決めます。

手順と変更履歴の正本：GitHub
実行状態の正本：デプロイサービス
公開結果の正本：本番URL
連絡先の正本：組織の連絡先台帳

すべてをGitHubへ入れるという意味ではありません。情報の種類ごとに「最終的にどこを信じるか」を1つにします。

チャットやAIの出力は、検討や下書きには使えますが、引き継ぎの正本にはしません。採用した内容を正本へ反映して初めて運用変更とします。

秘密情報を引き継ぎ資料へ書かない

資料に必要なのは、秘密そのものではなく、保管場所と更新方法です。

書かないもの
- APIキー
- パスワード
- トークン
- 秘密鍵
- 個人情報

書くもの
- 認証情報の保管先
- 管理者
- 利用範囲
- 更新期限
- 再発行の申請先
- 失効時の停止条件

例：

## デプロイサービス認証
- 保管先：組織のパスワード管理サービス
- 管理者：サービス管理者
- 利用範囲：対象プロジェクトのみ
- 期限確認：毎月第1営業日
- エラー時：再認証せず異常時カードを発動

引き継ぎを理由に権限を一括で広げません。新しい担当者が必要な作業を確認し、最小権限を設定します。

「人」「場所」「サービス」が変わる前提で書く

固定された名前や画面位置だけに依存すると、資料がすぐ古くなります。

人

個人名だけでなく役割を書きます。

悪い例：田中さんへ連絡
良い例：本番再開の承認者へ連絡（現在の担当：田中さん）

場所

フォルダ名だけでなく、正本からの経路を書きます。

悪い例：いつものフォルダ
良い例：GitHub正本 / docs / operations / runbook

サービス

ボタンの色や位置ではなく、操作の目的と確認結果を書きます。

悪い例：右上の青いボタンを押す
良い例：本番反映を開始し、対象コミットが一致することを確認する

画面が変わっても、目的と期待結果が残っていれば手順を更新できます。

AIへ引き継ぎ資料の下書きを作らせる

AIは、日次記録や既存手順から情報を整理する作業に使えます。

以下の運用記録と手順から、引き継ぎ資料の下書きを作ってください。

次の5つへ分けてください。
1. 運用の地図
2. 日次カード
3. 異常時カード
4. 復旧・再開カード
5. 変更履歴の初期版

各項目について、元記録への参照を付けてください。
記録にない担当者、権限、保存先、成功条件は推測せず、
「未確認」と表示してください。

APIキー、パスワード、トークン、個人情報は本文へ転記せず、
保管場所を確認する項目へ置き換えてください。

公開、削除、復旧、権限変更、再開承認は自動実行せず、
Human Approvalが必要な判断として分離してください。

AIが作った文書は、そのまま正本へしません。実際の保存先、権限、停止条件、連絡先を人が確認します。

引き継ぎリハーサルをする

引き継ぎ資料は、読んだだけでは検証できません。新しい担当者が実際に使うリハーサルをします。

通常日の試験

新しい担当者が日次カードだけで次を行います。

今日の目的を書く
対象範囲を確認する
差分とプレビューを見る
公開判断に必要な情報を揃える
日次記録を残す

最初は本番公開せず、判断材料を揃えるところまでにします。

異常日の試験

架空の異常を1つ渡します。

自動確認は成功
期待件数は5件
結果は4件
エラー表示なし

新しい担当者が次を判断できるか確認します。

続行せず停止する
結果異常として分類する
自動再実行をしない
現在地を記録する
手動照合へ切り替える
承認者へ連絡する

復旧後の試験

「修正済み」という情報だけを渡し、すぐ本番へ戻さず、読み取り、1件、並行比較、承認へ進めるか確認します。

担当者が迷った場所は、本人の理解不足ではなく、資料の改善候補として記録します。

合格基準を決める

引き継ぎリハーサルの合格基準を観察できる形にします。

10分以内に正本と日次カードを開ける
正常状態を3項目で説明できる
停止条件を3つ示せる
異常時に自動再実行を選ばない
手動フォールバックの入口を開ける
復旧と再開を分けて説明できる
本番反映の承認者を確認できる
秘密情報を資料へ転記しない

一度説明を聞いた記憶ではなく、資料を使って再現できることを合格にします。

引き継ぎの3段階

段階1：見学

現担当者が作業し、新担当者は判断理由を記録します。

段階2：交代

新担当者が操作し、現担当者は公開前の確認だけを行います。

段階3：単独実行

新担当者が資料だけで判断材料を揃え、現担当者へ結果を報告します。

本番公開、復旧、権限変更など影響の大きい操作は、組織の承認ルールに従います。引き継ぎ完了とHuman Approvalの省略を混同しません。

資料を古くしない更新条件

定期更新だけでなく、変更時の更新条件を決めます。

保存場所を変えた
担当者または承認者が変わった
権限範囲を変えた
入力・出力の形式が変わった
停止条件を追加した
手動フォールバックを使った
復旧方法を変えた
デプロイサービスを変えた

変更を実施する作業の完了条件へ、「関連する運用資料を更新した」を入れます。

月次では、次の4点だけでも確認します。

リンクが開く
担当の役割が現状と合う
日次カードを実行できる
異常時カードから手動手順へ移動できる

使われていない資料は、残す目的を確認します。安全境界でなければ統合または廃止します。

よくある失敗

1冊の大きな説明書を作る

日次と異常時の入口が埋もれます。目的別のカードへ分けます。

操作画面の説明だけを書く

画面が変わると使えません。目的、期待結果、停止条件を書きます。

作った本人が横で教え続ける

資料の不足が見えません。リハーサルでは、まず新担当者に資料だけで進めてもらいます。

秘密情報を文書へコピーする

保管場所、管理者、期限、再発行先だけを書きます。

正本を決めない

チャット、ローカル、共有ドライブに最新版が分かれます。情報の種類ごとに正本を1つにします。

復旧できる人だけを育てる

異常を早く見つけ、安全に止め、手動へ切り替えられることも同じくらい重要です。

引き継ぎ完了後に資料を更新しない

担当者交代は完成ではありません。変更履歴と更新条件を標準運用へ入れます。

最初の7日間

1日目

正本、日次記録、本番状態、連絡先がどこにあるかを書きます。

2日目

通常の流れと役割を1ページの運用地図にします。

3日目

毎日使う項目だけを日次カードへまとめます。

4日目

停止条件、状態固定、手動切り替えを異常時カードへまとめます。

5日目

読み取り、1件、並行比較、承認を復旧・再開カードへ書きます。

6日目

新しい担当者役の人が、通常日と異常日のリハーサルを行います。

7日目

迷った場所を修正し、変更履歴と次回確認日を残します。

まとめ

毎日デプロイを引き継ぐとき、渡すのは操作方法だけではありません。正常、停止、手動切り替え、復旧、再開を判断できる状態を渡します。

要点は次のとおりです。

1. 引き継ぎ完了を「説明した」ではなく「資料だけで判断できた」にする
2. 資料を運用地図、日次、異常時、復旧・再開、変更履歴へ分ける
3. 日次カードは短く、観察できる確認項目にする
4. 異常時カードは自動処理を止め、状態を固定するところから始める
5. 復旧と標準運用への再開を分ける
6. 情報の種類ごとに正本を1つ決める
7. 秘密情報ではなく、保管場所と更新方法を渡す
8. 人、場所、サービスが変わる前提で書く
9. 通常日、異常日、復旧後のリハーサルを行う
10. 変更時の資料更新を作業の完了条件へ入れる

最初の一歩は、現在の運用について「正本」「日次カード」「異常時の入口」「再開の承認者」を4行で書くことです。

次回は、この引き継ぎ資料を使っても判断が人によって分かれたとき、判断基準をテストケースへ変換し、担当者が変わっても同じところで止まれるようにする方法を整理します。