バージョンアップでビルドが通らなくなった画面を前に、どこから手をつけるか考えている開発者

AIコーディング作成2026-08-17 01:05約15分

AIにライブラリのバージョンアップを任せる｜破壊的変更の追い方

セキュリティの警告が出たので、ライブラリのバージョンを上げた。

それだけのつもりだったのに、ビルドが真っ赤になる。エラーの数が二桁を超えたあたりで、そっとバージョンを戻したくなる。あの気持ち、たぶん一度は通ってきていると思います。

ここでAIに丸ごと投げると、確かに直ります。エラーは消えて、ビルドは通る。ただ、それが「正しい直し方」かどうかは、また別の話です。AIが知っているのは少し前のバージョンで、しかもAIは「エラーを消す」ことにはとても熱心だからです。

この記事では、AIに手伝ってもらいながら、あとで泣かない進め方を整理します。

結論：バージョンアップをAIと進めるなら、順番は3つです。①選ぶ——公式の変更ログ（changelog）と移行ガイドを実際に渡し、その中から自分たちのコードに効く破壊的変更だけを抜き出させる。②1つずつ——複数のライブラリをまとめて上げない。1つ上げて、通して、コミットする。③確かめる——ビルドが通ったことと、挙動が同じことは別物なので、変わりやすい箇所を人の目で見る。

覚え方は 選ぶ → 1つずつ → 確かめる。AIに最初から「直して」と頼まないのが、いちばんの分かれ目です。

全部を今日やる必要はありません。①の「変更ログを渡してから聞く」だけでも、返ってくる答えの質はかなり変わります。

何が起きているのか——AIは「直す」のは得意で、「上げる」のは苦手

冊子に付箋を数枚だけ貼る場面、並んだ部品のうち1つだけを新しいものに交換する場面、動いた機械を見て確認表に印をつける場面を並べた図 — バージョンアップは「選ぶ・1つずつ・確かめる」の順で進める。まとめて上げないのが手戻りを防ぐ

バージョンアップでAIが空回りするのには、はっきりした理由があります。あなたの使い方が悪いわけではありません。

1つ目は、AIの知識が少し前で止まっていること。学習した時点より後に出たバージョンの仕様は、そもそも知りません。それでも聞けば答えてくれるので、古い書き方をそのまま「新しい書き方」として提案してくることがあります。バージョンアップは、AIの弱点をいちばん踏みやすい作業だと言えます（AIの知識は少し前で止まる｜古い情報で最新仕様を扱う注意点）。

2つ目は、AIが「エラーを消す」方向に強く引っ張られること。目の前のエラーが消える書き方を探すのが仕事なので、型をanyに緩める、tryで囲んで握りつぶす、非推奨の互換オプションを足す——といった手が普通に出てきます。ビルドは通ります。でも問題は先送りされただけ、ということも起こります（AIに型エラーを直させるとanyが増える｜安全な直し方の型）。

3つ目は、壊れ方が静かなこと。破壊的変更には、コンパイルエラーになって教えてくれる親切なものと、何も言わずに挙動だけ変わるものがあります。既定値が変わった、日付の扱いが変わった、エラー時に例外を投げていたのがnullを返すようになった。こういう変更は、ビルドが通ってしまうぶん厄介です。

4つ目は、範囲が読めないこと。1つのライブラリを上げると、その先の依存も一緒に動きます。「小さな更新のつもりが、気づけば数十ファイルの差分になっていた」は、AIに任せたときに特に起きやすい形です。差分が膨らむと、レビューできる人が誰もいなくなります（AIに複数ファイルの変更を任せる｜差分を見失わない追い方）。

裏を返すと、AIがとても役に立つ場所もはっきりしています。長い変更ログを読んで、自分たちに関係のある行だけ拾い上げる作業です。ここは根気がいるわりに退屈で、しかもAIの得意分野です。

具体例——ビルドが通っても、静かに変わっているところ

実際に上げたあと、抜けやすいのはこのあたりです。心当たりのある行があれば、そこだけ見に行くだけでも十分価値があります。

既定値（デフォルト）の変更：タイムアウトの秒数、リトライ回数、文字コード、丸め方。書いていない設定ほど、上げた瞬間に変わります。明示的に書いていた設定より、書かずに任せていた設定のほうが危ないという、少し意地悪な性質があります。
エラーの返し方の変更：例外を投げていたものがnullや空配列を返すようになる（またはその逆）。呼び出し側の分岐が、静かにすり抜けます。
日付・タイムゾーンの扱い：解釈の基準がUTCとローカルの間で変わる、あいまいな書式の解釈が厳しくなる。ズレは数時間なので、テストデータによっては気づけません。
数値・小数の丸め：金額計算に関わると影響が大きい場所です。合計が1円ずれる形で出てくることがあります。
非推奨（deprecated）から削除への移行：前のバージョンで「警告」だったものが、今回で「削除」になる。警告を見送っていた期間が長いほど、まとめて効いてきます。
設定ファイルの書き方の変更：コードは変えなくても、設定の項目名や階層が変わる。動かないのに、コードのほうばかり探してしまいがちです。
要求される実行環境の引き上げ：言語やランタイムの最低バージョンが上がっているケース。ローカルでは動いて、本番のサーバーで動かない、という形で出ます。

そして、いちばん気をつけたいのがAIが挙げてくる「移行方法」そのものです。存在しない関数名や、実際には別のライブラリの書き方が混ざることがあります。新しく出てきたAPI名は、必ず公式ドキュメントで実在を確認してください。ここは検索一回で済む確認です（AIのハルシネーションの見抜き方｜開発現場で気づく型）。

影響——つらいのは作業量ではなく、「戻れなくなること」

バージョンアップが重い作業になるのは、手数が多いからではありません。戻る場所を失うからです。

差分が大きすぎてレビューできない：まとめて上げると、他人がレビューできない大きさになります。結果、「動いたからマージ」になり、後から誰も経緯を説明できません。
障害が起きたとき、原因の切り分けができない：3つのライブラリを同時に上げて翌週に不具合が出ると、どれが原因か分かりません。1つずつ上げていれば、コミットを1つ戻すだけで済んだはずのものです。
直したのか、隠したのか分からなくなる：AIの提案で通したエラーが「正しく移行した」のか「握りつぶした」のか、時間が経つと本人にも判別できなくなります。
次のバージョンアップが、もっと怖くなる：一度つらい思いをすると、次は先送りしたくなります。そして先送りするほど、差は開いて、上げるのが難しくなります。

ここは、少しだけ希望のある話でもあります。この「戻れなくなる」問題は、技術力ではなく進め方で防げます。上げる単位を小さくして、その都度コミットする。それだけで、最悪の事態は「1つ戻す」に収まります。今日から変えられる部分です。

明日からやること（選ぶ・1つずつ・確かめる）

上から順に、小さく始められます。今日は①だけで構いません。

1. 選ぶ——変更ログを「渡してから」聞く

いきなり「このライブラリを最新に上げて」と頼まないでください。最初にやるのは、公式の変更ログと移行ガイドを手に入れて、AIに実際に読ませることです。記憶で答えさせない、というのがここでの目的です。

次に貼るのは、あるライブラリの公式の変更ログ（と移行ガイド）です。ここに書かれている内容だけを根拠に答えてください。書かれていないことは「記載なし」と書き、推測で補わないでください。

①現在のバージョンから目標のバージョンまでの間にある破壊的変更を、すべて箇条書きにしてください。
②そのうち、下に貼る私たちのコードの使い方に関係するものだけを選び直し、影響を受けそうな箇所を挙げてください。
③ビルドエラーにならず、挙動だけ静かに変わるものには印をつけてください。

現在のバージョン：（　）　目標のバージョン：（　）
変更ログ：（ここに貼る）
私たちの使い方：（そのライブラリを呼んでいる箇所を、代表的なものだけ数か所）

ポイントは③です。「ビルドが教えてくれない変更」を先に洗い出しておくと、あとの確認がぐっと楽になります。ここで出てきたリストが、そのまま③の確認項目になります。

なお、社外に出せないコードを丸ごと貼る必要はありません。呼び出し方が分かる範囲に絞れば十分です。

2. 1つずつ——上げる単位を小さくして、都度コミットする

複数のライブラリをまとめて上げたくなりますが、ここは我慢のしどころです。

1つ上げる → ビルドとテストを通す → コミットする。この3点セットを崩さない。
メジャーバージョンを飛ばさない。2つ先へ一気に上げるより、間を経由したほうが、公式の移行ガイドがそのまま使えます。遠回りに見えて速い道です。
「AIが直したところ」と「自分が直したところ」を混ぜない。分けてコミットしておくと、後から見返すときに助かります。
非推奨の警告は、消さずに一度読む。今回の警告が、次回の破壊的変更の予告です。仕分けの仕方はAIに静的解析・Lintの警告を仕分けさせる｜優先度のつけ方が使えます。

エラーを直させるときも、頼み方を少し変えるだけで結果が変わります。

次のエラーは、ライブラリを（　）から（　）へ上げたことで出たものです。

エラーを消すことより、新しいバージョンでの正しい書き方に直すことを優先してください。修正案は2つ出し、それぞれについて次を書いてください。
・変更ログのどの項目に対応する修正か
・その書き方で、元と同じ挙動になるか／変わるとしたら何が変わるか
・型を緩める・例外を握りつぶすなど、問題を先送りしている部分があればその旨

なお、確実でない部分は「不明」と書いてください。埋めなくて構いません。

「2つ出して」と頼むのが効きます。案が1つだと、それが唯一の正解に見えてしまうからです。修正ループが長引き始めたら、いったん手を止める判断も持っておいてください（AIとの修正ループが終わらない｜堂々巡りから抜ける手順）。

3. 確かめる——ビルドが通ったことは、まだゴールではない

ここが、いちばん省略されやすくて、いちばん効く工程です。

まず、既存のテストを先に流します。バージョンを上げる前の状態で全部通ることを確認してから上げる、という順番にすると、落ちたテストが「上げたせい」だと確実に言えます（AIに直させてもリグレッションを出さない既存テストの渡し方）。

そのうえで、①で「静かに変わる」と印をつけた箇所を、人の目で見ます。ここはAIに任せられません。

日付・時刻の表示が、上げる前と同じか（1件でいいので実際に動かす）
金額・数量の合計が、上げる前と同じか
エラーになる操作をわざとして、同じエラー画面が出るか
設定を書いていない箇所が、意図した既定値で動いているか

そして、差分を上から下まで一度は読んでください。AIが「ついでに」直した無関係な箇所が混ざっていることがあります。読む順番のコツはAIリファクタリングの差分レビュー｜壊さず確認する手順にまとめています。動作確認の型そのものはAI生成コードの動作確認｜そのまま使わない最低限の型が、そのまま流用できます。

最後に、上げた記録を1行残します。「いつ、何を、どこからどこへ、なぜ上げたか」。次に触る人（半年後の自分を含みます）が、この1行にかなり助けられます。

バージョンアップ確認チェックリスト（コピーして使えます）

上から順に見ていくためのリストです。全部に○が要るわけではありません。気になった行だけで十分です。

① 選ぶ（着手前）

公式の変更ログ・移行ガイドを実際に開いて手元に用意したか
AIに記憶で答えさせず、変更ログを貼って答えさせたか
破壊的変更のうち、自分たちのコードに効くものだけを絞り込んだか
「ビルドエラーにならず挙動だけ変わる」項目に印をつけたか
AIが挙げた新しい関数名・オプション名を公式ドキュメントで実在確認したか
要求される言語・ランタイムの最低バージョンを確認したか

② 1つずつ（作業中）

上げるライブラリを1つに絞ったか
メジャーバージョンを飛ばさず、間を経由しているか
ビルドとテストが通るたびにコミットしているか
エラーを「消した」のか「正しく移行した」のか、自分で説明できるか
any・例外の握りつぶし・互換オプションで先送りしていないか
非推奨の警告を、消す前に一度読んだか
差分が大きくなりすぎていないか（レビューできる量か）

③ 確かめる（マージ前）

上げる前に既存テストが全部通ることを確認していたか
日付・時刻の扱いが、上げる前と同じか実際に動かして見たか
金額・数量の計算結果が、上げる前と同じか確かめたか
エラー時の挙動（例外か、nullか）が変わっていないか
設定を書いていない箇所の既定値を確認したか
差分を上から下まで一度読み、無関係な変更が混ざっていないか見たか
いつ・何を・どこからどこへ・なぜ上げたかを1行残したか

この記事のまとめ

ライブラリのバージョンアップは、AIに丸投げすると事故りやすく、AIを使わないと骨が折れる——ちょうど間にある作業です。

やることは3つ。①選ぶ——変更ログを渡してから、自分たちに効く破壊的変更だけを抜き出させる。とくに「ビルドが教えてくれない変更」に印をつける。②1つずつ——まとめて上げず、1つ上げて通してコミットする。③確かめる——ビルドが通ったことと挙動が同じことは別なので、印をつけた箇所を人の目で見る。

この3つを守ると、最悪の事態が「コミットを1つ戻す」に収まります。それだけで、バージョンアップはずいぶん怖くない作業になります。