Claude Codeを利用してライブラリアップデート対応を爆速にした話

READYFOR プロダクトエンジニアの森です。

Claude Code が利用できるようになってから AI 利用についてちゃんと向き合い始めたこともあり Claude Code を使うことが多いのですが、GitHub 上で Copilot の進化を見つけて試すことが最近の楽しみになりつつあります。

社内でも AI 利用を進めているなか、普段のライブラリアップデート対応をする際に Claude Code を利用するようにしてみました。

その結果、ライブラリアップデート対応のマージ件数が月間で約2倍に増えるという明確な効果が得られました。

フロントエンドリポジトリにて、dependabot/renovateが作成したPull Requestのうち自身がマージした件数を月別に集計。2025年10月の数値は10/28時点の値

背景：ライブラリアップデートのボトルネック

しばらくバックエンドをメインにしていたのですが、ゆるゆるとフロントエンド領域に足を伸ばし、昨年ごろからライブラリのアップデートもいくつか対応するようになりました。

しかし普段触っていないリポジトリもありどこに影響するか把握できていないライブラリが多く、影響範囲や変更内容の確認に時間がかかってしまい、1日に 1-2 件確認を終えるのが精一杯という状況が続いていたため、Claude Code の活用を考えました。

改善案：カスタムコマンドで調査を自動化

普段の大まかな流れは下記の通りです。
ここでは dependabot もしくは renovate が作成する Pull Request を対象としています。

改善前（Before）：

1. 対象の Pull Request を確認（主に File Changes と Pull Request の本文）
2. アップデート・追加・削除されたライブラリの依存関係やリリースノート、関連コミットを確認
3. 影響範囲の確認
4. 必要に応じて修正
5. 動作確認
6. リリース

主に 1〜4 の過程に時間がかかっている状況だったため、主に調査・確認系を Claude Code に依頼するよう変更しました。

改善後（After）：

1. 対象の Pull Request を確認
2. Claude Code へ調査依頼を出す（影響範囲とアップデート内容をまとめてもらう）
3. 出力内容を参考に影響範囲やアップデート内容を確認
4. 必要に応じて修正（内容によっては修正も Claude Code や Copilot に依頼）
5. 動作確認
6. リリース

調査や確認を依頼する際、最初の方は Claude Code へ下記の指示をしていました。

[ライブラリ名]を[現在のバージョン]から[アップデート後のバージョン]へアップデートするにあたり、影響範囲と変更内容をまとめて
参考：[アップデートするライブラリのリポジトリリンク]

これでも十分ではあるのですが、毎度[xxx]にあたる部分を Pull Request からコピペしてくる手間がかかっています。

この手間を省くため、どうせ Pull Request からコピペしてくるならと、Pull Request のリンクを渡して良い感じにまとめるカスタムコマンドを作りました。

Pull Request の番号もしくは URL を指定すると、以下を実行します。

1. 該当 Pull Request の本文、変更内容を取得
2. 差分から変更のあったライブラリの特定
3. アップデートされたライブラリのリポジトリからリリース情報等を取得し、サマリを作成
4. 既存コードの影響範囲を分析
5. 結果の出力

▼ カスタムコマンドサンプル

# ライブラリアップデート影響範囲チェック

PRからライブラリのアップデート内容を確認し、影響範囲とアップデート内容のサマリを出力します。

## 使用方法

/check-update-lib <PR番号またはPR URL>

例：
/check-update-lib 123
/check-update-lib https://github.com/org/repo/pull/123

## 実行手順

### 0. 前提条件
- 現在のディレクトリのリポジトリに関連するPRを指定
- バージョン確認、依存関係確認、実装確認は全てコマンド実行箇所のディレクトリ配下のファイルを参照
- ghコマンドが認証済みであること

### 1. PR情報の取得
- `gh pr view`コマンドでPR情報を取得
  - PR番号またはURLから番号を抽出
  - PRのbody（description）を取得
  - PRのファイル一覧を取得

### 2. package.json/package-lock.json差分の解析
- `gh pr diff <PR番号> -- package.json package-lock.json`で両ファイルの差分を取得
- **package.json差分**から：
  - アップデート対象のライブラリ名を特定
  - dependencies/devDependenciesの区別を確認
- **package-lock.json差分**から：
  - 実際にインストールされる正確なバージョン（before/after）を抽出
  - 間接的な依存関係の変更も確認
  - ライブラリのresolved URLとintegrity情報を確認
- 複数のライブラリが更新されている場合は全て抽出

### 3. ライブラリのGitHubリポジトリ確認
- PRのdescriptionからGitHubリポジトリのリンクを抽出
  - `https://github.com/[owner]/[repo]`形式のリンクを検索
  - リンクが見つからない場合は`npm view <package-name> repository.url`で取得
- 各ライブラリのリポジトリURLをリスト化

### 4. ライブラリの変更内容確認
- WebFetchツールで各ライブラリのリリース情報を取得
  - `https://github.com/[owner]/[repo]/releases`からリリースノートを確認
  - 該当バージョンのリリースノートを抽出
  - リリースノートがない場合は`CHANGELOG.md`も確認
- 変更内容のサマリを作成：
  - 破壊的変更（Breaking Changes）
  - 新機能（Features）
  - バグ修正（Bug Fixes）
  - その他の変更

### 5. 既存コードの影響範囲分析
- 各ライブラリについて、Grepツールで使用箇所を検索
  - import/require文の検索
  - TypeScript型定義での使用状況
  - 設定ファイル（vite.config.ts, tsconfig.json等）での参照
- 影響を受けるファイルのリストを作成
- 各ファイルでの使用方法を簡単に説明

### 6. バージョン差分分析
- セマンティックバージョニングに基づく分類
  - メジャー（x.y.z → x+1.0.0）：破壊的変更の可能性が高い
  - マイナー（x.y.z → x.y+1.z）：後方互換性のある新機能
  - パッチ（x.y.z → x.y.z+1）：後方互換性のあるバグ修正

### 7. 結果の出力
以下の形式でまとめて出力：

# ライブラリアップデート影響範囲レポート

## PR情報
- PR番号: #xxx
- タイトル: [PRタイトル]

## アップデート対象ライブラリ

### [ライブラリ名]
- バージョン変更: x.y.z → a.b.c
- 変更タイプ: [Major/Minor/Patch]
- リポジトリ: [GitHub URL]

#### 主な変更内容
- [変更内容のサマリ]

#### 影響範囲
- 影響ファイル数: n件
- 主な影響ファイル:
  - `path/to/file1.ts`: [使用方法の説明]
  - `path/to/file2.ts`: [使用方法の説明]

#### リスク評価
- リスクレベル: [低/中/高]
- 理由: [評価理由]

## 推奨アクション
- [ ] [チェック項目1]
- [ ] [チェック項目2]
- [ ] [テスト項目]

### 8. エラーハンドリング
- PRが見つからない場合は明確なエラーメッセージを表示
- package.jsonに変更がない場合はその旨を通知
- GitHub APIの制限に達した場合の対処方法を提示
- ライブラリのリポジトリが見つからない場合は、手動確認を促す

結果

この方法に変えて以降、Pull Request 1件にかける時間が少なくなり、並列で進めやすくなったことで、1日に対応できる Pull Request の数が増えたことで、1ヶ月あたりのマージ数が倍以上になりました。

やろうと思えば全自動化も可能だと思うのですが、個人的に（特に production で動くものは）まだ全て AI にお任せというのは若干の不安が残るので、現時点での自分に合う距離感としてはこんなところかなと感じています。

まとめ

ライブラリアップデートは、地味ながらも継続的な開発に欠かせないメンテナンス作業です。
一方で、特に慣れないコードでは思いのほか時間を取られやすい領域でもあります。

今回、Pull Request を起点にライブラリアップデートの調査や確認を部分的に自動化したことで、対応コストを下げつつ、より重要な判断や検証の方へ集中できるようになりました。

結果として、1件あたりの対応時間が短縮され、1ヶ月あたりのマージ件数が倍以上に増えるという分かりやすい効果も得られました。

もちろん、完全自動化も技術的には可能ですが、現時点では「AI が調査・整理」「人が判断・確認」という分担が自分自身にはちょうど良いバランスだと感じています。

今後も調査結果の信頼性や精度をもう少し高めつつ、他の定常作業への展開など、活用方法を探っていきたいと思います。