OpenClaw を使用したマルチエージェント オーケストレーション パターン

単一の AI エージェントでプロセスを自動化できます。適切に調整されたエージェント システムにより、ビジネス機能を自動化できます。違いは、エージェントが境界を越えて調整し、通信し、障害を処理する方法にあります。マルチエージェント オーケストレーションは、独立したボットの集合と一貫性のある信頼性の高い自律システムとの間に違いをもたらすエンジニアリング分野です。

OpenClaw は、型指定されたメッセージ バス、エージェント レジストリ、ハンドオフ プロトコル、共有メモリの名前空間、エージェントの境界を越えてリクエストを追跡する分散トレースなど、マルチ エージェント オーケストレーションの基本要素を提供します。このガイドでは、4 つの基本的なオーケストレーション パターン、それぞれをいつ使用するか、OpenClaw での実装方法、および設計の対象となる障害モードについて説明します。

重要なポイント

• スーパーバイザーとワーカーのパターンは最も一般的なアーキテクチャです。1 つの調整エージェントが目標を分解し、専門のワーカーに委任します。
• パイプライン パターンは、各ステージが次のステージへの入力を生成する、順次ドキュメント処理または複数ステップのデータ変換に最適です。
• コンセンサス パターンにより、複数の独立したエージェントが同じ質問を評価できるようになり、一か八かの意思決定における単一エージェントのエラーのリスクが軽減されます。
• Market-Maker パターンは、最も有能な利用可能なエージェントにタスクを動的に割り当て、負荷分散と適切な機能低下を可能にします。
• エージェント間通信では、OpenClaw の型付きメッセージ バスを使用します。生の文字列の受け渡しや、エージェント間での共有の変更可能な状態はありません。
• 分散トレースはマルチエージェントのデバッグに不可欠です。すべてのメッセージにはエージェントの境界をまたがる相関 ID が含まれます。
• エージェント境界のサーキット ブレーカーは、システム内の 1 つのエージェントが使用できなくなった場合のカスケード障害を防ぎます。
• ECOSIRE は、複雑なエンタープライズ自動化ワークフロー向けのマルチエージェント アーキテクチャを設計および実装します。

---

財団: OpenClaw のエージェント通信モデル

パターンを説明する前に、OpenClaw エージェントがどのように通信するかを理解することが重要です。 3 つのメカニズムがあり、それぞれに異なるトレードオフがあります。

メッセージ バスは、同じシステム内のエージェント間の主要な通信チャネルです。エージェントは、入力されたメッセージを名前付きチャネルにパブリッシュします。他のエージェントはそれらのチャネルを購読します。メッセージはバス ブローカー (Redis Streams または Kafka、構成可能) によって保持されるため、受信エージェントが一時的に利用できなくなってもメッセージは失われません。

直接呼び出し を使用すると、あるエージェントが別のエージェントの公開スキルを直接呼び出して、応答を待つことができます。これは呼び出し側の観点からは同期であり、結果が得られるまで呼び出し側エージェントが続行できない低遅延ワークフローに適しています。使用は慎重に行ってください。エージェント間に緊密な結合が形成されます。

共有メモリ名前空間 を使用すると、同じシステム内のエージェントがメモリ ストアの共有領域に対して読み書きできるようになります。これは、メッセージ ペイロードを通じてシリアル化せずに、大きなコンテキスト オブジェクト (処理中のドキュメント、複数の段階にわたって強化される顧客プロファイル) を渡すのに適しています。

// Publishing a message
await messageBus.publish("document.classified", {
  documentId: "DOC-4521",
  type: "vendor-invoice",
  confidence: 0.94,
  storageKey: "incoming/doc-4521.pdf",
});

// Subscribing to messages
messageBus.subscribe("document.classified", async (message) => {
  await extractionAgent.handle(message);
});

すべてのメッセージには、相関 ID、タイムスタンプ、ソース エージェント ID、およびスキーマ バージョンが含まれます。スキーマ バージョンにより、メッセージ バスは、宣言されたコントラクトに対してメッセージを検証し、不正な形式のメッセージを受信エージェントに到達する前に拒否できます。

---

パターン 1: 監督者兼作業者

スーパーバイザーとワーカーのパターンは、最も広く適用可能なマルチエージェント アーキテクチャです。スーパーバイザー エージェントはトップレベルの目標を受け取り、それをサブタスクに分解し、各サブタスクを専門のワーカー エージェントに割り当て、進捗状況を監視し、結果を統合します。

User/System Goal
      ↓
[ Supervisor Agent ]
  ├─ task 1 → [ Worker Agent A ]
  ├─ task 2 → [ Worker Agent B ]
  └─ task 3 → [ Worker Agent C ]
      ↓
[ Supervisor Agent ] ← results from all workers
      ↓
Synthesized Response

使用する場合: 複雑な目標を達成するために異種の専門知識が必要な場合。スーパーバイザは調整ロジックを処理します。ワーカーは、1 つのことをうまく実行するドメインのスペシャリストです。

OpenClaw の実装:

export const SupervisorAgent = defineAgent({
  name: "due-diligence-supervisor",
  skills: ["decompose-goal", "assign-workers", "synthesize-results"],
  async run({ goal, workerRegistry, messageBus }) {
    // Decompose goal into tasks
    const tasks = await decomposeGoal(goal);

    // Assign to appropriate workers
    const assignments = tasks.map((task) => ({
      task,
      worker: workerRegistry.findBestMatch(task.type),
    }));

    // Publish tasks and wait for results
    const results = await Promise.allSettled(
      assignments.map(({ task, worker }) =>
        messageBus.requestReply(`worker.${worker.id}.tasks`, task, { timeoutMs: 60_000 })
      )
    );

    // Synthesize
    const successfulResults = results
      .filter((r) => r.status === "fulfilled")
      .map((r) => r.value);

    return synthesize(goal, successfulResults);
  },
});

設計に関する重要な決定事項:

• スーパーバイザにはドメイン ロジックを含めるべきではありません。調整するだけでなければなりません。
• ワーカーはステートレスであり、独立してスケーラブルである必要があります。
• 失敗したワーカー タスクは、ワーカー内部ではなくスーパーバイザによって再試行されます。
• スーパーバイザ レベルでのタスク タイムアウトにより、遅いワーカーがワークフロー全体をブロックするのを防ぎます。

実際の例: デューデリジェンス自動化システムでは、監督者が会社のレビューを、財務分析担当者、法的文書レビュー担当者、市場調査担当者、および参照チェック担当者に割り当てられた並行タスクに分解します。監督者は、すべての調査結果を統合したデューデリジェンスレポートにまとめます。

---

パターン 2: パイプライン

パイプライン パターンは、各エージェントの出力が次のエージェントの入力になるようにエージェントを順序付けします。これは、ドキュメント処理、データ強化、および各ステップが定義された順序でペイロードを変換または強化するワークフローに最適です。

Input Document
    ↓
[ Stage 1: Ingestion Agent ]
    ↓
[ Stage 2: Classification Agent ]
    ↓
[ Stage 3: Extraction Agent ]
    ↓
[ Stage 4: Validation Agent ]
    ↓
[ Stage 5: Integration Agent ]
    ↓
Output: ERP Record

使用する場合: 明確なステージ境界と各ステップでの変換を伴う連続ワークフロー。高スループットのドキュメント処理に優れています。

OpenClaw の実装:

OpenClaw のパイプライン プリミティブは、ステージ チェーンを管理し、障害を処理し、ペイロードの内容に基づいて任意のステージでの分岐をサポートします。

import { definePipeline } from "@openclaw/orchestration";

export const InvoicePipeline = definePipeline({
  name: "invoice-processing",
  stages: [
    { agent: "document-ingester", timeout: 30_000 },
    {
      agent: "document-classifier",
      timeout: 15_000,
      branch: {
        "vendor-invoice": "invoice-extractor",
        "credit-memo": "credit-memo-extractor",
        "unknown": "human-review-queue", // Branch to exception handling
      },
    },
    { agent: "invoice-validator", timeout: 20_000 },
    { agent: "invoice-enricher", timeout: 10_000 },
    { agent: "erp-integrator", timeout: 30_000, retries: 3 },
  ],
  onFailure: {
    agent: "exception-handler",
    preservePartialState: true,
  },
});

設計に関する重要な決定事項:

• 各ステージは冪等である必要があります。同じ入力で 2 回実行すると、同じ出力が生成されます。
• onFailure ハンドラーは部分的なパイプライン状態を受け取るため、最初からやり直すのではなく、最後に成功したステージから再開できます。
• 分岐により、分類後にさまざまなドキュメント タイプがさまざまなサブパイプラインをたどることができます。
• 共有メモリ名前空間を使用して、大きなペイロード (ドキュメント バッファ) をメッセージ バス経由でシリアル化するのではなく、ステージ間で受け渡します。

障害処理: M 個のステージが成功した後にステージ N が失敗すると、パイプラインの状態はステージ M でチェックポイントされます。障害が解決された後 (手動修正、依存関係が回復した後に再試行)、パイプラインは同じペイロードでステージ M+1 から再開します。

---

パターン 3: 合意

コンセンサス パターンは、同じ入力に対して複数の独立したエージェントを実行し、システムが動作する前にそれらのエージェントが (しきい値内で) 同意することを要求します。これは複数のエージェントによるセカンドオピニオンに相当し、単一のエージェントのミスが多大な損害をもたらす一か八かの意思決定において最も価値があります。

Input
  ├─ → [ Evaluator Agent A ] → assessment A
  ├─ → [ Evaluator Agent B ] → assessment B
  └─ → [ Evaluator Agent C ] → assessment C
          ↓
  [ Consensus Resolver ]
    ├── unanimous or majority? → act
    └── no consensus? → escalate to human

使用する場合: 一か八かの意思決定 (融資の承認、不正行為の検出、医療記録の分析、契約条項のレビュー)、単一のエージェントが操作される可能性のある敵対的な入力、または異なるモデルが補完的な強みを持つ状況。

OpenClaw の実装:

export const FraudConsensusCheck = defineAgent({
  name: "fraud-consensus",
  async run({ transaction, evaluators }) {
    // Run all evaluators in parallel
    const assessments = await Promise.all(
      evaluators.map((evaluator) =>
        evaluator.assess(transaction)
      )
    );

    const fraudVotes = assessments.filter((a) => a.isFraud).length;
    const totalVotes = assessments.length;
    const agreementRatio = fraudVotes / totalVotes;

    if (agreementRatio >= 0.67) { // Supermajority fraud detection
      return { decision: "block", confidence: agreementRatio, assessments };
    } else if (agreementRatio === 0) { // Unanimous clear
      return { decision: "allow", confidence: 1 - agreementRatio, assessments };
    } else {
      // Disagreement — escalate with all assessments for human review
      return { decision: "escalate", confidence: null, assessments };
    }
  },
});

設計に関する重要な決定事項:

• 評価エージェントは、相関する失敗を最小限に抑えるために、異なるモデルまたは異なるプロンプト戦略を使用する必要があります。同じプロンプトで同じモデルを使用する 2 人のエージェントは通常、同意しますが、これでは目的が果たせません。
• コンセンサスしきい値は構成可能です。取り消し不能な行動には全会一致の合意が適切です。可逆的な決定には単純多数決で十分です。
• エスカレーション パスにはキャパシティ プランニングが必要です。エスカレーション レートが高い場合は、評価基準を調整する必要があります。

---

パターン 4: マーケットメーカー

Market-Maker パターンは、ワーカー エージェントのプールを維持し、タスクの到着時に最も適切な利用可能なワーカーにタスクを動的に割り当てます。ワーカーは自分の能力と現在の負荷を登録します。マーケットメーカーは各タスクを最適なマッチにルーティングします。

Task Queue
    ↓
[ Market-Maker Agent ]
    ├── Worker A: [language-translation] load: 30%
    ├── Worker B: [language-translation] load: 80%
    └── Worker C: [language-translation] load: 10%  ← assigned

使用する場合: タスク量が大幅に変化する高スループット システム。ルーティング ロジックを変更せずに、ワーカー エージェントの水平スケーリングを有効にします。また、グレースフル デグラデーションも可能になります。専門のワーカーが利用できない場合、マーケット メーカーはタスクを失敗させるのではなく、パフォーマンスの低い一般的なワーカーにルーティングできます。

export const TranslationMarketMaker = defineAgent({
  name: "translation-market-maker",
  tools: ["worker-registry", "task-queue"],
  async run({ tools }) {
    while (true) {
      const task = await tools.taskQueue.dequeue("translation.pending");
      if (!task) { await sleep(100); continue; }

      const workers = await tools.workerRegistry.getAvailable({
        capability: "language-translation",
        targetLanguage: task.targetLanguage,
      });

      if (workers.length === 0) {
        // No specialist available — try generalist
        const generalists = await tools.workerRegistry.getAvailable({ capability: "general-translation" });
        if (generalists.length === 0) {
          await tools.taskQueue.requeueWithDelay(task, { delayMs: 5000 });
          continue;
        }
        workers.push(...generalists);
      }

      // Select worker with lowest load
      const selected = workers.sort((a, b) => a.currentLoad - b.currentLoad)[0];
      await selected.dispatch(task);
    }
  },
});

設計に関する重要な決定事項:

• ワーカー負荷レポートは正確かつ低遅延である必要があります。負荷データが古いと、分散が不均一になります。
• フォールバック チェーン (スペシャリスト → ゼネラリスト → 遅延付きキュー) により、容量不足時のタスクの損失を防ぎます。
• ワーカーは起動時に自己登録し、正常なシャットダウン時に登録を解除します。ヘルスチェックポーリングにより、クラッシュしたワーカーが自動的に削除されます。

---

クロスパターン: 分散トレーシング

どのオーケストレーション パターンを使用するかに関係なく、実稼働マルチエージェント システムでは分散トレースを交渉することはできません。すべてのメッセージには correlationId と spanId が含まれます。エージェントが子タスクを作成するとき (スーパーバイザー パターンの場合)、または作業を次のステージに渡すとき (パイプライン パターンの場合)、現在のスパンの子として新しいスパンを作成します。

// Middleware that injects tracing into all agent message handlers
agent.useHook("preRun", (ctx) => {
  ctx.span = tracer.startSpan(ctx.skill, { childOf: ctx.message.parentSpan });
  ctx.span.setTag("agent.id", ctx.agentId);
  ctx.span.setTag("correlation.id", ctx.message.correlationId);
});

agent.useHook("postRun", (ctx) => {
  ctx.span.finish();
});

分散トレースを使用すると、エージェントの境界全体にわたるあらゆるタスクの完全な実行ツリーを視覚化できます。これは、遅延の問題や予期しない動作をデバッグするのに非常に役立ちます。

---

避けるべきアンチパターン

共有可変状態: 複数のエージェントが調整せずに同じデータ ストア レコードに書き込むと、更新が失われ、競合状態が発生します。調整にはメッセージ バスを使用します。エージェントは独自の状態を所有します。

3 つのエージェントよりも長い同期チェーン: エージェント A が B を呼び出し、B が C を呼び出し、さらに C が D を同期的に呼び出す場合、待ち時間が増大し、障害の爆発範囲が大きくなります。チェックポイント設定を使用して、長い同期チェーンを非同期パイプライン ステージに分割します。

ドメイン ロジックを備えたスーパーバイザー エージェント: スーパーバイザーはドメイン作業を実行するのではなく、調整する必要があります。スーパーバイザに抽出ロジックや検証ルールが含まれ始めると、それは姿を変えた一枚岩になります。

エージェント間の暗黙的なコントラクト: メッセージ スキーマはバス レベルでバージョン管理され、検証される必要があります。メッセージ構造を検証するのではなく想定するエージェントは、送信者が出力形式を変更すると通知なく失敗します。

---

よくある質問

一部のワーカーは成功し、一部は失敗するスーパーバイザーとワーカーのシステムで部分的な障害をどのように処理しますか?

スーパーバイザは、すべてのワーカー タスクの結果を成功と失敗の組み合わせとして受け取ります。合成スキルは、目標に基づいて部分的な結果を処理する方法を決定します。目標によっては、有用な出力を生成するには部分的な結果で十分です。その他の場合は、すべての結果が必要です。最小限の成功しきい値を使用してスーパーバイザーを構成します。成功したワーカーの割合がその割合よりも少ない場合は、誤解を招く可能性のある部分的な出力を生成するのではなく、エスカレーションします。

同じエージェントが複数のオーケストレーション パターンに同時に参加できますか?

はい。エージェントは単なるサービスです。エージェントは、1 つのスーパーバイザーとワーカーのシステムのワーカーであると同時に、パイプラインのステージとなり、コンセンサス チェックの評価者として参加することもできます。各呼び出しは独立しています。重要な要件は、エージェントが呼び出し間でステートレスであること (ステートフル データはエージェント インスタンス変数ではなくメモリ ストアに置かれる) であるため、複数の同時呼び出しが干渉しないことです。

高スループット システムのメッセージ バスのオーバーヘッドはどれくらいですか?

Redis Streams をメッセージ バス バックエンドとして使用すると、メッセージのパブリッシュ/サブスクライブのレイテンシーは、通常、64 KB 未満のメッセージで 2 ミリ秒未満になります。毎分数千のドキュメントを処理する高スループットのパイプラインの場合、これは各ステージの処理作業に比べれば無視できます。非常に高スループットのシステム (1 日あたり数百万のメッセージ) の場合、Kafka は運用の複雑性を犠牲にして、より高い持続スループットを提供します。

個々のエージェントが進化する場合、マルチエージェント システムのバージョンをどのように作成しますか?

マニフェストでセマンティック バージョニングを使用して、エージェントを個別にバージョン管理します。メッセージ バスは、宣言されたスキーマ バージョンに対してメッセージを検証します。エージェントが出力スキーマを変更すると (重大な変更)、メジャー バージョンが上がり、バスは古いスキーマのメッセージを前のバージョンにルーティングします。両方のバージョンは、移行期間中に同時に実行されます。スーパーバイザーまたはパイプライン構成では、必要な各ワーカーのバージョンを指定するため、ロールアウトのタイミングを完全に制御できます。

タスクに依存関係がある場合、Market Maker パターンはタスクの順序付けをどのように処理しますか?

マーケットメーカーは、独立したタスク、つまり任意の順序で実行できるタスクに適しています。依存関係のあるタスクの場合は、代わりにパイプライン パターンまたはスーパーバイザー パターンを使用して、明示的に順序付けを強制します。独立したタスクと依存したタスクが混在している場合は、スーパーバイザー パターンがうまく機能します。スーパーバイザーは独立したタスクを Market-Maker プールにディスパッチし、残りの依存関係の順序を管理します。

---

次のステップ

マルチエージェント オーケストレーションにより、単一エージェントでは処理できない自動化の複雑さが解放されます。このガイドのパターン (スーパーバイザー ワーカー、パイプライン、コンセンサス、マーケット メーカー) は、エンタープライズ自動化のユース ケースの大部分をカバーしています。重要なのは、すべての問題を単一のアーキテクチャに押し込むことではなく、問題のコミュニケーション構造に適切なパターンを選択することです。

ECOSIRE の OpenClaw マルチエージェント オーケストレーション サービス は、複雑なマルチエージェント システムのアーキテクチャ設計、実装、継続的な最適化を提供します。私たちのチームは、毎月数百万の文書を処理する文書処理システム、年中無休で稼働する財務分析パイプライン、および十数の専門エージェント間で調整する人事自動化システムのオーケストレーション アーキテクチャを設計してきました。

ECOSIRE に連絡 して、マルチエージェント アーキテクチャの要件について話し合ってください。