# イベント駆動エージェント設計：非同期ワークフローで大規模化する

> イベント駆動型エージェントはメッセージブローカーで疎結合化し大規模展開が可能になる。Kafka・EventBridgeの選定基準、Saga補償設計、分散トレーシングの要点をエンタープライズ向けに解説する。

- Canonical: https://kuucorp.com/blog/event-driven-agent-workflow-design/
- Date: 2026-06-02
- Last modified: 2026-06-02
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
エンタープライズ規模のAIエージェントは、同期RPC設計では早晩スケール限界に当たる。LLM呼び出しはレイテンシが不定で、連鎖呼び出しは1ステップの遅延が全体を止め、障害伝播を制御できない。解決策はイベント駆動アーキテクチャへの移行だ。エージェント間の依存をメッセージブローカーで間接化し非同期で疎結合化することで、大規模マルチエージェントシステムの設計が現実的になる。

## 同期RPC設計がエージェント大規模化の壁になる理由

> イベント駆動型エージェントは同期RPC依存を排除し非同期メッセージで疎結合化することで大規模展開が可能になる。

同期呼び出しチェーン（A→B→C）の問題は3点に集約される。

**レイテンシ合算**: 中間エージェントBの遅延がCへの応答まで積み上がる。LLM推論は数秒〜十数秒かかるため、5段階のオーケストレーションでは数十秒のブロッキングが常態化する。

**障害伝播**: Bがタイムアウトすると呼び出し元Aまでエラーが伝播し、部分障害が全体障害になる。バックプレッシャー対策なしでは連鎖的なサービスダウンを招く。

**スケーリング非対称**: 各エージェントの処理速度が異なる場合、遅いエージェントが上流の速いエージェントを窒息させる。同期モデルでは速度の異なるステップを独立スケールできない。

イベント駆動モデルでは、各エージェントはブローカー上のトピックをコンシュームし自分のペースで処理する。プロデューサーはコンシューマーを知らない。コンシューマーは並列化できる。この疎結合設計が、チーム間独立デプロイとエージェント水平スケーリングを同時に実現する基盤となる。

## 3つのコア設計パターン：ファンアウト・イベント連鎖・Saga

> ファンアウト・イベント連鎖・Sagaの3パターンでエンタープライズ向けエージェントワークフローを設計する。

### ファンアウト（並列分散）

オーケストレーターが1つのイベントを発行し、複数のワーカーエージェントが同一トピックをコンシュームして並列実行する。Anthropicが「Parallelization」として定義するパターンの非同期版だ。

典型例として書類審査ワークフローが挙げられる。`document-submitted` イベントを発行すると、法務チェックエージェント・与信評価エージェント・規制適合確認エージェントが同時に起動する。各ワーカーは完了時に `review-completed` トピックにイベントを発行し、集約エージェントがジョイン処理を行う。全体のスループットは最遅ワーカーで決まるため、ボトルネックステップのコンシューマー数を増やす設計が有効だ。

### イベント連鎖（パイプライン）

あるエージェントの出力イベントが次のエージェントのトリガーになる線形フローだ。`order-created` → `inventory-allocated` → `payment-processed` → `shipment-queued` のように、セマンティックなトピック名でフロー全体を読み取り可能にする。各ステップが独立してリトライ・スケーリング可能なため、ステップごとの処理負荷の違いを吸収できる。サブエージェントの委譲設計との組み合わせについては[サブエージェント・オーケストレーションの設計パターン](/blog/subagent-orchestration-design-patterns/)も参照してほしい。

### Saga（補償トランザクション）

分散環境でのロールバックが必要な長時間ワークフロー向けだ。データベースの2相コミットはLLMを含む非同期システムでは使えない。Sagaでは各ステップが「前進イベント」と「補償イベント（undo処理）」を対で定義する。例えば `shipping-reserved` が成功後に `payment-failed` が発生した場合、補償エージェントが `shipping-cancel-requested` を発行して予約を取り消す。ステートは外部ストア（Redis、DynamoDB等）に保持し、エージェント自体はステートレスに保つ設計が原則だ。

## メッセージブローカー選定：Kafka・EventBridge・Pulsar の使い分け

> ブローカー選定はスループット・運用コスト・テナント分離の3軸で決まり、高スループット要件にはKafkaが第一選択となる。

**Apache Kafka** は分散設計で水平スケールし、イベントを永続保存する。監査証跡が要件に入る金融・医療システムでの採用が多い。コンシューマーグループの並列度をパーティション数で制御でき、エージェントのスケールアウトをブローカー側で制約なく受け入れられる。KRaftクラスタの運用コストを許容できるチームに適する選択肢だ。

**AWS EventBridge** はサーバーレスでオペレーショナルオーバーヘッドをゼロに近づけたい場合の選択肢だ。イベントバスのルーティングルールで特定条件のイベントを特定ターゲット（Lambda、Step Functions、他のエージェントサービス）に転送できる。ただしKafkaのようなイベントリプレイ機能を持たないため、障害後の再処理設計を別途組む必要がある。

**Apache Pulsar** はマルチテナント・地理分散レプリケーションを組み込みで提供する。グローバル展開するエンタープライズや、チーム・テナントごとの厳密なトピック分離が要件になる場合に検討する。

選定の実務判断として、既存Kafkaインフラがある場合は流用が最も合理的だ。グリーンフィールドでAWSネイティブな構成なら EventBridge + SQS の組み合わせが最小運用コストで始められる。

## エンタープライズ実装の設計判断と運用要件

> エンタープライズ実装ではDead-letterキュー・スキーマレジストリ・分散トレーシングの3要素が運用品質を左右する。

**Dead-letterキュー（DLQ）** は必須だ。エージェントが毒消しメッセージ（処理不能なイベント）に当たるとコンシューマーがループし続ける。DLQへの自動退避と、退避されたメッセージのアラート・再投入フローを設計しないと、本番でサイレント障害が発生する。

**スキーマレジストリ** はイベントの契約管理に使う。プロデューサーとコンシューマーが異なるチームの場合、AvroやProtobufでスキーマの後方互換・前方互換を保証しないと、エージェント間で無言の互換性破壊が起きる。Confluent Schema Registry、AWS Glue Schema Registryが代表的な選択肢だ。

**分散トレーシング** はエージェントをまたぐ因果追跡に不可欠だ。イベント駆動では `traceparent` ヘッダをKafkaヘッダまたはEventBridgeのdetailフィールドに伝搬させる設計が必要だ。OpenTelemetryのコンテキスト伝播仕様を使い、トレースIDがエージェントをまたいで連続するようにする。これが欠けると本番トレースが途切れてデバッグ不能になる（詳細は[AIエージェントの可観測性](/blog/agent-observability-tracing-instrumentation/)を参照）。

**べき等性** の確保も実装レベルで必須だ。ネットワーク障害後のリトライでイベントが重複コンシュームされても副作用が1回で済むよう、エージェント処理に一意な `eventId` ベースのべき等キーを組み込む設計を標準化する。

エンタープライズのエージェント基盤設計・ブローカー選定・Saga設計レビューについては、[Kuu株式会社のRDEサービス](/services/rde/)で支援している。

## 参考

- [Building effective agents — Anthropic Engineering](https://www.anthropic.com/engineering/building-effective-agents)
- [The Future of AI Agents Is Event-Driven — Confluent](https://www.confluent.io/blog/the-future-of-ai-agents-is-event-driven/)

## まとめ

イベント駆動アーキテクチャはエンタープライズAIエージェントのスケール課題を根本から解決する設計戦略だ。同期RPCのレイテンシ合算・障害伝播・スケーリング非対称を、メッセージブローカーによる疎結合で解消し、ファンアウト・イベント連鎖・Sagaの3パターンで複雑なワークフローを組み立てる。ブローカー選定はKafka（高スループット・監査要件）、EventBridge（サーバーレス・低運用コスト）、Pulsar（マルチテナント・地理分散）で判断し、DLQ・スキーマレジストリ・分散トレーシングを運用基盤として整備することが本番品質の条件だ。

大規模エージェント基盤の設計・実装支援を検討している場合は、[Kuu株式会社のRDEサービス](/services/rde/)にご相談ください。