ソースコードから仕様書をAIで作成する：既存システムの仕様書化で出せる範囲と精度、費用の目安、依頼前に決めること

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

AIを使えばソースコードから仕様書を作れる、という話は目にするようになりました。ただ、その多くはエンジニアが自分の手元でAIツールを使う話で、発注する側が知りたい「何がどこまで出るのか」「出ないものは何か」「いくらかかるのか」には答えていません。

機能一覧やデータ項目定義のように、答えがコードとデータベース定義に書かれているものは、AIでほぼ網羅できます。出ないのは「なぜそうなっているか」で、そこを誰がどこまで埋めるかによって費用も納期も変わります。仕様書がないまま移行まで進める場合は仕様書がないシステムはAIで移行できる？で、AIに仕様書を書かせる手順と執筆ルールはAIで仕様書を作成する方法で扱っています。

仕様書化が必要になる場面

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

自社で開発や保守を担おうとする企業も同じ壁に当たっています。JUASの企業IT動向調査2025では、システム開発の内製化の課題として「現行業務への理解不足」を挙げた企業が38.7%、「現行システムの仕様がわからない」が24.6%ありました。東証上場企業とそれに準じる企業959社の複数回答です。

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

保守会社を替えるときも、次の会社へ渡す引き継ぎ資料が必要です。相見積を取ろうにも、システムの規模や構成を示す資料がなければ、各社とも概算すら出せません。M&Aや事業承継では、譲り受ける事業がどんなシステムで動いていて、外部サービスやライセンスに何を依存しているかを短期間で把握しなければならず、コードから全体像を起こす作業が発生します。

システム移行の前提として仕様書を整えたいという相談もあります。移行の見積根拠を明らかにしたい、移行先の要件を先に整理したい、という考え方です。ただしこの場合は、仕様書化を単独で先に行うのが最善とは限りません。先に作った仕様書を移行の際にもう一度検証する二度手間になりやすく、どちらを選ぶかの分かれ目は「依頼前に判断しておくこと」で説明します。

AIが起こせる仕様書の種類と精度

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

ただ、どこまで自動で出せるかは仕様書の種類によって違います。当社が扱う範囲で整理すると次のようになります。

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

画面・帳票仕様は、項目の一覧、必須や桁数といった入力チェック、画面の遷移先まではコードから出せます。レイアウトや帳票の見た目は、実際の画面や出力サンプルと突き合わせて仕上げます。入力チェックが画面側のスクリプトとサーバー側の処理の両方に書かれているシステムでは、両者の条件が食い違っていることがあり、どちらを仕様とするかは確認事項になります。

処理フローは条件分岐や計算式、データの更新順序を文章化できますが、例外的な分岐がなぜ存在するのかは説明できません。外部インターフェースも、こちら側から何を送り、何を受け取っているかは出せる一方、相手システム側の仕様や運用上の取り決めはコードの外にあります。

AIが出した仕様書は、大半は正しいものの、確認が必要な箇所に印が付いた状態で出てきます。これをコードとの突き合わせと人のレビューを経て確定させます。AIは読み取れなかった箇所をもっともらしい文で埋めることがあり、確認を経ていない仕様書では、その部分とコードから読み取った部分を後で読む人が区別できません。

AIでは起こせない情報

コードに書かれていないことは、AIにも書けません。仕様書化で抜けるのは主に次の4つです。

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

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

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

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

これらは仕様書の中で「確認事項」として明示し、業務担当者の方に答えていただいて補います。コードに書かれた事実を整理するまでなら作業の大半はAIで済みますが、業務上の意味まで書き込んだ仕様書を求める場合は、担当者の方へのヒアリングと読み合わせの時間が追加で必要になります。

費用と納期の目安

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

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

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

納期のうち、AIが解析して暫定仕様書を出すまでの時間は、人がコードを読む場合より短く済みます。見通しを立てにくいのはその後の工程で、確認事項への回答と読み合わせにお客様側でどれだけ時間を割けるかによって全体の期間が決まります。担当者の方が週に1回しか時間を確保できなければ、確認のやり取りに要する日数がそのまま期間に加わります。依頼の際は、確認に協力できる人と時間の目安を先に決めておくと、納期の見込みが立ちやすくなります。

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

仕様書一式をすべて詳細設計の粒度で作ろうとすると、費用も期間も膨らみます。相見積のための資料が目的なら、概要レベルの機能一覧と規模の数値で足ります。目的ごとに優先する種類と粒度は次のとおりです。

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

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

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

お客様側でご用意いただくもの

既存の設計書は必須ではありません。用意していただきたいのは次の4点です。

ソースコード一式：
本番で動いているものと同じバージョンを揃えてください。バージョン管理されていないシステムでは、開発用のコピーと本番サーバー上のコードが食い違っていることがよくあります。判断に迷う場合は、本番環境から取得したコードを基準にします。夜間バッチの起動設定やシェルスクリプトのように、アプリケーションの外に置かれたファイルも含めていただくと、処理の流れを最後まで追えます。

データベース定義：
テーブル定義書があればそれを、なければデータベースから構造情報を出力したものをご用意ください。ストアドプロシージャやトリガーに処理を持たせているシステムでは、その定義も一緒に出力してください。テーブル定義だけでは、データベース側の処理が解析から漏れます。個人情報を含む実データは必要ありません。構造がわかれば解析できます。

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

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

自社でAIツールを使う場合との違い

仕様書化を外部に依頼せず、GitHub CopilotやClaude Codeのような汎用のAIツールで自社で進める選択肢もあります。社内にコードを読めるエンジニアがいて、対象が数千行から数万行、目的が特定機能の理解や引き継ぎ用の概要であれば、この進め方がもっとも安く、早く済みます。

違いが出るのは、数十画面を超える規模で体系立てた仕様書を作る場合と、業務上の意図まで文書にする場合です。汎用のAIツールは関数やファイル単位の説明は出せますが、画面設計書やテーブル定義書のような様式で分冊を管理し、出力をコードと突き合わせ、確認事項を洗い出す作業はエンジニアが担います。COBOLなどメインフレーム系に特化した専用製品も含めた3つの方法の比較は仕様書の自動生成は自社でやるか委託するかにまとめています。

当社の進め方

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

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

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

ご依頼の入口は、AIマイグレーションと同じ無料診断です。納品物の種類、進め方、費用の考え方はAI仕様書作成サービスのページにまとめています。

まとめ

依頼先に声をかける前に、社内で答えを出しておきたいことが3つあります。

1つ目は、何のための仕様書かです。保守の引き継ぎ、監査、相見積、M&Aのどれにあたるかで、上の表のどの行の粒度を求めるかが決まり、複数社から見積を取るときの前提も揃います。2つ目は、確認事項に答える担当者と、その方が確保できる時間です。AIの解析が早く終わっても、ここが決まっていなければ納期の見込みは立ちません。3つ目は、ソースコードをどの環境まで出せるかです。社外に出せない場合は、委託先の候補が専用環境の構築に対応しているかが最初の確認点になります。

移行が控えているなら、仕様書化を先行させるか、移行の中で作るかの判断がこれに加わります。

自社のコードからどの種類の仕様書がどの粒度まで出せるか、確認事項がどれくらい出そうかは、実際のコードを一部解析すると見えてきます。DEN-NOのAI仕様書作成サービスでは、NDAを締結のうえソースコードの一部をお預かりし、解析結果と概算費用を無料でご提示しています。設計書が残っていないシステムでも診断は可能です。移行を検討中の場合は、仕様書化を先に行うか移行の中で作るかについても、解析結果を見ながらAIマイグレーションサービスとあわせてご相談いただけます。

AI仕様書作成サービスの詳細はこちら

よくある質問

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

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

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

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

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

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

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

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