株式会社NTTデータは2026年8月20日、ホワイトペーパー「AI-Native時代のモダナイゼーション ― 目指すべき姿と品質保証の考え方」を公開しました。
白書は、モダナイゼーションの目的を「基幹システムの移行完了」から、業務を支えるAIと共に進化し続ける基幹システムの構築へ再定義しています。
刷新の評価軸は、移行先の環境だけではありません。AIが業務データや機能と連携し、変更と説明を積み重ねられる構造まで含めて考える必要があります。
※本記事は2026年8月28日時点の情報です。
目的の再定義｜移行完了から進化し続ける基幹システムへ
従来のモダナイゼーションは、古い基盤から新しい基盤へ移すことが大きな目的になりがちでした。
白書は、その先にある状態を「業務を支えるAIと共に進化し続ける基幹システム」と表現しています。
AIが補助的な道具ではなく、業務とシステム開発の主体になる状況をAI-Native時代と捉えています。
- 移行の視点：基幹システムを新しい基盤へ移す
- 進化の視点：業務を支えるAIと共に作り変え続ける
この定義転換により、計画時の成功条件も変わります。
移行完了日だけでなく、AI連携、変更、説明、セキュリティを継続的に扱えるかを確認します。
この考え方では、基幹システムは業務の変化を受け止める土台になります。
一度の移行で計画を終えず、業務変革を続けられる構造を先に定義します。
経営層、情報システム部門、業務部門が同じ到達点を共有することも重要です。
ポイント
白書が示す到達点は、基幹システムの移行完了ではありません。業務を支えるAIと共に進化し続けられる状態です。
AI-Native時代の基幹システムが満たす4要件
白書は、進化し続ける基幹システムの要求事項を4つに整理しています。
| 要件 | 意味 |
|---|---|
| 業務を支えるAIとの連携容易性 | AIエージェントが業務データや機能を利用できるAPIなどの接点を整える |
| AI-Native開発を前提とした変更容易性 | モジュール化・疎結合と読み取りやすい文書で修正箇所を特定しやすくする |
| AIガバナンスを支える説明可能性 | 利用データ、利用時点、利用方法を記録し、処理を後から追跡する |
| サイバー攻撃への耐性 | 脆弱性への対応とパッチ適用、影響確認を繰り返せる構造を備える |
1つ目は、業務を支えるAIとの接点です。
業務単位で機能を呼び出せるAPIなどを整え、AIが意味を理解できる形で提供します。
2つ目は、開発を担うAIを前提にしたシステムの性質です。
責務ごとのモジュール化や疎結合、実態と一致した設計・仕様が変更の土台になります。
3つ目と4つ目は、AI活用のリスクから信頼を守る要求です。
AIが関与した処理を説明できる記録と、脆弱性へ繰り返し対応できる構造を備えます。
変更容易性では、責務ごとのモジュール化と疎結合が修正の境界を明確にします。
実態と一致した設計や仕様も、AIが修正箇所と影響範囲を特定する手がかりになります。
Markdownなど、AIが読み取りやすい形式のドキュメントを備えることも要件の一部です。
説明可能性では、AIが利用したデータ、利用時点、利用方法を後から追跡できるようにします。
サイバー攻撃への耐性では、パッチ適用と影響確認を繰り返せる構造を整えます。
ポイント
4要件は、AIとの連携、AIを前提にした変更、処理の説明、攻撃への耐性です。基幹システムをAI活用の接点として設計する視点が表れています。
2段階戦略｜リホストを第1段階、AI-Native開発を第2段階に
白書は、基幹システムを一度に作り替えるのではなく、2段階で構造を転換する戦略を示しています。
| 段階 | 主な内容 | 狙い |
|---|---|---|
| 第1段階 | リホストによる基盤刷新 | 保守期限や維持費用に起因するリスク・コストを先に解消する |
| 第2段階 | AI-Native開発を導入したリビルドと現新比較試験 | システムを段階的に移行し、構造を転換する |
第1段階はリホストを基本とします。
白書は、リライトを選ぶ場合も、基盤起因のリスクとコストを先に解消する考え方を示しています。
第2段階では、AI-Native開発と現新比較試験を組み合わせます。
現新比較試験は、現行と新システムへ同じデータを入力し、出力結果を比較する手法です。
白書は、現行システムの振る舞いと現行データを正解に据え、「現行どおり」を直接確かめる考え方を示しています。
AI-Native開発では、現行仕様の復元から設計、製造、テストまでAIを適用する方法が示されています。
- 再設計を担うAIエージェント
- 実装を担うAIエージェント
- 単体・結合テストを担うAIエージェント
- 保守性を評価するAIエージェント
保守性評価の結果を再設計へ戻すループも、工程に組み込まれています。
現新比較試験は、移行時だけでなく、移行後の継続的な改修にも使う考え方です。
白書は、実際の基幹システムを対象に検証を重ね、技術の完成度を高めている段階と説明しています。
小規模システムでは、リビルドと最初の業務変革を同時に進める方法も有効とされています。
ポイント
第1段階はリホストを中心とした基盤刷新です。第2段階でAI-Native開発と現新比較試験を組み合わせ、規模や投資対効果に応じて進め方を選びます。
企業の計画への含意｜4ステップで目的と移行順序を決める
白書は、企画段階の進め方を4ステップに整理しています。
- 目的と目標の設定：経営上のニーズから定める
- 現状の把握：目標との隔たり、仕様の手がかり、内部依存を確認する
- 方針と超概算の策定：現状維持、リホスト、リビルドの投資額と効果を比べる
- ロードマップ策定：保守期限や有識者の残存期間から順序を設計する
現状の把握では、プログラムの呼び出し関係とデータベースアクセス関係も確認します。
投資対効果が目標に合わない場合は、段階や対象領域を調整して計画を繰り返します。
第1ステップでは、経営上のニーズとモダナイゼーションの目的を結び付けます。
第2ステップでは、仕様を知る手がかりがどれだけ残っているかも確認します。
第3ステップでは、現状維持、リホスト、リビルドの投資額と効果を粗く比べます。
第4ステップでは、保守期限や有識者の残存期間から、移行の順序を逆算します。
この整理を共有すると、基盤刷新と業務変革の議論を同じロードマップに置けます。
基幹業務でのAI活用を考える際は、法人向けAIと経営判断の接点も整理できます。
会計領域の再構築では、AIネイティブ経理SaaSの動向も比較材料になります。
ERPのAI活用を検討する企業は、SAPとAnthropicの連携も参考にできます。
AIエージェントを業務へ接続する際は、企業向けエージェント基盤の設計も確認します。
ポイント
計画では、移行先を先に決めず、目的、現状、投資対効果、期限から段階と対象領域を決めます。AIとの連携と継続的な変更も評価軸に加えます。
ロードマップの共有｜経営・情シス・業務を同じ到達点へ
AI-Nativeモダナイゼーションは、基盤だけを担当部署へ渡して終わる計画ではありません。
白書は、経営層、情報システム部門、業務部門の三者で結果を共有する考え方を示しています。
- 経営層：経営上のニーズから目的と目標を定める
- 情報システム部門：内部依存や保守期限を把握し、基盤の方針を整理する
- 業務部門：業務データや機能をAIが扱う接点を確認する
三者が別々の指標を持つと、移行完了と業務変革の優先順位がずれます。
目的、現状、投資対効果、期限を共通のロードマップへ置くことが、判断の前提になります。
業務側のAI導入を継続する段階では、基幹システムの変更容易性と説明可能性も見直します。
基盤刷新と業務変革を別の計画にせず、進化のループとして管理することが重要です。
現状把握では、既存の仕様だけでなく、プログラムとデータベースの依存関係も見ます。
依存関係が分かると、リビルドする領域と順序を検討しやすくなります。
保守期限が近い領域は、リホストを先に置く判断材料になります。
一方で、目的や投資対効果が合わない場合は、対象領域を調整します。
リビルドの設計では、AIが扱いやすい業務単位とドキュメントの形を確認します。
品質保証では、現行データを使った比較と、変更後の影響確認を計画へ組み込みます。
こうした確認を重ねることで、移行後の改修もロードマップの対象にできます。
モダナイゼーションの計画は、作成して終わる文書ではなく、判断を更新する土台になります。
4要件は、個別の機能追加ではなく、基幹システムの構造に関わる確認項目です。
AIとの連携容易性と変更容易性は、業務と開発の両方の接点になります。
説明可能性と攻撃への耐性は、AIを使い続けるための信頼を支えます。
この4要件を現状評価とロードマップへ反映すると、移行後の課題も見通せます。
2段階の経路は、目的と対象領域に応じて組み合わせる前提で読み取ります。
現新比較試験では、同じ入力に対する出力の差分を確認します。
差分を確認できることが、現行どおりの品質を考える基準になります。
AI-Native開発では、再設計から保守性評価までを工程としてつなぎます。
このつながりが、移行後も改修を続けるための品質保証の考え方です。
計画段階からこの品質保証を置くと、移行後の変更も見通しやすくなります。
4要件と2段階を、自社の計画表へ対応付けることが実務の出発点です。
移行後の継続的な改修まで含めて、到達点を定義します。
その定義を、各部門の判断基準にそろえます。
ポイント
経営層、情報システム部門、業務部門が、目的・現状・投資対効果・期限を共有します。基盤刷新を業務変革へつなげる共通言語になります。
よくある質問
Q. 白書はモダナイゼーションの目的をどう再定義しましたか？
基幹システムの移行完了から、業務を支えるAIと共に進化し続ける基幹システムの構築へ再定義しました。
Q. AI-Native時代の基幹システムの4要件は何ですか？
AI連携の容易性、変更容易性、説明可能性、サイバー攻撃への耐性です。
Q. 2段階戦略の第1段階は何ですか？
リホストによる基盤刷新です。リライトを選ぶ方法も白書は示しています。
Q. 小規模システムも2段階で進めますか？
小規模システムでは、リビルドと最初の業務変革を同時に進める方法も有効とされています。
まとめ
株式会社NTTデータは2026年8月20日、AI-Native時代のモダナイゼーションに関する白書を公開しました。
白書の中心は、基幹システムの目的を移行完了から、業務を支えるAIと共に進化し続ける状態へ広げることです。
企業の計画では、4要件と2段階戦略を、自社の目的、現状、投資対効果、期限に照らして整理します。
参考情報：
関連記事
- NIKKEI KAIを解説｜出典付き法人生成AI
- AIネイティブ経理SaaS「Rillet」を解説
- SAPとAnthropicの連携を解説
- Gemini Enterprise Agent Platformを解説
- AnaplanのAgentic Enterpriseを解説
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。