RHEL 10の先へ：RHEL 11に向けたロードマップを整理する
Red Hat Summitで、
“The roadmap beyond Red Hat Enterprise Linux 10: Building platforms the open source way”
というセッションを聞いてきました。
このセッションは、単なる「RHEL 10.2 / 9.8の新機能紹介」ではありませんでした。
大きなテーマは、RHELが今後どのように作られ、どのように運用されていくのか、という話です。
特に、RHEL 11に向けて、ユーザーやコミュニティとより早い段階から一緒に作っていく方向性が示されていたのが印象的でした。
この記事では、特に気になった以下のポイントを整理します。
- RHEL 11に向けた開発プロセスの変化
- Digital Roadmapによる将来情報の見える化
- RHEL 10.2 / 9.8の新機能
- RHEL MCP ServerとAIエージェント連携
- Image Mode / bootcによるOS運用の変化
- Sealed ImagesによるOSイメージの信頼性向上
RHEL 11では「もっと早い段階から一緒に作る」方向へ
今回のセッションでまず重要だったのは、RHEL 11に向けた開発の進め方です。
これまでのRHELも、RFEやバグ報告を通じてユーザーからのフィードバックを受け付けていました。
ただ、利用者側から見ると、ある程度できあがったものを受け取る印象が強かったと思います。
RHEL 11では、より早い段階からユーザーやコミュニティのフィードバックを取り入れていく方向が示されていました。
RHELの開発フローは、以下のように説明されていました。
ざっくり整理すると、以下のような関係です。
Fedora Linux
↓
Fedora ELN
↓
CentOS Stream
↓
RHEL
Fedora Linuxは、新しい技術が入ってくる場所です。
Fedora ELNは、次のメジャーRHELを見据えたプレビューに近い位置づけです。
CentOS Streamは、次のRHELマイナーリリースの上流にあたります。
そして最終的に、安定化され、サポート対象として提供されるものがRHELになります。
つまり、今後はRHELの将来像がより早い段階で見えるようになり、利用者側も「何が来そうか」「何が変わりそうか」を把握しやすくなります。
RHELのロードマップが、単に公開後に確認するものではなく、事前に見ながら備えるものに近づいていると感じました。
Digital Roadmap：将来のRHELを早めに確認できる
RHELの将来を確認する手段として紹介されていたのが Digital Roadmap です。
Digital Roadmapでは、今後のRHELに入る予定の機能、変更、非推奨、削除予定などを確認できます。
これまでだと、リリースノートを読んで初めて気づく変更も多かったと思います。
しかしDigital Roadmapを使うことで、次のような情報を早めに確認できます。
- 次のRHELで何が入りそうか
- どの機能が非推奨になりそうか
- 自社環境に影響する変更はあるか
- 移行計画に入れておくべきものは何か
SIerやインフラ担当の目線では、かなり実用的です。
たとえばお客様に対して、
RHEL 10.2ではこの変更が入りそうです
RHEL 11ではこの技術が変わる可能性があります
今のうちに移行方針を考えた方がよさそうです
といった説明がしやすくなります。
RHELを使う側として、今後はDigital Roadmapを継続的に確認していくことが重要になりそうです。
RHEL 10.2 / 9.8の新機能：AI・自動化・Image Modeが中心
RHEL 10.2 / 9.8で紹介されていた主な新機能は、以下の4つです。
- Goose command-line tool
- RHEL MCP Server
- RHEL upgrade system role
- Sealed Images enabled by Image Mode
一見するとそれぞれ別の機能に見えますが、方向性はかなり一貫しています。
大きくいうと、RHELを AIで支援し、自動化し、セキュアに更新できるOS にしていく流れです。
特に、AIと自動化の領域では、RHELの運用負荷を下げるための仕組みが増えてきています。
たとえば、アップグレード前の診断でエラーや警告が出たときに、それが何を意味するのか、どう直せばよいのかをAIが支援する。
さらに、その対応をAnsibleの自動化に落とし込み、複数台へ展開する。
RHEL 10.2 / 9.8では、こうした運用支援の方向性がかなり強く出ていました。
RHEL MCP Server：RHELを理解したAIエージェントへ
このスライドでは、RHELにAIエージェントをどう取り込んでいくかが説明されていました。
ポイントは、単に「AIチャットをRHELに入れる」という話ではありません。
RHELの運用で管理者が困りがちな調査、診断、アップグレード判断を、AIで支援しようとしている点です。
スライドには、以下の3つの要素が並んでいました。
- Command Line Assistant
- Goose AI Agent
- RHEL MCP Server
Command Line Assistant は、CLI上で使えるRHEL向けのAIアシスタントです。
エラーの意味、確認すべき設定、利用すべきコマンドなどを、ターミナル上で確認できるようにするイメージです。
Goose AI Agent は、オープンソースのAIエージェントです。
Red Hat独自の閉じた仕組みを作り込むというより、OSSのエージェント基盤を取り込んでいく流れは、Red Hatらしいと感じました。
そして特に重要なのが RHEL MCP Server です。
MCP Serverは、AIエージェントがRHELの情報にアクセスするための接続口のようなものです。
たとえばAIエージェントが、以下のような情報を参照できるようになります。
RHELの診断情報
RHELのロードマップ情報
アップグレード時の問題
今後の変更点と自社環境への影響
つまり、AIに一般論を答えさせるのではなく、RHELの情報や状態につないだうえで、管理者の判断を支援する方向です。
また、セッションでは guarded command execution の話もありました。
AIエージェントにコマンド実行まで任せると便利ですが、そのままだと危険です。
そこで、AIが実行しようとする操作をチェックし、危険なコマンドは止める仕組みを入れる、という考え方です。
AI「このコマンドを実行したい」
チェック機構「それは危険なので止める」
AIに運用を丸投げするのではなく、ガードレールを置きながらRHEL運用に取り込んでいく。
このあたりは、エンタープライズLinuxらしい現実的なAI活用だと感じました。
Image Mode / bootc：OSをコンテナのように扱う
次に重要なのが Image Mode / bootc です。
これは、OSをコンテナイメージとして作り、配布し、更新する考え方です。
アプリケーションコンテナではなく、OSそのものをコンテナイメージとして扱います。
従来のOS更新は、稼働中のOSに対してRPMパッケージを更新していく考え方です。
一方、Image Mode / bootcでは、以下のような流れになります。
OSイメージをビルドする
↓
レジストリに置く
↓
サーバーへ配布する
↓
新しいイメージへ切り替える
↓
問題があればロールバックする
つまり、OSを「稼働中に少しずつ変更していくもの」として扱うのではなく、
事前に作り、テストし、配布し、切り替えるものとして扱う方向です。
アプリケーションのCI/CDで当たり前になっている考え方を、OSにも広げていく動きだと理解しました。
この流れを支える機能として、いくつかの改善が紹介されていました。
Pre-download updates
Pre-download updates は、更新用のbootcイメージを事前にダウンロードしておき、メンテナンス時間になったら切り替えるだけにする仕組みです。
従来の更新では、メンテナンス時間中にパッケージやイメージのダウンロードが発生し、その分だけ待ち時間が長くなります。
Pre-download updatesでは、あらかじめ更新イメージを取得しておけるため、メンテナンス時間中の作業を「切り替え」と「再起動」に近づけられます。
事前に更新イメージをダウンロード
↓
メンテナンス時間に切り替え
↓
再起動
↓
問題があればロールバック
大量のサーバーやエッジデバイスを運用している環境では、この「事前に済ませられる」ことの効果は大きそうです。
BCVK
BCVK は、Bootable Containers and Virtualization Kitの略です。
bootcイメージをVMとして起動し、テストしやすくするための仕組みです。
Image Mode / bootcでは、OSイメージを事前に作ります。
そうなると次に必要になるのは、「そのOSイメージがちゃんと起動するのか」「想定した設定になっているのか」を確認する仕組みです。
BCVKを使うことで、bootcイメージを一時的なVMとして起動し、確認しやすくなります。
OSイメージを作る
↓
VMとして起動してテストする
↓
問題なければ配布する
OSにも、ビルド後にテストしてから配布するというCI/CD的な考え方を持ち込もうとしているように見えました。
Efficient bootc image storage
Efficient bootc image storage は、bootcイメージのストレージ効率を改善する取り組みです。
bootcではOSイメージを扱うため、複数世代のイメージを保持したり、コンテナイメージも同じ環境で扱ったりすると、ディスク使用量が気になります。
この改善では、同じバイナリやライブラリを共有することで、ディスク使用量やネットワーク転送量を減らせるという話がありました。
また、同じライブラリを使う複数のコンテナでキャッシュが効きやすくなり、性能面にも良い影響が出る可能性があるとのことでした。
少し低レイヤーな話ではありますが、Image Mode / bootcを大規模に使ううえでは重要な改善だと思います。
Sealed Images：OSイメージの改ざんを防ぐ
Image Mode関連で特に重要だったのが Sealed Images です。
Sealed Imagesは、簡単にいうと、
自社が署名したOSイメージだけを信頼し、起動時・実行時に改ざんされていないことを確認する仕組み です。
スライドでは、以下の要素が紹介されていました。
- Customer-Controlled Signing
- Targeted Trust
- Complete Chain of Trust
- Continuous Runtime Verification
流れとしては、以下のようなイメージです。
自社の鍵でOSイメージに署名する
↓
署名済みイメージだけを信頼する
↓
ハードウェアからOS、アプリまで信頼の連鎖を作る
↓
実行中も改ざんされていないか確認する
Image ModeでOSをコンテナイメージとして扱えるようになると、次に重要になるのは「そのイメージが本当に信頼できるものか」です。
Sealed Imagesは、まさにそこを守るための仕組みです。
ここで重要なのは、Sealed ImagesはConfidential Computingとは目的が違うという点です。
Confidential Computing
→ データや処理内容をインフラから守る
Sealed Images
→ OSやアプリが改ざんされていないことを守る
この2つは競合ではなく、補完関係です。
OSイメージを作り、配布し、切り替える運用が広がるほど、そのイメージの署名や検証は重要になります。
Sealed Imagesは、Image Mode / bootcのセキュリティ面を支える重要な機能だと感じました。
まとめ
このセッションでは、RHEL 10.2 / 9.8の新機能だけでなく、RHEL 11以降に向けた開発と運用の方向性が示されていました。
大きなポイントは、RHELがよりオープンな開発プロセスへ進んでいることです。
Fedora ELN、CentOS Stream、Digital Roadmapを通じて、将来のRHELに入る機能や変更予定を早い段階で確認できるようになり、利用者側も移行計画や影響確認をしやすくなります。
機能面では、AI・自動化・Image Modeが中心的なテーマでした。
RHEL MCP ServerやGooseにより、AIエージェントがRHELの情報と連携し、調査や診断、アップグレード支援に活用される方向が示されています。
また、Image Mode / bootcでは、OSをコンテナイメージとして扱い、ビルド、テスト、配布、切り替え、ロールバックする運用モデルが強化されています。
さらにSealed Imagesにより、署名済みのOSイメージだけを信頼し、実行時の改ざん検知・防止につなげる考え方も示されました。
全体として、RHELは従来の「安定して長く使えるエンタープライズLinux」という価値を維持しながら、AIによる運用支援、イメージベースのOS管理、サプライチェーンセキュリティを取り込む方向に進んでいます。
RHEL 10はその変化の途中段階であり、RHEL 11に向けて、開発プロセスと運用モデルの両方が大きく変わっていくことが分かるセッションでした。