「十数年前に作った販売管理のシステムが今も毎日動いている。作った人はもういないし、仕様書も古いまま」—— こうしたシステムの刷新や改修を考え始めると、最初に突き当たるのが中身が分からないという壁です。 開発会社に見積を頼んでも、現状が分からないままでは幅の大きな金額しか出せず、社内でも判断が進みません。 そこで、「AIにソースコードを読ませれば、中身がすぐ分かるのではないか」と考える方もいるでしょう。
実際、AIを使うと、古いシステムの現状調査はかなり進めやすくなりました。一方で、AIに読ませれば何でも分かる、というわけでもありません。 この記事では、システム開発とAI活用を手がけるCoconutWorksが、刷新や改修を決める前の現状調査で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に下書きを作らせる — 問いに沿って、見取り図・対応表・処理の説明を起こします。説明ごとに根拠の箇所を残します。
- ④人が抜き取りで確かめる — 根拠の箇所を読み、推測が事実として書かれていないかを確かめます。重要な処理ほど丁寧に見ます。
- ⑤業務側と突き合わせる — 推測の部分、理由の分からないルール、使われているか分からない機能を、業務の担当者に確認します。
- ⑥判断の材料としてまとめる — ①の問いごとに、分かったこと・分からないこと・分からないことの扱い方をまとめます。
①の問いを決める作業は、外部に頼む前に社内で始められます。たとえば「新しい会計サービスにつなぐために、請求データをどこから取り出せるか」 「月末の締め処理で、システムが自動でやっていることと人が手でやっていることは何か」のように、判断に直結する問いにしておくと、 調査の範囲が絞られ、成果物も読み切れる量に収まります。
判断に迷ったときのチェックポイントとしては、次の三つを確かめるのが分かりやすい基準です。 調査の結果が①の問いに答えているか。説明ごとに根拠の箇所が示されているか。 「分からないこと」が隠されず、一覧として残っているか。三つ目は見落とされがちですが、刷新の計画では分からない部分をどう扱うかを決めておく必要があるため、 むしろ一番大切な成果物といえます。調査の段階と開発の段階を分けて頼む考え方は要件定義だけを先に発注できるかで詳しく扱っています。
よくある質問
まとめ
古いシステムの現状調査でAIが引き受けられるのは、大量のコードやデータ定義を読み、見取り図や対応表、日本語の説明に起こす読む量の部分です。 一方で、ルールがなぜあるのか、今も使われているのか、コードの外でどんな運用がされているのかは、人が業務側と確かめるしかありません。 調査で答えたい問いを先に決め、根拠の箇所と「確認済み・推測・確認待ち」の区別を残し、分からないことを一覧にする。 この進め方にしておくと、AIで短くなった時間を、判断に必要な確認に回せます。 刷新や改修を考えているシステムの現状調査から、問いの立て方も含めてご相談いただけます。システム開発サービスのページもあわせてご覧ください。相談・お見積もりは無料です。
