Slackをグループポリシー（GPO）で一元管理する方法

2026年にSlackをGPOで一元管理する場合、アプリ配布とデスクトップ設定を分けます。Windows版の従来MSIは2025年9月15日に廃止され、現行の大規模配布は64bit・Arm64対応のMSIXが基本です。配布はIntuneやConfiguration Managerなどの企業向け管理を優先し、GPOだけで行う場合はSlack公式のMSIX配布方式を組織の署名済みスクリプト基準へ合わせます。設定はSlack公式GPOテンプレートを使い、HKLM側のDefaults（利用者が変更可能）またはEnforced（変更不可）へ必要な項目だけ配布します。旧MSIやSLACK_NO_AUTO_UPDATESの手順は使いません。

GPOで管理する対象を三つに分ける

第一はMSIXアプリの導入・更新・削除、第二はAutoUpdateやReleaseChannelなど端末側のデスクトップ設定、第三はワークスペース、アプリ承認、SSOなどSlackサービス側の管理です。GPOだけで三つすべてを制御できるわけではありません。端末設定とSlack管理コンソールの権限を分けて担当者を決めます。

Slackのアプリ承認やEnterprise組織ポリシーはクラウド側で設定し、利用可能な機能は契約プランで異なります。DefaultSignInTeamは初回サインイン先を案内する設定で、未承認ワークスペースへの接続を完全に禁止するものではありません。ネットワーク上の許可ワークスペース制御には、Slack公式が説明するプロキシ方式など別の設計が必要です。

旧MSI手順をMSIXへ置き換える

Slackは、ユーザー単位MSIとマシン単位MSIを2025年9月15日に廃止し、MSIXへ置き換えました。古い記事にあるGPOのソフトウェアインストールでMSIを割り当てる手順や、32bit版を新規展開する手順は現行構成に使えません。既存MSI端末はインストーラー種類、版、ユーザーデータ、アンインストール方法を棚卸しします。

Slackの現行MSIXはWindows 10・11の64bitとArm64に対応し、自動更新を含みます。新規端末はMSIXへ統一し、既存MSIからの移行は検証グループでアンインストール、MSIX導入、サインイン状態、通知、リンク、ファイルダウンロードを確認します。全端末のMSIを一括削除してから検証する順序にはしません。

配布方式は企業向け管理を優先する

SlackはMSIXの配布先としてIntune、Microsoft Endpoint Configuration Manager、DISMとプロビジョニング、MSIX App Attach、AppInstaller、PowerShellを案内しています。既にある端末管理基盤を正とし、検出規則、依存関係、更新リング、再試行、アンインストール、準拠レポートを利用します。

MSIXを全ユーザー向けにプロビジョニングする場合と、現在のユーザーへ登録する場合では動作が違います。共有PC、VDI、非永続端末、複数ユーザー、Arm64を代表パターンとして試します。Microsoft Store版、従来デスクトップ版、MSIXを同じ端末に混在させず、パッケージIDとインストール元を資産台帳に記録します。

GPOだけで配布する場合の安全条件を整える

Slack公式は、MSIXを読み取り可能なネットワーク共有へ置き、ユーザーのログオン時に予定タスクからインストールするGPO代替手順を案内しています。ただし、記事の例を無加工でコピーせず、固定した信頼済みUNC、ファイルハッシュ、コード署名、読み取り専用アクセス、実行ログ、版検出、再実行時の冪等性を組織の基準で実装します。

ExecutionPolicyを回避する引数や、全員が書き込めるNETLOGON・共有、資格情報を埋め込んだスクリプトは使いません。GPO予定タスクの実行主体、トリガー、ネットワーク未接続時、失敗時再試行を検証します。スクリプトを署名して承認済みポリシーで実行できない環境なら、GPO配布に固執せず企業向けMSIX管理へ切り替えます。

Slack公式GPOテンプレートを導入する

デスクトップ設定はSlackの「Manage desktop app configurations」からGPOテンプレートを取得します。テンプレートの配布元、取得日、版、ハッシュを記録し、既存Central StoreをバックアップしてADMXと対応ADMLを正しい言語フォルダーへ配置します。Slackデスクトップ4.31以降がこの管理方式の対象です。

GPOエディターでSlack設定が表示され、説明と値の型が公式表と一致することを確認します。古い独自ADMX、レジストリ基本設定、ログオンスクリプトが同じ値を書いていないか検索します。GPOテンプレートが更新されたときは、設定名と対応版の差分を検証OUで確認してからCentral Storeへ反映します。

DefaultsとEnforcedを使い分ける

SlackのWindows構成には、利用者が後から変更できるDefaultsと、管理者がロックするEnforcedがあります。レジストリではHKLMまたはHKCUを使えますが、同じ設定が両方にある場合はHKLMが優先します。DefaultsはHKLM\SOFTWARE\Policies\Slack\Defaults または HKCU\SOFTWARE\Policies\Slack\Defaults、EnforcedはHKLM\SOFTWARE\Policies\Slack または HKCU\SOFTWARE\Policies\Slack配下です。

初回の使いやすさを整えるだけならDefaults、セキュリティや更新品質の要件ならEnforcedを候補にします。すべてをEnforcedへ置かず、変更を禁止する業務理由を設定ごとに記録します。コンピューターとユーザーのGPOを異なる値にせず、HKLM・HKCU・Defaults・Enforcedの優先関係を表にして管理します。

サポートされる設定だけを配る

Windows向け公式設定には、AutoUpdate、ClientEnvironment、DefaultSignInTeam、DownloadPath、HardwareAcceleration、HideOnStartup、ReleaseChannelなどがあります。AutoUpdateやHardwareAccelerationはREG_DWORD、ReleaseChannelやDownloadPathはREG_SZというように型が異なります。テンプレートの入力欄と公式表を確認します。

商用SlackならClientEnvironmentは既定の1000、GovSlackは1001です。契約も接続先も異なるため、見た目を変える目的で値を変更しません。ReleaseChannelは本番端末をprod、検証端末だけbetaとするのが基本です。DefaultSignInTeamにはSlackが求める有効なワークスペースまたは組織IDを使い、推測したURLや表示名を入れません。

自動更新を止めるなら代替更新を必須にする

AutoUpdateの既定は有効です。Slackのサポートライフサイクルではデスクトップアプリ版はリリース後おおむね12〜18か月で対象外となり、サポート終了版は更新するまでSlackへアクセスできなくなる場合があります。安定化のためにAutoUpdateを無効にするだけでは、将来の利用停止と脆弱性対応遅延を招きます。

無効化する場合は、MSIX配布基盤が新しい本番版を検証・展開する期限、緊急更新SLA、失敗端末レポート、ロールバックを持つことを前提にします。AppInstallerで導入した場合は版のロールバック制御が可能だとSlackは案内しています。更新経路がない端末にはAutoUpdateを無効化しません。

MSIX移行でユーザーデータ場所が変わる

MSIXはファイルシステムとレジストリを仮想化するため、Slackユーザーデータは%LOCALAPPDATA%\Packages\com.tinyspeck.slackdesktop_8yrtsj140pw4g\LocalCache\Roaming\Slackへ保存されます。従来インストーラーの%APPDATA%\Slackとは異なります。Slackは、既存利用者ではWindowsがローミングデータをブレンドすると説明しています。

移行前にログ、キャッシュ、サインイン状態の扱いを検証し、フォルダーを手動でコピー・削除しません。プロファイルクリーンアップやVDI除外、バックアップ、セキュリティ製品のルールが旧パスだけを対象にしていないか確認します。キャッシュ削除を全端末へ配布すると再認証やデータ損失調査を招くため、障害端末へ限定します。

AppLockerとセキュリティ製品を事前確認する

Slackは、AppLockerでパッケージアプリが無効になっているとMSIXが動かない場合があると注意しています。既存のパッケージアプリ規則、発行元、署名、WindowsAppsアクセス、EDRの検知を確認し、Slackだけに必要な最小規則を検証します。AppLockerやEDR全体を無効化して導入しません。

ファイル共有から配布する場合は、管理者だけがMSIXを更新でき、端末・利用者は読み取りだけにします。取得したパッケージの発行元署名とハッシュを検証し、版ごとに保管します。プロキシやTLS検査でSlackのWebSocket通信が失敗する場合も、証明書検証を外さず、Slack公式の接続要件に沿ってネットワーク担当者と切り分けます。

適用結果を端末で四点確認する

検証端末では、①MSIXパッケージとアーキテクチャ、②Slackアプリ版、③適用GPO、④レジストリと画面の動作を確認します。AutoUpdate、ReleaseChannel、DefaultSignInTeamなど、今回変更した項目だけを一覧にし、Defaultsは利用者が変更でき、Enforcedは変更できないことを試します。

サインイン、通知、会議リンク、ファイルアップロード・ダウンロード、プロキシ経由接続、Windows再起動後の自動起動を業務要件に応じて試します。アプリが起動するだけで完了にせず、prodチャンネル、正しい組織、更新経路、ユーザーデータ、AppLockerイベントを確認します。検証結果に端末、利用者、版、時刻を含めます。

クラウド側の管理はSlack管理画面で行う

ワークスペースのアプリ承認、組織レベルのアプリポリシー、SSO、保持、外部共有などはSlack管理機能で構成します。Enterpriseプランでは組織所有者・管理者がアプリ管理ポリシーを設定できますが、利用権限はプランと役割に依存します。GPOのデスクトップ設定が成功しても、Slackサービス側の統制が完了したことにはなりません。

ネットワークから許可済みワークスペースだけへ接続させる場合、Slack公式はSSLプロキシで特定HTTPヘッダーを挿入する方式を説明しています。これはTLS復号、鍵管理、プライバシー、可用性を伴うネットワーク変更です。GPO記事のついでに導入せず、セキュリティ・ネットワーク担当者の独立した設計と承認を求めます。

段階展開とロールバックを設計する

IT検証、代表部門、小規模本番、全体の順でMSIXとGPOを展開し、導入率、版、起動失敗、更新失敗、サインイン、通知、ヘルプデスク件数を監視します。Arm64、共有端末、VPN、プロキシ、VDIなどを段階に含めます。旧MSIの削除とMSIX導入を別々に観測できるよう、移行状態を記録します。

設定の問題は対象GPOを以前の値へ戻し、アプリ問題は管理基盤の既知版またはAppInstallerの管理手順へ戻します。ユーザーデータフォルダーの削除や全社アンインストールを最初のロールバックにしません。未構成へ戻す場合もレジストリ値が残らないかを確認し、MSI・MSIX・Store版の混在を再発させないよう資産台帳を更新します。

確認チェックリスト

旧MSI配布を止め、現行MSIXとアーキテクチャを確認する
配布とGPO設定とSlackクラウド管理を分離する
公式GPOテンプレートでDefaultsとEnforcedを使い分ける
AutoUpdateを止める場合は代替更新リングを用意する
AppLocker・署名・共有権限・プロキシを無効化せず検証する
MSIX版、GPO、レジストリ、実際のSlack動作を段階確認する

SlackのGPO管理は、古いMSIの一括割り当てから、MSIX配布と公式デスクトップ構成へ移行しています。現行の安全な構成は、企業向けMSIX管理、署名済みの配布経路、DefaultsとEnforcedの最小設定、更新リング、クラウド側ポリシーを組み合わせる形です。MSIX移行前に旧インストーラー、ユーザーデータ、AppLocker、アーキテクチャを棚卸しし、小規模端末でサインインと更新まで検証してください。更新停止やセキュリティ無効化で一時的に動かす方法は、安定運用にはなりません。

公式情報・参考資料

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。