定義済み変数の使用

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

変数を使うと、パイプラインのさまざまな部分に重要なデータを簡単に取り込むことができます。 これは使用できる定義済み変数の一覧です。 他にもいくつか定義済み変数がある可能性がありますが、それらは主に内部使用のための変数です。

これらの変数は、システムによって自動的に設定され、読み取り専用となります。 (例外は Build.Clean と System.Debug です)

YAML パイプラインでは、定義済みの変数を環境変数として参照できます。 たとえば、変数 Build.ArtifactStagingDirectory は変数 BUILD_ARTIFACTSTAGINGDIRECTORY になります。

クラシック パイプラインの場合、配置タスクでリリース変数を使って、共通の情報 (たとえば、環境名、リソース グループなど) を共有できます。

変数の使用に関する詳細については、こちらを参照してください。

ヒント

変数 ヘルプについては、Copilot に問い合わせてください。 詳細については、「変数値に基づいて条件を持つステージを生成するように Copilot に依頼する を参照してください。

Build.Clean

これは、ビルド エージェントがソースをクリーンアップする方法を変更する非推奨の変数です。 ソースをクリーンアップする方法については、「エージェントのローカル リポジトリをクリーンする」を参照してください。

System.AccessToken

System.AccessToken は、実行中のビルドで使われるセキュリティ トークンを保持する特別な変数です。

YAML

YAML では、変数を使って、明示的に System.AccessToken をパイプラインにマップする必要があります。 これは、ステップ レベルまたはタスク レベルで行うことができます。 たとえば、System.AccessToken を使用してコンテナー レジストリで認証できます。

steps:
- task: Docker@2
  inputs:
    command: login
    containerRegistry: '<docker connection>'
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

System.AccessTokenを使って、 の既定のスコープを構成できます。

クラシック

ジョブ レベルでスクリプトとタスクが System.AccessToken にアクセスすることを許可できます。

1. ジョブに移動します

2. [その他のオプション] で、[スクリプトが OAuth トークンにアクセスできるようにする] ボックスをオンにします。

このボックスをオンにすると、スクリプトでプッシュとプルを実行できるように、資格情報セットが Git に残ります。

System.Debug

パイプラインの問題をデバッグするための詳細なログを取得するには、System.Debug を定義し、true に設定します。

1. パイプラインを編集します。

2. [変数] を選択します。

3. 名前が System.Debug、値が true の新しい変数を追加します。

   

4. 新しい変数を保存します。

System.Debug を true に設定すると、すべての実行の詳細ログが構成されます。 また、[システムの診断を有効にする] チェックボックスを使って、1 つの実行に対して詳細ログを構成することもできます。

また、パイプラインやテンプレートの変数として System.Debug を true に設定することもできます。

variables:
  system.debug: 'true'

System.Debug を true に設定すると、Agent.Diagnostic という名前の追加の変数が true に設定されます。 Agent.Diagnostic が true の場合、エージェントは、セルフホステッド エージェントのネットワークの問題のトラブルシューティングに使用できるログをさらに収集します。 詳細については、「セルフホステッド エージェントのネットワーク診断」を参照してください。

Note

Agent.Diagnostic 変数は、Agent v2.200.0 以降で使用できます。

詳細については、「ログを確認してパイプラインの問題を診断する」を参照してください。

エージェント変数 (DevOps Services)

Note

エージェント変数は、スクリプトの環境変数として、ビルド タスクではパラメーターとして使用できます。 これらを使ってビルド番号をカスタマイズしたり、バージョン コントロールのラベルやタグを適用したりすることはできません。

変数	説明
Agent.BuildDirectory	指定されたビルド パイプラインのすべてのフォルダーが作成される、エージェントのローカル パス。 この変数の値は Pipeline.Workspace と同じです。 (例: /home/vsts/work/1)。
Agent.ContainerMapping	YAML のコンテナー リソース名から実行時の Docker ID へのマッピング。 例は表の後にあります。
Agent.HomeDirectory	エージェントがインストールされるディレクトリ。 これには、エージェント ソフトウェアが含まれます。 (例: c:\agent)。
Agent.Id	エージェントの ID。
Agent.JobName	実行中のジョブの名前。 通常は "Job" または "__default" ですが、マルチ構成シナリオでは構成の名前になります。
Agent.JobStatus	ビルドの状態。 Canceled Failed Succeeded SucceededWithIssues (部分的に成功) Skipped (最後のジョブ) 環境変数は AGENT_JOBSTATUS として参照する必要があります。 下位互換性のため、以前の agent.jobstatus が使用できます。
Agent.MachineName	エージェントがインストールされているマシンの名前。
Agent.Name	プールに登録されているエージェントの名前。 セルフホステッド エージェントを使っている場合、この名前はユーザーが指定します。 エージェントに関するページを参照してください。
Agent.OS	エージェント ホストのオペレーティング システム。 有効な値は次のとおりです。 Windows_NT Darwin Linux コンテナーで実行している場合、エージェント ホストとコンテナーは異なるオペレーティング システムを実行している可能性があります。
Agent.OSArchitecture	エージェント ホストのオペレーティング システム プロセッサ アーキテクチャ。 有効な値は次のとおりです。 X86 X64 ARM
Agent.TempDirectory	各パイプライン ジョブの後にクリーンされる一時的なフォルダー。 このディレクトリは、公開前のテスト結果などの一時的な項目を保持するために、.NET Core CLI タスクなどのタスクで使われます。 例: Ubuntu の場合 /home/vsts/work/_temp。
Agent.ToolsDirectory	Node Tool インストーラーや Python バージョンの使用などのタスクで、ツールの複数のバージョンを切り替えるために使われるディレクトリ。 これらのタスクは、このディレクトリからツールを PATH に追加して、後続のビルド手順で使用できるようにします。 セルフホステッド エージェントで、このディレクトリを管理する詳細について参照してください。
Agent.WorkFolder	このエージェントの作業ディレクトリ。 (例: c:\agent_work)。 注: このディレクトリは、パイプライン タスクによって書き込み可能であるとは限りません (たとえば、コンテナーにマップされている場合)

Agent.ContainerMapping の例

{
  "one_container": {
    "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190"
  },
  "another_container": {
    "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb"
  }
}

ビルド変数 (DevOps Services)

テンプレートで使用可能とマークされていない変数をテンプレート内で使用した場合、その変数はレンダリングされません。 変数がレンダリングされないのは、その値がテンプレートの範囲内でアクセスできないためです。

変数	説明	テンプレートで使用可能か?
Build.ArtifactStagingDirectory	宛先にプッシュされる前に成果物がコピーされる、エージェントのローカル パス。 (例: c:\agent_work\1\a)。 このフォルダーの一般的な用途は、ファイルのコピーとビルド成果物の発行タスクでビルド成果物を発行することです。 注: Build.ArtifactStagingDirectory と Build.StagingDirectory は交換可能です。 このディレクトリは新しいビルドの前に消去されるので、自分でクリーンする必要はありません。 Azure Pipelines の成果物に関するページを参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.BuildId	完了したビルドのレコードの ID。	No
Build.BuildNumber	完了したビルドの名前で、実行番号とも呼ばれます。 この値には何を含めるかを指定できます。 この変数の一般的な用途は、リポジトリ タブで指定するラベルの形式の一部にすることです。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.BuildUri	ビルドの URI。 (例: vstfs:///Build/Build/1430)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.BinariesDirectory	コンパイルされたバイナリの出力フォルダーとして使用できる、エージェントのローカル パス。 既定では、新しいビルド パイプラインはこのディレクトリをクリーンするように設定されません。 [リポジトリ] タブで、このディレクトリをクリーンするようにビルドを定義できます。 (例: c:\agent_work\1\b)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.ContainerId	成果物のコンテナーの ID。 パイプラインで成果物をアップロードすると、その特定の成果物に固有のコンテナーに対して追加されます。	No
Build.CronSchedule.DisplayName	パイプライン実行をトリガーした cron スケジュールの displayName。 この変数は、パイプライン実行が YAML のスケジュールされたトリガーによってトリガーされる場合にのみ設定されます。 詳細については、「schedules.cron definition - Build.CronSchedule.DisplayName 変数」を参照してください	はい
Build.DefinitionName	ビルド パイプラインの名前。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.DefinitionVersion	ビルド パイプラインのバージョン。	はい
Build.QueuedBy	「ID 変数はどのように設定されますか?」を参照してください。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.QueuedById	「ID 変数はどのように設定されますか?」を参照してください。	はい
Build.Reason	ビルドの実行の原因となったイベント。 Manual: ユーザーが手動でビルドをキューに入れた。 IndividualCI: Git プッシュや TFVC チェックインによる継続的インテグレーション (CI) でトリガーされた。 BatchedCI: Git プッシュや TFVC チェックインによる継続的インテグレーション (CI) でトリガーされ、バッチ変更が選ばれた。 Schedule: スケジュール済みのトリガー。 ValidateShelveset: ユーザーが手動で特定の TFVC シェルブセットのビルドをキューに入れた。 CheckInShelveset: ゲート チェックインのトリガー。 PullRequest: ビルドを必要とする Git ブランチ ポリシーによってビルドがトリガーされた。 BuildCompletion: ビルドが別のビルドによってトリガーされた ResourceTrigger: ビルドが、リソース トリガーによってトリガーされたか、別のビルドによってトリガーされた。 ビルド パイプライン トリガー、ブランチ ポリシーでのコード品質の向上に関するページを参照してください。	はい
Build.Repository.Clean	ソース リポジトリの設定で Clean に選んだ値。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.LocalPath	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 (例: c:\agent_work\1\s)。 既定では、新しいビルド パイプラインは変更されたファイルのみを更新します。 [リポジトリ] タブでファイルのダウンロード方法を変更できます。 重要な注意事項: 1 つの Git リポジトリのみをチェックアウトした場合、このパスはコードへの正確なパスとなります。 複数のリポジトリをチェックアウトした場合、動作は次のようになります (Build.SourcesDirectory 変数の値とは異なる場合があります)。 セルフ (プライマリ) リポジトリのチェックアウト ステップにカスタム チェックアウト パスが定義されていない場合、またはチェックアウト パスがセルフ リポジトリのマルチ チェックアウトにおける既定のパス $(Pipeline.Workspace)/s/&<RepoName> の場合、この変数の値は既定値である $(Pipeline.Workspace)/s に戻されます。 セルフ (プライマリ) リポジトリのチェックアウト ステップにカスタム チェックアウト パスが定義されていれば (そしてそれがマルチ チェックアウトにおける既定のパスでなければ)、この変数にはセルフ リポジトリへの正確なパスが含まれます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.ID	リポジトリの一意識別子。 これは、リポジトリの名前が変わっても変わりません。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Name	トリガーするリポジトリの名前。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Provider	トリガーするリポジトリの種類。 TfsGit: TFS Git リポジトリ TfsVersionControl: Team Foundation バージョン管理 Git: 外部サーバーでホストされている Git リポジトリ GitHub Svn: Subversion この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Tfvc.Workspace	リポジトリが Team Foundation バージョン管理の場合に定義されます。 ビルド エージェントが使う TFVC ワークスペースの名前です。 たとえば、Agent.BuildDirectory が c:\agent_work\12 で Agent.Id が 8 の場合、ワークスペース名は次のようになります: ws_12_8 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Uri	トリガーするリポジトリの URL。 次に例を示します。 Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.RequestedFor	「ID 変数はどのように設定されますか?」を参照してください。 注: この値には、空白文字やその他の無効なラベル文字が含まれることがあります。 このような場合、ラベルの形式は失敗します。	はい
Build.RequestedForEmail	「ID 変数はどのように設定されますか?」を参照してください。	はい
Build.RequestedForId	「ID 変数はどのように設定されますか?」を参照してください。	はい
Build.SourceBranch	ビルドがキューに入れられた、トリガーするリポジトリのブランチ。 次に例をいくつか示します。 Git リポジトリのブランチ: refs/heads/main Git リポジトリの pull request: refs/pull/1/merge TFVC リポジトリのブランチ: $/teamproject/main TFVC リポジトリのゲート チェックイン: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC リポジトリのシェルブセットのビルド: myshelveset;username@live.com パイプラインがタグによってトリガーされた場合: refs/tags/your-tag-name この変数をビルド番号の形式で使う場合、スラッシュ文字 (/) はアンダースコア文字 (_) に置き換えられます。 注: TFVC では、ゲート チェックイン ビルドを実行している場合、またはシェルブセットを手動でビルドしている場合は、ビルド番号の形式でこの変数を使うことはできません。	はい
Build.SourceBranchName	ビルドがキューに入れられた、トリガーするリポジトリにあるブランチの名前。 Git リポジトリのブランチ、pull request、またはタグ: ref の最後のパスのセグメント。たとえば、refs/heads/main の場合、この値は main です。 refs/heads/feature/tools では、この値は tools です。 refs/tags/your-tag-name では、この値は your-tag-name です。 TFVC リポジトリのブランチ: ワークスペースのルート サーバー パスでの最後のパスのセグメント。 たとえば、$/teamproject/main の場合、この値は main です。 TFVC リポジトリのゲート チェックインまたはシェルブセット ビルドは、シェルブセットの名前です。 たとえば、Gated_2016-06-06_05.20.51.4369;username@live.com または myshelveset;username@live.com です。 注: TFVC では、ゲート チェックイン ビルドを実行している場合、またはシェルブセットを手動でビルドしている場合は、ビルド番号の形式でこの変数を使うことはできません。	はい
Build.SourcesDirectory	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 (例: c:\agent_work\1\s)。 既定では、新しいビルド パイプラインは変更されたファイルのみを更新します。 重要な注意事項: 1 つの Git リポジトリのみをチェックアウトした場合、このパスはコードへの正確なパスとなります。 複数のリポジトリをチェックアウトする場合、セルフ (プライマリ) リポジトリがマルチ チェックアウトにおける既定のパス $(Pipeline.Workspace)/s とは異なるカスタム パスにチェックアウトされても、既定値である $(Pipeline.Workspace)/s/<RepoName> に戻されます (この点で、この変数は Build.Repository.LocalPath 変数の動作とは異なります)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.SourceVersion	このビルドに含まれる、トリガーするリポジトリの最新のバージョン コントロールの変更。 Git: コミット ID。 TFVC: 変更セット。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	はい
Build.SourceVersionMessage	トリガーするリポジトリのコミットまたは変更セットのコメント。 メッセージは、最初の行か 200 文字のどちらか短い方に切り捨てられます。 Build.SourceVersionMessage は Build.SourceVersion のコミット時のメッセージに対応します。 PR ビルドの Build.SourceVersion のコミットはマージ コミットです (ソース ブランチ上のコミットではありません)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 また、この変数はステップ レベルでのみ使用でき、ジョブ レベルやステージ レベルでは使用できません (つまり、ジョブが開始されてコードがチェックアウトされるまで、メッセージは抽出されません)。 注: この変数は、TFS 2015.4 で使用できます。 注: [ビルドの進行中に変更をバッチ処理する] が有効な場合、Build.SourceVersionMessage 変数は、Bitbucket リポジトリのクラシック ビルド パイプラインでは機能しません。	No
Build.StagingDirectory	宛先にプッシュされる前に成果物がコピーされる、エージェントのローカル パス。 (例: c:\agent_work\1\a)。 このフォルダーの一般的な用途は、ファイルのコピーとビルド成果物の発行タスクでビルド成果物を発行することです。 注: Build.ArtifactStagingDirectory と Build.StagingDirectory は交換可能です。 このディレクトリは新しいビルドの前に消去されるので、自分でクリーンする必要はありません。 Azure Pipelines の成果物に関するページを参照してください。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.Repository.Git.SubmoduleCheckout	[リポジトリ] タブの [サブモジュールのチェックアウト] で選んだ値。複数のリポジトリがチェックアウトされている場合、この値はトリガーするリポジトリの設定を追跡します。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No
Build.SourceTfvcShelveset	リポジトリが Team Foundation バージョン管理の場合に定義されます。 ゲート ビルドまたはシェルブセット ビルドを実行している場合、これはビルドするシェルブセットの名前に設定されます。 注: この変数は、ビルド番号の形式でのビルド用途には無効な値が生成されます。	No
Build.TriggeredBy.BuildId	ビルドが別のビルドによってトリガーされた場合、この変数にはトリガーしたビルドの BuildID が設定されます。 クラシック パイプラインでは、この変数はビルド完了トリガーによってトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.DefinitionId	ビルドが別のビルドによってトリガーされた場合、この変数にはトリガーしたビルドの DefinitionID が設定されます。 クラシック パイプラインでは、この変数はビルド完了トリガーによってトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.DefinitionName	ビルドが別のビルドによってトリガーされた場合、この変数にはトリガーしたビルド パイプラインの名前が設定されます。 クラシック パイプラインでは、この変数はビルド完了トリガーによってトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.BuildNumber	ビルドが別のビルドによってトリガーされた場合、この変数にはトリガーしたビルドの番号が設定されます。 クラシック パイプラインでは、この変数はビルド完了トリガーによってトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Build.TriggeredBy.ProjectID	ビルドが別のビルドによってトリガーされた場合、この変数にはトリガーしたビルドを含むプロジェクトの ID が設定されます。 クラシック パイプラインでは、この変数はビルド完了トリガーによってトリガーされます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。 resources を使って YAML パイプラインをトリガーする場合は、代わりに resources 変数を使う必要があります。	No
Common.TestResultsDirectory	テスト結果が作成される、エージェントのローカル パス。 (例: c:\agent_work\1\TestResults)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No

パイプライン変数 (DevOps Services)

変数	説明
Pipeline.Workspace	特定のパイプラインのワークスペース ディレクトリ。 この変数の値は Agent.BuildDirectory と同じです。 たとえば、/home/vsts/work/1 となります。

ヒント

クラシック リリース パイプラインを使っている場合、クラシック リリースと成果物の変数を使って、パイプライン全体でデータを格納しアクセスできます。

配置ジョブ変数 (DevOps Services)

これらの変数のスコープは特定の配置ジョブで、ジョブの実行時にのみ解決されます。

変数	説明
Environment.Name	配置ジョブで、配置手順を実行し配置履歴を記録する対象となる環境の名前。 たとえば、smarthotel-dev となります。
Environment.Id	配置ジョブの対象となる環境の ID。 たとえば、10 となります。
Environment.ResourceName	配置ジョブで、配置手順を実行し配置履歴を記録する対象となる環境内の特定のリソースの名前。 たとえば、環境 bookings にリソースとして追加された Kubernetes 名前空間の smarthotel-dev。
Environment.ResourceId	配置ジョブで、配置手順を実行する対象となる環境内の特定のリソースの ID。 たとえば、4 となります。
Strategy.Name	配置戦略の名前: canary、runOnce、または rolling。
Strategy.CycleName	配置における現在のサイクル名。 オプションは、PreIteration、Iteration、または PostIteration です。

システム変数 (DevOps Services)

テンプレートで使用可能とマークされていない変数をテンプレート内で使用した場合、その変数はレンダリングされません。 変数がレンダリングされないのは、その値がテンプレートの範囲内でアクセスできないためです。

変数	説明	テンプレートで使用可能か?
System.AccessToken	OAuth トークンを使った REST API へのアクセス。 YAML スクリプトからの System.AccessToken の使用。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	はい
System.CollectionId	TFS コレクションまたは Azure DevOps 組織の GUID。	はい
System.CollectionUri	TFS コレクションまたは Azure DevOps 組織の URI。 (例: https://dev.azure.com/fabrikamfiber/)。	はい
System.DefaultWorkingDirectory	ソース コード ファイルがダウンロードされる、エージェントのローカル パス。 例: c:\agent_work\1\s 既定では、新しいビルド パイプラインは変更されたファイルのみを更新します。 [リポジトリ] タブでファイルのダウンロード方法を変更できます。 この変数はエージェント スコープです。 スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	はい
System.DefinitionId	ビルド パイプラインの ID。	はい
System.HostType	パイプラインがビルドの場合は build に設定されます。 リリースの場合、値は、配置グループ ジョブでは deployment、ゲートの評価中は gates、その他の (エージェントおよびエージェントレス) ジョブのときは release になります。	はい
System.JobAttempt	このジョブが最初に試行されたときに 1 が設定され、ジョブが再試行されるたびにインクリメントされます。	No
System.JobDisplayName	ジョブに付けられた人間が判読できる名前。	No
System.JobId	1 つのジョブの 1 回の試行に対する一意識別子。 値は現在のパイプラインに特有のものです。	No
System.JobName	ジョブの名前。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.OidcRequestUri	OpenID Connect (OIDC) を使用する Entra ID による認証用の idToken を生成します。 詳細情報。	はい
System.PhaseAttempt	このフェーズが最初に試行されたときに 1 が設定され、ジョブが再試行されるたびにインクリメントされます。 注: "フェーズ" は、ジョブのデザイン時を表す、ほぼ冗長な概念です (一方、ジョブは、フェーズの実行時バージョンです)。 Azure Pipelines からは "フェーズ" の概念がほぼ削除されました。 マトリックス ジョブとマルチ構成ジョブは、"フェーズ" が "ジョブ" と区別されている唯一の場所です。1 つのフェーズで、入力のみが異なる複数のジョブのインスタンスを作成できます。	No
System.PhaseDisplayName	フェーズに付けられた人間が判読できる名前。	No
System.PhaseName	ジョブの文字列ベースの識別子。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.PlanId	1 つのパイプライン実行に対する文字列ベースの識別子。	No
System.PullRequest.IsFork	pull request がリポジトリのフォークからの場合、この変数には True が設定されます。 それ以外の場合は、False に設定されます。	はい
System.PullRequest.PullRequestId	このビルドの原因となった pull request の ID。 (例: 17)。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。	No
System.PullRequest.PullRequestNumber	このビルドの原因となった pull request の番号。 この変数は、異なる pull request ID と pull request 番号を持つ GitHub からの pull request に対して設定されます。 この変数は、PR がブランチ ポリシーの影響を受ける場合にのみ、YAML パイプラインで使用できます。	No
System.PullRequest.targetBranchName	pull request のターゲット ブランチの名前。 この変数は、パイプラインで使用して、pull request のターゲット ブランチに基づいてタスクやステップを条件付きで実行できます。 たとえば、変更がマージされるブランチに応じて、異なるテスト セットやコード分析ツールをトリガーすることができます。	No
System.PullRequest.SourceBranch	pull request でレビューされているブランチ。 たとえば、Azure Repos での refs/heads/users/raisa/new-feature。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。 この変数は、PR がブランチ ポリシーの影響を受ける場合にのみ、YAML パイプラインで使用できます。	No
System.PullRequest.SourceCommitId	pull request でレビューされているコミット。 (この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます)。 この変数は、PR がブランチ ポリシーの影響を受ける場合にのみ、YAML パイプラインで使用できます。
System.PullRequest.SourceRepositoryURI	pull request を含むリポジトリへの URL。 (例: https://dev.azure.com/ouraccount/_git/OurProject)。	No
System.PullRequest.TargetBranch	pull request のターゲットとなるブランチ。 たとえば、リポジトリが Azure Repos にある場合 refs/heads/main、リポジトリが GitHub にある場合 main。 この変数は、ブランチ ポリシーの影響を受けた Git PR が原因でビルドが実行された場合にのみ初期化されます。 この変数は、PR がブランチ ポリシーの影響を受ける場合にのみ、YAML パイプラインで使用できます。	No
System.StageAttempt	このステージが最初に試行されたときに 1 が設定され、ステージが再試行されるたびにインクリメントされます。	No
System.StageDisplayName	ステージに付けられた人間が判読できる名前。	No
System.StageName	ステージの文字列ベースの識別子。通常、依存関係を表現したり、出力変数にアクセスしたりするために使われます。	No
System.TeamFoundationCollectionUri	TFS コレクションまたは Azure DevOps 組織の URI。 (例: https://dev.azure.com/fabrikamfiber/)。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	はい
System.TeamProject	このビルドを含むプロジェクトの名前。	はい
System.TeamProjectId	このビルドが属するプロジェクトの ID。	はい
System.TimelineId	1 つのパイプライン実行の詳細とログのための文字列ベースの識別子。	No
TF_BUILD	スクリプトがビルド タスクによって実行されている場合、True に設定されます。 この変数はエージェント スコープであり、スクリプトの環境変数やビルド タスクのパラメーターとして使用できますが、ビルド番号の一部やバージョン コントロール タグとして使用することはできません。	No

チェック変数 (DevOps Services)

変数	説明
Checks.StageAttempt	このステージが最初に試行されたときに 1 が設定され、ステージが再試行されるたびにインクリメントされます。 この変数は、環境に対する承認またはチェック内でのみ使用できます。 たとえば、$(Checks.StageAttempt) は REST API の呼び出しチェックの中で使用できます。

ID 変数はどのように設定されますか?

値はビルドの原因によって異なり、Azure Repos リポジトリに固有のものです。

ビルドがトリガーされた原因	Build.QueuedBy と Build.QueuedById の値が基づくもの	Build.RequestedFor と Build.RequestedForId の値が基づくもの
Git で、または継続的インテグレーション (CI) のトリガーによる場合	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	変更をプッシュまたはチェックインしたユーザー。
Git で、ブランチ ポリシー ビルドによる場合。	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	変更をチェックインしたユーザー。
TFVC で、ゲート チェックイン トリガーによる場合	変更をチェックインしたユーザー。	変更をチェックインしたユーザー。
Git または TFVC で、スケジュールされたトリガーによる場合	システム ID。例: [DefaultCollection]\Project Collection Service Accounts	システム ID。例: [DefaultCollection]\Project Collection Service Accounts
[ビルドをキューに挿入] ボタンをクリックしたため	自分	自分

変数値に基づいて条件を持つステージを生成するように Copilot に依頼する

Copilot 使用して、変数の値によって決定される条件を持つステージを生成します。

このプロンプト例では、前のステージが正常に実行されたことを示 Agent.JobStatus 実行するステージを定義します。

Agent.JobStatus が Succeeded または SucceededWithIssues場合にのみ実行される新しい Azure DevOps ステージを作成します。

要件を満たす値を使用するようにプロンプトをカスタマイズできます。 たとえば、パイプラインが失敗した場合にのみ実行されるステージの作成に関するヘルプを求めることができます。

Note

GitHub Copilot は AI を利用しているため、驚きや間違いが起こりうる可能性があります。 生成されたコードまたは提案を必ず確認してください。 GitHub Copilot の一般的な使用、製品への影響、人による監視、プライバシーの詳細については、GitHub Copilot に関する FAQ参照してください。