仕様書がない既存システム AIでソースコードから現行仕様書を起こし、業務担当者と確認する手順
要約： 稼働中のシステムに仕様書が残っていない場合、Claude CodeなどのAIにソースコードを読ませて、現行仕様書の下書きを作れます。ただし下書きから分かるのは、システムが今何をしているかであり、なぜそうなっているかは分かりません。新システムの前提にする前に、業務担当者が一項目ずつ確認する必要があります。
目次
- AIでソースコードから現行仕様書を作れるのか
- ソースコードから起こした仕様書で、分かることと分からないこと
- 現行仕様書を作る手順
- 業務担当者と一項目ずつ確認するには
- VAONの仕様確定フェーズでは、どこに位置づくか
- この進め方が向かない場合
- よくあるご質問
1. AIでソースコードから現行仕様書を作れるのか
AIで作れるのは仕様書の下書きまでで、それだけでは仕様書になりません。Anthropicの公開ドキュメントによれば、Claude Codeはコードベース全体を読めるコーディングツールです。数百の画面、データのテーブル、入れ子になった条件分岐など、人が読むと疲れる部分を速く読んでくれます。
一方で、10年動いているシステムには、10年分の、さまざまな人の判断が重なっています。ソースコードに残っているのは判断の結果であり、理由ではありません。VAONはAIの出力を「システムの挙動についての仮説の一覧」として扱います。本当の作業は、その仮説を一つずつ、システムを使っている人に確認するところにあります。
実際の案件で、この方法を行ってきました。ただし、どれだけ速くなったか、どれだけ正確だったかを示す計測値はまだありません。そのため本記事には数字を載せず、お客様名も出していません。
2. ソースコードから起こした仕様書で、分かることと分からないこと
ソースコードから起こした仕様書で分かるのは挙動のレベルまでで、理由、ルールがまだ生きているか、コードの外にある処理については、ほとんど分かりません。着手の前に知っておきたい限界を表にまとめます。
| 知りたいこと | コードから起こした仕様書で分かるか | 対処 |
|---|---|---|
| システムが何をしているか（画面、API、バッチ、計算） | 大部分は分かる | 実際に動く画面と突き合わせる |
| このルールがなぜあるのか | 分からない | 業務担当者、古くからいる方に聞く |
| このルールは今も使われているか、死んでいるか | 確実には分からない。コードが残っていても、実行されていない場合がある | ログと実データを確認し、利用者に聞く |
| コードの外にある処理（マスタデータ、本番環境の設定、手作業） | 分からない | 運用担当者にヒアリングし、本番環境を確認する |
| 外部の他社システムがどう動くか | 呼び出し側しか見えない | 先方の資料、担当者への確認 |
| この挙動は仕様か、長年残っている不具合か | 区別できない | 業務担当者が、残すか直すかを決める |
最後の行が最も危険です。何年も残っている不具合をAIが「仕様」として記録すると、新システムにそのまま引き継がれます。現場の方がその不具合を避ける手順に慣れてしまい、普通のことだと思っている場合もあります。
3. 現行仕様書を作る手順
VAONの手順は7段階で、AIが関わるのは2から4までです。残りは人が担います。
- 許可と範囲を決める。 ソースコードをAIツールに入れてよいか、どの部分までかをお客様に確認します。NDAを結び、使ってよいデータと閲覧できる人を決めます。許可がない場合はAIに入れず、人がコードを読みます。時間はかかりますが、進められます。
- システムを棚卸しする。 入り口になるものを一覧にします。画面、API、バッチ処理、データのテーブル、外部連携です。これが仕様書の骨組みになり、あとで何が抜けているかを知る手がかりにもなります。
- 小さな単位で下書きを作る。 システム全体を一度に読ませず、機能を一つずつ読ませます。下書きの各行には、根拠となるファイルと関数を書き添えます。確認する人が、そこを開いて照らし合わせられるようにするためです。
- 各項目にラベルを付ける。 「動いていそう」「死んでいる疑い」「不明」のどれかにします。AIが意図を推測している箇所（「二重注文を防ぐためだろう」など）は、挙動ではなく推測なので分けて書きます。
- 業務担当者への質問を作る。 「システムが何をしているか」（コードから分かる）と、「なぜか、まだ必要か、正しいか」（人にしか答えられない）を分けます。
- 一項目ずつ確認する会を開く。 次の第4章で述べます。最も時間がかかり、省けない工程です。
- 確定して承認を得る。 確認済みの現行仕様書と、各項目を残すか、直すか、捨てるかの判断を、新システムの仕様の入力にします。
手順3から6と並行して、実際に動いているシステムも観察します。ログ、実データ、本番環境の設定です。ソースコードからは得られない、計測の層です。
4. 業務担当者と一項目ずつ確認するには
一項目ずつ確認するとは、下書きに書かれた挙動を業務担当者が見て、4つの結論のどれかを出すことです。結論がない項目は、まだ仕様に入りません。
| 結論 | 意味 | 次にすること |
|---|---|---|
| 正しい、残す | 挙動が正しく、必要 | 新しい仕様に入れる |
| 違う、直す | コードの動きが、業務の実態と異なる | 正しい挙動を新しい仕様に書く |
| 死んでいる、捨てる | 誰も使っていない | 範囲から外す。作る量が減る |
| 不具合、判断する | コードが、本来の意図と違う | 業務担当者が直すか残すかを決める |
確認表の1行には、項目ID、コード上の挙動、コード上の根拠、業務担当者への質問、結論、確認者と日付の6列を持たせてください。最後の列が重要です。あとで食い違いが起きたとき、誰がいつ何と言ったかを辿れます。
確認の会は、ファイルの順ではなく、機能のまとまりごとに開きます。業務担当の方が覚えているのは業務の流れで、関数名ではありません。また、管理職だけでなく、実際に使っている方に来ていただいてください。現場の方が通っている回り道を、管理職の方はご存じないことがよくあります。
5. VAONの仕様確定フェーズでは、どこに位置づくか
現行仕様書の作成は、VAONの仕様確定フェーズのうち、すでにシステムをお持ちのお客様向けの入り口Aの中心です。入り口Aは、ソースコードの読み取り、運用担当の方へのヒアリング、計測で構成され、ブリッジSEとテックリードが主導します。
期間は1〜2週間、大規模な案件では2〜4週間です。料金は固定で、事前にお示しし、追加費用は発生しません。成果物は、要件定義書、画面ごとのワイヤーフレーム、データベース設計、システム構成、構築フェーズの固定価格の見積もりです。このフェーズが終わった時点で、お客様はそこでやめることもできます。
進め方について付け加えます。VAONのエンジニアはClaude CodeとGitHub Copilotを日常的に使っており、リリースの前には必ず人が確認します。最終的な成果物は、人が承認する文書であり、機械の出力そのままではありません。
要件定義の期間と費用の全体像は、要件定義にかかる期間と費用の目安をご覧ください。システムを理解していた方がすでに退職されている場合は、担当者が退職してシステムが分からないときも参考になります。AIが関わる開発の品質管理は、AI駆動開発を外注する前に確認する12項目で整理しています。古いシステムを止めずに入れ替える事例は、レガシーCMSをダウンタイムなしで刷新した事例にあります。
6. この進め方が向かない場合
この進め方は、確認に時間を割ける業務担当者がいない場合には向きません。第3章の6がなければ、読みやすい下書きが残るだけで、正しいかどうかを誰も判断できません。仕様書がない状態よりも悪い状態です。
ソースコードがない場合（パッケージ製品だけがある場合）も、できません。お客様がAIツールへの入力をまだ許可しておらず、それでもAIを使う場合と同じ速さを期待される場合も、難しくなります。システムの挙動の大半が、手作業や暗黙のルールの中にあってコードに現れない場合は、運用担当者へのヒアリングが主で、ソースコードは補助になります。
また、現行仕様書はテストではありません。システムが今何をしているかを書いたものであり、新システムが同じように動くことの証明にはなりません。それには、別にテストのシナリオが必要です。
7. よくあるご質問
仕様書がなく、作った人も退職しています。VAONで引き受けてもらえますか。 お引き受けできる可能性があります。まず、ソースコードがあるか、確認に参加できる業務担当の方がいるかを伺います。この2点で、できるかどうかが決まります。初回の60分はCEOが同席し、資料は不要です。
古い言語で書かれたコードも、AIは読めますか。 言語と規模によって異なり、コードを拝見する前にお約束はしません。小さな機能を一つ試し、利用者の方と突き合わせてから、広げるかどうかを決めます。その試行で、実際の信頼度が分かります。
AIが起こした仕様書は、正しいのですか。 業務担当者が確認するまでは、正しいとは言えません。意図を推測した箇所、すでに死んでいるルール、仕様として記録された不具合は、下書きの誤りになり得ます。そのため、各項目にはコード上の根拠と、確認者の結論を付けます。
ソースコードをVAONに渡す必要がありますか。 ソースコードはお客様のリポジトリに置いたままにできます。コードやデータをAIツールに入れるのは、お客様が許可した場合に限ります。許可がなければ人が読むため、時間は長くなります。
現行仕様書ができたあとは、何をしますか。 仕様確定フェーズとして、要件定義書、ワイヤーフレーム、データベース設計、システム構成、構築フェーズの固定価格の見積もりを作ります。希望されれば、そのフェーズでやめることもできます。
動いてはいるが、誰も仕様書を持っていないシステムはありませんか。 ソースコードがお手元になくても構いません。状況をお聞かせください。無料相談（60分）
執筆者： ドアン・ミン・ホアン（Đoàn Minh Hoàng）、VAON 共同創業者・CTO。
参考資料
- Anthropic「Claude Code overview」：https://code.claude.com/docs/en/overview（2026年10月17日確認）