AI

仕様書のない業務システムは、生成AIで読めるのか――引き取り現場の線引き

目次

「これ、AIに読ませれば全部分かるって聞いたんですけど、本当ですか？」――。担当者は数年前に辞めていて、設計書はどこにも残っていない。それでも毎日動いている基幹システム。そこに「AIで読めるらしい」という話が外から入ってくる。

生成AIで読めるのは、コードに書いてあることまでです。ソースコードの構造や処理の流れ、テーブルと画面の対応といった「コードを読めば分かること」は、生成AIで相当のところまで自動化できます。一方、なぜその処理がそうなっているのかという業務上の理由や、年に一度しか動かない例外運用、特定の取引先だけ走る裏ルートは、コードのどこにも書かれていません。ここは人が現場担当者に聞いて埋めるしかありません。

「AIで全部読める」でも「AIでは何も分からない」でもなく、対象によってきれいに分かれます。引き取り案件の現場で見えてきた、AIで読み解ける範囲とそうでない範囲、渡す前の準備と機密データの扱いまでを、判断軸として並べます。

仕様書がないシステムは、生成AIで本当に読めるのか

ソースコードが手元にあるなら、構造と処理の流れは生成AIで読み解けます。クラスや関数の呼び出し関係、テーブルの依存、画面と処理の対応といった「コードに書いてあること」は、人が一行ずつ追うよりも早く整理できるようになりました。ここ1〜2年で大規模言語モデルのコード理解は実用に乗り、数万行規模の業務システムを数週間で図解する事例も出てきています。

一方、コードに書かれていない情報は読めません。なぜその分岐があるのか、例外処理の閾値がなぜその数字なのか、特定の顧客コードに紐づく特別処理がいつから運用されているのか。こうした背景はコードのコメントにも書かれていないことが多く、現場の頭の中と紙のメモにしか残っていません。

つまり「AIで読めるか」という問いは、「何を読みたいか」を分けないと答えになりません。コードに書いてあることを読みたいなら、AIは強力な味方です。業務ルールの背景や例外運用を知りたいなら、AIは入口にしかなりません。

AIリバースエンジニアリングとは何をするものか――製品と自前運用の違い

AIリバースエンジニアリングとは、ソースコードを生成AIに読ませて、構造や処理の流れを設計書相当のドキュメントに再構築することを指します。「AIで保守困難なシステムを解析する」という売り出しは、ここ1〜2年で急速に立ち上がってきた市場で、実際にサービスとして出ているものを2つ挙げます。

東芝デジタルエンジニアリングは、生成AI活用サービス「AI-no-te（アイノテ）」のメニューの一つとして、リバースエンジニアリングサービスを提供しています。対応言語はPL/SQL、Python、VBA、HTML、JavaScript、Java、C#、COBOL、.NET、VB.NET。既存のプログラムコードと運用マニュアルを生成AIで解析した上で、同社のエンジニアが内容を検証して設計書を整備する流れです。従来手法比で約50%のコスト・期間削減をうたっています（参照: 東芝デジタルエンジニアリング「AI-no-te リバースエンジニアリングサービス」、2026年6月時点）。

SHIFTは「SHIFT DQS for リバースエンジニアリング」として、ソースコードからシステムの構造・ロジックから業務での使われ方までを解析するサービスを提供しています。AIと独自フレームワークの組み合わせで、46種のドキュメント生成に対応するとされています（参照: SHIFT DQS for リバースエンジニアリング、2026年6月時点）。

製品として提供されているこうしたサービスと、Claude CodeやCursorといった汎用ツールを使った自前運用とでは、向き不向きが異なります。

製品サービスは、解析の手順がパッケージ化されていて、最終的な設計書の体裁も決まっています。検証を含めた人手が乗るので品質は安定しますが、コードを社外に出す前提の契約や、調査範囲ごとの見積もりが必要です。数十万行規模の解析事例も報じられており（参照: 日経xTECH「東芝デジタルエンジニアリング、生成AIで20万行のCOBOLを3カ月解析」、2026年6月時点）、規模が大きい案件ほど効きやすい型ですが、規模が小さい案件にどこまで合うかは別の話です。

一方、汎用ツールを社内で動かす自前運用は、調査範囲を小さく切って試せます。Claude CodeやCursorで関数の呼び出し関係を辿らせる、テーブル間の依存を抽出させる、画面と処理の対応表を作らせる――こうした使い方なら、まずは数日のスポットで成果を確かめられます。代わりに、出力を検証する側にコードを読める人が必要で、機密を含むコードを外部APIに渡してよいかの線引きは自社で決めなくてはなりません。

製品か自前運用か、どちらが優れているという話ではありません。数十万行のCOBOLを設計書まで戻したいなら製品サービスが妥当ですし、数万行規模で「まず構造の見取り図がほしい」のであれば自前運用で十分足りる場面もあります。

AIで取れる読み解き、取れない読み解き

引き取り案件で実際にAIに読ませてきた範囲を、「取れた」「取れなかった」で並べます。

AIで取れる読み解きの代表例は、次のあたりです。

  • 主要な処理フローの図化（関数の呼び出し関係、画面遷移）
  • テーブルとカラムの依存関係、画面と処理の対応表
  • 使われていない可能性が高いデッドコードの一覧（推定）
  • 外部I/O（API呼び出し、ファイル入出力、メール送信など）の洗い出し
  • 設定ファイル・環境変数の意味づけと、利用箇所のマッピング

これらは、コードを一行ずつ追えば人にも分かる情報です。ただし、10年もののシステムだと「人がやれば3週間」が「AI＋人で1週間」に縮みます。引き取り初期の見取り図づくりには、十分実用に乗ります。

一方、AIでは取れない読み解きもはっきりしています。

  • なぜその処理がそうなっているのか、業務上の理由
  • 特定の取引先や顧客コードに対する特例処理の経緯
  • 年に一度しか動かない決算処理や棚卸処理の前後段取り
  • 紙やExcelで吸収されている前工程・後工程
  • 「このフラグが立つと営業部のあの人に電話する」といった暗黙の運用

このあたりはコードのどこにも書いてありません。コメントに残っていることはまれで、残っていたとしても古い情報のままなことが多い。結局は、現場担当者の頭の中にしかない情報です。

もう一つ重要なのは、AI出力の信頼性をどう確かめるかです。生成AIは「もっともらしいが間違っている」答えを返すことがあります。引き取り案件でこれをやられると、後の改修が壊れます。対策はシンプルで、AI出力には根拠となるコード行の参照を必ず付けさせ、人がトレースできる状態にしておくことです。「この処理フロー図は、どのファイルの何行目を根拠にしているのか」をたどれない出力は、現場で使ってはいけません。

引き取り案件でAIに読ませる前に、社内で揃えておきたいもの

AIの出力の質は、渡す素材で大きく変わります。引き取りのヒアリングを始める段階で、次のものを社内で揃えておくと、解析フェーズが滑らかに進みます。

1つ目は、本番稼働中のソースコード一式です。当然のようでいて、実は社内のどのサーバーに最新版があるか分からない、リポジトリが複数あってどれが本物か分からない、というケースは珍しくありません。最新の本番デプロイ物と、その元になったソースが一致しているかを確認するところが、最初の作業です。

2つ目は、DBスキーマと、PII（個人情報）を伏せたサンプルデータです。テーブル定義だけでも処理は読めますが、サンプルデータが数行あると、AIが返してくる解説の精度が上がります。本番データをそのまま渡すのは論外で、氏名・住所・電話番号といったPIIはマスクしたものを用意します。

3つ目は、現場担当者に聞いた「絶対に止められない処理3つ」のメモです。月初の請求書発行、毎週金曜の在庫締め、年に一度の棚卸――どんなシステムにも、止めたら業務が止まる処理が3つ前後あります。これを先に把握しておくと、AI出力をレビューするときの優先順位が決まります。

4つ目は、過去の改修依頼メールや障害メモです。「2年前にこういうトラブルがあった」「あの取引先だけ特別対応が入っている」といった情報は、コードに書かれていない業務文脈の塊です。古いメールフォルダや稟議書のコピーを掘り出しておくと、解析後のヒアリングで効いてきます。

順序が大事です。素材を揃えてからAIに渡すと、出力をそのまま現場確認の叩き台にできます。素材が中途半端なままAIに渡すと、出力の精度が落ち、現場側も「これは違いますね」で終わってしまい、二度手間になります。

機密データはどこまでクラウドに出してよいか

引き取り案件で必ず出る論点が、コードに含まれる機密の扱いです。業務システムのソースコードには、PIIだけでなく、取引先名、原価情報、独自の業務ロジックそのものが含まれています。これを外部のクラウドサービスに渡してよいかは、案件ごとに線引きが要ります。

実務での線引きを、おおまかに3パターンで整理します。

1つ目は、公開API（クラウドの生成AIサービス）を使うパターンです。手早く試せて費用も読みやすい一方、入力したコードがどう扱われるかは利用契約の範囲で判断します。社内規定で「ソースコードを外部送信不可」としている会社は、そもそも選択肢に入りません。

2つ目は、社内ネットワーク内でローカルLLMを動かすパターンです。OllamaやLM Studioといった環境で、機密を含むコードはローカルで前処理し、汎化された情報だけ外部APIに渡す、という二段構えが取れます。性能は公開APIに一歩譲る場面もありますが、機密の線が引きやすくなります。

3つ目は、解析を外注するなら、現地で作業してもらうパターンです。コードを社外に持ち出さず、解析担当者が顧客の社内環境に入って作業する形です。費用は上がりますが、社外送信のリスクをゼロにできます。

機密性が高いコードを扱う案件では、ローカルLLMで前処理してから外部に出すかどうかを最初に決めておくのが無理がありません。「機密だからAIは使えない」と諦めてしまう前に、何をどこまでAIに渡し、何を手元で処理するか、渡す範囲を切るほうに頭を使います。

AIで読み解いたあと、人がやる範囲

AIで処理フロー図とテーブル依存表ができあがった段階は、ゴールではなく出発点です。ここから現場担当者と突き合わせて、コードに書かれていない業務文脈を埋めていきます。

ヒアリングで効く問いの型を3つ挙げます。

1つ目は「この処理が動かなかったら、誰がいちばん困りますか」です。AIが洗い出した処理フローを見せて、止まると困る順に並べてもらう。これで実態に沿った優先順位が決まります。コードを書いた人と業務で使う人で、「重要な処理」の認識はずれます。

2つ目は「この分岐、なぜこの条件なんでしょうか」です。AIが「ここで顧客コードが100番台のときだけ別処理に飛んでいる」と教えてくれたとして、その背景は現場担当者にしか分かりません。「ああ、あれは10年前にA社さんから特別対応の依頼があって」というような答えが、コードのコメントの代わりになります。

3つ目は「年に何回くらい動く処理ですか」です。AIは静的な解析しかできないので、頻度は分かりません。毎日動くものと、年に一度しか動かないものでは、改修時の検証の重みが違います。

このヒアリングでは、現場担当者を「AI出力を疑う側」に立ててもらうのがポイントです。「AIがこう言っているんですが、合っていますか」と聞くと、現場の人は遠慮して頷きがちです。「AIの整理に間違いがあれば指摘してほしい」と立場を明示するだけで、出てくる情報の質が変わります。

人手主体で段階的に改修を進める手順は、別記事の仕様書のない業務システムは直せるのか――現状把握から始める段階的な改修の手順で整理しています。AIで見取り図ができたあとの動かし方は、こちらと合わせて読んでもらえると流れがつながります。レガシーシステムを引き取って維持していく全体像はレガシーシステムの運用管理を立て直す3つの手順：属人化からの脱却にまとめてあります。

自社でやるか外に頼むかの判断軸

自社でAI解析を進められる条件は、おおまかに3つです。コードを読める人が社内に1人以上いること。生成AIツールの利用環境（Claude CodeやCursorなどの契約と、必要に応じたローカルLLMの環境）が整えられること。解析の正解を誰が判断するかが社内で決まっていること。

逆に、外に頼んだほうが早い条件もはっきりしています。コードを読める人がそもそも社内にいない場合。対象がCOBOLやVB6など、社内に経験者がいない言語の場合。解析と並行して、システム刷新の提案までほしい場合。これらに当てはまるなら、製品サービスや専門会社に頼むほうが結果的に安く済みます。

費用面で押さえておきたいのは、AI解析フェーズが最初にスコープを切りにくい仕事だという点です。コードを開けてみるまで、どこに地雷があるか分かりません。にもかかわらず月額固定や一括見積もりで進めると、想定外の作業が出たときに発注側か受注側のどちらかが無理を被ります。three dots.では、解析フェーズや継続保守は実働ベース（使った分だけ）の料金で進めることが多いです。料金の組み立ては月額固定と実働ベースの選び分けに詳しく書いていますが、AI解析の初期フェーズについては、まず数日から1〜2週間の枠で「何が分かりそうか」を見るのが現実的です。

まとめ

仕様書のない業務システムを生成AIで読み解けるかは、対象によって分かれます。コードに書いてあることは、AIで相当のところまで自動化できます。なぜそうなっているかという業務上の理由や、例外運用、紙とExcelで吸収されている前後工程は、人が現場に聞いて埋めるしかありません。

成果を左右するのは、AIに渡す前の準備です。本番稼働中のソース、PIIを伏せたサンプル、絶対に止められない処理3つ、過去の改修・障害メモ。この4つを揃えてからAIに渡すと、出力をそのまま現場確認の叩き台にできます。素材を揃えずに渡せば、出力は粗くなり、現場の協力も得にくくなります。

引き取りを検討中なら、まず本番稼働中のソースとPIIを伏せたサンプルだけ手元に揃え、絶対に止められない処理3つを書き出すところから始めるのが妥当です。そこまでくれば、AIで取れる範囲と人手で埋める範囲が、案件の中身に即して見えてきます。

システムレスキュー

保守が困難になったレガシーシステムの引き継ぎ・維持を専門に扱います。AI解析を入口にした見取り図づくりから、段階的な改修・継続保守まで、実働ベース（使った分だけ）で対応します。

/service/system-rescue/

「設計書がないけれど、AIで何かできないか」と感じている方は、弊社まで現在のシステム構成と、止められない処理がどのあたりにあるかを共有いただければ、AIで取れる範囲と取れない範囲のあたりをつけた上でご返答します。

関連記事