追記専用の編集台帳とデプロイ前検査で、事故を出荷前に止める
193,849行の edit_stage テーブルと、5項目のプリフライト。証跡のない変更は本番に出せないようにした。
前提: 19万箇所を直している
この文字起こしには、いま19万箇所ほどの修正が入っています。
辞書で機械的に置換したもの、LLMが直したもの、映像のテロップを見て確定させたもの、
管理画面から手で直したもの。全部が同じ segments テーブルに載っています。
問題は、segments が今どうなっているかしか持っていないことでした。
前に直した1行について、テロップを見て決めたのか、辞書で置換されたのか、
文脈から判断したのかを、あとから区別できません。
区別できないと、間違いを1つ見つけたときに同じ種類の間違いを探せません。 それで、変更の履歴を別のテーブルに持つことにしました。
持たせたもの
CREATE TABLE edit_stage (
video_id TEXT,
idx INTEGER,
stage TEXT, -- dict / ai / telop / human / label / refill
source TEXT, -- 根拠(テロップの窓、辞書の行、実行したスクリプト)
after_hash TEXT, -- 直した直後の本文のハッシュ(あとで比較する)
run_id TEXT,
at TEXT
);
sqlite> SELECT stage, COUNT(*) FROM edit_stage GROUP BY 1 ORDER BY 2 DESC;
ai|182980
telop|6537
dict|4056
human|276
label|47
追記専用にしているので、更新の競合を考えなくて済みます。 「今どうか」は segments、「なぜそうなったか」は edit_stage、と役割を分けました。
stage はどの工程が書き換えたかであって、
自動でやったか手でやったかの区別ではありません。
dict は人が確かめて登録した辞書、ai は人が範囲を限定した校正、
telop は人が映像を見て確定させたぶんです。
台帳があると、検査が書けるようになる
履歴が残ると、出荷前に機械で見られるものが増えます。いまは5項目です。
$ python3 scripts/preflight_release.py --strict-e
デプロイ前検査 (比較元: 2026-09-07 10:54 時点の出荷内容)
[A] 出荷時から変わった segment: 51件
[B] 区切りが変わった動画: 0本
✅ 起こし直しなし。消えた修正の心配なし
[C] 証拠の中身が無い fix: 0件
[D] 今回の変更で新しく入った表記: 4種
🚨 番組の書き起こしに一度も出てこない表記が 4種 入っている
「「デカルトみ」」 5HUPJcw-YXA idx770 [24:56] ほか40箇所
[E] 段階の記録が無い変更: 1件
🚨 commit_edits.py 経由で直すか、edit_stage に記録すること
HeQJvgaZp50 idx162 [4:02]
🚨 中止 2件 / 警告 1件
[D] がいちばん効く
コーパスに一度も出てこない表記を新しく持ち込むのは、たいてい捏造か誤変換でした。 意図したものなら、理由を書いて承認ファイルに登録すると通ります。
# data/new_spellings_ok.csv
span,video_id,idx,reason
「デカルトみ」,5HUPJcw-YXA,770,番組の造語なので鉤括弧で囲む。囲みは全41箇所
[B] は起こし直しを見ている
音声認識をやり直すとセグメントの区切りが変わります。 区切りが変わると、idx で紐づけていた修正が別の場所に付くか、消えます。
もう1つ機械で止めている場所
要確認に登録すること自体は正しい行動なので、 登録した瞬間に作業を終えた感覚になり、 その手前のテロップ確認を飛ばしたことに自分では気づけませんでした。 「不安になったら確認する」型の規則は、不安を感じていないときに発火しません。
それで、登録の側に条件を置きました。
$ python3 scripts/check_unsure_evidence.py
unsure の行を検査した
🚨 テロップを見た証跡が無い N 件
screen_note に「何を見て、なぜ確定できなかったか」を書くこと
この検査を入れたきっかけは、10件を要確認に登録したあとで
fps=1 でテロップを見たら、10件すべて確定できたことです。
しかも文脈だけで直していた2箇所が、テロップでは別物でした。
ここまでで分かったこと
- 「今どうか」と「なぜそうなったか」は別のテーブルに置く。履歴は追記専用にする
- 履歴があると検査が書ける。とくに「新しい表記の持ち込み」の検出は効く
- 人の注意力に頼る規則は、注意力が落ちている場面でこそ発火しない。 「気をつける」ではなく機械が止める条件に翻訳する
← 書き込み口を2つにしたら、人が入れた修正が黙って消え… SQLite FTS5(contentless)の索… → 目次へ