AI自動化の裏側は、派手な魔法より地味な設計だった

AIで事業を自動化してると言うと、なんか派手なことをやってるように聞こえる。でも実態はかなり地味で、ほとんどは「この条件のときはこっち、失敗したらこう」という設計の積み重ねだ。魔法みたいなものは、ほぼない。

自動化の9割は「場合分け」だった

最初に仕組みを作り始めたとき、AIが賢いんだから任せておけばいい、と思ってた。実際にやってみると、そうはいかなかった。

たとえばメールの仕分けと返信の自動化を組んだとき、「普通のお問い合わせ」は動くんだけど、少しイレギュラーな内容が来た瞬間に処理が止まるか、的外れな返信が飛ぶ。

AIの出力がそもそも想定外のフォーマットで返ってきて、次のステップが受け取れない、みたいなことも頻繁にあった。

結局、フローを整理するたびに「このケースはどうする？」という場合分けが増えていく。例外処理、エラー時の通知、人間に回す条件の定義。地味にそればかりやってる感覚がある。

仕組みを回し始めて気づいたのは、うまくいくケースより、うまくいかないケースの設計の方が大事だということだ。

自動化が止まっても気づかない、というのが一番まずい。だから今は「エラーが出たら自分に通知が来る」というのをまず作る。

完璧に動くフローより、壊れたら教えてくれるフローの方が、実運用では全然ましだと思ってる。

あと、完全自動にしようとしすぎると逆にコストがかかる。判断が難しいところは人間が確認するステップを残して、単純なところだけ自動にする。

その切り分けを丁寧にやる方が、長続きする仕組みになる気がしてる。

どのAIを使うか、どのツールを組み合わせるか、という話はよく見る。でも個人的には、そこより「何を自動化対象にするか」の選択の方がずっと難しいと感じてる。

自動化に向いてる作業と、向いてない作業がある。繰り返しが多くて、判断基準がある程度決まっていて、出力の善し悪しをチェックできるもの——これが自動化しやすい。

逆に、毎回文脈が違うとか、微妙なニュアンスが重要とか、失敗したときのダメージが大きいものは、無理に自動化しない方がいい。

最初は「これも自動化できそう」といろいろ試したけど、結果的には対象を絞った方がうまくいった。広く浅くより、狭く深く、という感じ。

AI自動化の話をSNSで見てると、どうしても「これだけで楽になった」みたいな切り取りが多くなる。実際は、動かして、壊れて、直して、また少し広げて、の繰り返しだ。

ただ、地味だからこそ続けられてる面もある。派手な魔法を期待してたら途中で飽きてたかもしれない。

設計の問題として向き合えると、ちゃんと改善できるし、何がうまくいってるかも見えやすい。

仕組みは一度作って終わりじゃなくて、使いながらじわじわ育てるもの、という感覚が今は強い。そのくらいの温度感で付き合う方が、個人規模だと合ってる気がしてる。