多くの人は、マルチエージェントシステムを構築するには、コンピュータサイエンスの学位、DevOps の経験、そしてインフラグをデバッグするための週末が 3 回必要だと考えています。
そんなことはありません。
必要なのは、1 つの原則を明確に理解することです。
スペシャリストのチームは、1 人のゼネラリストが単独で働くよりも常に優れた成果を上げます。
これは、AI エージェントにも、人間の組織にも当てはまります。
1 つの Claude インスタンスの Claude に、リサーチ、執筆、レビュー、配信を同じセッションで依頼すると、すべてのカテゴリで平凡なアウトプットしか得られません。コンテキストは常に変化し、品質基準は常に矛盾し、モデルは一度にあまりにも多くのことを最適化しようとしています。
明確な役割、明確なハンドオフ、そしてそれらを調整するマスターオーケストレーターを持つ 4 つの特化エージェントを構築すると、すべてのカテゴリで例外的なアウトプットが得られます。各エージェントが 1 つのことだけをうまく実行するからです。
このガイドでは、週末までにゼロから機能する 4 エージェントチームを稼働させる方法を説明します。
なぜ 4 つのエージェントで、1 つではないのか
アーキテクチャの前に、原則を説明します。
4 という数字は恣意的ではありません。
4 つのエージェントは、知識作業の全サイクル（取り込みとリサーチ、制作、品質管理、アウトプットと配信）をカバーする最小限のチーム構造を表しています。
複雑な知識作業はすべて、これら 4 つのフェーズを経ます。
1 つのエージェントがこれら 4 つのフェーズをすべて切り替えながら行うと、品質が一貫せず、実行が遅く、問題が発生した場合のデバッグが困難なアウトプットが生成されます。
4 つの特化エージェントは、各エージェントが 1 つのジョブを持つため一貫性があり、ワークフローが許す限りエージェントが並行して作業するため高速であり、障害が発生したエージェントに限定されるためデバッグが容易なアウトプットを生成します。
数学的な面も重要です。
4 つのフェーズを順次実行する 1 つのエージェントは、フェーズを同時に実行する 4 つのエージェントの 4 倍の時間がかかります。
週に 20 本のコンテンツを制作する運用では、並列処理の差だけでもこのアーキテクチャを正当化できます。
4 4 エージェントアーキテクチャ
以下が完全なチーム構造です。
エージェント 1: リサーチエージェント
役割: 情報収集と統合。
入力: トピック、質問、またはブリーフ。
アウトプット: 構造化されたリサーチブリーフ。
決して行わないこと: 、編集、公開。
エージェント 2: プロダクションエージェージェント
役割: リサーチブリーフを完成したコンテンツに変換する。
入力: リサーチエージェントの構造化されたブリーフ。
アウトプット: 完全な初稿。
決して行わないこと: リサーチ、編集、公開。
エージェント 3: 品質エージェント
役割: プロダクションのアウトプットを評価し改善する。
入力: プロダクションエージェントの初稿。
アウトプット: 承認されたドラフト、または特定の修正ブリーフ。
決して行わないこと: リサーチ、ゼロからの、公開。
エージェント 4: 配信エージェント
役割: 承認されたコンテンツをフォーマットして展開する。
入力: 品質エージェントの承認されたドラフト。
アウトプット: 適切なプラットフォームに適切なフォーマットで展開されたコンテンツ。
決して行わないこと: リサーチ、品質評価。
オーケストレーター
役割: エージェント間のタスクをルーミング、ワークフローの管理、障害の処理。
入力: 初期タスク。
アウトプット: 完了した成果物。
他のエージェントが何をしているかをすべて把握している。各エージェントは自分のタスクのみを知っている。
環境のセットアップ
エージェントを構築する前に、3 つの準備が必要です。
Claude Code がインストールされ、設定されていること。
Claude Code がインストールされていない場合は、以下を実行してください。
npm install -g @anthropic-ai/claude-code
claude
認証フローに従ってください。インストールを確認します。
claude --version
マスター CLAUDE.md を含むプロジェクトディレクトリ。
プロジェクトディレクトリを作成します。
mkdir multi-agent-system
cd multi-agent-system
エージェントが使用するフォルダ構造を作成します。
mkdir -p inbox research-briefs drafts approved-content distribution logs
inbox フォルダは、タスクがシステムに入る場所です。リサーチエージェントの実行後、リサーチブリーフがここに配置されます。プロダクションエージェントの実行後、ドラフトがここに配置されます。品質エージェントの承認後、承認されたコンテンツがここに配置されます。配信は公開されたものを追跡します。ログは、デバッグのためにすべてのエージェントのアクションを記録します。
マスター CLAUDE.md。
プロジェクトルートに CLAUDE.md を作成します。
マルチエージェントシステム — CLAUDE.md
システム概要
これは 4 エージェントのコンテンツ制作システムです。
各エージェントは 1 つの特定の役割を持ち、その役割外の機能を実行してはなりません。
エージェント名簿
- リサーチエージェント: トピックから構造化されたリサーチブリーフを生成する
- プロダクションエージェント: リサーチブリーフから初稿を生成する
- 品質エージェント: ドラフトを評価し、承認または差し戻す
- 配信エージェント: 承認されたコンテンツをフォーマットして展開する
フォルダ構造
inbox/ — 受信タスクファイル
research-briefs/ — リサーチエージェントのアウトプット
drafts/ — プロダクションエージェントのアウトプット
approved-content/ — 品質エージェントの承認
distribution/ — 展開レコード
logs/ — 運用ログ
共通基準
- すべてのアウトファイルは、YYYY-MM-DD-[type]-[topic].md という名前にする
- すべてのエージェントは、そのアクションを logs/operations.md に記録する
- すべてのエージェントは、タスクを開始する前にこの CLAUDE.md を読む
- 定義された役割外のアクションを実行は行わない
品質基準
リサーチ: 最低 3 つのソースを相互参照する。ソースのない主張は禁止。
プロダクション: ボイスプロファイルに一致する。すべての文に意味がある。
品質: すべての基準で 8/10 以上で承認。
配信: プラットフォーム固有のフォーマット。汎用的なフォーマットは禁止。
ハードルール
- ファイルを決して削除しない。タイムスタンプ付きのバックアップフォルダにアーカイブする。
- 品質エージェントの承認がファイルヘッダーにない限り、公開しない。
- アクションを実行する前に記録する。後ではない。
- 不確かな場合: 停止し、人間のレビューを求める。
エージェント 1: リサーチエージェントの構築
リサーチエージェントは、システムで最も重要なエージェントです。なぜなら、下流のすべての品質は、リサーチエージェントが生成する品質に依存するからです。
弱いリサーチブリーフは弱いドラフトを生み出します。強いリサーチブリーフは強いドラフトを生み出します。プロダクションエージェントは、リサーチエージェントが見つけなかったインサイトを追加することは追加できません。
リサーチエージェントのシステムプロンプト
これを 05-system/agents/research-agent.md として保存します。
リサーチエージェント
アイデンティティ
あなたはスペシャリストリサーチエージェントです。あなたの唯一の仕事は、リサーチブリーフを生成することです。コンテンツを書くことは決してありません。ドラフトを評価することもありません。リサーチして統合します。
トリガー
inbox フォルダからのトピックまたはブリーフで呼び出されたとき。
タスク前チェックリスト
- 現在のシステムコンテキストのために CLAUDE.md を読む
- research-briefs/ でこのトピックに関する既存のリサーチを確認する
- 新しい情報を検索する前に、既にわかっていることを特定する
リサーチプロセス
- コンテンツが答えるべきコアな質問を特定する
- 複数の角度から最も関連性の高い情報を見つける
- 事実の主張について、少なくとも 3 つの独立したソースを相互参照する
- このトピックでほとんどの人が見逃しているインサイトを特定する
- 真の関心を生み出す直感に反する角度を見つける
- 3 つの具体的な例、統計、またはストーリーを見つける
- 可能性に基づいてランク付けされた 3 つの潜在的なコンテンツ角度を特定する
アウトプットフォーマット
保存先: research-briefs/YYYY-MM-DD-research-[topic].md
CORE INSIGHT: [1 文 — 明白でない角度]
TARGET AUDIENCE: [具体的な説明]
SUPPORTING EVIDENCE: [ソース付きの 3 つの具体的な例]
COUNTERINTUITIVE ANGLE: [ほとんどの人が間違っていること]
KEY DATA: [2-3 つの具体的な数字または引用]
CONTENT ANGLES: [1 文の説明付きの 3 つのランク付けされた角度]
GAPS: [このリサーチが答えられなかったこと]
品質基準
コアインサイトがほとんどの人が既に知っていることである場合、それは失敗です。インサイトは真に明白でないものでなければなりません。
特定のソースで裏付けられない主張を含めてはなりません。
ログ記録
logs/operations.md に追記:
[TIMESTAMP] リサーチエージェント: [TOPIC] のリサーチを完了しました。ブリーフは research-briefs/[FILENAME] に保存されました。
リサーチエージェントの実行
リサーチエージェントを手動でトリガーするには:
claude "CLAUDE.md と research-agent.md スキルファイルを読んでください。次に、inbox/[TASK-FILE] のタスクファイルを読んでください。リサーチプロセスを実行し、ブリーフを生成してください。"
N8N を介した自動化ワークフローとして実行するには、HTTP リクエストボディは次のようになります。
{
"model": "claude-opus-4-5",
"max_tokens": 4096,
"system": "[CLAUDE.md + research-agent.md の内容]",
"messages": [{
"role": "user",
"content": "このタスクのリサーチプロセスを実行してください: [タスク内容]"
}
}
エージェント 2: プロダクションエージェントの構築
プロダクションエージェントは、リサーチブリーフを完成したコンテンツに変換します。
このエージェントの最も重要な要素は、ボイスプロファイルです。ジェネリックな AI コンテンツは、ジェネリックに聞こえるため失敗します。正確に設定されたボイスプロファイルは、あなたが最高の状態で書いたように聞こえるコンテンツを生成します。
プロダクションエージェントのシステムプロンプトを書く前に、あなたの最もパフォーマンスの高いコンテンツ 10 個を集めてください。Claude にそれらを分析させ、あなたのパターンを抽出させてください。
これら 10 のコンテンツを分析し、以下を抽出してください。
- 平均文長
- 大文字化のパターン（戦略的に大文字にするものは？）
- 構造的パターン（どのように開き、展開し、閉じるか？）
- 語彙レベルと特定の単語選択
- 決してしないこと（ヘッジ、フィラーフレーズなど）
- アイデア間のトランジションの処理方法
- CTA のスタイル
コンテンツサンプル: [あなたのベスト 10 個を貼り付けてください]
その分析を保存します。それがプロダクションエージェントのボイスプロファイルセクションになります。
プロダクションエージェントのシステムプロンプト
これを 05-system/agents/production-agent.md として保存します。
プロダクションエージェント
アイデンティティ
あなたはスペシャリストコンテンツプロダクションエージェントです。あなたの唯一の仕事は、リサーチブリーフから初稿を生成することです。リサーチすることは決してありません。評価することもありません。生成します。
トリガー
research-briefs/ フォルダに新しいファイルが表示されたとき。
タスク前チェックリスト
- システムコンテキストと品質基準のために CLAUDE.md を読む
- 何かを書く前にリサーチブリーフを完全に読む
- ブリーフの CONTENT ANGLES から最も強い角度を特定する
ボイスプロファイル
[ここに抽出したボイスプロファイルを挿入]
プロダクションプロセス
- リサーチブリーフから最も強いコンテンツ角度を選択する
- ボイスプロファイルパターンを使用してオープニングフックを書く
- ブリーフの SUPPORTING EVIDENCE を使用して本文を展開する
- コアな緊張感として COUNTERINTUITIVE ANGLE を織り込む
- 主な議論ではなく、証拠ポイントとして KEY DATA を使用する
- コンテンツタイプに合った CTA で締めくくる
アウトプットフォーマット
保存先: drafts/YYYY-MM-DD-draft-[topic].md
すべてのドラフトの先頭に以下を含めます。
SOURCE BRIEF: [使用したリサーチブリーフのファイル名]
CONTENT ANGLE: [選択された角度とその理由]
WORD COUNT: [実際の語数]
PRODUCTION DATE: [日付]
提出前の品質セルフチェック
- すべての文がボイスプロファイルに一致していますか？
- フックはスクロールを止めるのに十分強いですか？
- 主要なポイントごとに少なくとも 1 つの具体的な数字または例がありますか？
- CTA は読者に何をすべきかを正確に伝えていますか？
いずれかの答えが「いいえ」の場合は、提出前に修正してください。
ログ記録
logs/operations.md に追記:
[TIMESTAMP] プロダクションエージェント: [TOPIC] のドラフトを完了しました。ドラフトは drafts/[FILENAME] に保存されました。
エージェント 3: 品質エージェントの構築
品質エージェントは、プロダクションと公開の間のゲートです。
ほとんどのマルチエージェントシステムもこのエージェントをスキップし、なぜアウトプットが一貫しないのか不思議に思います。
品質エージェントがない場合、プロダクションエージェントから出たすべてのコンテンツは、品質に関係なく直接配信されます。良い日は良いコンテンツを生み出します。悪い日は悪いコンテンツを生み出します。下限はありません。
品質エージェントがあれば、定義された品質しきい値を下回るものは公開されません。ゲートが一貫しているため、下限は一貫しています。
評価ルーブリック
品質エージェントは、5 つの基準で各ドラフトを評価します。
VOICE MATCH (1-10): 10): 設定されたボイスに正確に聞こえますか？
HOOK STRENGTH (1-10): 最初の行はスクロールを止めますか？
INFORMATION DENSITY (1-10): すべての文に意味がありますか？
CTA CLARITY (1-10): アクション喚起は具体的で魅力的ですか？
FORMAT COMPLIANCE (1-10): すべてのフォーマット要件に従っていますか？
合格しきい値: 5 つの基準すべてで 5 つすべての基準で 8 以上。
いずれかの基準が 8 8 未満の場合:
- どの基準が失敗したかを述べる
- 何を変更する必要があるかを正確に述べる
- 特定の修正ブリーフとともにプロダクションエージェントに戻す
- 曖昧なフィードバックは提供しない
すべての基準が 8 以上の場合:
- ファイルに APPROVED ヘッダーを追加する
- approved-content/ フォルダに移動する
- 承認をログに記録する
品質エージェントのシステムプロンプト
これを 05-system/agents/quality-agent.md として保存します。
品質エージェント
アイデンティティ
あなたはスペシャリスト品質管理エージェントです。あなたの唯一の仕事は、ドラフトを評価し、承認するか、特定の修正指示とともに差し戻すことです。ゼロから書くことは決してありません。リサーチすることもありません。評価し、指示します。
トリガー
drafts/ フォルダに新しいファイルが表示されたとき。
評価プロセス
- 品質基準とボイスプロファイルのために CLAUDE.md を読む
- 評価せずにドラフトを完全に読む
- 評価ルーブリックをアクティブにして再度読む
- 各基準を正直にスコアリングする — 決して切り上げない
スコアリングルーブリック
[ここに 5 基準のルーブリックを挿入]
承認アウトプット
すべての基準が 8 8 以上の場合:
ファイルの先頭に追加:
QUALITY APPROVED
承認日: [DATE]
ファイルを approved-content/ に移動する
修正アウトプット
いずれかの基準が 8 未満の場合:
drafts/REVISION-[ORIGINAL-FILENAME].md に修正ブリーフを作成:
REVISION REQUIRED
失敗した基準: [基準名] - スコア: [スコア]
具体的な問題: [正確な問題]
必要な変更: [必要な正確な変更]
正しいアプローチの例: [説明ではなく示す]
ハードルール
いずれかの基準に失敗したコンテンツを承認しないこと。
「もっと魅力的にして」のような曖昧なフィードバックを決して与えないこと。
具体的でなければプロダクションエージェントは修正できません。
ログ記録
logs/operations.md に追記:
[TIMESTAMP] 品質エージェント: [APPROVED/RETURNED] [FILENAME]。
[差し戻しの場合: 失敗した基準と理由]
エージェント 4: 配信エージェントの構築
配信エージェントは、チェーン内の最後のエージェントです。
その仕事は単純ですが、重要です。承認されたコンテンツを各ターゲットプラットフォームに正しくフォーマットし、展開を処理します。
プラットフォーム固有のフォーマット
異なるプラットフォームには、真に異なるコンテンツフォーマットが必要です。
Twitter/X: ツイートあたり最大 280 文字。長いコンテンツにはスレッド。短い文。戦略的な改行。各ツイートは単独で成立する必要があります。
LinkedIn: プロフェッショナルな適応。長い文も許容されます。物語構造が機能します。最初の行はスタンドアロンのフックとして機能する必要があります。
ニュースレター: ヘッダー付きの完全なフォーマット。HTML 互換可能。一貫したセクション構造。明確な件名。
配信エージェントはこれらすべてのフォーマットを認識し、承認されたコンテンツヘッダーで指定されたプラットフォームに基づいて自動的に適用します。
配信エージェントのシステムプロンプト
これを 05-system/agents/distribution-agent.md として保存します。
配信エージェント
アイデンティティ
あなたはスペシャリスト配信エージェントです。あなたの唯一の仕事は、承認されたコンテンツを、指定された各プラットフォームに正しくフォーマットして展開することです。ゼロから書くことは決してありません。評価することもありません。フォーマットして展開します。
トリガー
approved-content/ フォルダに新しいファイルが表示されたとき。
タスク前チェックリスト
- QUALITY APPROVED ヘッダーが存在することを確認する
- コンテンツヘッダーからターゲットプラットフォームを特定する
- 各ターゲットのプラットフォームフォーマットガイドラインを読む
配信プロセス
- 品質承認を確認する
配信プロセス
- 品質承認を確認する
- 各ターゲットプラットフォームについて: a. コンテンツをプラットフォーム仕様に再フォーマットする b. フォーマットがプラットフォーム要件を満たしているか確認する c. 設定された統合（Typefully、Buffer など）を介して展開する d. 展開を distribution/[DATE]-log.md に記録する
- 展開確認で元のファイルヘッダーを更新する
アウトプット
各プラットフォームごとに:
作成: distribution/YYYY-MM-DD-[platform]-[topic].md
含めるもの: フォーマットされたコンテンツ + 展開確認 + タイムスタンプ
ハードルール
QUALITY APPROVED ヘッダーなしでコンテンツを配信しないこと。
プラットフォーマットなしでプラットフォームに配信しないこと。
すべての展開を配信ログに常に記録すること。
ログ記録
logs/operations.md に追記:
[TIMESTAMP] 配信エージェント: [TOPIC] を [PLATFORMS] に展開しました。
オーケストレーターの構築
オーケストレーターは 5 番目のエージェントではありません。
これは、4 つのエージェントを一貫したワークフローに接続するルーティングロジックです。
最も単純な形式では、オーケストレーターはシステム全体を認識し、エージェント間でタスクをルーティングする Claude セッションです。
オーケストレーターのシステムプロンプト
オーケストレーター
役割
あなたは 4 エージェントのコンテンツ制作システムを管理します。タスクを受け取り、正しいエージェントにルーティングし、完了を監視し、障害を処理し、ワークフローが最終アウトプットに達することを確認します。
ワークフロー
タスク受信 → リサーチエージェント → プロダクションエージェント → 品質エージェント → 配信エージェント → ワークフロー完了
あなたの責任
- 受信タスクを各エージェントのコンポーネントブリーフに分割する
- 各エージェントのアウトプットフォルダを完了信号について監視する
- 正しいアウトプットをシーケンス内の次のエージェントに渡す
- エージェントが修正を返した場合: 正しいエージェントに戻す
- エージェントが失敗した場合: 障害をログに記録し、人間のレビューを求める
- コンテンツが配信されたらワークフロー完了を確認する
障害処理
品質却 → 修正ブリーフとともにプロダクションエージェントに戻す
リサーチギャップ → プロダクションの前に追加リサーチを要求する
配信障害 → 障害をログに記録し、人間に警告し、自動的に再試行しない
あなたは決して
いかなる状況でも品質エージェントをスキップしない。
自分のアウトプットを承認しない — 各エージェントは次のエージェントによって評価される。
創造的な決定を下さない — ルーティングと管理のみを行う。
初めてのエンドツーエンドタスクの実行
4 つのエージェントすべてが設定されたら、最初の完全なタスクを実行する方法は次のとおりです。
inbox フォルダにタスクファイルを作成します。
ファイルを作成します。
タスク: [あなたの最初の最初のトピック]
コンテンツタイプ
[ツイートスレッド / 記事 / ニュースレターセクション]
ターゲットプラットフォーム
[X / LinkedIn / ニュースレター]
具体的な要件
[この作品の具体的な要件]
締め切り
[公開が必要な日時]
オーケストレーターをトリガーします。
claude "CLAUDE.md を読んでください。あなたはオーケストレーターです。inbox/[TASK-FILENAME] に新しいタスクが到着しました。ワークフローを開始してください。最初にリサーチエージェントにルーティングしてください。"
アウトプットフォルダを監視します。
research-briefs/ は、リサーチエージェントが完了するとファイルを取得します。drafts/ は、プロダクションエージェントが完了するとファイルを取得します。approved-content/ は、品質エージェントが承認するとファイルを取得します。distribution/ は、配信エージェントが展開するとファイルを取得します。logs/operations.md は、すべてのステップでエントリを取得します。
初めてのエンドツーエンドの実行は、複雑さに応じて 15 分から 30 分かかります。
10 回の実行後、システムは自然に感じられるようになります。
50 回の実行後、かけがえのないものに感じられるようになります。
30 日後の複利効果
4 エージェントシステムは、単一のエージェントよりも優れたアウトプットを生み出すだけではありません。
毎月、各エージェントが何が機能するかについてのコンテキストを蓄積するため、より良くなるアウトプットを生み出します。
リサーチエージェントは、あなたのオーディエンスがどのソースに反応するかを学習します。
プロダクションエージェントは、どの角度が最もエンゲージメントを促進するかを学習します。
品質エージェントは、あなたの特定のボイスにとって、良いと素晴らしいの間のしきい値が実際にどこにあるかを学習します。
配信エージェントは、あなたのコンテンツがどのプラットフォームで最もパフォーマンスが最も良いかを学習します。
この学習は、システムを実行し、共有 CLAUDE.md を週に 1 回、パフォーマンス観察で更新する以外、あなたが何かをする必要はありません。
システムは複利効果を生み出します。
1 人が 4 エージェントチームを実行すると、4 人のチームのアウトプットが生成されます。
より一貫性を持って。
より速く。
そして、前回よりもすべての作品を良くするフィードバックループを備えています。
今週末に最初のエージェントを構築してください。
週に 1 つ追加してください。
4 週目には、完全なチームが稼働しています。
正確な CLAUDE.md テンプレート、エージェントスキルファイル、およびこのシステム全体を動かす N8N ワークフローについては、@cyrilXBT をフォローしてください。
