Linux on KnightLiブログ

pci=nomsi と pcie_aspm=off の詳解：Linux で SATA 拡張カードが認識されない、ディスクが落ちる、固まるときの切り分け

Sun, 24 May 2026 00:41:23 +0800

Linux / Ubuntu で PCIe SATA 拡張カードを使うと、ディスクが認識されない、しばらく動かすとディスクが落ちる、システムが固まる、PCIe Link Training 付近で起動が止まる、といった問題に遭遇することがあります。JMB585、ASM1166 などの SATA 拡張カードでよく見られ、NAS、小型 PC、産業用 PC、改造マザーボード、安価な変換カード環境では特に起きやすくなります。

pci=nomsi と pcie_aspm=off は、この種の問題を切り分けるときによく使われる Linux カーネルパラメータです。どちらも PCIe に関係しますが、解決する層は異なります。

pci=nomsi は主に 割り込み信号の問題、つまりデバイスが CPU に通知する方法の不安定さを扱います。
pcie_aspm=off は主に PCIe 電源管理の問題、つまりリンクが省電力状態から正常に復帰できない問題を扱います。

この 2 つを同じ種類の対策として扱うと、切り分けが勘頼みになります。症状を見て、割り込み、リンク省電力、ハードウェア本体のどれを優先して疑うべきかを決めるほうが合理的です。

pci=nomsi：Message Signaled Interrupts を無効化する

pci=nomsi は次のように読めます。

PCI：PCI 関連デバイス。
no：無効化。
MSI：Message Signaled Interrupts。

意味は、Linux カーネルに対して PCI デバイスで MSI / MSI-X 割り込みを使わず、従来の INTx 割り込み方式へ戻すよう指示することです。

MSI とは何か

従来、ハードウェアデバイスが CPU に「処理してほしい」と伝えるには、物理的な割り込みピン、つまりレガシー IRQ を使っていました。この方式は使えますが、共有や拡張性には限界があります。

その後、MSI / MSI-X が登場しました。デバイスは物理割り込みピンを必ずしも使わず、特定のメモリアドレスへメッセージを書き込みます。CPU はそのメッセージを受け取り、どのデバイスが割り込みを発生させたかを知ります。現代のシステムでは、MSI / MSI-X はより柔軟で、高並行デバイスにも向いています。

問題は、すべての PCIe 拡張カードのファームウェアが MSI を十分に正しく実装しているわけではないことです。一部の安価なカード、サーバー退役品、ブリッジチップ構成、品質の低い SATA コントローラでは、Linux ドライバ上で MSI メッセージ異常、割り込み喪失、割り込み嵐が起きることがあります。

よくある症状は次のとおりです。

起動中、PCIe 拡張カード検出時に固まる。
SATA 拡張カードがまったくディスクを認識しない。
システムがランダムに固まる。
dmesg に irq xx: nobody cared のようなエラーが出る。
Windows では一見動くが、Linux では不安定。

この問題の核心は、ディスク本体やファイルシステムではなく、デバイスと CPU の間の割り込み通信方式が不安定なことです。

pci=nomsi を追加すると何が起きるか

次を有効にします。

`1`	`pci=nomsi`

これは Linux カーネルに対し、PCI デバイスで高度な MSI メッセージ割り込みを使わせず、従来の INTx 割り込みへ戻すよう指示します。

高スループットや高割り込み頻度のデバイスでは、性能や並行効率が少し落ちる可能性があります。ただし家庭用 NAS、SATA 拡張カード、通常の HDD アレイでは、実感できる影響は小さいことが多いです。価値は、特定のデバイスファームウェアやブリッジチップの MSI 互換性問題を回避し、システムが安定してデバイスを認識し I/O を処理できる点にあります。

簡単に言えば、pci=nomsi は「デバイスが CPU に通知する方法が不安定」な問題を扱います。

pcie_aspm=off：PCIe Active State Power Management を無効化する

pcie_aspm=off は次のように読めます。

PCIe：PCI Express。
ASPM：Active State Power Management。
off：無効化。

意味は、PCIe リンクの省電力機構を無効にし、PCIe リンクを低電力状態に入れないようにすることです。

ASPM とは何か

ASPM は PCIe バスの省電力機構です。システムがある PCIe リンクでしばらくデータ転送がないと判断すると、リンクを L0s や L1 のような低電力状態にできます。再びデータの読み書きが必要になると、リンクを通常状態へ復帰させます。

設計の良いハードウェアでは、この仕組みで消費電力を下げられ、ユーザーはほとんど意識しません。しかし一部の消費者向けマザーボード、小型 PC、産業用 PC、安価な SATA 拡張カード、変換基板、信号品質が弱い構成では、「寝たあとに安定して起きられない」ことがあります。

典型的には、JMB585 や ASM1166 のような PCIe SATA 拡張カードがアイドル後に低電力状態へ入り、次のディスクアクセス時に L1 から復帰する場面です。コントローラ、マザーボード、ライザー、電源、ファームウェアの品質が十分でないと、復帰が遅すぎたり、リンク復帰時に物理層の揺れが起きたりします。Linux カーネルは、そのデバイスが一瞬消えたと判断することがあります。

典型的な dmesg は次のようなものです。

1
2
3

pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
ata1: link is slow to respond, please be patient
ata1: COMRESET failed (errno=-16)

その後、次のような現象が起きます。

ディスクが落ちる。
アレイが degrade する。
ファイルシステムが read-only になる。
NAS サービスが異常になる。
システム I/O が固まる。
再起動すると一時的にディスクが戻る。

厄介なのは、起動時には問題が出ないことも多い点です。一定時間動いた後、アイドルからの復帰時、または負荷の切り替わりで突然発生します。

pcie_aspm=off を追加すると何が起きるか

次を有効にします。

`1`	`pcie_aspm=off`

これはカーネルに対し、システム全体の PCIe ASPM 省電力機能を無効化するよう指示します。PCIe リンクはアイドルでも負荷中でも、できるだけ通常の接続状態を維持し、低電力スリープへ入らないようになります。

副作用は消費電力が少し増えることです。デスクトップ、NAS、小型 PC では、数百 mW から 1、2 W 程度のことが多いです。ノート PC ではバッテリー駆動時間に影響する可能性があります。その代わり、PCIe リンクのスリープと復帰が原因のディスク脱落、リンクトレーニングエラー、物理層エラーを減らせます。

簡単に言えば、pcie_aspm=off は「PCIe リンクが寝たあと安定して起きない」問題を扱います。

2 つのパラメータの違い

この 2 つは異なる問題を解決します。

パラメータ	解決する問題	よくある症状	主な副作用
`pci=nomsi`	割り込み信号の衝突、MSI / MSI-X 互換性不良	起動時に固まる、ディスクを認識しない、`irq xx: nobody cared`、システムフリーズ	高並行時に割り込み効率が少し下がる可能性
`pcie_aspm=off`	PCIe 省電力復帰失敗、リンク信号不安定	起動直後は正常、しばらくしてディスクが落ちる、`PCIe Bus Error`、`COMRESET failed`	消費電力が少し増える、ノート PC の駆動時間が少し短くなる

両者は代替関係ではありません。一方は割り込み、もう一方はリンク電源管理を扱います。

起動段階で固まる、デバイスがまったく認識されない場合は、まず pci=nomsi を疑います。起動は正常だがしばらくしてディスクが落ちる、または dmesg に PCIe Physical Layer、COMRESET、link is slow to respond のような情報がある場合は、まず pcie_aspm=off を疑います。

2 つを一緒に入れるべきか

多くの NAS ユーザーは次をまとめて追加します。

`1`	`pci=nomsi pcie_aspm=off`

これは確かに素早い切り分け方法です。JMB585、ASM1166、小型 PC、変換カード、電源やケーブルが不確かな環境では特に有効です。MSI 互換性問題と ASPM 復帰問題を同時に回避できます。

ただし、切り分けとしては症状とログを先に記録することを勧めます。

割り込みエラーや起動時フリーズなら、まず pci=nomsi。
起動後のディスク脱落、PCIe Bus Error、COMRESET なら、まず pcie_aspm=off。
すぐ安定稼働へ戻したい場合は両方入れ、安定後に分けて検証する。

こうすると、実際にどの種類の問題だったか分かり、後でカード、スロット、マザーボード、BIOS 設定を変えるときの判断材料になります。

Ubuntu / Debian で恒久的に有効化する方法

Grub 設定ファイルを編集します。

`1`	`sudo nano /etc/default/grub`

次の行を探します。

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"`

引用符の中にパラメータを追加し、空白で区切ります。

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi pcie_aspm=off"`

保存して終了します。Nano なら Ctrl+O で保存し、Enter で確定し、Ctrl+X で終了します。

Grub を更新して再起動します。

1
2

sudo update-grub
sudo reboot

再起動後、現在のカーネル起動パラメータを確認します。

`1`	`cat /proc/cmdline`

出力に pci=nomsi と pcie_aspm=off が含まれていれば、現在の起動で有効になっています。

ほかに確認すべきこと

この 2 つのパラメータは有用ですが、すべてのディスク脱落問題を解決する万能薬ではありません。SATA 拡張カードや NAS のディスク脱落を調べるときは、次も確認しましょう。

SATA データケーブルが緩んでいないか、品質が悪くないか。
複数 HDD の同時スピンアップ時に電源が安定しているか。
PCIe スロットの接触不良がないか。
拡張カードが過熱していないか。
BIOS に PCIe ASPM、Above 4G Decoding、PCIe speed などの関連設定があるか。
SATA 拡張カードのファームウェアに既知の問題がないか。
システムログにディスク本体の bad sector、I/O error、SMART 警告がないか。

ディスクの SMART がすでに異常を報告していたり、電源が不安定だったりする場合、カーネルパラメータだけでは根本解決できません。

まとめ

pci=nomsi と pcie_aspm=off は、Linux で PCIe SATA 拡張カードが不安定なときによく使われますが、扱う層は異なります。

pci=nomsi：MSI / MSI-X を無効化し、割り込み通信の互換性問題を回避する。
pcie_aspm=off：PCIe ASPM を無効化し、リンク省電力後の復帰失敗を避ける。

JMB585、ASM1166、NAS、小型 PC、安価な PCIe 拡張カードでは、この 2 つが効果を出すことがあります。より確実なのは、まず dmesg を見て、割り込み問題なのかリンク省電力問題なのかを判断し、単独または併用を決めることです。

これらは切り分け用の道具であり、ハードウェア品質の代わりではありません。追加後に安定するなら、中断互換性または PCIe 電源管理が原因である可能性が高いです。まだディスクが落ちるなら、電源、ケーブル、冷却、ディスク健康状態、拡張カード本体を引き続き確認する必要があります。

CVE-2026-43494 / PinTheft：Linux RDS と io_uring が組み合わさるローカル権限昇格リスク

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 は Linux カーネルのローカル権限昇格リスクです。関連する悪用チェーンは PinTheft とも呼ばれています。重要なのはリモート入口ではなく、低権限のローカルユーザーが RDS zerocopy、io_uring fixed buffer、読み取り可能な SUID-root プログラム、そして該当するカーネルバージョンを同時に満たせるかどうかです。

まず番号の扱いを整理しておきます。Unclecheng-li/poc-lab リポジトリのディレクトリ名は CVE-2026-43494 PinTheft ですが、README のタイトルには QVD-2026-27616 - PinTheft も書かれています。公開 CVE エントリと第三者アドバイザリを見る限り、CVE-2026-43494 は Linux kernel RDS zerocopy において op_nents が正しくリセットされず、double-free / 参照カウント異常につながる問題を指します。QVD-2026-27616 は Qianxin 側のリスクアドバイザリ番号に近いものと考えられます。実際の調査では両方の識別子を記録しつつ、ディストリビューションのセキュリティ告知とカーネルパッチ状況を基準にしてください。

脆弱性の核心は何か

この問題は Linux RDS、つまり Reliable Datagram Sockets の zerocopy 送信パスにあります。公開情報で挙げられている主要な関数は次の通りです。

1
2

rds_message_zcopy_from_user()
rds_message_purge()

rds_message_zcopy_from_user() の中で iov_iter_get_pages2() が失敗すると、すでに pin されたページがエラーパスで解放されます。しかし関連する op_nents の状態が正しくクリアされないため、後続の rds_message_purge() が残ったエントリに基づいてもう一度解放してしまう可能性があります。結果として、同じページ参照群のカウントが過剰に減り、悪用可能な参照カウントエラーになります。

RDS の bug だけを見れば、これはカーネル内部のメモリ管理におけるエラーパス問題です。PinTheft が危険なのは、この問題を io_uring の固定バッファ機構につなげる点にあります。io_uring は古い struct page * を保持したままですが、そのページ自体はすでに解放され、別用途に再割り当てされています。公開 PoC はこの状態を SUID-root プログラムの page cache 上書きへ誘導し、最終的にローカル権限昇格に到達します。

なぜ PinTheft と呼ばれるのか

io_uring REGISTER_BUFFERS はユーザーページを固定します。通常のページに対して、FOLL_PIN は単純な参照カウントの 1 増加ではなく、大きな bias によって page refcount を増やします。公開 PoC では GUP_PIN_COUNTING_BIAS = 1024 という概念が使われています。

PinTheft という名前は、攻撃チェーンが RDS zerocopy の失敗パスを通じて、これらの pin 参照を何度も「盗む」ことを意味します。参照が消費された後も、io_uring は自分が有効なページを保持していると考えますが、その物理ページはすでに解放され、page cache に再利用され得ます。

この種の脆弱性は「ディスク上の /usr/bin/su を直接書き換える」と誤解されがちです。より正確には、悪用チェーンが上書きしようとするのはメモリ上の page cache です。ファイル本体がディスクへ書き戻されるとは限りませんが、カーネルがその SUID プログラムを実行するとき、汚染されたページキャッシュから命令を読み出し、攻撃ペイロードを実行する可能性があります。

発火条件は広くない

これは「任意の Linux サーバーをリモートから攻撃できる」タイプの脆弱性ではありません。公開情報によると、悪用チェーンは少なくとも次の条件に依存します。

カーネルで CONFIG_RDS と CONFIG_RDS_TCP が有効。
システムで CONFIG_IO_URING が有効で、kernel.io_uring_disabled=0。
rds / rds_tcp モジュールがすでにロード済み、または低権限ユーザーが自動ロードを誘発できる。
/usr/bin/su、/usr/bin/passwd、/usr/bin/pkexec など、読み取り可能な SUID-root バイナリがローカルに存在する。
公開 PoC は比較的新しい IORING_REGISTER_CLONE_BUFFERS API にも依存する。CloudLinux の分析では、公開 PoC は kernel 6.13 以降により近い形だと説明されている。

このうち一つでも欠ければ、公開されている悪用経路は途切れます。たとえば多くの RHEL 系ディストリビューションは標準で RDS をコンパイルしておらず、古い Ubuntu カーネルには PoC が必要とする io_uring clone buffer API がない場合があります。また、一部の環境では非特権ユーザーによる RDS モジュールの自動ロードが制限されています。

1 分でできる確認

まずカーネル設定を確認します。

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

次に io_uring が無効化されているか確認します。

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

よくある値は次のように見ます。

0：使用可能で、露出面が最も大きい。
1：非特権ユーザーの利用を制限。具体的な挙動はカーネルバージョンとディストリビューションの方針による。
2：io_uring を無効化。

RDS モジュールが存在し、ロード可能かも確認します。

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

CONFIG_RDS が not set の場合、またはシステムに rds_tcp モジュールがまったくない場合、通常はこの bug に到達できません。逆に RDS が利用可能で、io_uring が無効化されておらず、比較的新しい汎用カーネルを使っている場合は、ディストリビューションの修正状況を優先して確認すべきです。

優先して確認したいマシン

次の環境を優先してください。

複数ユーザーの Linux ホスト、教育用マシン、踏み台、共有開発機。
コンテナホスト。特に信頼できないローカルユーザーを許可する環境や、コンテナ脱出面が緩い環境。
Arch のような rolling distribution など、新しめの mainline / rolling kernel を使うデスクトップやサーバー。
HPC、Oracle RAC、その他 RDS を実際に使う可能性のある場面。
非特権ユーザーが大量のローカルコードを実行できる CI worker、ビルドマシン、実験環境。

通常の Web サーバーで、管理されたサービスアカウントだけがアプリケーションを実行し、RDS も有効でない場合、実際のリスクはかなり下がります。ただし「かなり低い」は「対応不要」ではありません。カーネルのローカル権限昇格では、攻撃者がまず Web、SSH、CI、コンテナ、アプリケーション脆弱性などで低権限を得て、その後ローカル bug で制御範囲を広げる、という流れが典型です。

一時的な緩和策

正式な修正は、引き続きディストリビューションのカーネル更新を基準にしてください。パッチ、バックポート版、影響範囲は Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、Arch、クラウドベンダー、コンテナベースイメージ提供元などの各セキュリティ告知で確認する必要があります。上流のバージョン番号だけで判断しないでください。

パッチ待ち、またはすぐにカーネルを再起動できない場合は、環境に応じて一時対策を選べます。

# 業務が RDS に依存していない場合、関連モジュールのロードをブロックする
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

業務が io_uring に依存していない場合は、無効化または制限も検討できます。

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

永続化するには、対応する /etc/sysctl.d/*.conf に設定を書き込みます。ただしこの手順は慎重に扱う必要があります。現代的なデータベース、プロキシ、ランタイム、高性能 I/O プログラムは io_uring を使っている可能性があります。本番環境で変更する前に、業務依存を確認してください。

修正後の検証

カーネルを更新した後は、パッケージマネージャーの成功表示だけで済ませないでください。次の三つを確認することを推奨します。

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

ディストリビューションの告知で CVE-2026-43494 が修正済みと明記されていれば、uname -r が最新の上流版に見えなくても、安定版カーネルにバックポート済みの可能性があります。逆に、カーネルの入手元が自前ビルド、第三者リポジトリ、クラウドマーケットプレイスイメージ、コンテナホストテンプレートの場合は、パッチ commit とビルド時刻を引き続き照合してください。

参考情報

最近の Linux ローカル脆弱性 4 件の影響整理：Copy Fail、Dirty Frag、Fragnesia、ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

最近、Linux エコシステムでは注目度の高いローカルセキュリティ問題が相次いでいる。個別に見ると、暗号インターフェース、ネットワーク/IPsec 経路、ページキャッシュ処理、ptrace アクセスチェックなど、発生箇所は異なる。だがまとめて見ると、運用上の教訓は同じだ。攻撃者が低権限のローカル実行点を得た時点で、Linux ホスト、コンテナノード、CI マシン、マルチユーザーサーバーのリスクは大きく増える。

この記事では各脆弱性の技術詳細を繰り返さず、実環境への影響を整理し、詳しい解説としてサイト内の 4 本の記事へリンクする。

4 つの問題は何に影響するのか

最近特に追うべきリスクは次の 4 つだ。

Copy Fail（CVE-2026-31431）：低権限のローカルユーザーがカーネル暗号関連経路を通じてページキャッシュに影響し、権限を拡大する可能性がある。
Dirty Frag（CVE-2026-43284 / CVE-2026-43500 関連）：xfrm/ESP、RxRPC などのネットワークおよびカーネルデータ経路にリスクが集中し、侵害後の段階で危険性が高い。
Fragnesia（CVE-2026-46300）：Dirty Frag に近く、XFRM ESP-in-TCP、共有 fragment、ページキャッシュ書き込みリスクをめぐる問題。
ssh-keysign-pwn（CVE-2026-46333）：直接 root shell を得るタイプではなく、SSH ホスト秘密鍵や /etc/shadow などを読まれる可能性があるローカル情報漏えいリスク。

この 4 種類は入口が異なり、緩和策も完全には同じではない。Copy Fail を処理したから Dirty Frag と Fragnesia も安全とは言えない。ネットワークモジュールの一部を無効化したから ssh-keysign-pwn の情報漏えいリスクが消えるわけでもない。

Copy Fail：コンテナと CI ノードの優先度が高い

Copy Fail の重要な影響は「アプリが落ちる」ことではなく、低権限の実行能力が root 権限に変わる可能性があることだ。特に影響が大きいのは次の環境である。

ユーザーがコードをアップロードまたは実行できる CI/CD ノード。
信頼できないワークロードを動かすコンテナホスト。
開発・テスト機、踏み台、共有サーバー。
古いカーネルを使い、パッチ適用の遅いクラウドホスト。

Copy Fail が危険なのは、攻撃のハードルが比較的低く、コンテナ環境と重なりやすいためだ。多くのチームはコンテナを強い隔離境界のように扱うが、通常のコンテナはデフォルトでホストカーネルを共有している。攻撃者がコンテナ内で shell を得られるなら、カーネル LPE によってコンテナ内の問題がホスト全体の問題に拡大する可能性がある。

詳細解説：Copy Fail CVE-2026-31431：Linux カーネルのファイルコピー経路におけるコンテナエスケープリスク。

Dirty Frag：侵害後の権限拡大装置

Dirty Frag は、攻撃者がシステムに入った後の権限拡大ツールに近い。典型的なリモート未認証脆弱性ではなく、通常は弱いパスワード、WebShell、低権限サービスアカウント、コンテナタスクなどを通じて、すでにローカル実行能力を得ていることが前提になる。

実際の影響は主に次の通りだ。

侵害済みの低権限アカウントが root になる可能性がある。
コンテナ内の低権限実行点がホストを脅かす可能性がある。
IPsec、ESP、RxRPC、関連するカーネルネットワーク機能を使うシステムは、パッチと一時緩和を慎重に評価する必要がある。
セキュリティチームは境界防御だけでなく、侵害後の権限昇格チェーンも見る必要がある。

Dirty Frag は、ローカル権限昇格が最初の入口でなくても、侵入がどこまで広がるかを決め得ることを示している。低権限の足場があれば、攻撃者はカーネルバグを探して最高権限へ進もうとする。

詳細解説：Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド。

Fragnesia：同系統の攻撃面は一度では片付かない

Fragnesia が重要なのは、Dirty Frag 周辺の攻撃面が単発の孤立した問題ではないことを示している点だ。あるバグが修正されても、隣接経路、似たデータ構造、関連モジュールの組み合わせに新しい利用可能な点が残る可能性がある。

運用への影響は主に次の通りだ。

脆弱性名だけで一度きりの対応をするのではなく、攻撃面として継続的に確認する。
esp4、esp6、rxrpc、XFRM、ESP-in-TCP などの関連経路を、実際の業務依存と照らして評価する。
関連するネットワーク機能を使っていないなら一時的な無効化を検討できるが、VPN、IPsec、トンネル、内部ネットワークに影響しないか先にテストする必要がある。
ページキャッシュ汚染型のリスクは、ファイル自体は変わっていないように見えても実行経路が影響を受ける、という検知の盲点を作り得る。

企業にとって最大の教訓は、パッチ管理を単一 CVE だけで見ないことだ。より安全なのは、サブシステムと攻撃面を軸に棚卸しし、どのマシンが関連機能を露出しているのか、どの業務が本当にそのモジュールを必要としているのかを確認することだ。

詳細解説：Fragnesia (CVE-2026-46300)：Linux カーネルローカル権限昇格の影響と緩和。

ssh-keysign-pwn：直接 root でなくても危険

ssh-keysign-pwn は前の 3 件とは性質が異なる。直接 root shell を取る脆弱性ではなく、ローカルの機密情報漏えいに近い。しかし実際の攻撃では、機密情報の漏えいがより深刻な結果につながることが多い。

主な影響は次の通り。

SSH host private keys が漏えいすると、ホスト ID の信頼性に影響する可能性がある。
/etc/shadow などのファイルを読まれると、オフラインクラッキングやアカウント乗っ取りにつながる可能性がある。
マルチユーザーサーバー、踏み台、ビルドマシン、共有開発機のリスクが高い。
攻撃者がすぐに権限昇格しなくても、後続の横展開に使える認証情報を得る可能性がある。

この種の問題は、直接 root shell ほど派手ではないため過小評価されやすい。だが企業環境では、鍵やパスワードハッシュの漏えいは長い後処理を意味する。SSH ホスト鍵のローテーション、信頼関係の確認、アカウントパスワードの確認、ログインログ監査が必要になる可能性がある。

詳細解説：ssh-keysign-pwn（CVE-2026-46333）解説：Linux ローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク。

共通の影響：コンテナ隔離を強い境界と見なせない

この 4 件を合わせると、最も直接的な影響は、通常のコンテナ隔離は仮想マシン隔離ではないという再確認だ。

Docker、containerd、Kubernetes は namespace、cgroup、capabilities、seccomp、AppArmor、SELinux などで攻撃面を減らすが、通常はホストカーネルを共有している。脆弱性が共有カーネルにあるなら、コンテナ内の低権限実行点が攻撃の入口になる。

高リスク環境では次を確認すべきだ。

信頼できないコードを共有ホスト上で実行していないか。
コンテナがデフォルトで root ユーザーとして動いていないか。
不要な capabilities を付与していないか。
seccomp ポリシーが広すぎないか。
マルチテナントワークロードを gVisor、Kata Containers、Firecracker microVM、専用 VM、専用ノードへ移すべきか。

CI/CD プラットフォームは特に注意が必要だ。ビルドジョブは外部コード、依存関係のインストールスクリプト、テストスクリプト、一時バイナリを自然に実行する。これらが長期稼働サービスとホストを共有している場合、1 つのローカル権限昇格が大きなインフラに波及する可能性がある。

共通の影響：パッチは「実行中のカーネル」まで届く必要がある

Linux カーネルのパッチ適用でよくある誤解は、パッケージがインストールされたことと、マシンが修正済みカーネルで動いていることを混同することだ。

運用では少なくとも 3 点を確認する。

`1`	`uname -a`

現在実行中のカーネルを確認する。

`1`	`dpkg -l \| grep linux-image`

RHEL 系ディストリビューションでは次のように確認する。

`1`	`rpm -qa \| grep kernel`

インストール済みカーネルパッケージを確認する。

最後に、マシンが修正済みカーネルで再起動済みかを確認する。すぐ再起動できない重要サービスでは livepatch、ホットパッチ、短期隔離を検討する。ただし一時緩和を最終修正と考えてはいけない。

共通の影響：攻撃面最小化はモジュールと syscall まで具体化する

今回の経路は、Linux の堅牢化が「更新する」「ファイアウォールを入れる」だけでは不十分であることを示している。

より具体的な確認項目は次の通り。

AF_ALG / algif_aead を業務で使っているか。
XFRM、ESP、ESP-in-TCP、IPsec が VPN、トンネル、セキュリティゲートウェイに必要か。
RxRPC が必要か。
非特権 user namespace を有効にする必要があるか。
コンテナが広すぎる socket タイプを作成できるか。
ptrace アクセスポリシーが緩すぎないか。

業務上不要な機能であれば、モジュール無効化、sysctl 調整、seccomp の強化、capabilities の削減を評価できる。本番環境にコマンドをそのまま貼り付けるのではなく、依存関係を棚卸しし、段階的に展開するべきだ。

推奨される対応順序

第一に、ローカルコード実行が露出している高リスクマシンを優先して修正する。

コンテナホスト。
CI/CD runner。
踏み台。
マルチユーザーサーバー。
外部公開サービスのホスト。
信頼できないプラグイン、スクリプト、拡張を動かすシステム。

第二に、ディストリビューションのアドバイザリと実際の実行中カーネルを確認する。上流のバージョン番号だけを見てはいけない。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、SUSE、openEuler などはセキュリティ修正を backport することがある。

第三に、コンテナ実行ポリシーを締める。非 root ユーザー、最小 capabilities、no-new-privileges、読み取り専用ファイルシステム、明示的な seccomp と AppArmor/SELinux ポリシーを優先する。

第四に、鍵と認証情報のリスクを確認する。特に ssh-keysign-pwn が関係する環境では、SSH host key、/etc/shadow、踏み台の認証情報、CI secrets のローテーションが必要か評価する。

第五に、監視を補う。異常な root shell、不審なローカル LPE PoC、重要ファイルの変更、異常な ptrace 動作、コンテナプロセスによるホストパスへのアクセス、CI ノードからの異常なネットワーク接続を重点的に見る。

結論

この 4 件の要点は「Linux が安全でなくなった」ではなく、「デフォルトの信頼だけでは足りなくなった」だ。

Linux は今も透明で、修正でき、切り詰められ、堅牢化できる主流システムである。しかしコンテナ、CI、マルチテナント、AI による自動コード実行が広がる環境では、低権限の実行点を小さな問題と見なせなくなっている。カーネルに利用可能なローカル権限昇格や機密情報漏えいのバグがあれば、局所的な侵入はホスト制御、認証情報漏えい、横展開につながり得る。

より現実的な対応は、この 4 件を警告として受け止めることだ。パッチを早く適用し、再起動済みカーネルを確認し、モジュールは必要なものだけ有効化し、コンテナを締め、鍵をローテーションできるようにし、マルチテナントの隔離レベルを再評価する。

サイト内の関連解説:

ssh-keysign-pwn（CVE-2026-46333）解説：Linux のローカル情報漏えい、SSH ホスト鍵、/etc/shadow のリスク

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn は、Linux kernel の __ptrace_may_access() のロジック問題をめぐって公開された一連の利用経路で、CVE 番号は CVE-2026-46333 です。リモートから未認証で悪用できる脆弱性ではなく、直接 root shell を得るものでもありません。それでもリスクは高く、ローカルの低権限ユーザーが、本来アクセスできない root 所有の機密ファイル、たとえば SSH ホスト秘密鍵や /etc/shadow を読み取れる可能性があります。

運用上の重点は PoC の再現ではありません。影響を受けるマシンを特定し、カーネルを更新し、再起動して修正済みカーネルで起動し、必要に応じて SSH host keys のローテーションやパスワードリセットを行うことです。

まず結論

この脆弱性は高い優先度で対応すべきです。理由は次の 4 つです。

root 権限は不要で、ローカルの低権限ユーザーから発火できます。
公開 PoC が存在し、悪用のハードルが下がっています。
対象は通常ファイルではなく、SSH ホスト秘密鍵や /etc/shadow になり得ます。
修正にはカーネルパッチと再起動が必要で、パッケージ更新だけでは不十分です。

複数ユーザー、ローカル shell、共有ホスト、CI runner、コンテナホスト、学生用端末、踏み台サーバー、または完全には信頼できないローカルユーザーがいるサーバーでは、優先的に対応してください。

脆弱性の概要

Qualys は 2026 年 5 月 15 日、oss-security でこの問題を公開しました。Qualys はそれ以前に Linux kernel の __ptrace_may_access() ロジック問題を security@kernel.org に報告しており、上流修正は Linus によってマージ済みでした。その後、公開 exploit コードが現れたため、Qualys は情報を oss-security に投稿しました。

その後 Linux kernel CVE チームがこの問題に CVE-2026-46333 を割り当てました。NVD ページではソースが kernel.org とされ、問題説明はカーネルコミット ptrace: slightly saner 'get_dumpable()' logic に対応しています。

簡単に言えば、この脆弱性はプロセス終了経路にあります。一部の特権プロセスが終了中の場合、対象タスクがすでに mm を持たないため、カーネル内の ptrace アクセスチェック関連ロジックが、本来依存すべき dumpable チェックを迂回してしまう可能性があります。攻撃者は非常に狭い競合ウィンドウで、終了中の特権プロセスがまだ開いているファイルディスクリプタを取得できます。

これが ssh-keysign-pwn と呼ばれる理由です。公開された利用経路の一つは ssh-keysign を使い、SSH host private keys を読み取るものです。

SSH ホスト秘密鍵と /etc/shadow が読まれる理由

この問題の本質はローカル情報漏えいです。特権プログラムの終了過程で「メモリ記述子は切り離されたが、ファイルディスクリプタはまだ閉じられていない」時間差を悪用します。

AlmaLinux のアドバイザリはリスクを明確に説明しています。特権プログラムが権限を落とす前に機密ファイルを開いており、攻撃者が終了ウィンドウ中に対応するファイルディスクリプタを取得できれば、その機密ファイルを読み取れる可能性があります。

公開議論でよく挙がる対象は次の 2 つです。

ssh-keysign：/etc/ssh/ssh_host_*_key のような SSH ホスト秘密鍵に関係する可能性があります。
chage：/etc/shadow に関係する可能性があります。

SSH ホスト秘密鍵が漏えいすると、攻撃者はそのホストになりすまし、SSH のホスト ID 信頼を損なう可能性があります。/etc/shadow が漏えいすると、攻撃者はパスワードハッシュをオフラインで解析し、後続の侵害を広げることができます。

そのため、これは「直接 root shell」ではなくても高優先度で扱うべき問題です。

影響範囲の判断

上流の観点では、これは Linux kernel の脆弱性です。NVD の記録では、この問題は 2026 年 5 月 15 日に NVD データセットへ追加されており、その時点では CVSS スコアは付与されていませんでした。

ディストリビューションごとの状態は、それぞれのアドバイザリで確認してください。

AlmaLinux 8、9、10 は対応情報を公開し、2026 年 5 月 16 日の更新で patched kernels が本番リポジトリに入ったと説明しています。
Debian Security Tracker は bullseye、bookworm、trixie、sid などの vulnerable/fixed 状態と fixed versions を掲載しています。
その他のディストリビューションでは、Ubuntu、Red Hat、SUSE、Arch、Alpine などの公式セキュリティページや更新リポジトリを確認してください。

カーネルの上流バージョン番号だけで安全かどうかを判断しないでください。ディストリビューションは修正を backport するため、同じ上流バージョンに見えても、配布元によってパッチ状態が異なる場合があります。

優先的に対応すべきマシン

リスク順に対応するなら次の順序を推奨します。

複数ユーザーサーバーと共有ホスト。
通常の shell アカウントがある踏み台、教育用端末、開発機。
CI runner、ビルドマシン、ホスティング基盤ノード。
コンテナホストと仮想化ホスト。特に完全には信頼できない workload が共存する環境。
公開サービス用マシン。脆弱性自体はローカルアクセスを必要としますが、Web/RCE/弱いパスワードで低権限の足場が得られるとリスクが重なります。

純粋な単一ユーザーデスクトップのリスクは相対的に低めですが、システム更新で修正することを推奨します。ブラウザ、開発ツール、スクリプト、サードパーティソフトウェアを通じたローカル低権限コード実行は珍しくないためです。

修正方針

最優先の修正は、ディストリビューションが提供する修正済みカーネルをインストールし、再起動することです。

コマンドはディストリビューションごとに異なりますが、原則は同じです。

パッケージメタデータを更新する。
CVE-2026-46333 修正を含む kernel パッケージをインストールする。
再起動して新しいカーネルで起動する。
uname -r とディストリビューションのセキュリティアドバイザリで、実行中カーネルが修正済みか確認する。

AlmaLinux のアドバイザリでは、本番リポジトリに修正済みカーネルが提供されており、通常の dnf upgrade と再起動で対応できるとされています。Debian tracker も複数ブランチの fixed versions を掲載しています。

注意点として、新しい kernel パッケージをインストールしただけで再起動しない場合、古い脆弱なカーネルがまだ動作しています。

一時的な緩和策：ptrace_scope を厳しくする

すぐに再起動できない場合は、まず Yama の ptrace_scope を厳しくしてください。

Qualys は oss-security の後続返信で、/proc/sys/kernel/yama/ptrace_scope を 2（admin-only attach）または 3（no attach）に設定すると、既知の公開利用経路を阻止できると確認しています。ただし理論上は別の利用方法が存在し得るとも述べており、これは修正ではなく緩和策です。

一時設定は次の通りです。

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

永続化する場合は sysctl 設定に書き込みます。

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 は ptrace attach を無効化するため、gdb や strace -p などのデバッグに影響する可能性があります。本番環境でデバッグが必要なら 2 を検討してください。どちらを選んでも、カーネル更新と再起動は早めに計画すべきです。

SSH ホスト鍵をローテーションすべきか

脆弱性公開前後に次の条件があったマシンでは、保守的に対応することを推奨します。

信頼できないローカルユーザーがいる。
共有ホスト、またはコンテナ/CI のマルチテナント環境である。
Web 脆弱性、弱いパスワード、サプライチェーンスクリプトなど、攻撃者にローカル足場を与え得る要素がある。
ログに不審なローカルプロセス、異常なデバッグ挙動、公開 PoC ファイルがある。
修正前に長時間露出していた。

保守的な対応には次が含まれます。

修正と再起動後に SSH host keys をローテーションする。
既知ホスト指紋管理システムを更新する。
そのホスト指紋に依存する自動化システムへ通知する。
SSH 接続アラートを確認し、正当な指紋変更を中間者攻撃と誤認しないようにしつつ、本当のリスクを見逃さない。

/etc/shadow が漏えいした疑いがある場合は、パスワードリセット、弱いパスワードの禁止、古いハッシュがオフライン解析可能かどうかの確認も検討してください。

監視すべきもの

この種の脆弱性は利用ウィンドウが短く、従来のログに完全には残らない可能性があります。それでも次の点は確認できます。

通常ユーザーディレクトリに ssh-keysign-pwn、chage_pwn、または類似 PoC ファイルがないか。
短時間で見慣れない C プログラムをコンパイルするなどの不審なコンパイル行為。
/etc/ssh/ssh_host_*_key や /etc/shadow への異常アクセスの兆候。
異常な pidfd_getfd、ptrace、デバッガ関連の挙動。
外部システムから SSH ホスト指紋異常が報告されていないか。

これらのシグナルは悪用を証明するものではなく、存在しないからといって悪用されていない証明にもなりません。最優先事項は、パッチ、再起動、認証情報のローテーション、リスク隔離です。

よくある誤解

1 つ目の誤解：これは OpenSSH のリモート脆弱性ではありません。名前に ssh-keysign が入っていますが、根本原因は Linux kernel の ptrace アクセスチェックロジックであり、sshd のリモート認証フローではありません。

2 つ目の誤解：ローカルユーザーがいなければ完全に安全、というわけではありません。確かにローカル実行条件は必要ですが、実際の攻撃チェーンでは Web サービス、CI、スクリプト、弱いパスワード、コンテナエスケープなどを足がかりに低権限のローカル実行を得ることがよくあります。

3 つ目の誤解：ptrace_scope を設定すれば十分、というものです。これは一時的な緩和策であり、根本修正ではありません。カーネル更新と再起動は必要です。

4 つ目の誤解：root を取られていなければ問題ない、というものです。SSH ホスト秘密鍵や /etc/shadow の漏えいだけでも、横展開、ホストなりすまし、オフライン解析につながる十分なリスクがあります。

対応チェックリスト

次の順序で実行することを推奨します。

影響を受ける Linux ホストを棚卸しする。特に複数ユーザー環境と共有環境を優先する。
ディストリビューション公式のセキュリティアドバイザリを確認し、fixed kernel version を特定する。
修正済みカーネルをインストールして再起動する。
すぐに再起動できないマシンでは、先に kernel.yama.ptrace_scope=2 または 3 を設定する。
修正後、実行中のカーネルバージョンを確認する。
高リスクマシンでは SSH host keys をローテーションする。
/etc/shadow 漏えいが疑われる場合、パスワードリセットとアカウント監査を検討する。
公開 PoC、異常なコンパイル、不審なローカルデバッグ挙動を確認する。

まとめ

ssh-keysign-pwn（CVE-2026-46333）は、Linux kernel の __ptrace_may_access() 関連ロジックに起因するローカル情報漏えい脆弱性です。リモートから直接侵入できるものでも、直接 root shell を与えるものでもありませんが、低権限ローカルユーザーが高価値の機密ファイルを読み取れる可能性があるため、複数ユーザー、共有ホスト、CI、コンテナホスト環境では特に警戒が必要です。

最も確実な修正は、ディストリビューション提供の修正済みカーネルへ更新し、再起動することです。ptrace_scope=2/3 は一時的な緩和策として使えますが、パッチの代替にはなりません。リスクウィンドウにさらされていた重要ホストでは、SSH ホスト鍵のローテーションとパスワードリスク評価も検討してください。

参考リンク：

Dirty Frag、Copy Fail、Fragnesia：最近の Linux ローカル権限昇格脆弱性 3 件の比較

Fri, 15 May 2026 13:24:04 +0800

最近、Linux カーネルで注目度の高いローカル権限昇格脆弱性が続けて報告されています。Dirty Frag、Copy Fail、Fragnesia です。最終的な効果はいずれも似ています。低権限のローカルユーザーが root に昇格できる可能性があります。

ただし運用対応の観点では、これらを一つの脆弱性として扱うべきではありません。入口となるモジュール、発火経路、緩和策、パッチのタイミングが異なります。より正確には、Linux カーネルの「ページキャッシュ、splice、socket buffer、暗号処理経路」という複雑な境界に共通するリスクを露出させたものです。

この記事ではリスクと対応方針だけを扱い、再現可能な攻撃手順は扱いません。

3 つの脆弱性の概要

Dirty Frag：CVE-2026-43284

Dirty Frag は主に Linux カーネルのネットワーク経路におけるページキャッシュ書き込み問題を指します。公開資料では、xfrm-ESP 側の CVE-2026-43284 と、rxrpc 側の CVE-2026-43500 が一緒に語られることが多いです。

CVE-2026-43284 は、ESP が共有 skb fragment を処理する際のインプレース復号に関係します。重要なのは、攻撃者がディスク上のファイルを直接書き換えるのではなく、カーネルが書くべきでない共有ページへ書き込み、ページキャッシュ内のファイル内容に影響する点です。

運用上覚えておくべきなのは、Dirty Frag が esp4、esp6、rxrpc というカーネルモジュール群とネットワークサブシステム経路に到達することです。IPsec、ESP、RxRPC と関係するため、一時的な緩和策もこれらのモジュールを中心に考えることになります。

Copy Fail：CVE-2026-31431

Copy Fail は Theori / Xint Code が公開した Linux カーネルのローカル権限昇格脆弱性です。入口は IPsec のネットワーク経路ではなく、カーネルのユーザー空間暗号 API である algif_aead / AF_ALG 関連経路です。

公開説明では、2017 年に導入されたインプレース最適化に由来するとされています。特定の状況で、カーネルが期待どおりにデータをコピーせず、ページキャッシュページを writable な宛先経路に入れてしまいます。攻撃者は AF_ALG と splice() を組み合わせ、ページキャッシュに裏付けられたページへ小さな制御書き込みを行えます。

リスクが高い理由は、利用可能性が高く、複数の主要ディストリビューションにまたがって影響するためです。Dirty Frag と違い、Copy Fail の一時的な緩和は algif_aead の制限または無効化、そしてコンテナや CI 環境での AF_ALG socket 作成制限が中心になります。

Fragnesia：CVE-2026-46300

Fragnesia は V12 Security が公開した別の Linux カーネルローカル権限昇格脆弱性で、Dirty Frag と近い攻撃面に属します。Dirty Frag と同じ bug ではありませんが、IPsec ESP / rxrpc 関連モジュールとページキャッシュ書き込み効果を中心にしています。

AlmaLinux はこれを同じコード領域における 3 つ目の local-root 問題として位置付けています。ポイントは、skb_try_coalesce() が socket buffer fragment を結合する際に共有 fragment マーカーを正しく保持しなかったことです。その結果、後続の XFRM ESP-in-TCP 受信経路が外部ページキャッシュページ上でインプレース復号を行う可能性があります。

つまり、Fragnesia は Dirty Frag に近い問題です。どちらも esp4、esp6、rxrpc、skb fragment、ESP 復号経路の周辺にあります。一時的な緩和策も大きく重なります。

共通点：なぜ危険なのか

3 つの共通点は「コード位置が完全に同じ」ということではなく、攻撃結果とリスクモデルが非常に似ていることです。

第一に、いずれもローカル権限昇格です。攻撃者は通常、まず対象マシン上で一般ユーザーとしてコード実行能力を得てから、root への昇格を試みます。単一ユーザーのデスクトップではリモート一発侵害ではありませんが、複数ユーザーサーバー、CI runner、コンテナホスト、共有開発機、SSH を公開している VPS では、低権限入口は珍しくありません。

第二に、いずれもページキャッシュ書き込みに関係します。攻撃者は必ずしもディスク上のファイルを恒久的に書き換えるわけではなく、メモリ上のページキャッシュコピーに影響します。これにより従来のファイル整合性チェックは不十分になり得ます。ディスク hash は正常でも、実行経路が汚染されたページキャッシュ内容を読む可能性があります。

第三に、タイミングに強く依存する競合条件というより、決定的なロジックバグに近いものです。公開資料では、これらの脆弱性は race condition に勝つ必要がないと繰り返し述べられています。防御側は古い経験則で利用成功率を低く見積もるべきではありません。

第四に、コンテナや自動化実行環境のリスクを増幅します。コンテナ内の低権限コード、CI ジョブ、ビルドスクリプト、サードパーティプラグインがホストカーネルの関連インターフェースに到達できると、「ローカル問題」が「プラットフォーム問題」に変わります。

相違点：一つの対策では全部を覆えない

最大の違いは入口となるモジュールです。

Copy Fail の重要な入口は algif_aead / AF_ALG で、カーネルのユーザー空間暗号 API に属します。一時的な防御は algif_aead の無効化または制限、そして seccomp によるコンテナ内の AF_ALG socket 作成ブロックが中心です。

Dirty Frag の重要な入口は xfrm-ESP と rxrpc です。プロトコル処理と socket buffer 処理経路に近く、一時的な防御では esp4、esp6、rxrpc の無効化を検討します。ただし IPsec、VPN、トンネル、関連するネットワーク機能に影響する可能性があります。

Fragnesia の入口も Dirty Frag に近い領域ですが、具体的には skb_try_coalesce() が共有 fragment マーカーを保持しなかったことが問題です。Copy Fail の暗号 API 問題というより、Dirty Frag のリスク面にある別の分岐と見るべきです。

したがって、Copy Fail を処理済みだから Dirty Frag と Fragnesia も覆われる、とは言えません。逆に esp4 / esp6 を無効化したから Copy Fail が消えるわけでもありません。それぞれのパッチ状態と緩和策を別々に確認する必要があります。

影響範囲の判断方法

この種の脆弱性では、ディストリビューション名やカーネルのメジャーバージョンだけで判断しないことが重要です。ディストリビューションは修正をバックポートしますし、クラウドベンダーは独自のカーネルブランチを維持します。企業向けディストリビューションでは追加パッチが入っていることもあります。

より安全な確認順序は次の通りです。

ディストリビューションのセキュリティアドバイザリとカーネルパッケージ changelog を確認する。
現在のカーネルパッケージで対象 CVE が修正済みか確認する。
クラウドサーバー、コンテナホスト、CI ノードでは、クラウド事業者やプラットフォーム側の公告も確認する。
一時的な緩和策では、業務が対象モジュールに依存しているか確認する。
カーネル更新後は再起動を行い、実際に実行中のカーネルが切り替わったことを確認する。

この手順で最もありがちな落とし穴は「パッケージは更新したが、マシンを再起動していない」ことです。カーネル脆弱性は通常のユーザー空間サービス更新とは違います。新しいパッケージを入れても、再起動するまで古いカーネルが動き続ける可能性があります。

運用上の優先度

最優先で処理すべきマシンは、すべての Linux マシンを均等に並べたものではありません。低権限コード実行が最も起きやすい場所から始めるべきです。

優先度が高い環境は次の通りです。

複数ユーザーのログインサーバー
CI / CD runner
ビルドマシンと成果物パッケージングマシン
コンテナホストと Kubernetes ノード
共有開発機
SSH を公開しているクラウドサーバーと VPS
サードパーティスクリプト、プラグイン、ジョブキューを実行するプラットフォーム
Web 脆弱性、弱いパスワード、過去の侵害痕跡があるマシン

閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であればリスクはあります。ただし対応順序は後ろに回せる場合があります。

一時的な緩和策の位置付け

一時的な緩和策はパッチの代替ではありません。すぐに再起動できない、またはディストリビューションのパッケージを待っている間に露出面を下げるためのものです。

Copy Fail では algif_aead と AF_ALG に注目します。業務でカーネル AF_ALG 暗号インターフェースを使っていない場合は、関連モジュールの無効化を評価できます。コンテナ環境では、信頼できないワークロードが該当 socket を自由に作れないよう、まず seccomp ポリシーを確認すべきです。

Dirty Frag と Fragnesia では、esp4、esp6、rxrpc に注目します。システムが IPsec ESP、関連 VPN、トンネル、RxRPC に依存していない場合は一時的な無効化を検討できます。ただし本番環境では不用意に実行しないでください。これらのモジュールは実際のネットワーク業務を支えている可能性があります。

最終的にはカーネル更新に戻る必要があります。一時的な緩和策は攻撃面を減らせますが、システムが完全に安全であることの証明にはなりません。

3 つの脆弱性が示すもの

本当に警戒すべきなのは CVE の数だけではありません。これらの脆弱性はすべて、ゼロコピー、splice、socket buffer、ページキャッシュ、暗号インターフェース、プロトコルスタック最適化といった高複雑度のカーネル経路に集中しています。

これらの経路は大きな性能上の利益をもたらしますが、所有権の境界を保つのが難しくなります。fragment が共有されているか、ページにインプレースで書けるのか、最適化が本当にコピー削減だけなのか、といった点が安全境界そのものになります。

セキュリティチームと運用チームにとって、結論は実務的です。

ローカル権限昇格は「既存の低権限入口を増幅するもの」として扱う。
コンテナはカーネル脆弱性に対する自然な隔離境界ではない。
ファイル整合性チェックはディスク内容だけを見てはいけない。
CI、ビルドマシン、プラグイン基盤は高優先度資産として扱う。
カーネルパッチは「インストール済み」と「実行中」の両方を確認する。

まとめ

Dirty Frag、Copy Fail、Fragnesia はいずれも最近の Linux ローカル権限昇格リスクとして優先度の高い事象ですが、一つの脆弱性の別名ではありません。

Copy Fail は algif_aead / AF_ALG 暗号 API 経路を通ります。Dirty Frag は xfrm-ESP と rxrpc 関連経路を通ります。Fragnesia は Dirty Frag に近い攻撃面で、skb fragment マーカー処理の問題により再びページキャッシュ書き込みリスクを引き起こします。

対応として最も堅実なのは、ディストリビューションの公告に従ってカーネルを更新し、再起動することです。すぐに更新できないシステムでは、漏洞の入口に応じて一時的なモジュール無効化や seccomp の強化を評価します。複数テナント、CI、コンテナホスト、共有開発環境を優先してください。

参考資料：

Theori Copy Fail 説明：https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail セキュリティアドバイザリ：https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag 説明：https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia 説明：https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC 説明：https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300)：Linux カーネルのローカル権限昇格脆弱性の影響と緩和策

Fri, 15 May 2026 13:18:01 +0800

Linux カーネルで、Dirty Frag と同じ系統の攻撃面に関係するローカル権限昇格脆弱性が新たに報告されました。Fragnesia (CVE-2026-46300) です。

V12 Security の公開情報によると、Fragnesia は Linux のローカル権限昇格脆弱性です。攻撃者はホスト上で高権限を持っている必要はありません。ローカルでコードを実行できれば、カーネルの XFRM ESP-in-TCP サブシステムのロジック欠陥を利用し、読み取り専用ファイルのページキャッシュ内容をバイト単位で書き換え、最終的に root shell を得られる可能性があります。

原資料：

V12 Security PoC 説明：https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

この記事では再現可能な攻撃手順は扱わず、運用側が把握すべきリスクと対応方針に絞ります。

Dirty Frag との関係

V12 Security は Fragnesia を Dirty Frag 脆弱性クラスに分類しています。Dirty Frag と同一の bug ではありませんが、Linux カーネルの XFRM ESP-in-TCP という同じ攻撃面にある別の問題です。

XFRM は Linux カーネルで IPsec を処理するためのフレームワークです。ESP-in-TCP は ESP 暗号化トラフィックを TCP 上で運ぶ仕組みに関係します。Fragnesia の問題は、共有ページフラグメントと socket buffer の結合処理にあります。特定の状況で、カーネルが fragment がまだ共有状態であることを見失い、制御可能な書き込み余地が生まれます。

この種の問題は Dirty Pipe / Dirty Frag のようなページキャッシュ書き込み脆弱性を想起させます。具体的なコードは同一ではありませんが、攻撃効果が読み取り専用ファイルのページキャッシュ上のコピーに到達する点が共通しています。

なぜ危険なのか

Fragnesia が危険な理由は主に 3 つあります。

第一に、これはローカル権限昇格です。攻撃者が通常ユーザーとしてコードを実行できるだけで、root に昇格できる可能性があります。複数ユーザーのサーバー、コンテナホスト、CI runner、共有開発機、VPS、Shell を公開している環境では、通常のデスクトップよりも深刻です。

第二に、従来型の競合条件に依存しません。V12 の説明では、ESP-in-TCP の処理フローを構成し、すでに socket buffer に splice されたファイルページ上で暗号化ストリームを処理させることで、ページキャッシュ内容にバイト単位の影響を与える経路が示されています。これは単なる理論上の可能性ではなく、安定した利用経路が検証されていることを意味します。

第三に、変更されるのはディスク上のファイルではなくページキャッシュです。公開説明の例では /usr/bin/su が対象になっています。成功後もディスク上のファイルは恒久的には書き換えられず、変更はメモリ上のページキャッシュに存在します。ディスクファイルの hash や整合性だけを確認する巡回チェックでは異常を見逃す可能性があります。

管理者にとって厄介なのはここです。ファイルは変わっていないように見えても、汚染されたページキャッシュ上の対象バイナリを実行すると権限昇格につながる可能性があります。

既知の影響範囲

V12 Security の説明では、Dirty Frag の影響を受け、2026 年 5 月 13 日の関連パッチが適用されていないカーネルは Fragnesia の影響も受けるとされています。公開検証環境には Ubuntu 22.04、Ubuntu 24.04、6.8.0-111-generic などのカーネルが含まれます。

注意点は 2 つあります。

第一に、ディストリビューションのメジャーバージョンだけで判断しないことです。Ubuntu 22.04 / 24.04 が影響を受けるかどうかは、ディストリビューション名ではなく実際のカーネルパッチ状態で決まります。

第二に、デフォルトの AppArmor 制限だけに頼らないことです。Ubuntu の非特権ユーザー名前空間に対する AppArmor 制限はハードルを上げますが、公開情報ではそれは追加の回避対象であり、脆弱性本体の根本対策ではありません。

信頼できる判断方法は、各ディストリビューションのセキュリティアドバイザリとカーネルパッケージ更新を確認することです。

一時的な緩和策

すぐにカーネルを更新できない場合は、まず関連プロトコルモジュールに依存しているかを確認します。

V12 が示す緩和方向は Dirty Frag と同じです。システムが IPsec ESP や RxRPC に依存していない場合、esp4、esp6、rxrpc などのモジュール無効化を検討できます。ただしネットワーク機能に影響するため、本番環境で不用意に実行すべきではありません。IPsec、VPN、トンネル、関連するカーネル機能を業務で使っているか確認が必要です。

より安全な対応順序は次の通りです。

ディストリビューションがカーネルのセキュリティ更新を公開しているか確認する。
まずカーネルパッチをインストールし、再起動を計画する。
すぐに更新できない場合のみ、一時的なモジュール無効化を評価する。
複数ユーザーシステムと CI / ビルド環境を優先する。
不要なローカルアカウント、Shell、コンテナ脱出面、低権限実行入口を確認する。

モジュール無効化を最終修復とみなすべきではありません。これは露出面を一時的に下げる手段です。

すでに悪用された疑いがある場合

Fragnesia の特徴の一つはページキャッシュ汚染です。V12 は、悪用後に対象ファイルのページキャッシュ上のコピーが注入内容を含み、ページが追い出されるかシステムが再起動されるまで、後続の実行で異常な挙動を起こし得ると説明しています。

悪用が疑われる場合は、少なくとも次を実施します。

できるだけ早くログと監査記録を保全する。
最近の異常なローカルログイン、低権限ユーザー活動、不審なプロセス、root shell の痕跡を確認する。
関連するページキャッシュをクリアするか、直接再起動する。
修正済みカーネルへ更新する。
重要バイナリの整合性を確認する。ただしディスク hash のみに依存しない。
露出した可能性のある認証情報と鍵をローテーションする。

本番サーバーであれば、単なる通常のパッチ適用ではなく、潜在的なローカル権限昇格インシデントとして扱う方が安全です。

優先して確認すべきマシン

この種の脆弱性では、すべての Linux マシンを同じ優先度で扱うのではなく、攻撃者が低権限コード実行を得やすい場所から見るべきです。

優先度が高い環境は次の通りです。

複数ユーザーのログインサーバー
CI / CD runner
ビルドマシン
共有開発機
コンテナホスト
VPS とクラウドサーバー
SSH を公開しているエッジノード
サードパーティ製スクリプトやプラグインを実行するプラットフォーム

閉じた単一ユーザー環境で外部コード実行入口がないマシンも、脆弱であれば影響はあります。ただし緊急度は相対的に下げられます。

まとめ

Fragnesia が注目に値するのは名前が新しいからではありません。Linux のローカル権限昇格問題を、ページキャッシュとカーネルネットワークサブシステムの複雑な境界へ再び引き戻したからです。

管理者にとって重要なのは、攻撃手順を研究することではなく、カーネルのパッチ状態を確認し、ESP / RxRPC への依存を評価し、露出度の高いマシンを優先して更新し、「ディスクファイルが変わっていない」ことが「システムが影響を受けていない」ことを意味しないと理解することです。

影響を受けるシステムでは、最終的な答えはディストリビューションが提供するカーネル更新をできるだけ早く適用することです。一時的なモジュール無効化は移行措置であり、パッチの代替ではありません。

Dirty Frag CVE-2026-43284：Linux ローカル権限昇格のリスクと緩和ガイド

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag は、2026 年 5 月に公開され、実際の悪用の兆候も報告されている Linux kernel local privilege escalation 脆弱性群である。Microsoft は、攻撃者がすでに低権限の code execution を得た後に root へ昇格する post-compromise risk として説明している。Ubuntu も CVE-2026-43284 を High として扱っている。

この種の脆弱性で危険なのは、「remote から一発で侵入される」ことではない。「侵入後に権限を一気に広げられる」ことだ。攻撃者が弱い SSH account、WebShell、container escape、低権限 service account、phishing 後の remote access などで local execution を得ると、Dirty Frag を使って root を取得し、security tooling の停止、credential の読み取り、log 改ざん、lateral movement、persistence につなげる可能性がある。

Dirty Frag に関係する CVE

現在の公開情報では、Dirty Frag は主に二つの番号と関係している。

CVE-2026-43284：Linux kernel の xfrm/ESP path に関係する。Microsoft が言及する esp4、esp6 はこのリスク領域に含まれる。
CVE-2026-43500：Microsoft は rxrpc に関連すると説明しているが、2026 年 5 月 8 日時点では NVD にまだ正式公開されておらず、patch status も変化中である。

したがって、実際の確認では一つの CVE だけを見るべきではない。esp4、esp6、rxrpc、関連する xfrm/IPsec 機能が有効か、必要か、distribution kernel patch があるかをまとめて確認するのが安全だ。

技術的な概要

Microsoft と Ubuntu の説明によると、CVE-2026-43284 は Linux kernel の networking と memory-fragment handling、特に ESP/IPsec path における shared page fragments の扱いに関係する。

簡単に言えば、data page は splice などの仕組みで network buffer に attach されることがある。その後の kernel path が、それらの fragment を privately owned data とみなして in-place modification できるものとして扱うと、本来書き込むべきでない場所で in-place decrypt や modification が起きる可能性がある。攻撃者はこれを利用して page cache behavior を操作し、最終的に local privilege escalation を達成し得る。

これは以前公開された CopyFail（CVE-2026-31431）と背景が似ている。どちらも Linux page cache、kernel data path、local privilege escalation を中心にしている。Dirty Frag が危険なのは、追加の attack path を持ち、狭い race window に依存する従来型 LPE より安定しやすい可能性がある点だ。

優先的に見るべき環境

Dirty Frag は local privilege escalation なので、攻撃者がすでに対象 machine 上で code を実行できることが前提になる。優先的に確認すべき環境は次の通り。

SSH を公開している Linux server。
WebShell を書き込まれる可能性がある Web application server。
multi-user login host、bastion、developer machine、CI/CD runner。
container host、Kubernetes node、OpenShift node。
IPsec、VPN、xfrm、RxRPC 関連機能を使う system。
Ubuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE など主要 distribution を動かす server。

local multi-user、container、露出した application path がまったくない server ではリスクは低めだ。しかし「攻撃者が low-privileged shell を得る可能性」がある system では、高優先度の kernel vulnerability として扱うべきである。

まず patch を優先する

最も確実な修正は、distribution が提供する kernel security update をインストールし、新しい kernel で reboot することだ。

Ubuntu の CVE page では、CVE-2026-43284 は 2026 年 5 月 8 日に公開され、priority は High とされている。Microsoft も Linux Kernel Organization が CVE-2026-43284 の修正を公開しており、できるだけ早く patch を適用するよう促している。

まず system を確認する。

1
2

uname -a
cat /etc/os-release

distribution に合わせて kernel を更新する。

`1`	`sudo apt update && sudo apt full-upgrade`

または：

`1`	`sudo dnf update`

更新後は、新しい kernel で起動していることを必ず確認する。

`1`	`uname -r`

kernel package をインストールしただけで reboot していない場合、古い kernel が動き続けるため、脆弱性は残る可能性がある。

暫定緩和：関連 module を無効化する

patch がまだない、または production をすぐ reboot できない場合は、関連 module を一時的に無効化できるか評価する。Ubuntu の緩和策は、esp4、esp6、rxrpc の loading を block し、すでに loaded なら unload するというものだ。

modprobe block rule を作成する。

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

early boot で module が load されないよう initramfs を更新する。

`1`	`sudo update-initramfs -u -k all`

すでに loaded な module を unload する。

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

module がまだ loaded か確認する。

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

module が業務で使われている場合、unload に失敗することがある。その場合、block rule は reboot 後に有効になる可能性が高い。

無効化前に業務影響を確認する

上の緩和コマンドをそのまま貼り付けてはいけない。esp4、esp6、xfrm/IPsec 関連機能は、VPN、tunnel、encrypted networking、Kubernetes/container networking、企業 network configuration で使われている可能性がある。rxrpc も、その protocol に依存する workload に影響する。

production で実行する前に、少なくとも次を確認する。

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

IPsec VPN や関連 kernel networking に依存している場合、module 無効化で接続が切れる可能性がある。その場合は、module block に長く頼るより、kernel patch と maintenance reboot を早めに計画するべきだ。

侵害後確認を省かない

Microsoft は、緩和策だけでは成功した exploit による変更を元に戻せない可能性があると強調している。攻撃者がすでに root を得ていた場合、persistence、file modification、log tampering、session data access が残っている可能性がある。

少なくとも次を確認する。

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

特に次を見る。

異常な su、sudo、SUID/SGID process launch。
最近追加された ELF executable。
Web directory 内の怪しい PHP、JSP、ASP file。
SSH authorized_keys の変更。
systemd service、cron、rc.local に追加された persistence。
container host 上の異常な privileged container や mount。

悪用が疑われる場合は、host を isolate し、evidence を保存し、credential を rotate してから cleanup する。module unload や cache clearing だけで安全になったと考えてはいけない。

drop_caches について

Microsoft は、一部の post-exploitation integrity verification で cache clearing を検討できると述べている。

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

これは vulnerability fix でも incident cleanup command でもない。cache clearing は追加の disk I/O と production performance への影響を起こし得る。影響を理解したうえで補助操作として使うべきだ。本当の修正は patch、reboot、integrity verification、persistence check である。

推奨対応順序

production environment では、次の順序が比較的安全だ。

Linux asset と kernel version を棚卸しする。
exposed SSH、Web workload、container host、multi-user system を優先する。
reboot できる system は早急に patch して新 kernel で起動する。
まだ patch または reboot できない system は、esp4、esp6、rxrpc の無効化を評価する。
su、SUID/SGID、異常 ELF、WebShell、container escape indicator の監視を強化する。
悪用が疑われる host では侵害後確認と credential rotation を行う。

まとめ

Dirty Frag は「remote one-click」脆弱性ではないが、侵害後のリスクを大きく高める。攻撃者が local で低権限 code execution を得るだけで、CVE-2026-43284 と関連する rxrpc attack surface を使って root へ昇格できる可能性がある。

管理者にとって重要なのは PoC 研究ではない。kernel が影響を受けるかを確認し、distribution security update をインストールして reboot すること。patch window 前には関連 module の無効化を評価すること。そして露出している system や疑わしい system では integrity と persistence を確認することだ。

参考リンク：

Btrfs Scrub 使用ガイド：データ検証、自動修復、定期メンテナンス

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub は、Btrfs の日常メンテナンスで最も重要で、同時に誤解されやすい機能の一つである。これは伝統的な意味の fsck ではない。filesystem data と metadata を読み、checksum、superblock、metadata block header、disk read error を検証し、信頼できる replica がある場合に修復を試みる online validation pass である。

NAS、home server、backup disk、multi-device array で Btrfs を使っているなら、scrub は定期メンテナンスに入れるべきだ。価値は「壊れてから修理する」ことではなく、disk がまだ読めて、array に good replica が残っている段階で silent corruption を早期に見つけることにある。

scrub は何を確認するのか

Btrfs の公式ドキュメントによると、scrub は filesystem data と metadata を走査し、主に次を確認する。

data block checksum error。
basic super block error。
basic metadata block header error。
disk read error。

RAID1 のような replicated block group profile を使う filesystem では、read-write mount 上の scrub が一部の損傷を自動修復できる。修復は魔法ではない。別の replica から検証済みの good data をコピーするだけである。

ここが重要だ。scrub の修復能力は「利用可能な good copy が存在すること」に依存する。single disk に data が一つしかない場合、scrub は checksum error を検出できても、元の内容を自力で復元することは通常できない。

よく使うコマンド

mount point に対して scrub を開始する。

`1`	`sudo btrfs scrub start /`

foreground で実行し、結果を手動で観察する。

`1`	`sudo btrfs scrub start -B /`

status を確認する。

`1`	`sudo btrfs scrub status /`

実行中の scrub を cancel する。

`1`	`sudo btrfs scrub cancel /`

中断された scrub を resume する。

`1`	`sudo btrfs scrub resume /`

Btrfs の mount path を指定すると、その filesystem 内の全 device を並列に scrub する。device を指定した場合は、その device だけを scrub する。ただし指定 device 上の replica が読めない、または検証に失敗した場合、Btrfs は他の device から good copy を読むことを試みる。

scrub は fsck ではない

最もよくある誤解がこれだ。scrub は btrfs check ではなく、伝統的な filesystem checker でもない。

scrub ができること：

checksum を使って data または metadata corruption を検出する。
他に信頼できる replica がある場合に自動修復する。
disk read error と一部の基本構造 error を検出する。

scrub ができないこと：

good replica がない data を再構築する。
offline filesystem check を置き換える。
複雑な tree structure corruption をすべて修復する。
application-level file content が必ず正しいと保証する。

filesystem structure が深刻に壊れている場合、専門家の助言のもとで btrfs check などの tool が必要になることがある。scrub を万能修復コマンドとして扱ってはいけない。

NOCOW file のリスク

Btrfs 公式ドキュメントは重要な注意点を挙げている。chattr +C で file に NOCOW attribute を設定すると、現在の実装では暗黙に NODATASUM が有効になる。つまり、その file data 自体には checksum がない。

scrub はこれらの file の metadata を検証し修復できるが、file data の内容は検証できない。multi-replica setup では特に問題になる。ある NOCOW file の一つの copy が壊れても、Btrfs にはどの replica が正しいか判断する data checksum がないため、壊れた内容を user space tool に返す可能性がある。

一部の application は performance のために +C を default で使う。systemd journal や一部の libvirt storage pool が代表例である。VM image、database、log directory では性能上の理由があるが、普通の COW file と同じように scrub が data content を守ってくれるとは期待できない。

read-only scrub でも書き込みが起こり得る

もう一つ直感に反する点がある。read-write mounted filesystem で read-only scrub を実行しても、いくつかの write が発生する可能性がある。

公式ドキュメントによると、これは block group を read-only として mark することと block group items を write back することの race を避けるための design limitation である。完全に write のない scrub を望むなら、read-only mounted filesystem 上で read-only scrub を実行する必要がある。read-write mount に read-only scrub option を付けるだけでは不十分だ。

一般ユーザーにとっての意味は次の通り。

日常の online scrub は read-write mount 上で実行できる。
forensic、failure analysis、非常に保守的な read-only check では、先に mount state を確認する。
read-only scrub を絶対に zero-write だと解釈しない。

中断と再開

新しい kernel では、scrub は suspend、hibernate、filesystem freezing、cgroup freezing、pending signals などで中断されることがある。中断後、実行中の scrub は cancel されるが、btrfs scrub resume で保存位置から再開できる。

scrub status は次の場所に記録される。

`1`	`/var/lib/btrfs/`

file name は通常次のようになる。

1
2

scrub.status.UUID
scrub.progress.UUID

status file は定期的に更新される。resume した scrub は、完全に最初からではなく、最後に保存された位置から続行する。

どれくらいの頻度で実行するか

公式の推奨は月 1 回である。実際には data の重要性と disk 状態に合わせて調整する。

よくある schedule：

Home NAS：月 1 回。
Backup disk：長時間接続した後、または月 1 回。
重要な multi-device array：月 1 回、必要ならより頻繁に。
New disk migration や disk 不良の疑い：migration 後すぐに実行。

scrub は idle filesystem でも device bandwidth の約 80% を使う可能性があるため、peak workload 中に実行しないほうがよい。HDD array では scrub 中に latency がかなり上がることがある。SSD でも read amplification と background pressure は増える。

scrub の bandwidth を制限する

以前は ionice で foreground I/O への影響を下げる方法がよく使われた。しかし公式ドキュメントは、すべての I/O scheduler で同じように support されるわけではないと注意している。CFQ はすでに一般的ではない。BFQ は関連 priority behavior を support するが、使う前に理解しておく必要がある。mq-deadline のような一般的 scheduler では、cgroup2 I/O controller や Btrfs 専用の limit のほうが適している。

systemd で read bandwidth を制限する例：

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Linux 5.14 以降では、Btrfs 専用の sysfs interface で device ごとの scrub limit を設定できる。

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

現在の limit を表示する。

`1`	`sudo btrfs scrub limit /`

この設定は永続化されず、filesystem を unmount すると失われる。実際の system に合わせて FSID と DEVID を置き換える必要がある。まず次を確認する。

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

実用的なメンテナンス手順

堅実な Btrfs メンテナンス手順は次のようにできる。

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

scrub が corrected errors を報告した場合、Btrfs は good replica から data を修復したという意味だが、無視してよいわけではない。disk SMART、cable、power、controller、Btrfs device stats を続けて確認するべきだ。

scrub が uncorrectable errors を報告した場合、Btrfs は good copy を見つけられなかった。まだ読める data をできるだけ早く backup し、affected file または device を特定し、必要に応じて disk replacement や backup からの restore を行う。

まとめ

Btrfs scrub の役割は明確だ。online data verification と replica repair の tool であり、fsck ではなく、backup でもない。

checksum と redundant replica がある Btrfs filesystem で、silent corruption を定期的に見つけ、good copy から復元する用途に最も向いている。checksum のない NOCOW file data は保護できず、good replica がない場合に壊れた内容を復元することもできない。

重要な data を Btrfs に置くなら、月 1 回 scrub を実行し、SMART、device stats、backup、alerting と組み合わせるべきだ。信頼できる data safety は、checksum、redundancy、monitoring、backup が一緒に働くことで実現する。単一の command に依存するものではない。

参考リンク：

Btrfs 公式ドキュメント：Scrub

F2FS が HC620 SMR HDD を固まらせる？Linux SMR ディスクのトラブルシュート

Fri, 08 May 2026 22:34:39 +0800

HC620 のようなヘリウム封入 SMR HDD を F2FS と組み合わせたとき、システムが固まる、アプリが応答しない、iowait が長時間高い、といった症状が出る場合、原因は一つの設定ミスではないことが多い。デバイス特性とファイルシステムの方針が衝突している。

Western Digital Ultrastar DC HC620 は Host-managed SMR である。順次書き込み、zoned を意識したワークロード、底層制約を理解したソフトウェアスタックに向いている。一方 F2FS はフラッシュストレージ向けに設計されたログ構造ファイルシステムだ。多くのランダム書き込みを順次書き込みに寄せられるが、空き容量が少ない、GC が頻繁、metadata 更新が多いと、機械式 SMR HDD を長い内部整理周期へ引きずり込むことがある。

まずこの問題か確認する

最初に次を確認する。

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

ディスクの %util が長時間 100% 近く、await が高く、多数のプロセスが D 状態に止まるなら、ボトルネックはブロックデバイス I/O と見てよい。

次に、HDD が zoned device として見えているか確認する。

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

Host-managed SMR であれば、通常のファイルシステムや通常のランダム書き込み負荷では性能が大きく落ちる可能性がある。一般的な drive-managed SMR のように、複雑さを HDD firmware が完全に隠してくれるわけではなく、ホスト側ソフトウェアが書き込み規則を理解する必要がある。

F2FS が停止を増幅しやすい理由

SMR の問題は、任意の場所を自由に上書きできない点にある。容量を増やすために隣接トラックを重ねるため、ランダム書き込みや頻繁な上書き、キャッシュ枯渇が起きると、追加のデータ移動と整理が必要になる。

F2FS はもともと NAND flash 向けだ。ログ構造書き込みを使い、segment cleaning と garbage collection で空間を回収する。この設計は SSD では自然だが、機械式 HDD、特に SMR HDD では、GC による読み書きの移動が大きな tail latency になる。

F2FS の background GC、foreground write、checkpoint、metadata 更新、HDD 自身の SMR cleanup が重なると、I/O キューが長時間埋まり続ける。ユーザーから見ると、ファイルコピー、ディレクトリ削除、ダウンロード、展開、データベース書き込みでシステム全体が固まったように見える。

まず保守的な mount option から調整する

すぐにファイルシステムを移行できない場合は、/etc/fstab の mount option から調整する。

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

各 option の意味は次の通り。

nodiscard：リアルタイム discard を無効にする。機械式 HDD は SSD のように頻繁な TRIM/discard を必要としないことが多い。
active_logs=2：F2FS は 2、4、6 個の active logs をサポートし、既定は通常 6。2 に下げると、同時ログによる seek 圧力を減らせる。
gc_merge：background GC thread に一部の foreground GC request を処理させ、プロセスが遅い GC を直接踏んだときの停止を軽減する。
flush_merge：cache flush request をまとめる。下位デバイスの flush が遅い場合に有効なことがある。
lazytime：一部のアクセス時刻更新による metadata 書き込みを減らす。

checkpoint=disable を通常の性能改善策として使うのは勧めない。checkpoint の負荷は減る可能性があるが、異常終了や停電時のリスクが高くなる。kernel documentation でも、checkpoint を無効にしている間も空き領域を確保するために GC が必要だと説明されている。代償を理解していないなら、長期運用の性能スイッチとして使うべきではない。

I/O scheduler を調整する

機械式 HDD と SMR HDD では、request merge と遅延制御が重要になりやすい。まず現在の scheduler を確認する。

`1`	`cat /sys/block/sdX/queue/scheduler`

mq-deadline への切り替えを試せる。

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

デスクトップ用途なら bfq も試す価値がある。順次スループットだけで判断せず、停止が減るか、await が下がるか、操作感が安定するかを見る。

F2FS の background GC を制限する

F2FS の sysfs path は実際のデバイス名に依存する。まず確認する。

`1`	`ls /sys/fs/f2fs/`

対応する mount device に対して GC interval を調整する。

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

ここでの sdX は例であり、実際には sda1、dm-0 などになることがある。GC sleep time を増やすと background GC が I/O を奪う頻度は下がるが、空間回収は遅くなる。ディスクが満杯に近いほど foreground GC が再び発生しやすいため、十分な空き容量を残す必要がある。

長期的には別の選択がよい

重要データを保存しているなら、最も安定した方針はバックアップ後にファイルシステムを変えるか、より適した HDD に変えることだ。

大容量の機械式 HDD では、次を優先して検討する。

XFS：大きなファイル、バックアップ、メディアライブラリ、アーカイブ、順次書き込み負荷に向く。
EXT4：互換性が高く、挙動が安定し、トラブルシュート資料も多い。

Host-managed SMR の場合は、kernel、controller、filesystem、application stack が zoned block device の使い方を本当にサポートしているかも確認する。そうでなければ、普通のランダム書き込み HDD として扱ったときに、予測しにくい長時間停止が起きやすい。

実用的な勧め

この種の HDD は、cold data、アーカイブ、バックアップ、メディアファイル、順次書き込みに向いている。download cache、container image、VM disk、database、頻繁な展開、小ファイルのランダム書き込みには向かない。

どうしても F2FS を使い続けるなら、少なくとも次を行う。

リアルタイム discard を無効にする。
active_logs=2 で同時ログを減らす。
gc_merge と flush_merge を有効にする。
十分な空き容量を残し、満杯に近づけない。
download directory、database、VM image をこのディスクに置かない。
平均速度だけでなく iostat -x 1 を定期的に見る。

まとめると、HC620 + F2FS の停止は、SMR の書き込み制約、F2FS GC、機械式 HDD の tail latency が重なった結果である。短期対策は mount option、scheduler、background GC の調整。長期対策は XFS/EXT4 への移行、または SMR HDD を本来向いている順次書き込みアーカイブ用途に戻すことだ。

参考リンク：

Canonical の Ubuntu AI ロードマップ：ローカル推論を優先し、強制統合はしない

Fri, 08 May 2026 22:23:46 +0800

Canonical が最近示した Ubuntu の AI ロードマップで重要なのは、「Ubuntu が AI を無理にシステムへ押し込む」という話ではない。むしろ、AI 機能を段階的に提供し、既定では無効にし、ユーザーが明示的に選んだときだけ有効化し、推論はできるだけローカルで行うという慎重な方針だ。

これは、Windows や macOS のシステムレベル AI をめぐる議論とは対照的だ。Ubuntu が目指しているのは、避けられない全体 AI レイヤーでも、OS 全体を一括で止める「AI 総スイッチ」でもない。AI 機能を比較的独立したツールとして分け、インストールするか、使うか、どのモデルにつなぐか、データを外へ出すかをユーザーが決められるようにする方向である。

まず時期を確認する：Ubuntu 26.04 LTS ではない

今回のロードマップが主に向いているのは Ubuntu 26.10 “Questing Quokka” で、2026 年 10 月 9 日にリリース予定とされている。Canonical の計画は、一部の AI ツールを実験的な preview として導入することであり、Ubuntu 26.04 LTS に既定機能として入れることではない。

ここは重要だ。LTS は長期安定、企業導入、セキュリティ保守を担うリリースであり、探索段階のデスクトップ AI 機能を既定体験として入れる可能性は高くない。まず 26.10 のような通常リリースで試し、開発者や早期ユーザーの反応を見て、どの機能を後続の長期サポート版に入れるか判断するのが自然だ。

ローカル推論を優先し、クラウドは既定にしない

Canonical が強調している原則の一つは local inference first、つまり既定ではユーザーのマシン上で推論することだ。クラウドプロバイダー、自前サーバー、企業向けモデルサービスをユーザーが明示的に設定した場合だけ、リクエストが外へ出る。

理由は現実的だ。システムレベルの AI は、コマンド出力、ログ、ファイルパス、エラー、システム設定などの機密性が高い情報に触れやすい。たとえ「エラーを説明する」ためであっても、こうした情報を自動でクラウドへ送るのは、プライバシーとコンプライアンス上のリスクになる。

したがって Ubuntu の AI 路線は、クラウド AI の入口を OS に作るというより、差し替え可能な推論レイヤーに近い。ユーザーはローカルモデル、社内推論サービス、必要に応じて Canonical 管理のサービスを選べる。重要なのは、特定のモデルベンダーに固定しないことだ。

AI CLI：まずは端末支援から

最初に現実的に入ってきそうな機能の一つが、端末ユーザー向けの AI Command Line Helper、いわゆる ai-cli だ。

これは shell を置き換えるものでも、危険なコマンドを自動実行するものでもない。目的は、コマンド、ログ、systemd unit、エラー出力、システム状態を理解する手助けである。複雑なサービス起動失敗ログの原因を説明したり、コマンドオプションの意味をわかりやすく示したりする用途が想定される。

この入口は Ubuntu のユーザー層に合っている。Ubuntu のデスクトップユーザーやサーバーユーザーには、もともと端末で作業する人が多い。派手なチャット画面から始めるより、エラー調査、コマンド解説、運用支援といった高頻度の場面に AI を置くほうが実用的だ。

ただし、安全境界は明確でなければならない。ログには token、社内アドレス、ユーザー名、パス、鍵の断片、業務情報が含まれることがある。既定がローカル推論でも、ツールは秘匿情報の削除を促すべきだ。ユーザーがクラウドバックエンドを選ぶなら、何が送信されるかを明示する必要がある。

Settings Agent：自然言語でシステム設定を扱う

もう一つの方向が Settings Agent で、自然言語でシステム設定を問い合わせたり変更したりする機能である。

一見簡単そうだが、実装は難しい。成熟した Settings Agent は、画面を読み取り、ボタンを推測し、クリックを模倣するような方法で設定を操作すべきではない。読み取れる設定、変更できる設定、変更前に確認が必要な操作、失敗時のロールバックなどを、制御された内部 API で扱う必要がある。

そのため、これは 26.10 で完成して提供される機能というより、その後も継続して進む方向と見るべきだ。うまく作れば、一般ユーザーがデスクトップ Linux を設定するハードルを大きく下げられる。攻めすぎると、新しいセキュリティリスクにもなる。

なぜ「AI 総スイッチ」が最優先ではないのか

OS ベンダーが AI を入れると、「どこにでも AI があり、完全に止めにくい」体験になるのではないかと不安に思うユーザーは多い。そこで、Ubuntu に全体の AI kill switch が必要なのでは、という疑問が出てくる。

Canonical の考え方は、AI 機能がそもそも opt-in で、層ごとに分かれ、個別にインストールと設定ができるなら、全体スイッチは最優先ではないというものだ。つまり、「既定で有効、深く統合、あとからユーザーが無効化する」という構造を設計段階で避けようとしている。

それで十分かどうかは実装次第だ。AI ツールが既定で有効にならず、既定でネットワークに接続せず、既定でデータを収集せず、各機能に明確な設定入口があるなら、ユーザーは AI を止めるために隠れた項目を探し回る必要はない。

開発者と企業ユーザーへの意味

開発者にとって、AI CLI のようなツールの実用的な価値は、ドキュメント調査、ログ読解、システム問題の切り分け時間を減らすことだ。これはエンジニアの判断を置き換えるものではなく、「この出力をまず説明する」作業を自動化するものに近い。

企業ユーザーにとっては、ローカル推論と差し替え可能なバックエンドのほうが重要だ。多くの企業は、ソースコード、ログ、顧客データ、インフラ情報を公開モデルサービスへ送れない。Ubuntu がシステムレベル AI をローカルモデル、私有推論サービス、企業の権限体系と結び付けられれば、コンプライアンス環境でも制御可能な支援を提供できる。

これは Linux デスクトップとワークステーションにとっても機会だ。Windows や macOS は AI をベンダーエコシステムの一部にしやすい。一方 Ubuntu の強みは、オープンで、監査可能で、置き換え可能で、自前運用できることにある。Canonical がこの原則を保てるなら、AI はプロ向け Linux 体験を補強する可能性がある。

過度に読み取らない

現時点で、このロードマップを「Ubuntu が特定の小型モデルをプリインストールする」「Ubuntu 26.04 に AI 監査モードが入る」「固定の ubuntu-ai コマンドが用意される」と解釈するのは早い。公開情報でより確かなのは方向性であり、完成した製品形態ではない。

より安全な理解は、Canonical が Ubuntu にシステムレベル AI ツールの枠組みを入れようとしており、まずコマンドライン支援、設定支援、ローカル推論、バックエンド選択から始める、というものだ。既定の姿勢は、システムが選ぶのではなくユーザーが選ぶことである。

まとめ

Ubuntu の AI ロードマップで本当に注目すべきなのは、Ubuntu も「AI の波に乗る」ということではない。オープンソース OS における、より抑制された AI 統合の形を定義しようとしている点だ。知能はインフラになり得るが、プライバシー、制御性、ユーザーの選択権が先に来るべきだ。

26.10 の実験的機能がこの原則を守れるなら、Ubuntu は一般消費者向け OS とは異なる道を取れるかもしれない。避けられないシステム広告枠としての AI ではなく、選択可能で、置き換え可能で、監査可能な生産性ツールとしての AI である。

参考リンク：

2026年の Linux デスクトップディストリビューション選び：Ubuntu、Deepin/UOS、Linux Mint、Fedora 比較

Thu, 07 May 2026 21:17:11 +0800

2026年に Linux デスクトップディストリビューションを選ぶとき、重要なのはどれが最も「純粋」か、どれが最も「先進的」かではありません。毎日気持ちよく使い続けられるかです。

デスクトップはサーバーとは違います。サーバーではライフサイクル、パッケージ安定性、運用規約が重要です。デスクトップではさらに、インターフェース、ドライバ、アプリストア、入力方式、オフィスソフト、GPU、Bluetooth、音声、タッチパッド、外部ディスプレイ、日常的な細かい不具合も効いてきます。

あまり手間をかけたくないなら、まず Ubuntu、Linux Mint、Deepin/UOS を見ます。開発者で、新しいソフトウェアスタックと速い技術サイクルを受け入れられるなら、Fedora も注目に値します。

早見表

ディストリビューション	最適な用途	主な利点	注意点
Ubuntu 26.04 LTS	初心者、開発者、主力デスクトップ	ドキュメントが最も多く、エコシステムが広く、ハードウェアとソフトウェア対応が強い	標準 GNOME には慣れが必要。Snap 方針を好まない人もいる
Deepin / UOS	中国語ユーザー、国産化環境、見た目を重視する人	美しく使いやすい。中国語ローカライズが強く、国産ソフトや政企環境との互換性が高い	コミュニティ版と商用版の位置付けが違う。更新方針を分けて見る必要がある
Linux Mint	Windows からの移行、安定優先ユーザー	親しみやすい UI、非常に使いやすい、Cinnamon が安定	新技術の導入は遅め。標準スタックは攻めていない
Fedora	開発者、Linux 新技術を試したい人	新しいカーネル、新しい GNOME、新技術の導入が速い	更新頻度が高く、安定保守派には LTS より落ち着かない

一言で言えば次の通りです。

初心者と主力デスクトップ：Ubuntu 26.04 LTS。
中国語・国産化体験：Deepin / UOS。
Windows からの滑らかな移行：Linux Mint。
開発者と新技術の先取り：Fedora。

Ubuntu 26.04 LTS：万能型デスクトップ

Ubuntu 26.04 LTS Resolute Raccoon は 2026年4月にリリースされました。LTS 版として、長期的な主力デスクトップに向いています。

Ubuntu の利点は非常に分かりやすいです。資料が最も多く、チュートリアルも最も多く、問題が起きたときに答えを検索しやすいです。VS Code、Docker、NVIDIA ドライバ、Steam、Chrome、Slack、JetBrains、CUDA、Python、Node.js などを入れる場合、Ubuntu はベンダーとコミュニティが優先して対応する対象であることが多いです。

Ubuntu 26.04 LTS に向く人：

初めて本格的に Linux デスクトップを使う人。
長く使える主力システムを探している人。
開発に安定した Linux 環境が必要な人。
多くのチュートリアル、ドライバ、商用ソフトウェア対応が必要な人。
デスクトップ、サーバー、WSL エコシステムをつなげたい人。

利点：

LTS ライフサイクルが長い。
公式イメージとドキュメントが成熟している。
GNOME デスクトップが現代的で、タッチパッドと複数ディスプレイ体験が比較的良い。
ドライバ、クラウド、コンテナ、開発ツールのエコシステムが広い。
問題発生時の検索コストが最も低い。

注意点として、Ubuntu は標準で GNOME を使います。Windows のデスクトップ操作とは違うため、初心者は Activities Overview、Dock、ワークスペース、アプリランチャーに慣れる必要があります。また Ubuntu は Snap を長く推進しており、起動速度、パッケージ管理方式、エコシステム方針を好まないユーザーもいます。

私の判断では、どのデスクトップディストリビューションを選ぶべきか分からないなら、Ubuntu 26.04 LTS は今でも最も安全なデフォルト回答です。すべての方向で最先端ではありませんが、総合点が最も高いです。

Deepin / UOS：中国語デスクトップ体験と国産化互換

Deepin と UOS の強みは、中国語デスクトップユーザーをよく理解している点です。

Deepin 25 は 2025年にリリースされ、2026年も deepin 25.1 などで更新が続いています。公式説明では、deepin 25 の重点として DDE デスクトップ環境の改善、UOS AI、Solid immutable system、Linyaps アプリ互換方式、Distrobox subsystem、Treeland window compositor preview などが挙げられています。

これらは Deepin/UOS が単なる「きれいな Linux スキン」を作っているのではなく、中国語デスクトップの長年の課題を解こうとしていることを示します。

アプリインストールと依存関係の衝突。
国産ソフトウェア互換性。
デスクトップの美しさと使いやすさ。
システム更新失敗時のロールバック。
中国語入力、オフィス、政企ソフトウェアエコシステム。
Windows アプリ互換と移行。

Deepin / UOS に向く人：

中国語 UI、入力方式、オフィス、本地化体験を重視する人。
開封後すぐ使え、見た目の良い Linux デスクトップが欲しい人。
国産化されたソフトウェア・ハードウェア環境で使う必要がある人。
政企オフィス、国産ソフト、国産 CPU、互換認証が必要な人。
GNOME/KDE を一から設定したくない人。

Deepin の利点：

DDE インターフェースが統一され、美しい。
中国語ユーザー向けの細部がよい。
アプリストアとシステム設定が一般ユーザーの感覚に近い。
Linyaps、Distrobox などが Linux アプリ互換問題の緩和に役立つ。
UOS 商用版は国産化シナリオで現実的価値が高い。

注意点として、Deepin コミュニティ版と UOS 商用版は完全に同じ位置付けではありません。Deepin は個人体験とコミュニティユーザー向けです。UOS は政企、国産化、商用サービス、認証環境寄りです。本番のオフィス環境では、インターフェースだけでなく、ハードウェア、ソフトウェア、組織要件を見る必要があります。

私の判断では、中国語ユーザーで、特に見た目、入力方式、国産ソフト、オフィス体験を重視するなら Deepin/UOS は魅力的です。ただし、標準的な上流 Linux エコシステムに強く依存する重い開発者なら、Ubuntu や Fedora の方が自然に感じるかもしれません。

Linux Mint：最も Windows に近く、最も安心

Linux Mint の位置付けは一貫しています。普通のユーザーが Linux を簡単に使えるようにすることです。

2026年時点で、Linux Mint の主系列は 22.x 系を中心に進んでおり、Ubuntu 24.04 LTS をベースにしています。Linux Mint 22.3 Zena は 2026年初めにリリースされました。これは最新技術の展示台ではなく、安定しており、慣れやすく、学習コストの低いデスクトップシステムです。

Linux Mint は Windows から移行するユーザーに特に向いています。特に Cinnamon デスクトップです。

左下メニュー。
タスクバー。
システムトレイ。
ウィンドウの最小化/最大化の動作。
設定パネル。
ファイルマネージャ。
更新マネージャ。

これらの細部は、伝統的な Windows デスクトップに近い感覚を作ります。GNOME ワークフローに慣れたくない人には、Linux Mint は Ubuntu より始めやすいです。

Linux Mint に向く人：

Windows から Linux へ移行する人。
親、家族、非技術ユーザーに Linux を入れる人。
新技術を追わず、安定したデスクトップが欲しい人。
主な用途がブラウザ、オフィス、動画、ファイル管理、軽い開発の人。
GNOME が好きではなく、KDE も調整したくない人。

利点：

Cinnamon デスクトップが直感的。
更新マネージャが分かりやすい。
システムが保守的で安定している。
古い PC に比較的優しい。
コミュニティ資料が多く、問題が比較的少ない。

注意点として、Linux Mint は新技術優先ではありません。Wayland、PipeWire、最新 GNOME/KDE、最新カーネル、最新 Mesa などは、通常最前線で導入されません。目指しているのは「今日安定して動くこと」であり、「最新の Linux デスクトップ技術を最初に使うこと」ではありません。

私の判断では、Windows ノート PC を Linux にしたいが多くの概念を説明したくないなら、Linux Mint は最も安定した選択肢の一つです。Ubuntu ほど商用エコシステムが強いわけでも、Fedora ほど新しいわけでもありませんが、日常体験は非常に堅実です。

Fedora：開発者と新技術優先

Fedora はデスクトップ Linux 新技術の前線の一つです。

2026年5月時点で、Fedora の current mainline は Fedora Linux 44 です。Fedora Workstation は、GNOME、Wayland、PipeWire、Mesa、カーネル、systemd などの新技術が比較的早く入るディストリビューションの一つです。

Fedora に向く人：

Linux 開発者。
GNOME ユーザー。
新しいカーネル、新しい Mesa、新しいコンパイラ、新しいツールチェーンを早く使いたい人。
Wayland、PipeWire、Flatpak などの現代的 Linux デスクトップスタックを体験したい人。
半年ごとのアップグレードを怖がらない人。

Fedora の利点：

新技術の導入が速い。
標準システムが比較的クリーン。
GNOME 体験が上流に近い。
開発ツールチェーンが新しい。
Flatpak とオープンソースデスクトップエコシステムの結び付きが強い。
現代的なハードウェア対応が比較的積極的。

注意点も明確です。

ライフサイクルが短く、定期的なアップグレードが必要。
システムをまったく保守したくない人には向かない。
NVIDIA、プロプライエタリコーデック、一部商用ソフトには追加リポジトリが必要。
「インストールして 5 年放置したい」なら、Fedora は LTS ディストリビューションほど向きません。

私の判断では、Fedora は開発者、Linux 愛好者、新技術を試したい人に向いています。普通の人にとって最も手間の少ないデスクトップではありませんが、Linux デスクトップの未来がどうなるかを早く見ることができます。

四つをどう選ぶか

初めて Linux を入れる初心者

Ubuntu 26.04 LTS または Linux Mint を優先します。

Ubuntu の強みは資料とエコシステムです。Linux Mint の強みは Windows に近く学習コストが低いことです。GNOME に慣れる気があるなら Ubuntu。できるだけ Windows に近い方がよいなら Linux Mint です。

中国語オフィスと国産化環境

Deepin / UOS を優先します。

国産オフィスソフト、国産ブラウザ、政企システム、国産 CPU、組織が求める互換環境が必要なら、UOS の実用価値が高いです。個人ユーザーが美しい中国語デスクトップを求めるなら Deepin を見ます。

開発者の主力機

Ubuntu 26.04 LTS と Fedora はどちらも候補です。

安定性、チュートリアル、商用ソフトウェア対応を重視するなら Ubuntu。新しいカーネル、新しい GNOME、新しいツールチェーン、オープンソース技術の前線を重視するなら Fedora です。

古い PC や家庭用 PC

Linux Mint がより合います。

伝統的なインターフェース、比較的優しいリソース使用、低い保守負担があります。古い PC、家庭用ブラウジング機、軽いオフィス用途では、新技術重視の Fedora より Mint の方が安定します。

AI/GPU/開発ツールチェーン

Ubuntu を優先します。

NVIDIA ドライバ、CUDA、PyTorch、TensorFlow、Docker、VS Code、JetBrains などのツールは、公式説明やチュートリアルで Ubuntu が最もよく登場します。Fedora でも使えますが、問題解決にはより多くの Linux 経験が必要になることがあります。

選ぶ前に見るべき点

デスクトップ Linux はスクリーンショットだけで選ぶべきではありません。実際の体験を左右するのは次の細部です。

GPU ドライバが安定しているか。特に NVIDIA。
Wi-Fi、Bluetooth、指紋、カメラが正常に動くか。
外部ディスプレイ、スケーリング、複数画面が快適か。
中国語入力方式が使いやすいか。
よく使うソフトに公式パッケージまたは Flatpak があるか。
システム更新が理解しやすいか。
問題が起きたときに解決策を検索できるか。
標準デスクトップワークフローを受け入れられるか。

Linux への移行に失敗する人の多くは、カーネルが弱いからではありません。入力方式、スケーリング、WeChat、オンラインバンキング、プリンタ、GPU ドライバのような日常的な細部が合わないからです。

私のおすすめ

場面	推奨
初心者の主力デスクトップ	Ubuntu 26.04 LTS
Windows ユーザーの移行	Linux Mint
美しい中国語デスクトップ	Deepin
国産化オフィス/政企環境	UOS
開発者の安定環境	Ubuntu 26.04 LTS
Linux 新技術体験	Fedora Linux 44
古い PC の軽いオフィス用途	Linux Mint
AI/GPU 開発	Ubuntu 26.04 LTS

短い結論

Ubuntu 26.04 LTS は 2026年で最も無難な万能デスクトップ選択です。初心者、開発者、主力機に向きます。

Deepin/UOS は中国語体験、美しいインターフェース、国産化互換に強く、本地化や政企環境を重視するユーザーに向きます。

Linux Mint は非常に使いやすく安定しており、特に Windows からの滑らかな移行に向きます。

Fedora は新技術と開発者体験に強く、Linux デスクトップの前線を追いたい人に向きます。

デスクトップシステムの良し悪しは、最終的には毎日 PC を開いたときに使い続けたいと思えるかで決まります。紙の上で最も良く見えるディストリビューションより、長く快適に使えるディストリビューションの方が重要です。

2026年の Linux サーバー向けディストリビューション選び：Debian、Rocky Linux、AlmaLinux、Ubuntu Server 比較

Thu, 07 May 2026 21:03:12 +0800

2026年に Linux サーバー向けディストリビューションを選ぶとき、重要なのは「どれが一番良いか」ではなく、「どれが自分たちの運用モデルに合うか」です。

最も安定したコミュニティディストリビューションが必要なら、Debian は今でも有力な第一候補です。RHEL 互換エコシステムが必要だが RHEL を直接購入したくない場合、Rocky Linux と AlmaLinux は CentOS 後の自然な代替です。クラウドイメージ、ドキュメント、素早いデプロイ、新しめのパッケージを重視するなら、Ubuntu Server が今でも最も楽です。

以下では、サーバー用途の実務目線で比較します。

早見表

ディストリビューション	最適な用途	主な利点	注意点
Debian	長期安定、自ホスト、基礎サービス	安定、簡潔、強いコミュニティ、自由ソフトウェアの伝統	標準パッケージは保守的。企業向け商用サポートは RHEL/Ubuntu ほど明確ではない
Rocky Linux	RHEL 互換の本番環境	RHEL に近い運用習慣。CentOS からの企業移行に向く	パッケージ更新は保守的。デスクトップや新技術体験は主目的ではない
AlmaLinux	RHEL 互換本番環境、クラウド、企業向け代替	RHEL 互換、活発なコミュニティ、明確なライフサイクル	RHEL と少し差異があるため release notes の確認が必要
Ubuntu Server	クラウドサーバー、コンテナ、開発デプロイ	クラウド対応が強い、資料が多い、デプロイが速い、LTS が長い	Snap、HWE カーネル、PPA はチーム内ルールが必要

一言で言うと次の通りです。

最も無難な汎用選択：Debian。
企業向け RHEL エコシステム代替：Rocky Linux / AlmaLinux。
クラウドと開発効率優先：Ubuntu Server。

Debian：岩のような安定性

2026年5月時点で、Debian の current stable は Debian 13 trixie です。Debian 12 bookworm は oldstable に移行しており、セキュリティと LTS サポートはありますが、新規サーバー導入では Debian 13 を優先して検討するのがよいでしょう。

Debian の特徴は一貫しています。

標準パッケージ選択は保守的。
システム構造がきれい。
商用ベンダーに強く縛られない。
コミュニティガバナンスが成熟している。
長期稼働する基礎サービスに向く。

次のようなサーバーなら Debian は扱いやすいです。

Nginx / Apache。
PostgreSQL / MariaDB / Redis。
Docker / Podman。
WireGuard / Tailscale。
ファイルサービス、バックアップサービス、監視サービス。
小規模な自ホストアプリ。

Debian の強みは「最新」ではなく「手間が少ない」ことです。多くのサーバーはインストール後、数年間は通常のセキュリティ更新と小さな保守だけで動かせます。

Debian に向いている場面：

システムをなるべく素朴に保ち、ディストリビューションベンダーの戦略に振り回されたくない。
apt、systemd、Debian のファイル構成に慣れている。
ソフトウェアが最新版でなくてもよい。
安定性、セキュリティ更新、予測しやすいアップグレードを重視する。

Debian にあまり向かない場面：

ベンダーが RHEL または Ubuntu だけを認証している。
SLA 付きの企業向け商用サポートが必要。
最新カーネル、最新 GPU スタック、新しいハードウェア対応に依存している。
チームの運用標準が全面的に RHEL 系エコシステムで書かれている。

私の判断では、個人サーバー、自ホスト、軽量 SaaS、小規模チームの基礎サービスでは、Debian は今でも非常に有力です。

Rocky Linux：CentOS 後の堅実な代替

Rocky Linux の位置付けは明確です。RHEL 互換エコシステムを必要とするユーザー向けであり、かつて CentOS Linux が企業本番環境で果たしていた役割を引き継ぎます。

2026年時点で、Rocky Linux 9 と Rocky Linux 10 はどちらもサポート期間内です。Rocky Linux 9 はより保守的な本番環境に向き、Rocky Linux 10 は新規プロジェクト、新しいハードウェア、より長い将来期間に向きます。

Rocky Linux に向く場面：

以前 CentOS 7 / CentOS 8 を使っていた企業環境。
RHEL 系のディレクトリ構造、パッケージ名、運用習慣が必要。
dnf、RPM、SELinux、firewalld に依存している。
ソフトウェアベンダーが RHEL-compatible ディストリビューションを明示的にサポートしている。
社内自動化スクリプトが Enterprise Linux 前提で書かれている。

利点は移行の抵抗が小さいことです。多くのチームは CentOS を前提に Ansible playbook、監視ルール、監査スクリプト、セキュリティベースラインを長年積み上げています。Rocky Linux への移行は、Debian や Ubuntu への移行より心理的負担が小さいです。

Rocky Linux の注意点：

パッケージバージョンは保守的です。これは Enterprise Linux の設計目標であり、欠点ではありません。
非常に新しいユーザー空間コンポーネントが必要な場合、EPEL、第三者リポジトリ、またはコンテナに頼ることがあります。
RHEL 互換は、すべての商用ソフトウェアベンダーが自動的に正式サポートするという意味ではありません。認証リストを確認してください。
Rocky Linux 10 はハードウェア基準や第三者エコシステムに新しい要件があります。本番投入前に検証が必要です。

私の判断では、サーバー環境がもともと CentOS / RHEL 系なら、Rocky Linux は非常に自然な代替です。特に安定した本番環境と企業内部サービスに向いています。

AlmaLinux：より能動的な RHEL 互換ルート

AlmaLinux も CentOS 後の重要な代替です。位置付けは同じく、企業向け、長期サポート、RHEL 互換です。

Rocky Linux との共通点は多くあります。

どちらも RHEL 互換エコシステム向け。
どちらもサーバー本番環境に向く。
どちらも 8、9、10 の長期サポート系列を持つ。
どちらも CentOS からの移行に向く。
どちらも多くの Enterprise Linux エコシステムツールを使える。

違いは、AlmaLinux が RHEL 互換を保ちながら、上流との差異をより積極的に記録・処理する点です。たとえば AlmaLinux 10 は古いハードウェア向けに x86-64-v2 アーキテクチャ選択肢を提供し、release notes で RHEL との差異を明確に説明しています。

これは一部のユーザーに有用です。RHEL エコシステムに留まりつつ、ハードウェア対応、パッケージビルド、EPEL 互換性でより柔軟なコミュニティディストリビューションを求める場合です。

AlmaLinux に向く場面：

RHEL 互換が必要だが、RHEL のリリース戦略に完全には縛られたくない。
コミュニティガバナンスと透明な release notes を重視する。
クラウド、コンテナイメージ、企業ワークロードで安定したベースシステムが必要。
CentOS や古い Enterprise Linux から平滑に移行したい。

注意すべき点は、AlmaLinux が「目を閉じれば RHEL と同じ」ではないことです。厳格なコンプライアンス、ベンダー認証、データベース認証、ハードウェア認証が必要な場面では、ソフトウェアベンダーが AlmaLinux を明示的にサポートしているか確認してください。

私の判断では、Rocky Linux と AlmaLinux はどちらも CentOS 代替になります。より保守的で伝統的な CentOS 的ストーリーを好むなら Rocky、コミュニティ透明性と柔軟な互換ルートを重視するなら AlmaLinux です。

Ubuntu Server：クラウド対応とデプロイ効率が最も強い

Ubuntu Server の強みは現実的です。クラウドプラットフォーム、ドキュメント、コミュニティチュートリアル、イメージ、自動化ツール、開発者エコシステムが強いです。

2026年の新規サーバー導入では、主力は引き続き Ubuntu 24.04 LTS です。Ubuntu LTS は通常 5 年の標準サポートを持ち、ESM による延長も可能です。クラウドサーバー、コンテナホスト、開発環境、CI/CD ノードでは、Ubuntu Server が最も早く使える選択になることが多いです。

Ubuntu Server に向く場面：

AWS、Azure、Google Cloud、Oracle Cloud、Alibaba Cloud、Tencent Cloud などのクラウドサーバー。
Docker、Kubernetes、GitLab Runner、CI/CD。
AI / GPU / CUDA 開発環境。
大量のチュートリアルとコミュニティ解法が必要なチーム。
開発と本番をできるだけ同じ環境にしたい場合。

Ubuntu の利点：

クラウドイメージの品質が高い。
公式・第三者ドキュメントが多い。
新しいハードウェア対応が比較的積極的。
LTS のリズムが明確。
開発者ツールチェーンを更新しやすい。
多くの商用ソフトウェアが Ubuntu 向け手順を優先して用意する。

Ubuntu の注意点：

サーバーで Snap を好まないチームもあるため、利用方針は事前に決めるべきです。
PPA は便利ですが、本番環境で乱用すると保守リスクが増えます。
HWE カーネル、クラウドカーネル、標準カーネルのどれを使うか明確にする必要があります。
極めてミニマルな安定性を好む人には、Ubuntu の標準構成は Debian より「にぎやか」に感じられます。

私の判断では、クラウドサーバー、コンテナ、開発デプロイ、AI ツールチェーンが中心なら、Ubuntu Server は通常最も効率的です。最も「純粋」なディストリビューションではありませんが、多くの作業で調査とつまずきを減らしてくれます。

四つをどう選ぶか

個人 VPS / 自ホスト

Debian または Ubuntu Server を優先します。

安定、省心、低メンテナンスを求めるなら Debian。チュートリアルに沿って新しいプロジェクトを頻繁にデプロイする、または新しめのソフトウェアスタックが必要なら Ubuntu Server です。

企業本番環境

Rocky Linux、AlmaLinux、または RHEL を優先します。

会社が以前 CentOS を使っていたなら、Rocky / Alma への移行コストが最も低いです。商用データベース、ハードウェア認証、セキュリティコンプライアンス、ベンダーサポートが関わる場合は、認証リストを先に確認してください。

クラウドネイティブとコンテナホスト

Ubuntu Server、Debian、Rocky / Alma はいずれも使えます。

開発効率を重視するチームなら Ubuntu Server。極簡安定を求めるなら Debian。企業標準が RHEL 系なら Rocky / Alma です。

AI / GPU サーバー

まず Ubuntu Server、次に Rocky / Alma を見ます。

理由は単純です。NVIDIA、CUDA、PyTorch、TensorFlow、ドライバ導入手順、コミュニティ経験は Ubuntu が最も多いことが一般的です。企業 GPU クラスターがすでに RHEL エコシステムで構築されている場合は Rocky / Alma も選べますが、ドライバ、CUDA、コンテナランタイム、監視ツールは事前検証が必要です。

伝統的な業務システム

Rocky Linux / AlmaLinux を優先します。

伝統的な Java、データベース、ミドルウェア、商用ソフトウェア、監査、運用標準は RHEL 系に寄りがちです。この場合、Rocky / Alma は Debian / Ubuntu より既存体系に合わせやすいです。

選ぶ前に見るべき指標

ディストリビューション名だけで選ばないことです。サーバー選定では、次の質問で判断するのがよいでしょう。

ライフサイクル：このバージョンは何年まで保守されるか。
アップグレード経路：メジャーバージョンアップは成熟しているか。平滑移行は可能か。
ソフトウェア供給元：第三者リポジトリに依存するか。誰が保守しているか。
セキュリティ更新：セキュリティアドバイザリ、パッチ頻度、CVE 対応は明確か。
ハードウェア対応：CPU、NIC、RAID、GPU、ストレージコントローラは検証済みか。
チーム経験：チームは apt と dnf のどちらに慣れているか。Debian 系か RHEL 系か。
ベンダー認証：業務ソフトウェアはそのディストリビューションを明示的にサポートしているか。
自動化資産：既存の Ansible、Terraform、イメージビルドスクリプトを再利用できるか。

本当のコストはインストール ISO ではありません。今後 5 年のアップグレード、監査、トラブルシュート、引き継ぎです。

私のおすすめ構成

2026年のサーバー選定でデフォルト案を出すなら次の通りです。

場面	推奨
個人 VPS、自ホスト	Debian 13
クラウドサーバー、素早いデプロイ	Ubuntu Server 24.04 LTS
CentOS 移行	Rocky Linux 9 / AlmaLinux 9
新規企業プロジェクト	Rocky Linux 10 / AlmaLinux 10。先にエコシステム検証
AI / GPU 開発	Ubuntu Server 24.04 LTS
強いコンプライアンスが必要な商用本番	RHEL、またはベンダーサポート確認後に Rocky / Alma

短い結論

Debian のキーワードは、安定、簡潔、コミュニティ、自由ソフトウェアの伝統です。長期稼働する基礎サーバーに向きます。

Rocky Linux と AlmaLinux のキーワードは、RHEL 互換、企業本番、CentOS 代替です。既存の Enterprise Linux 運用体系を持つチームに向きます。

Ubuntu Server のキーワードは、クラウド、ドキュメント、開発効率、エコシステムの完全性です。素早いデプロイ、コンテナ、AI/GPU、クラウドサーバーに向きます。

永遠に正しいディストリビューションはありません。チーム、業務、ハードウェア、ライフサイクルに最も合うものが正解です。サーバーで最良の選択は、たいてい一番流行っているものではなく、5 年後も保守する気になれるものです。

fdupesで削除順を制御する方法：ディレクトリ優先度で重複ファイルを残す

Wed, 06 May 2026 09:23:09 +0800

fdupes で重複ファイルを削除するとき、a、b、c の3つのディレクトリがあり、優先的に a を残し、次に b を残し、c の重複ファイルから削除したい場合、重要なのは複雑なルールではない。ディレクトリの入力順だ。

fdupes は非対話の削除モードでは、各重複グループで最初に見つかったファイルを残し、後から見つかった重複項目を削除する。そのため、ディレクトリ引数は「保持優先度が高いものから低いものへ」の順に並べる。

つまり、「先に c を削除し、次に b を削除し、できるだけ a を残す」には、次のように書く。

`1`	`fdupes -rdN a b c`

スキャン順は a -> b -> c になる。3つのディレクトリに同じファイルが存在する場合、a のファイルが先に見つかって保持され、b と c の重複ファイルが削除される。b と c だけに重複がある場合は、b が保持され、c が削除される。

パラメータの意味

よく使うパラメータは次の通り。

-r：サブディレクトリを再帰的にスキャンする。
-d：重複ファイルを削除する。
-N：-d と組み合わせて使い、対話確認を行わず、各重複グループの最初のファイルを残して残りを削除する。

そのため、重複ファイルを自動削除する基本形式は次のようになる。

`1`	`fdupes -rdN 目录A 目录B 目录C`

ディレクトリが前にあるほど保持優先度が高い。後ろにあるほど、重複ファイルが削除されやすくなる。

削除前にプレビューする

-dN を直接使うとファイルが削除されるため、まず重複ファイルのグループを確認するのがよい。

`1`	`fdupes -r a b c`

出力は重複ファイルごとにグループ化される。各グループで前に表示されるファイルが、非対話削除時に保持されやすいファイルだ。

統計情報を見ることもできる。

`1`	`fdupes -rm a b c`

データが重要な場合は、結果を保存して手動で確認する。

`1`	`fdupes -r a b c > duplicates.txt`

各重複グループの並び順が期待通りであることを確認してから、次を実行する。

`1`	`fdupes -rdN a b c`

サブディレクトリの扱い

-r を有効にすると、fdupes は渡されたディレクトリ配下のすべてのファイルを再帰的にスキャンする。保持優先度を決めるのは、やはりコマンド内でパスが登場する順序だ。

例えば次のように実行する。

`1`	`fdupes -rdN dir_a dir_b dir_c`

これは次の意味になる。

dir_a の優先度が最も高い。
dir_b がその次。
dir_c が最も低い。

dir_a/sub1/file.txt と dir_c/sub1/file.txt の内容が同じなら、dir_a 配下のファイルが保持される。dir_a/x/y/file.txt と dir_c/file.txt の内容が同じ場合も、dir_a 配下のファイルが優先される。fdupes が比較するのはファイル内容であり、ファイル名やディレクトリ階層が完全に一致する必要はない。

サブディレクトリの優先度を細かく制御する

親ディレクトリだけを渡す場合、サブディレクトリ内部のスキャン順は fdupes の走査ロジックに従う。多くの場合はこれで十分だ。ただし、特定のサブディレクトリにより高い優先度を与えたい場合は、そのサブディレクトリを明示的に前へ書く。

例えば、まず dir_a を残し、次に dir_b/special を残し、その後 dir_b の残りを処理し、最後に dir_c を処理したい場合は次のようにする。

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

これにより、dir_b/special は dir_b より先にスキャンされる。その後 dir_b がスキャンされる時点では、special 内のファイルはすでに記録されているため、dir_b の他の部分より高い優先度を持つ。

この書き方は次のような需要に向いている。

a が最も重要な基準ディレクトリ。
b の中の特定サブディレクトリが、b の他の内容より重要。
c は主に低優先度のバックアップディレクトリ。

パス順はさらに拡張できる。

`1`	`fdupes -rdN a b/important b c/keep-first c`

ルールは変わらない。前にあるほど優先的に保持される。

ディレクトリが多い場合はリストを使う

ディレクトリやサブディレクトリが多い場合、長いコマンドを手で書くと間違えやすい。優先度順にパスを folders.txt のようなテキストファイルへ書いておくとよい。

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

その後、xargs で fdupes に渡す。

`1`	`cat folders.txt \| xargs fdupes -rdN`

パスに空白が含まれる可能性がある場合は、NULL文字区切りを使うほうが安全だ。

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

注意すべき境界

第一に、fdupes が比較するのはファイル内容であり、ファイル名ではない。ファイル名が完全に違っていても、内容が同じなら重複ファイルとして扱われる。

第二に、a ディレクトリ内部に重複ファイルがある場合、fdupes -rdN a b c によって a 内部で後から見つかる重複項目も削除される可能性がある。このコマンドが表すのは「全体のスキャン順で最初に出たファイルを残す」ということであり、「a の中のファイルを絶対に削除しない」という意味ではない。

第三に、デフォルトでは fdupes はシンボリックリンクをたどらない。シンボリックリンク関連のファイルを処理する必要がある場合は、-s が必要かどうか、またそれがデータ安全上の期待に合うかを確認する。

第四に、fdupes は重複ファイルだけを削除し、空ディレクトリは削除しない。削除後に b や c に空フォルダが残った場合は、次を実行できる。

`1`	`find b c -type d -empty -delete`

より安全な操作習慣

ディレクトリ内のデータが重要な場合、いきなり -rdN を実行するのは避けたい。より安全な流れは次の通り。

まず fdupes -r a b c を実行して重複グループを見る。
各グループで先頭にあるファイルが本当に保持したいファイルか確認する。
その後 fdupes -rdN a b c を実行して自動削除する。
削除後、空ディレクトリの整理が必要か確認する。

a 内のファイルを誤って削除するのが非常に心配な場合は、低優先度ディレクトリだけを小さい範囲で先に整理するか、結果を出力して手動で絞り込むとよい。fdupes のディレクトリ順は便利だが、権限分離ルールではない。スキャン対象に含まれたパス内の重複ファイルは、削除判断に参加する可能性がある。

まとめ

fdupes で優先度に従って重複ファイルを削除する核心は、「残したいディレクトリ」を前に置き、「優先的に削除したいディレクトリ」を後ろに置くことだ。

a を残し、次に b を残し、c を優先的に削除するなら次のようにする。

`1`	`fdupes -rdN a b c`

特定のサブディレクトリの優先度を高くしたいなら、親ディレクトリより前に単独で書く。

`1`	`fdupes -rdN a b/important b c`

覚えることは一つでよい。fdupes -dN は先に現れた重複ファイルを残し、後に現れた重複ファイルを削除する。ディレクトリ順こそが保持優先度だ。

Snap、Flatpak、apt は何が違うのか

Sat, 02 May 2026 11:22:26 +0800

Ubuntu でソフトウェアをインストールするとき、apt、Snap、Flatpak という三つの名前をよく見ます。どれもアプリをインストールできますが、解決している問題は異なります。

簡単にまとめると次の通りです。

ツール	主な位置づけ	向いているもの
`apt`	Ubuntu/Debian の従来型パッケージマネージャー	システムコンポーネント、CLI ツール、ディストリビューションが管理するソフトウェア
Snap	Canonical が推進するアプリ包装形式	Ubuntu デスクトップアプリ、サーバーツール、自動更新したいソフトウェア
Flatpak	デスクトップアプリ向けのクロスディストリビューション形式	GUI アプリ、サンドボックス化アプリ、Flathub エコシステム

apt：システムの一部

apt は Debian/Ubuntu 系の従来型パッケージマネージャーです。ディストリビューションのリポジトリから .deb パッケージをインストールし、依存関係もディストリビューション側で管理されます。

よくあるインストール方法です。

`1`	`sudo apt install firefox`

apt の特徴は次の通りです。

システムとの統合が最も深い。
依存関係はディストリビューションが一元管理する。
ソフトウェアのバージョンは通常、ディストリビューションのリリース周期に従う。
システムライブラリ、ドライバー、CLI ツール、サーバーコンポーネントに向いている。

弱点も明確です。ソフトウェアのバージョンが古めになることがあります。ディストリビューションは安定性を重視するため、常に上流の最新版をすぐ出すわけではありません。

Snap：アプリと依存関係を一つのパッケージにする

Snap は Canonical が推進するパッケージ形式です。アプリと多くの実行時依存関係をまとめて梱包し、システムライブラリのバージョン差への依存を減らします。

インストール方法は似ています。

`1`	`sudo snap install firefox`

Snap の利点は次の通りです。

同じパッケージを複数の Ubuntu バージョンで動かしやすい。
アプリ更新をシステム更新から独立させられる。
標準で一定の隔離と権限制御がある。
速い更新が必要なデスクトップアプリや一部のサーバーツールに向いている。

よくある不満は、起動が遅い、容量を多く使う、テーマ統合が自然でない、更新のタイミングを apt ほど細かく制御しにくい、といった点です。

Flatpak：よりデスクトップアプリ向け

Flatpak もクロスディストリビューションのアプリ包装方式ですが、より Linux デスクトップアプリに寄っています。多くの Flatpak アプリは Flathub から入手できます。

よくあるインストール例です。

`1`	`flatpak install flathub org.mozilla.firefox`

Flatpak の特徴は次の通りです。

クロスディストリビューション対応が強い。
デスクトップアプリ配布に重点を置いている。
runtime を使って基礎依存関係を共有する。
サンドボックスと権限モデルが分かりやすい。
Flathub には多くのソフトウェアがある。

Flatpak も追加の容量を使います。特に初回に runtime を入れるときは目立ちます。ただし複数アプリが同じ runtime を共有すると、無駄は少なくなります。

最大の違い：依存関係の扱い

apt は「システムに組み込む」方式に近いです。アプリはシステム内のライブラリに依存し、複数のソフトウェアが同じ依存関係を共有します。

Snap と Flatpak は「アプリが自分の実行環境を持つ」方式に近いです。アプリが必要な依存関係の一部を持ち歩くため、システムバージョン差による問題を減らせます。

ここには取捨選択があります。

方式	利点	欠点
`apt` がシステム依存関係を共有	省容量、統合が良い、保守が一元化される	バージョンがディストリビューションに縛られる
Snap/Flatpak が実行環境を持つ	バージョン差に強い、複数ディストリビューションで使いやすい、更新しやすい	パッケージが大きい、起動が遅いことがある、統合感が弱いことがある

隔離と権限

apt で入れたソフトウェアは、通常システム環境で直接動きます。統合は自然ですが、隔離は少なめです。

Snap と Flatpak はどちらもサンドボックスの考え方を持っています。アプリは標準ではすべてのシステム資源へ自由にアクセスできず、ファイル、カメラ、ネットワーク、デスクトップ通知などには権限インターフェースを通じてアクセスします。

これは絶対安全という意味ではありませんが、より明確な権限境界を提供します。出所がさまざまなデスクトップアプリでは重要です。

更新方式の違い

apt は通常、システム更新に従います。

1
2

sudo apt update
sudo apt upgrade

Snap は自動更新されます。これは便利ですが、議論もあります。ユーザーはバージョン管理を気にしなくて済みますが、制御感は減ります。

Flatpak は手動で更新できます。

`1`	`flatpak update`

そのため、いつ更新するかを重視するなら、apt と Flatpak のほうが制御しやすく感じます。アプリを自動で新しく保ちたいなら、Snap のほうが楽です。

どれを使うべきか

用途で選ぶと分かりやすいです。

システムツール、ドライバー、サーバーコンポーネント：apt を優先。
Ubuntu が標準で推奨するデスクトップアプリ：Snap でもよい。
新しめのデスクトップソフト、特にクロスディストリビューションアプリ：Flatpak が合うことが多い。
同じソフトが三方式すべてにある場合：安定性、起動速度、テーマ統合、更新ニーズを見る。

保守的には、システム層は apt、デスクトップアプリは必要に応じて Snap と Flatpak から選ぶ、という使い分けで十分です。

まとめ

apt、Snap、Flatpak は、どれかがどれかを完全に置き換えるものではありません。配布モデルが違います。

apt はシステム保守に向き、Snap はアプリ同梱依存関係と自動更新を重視し、Flatpak はクロスディストリビューションのデスクトップアプリとサンドボックス配布に向いています。

日常利用なら、どれが最高かに悩みすぎる必要はありません。システムソフトは apt、デスクトップアプリはディストリビューションの推奨と自分の体験で選びます。安定して動き、更新を把握でき、権限が分かりやすければ、それが合った選択です。

参考：

https://www.reddit.com/r/Ubuntu/comments/9awvip/eli5_snap_and_flatpak_how_are_they_differ_from_apt/

Linux 7.0 と 7.1 における NTFS ドライバー変更の整理

Sat, 02 May 2026 10:46:20 +0800

Linux 7.0 の公開後、7.1 は次の機能マージ期間に入りました。そこで注目される変更の一つが、新しい NTFS カーネルドライバーです。

ここでいう「新しい」は、Linux が初めて NTFS に対応するという意味ではありません。また、ntfs3 が置き換えられるという意味でもありません。より正確には、Linux 7.1 に新しい任意のカーネル内 NTFS 読み書きドライバーが追加されます。これは昔からあるカーネル内 ntfs ドライバーを整理し直し、より完全な書き込み機能を補ったものです。

まず結論

Linux での NTFS 対応は、現在おもに三つのルートがあります。

方式	場所	読み書き	向いている場面
`ntfs-3g`	ユーザー空間 FUSE	読み書き	安定性優先。長く使われてきたディストリビューション標準
`ntfs3`	カーネル空間	読み書き	より直接的なカーネル統合と性能を求める場合
新 `ntfs`	カーネル空間	読み書き	Linux 7.1 で追加される任意の実装

今回の変更は強制移行ではなく、選択肢が一つ増えるという話です。普通のユーザーは、当面ディストリビューションの標準設定に従えば十分です。

7.0 と 7.1 の関係

Linux 7.0 は、カーネルのバージョンが 7.x 系列に入ったことを示します。7.0 で NTFS 対応が突然書き換えられたわけではありません。NTFS に関する新しい変更は、7.1 の機能マージ段階で入ります。

NTFS は Linux デスクトップユーザーにとって避けて通れないファイルシステムです。デュアルブート、外付けドライブ、USB メモリ、Windows データディスクでよく使われます。問題は、NTFS の書き込み経路が複雑なことです。ファイルシステムドライバーにバグがあると、ユーザーデータへ直接影響します。そのため、カーネルコミュニティは NTFS ドライバーの変更に慎重です。

`ntfs-3g`、`ntfs3`、新 `ntfs`

ntfs-3g はユーザー空間の FUSE ドライバーで、Linux 上の NTFS 読み書きを長く担ってきました。常に最速とは限りませんが、成熟しており、互換性が高く、情報も豊富です。

ntfs3 は Paragon Software が提供し、Linux メインラインに入ったカーネル内 NTFS ドライバーです。経路が短く、VFS との統合も直接的で、理論上の性能も高くなります。ただし、ファイルシステムドライバーには高い保守品質が求められるため、ntfs3 のマージ後も保守ペースやコード品質について議論がありました。

Linux 7.1 で追加される ntfs ドライバーは、Namjae Jeon が保守しています。ゼロから作られたものではなく、古いカーネル ntfs ドライバーを現代化し、読み書き能力を補った別の任意実装です。ntfs3 と併存します。

三者の関係は次のように考えると分かりやすいです。

ntfs-3g：保守的で成熟したユーザー空間実装。
ntfs3：すでにメインラインにあるカーネル内実装。
新 ntfs：7.1 で追加されるカーネル内実装。安定性は今後の観察が必要。

どれを使うべきか

日常利用で急いで切り替える必要はありません。保守的には次の順番が無難です。

重要なデータでは、ディストリビューション標準の方式を使う。多くの場合は ntfs-3g、または検証済みの ntfs3。
性能が必要な場合は ntfs3 を試す。
新しい ntfs ドライバーは、まずテスト用ディスク、一時データ、復旧可能なデータで試す。
重要な NTFS パーティションへ書き込む前にバックアップする。

ntfs3 を手動で使う場合の一般的なマウント例です。

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

一時的に読み取りだけしたい場合は、読み取り専用でマウントできます。

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

現在どのドライバーでマウントされているかは、次のように確認できます。

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

デュアルブート環境での注意

NTFS パーティションが Windows のシステムディスク由来の場合、書き込む前に Windows が完全にシャットダウンされていることを確認してください。高速スタートアップや休止状態は NTFS ボリュームを未完了の状態に残すため、Linux から書き込むと整合性問題が起きることがあります。

確認したい項目は次の通りです。

Windows の高速スタートアップを無効にする。
パーティションが hibernation 状態でないことを確認する。
BitLocker などの暗号化がアクセスを妨げていないことを確認する。
外付けドライブは Windows で正しく取り外す。

これは ntfs-3g、ntfs3、新しい ntfs のどれを使う場合でも同じです。

なぜ複数の NTFS ドライバーが必要なのか

同じファイルシステムに複数の実装が存在することは、Linux では珍しくありません。古い実装、新しい実装、ベンダー実装、コミュニティ実装がしばらく併存し、保守状況と実利用のフィードバックによって主流が決まっていきます。

NTFS では特に保守的な扱いが必要です。

ユーザーデータへのリスクが高い。
互換性の場面が複雑。
実装ごとに性能と安定性の取捨選択が異なる。
ディストリビューションが標準設定を検証する時間が必要。

そのため、Linux 7.1 の新 ntfs ドライバーは、ntfs-3g や ntfs3 をすぐ不要にするものではありません。カーネルコミュニティに、もう一つ保守可能な選択肢を与えるものです。

まとめ

Linux 7.1 で追加される ntfs ドライバーは、任意で使えるカーネル内 NTFS 読み書き実装です。ntfs-3g や ntfs3 と併存し、どちらかを直接置き換えるものではありません。

普通のユーザーは、引き続きディストリビューション標準の方式を使えば十分です。性能や新しいファイルシステム実装を試したい場合は、ntfs3 と新 ntfs の今後の安定性を見ながら、重要データでは必ずバックアップを取ってから切り替えるのが安全です。

sudo と sudo-rs の違い：Rust 版 sudo は何を変えるのか

Fri, 01 May 2026 19:27:08 +0800

sudo は Linux ユーザーにとって最もなじみ深いコマンドの一つである。通常ユーザーが、許可された範囲で一時的により高い権限でコマンドを実行できるようにする。たとえば、ソフトウェアのインストール、システム設定の変更、サービスの再起動などで使われる。

最近 sudo-rs が注目されているのは、Ubuntu 25.10 が従来の sudo を置き換える形で、Rust 実装の sudo-rs をデフォルトで使い始めるためだ。一般ユーザーから見ると、表面上は引き続き sudo と入力する。本当に変わるのはシステムの内側で、実行される実装が Rust 版 sudo になっている可能性がある。

この話では、自然に二つの疑問が出てくる。

従来の sudo に何か問題があるのか。
sudo-rs は日常利用やサーバー設定に影響するのか。

簡単に言えば、普通のデスクトップユーザーはほとんど心配しなくてよい。ただし、サーバーを管理している、複雑な sudoers ルールを書いたことがある、または特殊な sudo の挙動に依存している場合は、きちんとテストする必要がある。

sudo-rs とは

sudo-rs は Rust で書かれた sudo / su の実装である。完全に別物の新しいコマンドを作ることが目的ではなく、従来の sudo の主要機能を再実装しつつ、Rust のメモリ安全性を利用して一般的なセキュリティリスクを下げることを目指している。

従来の sudo は主に C 言語で書かれており、歴史が長く、機能も非常に充実している。その成熟度は安定性をもたらす一方で、保守上の負担にもなる。多くのコードはかなり古い Unix/Linux の利用場面に由来し、その後、大量の互換ロジック、拡張、境界処理が重ねられてきた。

sudo-rs が再実装を選んだ理由には、次のようなものがある。

Rust によりメモリ安全性の問題を減らす。
より現代的なコード構造で保守難度を下げる。
一部の歴史的機能やリスクのあるデフォルト挙動を削る。
Rust に慣れた新しい貢献者を呼び込む。
将来の権限昇格ツールに、より監査しやすい土台を提供する。

ただし、sudo-rs は従来の sudo と 100% 互換の置き換えではない。現在も開発中であり、一部の従来機能はまだ実装されておらず、別の一部は今後も実装されない可能性がある。

一般ユーザーが感じる変化

一般ユーザーにとって、変化はかなり少ない。

これまで通り次のように使う。

`1`	`sudo apt update`

または：

`1`	`sudo systemctl restart nginx`

Ubuntu 25.10 では、sudo が sudo-rs を指す。ユーザーが入力するコマンドを sudo-rs に変える必要はなく、スクリプト内の一般的な sudo 呼び出しも、コマンド名の変更で即座に壊れるわけではない。

見えやすい変化は、パスワード入力時のフィードバックである。 sudo-rs はデフォルトで、パスワード入力時にアスタリスクを表示する。従来の sudo でも設定により同様の挙動にできるが、多くのディストリビューションでは何も表示しない設定がデフォルトだった。

また、一部のエラーや警告メッセージの文面が変わる可能性がある。たとえば、パスワード誤り、権限不足、設定の非互換などでは、以前とまったく同じ文面ではないことがある。人間のユーザーにとって大きな影響はないが、sudo のエラー出力を解析するスクリプトがある場合は確認が必要だ。

管理者が注意すべき違い

本当に注意が必要なのは、システム管理者と上級ユーザーである。

従来の sudo のエコシステムは大きく、多くのサーバーには複雑な sudoers 設定がある。これらの設定には、コマンド引数のマッチング、環境変数の制御、ログ、メール通知、PAM の挙動、ホストグループごとのポリシーなどが含まれることがある。

sudo-rs には現時点で従来の sudo との違いがある。たとえば、元記事では sudo-rs が従来 sudo の sendmail サポートを含まないことに触れている。過去に sudo 使用通知を sendmail で送っていた環境では、移行時に別の方法を用意する必要がある。

認証面では、sudo-rs は PAM を使う。そのため、リソース制限や umask などの挙動は、sudoers ファイルだけに頼るのではなく、より PAM 側で設定する必要がある。以前 sudoers で多くの細部を扱っていた場合、切り替え前にそのルールが今も有効か確認するべきである。

もう一つ重要なのは、コマンド引数位置でのワイルドカード対応だ。 sudo-rs は sudoers ファイルでありがちな設定ミスを避けるため、コマンド引数位置でのワイルドカードをサポートしない。これはセキュリティ上は良いことだが、既存ルールに影響する可能性がある。

Ubuntu で sudo と sudo-rs はどう扱われるか

Ubuntu 25.10 以降、システムはデフォルトで sudo-rs を使う。ユーザーは引き続き sudo と入力し、その下で Rust 実装が動く。

従来の sudo がすぐ消えるわけではない。 Ubuntu の移行設計では、従来の sudo は sudo-ws という形で残される。どうしても従来実装が必要な場合は sudo-ws を使うか、alternatives の仕組みでデフォルト sudo を切り替えられる。

切り替えコマンドは次のような形になる。

`1`	`sudo update-alternatives --config sudo`

ただし、普通のユーザーが積極的に従来 sudo へ戻すことは勧めにくい。 sudoers をカスタマイズしておらず、特殊な挙動にも依存していないなら、ディストリビューションのデフォルトに従うほうが楽である。

古い Ubuntu バージョンで試したい場合、sudo-rs は Ubuntu 24.04 以降 universe リポジトリから入手できる。他のディストリビューションでもパッケージが提供されている可能性はあるが、コマンド名や統合方法は同じとは限らない。

なぜ sudo-rs は Rust を選ぶのか

sudo は高権限ツールである。この種のツールに脆弱性があると、通常のコマンドよりも深刻な結果につながることがある。歴史的にも、sudo には複数の権限昇格脆弱性が存在した。

Rust の強みはメモリ安全性にある。所有権、借用チェック、型システムにより、ダングリングポインタ、境界外アクセス、use-after-free などの一般的な問題を減らせる。これでプログラムが絶対に安全になるわけではないが、C/C++ プロジェクトでよく見られる一群の脆弱性を減らせる。

sudo のように長くセキュリティ上重要な位置にあるツールでは、より安全な言語で書き直すことには現実的な意味がある。これは単なる「Rust を使いたいから Rust」ではなく、保守と監査のコストを下げようとする試みである。

もちろん、言語がすべてのセキュリティ問題を解決するわけではない。権限チェックロジック、設定解析、PAM 連携、環境変数処理、ログ、ユーザー体験は、今後も慎重な設計と長期的なテストを必要とする。

sudo-rs は唯一の選択肢ではない

sudo エコシステムには、もともと他の代替ツールも存在する。

比較的よく知られているのは doas である。 OpenBSD 由来で、より単純で小さな設定を目指している。 sudo ほど複雑ではない点を好むユーザーもいる。

ほかにも、RootAsRole や systemd の run0 など、Rust や systemd 関連の代替案がある。ただし、これらのツールの目的や適用場面は完全には同じではない。

多くの Linux ディストリビューションでは、sudo は今でもデフォルトの選択肢である。 sudo-rs の意味は、ユーザーの習慣を保ちながら、内部実装をより現代的なコード基盤に置き換えようとしている点にある。

移行前に確認すべきこと

個人のデスクトップユーザーなら、ディストリビューションのデフォルト設定に従えばよい。

サーバーやワークステーションを管理している場合は、次の点を確認したい。

複雑な /etc/sudoers または /etc/sudoers.d/ ルールがあるか。
コマンド引数のワイルドカードを使っているか。
sudo のメール通知に依存しているか。
sudo のエラー出力を解析するスクリプトがあるか。
sudoers で umask、リソース制限、環境変数を制御しているか。
LDAP、PAM、SSSD などの認証連携があるか。
automation やデプロイスクリプトが従来 sudo の挙動を前提にしているか。

まずテスト機で確認できる。

sudo -l

その後、重要な保守コマンドを実行し、権限、環境変数、ログ挙動が期待通りか確認する。

sudo-rs へ自分で切り替えるべきか

ディストリビューションがすでにデフォルトで切り替えているなら、普通のユーザーはそのまま受け入れてよい。サーバーや本番環境では、試したいという理由だけで手動置き換えするのは勧めにくい。

より安全な進め方は次の通り。

テスト環境に sudo-rs をインストールする。
既存の sudoers 設定を項目ごとに検証する。
PAM、ログ、監査、automation スクリプトを確認する。
ロールバック方法を確認する。
ディストリビューションが安定した統合を提供してから移行する。

この種のツールは権限チェーン上にあるため、「いくつかのコマンドが動く」だけで安全とは判断しにくい。本当に確認すべきなのは、境界条件と異常系である。

まとめ

sudo-rs は従来 sudo の Rust 実装であり、より現代的で安全なコード基盤で sudo の中核機能を担うことを目指している。 Ubuntu 25.10 がデフォルトで有効化することは、主要ディストリビューションがこの方向を本格的に進め始めたことを示している。

一般ユーザーにとって、変化は小さい。引き続き sudo と入力するだけで、内部実装が sudo-rs になっている可能性があるだけだ。気づくとしても、パスワード入力時にアスタリスクが表示されることや、エラーメッセージが少し変わることくらいである。

システム管理者にとって、重要なのは互換性だ。複雑な sudoers ルール、sendmail 通知、PAM 連携、引数ワイルドカード、sudo 出力に依存するスクリプトがある場合は、アップグレード前にテストすべきである。

Rust による書き直しは万能薬ではない。それでも sudo のようなセキュリティ上重要なツールでは、メモリ安全性リスクと保守の複雑さを減らす方向として、真剣に検討する価値がある。

参考ソース：

X11 と Wayland の違い、長所・短所、選び方

Fri, 01 May 2026 19:23:01 +0800

Linux デスクトップでは、X11 と Wayland という二つの名前をよく目にする。どちらもグラフィック表示に関係しているが、設計された時代、アーキテクチャの考え方、使い勝手はかなり違う。

簡単に言えば、X11 は旧世代のディスプレイプロトコルとエコシステムである。機能は成熟しており互換性も高いが、アーキテクチャは複雑で、セキュリティモデルは古い。 Wayland は新世代のディスプレイプロトコルで、中間層を減らし、セキュリティと滑らかさを高めることを目指している。ただし、一部のソフトウェアやワークフローはまだ適応が必要だ。

日常利用だけを考えるなら、結論は次の通り。

新しく Linux デスクトップを入れるなら、まず Wayland を試す。
古いソフトウェア、複雑なリモートデスクトップ、特殊な入力デバイス、一部の専門ツールが必要なら、X11 のほうがまだ安定しやすい。
ゲームや通常のオフィス用途では、Wayland はかなり実用的になっている。
互換性の問題が出たら X11 に戻せばよい。これは信条の問題ではない。

X11 とは

X11 は X Window System や Xorg とも呼ばれ、Linux や Unix デスクトップで長年使われてきたグラフィックシステムである。その設計思想は、プログラムをあるマシンで実行し、ウィンドウを別のマシンに表示するという、初期のネットワークコンピューティング環境に由来する。

X11 の典型的な構造は次のようになる。

アプリケーションがウィンドウ内容を描画する。
X Server が表示、入力、基本的なウィンドウ操作を管理する。
ウィンドウマネージャーが枠、移動、重なり順を担当する。
コンポジターが影、透明効果、アニメーション、ティアリング制御などを担当する。

この構造は柔軟で、X11 は大量のツールと拡張を蓄積してきた。しかし時間が経つにつれて、問題も明確になった。コンポーネントが多く、経路が長く、権限境界が緩く、現代的なデスクトップ要求の多くを拡張やパッチで支えている。

Wayland とは

Wayland は、従来型の完全なディスプレイサーバーというより、より現代的なディスプレイプロトコルである。 Wayland では、コンポジターが同時にディスプレイサーバーの役割を担うことが多い。 GNOME の Mutter、KDE の KWin、wlroots 系のコンポジターはいずれも Wayland compositor として動作できる。

Wayland の典型的な構造はより短い。

アプリケーションが自分でウィンドウ内容をレンダリングする。
コンポジターがアプリケーションから送られた buffer を受け取る。
コンポジターがウィンドウ、入力、ディスプレイ出力、合成を一元管理する。
最終的な画面はカーネルのグラフィックスタックへ直接渡されて表示される。

この設計により、従来の X11 にあった X Server、ウィンドウマネージャー、コンポジター間の遠回りが減る。また、権限制御も明確になる。アプリケーションはデフォルトで他のウィンドウ内容を自由に読めず、グローバルなキーボード入力も勝手に監視できない。

アーキテクチャの違い

最も大きな違いは、責務の分け方にある。

X11 では、X Server が中心にあり、多くのアプリケーションがそれとやり取りできる。ウィンドウマネージャー、コンポジター、入力メソッド、スクリーンショットツール、リモート制御ツールも、X11 のオープンなインターフェースを通じて多くの情報を取得できる。これは高い互換性をもたらす一方で、セキュリティ上の問題も生む。

Wayland では、コンポジターが中心である。アプリケーションは他のウィンドウ内容を直接取得できず、すべてのキーボード入力をデフォルトで監視することもできない。スクリーンショット、録画、画面共有、グローバルショートカット、リモート制御などは、デスクトップポータル、PipeWire、またはコンポジターが提供する制御されたインターフェースを通す必要がある。

整理すると次のようになる。

比較項目	X11	Wayland
設計時代	古い	新しい
中心コンポーネント	X Server	Compositor
コンポジターの役割	任意または追加コンポーネント	中核コンポーネント
アプリ間の隔離	弱い	強い
リモート表示	元から強い考え方	新しいツールチェーンに依存
互換性	非常に強い	まだ補完中
現代的なデスクトップ体験	拡張とパッチに依存	設計上、現代的な要求に近い

X11 の長所

X11 最大の長所は成熟度である。長年動いてきたため、ほぼすべての Linux グラフィカルアプリケーションが X11 で動作する。古いツール、専門ソフトウェア、特殊な入力メソッド、リモート制御、 automation スクリプトも、X11 を優先してサポートしていることが多い。

もう一つの長所は操作しやすさである。多くのツールはウィンドウの読み取り、入力のシミュレーション、画面キャプチャ、ウィンドウ移動、キー入力監視を直接行える。これは automation、リモート支援、ウィンドウ管理スクリプト、特殊なワークフローに便利だ。

次のような用途があるなら、X11 は今でも現実的な選択肢である。

古い GUI ソフトウェアを使う。
xrandr、xinput、xdotool、wmctrl に依存している。
従来型のリモートデスクトップやウィンドウ転送を使う。
特殊なスクリーンショット、録画、キーボード/マウスマクロツールが必要。
あるアプリが Wayland ではまだ不安定。

X11 の短所

X11 の短所は主に歴史的な負担から来ている。

まず、セキュリティモデルが古い。従来の X11 セッションでは、通常のアプリケーションが他のウィンドウ入力を監視したり、画面内容を取得したり、キーボードやマウス操作をシミュレートしたりできることが多い。現代的なデスクトップセキュリティの観点では、これは受け入れにくい。

次に、レンダリング経路が複雑である。 X11 は Composite、GLX、DRI、RandR、Present など、多くの拡張を経てきた。これらの拡張により現代的なデスクトップを支え続けられたが、グラフィックスタックも複雑になった。高リフレッシュレート、マルチモニター、異なるスケーリング、混在 DPI、低遅延入力などでは、X11 は細かな問題が出やすい。

さらに、X11 の保守の重点は徐々に互換性へ移っている。主要なデスクトップ環境は今でも X11 をサポートしているが、新機能や新しい最適化は Wayland に先に入ることが多い。

Wayland の長所

Wayland の利点は、主に現代的なデスクトップ体験にある。

レンダリング経路がより直接的である。アプリケーションが buffer をレンダリングし、コンポジターが一元的に合成して表示するため、従来の X11 アーキテクチャにあった遠回りが減る。アニメーション、ウィンドウ移動、高リフレッシュレート、マルチモニター、タッチパッドジェスチャー、分数スケーリングなどでは、Wayland のほうがきれいに実装しやすい。

セキュリティも Wayland の重要な長所である。アプリケーションはデフォルトで他のウィンドウを自由にキャプチャできず、グローバルなキーボード入力も無条件には監視できない。スクリーンショット、録画、画面共有にはユーザー許可が必要で、通常はデスクトップポータルと PipeWire を通じて処理される。

Wayland は現代的なハードウェアにも向いている。タッチパッドジェスチャー、HiDPI、可変リフレッシュレート、モニターごとの異なるスケーリングなどは、Wayland のほうが自然に扱いやすい。 GNOME と KDE も近年、多くのデスクトップ体験改善を Wayland セッションへ投入している。

Wayland の短所

Wayland の問題は「使えない」ことではなく、エコシステムがまだ移行中であることだ。

一部のツールは、グローバルキー監視、ウィンドウ列挙、自動クリック、画面取得、ウィンドウ移動など、X11 のオープンな機能に依存していた。 Wayland ではこれらをそのまま持ち込めず、ポータル、コンポジタープロトコル、またはデスクトップ環境 API を通す必要がある。そのため、一部の古いツールは動かなくなったり、特定のデスクトップ環境でしか動作しなかったりする。

リモートデスクトップも典型的な問題である。 X11 にはネットワーク透過性という歴史的な設計があり、現代の使用体験が常に良いとは限らないが、多くのツールが成熟している。 Wayland でリモートデスクトップを使うには、PipeWire、RDP、VNC、デスクトップポータル、またはコンポジターのサポートが必要で、体験は GNOME、KDE、Sway などの実装に依存する。

入力メソッドもかつては痛点だった。現在は Fcitx5 や IBus が主要な Wayland デスクトップでかなり改善されているが、一部の Electron アプリ、古いプログラム、特殊な組み合わせでは、候補ウィンドウの位置、フォーカス、ショートカットに問題が出ることがある。

NVIDIA も長く Wayland の障害の一つだった。近年は NVIDIA ドライバとデスクトップ環境のサポートが大きく改善したが、古い GPU、古いドライバ、特殊なマルチモニター構成では、まだ X11 のほうが安定する場合がある。

Xwayland の役割

Wayland に切り替えると X11 アプリがまったく使えなくなる、と思っている人も多い。実際にはそうではない。

Wayland デスクトップは通常、Xwayland を使って古い X11 アプリケーションを互換実行する。アプリケーションは自分が X11 上で動いていると思い、実際のウィンドウ内容は Wayland コンポジターへ渡されて表示される。

これにより移行はかなり滑らかになる。

ネイティブ Wayland アプリは Wayland を使う。
古い X11 アプリは Xwayland を使う。
ユーザーは一つのデスクトップセッションで両方の種類のプログラムを同時に使える。

ただし、Xwayland は万能ではない。グローバル入力監視、ウィンドウ管理スクリプト、低レベルの X11 拡張に依存するツールは、やはり制限を受けることがある。

性能はどちらが良いか

Wayland が必ず X11 より速い、または X11 が必ず安定している、と単純には言えない。実際の挙動は、デスクトップ環境、グラフィックドライバ、アプリの種類、使用場面に依存する。

一般的には次のように考えられる。

通常のデスクトップアニメーションや高リフレッシュレート表示では、Wayland のほうが滑らかに感じやすい。
混在 DPI やマルチモニターのスケーリングでは、Wayland に利点がある。
古いアプリや特殊なツールでは、X11 のほうが問題が少ない。
ゲームでは、Xwayland とネイティブ対応により Wayland はかなり成熟しているが、一部のゲームやキャプチャツールはまだ X11 を好む場合がある。
専門的なグラフィック、リモート制御、automation スクリプトは、具体的なツールごとに確認する必要がある。

多くの一般ユーザーにとって、性能は最大の違いではない。実際の体験を左右するのは、互換性、セキュリティ境界、モニター構成、入力デバイス対応である。

スクリーンショット、録画、画面共有

これは Wayland で最も誤解されやすい部分である。

X11 では、スクリーンショットや録画ツールが通常そのまま画面を取得できる。これは便利だが、悪意あるプログラムが画面を盗み見しやすいという意味でもある。

Wayland では、アプリケーションが自由に画面を取得することはできない。スクリーンショット、録画、配信、会議での画面共有は、通常デスクトップポータルと PipeWire を通り、ユーザーの許可を必要とする。これはより安全だが、アプリケーション側が新しいインターフェースをサポートしている必要がある。

そのため、ある会議ソフト、録画ツール、スクリーンショットツールが Wayland でうまく動かない場合、それは Wayland が「対応していない」という意味とは限らない。むしろ、そのアプリがポータルや PipeWire に十分適応していない可能性が高い。

ゲームではどちらを選ぶべきか

現在の Linux ゲームは、もはや X11 専用ではない。 Steam、Proton、Mesa、KDE、GNOME、Gamescope、Xwayland により、Wayland でのゲーム体験は大きく改善している。

AMD または Intel GPU を使っているなら、Wayland は日常のゲーム環境として十分使えることが多い。 NVIDIA の場合も新しいドライバではかなり実用的になっているが、ドライバとデスクトップ環境は新しめに保つのがよい。

ゲーム用途では次のように選べる。

通常の Steam / Proton ゲーム：まず Wayland を試す。
録画、配信、オーバーレイ、入力遅延に問題が出た場合：X11 と比較する。
Gamescope を使う場合：Wayland エコシステムのほうが合う。
古い GPU や古いドライバを使う場合：X11 のほうが楽なことがある。

リモートデスクトップと automation

ワークフローがリモートデスクトップ、ウィンドウ automation、グローバルなキーボード/マウス制御に依存している場合は、より慎重に考える必要がある。

X11 はこうした場面でツールが多く、挙動も直接的である。たとえば、スクリプトでウィンドウを制御する、クリックをシミュレートする、特定ウィンドウを取得する、といった操作は X11 のほうが簡単なことが多い。

Wayland は安全設計上、通常のアプリケーションが他のウィンドウを自由に制御することを許さない。そのため、automation ツールはデスクトップ環境が提供するインターフェースを使うか、専用のリモートデスクトップ実装を使う必要がある。 GNOME と KDE はこうした機能を補っているが、デスクトップ間の一貫性はまだ X11 ほどではない。

普通のデスクトップユーザーなら Wayland で問題ない。リモート制御、automation テスト、ウィンドウ管理スクリプトを重用しているなら、X11 のほうが合う可能性がある。

自分がどちらを使っているか確認する

現在のセッション種別は、環境変数で確認できる。

`1`	`echo $XDG_SESSION_TYPE`

出力が次なら：

wayland

現在は Wayland セッションである。

出力が次なら：

x11

現在は X11 セッションである。

GNOME や KDE などのデスクトップでは、ログイン画面の歯車メニューやセッション選択から X11 / Wayland を切り替えられることが多い。

選び方

次のように判断できる。

場面	推奨
新しいPC、主要ディストリビューション、通常のオフィス用途	Wayland 優先
最新の GNOME / KDE	Wayland 優先
マルチモニター、HiDPI、高リフレッシュレート	Wayland 優先
古いソフトウェア、古い GPU、古いドライバ	X11 優先
リモートデスクトップ、ウィンドウスクリプト、automation テスト	X11 優先、または Wayland を個別検証
ゲーム	まず Wayland、問題があれば X11
会議の画面共有、録画	ソフトウェアの PipeWire / ポータル対応次第
セキュリティ重視、マルチユーザーデスクトップ	Wayland 優先

Wayland は今後の方向性だが、X11 がすぐ消えるわけではない。両者はしばらく共存し続ける。

まとめ

X11 の強みは成熟、互換性、豊富なツールである。古いソフトウェア、リモートデスクトップ、ウィンドウ automation、一部の特殊なワークフローに向いている。弱点はセキュリティ境界が弱く、アーキテクチャが複雑で、現代的なマルチモニター、高リフレッシュレート、混在スケーリングに対してすっきりしない点だ。

Wayland の強みは、より現代的なアーキテクチャ、より良いセキュリティ、より直接的な表示経路である。 HiDPI、タッチパッドジェスチャー、マルチモニター、現代的なデスクトップ体験にも向いている。弱点は、一部の古いツール、リモート制御、スクリーンショット/録画、入力メソッドでまだ適応コストがあることだ。

一般ユーザーは Wayland をデフォルトの選択肢として考えてよい。特定のアプリや周辺機器が正常に動かない場合だけ、X11 に戻して確認すればよい。 Linux デスクトップにとって、これはどちらかを信じる話ではなく、ハードウェア、ソフトウェア、ワークフローに合うほうを選ぶ話である。

参考ソース：

Linux Kernel 7.0 更新内容の整理

Fri, 01 May 2026 14:46:07 +0800

Linux カーネルのバージョン番号は、以前からセマンティックバージョニングではない。メジャーバージョンの上昇は、主にメンテナンス周期上のロールアップに近い。 Linus Torvalds もリリースメールで 7.0 を通常のリリースとして説明しており、最後の週はネットワーク、アーキテクチャ、ツール、セルフテスト、ドライバまわりの小さな修正が中心だった。

本当に注目すべきなのは、この増分更新の中身である。 Linux 7.0 は、ファイルシステム、メモリ管理、ハードウェアサポート、セキュリティ分離、Rust サポート、ドライバ整理など、複数の領域にまたがっている。

ファイルシステム：XFS、EXT4、NTFS3 に変更

Linux 7.0 で最も体感しやすい更新の一つはファイルシステムだ。

XFS には自己修復に関連する機能が入った。新しい汎用ファイルシステムエラー報告の仕組みと組み合わせることで、ファイルシステムは metadata の破損や I/O エラーを、より統一された方法でユーザー空間へ伝えられる。適切なシステムサービスと連携すれば、XFS はファイルシステムをマウントしたまま一部の修復処理を自動で扱える。すべてのディスク破損を無痛で直せるという意味ではないが、サーバーや長時間稼働するシステムでは、エラー検出から修復までの経路がより整う。

EXT4 は並行 direct I/O 書き込み性能を引き続き改善している。バックアップ、ビルド、ダウンロード、データベース、ログ処理などが同時にディスクへ書き込む環境では、こうした最適化により並行書き込み経路がより安定する。すべてのデスクトップユーザーがすぐ体感する変化ではないが、高 I/O の場面では意味がある。

NTFS3 も比較的大きなドライバ更新を受けている。内容には delayed allocation、iomap ベースのファイル操作、大きなディレクトリを走査する場面での readahead 改善が含まれる。 Linux から Windows パーティションや外付け NTFS ディスクをよく使う場合は、注目してよい更新だ。

さらに exFAT は複数 cluster の順次読み取りを改善しており、一部の小さな cluster のデバイスでは順次読み取りが速くなる。

メモリと swap：メモリ圧迫時の挙動を引き続き改善

Linux 7.0 は、ここ数バージョンで進んできた swap サブシステムの整理を継続している。今回の重点の一つは、swap からメモリへ読み戻す経路の改善だ。特に、複数のプロセスが同じスワップアウト済みページを共有している場合、スループットが向上する。

デスクトップユーザーにとっては、「急にシステムが速くなった」と感じる種類の変化ではないかもしれない。しかし、メモリが厳しい環境、コンテナが密集したホスト、永続化を有効にした Redis 系サービス、または zram とバックエンドディスクを組み合わせた構成では、メモリ圧迫時の揺れを減らす助けになる。

zram 関連の経路も最適化されている。以前は一部のケースで、カーネルが zram ページをいったん展開してからバックエンドデバイスへ書き込む必要があった。新しい経路では圧縮データを直接書き込めるため、不要な処理を減らせる。

CPU と性能：Intel TSX auto、スレッドとファイル操作の高速化

Linux 7.0 は Intel TSX のデフォルト方針を調整した。過去のセキュリティ問題により、多くのプロセッサでは TSX がデフォルトで無効化されていた。現在のカーネルはより細かい auto 方針を採用し、影響を受ける CPU では引き続き無効化し、影響を受けない、または有効化に適した CPU では自動的に有効化できる。

これは一部のマルチスレッドワークロード、特にトランザクショナル同期拡張に依存するアプリケーションに役立つ可能性がある。ただし、汎用的な高速化スイッチではない。実際の効果は CPU 型番とアプリケーションがその機能を使うかどうかに依存する。

また、Linux 7.0 には PID 割り当て、スレッドの作成/破棄、ファイルの open/close 経路の最適化も含まれる。これらは単独で大きく宣伝される機能ではないが、システム応答性や高並行サービスでの小さな改善として積み上がる。

ハードウェアサポート：新プラットフォームの準備と既存デバイスの改善

Linux 7.0 は大量のハードウェア有効化作業を継続している。この種の更新は、まだ広く出回っていない新プラットフォームへの準備と、すでにユーザーの手元にあるデバイスの改善に分けられる。

新プラットフォームでは、Linux 7.0 に Intel Nova Lake、Intel Crescent Island、AMD の新しいグラフィックス IP、AMD Zen 6 に関する準備がさらに含まれる。普通のユーザーにとってすぐ役立つとは限らないが、新しいハードウェアが登場した後に、より早くメインラインカーネルで対応できるかを左右する。

ARM64 とシングルボードコンピュータでは、Rockchip RK3588/RK3576 の H.264/H.265 ハードウェア動画デコードがメインラインサポートの範囲に入った。これは Orange Pi 5 や Radxa ROCK 5 などのデバイスが、ハードウェアデコード体験のためにベンダー BSP カーネルへ完全に依存しなくてよくなることを意味する。

ノートPCや周辺機器にも細かな更新が多い。

ASUS WMI は ROG、TUF 機種のバックライト、キーボードライト、ファンホットキー対応を改善。
HP WMI は一部 Victus 機種の手動ファン制御を追加し、音声インジケーターライトを修正。
Lenovo WMI は Legion デバイス向けにより多くの HWMON 監視情報を公開。
Intel Xe グラフィックスドライバはより多くの温度センサーを公開。
Intel Arc B シリーズのディスクリートGPUは、より深い PCIe 省電力状態へ入れる。
Rock Band 4 Bluetooth ギターと Logitech K980 Bluetooth キーボードのカーネルサポートが改善。

一つ一つは小さな変更だが、ノートPC、ゲームデバイス、開発ボード、周辺機器のユーザーにとっては、メインラインカーネルでの対応が進むほど、その後のディストリビューション保守が楽になる。

セキュリティと分離：io_uring で BPF フィルタリングが可能に

Linux 7.0 は io_uring に BPF フィルタリング機能を追加した。これはコンテナ、サンドボックス、高いセキュリティ要件を持つ環境で重要になる。

以前は攻撃面を減らすため、管理者が io_uring を丸ごと無効化することがあった。現在は BPF フィルタリングにより、許可する操作をより細かく制限できる。つまり、「全開」か「全停止」だけを選ぶ必要がなくなる。

これで io_uring のセキュリティリスクが自動的に消えるわけではない。しかし、システム管理者やランタイムフレームワークにとって、より制御しやすい分離手段が増える。

Rust サポートは単なる実験ラベルではなくなった

Linux 7.0 では、Rust for Linux の状態がさらに安定した。これはカーネルが大規模に Rust へ書き換えられるという意味ではなく、C が置き換えられるという意味でもない。

より正確には、カーネル内で Rust を使うための基盤が、より正式な段階に入ったということだ。今後、新しいドライバ、新しいサブシステム、または一部のセキュリティに敏感なコードでは、適した場面で Rust を選べる。これは段階的な道筋である。まずインターフェース、ビルド、ドキュメント、保守プロセスを安定させ、その後で具体的なコードを少しずつ増やしていく。

古い機能の整理：laptop_mode の削除

Linux 7.0 は laptop_mode を削除した。これは長い歴史を持つ省電力機能で、主に機械式ハードディスク時代のノートPCを対象に、ディスクのスピンアップを減らして電力を節約するものだった。

現在のノートPCは SSD が主流であり、カーネル内のメモリ回収、ブロックデバイス、ファイルシステム経路も大きく変化している。この古い仕組みを残し続けると保守コストが増え、テストカバレッジも理想的ではない。削除により、古いコードが現代的な経路へ与える影響を減らせる。

AI 関連キー：新世代のキーボード操作に向けた準備

Linux 7.0 は、コンテキスト AI 操作向けにいくつかの新しい HID keycode を追加した。たとえば、選択中の内容に対して操作を実行する、コンテキスト生成内容を挿入する、コンテキスト検索を開始するといった用途である。

これはカーネルに AI 機能が組み込まれたという意味ではない。将来のノートPCキーボードや周辺機器のために入力イベント定義を用意し、デスクトップ環境、アプリ、ベンダーツールがそれらのキーを認識できるようにするものに近い。実際に何ができるかは、ディストリビューション、デスクトップ環境、アプリケーション層の統合に依存する。

すぐにアップグレードすべきか

ローリングリリース系のディストリビューションを使っている場合、Linux 7.0 は通常のシステム更新として自然に入ってくる可能性が高い。 Ubuntu 26.04 LTS のような新しいディストリビューションでは、7.0 がデフォルトまたは主要なカーネルバージョンとして採用されることもある。

ただし、対象のマシンが本番環境、NAS、仮想化ホストである場合、またはクローズドソースドライバや独自カーネルモジュールに依存している場合は、バージョン番号が 7.0 になったという理由だけで手動アップグレードするのは勧めにくい。より安全な進め方は次の通り。

ディストリビューションが正式なカーネルパッケージを提供するのを待つ。
GPU、ネットワークカード、ZFS、VirtualBox、VMware、DKMS モジュールの互換性を確認する。
テスト機またはスナップショット環境で先に検証する。
7.0.x のポイントリリースでの修正状況を追う。

kernel.org の v7.x ディレクトリを見る限り、7.0.1、7.0.2、7.0.3 はすでに順次公開されている。手動でビルドまたはテストするなら、最初の 7.0 tarball だけを見るのではなく、最新の安定版 7.0.x を優先したほうがよい。

まとめ

Linux Kernel 7.0 は、「メジャーバージョンが上がったからすべてを書き換えた」リリースではない。むしろ、範囲の広い通常のカーネル更新に近い。ファイルシステムはより信頼性を増し、swap と I/O 経路は引き続き最適化され、新しいハードウェア対応は前進し、Rust、io_uring の分離、HID 入力定義も長期的な進化に必要な基盤を補っている。

一般的なデスクトップユーザーにとって、最も実用的な変化はハードウェアサポート、グラフィックスドライバ、省電力、ファイルシステム修復にあるかもしれない。サーバーや開発者にとっては、XFS のエラー報告、自己修復、io_uring BPF フィルタリング、swap 最適化、新プラットフォーム対応がより注目に値する。

参考ソース：

Ubuntu 26.04 LTS の GPU とハードウェア対応アップデート: CUDA、ROCm、DPC++、そして各種プラットフォームの変更

Sun, 26 Apr 2026 19:35:57 +0800

前の記事が Ubuntu 26.04 LTS のデスクトップ全体像だったとすれば、こちらはハードウェアと計算基盤まわりの補足版です。今回の 26.04 では、AI、GPU コンピューティング、プラットフォーム互換性に関わる項目が、メインアーカイブや正式サポートの範囲にかなり取り込まれています。

先に結論を言うと、今回の注目点は単なるデスクトップやカーネルの更新ではなく、Ubuntu が Intel、NVIDIA、AMD の GPU コンピューティングスタックを、より体系的にディストリビューションへ取り込み始めたことです。

1. Intel DPC++ と関連コンポーネントが Ubuntu Archive に追加

26.04 から、Intel のオープンソース oneAPI DPC++ コンパイラが Ubuntu Archive から直接利用できるようになり、SYCL コードのビルドに使えます。ランタイムには Intel GPU 向けアダプタも含まれます。

あわせて、次の関連コンポーネントも Ubuntu リポジトリで利用可能になりました。

oneDPL。DPC++ library として、より高生産性な開発 API を提供
oneDNN。dpclang-6 でビルドされており、Intel GPU 上で実行可能

つまり、すでに SYCL、ヘテロジニアスコンピューティング、あるいは Intel GPU 上の AI ワークロードを見ている人にとって、Ubuntu 上での導入経路がかなり素直になったということです。従来のように外部スタックを丸ごと別管理する必要が薄くなります。

実運用上の注意点として、Ubuntu はこれらの Intel GPU 関連機能を使うにはユーザーが render グループに属している必要があるとも明記しています。

2. NVIDIA CUDA toolkit も `apt` で直接導入可能に

多くの開発者や運用担当者にとって、これは今回の更新の中でもかなり実用的な変更でしょう。

26.04 から、NVIDIA CUDA toolkit を Ubuntu Archive から直接インストールできます。

`1`	`sudo apt install cuda-toolkit`

意味があるのは、単にセットアップ手順が少し減るという話だけではありません。

Ubuntu 向けにソフトウェアを配布する開発者にとっては、CUDA runtime への依存関係を宣言するだけでよくなり、実際のインストールや互換性管理は Ubuntu 側がディストリビューションレベルで面倒を見る形になります。CUDA が Ubuntu 上でよりネイティブなシステム機能に近づき、別管理の外部スタックとして抱え込む必要が減るわけです。

3. AMD ROCm 7.1.0 が Universe に追加

AMD 側では、Ubuntu Universe に ROCm 7.1.0 が入りました。

このライブラリ群が提供する主なものは次の通りです。

AMD GPU 向け AI 学習・推論のバックエンド基盤
機械学習および高性能計算向けのソフトウェア基盤

さらに Canonical は、ROCm 関連コンポーネントを自社の CI/CD パイプラインで継続的に検証していると述べています。autopkgtests に加えて、次のようなユーザー空間アプリケーションも対象です。

llama.cpp
pytorch
Blender
Lemonade Server

ここはかなり重要です。Ubuntu は単にパッケージを置いただけではなく、ROCm をメンテナブルなソフトウェアスタックとして扱い、継続的に検証していることを意味します。

4. 本当のポイントは 3 社の GPU エコシステムが同時に進んでいること

DPC++、CUDA、ROCm を並べて見ると、26.04 の方向性がわかりやすくなります。

Intel: SYCL / oneAPI 系の機能を公式リポジトリへ取り込む
NVIDIA: CUDA toolkit にディストリビューション管理の導入経路を与える
AMD: ROCm 7.1.0 を Universe に入れ、継続的な検証も行う

Ubuntu 上で次のような用途に触れる人ほど、この更新の意味を感じやすいはずです。

ローカル LLM 推論
GPU アクセラレーションを使った学習やファインチューニング
Blender、科学技術計算、HPC
複数の GPU プラットフォームをまたぐ開発環境

要するに、Ubuntu は「GPU ドライバが入る OS」から一歩進み、AI と GPU コンピューティングに必要なユーザー空間ソフトウェアスタックもより包括的に担うディストリビューションになりつつあります。

5. NVIDIA Dynamic Boost がデフォルトで有効化

25.04 以降、対応する NVIDIA 搭載ノート PC では Dynamic Boost がデフォルトで有効になっています。

仕組み自体はわかりやすく、システム負荷に応じて CPU と GPU の間で消費電力を動的に振り分けます。ゲーム用途では、必要なときに GPU へより多くの電力を回し、性能を引き上げる形になります。

ただし有効になる条件は 2 つあります。

AC 電源に接続されていること
GPU 負荷が十分に高いこと

バッテリー駆動時には動作しません。

6. 新しい Intel 内蔵 GPU / 外付け GPU のサポートも前進

Ubuntu は新しい Intel GPU への対応も引き続き進めています。主な対象は次の通りです。

統合 GPU:

Intel Core Ultra Xe2
Intel Core Ultra Xe3

ディスクリート GPU:

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

これらのデバイスに関連して、Ubuntu はすでに利用可能な機能も挙げています。

Intel Embree を利用した GPU / CPU レイトレーシング描画性能の向上。Blender 4.2+ などで恩恵あり
“Battlemage” デバイスで AVC、JPEG、HEVC、AV1 のハードウェアエンコードをサポート
Intel Compute Runtime に新しい CCS 最適化を導入
Intel Xe GPU のデバッグサポートを有効化

さらに後続の 25.10 では、次のような機能強化も続きます。

Linux kernel 6.17 を通じて、開発コードネーム Panther Lake の次世代 Intel クライアントプラットフォームを初期サポート
IOMMU、PCIe サブシステム、マルチ GPU サポートの改善
Mesa 25.2.3 で Battlemage と Panther Lake 向けに VK_KHR_shader_bfloat16 を有効化
intel-media-driver 25.3.0 で Panther Lake のデコードと VP9 エンコードを追加
intel-compute-runtime 25.31 で Level Zero の USM プールやローカルデバイスメモリ上のイベント確保戦略を調整
level-zero 1.24 と level-zero-raytracing 1.1.0 で仕様対応と RTAS 拡張を強化

7. Nvidia デスクトップのサスペンド復帰も安定化

25.10 から、Ubuntu はプロプライエタリな Nvidia ドライバでサスペンド復帰を有効化し、復帰時の破損やフリーズを減らしています。

見た目に派手な変更ではありませんが、長時間稼働させるデスクトップや、サスペンドと復帰を繰り返す環境ではかなり大事な改善です。

8. ARM、Raspberry Pi、RISC-V、IBM Z でも要件変更がある

GPU ソフトウェアスタック以外にも、今回のリリースノートにはプラットフォーム面で覚えておきたい変更がいくつかあります。

ARM64 デスクトッププラットフォーム

25.10 から、ARM64 向け linux-generic カーネルは、UEFI で起動する ARM64 デスクトッププラットフォームへの互換性をより広く提供します。

Raspberry Pi の新しいブートレイアウト

25.10 で導入され、26.04 でも継続調整されている変更の 1 つが、Raspberry Pi 向けブートパーティションの新レイアウトです。

目的はブート信頼性の向上で、新しく書き込まれたブート資産はいったん「テスト」され、問題がなければ新しい “known good” セットとして確定されます。

特に覚えておきたいのはファームウェア日付の条件です。

Pi 3 / 3+ / CM3+ / Zero 2W: 追加作業は不要。ブートファームウェアはイメージ自体に含まれる
Pi 4 / 400 / CM4: ブートファームウェアの日付が 2022-11-25 以前であってはならない
Pi 5 / 500 / CM5: ブートファームウェアの日付が 2025-02-11 以前であってはならない

確認コマンドは次の通りです。

`1`	`sudo rpi-eeprom-update`

ファームウェアが古く、かつ Ubuntu 24.04 LTS 以降を使っているなら、次のように更新できます。

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi デスクトップイメージは desktop-minimal ベースに

25.10 から、Raspberry Pi 向け Ubuntu Desktop イメージは完全な desktop seed ではなく、desktop-minimal ベースになりました。

Ubuntu が示している利点は明確で、デフォルトのアプリセットが小さくなり、非圧縮イメージと実システムの両方で約 777MB を節約できます。

アップグレード後にこのデフォルトアプリ群をまとめて削除したい場合は、次を使えます。

`1`	`sudo apt purge ubuntu-desktop --autoremove`

一部のアプリを残したいなら、先に apt で手動インストール扱いにしておけば除外できます。

Raspberry Pi の swap は cloud-init 管理に

25.10 から、Raspberry Pi デスクトップイメージ上の swap ファイル作成は cloud-init が担当します。
初回起動前に swap サイズを調整したい場合は、ブートパーティション上の user-data を直接編集できます。

RISC-V の要件が引き上げ

25.10 から、Ubuntu 26.04 LTS の RISC-V 版は RVA23S64 ISA profile を実装したハードウェアを必要とします。

この要件を満たさないシステムでは Ubuntu 26.04 LTS を動かせません。もし以前の RVA20 プロセッサコアを使ったボードを使っているなら、Ubuntu 24.04 LTS のサポートラインに留まる必要があります。

Ubuntu の説明では、2026 年 4 月 時点で実機の RVA23S64 ハードウェアはまだ存在しません。そのため、現在サポートされる唯一の環境は、実質的には -cpu rva23s64 を指定した QEMU 仮想環境です。

IBM Z の最低要件は z15 に

26.04 から、s390x アーキテクチャの最低要件は z15 へ引き上げられました。

つまり次のようになります。

z14 / LinuxONE II およびそれ以前のシステムでは Ubuntu 26.04 LTS をインストールできない
z15 / LinuxONE III 以降では性能向上が期待できる

9. この内容を先に読むべき人

次のようなケースでは、この文章のほうがデスクトップ概要より優先度が高いはずです。

Ubuntu 上で CUDA、ROCm、SYCL、ローカル AI 推論を使う
Intel、NVIDIA、AMD の GPU を使った開発や計算処理を行う
Raspberry Pi、ARM64、RISC-V、IBM Z など、標準的な x86 以外のプラットフォームを運用している
アップグレード後のリポジトリ可用性、ドライバ挙動、ランタイム、プラットフォーム要件に敏感である

10. ひと言でまとめると

Ubuntu 26.04 LTS のハードウェアと AI スタック面での要点は、どこか 1 社の GPU だけが大きく強化されたことではありません。Intel の DPC++、NVIDIA の CUDA、AMD の ROCm が、より公式に、よりリポジトリ内で、より保守しやすい形で Ubuntu エコシステムへ入ってきたことです。

これまで Ubuntu を「まず OS を入れて、その上に GPU 環境は自分で組むもの」と見ていたなら、26.04 は AI やヘテロジニアスコンピューティングのワークロードを、ディストリビューション側がより積極的に支える方向へ進み始めた版だと言えます。

Ubuntu 26.04 LTS リリース：GNOME 50 と Linux 7.0 でデスクトップが大きく更新

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS は 2026 年 4 月 23 日 に公開され、コードネームは Resolute Raccoon です。今回は新しい長期サポート版で、標準サポートは 2031 年 4 月 まで続きます。Ubuntu Pro を使う場合は、セキュリティメンテナンスを 10 年 まで延長できます。

Ubuntu 24.04 LTS からアップグレードする場合、この版は単なる定例更新ではありません。24.10、25.04、25.10 の主な変化もまとめて取り込んでいます。なので、この記事は「アップグレード前に何を見ておくべきか」を素早く把握するための要約として読むのがいちばん向いています。

今回のリリースで特に重要な更新だけを先に押さえるなら、まず次の 4 点です。

GNOME 50 が LTS に入り、デスクトップ体験と表示まわりのサポートが一段進みました
Linux kernel 7.0 が新しい基準になり、ハードウェア対応と今後の保守基盤が更新されました
Ubuntu Desktop は正式に全面 Wayland へ移行しました
既定アプリ群がまとめて更新され、Firefox、LibreOffice、Thunderbird、GIMP が大きく新しくなりました

1. まずは重要な更新を確認

Ubuntu 26.04 LTS は長期サポート版で、標準サポートは 2031-04 までです
デスクトップ環境は GNOME 50 に更新されました
汎用カーネルは Linux kernel 7.0 に更新されました
Ubuntu Desktop のセッションは Wayland のみになりました
古いバージョンから 26.04 へ大きく飛び越して直接アップグレードすることはできません

まだ Ubuntu 22.04 LTS または 25.04 を使っている場合、公式にはまず Ubuntu 24.04 LTS か 25.10 へ上げてから、さらに 26.04 LTS へ進むことが推奨されています。

2. 最大の変化その 1：GNOME 50 が LTS に入った

今回のデスクトップ側で最もわかりやすい変化は、GNOME 50 がついに LTS に入ったことです。一般ユーザーにとって価値があるのは、単発の目立つ新機能というより、デスクトップ全体の使い勝手がまとめて良くなった点です。

小型画面や狭いウィンドウでの使いやすさが向上
通知をアプリ単位でグループ化可能
HDR、VRR、分数スケーリングなど表示関連の改善が継続
リモートデスクトップ、Wayland、NVIDIA ドライバ環境での滑らかさと安定性が向上
アクセシビリティ対応がさらに強化され、Orca スクリーンリーダーも目立つ更新が入っています

Ubuntu 独自の実用的な改善もあります。

GNOME Shell のグローバル検索から利用可能な snap アプリを直接探せる
検索からそのままウェブ検索を始められる
Yaru テーマは upstream GNOME の見た目にさらに近づいた
snap アプリの権限、ファイルアクセス、ドラッグアンドドロップの体験がより自然になった

普段デスクトップ版を使っているなら、この世代の LTS のポイントは「見た目が大きく変わった」ことではなく、以前からあった細かな引っかかりがまとめて減ったことにあります。

3. 最大の変化その 2：既定アプリが広く刷新された

24.04 LTS と比べると、26.04 LTS に含まれる標準アプリはかなり大きく更新されています。

Firefox は 150 へ
LibreOffice は 24.2 から 25.8 へ
Thunderbird は 140 へ
GIMP は 2.10 から 3.2 へ

さらに、日常利用で影響の大きい置き換えもあります。

PDF ビューアは Evince から Papers に変更
画像ビューアは Loupe に変更
ターミナルは Ptyxis に変更
システムモニターは Resources に変更
既定の動画プレーヤーは Showtime に変更

こうした変化から見える方向性は明確です。Ubuntu は GTK4、libadwaita、そして一部では Rust で再実装された新世代の GNOME アプリ群へ、より本格的に寄せています。

4. 最大の変化その 3：Wayland が唯一のデスクトップセッションになった

これは長く Ubuntu を使ってきた人ほど気になる変更です。

25.10 から始まっていた流れが、26.04 LTS で正式に定着しました。Ubuntu Desktop は Wayland バックエンドのみで動作し、GNOME Shell はもはや X.org セッションとしては動きません。

もちろん、これで古いアプリが全部使えなくなるわけではありません。公式リリースノートでも、X.org 向けアプリは XWayland 互換レイヤー経由で引き続き動かせると明記されています。ただし、古い GPU ドライバや一部のリモートデスクトップ手法、録画ツール、入力メソッドの細かな挙動に依存しているワークフローなら、アップグレード前の確認はやっておいたほうが安心です。

5. 最大の変化その 4：Linux kernel 7.0 と低層スタックもまとめて更新

Ubuntu 26.04 LTS の GA generic スタックは Linux 6.8 から Linux 7.0 に上がり、HWE スタックも 7.0 に統一されました。

公式が触れている低層側の変更の中で、一般ユーザーや運用担当に関係が大きいのは次のあたりです。

デスクトップ版とサーバー版の両方で crash dump が既定で有効
sched_ext により、開発者が eBPF を使ってスケジューリングポリシーを実装できる新しい拡張モデルが入った
linux-lowlatency バイナリパッケージは廃止され、linux-generic とユーザー空間の lowlatency-kernel パッケージによる低レイテンシ調整へ移行
amd64v3 アーキテクチャ変種は利用可能だが、既定では opt-in のまま

比較的新しいマシンを使っているなら、amd64v3 は気にしておいてよい項目です。公式が示している有効化方法は次のとおりです。

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

ただし、これは自動では有効になりません。Ubuntu は引き続き互換性を最優先にしています。

6. ハードウェア要件と導入の目安

Ubuntu Desktop 26.04 LTS に対して公式が示している推奨ラインは次のとおりです。

2 GHz のデュアルコア CPU 以上
6 GB RAM 以上
25 GB 以上の空きストレージ

マシンの性能がやや低めなら、公式には Xubuntu や Lubuntu のようなフレーバーも検討するよう案内されています。
サーバー版の下限はもっと低く、ドキュメントでは 1.5 GB RAM と 4 GB ストレージから始められるとされていますが、実際には動かすサービスの負荷次第です。

7. どんな人に優先してアップグレード向きか

すでに 24.04 LTS を使っていて、次のようなものを求めているなら、26.04 LTS はかなり有力です。

小さなパッチではなく、一世代分まとめて更新されたデスクトップスタック
より成熟した Wayland と表示サポート
新しくなった既定アプリ群
新しいカーネルと、より長い今後のサポート期間

一方で、古い X11 ワークフローや特殊なドライバ、独自のデスクトップ拡張に強く依存している場合、あるいは本番環境で変更に非常に慎重である場合は、アップグレード前に互換性確認を一度通しておくのが無難です。

8. ひとことでまとめると

Ubuntu 26.04 LTS の価値は、目立つ単独機能ひとつにあるわけではありません。ここ 2 年のデスクトップ、カーネル、アプリ、互換性の進化を、新しい LTS の基準に一気にまとめて載せたところにあります。

最短で言うなら、この版は「全体として新しくなり、全体として安定した」Ubuntu LTS であり、ひとつの派手な売りだけで成り立っている版ではない、ということです。

nftables フレームワークを理解する：テーブル、チェーン、ルール、セット

Sat, 18 Apr 2026 10:31:12 +0800

nftables を学び始めると、ついコマンドの細部に入りがちです。ルールをどう追加するか、handle をどう削除するか、ポートマッチをどう書くか。もちろんコマンドは重要ですが、先にフレームワークの概念を整理しておくと、ルールの読解、問題調査、ルールセット設計がかなり楽になります。

nftables は、次のような階層構造として理解できます。

table はルール空間を分離する。
family はルールが扱うネットワークプロトコルを決める。
chain はルールがどの段階で実行されるかを決める。
rule は具体的なマッチ条件とアクションを持つ。
set、map、verdict map は重複ルールを減らし、ルールセットを保守しやすくする。

以下では、概念を階層ごとに整理します。

table：ルールの名前空間

table は nftables で最も外側にあるルールコンテナです。異なる table は互いに分離されるため、関連するルールを同じ table にまとめるのが一般的です。

たとえば、フィルタリングルール、NAT ルール、独自のテスト用ルールを分けて置けます。こうすると境界が明確になります。デバッグ時にはどのルール群を変更しているかが分かりやすく、クリーンアップ時にも無関係な内容を誤って削除しにくくなります。

table 自体はパケットを直接処理しません。実際にパケット処理に関わるのは、table の中にある chain と rule です。

family：ルールが対象にするプロトコル

table を作成するときは family を選びます。これは、その table 内のルールがどの種類のパケットに適用されるかを決めます。

代表的な family は次のように理解できます。

ip：IPv4 のみを処理する。
ip6：IPv6 のみを処理する。
inet：IPv4 と IPv6 の両方を処理する。
arp：ARP を処理する。
bridge：ブリッジ層のトラフィックを処理する。
netdev：ネットワークデバイス入口に近く、より早い段階でトラフィックを処理する用途に向く。

通常のファイアウォールルールでは、inet がよく使われます。IPv4 と IPv6 のルールを同じ table に置けるため、似た構造のルールを 2 セット維持する必要がなくなります。

chain：ルールが実行される場所

chain は rule のリストです。パケットがある hook に入ると、chain 内のルールを順番に通過します。

chain は大きく 2 種類に分けられます。

基本 chain：カーネルのネットワーク経路上の hook に接続され、パケット処理の流れから直接呼び出される。
通常 chain：hook には直接接続されず、他のルールから jump されて呼び出される。

基本 chain では、通常いくつかの重要な属性を指定します。

type：この chain の用途。たとえば filter、nat、route。
hook：接続する処理段階。たとえば prerouting、input、forward、output、postrouting。
priority：同じ hook に複数の chain があるとき、どれを先に実行するか。
policy：どのルールにもマッチしなかった場合のデフォルト動作。一般的には accept または drop。

chain を理解するうえで重要なのは、ルールは「どこに書いても同じように効く」わけではないという点です。同じルールでも、input、forward、output のどこに置くかで意味はまったく変わります。

rule：マッチ条件とアクション

rule は、nftables が実際に判断を行う場所です。通常は 2 つの部分で構成されます。

マッチ条件：送信元 IP、宛先 IP、プロトコル、ポート、インターフェイス、接続状態など。
アクション：accept、drop、reject、counter、jump、return など。

ルールは順番に評価されます。パケットが処理を終了させるアクションにマッチすると、その後ろのルールは実行されません。マッチしなければ、chain の終端またはデフォルトポリシーに到達するまで処理が続きます。

そのため、ルールの順序は重要です。より具体的なルールは、通常より広い条件のルールより前に置く必要があります。そうしないと、実行される機会がない場合があります。

set：値の集合をまとめる

多数の IP、ポート、インターフェイスをマッチしたい場合、ルールを大量に並べると保守しにくくなります。set は、同じ型の値をひとまとめに管理するための仕組みです。

たとえば、信頼する IP の集合、拒否したいポートの集合、帯域制限したいアドレスの集合を set に入れられます。ルール側では、ある値がその set に含まれるかどうかだけを判定すれば済みます。

set の利点は次のとおりです。

ルール数を減らせる。
可読性が上がる。
後から要素を追加・削除しやすい。

ルールの中に同じような条件が大量に出てくる場合は、set の利用を検討するタイミングです。

map：マッチした値を結果に変換する

map は「参照表」として理解できます。入力値に応じて結果を返します。

たとえば、ポートごとに異なる mark を返す、アドレスごとに異なる処理パラメータを返す、といった表現ができます。多くの if/else 風ルールを書くより、map のほうが集中管理しやすく、保守もしやすくなります。

set が気にするのは「集合に含まれるかどうか」です。一方で map が気にするのは「この値に対応する結果は何か」です。

verdict map：マッチした値をアクションに変換する

verdict map は map の重要な使い方の 1 つです。マッチした値を verdict、つまりルールのアクションに変換します。

たとえば、IP 範囲ごとに accept、drop、または別 chain への jump を対応させられます。これにより、多くの分岐判断を 1 つの構造に圧縮できます。

ルールセットが複雑になってきたとき、verdict map はとても便利です。重複ルールを減らし、長い条件分岐の列ではなく、表に近い形でポリシーを表現できます。

概念からルール設計を考える

nftables ルールを設計するときは、次の順序で考えると整理しやすくなります。

まずルールが属する family を決める。
次に、どの table に入れるかを決める。
適切な hook と chain を選ぶ。
具体的な rule を書く。
重複条件が多い場合は、set、map、verdict map を導入する。

この順序で書くと、ルールは保守しやすく、問題も切り分けやすくなります。

まとめ

nftables の概念は複雑ではありませんが、階層が重要です。

table はルールの境界を管理する。
family はプロトコル範囲を管理する。
chain は実行位置を管理する。
rule はマッチとアクションを管理する。
set、map、verdict map は複雑さを管理する。

まずこれらの概念を理解してから具体的なコマンドを見るほうが、コマンドを直接暗記するより安定します。特にルールセットが増えてきたあとでは、概念が明確だと、問題がプロトコル範囲、実行段階、ルール順序、またはマッチ条件そのもののどこにあるのかを判断しやすくなります。

参考

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables クイック入門：テーブル、チェーン、ルールとよく使う操作

Sat, 18 Apr 2026 10:22:07 +0800

nftables は、Linux でよく使われるパケットフィルタリングとファイアウォールルール管理の仕組みです。端末の通信制御、トラフィック統計、ポートマッチ、簡単な帯域制限だけを行うなら、最初からルール体系全体を覚える必要はありません。まずは次の 3 つを押さえれば十分です。

table：ルールを入れるコンテナ。
chain：ルールが評価される場所。通常は特定の hook に接続します。
rule：実際のマッチ条件とアクション。

以下では、まずテスト環境で試しやすい最小構成の流れを整理します。

基本構成

先にいくつか変数を用意します。以降のコマンドで再利用します。

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

IPv4 と IPv6 の両方を扱える inet table を作成します。

`1`	`nft add table inet $table`

次に、forward 段階に接続する chain を作成します。

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

ここで、type filter はフィルタリング用のルールであることを示し、hook forward は転送されるパケットを処理することを示します。

よく使うマッチ方法

送信元 IP でマッチします。通常はアップロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

宛先 IP でマッチします。通常はダウンロード方向の制御として考えられます。

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

MAC アドレスでマッチする場合、ether saddr で上り方向を制御できます。

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

ブリッジ、転送、アドレス変換を経由するネットワークでは、下りパケットを宛先 MAC で安定してフィルタできない場合があります。端末の通信制御を行うときは、まず ether saddr または IP ベースのルールから検証するのが安全です。

ポートでマッチする場合、TCP と UDP をまとめて対象にできます。

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

ポート範囲をマッチしたい場合は、比較式を使えます。

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

単一端末の通信量を集計する

特定 IP の上りと下りの通信量を集計したいだけなら、counter return を使えます。マッチしたらカウンターを記録して戻るため、後続に他の統計ルールがある場合でも余計なマッチ処理を減らせます。

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

統計結果を確認します。

`1`	`nft list chain inet $table $chain`

各ルールの handle を確認したい場合は、-a を付けます。

`1`	`nft -a list chain inet $table $chain`

handle は重要です。nftables で単一ルールを削除するときは、通常この値で対象を指定します。

簡単な帯域制限

帯域制限には limit rate over を使えます。たとえば、MAC アドレスごとに指定速度を超えた通信を制限します。

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

ここでの mbytes、kbytes は、日常的な M、K の単位として理解できます。手動で 8 倍換算する必要はありません。実際に使うときは、まず緩めの値でテストし、マッチ方向と効果を確認してから調整するのが安全です。

ルールの削除と整理

まず handle 付きでルールを表示します。

`1`	`nft -a list chain inet $table $chain`

次に handle を指定してルールを削除します。

`1`	`nft delete rule inet $table $chain handle <handle>`

chain を空にします。

`1`	`nft flush chain inet $table $chain`

chain を削除します。

`1`	`nft delete chain inet $table $chain`

table 全体を削除します。

`1`	`nft delete table inet $table`

日常的なデバッグでは、自分で作成した table だけを整理するのがおすすめです。システムや他のサービスが自動生成した table を直接変更しないほうが、ルールを書き間違えた場合でも戻しやすくなります。

使い方のポイント

nftables を使うときは、まず独立した table と chain を自分で作成すると扱いやすくなります。利点は次の 2 つです。

システム既存のルールと混ざりにくい。
デバッグ、flush、削除を安全に行いやすい。

ルールを書いたあとは、必ず nft list chain で実際のマッチ状況を確認します。特に MAC、インターフェイス、ポート、帯域制限のルールは、デバイス、ブリッジ構成、システムバージョンによって挙動が変わることがあります。複雑なルールを一度に書くより、まず小さい範囲で試すほうが安全です。

参考

https://www.right.com.cn/forum/thread-8369750-1-1.html

Ollama モデルのデフォルトの保存場所と移行方法 (C ドライブがいっぱいになるのを防ぐため)

Mon, 06 Apr 2026 09:38:00 +0800

大規模なモデルをローカルで実行する場合、多くの場合、システムディスクが最初に爆発しやすくなります。 Ollama は、デフォルトでモデルをユーザーディレクトリまたはシステムディレクトリにダウンロードします。事前にパスを計画しておかないと、C ドライブがすぐにいっぱいになってしまいます。

Ollama 共通のデフォルトモデルディレクトリ

Windows: C:\Users\<用户名>\.ollama\models
macOS：~/.ollama/models
Linux: /usr/share/ollama/.ollama/models (一部インストール方法が異なる場合があります)

Windows: モデルディレクトリをシステム以外のディスクに移行します。

モデルディレクトリを D:\OllamaModels などに移行することをお勧めします。主な方法は、システム環境変数 OLLAMA_MODELS を設定することです。

1. 新しいターゲットディレクトリを作成します

たとえば、最初に D:\OllamaModels を作成します。

2. システム環境変数を構成する

変数名: OLLAMA_MODELS
変数値: D:\OllamaModels

これは、「システムのプロパティ -> 詳細設定 -> 環境変数」で追加することも、コマンドライン (管理者 PowerShell) を使用して設定することもできます。

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. Ollama を再起動します (またはシステムを再起動します)。

環境変数が有効になったら、Ollama サービス/アプリケーションを再起動します。有効になったかどうかわからない場合は、コンピュータを直接再起動するのが最も安全です。

4. 新しいディレクトリが有効かどうかを確認します

モデルをダウンロードまたはプルした後、新しいファイルが D:\OllamaModels の下に表示されるかどうかを確認します。

5. 古いディレクトリをクリーンアップします（それが正しいことを確認した後）

新しいディレクトリでモデルが正常に動作していることを確認してから、古いディレクトリの内容を削除して、C ドライブのスペースを解放します。

よくある質問

設定した後もCドライブに書き込まれたままの場合はどうすればよいですか?

まず、環境変数が「現在のセッションの一時変数」ではなく「システム変数」であることを確認します。
Ollama プロセスが再起動されたことを確認します。
変数名が正しいことを確認してください。それは OLLAMA_MODELS である必要があります。

古いモデルのファイルを移行する必要がありますか?

再度ダウンロードしたくない場合は、Ollama を停止した後、古いモデルを新しいディレクトリに手動でコピーし、Ollama の検証を開始できます。

Linux 上の Ollama を完全にアンインストールします (残留クリーニングを含む)

Mon, 06 Apr 2026 09:16:29 +0800

Linux 上で Ollama を完全に削除する必要がある場合は、以下の手順に従ってください。この記事では、サービス、実行可能ファイル、モデルディレクトリ、および ollama ユーザーとユーザーグループをクリーンアップします。

アンインストール前の注意事項

次のコマンドは、ネイティブ Ollama モデルファイル (通常は /usr/share/ollama) を削除します。最初にバックアップする必要があるかどうかを確認してください。
このコマンドはデフォルトで sudo を使用します。現在のアカウントに管理者権限があることを確認してください。

1. systemd サービスを停止して削除します。

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. Ollama 実行可能ファイルを削除します

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. Ollama 関連のライブラリディレクトリを削除します (存在する場合)。

インストール方法によって Ollama ファイルが lib ディレクトリに書き込まれる場合は、次のようにファイルを消去できます。

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. モデルとデータのディレクトリを削除します。

`1`	`sudo rm -rf /usr/share/ollama`

5. システムユーザーとグループを削除します (存在する場合)。

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. アンインストールが完了したことを確認します

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

上記のチェックで ollama が見つからなかった場合は、アンインストールが完了したことを意味します。

rsync --delete パラメータの詳細な説明とディレクトリのクリアの実践

Sun, 29 Mar 2026 11:00:00 +0800

rsync --delete の中心的な機能は、ターゲットディレクトリ内の「ソースディレクトリが存在しない」ファイルを削除して、ターゲット側とソース側の一貫性を保つことです。

一般に、次のシナリオで使用されます。

同期中にターゲット側の過去の冗長ファイルをクリーンアップする
空のディレクトリを使用してターゲットディレクトリをすばやくクリアします

基本的な文法

`1`	`rsync -a --delete 源目录/ 目标目录/`

-a: アーカイブモード、権限やタイムスタンプなどの属性を保持します。
--delete: ターゲット上の余分なファイルを削除します

重要な注意事項: 源目录 の最後に / があるかどうかは、同期動作に影響します。 / を使用すると、ディレクトリの内容を同期することを意味し、/ を使用しない場合は、ディレクトリ自体を同期することを意味します。

ターゲットディレクトリを空のディレクトリですばやくクリアします

「ディレクトリ構造は保持するが、中身は空にする」ことが目標の場合は、空のディレクトリをソースとして同期できます。

# 1) 创建空目录
mkdir -p /tmp/empty_dir

# 2) 同步并删除目标目录中的内容
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

通常、この方法は、大規模なディレクトリのシナリオで 1 つずつ削除するよりも効率的であり、自動スクリプトの作成も簡単です。

よく使用される拡張パラメータ

--delete-before: 最初に削除してから送信します。これは、シナリオによってはより効率的です。
--progress: 送信と処理の進行状況を表示

例 (クリーンな Nginx ログディレクトリ):

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

使用方法の提案

--dry-runでプレビューし、削除範囲を確認してから実行します
本番環境で使用する前に、対象ディレクトリのバックアップを作成することをお勧めします。
クリティカルパスを実行する場合は、オフピーク時間帯の操作を優先する

Git がファイルの実行可能権限を追跡する方法 (+x)

Sun, 29 Mar 2026 10:00:00 +0800

Linux 環境では、Git はファイルの実行可能ビット (+x) を追跡します。スクリプトを「実行可能ファイル」としてリポジトリに保持したい場合は、この権限の変更を Git で明示的に記録する必要があります。

ファイルに実行可能権限を追加する

1
2
3

git update-index --chmod=+x script.sh
git commit -m "chore: mark script.sh as executable"
git push

このコマンドは、script.sh の実行可能ビット変更を一時記憶領域に追加します。送信してプッシュした後、他のユーザーがリポジトリをプルまたはクローン作成するときに、この権限ステータスが保持されます。

ファイルの実行可能権限を削除する

1
2
3

git update-index --chmod=-x script.sh
git commit -m "chore: remove executable bit from script.sh"
git push

効果があるかどうかを確認する

次のコマンドを使用して、ワークスペースの権限を確認できます。

1
2

git clone xxxxxxxxxxxxxxx
ls -l script.sh

-rwxr-xr-x のようなものが表示された場合は、ファイルに実行可能アクセス許可が含まれていることを意味します。 -rw-r--r-- の場合は、実行可能ではないことを意味します。

説明する

git update-index --chmod=+x/-x は、Git によって記録されたファイルモードのみを変更し、ファイルコンテンツ自体の変更を置き換えることはありません。
チームコラボレーションでは、レビューとバックトラックを容易にするために、このような権限の調整を個別に送信することをお勧めします。