テーマ移行「完了」のはずが、キューに旧記事13件——Claude Codeに看破された話

最終更新: 2026-04-28

3月末にテーマ移行を完了した、と自分で記録に書いていた。生成スクリプトを差し替えて、新テーマの記事が出始めた時点で作業を閉じた。キューの中まで確認しなかった。

後で数えたら、幽霊在庫が13件あった。

キュー監査で発覚した「幽霊在庫」

発端は別の作業だった。priority_stock_manager.py と quality_guard.py を修正したとき、その diff を Claude Sonnet 4.6 にレビューさせていた。クラッシュリスクと意図ずれを先に潰す——これはいつもやっている。Codex をバックグラウンドで走らせてセカンドオピニオンも取る構成にしていた。

Codex の結果を待っている間に、Claude Code がキュー監査を先に完走してきた。返ってきたログを読んで、少し止まった。

BSky/Xキュー：クリーン ✅

noteキュー  5件 → 「旧ジャンル」キーワード混入
blogキュー  8件 → 旧テーマタイトル混入（posted_titles.jsonも含む）
Xキュー     5件 → session_log.json の text フィールドが空
                  （tweets[]には内容あり、実害なし）

X の件は実害なしで放置した。note 5件、blog 8件——合計13件。3月末に「完了」したはずの移行が、キューの中ではまだ動いていなかった。生成ロジックだけ差し替えて、在庫には誰も触っていなかった。それだけの話だが、実際にリストを見るまで気づいていなかった。

環境

MacBook Pro M5 32GB、macOS。ターミナルで Claude Code（Sonnet 4.6）を動かしながら、Codex はバックグラウンドで走らせる構成。キュー管理は priority_stock_manager.py と quality_guard.py の自前スクリプト2本。記事ファイルは JSON 形式で blog キューに積んでいる。

diff レビューの観点と、先に返ってきた監査結果

今回の diff レビューに渡した観点はこれ。

1. バグ・クラッシュリスク（非同期処理・ファイルI/O競合）
2. 意図通りに動かない可能性（重複チェック漏れ・条件分岐ミス）
3. セキュリティ上の問題
4. 改善提案（本当に必要なものだけ）

深刻度を 🔴🟡🟢 で分類して日本語で返すよう指示している。今回は Codex より Claude Code の監査が先に返ってきた。その結果が、前節の幽霊在庫の発見につながった。

削除対象6件と、s100_S でも通らなかった件

blog キューから旧テーマを絞り込んだら6件になった。

s080_A_20260410_priority_stock_managerが見せ.json
s075_B_20260410_ローカルAI自動化とサーバー検出並行させる実戦検証.json
s100_S_20260406_ClaudeAIとChatGPTの使い分け完全ガイ.json
s080_A_20260410_ローカルAIのゴミ掃除とBlueskyでの仮説検証.json
s080_A_20260410_macOS標準flockがなくてもPIDでロック再.json
s080_A_20260410_MacBo...（以下略）

3行目で手が止まった。s100_S_20260406_ClaudeAIとChatGPTの使い分け完全ガイ.json——スコア 100、グレード S。quality_guard.py の品質判定では最高評価のファイルだ。削除リストに入っていた。

タイトルに「ChatGPT との使い分け」が含まれている、それだけの理由で。品質スコアとテーマ適合は別の軸で管理しなければいけない——という当然の結論を、実際に s100_S を trash に落とすまで整理できていなかった。正直、一瞬「もったいない」と思った。が、削除した。スコアは投稿可否を保証しない。そこが詰まりポイントだった。

旧テーマファイルの除外処理と、posted_titles.json から旧テーマエントリを削除する処理を続けて走らせた。変更が入ったファイルの diff を確認したら、quality_guard.py・commander_actions.py・commander_agent.py・各種 blog スクリプトなど40本超が一度に変わっていた。

git diff --stat HEAD~1
# .claude/settings.local.json        |   71 +-
# 00_Shared/quality_guard.py         |   34 +
# 01_Scripts/agent_loop/commander_actions.py  |   54 +
# 01_Scripts/blog/add_meta_descriptions.py    | ...

40本を人間が一行ずつ追うのは無理だと判断して Claude Code に渡している。クラッシュリスクと意図ずれを先に潰せれば、あとはコミットして動かしながら直せばいい——そういう割り切りでやっている。

セッション継続の落とし穴と、中間状態の保存

この作業の途中で一回、Claude Code がコンテキスト上限に達して継続になった。継続後にキュー状態と削除対象リストを再確認したら、中間状態をファイルに書き出していなかったせいで一部の判断をやり直すことになった。10分のロスで済んだが、同じ失敗をその前に2回やっている。

3回目のあと、監査結果が出たタイミングで /tmp/queue_audit_result.json に書き出す処理を挟んだ。/tmp は再起動で消えるが Claude Code の継続をまたぐには十分だ。継続後に読み直すだけ——それだけのことだが、習慣になるまでに3セッションかかった。

テーマ移行の話に戻ると、「生成ロジックを変える」だけでは終わらない。キューに積まれた在庫は別で監査しないと、旧テーマ記事が普通に投稿されていく。生成フローと在庫フローは完全に独立していて、片方を変えても片方は変わらない——という当然の事実を、13件の幽霊在庫を実際に見るまで体感できていなかった。

キューの中身まで監査して初めて「完了」

テーマ移行が終わるのは、新しい記事を生成し始めた瞬間じゃない。旧在庫が全部 trash に落ちた瞬間だ。

今回、quality_guard.py にテーマチェックの判定軸を追加した。スコアが何点であろうと、テーマ違反なら trash に落ちる。スコアと投稿可否を同じ変数で管理しようとしていた設計ミスが根っこにあって、分離するのに1セッションかかった。s100_S を trash に落とした瞬間が、実質的な設計変更のトリガーになった。

Claude Code の diff レビュー＋Codex バックグラウンドのセカンドオピニオン構成は続ける。40本超の変更を人間が追わなくていい状態を維持するためのコスト——今のところ悪くない。