01
基幹システム刷新前の現行調査
刷新前に、構造・仕様・業務ルール・リスクを可視化します。
- 基幹システム更改を検討している
- 現行仕様が整理されていない
- どこから置き換えるべきか分からない
SpecLift
AI Modernization Readiness Platform
SpecLift誰も中身を知らない既存システムを、AIで刷新できる状態へ。
ソースコード・DB・SQL・設計書を解析し、仕様、業務ルール、影響範囲、テスト観点、移行判断を根拠付きで生成。AI刷新の前に、現行を“読める材料”へ変えます。
塩漬けの仕様、絡み合うDB、退職した担当者。そのブラックボックスに、解析の光を入れる。
まずは1機能・1サブシステムから診断可能です。
対応開始領域
- Java / Spring系業務システム
- SQL / RDB
- バッチ処理
- Excel / Word / PDF設計書
- Git / ZIP ソースコード
- 画面・API・DB・バッチ依存解析
The Problem
AIで刷新したい。
でも、現行システムの仕様が分からない。
レガシー刷新の最初の壁は、コードを書くことではありません。現行が何を守って動いているのか、誰も断言できないことです。
- 01
仕様が消えている
設計書は古い。担当者は異動した。ベンダーに聞かないと判断できない。
- 設計書と実装がズレる
- 仕様を知る人がいない
- 自社で中身を判断できない
- 02
つながりが見えない
DB、SQL、API、バッチが絡み合い、1つの変更がどこへ波及するか分からない。
- 影響範囲が追えない
- DB・SQL・バッチが複雑
- 置き換え順序を決められない
- 03
現行挙動を守れない
AIに旧コードを読ませても、業務ルールとテスト観点が不足すれば移行品質は担保できない。
- 業務再現が不安
- テスト観点が不足
- 移行後の差分が怖い
AIで新システムを作る前に、まず
AIが理解できる「現行システムの材料」を作る必要があります。
Why It Matters
AI刷新の成否は、モデルの性能だけではなく、
AIに渡す「現行理解の質」で決まる。
AIは画面もAPIもテストコードも作れます。けれど、守るべき現行仕様を渡せなければ、速く作った新システムは正しく動きません。
旧コードをそのまま渡すだけでは足りません。SpecLiftは、AIが扱える「構造化された現行理解」を先につくります。
本当に難しいのは、これらを正しく理解すること。
- 01現行業務は、どんな条件で動いているか
- 02守るべき業務ルールは、どこに埋もれているか
- 03DB項目の変更は、どの画面・API・バッチへ届くか
- 04どの機能から始めれば、リスクを抑えられるか
The Platform
SpecLiftは、AI刷新のための
「現行システム解析基盤」です
コード・SQL・DB・設計書を解析し、ブラックボックス化した既存システムを、刷新に使える5つの材料へ変換します。
- ソースコード
- SQL
- DB定義
- 設計書
SpecLiftが作るのは、読むためだけのドキュメントではありません。AIによる設計・実装・テスト・移行に渡せる、根拠付きの刷新材料です。
What SpecLift Delivers
現行システムを、4つの刷新材料に変える
読む、辿る、守る、渡す。刷新前に必要な材料を、根拠付きで揃えます。
01System Map
全体像を、地図にする
画面・API・Service・SQL・DB・バッチ・外部連携の依存関係を可視化。どこから調べ、どこから刷新するかが見えます。
- 依存関係グラフ
- Mermaid / PDF構成図
- API・DB・バッチ・外部連携一覧
02As-Is Spec & Rules
いま動いている仕様を、再生成する
コード・SQL・DBから現行仕様と業務ルールを根拠付きで抽出。古い設計書との差分も確認できます。
- Markdown / PDF / Word仕様書
- 業務ルール一覧
- 根拠ファイル・行番号・レビュー状態
03Impact & Test
変更の波及とテストを、先に押さえる
変更対象から、影響する画面・API・バッチ・DB・テスト対象を提示。現行挙動を守るテスト観点までつなげます。
- 影響範囲レポート
- 影響度と確認対象
- Excel / Markdownテスト観点
04AI Context
AIへ渡せる形に、束ねる
複雑度・DB依存・リスクから置き換え優先順位を診断し、AI設計・実装・テストに使える Context Bundle を生成します。
- 移行リスク診断
- 低リスクPoC候補・段階移行案
- AI刷新用 Context Bundle
Before / After
旧コードをAIに投げるだけでは、刷新は止まる
SpecLift なし
- 現行仕様が曖昧なまま新設計する
- 業務ルール・DB依存を見落とす
- テスト観点が不足し、移行判断が止まる
SpecLift あり
- 現行システムを System Graph 化
- 仕様・業務ルール・影響範囲を根拠付きで整理
- テスト観点と AI刷新用コンテキストまで生成
刷新の前に、AIが迷わない現行理解を整える。
How It Works
なぜ、根拠付きで解析できるのか
AIに丸投げしません。静的解析、SQL解析、DBリネージ、System Graph、LLM推論、根拠検証を組み合わせて、現行システムを構造化します。
旧システムの中で、何がつながっているか。
静的解析とAI推論を分けて考え、先に構造を掘り起こす。だから、仕様も影響範囲も「どこから言えるのか」をたどれます。
AIに丸投げしない。
コード・DB・設計書を構造化した上で、AIに推論させる。だから根拠をたどれる。
live analysis
ソースコード・DB・設計書を取り込む
- 01取り込むソースコード・DB・SQL・設計書
- 02抽出するクラス、API、SQL、画面項目、業務用語
- 03つなぐ画面・API・DB・バッチを System Graph 化
- 04推論する仕様、業務ルール、影響理由を生成
- 05根拠を残す出力に根拠を付け、レビュー済み成果物へ
Use Cases
現行理解が必要な場面で、最初の一手になる
刷新前調査、AI刷新PoC、影響分析、仕様書再生成、SIer提案支援まで。現行理解の初稿をそろえます。
02
AIによるシステム刷新PoC
AIに渡す現行仕様・業務ルール・テスト観点を整えます。
- AIでシステム刷新を試したい
- 旧コードをAIに読ませるだけでは不安
- 現行挙動を守った刷新をしたい
03
改修時の影響範囲分析
変更が届く画面・API・バッチ・テスト対象を根拠付きで提示します。
- 改修時の影響漏れが怖い
- 影響調査に時間がかかっている
- ベテラン依存を下げたい
04
設計書・仕様書の再生成
古い設計書に頼らず、いま動く仕様を実装ベースで再生成します。
- 設計書が古い
- 引き継ぎ資料がない
- 保守担当者の立ち上がりに時間がかかる
05
SIerのレガシー保守・刷新提案支援
現行調査・影響分析・テスト設計・移行診断の初稿を標準化します。
- レガシー刷新案件を多く抱えている
- 調査工数を削減したい
- 若手でも保守案件に参加できる状態を作りたい
Diagnostic Package
まずは1機能・1サブシステムから診断できます
いきなり全システムを預ける必要はありません。影響範囲が限定された1機能から、AI刷新に使える材料を生成します。
Package
AI現行システム可視化診断
診断対象の例
- 受注管理の一部機能
- 承認ワークフロー
- 請求バッチ
- 顧客管理機能
- 在庫引当処理
- 既存API群
- DB変更予定のサブシステム
ご提供いただく入力データ
- ソースコード
- DB定義
- SQL
- 既存設計書
- 代表的な変更要望
- 既存テストケース
- システム概要資料
診断でお渡しするもの
見える
- システム構成マップ
- 現行仕様書ドラフト
- 業務ルール一覧
- DB・SQL依存関係
守れる
- 代表変更の影響範囲分析
- テスト観点一覧
- 移行リスク診断
進める
- AI刷新用 Context Bundle
- 今後のAI刷新ロードマップ案
範囲・データ・進め方は初回相談ですり合わせます。
AI現行システム可視化診断について相談するSecurity & Trust
ソースコード・設計書を扱う前提のセキュリティ設計
企業のソースコード・DB定義・設計書を扱うため、セキュリティ、監査性、レビュー可能性を前提に設計しています。
AIに任せきるのではなく、根拠とレビューを前提に、企業で使える解析基盤を提供します。
学習利用しない
顧客データをモデル学習に利用しない前提で扱います。
原則 read-only
Git連携や本番DBへの操作は、読み取りを基本に設計します。
根拠を必須化
AI出力には根拠を付け、人間レビューを前提にします。
分離・監査・マスキング
顧客ごとのデータ分離、ログ化、秘密情報スキャンを想定します。
Why SpecLift
単なるAIチャットでも、単なるコード解析でもありません
汎用AIチャット
根拠が弱く、依存関係をたどれない
System Graph と根拠付きAIで解析
通常のRAG
文章検索はできるが、影響範囲に弱い
Graph探索・SQL解析・DBリネージを併用
静的解析ツール
技術構造は見えるが、業務仕様化が弱い
LLMで仕様・業務ルール・テスト観点を生成
コード変換ツール
変換前の現行理解が不足しやすい
刷新前の現行理解・移行材料を生成
手作業調査
時間がかかり、属人化しやすい
AIと解析基盤で初稿生成・標準化
SpecLiftの領域は、AI刷新の前工程。現行理解を構造化し、次の設計・実装・テストへ渡します。
Process
最初の一歩は、小さく始める
相談
対象システム・刷新予定・現在の課題・利用可能なデータを確認します。
範囲を絞る
1機能・1サブシステムなど、PoCに適した診断範囲を決めます。
取り込む
ソースコード、DB定義、SQL、設計書、代表的な変更要望を取り込みます。
解析する
静的解析、SQL解析、DBリネージ、設計書解析、AI推論で成果物を生成します。
つなげる
診断レポートを確認し、Context Bundle からAI刷新PoCへ進めます。
FAQ
よくあるご質問
SpecLift
Get Started
AIで刷新する前に、まず現行システムを
AIが理解できる状態にしませんか。
ブラックボックス化した既存システムを、根拠付きの仕様・業務ルール・影響範囲・テスト・移行判断材料へ。まずは1機能・1サブシステムから始められます。
刷新前調査・影響範囲分析・仕様書再生成だけのご相談も可能です。