Ubuntu 26.04（resolute）の開発; リリースまで一週間、各種インフラステータスの公開とリニューアル

resolute（Ubuntu 26.04）の開発; リリースまで一週間

resolute（Ubuntu 26.04 LTS）のリリースまであと一週間となりました。Beta以降の各種調整が進められ、Checkbox 7.1 [1]などの「間に合わせないといけないソフトウェア」の駆け込み調整が続けられています。

「本体」にあたるソフトウェア以外にも、今回はドキュメントの更新が非常に充実しており、26.04 LTSのセキュリティ関連の新機能まとめがリリースされています。今回からTLS 1.0および1.1がデフォルトでは利用不可になる等、非互換となる要素が多い（そして、そろそろ本格的に準備しなくてはいけない量子暗号の導入や基盤となるソフトウェアの見直しが含まれる）ため、特にUbuntu Serverを利用している場合は一読しておくと良いでしょう。

もっとも、ROCm（+Lemonade）はFFeのキューに入ったばかりで、リリースに対して間に合うのかどうかは絶妙なラインとなっています[2]。これ以外にもValkeyの依存関係の調整やOpenStackパッケージの投入 [3]など、「⁠あとはリリースを待つばかり」というよりは「リリースに間に合わせるための作業」が続けられています。

Ubuntu 26.04 LTSは、4月23日にリリースされる予定です。

各種インフラステータスの公開とリニューアル

Ubuntuのインフラまわりの可視性の不足の解決のために、新しい方針が公開されています。まず最初に、upptimeと呼ばれる各種インフラのuptimeビューが提供されるようになりました。

これはGitHubベースのステータスダッシュボードで、次の動作の組み合わせによって実現されるものです。

GitHub Actionsを使用してエンドポイントに対する定期的なSynthesisチェックを実行する。
GitHub Issuesを使用してインシデントを報告する。
GitHub Pagesを使用してリアルタイムのステータスダッシュボードをホストする。

今後JujuやCanonical Observability Stack（COS）を利用した本格的なオブザーバビリティの実現を目指すという記載が含まれています。「⁠なにかaptの動作がおかしい」という時に手がかりになるページが増えました。

その他のニュース

AMD64,ARM64向けの新しいカーネルフレーバーとして、「⁠linux-nvidia-bos」というものが生成されています。既存のnvidia-bosとの関連性は不明瞭なものの、NVIDIAの提供するNV-Kernelsリポジトリに関連するとみられるコミットがあり、推定としては「NVIDIA BaseOS向け」のものと見られます。

注目すべきセキュリティー的な視点：オープンソースとAIの共存

Claude Mythos Previewがセキュリティの世界に大きな衝撃をもたらしています。「⁠AIによる自動的なPentest」という、想像上の存在が現実のものになり、要求されるセキュリティレベルが大きく書き換わりつつあります。これまで見逃されていたシステムであっても、あっさりとAIによって乗っ取られてしまうようになるでしょう。

……が、この話に取りかかる前に、今回は、オープンソースとAIがどのように共存するのか、という点を考えてみましょう。オープンソースAIというものがそもそもどのように発生するのかという別の問題もありますが、ここでは既存のソースコードに対してAIがどのようにアプローチできるのかということを考えてみましょう。

まず根本的な問題として、クローズドソースとオープンソースの違いがAIにどのように作用するか、という点から始めましょう。クローズドソースのシステムに対してAIは根本的な修正という対応ができません。一方オープンソースであればAIに修正を頼むというアプローチを取ることができます。これはクローズドソースに対する圧倒的な優位性として機能します。実際にPentestをかけられる環境であれば、「⁠この脆弱性を塞いでおいて」とAIに頼むときに、ソースコードレベルで修正するアプローチが現実的になります（クローズドソースのシステムにおいては、「⁠脆弱性が突かれないように前段フィルターを作成する」といった方向になるでしょう⁠）⁠。

「プログラミングは非常にハードルが高い行為なので、ソースが公開されていてもあまり意味がない」という問題がオープンソースの歴史的な泣きどころでしたが、これはAIによってある程度解決されます。一方、「⁠現場」でAIによって修正が加えられたソースコードは無限に散逸し、メインストリームへのマージが困難になる可能性を持っています。

ただし、AIがオープンソースソフトウェアに対して修正を加えた場合、それを中央に集め、集積することは現時点では期待できません（うかつにPull Requestが投げ込まれた場合、完全に破綻することが予想されます⁠）⁠。これは根本的な問題として、オープンソースによって発見されたバグは、それを取り込む能力よりもはるかに豪快に発生するからです。

いわゆるAI Slop問題が、オープンソースの生態系を破壊する可能性があります。あるソースコードを取り込むかどうかは、オープンソースソフトウェアの開発者あるいはメンテナンス者がそれを受け取るかどうか、受け取ってよいかどうかを適切に判断する必要があります。AIが作成する説明は極めて「それらしい」ものの、実際には将来のメンテナンス性を伴っていないことが多々あります。そうした「それらしいが質の低いパッチ」を大量に受け取ってしまった場合、将来的にメンテナンスが不可能になる可能性があります。

また同時に、「⁠見た目それらしいものの、実際には悪意のあるコード」という問題も現実には存在します。AIを利用して大量に発生したコードは、これらを覆い隠す方向に作用してしまいます。AIによって大量にパッチが送られ、そこにはほとんど意味のないものと、意味のあるものと、悪意のあるものが紛れ込んでいる。それでも拾うと爆発する。なかなかに理不尽な構造であると言えるでしょう。もっともこれは、以前からオープンソース開発者が晒されていた現実そのもので、分量が増えることによって、より状況が悪化したというだけの話ではあります。

オープンソースライセンスは、著作権によって配布や改編が制限されることを利用した社会的なハックの一つです。著作権が存在しない場合、いわゆるコピーレフト条項を強制できなくなります。著作権法は人間（自然人）による思想や感情の創作的な表現を保護するものです。そして、AIはいわゆる自然人ではありません。つまり、AIが生成したものには基本的に著作権は生まれません（"A Recent Entrance to Paradise"という作品についての判例がこの論理を補強します⁠）⁠。Ubuntuの壁紙コンテストでも、AIによる生成物を受け入れていません。

つまり、分量の問題に限らず、そもそも「誰かがVibe Codingによって生成したオープンソースソフトウェアのパッチ」を受け入れることができるかどうか、そして受け入れた場合どのようなライセンスになるのかが、今のところ極めて不透明な状態にある、というのが現状です。

現時点では、AIによって増幅された脆弱性報告能力の行き先は、既存の脆弱性報告モデルを用いることになります。一方で、脆弱性レポートやパッチを受け取る能力はそこまで大きくなっていません。この不均衡が大きな問題になる前に、業界全体で対抗できる状態を作る必要があります。