SmartReplace
触れないシステムを、
動いているまま作り替える。
人手で何ヶ月もかけていたレガシー刷新を、AIと一緒に数日〜約1週間で。20年もののJavaのフル刷新、既存コード0行変更でのREST化、止まったAndroid/iOSアプリの再構築——構成図と実測値でご説明します。
What it is
人手で何ヶ月もかけていた刷新を、
AIと一緒に数日〜約1週間で。
SmartWork360 や SmartOptimizer は月額でお使いいただくSaaSですが、SmartReplace はお客様のシステムそのものを作り替える企業向けのSIです。レガシーの問題は昔から同じで、変わったのは作り替えにかかる時間とお金だけです。さらに刷新の過程で得た知見は SmartOptimizer で組織側に残せるので、次の改修が前回の判断から始められます。
Case Studies
実際に手を動かした6件。
人がやる場合と、何が違うのか。
いずれも当社が担当した案件です。各事例に構成図と、従来のやり方（人が読んで、人が直す）とAI駆動で進めた場合の違いを並べました。数値はGit履歴と実機からの実測値で、企業や環境が特定できない形に一般化しています。
CASE 01
20年もののJavaを、実働約1週間でフル刷新
稼働10年超・会員約2万人の会員制サービス。設計書はなく、当時の開発者も不在。「触れないから直せない」が固定化していた状態です。
従来のやり方（人が読んで、人が直す）
- 設計書がないので、まず読むことに数ヶ月。
- 読み終える前に担当者が変わると、また振り出しに戻る。
- 認証方式の変更は、全会員のパスワード再設定＝止めるか、告知して切り替えるかの二択になりがち。
AI駆動で進めた場合
- 解析と実装を同時に回すので、読む工程が実装に溶ける。
- 対象は会員向け全機能＋管理画面18種。実働約1週間で作り替え。
- SHA-1のパスワードはログイン時にbcryptへ自動で再ハッシュ。誰も止めずに安全になる。
CASE 02
既存コードを1行も変えずに、基幹システムをREST化
20年近く動いている販売管理の基幹システム。業務は毎日回っているので、全面刷新は業務影響が大きすぎて踏み切れない。そこで「作り替えない」を選びました。
従来のやり方（人が読んで、人が直す）
- 既存を理解してから改造する順番になり、触るほど壊れる不安が残る。
- 改造の影響範囲を洗い出す作業自体が大きく、着手前に止まりやすい。
- 「全部作り直す」以外の選択肢を、実物で確かめないまま捨ててしまう。
AI駆動で進めた場合
- 既存を読んだうえで、外側に薄い層を足すだけという選択が取りやすい。
- 既存クラスは1行も変更なし。触らないから壊れない。
- 前段は Java 21／Spring Boot。社内チャット基盤のアカウントでSSO。数日で本番E2Eが成立。
CASE 03 / 04
止まっていたAndroid・iOSアプリを作り直し、通知を復活させる
「アプリは動いている。ただ、通知だけが何年も届いていない」。落ちないまま、大事な機能だけが静かに止まっていた状態です。
従来のやり方（人が読んで、人が直す）
- 資料も担当者もいないアプリの再構築は、調査だけで見積もりが膨らむ。
- 署名鍵が見つからないとストアの既存アプリを更新できず、別アプリとして出し直しになりかねない。
- 「通知が飛ばない」原因の切り分け（アプリ側か、サーバ側か、配信基盤か）に時間を取られる。
AI駆動で進めた場合
- 調査と実装を並行できるため、原因の特定から作り直しまでが一本で進む。
- 2016年発行の署名鍵を引き継いだまま再構築。既存アプリの更新として配布でき、会員資産も維持。
- 古いサーバは入れ替えず、送信側だけを現行の仕組み（FCM）へ載せ替え。
CASE 05
サポート切れサーバから、社内システムを実働2日で救出
2016年のシステムが、2020年にサポートが終了したOSの上でインターネットに公開されたまま使われていました。1日20〜30リクエスト＝現役です。
従来のやり方（人が読んで、人が直す）
- 「動いているから触らない」が続き、誰も引き受けたがらない状態になる。
- 古い依存関係の解決に総当たりで時間がかかる。
- データ移行の検証（件数・添付の突き合わせ）を人手でやると、それだけで日数を使う。
AI駆動で進めた場合
- 環境差の切り分けを速く回せる。踏んだ8つの問題のうちアプリ起因は3つだけと分かった。
- 残りは10年分たまった周辺環境の差。ここに工数が集中することを前提に段取りできる。
- 移行後の件数突き合わせまで含めて実働2日。旧環境に無かった日次バックアップ（7世代）も用意。
CASE 06
1ヶ月かかる構成検討を、動くプロトタイプ2日に置き換える
レガシーを新しい基盤に移すとき、最初に来るのが構成検討です。従来は机上の比較表に約1ヶ月。その比較表が正しいかは、本番開発が始まるまで誰も確認できません。
従来のやり方（人が読んで、人が直す）
- 成果物は机上の比較表と概算。約1ヶ月かかる。
- 「選んだ構成が性能要件を満たさない」の発覚は、たいてい後戻りできなくなった頃。
- 検討のために人を張り付けるが、動くものは何も残らない。
AI駆動で進めた場合
- 現行を解析して画面14・機能45・項目527のロール別マトリクスと課題台帳46件に整理。
- 検討中の構成そのままで実働2日・約6.6万行の動くプロトタイプを構築。
- 1万件のデータで実測し、全API 22秒→3秒以内を確認してから構成を確定。検討の成果物が動くものとして残る。
※「従来のやり方」に挙げた進め方は、当社が請け負ってきた同種案件の体制感からの記述で、出典のある統計ではありません。期間や工数は業種・要件により変わり、再現性を保証するものではありません。数値のうち期間・行数・件数はGit履歴および実機からの実測値です。CASE 06 の「約1ヶ月」は、その案件で従来どおり進めた場合の見積もりです。
Track Record
1台のPCで、22システム・24.6万行。
エンジニア1人＋AIコーディングエージェント＋PC1台で、約3.5ヶ月に22システム・約24.6万行（446コミット）。推計ではなく、全Gitリポジトリのコミット履歴と実機からの集計です。従来の人月換算では10〜20人年に相当します。
How we do it
全部を捨てる必要はありません。
1. 現行システムを読む（無料）
設計書が無くても、ソースと実機から「何がどう使われているか」を読み取って一覧にします。
2. 作り替える範囲を決める
全部作り直すのか、既存に触らずREST化して段階移行するのか。CASE 01 と CASE 02 のどちらが合うかは実物を見てから決めます。
3. 動くプロトタイプで確認する
資料で議論する前に、触れるものをお見せします。性能は実データ規模で測ってから決めます。
4. 既存を止めずに並走させる
切り替えと旧環境の停止は別の日に分けます。データは件数を突き合わせて移します。
5. 知見を組織に残す
刷新中に調べたことと決めた理由を SmartOptimizer に残します。次の改修は、前回の判断から始められます。
Where it fits
こういう状態なら、ご相談ください。
- 開発した人がおらず設計書もない。触れる人がいないので直せない
- 保守費が高い。対応の順番待ちも長い
- APIが無いので周辺システムやAIエージェントとつなげない
- OSやライブラリのサポートが切れたまま、インターネットに公開されている
- アプリは動いているが、プッシュ通知や外部連携など一部の機能だけが静かに止まっている
まずは現行システムの解析までを無料で行います。考え方はなぜ今、モダナイゼーションが必要なのか、費用の見方はシステム開発は「投資」から「経費」へもあわせてご覧ください。
※本ページの事例は、実際の案件をもとに、企業や環境が特定できない形へ一般化しています。お客様名・案件名は掲載していません。SmartReplace は「AI Re:プラットフォーム」の新しいサービス名です。