Claude Desktop MSIXをWindowsへ一括導入する手順
Claude Desktop WindowsのMSIXは、Team・Enterprise管理者が一括導入に使うパッケージです。個別インストールとの違い、自動更新、Cowork向けVM機能の有効化、トラブル対処を扱います。
Claude DesktopのMSIXは、Windows端末へ一括配布するための管理者向けパッケージです。Team・Enterpriseプランで一括導入するときは、.exeのユーザー向けインストーラーではなくMSIXを使います。Microsoft Intune・SCCM・Group Policy・PowerShellのいずれかでサイレント配布でき、ユーザー操作は要りません。個人でのインストール手順はClaude Desktop Windows版のインストールと初期設定にあります。ここでは、管理者が複数の端末へまとめて配る場面を扱います。
つまずきの大半は、MSIXが「ユーザー単位のアプリ」として作られていることから来ます。以下は、その性質を前提に、配る前に決めること、配ったあとに起きる症状の順で進めます。
Claude DesktopのMSIXとは(.msiとの関係)
MSIXは、Windowsアプリを1つのパッケージにまとめる形式です。Claude Desktopの管理者向け手順が案内しているのはこのMSIXで、.msiは案内されていません。ファイル名はClaude.msixの形で、x64版とarm64版があります。
Claude DesktopのMSIXは、ユーザー単位のアプリとしてパッケージされています。この性質が、後の節で扱うコマンド選びとIntuneの失敗につながります。
個人向けインストーラーと何が違うのか
.exeインストーラーはユーザーが自分で実行する前提です。Coworkを含むフル機能には管理者権限が必要で、実行するとWindowsのUACプロンプトが出ます。管理者権限のないユーザーでもインストールはできますが、デスクトップ版のCoworkは使えません。
MSIXをエンドポイント管理ツールへ直接渡せば、ユーザー操作なしのサイレント展開になります。配布経路は5つあります。
- Microsoft Intune
- Microsoft Endpoint Configuration Manager(SCCM)
- Group Policy Software Installation
- DISM.exe(Deployment Image Servicing and Management)
- PowerShellスクリプト
何台に・誰向けに配るかでコマンドを選ぶ
ユーザー単位のアプリなので、登録の範囲を決める2つのコマンドのどちらを使うかが、導入の成否を左右します。
2つのインストールコマンド
Add-AppxPackage
実行した現在のユーザーにだけ登録します。ほかのユーザーのプロファイルには入りません。
Add-AppxPackage -Path "Claude.msix"Add-AppxProvisionedPackage
マシン全体にステージングし、そのデバイスの全ユーザーが使えます。管理者権限を持たない標準ユーザーも対象です。
Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" -SkipLicense -Regions "all"端末を共有する運用や、標準ユーザーの端末へ配る運用では、後者が基本になります。
標準ユーザーでIntuneのLOB配布が失敗する理由
MSIXをIntuneへLOB(ライン・オブ・ビジネス)アプリとしてアップロードすると、マシン全体ではなくユーザーコンテキストでインストールされます。管理者権限のない標準ユーザーでは、このインストールが完了しません。IntuneのLOB配布はAdd-AppxProvisionedPackageを代わりに実行できないためです。
マシン全体に配るには、Add-AppxProvisionedPackageを使う経路を別に用意します。次の3通りがあります。
- ユーザーがサインインする前に、対象端末へパッケージを事前ステージングする
- Win32アプリとして包み、そのインストールコマンドで
Add-AppxProvisionedPackageを呼ぶ - PowerShellスクリプトのラッパーでコマンドを配る
Coworkを使う端末はVirtual Machine Platformを先に有効化する
Claude Desktop WindowsでCoworkを使うには、Windowsの「Virtual Machine Platform」が必要です。多くのエンドポイント管理製品はこの機能の有効化を自動化できます。手動で有効化するコマンドは次のとおりです。
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart-NoRestartは自動再起動を止めるフラグで、サイレント展開向けです。機能が有効になるのはマシンの再起動後なので、再起動は管理ツール側でスケジュールします。
配布前に、パイロット端末で現状を見ておくと、あとの切り分けが楽になります。次は公式の確認項目を筆者が1つのブロックにまとめた例で、管理者権限のPowerShellで実行します。3行目は、公式のbcdedit確認をfindstrで絞ったものです。
Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Get-Service vmcompute, hns
bcdedit | findstr hypervisorlaunchtype機能が無効だったり、サービスが見つからなかったりする端末では、Coworkは起動しません。hypervisorlaunchtypeはVMwareやVirtualBoxを併用する端末で見る項目で、Autoであることが目安です。
自動更新の主導権をMDMとアプリのどちらに置くか
Claude Desktopは既定で約4時間ごとに更新を確認し、MDMが割り当てたバージョンとは無関係に自動で適用します。アプリ内アップデーターとMDMがぶつかるのを避けるため、展開前にどちらかを選びます。
更新の持ち主を1つに決める
案1
disableAutoUpdatesを1にして、新しいMSIXビルドはMDMの計画どおりに配ります。バージョンを固定したい組織向けです。
案2
disableAutoUpdatesは未設定のままにします。Win32で包んだAdd-AppxProvisionedPackageを1回だけ実行し、あとはアプリの自己更新に任せます。
案2では、MDMの「インストール済み」判定が自己更新で崩れないようにします。Get-AppxPackage -Name Claudeが展開したバージョン以上かどうかを見る、カスタム検出スクリプトを使います。次は考え方を示す例です。公式が載せているのは判定の方針だけで、このスクリプト自体は公式の配布物ではありません。
$min = [version]"0.0.0.0" # 展開したMSIXのバージョンに置き換える
$pkg = Get-AppxPackage -Name Claude -AllUsers | # -AllUsers は管理者権限が前提
Sort-Object { [version]$_.Version } -Descending | Select-Object -First 1
if ($pkg -and ([version]$pkg.Version -ge $min)) {
Write-Output "Claude $($pkg.Version)"; exit 0
}
exit 1どちらも選ばないと、アプリ内アップデーターとMDMの両方がパッケージを登録することがあります。Claudeのパッケージファミリーに重複エントリーができ、後述の「パラメーターが正しくありません」につながります。
管理設定はレジストリのポリシーキーで配る
Claude Desktopの管理設定は、Windowsではレジストリで配ります。マシン全体(HKLM)とユーザー単位(HKCU)のどちらにも置け、両方に値があるとマシン単位が優先されます。配布手段はGroup PolicyかIntuneのポリシーです。公式の例は、マシン全体の設定として推奨されているHKLM:\SOFTWARE\Policies\ClaudeにDWORD値を書く形です。
New-Item -Path "HKLM:\SOFTWARE\Policies\Claude" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "disableAutoUpdates" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "autoUpdaterEnforcementHours" -Value 72 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "isDesktopExtensionEnabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "isDesktopExtensionDirectoryEnabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "isLocalDevMcpEnabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "isClaudeCodeForDesktopEnabled" -Value 1 -Type DWordこの例のdisableAutoUpdatesは0で、既定と同じ自己更新のままです。更新の案1を採るなら1に変えます。値の一覧は次のとおりです。
| キー | 型 / 既定値 | 用途 |
|---|---|---|
disableAutoUpdates | 型 / 既定値Boolean / false | 用途自動更新の無効化。案1で使う |
autoUpdaterEnforcementHours | 型 / 既定値整数(1〜72)/ 72 | 用途更新を用意してから強制再起動で適用するまでの時間 |
isClaudeCodeForDesktopEnabled | 型 / 既定値Boolean / true | 用途Desktop内のClaude Codeへのアクセス |
secureVmFeaturesEnabled | 型 / 既定値Boolean / true | 用途Desktop内のCoworkへのアクセス |
isDesktopExtensionEnabled | 型 / 既定値Boolean / true | 用途拡張機能そのもの |
isDesktopExtensionDirectoryEnabled | 型 / 既定値Boolean / true | 用途拡張機能ディレクトリへのアクセス |
isLocalDevMcpEnabled | 型 / 既定値Boolean / true | 用途ローカルMCPサーバー |
effortLevel | 型 / 既定値文字列 / null | 用途Claude Codeセッションの既定のeffort level |
forceLoginOrgUUID | 型 / 既定値文字列 / 配列 / null | 用途ログインできる組織の限定 |
allowedWorkspaceFolders | 型 / 既定値文字列の配列(JSON)/ 無制限 | 用途Coworkへマウントできるフォルダー |
読み違えやすい点が3つあります。effortLevelはlow・medium・high・xhigh・maxのいずれかで、Claude Desktop 1.25927.0以降が対象です。セッションの開始ごとに管理値が適用され、ユーザーがピッカーで変えた値は次のセッションで上書きされます。Coworkのセッションには効きません。
forceLoginOrgUUIDは、UUIDを1つ書くとログイン時にその組織が事前選択されます。配列で複数書くと、どれに属していても通りますが、事前選択はされません。所属していない組織のアカウントではログインに失敗します。
拡張機能まわりでは、ユーザー端末側のポリシーがアプリ内の許可リストより優先されます。許可リストを使うなら、isDesktopExtensionEnabledとisDesktopExtensionDirectoryEnabledをfalseにしてはいけません。許可リストが利用可能な拡張機能の一覧(registry)を埋められるようにするためです。許可リストの運用はClaude Desktop拡張機能の許可リストを有効にする手順で扱っています。
配ったあとに起きる症状から原因を引く
一括導入で出る症状は、個別インストールでは見かけないものです。公式のトラブルシューティングに載っている4つを、見える症状から引けるように並べます。
MSIXがAppLockerにブロックされる
AppLockerの既定ポリシーは、パッケージアプリを制限することがあります。AppLockerのルールがMSIXパッケージを許可しているかを確かめるか、Claude Desktopを許可アプリの一覧に加えます。変更の前に、組織のセキュリティポリシーを確認します。
「パラメーターが正しくありません」と表示される
多くの場合、アプリ内アップデーターとMDMの両方がパッケージを登録し、Claudeのパッケージファミリーに重複エントリーが残っています。更新の案1か案2のどちらかに、主導権を一本化します。
標準ユーザーでインストールに失敗する、またはCoworkが起動しない
2つの症状は同じ原因から出ています。MSIXがマシン全体ではなく、ユーザーコンテキストで入っています。標準ユーザーでの失敗はIntune LOBの仕様どおりです。一方のCoworkは、ユーザー単位のAdd-AppxPackageでは仮想化サービスが登録されないことがあり、見かけ上はインストールできていても起動しません。Win32アプリ・PowerShellラッパー・事前ステージングのいずれかで、Add-AppxProvisionedPackageを実行し直します。
Coworkが「Missing HCS services」で起動しない
エラーは「Missing HCS services: HNS, vmcompute, vfpext」のような形で出ます。Claude自体は入っていても、Virtual Machine Platformのサービス群が登録されていない状態です。個人インストールの利用者が同じ原因で「Virtualization is not enabled」を見たときは、個別ユーザー向けの原因の切り分けと対処法が参考になります。診断は次の順に進めます。
HCSエラーの診断手順
- 1
機能とサービスを確認する
前述の
Get-WindowsOptionalFeatureとGet-Service vmcompute, hnsを実行します。 - 2
無効なら有効化し直す
機能が無効か、サービスが見つからないときは、有効化コマンドを実行し直します。
-NoRestartは付けません。 - 3
「再起動」で再起動する
シャットダウンして電源を入れ直す操作は避けます。高速スタートアップが有効だと、シャットダウンのサイクルで仮想化サービスが初期化されないまま残ることがあります。
- 4
ハイパーバイザーの起動設定を見る
VMwareやVirtualBoxが同居する端末では、管理者権限のプロンプトで
bcdeditを実行し、hypervisorlaunchtypeがAutoか見ます。違えばbcdedit /set hypervisorlaunchtype autoを実行して再起動します。
ここまでを踏んでも動かない端末が残るなら、ネスト仮想化のない仮想マシンやVDI環境かもしれません。そうした環境はサポート対象外で、Coworkは動きません。一括導入の対象にVDIが含まれる場合は、あらかじめ除外しておくと切り分けの手間が減ります。
どのチェックに失敗しているかは、ログで分かります。Claude Desktopの「Help」→「Troubleshooting」→「Show Logs」からsupported-features-info.jsonを開きます。
更新のあとに「Another program is currently using this file」(0x80070020)で起動できなくなる現象も報告されています。原因別の対処はClaude Desktopが0x80070020で起動しないときの原因と対処法にあります。Repairを実行しても0x80073D02で起動しなくなる場合は、CoworkVMServiceのAUTO_START設定が原因のことがあります。切り分けと回避策はClaude DesktopがCoworkVMServiceで起動しない原因と対処法に載せています。
展開の進め方
配る順序は次のとおりです。各手順の詳細は、手順名に対応する前の節にあります。
Windows一括導入の流れ
- 1
x64とarm64のMSIXを取得する
端末のCPUに合わせて選びます。入手先はWindows向けの公式配布ページのダウンロード欄です。
- 2
Virtual Machine Platformを有効化する
Coworkを使う端末だけで足ります。再起動の予定も組みます。
- 3
Add-AppxProvisionedPackageで配る
詳細は「何台に・誰向けに配るかでコマンドを選ぶ」の節にあります。
- 4
更新の持ち主を決める
選び方は「自動更新の主導権をMDMとアプリのどちらに置くか」の節にあります。
- 5
HKLMのポリシーを配る
キーの一覧は「管理設定はレジストリのポリシーキーで配る」の節にあります。
よくある質問
macOSの一括導入とはどう違いますか
Windowsには、Virtual Machine Platformの有効化と、ユーザー単位のMSIXをマシン全体へ配る手順が加わります。macOS側の手順はClaude DesktopをmacOSで一括導入する手順(PKG)にまとめています。