LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

CQRSとイベントソーシングとは何か

CQRS（コマンド・クエリ責任分離。Command Query Responsibility Segregationの略で、データの更新処理と参照処理を別々のモデルで扱う設計パターン）とイベントソーシング（Event Sourcing。状態そのものではなく、状態を変化させた一連のイベントを記録として保持する設計パターン）の導入とは、複雑なドメインにおいて読み取りと書き込みの要件が乖離した場合や、変更履歴の完全な保持が求められる場合に、データの持ち方そのものを見直す取り組みを指します^*1*2。

CQRSとは、データの更新（コマンド）と参照（クエリ）に異なるモデルを用いる設計パターンを指します^*1。従来型のCRUD（Create・Read・Update・Deleteの4操作）アーキテクチャは、更新と参照を単一のデータモデルで扱うため単純ですが、ドメインが複雑になるほど両者の要件差が無視できなくなります。Microsoft Azure Architecture Centerは、単一モデルの継続利用によって「読み取り時と更新時でデータの表現が異なる」「同一データへの並行操作によるロック競合」「クエリの複雑化に伴う性能低下」「読み書きの権限管理の難しさ」という課題が生じると整理しています^*2。

一方のイベントソーシングは、エンティティの最新状態だけを保存するのではなく、そのエンティティに生じた変更を一つひとつのイベントとして時系列に追記していく設計です^*3。現在の状態は、記録されたイベント列を最初から順に適用（リプレイ）することで導出します。Martin Fowlerは、この方式によって「任意の過去時点の状態を再現できる」「誤って記録されたイベントの影響を打ち消すイベントを追加して訂正できる」といった利点が生まれると述べています^*3。

両パターンはしばしばセットで語られますが、由来も目的も異なる別個の設計判断です。次章以降で、それぞれの考え方と関係、そして外注で進める際の実務ポイントを順に整理します。

CQRSの考え方 — コマンドとクエリを分離する設計

CQRSの核心は、更新系の処理を「コマンド」、参照系の処理を「クエリ」として明確に区別する点にあります。Azure Architecture Centerは、コマンドを低レベルなデータ更新ではなく「予約する」「注文する」といった業務上の意図を表す単位で設計すべきだとしています^*2。クエリ側はデータを一切変更せず、画面表示に最適化した形式でデータを返す役割に徹します。

実装の深さには段階があります。基礎的な形は、読み取り用モデルと書き込み用モデルの区分だけを設け、データストア自体は単一のまま共有する構成です^*2。より進んだ形では、読み取り用と書き込み用で別々のデータストアを用意します。この場合、書き込み側の変更を読み取り側に反映する同期の仕組みが必要になり、代表的な方法として書き込み側がイベントを発行し、読み取り側がそれを購読して自らのデータを更新する構成が使われます^*2。

この分離によって、読み取りと書き込みを別々にスケールできる、それぞれの処理に適したデータ構造を選べる、書き込み権限と参照権限を分けて管理しやすくなる、といった利点が得られます^*2。特に読み取り回数が書き込み回数を大きく上回るシステムでは、読み取り側だけを水平にスケールさせられる恩恵が大きいとされています^*2。

Martin Fowlerは、CQRSがイベント駆動のプログラミングやイベントソーシング、結果整合性（更新直後は一時的にデータの不整合が生じうるが、時間の経過とともに整合する方式）と組み合わせやすいパターンだと述べる一方で、「多くの場合、CQRSは適切な選択ではなく、生産性の低下とリスクの増大を招く」と明確に警告しています^*1。適用は特定の境界づけられたコンテキスト（システム全体ではなく意味のまとまりを持つ一部の領域）に限定すべきだという立場です^*1。

イベントソーシングの考え方 — 状態でなくイベント列を記録する

イベントソーシングは、CRUD型のように行を上書きするのではなく、発生した出来事を追記専用のストアに記録し続ける方式です^*3*4。Azure Architecture Centerは、この方式が向くのは高負荷時の書き込み競合と、変更履歴の欠落という2つの課題を解決したい場面だと説明しています^*4。CRUD型は更新のたびに読み取り・変更・書き込みのサイクルと行ロックを伴うため、同一エンティティへの同時更新が多いと性能上のボトルネックになりやすいとされています^*4。

イベントソーシングでは、各イベントは「注文にアイテムを追加した」「注文をキャンセルした」のように、業務上の意図を表す単位で設計することが推奨されています^*4。単に「残り数量が42になった」という結果だけを記録すると、何が起きたのかという文脈が失われ、監査ログとしての価値が下がるためです^*4。現在の状態を求める際は、対象エンティティに関するイベントを最初から順に適用し直します。この処理はリハイドレーション（rehydration）と呼ばれます^*4。

イベント列が長くなると、都度すべてを再生するのは時間もコストもかかります。そこで用いられるのがスナップショットです。一定間隔ごとにエンティティの状態をシリアライズして保存しておき、リハイドレーション時は直近のスナップショットから、それ以降のイベントだけを適用することで再計算を最小限に抑えます^*4。Azure Architecture Centerは、スナップショットはあくまで最適化の手段であり、イベントストア自体を置き換えるものではないと注記しています^*4。

Fowlerが指摘するもう一つの重要な論点が、外部システムとの連携です。イベントを再生（リプレイ）する際、その都度外部システムへの通知が重複して発生するリスクがあるため、通知の重複を制御する仕組み（ゲートウェイ的な仕組み）を挟む必要があるとしています^*3。Azure Architecture Centerも同様に、イベントの配信は「少なくとも1回」が前提であるため、イベントハンドラー側を冪等（同じイベントを複数回処理しても結果が変わらない設計）にする必要があると述べています^*4。

両者の関係 — 併用が定番だが単独採用も可能

CQRSとイベントソーシングは、しばしば組み合わせて使われますが、どちらか一方だけを採用することも可能です。CQRSは読み書きモデルの分離という設計判断であり、書き込み側のデータをどう永続化するかとは独立した論点です。したがって、書き込み側は従来どおりの状態保存のままでも、読み取り側だけモデルを分けるCQRSの適用はできます^*2。

両者を組み合わせる場合、Azure Architecture Centerはイベントストア自体を書き込みモデル（正となる記録＝single source of truth）とし、読み取りモデルはそのイベントから作られる非正規化された投影（マテリアライズドビュー）として構成する形を示しています^*2*4。書き込みモデルを更新するのと同じイベントを読み取りモデルの入力としても使えるため、イベントストアを正の記録として保てば、読み取り用のビューはいつでもイベントを再生して作り直せます^*2。

この組み合わせの利点は、書き込み側の設計をイベント単位でシンプルに保てる点と、要件変更時に読み取りモデルだけを作り直せる柔軟性にあります^*2。一方で、書き込みと読み取りが別ストアになることで生じる結果整合性への対応や、イベント処理とビュー更新のためのコード量増加という負担も同時に発生します^*2。単独採用か組み合わせかは、システムの要件次第で判断すべき論点です。

過剰適用の戒め — 全体ではなく一部の集約に限定する

CQRS・イベントソーシングともに、システム全体へ一律に適用することは推奨されていません。Fowlerは「ドメインが単純な場合や、単純なCRUD型の画面とデータアクセスで十分な場合には適さない」という趣旨の限定を明確にしています^*1。Azure Architecture Centerも、CQRSが適さない場面として「ドメインや業務ルールが単純な場合」「シンプルなCRUD型のUIとデータアクセスで足りる場合」を挙げています^*2。

イベントソーシングについても同様の立場が示されています。Azure Architecture Centerは「監査や再現、履歴からの状態復元を必要としないシンプルなCRUD操作しかないシステムでは、イベントストアの運用負担が見合わない」と明記し、マスターデータやカタログのように更新頻度が低く変更履歴の価値が薄いデータ、短命なプロトタイプやMVP（実用最小限の製品）にも不向きだとしています^*4。さらに「イベント駆動アーキテクチャの経験がないチームが基礎知識なしに採用すると、後から修正しづらいアンチパターンのリスクが高まる」とも注意を促しています^*4。

実務上の指針として、Azure Architecture Centerは「イベントソーシングをシステム全体に対するオール・オア・ナッシングの決定にする必要はない」とし、決済台帳や注文処理のように恩恵の大きい一部の集約（ドメイン駆動設計における、一貫性を保つべきデータのまとまり）に限定して適用し、ユーザープロフィール管理やアプリケーション設定のように複雑さが見合わない部分は従来型のCRUDのままにする選択を推奨しています^*4。

外注を検討する際も、まず対象システムのどの領域が読み書き要件の乖離や監査要件を抱えているかを洗い出し、その一部だけに適用範囲を絞るところから着手するのが定石です。全機能への一律導入を提案してくる委託先には、適用範囲の根拠を確認する必要があります。

結果整合性とイベントスキーマ進化という難所

CQRSで読み取りストアと書き込みストアを分離する場合、読み取り側への反映には遅延が生じます。この遅延の間、読み取り側は最新の変更を反映していない状態になり、結果整合性（eventual consistency）と呼ばれます^*2。Azure Architecture Centerは、利用者が古いデータを基に操作してしまう場面をどう扱うかを、設計段階で慎重に検討する必要があると述べています^*2。メッセージングを介する構成では、メッセージの失敗・重複・再送といった問題への対応も追加で必要になります^*2。

イベントソーシング側の難所は、イベントスキーマの進化です。イベントストアは永続的な記録であるため、一度記録したイベントのデータを書き換えることは原則としてしません。エンティティの訂正や取り消しは、過去のイベントを打ち消す新しいイベント（補正イベント）を追加する形で行います^*4。この不変性ゆえに、バグによって誤ったイベントが記録された場合、アプリケーションコード側のバグを直しても過去のイベント自体は残り続けるという特性があります^*4。

スキーマ自体を変更したい場合、Azure Architecture Centerはいくつかの戦略を示しています。未知のフィールドを無視し欠落フィールドに既定値を使う「寛容なデシリアライズ」、イベントにバージョン識別子を持たせる「イベントバージョニング」、旧スキーマを新スキーマへ変換する処理を登録する「アップキャスティング」、そして最後の手段として過去のイベント自体を新スキーマへ書き換える「インプレース移行」です^*4。最後の方法は不変性を損なうため推奨されておらず、監査証跡としての価値を弱める点に注意が必要だとされています^*4。

このほか、個人情報保護規制への対応も論点です。追記専用で不変というイベントストアの性質は、「忘れられる権利」のようなデータ削除要求と本質的に相性が悪いため、個人情報はイベント本体の外に置いて参照する設計や、対象者ごとの鍵で暗号化し鍵の破棄によって復元不能にする設計（クリプトシュレディング）が実務上の対応として挙げられています^*4。

外注で進める場合の委託範囲と発注準備

CQRSやイベントソーシングの導入を外注する場合、発注前に committed すべき論点がいくつかあります。第一に、適用範囲の特定です。前章までに述べたとおり、これらのパターンは一部の集約に限定して適用するのが定石であるため、委託先に丸ごとの設計を任せるのではなく、自社側で「どの業務領域が読み書き要件の乖離や監査要件を抱えているか」の一次整理をしたうえで相談する進め方が有効です。

第二に、結果整合性を許容できる業務要件かどうかの見極めです。Azure Architecture Centerが示すとおり、読み取りと書き込みを分離すると反映に遅延が生じます^*2。在庫数や残席数のように即時の一貫性が業務上不可欠な箇所には、別の設計判断が必要になる場合があります。この判断は外注先だけに委ねず、業務要件を理解する自社側の担当者を交えて確定させる必要があります。

第三に、イベント設計とスキーマ進化戦略の擦り合わせです。イベントは業務の意図を表す単位で設計する必要があり^*4、これは技術者だけでは決めきれず、業務ドメインの理解が欠かせません。また将来のスキーマ変更にどう備えるか（アップキャスティングを採用するのか、バージョニングの粒度をどうするか）を、開発着手前に委託先と合意しておくと、後工程での手戻りを抑えられます。

第四に、テスト・運用体制です。イベントソーシングを採用したシステムのテストは、過去のイベント列を用意してコマンドを実行し、生成されるイベントを検証する形（given-when-then形式）が基本になり、投影（マテリアライズドビュー）やイベント処理の冪等性、スキーマ進化の経路についても別途の統合テストが必要になります^*4。これはCRUD型システムに比べてテスト対象が増えることを意味するため、外注時の見積もり範囲にテスト工程が明示的に含まれているかを確認する必要があります。

内製でこれらを完結させるには、ドメイン駆動設計・イベント駆動アーキテクチャ・分散システムにおける整合性設計という複数領域の知見を持つ人材が必要になります。Azure Architecture Centerも、イベント駆動アーキテクチャの経験がないチームがこの基礎知識なしに採用することへ注意を促しており^*4、経験を持つ外部パートナーと役割分担する意義はこの点にあります。LASSICは元請（プライムベンダー）として、要件整理の段階から適用範囲の見極めに関与し、過剰適用を避けた設計を支援する体制を取っています。

まとめ：CQRS/イベントソーシング導入の3つの判断軸

本稿では、CQRSとイベントソーシングという2つのデータ設計パターンについて、それぞれの考え方と関係、適用時の難所、外注時の進め方を整理しました。要点は3つに集約できます。第一に、CQRSは読み書きモデルの分離、イベントソーシングは状態でなくイベント列を記録する仕組みであり、両者は組み合わせも単独採用も可能な別個の設計判断です。第二に、いずれも一次情報が繰り返し警告するとおり、システム全体への一律適用ではなく、恩恵の大きい一部の集約に限定して採用する対象です。第三に、外注する場合も適用範囲の特定と結果整合性の許容度、スキーマ進化戦略の合意を、委託先任せにせず自社側で確定させることが導入の成否を分けます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Martin Fowler「CQRS」（martinfowler.com/bliki/CQRS.html）
2. *2　出典：Microsoft「CQRS pattern – Azure Architecture Center」（2025年、learn.microsoft.com/en-us/azure/architecture/patterns/cqrs）
3. *3　出典：Martin Fowler「Event Sourcing」（martinfowler.com/eaaDev/EventSourcing.html）
4. *4　出典：Microsoft「Event Sourcing pattern – Azure Architecture Center」（2026年、learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing）

Tweet