下位互換は守るべきか捨てるべきか――「担保・変換・切り捨て」の判断基準

この記事を読み終えると、「この変更は互換性を維持すべきか」をチームで議論するための具体的な軸が手に入る。

📌 「下位互換」とは何か――冷蔵庫のコンセントで考える

ちょっと考えてほしい。あなたが10年前に買った冷蔵庫、今でも同じコンセントで動く。
電力会社は「古い家電には対応しません」とは言わない。これが後方互換性（backward compatibility）の日常的な姿だ。

ソフトウェアの世界でも同じことが起きる。新しいバージョンのソフトウェアが、古いバージョン向けに書かれたコードやデータを引き続き動かせる状態を「後方互換性がある」という。
本記事では一般的な用法にならい、「新バージョンが旧バージョンの資産を動かせる」意味で下位互換という言葉を使う（厳密な上位・下位の定義は別途確認してほしい）。

互換性を崩す変更のことを破壊的変更（breaking change）と呼ぶ。関数のシグネチャを変える、ファイルフォーマットを刷新する、依存ライブラリを切り替える——これらはすべて、既存の利用者に「コード直してね」を強要する変更だ。

そしてここからが本題だ。破壊的変更は悪なのか？

答えは「場合による」以外にない。しかし「場合による」で思考停止するのがいちばんまずい。
では、「場合」をどう判断するのか。

💡 なぜWindowsは40年前のソフトを動かし続けるのか

互換性維持の執念という点で、Microsoftは世界トップクラスだ。

DOSの時代に築いたソフトウェア資産を継承し続けることで、Windowsは選ばれ続けてきた。互換性を守る限りユーザーが離れない——これが同社の原体験であり、Win32 APIが何十年も維持されている背景にある。

Linuxカーネルも同様で、「ユーザーランドを壊さない（WE DO NOT BREAK USERSPACE!）」はカーネル開発の第一のルールとされている。アプリケーション開発者が毎回コードを書き直す羽目にならないよう、カーネル側が変化に追随するという思想だ。

これだけ読むと「互換性は絶対に守るべき」という結論になりそうだが、現実はそう単純ではない。

Python 3が2008年にリリースされ、2020年にPython 2のサポートが終了するまで、実に12年かかった。両方サポートし続けることはエコシステム全体に重い負担をかけ続けた——とはいえ、互換性を即座に切り捨てていたら、それはそれで阿鼻叫喚の地獄になっていただろう。

🔥 ハマりポイント：「互換性を守る」がデフォルト前提になる罠

「互換性は守るべきだ」という暗黙の合意が蔓延しているチームでよく起きる失敗がある。

破壊的変更を提案した人間が「説明責任」を一方的に押し付けられる構図だ。

「なぜ互換性を壊す必要があるのか説明せよ」という空気が生まれると、互換性の維持コストを誰も定量化しなくなる。10年後に「古いAPIを全部消したい」と言っても「影響範囲が大きすぎて動けない」という状況が生まれる。

正しい問いの立て方は「互換性を守るコストと、捨てるコストを両方テーブルに乗せること」だ。

🔄 3つの選択肢を整理する

破壊的変更への対応には、大きく3つの道がある。

どれが正解かはコンテキスト次第だが、選択肢を明示した上で意思決定することが重要だ。

✅ 判断基準：5つの軸で考える

「担保・変換・切り捨て」を選ぶための判断軸を5つ整理した。

軸1：影響を受けるユーザーの規模と種別

筆者の肌感覚では、ここが最も重要な軸だ。

破壊的変更によって何人が、どんな状況で影響を受けるかを考える。

• 組み込みシステム・医療機器・金融インフラに使われているなら、互換性を崩すことは人命や資産に直結するため、担保か変換ツールが原則必須になる
• 個人開発のライブラリで依存者が数十人なら、メジャーバージョンアップ時に破壊的変更を入れても許容されやすい
• プラットフォームやOSでは、不特定多数のユーザーが何年も前のコードを動かしているため、互換性の優先度は自然と高くなる

Linuxカーネルが「ユーザーランドを壊さない」を鉄則にするのは、世界中の無数のプログラムがその上で動いているからだ。依存関係の広さが互換性の義務を生む。

軸2：移行コストの非対称性

「移行してください」と言われたとき、ユーザー側の工数はどれくらいか。

• 置き換えが機械的にできる（関数名を変える程度）なら、変換ツールで吸収できる
• 設計思想ごと変わる（Python 2 のstr/unicode問題のように）なら、機械的変換では限界があり、担保か長い移行期間が必要になる

SemVer（Semantic Versioning）の考え方では、後方互換性のない変更はメジャーバージョンを上げることで「この変更は壊れます」と明示する。ただし現実では、メジャーバージョンアップを「マーケティング的な大型リリース」に使う例が後を絶たない。SemVer自体は優れた約束事だが、人間が絡むと形骸化しやすいのも事実だ（筆者もそのチームにいたことがある）。

軸3：技術的負債の蓄積速度

互換性を「担保」し続けることのコストは、時間とともに加速する。

Python 2/3の並走は、主要ライブラリが両方をサポートし続けることで維持コストが倍増し、エコシステム全体の進化を鈍化させた。互換性維持のコードは通常コードと重なり合って複雑度を増す——これを後方互換税と呼んでもいいかもしれない。

後方互換税の支払いが加速しているなら、早めに切り捨てのタイムラインを決めるべきサインだ。

軸4：セキュリティ・安全性の要件

セキュリティ上の理由がある場合、互換性は後退させざるを得ないことがある。

Red Hat Enterprise Linuxのポリシーでも明記されているように、「重大なセキュリティ問題への対処のために、互換性維持の目標に例外を設けることがある」とされている。古い暗号アルゴリズムへの対応や、根本的な脆弱性の修正は、互換性より優先される。

軸5：ユーザーの「移行意思と能力」

ユーザーが移行したくても移行できない状況があることを忘れてはいけない。

• レガシーシステムに組み込まれていて、アップデート自体ができない環境
• 開発が止まったサードパーティ依存があり、移行ブロッカーになっている
• 組織の意思決定サイクルが遅く、数年単位でしか変更できない

こういった場合は、「移行できるはずなのに移行しないユーザー」と「移行したくても移行できないユーザー」を区別した上で、どこまで待つかを決める必要がある。

🚀 実践：判断フレームワークとして使う

上記の5軸をまとめると、以下の問いを順番に答えるだけで意思決定の骨格が作れる。

重要なのは、「切り捨て」を選ぶ場合には必ず猶予期間と移行ガイドをセットにすることだ。
Joomlaのポリシーでは「deprecated（非推奨）にした機能は2メジャーバージョン先まで削除しない」という明文化されたルールがある。こういった「いつ消えるかを明示するルール」があるだけで、ユーザー側の計画立案がまったく変わる。

📅 まとめ：互換性の判断は「コスト比較」だ

互換性の是非は、哲学的な議論ではなくコスト比較の問題だ。

「守ることのコスト」と「壊すことのコスト」を両方見積もった上で、どちらが許容できるかを判断する。その見積もりを助けるのが今回紹介した5つの軸だ。

Windowsが互換性を守り続けたのは、それが事業上の合理的選択だったからだ。Pythonが互換性を捨てたのも、12年かけて説明責任を果たした上でエコシステム全体の健全性を選んだからだ。正解はどちらか一方ではなく、文脈の中にある。

あなたが今直面している「この変更、互換性壊していいの？」という問い——ぜひ5軸で一度整理してみてほしい。きっとチームの議論が変わる。

参考文献

1. Semantic Versioning 2.0.0 — Tom Preston-Werner
2. Backward Compatibility Policy — Joomla! Documentation
3. Why Semantic Versioning Isn’t — Jeremy Ashkenas (GitHub Gist)
4. Red Hat Enterprise Linux 9: アプリケーションの互換性ガイド
5. Python 3が後方互換性を捨ててでも求めたもの — ＠IT
6. ABI 互換性解説 — Cybertrust
7. Beyond API Compatibility: Understanding the Full Impact of Breaking Changes — InfoQ