結論：二択で考えているうちは、答えは「現状維持」にしかならない
米オラクルが2026年7月22日、「Oracle Base Database Cloud@Customer」を発表しました。顧客のデータセンター内に設置しながら、クラウド型データベースの利便性を得られるという構成です。
Oracle公式の発表によれば、構成は8Uラックマウント型のエンジニアドシステムで、「Oracle X11 Compute」サーバー2台と共有ストレージシェルフ1台からなります。各サーバーは利用可能な x86 コアが60、メモリ660GB。オールフラッシュのストレージは11.6TBから始まり47.2TBまで拡張でき、ネットワークは10／25GbEです。データベースは単一サーバー内で自動的にスケールするほか、2台にまたがって配置して可用性を高めることもでき、Real Application Clusters（RAC）に対応する準備がなされています。
そして、本記事の論旨にとって最も重要な点がここです。この基盤は顧客が選んだ場所に設置される一方、その下回りのインフラはOracleが完全に管理するとされています。位置づけは、既存の「Exadata Cloud@Customer」ほどの規模は必要ないが、インフラとAI機能を自社の場所に置きたい企業向けの、中規模ワークロード用です。
この発表そのものは、Oracleデータベースを使っている企業以外には直接関係しません。しかし、ここから読み取るべき流れがあります。「クラウドに置くか、自社に置くか」という二者択一が、製品の側から崩れつつあるということです。
そして、この流れが重要なのは、日本の中堅企業のレガシー刷新が長らく次の二択で語られてきたからです。
- 選択肢A：現状のまま（老朽化したサーバを自社で持ち続ける）。
- 選択肢B：クラウドへ全面移行する。
この二択を突きつけられた企業の多くは、Aを選んできました。Bには不安が大きく、Aは何もしなくてよいからです。結果として、サポート期限が切れたサーバが社内で動き続け、誰も触れない状態が固定化しました。
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
3行サマリー（先に結論）
- オラクルが2026年7月22日、小規模構成のオンプレミス設置型クラウドDB「Oracle Base Database Cloud@Customer」を発表。部門・遠隔拠点向けの位置づけ。
- レガシー刷新を「現状維持かフルクラウドか」の二択で考えると、多くの企業は現状維持を選び、塩漬けが続く。
- まず「クラウドに出せない理由」を、法規制・契約・回線・不安の4つに分解する。そのうえで中間解を検討する場合は、運用責任・ハード更改・出口の3点を必ず確認する。
要点表：発表された製品の概要
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 製品名 | Oracle Base Database Cloud@Customer |
| 発表日 | 2026年7月22日 |
| 構成 | 8Uラックマウント型のエンジニアドシステム。Oracle X11 Compute サーバー2台＋共有ストレージシェルフ1台 |
| CPU | 各サーバー 利用可能60コア（x86） |
| メモリ | 各サーバー 660GB |
| ストレージ | オールフラッシュ 11.6TB〜47.2TB（拡張可能） |
| ネットワーク | 10／25GbE |
| 可用性 | 単一サーバー内での自動スケール、または2台への分散配置。RAC対応の準備あり |
| 運用の担い手 | 下回りのインフラはOracleが完全管理 |
| 想定用途 | Exadata Cloud@Customer ほどの規模は不要だが、インフラとAI機能を自社の場所に置きたい企業。中規模の高性能ワークロード |
| 提供開始時期・国内提供 | 本記事の確認範囲では未確定 |
※製品の仕様・提供時期・課金モデルについては、オラクルの公式情報を一次情報としてご確認ください。
「クラウドに出せない」を4つに分解する
多くの経営者が口にする「うちはクラウドに出せない」という言葉には、実際には性質の異なる4つの理由が混在しています。まずこれを分解してください。分解しないまま議論すると、結論は必ず「だからできない」になります。
理由1：法規制によるもの 特定の業種・特定のデータについて、保管場所や取り扱いに規制がある場合です。医療、金融、公共調達の一部などが該当します。この場合、規制の条文を確認する必要があります。「規制があると聞いている」ではなく、実際にどの条文が何を制限しているかを確認してください。確認してみると、想定より制約が狭いことがしばしばあります。
理由2：契約によるもの 取引先との契約で、データの保管場所や再委託が制限されている場合です。大手企業のサプライヤーになっていると、この制約は現実に存在します。契約書を確認し、制限の範囲を特定してください。交渉によって条件が変わる場合もあります。
理由3：回線・物理的制約によるもの 工場や店舗にサーバがあり、回線が細い、または不安定なため、クラウドへ移すと業務が止まるリスクがある場合です。製造現場の設備制御に関わるシステムでは、応答速度の制約から現地に置く必要がある場合もあります。これは技術的に実在する制約です。
理由4：不安によるもの 「情報が外に出るのは怖い」「何かあったときに自社で対処できない」「クラウドは高くつくと聞いた」。明確な根拠ではなく、漠然とした懸念です。
そして実務的な経験から言えば、4つ目が最も多いというのが実感です。1〜3が本当に当てはまる企業は限られており、多くの場合、根拠を確認しないまま4が1〜3の言葉を借りて表明されています。
分解の効果は明快です。1〜3が本当に該当するなら、中間解や現地設置を真剣に検討すべきです。4だけなら、不安の中身を一つずつ潰していけば、選択肢は広がります。
三択で考え直す
分解が済んだら、選択肢を三択に広げます。
横にスクロールして確認できます
| 選択肢 | 内容 | 向いている状況 |
|---|---|---|
| 現状維持 | 既存のサーバ・システムをそのまま使い続ける | 保守期限に余裕があり、業務上の制約もない場合のみ |
| 中間解 | 自社・自拠点に設置しつつ、クラウド型の運用・課金を利用する | 法規制・契約・回線の制約が実在し、かつ運用負担を軽くしたい場合 |
| フルクラウド | クラウド事業者の環境へ移行する | 制約がなく、運用の内製化に限界がある場合 |
中間解には、今回発表されたような設置型のクラウドサービスのほか、自社データセンターに置いたまま運用だけを外部に委託する形態、拠点にはデータの一部だけを残し本体はクラウドに置くハイブリッド構成など、いくつかの型があります。
重要なのは、三択にした瞬間に議論の質が変わることです。二択では「やるかやらないか」の話になりますが、三択では「どの条件ならどれを選ぶか」という設計の話になります。
中間解を選ぶときに確認すべき3点
中間解は万能ではありません。むしろ、確認を怠ると現状維持より悪い結果になり得ます。契約前に次の3点を必ず確認してください。
確認1：誰が運用するのか
中間解と一口に言っても、運用の担い手は製品によってまったく違います。ここが最初の確認点です。
大きく2つの型があります。ひとつは、インフラの管理をベンダーが担う型です。冒頭で触れたOracleの製品は、設置場所は顧客が選ぶ一方、下回りのインフラはOracleが管理するとされています。この型では、ハードウェアの監視・保守・更新の多くがベンダー側の責任になります。もうひとつは、機器を購入・リースして自社（または委託先）が運用する型です。こちらは従来のオンプレミスに近く、責任の大半が自社に残ります。
どちらの型であっても、次の点は必ず確認してください。ベンダー管理型であっても、ゼロにはならない部分だからです。
- 機器の設置場所は確保できるか（サーバルームの空き、電源容量、空調能力）。
- 電源断・空調停止・物理的な入退室管理は誰の責任か。
- 監視はどちらが行うか。異常時の通知は誰に届くか。
- ハードウェア障害時、部品交換のために誰が現地に入るのか。その手配は誰がするのか。
- 夜間・休日の対応範囲はどうなるか。
- データベースそのもののバックアップ・パッチ適用は、どちらの責任か。
最後の項目が特に重要です。インフラの管理をベンダーが担う型でも、その上で動くデータベースやアプリケーションの運用は顧客側に残ることが一般的です。「Oracleが管理してくれるから何もしなくてよい」と読み違えると、パッチ適用やバックアップ設計が宙に浮きます。管理の境界線がどこに引かれているかを、契約書レベルで確認してください。
確認2：ハードウェアの更改は誰の責任か
設置型のサービスでは、数年ごとに機器の世代交代が発生します。そのとき、次のことがどうなるかを確認します。
- 更改の費用は誰の負担か（サービス料金に含まれるのか、別途か）。
- 更改作業に伴う停止時間はどの程度か。
- 更改を拒否した場合、どうなるか（サポート対象外になるか）。
- 契約期間はどの程度で、途中解約の条件はどうなっているか。
導入時の見積もりだけで判断すると、数年後の更改費用が想定外の支出になります。
確認3：出口はどうなっているか
これが最も見落とされる論点です。中間解は、多くの場合「いずれ本格的にクラウドへ移る前の橋渡し」として選ばれます。ところが、その橋を渡り切る計画が立てられていないことが非常に多いのです。
- 数年後にクラウドへ移行する場合、データはどう移すか。
- 独自の機能・設定に依存していると、移行時に何を作り直すことになるか。
- 契約終了時、機器の撤去とデータの消去は誰が行い、費用はどうなるか。
「とりあえず中間解で凌ぐ」という判断自体は否定しません。ただし、凌いだ先をいつ、どう決めるのかを、導入時点で日付付きで決めておくべきです。決めないと、その中間解が新しい塩漬けになります。
中間解が必要かどうかの判定フロー
実務で使えるよう、判定の順序を示します。
質問1：現行システムのサポート期限はいつか。 まだ数年あるなら、急いで動く必要はありません。ただし、以降の質問には答えておいてください。
質問2：クラウドに出せない理由は、前掲の1〜3のどれかに該当するか。
- 該当しない（4のみ）→ フルクラウドを含めて検討する。不安の中身を一つずつ確認する。
- 該当する → 質問3へ。
質問3：該当する制約は、データ全体にかかるか、一部にかかるか。
- 一部のみ → その一部だけを手元に残し、残りはクラウドという構成を検討する。全部を手元に置く必要はない。
- 全体 → 質問4へ。
質問4：自社に機器を設置・運用する体制（場所、電源、担当者）はあるか。
- ある → 中間解を検討する。前掲の3点を確認する。
- ない → 中間解も難しい。制約の緩和（契約交渉、規制の再確認）から検討する。
質問3が重要です。「うちのデータは全部機密だ」と言われることがありますが、実際に精査すると、厳格な制約がかかるのは一部であることが多いのです。全部を手元に置く前提を外すだけで、選択肢は大きく広がります。
「制約がある」を確認する具体的な手順
前節で「法規制・契約による制約」を挙げましたが、それが本当に存在するかを確認する手順を示します。この確認をせずに議論している企業が非常に多いためです。
法規制の確認手順
- 自社の事業が、どの業法・ガイドラインの対象かを列挙する（医療、金融、電気通信、公共調達など）。
- 該当する規制について、データの保管場所・越境移転・再委託に関する条文を特定する。
- その条文が、自社のどのデータに、どの範囲でかかるかを確認する。
- 判断が難しい場合、業界団体の照会窓口または法務の専門家に確認する。
多くの場合、この手順を踏むと「制約がかかるのはデータ全体ではなく一部」「クラウド利用そのものは禁止されておらず、条件を満たせば可能」といった結論に至ります。規制を「禁止」と読むか「条件」と読むかで、選択肢は大きく変わります。
契約の確認手順
- 主要な取引先との基本契約書・秘密保持契約書を集める。
- データの保管場所、再委託、第三者への開示に関する条項を抜き出す。
- クラウド事業者の利用が「再委託」に当たるか、当たる場合の通知・承諾の要否を確認する。
- 制約がある場合、その取引先と交渉可能かを検討する。
4番目が重要です。数年前の契約が現在の技術環境に合っていないだけ、というケースがあります。取引先も同様の課題を抱えていることが多く、話してみると条件が緩和される場合があります。
回線・物理制約の確認手順
- 対象システムの利用拠点と、各拠点の回線帯域・冗長性を確認する。
- 現在の応答速度と、業務上許容できる応答速度を測る。
- クラウド化した場合の想定応答速度を、試験環境で測定する。
- 通信が断たれた場合に、業務が何時間止まるかを評価する。
3番目の実測は重要です。「遅くなりそうだから無理」という推測で判断されていることが多く、実際に測ると許容範囲だった、あるいは逆に想定以上に問題だった、という結論が出ます。
拠点システムをどう整理するか
中堅企業で塩漬けになりやすいのが、本社ではなく拠点・工場・店舗にあるシステムです。整理の考え方を示します。
層1：現地でなければならないもの 設備の制御、リアルタイム性が要求される処理、通信断でも動き続ける必要があるもの。これは現地に残します。
層2：現地にあるが、必ずしも現地でなくてよいもの 拠点ごとの受発注管理、在庫管理、日報。歴史的に現地に置かれてきただけで、集約可能な場合が多い層です。
層3：本来は集約すべきもの 会計、人事、顧客情報。拠点ごとに別々に持っていると、全社の数字が作れません。
この3層で仕分けると、「全部を現地に置く」「全部をクラウドに出す」のどちらでもない構成が見えてきます。層1だけを現地に残し、層2は状況に応じて、層3は集約する。この整理ができていれば、中間解が必要な範囲も明確になります。
拠点システムに固有の課題
拠点のシステムには、本社とは別の課題があります。
- 管理する人が現地にいない、または本業と兼任している。
- 機器の設置環境が悪い（工場の粉塵、温度、電源の安定性）。
- 障害時に現地へ行くまでに時間がかかる。
- 拠点ごとにバラバラの構成になっており、全体像が把握できていない。
これらは、機器を現地に置き続ける限り解決しません。中間解を検討する動機は、規制対応より、この運用負担の軽減にあることが多いというのが実務上の実感です。
運用を内製するか、委託するか
構成を決めるうえで、避けて通れないのが運用体制の判断です。
横にスクロールして確認できます
| 体制 | 向いている状況 | 注意点 |
|---|---|---|
| 自社で運用 | 専任の担当者が複数おり、育成の計画がある | 1名体制は実質的に「体制がない」に等しい |
| ベンダーへ委託 | 社内に技術者がいない、または本業に集中したい | 契約範囲の明確化が必須。丸投げは判断力の喪失を招く |
| 一部委託（ハイブリッド） | 日常は自社、専門領域は委託 | 責任分界を文書化しておく |
| クラウド事業者に任せる | 運用そのものを持ちたくない | 構成の自由度は下がる |
判断の軸は、費用ではなく継続可能性です。「今の担当者がいる限り自社で運用できる」という状態は、体制ではありません。その人が異動・退職したときにどうなるかまで含めて、初めて体制と呼べます。
情シスが1名という企業では、次のいずれかを選ぶことになります。
- 2人目を採用・育成する（時間と費用がかかるが、内製の力は残る）。
- 運用を外部に委託し、その1名は企画・調整に専念させる（現実的な選択であることが多い）。
- 運用の少ない構成を選ぶ（クラウド寄りの構成にする動機になる）。
3つ目は、構成の選択が体制の制約から決まるという意味で、重要な観点です。「理想的な構成」ではなく「自社が運用し続けられる構成」を選ぶという判断軸を持ってください。
「安いから」でも「新しいから」でもない選び方
最後に、判断の軸そのものについて触れておきます。
クラウド移行の議論では、費用比較が持ち出されがちです。「クラウドのほうが安い」「いや、長期的にはオンプレのほうが安い」。どちらの主張にも、条件次第で成り立つ根拠があります。
しかし、中堅企業にとって本当に重要なのは費用の多寡ではなく、その構成を5年後も運用できるかです。具体的には次の点です。
- その構成を扱える人材を、自社または委託先で確保し続けられるか。
- 業務の変化（新規事業、法改正、取引先の要求）に、どれくらいの速度で対応できるか。
- 障害が起きたとき、誰が何時間で復旧できるか。
情シスが1名、あるいは兼任という体制の会社にとって、「自社で全部運用する」という選択は、その1名への依存を意味します。その人が退職した瞬間に、システムが誰にも触れないものになります。この人的リスクは、費用比較の表には出てきませんが、実際には最も大きなリスクです。
中間解も含めた選択肢を検討する意義は、この人的リスクをどこまで外部に移せるかを設計できる点にあります。
FAQ
Q1. Oracleのデータベースを使っていません。関係ありますか。 A. 製品自体は関係ありませんが、「オンプレミスに置きながらクラウド型の運用を得る」という選択肢が広がっている流れは、他のベンダーでも同様です。判定フローの部分はそのまま使えます。
Q2. 中間解は割高になりませんか。 A. 一般に、専用の機器を設置する形態は、共有のクラウドサービスより単位あたりのコストは高くなる傾向があります。それでも選ぶ理由があるかどうか（制約が実在するか）を先に確認してください。
Q3. 「クラウドは情報漏えいが心配」という社内の声にどう答えればよいですか。 A. 感情ではなく事実で議論してください。自社サーバの現状（パッチ適用状況、アクセス管理、バックアップ、監視の有無）と、クラウド事業者の管理体制を並べて比較します。多くの場合、自社側のほうが管理が手薄です。
Q4. 工場の設備制御システムもクラウドに移せますか。 A. 応答速度と可用性の要件によります。制御そのものは現地に残し、データの収集・分析だけをクラウドで行う構成が一般的です。全部か無かではなく、層で分けて考えてください。
Q5. 提供開始時期が未確定の製品を検討してよいですか。 A. 具体的な導入計画を立てる段階では、提供時期と国内での提供可否を確認する必要があります。現段階では「そういう選択肢が増えつつある」という認識を持つに留めるのが妥当です。
Q6. 現行システムのサポートがもう切れています。どうすればよいですか。 A. 優先度の高い課題です。まず、そのシステムがネットワーク上でどこから到達できるかを確認し、露出を最小化してください。並行して、移行の検討を開始します。
Q7. どこから相談すればよいですか。 A. 製品ベンダーに相談すると、そのベンダーの製品を前提とした提案になります。まず、自社の制約が何で、どこまでが本当の制約なのかを整理する段階を、中立的な立場と一緒に行うことをおすすめします。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、製品の検討に入る前に整理をおすすめします。
- 「クラウドに出せない」という前提で数年間、システムの更新が止まっている。
- その制約が本当に法規制や契約によるものか、確認したことがない。
- 現行システムのサポートが切れている、または切れる時期が近い。
- ベンダーから提案を受けているが、自社に必要な構成か判断できない。
GXOは特定のクラウド・ハードウェアを販売する立場ではないため、「移行しない」という結論も含めて中立に整理できます。現行システムの構成整理と移行方式の検討はシステム開発・DXの相談、移行後のデータ活用を見据えた設計はデータ基盤・データ活用の相談、情報の取り扱いや制約の整理はセキュリティの相談、現状の全体把握から始めたい場合はDX成熟度診断が入口です。「出せない理由」の分解からご一緒することもできます。お問い合わせより、対象システムの概要をお知らせください。
「出せない」を理由に止まっている限り、システムは古くなり続けます。まず確認すべきは、その理由が本当に制約なのか、それとも確認していないだけなのか、という一点です。
参考文献
- Oracle Database Blog「Announcing Oracle Base Database Cloud@Customer」（一次・公式。構成・コア数・メモリ・ストレージ容量・Oracleによるインフラ管理・RAC対応は当該発表で確認）: https://blogs.oracle.com/database/announcing-oracle-base-database-cloudcustomer
- IT Leaders「米オラクル、"オンプレミス型クラウドDB"」（二次・報道）: https://it.impress.co.jp/articles/-/29615
※提供時期、日本国内での提供可否、課金モデルについては、オラクルの公式情報を一次情報としてご確認ください。本稿の内容は2026年7月24日時点の公表内容に依拠しています。
