Azureのインフラ払い出しをセルフサービス化する｜IaCとDeployment Stacksで申請から変更管理まで統制する

開発や検証の環境を1つ用意するだけで、申請してから何日も待つ。Azureの利用が広がるほど、インフラ払い出しの窓口は詰まりやすくなります。

インフラのセルフサービス化とは、利用者に自由に作らせることではなく、決められたテンプレートを、承認と記録を通して誰でも同じ品質で使える状態をつくることです。本記事は、BicepとAzure Pipelines、Deployment Stacksで申請から構築・変更管理までを統制する仕組みと、Azure Deployment Environmentsの使いどころを、弊社の検証をもとに解説します。

弊社は、Azureの運用標準化を検討されているお客様に向けて、インフラ払い出しの標準化とセルフサービス化を提案し、実際に環境を構築して検証してきました。本記事では、その検討で整理した設計の考え方と、構築してみて分かった注意点をまとめます。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。

セルフサービス化の全体像｜申請から構築・変更まで同じ道筋を通す

弊社がインフラ払い出しのセルフサービス化として提案しているのは、利用者は申請するだけで、構築と変更はテンプレートとパイプラインが行い、その過程がすべて記録に残る仕組みです。インフラの構成はコード（IaC：Infrastructure as Code）として管理し、人がポータルで手作業をする場面を減らします。

この仕組みでは、利用者が選べるのは「どのテンプレートを、どの値で使うか」だけです。ネットワークの設計や命名規則、監視やセキュリティの設定といった標準は、テンプレートの側にあらかじめ組み込まれています。そのため、誰が申請しても同じ品質の環境ができあがり、共通チームは一つひとつの構築作業ではなく、テンプレートと仕組みの改善に時間を使えるようになります。

なぜこの仕組みが必要か｜インフラ払い出しが「申請待ち」になる理由

多くの企業では、Azureのリソースが必要になると、利用部門や開発者が情報システム部門などの共通チームに申請し、担当者がポータルや手順書に沿って構築しています。利用が少ないうちはこれで回りますが、サブスクリプションや案件が増えるにつれて、次のような課題が表に出てきます。

課題	起きていること	その結果
申請の集中	構築できる担当者が限られ、依頼が順番待ちになる	開発や検証の開始が遅れ、担当者も本来の業務に時間を割けない
手作業による構築	担当者ごとに設定の細部や命名、タグの付け方が変わる	同じ構成を二度と正確に作れず、設定の誤りがセキュリティの穴になる
残り続けるリソース	使い終わった環境が削除されず、誰のものか分からなくなる	不要な費用が発生し続け、棚卸しにも手間がかかる
構成のずれ	緊急対応などでポータルから直接変更し、手順書や設計書と実体が食い違う	次の変更で思わぬ影響が出るため、変更そのものを避けるようになる
記録の欠如	誰が、いつ、何を、なぜ変えたかがメールやチャットに散らばる	監査や障害対応のときに、経緯を後から追えない

ここで「利用者に権限を渡して各自で作ってもらう」と、スピードは上がっても統制が崩れます。反対に統制を強めるほど、申請の順番待ちは長くなります。必要なのは、スピードと統制のどちらかを選ぶことではなく、両方を同時に満たすことです。前章の仕組みは、利用者には申請だけを求め、構築と変更をテンプレートとパイプラインに任せることで、この両立を図ります。次章では、その仕組みを支える構成要素を見ていきます。

仕組みを支える構成要素

この仕組みは、特別な製品を1つ導入するのではなく、Azureに標準で備わっている機能を組み合わせて作ります。それぞれの役割は次のとおりです。

構成要素	役割	押さえどころ
Bicep（テンプレート）	払い出す構成と、命名・タグ・設定の標準をコードで定義する	申請ごとに変える値だけをパラメーターにし、それ以外は標準として固定する
Azure Pipelines	テンプレートの検証、差分の確認、デプロイを自動で実行する	承認とチェックはパイプラインの定義ファイルの外で、資源の管理者が設定する。定義を書き換えても承認は飛ばせない
Workload Identity Federation	パイプラインからAzureへの接続に使う	シークレットを保管・更新せずに接続できる。Microsoftが推奨する方式
Deployment Stacks	払い出したリソース群を1つの単位として管理する	テンプレートから外したリソースの削除・切り離しと、手動の変更・削除からの保護を担う
テンプレートスペック	承認済みのテンプレートをAzure上に保管して配布する	利用者は読み取り権限だけでデプロイでき、テンプレート自体は変更できない

Deployment Stacksがセルフサービスの要になる理由

通常のテンプレートのデプロイでは、テンプレートからリソースの定義を消しても、Azure上のリソースは残ります。これが「誰のものか分からないリソース」の温床になります。Deployment Stacksは、テンプレートで作ったリソース群をスタックという1つの単位として記録し、テンプレートから外れたリソースを削除するか、管理から切り離すだけにするかを選べます。

もう一つの特長が、拒否設定による保護です。「削除だけを禁止する」「読み取り以外の変更と削除を禁止する」といった設定をスタック単位でかけられるため、ポータルからの手動変更で構成がずれることを防げます。パイプラインで使う接続や運用担当のグループは、保護の対象から除外できます。

Azure Deployment Environmentsとは｜開発者が自分で環境を作る入口

Azure Deployment Environments（ADE）は、共通チームが用意したテンプレートの一覧から、開発者が自分で環境を作れるようにするAzureのサービスです。前章までの仕組みが「申請を受けて共通チームの側から押し出す」のに対し、ADEは「利用者が必要なときに自分で取りに行く」入口を提供します。

構成要素	役割
デベロッパーセンター	似た設定を必要とするプロジェクトをまとめる単位。カタログや環境の種類を管理する
プロジェクト	チームや業務の単位。利用者にはここでDeployment Environments Userのロールを割り当てる
カタログ	テンプレートを置いたGitHubまたはAzure Reposのリポジトリ。指定したフォルダを読み込み、環境定義を一覧にする
環境定義	IaCのテンプレートと、その説明やパラメーターを書いた環境ファイル（environment.yaml）の組み合わせ
環境の種類	開発・検証・本番前などの区分。プロジェクトごとに、デプロイ先のサブスクリプションとデプロイに使うIDを設定する

開発者に強い権限を渡さずに済む

ADEでは、環境の種類ごとに設定したマネージドIDが、開発者に代わってデプロイを実行します。開発者はデプロイ先のサブスクリプションに対する権限を持たなくても、許可されたテンプレートから環境を作れます。作成後に開発者がその環境に対してどこまで操作できるかも、環境の種類ごとに決められます。

費用と後片付け

ADEのサービス自体は無料で、作成した仮想マシンやストレージなどのリソースに通常の料金がかかります。環境には削除の予定日時を設定でき、その日時になると環境とリソースがまとめて削除されます。検証用の環境の消し忘れを防ぐのに有効です。

パイプラインからも作れる

ADEの環境は、開発者向けのポータルだけでなく、Azure CLIからも作成できます。Azure Pipelinesの中から環境を作成すれば、プルリクエストごとに一時的な検証環境を用意し、終わったら削除する、といった使い方もできます。

押し出し型とADE型、どちらから始めるか

セルフサービスの入口には、申請を受けて共通チームのパイプラインから構築する「押し出し型」と、ADEのカタログから利用者が自分で作る「ADE型」があります。どちらか一方を選ぶ必要はなく、同じテンプレートを両方の入口から使えるように作っておくのが、弊社の考え方です。

観点	押し出し型（申請＋共通パイプライン）	ADE型（カタログからセルフサービス）
入口	申請フォームと承認	開発者向けポータルまたはAzure CLI
操作する人	共通チームのパイプライン。利用者はAzureを操作しない	利用者自身。デプロイはマネージドIDが代行する
統制のかけ方	承認とチェック、what-ifによる差分の確認、デプロイ後の保護	選べるテンプレートと環境の種類、作成後の権限で制御する
向いている構成	本番環境、共通基盤、承認や記録が必須の構成	開発・検証の環境、短期間だけ使う環境
後片付け	テンプレートから外してスタックを更新、またはスタックを削除	削除の予定日時を設定して自動で削除
始めやすさ	利用者への教育が不要で、共通チームだけで始められる	利用者がポータルの使い方や環境の種類を理解する必要がある

変更管理の実装｜差分だけを反映し、証跡を残す

払い出しを自動化しても、その後の変更が手作業のままでは、構成のずれと記録の欠如は解消しません。仮想マシンのサイズ変更やディスクの追加といった変更も、新規の払い出しと同じ道筋に乗せます。

1. 変更も申請から始める

申請フォームに「新規」と「変更」の種別を設け、変更の内容と理由、影響の範囲を記入してもらいます。承認の記録は申請と一緒に保管し、後から経緯をたどれるようにします。

2. パラメーターを変えてレビューする

承認された変更は、該当する環境のパラメーターファイルを書き換え、プルリクエストとして提出します。どの値がどう変わるかがコードの差分として残るため、レビューする人も判断しやすくなります。

3. what-ifで影響を事前に確かめる

パイプラインは、デプロイの前にwhat-ifで「どのリソースが作成・変更・削除されるか」を出力します。Deployment Stacks自体にはwhat-ifがまだ提供されていないため、弊社は同じテンプレートとパラメーターで通常のデプロイのwhat-ifを実行し、その結果を承認の判断材料にしています。削除や再作成を伴う変更は、ここで見つけて止めます。

4. 承認後にスタックを更新する

Azure Pipelinesの承認とチェックを通過したら、スタックを更新します。変わった部分だけが反映され、テンプレートから外したリソースは、あらかじめ決めた設定に従って削除または切り離しになります。パイプラインの実行履歴とスタックのデプロイ履歴が、そのまま変更の証跡になります。

5. 日常の運用操作は、保護から外す設計にする

拒否設定で変更を厳しく禁止すると、日常の運用で必要な操作まで止まることがあります。読み取り以外を禁止する設定では、自動で許可されるのは読み取りなどごく一部の操作だけです。運用で必要な操作は、除外する操作として明示するか、運用担当のグループを除外の対象に指定し、実際の環境で動作を確かめてから本番に適用します。

操作の種類	扱いの例
起動・停止・再起動などの日常操作	保護の対象から除外し、運用担当が直接操作できるようにする
サイズ変更・ディスク追加・ネットワーク変更	変更の申請からパラメーターを変更し、パイプラインで反映する
不要になったリソースの削除	テンプレートから外してスタックを更新する
障害時の緊急対応	緊急用の管理者グループを除外しておき、対応後に内容をテンプレートへ反映してスタックを更新する

弊社の検証で分かった実装の注意点

弊社は、デベロッパーセンターとカタログ、Bicepの自動ビルド、what-ifとDeployment Stacksを組み合わせた払い出しの仕組みを実際に構築し、仮想ネットワーク・Key Vault・ストレージからなる標準構成の払い出しを確認しました。その過程でつまずいた点を、弊社の環境での事実として紹介します。

ランナーの指定とテンプレートの形式をそろえる

ADEの環境ファイルでARM用のランナーを指定した場合、テンプレートにBicepファイルを指定すると、環境定義が見つからないというエラーになりました。ARM用のランナーには、ビルド済みのARMテンプレート（JSON）を指定します。弊社はBicepを正本とし、変更がプッシュされるとパイプラインがJSONを自動で生成してリポジトリに反映する運用にしています。Bicep用のランナーを指定する方法もあります。

環境ファイルの説明欄は省略しない

公式のスキーマでは、環境定義やパラメーターの説明（description）は必須ではありません。しかし弊社の環境では、説明を省いた定義がスキーマのエラーとして読み込まれないことがありました。定義と各パラメーターには、説明を書いておくのが安全です。

カタログの同期結果を必ず確かめる

カタログは手動または自動で同期できますが、自動同期が一度失敗すると、手動の同期が成功するまで自動同期は再試行されません。弊社の環境では、定義を修正しても変更が反映されないことがあり、カタログをいったん削除して登録し直すと確実に反映されました。テンプレートを更新したら、同期の状態とエラーの有無を確認する手順を運用に組み込みます。

パスワードをパラメーターで受け渡さない

環境ファイルのパラメーターの型は、文字列・数値・真偽値・配列・オブジェクトなどで、パスワードのような秘密の値を安全に扱う専用の型はありません。仮想マシンの管理者パスワードなどを利用者に入力させる設計は避け、Key Vaultで生成・保管した値を参照するなど、秘密の値をパラメーターで受け渡さない設計にします。

公開モジュールはバージョンを固定する

Microsoftが公開しているBicepのモジュールを使うと、標準に沿った構成を短期間で組めます。一方で弊社の環境では、モジュールのバージョンによって、使っていない設定項目がテンプレートの検証でエラーになり、デプロイできないことがありました。モジュールはバージョンを固定し、更新するときは検証用の環境で確かめてから取り込みます。

スタックはサブスクリプション単位で置く

リソースグループ単位で作ったスタックは、そのリソースグループ自体を管理していないため、リソースグループを削除すると保護をすり抜けて中のリソースごと削除されてしまいます。Microsoftは、サブスクリプション単位でスタックを作り、リソースグループもテンプレートに含める方法を推奨しています。保護を確実に効かせたい構成では、スタックを置く単位から設計します。

小さく始める導入ステップ

最初からすべての構成をセルフサービス化する必要はありません。払い出しの頻度が高い構成を1つ選び、段階的に広げていくのが確実です。

1. よく払い出す構成を1つテンプレート化する
   命名規則、タグ、ネットワーク、監視の設定まで含めてBicepで定義し、申請ごとに変える値をパラメーターとして切り出します。
2. 押し出し型のパイプラインを動かす
   Workload Identity Federationで接続し、what-if、承認とチェック、Deployment Stacksによるデプロイまでを1本のパイプラインにします。
3. 申請と承認、記録をつなぐ
   申請フォームと承認の記録をパイプラインの起動につなぎ、利用者がAzureを操作せずに払い出しを受けられるようにします。
4. 変更の申請も同じ道筋に乗せる
   サイズ変更などの変更をパラメーターの変更として扱い、日常の運用操作は保護から外す設計を固めます。
5. 必要に応じて、利用者が自分で作れる入口を足す
   開発・検証の短期環境の依頼が増えてきたら、同じテンプレートを使ったセルフサービスの入口を検討します。

すでに手作業で構築したリソースがある場合も、テンプレートとして書き出し、what-ifで実体との差分がないことを確かめてからスタックの管理に移せば、稼働中の環境を止めずに同じ仕組みへ載せていけます。

弊社の支援｜Azureのインフラ払い出しを標準化する

弊社は、Azureの導入支援の一環として、インフラ払い出しの標準化とセルフサービス化を、設計から構築、運用の定着まで支援しています。

• 払い出しテンプレートの設計
  ランディングゾーンの考え方に沿って、ネットワーク、命名規則、タグ、監視とセキュリティの標準をテンプレートに組み込みます。
• パイプラインと承認・証跡の構築
  シークレットを置かない接続、what-ifによる差分の確認、承認とチェック、Deployment Stacksによるデプロイと保護を実装します。
• 変更管理と例外のルールづくり
  変更の申請の流れ、日常の運用操作や緊急対応の扱いを、実際の運用に合わせて決めます。
• 既存環境の取り込み
  手作業で構築したリソースをテンプレート化し、稼働を止めずに同じ仕組みへ移していきます。

サービスの詳細は「クラウド導入支援（Azure）」をご覧ください。

よくあるご質問

こちらをクリックして「よくある質問」を表示

Terraformでも同じ仕組みを作れますか？

作れます。ADEもカスタムのコンテナイメージを使うことでTerraformのテンプレートに対応できます。ただし、Deployment StacksはBicepとARMテンプレート向けの機能のため、Terraformではステートの管理によって同じようなライフサイクル管理を行うことになります。弊社は、Azureが中心の環境ではステートの管理が不要なBicepとDeployment Stacksを基本におすすめしています。

Azure PipelinesではなくGitHub Actionsでも構築できますか？

構築できます。GitHub ActionsからもOpenID Connectを使ってシークレットを保管せずにAzureへ接続でき、環境ごとの保護ルールで承認者を設定できます。すでにお使いの開発基盤に合わせて選ぶのが現実的です。

ポータルからの緊急対応はできなくなりますか？

保護の設計次第です。緊急用の管理者や運用担当をグループにまとめて保護の対象から除外しておけば、緊急時にも対応できます。除外できる対象の数には上限があるため、個人ではなくグループで指定するのがおすすめです。対応した内容は、後からテンプレートに反映してスタックを更新し、コードと実体をそろえます。

Deployment Stacksで、変更前に差分を確認できますか？

スタック自体のwhat-ifは、まだ提供されていません。弊社では、同じテンプレートとパラメーターで通常のデプロイのwhat-ifを実行して差分を確認し、その結果を承認の判断材料にしています。

Azure Deployment Environmentsの利用料金はかかりますか？

サービス自体は無料で、作成したリソースに通常の料金がかかります。検証用の環境には削除の予定日時を設定しておくと、消し忘れによる費用を防げます。

すでに手作業で構築したリソースも、この仕組みに載せられますか？

載せられます。既存のリソースをテンプレートとして書き出してBicepに変換し、what-ifで実体との差分がないことを確かめてからスタックの管理に移します。一度にすべてを移す必要はなく、重要度や変更の頻度が高いものから順に進めるのが安全です。

Azureのインフラ払い出しの標準化や、申請から構築・変更管理までの仕組みづくりのご相談は、お問い合わせよりお気軽にご連絡ください。現在の運用の進め方をお伺いしたうえで、どこから自動化すると効果が出やすいかをご提案します。

関連サービス・関連コラム

• 関連サービス：クラウド導入支援（Azure）
• 関連コラム：ゼロトラストとは｜中小企業がMicrosoft 365で始めるセキュリティ
• 関連コラム：AIエージェントに「権限」をどう与え、統制するか
• 関連コラム：ソブリンクラウドとは｜データ主権の基本と、Microsoftソブリンクラウドの3つのモデル
• 関連コラム：AI駆動開発を安全に始める

まずは無料トライアルで、効果をご確認ください

「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）や電話受注（AI-Voice）の自動化、Azure/Microsoft 365・DXのご相談まで、お気軽にどうぞ。