ホーム自己紹介ブログ
NO.418
DATE2026. 07. 24

モジュールアップデートでやっていること

ITヲタクな AI くんにピッタリな仕事の一つは、モジュールアップデート。
特に、メジャーアップデートが超助かる。
昔だったら 数ヶ月掛かった移行も、数日たらずに対応できるようになったので、
さすが ITヲタクくん。
対応してよかったフローについて、書き留めておきます。

前提

私の場合は、 npm のメジャーアップデートをここ1ヶ月ぐらいやっていました。
複数のWebフレームワークや、静的解析ツール、APIクライアントツール、モノレポツールなど、
メジャーアップデートを放置していたものを掘り起こして対応していました。
メジャーアップデートって、キラキラしてワクワクするんですけど、
移行と思うと 少しヘビーなんですよね...。

受け入れる仕組みを整える

一番は、安心安全にメジャーアップデートした内容を受け入れる仕組みを整えることです。
型検査、静的解析(種々様々な強固なもの)、テスト、ビルド、その他 機械的にチェックできるモノ全てです。

この中にあるテストは、主に単体テストや結合テストが一般的にですが、
私の場合は、 Testcontainers + Playwright + Cucumber による受け入れテストを CI 上で動かせる準備を整えています。
これはWebフレームワークやAPIクライアントなど、End to End な確認作業のときに大変重宝しました。

Web UI に関わるCSSフレームワークなどのメジャーアップデートの場合は、
Vitest + Browser Mode による VRT が実現できるため、デザイン崩れを検知できます。

少し古いですが、以下の記事にあるような網羅的にテストをカバーできていると安心です。

Webフロントエンドにおける網羅的テストパターンガイド

こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか?ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか?また、カオスエンジニアリングテストやアクセシビリティテストはありますか?

ジブンノート

※ もう3年前の記事なのでした...

この受け入れる仕組みがあれば、かなり安心してリリースできます。
もちろん手動確認は必須ですが、その前段階での 確認網羅が広いと作業工数が減って作業ミスも減って 、良きです。

マイグレーションガイドを共に読む

AI には、メジャーアップデートによるマイグレーションガイドを必ず読ませます。
トリッキーなことをさせずに、推奨方針で進めさせる方が、もしもの時のトラブルショート がやりやすいからです。
イシューがすでに起票されていたり、誰かが記事を書いていたりするかもだからです。

ただ、私もマイグレーションガイドを最後まで一読します。
AI の成果物の良し悪しのジャッジするためと、
デフォルトの挙動が変わらないかなどはみています。
まあ、結局のところ 成果物を見ても "わからない" となってしまうから 読むだけです。笑

試作と破棄

一旦 AI にマイグレーションガイドに沿って、
変更行数・変更ファイル数など無視して、
マイグレーションを完成させるところを目指します。
ゴールは、先ほどの受け入れ仕組みが通ることです。

試作して気づくことは多く、
プロダクト固有の問題や他のライブラリの依存関係で困ることなど、
机上の空論では気付けないことが多くあります。

とにかく受け入れを通せる状態まで来たら、
その修正(PullRequest)を捨てます。

その後、修正内容について分類し、メジャーアップデート前の準備できることを、
細かく分けて PullRequestを建ててリリースすると、ビッグバンリリースではなくなります。

これはレビュワーにとってありがたいことで、
そういう負担軽減にもつながります。

使い捨て冪等マイグレーションスクリプト

特に大規模な変更の場合、マイグレーションに時間がかかることがあります。
AI のトークンが勿体ないです。
そんなときは、使い捨てのマイグレーションスクリプトを AI に書かせます。
AST 解析させてコードを修正するスクリプトを書かせて、
そのスクリプトを実行することで、冪等に同じ結果になるようにします。

冪等が大事 で、実行するたびに結果が変わるとその内容を微調整しないといけなくなるため、
冪等で結果が変わらないようにすると、確認作業が楽です。

私の場合は、mjsファイルを沢山作らせてとnpm scriptで直列に実行するコマンドを追加します。
あとはそのコマンドを実行するだけで、マイグレーションが完成するようにします。

AI がない場合はこういうのを作らせるのって結構大変だったので、
ありがたい限りです。

終わりに

マイグレーションガイドを丁寧に公開してくださる OSSメンテナの皆さん、
いつもありがとうございます。

AI
フロントエンド

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア
個人ブログキュレーション こぶりー 運営

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

前の記事へ

関連する記事

タグ「AI」の記事

人が読む見る箇所は、人の手がここちよい

この記事をかくときは、100%人の手で書いています。 UIをつくるときも、100%人の手で書いています。 (ロジックは AI に書かせます) 他にはプレゼンテーションやスライドといった書き物も、 コンテンツ準備は AI にさせますが、文章を

2026年06月28日

仕事
AI
写経テストコードを全部消した

以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi

2026年06月08日

AI
フロントエンド
テスト
念の為に、手動確認をしよう

最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修

2026年06月03日

AI
フロントエンド

タグ「フロントエンド」の記事

写経テストコードを全部消した

以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi

2026年06月08日

AI
フロントエンド
テスト
念の為に、手動確認をしよう

最近のお悩みは、Webのソフトウェア開発におけるテストコードが爆増したことにより、 テスト成功による過度な安心感 によって手動確認するのが減っているのかもと思ったりしています。 例えば、Webのフォーム画面に小さな改修があったとして、その修

2026年06月03日

AI
フロントエンド
モバイルアプリからPWAアプリへ切り替え

以下で書いた個人ブログを読むアプリ(個人ブログライブラリ、略して "こぶりー" )をモバイルアプリで開発していました。 https://silverbirder.github.io/blog/contents/20260419/ 審査関連で

2026年05月11日

フロントエンド
← ブログ一覧へ