Windows起動時にアプリを自動実行する方法は、現在も主に「スタートアップアプリ」「タスクスケジューラ」「Runレジストリ」です。ただし「PC起動時」と「ユーザーサインイン時」は別です。画面を表示するアプリはサインイン後、ユーザー不在でも動く保守処理はサービスやタスクを検討します。実行ファイルの署名、保存先、権限、ネットワーク待ち、失敗時の再試行、停止方法を決めてから選びます。
最も簡単な方式を選ぶのではなく、誰の権限で、いつ、画面が必要か、失敗をどう検知するかで方式を決めます。自動起動はマルウェアも使う永続化ポイントなので、登録内容を定期監査します。
三方式の違い
- スタートアップ：ユーザーがサインインした後に、対話アプリを簡単に起動する
- タスクスケジューラ：起動時、サインイン時、時刻、イベントなどを条件にし、遅延・再試行・権限を管理する
- Runキー：サインイン時に実行する単純な互換手段。順序や即時性は保証されず、直接編集は管理負荷が高い
Windowsサービスは第四の選択肢ですが、画面操作をする通常アプリを無理にサービス化しません。ベンダーがサービスとして提供する常駐処理だけを正式手順で導入します。サービスアカウントへ対話ログオンや管理者権限を不要に付けないでください。
スタートアップを使う
Windows 11では「設定 → アプリ → スタートアップ」またはタスクマネージャーのスタートアップアプリから有効・無効を管理できます。登録されていないデスクトップアプリは、現在ユーザーの`startup`フォルダーへショートカットを置く方法があります。実行ファイル本体をコピーせず、管理されたインストール先へのショートカットにします。
- アプリを手動起動し、一般ユーザー権限で正常に動くことを確認します。
- 実行ファイルの署名、版、パスを記録し、ユーザーが書き換えられる共有場所を使いません。
- 現在ユーザーだけか全ユーザーかを決め、最小範囲のスタートアップへ登録します。
- サインアウト・サインイン後に一つだけ起動し、エラーや二重起動がないか確認します。
- 無効化またはショートカット削除で元へ戻し、手動起動できることを試します。
タスクスケジューラを使う
タスクスケジューラは、Boot triggerとLogon triggerを区別し、遅延、ネットワーク条件、再試行、最大実行時間、複数起動時の動作を設定できます。画面を表示するなら「ユーザーがログオンしているときのみ実行」が基本です。「ユーザーがログオンしているかどうかにかかわらず実行」では対話画面が見えず、資格情報管理も必要です。
タスクには専用フォルダー、説明、所有者、変更番号を付けます。「最上位の特権で実行」はアプリが本当に必要とする場合だけにし、一般アプリの起動問題を管理者権限で隠しません。パスに空白がある場合の引用、作業フォルダー、引数を確認し、スクリプトへパスワードを書きません。
Runレジストリを使う
Microsoft公式によるとRunは毎回のサインイン、RunOnceは一度だけ実行され、その後削除されます。HKCUは現在ユーザー、HKLMは端末全体です。複数項目の実行順序は不定で、システムが実行を遅らせることがあります。順序依存や厳密な起動時間が必要な処理には向きません。
レジストリを直接編集する前に対象キーをエクスポートし、値名、型、コマンド行を記録します。GPOやMDM、インストーラーが管理している値を手作業で上書きしません。RunOnceを毎回作り直す設計はWindowsセットアップと干渉するため避けます。
方式を選ぶ判断表
- 利用者が画面を操作する：スタートアップまたはログオントリガー
- 全ユーザーで必要：管理されたアプリ配布と端末単位設定
- ネットワーク接続後に起動：タスクのネットワーク条件と遅延
- 毎週・イベント発生時：タスクスケジューラ
- 一度だけセットアップ完了：ベンダーの正式なRunOnceまたは配布ツール
- 常時バックグラウンド処理：製品が提供するWindowsサービス
検証する項目
コールドブート、再起動、サインアウト・サインイン、スリープ復帰、VPN前後、オフライン、標準ユーザーで試します。二重起動、起動順、画面位置、更新通知、CPU・メモリー、終了、ログを確認します。起動に失敗してもデスクトップが使えること、セーフモードなど復旧経路を妨げないことが重要です。
Autorunsで棚卸しする
Microsoft SysinternalsのAutorunsは、Startup、Run/RunOnce、サービスなど多くの自動起動場所を読み取る公式ツールです。組織承認の下で使用し、まず一覧を保存します。不明項目を即削除せず、発行元、署名、ハッシュ、所有アプリを調査します。無効化で試し、問題があれば再有効化できるようにします。
ロールバック
変更前のスタートアップ一覧、タスクXML、レジストリエクスポートを保存します。障害時は追加した一項目だけを無効化し、再起動後に正常化を確認します。実行ファイル自体を削除する前に登録を外します。全社配布ではパイロットリングを戻し、GPO/MDMの旧構成を再配布して適用結果を確認します。
アプリ更新と自動起動の関係
アプリ更新で実行ファイルのパスが変わると、Startupショートカット、タスク、Run値が壊れます。MSIXやMicrosoft Storeアプリは従来のexeパスを直接指定しない場合があります。ベンダーが提供するスタートアップ登録を優先し、更新後にパス、署名、起動引数、設定ファイルを確認します。
自動更新プログラムを管理者権限で毎回起動する設計は避けます。組織のソフトウェア配布基盤で更新し、利用者セッションでは本体だけを標準権限で起動します。旧版実行ファイルがユーザー書き込み可能な場所に残ると、置換や乗っ取りの危険があります。
ログオンストームを防ぐ
共有VDIや多数端末が同時サインインすると、自動起動アプリがサーバー、プロキシ、ライセンス基盤へ集中接続します。タスクスケジューラの遅延やランダム遅延、アプリ側のバックオフを検討します。全員の始業時刻で負荷試験し、CPU、ディスク、認証、ネットワークを測ります。
依存サービスがまだ利用できない場合、アプリがエラー画面を残したまま再試行しないことがあります。ネットワーク利用可能、特定イベント、遅延ログオンなど適切なトリガーを選びます。固定時間の待機だけでは遅い端末と速い端末の両方に合いません。
自動起動が消えた場合
設定画面のスタートアップ一覧、タスク履歴、Run値、Autorunsを読み取り、どの方式で登録されていたかを確認します。セキュリティ製品が隔離した場合は、安易に許可リストへ入れず署名と検知理由を調べます。実行ファイルが削除・移動されているなら、正規インストーラーで修復します。
GPOで配布した項目を利用者が手動で再作成すると、次回更新で二重化します。ヘルプデスクには再登録ではなく、ポリシー適用、対象グループ、パス存在、イベントの確認手順を用意します。
廃止時の順序
利用を止めるときは、自動起動登録を無効化し、再起動で起動しないことを確認してからアプリをアンインストールします。先に本体を消すと壊れたスタートアップ項目が残ります。タスクの保存済み資格情報、ログ、設定、キャッシュ、ファイアウォール規則も製品手順に沿って整理します。
全社廃止は一部リングで実施し、業務依存がないか観察します。復旧が必要な期間はインストーラーと構成を安全に保管し、期限後に削除します。
コメント