長年使われてきた既存システムでは、「仕様書がない」「設計書が古い」「実装とドキュメントが合っていない」といった問題が珍しくありません。
担当者がいるうちは何とか回っていても、異動や退職、外部委託、オフショア化、システム刷新のタイミングで、一気に問題が表面化します。
「この機能はなぜこう動いているのか」
「どこを変更すると、どこに影響するのか」
「そもそも、今の仕様は誰が分かっているのか」
こうした状態のままでは、既存システムの保守や改修は進めにくくなります。
特に、基幹システムや長年改修を重ねてきた業務システムでは、仕様の把握そのものが大きな負担になります。
AWS Summit Japan 2026では、生成AIやAIエージェントを活用したモダナイゼーション、コード分析、ドキュメント化に関する展示やセッションが多く見られました。そこで見えてきたのは、AIを使うことで、仕様が分からない既存システムの理解を支援し、引き継ぎや保守の土台を作りやすくなっているという流れです。
ただし、AIがすべての仕様を自動で完全に復元してくれるわけではありません。
重要なのは、AIを「正解を出すもの」としてではなく、人が判断できる状態に情報を整理するための支援ツールとして使うことです。
本記事では、仕様書がないシステムの引き継ぎで起きる課題と、AIを活用した仕様整理の可能性、そして進める際の注意点を整理します。
目次
仕様書がないシステムは、なぜ引き継ぎが難しいのか
既存システムの引き継ぎが難しくなる理由は、単にドキュメントが不足しているからではありません。
本質的な問題は、システムの仕様や判断基準が、人の記憶や暗黙知に依存していることです。
古いシステムほど、仕様が人の記憶に残りやすい
長年使われているシステムでは、最初の設計書や仕様書が残っていても、その後の改修内容が十分に反映されていないことがあります。
たとえば、以下のような状態です。
- 仕様書はあるが、10年以上前の内容で止まっている
- 改修履歴が担当者のメールや口頭説明にしか残っていない
- なぜその処理になっているのか、コードを見ても分からない
- 特定の担当者だけが、業務ルールや例外処理を理解している
- 障害対応や緊急改修が積み重なり、全体像が見えなくなっている
このような状態では、新しい担当者がシステムを理解するまでに時間がかかります。
また、外部ベンダーやオフショアチームに引き継ごうとしても、説明する側の負荷が大きくなり、結局「分かっている人が対応した方が早い」という状況になりがちです。
仕様書があっても、実装と乖離しているケースが多い
仕様書が存在していても、それだけで安心とは限りません。
長年の改修によって、仕様書と実装がズレていることはよくあります。
初期開発時の設計書は残っているものの、その後の機能追加や例外対応が反映されていない。担当者の判断で加えられた処理が、どこにも記録されていない。こうしたケースでは、仕様書を見ても現在のシステムの正しい姿は分かりません。
むしろ、古い仕様書を前提に改修を進めることで、想定外の不具合を起こすリスクもあります。
既存システムの引き継ぎでは、「ドキュメントがあるかどうか」だけでなく、「現在の実装や運用実態と合っているか」を確認する必要があります。
引き継ぎできない状態は、改修・保守・障害対応のリスクになる
仕様が分からない状態は、日々の保守だけでなく、事業上のリスクにもつながります。
影響範囲が分からないため、簡単な改修にも時間がかかる。
障害が起きたとき、原因調査に時間がかかる。
担当者が退職すると、誰も判断できなくなる。
新しい機能を追加したくても、既存システムに手を入れられない。
このような状態では、システムは動いていても、事業の変化に対応しづらくなります。
「古いけれど動いている」システムは、短期的には問題が見えにくいものです。
しかし、引き継ぎや改修ができない状態が続くと、保守コストの増加、開発スピードの低下、人材依存といった形で、少しずつ組織の負担になります。
AWS Summit 2026で見えた、AIによる仕様整理の可能性
AWS Summit Japan 2026では、生成AIやAIエージェントを使ったモダナイゼーション、コード分析、ドキュメント化に関するテーマが多く扱われていました。
特に印象的だったのは、AIを使って既存システムを理解し、仕様整理や引き継ぎの土台を作るという考え方です。
ソースコードから構造や処理内容を読み解く
既存システムの仕様整理で最初に必要になるのは、現在のシステムがどのように動いているかを把握することです。
従来は、担当者がソースコードを読み、関連する設計書や運用資料を探し、過去の改修履歴を確認しながら、少しずつ全体像を把握していました。
AIを活用すると、この理解作業を支援できます。
たとえば、ソースコードを解析し、処理の流れや依存関係を整理する。
特定の機能がどのファイルやモジュールに関係しているかを確認する。
コード上の処理内容を、人が読みやすい説明に変換する。
もちろん、AIの出力をそのまま正解として扱うことはできません。
しかし、最初の理解の土台を作るという意味では、従来よりも調査を進めやすくなる可能性があります。
ビジネスロジックを抽出し、ドキュメント化する
既存システムで本当に重要なのは、単なるコードの構造だけではありません。
その中に含まれている業務ルールや判断条件、例外処理などのビジネスロジックです。
たとえば、特定の条件では処理を分岐する。
特定の顧客区分だけ、別の計算ロジックを使う。
過去の運用上の都合で、例外的な処理が組み込まれている。
こうしたビジネスロジックは、システムが長く使われるほど複雑化しやすくなります。
そして、仕様書には書かれていないことも少なくありません。
AIを活用することで、ソースコードや関連資料から処理内容を読み解き、業務上の意味を整理し、ドキュメント化する支援が可能になりつつあります。
これは、既存システムを引き継ぐうえで大きな意味があります。
仕様が分からない状態から、少なくとも「どこに何が書かれているのか」「どの処理がどの業務ルールに関係しているのか」を整理できれば、新しい担当者や外部チームも理解しやすくなります。
チャット形式でシステム理解を進めるアプローチ
AIを使った仕様整理では、チャット形式でシステムについて質問しながら理解を進めるアプローチも考えられます。
たとえば、次のような確認です。
- この処理は何をしているのか
- この機能に関連するファイルはどれか
- この項目はどこで計算されているのか
- この条件分岐はどの業務ルールに関係しているのか
- この修正を行う場合、影響しそうな箇所はどこか
従来であれば、担当者がコードや資料を横断的に確認していた作業を、AIが補助する形です。
これにより、システム理解のスピードを上げるだけでなく、確認内容を記録として残しやすくなります。
結果として、属人的な調査作業を、チームで共有できる知識に変えていくことができます。
仕様書がない場合でも、理解の土台を作れる可能性がある
仕様書がないシステムでも、ソースコードやログ、運用資料、過去のチケット、障害履歴などが残っていれば、AIを使って理解の土台を作れる可能性があります。
重要なのは、最初から完璧な仕様書を作ろうとしないことです。
まずは、現行システムの構造を把握する。
次に、重要な業務ロジックを整理する。
そのうえで、影響範囲が大きい箇所や、属人化している箇所を特定する。
このように段階的に整理することで、引き継ぎや保守、外部委託を進めやすくなります。
ただし、AIだけで完全な仕様書ができるわけではない
AIによる仕様整理には大きな可能性があります。
一方で、過度な期待は禁物です。
AIは、与えられた情報をもとに整理や推論を行います。
そのため、情報として残っていないものは、正確に復元できません。
ソースコードに表れていない設計意図は復元しきれない
ソースコードを読めば、システムが現在どのように動いているかはある程度分かります。
しかし、「なぜその設計にしたのか」「なぜその例外処理が必要だったのか」「過去にどのような制約があったのか」といった判断の背景までは、コードだけでは分からないことがあります。
たとえば、過去の法改正対応、顧客との個別契約、当時の性能制約、運用上の暫定対応などです。
こうした情報は、設計書や議事録、チケット、担当者の記憶に残っている場合があります。
逆に、どこにも残っていなければ、AIであっても正確に復元することはできません。
AIができるのは、あくまで残っている情報をもとに理解を支援することです。
稼働情報や過去の判断履歴もあわせて確認する必要がある
既存システムを理解するには、ソースコードだけでなく、稼働情報や過去の判断履歴も重要です。
たとえば、実際にどの機能がよく使われているのか。
どのバッチ処理が重要なのか。
どの画面はほとんど使われていないのか。
過去にどのような障害が起き、どう対応したのか。
こうした情報を組み合わせることで、単なるコードの説明ではなく、業務上意味のある仕様整理につながります。
既存システムの引き継ぎでは、ソースコード、設計書、運用資料、障害履歴、チケット、担当者ヒアリングを組み合わせて、段階的に理解を深める必要があります。
ベテラン担当者が残っているうちにナレッジ化することが重要
AIを活用した仕様整理で特に重要なのは、ベテラン担当者が残っているうちにナレッジ化を進めることです。
長年そのシステムに関わってきた担当者は、コードや資料には残っていない背景を知っています。
なぜこの処理だけ例外になっているのか。
なぜこの画面は使われなくなったのか。
なぜこの機能は変更しない方がよいのか。
どの処理は触ると危ないのか。
こうした知識は、退職や異動によって失われやすいものです。
AIを使ってドキュメント化を進める場合でも、担当者の知識を補足しながら進めることで、より実態に近い仕様整理ができます。
つまり、AIはベテラン担当者の代わりになるというより、ベテラン担当者の知識を組織に残すための支援ツールとして使うべきです。
既存システムの引き継ぎでまず整理すべきこと
仕様書がないシステムを引き継ぐ際、いきなり全体を完璧に整理しようとすると、作業範囲が大きくなりすぎます。
まずは、優先度をつけて整理することが重要です。
対象システムと重要機能の棚卸し
最初に行うべきは、対象システムと重要機能の棚卸しです。
どのシステムが事業上重要なのか。
どの機能が日常業務に欠かせないのか。
どの処理が止まると影響が大きいのか。
すべての機能を同じ粒度で整理する必要はありません。
重要度の高いシステムや機能から優先的に整理することで、現実的に進めやすくなります。
ソースコード・設計書・運用資料の有無
次に、既存資料の有無を確認します。
- ソースコード
- 設計書
- 仕様書
- テスト仕様書
- 運用手順書
- 障害対応履歴
- 改修履歴
- チケット
- 議事録
- 担当者メモ
これらがどこにあり、どの程度使える状態なのかを確認します。
古い資料であっても、まったく使えないとは限りません。
初期設計の意図や過去の判断を知る手がかりになる場合があります。
一方で、資料が現行システムと合っていない可能性もあるため、実装や稼働状況と照らし合わせて確認することが必要です。
担当者しか知らない判断基準
既存システムでは、担当者しか知らない判断基準が残っていることがあります。
たとえば、改修時に必ず確認する箇所、触ってはいけない処理、過去に問題が起きた機能、特定顧客向けの例外ルールなどです。
こうした情報は、仕様書やコードには表れにくいものです。
引き継ぎでは、担当者へのヒアリングを通じて、判断基準や注意点を明文化することが重要です。
AIを使う場合でも、こうしたヒアリング内容をテキスト化し、関連するコードや資料と紐づけることで、より実用的なナレッジになります。
改修時に影響範囲が分からない箇所
既存システムの保守で大きな負担になるのが、影響範囲の確認です。
小さな修正に見えても、他の機能やバッチ、帳票、外部連携に影響する可能性があります。
影響範囲が分からないと、改修に時間がかかるだけでなく、テスト範囲も広がります。
AIを活用することで、コードの依存関係や関連処理を把握しやすくなる可能性があります。
ただし、業務上の影響まではコードだけでは判断できない場合があるため、人による確認と組み合わせる必要があります。
外部委託・オフショア化できる作業範囲
仕様整理が進むと、既存保守の一部を外部委託・オフショア化しやすくなります。
たとえば、調査、ドキュメント整理、テスト、定型的な改修、影響範囲確認などです。
一方で、業務判断や優先順位の決定、重要な設計判断は、日本側で担う必要があります。
すべてを丸投げするのではなく、AIで理解の土台を作り、人が判断し、外部チームが実行できる状態を作ることが重要です。
AI時代の既存保守は「属人的な熟練作業」から「再現性のある知識作業」へ
これまで既存システムの保守は、特定の担当者の経験や勘に依存しがちでした。
もちろん、熟練者の知識は非常に重要です。
しかし、その知識が個人の中に閉じている限り、組織として継承することはできません。
AIを活用することで、既存保守は少しずつ「属人的な熟練作業」から「再現性のある知識作業」へ変えていける可能性があります。
AIは正解を出すものではなく、理解の土台を作るもの
AIを活用した仕様整理で大切なのは、AIにすべての判断を任せないことです。
AIは、ソースコードや資料、ログ、チケット、ヒアリング内容をもとに、情報を整理し、関連性を見つけ、理解の土台を作ります。
そのうえで、最終的な判断は人が行う必要があります。
この機能は本当に使われているのか。
この処理は残すべきか。
この設計は今後も維持すべきか。
どこまで外部委託できるのか。
こうした判断には、業務理解や事業判断が必要です。
AIは、人の判断をなくすものではなく、人が判断しやすい状態を作るものです。
仕様整理が進むと、保守・改修・外部委託がしやすくなる
仕様整理が進むと、既存システムの保守や改修は進めやすくなります。
システムの全体像が見える。
重要な機能が分かる。
影響範囲を確認しやすくなる。
新しい担当者がキャッチアップしやすくなる。
外部チームに任せられる作業範囲が明確になる。
こうした状態になれば、既存保守は特定の人に依存し続けるものではなく、チームで分担しやすい業務になります。
特に、既存システムの保守負荷が新規開発を圧迫している企業では、仕様整理は単なるドキュメント作成ではありません。
開発体制そのものを見直すための第一歩です。
スマラボでは、既存保守の構造化と分業体制づくりを支援
スマラボでは、AI活用とベトナムオフショアを組み合わせ、既存システムの保守・解析・構造化を支援しています。
重要なのは、単に人手を増やすことではありません。
仕様や判断基準を整理し、日本側・オフショア側・AIがそれぞれの役割を担える状態を作ることです。
日本側は、業務判断や優先順位付けに集中する。
オフショア側は、実装、調査、改善、定型的な保守作業を担う。
AIは、情報の構造化、要約、影響分析、ナレッジ化を支援する。
このように役割を分けることで、既存保守を「誰かが我慢して回すもの」から、継続的に改善できる体制へ変えていくことができます。
まとめ
仕様書がないシステムを引き継ぐには、まず現在のシステムを理解できる状態にする必要があります。
AIを活用することで、ソースコードや資料、ログ、過去の対応履歴をもとに、システム構造や処理内容、ビジネスロジックを整理しやすくなっています。
ただし、AIだけで完全な仕様書ができるわけではありません。
コードや資料に表れていない設計意図、過去の判断、業務上の背景は、人の確認が必要です。
重要なのは、AIを使って「人が判断できる状態」を作ることです。
仕様整理が進めば、既存システムの保守・改修・引き継ぎ・外部委託は進めやすくなります。
そして、属人的な保守作業を、再現性のある知識作業へ変えていくことができます。
古いシステムを安全に引き継ぎ、今後の開発体制を見直すためにも、まずは既存システムの現状整理から始めることが重要です。