私はここ数か月、8人のAIエージェントが協力して、トピックを投稿可能なレベルのLinkedIn投稿に変換するシステムを構築してきました。単発のプロンプトではありません。パイプライン形式で、各エージェントには1つの役割があり、フィードバックループを通じて互いに作業を引き継ぎます。
仕組みと、学んだことを紹介します。
問題
私はLinkedInの投稿を手作業で書いていました。トピックを調べる、下書きを書く、編集する、ハッシュタグを見つける、ビジュアルを作る、予約投稿する。各投稿には45〜60分かかっていました。ワークフローを自動化したいと思いましたが、すぐに壁にぶつかりました。単一のプロンプトではこれらをうまく全部はできないのです。1つのLLMにリサーチ、執筆、検証、ビジュアル生成をまとめてやらせると、結果は全体的にどれも中途半端になります。
解決策は、作業を専門化したエージェントに分割することでした。つまり、それぞれが「1つのこと」を得意に実行するようにしたのです。
アーキテクチャ
Topic Research --> Writing --> Validation --> Visual Generation
^ |
| v
+--- Feedback Loop (if score below threshold)
Orchestratorが全パイプラインを管理します。投稿のスコアが品質しきい値を下回った場合、Writing Agentに戻し、どこを直すべきかを具体的にフィードバックします。ベスト・オブ・N方式のトラッキングにより、すべての書き直しが失敗しても、最後の試行ではなく、最も高いスコアの試みが保持されます。
エージェント
各エージェントは、BaseAgentクラスを継承します。このクラスは、リトライロジック付きのClaude APIコール、モデルフォールバック、使用量トラッキング、観測性（オブザーバビリティ）を提供します。
class BaseAgent:
def __init__(self, anthropic_client, config):
self.client = anthropic_client
self.model = config.get("model", "claude-sonnet-4-20250514")
def _call_claude(self, system_prompt, user_prompt, max_tokens=4096, model=None):
use_model = model or self.model
response = self._create_message_with_retry(
model=use_model,
max_tokens=max_tokens,
system=system_prompt,
messages=[{"role": "user", "content": user_prompt}],
)
return response.content[0].text
各エージェントが何をするかは以下の通りです：
TopicResearchAgent
コードベースやトピックの説明をスキャンし、複数の次元でバイラル度のスコアリングを行ったうえで、「投稿する価値のあるトピック」を抽出します。たとえば、その見解はどれほど物議を醸しやすいか、痛み（課題）はどれほど強いか、アドバイスはどれほど実行可能か、といった観点です。
WritingAgent
複数のフック（導入）パターンを使って投稿を作成し、さまざまなタイプの読者にも対応します。重要な設計はこうです。声（トーン＆スタイル）を制御するのは「voice」で、内容（実体）と語彙を制御するのは「audience」です。開発者向けの投稿ならツール名や設定が入ります。リーダーシップ向けの投稿ならチーム規模や組織の意思決定が入ります。語彙の境界設定により、専門用語が読者タイプをまたいで漏れ出すのを防ぎます。
ValidationAgent
投稿を0〜100で採点します。複数の評価器（それぞれが異なる品質次元を測定）を使います。価値提供、フックの効果、構造、声の真正性（オーセンティシティ）、エンゲージメント可能性などです。評価器の中には「ハードゲート」として振る舞うものもあります。文章がどれほど上手くても、間違ったトピックについての投稿は、そのスコアが上限付きで打ち止めになります。
VisualAgent
Geminiを使って1080x1080のインフォグラフィックを生成します。内容の分析、テキストの検証、画像生成を、多段階のパイプラインとして実行します。
VisualValidationAgent
GPT-4o Visionでビジュアルを検証します。Claudeではありません。自分自身への選好バイアスを避けるためです。校正カーブと品質ゲートに加えて、AIの審査員が見落としがちな「壊れたレンダリング」を検出する決定論的な色の多様性チェックも含まれています。
SchedulingAgent
ユーザーのタイムゾーンに基づいて、投稿間隔が最小になるような最適な投稿スケジュールを生成します。
CarouselAgent
マルチスライドのLinkedInカルーセルを生成します。Geminiがコンテンツを分解し、Playwrightがスライドをレンダリングし、出力は圧縮されたPDFになります。
SourceExtractionAgent
GitHub/GitLabのリポジトリから関連するコードスニペットを抽出し、Writing Agentが参照できる「実際のコード例」を提供します。
フィードバックループ
ここから面白くなります。Orchestratorはエージェントを単に順番に実行するだけではありません。検証ループを回します：
# 簡略化したオーケストレーターのループ
for attempt in range(max_rewrite_attempts):
draft = writing_agent.write_post(topic, hook_style)
validation = validation_agent.validate(draft)if validation.score >= min_score:
break # 十分良い
# 最良の試行を追跡する（最後のものだけではない）
if validation.score > best_score:
best_draft = draft
best_score = validation.score
# ターゲットを絞ったフィードバックをコンパイルする
feedback = compile_feedback(validation, previous_feedback)
draft = writing_agent.rewrite_post(draft, feedback)
重要な設計上の意思決定が2つあります。
ベスト結果のトラッキング：リライトループが 72、68、71 のようなスコアを出した場合、システムは 71 ではなくスコア72の下書きを使用します。これがないと、リライトによって後退（回帰）することがあります。
フィードバックの重複排除：フィードバックコンパイラは、「依然として壊れている（STILL BROKEN）」問題（試行を重ねる中で繰り返し出てくるもの）を、新しい問題から分離します。これにより、Writing Agent が同じ汎用的なフィードバックを3回も受け取るのを防ぎます。
LLM-as-Judge: What I Learned
Claude を使って Claude の出力をジャッジさせることで、いくつかのことを苦労して学びました。
Few-shot のキャリブレーションは不可欠です。 「この投稿を0〜100で評価して」というようなプロンプトは、70〜80あたりの圧縮されたスコアを生成します。各評価者には、スコア段階ごとにそれが実際にどう見えるかを示すキャリブレーション例が必要です。これにより、スコアの分布が狭い範囲から、実際の 20〜95 という幅のあるレンジへ広がりました。
自己選好バイアスは現実にある。 Claude による Claude の視覚出力の評価はスコアを過大評価しました。視覚検証を GPT-4o に切り替えたところ、すぐに解消しました。LLM-as-judge のシステムを作るなら、出力を生成するものとは別のモデルファミリーを使ってください。
決定論的チェックはAIジャッジを補完する。 Pillow を使った色の多様性チェックは、Claude と GPT-4o の両方が「許容できる」と評価してしまう壊れた Gemini のレンダリングを検出できます。場合によっては、単純なピクセル数のほうが最前線の2つのモデルより役に立ちます。
ハードゲートで“ごまかし”を防ぐ。 間違ったトピックについての投稿は、ほかのすべての指標では高得点になります。文章が上手いからです。忠実度（フィデリティ）チェックは、減点するだけでなく、ブレンドされたスコアに上限を設ける必要があります。そうしないと、間違ったトピックでも素晴らしい文章であれば、そのまま通ってしまいます。
The Tech Stack
- Python 3.12 + FastAPI：API用
- Anthropic Claude：執筆と評価用
- Google Gemini：視覚とカルーセル生成用
- GPT-4o：視覚検証用（自己選好バイアスを回避）
- Celery + RabbitMQ：非同期タスク処理用
- MongoDB：コンテンツの保存用
- Redis：キャッシュとタスク結果用
- LangSmith：トレーシング、評価データセット、プロンプト管理用
- React + Vite：フロントエンド用
コスト効率は、初日から優先事項でした。分類タスク（CTA検出や構造チェックなど）には軽量なモデルを使い、本当に高性能なモデルは実際の執筆と評価に温存することで、視覚を含めても投稿あたり1ドルを十分に下回るコストに抑えられています。
What I'd Do Differently
書く前に評価から始める。 私は Writing Agent を最初に作りましたが、その後「変更によって出力が改善したかを測る方法がない」ことに気づきました。評価者を先に作っていれば、フィードバックのサイクルをかなり短縮できたはずです。
ジャッジには別のモデルを使う。 自己選好バイアスにより1週間をデバッグに費やしました。システムがあるモデルで出力を生成するなら、それを検証するのは別のモデルで行ってください。
最初からリライトループを前提に設計する。 検証とリライトの間のフィードバックループこそが、品質の大部分を作ります。シングルショットのプロンプトでもそれなりの出力は得られます。しかし、公開（パブリケーション）レディにするのはリライトループです。
Try It
このシステムは postsmith.io で稼働しています。無料プランでは月6件の投稿が可能です。マルチエージェントのアーキテクチャに興味がある、またはAI評価システムの構築について質問があるなら、コメントしてください。この内容のどの部分でも、より深く掘り下げることができます。
Python、Claude、そして Gemini がインフォグラフィック上のテキストをなぜ間違った場所に置き続けるのかを解決するための徹夜すぎるデバッグで作りました。
