はじめに

Oracle Databaseのライセンスコスト高騰を背景に、日本企業の間で「脱オラクル」の動きが加速しています。

ベネッセコーポレーションはオンプレミスのOracle環境からクラウドへ移行し、ハードウェア調達費とライセンス費を削減。田辺三菱製薬は、移行可能なシステムからPostgreSQLやSQL Serverへの段階的な切り替えを進めています。世界に目を向ければ、最大級のOracleユーザーだったAmazonが数千のDBを移行し、数億ドル規模のコスト削減と報じられたことが業界に大きなインパクトを与えました。

（出典：日本企業で「脱オラクル」加速…高額ライセンスとロックインへの懸念が背景｜ビジネスジャーナル）

私たちアレクシードベトナムも、ベトナムオフショア開発のパートナーとして、クライアントさまの基幹システムにおけるOracle→PostgreSQLのDBマイグレーションを複数お手伝いしてきました。その現場経験から言えるのは、DB移行は「やるかやらないか」ではなく「いつ、どうやるか」のフェーズに入っているということです。

ただし、基幹システムのDB移行は業務継続に直結するプロジェクトです。本記事では、メリットだけでなくリスクと判断軸を、私たちの実務経験も交えて解説します。

なぜ今「脱オラクル」が加速しているのか

理由1：ライセンスコストの構造的な問題

Oracle Databaseは高性能な反面、ライセンス体系が複雑です。CPUコア数や利用機能に応じて費用が積み上がり、年間保守費用はライセンス価格の約20%発生します。近年のOracle社のポリシー変更によりエントリー製品の提供終了や価格改定が相次いでいます。

私たちのクライアントさまからも、Oracle→PostgreSQLへの移行についてご相談をいただくことが増えています。ライセンス費用の見直しを機に移行を検討する際は、スコープの整理から実行まで一定の期間が必要なため、早めに動き始めることが重要です。

理由2：ベンダーロックインによる経営の硬直化

システムをOracleに最適化して構築すると、「他のDBに移りたくても移れない」状態に陥ります。特定ベンダーへの依存は、クラウド選定の自由度を制限し、長期的には経営上のリスクになり得ます。

ITジャーナリストの小平貴裕氏は「クラウド時代のIT戦略では柔軟なシステム構成が重要になるが、Oracle DBを中心とした構成はクラウド移行やマルチクラウド戦略を難しくすることがある」と指摘しています。

理由3：PostgreSQLの技術的成熟

移行先として選ばれるPostgreSQLは、もはや「無料だから」という理由だけではなく、技術的な実力が評価されているからです。

DB-Enginesランキングでは世界4位（OSS系では実質1位）に位置し、AWS・Azure・GCPすべてでマネージドサービスとして提供されています。トランザクション処理・JSON対応・全文検索・レプリケーションといった機能を備え、エンタープライズ用途でも採用実績が積み上がっています。
（出典：DB-Engines Ranking｜DB-Engines）

もちろん、Oracleが長年かけて磨き上げてきた機能や安定性には一日の長があります。ただ、「Oracleでなければ実現できない」要件を持つシステムは実際には多くなく、大多数の業務システムにおいてPostgreSQLは技術的に十分な選択肢です。コストと機能のバランスを冷静に判断することが重要です。

PostgreSQL移行の3つのメリット

メリット1：DB関連コストの大幅削減

PostgreSQLはオープンソースであり、ソフトウェアライセンス費用はゼロです。商用サポートが必要な場合でもOracleの数分の一のコストで済みます。

5年間のコスト比較イメージ

※ Oracle公式価格リストでは、Enterprise EditionがNamed User Plus方式またはProcessor方式で課金される。
（出典：Oracle Technology Global Price List｜Oracle）

例えば、年間Oracle費用が500万円のシステムを800万円の移行プロジェクトで移行した場合、約1.6年で初期投資を回収できる計算になります。オフショア開発を活用してプロジェクト費用を50〜70%に抑えれば、回収期間はさらに短縮されます。3年目以降はコスト削減効果がそのまま利益改善に直結します。

さらに、移行プロジェクト自体のコストもオフショア開発を活用することで抑えられます。SQL変換やテストなど工数の大きい工程を、国内の50〜70%のコストで対応できるベトナムのチームが担うことで、トータルの投資対効果はさらに高まります。

メリット2：マルチクラウド戦略への対応力

Oracleをクラウドで使い続ける際の問題は、ライセンスコストだけではありません。「BYOL（Bring Your Own License）」方式でAWSやAzureにOracle DBを持ち込む場合、クラウド側のCPUコアがそのままOracle課金の対象となるため、オンプレミスと同等かそれ以上のライセンス費用が発生します。Oracle Cloud以外でOracle DBを動かすとコストが実質倍増するケースも報告されています。

一方、PostgreSQLは主要クラウドすべてでマネージドサービスとして提供されており、インフラ利用料のみで運用できます。

さらに重要なのは、ベンダーを選ぶ自由を取り戻せることです。PostgreSQLに移行すれば、コスト・機能・リージョン・サービスの充実度を基準にクラウドプロバイダーを比較・選択できます。

• 障害時の可用性設計：マルチAZ・マルチリージョン構成が取りやすく、RTO/RPOの要件に合わせた設計が組みやすい
• クラウドネイティブサービスとの組み合わせ：AWSであればBedrock（生成AI）、GCPであればVertex AIなど、各社の最新サービスをDB側の制約なく組み合わせられる
• コスト最適化の余地：クラウド間での価格競争を利用でき、長期的に運用コストを下げる交渉力が生まれる

特定のクラウドベンダーに依存した状態では、契約更新のたびに価格交渉力を失います。PostgreSQLへの移行は、クラウド戦略の自由度そのものを取り戻す選択です。

メリット3：DX推進基盤の構築

経済産業省のDXレポートが警告する「2025年の崖」は、「レガシーシステムの維持に追われ、DX推進に人・金・時間を振り向けられない」状態を指しています。放置した場合、2025年以降に最大12兆円以上の経済損失が生じるリスクがあると試算されています。
（出典：DXレポート〜ITシステム「2025年の崖」克服とDXの本格的な展開〜｜経済産業省）

Oracle DBの高額ライセンスと属人的な保守体制に縛られた状態は、まさにこの「崖」を象徴しています。DBを刷新することで、その年間コスト・工数・依存関係を断ち切り、DX投資に振り向ける余力を生み出せます。

PostgreSQLはモダンなデータ活用基盤との親和性が高いのも大きな理由です。

• BIツールとのネイティブ連携：Tableau・Looker・Redashなど主要BIツールはPostgreSQLを標準サポートしており、追加のミドルウェアなしにデータを可視化・分析できます
• データレイク構成との接続：AWS GlueやGoogle BigQueryとの連携がしやすく、社内データを横断的に活用する基盤を作りやすい
• AI・機械学習への対応：PostgreSQL拡張の「pgvector」によりベクトル検索が可能で、RAGや社内ナレッジ検索といったAI機能の実装基盤として活用できます
• エンジニア採用・育成のしやすさ：PostgreSQLエンジニアの市場供給はOracleを大きく上回っており、採用コストや社内教育の負担が低い

DBマイグレーションは「古いシステムを置き換える」作業ではなく、データを経営に活かすための基盤を作り直す投資として捉えることで、DX推進の起点になります。

移行で押さえるべき3つのリスク

メリットだけを見て移行を進めるのは危険です。基幹システムのDB移行には固有のリスクがあり、事前の理解と対策が成功の鍵を握ります。

リスク1：SQL方言と機能差異による「変換の壁」

OracleのSQLとPostgreSQLのSQLは似ているものの、完全な互換性はありません。具体的には以下の領域で差異が発生します。

• Oracle独自関数の書き換え（NVL→COALESCE、DECODE→CASE等）
• PL/SQLのパッケージ機能（PostgreSQLには同等の概念がない）
• NULLと空文字の扱い（Oracleは同一視、PostgreSQLは区別）
• トリガー・シーケンスの構文差異

私たちが電力会社の基幹システムのDBマイグレーションを手がけた際も、この差異の洗い出しと変換検証に最も工数をかけました。そのプロジェクトでは、AIを活用した自動変換プロセスを導入することで膨大なDBオブジェクトとSQLの手動変換ミスを防ぎ、作業効率を大幅に向上させました。ここを丁寧にやれば移行後のトラブルは大幅に減らせます。（事例：電力企業 事業管理システムDBマイグレーション）

（参考：OracleからPostgreSQL移行、何に注意すべき？3つのポイントを解説｜SCSK株式会社）

リスク2：パフォーマンス特性の違い

Oracle環境で高速に動作していたクエリが、PostgreSQLではパフォーマンスが低下するケースがあります。DBの内部処理（オプティマイザ）の挙動が異なるためです。

特に、Oracleのヒント句に依存したチューニングや、ビットマップインデックス等のOracle固有機能を活用しているシステムでは、移行後のパフォーマンステストが必須です。

800件以上のプロジェクト経験から言えば、テスト工程こそDBマイグレーションの成否を分ける最重要工程です。本番に近いデータ量でのテストを移行計画に必ず組み込んでください。

リスク3：周辺システムへの影響範囲

DBだけを入れ替えても、接続する業務アプリケーション・バッチ処理・帳票出力・外部連携がOracle前提で作られていれば、それらも改修が必要です。

特に見落とされやすいのが、DBに直接接続していない間接的な依存関係です。例えば、アプリケーションが生成するSQLをORMやフレームワークが組み立てている場合、そのライブラリのPostgreSQL対応状況も確認が必要です。プロジェクト初期の段階で影響範囲を広く洗い出しておくことが、後工程での手戻りを防ぐ最大のポイントです。

移行を成功させる4つの判断軸

判断軸1：現行環境の「棚卸し」で移行難易度を可視化する

移行を決める前に、今のシステムがどれだけOracleに依存しているかを把握することが出発点です。

具体的には以下を確認します。

• データ構造の規模：テーブル数・データ量・増加傾向
• ロジックの所在：ストアドプロシージャ・トリガー・ビューにどれだけ処理が書かれているか
• 接続システムの数：業務アプリ・バッチ処理・外部連携など、DBに依存する処理の全体像
• Oracle固有機能の利用状況：シーケンス・パーティショニング・独自関数など

この棚卸しの結果によって、移行にかかる工数・期間・リスクが大きく変わります。「移行できるかどうか」の判断より前に、「どのくらいの規模感になるか」を見極めることが投資判断の前提です。

なお、この棚卸し作業はora2pgのような移行支援ツールを使うことで大部分を自動化できます。ora2pgの --type SHOW_REPORT オプションを実行すると、Oracle固有オブジェクトの一覧・SQL互換性スコア・概算工数が出力されます。（参考：ora2pg Documentation｜ora2pg.darold.net）

判断軸2：コスト比較は「5年間のTCO」で行う

移行プロジェクト自体には初期投資が必要です。しかし、判断すべきは単年の費用ではなく、5年間のTCO（総保有コスト）です。

前述の田辺三菱製薬のように、すべてを一度に移行するのではなく、移行可能なシステムから段階的に切り替えるアプローチも有効です。スモールスタートで効果を実証し、段階的に展開することでリスクとコストを分散できます。

なお、オフショア開発を活用すれば、移行プロジェクトの実行コスト自体を国内の50〜70%に抑えることも可能です。TCOの計算にこの選択肢を含めるかどうかで、投資判断の結論が変わることもあります。

判断軸3：移行方式はシステムの状態に合わせて選ぶ

コストと効果のバランスを見極め、「今のシステムの状態」に応じた方式を選択することが重要です。

判断軸4：「業務知識」と「移行技術」を兼ね備えた体制を組む

DBマイグレーションは、業務を理解している人と移行の技術を持っている人の両方がいないと成功しません。

• データの意味や業務フローを理解している社内メンバー
• SQL変換・パフォーマンスチューニング・テスト設計に精通した技術者

社内のエンジニアリソースが限られる場合は、移行実績のある外部パートナーとの協業が現実的な選択肢です。なお、オフショアパートナーの選定で陥りやすい失敗パターンについてはオフショア開発 失敗事例から学ぶ 回避すべき5つのパターンと対策もご参照ください。

現実的な体制としては、「社内メンバーが業務知識と意思決定を担い、外部パートナーが技術実行を担う」分担が機能しやすいです。社内側は業務仕様のレビューと受入テストに集中し、SQL変換・単体テスト・結合テストを外部に任せる構成です。

実際に、電力会社の基幹システムにおけるOracle→PostgreSQLマイグレーション（20人月規模）では、この体制で社会インフラとしての高い安定性を維持しながら、ライセンスコストの大幅削減を実現しました。（事例を見る：電力企業 事業管理システムDBマイグレーション）

また、印刷業界では、Oracle→MariaDBの移行に際して専用の移行ツールを開発し、手作業による変換ミスを減らしながらプロジェクトを効率的に進めた実績もあります。（事例を見る：OracleからMariaDBへのデータ移行ツール開発）

まとめ：DB移行は「攻めの経営判断」

Oracle→PostgreSQLのDBマイグレーションは、単なるコスト削減施策ではありません。

• 毎年の固定費を大幅に削減し、浮いた予算をDX投資に振り向けられる
• ベンダーロックインから脱却し、クラウド戦略の自由度を取り戻せる
• 将来のDX推進基盤を整えられる

ベネッセ、田辺三菱製薬、Amazonといった先行企業の事例が示すように、この流れは一過性のトレンドではなく、企業がITインフラの主導権を取り戻す構造的な転換です。

私たちは約20年、800件以上のプロジェクトを通じてベトナムオフショア開発の現場に立ち続けてきました。その経験から一つ言えるのは、DBマイグレーションは「やるかやらないか」ではなく「どうやるか」の段階に来ているということです。

成功のためには、以下の4点を押さえてください。

1. 現行環境の棚卸しで移行難易度を定量的に把握する
2. 5年間のTCOで冷静に投資対効果を判断する（オフショア活用も選択肢に含める）
3. システムの状態に合った移行方式を選択する
4. 業務知識と移行技術の両方をカバーする体制を組む

よくある質問

Q. OracleからPostgreSQLへの移行プロジェクト、期間の目安は？
規模によって大きく異なりますが、電力会社の基幹システム（20人月規模）では移行完了まで約6〜9ヶ月が目安です。テーブル数・ストアドプロシージャの量・接続システムの多さが工期に直結するため、まず棚卸しで規模感を把握することが重要です。

Q. Oracleの年間保守費はなぜこんなに高いのですか？
ライセンス価格の約22%が毎年自動加算される契約構造になっているからです。ライセンス自体が高額なうえ、解約・ダウングレードも容易ではないため、使い続けるほどコストが積み上がります。

Q. ora2pgだけで全自動移行はできませんか？
ora2pgはOracle環境のSQL互換性スコアや概算工数を自動出力できる優れたツールですが、全自動移行には対応していません。PL/SQLのパッケージ変換や、NULL/空文字の扱いの差異など、人手による判断と修正が必要な箇所が必ず残ります。本番環境に近いデータ量でのパフォーマンステストも必須工程です。

Q. 基幹システムでの段階的な移行は現実的ですか？
十分現実的です。田辺三菱製薬の事例のように「移行可能なシステムから順に切り替える」アプローチは、リスクとコストを分散できるため基幹システムへの全面適用前にも有効です。スモールスタートで効果を実証しながら展開する進め方が、現場では定着しています。

Q. ベトナムオフショア開発でDBマイグレーションを発注した場合のコスト感は？
SQL変換・テスト設計・結合テストなど工数の大きい工程を中心に、国内発注の50〜70%程度のコストが目安です。AIを活用した自動変換プロセスを組み合わせることで、さらにコストと期間を短縮できるケースもあります。

Q. PostgreSQLに移行した後、運用保守は難しくなりませんか？
むしろ体制を整えやすくなるケースが多いです。PostgreSQLエンジニアの市場供給はOracleに比べて大きく上回っており、採用コストや社内教育の負担が低くなります。また、AWSやAzureのマネージドサービスを使えば、DBの運用管理をクラウド側に委ねることもできます。

Q. PostgreSQL以外の移行先（MySQLやMariaDB）と比べてどうですか？
MySQL・MariaDBも有力な選択肢ですが、エンタープライズ用途ではPostgreSQLが一歩リードしています。JSON対応・全文検索・ウィンドウ関数・pgvectorによるベクトル検索など、データ活用の幅が広く、BIツールやAIとの親和性も高いためです。実際に当社でもOracleからMariaDBへの移行実績がありますが、DX推進基盤としてはPostgreSQLを選択するクライアントさまが増えています。

Q. 移行の「棚卸し」だけを先に依頼することはできますか？
はい、可能です。移行プロジェクト全体を発注する前に、現行Oracle環境の依存度調査と難易度スコアの算出だけを依頼するケースも多くあります。「移行すべきかどうか」の経営判断に必要な情報を先に揃えたい場合に適したアプローチです。まずはお気軽にご相談ください。

プロジェクトにあった方法をご提案させていただきます

弊社は約20年のベトナム オフショア開発経験を持つ日系のITソリューションのリーディングカンパニーとして、ソフトウェア開発・システム開発を提供してきています。
オフショア開発をご検討の際は是非ご相談ください。

ベトナムオフショア開発

導入事例 ｜ 資料ダウンロード ｜ 無料相談 ｜ LINEで相談