Nix flakes を使っているのに、Dependabot では flake.lock の更新を自動化できず、結局 nix flake update を手で回していた――そんな運用は今回かなり改善します。GitHub は 2026年4月7日、Dependabot の version updates で Nix ecosystem をサポートしました。dependabot.yml に package-ecosystem: "nix" を追加すれば、Dependabot が flake.lock の inputs を監視し、上流に新しいコミットがあれば pull request を作成します。ただし対象は version updates のみで、security updates ではありません。さらに flake.nix 内で直接固定した ref の書き換えや、Nix ecosystem の private repositories には現時点で制約があります。(The GitHub Blog)
この記事では、Dependabot の Nix サポートで何が変わったのか、どこまで自動化できるのか、dependabot.yml はどう書けばよいのか、導入前に知っておくべき制約と運用のコツまで、実務ベースで整理します。
DependabotのNixサポートで何が変わったか
まず押さえるべきなのは、今回の対応が「Nix 全般」ではなく Nix flakes の lock 更新 を GitHub 標準フローに載せる機能だという点です。GitHub 公式では、nix を dependabot.yml の package ecosystem として指定すると、flake.lock の inputs を監視し、古くなった flake input ごとに個別の PR を開くと説明しています。対応する入力元は GitHub、GitLab、SourceHut、plain git です。(The GitHub Blog)
公式情報を実務向けに整理すると、今回の仕様は次のとおりです。(The GitHub Blog)
| 項目 | 今回の仕様 | 実務での意味 |
|---|---|---|
| 有効化方法 | .github/dependabot.yml に package-ecosystem: "nix" を追加 | GitHub標準の更新PRに寄せられる |
| 監視対象 | flake.lock の inputs | lock file ベースで更新差分を追える |
| PRの単位 | 古い flake input ごとに個別PR | 原因を切り分けてレビューしやすい |
| 対応する入力元 | GitHub / GitLab / SourceHut / plain git | 一般的な flake 参照をかなりカバーできる |
| 対象外 | security updates | 脆弱性修正PRの代替にはならない |
| 主な制約 | flake.nix の固定ref更新、private repositories は未対応 | 既存運用の置き換え範囲を見極める必要がある |
要するに、「Nix の日常的な lock 更新は自動化しやすくなったが、脆弱性対応や private input まで一気に置き換わるわけではない」と捉えるのが正確です。(The GitHub Blog)
なぜ flake.lock 対応が重要なのか
Flakes では flake.nix が inputs と outputs を宣言し、Nix はコマンド実行時に flake.lock を生成して依存関係を pin します。Nix 公式ドキュメントでも、nix flake update は flake.lock を再作成し、nixpkgs などの unlocked input を現在の状態へ更新するコマンドとして説明されています。つまり、今回の Dependabot 対応は、これまで手動で行いがちだった lock 更新を、GitHub の定期 PR として継続運用しやすくした変更だと考えると分かりやすいです。(Nix.dev)
Nix の lock 更新と Dependabot の挙動を並べると、違いはかなりはっきりします。(Nix.dev)
| 観点 | 手動の nix flake update | DependabotのNixサポート |
|---|---|---|
| 更新の起点 | 人が任意のタイミングで実行 | スケジュールに沿って自動実行 |
| 更新の出方 | まとめて更新しやすい | 古い input ごとに PR 化 |
| レビューしやすさ | 差分が大きくなりやすい | 変更原因を追いやすい |
| 向いている場面 | 一括で最新化したい時 | 日常的な追従運用 |
特に大きいのは、Dependabot が古い flake input ごとに個別の PR を作る点です。たとえば nixpkgs と別の flake input が同時に古くなっていても、1本の大きな更新ではなく分けて見やすくなるため、レビューの負荷と原因特定のしやすさが大きく変わります。(The GitHub Blog)
まずはこの dependabot.yml で始めればよい
Dependabot の設定ファイルは、既定ブランチの .github/dependabot.yml もしくは .github/dependabot.yaml に置きます。Nix flake がリポジトリルートにあり、flake.lock をリポジトリで管理しているなら、最初は次の構成で十分です。PR が動き始めるのは設定直後ではなく、次回のスケジュール実行時です。(GitHub Docs)
version: 2
updates:
- package-ecosystem: "nix"
directory: "/"
schedule:
interval: "weekly"
day: "tuesday"
time: "02:00"
timezone: "Asia/Tokyo"
open-pull-requests-limit: 3この設定で見ておくべきポイントは4つです。directory は必須で、flake.nix と flake.lock がある場所を指します。schedule は time と timezone まで指定でき、時刻を決めない場合は Dependabot 側でランダムに割り当てられます。version updates の open pull requests の既定上限は 5 件なので、最初は 1〜3 件に抑えると運用が荒れにくくなります。また、PR の担当者は既定では自動で付かないため、放置防止が必要なら assignees を追加します。(GitHub Docs)
独自ラベル運用をしているなら labels も使えます。ただし、GitHub Docs では labels は既定ラベルを上書きすると説明されています。深く考えずに独自ラベルだけを設定すると、あとで振り分けしにくくなるので注意してください。(GitHub Docs)
複数の flake を持つリポジトリの設定例
モノレポや infra ディレクトリ分離の構成では、最初は update ブロックを分けるほうが分かりやすいです。GitHub Docs でも、同じエコシステムで複数ブロックを使う場合は directory / directories の値が重複しないよう求めています。(GitHub Docs)
version: 2
updates:
- package-ecosystem: "nix"
directory: "/"
schedule:
interval: "weekly"
- package-ecosystem: "nix"
directory: "/infra"
schedule:
interval: "weekly"導入前に必ず知っておきたい制約
security updates の代わりにはならない
今回の Nix 対応は version updates 向けで、security updates は対象外です。つまり「脆弱性が見つかったら Dependabot が自動で Nix 向け修正 PR を出してくれる」と期待するとズレます。今回追加されたのは、あくまで flake.lock ベースの更新自動化です。(The GitHub Blog)
flake.nix の直接 pin は書き換わらない
GitHub Docs では、flake.nix に書いた pinned ref の直接更新、たとえば github:cachix/devenv/v0.5 のような参照をより新しい tag に書き換えることは未対応だと明記されています。Dependabot を活かすなら、flake.nix で入力を宣言し、実際の pin は flake.lock に任せる、という標準的な flake フローに寄せるのが実務的です。(GitHub Docs)
private repositories 主体の構成は要注意
GitHub Docs では、Nix ecosystem は現時点で private repositories をサポートしていません。社内の private flake を多用している構成では、今回の追加だけで完全自動化できるとは限りません。公開の上流 input は Dependabot、private な input は別手段、という切り分けで考えるほうが安全です。(GitHub Docs)
flake.lock を使っていない構成には効かない
GitHub が対応したのは Nix flakes であり、監視対象も flake.lock です。つまり、flake.lock を前提にしない Nix 運用には、そのままでは適用できません。今回のアップデートは「Nix を全部自動化する機能」ではなく、「flake の lock 更新を Dependabot に載せる機能」と理解したほうがズレません。(The GitHub Blog)
失敗しやすいポイントと対策
公式仕様と実務運用を踏まえると、特に詰まりやすいのは次の点です。.github/dependabot.yml の配置、directory の指定、flake.lock の管理、PR 上限、ラベル上書き、そして nix flake check による検証は、最初に整えておく価値があります。(GitHub Docs)
| 失敗ポイント | 起きること | 対策 |
|---|---|---|
dependabot.yml の置き場所を間違える | 設定が読まれず PR が来ない | 既定ブランチの .github/dependabot.yml に置く |
directory が flake の場所と合っていない | 監視対象を見つけられない | flake.nix と flake.lock があるディレクトリを指定する |
flake.lock をコミットしていない | Dependabot が監視すべき lock 情報を持てない | lock file を生成し、リポジトリに含める |
| 初回から PR が多すぎる | レビューが滞り、結局放置される | weekly と open-pull-requests-limit: 1〜3 で始める |
labels を軽く追加する | 既定ラベルが消えて振り分けが崩れる | labels は上書きだと理解して設計する |
| CI なしで自動マージする | devShell や build が壊れてから気づく | PR ごとに nix flake check と主要ジョブを回す |
レビューで見るべきは「差分の行数」より「どの input が動いたか」
Nix の flake.lock は依存関係のグラフを保持します。そのため、1つの input 更新でも、関連する lock 情報が複数ノードぶん変わることがあります。レビューで本当に見るべきなのは diff の行数より、「どの直接 input が動いたか」「それが build、devShell、デプロイにどれだけ効くか」です。(Nix.dev)
Nix の更新は、npm のように major / minor / patch だけで機械的に危険度を分けやすい世界ではありません。Dependabot が追うのは flake.lock の inputs に対する上流コミットなので、実務では nixpkgs のような基盤 input を重めに、補助的な input を軽めに見る、といったレビュー基準のほうが現実的です。(The GitHub Blog)
最低限のチェックとして、PR ごとに次のコマンドを CI で実行できる状態にしておくと安心です。Nix 公式では nix flake check を、flake が正しく評価できるか、そして checks 出力がビルドできるかを検証するコマンドとして説明しています。(Nix.dev)
nix flake checkレビュー時は、少なくとも次の観点で見ておくと事故を減らせます。
- 更新対象が
nixpkgsのような基盤 input か、それとも補助的な input か flake.lockの差分が、意図した input の更新に収まっているかnix flake checkと主要な build / test / deploy ジョブが通るか- 開発者向け devShell や本番環境の構築手順に影響が出ていないか
まとめ：最初にやるべきこと
今回の Dependabot Nix サポートは、Nix flakes の flake.lock 更新を GitHub 標準の更新 PR に載せられるようにした、実務上かなり大きな変更です。すぐ始めるなら、まず .github/dependabot.yml に package-ecosystem: "nix" を1件追加し、週1回・PR上限1〜3件で動かしてください。そのうえで CI に nix flake check を入れ、private repositories や flake.nix 直書き pin が多いところだけは別運用にする。この順番で進めると、Nix 更新を「思い出した時に手で回す作業」から「見える化された継続運用」に変えやすくなります。(The GitHub Blog)
コメント