「生成AIを使えば、あのシステムの改修ももっと安くできるんじゃないか」——経営会議でそう問われて、言葉に詰まった経験はないでしょうか。稼働から10年以上が経った基幹システム。構築を担当したベンダーの担当者はもういない。設計書は断片しか残っていない。それでも小さな改修のたびに見積は上がり続け、稟議を通すのがますます難しくなっています。
困るのは、「AIで安くなるかどうか」を判断する材料が手元に何もないことです。ベンダー各社のモダナイゼーション記事を読んでも、大企業のメインフレーム刷新が前提だったり、「AIでこんなことができます」という機能紹介で終わっていたりして、肝心の「いくらかかって、いくら回収できるのか」が書かれていません。技術的な可否の話と、投資判断の話が、まったくつながらないのです。
実のところ、この分かりにくさには理由があります。AIによるレガシーコード改善は、「できること」と「できないこと」の境界が非常にはっきりしている一方で、その境界が業界内でもまだ十分に言語化されていないためです。そして費用対効果を左右するのは、AIツールそのものの料金ではなく、AIの出力を人が検証する工数という、見積書には現れにくいコストです。ここを押さえないまま導入すると、「AIを使ったのに、かえって時間がかかった」という結果になりかねません。
本記事では、レガシーコードのAI改善について、AIが実際に効く4つの領域と、逆に効かない領域を先に切り分けます。そのうえで、隠れコストを含めた費用対効果の試算手順、投資判断を通すためのKPI設計、そして丸投げにならない発注のしかたまでを、発注者の視点で順に整理します。読み終えたときに、自社の状況に当てはめて「どこまでAIに任せ、いくら投じて、何で回収を測るのか」を自分の言葉で説明できる状態になることを目指します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
レガシーコードのAI改善とは？従来のリファクタリングと変わる3つの点
まず、言葉の輪郭をはっきりさせておきます。ここを曖昧にしたまま話を進めると、ベンダーとの会話が噛み合わなくなり、見積の比較もできなくなってしまいます。
「レガシーコードのAI改善」とは、長年運用されてきた既存システムのソースコードに対して、生成AIやAIコーディングツールを使って、解析・ドキュメント復元・テスト整備・書き換えといった作業を支援・自動化する取り組みを指します。ポイントは、改善の対象がコードそのものである点です。
AIリファクタリングとは何を指すのか
「AIリファクタリング」という言葉は広く使われていますが、実際には性質の異なる3つの系統がひとまとめにされています。それぞれ得意分野も費用構造も違うため、分けて理解しておくと判断がしやすくなります。
系統 | 何をするものか | 向いている用途 |
|---|---|---|
AIコーディングエージェント | 対話しながらコードを読み、修正案を生成する。Cursor や Claude Code などが該当します | 個別機能の調査・改修、テスト生成、仕様の読み解き |
コード変換・自動リファクタリングツール | 構文木などの機械的な解析に基づき、決められた変換ルールを大量のファイルに一括適用します | ライブラリのバージョン更新、定型的な書き換えの横展開 |
静的解析・可視化系AI | コード全体を走査し、依存関係・重複・複雑度などを構造として提示します | 着手箇所の優先順位付け、影響範囲の把握 |
発注者が「AIでリファクタリングしたい」とだけ伝えると、ベンダー側は3つのどれを想定してよいか分かりません。後述する費用の議論も、どの系統を使うかで前提が大きく変わります。まずは「調査をAIで効率化したいのか」「書き換えそのものを任せたいのか」を切り分けて伝えるところから始めてください。
「AI連携」と「AI改善」は別物——目的別の使い分け
もうひとつ、混同されやすいのが「レガシーシステムのAI連携」との違いです。
AI連携は、既存システムには基本的に手を入れず、AI機能を外側から付け足すアプローチです。たとえば問い合わせ対応にチャットボットを載せる、蓄積されたデータをAIで分析する、といった取り組みが該当します。目的は新しい価値の追加であり、既存コードの保守性は改善されません。
一方でAI改善は、既存コードの構造そのものに手を入れて、保守しやすい状態に戻す取り組みです。目的はコスト構造の改善であり、見た目の機能は何も増えません。経営層への説明では、この「機能は増えないが、今後の改修が安くなる」という性質をあらかじめ伝えておかないと、投資の意義が伝わりにくくなります。
自社の課題が「既存システムを活かしつつAIで新しい機能を持たせたい」側にある場合は、レガシーシステムのAI連携の考え方のほうが適しています。目的が違えば打ち手も費用構造も変わりますので、どちらの話をしているのかを社内で揃えておくことをおすすめします。
従来のリファクタリングと変わらない部分
AIを使うと何が変わるのかを整理すると、大きく3点です。1つ目はコード理解のスピードで、人が数日かけて読み解いていた処理の流れを、短時間で概要レベルまで把握できるようになります。2つ目はドキュメント不在への耐性で、設計書がなくても実装から仕様を推定する作業が現実的な工数で回せるようになります。3つ目は着手コストの下限が下がることで、「調査だけで数十万円かかるから手をつけられない」という状態を抜け出しやすくなります。
一方で、変わらない部分のほうが重要です。書き換える前にテストで安全網を張る必要があること、一度に全部を変えず段階的に移行すること、変更の妥当性を最終的に人が判断すること——これらの原則は、AIを使っても一切変わりません。むしろAIは変更を高速に生成できる分、検証の仕組みが弱いチームでは品質の低い変更が速く積み上がるだけになります。Google の DORA が公開した 2025 年の調査報告でも、AIは組織のあり方を増幅する存在であり、プロセスが整っていないチームでは問題が加速すると指摘されています（DORA State of AI-assisted Software Development 2025）。
AIがレガシーコード改善で実際に効く4つの領域
ここからは、AIが投資効果を出しやすい領域を4つに分けて具体化します。それぞれ「何を入力して何が出てくるのか」「人が必ず検証すべき点は何か」をセットで見ていきます。作業単位まで分解しておくと、後の費用試算がぐっと現実的になります。
コード解析・依存関係の可視化——どこから手をつけるかを決める
レガシーコード 解析にAIを使う場合、最初の用途は「地図を作ること」です。リポジトリ全体を読み込ませ、機能単位のまとまり、モジュール間の依存関係、特定のテーブルや外部APIを参照している箇所の一覧などを出力させます。
この工程の価値は、改修の見積精度が上がることにあります。「この画面を直したい」という要望に対し、影響が及ぶ範囲が事前に見えていれば、ベンダーの見積に含まれるリスクバッファを減らせる可能性があります。逆にこの地図がないと、ベンダー側は不確実性を価格に上乗せせざるを得ません。見積高騰の一因は、実はここにあります。
人が検証すべきなのは、AIが提示した依存関係の漏れです。設定ファイルや動的な呼び出し、バッチ処理からの参照などは、AIが見落とすことがあります。可視化の結果は「確定した事実」ではなく「確度の高い仮説」として扱い、重要な箇所は実コードで裏を取ってください。
仕様書・設計書の復元——ドキュメント不在のブラックボックスを開ける
生成AI 設計書 自動生成が最も威力を発揮するのが、この工程です。実装コードを入力として、画面ごと・機能ごとの処理内容、入力値のバリデーション条件、分岐条件の一覧などを自然言語のドキュメントとして出力させます。前任者が不在でドキュメントも残っていないという状況では、これまで人が数週間かけて行っていた読み解き作業が、大幅に圧縮できる可能性があります。
ただし決定的な注意点があります。AIが復元できるのは「実装がどう動いているか」であって、「本来どう動くべきか」ではありません。実装にバグが含まれていれば、そのバグを含んだ挙動が仕様として記述されます。つまり出力されたドキュメントは、仕様書ではなく「現状の挙動の記録」です。
したがって復元後には、業務担当者との照合が必ず必要になります。復元されたドキュメントを業務部門に見せ、「実際の業務ではこう運用している」「この分岐は使っていない」といった認識との差分を洗い出す工程です。ここを省くと、誤った挙動を正しい仕様として固定してしまい、後の書き換えで問題が表面化します。この照合工程の工数は、後述するコスト試算に必ず織り込んでください。
テストコードの自動生成——書き換え前に安全網を張る
テストコード 自動生成 AIは、既存コードの振る舞いを固定するための「特性テスト」を用意する用途で有効です。現在の入力と出力の組み合わせをテストとして記録しておけば、書き換え後に挙動が変わってしまったことを機械的に検知できます。稼働中の業務を止めないための、もっとも実務的な安全装置です。
レガシーシステムの改修が高額になりやすい理由のひとつは、テストが存在しないために回帰確認をすべて手作業で行っている点にあります。AIでテストを整備しておけば、この確認コストを継続的に下げられます。しかもテストは一度作れば資産として残り続けるため、投資回収の観点でも効きやすい領域です。
検証すべきは、生成されたテストが「意味のある検証をしているか」です。AIは実装をなぞってテストを書くため、実装と同じ誤りを前提にしたテストが生成されることがあります。また、テストの本数が多いこと自体には価値がありません。重要な業務ロジックの分岐を押さえているか、という観点で人がレビューしてください。
コード変換・書き換え——言語／フレームワーク移行における現実的な適用範囲
最後が、実際の書き換えです。古いフレームワークから新しいバージョンへの移行、非推奨APIの置き換え、重複コードの整理といった作業がここに含まれます。
適用範囲を考えるうえで有用な整理があります。海外のリファクタリング支援ツール企業のCEOは、ソースコードそのものをLLMに読み込ませて書き換える方式について、「AIコーディングツールを使う採算が取れない。利用料金だけで数百万ドルに達する恐れもある」と述べています（TechTarget Japan「AIにコードは書かせない――レガシーアプリの自動リファクタリング"新常識"」）。同社は、AIには変換ルール（レシピ）の作成だけを担わせ、実際の大量変換は機械的な変換エンジンに任せる方式を採っています。
ここから読み取るべきは、「書き換えの物量が大きくなるほど、LLMに直接読ませる方式は費用面で不利になる」という構造です。定型的な置き換えを何千ファイルにも適用するのであれば、決定論的な変換ツールのほうが安く確実です。逆にAIコーディングエージェントが向いているのは、判断を要する少量の改修や、変換ルール自体の設計です。この使い分けを見積段階でベンダーと合意しておくと、費用の見通しが立てやすくなります。
AIリファクタリングが効かない領域と、費用対効果を毀損する失敗パターン
投資判断を誤らせる最大の要因は、AIができることの過大評価です。ここでは意識的に「効かない側」を扱います。効かない領域を先に潰しておくことで、後の費用試算が現実的な前提に立てるようになります。
AIが判断できないこと——仕様の妥当性と業務上の例外処理
AI リファクタリング 限界として最初に押さえるべきは、業務的な正しさの判断です。
AIはコードを読んで「何をしているか」を説明できます。しかし「その処理が業務上正しいか」は判断できません。たとえば、特定の取引先だけ締め日の計算が異なる処理があったとして、それが現場の運用に合わせた意図的な仕様なのか、過去の実装ミスがそのまま残っているのかは、コードを見ても分かりません。判断できるのは業務担当者だけです。
同様に、長年の運用で積み上がった例外処理も、AIには扱いが難しい領域です。「本来は不要なはずだが、消すと特定の帳票が出なくなる」といった、経緯が失われたまま生き残っている処理は、レガシーシステムには必ずと言っていいほど存在します。これらを機械的に整理すると、業務が止まります。
したがって、AI改善のプロジェクトでは「業務部門との確認工程」を必ず設計に含めてください。ここを削るとコストは下がりますが、下がった分がそのままリスクに置き換わるだけです。
一括変換が破綻する境界線——「検証しきれない量」を作らない
2つ目の限界は物量です。「AIに全部読ませて、まとめて書き換えてもらえばいい」という発想は、2つの意味で破綻します。
ひとつは、AIが一度に扱えるコンテキストの量には上限があることです。システム全体の文脈を保ったまま、全ファイルを整合的に書き換えるのは現実的ではありません。もうひとつは、より深刻な問題として、出力された変更を人が検証しきれなくなることです。数千ファイル分の差分を提示されても、レビューできなければ品質は担保できません。
判断の目安はシンプルです。人がレビューしきれる量を超える変更を、一度に生成させない。これを守るだけで、失敗パターンの大半は避けられます。具体的には、1回の変更単位を機能単位・画面単位に区切り、そのたびにテストで検証してから次に進む形にします。結果として、一括変換より時間はかかりますが、やり直しが発生しない分だけ総コストは安定します。
「速くなったつもり」の罠——AI活用で生産性が落ちる条件
そして、発注者がもっとも陥りやすいのが、体感と実測の乖離です。
AI研究機関の METR が2025年に実施したランダム化比較試験では、経験豊富なオープンソース開発者が、慣れ親しんだ大規模リポジトリで実際の課題に取り組みました。結果は、AIツールを使えた場合のほうが作業完了までの時間が 19% 長く なったというものでした。さらに注目すべきは、当の開発者たち自身は作業後に「AIによって 20% 速くなった」と見積もっていた点です（METR "Measuring the Impact of Early-2025 AI on Experienced …）。
この研究は16名・246課題という限定的な条件で行われたもので、METR 自身も調査時点のツールと開発手法を反映した結果であると位置づけています。そのため「AIは常に遅い」という一般化はできません。しかし発注者にとっての示唆は明確です。AIの効果は、体感では測れないということです。
対象システムの文脈が複雑であるほど、AIの提案を検証・修正する時間が増え、正味の生産性が下がる可能性があります。そして関係者は「AIのおかげで速くなった」と感じたまま、実際には工数が増えている——この状態が続くと、投資対効果の評価そのものが成り立ちません。だからこそ、次に述べるベースラインの測定が決定的に重要になります。
なお、AIが生成したコードが新たな負債になるリスクにも触れておきます。レビュー体制が追いつかないまま生成コードを取り込み続けると、「誰も意図を説明できないコード」が再び増えていきます。せっかく解消した状態に戻ってしまうわけです。AI改善を行う際は、生成コードに対するレビュー基準とテストの必須化を、あらかじめ運用ルールとして決めておいてください。
AI活用リファクタリングの費用対効果をどう試算するか
ここからが本題です。AI リファクタリング 費用対効果を判断するには、コスト側とリターン側をそれぞれ分解し、回収期間で見る必要があります。他社の実績値を眺めても自社の判断材料にはなりませんので、自社の数字を入れて計算できる形で整理します。
コスト側の内訳——見落とされやすい3つの隠れコスト
AI改善のコストは、大きく次の5項目に分解できます。このうち後半3つが、見積段階で見落とされやすい「隠れコスト」です。
コスト項目 | 内容 | 見落としやすさ |
|---|---|---|
調査・解析工数 | コード解析、依存関係の可視化、対象範囲の確定 | 低（見積に明示されやすい） |
改修・書き換え工数 | 実際のリファクタリング作業 | 低 |
AI出力の検証・レビュー工数 | 復元したドキュメントの業務照合、生成コードのレビュー | 高 |
AIツール・トークン利用料 | 月額ライセンス料および従量課金分 | 高（変動幅が読みにくい） |
リグレッションテスト整備費 | 特性テストの作成と実行環境の整備 | 高 |
とくに注意したいのが、AI出力の検証工数です。AIは出力を速く大量に生成しますが、それを確認する人の速度は変わりません。つまり生成量が増えるほど、検証がボトルネックになります。実務上は、「AIで削減できた作業工数のうち、相当部分が検証工数として戻ってくる」と見込んでおくのが安全です。この前提で試算しておけば、想定を下回ることは起きにくくなります。
AIツールの利用料も、定額とは限りません。従量課金の場合、扱うコード量や試行回数に応じて変動します。見積段階では「誰が費用を負担するのか」「上限額をどう設定するのか」をベンダーと明確にしておいてください。この点は後の発注時の確認項目としても改めて取り上げます。
リターン側の内訳——保守工数・障害対応・リードタイムの3本立て
リターン側は、次の3つに分けて考えると経営層にも説明しやすくなります。
1つ目は、保守・改修工数の削減です。 自社の年間の保守委託費と改修案件費の合計を出し、そのうち「調査・影響範囲の特定」に費やされている割合を見積もります。ベンダーに工数内訳を開示してもらえば概算できます。AI改善で効くのは主にこの調査部分ですので、削減率はここに掛けて計算します。全体の費用に対して一律の削減率を掛けると、過大な期待値になってしまうので注意してください。
2つ目は、障害対応コストの削減です。 過去1年の障害件数と、1件あたりの平均対応工数を集計します。テストが整備されることで、変更起因の障害はある程度抑制できます。ここには復旧作業の人件費だけでなく、業務停止によって発生した損失も含めて評価すると、経営層に響く数字になります。
3つ目は、改修リードタイム短縮による機会損失の回避です。 「この機能を追加したかったが、3か月かかると言われて見送った」という案件が、過去にいくつあったかを洗い出してください。リードタイムが短縮されればこれらが実行可能になります。金額換算が難しい項目ですが、投資判断の場では「できなかったことができるようになる」という定性的な説明として機能します。
なお、レガシーシステムを放置した場合の損失については、経済産業省が「DXレポート」で、企業がレガシーシステムの刷新を進められない場合に2025年以降で最大年間12兆円規模の経済損失が生じうると試算しています（出典: 経済産業省「DXレポート ～ITシステム『2025年の崖』克服とDXの本格的な展開～」2018年）。これは国全体の試算であり自社の数字ではありませんが、「何もしないことにもコストがある」という論点を提示する材料としては使えます。
回収期間で判断する——投資判断の考え方と、判断を保留すべきケース
コストとリターンが揃ったら、単純な回収期間で判断します。
回収期間（年） = 投資総額 ÷ 年間削減額
投資総額には前述の5項目すべてを含めます。年間削減額には、保守・改修工数の削減額と障害対応コストの削減額を入れ、機会損失の回避分は保守的に除外しておくと、説明時の説得力が増します。
判断の目安として、システムの残存利用予定年数と回収期間を比較してください。あと3年で刷新予定のシステムに、回収期間5年の投資をするのは合理的ではありません。逆に、今後10年使い続ける前提であれば、回収期間が数年でも投資として成立します。残存利用年数を超える回収期間なら、AI改善ではなく別の選択肢を検討すべきというのが、シンプルで説明しやすい判断軸です。
また、次のような場合は判断を保留し、先に小規模な検証を行うことをおすすめします。
- 対象システムの規模・構造が把握できておらず、投資総額の見積幅が2倍以上ある場合
- 業務部門との仕様確認に協力を得られる体制が固まっていない場合
- 削減額の根拠となる現状の保守工数が、社内で把握できていない場合
これらの状態でいきなり全体への投資を決めると、試算の前提が崩れたときに引き返せなくなります。後述するスモールスタートの進め方で、実測値を取ってから判断するほうが確実です。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
投資判断を通すためのKPI設計と、経営層への説明の組み立て方
試算ができても、稟議が通らなければ意味がありません。ここでは、社内で説明するための指標設計と、説明の組み立て方を整理します。
着手前に測っておくべきベースライン
もっとも多い失敗が、着手前の数値を測っていないことです。前述のとおり、AI活用の効果は体感では測れません。比較対象がなければ、後から「効果があった」とも「なかった」とも言えなくなります。
着手前に記録しておくべき数値は、次の4つで足ります。
- 直近1年の改修案件について、依頼から本番リリースまでの平均日数
- 直近1年の改修案件の平均見積金額と、そのうち調査工程が占める割合
- 直近1年の障害件数と、1件あたりの平均対応時間
- 現在の保守委託費（年額）
いずれも新たな計測ツールを入れずに、既存の発注履歴と障害記録から集計できるはずです。1日で揃う作業ですので、AI改善を検討し始めた時点で押さえておいてください。
稟議で使う指標は3〜5個に絞る
技術的な指標は無数にありますが、稟議の場に持ち込む指標は3〜5個に絞ります。取得に手間がかかる指標を並べても、継続して測定できなければ形骸化するだけです。
指標 | 見るもの | 取得方法 |
|---|---|---|
改修リードタイム | 依頼から本番リリースまでの日数 | 既存の案件管理記録から集計 |
変更起因の障害率 | リリース後に発生した障害の割合 | 障害記録から集計 |
調査工程の工数比率 | 改修見積に占める調査・解析の割合 | ベンダーの工数内訳から取得 |
ドキュメント・テストの整備率 | 仕様書が存在する機能／テストが存在する機能の割合 | 対象一覧を作成してカウント |
技術的負債 可視化の観点では、最後の整備率が扱いやすい指標です。「主要機能50本のうち、仕様書があるのは12本、テストがあるのは3本」といった形で示せば、技術に明るくない経営層にも現状が伝わります。負債の棚卸しや優先順位付けの進め方については、技術的負債の解消を扱った記事で詳しく整理していますので、あわせて参考にしてください。
ひとつ注意点があります。指標を目標として設定すると、数値を満たすこと自体が目的化しがちです。たとえばテスト整備率を目標にすると、意味の薄いテストが量産されることがあります。指標はあくまで状態を把握するための道具として扱い、目標値の達成を評価軸にしすぎないほうが健全です。
経営層への説明はこの順序で組み立てる
説明の順序も重要です。技術的な説明から入ると、投資の必要性が伝わる前に関心が離れてしまいます。次の順序で組み立てると、判断に必要な情報が過不足なく並びます。
- 現状の損失を数字で示す——「改修見積が3年で1.8倍になった」「昨年の障害対応に延べ何人日を要した」など、すでに発生しているコストを提示します
- 打ち手の範囲を明示する——AIで対応する範囲と、人が判断する範囲を切り分けて示します。「全部AIに任せる」と受け取られないことが重要です
- 投資額を内訳付きで提示する——検証工数とツール利用料を含めた総額を出します。隠れコストを最初から開示しておくと、後の追加請求で信頼を損なう事態を避けられます
- 回収見込みと回収期間を示す——保守的な前提で算出した数字を使います
- やらない場合のリスクを示す——システムの残存利用年数、保守できる人材の確保見通し、改修見積の上昇トレンドを提示します
この順序であれば、経営層が判断に必要とする「今いくら失っていて、いくら投じて、いつ回収できて、やらないとどうなるか」が揃います。
発注者としての進め方——スモールスタートで検証する4ステップ
レガシーシステムのモダナイゼーションは、全体を一度に置き換える進め方を取ると、試算の前提が崩れたときに引き返せなくなります。前提が正しいかどうかは、実際に小さく試してみないと分かりません。ここでは、レガシーシステムのモダナイゼーションをリスクの低い形で進めるための手順を、4ステップで整理します。
ステップ1〜2: 範囲を絞り、安全網を先に作る
ステップ1は、対象範囲を1機能に絞ることです。 選ぶ基準は「改修頻度が高く、かつ業務上の影響が限定的な機能」です。改修頻度が高ければ効果が測りやすく、影響が限定的であれば万一の際のリスクを抑えられます。基幹の決済処理のような、止まると業務全体が停止する領域は最初の対象には向きません。
このステップで発注者側が用意すべきものは、対象機能の業務上の位置づけと、確認に協力してもらえる業務担当者の確保です。ベンダーに任せるのは、技術的な影響範囲の調査です。ここを分担しておかないと、ベンダーは業務的な重要度を判断できないまま作業することになります。
ステップ2は、仕様書の復元とテスト整備を先行させることです。 いきなり書き換えるのではなく、まず現状の挙動をドキュメントとテストとして固定します。復元したドキュメントは業務担当者と照合し、認識の差分を洗い出します。この工程は一見遠回りに見えますが、後の書き換えでの手戻りを大きく減らします。
ここで発注者側が担うのは、復元されたドキュメントのレビューです。「この処理は現場の運用と合っている」「この分岐はもう使っていない」という情報は、社内にしかありません。ベンダーに丸投げできない部分であり、同時にプロジェクトの成否を分ける部分でもあります。
ステップ3〜4: 実測して横展開を判断する
ステップ3は、小さく書き換えて効果を実測することです。 ステップ2で作った安全網の範囲内で、実際のリファクタリングを行います。このとき必ず、要した工数・AIツールの利用料・検証にかかった時間を記録してください。とくに検証時間は、次の横展開の見積を左右する最重要データです。
ステップ4は、実測値をもとに横展開の可否を判断することです。 ステップ3で得た「1機能あたりの実コスト」を、対象機能数に掛けて全体の投資額を再計算します。着手前の試算と大きくずれていれば、前提を見直します。ずれが小さければ、そのまま横展開の稟議に進めます。
この進め方の利点は、判断を保留したまま前に進める点にあります。ステップ3までで「思ったほど効果が出ない」と分かった場合、そこで止めれば損失は1機能分の投資に収まります。全体への投資を一度に決めるより、はるかに安全な形です。
AI改善を外注するときの見極めポイント
社内にAIを使いこなせる人材がいない場合、外注が現実的な選択肢になります。ここでは、発注先を選ぶ際の確認項目を整理します。
見積書で確認すべき4項目
レガシーコード 改善 外注の見積を比較する際、金額の総額だけを見ても判断できません。次の4項目が明示されているかを確認してください。
1つ目は、AI出力の検証プロセスを説明できるかです。 「AIが生成したコードを、誰が、どういう基準でレビューするのか」に答えられないベンダーは、検証工数を見積に織り込んでいない可能性があります。安い見積が出てきた場合、この工程が抜けていないかを疑ってください。
2つ目は、ドキュメント不在の既存システムの調査実績があるかです。 AI改善の成否は、書き換えの技術力よりも、初期調査の設計で決まります。秋霜堂株式会社でも、前任者が不在でドキュメントも残っていない既存システムについて、初期調査から改善対応までを継続的に実施してきましたが、この種の案件では「実装から現状の挙動を把握し、業務側の認識と突き合わせる」工程をどう組み立てるかが、その後の工数を大きく左右します。実績の有無は、具体的な進め方を質問すれば判断できます。
3つ目は、成果物の引き継ぎが契約に含まれているかです。 AI改善の過程で生成される仕様書とテストコードは、そのまま自社の資産になります。これらが納品対象に含まれているか、著作権や利用範囲の扱いはどうなっているかを、契約段階で確認してください。含まれていなければ、次に別のベンダーに依頼する際に同じ調査費用を再び払うことになります。
4つ目は、AI利用料の負担区分が明記されているかです。 従量課金部分を誰が負担するのか、上限はあるのか、超過した場合の扱いはどうなるのかを確認します。ここが曖昧なまま進むと、想定外の追加請求につながります。
AI改善で延命できる範囲を超えたときの判断
最後に、AI改善では対応しきれないケースについても触れておきます。
次のような状況では、部分的な改善を重ねるより、刷新を検討したほうが総コストは低くなる可能性があります。
- 使用している言語・フレームワークのサポートが終了しており、セキュリティ更新が受けられない
- 動作しているサーバーやミドルウェアが保守期限切れで、環境ごと移行が必要になる
- 業務プロセス自体が大きく変わっており、現行の機能構成が実態と合っていない
- 試算した回収期間が、システムの残存利用予定年数を超える
これらに該当する場合は、レガシーシステムの刷新の判断基準を確認したうえで、改善と刷新の比較検討に進むことをおすすめします。AI改善はあくまで既存資産を活かす手段であり、すべての状況に適した打ち手ではありません。
まとめ——AI改善の投資判断は「効かない領域の線引き」から始まる
レガシーコードのAI改善について、効く領域・効かない領域・費用構造・進め方を整理してきました。最後に、明日から取れる行動の順序で要点を振り返ります。
第一に、線引きをすることです。 AIが効くのは、コード解析、仕様書の復元、テストの生成、そして判断を要する少量の書き換えです。効かないのは、業務ロジックの妥当性判断と、人が検証しきれない量の一括変換です。この境界を社内で共有しておけば、ベンダーとの会話も、経営層への説明も噛み合うようになります。
第二に、着手前のベースラインを測ることです。 改修リードタイム、改修見積に占める調査工程の割合、障害件数、保守委託費——この4つを記録しておいてください。AIの効果は体感では測れないという事実は、METR の研究が示したとおりです。比較対象がなければ、投資の成否を語ることができません。
第三に、1機能から始めることです。 改修頻度が高く影響範囲の限定的な機能を選び、仕様書の復元とテスト整備を先行させ、小さく書き換えて実測する。得られた「1機能あたりの実コスト」こそが、横展開の稟議で最も説得力を持つ数字になります。
第四に、隠れコストを最初から開示することです。 AI出力の検証工数、ツールの利用料、テスト整備費を含めた総額で回収期間を示せば、後から前提が崩れる事態を避けられます。保守的な前提で出した数字のほうが、結果として信頼されます。
AIを使えばすべてが安くなるわけではありませんし、逆にAIを避ければ安全というわけでもありません。判断の材料は、他社の事例ではなく自社で測った数字の中にあります。まずは手元の発注履歴と障害記録から、現状の数字を揃えるところから始めてみてください。
関連情報
既存システムの改善方針や外部委託の進め方を社内で検討される際には、お役立ち資料もあわせてご活用ください。検討の整理にお使いいただける内容をまとめています。
ドキュメントが残っていない既存システムの調査や、AI活用を含む改善範囲の切り分けについてご相談がある場合は、お問い合わせフォームよりご連絡ください。投資判断の前段となる現状把握の段階からご相談いただけます。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- レガシーコードのAI改善は、何から着手すればよいですか？
全体を一度に置き換えるのではなく、改修頻度が高く業務影響の限定的な1機能に絞って着手してください。仕様書復元とテスト整備を先行させ、小さく書き換えて効果を実測してから横展開を判断するのが安全な進め方です。
- AI改善とAI連携（チャットボット導入など）はどちらを検討すべきですか？
既存コードの保守コストを下げたいならAI改善、新しい機能を外側に加えたいならAI連携が適しています。前者はコードの中身に手を入れてコスト構造そのものを変える取り組み、後者はコードにはほぼ触れず外部から機能を付け足す取り組みで、狙う効果も費用の内訳も異なります。社内で「AI活用」とだけ話すと両者が混同されやすいため、まずどちらの話をしているのかを揃えておくことをおすすめします。
- 社内にAIコーディングエージェントの実務経験者がいない場合、どう進めればよいですか？
外注時に見積書で4点を確認してください。AI出力の検証プロセスを説明できるか、ドキュメント不在の既存システムでの調査実績があるか、仕様書やテストコードなど成果物の引き継ぎが契約に含まれているか、AI利用料の負担区分が明記されているか、です。特にAI改善の成否は書き換えの技術力より初期調査の設計力で決まるため、この分野の実績を具体的な進め方まで質問して見極めることが重要です。
- 過去の保守工数のデータが社内に残っていない場合、費用対効果は試算できますか？
発注履歴と障害記録から、改修リードタイム・見積金額・障害件数・保守委託費の4項目を集計すれば試算可能です。いずれも新たな計測ツールなしに既存記録から1日程度で揃うため、検討を始めた時点で先に押さえておいてください。
- AI改善の投資は何年で回収を見込めばよいですか？
「投資総額 ÷ 年間削減額」で算出した回収期間を、対象システムの残存利用予定年数と突き合わせて判断します。この年間削減額を出す際、金額換算が難しい機会損失の回避分はあえて含めず、保守・改修工数と障害対応コストの削減額だけで保守的に見積もっておくと、後から前提が崩れにくく経営層への説明でも説得力が増します。
