パイプラインキャッシュ

2025-05-04

Azure DevOps Services

パイプラインキャッシュを使用すると、以前の実行からダウンロードした依存関係を再利用してビルド時間を短縮できるため、同じファイルを再作成または再ダウンロードする必要がなくなります。これは、各実行の開始時に同じ依存関係が繰り返しダウンロードされるシナリオで特に役立ちます。これは、多くの場合、数百または数千のネットワーク呼び出しを伴う時間のかかるプロセスです。

キャッシュは、キャッシュの復元と保存に必要な時間が、ファイルの再生成にかかる時間よりも短い場合に最も効果的です。ただし、キャッシュによってパフォーマンス上の利点が得られない場合があり、ビルド時間に悪影響を及ぼす可能性もあります。キャッシュが適切なアプローチであるかどうかを判断するには、特定のシナリオを評価することが重要です。

手記

パイプラインキャッシュは、クラシックリリースパイプラインではサポートされていません。

パイプラインアーティファクトとパイプラインキャッシュを使用するタイミング

パイプラインキャッシュとパイプラインアーティファクトは同様の機能を実行しますが、さまざまなシナリオを対象としており、同じ意味で使用しないでください。

パイプライン成果物を使用: 1 つのジョブで生成された特定のファイルを利用し、それらを他のジョブと共有する必要がある場合（そうしないと、他のジョブが失敗する可能性があります）。
パイプラインキャッシュを使用する: 以前の実行のファイルを再利用してビルド時間を短縮する場合 (また、それらのファイルが含まれていない場合は、ジョブの実行機能に影響しません)。

手記

パイプラインキャッシュとパイプライン成果物は、すべてのレベル (無料および有料) で無料で利用できます。詳細については、「アーティファクトのストレージ使用量」を参照してください。

セルフホステッドエージェントの要件

次の実行可能ファイルは、 PATH 環境変数に一覧表示されているフォルダーに配置する必要があります。これらの要件は、セルフホステッドエージェントにのみ適用されることに注意してください。ホストされたエージェントには、必要なソフトウェアがプレインストールされています。

アーカイブソフトウェア/プラットフォーム	ウィンドウズ	Linux	マック
GNUタール	必須	必須	いいえ
BSDタール	いいえ	いいえ	必須
7ジップ	推奨	いいえ	いいえ

キャッシュタスク: しくみ

キャッシュは、ジョブのセクションにstepsを追加することによってパイプラインに追加されます。

パイプラインの実行中に、キャッシュステップが検出されると、タスクは指定された入力に基づいてキャッシュの復元を試みます。キャッシュが見つからない場合は、ステップが完了し、ジョブの次のステップが実行されます。

ジョブ内のすべてのステップが正常に実行されると、スキップされなかった "復元キャッシュ" ステップごとに、特別な "ジョブ後: キャッシュ" ステップが自動的に追加され、トリガーされます。この手順はキャッシュを保存するの役割を担っています。

手記

キャッシュは不変です。キャッシュが作成されると、そのコンテンツを変更することはできません。

キャッシュタスクを構成する

キャッシュタスクには、パスとキーの 2 つの必須引数があります。

path: キャッシュするフォルダーへのパス。絶対パスまたは相対パスを指定できます。相対パスは、$(System.DefaultWorkingDirectory)に対して解決されます。

ヒント

定義済みの変数を使用して、キャッシュするフォルダーへのパスを格納できます。ただし、ワイルドカードはサポートされていません。
key: 復元または保存するキャッシュの識別子を定義します。キーは、文字列値、ファイルパス、またはファイルパターンの組み合わせで構成され、各セグメントは | 文字で区切られます。
- 文字列:
  固定値 (キャッシュ名やツール名など)、または環境変数 (現在の OS やジョブ名など) から取得されます。
- ファイルパス:
  コンテンツがハッシュされる特定のファイルへのパス。このファイルは、タスクの実行時に存在する必要があります。ファイルパスに似たセグメントはそのように扱われるので、特に .を含むセグメントを使用する場合は、"ファイルが存在しない" というエラーが発生する可能性があるため、注意が必要です。
  
  ヒント
  
  パスに似た文字列セグメントがファイルパスのように扱われないようにするには、二重引用符で囲みます (例: "my.key" | $(Agent.OS) | key.file
- ファイルパターン:
  少なくとも 1 つのファイルと一致する必要がある glob スタイルのワイルドカードパターンのコンマ区切りのリスト。例：
  - **/yarn.lock: ソースディレクトリのすべての yarn.lock ファイル。
  - */asset.json, !bin/**: bin ディレクトリ内のファイルを除き、ソースディレクトリの下のディレクトリにあるすべてのasset.jsonファイル。

ファイルパスまたはファイルパターンによって識別されるファイルの内容は、動的キャッシュキーを生成するためにハッシュされます。これは、キャッシュされている内容を一意に識別するファイルがプロジェクトにある場合に便利です。たとえば、 package-lock.json、 yarn.lock、 Gemfile.lock、 Pipfile.lock などのファイルは、一意の依存関係のセットを表しているため、キャッシュキーで参照されることがよくあります。相対ファイルパスまたはパターンは、 $(System.DefaultWorkingDirectory)に対して解決されます。

例の:

次の例は、Yarn パッケージをキャッシュする方法を示しています。

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/s/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       "yarn" | "$(Agent.OS)"
       "yarn"
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

この例では、キャッシュキーは 3 つの部分で構成されています。静的文字列 ("yarn")、ジョブが実行されている OS (キャッシュはオペレーティングシステムごとに一意であるため)、 yarn.lock ファイルのハッシュ (依存関係を一意に識別するため)。

タスクが追加された後の最初の実行では、このキーによって識別されるキャッシュが存在しないため、キャッシュステップによって "キャッシュミス" が報告されます。最後の手順の後、$(Pipeline.Workspace)/s/.yarn 内のファイルからキャッシュが作成され、アップロードされます。次の実行では、キャッシュステップによって "キャッシュヒット" が報告され、キャッシュの内容がダウンロードされて復元されます。

checkout: selfを使用する場合、リポジトリは$(Pipeline.Workspace)/sにチェックアウトされ、.yarn フォルダーはリポジトリ自体に存在する可能性があります。

手記

Pipeline.Workspace は、すべてのディレクトリが作成されるパイプラインを実行しているエージェントのローカルパスです。この変数の値は Agent.BuildDirectoryと同じです。 checkout: selfを使用していない場合は、リポジトリ内のYARN_CACHE_FOLDERの場所を指すように.yarn変数を更新してください。

復元キーを使用する

restoreKeys では、複数の正確なキーまたはキープレフィックスに対してクエリを実行できます。これは、指定した key がヒットしない場合にフォールバックとして使用されます。復元キーは、プレフィックスでキーを検索し、最後に作成されたキャッシュエントリを返します。これは、パイプラインが完全に一致するものが見つからないが、それでも部分的なキャッシュヒットを使用する場合に役立ちます。

複数の復元キーを指定するには、それらを別々の行に一覧表示します。復元キーが試行される順序は上から下になります。

例の:

復元キーを使用して Yarn パッケージをキャッシュする方法の例を次に示します。

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: '"yarn" | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

この例では、キャッシュタスクは最初に指定したキーの復元を試みます。キーがキャッシュに存在しない場合は、最初の復元キー ( yarn | $(Agent.OS)) が試行されます。これにより、このプレフィックスと完全に一致するキャッシュキーまたは先頭のキャッシュキーが検索されます。

プレフィックスの一致は、 yarn.lock ファイルのハッシュが変更された場合に発生する可能性があります。たとえば、キャッシュにキー yarn | $(Agent.OS) | old-yarn.lock (現在のold-yarn.lockとは異なるハッシュyarn.lock) が含まれている場合、この復元キーは部分的なキャッシュヒットになります。

最初の復元キーが一致しない場合、次の復元キー (yarn) yarnで始まるキャッシュキーが検索されます。プレフィックスの一致の場合、復元プロセスは最後に作成されたキャッシュエントリを返します。

手記

パイプラインには複数のキャッシュタスクを含めることができます。キャッシュのストレージ制限はありません。同じパイプライン内のジョブとタスクは、同じキャッシュにアクセスして共有できます。

復元条件を使用する

一部のシナリオでは、キャッシュが正常に復元されたかどうかに基づいて、条件付きでステップを実行できます。たとえば、キャッシュが復元された場合に依存関係をインストールする手順をスキップできます。これは、 cacheHitVar 引数を使用して実現できます。

この入力を環境変数の名前に設定すると、キャッシュヒット時に変数が true に設定され、復元キーによって部分的なキャッシュヒットが発生した場合は inexact 、キャッシュが見つからない場合は false されます。その後、ステップ条件またはスクリプト内でこの変数を参照できます。

キャッシュの復元時に install-deps.sh ステップがスキップされる例を次に示します。

steps:
- task: Cache@2
  inputs:
    key: mykey | mylockfile
    restoreKeys: mykey
    path: $(Pipeline.Workspace)/mycache
    cacheHitVar: CACHE_RESTORED

- script: install-deps.sh
  condition: ne(variables.CACHE_RESTORED, 'true')

- script: build.sh

キャッシュの分離とセキュリティ

異なるパイプラインと異なるブランチからのキャッシュ間の分離を確保するために、すべてのキャッシュは スコープと呼ばれる論理コンテナー内に格納されます。スコープは、次を保証するセキュリティ境界として機能します。

あるパイプラインのジョブは、別のパイプラインのキャッシュにアクセスできません。
プル要求を作成するジョブは、(同じパイプラインの) ターゲットブランチからキャッシュを読み取ることができますが、ターゲットブランチのスコープ内でキャッシュを書き込む (作成) することはできません。

実行中にキャッシュステップが発生すると、キーによって識別されるキャッシュがサーバーから要求されます。その後、サーバーはジョブに表示されるスコープからこのキーを持つキャッシュを検索し、キャッシュ (使用可能な場合) を返します。キャッシュの保存時 (ジョブの最後) に、パイプラインとブランチを表すスコープにキャッシュが書き込まれます。

CI、手動、スケジュールされた実行

スコープ	既読	書き込み
ソースブランチ	はい	はい
`main` ブランチ	はい	いいえ
`master` ブランチ	はい	いいえ

Pull request の実行

スコープ	既読	書き込み
ソースブランチ	はい	いいえ
ターゲットブランチ	はい	いいえ
中間分岐 (`refs/pull/1/merge`など)	はい	はい
`main` ブランチ	はい	いいえ
`master` ブランチ	はい	いいえ

Pull request fork の実行

ブランチ	既読	書き込み
ターゲットブランチ	はい	いいえ
中間分岐 (`refs/pull/1/merge`など)	はい	はい
`main` ブランチ	はい	いいえ
`master` ブランチ	はい	いいえ

ヒント

キャッシュのスコープは既にプロジェクト、パイプライン、ブランチであるため、プロジェクト、パイプライン、またはブランチの識別子をキャッシュキーに含める必要はありません。

例示

Bundler を使用する Ruby プロジェクトの場合は、 BUNDLE_PATH 環境変数をオーバーライドして、Bundler が Gem を検索するパスを設定します。

例の:

variables:
  BUNDLE_PATH: $(Pipeline.Workspace)/.bundle

steps:
- task: Cache@2
  displayName: Bundler caching
  inputs:
    key: 'gems | "$(Agent.OS)" | Gemfile.lock'
    path: $(BUNDLE_PATH)
    restoreKeys: | 
      gems | "$(Agent.OS)"
      gems

Ccache は C/C++ のコンパイラキャッシュです。パイプラインで Ccache を使用するには、がインストールされ、必要に応じてに追加されていることを確認します (Ccache 実行モード参照)。 CCACHE_DIR 環境変数を $(Pipeline.Workspace) のパスに設定し、このディレクトリをキャッシュします。

例の:

variables:
  CCACHE_DIR: $(Pipeline.Workspace)/ccache

steps:
- bash: |
    sudo apt-get install ccache -y    
    echo "##vso[task.prependpath]/usr/lib/ccache"
  displayName: Install ccache and update PATH to use linked versions of gcc, cc, etc

- task: Cache@2
  displayName: Ccache caching
  inputs:
    key: 'ccache | "$(Agent.OS)" | $(Build.SourceVersion)'
    path: $(CCACHE_DIR)
    restoreKeys: | 
      ccache | "$(Agent.OS)"

詳細については、Ccache 構成設定を参照してください。

Docker イメージをキャッシュすると、パイプラインの実行にかかる時間が大幅に短縮されます。

variables:
  repository: 'myDockerImage'
  dockerfilePath: '$(Build.SourcesDirectory)/app/Dockerfile'
  tag: '$(Build.BuildId)'

pool:
  vmImage: 'ubuntu-latest'
steps:
  - task: Cache@2
    displayName: Cache task
    inputs:
      key: 'docker | "$(Agent.OS)" | cache'        ## A unique identifier for the cache
      path: $(Pipeline.Workspace)/docker           ## Path of the folder or file that you want to cache
      cacheHitVar: CACHE_RESTORED                  ## Variable to set to 'true' when the cache is restored
    
  - script: |
      docker load -i $(Pipeline.Workspace)/docker/cache.tar
    displayName: Docker restore
    condition: and(not(canceled()), eq(variables.CACHE_RESTORED, 'true'))

  - task: Docker@2
    displayName: 'Build Docker'
    inputs:
      command: 'build'
      repository: '$(repository)'
      dockerfile: '$(dockerfilePath)'
      tags: |
        '$(tag)'

  - script: |
      mkdir -p $(Pipeline.Workspace)/docker
      docker save -o $(Pipeline.Workspace)/docker/cache.tar $(repository):$(tag)
    displayName: Docker save
    condition: and(not(canceled()), not(failed()), ne(variables.CACHE_RESTORED, 'true'))

docker buildx の使用例:

steps:
  - task: Cache@2
    displayName: Cache Docker
    inputs:
      key: 'docker | "$(Agent.OS)" | mydockerimage | ./Dockerfile'
      path: $(Pipeline.Workspace)/docker_image_cache
      restoreKeys: |
        docker | "$(Agent.OS)" | mydockerimage

  - script: |
      docker buildx create --name builder --driver docker-container --use
      docker buildx build \
        --cache-from=type=local,src=$(Pipeline.Workspace)/docker_image_cache \
        --cache-to=type=local,dest=$(Pipeline.Workspace)/docker_image_cache,mode=max \
        --file ./Dockerfile \
        --output=type=docker,name=mydockerimage \
        .
    displayName: docker buildx
    env:
      DOCKER_BUILDKIT: 1

Golang プロジェクトの場合は、go.mod ファイルにダウンロードするパッケージを指定できます。 GOCACHE 変数がまだ設定されていない場合は、キャッシュをダウンロードする場所に設定します。

例の:

variables:
  GO_CACHE_DIR: $(Pipeline.Workspace)/.cache/go-build/

steps:
- task: Cache@2
  inputs:
    key: 'go | "$(Agent.OS)" | go.mod'
    restoreKeys: | 
      go | "$(Agent.OS)"
    path: $(GO_CACHE_DIR)
  displayName: Cache GO packages

Gradle の組み込みのキャッシュサポートを使用すると、ビルド時間に大きな影響を与える可能性があります。ビルドキャッシュを有効にするには、GRADLE_USER_HOME 環境変数を $(Pipeline.Workspace) の下のパスに設定し、--build-cache を使用してビルドを実行するか、org.gradle.caching=true ファイルに gradle.properties を追加します。

例の:

variables:
  GRADLE_USER_HOME: $(Pipeline.Workspace)/.gradle

steps:
- task: Cache@2
  inputs:
    key: 'gradle | "$(Agent.OS)" | **/build.gradle.kts' # Swap build.gradle.kts for build.gradle when using Groovy
    restoreKeys: |                                      # The fallback keys if the primary key fails (Optional)
      gradle | "$(Agent.OS)"
      gradle
    path: $(GRADLE_USER_HOME)
  displayName: Configure gradle caching

- task: Gradle@2
  inputs:
    gradleWrapperFile: 'gradlew'
    tasks: 'build'
    options: '--build-cache'
  displayName: Build

- script: |   
    # stop the Gradle daemon to ensure no files are left open (impacting the save cache operation later)
    ./gradlew --stop    
  displayName: Gradlew stop

手記

キャッシュは不変です。特定のスコープ (ブランチなど) に対して特定のキーを持つキャッシュを作成した後は、更新できません。つまり、固定キー値を使用すると、キャッシュの内容が変更された場合でも、同じブランチの後続のすべてのビルドでキャッシュを更新できなくなります。固定キーを使用する場合は、フォールバックオプションとして必ず restoreKeys 入力を指定してください。

Maven はローカルリポジトリを使用して、ダウンロードした依存関係とビルドされた成果物を格納します。キャッシュを有効にするには、 maven.repo.local オプションを $(Pipeline.Workspace) のパスに設定し、このフォルダーをキャッシュします。

例の:

variables:
  MAVEN_CACHE_FOLDER: $(Pipeline.Workspace)/.m2/repository
  MAVEN_OPTS: '-Dmaven.repo.local=$(MAVEN_CACHE_FOLDER)'

steps:
- task: Cache@2
  inputs:
    key: 'maven | "$(Agent.OS)" | **/pom.xml'
    restoreKeys: |
      maven | "$(Agent.OS)"
      maven
    path: $(MAVEN_CACHE_FOLDER)
  displayName: Cache Maven local repo

- script: mvn install -B -e

Maven タスクを使用している場合は、MAVEN_OPTS 変数が上書きされないようにするため、必ず渡してください。

- task: Maven@4
  inputs:
    mavenPomFile: 'pom.xml'
    mavenOptions: '-Xmx3072m $(MAVEN_OPTS)'

PackageReferences を使用してプロジェクトファイル内で直接 NuGet 依存関係を管理し、packages.lock.json ファイルがある場合は、NUGET_PACKAGES 環境変数を $(UserProfile) のパスに設定し、このディレクトリをキャッシュすることで、キャッシュを有効にすることができます。依存関係をロックする方法の詳細については、プロジェクトファイル内のパッケージ参照およびをご覧ください。

複数の packages.lock.jsonを使用する場合でも、変更を加えずに次の例を使用できます。すべての packages.lock.json ファイルの内容がハッシュされ、いずれかのファイルが変更されると、新しいキャッシュキーが生成されます。

例の:

variables:
  NUGET_PACKAGES: $(Pipeline.Workspace)/.nuget/packages

steps:
- task: Cache@2
  inputs:
    key: 'nuget | "$(Agent.OS)" | $(Build.SourcesDirectory)/**/packages.lock.json'
    restoreKeys: |
       nuget | "$(Agent.OS)"
       nuget
    path: $(NUGET_PACKAGES)
  displayName: Cache NuGet packages

この方法は、プロジェクトがパッケージバージョンをロックするために packages.lock.json を使用している場合、.NET Core プロジェクトでも有効です。これを有効にするには、RestorePackagesWithLockFile を True ファイルにするように設定するか、次のコマンドを使用します dotnet restore --use-lock-file。

Node.js プロジェクトでキャッシュを有効にする方法はさまざまですが、npm の共有キャッシュディレクトリをキャッシュすることをお勧めします。このディレクトリは npm によって管理され、ダウンロードされたすべてのモジュールのキャッシュされたバージョンが含まれています。インストール時に、npm は最初にこのディレクトリをチェックします (既定)。これにより、パブリック npm レジストリまたはプライベートレジストリへのネットワーク呼び出しを減らしたり排除したりできます。

npm の共有キャッシュディレクトリへの既定のパスはプラットフォームによって異なるため、 npm_config_cache 環境変数をオーバーライドし、 $(Pipeline.Workspace)の下のパスに設定することをお勧めします。これにより、コンテナージョブと非コンテナージョブの両方からキャッシュにアクセスできるようになります。

例の:

variables:
  npm_config_cache: $(Pipeline.Workspace)/.npm

steps:
- task: Cache@2
  inputs:
    key: 'npm | "$(Agent.OS)" | package-lock.json'
    restoreKeys: |
       npm | "$(Agent.OS)"
    path: $(npm_config_cache)
  displayName: Cache npm

プロジェクトに package-lock.json ファイルがない場合は、代わりにキャッシュキー入力で package.json ファイルを参照します。

ヒント

npm ciは、一貫性のある反復可能なモジュールセットを確保するためにnode_modulesフォルダーを削除するため、node_modulesを使用する場合はnpm ciキャッシュしないようにします。

npm と同様に、Yarn には、インストールされているパッケージをキャッシュする方法がいくつか用意されています。 Yarn の共有キャッシュフォルダーをキャッシュすることをお勧めします。このディレクトリは Yarn によって管理され、ダウンロードされたすべてのパッケージのキャッシュされたバージョンが格納されます。インストール時に、Yarn は最初にこのディレクトリをチェックします (既定)。これにより、パブリックレジストリまたはプライベートレジストリへのネットワーク呼び出しを減らしたり、排除したりする可能性があります。

例の:

variables:
  YARN_CACHE_FOLDER: $(Pipeline.Workspace)/.yarn

steps:
- task: Cache@2
  inputs:
    key: 'yarn | "$(Agent.OS)" | yarn.lock'
    restoreKeys: |
       yarn | "$(Agent.OS)"
       yarn
    path: $(YARN_CACHE_FOLDER)
  displayName: Cache Yarn packages

- script: yarn --frozen-lockfile

Anaconda 環境でパイプラインキャッシュを設定します。

例

variables:
  CONDA_CACHE_DIR: /usr/share/miniconda/envs

# Add conda to system path
steps:
- script: echo "##vso[task.prependpath]$CONDA/bin"
  displayName: Add conda to PATH

- bash: |
    sudo chown -R $(whoami):$(id -ng) $(CONDA_CACHE_DIR)
  displayName: Fix CONDA_CACHE_DIR directory permissions

- task: Cache@2
  displayName: Use cached Anaconda environment
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA_CACHE_DIR)
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create Anaconda environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

ウィンドウズ

- task: Cache@2
  displayName: Cache Anaconda
  inputs:
    key: 'conda | "$(Agent.OS)" | environment.yml'
    restoreKeys: | 
      python | "$(Agent.OS)"
      python
    path: $(CONDA)/envs
    cacheHitVar: CONDA_CACHE_RESTORED

- script: conda env create --quiet --file environment.yml
  displayName: Create environment
  condition: eq(variables.CONDA_CACHE_RESTORED, 'false')

Composer を使用する PHP プロジェクトの場合は、Composer で使用環境変数をオーバーライドします。

例の:

variables:
  COMPOSER_CACHE_DIR: $(Pipeline.Workspace)/.composer

steps:
- task: Cache@2
  inputs:
    key: 'composer | "$(Agent.OS)" | composer.lock'
    restoreKeys: |
      composer | "$(Agent.OS)"
      composer
    path: $(COMPOSER_CACHE_DIR)
  displayName: Cache composer

- script: composer install

既知の問題とフィードバック

パイプラインでのキャッシュの設定で問題が発生した場合は、リポジトリでmicrosoft/azure-pipelines-tasksの一覧を確認してください。問題が一覧に表示されない場合は、新しい問題を作成し、シナリオに関する必要な情報を提供してください。

Q&A(質疑応答)

Q: キャッシュをクリアできますか?

A: キャッシュのクリアはサポートされていません。ただし、キャッシュキーに文字列リテラル ( version2 など) を追加することで、既存のキャッシュでのヒットを回避できます。たとえば、次のキャッシュキーをこのキーから変更します。

key: 'yarn | "$(Agent.OS)" | yarn.lock'

これに対して:

key: 'version2 | yarn | "$(Agent.OS)" | yarn.lock'

Q: キャッシュの有効期限はいつですか?

A: キャッシュは、アクティビティがない状態が7日間続くと期限切れになります。

Q: キャッシュはいつアップロードされますか?

A: 指定した path からキャッシュが作成され、ジョブの最後のステップの後にアップロードされます。詳細については、の例を参照してください。

Q: キャッシュのサイズに制限はありますか。

A: 組織内の個々のキャッシュのサイズやキャッシュの合計サイズに対する制限は適用されません。

次の方法で共有

パイプライン キャッシュ