2026 年 6 月 1 日、Publickey が Oracle Database@AWS が大阪リージョンでも提供開始 を報じました。Oracle Database@AWS は、AWS のデータセンター内に Oracle Cloud のインフラを持ち込み、AWS 上で Oracle Database を提供するサービスです。これまで東京リージョンのみでしたが、大阪リージョンが加わったことで国内 2 リージョン構成が可能になり、DR（災害復旧）・データ主権・低遅延といった日本特有の要件に応えやすくなりました。
オンプレミスや専用ハードで Oracle Database を抱える中堅企業にとって、これは大きな意思決定の契機です。受託で基幹システムやデータ基盤を支える立場では、これは 「Oracle をやめるか否か」ではなく、「Oracle 資産をどのアーキテクチャへ、どのリスク許容度で寄せるか」を判断する移行フェーズだと捉えています。これまで AWS Aurora Serverless v4 DB 近代化受託（GH Media） で扱った DB モダナイゼーション、MySQL 9.7 LTS 近代化受託（GH Media） で扱った バージョン移行、AlloyDB ホットスタンバイ DR 設計受託（GH Media） で扱った DR 設計と接続して、本記事では 「Oracle DB クラウド移行」を 受託パッケージとして整理します。
なぜ「いま」Oracle DB のクラウド移行なのか
| 観点 | オンプレ Oracle（従来） | Oracle Database@AWS（2026） |
|---|---|---|
| 設置場所 | 自社 DC / ハウジング | AWS DC 内の Oracle インフラ |
| 国内リージョン | 自社拠点 | 東京 + 大阪 |
| DR | 遠隔地 DC を自前構築 | リージョン間 Data Guard |
| AWS サービス連携 | VPN / 専用線で接続 | 同一 VPC で低遅延連携 |
| ライセンス | 自社保有 / 保守契約 | BYOL / サブスク選択 |
| スケール | ハード調達が前提 | 弾力的にリサイズ |
| 運用責任 | 全て自社 | インフラは AWS / Oracle |
つまり今回の追加は、「Oracle を捨ててオープンソースへ全面移行」と 「Oracle のままクラウドへ持ち上げる」の間に、「Oracle を活かしつつ AWS の DR・連携を得る」現実解が国内 2 リージョンで成立したことを意味します。
受託案件で活きる 3 つの判断軸
軸 1: 「全面リプレース」か「リフト&シフト」か
PL/SQL・パーティション・RAC など Oracle 固有機能への依存度が高い基幹系は、PostgreSQL への全面移行が高コスト・高リスクになりがちです。受託では 依存度スコアリングを行い、依存が深い領域は Oracle Database@AWS へリフト、疎結合な周辺は Aurora/PostgreSQL へ寄せるハイブリッド設計を提供します。これは AWS Aurora Serverless v4 DB 近代化受託（GH Media） の Oracle 版判断フレームです。
軸 2: 「自前 DR」から「リージョン間 DR」へ
これまで遠隔地 DC を自前で構えていた DR を、東京⇔大阪のリージョン間 Data Guard / バックアップで再設計できます。受託では RPO / RTO 目標から逆算した DR 構成と 切替演習を設計します。これは AlloyDB ホットスタンバイ DR 設計受託（GH Media） の Oracle 版です。
軸 3: 「DB 単独移行」から「AWS 連携前提の再設計」へ
同一 VPC で S3 / Lambda / Redshift / SageMaker と低遅延連携できるため、DB を AWS データ基盤のハブにできます。受託では Google Spanner オンプレ分散 RDB 移行受託（GH Media） で扱った 分散 DB の知見も踏まえ、移行後のデータ活用設計まで含めます。
受託で提供する「Oracle DB クラウド移行」5 フェーズ
フェーズ 1: 現状診断（2〜3 週間）
- Oracle 資産棚卸し（バージョン / オプション / RAC / 文字コード）
- Oracle 固有機能の依存度スコアリング
- ライセンス棚卸し（保有 / 保守 / コア数）
- RPO / RTO / 監査要件の整理
- リスク + TCO マトリクス
フェーズ 2: 設計（2〜3 週間）
- 移行方式選定（リフト / Aurora 移行 / ハイブリッド）
- ライセンス戦略（BYOL / サブスク）
- 東京 + 大阪の DR 構成設計
- AWS サービス連携設計（S3 / Lambda / 分析基盤）
- ネットワーク / 暗号化 / 監査ログ設計
フェーズ 3: 構築（4〜6 週間）
- Oracle Database@AWS 環境構築
- ネットワーク（同一 VPC / 専用線）構築
- Data Guard / バックアップ構成
- IaC（Terraform）による再現可能化
- 監視 / 監査ログ（CloudWatch / 監査証跡）
フェーズ 4: データ移行・カットオーバー（3〜5 週間）
- 移行リハーサル（フルロード + 差分同期）
- 性能検証（本番相当負荷テスト）
- カットオーバー計画 + ロールバック手順
- 切替演習 + DR フェイルオーバー演習
フェーズ 5: 運用レビュー（継続）
- 性能 / コスト最適化（インスタンスサイズ）
- DR 定期演習（半期ごと）
- パッチ / バージョン管理
- ライセンスコンプライアンス監査
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| DB（リフト） | Oracle Database@AWS | Oracle on EC2 |
| DB（移行先） | Aurora PostgreSQL | RDS for PostgreSQL |
| 移行ツール | AWS DMS / SCT | GoldenGate |
| DR | Data Guard / クロスリージョンバックアップ | 手動レプリケーション |
| IaC | Terraform | CloudFormation |
| 監視 | CloudWatch + OEM | Datadog |
| データ連携 | S3 / Glue / Redshift | DataSync |
| 暗号化 | KMS / TDE | 自前鍵管理 |
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| オンプレ Oracle の保守更改が近い | 既にクラウド DB で安定運用 |
| 国内 DR / データ主権が必須 | DR 要件が緩い |
| PL/SQL / RAC への依存が深い | 依存が浅くすぐ PostgreSQL へ移行可 |
| AWS データ基盤と連携したい | DB 単独で完結 |
| ハード調達リードタイムが課題 | 弾力性が不要 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 移行範囲 | 対象 DB / スキーマ / 連携先 | 段階移行の区切り |
| ライセンス責任 | BYOL 適合性の確認 | コンプライアンス所在 |
| データ移行保証 | 整合性検証の範囲 | 欠損時の責任分界 |
| DR 要件 | RPO / RTO 達成基準 | 演習頻度 |
| 退場時引き渡し | IaC / Runbook / 教育 | 自社運用継続性 |
| コスト上限 | インスタンス / 転送費用 | 想定外課金の扱い |
価格モデル — Oracle DB クラウド移行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 220 万円〜（5 週間） | 棚卸し + 移行方式設計 | TCO レポート + 移行設計書 |
| Lite | 70 万円〜 / 月 | DB 〜5 | 月次運用 + パッチ管理 |
| Standard | 160 万円〜 / 月 | DB 5〜20 + DR | + DR 演習 + コスト最適化 |
| Enterprise | 360 万円〜 / 月 | 基幹系 / 多拠点 | + 専任 DBA + 24/365 対応 |
| 初期構築・移行 | 700 万円〜（一括） | 環境 + 移行 + DR | 全プラン共通 |
顧客側 ROI 試算（オンプレ Oracle 8 インスタンス / DR 自前構築想定）
| 項目 | 既存（オンプレ + 自前 DR） | Oracle Database@AWS 移行後 | 差分 |
|---|---|---|---|
| ハード / DC コスト（年） | 2,400 万円 | 1,500 万円 | -900 万円 |
| DR 構築・維持（年） | 1,200 万円 | 400 万円 | -800 万円 |
| ハード調達リードタイム | 12 週間 | 1 週間 | -11 週間 |
| DB 運用工数（月） | 320 時間 | 180 時間 | -140 時間 |
| 年間効果 | — | — | 約 2,800 万円相当 + 調達速度向上 |
Standard プラン（年額 1,920 万円 + 初期）でも、DR コストとハード更改の回避だけで十分に回収可能です。
ハマりやすい 5 つの落とし穴
落とし穴 1: ライセンス適合を後回しにする
BYOL の コア数・オプション（RAC / パーティション）適合を誤ると追徴リスクがあります。移行前にライセンス棚卸しを完了します。
落とし穴 2: 文字コード / ソート順を軽視する
日本語環境では 文字コード・照合順序の差異がデータ不整合を生みます。移行リハーサルで検証します。
落とし穴 3: DR を「バックアップだけ」で済ませる
バックアップ ≠ DR です。RTO を満たすフェイルオーバー演習を契約に含めます。
落とし穴 4: 性能検証を本番相当でやらない
開発環境の検証だけでは 本番ピーク負荷で破綻します。本番相当の負荷テストを必須にします。
落とし穴 5: 全面 PostgreSQL 移行を急ぎすぎる
依存が深い基幹を無理に移すと頓挫します。ハイブリッドで段階的に寄せます。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜3 | 資産棚卸し + 依存度スコアリング + TCO 試算 |
| Week 4〜6 | 移行方式 + DR + 連携設計 |
| Week 7〜12 | 環境構築 + IaC + Data Guard |
| Week 13 | 移行リハーサル + 性能検証 + DR 演習 |
| Week 13 | カットオーバー計画確定 + 運用レビュー準備 |
まとめ — 「Oracle を捨てる/残す」から「リスク許容度で寄せる」へ進化する DB 戦略
Oracle Database@AWS の大阪追加は、国内 DR・データ主権を満たしつつ Oracle 資産を活かす現実解を成立させました。受託で基幹システムを支える立場では、依存度スコアリングでリフトと移行を振り分け、東京⇔大阪の DR を設計し、AWS データ基盤と連携させる 「Oracle DB クラウド移行」が新しい主力サービスです。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で本パッケージを提供しています。「オンプレ Oracle の更改が近い」「国内 DR をクラウドで再設計したい」「Oracle 資産を活かしつつ AWS と連携したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
