ソースコードから仕様書をAIで作成する：何がどこまで出るか、費用と依頼前の判断基準

長年動いているシステムの仕様書を作り直したい。保守を任せてきた担当者が退職する、監査でシステムの説明資料を求められた、次のベンダーに見積を依頼したいのに渡せる資料がない。きっかけはさまざまですが、共通しているのは「ソースコードはあるが、それを読める人が社内にいない」という状況です。

AIを使えばソースコードから仕様書を作れる、という話は目にするようになりました。ただ、その多くはエンジニアが自分の手元でAIツールを使う話で、発注する側が知りたい「何がどこまで出るのか」「出ないものは何か」「いくらかかるのか」には答えていません。この記事では、既存システムの仕様書化を外部に依頼する立場で、AIが起こせる仕様書の種類と精度、人の確認が必要な部分、費用と納期の考え方、依頼前に決めておくことを整理します。仕様書がないまま移行する場合の進め方は仕様書がないシステムはAIで移行できる？で扱っているので、そちらもあわせてご覧ください。

仕様書化の依頼が出てくる5つの場面

仕様書を作り直す必要が出てくる場面は、おおむね5つに分かれます。

保守の引き継ぎがもっとも多いきっかけです。長年システムを見てきた担当者が退職や異動で離れるとき、後任が頼れる資料がないと、小さな改修にも調査から入ることになります。担当者が在籍しているうちに、頭の中にある知識をコードと突き合わせて文書にしておきたいという相談です。

監査や内部統制への対応も、仕様書が急に必要になる場面です。システムがどのデータをどう処理しているか、誰がどの操作をできるかを説明する資料を求められたときに、実装と食い違った古い設計書しかなければ説明がつきません。

ベンダーの変更では、現在の保守会社から次の会社へ引き継ぐ際に、引き継ぎ資料として仕様書が要ります。相見積を取ろうにも、システムの規模や構成を示す資料がなければ各社とも概算すら出せません。

システム移行の前提として仕様書を整えるケースもあります。移行の見積根拠を明らかにするため、あるいは移行先の要件を整理するために、現行の仕様を先に把握しておきたいという考え方です。もっとも、この場合は仕様書化を単独で先に行うのが最善とは限りません。理由は後述します。

最後に、M&Aや事業承継です。譲り受ける事業がどんなシステムで動いていて、外部サービスやライセンスに何を依存しているかを短期間で把握しなければならず、コードから全体像を起こす作業が発生します。

目的が違えば、必要な仕様書の種類も粒度も変わります。この点は依頼前の判断として後半で整理します。

AIがソースコードから起こせる仕様書と、その精度

生成AIがソースコードを読んで文書にできるようになったことで、仕様書化の前提は変わりました。従来のリバースエンジニアリングツールが出力するのは、モジュールの呼び出し関係やCRUD図(どの機能がどのデータを作成・参照・更新・削除するかの一覧)といった構造情報でした。生成AIはそれに加えて、「この処理は受注金額から得意先ごとの割引率を差し引き、締め日を過ぎていれば翌月に計上している」というように、処理の意味を文章で説明できます。読む側にプログラミングの知識が要らない仕様書を出せるようになった、というのが一番の違いです。

とはいえ、仕様書の種類によって自動で出せる度合いは異なります。当社が扱う範囲で整理すると次のようになります。

機能一覧、データ項目定義、呼び出し関係と影響範囲は、コードとデータベース定義の中に答えがほぼすべて書かれているため、AIで網羅的に起こせます。数百画面の規模でも全ファイルを機械的に読むため、人の目で拾うより漏れが出にくいのも利点です。

画面・帳票仕様は、項目の一覧、必須や桁数といった入力チェック、画面の遷移先まではコードから出せます。ただしレイアウトや帳票の見た目は、実際の画面や出力サンプルと突き合わせて仕上げます。処理フローは条件分岐や計算式、データの更新順序を文章化できますが、例外的な分岐がなぜ存在するのかは説明できません。外部インターフェースも、こちら側から何を送り、何を受け取っているかは出せる一方、相手システム側の仕様や運用上の取り決めはコードの外にあります。

精度について正直に言えば、AIが出した仕様書は「大半は正しいが、確認が必要な箇所に印が付いた状態」で出てきます。出力をそのまま正本にするのではなく、コードとの突き合わせと人のレビューを経て確定させる工程が必ず要ります。この工程を省いた仕様書は、後で読む人を誤らせる資料になります。

AIでは出ないもの

出ないものをあらかじめ知っておくと、納品物への期待と実物のずれを防げます。

業務上の意図。 コードに書かれているのは何をしているかであって、なぜそうしているかではありません。「取引区分が9の得意先を一覧から除外している」という事実は書けても、区分9が何を意味し、今も必要な除外なのかは、業務を知る人にしか答えられません。

不具合と仕様の区別。 納品日が受注日より前でも登録できてしまう挙動は、入力チェックの漏れかもしれませんし、先に納品して後から受注を起票する業務が実際にあるのかもしれません。AIはこの挙動を「そうなっている」と書くことはできますが、正しいかどうかは判断しません。当社ではAIが勝手に正しそうな形へ直すことはせず、確認事項として一覧にします。

画面設定にしか存在しないロジック。 Accessや帳票ツール、ローコード製品のように、処理の一部が画面やツールの設定として保存されているシステムでは、コードとして取り出せない部分があります。実際の動作を確認しながら人が補います。

外部部品の中身。 市販のライブラリやDLLの内部処理は、そのソースコードがない限り解析の対象外です。呼び出している事実と渡している値までは記録し、部品の挙動は製品仕様やテストで確認します。

これらは仕様書の中で「確認事項」として明示し、業務担当者に答えてもらって埋めていきます。どこまで埋めるかで人の工数が変わります。コードに書かれた事実を整理するまでなら作業の大半はAIで済みますが、業務上の意味まで書き込んだ仕様書を求めるなら、担当者へのヒアリングと読み合わせの時間が上乗せになります。仕様書の粒度をどこまで求めるかは、費用に直結する判断です。

費用と納期はどう決まるか

人手で仕様書を起こす場合、見積はソースコードの行数や画面数あたりの単価で組まれるのが一般的です。エンジニアがコードを読んで書く作業が中心なので、規模に比例して人月が積み上がります。AIを使う場合はこの「読んで書く」部分の工数が大きく減り、人の工数は確認と意味づけに集中します。したがって費用は、規模そのものよりも「どこまで人の確認を求めるか」で決まる度合いが大きくなります。

費用を左右する要素を整理すると次のとおりです。

当社では、移行を伴わない解析・仕様書化単体のご依頼にも対応しており、費用は規模と目的により数十万円から数百万円の範囲です。ソースコードの一部を解析し、出せる仕様書の種類と粒度、確認事項の量を見たうえで概算をご提示します。行数だけでは決まらない見積の内訳と根拠の読み方はマイグレーションの見積方法で解説しています。

納期については、AIが解析して暫定仕様書を出すまでの時間は、人がコードを読む場合と桁が違います。全体の期間を左右するのはむしろ、確認事項への回答と読み合わせにお客様側でどれだけ時間を割けるかです。担当者が週に1回しか時間を取れなければ、確認の往復がそのまま期間になります。依頼の際は、確認に協力できる人と時間の目安を先に決めておくと、納期の見込みが立ちやすくなります。

依頼前に判断しておくこと

仕様書一式をすべて最高の粒度で作ろうとすると、費用も期間も膨らみます。目的に応じて優先する種類と粒度を絞るのが現実的です。

移行を予定しているなら、仕様書化を先に単独で行うかどうかも考えどころです。仕様書を完成させてから移行に入るより、移行の中で仕様を復元しながら進めるほうが早く済むことが多くあります。先に作った仕様書を移行時にもう一度検証することになり、二度手間になるからです。当社のAIマイグレーションでは、移行の成果物として最新コードに対応した仕様書が残ります。一方で、移行できるかどうかをまず判断したい、移行先の要件を先に整理したい、という場合は、仕様書化と依存関係の整理を先行させることに意味があります。難易度が高い言語や構成の案件では、当社もまず仕様書化と依存関係整理を行ってから移行可否を診断しています。

ソースコードを社外に出せるかどうかも、依頼前に確認しておく点です。AIで解析する以上、ソースコードをAIが動く環境に置く必要があります。社内規程で持ち出しが制限されている場合は、委託先の作業環境を先に確かめてください。当社では当社が管理するクラウドAI基盤のほか、お客様のAWSやAzure環境内に専用環境を構築する方式にも対応しています。学習利用の有無や委託先への確認点はソースコードを生成AIに渡して大丈夫かにまとめています。

もう一つ、仕様書の書式です。自社に既存の設計書テンプレートがあるならそれに合わせるのか、委託先の標準書式でよいのか。監査向けに様式が指定されている場合も同様です。後から書式を変えると整形のやり直しになるため、最初に決めておきます。

依頼側が用意するもの

仕様書化の依頼に、既存の設計書は必要ありません。用意していただきたいのは次の4点です。

ソースコード一式。 本番で動いているものと同じバージョンを揃えてください。バージョン管理されていないシステムでは、開発用のコピーと本番サーバー上のコードが食い違っていることがよくあります。迷ったら本番から取得したものが正です。

データベース定義。 テーブル定義書があればそれを、なければデータベースから構造情報を出力したものを用意します。個人情報を含む実データは必要ありません。構造がわかれば解析できます。

動く環境か、画面と帳票の実物。 実際に操作できる検証環境があると、画面仕様やレイアウトの確認が正確になります。環境を用意できない場合は、主要画面のキャプチャと帳票の出力サンプルで代用できます。

業務を説明できる担当者。 開発の知識は不要です。確認事項に対して「この区分は今も使っている」「この挙動は業務上ありえない」と答えられる方に、確認の場へ加わっていただきます。

当社の進め方

当社では、ソースコード、データベース構造、画面と帳票、ログの4つの情報源をAIが突き合わせ、機能一覧、画面・帳票ごとの仕様、データ項目定義、処理フロー、外部システムとの依存関係を暫定仕様書として起こします。そのうえで、業務上の意図がコードから読み取れない箇所を確認事項として抽出し、業務担当者との読み合わせで確定させていきます。次の図は、AIが生成した画面仕様書の1ページのイメージです。

※実案件のものではなく、当社で作成したサンプル資料です。

項目の一覧や入力チェック、遷移先はコードから起こした内容で、確認事項の欄には「コードからはこう読めるが、業務上の正解はどちらか」を書いています。サンプルの下部には記述の根拠になったコードの位置も入れています。後で疑問が出たときにコードへ戻れるよう、こうした併記は依頼時に求めておくと役立ちます。

ご依頼の入口は、AIマイグレーションと同じ無料診断です。NDA(秘密保持契約)を締結のうえシステム概要とソースコードの一部をお預かりし、解析結果と、仕様書化にかかる概算をご提示します。移行を検討中であれば、仕様書化を先行させるべきか、移行の中で作るべきかも、解析結果を見ながらご相談いただけます。

まとめ: 出せるものと出ないものを分けてから依頼する

ソースコードからAIで仕様書を作る場合、機能一覧、データ項目定義、呼び出し関係はほぼ自動で網羅でき、画面・帳票仕様や処理フローも大半をAIが起こせます。出ないのは、業務上の意図、不具合か仕様かの判断、設定にしかないロジック、外部部品の中身です。これらは確認事項として業務担当者に埋めてもらう部分であり、どこまで埋めるかが費用と納期を決めます。

依頼前に、目的に応じて必要な仕様書の種類と粒度を絞り、移行が前提なら仕様書化を先行させるかどうかを考え、ソースコードを出せる環境を確認しておく。この3点が整理できていれば、見積の比較も納品物の評価もしやすくなります。

自社のシステムからどの程度の仕様書が出せるかは、実際のコードを解析すれば見えてきます。DEN-NOのAIマイグレーションサービスでは、NDAを締結のうえソースコードの一部をお預かりし、解析結果と概算費用を無料でご提示しています。仕様書化のみのご依頼も承っています。

AIマイグレーションサービスの詳細はこちら

よくある質問

Q. 仕様書だけ作ってもらい、移行は自社や別の会社に頼むこともできますか？

できます。納品する仕様書は当社の移行を前提にした書式ではなく、自社での保守や他のベンダーへの引き継ぎにそのまま使える形で整えます。ただし、移行を予定している場合は、仕様書化を先に単独で行うより移行の中で作るほうが早いことが多いため、解析結果を見たうえでどちらが適しているかをご案内します。

Q. 古い設計書が一部残っています。それも使えますか？

使えます。現行の仕様はコードから起こしますが、古い設計書は当時の意図を知る手がかりになり、現物との差分を洗い出す材料にもなります。改修履歴や問い合わせの記録も同様です。内容が古いからといって捨てずに、あるものはすべてお渡しください。

Q. AIが生成した仕様書が正しいかどうかは、どう確かめるのですか？

コード、データベース定義、実際の画面との突き合わせと、人によるレビューを行います。コードから判断できない箇所は正しそうな形に直さず、確認事項として明示し、業務担当者の回答で確定させます。AIの出力をそのまま正解として扱わない考え方はAIマイグレーションのよくあるご質問でも説明しています。

Q. ソースコードを社外に出せない場合はどうなりますか？

お客様のAWSまたはAzure環境内に専用の作業環境を構築する方式でご相談いただけます。完全なオンプレミスや閉域環境は、利用できるAIと運用条件を確認したうえで個別に判断します。いずれの場合も、お預かりしたコードがAIモデルの学習に使われない契約・設定で運用します。