dependabot 11 本の triage で踏んだ 6 つの罠

kokan-nikki の repo で長らく依存更新を放置していたので、.github/dependabot.yml を入れた。merge した瞬間に PR が 7 本立ち、その日のうちにさらに 4 本追加、計 11 本になった。GitHub Actions 5 本 + npm patch/minor 6 本を全部 merge し、major 4 本 (prisma 7 / @types/node 25 / typescript 6 など) は別タスク扱いに切り出した。

dependabot 自体は素直なボットだが、初回導入のバーストと、その後の運用で「ドキュメントには載っていない (or 載っていても読み飛ばす) 罠」を 6 個踏んだので残しておく。

1. 初回バースト

.github/dependabot.yml を main に merge した瞬間、schedule が weekly でも install 検出時に 1 周走る。長期間 dependabot 無しだった repo では初回で 10 本前後の PR が一気に立つことを想定する。普段の運用は週 1 で 0〜数本だが、初回だけは別。

これは仕様で、想定通りの挙動。問題は次。

2. lockfile を共有する PR は conflict cascade を起こす

package.json / pnpm-lock.yaml を触る npm 系 PR を順次 merge していくと、2 本目以降は必ず CONFLICTING になる。同じ lockfile を全 PR が触るため。

対処は 2 つ。

# 方式 A: 1 本 merge するごとに残りに rebase 指示
gh pr merge 104 --squash --delete-branch
gh pr comment 105 --body "@dependabot rebase"
gh pr comment 107 --body "@dependabot rebase"
# ... 残り全部に

# 方式 B: 最初から auto-merge を仕掛けて GitHub に並列処理させる
for n in 104 105 107 108 109 111
  gh pr merge $n --auto --squash --delete-branch
end

方式 B の方が手数が少ないが、後述の「--auto は branch protection 次第で即時 merge」に注意。GitHub Actions 系 PR は同じ workflow ファイルでも別の行を触っているので conflict は出にくく、こちらは並列で投げて問題ない。

3. @dependabot rebase / recreate が無反応のことがある

PR コメントで @dependabot rebase を投げると bot が Looks like ... rebasing now と返事して PR を rebase してくれる 建前。だが実際は無反応で固まることがある。GitHub 側の service 遅延か特定の状態 (CONFLICTING の解消に lockfile 再生成が要るときに起きやすい印象) で詰まる。

3 分待って動かなければ手動 rebase に切り替えた方が早い:

gh pr checkout <N>           # PR ブランチをローカルへ
git merge origin/main        # main を取り込む (conflict 出る)
# package.json の conflict を手動解消
pnpm install                 # pnpm-lock.yaml を再生成
git add package.json pnpm-lock.yaml
git commit                   # デフォルトの merge commit メッセージで OK
git push origin <branch>

人間が push したブランチを dependabot が force-push で奪い返すことは無い。CI が走り直して MERGEABLE になれば squash merge できる。今回は #111 zod がこれで詰まり、手動 rebase で解消した。

4. pnpm-lock.yaml の conflict は手で解こうとしない

merge conflict が pnpm-lock.yaml に出たとき <<<<<<< HEAD のマーカーを手で除去するのは無理筋。lockfile は自動生成物で、package.json の整合に基づく数千行のハッシュが入っている。手で解いても整合は取れない。

代わりに、

git checkout --theirs pnpm-lock.yaml   # またはどちら側でもよい
pnpm install                            # 新しい package.json と整合した lockfile を再生成
git add pnpm-lock.yaml

pnpm install は package.json を入力にして lockfile を作り直すので、conflict があっても上書きで解決する。手解きは時間と精神力の無駄。

5. --auto --squash は条件次第で即時 merge する

gh pr merge 105 --auto --squash --delete-branch

これは「CI が緑になったら merge してくれ」のつもりで投げる。ところが branch protection の "require status checks to pass" が設定されていない repo では、UNSTABLE (CI 走行中) でも mergeable なら --auto を投げた瞬間に merge が走る。

「CI 待ち」のつもりで投げて、5 秒後に main にコミットが乗っていて驚く。

CI 完了を確実に待ちたいなら 2 択:

• branch protection の "require status checks" を ON にする (推奨、副作用としてこの問題は永久に消える)
• --auto ではなく CI 完了を見届けてから普通に --squash を投げる

私は今回の repo を private mirror として運用しているので branch protection を切っていた。今回の triage 中は前者に倒すか迷ったが、後者で済ませた。

6. LSP の警告と tsc --noEmit の結果はズレる

pnpm install 直後に LSP (TypeScript Server) が

Property 'session' does not exist on type 'null | { ... }'
Module '"next/navigation"' has no exported member 'redirect'
Cannot find module '*.module.css' or its corresponding type declarations

のような警告を一斉に出すことがある。これに引きずられて「依存更新で型が壊れた」と誤判定しがちだが、

pnpm exec tsc --noEmit
# Found 0 errors.

を走らせると clean。LSP 側の TS Server がパッケージ更新に追いついていないだけの偽陽性で、TS Server を restart すれば消える (VSCode なら Cmd+Shift+P → TypeScript: Restart TS Server)。

CI を信じる、LSP を信じない。これは dependabot に限らず、pnpm install 直後の一般則として有用。

残ったもの

major bump 4 本 (prisma 7、@types/node 25、typescript 6、もう 1 本) は今回見送った。これらは breaking change を含む可能性が高く、CI green だけでは動作確認として不十分。各々の release notes と migration guide を読んでから個別に上げる。dependabot は PR を立て続けてくれるので、こちらの都合で順に処理すればよい。

なぜここで効くか

依存更新は溜めると指数的に大変になる (5 段以上溜めると breaking change が累積する) ので、定期的に 1 段ずつ上げるのが正解。dependabot は「定期的に 1 段ずつ」を自動化する仕組みだが、初回導入と週次運用で挙動が違うこと、特にバースト時の lockfile cascade と rebase 無反応に備えると、triage が「機械的に CI 緑なら merge」のリズムに乗る。乗り遅れると 11 本の山を見て心が折れる、これは作業速度の問題ではなく整流の問題だった。

(Origin: 2026-05-07、kokan-nikki repo に .github/dependabot.yml を導入した日。PR #82/#95 で dependabot 設定 merge → 初回バースト 7 本 + 途中追加 4 本 = 11 本 triage、Actions #97-#101 + npm #104-#111 を merge、major 4 本は別タスクへ。)