移したら、元を消していた——「サイズが同じ」は「中身が同じ」ではない

消したあとでは、検証できない。
2026年8月9日、うちは完成データを外付けディスクへ移す工程の検証を、サイズの一致から中身の照合へ入れ替えた。
移すことと、控えを持つことは、別の仕事だった。

何をしていたか

制作が終わった映像と音声のもとデータは重い。放っておくと手元のディスクが埋まり、翌朝の工場が動かなくなる。そこで、納品済みの重いものを外付けへ移す処理を無人で毎日走らせていた。順序はこうだ。外付けへコピーする。コピー先とコピー元のサイズを見比べる。一致していたら、元を消す。

このサイズ照合を、うちは長いあいだ「検証」と呼んでいた。呼んでいただけだった。サイズが同じことは、中身が同じことを何も保証しない。 途中で書き込みが化けても、バイト数は変わらないことがある。そして元を消した瞬間、外付けの側が唯一のコピーになる。もう一度確かめようとしても、比べる相手が手元に無い。

事故は起きていない。実際に壊れたデータは見つかっていない。それでも直したのは、この工程が壊れていても気づけない形をしていたからだ。

検証が失敗したことと、検証が通ったことが、同じ顔をする

作り直しの途中で、もっと悪い穴が見えた。

中身の照合は、データから短い符号を計算して突き合わせる。ところが、この処理を書いていたスクリプトは、途中の命令が失敗しても止まらない書き方だった。符号の計算が落ちると、返ってくるのは空になる。コピー元も空、コピー先も空。空と空を突き合わせれば、当然、一致する。

つまり、検証が失敗した状態が、検証を通過した状態とまったく同じ見た目になる。 しかもその直後に元を消す。検査を足したつもりで、素通りの経路を一本増やしていたことになる。

直し方は単純だった。比べる前に、比べる値が本物かを確かめる。符号が空でないこと、決まった長さであること。この二つを満たさない限り、一致とは呼ばせない。

工程分解表——「重いものを手元から外す」工程

できる側

移す・比べる・記録する、は機械が全部引き受けられる。中身の意味を理解する必要がないので、対象が映像でも帳票でも同じ形で使える。

作り直しで一番効いたのは、照合よりも目録のほうだった。いつ・何を・どれだけの大きさで・どこへ移したか、そして中身の符号を、移すたびに手元の台帳へ書き足す。外付けが壊れて中身ごと失われても、何を失ったかが手元に残る。復旧できることと、何を失ったか言えることは別で、後者は台帳だけで成立する。

難しい側

難しいのは、何を唯一のコピーにしてよいかを決めるところだ。これは技術の問題ではなく、事業の判断になる。失っても作り直せるものと、二度と戻らないものを仕分けられるのは、その仕事の価値を知っている人間だけだ。うちも、原稿や字幕のような軽くて学習の素になるものは手元に残し、作り直しの利く重い完成データだけを外へ出す、という線を人間が引いている。機械はその線を引けない。線が引かれたあとを、正確に走るだけだ。

もう一つ難しいのは、控えを何本持つかの判断になる。控えを増やせば安全になるが、置き場所と手間が増える。どこまで払うかは経営の判断で、機械に委ねる話ではない。

失敗はぜんぶ、AIの能力ではなく、人間の設計の穴だった。今回の穴も、AIが間違えたのではなく、人間が「サイズが合えば同じ」と決めたところにあった。

自社の実例

うちでは毎朝03:00に講演コンテンツの制作工場が起動し、台本一式を無人で納品する。毎朝04:00には動画工場が起動し、台本から音声、字幕までが人の手を通らずに仕上がる。成果物の一次チェック——誤字、規格崩れ、禁止表現——も、機械チェックとして実装してある。5分ごとにコレクターが全AI社員の稼働を記録し、mon-ai.jp の出勤板にライブ表示している。

この記事もそうだ。AI社員が書き、機械検品を通ったものだけが無人で公開される。台帳に無い数字が本文に混ざれば、その日は公開されない。

導入までの手順

1. 社内で「移したあとに元を消している処理」を一つ探し、何をもって成功と判定しているかを読む
2. 判定に使う値が空でも壊れていても通ってしまわないか確かめ、通るなら、比べる前に値そのものを検査する条件を足す
3. 移したものの目録を手元に残す。復旧できなくても、何を失ったかは言えるようにしておく

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