Ubuntu Core 26で2041年まで使える"不変Linux"｜EU CRA対応とTPM/LUKS2鍵管理を読み解く

「Ubuntu Core 26で2041年まで使える"不変Linux"って、業務で使う側にとって何が変わるんだろう？」
2026年5月19日、CanonicalはIoT・組込み向けの最小・不変型ディストリビューション「Ubuntu Core 26」をリリースしました。15年の長期セキュリティ提供、EU Cyber Resilience Act（CRA）への対応強化、そしてTPMで封印したLUKS2鍵管理という、Linux管理者にとって看過できない変更が並びます。

この記事では、Ubuntu Core 26の発表内容を「現役Linuxサーバー管理者の実務」に引きつけて整理します。組込みやIoTを直接担当していない管理者にとっても、EU CRAとTPM/LUKS2の話は、いずれ自分のサーバーOSにも降りてくるテーマです。

Ubuntu Core 26の発表概要｜「不変Linux」を15年支える

Ubuntu Core 26は、Canonicalが2026年5月19日に正式リリースした、IoT・組込み機器向けの最小・不変（イミュータブル）型Linuxディストリビューションです。ベースは2026年4月にリリースされたUbuntu 26.04 LTS（Resolute Raccoon）で、最大15年のセキュリティ提供が約束されており、計算上は2041年まで同じバージョンを安全に運用できる構成になります。

通常のUbuntu Serverと根本的に異なるのは、システム全体を「snap」というパッケージ単位で管理し、ルートファイルシステムを書き換え不可（イミュータブル）にしている点です。OSの更新は差分OTA（Over-The-Air）として配信され、失敗時には前のバージョンに自動ロールバックします。

今回の26では、その不変OSの基盤が大きく強化されました。主な変更点は次のとおりです。
・サポート期間：15年のセキュリティ提供（2041年まで）
・EU CRA対応：CanonicalがManufacturer責任を負い、IEC 62443-4-1とCVE監視に準拠
・暗号化：TPMで封印したLUKS2鍵をヘッダーに直接格納、OP-TEEでARM TrustZoneにも対応
・OTA：更新サイズを最大90%削減、Core base snapは16MB→1.5MBへ縮小
・Livepatch：ARM64で初の再起動不要カーネル更新、AMD64はCore 20以降で公式対応
・Chisel：新ビルドシステムでファイル単位の追跡可能性、ベースイメージを7%削減

EU CRAとは何か｜なぜLinux管理者も知っておくべきか

EU Cyber Resilience Act（CRA、サイバーレジリエンス法）は、EU域内で「デジタル要素を含む製品」を販売する際にサイバーセキュリティ要件を義務化する規則です。IoT機器・産業機器だけでなく、ソフトウェア製品も対象になり、適用は2027年12月から段階的に始まります。

1. CRAが求めるのは「製品ライフサイクル全体での責任」

CRAが従来の規制と違うのは、「製造者（Manufacturer）」が製品の販売後もセキュリティに責任を持つ点です。具体的には次のような義務が課せられます。

・脆弱性発見から24時間以内のENISA（EUサイバーセキュリティ機関）への通知
・既知の脆弱性を含まない状態での出荷
・サポート期間中の継続的なセキュリティ更新提供
・脆弱性対応プロセス（VDP）の整備と公開

このため、Linux搭載のIoT機器・産業機器をEUに輸出する日本企業も、土台となるOSが「CRAに準拠している」ことを示せなければ、出荷自体が止まるリスクがあります。

2. Ubuntu Core 26がCRA上で果たす役割

今回のリリースでCanonicalは、Ubuntu Coreの中核モジュールに関して「Manufacturer責任」を自ら引き受けると宣言しました。具体的には、IEC 62443-4-1（産業用オートメーションのセキュア開発ライフサイクル規格）に準拠した開発プロセス、CVE継続監視、調整された脆弱性開示（CVD）を提供します。

つまり、機器メーカーは「Ubuntu Core部分のセキュリティ責任の一部をCanonicalに移譲できる」構造になります。これは、Linuxディストロが従来「無保証」ベースだったことを考えると、運用側にとって大きな転換点です。

TPM＋LUKS2による鍵管理の刷新｜実装の中身

Ubuntu Core 26で技術的にもっとも重要な変更は、フルディスク暗号化（FDE）の鍵管理方式です。これまでもLUKS2は使われていましたが、26からはTPM（Trusted Platform Module）で封印（seal）した鍵を、LUKS2ヘッダーに直接書き込む構造になりました。

1. 従来方式との違い

従来のTPM＋LUKS構成では、TPMで保護した鍵を別領域（initramfsやEFIパーティション）に置き、ブート時にinitramfs内のスクリプトでTPMから取り出してLUKSに渡す、という構造でした。鍵の取り回しに複数のステージが介在するため、鍵の流用や残存リスクがありました。

Ubuntu Core 26では、TPMで封印された鍵そのものがLUKS2ヘッダー内に格納されます。デバイスの状態（PCR値）と紐づけられているため、TPM以外では復号できず、ブートチェーンに改ざんがあれば自動的に解除を拒否します。

2. ARM TrustZone対応（OP-TEE）

さらに、ARM系プロセッサ向けにはOP-TEE（Open Portable Trusted Execution Environment）を統合し、ARM TrustZone上で鍵の封印・解除を行う構造を取り入れました。これにより、x86のTPM 2.0だけでなく、組込みARM SoCでも同等のハードウェアルートオブトラストを構築できます。

3. 通常のUbuntu Server運用者への影響

Ubuntu Server側でも、Ubuntu 25.10以降で「Snapd FDE」を使ったTPM自動アンロックが順次拡大しています。Ubuntu Core 26の鍵管理方式は、将来のUbuntu Server LTSにも段階的に降りてくると見るのが妥当です。今のうちにTPM 2.0搭載機材でcryptsetup luksDumpの出力を読み、LUKS2ヘッダーの構造に慣れておくと無駄になりません。

OTA更新の最適化とARM64 Livepatch｜運用稼働率の話

Ubuntu Core 26のもう一つの目玉は、運用稼働率に直結する更新まわりの改善です。

項目	Ubuntu Core 24以前	Ubuntu Core 26
OTA更新サイズ	フルイメージ転送に近い	差分配信で最大90%削減
Core base snap	16MB	1.5MB
Livepatch対応	AMD64のみ（Server中心）	ARM64 + AMD64（Core 20以降公式化）
ベースイメージサイズ	従来比100%	Chiselで約7%削減
失敗時の挙動	自動ロールバック	自動ロールバック（継続）

1. Livepatch ARM64対応の意味

Livepatchは、カーネルの脆弱性修正を再起動なしで適用する機能です。これまでAMD64中心でしたが、Ubuntu Core 26からARM64にも展開されました。CRAは「速やかな脆弱性修正の適用」を要求するため、再起動でサービス停止を起こさずに修正を当てられる仕組みは、コンプライアンス上も実利上も大きな意味を持ちます。

2. Chiselビルドシステムによる追跡可能性

Chiselは、Ubuntu Coreイメージを構成するすべてのファイルを「スライス」単位で扱い、どのソースパッケージから来たかを追跡できるビルドシステムです。CRAが求める「ソフトウェア部品表（SBOM）」の生成・脆弱性追跡が、ディストリビューション側で原理的に成立する構造になりました。

競合する不変Linuxとの位置付け｜Fedora IoT、SUSE MicroOSとの比較

Ubuntu Core 26を選定する際、競合となる不変Linuxの主要選択肢は次のとおりです。

項目	Ubuntu Core 26	Fedora IoT	SUSE MicroOS
ベース	Ubuntu 26.04 LTS	Fedora（rpm-ostree）	openSUSE Leap / SLE
更新方式	snap差分OTA	rpm-ostree（イメージ単位）	btrfs snapshot + transactional-update
サポート期間	15年（CRA対応明示）	約13ヶ月（短サイクル）	SLE Micro：10年
商用サポート	Canonical Ubuntu Pro	コミュニティのみ（商用はRHEL系）	SUSE有償
主な用途	IoT・組込み・産業機器	エッジ・実験用途	クラウドエッジ・組込み

長期サポート＋CRA上の「Manufacturer責任の引き受け」を明示している点では、Ubuntu Core 26が現時点でもっとも明確なポジションを取っています。Fedora IoTはRHELの実験場としての性格が強く、長期運用にはRHELやAlmaLinuxへの移行を前提に考える必要があります。SLE Microは商用ライセンスが必要なため、コスト要件次第になります。

Linux管理者として身につけたい確認ポイント

組込み・IoTに直接タッチしていない一般的なLinuxサーバー管理者にとっても、Ubuntu Core 26の動向は「他人事」では済みません。チェックしておきたいポイントを整理します。

1. TPM/Secure Bootの状態を実機で確認できるか

まず手元のサーバーでTPMが利用可能か確認します。

・ls /dev/tpm*でTPMデバイスの存在確認
・tpm2_getcap properties-fixedでTPM 2.0のプロパティ取得
・mokutil --sb-stateでSecure Bootの有効/無効確認

TPMが装着されていても、BIOS（UEFI）で無効化されているケースは多くあります。

2. LUKS2ヘッダーの読み方

既存のサーバーが暗号化されているなら、LUKS2ヘッダーを読み解けるようにしておきます。

・cryptsetup luksDump /dev/sdaXでヘッダー情報を表示
・「Version: 2」を確認、LUKS1ならLUKS2への移行を計画
・cryptsetup convert --type luks2 /dev/sdaXで変換可能（事前バックアップ必須）

3. snapとシステム更新の挙動把握

Ubuntu CoreはsnapベースのOSなので、運用ではsnap管理が中核です。

・snap listで導入済みsnapを確認
・snap refresh --holdで自動更新を一時停止可能
・snap revert <snap名>で前バージョンに戻せる

EU CRA対応で日本企業が抑えるべき実務ポイント

EU CRAは2027年12月から本格適用が始まりますが、日本企業の現場では「自社製品はLinuxを内蔵しているがCRAの対象になるか」がまず分かれ目になります。実務上のチェックポイントを整理します。

1. 対象になるかの一次判定

CRA対象となる「デジタル要素を含む製品」は、ハードウェア・ソフトウェアを問わず、データ処理機能を持つ製品全般です。Linuxを搭載したIoTゲートウェイ、産業用PC、ネットワーク機器、医療機器（独自の規制と二重適用）が広く該当します。

EUに直接出荷していなくても、商社や代理店経由で最終的にEUへ流れる場合は、サプライチェーン上で要件が降りてくる可能性があります。商社の調達担当からSBOMやCVE対応プロセスの提出を求められるケースが、すでに2026年初頭から散見されます。

2. SBOMとVDPの整備

CRAでは、ソフトウェア部品表（SBOM）の維持と、脆弱性開示ポリシー（VDP）の公開が事実上必須になります。Ubuntu Core 26のChiselビルドシステムは、SBOM生成と相性が良く、CycloneDX形式での出力にも対応します。

社内でゼロからSBOMを作るのは現実的でないため、ベースOSがSBOMを出してくれることの意味は大きいです。

3. 脆弱性報告窓口の準備

CRAは、自社製品の脆弱性を「24時間以内にENISAへ通知」する義務を課します。これに対応するには、社内に脆弱性報告窓口（security.txtの公開、メールエイリアス、内部トリアージプロセス）を用意する必要があります。

Ubuntu Core部分の脆弱性はCanonicalが処理してくれますが、自社アプリ・設定起因の脆弱性は自社で受け取る必要があります。

不変Linuxの考え方｜なぜ"書き換え不可"が安全なのか

Ubuntu Coreの「不変（イミュータブル）」設計は、Fedora Silverblue、openSUSE MicroOS、Bottlerocketなどでも採用されている考え方です。共通する利点は次のとおりです。

・改ざん検知が容易：ルートFSが読み取り専用なので、想定外の書き込みは即異常
・更新の原子性：更新は「次世代スロット」に書き込み、再起動で切替
・ロールバックが安全：更新前のスロットが残っているため即座に戻せる
・状態のドリフト防止：各機体で異なる状態（snowflake server）になりにくい

逆に欠点は、「いつものvi /etc/...で設定を書き換える」操作が原則できない点です。設定はsnap configやcloud-init経由で渡す前提に変わるため、運用フローの作り直しが必要になります。

よくある質問｜Ubuntu Core 26の運用判断で迷うポイント

Q1. 既存のUbuntu ServerからUbuntu Core 26に移行できる？

A. 直接の「アップグレード」は想定されていません。Ubuntu CoreはOS構造（snap中心・イミュータブル）が根本的に違うため、Ubuntu Serverの環境をそのまま移すのではなく、対象ワークロードをsnap化して新規にUbuntu Core 26イメージを作る形になります。一般的なWebサーバー・DBサーバーは、引き続きUbuntu Server LTSを使うのが現実的です。

Q2. TPM未搭載の機材ではUbuntu Core 26は使えない？

A. TPM 2.0は推奨だが必須ではありません。TPMなしでもLUKS2＋パスフレーズで暗号化は可能で、Ubuntu Coreの基本機能は利用できます。ただし、CRAが想定する「ハードウェアルートオブトラスト」を満たすにはTPM搭載が前提になるため、新規調達時はTPM 2.0モジュール（fTPMでも可）が載った機材を選びたいところです。

Q3. Ubuntu Pro契約は必須？

A. Ubuntu Core 26自体は無料で利用できますが、Livepatchの利用、商用サポート、CVE対応のSLAなどはUbuntu Pro契約が必要です。CRA対応の文脈で「Manufacturer責任の移譲」を制度的に裏付けたい場合は、Ubuntu Pro契約が事実上の前提と考えられます。

Q4. 2041年までというのは本当に保証される？

A. Canonicalは公式に「15年のセキュリティメンテナンス」を表明しています。ただし、これは法的保証ではなく事業継続前提のコミットメントです。ESM（Expanded Security Maintenance）の運用実績から見て、Ubuntu Core 26も同様の長期サポートが期待できますが、長期運用案件では契約面でも確認しておきたい項目です。

参考書籍｜Linux基礎とサーバー暗号化を体系的に学ぶ

※本セクションには広告（PR）リンクを含みます

TPMやLUKS2の運用は、まずLinuxサーバーの基礎（systemd、initramfs、ブートシーケンス、ファイルシステム）をしっかり押さえてから取り組むのが近道です。Ubuntu Core 26を直接学ぶ書籍はまだ少ないため、Linuxの基礎を底上げする定番書から押さえることをおすすめします。

・Linux教科書 LPICレベル1 Version5.0対応（翔泳社）：Linuxサーバーの基本コマンド・ファイルシステム・ブート処理まで体系的にカバー
・［改訂新版］Linuxエンジニア養成読本（技術評論社）：systemd・コンテナ・自動化など現場感覚で学べる入門書

本記事のまとめ

ポイント	内容
リリース日	2026年5月19日（Ubuntu 26.04 LTSベース）
サポート期間	15年（2041年まで継続提供）
EU CRA対応	CanonicalがManufacturer責任、IEC 62443-4-1準拠、CVE継続監視
鍵管理	TPMで封印したLUKS2鍵をヘッダーに直接格納、OP-TEEでARM対応
OTA更新	最大90%削減、Core base snap 16MB→1.5MB
Livepatch	ARM64初対応、AMD64はCore 20以降で公式化
管理者の準備	TPM/Secure Boot状態確認、LUKS2ヘッダー読解、snap運用慣れ

組込み・IoT向けというラベルが付くと「自分は関係ない」と感じがちですが、Ubuntu Core 26で示された鍵管理・更新最適化・追跡可能性の方向性は、数年内に通常のUbuntu Server LTSにも降りてきます。EU CRAの本格適用は2027年12月以降。それまでに、TPMとLUKS2、不変OSの考え方を一度実機で触っておくことは、20年以上Linuxサーバーを運用してきた経験から言っても、確実に投資価値のある時間の使い方です。

---

• 次のページへ：MySQL 8.0 EOL到来｜Linux管理者のためのMySQL 8.4 LTS移行判断フレーム
• 前のページへ：Linuxサーバー性能ベンチを30秒で取る方法｜Yet-Another-Bench-ScriptでCPU/IO測定
• この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る