Ubuntu PC セットアップ — NVIDIA・サスペンド・Bluetooth・ターミナル選定

🎯 はじめに：この記事のスコープ

本記事はシリーズ 「脱Microsoft・OSS移行」の第 3 回 です。前回のWindows 11 + Ubuntu デュアルブート構築で OS の土台までは完成しましたが、「OS は起動するが業務に使えない」谷が残っています。本記事はそこを埋め、第 4 回のUbuntu 開発環境セットアップ に渡せる状態まで持っていく PC セットアップ のフェーズです。

💡 本記事の到達点: Ubuntu を電源オフ・再起動・サスペンド復帰で安定運用でき、業務 PC として日常使いできる状態。GPU・周辺機器・ネットワーク・端末の使い勝手をすべて Windows 並みに整える。

🎮 NVIDIA ドライバの事後導入

第 2 回のインストーラ画面で「プロプライエタリソフトウェアをインストール」のチェックを 入れ忘れた場合、nvidia-smi コマンドが見つからず、GPU は Nouveau（オープンソース） または ソフトウェアレンダリングで動作している状態になります。実機では症状として以下が観測されます。

• Google Meet の背景設定でカメラ映像が真っ白
• WebGL を使う Web アプリが極端に遅い
• 動画再生で GPU アクセラレーションが効かない
• 機械学習タスクで CUDA が使えない

このうち Google Meet の真っ白問題は、ドライバを入れただけでは Wayland 環境では解決せず、第 6 回（Workspace 移行）で扱う Chrome 起動オプション + ANGLE/GL の組み合わせまで揃って初めて解消します。本記事ではドライバ層の前提までを固めます。

ドライバ未導入の確認

nvidia-smi
# → コマンドが見つかりません  なら未導入

利用可能なドライバ確認

ubuntu-drivers devices

実機（RTX 4070 Ti SUPER）での出力例：

== /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0 ==
modalias : pci:v000010DEd00002705sv00001462sd0000E132bc03sc00i00
vendor   : NVIDIA Corporation
model    : AD103 [GeForce RTX 4070 Ti SUPER]
driver   : nvidia-driver-595-open - distro non-free recommended
driver   : nvidia-driver-580 - distro non-free
driver   : xserver-xorg-video-nouveau - distro free builtin

580 LTS と 595-open の選び分け

recommended は最新の 595-open（オープンソースカーネルモジュール版）ですが、業務開発用途では 580 LTS を推奨します。

💡 業務 PC は LTS（580）を選ぶのが鉄則。Web 会議・動画視聴・WebGL の安定動作が最優先で、最新機能はほぼ不要。トラブルシュート時に Stack Overflow / NVIDIA フォーラムにヒットする情報量が桁違いに多いのも 580 系。

インストールと再起動

sudo apt install -y nvidia-driver-580
sudo reboot

⚠️ 再起動は必須。apt が完了してもカーネルモジュールはロード済みカーネル上では切り替わりません。reboot するまで nvidia-smi は通りません。

動作確認

再起動後：

nvidia-smi

期待される実機出力（CTS の業務 PC、再起動直後のアイドル時）：

+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 580.142                Driver Version: 580.142        CUDA Version: 13.0     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4070 Ti SUPER  Off |   00000000:01:00.0  On |                  N/A |
|  0%   37C    P5             24W /  285W |     886MiB /  16376MiB |     25%      Default |
+-----------------------------------------+------------------------+----------------------+

Driver Version: 580.142 と GPU 名・メモリ容量が表示されればドライバ導入成功です。16376MiB が GPU 側 16 GB VRAM を認識できている証跡。

🛡️ サスペンドの完全無効化（NVIDIA + カーネルパニック対策）

ドライバを 580 系に固めても、サスペンドからの復帰時にカーネルパニックで落ちる現象が NVIDIA ドライバ + 比較的新しいカーネル + RTX 40/50 系 GPU の組み合わせで一定頻度で発生します。Claude Code を「数時間放置できる開発体験」が本シリーズの中核なので、サスペンドそのものを無効化するのが最も確実です。

既知の症状

• アイドル時のサスペンド復帰時に画面が真っ黒のまま入力を受け付けない
• ロック画面復帰でフリーズ
• journalctl -k に nvidia モジュール関連のスタックトレース
• coredumpctl list に該当時刻のクラッシュダンプ

長時間ジョブ・Agent Teams の並列稼働中にサスペンドに入ると、復帰失敗で ジョブも失うため、業務開発機としては致命的です。

対処：4 つの sleep target を mask

systemctl mask で 4 つの sleep target すべてを無効化します（これらは互いに依存しているため、1 つだけ mask してもアイドルから別経路で sleep に入ることがある）。

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

実行結果：

Created symlink /etc/systemd/system/sleep.target → /dev/null.
Created symlink /etc/systemd/system/suspend.target → /dev/null.
Created symlink /etc/systemd/system/hibernate.target → /dev/null.
Created symlink /etc/systemd/system/hybrid-sleep.target → /dev/null.

動作確認

サスペンドを試みて拒否されることを確認：

systemctl suspend
# → Call to Suspend failed: Access denied  が出れば成功

各 target が masked になっているか確認：

for t in sleep.target suspend.target hibernate.target hybrid-sleep.target; do
  systemctl status "$t" --no-pager | head -3
done

すべてが Loaded: masked と Active: inactive (dead) になっていれば成功です。

KDE Plasma 側のスリープ設定も無効化

systemd 側で mask しても、KDE 電源管理が独自に画面オフ → サスペンドを呼ぼうとすることがあります（systemd で拒否されてもログにエラーが残る）。System Settings → 電源管理 → エネルギーセーバーで：

万が一カーネルパニックが発生した場合の調査手順

すでに mask 済みでも、別経路で発生したパニックの調査手順は以下：

# クラッシュダンプの一覧
coredumpctl list

# 最新クラッシュ直前のカーネルログ
journalctl -k -b -1 | tail -200

# 起動履歴と異常終了の有無
journalctl --list-boots
last reboot | head

💡 長期的にはサスペンド復帰の安定化を NVIDIA + Ubuntu に期待しつつ、当面は無効化が最も実用的。デスクトップ機・常時電源の業務 PC ではそもそもサスペンドの恩恵は薄く、無効化のデメリットはほぼゼロ。ノート PC で運用する場合のみ、消費電力との兼ね合いで再検討の余地があります。

⌨️ Bluetooth 周辺機器の取り回し（HHKB Hybrid 等）

第 2 回で「BIOS で Bluetooth キーボードは動かない」を扱いましたが、Ubuntu 起動後の Bluetooth ペアリングも一部のキーボードで不安定です。実機で確認した挙動を整理します。

症状

bluetoothctl
[bluetooth]# pair XX:XX:XX:XX:XX:XX
Failed to pair: org.bluez.Error.ConnectionAttemptFailed

ConnectionAttemptFailed が繰り返され、運良くペアリングできても数分後に切断される、というパターン。

回避策：USB 有線で割り切る

HHKB Hybrid は本体側の Fn + Control + 0 ショートカットで USB モードに切り替わります。USB-C ケーブル接続だけで安定動作するため、業務利用では割り切って USB 接続が現実解です。

💡 BIOS でも OS 起動後でも安定する USB 有線キーボードを 1 本確保しておくと、トラブルシュート時に「キーボードが効かない地獄」を回避できます。HHKB の打鍵感は USB でもまったく同じなので、業務 PC では USB 固定運用が無難。

Bluetooth が必要なら別のキーボードを

業務開発でどうしても Bluetooth キーボードを使いたい場合は、Linux での実績が豊富な以下を検討：

• Logicool MX Keys S（Logi Bolt レシーバー併用で安定）
• Apple Magic Keyboard（USB-C モデル、Bluetooth で素直に動く）
• Keychron K シリーズ（Bluetooth + 有線両対応、Linux 公式言及あり）

HHKB Hybrid のように **Bluetooth が「動くこともある」**製品は、業務 PC では運用コストが見合いません。

📷 顔認証ログイン（Howdy）— Windows Hello 風を Ubuntu でも

業務 PC を Windows + Windows Hello から Ubuntu に移すと、地味に効いてくるのがログイン / ロック解除 / sudo ごとに長いパスフレーズを打ち直す摩擦です。Linux 側でも Howdy を使えば、Web カメラ + PAM 連携で ログイン画面・ロック画面解除・sudo 実行を顔認証に置き換えられます。CTS では Logicool BRIO（USB 接続）で常用しています。

⚠ Ubuntu 26.04 では公式 PPA（ppa:boltgolt/howdy）を使わないこと

Ubuntu 26.04（Resolute Raccoon）では、公式 PPA の post-install スクリプトが古く、numpy / dlib のインストールに失敗してインストール自体が完走しません。Python 3.14 の PEP 668（externally-managed-environment）ポリシー変更により、pip install がシステム全体で --break-system-packages 必須となったことが直接の原因です。

# ❌ これは Ubuntu 26.04 では失敗する
sudo add-apt-repository ppa:boltgolt/howdy
sudo apt install howdy
# → numpy / dlib のビルドエラーで postinst が abort

pip3 install --break-system-packages で逃げる方法も試行可能ですが、howdy コマンド自体がシンボリックリンクの手動作成を要求するなど不安定で、業務 PC で常用するには整備コストが見合いません。

推奨：ppa:ubuntuhandbook1/howdy を使う

Ubuntu Handbook の手順（2026-05-18 更新）で配布されている非公式 PPA は、Ubuntu 26.04 向けに依存関係が解決済みで、apt 一発で完走します。

# 1. PPA を追加
sudo add-apt-repository ppa:ubuntuhandbook1/howdy

# 2. howdy 本体
sudo apt update
sudo apt install howdy

# 3. 依存パッケージ（明示的に揃える）
sudo apt install python3-numpy python3-opencv python3-dlib \
                 libpam-python dlib-models libinireader0

カメラデバイスの指定

# 接続中のカメラを確認（Logitech BRIO → /dev/video0 など）
v4l2-ctl --list-devices

# howdy の設定ファイルを開く
sudo howdy config
# → device_path = /dev/video0 に書き換え

💡 ノート PC 内蔵カメラと外付け USB カメラが混在する環境では、起動順で /dev/video* の番号がずれることがあります。udev ルールでシンボリックリンクを固定するか、起動時に v4l2-ctl --list-devices で都度確認するのが堅実です。

顔の登録（複数パターンで認識精度を上げる）

# カメラに正面を向けて登録
sudo howdy add
# → ラベル入力（normal / glasses / no-glasses など任意）

# メガネあり・なしの 2 パターンを登録すると認識率が大きく上がる
sudo howdy add    # メガネあり
sudo howdy add    # メガネなし

PAM 認証を有効化

sudo pam-auth-update

表示されるリストで Howdy にチェックが入っていることを確認して OK。これで ログイン画面 / ロック解除 / sudo の各認証で顔認証が走るようになります。

普段使う管理コマンド

ハマりポイントまとめ

🔐 セキュリティ観点： Howdy は Windows Hello のように赤外線カメラを使うわけではなく、通常 RGB カメラの顔画像で照合します。「写真でも突破される可能性がある」前提で、業務上の機密度が極めて高い PC では PIN / パスフレーズ運用を残すか、sudo howdy disable 1 で必要な場面だけ無効化する判断もあり得ます。CTS では「ロック解除と sudo の摩擦低減」が主目的で、機密データは別途 DevContainer 隔離 + readonly bind mount で守る前提です。

⚠ 重大ハマり：Howdy が KDE Discover / GUI polkit 認証を全部潰す

Howdy をインストールした直後に、ターミナルの sudo は顔認証で通るのに、KDE Discover の「更新」ボタンや Snap GUI の認証が一切通らなくなる現象が出ます。実機で踏んで真因特定までに数時間溶かしたバグなので、症状・原因・対処をフルセットで残します。

症状

要約：polkit を経由する GUI 認証が全滅する。ターミナル sudo だけは生き残る。

原因：Howdy の PAM モジュールが polkit の PAM 対話プロトコルを壊している

Howdy インストーラは pam_howdy.so を /etc/pam.d/common-auth の先頭に登録します。common-auth は Ubuntu の認証スタックの中核で、sudo だけでなく polkit、screensaver、login、ssh など PAM を使うほぼ全経路がここを参照します。

問題は polkit 経路で起きます。polkit-kde-authentication-agent（KDE のパスワード入力ダイアログを出す常駐プロセス）が認証要求を受けると、PAM スタック先頭の pam_howdy.so が GUI ダイアログより先にカメラ顔認証を開始します。すると：

• GUI 側：パスワード入力ダイアログを表示しようとする
• Howdy 側：カメラ UI を出して顔認証を試みる
• → 両者が同じ PAM **conversation（対話プロトコル）**を奪い合って崩壊

journalctl -u polkit にこのエラーが大量に積もります：

polkitd: Operator of unix-session:X FAILED to authenticate to gain authorization
         for action io.snapcraft.snapd.manage for unix-process:X [/usr/bin/plasma-discover]
pam_howdy: pam_unix(polkit-1:auth): conversation failed
pam_howdy: pam_unix(polkit-1:auth): auth could not identify password for [<user>]

conversation failed は PAM 用語で 「認証に必要な対話（パスワードプロンプト表示など）が完遂できなかった」 を意味します。

sudo 経路だと tty が存在するため Howdy のカメラ UI が問題なく走り、そのまま成功できます。polkit 経路には tty がなく、GUI ダイアログと衝突するわけです。

💡 /lib/security/howdy/config.ini の workaround = input 設定も試しましたが改善しません。これは Howdy 単体での conversation 改善設定であって、別 PAM モジュールとの衝突は解けません。

解決策：polkit 専用 PAM 設定で Howdy を経由させない

/etc/pam.d/polkit-1 を新規作成し、polkit 経路だけ common-auth を参照させず、pam_unix.so（パスワード認証）だけを使うようにします：

sudo tee /etc/pam.d/polkit-1 > /dev/null <<'EOF'
#%PAM-1.0
auth       required   pam_unix.so
account    required   pam_unix.so
password   required   pam_unix.so
session    required   pam_unix.so
EOF

# polkit デーモンを再起動して反映
sudo systemctl restart polkit

これで：

ターミナルでは顔認証の摩擦低減を維持しつつ、GUI 経路は確実な KDE パスワードダイアログに切り替える構成です。

検証手順

# 1. sudo 認証キャッシュをクリア
sudo -k

# 2. ターミナル sudo → カメラ LED 点灯 → 顔認証成功を確認
sudo whoami
# [sudo] Identified face as <user>
# root

# 3. GUI polkit → KDE のパスワード入力ダイアログが正しく出るか確認
snap install hello-world
# → KDE パスワードダイアログ表示 → パスワード入力で成功

真因特定のための切り分けフロー（同じ症状を踏んだ人向け）

このバグは表層症状（Discover で更新できない）から真因（Howdy ↔ polkit 競合）まで複数レイヤーの切り分けが必要でした。同じ症状に遭遇した場合の判別フロー：

周辺で踏んだ Ubuntu 26.04 固有の地雷（参考）

Howdy 問題に切り分けで到達するまでに、Ubuntu 26.04 / KDE 環境特有のいくつかの罠も並行で踏みます。同時に押さえておくと一気に楽になります。

Discover のキャッシュ強制クリア手順：

sudo systemctl stop packagekit
sudo rm -rf /var/cache/PackageKit/*
rm -rf ~/.cache/plasma-discover/
sudo systemctl start packagekit
killall plasma-discover
plasma-discover &

💡 「Discover が動かない」=「Howdy のせい」と断定する前に、まずキャッシュクリアを試すのが切り分けの順番として正しいです。キャッシュクリアで治らず、journalctl に pam_howdy: conversation failed が積もっていたら Howdy ↔ polkit 競合が真因と判断できます。

💻 標準ターミナル選定（Ptyxis → Terminator / Konsole）

Ubuntu 26.04 では Ptyxis が標準ターミナルです（GNOME Terminal の後継として採用）。ただし業務利用では 右クリックペーストの操作性で詰まりやすく、Windows 出身者にとっては最初のストレスポイントになります。

Ubuntu 26.04 で選べる主要ターミナル

業務 PC 化のフェーズでは Terminator か Konsole のどちらかを選ぶ運用がスムーズです。CTS では移行直後の操作感ギャップ吸収を優先して Terminator を採用しました。

💡 「右クリック = ペースト」に慣れているなら Terminator 一択。 PuTTY / Tera Term 等の Windows ターミナル経験者には PuTTY style paste の右クリックペーストが圧倒的に馴染みやすく、Konsole よりストレスが少ないです。

Terminator 最小セットアップ（業務 PC 化に必要な分だけ）

sudo apt install -y terminator

設定 → Profiles → General で 3 項目だけ ON にすれば、Windows ライクな操作感になります（詳細な配色・Gogh テーマ — CTS では Tokyo Night（目に優しい紺紫系）を業務利用中 — や Smart copy は第 4 回 Ubuntu 開発環境セットアップ 側で扱います）。

⚠️ PuTTY style paste を ON にすると、右クリックがペースト動作に変わるため、Terminator 本来の「右クリック → コンテキストメニュー（設定 / プロファイル切替 / 分割など）」が呼べなくなります。 回避策は F10 キーでコンテキストメニューを表示。設定画面に入れなくなって慌てがちなので、この一手だけ覚えておけば OK。

⚠️ tmux / vim の中では右クリックが奪われる — tmux や vim はマウスイベントを自分で処理するため、PuTTY style paste の右クリックペーストが効きません（Terminator まで届かずにアプリ側に吸われる）。Shift+右クリック（Shift キー押下中はマウスイベントが Terminator にバイパスされる）または Shift+Ctrl+V でペーストします。Shift+Ctrl+V は bash / tmux / vim / SSH 先すべてで共通動作なので、**「迷ったら Shift+Ctrl+V」**を基本動作にしておくと操作が揃います。

覚えておきたい Terminator ショートカット

Shift+Ctrl+T のタブ追加は、Agent Teams 並列稼働中に「もう 1 本セッション足したい」という場面で頻発するため、最初に体に入れておく価値があります。

Konsole を選ぶなら（KDE Plasma 統合派向け）

KDE Plasma 6 系の Konsole は 追加インストール不要（kubuntu-desktop で導入済み）。標準ショートカットでだいたい困りません：

💡 第 4 回の Claude Code + tmux 運用では、ホスト OS のターミナルが安定しているほど作業効率が上がるため、業務 PC 化フェーズでターミナルだけは早めに固めるのが吉。VS Code 統合ターミナルから tmux を起動する経路は公式に非対応なので（第 4 回参照）、ホスト OS のターミナルアプリは独立して整える価値があります。

🪟 KDE Plasma の縦/横最大化（エッジダブルクリック）

業務開発で AI からの長い出力を縦に最大化して読みたい場面が頻発します（Agent Teams の出力、長いログ、コードレビュー）。KDE Plasma 6.1.3 以降では、ウィンドウのリサイズエッジ（↕ カーソルが表示される 1〜2 px の領域）を ダブルクリックすると その方向にのみ最大化される機能が標準搭載されています。

アプリ別の動作

⚠️ Chrome は当面「待ち」の状態 — Wayland セッションかつ CSD（クライアントサイドデコレーション）という組み合わせで、現時点では確実な解決方法がありません。Chrome 側のアップデート、もしくは KWin Bug 502885 の修正待ちが現実的な状況です。当面の運用は次節のキーボードショートカット代替で凌ぎます。

Chrome / 全アプリ向けの代替策（KDE キーボードショートカット）

System Settings → ショートカット → KWin →
  「ウィンドウを縦に最大化」 / 「ウィンドウを横に最大化」
  にキーバインドを割り当て

割り当て例（個人環境で重複しないキーを選ぶ）：

💡 Meta は Windows キー。タイル WM 風の操作感に揃えたい場合は、Meta+矢印 系で吸着系操作と組み合わせて整えるのがおすすめ。

🌐 ネットワーク確認と速度実測

業務 PC として運用する前に、ネットワークインターフェースが正しく認識されているか確認します。

ip link show

CTS の業務 PC（GIGABYTE Z790 AORUS PRO X、5GbE 有線 + Wi-Fi）の出力例：

2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... state UP
3: wlp4s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ... state DOWN

速度実測

近隣のミラーへの curl ベースの簡易計測でも、有線 / Wi-Fi の差ははっきり出ます。

💡 業務 PC は迷わず有線 5GbE。Docker pull や apt update の体感、Drive / NAS の転送速度がすべて変わります。第 4 回で扱う pnpm install の中規模リポジトリ（実機計測 40 秒）も、回線速度がボトルネックになる場面があります。

📌 オフィス側のスイッチが 1 GbE 止まりだと当然 1 Gbps が上限。スイッチ・LAN ケーブル（Cat6A 以上）も含めて 5GbE 環境を整えると、コスト削減（脱 Microsoft）の効果と並んで日常開発のストレスが減ります。

🖨️ プリンター設定（Canon LBP621C — driverless ではカラー印刷不可）

Ubuntu 26.04 はネットワークプリンターを自動検出し、IPP Everywhere（driverless / ドライバレス） で接続するのがデフォルト挙動です。が、Canon LBP621C のような Canon カラーレーザーでは driverless 経路だとカラー設定が反映されず、CUPS の Print Color Mode を Color に切り替えてもモノクロで出力される罠があります。Canon 公式 Linux ドライバー（LIPSLX/CARPS2）に切り替えるのが正攻法です。

症状

プリンタープロパティ → Print Color Mode → Color
↓
（テスト印刷を投げる）
↓
❌ なぜかモノクロで出力される（CUPS ジョブの色指定が無視される）

CUPS の Web 管理画面（http://localhost:631/）でジョブ詳細を見ると、`com.apple.print.PrintSettings.PMColorMatchingMode` が AutomaticColorMatching 等になっていてもプリンター側で解釈されません。

解決策：Canon 公式 Linux ドライバーを入れて再追加

1. 公式ドライバーをダウンロード — Canon サポート から LIPSLX/CARPS2 Printer Driver for Linux Ver.6.30（CTS 検証時点）を取得。Ubuntu 26.04 は公式サポート対象外と書かれているが、インストーラは正常に動作する

2. インストール：

   cd ~/ダウンロード
   tar xvf linux-lipslx-drv-v630-jp.tar.gz
   cd linux-lipslx-drv-*
   sudo ./install.sh

   インストーラの確認プロンプトはすべて Y で続行。

3. 既存の driverless キューを再構成（推奨） — KDE プリンター設定（または CUPS Web 管理画面 http://localhost:631/ ）で、自動検出済みのキュー（キュー名は MAC 末尾付きで Canon_LBP621C_<mac-suffix> 等）を選び、以下の 2 点を書き換える：

   項目	変更前（driverless）	変更後
   接続 (Device URI)	ipp://<printer-ip>/ipp/print 等	lpd://<printer-ip> に書き換え
   メーカー / モデル	IPP Everywhere	「Canon LBP621C CARPS2」 を選択

   キュー名（Canon_LBP621C_<mac-suffix>）はそのままで OK。新規キュー追加ではなく既存キューの差し替えにすると、アプリ側の既定プリンター設定や印刷履歴がそのまま引き継がれます。

4. テストページを印刷し、カラー出力されることを確認

💡 新規キューとして追加する手順もあり — Canon Printer Setup Utility 2（インストール後に自動起動）で「Canon LBP621C CARPS2」を選んで IP 指定で追加すると、Canon-LBP621C-CARPS2 名で別キューが作られます。が、その場合は driverless 版（Canon_LBP621C_<mac-suffix>）が残り「どちらに送ったかでカラー / モノクロが変わる」事故が起きやすいので、本記事は既存キュー差し替え方式を推奨します。

設定後の状態

インストールされるユーティリティ

KDE アプリケーションメニュー → ユーティリティ に 2 つ追加されます：

新規キューを追加してしまった場合の後始末

新規追加方式（Canon-LBP621C-CARPS2）を試した後で「driverless 版」と「Canon ドライバー版」が両方残ってしまった場合は、driverless 側を削除してドライバー版にデフォルトを寄せます：

# 現在のキュー一覧を確認
lpstat -a

# driverless 版（MAC 末尾付き）を削除
lpadmin -x Canon_LBP621C_<mac-suffix>

# Canon ドライバー版をデフォルトに設定
lpadmin -d Canon-LBP621C-CARPS2

推奨は §設定後の状態のように既存 driverless キューを差し替える方式（このコマンド自体が不要になる）です。

ハマりポイントまとめ

💡 driverless を捨てる判断軸： 「自動検出されたから使う」ではなく、色再現が必要なカラー機・両面印刷・ホチキス止め・トナー残量表示などのベンダー機能を使うなら公式ドライバー一択。Canon / Brother / Epson は Linux 向けドライバーを公開しています（Ricoh は要事前確認）。

💡 ハードウェア固有の制約（参考）

「Linux ですべて完結する」という前提だと、一部のホビー系ハードウェアで詰まります。CTS の業務 PC で確認した実例：

NZXT Kraken Elite（簡易水冷）

sudo apt install -y liquidctl
sudo liquidctl list
# → NZXT Kraken 2023 Elite (broken)

LED 配色が必要なら、デュアルブートの Windows 側で NZXT CAM を起動 → 配色設定 → 電源オフ後もハードウェア側に保持される運用で割り切れます。CTS ではこの方法で運用中。

その他の「Linux 側未対応」になりがち機器

💡 「Linux で 100% 揃わなくて良い」のがデュアルブート構成の利点。LED 配色のような「設定しておけば保持される」系の機能は Windows 側で済ませて、業務時間中は Ubuntu で開発、という割り切りが現実的です。

📝 LibreOffice — Kubuntu 標準同梱、Workspace との二段構え

第 2 回で sudo apt install kubuntu-desktop -y を実行したとき、KDE Plasma + Dolphin + Konsole と一緒に LibreOffice 6 アプリ（Writer / Calc / Impress / Draw / Base / Math）が自動でインストールされています。これは kubuntu-desktop メタパッケージが「フル Kubuntu 環境」として LibreOffice を依存に含めているためで、追加コストゼロで使える状態になっています。

which libreoffice && libreoffice --version
# → /usr/bin/libreoffice / LibreOffice 26.2.x

脱 Microsoft 戦略における位置づけ

第 1 回脱Microsoft 全体戦略・総論では Microsoft 365 の代替として Google Workspace を主軸に置きましたが、Workspace 単体で全業務をカバーするのは現実的ではありません。Workspace + LibreOffice の二段構えが現実解です。

LibreOffice 26.2 の Microsoft Office 互換性

2026 年初頭リリースの LibreOffice 26.2 は、Microsoft Office 互換性で大きく前進しています：

💡 「日常的な交換は OK、最終確定はネイティブ形式で」が現実的なワークフロー — 取引先から受領した docx は LibreOffice で開いて確認・軽微編集しつつ、新規の社内ドキュメントは Workspace の Docs / Sheets で作る。Workspace で書いて取引先に送るときは「PDF 出力 + docx エクスポート両方」が安全。

なぜ Calligra ではなく LibreOffice なのか（歴史的経緯）

KDE には Calligra Suite（Qt ベース・KDE ネイティブ）という独自オフィススイートがあります。一見 Kubuntu と相性が良さそうですが、Kubuntu 12.04 で Calligra Words をデフォルトに採用したのち、互換性問題で LibreOffice に戻した経緯があります。

業務環境では Microsoft Office との相互運用がデファクト要件である以上、Calligra の「.docx 書き込み非対応」は致命的でした。Kubuntu 26.04 でも kubuntu-desktop の依存は LibreOffice のみで、Calligra は別途 sudo apt install calligra-suite で入れる任意パッケージ扱いになっています。

業務開発機での LibreOffice 運用 Tips

日本語 UI 化（libreoffice-l10n-ja）

kubuntu-desktop で同梱される LibreOffice は 既定で英語 UI です。日本語業務で使うなら言語パックを追加：

sudo apt install -y libreoffice-l10n-ja
# 起動済みの LibreOffice は一度終了して再起動すると日本語化される

メニュー・ダイアログ・ツールチップが日本語に切り替わります。ヘルプも日本語化したい場合は libreoffice-help-ja を併せて：

sudo apt install -y libreoffice-help-ja

💡 言語パックは UI のみで、ドキュメント表示には不要 — 日本語 docx / xlsx は言語パックなしでも普通に開けます（フォントさえあれば）。l10n-ja はあくまで メニューや設定画面の日本語化用。Windows から移ってきた人には実質必須。

フォント周りの設定

# 既定のフォントを Noto Sans JP / Noto Serif JP に揃える
# Tools → Options → LibreOffice → Fonts → Replacement Table
#   または ~/.config/libreoffice/4/user/registrymodifications.xcu

💡 Microsoft フォント問題 — 取引先から MS 明朝 / MS ゴシック前提の docx を受領すると、LibreOffice / Linux にはこれらのフォントがなくレイアウトが崩れます。Noto Sans / Serif で代替するか、ライセンス的に許可される場合のみ Microsoft の Web フォント（Cascadia Code 等）を別途導入。CTS 環境では「最終確認は Windows 側で」のルールでカバーしています。

# LibreOffice を不要なら削除（容量約 1 GB）
sudo apt remove --purge libreoffice-*
sudo apt autoremove

⚠️ 削除は慎重に — Workspace に完全移行できる前提でないと、取引先からの docx を開けない端末になります。業務 PC では入れたままが無難。

🛡️ ウィルス対策（CLI ベースの ClamAV）

業務 PC として日常運用するなら、ウィルス対策の最低ラインも押さえておきます。Linux でも、npm / pip / 不正な Docker イメージ経由のサプライチェーン攻撃や、Windows 由来のドキュメントマクロ等の 既知マルウェアは脅威です。

ClamTK は 2024 年 4 月にメンテナンス停止

長らく Linux のお手軽 ClamAV GUI として使われてきた ClamTK は 2024 年 4 月で公式にメンテナンス停止。バグ修正もセキュリティ修正も入りません。Ubuntu 26.04 でも apt から消えており、業務 PC では削除推奨です。

sudo apt remove clamtk        # インストール済みの場合のみ
sudo apt autoremove           # 依存していた libtext-csv-perl 等を整理

代替の GUI に ClamAV-GUI（KDE Store / OpenCode）や ClamUI（GTK4 + Adwaita）もありますが、業務開発機では CLI ベース運用が筋です：

• systemd サービスで自動更新・自動スキャンを組み込みやすい
• DevContainer / CI / リモート（Tailscale + SSH）でも同じ運用が通る
• GUI が止まっても監視は続く

インストールと systemd 常駐化（freshclam）

sudo apt install -y clamav clamav-freshclam

# 自動更新サービス（freshclam）を有効化
sudo systemctl enable --now clamav-freshclam
sudo systemctl status clamav-freshclam
# → Active: active (running) を確認

clamav-freshclam は デフォルトで 1 日 24 回ウィルス定義を自動更新します。Ubuntu では cron 不要・systemd が常駐管理してくれます。

⚠️ NotifyClamd エラーの対処

sudo freshclam を手動実行すると、最後に以下のエラーが出ることがあります：

ERROR: NotifyClamd: Can't find or parse configuration file /etc/clamav/clamd.conf

freshclam は更新後に clamd（リアルタイムスキャン用デーモン）に通知しようとしますが、clamd.conf が未設定だと失敗します。業務開発機では clamd 常駐は推奨しないので、通知設定だけ無効化します：

sudo nano /etc/clamav/freshclam.conf
# NotifyClamd の行をコメントアウト
# # NotifyClamd /etc/clamav/clamd.conf

なぜ業務開発機で clamav-daemon を常駐させないか

オンデマンド clamscan（必要時実行 + 週次バッチ）で十分です。

運用：週次スキャン + 異常時の手動

⚠️ --remove の自動削除は使わない — 誤検知で正常なソースコード・ビルド成果物が消える事故が起きます。--infected --log=... で記録し、人間がレビューしてから対処するのが原則。

除外オプションの基礎（clamscan は設定ファイルを暗黙には読まない）

ClamAV の clamscan コマンドは、設定ファイルを暗黙に読み込みません。clamscan -r ~/ だけ実行しても、どこかに置いた設定ファイルは一切無視されます。除外を効かせるには --exclude-dir=PATTERN をコマンドラインで明示的に渡す必要があります（clamd デーモンの ExcludePath 設定とは完全に別系統）。

⚠️ @filename 構文は clamscan には存在しない — オンライン情報の一部に「--exclude-dir=@/path/to/list でリストファイルから読める」という記述がありますが、ClamAV 1.4.4 で実機検証した結果、動きません。@/path/to/list は「正規表現リテラル」として解釈され、どのパスにもマッチせず除外がゼロ件になります。実証済みの方法は --exclude-dir を複数回並べることだけです（man page でも「複数回指定可」と明記）。

実証済みの除外オプション

node_modules のようなディレクトリ名そのものを書けば、パスのどこに node_modules があっても配下が再帰対象から外れます。Excluded ログが出ることで動作確認できます：

clamscan -r --exclude-dir=node_modules ~/Projects/<your-repo>/ 2>&1 | grep -E "node_modules|Excluded" | head
# → /home/.../node_modules: Excluded  が出れば成功

開発機向けの除外パターン 13 個

💡 target / dist / build は意図的に除外していません — ~/Documents/dist（製品配布資料）のような正常なフォルダ名と衝突しがちで、業務 PC のホーム全体に対するスキャンでは入れない方が安全。プロジェクトリポジトリ単位で外したい場合は、その都度 --exclude-dir=target などを足すか、リポジトリの .gitignore 相当の感覚で個別運用してください。

スキャン対象は「狙い撃ち」と「ホーム全体」を使い分ける

実機計測：

⚠️ ホーム全体を手動でその場で待つのは非現実的 — clamscan-home ~/ は約 1 時間かかります。日常運用は 狙い撃ち（数秒〜数分）、ホーム全体は 深夜の systemd timer に任せるのが筋です。

動作する手動コマンド（特定ディレクトリ向け）

clamscan -r \
  --exclude-dir=node_modules \
  --exclude-dir='\.git/objects' \
  --exclude-dir='\.cache' \
  --exclude-dir='\.venv' \
  --exclude-dir=__pycache__ \
  --exclude-dir='\.cargo/registry' \
  --exclude-dir='\.rustup' \
  --exclude-dir='\.npm' \
  --exclude-dir='\.pnpm-store' \
  --exclude-dir='\.gradle' \
  --exclude-dir=GoogleDrive \
  --exclude-dir=NAS \
  --exclude-dir=snap \
  --infected --log="$HOME/.clamscan.log" \
  ~/Downloads/

実行ログに : Excluded の行が出れば、そのディレクトリ配下が完全にスキップされた証拠：

/home/<user>/Projects/<repo>/.git/objects: Excluded
/home/<user>/Projects/<repo>/node_modules: Excluded

恒久化 A: シェル関数（手動スキャン用）

毎回 13 行のオプションを書くのは現実的でないので、~/.bashrc にシェル関数として登録します：

clamscan-home() {
  clamscan -r \
    --exclude-dir=node_modules \
    --exclude-dir='\.git/objects' \
    --exclude-dir='\.cache' \
    --exclude-dir='\.venv' \
    --exclude-dir=__pycache__ \
    --exclude-dir='\.cargo/registry' \
    --exclude-dir='\.rustup' \
    --exclude-dir='\.npm' \
    --exclude-dir='\.pnpm-store' \
    --exclude-dir='\.gradle' \
    --exclude-dir=GoogleDrive \
    --exclude-dir=NAS \
    --exclude-dir=snap \
    --infected --log="$HOME/.clamscan.log" \
    "$@"
}

source ~/.bashrc 後：

clamscan-home ~/Downloads/          # ダウンロードフォルダ（数秒〜数十秒）
clamscan-home ~/Documents/          # ドキュメントフォルダ（数十秒〜数分）
clamscan-home ~/Projects/<repo>/    # 単一リポジトリ（数秒〜数分）
# clamscan-home ~/                  # ホーム全体は約 1 時間。手動より systemd timer 推奨

💡 alias より関数を推奨 — alias は引数の扱いが面倒（末尾固定）で、関数なら "$@" でスキャン対象パスを自由に渡せます。

⚠️ 手動でホーム全体を実行しない — 約 1 時間ブロックされます。緊急時の侵害調査などで本当にホーム全体を回す必要があるときは、別ターミナルで nohup 付き or screen / tmux で投げ、結果は --log ファイルで確認するのが現実的。

恒久化 B: 週次スキャンを systemd ユーザータイマーで自動化

業務 PC では systemd ユーザータイマーのほうが journald 統合・依存関係制御の観点で筋が良いです。ExecStart= には個別 --exclude-dir= を 直接列挙します（@filename は使えないため）。

💡 ホーム全体は約 1 時間 — 実機計測 11 万ファイル / 28 files/sec で約 64 分。深夜（日曜 03:00）の自動実行なら問題なし。日中・手動は前述の狙い撃ち運用に。

~/.config/systemd/user/clamscan-weekly.service：

[Unit]
Description=Weekly ClamAV home scan

[Service]
Type=oneshot
ExecStart=/usr/bin/clamscan -r \
  --exclude-dir=node_modules \
  --exclude-dir=\.git/objects \
  --exclude-dir=\.cache \
  --exclude-dir=\.venv \
  --exclude-dir=__pycache__ \
  --exclude-dir=\.cargo/registry \
  --exclude-dir=\.rustup \
  --exclude-dir=\.npm \
  --exclude-dir=\.pnpm-store \
  --exclude-dir=\.gradle \
  --exclude-dir=GoogleDrive \
  --exclude-dir=NAS \
  --exclude-dir=snap \
  --infected --log=%h/.clamscan.log \
  %h

~/.config/systemd/user/clamscan-weekly.timer：

[Unit]
Description=Weekly ClamAV home scan timer

[Timer]
OnCalendar=Sun *-*-* 03:00:00
Persistent=true
RandomizedDelaySec=1800

[Install]
WantedBy=timers.target

systemctl --user daemon-reload
systemctl --user enable --now clamscan-weekly.timer
systemctl --user list-timers | grep clamscan

動作確認の方法

Excluded ログがスキャン結果に出ること、および除外したパスがスキャン対象から消えることの両方で確認します。

# 単体パターンの動作確認（最小ケース）
clamscan -r --exclude-dir=node_modules ~/Projects/<your-repo>/ 2>&1 | grep -E "node_modules|Excluded" | head
# → "/home/.../node_modules: Excluded" が出れば成功
# → 配下の "node_modules/<file>" が出てこないことも併せて確認

# シェル関数 / systemd unit が正しいか
clamscan-home ~/Projects/<your-repo>/ 2>&1 | grep -E "node_modules|\.git/objects|Excluded" | head
# → 各除外対象に "Excluded" が出れば全 13 パターンが効いている

⚠️ --verbose で除外ログを見る方法は ClamAV のバージョンで出力形式が変わるため信頼性が低い。**「除外対象に : Excluded が付与されている」「SCAN SUMMARY のスキャンファイル数が大幅に減っている」**で見るのが最も確実です。

参考: clamd 常駐版の除外設定（clamscan とは別系統）

業務開発機では clamd 常駐は推奨しないので通常は不要ですが、もしリアルタイムスキャンを使うなら、/etc/clamav/clamd.conf の ExcludePath に書きます。これは clamscan のオプションとは別物で、clamd プロセス起動時に読み込まれます：

ExcludePath ^/home/.+/GoogleDrive
ExcludePath ^/home/.+/NAS
ExcludePath ^/home/.+/\.cache

設定後は sudo systemctl restart clamav-daemon で再読み込み。

💡 ClamAV は「既知マルウェアの検知」に有効、行動ベースの脅威には別途対策が必要 — Linux 開発機の主な脅威はサプライチェーン攻撃（npm / pip / 不正な Docker イメージ）と OSS 依存物。ClamAV はそれら一部のシグネチャベース検知に有効ですが、ゼロデイには DevContainer 隔離 + bypassPermissions の閉じ込め（第 4 回）/ AppArmor（第 5 回）/ 最小権限運用で対処します。

🛡️ リスクと対策

✅ 第 3 回まとめ

業務 PC 化フェーズで押さえるべき項目チェックリスト：

• NVIDIA ドライバを 580 LTS で導入。ubuntu-drivers devices で候補確認 → sudo apt install nvidia-driver-580 → 再起動 → nvidia-smi で Driver Version: 580.142 を確認
• サスペンド系 4 target すべてを systemctl mask で完全無効化。NVIDIA + 比較的新しいカーネルでの復帰時カーネルパニックは「数時間放置できる開発体験」を直撃するため、業務 PC では消費電力よりも安定性を優先
• KDE 電源管理側もサスペンド無効化。systemd だけ mask しても KDE 側から呼ばれてエラーログが残る
• HHKB Hybrid は Fn+Control+0 で USB モードに固定。Bluetooth は「動くこともある」レベルなので業務利用には不向き
• 標準ターミナル Ptyxis ではなく Terminator か Konsole。Windows 出身者なら Terminator + PuTTY style paste + Copy on selection で操作感ギャップが消える
• 有線 5GbE で接続。Wi-Fi（340 Mbps）→ 有線（2.3 Gbps）の差はあらゆる体感に効く
• Linux で 100% 揃えない割り切り。Kraken Elite LED は Windows 側で設定すればハードウェア側に保持される
• ウィルス対策は CLI ベースの ClamAV で運用。ClamTK は 2024 年 4 月メンテ停止で削除推奨。clamav-freshclam を systemd で常駐させて自動更新。スキャンは **「狙い撃ち（手動・数秒〜数分）」+「ホーム全体（深夜 systemd timer・約 1 時間）」**の二段構え。clamd 常駐は重いので業務開発機では使わない。除外は --exclude-dir をコマンドラインで複数並べる（@filename 構文は存在しないので注意）
• エッジダブルクリックでウィンドウ縦/横最大化 — KDE Plasma 6.1.3 以降の標準機能。Terminator は即座に動く / VS Code は window.titleBarStyle: native（第 4 回）/ Chrome は KWin Bug 502885 待ちで KDE ショートカット代替
• LibreOffice は kubuntu-desktop に標準同梱（追加コストゼロ）。脱 Microsoft 戦略は Workspace（クラウド共同編集）+ LibreOffice（オフライン MS 形式）の二段構えが現実解。LibreOffice 26.2 は MS Office 互換性が大幅向上（Excel 関数 92%、DOCX/XLSX/PPTX 読み書き）。Calligra ではなく LibreOffice なのは「.docx 書き込み非対応」という互換性問題が決定打。日本語業務では sudo apt install libreoffice-l10n-ja で UI 日本語化必須

これで OS の土台 + 業務 PC 化 までが完成しました。次回からは Ubuntu の上に開発スタックを積み上げていきます。

次回（公開済み）「Ubuntu 開発環境セットアップ」では、ネイティブ Docker Engine・VS Code・DevContainer・Claude Code を組み立て、Agent Teams が安定動作する tmux 環境までを扱います。

📚 シリーズ記事

🔗 関連リソース

CTS-KB 内の関連記事

• 脱Microsoft 全体戦略・総論 — シリーズ第 1 回
• Windows 11 + Ubuntu デュアルブート構築 — シリーズ第 2 回（前提となる OS 構築）
• Ubuntu 開発環境セットアップ — シリーズ第 4 回（次の積み上げ）

関連用語

• Ubuntu — 業務 PC 化の対象 OS
• KDE Plasma — Windows ライクな操作感のデスクトップ環境
• Wayland — KDE Plasma 6 系のデフォルトディスプレイサーバー

外部リソース

• Ubuntu Drivers ドキュメント
• NVIDIA Linux ドライバ
• systemd.special man page — sleep.target / suspend.target の挙動