---
title: LGTM, Dependabot! 見てないけど
tags: 
author: [Kazuki Ohta](https://www.docswell.com/user/otariidae)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/4JQVWQ6R7P.jpg?width=480
description: STORES Tech Conf 2025 “What Would You Do?” https://storesinc.tech/conf/2025 のポスター発表の資料です
published: December 17, 25
canonical: https://www.docswell.com/s/otariidae/5WMDPG-lgtm-dependabot
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/4JQVWQ6R7P.jpg)

依存ライブラリを更新し続けるのは地味に大変
フローチャート
DepenadabotやRenovateがPRを自動でつくってくれるようになった。
DependabotがPRを作成
ありがたい。これで万事解決！めでたしめでたし...とはいかなかった。
全てのリポジトリの依存ライブラリを常に最新にし続けられてる？
ブランチ作成
ボトルネックはコードレビューへ
例：パッチバージョン
更新は軽微とみなす
PRが自動で作成されるようになったいま、コードレビューという工程は
最初で最大の関門だ。
軽微な変更か？
開発者には安全なソフトウェアを出荷する責任がある。無邪気にPRを
依存ライブラリを更新する
マージしまくって壊れたら困るから、レビューして安全性を確かめる。大
コード変更
事なことではあるが、相応の労力がかかるものだ。
NO
STORES特有の状況
例：マイナーバージョン
更新はAIに任せる
エンジニア組織がプロダクトカットからミッション単位のプロジェクト
カットに移行したことで、個々のシステムの保守・運用に継続的に関与し
commit
続けることが難しくなった。
AIに任せられる変更か？
問題
YES
結果として表裏の関係にある次の2つの問題が起こりがちだ。
YES
push
⚫ 🥺 更新が停滞する
○
Claude Code
Actionを使用
レビューに時間を割けずPRが放置されてしまう
⚫ 🥺 開発生産性が低下する
○
愚直にレビューしていると時間が溶けてしまう
○
本来推進したい開発は別にあるのに
AIがレビューして
承認したか？
PR作成
よくある対策のトレードオフ
たびたび挙げられる次の2つは問題の軽減策としては効くがトレードオフ
NO
YES
ボトルネック！→
があり、根本的解決にはならない。
⚫ 更新をまとめる
○
複数の依存ライブラリの更新を1つのPRにまとめる
○
👍 PRの数が少ない
○
🔥 レビューコストが増大
○
🔥 デグレリスクが増大
NO
コードレビュー
CIが通ったか？
⚫ 更新頻度を下げる
○
毎日じゃなくて1週間に1回とか1ヶ月に1回とかにする
○
👍 PRの数が少ない
○
🔥 依存関係を最新に保つという目的を毀損
マージ
YES
NO
理想形
コツコツ更新が一番良い。
自動でマージ
デプロイ
人間がレビュー
⚫ 小規模
○
変更が小さい
⚫ 頻回
○
3つの拠り所を多段階で組み合わせてこのようなフローとした。
頻繁に更新される
⚫ 安全
○
これをがんばってGitHub Actionsのワークフローとして記述するだけ。
結果として、カスタマイズも含めると300行超のYAMLができた。
壊れない
Tips
レビューからマージまでを自動化する
⚫ ☝ dependabot/fetch-metadataアクションが便利
根本的解決のためにはボトルネックの部分を太くしたい。手作業で細まっているのであれば、自動化すれば流れが良
⚫ ☝ マージはgithub.tokenではなくGitHub Appの権限で
○
依存の種類、アップデートの種類、パッケージエコシステムなどの情報を取得できる
github.token権限でマージするとマージコミットのCIが実行されない。罠 ☠
くなるはずだ。
○
安全の確保
安全策
自動化といえど、PRが来たらなんでもマージすれば良いわけではない。壊れたら困る。
信じるとはいえ、怖い部分はリスク低減策をとった。
そこで、低リスクでマージしても安全であろうと信じられる条件を検討して設定していった。
⚫ DependabotのPRの作成タイミングを平日の日中に設定
○
信じるための3つの拠り所
みんなの業務時間外にデプロイされてしまうことを防ぐ
⚫ クールダウン期間を設定
○
脆弱性や悪意のあるコードを含む更新を取り入れてしまうリスクを下げる
安全であると信じるために、次の3つを拠り所に選んだ。
⚫ CI
⚫ セマンティックバージョニング
⚫ ドキュメントとコードの読み合わせ機※1としてのAI
これらを組み合わせることで信じられる条件を構築する。
新規性が高いのはAIの利用だ。つまりAIのレビューを鵜呑みにするということだ。もちろんリスクがあるが、人間と比較
して現在のAIの出力は一定程度の信用に値すると考えて採用した。
上記3つに加えてリポジトリの特性に応じてカスタマイズも可能だ。例えばナイーブなSPAなら「ビルド成果物に差分がな
結果
⚫ 🎉 合計130コのPRをマージ
⚫ 4つのリポジトリでフローの全部もしくは一部を運用中
○
Railsとフロントエンド系が中心
⚫ ライブラリ更新起因の障害ゼロ
い」も拠り所に追加できる。
自動化フローの構築
GitHubの機能を使って構築した。
1. ブランチ保護ルールもしくはルールセットで必須のCIを設定
2. 一定の条件を満たして安全だと信じられる更新であれば、自動でapproveして自動マージを有効にするGitHub
Actionsのワークフローを作成
仕組みはシンプル。あとは「一定の条件を満たす」の部分をどう組むかが鍵になる。
日毎の自動マージ数の推移
今後の課題
⚫ スケーラビリティ
○
他リポジトリでもっと広めるために、手軽に導入できるようにしたい
⚫ 他エコシステムへの適用
○
例えばモバイルアプリでも適用可能か検証したい
⚫ プロアクティブな更新
○
依存に競合があってDependabotが自動でPRが作成されないケースも解消したい
⚫ 自動修正
※1：元ネタは https://scrapbox.io/shokai/ドキュメントとコードの読み合わせ機
○
ライブラリの破壊的変更・仕様変更があった場合に自動でコードを修正したい
○
リンター・フォーマッターの新ルール対応も自動で修正したい