【20260219 AI×DevOpsStudy #6】Claude Code によるリファクタリング（2/2）：実装計画の策定方法

■AI×DevOps Study #6 の概要
2026年2月19日に開催した「AI×DevOps Study」第6回の勉強会資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「Claude Code によるリファクタリング（2/2）：実装計画の策定方法」

レガシーシステムは、様々な人により改修が繰り返されており、コードの見通しが悪くなり、技術負債が蓄積されていることが多いのが実態です。これを調査して、改善点を洗い出すにも、人手がかかるため、分析が行われずリスクを抱えたシステムが多数運用されています。

このような企業内に散在するEUCシステムやレガシーなシステムの調査をAIエージェントを用いて行うことで、人の主観によらない客観的な分析を実現することができます。

本セッションでは、株式会社Scalarでどのように現行システム分析を行い課題の洗い出しを行い、システムの課題を解決していっているのかを2回に渡ってお話しします。

2回目は、現行システムの分析と評価の結果をもとに Claude Code を使ってドメイン駆動開発の手法で再設計し、マイクロサービスアーキテクチャを適用した設計を行う方法をお話しします。

● DDD 再設計の実践. 　境界コンテキストの特定とコンテキストマップ作成.

戦術的設計（集約、エンティティ、値オブジェクト、リポジトリ）.

● マイクロサービスアーキテクチャ設計.

サービス分割戦略とゼロトラストセキュリティ.

● ScalarDB によるデータベース再設計

マルチストレージ対応スキーマ設計.

トランザクションパターンの最適化.

● デモ：設計スキルの実行.

■登壇者情報（敬称略）
深津航
株式会社Scalar Founder & CEO。日本オラクル株式会社、決済系のスタートアップを経て、株式会社Scalarを創業。

■勉強会動画
本勉強会の動画は録画の音声品質の関係によりありません。

Transcript

1. Claude Code によるリファクタリング#2 実装計画の策定⽅法 2026/02/19 株式会社Scalar CEO 深津 航
2. ⾃⼰紹介 名前：深津航 所属：株式会社Scalar CEO, Co-Founder 主な関⼼事項 • ⽇本のIT強化 • アーキテクチャ/設計 • DevSecOps, FinOps • AIが与える各種業界へのインパクト ◦ 個⼈的には、Moltbookが⾯⽩い LinkedIn: https://www.linkedin.com/in/wataru-fukatsu-1692655/ 2
 ▪ IPAの専⾨委員としての活動 DADCの専⾨委員としても活動しています。 ▪ 株式会社 Scalar としての活動 株式会社Scalarは、分散トランザクションマネー ジャーのScalarDBと改ざん検知ソフトウェアの ScalarDLを展開中。マイクロサービス化におけるシ ステムの課題やAIなどのデータ基盤の信頼性を担保 するソリューションを展開しています。 ソフトウェア開発、システム開発、マーケティン グ、営業、経営など様々な役割で活動中。
3. 本⽇のお話 本⽇は以下のお話をします。 3
 ブラックボックスを可視化する 「機能」ではなく 「ドメイン」で分離する データ整合性を「中央集 権」ではなく「トランザク ション設計」で担保する 内製化し業務とシステムを ⼀致させる Claude Code による リファクタリング #1 現⾏システムの分析 と評価の⽅法ç Claude Code による リファクタリング #2 実装計画の策定⽅法
4. 前回の振り返り 4 Claude Code によるリファクタリング#1 現行システムの分析と評価の方法
5. 前回：DDDに対する技術負債とギャップを評価 5
 調査 Phase 0-1 評価 Phase 2 再設計 Phase 3-6 コード⽣成 Phase 7-8 • コード構造分析 • セキュリティ分析 • データモデル分析 • MMI品質スコア • DDD適合度評価 • 統合レポート • DDD再設計 • マイクロサービス化 • ScalarDB/API/k8sインフラ • テスト仕様書⽣成 • デザインパターン適⽤ • コード⽣成 Claude Code によるリファクタリング#1 現行システムの分析と評価の方法 Claude Code によるリファクタリング#2 実装計画の策定方法
6. DDDとは何か？ 6
 ドメイン駆動設計（DDD）の本質は、 「複雑なビジネスを正しく理解し、それをソフトウェアに正確に反映すること」 ドメインエキスパート ユビキタス⾔語 ドメインモデル リポジトリ ドメインサービス ドメインオブジェクト 制約 エンティティ 集約 値オブジェクト コーディング モデリング モデルの妥当性 実装で発⾒した知識 ソフトウェアとして 反映しやすいモデルか ビジネス → 戦略的設計 コード → 戦術的設計
7. DDD - 戦略的設計の評価 7
 境界コンテキストの分析 ユビキタス⾔語の分析 コンテキストマップの分析 評価項目: ├── コンテキスト境界の明確さ │ ├── モジュール/パッケージによる分離 │ ├── 名前空間による分離 │ └── 責務の分離度 ├── コンテキスト間の関係 │ ├── 依存の方向性 │ ├── 共有カーネルの有無 │ └── 腐敗防止層の有無 └── コンテキストの独立性 ├── デプロイ独立性 ├── データ独立性 └── チーム独立性 評価項目: ├── 用語の一貫性 │ ├── コード内での命名 │ ├── コメント/ドキュメント │ └── テストケース名 ├── ドメインエキスパートとの整合性 │ ├── ビジネス用語の使用 │ ├── 技術用語の混入度 │ └── 略語の使用状況 └── コンテキスト間での用語の分離 ├── 同一用語の異なる意味 ├── ポリセミ（多義語）の検出 └── コンテキスト固有の語彙 関係パターンの検出 : ├── Partnership（協力関係） ├── Shared Kernel（共有カーネル） ├── Customer-Supplier（顧客-供給者） ├── Conformist（順応者） ├── Anti-Corruption Layer（腐敗防止層） ├── Open Host Service（公開ホストサービス） ├── Published Language（公表された言語） └── Separate Ways（別々の道） ビジネス整合性、組織適合性、技術的健全性の3つの観点で評価を⾏い、 事業構造とシステム構造の整合性が設計に反映されているかを評価します。
8. DDD - 戦術的設計の評価 8
 エンティティの分析 値オブジェクトの分析 集約の分析 評価項目: ├── 識別子の設計 │ ├── ID生成戦略 │ ├── 自然キー vs サロゲートキー │ └── ID型の適切さ ├── ライフサイクル管理 │ ├── 生成パターン │ ├── 状態遷移 │ └── 不変条件 └── 振る舞いの充実度 ├── ビジネスロジックの配置 ├── 貧血ドメインモデルの検出 └── Tell, Don't Askの適用 評価項目: ├── 不変性の確保 │ ├── イミュータブル設計 │ ├── 副作用のない操作 │ └── コンストラクタでの検証 ├── 等価性の実装 │ ├── equals/hashCode │ ├── 構造的同一性 │ └── 型安全性 └── 値オブジェクト候補の検出 ├── プリミティブ執着の検出 ├── 複合値の検出 └── 型エイリアスの検出 評価項目: ├── 集約ルートの特定 │ ├── ルートの責務 │ ├── 不変条件の保護 │ └── トランザクション境界 ├── 集約サイズの適切さ │ ├── 小さすぎる集約 │ ├── 大きすぎる集約 │ └── 参照vs値の判断 └── 集約間の参照 ├── IDによる参照 ├── オブジェクト参照の回避 └── 整合性境界 コードを調査し、実装レベルの設計パターンを分析し、 モデルがビジネスを正しく表現できているか？を評価します。 リポジトリの分析 評価項目: ├── インターフェース設計 │ ├── コレクション指向 vs 永続化指向 │ ├── クエリメソッドの設計 │ └── 仕様パターンの適用 ├── 実装の品質 │ ├── インフラ層への分離 │ ├── テスト容易性 │ └── トランザクション管理 └── 集約単位の永続化 ├── 集約全体の保存 ├── 遅延ロード戦略 └── キャッシュ戦略 ドメインサービスの分析 評価項目: ├── サービスの責務 │ ├── ステートレス性 │ ├── ドメインロジックの配置 │ └── 複数集約の協調 ├── サービスの粒度 │ ├── 単一責任 │ ├── インターフェースの明確さ │ └── 依存の最小化 └── アプリケーションサービスとの区別 ├── ユースケース層との分離 ├── トランザクション管理 └── セキュリティ/認可 戦術的パターン : ├── Factory（ファクトリ） ├── Repository（リポジトリ） ├── Domain Event（ドメインイベント） ├── Domain Service（ドメインサービス） ├── Application Service（アプリケーションサービス） ├── Specification（仕様） └── Policy（ポリシー） アーキテクチャパターン : ├── Layered Architecture（レイヤードアーキテクチャ） ├── Hexagonal Architecture（ヘキサゴナルアーキテクチャ） ├── Clean Architecture（クリーンアーキテクチャ） ├── CQRS └── Event Sourcing
9. ドメイン分類フレームワーク 9
 タイプ 特徴 例 Pipeline 順序的なデータ/処理フロー 注文処理、ワークフロー Blackboard 共有データへの協調的アクセス 在庫管理、予約システム Dialogue 双方向のインタラクション チャット、通知システム カテゴリ 責務 特徴 Process ビジネスプロセスの実行 ステートフル、サガ管理 Master マスタデータの管理 CRUD中心、データ整合性 Integration 外部システム連携 アダプタ、変換処理 Supporting 横断的機能の提供 認証、ログ、通知 ビジネス構造軸での分類（Domain Type） マイクロサービス境界軸（Service Category）
10. アーキテクチャの設計 10 ドメインモデル（戦略的設計）⇒ドメインオブジェクト（戦術的設計）
11. 分析結果をもとにドメインを再構築する 11
 ドメインを再構築するために、情報を抽出し、分類し、整理します。 境界コンテキスト⼀覧 （Bounded Context List） サービスの境界 （Service Boundary） ユビキタス⾔語 （Ubiquitous Language） 意味 どこまでを1つのサービス（マイクロサービ ス／モジュール）とするかの境界。 「どこまでが同じ言語で話せる世界か」の リスト。 • 同じ単語でもコンテキストが違えば意味 が違う • 各BCごとにモデルが独立する 意味 開発者と業務担当が共有する共通語彙。 「どこまでを1つのデプロイ単位・責任単位 にするか」 • 1 Bounded Context = 1 Service が理想 • ただし必ずしも一致しない 意味 ユビキタス言語の辞書。 「このシステムで使う公式な言葉」 • コードにもそのまま反映される言葉 戦略設計レベル（全体構造を決める） 言語の境界 デプロイと責任の境界
12. 分析結果をもとにドメイン内を再構築する 12
 ドメイン内を再構築するために、情報を抽出し、分類し、整理します。 集約⼀覧 （Aggregate List） 集約ルート （Aggregate Root） エンティティ （Entity） 意味 各境界コンテキスト内で定義さ れる集約の一覧。 「不変条件を守る最小単位のリ スト」 意味 集約の代表エンティティ。 特徴 • 外部から直接参照できる唯一 のオブジェクト • トランザクション境界の中心 意味 同一性（ID）で区別されるオブ ジェクト。 特徴 • 状態が変わる • ライフサイクルがある 戦術設計レベル（ドメイン内部構造） 値オブジェクト （Value Object） 意味 値そのものに意味があるオブ ジェクト。 特徴 • IDを持たない • 不変（immutable） • 同値性で比較 不変条件の境界
13. 分析結果をもとに外部接続を再構築する 13
 外部接続を再構築するために、情報を抽出し、分類し、整理します。 APIエンドポイント 操作⼀覧 （Use Case List） データスキーマ （Logical Schema） 意味 外部と通信するための入口。 役割 • Application層の公開イン ターフェース 意味 ユーザーが実行できる業務操作 の一覧。 特徴 • APIよりも業務寄りの概念。 意味 データ構造の概念モデル。 特徴 • 集約中心 • ERよりもドメイン寄り • 物理DBに依存しない 技術設計レベル（外部との接続） テーブル定義 （Physical Schema） 意味 実際のデータベース構造。 注意点 • 集約境界と一致しているのが 理想 • 他集約はID参照のみ 外部との境界 永続化の実装
14. ドメイン全体の関係性 14
 ユビキタス⾔語 境界 コンテキスト 集約 エンティティ 値オブジェクト API 操作 = ユースケース スキーマ テーブル
15. ドメイン同⼠の繋がりを考える 15
 Context Map = Bounded Context 間の関係の“意味”と“力関係”を定義するもの 基本的な戦略 Bounded Context 内は、強整合、Bounded Context 間は、結果整合 ただし、Bounded Context 間でも強整合を使う場合がある AI駆動開発では、ドメインの”意図”が重要
16. Partnership 16
 注⽂ Order 在庫 Inventory 2つの境界コンテキストが対等な⽴場で共同設計する関係 特徴 • 両者でモデルを調整する • 同時リリースが発生しや すい • 組織的な連携が前提 使う場面 • 同一チーム • ドメインが密接で分離が 難しい トランザクション • 強整合が求められる • 設計が悪いと事実上1つ の Bounded Contextに なる リスク • ScalarDBを使わない場 合、データベースを分離 すると要件を満たせない
17. Customer / Supplier 17
 請求 Billing サブ スクリプション Subscription 上流（Supplier）がモデルを提供し、下流（Customer）が利⽤する 特徴 • 上流が仕様主導 • 下流は要求を出せる • 明確な責任分離 使う場面 • 社内の明確な責任分担 • プラットフォーム型構造 トランザクション • 同期API • 結果整合に分離できるこ ともある リスク • 設計が悪いと、上流変更 の影響を下流が受ける 上流 下流 上流は、 専⾨組織が管理 下流は、 依存するが要望は出せる
18. Conformist 18
 外部の決済 Stripe 決済 Payment 下流が上流モデルに完全に従う 特徴 • 翻訳しない • モデル汚染の危険あり • 実装は簡単 使う場面 • 外部SaaSの利用時 • 単純な参照用途 トランザクション • 上流依存 • 強整合が求められる リスク • 自分のドメインが影響を 受ける SaaS 外部のI/Fは ⾃⾝で決められない 外部の影響を 直接受ける
19. Anti-Corruption Layer（ACL） 19
 ERP: 注⽂書 SalesDoc 注⽂ Order 上流モデルを⾃分のドメインへ翻訳する盾 特徴 • ドメインを保護 • 長期的に安定 • 実装コストが高め 使う場面 • 外部システム連携 • モデル間の意味が違う トランザクション • 結果整合性 • Sagaで実装可能 リスク • 実装が複雑で肥大化する 翻訳 外部のI/Fは ⾃⾝で決められない 内部のドメインを 保護する
20. Shared Kernel 20
 顧客 Customer ロイヤルティ Loyalty ⼀部のモデルを共有する 特徴 • 共同管理 • 小さく保つ必要がある • 境界が曖昧になりがち 使う場面 • 共通の概念のみ トランザクション • 強整合性 リスク • ScalarDBを使わない場 合、肥大化による結合地 獄が発生する IDを共有 共通モジュール 同じIDを共有 同じID⽣成ルール
21. Published Language 21
 発送 Shipping 注⽂ Order 公開契約（API/イベントスキーマ）で連携 特徴 • 明確な契約 • 非同期と相性良い • 進化しやすい 使う場面 • イベント駆動 トランザクション • 結果整合性が基本 • Saga設計と相性が良い リスク • ScalarDBを使わない場 合、肥大化による結合地 獄が発生する イベント を送信 注⽂ドメインを参照して 駆動する Order内は、強整合性 参照
22. Open Host Service 22
 顧客 Customers 注⽂ Order 上流が安定したAPIを公開する 特徴 • REST, gRPC • 拡張設計が重要 使う場面 • 公開APIの提供 • 社内基盤サービス トランザクション • 同期呼び出し中心 • 呼び出しドメイン内は、 強整合性、外部は結果整 合性 リスク • トランザクションの抜け 漏れがでる可能性がある GET処理 上流が安定した APIを公開 Order内は、強整合性
23. Separate Ways 23
 売上レポート Sales Report 売上 Sales 統合しない 特徴 • 完全独立 • 重複を許容 使う場面 • 相互に依存しない場合 • 無理に統合すると複雑化 する場合 トランザクション • 不要 リスク • 障害時に不整合が起きる 可能性がある イベント 処理 同じ売上という概念 ドメイン同⼠が 強く依存していない
24. 実装に向けた準備 24 “意図（Intent）”を設計に組み込むインテント・エンジニアリング
25. インテントコーディングのゴール 「ユースケース＝Intent」を中⼼に、ドメインモデルが “何がしたいか” で読める 具体的に起きる変化 • if/else や⼿続きが散らばらず、意思決定がドメインに集約 • 仕様変更が “Intent の追加/変更” として表現される 25
 レイヤ責務 “Intent” の置き場所 Controller / Handler：入出力変換（I/O）、認証・認可の受け口 UseCase（= Intent）：アプリケーションの意図（何を達成するか） Domain：業務ルール・不変条件（できる /できないの判断を返す） Infra：DB/外部API/メッセージング Intent は UseCase 名として表す （例：ConfirmPayment, CancelOrder, RegisterCustomer） ドメインは 意図を実現するルールの本体 （例：order.confirmPayment()） インテントに注⽬してAIに実装させると同⼀コンテキストで実装を進めることが出来る
26. 設計の基本形 26
 レイヤ / 要素 役割 主な⼊⼒ 主な出⼒ やること やらないこと 典型成果物 Controller / Handler （受け⼝） 外部I/OをIntentに変 換する⼊⼝ HTTP/Msg、認証情報、リ クエストDTO レスポンスDTO、HTTPス テータス、相関ID ⼊出⼒変換、バリデーション（形 式/型）、認証、相関ID付与、レー ト制御 業務ルール判断、永続化、トラン ザクション整合の本体 OpenAPI、DTO、ルーティング、 ⼊⼒スキーマ UseCase （= Intent） 「何を達成するか」を 表すアプリ層の単位 コマンド （ConfirmPaymentCmd 等）、actor、context 結果（Result）、 DomainError、イベント トランザクション境界、リポジト リI/O、ドメイン呼び出しのオーケ ストレーション、エラー変換の起 点 ドメインルール実装、SQL/外部 API直書き、UI都合のロジック UseCaseクラス、コマンド/結果 型、ユースケーステスト Domain （Entity / ValueObject / DomainService） 業務ルール‧不変条件 を保持し判断する中核 ドメイン状態、値、ポリ シー 状態変化、 DomainEvent、 DomainError 不変条件チェック、状態遷移、計 算、意味のある命名（動詞/名詞） I/O、フレームワーク依存、DTO依 存、インフラ呼び出し エンティティ/VO、ドメインイベン ト、ドメインテスト Policy / Specification （判断の部品） 「〜できるか」を名前 にする再利⽤可能な判 断 order/actor等の状態 boolean or DomainError キャンセル可否/返⾦可否などの条 件を集約、ルールの組合せ ⼿続きの実⾏（在庫更新等）、I/O CanCancelOrderSpec、 RefundablePolicy Repository （永続化境界） ドメインを保存/復元 する境界 ドメインオブジェクト、ID ドメインオブジェクト load/save、楽観ロック、整合性 キー、冪等性キーの記録 業務判断、複雑なオーケストレー ション Repository interface、実装、永続 化テスト Infrastructure （DB/外部API/Queue） 技術詳細を隠して実⾏ する層 クエリ、外部API要求、イ ベント データ、応答、発⾏結果 SQL/SDK、再試⾏、タイムアウ ト、回復戦略、観測性 ドメインの意味付け、Intent命名 DAO、クライアント、メッセージ ング設定 Cross-cutting （Observability / Security） Intentの流れを追える ‧守れる状態にする correlation_id、actor、メ タデータ ログ/トレース/監査、認可 結果 相関ID、監査ログ、認可（ABAC 等）、メトリクス ドメインルールの代替 ログ規約、監査スキーマ、ポリ シー定義
27. 典型的なパターン コマンド（Intent:意図）→ ドメイン操作 • UseCaseは「1つの意図」を表すコマンド • ドメインメソッド名も動詞で意図を表す 例）⽀払いの確認のコード ※擬似コード 27
 UseCase: ConfirmPayment(orderId, paymentId) order = repo.load(orderId) payment = paymentRepo.load(paymentId) order.confirmPayment(payment) repo.save(order)
28. 典型的なパターン 28
 ポリシー（判断）を名前で表す if⽂を増やす代わりに、判断を Policy / Specification に押し上げる。 • RefundablePolicy • CanCancelOrderSpec 例）“キャンセル可能性” を概念として⽰すコード ※擬似コード if (canCancelSpec.isSatisfiedBy(order, actor)) { ... }
29. 典型的なパターン 不変条件（Invariant）を例外/結果として返す • 失敗は DomainError（理由付き）にする • UseCaseは DomainError を HTTP や UI のエラーに変換する 29

30. “Intent”とCommand/Event/Queryの関係 “Intent”を意識して設計すると、Command/Event/Queryの関係が明確になりま す。以下は、時系列に沿って処理される流れです。 30
 Intent 要求 注⽂をキャンセルしたい Command 実⾏要求 CancelOrderCommand （成⽴するかを厳密に判定） Event 成⽴した事実 OrderCancelledEvent （起きた事実） Query 結果を知る要求 画⾯⽤：注⽂詳細 BI⽤：キャンセル率 AI⽤：時系列履歴
31. ドメインの“意図（Intent）”の構造 ”意図”を構造化すると以下のようになります。 31
 要素 役割 料理ロボットでの例 目標層 目的 「美味しいカレーを作る」というオーダーを理解する。 コンテキスト層 文脈 「ユーザーは辛いものが苦手」「冷蔵庫には豚肉がある」と把握する。 制約層 ルール 「予算は1000円以内」「火傷しないように安全装置を作動」を守る。 ソフトウェアスタック 身体 包丁、鍋、レシピデータベース、ロボットアーム自体。 フィードバックループ 改善 味見をして「塩が足りない」と修正する、またはユーザーの「美味しい」を記録する。 AI駆動開発プロジェクトでは、このように”意図”を要素に分解し、これらの要 素をあらかじめ、AIに与えておきます。
32. Bounded Context から実装へ 32
 ユーザー⼊⼒ 「〜を実装したい」 ⽬標層 コンテキスト層 制約層 ソフトウェアスタック フィードバック‧ループ 表層意図          → 深層意図へ変換 タスク分解         → サブコール⽣成 成功条件の定義 Memory MCP検索      → 関連する過去の知識の収集 ドキュメント参照      → 処理に関わる情報の収集 ユーザープロファイルの適⽤ → ユーザー固有の情報を取得 セキュリティチェック 出⼒フォーマットの強制 ユーザープロファイルの適⽤ AIによるタスクの実⾏    → コード⽣成、ファイル操作、API呼び出しなど MCPサーバーの呼び出し 外部ツールの連携 セルフ‧リフレクション  → レビューの実施 システムによるレビュー  → lintやテストの実施 ⼈によるレビュー     → 開発者への確認 学習記録（Memory MCP）
33. APIを “Intent” で設計する理由 APIが“意図”で区切られ、境界がズレにくい（変更に強い）状態を担保できると、AIがコー ド修正する際に、暴⾛することを抑制できます。 このため、「APIの安定性（契約）」を優先し、 実装の都合を劣後させる必要がありま す。 RESTでも「リソース」より「意図」を前⾯に出す場⾯がある CRUDはリソース中⼼でもOK。ただし 状態遷移‧業務操作は Intent が本体になる。 • POST /orders/{id}/confirm-payment • POST /orders/{id}/cancel • POST /customers/{id}/activate ※業務操作＝意図なのでむしろ明確 33

34. 分散環境での “Intent” を壊さない実装ポイント 34
 冪等性（Idempotency） • Intent APIは二重実行されやす い（リトライ、タイムアウト）。 • Idempotency-Key を受けて、 同一Intentの再実行を防ぐ 意図を一度だけ成立させるを保証 する 相関ID（Correlation ID） Intentの流れを追えるようにする（観 測性）。 • 受け口で correlation_id を発番/ 継承 • ログ/メトリクス/トレースに一貫し て付与 失敗のモデリング （HTTPの前に業務エラー） • 409 Conflict（状態が合わない） • 422 Unprocessable Entity（業 務ルールで不可） • 403 Forbidden（権限） などに DomainError をマッピング 分散トランザクションの 実装 分散トランザクションは「意図」を中 心に編むと破綻しにくい。 • 内部境界は ScalarDB を用いる • 外部境界は、Saga/TCCを用い る ⼀連の業務フローの中で、”Intent”が壊れないようにすることを意識して設計す ることで、何をどこまで担保するかが明確になります。
35. 出⼒レポートの例 デモアプリケーションの分析 35
36. Architecture Redesign Agent for Claude Code 36
 このエージェントは、以下のURLから入手できます。 https://github.com/wfukatsu/architecture-redesign-agent 前提条件： • Claude Code • Serena MCP ◦ 対応⾔語はSerenaに依存するが、LSP（Language Server Protocol）を拡張すれば、多⾔語でも対応 することが可能。アセンブラの場合は、リバースし てC⾔語に変換することで対応できます。 • Context7 ◦ コーディングエージェントが最新のコード記述パ ターンを理解するのに利⽤します。 • RyuGraph（オプション） ◦ ドメインとコードの関係を可視化する場合に利⽤ します。 MITライセンスで提供しており、著作権を表⽰し、ScalarDBの設 計エンジンを外さなければ、ダウンロードして⾃由に使っていた だいてもOKです。
37. 詳細設計エージェント:近⽇公開予定 37

38. まとめ 38
39. まとめ 39
 曖昧になりがちな ドメインの分割 ドメインの性質に基づいた分割 AIを⽤いることで、設計書とコードから⾃動で分割を実施 難しい ドメイン間の連携 ドメイン間の関係に基づいたトランザクション設計 AIによる、ルールに基づいた関係定義 AIでも難易度の⾼い 強整合性の実装 ScalarDBを⽤いたドメイン間の強整合性の実装 シンプルでAIフレンドリーなコードでの実装
40. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催