「失敗0件」がいちばん危ない——無人ラインに合否を返させる設計

無人ラインで最も危ないのは、失敗が0件と表示されている状態だ。
何も失敗していないのか、そもそも何も処理していないのか、その表示だけでは区別がつかない。
2026年8月9日、うちの制作ラインで同じ形の穴を2か所まとめて塞いだ。

何が起きたか

うちの動画工場は、台本から音声を作り、そのあとに字幕を組み立てる。人はどこにも立っていないので、各工程は終わったときに合否をひとことだけ返す。合格か、不合格か。次の工程も、記録も、警報も、その返事だけを見て動く。

字幕を組み立てる工程で、その返事が反転していた。失敗が1つもないときに「不合格」を返し、失敗が出たときに「合格」を返す。原因は処理の中身ではなく、返事を作る最後の一行の書き方だった。条件式をブロックの末尾に置いたため、条件が成り立たなかったこと自体が不合格として返っていた。

「成功したのに不合格」と言われるほうは、人がすぐ気づく。翌朝に警報が出るからだ。逆は気づけない。失敗した日にだけ合格と表示されるラインは、静かに壊れたまま何日でも動く。

同じ日にもう1つ見つかった。集計の道具のほうは、内部で失敗を数えていたのに、その結果を捨てて常に合格を返していた。画面には失敗案件の名前が並んでいるのに、機械にとっては合格だった。人が読む表示と、機械が読む返事が、別々に作られていた。

もう1つの穴——「対象0件」

返事を直しただけでは足りなかった。素材の置き場が読めていない日は、処理0・失敗0で、正々堂々と合格が返る。外付けの保存先が外れていても、フォルダの場所が変わっていても、ラインは「何も失敗していません」と答える。

入力が消えている日ほど、板は緑になる。 そこで、合否を判定するより前に「対象が0件ではないか」を見る関門を1か所だけ置いた。0件は正常のこともあるので、どちらに倒すかは工程ごとに人間が決める。

工程分解表——「終わり方」を分解する

できる側

合否の返事は、機械が完全に引き受けられる。工程の最後で明示的に合格・不合格を返し、呼び出した側がそれを読む。ここに人の目を挟む必要はない。

成果物の側から確かめるのも機械の仕事だ。 起動したかどうかではなく、今日の予定時刻より後に成果物が更新されているかを見る。うちはルーチンの点呼をこの形に変えた。取れなかったものは「不明」として置き、合格には倒さない。緑に倒れる板は、いずれ誰にも読まれなくなる。

難しい側

難しいのは、0件をどちらに数えるかの線引きだ。まだ音声が出ていない案件は、字幕が無くて当たり前で、これを失敗に数えると警報が毎日鳴る。鳴りっぱなしの警報は、無いのと同じになる。一方で、素材の置き場ごと読めていない0件は事故だ。見た目はどちらも0件で、区別できるのは業務を知っている人間だけだ。

もう1つ難しいのは、直したものを実際に本番へ乗せるところだ。今回の2か所のうち片方は、以前に一度直していた。ところが直した内容が手元に残ったままで、いつでも元の反転した状態へ戻りうる形になっていた。直したことと、直った状態が続くことは別だ。

失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。

自社の実例

うちでは毎朝03:00に講演コンテンツの制作工場が、毎朝04:00に動画工場が無人で起動する。台本から音声、字幕までが人の手を通らずに仕上がる。成果物の一次チェック——誤字、規格崩れ、禁止表現——も機械チェックとして実装してある。

このブログもそうだ。AI社員が書き、機械検品を通ったものだけが無人で公開される。検品に引っかかった日は、記事が増えない。増えないこと自体が異常の合図になるように組んである。

導入までの手順

1. 無人で動いている処理を1つ選び、それが終わったときに何を根拠に「終わった」と判定しているかを書き出す
2. 判定の根拠を、実行側（起動したか）から結果側（成果物が更新されたか）へ移す
3. 「対象0件」のときにどちらへ倒すかを工程ごとに決め、判定より前に置く

この線は、会社ごとに引き直せる。どこまでを機械の返事に任せ、どの判断を人間が持つのか——その線引きは実装設計図で一緒に引けるし、まず話だけ聞きたいなら無料相談から始められる。