サービス ／ AIモダナイゼーション支援
サービス
AIモダナイゼーション支援
自社開発のAIプラットフォーム「AVATAR」を活用し、レガシー資産を次世代の戦略的資産へと作り替えます。単なるシステムの入れ替えではなく、企業の成長を止めている技術的負債その場をしのぐ改修を重ねた結果、あとから手を入れるたびに余分な手間がかかる状態のこと。返済しないと利息が増えていく借金にたとえた言い方です。そのものを解消し、変化に強い基盤をつくることを目的としています。
背景
「2025年の崖」は、期限ではなく積み残しの量の問題です。
経済産業省が「DXレポート」で示した「2025年の崖」は、老朽化した基幹システムを抱えたまま推移した場合に生じる損失への警鐘として広く知られています。ただ、実務で問題になるのは特定の年そのものではありません。改修を重ねるたびに積み上がった負債が、ある時点から新しい取り組みそのものを止めてしまう。その構造こそが本当の課題です。
私たちは、この負債を一度に取り除くことをお勧めしていません。事業への影響が大きい範囲から、既存システムを動かしたまま順に解いていく。そのための順序と体制を、最初の分析段階で一緒に設計します。どこから手をつけるかが決まれば、刷新は現実的な計画になります。
こんな課題はありませんか
古い仕組みが、次の一手を止めている。
技術的負債の蓄積
度重なる改修でシステムが複雑になり、中身が見えないまま保守・運用コストだけが増え続けている。
人材とナレッジの不足
VB6や旧Java、ASP.NETを扱える技術者が減り、現行仕様を把握できる人がいなくなりつつある。
開発スピードの低下
一体化した構造のため、小さな変更でも影響範囲が読めず、市場の動きに合わせた改善が進まない。
クラウド活用の不足
移行は済んでいるが構成は以前のまま。拡張性や自動化といったクラウド本来の利点を活かせていない。
よくある課題下のボタンを押すと、段階ごとの様子を見られます
よくある課題は、古い街が一つの塊になった状態です。区画の境目も道もなく、一か所を直すと、どこに響くか分かりません。
現状分析は、再開発の前の「測量」です。どの区画が何をしていて、どこにつながっているかを、図面に起こします。
再設計は、新しい街の「計画図」です。区画の分け方と、切り替える順番を、お客様と合意します。
段階的刷新は、街を使いながら、一区画ずつ建て替えることです。既存のシステムを動かしたまま、決めた順に切り替えます。
定着・改善は、完成後の「街の見回り」です。新しい街が使われ方に合っているかを見守り、必要に応じて見直します。
用語の説明APIゲートウェイ建物でいえば「受付」にあたる、各サービスへの共通の入り口。外からの依頼を受け付けて、担当のサービスへ振り分けます。共有データ基盤複数のサービスが、同じデータを使えるようにするための土台。
考え方を示すイメージ図です。
進め方
一度に全部ではなく、順番に。
四つの段階で進めます。影響の大きい範囲から段階的に進める方法をご提案し、最初の分析で対象の優先順位を決めてから着手します。
各段階で、成果物をお渡しします。
カードは、お渡しする成果物のイメージです。実際の資料とは異なります。
-
01現状分析
稼働中のシステムとコードから現状を整理し、仕様書と業務フローを再構築するところから始めます。担当者が不在でも、現状を読める形に戻します。
- 仕様書と業務フローの再構築
- 現状の課題の整理
- 対象の優先順位の決定
成果物プレビュー現状分析と課題整理対象仕様書業務フロー着手順業務A1業務B2業務C3共通処理4現状が、読める形に -
02再設計
システムをどこまで分けるかは、拡張したい範囲と運用体制から決めます。移行後に誰が保守するかまで含めて、移行先の技術を選びます。
- 新アーキテクチャの設計
- 移行先の技術の選定
- 切り替えの範囲と順序の合意
成果物プレビュー新アーキテクチャ設計分け方が、決まった業務A業務B業務C共通処理どこまで分けるか誰が保守するか切り替えの順序 -
03段階的刷新
影響の大きい範囲から順に、既存システムを動かしたまま新しい構成へ切り替えます。移行期間中は並行運用新しいシステムが動き出したあとも、しばらく古いシステムを止めずに並べて動かしておくこと。切り替えの途中でも、業務が止まりにくくなります。を前提とし、AIによる変換結果は、エンジニアが確認したうえで反映します。
- AIによるコード変換と整理
- エンジニアによる確認
- テストの生成と動作の確認
成果物プレビュー刷新ロードマップ業務A業務B業務C共通処理旧並行運用新順に、切り替える -
04定着・改善
刷新して終わりにせず、移行後の運用を設計します。テストの生成と継続的な監視で品質を保ち、負債が再び積み上がることを防ぐ仕組みを整えます。
- 移行後の運用設計
- 継続的なモニタリング
- 負債を再び積み上げない仕組み
成果物プレビュー移行後の運用設計テストの生成運用中継続的なモニタリング運用中負債を再び積み上げない仕組み運用中品質を、保つ仕組み
提供内容
作り直すのではなく、順序を設計します。
ご提供は三つの柱で構成しています。アプリケーションの刷新とクラウドへの再設計は、お客様の状況に応じて単独でも組み合わせでもお選びいただけます。三つ目の「AVATAR」は、その二つを進めるための私たちの土台です。
01 アプリケーションモダナイゼーション
読めなくなった資産を、もう一度「生きた知識」に戻す。
VB6や旧Java、ASP.NETで書かれた資産を、保守と拡張に耐えるモダンな環境へ移します。作業の中心は書き換えそのものではなく、いま何がどう動いているかを取り戻すことです。仕様が読める状態に戻ってはじめて、移行の順序とリスクを判断できます。
言語・プラットフォーム移行
VB6・旧Java・ASP.NETなどから、Go／Kotlin／TypeScript／Modern Javaといった現行技術へ移行します。移行後に誰が保守するかまで含めて選定します。
現行資産の可視化
ドキュメントが残っていないコードから、仕様書と業務フローを再構築します。担当者が不在でも、現状を読める形に戻すところから始めます。
AIリファクタリングプログラムの動きは変えずに、中身を読みやすく整理し直すこと。
AIによるコード変換と整理で、読みやすさと保守しやすさを取り戻します。変換結果はエンジニアが必ず確認したうえで反映します。
一体化した構造は、すべての部屋の壁がつながった一つの大きな建物のようなものです。一か所を直すと、どこに響くかが読めません。
疎結合は、部屋ごとに独立した建物のような作りです。それぞれを、個別に改修できます。
切り出しは一度に行わず、影響の大きい範囲から順に進めます。移行期間中は既存システムとの並行運用を前提とします。
02 クラウドモダナイゼーション
移すだけで終わらせず、クラウドの利点まで取りに行く。
既存システムの価値を保ったまま、クラウドの特性を活かせる構成へ作り替えます。移行そのものが目的ではありません。運用の手間が減り、必要なときに増やせて、変更を安全に出せる状態になってはじめて、クラウドに移した意味が生まれます。
マイクロサービス一つの大きなシステムを、役割ごとの小さなシステムに分けて、それぞれ独立して動かす作り方のこと。化
一体化した構造を、独立して動く単位へ分けて設計し直します。どこまで分けるかは、拡張したい範囲と運用体制から決めます。
コンテナアプリを、動かすのに必要なものごと一つの箱にまとめる仕組み。環境が変わっても、同じように動かしやすくなります。基盤・IaCサーバーなどの構成を手作業で設定せず、設定ファイルとして書き残しておく方法。同じ環境を何度でも作り直せるようになります。
KubernetesやTerraformなどを用いて、AWS／Google Cloud上の環境構築を自動化します。構成をコードで残すことで、同じ環境を何度でも再現できます。
CI／CDソースコードの変更を、自動で検証し、公開まで届ける仕組みのこと。パイプライン
検証から公開までの流れを整え、変更を小さく安全に出せるようにします。リリースのたびに人手で確認していた作業を減らします。
クラウド環境の新規構築や、既存環境の運用・最適化のみをお求めの場合は、AWS / GCP クラウド導入・構築でも承っています。
03 AI駆動のアプローチ
AIとエンジニアの分担を、仕組みとして固定する。
「AVATAR」は、AIとエンジニアの協業を支えるために私たちが自社開発したプラットフォームです。AIに任せる範囲と、人が判断する範囲を毎回決め直すのではなく、あらかじめ仕組みとして定めておく。そのための土台と位置づけています。
- STEP 01コード解析現行資産を読み取る
- STEP 02仕様の再構築業務フローを起こす
- STEP 03コード変換現行技術へ書き換える
- STEP 04テスト生成・検証動作と品質を確かめる
AIハーネス層AIに任せる範囲や手順を、あらかじめ決めておくための土台となる仕組みのこと。
Knowledge Hub
開発の過程で得られた設計情報やノウハウを蓄積し、再利用できる形で共有します。解析した現行仕様もここに残ります。
AI Package & Agents
役割の異なる複数のAIエージェントが、コードや設計の分析、ドキュメントの生成を担当します。
Quality & Drift Control
テストの生成と継続的な監視により、品質を保ち、負債が再び積み上がることを防ぎます。
AVATARは私たちの開発を支える基盤です。お客様側での導入を前提とするものではありません。
特徴・強み
なぜ、NALにご依頼いただくのか。
自社開発のAIプラットフォームで進めること
コード解析、仕様書の再構築、リファクタリング、品質管理まで、AIとエンジニアが役割を分けて協業します。外部のツールを組み合わせるのではなく、自分たちで作り、自分たちで使っている基盤なので、案件ごとに手を入れられます。
日本市場に合わせた進め方
日本の商習慣と品質基準を理解したリーダーがプロジェクトを推進します。合意の取り方、報告の粒度、受け入れ確認の進め方まで、日本側の運用に合わせて設計します。
AI駆動開発（AIDD）の実践
単発のツール利用ではなく、開発工程全体にAIを組み込む方法を自社で実践しています。
アプリからクラウドまで一貫
アプリケーションとクラウド、どちらか一方でも、両方あわせてでもご依頼いただけます。
期待できる効果
刷新のあとに、何が変わるか。
ITコスト構造の改善
保守と運用に固定されていた予算を見直し、新規事業やDXへの投資に回しやすい構造にします。
デリバリースピードの向上
AIの活用とクラウドの自動化により開発サイクルが短くなり、必要な機能を必要な時期に出せるようになります。
ブラックボックスの解消
資産が読める状態に戻ることで属人化が解け、担当者が代わっても手を入れられる資産になります。
将来の変化への対応力
モダンな構成へ移ることで、利用者やデータの増加、事業の方針転換にも構成を変えて対応できます。
図は、考え方を示すイメージです。実際の数値ではありません。
対応技術
これまでに扱ってきた範囲。
Terraform
上記は代表例です。記載のない環境についても、まずは現状をお聞かせください。
よくあるご質問
ご相談前に、よくいただくご質問
ありません。影響の大きい範囲から段階的に進める方法をご提案します。最初の分析で対象の優先順位を決めてから着手します。
対応可能です。稼働中のシステムとコードから現状を整理し、仕様書と業務フローを再構築するところから始めます。
並行運用を前提とした計画を立てます。切り替えの範囲と順序を事前に合意したうえで進めます。
変換結果はエンジニアが確認したうえで反映します。あわせてテストを生成し、移行前後で動作が変わっていないことを確かめながら進めます。
