先に結論
Scala と sbt を使う repository があるなら、今回の更新は見逃さないほうがいいです。
GitHub は 2026-05-26 に、Dependabot version updates が sbt ecosystem をサポート したと案内しました。
これで .github/dependabot.yml に sbt を足すだけで、build.sbt を見た更新 PR を GitHub 上で回せます。
一番大事なのは、今回の主語が version updates だという点です。
security updates まで一気に何か変わる話ではありません。まずは「Scala repo が Dependabot の監視対象に入るようになった」と読むのが正確です。
Dependabot の private registry 側も含めて整理したいなら、Dependabot OIDC 対応の整理 もつながります。期限付きの停止リスクを見るなら、Dependabot Python 3.9 廃止の整理 も参考になります。
今回何が変わったのか
GitHub changelog の案内はかなりシンプルです。
Dependabot now supports sbt. Add sbt as a package ecosystem in your dependabot.yml file.
つまり、新しくできるようになったのは次の 2 点です。
package-ecosystem: "sbt"をdependabot.ymlに書ける- Dependabot が
build.sbt入力を監視し、upstream に新しい commit があれば PR を開ける
GitHub Docs の options reference でも、サポートされる package ecosystem の一覧に sbt が加わっています。
そのため、今回の更新は「Scala repo だけ Dependabot の自動更新から外れていた」というチームほど効きます。
最小設定はこれで足ります
root に build.sbt がある repository なら、最初の設定はかなり小さくできます。
version: 2
updates:
- package-ecosystem: "sbt"
directory: "/"
schedule:
interval: "weekly"これを .github/dependabot.yml に置けば、次の scheduled run から Dependabot が sbt を見始めます。
すでに npm や Docker や GitHub Actions を Dependabot で回している repository なら、既存の updates: 配下へ sbt の entry を 1 つ足すだけです。
monorepo で Scala 部分がサブディレクトリにあるなら、directory はその場所に合わせて分けたほうが安全です。
まず誰が見直すべきか
今回すぐ価値が出るのは、Scala と sbt の repository があるのに、依存更新をまだ手で回しているチーム です。
特に優先度が高いのは次のケースです。
- GitHub 上の Dependabot 運用に Scala repo だけ穴が空いていた
- platform team が複数言語の更新方針をそろえたい
- AppSec や DevOps が dependency updates の棚卸し対象を広げたい
- monorepo の中に
build.sbtが残っていて、更新漏れが起きやすい
逆に、Scala を持たない組織には直接の影響はありません。
ここは誤解しないほうがいい
一番ずれやすいのは、version updates と security updates を同じものとして読むこと です。
GitHub changelog は、今回の更新を version updates だと明記しています。
そのため、今回増えるのは「新しい upstream に追従する更新 PR を出せる範囲」です。
脆弱性の検出や security updates の扱いは、別の設定や既存機能として見ておくほうが安全です。
もう 1 つ見落としやすいのは、directory 設計 です。
root の build.sbt だけなら簡単ですが、Scala が一部ディレクトリにだけある monorepo では、directory を雑に書くと review 対象が読みにくくなります。
最初は root か主要な 1 ディレクトリから始め、PR の出方を見てから広げるほうが失敗しにくいです。
実務ではここから始めると楽です
一番堅い順番は次の 3 つです。
- Scala と sbt を使う repository を洗い出す
- 既存の
.github/dependabot.ymlに sbt entry を足せるか見る - weekly か daily か、どの頻度なら review できるか決める
ここで review 体制まで決めておくと、PR だけ増えて放置される状態を避けやすくなります。
GitHub 上の CI / security 運用まで広く見直したいなら、GitHub Actions security roadmap 2026 の整理 と合わせて考えると、workflow 権限や dependency review までつながります。
まとめ
Dependabot の sbt 対応は、派手ではありませんが実務では効く更新です。
今日の時点で押さえることは多くありません。
- sbt が version updates の対象に加わった
.github/dependabot.ymlにpackage-ecosystem: "sbt"を足せば始められる- 対象は
build.sbt入力を見た更新 PR - security updates の拡張ではない
- monorepo では
directory設計を先に見る
Scala repo を持つのに Dependabot へ入れていなかったチームなら、まず 1 repository から足してみる価値があります。今回の更新は、その最初の一歩をかなり軽くしてくれます。