KEEPALIVE / AI-READY
古くなったシステムの「図面」を描き直し、AIと一緒に変えていける状態へ。
01AS-IS / TO-BE
長く使われてきた業務システムは、言語も作り方もさまざまです。主な現行システム（As-Is）と、モダナイズ後の姿（To-Be）の代表的な例をご紹介します。どの方式で移すかは、アセスメントでお客様と決めます。
素のPHP、FuelPHP・Laravel・CakePHPなど（PHP 5.x〜8.x）
PHPの版が古く、脆弱性への対応が追いつかない。画面と処理が1つのファイルに混ざり、業務のルールがどこにあるか分からない。
Spring Boot・Spring MVC、JSP、MyBatis・JPAなど
古いJavaやSpringの版のまま。独自の共通部品に、暗黙の条件（論理削除など）が隠れている。
ASP.NET WebForms・ASMX・WCF、C#・VB.NET、ADO.NET・ストアドプロシージャなど
.NET Frameworkのまま、画面のイベント処理やストアドプロシージャに業務のルールが埋もれている。
Apex・LWC・Visualforce、Flow・入力規則・数式項目など
作り込みが積み重なり、レコードを保存したときにどの処理がどの順で動くか分からない。
部門ごとにつくられたマクロやツール
部門ごとのツールが乱立し、つくった人にしか中身が分からない。
社内やデータセンターの仮想サーバで動くシステム
ソースの管理（Git）がなく、サーバ上のファイルだけが正しい版になっている。
言語・フレームワークの版や構成によって、対応の進め方は変わります。対象のシステムで設計書を試しにつくり、どこまで確かめられるかを最初に測ります。
02TARGET
どの方式を選んでも、目指すのはAIと一緒に変えていける状態です。
画面・バッチ・AIエージェントが、同じAPIを通して業務のルールを使います。
改修は設計書の更新から始め、設計書からコードを直します。
APIをAIエージェント連携基盤（iPaaS）につなぎ、業務の自動化に広げます。
03METHODS
サブシステムごとに、次の7つの方式から選びます。方式によって、AI-Ready設計書がどれだけ必要になるかが変わります。
| 方式 | 内容 | 向いている場合 | 設計書の必要度 |
|---|---|---|---|
| 継続Retain | 当面そのまま使い、保守の体制を整える | 安定していて、基盤のサポート期限に余裕がある | 中 |
| 廃止Retire | 使っていないので止める | 利用の実績がない、ほかの機能で代わりがきく | 低 |
| 置き換えReplace | パッケージやSaaSに替える | 業務が標準的で、独自の作り込みが少ない | 中 |
| 移設Rehost | 仮想サーバをそのままクラウドなどへ移す | 期限が迫っている、中身は変えたくない | 低〜中 |
| 基盤更新Replatform | ランタイム・DB・OSの版を上げ、コードの修正は最小限にする | 言語・フレームワークは使い続けられる | 高 |
| 改修Refactor | 同じ言語のまま、構造を直す | コードは使い続けるが、保守しにくい | 高 |
| 再構築Rebuild | 設計書から、別の言語・基盤で作り直す | 言語や基盤を替える必要がある | 最高 |
1つのシステムの中で、サブシステムごとに違う方式を選ぶこともできます。改修・基盤更新・再構築を選ぶ場合は、対象の設計書の可逆性検証で、元のシステムとの一致を確かめてから進めます。
MOREREAD NEXT
NEXTLET’S TALK
サービスに関するご相談をお待ちしています。
お問い合わせ