【2026年版】レガシー基幹システム刷新ガイド：奉行11・GLOVIA・SMILE・Access・AS/400 (IBM i)・Notes/Domino からの移行戦略
奉行11、GLOVIA、SMILE、Access、AS/400、Notes/Dominoなど主要レガシー基幹システムのサポート終了タイムライン、移行先パターン、TCO目安、段階移行プランを徹底解説。2025年の崖を越えるための実務ガイド。
目次 クリックで開く
奉行11、GLOVIA、SMILE、Microsoft Access、AS/400（IBM i）、Notes/Domino——日本の中堅・大企業の基幹システムを支えてきたこれらレガシー製品が、2026〜2027年にかけて一斉にサポート終了の節目を迎えます。経済産業省の「DXレポート」が警鐘を鳴らした「2025年の崖」は、もはや概念的なリスクではなく、目の前のスケジュール問題になっています。
本記事では、主要レガシー基幹システム別のサポート終了タイムライン、現実的な移行先パターン、移行コストの目安、よくある失敗と回避策を、過去の支援実績と公開情報をもとに整理します。今日から3年スパンで動き出すための意思決定資料として、社内提案にそのまま使える形でまとめました。
この記事の構成
- なぜ今レガシー基幹刷新が急務か（2025年の崖の最新解釈）
- 主要レガシー製品のサポート終了タイムライン早見表
- レガシー製品別 移行戦略
- 移行先パターン4分類とその選び方
- TCO試算と移行コストの目安
- 段階的移行プランのフレームワーク
- よくある7つの失敗パターンと回避策
- AI / Claude Code / MCP を活用した移行支援
- まとめ
- FAQ
1. なぜ今レガシー基幹刷新が急務か
経済産業省は2018年に「DXレポート」を発表し、レガシーシステムの放置による経済損失が2025年以降最大年間12兆円にのぼる可能性を示しました（経済産業省 DXレポート サマリー）。当初は遠い未来の話のように扱われていましたが、2025年5月には経産省が「レガシーシステムモダン化委員会総括レポート」を取りまとめ、ベンダー企業とユーザー企業の両面からモダン化の加速が必要と提言しました。
3つの構造要因が同時進行している
2026年現在、レガシー刷新を待ったなしにする3つの構造要因が同時に進行しています。
- サポート終了の集中：奉行11（2027年4月）、IBM i 7.3（2026年9月）、Windows Server 2012/2016（既終了）など、複数製品の終焉が同時期に重なる
- 人材引退とRPG/COBOL技術者の枯渇：DXレポートは21年以上稼働の基幹系システムが2025年に約6割を占めると指摘。それを保守できる人材は急速に減少中
- クラウド化を前提とした取引先・規制要件：電子帳簿保存法、インボイス制度、改正電気通信事業法など、クラウド前提の制度設計が業務プロセスを更新せざるをえない状況に
レガシーシステムは「動いている間は問題が見えない」のが特徴です。サポート終了後の障害発生・セキュリティインシデント・改正対応の遅れは、いずれも事業継続に直結する致命的なリスクとして顕在化します。「動いているうちに段階的に置き換える」が唯一のリスク低減策です。
2. 主要レガシー製品のサポート終了タイムライン早見表
| 製品 | カテゴリ | サポート終了時期 | 後継・移行先（公式推奨） |
|---|---|---|---|
| 奉行11シリーズ（勘定奉行i11等） | 会計・販売管理 | プログラムメンテナンス 2026年12月末／サポート完全終了 2027年4月末 残り約12か月 | 奉行クラウド（オンプレ後継なし） |
| 奉行7・8・10シリーズ | 会計・販売管理 | 順次終了済み | 奉行クラウドまたは奉行11→クラウドの2段階 |
| IBM i 7.3（AS/400後継） | 基幹サーバーOS | 延長サポート 2026年9月30日 残り約4か月 | IBM i 7.4/7.5への更新、またはクラウドERPへの移行 |
| GLOVIA smart シリーズ | 大企業ERP | 順次販売終了・保守期限あり | GLOVIA iZ、Azure 上での GLOVIA、または他社ERP |
| SMILE BS / SMILEes | 中堅ERP | 順次サポート終了 | SMILE V 2nd Edition |
| Microsoft Access ベース内製システム | 中小業務システム | Access本体は継続だが、保守人材の枯渇 | kintone、Microsoft Power Apps、Salesforce、自社Webアプリ |
| Notes/Domino（IBM Domino） | グループウェア・業務DB | HCL Domino としてはサポート継続だが日本市場では縮小 | Microsoft 365 (Teams + SharePoint)、kintone、Google Workspace |
| 大蔵大臣（応研） | 会計 | 製品継続だが、クラウド版への移行推奨 | 大蔵大臣NX、freee会計、マネーフォワード クラウド会計 |
サポート終了が近い製品を使っている企業は、残された時間で「移行先選定 → PoC → データ移行設計 → 段階的切替」を完了する必要があります。奉行11の場合、2027年4月の完全終了から逆算すると、2026年中に移行先決定、2027年初頭に切替実施が現実的なスケジュールです（OBC 奉行11サポート終了案内）。
3. レガシー製品別 移行戦略
奉行11 → 奉行クラウド／freee会計／MFクラウド会計
OBC公式の推奨は「奉行クラウド」一択ですが、この機会に競合クラウド会計（freee会計、マネーフォワード クラウド会計）への移行を検討する企業も増えています。判断基準は以下です。
- 奉行クラウドが向く：既に奉行11の運用が安定し業務プロセスを大きく変えたくない／会計事務所が奉行に習熟している／グループ会社統合管理が必要
- freee会計が向く：銀行・クレカ連携の自動仕訳を強化したい／API連携で他SaaSと繋ぎたい／中小〜中堅
- MFクラウド会計が向く：請求書・経費精算・給与など周辺SaaSと統合運用／会計事務所連携をクラウドに寄せたい
移行期間は概ね3〜4か月（マスタ移行、過去データ整理、ユーザートレーニング含む）。詳細は 勘定奉行→freee 移行ガイドもご参照ください。
GLOVIA → SAP S/4HANA／Oracle Fusion／Microsoft Dynamics 365／Workday
富士通の GLOVIA シリーズは、SUMMIT/G2（大企業）、iZ（中堅）、きらら（中小）にラインナップが分かれます（FUJITSU Enterprise Application GLOVIA）。Azure 上での運用も可能になっており、GLOVIA を継続しつつクラウドリフトする選択肢もあります。一方、抜本的な刷新を目指す企業には以下のパターンが現実解です。
- 製造業・連結経営強化：SAP S/4HANA（RISE with SAP含む）／Oracle Fusion Cloud Applications
- Microsoft 365 / Azure 中心：Microsoft Dynamics 365 Finance & Operations
- HR・財務一体運用：Workday Human Capital Management + Workday Financial Management
- 中堅でクラウド完全移行：Oracle NetSuite
大規模な GLOVIA 刷新は2〜3年スパンの大型プロジェクトになることが多く、2026年現在で着手するか、Azure 移行で短期延命するかの判断が分岐点です。
SMILE BS / SMILEes → SMILE V 2nd Edition または他社ERP
大塚商会は SMILE BS / SMILEes / SMILEα ユーザー向けの後継として SMILE V を2017年9月にリリース、その進化版「SMILE V 2nd Edition」が現在の主力製品です（大塚商会 SMILE V 2nd Edition）。SMILE V への移行が公式推奨ですが、この機会に他社クラウドERPへ乗り換える企業も少なくありません。
- SMILE V 2nd Edition：SMILE シリーズ習熟ユーザーが業務プロセスを大きく変えずに継続できる
- SAP Business ByDesign / NetSuite：中堅企業の本格クラウドERPへ移行したい場合
- kintone × クラウド会計の組合せ：基幹+情報系を分割し、低コストで再構築したい場合
Microsoft Access 内製システム → kintone／Power Apps
Access ベースの内製システムは、2000年代初頭から多くの中小企業で構築されてきましたが、開発者の引退・サポート困難・ファイル破損リスクなどで保守限界に達しているケースが多発しています。後継として最も多いのが kintone または Microsoft Power Apps への置き換えです。
実績として、トラン系30テーブル・マスタ系50テーブル・約38万レコードの Access システムを kintone へ移行した事例も報告されています（アイティエス 移行事例）。判断基準：
- kintoneが向く：業務担当者自身が継続的に画面設計・改修したい／Slackやfreee等のSaaSと連携したい／クラウドで複数拠点共有
- Power Appsが向く：Microsoft 365 を全社で利用済み／Excel・SharePoint との統合が深い／IT部門主導
- Webアプリ自社開発：データ量が極端に大きい／業界特有のロジックが複雑／長期的内製化を志向
AS/400（IBM i）→ クラウドERP移行 or モダナイゼーション
IBM i 7.3 の延長サポートは2026年9月30日に終了します。RPG言語が IBM i 専用であることから、技術者の確保が年々困難になっており、2つの戦略選択肢が現実的です。
- 戦略A：IBM i上でモダナイゼーション：RPG → Java/Node.js 段階リライト、API化して外部SaaSと連携。継続性とリスク最小化が目的（ITmedia エンタープライズ）
- 戦略B：クラウドERPへフルリプレース：SAP S/4HANA、Oracle NetSuite、Workday、Dynamics 365 などへ移行。3〜5年の大規模PJ
段階的アプローチとして、IBM i を継続しつつフロント側を Mendix や OutSystems などのローコードでモダン化、徐々に基幹側もリプレースしていく企業も増えています。
Notes/Domino → Microsoft 365 + kintone
HCL Domino としては開発が継続されていますが、日本市場では新規導入は減少傾向。長年蓄積された Notes DB（顧客情報、ワークフロー、稟議システム等）を Microsoft 365（Teams + SharePoint + Power Platform）または kintone へ移行するパターンが標準的です。
- シンプルな業務DB：kintone（業務担当者主導でアプリ再構築）
- ワークフロー＆ドキュメント管理：Microsoft 365 + Power Automate
- 大規模DB＆複雑なロジック：Salesforce や 自社Webアプリ
4. 移行先パターン4分類とその選び方
レガシー基幹システムの移行先は、大きく4つのパターンに分類できます。それぞれメリット・デメリット・向くケースが異なります。
| パターン | 代表的な移行先 | 初期コスト | 運用コスト | 柔軟性 | 向くケース |
|---|---|---|---|---|---|
| ① クラウドERPフルリプレース | SAP S/4HANA、Oracle Fusion、Workday、NetSuite、Dynamics 365 | 高（数千万〜数十億） | 中〜高 | パッケージ標準範囲内 | 大企業、グループ統合、グローバル展開 |
| ② SaaS連携型（会計＋周辺SaaS） | 奉行クラウド・freee・MFクラウド ＋ kintone・楽楽精算・バクラク | 低〜中（数百万〜数千万） | 低〜中 | API連携で柔軟 | 中小〜中堅、業務分割再設計 |
| ③ ローコード／内製型 | kintone、Microsoft Power Apps、サーバーレス＋自社開発 | 低（数百万〜） | 低 | 非常に高い | 業務固有性が高い、内製人材あり、漸進的改善 |
| ④ リフト＆シフト | 既存システムをAzure / AWS / GCP 上にIaaS移行（GLOVIA on Azure 等） | 低〜中 | 中 | 低（既存ロジック維持） | 本格刷新の時間がない、短期延命 |
全てのレガシーを一度にリプレースするのは現実的でないことがほとんどです。多くの企業は「会計＝クラウド会計に即時移行、販売管理＝中期で他社ERPへ、内製Access＝kintoneに即時移行」のように 領域ごとに異なるパターンを組み合わせる ハイブリッドで進めています。
5. TCO試算と移行コストの目安
移行先パターン別の年間TCO目安（中堅企業：従業員300〜1,000名、年商100〜500億円規模）を整理します。価格はベンダー公開情報と業界水準からの推定で、実際は契約条件・実装規模で大きく変動します。
| パターン | 初期構築費用 | 年間ライセンス＋保守 | 移行期間 | 備考 |
|---|---|---|---|---|
| ①クラウドERPフルリプレース（SAP S/4HANA、Oracle Fusion 等） | 1億〜10億円 | 3,000万〜2億円 | 18〜36か月 | 専門コンサル必須、業務プロセス再設計 |
| ②SaaS連携型（奉行クラウド+周辺） | 300万〜2,000万円 | 500万〜2,000万円 | 3〜9か月 | API連携の設計負荷あり |
| ③ローコード／内製型（kintone等） | 200万〜1,500万円 | 200万〜800万円 | 3〜12か月 | 業務担当者の関与が必須 |
| ④リフト＆シフト（GLOVIA on Azure 等） | 500万〜3,000万円 | 従来ライセンス＋クラウドインフラ費 | 3〜6か月 | 本質的な刷新ではない、延命策 |
移行コストで見落とされがちな項目
- データクレンジング：レガシーシステムには重複・古い・整合性のないデータが大量に蓄積されており、移行前のクレンジング工数を低見積りすると後で破綻
- 業務プロセス再設計：システム移行はプロセス再設計を伴うのが本質。BPR（業務改革）の工数を別途見込む
- ユーザートレーニング：旧システムに習熟したベテラン社員ほど抵抗感が強い。研修・マニュアル整備・並行稼働期間の準備
- 外部システム連携の改修：銀行・税務署・取引先EDI・社内システム連携は移行に伴って必ず再構築が発生
- 並行稼働期間のコスト：旧システムと新システムを3〜6か月並行運用するためのライセンス・人件費の重複
6. 段階的移行プランのフレームワーク
レガシー基幹刷新は2〜3年の長期プロジェクトになります。フェーズを切って計画的に進めることが成否を分けます。
フェーズ0：準備（1〜3か月）
- 現状システムの棚卸し（製品・バージョン・サポート終了時期・連携先）
- 業務プロセスの可視化（As-Is）
- 移行ゴールの定義（To-Be像）と成功指標（KPI）設定
- 経営層・部門長の合意形成
フェーズ1：選定（2〜4か月）
- 移行先候補のロングリスト化（4〜6製品）
- RFI（情報提供依頼）→ RFP（提案依頼書）
- ショートリスト3製品でPoC（概念実証）
- 意思決定（ベンダー・実装パートナー選定）
フェーズ2：設計・構築（6〜18か月）
- 業務プロセス再設計（To-Be 詳細化）
- マスタデータ移行設計
- 連携インターフェース設計・開発
- テスト（単体／結合／受入）
- ユーザートレーニング・マニュアル整備
フェーズ3：移行・並行稼働（3〜6か月）
- データ移行リハーサル（最低3回）
- 本番データ移行
- 新旧並行稼働（差異検証）
- 旧システム停止
フェーズ4：定着化（3〜12か月）
- 運用定着支援、改善要望の収集
- 追加開発・カスタマイズの優先順位付け
- 次期改善計画の策定
7. よくある7つの失敗パターンと回避策
- 「現行業務を完全再現する」前提で要件定義してしまう
回避：レガシーで「やむなくやっていた業務」を残してはいけない。BPRを並行実施 - ベンダーの「できます」を額面通りに信じる
回避：PoCで実データを使って検証。「できる」と「すぐ快適に使える」は別物 - ユーザー部門の巻き込みが遅れる
回避：要件定義開始時点から実務者をプロジェクトメンバーに - データ移行を軽視してマスタ整理を後回し
回避：データクレンジングを最優先タスクに位置付け、移行前6か月から実施 - 並行稼働期間を短く見積もる
回避：最低3か月、月次決算を含む四半期1サイクルは並行 - 段階移行のつもりが「ビッグバン」になる
回避：機能単位・部門単位で切り出して段階的にカットオーバー - 運用定着フェーズの予算が無い
回避：本稼働後12か月の運用支援費を初期予算に含める
8. AI / Claude Code / MCP を活用した移行支援
2025年以降、生成AI（特にClaude、ChatGPT、Gemini）とMCP（Model Context Protocol）を活用した移行支援が現実的な選択肢になっています。Aurant Technologies が支援する案件でも次のようなパターンが定着してきました。
- レガシーコード解析：Claude Code に RPG / COBOL / Access VBA を読ませ、ロジック仕様書を自動生成 → 工数50〜70%削減
- マスタデータマッピング自動化：旧システムと新システムのマスタフィールド対応を AI が初稿作成、人間がレビュー
- テストケース自動生成：旧システムの実データから AI が境界値・異常系テストケースを生成
- 運用ドキュメント生成：移行後のマニュアル・FAQ を AI で大量自動生成、現場フィードバックで継続改善
- MCP経由での新基幹操作：移行後の kintone / 奉行クラウド / freee を Claude Code から自然言語で操作する開発体験
これらの実装パターンは、Aurant の Claude Code × 業務SaaS連携シリーズでも詳しく扱っています。
9. まとめ
- 2026〜2027年は複数のレガシー基幹システムが同時にサポート終了の節目を迎える、まさに「動き出す年」です
- 現行業務の完全再現を諦め、業務プロセス再設計と一体で進めるのが移行成功の最大の要因です
- 領域ごとに異なる移行パターン（フルリプレース／SaaS連携／ローコード／リフト&シフト）を組み合わせる ハイブリッドが現実解
- AI・Claude Code・MCPの活用は移行コストを実数で30〜50%削減する新しい武器
Aurant Technologies は、レガシー基幹システムの棚卸しから移行先選定、PoC、データ移行設計、運用定着までを一気通貫で支援しています。「今のままでサポート終了に間に合うか」「自社にどの移行パターンが合うか」といった初期相談は無料で承っていますので、お気軽にお問い合わせください。
10. FAQ
Q1. 奉行11のサポート終了に間に合わないと何が起きますか？
サポート終了後は新規バグ修正・セキュリティパッチが提供されなくなります。法令改正（インボイス・電帳法・税制改正）への対応も止まるため、業務継続が事実上不可能になります。サポート切れ後の継続使用は、監査やコンプライアンス上のリスクとしても問題視されます。2027年4月までに移行完了を目指してください。
Q2. GLOVIA を続けるべきか、他社ERPへ移行すべきかの判断基準は？
GLOVIA に高度なカスタマイズ・業界特有のロジックを大量に積み上げている場合、移行コストが極めて大きくなるため、Azure 上での継続運用＋段階モダナイゼーションが現実的です。一方、標準機能中心で運用している、グループ統合や海外展開を進めたい場合は、SAP S/4HANA、Oracle Fusion、Workday などへの抜本刷新が長期投資効率で優位です。
Q3. Access内製システムをkintoneへ移行する場合の典型的なコストは？
テーブル数20〜50、レコード数10万〜50万程度の標準的なAccess内製システムであれば、要件整理・kintoneアプリ設計・データ移行・ユーザートレーニングを含めて300万〜1,500万円、期間3〜9か月が目安です。kintoneライセンス費用は別途、年間1ユーザー1万円〜（プランによる）。VBAの複雑なロジックがある場合は、kintone カスタマイズや外部連携で再構築が必要になり追加コストが発生します。
Q4. AS/400 (IBM i) を完全に捨てるべきか、続けるべきか？
IBM i 自体は2026年9月の7.3サポート終了後も7.4/7.5で継続可能で、技術的には現役で使えます。問題はRPG技術者の引退と新規採用困難。「中期で完全リプレース」と決めて段階移行するか、「IBM i を継続しつつフロント側だけモダン化」するかを3年スパンで判断すべきです。後者を選ぶ場合は Mendix、OutSystems、Power Apps などのローコードでフロント開発、IBM i は API公開して残すパターンが現実的です。
Q5. 移行プロジェクトの社内合意をどう取り付けるべきですか？
「コストの話」ではなく「リスクの話」から始めるのが効果的です。サポート終了スケジュール、セキュリティインシデント時の事業継続不能リスク、人材引退による保守不能リスクを定量化して経営層に提示。次に「移行しない場合の3年後・5年後のコストとリスク」と「移行する場合のコスト」を並べて比較。最後に「段階的に進めれば一度に大きな投資は不要」を提示すれば、合意は取りやすくなります。
Q6. 中堅企業（年商100〜300億円）でフルクラウドERPは過剰投資ではないですか？
確かに SAP S/4HANA や Oracle Fusion は過剰になりがちです。中堅企業の現実解は パターン②（SaaS連携型） または NetSuite / Microsoft Dynamics 365 Business Central のような中堅向けクラウドERP が多いです。会計はクラウド会計、販売管理は kintone or 中堅ERP、経費精算・請求は専用SaaSと、領域分割で組み立てたほうが投資対効果が良いケースがほとんどです。
- 経済産業省 DXレポート サマリー
- 経済産業省 レガシーシステムモダン化委員会総括レポート（2025年5月）
- OBC 奉行11サポート終了案内
- FUJITSU Enterprise Application GLOVIA 公式
- 大塚商会 SMILE V 2nd Edition 公式
- ITmedia エンタープライズ：IBM i モダナイゼーション
- アイティエス Access→kintone移行事例
- コムデック Access→kintone移行事例
※ 価格・サポート終了時期等の情報は2026年5月時点の公開情報をもとに整理しています。最新の正確な情報は各ベンダー公式までご確認ください。本記事の判断基準・推奨事項は過去の支援案件・公開資料・公式ドキュメントに基づくAurant Technologies独自の見解で、いずれか特定ベンダーから対価を得て作成したものではありません。