AIエージェント運用に学ぶブログ自動化の分業設計

AIエージェントを本番運用する事例では、ひとつのモデルへ全部を任せるのではなく、仕事を分け、評価し、失敗時に止める設計が重視されています。この考え方は、小さなブログ自動化にもそのまま使えます。

先に結論

ブログ自動化は、次の4工程を分けると安定します。

1. 情報を収集して候補を作る

2. 記事と画像を生成する

3. 出典、重複、本文品質を監査する

4. 合格した記事だけを公開し、外部表示を検証する

重要なのは、生成と公開を同じ成功条件にしないことです。記事ファイルができても、監査に通るまではWordPressの下書きに留めます。noteはWordPress公開後の要点版として別の待ち行列で処理します。

AWS Machine Learning Blogで公開された3事例は用途が異なりますが、運用上の共通点があります。

Thrad.aiの事例では、見込み顧客の発見からメール生成までを複数エージェントで処理し、SwarmとGraphの2つのオーケストレーション方式を、遅延、費用、品質で比較しています。スコアリング、意図分類、時間経過による重み付けに加え、本番向けのガバナンスも組み込んでいます。

ブログ運用に置き換えると、「どのモデルが賢いか」だけでなく、収集、執筆、監査、公開のどこを誰が担当し、何を基準に次へ進めるかを明示する必要があります。

Amazon Nova Actを使ったQA Studioの事例では、回帰テストをテストスイートとしてまとめ、並列実行し、CLIからCI/CDへ組み込んでいます。単発のテスト成功ではなく、継続的に同じ基準を適用できる形です。

記事公開でも、HTTP 200だけでは不十分です。タイトル、主要出典、アイキャッチ、OGP、カテゴリ、著者情報、関連記事、内部パスの混入をひとつの検証セットとして扱うと、確認漏れを減らせます。

Bluesightの事例では、単一製品向けのAIプロトタイプから、6つの医療コンプライアンス製品を横断する仕組みへ段階的に拡張しています。最初の機能を利用現場へ出した後、より複雑な複数製品対応へ進む流れです。

個人ブログでも、最初から投稿先や自動処理を増やすより、WordPressを本体、noteを要点と導線に固定し、公開本数を絞って検証するほうが改善点を追いやすくなります。

今回、実際の自動投稿経路を追ったところ、記事生成後すぐWordPressへ公開し、その後に監査する順序になっていました。これでは監査が問題を見つけても公開済みです。

そこで処理順を次のように変更しました。

1. 同じslugでWordPress下書きを作る

2. WordPress本文とnote要点版をローカル監査する

3. `ready_for_publish=true` の記事だけpublishへ更新する

4. 外部URLから表示内容を再検証する

5. noteは公開済みWordPress URLを確認してから1件ずつ投稿する

監査には、本文中で切れた原題、長い未翻訳要約、記事テーマと出典の明らかな不一致も追加しました。再実行時は既存アイキャッチを再利用し、同じ画像を増やし続けないようにしています。

この分業なら、AIを使う範囲を広げても、公開品質を守るゲートは独立したままです。