【2026/9/8】ITイノベーターズ会議 AI駆動レガシーモダナイゼーションの最新動向最新事例に学ぶ実践法

2026年9月8日に開催されました 日経クロステック（日経BP）様主催の 第46回 ITイノベーターズ会議 にて、弊社CEO 深津が登壇時した際の発表資料になります。

Transcript

1. AI駆動レガシーモダナイゼーションの 最新動向、最新事例に学ぶ実践法 AI時代のレガシーモダナイゼーション 2026年9⽉8⽇ 株式会社Scalar
2. 株式会社Scalar 東京、札幌、サンフランシスコを拠点に 日本からグローバルへの展開を目指す B2Bソフトウェアのスタートアップ VISION データマネジメントの未来を創る 今後はデータ中心の社会になっていき、データが様々なシス テムを有機的に結合し、データに基づいて様々な処理が自動 化されていきます。そのようなデータ社会を安心できるものに することが私たちのビジョンです。 © 2026 Scalar, inc.
3. 現状維持は選べないが、便益不明と仕様不明が刷新を阻む なぜ刷新が必要か：放置しても現状は維持されず、リスクと費⽤が複利で増える 守れない 変えられない 維持できない サポート終了‧脆弱性‧障害 → 事業継続リスクが年々増⼤ 新サービス‧AI活⽤に追随できず → 競争⼒と機会を失う 保守費は増え担い⼿は引退‧枯渇 → いずれ運⽤が成り⽴たない 技術負債は、 年利20%で 複利で増えていく *1 ビジネスの壁：便益が⾒えない 技術の壁：仕様と影響範囲が分からない 1 「動いている」ものへ投資しにくい 新価値を⽣まない⽀出に⾒える 1 ブラックボックス‧暗黙知 2 便益が定量化できない 障害回避‧機会獲得は反事実で測れない 2 密結合で影響範囲が読めない 3 新規案件が常に優先される 刷新は「来期」へ送られ負債が積む 3 データ移⾏が最難所 4 ⽅針‧スコープが揺れる 4 同等性を証明できない システム刷新か業務変⾰か決まらない 仕様書がなく動作の「正解」が不明 ⼩さな変更でも全体が壊れる 数⼗年分のデータと業務ルールを保つ テスト資産がなく同じ動きを担保不可 共通の根：現⾏システムを「理解できていない」— 便益も仕様も、理解できなければ⾒積もれない モダナイゼーションの壁の正体は「理解不⾜」 AIエージェントで解析‧仕様復元‧特性テスト⽣成のコストが下がれば、 ⾒積精度とリスク評価が変わり投資判断そのものが動く *1 出典：CTO Accelerator “Legacy Modernization: The Definitive Business Case Data Guide” より © 2026 Scalar, inc. 2
4. AIで最適解は変更度の大きい側へ、課題は検証と統制へ移る ⼩ ⼤ 変更度 リホスト リプラット フォーム リファクタ∕ リコード リ‧アーキテクト リビルド そのまま移設 基盤だけ変更 中⾝を書換 構造を再設計 作り直す 負債が残る 互換性検証が ⼿作業 ブラックボックス 専⾨⼈材不⾜ 境界設計が⾼難度 ⻑期‧⾼コスト 最⾼コスト 暗黙仕様の⽋落 ⼿法 従来の課題 枠 = 現実解の範囲 AI時代 AIで現実解が右へ広がる 変化は⼩ DB移⾏‧互換 テストを⾃動化 解析‧特性テスト を⾃動化 AIエージェントが担う 理解 解析‧ロジック抽出 DDD分析‧再設計 を下書き 既存コードから 仕様を逆⽣成 ⼈が担う 変換 再設計‧コード⽣成 テスト 特性テスト‧品質ゲート 検証と統制：誤変換‧幻覚のビュー、 受⼊判定と投資判断 敬遠されてきたリファクタ〜リビルドが現実解になり投資判断はAI前提で⾒直すべき。ただし誤変換‧幻覚は残るため、特性テスト‧ 品質ゲート‧⼈のレビューを組み込む「検証設計」が成否を分ける © 2026 Scalar, inc. 2
5. 【事例】常石造船：16年間刷新できなかった理由 稼働16年超の調達システム（モノリス） 7,061 217+ 458 プログラム 画⾯ テーブル 350+ 1,100+ 17年分 ストアド 関連ファイル 業務ルール 巨⼤モノリス ブラックボックス 密結合で⼀部の変更が 全体に波及 「あの⼈に聞かないと 分からない」属⼈化 ④ 調査コスト 80〜200⼈⽉ さらに：従来型の刷新（4年）では、完成した時点で時代遅れになる 要件定義 基本‧詳細設計 2026 技術を選定＝凍結 開発‧テスト 移⾏‧稼働 2030 完成‧稼働 技術負債 ⼤規模修正‧更新が できず脆弱性が蓄積 改修のたびに影響範囲の調査に多⼤な時間 → 調査コストの⾼さ⾃体が着⼿を阻む要因に → ⼿を付けられず負債がさらに積み上がる 技術のサイクルは、4年で Ver.Up 8回、Framework は1 年ごと、基盤は 2年ごとに新 しくなっていく 稼働初⽇に 4年分の遅れ 調査コストの⾼さが着⼿を阻み、着⼿しても4年後には時代遅れ。 「⼈が数か⽉かけて調べ、数年かけて作る」やり⽅そのものの⾒直しが必要 © 2026 Scalar, inc. 1
6. 【事例】AIエージェントで約4時間：分析から再設計まで ① 解析 ② リファク タリング ③ ドメイン 分割 ④ MS再設計 ロジック抽出 ‧整理 設計書レベル に復元 ドメインマッ ピング 11の境界づけ られた コンテキスト 9マイクロ サービス API‧トラン ザクション 設計 ⑤ ⾒積 現⾏モノリス 7,061 プログラム 458 テーブル 350+ ストアド 全プログラム ‧テーブル を同⼀基準で 全量分析 ドメインス トーリー コスト⾒積 9 マイクロサービス 購買調達 鋼材調達 在庫 会計連携 輸出‧物流 ⼯事‧予算 マスタ 認証 外部連携 AIエージェント実⾏ 約4時間 refactoring-agent-for-claude-code：10段階プロセス（分析∕設計∕データ基盤∕⾒積）を⾃動実⾏ 従来（⼈⼿ / SI 外注） 80〜200⼈⽉ AI 活⽤（実績） Claude Code 約4時間 1年〜2年 AI：全量分析‧変換‧設計案の作成 ｜ 99%超 削減 ⼈：結果の解釈‧リファクタリング⽅針の決定‧レビュー（Human-in-the-Loop） 調査をした上で、ドメイン駆動設計、テスト駆動設計を⾏い、マイクロサービスアーキテクチャへ移⾏中 © 2026 Scalar, inc. 2
7. 弊社の取り組みにおけるAIの適用領域 ⼈が⾏う ⼈が主導 AIが主導 AIが⾃⾛ AIエージェントが⾃動化 ⼤⼯程 → プロセス ↓ 企画‧要件定義 設計 開発 テスト 移⾏‧リリース 保守‧運⽤ 調査 分析 現⾏システム分析 技術負債‧DDD評価 SaaS/PaaS‧法的調査 ドメイン分類‧ 境界コンテキスト抽出 既存コード影響調査 脆弱性‧依存関係 スキャン 既存スキーマ解析 ログ解析‧異常検知 定義 設計 FR/NFR定義 SLO‧SLA策定 会議⾳声⇒要件 アーキテクチャ‧API データ‧物理モデル セキュリティ‧DR設計 詳細設計 DTO‧例外マッピング テスト仕様⽣成 BDD‧契約‧性能 移⾏計画 TX境界の設計 運⽤⼿順‧ アラート設計 ⽣成 実装 UIプロトタイプ ドメインストーリー API契約‧ER図‧構成図 UX/UI‧Atomic Design API/BFF/フロント データ‧インフラ実装 契約テスト‧ 単体‧E2E実装 移⾏コード‧ IaC⽣成 ドキュメント⽣成 パッチ作成‧適⽤ 検証 レビュー 要件の追跡性確認 7観点の並列レビュー ＋統合ゲート判定 コードレビュー 設計乖離の検証 テスト実⾏‧結果判定 障害‧性能試験 UX評価 マージ前チェック CI‧承認‧競合 脆弱性再スキャン 回帰テスト 判断 承認 ゴール設定‧ スコープ確定 Go/No-Go判断 アーキテクチャ決定 境界の確定 実装⽅針‧ 例外対応の判断 受⼊テスト(UAT) 品質ゲート承認 リリース判断‧ マージ承認 エージェント‧ ルール改善の判断 AIの管理（全⼯程を横断‧⼈が⾏う） エージェント開発 ∕ ルールの最適化 ∕ ⼯程依存グラフの定義 ∕ ⼯程ごとのモデル割当とコスト最適化 1 © 2026 Scalar, inc.
8. 部品化と監督型エンジニアリングで、品質を担保 アンドン ｜ 異常を検知して、その場で⽌める AIエージェントにナレッジを蓄積し、 ⾃働化と省⼈化を⾏い、 ループを加速していく ポカヨケ ｜ 間違いを作り込ませない © 2026 Scalar, inc.
9. 【事例】AI駆動開発によるAPIの開発生産性の向上 レビュー済みのAPIの開発本数 合計（ブランチ込み‧参考値） 200件 テストカバレッジ 20%→95%以上に向上 API開発体制 1/3へ移行 150 138件 86件 100 50 0 22Q4 23Q1 23Q2 23Q3 23Q4 24Q1 24Q2 24Q3 24Q4 25Q1 25Q2 25Q3 25Q4 26Q1 26Q2 AI駆動開発へ移行開始 ループエンジニアリング開始 © 2026 Scalar, inc. 26Q3
10. AI活用した製品開発・開発プロジェクトの経験より: AI駆動開発におけるベストプラティス コンテキストが⼤きいほど精度が落ちる マイクロサービスでの開発が効率的 モノリス∕モジュラーモノリス AI Agent マイクロサービス AI Agent 従来（⼈⼿‧推定） 1,220h∕6〜9ヶ⽉ AI＋モジュラーモノリス 900h∕約3ヶ⽉ AI＋マイクロサービス 56h∕約3週間 出典: NoLiMa (ICML 2025, Adobe Research) AI駆動開発のベストプラクティス 1 コンテキストを⼤きくしすぎない 2 ドメイン∕モジュールを切り予期せぬ変更を防ぐ 3 脆弱性対応を迅速に⾏える構造にする © 2026 Scalar, inc.
11. 【事例】AI時代の脆弱性の実態 出典: GitLab Security Dashboard（2025-12-12 〜 2026-08-04‧全 29 週‧detectedAt 基準） 288 件 総検出 26 件 Critical 90 件 High Critical High Medium 11 件 Other Low Info Unknown 98 100 運用中のシステムでの 脆弱性検出の件数 スキャナの 拡充後 Claude Mythos / Fable 5 Release 75 50 45 Claude Mythos preview Release 25 21 17 19 0 12/8 12/15 12/29 1/5 1/12 1/19 1/26 2/2 2/9 2/16 2/23 3/9 3/16 3/23 3/30 4/6 4/13 4/20 5/4 5/11 5/18 5/25 6/1 6/8 6/15 6/22 6/29 2 つの⼭（5/18‧7/20）は新規発⽣ではなくスキャナ拡充による⼀括検出。定常ペースは週 1〜10 件、うち Critical / High が 1〜3 件 © 2026 Scalar, inc. 7/20 8/3
12. Scalar製品の開発の方向性：AIによる開発前提に AI駆動開発(AIDD)がマイクロサービスアーキテクチャの選択を後押し AI1 AI2 AI コンテキストを小さく保てる 変更範囲を閉じ込められる 部分的に早くリリースできる AIに渡すコンテキストが小さいほど AIは正確に動作 境界を物理的に閉じ、AIに意図しな い変更をさせない。並行開発も可能 部分リリースにより、迅速なリ リースと脆弱性対応が可能 AIDDによる経営スピードの向上は、マイクロサービスアーキテクチャの選択が一つの鍵 ScalarDB はマイクロサービスユースケースにおける大幅な機能強化を実装 © 2026 Scalar, inc.
13. 異常系を有限の型に閉じて、AIに実装させる 業務ごとに考えるものだった異常系が、決まった分岐と決まった⾻組みになる 例外は3つの分岐に閉じる モデルごとに、異常系の⾻組みが決まる prepare が1つでも失敗すれば、 CommitConflictException CrudConflictException rollback して リトライする 2PC UnknownTransaction StatusException rollback しない 状態を後から照合する Saga その他の TransactionException rollback する TCC どれに当たるかで、取るべき動作が⼀意に決まる 全 participant を rollback。 commit は1つ成功すればコミット扱いになる 失敗したステップまでの処理を、 補償トランザクションで逆順に打ち消す Try で確保した資源を Cancel で解放する。 確定済みなら Confirm 済みとして扱う モデルを選んだ時点で、書くべき異常系が決まる 分岐が有限になる 判断が定型になる ⾻組みは基盤側にある プロンプトにも規約にも書き切れる レビューは型どおりかの確認で済む AIが書くのは業務ロジックだけになる © 2026 Scalar, inc. 3
14. 守る場所を、アプリケーションから基盤へ移す 同じ3サービス‧同じ3データベースで、認可と暗号化がどこに置かれるか アプリケーションに実装する 注⽂ 認可＋暗号 のコード 決済 認可＋暗号 のコード ScalarDB に寄せる 請求 認可＋暗号 のコード 注⽂ サービス 共通の層がないため、 PostgreSQL RLS を個別設定 請求 サービス ScalarDB Cluster 認証 / OIDC ‧ ABAC ‧ カラム暗号化 各サービスが各DBの流儀で個別に実装する MySQL RLS を個別設定 決済 サービス DynamoDB RLS を個別設定 MySQL PostgreSQL DynamoDB 認可と暗号化がアプリに散在し、DBごとに個別設定が要る 1回の設定が、全DB‧全アクセスに⼀律に効く 1箇所の抜けは、コードを読んでも⾒えない アプリのコードに認可も暗号化も現れない 「レビューで⾒つける」から「そもそも書かせない」へ © 2026 Scalar, inc. 5
15. 4 つの製品で、散らばったデータを「正しく」使えるようにする — Universal HTAP エンジン Enterprise Edition Saga （3.19 新） Analytics 改ざん検知 ミドルウェア ‧異種 DB をまたぐ ACID ‧Saga / TCC の実⾏基盤 ‧ETL なしの横断分析 ‧ビザンチン故障を検知 ‧統⼀ API / SQL ‧外部 API‧SaaS 連携 ‧Apache Spark で実⾏ ‧Ledger + Auditor ‧暗号化‧アクセス制御 ‧補償処理を⾃動管理 ‧3.19 でクエリ⾼速化 製品の特⻑ データベースそのものではなく、異種複数のデータベースを仮想的に統合し、トランザクション‧分析‧証拠性を 「後から⾜す」ミドルウェア群。ScalarDB は 3 製品の組み合わせ、ScalarDL は単独でも導⼊できる。 © 2026 Scalar, inc. 2
16. © 2026 Scalar, inc.