AI に記事生成を任せる運用では、品質以前に「生成器が止まる」問題があります。Cruxnote の TypeA 自動投稿で起きた JSON パースエラーも、表面上は形式エラーでしたが、根は Claude の usage limit 到達でした。つまり、記事の中身ではなく、LLM 呼び出しの単一点障害で投稿が止まっていたことになります。
この対策として設計されているのが、claude --print の直接呼び出しを scripts/llm-print.sh に集約し、Claude が空応答、usage limit、API error、期待形式不一致になった場合に Codex CLI へ fallback する仕組みです。TypeA 自動投稿では RSS 取得後に記事生成を1回行うため、この1回の生成失敗を別の LLM 実行枠で受けられる意味は大きいです。
ただし、これは「投稿全体を必ず成功させる」仕組みではありません。防げるのは、LLM が期待する JSON を返せないことで後続処理に進めなくなる停止です。RSS 候補がない、WordPress 投稿で失敗する、生成内容の品質が基準を満たさない、といった問題までは解決しません。
見方を変えると、Codex fallback の価値は代替モデルそのものより、失敗点を分離することにあります。これまで TypeA は、Claude の一時的な利用制限と記事生成品質を同じ失敗として扱っていました。ラッパー化により、少なくとも「LLM 実行枠の枯渇」と「記事として使えるか」を分けて観察できます。
TypeA の自動投稿を止めないために必要なのは、万能な生成 AI ではなく、壊れ方を想定した運用設計です。Codex fallback はその第一歩として、usage limit による停止を投稿不能ではなく再試行可能な経路に変えます。自動化の信頼性は、成功時の速さより、失敗時にどこまで狭く壊れるかで決まります。
出典: tasks/pending/media-llm-codex-fallback.md, docs/media-llm-codex-fallback-design.md, docs/media-llm-codex-fallback-test.md
コメント