昨日動いたものが今日動かなくなる：外部起因の仕様変更とEOLに備える【第2回】

「何も変えていないのに壊れた」——この記事を読み終えると、サポート終了・OSパッチ・API廃止という「自分の外側のカレンダー」で起きる理不尽を、期限の一覧表に変え、壊れる前に手を打てるようになります。理不尽との付き合い方シリーズ（全8回）の第2回です。

⚠️ このシリーズの事例について
各回に登場する職場のストーリーは、Reddit（r/ExperiencedDevs、r/sysadmin 等）・Hacker News・X（旧Twitter）で繰り返し共有されている体験談をモデルに、人物・企業・時期・数値を置き換えて脚色したフィクションです。一方、検証セクションで扱う製品のサポート終了日・脆弱性・事故は一次情報で確認できる実在の事実であり、参考文献に原典を示しています。

🎯 テーマの主役：「外部起因の仕様変更」——他人のカレンダーで動いている時限爆弾

今回の主役は外部起因の仕様変更です。一言で言えば、外部起因の仕様変更とは、あなたが一行もコードを変えていないのに、あなたの外側の都合で、あなたのシステムの前提が壊れることです。

日常の例えで言うなら、賞味期限です。冷蔵庫に入れた牛乳は、あなたが何もしなくても、日付が来れば飲めなくなります。牛乳が悪いわけでも、あなたが管理を怠ったわけでもありません。ただ、期限というものが、あなたの外側のカレンダーで決まっているだけです。ソフトウェアも同じです。OSにもライブラリにも証明書にも、それぞれ別の会社が決めた期限があります。あなたが完璧に動くコードを書いても、依存先の期限が来れば、そのコードは動かなくなります。

この「外部のカレンダー」は、3つの形で牙をむきます。第一に、サポート終了（EOL: End of Life）。更新が止まり、脆弱性が修正されなくなり、やがて動作しなくなります。第二に、一斉に切れる期限。TLS証明書、認証トークン、APIのバージョンなど、ある日時を境に一斉に無効になるものです。第三に、脆弱性。ある日突然、世界中の誰かがあなたのシステムを攻撃対象として見つけます。この3つは、壊れる速さと、事前に気づけるかどうかが違います。だから対策も変わります。

動機：「何も変えていないのに壊れた」は本当に理不尽か

※以下は、Reddit の r/sysadmin や Hacker News で繰り返し共有されてきた体験談をモデルにした脚色（フィクション）です。実在の個人・企業ではありません。

ある物流会社の基幹システムを保守していたエンジニアBは、朝の8時40分に電話を受けました。倉庫のハンディ端末が、全台、接続できなくなっている。前日の夜まで、何の問題もなく動いていました。リリースもしていない。サーバーの設定も変えていない。誰も何もしていないのに、全部が止まりました。

原因は、その日の朝に切れたTLS証明書でした。切れたのは、外部の連携サービスの証明書でした。Bのチームは、Bのシステムの証明書は管理していましたが、連携先の証明書の期限は把握していませんでした。連携先の担当者は、3週間前に異動していました。

復旧には6時間かかりました。この6時間で、Bのチームは「何もしていないのに壊れた」と何度も言いました。しかし振り返ってみると、壊れたのは必然でした。期限は、3年前から決まっていたのです。ただ、誰もその日付を見ていなかっただけでした。

この出来事を「理不尽」と呼ぶかどうかは、実は紙一重です。第一回で確認した3条件に当てはめてみます。納得できたか——できません（自分たちの管理外の日付だから）。落ち度があるか——あります（1回目の記事の定義では、落ち度がないことが理不尽の条件でした）。ここが重要です。外部起因の仕様変更は、当事者にとっては理不尽に見えるが、実は「見ていなかっただけ」である部分が大きい。つまり、「理不尽」の中でも予防できる理不尽です。

だからこの回で扱うのは、感情ではなく作業です。やることは3つ。第一に、依存しているものの期限を集める。第二に、期限を1枚の表にする。第三に、期限に合わせて、壊れる前に手を打つ順番を決める。この3つができれば、「何もしていないのに壊れた」の大半は消えます。

🔍 検証①：3つの壊れ方——なぜ「EOL」は静かなのか

外部起因の破壊は、壊れ方の性質が3種類あります。この違いを知らないと、期限管理の優先順位を間違えます。

この表で最も誤解されているのは、EOLは「まだ動いているから大丈夫」が通用しないという点です。EOLを過ぎても、システムは多くの場合そのまま動き続けます。動かなくなるのは、もっと後です。ここが罠です。

EOLを過ぎると、次の4つが順番に起きます。第一に、脆弱性が修正されなくなる（攻撃は増える）。第二に、周辺ライブラリとの互換性が壊れる（新しい証明書方式に対応できない、新しいTLSのバージョンで通信できない）。第三に、調達できなくなる（対応ハードウェアが新品で買えない、保守契約が結べない）。第四に、人がいなくなる（そのバージョンを扱えるエンジニアが社内外から消える）。

つまり、EOLは「その日に壊れる」のではなく、「その日から徐々に修復不能になっていく」ものです。ここが第3の壊れ方（脆弱性）と決定的に違う点です。EOLは静かに進行するので、気づいたときには選択肢が消えています。

🔍 検証②：実際のEOLはどう宣告されるのか——CentOSとTerraformの事例

抽象論では実感が湧かないので、実際に起きた「外部起因の仕様変更」を見ます。この2つは、いずれも技術者コミュニティで大きな議論を呼んだ事例です。

事例A：CentOS 8 のサポート終了（2020年12月8日発表）

CentOSは、Red Hat Enterprise Linux と互換性を持つ無償のサーバー向けOSとして、長く使われてきました。CentOS 8 は2029年5月までサポートされると案内されていました。ところが2020年12月8日、Red Hatは方針を転換し、CentOS 8 のサポートを2021年12月31日で終了すると発表しました（当初予定より約7年半の前倒し）。代わりに、CentOS Stream という「開発版に近い位置づけ」の配布形態へ移行するという説明でした。

この発表は、CentOS 8 を前提にシステムを組んでいた世界中の現場に、数年単位の予定変更を強いました。コミュニティでは、後継として AlmaLinux と Rocky Linux が立ち上がりました。注目すべきは、サポート終了の日付が、使っている側の努力では一切動かなかったという点です。どれだけ反対しても、決定は変わりませんでした。一方で、「互換性のある選択肢が現れた」ことも事実です。理不尽は理不尽のままですが、逃げ道は用意されることがあります。

事例B：HashiCorp のライセンス変更（2023年8月10日発表）

インフラ構成管理ツール Terraform を提供していた HashiCorp は、2023年8月10日、同社製品のライセンスを MPL 2.0 から BUSL 1.1（Business Source License）へ変更すると発表しました。BUSL は「一定期間後にオープンソース化されるが、それまでの商用利用に制限がある」という形式のライセンスです。

これにより、Terraform と競合する製品やサービスを提供していた事業者が、そのままでは Terraform を使えなくなりました。コミュニティは MPL 2.0 の時点のコードから分岐（フォーク）し、同年、OpenTofu というプロジェクトを立ち上げました。2024年には Linux Foundation の傘下に入っています。

この2つの事例から読み取れる構造は、同じです。

共通する3つの教訓。 第一に、決定の理由はいつも「相手の事業戦略」であること。こちらが良く使っているかどうかは、決定要因になりません。第二に、告知は「決定済み」の状態で来ること。つまり、告知を受け取った時点で、こちらに残っている選択肢は「どう適応するか」だけです。第三に、逃げ道は、多くの場合コミュニティが作ること。ただし、コミュニティが動くまでには時間がかかるので、期限ぎりぎりまで待つと逃げ道が間に合いません。

🔍 検証③：依存の4層——自分の外側はどこまで続いているか

では、何の期限を集めればよいのでしょうか。自分のシステムの外側は、4層に分かれています。この4層を意識すると、棚卸しの抜けが減ります。

重要なのは、③と④は「コードの中」を見ても見つからないという点です。証明書の期限は設定ファイルやクラウドの管理画面にあり、ライセンスの期限は契約書にあります。コードを読んで分かる範囲には、これらの期限は存在しません。だから「コードはきれいなのに壊れる」という現象が起きます。

🔍 検証④：3つの適応——移行・隔離・据え置き

外部起因の変更に対して、取れる手は3つしかありません。ここで大切なのは、「どれを選ぶかは経営判断であり、エンジニアの仕事は選択肢と代償を並べること」という点です。

3つ目を選ぶことは、悪ではありません。「知らないうちに過ぎていた」ことだけが問題です。据え置きを選ぶなら、次の3点を必ず記録します。第一に、いつからいつまで据え置くか。第二に、その間、何のリスクを受け入れるか（攻撃されたらどうなるか、止まったら誰が困るか）。第三に、誰がその判断をしたか。記録がなければ、あなたが数年後にその責任を負います。記録があれば、それは組織の判断として扱われます。

「隔離」は最も過小評価されている選択肢です。全部を移行できないとき、影響範囲を狭めて時間を稼ぐのは、立派な設計判断です。具体的には、古い依存を使う部分を1つのモジュールや1つのサービスに閉じ込める、間に変換用の層（アダプタ）を挟む、といった方法があります。第7回で扱う「前任者の遺産」でも、この隔離が中心的な技術になります。

🔍 検証⑤：逆算のタイムライン——「いつ始めるか」は期限から決まる

期限が分かったら、次は「いつ始めるか」を決めます。ここで多くの人が間違えます。移行の作業量を過大評価して先延ばしにするか、過小評価して直前で慌てるかのどちらかです。正確な見積もりは困難なので、期限から逆算した締切を先に決めるのが実務的です。

この表の要点は、「18か月前にやることは、期限を知ることだけ」という点です。期限を知るのは、ほぼ無料です。しかし、期限を知らずに12か月を過ごすと、残り6か月で全部やることになります。差額は、ほぼ「知っていたかどうか」だけで発生します。

結果：EOL棚卸しの手順（4ステップ）

ここまでの内容を、実行できる手順に畳みます。

この表の最大の価値は、判断を「今」から「期限の直前」に移せることです。エンジニアが最も消耗するのは、作業そのものよりも「いつか壊れる何かを、忘れたまま抱えている状態」です。一覧にして壁に貼れば、その不安は消えます。不安は、把握できないときに最も大きくなります。

考察：外部起因の理不尽は「予報」できる唯一の理不尽である

第1回で、理不尽を技術・組織・制度の3つに分けました。この回で扱った外部起因の仕様変更は、この3つの中でも、最も「予報」が効くものです。天気に例えるなら、台風です。いつ来るかは予報に出ます。進路も分かります。被害をゼロにはできませんが、被害を小さくする準備はできます。

対して、組織の理不尽（第4回〜第6回）は予報が難しく、制度の理不尽は予報以前に前提です。つまり、この回の内容は「コストが低く、効果が確実な対策」です。何より、外部起因の理不尽は、努力ではなく段取りでほぼ解決できます。これは、シリーズ全体の中で数少ない「確実に勝てる戦い」です。

そしてもう1つ。外部起因の変更は、あなたの技術力を試す場でもあります。CentOS 8 の話でも Terraform の話でも、移行を実行した現場のエンジニアは、新しい環境での設計判断を大量にこなしました。理不尽は、準備していた人にとっては学習の機会になり、準備していなかった人にとっては障害対応の夜になります。同じ出来事が、です。

📌 注目ポイント

第一に、外部起因の破壊には3種類（EOL・一斉に切れる期限・脆弱性）があり、それぞれ壊れる速さと事前に気づけるかが違うことです。第二に、EOLは「その日に壊れる」のではなく「その日から修復不能になっていく」こと。静かに進行するからこそ危険です。第三に、依存は4層（コード・実行基盤・通信・契約制度）あり、下の層ほどコードを読んでも見えないこと。第四に、取れる手は移行・隔離・据え置きの3つだけであり、据え置きを選ぶなら記録が必須であること。

💡 活用事例（脚色）：証明書が切れる日を知っていたチームと、知らなかったチーム

※Reddit や Hacker News で繰り返し共有されてきた複数の体験談をモデルにした脚色（フィクション）です。

同じ会社の、隣り合う2つのチームの話です。

Cチームは、外部の決済サービスと連携していました。あるとき、リードエンジニアが「この連携、証明書の期限が1年後だ。更新手順を確認しておこう」と提案しました。作業は2時間で終わりました。やったことは3つ。連携先の証明書の期限を調べて表に書く。更新が必要になったときの連絡先を確認する。切れた場合に何が止まるかを、運用チームと共有する。コードは1行も変えていません。

Dチームも、別の外部サービスと連携していました。Dチームは多忙でした。新機能の開発が3本走っており、EOLの棚卸しは「落ち着いたらやる」と先延ばしになっていました。

1年後、Cチームの連携先の証明書が切れました。切れる1か月前に連携先から告知があり、Cチームはあらかじめ確認していた手順で2時間で更新しました。誰も気づきませんでした。何も起きなかったので、Cチームは褒められませんでした。

同じ週、Dチームの連携先で認証方式が変わりました。Dチームは告知メールを見落としていました（担当者が異動しており、メーリングリストの宛先が古かったためです）。金曜の夕方、連携している機能が全停止しました。復旧は月曜の昼までかかりました。週末に2名が出勤し、取引先に謝罪し、原因調査の報告書を書き、再発防止策として「EOL棚卸しをやる」と決めました。Dチームは、Cチームが1年前に2時間でやったことを、1年遅れで、週末勤務つきでやることになったのです。

この2チームの差は、能力ではありません。 Dチームのエンジニアのほうが優秀だった可能性すらあります。差は、「棚卸しを、やるべき仕事として先に予定に入れていたか」だけです。外部起因の理不尽は、「落ち着いたらやる」と言っている限り、永遠に来ません。落ち着く日は来ないからです。だから、落ち着くのを待たずに、予定に入れる必要があります。

✅ 要点まとめ

この回の内容は、覚えるべき知識ではなく、そのまま作業手順になるものです。期限を見つけた時点で、この一覧に戻ってください。

• 「何も変えていないのに壊れる」の大半は、期限（他人のカレンダー）を見ていなかっただけであり、予防できる。
• 壊れ方は3種類。EOL（遅い・事前に分かる）／一斉に切れる期限（速い・事前に分かる）／脆弱性（速い・公表まで分からない）。
• EOLを過ぎても動き続けるのが罠。動かなくなる前に、修正されなくなり、調達できなくなり、人がいなくなる。
• 決定はいつも相手の事業戦略で行われ、告知は決定済みの状態で来る。受け取った時点で選べるのは適応だけ。
• 依存は4層。③通信層と④契約層は、コードを読んでも見つからない。
• 取れる手は移行・隔離・据え置きの3つ。隔離は最も過小評価されている。据え置きは記録とセットでのみ許される。
• 18か月前にやることは「期限を知る」だけ。ここを飛ばすと、残り6か月で全部やることになる。
• 外部起因は予報できる唯一の理不尽。準備した人にとっては学習の機会、しない人にとっては障害対応の夜になる。
• 不安は、把握できないときに最も大きくなる。一覧にすることが最大の対策。

🚀 取り込み方：明日から使う3段階

今日（30分でできること）：自分の担当システムで使っている言語・フレームワーク・OSのバージョンを、3つだけ書き出してください。次に、そのうち1つの公式サイトで「ライフサイクル（Lifecycle / Support policy）」のページを開き、サポート終了日を確認します。1つ分かるだけで、この作業が想像より軽いことが分かります。

今週（小さく試すこと）：上の4ステップのうち、ステップ1と2を担当範囲だけでやってみてください。表は「名前／現行バージョン／期限／担当／次の行動」の5列です。分からない欄は「不明」と書きます。空欄にしないことが重要です。「不明」は調べる対象ですが、空欄は忘れられます。

今月（仕組みにすること）：できた表を、チームが必ず見る場所（スプリントのボード、共有ドキュメント、Wiki など）に置き、四半期ごとの見直しを予定表に登録してください。あわせて、証明書とドメインと外部APIの期限だけを集めた「③通信層の一覧」を別途作ります。この2枚の表が、あなたのチームの初期の防災マップになります。

🔥 ハマりポイント

その1：「まだ動いているから大丈夫」と判断する。 EOLはその日に壊れません。だから「動いている」という証拠は、何の安心材料にもなりません。判断すべきは「動いているか」ではなく「期限から何か月経ったか」です。EOL後1年を超えたら、新しい環境で再現できないリスクが急に上がります。

その2：棚卸しを「落ち着いたらやる」と先延ばしにする。 落ち着く日は来ません。棚卸しは、「落ち着いてからやる仕事」ではなく「落ち着くために予定に入れる仕事」です。半日で終わる作業が、1年後には週末勤務になります。第1回の「記録」と同じで、その日のうちにやるから安いのです。

その3：据え置きを「何もしない」と同一視する。 据え置きは立派な経営判断になり得ますが、記録を伴わない据え置きは、単なる先送りです。後で問題になったとき、あなたの判断なのか組織の判断なのかが分からなくなります。「いつまで・何のリスクを・誰が承認したか」の3点を、その日のうちに書いてください。

その4：依存の期限を、コードの中だけ探す。 ③通信層と④契約層の期限は、コードの中にありません。探す場所を間違えると、「全部調べたのに漏れた」が起きます。

🔄 比較：4つの対策アプローチと、それぞれの代償

組み合わせが実務的です。 コード層はツールで自動化し、③通信層と④契約層は手動の表で補う。この分担が、最も費用対効果が高いと考えられます。

📅 今後の展望：2026年に向けた期限の動向

外部起因の仕様変更は、これからも続きます。特にジュニアエンジニアが知っておくべき動向を3つ挙げます。

第一に、OSとミドルウェアの一斉更新です。Windows 10 は2025年10月14日にサポートが終了しました（Extended Security Updates を除く）。Ubuntu 20.04 LTS は2025年5月に標準サポートが終了し、22.04 LTS も2027年4月が期限です。「会社のPCがまだWindows 10」という現場は珍しくありません。これは開発環境全体の更新を意味します。

第二に、ライセンスモデルの変更が定着しつつあることです。HashiCorp の事例以降、いくつかの製品で同様の方針転換が続いています。「無償で使えていたものが、有償になる」は、これからも起きます。技術選定の時点で、ライセンスの将来性を確認する習慣が必要です。

第三に、言語とフレームワークのサポート期間が短くなる傾向です。Node.js は偶数バージョンがLTSとして扱われ、サポート期間はおおむね30か月です。Python や Java の長期サポート版に乗り換えておくほうが、結果的に安定します。「新しいものを使う」より「長く支えられるものを選ぶ」が、外部起因の理不尽に対する最も実務的な防御です。

まとめ

外部起因の仕様変更は、あなたの落ち度ではありません。あなたの外側の都合で決まります。そして、決定はいつも相手の事業戦略で行われ、こちらには適応だけが残されます。だから、この理不尽は「避ける」のではなく「予定に入れる」ことでしか対処できません。

やることは3つだけです。期限を集める。1枚の表にする。期限から逆算して予定に入れる。この3つは、18か月前ならほぼ無料で、6か月前なら残業になり、当日なら障害対応になります。

ここまで読んだあなたは、自分の担当システムの期限を、今日1つだけ調べられるようになりました。明日は3つ調べてください。その1週間後には、あなたのチームには「いつ何が壊れるか分かっている人」が1人いる状態になります。理不尽に強いチームと弱いチームの差は、能力ではなく、この1人から始まります。

参考文献

1. CentOS Project. “CentOS Linux 8 EOL.” https://www.centos.org/
2. Red Hat. “CentOS Stream: Frequently Asked Questions.” https://www.redhat.com/
3. AlmaLinux OS Foundation. https://almalinux.org/
4. Rocky Linux. https://rockylinux.org/
5. HashiCorp. “HashiCorp adopts Business Source License.” 2023. https://www.hashicorp.com/
6. OpenTofu. “OpenTofu: The open source infrastructure as code tool.” https://opentofu.org/
7. Linux Foundation. “OpenTofu joins the Linux Foundation.” 2024. https://www.linuxfoundation.org/
8. Python Software Foundation. “PEP 373 / PEP 404: Python 2.7 Release Schedule and Sunset.” https://peps.python.org/
9. OpenSSL. “OpenSSL 1.1.1 End of Life.” 2023. https://www.openssl.org/
10. Let’s Encrypt. “DST Root CA X3 Expiration (September 2021).” https://letsencrypt.org/
11. NIST. “CVE-2021-44228 (Log4Shell).” National Vulnerability Database. https://nvd.nist.gov/
12. IETF. “RFC 8996: Deprecating TLS 1.0 and TLS 1.1.” 2021. https://www.rfc-editor.org/
13. Microsoft. “Windows 10 support ends on October 14, 2025.” https://www.microsoft.com/
14. Canonical. “Ubuntu release cycle / LTS support.” https://ubuntu.com/
15. Node.js. “Releases: Node.js Release Working Group (LTS schedule).” https://nodejs.org/
16. CycloneDX / SPDX. “Software Bill of Materials (SBOM) standards.” https://cyclonedx.org/ , https://spdx.dev/