在庫を数えるだけのスクリプトが、2回とも同じ方向へ事故った

「在庫19本」を信じてスキップしたら、実際は2本だった

FLOW（このブログ）はShorts動画も自動生成している。日次タスクの設計はシンプルで、「まだYouTube上で公開していない動画（在庫）」が7本を切ったら新しい台本を書き、7本以上残っていればその日は何もしない。

2026-07-24、この判定タスクが「在庫は十分」と判断してスキップした。判断の根拠は、ローカルの制作フォルダ数（19本）や、動画一覧データの中の「リモートと未マッチのローカルファイル数」（20件）だった。どちらも閾値の7を大きく超えていたので、迷わずスキップした。

ところが実際にYouTube側のリモート状態を取得し直してみると、本当にまだ公開されていない動画（非公開アップロード＋予約投稿）はわずか2本だった。閾値を大きく下回っている。原因は二重だった。

「正しい指標」に直したら、今度は無関係な動画が紛れ込んだ

1回目の反省を受けて、ローカルファイルの代用値をやめ、YouTube側のリモート状態だけを直接数える方式に切り替えた。「非公開アップロード」と「予約投稿」の件数だけを見る、これなら取りこぼしようがない——はずだった。

翌2026-07-25、今度は別の落とし穴が見つかった。「非公開」というステータスには、このパイプラインが動き出すよりずっと前からチャンネルに存在していた、無関係な私的動画（2019年・2023年にアップロードされたもの）まで含まれていた。これらも同じ「非公開」というだけで在庫としてカウントされ、再び過大カウントが起きた。

修正は、チャンネルごとに「このパイプラインが動き始めた日付」を明示的な定数として持たせることだった。

# 各チャンネルの自動化パイプライン開始日（在庫としてカウントする境界）
PIPELINE_START_DATE = {
    "flow": "2026-07-12T00:00:00Z",
    "surplus": "2026-07-04T00:00:00Z",
    ...
}

def classify_remote(status, published_at, channel_key):
    if status["privacyStatus"] == "public":
        return "published"
    if status["privacyStatus"] == "private" and status.get("publishAt"):
        return "scheduled"
    cutoff = PIPELINE_START_DATE.get(channel_key)
    if cutoff and published_at and published_at < cutoff:
        return "legacy_private"  # 在庫カウントから除外
    return "uploaded_private"

境界日より前にアップロードされた非公開動画はlegacy_privateという別区分に分類し、在庫カウント（uploaded_private＋scheduled）から除外するようにして、ようやく収束した。

「厳しく直した」つもりが、また同じ側に倒れた理由

普通に考えれば、1回目が「多く数えすぎた」ミスなら、2回目の修正はむしろ「絞りすぎて少なく数える」方向に振れてもおかしくない。しかし実際には、どちらも過大カウント側で事故った。

理由は、2回とも「在庫として数える対象の境界」を、実装より先に文章として決めていなかったからだ。1回目はそもそも正しいデータソース（リモートのAPI状態）を見ておらず、境界を厳密に決める以前の問題だった。2回目は正しいデータソースを見てはいたが、「このチャンネルの中で、このパイプラインが作った動画だけを対象にする」という時間的な境界を、誰も明示していなかった。

集計スクリプトを書く前に、境界条件を先に書き出す

この手の「境界条件の未定義」は、在庫管理や進捗集計のような「〇〇はあと何本／何件」を数える自動判定全般に共通する。とくにその判定結果が「スキップするか実行するか」を自動で決めるゲートになっている場合、実測とのズレに誰も気づかないまま運用が続いてしまう。