毎日残る作業を自動化する前に――AIへ任せる・人が続ける・やめるを決める基準
毎日デプロイの記録を見える化すると、操作盤を改善しても残り続ける作業が見つかります。
- 毎回、同じファイル一覧をAIへ渡す
- プレビューURLを開き、同じ3画面を見る
- デプロイ履歴から対象の変更を探す
- 公開後に正常操作を1回試す
- 日次記録を同じ書式へ整理する
- 週末に時間、確認漏れ、やり直しを集計する
同じ作業が毎日続くと、「ここは全部自動化したい」と考えます。
しかし、繰り返し作業だから自動化に向いているとは限りません。
判断基準が明確な集計は自動化しやすい一方、本番反映の承認や利用者への影響判断は、人が持つ方が安全です。また、目的を失った記録や誰も使わない集計は、自動化するのではなく、やめる方がよい場合があります。
そこで私は、残った作業を次の3つへ分けます。
- AIや仕組みに任せる
- 人が続ける
- やめる
この記事では、非エンジニアでも判断できるように、頻度だけでなく、ルールの明確さ、失敗時の影響、戻しやすさ、Human Approval、維持費まで含めて整理します。
「面倒」と「自動化できる」は別
面倒な作業ほど自動化したくなります。しかし、面倒さは自動化可能性の証拠ではありません。
たとえば「本番公開してよいか判断する」は、毎日発生し、時間もかかる作業です。それでも、次の事情が日によって変わります。
- 変更範囲
- 利用者への影響
- 未確認事項
- 復旧可能性
- 公開時刻
- 関係者の承認
この判断を「テストが緑なら自動公開」という一つの条件へ縮めると、テストで見ていない問題を通す可能性があります。
反対に、5日分の日次記録から合計時間を抜き出し、短い順に並べて中央の値を出す作業は、入力と計算規則が明確です。
自動化したい気持ちではなく、入力と判断規則を固定できるかから考えます。
まず4種類へ分ける
作業名だけで判断せず、役割を4種類へ分けます。
| 種類 | 例 | 自動化の考え方 |
|---|---|---|
| 収集 | ファイル一覧、時間、履歴を集める | 自動化しやすい |
| 変換 | 表、要約、分類、書式統一 | AIへ任せやすい |
| 確認 | URLを開く、操作する、差分を見る | 条件を限定して支援 |
| 判断 | 公開、停止、復旧、削除、承認 | 人が持つ |
収集
元データを変えずに集める作業です。
GitHubの変更ファイル一覧を取得する
日次記録から作業時間を抜き出す
公開URLと確認日時を一覧にする
読み取り専用で、失敗しても元データへ影響しにくいため、最初の自動化候補です。
変換
集めた情報を別の形へ整えます。
5日分を週次表へまとめる
確認漏れの理由を分類する
変更概要を3行に要約する
AIが得意な領域ですが、要約漏れや誤分類があります。元記録へ戻れるようにし、提案として出力させます。
確認
期待結果と実際を比べる作業です。
リンクがHTTP 200か確認する
画面に文字の重なりがないか見る
正常入力と空欄を試す
機械的な確認は自動化できますが、「利用者にとって分かりやすいか」は人の判断が必要です。確認項目を分割します。
判断
結果をもとに、次の行動を決めます。
本番へ反映する
自動デプロイを止める
正常地点へ戻す
未確認のまま公開するか保留する
手順から安全項目を削除する
影響が大きく、状況依存のため、Human Approvalを残します。
自動化候補を6つの質問で評価する
各作業に、次の6つを確認します。
Q1. 入力を毎回同じ形式にできるか
Q2. 正解または合格条件を説明できるか
Q3. 失敗しても元データや本番を壊さないか
Q4. 実行結果を人が短時間で確認できるか
Q5. 元へ戻す方法があるか
Q6. 自動化を維持する費用より、減らせる負担が大きいか
6つすべてが「はい」なら、小さな自動化を検討できます。
1つでも「いいえ」がある場合、直ちに自動化禁止という意味ではありません。自動化する範囲を狭めます。
例：
本番公開を自動化する
→ 失敗時の影響が大きい
変更ファイル一覧とテスト結果の収集だけ自動化する
→ 人が結果を見て公開を承認する
自動化の単位を、最終判断ではなく判断材料の準備へ縮小します。
失敗時の影響を4段階で見る
頻度が高くても、影響が大きい作業は慎重に扱います。
| 影響 | 例 | 基本方針 |
|---|---|---|
| 小 | 集計表の作成失敗 | 自動化を試しやすい |
| 中 | 確認候補の漏れ | 人が元記録と照合 |
| 大 | 本番への誤反映 | Human Approval必須 |
| 重大 | データ消失、秘密情報公開 | 自動実行しない |
小
再実行すればよく、元データが変わらないものです。
中
AIの要約や分類が誤り、判断材料が不足する可能性があります。出典リンクや元記録を一緒に表示します。
大
利用者が触る本番状態へ影響します。自動処理は準備までに留め、実行前に人が確認します。
重大
削除、上書き、秘密情報、個人情報、課金、外部送信などです。自動化しないか、専用の安全設計と承認を別途用意します。
「毎日5分かかる」という理由だけで、重大な作業を自動化しません。
3つの行き先を決める
AIや仕組みに任せる
次を満たす作業です。
- 入力が揃っている
- 手順が繰り返せる
- 合格条件が観察できる
- 失敗しても戻せる
- 結果を人が確認できる
- 頻度または負担が十分に大きい
例：
日次記録から週次表を作る
画像URLがHTTP 200か確認する
記事タイトルと先頭見出しを比較する
変更ファイルを許可範囲内・範囲外へ分ける
人が続ける
状況依存で、責任を伴う作業です。
- 利用者への影響を判断する
- 未確認事項を許容するか決める
- 本番反映を承認する
- 復旧を実行する
- 秘密情報や個人情報の境界を決める
- AIの提案を採用・修正・却下する
AIは材料を整理できますが、決定者にはしません。
やめる
次に当てはまる作業です。
- 4週間記録したが一度も判断に使わない
- 同じ情報が別の正本にある
- 誰も結果を読んでいない
- 目的がなく「以前からある」だけ
- 維持費が効果を上回る
- 自動化しても利用者価値が増えない
やめることは失敗ではありません。不要な作業を高速化するより効果があります。
「やめる」前にも安全確認が必要
使っていないように見える手順が、安全境界である場合があります。
たとえば、復旧カードは問題がない週には使いません。Human Approvalも自動チェックの件数には現れません。
次の項目は、利用回数だけで削除しません。
本番反映前の人間承認
秘密情報の確認
最後の正常地点の記録
削除・上書きの停止条件
復旧後の公開URL確認
やめる前に質問します。
この作業は、低頻度だが大きな事故を防いでいないか
別の手順が同じ境界を守っているか
削除したあと、誰が何を判断できなくなるか
問題時に復活させる方法があるか
安全境界ではないと確認できてから外します。
費用対効果を「時間だけ」で見ない
自動化による節約時間を計算します。
1回の作業：5分
週5回：25分
月4週：約100分
一方、自動化には次の費用があります。
最初の設計と実装
テスト
権限設定
エラー対応
仕様変更への追従
ログ確認
引き継ぎ文書
例：
月100分を減らすために、初期構築8時間
毎月の保守1時間
この場合、時間だけではすぐに元を取れません。
ただし、確認漏れを減らし、重大な失敗を早く検出できるなら、時間以外の価値があります。
評価軸を4つにします。
| 軸 | 質問 |
|---|---|
| 時間 | 毎月何分減るか |
| 品質 | 漏れ、ばらつき、転記ミスが減るか |
| 安全 | 失敗を早く止め、戻しやすくなるか |
| 維持 | 誰が直し続けられるか |
4つを見て、導入する価値を判断します。
AIへ任せる最初の範囲
最初は、読み取りと提案だけにします。
日次記録を読む
→ 時間・漏れ・やり直しを抽出
→ 週次表の案を作る
→ 元記録への参照を付ける
→ 人が確認して保存する
次に、影響の小さい書き込みへ広げます。
新しい集計ファイルを作る
既存ファイルは上書きしない
公開や送信はしない
本番への反映、削除、復旧、外部公開は最後まで人間承認を残します。
自動化の試験を5段階にする
段階1：観察
作業を変えず、頻度、時間、失敗、入力、出力を記録します。
段階2：提案
AIへ手順案や集計結果を作らせます。ファイルや外部サービスは変更させません。
段階3：下書き
新しいファイルや下書きだけを作ります。既存の正本は更新しません。
段階4：限定実行
対象、件数、時間、権限を限定して実行します。
対象：テスト用データ1件
回数：1回
書き込み先：新規ファイル
外部公開：なし
停止条件：予想外の変更が1件でもある
段階5：標準化
成功条件、失敗時の停止、確認、復旧、担当を文書化して毎日の操作盤へ組み込みます。
一度成功しただけで段階5へ進みません。異常入力や空データでも安全に止まるか確認します。
自動化候補カードを作る
1件につき1枚、次の書式で判断します。
# 自動化候補：週次記録の集計
## 現在
- 頻度：週1回
- 所要時間：25分
- 入力：5日分の日次Markdown
- 出力：週次レビュー表
- やり直し：月2回。転記漏れ
## 6つの質問
- 入力固定：はい
- 合格条件：はい
- 元データ非破壊：はい
- 人が確認可能：はい
- 戻せる：はい
- 維持費に見合う：条件付き
## 失敗時の影響
- 中。集計漏れで判断材料が不足する
## 方針
- AIが下書きを作り、人が元記録と照合して保存
- 正本の上書き、外部公開は行わない
## 2週間後の確認
- 所要時間
- 転記漏れ
- 人の確認時間
「自動化する」と決めるだけでなく、どこまで任せるかを書きます。
具体例1：週次集計
判定
AIへ任せる。
理由
入力書式、抽出項目、出力表が決まっており、元記録を変更せず下書きを作れます。
人が残す作業
- 元記録との照合
- 改善候補の優先順位
- 安全項目の削除判断
- 来週変える1件の承認
具体例2：公開URLの基本確認
判定
一部を自動化し、一部は人が続ける。
自動化する部分
- URLへ接続できる
- HTTP状態
- 必須の文字列がある
- 画像が読み込める
人が続ける部分
- 内容が利用者に分かりやすい
- スマートフォンで操作しやすい
- 変更の価値が届いている
- 公開を続けてよい
機械的な到達確認と、利用者視点の判断を分けます。
具体例3：本番公開
判定
人が続ける。
AIへ任せる準備
- 変更概要
- 変更ファイル一覧
- テスト結果
- プレビューURL
- 未確認事項
- 戻るコミット
人が判断すること
- 本番へ進む
- 保留する
- 範囲を縮める
- 復旧条件を追加する
公開操作が技術的に自動化できても、Human Approvalは外しません。
具体例4：誰も読まない日次項目
判定
やめる。
確認
4週間、判断に使われず、別の正本に同じ情報があり、安全境界でもないことを確認します。
自動転記を作るのではなく、記録項目から外します。
AIへ判断材料を作らせる依頼文
以下の作業記録から、繰り返し発生する作業を抽出してください。
各作業について、次を整理してください。
1. 頻度と所要時間
2. 入力と出力
3. 判断規則の明確さ
4. 失敗時の影響
5. 元へ戻す方法
6. 人が確認できる証拠
7. 維持に必要な作業
「AIへ任せる」「人が続ける」「やめる」の候補を示してください。
ただし、公開、削除、上書き、秘密情報、復旧、Human Approvalは
自動化対象へ決めず、判断が必要な項目として分けてください。
記録にない情報は推測しないでください。
AIの分類は決定ではありません。候補カードの下書きとして使います。
2週間の試験計画
1〜5日目：観察
対象作業の時間、入力、出力、例外、やり直しを記録します。
6日目：提案だけ作る
AIに自動化手順と停止条件を提案させます。実行しません。
7日目：1件で下書き
テスト用データから、新規ファイルへ結果を作ります。
8〜12日目：人の作業と並行比較
自動化結果と手作業の結果を比べます。
13日目：例外を試す
空データ、項目不足、形式違いで安全に止まるか確認します。
14日目：標準化・保留・中止を決める
次のどれかを選びます。
標準化：効果と安全性を確認できた
条件付き：対象を限定して使う
保留：証拠が不足している
中止：維持費や影響が大きい
よくある失敗
頻度だけで選ぶ
毎日行う作業でも、判断が複雑で影響が大きければ、人が持つ方がよい場合があります。
自動化の維持を数えない
作って終わりではありません。仕様変更、認証、エラー、引き継ぎが発生します。
最終操作まで一括で任せる
収集、変換、確認、判断を分け、まず判断材料の準備だけを任せます。
1回の成功で標準化する
空入力、形式違い、接続失敗でも安全に止まるか確認します。
不要な作業を自動化する
目的を確認し、使われていないならやめる選択肢を持ちます。
Human Approvalを遅さとして扱う
承認は、責任と影響を人が確認する安全境界です。省略せず、判断材料の準備を速くします。
まとめ
毎日残る作業を見つけても、すぐに全部を自動化しません。
収集、変換、確認、判断へ分け、入力、合格条件、失敗時の影響、戻しやすさ、確認方法、維持費を見て、最小範囲から試します。
今回の要点は次のとおりです。
- 面倒さではなく、入力と判断規則を固定できるかを見る
- 作業を収集、変換、確認、判断へ分ける
- 失敗時の影響が大きいほどHuman Approvalを残す
- AIへ任せる・人が続ける・やめるの3つを選ぶ
- 時間、品質、安全、維持の4軸で費用対効果を見る
- 観察、提案、下書き、限定実行、標準化の順で広げる
- 最初は読み取りと判断材料の準備だけを任せる
- 不要な作業は、自動化せずやめる
最初の一歩は、今週最も繰り返した作業を1つ選び、「入力」「出力」「合格条件」「失敗時の影響」を4行で書くことです。
次回は、小さな自動化を標準運用へ入れたあと、失敗、権限切れ、仕様変更を検知し、人の作業へ安全に戻す方法を整理します。