「生成AIでCOBOLを自動変換できるので、従来より安く早く移行できます」。そういう提案を受けて、この記事にたどり着いた方が多いのではないかと思います。実際、大手ベンダーはAIを使った刷新サービスを次々に出していて、技術としては実用段階に入りつつあります。ただ、そこで気になるのは「で、うちの見積もりは実際いくら下がるのか」という一点だと思います。
先に結論をお伝えすると、移行の工程は一律には縮みません。AIが効くのは現行コードを読む作業と、変換して書く作業で、ここは確かに短くなります。一方、引き継ぐ機能を決める作業と、動きが正しいか確かめる作業はほとんど縮みません。しかも後者は移行プロジェクトの中で大きな比重を占めます。この記事では、工程ごとの効き方の違いと、ベンダーが示す短縮率の読み方、提案を受けたときに確認する質問までを整理します。移行方式そのものの選び方や刷新の費用相場は別の記事に譲ります。
この記事のポイント
- AIが効くのは読む作業と書く作業で、決める作業と確かめる作業はほとんど縮まない
- ベンダーが示す短縮率は費用の割引率ではなく、条件付きの工程期間の話
- AIを使うほど、生成物が正しいか比べるための設計書とテストが必要になる
- 見積書はAIで代替する工程と人が見る工程が分けて書かれているかで判断する
目次
レガシーシステムの移行でAIができること
まずは、移行という作業の中身を分解するところから始めます。「AIで移行が速くなる」という言い方は、工程をひとまとめにしているぶん判断に使えません。どの工程がどれだけ短くなるのかを分けて見ると、提案の中身を評価できるようになります。
移行の工程はAIで一律には縮まない
古いシステムの移行は、大きく5つの工程に分かれます。現行システムを調べる工程、引き継ぐ範囲を決める工程、プログラムを変換して作る工程、動きが正しいかテストする工程、そして本番に切り替える移行リハーサルと受け入れの工程です。
このうちAIが直接効くのは、1つ目と3つ目に集中します。残りは人の判断と現場の確認が中心なので、AIを入れてもほとんど短くなりません。ここを分けずに「移行にAIを使うので3割安くなります」と言われた場合、その3割がどの工程の話なのかを聞かないと、金額の妥当性は判断できないんですね。
私の感覚では、発注する側が期待している「安くなる」と、ベンダーが言っている「効率化」は、指しているものがずれていることが多いです。ベンダーは自社の作業時間が減ることを効率化と呼びますが、発注側が知りたいのは請求額です。作業時間が減っても、その分がそのまま値引きに回るとは限りません。
AIが効くのは読む作業と書く作業
効く工程から具体的に見ていきます。ひとつ目は、現行システムを読み解く工程です。設計書が残っていないシステムでも、ソースコードから処理の内容を要約し、設計情報を再構成する取り組みが実用段階に入っています。人が一行ずつ追っていた下読みが速くなるので、ここは素直に効果が出ます。
ふたつ目は、プログラムを別の言語に変換して書く工程です。COBOLからJavaへの変換では、変換後にCOBOL特有の書き方が残らない形を目指す取り組みが進んでいます。従来の機械的な変換ツールは、動くけれど読めないコードを生みがちでしたが、その弱点が改善されつつあるという状況です。
ただし、ここには前提があります。汎用の生成AIは、COBOLのような古い言語の学習データが不足していて、そのままでは精度が出にくいという指摘が技術メディアで繰り返し出ています。つまり、どのAIを使うかで結果が変わるということです。提案を受けたときは「一般的な生成AI」なのか「その言語向けに調整したもの」なのかを確認しておくと、期待値を間違えずに済みます。
効きにくいのは決める作業と確かめる作業
次に、効きにくい工程です。まず「引き継ぐ範囲を決める工程」。どの機能を残し、どれを捨て、どこを業務ごと変えるかは、社内の事情と今後の方針で決まります。AIは現行の処理内容を教えてくれますが、その機能が今も必要かどうかは判断できません。ここは発注する側の仕事として残ります。
次に「確かめる工程」です。変換したプログラムが従来と同じ結果を返すかを確認する作業は、件数が多く、業務側の人が実際の帳票や画面を見て判断する必要があります。テストコードの自動生成でカバーできる部分はありますが、月次の締め処理や年に一度しか動かない処理まで含めて確認するとなると、期間はカレンダー側の制約を受けます。
最後に「切り替えの工程」です。本番移行のリハーサル、データの移し替え、旧システムとの並行稼働は、AIの有無に関係なく同じだけ時間がかかります。ここは業務を止められないという制約から来るもので、技術で圧縮できる部分が小さいところです。移行方式そのものによって作業量がどう変わるかは、基幹システムの移行方式はどう選ぶ？3つの選択肢と費用の見方で整理しています。
AIを使うほど検証の土台が要る
ここが一番お伝えしたい点なのですが、AIを使うと検証の重要度はむしろ上がります。理由はシンプルで、生成されたプログラムが正しいかどうかを確かめるには、比較する相手が必要だからです。
比較する相手というのは、現行の仕様が書かれた設計書と、動きを確認するテストケースです。人が手で書き換えた場合は、書いた本人が判断の理由を説明できます。AIが大量に変換した場合、一つひとつがなぜその形になったのかは追いにくいので、正しさは外側から確認するしかありません。実際、大手ベンダーのサービスでも、人が介在して最終判断と補完を行う仕組みを前提に組まれています。
この構造は、発注する側にとって少し皮肉な結果を生みます。設計書が残っていてテストも整っている会社ほどAIの恩恵を受けやすく、何も残っていない会社ほど、AIを使う前の土台づくりに費用がかかるということです。自社にその土台があるかどうかを先に確かめたい場合は、レガシーシステムの解析はどこまで必要？費用と頼み方で調査範囲の決め方を整理していますので、そちらから入ると順序がつながります。
レガシーシステムの刷新でAIの効果を見積もる
ここからは、実際に提案や見積書を受け取ったときの読み方です。数字の意味を取り違えないこと、そして前提を質問で埋めることの2つに絞って整理します。
短縮率は費用の割引率ではない
ベンダーの発表には具体的な数値が出てきます。たとえば富士通が2026年7月に提供を始めたAIドリブンモダナイゼーションサービスでは、工程期間を約40%短縮できるとしています。この種の数字を見たとき、確認したいのは3点です。
ひとつ目は、短縮されるのが「期間」なのか「費用」なのかです。この例で示されているのは工程期間であり、請求額が4割減るという意味ではありません。期間が縮んでも、投入する人数が変わらなければ費用はそれほど下がらないこともあります。ふたつ目は、どの範囲の工程を指しているのかです。全工程の合計なのか、変換工程だけなのかで意味がまったく変わります。
みっつ目は条件です。先の例では「大規模かつ複雑なモダナイゼーション案件において、AIによる自動化と並列実行を活用した場合」という条件が付いています。並列実行が効くのは対象が大きいときなので、中小規模の案件で同じ比率が出るとは限りません。数字そのものを疑う必要はありませんが、自社の規模と条件に当てはまるかは別問題として見ておくのが安全です。
見積書でAIの前提を切り分ける
見積書を受け取ったら、AIで代替する工程と人が担当する工程が分けて書かれているかを見てください。分かれていない見積書は、後から「そこはAIでは対応できませんでした」という追加費用の話になりやすいところです。
| 工程 | AIの効き方 | 見積書で確認すること |
|---|---|---|
| 現行システムの調査 | 下読みが速くなる | 人が確認する範囲がどこまでか |
| 引き継ぐ範囲の決定 | ほぼ効かない | 自社側の作業として計上されているか |
| プログラムの変換 | 効果が出やすい | どのAIを使い、精度が出ない場合どうするか |
| テストと確認 | 一部が自動化できる | 業務側が確認する件数と期間 |
| 本番切り替え | ほぼ効かない | 並行稼働の期間が短縮前提になっていないか |
特に注意したいのが最下段です。AIによる短縮を織り込んで全体スケジュールが引かれていると、本来は圧縮できない切り替え工程まで短く見積もられていることがあります。ここが破綻すると、本番直前で並行稼働の期間が足りなくなり、追加費用と現場の負担で跳ね返ります。刷新全体の費用がどう積まれるかは、基幹システム刷新の費用相場はいくら？内訳と見積もりの読み方で整理しています。
提案を受けたときに聞く4つの質問
技術の詳細が分からなくても、次の4つを聞けば提案の中身をかなり評価できます。相手が答えられるかどうか自体も、判断材料になります。
AI活用の提案で確認する4つの質問
- AIで代替するのはどの工程で、人が確認するのはどこまでか
- 変換に使うAIは何で、その言語向けに調整されたものか
- 生成したプログラムに不具合があった場合、責任と修正費用はどちらが持つか
- 当社のソースコードや業務データが、AIの学習に使われることはないか
3つ目は契約に直結します。AIが生成したという理由で品質の責任があいまいになると、後から揉めます。従来の請負と同じく、納品物の不具合はベンダー側が直すという前提を確認しておいてください。4つ目は情報管理の話で、社外のAIサービスを使う場合に自社のコードがどう扱われるかを、契約書か覚書のレベルで押さえておくと安心です。
AI活用をうたう会社をどう見るか
提案してくる会社をどう見るか、という点にも触れておきます。ここ数年でAI活用をうたう開発会社は一気に増えましたが、実際にレガシーの移行で使い込んでいる会社はまだ限られます。
見極めるうえで有効なのは、成功した話ではなく「うまくいかなかった箇所」を聞くことです。AIの変換精度が出なかった処理はどういうものだったか、そのときどう対処したか。実際にやっている会社は具体的に答えられますし、答えの中身から自社の案件との相性も見えてきます。逆に、できることだけを並べる提案は、まだ実案件の経験が薄い可能性があります。
あわせて、AIを使う前提の見積もりは従来型より前提条件が複雑になるため、書かれていない項目が増えがちです。見積もりの危険サインを見抜く60項目チェックシートで、前提の抜けや責任範囲の曖昧さを点検しておくと、比較の精度が上がります。
レガシーシステムの移行とAIについてよくある質問
- Q. AIを使えばレガシーシステムの移行費用は下がりますか？
- A. 工程によります。現行コードの読解と言語変換は短縮されやすい一方、引き継ぐ範囲の決定、テスト、本番切り替えはほとんど変わりません。移行プロジェクトは後者の比重が大きいため、全体費用が劇的に下がるとは考えないほうが安全です。提案で示された削減率が、どの工程を指しているのかを必ず確認してください。
- Q. COBOLはAIでJavaに自動変換できるのですか？
- A. 変換の取り組みは実用段階に入りつつあり、変換後にCOBOL特有の書き方が残らない形を目指す動きも出ています。ただし汎用の生成AIは古い言語の学習データが不足しており、精度が出にくいという指摘があります。どのAIを使うのか、精度が出なかった処理をどう扱うのかまで含めて提案を見る必要があります。
- Q. 設計書がない状態でもAIによる移行はできますか？
- A. 変換自体は進められますが、生成されたプログラムが正しいかを確かめる比較対象がないため、検証の負担が大きくなります。結果として、先に現行調査で設計情報を整えたほうが総額では安く収まることが多いです。設計書がない会社ほど、AIの前に土台づくりの費用がかかると考えておいてください。
- Q. AIが生成したプログラムの品質は誰が保証しますか？
- A. 契約で決めることです。AIを使ったかどうかにかかわらず、納品物の不具合を修正する責任は受注側にあるという前提を、契約書で確認してください。ここを曖昧にしたまま進めると、不具合が出たときに「AIの出力なので」という説明で追加費用の話になりかねません。
- Q. 自社のソースコードをAIに読ませても大丈夫ですか？
- A. 使うサービスの規約次第です。入力したデータが学習に使われない設定になっているか、どこのサーバーで処理されるかを確認してください。業務データを含むテスト用データを渡す場合は、範囲と保管期間も決めておきます。開発会社任せにせず、覚書のレベルで残しておくと後で確認できます。
