PowerShell 7.6 遅延の真相：Microsoftが公式に認めた6つの失敗
PowerShell 7.6のLTSリリースが.NET 10のGA後131日遅れた。Microsoftは事後報告書を公開し、その原因を珍しく詳細に告白している。
PowerShell 7.6のLTSリリースが.NET 10のGA後131日遅れた。Microsoftは事後報告書を公開し、その原因を珍しく詳細に告白している。
「131日の遅れ」が意味するもの
.NET 10のGA（一般提供）から、PowerShell 7.6のリリースまでに131日かかった。DevolutionsのCTO・Marc-André Moreauがリリース直後に公開した計算で明らかになった数字で、過去のリリースと比べると異常に映る。
PowerShell 7.4は.NET 8のGA後わずか2日でリリースされた。7.5は51日だった。それが今回は131日。
PowerShellは.NETと深く結びついた言語だ。これは正常な状態ではなく、私たちのような企業の.NETエコシステムにも、すでに影響が出ている。 — Marc-André Moreau（CTO, Devolutions）
これは単なる遅延ではない。.NETエコシステム全体が.NET 10への移行を進めるなかで、PowerShellだけが足踏みを続けた。プロダクション環境で安定版のみを使えるエンタープライズや、PowerShellモジュールを同梱する製品開発者にとって、この空白期間は実害を伴うものだった。
シニアPMが自ら書いた「何が起きたか」
遅延の経緯を知るために、Microsoftが公式ブログで公開した事後検証記事が手がかりになる。著者はシニアプロダクトマネージャーのジェイソン・ヘルミック本人だ。企業が自らの失敗をここまで細かく列挙するのは珍しく、その内容は率直だった。
まず規模感から。PowerShellの1リリースには、月3〜4バージョン、29パッケージ、8パッケージ形式、4アーキテクチャ、8種のOSへの対応が含まれる。そしてリリースごとに約28万7,855件のテストが全プラットフォームで実行される。この複雑さを前提として、問題はリリースサイクル後半に集中した。
2025年10月：最初のひび割れ
新しいビルドシステムへの移行作業中、7.6-preview.5においてAlpineパッケージのビルドが壊れた。Microsoft.PowerShell.Nativeライブラリの新しいビルド方法がAlpineと互換性を持たなかったためだ。
これ自体は修正可能な問題だった。問題なのは、この修正が後の工程に連鎖した点にある。
2025年11月：コンプライアンスが追い打ちをかける
外部からのコンプライアンス要件が追加され、非Windowsプラットフォーム向けパッケージングツール（RPM・DEB・PKG）を全面的に置き換えることが求められた。
リリースパイプラインはこのツールに強く依存していた。それが使えなくなったとき、代替手段は何も用意できていなかった。
既存ツールで要件を満たせないと判断されたため、コアのリリースパイプラインをゼロから再構築することになった。リリースサイクルの後半、時間的プレッシャーが最も高まるタイミングで、だ。
2025年12月〜2026年3月：問題の連鎖
12月はホリデーシーズンによるチェンジフリーズと人員不足が重なり、PMC（Package Management Center）へのパッケージ公開が不可能に。NuGetパッケージの公開は手動プロセスに依存しており、担当可能な人員が休暇中だった。
1月にはRHEL 8との互換性問題が追加で浮上した。libpsl-nativeライブラリが、RHEL 9以降で使われるglibc 2.33ではなく、glibc 2.28でビルドされる必要があることが判明した。
こうして修正・検証・バックポートのサイクルが2月まで続き、ようやく3月に安定版がリリースされた。
Microsoftが認めた「6つの失敗」
事後検証が単なる謝罪文と異なるのは、ヘルミックが問題を技術的事象としてではなく、構造的な失敗として名指しした点にある。
リリースオーナーシップの不在 — 誰がリリースに責任を持つか明確に定義されておらず、特にメンテナーの引き継ぎ時に責任の空白が生まれた。
タイトでない依存関係管理、プレビューリリースの減速、ブランチ間のバックポート複雑化、そして「問題が起きていることを早期に示すシグナルがなかった」という検知の失敗。読み返すと、技術的な問題というより、プロジェクト管理の問題としての側面が強い。
今回のリリースサイクルで最大の盲点は、パッケージングの変更がリリーススケジュールに深刻な影響を与えるという、早期シグナルが存在しなかったことだ。
約束された改善策
問題の列挙だけで終わらないのが今回の報告書のもう一つの特徴で、すでに実施中の変更として具体的な施策が示されている。
リリースごとの明確なオーナー指定、内部トラッキングシステムの強化、プレビューの定期カデンス再建、パッケージングシステムの簡素化。そしてGitHubのdiscussionsを通じた早期コミュニティ通知。
最後の点は注目に値する。これまでMicrosoftはリリース遅延に関してコミュニティへの説明が遅れがちだった。今後はGitHubのパブリックな議論スペースでタイムリーに状況を共有するという約束だ。
問題の本質は何か
今回の遅延を「技術的な事故」として片付けることはできる。だが、コンプライアンス要件が後半に割り込んだという構造は、大企業のソフトウェア開発において繰り返し現れるパターンだ。法務・セキュリティ部門の要求がエンジニアリングスケジュールと衝突したとき、後者が押し流される。
エンタープライズ企業やDevOpsエンジニアにとって、「安定版がない」という状況はプロダクションのデプロイ計画に直接影響する。今回の事後報告書は誠実な内省であることは確かだが、改善策が次のリリースで実証されるかどうかが、信頼回復の本当の試練になるだろう。
Jason Helmick
関連記事
- Windows 11、24H2ユーザーに25H2への強制アップデートを開始
- Teamsの「外部デバイス連携」が6月末で完全終了――影響範囲は想像以上に広い
- Windowsセキュリティに「セキュアブート」警告が表示される理由と、6月の期限前に知っておくべきこと
- Artemis II宇宙船でOutlookが二重起動——NASAが月への旅でMicrosoftトラブル対応
- イランのサイバー部隊がStrykerを壊滅させた手口と、FBIが学んだ教訓
- EdgeがPC起動時に自動で開くようになる――Microsoftが新機能をテスト中
- MS古参エンジニアが断言「壊したのは更新ではなく再起動だ」
- リモートデスクトップ終了、後継「Windows App」が検索できない
- 英国CMA、Microsoftの業務ソフト帝国にメスを入れる
- コマンドプロンプトが本気を出す──Windows Terminalの機能がOS標準に統合へ
