Azure DatabricksでGitHub、GitLab、Azure DevOps Services、Bitbucketなどのリポジトリを使う場合、結論から言うと「個人開発はユーザーのGit資格情報」「JobsやCI/CDなどの自動化はサービスプリンシパル」を分けて設計することが重要です。Microsoft Learnの「Connect your Git provider to Databricks」は、Azure DatabricksのGit foldersからリモートリポジトリへ接続するための認証設定を整理した公式情報で、2026年5月7日前後に確認された更新では、GitHub App、PAT、Microsoft Entra ID、サービスプリンシパル、Bitbucketの移行注意点まで押さえる必要があります。なお、Microsoft Learn上の最終更新日は2026年5月6日と表示されています。(Microsoft Learn)
この記事では、Microsoft Azure上のAzure Databricksを運用する管理者・開発者向けに、何が実務上の確認ポイントになるのか、どの設定を見直すべきか、移行や展開で失敗しやすい箇所を具体的に整理します。
Connect your Git provider to Databricksは何をする設定か
「Connect your Git provider to Databricks」は、Azure DatabricksのワークスペースでGit foldersを使い、GitHubやAzure DevOps Servicesなどのリモートリポジトリに接続するためのGit資格情報を設定する手順です。
Azure Databricks Git foldersは、ワークスペース内でGitリポジトリを扱うためのビジュアルGitクライアント兼APIです。ノートブックやファイルをGitでバージョン管理しながら、開発、共同作業、CI/CDに利用できます。(Microsoft Learn)
ポイントは、単に「DatabricksからGitをcloneできるようにする」だけではないことです。以下のような運用に直接関わります。
| 観点 | 影響する内容 |
|---|---|
| 開発作業 | ノートブックやPythonファイルをGit foldersで編集、commit、pushする |
| 認証管理 | GitHub App、PAT、Microsoft Entra ID、API tokenなどを使い分ける |
| 自動化 | Jobs、Repos API、CI/CDで使う資格情報をサービスプリンシパルに寄せる |
| セキュリティ | Git URL allowlist、監査ログ、シークレット検出、顧客管理キーを確認する |
| 移行対応 | Bitbucket app passwordなど、廃止予定の認証方式を置き換える |
公開リポジトリをcloneするだけならGit資格情報が不要な場合がありますが、プライベートリポジトリを扱う場合や書き込み操作を行う場合は、書き込み権限を持つ資格情報が必要です。(Microsoft Learn)
今回の実務上のポイントは「認証方式の選び方」にある
今回の公式情報で管理者が最初に見るべきなのは、Git providerごとの認証方式です。特にGitHub、Azure DevOps Services、Bitbucketでは、推奨される方式や移行判断が異なります。
| Git provider | 推奨・基本の認証方式 | 管理者が確認すべきこと |
|---|---|---|
| GitHub | Databricks GitHub App、またはPAT | Hosted GitHubではGitHub Appを優先。GitHub Enterprise ServerやEnterprise Managed UsersではPATが必要になる |
| GitLab | Personal access token、必要に応じてproject access token | tokenのscopeを最小限にし、対象プロジェクトを明確にする |
| Azure DevOps Services | 同一Microsoft Entra IDテナントならEntra ID認証、異なるテナントならPAT | Azure DatabricksとAzure DevOps組織のテナント関係、ネットワーク到達性を確認する |
| Bitbucket | CloudではAPI token、サービスプリンシパルではaccess tokenを検討 | app passwordを使っている場合は廃止予定に備えて移行する |
| その他のGit provider | GitHubを選択してPATを入力する方法が使える場合がある | 動作は保証されないため、clone、pull、commit、pushを検証する |
GitHubについては、Hosted GitHubアカウントではDatabricks GitHub Appが推奨されています。OAuth 2.0を使い、トークンを自動更新でき、特定リポジトリにアクセス範囲を絞れるためです。一方で、GitHub Enterprise ServerではGitHubアカウント連携がサポートされず、Enterprise Managed UsersもユーザーアカウントへGitHub Appsをインストールできないため、PATを使う必要があります。(Microsoft Learn)
Azure DevOps Servicesでは、Azure DatabricksとAzure DevOps組織が同じMicrosoft Entra IDテナントにリンクされている場合、Microsoft Entra IDによる認証を利用できます。異なるテナントの場合は、Azure DevOpsのPATを使う判断になります。加えて、Microsoft Entra IDのサービスエンドポイントがAzure Databricksワークスペースのプライベートサブネットとパブリックサブネットの両方から到達可能であることも確認が必要です。(Microsoft Learn)
Bitbucket Cloudではapp passwordの扱いに注意が必要です。公式情報では、AtlassianがBitbucketのapp passwordを段階的に廃止し、2026年6月9日に完全廃止予定であることが示されています。既存環境でapp passwordを使っている場合は、API tokenへの移行計画を早めに作るべきです。(Microsoft Learn)
影響範囲：管理者・開発者・DevOps担当で確認点が違う
この更新は、Git接続設定を行う開発者だけでなく、ワークスペース管理者、セキュリティ担当、CI/CD担当にも影響します。
| 対象者 | 主な影響 | すぐ確認すべきポイント |
|---|---|---|
| Azure Databricks管理者 | ワークスペース全体のGit接続ポリシーに影響 | Git foldersの有効化、Git URL allowlist、アクセス権限、監査ログ |
| 開発者 | Git credentialsの登録方法が作業効率に影響 | Settings > Linked accountsで正しいprovider、email、tokenを設定しているか |
| DevOps・CI/CD担当 | JobsやRepos APIの実行主体に影響 | 個人PATではなくサービスプリンシパルに移行できているか |
| セキュリティ担当 | token管理とリポジトリ制限に影響 | PATのscope、有効期限、顧客管理キー、secret detection、URL allowlist |
| Bitbucket利用チーム | 認証方式の廃止対応が必要 | app passwordをAPI tokenまたはaccess tokenへ移行する計画があるか |
特に見落としやすいのは、Databricksがユーザーごとに複数のGit credentialsを保存できる点です。各Git providerにはユーザーごとに1つのデフォルト資格情報があり、Jobs、Repos API、Git folder操作で特定の資格情報が指定されていない場合はデフォルトが使われます。また、ユーザーごとのGit credentialsは最大10個で、非デフォルト資格情報をJobsで使う必要がある場合はサービスプリンシパルを使う必要があります。(Microsoft Learn)
開発者が行う基本設定
開発者が手動でGit foldersを使う場合は、Azure Databricksのユーザー設定からGit credentialsを登録します。
| 手順 | 操作 | 注意点 |
|---|---|---|
| 1 | Azure Databricksワークスペース右上のユーザー名からSettingsを開く | ワークスペースごとに設定場所を確認する |
| 2 | Linked accountsを開く | 既存のGit credentialsがある場合は重複に注意する |
| 3 | Add Git credentialを選択する | providerを間違えるとcloneやpushで失敗する |
| 4 | Git providerを選択する | GitHub App連携が使える場合はPATより優先する |
| 5 | email、token、usernameなど必要項目を入力する | commit authorの表示に影響する |
| 6 | clone、pull、commit、pushをテストする | 認証成功だけでなく書き込みまで確認する |
Git commit identityも重要です。Azure Databricksでは、Git credentialsに設定したemailがGIT_AUTHOR_EMAILとGIT_COMMITTER_EMAILに、usernameがGIT_AUTHOR_NAMEとGIT_COMMITTER_NAMEに使われます。emailを正しく設定しないと、Git provider上でコミット作成者が正しく紐づかないことがあります。過去にemail設定が利用できる前に作成した資格情報では、email欄がusernameのままになっている場合があるため、既存ユーザーも確認しておくべきです。(Microsoft Learn)
管理者が確認すべき設定
Git URL allowlistを使って接続先を制御する
ワークスペース管理者は、Git URL allowlistを使ってユーザーがアクセスできるリモートリポジトリを制限できます。これは、意図しない外部リポジトリへのコード流出を防ぐうえで有効です。
選択肢としては、制限なし、clone・commit・pushすべてを制限、commit・pushのみを制限する、といった運用が考えられます。URLはprefix matchingで判定され、wildcardはサポートされません。たとえば、全GitHubを許可するのではなく、https://github.com/CompanyNameのように組織単位へ絞ると管理しやすくなります。URLにユーザー名や認証tokenを含めないことも重要です。 (Microsoft Learn)
JobsやCI/CDはサービスプリンシパルを使う
個人ユーザーのPATでJobsやCI/CDを動かすと、退職、異動、パスワード変更、token期限切れの影響を受けやすくなります。Microsoft Learnでも、Jobs、CI/CD pipelines、その他の自動化ワークフローでは、ユーザーではなくサービスプリンシパルを使うことが推奨されています。(Microsoft Learn)
サービスプリンシパルにGit credentialsを紐づける場合、ワークスペース管理者がSettingsのIdentity and accessから対象サービスプリンシパルを選び、Git integrationタブでGit credentialを追加します。Databricks CLIを使ってサービスプリンシパル用のGit credentialを作成することもできます。(Microsoft Learn)
Azure DevOpsとMicrosoft Entra IDを組み合わせた自動化では、Azure Databricks側でMicrosoft Entra ID managed service principalを設定し、Azure側でfederated credentialsを構成する流れになります。サービスプリンシパルにはAzure DevOps組織でBasic以上のアクセスレベルが必要で、Azure Databricks側でも必要なユーザーにService Principal User権限を付与する必要があります。(Microsoft Learn)
プライベートGitサーバーはネットワーク到達性を確認する
GitHub Enterprise Server、Bitbucket Server、GitLab Self-Managed、オンプレミスGitサーバーなどを使う場合は、認証情報だけでは不十分です。Databricks側からGitサーバーへ到達できるネットワーク構成が必要になります。
インターネット公開されているGit serverでIP allowlistを使っている場合は、Azure Databricksのcontrol plane NAT IPをGit server側の許可リストへ追加します。プライベートGitサーバーの場合は、Git server proxyやServerless Private Git、NCCなどの構成を確認する必要があります。(Microsoft Learn)
セキュリティ機能をセットで確認する
Git接続設定を展開するときは、認証だけでなくセキュリティ機能も同時に確認します。Azure Databricks Git foldersでは、Git credentialsを顧客管理キーで暗号化する構成、Git URL allowlist、アクセス制御、監査ログ、シークレット検出などを利用できます。監査ログを有効にすると、Git foldersの作成、更新、削除、一覧取得、リモートリポジトリとの同期などを記録できます。(Microsoft Learn)
移行・展開で失敗しやすいポイント
| 失敗例 | 起きやすい状況 | 対策 |
|---|---|---|
| 個人PATで本番Jobsを動かしている | 最初に開発者が手早く設定した環境をそのまま本番化した | JobsやCI/CDはサービスプリンシパルへ移行する |
| GitHub Appを使えない環境でApp連携を前提にする | GitHub Enterprise ServerやEnterprise Managed Usersを利用している | PATまたはfine-grained PATの利用可否を確認する |
| Azure DevOpsのテナント条件を見落とす | Azure DatabricksとAzure DevOps組織が別テナント | PAT利用、またはEntra ID連携設計を見直す |
| commit authorが正しく表示されない | Git credentialsのemailがusernameのまま | Linked accountsでemailを実メールアドレスに修正する |
| allowlist設定後にcloneできない | custom CNAMEやURL aliasを使っている | 実際に使うURL prefixをallowlistへ追加する |
| Bitbucket app passwordの廃止対応が遅れる | 既存の接続が動いているため後回しにする | 2026年6月9日より前にAPI tokenへ移行し、検証する |
| プライベートGitに接続できない | 認証tokenだけ設定し、ネットワーク経路を作っていない | IP allowlist、Git server proxy、NCC、Private Git構成を確認する |
特に本番環境では、「cloneできたから完了」と判断しないことが大切です。実際には、pull、branch切り替え、commit、push、Jobsからの実行、Repos API経由の操作まで確認して初めて運用可能と判断できます。
管理者向けの展開チェックリスト
Azure DatabricksのGit接続設定をチームへ展開する場合は、次の順序で確認すると手戻りを減らせます。
| 順序 | 確認項目 | 完了条件 |
|---|---|---|
| 1 | 利用するGit providerを棚卸しする | GitHub、Azure DevOps、Bitbucketなどの利用チームが分かっている |
| 2 | 認証方式を決める | GitHub App、PAT、Entra ID、API token、サービスプリンシパルの使い分けが決まっている |
| 3 | 自動化アカウントを整理する | JobsやCI/CDで個人資格情報を使っていない |
| 4 | Git URL allowlistを設計する | 許可する組織、プロジェクト、リポジトリURLが明確になっている |
| 5 | ネットワーク要件を確認する | プライベートGit、IP allowlist、VNet、NCCの要否が判断済み |
| 6 | 既存credentialsを点検する | email、token期限、scope、デフォルトcredentialが確認済み |
| 7 | 検証手順を作る | clone、pull、commit、push、Jobs実行までテストできる |
| 8 | 運用ルールを文書化する | token更新、退職者対応、権限変更、監査ログ確認の担当が決まっている |
展開時のおすすめは、まず非本番ワークスペースで1つの代表リポジトリを使って検証することです。そこで認証方式、allowlist、commit identity、Jobs実行まで確認し、問題がなければ本番ワークスペースへ段階的に展開します。
開発チームに伝えるべき運用ルール
開発者向けには、細かい認証方式の説明よりも「どの場面で何を使うか」を明確にしたほうが定着します。
| 利用シーン | 推奨ルール |
|---|---|
| 個人の検証・開発 | 自分のGit credentialをLinked accountsに登録する |
| GitHub.comの通常利用 | 可能ならDatabricks GitHub Appを使う |
| プライベートリポジトリへの書き込み | 必要なscopeだけを持つPATまたはOAuth credentialsを使う |
| 本番Jobs・CI/CD | 個人PATではなくサービスプリンシパルを使う |
| 複数アカウント・複数provider | デフォルトcredentialがどれかを確認してから操作する |
| 退職・異動・権限変更 | 個人credentialに依存しているJobsやGit foldersがないか確認する |
このルールをチームのオンボーディング資料に入れておくと、「ローカルではpushできるがDatabricksでは失敗する」「Databricks上のcommit authorが別人になる」「本番Jobsが突然Gitにアクセスできなくなる」といったトラブルを減らせます。
まず取るべきアクション
Azure DatabricksでGit foldersを使っている、または今後導入するチームは、最初に以下を確認してください。
まず、現在のGit credentialsを棚卸しし、個人PATがJobsやCI/CDに使われていないか確認します。次に、GitHubはDatabricks GitHub Appを優先できるか、Azure DevOps ServicesはMicrosoft Entra ID認証を使えるテナント構成か、Bitbucketはapp passwordから移行が必要かを判断します。最後に、Git URL allowlist、commit identity、サービスプリンシパル、ネットワーク到達性を非本番環境で検証してから、本番へ展開します。
「Connect your Git provider to Databricks」は、単なる初期設定手順ではなく、Azure DatabricksにおけるGit運用、認証、CI/CD、セキュリティをつなぐ基盤設定です。チームで使うGit providerごとに認証方式を標準化し、自動化はサービスプリンシパルへ寄せることで、token期限切れや権限変更に強い運用へ移行できます。
コメント