オラクルとAWSの協業サービス、国内企業の基幹システムで稼働

ニュースの要点

IT基盤の導入を支援するレック・テクノロジー・コンサルティングは2026年10月7日、国内企業の基幹システムをクラウドへ移したと発表しました。オラクルとアマゾン・ウェブ・サービス（AWS）の協業サービス「Oracle AI Database@AWS」を採用しました。既存システムの更新とクラウド移行の費用課題に対応する取り組みで、9月中旬に本番稼働を始めました。

レックは、移行先の提案から契約、設計、移行までを支援しました。同社によると、災害時の復旧用環境も整え、運用コストを移行前とほぼ同水準に抑えました。顧客名、費用の内訳、復旧にかかる時間は公表していません。すべての企業が同じ費用で移行できるという発表ではありません。

ニュース出典：レック・テクノロジー・コンサルティング（PR TIMES）／原題：オラクル・AWSの協業サービスを国内大手企業の基幹システムに導入／公開日：2026年10月7日／公式発表を読む

---

イノベーション総研の考察

新規事業でAIやデータサービスを始めようとしても、必要なデータは既存の基幹システムに残っていることがあります。今回の事例は、すべてを作り直す前に、既存のデータベースを生かす選択肢を比較する材料です。ただし、移行そのものが新しい売上を生んだわけではありません。

既存データベースを残したまま、クラウドへ移す選択肢

基幹システムは、受注、在庫、会計など日々の業務を支える仕組みです。長く使ったデータベースを別の製品へ移す場合、周辺のプログラムや運用手順も変更する可能性があります。新機能の開発と移行作業が重なると、担当者も費用も不足しかねません。

オラクルは2月5日、AWSの東京リージョンでOracle Database@AWSの提供を始めました。AWS内の専用基盤でオラクルのデータベースを動かす仕組みです。これは、今回の移行事例より前に利用可能になったサービスであり、10月に初めて登場したものではありません。国内提供開始の発表

新しい基盤の選定では、便利さだけでなく、変えずに残せる仕組みを確認することが重要です。

既存の業務を止めずに段階的な変更ができれば、新規事業の担当者は新しい顧客価値の検証に時間を使いやすくなります。一方、既存製品を残すほど、その製品の契約や技術者への依存も続きます。変更を減らす効果と、将来の選択肢が狭くなる負担を合わせて見る必要があります。

二社の技術より、契約と運用をつなぐ役割に注目する

レックは3月3日に、このサービスの設計・構築支援を開始していました。サービス開始から本番導入へ進んだ点は、支援事業の実行過程として読むことができます。設計・構築支援の発表

今回、レックは既存システムを理解したうえで、オラクルとAWSの契約情報を整理し、複数分野の技術者を連携させたと説明しています。競合企業同士がサービスを組み合わせても、利用者にとって窓口や責任範囲が自動的に一つになるとは限りません。

複数社のサービスを組み合わせる事業では、顧客が迷う境目を引き受けることが提供価値になります。

読者が提携型サービスを企画するなら、障害時の一次窓口、原因の切り分け、問い合わせの引継ぎ、請求の扱いを先に書き出してください。技術上は連携できても、顧客が二社へ同じ説明を繰り返すなら、使い勝手は良くなりません。今回の発表から、障害時の詳細な責任分担までは確認できないため、その完成度を断定することはできません。

「運用費が同水準」を、同じ機能の総費用で読み直す

運用費が上がらずに復旧用環境も整ったという説明は、投資判断の入口になります。ただし、移行前と移行後で、何を費用に含めたかが分からなければ、そのまま自社へ当てはめることはできません。初期移行費、利用料、ライセンス、保守、人の確認作業を分ける必要があります。

費用比較は、平時の処理と災害時の復旧条件をそろえ、初期費用を含めて行うべきです。

たとえば、復旧までの許容時間や失ってよいデータの範囲が違えば、必要な設備も違います。安い構成が、事業を止められない時間帯にも対応できるとは限りません。また、移行期間に旧環境と新環境を並行して動かす費用が発生する可能性もあります。

自社では、一定期間の総費用と、現行業務に必要な機能を同じ表に並べると比較しやすくなります。今回の費用説明は導入支援会社の報告であり、独立した効果検証ではありません。価格の優位がすべての利用条件で成立したとは扱わないことが大切です。

本番稼働の次は、復旧と新しい利用用途を確かめる

今回の確認済みの到達点は本番稼働です。レックにとって、このサービスの初の本番導入実績でもあります。基幹業務を継続して処理できることと、新しいAIサービスが顧客に使われることは別の課題です。まず、運用が安定し、予定した費用と復旧条件を満たすかを見ます。その後に、データを使う新しい用途を検証します。

基盤の移行完了を事業の成功とせず、運用の安定と顧客価値を順に確かめる必要があります。

担当者の方は、移行後の障害件数、問い合わせ対応時間、復旧訓練の結果、実際の支出を記録できます。新用途については、誰が何の判断に使うのかを決め、小さい対象で試します。移行と新規事業の両方を一度に成功扱いすると、どこに問題が残ったのか見えにくくなります。

次の観測点は、費用の算定範囲と復旧性能が説明されるか、異なる顧客条件でも導入できるかです。具体的な条件が増えれば、今回の一事例から、自社でも使える選定材料へ近づきます。

まとめ

今回の事例は、既存のオラクル基盤とAWSを組み合わせる選択肢が国内で本番稼働に進んだものです。自社への示唆は「クラウドにすれば安くなる」ではありません。残せる資産、契約・運用の責任、復旧条件をそろえた総費用を確認し、新しい事業に使える基盤かを判断することです。