古いシステムの改修は全面刷新しかない？既存システムを読み解いて変更可能にする方法
古いシステムを改修したい場合は、全面刷新するしかないと考えていませんか。
作った人はすでに退職している。仕様書が残っていない、仕様書はあっても、いつの版なのか分からない。触ったときに何が壊れるか読めないので、現場から来る小さな改修依頼も「できません」と返すしかない。情報システム部門でこの状態に置かれると、話はたいてい「もう作り直すしかない」と判断されてしまいます。
ただ、作り直しは金額も期間も大きく、途中で問題が起きた際の損失も大きくなります。
しかし、近年のAIや新しいテクノロジーを活用し、まず既存システムを読み解き、変更できる状態をつくる方法があります。
目次
- なぜ「全面刷新しかない」と感じるのか
- 「読み解く」とは具体的に何をする作業か
- 刷新せずに変更できる状態をつくった事例
- 刷新前に決める4つのこと
- 仕様書がないシステムの改修は スパイクスタジオまでご相談ください
なぜ「全面刷新しかない」と感じるのか
はじめに、これは特殊な状況ではありません。経済産業省・デジタル庁・IPAが事務局を務める「レガシーシステムモダン化委員会」の総括レポート（2025年5月公表）では、ユーザー企業の61%がレガシーシステムを保有していると報告されています。同じレポートでは、メインフレームのシステムを有していた企業のうち52%はメインフレーム以外へ移行しているとも示されました。移行を終えた企業も出てきている一方で、抱えたままの企業のほうがまだ多い、という状況です。
そのうえで、改修が止まる理由は3つに分かれます。
仕様書が現物と合っていない
改修のたびにコードだけを直し、設計書の更新は後回しになる。これが何年も続くと、コードと文書のどちらが正しいのか誰にも分からなくなります。こういった書かれていることが嘘になっている文書は、誤解を生むので仕様書が無いより危険です。
言語や書き方の混在も解析を難しくします。富士通は、メインフレーム上のCOBOLについてさまざまな記述方法の膨大なCOBOLが約40年の歴史の中で存在し、解析が困難だったと説明しています。1つのシステムの中に、さまざまな世代の「常識」が積み重なっている状態です。
作った人が社内にいない
設計の意図はコードに書かれません。「なぜこの条件分岐があるのか」「なぜこの日付だけ例外処理なのか」は、作った人の記憶の中にあるケースが発生します。しかし、その方が会社を辞めると、コードは残っても判断の根拠が消えるのです。
経済産業省の「DXレポート」（2018年9月7日公表）は、既存システムの複雑化・老朽化・ブラックボックス化を放置した場合、保守運用の担い手不在によるリスクが高まり、システムの維持管理費が高額化してIT予算の9割以上が技術的負債の維持に向かう可能性があると指摘しました。また、このレポートは、克服できない場合に2025年以降で最大12兆円／年（当時の約3倍）の経済損失が生じる可能性も試算しています。
直したときの影響範囲が読めない
影響範囲が読めないと、見積もりが立ちません。そして見積もりが立たないまま始まった計画は、途中で膨らみます。日経コンピュータが1,201人から1,745件のプロジェクトについて回答を得た調査では、成功率は52.8%でした。この調査は、スケジュール・コスト・満足度の3つをすべて満たしたものだけを成功と定義しています（2018年の調査から、品質に代えて満足度を採用）。
同じ調査をもとにした日経クロステックの記事では、計画よりも遅延したプロジェクトは1,745件中513件（29.4%）で、遅延理由の最多は「仕様変更が相次いだ」の37.4%（n=513、複数回答）と報告されています。中身が分からないまま計画を固め、あとから仕様が出てくるという構図は、仕様書のないシステムを刷新する場面とそのまま重なります。
3つとも、原因は「刷新していないこと」ではなく「中身が分からないこと」です。だから、刷新を決める前に着手できる作業があります。
「読み解く」とは具体的に何をする作業か
読み解く作業は、次の4つに分けられます。順番に意味があり、飛ばすと後戻りが発生します。
1. 現物を確定させる
最初にやるのは資料集めではなく、対象の確定です。稼働中のソースコード、データベースの定義、バッチのジョブ定義、実際に出力されている帳票やCSV、稼働中の設定値を集め、日付を切って版を固定します。
ここで決めるのは1つだけです。ドキュメントと現物が食い違ったら、動いているコードとデータを正とする。この原則を先に合意しておくと、以降の作業で「どちらが本当か」という議論が起きません。仕様書は参考資料に格下げする、と決めるのが実際的です。
2. コードから仕様を復元する
次に、コードから処理の一覧と業務ルールを書き起こします。生成AIとコード解析を組み合わせると、人手だけで行うより速く進みます。後述する富士通のサービスでは、設計書の生成にかかる時間が約30分の1に短縮されたと発表されています。
ただし、復元したものをそのまま信じてはいけません。生成された設計書は「コードにこう書いてある」の要約であって、「業務としてこれが正しい」の保証ではありません。復元物は必ず業務側の担当者が査読し、実際の運用と違う箇所に印を付けていきます。この査読で見つかる差分が、あとで一番効きます。
3. 影響範囲を可視化する
プログラム間の呼び出し関係、テーブルの参照・更新箇所、外部システムとの連携点を機械的に洗い出します。「この項目を変えると、どこが動くか」を一覧で持てるようにするのが目的です。
ここまでできると、改修依頼への回答が変わります。「分からないのでできません」ではなく「この範囲に影響が出るので、確認に2人日ください」と言えるようになります。止まっていた依頼が動き出すのは、たいていこの段階です。
4. テストで挙動を固定する
仕様が分からなくても、いまの入出力は記録できます。本番と同じ入力を流し、出力を保存して、それを回帰テストの期待値にします。仕様が言葉で説明できなくても「変更後も今と同じ結果になるか」は機械的に判定できます。
この考え方が、仕様書のないシステムに手を入れるときの安全網になります。テストを先に用意してから改修に入ると、壊したかどうかがその日に分かります。
刷新せずに変更できる状態をつくった事例
やり方は大きく3つの型に分かれます。型ごとに1件ずつ、公表されている事例を紹介します。あわせて、中身が分からないまま刷新に踏み切った場合に何が起きたのかも1件挙げます。
①仕様書をAIで復元した｜富士通・SMBC日興証券
富士通は2026年3月30日、ソースコードから設計書を自動生成するサービス「Fujitsu Application Transform powered by Fujitsu Kozuchi」を、SaaSとして国内で提供開始しました。生成AIと独自のナレッジグラフ拡張RAG（検索した情報を生成AIに与えて回答させる仕組み）でCOBOLなどのソースコードを解析し、設計書を起こす仕組みです。前身の「設計書リバースサービス for アプリケーション資産」は2025年2月に提供が始まっています。SMBC日興証券の常務執行役員はプレスリリースの中で、2025年度より富士通とともにCOBOLをはじめとしたレガシー言語の設計書リバースに関する共同検証を進めてきたと述べています。
富士通が背景として挙げているのは、さまざまな記述方法の膨大なCOBOLが約40年の歴史の中で積み上がり、解析が困難だったことです。発表では、設計書生成の時間が約30分の1に短縮、COBOLでも抜け漏れなく設計書を自動生成でき網羅性は95%向上、可読性は従来比60%向上とされています。（富士通のプレスリリース 2026年3月30日）
②機能ごとに置き換えた｜オイシックス・ラ・大地
オイシックス・ラ・大地は、24時間365日稼働するECサイト「Oisix」のモノリシックなアプリケーションをマイクロサービス化するとき、全面書き換えを選びませんでした。採用したのはストラングラーパターン（既存システムを包む形で新実装に少しずつ移す進め方）です。
既存システムと新システムの間に置く「ストラングラーファサード」には、以前から使っていたALB（Application Load Balancer）とAPI Gatewayを利用しました。ALBで新しいアプリケーションへのルーティングを制御し、API Gatewayで新規に開発するRESTful APIへのルーティングを実現する形です。工数やコストの数値は公表されていませんが、稼働を止めずに機能単位で移していく進め方が＠ITの記事（2020年1月）で公開されています。切り替えの単位が小さいので、問題が出たときに元の経路へ戻せるのがこの型の利点です。
③資産を残して基盤だけ移した｜日本政策金融公庫
日本政策金融公庫は、各社のベンダーの13台のシステムで稼働していた基幹業務を、プライベートクラウド上の共通基盤へ移しました。オープン系システムへの移行の本格的な検討は2010年度に始まり、2011年12月に構築を開始、2014年5月までの約30カ月で完了しています。
公庫が公表した受注金額は、プライベートクラウドの構築が78億円、中小企業システムのオープン化が28億円で、計106億円です。経緯はITmedia エンタープライズの記事にあります。この型の要点は、動いている処理そのものには手を付けず、土台だけを入れ替えるところです。業務側が確認する範囲が小さくなる一方で、元の言語を保守できる人は移行後も必要になります。
④中身が分からないまま刷新に踏み切った場合｜京都市
京都市は2014年から81億円を投じ、30年前からNEC製メインフレーム上で動いていた基幹系システムの刷新を進めていました。稼働は遅延し、京都市は2017年10月11日に受託ベンダーとの設計・開発などの業務委託契約を解除します。同年11月8日にはベンダー側が京都市に約2億円を求めて東京地方裁判所に提訴し、12月8日には京都市議会が訴えの提起を可決しました（京都市側の正式な提訴は2018年2月）。仕切り直しでアプリケーションの刷新費用は合計で8億円増え、システム全体では約100億円規模になりました。経緯は日経クロステックの記事（2026年3月30日）で確認できます。
責任の所在は当事者間で争われており、どちらに問題があったのかは本記事では判断しません。参考になるのは、30年動いてきたシステムの刷新が、当初81億円の計画から約100億円規模へ膨らんだという事実です。中身が分かる前に金額と期間を固めると、あとから出てくる差分がそのまま費用と期間に乗ります。
刷新前に決める4つのこと
ここからは、刷新前に決める4つのことを紹介します。
スパイクスタジオがDXPO東京'25の来場者に行った自主調査（有効回答200名）では、生成AIの導入率は87%、業務効率への寄与を実感した人は91%だった一方、満足度は30.5%にとどまりました（DXPO東京'25来場者調査）。使えてはいるが満足には届いていない、という結果です。業務の中心にある古いシステムに手が入らないままだと、周辺をAIで効率化しても手応えが出にくくなります。
1. 凍結して現物を確定させる
日付を切って、稼働中のコード・ジョブ定義・帳票・設定値の版を固定します。あわせて「ドキュメントと現物が違ったら現物を正とする」を関係者で合意します。合意を文書に残しておくと、あとの手戻りが減ります。
2. 仕様の復元は範囲を切って始める
全システムを一度に解析しようとすると、費用も期間も刷新と変わらなくなります。改修依頼が集中している1業務、あるいは月次で必ず問題が出る1機能に絞ります。範囲を切ると、解析の成果が数週間で目に見えます。
3. テストを先に作る
現行の入力と出力を記録し、期待値として保存します。仕様が説明できない機能でも、変更前後で同じ結果が出るかは判定できます。ここを作らずに改修へ進むと、影響の確認が人の目視に戻ってしまいます。
4. 部分改修から通す
1機能だけ新しい実装に切り替え、問題が出たら元の経路へ戻せる形にします。1本通ると、社内の議論が「刷新すべきか」から「次はどの機能を切り出すか」に変わります。全面刷新を選ぶ場合でも、この4つを終えてからのほうが要件が固まります。
どこから切り出せるかの見立てだけでも構いません。仕様書がないシステムの改修について相談するから、現状の構成と困っている改修依頼をお知らせいただければ、進め方の案をお返しします。
スパイクスタジオの支援事例
株式会社Circloopのシステム改修では、生成AIを全面的に使い、開発業務の80%以上をAIが担いました。改修は従来の約1.3倍の速度で完了しています。何をAIに任せ、どこを人が判断したのかはCircloopの支援事例にまとめています。生成AIを使ったシステム開発の他の事例は生成AIを活用したシステム開発事例もあわせてご覧ください。
仕様書がないシステムの改修は スパイクスタジオまでご相談ください
スパイクスタジオは、動いているシステムの中身を読み解き、変更できる状態に戻す支援を行っています。刷新の是非を決める前の調査からご相談いただけます。
- AIモダナイゼーション … 既存システムの解析、仕様の復元、段階的な改修の設計と実装
- BPRコンサルティング … システムに合わせて歪んだ業務プロセスの組み替え
- Spike AI Agent Studio … 改修と機能追加を継続的に回す開発体制の提供
「どこから手を付けるべきか分からない」という段階で構いません。現状の構成と、いま止まっている改修依頼を伺ったうえで、範囲の切り方から一緒に整理します。AIモダナイゼーションについて相談するからお問い合わせください。