見た目以上のもの：Red Hat Enterprise Linux 10 の舞台裏 (パート 4)

このシリーズでは、Red Hat Enterprise Linux 10 の構築とリリースに関わった人々と計画を取り上げます。構想の初期段階から Red Hat Summit 2025 での発表に至るまで、RHEL 10 がどのようにして実現したのか、現場の声をお届けします。

パート 1 | パート 2 | パート 3

前回の Red Hat Enterprise Linux (RHEL) 10 の誕生についての記事では、テストプロセスや、主要機能 (およびそれらの機能に関するストーリー) がどのように形作られていったのかについて、洞察を得ることができました。パート 4 では、チームがコードフリーズ前にさまざまな機能の最終仕上げに取り組む中で、それらのストーリーがより明確に浮かび上がってきます。

2025 年 (Summit 2025 までの 6 カ月)

Brian Stinson、プリンシパルソフトウェアエンジニア

「最後の追い込みの時期：この段階になると、各チームにとって状況が少し緊迫してきます。なぜなら、『機能の最終調整は完了しているか？』だけでなく、『リリースの一環として必要な基本設定作業をすべて完了できたか？』『パッケージはすべて実装済みか？』『適切なスケジュールで品質保証テストは完了したか？』『フィードバックは収集済みか？』といった点も重要になるからです。コードフリーズに向けて、こうした種類の作業は実際にかなり活発化します。」

Chris Wells、 RHEL ビジネスユニット、プロダクトマーケティング担当シニアディレクター

「このストーリーを取り上げて、エキサイティングなものにする必要があることはわかっていました。でも、今回のリリースに含まれる機能自体を変えるわけにはいかないので、変えられるのは、それらの機能についてどう語るかということだけだと考えました。

そこで私はコロンバスでミーティングを開き、RHEL 10 の主任プロダクトマーケティングマネージャーである Marty Loveless と、そこから車で 1、2 時間のアクロンに住んでいる Scott McCarty に集まってもらいました。彼はその日、車で来てくれました。私たちは会議室にこもり、『どんな角度から物事を語れるだろうか？』についてブレインストーミングを行いました。新しいものに着目し、『何か違った視点はないだろうか？』と考えたのです。」

Major Hayden、シニアプリンシパルソフトウェアエンジニア

「エンジニアリング側でコードを構築していたのは、もう一人の Red Hat 社員と私だったので、彼と作業を分担しました。RAG [検索拡張生成] が最大の課題でした。当初は、PDFファイルをまとめてバケツに入れて、検索すればいい」と考えていましたが、それは間違いでした。

課題の多くは、私たちの多くがベクトルを扱うのが初めてだったことに起因していました。学生時代に微分積分を学んだので、ベクトルがデカルト平面上の線であることは知っていますが、知っているのはそれくらいです。これらの文章がどうやってベクトルになるのか、全く理解できませんでした。そこで私はある日、微分積分を学び直し、「これは実際に何を行っているのか」を理解する必要がありました。

そして、私たちが直面した最大の障害は、質の高い結果が得られないということでした。 

しかし、あるブログ記事か何かで、LLM に顧客の質問をリファイン (洗練) させるよう依頼するという内容を読みました。最終的に、私たちは質問を洗練させるプロセスを構築し、お客様から質問を受け取り、それをLLM に送ります。そして、「この質問は RHEL、Red Hat 製品、または Linux に関するものである可能性があるので、お客様からのこの質問を受け取り、これらのトピックに沿ったキーワードを使用して、より具体的な 5 つの質問に変更できますか？」と依頼します。たとえば、お客様が「SSH 再起動しない」などと言うかもしれません。そして質問を精練をすることによって質問がより具体的になり、RAG コンテンツ内に出現しやすいフレーズが使用されるようになります。そうすることで、ベクトル検索がより多くのドキュメントに一致するようになります。すると突然、より良い結果が得られるようになり始めました。」

Wells

「市場における Red Hat の独自の差別化要因、つまり RHEL 向けの Linux に関する当社のあらゆる知識と専門知識を、Lightspeedを通じて製品化し、アシスタントとして提供できるようになったことが、本当に大きな成果です。これにより、RHEL 10について非常に効果的な方法で説明できるようになりました。」

Stef Walter、Linux Engineering シニアディレクター

「あらゆる分野のお客様 (それも有名な大企業のお客様) が、サポートが開始される前からイメージモードをデプロイしていました。お客様は、『これは素晴らしい、サポートの有無は気にしない』という様子でした。『今すぐデプロイする』と言っていたのです。」

本当に実感が湧いたのは、『驚いたことに、お客様が私たちの対応を待たずに本番環境にデプロイしている』と気づいた時でした。これはお客様の IT プロセスや、彼らが実現しようとしている変革において非常に価値があるため、彼らは私たちを待ってはくれないのです。だからこそ、私たちは彼らに追いつかなければならないのです。」

Wells

「イメージモードに関しては、非常に説得力のあるストーリーがありました」そこで私たちは、『イメージモードを、システムのパッチ適用や更新の別の方法と捉えてみたらどうだろうか？』と考えました。昨年、私たちはイメージモードを、新しいシステムや新しいイメージ、エッジデプロイメントをデプロイするための手段として議論されてきました。もちろん、それらはすべて有効で、良い方法です。 

しかし私たちは、『さらにもう一歩踏み込んだらどうなるだろうか？』と考えたのです。これをエッジにデプロイするのではなく、文字通り本番サーバーのイメージを作成して不変にし、そのようにデプロイしたとしたらどうなるだろうか？』と考えました。そのため、そのサーバーを更新する必要がある場合は常に、イメージを更新するだけで、実質的にシステムの再イメージ化を行うことになります。それは、これまでとは異なるデプロイ方法になります。そうすることで、Linux システム管理における大きな悩みの 1 つである、パッチ適用の手間を解消できます。イメージモードでパッチ管理を行えば、従来のパッケージ方式で行うよりもはるかに簡単かつ迅速で、リスクも大幅に軽減できるからです。」

Summit 2025 での RHEL 10 リリースが目前に迫っています。ここまでは順調に進んできたでしょうか……そうですよね？2026 年の次の投稿では、チームが実際のリリース・メカニズムとプロセスについて詳しく解説します。