2026年3月31日付の GitHub Changelog で、Dependabot が xcodeproj manifests を使う SwiftPM（Swift Package Manager）依存関係に対応したと案内されました。結論からいうと、Package.swift を置いていない Xcode 管理の iOS/macOS アプリでも、Dependabot で依存更新PRを自動化しやすくなった、というのが最大の変化です。Dependabot は .xcodeproj / .xcworkspace 内の Package.resolved を検出し、project.pbxproj にある制約を読み取り、適切な Package.resolved を更新するPRを作成できます。(The GitHub Blog)
これまで Apple 系のアプリ開発では、SwiftPM を Xcode 側で管理しているせいで Dependabot を素直に使えず、更新担当者がローカルで依存関係を上げて差分をコミットする運用が残りがちでした。今回の対応で、その“Xcode 起点の更新作業”を GitHub の標準的な PR フローに寄せやすくなります。ただし、導入の要になるのは /.github/dependabot.yml の設定、正しい directory 指定、そして CI での検証です。Dependabot の version updates は dependabot.yml をリポジトリに置いて有効化し、更新後はテストや変更内容を確認してからマージする前提で使うのが基本です。(The GitHub Blog)
GitHub.com ではすでに利用可能で、GitHub Enterprise Server では 3.22 での対応予定とされています。クラウド利用なら今すぐ試す価値があり、GHES 利用中なら自社環境の版数確認が最初のチェックポイントです。(The GitHub Blog)
Dependabot が Xcode projects の SwiftPM をサポートして何が変わったか
公式情報を整理すると、今回の変化の中心は「トップレベルの Package.swift がなくても、Xcode が管理する SwiftPM 依存関係を Dependabot が扱えるようになった」ことです。特にアプリ開発のリポジトリでは、この差がかなり大きいです。(The GitHub Blog)
| 項目 | 従来 | 今回の対応後 |
|---|---|---|
| 依存関係の前提 | トップレベルの Package.swift が事実上の前提 | Package.swift がなくても Xcode 管理の SwiftPM を拾いやすい |
| 検出対象 | Xcode 中心のアプリ案件では取りこぼしが出やすい | .xcodeproj / .xcworkspace 内の Package.resolved を自動検出 |
| 制約の扱い | Xcode 側の制約を前提にしづらい | project.pbxproj の version rules を解釈 |
| 更新結果 | 手動更新が残りやすい | Package.resolved を更新する PR を自動作成 |
要するに、ライブラリ寄りの Package.swift 中心運用だけでなく、Xcode プロジェクト中心のアプリ開発も Dependabot の守備範囲に入ってきた、と考えると分かりやすいです。(The GitHub Blog)
何が自動化されるのか
.xcodeproj / .xcworkspace 内の Package.resolved 検出
GitHub の changelog では、Dependabot が Xcode 管理の Package.resolved を .xcodeproj と .xcworkspace の両方の bundle layout で自動検出すると説明しています。つまり、SwiftPM の依存管理を Xcode に寄せているアプリでも、リポジトリ構成を無理に Package.swift 中心へ寄せ直さなくてよくなります。(The GitHub Blog)
project.pbxproj の制約を踏まえた更新
単に「最新版へ上げる」だけではなく、Dependabot は project.pbxproj から依存関係の version rules を読み取って、Xcode で設定した制約を尊重しながら更新します。現場目線では、制約無視の雑な更新ではなく、Xcode の設定を前提にした PR になりやすい点が重要です。(The GitHub Blog)
更新 PR の自動作成
Dependabot は適切な Package.resolved をその場で更新する PR を作成します。Dependabot の version updates 自体も、依存関係が古くなったときに PR を起こし、レビュー担当者がテストや changelog、release notes を確認してからマージする運用を前提にしています。今回の対応で、その標準フローを SwiftPM の Xcode 管理プロジェクトにも広げやすくなりました。(The GitHub Blog)
まず確認したい、恩恵が大きいプロジェクト
次の条件に当てはまるほど、今回のアップデートの効果は大きくなります。
Package.swiftを置かず、アプリ本体を Xcode プロジェクトやワークスペースで管理している- SwiftPM の解決結果を
Package.resolvedとして Git 管理している - GitHub 上で PR レビューと CI を回している
- 複数の Apple 向けアプリやモジュールを持ち、依存更新の手作業が負担になっている
特に「アプリだから Package.swift は使っていないが、SwiftPM は使っている」というチームには直撃の改善です。逆に、すでに Package.swift ベースで Dependabot を回せていたライブラリ中心のリポジトリでは、今回の更新は“新機能の追加”というより“アプリ案件にも同じ運用を広げやすくなった”と捉えると理解しやすいです。(The GitHub Blog)
導入手順：最小構成と実運用の設定
Dependabot の version updates は、/.github/dependabot.yml をコミットして有効化します。設定上の必須要素は version、updates、package-ecosystem、directory または directories、そして schedule.interval です。Swift の ecosystem 値は swift です。GitHub Docs の quickstart では、リポジトリの Settings から Dependabot を有効化でき、dependency graph が未有効なら自動で有効化されると案内されています。(GitHub Docs)
最小構成の例
version: 2
updates:
- package-ecosystem: "swift"
directory: "/"
schedule:
interval: "weekly"この設定で、リポジトリ直下を起点に Swift 依存関係の更新を週1回チェックできます。プロジェクトが /ios/App 配下にあるなら directory: "/ios/App" のように調整してください。複数のアプリやモジュールを同じリポジトリで管理しているなら directory ではなく directories を使います。directories はリポジトリルートからの相対指定で、glob や * も使えます。(GitHub Docs)
実運用向けの例
version: 2
updates:
- package-ecosystem: "swift"
directory: "/"
schedule:
interval: "weekly"
day: "tuesday"
time: "10:00"
timezone: "Asia/Tokyo"
open-pull-requests-limit: 3
cooldown:
semver-major-days: 14
semver-minor-days: 3
semver-patch-days: 1この例が実務向きなのは、PR の出るタイミングと量を制御できるからです。GitHub Docs では、schedule.interval だけを指定した場合、Dependabot は実行時刻をランダムに割り当てるとされています。週次レビューの前にまとめて PR を出したいなら、day、time、timezone まで固定したほうが運用しやすいです。また、version updates の同時オープン PR 数はデフォルトで 5 なので、ノイズを抑えたいなら open-pull-requests-limit を下げる意味があります。Swift は SemVer ベースの cooldown にも対応しているため、メジャー更新だけ遅らせる設定も相性がいいです。(GitHub Docs)
PR が増えすぎない運用のコツ
Dependabot は便利ですが、設定を雑にすると「PR が増えて誰も見なくなる」状態に陥りやすいです。GitHub Docs でも、更新頻度の制御、groups による集約、cooldown による遅延が用意されており、レビュー負荷を減らす前提で使うことが推奨されています。(GitHub Docs)
| 状況 | 最初に試したい設定 |
|---|---|
| 毎週の定例でまとめてレビューしたい | schedule で曜日・時刻・タイムゾーンを固定 |
| PR 数を抑えたい | open-pull-requests-limit を 3〜5 で調整 |
| major 更新だけ慎重に見たい | cooldown で major を遅らせる、必要なら ignore も使う |
| 複数アプリを同じリポジトリで管理している | directories を使い、必要に応じて groups や group-by: dependency-name を検討 |
特にモノレポ構成では、directories を複数指定したうえで groups.<group-name>.group-by: dependency-name を使うと、同じ依存関係の更新をディレクトリ横断で1つの PR にまとめやすくなります。複数の iOS アプリやサンプルアプリを同じリポジトリで持っている場合に効きやすい設定です。(GitHub Docs)
バージョン更新と脆弱性対応は別で考える
Dependabot には大きく分けて alerts、security updates、version updates の3つがあります。version updates は脆弱性の有無に関係なく新しい版へ追従する仕組みで、dependabot.yml で制御します。一方の security updates は、dependency graph と Dependabot alerts が有効になっていて、既知の脆弱性に対してパッチがあるときに修正 PR を起こす仕組みです。今回の changelog は、Xcode 管理の SwiftPM プロジェクトで「version updates を回しやすくする」意味合いが特に強い、と理解しておくと混乱しません。(GitHub Docs)
| 機能 | 役割 | 設定の中心 |
|---|---|---|
| Dependabot version updates | 古くなった依存関係を新しい版へ追従させる | dependabot.yml |
| Dependabot security updates | 既知脆弱性の修正 PR を自動作成する | dependency graph + alerts + security updates |
「今回の対応で脆弱性修正まで全部自動になるのか」と期待しすぎるとズレます。まずは version updates を安定運用し、そのうえで alerts と security updates を組み合わせる、という順番のほうが現場では失敗しにくいです。(GitHub Docs)
ハマりやすいポイント
Package.resolved をコミットしていない
changelog では、リポジトリ内の .xcodeproj bundle に Package.resolved があれば次回の scheduled run で Dependabot が自動検出すると説明されています。裏を返すと、対象ファイルがリポジトリに存在しないなら、自動検出の前提を満たしません。まずは Package.resolved をどこまで Git 管理するのかをチームで統一してください。(The GitHub Blog)
directory の指定がずれている
Dependabot は directory または directories に基づいて定義ファイルの場所を見に行くため、この指定が外れていると PR が出ません。GitHub Docs でも、directory / directories は version updates に必須で、複数ブロックを同一 ecosystem に使う場合はディレクトリが重ならないようにする必要があると説明されています。(GitHub Docs)
CI がないまま自動化だけ先に入れる
Dependabot の version updates は PR を作ってくれますが、最終的にマージ可否を判断するのはチームです。GitHub Docs でも、更新 PR ではテストの成功確認、changelog や release notes のレビューを行ってからマージする前提が示されています。iOS アプリのようにビルドと実機差分の影響が大きい案件では、ここを省くと自動化のメリットより事故のほうが目立ちます。(GitHub Docs)
Swift private registry 前提で考えている
GitHub Docs では、Swift の private registry 対応は git registries のみで、Swift registries 自体はサポートされていないと案内されています。社内の依存配布方法が Swift registry 前提なら、導入前にこの点を確認しておかないとハマります。(GitHub Docs)
GitHub Enterprise Server の版数を見落とす
今回の対応は GitHub.com では利用可能ですが、GHES は 3.22 対応予定です。社内で GitHub Enterprise Server を使っている場合、記事を読んですぐ設定を書き始めるより、まず環境の版数を確認するほうが確実です。(The GitHub Blog)
Dependabot が Xcode + SwiftPM に対応した今、最初にやること
まずやるべきことはシンプルです。Package.swift の有無ではなく、Xcode 管理の SwiftPM 依存関係がリポジトリ内でどう表現されているかを確認し、Package.resolved を Git 管理していることを確かめたうえで、/.github/dependabot.yml に package-ecosystem: "swift" を追加します。その後、週1回・時刻固定・PR 上限ありの控えめな設定で回し、初回の PR を CI で検証してからチームの運用に合わせて微調整するのが現実的です。(The GitHub Blog)
今回のアップデートの本質は、Xcode 中心の Apple アプリ開発も GitHub の標準的な dependency update workflow に乗せやすくなったことです。手動更新の習慣がまだ残っているなら、まずは1リポジトリだけでも Dependabot を試す価値は十分あります。うまく回れば、依存更新は「思い出した人がやる作業」ではなく、「決まった頻度で流れてくるレビュー対象」に変わります。(The GitHub Blog)
コメント