AI導入事例
「動いているから、触らない」。そう言われ続けたシステムが、気づけば10年前のまま社内の中心で動いていた——多くの企業に心当たりがあるはずです。今回は、2016年リリースのプロジェクト管理システムが、2020年にサポートが終了したOSの上でインターネットに公開されたまま使われていた状態から、最新環境へ移設した実録です。実働2日。チケット3,623件・添付4.0GBを、1件の欠損もなく引き継ぎました。
「動いているから触れない」が、10年続いていた。
対象は社内のプロジェクト管理システム（Redmine）。案件の進行、障害対応の記録、顧客とのやり取りの経緯——10年分がここに溜まっています。まさに止められないから触れないという状態でした。
しかし中身を調べると、決して放置していい状態ではありませんでした。
| 項目 | 移設前 | 移設後 |
|---|---|---|
| OS | CentOS 6.10 （2020年サポート終了） | AlmaLinux 10.1 |
| アプリ | Redmine 3.2.1（2016年） | Redmine 6.1.3 |
| 実行環境 | Ruby 2.2.4 | Ruby 3.3.10 |
| データベース | MySQL 5.7 | MariaDB 10.11 |
| Webサーバ | Apache 2.2 + Passenger | nginx 1.26 + puma |
OSのサポートが切れて6年。その間に公開された脆弱性の修正は、一切適用されていません。それが社外からアクセスできる状態で動き続けていました。「動いているから安全」ではなく、「動いているだけで、守られてはいない」というのが正確な表現です。
壊れないまま、守りだけが止まっていることです。
移設の成否は、着手前の実測で決まっていた。
移設に入る前に、現状を数字で押さえました。ここが結果的に、工数を大きく左右しています。
- データベース 38MB / 添付ファイル 4.0GB
- 1日あたり20〜30リクエスト＝現役で使われている
- 拡張プラグイン：ゼロ。独自デザイン：なし
最後の1行が決定的でした。この種の移行で最も揉めるのは、後付けした拡張機能が新バージョンで動くかどうかです。動かなければ「代わりを探す」「機能を諦める」「自分で直す」の三択になり、そこで数週間が消えます。今回はその障害が最初から存在しませんでした。
この実測を踏まえ、着手前に3つの方針を決めています。
1. バージョンを一段ずつ上げるのをやめた
当初は 3.2 → 4.2 → 5.1 → 6.x と段階的に上げる前提で見積もっていました。ところが検証したところ、10年分を一度に飛び越えて更新できることが分かりました。想定していた工数がまるごと不要になっています。
2. データベースの種類を変えなかった
他システムと運用を揃えるため、別のデータベース製品へ移す案もありました。しかし移行元のデータ形式が違うため、変換処理を挟む必要があります。チケット3,623件・履歴6,071件という「消えても気づきにくいデータ」に、変換というリスクを持ち込まない。運用の統一より、データが1件も欠けないことを優先しました。
3. 既存サーバを直接アップグレードしなかった
新しいサーバを別に用意し、切替は入口の設定を1行書き換えるだけにしました。失敗しても1行戻せば元通りという状態を、最後まで維持するためです。
時間を取られたのは、Redmineではなかった。
ここからが実務です。移設中に踏んだ問題を並べると、傾向がはっきり出ました。
8つのうち、Redmine 本体に起因するのは3つだけ。しかもそのうち1つは「思ったより簡単だった」という良い誤算です。実質的に手を焼いたのは2つにすぎません。
残りは OS の世代差、セキュリティ機構、通信経路、暗号化、外部システム連携——すべてアプリケーションの外側にあります。
10年分たまった「周辺環境の差」です。
「1行で戻せる」を最後まで手放さない。
切替は、入口サーバの転送先を新サーバへ向けるだけ。戻すときも1行です。そして旧環境は停止せず、動いたまま残しました。
切替当日は「動いている旧環境」と「動いている新環境」が並存し、どちらへも1行で行き来できる状態を保っています。数日おいて問題がないことを確認してから、旧側を停止しました。
移設で終わりにせず、10年分の不足を埋めた。
新環境では、旧環境になかったものを同時に整えています。
- 毎日のバックアップ（7世代） — 旧環境にはバックアップの仕組み自体がありませんでした
- アクセス元の記録 — 移設前は全アクセスが同一に見え、誰がどこから来ているのか追えない状態でした
- ログイン試行の制限 — 標準機能がないため、Webサーバ側で補強
- ソースコード連携の自動更新 — 事実上凍結していた連携が15分ごとに更新されるように
結果として引き継いだデータは以下のとおりです。旧環境と新環境で、件数が完全に一致することを確認しています。
外部システムからの連携も、設定変更なしでそのまま動いています。利用者から見れば、ログイン画面が新しくなっただけ——移設として理想的な着地です。
「うちにも、同じサーバがある」なら。
今回の移設が短期間で終わった理由は、3つに集約できます。
- 拡張機能が入っていなかった——だから10年分を一度に飛び越えられた
- 着手前に実測した——判断の材料が数字で揃っていた
- 戻せる状態を保った——切替当日に賭けをしなくて済んだ
逆にいえば、この3つは着手前に確かめられます。「サポートが切れたサーバで、止められないシステムが動いている」——もし心当たりがあるなら、まず現状を数字で把握するところからご相談ください。移せるかどうかは、たいてい調べれば分かります。
当社は、サポートが終了したOS・古いフレームワーク上で動き続けている業務システムの移設・刷新を支援しています。
現状調査（バージョン・データ量・拡張機能の有無・公開範囲）は無料。レガシーシステムの刷新（AI Re:プラットフォーム／略称：AIRプラットフォーム）とあわせて、今すぐお問い合わせください。
お問い合わせフォーム（「レガシー移設 相談希望」とお書き添えください）／ info@flagship-ai.jp
シリーズ「レガシー to AI 実録」
- 総集編：1台のPCで22システム・24.6万行 ― AI開発3.5ヶ月の実測記録
- 実録①：20年もののJavaを、約1週間でフル刷新
- 実録②：既存コード0行変更で、基幹系に新しい入口を作る
- 実録③：1ヶ月級の構成検討を、プロトタイプ2日＋実測で
- 実録④：旧マイニングPCが2日で「社内専用ChatGPT」に
- 実録⑤：サポート切れサーバから、10年もののシステムを2日で救出（本記事）
※本記事の数値は2026年8月時点の実測値です。移設に要する期間・作業内容はシステムの構成・拡張機能の有無により異なります。