Dependabotでpre-commit rev更新を自動化する実践ガイド

Dependabot pre-commit、.pre-commit-config.yaml 自動更新、pre-commit rev 更新あたりで、設定は触ったけど運用が続かないと感じている人に向けて書きました。2026年3月10日のアップデートで、Dependabotが.pre-commit-config.yamlのrev更新に正式対応したので、運用の主役は「手動autoupdate」から「PRレビュー中心」に変わりました。この記事を読むと、rev固定を維持したまま更新を自動化し、CIで壊れる前に止める設計まで今日から実装できます。僕は福祉事業のIT全般を担当しつつAI×SaaS開発も並行していて、複数リポジトリで回している実運用の型をそのまま共有します。

2026年3月アップデートの要点｜Dependabot pre-commitで何が変わったか

まず前提です。2026年3月10日に、GitHub公式の変更としてDependabotがpre-commitエコシステムへネイティブ対応しました。つまり.pre-commit-config.yamlのrevをDependabotが解析し、更新PRを自動で作ってくれるようになったということです。詳細はGitHub Changelogの発表で確認できます。

ここが大きいのは、作業の重心が変わるからです。今までは「定期的にpre-commit autoupdateを叩く人」が必要でしたが、これからは「Dependabot PRをレビューする仕組み」を作ったチームが強くなります。更新の実行を自動化して、破壊的変更を人間が最終判断する流れに寄せられるので、忙しい週でも更新が止まりにくいです。

• 以前の中心作業 — 手元でautoupdate実行、差分コミット、CI確認
• 今の中心作業 — Dependabot PR確認、ラベル運用、マージ判断
• 運用のコツ — PR数を制御しないとレビュー待ちが詰まります

イメージとしては、福祉現場の紙台帳をスプレッドシート化するのに近いです。入力を自動化しても、最終確認のルールがないと現場は楽になりません。「自動化したのに忙しい」状態は、更新数の設計不足で起きやすいので、次セクションでrev管理の土台を先に固めます。

.pre-commit-config.yaml更新ルール完全整理｜tag・SHA・# frozenの挙動差

pre-commit公式は、revにブランチ名やHEADを使わず、不変参照（tagやSHA）を使う方針です。理由は再現性です。同じコミットを誰が実行しても同じhookが走る状態を保つためです。ここにDependabotの仕様が重なります。GitHub公式ドキュメントでは、SHA固定でも# frozen:コメントを使うかどうかで追跡方法が変わります。

結論は「本番運用はSHA + # frozen」が安定です。更新のタイミングはDependabotに任せつつ、何を追っているかを人間が読める形で残せます。手動更新したいときはpre-commitのautoupdate --freezeで同じ思想を維持できます。

pre-commit autoupdate --freeze
pre-commit run --all-files

つまり、tag派かSHA派かの議論より、「チーム全員が同じルールを読めるか」の方が重要です。非エンジニアがレビューに入る現場でも、# frozenコメントがあるだけで意図が伝わりやすくなります。

壊さないdependabot.yml設計｜groups・ignore・cooldown・PR上限

Dependabot pre-commit運用で最初に詰まるのは、更新そのものではなくPR量です。Dependabotオプション仕様では、version updatesの同時オープン上限は既定5件、security updatesは内部上限10件です。ここを知らないまま導入すると「通知だけ増える」状態になります。まずPRの流量を先に設計してから自動化をONにするのが実務ではいちばん安定します。

version: 2
updates:
  - package-ecosystem: "pre-commit"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Tokyo"
    open-pull-requests-limit: 3
    cooldown:
      default-days: 3
    groups:
      precommit-nonmajor:
        patterns:
          - "*"
        update-types:
          - "minor"
          - "patch"
    ignore:
      - dependency-name: "*"
        update-types:
          - "version-update:semver-major"

僕の現場では、monorepoならgroup-by: dependency-nameも併用してCI実行回数を減らしています。イメージとしては、宅配を毎日バラバラで受け取るより、曜日を決めてまとめて受け取る運用です。受け取りコストを下げると、レビュー品質を落とさず続けられます。

rev固定でも事故らないCI｜pre-commit run --all-filesとキャッシュ戦略

更新PRが来ても、CIが弱いと「マージ後に壊れる」が発生します。ここはシンプルで、必須チェックにpre-commit run --all-filesを置くのが軸です。全ファイル検査なので、差分外に潜む整形ズレやlint不整合まで拾えます。Dependabotの自動更新と相性がいいのは、局所テストより全体チェックです。

name: pre-commit
on:
  pull_request:
  push:
    branches: [main]

jobs:
  precommit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.cache/pre-commit
          key: pre-commit-${{ runner.os }}-${{ hashFiles('.pre-commit-config.yaml') }}
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install pre-commit
      - run: pre-commit run --all-files

このキャッシュキーにhashFiles('.pre-commit-config.yaml')を入れるのが地味に重要です。設定が変わったのに古いキャッシュを使ってしまう事故を避けられます。なお、Dependabotはadditional_dependencies更新にも対応していますが、private registry非対応の領域があります。private依存があるチームは、該当hookだけ更新経路を分離しておくと安全です。

失敗パターンと回避策｜PRノイズ、HEAD追従、major更新の扱い

ここは実務で差がつくところです。僕が見てきた失敗はだいたい3つに集約されます。1つ目はPRノイズ過多、2つ目はSHA固定のつもりで実はHEAD追従、3つ目はmajor更新を通常PRと同列で処理してしまう運用です。つまり「設定はあるけど運用ルールがない」状態です。

• PRノイズ過多 — groups未設定でレビュー負荷が飽和します
• 意図しない追従 — SHA固定でも# frozenなしだと挙動がブレます
• major混在 — 破壊的変更を通常枠で流して障害化します

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

運用テンプレート集｜小規模リポジトリ用とモノレポ用の設定例

最後に、今日から使えるテンプレートを2パターンに絞って置いておきます。小規模リポジトリは「更新を止めない」優先、monorepoは「CIコストを増やしすぎない」優先です。僕の24時間稼働のMac mini開発環境でもこの2型で回しています。

# 小規模向けの最小追加
open-pull-requests-limit: 3
cooldown:
  default-days: 2

# モノレポ向けの追加イメージ
groups:
  precommit-workspace:
    patterns: ["*"]
    update-types: ["minor", "patch"]

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

自動更新を先送りしたまま1年過ごすと起きること

このテーマは、今すぐ困っていないと後回しになりやすいです。ただ、更新を止める期間が長いほど、戻すときの差分は大きくなります。結果として一度に大量の修正が必要になり、通常開発を止める可能性があります。「今は動いているから大丈夫」を続けるほど、将来の修復コストが上がるんですよね。特に複数案件を抱える人ほど、週1回の小さな更新に分割した方が安全です。

この記事を書いている理由

僕自身、2026年3月17日にGitHub Actions課金とDependabot運用を絡めた記事を出したあと、相談でいちばん多かったのが「pre-commitのrev更新をどう回すか」でした。福祉事業のIT全般を担当しながら、AI×SaaS開発を複業で回す中で、更新が止まると現場の信頼が落ちる瞬間を何度も見てきました。だからこそ、自動化そのものより、止めない運用設計を共有したいと思ってこのテーマを書いています。僕が550名以上の面談で学んだのも、仕組みはシンプルな方が続くという一点でした。

次のアクション

まずは今週、pre-commitエコシステムをDependabotに追加して、minor/patchだけグループ化してみてください。運用が回り始めると、CIは一気に静かになります。設定で詰まったら気軽にコメントで聞いてください。