Azure Data FactoryとAzure DevOps Git連携の権限設定完全ガイド｜Create repositoryは本当に必要か？

Azure Data Factory(ADF)をAzure DevOpsのGitと連携しようとしたとき、「権限が足りません」「リポジトリを作成できません」といったエラーで止まっていないでしょうか。本記事では、どの権限が本当に必要なのか、Create repositoryは必須なのか、既存パイプラインを安全にGitへ取り込む手順まで、現場目線で詳しく解説します。

Azure Data FactoryとAzure DevOps Git連携の全体像

まずは、Azure Data Factory(ADF)とAzure DevOps Gitを連携したときに何が起こるのか、ざっくりと整理します。

ADFのパイプライン・データセット・データフロー・リンクサービスなどの定義が、Azure DevOpsのGitリポジトリ上でJSONファイルとして管理される。
ADF Studioから行った編集は、指定したコラボレーションブランチ(例: main や develop)にコミットされる。
Publish(発行)ボタンを押すと、adf_publishブランチにデプロイ用テンプレート(ARM/Bicep)が自動生成・プッシュされる。
CI/CD環境では、多くの場合 adf_publish ブランチをトリガーに、テスト・本番環境へデプロイするパイプラインが組まれる。

この構成により、ADFの変更がGitの履歴として残り、レビューやロールバック、環境間の自動デプロイがしやすくなります。しかし、その分GitリポジトリとADFリソースの両方で適切な権限設定が必須になります。

Azure DevOps側で必要なGit権限の整理

質問として特に多いのが、次の3点です。

「どの権限があればADFからGit接続できるのか？」
「Create repositoryは必須なのか？」
「既存プロジェクト／既存リポジトリがある場合はどう考えればいいのか？」

最初に要点を表で整理します。

シナリオ	権限スコープ	最低限必要な権限	備考
ADFセットアップ時に新規リポジトリを作成	プロジェクト単位 (Project level)	Create repository = Allow	プロジェクトの「Project」ノードに対して必要。一般開発者には付与されていないことが多い。
既存リポジトリに接続(推奨)	リポジトリ単位 (Repository level)	Read = Allow Contribute = Allow Create branch = Allow	collaborationブランチや `adf_publish` ブランチをADFが自動作成・更新するために必要。

つまり、既存リポジトリを使う場合に「Create repository」権限は不要です。むしろ、多くの組織ではプロジェクト管理者だけがリポジトリ作成権限を持ち、開発者は既存リポジトリを使う、という運用になっているはずです。

新規リポジトリをADFから作成する場合

ADFのGit構成ウィザードでは、「接続先リポジトリを新規作成する」こともできます。この場合、次の条件を満たす必要があります。

Azure DevOpsのプロジェクト設定で、対象ユーザーまたは所属グループに対して
- Create repository = Allow
権限の設定場所:
- Project settings → Repositories → Security → Project(プロジェクトノード) を選択

実務では、セキュリティとリポジトリ命名ルールの観点から、開発者が勝手にリポジトリを増やさない運用が多いため、このパターンはあまり採用されません。プロジェクト管理者が事前にリポジトリを作成しておき、ADF開発者は既存リポジトリに接続する、という形が現実的です。

既存リポジトリにADFを接続する場合(推奨構成)

最も一般的かつ推奨されるのは、Azure DevOps側であらかじめ用意したリポジトリにADFを接続するパターンです。この場合、必要な権限はシンプルです。

対象リポジトリの Security 設定で、ADF開発者(または所属グループ)に以下を付与:
- Read = Allow
- Contribute = Allow
- Create branch = Allow

Contribute はコミット・プッシュに必要、Create branch はコラボレーションブランチや adf_publish ブランチを作るために必要です。ADFのPublishでは、adf_publish に対して直接プッシュを行うため、ブランチポリシーで「直接プッシュ禁止」にしている場合は例外設定も検討します(これについては後述します)。

コラボレーションブランチと adf_publish ブランチの役割

ADFをGit連携すると、典型的には次のようなブランチ構成になります。

ブランチ	役割	主な更新者	補足
main / develop など	コラボレーションブランチ(開発ブランチ)	ADF開発者	ADF Studioでの編集内容がコミットされる。PR運用を行う場合は別ブランチを切ってマージする構成も可。
adf_publish	発行用ブランチ(デプロイテンプレート)	ADF(=Publish操作を行ったユーザー)	ARM/Bicepテンプレートとパラメータファイルが生成され、CI/CDパイプラインの入力として利用される。

このように、ADFは自分でブランチを作成・更新するため、少なくとも Create branch と Contribute が必要だという点を押さえておきましょう。

Azure側(ADFリソース側)で必要なロール

Azure側では、ADFリソースに対してどのRBACロールを持っているかが重要です。特に「パイプラインを編集してPublishできるかどうか」は、Azure DevOpsではなくAzure RBACで決まります。

ロール名	ADFに対してできること	Git連携との関係
Data Factory Contributor (データファクトリ共同作成者)	ADFの作成・更新・削除、パイプライン/データセットなどの編集・Publishが可能。	本記事の前提となる最低限のロール。通常はリソースグループ単位で付与。
Contributor	対象リソースグループ内のほぼ全てのリソースを作成・更新・削除可能。アクセス権限の変更は不可。	Data Factory Contributorより強い権限。ADF以外のリソースも操作できるため、権限配布には注意。
Owner	Contributorの操作に加え、RBAC権限の付与・剥奪が可能。	運用管理者・サブスクリプション管理者向け。一般のADF開発者には不要。

結論として、ADFリソースに対しては「Data Factory Contributor」以上のロールがあれば、Git連携の前提となる「パイプラインの編集とPublish」が可能です。実務では、リソースグループ単位で Data Factory Contributor を付与しておくケースが多いでしょう。

既存リポジトリへ接続し、ADFリソースを取り込む手順

次に、実際に既存リポジトリへ接続し、すでに作成済みのパイプラインやデータセットを取り込む手順を、画面遷移とともに整理します。

前提条件のチェック

Azure DevOps
- 対象プロジェクトとリポジトリが作成済み。
- 対象リポジトリのSecurityで、自分(または所属グループ)に
  - Read = Allow
  - Contribute = Allow
  - Create branch = Allow
  が設定されている。
Azure
- 対象のADFリソースに対して Data Factory Contributor 以上のロールが付与されている。

ADF StudioからのGit構成手順

ブラウザでADF Studioを開きます。(Data Factoryのメニューから「Author & Monitor」など)
左メニューの管理(Manage) → Git 構成(Git configuration) を開きます。
構成(Configure) ボタンを押し、Gitのセットアップウィザードを開始します。
Git プロバイダで「Azure DevOps Git」を選択します。
Azure DevOpsの「組織」「プロジェクト」を選択し、既存リポジトリを指定します。
コラボレーションブランチとして使用するブランチを指定します。(例: main)
「既存のリソースをリポジトリにインポート」(Import existing resources to repository) をオンにします。
必要に応じてルートフォルダを指定します。(例: /, /adf, /src/adf など)
内容を確認し、保存(Save)をクリックします。

ここで「既存のリソースをリポジトリにインポート」をオンにしておくことが、既にADF上に存在するパイプラインやデータセットをGit管理に移行するためのポイントです。

インポート後のディレクトリ構成のイメージ

インポートが成功すると、指定したルートフォルダ配下に、次のような構成でJSONファイルが配置されます。

/adf
  /pipeline
    MyPipeline1.json
    MyPipeline2.json
  /dataset
    ds_source.json
    ds_sink.json
  /linkedService
    ls_storage.json
  /dataflow
    df_transform1.json

JSONの中身は、ADFポータルで見ているパイプライン定義そのものです。例えば、単純なパイプラインは次のようなイメージです。

{
  "name": "pl_example_copy",
  "properties": {
    "activities": [
      {
        "name": "CopyFromBlobToSql",
        "type": "Copy",
        "dependsOn": [],
        "typeProperties": {
          "...": "..."
        }
      }
    ]
  }
}

このJSONをGitでレビューしたり、ブランチを切って変更差分を比較したりできるようになります。

Publish(発行)の実行と adf_publish ブランチ

Git接続とインポートが完了したら、ADF Studioの上部にあるPublish(発行)ボタンを押します。すると、次の2つが行われます。

コラボレーションブランチ上の最新JSON定義をもとに、Data Factoryの「ライブ」環境が更新される。
adf_publish ブランチが自動作成され、デプロイ用テンプレート(ARM/Bicepおよびパラメータファイル)がコミット・プッシュされる。

以後、CI/CDパイプラインからはこの adf_publish ブランチを参照して、テスト/本番環境に展開する形が一般的です。

フォルダ構成・ブランチ戦略のおすすめ例

権限だけでなく、フォルダ構成やブランチ戦略をあらかじめ決めておくと、運用がかなり楽になります。

フォルダ構成のパターン

パターン	ルートフォルダ例	特徴	向いているケース
シンプル	`/`	リポジトリ直下に `pipeline`, `dataset` などが並ぶ。構成はシンプルだが、リポジトリをADF専用にする前提。	ADF専用のリポジトリを1つ用意できる小〜中規模チーム。
ADF専用ディレクトリ	`/adf`	他のIaCコード(例: Bicep, Terraform)と同じリポジトリ内にADFを共存させるのに適している。	インフラコードとアプリ/データパイプラインを同居させたいチーム。
モノレポ連携	`/src/datafactory/adf`	アプリケーションコードや他のDWH定義(SQL, dbtなど)と一つの大きなリポジトリで管理する構成。	大規模組織や、モノレポ戦略を採っているチーム。

ブランチ戦略の一例

main: 本番相当の定義。通常はADF Studioのコラボレーションブランチとし、PRを通してのみ更新。
feature/xxx: 開発者ごとの作業ブランチ。ADF StudioのGitモードでこのブランチを選択し、ローカルな作業を行う。
adf_publish: Publishボタンでのみ更新されるブランチ。CI/CDパイプラインのトリガーとして利用。

このように分けることで、開発中の変更と本番相当の定義、そしてデプロイ用テンプレートを明確に分離できます。

よくあるつまずきと対処方法

ここからは、実際の現場でよく起こるトラブルと、その原因・対処パターンを整理します。

セットアップ時に「権限不足」「リポジトリ作成不可」で失敗する

症状の典型例

Git構成ウィザードでリポジトリを選択しても、「アクセスが拒否されました」系のエラーが表示される。
「リポジトリを作成できません」「プロジェクトに対する権限が不足しています」といったメッセージが出る。

チェックポイント

新規リポジトリを作成しようとしていないか？
- 新規作成を選ぶと Create repository が必須です。
- 既存リポジトリがあるなら、必ず「既存リポジトリを使用」を選択しましょう。
既存リポジトリを選んでいる場合
- 対象リポジトリのSecurityで、ユーザーまたはグループに
  - Read = Allow
  - Contribute = Allow
  - Create branch = Allow
  が付与されているか確認。
- 「Deny」がどこかのグループで設定されていないかも要チェックです。(DenyはAllowより優先されます)

Publishで adf_publish へのプッシュが弾かれる

症状の典型例

Git接続や編集はできるが、Publishすると「ブランチにプッシュできません」系のエラーが出る。
Azure DevOps側のブランチポリシーで、adf_publish に対する直接プッシュが禁止されている。

原因と対処

理由:
- 組織ポリシーで「保護ブランチにはPR経由のみ」「全ブランチの直接プッシュ禁止」としている場合、ADFが自動で行う直接プッシュもブロックされるため。
対処案:
- adf_publish ブランチに限り、
  - 直接プッシュを許可する例外ルールを作成する。
  - または、ADF Publish用のサービスアカウント(または専用グループ)だけがポリシーバイパスできるようにする。
- 組織ポリシー上、どうしても例外が作れない場合は、adf_publish 相当のテンプレートを別の仕組み(例: 自前でARM/Bicepを生成)で用意する必要がありますが、運用負荷が高くなります。

ブランチ作成だけが失敗する

症状の典型例

Git接続はできるが、初回のPublishや新しいコラボレーションブランチの切り替え時にエラーが出る。
Azure DevOps側で「Create branch が拒否されている」旨のメッセージが表示される。

チェックポイント

対象リポジトリのSecurityで、ユーザーまたは所属グループに対して
- Create branch = Allow
が設定されているか。
別のグループや「Project valid users」などで Deny が設定されていないか。
ブランチポリシーで「ブランチの作成禁止」や、「特定のパス以外のブランチ名を禁止」など、制約がかかっていないか。

運用に即した権限チェックリスト

ここまでの内容を、実際の運用で確認しやすいようにチェックリスト形式にまとめます。

観点	確認する場所	確認すべきポイント
リポジトリ作成可否	Azure DevOps → Project settings → Repositories → Security → Project	新規リポジトリをADFから作成したい場合のみ、 Create repository = Allow
既存リポジトリへの接続	Azure DevOps → 対象リポジトリ → Security	ユーザーまたはグループに Read = Allow Contribute = Allow Create branch = Allow が設定されている。どこかで Deny が設定されていない。
adf_publishのブランチポリシー	Azure DevOps → Repos → Branches → adf_publish → Branch policies	ADFからの直接プッシュを禁止していないか。必要であれば、ADF Publish用アカウント/グループだけポリシーバイパスを許可。
ADFリソースのロール	Azure Portal → ADFリソース → アクセス制御(IAM)	対象ユーザー/グループに Data Factory Contributor 以上のロールが付与されている。

権限設計のベストプラクティス例

最後に、現場で採用されやすい権限設計の例を紹介します。必ずしも唯一の正解ではありませんが、検討の叩き台として活用できます。

小規模チーム(開発者数名)の場合

Azure DevOps
- プロジェクト管理者が事前に adf-dev などのリポジトリを作成。
- 開発者は共通グループ(例: ADF Developers)に所属し、そのグループに対して
  - Read = Allow
  - Contribute = Allow
  - Create branch = Allow
  を付与。
- adf_publish への直接プッシュは許可し、ブランチポリシーは軽めに設定。
Azure
- 開発用サブスクリプション/リソースグループに対し、開発者グループへ Data Factory Contributor を付与。

中〜大規模チーム(レビュー必須)の場合

Azure DevOps
- コラボレーションブランチを develop に設定し、main は保護ブランチとしてPR必須にする。
- 開発者は feature/xxx ブランチで作業し、PRで develop へマージ。
- adf_publish は develop からのPublishのみ許可し、Publish操作ができるのは限定されたグループ(リードエンジニアなど)にする。
Azure
- 開発環境ADF: 開発者に Data Factory Contributor。
- テスト/本番ADF: 運用チームのみに Data Factory Contributor を付与し、デプロイはCI/CDパイプラインからのみ行う。

このように、「誰がどの環境に対して編集・Publishできるか」を明確に切り分けると、誤操作や無断変更のリスクを大きく減らせます。

まとめ

最後に、冒頭の質問に対する答えを簡潔にまとめます。

どの権限が必要か？
- Azure DevOpsの既存リポジトリを使う場合は、リポジトリ単位で
  - Read
  - Contribute
  - Create branch
  があればADFから接続可能です。
- Azure側では、ADFリソースに対して Data Factory Contributor 以上のロールが必要です。
既存プロジェクト／既存リポジトリがある場合に「Create repository」は必須か？
- いいえ、不要です。
- 「Create repository」が必要なのは、ADFのセットアップ時に新規リポジトリを作成したい場合だけです。
- 多くの組織では、プロジェクト管理者だけがこの権限を持ち、開発者は既存リポジトリを利用する運用になっています。
ADF側の既存パイプラインやデータセットをリポジトリへ取り込む方法は？
- ADF Studio → 管理(Manage) → Git構成(Git configuration) → 構成(Configure) で、Azure DevOps Git を選択。
- 既存プロジェクト/既存リポジトリとコラボレーションブランチを指定し、 「既存のリソースをリポジトリにインポート」 をオンにして保存。
- その後、Publish を実行すると、JSONがリポジトリにコミットされ、adf_publish ブランチも作成されます。

このポイントさえ押さえておけば、「Create repositoryは本当に必要か？」という疑問には、既存リポジトリを使うなら不要、新規作成するなら必要と自信を持って回答できるはずです。自組織のセキュリティポリシーや運用体制に合わせて、ここで紹介した権限設計やチェックリストをカスタマイズし、安心してADFとAzure DevOps Gitの連携を進めてください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Data FactoryとAzure DevOps Git連携の権限設定完全ガイド｜Create repositoryは本当に必要か？

Azure Data FactoryとAzure DevOps Git連携の全体像