既存システムの仕様調査をAIで進める方法｜設計書がない・属人化した開発を引き継ぐには

担当していたエンジニアが退職し、システムの中身がわかる人がいなくなった。設計書は残っていない、あるいは残っていても実装と合っていない。既存システムの改修を検討したときに、この状態に突き当たる企業は少なくありません。

従来、こうしたシステムの仕様調査には多くの時間がかかりました。コードを1つずつ追って、何をしているのかを人力で読み解く必要があったからです。この工程にAIを使うことで、調査を現実的な工数に収められる場面が増えています。

この記事では、既存システムの仕様調査をAIで進める方法と、その際に何が変わり、何は変わらないのかを、実際に引き継ぎ改修を請け負っている側からまとめます。

既存システムの仕様調査が難しい理由

調査が進まない原因は、たいてい次のどれかです。

• 設計書がない、または更新されておらず実装と食い違っている
• 作った本人がいない（退職・委託先の変更）
• 長年の改修で例外処理が積み重なり、全体像が読み取れない
• どこまでが「使われている機能」なのか誰も判断できない

いずれも属人化が根本にあります。仕様が人の頭の中にしかなく、その人がいなくなった時点で情報が失われる構造です。

AIを使うと何が変わるのか

変わるのは調査にかかる時間です。コードを読み解いて何をしているかを整理する作業、処理の流れを図に起こす作業、機能の一覧を作る作業。これらをAIが下書きし、人が確認する形に置き換えられます。

当社では、既存システムの解析やコードリファクタリング、モダン環境へのリプレイスに対応しており、この工程にAIを取り入れています。定型的な読み解きと資料の整理をAIに任せ、人は全体設計と品質の作り込みに時間を使う体制です。

変わらないこと

一方で、AIに任せられない部分もはっきりしています。

「コードが何をしているか」はAIが読み取れますが、「その処理が業務上どういう意味を持つか」は、業務を知っている人でないと判断できません。ここを取り違えると、使われていない機能を丁寧に移植して、必要な機能を落とすことになります。

調査の進め方

1. 現物を揃える

まずソースコードとサーバー環境の情報が必要です。当社では引き継ぎのご相談を受ける際、仕様書またはサーバーのログイン情報のご提供をお願いしています。仕様書が残っていない場合も対応できますが、解析に時間をいただく形になります。

2. 全体像を先に作る

細部から読み始めると必ず迷います。機能の一覧と処理の流れという地図を先に作り、そのうえで重要な部分を深く読む順序が効率的です。この地図の下書きにAIが効きます。

3. 現行の挙動を「正」として記録する

ドキュメントがない以上、現在動いているものが唯一の仕様です。改修前に挙動を記録しておくと、リプレイス後の検証で比較対象になります。

4. 使われていない機能を切り分ける

長年運用されたシステムには、もう使われていない機能が残っていることがよくあります。ここを整理せずに移植すると、不要な工数と保守対象を抱え込みます。ここは業務側との確認が必須です。

調査だけを依頼することもできる

「作り直すかどうかを決めるために、まず中身を把握したい」という段階のご相談は少なくありません。この場合、調査を先に切り出して依頼する進め方が有効です。

調査の結果として、次のような判断材料が得られます。

• 機能の一覧と、現在使われている／使われていない機能の切り分け
• 処理の流れと、外部システムとの連携箇所
• 改修が難しくなっている原因（技術的な負債がどこにあるか）
• 改修で対応する場合と作り直す場合の、おおまかな規模感

ここまで揃うと、社内で予算を取る判断ができるようになります。当社では概算見積もりを無料でお出ししており、要件が固まっていない段階でのご相談にも対応しています。

費用と期間の目安

改修・リプレイスの費用は規模によって変わります。参考として、当社の費用レンジを公開します。

仕様書がない既存システムの場合、解析の工数が上乗せされます。ここを見込まずに見積もりを比較すると、後から追加費用が発生しやすくなります。見積もりの読み方についてはシステム開発会社の選び方で整理しています。

属人化を繰り返さないために

調査して終わりにすると、数年後に同じことが起きます。せっかく整理した仕様を残す仕組みが必要です。

AIを使うと、ドキュメントを作る負担そのものが下がります。従来は「書く時間がないから残せない」ことが属人化の原因でしたが、下書きをAIが担えるなら、更新を継続できる可能性が上がります。

あわせて、改修時に誰が対応するかも重要です。当社では開発したチームがそのまま運用・保守を担当し、初回の相談から運用後の改修まで担当が変わりません。引き継ぎのたびに解析からやり直す状態を避けるためです。

調査でよく見つかる問題

実際に既存システムを解析すると、次のような状態がよく見つかります。事前に知っておくと、見積もりの前提が理解しやすくなります。

同じ処理が複数箇所に散らばっている

改修のたびに似た処理が追加され、1つの仕様変更で何箇所も直す必要がある状態です。改修コストが下がらない原因の多くはここにあります。

使われていない機能が残っている

過去の要件で作られたまま、今は誰も使っていない機能です。これを整理せずに移植すると、不要な工数と保守対象を抱え込みます。業務側との確認が必須です。

データの持ち方が現在の業務と合っていない

運用の中で業務フローが変わり、当初の設計と実態がずれているケースです。この場合、画面だけ作り直しても課題は解決しません。データ構造から見直す判断が必要になります。

サーバー環境が古い

使用している言語やミドルウェアのサポートが終了しており、セキュリティ更新ができない状態です。この場合はアプリケーションの改修より、環境の移行を先に検討すべきことがあります。当社ではオンプレミスから AWS / GCP へのサーバー移行にも対応しています。

リプレイスを視野に入れる場合

調査の結果、改修を重ねるより作り直したほうが早い、と判断されることもあります。判断の材料になるのは次の点です。

• 使用している言語・フレームワークのサポート状況
• 改修のたびに影響範囲の調査に時間がかかっていないか
• サーバー環境が古く、セキュリティ更新が難しくなっていないか

当社では PHP / Laravel を主軸に、Next.js や NestJS を用いたモダン構成まで対応しており、レガシーからモダンまで技術選定の段階からご相談いただけます。オンプレミスから AWS / GCP へのサーバー移行にも対応しています。

まとめ

既存システムの仕様調査は、AIを使うことで所要時間を大きく圧縮できます。コードの読み解きと資料の整理をAIが担い、人は「この機能は必要か」「どこにリスクがあるか」という判断に集中する形です。

ただし、業務上の意味を判断できるのは人だけです。AIが調査を速くしても、何を残し何を捨てるかの判断は変わりません。

C-limber は2013年の設立から13年目、累計1,000件以上のプロジェクトに携わってきました。他社が構築したシステムの改修・保守引き継ぎに対応しており、仕様書が残っていないケースも解析から着手できます。ISMS（ISO/IEC 27001）認証、AWSセレクトティアサービスパートナーの認定を取得しています。

開発担当者が退職して困っている、既存ベンダーの対応が遅い、といったご相談も承っています。Webシステム開発のページに対応領域をまとめていますので、あわせてご覧ください。

調査だけのご依頼や、要件が固まっていない段階のご相談でも構いません。概算見積もりは無料です。お問い合わせからお気軽にご連絡ください。