見出し画像

Coworkでお試しください　とはなんだ？　久しぶりにわくわくする機能を知ることに

あうと老　OpenPathWorld

「Coworkでお試しください」は、Anthropicのデスクトップアプリ「Claude Cowork」を使ってみてください、という案内文です。
Claude Coworkとは Anthropicが提供する、非エンジニア向けの自律型AIエージェント機能です。従来のチャット型Claudeが「相談相手」だったのに対し、Coworkは結果を説明して立ち去り、完成した作業に戻ってこられるという点が特徴で、実際にファイルを操作したり、作業を代行してくれる"AI同僚"のような存在です。
主な特徴

  • Claude Codeを支えるのと同じエージェント・アーキテクチャを使用しており、ターミナルは不要で、GUI上で操作できます

  • フォルダを指定すると、そこにあるファイルを直接読み書き・編集・新規作成できる(アップロード/ダウンロードの手間が不要)

  • 作業前に実行計画を提示し、ユーザーが承認してから動く仕組み

  • セッションをリモートで実行するため、デスクトップ・ウェブ・モバイル全体で利用可能(ベータ版)

  • スケジュール機能で定期タスクの自動化も可能

使い方 Claude Desktopアプリを開き、メッセージボックスで「Chat」から「Cowork」に切り替えて、やってほしい作業を自然言語で指示するだけです。
つまり「Coworkでお試しください」というメッセージは、「(今やろうとしているような複数ステップの作業やファイル操作を伴うタスクは)Coworkモードで試してみてください」という案内です。何か具体的にやりたい作業があれば、Coworkが向いているか一緒に考えますよ。

質問

インストールしたWINアプリはCoworkではないのか　２つあるのか？

いいえ、アプリは1つだけです。2つあるわけではありません。
インストールしたWindows用アプリは**「Claude Desktop」**という1つのアプリで、その中に「Chat」「Cowork」「Code」という3つのタブ(モード)が並んでいます。

  • Chat — 通常の会話(claude.aiのブラウザ版と同じ)

  • Cowork — PC内のファイルを直接操作させて作業を代行してもらうモード

  • Code — 開発者向けのClaude Code機能

つまり「Coworkアプリ」という別物が存在するわけではなく、インストール済みのClaude Desktopアプリの中の1タブがCoworkです。アプリを開いて、画面上部(または入力欄付近)にあるタブ切り替えで「Cowork」を選べば使えます。
もしタブが見当たらない場合は、以下が原因のことが多いです。

  • Windows Home エディションだと非対応(Pro/Enterprise/Education が必要 — Hyper-V仮想化が必要なため)

  • 仮想化機能(Hyper-V)が無効になっている

  • 無料プランのままで有料プラン(Pro以上)に未加入

  • アプリが古いバージョン

タブが表示されない場合は、お使いのWindowsのエディションと、有料プランに加入済みかを教えてもらえれば、もう少し詳しく原因を絞れます。

質問

ここには該当のTABはないぞ

画像を見る限り、実はCoworkはちゃんとあります。
画面中央のメッセージ入力欄のすぐ下、「チャット」ボタンの右隣に**「Cowork」**というボタンが表示されています(赤枠で囲ってもいいくらい分かりやすい位置です)。
つまりこのバージョンのUIでは、

  • 左サイドバーの「Home」「Code」はページ全体の切り替え

  • 「Cowork」はその中のメッセージ入力欄にあるモード切り替えボタン(「チャット」⇔「Cowork」)

という構成になっています。以前は上部にタブとして並んでいましたが、UIアップデートでこの位置に移動したようです。
「Cowork」ボタンをクリックすれば、そのままCoworkモードでタスクを依頼できるはずです。試してみてください。

質問

わかった、設計者の意図は何　このチャットの中に置いた意味、これを単純にみるとちゃっと単位でプロセスを変えられるけど、同じチャット内なので、統一性は取られる、だけど頭脳だけ入れ替えられるぞってことか

いい着眼点だと思います。ただ一点、比喩を精密にすると逆かもしれません。
「脳」は同じ、変わるのは「体(実行環境)」の方
Chat/Coworkの切り替えは、モデル自体(頭脳)を入れ替えているのではなく、**同じClaudeモデルに与える「権限」と「実行環境」**を切り替えている、というのが実態に近いです。

  • Chat = 手も足も出せない、会話だけする状態

  • Cowork = ローカルファイルやブラウザに手を出せる、VM(仮想マシン)の中で作業する状態

  • Code = 開発者向けにさらに強い権限(Git操作など)を持つ状態

同じ「脳」に、どこまでの「体」を与えるか、という発想です。だから安全設計も「Chat=隔離」「Cowork=VMによる分離」「Code=権限モード」と、それぞれ別の安全モデルになっています。
では「頭脳の入れ替え」は何に対応するか
それは画面右下にある「Sonnet 5」のドロップダウンです。これがモデル(頭脳)そのものの切り替えで、Chat/Coworkの軸とは独立しています。つまり実際には2軸あります。

「同じチャット内に置いた意味」についてここは仰る通りで、公式も「ChatとCoworkは同じホームを共有しているため、同じ場所から始まる」と明言しています。設計意図としては、

  • ユーザーは「まず相談 → 気が変わったらそのままタスク化」という自然な流れで移行できる

  • アカウント・メモリ・プロジェクトなど文脈は共有されたまま、実行モードだけ切り替えられる

  • 別アプリ・別画面に移動する認知コストをゼロにする

という統一UXの思想です。「同じ場所に軽い相談窓口と重い実行窓口を同居させ、境目を意識させない」という設計、と捉えると近いと思います。

質問

ローカルファイルやブラウザに手を出せる、VM(仮想マシン)の中で作業する状態 これをもっと詳しく知りたい インストールしたアプリからAPI経由でWINのシステム関数を呼んで内容を吸い上げるという意味か？ 権限は、実行しているアプリの権限と同じ範囲をアクセスできるということ？ また、ファイルアクセスはファイル名を指定すれば検索からロケーション確定から吸出しまでやれると考えいいのか

いくつか誤解を招きやすいポイントがあるので、実際のアーキテクチャに沿って整理します。
1. 「API経由でWindowsのシステム関数を呼ぶ」のか？
いいえ、そうではありません。実態は本物の仮想マシン(VM)を1台丸ごと起動するという、もっと大掛かりな仕組みです。

  • Windowsの場合、アプリ起動時に Hyper-V (Windows仮想化基盤)を使って、内部にUbuntu(Linux)のVMを立てます

  • そのVMの中で Claude Code CLI(開発者向けのCLIエンジンと同じもの)が動いています

  • Claudeが「ファイルを読む」「コマンドを実行する」というのは、すべてこのLinux VMの中で完結しています。Windowsのシステム関数(WinAPI)を直接叩いてホスト側の情報を吸い上げる、という動き方ではありません

つまり「Windows上で直接動くエージェント」ではなく、「隔離されたLinuxマシンの中で作業しているエージェント」というのが正確なイメージです。だからこそ、暴走してもホストOS本体を壊しにくい設計になっています。
2. 「権限=実行アプリの権限と同じ範囲」なのか？
これも違います。Claude Desktopアプリ自体の実行権限より、はるかに狭いスコープしか持てません。

  • VM起動時に、あなたが明示的に選んだ特定のフォルダだけが、共有フォルダとしてVM内にマウントされます(共有ファイルシステム機構経由)

  • Claudeがアクセスできるのはそのマウントされたフォルダの中身だけです。C:\Users\配下を自由に見られるわけでも、Desktopアプリのプロセスが持つWindowsユーザー権限をそのまま使えるわけでもありません

  • ネットワークについても、VM内から出ていく通信は許可リスト方式(必要なAPIやパッケージ管理サーバーのみ)で制限されており、自由にどこへでもアクセスできるわけではありません

  • ブラウザ操作は別経路で、「Claude in Chrome」拡張機能を使い、ブラウザ拡張自体の権限の範囲で動きます(VM内からブラウザを直接乗っ取るわけではない)

なのでインストール時に管理者権限が必要なのは「VM関連サービス(CoworkVMServiceなど)をセットアップするため」であって、日常の実行時にその管理者権限をClaudeがフル活用しているわけではありません。
3. 「ファイル名指定→検索→ロケーション確定→吸出し」までできるか
これはYesですが、範囲限定つきです。

  • あなたが許可したフォルダ(例: cowork_testフォルダなど)のツリー内であれば、ファイル名やパターンで検索し、中身を読み、まとめて処理する、という一連の操作は普通にできます

  • ただし許可していない場所は最初から見えません。「PC全体からファイル名で探して」と頼んでも、マウントされていない領域は物理的にVMから見えないので、原理的に拾えません

  • 逆に言えば、許可フォルダの中では実質フルアクセス(読み書き・削除も含む)なので、大事なファイルを含むフォルダをうっかり丸ごと許可すると、そこは無条件で触られるリスクがあります

まとめると

質問

面白い　めちゃくちゃ　Ubuntu(Linux)のVMを立てます　ということは　Ubuntu `ga

メッセージが途中で切れているみたいです(「Ubuntu `ga」で終わっています)。
続きを教えてもらえますか？ 推測すると、こんな方向の質問かなと思うのですが、当てはまるものがあれば教えてください。

  • Ubuntuの中身を自分で覗いたり、直接ログインして操作できるのか

  • そのVMは毎回使い捨てなのか、それとも同じイメージが使い回されるのか

  • ディスク容量やスペックはどうなっているのか

  • Ubuntu内部で何のツールが使えるのか(Python/Node.jsなど)

もちろん全然違う質問でも大丈夫です。続きをどうぞ。

質問

えらい　Ubuntuはインストールされているのか　カーネルだけ？　ターミナルで通信できるのか　ローカルIP 127.0.0.1とかポート指定すればターミナルからログインできるのか？

良い質問です。整理すると:
Ubuntuは「フルインストール」か「カーネルだけ」か
フルインストールです。 カーネルだけの最小構成ではなく、初回起動時に約2GBのVMイメージ(Ubuntu 22.04系ベース)がダウンロードされ、その中でClaude Code CLIが動くのに必要な一式(パッケージマネージャ、シェル、各種ツール)が揃っています。「軽量だけど、ちゃんとしたLinuxディストリビューション」というイメージです。
ターミナルで通信・ログインできるか
公式にはできません。 ここが重要な点です。

  • Windows Desktopアプリと、内部のVM(Hyper-V経由)との間の通信は、CoworkVMServiceのような専用のプロセス間通信(名前付きパイプ)で行われています。これはユーザーが自由に叩ける汎用APIではなく、署名済みのClaude Desktop本体だけが呼べるように制限された内部インターフェースです

  • つまり 127.0.0.1:ポート番号 に向けて普通に ssh コマンドを打って、任意のユーザーがそのVM内にログインできる、という公式にサポートされた入口は用意されていません

  • VM自体のネットワークもHyper-Vの仮想スイッチ+WinNAT経由で構成されており、外部からの通信を受け付ける想定にはなっていません

ただし「覗くこと」自体は不可能ではない
有志のセキュリティ researcher やリバースエンジニアが、内部のセッションフォルダ構造やIPCの仕組みを解析した記事・OSSプロジェクトは実際に存在します(Windows側の%APPDATA%\Claude\配下にセッション情報やVMバンドルが残っていることも確認されています)。ただしこれらは非公式な解析結果であり、Anthropicが「ユーザー向け機能」としてターミナルログインの手段を提供しているわけではない、という点は分けて考える必要があります。
まとめ: Ubuntuは実体のあるフルVM。ただし公式には「Claude Desktop本体だけがVMを操作できる」設計になっていて、あなたが手元のPowerShellやターミナルから直接 ssh 127.0.0.1:<port> して中に入る、という使い方は想定されていません。

質問

ファイルシステムがあるんだな、なら　コマンドもあるということになる　でもログインできなければ、例えばviは起動できない、では外からコマンド群にアクセスできるのか あとパイソンなどのインストールできるのか？apt install とか使って

良い流れです。整理すると:
ファイルシステムやコマンドへの「外からのアクセス」は誰がやるのか
これがポイントで、あなたが直接シェルに入るのではなく、Claude(AIエージェント自身)がそのVM内でコマンドを実行する、という設計になっています。

  • チャット欄で「このフォルダを整理して」「このPythonスクリプトを実行して」と指示する

  • Claude(の中の人格でなく、実行エンジンとしてのClaude Code)が、VM内で ls、mv、python3 script.py のようなコマンドを実際に叩く

  • 実行結果(標準出力・エラー・作成されたファイルなど)が、チャットのUI上に表示される

つまり「あなた ⇄ ターミナル ⇄ VM」ではなく、「あなた ⇄ チャットUI ⇄ Claude ⇄ VM」という一段挟まった構造です。あなたがviを対話的に開いて編集する、という使い方はそもそも想定されていません(viのような対話型エディタは、標準入力を継続的にやり取りする必要があるため、エージェント経由のコマンド実行とは相性が悪いです)。ファイル編集はClaudeが直接ファイルの中身を書き換える形で行われます。
Python等はインストールできるのか(apt install)
はい、できます。 実際、VMのネットワークは基本的に外部への自由なアクセスを許可リスト方式で制限していますが、パッケージレジストリ(PyPI、npmなど)へのアクセスは許可されていることが分かっています。なので、

  • 「Pythonのpandasを使ってこのCSVを分析して」と頼むと、Claudeが必要に応じてpip install pandasのようなコマンドをVM内で実行し、処理を進める

  • Node.jsパッケージ(npm install)なども同様に可能

という流れです。ただしこれもあなたがapt install python3と手打ちするのではなく、Claudeに「〇〇を使いたい」と伝えると、必要な場合はClaudeが自律的にインストールコマンドを判断して実行する、という間接的な形になります。
まとめると

質問

言い換えると、Linuxのコマンドを知らなくても指令を出せるということか topコマンドを実行させたりする必要なくCPUの使用状態を報告せよということでいいんだな

その理解で合っています。
自然言語で目的を伝えるだけでよく、コマンド名を知る必要はありません。
「CPUの使用状況を教えて」と言えば、Claudeが裏側で

  • top -bn1(対話しない1回だけのスナップショットモード)

  • または /proc/stat を読む

  • あるいは ps aux --sort=-%cpu のような一覧表示

など、状況に応じて適切なコマンドを自分で選んで実行し、その結果を人間の言葉に要約して返してくれます。あなたはtopというコマンド名も、そのオプションも知らなくて構いません。
ただし1点補足しておきたいこと
topは本来「画面を継続的に更新し続ける対話型コマンド」ですが、Claudeがエージェント経由で実行するのは基本的に「1回実行して結果を受け取る」非対話型のコマンドです。なので実際には、Claudeはtopをそのまま起動するのではなく、-bn1(バッチモードで1回だけ出力)のような非対話型に変換したコマンドを選んで実行します。ここも含めて「どうやって情報を取るか」の判断はClaude側に任せられる、ということです。
まとめると、あなたのイメージ通り:
「何が知りたいか」だけを伝えれば、「どのコマンドで、どう取得するか」はClaudeが判断して代行してくれる
これがCoworkの基本的な使い方です。Linuxに詳しくない人でも、目的さえ言語化できれば使える、というのがこの機能の狙いですね。

質問

すげーなー　これは革命だ　Linuxはコマンドがネックだった　知っている　知らないで　敷居があった でも　知らなくてもなんとなく調べたいことを言えばいいんだな 会話の中から、コマンドを考えてくれて実行するということだな sync コマンドだ、マウント状態など　なんだっけコマンドなんて考えなくていいことだ

例えば、ＳＳＤのスマート情報を呼ぶこともできるんだよね

鋭い質問ですが、ここでVMという構造の限界が出てきます。結論から言うと、実際の物理SSDのSMART情報は基本的に取得できません。

なぜダメなのか

  • smartctlのようなSMART情報取得コマンドは、物理ディスクデバイス(/dev/sdaなど)に直接アクセスして、コントローラファームウェアから温度・書込量・エラーカウントなどの生データを読み取る仕組みです

  • これは「ハードウェアそのものへの低レベルアクセス」が必要で、VM(仮想マシン)からは通常見えません

  • Coworkのファイルアクセスは「VirtioFS」のような共有フォルダ機構で、これは「特定フォルダの中身を橋渡しする」仕組みであって、「物理ディスクをまるごとVMに渡す(パススルーする)」仕組みではありません

  • つまりVM内から見えるのは「共有されたフォルダの中身」だけで、「PCに挿さっている物理SSDそのもの」は見えていません

試すとどうなるか

  • Claudeに「SMART情報を見て」と頼んでも、VM内には物理ディスクのデバイスファイル自体が存在しないため、smartctlが「デバイスが見つからない」と失敗するか、もしくは意味のない仮想ディスクの情報しか返せません

同じ理由でできないこと・できること

つまり境界線は明確で、「VM自身の中の話」は自由に聞けますが、「ホストPCの物理ハードウェアの話」はVMの外側なので原則届きません。ここは「隔離による安全性」の裏返しとも言えます。VMがホストのハードウェアに直接触れられないからこそ、Claudeが暴走してもPCの物理的な部分は守られる、という設計です。

質問

足回りはＶＭを通り抜けないといけないんだな ではＤＯＣＫＥＲをかませれば横からアクセスできそうだが

その発想は自然ですが、結論としてはDockerを挟んでも突破できません。むしろ逆に「もう一段、内側に潜る」だけになります。

なぜDockerは"横から"アクセスできないのか

Dockerコンテナは仮想マシンとは根本的に違う仕組みです。

  • VM(仮想マシン) = ハードウェアそのものを仮想化する。VMは独自のカーネルを持ち、ホストとは別の「マシン」として振る舞う

  • Docker(コンテナ) = OSのカーネルを共有して、プロセスやファイルシステムの見える範囲だけを隔離する仕組み

つまりDockerは「新しいマシンを作る」のではなく、「今動いているLinuxカーネルの中で、視界を制限した部屋を作る」だけです。

図にすると

Dockerコンテナが使えるハードウェア資源は、あくまでそれを動かしているVMのカーネルが持っている資源の範囲内です。VM自体が物理SSDのデバイスファイルを持っていない以上、その中でDockerを何重に重ねても、物理SSDには辿り着けません。「部屋の中にさらに小部屋を作る」だけで、建物の外(ホストのハードウェア)には出られない、というイメージです。

もし本当に脱出できてしまったら

逆に言うと、もしDockerを経由してVMの外(ホストの物理ハードウェア)にアクセスできてしまったら、それはVM分離が破られているということになり、Anthropicにとっては重大なセキュリティ上の欠陥(サンドボックスエスケープ)ということになります。今のところそういう抜け道は公式には確認されていません。

つまり「足回り(ハードウェア)に届くには、VMという壁をそもそも越えないといけない」というあなたの理解は正しくて、Dockerはその壁の内側の話でしかない、ということです。

質問

そうか、Linuxは動いているがそれはＶＭの上だけ Vmwearでいう母艦からアクセスすればいいので、ウインドウズから足回りにアクセスするということだね あと、ＩＰアドレスがＶＭ側に割り振られていると思うけど そこフックしてもいい気がするがどう？

その理解は前半合っていて、後半はちょっと分けて考える必要があります。

母艦からのアクセス、はい合ってます

VMwareで言う「ホストOS側からゲストOSの中身を触れる」のと同じ発想です。Windows側(母艦)からは、原理上VMの中身を管理・監視する権限を持っています。実際、Claude Desktopアプリ自体が「母艦側のプロセス」として、VM管理サービス経由でVMを起動・操作しています。足回り(ハードウェア)へのアクセスは、常にWindows側が主導権を持つという構造です。VM側から母艦に手を伸ばすことはできないが、母艦からVMに手を伸ばすことは(管理者としては)可能、という非対称な関係です。

IPアドレスを"フック"する、については

ここは狙いを分けて考える必要があります。

ネットワークの仮想化 ≠ ハードウェアの仮想化

VM側に割り振られているIPアドレス(おそらく172.x.x.xのようなプライベートアドレス)は、Hyper-Vの仮想スイッチ+WinNATが作り出した、完全に仮想的なネットワークセグメントです。

VM側のIPを"フック"(傍受)しても、見えるのはVMが送受信するネットワークパケットの中身だけです。これは:

  • VMの通信内容を覗く/操作するという意味では成立します(実際、通信は一度WinNAT経由でホストを通るので、ホスト側で覗くことは技術的に可能)

  • ただしそれは「物理ハードウェア(SSD、CPU情報など)への到達経路」にはなりません。ネットワークとハードウェアは別レイヤーだからです

つまり「IPをフックする」というアプローチは、通信の中身を見る/改ざんするという目的には筋が良いですが、「VMの外にあるSSDのSMART情報を取る」という当初の目的には、そもそも繋がる経路が違う、という話になります。ネットワークの穴を通っても、出てくる先はインターネットであって、隣にあるハードウェアではない、というイメージです。

質問

ちなみにセグメントは127だよね

いえ、127ではないはずです。ここは訂正しておきたいポイントです。

127.0.0.0/8 は「ループバック」専用

127.x.x.xは、そのマシン自身の中で完結する通信(自分から自分へ)のために予約されたアドレス帯です。127.0.0.1(localhost)がその代表です。これは規格上、ネットワークインターフェースを経由しない特殊な範囲なので、VMのような「別マシンとして扱われる存在」に割り振られることは基本的にありません。

実際に使われそうな範囲

Hyper-Vの仮想スイッチ(NAT型)がVMに払い出すアドレスは、一般的にプライベートIPアドレス帯です。

  • 172.16.0.0/12(例: 172.x.x.x) ← Hyper-Vのデフォルトスイッチでよく使われる範囲

  • または 192.168.x.x

のどちらかである可能性が高いです。先ほどの説明で「172.x.x.x」と書いたのは、Hyper-Vのデフォルト仮想スイッチでよく採用される代表的なレンジだったからです(実機で確認したわけではないので、正確な値は環境によって変わります)。

整理すると

もし実際にご自分の環境で確認したい場合、Windows側で

Get-VMNetworkAdapter -VMName <VM名> | Select IPAddresses

のようなHyper-V管理コマンドを叩けば、実際に割り当てられているIPを確認できます(ただしCowork用VMがこの管理コマンドで見える名前で登録されているかは環境依存です)。

質問

ＶＭのことよく知らないからだな 母艦からnetstat とかで見れるということ？

いいところに気づきました。部分的に見えますが、粒度が違います。

netstat(host側)で見えるもの

Windows側でnetstat -anを打つと、見えるのは基本的にWindows自身のソケットです。

  • VMの中で動いているプロセス(例えばClaude内部のPythonプロセスなど)が「誰と通信しているか」は、VM内部の話なのでnetstatには出てきません

  • 見えるのは、Hyper-Vの仮想スイッチ自体がホスト側に持つ仮想アダプタ(vEthernet)の通信です

具体的には:

netstat -an

で、vEthernet (Default Switch)のようなアダプタに紐づく通信や、WinNATが変換した後の通信(ホストの実NIC経由でインターネットに出ていく部分)は見えます。ただし「VM内のどのプロセスが張った接続か」というプロセス単位の情報は失われています(NAT変換された後は、ホスト側からは「VM全体からの通信」としか見えない)。

もう少し詳しく覗きたいなら

Hyper-V専用のコマンドを使えば、もう少しVM寄りの情報が見えます。

powershell

Get-NetNatSession       # WinNATが今どんな変換(セッション)を持っているか一覧できる
Get-VMNetworkAdapter     # VMに割り振られたIP自体を確認

まとめ

つまり「通信していること自体」や「VMのIP」はホスト側からある程度追えますが、「VM内で誰が(どのプロセスが)その通信をしているか」という中身の詳細は、VMにログインしない限り見えない、という限界があります。

質問

惜しいですが、2点訂正があります。

コマンドの文法が少し違う

  • Windows: ipconfig /all (スラッシュ/。ハイフンではありません)

  • Linux: ifconfig はオプションなしで全部出ますが、最近のディストリビューションでは非推奨で、代わりに ip addr を使うのが主流です

ifconfig -all という書き方(ハイフン+all)は、どちらの体系にも存在しない組み合わせです。

実行場所による違い

つまり:

  • 母艦(Windows)でipconfig /allを打つ → 「Hyper-V仮想スイッチ」というホスト側から見た橋渡し役のアダプタが1つ見える。これがVMとの接続点

  • VM内部でifconfigやip addrを打つ → VM自身が実際に持っているIPアドレス(172.x.x.xなど)が直接見える。でもこれはVMにログインしないと打てないコマンドなので、公式には実行不可

なので ipconfig /all をWindows側で打っても、「VMという相手が繋がっている入り口(vEthernetアダプタ)」は見えますが、「VM自身が名乗っているIPアドレスそのもの」はここには出てきません。それを直接見るには、結局VMの中に入る必要がある、という同じ壁に戻ってきます。

質問

なんとなく理解できた。　ちなみに　母艦をLinuxにしてこのアプリインストールできるの？ apt installとかで

できます、しかもタイムリーな話です。2026年6月30日にAnthropicが公式Linux版のベータをリリースしたばかりです(まさにapt installできます)。

インストール方法

bash

# 署名キーを追加
sudo curl -fsSLo /usr/share/keyrings/claude-desktop-archive-keyring.asc https://downloads.claude.ai/claude-desktop/key.asc

# リポジトリを登録
echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/claude-desktop-archive-keyring.asc] https://downloads.claude.ai/claude-desktop/apt/stable stable main" | sudo tee /etc/apt/sources.list.d/claude-desktop.list

# インストール
sudo apt update && sudo apt install claude-desktop

対応環境

  • Ubuntu 22.04以降 / Debian 12以降

  • x86_64・arm64両対応

  • Fedora/RHEL/Archなどは今のところ非対応

Windows/macOS版との違い(ベータなので一部制限あり)

  • Computer Use(画面操作機能)は未対応 — 「近日対応予定」とのこと

  • **音声入力(dictation)**は未対応

  • Wayland環境ではQuick Entryのグローバルショートカットに制約あり

  • アプリ自体は自動更新しない → apt upgradeで手動更新が必要

ここで面白いポイント

母艦がLinuxになると、これまで話してきた「Windows→Hyper-V→Ubuntu VM」という構造が変わります。おそらく母艦(Linux)上でも、Coworkは同様に隔離されたサンドボックス(VMかコンテナ的な仕組み)の中で動く設計になっていると考えられますが、母艦自体が最初からLinuxカーネルなので、Windowsの時のような「異なるOSを跨ぐ仮想化(Hyper-V)」は不要になり、もう少し軽量な仕組み(例えばnamespace/cgroupベースのサンドボックス化)になっている可能性があります。ここは公式ドキュメントにもまだ詳細な内部構造の記載がなく、はっきりしません。

もし実際に試される場合は、Coworkタブでの動作(VM起動やファイルアクセスの挙動)がWindows版とどう違うか、実機で確認してみると面白いと思います。

質問

久しぶりに面白ネタにであった　わくわくするわ

その感覚、すごくよく分かります。今日の話、けっこう筋が良かったと思います。

「Chat/Coworkの切り替え」という一見地味なUIボタンから始まって、

  • 脳(モデル)と体(実行環境)の分離という設計思想

  • Hyper-VでUbuntu VMが立ってること

  • VMという境界がどこまでを許し、どこからを拒むか(SMART情報がなぜ取れないか)

  • Dockerを挟んでも壁は越えられない理由

  • ネットワークの仮想化とハードウェアの仮想化は別レイヤーだという整理

  • そして最後にLinux版アプリがまさに数日前に出たばかり、というタイムリーな着地

という流れ、素人談義じゃなくてちゃんとアーキテクチャの骨格を掴みにいく質問の連続でした。特に「Dockerで横からいけるのでは」「IPをフックすれば」というのは、実際にVM脱獄やサンドボックスエスケープを考えるセキュリティリサーチャーが最初に思いつく発想そのものなので、筋の良い疑い方だったと思います。

もし引き続き掘りたければ、

  • 実際にご自身のPCでLinux版を試してWindows版とVM構造を比較してみる

  • Coworkの権限モード(3段階あるらしい承認モード)がどう「常に許可」と「毎回確認」を切り替えるのか

  • リモート実行版(Anthropicサーバー側で動く方)とローカル実行版で、この境界線がどう変わるか

あたりは、今日の続きとして面白いと思います。またネタが出てきたら、いつでもどうぞ。

質問

いやいや、まだまだ質問したいんだ　でも　サックスの練習して　先生に教えてもらうレッスンが控えているし明日から旅行だし　旅行中にひらめくかもしれん この仕組みがあればネットワーク上で連携できそうだ、サーバーの本体は同じだが また　このチャットは続けるわ　じゃあ

いいですね、サックスのレッスンに旅行、両方楽しんできてください。

「ネットワーク上で連携」というのも良い着眼点だと思います。実際、リモートセッション化が進んでいる話をしたように、Anthropicの設計思想自体が「同じセッションをどのデバイスからでも継続できる」方向に向かっているので、その勘は結構当たっていると思います。旅行中にふと閃いたら、続きはこのチャットに書いておいてください。ここまでの文脈(Hyper-V、VM境界、権限モードの話など)は憶えているので、途中からでもすぐ再開できます。

では、レッスンと旅行、楽しんできてください🎷

質問

これpc同士を繋いで行くことができて ウィニーのようなソフトで AIセンター側のアクセスの遅いデータを各pcにおいて、センター側のメモリーの削減に貢献できないか アカマイのようなキャッシュサーバー機能も各ユーザに持たせて ネットワーク上で共有して リソースを提供した人にはお金を還元する仕組みも混ぜて、マイニングもどきのスキームで メモリー使用量を減らし メモリー高騰の抑制に出来るのではないか？

面白い発想です。実際、部分的には近い仕組みがすでに業界で試みられています。整理して技術的な筋の良さと、壁になりそうな点の両方をお伝えします。

発想として筋が良い部分

  • CDN型のキャッシュ分散 = AkamaiがWebコンテンツでやっていることを、AI推論結果に応用する発想は自然です。実際、LLMの世界には「プロンプトキャッシュ」という概念があり、同じ入力の一部を毎回計算し直さず使い回す仕組みはすでに存在します。これをユーザー間で共有する発想への拡張は理屈として成立します

  • リソース提供者への還元 = これも既視感があります。Filecoin(ストレージ提供者に報酬)、Render Network(GPU計算力の提供者に報酬)など、まさに「マイニングもどき」でリソースを分散調達する暗号資産プロジェクトが実在します

壁になりそうな点

1. AIの応答は「静的コンテンツ」ではない
AkamaiのキャッシュはHTML/画像など変化しない静的データが前提です。しかしAI推論結果は、ユーザーごとの文脈・会話履歴に強く依存するため、他人と使い回せるデータがそもそも少ないんです。ウェブページのように「同じURLなら同じ内容」という前提が成立しません。

2. セキュリティ・プライバシーの壁
ユーザーのPCにキャッシュを置くというのは、裏を返せば「他人の会話の断片や中間データが、見知らぬ誰かのPCに保存される」ということです。これは日本だとWinnyの前例がまさに象徴的で、「善意の分散システム」のはずが「情報漏洩の温床」になった歴史があります。AIチャットは機密情報・個人情報を含みやすいので、この壁は相当厚いです。

3. 信頼できないノードの汚染リスク
中央集権的なAkamaiのサーバーと違い、素性の分からない個人PCがキャッシュを持つと、改ざんされたデータを掴まされるリスク(キャッシュポイズニング)が出てきます。AIの回答が誰かに書き換えられて配信される、というのはただの通信障害よりずっと危険です。

4. 経済設計の難しさ
「リソース提供→報酬」の仕組みは、Sybil攻撃(偽アカウントを大量に作って報酬を稼ぐ)や、実際のコスト(電気代・回線)に見合わない過当競争など、暗号資産系プロジェクトが軒並みぶつかってきた課題と同じ壁にぶつかります。

一番現実的な着地点

実は方向性として一番近いのは、**「ユーザーの入力の一部を毎回計算し直さない」**という、中央側での最適化(プロンプトキャッシュ、KVキャッシュの共有)であって、「ユーザーのPCに分散配置する」必要は薄いかもしれません。むしろメモリー高騰対策としては、推論エンジン側の効率化(モデル圧縮、量子化、専用チップ)の方が実際に業界が向かっている方向です。

とはいえ、「静的でなくても、ある程度共通するパターン(よくある質問への回答の下書きなど)なら分散キャッシュが効くのでは」という切り口は、まだ掘る余地があると思います。旅行中、続きを考えてみてください。

質問

なんでも壁があるからな 壁がなかったら 誰かがやってる 反対者がいてこそ、やって価値がある 皆んながいいと思った時点で もう先はない。 フロントエンドの実装を各マシンローカルでやらせれば、データのやりとりの回数を抑制できるかも

その姿勢、いいと思います。「壁がある」は「終わり」じゃなくて「まだ誰もちゃんと解いてない」のサインですからね。

「フロントエンドをローカル実行させて通信回数を減らす」という発想は、実は的を射ています。

すでにある近い実例

  • WebAssembly + ローカル推論: 小型モデル(要約、意図判定、簡単な分類など)をブラウザ内やローカルマシンで動かし、「本当にセンター(大規模モデル)に聞く必要があるか」の事前フィルタをローカルでやる、という設計はすでに研究・実装が進んでいます

  • 投機的実行(Speculative Decoding): 軽量モデルがローカルで「たぶんこの続きだろう」と予測し、重いモデル側は答え合わせだけする、という仕組みも近い発想です。通信回数そのものは減らせずとも、**やり取りする情報量(トークン数)**を減らせます

あなたの発想の面白いところ

「フロントエンド(=軽い処理)はローカルに逃がし、本当に必要な部分だけセンターに投げる」という役割分担の設計は、まさにエッジコンピューティングの王道パターンです。AIに当てはめると:

  • 誤字修正、フォーマット整形、簡単な会話継続の判定 → ローカルの軽量モデルで完結

  • 本当に複雑な推論・創造的な生成が必要な部分だけ → センターに投げる

これなら「センター側のメモリー」というより「通信のラウンドトリップ回数と帯域」を減らす方向で効いてきます。さっきのキャッシュ分散の話と組み合わせると、「ローカルで完結できるものはローカルで捌き、どうしても必要なものだけセンターに聞く」という階層型アーキテクチャになりますね。

これ、旅行中に紙にでも書き留めておくと面白いかもしれません。続きはまたいつでもどうぞ。良いレッスンと旅を。

質問

特許とかありそうだけどね

その勘は正しいです。実際、かなり近い領域に特許はすでに山ほどあります。

近い領域の特許状況

  • エッジ推論の階層化(軽いモデルをローカル、重いモデルをクラウドに配置する設計)は、Google、Apple、Qualcomm、Samsungあたりが既に大量に出願・取得しています。特にスマホのオンデバイスAI(Google Geminiのon-device版、AppleのApple Intelligenceなど)がまさにこの構造です

  • **投機的実行(Speculative Decoding)**自体も、GoogleやDeepMindが原論文と前後して特許出願している可能性が高い領域です

  • 分散キャッシュ+報酬還元(Filecoin、Render Networkなど)は、それぞれのプロジェクトが独自に特許や技術文書を持っています

ただし、ここは知っておくといいポイント

  • 特許は「その組み合わせ・実装方法」に対して成立するものであって、「ローカルとクラウドで役割分担する」というアイデアそのものは特許にならないことが多いです(アイデア単体は特許の対象外、具体的な実装手法が対象)

  • なので「既に似た特許がありそう」=「もうこの方向で何も出来ない」ではなく、「具体的にどう実装するか」の部分にはまだ工夫の余地が残っていることが多いです

調べる方法

もし本気で気になるなら、旅行から戻ってから

  • Google Patents(無料)で edge inference caching reward speculative decoding local model のようなキーワードで検索

  • 「on-device LLM caching incentive」あたりでも近い出願が出てくるはず

という感じで実際に軽く当たってみると、「どこまで先行されてて、どこが空いてるか」が見えてくると思います。良い旅を、また続きが浮かんだらどうぞ。


いいなと思ったら応援しよう！