【AI×DevOps Study #17】AI駆動におけるモダナイゼーション by Claude CodeとAI活用のヒント

■AI×DevOps Study #17 の概要
2026年6月23日に開催した「AI×DevOps Study」第17回の発表資料です。

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

■今回のテーマ
「AI駆動におけるモダナイゼーション by Claude CodeとAI活用のヒント」

AIを日々の開発に活用していると、レガシーシステムの改善でこんな課題が出てきます。

・古いシステムを直したいけど、どこから調べればいいかわからない.
・コードやDBの構造が複雑で、影響範囲の把握に時間がかかる.
・AIで実装は速くできても、設計やレビューが弱いままだと品質が不安.

今回は、これらの課題に対して、Nexus Architectを使ってAI駆動でモダナイゼーションを進める体験をお伝えします。

紹介する内容は以下になります。

・現状調査と分析：既存コード、主要クラス、DB構成、業務機能の対応を整理し、最初に読むべきポイントを絞り込む流れ.
・評価と再設計：MMIやDDDの観点で課題を可視化し、境界コンテキストやサービス分割、ScalarDBを含む改善後の設計を具体化する流れ.
・設計レビューと実務活用：生成された設計をそのまま採用せず、データ一貫性、運用、障害対応などの観点でレビューし、実装に進める品質まで引き上げる流れ.

題材として、注文、在庫、決済、ポイント、返品を扱うレガシーPOSシステムを取り上げます。 今回の内容を通じて、AIに実装を任せる前に、調査、設計、レビューの質をどう高めるか、そして人間がより本質的な判断に集中するためのAI活用のヒントをお伝えいたします。

■登壇者情報（敬称略）
箱崎一輝
札幌の株式会社マーベリックスで、Webエンジニア兼リーダーを務めています。 これまで社内のGoogle Workspace全社導入を推進し、組織の働きやすい環境づくりに貢献しました。 今年からはAI駆動型の開発案件に本格的にジョイン。リーダーとしてチームをまとめながら、実際の現場で「AIをどうUI/UX開発に組み込むか」、日々の実践を通じて探求しています。

■関連コンテンツ
・Youtube（過去の勉強会動画も公開中！）
www.youtube.com/@scalar-labs

・Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

・イベントページ（connpass）
https://scalar.connpass.com/

Transcript

1. AI駆動におけるモダナイゼーション Claude CodeとAI活⽤のヒント 2026/06/23 株式会社マーベリックス 箱崎 ⼀輝
2. 発表者⾃⼰紹介 箱崎 ⼀輝 • 株式会社マーベリックス • Zenn（https://zenn.dev/hako_hako） • AI活⽤歴：約5年 ◦ 業務：Claude Code ◦ 個⼈：Codex
3. 今回お話しすること 1. なぜ今、AI駆動のモダナイゼーションが必要なのか 2. 従来のリファクタリングにある課題 3. Nexus Architectで何を⽀援できるか 4. レガシーPOSを題材にした実例 5. AI駆動モダナイゼーションの効果
4. • Scalar社 深津さんが開発した Claude CodeやCodex上で使うことができる システムアーキテクチャ設計⽀援のためのツールキット → 既存システムの調査‧再設計や新規システム設計を、   DDD/マイクロサービス / ScalarDB 観点で   設計‧レビュー‧レポート化するためのAIエージェント⽤スキル集 Nexus Architectについて https://github.com/wfukatsu/nexus-architect （ざっくりと）
5. 背景 5 なぜAI駆動でモダナイゼーションを考えるのか
6. モダナイゼーションとは ⼀般的な⽇本のモダナイゼーション • ⻑年運⽤されてきた⽼朽化‧複雑化したシステム（レガシーシステム）に対 し、⼤きく4つの⼿法でシステムを最適化すること 手法 役割 リプレイス ソフト／ハードウェアの両面から新しいシステムを構築して刷新する手法 リライト レガシーな言語で書かれたコードを、現代的な言語に書き換えること リホスト ソフトウェア部分に手を加えず、ハードウェアのみを最新に置き換える方法 リファクタリング 同じプログラミング言語と機能を維持したまま、コードの内部構造を改善する取り組み （そもそも）
7. レガシー改善は必要だが、進めるのが難しい • ⻑年の機能追加により、コード‧DB‧業務ロジックが複雑に絡まりがち... • 既存仕様や影響範囲の把握に時間がかかり、なかなか進まない...                  ↓                  ↓ AIで調査‧再設計を⽀援できないか？？ • ただし、既存仕様や業務上の意味を理解しないまま実装だけを急ぐと、 誤った設計や変更を⾼速に広げてしまう可能性がある
8. AI駆動開発における品質低下 ⽣成AIによるコード⽣成の効率化を急いだ結果 重⼤な障害に繋がる事例が報告されている • Amazon：AI⽣成コードの未確認マージによる障害多発（シニアエンジニアのレビューが必須になった） • GitHub：AI⽣成コードによって過去最⼤の品質低下が起きた問題 The Pragmatic Engineer.「Ideas: slow down to speed up when working with AI agents」. https://newsletter.pragmaticengineer.com/p/ideas-slow-down-to-speed-up-when • 実装速度だけを求めると、システム品質を⼤きく損なうリスクがある • あえてスピードを落として、設計‧テスト‧レビューの仕組みを整える
9. AI時代のモダナイゼーションについて • 単なる技術の置き換えではなく、AI開発に耐えうる構造への変⾰が必要である • 特に業務ルールが複雑なシステムでは、DDDの考え⽅を⽤いて 業務境界‧責務‧⽤語を明確にする 具体的に... • 業務の境界を明確にする ◦ DDDにより、業務領域‧責務‧⽤語を整理する • 依存関係を制御する ◦ 変更が他の機能へ影響しない構造にする • 品質を検証可能にする ◦ テスト‧レビュー‧評価によって、AIの変更を継続的に確認する
10. 課題 10 モダナイゼーションのボトルネックは、実装前の判断工程
11. • 前半⼯程の質が低いと、 後続の実装でも⼿戻りや⾒落としが発⽣しやすくなる • モダナイゼーションは、実装より前に多くの判断⼯程があり、 その品質が後⼯程を左右する ⼀般的なモダナイゼーションプロセス 現状調査 課題整理 改善方針の 検討 アーキテク チャ設計 設計レビュー 実装計画化 実装・テスト
12. 業務 ‧機能‧ユースケース ‧業務ルール ‧権限‧制約 コード ‧主要クラス ‧依存関係 ‧責務の集中 課題①：システムの全体像をつかむまでに時間がかかる データ ‧テーブル構造 ‧更新経路 ‧複数DBの整合性 ↓
13. • 合意しづらい • 理由を追えない • 担当者交代で再現できない 課題②：設計判断を同じ品質で再現できない • どこから直すべきか、どの単位で分割すべきかは担当者の経験に依存しやすい • 判断理由が暗黙知のままだと チーム内で合意しづらく、後から意思決定を追いにくい
14. 課題③：レビュー観点と判断理由が抜け落ちる • 設計レビューの観点は、⼈やチームによってばらつきやすい ◦ 機能、データ⼀貫性、運⽤‧監視、障害対応、セキュリティ‧コストなど • レビュー担当者やチームによって、重視する観点が異なる ◦ 機能⾯は詳しく確認できていても、障害時対応や運⽤設計が ⼗分に確認されていないこともある
15. AI駆動で解決したいこと ここまでの課題 • 全体像の把握に時間がかかる • 設計判断を再現できない • レビュー観点が抜け落ちる AIで⽀援したいこと • コード‧業務‧DBを横断して調査する • 共通の評価軸で判断材料を整理する • 複数観点でレビューし、結果を記録する → 役割の変化 AI → 広く調べ、整理し、繰り返し評価する ⼈間 → ⽬的、業務上の意味、制約、トレードオフを判断する
16. Nexus Architectとは？ 16 何を支援するツールなのか、できることを解説
17. Nexus Architectとは？ AIエージェント上で利⽤できるアーキテクチャ設計⽀援ツールキット • Claude Code（Codex）で使⽤可能、mdファイルで領域ごとにレポート⽣成 • モダナイゼーションの、実装の前⼯程までを⽀援 現状調査 課題整理 改善方針の 検討 アーキテク チャ設計 設計レビュー 実装計画化 実装・テスト
18. • 既存コードのディレクトリ構造、主要クラス、DB構成を整理しレポート化 ◦ どの機能がどこに実装されているか、どの責務が集中しているかを把握 具体例 • Javaファイル数、Thymeleafテンプレート、PostgreSQLとMySQLのスキー マ、主要クラスの⾏数、DAOやrepositoryの命名揺れなど 調査：現状を把握する
19. • 業務機能、アクター、権限、ドメイン概念を整理 • ビジネスルールがどのクラス‧テーブル‧処理に実装されているか 具体例 • アクター（Admin、Member）や注⽂/在庫/⽀払/ポイントなどの業務概念が、 どのコードやテーブルに対応しているかの整理 分析：業務とコードの対応を整理する
20. • MMIやDDDの観点で、システムの成熟度や弱点を評価する ◦ 事例紹介の際に解説します! • 境界コンテキスト、集約、レイヤリング、責務分離などの課題を数値やレポー トで確認する 評価：改善すべき箇所を優先度づけする
21. 再設計：改善後のアーキテクチャを具体化する • 分析‧評価結果をもとに、境界コンテキストやサービス分割案を設計する • ScalarDB、Outbox、Saga、CQRS Read Modelなどを含めて、⼀貫性や副作⽤ の扱いを整理する • どこをどう直すかを、実装に進められる設計レベルまで具体化する • なぜOpus？ → アーキテクチャ判断‧トレードオフ分析は⾼度な推論が必要
22. レビュー：設計のリスクと抜け漏れを検出する • ⽣成された設計をそのまま採⽤せず、複数観点でレビューする ◦ 品質チェックを⾏い、合格するまで設計→レビューのサイクルを回る • データ⼀貫性/運⽤/障害対応/セキュリティ/コストなどのリスクを確認する • ⼀部なぜOpus？ → 敵対的な視点でシステムの弱点を能動的に探すには⾼度な推論が必要なため
23. デモ‧実例紹介 23 レガシーPOSを題材にした分析・評価・再設計・レビュー
24. • モダナイゼーション対象のシステム • モノリス構成のPOS（Point of Sale）システム ◦ 商品が売れる瞬間を管理するシステム ◦ コンビニやスーパーのレジがイメージしやすい • 今回デモ開発した機能 ◦ 顧客：バーコードスキャン → 在庫確認 → ⽀払い → レシート発⾏ ◦ 管理者：商品‧在庫管理、売上確認 • 複数のDB更新や業務ロジックの複雑化がある POSシステム
25. Before題材の技術スタックとモジュール構造 構成要素 採用技術およびバージョン 言語 / FW Java 11 / Spring Boot 2.7.18 データベース PostgreSQL 15（マスタ、顧客、ポイント） MySQL 8.0（在庫、注文、決済、返品） 永続化層 JdbcTemplateによる手書きSQL（ORMやLombokは不使用） 認証 / セキュリティ Spring Security（古い WebSecurityConfigurerAdapter によるセッション管理） UI Thymeleaf によるサーバーサイドレンダリング、 jQuery トランザクション管理 同一DB内は @Transactional、複数DBをまたぐ処理は手書きの協調制御 （Saga） コンテナ環境 Docker Compose によるアプリケーション / 各DBのコンテナ実行
26. Claude Codeへの導⼊ → 開始
27. 調査①：コードの全体を俯瞰する 確認したこと • ディレクトリとファイル構成 • 主要クラスの規模と依存関係 • PostgreSQL / MySQLの利⽤状況 代表的な発⾒ • OrderServiceとCheckoutSagaに複 数の責務が集中していた
28. 調査②：DDDを適⽤できる状態か確認する 確認したこと • 業務境界を識別できるか • ドメインモデルが存在するか • モジュールが独⽴しているか 評価結果 • DDD準備度：29 / 100 ◦ 業務概念は⾒えるが、コード上の境界が 崩れている ◦ DDDを始める前に、巨⼤クラスと依存関 係の整理が必要
29. 調査③：改善すべき問題を重⼤度別に整理する 検出された課題 • すぐに対応が必要...4件 • 影響が⼤きい課題...8件 • 計画的に改善する課題...18件 もっとも重⼤な問題 • 注⽂‧在庫‧ポイントを複数のDBへ順 番に更新している → 途中で処理が失敗すると、⼀部の データだけが更新される可能性がある
30. 調査④：技術要素と移⾏リスクを整理する 検出した主な構成 • Java 11 • Spring Boot 2.7 • JdbcTemplate • Thymeleaf / jQuery • PostgreSQL + MySQL 移⾏時の論点 • Java / Spring Bootの更新 • javaxからjakartaへの移⾏ • 認証⽅式とテスト基盤の⾒直し
31. 調査：現状を把握する レポートの種類 POSにおける、主な出力内容 コードベース構造 56 Java ファイル、OrderService（976行）God Service、 CheckoutSaga（557行）God Class、dao/+repository/ パッケージ命名揺れ DDD準備度 総合点 29/100。 潜在的 BC（8個）は識別可能だが God Service/Saga が境界を崩壊。ScalarDB で手書き Saga を置き換えると TD-002/003/009 が根本解決 技術的負債 すぐに対応が必要...4件、影響が大きい課題 ...8件、計画的に改善する課題 ...18 件の計30件 最重大はDB跨ぎ原子性未保証 テクノロジースタック Spring Boot 2.7.18 (EOL), Java 11 (EOL)
32. ドメイン分析①：ビジネス観点で整理 主要な業務 • レジ販売 • 商品 / 在庫管理 • 注⽂ / 返品管理 • 会員ポイント • 売上ダッシュボード コードを読む前に、システムが実現して いる業務を定義する
33. ドメイン分析②：誰が何を操作できるか整理する 4種類の利⽤者と役割を整理 • CASHIER … レジ販売‧会計‧レシート発⾏ • MANAGER … 商品‧在庫‧注⽂‧返品‧売上管理 • ADMIN … 全管理機能‧ユーザー管理 • Member … ログインはせず、会計時に会員IDを提⽰するポ イント対象者 分析で確認できたこと • 3つのシステムロールを識別 • Memberは認証ユーザーではない • 認可は主にURLパターンで制御 • サービスメソッド側の認可は未実装
34. ドメイン分析③：システム内で使われている⾔葉を揃える 60以上の業務⽤語を抽出 • DAO / Repositoryの混在 • UserとMemberの意味が曖昧 • ポイント種別の名称が不統⼀ • ステータスが⽂字列で散在
35. ドメイン分析④：業務概念と実装箇所を対応づける 業務概念とコードの対応を整理 分析で⾒つかった問題 • 同じ業務ルールが複数箇所に分散 ◦ 税計算やポイント計算や返品可否判定など コード構造とのズレ • 決済処理がCheckoutSagaに埋め込まれている • 返品処理がOrderServiceとReturnSagaに分散 • DBの分け⽅と業務上の境界が⼀致していない
36. レポートの種類 POSにおける、主な出力内容 システム概要 10 機能カテゴリ、主要フロー： CheckoutSaga（6ステップ） / ReturnSaga（6ス テップ）。 決済は System.out.println モック アクター・ロール・パーミッショ ン 3 ロール（CASHIER/MANAGER/ADMIN）+ Member。SecurityConfig の URL パターン認可のみ。メソッドレベル認可なし ユビキタス言語辞書 60+ ドメイン用語。不統一： dao/repository 並存、 ポイントtype文字列の混乱、User vs Member の概念分離 ドメイン-コードマッピング 10 BC 候補、税計算 4 重・ポイント計算 4 重・返品可否 3 重、 PaymentService/ReturnService 欠如、DB 境界が BC 境界と不一致 ドメイン分析：ビジネス観点で整理
37. 評価‧採点：MMI評価 • MMI（モジュール成熟度指標）とは ◦ このシステムはマイクロサービスに分割できる状態かを数 値で表す指標 • MMI評価とは … MMIを実際のコードに適⽤して採点する⾏為 ◦ 4つのサブエージェントが並⾏して各軸を評価 軸 意味 重み 凝集性 モジュール内の責務が一貫しているか 30% 結合度 他モジュールへの依存が少ないか 30% 独立性 単独でデプロイ/テストできるか 20% 再利用性 他のコンテキストでも使えるか 20%
38. 評価‧採点：MMI評価 • どうやって算出している？などMMIの基本的な考え⽅は Zennのブログで解説されています！ ◦ ※記事内では3つになってますが、 Nexus Architectではより細かく評価するため 4つの評価軸で算出されています
39. DDD評価とは • 現状のシステムがDDDの原則にどれだけ準 拠しているかを定量スコア化する⾏為 ◦ 総合スコアは24.5% • 戦略的設計（1.3/5） ◦ システムをどう分割するか • 戦術的設計（1.3/5） ◦ 境界の中をどう実装するか • アーキテクチャ（1.0/5） ◦ レイヤー構造と依存の⽅向が正しいか 評価‧採点：DDDの3つの観点で評価する
40. 評価‧採点：複数の評価結果から、構造的な課題を特定 MMI平均 46% DDD評価 24.5% 両⽅の評価で⼀致した課題 • ⼿書きSagaの構造的な⽋陥 • OrderServiceへの責務集中 • 貧⾎ドメインモデル • Application層の⽋落
41. 再設計：境界コンテキストを再設計 12の業務領域を、重要度と役割で分類 事業の中核 • Checkout … 会計全体の進⾏を管理 • Order … 注⽂と状態遷移を管理 • Loyalty … 会員とポイントを管理 共通基盤 • Identity … 認証‧権限 • Audit … 監査ログ • Dashboard … 売上‧在庫集計 業務ルールの変更で 他の領域へ広がりにくい構造にする
42. ScalarDBによって、複数DB更新を⼀つ のTxで管理する構成に変更 再設計：ScalarDB設計
43. 処理の性質に合わせ、3つの連携⽅式を設計 画⾯‧外部からのAPI • 商品検索、注⽂確認、チェックアウトなど、画⾯や外部シス テムから呼び出す • HTTP APIの仕様をサービスごとに定義 業務イベントによる⾮同期連携 • 注⽂完了、在庫更新、ポイント付与など • 監査ログや売上集計へ⾮同期で連携する サービス間の内部連携（gRPC） • 注⽂‧在庫‧決済などのサービス間で⾼速に処理を呼び出す • 複数サービスを跨ぐ処理では、同じtransaction_idを引き継 ぐ 再設計：API設計
44. • 初回設計を5つの観点でレビュー ◦ レビューエージェント並列起動 • ブロッカー / 必須修正レベルの 指摘を抽出 • 設計を修正して再レビュー ◦ FAIL→PASSになるまで繰り返す 設計レビュー
45. 設計後のAI駆動による実装について • 合格した設計書をもとに、AI駆動開発を⾏う流れは Zennのブログで解説しています！ • Compound Engineeringについて、 計画 / レビュー / デバッグ / 解決した問題の記録を 残し、次の作業を前回より進めやすくするような Claude Codeのプラグイン
46. Nexus Architect サマリー Before / After ⽐較 指標 役割 Before After DDD準拠度 ドメイン設計の成熟度を示す指標 21.8% 86.8% MMI平均 モジュールの独立性・凝集度を示す指標 45.3% 77.4% 総合評価 マイクロサービス移行準備度の総合指標 33.6% 82.1% 主な改善事項 • 責務が OrderService、CheckoutSaga、ReturnSaga から13サービスへ分散され、構造が整理された • ⾦額や数量などの共通ルールをまとめたことで、同じ処理を何度も書かずに済むようになった • サービス同⼠が相⼿の内部モデルに直接依存しなくなり、変更の影響が広がりにくくなった
47. AIに任せること、⼈間が担うこと AIが得意なこと • コード‧DB‧設計書を横断して広く調査する • 課題候補や設計案を網羅的に列挙する • 同じ評価基準で繰り返しレビューする ⼈間が担うこと • 何を改善⽬的とするかを決める • 業務上の意味や暗黙の制約を補う • コスト‧納期‧リスクのトレードオフを選ぶ
48. 導⼊効果とはじめかた 48 品質向上・工数削減・実務適用の可能性
49. 効果①：調査‧設計の初動を速くできる 従来 • コードやDBを⼈間が順番に読み解く • 調査結果を⼿作業で資料化する • レビューに必要な情報を後から集め直す Nexus Architect活⽤後 • コード‧DB‧設定ファイルを横断して調査する • 主要クラス、依存関係、技術的負債をレポート化する • 調査結果をそのまま分析‧評価‧設計の⼊⼒にできる
50. 効果②：判断とレビューの品質を⾼められる 課題を同じ評価軸で確認できる • MMIやDDDの観点で弱点を評価する • 責務集中や境界の崩れを数値‧根拠付きで確認する • 複数の改善候補を⽐較しやすくする レビューの抜け漏れを減らせる • データ⼀貫性 • 障害対応‧運⽤ • セキュリティ • コスト‧移⾏リスク • ビジネス要件との整合性
51. 実務では最⼩限単位から始める Nexus Architectの具体的なはじめ⽅ 1. 現状分析だけ実施してみる • コード構造とDB構成を整理する • 責務が集中している場所を⾒つける • AIの分析結果が事実と⼀致するか確認する 2. 課題の⼤きい領域と⼀つ選ぶ • 変更頻度が⾼い • 障害影響が⼤きい • 業務ルールが複雑 • 属⼈化している
52. まとめ 52
53. AIで速く作るのではなく、判断と整合性を仕組みにする Nexus Architectの価値 • コード‧DB‧業務‧運⽤を横断して現状を可視化 • MMI / DDD / レビュー観点で、課題と根拠を残す • 設計判断を属⼈化させず、再現可能なプロセスにする ⼈間が決めること • どの領域から始めるか • どこまで変更を許容するか • コスト‧納期‧リスクを踏まえた最終判断 まとめ