Contents
スポンサードリンク
想定読者と前提（権限・CLI・拡張）
対象読者と実行前の前提を明確にします。想定スキルと必須の権限・ツールを満たしてから手順を進めてください。CLIやAPIの移行リスクにも配慮しています。
対象読者（スキル別）
このガイドの想定読者は次の通りです。
- 初心者: Azureの基本概念は理解しているが実務はこれからの方。
- 中級者: Azureでリソース作成・運用経験があり、IaCや権限管理を学びたい方。
- 運用担当／SRE: 複数サブスクリプションやガバナンス運用を担当する方。
7日スプリント（Day1〜Day7: 手順と検証基準）
ここでは短期集中で構築→検証→本番移行準備まで進める流れを示します。各日ごとに期待される成果と検証項目を明記します。コマンドはプレースホルダを置換して利用してください。
Day1: 初期登録と課金保護
Day1 はアカウントと支払い・予算設定の初期整備を行います。
- 目的: サブスクリプションと請求監視の基礎を整える。
- 期待される成果（exit criteria）: サブスクリプションが明確で、予算アラートと通知先が設定されている。
- 検証項目: サブスクリプション選択、予算アラートがトリガー条件を保存していること。
- Portal（要点）: Cost Management > Budgets で予算を作成し、Action Group を通知先に設定する。
- CLI（前提: Billing Reader/Owner 権限）:
|
1 2 3 4 |
az login az account set --subscription "<subscription-id-or-name>" az account show --query "{name:name,id:id}" --output table |
- 予算作成例（az consumption 拡張が必要な場合あり。Billing 権限を確認）:
|
1 2 3 4 5 6 7 |
az consumption budget create \ --name "monthly-budget" \ --amount 1000 \ --time-grain Monthly \ --category Cost \ --subscription "<subscription-id>" |
プレースホルダ例: "
Day2: 基盤設計と VNet 構築
Day2 はネットワーク基盤の立ち上げと命名規則確立を行います。
- 目的: VNet、サブネット、管理系ネットワークのベースを作成する。
- 期待される成果: VNet とサブネットが作成され、管理用サブネットに NSG が適用されている。
- 検証項目: サブネット一覧、NSG ルールの適用、IP アドレス設計の非重複確認。
- CLI（前提: Contributor 権限）:
|
1 2 3 4 |
az group create -n my-rg -l japaneast az network vnet create -g my-rg -n my-vnet --address-prefixes 10.0.0.0/16 --subnet-name management --subnet-prefixes 10.0.0.0/24 az network vnet subnet create -g my-rg --vnet-name my-vnet -n app --address-prefixes 10.0.1.0/24 |
- NSG ルール例（
は CIDR 形式で指定）:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
az network nsg create -g my-rg -n nsg-management az network nsg rule create \ -g my-rg \ --nsg-name nsg-management \ -n allow-ssh \ --priority 100 \ --direction Inbound \ --access Allow \ --protocol Tcp \ --source-address-prefixes 203.0.113.4/32 \ --destination-port-ranges 22 |
プレースホルダ例: 1IP の場合は "/32"（例: 203.0.113.4/32）。社内ネットワーク全体を許可する場合は CIDR 範囲（例: 203.0.113.0/24）を用いること。アクセスは最小許可にしてください。
- 管理アクセス: Azure Bastion はターゲット VM にパブリック IP を割り当てずに、ブラウザまたは Azure ポータル経由で RDP/SSH 接続を提供できます。Bastion 自体はパブリック IP を使う構成も可能です。踏み台 VM を使う場合はログ収集と監査を必須にしてください。
設計メモ: アドレス計画はオンプレと重複しないことを最優先にしてください。ハブ&スポークやルート（UDR）設計は将来のトランジット要件を踏まえて検討します。
Day3: VM とストレージのデプロイ
Day3 は VM のデプロイとストレージ基盤を構築します。
- 目的: 管理用/アプリ用 VM とストレージを適切な性能で配置する。
- 期待される成果: VM が起動し、ストレージがアタッチされ、SSH/AD ログインが確認できる。
- 検証項目: VM のステータス、ディスク性能、SSH 接続、エージェント（Azure Monitor）導入の確認。
- CLI（前提: Contributor）:
|
1 2 3 4 5 6 7 8 9 |
az vm create \ --resource-group my-rg \ --name myLinuxVM \ --image UbuntuLTS \ --size Standard_B2s \ --admin-username azureuser \ --ssh-key-values ~/.ssh/id_rsa.pub \ --nsg nsg-management |
- ディスク選定の目安: 開発は Standard SSD、汎用は Standard/Premium SSD、I/O 要件が高い場合は Ultra を検討します。Managed Disk を推奨します。
- 暗号化: デフォルトではプラットフォーム管理キー（PMK）で暗号化されます。顧客管理キー（CMK）を使う場合は Key Vault と Disk Encryption Set を組み合わせます。Key Vault の動作仕様は変更される場合があるため、必ず公式ドキュメントを参照してください。
検証コマンド例:
|
1 2 3 |
az vm show -g my-rg -n myLinuxVM --query "{powerState:powerState,os:storageProfile.imageReference}" --output json az vm extension list -g my-rg --vm-name myLinuxVM --output table |
Day4: Entra ID（旧: Azure AD）・RBAC 管理
Day4 はユーザー・グループ・ロール割当てと MFA、条件付きアクセスを整備します。
- 目的: グループ運用と最小権限の RBAC を実装し、管理者に MFA を必須化する。
- 期待される成果: グループによるロール管理が可能で、管理者に MFA が設定されている。
- 検証項目: グループ作成確認、ロール割当の一覧、条件付きアクセスポリシーの適用状況。
- CLI（注意: az ad は将来変化する可能性あり）:
グループ作成（az ad が運用可能な環境向け）:
|
1 2 |
az ad group create --display-name "dev-team" --mail-nickname "dev-team" |
az ad が利用できない、あるいは将来の移行を想定する場合は Microsoft Graph を使うか az rest を利用してください。Graph を使う場合は適切な権限が必要です。
Graph を az rest で呼ぶ例（権限: Group.ReadWrite.All 等）:
|
1 2 3 4 5 |
az rest --method POST \ --uri "https://graph.microsoft.com/v1.0/groups" \ --headers "Content-Type=application/json" \ --body '{"displayName":"dev-team","mailNickname":"dev-team","mailEnabled":false,"securityEnabled":true}' |
ロール割当例（リソースグループに Contributor を付与）:
|
1 2 |
az role assignment create --assignee "<group-object-id-or-principalId-or-upn>" --role "Contributor" --scope "/subscriptions/<subId>/resourceGroups/my-rg" |
注意点: ロール割当を行うには Owner か User Access Administrator 権限が必要です。Conditional Access の作成/変更は Entra 管理者権限が必要です。ブレイクグラスアカウントを別途用意し、保管ポリシーを定義してください。
Day5: セキュリティ適用とポリシー
Day5 は Defender、Azure Policy、Resource Lock 等で基盤を固めます。重複説明は統合して後述のセキュリティ節で詳述します。
- 目的: 基本的なセキュリティガードレールを導入する。
- 期待される成果: Defender for Cloud が有効化され、主要な Policy が適用されている。重要リソースに Resource Lock を付与した。
- 検証項目: Defender の推奨事項、Policy の適用結果、Resource Lock の状態確認。
- CLI 例:
Resource Lock（削除不可）の付与:
|
1 2 |
az resource lock create --lock-type CanNotDelete --name prod-lock --resource-group my-rg |
Defender for Cloud の有効化やポリシーの導入は Portal から行うか、組織のガバナンスフローに沿って自動化します。Defender、DDoS Protection Standard、Log Analytics のデータ取り込みやバックアップは有料項目があるため、事前にコスト見積りをしてください。
Day6: 監視・ログ・バックアップの導入
Day6 は監視基盤とバックアップの設定と動作確認を行います。
- 目的: Log Analytics へログを集約し、バックアップ方針を定義する。
- 期待される成果: ワークスペースが作成され、Diagnostic Settings が送信先に設定され、バックアップがスケジュールされている。
- 検証項目: エージェントの Heartbeat、ログがクエリで取得できること、リストアテストの実施。
- CLI（前提: Contributor + Backup Contributor）:
Log Analytics ワークスペース作成:
|
1 2 |
az monitor log-analytics workspace create -g my-rg -n my-law -l japaneast |
Recovery Services Vault 作成（バックアップ）:
|
1 2 |
az backup vault create -g my-rg -n my-vault -l japaneast |
Diagnostic Settings を設定してログをワークスペースへ送る例（リソースパスは対象リソースに置換）:
|
1 2 3 4 5 6 |
az monitor diagnostic-settings create \ --name "diag-to-law" \ --resource "/subscriptions/<subId>/resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/myLinuxVM" \ --workspace "/subscriptions/<subId>/resourceGroups/my-rg/providers/Microsoft.OperationalInsights/workspaces/my-law" \ --logs '[{"category":"Administrative","enabled":true}]' |
検証クエリ例（Log Analytics）:
|
1 2 |
az monitor log-analytics query --workspace "<workspace-id>" --analytics-query "Heartbeat | take 10" |
- 期待される出力例: Heartbeat の行が 1 行以上返る。返らない場合はエージェント未導入やネットワーク接続を確認してください。
- コスト注意: Log Analytics のデータ量と保持期間はコストに直結します。保管期間とデータ取り込み量を設計段階で決めてください。
Day7: IaC・自動化と本番移行の最終チェック
Day7 は全構成のテンプレート化と本番移行の最終確認を行います。
- 目的: Bicep/ARM テンプレートで再現性を確保し、CI/CD により段階的に昇格する。
- 期待される成果: Bicep テンプレートで dev→staging→prod のデプロイが自動化され、移行チェックリストを満たしている。
- 検証項目: テンプレートの lint/validate を通過、CI のテスト成功、本番移行のロールアウト手順とロールバック手順が整備されている。
- Bicep デプロイ例（前提: az login, Contributor）:
|
1 2 |
az deployment group create -g my-rg --template-file main.bicep --parameters @params.json |
本番移行チェック項目の主要例: コスト・権限・監視・バックアップの最終確認、負荷試験、運用ドキュメントの整備。移行は段階的に行い、必ずロールバック手順を準備してください。
ネットワーク基盤とリソース設計（命名規則・VNet・NSG・ピアリング）
ここではネットワーク設計や命名規則など、運用しやすい基盤設計のポイントを示します。設計は保守性と最小権限の両立を重視してください。
命名規則とタグ設計
命名規則とタグはコスト管理や自動化で効果が出ます。組織ごとに最適化してください。
- 命名例: {org}-{env}-{app}-{rtype}-{region}-{instance}（例: contoso-prod-web-vm-jpe-01）
- 推奨タグ: Owner, Environment, CostCenter, Project, ExpiryDate
- 運用ポイント: 自動化スクリプトでタグ付けを必須にし、未タグのリソースは停止・通知する仕組みを検討します。
VNet／サブネット設計とアドレス計画
アドレス計画は将来の拡張性を念頭に置いて設計してください。
- 推奨: RFC1918 範囲を利用し、オンプレと重複しないこと。
- 小〜中規模の例: 10.0.0.0/16 を用い、サブネットは /24 単位で分割。
- 管理系サブネットは最小アクセスに制限し、監査ログを収集すること。
NSG・ルート・ピアリングの設計
セキュリティは「最小許可」の原則で実装します。
- NSG は受信を基本ブロックにし、必要なポートのみ許可。ASG を活用すると管理が簡単です。
- VNet ピアリングは低レイテンシ接続を提供します。トランジティブ接続が必要ならハブ&スポーク＋FW を検討してください。
- ピアリング作成例:
|
1 2 |
az network vnet peering create -g my-rg --name peer-to-hub --vnet-name my-vnet --remote-vnet "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/hub" --allow-vnet-access |
パブリックアクセスとロードバランサ設計
公開IP は最小限にします。L7（WAF）が必要な場合は Application Gateway を検討してください。フロントは WAF、バックエンドはプライベートという構成を推奨します。
仮想マシン・ストレージの設計と実装（要点）
VM とストレージの設計は性能・可用性・コストのトレードオフがあります。ここでは実務的な要点を示します。
VM の設計ポイント
- サイズ選定は負荷とコストで決めます。開発は B シリーズ、汎用は D 系、I/O 重視は L/Ultra を検討。
- 認証方式: Linux は公開鍵認証（SSH）を推奨。Windows は Azure AD ログインの利用を推奨します。
- 公開IP: 管理用は Bastion 経由を原則にし、最小限のみ割当てる。
ディスクと暗号化の要点
- Managed Disk（GPv2）を基本に選択します。IOPS 要件で Premium/Ultra を選択。
- 暗号化: デフォルトはプラットフォーム管理キーです。CMK を使う場合は Key Vault と Disk Encryption Set を組合せます。Key Vault のソフトデリートやパージ保護等は公式ドキュメントで最新仕様を確認してください。
VM 初期化と拡張
Custom Script Extension や Cloud-init で初期設定を自動化します。Azure Monitor エージェントを事前に組み込んでおくと監視が容易です。
セキュリティ基盤・キー管理・監視・バックアップ（統合）
このセクションにセキュリティ関連の主要項目を一箇所にまとめます。説明の重複を避け、実務での運用ルールに焦点を当てます。
認証・RBAC・MFA の運用
- RBAC はグループ単位で割り当て、最小権限を徹底します。
- 管理者アカウントには MFA を必須化してください。条件付きアクセスでリスクベース制御を追加します。
- ブレイクグラス運用は手順書化し、保管方法を定義します。
Key Vault と Managed Identity
- Key Vault にシークレット・キー・証明書を保管し、アプリは Managed Identity でアクセスします。
- ネットワーク制限（Firewall/Private Endpoint）を検討してください。Key Vault のソフトデリートやパージ保護などの仕様は変更され得るため、公式ドキュメントで最新情報を確認してください（参照リンクを必ず参照）。
参照（Key Vault 一覧）: https://learn.microsoft.com/ja-jp/azure/key-vault/
セキュリティサービスとポリシー
- Microsoft Defender for Cloud を有効化し、推奨事項を継続的に確認します。導入はコストに注意してください。
- Azure Policy でタグ強制、許可リージョン、公開 IP 制限を自動化します。
- 重要リソースには Resource Lock を付与しますが、解除手順を運用手順書に明記してください。
監視・ログの設計
- Log Analytics を中心に Diagnostic Settings でログを集約します。
- アラートはメトリクスアラートとアクティビティログアラートを組合せます。通知先は運用フローに合わせて設計してください。
- Application Insights はアプリ層のトレーシングに有効です。
バックアップと可用性
- Recovery Services Vault で VM バックアップを設定し、定期的に復旧試験を実施してください。
- スナップショットは短期復旧、バックアップは長期保持に使い分けます。
- 可用性要件に応じて可用性セットか可用性ゾーンを選定し、SLA を確認してください。
IaC・自動化・本番移行チェックリストとトラブルシューティング
IaC と自動化は再現性と運用効率を高めます。ここではデプロイフロー、チェックリスト、代表的なトラブル対応を示します。
デプロイフローと本番移行チェックリスト
テンプレート作成→CI による検証→段階的昇格の流れが基本です。主要チェック項目は次の通りです。
- テンプレートの lint/validate を通過していること。
- デプロイを dev 環境で自動テストし、staging を経て本番へ昇格すること。
- 主要チェック: コスト、権限、監視、バックアップ、負荷試験、運用手順の整備。
Bicep デプロイ例:
|
1 2 |
az deployment group create -g my-rg --template-file main.bicep --parameters @params.json |
代表的なトラブルシューティング例
以下に代表的な障害と確認コマンド、期待される出力例、次のアクションを示します。
権限不足でコマンドが失敗する
確認コマンド:
|
1 2 |
az role assignment list --assignee "<user-or-objectId>" --output json |
期待される出力例:
- JSON に当該スコープでのロール割当が一覧表示される。
- 空の場合はロールが付与されていない。
次に取るべきアクション:
- 必要なロール（Owner か User Access Administrator）を付与する。
- 付与後は数分待って再試行する。
VM が起動しない（Boot failure）
確認コマンド:
|
1 2 3 |
az vm get-instance-view -g my-rg -n myVM --query "instanceView.bootDiagnostics" --output json az vm show -g my-rg -n myVM --query "properties.instanceView" --output json |
期待される出力例:
- Boot Diagnostics のログ URI が存在する。
- instanceView にエラーや停止状態の情報が表示される。
次に取るべきアクション:
- シリアルコンソール / Boot Diagnostics のログを確認する。
- OS 拡張やディスクの破損が疑われる場合はディスクを別 VM にアタッチしてログを確認する。
ログが Log Analytics に来ない
確認コマンド:
|
1 2 3 |
az monitor log-analytics query --workspace "<workspace-id>" --analytics-query "Heartbeat | take 5" az vm extension list -g my-rg --vm-name myVM --output table |
期待される出力例:
- Heartbeat が 1 件以上返る。
- エージェント拡張が VM にインストールされている。
次に取るべきアクション:
- エージェント未導入ならインストールする。
- Diagnostic Settings の対象ワークスペースを再確認する。
- ネットワーク FW/NSG でアウトバウンドが遮断されていないか確認する。
NSG による通信遮断
確認コマンド:
|
1 2 3 |
az network nsg rule list -g my-rg --nsg-name nsg-management --output table az network watcher packet-capture show --name "<pc-name>" -g my-rg --output json |
期待される出力例:
- 必要なポートを許可するルールが存在する。
- 優先度による上書きがないか確認できる。
次に取るべきアクション:
- NSG の優先順位を見直す。
- 一時的にログを有効化して通信の阻害箇所を特定する。
コスト管理と最適化（運用ルール）
- Pricing Calculator を使って見積もりを作成してください。
- 非本番は稼働時間を限定し、スポット VM や予約インスタンスを検討します。
- Log Analytics の取り込み量と保持期間を削減してコストを抑えます。
参考リソース（公式ドキュメント・導入資料）
主要な公式ドキュメント（日本語）を中心に参照してください。仕様は変更され得ます。必ずリンク先の最新情報を確認してください。
- Azure ポータル: https://portal.azure.com/
- Azure CLI ドキュメント（日本語）: https://learn.microsoft.com/ja-jp/cli/azure/?view=azure-cli-latest
- Entra ID（旧: Azure AD）概要（日本語）: https://learn.microsoft.com/ja-jp/azure/active-directory/fundamentals/
- Azure Bastion（日本語）: https://learn.microsoft.com/ja-jp/azure/bastion/bastion-overview
- Key Vault（日本語）: https://learn.microsoft.com/ja-jp/azure/key-vault/
- Microsoft Defender for Cloud（日本語）: https://learn.microsoft.com/ja-jp/azure/defender-for-cloud/
- Log Analytics（日本語）: https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/log-analytics-overview
- Azure Backup（日本語）: https://learn.microsoft.com/ja-jp/azure/backup/backup-introduction-to-azure-backup
- Azure Policy（日本語）: https://learn.microsoft.com/ja-jp/azure/governance/policy/overview
- Microsoft Graph（日本語）: https://learn.microsoft.com/ja-jp/graph/overview
まとめ（要点）
- 想定読者と前提（権限・CLI）を満たしてから作業を開始してください。
- Day1〜Day7 の各日で「期待される成果」と「検証項目」を明確にし、段階的に進めます。
- セキュリティ（RBAC/MFA/Key Vault）、監視、バックアップは一箇所に集約して運用ルールを定めてください。
- CLI コマンドは環境依存や将来の API 変更の影響を受けます。必要に応じて az rest や Microsoft Graph CLI を利用してください。
- 有料サービス（Defender、DDoS Standard、Log Analytics、Backup 等）はコスト影響が大きいので事前に見積りを行い、運用ルールに落とし込んでください。
スポンサードリンク