この記事は、SEN アドベントカレンダー2025の 25日目の記事です！
はじめに
こんにちは|こんばんは|メリークリスマス！
千株式会社CTOのytakeです。
今年も去年と変わらずドメインイベントなどを中心として、
如何にアジリティ高く、物事の分析やアプリケーションとの分離を図るか、
AIとともに加速させていくか、という観点で解説していきます。
無限の力の正体は「時間を味方にする」
世の中の殆どのすべてのプロダクトが成長すると、必ずこういう局面に遭遇します。
- 「なぜこの状態になったのか」を説明できない
- 仕様変更の影響範囲が読めず、開発の範囲も広くリリースが遅れる
- 障害調査が“推理ゲーム”になり、再発防止が弱い
- 分析やAI活用に必要なデータが揃わず、後段が常に苦しい
- 開発サイクルがうまく構築することができない
この根っこはシンプルで、多くのシステム的な思想が いまの状態（state） だけを保存しているからです。
今の状態を常に保存しているということは、
多くのシステムの根幹部分が同期的なデータになっている必要があり、
何かを変更する場合や調べる場合は、常に今の状態がつきまとい
正解がわからなくとも常に "今" の状態を正とするためにあらゆる手段を尽くさなければならなくなってしまいます。
この今の状態が、たくさんの領域において密結合してしまい、
あらゆるアクティビティの足かせになってしまうことがほとんどです。
状態は非常に便利ですが、過去に何が起きたか・事実は消えていきます。
ここで発想を反転させて、状態ではなく「起きた事実（immutable facts）」を積み上げる。
これがドメインイベントの価値です。
この積み上げは時間の経過と変わる事実を利用できるということでもあり、
いつでもその時に戻ってビューを構築できるということでもあります。
そしてこの「事実の蓄積」が、単なる設計テクニックを超えて、
AI活用のポイントの一つ GraphRAGや、データ分析・プロダクト進化を加速する“資産”になります。
イベントストーミング：ドメインイベントは「設計」ではなく「発見」する
ドメインイベントと聞くと、技術駆動的なイベントのPubSubや
Queue自体を連想してしまう方も多いかもしれません。
または単なるDispatcher のような感覚かもしれません。
このドメインイベントはエンジニアが整理のために命名して作って終わり、ではありません。
イベントストーミングを通じて業務の現実から発見することに価値があります。
ここは先日のべったけさんの記事も是非参照してください。
イベントストーミングの本質は、次の三つです。
- 出来事（Event） で認識を揃える（過去形の事実）
- その出来事を起こす意思決定 と 制約 を明確にする
- 境界（Bounded Context）と責務（Ownership）を合意する
イベントストーミングの始め方については、
ネット上にたくさんありますので是非参考にしてみてください。
重要なのは、イベントは 単なるログ ではありません。
「誰が」「何を」「どのルールで」決めた結果、業務的に意味のある事実として残るのがドメインイベントです。
エンジニアだけでなくプロダクトに関連するすべての人を巻き込んで実施しましょう。
ビジネスプロセスモデリングを通じて、多方面の業務フロー改善や把握にも役立ちます。
ドメインイベントとは何か：技術イベントやCRUD通知と切り分ける
ドメインイベントは、次の条件を満たすようにします。
- 業務に意味がある（ビジネス側が読んで理解できる）
- 過去形で表現できる（起きた こと）
- 不可逆である（原則、取り消しは「取り消しイベント」）
- 境界がある（どのコンテキストの責務か明確）
たとえば同じ「注文」でも以下は別ものとして識別します。
- ❌ OrderUpdated（CRUDの気配、意味が曖昧）
- ✅ OrderPlaced（注文が確定した、という事実）
- ✅ PaymentAuthorized（与信が通った、という事実）
- ✅ OrderCancelled（キャンセルが成立した、という事実）
よく話題になる削除フラグのような表現は、更新された削除されたではなく、
イベントストーミングなどを行うとほとんどが利用停止された、や退会になったなどの
明確な事実や意思決定になっているはずです。
冒頭の いまの状態 を保管しようと技術駆動で考えると削除フラグなどに結びついてしまいがちですが、
不可逆であり、積み上げであることを考えると 利用停止や退会などと明確に表現しておいたほうが、
認識のズレが起きにくい、ということにもつながります。
このドメインイベントをそれぞれ集計すると価値のある定量的な指標を手に入れることができるのが
理解できると思います。
このドメインイベントをかけ合わせたり、
ある時点を集計したり検索することでデータ分析や、
仮説検証や施策などのマーケティングやプロダクト開発に還元される ということになります。
これらはすべてRead Modelに含まれますので、
ソフトウェアのなになにパターンだけのものではない、ということを覚えておきましょう。
flowchart TB E[Domain Events] --> C[Commands] C --> P[Policies / Rules] P --> R["Read Models <br />（UI / Analytics / Search）"]
今の状態だけを持つようにすると、
そこからあらゆるものが歪んで複雑になるのが想像できるのではないでしょうか。
ドメインイベントとイベントソーシング
ここは混同されがちなものですが、
- ドメインイベント：モデルの表現 / 何が起きたか を表す
- イベントソーシング：永続化の戦略 / 状態をイベントから復元する
です。
ドメインイベント自体はイベントソーシングを採用しなくても有効です。
たとえば「DBは状態保存のまま、Outboxでイベントを確実に発行し、分析・検索・連携に使う」でも大きな効果が出ます。
データ基盤などのデータパイプライン（あるタイミングで実行されるデータ転送など）も
これに含まれる場合もあります。
イベントソーシングが必要になるのは、概ね次のようなケースです。
- 監査性・再現性が“要件”として強い
- 状態遷移が複雑で、再現できること自体が価値
- 後から別の読み取りモデルやプロダクト機能を増やす確度が高い
このうち 再現できること自体が価値 や
後から別の読み取りモデルやプロダクト機能を増やす確度が高い は
企業としてのバリューチェーン最大化などにも大きな価値をもたらします。
逆に単純なCRUD中心の領域に持ち込むとROIが悪化することが多いです。
重要なのは「すべてイベントソーシングにする！」ではなく、
価値が出る領域に適用することです。
そしてこの価値が出る領域があるかどうかを イベントストーミングやドメインの理解、
多くの対話や自らがドメインエキスパートになることで
確かなものであると感じる匂いを見つける能力を手に入れる必要があります。
残念ながらここはエンジニアリングだけの力ではどうにもなりません。
かっこいいソフトウェアアーキテクチャやテクニックを盛り込んだとしても、
技術駆動の狭い活動にしかなりません。
またAIを活用するという観点でもコーディングのみにしか作用しないものとなってしまいます。
ドメインイベントを積み上げる：時間軸 × イミュータブルがもたらす経営レベルの価値
ドメインイベントを資産として積むと、システムの性質が変わります。
任意時点の再現
「2025/12/01 10:03 の時点で、この注文はどういう状況だったか？」
「2024/12/01 と比べて、これまでのキャンセルの推移を知りたい」
「去年と比べて配送率がどのくらい変わり、どのセグメントが一番成長したのか知りたい」
ドメインイベントがあれば簡単に再現ができるでしょう。
これらが用意できていない場合は、Google アナリティクスの活用や
定期的にスプレッドシートに吐き出したり、
集計のための謎のデータ構造を今の状態にくっつけたりすることが多いと思います。
ドメインイベントが認識されず、正しい形で残っていないため、
かえって複雑な状況を作り出しているだけなのです。
他にも色々なシーンがあります。
- CS対応：事実にもとづく説明が可能
- 不正対策：行動系列（sequence）を検知できる
- ドリフト検知 : AIの評価やモニタリングに有用
変更耐性（未来の機能を過去から生成できる）
後から「この指標を見たい」「この画面が要る」「このAI機能を足したい」が来るのがプロダクトです。
要件が先に確定するプロダクトは絶対にありません。
ドメインイベントがあれば、過去分も含めて再構築できたり、
新しい領域に必要なビューを構築し直すこともできます。
- 新しいRead Model（集計/検索用）を作り直せる
- 仕様変更の影響範囲をイベント単位で評価しやすい
- 後から分析したい を救える
ソフトウェアアーキテクチャの変更容易性とともに、
ポイントがわかるとプロダクトは俊敏さを手にすることができます。
（多少のストレージコストはかかる）
組織スケール（境界と責務が明確になる）
ドメインイベント中心にすると、境界付けられたコンテキストが可視化・言語化されます。
結果としてチームが増えても 非同期連携しやすくなり、
出来事からの進化にも対応しやすくなります（とはいえ組織の基礎体力によります）
そしてAIへ：GraphRAG / 分析 / サービス進化を加速する「一次情報」
AI活用の詰まりどころは、モデルではなく入力の質（コンテキスト）です。
それっぽいテキストを増やしても、根拠が弱く検証ができず、意思決定に耐えません。
また入力している方のバイアスにも左右されます。
ここでドメインイベントを活用することで、AIにとって理想的な一次情報になります。
ドメインイベントは下記の要素を自体であったり、
補完することができる構造化された入力として構築できます。
- when
- who
- what
- why/how
この構造化された事実を、Graph（関係）として組むことでAIや自分たちの進化にも大きく活用できます。
GraphRAGにおけるイベントの位置づけ
GraphRAGは「検索→生成」ではなく、
関係（グラフ）と根拠（証跡）を辿って回答する設計に向きます。
イベントを起点にすると、たとえば下記が表現可能になります。
顧客（Customer）—> 注文（Order）—> 決済（Payment）—> 提供（Fulfillment）
この因果関係を辿れるのは大きな力となります。
「同様の障害の前兆パターン」「キャンセルの主要因」などを時系列で抽出でき、
回答に根拠（参照イベントID）を付与しやすい構造となります。
Neo4jなどで直接問い合わせることで、品質の評価も可能な状態になります。
ではどうグラフに落とすか
たとえば、販売系の物事であれば、
ノード：Customer / Order / Payment / Product / Document / SupportTicket / Event
エッジ：PLACED / AUTHORIZED / CAPTURED / CANCELLED / DELIVERED / REFERENCED_BY 等
エッジに 時刻 と イベントID を持たせ、ドメインイベントから再構築したり
巡れる状態にすることで説明可能性が大きく向上します。
このあたりはデータのつながりを活かす技術関係の書籍などを参照ください。
機会があればどこかで実際の実装などの解説もしようかなと思います。
ではいつイベントソーシングに踏み込むべきか
全体を急にではなく、現実的には
「まずドメインイベントを資産化し、価値が見えた領域だけイベントソーシングへ」が
良いでしょう。
正しい価値を生み出すにはソフトウェアレベルではなく、
まずはイベントストーミングからはじめ、ドメインイベントを発見し定義することです。
それからシステムとしてOutboxで確実配信にしたり、アクターモデルを活用したり、
表現できる手法を考えましょう。
技術駆動だけですすまないように気をつけましょう。
それからデータ分析などを行うデータ基盤への蓄積と、
Read Modelの再構築を経験・体験しましょう（事業で必要なデータ分析などを自分でやりましょう）。
そこからコアドメインなどの領域のみイベントソーシング、かつ監査や
状態の再現が価値につながる領域に対して実践します。
ソフトウェアで色々トライするのはこのフェーズでも良いと思います。
最後にこれからのAIなどの新しい領域に作用する
Graph化 → GraphRAG → 根拠付き回答をプロダクトなどに組み込んだりしてみる
というステップで踏み込んでいくのが良いのかもしれません。
「まずドメインイベントを資産化し、価値が見えた領域だけイベントソーシングへ」
これがROIと学習コストの両方のバランスが両立した状態になります。
さいごに
無限の力とは、未来を“過去の事実”から何度でも生成できる力です
ドメインイベントは、単なる連携のためのメッセージではありません。
プロダクトが積み上げた事実の資産であり、
無限の力の正体は、
時間軸に沿って積み上がるイミュータブルな事実を持つこと です。
その第一歩がイベントストーミングで言葉を揃え、
ドメインイベントを発見し運用可能な形で様々な物事を表現していきましょう。
おまけ
こういった実践者からのたくさんの話が聞けるカンファレンスがあるらしいです。
2026/01/10(土) 福岡工業大学 FITホールにて開催しますので、
福岡で参加できる方はぜひご来場ください。
参加費はなんと無料です！
お待ちしております！
