見出し画像

「作った人はもういない」AI自動化が現場に残す請求書

しろふじ

海外の起業家コミュニティに、こんな投稿がありました。ノーコードツールで組まれた業務自動化が、本番で止まる。作った本人が直せず、AIに修正を丸投げしてさらに壊す。最後は連絡が取れなくなる。

残されるのは、誰も中身を説明できないワークフローが一本だけ。

この現象は「Vibe Coded Automations」と呼ばれています。ソフトウェアエンジニアリングの訓練を受けていない人が、感覚だけで組み上げた自動化のことです。作る速度は確かに速い。ただ、運用フェーズに入った瞬間に手綱が効かなくなります。

日本でも Dify や n8n のようなローコード／ノーコードのAIツールが、業務自動化の選択肢に入ってきています。海外で先に起きていることは、そのうち同じ形でこちらにも来ます。

この記事では、コミュニティで報告されている壊れ方を三つに整理し、自動化を人に引き渡す前に決めておく項目を並べます。ツールの良し悪しや、非エンジニアが自動化を組むことの是非は扱いません。

「動いた」と「運用に乗った」の間にある距離

批判されているのは、感覚で作ったこと自体ではありません。引き継げない状態のまま、本番に置いたことです。

デモの日は、たいてい何でもうまくいきます。データはきれいで、APIは即座に返ってきて、想定外の入力は来ない。

問題が出るのは、そこから3週間後の火曜の朝です。担当者が休んでいて、顧客名に旧社名が入っていて、外部サービスが5秒黙る。そのときに何が起きるかを決めていないと、自動化は「動くもの」から「たまに動くもの」に変わります。

壊れ方は、だいたい三つに集約される

コミュニティで共通して挙がっている欠陥は、次の三つです。

三つとも、デモの日は問題なく通ります。差が出るのは、本番のデータと担当者が不在の日です。

失敗するのではなく、黙る

一番多いのがエラーハンドリングの不在です。すべてが想定どおりに進む経路（ハッピーパス）しか設計されていない。

外部APIがタイムアウトした、必須項目が空だった。このときワークフローは、エラーを出して止まるのではなく、何も起こさずに終わります。人間から見ると「今日は問い合わせが少なかったな」としか見えません。

気づくのは3日後、顧客から「返事がまだですか」と連絡が来たときです。

構築者にエラー処理の経験がないため、LLMに修正を投げて直そうとして失敗し、最終的にクライアントと連絡が取れなくなる。この流れが繰り返し報告されています。

たまたま動いているだけのロジック

二つ目は、正しく設計されたのではなく、偶然うまくいっていたケースです。

テストに使った顧客データが、たまたま全部きれいだった。本番には表記ゆれの社名、全角の電話番号、空欄の担当者欄が混ざっています。分岐条件はそこで崩れます。

厄介なのは、構築者自身も「なぜ動いていたか」を説明できないことです。動く理由が分からないものは、壊れた理由も分かりません。

変更したい場所だけを、変更できない

三つ目は、モジュール化とドキュメントの不在です。トリガーから通知までが、一本の巨大なシナリオに詰め込まれている。

やりたいことは「通知先を一人増やす」だけなのに、全体を読まないと安全に触れない。コメントもなく、なぜこの分岐があるのかという業務上の理由も残っていない。

数か月後には、作った本人にとってもブラックボックスになります。

請求書は、作った人ではなく現場に届く

ここが問題の本体だと思います。

作った人は、感覚で作れたぶん、直すときも感覚に頼るしかありません。手に負えなくなれば、離れることもできます。一方で業務は止められないので、後始末は現場が引き受けます。

コードの汚さではなく、こういう時間として現れます。

  • 自動化の出力が正しいかを、毎朝目視で確認する時間

  • 止まっていた期間の処理を、手作業で埋め戻す時間

  • 「またAIが変なことをした」という前提で、二重チェックを常設する時間

工数を削減するはずの仕組みが、確認作業を増やしている。この状態が半年続けば、導入前より高くつきます。

ツールを売っていたつもりが、業務設計を売っていた

同じ現象は、提供する側でも起きています。

AIツールをSaaSとして売ってきた起業家たちが、「企業はAIをどう使えばいいか分かっておらず、解決策ごと丸投げしてくる」という現実に突き当たっています。プロダクトを渡すだけでは定着せず、解約が積み上がる。

そこで多くの提供者が、ツール販売にAI導入コンサルティングを併売する形へ回帰しています。トリガー条件、エラー時の分岐、出力テンプレート、そして「そのプロセスを誰が所有しているか」を定義し直す仕事です。自動化を、再利用と引き継ぎが効くプロセスとして文書に落とすところまでを請け負う。

導入する側から見ると、ツールを買っても、運用設計は付いてきません。 ここを誰が担当するか決まっていない導入は、ベンダーが優秀でも同じになります。

引き渡しの前に決める7項目

自動化を自分以外が触る場所に置くとき、先に埋めておく項目です。コードの知識は要りません。埋まらない項目があるなら、そこがそのまま将来の障害ポイントになります。

ゲートを通すのは一度だけで、埋まらなかった項目が、そのまま将来の障害ポイントになります。

  1. トリガー条件 — いつ動くのか。動かさない条件も書く

  2. 失敗時の分岐 — 止まるのか、やり直すのか、人に渡すのか

  3. 通知先 — 失敗したことを、誰がどこで知るのか

  4. リトライの回数と上限 — 何回試して、それでもだめなら何をするか

  5. 正常な出力の形 — 出力テンプレートを一つ、実例として残す

  6. 人が介入する境界 — 金額、件数、宛先など、自動で通してよい範囲の線

  7. 所有者と止め方 — 誰の持ち物で、誰がどうやって止められるか

エンジニアリングの話に見えますが、中身はほとんど業務の話です。だからこそ、業務を知っている人が埋めたほうが早く済みます。

特に7番目は抜けやすい項目です。作った人が異動や退職でいなくなったとき、止め方を知っている人が社内にいるかどうかで、被害の大きさが変わります。

速さを捨てずに、渡し方だけ決める

感覚で素早く組めることは、そのままで強みです。試作の段階から設計書を求めれば、動くものが出てくる速度が落ちるだけになります。

区切りを入れる場所は自分以外が触る場所に置くときです。そこで7項目を通す。埋まらない項目があれば、本番に出すのを止める。

どちらを選んでも構いません。決めないまま置かれた自動化だけが、あとになって現場に請求書（報告書作成、徹夜復旧指示など）を送られるだけです。

ここまでの整理は、海外コミュニティで共有されている失敗の報告に基づくものです。壊れ方のパターンとして見たときに、日本の現場と重なる部分がどれだけあるか？（同じだと思います！）

出典・参考リンク


いいなと思ったら応援しよう！