DEVELOPER’s BLOG

技術ブログ

システムリプレイスの進め方ーAI駆動開発で"触れないシステム"を再構築する方法

2026.05.18 深川 愛子
生成AI
システムリプレイスの進め方ーAI駆動開発で


  1. はじめに
  2. 開発フローと注意点
  3. まとめ


1.はじめに

現在、多くの企業で「今動いているシステムをどうするか」という課題に直面しています。長年使い続けてきたシステムは、業務に深く根付いている一方で、技術的な老朽化やブラックボックス化が進み、手を入れること自体が難しくなっているケースも少なくありません。既存システムの設計書や仕様書が存在しない、"触れないシステム"が現場に残り続けているのが実情です。

しかし一方で、こうしたシステムは企業にとって重要な業務データやノウハウの塊でもあります。単純な作り直しではなく、「既存の資産を活かしながら、より良い形へと進化させる」ことが求められています。こうした背景の中で、AIを活用したシステムリプレイスが注目されています。AIに、人間が時間をかけて行っていた解析・整理・確認作業を担わせることで、既存資産を理解・再構成しながら、システムを進化させることが可能になります。

本記事では、AIを活用したシステムリプレイスの考え方と、その具体的なアプローチについて紹介していきます。


2.開発フローと注意点

本章では、システムリプレイスにおけるAI駆動開発の流れと、各フェーズのポイントを解説します。

AIは膨大なコードやデータを読み解き、構造を整理し、改善のヒントを導き出すことを得意としています。特に、既存システムを理解し、再構成していくプロセスにおいて、その力を大きく発揮します。

【前提】

AI駆動開発では、AIが要件や仕様を理解できるように、「AIが参照しやすい形」で情報を蓄積することが重要です。

特に、マークダウン形式のデータはAIが構造を解釈しやすいため、要件管理には Backlog などのマークダウン形式で保存できるツールを活用することをおすすめします。 本記事では、Backlogに蓄積された要件情報をMCPサーバー経由でAIと接続し、業務・要件・コードを分断しない形で開発を進める構成を前提としています。


2-1. 分析フェーズ:レガシーシステムを理解する

分析フェーズでは既存のソースコード(レガシー)を起点に、システムの構造、挙動を把握します。

AIを活用することで、

  • システムの機能・処理内容
  • 画面構成・画面遷移
  • データ構造・項目定義


といった情報を抽出し、現行システム仕様書として整理します。これにより、ブラックボックス化していたシステムの全体像を可視化することが可能になります。

さらに、AI開発用のルールや観点をまとめた「スキル(AI向けルール定義)」を活用することで、

  • 不要な機能の洗い出し
  • 問題点の指摘
  • 改善案の提示


までを同時に実行しています。最初にスキルを完璧な状態にしなくても、ある程度の状態で開始して、運用しながら改善することも可能です。従来は、「現状を理解する工程」と「改善を検討する工程」を分けて進めるケースが一般的でした。AIを活用することで、現行システムの理解と改善の方向性検討を同時に進めることが可能になります。

ただし、外部システム連携や業務上の運用ルールなど、コードから読み取れない情報は含まれません。そのため、後続フェーズで補完していく必要があります。


2-2. 仕様フェーズ:現行仕様から新仕様へつなげる

分析フェーズで現行システムの理解が進んだ後、新しいシステム仕様書を作成します。このフェーズでは、以下の情報を統合します。

  • 現行システム仕様書
  • Backlogに蓄積された要件
  • 業務フロー情報


特に重要となるのが業務フローの整理です。

業務フローが属人化している場合、人によって認識が異なっていたり、システムと実際の運用が一致していないケースも少なくありません。そのため、必要に応じて業務フローを可視化し、関係者間の認識を整理していきます。

これにより、

  • 要件の明確化
  • 関係者間の認識の統一
  • 開発意思決定の迅速化


が実現され、プロジェクトの円滑な進行につながります。

ここで重要なのは、「業務フローを作ること」ではなく、既存の情報を活かしながら最適な形に整理することです。


2-3. 実装準備フェーズ:テストと実装計画を整える

仕様が整理できたら、次にテスト仕様書と実装計画を作成します。2−2で作成したシステム仕様書をもとにAIがテスト仕様書を作成します。

これにより、

  • 仕様の抜け漏れを網羅的に検出
  • 人では見落としがちな観点の補完
  • 作業時間の削減


が可能になります。人がミスしやすい「網羅性の担保」をAIが担います。さらに、システム仕様書とテスト仕様書をもとに、実装計画を作成します。

機能が大きい場合は、「スライス」と呼ばれる単位で分割し、「まずはここまで作る」、「次にここを実装する」といった具体的な開発ステップに落とし込みます。このフェーズの本質は、実装しやすい状態をつくることです。AIが計画や分割を担うことで、人間は判断に集中できる状態になります。


2-4. 実装フェーズ:AIが作成し、人が判断する

実装フェーズでは、バックエンド・フロントエンドの開発と並行して、テスト仕様書に基づく検証を行います。また、コーディング規約や開発ルールのチェックもAIが自動で実行します。

これにより、

  • チェック漏れの防止
  • レビュー工数の削減
  • 品質の均一化


が実現されます。

ここで重要なのは、AIは「人ができないこと」を代替しているわけではないという点です。人がやると時間がかかる/抜け漏れが発生する、といった作業をAIが担うことで、

  • 仕様の妥当性の判断
  • ビジネス的な意思決定
  • 最終的な品質判断


といった、人間の強みがより発揮される構造になります。AIは人を置き換えるのではなく、人の強みを引き出すための仕組みです。

最終的なレビューは人間が行いますが、AIによる事前チェックがあるため、短時間で本質的な確認に集中できます。また、AIレビューを行う場合は、新しいセッションで実施することで、より客観的で精度の高い評価が可能になります。


3.まとめ

本記事では、システムリプレイスにおけるAI駆動開発の進め方を、分析・仕様・実装準備・実装の各フェーズに分けて解説しました。

特に重要なポイントは以下の3点です。

  • ソースコードから仕様を再構築し、「分からない状態」から脱却できること
  • テスト・計画・チェックといった工程をAIが担うことで、開発の土台を整えられること
  • 人間が判断や意思決定といった、本来の強みに集中できる構造を作れること


従来のリプレイスは、「全てを人が理解し、設計し、作り直す」ことが前提でした。しかしAI駆動開発では、「AIが理解と整理を担い、人が判断する」という役割分担に変わります。

この変化により、これまで手が出せなかったレガシーシステムにも、現実的なアプローチが可能になります。システムリプレイスにおいて重要なのは、すべてを作り直すことではなく、既存の資産を理解し、活かしながら進化させることです。

また、Backlogに蓄積された(マークダウン形式で蓄積された)要件とAIを接続することで、業務・要件・コードが分断されない状態を実現できます。これは単なる開発効率化ではなく、業務とシステムを一体として捉え直すアプローチです。

重要なのは、AIを導入することではなく、AIが自然に機能する構造をどう設計するかです。その設計こそが、これからのシステム開発における競争優位になると考えられます。

システムリプレイスにおいて、「現行システムが理解できない」「仕様が不明確で進められない」といった課題をお持ちの場合は、お気軽にご相談ください。

AUCへのお問い合わせ 



X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

AWS Japan様と共催ワークショップ AIエージェントText2SQLでデータ分析

アマゾンジャパン品川オフィス3階 森のようなアトリウム はじめに Text2SQLとは ワークショップの内容 参加者の声 PoCから本格導入まで 1.はじめに 営業担当から突然、「この商品の半年分の売上推移のデータください」と言われ、思いがけないタイミングでデータ集計に時間を取られてしまう--。そんな依頼を様々な部署から受け、毎日追われている、というご経験がある方もいらっしゃるのではないでしょうか? こうした課題を解決する手段として注目

記事詳細
AWS Japan様と共催ワークショップ AIエージェントText2SQLでデータ分析
AWS 生成AI
PoCでは動いた生成AIが本番直前で崩れる理由 ― few-shotの限界 ―

はじめに 生成AIプロジェクトで起きがちなこと リリース前に起きる問題とよくある対応 本質的に必要なアプローチ おわりに 1.はじめに 「PoCではうまくいっていたのに、本番が近づくと急に問題が噴出する」 いくつかの生成AI案件を進める中で、この現象には共通する構造があることに気づきました。PoCでは「使えそう」だったものが、本番直前で「このままでは出せない」と判断されるのです。 原因はモデルの性能不足だけではありません。 多くの場合

記事詳細
PoCでは動いた生成AIが本番直前で崩れる理由 ― few-shotの限界 ―
コラム 生成AI
AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ

目次 はじめに Kiroについて 実際に触ってみた 感想 おまけ 1. はじめに AIを使用してコーディングする場面を思い浮かべてください。 コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか? 他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、 他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど

記事詳細
AWS Kiro Spec駆動開発とは - AIとの対話を構造化する新しいアプローチ
体験記 生成AI
コード生成を安定させる3つのポイント:設計書・指示の出し方・セッション管理

はじめに ポイント1:設計書を書いてもらいましょう ポイント2:Geminiを使うときの指示の出し方 ポイント3:自分で修正したら「読み直して」と必ず伝える まとめ はじめに 生成AIを使ってコード生成や修正を行うことは、もはや特別なことではなくなってきました。 Gemini や CodeX、Copilot、Cursor など、選択肢も増え、「うまく使えばかなり楽になる」という実感を持っている方も多いと思います。 一方で、実際に使い込

記事詳細
コード生成を安定させる3つのポイント:設計書・指示の出し方・セッション管理
コラム 生成AI

お問い合わせはこちらから