ハクソク

世界を動かす技術を、日本語で。

Anthropic、公式の「Claude Desktop」をLinux用に出荷してください。

5時間前原文(github.com)

概要

  • Claude Desktop のLinux版公式ビルドを求める要望
  • 現状は macOS/Windowsのみ公式サポート、Linuxは非公式再パッケージ依存
  • 開発・テスト効率やセキュリティリスク の観点から公式対応の必要性を訴求
  • 既存の技術基盤・市場データから Linux対応の実現可能性 を指摘
  • 最低限の要望として 公式見解の公開 やガイドラインの提示も提案

Claude DesktopのLinux公式ビルド要望

  • 現状

    • Anthropicは Claude Desktop をmacOS/Windows向けにのみ公式配布
    • 公式ダウンロードページで「 Linux未対応」と明記
    • Claude Code CLI はLinux向けにapt/dnf/apkリポジトリで配布されているが、 GUI機能や拡張機能の開発・テスト は不可
    • Cowork や Desktop拡張、 デスクトップ連携機能 は公式Desktopアプリ限定
    • Linuxユーザーは 非公式再パッケージ やWine経由での利用を余儀なくされている

  • 技術的背景

    • Anthropicは既に Linux向けバイナリ や 署名付きリポジトリ を運用
    • macOS版Coworkは Apple Virtualization Framework 上のUbuntu 22.04 VM内でClaude Codeを実行
    • Windows版は Hyper-V を利用
    • Linux用Cowork はコミュニティによる移植（johnzfitch/claude-cowork-linux）で実現可能性が実証済み
    • 主要な非公式再パッケージ（aaddrick/claude-desktop-debian）は4,500スター超、CI・署名付きリポジトリ・最新追従など高品質

  • セキュリティ・信頼性の課題

    • OAuthトークンやAPIキー を扱うアプリであり、 非公式パッケージの利用は構造的リスク
    • 現行メンテナの信頼性とは別に、 公式がLinux対応しないこと自体が前例リスク
    • Linuxは開発者にとって決して少数派ではなく、 Stack Overflow 2025調査で27.7%がUbuntuを主OS と回答

  • なぜ公式対応が必要か

    • プラグイン開発・テスト のたびにmacOS/Windowsへの切り替えが発生し、開発効率が著しく低下
    • 公式ビルドが無いことで非公式再パッケージ依存が常態化 し、セキュリティ面でのコスト増大
    • Linux市場の拡大 （StatCounter: インド16.2%、米国5%超、世界4.7%）を無視できない状況

  • 提案する解決策

    • 公式Claude Desktop Linux版 を、Ubuntu LTS（およびDebian）向けに 署名付き.debパッケージとaptリポジトリ で配布
    • 既存の Claude Code配布パイプライン を流用可能
    • 最低限の対応として
      • 公式見解の公開 （ロードマップ外なら理由付きで明記）
      • 推奨コミュニティパッケージの明示 や セキュリティレビュー
      • Linuxユーザー向けの明確なセキュリティガイドライン の提示

  • 他の回避策とその問題点

    • CLI（Claude Code） ：GUI機能・拡張開発不可
    • Webクライアント（claude.ai） ：拡張・Cowork不可、状態保持やリソース効率の問題
    • 非公式再パッケージ ：セキュリティ・信頼性・公式アップデート非対応
    • Wine経由のWindows版 ：動作不安定、セキュリティリスク
    • macOS/Windowsへの都度切り替え ：開発効率の著しい低下

公式対応が難しい場合の「納得できるNo」の条件

  • 工数やサポートコスト （Linuxの多様性、サンドボックス・グラフィック環境差異、既存コミュニティパッケージの課題）を理由とする
  • エンタープライズ需要や収益性、 他機能（CoworkやMCPなど）へのリソース集中 を優先
  • 配布・署名・サポート体制の複雑さ を考慮
  • その上で「 現時点ではロードマップ外」と 明確な理由付きで公表 し、 セキュリティガイドラインや推奨パッケージの案内 を行う

まとめ・要望

  • Linux公式ビルドの公開 が最善
  • それが難しければ、 公式見解の明示 と 信頼できる情報提供 でセキュリティリスクを最小化
  • 「理由なき沈黙」が最大のリスク であり、開発者コミュニティの信頼維持のためにも透明性ある対応を要望

Hackerたちの意見

CLIではカバーされてないデスクトップアプリの何が恋しい？俺も主にLinux使ってるから、CLIだけ使ってるんだけど、ちょっと気になって。

└

主に：真のサンドボックス分離。モデルに俺のマシンに完全にアクセスされるのは嫌なんだ。Claudeが理解できるダンプフォーマットを使えば、見せたいファイルだけ渡せるし、壊される心配もない。アクセスリストとか設定するのは面倒だし、CLI製品がちゃんとサンドボックスされてるとは信じられない。彼らのソフトウェアはほとんどAIのコードだし、毎日Claudeからバグを拾ってる。役に立つこともあるから、使う価値はあるけど、俺のマシンにアクセスを許可するのは絶対にないな。

└

AnthropicのサブスクリプションでCLIはもう日常のルーチンを提供してないんじゃない？クロス会話メモリ検索もあって、Claude Codeとは違う会話データセット（Claude Web / Claude.AIの会話）を使ってるし。Claude Codeがクロス会話検索できるかもわからない。デスクトップインターフェースはMarkdownをフォーマットされたテキストとして表示して、CLIよりもインタラクティブなアーティファクトをうまく見せてくれる。とはいえ、実際にはほとんどすべてCLIを使ってる（Windowsでも）。15個のcronジョブに制限された日常の「ルーチン」のためにClaude Desktopを使うより、俺は自分のミニマルなハーネスを作り続けて、他のプロバイダーのモデルにルーチンを移すつもり。

└
  1. 非Linuxの同僚と同じ体験ができるから、学びやプロセスを共有できる 2. ローカルで実行されるスケジュールタスク（https://support.claude.com/en/articles/13854387-schedule-rec...）これはClaude Codeのルーチンとは重要に異なる 3. 同じフォルダ内で複数のプロジェクト/孤立したメモリ 4. より良いUI
└

CLIはコーディングタスクにはいいけど、コーディング以外のことにはデスクトップアプリがすごく役立つよ。

└

それで、デスクトップアプリはウェブページではできないことを何をしてるの？

Anthropicがソフトウェアをポーティングするための自動ツールでもあればいいのに。

└

既存のSlopを使って、シンプルなターミナルアプリに1GBのRAMが必要なLinuxアプリをさらにダメにする… 500K以上の給料をもらってる開発者が、ちゃんとしたアプリを書ければいいのにね。

└

それがボトルネックってわけじゃなさそうだね。

└

そこに*「いわく」ってのを忘れてるよ。

└

ごめん、もうその使い方じゃないよ。今は（メモを見ながら）「前方展開エンジニア」についてだね、そういうこと。さあ、作ってみて！

└

無限のソフトウェアを作れるとしても、何を選んで作業するかにはすごく意図的である必要がある。コーディングが「無料」になったとしても、テストやサポート、計画にはまだコストがかかるからね。

そうだね！でも、うーん、どうかな。数時間前に非公式ビルドをインストールしたばかりなんだけど、起動したらElectronプロセスがいっぱい立ち上がって、スワーム検出器が反応したから、すぐに閉じちゃった。もう二度と触ることはないと思う。[0] https://github.com/aaddrick/claude-desktop-debian

└

こんにちは！それ、私のことだし、ちょっと変な感じ。もう少し詳しく教えてくれたら、原因を探る手助けができるかも。もしくは、リポジトリに問題を提出してもいいよ。基本的には一つのメインのElectronプロセスだけのはず。

自分のために一発でやってみて。ダサいけど、ここでみんなが話してるのは辛辣な自動修正と自己破壊的な仕事の話ばっかりだから、たまには自分を楽しませないとね。

└

自己破壊的な仕事 Glad someone else sees this as well in this crappy website こんなクソサイトで他にも同じことを思ってる人がいてよかった。

こんにちは！私は非公式ビルドを管理してるよ。https://github.com/aaddrick/claude-desktop-debian Debianって名前に入ってるけど、範囲はすべてのバックエンドやコンポジタに広がってる。多くの会社がLinuxのElectronアプリを公開しない理由は、フラグメンテーションだね。ウェブページをアプリとして表示する以上のことをやろうとすると、複雑になってくる。テスト用にVMをいくつか用意してるけど、まだ必要なんだ。

└

まだミスしちゃうんだよね。モバイルのスワイプキーボードは最悪だけど、その習慣をやめられない。

└

OpenCodeができるなら、Anthropicもできるはず。

└

Linuxアプリの最大の問題は、WindowsやmacOSのアプリのように簡単に配布できないことだね。安定したABIがないから。20年前にこれを聞かれたら、2026年には確実に安定したABIがあるって言ってたけど、全然ダメだった。

└

多くの会社がLinuxのElectronアプリを公開しない主な理由 でも、実際には公開してるよね？ 会社はElectronアプリ以外のものは公開しない。デスクトップLinuxがFOSS以外から何かを得るとしたら、それはElectronだよ。Spotify、Discord、Slack、VSCode… まだまだ続く。利益を追求する会社がここ20年でGTKやQtのアプリをLinux向けに提供したことはないと思う。君の努力には拍手を送りたいけど、これはおそらく数兆ドルの会社で、製品には何千ものElectronアプリがトレーニングセットに入ってるはず。彼らは君にお金を払うべきだよ。

└

主な理由は、ほとんどの企業がLinuxのElectronアプリを公開しないのは、フラグメンテーションだと思う。ウェブページをアプリとして表示する以上のことをやろうとすると、すごく複雑になる。実際に確認済み。以前の会社では、少数の顧客のためにLinuxデスクトップクライアントをリリースするのに一生懸命だったけど、すぐに互換性の地獄に陥る。最近のUbuntuのリリースをターゲットにすれば大丈夫だと思っても、アプリの一部がうまく動かないせいで、聞いたこともないディストリビューションを使っている人たちからクレームが来る。エンジニアたちはVMにそれをインストールしてデバッグするのに半日を費やすけど、問題は上流のどこかにある。Linuxの問題に関するチケットの数は増え続けていて、どれもデバッグに時間がかかる。顧客の数が少なすぎて、やる価値がないのに、でもその顧客たちは怒ってるし、声を上げてる。TwitterやHacker News、Redditで「自社のソフトウェアはゴミだ」って投稿してるけど、彼らが13年前のThinkPadで知らないディストリビューションを使ってることには触れない。これってオープンソースプロジェクトにも影響を与える。いくつかの人気のあるOSS Electronアプリは、コマンドラインの回避策を設定しないと多くの人気ディストリビューションでは動かないし、動いても不安定。オープンソースプロジェクトはオープンソースだから許されるけど、もし自社が何かをリリースしたら、望んでいなかった多くの怒った顧客を抱えることになるかも。

└

Flatpakサポートを考えたことある？ rough edgesはあるけど、Arch/Fedora/Ubuntuで配信されてるアプリをFlatpakで使ってるよ。

└

Codex Desktopの似たようなプロジェクトがあるよ: https://github.com/ilysenko/codex-desktop-linux。LinuxにCodexをインストールするためのこのプロセスを経て、OpenAIが公式のポートを持っていない理由が本当に不思議だ。アプリのすべての部分をテストしたわけじゃないけど、すべて意図した通りに動いてるし、コンピュータの使用も問題なく動いてる。

└

Opusよりももっと能力のあるLLMの仕事っぽいね。

それと、モバイルで仕事用と個人用のアカウントを簡単に切り替えられるようにしてくれない？

└

それはいいね。こんなにお金がある会社が、基本的なUXすら実装してないなんて、マジで理解できない。びっくりだよ。

個人的には、Claude Codeにテキストを緑にして、キャラクターが画面の上から一つずつ降りてくるモードがないのが理解できない。まるで「マトリックス」みたいに。

└

すごくイライラする。今は緑のサングラスをかけて、日本語に言語を変えて、モニターを横にしないと本当に仕事ができない。

私たちのアプリ、Runner: Cowork++はLinuxをサポートしてるよ :) https://runner.now/

正確にはClaude Desktopじゃないけど、複数のOSで動く「一般的な」ものがあるよ（Tauriで書かれてる） - Msty Claw [1]。それにE2E暗号化されたモバイルアプリもついてくるよ。[1]: https://msty.ai/claw/features

どうやってやるの？彼らはエージェントループを設計するのに忙しいんだ。コードの行数は8倍も多い！！！