ADR-0196: 依存関係の週次自動更新を有効化

• Status: Accepted
• Mode: Standard
• Kruchten Type: Executive/Property
• Scope: platform
• Implementation Status: Partial (dependabot.yml PR #4055 shipped 済 · 追加配線 3 file (.github/workflows/dependabot-dup-close.yml / dependabot-zero-pr-alert.yml / scripts/dependabot_sla_export.mjs) + docs 2 本 (dependency_management.md 新設 / git_workflow.md 追記) は本 ADR 受理後 2 週間以内で予定 · Review After 2026-10-01)
• 起案者: [email protected]
• 起案日時 (JST): 2026-07-03 08:21
• 承認日時 (JST): 2026-07-03
• Approver Role: platform
• Approver Who: [email protected]
• Driver: [email protected]
• Consulted: Decision Pipeline AI 審査 (Gate 0-4)

1. Executive Summary

• 文脈: Enterprise 化直後 (2026-07-03) に GitHub Dependabot alerts が 44 件検出された状況で、drp/pnpm-lock.yaml 由来の hono 9 alerts が自然発火の Security Update PR 対象から漏れて 2 日以上滞留していた。
• 課題: .github/dependabot.yml (= Dependabot の設定ファイル) が未存在で Version Updates が起動せず、脆弱性 fix PR が起票されないまま alerts が積み上がる状態が続いた。
• 対策: .github/dependabot.yml に 4 update 単位 (root / drp / tools/rq-eval / github-actions) を weekly で明示登録し、label 分離 (dep-*) で並行 PR 数を制御する。
• 効果: drp/hono 9 alerts を含む未 PR 化案件を weekly cycle 内で PR 化し、月間 open dependency PR 数を 16 件以内に抑える。
• 代償: 月 CI minute 約 32 分の追加消費 (= 月 $0.26 想定) と PR review 工数 30-60 分 / 月 の増加。

2. 何を解決するか

2.1 背景

Enterprise 化 (2026-07-03) で Dependabot alerts が正常に稼働し始めたが、root pnpm-lock.yaml のみ自然発火し drp / tools/rq-eval は起票されない状態だった。drp/hono 9 件の alerts のうち、CVE-2025-XXXX を含む複数の脆弱性が 2 日以上未 PR 化のまま滞留していた。

2.2 現状 (As-Is)

• 適合性: .github/dependabot.yml が未存在で Version Updates が起動しない。Security Update は自然発火するが drp/tools 領域では 4 update 単位のうち 3 単位が未カバー。
• 運用性: 手動 pnpm update の運用は過去 4 回中 3 回で一括更新に流れており、粒度制御が破綻している。月 20-40 件の依存更新を人手で消化する工数が捻出できない。
• 安全性: drp/hono 9 alerts が 2 日以上滞留し、SOC 2 / ISO 27001 目標に対する「脆弱性対応 SLA 不定」の指摘リスクが顕在化している。

2.3 課題

• 安全性: 脆弱性を含む依存が未 PR 化のまま production Cloudflare Workers (drp) に残留する構造リスクが存在する。
• 運用性: 手動運用では update 粒度が大きすぎて review が難航し、過去 4 回中 3 回で一括更新に流れた実測がある。
• 適合性: Security Update は自然発火するが、Version Update が動かないため drp/hono のような version drift 起因の alerts が拾えない。

2.4 制約・要件

• 適合性: Enterprise 化以後の Dependabot v2 schema (version: 2 固定・updates array 形式) に準拠する。
• 運用性: Merge Queue に一度に 5 件以上が集中しない設計にする (並行 PR 数制御)。
• 安全性: 未 PR 化 alerts の SLA を「30 日以内に PR 化」に暫定設定する。
• 保守性: 次段の auto-approve ルール ADR に接続できる label 分離を先行整備する。

2.5 目標 (To-Be)

drp/hono 9 alerts を含む未 PR 化案件を weekly cycle 内で PR 化し、7 日以内 PR 化率 > 80% · 月間 open dependency PR 数 16 件以内を成立させる。Non-Goals: 本 ADR では auto-approve ルール (patch/minor の自動承認) の実装は行わない (次段 ADR で対応)。

3. 採用したい方針

3.1 対策方針

.github/dependabot.yml に 4 update 単位を明示登録し、weekly interval で自動 PR 化する運用を有効化する。個々の update PR は Merge Queue + auto-merge で消化し、主要 review は「複数 dependency の同時 major bump」時のみ人手介入する。label 分離 (dep-root / dep-drp / dep-tools / dep-actions) を先に整備し、次段 (別 ADR) で auto-approve ルールに接続する。

• 運用性: weekly 集約で PR 数を月 16 件以内に抑え、daily 発火の PR 洪水を避ける。
• 安全性: 各 update の CI が全て緑にならないと merge されない gate は既存 (Merge Queue) のまま保持する。
• 保守性: label 分離で source manifest を可視化し、次段 auto-approve ルール (dep-actions patch は自動 approve 等) の起点にする。

3.2 守るべき設計制約

• 適合性: Enterprise 化以後の Dependabot v2 schema に準拠する (version: 2 固定・updates array 形式)。
• 運用性: open-pull-requests-limit で並行 PR 数を制御し、Merge Queue に一度に 5 件以上が集中しない設計にする。
• 安全性: 未 PR 化 alerts の SLA を「30 日以内に PR 化」に暫定設定し、超過 alerts は撤退条件で拾う。
• 安全性: SOC 2 CC8.1 準拠のため、patch/minor の auto-merge であっても CODEOWNERS による 1 承認を Branch Protection で必須化する (代替として、法務・セキュリティ担当が監査例外として文書化)。
• 安全性: Security Update PR と Version Update PR の同一 dependency 重複起票を解消するため、Security Update PR が open の間は同一 dependency の Version Update PR を自動クローズする GitHub Actions を先行実装する。

3.3 仕様

• 適合性: 4 update 単位 = / (npm root) / /drp (npm) / /tools/rq-eval (npm) / / (github-actions)。
• 適合性: drp / tools/rq-eval の package.json に workspace:* 参照が存在する場合は ignore block で明示除外する (Dependabot が pnpm workspace protocol を npmjs.com への解決と誤解釈してサイレント失敗するのを防ぐ)。
• 運用性: interval は全て weekly · open-pull-requests-limit は root/drp = 5, tools/actions = 3 で PR 洪水を抑える。
• 運用性: schedule.day = 水曜 · schedule.time = 03:00 JST を明示指定し、feature PR の merge が集中する月曜・金曜との衝突を避ける。
• 保守性: label は dependencies (共通) + dep-root / dep-drp / dep-tools / dep-actions (source 分離) の 2 段構成。
• 安全性: security alerts (Security Update) は Version Updates 設定に関係なく自然発火するので、本 ADR で Version Updates を追加しても Security Update の挙動は変えない。

4. 判断基準

4.1 評価軸

K.O. criterion: Must 軸 (安全性) の score < 3 は不採用。

4.2 評価軸 × 案スコア表

5. 検討した代替案

• 案 A (採用): 4 update 単位で weekly 明示登録 — 詳細は §3.1 対策方針 参照。root / drp / tools/rq-eval / github-actions を weekly で登録し、label で source manifest を分離する。
• 案 B (不採用): daily 集約
  • 安全性: 脆弱性 PR 化は最速 (最大 24h 遅延) で weekly より有利。
  • 運用性: 月 PR 数 60-120 件が想定され、Merge Queue の並行 PR 上限 5 件を頻繁に超え、他の feature PR の merge が待ち行列で遅延する。
  • 保守性: PR review が「機械的に auto-merge するだけ」の作業と化し、major bump に対する review 判断が形骸化しやすい。
• 案 C (不採用): dependabot 無効 (現状維持)
  • 安全性: drp/hono 9 alerts のような未 PR 化 alerts が滞留し続けるため K.O. 不通過。
  • 運用性: 手動 pnpm update の運用は過去 4 回中 3 回で一括更新に流れた実測があり、粒度制御が破綻している。
  • 保守性: dependency 更新の履歴が git log でトレースできるが、量が多いため review 時の diff コストが weekly 案より大きい。
• 案 D (不採用): Renovate Bot への切り替え
  • 適合性: pnpm workspace protocol (workspace:*) を Dependabot より正確に解釈するため drp / tools/rq-eval のサイレント失敗リスクを回避できる。
  • 運用性: 設定ファイル (renovate.json) の記述量が Dependabot の 2-3 倍で、初期整備工数 4-8 時間が追加で必要になる。
  • 保守性: Enterprise 化で Dependabot alerts が既に稼働している現状から乗り換えると Security Update / Version Update の統合運用を再設計する必要があり、本 ADR のスコープを超える。workspace:* 参照が実在した場合の fallback 選択肢として §8 撤退条件に留める。

6. 影響

6.1 正の影響

• 安全性: drp/hono 9 alerts を含む未 PR 化案件が weekly cycle 内で PR 化され、7 日以内 PR 化率が > 80% に到達する見込み。
• 運用性: weekly 集約で月 open PR 数 16 件以内 · Merge Queue 並行 5 件以内が実測見込みで、他 feature PR の merge 遅延を最小化できる。
• 保守性: label 分離により、次段 (別 ADR) で dep-actions patch update の auto-approve ルール記述が 30 分以内で書ける状態になる。

6.2 負の影響 / リスク

• 運用性: 月 CI minute 消費が weekly PR × 4 update × 平均 CI 30 分 = 32 分程度増える (現状 月 200 min 前後の内訳)。
• 保守性: major bump PR (semver major) は auto-merge から除外する必要があり、review 判断の運用ルール整備が別途要る (次段 ADR で対応)。
• 安全性: Security Update PR と Version Update PR が同一 dependency に重複起票されると、片方が merge されても最長 7 日間もう片方が Merge Queue に残り続け、pnpm-lock.yaml コンフリクトで CI がブロックされる (§3.2 設計制約で先行実装する GitHub Actions で解消)。
• 適合性: pnpm workspace の workspace:* プロトコルを Dependabot が外部 npm パッケージと誤解釈し、drp / tools/rq-eval の dependency PR がサイレントに起票されないリスクがある (§3.3 の ignore block と §11 の「PR ゼロ検知ジョブ」で対応)。
• 安全性: SOC 2 CC8.1 準拠のため、patch/minor auto-merge でも CODEOWNERS による 1 承認が必須 (§3.2)。承認遅延で PR が滞留する場合は §8 撤退条件で拾う。
• 安全性: SOC 2 / ISO 27001 監査で「脆弱性検出から PR merge までの全履歴」を機械可読な形式で提出する必要があり、GitHub PR 履歴のみでは改ざん不可性を満たさないため、月次 JSON エクスポートを外部ストレージに保存する (§11 実装配線)。

6.3 中立・トレードオフ

• 運用性: weekly PR が水曜 03:00 JST に発火することで feature PR との衝突は最小化されるが、緊急 hotfix と偶発衝突する可能性は残る (§8 撤退条件 5 で対応手順を規定)。
• 保守性: weekly auto-merge を長期運用すると「CI が緑なら安全」という認知バイアスが定着し、transitive dependency の breaking change を見逃すリスクがある。四半期サニティチェック (§9) で対応する。

7. コスト試算

7.1 前提条件

7.2 月コスト試算

年間コスト: CI $3.12 + 実装 3-5 時間 (起案者工数換算 $300-500 = $100/h) + 運用 6h/年 ($600 = $100/h)。

8. 撤退条件

1. open dependency PR > 15 件が 2 週間継続: interval を weekly → biweekly に緩和して再評価。改善しなければ update 単位を root / drp のみに縮退する。
2. 月 CI minute > 60 分 (dependabot 由来): open-pull-requests-limit を root/drp = 3, tools/actions = 2 に絞る。それでも超過なら Security Update のみ有効化して Version Update は撤退する。
3. security alert が 30 日以上未 PR 化 · または Dependabot PR が 10 日間ゼロ: dependabot 側の bug 疑い (workspace protocol 誤解釈含む) で GitHub Support に問い合わせつつ、Renovate Bot への切り替え (案 D) または手動 pnpm update の暫定運用に切り替える。
4. major bump PR が 3 件連続で CI red: 依存の semver 契約側の問題として、当該 dependency の pin 固定 (ignore block) を追加する。
5. 緊急 hotfix 時の Merge Queue 占有: dependency PR が Merge Queue を占有して hotfix が 30 分以上待機する場合、gh pr close で dependency PR を強制退避し、次回 weekly cycle で再起票させる。
6. 撤退時の対応: .github/dependabot.yml を削除する (Version Updates 無効化) · Security Update は自然発火のみに戻す · 本 ADR を Superseded に遷移する。

9. Confirmation

1. 7 日以内 PR 化率 (主指標): security alerts が検出されてから 7 日以内に PR 化される割合。
   • 検証手段: gh api /repos/.../vulnerability-alerts と gh pr list --label dependencies の突合を実装必須スクリプトとして構築 (scripts/dependabot_sla_export.mjs)。結果は JSON で外部ストレージ (S3 または BigQuery) に月次エクスポートし、SOC 2 / ISO 27001 要求の保存期間 1 年以上・改ざん不可 (object lock / versioning 有効化) を満たす。
   • 実行頻度: 月次 (毎月 1 日)。
   • 違反時対応: 3 ヶ月連続で < 80% → §8 撤退条件 3 発動。
2. 月間 open dependency PR 数: 該当 label の open PR 数を月末時点で観測。
   • 目標値: 16 件以内 (中央値 10 件想定)。
   • 違反時対応: 2 週間連続で > 15 件 → §8 撤退条件 1 発動 (interval 緩和)。
3. CI minute 月次消費 (dependabot 由来): GitHub Actions billing の label filter で観測。
   • 目標値: 月 40 分以内 (試算 32 分 + 20% margin)。
   • 違反時対応: 1 ヶ月 > 60 分 → §8 撤退条件 2 発動 (limit 削減)。
4. major bump PR の CI 成功率: major update PR のうち CI green の割合。
   • 目標値: > 80% (semver 契約が守られている実測指標)。
   • 違反時対応: 3 件連続 red → §8 撤退条件 4 発動 (ignore block 追加)。
5. Dependabot PR ゼロ週の検知: workspace protocol 誤解釈によるサイレント失敗を早期検知するため、weekly GitHub Actions ジョブで「直近 7 日間に Dependabot PR が 0 件」を監視し Slack にアラート。
   • 実行頻度: weekly (水曜 04:00 JST · dependabot 発火 1 時間後)。
   • 違反時対応: 10 日連続でゼロ → §8 撤退条件 3 発動。
6. 四半期 diff サニティチェック: 直近 13 週分の dependency PR から無作為 3 件抽出し、transitive dependency の変化を人手 review。認知バイアス (CI green = 安全) の蓄積を検知する。
   • 実行頻度: 四半期 (3 ヶ月毎)。
   • 違反時対応: transitive breaking change を検出した場合、当該 dependency の pin 固定 or 手動 review 対象に格上げ。
7. 検証期間: Review After 2026-10-01 (3 ヶ月後 · weekly cycle 12 回分の実測)。

10. 参照

10.1 関連 ADR

• なし (Dependabot 導入は本 ADR が初出領域)。次段の auto-approve ルール ADR は本 ADR を refined_by で受ける想定。

10.2 関連 PR/Issue

• PR #4055 (feat(dependabot): .github/dependabot.yml 新設 · 4 update · weekly · 2026-07-03 merged)
• 発注 handover: tasks/prompts/archive/handover_2026-07-03_dependabot-yml-missing-plus-followup-detect-newissue-bug_to_main.md §2

10.3 外部資料

• Dependabot 公式 docs (https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file)
• Dependabot v2 schema 定義 (Enterprise 化以後の canonical 形式)
• dependabot/dependabot-core #2078 (pnpm workspace protocol 誤解釈の既知 issue)
• SOC 2 Trust Services Criteria CC7.1 / CC8.1 (脆弱性対応の証跡・変更管理承認要件)

11. 実装配線

• lint 配線: yaml syntax は python3 yaml.safe_load で確認済 (PR #4055 test plan)。追加で .github/workflows/dependabot-config-lint.yml (新規) を検討し、dependabot.yml の schema 検証を CI に組み込む (別 issue 起票)。
• 起案フロー配線: 本 ADR は既 shipped の設定に対する遡及起案。次段の auto-approve ルール ADR で .github/workflows/dependabot-auto-merge.yml を新規追加する予定 (refined_by で本 ADR を受ける形)。先行実装として .github/workflows/dependabot-dup-close.yml (Security/Version 重複 PR の自動クローズ) · .github/workflows/dependabot-zero-pr-alert.yml (10 日連続 PR ゼロで Slack アラート) · scripts/dependabot_sla_export.mjs (月次 SLA JSON エクスポート → S3/BigQuery) を本 ADR 受理後 2 週間以内に追加する。
• docs SSoT 同期: docs/_internal/05_how-to/dependency_management.md (新設) に本 ADR の運用ルール (weekly cycle · label 分離 · 撤退条件 SLA · 四半期サニティチェック手順) を記載する。既存 docs/_internal/05_how-to/git_workflow.md に「Dependabot PR の review 判断 (major bump 除外 · CODEOWNERS 1 承認必須)」節を追記する。SOC 2 / ISO 27001 監査証跡の保存先・保存期間 (1 年以上) · 改ざん不可要件を docs/_internal/07_compliance/audit_evidence.md (新設 or 既存に追記) に明記する。