مرکزی مواد پر جائیں
友田 陽大
Dependabot & dependency automation
Dependabot
モノレポ
Turborepo
依存関係管理
GitHub Actions
DevSecOps

Dependabot でモノレポを回す:Turborepo / pnpm workspaces を directories・groups で破綻させない設計

モノレポ(Turborepo / pnpm・npm・yarn workspaces / Nx)で Dependabot を破綻させずに運用する設計ガイド。公式ドキュメント(2026年6月時点)に忠実に、directories のグロブで1エントリに集約する方法、ワークスペースとロックファイルの関係、groups と group-by: dependency-name でディレクトリ横断にPRを束ねる方法、パッケージ別ポリシー、影響範囲だけテストするCIとの連携までを、コピペできる実コードで解説します。

Published
Last updated
Updated
Reading time
6 min read
Author
友田 陽大
شیئر کریں

モノレポに Dependabot を素朴に入れると、月曜の朝に数十本のPRが並ぶ——そして誰も見なくなります。原因は明確で、モノレポでは更新対象が「パッケージ数 × 依存数」に膨らむからです。けれどこれは設計で解けます。directories で集約し、groups で束ね、cooldown で寝かせ、auto-merge で patch/minor を流す——この4点で、巨大モノレポでも依存更新は静かに自動化されます。

この記事はDependabot 本番運用ガイドの各論として、モノレポ特有の設計にフォーカスします。Turborepo / pnpm workspaces を主な題材にしますが、npm/yarn workspaces・Nx でも考え方は同じです。

この記事のルール:設定キー・挙動は GitHub 公式ドキュメント(2026年6月時点) に基づきます。directories(グロブ)・group-by は比較的新しい機能です。本番前に必ず公式の設定リファレンスで最新を確認してください。


0. なぜモノレポで破綻するのか

通常リポジトリ:   1 つの package.json → 依存 N 個 → 最大 N 本のPR
モノレポ(素朴):  M 個の package.json → 依存 N 個ずつ → 最大 M×N 本のPR

apps/ に5つ、packages/ に10、それぞれが数十の依存を持てば、容易に3桁のPRになります。これを「頻度を下げる」で誤魔化すと、今度は脆弱性対応が遅れます。正しい解は集約と束ねです。順に組み立てます。


1. directories のグロブで1エントリに集約

かつてはディレクトリの数だけ updates エントリを書いていました。いまは directories(複数形)+グロブで1エントリにまとめられます。

version: 2
updates:
  - package-ecosystem: "npm"
    directories:
      - "/"            # ルート(ワークスペース定義・共有devDeps)
      - "/apps/*"      # 各アプリ
      - "/packages/**" # 共有パッケージ(再帰)
    schedule:
      interval: "weekly"

* は1階層、** は再帰。これで新しいアプリ/パッケージを足しても設定変更が不要になります(ETC:変更が一箇所に閉じる)。


2. ワークスペースとロックファイルの関係(ここが肝)

モノレポの依存解決はロックファイルの位置で決まります。

  • pnpm workspacespnpm-lock.yamlリポジトリ・ルートに1つ。全ワークスペースの依存がここに解決されます。
  • npm / yarn workspaces:同様にルートに単一のロックファイルpackage-lock.json / yarn.lock)。

つまり多くのモノレポでは、まずルート(/)の1エントリだけで、全ワークスペースの外部依存を更新できます。各 apps/*package.json は「どの外部依存を使うか」を宣言しますが、解決の真実源はルートのロックファイルです。

# pnpm/npm/yarn workspaces:まずはルート1エントリで十分なことが多い
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

個別アプリで異なる更新ポリシー(頻度・グループ・ignore)を分けたいときに初めて directories で展開します。YAGNI:最初からアプリ単位に割らず、必要になってから割るのが運用を軽く保つコツです。


3. groups でPRを束ねる

集約しても、束ねなければPRは依存数だけ出ます。groups意味のある単位にまとめます。

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      types:
        patterns: ["@types/*"]
      testing:
        patterns: ["vitest", "@testing-library/*", "playwright", "msw"]
      linting:
        patterns: ["eslint*", "prettier", "@typescript-eslint/*"]
      # 上記以外の minor/patch を1本に(major は個別PRのまま)
      minor-and-patch:
        update-types: ["minor", "patch"]
        exclude-patterns: ["@types/*", "vitest", "eslint*"]

これで「型」「テスト」「lint」「その他 minor/patch」の4〜5本に集約され、レビュー対象が劇的に減ります。groups の全オプションは設定完全ガイドへ。


4. group-by: dependency-name でディレクトリ横断に統合

アプリ単位で directories を割っている場合、「全アプリの react 更新がバラバラにPR化」されると本末転倒です。group-by: dependency-nameディレクトリをまたいで同一依存をまとめます

  - package-ecosystem: "npm"
    directories: ["/apps/*"]
    schedule:
      interval: "weekly"
    groups:
      react-across-apps:
        patterns: ["react", "react-dom", "next"]
        group-by: "dependency-name"   # 全 app の react/next 更新を1PRに

フレームワークのバージョンをモノレポ全体で揃える運用(バージョンスキューの防止)と相性が良い設定です。


5. 内部パッケージは更新対象外(だから楽)

モノレポでは内部パッケージを "@acme/ui": "workspace:*" のように参照します。この workspace:* 参照は Dependabot の更新対象になりません——内部パッケージのバージョンはモノレポ自身が管理するものだからです。

つまり Dependabot は外部依存の追従だけに集中します。「内部依存を ignore しなきゃ」と心配する必要はありません。内部パッケージ間の整合は、Turborepo/Nx のビルドグラフや changesets など別のツールの仕事です(SRP:責務を混ぜない)。


6. パッケージ別ポリシー(リスクに比例した更新)

すべてを同じ強度で更新する必要はありません。本番に近いほど慎重に割り当てます。

updates:
  # アプリ:積極的に追従(minor/patch は groups でまとめ auto-merge 前提)
  - package-ecosystem: "npm"
    directories: ["/apps/*"]
    schedule:
      interval: "weekly"
    groups:
      app-minor-patch:
        update-types: ["minor", "patch"]
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]   # major は人間が棚卸し

  # 共有ライブラリ:保守的(月次・cooldown 長め)
  - package-ecosystem: "npm"
    directories: ["/packages/**"]
    schedule:
      interval: "monthly"
    cooldown:
      default-days: 14

共有ライブラリの破壊的変更は全アプリに波及します。だから libs は頻度を落とし cooldown を長めに。アプリは速く小さく追従。この使い分けが、安定性と鮮度のトレードオフを地に足のついた形で解きます。


7. CI と auto-merge:影響範囲だけ回す

モノレポで全パッケージをフルテストすると、Dependabot PR のたびに CI 時間(=Actions 課金)を浪費します。影響パッケージだけテストします。

# .github/workflows/ci.yml(抜粋)— Turborepo の filter で影響範囲のみ
- run: pnpm install --frozen-lockfile
- run: pnpm turbo run lint test build --filter="...[origin/main]"

--filter="...[origin/main]" は「変更の影響を受けるパッケージとその依存元だけ」を回す指定。Dependabot PR の差分に応じて必要最小限のテストになり、速く・安く・確実になります。

その上でauto-mergeを組み合わせ、グループ化された patch/minor を CI 条件付きで自動マージします。

      - name: Auto-merge grouped patch/minor
        if: |
          steps.meta.outputs.dependency-group != '' &&
          steps.meta.outputs.update-type != 'version-update:semver-major'
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

8. モノレポ運用チェックリスト

  • ルート1エントリから始める(ワークスペースのロックファイルはルート単一)
  • アプリ別ポリシーが要るときだけ directories で展開(YAGNI)
  • groups で型/テスト/lint/その他 minor-patch を束ねる
  • アプリ横断のバージョン統一は group-by: dependency-name
  • 共有ライブラリは月次+長め cooldown、アプリは週次+積極追従
  • CI は影響範囲のみ(Turborepo/Nx の filter)で時間とコストを最小化
  • グループ化 patch/minor は auto-merge、major は人間レビュー

عمومی سوالات

apps と packages で全部 package.json があります。エントリも分けるべき?
まずは**ルート1エントリ**で十分なことが多いです(ワークスペースのロックファイルはルート単一)。頻度やグループを**個別に変えたくなってから** `directories` で割ってください。
全アプリの react がバラバラにPR化されます。
`directories` を割っているなら `group-by: dependency-name` で同一依存をディレクトリ横断にまとめてください。バージョンスキューも防げます。
内部パッケージ(workspace:*)も更新されますか?
されません。Dependabot は外部依存だけを見ます。内部整合は changesets や Turborepo/Nx の仕事です。
PRごとに全パッケージのCIが回って遅い・高いです。
Turborepo/Nx の filter で**影響範囲だけ**テストしてください。Dependabot は標準ランナーで無料ですが、CI 自体は通常通り Actions 分を消費します。
pnpm の `pnpm-lock.yaml` は正しく更新されますか?
はい。Dependabot はルートのロックファイルを解決して更新します。ロックファイルは必ずコミットしてください。

حوالہ جات

友田

友田 陽大

وزیر (METI) ایوارڈ یافتہ پروڈکٹ کے ڈویلپر۔ TypeScript + Python + AWS کے ساتھ میں SaaS، صنعتی ڈیجیٹل تبدیلی اور پروڈکشن کے قابل جنریٹو اے آئی (RAG) تنہا ابتدا سے انتہا تک فراہم کرتا ہوں — تقاضوں کی تعیین سے انفراسٹرکچر اور آپریشن تک۔

I can take on the implementation from this article as an engagement

Dependency auto-updates & supply-chain defense, from design to production

From enabling alerts/security/version updates, to dependabot.yml design (groups, cooldown, monorepo directories, private registries), safe auto-merge via GitHub Actions + fetch-metadata (auto for patch/minor, human review for major), severity-based-SLA vulnerability response, and observability of the open count. With experience wiring dependency updates into CI quality gates, I implement automation that doesn't flood you with PRs or pile up technical debt.

پروجیکٹ کی بنیاد پر کام اور تکنیکی مشاورت دونوں کے لیے دستیاب ہوں۔ 30 منٹ کی مفت مشاورت سے آغاز کریں۔

最短ルート:カレンダーから直接予約

相談内容が固まっている方は、フォーム送信よりその場で日程を確定する方がスムーズです。下記から空き時間をお選びください。

  • 30分のオンライン無料相談
  • Google Meet / Zoom / Microsoft Teams
  • NDA 商談前締結可・無理な営業はいたしません
無料相談の空き枠を予約する

یہ بھی پڑھنے کے قابل