Azure DevOpsとAzureを安全に連携！Service Connectionの作り方を解説

Azure DevOpsのパイプラインからAzureへ自動デプロイする際、必ず必要になるのが双方を繋ぐ架け橋となる「Service Connection」です。

しかし、いざ設定しようとすると「どの認証方式を選ぶべき？」「権限エラーで進まない…」とつまずくケースが少なくありません。

そこで本記事では、Service Connectionの概要と3ステップでの作成手順を分かりやすく解説します。

「そもそもAzure DevOpsって何ができるの？」という方は、まずはこちらの概要記事をご覧ください！

Service Connectionとは？
【事前準備】必要な権限をチェック
【実践】Service Connectionを作成する3ステップ
作成したService Connectionをパイプライン（YAML）で使う
まとめ

Service Connectionとは？

Azure DevOpsを使って、Azure上にWebアプリをデプロイしたり、仮想ネットワークを構築したりする際、Azure DevOpsに対して「私の代わりにAzureを操作してね」と許可を出す必要があります。

このAzure DevOpsとAzureサブスクリプションを安全に繋ぐ「架け橋（認証設定）」のことを、「Service Connection」と呼びます。

Service Connectionを作成すると、Azure側には「サービスプリンシパル」と呼ばれる、プログラム専用の自動実行アカウント（＝鍵）が作られます。

Azure DevOpsはこの鍵を使ってAzureにアクセスし、パイプライン（YAML）に書かれたデプロイ処理を実行します。

なぜService Connectionが必要なのか

最大の理由は、「認証情報を安全に管理し、CI/CDのセキュリティを守るため」です。

もしService Connectionを使わずにパイプラインからAzureを操作しようとすると、個人のログインIDやパスワード、アクセスキーをYAMLコードの中に直接ベタ書き（ハードコーディング）しなければならなくなります。

機密情報のハードコーディングには、以下のような致命的なリスクがあります。

ソースコードから認証情報が漏洩するリスク

個人のアカウントが異動や退職で消えた瞬間に、パイプラインが動かせないリスク

パスワードの定期変更のたびに、すべてのパイプラインを書き換える手間の発生

Service Connectionを使えば、安全にAzure DevOpsとAzureを連携させることができます。

まずはこの「安全に自動化するための仕組みなんだ」というイメージを持った状態で、次の「設定に必要な権限のチェック」に進みましょう。

【事前準備】必要な権限をチェック

「Service Connectionを作成しようとボタンを押したのにエラーになる」

「そもそも設定画面のボタンがグレーアウトして押せない」

このようなトラブルは、ほぼ100%権限不足が原因です。

スムーズに設定を完了させるため、作業を始める前に、ご自身のアカウントに以下の3つの場所で必要な権限があるか、必ず確認してください。

Azure DevOps側の必要な権限

Azure DevOpsプロジェクト内でService Connectionを作成・管理するための権限が必要です。

具体的には、以下のどちらかが必要です。

対象プロジェクトの Project Administrator（プロジェクト管理者） グループに属していること。
Endpoint Administrators グループのメンバーであること。

確認方法

プロジェクトの [Project settings] を開く。
[General] -> [Permissions] をクリック。
「Users」タブから自分のアカウントを探し、所属しているグループを確認。

Permissionsを開くと以下のように、デフォルトで作成されるグループがいくつか表示されます。確認する際はグループの選択を間違えないように注意してください。

Azureサブスクリプション側の必要な権限

ここが最も重要、かつ最もつまずきやすいポイントです！

今回の記事で紹介する「Workload Identity (automatic)」方式でService Connectionを作成する場合、Azure DevOpsは裏側でAzureサブスクリプションに対して「共同作成者（Contributor）」などのロールを自動的に付与します。

「ロールを付与する（IAMの操作をする）」ためには、作業するご自身のアカウントに専用の権限が必要です。

なんの権限が必要なのか

作業を行うご自身のアカウントに、対象のAzureサブスクリプション（またはデプロイ先のリソースグループ）に対する、以下のいずれかのロール（役割）が必要です。

Owner（所有者）
User Access Administrator（ユーザーアクセス管理者）

なぜ必要か

今回の記事で紹介する最新の認証方式「Workload Identity (automatic)」は、設定ボタンをポチッと押すだけで、双方の連携を自動で行ってくれる便利な機能です。

しかし、その「自動設定」の裏側では、Azure DevOpsがAzureサブスクリプションに対して、「共同作成者（Contributor）」というロールを自動的に付与（IAM操作）しています。

Azureのセキュリティ設計上、他のアカウント（サービスプリンシパル）にロールを付与する（ IAMを操作する）際は専用の権限が必要になります。

確認方法

Azureポータルを開く。
対象のサブスクリプション（またはリソースグループ）の [アクセス制御 (IAM)] を開く。
[役割の割り当てを表示する] または「割り当て」タブで、ご自身のアカウントが「所有者」になっているか確認。

Azureポータル上でアクセス制御を開くと以下のように割り当て済みのロールが確認できます。

Microsoft Entra ID（旧Azure AD）側の権限確認

Service Connectionの作成プロセスでは、Microsoft Entra ID側にも「アプリ登録（サービスプリンシパル）」というオブジェクトが自動生成されます。

これを作成する権限があるかの確認する手順を解説します。

必要な権限

Microsoft Entra IDにおける アプリケーション（App registration）を登録する権限。

確認方法

Azureポータルで [Microsoft Entra ID] を検索して開く。
[ユーザー設定] をクリック。
「アプリの登録」セクションを確認し、「ユーザーはアプリケーションを登録できる」が 「はい」 になっているか確認する。

企業のセキュリティポリシーで、管理者が「いいえ」に設定している場合は。一般ユーザーはService Connectionの「自動作成」ができません。

これですべての事前準備が整いました。次の章では、実際にService Connectionを作成していきましょう。

【実践】Service Connectionを作成する3ステップ

事前準備が整ったら、いよいよ設定に入ります。

今回は、現在Microsoftが最も推奨している「Workload Identity (automatic)」という方式で、安全かつ簡単に作成する手順を解説します。

ステップ1：Azure DevOpsの「Project settings」を開く

まずは、Azure DevOpsのプロジェクト画面を開きます。

Object moved

上記URLから自身のプロジェクトにログインします。

画面左下のサイドバー一番下にある [Project settings] （歯車アイコン）をクリックします。
設定メニューが開いたら、[Pipelines] グループの中にある [Service connections] をクリックします。
画面中央または右上の [Create service connection] （または [New service connection]）ボタンをクリックします。

ステップ2：新規接続の作成と「Workload Identity (automatic)」の選択

次に、どのような接続を作るかを選択します。

右側に表示されるリストから [Azure Resource Manager] を選択し、[Next] をクリックします。
認証方式（Identity Scheme）の選択画面になります。ここで [Workload Identity (automatic) (recommended)] を選択して、[Next] をクリックします。

💡 ポイント

以前主流だった「Service Principal (automatic)」は、シークレットの管理が必要なため、現在はWorkload Identity方式が推奨されています。

ステップ3：サブスクリプションの選択とスコープの決定

最後に、どのAzureリソースを操作できるようにするかを具体的に設定します。

Azureへのサインイン： 認証を求められたら、事前準備で確認した「所有者」権限を持つアカウントでサインインします。
Scope level（スコープ）： 通常は [Subscription] を選択します。
Subscription / Resource group： 連携したい [Subscription] をドロップダウンから選択します。 [Resource group] は空欄のままでも構いませんが、特定の範囲に限定したい場合は選択してください。
Service Connection Name： パイプライン（YAML）から呼び出す際の名前を付けます（例：AIT-Azure-Connection）。
Security（セキュリティ）： [Grant access permission to all pipelines] にチェックを入れます。これにチェックを入れることで、このプロジェクト内のすべてのパイプラインがこの接続を使えるようになります。
保存： [Save] をクリックして完了です！

これで、Azure DevOpsとAzureを繋ぐ「Service Connection」の作成が完了しました。

作成したService Connectionをパイプライン（YAML）で使う

Service Connectionの作成が完了したら、次はいよいよ実際のCI/CDパイプライン（YAMLコード）から呼び出して、Azureを操作してみましょう。

設定自体は非常にシンプルで、パイプラインのタスク内で「作成したService Connectionの名前」を指定するだけです。具体的なコード例と、実務で役立つ運用ノウハウを解説します。

YAMLでの具体的な記述例

Azureを操作する代表的なタスクである AzureCLI@2（Azure CLIを実行するタスク）を例に解説します。

先ほど作成したService Connection名（例: AIT-Azure-Connection）を、azureSubscription という項目に指定します。

trigger:
  - main

pool:
  vmImage: 'ubuntu-latest'

steps:
# Azure CLIを使って操作を実行するタスク
- task: AzureCLI@2
  displayName: 'Azureリソースグループ一覧の取得'
  inputs:
    # ★ここに作成したService Connectionの名称を入力します
    azureSubscription: 'AIT-Azure-Connection' 
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    # 実行したいAzure CLIコマンドを記述
    inlineScript: |
      az group list --output table

このように、生のパスワードやシークレットを一切記述することなく、安全にAzureサブスクリプションへアクセスしてコマンドを実行することができます。

ARMテンプレートのデプロイ（AzureResourceManagerTemplateDeployment@3）や、Webアプリへのデプロイ（AzureWebApp@1）など、他のAzure系タスクでも同様に azureSubscription 項目に名前を指定するだけでOKです。

パイプライン実行時に「Permit」を求められたときの対処法

パイプラインを初めて実行した際、ジョブが開始されずに「There are authorization issues…」という警告メッセージが表示され、パイプラインが一時停止することがあります。

これは、「このパイプラインがService Connectionを使用することを許可してよいか？」をAzure DevOpsが確認しているセキュリティ機能です。

対処方法：

警告メッセージの右側にある [View] ボタンをクリックします。
ポップアップが表示されるので、[Permit]（許可） をクリックします。
許可されると、保留状態だったパイプラインが自動的に動き出します。

💡 Service Connectionの作成時に「Grant access permission to all pipelines」にチェックを入れておくと、この「Permit」の確認手順をスキップして最初から自動実行させることができます。

複数環境（Dev/Prod）でService Connectionを使い分けるコツ

実務のシステム開発では、「開発環境（Dev）」と「本番環境（Prod）」でAzureサブスクリプションやリソースグループを完全に分離するのが鉄則です。

それに伴い、Service Connectionも環境ごとにそれぞれ作成（例: AIT-Azure-Dev-Conn と AIT-Azure-Prod-Conn）し、パイプライン側で動的に切り替えるように構成するのがスマートです。

中級エンジニア向けにおすすめの、「変数（Variables）を使って、デプロイ先に応じてService Connectionを切り替える記述例」をご紹介します。

# パイプライン内で使用する変数の定義
variables:
  # 実行ブランチやトリガーに応じて切り替える設定（例として開発環境をデフォルトに指定）
  ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}:
    envName: 'prod'
    azureConn: 'AIT-Azure-Prod-Conn' # 本番用Service Connection
  ${{ else }}:
    envName: 'dev'
    azureConn: 'AIT-Azure-Dev-Conn'  # 開発用Service Connection

steps:
- task: AzureCLI@2
  displayName: '環境に応じたAzure操作の実行'
  inputs:
    # ★変数を使って動的にService Connectionを切り替える
    azureSubscription: '$(azureConn)' 
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      echo "現在のデプロイ環境: $(envName)"
      az group list --output table

このように設計しておくことで、同じYAMLコードのまま、「developブランチのときは開発環境へ」「mainブランチのときは本番環境へ」安全かつ自動的に出し分ける、実用的なCI/CDパイプラインを構築することができます。

これで、作成したService Connectionを実際にパイプラインでフル活用できるようになりました。

まとめ

この記事では、Azure DevOpsとAzureサブスクリプションを安全に連携させる「Service Connection（サービス接続）」について、概念から実践的な設定、そして実務に耐えうるセキュリティ運用までを解説しました。

特に重要なポイントは以下の3点です。

推奨方式を選ぶ: シークレットレスで安全な「Workload Identity」を利用する。
事前権限の確認: 作成エラーを防ぐため、Azure側で「所有者」権限を確保する。
利用制限をかける: 本番環境の事故を防ぐため、パイプラインの承認設定などを必ず行う。

権限と仕組みさえ理解すれば、設定はとても簡単です。まずは開発環境用の接続を作り、安全な自動デプロイ環境を構築してみてください！