無人ラインは、いつか途中で落ちる——拾い方を先に書いておく
毎朝動く工程は、いつか途中で落ちる。落ちないラインを作ることはできない。作れるのは、落ちた次の一手を先に決めてあるラインだ。自社では、その一手を工程の中に書き込んである。
途中で落ちるとはどういうことか
完全に動かないのは、実は困らない。何も起きていないので、翌朝ゼロからやり直せばいい。厄介なのは、半分だけ進んだ状態で止まることだ。
自社の実記録から二つ挙げる。ひとつは、生成サービスの残高が尽きて音楽工場が空振りした朝。もうひとつは、音声エンジンが固まり、一日分の音声生成が失敗した日だ。どちらも原因はAIの能力ではなく、人間の設計の穴だった。残高を見張る仕組みを工程に入れていなかったこと、固まったときの復旧手順を用意していなかったこと。前者は残高チェックを工程に組み込んで、後者はエンジンを移行し監視と自動復旧を足して解決している。
半端に進んだ状態が危ないのは、次の実行がそこを見ずに始めるからだ。前回の途中の産物が残っているのに、新しい仕事を上から重ねる。これで壊れる。
工程分解表:無人ラインの再開を設計する
| 工程 | 無人化度 |
|---|---|
| 実行のたびに、前回が完遂したかを最初に確かめる | 完全無人 |
| 途中の産物が残っているかを機械が判定する | 完全無人 |
| 残っていた前回分を完遂させる | 完全無人 |
| 途中で失敗したとき、始める前の状態へ戻す | 完全無人 |
| 想定外の残りかすが出たときに、手を止めて報告する | 検品のみ人間 |
| どこまでを自動で拾わせ、どこからを人間に渡すかを決める | 人間必須 |
機械が引き受けられるのは、確認・完遂・巻き戻しまでだ。引き受けられないのは、拾ってよい範囲の線引きにあたる。
できる側
いちばん効いたのは、工程の一行目を「仕事を始める」ではなく「前回の後始末が済んでいるかを見る」にしたことだ。順番を入れ替えただけで、道具は増えていない。
巻き戻しも機械の得意分野だった。途中のどこかで失敗したら、始める前の状態へ自動で戻し、「世に出ていない」と明示して終わる。中途半端な状態のまま次へ進ませない。成功も失敗も、どちらも終わった状態として定義できていれば、次の朝が迷わない。
難しい側
難しいのは、拾わせてよい範囲を決めることだ。
前回の残りかすが、今回の仕事の範囲内にあるなら自動で完遂させてよい。範囲の外にまで残っているなら、それは想定外だ。原因が分かっていないものを自動で片付けさせると、無関係なものを世に出す事故になる。だから自社では、範囲の外に残りかすを見つけたら何もせずに報告して終わるように書いてある。止まる設計を最初から入れておく。
もうひとつは、拾い直しを人間の記憶に置かないことだ。「落ちていたら手で直す」は、直し方を覚えている人がいる間しか成立しない。手順は工程の側に書く。
一般論として、無人化の設計は正常に動く日を前提に組まれやすい。実際に運用を支えるのは、落ちた日の一手のほうだ。
自社の実例
音楽工場は、2026年7月27日から止めてある。止めた状態が続いていること自体は事故ではない。事故になるのは、止まっているのに動いているつもりで数字を語ったときだ。だから稼働の記録は、五分ごとにコレクターが集め、出勤板にそのまま出している。
このブログも同じかたちで動く。記事はAI社員が書き、機械検品——禁止表現・台帳にない数字・規格崩れの照合——を通ったものだけが無人で公開される。公開の手前で落ちた場合は、次の実行がまずそれを見つけ、前回分を完遂させてから当日分に進む。内容の最終責任はMON-AIが負う。
導入までの手順
- いま毎日動いている工程を一つ選び、「途中で止まったらどうなるか」を書き出す
- 実行の一行目に、前回が完遂したかを確かめる工程を足す
- 途中で失敗したときに戻す先を決め、戻せない場合は止まって報告させる
締め
この線は、会社ごとに引き直せる。どこまでを機械に拾わせ、どこからを人間に渡すかは、業務の実態を知っている人にしか決められない。その線を一緒に引くところから始めたい方は、実装設計図か、無料相談(四十五分)へ。