ニュース
Windows版「Claude Cowork」の動作環境をチェックする
VMはどこ？ Linuxのバージョンは？ ネットワークアクセスは可能？
2026年4月9日 10:45
話題の「Claude Cowork」は、どのような環境でPCを制御しているのか？ ログファイルやチャットの動作履歴、実際の仮想環境の中身をチェックすると、こうした状況がある程度推測できる。PCの操作を生成AIにまかせるのであれば、何が、どう動いているのかを把握しておきたい。
Windows版登場、Dispatchでのチャット指示も可能に
PCの自動操作が可能ということで、大きな話題になったAnthropicの「Claude Cowork」。有料プランの契約が必要なため、誰でも手軽に使えるわけではないが、自律的にタスクを処理するAIエージェントの身近な活用例として注目を集めている。
2026年1月の登場当初はmacOSのみの対応となっていたが、2026年2月にはWindows版のリリース、OpenClawのようにスマホのチャットアプリから遠隔で指示が出せる「Dispatch」もリリースされ、現在も進化を続けている。
残念ながら、現状のWindows版にはマウスやキーボードを操作してPC上のアプリを操作する「Computer Use」機能が搭載されておらず（サードパーティのWindows-MCPを追加すれば可能だが実装がかなり面倒）、以下の機能のみが提要される。
・ローカルファイルへの直接アクセス Claudeは手動アップロードやダウンロードなしにローカルファイルの読み取りと書き込みができます。
・サブエージェント調整
Claudeは複雑な作業をより小さなタスクに分割し、並列ワークストリームを調整して完了させます。
・プロフェッショナルな出力
動作する数式を含むExcelスプレッドシート、PowerPointプレゼンテーション、フォーマットされたドキュメントなどの洗練された成果物を生成します。
・長時間実行タスク
会話タイムアウトやコンテキスト制限があなたの進捗を中断することなく、長期間複雑なタスクに取り組みます。
・スケジュール済みタスク
Claudeがオンデマンドで実行したり、選択した頻度で自動的に実行したりできるタスクを作成して保存します。
・スプレッドシートとプレゼンテーション
Coworkはスプレッドシートとスライドを生成でき、Claude for ExcelおよびPowerpointでさらに編集できます。
具体的にどのようなシーンで役立つのかというと、例えば以下のようなものが考えられる。
・ダウンロードした大量の請求書から自動的に中身を判断して請求日や請求先に応じてフォルダーに分類する
・競合製品比較など、複数のWebページの情報を取得し、情報をまとめて指定したフォルダーにExcelファイルで保存する
・「未処理」フォルダーに保存されたPDFファイルの内容を社内のWeb申請アプリに自動入力して「処理済み」フォルダーに移動する
・フォルダーに保存された業務委託契約書や秘密保持契約書などの内容を専門的な観点でチェックし、注意すべき点をExcelファイルにまとめる
・毎朝、業務に必要な指標を社内ポータルやWebページから取得し、Gmailの下書きに保存する
上記のうち、「複数のWebページの情報を取得する」はClaude用語で「ツール」に分類されるAnthropicが用意したAPIを利用する機能、「社内のWeb申請アプリに自動入力する」は「スキル」に分類される「Claude in Chrome」という拡張機能によるブラウザ操作機能、「Gmailの下書きに保存する」は「コネクタ」と呼ばれる外部サービス連携機能、「専門的な観点でチェック」は「プラグイン」と呼ばれるコネクターやスキルを組み合わせて専門分野に特化させた機能なのだが、Claude Coworkは、このようにClaudeのツールやスキル、コネクター、プラグインなどの機能に加え、ローカルを操作するためのしくみを併用できるのが特徴だ。
どうやってローカルフォルダーにアクセスしているのか？
ということで、筆者も実際にインストールして使ってみたのだが、気になったのは、Coworkがどのような環境で動作しているのか？ という点だ。
ローカルのファイルを操作できることを考えると、なんらかの方法でCoworkがPCのファイルシステムにアクセスしているわけだが、そのしくみや環境をユーザー自身が知らぬまま使うのは気持ちが悪い。
上で掲示したサポートページには「Coworkはコンピュータ上の仮想マシン（VM）で実行されます。これにより、いくつかのセキュリティ上の利点が得られます」と記載されているので、仮想マシンを利用していることは明らかだが、これがどのように動いていのかが気になるところだ。
ということで、ログや設定ファイルなど、わかる範囲でCoworkの動作環境を確認してみたが、結構、いろいろなことがわかった。
ログファイルを確認する
まず確認したのはCoworkのログファイルだ。ログファイルの場所はインストール方法（MSIXパッケージかEXE）によって違うのだが、筆者の環境（おそらくこちらが一般的）では、以下のフォルダーに保存されていた。
C:\Users\（ユーザー名）\AppData\Local\Packages\Claude_[個別の
識別子]\LocalCache\Roaming\Claude\logs
フォルダーには、複数のログファイルがあるが、手がかりになるのは、「cowork_vm_node.log」「coworkd.log」「coworkd-user-[ID].log」「cowork-service.log」などになる。
面倒なら、これらすべてClaudeに登録して解析をお願いしてもいいが、ざっと見ただけでもCoworkがVM（仮想マシン）で動作し、「Claude\vm_bundles\claudevm.bundle」のVHDXファイルを使っていること、「HVSock」（Hyper-V Socket：Hyper-Vで動作するホストOSと仮想マシン（VM）、またはVM同士が、ネットワークを使わずに直接通信するための仮想通信機能）で通信していることがわかった。
仮想マシンを確認してみる
次に、実際に動作している仮想マシンを確認してみることにした。Claude Coworkの仮想マシンは、WSL（Windows Subsystem for Linux）に似た環境で、Windowsの「仮想マシンプラットフォーム（仮想マシンを動かすためのコア機能だけを提供するWindows機能）」を利用している。
ということで、以下のように「hcsdiag list」や「Get-Process vmwp -ErrorAction SilentlyContinue」コマンドを使うと、現在稼働中の仮想マシンを確認できる。
ただ、リアルタイムにログを表示（Get-Content C:\Users\ユーザー名\AppData\Local\Packages\Claude_識別子\LocalCache\Roaming\Claude\logs\cowork_vm_node.log -Wait -Tail 20）しながら確認するとわかるのだが、これは常に起動しているわけではなく、Claude Desktopアプリを起動して「Cowork」タブをクリックしてはじめて起動するしくみになっている。
また、この仮想マシンのネットワークだが以下のようになっていた。途中に「Default Switch」とあるが、筆者宅の環境ではHype-Vを運用中の環境だったため、Hyper-Vの仮想スイッチ（NAT構成）が自動的に適用されている。Hyper-Vがない環境であれば、Claude用の接続が自動的に作成されるはずだ。
「coworkd.log」を見ると、ネットワークに「172.16.10.3」（Hyper-VのNATスイッチの標準値）が割り当てられ、ポート番号として1024と51234が見える。ホストとVMの通信はHVSock（VM側はAF_VSOCK）だが、VMからのネットワーク通信をホストに転送する際に、ポート1024（おそらく外部接続用）と51234（おそらく制御用）を使っていると推測できる。
VHDXファイルで仮想マシンを起動してみる
次に、実際に利用されている仮想マシンの中身を確認する。仮想マシンのVMはログから以下にあることがわかっているので、これを開いて確認する。
C:\Users\ユーザー名\AppData\Local\Packages\Claude_識別子\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle
フォルダーには、「rootfs.vhdx」「smol-bin.vhdx」「sessiondata.vhdx」の3つのファイルがある。「coworkd.log」を見ると、「smol-bin.vhdx」が「sdb1」、「sessiondata.vhdx」が「sdc」に割り当てられているので、3つの仮想ディスクをまとめて使っていることがわかる。また、rootfs.vhdxはCoworkの最初のタイミングでクラウド上からダウンロードされていることもわかる。
一応、力業で、これらのVHDXをHyper-Vに割り当てて仮想マシンを起動してみたが、無事に起動することを確認できた。ただし、起動してもユーザー名やパスワードはわからないのでログインすることはできない。これでわかるのは、OSが「Ubuntu 22.04.5 LTS」であること、ホスト名が「claude」であることだ。
VHDXの中身を見てみる
せっかくなので、それぞれのVHDXファイルの中身も見てみた。EXT4なのでWindowsにマウントしても見えないので、今回は7-Zipを使って中身を参照することにした。
rootfs.vhdx
これは、Ubuntuの本体が保存されているファイルとなる。/bootでカーネルを確認すると「vmlinuz-6.8.0-94-generic」となっていた。また、ユーザー情報ファイルなども覗いてみたが、どうやらubuntuユーザーは使えるように見えた。
smol-bin.vhdx
こちらは、どうやらCoworkのプログラム一式が収められているようだ。他の設定なども合わて確認すると、このディスクがUbuntuの「/smol/bin」にマウントされるようで、VHDX形式でCoworkの実行ファイルを配布（アップデートなどで更新し）、仮想マシンで利用するという流れに見える。
興味深いのは、「srt-settings.json」だ。ここには、アクセス許可の設定が記述されている。ネットワークの通信が許可されるドメインとして内部動作に必要なモジュール（API通信、パッケージやソースコード取得先）のサイトがホワイトリストとして記述されている。これにより、仮想マシン内に後からモジュールを追加して実行することが容易になっていることがわかる。
逆に言うと、これらのドメイン以外へのアクセスは禁止されるため、仮想マシン内から外部サイトへのアクセスはできないことになる。
また、Anthropic関連のドメインに対してはMITMプロキシ（中間で通信を解析・書き換えるプロキシ）を利用する設定になっており、通信チェックやデバッグなどに使われているのではないかと思われる。
一方、ファイルシステムに対しては「/」なので広い書き込み権限が与えられている。VM自体をサンドボックスとして捉えて広く権限を与えていると考えられる。
sessiondata.vhdx
これは、ユーザーセッションが保存されている。Ubuntu上では「sessions」にマウントされ、タスクごとに「trusting-optimistic-ramanujan（最後は科学者名）」のようなフォルダーが割り当てられている。
Ubuntuのユーザー設定ファイルにも同じ名前のユーザーが登録されていたので、Cowrokの処理を実行する際に、タスクごとにユーザーを作成し、そのユーザー権限で各種処理を仮想マシン内で実行していると考えられる。
ローカルフォルダーはどうマウントされるのか？
PCのローカルフォルダーが仮想マシンにどうマウントされるのかは、途中まで確認することができた。
「coworkd.log」ログを見ると、「mounting Plan9 share via vsock port 9999」とあるので、Plan9プロトコルを使ってホスト側のフォルダー（PCのローカルフォルダー）を仮想マシンにマウントしている。
Plan9は、ベル研究所で誕生したすべてのリソースをファイルとして扱う分散OSで、現在は仮想マシンとホストのファイル転送のしくみとして使われているプロトコルとなる。WindowsのWSLでも利用されている。
ログにはさらに「Plan9 share mounted at /mnt/.virtiofs-root/shared」とあるので、Plan9によって、ローカルのフォルダー（Claude Coworkでプロジェクトとして指定した作業フォルダー）が、仮想マシンの「/mnt/.virtiofs-root/shared」にマウントされるまではわかった。
ただし、前述したようにユーザーのセッションは「/sessions」で永続化されているので、内部の処理で、さらにユーザーのホームやsessionsあたりにリンクされているのではないかと想像できる。
全体の構造を整理する
ということで、現状（2026年3月31日時点）でのWindows版Claude Coworkの全体像をログや設定ファイルからわかる範囲で整理すると、以下のようになる。
こうしたしくみによって、「OSと基本プログラム」「実行プログラムの更新部分」「永続データ」をそれぞれ分離しつつ、ネットワークアクセスできる宛先も限定したサンドボックス環境となっていることがわかる。
普通に使うにはまったく意識する必要はないが、知った上で使うと、Coworkがローカルフォルダーのファイルを操作できることに、違和感を覚えることなく活用できるだろう。