組織のGitHub Actionsの無効化または制限

組織のGitHub Actionsを有効、無効、および制限できます。

この機能を使用できるユーザーについて

Organization owners can enable, disable, and limit GitHub Actions for an organization.

この記事で

組織の GitHub Actions アクセス許可について

既定では、GitHub Actions の後の GitHub Actions ですべてのリポジトリと組織で有効になります。 GitHub Actions を無効にするか、または Organization のアクションと再生可能なワークフローに制限することができます。 GitHub Actionsの詳細については、「ワークフローの書き込み」を参照してください。

組織内のすべてのリポジトリに対して GitHub Actions を有効にすることができます。 GitHub Actions を有効にすると、ワークフローはリポジトリ内および他のパブリックリポジトリに配置されているアクションと再利用可能なワークフローを実行できます。 組織内のすべてのリポジトリの GitHub Actions を無効にすることができます。 GitHub Actionsを無効化すると、リポジトリでワークフローが実行されなくなります。

または、組織内のすべてのリポジトリで GitHub Actions を有効にすることもできますが、ワークフローが実行できるアクション および再利用可能なワークフロー は制限できます。

組織の GitHub Actions アクセス許可の管理

組織内のすべてのリポジトリに対して GitHub Actions を無効にすることも、特定のリポジトリのみを許可することもできます。 パブリック アクション再利用可能なワークフローの使用を制限して、ユーザーがローカル アクションと再利用可能なワークフローのみを使用できるようにorganizationに存在するようにすることもできます。

メモ

組織が、優先ポリシーのあるエンタープライズによって管理されている場合、これらの設定を管理できない場合があります。 詳しくは、「企業でGitHub Actionsのポリシーを適用する」をご覧ください。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. [Policies] で、オプションを選択します。

    **[Allow _OWNER_, and select non-_OWNER_, actions and reusable workflows]\(所有者を許可し、非所有者、アクション、再利用可能なワークフローを選択する\)**  を選択した場合、組織内のアクションおよび再利用可能なワークフローが許可され、追加のオプションで、その他の特定のアクションや再利用可能なワークフローも許可されます。 詳細については、「[選択したアクションと再利用可能なワークフローの実行の許可](#allowing-select-actions-and-reusable-workflows-to-run)」を参照してください。

    組織からのみ再利用可能なワークフローとアクションを許可する場合、ポリシーにより GitHub で作成したアクションへのすべてのアクセスがブロックされます。 たとえば、actions/checkout アクションにはアクセスできません。

    [Require actions to be pinned to a full-length commit SHA] を有効にすると、すべてのアクションは、使用するには完全な長さのコミット SHA に固定する必要があります。 これには、organization からのアクションと、GitHub によって作成されたアクションが含まれます。 再利用可能なワークフローは、引き続きタグで参照できます。詳細については、「セキュリティで保護された使用に関するリファレンス」を参照してください。

  6. [保存] をクリックします。

選択アクション 再利用可能なワークフロー 実行を許可する

[Allow OWNER, and select non-OWNER, actions and reusable workflows](所有者を許可し、非所有者、アクション、再利用可能なワークフローを選択する) を選択すると、ローカル アクション再利用可能なワークフローが許可され、他の特定のアクション再利用可能なワークフローを許可するための追加のオプションがあります

メモ

Organization に優先ポリシーがある場合、または優先ポリシーのある Enterprise によって管理されている場合は、これらの設定を管理できない場合があります。 詳細については、「組織のGitHub Actionsの無効化または制限」または「企業でGitHub Actionsのポリシーを適用する」を参照してください。

  • **GitHubによって作成されたアクションを許可する:**GitHubによって作成されたすべてのアクションをワークフローで使用することを許可できます。 GitHubによって作成されたアクションは、actionsおよびgithub組織にあります。 詳細については、「actions および github 組織」を参照してください。

  • 認証済みの作成者による Marketplace アクションを許可: 検証済みの作成者によって作成されたすべての GitHub Marketplace アクションをワークフローで使用することを許可できます。 GitHubがパートナー組織としてアクションの作成者を確認すると、のアクションの横にGitHub Marketplace バッジが表示されます。

  • 許可 またはブロック 指定されたアクション 再利用可能なワークフロー: 特定の組織やリポジトリでアクション 再利用可能なワークフロー を使用するようにワークフローを制限できます。 指定したアクションは、1000 を超えるアクションに設定できません。

    特定のタグへのアクセスを制限したり、アクション または再利用可能なワークフローの SHA をコミットしたりするにはワークフローで使用されるのと同じ構文を使用して、アクション または再利用可能なワークフローを選択します。

    • アクションの場合の構文は、OWNER/REPOSITORY@TAG-OR-SHA です。 たとえば、タグを選択するには actions/javascript-action@v1.0.1 を使用し、SHA を選択するには actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f を使用します。 詳しくは、「ワークフローで事前に作成されたビルディング ブロックを使用する」をご覧ください。
    • 再利用可能なワークフローの場合の構文は、OWNER/REPOSITORY/PATH/FILENAME@TAG-OR-SHA です。 たとえば、「 octo-org/another-repo/.github/workflows/workflow.yml@v1 」のように入力します。 詳しくは、「ワークフローを再利用する」をご覧ください。

    パターンのマッチには、ワイルドカード文字 * を使用できます。 たとえば、で始まる組織のすべてのアクションワークフローspace-org再利用可能なワークフローを許可するには、space-org*/*を指定できます。 octocat で始まるリポジトリ内のすべてのアクション ワークフロー 再利用可能なワークフローを許可するには、 */octocat**@*を使用できます。 * ワイルドカードの使用の詳細については、「GitHub Actions　のワークフロー構文」を参照してください。

, を使用して、パターンを区切ります。 たとえば、および組織からのすべてのアクションoctocatおよび再利用可能なワークフローoctokitを許可するには、octocat/*, octokit/*を指定できます。

パターンをブロックするには、 ! プレフィックスを使用します。 たとえば、組織のすべてのアクション再利用可能なワークフローspace-orgを許可し、space-org/actionなどの特定のアクションをブロックするには、space-org/*, !space-org/action@*を指定できます。 既定では、一覧で指定されたアクション および再利用可能なワークフロー のみが許可されます。 すべてのアクションと再利用可能なワークフローを許可しつつ、特定のアクションをブロックするには、*, !space-org/action@*を指定できます。

この手順では、特定のアクション 再利用可能なワークフロー を一覧に追加する方法を示します。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. [ポリシー] で [Allow OWNER, and select non-OWNER, actions and reusable workflows](所有者を許可し、非所有者、アクション、再利用可能なワークフローを選択する) を選択し、必要なアクション 再利用可能なワークフロー を一覧に追加します。

  6. [保存] をクリックします。

セルフホステッド ランナーの使用を制限する

GitHub のセルフホステッド ランナーがエフェメラルでクリーンな仮想マシン上でホストされる保証はありません。 その結果、ワークフロー内の信頼できないコードによって侵害される可能性があります。

同様に、リポジトリをフォークしてプル リクエストを開くことができるユーザー (通常は、リポジトリへの読み取りアクセス権を持つユーザー) は、セルフホステッド ランナー環境を侵害する可能性があります。それには、シークレットへのアクセスや、リポジトリへの書き込みアクセス権を設定に応じて付与できる GITHUB_TOKEN の取得が含まれます。 ワークフローは、環境と必要なレビューを使用して環境シークレットへのアクセスを制御できますが、これらのワークフローは分離された環境では実行されず、セルフホストランナーで実行した場合でも同じリスクの影響を受けやすくなります。

このような理由やその他の理由から、ユーザーがリポジトリ レベルでセルフホステッド ランナーを作成できないようにすることができます。

リポジトリの使用を無効にしたとき、既にセルフホステッド ランナーがあった場合、これらは "無効" の状態で一覧表示され、新しいワークフロー ジョブを割り当てることができません。

"ランナー"の一覧の状態が "無効" のセルフホステッド ランナーを示すスクリーンショット。

メモ

リポジトリ レベルのセルフホステッド ランナーが作成できなくなっている場合でも、ワークフローは Enterprise レベルまたは Organization レベルのセルフホステッド ランナーにアクセスできます。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. "ランナー" で、ドロップダウン メニューを使って好みの設定を選びます。

    • すべてのリポジトリ - セルフホステッド ランナーは、Organization 内の任意のリポジトリで使えます。
    • 選択したリポジトリ - セルフホステッド ランナーは、選んだリポジトリでのみ使えます。
    • 無効 - セルフホステッド ランナーはリポジトリ レベルで作ることはできません。

  6. 選択したリポジトリ を選択した場合は、次のようにします。

    1. をクリックします。
    2. セルフホステッド ランナーを許可するリポジトリのチェック ボックスをオンにします。
    3. リポジトリの選択 をクリックします。

標準のホストランナーの無効化

標準 GitHub ホステッド ランナーは、組織レベルで無効化できます。 この設定では、ランナー グループを介してランナーをターゲットにするワークフローが必要であり、一貫したアクセス制御とガバナンスを適用するのに役立ちます。

GitHub でホストされるランナーのジョブの同時実行制限については、アクションの制限 を参照してください。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. [Standard hosted runners](標準のホストランナー) セクションまでスクロールし、[ Disable for all repositories](すべてのリポジトリに対して無効にする) をクリックします。

  6. [保存] をクリックします。

パブリックフォークからのワークフローに対する必須の承認の設定

誰でもパブリック リポジトリをフォークし、リポジトリの GitHub Actions ワークフローへの変更を提案するプル要求を送信できます。 フォークからのワークフローはシークレットなどの機密データにアクセスできませんが、悪用目的で変更された場合、メンテナが迷惑を被る可能性があります。

これを防ぐために、外部コラボレータのパブリックリポジトリへのPull Requestではワークフローは自動的には動作せず、まず承認が必要になることがあります。 [Approval for running fork pull request workflows from contributors] の設定によっては、パブリック リポジトリに対するプルリクエストのワークフローは自動的に実行されず、次の場合は承認が必要になることがあります。

  • pull request は、選択したポリシーに基づいて承認を必要とするユーザーによって作成される。
  • pull request イベントは、選択したポリシーに基づいて承認を必要とするユーザーによってトリガーされる。

デフォルトでは、すべての初めてのコントリビューターは、ワークフローを実行するのに承認を必要とします。

pull_request_target イベントによってトリガーされるワークフローは、ベース ブランチのコンテキストで実行されます。 ベース ブランチは信頼済みと見なされるため、承認設定に関係なく、これらのイベントによってトリガーされるワークフローは常に実行されます。 pull_request_target イベントの詳細については、「ワークフローをトリガーするイベント」を参照してください。

警告

これらのワークフロー承認ポリシーは、 GitHub Actions ランナーでワークフローを実行できるユーザーのセットを制限することを目的としており、 GitHubホストランナーを使用すると、予期しないリソースとコンピューティングの消費につながる可能性があります。 自己ホストランナーを使用している場合、設定された承認ポリシーでの承認をユーザーがバイパスすることが許可されているか、pull request が承認されていると、悪意のある可能性のあるユーザーが制御するワークフロー コードが自動的に実行されます。 インフラストラクチャでこのコードを実行するリスクを考慮する必要があり、使用されている承認設定に関係なく、自己ホストランナーのセキュリティに関する推奨事項を確認して従う必要があります。 「セキュリティで保護された使用に関するリファレンス」をご覧ください。

Organizationのこの動作は、以下の手順で設定できます。 この設定を変更すると、Enterpriseレベルでの設定が上書きされます。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. コントリビューターからのフォーク プルリクエスト ワークフローの実行の承認 で、そのユーザーによるプルリクエストに対してワークフローを実行する前に承認が必要となるユーザーの範囲を選択します。 pull request の作成者と、ワークフローをトリガーする pull request イベントのアクターの両方がチェックされて、承認が必要かどうかを判断されます。 承認が必要な場合、リポジトリへの書き込みアクセス権限を持つユーザーが、実行される pull request ワークフローを承認する必要があります。 「フォークからのワークフロー実行の承認」を参照してください。

    警告

    初めてのコントリビューターに対してのみ承認を要求する場合 (最初の 2 つの設定)、リポジトリにコミットまたは pull request をマージしたことのあるユーザーは承認を必要としません。 悪意のあるユーザーは、作成した pull request の一部として、または別のユーザーの pull request の一部として、単純な入力ミスや他の無害な変更をメンテナに受け入れさせることで、この要件を満たす可能性があります。

    • GitHub に初めて参加するコントリビューターの承認を必須にする GitHubの新規ユーザーであり、かつこのリポジトリにコミットまたはプルリクエストが一度もマージされたことがないユーザーのみ、ワークフローの実行に承認が必要です。
    • 初めての共同作成者の承認が必要です。 このリポジトリにコミットまたは pull request をマージしたことがないユーザーについてのみ、ワークフローを実行するための承認が必要です。
    • [Require approval for all external contributors] このリポジトリのメンバーまたは所有者ではないすべてのユーザー、および organization のメンバーではないすべてのユーザーは、ワークフローを実行するために承認が必要です。

  6. [保存] をクリックして設定を適用します。

このポリシーが適用されるワークフロー実行の承認の詳細については、「フォークからのワークフロー実行の承認」を参照してください。

プライベートリポジトリのフォークのワークフローを有効にする

プライベート リポジトリのフォークの利用に依存している場合、pull_request イベントの際にユーザーがどのようにワークフローを実行できるかを制御するポリシーを構成できます。 プライベート リポジトリでのみ使用でき、組織またはリポジトリに対してこれらのポリシー設定を構成できます。

組織でポリシーが無効になっている場合、リポジトリに対してポリシーを有効にすることはできません。 Organizationがポリシーを有効化していると、そのポリシーを個々のリポジトリで無効化することはできません。

  • フォーク pull request からワークフローを実行する - 読み取り専用権限を持ち、シークレットへのアクセス権を持たない GITHUB_TOKEN を使用して、フォーク pull request からワークフローを実行できます。
  • pull request からワークフローに書き込みトークンを送信する - フォークからの pull request で書き込み権限を持つ GITHUB_TOKEN を使用できます。
  • pull request からワークフローにシークレットを送信する - すべてのシークレットを pull request で利用できるようにします。
  • フォークの pull request ワークフローに対して承認を要求する - 書き込みアクセス許可のないコラボレーターからの pull request に対するワークフロー実行には、実行する前に書き込みアクセス許可を持つ誰かからの承認が必要になります。

Organization のプライベートフォークポリシーを設定する

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  2. 組織をクリックして選択します。

  3. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  4. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  5. [Fork pull request workflows](pull request ワークフローのフォーク) で、オプションを選択します。

  6. [保存] をクリックして設定を適用します。

組織の GITHUB_TOKEN のアクセス許可の設定

GITHUB_TOKEN に付与される既定のアクセス許可を設定できます。 GITHUB_TOKEN の詳細については、「ワークフローでの認証に GITHUB_TOKEN を使用する」を参照してください。 デフォルトとして制限付きアクセス許可セットを選択するか、より幅広く許可をする設定を適用できます。

組織またはリポジトリの設定で、GITHUB_TOKEN の既定のアクセス許可を設定できます。 Organization の設定でデフォルトとして制限付きのオプションを選択した場合、そのオプションは Organization 内のリポジトリの設定でも選択され、制限の緩いオプションは無効化されます。 組織が GitHub Enterprise アカウントに属していて、エンタープライズ設定でより制限の厳しい既定値が選択されている場合、組織の設定で制限の厳しい既定値を選択することはできません。

リポジトリへの書き込みアクセス権を持っている人は誰でも、ワークフロー ファイルの GITHUB_TOKEN キーを編集して、permissions に付与されたアクセス許可を変更でき、必要に応じて追加または削除できます。 詳細については、permissions をご覧ください。

既定の GITHUB_TOKEN のアクセス許可の構成

既定では、新しい組織を作成すると、 GITHUB_TOKEN は、 contents スコープと packages スコープに対する読み取りアクセス権のみを持ちます。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  3. 組織をクリックして選択します。

  4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  6. [Workflow permissions] で、GITHUB_TOKEN に対してすべてのアクセス許可での読み取りと書き込みのアクセスを許可するか (制限の緩い設定)、contents と packages アクセス許可での読み取りアクセスのみを許可するか (制限の厳しい設定) を選びます。

  7. [保存] をクリックして設定を適用します。

GitHub Actionsがプル要求を作成または承認できないようにする

GitHub Actions ワークフローでの pull request の作成または承認を許可するか禁止するかを選択できます。

既定では、新しい organization を作成した場合、ワークフローでの pull request の作成または承認は許可されません。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  3. 組織をクリックして選択します。

  4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  6. ワークフローのアクセス許可で、"Allow GitHub Actions to create and approve pull requests" の設定を使用して、GITHUB_TOKEN がプルリクエストを作成および承認できるかどうかを設定します。

  7. [保存] をクリックして設定を適用します。

組織 GitHub Actions キャッシュ ストレージの管理

組織の管理者は、 GitHub Actions キャッシュ ストレージを管理できます。

リポジトリ別 GitHub Actions キャッシュ ストレージの表示

Organization 内の各リポジトリについて、リポジトリが使用しているキャッシュ ストレージの量、アクティブなキャッシュの数、リポジトリがキャッシュ サイズの合計の上限に近いかどうかを確認できます。 キャッシュの使用と削除のプロセスについて詳しくは、「依存関係キャッシュのリファレンス」を参照してください。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  3. 組織をクリックして選択します。

  4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  5. 左側のサイドバーで、「 アクション」 をクリックし、「 キャッシュ」をクリックします。

  6. GitHub Actions キャッシュに関する情報については、リポジトリの一覧を確認してください。 リポジトリ名をクリックすると、リポジトリのキャッシュの詳しい情報を表示できます。

組織の GitHub Actions キャッシュ設定を構成する

組織内のすべてのリポジトリに適用されるキャッシュリテンション期間とサイズの設定を構成できます。 この機能は選択式で、登録済みの支払い方法を持つユーザーが利用可能です。

組織がキャッシュ設定を構成した企業が所有している場合は、企業によって設定された最大値までの制限のみを構成できます。 組織が企業によって所有されていない (または企業がキャッシュ設定を構成していない) 場合は、グローバル最大値まで構成できます。

リポジトリ管理者は、リポジトリの制限を構成することを選択できますが、組織レベルで設定されている制限を超えることはできません。

  1. GitHub の右上隅にあるプロフィール画像をクリックしてから、[Your profile] をクリックします。

    @octocat のプロファイル写真の下にあるドロップダウン メニューのスクリーンショット。 [自分のプロファイル] が濃いオレンジ色の枠線で囲まれています。

  2. GitHub の右上隅にあるプロフィール画像をクリックしてから、[ Your organizations] をクリックします。

  3. 組織をクリックして選択します。

  4. Organization 名の下で、[ Settings] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    組織のプロファイルのタブのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で囲まれています。

  5. 左側のサイドバーで、 [Actions] をクリックしてから [General] をクリックします。

  6. [キャッシュ] セクションで、次の設定に対する変更を構成して保存します。

    • キャッシュリテンション期間: キャッシュを保持してから自動削除するまでの最大日数。 既定値は 7 日です。 最大 365 日 (または企業が設定した上限まで) を構成できます。 [ 保存] をクリックして、行った変更を適用します。
    • キャッシュ サイズの削除制限: リポジトリ内のすべてのキャッシュの最大合計サイズ。 既定値は 10 GB です。 リポジトリあたり最大 10,000 GB を構成できます (または、企業によって設定された上限まで)。 この制限を超えると、古いキャッシュが削除され、新しいキャッシュ用のスペースが作成されます。 [ 保存] をクリックして、行った変更を適用します。

キャッシュの削除の詳細については、「 依存関係キャッシュのリファレンス」を参照してください。