自動記事生成で、本文・要約・タイトルを一つのprovider呼び出しとして扱うと、部分的な失敗からの復旧が難しくなります。

予兆（YOCHO）では、生成候補を非公開のdraftとして保存し、本文・要約・タイトルを段階的に検証する構成にしました。本稿は実装・運用上の設計メモです。サービスの現在地は https://yocho.ai で確認できます。

1. 失敗を「全文失敗」にしない

記事化の処理は、概念的には次のphaseに分けます。

source snapshot
  -> body generation
  -> body checkpoint
  -> summary generation
  -> title validation / title repair
  -> final publication transaction

本文が成功して要約だけが失敗した場合、本文を再生成してはいけません。本文の候補、source digest、response digest、費用receiptを保存したcheckpointを要約phaseの入力にします。

2. draftと公開済み記事を分ける

provider応答は、品質検証前にeditorial_draftsへ保存します。保存するのは、次のような監査に必要なbounded receiptです。

sourceのdigest/hash
provider応答のdigest
call IDとphase
費用receipt
品質判定
タイトル補正前後

APIキーやHTTP header、providerの応答本文そのものは保存しません。候補draftと公開済み編集稿を同じレコードの「成功」として扱わないことが重要です。

3. known failureとunknown failure

再試行の判断は、HTTP statusだけではなく、外部処理の結果と課金の確定状態で分けます。

状態	扱い
応答・課金が確定した検証失敗	対象phaseだけを限定的に一回修復
429など再試行可能な拒否	共有backoffと上限に従う
timeout・通信断・請求結果不明	unknown hold。自動再送しない
保存済み本文があり、source identityが一致	本文を再生成せず再検証

結果不明を自動再送しないのは、品質よりも費用のためだけではありません。同じ呼び出しが実は成功していた場合、重複生成と二重計上が起こるからです。

4. 具体例：タイトルは本文とは別の品質境界にする

本文が妥当でも、タイトルには別の問題が入ります。

空文字やページ番号だけになる
出典にない数量が入る
source_urlやJSONなどのmetadataが漏れる
企業名が曖昧一致になる
英語の原見出しが日本語記事タイトルとして残る

TDnetのような企業開示資料では、取得済みのissuer_nameとlisting_titleから安全なタイトルを構成し、同じvalidatorを通します。それでも修正が必要なら、本文を作り直さずタイトル専用phaseを使います。

公開許可はprovider応答時だけで決めません。NewsEditorial.status='published'へ変更する最終transaction内でも、source snapshotを使ったタイトル品質ゲートを再実行します。

5. 実装で見えたこと

2026年9月14日の固定救済対象は95 task IDsでした。v2では本文を全件再利用し、保存済み要約も条件が一致するものは再利用しました。英語原見出しへ置換された43件は、本文と要約を保持して日本語タイトルへ修正しています。

この95件の救済完了を、元の3,356件全体の処理完了と混同しないよう、manifestとreceiptを別に持ちます。成功件数だけを見てqueueが空になったと判断しないためです。

6. まとめ

自動記事化の再現性を上げる鍵は、モデルを交換することだけではありません。

provider候補を公開前に保存する
本文・要約・タイトルを別phaseにする
known/unknown failureを分ける
再生成ではなく、保存済み候補を再検証・救済する
最終公開transactionでも品質ゲートを通す

これは設計・運用上の実装記録であり、すべてのAI生成内容が正しいことを保証するものではありません。実際のサービスと現在の公開情報は https://yocho.ai を参照してください。