{"meta":{"title":"Dependabot オプションリファレンス","intro":"リポジトリの管理方法をカスタマイズするために使用できるすべてのオプションの詳細情報 Dependabot 。","product":"セキュリティとコードの品質","breadcrumbs":[{"href":"/ja/code-security","title":"セキュリティとコードの品質"},{"href":"/ja/code-security/reference","title":"リファレンス"},{"href":"/ja/code-security/reference/supply-chain-security","title":"サプライチェーンのセキュリティ"},{"href":"/ja/code-security/reference/supply-chain-security/dependabot-options-reference","title":"Dependabot オプション"}],"documentType":"article"},"body":"# Dependabot オプションリファレンス\n\nリポジトリの管理方法をカスタマイズするために使用できるすべてのオプションの詳細情報 Dependabot 。\n\nこの記事では、 `dependabot.yml` ファイルで使用できる構成オプションのリファレンス情報を提供します。これらのオプションを使用して、 Dependabot がパッケージエコシステムを監視し、更新プログラムをスケジュールし、プル要求を作成する方法をカスタマイズします。\n`dependabot.yml` ファイルの概要とそのしくみについては、[dependabot.yml ファイルについて](/ja/code-security/concepts/supply-chain-security/about-the-dependabot-yml-file) を参照してください。\n\n```\n アイコンでマークされているすべてのオプションは、Dependabot が使用されていない限り、`target-branch` によるセキュリティ更新プログラムの pull request 作成方法も変更します。\n```\n\n### 必要なキー\n\n| Key | ロケーション | 目的 |\n| --------- | ------ | -- |\n| `version` | 最上位レベル | |\n\n```\n Dependabot 使用する構成構文。 Always (常に)`2`。|\n```\n\n\\| `updates` | 最上位レベル| 更新する各 `package-ecosystem` を定義するセクション。|\n\\| [`package-ecosystem`](#package-ecosystem-) |\n`updates` の下 | 更新するパッケージマネージャーを定義します。 |\n\\| [\n`directories` または `directory`](#directories-or-directory--) | 各 `package-ecosystem` エントリの下 | 更新対象となるマニフェストまたはその他の定義ファイルの場所を定義します。 |\n\\| [`schedule.interval`](#schedule-) | 各 `package-ecosystem` エントリの下 | バージョンの更新プログラム ( `daily`、 `weekly`、 `monthly`、 `quarterly`、 `semiannually`、 `yearly`、または `cron`) を検索するかどうかを定義します。 |\n\n必要に応じて、最上位レベルの `registries` キーを含めて、プライベートレジストリのアクセス詳細を定義することもできます。「[最上位レベルの `registries` キー](#top-level-registries-key)」を参照してください。\n\n```yaml copy\n\n# Basic `dependabot.yml` file with\n# minimum configuration for two package managers\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates every day (weekdays)\n schedule:\n interval: \"daily\"\n\n # Enable version updates for Docker\n - package-ecosystem: \"docker\"\n # Look for a `Dockerfile` in the `root` directory\n directory: \"/\"\n # Check for updates once a week\n schedule:\n interval: \"weekly\"\n```\n\n```\n `dependabot.yml` ファイルの実際の例については、[Dependabot独自の構成ファイル](https://github.com/dependabot/dependabot-core/blob/main/.github/dependabot.yml)を参照してください。\n```\n\n##\n\n```\n `allow`\n \n \n \n```\n\nパッケージエコシステムに対してどの依存関係を保持するかを正確に定義するために使います。多くの場合、[`ignore`](#ignore--) オプションと共に使われます。例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* マニフェストで明示的に定義されているすべての依存関係は、バージョンの更新によって最新の状態に保たれます。\n* 脆弱な依存関係を持つロックファイルで定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。\n\n ```\n `allow`を指定Dependabot場合は、次のプロセスを使用します。\n ```\n\n1. 明示的に**許可した**依存関係をすべてチェックします。\n2. 次に、**無視された**依存関係またはバージョンを除外します。\n\n 依存関係が `allow` と `ignore` ステートメントと一致する場合、依存関係は**無視されます**。\n\n| パラメーター | 目的 |\n| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | 名前が一致する依存関係の更新を許可します。必要に応じて、0 文字以上に一致させるために `*` を使用できます。 |\n| `dependency-type` | 特定の種類の依存関係に対する更新を許可します。 |\n| | |\n| `update-types` | 1 つ以上のセマンティックバージョン管理レベルの更新を許可します。サポートされている値: `version-update:semver-patch`、`version-update:semver-minor`、および `version-update:semver-major`。 |\n| | |\n\n###\n\n```\n `dependency-name` (`allow`)\n```\n\nほとんどのパッケージマネージャーでは、ロックまたはマニフェストファイルで指定された依存関係名と一致する値を定義する必要があります。一部のシステムには、より複雑な要件があります。\n\n| パッケージマネージャー | 必要な形式 | Example |\n| ---------------- | -------------------- | ------------------------ |\n| Gradle と Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| イメージタグ用の Docker | リポジトリのフルネーム | |\n\n```\n `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` のイメージタグには、`base/foo/bar/ruby` を使います。|\n```\n\n###\n\n```\n `dependency-type` (`allow`)\n```\n\n| 依存関係の種類 | パッケージマネージャーによるサポート | 更新の許可 |\n| ---------- | ------------------ | ------------------ |\n| `direct` | All | 明示的に定義されたすべての依存関係。 |\n| `indirect` | | |\n\n```\n `bundler`、 `pip`、 `composer`、 `cargo`、 `gomod`、 `uv` | 直接依存関係 (サブ依存関係または推移的依存関係とも呼ばれます) の依存関係。|\n```\n\n\\| `all` | All | 明示的に定義されたすべての依存関係。\n`bundler`、`pip`、`composer`、`cargo`、`gomod`、`uv`の場合、直接依存関係の依存関係も含まれます。|\n\\| `production` |\n`bundler`、 `composer`、 `mix`、 `maven`、 `npm`、 `pip`、 `uv` (すべてのマネージャーではない) | パッケージマネージャーによって運用依存関係として定義された依存関係のみ。 |\n\\| `development`|\n`bundler`、 `composer`、 `mix`、 `maven`、 `npm`、 `pip`、 `uv` (すべてのマネージャーではない) | パッケージマネージャーによって開発依存関係として定義された依存関係のみ。 |\n\n###\n\n```\n `update-types` (`allow`)\n\n `update-types` は _バージョン_ 更新プログラムにのみ影響し、 _セキュリティ更新プログラム_には影響しません。\n```\n\n許可するセマンティックバージョン (SemVer) を指定します。\n\nSemVer は、`x.y.z` の形式でソフトウェアパッケージのバージョンを定義するための標準として認められています。\nDependabot は、この形式のバージョンが常に `major.minor.patch`されることを前提としています。\n`update-types`値は、1 つ以上の文字列のリストです。\n\n* `version-update:semver-patch`を使用して、パッチのリリースを許可します。\n* マイナーリリースを許可するには、 `version-update:semver-minor` を使用します。\n* メジャーリリースを許可するには、 `version-update:semver-major` を使用します。\n\n ```\n `update-types`ルールから`allow`を省略すると、そのルールのすべての更新の種類が許可されます。\n\n `update-types`を`dependency-name`または`dependency-type`と組み合わせて、許可される更新プログラムをさらに絞り込むことができます。これらのオプションを組み合わせる方法の例については、 [AUTOTITLE を](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-semantic-versioning-levels-for-updates)参照してください。\n ```\n\n##\n\n```\n `assignees`\n \n \n \n```\n\nパッケージエコシステムで作成されるすべてのプルリクエストに、個別の担当者を指定します。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* Pull request は担当者なしで作成されます。\n\n ```\n `assignees` が定義されている場合：\n ```\n\n* バージョン更新のすべてのプル要求は、選択した担当者で作成されます。\n\n* 既定以外のブランチへの更新を定義 `target-branch` 場合を除き、セキュリティ更新プログラムに対するすべてのプル要求は、選択した担当者によって作成されます。\n\n担当者はリポジトリへの書き込みアクセス権限を持っている必要があります。 Organization が所有するリポジトリの場合、読み取りアクセス権を持つ organization メンバーも有効な担当者です。\n\n##\n\n```\n `commit-message`\n \n \n \n```\n\nコミットメッセージの形式を定義します。 Pull request のタイトルはコミットメッセージに基づいて記述されるため、この設定は pull request のタイトルにも影響します。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* コミットメッセージは、リポジトリで検出されたものと同様のパターンに従います。\n\n ```\n `commit-message` が定義されている場合：\n ```\n\n* すべてのコミットメッセージは、定義されたパターンに従います。\n\n* 既定以外の分岐に対する更新を定義 `target-branch` 場合を除き、すべてのコミットメッセージは定義されたパターンに従います。\n\n| パラメーター | 目的 |\n| -------------------- | ---------------------------------------------------------------------- |\n| `prefix` | すべてのコミットメッセージと pull request のタイトルのプレフィックスを定義します。 |\n| `prefix-development` | サポートされているシステム上で、Development 依存関係グループ内の依存関係を更新するコミットに使う別のプレフィックスを定義します。 |\n| `include` | コミットメッセージのプレフィックスの後にその他の情報を入力します。 |\n\n> \\[!TIP]\n> グループ化された更新に対して pull request が生成されると、ブランチ名と pull request のタイトルはグループ `IDENTIFIER` によって定義されます。「[`groups`](#groups--)」を参照してください。\n\n### `prefix`\n\n* `prefix-development` も定義されていない場合、すべてのコミットメッセージに使われます。\n* 値は最大 50 文字まで使用できます。\n* Dependabot は、値が文字、数字、閉じ丸括弧、または閉じ角括弧で終わるときに、メインのコミットメッセージを追加する前に、プレフィックスの後にコロンを挿入します。\n* コロンの追加を停止するには、値の末尾を空白文字にします。\n\n### `prefix-development`\n\nサポート対象: `bundler`、 `composer`、 `mix`、 `maven`、 `npm`、 `pip`、 `uv`。\n\n* Development 依存関係グループ内の依存関係を更新するコミットメッセージにのみ使われます。\n* それ以外の場合、パラメーターは `prefix` パラメーターとまったく同じように動作します。\n\n### `include`\n\n* 値 `scope` のみをサポートします\n* 定義すると、プレフィックスの後にコミットで更新される依存関係の種類 (`deps` または `deps-dev`) が続きます。\n\n##\n\n```\n `cooldown`\n \n \n```\n\n依存関係の更新の**クールダウン期間**を定義し、構成可能な日数だけ更新を延期することができます。\n`cooldown` オプションは、\\_バージョン\\_更新プログラムでのみ使用でき、\\_セキュリティ\\_更新プログラムでは使用できません。\n\nこの機能を使用すると、ユーザーは新しいバージョンの更新プログラム Dependabot 生成する頻度をカスタマイズでき、更新頻度をより詳細に制御できます。例については、「[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates#setting-up-a-cooldown-period-for-dependency-updates)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* `schedule.interval` で定義したスケジュールに従って更新がチェックされます。\n* すべての新しいバージョンは**すぐに**更新対象として検討されます。\n\n ```\n **\n `cooldown`\n ** が定義されている場合：\n ```\n\n1. ```\n Dependabot は、定義された `schedule.interval` 設定に従って更新プログラムをチェックします。\n ```\n2. ```\n Dependabot は、クールダウン設定をチェックします。\n ```\n3. 依存関係の新しいリリースがクールダウン期間内にある場合、 Dependabot はその依存関係のバージョンの更新をスキップします。\n4. クールダウン期間のない依存関係、またはクールダウン期間を過ぎた依存関係は、構成した `versioning-strategy` 設定に従って最新バージョンに更新されます。\n5. 依存関係のクールダウンが終了した後、 Dependabot は、 `dependabot.yml`で定義されている標準的な更新戦略に従って依存関係の更新を再開します。\n\n###\n\n```\n **\n `cooldown` の構成**\n```\n\n以下のオプションを使ってクールダウンの期間を指定できます。\n\n| パラメーター | Description |\n| ------------------- | ------------------------------------ |\n| `default-days` | 特定の規則のない**依存関係の既定のクールダウン期間** (省略可能)。 |\n| `semver-major-days` | |\n\n```\n **メジャーバージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージマネージャーにのみ適用されます)。 |\n```\n\n\\| `semver-minor-days` |\n**マイナーバージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージマネージャーにのみ適用されます)。 |\n\\| `semver-patch-days` |\n**パッチバージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージマネージャーにのみ適用されます)。 |\n\\| `include` |\n**クールダウンを適用**する依存関係のリスト (最大 **150 項目**)。ワイルドカードのサポート (`*`). |\n\\| `exclude` |\n**クールダウンから除外する**依存関係のリスト (最大 **150 項目**)。ワイルドカードのサポート (`*`). |\n\n以下の表は、SemVer をサポートするパッケージマネージャーをまとめたものです。\n\n| パッケージマネージャー | SemVer がサポートされています |\n| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| | |\n| Bazel | |\n| | |\n| Bundler | |\n| Bun | |\n| 貨物 | |\n| Composer | |\n| Devcontainers | |\n| Docker | |\n| Docker Compose | |\n| Dotnet SDK | |\n| Elm | |\n| GitHub Actions | |\n| Gitsubmodule | |\n| Gomod (Go モジュール) | |\n| Gradle | |\n| Helm | |\n| 16 進 (16 進) | |\n| | |\n| Julia | |\n| | |\n| Maven | |\n| NPM と Yarn | |\n| NuGet | |\n| | |\n| OpenTofu | |\n| | |\n| pip | |\n| Pub | |\n| Swift | |\n| Terraform | |\n| UV | |\n\n> \\[!NOTE]\n>\n> *\n\n```\n `semver-major-days`、`semver-minor-days`、または `semver-patch-days` が定義されていない場合、クールダウンベースの更新では `default-days` 設定が優先されます。\n```\n\n> *\n\n```\n `exclude` リストは常に `include` リストよりも優先されます。依存関係が両方のリストに指定されている場合、その依存関係は**クールダウンから除外**され、すぐに更新されます。\n```\n\n##\n\n```\n `directories` または `directory`\n\n **必須オプション**。各パッケージマネージャー (_package.json_ や _Gemfile_ など) のパッケージマニフェストの場所を定義するために使用します。この情報がないと Dependabot バージョン更新のプル要求を作成できません。例については、「[マニフェストファイルの複数の場所を定義する](/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#defining-multiple-locations-for-manifest-files)」を参照してください。\n```\n\n* `directory` を使って、マニフェストのディレクトリを 1 つ定義します。\n\n* `directories` を使って、マニフェストの複数のディレクトリで構成されるリストを定義します。\n\n* ほとんどのパッケージマネージャーのリポジトリのルートに対して相対的なディレクトリを定義します。\n\n* GitHub Actionsの場合は、`/`値を使用します。\n Dependabot では、 `/.github/workflows` ディレクトリとルートディレクトリから `action.yml/action.yaml` ファイルが検索されます。\n\n構成ファイル内で複数のブロックを使ってエコシステムの 1 つのターゲットブランチの更新を定義する必要がある場合は、すべての値が一意であり、定義したディレクトリに重複がないことを確認する必要があります。\n\n> \\[!NOTE]\n\n```\n `directories` キーはグロビングとワイルドカード文字 `*` をサポートしています。これらの機能は `directory` キーではサポートされていません。\n```\n\n##\n\n```\n `enable-beta-ecosystems`\n \n \n```\n\n現在使用できません。\n\n##\n\n```\n `groups`\n \n \n \n```\n\nパッケージマネージャーによって管理される 1 つ以上の依存関係のセットを作成し、更新プログラムを少数の対象を絞った pull request にグループ化するようにルールを定義します。例については、「[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* バージョン更新とセキュリティ更新の場合、新しいバージョンに更新する必要がある依存関係ごとに 1 つの pull request を開きます。\n\n ```\n `groups` を使ってルールを定義する場合:\n ```\n\n* 規則と一致する依存関係のすべての更新は、1 つの pull request に結合されます。\n\n* 依存関係が複数のルールと一致する場合、その依存関係は最初に一致したグループに含まれます。\n\n* 一致するルールがない古い依存関係は、個別の pull request で更新されます。\n\n| パラメーター | 目的 |\n| ------------------ | -------------------------------------------------------------------------------------------------------------------- |\n| `IDENTIFIER` | ブランチ名と pull request のタイトルで使うグループの識別子を定義します。この先頭と末尾は文字にする必要があります。また、文字、パイプ `\\|`、アンダースコア `_`、またはハイフン `-` を含めることができます。 |\n| `applies-to` | グループが適用される更新プログラムの種類を指定します。未定義の場合、既定でバージョン更新プログラムになります。サポートされる値: `version-updates` または `security-updates`。 |\n| `dependency-type` | グループを 1 つの種類に制限します。サポートされる値: `development` または `production`。 |\n| `exclude-patterns` | グループから依存関係を除外するパターンを 1 つ以上定義します。 |\n| | |\n| `group-by` | 複数のディレクトリ間で更新をグループ化します。サポートされる値: `dependency-name`。 |\n| | |\n| `patterns` | 名前が一致する依存関係を含めるパターンを 1 つ以上定義します。 |\n| `update-types` | グループを 1 つ以上のセマンティックバージョニングレベルに制限します。サポートされている値: `minor`、`patch`、および `major`。 |\n\n###\n\n```\n `dependency-type` (`groups`)\n```\n\nサポート： `bundler`、`composer`、`mix`、`maven`、`npm`、および`pip`。\n\n既定では、グループにはすべての種類の依存関係が含まれます。\n\n* \"Development dependency group\" に依存関係のみを含めるには、`development` を使います。\n* \"Production dependency group\" に依存関係のみを含めるには、`production` を使います。\n\n###\n\n```\n `group-by` (`groups`)\n\n `groups..group-by`を使用して、monorepo 内Dependabot複数のディレクトリ間で更新をグループ化する方法を指定します。\n```\n\n* **型:** 文字列\n\n* **受け入れ可能な値:**`dependency-name`\n\n* **適用対象:** 複数のディレクトリが指定された構成\n\n ```\n `dependency-name`に設定すると、Dependabotは、ディレクトリごとに個別のプル要求ではなく、指定されたすべてのディレクトリにわたって依存関係の更新ごとに 1 つのプル要求を作成します。\n\n **ディレクトリ間グループ化の制限事項**\n\n `group-by: dependency-name`を使用する場合:\n ```\n\n* すべてのディレクトリで同じパッケージエコシステムを使用する必要があります (たとえば、すべての `npm` またはすべての `bundler`)\n\n* バージョン更新のみに適用されます\n\n* ディレクトリに依存関係に互換性のないバージョン制約がある場合、 Dependabot は個別のプル要求を作成します\n\n ```\n `group-by`の使用例については、[AUTOTITLE](/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#grouping-updates-across-directories-in-a-monorepo) を参照してください。\n ```\n\n###\n\n```\n `patterns` と `exclude-patterns` (`groups`)\n```\n\nどちらのオプションも、依存関係名との一致を定義する際にワイルドカードとして `*` を使用できます。依存関係がパターンと除外パターンの両方と一致する場合は、グループから除外されます。\n\n###\n\n```\n `update-types` (`groups`)\n```\n\n既定では、グループにはすべてのセマンティックバージョン (SemVer) 更新プログラムが含まれます。 SemVer は、`x.y.z` の形式でソフトウェアパッケージのバージョンを定義するための標準として認められています。 Dependabot は、この形式のバージョンが常に `major.minor.patch` であると想定します。\n\n* パッチリリースを含めるには、`patch` を使います。\n* マイナーリリースを含めるには、`minor` を使います。\n* メジャーリリースを含めるには、`major` を使います。\n\n例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore)」を参照してください。\n\n##\n\n```\n `ignore`\n \n \n \n```\n\nパッケージエコシステムに対してどの依存関係を保持するかを正確に定義するには、[`allow`](#allow--) オプションと共に使います。\nDependabot は、許可されているすべての依存関係をチェックし、無視された依存関係またはバージョンを除外します。許可条件と無視条件の両方で一致する依存関係は、無視されます。例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#ignoring-specific-dependencies)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* マニフェストで明示的に定義されているすべての依存関係は、バージョンの更新によって最新の状態に保たれます。\n* 脆弱な依存関係を持つロックファイルで定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。\n\n ```\n `ignore`を使用する場合、Dependabotは次のプロセスを使用します。\n ```\n\n1. 明示的に**許可した**依存関係をすべてチェックします。\n2. 次に、**無視された**依存関係またはバージョンを除外します。\n\n 依存関係が `allow` と `ignore` ステートメントと一致する場合、依存関係は**無視されます**。\n\n| パラメーター | 目的 |\n| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `dependency-name` | 一致する名前を持つ依存関係の更新を無視します。必要に応じて、ゼロ文字以上に一致する `*` を使用できます。 |\n| `versions` | 特定のバージョンまたはバージョン範囲を無視します。 |\n| `update-types` | 1 つ以上のセマンティックバージョニングレベルへの更新プログラムを無視します。サポートされている値: `version-update:semver-patch`、`version-update:semver-minor`、および `version-update:semver-major`。 |\n\n###\n\n```\n `dependency-name` (`ignore`)\n```\n\nほとんどのパッケージマネージャーでは、ロックまたはマニフェストファイルで指定された依存関係名と一致する値を定義する必要があります。一部のシステムには、より複雑な要件があります。\n\n| パッケージマネージャー | 必要な形式 | Example |\n| ---------------- | -------------------- | ------------------------ |\n| Gradle と Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| イメージタグ用の Docker | リポジトリのフルネーム | |\n\n```\n `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` のイメージタグには、`base/foo/bar/ruby` を使います。|\n```\n\n###\n\n```\n `versions` (`ignore`)\n```\n\n特定のバージョンまたはバージョン範囲を無視するために使います。範囲を定義する場合は、パッケージマネージャーの標準パターンを使います。例えば次が挙げられます。\n\n* npm: `^1.0.0` を使います \n* Bundler: `~> 2.0` を使います\n* Docker: Bundler バージョンの構文を使います\n* NuGet: `7.*` を使います\n* Maven: `[1.4,)` を使用する\n\n例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#ignoring-specific-versions-or-ranges-of-versions)」を参照してください。\n\n###\n\n```\n `update-types` (`ignore`)\n```\n\n無視するセマンティックバージョン (SemVer) を指定します。 SemVer は、`x.y.z` の形式でソフトウェアパッケージのバージョンを定義するための標準として認められています。\nDependabot は、この形式のバージョンが常に `major.minor.patch`されることを前提としています。\n\n* パッチリリースを含めるには、`version-update:semver-patch` を使います。\n* マイナーリリースを含めるには、`version-update:semver-minor` を使います。\n* メジャーリリースを含めるには、`version-update:semver-major` を使います。\n\n##\n\n```\n `insecure-external-code-execution`\n \n \n \n```\n\nサポート: `bundler`、`mix`、および `pip`。\n\n```\n Dependabotが更新中にマニフェストで外部コードを実行できるようにします。例については、「[外部コードの実行を許可する](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot#allowing-external-code-execution)」を参照してください。\n\n Dependabot 既定の動作:\n```\n\n* 1 つ以上のレジストリ Dependabot アクセス権を付与すると、侵害されたパッケージからコードを保護するために外部コードの実行が自動的に無効になります。\n\n* コードを実行できないと、バージョン更新プログラムが失敗する場合があります。\n\n ```\n `insecure-external-code-execution` を許可する場合:\n ```\n\n* Dependabot は、バージョン更新プロセスの一環としてマニフェストでコードを実行します。\n\n* コードは、その `updates` の設定に関連付けられたレジストリ内のパッケージマネージャーにのみアクセスできます。最上位の `registries` 構成で定義されているレジストリへのアクセスは許可されません。\n\n* そのため、更新プログラムは成功するはずですが、侵害されたパッケージが資格情報を盗んだり、構成済みのレジストリにアクセスしたりする可能性もあります。\n\nサポートされる値: `allow`。\n\n##\n\n```\n `labels`\n \n \n \n```\n\nパッケージマネージャーに対して発行されるすべての pull request に独自のラベルを指定します。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* すべての pull request には `dependencies` ラベルが付いています。\n\n* 複数のパッケージマネージャーを定義すると、エコシステムまたは言語の追加ラベルが各 pull request に追加されます。例: Gradle の更新プログラムの場合は `java`、git サブモジュールの更新プログラムの場合は `submodules` です。\n\n* セマンティックバージョン (SemVer) ラベルがリポジトリに存在する場合は、バージョン更新の種類 (`major`、 `minor`、または `patch`) を示すために自動的に適用されます。\n\n* Dependabot は、リポジトリで必要に応じてこれらの既定のラベルを自動的に作成します。\n\n ```\n `labels` が定義されている場合：\n ```\n\n* 指定したラベルは、既定のラベルの代わりに使われます。\n\n* SemVer ラベル (リポジトリに存在する場合) は、定義されているカスタムラベルに加えて適用されます。\n\n* これらのラベルのいずれかがリポジトリで定義されていない場合は無視されます。\n\n* `labels: [ ]` を使用すると、デフォルトのラベルを含むすべてのラベルを無効化できます。\n\n`target-branch` を使って既定以外のブランチのバージョンアップデートをチェックしないかぎり、このオプションの設定も、このパッケージマネージャーのマニフェストファイルに対するセキュリティ更新プログラムの pull request に影響します。\n\n##\n\n```\n `milestone`\n \n \n \n```\n\nパッケージマネージャーにより作成されたすべてのプルリクエストをマイルストーンに関連付けます。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* マイルストーンは使われません。\n\n ```\n `milestone` が定義されている場合：\n ```\n\n* パッケージマネージャーに対するすべての pull request がマイルストーンに追加されます。\n\nサポートされる値: マイルストーンの数値識別子。\n\n> \\[!TIP]\n> マイルストーンを表示した場合、ページの URL の `milestone` より後の最後の部分が識別子になります。例：`https://github.com///milestone/3`、「[マイルストーンの進捗状況を表示する](/ja/issues/using-labels-and-milestones-to-track-work/viewing-your-milestones-progress)」を参照してください。\n\n##\n\n```\n `multi-ecosystem-groups`\n \n \n```\n\n複数のパッケージエコシステムにまたがるグループを定義して、サポートされているすべてのパッケージエコシステムを更新する単一の Dependabot プル要求を取得します。この方法は、受け取る Dependabot プル要求の数を減らし、依存関係の更新ワークフローを合理化するのに役立ちます。\n\n```\n Dependabot 既定の動作:\n```\n\n* 依存関係の更新があるパッケージエコシステムごとに個別の pull request が作成されます。\n\n ```\n `multi-ecosystem-groups` が使用された場合。\n ```\n\n* 同じグループ内の複数のパッケージエコシステムにまたがる更新が、1 つの pull request に結合されます。\n\n* グループには独自のスケジュールがあり、個々のエコシステム設定を継承するか、オーバーライドすることができます。\n\n### `multi-ecosystem-group`\n\n```\n `multi-ecosystem-group` 構成で `updates` パラメーターを使って、個々のパッケージエコシステムをマルチエコシステムグループに割り当てます。\n```\n\n> \\[!IMPORTANT]\n> マルチエコシステムの更新には、特定の構成パターンが必要であり、独自のパラメーターマージ動作があります。詳細なセットアップ手順、構成例、詳細なパラメーターリファレンスについては、「[Dependabot 用にマルチエコシステム更新を構成する](/ja/code-security/tutorials/secure-your-dependencies/configuring-multi-ecosystem-updates)」を参照してください。\n\n```yaml copy\n# Basic `dependabot.yml` file defining a multi-ecosystem-group\nversion: 2\n\nmulti-ecosystem-groups:\n infrastructure:\n schedule:\n interval: \"weekly\"\n\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/\"\n patterns: [\"nginx\", \"redis\"]\n multi-ecosystem-group: \"infrastructure\"\n\n - package-ecosystem: \"terraform\"\n directory: \"/\"\n patterns: [\"aws\"]\n multi-ecosystem-group: \"infrastructure\"\n```\n\n##\n\n```\n `open-pull-requests-limit`\n \n \n```\n\n開いているバージョン更新プログラムの pull request の最大数に関する制限はいつでも変更できます。\n\n```\n Dependabot 既定の動作:\n```\n\n* バージョン更新プログラムを含む pull request が 5 つ開いている場合、それらの開いている request の一部がマージまたは終了されるまで、それ以上の pull request は生成されません。\n\n* セキュリティ更新プログラムには、開いている pull request は 10 件という別の内部制限があり、変更できません。\n\n ```\n `open-pull-requests-limit` が定義されている場合：\n ```\n\n* Dependabot は、定義された整数値までのプル要求を開きます。大きな値を設定して、オープン pull request の制限を効果的に削除できます。\n\n* パッケージマネージャーのバージョン更新プログラムを一時的に無効にするには、このオプションを 0 に設定します。[Dependabot version updatesの無効化を](/ja/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#disabling-dependabot-version-updates)参照してください。\n\n##\n\n```\n `package-ecosystem`\n \n \n```\n\n\n\n```\n **必須オプション。** 新しいバージョンを監視するために`package-ecosystem`において、監視したい各パッケージマネージャーごとに 1 つのDependabot要素を定義します。リポジトリには、各パッケージマネージャー用の依存関係マニフェストまたはロックファイルも含まれている必要があります。[Example `dependabot.yml` file](/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates#example-dependabotyml-file)を参照してください。\n```\n\n| パッケージマネージャー | YAML値 | サポートされているバージョン |\n| ------------ | --------- | :------------: |\n| | | |\n| Bazel | `bazel` | v7、v8、v9 |\n| | | |\n| | | |\n| Bun | `bun` | >=v1.2.5 |\n| | | |\n| Bundler | `bundler` | |\n\n```\n v2 |\n```\n\n\\| 貨物 | `cargo` | v1 |\n\\| Composer | `composer` | v2 |\n\\| |\n\\| Conda | `conda` | 適用なし |\n\\| |\n\\| 開発コンテナー | `devcontainers` | 適用なし |\n\\| Docker | `docker` | v1 |\n\\| |\n\\| Docker Compose | `docker-compose` | v2、v3 |\n\\| |\n\\| |\n\\| .NET SDK | `dotnet-sdk` | >=.NET Core 3.1 |\n\\| |\n\\| |\n\\| Helm チャート | `helm` | v3 |\n\\| |\n\\| Hex | `mix` | v1 |\n\\| |\n\\| Julia | `julia` | >= v1.10 |\n\\| |\n\\| elm-package | `elm` | v0.19 |\n\\| Gitサブモジュール | `gitsubmodule` | 適用なし |\n\\| GitHub Actions | `github-actions` | 適用なし |\n\\| Go モジュール | `gomod` | v1 |\n\\| Gradle | `gradle` | 適用なし |\n\\| Maven | `maven` | 適用なし |\n\\| |\n\\| Nix フレーク | `nix` | 適用なし |\n\\| |\n\\| npm | `npm` | v7、v8、v9、v10 |\n\\| NuGet | `nuget` |\n<=6.12.0 |\n\\| |\n\\| OpenTofu | `opentofu` | 適用なし |\n\\| |\n\\| pip | `pip` | 24.2 |\n\\| pip-compile | `pip` | 7.5.3 |\n\\| pipenv | `pip` | <= 2024.4.1 |\n\\| pnpm | `npm` | v7、v8、v9、v10 |\n\\| poetry | `pip` | v2 |\n\\| |\n\\| pre-commit | `pre-commit` | 適用なし |\n\\| |\n\\| pub | `pub` | v2 |\n\\| |\n\\| Rust ツールチェーン | `rust-toolchain` | 適用なし |\n\\| |\n\\| Swift | `swift` | v5 |\n\\| Terraform | `terraform` | >= 0.13、<= 1.10.x |\n\\| |\n\\| uv | `uv` | v0 |\n\\| |\n\\| |\n\\| vcpkg | `vcpkg` | 適用なし |\n\\| |\n\\| yarn | `npm` | v1、v2、v3、v4 |\n\n##\n\n```\n `pull-request-branch-name.separator`\n \n \n \n```\n\nブランチ名の生成時に使う区切り記号を指定します。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* 次の形式のブランチ名を生成します: `dependabot/PACKAGE_MANAGER/DEPENDENCY`\n\n ```\n `pull-request-branch-name.separator` が定義されている場合：\n ```\n\n* `/` ではなく指定した文字を使います。\n\nサポートされている値: `\"-\"`、`_`、`/`。\n\n> \\[!TIP]\n> ハイフン記号は、空の YAML リストの開始として解釈されないようにエスケープする必要があります。\n\n##\n\n```\n `rebase-strategy`\n \n \n \n\n Dependabotによって発生したプルリクエストの自動リベースを無効にします。\n\n Dependabot 既定の動作としては、バージョンまたはセキュリティ更新のプルリクエストに変更がDependabot 検出されたときに、オープンなプルリクエストをリベースします。 \n Dependabot 次の場合に変更をチェックします。\n```\n\n* バージョン更新プログラムをチェックするスケジュールが実行される。\n* 閉じた Dependabot プル要求を再度開きます。\n* `target-branch`構成ファイルでDependabotの値を変更する場合は、[`target-branch`](#target-branch-)を参照してください。\n* ターゲットブランチに対する最近のプッシュの後で、Dependabot の pull request に競合が発生しました。\n\n ```\n `rebase-strategy`が`disabled`に設定されている場合、Dependabotはプル要求の再評価を停止します。\n ```\n\n> \\[!NOTE]\n> リベースを無効にする**前**に開かれていた pull request は、開かれてから 30 日後までリベースされ続けます。これは、ターゲットブランチと競合するすべての pull request と、バージョン更新プログラムのすべての pull request に影響します。\n\n##\n\n```\n `registries`\n \n \n \n```\n\nプライベートパッケージレジストリへのアクセスを構成して、 Dependabot がより広範な依存関係を更新できるようにします。 [Dependabot のプライベートレジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot) と [Dependabot のプライベートレジストリの構成に関するガイダンス](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/guidance-for-the-configuration-of-private-registries-for-dependabot) を参照してください。\n\n```\n `dependabot.yml` ファイルには、`registries` キーを使用できる場所が 2 つあります。\n```\n\n1. 最上位レベルには、使うプライベートレジストリとそのアクセス情報を定義します。「[Dependabot のプライベートレジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot)」を参照してください。\n2. ```\n `updates` ブロック内で、各パッケージマネージャーが使うプライベートレジストリを指定できます。\n\n Dependabot 既定の動作では、パブリックにアクセス可能なレジストリに格納されている依存関係を更新するためだけにプル要求を発生させます。\n\n Dependabot構成ファイルに最上位の`registries` セクションがあり、1 つ以上のプライベートレジストリへのアクセスを定義している場合は、これらのプライベートレジストリの 1 つ以上を使用するように各`package-ecosystem`を構成できます。\n\n `registries` がパッケージマネージャーに対して定義されている場合:\n ```\n\n* パッケージマネージャーに指定された各プライベートレジストリのバージョンとセキュリティの更新がチェックされます。\n* Dependabot では、最上位レベルの `registries` セクションで定義されているアクセスの詳細が使用されます。\n\nサポートされる値: `REGISTRY_NAME` または `\"*\"`\n\n##\n\n```\n `schedule`\n \n \n\n **必須オプション。** \n `interval` パラメーターを使って、構成する各パッケージマネージャーの新しいバージョンをチェックする頻度を定義します。必要に応じて、毎日および毎週の間隔で、Dependabot が更新プログラムを確認するタイミングをカスタマイズできます。例については、「[AUTOTITLE](/code-security/dependabot/dependabot-version-updates/optimizing-pr-creation-version-updates)」を参照してください。\n```\n\n| パラメーター | 目的 |\n| ----------------------- | -- |\n| [`interval`](#interval) | |\n\n```\n **必須。** \n Dependabotの頻度を定義します。 |\n```\n\n\\| [`day`](#day) |\n**週単位**の間隔で実行する日を指定します。 |\n\\| [`time`](#time) | 実行する時刻を指定します。 |\n\\| |\n\\| [`cronjob`](#cronjob) | 間隔の種類が `cron`の cron 式を定義します。 |\n\\| |\n\\| [`timezone`](#timezone) |\n`time` の値のタイムゾーンを指定します。 |\n\n### `interval`\n\nSupported values: `daily`、 `weekly`、 `monthly`、 `quarterly`、 `semiannually`、`yearly`、または `cron`\n\n各パッケージマネージャーでスケジュール間隔を定義する**必要があります**。\n\n* `daily`を使用して、月曜日から金曜日までのすべての平日に実行します。\n* 週 1 回 (既定では月曜日) 実行するには、`weekly` を使います。\n* 毎月 1 日に実行するには、`monthly` を使います。\n* 各四半期 (1 月、4 月、7 月、10 月) の初日に実行するには、`quarterly` を使います。\n* 6 か月ごと (1 月と 7 月) の初日に実行するには、`semiannually` を使います。\n* 1 月 1 日に実行するには、`yearly` を使います。\n* cron 式ベースのスケジュールオプションには `cron` を使います。\n [\n `cronjob`\n ](#cronjob)を参照してください。\n\n> \\[!NOTE]\n> サポートされている値 `quarterly`、 `semiannually`、および `yearly` は、バージョン 3.19 の GitHub Enterprise Server でのみ使用できます。\n\n既定では、 Dependabot は、構成ファイル内のすべての更新プログラムを適用する時間をランダムに割り当てます。すべての間隔に特定のランタイムを設定するには、`time` および `timezone` パラメーターを使用できます。\n\n```\n `cron`間隔を使用する場合は、`cronjob`式を使用して更新時刻を定義できます。\n```\n\n### `day`\n\nSupported values: `monday`、 `tuesday`、 `wednesday`、 `thursday`、 `friday`、`saturday`、または `sunday`\n\n必要に応じて、特定の曜日にパッケージマネージャーの更新プログラムを**毎週**実行します。\n\n### `time`\n\n形式: `hh:mm`\n\n必要に応じて、パッケージマネージャーのすべての更新プログラムを特定の時間に実行します。既定では、時刻は UTC として解釈されます。\n\n### `cronjob`\n\nサポートされる値: cron 構文または自然な表現での有効な cron 式。\n\nクーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\n例: `0 9 * * *`、`every day at 5pm`\n\n```\n `0 9 * * *` は \"毎日午前 9 時\" に相当します。 \n `every day at 5pm` は `0 17 * * *` と等価です。\n```\n\n> \\[!NOTE]\n>\n> * タイムゾーンは、`timezone`ではなく、[](#timezone)パラメーターで指定する必要があります。\n> *\n\n```\n `cronjob` 間隔を使うには、`cron` 型のスケジュールが必要です。\n```\n\n```yaml copy\n\n# Basic `dependabot.yml` file for cronjob\n\nversion: 2\nupdates:\n # Enable version updates for npm\n - package-ecosystem: \"npm\"\n # Look for `package.json` and `lock` files in the `root` directory\n directory: \"/\"\n # Check the npm registry for updates based on `cronjob` value\n schedule:\n interval: \"cron\"\n cronjob: \"0 9 * * *\"\n```\n\n### `timezone`\n\n```\n `time` 値のタイムゾーンを指定します。既定のタイムゾーンは `UTC` です。\n```\n\nタイムゾーン識別子は、[iana](https://www.iana.org/time-zones) によって管理されているデータベース内のタイムゾーンと同じにする必要があります。「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」(tz データベースのタイムゾーン一覧) を参照してください。\n\n##\n\n```\n `target-branch`\n \n \n```\n\nバージョン更新プログラムをチェックし、バージョン更新プログラムの pull request をターゲットにするように特定のブランチを定義します。例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* Dependabot では、リポジトリの既定のブランチが使用されます。 [「既定のブランチについて」を](/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#about-the-default-branch)参照してください。\n\n ```\n `target-branch` が定義されている場合：\n ```\n\n* バージョン更新プログラムがチェックされるのは、ターゲットブランチ上のマニフェストファイルのみです。\n\n* バージョン更新プログラムのすべての pull request は、指定したブランチを対象として開かれます。\n\n* この `package-ecosystem` に対して定義されたオプションはセキュリティ更新プログラムには適用されなくなります。セキュリティ更新プログラムには、常にリポジトリの既定のブランチが使われるためです。\n\n##\n\n```\n `exclude-paths`\n \n \n```\n\nマニフェストおよび依存関係をスキャンする際に Dependabot が無視するディレクトリおよびファイルのパスを指定するために使用します。このオプションは、テスト資産、ベンダーコード、特定のファイルなど、特定の場所にある依存関係の更新を防ぐ場合に役立ちます。\n\n```\n Dependabot 既定の動作:\n```\n\n* このオプションで除外されない限り、指定された `directory` 内のすべてのディレクトリとファイルは更新スキャンに含まれます。\n\n ```\n `exclude-paths` が定義されている場合：\n ```\n\n* 指定されたパスに一致するすべてのファイルとディレクトリは、指定された `package-ecosystem` エントリの更新スキャン中に無視されます。\n\n| パラメーター | 目的 |\n| --------------- | --------------------------------- |\n| `exclude-paths` | 無視するファイルまたはディレクトリの glob パターンのリスト。 |\n\n再帰マッチング用の `**` や単一セグメントのワイルドカード用の `*` などの glob パターンがサポートされています。パターンは、更新構成で指定された `directory` に対する相対パスになります。各エコシステムは独自の `exclude-paths` 設定を持つことができます。\n\n### Example\n\n```yaml copy\nversion: 2\nupdates:\n - package-ecosystem: \"npm\"\n directory: \"/\"\n schedule:\n interval: \"daily\"\n exclude-paths:\n - \"src/test/assets\"\n - \"vendor/**\"\n - \"src/*.js\"\n - \"src/test/helper.js\"\n\n# Sample patterns that can be used-\n\n# Pattern: docs/*.json\n# Matches: docs/foo.json, docs/bar.json\n\n# Pattern: *.lock\n# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)\n\n# Pattern: test/**\n# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt\n\n# Pattern: config/settings.yml\n# Matches: config/settings.yml\n\n# Pattern: **/*.md\n# Matches: README.md, docs/guide.md, any/depth/file.md\n\n# Pattern: src/*\n# Matches: src/main.rb, src/app.js\n# Does NOT match: src/utils/helper.rb\n\n# Pattern: hidden/.*\n# Matches: hidden/.env, hidden/.secret\n```\n\nこの例では、 Dependabot は、 `src/test/assets` ディレクトリ、 `vendor/`のすべてのファイル、 `src/`のすぐ下にあるすべての JavaScript ファイル、および更新プログラムのスキャン時に `src/test/helper.js` 特定のファイルを無視します。\n\n##\n\n```\n `vendor`\n \n \n \n```\n\nサポートしているもの: `bundler` と `gomod` のみ。\n\nベンダーの依存関係と、マニフェストファイルによって定義された依存関係を維持するように Dependabot に指示します。コードをリポジトリ内に格納すると、依存関係は \"ベンダリングされている\" または \"キャッシュされている\" と記述されます。[`bundle cache` ドキュメント](https://bundler.io/man/bundle-cache.1.html)と [`go mod vendor` ドキュメント](https://golang.org/ref/mod#go-mod-vendor)を参照してください。\n\n例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#updating-vendored-dependencies)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* マニフェストに記録された依存関係のみを保持し、Bundler 用として識別されたファイルをロックします。\n\n* マニフェストとロックファイルに記録されているバージョン番号を更新する、セキュリティおよびバージョン更新プログラムの pull request を生成します。\n\n* Go モジュールの場合、ベンダリングされた依存関係はすべて、`vendor` が有効になっているかのように自動的に特定され、保持されます。\n\n ```\n `vendor` が有効な場合:\n ```\n\n* Dependabot では、リポジトリの `_vendor/cache_` ディレクトリに格納されている Bundler の依存関係も保持されます。\n\n* Pull request には、リポジトリに格納されている依存関係の更新が含まれる場合があります。\n\nサポートされる値: `true` または `false`\n\n##\n\n```\n `versioning-strategy`\n \n \n \n```\n\nサポート対象: `bundler`、 `cargo`、 `composer`、 `mix`、 `npm`、 `pip`、 `pub`、および `uv`\n\nマニフェストファイル Dependabot 編集する方法を定義します。例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/dependabot/dependabot-version-updates/controlling-dependencies-updated#defining-a-versioning-strategy)」を参照してください。\n\n```\n Dependabot 既定の動作:\n```\n\n* アプリとライブラリの依存関係を区別するようにしてください。\n* アプリの場合は、新しいバージョンに合わせて最小バージョン要件を常に引き上げてください。\n `increase`方法。\n* ライブラリの場合は、可能であれば、新旧両方のバージョンを含むように、許可するバージョン要件を広げます。\n `widen`方法。\n\n ```\n `versioning-strategy`が定義されている場合、Dependabotは指定された戦略を使用します。\n ```\n\n| 価値 | 行動 |\n| ----------------------- | ------------------------------------------------------------------------------------------------------ |\n| `auto` | 既定の動作。 |\n| `increase` | 新しいバージョンに一致するように、常に最低限必要なバージョン要件を増やします。範囲が既に存在する場合は、通常、下限を増やすだけです。 |\n| `increase-if-necessary` | バージョン要件で新しいリリースが既に許可されている場合は、変更せずそのままにします (その場合でも Dependabot は解決済みのバージョンを更新します)。そうでない場合は、要件をさらに広くします。 |\n| `lockfile-only` | ロックファイルを更新する pull request のみを作成します。パッケージマニフェストの変更が必要になる新しいバージョンは無視します。 |\n| `widen` | 可能であれば、許容されるバージョン要件を緩和して、新旧両方のバージョンを含めます。通常、これは許容されるバージョンの最大要件を増やすだけです。 |\n\nたとえば、現在のバージョンが `1.0.0` であり、現在の制約が `^1.0.0`、複数の戦略によって次の更新が行われます。\n\n新しいバージョン `1.2.0`\n\n* `increase`: 新しい制約`^1.2.0`\n* `increase-if-necessary`: 新しい制約`^1.0.0`\n* `widen`: 新しい制約`^1.0.0`\n\n新しいバージョン `2.0.0`\n\n* `increase`: 新しい制約`^2.0.0`\n* `increase-if-necessary`: 新しい制約`^2.0.0`\n* `widen`: 新しい制約`>=1.0.0 <3.0.0`\n\n> \\[!NOTE]\n> 使用するパッケージマネージャーが `versioning-strategy` パラメーターの構成をまだサポートしていない場合、または必要な値をサポートしていない場合、戦略コードはオープンソースされるため、特定のエコシステムで新しい戦略をサポートする場合は、常にでプル要求を送信できます。\n\n### バージョン管理タグ\n\n\n\n* アルファ、ベータ、安定バージョンなど、ソフトウェアリリースライフサイクルのステージを表します。\n* 発行者は、パッケージをいっそう効率的に配布できます。\n* バージョンの安定性を示し、機能と安定性に関してユーザーが予期する必要があることを伝えます。\n\nDependabot は、異なるエコシステムで、プレリリース、安定バージョン、カスタムのタグのさまざまなバージョン管理タグを認識します。\n\n```\n `dependabot.yml` ファイルでは使用できるバージョン管理タグは制御されませんが、サポートされているバージョン管理タグのうち更新を無視するものを、[`ignore`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#ignore--) などの構成オプションで定義できます。\n```\n\n#### サポートされているバージョン管理タグ\n\n\\| **パッケージマネージャー** |\n**YAML の値** |\n**サポートされるタグ** |\n**使用例** |\n\\|---------------------|----------------|--------------------|--------------|\n\\| Maven | `maven` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`spring-security-web@5.6.0-SNAPSHOT`、`spring-core@5.2.0.RELEASE` |\n\\| npm | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@beta`、`react@latest`、`express@next` |\n\\| pnpm | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@1.2.0-alpha`、`react@alpha`、`vue@next` |\n\\| yarn | `npm` |\n`alpha`、`beta`、`canary`、`dev`、`experimental`、`latest`、`legacy`、`next`、`nightly`、`rc`、`release`、`stable` |\n`lodash@1.2.0-alpha`、`axios@latest`、`moment@nightly` |\n\n#### バージョン管理タグ用語集\n\n***\n\n```\n `alpha`:** 初期バージョン。不安定であり、不完全な機能がある可能性があります。\n```\n\n***\n\n```\n `beta`:** アルファより安定していますが、バグが残っている可能性があります。\n```\n\n***\n\n```\n `canary`:** テストのために定期的に更新されるプレリリースバージョン。\n```\n\n***\n\n```\n `dev`:** 開発バージョンを表します。\n```\n\n***\n\n```\n `experimental`:** 試験的な機能を備えたバージョン。\n```\n\n***\n\n```\n `latest`:** 最新の安定版リリース。\n```\n\n***\n\n```\n `legacy`:** 古い、または非推奨のバージョン。\n```\n\n***\n\n```\n `next`:** 次回のリリースバージョン。\n```\n\n***\n\n```\n `nightly`:** 夜間にビルドされるバージョン。多くの場合、最新の変更が含まれます。\n```\n\n***\n\n```\n `rc`:** 安定リリースに近いリリース候補。\n```\n\n***\n\n```\n `release`:** 公式のリリースバージョン。\n```\n\n***\n\n```\n `stable`:** 最も信頼性が高く、運用に対応したバージョン。\n```\n\n\n\n## 最上位レベルの `registries` キー\n\nプライベートパッケージレジストリ Dependabot アクセスするために使用できる認証の詳細 (GitLab または Bitbucket によってホストされているレジストリを含む) を指定します。\n\n```\n `registries` キーの値は連想配列で、その各要素は、特定のレジストリを指定するキーと、そのレジストリへのアクセスに必要な設定を指定する連想配列の値により構成されます。次の `dependabot.yml` ファイルでは、ファイルの `dockerhub` セクションで `registries` として指定されたレジストリが構成された後、ファイルの `updates` セクションでそれが参照されています。\n```\n\n```yaml copy\n# Minimal settings to update dependencies stored in one private registry\n\nversion: 2\nregistries:\n dockerhub: # Define access for a private registry\n type: docker-registry\n url: registry.hub.docker.com\n username: octocat\n password: ${{secrets.DOCKERHUB_PASSWORD}}\nupdates:\n - package-ecosystem: \"docker\"\n directory: \"/docker-registry/dockerhub\"\n registries:\n - dockerhub # Allow version updates for dependencies in this registry\n schedule:\n interval: \"monthly\"\n```\n\n以下のオプションを使用して、アクセス設定を指定します。レジストリの設定には、`type` と `url`、そして通常は `username` と `password` の組み合わせまたは `token` を含める必要があります。\n\n| パラメーター | パーパス |\n| :-------------- | :---------------------------------------------------------------------------------------------------------------------- |\n| `REGISTRY_NAME` | **必須:** レジストリの識別子を定義します。 |\n| `type` | **必須:** レジストリの種類を特定します。 |\n| 認証の詳細 | **必須:** 認証の詳細を指定するためにサポートされるパラメーターは、レジストリの種類によって異なります。 |\n| `url` | **必須:** このレジストリ内の依存関係にアクセスするために使う URL。プロトコルはオプションです。指定しないと、`https://` が想定されます。 Dependabot が必要に応じて末尾のスラッシュを追加または無視します。 |\n| `replaces-base` | ブール値が `true`、Dependabot により、そのエコシステムのベース URL ではなく、指定した `url` を使って依存関係が解決されます。 |\n\n使用可能なオプションの詳細と、プライベートレジストリを構成するときの推奨事項とアドバイスについては、「[Dependabot のプライベートレジストリの構成に関するガイダンス](/ja/code-security/dependabot/working-with-dependabot/guidance-for-the-configuration-of-private-registries-for-dependabot)」を参照してください。\n\n### 　　　 `type`と認証の詳細\n\nプライベートレジストリにアクセスするための認証の詳細を指定するために使われるパラメーターは、レジストリ `type` によって異なります。\n\n| レジストリ `type` | 必須の認証パラメーター |\n| --------------------- | ----------- |\n| `cargo-registry` | `token` |\n| `composer-repository` | |\n\n```\n `username` および `password`
または OIDC ( `tenant-id` と `client-id` |\n```\n\n\\| `docker-registry` |\n`username` および `password`
または OIDC ( `tenant-id` と `client-id` |\n\\| `git` |\n`username` および `password`
または OIDC ( `tenant-id` と `client-id` |\n\\| `hex-organization` |\n`organization` および `key` |\n\\| `hex-repository` |\n`repo` と `auth-key` (必要に応じて、対応する `public-key-fingerprint` と共に使用します) |\n\\| `maven-repository` |\n`username` および `password`
または OIDC ( `tenant-id` と `client-id` |\n\\| `npm-registry` |\n`username` および `password`
または `token`
または OIDC ( `tenant-id` と `client-id` |\n\\| `nuget-feed` |\n`username` および `password`
または `token`
または OIDC ( `tenant-id` と `client-id` |\n\\| `pub-registry` | `token` |\n\\| `python-index` |\n`username` および `password`
または `token`
または OIDC ( `tenant-id` と `client-id` |\n\\| `rubygems-server` |\n`username` および `password`
または `token`
または OIDC ( `tenant-id` と `client-id` |\n\\| `terraform-registry` | `token` |\n\n認証に使われるすべての機密データを安全に格納し、その安全な場所から参照する必要があります。「[Dependabot のプライベートレジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot)」を参照してください。\n\n> \\[!TIP]\n> アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。\n\n```\n Dependabotの OIDC サポートの詳細については、[AUTOTITLE](/actions/concepts/security/openid-connect#oidc-support-for-dependabot) と [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configuring-access-to-private-registries-for-dependabot#using-oidc-for-authentication) を参照してください。\n```\n\n###\n\n```\n `url` および `replaces-base`\n\n `url` パラメーターを使って、レジストリにアクセスする場所を定義します。省略可能な `replaces-base` パラメーターが有効 (`true`)、 Dependabot は、その特定のエコシステムのベース URL ではなく、 `url` の値を使用して依存関係を解決します。\n```"}