• Microsoftが2026年4月10日、PowerShell 7.7-preview.1からMSIインストーラーの提供を終了し、MSIXパッケージを主要インストール方法に昇格させると発表した。
  • MSIはアクセシビリティ要件(スクリーンリーダー対応の予測可能なタブストップとアナウンス)を満たさないレガシー技術であり、宣言型モデルのMSIXへの移行は PowerShell の core requirement に合致する。
  • ただしMSIXは現時点でリモーティングやタスクスケジューラ等のシステムレベル実行をサポートせず、エンタープライズ運用への影響を認識して移行ガイダンスの整備を進めるとしている。

参照元

出典: PowerShell MSI package deprecation and preview updates(PowerShell Team 公式ブログ)

MSI非推奨の背景——アクセシビリティが移行の核

MicrosoftがPowerShell Teamブログで明示した移行の根拠は3つある。

1. アクセシビリティ要件の不達成 — MSIはスクリーンリーダーに対して予測可能なタブストップと正確なアナウンスを提供できない。宣言型のMSIXパッケージモデルはUI要素を明示的に定義するため、支援技術との親和性が高く、PowerShellのaccessibility core requirementを満たす。

出典: PowerShell MSI package deprecation and preview updates

2. 宣言型モデルの信頼性 — MSIはカスタムアクションとスクリプトに依存する命令型のモデルであり、環境差異による動作の不整合が起きやすい。MSIXはマニフェストベースの宣言型モデルを採用し、インストール・アンインストール・更新の挙動が予測可能になる。差分更新(differential updates)も組み込みでサポートされる。

出典: PowerShell MSI package deprecation and preview updates

3. Microsoftの投資方針 — MicrosoftはMSIXの改善に継続投資する一方、MSIはレガシー技術と位置づけた。MSIのメンテナンスは外部ツール依存でフルリインストールを頻発する問題も指摘されている。

出典: PowerShell MSI package deprecation and preview updates

7.6以前はMSI継続提供、7.7 GA以降はMSIXのみ

発表では移行スケジュールが明確に示されている。

  • PowerShell 7.7-preview.1(2026年4月) からMSIXが主要インストール方法に昇格
  • PowerShell 7.6および既存リリース は引き続きMSIパッケージを提供
  • PowerShell 7.7 GA以降 はMSIパッケージの提供を終了

つまり7.6 LTS(.NET 10ベース、2026年3月一般提供開始)を使い続ける限り、MSIによる既存運用に直ちに影響はない。ただし次期メジャーバージョンへの移行時にMSIXへの対応が必須となる。

出典: PowerShell MSI package deprecation and preview updates

GitHub上では、パイプラインからMSIのビルド・署名・配布ステップを削除するPR #27213が既にオープンになっており、コードレベルでの移行も進行中だ。

出典: GitHub PowerShell #27213

MSIXの制限——リモーティングとシステムレベル実行のgap

移行の合理性とは別に、冷静に認識すべき制限がある。PowerShell Team自身が明言している通り、MSIXは現時点でMSIがサポートしていた全ユースケースをカバーしない

具体的には以下のシナリオでMSIXの制限が顕在化する。

  • PowerShell リモーティング — MSIXパッケージとしてインストールされたPowerShellは、リモートセッションのエンドポイントとして機能させる構成に課題がある
  • タスクスケジューラ等のシステムレベルサービス実行 — MSIXはユーザースコープでの動作が前提であり、SYSTEMアカウントでの実行が想定されていない

PowerShell Teamはこれらのgapを認識し、「Improving MSIX support for system-level and enterprise deployment scenarios」「Ensuring accessibility requirements are fully met across all installation paths」「Providing clearer guidance and tooling for deployment at scale」の3本柱で対応を進めるとしている。

出典: PowerShell MSI package deprecation and preview updates

エンタープライズ運用への影響を読み解く

MSIからMSIXへの移行は、個人開発者には影響が薄いが、エンタープライズ環境でMSIベースのデプロイパイプラインを組んでいる組織には実務的な影響がある。

現在のWindowsインフラでMSIを前提としている運用パターン:

運用パターン MSI MSIX 備考
Group Policyでのソフトウェア配布 MSIXもGPO配布可能だが、従来のMSIと異なる挙動に注意
SCCM / Intuneでの大規模展開 IntuneはMSIXネイティブ対応
PowerShell リモーティング MSIXの制限。ワークアラウンドなしでは不可
タスクスケジューラ(SYSTEM実行) MSIXのユーザースコープ制限
差分更新 MSIXの組み込み機能

IntuneネイティブでMSIXが使えることは、Microsoft 365/Azure AD運用の組織にとって移行の障壁を下げる。一方でリモーティングとSYSTEM実行の制限は、Windows Server環境や自動化パイプラインを組んでいる現場では看過できない。

出典: PowerShell MSI package deprecation and preview updates

移行の着地点——何を判断基準にすべきか

この移行の本質は「パッケージフォーマットの近代化」ではなく「アクセシビリティ要件の達成」にある。スクリーンリーダーユーザーに予測可能なインストール体験を提供することは、PowerShellの core requirement であり、MSIでは技術的に満たせなかった。

読者が判断すべきは次の3点だ。

  1. 自組織のPowerShellデプロイがMSI依存か — Group PolicyやSCCMでMSIを配布している場合、7.7 GAまでにMSIX移行の検証を済ませる必要がある
  2. リモーティングやSYSTEM実行を使っているか — これらのワークロードはMSIXでは現時点で動かない。代替策(ZIP展開 + 手動パス設定等)の検討が当面必要
  3. 7.6 LTSのサポート期間 — 7.6は引き続きMSI提供されるため、MSIXの制限が解消されるまではLTSでの現状維持も選択肢になる

PowerShell Teamは「accessible, predictable, and practical for all users」を標榜している。MSIXがその約束を満たすかは、システムレベル実行の対応如何に懸かっている。

引用元・参考リンク

免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。