キュー汚染を本番前に発見——旧テーマ混入13件をClaude Code×Codexで除去した話

最終更新: 2026-04-28

テーマ転換したのにキューは知らなかった

Claude Code（Sonnet 4.6）とのセッション中、気まぐれでキュー監査を走らせた。返ってきた結果を見て、少し止まった。

noteキューに「旧ジャンル」タグのコンテンツが5件。blogキューに旧テーマタイトルが8件。旧テーマ群——テーマ転換を宣言してから2週間以上が経過しているのに、priority_stock_manager.pyは何事もなかったかのように旧コンテンツを順番に拾い続けていた。

生成パイプライン自体は止まっていた。問題はキュー側だった。01_Scripts/blog/と01_Scripts/sns/配下にJSONが静かに残り続けていて、それに気づかなかったのは私だ。スコアSの旧テーマ記事が、今まさに投稿順番待ちをしていた。

環境

MacBook Pro M5 32GB / macOS Sequoia。Claude Code（ターミナル、Sonnet 4.6）でメイン作業。Codex（gpt-5.4）をセカンドオピニオン用にバックグラウンド投入。キュー管理の主役はpriority_stock_manager.pyとquality_guard.pyで、対象JSONはblog/・sns/配下のストックファイル群。

レビュー依頼の観点を4点に絞った理由

このセッションはもともとdiffレビューから始まっていた。変更量が多かったので「コードをレビューして」とだけ投げるのはやめた——過去に曖昧な依頼を出して「全体的に問題ありません」の一行が返ってきたことがある。あれ以来、観点を明示するようにしている。

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

Codexにこれを渡してバックグラウンドへ。結果が返ってくるまでの数分で、キュー除去を並行して進める——この順序が今回うまく機能した。偶然ではなく、重い処理が走っている間に手を止めるのがもったいないというだけの話だ。

監査を走らせたらBSky・Xキューはクリーンだった。汚染はnoteとblogに集中していて、さらにposted_titles.jsonにも混入が確認された。合計13件。

Xキューのsession_log.jsonはtextフィールドが空になっていて一瞬焦った。が、中身を読んだらtweets[]配列には内容が入っていた。構造の問題であって実害なし——この判断を30秒で済ませられるかどうかで、無駄な修正作業を1時間削れる。「壊れている」と即断しなかったのは、今回の数少ない正解だったと思う。

削除対象6件、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_が見える。スコア100、Sグレード——品質スコアとしては最高値だ。でも削除した。テーマが旧ならスコアは関係ない。むしろスコアが高いほど危ない。高品質な旧テーマコンテンツが優先的に投稿されていく状態こそ、気づきにくい地獄だと今回わかった。

同じセッションで前回から持ち越していた問題も片づけた。X投稿のサムネイルが「X/TWITTER SETUP GUIDE」と英語表記になっていたのを日本語タイトル入りで再生成。Discord Botの重複通知——朝のサマリーが2〜3回届く問題——も修正している。

Discord Botのほうはfetch_user失敗時のキュー保持ロジックが原因だった。asyncio.sleep(3)のリトライ間隔と組み合わさって、同じDMが複数回送信されるレースコンディションが起きていた。Codexのバックグラウンドレビューが返ってきてから深刻度別に対応順を決め、このコードに手を入れた。

# Discord Bot DM送信の失敗ハンドリング（修正前の問題箇所）
print(f"[dm] fetch_user 失敗（キュー保持）: {e}", flush=True)
await asyncio.sleep(3)

ここでasyncio.sleep(3)の後に再キューイングが走る構造になっていて、失敗するたびに同じDMがスタックに積まれ続けていた。修正自体は10行程度だったが、気づくまでに3回詰まった。

「テーマ転換＝キューも切り替わる」は幻想だった

生成パイプラインを止めればキューも止まると思っていた時期がある。違った。生成を止めた時点でキューに積まれていたJSONは、何もしなければ投稿されるまで残り続ける。スコアSが旧テーマで埋まっていたのはその証拠だ——テーマ転換後も2週間、パイプラインは旧コンテンツを粛々と消化していたことになる。

Codexのバックグラウンド実行は今回初めてこのパターンで使った。「重いレビューを投げながら別の作業を進める」というだけの話なのに、意識してやったことがなかった。観点を事前に4点に絞っておくと、返ってきた結果の使い勝手が全然違う。「非同期処理・ファイルI/O競合」「重複チェック漏れ」と具体的に書いたほうが、深刻度付きの箇条書きで整理された回答が返ってくる。「コードをレビューして」では同じことは起きない——この差は体感として結構大きかった。

Xキューのtextフィールド空問題でも気づきがあった。JSONの構造確認を怠って「壊れている」と即断していたら、修正作業を1時間やって最終的に「元から問題なかった」という結果になっていた。tweets[]配列に内容があることを確認してから判断した——それだけで無駄な作業がゼロになった。自動化への信頼度が高くなるほど、こういう「確認を省く」癖がつきやすい。

テーマ転換後のキューは手動で棚卸しするしかない

品質スコアとテーマ適合性は別指標——この2軸を持っていないと、高品質な旧コンテンツが優先投稿されるパイプラインになる。今回の13件はその典型だった。Codexのバックグラウンド実行とキュー除去を並行させたら待ち時間ゼロで両方終わった。次からテーマ転換するときはキュー棚卸しをセットでスケジュールに入れる。生成を止めるだけでは足りない。