LCL Engineers' Blog

バス比較なび・格安移動・バスとりっぷを運営する LCLの開発者ブログ

Claude Codeと作った依存関係の自動更新パイプライン

こんにちは。SREチームでインフラエンジニアをしております小林(@kasei_san)です。

格安移動（idou.me）の依存関係の更新PRが常に残件を抱えている状態でした。自動化したくてもテスト基盤がなく、「壊れていないこと」を保証できないのが課題でした。

この記事では、テスト基盤の構築から始めて、PATCHバージョン更新を全自動で安全にマージ・デプロイする仕組みをClaude Codeと対話しながら構築した話を紹介します。最終的には、Webサービスは画面差分テスト（VRT）付き、管理画面はスモークテスト→本番デプロイまで全自動、バッチはCI＋監視で即デプロイ、という3リポジトリそれぞれに合った自動化を実現しました。

背景: 依存関係の更新の運用コスト

格安移動は3つのリポジトリで構成されています。

リポジトリ 役割 技術スタック
Webサービス 検索・比較サイト本体 Rails + React
管理画面 マスターデータ管理 Rails
バッチ クロール・データ集計 Rails

Dependabotは設定済みで、PRは自動で作られていました。運用としては：

  • 担当者を決めて 週1でissueを作成
  • 対象PRを目視チェック → 問題なさそうならマージ

週5件ペースで消化していましたが、新しいPRも同じペースで作られるため、常に残件がある状態でした。チェック自体も実態は rubber stamping（形骸化したレビュー）で、PRの中身を詳しく見る余裕はなく「CIが通っているし大丈夫だろう」でマージしていました。

問題は自動化したくてもできなかったことです。CIにビルドチェックすらなく、テストスイートもなし。自動マージしても「壊れていないこと」を保証する仕組みがありませんでした。

自動化方針をどう決めたか

Claude Codeに現状を説明し、どうすればいいか相談しました。出てきた選択肢を議論して、以下の4つの設計原則に落ち着きました。

  1. PATCHのみ自動化する — MINOR/MAJORは破壊的変更のリスクがあるため人間が判断
  2. リポジトリごとに検証の厚さを変える — 収益サービスは厚く、バッチは軽く
  3. テスト・観測・即停止可能性で守る — PATCHバージョンでも壊れることは普通にある。安全性はバージョン番号ではなくガードレールで担保する
  4. 段階的に導入する — devDepsから始めて、テスト基盤を作ってから本番depsに拡大

devDepsの自動マージから始め、テスト基盤を作り、動作確認してから本番depsに拡大する段階的アプローチを取りました。

なぜRenovateを選んだか

この方針を実現するツールとして、DependabotからRenovateに切り替えました。

決め手は packageRules の柔軟性です。「devDepsのPATCHだけ自動マージ」「本番depsは14日待ってからPATCHのみ」「セキュリティ修正は3日に短縮」といった細かい条件分岐を、1つの設定ファイルで宣言的に記述できます。Dependabotでも自動マージは実現できますが、GitHub Actionsで条件分岐を自前実装する必要があり、メンテナンスコストが上がります。

加えて、3リポジトリ横断で同じ設計思想の設定を展開するにあたって、統一的な制御ができる点も大きな利点でした。

観点 Dependabot Renovate
自動マージの条件制御 GitHub Actionsで自前実装 packageRules で宣言的に記述
グルーピング 基本的な機能のみ 正規表現で柔軟に制御
minimumReleaseAge なし あり
マルチリポジトリ統一管理 リポジトリごとに個別設定 同じpackageRulesを展開可能

完成した仕組み

まず全体像です。3リポジトリ共通でPATCH更新はPR作成→CI（ビルドチェック・依存関係のインストール確認）→条件付き自動マージまで進め、マージ後の検証とデプロイはサービス特性ごとに変えています。

全体フロー

リポジトリごとの実装差分

Webサービス: 収益サービスなので最も厚く守る

Webサービスのフロー

  • VRT（Visual Regression Testing）: QA環境を自動構築し、Stage環境と画面をピクセル単位で比較。差分があれば自動マージしない
  • スモークテスト: デプロイ後に主要ページのHTTPステータス・キーワード・レスポンスタイムを検証
  • Error Rate監視: 本番デプロイ後のALB 5xxエラー率をAthenaで自動チェック。現状は5xxのみで、レイテンシや主要業務指標まではカバーできておらず今後の改善ポイント

管理画面: 利用者限定なので、ステージ確認後に本番まで自動化

管理画面のフロー

QA環境がないため、masterマージ後のステージスモークテストで検証しています。スモークテストが通れば自動でタグ作成→本番デプロイまで進みます。

  • スモークテスト: ログイン画面の表示・ログイン実行・検索機能の動作をcurlベースで確認
  • ロールバック: 本番デプロイ失敗時はSlackに前回タグでの手動ロールバック手順を通知。自動ロールバックは行わない（利用者限定のため手動対応で十分と判断）

バッチ: 影響範囲が限定的なので、CI + 監視で割り切る

バッチのフロー

masterマージでJenkinsが即座に本番デプロイするシンプルな構成です。

  • Rails Bootチェック: アプリケーションが正常に起動するかをCIで確認。通れば自動マージ
  • slackアラート: ジョブ実行時のエラーを即座に検知。Rails Bootだけでは拾えない実行時エラー（外部APIクライアントの挙動変化等）をカバー

安全性の設計

自動マージの前提はガードレールです。「PATCHだから安全」ではなく、複数の検証層で守っています。

自動マージ条件

種類 minimumReleaseAge 自動マージ条件
devDeps PATCH 3日 CI green
本番deps PATCH 14日 CI green（+ WebサービスはVRT green）
セキュリティ PATCH 3日 CI green（+ WebサービスはVRT green）
MINOR - 自動マージしない
MAJOR - 自動マージしない

Kill Switch

何か問題が起きたときは renovate.json の automerge: true を false に変更してマージするだけで、即座に自動マージを停止できます。

minimumReleaseAge: 公開直後のリスク緩和

Renovateの minimumReleaseAge は「パッケージが公開されてからN日間は取り込まない」という設定です。eslint-config-prettier事件（2024年、汚染バージョンが約2時間で撤回）のような公開直後の不正・事故リリースに対する緩和策として機能します。

注意: これは公開直後の事故・撤回に対する緩和策であり、XZ Utilsのような長期間潜伏する攻撃やtypo-squattingには効きません。あくまで多層防御の一要素です。

セキュリティ更新の例外運用

セキュリティPATCHの minimumReleaseAge: 3日 はトレードオフがあります。脆弱性の深刻度によっては、待つこと自体がリスクです。

  • 原則: 3日待って自動マージ
  • 例外: CVSSスコアが高い脆弱性やactive exploitationが報告されている場合は手動で即時対応
  • Renovateが作成するPRの [SECURITY] ラベルとSecurity Advisoryの内容は、自動マージ前でも確認可能

Slack通知と週次レポート

すべての自動マージ・自動リリースの結果はSlackチャンネルに通知されます。成功時も失敗時も通知が来るので、何が起きたか常に把握できます。

加えて、毎週水曜日に3リポジトリ横断の週次メンテナンスissueがGitHub Actionsで自動生成されます。自動マージされたPR、手動マージされたPR、未マージのオープンPR（MINOR/MAJORなど）が一覧化されるので、週1でチェックすることでMINOR/MAJORの対応漏れを防いでいます。

週次メンテナンスissue

今後の展望

MINOR/MAJORのPRは現在人間がレビューしていますが、LLMを活用してchangelog要約・影響調査の優先順位付け・修正差分の自動生成まで任せることで、週次チェックの負荷を大幅に下げたいと考えています。また、同じチームで運用している他サービス群への横展開も進めています。

まとめ

Dependabotの未マージPRを、Renovate + 自動テスト + 自動マージで全自動化しました。

  • 「人間がレビューしてマージ」の形骸化問題を 機械的ガードレール で解決
  • PATCHに限定し、テスト・観測・即停止可能性 で安全性を担保
  • 3リポジトリそれぞれの特性に合わせた検証手段（VRT / スモークテスト / CI）を構築

この仕組みの構築では、Claude Codeを「業務パートナー」として自律的に動かせる環境が大きく効きました。戦略の相談、Renovate設定の試行錯誤、GitHub Actionsワークフローの実装、エラーの原因調査と修正PR作成 ── これらの作業の大部分をClaude Codeが担い、人間は方針判断とマージ操作に集中できました。Claude Codeを自律的に動かすための仕組みについては、以前のブログ記事で紹介しています。

依存関係の更新は、退屈な作業の典型です。退屈な作業は後回しになり、後回しになったPRはセキュリティリスクになります。全部自動化するのではなく、検証可能な範囲だけ自動化し、人間は判断が必要な更新に集中する。この考え方が、同じ課題を抱えるチームの参考になれば幸いです。