Just Keep Updating - RHEL運用に見る日本型エンタープライズの黄昏
RHEL の運用をめぐる議論で、いちばん先に確認すべきことは単純です。Red Hat の本流は、minor release を追いかけて更新し続けることです。Red Hat 自身が、保守メリットを最大化する推奨運用として、minor が出るたびに順次更新していくことを明示しています。そのうえで、どうしても同じ minor に留まりたい顧客のために EUS を用意し、24 か月の延長枠を設けています。つまり、思想の中心は最初から「固定」ではなく「追随」です。
では AUS は何か。Red Hat の公開情報には RHEL Advanced Update Support Add-on, Annual が現れ、実際の errata やリポジトリー運用の文脈でも存在が確認できます。けれども、EUS のように対象 minor、期間、運用意図が公開制度として前面に整理されているわけではありません。AUS は「存在する」が、「公開された標準制度」としては見えにくい。ここが本質です。
日本企業で AUS が重宝された理由も、簡単です。止められない基幹系では、OS の minor update は OS だけの変更ではなく、監視、バックアップ、認証、監査、業務アプリ、停止計画の再承認まで連鎖します。だから「変えないこと」には強い合理性がありました。AUS や AMC は、その合理性を制度にしたものです。実際、AMC の歴史は日本の mission-critical 顧客や OEM 協業の文脈と強く結びついています。
しかし、ここで現代のセキュリティ実務が冷徹な線を引きます。世界標準の脆弱性管理は、「ベンダーが何かを出しているか」だけでは回りません。資産管理、監査、サポート判定、運用自動化の各層が、その運用を共通言語で理解できる必要があります。Tenable の公開情報を見ると、AUS 対象の RHSA を取り込むプラグインは存在しますが、監査やサポート判定の公開面では EUS 対象 minor を明示し、7.3 系のような系統を SEoL として検出しています。Rapid7 も AMC 由来のアドバイザリを公開 DB に取り込んではいますが、少なくとも確認できる範囲では、AUS を前提にした公開制度設計を前面には出していません。AUS は「読めない」のではなく、第一級の前提として扱われにくいのです。
ここに、日本の強さと限界が同時にあります。日本企業は、変更のコストと責任の重さを深く知っていたからこそ、AUS のような制度を必要としました。それ自体は合理的でした。けれども、例外は長く使われると常識に見えてきます。そして、常識になった例外は、やがて世界標準の運用モデルやツール群と噛み合わなくなります。AUS の弱点は、セキュリティ修正が出ないことではありません。例外としては成立していても、標準としては説明しにくいことです。
しかも、RHEL 自体の進む方向はすでに変わり始めています。Red Hat は RHEL 7 の保守終了後、RHEL 9 または 10 への移行を強く推奨しており、同時に Image Mode for RHEL では OS をコンテナーとして構築、配布、更新する運用を打ち出しています。これは単なる新機能ではありません。OS を「固定して守る対象」から、「再生成して入れ替える対象」へ移す発想です。この世界では、安定とは止まっていることではなく、更新し続けても壊れにくいことを意味します。
だから結論は、身もふたもないほど単純です。AUS は悪ではありません。歴史的には、きわめて日本的で、きわめて実務的な知恵でした。けれども 2026 年の視点で言えば、それはもはや中心ではありません。EUSやEEUS が「公開された例外」なら、AUS は「案件に埋め込まれた例外」です。例外に価値がないのではありません。ただ、現代のインフラは、例外を賢く増やすことではなく、例外なしでも回るように更新し続けることを要求している。Just Keep Updating――結局、それがいちばん深い意味での安定なのです。
