Azure DevOps
Azure DevOps 連携を使用すると、Azure DevOps Services のリポジトリを Cloud Agents および Bugbot に接続できます。
Azure DevOps 連携はパブリックベータ版です。dev.azure.com の Azure DevOps Services をサポートしています。Azure DevOps Server には対応していません。
対応機能
Cloud Agents はコードをクローンし、ブランチで作業して、プルリクエストを作成します。Bugbot はプルリクエストをレビューし、検出事項をコメントとして投稿します。
以下の機能は、まだ Azure DevOps に対応していません。
- 自動化
- Bugbot Autofix
- Security Reviewer と Vulnerability Scanner を含む セキュリティエージェント
これらの機能は本日、GitHub で利用できます。Azure DevOps への対応はロードマップに含まれています。
セットアップ
Cursor で使用する Azure DevOps の組織とリポジトリにアクセスできる必要があります。
- ダッシュボードの連携に移動します
- Azure DevOps の横にある Connect をクリックします
- Azure DevOps で使用している Microsoft アカウントでサインインします
- Microsoft Entra の OAuth 同意画面を確認し、アクセスを承認します
- Cursor に戻り、Azure DevOps の組織からリポジトリを選択します
- Cursor で使用するリポジトリに Cloud Agent を設定します
Azure DevOps アカウントの接続を解除するには、連携ダッシュボードに戻り、Disconnect Account をクリックします。
Bugbot をセットアップする
Azure DevOps 向け Bugbot は限定提供中です。セットアップには、Microsoft Entra ID 管理者によるテナント管理者の同意が必要です。この手順についてはガイドします。開始するには、お問い合わせください。
Bugbot は、Cursor がテナント内にプロビジョニングする Microsoft Entra サービス プリンシパルを通じて、Azure DevOps のプルリクエストをレビューします。このサービス プリンシパルは、Bugbot が監視するサービス フックをインストールし、プルリクエストの差分を読み取り、確認コメントとビルド ステータスを投稿します。セットアップは Azure DevOps 組織ごとに、次の順序で一度だけ実行します。
- Project Collection Administrator がダッシュボードの連携から Azure DevOps を接続し、自動化の Bugbotでリポジトリの Bugbot を有効にします。これにより、組織の Entra テナントが検出され、Cursor サービス プリンシパルが自動的にプロビジョニングされます。プロビジョニングには、一度限りのMicrosoft Entra の管理者同意が必要です。
- プロジェクト管理者が、確認対象にする各プロジェクトの Project Administrators グループに Cursor サービス プリンシパルを追加します。Bugbot がサービス フックを管理するには、プロジェクト管理者権限が必要です。
- Azure DevOps では、権限の変更が反映されるまで数分かかります。権限変更の直後に失敗したトグルも、数分後には変更なしで成功する場合があります。
手順が不足している場合、リポジトリのトグルは不足している手順を示すエラーで失敗します。問題を修正してから、リポジトリを再度有効にしてください。
Azure DevOps 向け Bugbot はチーム リポジトリで利用できます。個人スコープのリポジトリはサポートされていません。
Microsoft Entra の管理者同意を付与する
Cursor のサービス プリンシパルをディレクトリ内に作成するには、Microsoft Entra ID 管理者がテナント全体に対する管理者同意を一度付与する必要があります。同意の付与には、Global Administrator、Application Administrator、または Cloud Application Administrator のロールが必要です。これはテナント全体に適用されるため、リポジトリ管理者だけでは完了できません。
同意が付与されていない場合は、enable エラーで通知されます。自分で同意リンクを作成することもできます。
https://login.microsoftonline.com/{your-tenant-id}/v2.0/adminconsent?client_id=29df4809-337a-4255-bd57-d4a1476b0e65&redirect_uri=https://cursor.com/azure-devops-connected&scope=499b84ac-1321-427f-aa17-267ca6975798/.default%20offline_access%20openid%20profile{your-tenant-id} を Microsoft Entra 管理センター にあるテナント ID に置き換えます。client_id は Cursor のアプリケーション ID です。scope には Azure DevOps API (499b84ac-1321-427f-aa17-267ca6975798 は Microsoft によるこの API の識別子) と標準のサインイン スコープが含まれます。Cursor は Microsoft Graph のデータを一切要求しません。サービス プリンシパルはテナント内に保持され、Entra からいつでも取り消せます。
管理者が同意すると、Microsoft は管理者を cursor.com/azure-devops-connected にリダイレクトし、ページに許可が確認されます。許可はテナント内に保持されるため、次にリポジトリを有効にするとセットアップが完了します。
以前の同意で対象となるのは、その時点で Cursor が要求した権限のみです。テナントで同意した後に Cursor が権限を追加した場合、セットアップは途中で失敗し、再接続しても解決しません。許可を更新するには、同意リンクをもう一度開いてくださ���。
個人用 Microsoft アカウントに紐づく Azure DevOps 組織では、サービス プリンシパルをホストできません。先に組織を Microsoft Entra ID に接続してください。
サービス プリンシパルに組織へのアクセス権を付与する
同意後、Cursor はサービス プリンシパルを Azure DevOps 組織に追加し、Basic アクセス レベルをリクエストします。これらはいずれも、Azure DevOps を接続した管理者アカウントを使用して自動的に行われます。その後、サービス プリンシパルは Organization settings → Users に表示されます。
次の 2 つの理由により、これが妨げられる可能性があります。
- 接続したアカウントに組織へユーザーを追加する権限がない。 組織の管理者アカウントで Azure DevOps を再接続してください。
- 利用可能な Basic アクセス レベルがない。 Basic シートを空けるか、Organization settings → Users でサービス プリンシパルに割り当ててください。
サービス プリンシパルをプロジェクトに追加する
サービス フックは、Azure DevOps がプルリクエストに関する通知を Bugbot に送る仕組みです。管理できるのはプロジェクト管理者のみです。確認対象の各プロジェクトで、Project settings → Permissions に移動し、Project Administrators グループに Cursor のサービス プリンシパルを追加してください。リポジトリの読み取り権限だけでは不十分です。
権限の変更が反映されるまで数分かかる場合があります。そのため、付与直後に失敗したトグルでも、数分後には変更せずに成功することがあります。
リポジトリで Bugbot を有効にする
- 自動化の Bugbot を開きます
- インストール一覧で Azure DevOps のリポジトリを見つけます
- 確認対象にする各リポジトリで Bugbot をオンにします
リポジトリをオンにすると、Bugbot はサービスフックをインストールし、オフにすると削除します。リポジトリで Bugbot をオフにするか、Azure DevOps の接続を解除すると、そのリポジトリの確認はすぐに停止します。
確認のトリガー方法
Bugbot は、各プルリクエストが作成・更新されるたびに確認を行います。また、cursor review または bugbot run とコメントして、必要に応じて確認を依頼することもできます。
コメントによるトリガーには、Azure DevOps に関する制限が 1 つあります。リポジトリを所有するチームの Cursor アカウントに登録されているメールアドレスと、Azure DevOps のサインインアドレスが一致するユーザーのみ利用できます。それ以外のユーザーからのコメントでは、確認は開始されません。自動確認にはこの制限はなく、すべての作成者が対象です。
確認対象の作成者を絞り込む
Bugbot はデフォルトですべての作成者をレビューします。対象を絞り込むには、リポジトリの Bugbot 設定で Run for All Authors をオフにし、Only Review PRs by... または Skip PRs by... を選択します。
このリストにはユーザー名ではなく、Azure DevOps のサインインアドレスを入力します。フィールドにもそのように表示されています。サインインアドレスは taylor@contoso.com のような形式で、組織の管理者が Organization settings → Users で確認できる値です。ユーザー名は誰にも一致しないため、その作成者に対して Bugbot は確認を行いません。
他のプロバイダーとの違い
リポジトリ設定とリポジトリ ルールは Azure DevOps でも利用できます。以下の機能は利用できません。
- 新しいリポジトリでの自動有効化。 新しいリポジトリごとに、Bugbot を手動で有効にしてください。
- ルールの自動学習。 手動で作成したリポジトリ ルールは引き続き適用されます。
- 個人用の Bugbot 設定。 代わりに、リポジトリ設定が全員に適用されます。
- Autofix。 Bugbot は修正コミットを作成せずに検出結果を報告します。
ビルド ステータスとブランチ ポリシー
Bugbot は、確認対象の各プルリクエストに cursor-bugbot/review コンテキストでビルド ステータスを投稿します。各結果の意味については、CI チェック ステータスを参照してください。
このコンテキストを必須ステータスのブランチ ポリシーとして設定する場合は、ポリシーの リセット条件 を 新しい変更があるたびにステータスをリセットする に設定します。これを設定しないと、新しいコミットがマージされた後も、以前のプッシュのステータスがポリシーを満たし続けます。
以前の Bugbot セットアップからの移行
2026 年 8 月より前に Azure DevOps で Bugbot を有効にした組織では、以前のリポジトリごとのセットアップが使用されています。このセットアップを引き続き使用しているリポジトリを有効にすると、「This Azure DevOps repository still uses the earlier Bugbot setup.」と表示されます。
移行は自動的に行われます。組織の管理者として Azure DevOps を接続し、自動化の Bugbotでリポジトリを再度有効にします。Cursor が以前のサービス フックを削除し、新しいセットアップを 1 ステップで完了します。
Cursor から以前のセットアップを削除できなかったと表示された場合は、手動で削除してください。
- Azure DevOps で Project settings → Service hooks を開きます
https://api2.cursor.sh/azure_devops_webhookに配信する Cursor の Web Hooks サブスクリプションを削除します- 自動化の Bugbotでリポジトリを再度有効にします
移行後は、新しいセットアップの前提条件が適用されます。テナントには一度限りの Microsoft Entra の管理者同意が必要であり、サービス プリンシパルには組織内の Basic アクセス レベルおよび各プロジェクトの Project Administrators グループへの所属が必要です。
リポジトリ URL
Cursor は、次の形式の Azure DevOps Services リポジトリ URL をサポートしています。
https://dev.azure.com/{organization}/{project}/_git/{repository}Azure DevOps では、組織、プロジェクト、リポジトリの階層構造を使用します。Cursor では、Azure DevOps 組織内のリポジトリが {project}/{repository} として表示されます。
組織でまだ *.visualstudio.com URL を使用している場合は、Azure DevOps でリポジトリを開き、Cursor に追加する前に dev.azure.com URL をコピーしてください。
権限
Cursor は Microsoft Entra OAuth を通じて Azure DevOps に接続します。この接続により、Cursor は次の操作を行えます。
| アクセス | 用途 |
|---|---|
| 組織とプロジェクト | アクセス可能な Azure DevOps の組織、プロジェクト、リポジトリを一覧表示 |
| コードリポジトリ | リポジトリのクローンと作業ブランチの作成 |
| プルリクエスト | Cloud Agent が作成したプルリクエストのオープン、更新、マージ |
Bugbot では、2 つ目の ID が追加されます。Cursor はテナント内に Microsoft Entra サービス プリンシパルをプロビジョニングし、すべての Bugbot 操作に使用します。これにより、連携を設定したユーザーの役割が変わったり退職したりしても、確認は継続して実行されます。
| 操作 | Azure DevOps ID |
|---|---|
| Bugbot の確認コメント、インラインコメント、ビルドステータス | Cursor サービス プリンシパル |
| Bugbot サービスフックのインストールと削除 | Cursor サービス プリンシパル |
| Cloud Agent による Git クローン、ブランチのプッシュ、コミット、プルリクエストの作成 | 接続されている Azure DevOps ユーザー |
トラブルシューティング
- リポジトリが
dev.azure.comの Azure DevOps Services 上にホストされていることを確認してください。 - 接続した Microsoft アカウントに、組織、プロジェクト、リポジトリへのアクセス権があることを確認してください。
- Microsoft アカウントのアクセス権が変更された場合は、連携ダッシュボードから Azure DevOps を再接続してください。
- 選択した Azure DevOps リポジトリが Cursor に接続されていることを確認してください。
- Azure DevOps アカウントに、ターゲットリポジトリでブランチとプルリクエストを作成する権限があることを確認してください。
- ターゲットブランチでプルリクエストの作成や更新がブロックされている場合は、ブランチポリシーを確認してください。
Azure DevOps の dev.azure.com リポジトリ URL を使用してください。Cursor はこの連携では Azure DevOps Server の URL を受け付けません。
- リポジトリが 自動化の Bugbot で有効になっていることを確認してください。
- リポジトリが Cursor チームに属していることを確認してください。Azure DevOps の Bugbot は個人スコープのリポジトリを確認しません。
- Cursor サービスプリンシパルが Project settings → Permissions のプロジェクトの Project Administrators グループに属していることを確認してください。
- 作成者をフィルタリングしている場合は、プルリクエストの作成者がユーザー名ではなく Azure DevOps のサインインアドレスで一覧に含まれていることを確認してください。
コメントトリガーは、Azure DevOps のサインインアドレスが、リポジトリを所有するチームの Cursor アカウントと一致する場合にのみ機能します。同じ人物の 2 つのアドレスでも、ここでは別人として扱われます。
Azure DevOps プロファイルのサインインアドレスと Cursor アカウントのメールアドレスを照合し、そのアドレスがない場合はチーム管理者に招待してもらってください。自動確認はいずれの場合も継続して実行されます。
個人用の Bugbot 設定は、まだ Azure DevOps リポジトリには適用されません。リポジトリ設定は適用されます。自動化の Bugbot で、リポジトリレベルで必要な挙動を設定してください。
cursor-bugbot/review ステータスのブランチポリシーを開き、Reset conditions を Reset status whenever there are new changes に設定してください。そうしない場合、Azure DevOps は以前のステータスを保持するため、Bugbot が確認していないコミットでもポリシーが通過します。
次のステップ
Azure DevOps 連携を接続したら、それを利用する機能を設定します。
- Bugbot - バグやセキュリティ上の問題を検出する自動 PR 確認
- Cloud Agents - リポジトリ上でクラウド実行される AI エージェント
- Cloud Agent のセットアップ - 保存済み環境、マルチリポジトリのセットアップ、シークレット、Dockerfile