作った人がいない業務システムの仕様書をAIでソースコードから起こす｜読み取れる範囲と、人が確かめる範囲、頼むときに費用が決まる所

仕様書が無い業務システムでも、AI にソースコードを読ませれば、処理の中身を日本語に起こせます。ただし、起こせるのは、プログラムの中に書かれた処理までです。設定の表やデータで決まる処理、人が手でしている作業、画面や帳票の速さと出る時刻、なぜその条件になっているかという理由は、ソースコードに書かれていないので、AI にも読めません。

IPA のユーザガイドも、資料が足りないときの補い方を分けています。処理設計書の水準はソースコードから作り直し、基本設計から要件定義にあたる部分は、有識者と使っている部門への聞き取りで作り直す、という分け方です（IPA ガイド p.99）。AI が活躍するのは、前者の「ソースコードから作り直す」部分です。

AI が出した文章は、起こした時点では、ソースコードの読み方の一案です。実データで動かして現行の出力と比べ、使う部門が確認して合意してから、入れ替えの見積りやテストの拠り所になります。この記事は、仕様書の無いシステムの入れ替えを考えている担当の方に向けて、AI で読める範囲、人が確かめる範囲、頼むときに費用が動く所を、この順に書きます。

AI が読めるもの、読めないもの

仕様書の無いシステムで、仕様のずれが起きる理由は、IPA のガイドに書かれています。ガイドは、長く使われたシステムでは、設計書・ソースコード・動いているシステムの3つの間に食い違いが生まれる、としています。仕様を変えたときに関係する業務の資料までは直さなかった、障害の対応でソースコードだけを直した、といった積み重ねです（p.15〜16）。AI が読めるのは、このうちソースコードだけです。動いているシステムと、人の作業は、AI の目に入りません。

AI の側にも限りがあります。Claude Code の公式ガイドは、読んだファイルやコマンドの出力がすべて会話の記憶領域（コンテキスト）に入り、いっぱいになるほど指示を忘れたり誤りが増えたりする、と書いています（Best practices）。GitHub の公式ページも、Copilot Chat のコードの説明が正確・完全とは限らないことと、あまり使われない言語では品質が下がることがあることを挙げ、出力は人が確かめる前提です（Responsible use of Copilot Chat）。古い言語や独自の仕組みで書かれたシステムほど、読ませ方と確かめ方に手間がかかる、というのが当社の見立てです。

読ませる前に、どの材料を渡せるかを決めておくと、仕様書の穴が減ります。次の表は、渡す材料ごとに、AI が読み取れることと、渡すときの注意を並べたものです。

書かれていない処理の数え方と、見積りのどの行に効くかは、基幹システムの入れ替え費用と期間の記事に書きました。この読み取り範囲の切り分けを、手元のシステムで一緒に見る相談もできます（古い業務システムの移行・保守の案内）。

人が確かめる範囲：実データで動かして比べる

AI が起こした仕様書は、もっともらしい文章になります。そのため、読んだだけでは間違いに気づきにくく、確かめるには、実際に動かした結果と比べるのが近道です。IPA のガイドが書く現新比較テストは、現行のシステムから取った実データを、現行と新しいシステムで同じ処理に通し、出力を比べる確かめ方です（p.18）。同じ考え方を、仕様書に当てはめます。

比べる処理は、全部にしなくてもかまいません。ガイドは、影響が大きい「変えない」部分を中心に、現行踏襲を確認できるテストのデータとケースを、早めに開発会社へ渡しておくと有効としています（p.90）。月末・期末・例外のある処理も、取り違えが起きやすいので、先に比べる候補になります。

仕分けが済んだ仕様書は、使う部門が確認して、内容を「正」とすることを合意しておきます。ガイドは、現行踏襲の内容は設計ドキュメントに仕様として明記し、その内容を正とすることを各関係者で合意しておく必要がある、と書いています。レビューと承認は、以降のテストの拠り所になるので、責任を持って行うよう求めています（p.90）。AI が書いたかどうかにかかわらず、承認する人が責任を持つ、という点は変わりません。

AI にソースコードを渡してよいか：プランで学習の扱いが分かれる

AI にソースコードを読ませると、そのコードは外部のサービスに送られます。Claude Code の公式の説明では、利用者の入力とモデルの出力のすべてが、ネットワーク経由で送られます（Data usage）。このとき、学習に使われるか、どれだけ保持されるかは、同じツールでも、プランや設定で変わります。

GitHub は、2026年3月25日の告知で、個人向けのプラン（Free・Pro・Pro+）の入出力とコードの断片が、4月24日から学習に使われると案内しました。Business と Enterprise は、この更新の対象外です（GitHub Changelog）。Claude Code は、個人向けのプランでは設定で学習への利用を選べ、Team・Enterprise・API などの商用の契約では、学習に使われません（Data usage）。2社以外のツールは、今回確かめていません。

発注する側が開発会社に確かめるのは、使うツールとプランの名前、渡したコードと実データの保持期間、学習への利用の有無の3つです。そのうえで、自社の契約や規程に照らして、コードや実データを外部のサービスに出してよいかを決めます。出せない場合は、閉じた環境で読ませる前提で、見積りを依頼します。

頼むとき費用が決まる所

AI で起こす作業の費用は、AI を使うかどうかより、次の6つの所で動きます。IPA のガイドが載せている一例でも、再構築の手法を選ぶために現行システムを調べるとき、費用に影響する要素として、ドキュメントの網羅性と信頼性、プログラムの規模と複雑性と読みやすさ、仕様を再定義できる人の有無などを指標にしています（p.149）。起こす作業でも、同じ観点が効きます。

「完了の基準」は、決めておかないと、終わりが見えなくなります。ガイドは、再構築のテストについて、どこまで実施すれば品質を担保できたかの方針を決めておかないと、テストを延々と続けることがある、と注意しています（p.18）。仕様書を起こす作業にも、同じことが当てはまります。比べる処理の数と、「不明」の残し方を、頼む前に決めておきます。

見積りを受け取るときは、次の点を開発会社に聞きます。

• AI が起こした部分と、人が書き足した部分を、納品物の中で分けて示してもらえるか
• 実データで確かめた処理の数と、確かめなかった処理の理由を、書いてもらえるか
• 「不明」の一覧を、仕様書とは別に出してもらえるか
• 使う AI のツールとプラン、渡したデータの保持期間を教えてもらえるか
• 見積りは、対象を何件と置いたものか。件数が増えたときの扱いはどうなるか

見積りの金額は、対象を何件と置いたかで変わります。件数が増えたときの扱いを、見積りの前提に書いてもらうと、あとから行が増えにくくなります。

出来上がった仕様書の使い方

仕様書は、書いた時点のコードの写しです。ソースコードを直したあとで仕様書を直さなければ、IPA のガイドが書くドキュメントとソースコードの食い違い（p.15〜16）が、また生まれます。保守を頼む開発会社と、「ソースコードを直したら、仕様書も直す」ことを、保守の範囲として決めておきます。

仕様書を起こす材料が、プログラムでなく Excel のマクロや FileMaker のファイルのときは、読ませ方と確かめ方が変わります。Excel マクロの引き継ぎとFileMaker の移行を、別の記事に書きました。仕様書の「前提」の欄に書く言語・DB・OS の版は、部品の期限の記事で、期限の日付を確かめられます。

仕様書の起こし方と、頼むときに決める所の整理は、Aurant Technologies の古い業務システムの移行・保守の案内から、困っている1点だけでも相談できます。