Dependabot の依存更新を『週次でまとめて検証・自動マージ』にする
依存更新の PR は、放っておくと溜まり、いざ触ると一気に壊れます。「ぽんっ！」（旧称：でいりんぐ）では、Dependabot を週次に固定し、そのあと走らせた検証で全合格なら自動マージ、破壊的変更は直してからマージする運用に整えました。個人開発でも回る形にした工夫を残します。
背景（当時の状況）
個人開発だと、依存更新の PR はつい後回しになり、気づけば大量に溜まって手がつけられなくなりがちです。2026-07-16、これを仕組みで解決しようと、Dependabot を週次に固定し、そのあと検証して問題なければ自動でマージする運用に整えました。
週次に固定して「まとめて」扱う
Dependabot は既定だと更新のたびに PR を作りますが、これを曜日・時刻で固定しました。
- 毎週月曜の朝に Dependabot を実行（
dependabot.ymlでスケジュール固定）。 - 対象は Flutter 側（pub）と Cloud Functions 側（npm）。
- パッチ更新は無視して、意味のある更新（マイナー/メジャー）に絞る。ノイズを減らし、レビュー対象を意味のある差分に寄せます。
「いつ来るか分からない PR」を「毎週この時間にまとめて来る」に変えるだけで、扱いがぐっと楽になります。
少し後に検証ジョブを走らせ、合格なら自動マージ
Dependabot が PR を作った数時間後に、検証して問題なければマージする段取りを回します。これは GitHub Actions 上にコミットしたワークフローではなく、定期実行のルーティンとしての運用です（本記事では構成の詳細には踏み込みません）。方針はこうです。
- 検証が全合格なら自動マージ。
- 破壊的変更は、ジョブ自身が修正を実装 → 検証 → 自前 PR → マージまで行う（1 回の実行で修正は上限を設ける）。
- 修正不能な外部要因のブロックだけ報告に留める。
- 認証・課金など影響の大きい修正は、PR に 「手動確認推奨」 を明記したうえでマージする。
「更新はしたいが毎回手で見る時間はない」という個人開発の現実に、自動で通せるものは通し、危ういものだけ人に上げるという線引きで対応しています。
外部要因でブロックされる依存は無理に上げない
すべてが上げられるわけではありません。外部要因で止まる依存は、無理せず据え置きます。実際に止まっていた例:
- あるメジャー更新が、別ツールがその新メジャーに未対応の間はブロック。
- ある依存の新メジャーが、別パッケージの peer 依存の上限に引っかかる／要求するランタイムのバージョンが実行環境と不整合。
- 実機テストが必須で、クラウドの検証だけでは完了できない更新。
これらは「上げられない理由」を記録して据え置き、前提（対応版のリリース等）が整ってから再挑戦します。無理に上げて壊すより、ブロック理由を明示して待つほうが安全でした。
まとめ
- Dependabot は週次に固定 + パッチ無視で「まとめて意味のある更新」に整えるとノイズが減る。
- 検証 → 全合格なら自動マージ、破壊的変更は直してからマージ、外部要因は報告のみという線引きで、個人開発でも依存更新を回せる。
- 上げられない依存は理由を記録して据え置く。前提が整うまで待つのも立派な運用判断です。