こんにちは！ ファサード開発チームの中川です。
2026/01/10 に開催された CQRS+ES Conference 2026 に、チームの開発メンバーとともに参加してきました。
私の所属するファサード開発チームでは、Chatworkのファサード層（API Gateway層）を開発・運用しています。
既存の仕組みと新しいアーキテクチャをつなぎつつ、クライアントに安定したインターフェースを届ける役割を担っています。(詳しくは、Chatworkの技術的展望について - kubell Creator's Noteの記事に詳細がありますので、気になる方はぜひご覧ください！)
こうしたつなぎ目のレイヤーで開発をしていると、可用性や拡張性を落とさずに連携していく設計が重要だと感じる場面が多いです。
今回のカンファレンスは、まさにその周辺(イベント・ドメイン・分離・運用)をまとめて吸収できそうだと思い、チームで参加しました。
なお、私自身は新卒1年目で、技術カンファレンスへの参加も今回が初めてです。
本記事では、当日印象に残ったことと、複数のセッションを通して共通して学んだことを中心に初学者の目線で振り返ります。
CQRS / ES とはどのようなものか
ここでは、CQRS と イベントソーシング(ES) についてざっくりと説明します。
- CQRS は、「更新処理（コマンド）」と「参照処理（クエリ）」で目的と最適化が異なるものとして捉え、別の責務・別のモデルとして設計する考え方です。 コマンドは状態を変えることに集中し、クエリは読むことに集中することで責任を分離します。
- イベントソーシングは、データの“今の状態”ではなく、起きた出来事(イベント)を正として時系列で保存し、それを再生して状態を復元できるようにする考え方です。
CQRS とイベントソーシングは必須の組み合わせではありませんが、 CQRS の「コマンド側で出来事を確定し、クエリ側でそれを参照に最適化する」という分離は、 「出来事をイベントとして残し、それを元に参照用データを作れる」イベントソーシングと相性が良いため、併用されることが多いです。
印象に残ったこと
イベントストーミングを「AIで実装へ橋渡し」する発想
今回、イベントストーミングという手法を初めて知りました。
イベントストーミングは、付箋を使って業務で起きる出来事(ドメインイベント)を時系列に並べ、関係者みんなでドメイン理解を揃える手法です。 特に印象に残ったのが、イベントストーミングで描いた図をAIに読み取らせて、コード生成につなげるというnrs(@nrslib)さんのセッションでした。
Miro で作成した図からコード変換を行うライブデモに加えて、「CQRS+ESの構造だと、図の意図を実装へ写し取りやすい」という整理や、成立させるための準備・工夫が語られていました。
この話を聞いて納得したのは、AI活用でよく問題になるハルシネーションは、イベントストーミングに限らず「前提が曖昧」「必要な情報がAIに渡っていない」状態で起きやすい、ということです。
逆に言えば、図のような合意済みの設計を入力として渡すのは、AIにとって強い制約になるんだなと感じました。
イベントストーミングに限らず、AIに実装を手伝ってもらうときは今回紹介されていた以下の点に気をつけると良さそうです。
- しっかりとルールを指定した指示書を作成する (出力形式、命名規則、採用するパターン、禁止事項などを明文化する)
- モデルが知らない情報は渡す (自社ドメインの用語、既存の制約、境界、例外パターン、サンプル入出力などを材料として与える)
- 最初から完璧なプロンプトを目指さず、反復しながらプロンプト(指示書)を更新する (出力を見て不足の前提や制約を AI 自身に追加させ、反復で精度を上げる)
電卓という題材がイベントソーシングの理解への入り口として良かった
あき(@aki_artisan)さんの「手軽に作れる電卓を作って イベントソーシングに親しもう」というセッションでは電卓を題材にイベントソーシングの基本概念を説明されていました。
イベントソーシングは概念としては聞いたことがあっても、実装や運用の姿を想像するのが難しい印象がありました。 その点、電卓のように状態遷移がシンプルな題材だと、
- どんなイベントが積まれるか (押したボタンを記録する)
- それをどう適用して状態を作るか (イベントログから計算を復元する)
が追いやすく、理解の助けになりました。
「小さく作って、動かしながら掴む」導入は初学者にかなり効くと思いますし、勉強会などに使う題材としても良さそうだと思いました。
現場の事例から、設計・運用の論点が具体になった
全体として、パターンの紹介だけで終わらず、運用しているサービスに段階的に適用していく中で何が起きたか、という話が多かったのが印象的でした。 たとえば「DBの現在値だけだと過去が辿れず、分析や調査がログ頼みになる」といった状態から、イベントを取り入れることでどう変化したか、という流れは自分の仕事の文脈にも重ねやすかったです。
また、かとじゅん(@j5ik2o)さんのセッションでは、コマンド側の同時更新や競合にどう向き合うか、という文脈でアクターモデルに触れられていました。
このセッションを通じて改めて認識したのは、コマンド側の難所は「同時更新が起きること」そのものより、順序が結果を変えてしまう更新が混ざることだという点です。
たとえば「同じユーザーの設定を同時に更新する」「同じ注文に対して同時に処理が走る」などは、処理順次第で最終結果がブレます。
アクターモデルは、こうした領域を集約単位で直列化して順序を固定するアプローチとして捉えられました。
その上でコマンド側の設計では、まず「順序が重要な更新はどれか」を見極め、該当する処理を集約単位で直列化できる形に寄せて考える必要があると感じました。
カンファレンス全体を通して学んだこと
複数のスピーカーの方々のお話を聞く中で、共通して語られていたポイントがいくつかありました。
状態ではなく、イベント (事実) を記録すると「歴史」が資産になる
従来のシステムでは「現在の状態」を保存しますが、イベントソーシングでは「何が起きたか」という事実を記録します。 これにより、システムの歴史を情報として残すことができます。 この考え方は、監査対応や障害の原因調査など「あの時点でどうなっていたか」を知る必要がある場面で大きな力を発揮します。 また、単に「こうなっている」だけでなく「なぜそうなったか」を追えるようになるのも大きな利点です。
良いイベント設計には、業務理解が先に必要となる
「アーキテクチャを当てはめる前に、まずドメイン(現実の業務)に向き合う」というメッセージも繰り返し出てきました。 特に、あき(@aki_artisan)さんがセッションの中で話されていた「操作を業務の言葉で表現していれば、記録すべきイベントは明確になるはず」という言葉が印象的でした。 イベントを適切に設計するには、業務そのものを深く理解する必要があります。 技術的なスキルだけでなく、ドメイン知識が重要だということを改めて実感しました。
AI時代との親和性
これは個人的に「なるほど」と思ったポイントでした。 イベントソーシングで履歴が残っていれば、AI は「最新の状態」だけでなく「過去の履歴」も読み取ることができます。 AI が「最新状態」だけでなく「過去の履歴」を読めると、なぜそうなったのか (意思決定の文脈) まで含めて理解できるようになる、という期待があります。 Git のコミット履歴を読んで修正をする AI コーディングツールが便利なのと同じで、プロダクト内の出来事の履歴が綺麗に残っていれば、AI 活用の地力が上がるのではないか…という想像が膨らみました。
まとめ
初めての技術カンファレンス参加ということもあり、若干ドキドキしながら会場に向かったのですが、想定していたよりも和気あいあいとしていて、安心して話を聞ける空気感でした。 今回改めて実感したのは、CQRS+ESが「状態を保存する」話というより、“何が起きたか”をイベントとして残し、歴史を資産にしていく考え方だということです。 監査や原因調査のように「その時点でどうだったか / なぜそうなったか」を辿りたい場面で効く、という話が具体例つきで語られていたのが印象的でした。 また、イベントをきちんと扱うには、技術以前に業務の言葉で整理することが重要で、そこが曖昧だと設計も運用も破綻しやすい、というメッセージが複数のセッションで共通していたのも学びでした。
今回得た視点が、Chatworkの目指すイベント駆動の方向性にもつながっていくはずなので、日々の開発の中で少しずつ活かしていきたいと思います。
