アーキテクチャパターン

CQRS（コマンドクエリ責務分離）しーきゅーあーるえす

コマンドクエリイベントソーシングマイクロサービス読み書き分離ドメイン駆動設計

CQRSについて教えて

簡単に言うとこんな感じ！

「データを書く窓口」と「データを読む窓口」を完全に別々にする設計のことだよ！レストランで「注文カウンター」と「料理を受け取るカウンター」が分かれてるイメージで、それぞれを独立させることで大量アクセスにも強くなるんだ！

CQRSとは

CQRS（Command Query Responsibility Segregation＝コマンドクエリ責務分離）とは、システムへの操作を「コマンド（書き込み）」と「クエリ（読み取り）」という2種類に分け、それぞれを完全に独立した経路・モデルで処理するアーキテクチャパターンです。通常のシステムでは「データの読み書き」を同じ場所・同じ仕組みで行いますが、CQRSではそれを意図的に切り離します。

もともとはBertrand Meyerが提唱した「CQS（Command Query Separation＝コマンドクエリ分離原則）」という設計原則に由来します。CQSは「メソッドは値を返すか、状態を変えるか、どちらか一方のみ行うべき」という考え方です。CQRSはこれをより大きなアーキテクチャレベルに拡張したもので、Greg Youngが2010年前後に広めました。

実務上では、ECサイトや予約システムのように「大量のユーザーが同時に閲覧（読み取り）しながら、一部のユーザーが購入・変更（書き込み）する」という負荷の偏りがあるシステムで特に効果を発揮します。読み取りと書き込みのスケールアウト（処理能力の拡張）を個別に行えるため、パフォーマンスと保守性が大きく向上します。

CQRSの仕組みと構造

CQRSの中心的なアイデアは「書く側と読む側はそもそも求めるものが違う」という認識です。書き込みは整合性・トランザクションが重要で、読み取りは速さ・柔軟な絞り込みが重要です。これを同じモデルで扱おうとすること自体が無理の原因になります。

側面	コマンド（書き込み）	クエリ（読み取り）
目的	状態を変更する	状態を返す（変更しない）
例	注文する・キャンセルする	商品一覧を見る・注文履歴を確認する
重視するもの	整合性・トランザクション	速度・柔軟性
データモデル	書き込み最適化（正規化）	読み取り最適化（非正規化）
スケール戦略	垂直スケール（性能強化）	水平スケール（台数増加）
DB	書き込み用DB（主系）	読み取り用DB（レプリカ・専用ストア）

覚え方：「CQRS＝厨房とホール」

レストランに例えると、厨房（コマンド側）が料理を作り・在庫を更新し、ホール（クエリ側）がお客様にメニューを見せ・注文状況を伝える。厨房とホールは役割が違うので、それぞれ別のスタッフ・別の仕組みで動いている—これがCQRSのイメージです。

コマンドとクエリのデータフロー

【コマンド側（書き込み）】
  ユーザー操作
     ↓
  Command（命令）発行
     ↓
  CommandHandler（処理）
     ↓
  ドメインモデル（ビジネスロジック）
     ↓
  書き込みDB（整合性優先）
     ↓（非同期で同期）
【クエリ側（読み取り）】
  読み取り用DB（速度優先）
     ↑
  QueryHandler（処理）
     ↑
  Query（問い合わせ）発行
     ↑
  ユーザー画面

歴史と背景

1988年 — Bertrand MeyerがCQSの原則を提唱（著書「Object-Oriented Software Construction」）。「メソッドは命令か問い合わせかどちらか一方のみ」を主張
2000年代初頭 — ドメイン駆動設計（DDD） の普及とともに、複雑なビジネスロジックを持つシステムでの読み書き分離の重要性が認識されはじめる
2010年前後 — Greg YoungとUdi Dahanがブログ・講演を通じてCQRSという名称・パターンを体系化・普及させる
2012〜2015年 — マイクロサービスアーキテクチャ の台頭と相性の良さが注目され、急速に広まる。イベントソーシング との組み合わせが定番化
2015年以降 — クラウドネイティブ環境（AWS・Azure・GCP）でのCQRS実装パターンが整備され、AzureアーキテクチャガイドやAWSホワイトペーパーで公式に言及される
現在 — マイクロサービス・大規模Webサービスの標準的なパターンとして定着。過度な適用による複雑化への警鐘も広まる

CQRSと関連パターン・技術の比較

CQRSはそれ単体で使われることもありますが、イベントソーシング との組み合わせが特に有名です。また、似た概念との違いを押さえておくと整理しやすくなります。

CQRSを使うべき場面・使わなくていい場面

適用すべきケース	適用しなくていいケース
読み取りと書き込みの負荷が大きく異なる	小規模・シンプルなCRUDアプリ
複雑なビジネスロジックがある	チームの規模が小さく学習コストを払えない
マイクロサービス構成で責務を分けたい	データの整合性をリアルタイムで保つ必要がある
スケールアウトを個別に行いたい	開発初期のプロトタイプ
イベントソーシングと組み合わせたい	シンプルな管理画面・社内ツール

⚠️ 過剰適用に注意！ CQRSは強力な反面、実装の複雑さが増します。「読み書き分離が本当に必要か」を先に検討することが重要です。Microsoftのアーキテクチャガイドでも「デフォルトで使うパターンではない」と明記されています。

ドキュメント	内容
Microsoft Azure アーキテクチャガイド: CQRS	Microsoftによる公式CQRS解説・実装パターン
AWS prescriptive guidance: CQRS	AWSによるCQRS実装ガイダンス