Azure SQL Databaseとは？仕組み・購入モデル（vCore／DTU）・サービス階層とSQL Server／Managed Instanceとの違いを実装者目線で解説

Azure SQL DatabaseはMicrosoft AzureのフルマネージドなPaaS（Platform as a Service）リレーショナルデータベースで、OSのパッチ適用・バックアップ・高可用性の構成をプラットフォーム側が引き受けます。実装で最初に押さえるべきは、vCoreベースとDTUベースという2つの購入モデル、General Purpose・Business Critical・Hyperscaleというサービス階層、そしてプロビジョニング済みとサーバーレスのコンピューティング階層の関係です。この記事では定義から、階層選択が料金と性能をどう左右するか、組み込みの可用性・バックアップ・セキュリティ、SQL Server本体やAzure SQL Managed Instance・SQL Server on Azure VMとの違い、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年時点の公式ドキュメントに基づいて整理します。

まとめ：Azure SQL Databaseの要点と採用判断の分岐

Azure SQL Databaseは、常に最新の安定版SQL Databaseエンジンと修正済みOSの上で動くDBaaS（Database as a Service）です。インフラの保守はMicrosoftが担い、実装者はスキーマ設計とクエリ、そして階層選択に集中できます。動く土台は購入モデル（vCore／DTU）とサービス階層の組み合わせで、この選択が料金・性能・使える機能を同時に決めるのが要点です。2026年時点ではvCoreベースが推奨で、なかでもHyperscaleが最大128TBまで伸ばせる標準的な選択肢に位置づけられています。

採用が合理的なのは、新規のクラウドアプリやSaaSで、単一の信頼できるリレーショナルデータソースをサーバー管理なしで持ちたい場合です。逆に、既存のSQL Serverをそのまま移したいならほぼ完全互換のManaged Instance、OSやSQL Server Agentまで自分で握るならSQL Server on Azure VM、非構造データやベクトル検索が中心ならCosmos DBが向きます。自社システムでどのデータベース基盤を組むべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。

Azure SQL Databaseの定義とフルマネージドPaaSとしての仕組み

Azure SQL Databaseを理解する起点は、「データベースエンジンだけをサービスとして借りる」という発想です。サーバーやOSは表に出てこず、実装者が触れるのはデータベースとその設定に限られます。

常に最新のSQLエンジンで動くフルマネージドDBaaSの立ち位置

Azure SQL Databaseは、SQL Databaseエンジンの最新安定版とパッチ適用済みOSの上で動きます。SQL Serverの新機能は多くの場合まずAzure SQL Databaseに投入され、その後オンプレミス版へ展開されます。修正プログラムの適用やアップグレード、バックアップ、フェールオーバーはMicrosoftが自動で処理するため、実装者は基盤インフラを管理しません。無料枠では毎月10万vCore秒のサーバーレスコンピューティングと32GBのストレージを試せます（2026年時点）。

マルチモデル対応と組み込みインテリジェンスによる運用負荷の軽減

Azure SQL Databaseはマルチモデルデータベースで、リレーショナルデータに加えてベクトル・グラフ・JSON・XML・空間・キーと値のペアを1つのエンジンで扱えます。運用面では自動チューニング（不足・重複インデックスの自動管理、問題プランの自動修正）、クエリストアによるクエリ性能の記録、アダプティブクエリ処理といった機能が標準です。自動チューニングは適用前後の性能を比較し、改善しなければ変更を元に戻す仕組みで、夜間の性能劣化のリスクを下げます。

単一データベースとエラスティックプールという2つのデプロイモデル

デプロイの選択肢は2つです。単一データベースは、専用のコンピューティング・メモリ・ストレージを持つ分離されたデータベースで、1つの信頼できるデータソースが要る新規アプリやマイクロサービスに向きます。エラスティックプールは、複数のデータベースがCPU・メモリの共有セットを使う方式で、使用パターンが読みにくい多数のデータベースをまとめてコストを予測可能にする方式です。SaaSでテナントごとにデータベースを分ける設計では、プールに出し入れしながら数個から数千まで伸ばせます。

vCore・DTUの購入モデルと3つのサービス階層の選び分けの基準

費用と使える機能は、購入モデルとサービス階層の選択でほぼ決まります。ここを設計段階で取り違えると、動いてから性能不足やコスト超過に直面します。

vCoreベース（推奨）とDTUベースという購入モデルの違い

vCoreベースは、仮想コア数・メモリ量・ストレージ容量と速度を個別に選ぶモデルで、コンピューティングとストレージを分けて考えられます。Azureハイブリッド特典を使えば、保有するSQL Serverライセンスを割り当ててHyperscale以外のデータベースの単価を下げられます。DTUベースは、コンピューティング・メモリ・I/Oをひとまとめにした「DTU」という単位で3階層（Basic／Standard／Premium）から選ぶ簡易な方式です。新規設計ではリソースを個別に制御できるvCoreベースが推奨で、DTUは小規模で見積もりを単純にしたい場合の選択肢になります。

General Purposeなど3つのサービス階層の役割と選び分け

vCoreベースのサービス階層は用途で次のように分かれます。

General Purpose は計算層とストレージ層を分離したバランス型で、まず小さく始める用途に向きます。Business Critical はローカルSSDと複数の分離レプリカを持ち、トランザクションレートが高く低遅延I/Oが要るOLTP（オンライントランザクション処理）の仕組みを解説した記事で扱うような業務に向きます。Hyperscale は計算とストレージを独立してスケールし、最大128TB・最大30の読み取り専用名前付きレプリカ・任意リージョンへの読み取りgeoレプリカを備え、SQLライセンス料が別建てにならない点も含めて2026年時点の推奨階層です。

プロビジョニング済みとサーバーレスというコンピューティング階層の課金差

vCoreベースにはコンピューティング階層が2つあります。プロビジョニング済みは、負荷に関係なく一定量の計算リソースを確保し、1時間あたりの固定価格で課金する方式です。サーバーレスは、ワークロードに応じて計算リソースを自動スケールし、1秒あたりの使用量で課金します。一定時間アクセスが無いと自動的に一時停止し、その間は計算課金が止まってストレージ分だけになるため、断続的にしか使わない開発・検証環境や負荷の谷が深いアプリで費用を圧縮できます。サーバーレスは General Purpose と Hyperscale で利用できます（2026年時点）。

組み込みで提供される可用性・バックアップ・セキュリティの機能

Azure SQL Databaseを実装で選ぶ決め手は、事業継続とセキュリティの機能が最初から組み込まれている点です。ここがオンプレミス運用との差になります。

組み込み高可用性とゾーン冗長・geoレプリケーションによる耐障害性

可用性の仕組みは階層で変わります。General Purpose は計算層とストレージ層を分離することで標準的な可用性を得るのに対し、Business Critical や Premium は計算とストレージを同一ノードに統合し、Always On 可用性グループに相当する技術で冗長レプリカを保つ構成です。さらに Premium／Business Critical のデータベースは複数の可用性ゾーンにレプリカを分散するゾーン冗長を構成でき、データセンター規模の障害からデータ損失なしで自動復旧します。リージョン全体の停止に備えるのがアクティブgeoレプリケーションの役割です。

自動バックアップとポイントインタイムリストアによるデータ保護

バックアップは自動です。フル・差分・トランザクションログの各バックアップが自動取得され、保持期間内の任意の時点への復旧（ポイントインタイムリストア）が全デプロイオプションで使えます。長期保持を構成すれば、フルバックアップをAzure Storageに保存する運用も可能です。バックアップに直接アクセスするインターフェースは無く、保持期間を過ぎると自動削除される仕様のため、復旧要件（RPO／RTO）は保持期間とgeoレプリケーションの設計で担保します。リージョンをまたぐ冗長にはフェールオーバーグループを使い、監視と切替のオーケストレーションはプラットフォームに委ねられます。

TDEとMicrosoft Defender for SQLによる多層防御の仕組み

暗号化は3つの状態を押さえます。転送中はTLS、保存時はTransparent Data Encryption（TDE）、使用中はAlways Encryptedです。認証はMicrosoft Entra ID統合で一元管理し、多要素認証とシングルサインオンに対応します。脅威対策はMicrosoft Defender for SQLがまとめて担い、脆弱性評価と異常検知（SQLインジェクションや異常なアクセスパターンの通知）を提供します。監査ログ、データの検出と分類も組み込みです。トランザクションの競合設計を誤るとデッドロックの原因と検出・予防を解説した記事で扱うような問題が本番で顕在化するため、分離レベルとロック順序の設計はアプリ側で詰めておきます。

SQL Server・Managed Instance・VM実行との違い

Azure SQLは単一のサービスではなく、管理度と互換性の異なる複数の選択肢を束ねたファミリです。ここを取り違えると移行方針ごと破綻します。

3つの選択肢を管理モデルと互換性の範囲で切り分けるための判断軸

同じSQL系でも、管理境界と互換性が段階的に異なります。

Azure SQL Database はデータベース単位のPaaSで、管理負荷が最も小さい代わりにインスタンス全体を前提とする一部機能（SQL Server Agent、データベース間クエリ、CLR等）は形を変えて提供されます。Managed Instance はインスタンス単位のPaaSでSQL Serverにほぼ完全互換のため、既存資産をなるべく書き換えずに移すリフト&シフトに向きます。SQL Server on Azure VM はIaaSでOSまで自分で握れる代わりに、パッチやバックアップの運用も自分の責任です（基盤となるAzure Virtual Machinesの仕組みと料金を解説した記事もあわせて参照できます）。管理を任せたい順にDatabase→Managed Instance→VMと並べて捉えると選定しやすくなります。

リレーショナルとNoSQL（Cosmos DB）で守備範囲が分かれる

データモデルが構造化トランザクションでなく、グローバル分散や非構造データ・ベクトル検索が中心なら、そもそもリレーショナルが常に正解とは限りません。柔軟なスキーマや低遅延の分散書き込みが要る場合はAzure Cosmos DB for NoSQLのベクトル検索を解説した記事で扱うNoSQL側が候補になります。強い整合性を持つトランザクション、JOINを多用する集計、既存のT-SQL資産があるならAzure SQL Databaseが適します。両者は競合ではなく、システム内で役割ごとに使い分ける対象です。

Azure SQL Databaseを採用すべき場面と見送る場面

ここからは判断です。Azure SQL Databaseは万能のデータベース基盤ではなく、向く要件と向かない要件がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。

Azure SQL Databaseの採用が第一候補になるケースの条件

次のいずれかに該当するなら、Azure SQL Databaseが第一候補になります。

• 新規のクラウドアプリやSaaSで、単一の信頼できるリレーショナルデータソースをサーバー管理なしで持ちたい
• バックアップ・PITR・自動チューニング・脅威検知をプラットフォーム標準で手早くそろえたい
• 負荷の谷が深い、または断続利用のワークロードを、サーバーレスの秒課金と自動一時停止で安く回したい
• 128TB級までの成長余地を、計算とストレージを独立スケールできるHyperscaleで確保したい

いずれもマネージド運用と柔軟なスケールが効く領域です。特に初期はサーバーレスの General Purpose で試作し、本番で必要な階層へ引き上げる段階的な進め方が、実装のハードルを下げます。

Azure SQL Databaseを選ぶべきでない場面と代替の選択

一方で、次の要件にはAzure SQL Databaseを選びません。ここを混同すると設計が破綻します。第一に、既存SQL Serverのストアドやリンクサーバー、SQL Server Agentのジョブをそのまま動かしたいなら、DBスコープのAzure SQL DatabaseよりインスタンススコープのManaged Instanceが適した選択です。第二に、OSレベルの設定や特定バージョンの固定、サードパーティ製エージェントの常駐が要るなら、IaaSのSQL Server on VMを選びます。第三に、非構造データやグローバル分散書き込み、ベクトル検索が主役ならCosmos DBの領分です。第四に、常時高負荷でメモリ内OLTPや読み取りスケールアウトが要るなら、General Purposeではなく Business Critical や Hyperscale を選ばないと性能が頭打ちになります。

受託開発におけるクラウドデータベース基盤の設計相談と外注先選定の勘所

実際のシステムでは、Azure SQL Database単体ではなくアプリ層・認証基盤・監視・ストレージを役割ごとに組み合わせる構成が普通です。どのワークロードをどの階層に載せ、どこをゾーン冗長にし、どのバックアップ保持とgeoレプリケーションでRPO／RTOを満たすかは、負荷・可用性要件・月次コストのトレードオフで決まり、稼働後の階層変更や購入モデルの移行には相応の検証が伴います。要件定義の段階で全体設計を固めておくほど、後の作り直しを避けられる設計です。Azureを含むクラウド基盤の構築・移行の相談では、データベース方式の選定を含めた設計から実装・運用までを一貫して支援できます。

よくある質問

Azure SQL Databaseの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。

Azure SQL DatabaseとSQL Serverはどう違いますか？

提供形態が異なります。SQL Serverは自分でサーバーやOS、SQL Serverエンジンを管理するデータベース製品です。Azure SQL Databaseは、そのエンジンをフルマネージドのPaaSとして借りる形態で、パッチ適用・バックアップ・高可用性の構成をMicrosoftが自動で処理します。最新のSQL機能の多くは、まずAzure SQL Databaseに投入される流れです。ただしインスタンス全体を前提とする一部機能は、Azure SQL Databaseでは形を変えて提供されます。

Azure SQL DatabaseとManaged Instanceはどちらを選べばよいですか？

互換性の要件で分かれます。既存SQL Serverの資産（データベース間クエリ、SQL Server Agent、CLR等）をなるべく書き換えずに移したいなら、ほぼ完全互換のManaged Instanceが有力です。新規開発でデータベース単位の分離と最小の運用負荷を優先するなら、Azure SQL Databaseが適します。移行のしやすさを取るか、管理の軽さを取るかで判断します。

vCoreベースとDTUベースはどちらがよいですか？

新規設計ではvCoreベースが推奨です。仮想コア・メモリ・ストレージを個別に制御でき、Azureハイブリッド特典でSQL Serverライセンスの割引も受けられます。DTUベースは、リソースをひとまとめの単位で選ぶ簡易な方式で、小規模で見積もりを単純にしたい場合の選択肢です。将来の拡張やHyperscaleへの移行を見込むならvCoreベースから始めると移行が滑らかです。

サーバーレスはどんなときに使いますか？

負荷が断続的で谷が深いワークロードに向いた方式です。アクセスが無い間は自動的に一時停止して計算課金が止まり、ストレージ分だけの費用になるため、開発・検証環境や利用時間が限られるアプリでコストを圧縮できます。常時一定以上の負荷がかかる本番では、プロビジョニング済みのほうが単価が読みやすく安定した選択です。サーバーレスはGeneral PurposeとHyperscaleで利用できます。

Hyperscaleは大規模でなくても使えますか？

使えます。Hyperscaleは最大128TBまで伸ばせますが、小さく始めて必要に応じて拡張でき、計算とストレージを独立してスケールできる柔軟性から、2026年時点では大半の業務ワークロードの推奨階層です。高速なバックアップと復元、読み取りレプリカによる分析ワークロードのオフロードが要るなら、規模が中程度でも候補になります。

関連記事

• OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説【2026年版】：Business Criticalが対象とするトランザクション処理ワークロードの性質を押さえられます。
• デッドロックとは？原因・具体例・検出と解消・予防策｜トランザクションとロック：リレーショナルDBの競合設計で避けるべき問題と対策を確認できます。
• Azure CosmosDB for NoSQLにおけるベクトル検索の特徴：非リレーショナル側の対応物として、データモデルの使い分けを読み比べられます。