「完全自動化」という言葉は魅力的です。寝ているあいだに仕組みが動いて、成果物ができている。そういう状態を目指したくなります。
この記事では、実際に自動化の仕組みを組んで運用した経験から、完全自動化を目指すと続かない理由と、半自動化のちょうどいい線を書きます。
結論を先に書くと、線は「判断が入るかどうか」です。そして、この線を越えて自動化した部分は、例外なく後で直すことになりました。
※本記事は、半自動化の線をどこに引くかという考え方を整理したものです。うまくいかない形も含めて書いています。
完全自動化が続かない、3つの理由
① 例外が必ず出る
自動化は「毎回同じ」を前提に作ります。ところが実務では、毎回同じにならない。
| 想定した流れ | 実際に起きた例外 |
|---|---|
| 依頼が来たら定型で返信する | 依頼ではなく、条件の相談だった |
| 記事を書いて公開する | その日に関連する出来事があり、触れるべきだった |
| 画像を8枚作って動画にする | 混雑で0枚しか取れなかった |
| 集計して結果を送る | 月末で日数が足りず、計算でエラーになった |
例外が出るたびに、仕組みに条件を足すことになります。条件が増えるほど、壊れやすくなり、直すのに時間がかかるようになります。
そして、例外を全部カバーしようとすると、最終的には「人が判断するのと同じ量の指示」を書くことになります。それなら人がやったほうが速い。
② 壊れたことに気づかない
完全自動化の怖さは、壊れることではありません。壊れたのに気づかないことです。
人が間に入る仕組みなら、その人が「今日は動いていない」と気づきます。誰も間に入らない仕組みは、誰も気づきません。
実際にあった例を書きます。画像を生成する処理で、20分間1枚も生成できていないのに、状況としては「生成中」として扱われ続けていました。
処理が動いていることと、前に進んでいることは別です。この2つを区別する仕組みがないと、止まったまま時間が過ぎます。
③ 直すコストが、作るコストより大きい
自動化は、作るときがいちばん楽しい工程です。そして、作ったあとに発生するコストが見えていません。
| フェーズ | 発生すること |
|---|---|
| 作るとき | 設計して動かす。ここは1回 |
| 例外が出たとき | 条件を足す。何度も発生する |
| 使うサービスが変わったとき | 画面や仕様の変更に追随する |
| しばらく使わなかったとき | 何をする仕組みだったか思い出す |
| 壊れたとき | どこが壊れたかを特定する |
最後の行が重いです。複雑な仕組みほど、壊れた場所の特定に時間がかかります。作るのに2時間、直すのに毎回30分、ということが起きます。
線は「判断が入るかどうか」
真ん中の「半自動」が、この記事の主題です。候補を出すところまでを自動にして、選ぶのは人が残す。
なぜ「候補まで」が続くのか
- 例外に強い。変な候補が出ても、人が選ばなければ害がない
- 壊れたら気づく。候補が出てこなければ、選ぶ段階で分かる
- 条件を足さなくていい。例外の処理を人が引き受けるので、仕組みが複雑にならない
2番目が特に効きます。人が間に入ること自体が、監視の仕組みになっています。
実際に引いた線（3つの例）
① メールの返信：下書きまで
返信を自動送信にすることもできますが、下書きを作るところで止めています。
理由は2つ。誤送信が取り消せないこと。そして、削れる時間のほとんどが下書きの段階で出ることです。
| 工程 | 手動 | 下書きあり |
|---|---|---|
| 読む・考える | 90秒 | 50秒 |
| 白紙から書き出す | 90秒 | 0秒 |
| 直す・送信 | 35秒 | 45秒 |
| 合計 | 約3分35秒 | 約1分35秒 |
送信まで自動にして追加で削れるのは、1通5秒です。それとリスクが釣り合いません。詳しい作り方はメール返信をAIに下書きさせるに書きました。
② 記事の制作：構成と初稿まで
テーマを決める工程は自動化していません。ここは毎回違う判断だからです。
そして、事実確認も自動化していません。確認とは「出典に当たって目で照合する」ことなので、それ自体を任せると、確認の正しさを確認することになります。
自動にしているのは、構成の叩き台と初稿だけ。そして、材料の範囲を区切る指示を入れて、確認すべき箇所に印が付いて返るようにしています。
これも半自動です。印を付けるところまでが自動で、当たりに行くのは人。
③ 集計：計算と通知まで
売上と作業時間の集計は自動にしています。毎回同じ計算だからです。
ただし、「結果を見て何をするか」は自動化していません。次にどの工程を削るか、この案件を続けるか。ここは毎回違う判断です。
そして、結果を毎朝メールで送るようにしています。これが「止まったことに気づく仕組み」を兼ねています。メールが来なければ止まっている、と分かる。
止まったことに気づく仕組み
半自動化で、これだけは必ず入れてください。作る労力は1行ぶんです。
入れ方は3種類
| 方法 | やり方 | 向いている場面 |
|---|---|---|
| 結果を送る | 処理が終わったら件数をメールで送る。0件でも送る | 定期実行する仕組み |
| 上限で打ち切る | 一定時間、進捗がなければ明示的に止める | 待ちが発生する処理 |
| 最終更新を書く | 処理した日時を、結果と同じ場所に書き込む | 数字だけ見る仕組み |
1つめの「0件でも送る」が要点です。0件のときに何も送らない設計にすると、止まっているのか対象がなかったのか区別がつきません。
実際に7分で打ち切るようにした話
画像を生成する処理で、ある回に20分待って0枚、次に約10分待って0枚、その次は3枚取れたところで15分止まるということが起きました。同じ壁に3回ぶつかっています。
表面的な原因は混雑ですが、3回も繰り返した理由は別でした。「どれくらい待ったら諦めるか」を決めていなかったことです。
いまは、1枚も取れないまま7分経ったら明示的に処理を止めるようにしています。止まったとわかれば、時間帯を変えるという判断ができます。
この記録はAIショート動画で副業する手順に詳しく書きました。
半自動と完全自動を、コストで比べる
言葉で「続かない」と言っても伝わりにくいので、かかる時間で比べます。同じ作業を1年間続けた場合の想定です。
| 項目 | 完全自動 | 半自動 |
|---|---|---|
| 作るとき | 6時間（例外処理を含む） | 2時間 |
| 例外が出たときの対応 | 条件を足す（30分×年10回） | 人が判断する（2分×年10回） |
| 仕様変更への追随 | 2時間×年2回 | 30分×年2回 |
| 壊れた場所の特定 | 1時間×年3回 | 10分×年3回（人が気づく） |
| 日々の人の作業 | 0分 | 1分×年250回 |
| 年間の合計 | 約22時間 | 約8時間 |
完全自動のほうが「日々の人の作業」はゼロですが、それ以外の項目が全部大きいので、合計では逆転します。
この表の数字は、扱う作業によって変わります。ただ、構造は変わりません。完全自動は、作るコストと直すコストを前借りしているだけです。
逆転しない場合もある
正直に書いておくと、完全自動のほうが合計で安くなる条件もあります。
- 実行回数が桁違いに多い（1日に何百回も動く）
- 例外がほとんど出ない（入力の形が完全に決まっている）
- 出力の正しさを機械的に判定できる（人が見なくても分かる）
この3つが揃うなら、完全自動にする価値があります。副業の規模では、1つめの条件がまず揃いません。1日に数回の処理なら、人が1分見る形で十分です。
半自動化を、どの順で作るか
一度に全部作らないでください。この順番が、いちばん壊れにくく、いちばん早く効果が出ます。
第1段階：記録だけ自動にする（1時間）
まず、どの工程が長いかを見えるようにします。ここを飛ばすと、自動化する場所を間違えます。
集計を自動にする手順はスプレッドシートの集計をAIに任せるに書きました。1時間で作れます。
第2段階：いちばん長い工程を、候補出しまで自動にする（1〜2時間）
記録を見て、いちばん長い工程を1つ選びます。そして、その工程の「候補を出すところまで」を自動にします。
完成品を作らせないでください。候補です。選ぶのは人。
第3段階：止まったことに気づく仕組みを足す（10分）
第2段階を作った直後に、必ず入れてください。後回しにすると、止まったときに気づけません。
10分で終わります。そして、これを入れていない仕組みは、いつか必ず静かに止まります。
第4段階：1か月使って、例外を数える（0分）
作業そのものは発生しません。1か月使って、「自動の結果をそのまま使えなかった回数」を数えるだけです。
| 例外の割合 | 判断 |
|---|---|
| 1割以下 | うまく設計できている。次の工程に進む |
| 2〜3割 | 条件を1つ足すか、渡す材料を変える |
| 半分以上 | その工程は、まだ人がやる工程。いったん外す |
最後の行の判断ができるかどうかが、続くかどうかを分けます。作った仕組みを外すのは失敗ではありません。「その工程には判断が入っていた」と分かった、という成果です。
半自動化の「候補の出し方」を設計する
「候補を出すところまで自動」と書きましたが、候補の出し方にも良し悪しがあります。選ぶ時間が長くなる出し方は、失敗です。
候補は3つまで
10個出されると、選ぶのに時間がかかります。しかも、選択肢が多いほど決められなくなります。
指示に「3案まで」と入れてください。それで足りなければ、出し直せばいい。最初から10個もらうより速く終わります。
選ぶ基準を、候補と一緒に出させる
候補だけ並んでいると、比べるための軸を自分で考えることになります。これが時間を食います。
3案出してください。それぞれについて、「どういう読者に向いているか」を1行で添えてください。
この一文で、選ぶ作業が「読んで決める」から「軸を見て選ぶ」に変わります。体感で半分くらいになります。
「そのまま使えない」を前提に出させる
完成品として出させると、直すときに全体を書き直すことになります。叩き台として出させると、部分的に直せます。
頼み方の違いはこうです。
| 頼み方 | 返ってくるもの | 直しやすさ |
|---|---|---|
| 「完成させてください」 | 整った文章 | 直すと全体が崩れる |
| 「叩き台を作ってください」 | 要素が並んだ状態 | 部分的に入れ替えられる |
| 「箇条書きで案を出してください」 | 選べる形 | いちばん扱いやすい |
下にいくほど、半自動に向いています。整いすぎたものを受け取ると、直す気力のほうが削られます。
やってはいけない3つ
① 複数の仕組みを同時に作る
1か月に1つです。2つ作ると、どちらも中途半端になり、壊れたときにどちらが原因か分かりません。
② 動いている仕組みを、理由なく変える
「もっと良くできそう」で触ると、壊れます。そして、変える前の状態に戻せないことがあります。
変えるなら、記録を見て「この工程がまだ長い」という理由があるときだけ。そして、変える前の状態を残しておいてください。
③ 判断の工程を「たぶん大丈夫」で自動にする
いちばん多い失敗です。「この判断、だいたい同じだから自動でいけそう」と思った工程は、だいたい同じであって、毎回同じではありません。
この「だいたい」の部分が、あとで全部跳ね返ってきます。
作った仕組みを、月1回だけ点検する
半自動化した仕組みは、放っておくと静かに劣化します。月1回、10分だけ見る日を決めてください。
見るのは3つ
| 確認 | やり方 | 該当したら |
|---|---|---|
| 動いているか | 通知メールが今月も届いているか | 届いていなければ、実行の記録を見る |
| 使っているか | 出力をそのまま使った回数を思い出す | 使っていないなら、外す候補 |
| 例外が増えていないか | 直した回数が先月より多いか | 増えているなら、前提が変わった |
2つめが大事です。動いているけれど使っていない仕組みが、いちばん厄介です。壊れても気づかず、しかも「ある」という安心感だけが残ります。
使っていない仕組みは、止める
止めることに抵抗があるかもしれませんが、動いている仕組みが多いほど、点検のコストが増えます。
5つの仕組みを持っていて3つしか使っていないなら、2つ止める。点検が10分から6分になります。
そして、コードやファイルは消さずに残しておいてください。また必要になったときに、作り直さずに戻せます。
前提が変わったサインを見逃さない
例外が増えたときは、仕組みが壊れたのではなく作業の前提が変わっていることがあります。
扱う案件の種類が変わった。依頼主が増えた。納品の形式が変わった。この場合、条件を足して対応するより、いったん外して作り直すほうが速いことがあります。
「今の仕組みを直す」と「今の作業に合わせて作り直す」は別の選択肢です。月1回の点検で、後者を選べるかどうかを見てください。
まとめ
完全自動化を目指すと続かない理由は3つです。
- 例外が必ず出る。カバーしようとすると、人が判断するのと同じ量の指示を書くことになる
- 壊れたことに気づかない。人が間に入らない仕組みは、誰も止まりに気づかない
- 直すコストが、作るコストより大きい。複雑な仕組みほど、壊れた場所の特定に時間がかかる
線は「判断が入るかどうか」です。毎回同じ手順は自動化していい。毎回違う判断は自動化しない。その中間が、候補を出すところまで自動にして、選ぶのは人が残す半自動です。
作る順番は、記録の自動化 → いちばん長い工程の候補出し → 止まったことに気づく仕組み → 1か月使って例外を数える。
そして、例外が半分以上出る工程は、いったん外してください。外すのは失敗ではなく、「そこには判断が入っていた」と分かった成果です。
よくある質問
完全自動化が成立する作業もあるのでは？
あります。入力の形が決まっていて、出力の正しさが機械的に判定できる作業なら成立します。決まった形式のファイルを変換する、決まった条件で並べ替える、といったものです。
この記事で「続かない」と書いたのは、出力の良し悪しを人が判断する作業についてです。文章、画像、返信の内容。ここは判断が入るので、完全自動化すると例外に負けます。
「止まったことに気づく仕組み」が面倒です
1行で足ります。コードを書かせるときに「処理が終わったら件数をメールで送ってください。0件のときも送ってください」と足すだけです。10分もかかりません。そして、これを入れていない仕組みは、いつか静かに止まって、気づいたときには数週間経っています。
例外を数えるのが面倒です
正の字で足ります。作業記録のメモ欄に「自動の結果をそのまま使えなかった」と1文字書くだけです。1か月で何回あったかが分かれば十分で、正確な数は要りません。感覚で「けっこうある」と思っていたものが、数えると月2回だったということもあります。逆もあります。
作った仕組みを外すのは、もったいなくないですか？
作った時間は戻りませんが、使い続けるコストのほうが大きいことがあります。例外が半分以上出る仕組みは、毎回「今回は使えるか」を判断する手間が発生します。それなら最初から人がやったほうが速い。
そして、外しても学びは残ります。「その工程には判断が入っていた」という発見は、次に自動化する場所を選ぶときに効きます。
半自動だと、結局人の時間が要りますよね
要ります。ただ、減る量が大きいのは「作る時間」で、残るのは「選ぶ時間」です。メールの例だと、書き出す90秒がゼロになって、選んで直す時間が残る。1通2分減りました。
「人の時間をゼロにする」ではなく、「人がやるべき部分だけを残す」。これが半自動の目的です。
どこまで作れば「十分」ですか？
記録を見て、いちばん長い工程が「判断が入る工程」になったら、そこが一区切りです。それ以上は自動化しても、直すコストのほうが大きくなります。
そのあとは、仕組みを増やすより、作業そのものの質を上げるほうに時間を使ってください。