マルチエージェントシステムの設計原則

3エージェントから始まった。SEOライター、コンプライアンスチェッカー、データフェッチャー。この3つを作ったのが最初の1日目です。4日後には13エージェントが連携して動いていました。

私はD2Cヘルスケア企業の代表で、5ブランドを1人で運営しています。日次タスクは30以上。SEO記事、FAQ作成、X投稿、CRM文面、LINE配信文、広告コピー、市場調査、デザイン、日次レポート。これを16種類 × 5ブランド分。人間1人では物理的に不可能な量を、マルチエージェントシステムが毎日処理しています。

この記事では、3エージェントから13エージェントに拡張した4日間の実体験と、その過程で学んだ設計原則を体系的にまとめます。理論ではなく、毎日動いているシステムから得た知見です。

Day 1：最初の3エージェント

最初に作ったのは、最も緊急度が高い3つでした。

1. SEOライターエージェント

5ブランドのSEO記事を毎日生成する必要がありました。キーワード選定、構成案作成、本文執筆、メタディスクリプション生成までを1つのエージェントに担当させました。これが最初の失敗でした。1つのエージェントに4つの責務を持たせたため、キーワード選定の精度が落ちると記事全体が崩壊する。Day 2でキーワードリサーチャーを分離することになります。

2. コンプライアンスチェッカーエージェント

ヘルスケア業界で薬機法違反は致命的です。2025年12月に薬務課の承認を取得した3層チェック構造を、このエージェントに実装しました。NGワードスキャン、文脈チェック、根拠チェック。これは最初から独立したエージェントにして正解でした。コンテンツ生成と同じエージェントに入れると、自分の出力を肯定するバイアスがかかり、チェックが甘くなるからです。

3. データフェッチャーエージェント

ECサイト（MakeShop/ecforce）、広告管理画面（Meta/Google/Amazon）、SNSからデータを自動取得するエージェント。朝4時に起動し、全データソースから前日データを収集します。5ブランド分のデータを15分で取得完了。

Day 2-3：失敗から学んだ設計原則

Day 1の3エージェントを動かしてすぐに問題が噴出しました。

失敗1：SEOライターが万能すぎた

「キーワードを選定して、構成を作って、本文を書いて、メタタグも生成して」

この設計は1日で破綻しました。理由は3つ。

• デバッグが困難：キーワード選定がおかしいのか、構成が悪いのか、本文の問題なのか切り分けられない
• プロンプトが肥大化：4つの責務をすべて指示すると、LLMのコンテキストウィンドウを圧迫して精度が落ちる
• ブランド間の混同：5ブランドの情報を1つのプロンプトに詰め込んだ結果、スカルプケアの記事にスキンケアの情報が混入

Day 2で分離しました。keyword-researcher、content-planner、seo-writer、meta-generatorの4つに。1エージェント1責務。これがソフトウェア設計のSOLID原則と同じく、マルチエージェントの鉄則です。

失敗2：エージェント間のデータ形式がバラバラ

データフェッチャーが吐き出すデータと、分析エージェントが期待するデータの形式が合わない。フェッチャーはCSV的な文字列を返し、分析エージェントはJSON配列を期待していた。

解決策として、全エージェントの入出力に統一されたJSON形式を導入しました。

{
  "agent_id": "data-fetcher-001",
  "timestamp": "2026-03-15T04:00:00+09:00",
  "status": "success",
  "data": {
    "sales_total": 4778000,
    "orders": 312,
    "new_customers": 48
  },
  "metadata": {
    "source": "makeshop_api",
    "brand": "kadason",
    "period": "2026-03-14"
  }
}

5ブランドのデータがすべてこのフォーマットで統一されるため、エージェントの差し替えが容易になりました。

失敗3：1つが壊れると全部止まった

Day 2の朝、MakeShopのAPIがメンテナンスでダウン。データフェッチャーが停止し、分析エージェントが「データがない」とエラー。レポートエージェントも停止。Slackに朝のレポートが届かず、異常に気づいたのは3時間後。

この経験から、フォールバック戦略を設計しました。

1. 前回値の再利用：データフェッチャーが停止したら、前日のデータでレポートを生成（注記付き）
2. スキップ：X投稿エージェントが停止しても、LINE配信エージェントは影響なく稼働
3. エスカレーション：コンプライアンスエージェントが停止したら、全コンテンツの公開を停止し、Slackで人間に通知

どのエージェントがどの戦略を使うかは、ビジネスリスクで決める。薬機法チェックが止まったらコンテンツ全停止。レポートは前日値でも致命傷にはならない。

Day 4：13エージェント完成

4日目に全13エージェントが稼働開始。具体的な内訳は以下です。

• data-fetcher：EC・広告・SNSから全ブランドのデータを取得
• analyzer：売上・ROAS・CPA・LTVを自動計算、異常値検出
• reporter：経営ダッシュボードを毎朝自動更新
• keyword-researcher：5ブランドのキーワード調査とスコアリング
• seo-writer：SEO記事の本文を自動生成
• ad-copywriter：広告コピーのA/Bテスト候補を生成
• crm-operator：CRM文面、LINE配信文、メルマガ原稿を生成
• compliance-checker：全コンテンツの薬機法3層チェック
• sns-manager：X投稿案・Instagram投稿案を生成
• faq-generator：顧客問い合わせデータからFAQを自動更新
• market-researcher：競合動向・市場トレンドを自動収集
• design-assistant：バナー・サムネイルの構成案を生成
• alerter：異常値検知時のSlack通知と対応案の提示

エージェント間の連携フロー：朝4時の実例

毎朝4時に起動する実際の連携フローを公開します。

1. 04:00 data-fetcherが5ブランドの売上・広告・SNSデータを収集（15分）
2. 04:15 analyzerが収集データを分析、異常値にフラグを立てる（10分）
3. 04:25 reporterがダッシュボードを更新（5分）
4. 04:30 keyword-researcherが検索順位変動を分析（20分）
5. 04:50 seo-writerがキーワードデータをもとに記事を生成（30分）
6. 05:00 並行してad-copywriter、crm-operator、sns-managerがコンテンツ生成（各20分）
7. 05:20 compliance-checkerが全コンテンツを一括チェック（15分）
8. 05:35 NGがあれば生成エージェントに差し戻し、修正→再チェック（10分）
9. 05:45 alerterが全結果をまとめてSlackに送信

人間が朝起きる頃には、全部終わっています。自動化前は1日1.5時間かかっていたこれらの作業が、今は人間の確認時間15分以内で完了します。

観測可能性：13エージェントを管理する仕組み

13エージェントが毎日動いていると、何かが壊れるのは「もし」ではなく「いつ」の問題です。

毎朝のダッシュボード

ログ、メトリクス、トレースの3本柱で観測可能性を確保しています。各エージェントの入出力、処理時間、エラー内容をすべて記録。1つのジョブがどのエージェントをどの順番で通過したか、エンドツーエンドで追跡可能です。

冪等性：再実行しても壊れない設計

各エージェントは同じ入力に対して常に同じ結果を返すように設計しています。ネットワーク障害やAPI制限で処理が中断されたとき、再実行してもデータが二重処理されない。

段階的デプロイ：いきなり全部を入れ替えない

新しいエージェントを追加するときの手順です。13エージェントが安定稼働している環境に、新しいエージェントをいきなり投入すると全体が壊れるリスクがあります。

1. シャドウモード：新エージェントを動かすが、出力は使わない。旧システムと並行稼働させ、結果を比較する
2. カナリアリリース：全体の10%のタスク（例えば1ブランド分だけ）を新エージェントに処理させる
3. 段階拡大：1ブランド → 3ブランド → 5ブランドと段階的に切り替える
4. ロールバック準備：問題が発生したら即座に旧設定に戻せるようにしておく

人間との接点設計：すべてを自動化しない勇気

13エージェントが自律的に動くシステムですが、人間が判断すべきポイントは必ず残す。これが設計の最後にして最も重要な原則です。

• 承認ゲート：外部公開コンテンツの最終承認（薬機法チェック済みでも、人間が最終GO/NO-GOを出す）
• 閾値アラート：広告ROASが急落した場合の予算判断
• 週次レビュー：エージェントの出力品質を人間がサンプルチェック
• 戦略変更：新ブランドの追加、ターゲット変更などの経営判断

これらは「エージェントが足りないから人間がやる」のではなく、「人間が判断すべきだから人間がやる」もの。自動化前に1日1.5時間かかっていた作業が15分になったのは、この線引きが正しかったからです。

技術スタック

参考までに、実際に使っている技術スタックを公開します。

• LLMバックエンド：Claude（Anthropic）をメイン、GPT-4を補助的に使用
• エージェントフレームワーク：Claude Code
• オーケストレーション：launchd（macOS）でスケジュール管理
• データストア：SQLite + PostgreSQL
• 監視：カスタムダッシュボード + Slack通知

重要なのは技術選定よりも設計原則を守ることです。責務分離、疎結合、冪等性、障害分離、観測可能性。これらが守られていれば、技術スタックは後から入れ替えられます。

まとめ：3エージェントから始めて、4日で13に拡張した

振り返ると、4日間で学んだ設計原則は7つです。

1. 単一責任：1エージェント1責務。万能エージェントは必ず壊れる
2. 疎結合：統一JSON形式でエージェントを独立させる
3. 冪等性：再実行しても結果が変わらない設計
4. 障害分離：1つが壊れても全体は止まらない
5. 観測可能性：ログ・メトリクス・トレースの3本柱
6. 段階的デプロイ：シャドウ → カナリア → フルデプロイ
7. 人間との接点設計：判断すべきところは人間に委ねる

最初から13エージェントを設計しようとしなくていい。まず3つ作る。動かす。壊れる。直す。そこから学んだ原則に従って拡張する。私たちはこの方法で4日間で13エージェントを立ち上げ、今も毎日安定稼働しています。5ブランド、日次30タスク以上、1日1.5時間の作業が15分に。これがマルチエージェント設計の実力です。