Azure SQL Database の作成手順まとめ
Azure でデータベースを作ってみたいけど「どこから始めればいいの？」と思ったことはありませんか？
この記事では、初めての方でも迷わず進められる SQL Database 作成の流れを分かりやすく解説します。
SQL データベースの作成
まずはポータルから「SQL データベース」を作成します。
Azure のサービス一覧から選ぶだけなので、迷うことはないでしょう。
無料オファーを適用する
Azure SQL Database には 無料枠 があります。これがとても嬉しいポイントです。
- 毎月 100,000 vCore 秒
- 32GB データ
- 32GB バックアップ
が無料で利用可能です。学習・検証ならこれで十分ですし、お財布にも優しいですね。
データベース名の考え方
Azure のリソース命名規則に従い、システムや用途に応じて分かりやすい名前を付けるのがポイントです。
後から「あれ、これ何のデータベースだっけ？」とならないよう、しっかり考えておきましょう。
-
候補1（プロジェクト名ベース）
project-sql-db
→ プロジェクト全体を代表する名前でシンプルに。 -
候補2（用途ベース）
video-meta-db
→ 「動画生成のメタ情報を扱うデータベース」といった用途を明確化。 -
候補3（環境ごと）
-
app-sql-db-dev（開発用） -
app-sql-db-prod（本番用）
→ 環境ごとに分けて運用したい場合。本番と開発を間違えないよう注意です。
-
ストレージとデータベースの違い
Azure では「ストレージ（Blob などのオブジェクトストレージ）」と「データベース（SQL Database）」の役割が異なります。
これ、最初は混乱しがちなポイントです。
| 項目 | ストレージ（例: Blob Storage） | データベース（例: Azure SQL Database） |
|---|---|---|
| 保存方法 | オブジェクト単位（ファイルやバイナリをそのまま保存） | テーブル・行・列の構造化データとして保存 |
| データ構造 | 非構造・半構造データ（画像、動画、CSV、JSON など） | 構造化データ（スキーマに従った表形式） |
| 検索方法 | ファイル名やメタデータ検索が中心 | SQL クエリで複雑な検索・集計が可能 |
| 複数利用 | 同時利用は可能だが整合性制御はアプリ側 | トランザクション制御で整合性を保証 |
| 信頼性 | 冗長化・バックアップでファイルを保護 | 冗長化 + トランザクションログ + バックアップで保護 |
| 拡張性 | ペタバイト級まで保存可能 | 数TB〜100TB級まで拡張可能（プラン依存） |
ストレージは 「そのままデータを置く箱」、
データベースは 「整理して検索・分析しやすくする仕組み」 と考えると分かりやすいですね。
サーバーを作成する必要性
SQL Database は必ず「論理サーバー」にぶら下げて作成します。
これは Azure の仕組み上、避けて通れないステップです。
認証方式は以下から選択できます：
-
SQL 認証（ユーザー名+パスワード）
→ 開発・検証用途にシンプルで便利。慣れ親しんだ方式ですね。 -
Microsoft Entra 認証（旧 Azure AD）
→ 本番環境ではこちらを推奨（組織IDと統合できる）。セキュリティ面でより安心です。
ネットワークの設定
1. Azure サービスおよびリソースへのアクセス
- はい → 同じ Azure 環境内（Functions, Power BI など）から接続可能
- いいえ → 不要なアクセスを防ぐ。セキュリティ重視なら本番はこれがおすすめ。
2. 現在のクライアント IP アドレスを追加
- はい → 今のPCからのアクセスを許可（自分のグローバルIPを自動登録）
- いいえ → アプリ経由のみで接続したい場合
グローバルIPとは？
ネットワークに1つ割り当てられる「インターネット上の住所」のことです。
家庭用回線では動的（時々変わる）、法人回線では固定が多いです。自宅で作業する場合は、たまにIPが変わって接続できなくなることがあるので覚えておくと良いでしょう。
接続方式について
「既定」を選ぶと、接続元によって自動的に方式を切り替えます。
Azure が賢く判断してくれるので、基本的にはこれで問題ありません。
Azure 内部からの接続
- 例: Azure VM, Functions, App Service
-
リダイレクト方式
- DBノードに直接接続
- 最短経路で高速。まさに直通ルートですね。
Azure 外部からの接続
- 例: 自分のPC（インターネット経由）
-
プロキシ方式
- まず Azure SQL Gateway に接続してからDBへ転送
- 少し遅延するが 1433ポートのみ で接続できるため簡単
プロキシとは何か？
プロキシは「仲介役」のサーバーです。
郵便局のようなイメージでしょうか。
-
役割
- クライアントは常に固定の入口（
xxx.database.windows.net:1433）に接続できる - 実際のDBノードがどこに移動しても、ゲートウェイが正しい場所に転送
- ファイアウォール設定がシンプルになる
- クライアントは常に固定の入口（
-
メリット
- 外部からでも安定して接続できる
- ポート1433だけ開ければ良い（ネットワーク設定が楽）
-
デメリット
- 直接接続より少し遅延する（とはいえ、体感で分かるほどではありません）
セキュリティ
開発用であればデフォルトのままで良いと思いますが、
下記のような設定をすることができます。知っておくと役立つ場面があるでしょう。
1. Microsoft Defender for SQL
- 有料オプション（$15/月/サーバー）、30日間無料試用あり
- 機能：脆弱性評価、不審アクセス検知（ATP）
- 開発: 無効でOK / 本番: 有効化推奨
2. 台帳（Ledger）
- データ改ざん検知（トランザクション履歴を暗号化して保存）
- 主に金融・監査向けの機能です
- 開発では不要 / 必要時のみ有効化
3. サーバーID（Managed Identity）
- SQL サーバーにマネージドIDを割り当て、他Azureサービスと安全連携
- 例: Key Vaultから鍵を取得する場合
- デフォルト無効 / 必要時に有効化
4. 暗号化
Transparent Data Encryption (TDE)
- データベース全体を保存時に自動暗号化
- デフォルト有効 / 鍵はAzure管理 or Key Vault管理
Always Encrypted
- 特定列をアプリ側で暗号化
- 管理者でも中身を閲覧不可（かなり強力な仕組みです）
- 個人情報や機微データに利用
追加設定
データベースの細かいルールについてです。
初期の段階ではデフォルトのままで良いと思います。あとから変更もできるので、まずは動かすことを優先しましょう。
