イベントソーシングとCQRSとは｜違い・仕組みと導入判断の基準

イベントソーシングとCQRSとは｜関係とCRUDとの違い

結論から言えば、この2つは「よく一緒に語られるが、解いている問題が違う」パターンです。イベントソーシングはデータの保存の仕方、CQRSはモデルの分け方の話をしています。

イベントソーシング｜状態ではなく「起きたこと」を保存する

イベントソーシングは、エンティティに起きた変更を不変のイベントとして追加専用ストアに積み、現在の状態はそれを再生して求める方式です。マイクロソフトのイベント ソーシング パターンでは、この再生処理をリハイドレートと呼んでいます。

カートを例にすると、保存されるのは「カート作成」「商品1を追加」「商品2を追加」「商品1を削除」「配送情報を追加」という出来事の列です。最終的なカートの中身は、この列を頭から適用した結果として得られます。

ここがCRUDとの決定的な違いです。CRUDでは更新のたびに過去が上書きされて消えます。イベントソーシングでは過去が消えません。

CQRS｜書き込みと読み取りでモデルを分ける

CQRSはCommand Query Responsibility Segregationの略で、データを変更するコマンドと、データを返すクエリを別のモデルとして扱う設計です。CQRS パターンでも、書き込みモデルは検証とドメインロジックを持ち、読み取りモデルはドメインロジックを持たずDTOを返す、という役割分担が示されています。

コマンドは「予約ステータスを予約済みに設定する」ではなく「ホテルの部屋を予約する」という粒度で書きます。業務上の意図をそのまま表現するわけです。

2つは必ずセットではない

ここを混同すると導入判断を誤ります。

• CQRSのみ：同じデータベースのまま、読み書きのモデルだけ分ける。もっとも導入コストが低く、適用範囲も広い

• イベントソーシングのみ：履歴を正として保存するが、読み取りは同じストアから再生する。ストリームが短い領域なら成立する

• 両方：イベントストアを書き込みモデル、マテリアライズドビューを読み取りモデルとする。性能と柔軟性は最大だが、複雑さも最大

マイクロソフトの解説でも、CQRSは「特にイベントソーシングと組み合わせると、アプリケーション設計に大きな複雑さが生じる」と明記されています。セットで入れるのが標準ではありません。

CRUDとの違いを5つの軸で比較

この表は、イベントソーシングとCQRSを併用した典型構成とCRUDを比べたものです。CQRS単独の場合、読み取りが結果整合性になるとは限りません（詳細は後述の3段階で整理します）。

表の最後の行が、導入可否を分ける最大の論点です。「更新した直後に、その結果が一覧画面に出ていないことがある」という挙動を業務側が受け入れられるか。ここで止まる案件は少なくありません。

イベントソーシングの仕組み｜4つの基本部品

実装を具体的に考えるときは、イベントストア・リハイドレート・スナップショット・補正イベントの4点を押さえれば全体像がつながります。

イベントストアとイベントストリーム

イベントストアは、エンティティごとに独立したイベントストリームを保持します。注文Aのストリーム、注文Bのストリーム、というようにエンティティIDで自然に分割されるため、水平スケールやシャーディングと相性が良い構造です。ただし分割できることと負荷が均等になることは別で、特定のIDに更新が集中する場合はホットスポット対策が必要になります。

実装の選択肢は大きく2つあります。専用のイベントストア製品を使うか、リレーショナルDBやドキュメントDBに追加専用テーブルを作るか。専用品はストリーム単位の読み取り・楽観的並行性制御・スナップショットを組み込みで持ちますが、汎用DBを使う場合はそれらを自前で作る必要があります。

ここで最も多い誤解を先に潰しておきます。イベントストアとメッセージブローカーは別物です。 Microsoft Learnも両者を混同しないよう明記しており、Apache Kafkaのようなブローカー単体では、イベントストアで重視されるエンティティ単位の再構成や楽観的並行性制御がそのままは提供されません。周辺のエコシステムや追加実装で補える部分はありますが、プロジェクションへイベントを配る配信層と、記録のシステムとしてのイベントストアは役割が違う、という整理です。Kafka自体の役割については「Apache Kafkaとは｜分散イベントストリーミング基盤の仕組み・用途・案件単価を解説」で詳しく触れています。

リハイドレートとスナップショット

コマンドを処理するとき、ハンドラーはまずそのエンティティのイベントを全部読んで再生し、現在の状態を組み立てます。これがリハイドレートです。

問題は、ストリームが伸びるほどこの処理が重くなること。そこで一定間隔でスナップショット（ある時点の状態をシリアライズしたもの）を保存し、再生時は「最新のスナップショット＋それ以降のイベントだけ」で済ませます。

間隔の決め方に公式な正解はありません。イベント件数ベースで区切ることが多く、閾値はリハイドレートの実測時間が許容値を超える手前に置きます。数百件前後から検討されることもありますが、これは一般的な相場ではなく、イベントの大きさと再生処理の重さで変わる値です。本番相当のデータ量で測ってから決めてください。

ひとつ注意点を。スナップショットはあくまで最適化です。信頼できるソースはイベントストリームのほうであり、スナップショットはいつでも再生成できる前提で設計します。

補正イベント｜過去は書き換えない

イベントストアは永続的な情報源なので、保存済みのイベントは更新しません。取り消したいときは、打ち消す新しいイベントを追記します。予約キャンセルなら、座席予約イベントを消すのではなく、予約キャンセルイベントを足す。元のイベントはストリームに残り続けます。

この不変性には副作用があります。バグによって間違ったイベントが生成された場合、そのイベントもストアに残るということです。コードを直しても過去のイベントは直りません。リプレイ時に不正なデータを処理するための補正イベントや変換処理が別途必要になるケースがあります。

イベント設計の良し悪しが後から効く

結論として、イベントは「結果の状態」ではなく「ビジネス上の意図」を記録すべきです。ここを外すと、監査証跡としても読み取りモデルの材料としても使いものになりません。

後者はイベントストアを、業務的な意味を持たない変更ログに縮めてしまいます。設計時点では差が小さく見えるので、見落としやすい論点です。

この章の補足Q&A

Q. イベントは削除できないと、ストレージは増え続けるのでは？

増え続けます。ただし1イベントのサイズは小さく、エンティティIDでパーティション分割できるため、古いストリームのアーカイブで対処するのが一般的です。問題になるのは容量より、むしろ後述する個人データの削除要求のほうです。

Q. 既存のCRUDシステムを後からイベントソーシングに移行できますか？

技術的には可能ですが、移行コストは高めに見積もってください。過去データには「何が起きたか」の情報が残っていないため、移行時点のスナップショットを初期イベントとして、そこから先だけイベント化する割り切りが現実的です。

CQRSの3段階｜どこまで分離するかを選ぶ

CQRSは0か1かではありません。分離の深さを3段階で捉えると、自分の案件がどこまで必要かを判断しやすくなります。

レベル1：同じDBでモデルだけ分ける

読み書きが同じデータベースを共有しつつ、コードの上で書き込みモデルと読み取りモデルを分けます。書き込み側にはバリデーションとドメインロジックを置き、読み取り側はDTOを返すだけにする。

結果整合性の問題が発生しないのが最大の利点です。CQRSの効果のうち「関心の分離」「クエリの単純化」はこの段階で取れます。迷ったらまずここから始めるのが無難でしょう。

レベル2：読み取り専用ストアを分ける

読み取り用に別のストアを用意し、クエリ向けに最適化したスキーマやマテリアライズドビューを持ちます。書き込みストアのリードレプリカを使う構成もここに含まれます。

読み取りのスケールと応答性が改善する一方、2つのストアの同期が課題になります。ここから結果整合性が顔を出します。データベースの更新とイベント発行を1つの分散トランザクションにまとめるのは通常できないため、トランザクショナルアウトボックスのような仕組みで状態変更とイベントを原子的に永続化する必要があります。

レベル3：イベントソーシングを書き込みモデルにする

書き込みストア自体をイベントストアに置き換え、読み取りモデルはイベントから生成するマテリアライズドビューにします。

この段階まで来ると、読み取りモデルはイベントから何度でも作り直せる、使い捨ての存在になります。要件変更で画面が変わっても、過去のイベントを再生して新しいビューを作ればよい。柔軟性は最大です。

ドメインモデルの組み立て方そのものに自信がない段階でレベル3に進むと、たいてい破綻します。集約の切り方は「ドメイン駆動設計（DDD）とは｜戦略設計と戦術設計の使いどころ」、層の分け方は「クリーンアーキテクチャとは｜4層構造とDDDの関係を実務目線で解説」が前提知識になります。

導入前に潰しておく5つの落とし穴

結果整合性｜「まだ反映されていない」をどう見せるか

読み取りモデルの更新は、イベント発生から遅れて届きます。遅延の幅は構成次第で、同一リージョンの単純な構成なら体感されない程度に収まることもあれば、処理が詰まれば数秒単位まで伸びることもあります。数値は環境で大きく変わるため、必ず自分たちの構成で実測してください。

重要なのは、この遅延を技術側だけで吸収しようとしないことです。「登録しました。一覧への反映まで少し時間がかかります」と画面で伝える、登録直後だけ書き込み側の結果を返す、といったUI設計の合意を業務側と取っておきます。ここを曖昧にしたまま進むと、リリース後に「バグだ」と言われます。

イベントのスキーマ進化

イベントは長期に残るので、数年前のイベントを今のコードで読めなければなりません。マイクロソフトのドキュメントでは、対処方針として次の選択肢が挙げられています。

• 寛容な逆シリアル化：未知のフィールドを無視し、欠けたフィールドは既定値を使う。追加だけの変更に有効

• イベントのバージョン管理：イベントにバージョン識別子を持たせ、コンシューマーが処理を切り替える

• アップキャスト：逆シリアル化時に古いスキーマを現行スキーマへ変換する。保存済みイベントは変更しない

• インプレース移行：ストア内の履歴イベントを直接書き換える。不変性と監査証跡を損なうため最後の手段

実務では、寛容な逆シリアル化とアップキャストの組み合わせが扱いやすい構成です。

べき等性｜「少なくとも1回」配信が前提

コンシューマーへのイベント配信は、通常は少なくとも1回の保証です。つまり同じイベントを複数回受け取ります。

イベントハンドラーがべき等でないと、プロジェクションがイベントストリームからずれ、支払いや通知のような副作用が二重に起きます。コンシューマーごとに最後に処理したイベントのシーケンス番号を持って重複をスキップするか、繰り返しても結果が変わらない状態変更として設計するか。どちらかの手当ては必須です。

個人データの削除要求

追加専用で不変というイベントストアの性質は、個人データの削除を求める規制と正面からぶつかります。イベントを物理削除するとストリームの整合性が壊れるため、設計の最初から織り込んでおく必要があります。

よく採られるのは、個人データをイベントストアの外に置き、イベントからは識別子だけ参照する構成です。分離できない場合は、対象者ごとの鍵で暗号化しておき、鍵を破棄することでデータを復元不能にする方法（暗号化シュレッディング）があります。後者は読み書きごとに暗号化のオーバーヘッドが乗り、堅牢な鍵管理も必要になります。

テストと運用の増分

イベントソーシングのテストは、過去のイベントを与え、コマンドを発行し、生成されたイベントを検証するスタイルが向いています。DBもキューも使わずにビジネスロジックを検証できるのは利点です。

ただしこれで終わりではありません。プロジェクションの正しさ、べき等な振る舞い、スキーマ進化の経路については、別途結合テストが要ります。CRUDに比べてテスト対象の面積が増える、という前提で工数を見てください。

この章の補足Q&A

Q. 結果整合性を避けながらCQRSの利点だけ取る方法はありますか？

レベル1（同一データベースでモデルのみ分離）であれば、結果整合性は発生しません。読み取り性能が足りているうちは、この段階に留めておく判断は十分合理的です。

向く場面・向かない場面

マイクロソフトのドキュメントは、イベント駆動アーキテクチャの経験がないチームが採用すると「逆にコストがかかるアンチパターンのリスクが高くなる」と踏み込んで書いています。技術的な適合性だけでなく、チームの習熟度を判断軸に入れている点は見落としがちです。

そして現実的な結論は、全部入れるか入れないかではありません。支払台帳や注文処理のように恩恵が大きい部分にだけ選択的に適用し、ユーザープロファイル管理や設定のような領域はCRUDのまま残す。 この部分適用が、実務でもっとも成功率の高い進め方です。マイクロサービス単位で採用範囲を切る考え方については「マイクロサービスとは｜モノリスとの違い・採用判断・案件動向を解説」が参考になります。

フリーランスエンジニアから見たイベントソーシング/CQRS案件

どんな文脈で出てくるか

案件要件に「イベントソーシング経験者募集」と単独で書かれることは、まず多くありません。実際に遭遇するのは次のような形です。

• 決済・ポイント・在庫など、整合性と履歴が厳しい領域のリプレースで、設計方針としてCQRSが挙がっている

• 既存のモノリスをサービス分割する過程で、サービス間連携の設計としてイベントが登場する

• 監査要件（誰がいつ何を変えたか）が先にあり、その実装手段として検討されている

• すでにイベントソーシングで作られたシステムの保守・改修要員として募集される

4つめは要注意です。設計者が離任したあとのイベントソーシング製システムは、学習コストが高いわりに手を入れづらく、プロジェクト難度が上がりやすい傾向があります。参画前に、スキーマ進化の方針が文書化されているか、読み取りモデルを再構築する手順が実在するかを確認しておくと安全です。

求められるスキルと単価の見方

正直に書くと、イベントソーシングやCQRSという語そのものが単価を押し上げる、という単純な関係は観測できません。評価されているのは、その手前にある設計能力です。

• 集約の境界を業務語彙で説明できること

• 整合性要件を業務側と交渉し、落としどころを決められること

• 既存のCRUD資産との共存・移行計画を描けること

つまり、この領域は「上流設計ができるバックエンド」として評価される文脈に乗ります。レイヤー別・言語別の単価レンジは「バックエンドフリーランスの単価相場｜言語別・レイヤー別レンジと動向」、単価を上げる考え方そのものは「【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？」に整理しています。自分の経験でどのくらいのレンジを狙えるかを確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。実際の募集条件を見たい場合はフリコンの案件一覧から探せます。

面談で見られるポイント

パターン名を知っているかではなく、トレードオフを言語化できるかが見られます。「なぜ採用したか」より「どこで採用しなかったか」を具体的に話せると評価が安定します。

設計方針を提案として通す進め方は「技術選定の進め方5ステップ｜評価軸の作り方と提案を通す型」、設計スキルそのものの伸ばし方は「エンジニアの設計力・上流スキルの磨き方｜段階別ロードマップと単価アップ」でまとめています。

よくある失敗と対策

全社システムに一括適用してしまう。 もっとも多い失敗です。恩恵の小さい領域にまで複雑さだけが広がり、開発速度が落ちます。対策は単純で、1つの集約に限定して始めること。注文なら注文だけ、台帳なら台帳だけに絞り、しばらく運用してから範囲を広げます。

イベントを状態の差分で設計してしまう。 前述のとおり、残席数が42に変わったという記録からは意図が読めません。設計レビューの段階で「このイベント名だけ読んで、業務の人に何が起きたか伝わるか」を基準にすると判定しやすくなります。

読み取りモデルを作り直す手段を用意していない。 イベントソーシングの最大の利点は、ビューをいつでも再構築できることです。ところが再構築のバッチや手順を整備しないまま運用に入ると、その利点が使えません。初回リリース前に、全イベントからプロジェクションを再生成する経路を必ず通しておきます。

メッセージブローカーをイベントストアとして使ってしまう。 配信と記録は役割が違います。Kafkaに全イベントが流れているからイベントソーシングになっている、という理解は危険です。ストリーム単位の読み出しと並行性制御ができるかで判断してください。

導入判断チェックリスト

設計レビューの前に、以下を順に確認してください。上段の「必須条件」に1つでもNoがあれば、イベントソーシングの採用は見送りを推奨します。

必須条件

• 変更の履歴そのものに業務価値がある（監査・分析・トラブル調査のいずれかで実需がある）

• 読み取り側の反映遅延を、業務側が合意のうえで許容できる

• 対象を特定の集約に限定できる（全体適用を前提にしていない）

• 長期運用が前提である（短命なプロトタイプではない）

設計時に決めておく条件

• イベント名が業務の意図を表しており、結果の状態になっていない

• スキーマ進化の方針（寛容な逆シリアル化／バージョニング／アップキャスト）を選定済み

• イベントハンドラーのべき等性をどう担保するか決めてある

• スナップショットの取得間隔と再生成手順を決めてある

• 読み取りモデルをゼロから再構築する経路が実装・検証済み

• 個人データの扱い（外部保管か暗号化シュレッディングか）を決めてある

• イベントストアとメッセージブローカーの役割を分離して設計している

• 結合テストの範囲（プロジェクション・べき等性・スキーマ進化）を見積もりに含めている

下段は、1つ未決のまま進むと高確率で後戻りが発生する項目です。特に「読み取りモデルの再構築経路」は、運用開始後に必要になってから作ると難易度が跳ね上がります。

まとめ

イベントソーシングは「履歴を正とする保存方式」、CQRSは「読み書きのモデル分離」であり、別々に採否を判断できます。 履歴に業務価値がなく読み取り遅延も許容できないなら、CRUDのままが正解です。

• 2つはセットではない。CQRSのレベル1（同一DBでモデルのみ分離）から始める判断は十分に合理的

• イベントソーシングの正はイベントの並び。現在の状態は再生して導く派生物

• イベントは「結果の状態」ではなく「ビジネス上の意図」で設計する

• 結果整合性・スキーマ進化・べき等性・個人データ削除の4点は、着手前に方針を決めておく

• イベントストアとメッセージブローカーを混同しない

• 全体適用ではなく、恩恵の大きい集約への部分適用から始める

• 読み取りモデルの再構築経路は、初回リリース前に必ず通しておく

次のステップとしては、自分が関わるシステムの中で「履歴を聞かれて答えられなかった問い合わせ」を1つ洗い出してみてください。それが実需なら、該当する集約がイベントソーシングの最初の候補になります。

参照した一次情報

• イベント ソーシング パターン（Microsoft Learn）

• CQRS パターン（Microsoft Learn）

• Event Sourcing（Martin Fowler）

• CQRS（Martin Fowler）