AIに任せて失敗したこと——自社の実記録から3つ

うちの無人経営には、記録に残る失敗が3つある。
3つとも、原因はAIの側になかった。人間の設計の穴だった。
何が起きて、どこに穴があり、どう塞いだか。そのまま書く。

工程分解表——無人工場の「運転」を分解する

無人化の設計は、生成の工程だけでは完結しない。運転を支える工程まで含めて、いまの線はこうなっている。

表のうち3行に「失敗の後に」と書いた。つまり、最初の設計には入っていなかった。ここからが本題だ。

失敗1——クォータ切れで音楽工場が止まった朝

何が起きたか。 定時起動を設定してあった音楽工場が、ある朝空振りした。生成サービスの残高が尽きていた。
本当の原因。 AIは指示どおりに動いていた。残高を管理する仕組みを、設計した人間が作っていなかった。穴はAIの外にあった。
どう直したか。 残高チェックを工程そのものに組み込んだ。工場は、残高を確認してから走る。
それでも再発した。 7月24日から27日まで、生成サービスのクォータ切れで、生成は4日続けて0曲だった。チェックは空振りに気づかせてくれるが、クォータそのものは補充しない。7月27日、こちらの判断で音楽工場を停止させ、いまも止めたままにしてある。穴を一つ塞いでも、その外側にまだ塞いでいない穴がある——という記録として、ここに残しておく。

失敗2——毎時ルーチンが空回りし、2日で約85件の無駄なセッションを生んだ

何が起きたか。 毎時実行のルーチンが、処理すべき素材が無いのに起動し続けた。2日間で約85件、何もしないセッションが積み上がった。
本当の原因。 「毎時動かしておけば取りこぼさない」という発想で組んだ。起動すべき条件を定義していなかった。スケジュールを書いた人間の穴だ。
どう直したか。 1日1回のバッチに設計し直した。空回りは消えた。

失敗3——音声エンジンのハングで、1日分の生成が失敗した

何が起きたか。 旧エンジンのGPU処理が固まり、長尺4本+ショート3本、1日分の音声生成がまるごと失敗した。
本当の原因。 エンジンが固まること自体は不具合だ。だが、固まったことを検知する仕組みも、自動で立ち直る仕組みも用意していなかった。「壊れない前提」の設計が穴だった。
どう直したか。 エンジンを移行し、監視と自動復旧を追加した。固まっても、工場は自分で立ち直る。

3つに共通していたこと

失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。
AIは残高が尽きても訴えず、素材が無くても律儀に起動し、エンジンが固まっても黙って止まる。だから無人化の設計は「うまくいく手順」だけでは足りない。資源が切れたらどうするか。そもそも起動すべきか。処理が固まったら誰が気づくか。この3つの問いに答えてはじめて、工場は放っておける。
実際、設計を直した後の音楽工場は、バッチを走らせた7月21日に140曲、22日に260曲を無人で生成しきった。一方で7月24日から27日は、クォータ切れで0曲だった。穴は塞げる。塞いだ分だけ、無人で動く時間が延びる。ただし塞いだ穴の数だけ工場が強くなるのであって、塞ぎ終わることはない。
もうひとつ書き添える。3つの失敗はどれも、発見が遅れるほど傷が深くなる型だった。無人化した業務は人が見ていない。だからこそ、止まったことに気づく仕組みまで設計に含める。うちでは5分ごとにコレクターが全AI社員の稼働を記録し、mon-ai.jpの出勤板にライブ表示している。止まれば、板に出る。隠れて空回りする場所を、仕組みの上から消していく。

導入までの手順

1. 止まったら困る業務をひとつ選び、工程に分解する
2. 各工程に「資源が切れたら」「起動すべき条件は」「処理が固まったら」の3つの問いを当てる
3. 答えられなかった箇所に、チェックと復旧を工程として追加する

この線は、会社ごとに引き直せる。自社の業務のどこに穴があるかの洗い出しは実装設計図で請け負い、穴を塞いだ後の毎朝の無人稼働は、mon-ai.jpのオフィス（出勤板）でそのまま公開している。