Linux

UbuntuがAI機能を本格搭載へ、ローカル推論優先の設計哲学

CanonicalのVPエンジニアリングであるジョン・シーガー（Jon Seager）が、Ubuntuの今後のAI戦略を公式に表明した。鍵は「ローカル推論優先」と、AI機能の二層分離だ。

情報の灯台

2026年4月28日

「AI製品にはならない、しかしAIで強くなる」

Ubuntuの母体であるCanonicalが、長らく曖昧だった「AIをOSにどう載せるか」という問いに、公式の回答を出した。Ubuntu Discourseに投稿されたシーガーの文章は、そのまま社内向けの方針書のような構成を持っている。

冒頭で打ち出される結論は明快だ。CanonicalはAI機能をUbuntuに段階的に搭載していく。ただし方針は「焦点を絞り、原則に従う」ものであり、推論はローカルをデフォルトとする。クラウド経由の大規模モデルではなく、ユーザーの手元で動くモデルを基盤に据えるという宣言だ。

Ubuntuは、AI製品になっているわけではない。だが、慎重なAI統合によって、より強くなることはできる。

シーガーがこう締めくくった一文は、最近のテック業界の空気のなかで控えめに言っても異色だ。WindowsはCopilotをOSの中核に据えた。macOSはApple Intelligenceで同じ方向に進んだ。Linuxユーザーのなかには「Windowsから逃げてきた」「逃げる準備をしている」と語る声もある。そうした文脈で、Canonicalは「逃避先と最先端の両立」を試みようとしている。

Implicit AI と Explicit AI、二層に分けた設計思想

シーガーは、UbuntuにおけるAI機能を二つの層に明確に分離した。これが今回の発表で最も独自性のある部分だ。

Implicit AI （暗黙的AI）は、既存のOS機能をAIで強化する。ユーザーから見れば「AI機能」というよりも、単に「アクセシビリティが良くなった」「読み上げ精度が上がった」という体験になる。Speech-to-Textや Text-to-Speech が代表例として挙げられている。シーガー自身、これらを「AI機能」としては位置づけていないと書く。

私はこれらを「AI機能」とは見ていない。クリティカルなアクセシビリティ機能であり、LLMの採用によって、ほぼデメリットなしで劇的に改善できるものだ。

一方、Explicit AI （明示的AI）は、より「AIネイティブ」な機能群を指す。新規ドキュメントやアプリケーションの生成、トラブルシューティングの自動化、個人向けの自動化タスク（毎朝のニュースブリーフィングなど）といった、ユーザーが意識して「AIを使う」場面のことだ。

この区分は、技術的な実装の違いというよりも、ユーザー体験の設計に関わる。Implicit AIは「Ubuntuがすでにできること」を改善するもので、新しいメンタルモデルを要求しない。Explicit AIは「新機能」として導入される。同じ「AI」という言葉でくくられがちなものを、設計の意図で分けた点に、Canonicalの慎重さがにじむ。

ローカル推論を支える「Inference Snaps」

ローカル推論を優先するという方針には、すでに技術的な裏付けが用意されている。Canonicalは2025年10月にInference Snapsを発表しており、これは特定のシリコンに最適化されたモデルを、Snapパッケージ経由で配布する仕組みだ。

Inference Snaps公式発表によれば、snap install nemotron-3-nano のような単一コマンドで、ユーザーの環境に最適化されたモデルが導入される。Ollama、Hugging Face、量子化モデルの選択といった煩雑な作業を、Canonicalが裏で吸収する設計だ。Intel、Ampereなどのシリコンパートナーが、自社ハードウェア向けの最適化済みビルドを提供している。

Snapパッケージとして配布される以上、Inference SnapsはSnapのconfinement（権限制限）の対象になる。シーガーはこの点を強調する。モデルがユーザーのマシンや個人データに無制限にアクセスすることはない、と。

推論Snapは、他のSnapと同じconfinementルールに従う。これは、モデルがマシンやデータに無差別にアクセスしないというユーザーの安心感につながる。

ここで生きてくるのが、Canonicalが長年かけて築いてきたSnapのサンドボックス基盤だ。エージェント型ワークフローの導入を考えるとき、「AIエージェントに何を許すか」を制御する仕組みが必須になる。すでに整備されたconfinementを土台として再利用できる点は、Canonicalにとって構造的な優位性だ。

エージェント型ワークフローと、SREへの応用

シーガーが描く未来像は、デスクトップに留まらない。Linuxマシンに「Wi-Fiの接続不良をトラブルシュートしてくれ」と頼める日。あるいは、TLS設定済みのソフトウェアフォージを「立ち上げてくれ」と頼める日。スマホアプリや音声、テキストメッセージを通じて、自分のLinuxマシンを操作できる日。

サーバー側では、SRE（Site Reliability Engineer）の業務支援が想定されている。インシデント時のログ解釈、ルート原因分析の高速化、ガードレール付きのスケジュールメンテナンス。エージェントに権限を渡すことについて、シーガーは「新しいリスクの種類が生まれるわけではない」と整理する。

エージェントに作業の一部を委譲することは、必ずしも全く新しいリスクのクラスを持ち込むわけではない。既存の本番システムの制約を継承すべきだ。

つまり、本番環境にすでに存在するアクセス制御、監査ログ、観察と操作の分離といった枠組みのなかでエージェントを動かす。「エージェントを信頼する」のではなく、「既存のガードレールを信頼する」という考え方だ。これは、AIエージェントの導入に対するエンジニアリング寄りの解決策として、筋が通っている。

「グローバルAIキルスイッチ」は作らない、というシーガーの回答

しかし、Discourseのコメント欄では、すでに別の論点が立ち上がっている。「AI機能を完全にオフにできるグローバルなキルスイッチを用意してほしい」という要望だ。

これに対するシーガー本人の返答は、率直に言って身も蓋もない。

「グローバルAIキルスイッチ」は導入しないと思う。Ubuntuユーザーが今日ソフトウェアを消費する経路は非常に多様で、それを「正直に」実装するのは極めて複雑だからだ。

代わりにシーガーが提示するのは、Ubuntu 26.04 LTSでデフォルト有効化されたSnapのプロンプト機能のような、より粒度の細かい制御だ。モデルがランタイムで何をするかを、Snapサンドボックス越しに管理する。ユーザーは個別の機能ごとに許可を与えたり拒否したりできる。

この姿勢は、DuckDuckGoが提供する noai.duckduckgo.com のような「全部オフのスイッチ一つ」とは対照的である。検索エンジンのDuckDuckGoは、AI機能を完全に排除した別ドメインを用意して「AIフリーの検索体験」を提供している。Ubuntuのコメント欄でも、このDuckDuckGoの方針を引き合いに出して、Canonicalにも同様のオプションを求める声が上がっている。

ユーザーが望むのは「AIから逃げられる場所」だ、という主張がコメント欄には繰り返し現れる。Microsoftの強引なAI統合に違和感を持ってLinuxへ向かおうとしている層にとって、Ubuntuが「AIを内蔵」していくこと自体が、すでに失望の理由として語られている。

残る問い、「焦点を絞った原則」が機能するか

Canonicalの方針が、言葉のうえで筋が通っていることは間違いない。オープンウェイトモデル、オープンソースのハーネス、ローカル推論、Snapのconfinement、Implicit/Explicitの分離。一つひとつは、エンジニアリング的に妥当な選択だ。

問題は、これが実装で守られるかである。Canonicalは過去にも「ユーザーの選択を尊重する」と表明しながら、Snapの強制的な置き換えやUbuntu Proの宣伝表示で、ユーザーコミュニティの一部から強い反発を受けてきた経緯がある。「方針の表明」と「実装での約束履行」のあいだには、しばしば距離がある。

Ubuntu 26.10「Stonking Stingray」（2026年10月15日リリース予定）が、最初の試金石になる。ここでImplicit AIがどう統合されるのか。ユーザーがAI機能の有無を実際にどこまで制御できるのか。「アクセシビリティのAI機能を最優先にしてほしい」というコメント欄の声が、どこまで開発の優先順位に反映されるのか。

Canonicalは、AIに対して「全乗っかり」でも「全拒否」でもない第三の道を提示している。その道が本物かどうかは、これから一年の実装が答えを出す。

参照元