AIと協働し、イベントソーシングと アクターモデルで作る、後悔しない アーキテクチャ 株式会社ジェイテックジャパン 高丘 知央 2025年11月20日(木曜日) アーキテクチャConference 2025 #アーキテクチャcon_findy 

自己紹介 高丘 知央 - Tomohisa Takaoka X: @tomohisa GitHub: @tomohisa Works at: 株式会社ジェイテックジャパン、J-Tech Creations, Inc. JTS Group - 株式会社ジャパンテクニカルソフトウェア 品川 CTO: 中小企業の受託開発をモダンな開発スタイルで。イベントソ ーシング、CQRSなどのソフトウェアアーキテクチャに関するコン サル業務 Microsoft MVP for Developer Technologies from Nov 2024- OSS: Sekiban - Event Sourcing and CQRS Framework. 2 / 44 

本日のアジェンダ 1. オープニング：変化の時代における開発者の選択 2. AIとアーキテクチャ：能力の増幅器としてのAI 3. 複雑性との戦い：本質的 vs 偶有的 4. イベントソーシング：変更の意図を記録する 5. アクターモデル：責務を分離し、スケールする 6. 後悔しないアーキテクチャへの道筋 3 / 44 

1. オープニング： 変化の時代における開発者の選択 4 / 44 

1-1. 2025年、AIが当たり前の時代に しかし「AIがコードを書く」だけでは不十分 生成されたコードが積み重なり、複雑性が爆発する 動くが、将来の修正で破綻するコード 技術的負債を抱えたまま大量生産される このセッションの目標 完璧な答えはない しかし「後悔しない」という観点で、僕が大事にしているアーキテクチャのスタイル を紹介 AI、LLMの新時代においてアーキテクチャの方針を考えるきっかけになれば 5 / 44 

1-2. AIは道具であり、アーキテクチャ は未来への羅針盤 今日お伝えすること AIは能力の増幅器。しかしガードレールが必要 アーキテクチャが「羅針盤」となり、方向性を示す イベントソーシングとアクターモデルで複雑性と戦う AIが加速させる本質的な課題：認知負荷 コード量は10倍。しかし理解できる範囲は変わらない 「動くコード」と「保守できるコード」の差が拡大 アーキテクチャによる認知負荷の削減が生存戦略に 6 / 44 

2. AIとアーキテクチャ： 能力の増幅器としてのAI 7 / 44 

2-1. AIの本質的な3つの力 1. 幅広い知識の補完 私たちが知らないことを知っている 経験の差を一気に埋める 技術選択、設計パターン、理論の根拠を引き出す 2. 文章・コード・情報の整理（要約力） 複雑な議論をかみ砕いて整理する 大量のコードやログを一瞬で読み解く 全体像を作ることが得意 3. 人間の得意なことを支えて、面倒なことをやってくれる作業力 すぐに試せるプロトタイプを作る 同じ処理を何度でも繰り返す エッジケースも漏れずに網羅したテストを記述できる 8 / 44 

2-3. AIは賢い計算機、アーキテクトでは ない Kent Beckの洞察 "90% of my skills went to $0, but the other 10% went up 1000×." 「私のスキルの90%は価値ゼロになったが、残りの10% は1000倍になった」 AIは「賢い計算機」であって、 「責任を持つアーキテク ト」ではない AIは知識を教えられるが、導き・対話・信頼関係を築けない。正しいかど うかの最終判断も、プロジェクト全体の整合性の理解もできない だから人間の役割は終わらない 9 / 44 

2-4. AIは知識の代替ではなく、能力の 増幅器 自分の能力を増幅する → 自身の設計能力向上が 不可欠 アーキテクトの能力を活かして、AIにガードレールを作り、正しく動 作しやすい環境を作る AIを能力向上のために使う（和田 卓人 @t_wada さん） Outputを出すためだけでなく、自分の能力を上げるために 設計のバディとして使う 批判的レビュアーとして使う 根負けしない議論相手として使う 新しい言語を学ぶために使う AIが最大の能力が発揮できるように自分の能力を磨く必要がある 

2-5. AIとセキュリティ負債 Ory Segal (Palo Alto Networks) の警告 "An AI assistant's main value is speed, but that velocity often comes at the cost of code quality."「AI アシスタントの主な価値はスピードですが、その速度は しばしばコード品質を犠牲にします。 」 人間の監視は不可欠 "Human oversight remains essential, especially at architectural decision points and during reviews of production-bound code."「人間の監視は不可欠であ り、特にアーキテクチャ上の意思決定ポイントや本番環 境向けコードのレビュー時には重要です」 11 / 44 

2-5. アーキテクチャが「羅針盤」になる "Architecture is a compass, not a blueprint" David Robertson (2008), Uwe Friedrichsen 羅針盤と地図の違い 完全な地図は描けない - 環境は複雑で変化する 羅針盤は常に有用 - 方向を示し続ける アーキテクチャは動的 - ゴールではなく、旅の一部 AI時代におけるアーキテクトの役割 遠くから全体を観察し、次の一歩の方向を決める AIという強力な推進力に、進むべき方向を与える 環境の変化を見て、必要なら方向を修正する アーキテクトは羅針盤を手に、複雑な領域を進む旅を導く。 12 / 44 

2-6. まとめ：AI時代のアーキテクトの本質 AIと『協働』するためのポイント 1. Kent Beck: 私のスキルの90%は価値ゼロになったが、残りの10%は1000倍になった 2. Ory Segal: 人間の監視は不可欠、特にアーキテクチャ上の意思決定ポイントで 3. Uwe Friedrichsen: アーキテクチャは地図ではなく羅針盤 アーキテクトの4つの役割 1. 遠くから観察する - 複雑な環境を抽象的な視点から見る 2. 方向を決める - 次の一歩をどこへ進むべきか判断する 3. ガードレールを設ける - AIが暴走しない制約を定義する 4. 羅針盤を手渡す - チーム全体が方向を共有できるようにする AIは推進力。アーキテクチャは羅針盤。そして開発者は、その羅針盤を手に複雑な領域を進む 旅の航海士となる。 

3. 複雑性との戦い： 本質的 vs 偶有的 14 / 44 

3-1. Fred Brooksの教え 複雑性の2つの種類 本質的複雑性（Essential Complexity） ドメインに固有、除去不可能 ビジネスロジックの複雑さ 偶有的複雑性（Accidental Complexity） 技術的制約、フレームワークで削減可能 実装の都合による複雑さ 問題：偶有的複雑性がドメインコードを侵食 技術的な制約が、ビジネスロジックを複雑にしてしまう "No Silver Bullet" (1986) 「銀の弾丸はない」 - 本質的複雑性を魔法のように消し去る技術は存 在しない。しかし、偶有的複雑性は削減できる 15 / 44 

3-2. テーブル駆動でドメインコード設計は困難 ORマッパーと併用してテーブル駆動でドメイン設計を行う のは「難しすぎる」 "It can be done. I did it some... But it's very hard, maybe too hard."-Eric Evans, DDD EU 2016「 （ORマッパーと併用し てテーブル駆動でドメイン設計を行うのは）できることはでき ます。しかし非常に難しい、おそらく難しすぎるほどです。 」 単一のRDB共有がもたらす根本的な問題 ドメイン主導の境界が維持できない - AggregateやBounded Contextの境界 が曖昧になる トランザクション境界の強制 - データベーストランザクションが設計を支配 する 技術制約がドメイン設計を侵食 - アーキテクチャの選択が本質的な複雑性の 理解を妨げる 16 / 44 

3-3. Eric Evans: 大容量メモリと 新しい設計アイデア 「これが大きな制約を取り除いてくれます」 「膨大な量のメモリを利用できるようになったため、本当に複 雑な部分については、データを取り込んで、メモリ内に存在さ せる構造に変換できる。これが大きな制約を取り除いてくれま す。 」 イベントソーシングのような新しいアイデア の登場 「 『モデル全体や設計を完全に異なる方法で構造化すべきかも しれない』といった新しいアイデアが登場してきました - イベ ントソーシングのようなものです。もしかしたら今ならもっと うまくできるかもしれません。 」 Eric Evans, DDD EU 2016 17 / 44 

3-4. 「後悔しない」ための設計判断：偶有的複雑性の前払い アーキテクチャの羅針盤が示す方向：永続化手法からの分離 テーブル駆動ではなく、ドメイン駆動 - RDBスキーマに引きずられない設計 将来のスケーラビリティを考慮 - 後でリニアにスケールできる構造 認知負荷の軽減 - 開発者が理解できる範囲を保つ 本質的複雑性に集中するための「前払い」 ドメインのコア部分を純粋に設計する データと関数を分離し、永続化手法と直結させない イベントソーシング等の選択肢を後から検討できる柔軟性 偶有的複雑性（永続化の制約）を先に解決することで、本質的複雑性（ドメインロジック）に集中 できる 18 / 44 

4. イベントソーシング： 変更の意図を記録する 19 / 44 

4-1. イベントソーシングの本質 ステートソーシング: データの現在の状態だけを保 存、必要に応じて履歴も保存 イベントソーシング: すべての変更を記録 利点 何が起きたかの履歴が完全に残る 時間を遡ったデバッグが可能 監査ログとして機能 Append Data by Default イベントは貯蓄 - 後で分析する上で、ただのログより 価値が高い 20 / 44 

UnregisteredBook （未登録本） イミュータブルモデル イミュータブルモデルプロジェクト AvailableBook （貸出可能本） CheckedOutBook （貸出中） イベントソース プロジェクト 登録コマンド 書籍登録 イベント 貸出コマンド 書籍貸出 イベント 返却コマンド 書籍返却 イベント 本の 登録 モデル 変換関数 本の 貸出 モデル 変換 関数 本の 返却 モデル 変換 関数 変換関数 コマンド イベント Pure C# 4-2. Always Valid Domain Model Greg Young "Always Valid" (2009) イミュータブルモデル + 関数渡し 変更するオブジェクトではなく、イミュータブルモ デルと変換関数 拡張メソッドにより、データと関数を分ける インフラ機能を関数渡しすることにより、データの 純粋性を保つ 設計思想 「そのイミュータブルモデルのデータが存在する 限り、常に正しい状態である」ことを保証する 高速にテストができ、再利用が可能 不変条件（Invariants）を守る設計 21 / 44 

Client Command Model Query Model Command Handler Event Store Materialized View Event Projector Projection CQRS & Event Sourcing 4-3. CQRSとの組み合わせ Command Query Responsibility Segregation コマンドモデル: 変更の意図を表現 クエリモデル: 表示用に最適化 メリット 読み書きの分離により、それぞれを最適 化できる 複雑なクエリを効率的に実行可能 スケーラビリティの向上 22 / 44 

4-4. トレードオフと判断基準 得られるもの vs 失うもの/払うコスト 得られるもの 失うもの/払うコスト 完全な監査ログ 学習コスト（CRUD思考からの転換） 時間を遡ったデバッグ 初期実装コスト（イベントストア等） 柔軟なクエリモデルの再構築 結果整合性（即座に見えない場合） 採用判断 適する: 監査要件、データ損失リスク大、長期運用、学習時間あり 適さない: 小規模短期、単純CRUD、習熟度低 銀の弾丸ではない。適切な判断が必要 23 / 44 

クラスA 作成イベント クラスA 集約 佐藤さん⼊学イベント 佐藤さん集約 佐藤さんをクラスに登録 佐藤さんをクラスに登録 集約ベースのイベントソーシング 集約を超えたイベントは登録できないので、同じ意味のイベントを複数の集 約、パーティションを分けたデータ領域に登録する クラスA タグ 佐藤さんタグ 佐藤さんをクラスに登録 動的⼀貫性境界(DCB) のイベントソーシング イベントに動的にタグを紐づけて、紐づけたタグ両⽅の⼀貫性を確認してか らイベントを発⾏することができる。この例ではクラスタグと、佐藤さんタ グ両⽅の⼀貫性を確認してからイベントを保存する 佐藤さん⼊学イベント クラスA 作成イベント 4-5. Dynamic Consistency Boundary (DCB) 従来のイベントソーシングの課題 集約を超えた整合性担保が難しく、サーガ（Saga） で複数集約を調整 同じイベントを複数集約に置くモデリングが難しい DCBのアプローチ 判断に関連する最小限のデータだけの整合性境界を 動的に定義 イベントを事実としてモデリングでき、サーガ、プ ロセスマネージャの負担を低減 パフォーマンスは集約版よりも若干落ちるが、モデ リングをシンプルにでき偶有的複雑性を低減できる 参照: https://dcb.events Axon, SekibanなどがDCB対応 フレームワークをリリース 

4-6. イベントソーシングとAIとの親和性 「後悔しない」選択：データを消さない設計 イベント = 貯蓄: 削除せず保存 → 将来の分析・AIへの高品質な入力 AIの要約力: イベント履歴から意図を抽出、パターンを発見 安全性: データを消さない設計 AIコーディング向き: データ削除のバグも追跡・復旧可能 GIGO原則の適用: Garbage in, Garbage out（ゴミを入れればゴミが出 る）- 質の低い入力データからは質の低い出力しか得られない。イベン トソーシングで意味のあるデータを保存することで、AIに高品質な入 力を提供できる 完全な履歴 = 高品質な入力データ → AIによる高品質な分析・学習 「保存しておけば良かった」という後悔を避ける ストレージコストは低下 << データロストのヒューマンコスト 経済的には明らかにデータ保存の方が低コスト 

5. アクターモデル： 責務を分離し、スケールする 26 / 44 

Actor 1 State Execution Queue DB Transaction Actor 2 State Execution Queue DB Transaction User 1 User 3 User 2 Message Message 5-1. アクターモデルの基本 アクターとは アクター: 独立した処理単位 メッセージパッシング: 非同期通信 状態のカプセル化: 外部から直接アクセスできない 特徴 並行処理の簡素化（ロック不要） 、インメモリのデ ータでデータ検証を行うため、DDDのAlways Valid Domain Modelと相性が良い。 高いスケーラビリティ、イベントソーシングの集 約、DCBのタグの管理を明示的に行うことができる 明確な責務分離 27 / 44 

5-2. DDDの集約とアクターモデルの融合 同じ概念 集約ルート（Aggregate Root）: Eric Evansの言ったように、メモリにオブジェクトを展開して、インメモ リのオブジェクトで集約を管理するのが効率的 アクター: アクターモデルは、集約ごとにオブジェクト展開されて、インメモリのオブジェクトに対してメ ソッドを実行することができる 同じ: メモリに置くことにより、DBに確認せずに実行判断をすることができる 制約によってスケーラビリティを確保する 広範なトランザクションを作れないからこそスケーラビリティを犠牲にしない データのグループごとにデータの整合性をとる 分散アクターモデルを使うと、オブジェクトが複数のサーバーに分散していても使い手はアドレスだけ指定 して、どのサーバーに使うか意識しなくて良い 集約（Aggregate）= アクター = トランザクション境界、DCBではタグ毎にアクター管理を行う 28 / 44 

5-3. アクターモデルの実践方法 DDIA本 『データ指向アプリケーションデザイン』より 「アクターモデルではメッセージが単一プロセス内でさえ失われうることを前提として いるため、RPC よりも場所の透過性がうまく働きます。...アクターモデルを用いるとロ ーカルとリモートのコミュニケーションの基本的なミスマッチは少なくなります」 分散システムの現実を受け入れた設計 → スケーラビリティと保守性の両立 複数の選択肢がある C#: Orleans、 Dapr、Akka.NET Typescript: Dapr、Claudflare Durable Objects (注目！) Go/Kotlin/etc: Proto Actor Elixir/Erlang: OTP Scala: Akka/Pekko 29 / 44 

5-4. トレードオフと判断基準 得られるもの vs 失うもの/払うコスト 得られるもの 失うもの/払うコスト 高いスケーラビリティ（水平分散が容 易） トランザクション制約: 複数集約にまたがる即座の整合性は 困難 明確な責務分離 学習曲線: 非同期思考、メッセージパッシングへの慣れ 並行処理の簡素化（ロック不要） デバッグの複雑性: 分散システム特有の課題 インフラ要件: Orleans、Dapr等のランタイム 採用判断 適する: 将来の大規模化、複雑なドメイン、可用性・スケーラビリティ優先 適さない: 強い即時整合性必須、小規模単純CRUD、学習時間なし 全てのプロジェクトに適するわけではない 30 / 44 

5-5. 「後悔しない」アーキテクチャ：最初から スケールアウト設計を行なっておく システムが大きくなる前からスケールアウト設計を 将来の後悔を避ける: 小規模時からスケールアウト可能な設計 リアーキテクチャのコスト回避: 後から作り直すより、最初から正しい方向へ 段階的な成長に対応: 小さく始めて、必要に応じてスケール 現実的なコストで始められる Sekiban: インフラの設定により、月額5千円未満からアクターモデルでシステムを運 用可能! Claudeflare Durable Objectは無料使用枠もある程度大きい 小規模スタート → 成長に合わせてスケールアウト クラウドネイティブな設計により、柔軟なコスト管理 「あの時スケールアウト設計をしておけば…」という後悔をしない 

6. 後悔しない アーキテクチャへの道筋 32 / 44 

6-1. 後悔しないための4つの設計原則 1. インメモリでAlways Valid Domain Model 永続化から分離: RDBスキーマに引きずられない純粋なドメインモデル 常に正しい状態: イミュータブルモデル + 関数渡しで不変条件を保証 後悔しないポイント: データベース変更でドメインロジックを書き直す必要がない 2. Append Data by Default - データを消さない イベントは貯蓄: 削除せず保存 → 将来の分析・監査に活用 時間を遡れる: デバッグ、問題追跡が可能 後悔しないポイント: 「あのデータ保存しておけば…」という後悔をしない 33 / 44 

6-2. 後悔しないための4つの設計原則（続き） 3. スケールアウト前提の設計 集約 = アクター: 最初から水平分散可能な境界設計 段階的成長: 小さく始めて、必要に応じてスケール 後悔しないポイント: システムが大きくなってからリアーキテクチャする必要がない 4. CQRSで読み書きを分離 それぞれを最適化: コマンドモデルとクエリモデルの独立進化 柔軟な対応: 要件変更に強い構造 後悔しないポイント: クエリ要件変更でドメインロジックに影響しない 34 / 44 

6-3. 結合のバランス：モジュラーシステムへの道 設計の本質は結合の最小化ではない 「システムのコンポーネント間の相互作用を設計する際のゴールは、結合の強度を最小化することではな い。ゴールは、実装や進化、メンテナンスが容易なモジュラーシステムを設計することだ。これは、結合 の 3 つの次元すべてを考慮することでのみ達成できる」 Vlad Khononov 『ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 』 10.1 結合の次元を組み合わせる 結合の3つの次元 1. 統合強度: コンポーネント間の共有知識の量 2. 距離: コンポーネントのライフサイクルの近さ 3. 変動性: 変更の頻度と影響範囲 「後悔しない」アーキテクチャとは: 最新技術の導入ではなく、適切な粒度でバランスを取 ること。 イベントソーシング、アクターモデルは、このバランスを実現する具体的な手法 

6-4. AIと協働しAIを能力の増幅器として活用 アーキテクチャがAIのガードレールになる 1. 明確な境界: 集約・アクターが責務を明確化 → AIへの指示が 明確 2. 常に正しい状態: Always Valid → AIが生成したコードも検証 しやすい 3. 完全な履歴: イベントソーシング → AIが過去の判断から学習 開発者の役割は羅針盤を持つ航海士 アーキテクチャの方針を決定（AIはそれに従う） ドメインの本質を理解（AIはそれを表現する） 制約とガードレールを定義（AIはその中で動く） AIは推進力。アーキテクトは方向を示す羅針盤。 

6-5. 試して、小さく始めて、育てていく Phase 1: 小規模スタート インメモリのドメインモデルを設計 基本的なイベントストア（シンプルなもので良い） 単一インスタンスでも動作 Phase 2: 成長に合わせて アクターモデルのフレームワーク導入（Orleans、Dapr等） クエリモデルの最適化 水平スケールアウト Sekiban等のフレームワーク活用で、最初から「後悔しない」設計を低 コストで実現 37 / 44 

6-6. トレードオフの正直な評価 前払いするコスト 学習投資: イベントソーシング、アクターモデルの理解 初期設計: ドメインモデルの純粋性を保つ設計思考 フレームワーク選定: 適切なツールの選択 避けられる後悔 「あのデータ保存しておけば…」 「スケールアウト設計にしておけば…」 「永続化から分離しておけば…」 「リアーキテクチャに数ヶ月かかる…」 判断基準 将来のリアーキテクチャコスト >> 最初の設計投資 

7. クロージング：未来を切り拓く 39 / 44 

7-1. 本日のキーメッセージ 「後悔しない」アーキテクチャの4つの柱 1. インメモリでAlways Valid: 永続化から分離された純粋なドメインモデル 2. データを消さない: イベントは貯蓄。完全な履歴が未来の資産 3. 最初からスケールアウト設計: 小さく始めて、大きく育てる 4. 読み書きを分離: それぞれの進化を独立させる AI時代における開発者の役割 AIは能力の増幅器: 真価は「要約力」にある アーキテクチャは羅針盤: 方向性を示し、AIのガードレールとなる 開発者は航海士: 羅針盤を手に、複雑な領域を進む 40 / 44 

7-2. それでも設計、実装は簡単ではない これらは「銀の弾丸」ではない 学習コスト: イベントソーシング、アクターモデルの理解が必要 初期投資: ドメインモデル設計の時間 チーム育成: 新しいパターンの習得 しかし、後悔しないための投資 「あの時こうしておけば…」という後悔を避ける 将来のリアーキテクチャコスト >> 最初の設計投資 よくできたフレームワーク使用することにより、 『設計の高速道路』に乗ることができる すべてのプロジェクトに適するわけではないが、選択肢を知っておくことが重要 詳しく知らなくてもコンセプトを理解していることで、AIのアシストで採用していくことができる時代 41 / 44 

7-3. まとめ 「後悔しない」とは 「完璧」ではなく「選択に納得できる」こと データを消さない → 保存しておけば良かったという後悔をしない 永続化から分離 → RDB変更でドメインロジックを書き直す後悔をしない スケールアウト設計 → システムが大きくなってから作り直す後悔をしない 変化を恐れず、未来を切り拓く AIという増幅器を通じて、持続可能な品質向上へ アーキテクチャという羅針盤を手に、複雑な領域を進む 今日の話が、皆さんの羅針盤の一部になれば 後悔しないアーキテクチャで、未来への道を切り拓こう 42 / 44 

参考文献・リソース 書籍・論文・ブログ・登壇 David Robertson "Architecture is a compass, not a blueprint" (2008) - Enterprise Architecture Conference in London Uwe Friedrichsen - Blog post on Architecture as Compass (2011) Greg Young "Always Valid" (2009) Vlad Khononov "Balancing Coupling in Software Design" Fred Brooks "No Silver Bullet" Martin Kleppmann "Designing Data-Intensive Applications" Eric Deutsch & John F. Proud "Master Planning and Scheduling" (GIGO) Ory Segal "AI Security Debt" (2025) - Palo Alto Networks Blog Takuto Wada "AI時代のソフトウェア開発を考える（2025/07版）" Speaker Deck Dynamic Consistency Boundary: https://dcb.events 43 / 44 

Thank you 株式会社ジェイテックジャパン https://www.jtechs.com/japan/ イベントソーシング・CQRSフレームワーク Sekiban https://github.com/j-tech-japan/sekiban Zenn - ジェイテックジャパンブログ https://zenn.dev/p/jtechjapan_pub