Container Appsのリビジョン管理で無停止変更を説明する
- 山崎行政書士事務所
- 7月8日
- 読了時間: 20分
本番変更時の影響範囲・切戻し・承認を「説明できる」リリース管理へ
確認日：2026年7月8日対象読者：情シス担当者、クラウド運用担当者、経営層、監査対応担当者対象領域：Azure Container Apps、リビジョン管理、本番変更管理、リリース手順、承認証跡
結論
Azure Container Appsを本番運用する場合、重要なのは「コンテナーを更新できること」ではありません。重要なのは、本番変更時に、どのリビジョンへ、どの割合で、いつ、誰の承認で、どのように切り替え、問題時にどう戻すかを説明できることです。
Azure Container Appsには、リビジョン、トラフィック分割、リビジョンラベル、ブルーグリーンデプロイといった仕組みがあります。これらを変更管理規程・リリース手順・承認証跡と結び付けることで、情シスと経営層が「無停止変更」を説明しやすくなります。
ただし、ここでいう「無停止」は、Azure Container Appsのリビジョン切替の仕組み上、既存リビジョンを維持しながら新リビジョンを準備・切替できるという意味です。アプリケーション不具合、DBマイグレーション、外部API障害、セッション管理不備まで含めて停止ゼロを保証するものではありません。個別環境の可用性は、実装・監視・DB設計・リリース手順を確認しない限り断定できません。
理由
本番変更では、監査・事故対応・経営説明の場で、次の質問が必ず問われます。
問われること | 説明できない場合のリスク |
何を変更したのか | 影響範囲が不明になり、障害時の原因特定が遅れる |
どのリビジョンへ切り替えたのか | 稼働バージョンとコード差分を追跡できない |
どのユーザーに影響したのか | 障害範囲・顧客影響・告知判断が曖昧になる |
どう切り戻すのか | 障害時に判断が止まり、復旧が遅れる |
誰が承認したのか | 変更管理・内部統制・監査証跡が弱くなる |
どのログで確認するのか | 事後検証・再発防止策が作れない |
Container Appsのリビジョンは、コンテナーアプリの各バージョンのスナップショットであり、作成後は不変、バージョン管理の記録として機能し、複数リビジョンを同時に実行できます。Microsoft公式情報では、リビジョンはリリース管理、以前のバージョンへの戻し、A/Bテスト、ブルーグリーンデプロイに利用できると説明されています。
数字で見る：本番リリースで最低限管理すべき12項目
No. | 管理項目 | 目的 |
1 | 変更申請番号 | 監査・承認・リリース記録を紐付ける |
2 | 対象Container App名 | 変更対象を特定する |
3 | 旧リビジョン名 | 切戻し先を明確にする |
4 | 新リビジョン名 | リリース対象を特定する |
5 | コンテナーイメージタグ／Digest | 実体を固定する |
6 | GitコミットID | ソースコード差分を追跡する |
7 | 変更種別 | 機能追加・設定変更・障害修正・緊急対応を区別する |
8 | 影響範囲 | ユーザー、API、DB、認証、外部連携を確認する |
9 | トラフィック比率 | 段階リリース・全面切替・切戻しを管理する |
10 | 監視指標 | 成功・異常・中止条件を定義する |
11 | 承認者 | 責任者の確認を証跡化する |
12 | 切戻し手順 | 障害時に迷わず戻す |
1. Container Appsのリビジョン管理とは
Azure Container Appsでは、アプリケーションのライフサイクルはリビジョンを中心に展開されます。コンテナーアプリをデプロイすると最初のリビジョンが作成され、コンテナー変更やtemplateセクションの調整により追加のリビジョンが作成されます。Microsoft公式情報では、Container Appsには「デプロイ」「更新」「非アクティブ化」「シャットダウン」の4フェーズがあると説明されています。なお、Container Appsジョブはリビジョンをサポートしません。
図1：Container Appsリビジョンの基本構造
┌──────────────────────────────────────────┐
│ Container App │
│ app-api.example.internal │
└──────────────────────────────────────────┘
│
│ リビジョンとして履歴化
▼
┌────────────────────┐ ┌────────────────────┐
│ Revision v1 │ │ Revision v2 │
│ image: app:1.0.0 │ │ image: app:1.1.0 │
│ env: stable │ │ env: new │
│ status: active │ │ status: active │
└────────────────────┘ └────────────────────┘
▲ ▲
│ │
旧安定版 新バージョン2. 「無停止変更」を説明するための基本
Microsoft公式情報では、単一リビジョンモードでは、新しいリビジョンが準備できるまで既存のアクティブリビジョンは非アクティブ化されず、イングレスが有効な場合は新しいリビジョンの準備ができるまで既存リビジョンがトラフィックの100%を受け続けると説明されています。また、新しいリビジョンは、プロビジョニング成功、必要レプリカ数へのスケール、起動プローブ・準備プローブ合格などを満たした場合に準備完了と扱われます。
図2：単一リビジョンモードでの無停止切替イメージ
時点A：本番稼働中
┌──────────────┐
│ Revision v1 │ ← 100% traffic
│ stable │
└──────────────┘
時点B：新リビジョン作成中
┌──────────────┐ ┌──────────────┐
│ Revision v1 │ │ Revision v2 │
│ stable │ │ provisioning │
│ 100% traffic │ │ 0% traffic │
└──────────────┘ └──────────────┘
時点C：新リビジョン準備完了後
┌──────────────┐ ┌──────────────┐
│ Revision v1 │ │ Revision v2 │
│ inactive │ │ active │
│ 0% traffic │ │ 100% traffic │
└──────────────┘ └──────────────┘この仕組みは便利ですが、監査や事故対応で重要なのは「本当に無停止だったか」ではなく、無停止を意図した設計・判断・監視・切戻し条件が記録されているかです。
3. 単一リビジョン・複数リビジョン・ラベルの使い分け
Azure Container Appsでは、単一リビジョンモードと複数リビジョンモードを選択できます。公式情報では、単一リビジョンモードが既定であり、複数リビジョンモードでは複数のアクティブリビジョンを設定し、リビジョン間でトラフィックを分割できます。
表1：リビジョンモードの実務上の使い分け
モード | 公式上の特徴 | 実務での使いどころ | 注意点 |
単一リビジョン | 最新リビジョンへ自動切替。既定モード | 小規模アプリ、標準的な本番更新 | 段階リリースやA/Bテストには不向き |
複数リビジョン | 複数リビジョンを同時にアクティブ化可能 | カナリア、ブルーグリーン、段階リリース | トラフィック比率と切戻し運用が必要 |
リビジョンラベル | 特定リビジョンに一意URLを付与 | ステージング確認、限定テスト | ラベルの移動履歴を管理する必要 |
デプロイラベル | stage/prod等のラベルで管理し、履歴からロールバック可能 | 高度なリリース管理 | 公式情報では事前有効化が必要とされています |
デプロイラベルは、開発・ステージング・prodなどのわかりやすい名前を特定リビジョンに割り当て、ラベル履歴から以前のリビジョンにロールバックできる機能として説明されています。ただし、公式ページではデプロイラベルを使う前にポータルで有効化が必要とされています。
4. 影響範囲を「図」で説明する
本番変更では、変更対象のコンテナーだけを見ても不十分です。Container Appsの背後には、ID、ネットワーク、DB、外部API、監視、ログ、シークレット、CI/CDが関係します。
図3：本番変更時の影響範囲マップ
┌────────────────────┐
│ 利用者・取引先 │
└─────────┬──────────┘
│
▼
┌─────────────┐ ┌────────────────────┐
│ Front Door等 │──────▶│ Container Apps │
│ WAF/CDN等 │ │ Revision v1 / v2 │
└─────────────┘ └─────────┬──────────┘
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Entra ID │ │ Database │ │ 外部API │
│ 認証・認可 │ │ スキーマ変更 │ │ 決済・連携等 │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└───────────────────────┼───────────────────────┘
▼
┌────────────────────┐
│ Azure Monitor / Logs│
│ 監視・証跡・分析 │
└────────────────────┘表2：影響範囲レビュー表
確認領域 | 確認ポイント | 証跡例 |
アプリ機能 | API仕様変更、画面変更、互換性 | Pull Request、テスト結果 |
コンテナー | イメージタグ、Digest、ベースイメージ | ACR情報、SBOM、スキャン結果 |
設定 | 環境変数、シークレット、Dapr、Ingress | Bicep/YAML差分 |
認証認可 | Entra ID、ロール、トークン検証 | 権限設計書、試験結果 |
ネットワーク | Ingress、内部通信、Private Endpoint | 構成図、通信試験 |
データ | DBスキーマ、互換性、移行手順 | マイグレーション手順 |
監視 | 5xx、レイテンシ、ログ、アラート | Azure Monitor設定 |
セキュリティ | 脆弱性、依存ライブラリ、秘密情報 | スキャン結果 |
運用 | 切戻し、連絡体制、停止判断 | リリース手順書 |
法務・規程 | 変更管理規程、委託先責任、証跡保管 | 規程、承認記録 |
5. トラフィック分割で段階リリースを説明する
Container Appsの複数リビジョンモードでは、アクティブなリビジョン間で受信トラフィックを分割できます。公式情報では、トラフィック分割は各リビジョンへルーティングされる割合に基づき、すべてのトラフィック分割ルールの重み合計は100%である必要があります。
図4：カナリアリリースの段階例
Step 0：リリース前
Revision v1 ━━━━━━━━━━━━━━━━━━━ 100%
Revision v2 ─────────────────── 0%
Step 1：限定投入
Revision v1 ━━━━━━━━━━━━━━━━━━ 95%
Revision v2 ━ 5%
Step 2：初期拡大
Revision v1 ━━━━━━━━━━━━━━━━ 80%
Revision v2 ━━━━ 20%
Step 3：本格拡大
Revision v1 ━━━━━━━━━━ 50%
Revision v2 ━━━━━━━━━━ 50%
Step 4：全面切替
Revision v1 ─────────────────── 0%
Revision v2 ━━━━━━━━━━━━━━━━━━━ 100%表3：段階リリース判断表
段階 | トラフィック比率 | 観察時間 | 進行条件 | 中止条件 |
事前確認 | v1 100% / v2 0% | 30分 | v2の直接URL確認OK | 起動失敗、重大ログ |
カナリア1 | v1 95% / v2 5% | 30〜60分 | 5xx増加なし、P95悪化なし | 5xx急増、認証失敗 |
カナリア2 | v1 80% / v2 20% | 60分 | 問い合わせ増加なし | 業務エラー増加 |
半量切替 | v1 50% / v2 50% | 60分 | 主要KPI正常 | DB負荷上昇 |
全面切替 | v1 0% / v2 100% | 監視継続 | SLA/SLO範囲内 | 即時切戻し |
6. ブルーグリーンデプロイで切戻しを説明する
Microsoft公式情報では、Azure Container Appsでブルーグリーンデプロイを有効にするには、リビジョン、トラフィックの重み、リビジョンラベルを組み合わせて使用すると説明されています。安定版をBlue、新バージョンをGreenとして、新リビジョンをテスト後に本番トラフィックを切り替え、問題があれば安定したBlueへ戻すことができます。
図5：ブルーグリーンデプロイの説明図
【通常時】
┌──────────────────┐
利用者 ─────▶│ Blue Revision │
│ stable / prod │
│ traffic 100% │
└──────────────────┘
【新バージョン準備】
┌──────────────────┐
利用者 ─────▶│ Blue Revision │
│ traffic 100% │
└──────────────────┘
┌──────────────────┐
検証者 ─────▶│ Green Revision │
│ staging / test │
│ traffic 0% │
└──────────────────┘
【切替後】
┌──────────────────┐
利用者 ─────▶│ Green Revision │
│ new prod │
│ traffic 100% │
└──────────────────┘
【障害時の切戻し】
┌──────────────────┐
利用者 ─────▶│ Blue Revision │
│ previous stable │
│ traffic 100% │
└──────────────────┘表4：切戻し判断マトリクス
事象 | 判断 | 操作 | 承認 |
新リビジョンが起動しない | リリース中止 | 旧リビジョン100%維持 | リリース責任者 |
5xxが閾値超過 | 即時切戻し | 旧リビジョン100%へ戻す | 運用責任者 |
認証エラー増加 | 原則切戻し | Green 0%、Blue 100% | 情シス責任者 |
DB互換性問題 | 切戻し可否を個別判断 | DB変更手順に従う | 業務責任者＋DB責任者 |
軽微な表示不具合 | 継続または段階停止 | 比率維持・修正版準備 | サービス責任者 |
セキュリティ事故疑い | 緊急停止・遮断も検討 | WAF/Ingress/Traffic制御 | セキュリティ責任者 |
7. 変更種別を分ける：新リビジョンが作られる変更・作られない変更
Container Appsの変更は、リビジョンスコープ変更とアプリケーションスコープ変更に分類されます。公式情報では、リビジョンスコープ変更では新しいリビジョンが作成され、アプリケーションスコープ変更では全リビジョンにグローバル適用され、新しいリビジョンは作成されません。アプリケーションスコープ変更には、シークレット値、リビジョンモード、Ingress構成、トラフィック分割ルール、ラベル等が含まれると説明されています。
表5：変更種別とレビュー観点
変更種別 | 例 | 新リビジョン | 重点レビュー |
コンテナーイメージ変更 | app:1.0.0→app:1.1.0 | 作成される | 機能、脆弱性、起動確認 |
環境変数変更 | API URL、Feature Flag | 内容により要確認 | 秘密情報、互換性 |
スケール設定変更 | min/max replicas、KEDA | 作成される場合あり | 性能、コスト、可用性 |
シークレット変更 | DB接続文字列等 | 新リビジョンなし | 再起動要否、漏えい防止 |
Ingress変更 | 外部公開、ポート等 | 新リビジョンなし | 公開範囲、WAF、認証 |
トラフィック比率 | 95/5、80/20等 | 新リビジョンなし | 切戻し、監視、承認 |
ラベル移動 | staging/prod切替 | 新リビジョンなし | どのリビジョンを指すか |
Dapr設定 | コンポーネント変更 | 新リビジョンなしの場合あり | 接続先、権限、障害時影響 |
8. 変更管理規程に入れるべき条項
NIST SP 800-128は、情報セキュリティが組織全体の構成管理に不可欠であること、構成を管理・監視してリスクを最小化しつつ業務機能を支えることを目的として説明しています。クラウドのリビジョン管理も、単なるリリース作業ではなく、構成管理・変更管理・監査証跡の一部として扱うべきです。
表6：変更管理規程に入れるべき項目
規程項目 | 記載すべき内容 |
目的 | 本番変更の安全性、可用性、説明責任を確保する |
適用範囲 | Azure Container Apps、CI/CD、関連DB、外部連携、監視設定 |
変更分類 | 通常変更、標準変更、緊急変更、軽微変更 |
申請事項 | 変更内容、対象、影響範囲、切戻し、承認者 |
影響評価 | ユーザー影響、業務影響、セキュリティ影響、法務・契約影響 |
承認基準 | 本番変更の承認者、緊急変更の事後承認 |
リリース手順 | 事前確認、段階切替、監視、完了判定 |
切戻し手順 | 条件、実施者、承認、記録 |
証跡保管 | PR、Pipeline、Activity Log、監視ログ、承認記録 |
例外管理 | 手順省略・緊急対応・期限・事後レビュー |
定期見直し | 障害、監査指摘、構成変更に応じて更新 |
規程文サンプル
第○条（Azure Container Appsの本番変更管理）
1. 本番環境のAzure Container Appsに対する変更は、事前に変更申請を行い、
変更内容、対象リビジョン、影響範囲、監視項目、切戻し手順を明記しなければならない。
2. 複数リビジョンモード、トラフィック分割、リビジョンラベルを使用する場合、
変更申請には旧リビジョン、新リビジョン、トラフィック比率、切替予定時刻、
切戻し条件を記載しなければならない。
3. 本番トラフィックを新リビジョンへ切り替える前に、
起動確認、準備プローブ、主要機能試験、監視項目の確認を実施しなければならない。
4. 障害、性能劣化、認証失敗、データ不整合その他重大な影響が確認された場合、
あらかじめ定めた切戻し条件に従い、旧リビジョンへのトラフィック復旧を実施する。
5. 変更後は、承認記録、パイプライン実行結果、リビジョン名、トラフィック設定、
Activity Log、監視ログ、障害有無を記録し、所定期間保管する。9. リリース手順書テンプレート
図6：本番リリース全体フロー
┌──────────────┐
│ 変更申請作成 │
└──────┬───────┘
▼
┌──────────────┐
│ 影響範囲評価 │
└──────┬───────┘
▼
┌──────────────┐
│ Pull Request │
│ レビュー │
└──────┬───────┘
▼
┌──────────────┐
│ 検証環境反映 │
└──────┬───────┘
▼
┌──────────────┐
│ 本番承認 │
└──────┬───────┘
▼
┌──────────────┐
│ 新Revision作成│
└──────┬───────┘
▼
┌──────────────┐
│ 0%で確認 │
└──────┬───────┘
▼
┌──────────────┐
│ 段階的切替 │
└──────┬───────┘
▼
┌──────────────┐
│ 完了判定 │
└──────┬───────┘
▼
┌──────────────┐
│ 証跡保管 │
└──────────────┘表7：リリース手順書
手順 | 作業 | 実施者 | 確認者 | 証跡 |
1 | 変更申請を作成 | 開発担当 | 情シス責任者 | 変更申請番号 |
2 | 影響範囲を確認 | 開発・運用 | 業務責任者 | 影響範囲表 |
3 | PRを作成 | 開発担当 | レビュアー | PR URL |
4 | イメージをビルド | CI/CD | 自動 | Pipelineログ |
5 | 検証環境へ反映 | CI/CD | QA担当 | テスト結果 |
6 | 本番承認 | 承認者 | 情シス責任者 | 承認ログ |
7 | 新リビジョン作成 | CI/CD | 運用担当 | Revision名 |
8 | 0%またはラベルURLで確認 | 運用担当 | 開発担当 | 動作確認記録 |
9 | 5%へ切替 | 運用担当 | リリース責任者 | Traffic設定 |
10 | 監視 | 運用担当 | 情シス責任者 | Azure Monitor |
11 | 20%、50%、100%へ段階移行 | 運用担当 | リリース責任者 | Traffic履歴 |
12 | 完了判定 | リリース責任者 | 業務責任者 | 完了報告 |
13 | 証跡保管 | 運用担当 | 監査担当 | 台帳・ログ |
10. 承認証跡をAzure DevOpsで残す
Azure DevOpsの承認とチェックは、ステージの実行可否やタイミングを制御する仕組みです。公式情報では、承認やチェックはYAMLファイルでは定義されず、リソース管理者がAzure PipelinesのWebインターフェイスで管理すると説明されています。また、承認チェックは一般的に運用環境へのデプロイ制御に使用されます。
Azure DevOps環境は、Dev、Test、QA、Staging、Productionなどの論理ターゲットを表し、デプロイ履歴、コミットと作業項目の追跡可能性、環境のセキュリティに利用できます。公式情報では、環境のデプロイ履歴から、その環境に影響を与えたパイプラインやコミット、作業項目を確認できると説明されています。
図7：承認証跡の流れ
Git Commit
│
▼
Pull Request
│
▼
Build Pipeline
│
▼
Deploy to Staging
│
▼
Production Environment Approval
│
├─ 承認者
├─ 承認日時
├─ コメント
└─ チェック結果
│
▼
Deploy to Production
│
▼
Revision / Traffic / Logs表8：承認時に見るべき資料
承認者 | 見るべき資料 | 判断内容 |
情シス責任者 | 変更申請、影響範囲、切戻し手順 | 本番反映してよいか |
アプリ責任者 | テスト結果、仕様差分 | 業務機能に問題ないか |
セキュリティ担当 | 脆弱性、認証認可、シークレット | セキュリティリスクが許容内か |
運用担当 | 監視項目、連絡体制、作業時間 | 運用可能か |
経営層 | 重大変更・停止リスク・顧客影響 | 事業リスクとして許容できるか |
11. Activity LogとContainer Appsログで事後説明する
Azure MonitorのActivity Logは、Azureリソースの管理操作を記録し、VM作成、Key Vaultアクセスポリシー変更、Resource Managerデプロイエラーなどのコントロールプレーン操作を確認・監査できます。Activity Logは既定で90日保持され、長期保管が必要な場合は診断設定で別の場所に収集する必要があります。
Container Appsのログについては、公式情報でコンソールログ、システムログ、HTTPログの3種類が示されています。システムログには、トラフィック重み設定、新リビジョン作成、リビジョンプロビジョニング成功・失敗、旧リビジョン非アクティブ化などが含まれます。また、HTTPログにはリビジョン名、ステータスコード、要求時間などが含まれ、リビジョン別のエラー率やP95応答時間の分析に利用できます。
表9：証跡として残すべきログ
証跡 | 目的 | 保存先例 |
Pull Request | 変更内容とレビュー | GitHub / Azure Repos |
Pipeline Run | いつ何をデプロイしたか | Azure DevOps |
Environment Approval | 誰が承認したか | Azure DevOps |
Revision名 | 稼働バージョンの特定 | Container Apps |
Traffic設定 | 何%切り替えたか | Container Apps / CLI出力 |
Activity Log | Azure管理操作の監査 | Azure Monitor |
System Logs | リビジョン作成・重み変更 | Log Analytics |
HTTP Logs | 5xx、遅延、影響範囲 | Log Analytics |
障害対応メモ | 判断・連絡・復旧 | チケット管理 |
完了報告 | 監査・経営説明 | 変更管理台帳 |
KQL例：リビジョン別のエラー率確認
ContainerAppHTTPLogs
| where TimeGenerated > ago(2h)
| where ContainerAppName == "<app-name>"
| summarize
Requests = count(),
Errors = countif(StatusCode >= 500),
ErrorRatePct = round(100.0 * countif(StatusCode >= 500) / count(), 2),
P95DurationMs = percentile(RequestDuration, 95)
by RevisionName, bin(TimeGenerated, 5m)
| order by TimeGenerated descKQL例：リビジョン作成・トラフィック変更の確認
ContainerAppSystemLogs_CL
| where TimeGenerated > ago(24h)
| where ContainerAppName_s == "<app-name>"
| where Log_s has_any ("revision", "traffic", "プロビジョニング", "重み")
| project TimeGenerated, ContainerAppName_s, RevisionName_s, Log_s
| order by TimeGenerated desc12. 本番変更のRACI表
RACIとは、Responsible、Accountable、Consulted、Informedの役割整理です。本番変更では、作業者と承認者が曖昧だと、障害時に判断が止まります。
表10：Container Apps本番リリースRACI
作業 | 開発担当 | 運用担当 | 情シス責任者 | 業務責任者 | セキュリティ担当 | 経営層 |
変更申請 | R | C | A | C | C | I |
影響範囲評価 | R | R | A | C | C | I |
PRレビュー | R | C | A | C | C | - |
検証環境テスト | R | R | A | C | C | - |
本番承認 | C | C | A | C | C | I |
リリース作業 | C | R | A | I | C | I |
監視 | C | R | A | I | C | - |
切戻し判断 | C | R | A | C | C | I |
完了報告 | C | R | A | I | C | I |
事後レビュー | R | R | A | C | C | I |
13. 変更管理台帳テンプレート
表11：本番変更管理台帳
項目 | 記入例 |
変更申請番号 | CHG-2026-0001 |
対象システム | 顧客ポータルAPI |
対象Container App | ca-prod-customer-api |
変更種別 | 通常変更／緊急変更／標準変更 |
旧リビジョン | ca-prod-customer-api--a1b2c3d |
新リビジョン | ca-prod-customer-api--e4f5g6h |
コンテナーイメージ | |
Git Commit | e4f5g6h |
変更内容 | APIレスポンス改善、ログ出力追加 |
影響範囲 | /api/orders、注文照会機能 |
DB変更 | なし |
外部連携変更 | なし |
認証認可変更 | なし |
リリース方式 | 複数リビジョン＋カナリア |
切替計画 | 5%→20%→50%→100% |
監視項目 | 5xx、P95、注文照会成功率 |
中止条件 | 5xxが通常比2倍、P95が1秒超過 |
切戻し方法 | 旧リビジョン100%へ変更 |
承認者 | 情シス責任者、業務責任者 |
作業予定日時 | 2026-07-15 22:00 |
作業完了日時 | 2026-07-15 23:00 |
証跡 | PR、Pipeline、Activity Log、Log Analytics |
事後レビュー | 障害なし／改善点あり |
14. リリース当日のチェックリスト
表12：リリース前チェック
No. | チェック項目 | OK/NG |
1 | 変更申請が承認済みである | |
2 | 旧リビジョン名を確認した | |
3 | 新リビジョン名を確認した | |
4 | 切戻しコマンドを準備した | |
5 | DB変更の有無を確認した | |
6 | Feature Flagの状態を確認した | |
7 | シークレット変更の有無を確認した | |
8 | 監視ダッシュボードを開いた | |
9 | アラート通知先を確認した | |
10 | 関係者の待機体制を確認した | |
11 | 本番承認が完了している | |
12 | 作業開始連絡を行った |
表13：リリース後チェック
No. | チェック項目 | OK/NG |
1 | 新リビジョンがプロビジョニング済み | |
2 | 新リビジョンの起動確認OK | |
3 | 5xx増加なし | |
4 | P95レイテンシ悪化なし | |
5 | 認証エラー増加なし | |
6 | DB接続エラーなし | |
7 | 外部APIエラー増加なし | |
8 | 問い合わせ増加なし | |
9 | 100%切替後も監視正常 | |
10 | 変更完了報告を記録 | |
11 | Activity Log確認 | |
12 | リリース台帳更新 |
15. コマンド例：複数リビジョンモードとトラフィック制御
実際の値は環境に合わせて置き換える必要があります。個別環境のリソース名、RBAC、CI/CD構成は確認できないため、以下は標準的な説明例です。
複数リビジョンモードへ変更
az containerapp revision set-mode \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--mode multiple新リビジョンを作成
az containerapp update \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--image <ACR_NAME>.azurecr.io/<IMAGE_NAME>:<TAG> \
--revision-suffix <GIT_SHORT_SHA>旧リビジョン95%、新リビジョン5%
az containerapp ingress traffic set \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--revision-weight <OLD_REVISION_NAME>=95 <NEW_REVISION_NAME>=5切戻し：旧リビジョン100%
az containerapp ingress traffic set \
--name <CONTAINER_APP_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--revision-weight <OLD_REVISION_NAME>=100 <NEW_REVISION_NAME>=016. 経営層へ説明する場合の要約
図8：経営層向けの説明図
本番変更の目的
↓
新しいリビジョンを作る
↓
最初は本番利用者へ流さず検証
↓
5%だけ流して監視
↓
問題なければ段階的に拡大
↓
異常があれば旧リビジョンへ戻す
↓
承認・ログ・結果を証跡として保存経営層向けメッセージ例
本番変更は、単に新しいプログラムを反映する作業ではありません。Azure Container Appsのリビジョン管理を使うことで、旧バージョンを残したまま新バージョンを準備し、少量のトラフィックから段階的に切り替え、問題があれば旧バージョンへ戻す運用が可能になります。
重要なのは、技術的な切替だけではありません。変更申請、影響範囲、承認、監視、切戻し、証跡保管まで整備することで、監査・事故対応・経営説明に耐えるクラウド運用になります。
17. 山崎行政書士事務所としての支援領域
山崎行政書士事務所では、Azure技術支援とクラウド法務・ガバナンス支援を一体で行います。
Container Appsのリビジョン管理は、技術だけでなく、変更管理規程、リリース手順、承認証跡、監査説明資料と結び付けて初めて、企業運用に耐える仕組みになります。
支援できる内容
領域 | 支援内容 |
Azure技術支援 | Container Apps設計、リビジョン管理、トラフィック分割、監視設計 |
CI/CD支援 | GitHub Actions、Azure DevOps、承認ゲート、リリース手順 |
セキュリティ | Entra ID、シークレット管理、ログ設計、ゼロトラスト観点 |
監査対応 | Activity Log、Container Appsログ、承認証跡、変更台帳 |
規程整備 | 変更管理規程、リリース管理規程、例外管理、証跡保管ルール |
経営説明 | 影響範囲、切戻し、事業リスク、監査向け説明資料 |
契約・法務支援 | クラウド利用規程、委託先管理資料、責任分界整理 |
行政書士業務の範囲を踏まえ、個別紛争対応や訴訟代理など弁護士領域に属する事項は切り分けたうえで、企業がクラウドを安全に活用するための規程整備、契約関連資料、監査説明資料、運用ルール整備を支援します。
18. まとめ
Container Appsのリビジョン管理は、単なるデプロイ機能ではありません。
本番変更時に、何を変えたのかどのリビジョンへ切り替えたのかどの範囲に影響があるのか問題時にどう戻すのか誰が承認したのかどのログで説明するのかを明確にするための、クラウド変更管理の中核です。
Azure Container Appsのリビジョン、トラフィック分割、ラベル、ブルーグリーンデプロイを、変更管理規程・リリース手順・承認証跡と一体化することで、情シス担当者も経営層も「説明できるクラウド運用」を実現できます。
Azure Container Appsの本番リリース設計、無停止変更の説明資料、変更管理規程、リリース手順書、承認証跡、監査対応資料の整備は、山崎行政書士事務所へご相談ください。
出典・確認日
確認日：2026年7月8日
出典 | 確認した主な内容 | 最終更新日 |
Microsoft Learn：Azure Container Apps の変更を更新してデプロイする | リビジョンの性質、リビジョンモード、無停止デプロイ、変更種別、リリース管理 | 2025年10月27日 |
Microsoft Learn：Azure Container Apps でのアプリケーション ライフサイクル管理 | ライフサイクル、単一リビジョンモード、シャットダウン、ジョブの注意点 | 2026年2月26日 |
Microsoft Learn：Azure Container Apps でのトラフィック分割 | 複数リビジョン、トラフィック重み、合計100% | 2025年6月16日 |
Microsoft Learn：Azure Container Apps でのブルーグリーンデプロイ | Blue/Green、トラフィック切替、ロールバック | 2025年11月7日 |
Microsoft Learn：Azure Container Apps でのデプロイ ラベル | ラベル履歴、ラベルによるロールバック、事前有効化 | 2026年1月8日 |
Microsoft Learn：Azure DevOps 承認とチェック | YAML外の承認管理、本番環境デプロイ制御 | 2025年12月17日 |
Microsoft Learn：Azure DevOps 環境 | デプロイ履歴、コミット・作業項目の追跡、環境セキュリティ | 2026年6月17日 |
Microsoft Learn：Azure Monitor Activity Log | 管理操作の監査、90日保持、長期保管 | 2026年5月26日 |
Microsoft Learn：Azure Container Appsログ監視 | システムログ、HTTPログ、RevisionName、エラー率確認 | 2026年6月11日 |
NIST SP 800-128 | セキュリティ重視の構成管理、リスク最小化、構成監視 | 2019年10月10日更新 |
コメント