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 / 教育 | 自社運用継続性 |
| コスト上限 | インスタンス / 転送費用 | 想定外課金の扱い |
顧客側 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 万円相当 + 調達速度向上 |
移行そのものにも構築・運用コストはかかりますが、DR の自前構築とハード更改の回避だけで回収の目処が立つケースは少なくありません。まずは自社の資産構成で TCO を試算するところから始めるのが現実的です。
ハマりやすい 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 データ基盤と連携させる——これが 2026 年の Oracle DB クラウド移行の基本線になります。
Oracle DB のクラウド移行は、資産構成・ライセンス・DR 要件によって進め方も規模も大きく変わります。「オンプレ Oracle の更改が近い」「国内 DR をクラウドで再設計したい」「Oracle 資産を活かしつつ AWS と連携したい」といったご相談は、要件をうかがったうえで個別にお見積りします。お問い合わせフォーム からお気軽にどうぞ。
