自分のブログ（chiapuru.com）向けに、記事の生成から配信までを自動化するエージェントシステムを構築した。
Agent1がトレンドを収集して記事を生成し、Agent2がchiapuru.com・Qiita・Zennに配信し、Agent3がXに投稿する。 GitHub Actionsで週次スケジュール実行され、人間がSupabaseで承認するだけで動く。
しかし、ループエンジニアリングを解説したQiitaの記事を読んで気づいた。 このシステムはまだ「パイプライン」であり、「ループ」ではない。
パイプラインは品質が水平に流れる
パイプラインとは、決められた処理を決められた順序で流すだけの構造だ。
自分のシステムで言えば、同じプロンプト・同じルールで毎週記事が生成される。 Agent4がQiitaのいいね数やPVを収集してSlackに投げるが、その数字は次の記事生成に何も影響しない。
つまり品質は改善されない。最初の記事も100本目の記事も、生成プロセスの質は同じだ。
ループは成果が入力を書き換える
ループとの違いは、出力が次の入力に戻るかどうかだ。
パイプライン:
入力 → 処理 → 出力 → 入力 → 処理 → 出力（水平に流れる）
ループ:
入力 → 処理 → 出力
↑ |
└── 成果の分析 ──┘（螺旋状に上昇する）
記事の質を上げていくループが閉じた状態とは、たとえばこういうことだ。
- PVが高かった記事のタイトルパターン → Agent1のトピック選定プロンプトに注入する
- いいね数が伸びた記事の構成 → writing-rulesに自動反映する
- 読者が離脱しやすい章の位置 → 記事構造のテンプレートを修正する
これが実装されてはじめて、週を追うごとに記事の質が上がっていく。
人間がオーケストレートするか、AIがオーケストレートするか
ループとパイプラインの違いを別の角度から見ると、「誰がオーケストレートしているか」の問題でもある。
現在の自分のシステムでは、人間が次のことを判断している。
- 承認（Supabaseでdraft → approvedに手動更新）
- 次週のテーマ方針（Agent4のSlackレポートを見て人間が決める）
AIのオーケストレート比率が上がれば上がるほど、ループの概念に近づく。 ただし、比率だけを上げてもループにはならない。フィードバックが閉じていなければ、高度に自動化されたパイプラインになるだけだ。
ループ度を決めるのは「自動化の度合い」と「フィードバックの閉鎖度」の2軸だ。
人間の承認をどこに残すか
フィードバックを自動化するほど、人間の介在点を減らすほど、ループは自律的に動くようになる。
一方で、品質に責任を持つポイントは残す必要がある。 誤情報が自動投稿されたり、一人称トーンがズレた記事が自動公開されたりするリスクは、自動化が進むほど高くなる。
自分が選んでいるバランスは「生成はAI・承認は人間」だ。
承認以外のオーケストレーションをすべてAIに移譲しつつ、公開前の最終チェックだけ人間が握る。 このポイントだけ残せば、フィードバックループを自動化してもシステムが暴走するリスクは低い。
今のシステムに足りないもの
自分のAgent4（効果測定）は、現状「観測はしているが学習していない」状態だ。
Supabaseにメトリクスを貯めているにもかかわらず、そのデータがAgent1のプロンプトに戻っていない。 ここを繋ぐだけで、システムの性格が「パイプライン」から「ループ」に変わる。
具体的な実装は単純だ。
// Agent1起動時に、過去の高PV記事タグをSupabaseから取得する
const topTags = await getTopPerformingTags({ limit: 5 });
// システムプロンプトに注入する
const systemPrompt = `${BASE_PROMPT}
なお、過去の高PV記事で多く使われたタグは ${topTags.join(', ')} です。
これらのテーマに関連するトピックを優先してください。`;
たったこれだけで、フィードバックが閉じる。
ループは目的ではなく手段
ループを完成させることが目的ではない。 記事の質が週を追うごとに上がり、読者が増え、サイトの価値が高まる、それが目的だ。
ループはその手段として機能する。 パイプラインのまま運用し続けることも選択肢の一つだが、成果が同じ水準で流れ続けることを受け入れる必要がある。
自分は記事の質を改善していきたいので、フィードバックループを閉じる実装を次のフェーズで追加する予定だ。