Oracle E-Business Suite(EBS)監査が増えている‐パッケージ製品の落とし穴　Part1

“オンプレEBS監査”の真の狙いとはーOracle決算が示す戦略的布石

多くのIT担当者は、「Oracle監査」と聞くと、DatabaseやJavaを思い浮かべるのではないでしょうか？しかし今、水面下で着実に増えているのがOracle EBS監査です。「パッケージ製品なのにライセンス違反が起こるのか？」そう疑問に感じるのは当然です。

2025年5月31日締めで発表されたオラクルの2025年度第4四半期決算では、以下のような成長が報告されました。

• クラウドサービスおよびライセンスサポートの売上高：約1兆8,700億円超*1（前年同期比14％増）
• Fusion Cloud ERP（SaaS）の売上高：1,600億円*1（前年同期比22％増）

これらの数字が物語るのは、オラクルのクラウドシフトが確実に成果を上げているという事実です。 オラクルCEOのSafra Catz氏は「2026年にクラウド成長率を2025年の24％から40％以上へ、インフラ成長を50％から70％以上へ引き上げる」と明言しています。さらに、ある市場調査では、2024年のERP市場において、オラクルがSAPを抜きシェア首位にたったという報告もあります。オラクルは今、かつてない規模でクラウド事業にドライブをかけており、オンプレミスEBS監査強化もその戦略の一環として位置づいているのです。

*1：為替レート：1ドル＝160円で換算　（4q25-pressrelease-June-final.pdf）

EBSも「本格監査」の対象へーパッケージの盲点がリスクになる時代

かつてオンプレEBSに対する監査は、Database監査の延長上で簡易的に行われるに過ぎませんでした。主な確認項目は、EBSの利用ユーザー数や、稼働するDatabaseのCPUコア数といった、あくまでDatabaseの周辺的なものにとどまっていたのです。しかし、現在状況は大きく変化しています。オラクルはEBS環境の実態をより深く把握するために非公開スクリプトを各社へ提供しており、 EBSモジュールがどのように利用されているか、ユーザーごとのアクセス経路や、EBSと連携しているカスタムアプリケーションや外部システムまで、精緻に確認するケースが増えています。これにより、従来は問題視されなかったEBSの構成や設定が、突如として“ライセンス違反”と指摘される。そんな事例が、今まさに現場で増えているのです。

パッケージ製品の“柔軟性”が落とし穴に

Oracle EBSはパッケージ製品でありながら、他のERP製品と比べて柔軟性・汎用性に優れ、業務に応じて自由にカスタマイズできる点が支持されてきました。一方で、この柔軟性がライセンスリスクの温床となるケースも少なくありません。EBSは財務、調達、在庫、サプライチェーンといった業務領域を網羅する統合型のERPであり、インストール方法によっては、契約対象外のモジュールも合わせてインストールできてしまう構造を持ちます。例えば、企業が「一般会計」モジュールのみを利用する想定であっても、Rapid Install機能（モジュールを一括で展開する機能）を利用して環境を構築した場合、依存関係にある「在庫管理」や「サプライチェーン管理」などのモジュールが同時にインストールされ、かつ利用可能な状態として構成されてしまうのです。オラクルは、こうした“導入当初の初期構成ミス”や”意図せぬ有効化“が放置されがちであることを把握しています。

EBS 12.2サポート延長の“本音”を読み解く

2025年3月19日、オラクルはオンプレミス版 EBS 12.2 に対する Premier Support の提供期限を2036年末まで延長すると発表しました。一見すると、ユーザーにとっては朗報ともいえるこの発表。しかしその裏には、オラクルの思惑があるのです。オラクルとしてはオンプレEBSを企業が長期間使い続けることによって、旧技術の維持管理やパッチ開発といった非戦略領域にリソースを割かざるを得ないという構図を脱却したいと考えています。とはいえ、依然としてオンプレEBSは多くの大手企業に採用されており、年間保守料という高利益率の収益源でもあります。そのため、無下にやめさせることはできず、「まだ10年以上使える！」というメッセージを打ち出すことでユーザーの安心感を担保している側面も否めません。しかしこのサポート延長には注意すべき前提条件があります。

• 2036年以降、新たなパッチやアップデートの提供は予定されていない
• 次のメジャーバージョンのリリース計画も未発表のまま

つまり、この延長は、オラクルの戦略的オンプレ撤退の時間稼ぎともとれるのです。

段階的に進むクラウド移行の“提案型アプローチ”

このタイミングで、オラクルは各企業に対して次のような提案を行い始めています。

• オンプレミスEBSの長期運用リスクに備え、OCI（Oracle Cloud Infrastructure）への移行をご検討されてはいかがでしょうか？
• OCI環境へのLift & Shitには自動化ツールもご用意しており、移行支援体制も充実しています。
• まずは現在のEBSの利用状況を拝見させてください。移行費用を試算いたします。

オラクルは、あくまで“提案”という形をとり、強引なIaaSやSaaSへの移行誘導は行いません。そのため、多くの企業では「監査ではない」として、構成情報の提供に応じてしまうのです。

構成情報が、ライセンス違反の導火線になるとき

「構成情報の提供くらい問題ない」そう思って、EBSの詳細な設定情報を無防備に開示していないでしょうか？それこそが落とし穴です。

EBSは極めて柔軟性が高く、ほとんどの企業が導入時に何らかのカスタマイズを加えています。しかしその柔軟性ゆえに、実際のシステム構成とライセンス契約がずれてしまうことがよくあります。しかし、こういったチェックを導入当初から正確に行えている企業はどのくらいあるでしょうか？

例えば、モジュールの一括インストール機能を利用して環境を構築した場合、契約していないモジュールや有償オプションが、自動的に“利用可能”として構築され、ユーザーは意図せずそれらの画面にアクセスできてしまうのです。これらの設定を意識的に無効化しない限りは、「意図せず違反者」になっている可能性があるのです。こういった事実をオラクルは熟知しており、使用ログや構成情報を根拠に、ライセンス違反の可能性を指摘してくることがあります。

まずは、自社環境におけるEBS構成を今すぐ確認してみてください。

「APPLSYS.FND_APPLICATION」テーブルには、インストールされているすべてのモジュール情報が格納されており、契約外のアプリケーションやオプションモジュールが「A（Active＝有効化）」ステータスのまま残っていることがあります。これらはたとえ利用していないつもりであっても、オラクル視点ではライセンス違反と見なされる可能性があります。しかも、こうした情報は使用ログや構成ファイルに長年残り続けるため、指摘されるタイミングによっては「10年以上にわたりライセンス違反をしていた」と判断され、結果、是正金額が数千万円～数億円に達するケースも決して珍しくありません。