Microsoft Teamsの自動起動をGPOで止める前に、対象が旧Teamsか新Teamsかを必ず確認してください。旧TeamsのMachine-Wide Installer向け「Prevent Microsoft Teams from starting automatically after installation」は、インストール後に一度も起動していない利用者を主対象とする旧方式です。現在の新TeamsはMSIXとしてプロビジョニングされ、初回起動後にWindowsのStartupTaskへユーザー単位の状態を持ちます。2026年7月時点では、通常PCと非永続VDIで公式に説明される管理範囲が異なります。本記事では新Teamsを基準に、パイロットユーザーのStartupTask状態をGPPで設定し、Windows設定とTeams設定、gpresultで確認する方法を示します。全UWPアプリの起動タスクを無効にするマシンポリシーは影響が広いため、Teamsだけを止める標準策にしません。
最初に旧Teamsと新Teamsを見分ける
新TeamsはTeamsBootstrapperがTeams MSIXを全ユーザーへプロビジョニングする方式です。旧TeamsのMachine-Wide Installer、Teams.exeのRunキー、Office 16.0のTeams管理テンプレートを前提にした記事をそのまま使うと、新Teamsへ効かなかったり旧Teamsだけが残ったりします。設定、アプリ、インストールされているアプリでMicrosoft Teamsのパッケージを確認し、Teamsのバージョン、Windowsビルド、VDIか通常PCか、初回起動済みかを台帳へ記録します。旧・新が同時に自動起動する端末では、先に組織の移行手順で旧Teamsを整理し、二つの起動元を別々に調査します。
- 新Teamsの導入元がTeamsBootstrapper、Microsoft 365 Apps、Intuneなどのどれか確認する。
- 利用者が一度Teamsを起動したか、TeamsのGeneral設定にAutostart Teamsが表示されるか確認する。
- Windows 11のSettings、Apps、StartupでMicrosoft Teamsの現在状態を記録する。
- 通常PC、共有PC、AVD/RDS、非永続VDI、FSLogixの対象を分ける。
- 自動起動を管理者が強制するのか、初期値だけOffにして利用者変更を許すのか決める。
新Teamsの自動起動は初回起動後に登録される
Microsoftの新Teams VDI資料では、MSIXアプリはプロビジョニングされた段階では自動起動せず、初回起動とユーザーの同意後にStartupTaskが登録されると説明されています。その後、TeamsのSettings、GeneralにあるAutostart Teams、またはWindowsのStartup appsから変更できます。つまり「Teamsをインストールした直後に自動起動を止める」という旧ポリシーと、「既にTeamsを使ったユーザーのStartupTaskを無効にする」は別の処理です。既存ユーザーへ一括適用するなら、ユーザーコンテキストで現在のStartupTaskキーが存在するかを確認し、存在しない新規ユーザーにも安全な挙動を検証します。
通常PCで利用者が手動確認する方法
単発端末や利用者選択を許す運用では、Teamsのプロフィール画像、Settings、GeneralでAutostart Teamsをオフにするか、WindowsのSettings、Apps、StartupでMicrosoft Teamsをオフにします。Task ManagerのStartup appsにも同じ管理対象が表示されます。Microsoft Supportは、WindowsのスタートアップアプリはSettingsまたはTask Managerで有効・無効を切り替えられると説明しています。これを検証の基準にし、GPO適用後に両画面の状態が一致するか確認します。StartupフォルダーへTeamsのインストーラーやショートカットが別途置かれている場合は、それも別の起動元です。
新TeamsのStartupTask状態を読み取り確認する
MicrosoftのTeams VDI資料では、ユーザーごとのMSTeamsパッケージにあるTeamsTfwStartupTaskキーのStateで自動起動状態を表します。0はDisabled、1はDisabledByUser、2はEnabledByUser、3はDisabledByPolicy、4はEnabledByPolicyです。キーはHKEY_CURRENT_USER配下であり、利用者ごとに異なります。まずレジストリエディターや読み取り用管理ツールで存在と現在値を確認し、エクスポートまたは設定記録を保存します。パッケージ識別子や内部パスはTeams更新で変わる可能性があるため、Microsoftの最新VDI資料と実機を照合します。
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MSTeams_8wekyb3d8bbwe\TeamsTfwStartupTask
State = 1 または 3（目的と利用者変更可否に応じて検証）DisabledByUserの1は利用者が無効にした状態、DisabledByPolicyの3はポリシーで無効にした状態を表します。どちらを配るべきかは、利用者に再有効化を許すかで決めます。値を設定すればすべての通常PCでMicrosoftが保証する、と一般化しません。引用元はVDI展開資料であるため、対象の新Teams版、Windowsビルド、通常PCまたはVDIで実機検証し、Microsoftサポート要件へ合わせます。キーが存在しないユーザーへ親階層を推測して作る前に、Teamsを一度起動した検証ユーザーと未起動ユーザーで差を確認します。
GPP Registryでユーザー単位に配る
- 新Teamsを公式手順で導入した検証PCと、初回起動済み・未起動の検証ユーザーを用意する。
- 変更前のTeams設定、Windows Startup、StartupTaskキー、Teams版を記録する。
- 検証用GPOのUser Configuration、Preferences、Windows Settings、Registryを開く。
- HKEY_CURRENT_USERの対象キーとStateをUpdateで設定し、値の型をDWORDにする。
- アイテムレベルのターゲット設定で新Teams導入済み、対象グループ、必要なOSを限定する。
- 検証OUへリンクし、サインアウト・サインイン後にTeamsが起動しないことと画面状態を確認する。
- 対象外へ戻したときの値の残存、利用者が再有効化できるか、次のGPO更新で戻るか確認する。
Updateは既存値を更新します。「Apply once and do not reapply」を選べば初期値だけを与えて利用者変更を許す設計にできますが、端末交換や新規プロファイル時の再適用を考えます。毎回再適用すれば管理者のOffを維持できますが、利用者が会議通知のために自動起動を必要とする例外が発生します。対象グループと例外グループを用意し、勤務形態や共有PCごとに決めます。「適用されなくなったら削除」はキーを消す影響を検証し、別のTeams状態を壊さないよう安易に使いません。
旧Teams向けADMXポリシーの扱い
Office管理テンプレートにある「Prevent Microsoft Teams from starting automatically after installation」は旧Teamsの導入時動作を制御するためのものです。説明上、Teamsをインストールする前に有効化し、ユーザーが一度Teamsを起動すると、その後の自動起動は利用者設定の影響を受けます。新Teamsへ移行済みの環境でこのGPOだけを有効にしても、既存のStartupTaskを止める根拠にはなりません。旧Teamsが残る移行期間だけ目的と対象を明記し、新Teamsの検証結果と混ぜないでください。旧クライアント撤去後は不要な旧GPOを無効化・保管し、競合調査を簡単にします。
全UWP StartupTaskを止めるポリシーを避ける
Teams VDI資料には、EnableFullTrustStartupTasksやEnableUwpStartupTasksなどWindows全体のStartupTask可否に関わる値も記載されています。これらを0にするとTeamsのチェックボックスがグレーになる一方、他のUWP・MSIXアプリへ影響する可能性があります。Teamsだけの自動起動を止めたい目的で、端末全体のStartupTask機構を無効にしません。既に設定されている場合は、セキュリティ基準やVDI設計の所有者へ確認し、他アプリの通知・常駐・更新を含めて検証します。
非永続VDIではプロファイル保持を確認する
非永続VDIでは、TeamsTfwStartupTaskキーをセッション間で保持しないと、利用者がOffにしても次回ログオンで戻る場合があります。MicrosoftはFSLogix ODFCコンテナーがこのキーをローミングしない点と、別のプロファイル管理で保持する必要を説明しています。通常PC向けGPOをそのままVDIへ広げず、HVDの新Teams版、WebView2、メディア最適化、プロファイル製品、ゴールデンイメージ更新を含めたVDI手順へ統合します。自動更新を止めるVDI専用レジストリも通常PCへ配らず、Teams更新と会議アドインの管理を別に設計します。
適用結果を確認する
- gpresultでユーザーGPOが適用され、セキュリティ・WMI・ループバックで拒否されていない。
- StartupTaskのState、Teams General、Windows Startup、Task Managerの表示が目的に一致する。
- サインアウト、再起動、Teams更新、端末交換、新規ユーザーで自動起動しない。
- Teamsを手動起動して会議通知、チャット、通話、Outlook連携が正常に動く。
- 例外ユーザーは再有効化でき、強制対象は次回更新でもOffを維持する。
反映されない場合の確認順
旧Teamsか新Teamsか、初回起動済みか、対象キーが存在するかを最初に確認します。次にgpresult、ユーザーOU、セキュリティフィルター、ループバック、値型、Stateを確認します。Teamsが起動する場合はWindows Startup、Runキー、Startupフォルダー、旧Teams、スケジュールタスクなど別の起動元を調べます。利用者プロファイル削除やTeamsキャッシュ全消去を通常の解決策にせず、新規検証ユーザーと比較します。更新後にキーの扱いが変わった場合は、最新のMicrosoft Teams展開資料とサポートへ確認し、推測した内部キーを全社配布しません。
Teams自動起動の一括管理は、製品世代と利用者変更可否を明確にすることが核心です。旧TeamsのOffice ADMXだけに頼らず、新TeamsのStartupTaskをパイロットで確認し、通常PCとVDIを分け、Teamsだけに限定したユーザー設定として配布してください。
コメント