Linuxデスクトップに「AIアシスタント」を乗せた製品が増えるにつれ、かえって不信感を抱くユーザーも少なくない。クラウド送信が前提の推論、ログアウト後も残るデータ収集の痕跡、そして「AIが搭載されました」という触れ込みで増えるだけの権限要求。Ubuntuを開発するCanonicalのVP of Engineering、Jon Seager氏が公開した設計方針書は、その一つひとつへの答えを持っている。AI機能の一括オフ機能（kill-switch）については「実装が複雑すぎて正直に作れない」と明言し、代わりにSnap confinement（コンテナに近い隔離機構）とローカル推論による透明性を選択した。「UbuntuをAI製品にしない」という宣言は単なるブランディングではなく、設計上の具体的な選択の積み重ねだ。
Ubuntu 26.04 LTS翌週の公開は競争戦略の表明だった
Ubuntu 26.04 LTS（コード名: Resolute Raccoon）は2026年4月23日にリリースされた。GNOME 50とLinux 7.0を採用し、CUDA/ROCmをネイティブで同梱するなど、AI/ML用途を意識した構成だ。その4日後、Seager氏が投稿したのは技術発表ではなく、Canonicalの内部哲学を率直に書いた文書だった。
MicrosoftのCopilot+とmacOSのApple Intelligenceが先行する中で、Linuxディストリビューションはその後追いか差別化かを選ぶ岐路にある。Seager氏はオープンウェイトモデルとCanonicalの価値観に合致するライセンス条件を優先すると明記した。MicrosoftやGoogleのクローズドモデルとクラウド依存のエコシステムから、Canonicalは意図的に距離を置いている。
Red Hat/FedoraがInstructLabとIBM Granite LLM（大規模言語モデル）でAI開発者向けのツール整備を進める一方、CanonicalはデスクトップからサーバーやSRE（サイト信頼性エンジニアリング）まで、一般ユーザーとエンジニアの双方を同じ設計思想でカバーする方向を選んだ。AI機能を段階的に投入するという方針も、この射程の広さから来ている。Ubuntu 26.04 LTSはそのスタート地点だ。
OS機能として溶け込む「暗黙的AI」、ユーザーが呼び出す「明示的AI」
Canonicalは社内でAI機能を2種類に分類している。「Implicit AI（暗黙的AI）」と「Explicit AI（明示的AI）」だ。前者はspeech-to-text（音声認識）やTTS（text-to-speech、テキスト読み上げ）のようなアクセシビリティ機能が該当し、「AIフィーチャー」として前面に出さず、OSの機能として自然に使える形を目指す。後者は文書作成エージェント、自動トラブルシューティング、ニュースブリーフィング等のパーソナル自動化で、ユーザーが意図的に呼び出し、処理内容を把握したうえで使う設計だ。
どちらのバケツに入れるかで、UIの提示方法からパーミッション設計まで変わってくる。単なる概念分類ではなく、開発チームが機能を設計する際の判断軸として機能する分類だ。「AIが入っている」という印象を押し付けずに機能を届けるか、ユーザーが選んで使える形にするか——その違いが、実装の細部に直結している。
Seager氏は「LLM（大規模言語モデル）をシステムのコンテキストで注意深く活用すれば、現代のLinuxワークステーションの能力を解きほぐし、より多くのユーザーに届けられる」と述べている。「解きほぐす」という言葉には、OSが習熟の壁を下げる補助線としてAIを使う意図が込められている。アクセシビリティ機能から開発者向けの自動化ツールまで同じ設計哲学に根ざしているのは、ユーザーからエンジニアまで、Linuxの複雑さを下げる役割を担おうとするからだ。
snap install 1行で完結するローカル推論基盤「Inference Snaps」の設計
Snapとは、依存関係を含めたアプリを自己完結パッケージとして配布・実行する仕組みで、Canonicalが開発している。アプリはSnap confinementによってシステムの他の部分から切り離されて動作するため、想定外の領域へのアクセスを防ぐ。Inference Snapsはこの仕組みをAIモデルに適用したものだ。各モデルはIntel・AMD・NVIDIA等のシリコン向けに最適化された状態でパッケージ化されており、snap install nemotron-3-nano のようなコマンド1行でインストールできる。
推論エンジン部分には「読み取り専用の分析、アクション実行に対するスコープを厳格に絞ったパーミッション、意思決定と結果の完全な監査可能性」が設計上の要件として組み込まれている。現時点でインストール可能なモデルはNemotron 3 Nano、Gemma 3、DeepSeek R1、Qwen VLで、Seager氏は今後の対応候補としてGemma 4やQwen-3.6-35B-A3Bに言及しているが、これらはまだカタログに収録されていない。
クラウド推論を排してローカル処理を優先する設計は、プライバシーポリシーとOSSの価値観の両方と整合する。ユーザーデータがサーバーに送出されない構成は、Snap confinementの監査可能性と組み合わさることで、「何が動いているか把握できる」状態を維持できる。キルスイッチを設けない代わりに透明性で応えるというCanonicalの選択は、この設計の上に成り立っている。
Wi-Fiトラブルシューティングからインシデント対応まで同じ思想が貫く
Wi-Fiが繋がらないとき、ユーザーがログを読んでコマンドを調べて試す作業を、OSが状況を判断して次の一手を提示するシナリオに変える。これがExplicit AIとして設計されたデスクトップ支援の具体像だ。TLS設定済みのソフトウェアフォージの自動セットアップ、SREでのログ解釈と根本原因分析（RCA）の高速化も、Seager氏が例として挙げた用途に含まれる。
SREの文脈では規模が異なる。本番環境のログからRCAを絞り込む作業は人間が読めば数十分かかる処理で、ここでのAI活用は分析速度を支援するものだ。デスクトップのアシスタント機能と同じInference Snaps基盤で動かせるなら、デスクトップユーザーとインフラエンジニアを別々の製品ラインで対応する必要がなくなる。
Snap confinementとローカル推論の組み合わせが、「状況理解」を外部サービスへの依存なしに動作させる。ネットワーク障害なのか、新規セットアップ中なのか、インシデント対応中なのか、OSがユーザーの状況を把握して支援を差し込む設計だ。この守備範囲の広さが、Copilot+やApple Intelligenceとは異なる評価軸をCanonicalに与えている。
「AI製品にはならない」という宣言が持つ重さ
「Ubuntuは AI製品にはならないが、思慮深いAI統合によって強化されることはできる」（原文: "Ubuntu is not becoming an AI product, but it can become stronger with thoughtful AI integration."）。Seager氏がこの一文を書けるのは、ローカル推論優先・Snap隔離・ユーザーが選択する設計という具体的な実装の選択がすでに存在するからだ。宣言と設計が対応していなければ、この言葉は空洞になる。
キルスイッチを「実装が複雑すぎて正直に作れない」として否定した判断も、この文脈で読む必要がある。AI機能がシステムの深い部分と統合されていく中で、ボタン1つでAIをオフにするという単純なスイッチは技術的に誠実ではないというのが、Canonicalの立場だ。Snap confinementとパーミッション制御のほうが、キルスイッチより実質的な透明性を提供できると判断している。
エンジニア評価の方針についても、Seager氏は踏み込んで述べた。「AIの使用量でなく、どれだけうまく成果を出すかで評価する」（原文: "I will not be measuring people at Canonical by how much they use AI, but rather continue to measure them on how well they deliver."）。AIツール活用量を評価軸にする傾向が業界に広がる中で、Canonicalは成果物の質に軸を置く。AIは誰かの仕事を奪わないが、AIツールを高度に使いこなす有能なエンジニアは、そうでないエンジニアの仕事を奪いうる——Seager氏が続けた言葉は、評価方針の背景にある現実認識を率直に示している。
Ubuntu 26.04 LTS以降の5年間のLTSサイクルで、CanonicalがAIキルスイッチを否定してSnap隔離に賭けた選択が評価されるのか問われる。MicrosoftやAppleが機能数で差をつけていく一方、Canonicalは「制御可能性と透明性」を軸にLinuxデスクトップの新たなユーザー層を掴めるかが焦点だ。