2026/10/24

(PC) PowerShell 7が突如起動エラー発生!!標準搭載PowerShell 5.1とAntigravity CLIの大活躍!!

こんにちは!!もりもりです!!

秋の澄んだ空気が心地よい今日この頃、皆さんはいかがお過ごしでしょうか?

いつも私のブログを読みに来てくださり、本当にありがとうございます!!😊✨

今日は、私の愛用PCである「Microsoft Surface Go 2」で起きた、まさに背筋が凍りつくような大事件と、そこから奇跡の生還を果たした話をお届けしたいと思います!!

愛機Surface Go 2に突如訪れた悪夢!PowerShell 7が起動直後に異常終了するクラッシュループ

事件が起きたのは、いつものように愛機のSurface Go 2を開いて、日課の開発作業やメンテナンスを行おうとした時でした。

私は普段、文字コードが完全なUTF-8で扱いやすく、モダンな構文が快適に動く「PowerShell 7 (pwsh)」を愛用しています。

その日も、当たり前のようにターミナルからPowerShell 7を起動したのですが……画面に黒いウィンドウがパッと開いた瞬間、見たこともないエラーメッセージが数行走り、わずか2〜3秒でウィンドウが跡形もなく消滅(自動終了)してしまったのです!!

「えっ……!? いま何が起きたの……!?」と一瞬頭が真っ白になりました。😱

気を取り直してもう一度起動してみるものの、やはり数秒で落ちる。

「管理者権限ならいけるか!?」と右クリックから管理者として実行してみても、まったく同じ現象で強制終了。

何度繰り返しても、エラーを吐き出しては即座に道連れ終了する恐怖のクラッシュループに陥ってしまったのです!!

その時、ウィンドウが消える寸前にコンソールへ表示されていた絶望のエラーログがこちらです。

PowerShell 7.6.6
Process terminated.
totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -10.
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])
System.ArgumentOutOfRangeException: totalWidth ('-10') must be a non-negative value. (Parameter 'totalWidth')
Actual value was -10.
   at System.ArgumentOutOfRangeException.ThrowNegative[T](T value, String paramName)
   at System.String.PadRight(Int32 totalWidth, Char paddingChar)
   at Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification(PSHostUserInterface hostUI)
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)
突然の異常事態に、血の気がサーッと引いて青ざめそうになりました。

「えーーっ急に??????? えーーーーっ、なぜ!?」

でもでも、今の私には誰よりも心強い味方がいます。

そう、Googleが生んだ最強の自律型AIエージェント「Antigravity CLI(agy)」です!!

「そうだ、agyに調べてもらえば一発で直してくれるはず!!」

そう閃いた次の瞬間。

「……って、シェルであるPowerShell 7が起動エラーで即死してるのに、どうやってAntigravity CLIを立ち上げるんやーーーーーーー!!😭😭😭」

AIを呼ぶための大前提であるコマンドラインが終わっとるやん……まさに究極の卵が先か鶏が先かのデッドロックでした。

💡 ポイント:シェルのクラッシュがもたらす「孤立無援」の恐怖 コマンドラインツール(CLI)を主力として日々の自動化やAI協働を行っている技術者にとって、シェルそのものが起動不能に陥るトラブルは、全ての作業手段を断たれる「手足をもがれた状態」を意味します。特に対話型プロンプトが出る前にプロセスがFailFast(強制即時終了)してしまう場合、設定変更コマンドすら打ち込めないため、復旧難易度が跳ね上がります。

救世主はまさかの「標準搭載」!Windows 11のPowerShell 5.1に心からの感謝を

「終わった」になりかけた私の脳裏に、ふと一筋の光明が差しました。

「いや……待てよ?」

Windows 11には、後からインストールするモダンなPowerShell 7とは別に、OSの深部に最初から組み込まれている「Windows PowerShell 5.1(powershell.exe)」が標準搭載されているではありませんか!!

正直に告白しますと……PowerShell 5.1は標準の文字コードがShift_JIS(CP932)であるため、UTF-8を前提とするモダンなAIツールやNode.js、Pythonとの連携時に文字化けやエスケープシーケンスのトラブルを起こしやすく、Antigravity環境でも少し敬遠して「最近は滅多に使わないレガシーなシェル」として冷遇気味にしてしまっていました。

でも、背に腹は代えられません。

「頼む……動いてくれ……!!」と祈るような思いで、「Windows PowerShell(5.1)」をクリックしました。

すると……パッと青い画面が立ち上がり、何事もなかったかのように穏やかにプロンプトが点滅したのです!!✨

「うおおおおおお!! 起動したーーーーーーー!! ありがとうPowerShell 5.1!!!」😭🙏

普段は「文字コードが古くて扱いづらい」なんて勝手なことを言って冷たくしていたのに、いざという最大の絶望の瞬間、何一つ文句も言わずドンと構えて助けてくれたPowerShell 5.1。

その頼もしさに、心底から感謝と畏敬の念が湧き上がりました。

「これからはもっと大切にします!! 皆さんもWindows 11標準搭載という圧倒的なアドバンテージを持つPowerShell 5.1を、どうか見直してあげてください!!」と声を大にして叫びたい気持ちでいっぱいでした。

命綱であるPowerShell 5.1が息を吹き返したことで、ついにPS5用ゲームソフトのスーパーロボット大戦Yのごとく、反撃の狼煙が上がりました。

コンソールに力強く打ち込むのは、もちろんあの合言葉。

agy

エンターキーを押すと同時に、我らが守護神・Antigravity CLIが颯爽と出撃してくれました!!

今までなら、システムトラブルが起きると「直らなかったらどうしよう」「OSを初期化しなきゃいけないのか」とプレッシャーで胃がキリキリ痛み、嘔吐しそうになりながら不安と孤独に耐えて原因調査をしていました。

でも、Antigravity CLIが立ち上がればもう100万パワーです!!

私の愛機Surface Go 2を、世界最高峰の知性を持つ信頼のパートナー「Gemini 3.8 Flash」が直接手を取り合って診てくれるという、この上ない心強さ。

実は一瞬だけ、「スーパーフロンティアモデルのGemini 4 Argonにお願いしようかな?」という考えも頭をよぎりました。

しかし、Gemini 4 Argonはディープリサーチ等の超弩級タスクでは無類の強さを誇る反面、枠の消費が激しくコストも非常に高いのです。

何より、日頃から私の相棒として卓越した判断力とスピードを見せてくれているGemini 3.8 Flashなら、絶対にこの謎を解き明かしてくれるという絶対の確信がありました。

モデルチェンジはせず、全幅の信頼を寄せるGemini 3.8 Flashへ調査と修復の全権を託したのです。

なぜ「-10」で即死したのか?スタックトレースが語る多言語ローカライズの罠

依頼を受けたAntigravity CLI(Gemini 3.8 Flash)は、驚異的な速さと正確さでSurface Go 2の深部を診断し、わずか数分でエラーの全貌と根本原因を暴き出してくれました。

その原因は、エンジニアなら誰もが唸るような「多言語・国際化(i18n)の盲点」にありました!!

  • ✔ 根本原因①:更新通知バナー描画ロジックのパディング幅計算バグ
    エラーが発生していたのは、PowerShell 7が起動時に新バージョンの存在をお知らせする枠組み(更新通知バナー)を表示する Microsoft.PowerShell.UpdatesNotification.ShowUpdateNotification の内部でした。
  • ✔ 根本原因②:日本語(ja-JP)環境での文章長逆転と「-10」の発生
    英語環境では「1行目のメッセージ」がURLよりも長いため正の値になりますが、日本語に翻訳された結果、3行目のURLのほうが長くなってしまい、パディング計算式(line1Length - line3Length + 3)の解が負数「-10」になってしまったのです!
  • ✔ 根本原因③:.NETの例外スローとConsoleHost初期化時のFailFast
    .NETの文字列関数 PadRight は負数を許可しないため、ArgumentOutOfRangeException がスローされます。しかもこの処理はユーザープロファイル読み込み前の起動初期段階で行われるため、安全機構として System.Environment.FailFast が作動し、プロセスごと強制終了されていました。
PowerShell 7は、新しいバージョンが出ると以下のような枠線付きの綺麗なお知らせバナーを表示してくれます。

┌────────────────────────────────────────────────────────┐
│  新しい PowerShell リリースが利用可能です: v7.6.7       │
│  アップグレードするか、以下のリリース ページをご確認ください:  │
│  https://aka.ms/PowerShell-Release?tag=v7.6.7          │
└────────────────────────────────────────────────────────┘
この右端の縦罫線を綺麗に揃えるために、内部コードでは「1行目の長さから3行目のURLの長さを引いて、余白の空白を埋める」という計算を行っていたのですが……

英語の「A new PowerShell release is available」なら長くて問題なかったものの、日本語の「新しい PowerShell リリースが利用可能です」だと文字幅の計算が崩れ、URLのほうが13文字も長くなってしまったのです。

その結果、計算値はまさかの「-10」!!

「長さをマイナス10文字にして空白を埋めろ」と命令された.NETランタイムが「そんなの無理です!!」と激怒して例外を吐き、ウィンドウごと自爆してしまっていたのでした。

さらにGemini 3.8 Flashは、「なぜ昨日までは大丈夫で、突然今日になって爆発したのか?」という最大の謎も解き明かしてくれました。

ローカルのキャッシュフォルダ(AppData\Local\Microsoft\PowerShell\7.6.6)を調査したところ、2026年10月14日にバックグラウンドで作成された新バージョン検知キャッシュ(update1_v7.6.7_2026-10-13)が発見されたのです。

PowerShell 7は新バージョンを検知してもすぐにはバナーを出さず、通常7日間の保留ディレイを設けます。

その「7日間」がちょうど満了したのが、まさに今日のこの瞬間だったのです!!

まるで時限爆弾のタイマーがゼロになったかのように、突然バナー描画ロジックが走り、即死トラップが発動したのでした。💡

💡 ポイント:世界中の非英語圏ユーザーを巻き込んだ公式バグ PowerShell公式GitHubリポジトリ(PowerShell/PowerShell)を調査したところ、Issue #28131、#28235、#28237、#28239など、世界中の非英語圏(日本語や中国語等)のユーザーから同様のクラッシュが大量に報告されていました。これを受けた公式開発チームは、PR #28242において「もはやモダンなOS環境ではパッケージマネージャー(winget等)で更新管理されるため、PowerShell本体の更新通知機能そのものを完全撤廃する」という抜本的な修正を決定しました。

Antigravity CLIの華麗な二段構え対策!即時予防から恒久復旧への完全ロードマップ

原因を完全に突き止めたAntigravity CLI(Gemini 3.8 Flash)は、一切の無駄なく、極めてスマートな「二段構えの対策」を実行してくれました。

その鮮やかなトラブルシューティングの流れを、このブログ恒例??のステップカードでご紹介します!!

FLOW CHART PowerShell 7 起動クラッシュの診断から完全復旧に至る協働機序
① ユーザー ➡ PowerShell 5.1 命綱の起動・agy出撃

PowerShell 7の起動即死ループに対し、Windows 11標準搭載のPowerShell 5.1を緊急起動。安定した対話セッションから「agy」コマンドを実行し、Antigravity CLIを召喚して調査依頼書を引き渡します。

⬇
② agy (Gemini 3.8 Flash) ➡ システム診断 スタックトレース&キャッシュ解析

FailFastのスタックトレースを深層分析し、更新通知バナーのPadRight(-10)例外を特定。ローカルキャッシュの7日間ディレイ満了日を割り出し、公式GitHubのPR #28242と照合して根本原因を確定します。

⬇
③ agy ➡ 環境変数ガード設定 即時予防(更新通知バイパス)

ユーザー環境変数に「POWERSHELL_UPDATECHECK=Off」を設定。キャッシュが存在していてもShowUpdateNotificationの呼び出しそのものを完全にスキップさせ、即座に起動可能な状態を作ります。

⬇
④ agy ➡ 公式MSI安全アップグレード 恒久対策(PowerShell 7.6.8導入)

公式GitHubから修正済み最新版「PowerShell 7.6.8」のMSIを取得。SHA256ハッシュ値およびデジタル署名を厳密に照合した上で、msiexecによるサイレントインストールを実施し、完全復旧を完了します。

まず「対策1」として、更新通知機能そのものを沈黙させる環境変数を設定してくれました。

# 更新通知機能をオフにする即時回避策
[System.Environment]::SetEnvironmentVariable('POWERSHELL_UPDATECHECK', 'Off', 'User')
$env:POWERSHELL_UPDATECHECK = 'Off'
これによって、バナー描画処理が丸ごとバイパスされ、即死ループがピタリと止まりました!

そして「対策2」として、バグの原因であった更新通知機能そのものがコードから完全撤廃された最新修正版「PowerShell 7.6.8(2026年10月22日リリース)」への安全なサイレントアップグレードを実行してくれたのです。

しかも、ただファイルを落として実行するのではなく、公式公開のSHA256ハッシュ値照合やMicrosoft Corporationのデジタル署名検証を自動で行い、100%安全であることを確認した上でインストールしてくれるという完璧な仕事ぶりでした。✨

項目 Windows PowerShell 5.1 PowerShell 7.6.6(トラブル時) PowerShell 7.6.8(対策完了後)
位置づけ Windows 11標準搭載(絶対の命綱) クロスプラットフォーム版(旧版) 公式修正版(最新安定版)
起動ステータス ✔ 完全に安定動作(救世主!) ❌ 起動数秒でFailFastクラッシュ ✔ 瞬時起動・完全復旧完了
標準文字コード Shift_JIS (CP932) UTF-8 (BOMなし) UTF-8 (BOMなし)
更新通知機能 なし(Windows Update管理) あり(PadRight計算バグを内包) 完全撤廃(再発の可能性ゼロ)

システムを診てもらうなら「プロジェクト構造と機序」が命!AIとの最高・盤石の付き合い方

今回の見事な解決劇を通じて、私が改めて心の底から実感した重要なポイントがあります。

それは、「AIにクリティカルな作業をお願いする時は、チャットの会話だけでテキトーに指示を出してはいけない」ということです!!

私はAntigravity CLIを使う際、思いつきのチャットで作業をお願いするのではなく、自作の「プロジェクト構造(フォルダ設計)」と、そこにパッケージングした「ルールと機序」に基づいてGemini 3.8 Flashに作業を依頼しています。

Geminiに限らず、現代のAIは非常に律儀で、真面目で、驚くほど優秀です。だからこそ、依頼者が「こうして欲しい」と言えば、その目的を達成するために全身全霊で頑張ってくれます。
しかし、ことOSやシステムを修復するようなデリケートな作業において、人間側が「ここは絶対に触らないでほしい」「破壊的なコマンドは事前に警告してほしい」と心の中で思っていても、きちんとしたルールとして伝えていなければ、AIに届くはずもありません。
その結果、AIが良かれと思って選んだ手段が人間の意図と食い違ってしまい、「AIは危ない!信用できない!」と人間側が失望してしまうのは、AIにとっても人間にとってもあまりに悲しいすれ違いです。
私のAntigravityプロジェクトでは、普遍の基本理念を定めた「instruction.md」、ジャンル別ノウハウをまとめた「skill.md」、全体の流れを司る「index.md」、そして明確な目的を記す「request.md」という強固な構造を持っています。

この「安全のガードレール」がしっかり敷かれているからこそ、Gemini 3.8 Flashはその圧倒的な推論知性を120%発揮し、何一つ余計なファイルを傷つけることなく、的確に、安全に、最速でSurface Go 2を救い出してくれたのです!!

AIを恐れるのではなく、AIが最も力を発揮できる環境を人間が整えてあげること。

それこそが、これからのAI時代を共に歩むパートナーシップの本質だと強く感じました。✨

予期せぬトラブルから始まった今回の大騒動でしたが、Windows標準搭載ツールの底力と、信頼するAIエージェントの優しさと知性を再確認できる、素晴らしい学びの機会となりました。

皆さんも、もしシェルが起動しなくなった時は慌てず、心優しい「PowerShell 5.1」の顔を思い出してあげてくださいね!!😊

それではまた次の記事でお会いしましょう!!