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

ライセンスリスクは、時に非常に些細な“見落とし”から始まります。EBSもまさにその典型です。

「購買部門で３名の社員がEBSを利用。しかしなぜか７人分のライセンス違反と見なされた？！」

Part1では、オラクルが進めるEBS監査の背景を紹介しましたが、Part2では、実際の違反事例をもとに、EBSに潜むライセンスリスクの構造と、オラクルが提示する“出口戦略”の実態に迫ります。

EBS の違反事例から見るーその指摘の先にあるもの
ケース①：見落とされがちな「アプリケーションユーザー数」の罠

EBSを利用する企業の多くは、「Application User」という単位でライセンスを購入しています。これは、財務、調達、在庫、サプライチェーンなどの業務機能ごとに、利用者数に応じたライセンス契約を結ぶ仕組みです。一見シンプルに見えますが、実際には複数の落とし穴が存在します。

1. 最小購入数という契約上の盲点

オラクルは、各業務システムや機能ごとに、“最小限購入すべきライセンス数”を明確に定めています。たとえば、「Purchasing（購買）」機能を利用する場合、最低でも５名分のライセンスを購入する必要があると明記されています。

つまり、実際に「Purchasing（購買）」機能を利用する社員が3名であっても、契約上は最低5名分のライセンスを購入しなければ契約違反となるのです。

そして一見、「2名分の不足程度であれば、大きな問題にならない」と考えがちです。しかし、オラクルのライセンス違反の是正は、原則、過去の利用期間に遡って金額が算定されるため、仮に２名分の不足でも10年分となれば数百万円規模の是正額になる可能性があります。さらに実際の現場では、1つの機能だけでなく複数の業務アプリケーションを併用していたり、多数のユーザーが関与していたりするケースが大半です。このような場合、指摘の対象範囲は広がり、是正総額が数千万円〜数億円規模に膨れ上がることも決して珍しくありません。

つまり、「少し足りないだけだから大丈夫」と油断していた状況が、企業の経営判断に直結するレベルのリスクへと発展する可能性があるということです。

2. 技術的制御のないEBS ライセンス構造の落とし穴

EBSには、契約ライセンス数に応じてユーザーアクセス数を自動的に制御する技術的な仕組みが存在しません。そのため、契約数を超えるユーザーであっても、企業側の操作次第で 利用させることが可能です。たとえば、「Purchasing（購買）」機能のライセンスを5名分しか契約していない場合でも、企業側でユーザー登録さえすれば6人目、7人目のユーザーも「Purchasing（購買）」機能を利用できてしまうのです。この柔軟性は運用上便利な反面、ライセンス違反のリスクを企業内部に無自覚のまま蓄積させる要因にもなりかねません。

さらにEBSは、業務機能（たとえば購買や在庫管理など）ごとに異なるライセンス体系を持ち、それぞれの契約数に応じた適切なユーザー管理が求められます。しかし現場では、「登録できた＝ライセンスがある」という誤った前提で運用されているケースも多く、結果としてライセンス逸脱が常態化していることがあります。実際、私たちが支援してきた企業の多くで、以下のようなユーザーアカウントが長年EBS上に残存していることが確認されています：

• すでに退職した社員
• 異動により現在は該当機能を使用していない社員
• 一時的な業務で作成されたままのアカウント

オラクルのライセンスルールでは、こうしたユーザーであっても、登録されている限り「ライセンスの対象」としてカウントされる可能性が高く、「今は使っていない」は免責の理由にはなりません。貴社では、業務機能ごとに契約したライセンス数を踏まえたユーザー登録・管理が、確実に行われているでしょうか？

ケース②：見落とされがちな「ライセンス前提条件」の壁

EBSの導入において、多くの企業が陥りがちな誤解があります。それは、「業務機能（たとえば購買や在庫管理など）のライセンスさえ購入していれば十分」と考えてしまうことです。

確かにEBSは業務機能（たとえば購買や在庫管理など）を提供するパッケージ製品ですが、EBS単体で動作するものではありません。その背後でOracle Database、Javaプログラム、WebLogicなどのアプリケーションサーバーといった技術基盤が密接に連携しており、これらすべてが一体となってはじめて機能します。つまり、EBSを利用するということは、それらの技術基盤も併せて使用しているということであり、それぞれにライセンス上の前提条件が存在することを意識しなければなりません。

EBSの変更レベルとライセンス前提条件

オラクルはEBSのカスタマイズ状況に応じて、追加ライセンスが不要なケースと必要なケースを明確に定義しています。以下がその概要です。

パターン①：EBSカスタマイズなし（追加ライセンス不要）

EBSを完全な「純正状態」で利用している場合に限り、特定の基盤製品は追加ライセンスなしで使用可能とされています。（ただし、EBS用途に限る）

パターン②：EBSカスタマイズあり（追加ライセンス要件あり）

しかし現実的には、EBSを一切カスタマイズせずに導入している企業はごく稀です。もし、Javaコードの修正、外部システムとの連携、レポートやフォームの変更・追加などを行っている場合には、追加ライセンスの取得が必要になります。また、データベースに対する変更を行っている場合には、DBライセンスの追加取得が必要になります。

このようにEBSの構造を正しく理解しないまま運用を継続していると、思いがけないライセンス違反や重大な監査リスクを抱えることになります。EBSライセンス管理においては、その背後にある技術スタック全体も俯瞰的に把握し、契約条件との整合性を継続的に検証することが不可欠です。

EBSの出口戦略は突然に　―主導権を握るのは、誰か？

EBSの利用実態とライセンス契約に乖離が見つかった時、オラクルが次にとるアクションは、単なる是正勧告にとどまりません。実際の現場では、その直後に“出口戦略”と呼ぶべき提案が提示されます。

• 「OCIへの移行もしくはFusion Cloud ERPへの刷新で、是正金額は大幅に調整できます」

一見すると、配慮ある救済策のように映りますが、実際にはクラウド移行を促進することを目的とした戦略的な提案であることがほとんどです。違反指摘という心理的インパクトが大きいタイミングで、こうした選択肢が“解決策”として提示されることで、企業は冷静な検討や他の選択肢の比較を行う余地を失いがちです。その結果、主導権はオラクル側に移り、企業は“選ばされる”立場に追い込まれてしまうのです。ここで問われるのは、企業自身がその局面において意思決定の軸を持てているかということです。

• 契約面・技術面・運用面を包括的に分析する材料は揃っているのか
• 自社にとっての最適な出口戦略を準備しているのか

もちろん、クラウド移行そのものが問題ではなく、真の問題は、クラウド移行が「指摘違反の延長上」で突如として唯一の選択肢になることです。EBS監査が企業にもたらすのは、過去の運用に対する指摘ではなく、今後のIT戦略をどの方向に進めるべきかという意思決定の分岐点です。