【Azureサービス（機能）一覧】カテゴリ別に全体像と“選び方”がわかるまとめ

更新日：2025年12月15日※Azureはサービス追加・名称変更が頻繁です。本記事は「情シスが設計・運用・統制で迷わないための地図」として、代表サービスをカテゴリ別に整理しています。最新の提供状況やリージョン対応は、Microsoft公式の製品一覧（A-Z）で最終確認してください。

────────────────────────────目次

1. 情シスがAzureで最初に詰まるポイント（先に言語化）

2. Azureを“情シス視点”で見るための地図（カテゴリと責任分界）

3. Compute（計算資源：VM/PaaS/サーバレス）

4. Containers（AKS/Container Apps/ACR）

5. Web / API（公開・配信・API統制）

6. Storage（ストレージ：置き場と統制）

7. Databases（DB：マネージド化と責任）

8. Networking（ネットワーク：閉域・境界・公開）

9. Identity（Entra ID：ゼロトラストの本丸）

10. Security（防御・検知・鍵管理）

11. Management & Governance（監視・ログ・ポリシー・コスト）

12. Integration（連携：キュー・イベント・ワークフロー）

13. Analytics（分析：データ基盤）

14. AI / Machine Learning（AI活用：情シスが見るべき論点）

15. Hybrid / Migration（移行・ハイブリッド）

16. 情シス向け「導入の順番」おすすめロードマップ

17. ありがちな事故パターン（運用・監査で炎上しやすい）

18. チェックリスト（社内説明・監査・委託まで含む）

19. まとめ：この記事の更新方法

    ────────────────────────────

1. 情シスがAzureで最初に詰まるポイント（先に言語化）

Azureを導入するとき、技術的にPoCが通っても、情シスは次で詰まりやすいです。

・「テナント／サブスク／ネットワーク」の初期設計が曖昧で、後から統制できない・権限（RBAC）が増え続け、退職・異動・委託先変更で剥奪漏れが起きる・ログを集めすぎてコストが爆発、または必要な証跡が短期間で消えて監査で詰む・Key Vault（Secrets/Keys/Certificates）が増殖し、期限切れで本番停止する・Private Endpointや閉域化を進めた結果、DNSや運用が複雑化して障害対応が遅れる・「Microsoft／SIer／MSP／自社」の責任分界が曖昧で、事故後に説明が割れる

本記事は、上の“詰まり”を避けるために、Azureの機能を「情シスが使える整理」に落とします。

2. Azureを“情シス視点”で見るための地図（カテゴリと責任分界）

情シス向けにAzureを理解するコツは、次の2軸です。

（A）カテゴリ地図：何の領域のサービスか（Compute/Network/Security…）（B）責任分界：IaaS/PaaS/サーバレスで「自社が運用する範囲」が変わる

ざっくり言うと、・IaaS（VM中心）＝自由度は高いが、OS運用・バックアップ・監視など自社責任が増える・PaaS（App Service/DB PaaSなど）＝運用負荷は下がるが、設計と統制（ログ・権限・ネットワーク）が重要・サーバレス（Functionsなど）＝拡張性は高いが、運用ルールを作らないと事故が起きやすい

以下、カテゴリ別に「代表サービス」と「情シスが見るべき論点」を書いていきます。

3. Compute（計算資源：VM/PaaS/サーバレス）

Computeは「どこでアプリや処理を動かすか」です。情シス的には“運用負荷”が最も効くカテゴリです。

代表サービス・Virtual Machines（VM）　- 既存サーバ移行（Lift & Shift）や自由度重視　- 注意：OSパッチ、脆弱性対応、バックアップ、監視、構成管理が自社側に寄る

・VM Scale Sets　- VMを台数増減してスケールアウト

・App Service　- Webアプリ/APIをPaaSで運用（OS運用が軽くなる）　- 注意：ネットワーク閉域化、証明書、スロット運用、ログ保持の設計で詰まりがち

・Azure Functions　- イベント駆動（Webhook、バッチ、軽量API）　- 注意：接続先（DBなど）、実行時間、監視、例外時の運用手順を作らないと事故る

・Azure Batch / HPC系　- 並列ジョブ・大量計算用途

情シスの選び方（超短縮）・運用を減らしたい → App Service / Functions・互換性と自由度 → VM・コンテナ前提 → 次章へ

4. Containers（AKS/Container Apps/ACR）

コンテナは「移植性」と「スケール」の中心。情シスは“統制の難易度”も一緒に見る必要があります。

代表サービス・AKS（Azure Kubernetes Service）　- Kubernetesのマネージド　- 注意：権限（クラスタ管理/namespace管理）、ネットワーク、監視、秘密情報管理が複雑

・Container Apps　- Kubernetesを意識せずサーバレス寄りでコンテナ運用　- 「運用負荷を下げたいがコンテナは使いたい」に刺さる

・Container Instances　- 単発・短時間コンテナ実行

・Container Registry（ACR）　- イメージ保管庫（CI/CDの前提）　- 注意：脆弱性スキャン、アクセス制御、署名（サプライチェーン）をどうするか

5. Web / API（公開・配信・API統制）

ユーザーに触れる入口。公開系は事故時の影響が大きいので、情シスは“防御と証跡”までセットで考えます。

代表サービス・Application Gateway（L7ロードバランサ）　- WAFと組み合わせることが多い

・Front Door / CDN系　- グローバル配信、ルーティング最適化、WAF連携

・API Management（APIM）　- API公開の統制（認証、レート制限、バージョン管理、ログ）　- “社内API・取引先API”が増えるほど価値が出る

・Static Web Apps　- 静的サイト＋APIの構成を簡単に

情シス観点のチェック・WAFをどこに置くか（入口統制の一貫性）・証明書更新（期限切れ事故）・API鍵やトークンの管理（Key Vaultと連動）・アクセスログの保持（監査・事故調査で出せるか）

6. Storage（ストレージ：置き場と統制）

ストレージは「置いた瞬間から統制課題が始まる」領域です。用途ごとに置き場を分けると運用が安定します。

代表サービス・Storage Account（基盤）　- Blob：ログ、バックアップ、画像など　- Files：ファイル共有　- Queue：軽量メッセージ　- Table：簡易NoSQL

・Managed Disks（VMディスク）・Data Lake系（分析向けの置き場）・Archive（長期保管）

情シスが必ず見るポイント・アクセス制御（RBAC、共有キー運用の排除、Managed Identity化）・暗号化と鍵管理（Key Vault連携／顧客管理鍵の要否）・ネットワーク閉域化（Private Endpoint）・ログ保持（監査要件があると年単位になることがある）・データ削除・保全（トラブル時に消さない／消せない状態をどう作るか）

7. Databases（DB：マネージド化と責任）

DBは「可用性・バックアップ・復旧」が本番で効きます。情シスは“止まった時に誰が復旧するか”まで設計に入れます。

代表サービス・Azure SQL Database（PaaS）　- 運用負荷を下げたい場合の定番

・SQL Managed Instance　- 互換性とPaaSのバランス

・SQL Server on Azure VMs　- 互換性最優先だが運用負荷は上がる

・Cosmos DB（グローバル分散NoSQL）・PostgreSQL / MySQL マネージド・Azure Cache for Redis（性能対策）

情シスが詰まりやすいポイント・バックアップは「取る」ではなく「復旧できる」ことが重要（復旧手順・責任者・訓練）・DR（別リージョン）をどこまで求めるか（BCP/SLAと接続）・監査ログ（操作・設定変更）の保持期間

8. Networking（ネットワーク：閉域・境界・公開）

ネットワークはクラウドの“設計負債”になりやすいです。最初に標準構成（型）を作ると後が楽です。

代表サービス・Virtual Network（VNet）／Subnets・NSG（セグメント分離の基本）・Route Table（経路制御）・VPN Gateway / ExpressRoute（拠点接続）・Azure Bastion（踏み台）・Load Balancer（L4）・Application Gateway（L7）・Azure Firewall（境界統制）・DDoS Protection・Private Link / Private Endpoint（PaaSの閉域化）・DNS（名前解決）

情シスが詰まりやすいポイント（重要）・閉域化（Private Endpoint）は“できる”が、DNSと運用が難しくなる・インターネット出口（NATやFirewall）を統一しないと、証跡と統制が崩れる・ネットワーク変更は影響範囲が大きいので、変更管理と承認フローが必要

9. Identity（Entra ID：ゼロトラストの本丸）

情シスが最も“監査と事故”で問われるのがID領域です。ネットワーク境界よりIDが本丸です。

代表機能・Microsoft Entra ID（SSO、MFA、条件付きアクセス）・条件付きアクセス（Conditional Access）・PIM（特権管理：必要時だけ管理者権限）・Managed Identities（秘密情報を減らす）・外部ユーザー（B2Bゲスト等）の統制

情シス観点で必ず押さえる・例外運用（VIP、海外、委託先、障害対応）の恒久化をどう防ぐか・Break-glass（緊急用）を“作る”だけでなく、規程・証跡・復旧後手順まで整える・管理者権限を常設にしない（PIM/期限付き/承認）

10. Security（防御・検知・鍵管理）

セキュリティは「設定」ではなく「運用」です。情シスは“検知→対応→証跡”まで含めて整えます。

代表サービス・Microsoft Defender for Cloud　- セキュリティ態勢管理（推奨、脆弱性、設定の可視化）

・Microsoft Sentinel（SIEM）　- ログ集約、相関、検知、インシデント管理　- 注意：ログ保持コスト、提出可能性（監査・取引先照会）、委託先SOC運用の統制

・Azure Key Vault　- Secrets／Keys／Certificatesの保管庫　- 注意：棚卸し（所有者・用途・重要度）、期限切れ、過剰権限、例外の恒久化が事故の原因

・WAF / Firewall / DDoS　- 防御は入口と出口で統一するほど運用が安定する

11. Management & Governance（監視・ログ・ポリシー・コスト）

情シス向けに最重要カテゴリ。ここが弱いと「スケールした瞬間に統制不能」になります。

代表サービス／概念・Azure Monitor（監視の土台）・Log Analytics（ログ集約）・Application Insights（アプリ観測）・Azure Automation（運用自動化）・Azure Backup（バックアップ）・Azure Site Recovery（DR）・Azure Policy（ルール強制）・Management Groups（統制単位）・Tags（棚卸しと請求配賦の基本）・Cost Management（コスト統制）・Resource Graph（横断検索）

情シスが“最初に決めると強い”こと・ログ：何を集めるか、保持期間、保全（削除停止）を決める・Policy：最低限のガードレール（リージョン、暗号化、パブリック禁止、タグ必須など）・コスト：予算・アラート・誰が責任を持つか（情シスだけで抱えない）

12. Integration（連携：キュー・イベント・ワークフロー）

連携は“障害時の切り分け”に影響します。イベント駆動はログと追跡が命です。

代表サービス・Logic Apps（ワークフロー自動化）・Service Bus（キュー／トピック）・Event Grid（イベント通知）・Event Hubs（ストリーム取り込み）・API Management（API統制）

情シス観点・どこで詰まったかを追えるログ設計（分散トレーシング／相関ID）・再送、DLQ（デッドレター）などの運用設計

13. Analytics（分析：データ基盤）

分析は「データの所在」「権限」「匿名化」「保持・保全」で監査に刺さりやすい領域です。

代表サービス・Data Factory（データ連携）・Synapse / Databricks系（分析基盤）・Stream Analytics（リアルタイム）・Data Explorer系（ログ分析に強い）

情シス観点・分析基盤に“機密が集まりやすい”前提で、権限と証跡を強める・データ持ち出し（外部SaaS）や越境が絡むと、契約と説明が必要になる

14. AI / Machine Learning（AI活用：情シスが見るべき論点）

AI/MLは技術よりも「データ」「統制」「ログ」で揉めます。

代表領域・Azure Machine Learning（学習・運用）・AIサービス（画像・音声・言語などのAPI）・生成AI（文章生成・要約・検索拡張など）

情シスが必ず見るポイント・学習データ／プロンプト／出力の取り扱い（機密・個人情報・目的外利用）・ログの保全（後から「何を入力したか」が問われるケースがある）・委託・再委託・海外SOCが絡む場合の統制（越境・提出・削除証明）

15. Hybrid / Migration（移行・ハイブリッド）

現実には「全部クラウド」は少なく、移行とハイブリッドが主戦場です。

代表サービス・Azure Arc（オンプレや他クラウドを統合管理）・Azure Migrate（移行計画・評価）・Data Box（大量データ移行）・Backup / Site Recovery（移行とBCPを接続）

16. 情シス向け「導入の順番」おすすめロードマップ

フェーズ0：基盤の型（Landing Zone）を作る・テナント／管理グループ／サブスク分割方針・ネットワーク標準（VNet、出口、DNS、閉域化方針）・IDと権限（RBAC、PIM、委託先アクセス方針）・Policy（最低限のガードレール）・ログ方針（何を、どこに、何日/何年、誰が責任者）

フェーズ1：代表ワークロードを載せる・Compute（VM/PaaS）を選定・Storage/DBを用途別に設計・監視（可観測性）とバックアップを必須セットに

フェーズ2：セキュリティ運用（SOC/CSIRT）を整える・Defender/Sentinel等の導入・インシデント手順（一次報告、保全、証跡提出）・委託先運用があるなら契約・責任分界を固める

フェーズ3：BCP/DRを現実化・Azure Backup / Site Recovery・復旧訓練（机上で終わらせない）

17. ありがちな事故パターン（運用・監査で炎上しやすい）

・Key Vaultの証明書期限切れで本番停止（所有者不明、更新手順なし）・RBACが増殖して強権限が残留（委託先変更・退職者で剥奪漏れ）・ログを集めすぎてコスト爆発、または保持が短く監査で証跡が出ない・Private Endpointを増やしすぎてDNSが破綻（障害時に切り分け不能）・委託先SOCが海外再委託しており、越境・提出・削除証明で揉める・SLAを社内で語っているが、実際の責任分界（Microsoft/ベンダー/自社）が合意されていない

18. チェックリスト（社内説明・監査・委託まで含む）

設計・運用の最低ライン（情シス向け）□ テナント／サブスク／管理グループの分割方針がある□ ネットワーク標準（公開・閉域・出口・DNS）が決まっている□ 権限方針（RBAC、PIM、委託先アクセス）が文章化されている□ Policyで最低限のガードレールが効いている□ ログ方針（収集範囲、保持期間、保全手順、提出形式）が決まっている□ Key Vaultの棚卸し（Secrets/Keys/Cert：所有者・用途・重要度・期限）ができている□ バックアップ／DR（復旧手順・訓練・責任分界）が決まっている□ インシデント対応（一次報告、証跡保全、取引先回答）が回る□ 委託先がある場合、再委託（国外含む）・提出義務・削除証明・学習利用禁止などが整理されている

19. まとめ：この記事の更新方法

・Azureのサービスは増え続けるため「完全な一覧」を記事内で維持するのは現実的ではありません・本記事は“情シスの地図”として、代表サービスと選び方・詰まりポイントを更新するのがおすすめです・更新時のチェックポイント　- セキュリティ／ID（PIM、条件付きアクセス、SIEM）の運用トレンド　- 監視ログ（保持期間・保全・コスト）の設計　- ネットワーク（閉域化の方針とDNS運用）　- BCP/DR（復旧訓練・責任分界）　- 委託先運用（越境・再委託・提出・削除証明・学習利用）