紋
MON - Ai
— 記録 —
自社の現場記録

「成功しました」が嘘だった日——無人ラインの自己申告を数えない

2026.08.07

無人で回す仕組みは、自分の失敗を自分で報告できない日がある。
2026年8月6日、うちの動画工場で、成功と失敗の合図そのものが壊れているのを2つ見つけた。
どちらも本番に出る寸前で止めた。

何が起きたか

ひとつめ。字幕データを一括生成するスクリプトが、正常に終わっているのに「失敗」を返していた。原因は、処理の最後に置いた条件式だった。失敗件数がゼロかどうかを判定する式が最後に走るため、失敗ゼロのときは判定が偽になり、そのまま「失敗」として返る。逆に失敗があるときは、失敗案件を並べる表示処理が最後に走って「成功」として返る。合図が完全に反転していた。

無人ルーチンは、この合図だけを見て次に進む。反転していれば、字幕が1件も作れなかった朝だけ、機械は「成功」と報告する。

ふたつめ。案件をまとめて作り直すループが、対象を1件おきに飛ばしていた。ループが1行ずつ読み込む入力を、内側で呼び出したレンダリング処理が横から読んでしまう。案件名の途中から読み始めた行が、そのまま失敗として記録されていた。回したつもりの件数と、実際に処理された件数が食い違っていた。そのまま「全件完了」と報告する寸前だった。

なぜ両方とも見つかったか

成果物の側を見に行ったからだ。ひとつめは、報告が「失敗」なのに字幕データが揃っていたことで気づいた。ふたつめは、処理の記録ではなく、出来上がった音声ファイルの更新時刻を台本より新しいかどうかで数え直したときに露見した。どちらも、機械の自己申告を疑って実物を見た結果として出てきている。

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

工程分解表——無人ラインの「確認」を分解する

工程担い手無人化度
処理そのものの実行 AI社員・スクリプト 完全無人
成功・失敗の合図を返す スクリプト(人間が設計する) 人間必須
成果物が存在するかの照合 照合コマンド 完全無人
成果物の中身が規格どおりかの照合 機械チェック 完全無人
合図と実物が食い違ったときの判断 人間 人間必須
穴を歯止めに変える改訂 人間 人間必須

無人化できるのは1行目と、3行目・4行目だ。2行目は機械が実行するが、何をもって成功とするかを書くのは人間で、ここを間違えると下の照合が全部意味を失う。

難しい側——「失敗したのに成功」は永久に気づけない

成功したのに失敗と出れば、人間はすぐ調べる。逆は調べない。合図が正しい前提で組まれた集計は、合図が壊れている場面で必ず嘘をつく。しかもその嘘は、いちばん見てほしい日——1件も処理できなかった日にだけ現れる。

一般論として、この手の反転は書いた本人には見えない。書いた本人は「失敗ゼロなら通す」つもりで書いており、コードもその意図どおりに読める。壊れているのは意図ではなく、最後に走った式が何を返すかという実行順の話だからだ。

うちは毎朝03:00に講演コンテンツの制作工場が台本一式6点を、毎朝04:00に動画工場が台本から音声・字幕までを無人で仕上げる。人間が横で見ていない以上、合図を信じるほかない場面は必ず残る。だから合図の設計そのものを、検品の対象に入れている。

直したこと

条件式に頼るのをやめ、失敗があれば失敗として明示的に終わり、無ければ成功として明示的に終わる形に書き直した。再実行して、合図が正しく返ることを確認している。ループの側は、内側の処理が入力を横取りしないよう入力元を切り離したうえで、成果物の更新時刻で対象を選び直す2巡目を必ず走らせる手順にした。

数えるのは、回した回数ではなく、出来上がった実物の状態だ。

導入までの手順

  1. 無人ルーチンが「成功」と判定している根拠を1つずつ書き出す(何の合図を見ているか)
  2. その合図を、成果物の存在と中身の照合に置き換える(合図と実物を突き合わせる)
  3. 合図が壊れていた場合に何が素通りするかを1行で書き、その素通りを止める照合を足す

この線は、会社ごとに引き直せる。どこまでを機械の報告で済ませ、どこから実物を見に行くのか——その線引きは実装設計図で一緒に引けるし、まず話だけ聞きたいなら無料相談から始められる。

この記事は 2026.08.07 にAI社員が執筆し、機械検品を経て公開されました。内容の最終責任はMON-AIが負います。
メールで問い合わせる → 記録の一覧へ