{"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 アイコンでマークされているすべてのオプションは、Dependabot が使用されていない限り、`target-branch` によるセキュリティ更新プログラムの pull request 作成方法も変更します。\n\n### 必要なキー\n\n| Key | ロケーション | 目的 |\n| ------------------------------------------------------------ | ---------------------------- | ---------------------------------------------------------------------------------------------------------------- |\n| `version` | 最上位レベル | |\n| Dependabot 使用する構成構文。 Always (常に)`2`。 | | |\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`dependabot.yml` ファイルの実際の例については、[Dependabot独自の構成ファイル](https://github.com/dependabot/dependabot-core/blob/main/.github/dependabot.yml)を参照してください。\n\n## `allow`\n\nパッケージ エコシステムに対してどの依存関係を保持するかを正確に定義するために使います。 多くの場合、[`ignore`](#ignore--) オプションと共に使われます。 例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-dependencies-to-be-updated)」を参照してください。\n\nDependabot 既定の動作:\n\n* マニフェストで明示的に定義されているすべての依存関係は、バージョンの更新によって最新の状態に保たれます。\n* 脆弱な依存関係を持つロック ファイルで定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。\n\n`allow`を指定Dependabot場合は、次のプロセスを使用します。\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### `dependency-name` (`allow`)\n\nほとんどのパッケージ マネージャーでは、ロックまたはマニフェスト ファイルで指定された依存関係名と一致する値を定義する必要があります。 一部のシステムには、より複雑な要件があります。\n\n| パッケージ マネージャー | 必要な形式 | Example |\n| --------------------------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------ |\n| Gradle と Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| イメージ タグ用の Docker | リポジトリのフルネーム | |\n| `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` のイメージ タグには、`base/foo/bar/ruby` を使います。 | | |\n\n### `dependency-type` (`allow`)\n\n| 依存関係の種類 | パッケージマネージャーによるサポート | 更新の許可 |\n| -------------------------------------------------------------------------- | --------------------------------------- | ------------------ |\n| `direct` | All | 明示的に定義されたすべての依存関係。 |\n| `indirect` | | |\n| `bundler`、 `pip`、 `composer`、 `cargo`、 `gomod`、 `uv` | 直接依存関係 (サブ依存関係または推移的依存関係とも呼ばれます) の依存関係。 | |\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### `update-types` (`allow`)\n\n`update-types` は *バージョン* 更新プログラムにのみ影響し、 \\_セキュリティ更新プログラム\\_には影響しません。\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`update-types`ルールから`allow`を省略すると、そのルールのすべての更新の種類が許可されます。\n\n`update-types`を`dependency-name`または`dependency-type`と組み合わせて、許可される更新プログラムをさらに絞り込むことができます。 これらのオプションを組み合わせる方法の例については、 [AUTOTITLE を](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#allowing-specific-semantic-versioning-levels-for-updates)参照してください。\n\n## `assignees`\n\nパッケージエコシステムで作成されるすべてのプルリクエストに、個別の担当者を指定します。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* Pull request は担当者なしで作成されます。\n\n`assignees` が定義されている場合：\n\n* バージョン更新のすべてのプル要求は、選択した担当者で作成されます。\n* 既定以外のブランチへの更新を定義 `target-branch` 場合を除き、セキュリティ更新プログラムに対するすべてのプル要求は、選択した担当者によって作成されます。\n\n担当者はリポジトリへの書き込みアクセス権限を持っている必要があります。 Organization が所有するリポジトリの場合、読み取りアクセス権を持つ organization メンバーも有効な担当者です。\n\n## `commit-message`\n\nコミット メッセージの形式を定義します。 Pull request のタイトルはコミット メッセージに基づいて記述されるため、この設定は pull request のタイトルにも影響します。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* コミット メッセージは、リポジトリで検出されたものと同様のパターンに従います。\n\n`commit-message` が定義されている場合：\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## `cooldown`\n\n依存関係の更新の**クールダウン期間**を定義し、構成可能な日数だけ更新を延期することができます。\n`cooldown` オプションは、\\_バージョン\\_更新プログラムでのみ使用でき、\\_セキュリティ\\_更新プログラムでは使用できません。\n\nこの機能を使用すると、ユーザーは新しいバージョンの更新プログラム Dependabot 生成する頻度をカスタマイズでき、更新頻度をより詳細に制御できます。 例については、「[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#setting-up-a-cooldown-period-for-dependency-updates)」を参照してください。\n\nDependabot 既定の動作:\n\n* `schedule.interval`で定義されたスケジュールに従って更新プログラムを確認します。\n* \\*\\*\\*\\*が構成されていない場合でも、バージョン更新プログラムに `cooldown`を適用します。 新しいバージョンは、リリースから 3 日後までバージョン更新プログラムとは見なされません。 **この既定のクールダウンは、セキュリティ更新プログラムには適用されません。**\n\n`cooldown` オプションを構成して、これらの既定のクールダウン期間をカスタマイズし、適用する依存関係を制御できます。\n\\*\\*\n`cooldown`\n\\*\\* が定義されている場合：\n\n1. Dependabot は、定義された `schedule.interval` 設定に従って更新プログラムをチェックします。\n2. Dependabot は、クールダウン設定をチェックします。\n3. 依存関係の新しいリリースがクールダウン期間内にある場合、 Dependabot はその依存関係のバージョンの更新をスキップします。\n4. クールダウン期間のない依存関係、またはクールダウン期間を過ぎた依存関係は、構成した `versioning-strategy` 設定に従って最新バージョンに更新されます。\n5. 依存関係のクールダウンが終了した後、 Dependabot は、 `dependabot.yml`で定義されている標準的な更新戦略に従って依存関係の更新を再開します。\n\n### **`cooldown` の構成**\n\n以下のオプションを使ってクールダウンの期間を指定できます。\n\n| パラメーター | Description |\n| --------------------------------------------------------------------- | --------------------------------------------------------------------------------- |\n| `default-days` | 特定のルールがない**依存関係の既定のクールダウン期間** (省略可能)。 指定しない場合、 Dependabot は 3 日間の既定のクールダウンを適用します。 |\n| `semver-major-days` | |\n| **メジャー バージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージ マネージャーにのみ適用されます)。 | |\n| `semver-minor-days` | |\n| **マイナー バージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージ マネージャーにのみ適用されます)。 | |\n| `semver-patch-days` | |\n| **パッチ バージョン更新**のクールダウン期間 (省略可能。SemVer をサポートするパッケージ マネージャーにのみ適用されます)。 | |\n| `include` | |\n| **クールダウンを適用**する依存関係のリスト (最大 **150 項目**)。 ワイルドカードのサポート (`*`). | |\n| `exclude` | |\n| **クールダウンから除外する**依存関係のリスト (最大 **150 項目**)。 ワイルドカードのサポート (`*`). | |\n\n次の表は、 `cooldown`をサポートするパッケージ マネージャーを示しています。\n`default-days` オプションは、一覧表示されているすべてのパッケージ マネージャーでサポートされますが、`semver-major-days`、`semver-minor-days`、および`semver-patch-days`は示されている場合にのみサポートされます。\n\n| パッケージ マネージャー | サポートされている既定の日数 | SemVer-bump の日数がサポートされています |\n| ---------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |\n| | | |\n| Bazel | | |\n| | | |\n| Bundler | | |\n| Bun | | |\n| 貨物 | | |\n| Composer | | |\n| | | |\n| Conda | | |\n| | | |\n| | | |\n| Deno | | |\n| | | |\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| | | |\n| Nix フレーク | | |\n| | | |\n| NPM と Yarn | | |\n| NuGet | | |\n| | | |\n| OpenTofu | | |\n| | | |\n| pip | | |\n| | | |\n| pre-commit | | |\n| | | |\n| Pub | | |\n| | | |\n| Rust ツールチェーン | | |\n| | | |\n| | | |\n| sbt | | |\n| | | |\n| Swift | | |\n| Terraform | | |\n| UV | | |\n| | | |\n| vcpkg | | |\n| | | |\n\n> \\[!NOTE]\n>\n> *\n\n`semver-major-days`、`semver-minor-days`、または `semver-patch-days` が定義されていない場合、クールダウンベースの更新では `default-days` 設定が優先されます。\n\n> \\*\n> `exclude` リストは常に `include` リストよりも優先されます。 依存関係が両方のリストに指定されている場合、その依存関係は**クールダウンから除外**され、すぐに更新されます。\n\n## `directories` または `directory`\n\n**必須オプション**。 各パッケージ マネージャー (*package.json* や *Gemfile* など) のパッケージ マニフェストの場所を定義するために使用します。 この情報がないと Dependabot バージョン更新のプル要求を作成できません。 例については、「[マニフェスト ファイルの複数の場所を定義する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-multiple-locations-for-manifest-files)」を参照してください。\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> `directories` キーはグロビングとワイルドカード文字 `*` をサポートしています。 これらの機能は `directory` キーではサポートされていません。\n\n## `enable-beta-ecosystems`\n\n現在使用できません。\n\n## `groups`\n\nパッケージ マネージャーによって管理される 1 つ以上の依存関係のセットを作成し、更新プログラムを少数の対象を絞った pull request にグループ化するようにルールを定義します。 例については、「[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates)」を参照してください。\n\nDependabot 既定の動作:\n\n* バージョン更新とセキュリティ更新の場合、新しいバージョンに更新する必要がある依存関係ごとに 1 つの pull request を開きます。\n\n`groups` を使ってルールを定義する場合:\n\n* 規則と一致する依存関係のすべての更新は、1 つの pull request に結合されます。\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### `dependency-type` (`groups`)\n\nサポート： `bundler`、`composer`、`mix`、`maven`、`npm`、および`pip`。\n\n既定では、グループにはすべての種類の依存関係が含まれます。\n\n* \"Development dependency group\" に依存関係のみを含めるには、`development` を使います。\n* \"Production dependency group\" に依存関係のみを含めるには、`production` を使います。\n\n### `group-by` (`groups`)\n\n`groups..group-by`を使用して、monorepo 内Dependabot複数のディレクトリ間で更新をグループ化する方法を指定します。\n\n* **型:** 文字列\n* **受け入れ可能な値:**`dependency-name`\n* **適用対象:** 複数のディレクトリが指定された構成\n\n`dependency-name`に設定すると、Dependabotは、ディレクトリごとに個別のプル要求ではなく、指定されたすべてのディレクトリにわたって依存関係の更新ごとに 1 つのプル要求を作成します。\n\n**ディレクトリ間グループ化の制限事項**\n\n`group-by: dependency-name`を使用する場合:\n\n* すべてのディレクトリで同じパッケージ エコシステムを使用する必要があります (たとえば、すべての `npm` またはすべての `bundler`)\n* バージョン更新のみに適用されます\n* ディレクトリに依存関係に互換性のないバージョン制約がある場合、 Dependabot は個別のプル要求を作成します\n\n`group-by`の使用例については、[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates#grouping-updates-across-directories-in-a-monorepo) を参照してください。\n\n### `patterns` と `exclude-patterns` (`groups`)\n\nどちらのオプションも、依存関係名との一致を定義する際にワイルド カードとして `*` を使用できます。 依存関係がパターンと除外パターンの両方と一致する場合は、グループから除外されます。\n\n### `update-types` (`groups`)\n\n既定では、グループにはすべてのセマンティック バージョン (SemVer) 更新プログラムが含まれます。 SemVer は、`x.y.z` の形式でソフトウェア パッケージのバージョンを定義するための標準として認められています。 Dependabot は、この形式のバージョンが常に `major.minor.patch` であると想定します。\n\n* パッチ リリースを含めるには、`patch` を使います。\n* マイナー リリースを含めるには、`minor` を使います。\n* メジャー リリースを含めるには、`major` を使います。\n\n例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#specifying-the-semantic-versioning-level-to-ignore)」を参照してください。\n\n## `ignore`\n\nパッケージ エコシステムに対してどの依存関係を保持するかを正確に定義するには、[`allow`](#allow--) オプションと共に使います。\nDependabot は、許可されているすべての依存関係をチェックし、無視された依存関係またはバージョンを除外します。 許可条件と無視条件の両方で一致する依存関係は、無視されます。 例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-dependencies)」を参照してください。\n\nDependabot 既定の動作:\n\n* マニフェストで明示的に定義されているすべての依存関係は、バージョンの更新によって最新の状態に保たれます。\n* 脆弱な依存関係を持つロック ファイルで定義されているすべての依存関係は、セキュリティ更新プログラムによって更新されます。\n\n`ignore`を使用する場合、Dependabotは次のプロセスを使用します。\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### `dependency-name` (`ignore`)\n\nほとんどのパッケージ マネージャーでは、ロックまたはマニフェスト ファイルで指定された依存関係名と一致する値を定義する必要があります。 一部のシステムには、より複雑な要件があります。\n\n| パッケージ マネージャー | 必要な形式 | Example |\n| --------------------------------------------------------------------------------------------------------------------------- | -------------------- | ------------------------ |\n| Gradle と Maven | `groupId:artifactId` | `org.kohsuke:github-api` |\n| イメージ タグ用の Docker | リポジトリのフルネーム | |\n| `.dkr.ecr.us-west-2.amazonaws.com/base/foo/bar/ruby:3.1.0-focal-jemalloc` のイメージ タグには、`base/foo/bar/ruby` を使います。 | | |\n\n### `versions` (`ignore`)\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#ignoring-specific-versions-or-ranges-of-versions)」を参照してください。\n\n### `update-types` (`ignore`)\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## `insecure-external-code-execution`\n\nサポート: `bundler`、`mix`、および `pip`。\n\nDependabotが更新中にマニフェストで外部コードを実行できるようにします。 例については、「[外部コードの実行を許可する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#allowing-external-code-execution)」を参照してください。\n\nDependabot 既定の動作:\n\n* 1 つ以上のレジストリ Dependabot アクセス権を付与すると、侵害されたパッケージからコードを保護するために外部コードの実行が自動的に無効になります。\n* コードを実行できないと、バージョン更新プログラムが失敗する場合があります。\n\n`insecure-external-code-execution` を許可する場合:\n\n* Dependabot は、バージョン更新プロセスの一環としてマニフェストでコードを実行します。\n* コードは、その `updates` の設定に関連付けられたレジストリ内のパッケージ マネージャーにのみアクセスできます。 最上位の `registries` 構成で定義されているレジストリへのアクセスは許可されません。\n* そのため、更新プログラムは成功するはずですが、侵害されたパッケージが資格情報を盗んだり、構成済みのレジストリにアクセスしたりする可能性もあります。\n\nサポートされる値: `allow`。\n\n## `labels`\n\nパッケージ マネージャーに対して発行されるすべての pull request に独自のラベルを指定します。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* すべての pull request には `dependencies` ラベルが付いています。\n* 複数のパッケージ マネージャーを定義すると、エコシステムまたは言語の追加ラベルが各 pull request に追加されます。 例: Gradle の更新プログラムの場合は `java`、git サブモジュールの更新プログラムの場合は `submodules` です。\n* セマンティック バージョン (SemVer) ラベルがリポジトリに存在する場合は、バージョン更新の種類 (`major`、 `minor`、または `patch`) を示すために自動的に適用されます。\n* Dependabot は、リポジトリで必要に応じてこれらの既定のラベルを自動的に作成します。\n\n`labels` が定義されている場合：\n\n* 指定したラベルは、既定のラベルの代わりに使われます。\n* SemVer ラベル (リポジトリに存在する場合) は、定義されているカスタム ラベルに加えて適用されます。\n* これらのラベルのいずれかがリポジトリで定義されていない場合は無視されます。\n* `labels: [ ]` を使用すると、デフォルトのラベルを含むすべてのラベルを無効化できます。\n\n`target-branch` を使って既定以外のブランチのバージョン アップデートをチェックしないかぎり、このオプションの設定も、このパッケージ マネージャーのマニフェスト ファイルに対するセキュリティ更新プログラムの pull request に影響します。\n\n## `milestone`\n\nパッケージマネージャーにより作成されたすべてのプルリクエストをマイルストーンに関連付けます。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* マイルストーンは使われません。\n\n`milestone` が定義されている場合：\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## `multi-ecosystem-groups`\n\n複数のパッケージ エコシステムにまたがるグループを定義して、サポートされているすべてのパッケージ エコシステムを更新する単一の Dependabot プル要求を取得します。 この方法は、受け取る Dependabot プル要求の数を減らし、依存関係の更新ワークフローを合理化するのに役立ちます。\n\nDependabot 既定の動作:\n\n* 依存関係の更新があるパッケージ エコシステムごとに個別の pull request が作成されます。\n\n`multi-ecosystem-groups` が使用された場合。\n\n* 同じグループ内の複数のパッケージ エコシステムにまたがる更新が、1 つの pull request に結合されます。\n* グループには独自のスケジュールがあり、個々のエコシステム設定を継承するか、オーバーライドすることができます。\n\n### `multi-ecosystem-group`\n\n`multi-ecosystem-group` 構成で `updates` パラメーターを使って、個々のパッケージ エコシステムをマルチエコシステム グループに割り当てます。\n\n> \\[!IMPORTANT]\n> マルチエコシステムの更新には、特定の構成パターンが必要であり、独自のパラメーター マージ動作があります。 詳細なセットアップ手順、構成例、詳細なパラメーター リファレンスについては、「[Dependabot 用にマルチエコシステム更新を構成する](/ja/code-security/how-tos/secure-your-supply-chain/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## `open-pull-requests-limit`\n\n開いているバージョン更新プログラムの pull request の最大数に関する制限はいつでも変更できます。\n\nDependabot 既定の動作:\n\n* バージョン更新プログラムを含む pull request が 5 つ開いている場合、それらの開いている request の一部がマージまたは終了されるまで、それ以上の pull request は生成されません。\n\n> \\[!NOTE]\n> *セキュリティ更新プログラム* のプル要求は、この制限の対象ではなく、それに対してカウントされません。 セキュリティ更新プログラムのオープン プル要求の数に制限はありません。\n\n`open-pull-requests-limit` が定義されている場合：\n\n* Dependabot は、定義された整数値までのプル要求を開きます。 大きな値を設定して、オープン pull request の制限を効果的に削除できます。\n* パッケージ マネージャーのバージョン更新プログラムを一時的に無効にするには、このオプションを 0 に設定します。[Dependabot version updatesの無効化を](/ja/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#disabling-dependabot-version-updates)参照してください。\n\n## `package-ecosystem`\n\n\n\n**必須オプション。** 新しいバージョンを監視するために`package-ecosystem`において、監視したい各パッケージ マネージャーごとに 1 つのDependabot要素を定義します。 リポジトリには、各パッケージマネージャー用の依存関係マニフェストまたはロックファイルも含まれている必要があります。[Example `dependabot.yml` file](/ja/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-version-updates#example-dependabotyml-file)を参照してください。\n\n| パッケージ マネージャー | YAML値 | サポートされているバージョン |\n| -------------- | ---------------- | :---------------: |\n| | | |\n| Bazel | `bazel` | v7、v8、v9 |\n| | | |\n| Bun | `bun` | >=v1.1.39 |\n| Bundler | `bundler` | v2 |\n| 貨物 | `cargo` | v1 |\n| Composer | `composer` | v2 |\n| | | |\n| Conda | `conda` | 適用なし |\n| | | |\n| | | |\n| Deno | `deno` | >=v2 |\n| | | |\n| 開発コンテナー | `devcontainers` | 適用なし |\n| Docker | `docker` | v1 |\n| Docker Compose | `docker-compose` | v2、v3 |\n| .NET SDK | `dotnet-sdk` | >=.NET Core 3.1 |\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、v11 |\n| NuGet | `nuget` | <=6.12.0 |\n| | | |\n| OpenTofu | `opentofu` | 適用なし |\n| | | |\n| pip | `pip` | 26.1.1 |\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| | | |\n| sbt | `sbt` | 適用なし |\n| | | |\n| Swift | `swift` | v5、v6 |\n| Terraform | `terraform` | >= 0.13,<= 1.15.x |\n| uv | `uv` | v0.11 |\n| | | |\n| vcpkg | `vcpkg` | 適用なし |\n| | | |\n| yarn | `npm` | v1、v2、v3、v4 |\n\n## `pull-request-branch-name`\n\nDependabot がプル リクエストのブランチ名を生成する方法を設定します。 区切り記号、プレフィックス、長さ、大文字と小文字、単語の区切り記号をカスタマイズし、カスタム テンプレートを提供できます。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* 次の形式のブランチ名を生成します: `dependabot/PACKAGE-MANAGER/DEPENDENCY`\n\n| パラメーター | タイプ | デフォルト | Description |\n| --------------------------------------- | --------------- | -------------- | --------------------------------------------- |\n| [`separator`](#separator) | String | `\"/\"` | 分岐名のセグメント間で使用される文字。 |\n| [`prefix`](#prefix) | 文字列 (最大 50 文字) | `\"dependabot\"` | ブランチ名の先頭に付加する文字列。 |\n| [`max-length`](#max-length) | 整数 (20 \\~ 244) | `100` | 分岐名の最大文字数。 |\n| [`word-separator`](#word-separator) | String | 設定されていません | プレフィックスより後ろのブランチ名に含まれるアンダースコア (`_`) を置き換える文字。 |\n| [`branch-name-case`](#branch-name-case) | String | 設定されていません | プレフィックスより後ろのブランチ名に大文字小文字変換を適用します。 |\n| [`template`](#template) | 文字列 (最大 200 文字) | 設定されていません | プレースホルダーを使用したカスタム書式テンプレート。 |\n\nすべてのオプションは構成可能です。\n`template`が単純なオプションと共に設定されている場合、処理順序は次のようになります。\n\n1. テンプレートのレンダリング (プレースホルダーの置換)\n2. 区切り記号の置換 (`/` 構成された区切り記号に置き換えられます)\n3. 単語区切り記号の置換（`_` は設定された単語区切り記号に置き換えられます）\n4. プレフィックスの後のコンテンツに適用されるケース変換\n5. 最大長で切り詰める\n\n### `separator`\n\n分岐名セグメント間の `/` の代わりに使用する文字を指定します。\n\nサポートされる値: `\"-\"`、`_`、`/`\n\nたとえば、 `separator: \"-\"`では、 `dependabot/npm_and_yarn/lodash-4.17.21` は `dependabot-npm_and_yarn-lodash-4.17.21`になります。\n\n> \\[!TIP]\n> ハイフン記号は、空の YAML リストの開始として解釈されないようにエスケープする必要があります。\n\n### `prefix`\n\n既定の `dependabot`ではなく、ブランチ名の先頭で使用するカスタム文字列を指定します。\n\n値は最大 50 文字です。\n\nたとえば、 `prefix: \"deps\"`では、 `dependabot/npm_and_yarn/lodash-4.17.21` は `deps/npm_and_yarn/lodash-4.17.21`になります。\n\n### `max-length`\n\n生成されたブランチ名に許可される最大長を設定します。\n\n* 最小値: `20`。\n* 最大値: `244`。\n* 既定値: `100`。\n* ブランチ名がこの制限を超えると、一意性を維持するために、ブランチ名は切り捨てられ、ハッシュ サフィックスが追加されます。\n\nたとえば、 `max-length: 40`では、 `dependabot/npm_and_yarn/some-long-dependency-name-1.0.0` のようなブランチ名は、ハッシュ サフィックスを持つ 40 文字に切り捨てられます。\n\n### `word-separator`\n\nプレフィックスの後にあるすべてのブランチ名コンテンツのアンダースコア (`_`) を置き換える文字を指定します。これには、パッケージ マネージャー名、依存関係名、グループ名、ディレクトリ パスが含まれます。\n\nたとえば、 `word-separator: \"-\"`の場合:\n\n* `npm_and_yarn` → `npm-and-yarn`\n* `front_end_dir` → `front-end-dir`\n\n### `branch-name-case`\n\nプレフィックスより後ろのブランチ名に大文字小文字変換を適用します。\n\nサポートされる値: `\"lowercase\"`、`\"uppercase\"`\n\nたとえば、 `branch-name-case: \"lowercase\"`では、 `dependabot/npm_and_yarn/Lodash-4.17.21` は `dependabot/npm_and_yarn/lodash-4.17.21`になります。\n\n### `template`\n\nプレースホルダーを使用してカスタム ブランチ名の形式を定義します。 このテンプレートを使用すると、生成されたブランチ名の構造を完全に制御できます。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\n使用可能なプレースホルダーは、更新戦略によって異なります。\n\n| プレースホルダー | Solo の更新 | グループ化された更新 | マルチエコシステム グループ | Description |\n| ------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | ------------------------------------------------ |\n| `{prefix}` | | | | 構成されたプレフィックス (既定の `dependabot`)。 |\n| `{package_manager}` | | | | パッケージ エコシステム識別子 (たとえば、 `npm_and_yarn`)。 |\n| `{directory}` | | | | 依存関係ファイル ディレクトリ。 |\n| `{target_branch}` | | | | ターゲット ブランチ (構成されている場合)。 |\n| `{dependency}` | | | | 依存関係の名前。 |\n| `{version}` | | | | 新しいバージョンまたは参照。 |\n| `{group_name}` | | | | 構成されたグループ名。 |\n| `{name}` | | | | 戦略に適した名前: ソロ更新の依存関係とバージョン、グループ化された更新プログラムのグループ名。 |\n\nテンプレートの検証規則:\n\n* すべてのプレースホルダーは、使用中の更新戦略で認識され、許可されている必要があります。\n* 中かっこは正しく対応している必要があります (閉じられていない `{` または `}` がないこと)。\n* 複数エコシステム グループ テンプレートで `{package_manager}` を使用すると、1 つのパッケージ マネージャーが適用されないため、検証エラーが発生します。\n* レンダリングされるブランチ名は、有効な Git 参照名である必要があります。 スペース、 `~`、 `^`、 `:`、 `?`、 `*`、 `[`、 `\\` などの文字は使用できません。また、 `..` や `@{` などのシーケンスは拒否されます。\n* グループ化された複数のエコシステムの更新では、一意性を保証するために、10 文字のダイジェストがブランチ名に自動的に追加されます。 これはユーザー制御ではありません。\n\n## `rebase-strategy`\n\nDependabotによって発生したプルリクエストの自動リベースを無効にします。\n\nDependabot 既定の動作としては、バージョンまたはセキュリティ更新のプルリクエストに変更がDependabot 検出されたときに、オープンなプルリクエストをリベースします。\nDependabot 次の場合に変更をチェックします。\n\n* バージョン更新プログラムをチェックするスケジュールが実行される。\n* 閉じた Dependabot プル要求を再度開きます。\n* `target-branch`構成ファイルでDependabotの値を変更する場合は、[`target-branch`](#target-branch-)を参照してください。\n* ターゲット ブランチに対する最近のプッシュの後で、Dependabot の pull request に競合が発生しました。\n\n`rebase-strategy`が`disabled`に設定されている場合、Dependabotはプル要求の再評価を停止します。\n\n> \\[!NOTE]\n> リベースを無効にする**前**に開かれていた pull request は、開かれてから 30 日後までリベースされ続けます。 これは、ターゲット ブランチと競合するすべての pull request と、バージョン更新プログラムのすべての pull request に影響します。\n\n## `registries`\n\nプライベート パッケージ レジストリへのアクセスを構成して、 Dependabot がより広範な依存関係を更新できるようにします。 [Dependabot のプライベート レジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries) と [Dependabot のプライベート レジストリの構成に関するガイダンス](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries) を参照してください。\n\n`dependabot.yml` ファイルには、`registries` キーを使用できる場所が 2 つあります。\n\n1. 最上位レベルには、使うプライベート レジストリとそのアクセス情報を定義します。「[Dependabot のプライベート レジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries)」を参照してください。\n2. `updates` ブロック内で、各パッケージ マネージャーが使うプライベート レジストリを指定できます。\n\nDependabot 既定の動作では、パブリックにアクセス可能なレジストリに格納されている依存関係を更新するためだけにプル要求を発生させます。\n\nDependabot構成ファイルに最上位の`registries` セクションがあり、1 つ以上のプライベート レジストリへのアクセスを定義している場合は、これらのプライベート レジストリの 1 つ以上を使用するように各`package-ecosystem`を構成できます。\n\n`registries` がパッケージ マネージャーに対して定義されている場合:\n\n* パッケージ マネージャーに指定された各プライベート レジストリのバージョンとセキュリティの更新がチェックされます。\n* Dependabot では、最上位レベルの `registries` セクションで定義されているアクセスの詳細が使用されます。\n\nサポートされる値: `REGISTRY_NAME` または `\"*\"`\n\n## `schedule`\n\n**必須オプション。**\n`interval` パラメーターを使って、構成する各パッケージ マネージャーの新しいバージョンをチェックする頻度を定義します。 必要に応じて、毎日および毎週の間隔で、Dependabot が更新プログラムを確認するタイミングをカスタマイズできます。 例については、「[Dependabot バージョン更新プログラムに合わせて pull request の作成を最適化する](/ja/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates)」を参照してください。\n\n| パラメーター | 目的 |\n| ----------------------- | ---------------------------- |\n| [`interval`](#interval) | |\n| **必須。** | |\n| Dependabotの頻度を定義します。 | |\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`cron`間隔を使用する場合は、`cronjob`式を使用して更新時刻を定義できます。\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`0 9 * * *` は \"毎日午前 9 時\" に相当します。\n`every day at 5pm` は `0 17 * * *` と等価です。\n\n> \\[!NOTE]\n>\n> * タイムゾーンは、`timezone`ではなく、[](#timezone)パラメーターで指定する必要があります。\n> *\n\n`cronjob` 間隔を使うには、`cron` 型のスケジュールが必要です。\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`time` 値のタイム ゾーンを指定します。 既定のタイム ゾーンは `UTC` です。\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## `target-branch`\n\nバージョン更新プログラムをチェックし、バージョン更新プログラムの pull request をターゲットにするように特定のブランチを定義します。 例については、「[実際のプロセスに合わせて Dependabot pull request をカスタマイズする](/ja/code-security/tutorials/secure-your-dependencies/customizing-dependabot-prs)」を参照してください。\n\nDependabot 既定の動作:\n\n* Dependabot では、リポジトリの既定のブランチが使用されます。 [「既定のブランチについて」を](/ja/pull-requests/reference/branches#about-the-default-branch)参照してください。\n\n`target-branch` が定義されている場合：\n\n* バージョン更新プログラムがチェックされるのは、ターゲット ブランチ上のマニフェスト ファイルのみです。\n* バージョン更新プログラムのすべての pull request は、指定したブランチを対象として開かれます。\n* この `package-ecosystem` に対して定義されたオプションはセキュリティ更新プログラムには適用されなくなります。セキュリティ更新プログラムには、常にリポジトリの既定のブランチが使われるためです。\n\n## `exclude-paths`\n\nマニフェストおよび依存関係をスキャンする際に Dependabot が無視するディレクトリおよびファイルのパスを指定するために使用します。 このオプションは、テスト資産、ベンダー コード、特定のファイルなど、特定の場所にある依存関係の更新を防ぐ場合に役立ちます。\n\nDependabot 既定の動作:\n\n* このオプションで除外されない限り、指定された `directory` 内のすべてのディレクトリとファイルは更新スキャンに含まれます。\n\n`exclude-paths` が定義されている場合：\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## `vendor`\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/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#updating-vendored-dependencies)」を参照してください。\n\nDependabot 既定の動作:\n\n* マニフェストに記録された依存関係のみを保持し、Bundler 用として識別されたファイルをロックします。\n* マニフェストとロック ファイルに記録されているバージョン番号を更新する、セキュリティおよびバージョン更新プログラムの pull request を生成します。\n* Go モジュールの場合、ベンダリングされた依存関係はすべて、`vendor` が有効になっているかのように自動的に特定され、保持されます。\n\n`vendor` が有効な場合:\n\n* Dependabot では、リポジトリの `_vendor/cache_` ディレクトリに格納されている Bundler の依存関係も保持されます。\n* Pull request には、リポジトリに格納されている依存関係の更新が含まれる場合があります。\n\nサポートされる値: `true` または `false`\n\n## `versioning-strategy`\n\nサポート対象: `bundler`、 `cargo`、 `composer`、 `helm`、 `mix`、 `npm`、 `pip`、 `pub`、および `uv`\n\nマニフェスト ファイル Dependabot 編集する方法を定義します。 例については、「[Dependabot が更新する依存関係を制御する](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/controlling-dependencies-updated#defining-a-versioning-strategy)」を参照してください。\n\nDependabot 既定の動作:\n\n* アプリとライブラリの依存関係を区別するようにしてください。\n* アプリの場合は、新しいバージョンに合わせて最小バージョン要件を常に引き上げてください。\n `increase`方法。\n* ライブラリの場合は、可能であれば、新旧両方のバージョンを含むように、許可するバージョン要件を広げます。\n `widen`方法。\n\n`versioning-strategy`が定義されている場合、Dependabotは指定された戦略を使用します。\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`dependabot.yml` ファイルでは使用できるバージョン管理タグは制御されませんが、サポートされているバージョン管理タグのうち更新を無視するものを、[`ignore`](/ja/code-security/reference/supply-chain-security/dependabot-options-reference#ignore--) などの構成オプションで定義できます。\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\\| |\n\\| sbt | `sbt` | `alpha, a, beta, b, milestone, m, rc, cr, sp, ga, final, release, snapshot` |\n`akka-actor@2.7.0-RC1`、`play-json@3.0.0-M1` |\n\\| |\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\\| Bundler | `bundler` | プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`、 `pre`) |\n`rails@1.0.0.alpha`、`rack@1.0.0.beta1`、`rspec@1.0.0.rc2` |\n\\| 貨物 | `cargo` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`、 `dev`) |\n`serde@1.0.0-alpha`、`tokio@0.2.0-preview.3`、`clap@4.0.0-rc.1`、`rand@1.0.0-dev` |\n\\| pip | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| pipenv | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| pip-compile | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| poetry | `pip` |\n`a`、`b`、`rc`、`dev`、`post` |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| Gradle | `gradle` |\n`alpha`、`a`、`beta`、`b`、`milestone`、`m`、`rc`、`cr`、`snapshot`、`ga`、`final`、`release`、`sp` (大文字と小文字は区別されません) |\n`spring-boot-starter@3.0.0-RC1`、`kotlin-stdlib@2.0.0-beta`、`guava@33.0.0-SNAPSHOT`、`junit@5.10.0-M2`、`ktor@2.3.0-rc.1` |\n\\| Elm | `elm` | なし- 厳密な `MAJOR.MINOR.PATCH` のみ (プレリリース バージョンなし) |\n`elm/core@1.0.0`、`elm/html@2.3.1`、`elm/json@10.0.0` |\n\\| Docker | `docker` |\n`alpha`、 `beta`、 `rc`、 `dev`、 `preview`、 `pre`、 `nightly`、 `snapshot`、 `canary`、 `unstable` (ヒューリスティック検出) |\n`nginx@1.25.0-rc1`、`node@20.0.0-alpha.1`、`redis@7.0.0-nightly`、`alpine@3.18.0-dev`、`ubuntu@22.04-preview` |\n\\| Gitサブモジュール | `gitsubmodule` | なし - SHA または git タグをコミットするためのピン留め (バージョン管理スキームなし) |\n`my-lib@abc1234`、`shared-utils@v1.2.0` |\n\\| Go モジュール | `gomod` |\n`alpha`、 `beta`、 `rc` ( `-`後の SemVer プレリリース) |\n`github.com/go-chi/chi@v5.0.0-rc1`、`google.golang.org/grpc@v1.60.0-beta.1`、`github.com/octo-org/octo-module@v0.17.0-alpha.1` |\n\\| |\n\\| Bazel | `bazel` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`rules_go@0.46.0-rc1`、`rules_rust@0.40.0-beta`、`bazel_skylib@1.5.0-alpha` |\n\\| |\n\\| Bun | `bun` |\n`alpha`、 `beta`、 `rc`、 `canary` ( `-`後の SemVer プレリリース) |\n`bun@1.0.0-beta.1`、`elysia@1.0.0-rc.3`、`hono@4.0.0-canary.1` |\n\\| Composer | `composer` |\n`dev`、`alpha`、`a`、`beta`、`b`、`RC` (大文字と小文字は区別されません。 |\n`laravel/framework@11.0.0-alpha1`、`symfony/console@7.0.0-beta2`、`monolog/monolog@3.0.0-RC1` |\n\\| |\n\\| Conda | `conda` |\n`dev`、 `alpha`、 `a`、 `beta`、 `b`、 `rc`、 `c`、 `post` |\n`numpy@2.0.0a1`、`pandas@2.1.0b2`、`scipy@1.12.0rc1`、`scikit-learn@1.4.0.dev0` |\n\\| |\n\\| |\n\\| Deno | `deno` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`oak@13.0.0-alpha`、`fresh@2.0.0-rc.1`、`std@0.220.0-beta.2` |\n\\| |\n\\| 開発コンテナー | `devcontainers` | SemVer 2.0.0 (プレリリースは実際には使用されません) |\n`ghcr.io/devcontainers/features/node@1.6.1`、`ghcr.io/devcontainers/features/python@1.6` |\n\\| .NET SDK | `dotnet-sdk` |\n`preview.N`、`rc.N`、`alpha.N` |\n`dotnet-sdk@9.0.100-preview.7.24407.12`、`dotnet-sdk@9.0.100-rc.2.24474.11` |\n\\| GitHub Actions | `github-actions` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`my-org/my-action@v1.0.0-beta.1`、`my-org/deploy@v2.0.0-rc1`、`my-org/lint@v3.0.0-alpha` |\n\\| |\n\\| Helm チャート | `helm` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`ingress-nginx@4.11.0-beta.0`、`cert-manager@1.15.0-alpha.1`、`prometheus@25.0.0-rc1` |\n\\| |\n\\| Hex | `mix` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`、 `dev`) |\n`phoenix/phoenix@1.7.0-rc.0`、`elixir-ecto/ecto@3.11.0-beta.1`、`elixir-plug/plug@1.15.0-alpha.1` |\n\\| |\n\\| ジュリア | `julia` | SemVer プレリリース識別子 (一般的に `rc`、 `DEV`、 `beta`) |\n`HTTP@1.10.0-rc1`、`Plots@2.0.0-DEV`、`DataFrames@1.6.0-beta.1` |\n\\| |\n\\| |\n\\| Nix | `nix` | なし - フレーク入力コミットを追跡します (バージョン管理スキームなし) |\n`nixpkgs@a1b2c3d`、`devenv@e4f5a6b`、`flake-utils@c7d8e9f` |\n\\| |\n\\| NuGet | `nuget` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`、 `preview`) |\n`Newtonsoft.Json@13.0.0-rc1`、`Microsoft.Extensions.Hosting@8.0.0-preview.7`、`Serilog@3.0.0-beta.1` |\n\\| |\n\\| OpenTofu | `opentofu` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`opentofu/aws@5.0.0-alpha`、`opentofu/google@5.0.0-rc1`、`opentofu/azurerm@4.0.0-beta1` |\n\\| |\n\\| |\n\\| pre-commit | `pre-commit` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`pre-commit/mirrors-mypy@1.10.0a1`、`psf/black@24.1.0rc1`、`astral-sh/ruff-pre-commit@0.4.0-beta.1` |\n\\| |\n\\| Pub | `pub` | SemVer プレリリース識別子 (一般的に `dev`、 `beta`、 `rc`) |\n`flutter/dio@5.0.0-dev.1`、`dart-lang/http@1.2.0-beta.1`、`invertase/melos@4.0.0-rc.1` |\n\\| |\n\\| Rust ツールチェーン | `rust-toolchain` | チャネルベース: `stable`、 `beta`、 `nightly` (SemVer プレリリースではない) |\n`rust@1.78.0`、`rust@beta`、`rust@nightly`、`rust@nightly-2024-01-15` |\n\\| |\n\\| Swift | `swift` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`vapor/vapor@5.0.0-beta.1`、`apple/swift-nio@3.0.0-rc1`、`pointfreeco/swift-composable-architecture@2.0.0-alpha.1` |\n\\| Terraform | `terraform` | SemVer プレリリース識別子 (一般的に `alpha`、 `beta`、 `rc`) |\n`hashicorp/aws@5.0.0-rc1`、`hashicorp/google@4.0.0-alpha`、`hashicorp/azurerm@3.0.0-beta1` |\n\\| uv | `uv` |\n`a`、 `b`、 `rc`、 `dev`、 `post` (PEP 440) |\n`requests@1.0.0a1`、`numpy@2.0.0b3`、`django@4.0rc1`、`black@1.0.0.dev5`、`pandas@2.0.5.post1` |\n\\| |\n\\| vcpkg | `vcpkg` | SemVer プレリリース識別子 (一般的に `beta`、 `rc`) |\n`zlib@1.3.1-beta1`、`openssl@3.2.0-rc.1`、`fmt@10.2.0-beta` |\n\\| |\n\n#### エコシステム固有のバージョン管理の詳細\n\n次の詳細では、 Dependabot が特定のエコシステムのバージョン管理を解釈する方法について説明します。\n\n* **Bundler:** プレリリース タグの固定セットは使用しません。 レターを含むバージョン セグメントはプレリリースとして扱われます (たとえば、 `.alpha`、 `.beta1`、 `.rc2`)。 ハイフンは内部的に `.pre.` に正規化されます (たとえば、 `1.0.0-beta` が `1.0.0.pre.beta`になります)。\n\n* **貨物：** SemVer 2.0.0 の規則に従います。\n `-`後の何でもプレリリース識別子 (ドット区切り、`[0-9A-Za-z-]`)。 ビルド メタデータ (`+...`) は許可されますが、優先順位は無視されます。\n\n* **Gradle:** 表に示されている修飾子に加えて、 `pr`/`pre`/`preview`→`rc`、 `eap`/`ea`→`alpha`などのエイリアスが認識されます。 その他のプレリリース修飾子には、 `dev`、 `experimental`、および `unstable`が含まれます。 修飾子は優先順位順に並べられます: `alpha`/`a` < `beta`/`b` < `milestone`/`m` < `rc`/`cr` < `snapshot` < (empty/`ga`/`final`/`release`) < `sp`。 この一覧にない自由形式の識別子は、安定として扱われます。\n\n* **pip/pipenv/pip-compile/詩 (PEP 440):** 次の表に、正規のプレリリースとリリース後のサフィックスの一覧を示します。 エイリアスも認識され、正規化されます (`alpha`→`a`、 `beta`→`b`、 `c`/`pre`/`preview`→`rc`、 `rev`/`r`→`post`)。 エポック バージョン (`N!...`) とローカル バージョン (`+local`) がサポートされています。ローカル セグメントは、パブリック バージョンが同じ場合にのみ、タイを解除するために使用されます。\n\n* **ニレ：** 厳密な SemVer を適用します (`MAJOR.MINOR.PATCH` 整数のみ)。 Elm パッケージ レジストリでは、プレリリース バージョンの発行は許可されません。\n Dependabot では、バージョンが数値で比較されます。\n\n* **Go モジュール:** 必須の `v` プレフィックスを使用して SemVer に従います。 擬似バージョン (`v0.0.0-YYYYMMDDHHMMSS-commithash`) は未リリースのコミットを表し、常にプレリリースとして扱われます。\n `+incompatible` サフィックスは、メジャー バージョン 2 以降のモジュールに`go.mod` ファイルを付けずにマークし、バージョンの順序には影響しません。\n\n* \\*\\*git submodule:\\*\\*Dependabot は、構成されたブランチの最新のコミットを追跡します。 バージョンの比較はありません。更新プログラムは常に固定された SHA を前方に移動します。 サブモジュールがタグを追跡する場合、 Dependabot はタグのコミットに従います。\n\n* **バゼル:** SemVer プレリリース規則に従います。 Bazel Central Registry (BCR) `.bcr.N` サフィックスは比較前に削除され、プレリリース検出には影響しません。\n\n* **Deno:** SemVer プレリリース規則に従います。 ビルド メタデータ (`+...`) はサポートされていますが、バージョンの優先順位では無視されます。\n\n* **Bun:** npm 形式の SemVer のプレリリース規則に従います。 ビルド メタデータ (`+...`) はサポートされていますが、バージョンの優先順位では無視されます。\n\n* \\*\\*GitHub Actions:\\*\\*Dependabot は、git タグからアクションのバージョンを解決します。 SemVer プレリリース識別子 ( `-`後のすべてのタグ) はプレリリースとして扱われます。 さらに、GitHub Release API を介してプレリリースとしてマークされたリリースは、タグ形式に関係なく認識されます。\n\n* **ジュリア：** SemVer プレリリース規則に従います。 プレリリース識別子では大文字と小文字が区別されます (たとえば、 `DEV` と `dev` は区別されます)。\n\n* **Hex:** SemVer のプレリリース規則に従います。\n `-`後の識別子はプレリリースとして扱われます。\n\n* \\*\\*Nix:\\*\\*Dependabot は、git サブモジュールと同様に、フレーク入力コミットを追跡します。 内部的には、バージョンは擬似バージョン (`0.0.0-0.N`) として表されます。 従来のバージョンの比較はありません。更新プログラムは最新のアップストリーム コミットに進みます。\n\n* **Nuget：** SemVer 2.0.0 プレリリース規則に従います。 ビルド メタデータ (`+...`) はサポートされていますが、バージョンの優先順位では無視されます。\n\n* **OpenTofu:** SemVer プレリリース規則 (Terraform と同じ) に従います。 ビルド メタデータ ( `+backport` サフィックスを含む) は比較前に削除され、プレリリース検出には影響しません。\n\n* **Rust ツールチェーン:** SemVer プレリリース識別子ではなく、チャネル ベースのバージョン管理 (`stable`、 `beta`、 `nightly`) を使用します。\n Dependabot は、ピン留めされたチャンネルまたは日付が記録された nightly (`nightly-2024-01-15` など) を、利用可能な最新の状態に更新します。\n\n* **Terraform:** SemVer プレリリース規則に従います。 比較の前に、 `v` プレフィックスが削除されます。 ビルド メタデータ (`+...`) は、バージョンの優先順位では無視されます。\n\n* **Composer:** PHP Composer の安定性規則に従います (大文字と小文字は区別されません)。 制約内の安定性フラグ (`@dev`、 `@beta`) は、比較前に削除されます。\n `v` プレフィックスは透過的に処理されます。\n\n* **Conda:** conda バージョンの仕様に従います (PEP 440 に似ています)。 エポック バージョン (`N!...`) とローカル バージョン (`+local`) がサポートされています。 リリース後 (`post`) サフィックスが認識されます。\n\n* **.NET SDK:** プレリリース識別子は、`preview.N`、`rc.N`、`alpha.N` パターンに従います。 プレリリース更新プログラムを使用するには、`allowPrerelease: true`で`global.json`が必要です。\n\n* **Helm チャート:** SemVer プレリリース規則に従います。 グラフのバージョン プレフィックス ( `chart-v` など) とビルド ダイジェスト (`+sha256:...`) は、比較前に削除されます。\n\n* **事前コミット:** git タグからフック バージョンを解決します。 プレリリース検出では、Gem::Version ヒューリスティックと GitHub Release API `prerelease` フラグの両方が使用されます。 SHA で固定されたフックもサポートされています。\n\n* **パブ：** SemVer プレリリース規則に従います。 ビルド メタデータ (`+...`) はサポートされていますが、バージョンの優先順位では無視されます。\n\n* **Swift:** SemVer プレリリース規則に従います。 プレリリース のフィルター処理は現在適用されていません。すべてのバージョンが比較で均等に扱われます。\n\n* **vcpkg:** ドット区切り数値、SemVer (ビルド メタデータなし)、日付ベースの複数のバージョン形式をサポートします。 ポート バージョン サフィックス (`#N`) はパッケージのリビジョンを示し、プレリリース検出には影響しません。\n\n#### バージョン管理タグ用語集\n\n* **`alpha`:** 初期バージョン。不安定であり、不完全な機能がある可能性があります。\n* **`beta`:** アルファより安定していますが、バグが残っている可能性があります。\n* **`canary`:** テストのために定期的に更新されるプレリリース バージョン。\n* **`dev`:** 開発バージョンを表します。\n* **`experimental`:** 試験的な機能を備えたバージョン。\n* **`latest`:** 最新の安定版リリース。\n* **`legacy`:** 古い、または非推奨のバージョン。\n* **`next`:** 次回のリリース バージョン。\n* **`nightly`:** 夜間にビルドされるバージョン。多くの場合、最新の変更が含まれます。\n* **`rc`:** 安定リリースに近いリリース候補。\n* **`release`:** 公式のリリース バージョン。\n* **`stable`:** 最も信頼性が高く、運用に対応したバージョン。\n\n\n\n## 最上位レベルの `registries` キー\n\nプライベート パッケージ レジストリ Dependabot アクセスするために使用できる認証の詳細 (GitLab または Bitbucket によってホストされているレジストリを含む) を指定します。\n\n`registries` キーの値は連想配列で、その各要素は、特定のレジストリを指定するキーと、そのレジストリへのアクセスに必要な設定を指定する連想配列の値により構成されます。 次の `dependabot.yml` ファイルでは、ファイルの `dockerhub` セクションで `registries` として指定されたレジストリが構成された後、ファイルの `updates` セクションでそれが参照されています。\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| **必須:** レジストリの識別子を定義します。 | |\n| `type` | |\n| **必須:** レジストリの種類を特定します。 | |\n| 認証の詳細 | |\n| **必須:** 認証の詳細を指定するためにサポートされるパラメーターは、レジストリの種類によって異なります。 | |\n| `url` | |\n| **必須:** このレジストリ内の依存関係にアクセスするために使う URL。 プロトコルはオプションです。 指定しないと、`https://` が想定されます。 | |\n| Dependabot は、必要に応じて末尾のスラッシュを追加または無視します。 | |\n| `replaces-base` | ブール値が `true`場合、 Dependabot は、そのエコシステムのベース URL ではなく、指定された `url` を使用して依存関係を解決します。 |\n| | |\n| `scope` | |\n| `npm-registry`型の場合のみ。 このレジストリに関連付ける npm スコープ ( `@my-company`など)。 | |\n| `scope`が指定されると、Dependabotはレジストリ資格情報から`.npmrc`構成を生成し、コミットされた`.npmrc` ファイルまたはロックファイルの推論をオーバーライドします。 | |\n| | |\n\n使用可能なオプションの詳細と、プライベート レジストリを構成するときの推奨事項とアドバイスについては、「[Dependabot のプライベート レジストリの構成に関するガイダンス](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-private-registries)」を参照してください。\n\n### `type`と認証の詳細\n\nプライベート レジストリにアクセスするための認証の詳細を指定するために使われるパラメーターは、レジストリ `type` によって異なります。\n\n| レジストリ `type` | 必須の認証パラメーター |\n| -------------------------------------------------------------------------------- | ----------- |\n| `cargo-registry` | `token` |\n| `composer-repository` | |\n| `username` および `password`
または OIDC ( `tenant-id` と `client-id` | |\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/configure-access-to-private-registries)」を参照してください。\n\n> \\[!TIP]\n> アカウントが GitHub アカウントの場合は、パスワードの代わりに GitHub personal access token を使用できます。\n\nDependabotの OIDC サポートの詳細については、[OpenID Connect](/ja/actions/concepts/security/openid-connect#oidc-support-for-dependabot) と [Dependabot のプライベート レジストリへのアクセスの構成](/ja/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#using-oidc-for-authentication) を参照してください。\n\n### `url` および `replaces-base`\n\n`url` パラメーターを使って、レジストリにアクセスする場所を定義します。 省略可能な `replaces-base` パラメーターが有効 (`true`)、 Dependabot は、その特定のエコシステムのベース URL ではなく、 `url` の値を使用して依存関係を解決します。\n\n### `scope`\n\n`scope` パラメーターは、`npm-registry`型レジストリで使用できます。 レジストリに関連付ける npm スコープを指定します。 値は、`@`など、`@my-company`で始まる必要があります。 複数のスコープを同じレジストリ URL に関連付けるには、スコープごとに個別のレジストリ エントリを作成します。\n\n`scope`が指定されると、Dependabotはレジストリ資格情報から`.npmrc`構成を生成します。 この生成された構成は、コミットされた `.npmrc` ファイルまたはロックファイル ベースの推論よりも優先されます。\n\n#### npm レジストリ解決の優先順位\n\nnpm 依存関係に使用するレジストリを決定する場合、 Dependabot は次の優先順位に従います。\n\n1. **資格情報ベースの生成 (`scope`または`replaces-base`):**`scope`または`replaces-base`が`npm-registry`の任意の`dependabot.yml`資格情報で構成されている場合、Dependabotはそれらの資格情報から`.npmrc`を生成します。 これは常に優先され、コミットされた `.npmrc` ファイルはすべてオーバーライドされます。\n2. **リポジトリ内のコミット済み `.npmrc` :**`scope` が設定されていない場合、 Dependabot はリポジトリにコミットされた `.npmrc` ファイルを使用します。\n3. **Lockfile 推論 (遷移):**`scope`がなく、コミットされた`.npmrc`がない場合、Dependabotはロックファイルからレジストリ構成を推論しようとします。\n4. **エラー生成:** 上記のいずれの方法も成功しなかった場合、 Dependabot は明示的な構成を追加するためのガイダンスを含むエラーを報告します。"}