Ubuntu

UbuntuのAIキルスイッチ、正体はSnap削除

CanonicalがUbuntu 26.10からAI機能を段階導入する計画を出した翌日、エンジニアリング担当VPのJon Seagerが釈明を投じた。「キルスイッチはSnapの削除だ」という答えは、不信を解くより別の疑問を呼ぶ構造になっている。

情報の灯台

2026年4月28日

Snap削除がキルスイッチである、という回答

Phoronixが取り上げたJon Seager(ジョン・シーガー)の投稿は、前日に公開された「The future of AI in Ubuntu」が呼んだ反発を受けたものだった。前日の発表は、Ubuntu 26.10からAI機能を「テキスト読み上げ」「カメラフォーカス」といった既存機能の補強を皮切りに段階導入していく計画を示したもので、コミュニティからは「マーケティング言葉が並んでいる」「プライバシー懸念が無視されている」「Opt-inかOpt-outかが不明瞭だ」という声が相次いだ。

シーガーはCanonicalでUbuntuのエンジニアリング担当VPを務め、Ubuntu Desktop・Server・Foundationsの3チームを率いる立場にある。翌朝、3点の釈明を投稿した。

ひとつ目が、いわゆる「キルスイッチ」の話だ。

「グローバルなキルスイッチは追加しない」と言いはしたが、これらの機能はすべてSnapとしてOSに提供される。既存のUbuntuスタックの上に重なる形だ。つまり、それらのSnapを削除する選択肢は常に存在する。これが、出荷予定の機能に対する一種のキルスイッチとして機能する。

機能を消したければパッケージごと消せばいい。設計としては筋が通っている。ただ、これを「キルスイッチ」と呼ぶのが妥当かどうかは別途検討が要る。一般にキルスイッチとは、機能の停止だけを目的とした明示的なトグルを指す。Snapごと削除するのは「停止」というより「アンインストール」に近い。Snap削除は機能の終了であって、機能の制御ではない。

26.10は厳格なOpt-In、その先は

ふたつ目の釈明はOpt-Inの方針だ。Ubuntu 26.10ではAI機能を「プレビュー」として、厳格なOpt-Inで提供するとシーガーは明言した。

その先のリリース、つまり27.04以降については、初回起動時のセットアップウィザードに「AIネイティブ機能を有効にするか」のステップを置くという。LLMはサイズが大きく、インストーラーに同梱できないから、Opt-Outしたければ単に何も降ってこない、と説明している。

ここはユーザーにとって悪い話ではない。デフォルトオフから始まり、27.04以降もインストール時に明示選択する形が維持されるなら、勝手に有効化される心配は当面ない。問題は「当面は」という限定がいつ外れるか、だ。Opt-Inから始まったテレメトリやアカウント連携が、リリースを重ねるうちにいつの間にか前提化していく流れは、過去の他社製品で何度も見てきた光景でもある。

クラウド送信は「明示設定が必要」

3つ目の釈明はクラウド推論について。元の発表では「クラウドへログを送るのか」という疑念がコミュニティで広がっていた。

デフォルト構成は常にローカル推論・ローカルモデルになる。クラウドベースの推論を使うには、明示的に設定し、APIトークンや認証情報を提供する必要がある。

これは比較的明快な回答だ。ローカルがデフォルトで、クラウド利用は明示同意を要する。プライバシー設計としては妥当な線で、Canonicalがこれまで推進してきた「inference snap」(量子化されたオープンウェイトモデルをパッケージ化する仕組み)の路線とも整合する。

ここで気になるのは、こうした重要な情報が発表時に明文化されていなかったことだ。クラウド送信の有無、Opt-Inの厳格さ、キルスイッチの実装方法──いずれもAIをOSに組み込む話で最初に説明されるべき項目で、それが「コミュニティの混乱を受けた釈明」として翌日に出てきた。プロダクト戦略としての完成度に疑問を残す。

AI共著コード「我々もそうする」

シーガーはもうひとつ重要な点に踏み込んだ。AIが共著したコードをUbuntuに取り込むかどうか、だ。

AIが共著したコードを出荷すべきかどうか──現実には、我々はそれをやることになる。エコシステムの基盤プロジェクト、たとえばカーネル自体も、AI共著コードのガバナンス方針を整え、節度ある正確な貢献は受け入れるようになっている。

カーネルの動向を引き合いに出して自分たちの方針を正当化する手法は、議論の方向としては理解できる。実際、Linuxカーネルの開発プロセスはAI関連の言及を含むようになっている。一方で「カーネルもやっているから問題ない」という論法は、UbuntuがディストリビューションとしてAI生成コードをどう審査するかという論点を脇に追いやる効果も持っている。カーネル開発のレビュー文化は、Ubuntuのパッケージング工程と同じ厳格さで運用されているわけではない。

26.04 LTSには影響なし、26.10へ向けた工程表

最後にシーガーは、Ubuntu 26.04 LTS(Resolute Raccoon、4月23日リリース)にはこれらの機能は一切入っていないと改めて確認した。すべては26.10以降の話で、今後数か月かけて開発される。26.04 LTSユーザーが希望すれば後からこれらの機能をインストールできるようにする予定だ、とも付け加えている。

整理すると、26.04 LTSは無風、26.10は厳格Opt-In、27.04以降はセットアップウィザードでの選択──という3段階のロードマップになる。各段階で初期値がどこに置かれるかが、AIをユーザーの手元に届ける勢いを決める。

つまり、いま手元のLTSを使っているユーザーには、当面のあいだ何も降りてこない。10月の26.10、コードネーム「Stonking Stingray」が、最初の判断材料を出すリリースになる。

釈明で消えなかった疑問

シーガーの返信は、リプライツリーで一定の支持を得た。「明確化に感謝する」「成熟した投稿だ」という反応もあり、Opt-Inの厳格さやクラウドのデフォルトオフは、心配していたユーザーには安心材料として届いている。

ただ、Discourseのスレッドを通読すると、根本的な不信は残ったままに見える。Ubuntuの選択肢を尊重する設計だから選んできたのにAI機能を強制的に推されるのは話が違う、LLMはクラウド経由でしか動かない場合が多くその時点でプライバシー懸念は本質的だ、Mozillaが Firefox に追加したような明示的なキルスイッチがないならSnap削除を強いられる構造そのものが問題だ──そんな指摘が連なる。

CanonicalがSnapを中心に据えた設計を選び続けてきたのは、技術的にも商業的にも一貫している。AI機能をSnapで配るのも、その路線の自然な延長だ。疑問は技術ではなく順序にある。AIをOSに組み込むなら、コミュニティへの最初の説明で「キルスイッチ」「Opt-In」「クラウド」の3点を明示するのが筋だった。それが翌日の釈明として出てきた事実が、プロダクト発表とコミュニケーションの設計に何かが欠けていることを示している。

10月の26.10で、Canonicalがどんな初期設定とどんなUIを提示するか。釈明の言葉ではなく、実装そのものが評価される段階が、半年後に控えている。

参照元