CQRS+ESカンファレンス2026に参加しました
2026/01/10に開催されたCQRS+ESカンファレンス2026に参加してきました。
私はCQRS+ESの実践経験がないものの、現実で解きたい問題を解くためにソフトウェアエンジニアリングをする方法を考える上で非常に興味を惹かれるトピックです。
初心者でも理解できるだろうか...と少し不安な気持ちもありながら参加しましたが、当日は開催から閉幕まで（11:00〜18:00）があっという間に感じるほど面白い発表ばかりでした。
各セッションについて、特に印象に残ったことを中心に書いていきます。
AIによるイベントストーミング図からのコード生成：CQRS+ESの妙 | nrsさん
nrsさんの発表では、イベントストーミング図のスクリーンショットからAI(Claude Code)にコード生成させるデモとそれを支える考え方が共有されました。
イベントストーミングはnrsさんの以下の動画で学べます。本当にお世話になっています。
AIへの指示の流れ
デモ中の指示の流れは以下のようなものだったと記憶しています
- イベントストーミング図のスクリーンショットを添付し、ステップバイステップで実装するようにClaude Codeに指示（このあと作業させつつ、トーク）
- 成果物をざっと確認し、抜け漏れがあったら対象箇所のイベントストーミング図を再度スクショし、追加実装を指示
イベントストーミングで表現したドメインイベントの流れがそのままコードになっていく様子はかなり衝撃的でした。
AI活用のポイント
トーク開始時は割とざっくりした指示をされたように見えたのですが、実際にはしっかりプロンプトがありました。精度高く実装させるためのポイントとして次の部分が印象に残りました。
- ディレクトリ構造は技術的な関心ごとの水平分解よりもドメイン関心ごとの垂直分解がよい
- 効果的にコンテキストウィンドウに情報を渡すことができる
- プロンプトは育てるもの
- 凝ったプロンプトを自作するより、AIに書かせながらコード（結果）を見て修正を繰り返す
- 曖昧さがないように、命名規則やディレクトリ構造、付箋の色と定義などはしっかり含める
ちなみに、トーク冒頭でXの広告マネージャーにCQRS+ESが潜んでいる、という話が出てくるのですが、私がイベントを知ったきっかけはまさにnrsさんのX広告です。広告に感謝したのは初めてかもしれません。
手軽に作れる電卓を作ってイベントソーシングに親しもう | あきさん
デモ：https://akinoriakatsuka.github.io/es-dentaku
GitHub：https://github.com/akinoriakatsuka/es-dentaku
あきさんのトークでは、バニラJSで動く電卓アプリでESのメリットが共有されました。
イベントが残るから計算途中を復元できる
普通の電卓は12と表示されていたら、
-
1,2を順に入力した -
3×4を計算した -
2×6を計算した -
5+7を計算した
などなど色んな経緯が考えられますが、なぜそうなったかはわかりません。
この電卓は、このような経緯まですべて記録されているので一つ一つの入力途中を再現できるのが特徴です。
この違いがまさに「状態」で表現するか、「イベントの積み上げ」で表現するかを示しており、イベントソーシングの題材としての電卓は非常に直感的に理解できました。
イベントソーシングを阻むもの
印象的なスライドです。
操作を業務の言葉で表現していれば記録すべきイベントは明確になるはず
リソースをCRUDで操作する発想に極端に閉じ込められていると、「計算結果を更新した」のようなイベントを想像しそうですが、そうではない。
「3が入力された」「×が入力された」などのイベントの積み重ねとして計算結果がある。
私は普段Railsを書くのですが、このようなCRUDの扱いに非常に長けたフレームワークから技術に触れると思考回路としてCRUDが疑いようのない前提になることもあり得ると思います。（※RailsでもESを実践されている方々はいます）
このような前提を疑うことを可能にするとても興味深い発表でした。
また、あきさんは約1年前のCQRS+ESカンファレンスでイベントソーシングを知って、今年登壇されたということで行動力にも非常に刺激を受けました。
なぜコマンド側にアクターモデルが必要になるのか | かとじゅんさん
かとじゅんさん発表では、CQRS+ESをオブジェクトベースで実装する場合の限界とアクターモデルという概念が出てくる必然性について共有されていました。
私は「アクターモデルとは...？？」という状態からスタートしました。
ReadModelとイベント
私がCQRS+ESについて軽く調べたとき、疑問に思ったのは
- 状態ではなくイベントを記録する発想はわかった気がするが、GETで取得される情報はどうやって管理するのか
- イベントを記録するということは、状態を記録するよりはるかに多いデータ量になるがどう取り扱うのか
ということでした。この疑問はXでいただいた引用リプやかとじゅんさんのご発表で一定イメージできるようになりました。カンファレンスってすごい...!!
このスライドで言えば、clientの初回読み込み時はRead API Serverからデータを取得し、その後はSubscription Serverから配られるイベントで画面を更新するような構成を取るようです。Queryはストック、Eventはフロー型の情報です。ReadModelUpdaterが複雑になりがちという理解をしているのですが、それも納得感があります。
イベント記録の競合管理とアクターの導入
アクターモデルとはなんぞ？を明瞭に説明できるまでは至れなかったのですが、アクターモデルという概念が重要そうである理由は以下のように理解しました。
- 非常に素朴にロック等を意識せずにイベント記録を行うことを考えると、現代の大抵の構成ではロードバランサの背後にサーバーマシンが複数台存在するため「イベントの追い越し」が発生し得る。
- これを阻止するには、ドメインオブジェクトのバージョン管理によるロック制御を導入できるが、競合発生時にユーザーにリトライを強いるためUX低下が発生する。
- これを解決する考えがアクターモデル。特定の集約に対するアクターインスタンスはシステム内で単一であり、データ共有をせず、メールボックスを持つ。この特性から、イベント更新はメールで受け付け、更新は順次可能になる。
インフラも含めてかなり高度なお話で、刺激的でした。
新しい機能では「"状態"ではなく"事実(イベント)"を記録する」ことを選びました | すずきさん
すずきさんの発表では、ネットスーパーを扱うシステムでのこれまでのつらみとイベントソーシングをどう活用していったかが共有されました。
ピッキング・パッキング業務の事例
ネットスーパーは注文受付や店内からの商品ピッキング、注文通りに梱包、配送など様々な人が携わる業務領域とのことです。今回のお話は
- これまでピッキング担当者の操作はローカルで一定蓄積され、「状態」がサーバーに送信されていた
- イベントソーシングの考えを適用することで、「イベント」を逐次的に送信可能になり、ユーザー行動の解像度向上（問い合わせ対応品質向上）、UX向上等の効果があった
という実業務での導入・効果事例でした。技術的にもかなり良い効果が紹介されており、業務がイベントで表現されるのが自然だったからこそ、技術的な表現も自然になったように見えました。
業務、業務、業務！！！
思わずこのようにつぶやいていました。
発表者のすずきさんのユーザー解像度の高さが凄まじく、技術的な話も盛り沢山なのですが、「技術はあくまでも手段」というのはまさにこのことかと感じました。
たとえば、品切れに関する事例で次のようなことをおっしゃっていました。
- 状態管理だけの場合は、ピッカーさんは便が変われば入荷があるか確認する必要がある
- たとえば惣菜の場合、惣菜調理の人に確認することもあるが、何度も聞きに行くのは互いにストレスがかかる
- ただの状態ではなく、イベントをトリガーに品切れ状態を集計・更新することでシステム上で確認可能になる
言われて想像してみれば反論の余地なく同意できるのですが、机上で機能再現だけを考えているとなかなかここまで想像できないこともあるかと思います。業務理解と適切なモデル化、モデルを実装する技術を組み合わせれば、こんな現実の価値が出せるんだと希望を感じる発表でした！
スタートアップ企業での7年の軌跡：なぜEvent Sourcingを選んだのか、そして既存サービスへの段階的適用の実践 | 佐藤さん
佐藤さんの発表では、とにかく動くプロダクトを作るスタートアップの状況から、物理的な鍵等を扱う業務領域でイベントソーシングの考えを適用していくまでの流れが共有されました。
動くカオス→求める秩序→なお複雑な業務
私も今、とにかく動くものを！から少し脱却したい状況にいるので臨場感を持って聴くことができました。
動く状態のプロダクトをクリーンアーキテクチャなどを参考に整理していったものの、プロダクト拡大に伴いユースケースが増えて見通しが悪くなって...という話だったかと思います。構造の秩序は得たけど、意味の秩序は得ていなかったというような表現が印象的です。
具体例として、デバイスモデルのお話がありました。認証方法などによって様々な「デバイス」そのものをモデル化して整理したものの、「デバイスの設置」と「デバイスの解錠」のユースケースで使いたいデバイスモデルは全然違うというお話は、コンテキストでモデルを分ける重要性をイメージできました。
イベントソーシングの導入とチーム
個人的により深く聞いてみたくなったのは、とにかく動く状態ベースの構造からイベントソーシングのアイデアの導入までのチームの変遷です。結構大きなメンタルモデルの変革を迫るものだという感覚があるので、なぜ変化できたのかとても気になりました。
発表で触れられていた、状態変更の話は抽象的であり、イベントの話は具体的というアイデアがひとつのキーかもしれないと感じています。イベント（事実）をまず特定し、イベントの制約を特定して、イベントによる状態変化を考える。このような流れで会話をすることで自然にES的な発想が入ってくるのかもしれません。
物理的なデバイスとイベントソーシング
私の仮説として、物理的なデバイスはセンシング機構などがない限り、現在の状態を取得することはできませんし、できたとしてもデバイス側にサーバー機能がないと現状の状態を返すことはできないので難しそうだと考えていました。
お話を伺っていると、実際「状態」で管理するのは難しかったようです。特に、なぜその状態になったのか？は「当時の」ソースコードに依存するというお話があり、コードとデータの責務で捉えるのはすごくスッキリしました。
AI活用とES
今回の資料ではないですが、次のような4象限のお話があり、興味深かったです。
予防的な領域は動かす前に発見したいので強化したいのですが、主観的な判断領域は人間の関与が必要でボトルネックになりがちなので縮小したいということでした。
この考えのもとで、CQRS+ESはQueryとEventを分けられるため重点的にレビューすべき変更を分離できるという話があり、nrsさんの発表のようにAIで大半を記述できるならば無視できないメリットになりそうだと感じました。
コマンドとリード間の連携に対する脅威分析フレームワーク | くどうさん
工藤さんの発表では、CRQSのアーキテクチャにおいて同期・非同期連携を選択する際の評価方法としてCQRS Linkage Threat Matrixが共有されました。
情報量も多く、私の背景知識から一番理解に自信がないのですが、わかるようになりたい内容でした！
サービス境界と連携の同期・非同期
業務的な意味の観点ばかりの頭になっていたので、サービス境界をセキュリティの信頼性の観点で考える切り口はとても勉強になりました。
サービスを提供してしまう前に、机上で設計している段階で脅威分析をせよ！と。
CQRSのコマンドリード関連系の同期、非同期を安直に決めず、ちゃんと評価する手法として紹介された8つの観点による分析はすぐに使える問いだと感じました。
脅威とリスクは分けて考える
考えた設計モデルに対して、発生しうる脅威を特定し、スコアリングすることでリスクを評価する。脅威は事象、リスクはそれをプロダクト特性などを考慮し重み付けしたものと明確に分けて取り扱うのはその通りだなぁと。
普段の会話では「リスク」とだけ言いがちになっているので、気をつけたいなと思いました。リスクがリスクである理由、リスクとなる事象を取り巻く環境を会話しなければいけないですね。
このあたり読んでもっと勉強していきたいです。
まずはドメインに向き合って、それから CQRS で実装する | Kosuke Abeさん
Kosuke Abeさんの発表は、非常に丁寧な言葉の取り扱いとただ業務をシステムに落とすだけではなく、ドメインに向き合って価値創造を行う実例が特に印象的でした。
CQRSは体験に視野が行く
CQRS+ESというアーキテクチャパターンの恩恵を受けるためには、ユーザーの意図を汲み取り、体験に気を配る（プロダクトデザイン）ことが重要という旨を読み取ったスライドがありました。
CRUDベースでシステムを設計すると、何を作成する？何を更新する？と考えてしまいますが、現実の生活で作成更新するのは免許証のような資格証明ぐらいしかパッと思い浮かびません。
CRUD志向のUIはユーザー意図ではなく、設計側の概念モデルの表出となるので、ユーザーにモデル理解を強いるというのは、高齢の方にスマホの使い方を教える会話を想起させました。
「この家族アルバムの写真、○○に見せたい、どうしたらいい？」
「ここ押したら共有のメニューがあるので、○○さんを選んでください。」
「○○表示されてない。」
「新規に共有したいご家族なのですね。まずはアルバムにアクセスを許可しましょう...」
私も祖父と近い会話をした記憶があります。
デジタルネイティブ世代と高齢の方の差は、類似の概念モデルの経験値なんだとハッとしました。
CQRS+ESはアーキテクチャパターンでありながら、イベント（現実の事実）からモデリングが始まるため、ユーザー体験に寄り添った強いプロダクトデザインに繋がるというのはこういうことかと気付きを得たように思います。
制約とポリシーで柔軟な現実を表現する
ポリシーを比較的緩やかなビジネス上の意思決定と捉えるのは、ピースがはまったような感覚を得ました。
スライドにもあったスタバの例がすごくわかりやすく、固定観念で支払い完了の後にドリンク提供をすると思い込んでいたのですが、注文確定時点でドリンクを作っていいのです。支払い完了を確認できなければ作ったドリンクを提供しなければよい。
この、支払い完了を経てドリンクを作るラインを組むか、少し無駄になっても注文確定時に作り出すラインを組むかは判断基準でどちらもあり得ます。
コスト管理、食べ物を大事に、SDGsを前面に押し出し、オペレーションを整合させることも価値に転化するなら前者が優先されそうですし、分業ライン、素早い提供、ユーザー体験ファーストのようなキーワードが価値なら後者を優先しても良さそうです。
この判断はまさにポリシーという言葉の通りで、ビジネス上の意思決定に対応しそうです。イベントストーミングで作られる図はここまで迫れるんですね。
ぎこちなさはドメイン理解のチャンス
会員証の具体例は聞いているだけで気持ちよくなる価値創造でした。
CRUDを悪にしない
CQRS+ESすごい！と感じるのですが、やっぱり技術的に色んな大変さがありそうです。
状態はスナップショットであり、イベントは事実であるというだけで、どちらが良い悪いではないということを肝に銘じたいと思います。
状態の記録は解像度は低いですが、ソフトウェアで表現したいモデルとしては十分なことも多いです。
パブリックで協調的に扱われるものはCRQS+ES、プライベートで比較的独立に扱われるものはCRUD、のような判断のひとつの指針も勉強になりました。
今回初めてGreg Young氏やUdi Dahan氏のことを知りました。そういった権威の言葉を引用しつつ発表くださったので、今後の自学にも非常に有益でありがたかったです。
純粋なイミュータブルモデルを設計してからイベントソーシングと組み合わせるDeciderの実践方法の紹介 | 高丘さん
高丘さんの発表では、関数型イベントソーシングの実装パターンであるDeciderパターンとモデリング、設計に関係するDCB(Dynamic Consistency Boundary)というアイデアを採用・運用しての所感などが共有されました。
イミュータブルに設計・実装する
純粋関数とデータモデルでイミュータブルにドメインを表現していくことは『関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう』などで良さそうだと考えていたのですが、本発表ではこのように実装することが「LLMへのガードレール」として有用とされており、興味深かったです。
ちょうど最近仕事で、アプリケーションコードに扱っている値の定義がないという結構まずい状態を改善する取り組みをしているのでエッセンスを取り入れたいと感じました。
また、ESで情報を保持することで「なぜそうなったのか」が記録される設計であることもLLM協業の中でメリットになるのは間違いないと感じます。
DCB
DCBは初めて知った概念でしたが、DDD的なアプローチで取り組んでいる中でも、ビジネスをモデリングする方法にこれだけバリエーションというか、進化が起こっていることに驚きました。
集約が起点にあって、それをイベントでどう変化させると考えるのか。
イベントが起点にあって、そのイベントが複数の集約にどう影響するかを考えるのか。
こんな違いなのかな？と今は考えています。
Sekiban
今回の発表のような内容も実践可能なCQRS+ESのフレームワークSekibanのデモがありました。
C#で作られており、.NET SDKさえ入っていれば以下のコマンドで簡単にスタートできるそうです！
dnx CreateSekibanTemplate
立ち上がったアプリは会議室予約等が行えるもので、アプリとしても単純に良さそうですごかったです。
.NETは新卒の頃に少し触れてそれっきりなのですが、こちらを理解するためにまた触れてみたいと思います。
高丘さんはなんとアメリカから、現地時刻深夜にも関わらずリモート登壇されたそうです！刺激的なご発表ありがとうございました🙇
CQRS+ESで実現するAI-ReadyなGraphRAG実践 | ytakeさん
イベント最後は、主催のytakeさんによるショート発表でした。
この時間で話すボリュームじゃないとおっしゃっており、Xのタイムラインは詳しく聞きたい人で溢れていました。
GraphRAGとES
通常のRAGはベクトル化された情報の類似度で情報を引っ張ってくるので、因果関係ではなくそのベクトル化手法で計算された結果、類似度が高いとされる「それっぽいもの」を返します。
GraphRAGは知識をベクトル化するのではなく、グラフで表すことで情報間の関係性なども含めて表現することで、より構造的な回答を行えるようなもののようです。
本発表のアイデアはCQRS+ESのReadModelとして、グラフを生成するというものだと理解しました。
アプリケーションで扱いたい業務をイベントでモデリングし、イベントだけでは状態が表現できないのでReadModelみたいな概念が出てくるのかなぁ程度で理解していたので、まさかここにGraphRAGというアイデアがくるとは...
イベントソーシングなしでは成り立たない発想でめちゃくちゃ面白かったです。
カンファレンスで得た学び
小さく始めて良い
CQRS+ESを実際に採用しなくても、参考にできるアイデアがたくさんありました。そして、実際に少しづつ本番適用されている方々がいることを知ることができました。
CRQS+ESは選びどころがある
イベントストーミングのような手法や実際に適用された例を聞いていると、確かに「イベント」が存在していました。
私は業務アプリの開発にはDDD的なアプローチがいいんじゃないかと思い込んでいたのですが、例えば以前取り組んだことがあるGIS(地理情報システム)のようなものだと、イベントを捉える発想は難しそうだと感じました。
ただ、難しいというのは不可能ではなく、イベントを発見できる可能性はあるのではないかと感じました。現実世界のアナロジーが難しかったり、解像度が低かったりするからイベントで語るのが難しく、語る経済的メリットもまだない状態なだけかもしれません。
CQRS+ESすごそうなのでやってみたい！ではなく、ドメインに向き合って採用する合理性がありそうか天秤に乗せられる状態であろうと思います。
おわりに
イベント参加前には全く分からなかったワードも少しづつ理解が深まっていくような、素晴らしい1日でした。
また、どなたのお話も技術を使って現実の問題をより良く解こうとする熱いパッションのようなものを感じました。
今回は福岡開催なので参加してみるか〜と気軽な気持ちで行ったのですが、次回があればどこでも参加したいと思います！運営の皆様、登壇者の皆様、また会場の福岡工業大学様、改めて本当に素晴らしい会をありがとうございました。
無料だったんですよ...信じられない。
Discussion