結論：延長は朗報ではあるが「刷新しなくてよい理由」ではない
2026年3月、Oracleは主力ERPであるOracle E-Business Suite（EBS）12.2のPremier Supportを「少なくとも2037年まで」延長すると告知しました。これは2018年の「Continuous Innovation（継続的イノベーション）」リリースモデル導入以降、毎年1年ずつ延長を繰り返してきた9回目の年次延長にあたると報じられています。EBSを基幹に据える企業にとって、当面の保守切れ不安が遠のいたという意味では歓迎すべきニュースです。
ただし、経営として押さえるべき最重要ポイントは次の一点です。この「2037年」は**恒久的な契約保証ではなく、Oracleが毎年その年に1年延長するかどうかを見直す「年次延長方式」**です。Oracle自身が、Premier Supportをもう1年延長するかを毎年レビューすると表明しており、「2037年まで確約された」わけではありません。過去に前倒しで延長され続けてきた実績はありますが、それは将来の継続を約束するものではなく、あくまで年次の判断の積み重ねです。「2037年という数字が独り歩きして、それを固定の締切のように扱う」こと自体が最初の誤読になります。
そして本稿がもっとも伝えたいのは、その先です。サポートが延びたことと、自社が基幹システムを刷新すべきかどうかは、まったく別の問題です。基幹刷新（EBSからクラウドERP、SAP S/4HANA、あるいは個別最適の再設計への移行）は一般に構想から本番稼働まで18〜36か月を要します。つまり「サポート期限から逆算して動く」発想では常に手遅れになりやすく、判断の起点はサポート期限ではなく自社の事業計画に置くべきだ、というのが結論です。延長を「安心材料」として受け取り判断を先送りした瞬間から、カスタマイズの肥大化・アドオンのブラックボックス化・技術者の枯渇・周辺システムとの乖離が静かに進行します。以下では、この「まだ大丈夫」の罠の構造と、塩漬けを避けるための棚卸しチェックリスト、刷新時期の逆算、保守ベンダーへの質問テンプレを整理します。
NOCODE EXIT
Bubble／kintone の限界、スクラッチ移行で解消しませんか？
ノーコードの肥大化・応答遅延・カスタマイズ限界を Laravel+Vue 移行で根治。概算費用・移行期間・データ移行設計・並行稼働プランをその場で確認できます。
この記事を読むべき人
- Oracle EBS（あるいは同種の老朽化した基幹システム／ERP）を使い続けており、「サポートがある間は現状維持でよい」と考えている経営者・役員
- 情シスが0〜1名または兼任で、基幹システムの中身がブラックボックス化しており、刷新の要否を社内だけで判断しづらい事業責任者
- 保守ベンダーから「まだサポートがあるので急がなくてよい」と言われ、その言葉をそのまま信じてよいか迷っている決裁者
- 基幹刷新にどれくらいの期間・体制が必要かの相場観がなく、いつ動き始めるべきか判断できない経営者
- 過去にERP更新やシステム移行で追加費用・要件の食い違い・PoC止まりを経験し、次は失敗を避けたいと考えている実務決裁者
何が起きたのか：事実関係の整理
まず、報道されている事実を時系列と論点で整理します。憶測を混ぜず、確認できる範囲に絞ります。
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 告知内容 | Oracle E-Business Suite 12.2のPremier Supportを「少なくとも2037年まで」延長 |
| 告知時期 | 2026年3月（2018年以降で9回目の年次延長と報じられている） |
| 延長の性質 | 恒久保証ではなく、毎年延長可否を見直す「年次延長方式」 |
| 背景モデル | 2018年導入の「Continuous Innovation」リリースモデル（大規模アップグレードなしで継続的に更新を提供） |
| 旧リリースの扱い | EBS 12.1はすでにPremier Supportを離脱済み（延長を経てSustaining Supportへ移行） |
「Continuous Innovation」と年次延長の意味
Oracleは2018年に、EBS 12.2について大規模なメジャーアップグレードを求めず、継続的に機能・技術スタックの更新を提供する「Continuous Innovation」モデルを打ち出しました。その一環として、オンプレミス版のPremier Supportを「少なくとも◯◯年まで」提供すると表明し、その年限を毎年1年ずつ前倒しで延ばしてきました。2026年3月の告知で、その到達点が「2037年」になったという構図です。
ここで誤解してはならないのは、「毎年延ばしてきた実績があるから今後も自動的に延びる」と読むことです。Oracleは各年で継続可否をレビューすると明言しており、これは方針であって契約上の永続保証ではありません。過去の延長パターンは参考にはなりますが、経営判断の土台に「延び続ける前提」を置くのはリスク管理として不健全です。
旧リリースは実際に「終わって」いる
もう一つ重要なのは、Oracleが古いリリースについては実際にPremier Supportを終了させてきたという事実です。EBS 12.1は、当初の想定より延長を重ねたものの、最終的にPremier Supportを離脱し、Sustaining Support（新規パッチや法改正対応の提供が縮小・停止するフェーズ）へ移行しています。つまり「Oracleは結局サポートを切らない」という楽観は成り立ちません。12.2が今回延びたことと、いずれ12.2にも同じ運命が訪れうることは矛盾しません。「延長される」ことと「永久に安全」であることは違うという当たり前の事実を、経営として明確に区別しておく必要があります。
なお、Premier Support・Extended Support・Sustaining Supportといったサポート区分の正確な内容や各リリースの最新の期限は、契約状況によって差が生じます。自社の正確な状態は、Oracleの公式サポートポリシーと自社の契約・見積を照合して確認してください。本稿は特定企業のライセンス状況を断定するものではありません。
「まだ2037年まで大丈夫」がなぜ罠になるのか
ここからがGXOとしての分析の中心です。サポート延長のニュースは、経営会議で「では急がなくてよい」という結論に着地しがちです。しかしその結論は、システムの実態を見ずに「サポートの有無」という一次元だけで判断しているために生まれます。実際には、サポートが続いていても、放置している間に自社の内部で次の四つの劣化が進みます。
罠1：カスタマイズの肥大化（改修の複利で身動きが取れなくなる）
EBSのような基幹は、長年の業務要求に応えるうちにカスタマイズやカスタムコードが積み上がります。サポートが続く限りは「今のまま追加改修」を選び続けられるため、標準機能から乖離した独自実装がさらに増えます。この積み上げは複利で効き、刷新時に「何を残し、何を捨てるか」の棚卸しコストを年々押し上げます。先送りの本質的なコストは、保守費そのものではなく、将来の刷新難易度が毎年上がっていくことにあります。動ける時期を逃すほど、動くための費用と期間が膨らむのです。
罠2：アドオン・連携のブラックボックス化
導入当時の開発者が社内・ベンダー双方から退職・異動し、なぜその設定・そのアドオンが存在するのかを説明できる人がいなくなります。ドキュメントが更新されていない、テスト仕様が残っていない、連携先システムとのインターフェース仕様が口伝になっている——こうした状態は、サポートが続いている間はトラブルが顕在化しないため放置されます。しかし刷新や移行に着手した瞬間、「触ると何が壊れるか分からない」という理由で調査だけで数か月を溶かします。ブラックボックス化は時間とともに悪化する一方向の劣化です。
罠3：技術者の枯渇（人材市場の縮小は不可逆）
古いバージョンを扱える技術者の母数は、時間とともに縮小します。これは自社の努力ではどうにもならない外部要因です。サポートが延びても、実際に手を動かせる人材の採用・調達は年々難しく、単価は上がります。保守を委託しているベンダー側でも同じ現象が起き、対応できる担当者が限られていく。「サポートは続く」という契約上の安心と、「実際に直せる人がいる」という現場の実態は、時間差でずれていきます。
罠4：バージョン固定による周辺システムとの乖離
基幹を固定している間も、その周囲——OS、ミドルウェア、ブラウザ、認証基盤、外部SaaS、取引先のEDIやAPI、法改正対応——は動き続けます。基幹だけが止まっていると、周辺の更新に追随できず、連携のための場当たり的な変換層やパッチが増えます。この「基幹は塩漬け、周りは変化」というギャップは、セキュリティ面でも運用面でも負債になり、いずれ周辺側の都合で刷新を強いられます。刷新のトリガーが自社の計画ではなく、外部の都合で降ってくる——これが最悪の展開です。
これら四つに共通するのは、いずれも「サポートの有無」では計測できず、かつ時間の経過とともに一方向に悪化するという性質です。だからこそ、サポート延長を「時間ができた」と受け取るのは危険で、正しくは「劣化が進む時間を、意図せず買ってしまった」と捉えるべきなのです。
判断の起点を変える：期限逆算ではなく事業計画から決める
では、いつ動くべきか。ここで発想を切り替えます。多くの企業は「サポート期限 − 移行期間 = 着手時期」という引き算で考えます。しかしこの引き算には二つの欠陥があります。第一に、前述のとおりサポート期限（2037年）は確約ではなく、逆算の起点として不安定です。第二に、期限ギリギリに動くと、劣化が最も進んだ最悪のコンディションで、最も人材が枯渇した市場環境で刷新することになります。
GXOが推奨するのは、自社の事業計画を起点に刷新時期を決めるという考え方です。次のような事業イベントは、いずれも基幹の作りが直接影響する局面です。
- 新規事業・新チャネルの立ち上げ（既存基幹が新しい業務プロセスに追随できるか）
- M&A・グループ会社統合（複数基幹の統合・データ統合が必要か）
- 事業承継・経営体制の変更（属人化した基幹を次世代が引き継げるか）
- 海外展開・多通貨/多言語対応
- 大幅な業務改革・DX投資の実行フェーズ
これらの計画が「向こう3年以内」に一つでもあるなら、基幹刷新はその計画に間に合うよう逆算して始める必要があります。刷新に18〜36か月かかるという相場を踏まえれば、「3年後に大きな事業イベントがある」なら、刷新の検討は今始めるべきという結論になります。サポート期限は制約条件の一つにすぎず、意思決定の主軸ではありません。
刷新期間の逆算イメージ
以下は一般的な基幹刷新の大まかなフェーズ感です。個社の規模・カスタマイズ量で大きく変動するため、あくまで「動き出しの目安」として提示します。
横にスクロールして確認できます
| フェーズ | 主な作業 | 期間の目安 |
|---|---|---|
| 現状把握・棚卸し | カスタマイズ/アドオン/連携/データの可視化、あるべき姿の整理 | 3〜6か月 |
| 方式選定・要件定義 | 移行先の選択、Fit&Gap、要件確定、体制・予算の確定 | 3〜6か月 |
| 設計・構築 | 移行設計、開発、データ移行設計、周辺連携の再設計 | 9〜18か月 |
| テスト・移行・稼働 | 総合テスト、移行リハーサル、本番切替、初期安定化 | 3〜9か月 |
合計するとおおむね18〜36か月、規模が大きい・カスタマイズが厚い案件では3年（36か月）を超えることもあります。ここで見落とされがちなのは、最初の「現状把握・棚卸し」フェーズです。ブラックボックス化が進んでいるほど、この工程だけで想定を超える時間を消費します。逆に言えば、棚卸しだけでも先に着手しておくことが、将来の刷新を軽くする最も費用対効果の高い一手です。
塩漬けEBSの棚卸しチェックリスト
刷新するかどうかを決める前に、まず「自社のEBSが今どういう状態か」を可視化します。以下は、保守ベンダーに丸投げせず、経営・実務側が主体的に把握しておくべき項目です。刷新の要否・難易度・概算規模は、この棚卸しの結果からしか見積もれません。
1. カスタマイズ・カスタムコード
- 標準機能からどれだけ乖離しているか（カスタマイズ画面・帳票・バッチの数）
- 各カスタマイズの「なぜ入れたか（業務上の理由）」を説明できる人が社内にいるか
- 使われていない・形骸化したカスタマイズはどれか（廃止候補の把握）
2. アドオン・追加開発
- 導入済みアドオンの一覧と、それぞれの提供元・保守状況
- ソースコード・設計書・テスト仕様の有無と最新性
- 提供元が撤退・サポート終了しているアドオンはないか
3. 外部連携・インターフェース
- 連携している周辺システム／SaaS／取引先の一覧（EDI、API、ファイル連携含む）
- 各連携のインターフェース仕様が文書化されているか、口伝になっていないか
- 連携が止まった場合の業務影響度（止まると何が困るか）
4. 保守体制・人材
- 現在の保守ベンダー・契約範囲・年間費用
- 障害時に実際に手を動かせる人が何人いるか（自社／ベンダー双方）
- そのバージョンを扱える技術者を今後も確保できる見込みがあるか
5. ライセンス・コスト構造
- 現在のライセンス・サポート費用の年額と、その内訳
- 「使っていないのに払い続けている」モジュールがないか
- 現状維持を続けた場合の今後5年の累計コスト（保守＋改修＋人材確保）
この5項目を一枚にまとめるだけで、「サポートがあるから大丈夫」という感覚論から、「自社の基幹は今どれだけ動かしにくくなっているか」という事実ベースの議論に移れます。棚卸しの結果、カスタマイズが薄く連携も文書化されていれば、慌てて刷新する必要はないかもしれません。逆に、ブラックボックスが多く扱える人が減っているなら、サポート期限に関わらず早めの着手が正解です。判断はサポート年限ではなく、この棚卸しの中身で決める——これが本稿の核心です。
刷新の選択肢と判断軸
棚卸しの結果「動くべき」となった場合、移行先には複数の選択肢があります。ここでも「流行っているから」「ベンダーが勧めるから」ではなく、自社の状況に照らした判断軸で選ぶことが重要です。
横にスクロールして確認できます
| 選択肢 | 向いているケース | 主な注意点 |
|---|---|---|
| クラウドERPへ移行 | 標準業務に寄せられる、運用負荷を下げたい | 独自業務を標準に合わせる痛みを許容できるか |
| 別ERP（S/4HANA等）へリプレイス | 大規模・グローバル、長期の標準基盤を求める | 期間・投資が大きく、要件定義の精度が成否を分ける |
| 個別最適の再設計（脱ERP的アプローチ） | 業務が独自で、既製ERPに乗り切らない | 設計・保守責任を自社/パートナーで持ち続けられるか |
| 現状維持＋棚卸しのみ先行 | 当面の事業イベントがなく、劣化も限定的 | 「先送り」と混同しない。棚卸しは必ずやる |
判断軸として最低限そろえるべきは、次の観点です。
- 標準に寄せられる業務がどれだけあるか（独自業務が多いほど、既製ERPへの適合コストが上がる）
- 事業計画との整合（前述の3年イベントに間に合うか）
- 総保有コストの比較（初期費用だけでなく、5〜10年の運用・保守・人材コストで比較する）
- 撤退・変更のしやすさ（一度入れたら抜けられない構造を避けられるか）
- 自社に残る運用責任の重さ（誰が、どの範囲を、いつまで面倒を見るのか）
ここで避けたい典型的な失敗が、「ベンダーが売りたい構成」がそのまま「自社に最適な構成」だと思い込むことです。移行先の選定は、特定製品の導入を前提にせず、自社の業務・データ・コスト構造から逆算して評価すべき領域です。中立的な第三者の視点で選択肢を並べて比較するレガシー基幹の刷新・再設計の進め方を、社内の意思決定材料として持っておくと、ベンダー提案を鵜呑みにせず評価できます。
保守ベンダー・提案元への質問テンプレ
刷新の検討を始めると、既存の保守ベンダーや新規の提案元と話すことになります。ここで「聞くべきことを聞けるか」が、追加費用トラブルや要件の食い違いを防ぐ分岐点になります。以下は、経営・実務側がそのまま使える質問テンプレです。
現状把握のために保守ベンダーへ聞くこと
- 現在のカスタマイズ・アドオンの一覧と、それぞれの目的・依存関係を文書で出せますか
- このバージョンを実際に保守できる技術者は、御社に何名いますか。今後3年の確保見込みは
- 現状維持を続けた場合、今後5年で発生しうる追加費用・リスクをどう見ていますか
- サポート期限の年次延長は「確約」ではないという理解で合っていますか。切れた場合の影響は
移行提案を受けるときに聞くこと
- 提案する移行先は、他の選択肢と比較してなぜこれなのか。比較検討の過程を示せますか
- 移行後に自社側に残る運用・保守責任の範囲はどこまでですか
- 見積の前提（対象範囲・カスタマイズの扱い・データ移行範囲）は何ですか。前提が崩れたら費用はどう動きますか
- PoCや初期フェーズと本番稼働の間で、どこにリスクが集中すると考えていますか
これらの質問に対して、根拠を持って明確に答えられるベンダーかどうかは、それ自体が発注可否の判断材料になります。答えが曖昧なまま契約に進むと、後の「追加費用」「要件の食い違い」「責任の所在不明」の温床になります。質問への回答の質を評価する準備段階では、開発会社に相談する前の要件・見積の整理の観点をあらかじめ押さえておくと、提案の良し悪しを見極めやすくなります。
よくある質問（FAQ）
Q. サポートが2037年まで延びたのなら、当面は何もしなくてよいのでは？ A. 「サポートがある」ことと「自社の基幹が健全である」ことは別問題です。サポートが続いていても、カスタマイズの肥大化・ブラックボックス化・技術者の枯渇・周辺との乖離は進行します。少なくとも現状の棚卸しは早めに行い、事業計画と照らして刷新の要否だけは判断しておくべきです。
Q. 「少なくとも2037年まで」は確定した期限ですか？ A. いいえ。これはOracleが毎年延長可否を見直す「年次延長方式」で決まっている暫定的な年限であり、恒久的な契約保証ではありません。過去は前倒しで延長されてきましたが、それは将来の継続を約束するものではなく、逆算の固定起点として扱うのは適切ではありません。
Q. 基幹刷新にはどのくらいの期間がかかりますか？ A. 一般に構想から本番稼働まで18〜36か月程度が目安です。カスタマイズが厚い、連携が多い、体制が薄いほど上振れします。特に最初の現状把握・棚卸しフェーズは、ブラックボックス化が進んでいるほど想定以上に時間を要します。
Q. いつ動き始めるべきですか？ A. サポート期限ではなく、自社の事業計画から逆算してください。新規事業・M&A・事業承継・海外展開などが向こう3年以内にあるなら、その計画に間に合うよう今から検討を始めるのが妥当です。該当イベントがなくても、棚卸しだけは先行して行う価値があります。
Q. 保守ベンダーに「急がなくてよい」と言われました。信じてよいですか？ A. その言葉の根拠を確認してください。「サポートがあるから」という理由だけなら、自社内部の劣化を見ていない可能性があります。カスタマイズ量・保守できる技術者数・今後5年のコスト見通しなどを文書で示してもらい、事実ベースで判断することをおすすめします。
Q. EBS 12.1など古いリリースはどうなっていますか？ A. 12.1はすでにPremier Supportを離脱し、Sustaining Support（新規対応が縮小・停止するフェーズ）へ移行しています。Oracleは古いリリースについては実際にサポート区分を切り替えてきた実績があり、「結局切られない」という楽観は成り立ちません。正確な自社の状態は契約と公式ポリシーで確認してください。
GXOに相談すべきタイミング
最後に、どういう状態なら第三者を入れる価値があるか、判断基準の形で整理します。押し売りではなく、以下に一つでも当てはまるなら、社内だけで抱えず外の視点を入れたほうが安全だ、という目安です。
- 自社のEBS（や基幹）のカスタマイズ量・連携先・保守体制を、経営として説明できない
- 保守ベンダーの「まだ大丈夫」を検証できず、そのまま信じるしかない状態になっている
- 向こう3年以内に新規事業・M&A・事業承継など、基幹の作りが効く事業イベントがある
- 移行先の選択肢を、特定製品ありきでなく中立的に比較したい
- 過去の更新・移行で追加費用や要件の食い違いを経験し、次は同じ失敗を避けたい
こうした状態では、まず「刷新するか否か」を決める前段として、現状を可視化する棚卸しから始めるのが定石です。GXOは、特定製品の販売を前提にせず、自社の業務・データ・コスト構造から刷新の要否と選択肢を評価するレガシー基幹システムのモダナイゼーション支援を提供しています。あわせて、刷新を前提にしたDX・基幹システム再構築の進め方や、着手前に現状と課題を客観的に把握するためのAI・システム活用の第三者アセスメントも、意思決定の材料としてご活用いただけます。
「サポートが2037年まで延びたから、まだ考えなくてよい」——その一言で判断を止めてしまう前に、自社の基幹が今どれだけ動かしにくくなっているかを、一度事実ベースで棚卸ししてみてください。具体的な状況に応じた進め方の相談は、GXOへのお問い合わせから承ります。刷新は期限に追われて始めるより、事業計画に合わせて自ら選んで始めるほうが、はるかに安く、確実です。
