【IT用語】破壊的変更とは？プログラミングでよく聞く言葉をわかりやすく解説！

ITやプログラミングの情報を調べていると、「今回のアップデートには破壊的変更が含まれます」という説明を見かけることがあります。

この記事では「破壊的変更」について、以下の内容をわかりやすく説明します。

• 破壊的変更の意味
• 破壊的変更の具体例
• 非破壊的変更との違い
• 更新前に確認するポイント

破壊的変更とは？

破壊的変更とは、ソフトウェアやAPI、ライブラリなどをバージョンアップしたときに、これまでの使い方やコードがそのままでは使えなくなり、新しい仕様に合わせた修正が必要になる変更のことです。

英語では「Breaking Change」と呼ばれます。

例えば、利用しているライブラリの更新で、これまで使っていた関数が削除された場合です。更新前のコードでその関数を呼び出そうとしても使えないため、代わりの関数を使うように書き直す必要があります。

このように、従来の利用方法が通用しなくなることが、破壊的変更のポイントです。

ここでいう「破壊」は、データの削除や機器の故障を意味するわけではありません。また、エラーで停止する場合だけでなく、処理結果が変わり、従来のコードでは期待した動作にならなくなる場合も含まれます。

破壊的変更の具体例

破壊的変更は、関数の削除だけでなく、受け取るデータや設定方法の変更でも発生します。ここでは、説明用の架空の例で見ていきましょう。

関数名が変更され、古い関数が使えなくなる

あるライブラリで、利用者情報を取得する関数がgetUser()からfetchUser()へ変更され、古いgetUser()が削除されたとします。

この場合、更新後もgetUser()を呼び出しているコードは動かなくなるため、fetchUser()を使うように修正する必要があります。

ただし、fetchUser()が追加されても、getUser()が従来どおり使える状態で残っていれば、関数の追加だけでは破壊的変更にはなりません。

APIから返されるデータの項目名が変わる

APIは、プログラムから別のソフトウェアの機能やデータを利用するための窓口です。

例えば、顧客情報を取得するAPIで、氏名を表す項目名がnameからfullNameに変更され、nameが返されなくなったとします。

従来のプログラムがnameを読み取る作りになっていれば、そのままでは氏名を取得できなくなります。fullNameを読み取るように、プログラムの修正が必要です。

通信自体が成功していても、受け取るデータの形式が変わることで問題が発生する場合があります。

必須の設定項目が増える

あるツールが、更新前は接続先を指定するだけで動いていたとします。

更新後、新たに認証用の設定が必須になり、未設定では起動できなくなった場合、従来の設定ファイルをそのまま使うことはできません。新しい設定項目を追加する必要があります。

このように、プログラムのコードだけでなく、設定ファイルの修正が必要になる変更も破壊的変更に該当します。

破壊的変更と非破壊的変更の違い

非破壊的変更とは、従来の使い方やコードをそのまま利用できるように、互換性を保った変更のことです。

両者の違いは、変更の大きさや追加機能の数ではなく、従来の利用方法を維持できるかどうかにあります。

比較項目	破壊的変更	非破壊的変更
従来の使い方	そのままでは動作しなくなる場合がある	従来どおり利用できる
利用者側の対応	影響を受ける部分の修正や移行が必要	従来の使い方を続けるための修正は基本的に不要
関数の変更例	古い関数を削除し、新しい関数へ置き換える	古い関数を残したまま、新しい関数を追加する
設定の変更例	新しい設定を必須にし、従来の設定では動かなくする	省略しても従来どおり動く任意の設定を追加する

例えば、顧客情報を取得するライブラリに、新しく「メールアドレスを取得する機能」が追加されたとします。既存の氏名取得機能も従来どおり使えるなら、その機能追加は非破壊的変更です。

一方、氏名取得機能の呼び出し方が変わり、以前のコードでは使えなくなれば、破壊的変更になります。

つまり、機能追加だから必ず非破壊的変更になるわけではありません。既存の機能や動作への影響を含めて判断することが大切です。

破壊的変更が行われる理由と更新前の確認ポイント

破壊的変更は、古い仕組みを整理したり、安全性を高めたり、使いにくい設計を改善したりするために行われることがあります。

例えば、古い認証方法に問題があり、安全性の高い方法へ切り替える場合です。従来の接続方法を廃止すれば利用者側の対応が必要になりますが、安全に利用し続けるために必要な変更である場合もあります。

破壊的変更が含まれる場合、影響を受けるコードや設定の修正、動作確認などに多くの時間と手間がかかることがあります。そのため、バージョンアップしたくても、なかなか対応を進められない場合があります。

更新するときは、提供元のリリースノートや移行ガイドで、次の点を確認しましょう（リリースノートは、そのバージョンで何が変わったかをまとめた資料です）。

• 「破壊的変更」「Breaking Changes」などの記載があるか
• 自分が使っている機能や設定が変更対象になっているか
• 変更対象の場合、どのような修正や移行が必要か

また、バージョン番号も確認の手がかりになります。

例えば、バージョン番号に変更の意味を持たせる「セマンティックバージョニング」というルールでは、正式版の公開APIに互換性のない変更を加える場合、1.4.2から2.0.0のように先頭の数字を上げます。

ただし、すべての製品がこのルールを採用しているわけではありません。また、このルールでも0.x.xは初期開発段階として扱われ、互換性が安定しているとは限りません。番号だけで判断せず、提供元が公開している変更内容を確認しましょう。

本記事のまとめ

この記事では「破壊的変更」について、以下の内容を説明しました。

• 破壊的変更とは、従来の使い方やコードではそのまま動かなくなり、修正や移行が必要になる変更のこと。
• 破壊的変更があっても、変更対象の機能を使っていなければ、その変更による影響を受けない場合がある。
• 非破壊的変更は、従来の使い方やコードを引き続き利用できるように互換性を保った変更である。
• 更新前には、バージョン番号だけでなく、変更内容と自分の利用箇所への影響を確認する。

お読みいただきありがとうございました。