イベント駆動アーキテクチャとは｜同期APIとの違いと採用判断
最終更新日：2026/09/23
イベント駆動アーキテクチャ（EDA）とは、サービス同士が直接呼び合わず、「起きた事実」をイベントとして発行し、必要な側が購読して動く設計スタイルです。同期APIとどちらを選ぶかは、整合性の要件・応答時間・後続処理の増減・運用体制で決まります。採用判断の基準と、導入後に踏みやすい落とし穴を、設計に関わるエンジニア向けに整理します。
先に結論
EDAは「非同期にする技術」というより、イベントを介して疎結合に連携する設計スタイルです。結果として、呼び出し側が相手を知らなくていい状態を作れます
同期APIとの本質的な違いの一つは、失敗時の責任分担をどちらに置くかにあります
向くのは、1つの出来事に対して後続処理が3つ以上ぶら下がり、しかもそれが増減するシステムです
見送るべきなのは、即座に結果を返す必要がある処理と、分散システムの運用経験がチームにない場合です
採用の可否を分ける実務上の論点は、順序保証・冪等性・結果整合性・二重書き込みの4つに集約されます
この記事でわかること
EDAの基本構造と、イベント・コマンドという2つの概念の使い分け
同期APIとEDAを5つの軸で比較した、採用判断のための早見表
Martin Fowlerが整理した4つの型（イベント通知／状態転送／イベントソーシング／CQRS）の違い
導入時に必ず詰まる6つの設計論点と、それぞれの定番の解き方
フリーランス案件でEDAの知識がどう問われるか
対象は、実務経験3年以上のバックエンド・インフラ寄りのエンジニアで、既存システムに非同期処理を入れるか判断する立場にある方を想定しています。メッセージング製品そのものの使い方ではなく、設計スタイルを選ぶ側の話が中心です。
目次
イベント駆動アーキテクチャ（EDA）とは
同期APIとの違いを5つの軸で比較
EDAの代表的な4つの型
採用判断：向く条件と見送るべき条件
実装・運用で詰まりやすい6つの論点
段階的に入れる導入ステップと実践チェックリスト
フリーランス案件でEDAはどう問われるか
よくある失敗と対策
まとめ
よくある質問
イベント駆動アーキテクチャ（EDA）とは
EDAは、システムの構成要素が「イベント」を介して間接的に連携する設計スタイルです。注文が確定した、ユーザーが退会した、決済が失敗した。こうした過去形で言い切れる事実をメッセージとして流し、関心のあるサービスが自分の判断で拾います。
発行する側は、誰が受け取るかを知りません。ここが要点です。
イベントとコマンドは別物
混同されやすいのですが、この2つは設計上の意味がまったく違います。
種別 | 意味 | 受け手 | 例 |
|---|---|---|---|
イベント | すでに起きた事実の通知 | 誰が受けてもよい（0人でも成立） | 注文が確定した |
コマンド | 特定の相手への処理依頼 | 1つに決まっている | 在庫を引き当てろ |
コマンドをイベントの形で流すと、送り手は「誰かがやってくれるはず」という前提で投げっぱなしになります。実行されたかどうかの責任が宙に浮くわけです。イベント名を動詞の命令形で付けたくなったら、それはたいていコマンドです。
登場するのは3者だけ
構造自体は単純です。イベントを発行するプロデューサー、受け渡しを担うブローカー、受け取って処理するコンシューマー。この3者で成り立ちます。
ブローカーにあたるのがApache KafkaやAmazon SQS、Google Cloud Pub/Subといったミドルウェアです。製品ごとの特性の違いはApache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説で詳しく扱っているため、本記事では設計スタイルの選択に絞ります。
「疎結合」が実際に何を指すか
疎結合という言葉は曖昧に使われがちです。EDAの文脈では、次の3つが同時に外れている状態を指します。
時間的結合：相手が起動していなくても発行できる
空間的結合：相手のエンドポイントを知らなくていい
同期的結合：相手の処理完了を待たなくていい
同期APIはこの3つがすべて結合しています。だからこそ呼び出し元は結果を確実に受け取れるわけで、疎結合が常に優れているという話ではありません。
同期APIとの違いを5つの軸で比較
結論から言えば、違いは単に「非同期かどうか」ではなく、失敗の扱い方・責任分担・整合性の前提にあります。同期APIは失敗を呼び出し元に返します。EDAは失敗をコンシューマー側に閉じ込めます。
比較軸 | 同期API（REST／gRPC） | イベント駆動（EDA） |
|---|---|---|
呼び出しの向き | 呼ぶ側が相手を指定 | 発行側は受け手を知らない |
処理結果 | その場で受け取れる | その場では受け取りにくい（必要なら別経路で確認） |
失敗時の責任 | 呼び出し元が検知・再試行 | コンシューマーが再試行、最終的にDLQ |
データ整合性 | 強整合を取りやすい | 結果整合が前提 |
障害調査 | リクエスト単位で追える | トレースIDの伝播設計が必須 |
後続処理の追加 | 呼び出し元の改修が必要 | 購読を増やすだけ |
一番下の行が、EDAを選ぶ最大の動機です。「注文確定後にポイント付与も追加したい」という要求が来たとき、同期APIだと注文サービスに手を入れます。EDAなら注文サービスは無改修で、新しいコンシューマーを足すだけで済みます。
同期APIのままで十分なケース
次に当てはまるなら、無理にイベント化しない判断が妥当です。
呼び出し元が結果を画面に表示する必要がある（ログイン、残高照会、検索）
後続処理が1つしかなく、今後増える見込みも薄い
処理全体が同期APIのタイムアウト（多くの構成で30秒前後）に十分収まる
決済と在庫引当のように、部分的な成功を許容できない一連の処理
REST APIの設計そのものについてはREST APIとは｜設計原則・HTTPメソッド・GraphQL/gRPCとの違い、型付きの内部通信を選ぶ場合はgRPCとは｜RESTとの違い・Protocol Buffersと使いどころを参照してください。
ミニFAQ：非同期処理を入れたらEDAと呼べますか？
呼べません。バッチやジョブキューで非同期化しても、呼び出し元が処理内容を指定しているならコマンド送信です。EDAかどうかの分かれ目は「発行側が受け手を知らずに済んでいるか」です。
EDAの代表的な4つの型
EDAはひとつの手法ではありません。Martin FowlerがWhat do you mean by "Event-Driven"?で整理した4分類が、実務でも判断の軸として使いやすいです。
イベント通知（Event Notification）
「何かが起きた」という最小限の情報だけを流す型です。イベントには識別子と種別しか入れません。受け取った側が必要に応じてAPIを叩いてデータを取りに行きます。
ペイロードが小さく、導入コストを抑えやすいため、導入初期の選択肢になりやすい型です。ただし受け手が毎回問い合わせるため、結局は同期依存が残ります。
イベント伝達型（Event-Carried State Transfer）
英語の Event-Carried State Transfer をそのまま訳した呼び方で、イベントに状態を載せて渡す型を指します。イベントに必要なデータを丸ごと載せて流す形です。受け手は問い合わせ不要になり、発行元が落ちていても処理を続けられます。
代償はデータの重複です。各コンシューマーが自分用のコピーを持つため、鮮度のズレをどこまで許すかを先に決めておかないと、後から辻褄合わせに追われます。
イベントソーシング
状態そのものではなく、状態変化の履歴をすべて保存する型です。現在の残高ではなく、入出金の全記録を正とする発想と言えばイメージしやすいと思います。
監査要件が厳しい金融系や、過去の任意時点の状態を再現したい場面で効きます。一方で、実装難度は4つの中で抜けて高い。イベントの定義を後から変えるのが困難なため、ドメイン理解が固まる前に選ぶと苦しくなります。ドメインモデルの設計はドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころが参考になります。
CQRS（コマンドクエリ責務分離）
更新系と参照系でモデルを分ける型です。イベントソーシングと組み合わせて語られることが多いものの、別個に採用できます。
参照側を非正規化しておけるため、読み取りの負荷が書き込みの10倍を超えるようなサービスで効果が出やすい構成です。
ブローカー型とメディエーター型
上の4分類とは別に、イベントの流し方でも2系統に分かれます。ブローカー型は中央の調整役を置かず、各サービスが購読して自律的に動きます。メディエーター型はワークフローエンジンのような調整役が処理順を制御します。
前者は疎結合を最大化できますが、全体の処理フローがコードのどこにも書かれていない状態になります。後者は見通しが良い代わりに、調整役が単一障害点になりやすい。どちらが正解ということはなく、フローの複雑さと追跡のしやすさのどちらを優先するかで選びます。
採用判断：向く条件と見送るべき条件
判断の前に一つ。EDAは同期APIの上位互換ではありません。運用の複雑さを引き受ける代わりに、拡張のしやすさを買う取引です。
向く条件
1つの出来事に対して後続処理が3つ以上あり、今後も増減する見込みがある
ピーク時と平常時のトラフィック差が大きく、処理を平準化したい
後続処理が失敗しても、主処理は成立させたい（通知メールの失敗で注文を止めたくない等）
サービス間の依存が増え、1つの変更が連鎖的に他サービスの改修を呼んでいる
外部システム連携があり、相手先の応答時間を自分たちで制御できない
見送るべき条件
主処理の大半が即時応答を求められ、後続処理にも同期完了が要求される
チームに分散システムの運用経験者がおらず、学習の時間も確保できない
分散トレーシングやログ集約の基盤が未整備
サービスが2〜3個程度で、当面増える計画もない
結果整合性をビジネス側に説明して合意を取れる見込みがない
最後の項目は技術判断ではないため見落とされがちです。「登録したのに一覧にすぐ出ない」を仕様として受け入れてもらえるかは、着手前に確認しておくべき論点になります。
判断フロー
迷ったときは上から順に見ていくと整理できます。
順 | 問い | Yesの場合 | Noの場合 |
|---|---|---|---|
1 | 呼び出し元は結果を即座に必要とするか | 同期APIを維持 | 次へ |
2 | 後続処理は1つだけで固定か | 同期API、またはジョブキュー | 次へ |
3 | 結果整合をビジネス側が許容できるか | 次へ | 同期API中心で設計し、必要なら処理境界を見直す |
4 | 可観測性の基盤と運用体制があるか | EDAを検討してよい | 先に基盤を整備 |
5 | イベントの粒度をドメインで説明できるか | イベント通知型から着手 | まずドメイン整理 |
4番目で止まる現場が実際には多い印象です。EDAの導入失敗は、設計よりも運用基盤の不足から起きるケースが目立ちます。
ミニFAQ：マイクロサービス化とEDAはセットで進めるべきですか？
分けたほうが安全です。サービス分割と通信方式の変更を同時にやると、問題が起きたときに原因の切り分けができません。モノリスのまま内部イベントを導入し、運用に慣れてから分割に進む順序も現実的です。分割の判断そのものはマイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説で扱っています。
実装・運用で詰まりやすい6つの論点
ここからが本題です。EDAの難しさは設計図ではなく、この6つに現れます。規模や採用した型によって顕在化の度合いは変わりますが、いずれも着手前に方針を決めておく価値があります。
1. 順序保証
イベントは発行順に届くとは限りません。「商品を追加」と「商品を削除」が逆順で届けば、削除済みの商品が復活します。
対策は2つ。順序が必要な範囲を絞り、同じキー（ユーザーID、注文ID等）のイベントを同一パーティションに寄せる方法が一つ。もう一つは、イベントにバージョン番号を持たせ、古いものを受信側で捨てる方法です。全体順序を厳密に保証すると並列性が大きく落ちるため、キー単位に限定するのが定石になります。
2. 冪等性
多くの構成では at-least-once（最低1回は届く）を前提に設計します。基盤や設定によっては重複排除の機能もありますが、同じイベントが2回届く前提で作っておくほうが安全です。
受信側でイベントIDを記録し、処理済みなら黙って捨てる。この仕組みを最初から全コンシューマーに入れておくのが安全です。後付けは対象箇所の洗い出しから始まるため、コストが跳ね上がります。
3. 結果整合性とSaga
複数サービスにまたがる処理では、分散トランザクションの代わりにSagaパターンを使います。各サービスがローカルトランザクションを実行し、失敗したら補償処理（打ち消し処理）を流す方式です。
注意点は、補償処理は「元に戻す」わけではないことです。発送済みの商品は未発送に戻せません。返品という別の業務プロセスとして設計する必要があります。詳細はSagaパターン（Microsoft Learn）が整理されています。
4. 二重書き込み問題
見落とされやすい割に、本番で効いてくる論点です。DBを更新してからイベントを発行する処理で、DB更新後・イベント発行前にプロセスが落ちるとどうなるか。データは変わったのに、誰もそれを知らない状態が残ります。
定番の解法がTransactional Outboxパターンです。イベントを業務データと同じトランザクションで専用テーブルに書き、別プロセスがそれを読んでブローカーへ送ります。実装の詳細はTransactional Outbox（microservices.io）にまとまっています。
5. スキーマ進化
イベントの形式は必ず変わります。そして発行側と受信側は別々のタイミングでデプロイされます。
フィールドの追加は後方互換を保てますが、削除と型変更は壊れます。最低2世代は旧形式を受け付けられる状態を維持する運用にしておくと事故が減ります。イベント形式の標準化にはCloudEvents、非同期APIの仕様記述にはAsyncAPIといった仕様があり、同期API側のOpenAPIとは｜Swaggerとの違い・仕様書の書き方と運用と同じ役割を果たします。
6. 可観測性とリトライ設計
同期APIならスタックトレースで追えた障害が、EDAでは追えなくなります。イベントにトレースIDを載せ、発行から最終処理まで貫通させる設計が前提条件です。分散トレーシングの標準化についてはOpenTelemetryとは｜可観測性標準の仕組み・導入の流れ・案件動向で解説しています。
リトライは指数バックオフで3〜5回程度を上限とし、超えたらDLQ（デッドレターキュー）へ退避させる構成が一般的です。そして少なくとも重要イベントについては、DLQの滞留を即時検知できるようにしておきます。件数や継続時間で閾値を分ける運用もあるため、イベントの重要度に応じて設計してください。放置されたDLQは、気づいたときには数万件たまっている、というのがありがちな展開です。障害時の動き方は障害対応の手順とポストモーテムの書き方｜一次対応から再発防止までが参考になります。
段階的に入れる導入ステップと実践チェックリスト
全面刷新は推奨しません。既存の同期APIを残したまま、影響の小さい経路から1つずつイベント化する進め方が現実的です。
対象を1系統だけ選ぶ（通知メール、集計、監査ログなど失敗しても主処理が止まらないもの）
可観測性を先に整える（トレースID伝播、コンシューマーのラグ監視、DLQのアラート）
イベント通知型で最小構成を作る（ペイロードは識別子と種別のみ）
冪等性とDLQを最初から組み込む（後付けしない）
数週間から数か月運用して問題を洗い出す（本番での失敗パターンは机上では出てこない）
2系統目以降を広げる
1系統目が落ち着くまでの期間はチーム規模やトラフィック量で変わりますが、2〜3か月を一つの目安に置くと、想定外の運用課題を拾う余裕ができます。
着手前の確認用チェックリストです。
項目 | 確認内容 |
|---|---|
イベント定義 | 過去形で言い切れる事実になっているか（命令形ならコマンド） |
粒度 | ビジネス上意味のある単位か。DBの更新単位になっていないか |
ペイロード | 個人情報・機微情報を不用意に載せていないか |
冪等性 | 全コンシューマーで重複受信を処理できるか |
順序 | 順序が必要な範囲を特定し、キー設計に反映したか |
スキーマ | バージョン管理の方針と、互換性の維持期間を決めたか |
監視 | コンシューマーラグ・DLQ滞留のアラートを設定したか |
合意 | 結果整合の挙動をビジネス側に説明し、合意を得たか |
このうち「合意」の欄は技術チェックではありませんが、ここが抜けたまま進むと、リリース後に仕様不備として差し戻される場面につながります。
フリーランス案件でEDAはどう問われるか
ここからはキャリア観点の補足です。EDA単体を指定した募集は多くありません。実際には、Kafkaなどのメッセージング基盤やマイクロサービス基盤の案件で、設計判断ができる人として求められる形が中心です。
求められるスキル像
募集要項でよく組み合わせて挙がるのは次の要素です。
メッセージング基盤（Kafka、SQS、Pub/Sub等）の運用経験
クラウドのマネージドサービスを使った非同期処理の構築経験。AWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説で扱うようなサーバーレス構成との組み合わせも頻出です
分散システムの障害対応経験（再送、順序ずれ、データ不整合の調査）
既存の同期処理を段階的に移行した経験
面談で踏み込まれやすいのは、製品の知識よりも「なぜEDAを選んだか」「選ばなかったケースはあるか」という判断の部分です。導入した結果どんな運用負荷が増え、どう対処したかまで語れると、設計レイヤーの評価につながります。設計力そのものの伸ばし方はエンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップで整理しています。
単価の目安
以下は、2026年9月時点で、首都圏を中心とする主要フリーランスエージェント数社の公開案件ページを確認し、募集要項にメッセージング基盤やイベント設計への言及があった案件を20件程度ピックアップして整理した観測ベースの目安です。公開案件数がそれほど多い領域ではないため、レンジの幅は広めに見てください。
役割 | 月額の目安 | 想定する人物像 |
|---|---|---|
バックエンド開発（イベント処理の実装） | 70〜100万円 | Web系バックエンド実務3年以上、非同期処理の実装経験あり |
基盤・SRE寄り（ブローカー運用込み） | 80〜110万円 | Kafka等の運用経験、監視基盤の構築経験あり |
アーキテクト・設計リード | 100〜130万円 | 分散システムの設計経験5年以上、移行の旗振り経験あり |
同じ役割でも、商流（元請けに近いか）、週5稼働が前提か、出社比率、担当する業務範囲によってレンジは上下します。また上記は公開案件ベースの数字です。非公開案件は個別条件で動くため、別の話として切り分けて考えてください。
自分がどのレンジを狙えるか把握しておきたい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？にまとめています。
よくある失敗と対策
イベントの粒度がDBの更新単位になっている
「usersテーブルが更新された」というイベントは、業務上の意味を持ちません。受信側は何が起きたのか判断できず、結局全フィールドを比較する羽目になります。ビジネス上の出来事（ユーザーがプランを変更した、等）を単位にします。
全部を非同期にしてしまう
ログイン処理までイベント化して、応答が返らない設計になっている例があります。ユーザーが結果を待っている処理は同期のままでよく、EDAは待たなくていい処理に適用するものです。
イベントを使って同期的な往復をする
イベントを投げて、返信イベントを待つ。これは実質的に同期呼び出しで、しかもデバッグが困難な形になっています。リクエスト・レスポンス型が必要なら素直にAPIを使う判断が妥当です。
DLQを作ったが誰も見ていない
設定だけして監視対象から外れているパターンです。DLQは滞留件数にアラートを設定し、気づける状態にして初めて機能します。
全サービスを一斉に移行する
段階移行ではなくビッグバン移行を選ぶと、問題が起きたときの切り分けができません。1系統ずつ、戻せる形で進めます。
まとめ
イベント駆動アーキテクチャ（EDA）とは、イベントを介してサービスを疎結合に連携させる設計スタイルです。後続処理が増減する場面で拡張コストを下げられる一方、順序保証・冪等性・結果整合性・二重書き込みの設計が前提になります。
イベントとコマンドを区別する。過去形で言えない名前はコマンドの疑いがある
同期APIとの本質的な違いは通信方式ではなく、失敗の責任の所在にある
4つの型のうち、まずはイベント通知型から始めるのが導入コストの面で無理がない
判断フローの4番目「可観測性の基盤と運用体制があるか」で止まるなら、先に基盤を整える
冪等性とDLQアラートは後付けせず、1系統目から組み込む
1系統ずつ、2〜3か月かけて運用しながら広げる
案件では製品知識より「なぜ選んだか／選ばなかったか」の判断が問われる
次の一歩としては、いま抱えている同期APIの中で「結果を待つ必要がない後続処理」を洗い出してみてください。そこが1系統目の候補になります。
参照した一次情報
よくある質問
EDAとマイクロサービスは同じものですか
違います。マイクロサービスは「どう分割するか」、EDAは「どう通信するか」の話です。マイクロサービスを同期APIだけで組むことも、モノリス内部でイベント駆動にすることも可能です。
Kafkaを使えばEDAになりますか
なりません。Kafkaは選択肢の一つで、設計スタイルとは別の層の話です。Kafkaを使いながら実質的にコマンド送信をしているケースもあります。判断軸は「発行側が受け手を知らずに済んでいるか」です。
ジョブキュー（Sidekiq、Celery等）との違いは何ですか
ジョブキューは「この処理をやってくれ」という依頼を投げる仕組みで、送り手が処理内容を指定します。EDAは「これが起きた」という事実を流すだけで、何をするかは受け手が決めます。実装は似ていても、依存関係の向きが逆です。
小規模なサービスでもEDAを使う意味はありますか
小規模でも、監査ログ・通知・集計のように主処理から切り離せる後続処理だけをイベント化するなら有効です。全面適用ではなく部分導入という選択肢があります。ただしサービスが2〜3個で追加予定もない段階で全体を組み替えると、運用コストのほうが上回るケースが多いです。
イベントの重複はどの程度の頻度で起きますか
頻度は構成によりますが、「まれに起きる」ではなく「必ず起きる前提」で設計します。ネットワークの一時断、コンシューマーの再起動、リバランスなど、重複を生む要因は日常的な運用の中にあります。冪等性は例外処理ではなく標準実装として入れてください。
結果整合性をビジネス側にどう説明すればよいですか
「反映まで数秒から数十秒かかる場合がある」という体感レベルの説明が通りやすいです。技術用語を使うより、具体的な画面の挙動（登録直後は一覧に出ないことがある）で示し、許容できるかを確認します。許容できない画面があれば、その部分だけ同期で取りに行く設計にします。
イベントスキーマの管理にはどんな方法がありますか
スキーマレジストリでバージョンと互換性ルールを一元管理する方法が一般的です。仕様の記述にはAsyncAPIのような標準を使い、同期APIにおけるOpenAPIと同じ位置づけで運用します。少なくとも、イベント定義がコード内に散在している状態は避けてください。
既存のモノリスにEDAを部分導入できますか
できます。むしろ推奨される進め方です。モノリス内部でイベントを発行し、同一プロセス内で購読する構成から始めれば、ブローカーの運用負荷なしにイベント設計の練習ができます。境界が見えてきた段階で外部ブローカーへ移します。
EDAの経験は職務経歴書にどう書くと伝わりますか
製品名の羅列より、判断と結果を書くほうが伝わります。「注文処理の後続3系統をイベント化し、機能追加時の注文サービス改修を不要にした」「DLQ滞留のアラート設計により、データ不整合の検知を運用フローに組み込んだ」といった形です。移行の規模と、扱ったイベントの種類数も添えると具体性が出ます。
学習を始めるなら何から手をつけるべきですか
まず同期APIの設計を固めるのが先です。その上で、手元のクラウドアカウントでキューを1つ作り、重複受信と順序ずれを意図的に発生させてみる。この2つを自分の手で再現すると、記事を読むだけでは掴みにくい部分が具体的に理解できます。
