マルチクラウドの構成はどう決める？6つの制約から導く最適配置の考え方

オンプレミス環境をクラウドへ移行するとき、マルチクラウドとシングルクラウドのどちらを選ぶべきかは、システムの構成や要件、目的によって変わります。管理する対象が1つにまとまるぶん、一般的にはシングルクラウドのほうがコストや運用の負荷を抑えやすいと考えられます。
ただし実際には、既存のライセンスや移行制約といった要件から、マルチクラウド構成を選んだほうがメリットにつながるケースもあります。判断を分けるのは、クラウド同士の優劣ではなく自社が抱える制約です。本記事では、マルチクラウドを選択することで環境を最適化した実例とともに、構成を左右する6つの制約領域と、そこから最適配置を導く手順を解説します。

本記事は、ＪＢＣＣが2026年5月に実施したセミナー「6社コンペを勝ち抜いたマルチクラウド＆コスト最適化提案、その決め手とは ～お客様事例から紐解く Azure 移行成功のポイント～」（登壇：ＪＢＣＣ株式会社　長岡 賢陽）の内容をもとに編集・再構成しました。

マルチクラウドの構成を検討するとき、多くの企業がまず各クラウドの機能比較表を並べます。しかし実際に配置を決めているのは、クラウド側の性能や機能ではなく、自社システムが抱える制約です。この章では、構成検討の出発点をどこに置くべきかを整理します。

マルチクラウド構成の基本の考え方

マルチクラウドとは、複数のパブリッククラウドを適材適所で併用する構成のことです。Azure にWindows サーバー群を集約しつつ、Oracleデータベースだけは別のクラウドに置く。あるいは大容量のファイルサーバーだけ、その用途に強いサービスを選ぶ。こうした「用途ごとに置き場所を変える」考え方が基本になります。
複数のクラウドを使うと聞くと、構成が複雑になり管理の手間が増えるという印象を持つかもしれません。実際、管理対象が増えることは事実です。それでもマルチクラウドが選ばれるのは、複雑さを上回るメリットが生じる条件があるためです。その条件こそが、本記事で扱う「制約」にほかなりません。
なお、マルチクラウドの定義そのものや、オンプレミスと組み合わせるハイブリッドクラウドとの違いについては関連記事で詳しく解説しています。本記事では「どう組み合わせを決めるのか」という設計の側面に絞って進めます。

※関連記事：マルチクラウドとは？メリットやハイブリッドクラウドとの違いをわかりやすく解説

シングルクラウドとマルチクラウド、どちらを選ぶべきか

結論として、どちらが優れているかを一般論で決めることはできません。判断はシステムの構成、要件、そして移行の目的によって変わります。
まず前提として、シングルクラウドには明確な利点があります。管理インタフェースが1つにまとまり、運用ルールも統一しやすく、契約や請求も単純化できるためです。習熟すべき技術領域が絞られることから、担当者の負荷も抑えられます。特別な事情がなければ、単一のクラウドに寄せるほうが合理的でしょう。
問題は、その「特別な事情」が大規模な移行では高い確率で発生することにあります。たとえばサーバーが数百台規模になると、オンプレミス時代に導入したソフトウェアのライセンス、IPアドレスを変更できないレガシーアプリケーション、数十テラバイトを超えるファイルサーバーといった要素が必ずと言っていいほど混在します。これらを1つのクラウドに無理に収めようとすると、特定の領域だけコストが跳ね上がったり、そもそも移行そのものが成立しなかったりする場合があります。
両者の特徴を整理すると、次のようになります。

つまりマルチクラウドは、はじめから目指すべきゴールではありません。制約を1つずつ解いていった結果として、複数のクラウドに分かれる。そういう性質のものだと捉えるのが実態に近いでしょう。

構成検討の起点は「制約の棚卸し」

そこで検討の起点になるのが、移行制約の棚卸しです。VMwareのライセンス体系の変更やハードウェアの価格上昇を背景に、基盤刷新の判断を迫られる企業が増えています。限られた時間のなかで移行先を決めるとなると、つい各クラウドの機能や料金の比較から入りたくなるものです。

しかし順序を逆にしたほうが、検討ははるかに速く進みます。まず自社の制約を洗い出す。すると「この制約があるからこのサービスは使えない」「この要件を満たせるのはこの構成だけ」という形で、選択肢が自動的に絞り込まれていきます。移行できるか・すべきかは、制約を洗い出した時点でおおむね決まっているのです。
次章では、その制約を6つの領域に分けて整理します。自社環境のチェックリストとしても活用してみてください。

クラウド移行における制約は、大きく6つの領域に整理できます。これはＪＢＣＣが多数の移行アセスメントを通じて体系化したもので、現行環境とクラウドの適合状況を突き合わせる「Fit＆Gap」の検討事項にあたります。ここで挙げる観点に沿って自社環境を棚卸しすれば、マルチクラウド構成の骨格が見えてきます。

ソフトウェアライセンスポリシー

最初の、そして最も構成を左右しやすい制約がソフトウェアライセンスです。すでに導入しているソフトウェアが、クラウド上での稼働をサポートしているかどうか。ライセンスの課金方式がクラウドでどう変わるのか。この2点を確認します。
特に注意が必要なのは、パッケージ製品のなかにはそもそもクラウドでの利用をサポートしていないものが残っている点です。特定のクラウドでは動作保証がなく、別のクラウドなら保証されるというケースもあります。この時点で、移行先の選択肢が絞られることになります。
加えて、Oracleデータベースのようにクラウドごとにライセンスの必要数が変わる製品もあります。オンプレミスと同じ感覚で見積もると想定外の費用が発生しかねません。この論点は後の章で詳しく扱います。

非機能要件制約

可用性や性能といった非機能要件も、クラウドでは考え方を切り替える必要があります。象徴的なのがサイジングです。オンプレミスでは調達サイクルの長さから、将来の負荷増を見込んで余裕を持たせた構成を組むのが一般的でした。しかしクラウドは使った分だけ課金される仕組みであり、その余裕がそのまま費用として跳ね返ります。
認証、ウイルス対策、ログ管理、バックアップ、監視、災害対策といった共通系の機能も、この領域で設計を見直します。オンプレミスの仕組みをそのまま持ち込むのか、クラウドのマネージドサービスに置き換えるのか。判断次第で、必要なサービスも移行先も変わってきます。

ネットワーク構成変更

クラウドのIaaSでは、原則としてオンプレミスで使っていたプライベートIPアドレスをそのまま引き継ぐことができず、IPアドレスの変更が発生します。
この変更が問題になるのは、IPアドレスを直接指定して連携しているレガシーなアプリケーションを抱えている場合です。影響範囲が広いと、アプリケーションの改修が現実的でなくなり、移行そのものの制約になります。この制約への対処法については、後の章で具体的な選択肢を紹介します。
あわせて、クラウドとオンプレミス拠点をどう接続するかというネットワーク構成、そしてシステム間接続で許容できるレイテンシも整理しておきます。

物理デバイス制約

見落とされがちですが、物理デバイスはクラウドに持ち込めません。EDIで使うINS回線のルーターのように、物理的な機器や回線に依存する仕組みがある場合、その部分だけはクラウド化できないことになります。
該当する機器があるなら、オンプレミスに残すのか、サービスそのものを別の方式へ切り替えるのかを早い段階で決めておく必要があります。ここが未確定のままだと、移行計画の後半で全体構成の見直しを迫られかねません。

クラウド技術制約

ネットワークの通信方式や暗号化の要件など、技術面でクラウドが対応していない項目がないかも洗い出します。現行環境で当たり前に使っている技術が、クラウドでは同じ形で再現できないことがあるためです。
重要なのは、制約を見つけたら同時に回避策の有無まで検討することです。回避できる制約なのか、回避できず配置を変えるしかない制約なのか。この仕分けが、後の構成判断を左右します。

社内情報セキュリティポリシー

最後は技術ではなく、規程面の制約です。社外委託の条件、監査の条件、環境の資格要件、システムやデータの所在を明確にできるか。こうした社内の情報セキュリティポリシー（コンプライアンス）に準拠できるかどうかを確認します。
技術的には問題なく移行できても、社内規程が許さないという理由で構成変更を余儀なくされる例は少なくありません。技術面の棚卸しと同時に、規程面の確認も進めておくのが確実です。

制約を棚卸ししたら、次に決めるのは「サーバーの大半をどこに置くか」、いわば土台となるクラウドです。ここでの判断材料は、多くの企業でコストになります。この章では、判断の前提となるサーバー構成の実態と、Windows 環境で効いてくるライセンスの考え方を見ていきます。

企業サーバーの実態：7割以上が小規模サーバー

ＪＢＣＣがこれまで実施してきたアセスメントの結果を見ると、興味深い傾向が浮かび上がります。サイジングを適正化した後の企業サーバーは、CPUコア数が1〜2コア程度の小規模サーバーが7割以上を占める傾向があるのです。鉄道、商社、流通、製造と業種が異なっても、この傾向は共通して確認されています。
一方、適正化を行う前の環境では、小規模・中規模・大規模がそれぞれ3割程度に分散しているケースが目立ちます。この差が示しているのは、オンプレミス環境には余剰なサイジングが含まれがちだという事実です。
使った分だけ課金されるクラウドでは、この余剰がそのまま無駄な費用になります。逆に言えば、サイジングを適正化するだけでコストを抑えられる余地が、多くの企業に残されているということ。移行のプロセスとして、必ず通しておきたい工程です。

サイジングツールの違いも見落とせない

サイジングの適正化には、各クラウドベンダーが提供する評価ツールを使います。どれも同じようなものだと思われがちですが、収集できるデータには違いがあります。
たとえばCPU使用率とメモリ使用率は、いずれのツールでも取得できます。差が出るのはストレージです。ディスクの使用率しか取得できないツールもあれば、ディスクのIOPSやスループットまで取得できるツールもあります。
この違いは、移行後の性能に直結します。容量だけを見て移行した結果、必要な性能が出ないという事態は避けたいところ。ストレージの性能まで見たうえでサイジングできるツールを選ぶことが、移行後のトラブルを防ぐポイントになります。

Windows サーバーのライセンスを持ち込める「Azure ハイブリッド特典（AHB）」

オンプレミスのアプリケーション基盤は、Windows OS で構成されている企業が多くを占めます。この場合に検討したいのが、Azure ハイブリッド特典（AHB）です。
これは、ソフトウェアアシュアランス（SA）が付いた Windows Server のライセンスをクラウドに持ち込む（BYOL）ことで、仮想マシンのOSライセンス費用の負担を抑えられる制度です。Microsoft も公式に、Windows Server の資産を移行することでコスト削減が見込めると案内しています。
ポイントは、この差が月々の利用料に効いてくる点にあります。クラウドの費用は初期投資ではなく継続的な運用費として発生するため、長く使い続けるほど累計の差は広がっていきます。オンプレミスのアプリケーションを10年近く使い続ける企業にとって、無視できない要素になり得ます。

土台となるクラウドを決めても、それだけでは解けない制約が残ります。Oracleデータベース、大容量のファイルサーバー、そして移行そのものが難しいサーバー。ここからがマルチクラウド構成の本題です。それぞれの制約に対する組み合わせの定石を見ていきましょう。

Oracle DBの制約にはOCIの併用

100台を超える規模の環境では、Oracleデータベースをまったく使っていないという企業はほとんどありません。ＪＢＣＣのアセスメント実績でも、全体の1割程度をOracleサーバーが占めるケースが多く見られます。そして、このOracleがマイグレーションのボトルネックになりがちです。
理由はライセンスポリシーにあります。Oracleが承認クラウド環境と位置づけるAWS・Azure・GCPでは、Standard Edition 2（SE2）は8vCPUまでしか利用できません。これを超える構成が必要になると、より高価なEnterprise Edition（EE）へ切り替えざるを得なくなります。負荷の高い処理を担うOracleサーバーでは、十分に起こり得る話です。

一方、Oracle自身が提供するOCI（Oracle Cloud Infrastructure）では、SE2のライセンスで16vCPUまで利用できます。これはSE2の仕様上限にあたる規模で、承認クラウド側の8vCPUという制限がOracleのクラウドライセンスポリシーによるものであるのに対し、OCIではその上限まで使い切れるという違いによります。さらに1ライセンスあたりで利用できるvCPU数が多いため、必要なライセンス数そのものを抑えられます。大量のSE2ライセンスや高額なEEライセンスを保有している企業ほど、この差は大きく効いてきます。

そこで有力になるのが、Windows サーバーは Azure に、OracleデータベースはOCIに配置するという組み合わせです。両者の間は Oracle Interconnect for Azure で接続でき、往復のレイテンシは約2ミリ秒。クラウド間のデータ移動に追加料金もかかりません。アプリケーションは Azure、データベースはOCIという分割配置が、現実的な選択肢になります。

大容量ファイルサーバーには階層管理できるストレージ

数十から数百テラバイト規模のファイルサーバーも、クラウド移行では悩みどころです。容量が大きいぶん、そのまま高速なストレージに置けば費用がふくらみます。
ここで手がかりになるのが、ファイルのアクセス日時の分析です。ＪＢＣＣが実際に調査した事例では、総容量の約6割が3年以上アクセスされていませんでした。Microsoft も、使われていないデータが全ストレージ容量の半分以上を占める可能性があると説明しています。つまり、すべてのデータに高い性能は必要ないということです。
そこで有効なのが、階層管理に対応したストレージサービスです。アクセス頻度の高いデータは高速なプライマリ層に、頻度の低いデータは安価なキャパシティ層に自動で移動させることで、拡張性を保ちながら費用を抑えられます。Amazon FSx for NetApp ONTAPやAzure NetApp Files が、この階層管理に対応しています。
大容量のファイルサーバーをどこに置くかは、こうした機能の有無で決まります。ここでも、クラウドの総合力ではなく個別の要件が配置を決めているわけです。

IP変更不可・老朽OSにはVMwareベアメタルの一時活用

IPアドレスを変更できない、あるいはOSが古くIaaSでは動かせない。そうしたサーバーに有効なのが、クラウド上でVMware環境をそのまま利用できるベアメタルサービス（ Azure VMware Solution など）です。
最大の利点は、基盤のアーキテクチャがオンプレミスと変わらないことにあります。ネットワークを延伸する機能を使えば、仮想マシンのIPアドレスを維持したまま移行でき、IP変更に伴うアプリケーション改修やダウンタイムを回避できます。技術的な制約やソフトウェアの制約を、まとめて緩和してくれる存在です。
ただし、ＪＢＣＣではベアメタルを恒久的に使い続けることは推奨していません。災害対策のために同じ環境をもう一式用意する必要が生じたり、大きな1つの塊であるがゆえに部門ごとの利用状況が見えにくく、費用配賦が難しかったりするためです。
位置づけとしては、あくまで移行時の制約を解消するための一時的な受け皿。まずベアメタルで移行を実現し、その後で段階的にIaaSやPaaSへ移していく。この二段構えが現実的な進め方といえるでしょう。

ここまで説明してきた設計手順が、実際にどう機能するのか。大手食品製造業における約290台のクラウド移行の実例で確かめてみましょう。複数社が競った提案のなかで決め手となったのは、単一クラウドへの集約ではなく、制約起点の組み合わせ構成でした。

前提条件と評価の経緯

対象となったのは、VMware環境で稼働する約290台の仮想マシン。Windows サーバーの比率が高く、Oracleデータベースも利用しているという、これまで見てきた制約が一通り揃った環境です。
複数のベンダーが参加した比較検討では、多くがAWSへの単一クラウド移行を提案しました。そのなかでＪＢＣＣが提示したのが、複数のクラウドを評価したうえでの組み合わせ構成です。採用の理由として挙げられたのは、マルチベンダー評価にもとづく最適なクラウド提案と、移行コンサルテーションからクラウド設計までの実績でした。

採用された構成： Azure（IaaS＋ベアメタル）＋AWS（FSx）

実際に採用された構成は、次のような組み合わせです。
Windows サーバーが主体であることから、土台は Azure に置きました。IPアドレスを変更できないサーバーや、IaaSへの移行が難しいサーバーは、Azure 上のベアメタル（AVS）に集約して移行制約をクリアしています。そして大容量のファイルサーバーについては、検討当時に階層管理機能を備えていたAWSのFSx for NetApp ONTAPを採用しました。
なお現在は、Azure NetApp Files も階層管理に対応しています。移行先の選定にあたっては、検討時点での機能提供状況を必ず確認することが大切です。マルチクラウドにすること自体が正解なのではなく、そのときの要件と機能を突き合わせた結果として構成が決まる、ということでもあります。

OCIを見送った判断：制約が構成を決めるということ

この事例で示唆に富むのは、OCIを採用しなかった判断です。
この企業はOracleのEEとSE2の両方のライセンスを保有していたため、ライセンスコストの観点からはOCIの併用が有力な候補でした。ところが実際に検討を進めると、技術的な制約からOCIへは移行できないことが判明します。結果として、Oracleサーバーも Azure へ着地させる構成になりました。
一般論として有利な選択肢が、自社の制約のもとでは選べない。この事実こそ、本記事の結論を端的に表しています。構成を決めるのは「どのクラウドが優れているか」ではなく「自社の制約が何を許すか」なのです。だからこそ、比較表を眺める前に制約の棚卸しから始める必要があります。

マルチクラウドの構成は、組み上げて終わりではありません。オンプレミスが「構築して納める」ものだったのに対し、クラウドは「使い続ける」ことが前提になります。この違いを踏まえた定着化のポイントを、コストとセキュリティの2つの観点から整理します。

コストマネジメントの継続（FinOps）

使った分だけ課金されるという特性は、裏を返せば、使い方を見直し続けなければコストが下がらないということでもあります。移行時に適正化したサイジングも、時間が経てば実態とずれていきます。
そこで必要になるのが、利用状況の可視化と定期的な見直しを組み込んだ運用です。あわせて、部門ごとの利用ルールをガイドラインとして定め、統制をかけておくことも欠かせません。削減したコストをセキュリティ強化やAI活用といった次の投資に回していく。その原資を生み出す取り組みと考えると、位置づけが明確になります。

セキュリティ態勢管理（CSPM）と効率的な脆弱性対応

クラウド移行後に多くの企業が不安を抱くのが、セキュリティです。とはいえ数百台規模の環境で、すべてのサーバーに即座にパッチを適用するのは現実的ではありません。
有効なのは、優先順位をつけて対応する考え方です。CSPM（クラウドセキュリティ態勢管理）のツールには、攻撃者がどの経路をたどって機密データに到達し得るかを分析する機能があります。この攻撃パス分析を使えば、経路上にある脆弱性を特定し、リスクの高いものから優先的に対処できます。
すべてに一律で対応するのではなく、リスクの高いところから確実に潰していく。クラウドだからこそ取れる、効率的なアプローチです。

最後に、マルチクラウド構成を検討する際によく挙がる疑問にお答えします。

Q. マルチクラウドにすると運用は複雑になりませんか？

管理する対象が増えるという意味では、複雑になるのは事実です。ただし、その複雑さはマネージドサービスの活用や、マルチクラウドに対応した運用サービスの利用によって軽減できます。判断の際は、複雑さによる負荷と、組み合わせによって得られるメリットを天秤にかけて考えるとよいでしょう。

Q. 小規模な環境でもマルチクラウド構成にすべきですか？

制約が少ない環境であれば、シングルクラウドのほうが合理的な場合が多いといえます。マルチクラウドは目的ではなく、制約を解いた結果として選ばれるものです。台数や規模にかかわらず、まずは制約の棚卸しから始めることをおすすめします。

Q. 現在VMwareを使っています。まず何を確認すべきですか？

確認しておきたいのは、Windows サーバーの比率、Oracleなど個別ライセンスを持つ製品の有無、IPアドレスを変更できないシステムの有無、そしてファイルサーバーの容量です。この4点がわかるだけで、移行先の候補と想定される構成はかなり絞り込めます。逆にここが曖昧なままでは、どのクラウドが適しているかを判断する材料が揃いません。

Q. 何から始めればよいですか？

最初の一歩は、現状のアセスメントです。オンプレミスの投資額とクラウドの費用感を比較する移行の簡易診断から始まり、制約の整理、移行プランの検討、非機能要件の定義、アーキテクチャの策定という段階を踏むことで、網羅的かつ安全に検討を進められます。ＪＢＣＣでは、これらを支援するクラウド移行コンサルテーションサービスを提供しています。

マルチクラウドの構成は、クラウド同士の製品比較ではなく、自社の制約から構造的に決まります。ソフトウェアライセンス、非機能要件、ネットワーク構成、物理デバイス、クラウド技術、そして社内のセキュリティポリシー。この6つの領域を棚卸しし、土台となるクラウドを決めたうえで、残る制約に個別解を組み合わせていく。約290台の移行事例でも、この手順が決め手となりました。
マルチクラウドは、はじめから目指すゴールではありません。制約を1つずつ解いた先に現れる、最適配置の結果です。削減できたコストをセキュリティやAIといった新しい価値への投資に回すためにも、まずは自社の制約を洗い出すところから始めてみてください。

本記事で紹介した内容について、さらに詳しく知りたい方は、以下の関連コンテンツもぜひご活用ください。

毎週開催「クラウド相談会」

お客様に最適なクラウドサービスを提案

企業のITインフラや業務アプリケーションの最適化を目的とした無料の相談会です。経験豊富な担当者が、クラウド移行の導入から運用まで、最適な解決策を提案します。

クラウド相談会に申し込む

見逃し配信中

Azure と Microsoft 365 で実現するモダナイゼーション

本記事でご紹介のセミナーを見逃し配信中です。マルチクラウドでの最適配置によりコスト最小化を実現した事例をはじめ、セキュリティを考慮した安全なクラウド移行のポイントや Microsoft 365 の利活用やAIへの取り組みをご紹介します。

視聴を申し込む

登壇者プロフィール：

長岡 賢陽（ながおか けんよう）

ＪＢＣＣ株式会社
ソリューション事業 ハイブリッドクラウド事業部
テクニカル推進本部 本部長 ／ Technical Director

入社以来、ITインフラの構築や、VMwareをはじめとする仮想化環境の設計・移行に従事。
現在は、AWS や Microsoft Azure をはじめとするマルチクラウド環境の提案・技術支援を担当。特に、大規模なクラウド移行や、クラウドとオンプレミスを組み合わせたハイブリッド環境の構築など、難易度の高い案件を数多く手掛け、ＪＢＣＣグループを代表するクラウドアーキテクトとして最前線で活動してします。
インフラコストの最適化や移行後の運用改善まで幅広く携わるほか、社内外のセミナーや技術イベントにも登壇。お客様事例を交えながら、クラウド移行を成功に導くためのポイントを発信しています。