――IEモード移行期に潜む“UserChoice”の罠と実践的な解決フロー
仮想環境では同じマスターイメージを使っているはずなのに、同僚の PC でだけ「このページのスクリプトでエラーが発生しました」と表示される謎のダイアログ。原因は HTA（HTML Application）が Windows 11 のレジストリ保護にぶつかったことでした。実際に行った聞き取り・再現テスト・資料調査をもとに、トラブルのメカニズムから恒久対処、さらには IE 依存脱却のロードマップまで多角的にまとめます。
エラーが出た瞬間を時系列で整理
まずは「何が起きたのか」を情景ごとに洗い直すと原因が見えやすくなります。
同僚が VMware Workstation で起動した Windows 11 Pro にログオンし、社内ツールのショートカット（CMAWPXAOpener.hta）をダブルクリック。即座にスクリプトエラーが発生し、「UserChoice\Progid を開いて読み取ることができません」とだけ表示されました。同じ操作をしても問題なく Edge（IE モード）でサイトが開く――ここに「環境は同じなのに挙動が違う」ギャップがあります。初動対応としてエラーダイアログを Yes で継続させてもアプリは起動せず、No を押すと HTA が終了するだけでした。
HTAとは何か？仕組みとリスクをざっくり理解
HTML だけで作れる小さな Windows アプリ。それが HTA です。
HTA は .hta 拡張子のファイルを mshta.exe が実行する仕組みで、JavaScript / VBScript が OS のレジストリやファイル操作を“ほぼ制限なく”呼び出せます。ブラウザサンドボックス外で動けるため強力ですが、逆にマルウェアに悪用されやすく、Microsoft も高リスクであることを明言しています。Windows 11 でも動作は保証されていますが、描画エンジンは IE11 世代で頭打ちのままです。
HTMLと何が違う？一目でわかる比較表
混同しやすいので、表で要点を押さえましょう。
| 項目 | HTA | HTML |
|---|---|---|
| 実行主体 | mshta.exe | Webブラウザ |
| OS 依存 | Windowsのみ | クロスプラットフォーム |
| 権限 | フル（レジストリ・ファイル操作可） | サンドボックス制限 |
| 主用途 | 社内業務ツール、旧インストーラ | Webコンテンツ |
| セキュリティ | 高リスク／署名推奨 | ブラウザ側で保護 |
同僚だけにエラー？水平思考で3パターンを検証
「設定」より「履歴の差」に着目すると糸口が見えます。
- 既定ブラウザ未設定
- Windows 11 は既定ブラウザを決めるまで
UserChoiceキーを生成しません。HTA がキー読取に失敗→エラー。
- Windows 11 は既定ブラウザを決めるまで
- GPO でレジストリ読取が制限
- 社内 OU が違う、あるいは一時テスト用アカウントでポリシーが緩い／厳しい差が出た可能性。
- UAC・AppLocker が阻止
- HTA を初回実行した際の判断が“危険”として記録され、以後ブロックされるケース。
検証では、同僚の VM にログオンして Edge を開いてみると「既定のブラウザに設定しますか？」ダイアログが残っており、①の可能性が極めて高いと判断できました。
レジストリキー「UserChoice\Progid」の役割
謎のエラーメッセージの本丸がここです。
HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\HTTP\UserChoice にある Progid 値は「HTTP を開くときに呼ぶプログラム ID」を保持します。Windows 11 では初回にアプリを選ばない限りこのキー自体が存在せず、読取を行うスクリプトは“キーが無い＝エラー”を返します。Enterprise 管理では GPO でこのキーの権限を変更し、書き換えを防止する運用が一般的です。
GPO（グループポリシー）が影響する場合の見分け方
「自分は動くのに同僚は読めない」の典型がポリシー差です。
gpresult /h report.html コマンドを実行すると適用 GPO 一覧を取得できます。Computer Configuration → Windows Settings → Security Settings → Registry に対象キーが列挙されていれば、管理側でアクセス権が ReadOnly に縛られています。この場合ユーザー側では解除できず、IT 管理者に“キー読取だけ許可”か“HTA の改修”を依頼する必要があります。
即効解決！Edgeを既定ブラウザに設定する手順
最短ルートは「キーを自動生成させる」こと。
- Edge を起動し、右上「…」→設定。
- 左メニュー [既定のブラウザ] を開く。
- [既定に設定] をクリック。
- Windows の UAC が出たら「はい」で許可。
- HTA を再実行し、エラー消失を確認。
これで UserChoice\Progid=MSEdgeHTM が書き込まれ、HTA 側も読取に成功します。
それでも解決しないときの深掘りアプローチ
キーは作成されたのにまだエラー？順に切り分けます。
- 64bit／32bit の mshta.exe 切り替え
SysWOW64 側が呼ばれ、レジストリリダイレクトで読取に失敗するケースあり。 - IE モードのサイトリスト確認
管理テンプレートで.hta起動後の URL が IE モード強制になっていないかチェック。 - サードパーティ AV の HTA ブロック
ログに「mshta.exe が危険」と出ていれば除外設定。 - レジストリ ダミー値の作成（社内規定で許される場合のみ）
reg addでProgidを手動投入し、再起動後に挙動を観察。
IE依存の限界と脱却プラン
HTA は動き続けますが“時代遅れ”は否めません。
Microsoft は IE 本体を廃止しても HTA の互換実行は当面維持するとしていますが、描画エンジンは更新されず Web 標準への対応も停滞します。Edge の IE モードは 2030 年までサポート予定なので、その間に WebView2 への置き換え や Progressive Web App（PWA）化 を検討するのが現実的です。また、Edge では IE モードで開きたい拡張子をグループポリシーで関連付けることも可能です。
まとめチェックリスト
再発防止のために、最後に要点を箇条書きで。
- HTA は強力だがレガシー。Windows 11 ではレジストリ保護が強化。
- キー未生成状態で HTA が
UserChoice\Progidを読みに行くとエラー。 - 既定ブラウザが未設定か GPO で権限が絞られたときに発生しやすい。
- 対処の第一歩は Edge（または運用ブラウザ）を既定に設定。
- 長期的には HTA 依存を抜け出し、WebView2 や PWA へ移行する。
コメント