小さい自動化をAIに作らせるときの現実：量産と保守

「これ、自動でやってくれる小さいスクリプトが欲しい」とAIに頼むと、今は数分で動くものが返ってきます。通知を1か所に集約する、決まった形式かどうかをチェックする、ファイルをルールで振り分ける。自分でゼロから書いていた頃と比べると、作るコストは桁違いに下がりました。

ただ、作った直後は気持ちよくても、数か月経つと景色が変わります。頼りにしていた自動化が、いつの間にか止まっている。あるいは、自分で作ったはずなのに中身がどうなっているか思い出せない。作るコストが下がった分、別のコストが目立ってきた、というのがここ最近の実感です。

下がったのは「作るコスト」だけ

自動化にかかる手間は、作る場面だけではありません。むしろ作った後が長い。

• 外部サービスのAPIや画面の仕様が変わって、ある日突然動かなくなる
• エラーで止まっているのに、成功しているものと見分けがつかない
• 作ったときの自分は覚えていても、半年後の自分は覚えていない。まして頼んだ相手がAIだと、中身を「読んだ」記憶すら曖昧です

作るコストが下がると、つい「とりあえず作る」の判断が軽くなります。でも判断が軽い分だけ、面倒を見る対象が増えていく。ここが量産時代の自動化の落とし穴だと思っています。

「壊れたら、またAIに直させればいい」というのは半分だけ正解です。エラーの内容を渡せば修正案は返ってきます。ただ、直した変更が本当に正しいかはテストの質に左右されます（AIにテストを書かせるときの注意点）。でも、そもそも壊れたことに気づくこと、そして「直す価値があるか、もう要らないのではないか」を判断すること。この2つは自動化の外側に残ります。保守の手間の本体は、じつはこちら側です。

向く自動化、向かない自動化

全部を自動化しない、という線引きは必要です。この考え方は、AIに任せる作業・任せない作業の線引きで整理したものと地続きです。自分が目安にしているのは、実行の頻度と失敗したときの被害の2つです。頻度が高くて失敗しても被害が小さいものは自動化向き。逆に、失敗時の被害が大きいものは、頻度が高くても人が関わった方が結果的に安くつきます。

自動化の例	向き	理由
通知を1か所に集約する	向く	壊れても「通知が来ない」だけで済み、手作業に戻れる
定型フォーマットのチェック	向く	間違えても下書きの段階で人が気づける
ファイルの振り分け・リネーム	条件付き	ルールが単純なら向く。削除を伴い始めると話が変わる
外部サービスへの自動送信・投稿	微妙	仕様変更で壊れやすく、失敗が外に漏れる
お金や予約、対外連絡が絡む処理	向かない	失敗時の被害が大きく、確認する人がいた方が速い

もう1つ、見落としがちなのが頻度です。月に1回しかやらない作業は、手順を覚えるコストより自動化を保守するコストの方が高くつくことがあります。「面倒くさい」と「自動化した方が得」は、意外と一致しません。

被害の大きさを考えるときは、「止まる」ことと「間違って動き続ける」ことを分けて考えます。止まるだけならまだ親切な方で、厄介なのは、古いルールのまま処理を続けたり、間違った内容を送り続けたりするケースです。後者があり得るものほど、自動化のハードルは上げた方がいい。

壊れたときに気づけるか

スクリプトは、静かに壊れます。画面のあるアプリと違って、止まっていても誰も文句を言ってくれません。自動化が本当に怖いのは、壊れること自体より、壊れたことに気づけない期間が長引くことです。

なので、作るときは本体より先に「気づく仕組み」を決めます。失敗したらいつもの通知先にエラーを飛ばす。定期実行の結果は、成功・失敗を問わず目に入る場所に残す。凝った監視は要りません。要は、自分が普段見ている場所に「止まっています」のサインが出ればいい。

もう1つ効くのが、「成功の証跡」を残すことです。失敗通知だけに頼ると、通知が来ない理由が「成功しているから」なのか「通知の仕組みごと止まっているから」なのか区別できません。実行のたびに日時と結果を1行残しておけば、証跡が途切れたこと自体が異常として見えるようになります。地味ですが、この差は実際に効きます。

作るときの原則：自動化は「正しく動くこと」より先に「壊れたら分かること」を作る。気づけない自動化は、無い方がまだましです。

棚卸しの習慣：一覧を1枚持つ

作るコストが下がると、自動化の数は自然に増えます。増えた分だけ効いてくるのが棚卸しです。やっているのは単純で、「何を作ったか」の一覧を1枚持つだけです。

一覧には、名前、何をしているか、どこで動いているか、止め方、の4つを書きます。大した手間ではありません。でもこれが無いと、止めたいときに止め方が分からない、似たものを二重に作る、そもそも存在を忘れる、といったことが普通に起きます。AIに作らせる場合ほど、この一覧は効きます。生成が速い分、忘れるのも速いからです。

作った日も書いておくと、寿命の判断がしやすくなります。何か月も触っていない自動化は、大抵もう自分の生活や仕事の流れから外れています。逆に、長く残っているものはそれだけ役に立っている証拠でもある。棚卸しは管理作業というより、自分の自動化の使い方を眺め直す時間だと思っています。

棚卸しのついでに、「もう使っていないもの」を消す判断もここでします。自動化は作るより捨てる方が難しい。動いているものを止めるのには勇気が要りますが、一覧の上で定期的に見直すと、判断はだいぶ楽になります。

作る前に決めること

最後に、AIに作らせる前に自分の中で決めていることを、チェックリストの形で置いておきます。

• 終了条件は何か（いつ・どうなったら捨てるか）
• 保守するのは誰か（基本的には未来の自分。その自分が読んで分かる作りか）
• 失敗したとき、どこに通知が届くか
• 壊れたとき、手作業に戻る手順があるか
• 作ったら「何を作ったか」の一覧に1行足したか

どれも作る前の数分で決められることばかりです。逆に、作った後だと決めるのが面倒になるものばかりでもあります。

おわりに

AIのおかげで、自動化は「作れるかどうか」ではなく「いくつ飼えるか」の問題になりました。作ること自体はこれからも頼っていくつもりです。ただ、増やすペースと同じくらい、壊れたら気づけることと、捨てる判断の仕組みを持っておくこと。その2つがあるかどうかで、量産した自動化が資産になるか、静かに腐っていくかが分かれる気がしています。