「たぶん、どこかで止まっている」
AIで仕事を自動化していると、こういう日が出てくる。
でも実際に見ると、止まっていないこともある。
別の時間に動いていたり、ログの保存場所が違っていたり、古い仕組みがまだ残っていたりする。
今日の作業場では、毎日の自動化レーンを棚卸しして、担当、時刻、正本、ログの場所を1枚の地図に寄せ直していた。
そこで改めて思った。
AI自動化は、増やす前に「どこを見るか」を決めないと、あとで人間が迷子になる。
動いていない、と思った
AIの自動化は、最初の1本だけなら分かりやすい。
毎朝この処理が走る。
終わったらここにファイルができる。
失敗したらこのログを見る。
このくらいなら、頭の中でも追える。
でも、便利だからといって少しずつ増やしていくと、すぐに見え方が変わる。
- 朝に記事を作る仕組み。
- 夜に数字を集める仕組み。
- 返信を待って動く仕組み。
- サイトの回遊リンクを足す仕組み。
- 別の場所で予約投稿する仕組み。
それぞれは小さくても、合計すると「今、何がどこで動いているのか」が分からなくなる。
この状態で何かが届かないと、人間はすぐに不安になる。
「壊れた？」
「止まった？」
「昨日の変更が悪かった？」
でも、ここでいきなり直そうとすると危ない。
止まっているのか、見に行く場所を間違えているだけなのかを分けないまま直すと、動いているものまで壊す。
AI自動化で怖いのは、失敗そのものよりも、失敗の見え方が散らばることだと思う。
実はログの場所が違った
今回の棚卸しで見えた大きな学びは、ログの場所だった。
自動化の設定ファイルにはログの場所が書いてある。
だから普通は、そこを見れば状態が分かると思う。
でも実際の運用では、そう単純ではない。
設定ファイルに書いてあるログは空。
本当に見るべきログは、別のフォルダにある。
昔のログだけが残っていて、今の状態を表していない。
こういうことが起きる。
それ自体は珍しくない。
あとから直したり、別のツールを挟んだり、古い仕組みを残したまま新しい仕組みに移ったりすると、ログの置き場はずれやすい。
問題は、そこが正本に書かれていないこと。
「この自動化はどの時刻に走る」
「この担当が動かす」
「正しい仕様書はこれ」
「失敗時に見るログはここ」
この4つが揃っていないと、トラブル時に人間は推理を始めてしまう。
推理が必要な自動化は、長期運用に向いていない。
人間が疲れている日に必要なのは、賢い説明ではなく、次に見る場所が分かる地図。
AIに任せる部分が増えるほど、人間側の確認場所は単純にしておいた方がいい。
自動化の地図を作る
今回の整理で効いていたのは、技術的にすごい仕組みではなく、地図だった。
1枚の表に、レーンごとに次の情報を並べる。
- いつ動くか：毎朝なのか、5分ごとなのか、週1なのか。
- 何を作るか：記事なのか、動画なのか、通知なのか。
- どの正本に従うか：仕様が混ざらないように、入口を1つにする。
- どこを見れば分かるか：成果物とログの場所を明記する。
これだけで、かなり迷いが減る。
特に大事なのは、レーンを混ぜないこと。
ブログを書く仕組み。
動画を作る仕組み。
漫画を作る仕組み。
通知を送る仕組み。
全部AIが関わっていても、目的は違う。
目的が違うものは、ネタ元も、正本も、停止条件も違う。
ここを曖昧にすると、ブログのために動画の在庫を読んだり、通知の問題を記事制作の問題として扱ったりする。
それは、AIが悪いというより、人間が渡した地図が悪い。
AIは、境界が書かれていない仕事を、親切に混ぜてしまう。
だから、混ぜてほしくないところほど、地図に太く線を引く。
増やす前に、見る場所を決める
自動化を作っていると、つい「次に何を自動化するか」を考えたくなる。
でも、ある程度まで増えたら、先にやることは別になる。
新しい1本を足す前に、今あるものを見渡す。
そして、止まった時の確認順を決める。
たとえば、こんな順番でいい。
- 今日の成果物はできているか。
- そのレーンの正本はどれか。
- 実ログはどこか。
- 最後に成功した時刻はいつか。
- 人間の承認待ちなのか、機械の失敗なのか。
これが決まっているだけで、トラブル時の初動が変わる。
「なんとなく壊れた気がする」から、「まずここを見る」に変わる。
AI自動化は、作る瞬間よりも、翌週、翌月に効いてくる。
その時に大事なのは、かっこいい構成図ではなく、普通の日に見返せる運用地図だと思う。
私は今日、自動化の数そのものよりも、「どこを見れば状態が分かるか」の方が大事だと感じた。
自動化を増やす前に、止まった時に人間が迷わない地図を作る。