要約

  • Oracle は、データベースの名声、クラウド成長の見出し、AI インフラの発表だけで判断されるべきではなく、受け入れられたエンタープライズワークロードによって判断されるべきである。
  • 同社はデータベース状態、Exadata、自律データベース運用、復旧、ハイブリッド展開、マルチクラウド配置、エンタープライズアプリケーションにおいて信頼できる技術的深みを持つが、これらの能力が意味を持つのは、顧客が自社環境で移行、フェイルオーバー、パッチ適用、ID 管理、コスト、サポートのルーチンを実証した場合のみである。
  • 2026会計年度のデータは、同社がクラウドインフラに大きく舵を切っていることを示している：総収益は674億ドル、クラウド収益は340億ドル、クラウドインフラ収益は前年比77%増、残存履行義務は6,380億ドルに達し、大規模な AI インフラ構築に投資する一方で、フリーキャッシュフローは237億ドルの赤字であった。
  • Oracle の価値提案は、既に Oracle Database、Exadata、Fusion Applications、E-Business Suite、PeopleSoft、JD Edwards、Siebel、MySQL の資産を持ち、リプラットフォーム作業を削減し運用を統合できる組織にとって最も強力である。一方、ライセンスの複雑性、スキル依存、容量制約、統合負債、クラウドコミットメントの経済性が運用上の利益を上回る場合には弱くなる。
  • 正しい結論は条件付きである：Oracle は長期間存続するエンタープライズ状態にとって信頼できるプラットフォームとなり得るが、それはバイヤーが移行、監視、サポート、復元力、および撤退経済性をワークロードの一部として扱い、後付けではない場合に限られる。

有用な問いは、ワークロードが受け入れられているかどうかである

Oracle は、一つの名前に複数の企業が内包されているため、誤解されやすい。同社は深い導入基盤を持つデータベース企業であり、財務、人事、サプライチェーン、カスタマーエクスペリエンス、業界製品を提供するエンタープライズアプリケーション企業であり、リージョン、分散クラウドオプション、Exadata サービス、AI コンピュートを構築するクラウドインフラ企業である。また、契約がエンジニアリングと同様に重要となるライセンス、サポート、サービスの企業でもある。有用な評価は、これらのアイデンティティを一体として捉え、どれか一つをもって全体を代表させないようにしなければならない。

誤った問いは、Oracle が印象的な技術を持っているかどうかである。持っている。Oracle Database は数十年にわたるミッションクリティカルな使用実績を持つ。Exadata は、密接に統合されたデータベースコンピュート、ストレージ、ネットワーキング、ソフトウェアを中心に構築されている。Autonomous AI Database は、かつて専門スタッフを必要とした多くのデータベース運用を自動化する。Oracle Cloud Infrastructure は、コンピュート、ストレージ、ネットワーキング、ID 管理、モニタリング、データベースサービス、分散クラウドオプション、AI インフラを提供する。Fusion Applications は、共通のアプリケーションスイートとデータモデルの上にビジネスプロセスを載せる。これらは実際の能力である。

しかし、エンタープライズ価値は機能が存在するだけでは生まれない。ワークロードが受け入れられた状態に達したときに生まれる。データベース移行において、それはアプリケーションの動作が正しく、パフォーマンスが合意範囲内にあり、データ損失と復旧時間枠が理解され、バックアップとリストアがテストされ、ID 管理とネットワーク制御が整備され、可観測性が適切なチームに届き、ライセンスが文書化されており、経理チームが請求書を説明できることを意味する。エンタープライズアプリケーションの移行では、最初の起動後に承認、レポート、統合、例外キューが機能することを意味する。AI インフラでは、容量が実際に利用可能で、ワークロードが期待される経済性で実行でき、サポートが大規模な障害に対処できることを意味する。

その区別が重要なのは、Oracle の2026年における公のストーリーがクラウドインフラの成長と AI 需要に支配されているからである。Oracle は、2026会計年度の総収益674億ドル、クラウド収益340億ドルを報告した。クラウドインフラ収益は年間で77%増加し、第4四半期だけでもクラウドインフラ収益は58億ドル（前年同期比93%増）を記録した。残存履行義務は6,380億ドルに達し、Oracle は大半の増加について大規模な AI 契約によるものと述べている。これらの数字は需要と戦略的勢いを示しているが、すべての顧客のデータベース移行、災害復旧計画、サポートモデル、コストケースが機能していることを証明するものではない。

バイヤーにとって、テストは意図的に実践的である。Oracle は、移行、ハイブリッド環境、AI インフラ需要、長期にわたるエンタープライズ管理の全体を通じて、データベースおよびクラウドワークロードの状態を信頼できるものに保てるだろうか？監督、統合、保守、レビュー、例外処理、ロールバック、ユニットエコノミクスを含めた後に、ビジネスはその結果を受け入れられるだろうか？答えがイエスなら、エンタープライズ状態における Oracle の古い強みと新しいクラウド投資が相互に補強しあう。答えがノーなら、クラウドの話は既に高価な資産の上に複雑さの層を重ねるだけになる。

Oracle の重心はライセンス資産から稼働状態へ移行した

Oracle の2026会計年度の提出書類は、クラウド、オンプレミス、ハイブリッド、マルチクラウドの展開モデル全体にわたって、エンタープライズ IT フレームワークを構築、実行、サポートする製品とサービスについて述べている。この表現は重要である。同社は単にパッケージ化されたデータベースライセンスを顧客のデータセンターに販売しているわけではない。古い Oracle 資産からの移行を、完全なプラットフォーム変更よりも安全に感じさせる十分な互換性を保ちつつ、これまで顧客が自ら実行していた状態の多くを運用しようとしている。

財政構成はそのシフトを裏付けている。Oracle は、クラウド収益が2026会計年度に総収益の51%を占め、2025会計年度の43%、2024会計年度の37%から上昇したと述べた。また、クラウドインフラが2026会計年度の総クラウド収益の53%を占め、クラウドアプリケーションが47%を占めたとも述べている。これは、長らくアプリケーションとデータベースソフトウェアのライセンスで知られてきた企業にとって大きな変化である。クラウドインフラはもはや傍流の話ではない。中心的な収益エンジンになりつつある。

戦略的な魅力は明白である。Oracle は既存のデータベース顧客に対し、管理された運用モデルへ移行するためにすべてを書き直す必要はないと伝えることができる。Oracle Database を OCI、Exadata Cloud@Customer、Autonomous AI Database、Oracle AI Database@Azure、Oracle AI Database@Google Cloud、Oracle Database@AWS で稼働させることができる。データベースサービスを顧客のデータセンター、Oracle リージョン、またはその他のハイパースケーラー環境に配置できる。それらのデータベースを Fusion Applications、分析、復旧サービス、AI インフラに接続できる。大規模な Oracle 資産を持つ顧客にとって、これは真剣な提案である。なぜなら、近代化が何十年ものビジネスロジックを放棄することを必要とするのではないかという不安を軽減するからである。

同じ論理がロックイン圧力を生む。企業がデータベース状態、アプリケーションプロセス、復旧運用、AI サービス、ID パターン、サポート関係を Oracle のクラウドモデルに深く組み込めば、スイッチング問題は拡大する。顧客は運用効率を得る一方で、Oracle の価格設定、容量、サポート品質、製品ロードマップ、契約条件への依存度を高める可能性がある。これは Oracle に限ったことではない。あらゆるエンタープライズプラットフォームは、有用になるにつれて離脱しにくくしようとする。しかし、Oracle は多くの顧客が既に Oracle Database、Oracle アプリケーション、または関連するサポート契約でクリティカルなシステムを稼働させているため、特に強固な基盤から出発する。

だからこそ、受け入れられたワークロードは、ソフトウェア資産よりも優れた分析単位である。ライセンス資産はスプレッドシート上では合理的に見えても、依然として運用上の摩擦を生み出すことがある。クラウド移行はモダンに見えても、顧客を古いデータモデル、古いスキル、古い承認プロセスに縛りつけたままにすることがある。マネージドデータベースは管理者の労力を軽減できても、依然として慎重なネットワーク、ID 管理、復旧、コスト管理を必要とする。問いは、Oracle がエンタープライズスタックのさらに多くを吸収できるかどうかではない。できる。問いは、吸収された各ワークロードが、時間の経過とともに、より簡単に稼働でき、より簡単に復旧でき、より簡単に監査でき、より簡単に正当化できるようになるかどうかである。

データベースの信頼性はスローガンではなく連鎖である

Oracle の最も永続的な資産は、データベース状態への信頼である。その信頼は一つの機能から来たのではない。トランザクション処理、同時実行性、復旧、セキュリティ、レプリケーション、パフォーマンスチューニング、高可用性、サポート、そしてデータベース管理者やアプリケーションチームの蓄積されたスキルといった、一連の能力の連鎖から来ている。Oracle の現在のクラウドデータベースのストーリーは、その連鎖を、顧客が依存する部分を壊すことなくマネージド環境やハイブリッド環境へ移行させることにかかっている。

公の製品表面は広範である。Autonomous AI Database は、自動プロビジョニング、監視、バックアップ、監査、チューニング、パッチ適用、スケーリング、災害復旧、セキュリティ制御を備えたマネージドデータベースとして提示されている。Oracle は、災害復旧を有効にしなくても99.95%の稼働時間サービスレベルを持ち、Autonomous Data Guard を使用することで99.995%の可用性を達成できると述べている。また、Oracle は Exadata Cloud@Customer を、Exadata のパフォーマンスとマネージドクラウド運用を顧客のデータセンターに持ち込みながら、データレジデンシー、セキュリティ、レイテンシーの懸念に対応する手段として提示している。Exadata Cloud@Customer の資料では、オンラインスケーリング、Oracle RAC、Maximum Availability Architecture へのアクセス、自律型および非自律型データベースの統合、現在のシステムにおける極めて高いトランザクション性能および分析性能の主張について説明されている。

こうした主張は、Oracle の導入基盤にとって理にかなっている。多くのエンタープライズシステムは、どのクラウドでも容易に再構築できるステートレスなウェブサービスではない。長年にわたるストアドプロシージャ、パッケージアプリケーションの依存関係、レポーティングルーチン、コンプライアンス管理、インターフェース、運用習慣を抱えている。Oracle 互換性を維持したデータベース移行は、完全な書き換えよりもはるかにリスクが低い場合がある。これは、高いトランザクション一貫性、長期保存、複雑なレポーティング、規制対象のデータ配置、または既存の Oracle アプリケーションとの密接な統合を必要とする顧客に特に当てはまる。

しかし、信頼性は依然として連鎖である。Data Guard のドキュメントは、高可用性と災害復旧がプライマリデータベースとスタンバイデータベース、保護モード、REDO 転送、スイッチオーバー、フェイルオーバー、スタンバイの準備状況、ネットワークスループット、構成の選択に依存することを明確にしている。スイッチオーバーは計画メンテナンス中のデータ損失を回避するために使用できるが、フェイルオーバーは一部の保護モードでデータ損失を伴う可能性がある。Oracle は、より優れた分離と保護のため、プライマリとスタンバイのデータベースを異なる Exadata Cloud Infrastructures に配置することを強く推奨している。また、一部のクラスタ間のネットワークを Oracle が所有していないため、実装前に顧客がスループットを評価すべきであるとも述べている。

これは適切な詳細度である。これは、Oracle が成熟した信頼性メカニズムを持っていることを示すと同時に、顧客がそれらを設計しテストしなければならないことも示している。Data Guard を購入することは、フェイルオーバーを成功させることと同じではない。マネージドデータベースを契約することは、フェイルバック後にアプリケーションを検証することと同じではない。Exadata で稼働することは、どの保護モードがビジネスリスクに合致するかを知っていることと同じではない。銀行の決済システム、病院のスケジューリングアプリケーション、通信の課金データベースは、ネットワーク、ストレージ、コンピュート、データベースバージョン、クライアント接続文字列、フェイルオーバーロール、監視、サポートエスカレーション、ユーザー向け復旧手順といった、完全な連鎖が機能する証拠を必要とする。

Oracle の Zero Data Loss Autonomous Recovery Service も同じ議論を広げる。これは、データベースの変更をリアルタイムで保護し、本番データベースサーバーから切り離してバックアップを検証し、OCI、AWS、Azure、Google Cloud、オンプレミスのデータベース全体でポイントインタイムリカバリをサポートするように設計されている。この能力は、バックアップと復旧がまさに必要な瞬間に失敗することが多いため、意味がある。しかしここでも、受け入れられたワークロードには、製品のサブスクリプション以上のものが必要である。顧客は、どのデータベースが保護され、どの保持ポリシーが適用され、誰がバックアップポリシーを削除または変更でき、不変保持がどのように動作し、復旧がテストされているか、アプリケーションがどのように再接続し、監査人が証拠を理解できるかどうかを知る必要がある。

したがって、Oracle のデータベースの価値は、バイヤーが信頼性を運用上の証拠として扱う場合に最も強力になる。有用なパイロットはデモクエリではなく、パッチ適用、フェイルオーバー、リストア、ユーザーエラー、ID 変更、ワークロードスパイク、請求レビューを切り抜けられる移行済みワークロードである。そこが Oracle が勝てる場所である。また、計画が不十分だと、強力なデータベース機構が期待外れの結果に終わる場所でもある。

移行は、検証、ロールバック、所有権の後に初めて受け入れられる

Oracle の移行の売り文句は実利的である：可能な限り最小限の変更で既存のワークロードを移行し、その後選択的に近代化する。その移行資料は、カスタム、オープンソース、サードパーティ、Oracle のワークロードを対象とし、計画、準備、実行、検証を明示的なステップとしてカバーしている。データベース移行について、Oracle は、あらゆるバージョン、プラットフォーム、オペレーティングシステムから Exadata、Cloud@Customer、Autonomous を含む OCI データベースサービスに移行するための、オンラインおよびオフライン戦略、計画アドバイザー、自動化、ステップバイステップガイドを提供すると述べている。

このアプローチは大企業の現実に適合する。Oracle E-Business Suite の実装、PeopleSoft 環境、Oracle Database 上のカスタム Java アプリケーション、または Exadata 資産を持つ企業は、大規模な書き換えを望まないかもしれない。データセンターの負荷を下げ、バックアップ態勢を改善し、キャパシティの柔軟性を高め、クラウド分析との統合を改善し、または AI 対応サービスへの道筋を確保しつつ、アプリケーションロジックを維持したいと考えるかもしれない。Oracle は、互換性のあるクラウドパスがリプラットフォームによって生じる新たなバグのリスクを低減すると、もっともらしく主張できる。

しかし、互換性は単純さと誤解されることがある。データベースはスキーマの書き換えなしに移行できても、バッチウィンドウの変更、ネットワークレイテンシーがアプリケーション動作に影響を与える、レポートが従来のストレージ前提に依存している、ID 統合が不完全、バックアップウィンドウが決算期と重なる、ライセンス前提が変わるなどの理由で、受け入れに失敗することがある。Oracle の移行ハブ自体が、過程の一部としての検証を指摘している。それは形式的なものではない。それは、移動されたワークロードと信頼されたワークロードの違いである。

移行オーナーは、移行を成功と呼ぶ前に、いくつかの質問に答えなければならない。どのビジネストランザクションがワークロードの機能を証明するか？どの照合がデータの整合性を証明するか？どのベンチマークが通常時とピーク時のパフォーマンスを代表するか？本番稼働前にどのフェイルオーバーイベントをテストするか？新しい環境がワークロードを実行できない場合、どのロールバック経路が存在するか？アプリケーションコード、データベース構成、クラウドネットワーキング、顧客 ID にまたがる問題を、どのサポートパスがオーナーとなるか？どのコストセンターがクラウド消費を認識するか？実際に廃止できる古いシステムはどれか？

これらの質問が重要なのは、Oracle の強みがリスクを覆い隠すこともあるからだ。Oracle のツールが移行を親しみやすく見せれば、顧客は古い前提を整理する作業を過小評価するかもしれない。クラウド環境がスケールできれば、顧客はコストガバナンスを先送りするかもしれない。マネージドサービスがパッチ適用の労力を削減すれば、顧客はデータベース専門知識を早期に削減しすぎるかもしれない。サポート契約がそのまま維持されていれば、顧客は問題の所有権が実際よりも単純だと思い込むかもしれない。移行の品質は、ベンダーの自動化と顧客の説明責任の間の引き継ぎで証明される。

したがって、最良の Oracle 移行とは、最も劇的なアーキテクチャ図を持つものではない。テスト実行、ワークロードベースライン、復旧訓練、アプリケーションオーナーによる承認、検証済みの統合、文書化されたライセンスポジション、コスト制限、サポートランブック、廃止されたレガシーコンポーネントといった、地味な証拠を伴うものである。価値は、ワークロードが OCI または Exadata Cloud@Customer に移動したことではない。価値は、移行後、ビジネスが以前よりも不確実性を少なくしてそのワークロードを運用できることである。

自律運用は労苦を減らすが、説明責任を取り除かない

Oracle の自律データベースのストーリーは説得力がある。なぜなら、データベース管理には反復的で高度なスキルを要する作業が大量に含まれているからだ。プロビジョニング、パッチ適用、チューニング、スケーリング、監視、バックアップ、復旧、監査、セキュリティレビューは希少な人材を消費する。Oracle がそれらのルーチンワークの多くをデータベースサービス内で自動化できれば、顧客は人為的ミスを減らし、開発環境を高速化し、運用を標準化し、スタッフをより価値の高いタスクに振り向けることができる。

公開資料はその方向性を裏付けている。Oracle によれば、Autonomous AI Database はデータベースライフサイクルタスクを自動化し、機械学習をチューニングと診断に使用し、ダウンタイムや人的介入なしにパッチを適用し、監査を有効に保ち、バックアップを自動化し、暗号化、マスキング、リダクション、ロールベースアクセスなどの統合セキュリティ制御を提供できる。また、Oracle はデータベースを AI Vector Search やインデータベース機械学習と結びつけ、顧客がデータを別のシステムに移動させるのではなく、管理されたエンタープライズデータに AI を近づけられると主張している。

これは実際の運用テーゼである。多くの企業にとっての問題は、データベース管理者が不要だということではない。開発者が待たされ、分析チームがデータを複製し、セキュリティチームがパッチを最新に保つのに苦労する中で、管理者が反復的な保守に駆り出されてしまうことである。自動化はその負荷を軽減できる。また、サービスがうまく設計されていれば、より小規模なチームの一貫性を高めることもできる。

限界は説明責任である。自律運用は、顧客がそれを符号化しない限り、顧客のビジネス優先順位を知らない。ビジネス締め処理中にどのデータベースがダウンタイムを受け入れられるかを判断できない。パッチ適用後にアプリケーションが文書化されていない動作に依存しているかどうかを知ることができない。ワークロードの急増が正当なキャンペーンなのか、暴走ジョブなのか、セキュリティ問題なのかを、文脈なしに見分けられない。データ分類、アクセスレビュー、復旧の優先順位、コスト制限の所有権に取って代わることはできない。

Oracle 自身のクラウド責任に関する資料が、この境界を強化している。共有セキュリティモデルでは、Oracle はクラウドのインフラと運用を保護するが、データ、資格情報、アカウントアクセス、アプリケーション管理、安全なユーザー行動、IAM ポリシー、ネットワークおよびファイアウォール設定、クライアント側暗号化の選択、ワークロードの全体的なガバナンス、リスク、セキュリティについては、顧客が引き続き責任を負う。復元性モデルでは、Oracle は復元力のあるクラウドインフラを提供するが、顧客はアプリケーションの高可用性と災害復旧を設計し、障害ドメイン、可用性ドメイン、リージョンにわたって展開し、フェイルオーバーをテストしなければならないと述べている。

これは正しい分担である。また、顧客は「自律」という言葉を、無差別に監督を薄める理由として扱うべきではないことも意味する。仕事の形は変わる。すべてのインデックスを手動でチューニングする代わりに、チームはポリシー、例外、サービスレベル、証拠を監督する。各システムを手作業でパッチ適用する代わりに、パッチウィンドウを検証し、代表的なアプリケーションをテストし、結果を監視する。すべてのバックアップルーチンを手動で構築する代わりに、リストア、保持、削除の保護を証明する。運用上の成果は、新しい監督が古い手動作業よりも小さく、信頼性が高い場合にのみ現実のものとなる。

ハイブリッドとマルチクラウドは制約への回答であり、複雑さからの解放ではない

Oracle は、主要クラウドプロバイダーの中でも、より特徴的なハイブリッドおよびマルチクラウド戦略を持つ。パブリック OCI リージョン、Exadata Cloud@Customer、Dedicated Region Cloud@Customer、Compute Cloud@Customer、Oracle Alloy、そして AWS、Microsoft Azure、Google Cloud 環境の内部または隣接に配置されるデータベースサービスを提供している。これは見せかけの差別化ではない。多くの Oracle ワークロードが移行しにくいままである実際の理由、すなわちデータレジデンシー、既存システムへのレイテンシー、規制管理、パッケージアプリケーションの互換性、クラウド隣接分析、そして多くの企業が既に資産の一部を別のハイパースケーラーで標準化しているという実際的事実に対処している。

顧客にとって、これは古い二者択一を緩和できる。銀行はクラウドデータベースの自動化を望むが、データを国内または施設内に留める必要があるかもしれない。製造業者は、ローカルの工場システムへの低レイテンシーアクセスを必要とするかもしれない。ソフトウェア企業はアプリケーションサービスを AWS で実行するが、データ層を再構築せずに Oracle Database の互換性が必要かもしれない。グローバル企業は、Oracle データベースの近くで Azure の分析機能を必要とするかもしれない。Oracle の分散オプションにより、これらのバイヤーは、すべてを1つの Oracle パブリッククラウドリージョンに移行することなく、ワークロードの一部を近代化できる。

それは有用である。だが、複雑さを避けることと同じではない。マルチクラウドデータベースサービスは、プロバイダー、コンソール、ネットワーク経路、サポートチーム、ID システム、監視モデル、課金システム、調達経路の間に境界を追加する。Cloud@Customer 環境は、マネージドクラウドインフラを顧客のデータセンターに設置するが、顧客は依然としてローカル施設、ネットワーキング、物理的アクセス、データガバナンス、アプリケーション所有権の問題を抱える。Dedicated Region は OCI の機能をさらに制御された環境にもたらすことができるが、長期的なコミットメントも増大させる。

運用上の問いは、コントロールサーフェスがどこで終わるかである。Oracle データベースサービスが AWS、Azure、Google Cloud 環境の内部にある場合、アプリケーションのレイテンシーが上昇したときに、誰がインシデントを所有するのか？問題がクライアント接続プーリングなのか、クロスクラウドルーティングなのか、ストレージなのか、データベース待機イベントなのか、ID フェデレーションなのか、リージョンキャパシティなのか、プロバイダー側の変更なのか、誰が確認するのか？誰がログを持っているのか？どのチームが呼び出されるのか？どの商業契約がサービス与信またはサポートエスカレーションを管理するのか？どのクラウドコストレポートがアーキテクチャの全コストを捕捉するのか？

Oracle のマルチクラウド配置は、これらの所有権の問題を隠すことなくアーキテクチャ上の妥協を減らす場合に最も強力である。それは、すでに別のクラウドにあるアプリケーションや分析機能の近くに Oracle Database を置きたい顧客にとって良い答えとなり得る。バイヤーがそれを摩擦のない架け橋として扱うなら、弱い答えになり得る。その架け橋にも、経路設計、セキュリティレビュー、復旧テスト、パフォーマンスベースライン、サポート演習、商業的明確さが必要である。

同じことが Cloud@Customer にも当てはまる。データを顧客のデータセンターに保持することは、レジデンシーとレイテンシーの制約を解決できるが、ガバナンスを自動的に解決するわけではない。バイヤーは依然として、誰が変更を承認するのか、バックアップがどのように保持されるのか、ローカル障害シナリオがどのように処理されるのか、Oracle のリモート操作がどのように制御されるのか、ID がどのように統合されるのか、契約が変更された場合にワークロードがどのように退去するのかを決定しなければならない。ハイブリッドアーキテクチャは、エンタープライズの規律への近道ではない。それは、その規律をより多くの場所に適用する方法である。

AI インフラは、一般のエンタープライズバイヤーにとって Oracle のリスクプロファイルを変える

Oracle のクラウドインフラ成長は、ますます AI 需要と結びついている。同社は、最近の残存履行義務の増加の大半が大規模 AI 契約によるものであり、前払い分と顧客提供のハードウェア部分が合計750億ドルに達したと報告した。また、クラウドインフラ成長を支援する投資を行いながら、2026会計年度に237億ドルのマイナスフリーキャッシュフローを記録した。Oracle は、2026会計年度に430億ドルの負債と50億ドルの株式資金調達を実施し、2027会計年度には負債と株式を通じて約400億ドルの追加資金調達を見込んでいると述べた。

これらの数字は、最先端 AI 訓練クラスタを購入していない顧客にとっても重要である。これらは、Oracle が資本集約的な転換を行っていることを示している。より多くのクラウドリージョン、データセンター、GPU、ネットワーキング、電力コミットメント、長期顧客契約は、実行が良好であれば OCI を強化できる。しかし、容量の提供、サプライヤーの可用性、エネルギーコスト、顧客集中度、資金調達状況が変化すれば、プレッシャーを生じさせる可能性もある。

S&P グローバルレーティングによる2026年7月の Oracle の BBB-/A-3 への格下げは、製品の判定ではなく、有用な市場シグナルである。この格下げは、Oracle の AI インフラ構築のペースと財務的影響への懸念を反映している。それは、特定の Exadata サービスが故障するかどうかをデータベース管理者に伝えるものではない。しかし、調達・財務チームに対して、AI インフラ戦略が信用分析に影響を与えるほど重要になったことを伝えている。

このため、バイヤーの問いは「Oracle は AI で勝利しているか」よりも細分化されるべきである。AI インフラの顧客にとって問いは、約束通りに容量が提供されるか、ネットワーキングとストレージがワークロードをサポートするか、モデル訓練や推論の経済性が予測可能か、適切なリージョンで GPU が利用可能か、大規模クラスタでの障害をサポートが解決できるか、である。一般のエンタープライズデータベース顧客にとって問いは、Oracle の AI 構築が、サポートを圧迫したり、価格を上昇させたり、容量を逼迫させたり、商業行動を変えたりすることなく、プラットフォームを改善するかどうかである。

AI インフラにおける Oracle の技術的ケースは空っぽではない。OCI Supercluster の資料は、非常に大規模な GPU クラスタ、ベアメタルインスタンス、RDMA ネットワーキング、AI 訓練および推論のための高性能インフラについて説明している。Oracle AI Database と AI Vector Search は、ベクトル検索と機械学習の機能をデータベース層にもたらす。これは、企業が管理されたデータを別のベクトル専用システムに移動させることなく使用したい場合に価値がある。Fusion Applications は、ビジネスプロセス全体に AI 支援機能を追加する。これらはプラットフォーム戦略の一貫した構成要素である。

しかし、AI インフラはデータベースの信頼性と同じテストではない。データベース顧客は永続的な状態、予測可能な復旧、安定した運用を望む。AI インフラの顧客は、異なる障害パターン、より短いハードウェアリフレッシュサイクル、極端な容量変動を許容するかもしれない。Oracle は両方に応えようとしている。それは強力になり得るが、同時に運用規律をより重要にする。同社は、AI コンピュートをめぐる新たな資本集約的な競争に投資しながら、信頼できるエンタープライズ状態という古い約束を守り続けなければならない。

エンタープライズアプリケーションが技術をビジネス受容につなぐ

Oracle のアプリケーションスイートが重要なのは、受け入れられたワークロードの多くが純粋なデータベースワークロードではないからである。財務決算、給与計算実行、サプライチェーン変更、調達承認、受注、サービスケース、勤務シフト決定は、データ、権限、ルール、統合、監査証拠の上に成り立つビジネスプロセスである。Oracle Fusion Cloud Applications は、ERP、HCM、サプライチェーン、製造、カスタマーエクスペリエンス、分析を、組み込み AI と定期的な更新を備えた接続されたクラウドスイートに統合しようとしている。

魅力は Workday や SAP とある点で似ている。バイヤーは断片化されたシステムを減らし、より多くの受け入れられたビジネスアクションを望む。Oracle によれば、Fusion ERP は日常的な会計、コンプライアンス、決算業務を合理化し、サプライチェーンアプリケーションは製品イノベーション、調達、ロジスティクスを結びつけ、HCM は採用から退職まで従業員をサポートし、カスタマーエクスペリエンスアプリケーションはキャンペーン、見積、受注、更新、サービスのフローを接続する。共通の糸は画面ではなく、制御されたビジネス意思決定である。

これは Oracle のインフラストーリーにとって重要である。なぜなら、データベース層とアプリケーション層が相互に強化し合うからである。Oracle アプリケーションを実行している顧客は、OCI、Autonomous Database、Exadata、Fusion Analytics の方が、多くのベンダーにまたがって組み立てられた異種混合スタックよりも自然に感じるかもしれない。すでに Oracle Database を使用している顧客は、Fusion Applications を、ビジネスデータを既存のプラットフォームの近くに保つ方法と見なすかもしれない。別のクラウドを使用している顧客は、そのクラウドのアプリケーションや分析サービスの近くに埋め込まれた Oracle データベースサービスを好むかもしれない。Oracle の戦略は、すべてのワークロードを1つの物理的な場所に強制することなく、スタックが統合されているように感じさせることである。

リスクは、ビジネスプロセスの受容がプラットフォーム統合よりも難しいことである。ERP の決算は、AI が差異を説明できるから受容されるのではない。元帳が正しく、承認が完了し、例外が理解され、監査証拠が利用可能で、下流のレポーティングが整合しているから受容されるのである。サプライチェーンの推奨は、モダンなインターフェースで届くから受容されるのではない。マスターデータ、サプライヤー制約、在庫記録、リードタイム、リスクポリシーが信頼できるから受容されるのである。給与や HR のアクションは、HCM がクラウドにあるから受容されるのではない。従業員記録、給与ルール、承認、プライバシー管理、統合がサイクルごとに機能するから受容されるのである。

したがって、Oracle のアプリケーション AI は、自律的真実としてではなく、監督されたビジネス支援として評価されるべきである。有用な質問は平凡で厳格である。財務ユーザーは、提示された仕訳や差異の説明がなぜ表示されたのかを見ることができるか？調達レビュー担当者はソーシング推奨に異議を唱えることができるか？HR マネージャーは、ワーカフォース提案の背後にあるポリシーとデータを理解できるか？アクセス要求を職務分離ルールに照らしてチェックできるか？監査人は、誰がどの変更を承認し、なぜ承認したのかを再構成できるか？

これらの質問は、Oracle のアプリケーションストーリーを弱めるものではない。それをより現実的にする。Oracle のアプリケーションは、データベース状態、プロセス制御、ビジネス証拠を結びつけるときに最も価値がある。バイヤーが組み込み AI をプロセス所有権の代替物と誤解するときに最も価値が低くなる。

セキュリティ、ID、復旧可能性は依然として共有責任である

Oracle の信頼ポジションは、セキュリティ、プライバシー、可用性、コンプライアンスのシグナルに支えられているが、それらのシグナルは正しく読み取られなければならない。Oracle Cloud は可用性、管理性、パフォーマンスに関するサービスレベル契約を提供している。そのトラストセンターは、OCI と Fusion Cloud Applications のリアルタイムステータスと履歴を顧客に案内する。OCI のドキュメントは、セキュリティと復元性の共有責任を説明している。課金ドキュメントは、コスト分析、予算、コストレポート、請求書、使用状況明細、サポートリワードを提供する。契約ページは、クラウドサービスが契約、注文書、サービスポリシーに依存することを示している。

これらはすべて有用である。エンタープライズバイヤーに検討材料を与える。しかし、デフォルトで顧客のワークロードを安全にしたり復旧可能にしたりするわけではない。

ID が最も明確な例である。Oracle は IAM サービス、コンパートメント、ポリシー、監査ログ、暗号化ツール、セキュリティサービスを提供できる。それでも顧客は、アカウント構造、最小権限アクセス、フェデレーション、緊急アクセス、ローテーション、職務分離、統合ユーザー、特権データベースロール、レビュールーチンを設計しなければならない。適切に構築された OCI テナンシは安全になり得る。不十分に管理されたテナンシは、機密データを露出させたり、過剰なアクセスを許したり、復旧を困難にしたりする可能性がある。

復元性も同様に明確である。Oracle の復元性に関するドキュメントは、OCI が災害または停止時に、顧客のテナンシ内のアプリケーションリソースとデータを別の可用性ドメインまたはリージョンに自動的に複製、展開、フェイルオーバーするわけではないと述べている。顧客は、障害ドメイン、可用性ドメイン、リージョンにわたってリソースを展開し、RPO および RTO 目標を定義し、高可用性と災害復旧計画を文書化し、フェイルオーバーをテストする責任を負う。これは欠陥ではない。クラウド責任がそう機能するのである。しかし、それは魔法のような思考に対する安全弁である。

復旧可能性にもビジネスコンテキストがある。データベースバックアップが存在していても、どの時点にリストアすべきか、どの下流システムを調整しなければならないか、処理中のトランザクションをどのように扱うか、ユーザーとどのようにコミュニケーションを取るか、復旧状態を監査人にどのように証明するか、誰も知らなければ、組織にとって失敗となり得る。フェイルオーバーが技術的に機能しても、アプリケーションが誤ったエンドポイントに接続したり、サポートチームがロール移行のトリガーを誰が承認する権限を持っているか知らなければ、ビジネスに損害を与える可能性がある。

したがって、セキュリティと復旧は受け入れテストの一部であるべきである。バイヤーは、成功を宣言する前に、リストア、フェイルオーバー、ロールレビュー、キー管理、ネットワーク分離、監査エクスポート、コストアラート、サポートエスカレーションをテストすべきである。認証バッジや SLA カテゴリの強さだけで本番稼働日を受け入れるべきではない。Oracle は強力な制御を提供できる。顧客は自らのワークロードでその制御を証明しなければならない。

ライセンスとコストは調達詳細ではなく運用上の事実である

Oracle の商業的ケースは、クラウドの表示価格だけで評価することはできない。顧客は、ライセンス、サポート契約、クラウドコミットメント、移行作業、パートナーサービス、内部スタッフ、統合保守、トレーニング、セキュリティレビュー、ネットワーク接続、可観測性、データ出力、バックアップ保持、災害復旧キャパシティ、アプリケーション近代化、廃止、撤退コストを含めなければならない。

Oracle は役立つツールを提供している。OCI コスト管理には、見積もり、予算、コスト分析、スケジュールレポート、コストレポート、サブスクリプション詳細、請求書、使用状況明細が含まれる。Oracle Support Rewards は、OCI の使用によるリワードを、対象となるオンプレミスサポート契約に適用できる。移行資料は、既存ライセンスをクラウドサービスに持ち込むことやサポート相殺について言及している。これらは大規模な Oracle 資産を持つ顧客にとって意味がある。近代化の経済性を変え得るからである。

同じ機能が複雑さを生むこともある。Oracle のクラウドサービス契約は1ページではない。契約モデルは、契約、注文書、サービスポリシーを組み合わせたものである。サービス記述、ホスティングポリシー、サポート条件、データ処理条件、製品固有の制限事項がすべて重要になり得る。クラウドコンピューティング環境でソフトウェアをライセンスするための Oracle のポリシーは、認定クラウド環境での vCPU カウントを顧客に要求し、Standard Edition 展開の制限も含む。これを後回しにするバイヤーは、予算やコンプライアンス上の驚きを生む可能性がある。

したがって、受け入れられたワークロードには商業的ランブックが必要である。どのライセンスが使用されているのか？どれがライセンス込みのクラウドサービスか？どれが BYOL か？どのサポート契約が残っているのか？どのサポートリワードが適用されるのか？どの機能がデータベースオプションを必要とするのか？どのリージョン、スタンバイデータベース、災害復旧リソースがコストを追加するのか？どのスケーリングイベントが請求を変更するのか？予算超過前にどのコストアラートが発火するのか？どの古いハードウェア、ライセンス、サポート契約が廃止できるのか？

ユニットエコノミクスはまた、Oracle が単に作業を移動させるのではなく、削減するかどうかにも依存する。Autonomous Database が日常的なパッチ適用とチューニングを削減しても、顧客が他の場所で同じサポート負担を維持すれば、節約は小さいかもしれない。OCI がインフラコストを下げても、移行が数年にわたるコンサルティング支出を生めば、回収は遅いかもしれない。Cloud@Customer がレジデンシーを解決しても、顧客を大規模な長期プラットフォームコミットメントに縛るなら、戦略的価値は依然高いかもしれないが、それは正直に認識されるべきである。

Oracle の最良の商業的ケースは、パフォーマンス＋制御－回避された複雑さである。顧客がデータベースを統合し、古いインフラを廃止し、手動管理を削減し、復旧を改善し、データをアプリケーションの近くに保ち、既存のスキルを活用し、完全な書き換えを回避できる場合に最も強力である。顧客がライセンスポジション、データアーキテクチャ、アプリケーション依存関係、運用所有権を整理せずにクラウド容量を購入する場合に最も弱い。

市場証拠は勢いを支持するが、必然性ではない

Oracle には勢いがある。2026会計年度の結果は、強力なクラウドインフラ成長、過去最高の残存履行義務、そして総収益の半分を超えたクラウド収益の構成比を示した。製品ポートフォリオは、データベース、アプリケーション、ミドルウェア、インフラ、分析、AI、業界ワークロードに及ぶのに十分に広い。Oracle の公開サマリーによると、Gartner は2025年の Magic Quadrant for Strategic Cloud Platform Services において Oracle を Leader と認定した。Synergy Research の2025年第3四半期のクラウドインフラレポートでは、依然として Amazon、Microsoft、Google がエンタープライズクラウドインフラ支出の63%を占め、Oracle は注目を集めつつあるはるかに小さな追走グループに位置している。

この組み合わせは重要である。Oracle は大きく、収益性があり、戦略的に関連性があるが、単に AWS、Azure、Google Cloud の4番目のコピーではない。データベース重力、Exadata パフォーマンス、ハイブリッド配置、エンタープライズアプリケーション、マルチクラウドデータベースサービス、深い既存顧客関係という異なる楔を持っている。意味を持つために、すべての一般的なクラウドワークロードを勝ち取る必要はない。Oracle 中心のワークロード、データベース依存のエンタープライズ、インフラ設計を評価する AI 顧客にとって、最も信頼できる場所である必要がある。

欠点は、楔が境界になり得ることである。既に Oracle 中心でない顧客は、AI 容量、価格性能、データベース統合、またはソブリン展開オプションが決定的でない限り、OCI を一般的なプラットフォームとして採用する理由が少ないと見るかもしれない。既に別のクラウドのネイティブサービスに投資している開発者は、ほとんどの新しいアプリケーションをそこに置き続けることを好むかもしれない。ライセンスやサポートの摩擦を懸念する企業は、Oracle を既存ワークロードに不可欠と見なしつつも、代替手段が成熟している分野への依存拡大を避けるかもしれない。

これが、容量発表が判断を支配すべきでない理由である。クラウドの価値は利用可能なコンピュートだけではない。エコシステムの深さ、サポートの応答性、リージョンカバレッジ、開発者の習熟度、サードパーティツール、マーケットプレイスの成熟度、セキュリティ運用、コストの予測可能性、移行スキルである。Oracle はそのポジションを改善してきたが、バイヤーはなおもクラウド成長が問題を解決すると想定するのではなく、正確なワークロードを評価すべきである。

したがって、市場シグナルはバランスが取れている。Oracle のクラウドインフラ急増は、同社を変えるのに十分現実的である。データベースとアプリケーションの基盤は、エンタープライズ近代化への永続的なルートを与える。AI 構築は OCI を戦略的にさらに重要にする可能性がある。しかし同じ構築は、資本集約度、実行リスク、顧客集中度の問題を増大させる。勢いは賭け金を上げるが、勤勉さを排除するわけではない。

バイヤーが Oracle を信頼する前にテストすべきこと

真剣な Oracle 評価は、最も良く見えるスライドではなく、最も苦痛なワークロードから始めるべきである。データベース資産については、実際のトランザクションパターン、レポーティング負荷、バッチジョブ、統合依存関係、復旧要件を持つ代表的な本番ワークロードを選ぶ。アプリケーション資産については、承認、データ品質、レポーティング、下流システムにまたがるプロセスを選ぶ。AI インフラについては、単なるベンチマークではなく、実際の訓練または推論の経済性を反映するワークロードを選ぶ。

最初のテストは移行の正確性である。バイヤーは移行後にデータ整合性、アプリケーション動作、パフォーマンス、バッチタイミング、ユーザーアクセス、レポーティング、照合を証明すべきである。ワークロードがそのまま移行されるなら、古い前提をテストする。リプラットフォームされるなら、新しい前提をテストする。自律機能が導入されるなら、ユーザーがそれらをどのように監督し、例外がどのように表面化するかをテストする。

2番目のテストは復元性である。フェイルオーバーを実行する。リストアを実行する。バックアップの不変性と削除保護をテストする。インフラチームだけでなく、ビジネスオーナーと共に RPO と RTO を確認する。アプリケーション接続動作、DNS、ID、監視、ランブックの明確さ、サポートエスカレーションを検証する。リージョン、可用性ドメイン、ネットワークリンク、データベースノード、統合ユーザー、またはキー管理パスが失敗した場合に何が起こるかを文書化する。

3番目のテストはセキュリティと監査可能性である。IAM ポリシー、コンパートメント、データベースロール、特権アクセス、統合アカウント、暗号化の選択肢、監査証跡、データマスキング、職務分離をレビューする。誰がバックアップ、ネットワーキング、データベースオプション、コスト設定を変更できるかを確認する。監査人やリスクチームが実際に使用できる形式で証拠をエクスポートする。

4番目のテストはコスト管理である。楽観的な見積もりではなく、実際のワークロード消費を用いる。スタンバイキャパシティ、ストレージ増加、バックアップ保持、データ転送、サポート、ライセンス、パートナー作業、内部人件費、旧システム廃止を含める。予算とコストアラートをテストする。予期せぬ支出の所有者を決定する。Support Rewards や BYOL の経済性がケースの一部であるなら、契約と実際の展開設計に照らして検証する。

5番目のテストはサポートである。パイロット中に簡単ではないサポートケースを開く。誰が応答し、どの情報が必要か、問題がどれだけ迅速にトリアージされるか、問題がデータベース、クラウドネットワーキング、アプリケーション、顧客コードにまたがる場合に何が起こるかをテストする。ミッションクリティカルなワークロードは、製品設計だけでなくサポート行動に依存する。

6番目のテストは離脱と変更である。ワークロードを再度移動しなければならない場合、クラウドコミットメントが変わった場合、データベースオプションが高価になりすぎた場合、ビジネスユニットが別のプラットフォームに移る場合、または規制当局が異なるデータ配置を要求する場合に何が起こるかを問う。Oracle は依然として正しい選択であり得るが、バイヤーは離脱や再構築に何がかかるかを理解すべきである。

これらのテストは敵対的ではない。それは、エンタープライズ状態を信頼するための通常の代価である。Oracle の最も強力な製品はそれらに耐えるはずである。これらをスキップするバイヤーは楽観的であるのではなく、リスクを調達から運用へと移しているのである。

測られた評決

Oracle は信頼できるエンタープライズ状態のための真剣なプラットフォームであるが、単一の物語で評価されるべきではない。データベースの物語は信頼できる。なぜなら Oracle はトランザクション、パフォーマンス、高可用性、Exadata、復旧、マネージド運用に関して成熟した技術を持っているからだ。クラウドの物語は信頼できる。2026会計年度の結果が実際のインフラ需要を示しており、Oracle が Oracle 中心の資産の制約に適合するパブリック、ハイブリッド、マルチクラウドの展開経路を構築したからだ。アプリケーションの物語は信頼できる。ビジネス受容がデータベースだけでなく、財務、人事、サプライチェーン、顧客プロセスに宿ることが多いからだ。AI の物語は、Oracle の成長プロファイルを変えるのに十分信頼できるが、実行と財務監視を強めるほど資本集約的である。

リスクも明確である。Oracle は手作業を減らせるが、データ品質、ID、復旧、統合、コスト、ライセンス、サポート所有権に関する顧客の説明責任を取り除くことはできない。より多くのクラウドやより多くの顧客管理環境にデータベースサービスを配置できるが、それがマルチクラウドの複雑さを取り除くわけではない。パッチ適用とチューニングを自動化できるが、顧客は依然として例外を監督し、ビジネスへの影響を検証する必要がある。巨大な残存履行義務を報告できるが、バイヤーは依然として自らのワークロードにキャパシティ、復旧可能性、意味のある経済性があるという証拠を必要とする。

2026年の Oracle を理解する最善の方法は、エンタープライズワークロード受容会社としてである。その価値は、データベース、アプリケーション、またはクラウドワークロードが信頼できる稼働状態への困難な移行を完了したときに現れる。証拠は、顧客が既に Oracle 重心を持ち、互換性の恩恵を受けられ、移行規律に投資し、フェイルオーバーをテストし、ID を管理し、ライセンスポジションを理解し、総運用コストを追跡している場合に信頼を支持する。証拠は、バイヤーが運用モデルを証明せずにクラウドや AI の見出しを追いかけている場合に注意を支持する。

Oracle の本当のテストは、より多くのクラウドインフラを構築できるか、エンタープライズソフトウェアにさらなる知能を付加できるかではない。それは、クリティカルなワークロードが来月も稼働し、次のパッチを切り抜け、次の障害後に復旧し、自らを監査人に説明でき、商業的制限内に収まり、元の移行チームが去った後もなお道理にかなっているかどうかである。それは容量発表よりも難しいテストである。それこそが、Oracle が維持したいと望むエンタープライズにとって唯一重要なテストである。