Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方

小村 豪

doi:10.5281/zenodo.21589724

Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方

2026年03月23日 01:00 · 更新日: 2026年08月23日 · 小村豪 · Windows, UAC, セキュリティ, 配布, Windows開発

更新履歴(5件・最終更新 2026年08月23日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年08月23日: 管理者特権の要否を決める境界、UACの挙動、昇格を減らす設計を図でも追えるように、Mermaid図を24点追加しました(地の文500〜750字につき1図の規約に合わせたものです)。既存のトークン分離の図にもキャプションを付け、図番号を通しで振り直しました。本文の文章は変えていません。
2026年08月02日: 記事の冒頭に「この記事の知識マップ」節を追加しました。本文で扱っている概念とその関係を、要約・図・詳細ページへのリンクにまとめたものです。本文の主張は変えていません。
2026年08月01日: 外部レビュー(1283件)への対応として本文を更新しました。個々の変更内容は、この下の履歴を参照してください。
2026年08月01日: 書き込みに昇格が必要な代表領域の一覧表と、UACのトークン分離の図を追加しました。判断表に必須・状況次第・不要の判定列を足してラベルを統一し、自分のアプリがどれに当たるかを調べる手順(マニフェストの抽出とVirtualStoreの確認)を新設しました。既定ACLの挙動を一次情報で確認しきれなかった項目は表から外しています。
2026年07月31日: 本文中の関連記事へのリンクの文言が、リンク先の現在のタイトルと食い違っていたのを、実際のタイトルに揃えました。本文の内容は変えていません。
2026年03月23日: 初版公開

この記事を引用する(DOI: 10.5281/zenodo.21589724)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村豪(2026)「Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方」合同会社小村ソフト. https://doi.org/10.5281/zenodo.21589724 https://comcomponent.com/blog/2026/03/23/001-windows-admin-privilege-when-required/

DOI(最新版): 10.5281/zenodo.21589724
DOI(この版): 10.5281/zenodo.22064722

Windows まわりの相談で、よく混ざってくる話があります。

どんな時に「管理者として実行」が必要になるのか
管理者アカウントなのに、なぜまだ UAC が出るのか
インストールは必ず管理者なのか
Program Files に置きたいが、実行時まで昇格が必要になるのか
HKCU と HKLM の違いは、実務では何に効いてくるのか
「一部の処理だけ」管理者特権が必要なアプリはどう作るべきか

この話は、単に「その人が管理者かどうか」だけでは決まりません。実際には、どこへ書くのか、誰に影響する変更なのか、OS のどの保護対象に触るのか で、かなり決まります。

flowchart TB
    accTitle: 管理者特権の要否を決めるもの
    accDescr: 管理者特権が必要かどうかは、その人が管理者かどうかだけでは決まらず、どこへ書くのか、誰に影響する変更なのか、OSのどの保護対象に触るのかでかなり決まることを示す図。
    a0["その人が管理者かどうか"] -.-> a1["それだけでは決まらない"]
    b0["実際に効く問い"] --> b1["どこへ書くのか"]
    b0 --> b2["誰に影響する変更か"]
    b1 --> b3["OSのどの保護対象に 触るのか"]

図1: 要否を決めるのは利用者の肩書きではなく、書き先・影響範囲・保護対象。

この記事では、Windows で管理者特権が必要になる場面を、UAC の前提から順に整理しつつ、どこまでが標準ユーザー権限で済み、どこからが昇格の話になるのか を実務向けにまとめます。内容は 2026 年 3 月時点 で確認できる Microsoft の公式情報を前提にしています。¹²³⁴⁵

1. まず結論

先に、実務での結論だけ並べておきます。

Windows で管理者特権が必要かどうかは、「すごい処理かどうか」よりも、「OS やマシン全体に影響するかどうか」 で決まります。¹⁴
自分のプロファイルだけ に閉じた処理、たとえば %AppData%、%LocalAppData%、HKCU、Documents などを使う処理は、通常は管理者特権なしで済みます。⁶⁷
逆に、マシン全体・全ユーザー・保護領域 に触る処理、たとえば Program Files、Windows、System32、HKLM、HKCR の machine-wide な設定、Windows サービス、カーネルドライバ、ファイアウォール、最高権限タスクなどは、管理者特権が必要になりやすいです。⁴⁶⁸⁹¹⁰
ここで大事なのは、利用者が Administrators グループに所属していること と、そのアプリが今、管理者アクセストークンで動いていること は別だという点です。UAC が有効なら、管理者ユーザーでも通常プロセスは標準ユーザー相当で動き、必要なときだけ昇格します。²⁶
インストール = 必ず管理者 ではありません。per-user インストールのように、%LocalAppData% 配下へ入れる前提なら、管理者特権なしで配布・更新できる設計もあります。¹¹¹²
「なぜか毎回管理者権限が必要なアプリ」は、実際には 実行時データを保護領域へ書いている か、マニフェストで requireAdministrator / highestAvailable を宣言している ことが多いです。⁴¹³
これからの方向性としても、Windows は 必要な瞬間だけ明示的に昇格する 方向に寄っています。Windows 11 の Administrator protection（preview）は、その流れをかなりはっきり示しています。⁵

要するに、「管理者特権が必要か」は、利用者の肩書きではなく、アプリが触る境界で決まる と見ておくのが一番実務的です。

flowchart TB
    accTitle: 影響範囲で分かれる昇格の要否
    accDescr: 管理者特権が必要かどうかは、すごい処理かどうかではなくOSやマシン全体に影響するかどうかで決まり、自分のプロファイルに閉じた処理は不要で、マシン全体・全ユーザー・保護領域に触る処理は必要になりやすいことを示す図。
    j1{"OSやマシン全体に 影響するか"}
    j1 -->|"自分のプロファイル に閉じる"| r1["管理者特権なしで 済みやすい"]
    j1 -->|"マシン全体・全ユーザー・ 保護領域に触る"| r2["管理者特権が 必要になりやすい"]
    r0["すごい処理かどうか"] -.-> r3["判断基準ではない"]

図2: 分かれ目は処理の高度さではなく、変更の影響範囲。

この記事の知識マップ

この記事はWindowsで管理者特権が必要になる場面を、OSやマシン全体に影響する保護領域への書き込みかどうかという観点から整理します。UACが有効な環境では管理者ユーザーが起動したプロセスも既定では標準ユーザー権限で動き、Program FilesやHKLMなど保護領域に触れる操作の瞬間だけ昇格が要求されます。インストールは必ずしも管理者を要さず、per-userインストールなら管理者権限なしで配布・更新できますが、実行時データを保護領域に書いていたり、installer detectionの条件に合致したりすると管理者が必要になりがちです。管理者処理を分離するモデルにはAdministrator Broker Model・サービス・最高権限タスク・昇格COMがあり、Windows11のAdministrator protection(preview)は必要な瞬間だけ昇格する方向をさらに進めたものです。

flowchart LR
    accTitle: Windowsで管理者特権が必要になる場面の知識マップ
    accDescr: OSの保護領域への書き込みかどうかという基準が、UACの昇格要求・per-user/per-machineインストールの選択・installer detectionや仮想化との関係・4つの権限分離モデルの使い分けをどう左右するかを示した図。
    admin_rights["管理者権限"]
    uac["UAC(ユーザーアカウント制御)"]
    protected_system_location["OSの保護領域"]
    integrity_level["整合性レベル"]
    installer_detection["installer detection(インストーラー検出)"]
    file_registry_virtualization["ファイル/レジストリの仮想化(VirtualStore)"]
    requested_execution_level["requestedExecutionLevel(実行レベル宣言)"]
    runtime_data_storage["実行時データの保存先"]
    user_profile_storage_location["ユーザープロファイル配下の保存先"]
    per_machine_install["per-machineインストール"]
    per_user_install["per-userインストール"]
    administrator_broker_model["Administrator Broker Model"]
    sporadic_admin_operation["散発的な管理者操作"]
    os_service_model["Operating System Service Model"]
    continuous_unattended_admin_operation["常時・無人・頻繁な管理者操作"]
    elevated_task_model["Elevated Task Model"]
    short_scheduled_admin_task["短い定型の管理者ジョブ"]
    admin_com_object_model["Administrator COM Object Model"]
    existing_com_integration["既存COM前提の統合"]
    administrator_protection["Administrator protection (preview)"]
    windows_service["Windowsサービス"]
    windows_firewall["Windowsファイアウォール"]
    protected_system_location -->|"前提とする"| admin_rights
    uac -->|"利用する"| integrity_level
    uac -.->|"前提とする"| admin_rights
    installer_detection -.->|"原因になり得る"| uac
    file_registry_virtualization -->|"両立しない"| requested_execution_level
    protected_system_location -->|"用いるのは非推奨"| runtime_data_storage
    user_profile_storage_location -->|"推奨される対応"| runtime_data_storage
    per_machine_install -->|"前提とする"| protected_system_location
    per_user_install -->|"前提とする"| user_profile_storage_location
    per_machine_install -->|"前提とする"| admin_rights
    administrator_broker_model -->|"推奨される対応"| sporadic_admin_operation
    os_service_model -->|"推奨される対応"| continuous_unattended_admin_operation
    elevated_task_model -->|"推奨される対応"| short_scheduled_admin_task
    admin_com_object_model -->|"推奨される対応"| existing_com_integration
    administrator_protection -.->|"の後継"| uac
    installer_detection -->|"両立しない"| requested_execution_level
    windows_service -.->|"前提とする"| admin_rights
    windows_firewall -.->|"前提とする"| admin_rights
    elevated_task_model -->|"前提とする"| admin_rights
    administrator_broker_model -.->|"前提とする"| admin_rights
    os_service_model -->|"前提とする"| admin_rights
    admin_com_object_model -->|"前提とする"| admin_rights

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. そもそも「管理者特権が必要」とは何か

この話で最初に整理したいのは、ユーザー と プロセス を分けて考えることです。

Windows の UAC は、OS への不正な変更を防ぐためのセキュリティ機能です。Microsoft Learn でも、管理者レベルのアクセス許可が必要な変更を行うとき、UAC が通知する と説明されています。¹

さらに、UAC の公式説明では、管理者アクセストークンを必要とするアプリは、エンドユーザーに同意を求める とされており、子プロセスは親プロセスのアクセストークンを継承し、親子は同じ整合性レベルで動く とされています。²

ここから分かることは 2 つあります。

2.1 「管理者ユーザー」でも、普段はずっと管理者として動いているわけではない

Microsoft Learn では、UAC 有効時には Administrators グループのメンバーが起動したプロセスも、特に昇格しない限り標準ユーザー権限で実行される と説明されています。⁶

これは、管理者ユーザーのログオン時に 2 つのアクセストークン が作られ、ふだんは制限された側だけが使われるためです。図にするとこうなります。²

flowchart TD
    L["管理者ユーザーがログオン"] --> S["Windows が 2 つのトークンを用意する"]
    S --> F["フィルターされたトークン<br/>標準ユーザー相当"]
    S --> A["完全な管理者トークン<br/>昇格したときだけ使われる"]
    F --> N["ふだんのアプリ起動<br/>エクスプローラーもこちら"]
    N --> C["子プロセスは親のトークンを継承<br/>だから子も標準ユーザー相当"]
    N --> Q{"保護領域やサービスに<br/>触ろうとしたか"}
    Q -- "いいえ" --> OK["そのまま実行できる"]
    Q -- "はい" --> P["UAC の同意プロンプト"]
    P --> A
    A --> E["昇格したプロセスだけが<br/>保護領域を変更できる"]

図3: 管理者ユーザーのログオン時には2つのトークンが作られ、ふだんは標準ユーザー相当の側で動く。

「管理者ユーザーなのに毎回 UAC が出る」のは、フィルターされたトークンで起動しているところへ、完全な管理者トークンでしかできない操作が来たからです。トークンは起動時に決まるので、あとから足すには新しいプロセスを起こすしかない という点も、ここから読み取れます。

言い換えると、

自分の Windows アカウントは管理者
でも、今ダブルクリックして起動したアプリは非昇格
だから、管理者特権が必要な操作の瞬間だけ UAC が出る

というのは普通です。

「自分は管理者なのに、なぜまだ権限が足りないのか」は、Windows ではごく自然な挙動です。

2.2 同じプロセスの中で「この処理だけ急に管理者」はできない

UAC は関数単位の魔法ではなく、プロセスがどのトークンで動いているか の話です。親子プロセスはトークンを継承するので、非昇格の UI プロセスの中で、あるボタンを押した瞬間だけ同じプロセス内の一部メソッドを管理者化する、という設計はできません。²

必要なら、

別 EXE に切り出す
サービスを使う
最高権限タスクを使う
昇格 COM を使う

といった 別の実行単位 を使う必要があります。¹⁴

この前提を知らないまま設計すると、だいたい「このボタンだけ管理者で実行したいのですが」という、少しつらい相談になります。

flowchart TB
    accTitle: プロセス内の一部だけの昇格はできない
    accDescr: UACはプロセスがどのトークンで動いているかの話で、親子プロセスはトークンを継承するため、非昇格のUIプロセスの中で一部メソッドだけを管理者化することはできず、必要なら別EXE・サービス・最高権限タスク・昇格COMという別の実行単位に分ける必要があることを示す図。
    p1["非昇格のUIプロセス"] -.-> p2["一部メソッドだけ 管理者化は不可"]
    p1 --> p3["必要なら別の実行単位へ"]
    p3 --> q1["別EXEに切り出す"]
    p3 --> q2["サービスを使う"]
    q1 --> q3["最高権限タスクを使う"]
    q2 --> q4["昇格COMを使う"]

図4: 昇格はプロセス単位なので、必要な処理は別の実行単位に分離する。

なお、ここで挙げた 2 点は誤解の温床でもあるので、9 章の「よくある誤解」でも Q&A の形でもう一度扱っています。社内で説明するときは、9 章のほうが短くて引用しやすいはずです。

3. 何で決まるのか - まずは見分け方

一番分かりやすい見分け方は、次の 3 つです。

どこへ書くのか
誰に影響する変更なのか
OS の保護対象に触るのか

3.1 書き込みに昇格が必要な代表領域

以降の各論の前提になるので、まず「ここに書こうとすると昇格が要る」という領域を一覧にしておきます。4 章以降で出てくる話は、ほぼすべてこの表のどれかに当たります。

領域	代表的なパス / キー	書き込み	代わりに使う場所
プログラム配置先	`C:\Program Files`, `C:\Program Files (x86)`	必須	実行時データは `%LocalAppData%` か `%ProgramData%` へ
OS 本体	`C:\Windows`, `C:\Windows\System32`	必須	アプリからは触らない
マシン全体のレジストリ	`HKEY_LOCAL_MACHINE`、通称 `HKLM`	必須	`HKEY_CURRENT_USER`、通称 `HKCU`
ファイル関連付けなど	`HKEY_CLASSES_ROOT`、通称 `HKCR` の machine 側。実体は `HKLM\Software\Classes`	必須	`HKCU\Software\Classes`
全ユーザー共有データ	`C:\ProgramData`	ACL 次第	インストール時にアプリ用フォルダーを作り、ACL を設計しておく
サービス構成	SCM、サービスの実行ファイルや起動種別	必須	-
ドライバ	カーネルモードドライバの導入	必須	-
ファイアウォール	Windows Firewall のルール	必須	-
高権限タスク	タスクスケジューラの `HIGHEST`	必須	`LUA` で足りないか見直す
自分のプロファイル	`%AppData%`, `%LocalAppData%`, `HKCU`, `Documents`	不要	ここが既定の置き場所

はっきり「不要」なのは最後の 1 行だけで、C:\ProgramData が条件付き、残りはすべて昇格側です。逆に言えば、アプリが書く先を、この最後の 1 行と %ProgramData% に寄せられるかどうか が、昇格の要否をほぼ決めます。⁴⁶⁷

flowchart TB
    accTitle: 書く先を寄せられるかで昇格の要否が決まる
    accDescr: アプリが書き込む先を自分のプロファイル配下とProgramDataに寄せられるなら昇格なしの設計に近づき、寄せられずに保護領域へ書くなら昇格側に残ることを示す図。
    w1["アプリが書き込む先を 洗い出す"] --> j1{"プロファイル配下と ProgramDataへ寄せられるか"}
    j1 -->|"寄せられる"| r1["昇格なしの設計に 近づく"]
    j1 -->|"保護領域に残る"| r2["昇格が要る側に残る"]

図5: 昇格の要否をほぼ決めるのは、書く先をどこまで寄せられるか。

3.2 やりたいこと別の判断表

これを「やりたいこと」の側から引けるようにすると、こうなります。判定は 必須 / 状況次第 / 不要 の 3 つで統一しました。

やりたいこと	典型的な対象	判定	補足
自分用の設定・キャッシュ・ログ保存	`%AppData%`, `%LocalAppData%`, `HKCU`	不要	原則ここで足ります
アプリの per-user インストール / 更新	`%LocalAppData%` など	状況次第	配置先が per-user なら不要で済みます
全ユーザー向けインストール / 更新	`Program Files`, `HKLM`	必須	保護領域に書くためです
実行時に保護領域へ書き込む	`Program Files`, `Windows`, `System32`, `HKLM`, `HKCR`	必須	そもそも保存先の設計を見直す対象です
Windows サービスの登録 / 構成変更	SCM, service config	必須	`CreateService` / `ChangeServiceConfig` に管理者権限が要ります
カーネルドライバの導入	driver / kernel	必須	標準ユーザーでは実行できない種類の操作です
Windows Firewall ルールの変更	firewall policy	必須	そのデバイス上の administrative rights が必要です
タスクを `HIGHEST` で実行する	Task Scheduler	必須	登録も実行も昇格前提です

かなり乱暴にまとめるとこうです。

自分のための変更 なら、標準ユーザーで済みやすい
全員のための変更 なら、管理者が絡みやすい
OS の安全側の境界 に触るなら、管理者が必要

この 3 つを先に見るだけで、「なぜ UAC が出るのか」はだいぶ説明しやすくなります。

flowchart TB
    accTitle: 誰のための変更かで見分ける
    accDescr: 自分のための変更なら標準ユーザーで済みやすく、全員のための変更なら管理者が絡みやすく、OSの安全側の境界に触るなら管理者が必要という、乱暴だが実務で役に立つ見分け方を示す図。
    q1{"誰のための変更か"}
    q1 -->|"自分のため"| r1["標準ユーザーで 済みやすい"]
    q1 -->|"全員のため"| r2["管理者が絡みやすい"]
    q1 -->|"OSの安全側の境界"| r3["管理者が必要"]

図6: 「誰のための変更か」を先に見るだけで、UACが出る理由は説明しやすくなる。

4. 管理者特権が必要になりやすい典型例

4.1 全ユーザー向けのインストール、更新、アンインストール

Microsoft Learn の UAC アーキテクチャの説明では、多くのインストーラーはシステムディレクトリやレジストリキーへ書く ため、標準ユーザーには十分なアクセス権がなく、Windows はインストールプログラムを検出して昇格を求めるとされています。³

ここでポイントなのは、インストーラーが「インストーラーだから偉い」のではなく、書き込み先が保護領域だから昇格が必要 だということです。

典型的にはこのあたりです。

Program Files へ配置する
HKLM に machine-wide な情報を書く
全ユーザー向けの COM 登録や統合を行う
サービスやドライバを入れる
マシン全体の更新経路を持つ

このあたりは、管理者特権が必要になりやすいです。³⁸

flowchart TB
    accTitle: インストーラーが昇格を求める理由
    accDescr: インストーラーが偉いから昇格が必要なのではなく、Program FilesやHKLMなどシステムディレクトリやレジストリキーへ書くため標準ユーザーには十分なアクセス権がなく、Windowsがインストールプログラムを検出して昇格を求めることを示す図。
    i1["多くのインストーラー"] --> i2["システムディレクトリや レジストリキーへ書く"]
    i2 --> i3["標準ユーザーには 十分なアクセス権がない"]
    i3 --> i4["Windowsが検出して 昇格を求める"]
    i1 -.-> i5["インストーラーだから 偉いのではない"]

図7: 昇格が要るのは、インストーラーの書き込み先が保護領域だから。

4.2 実行時データを `Program Files` や `HKLM` に書く

これもかなり多いです。 Microsoft の UAC 設計ガイドでは、不要な昇格をなくすべきであり、多くの古いソフトは HKLM / HKCR や Program Files / Windows System folders に書くために、不要に管理者特権を必要としている と説明されています。⁴

さらに、標準ユーザーについての説明では、Program Files フォルダーや HKEY_LOCAL_MACHINE へは書けず、システムを変更するような処理もできない と明記されています。⁶

つまり、

設定ファイル
ログ
キャッシュ
ユーザーごとの状態
最近使った履歴

のような 実行時に変わるデータ を、インストール先フォルダーや HKLM に置いていると、それだけで「このアプリは管理者で起動しないと動かない」になりやすいです。

そしてこれは、アプリが本当に管理者向けだからではなく、保存場所の選び方が悪い だけで起きることが珍しくありません。

flowchart TB
    accTitle: 実行時データを保護領域に書くとどうなるか
    accDescr: 設定ファイル・ログ・キャッシュ・履歴のような実行時に変わるデータをインストール先フォルダーやHKLMに置くと、それだけで管理者で起動しないと動かないアプリになりやすく、原因はアプリが管理者向けだからではなく保存場所の選び方であることを示す図。
    d1["設定・ログ・キャッシュ・ 履歴などの実行時データ"] --> d2["インストール先フォルダーや HKLMに置いてしまう"]
    d2 --> d3["管理者で起動しないと 動かないアプリになる"]
    d3 -.-> d4["原因は保存場所の 選び方だけのことが多い"]

図8: 「毎回管理者が必要」の正体は、実行時データの置き場所であることが多い。

4.3 Windows サービスの登録や構成変更

サービスは OS の管理対象なので、当然ながら軽くは触れません。

サービス制御マネージャーのアクセス権の公式ドキュメントでは、CreateService を呼ぶには SC_MANAGER_CREATE_SERVICE が必要 であり、CreateService に使えるハンドルを開けるのは Administrator privileges を持つプロセスだけ と説明されています。⁸

また、ChangeServiceConfig / ChangeServiceConfig2 に必要な SERVICE_CHANGE_CONFIG は、システムが実行する EXE を変更できてしまうため、管理者のみに付与すべき とされています。⁸

なので、

サービスを登録する
サービスの実行ファイルや起動種別を変える
サービスを削除する
サービスのセキュリティ記述子を変える

のような処理は、管理者特権が前提になります。

flowchart TB
    accTitle: サービス操作と管理者特権
    accDescr: CreateServiceを呼ぶにはSC_MANAGER_CREATE_SERVICEが必要で、そのハンドルを開けるのはAdministrator privilegesを持つプロセスだけであり、構成変更に必要なSERVICE_CHANGE_CONFIGもシステムが実行するEXEを変更できてしまうため管理者のみに付与すべきとされていることを示す図。
    s1["サービスの登録"] --> s2["SC_MANAGER_CREATE_SERVICE が必要"]
    s2 --> s3["ハンドルを開けるのは 管理者プロセスだけ"]
    t1["サービスの構成変更"] --> t2["SERVICE_CHANGE_CONFIG が必要"]
    t2 --> t3["管理者のみに 付与すべきとされる"]

図9: サービスはOSの管理対象で、登録も構成変更も管理者特権が前提。

4.4 カーネルドライバを入れる

Microsoft Learn では、標準ユーザーは kernel-mode driver のインストールのような、システムを変更するタスクを実行できない と説明されています。⁶

これはかなり分かりやすい境界です。ドライバはカーネル側で動くので、普通の「ユーザーアプリの設定保存」と同列には扱えません。

デバイスドライバを導入する
仮想ドライバやフィルタドライバを入れる
ブートや I/O に関わる部品を変える

こうした処理は、管理者特権が必要になると考えてよいです。

flowchart TB
    accTitle: カーネルドライバという分かりやすい境界
    accDescr: ドライバはカーネル側で動くため、普通のユーザーアプリの設定保存と同列には扱えず、kernel-mode driverのインストールのようなシステムを変更するタスクは標準ユーザーには実行できないことを示す図。
    k1["ドライバの導入"] --> k2["カーネル側で動く部品を システムに入れる"]
    k2 --> k3["システムを変更するタスク"]
    k3 --> k4["標準ユーザーでは 実行できない"]
    k1 -.-> k5["ユーザーアプリの設定保存 とは同列に扱えない"]

図10: カーネルに触るものは、いちばん分かりやすく管理者側の境界にある。

4.5 ファイアウォールや高権限タスクの設定

ファイアウォールも OS のセキュリティ境界の一部です。 Microsoft Learn のファイアウォール設定手順では、単一デバイスで Windows Firewall with Advanced Security を操作するには、そのデバイス上の administrative rights が必要 と明記されています。⁹

また、タスクスケジューラについては、TASK_RUNLEVEL_LUA は最小権限、TASK_RUNLEVEL_HIGHEST は最高権限で実行 と定義されており、schtasks のドキュメントでも ローカルコンピューター上のすべてのタスクを schedule / view / change するには Administrators グループのメンバーである必要がある とされています。¹⁰

まとめると、

Windows Firewall ルールを追加・変更する
特定の処理を最高権限タスクとして登録する
別ユーザーや SYSTEM でジョブを動かす

といった構成は、管理者特権が必要になる側にあります。

flowchart TB
    accTitle: ファイアウォールと高権限タスク
    accDescr: ファイアウォールのルール変更はそのデバイス上のadministrative rightsが必要で、タスクスケジューラの最高権限での実行やすべてのタスクの変更もAdministratorsグループのメンバーであることが前提とされており、どちらも管理者特権が必要になる側にあることを示す図。
    f1["ファイアウォールの ルールを変更する"] --> f2["そのデバイス上の administrative rightsが必要"]
    g1["タスクを最高権限で 登録・実行する"] --> g2["登録も実行も昇格前提"]
    f2 --> h1["OSのセキュリティ境界の 一部として管理者側"]
    g2 --> h1

図11: ファイアウォールも高権限タスクも、OSのセキュリティ境界として管理者側。

5. 実は管理者特権が不要で済むことが多い典型例

「Windows はすぐ管理者を要求する」と見えがちですが、実際には 管理者特権が不要な設計にできる部分 が思いのほか多くあります。

5.1 自分用の設定、キャッシュ、ログ

Microsoft Learn では、互換性のための仮想化に頼るのではなく、アプリは per-user location か、ACL を正しく設定した %alluserprofile% 内の computer location に保存するべき と説明されています。⁷

実務的には、次のように分けると整理しやすいです。

ユーザー固有: %AppData%, %LocalAppData%, HKCU
共有だが実行時に更新される: %ProgramData% + ACL 設計
実行ファイル本体: Program Files などの保護領域

この分離ができていれば、アプリ本体のインストールは管理者でも、普段の利用は非管理者 にできます。

flowchart TB
    accTitle: データの3分離
    accDescr: ユーザー固有のデータはAppDataやHKCUへ、共有だが実行時に更新されるデータはProgramDataとACL設計へ、実行ファイル本体はProgram Filesなどの保護領域へと分離できていれば、インストールは管理者でも普段の利用は非管理者にできることを示す図。
    z0["アプリが扱うもの"] --> z1["ユーザー固有のデータ"]
    z0 --> z2["共有だが実行時に 更新されるデータ"]
    z0 --> z3["実行ファイル本体"]
    z1 --> y1["AppData / HKCU"]
    z2 --> y2["ProgramData + ACL設計"]
    z3 --> y3["Program Filesなど 保護領域"]
    y2 -.-> y4["普段の利用は 非管理者にできる"]

図12: この3分離ができれば、昇格が要るのはインストールの瞬間だけになる。

5.2 per-user インストールと更新

Microsoft の公式ドキュメントでも、per-user 配置の例は普通に出てきます。

たとえば Remote Desktop client のドキュメントでは、per-user インストールは各ユーザープロファイルの LocalAppData 配下へインストールし、ユーザーが管理者権限なしで更新できる と説明されています。¹¹

また OneDrive のドキュメントでは、既定では per-user インストール であり、per-machine インストールは /allusers を付けてコマンドを実行し、その結果 UAC プロンプトが出る とされています。さらに、per-user は %localappdata%、per-machine は Program Files 配下に入ります。¹²

ここから分かるのは、「インストール」という単語だけでは、管理者特権の要否は決まらない ということです。

各ユーザーが自分の領域へ入れるなら、非管理者で済む場合がある
全ユーザー共通の領域へ入れるなら、管理者が要りやすい

大事なのは per-user か per-machine か を先に決めることです。

flowchart TB
    accTitle: インストールという言葉では要否は決まらない
    accDescr: 各ユーザーが自分の領域へ入れるper-userインストールなら非管理者で済む場合があり、全ユーザー共通の領域へ入れるper-machineインストールなら管理者が要りやすいため、インストールという単語だけでは管理者特権の要否は決まらないことを示す図。
    i0{"どちらの入れ方か"}
    i0 -->|"per-user"| i1["各ユーザーが 自分の領域へ入れる"]
    i0 -->|"per-machine"| i2["全ユーザー共通の 領域へ入れる"]
    i1 --> i3["非管理者で 済む場合がある"]
    i2 --> i4["管理者が要りやすい"]

図13: 「インストール=必ず管理者」ではなく、per-userかper-machineかで決まる。

5.3 通常の UI 操作や業務ロジック

逆に言うと、次のような処理は、それ自体では管理者特権を必要としません。

文書や画像を開く
自分のプロファイル配下のファイルを編集する
HTTP 通信や DB 通信を行う
業務ロジックを実行する
画面に結果を表示する
自分用設定を読み書きする

にもかかわらず「アプリ全体を管理者として実行」が必要になっているなら、原因はアプリの本体機能ではなく、一部の周辺処理が保護領域へ触っている ことが多いです。

flowchart TB
    accTitle: 本体機能ではなく周辺処理が原因
    accDescr: 文書を開く、業務ロジックを実行する、自分用設定を読み書きするといった処理はそれ自体では管理者特権を必要とせず、それでもアプリ全体に管理者実行が必要なら、一部の周辺処理が保護領域へ触っていることが原因のことが多いことを示す図。
    m1["文書を開く・通信する・ 業務ロジックを実行する"] --> m2["それ自体は 管理者特権が不要"]
    m3["それでもアプリ全体が 管理者実行を要求"] --> m4["一部の周辺処理が 保護領域へ触っている"]
    m4 -.-> m5["原因は本体機能ではない"]

図14: 本体は普通の処理なのに管理者が要るなら、疑うのは周辺処理の書き先。

6. なぜ「このアプリは管理者で」と言われるのか

6.1 マニフェストで `requireAdministrator` を宣言している

アプリケーションマニフェストでは、requestedExecutionLevel により、必要な権限レベルを宣言できます。Microsoft Learn では、次の 3 つが定義されています。¹³

asInvoker: 起動元プロセスと同じ権限で動く
highestAvailable: 可能な限り高い権限で動く
requireAdministrator: 管理者権限で動く

もしアプリが requireAdministrator になっていれば、起動のたびに昇格が前提 になります。 highestAvailable でも、環境によっては昇格が絡みます。¹³

なので、「なぜ毎回 UAC が出るのか」の一番素直な答えは、そのアプリがそう宣言しているから です。

flowchart TB
    accTitle: requestedExecutionLevelの3つの宣言
    accDescr: アプリケーションマニフェストのrequestedExecutionLevelにはasInvoker・highestAvailable・requireAdministratorの3つがあり、requireAdministratorなら起動のたびに昇格が前提になり、highestAvailableでも環境によっては昇格が絡むことを示す図。
    a1["マニフェストの requestedExecutionLevel"] --> b1["asInvoker"]
    a1 --> b2["highestAvailable"]
    a1 --> b3["requireAdministrator"]
    b1 --> c1["起動元と同じ権限"]
    b2 --> c2["環境によっては 昇格が絡む"]
    b3 --> c3["起動のたびに昇格前提"]

図15: 毎回UACが出る一番素直な理由は、マニフェストの宣言。

6.2 Windows の installer detection に引っかかっている

UAC アーキテクチャの説明では、Windows には installer detection technology があり、多くのインストールプログラムは protected system locations に書くため、昇格が必要になる と説明されています。³

しかもこれは、単純に setup.exe という名前だからではなく、Windows がある程度 ヒューリスティックに「これはインストーラーっぽい」と判定 しています。公式ドキュメントでは、次の条件が挙げられています。³

32-bit 実行ファイル
requestedExecutionLevel 属性がない
UAC 有効の標準ユーザーによる対話プロセス
ファイル名に install、setup、update といった語を含む、など

なので、SetupLauncher.exe や Updater.exe が突然昇格を求めるのは、Windows 側の設計として不思議ではありません。

flowchart TB
    accTitle: installer detectionに当たる条件
    accDescr: Windowsのinstaller detectionは、32-bit実行ファイルでrequestedExecutionLevel属性がなく、UAC有効の標準ユーザーによる対話プロセスで、ファイル名にinstallやsetupやupdateといった語を含むなどの条件からインストーラーっぽいとヒューリスティックに判定し、昇格を求めることを示す図。
    c1["32-bit実行ファイル"] --> e1["インストーラーっぽいと 判定される"]
    c2["requestedExecutionLevel 属性がない"] --> e1
    c3["ファイル名にinstall / setup / updateなどを含む"] --> e1
    e1 --> e2["昇格が求められる"]

図16: 名前と属性の組み合わせだけで、インストーラー扱いされて昇格が要求される。

6.3 旧来アプリが仮想化で「たまたま動いていた」

ここはかなり誤解されやすいです。

Microsoft Learn では、UAC は保護領域へ書こうとする非準拠アプリのために、ファイルとレジストリの仮想化を提供する と説明されています。一方でこれは 短期的な互換性対策であり、長期的な解決策ではない とも明記されています。³⁷

さらに、仮想化には制限があります。

昇格済みアプリには適用されない
32-bit アプリにしか適用されない
requestedExecutionLevel を含むマニフェストがあると無効
アプリは本来、正しい保存先へ書くよう修正するべき

という条件です。³⁷

つまり、昔の 32-bit アプリが「管理者なしでも Program Files に書けていたように見える」ことがありますが、それは 正しく書けていたのではなく、VirtualStore に逃がされていた だけかもしれません。

このため、

64-bit 化した
マニフェストを追加した
ビルド方法を変えた
UAC 準拠を進めた

といったタイミングで、以前は表面化しなかった「保存先の設計ミス」が急に見えることがあります。

flowchart TB
    accTitle: 仮想化で「たまたま動いていた」が表面化する流れ
    accDescr: 保護領域へ書こうとする非準拠の32-bitアプリはファイルとレジストリの仮想化によりVirtualStoreへ逃がされて動いて見えるが、これは短期的な互換性対策であり、64-bit化やマニフェスト追加のタイミングで仮想化が効かなくなり、保存先の設計ミスが急に表面化することを示す図。
    v1["非準拠の32-bitアプリが 保護領域へ書こうとする"] --> v2["仮想化がVirtualStoreへ 逃がす"]
    v2 --> v3["正しく書けていないのに 動いて見える"]
    v3 --> v4["64-bit化やマニフェスト 追加で仮想化が効かなくなる"]
    v4 --> v5["保存先の設計ミスが 急に表面化する"]

図17: 仮想化は暫定策なので、環境が変わった瞬間に設計ミスが見えてくる。

6.4 そもそも実行時に触る場所がよくない

実務では、結局これがいちばん多いです。

設定を EXE の隣へ保存する
ログをインストール先へ吐く
一時ファイルを Program Files 配下へ作る
ユーザーごとの状態を HKLM に書く

こういう構成にすると、アプリ本体は普通の UI なのに、起動に管理者特権が必要 という、かなり扱いにくい形になります。⁴⁶

「その処理が高度だから管理者」ではなく、保存先が悪いから管理者 というケースは、本当に多いです。

6.5 自分のアプリがどれに当たるかを調べる手順

6.1 から 6.4 は「原因の型」ですが、実際の調査では 自分のアプリがどれに当たっているか を確かめる必要があります。順番はこの 2 つで足ります。

手順 1: マニフェストの `requestedExecutionLevel` を見る

まず、そのアプリが自分で昇格を宣言していないかを確認します。EXE に埋め込まれたマニフェストは、Windows SDK の mt.exe で取り出せます。

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 は、実行ファイルに埋め込まれるマニフェストのリソース ID です。取り出した XML の中に、次のような行があるかを見ます。

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

requireAdministrator なら、原因は 6.1 で確定です。asInvoker なら宣言由来ではないので、手順 2 へ進みます。マニフェスト自体が埋め込まれていない場合もあります。これも重要な情報で、requestedExecutionLevel を持たない 32bit の実行ファイルは、6.2 の installer detection と 6.3 の仮想化の両方に当たり得ます。³

手順 2: `VirtualStore` に複製ができていないかを見る

次に、保護領域へ書いたつもりのファイルが、実は仮想化されていないかを見ます。リダイレクト先は決まっています。

dir /s /a "%LocalAppData%\VirtualStore"

ここに自分のアプリの設定ファイルやログが並んでいたら、そのアプリは Program Files に書けていたのではなく、ユーザーごとの複製へ逃がされていた ということです。たとえば C:\Program Files\Contoso\Settings.ini への書き込みは、%LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini へ振り替えられます。³

レジストリ側の仮想化先も同様で、HKEY_LOCAL_MACHINE\Software への書き込みは HKEY_USERS\<ユーザーの SID>_Classes\VirtualStore\Machine\Software へ振り替えられます。現在のユーザーから見るなら、レジストリエディターで HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software を開けば同じものが見えます。⁷

この 2 つを見れば、「管理者権限が必要」の原因が 宣言なのか、保存先なのか がはっきりします。原因が保存先なら、7.3 のとおり置き場所を直すのが本筋で、昇格を足すのは対処になりません。

flowchart TB
    accTitle: 原因を確かめる2手順
    accDescr: まずmt.exeでEXEに埋め込まれたマニフェストを取り出してrequestedExecutionLevelを見て、requireAdministratorなら宣言由来で確定し、asInvokerならVirtualStoreに自分のアプリの複製ができていないかを確認し、複製があれば保存先の問題なので置き場所を直すのが本筋であることを示す図。
    s1["手順1: マニフェストの requestedExecutionLevelを見る"] --> j1{"何が宣言されているか"}
    j1 -->|"requireAdministrator"| r1["原因は宣言で確定"]
    j1 -->|"asInvokerや宣言なし"| s2["手順2: VirtualStoreの 複製を確認する"]
    s2 -->|"複製がある"| r2["原因は保存先"]
    r2 --> r3["置き場所を直すのが本筋 （昇格を足すのは対処でない）"]

図18: 宣言か保存先か、2手順の確認で原因ははっきり分かれる。

7. どう設計すると無駄な昇格を減らせるか

7.1 基本は `asInvoker`

アプリ全体が本当にシステム管理ツールでない限り、基本線は 通常の UI アプリを非昇格で動かす ことです。マニフェストの意味としても、asInvoker は「起動元と同じ権限で動く」という宣言です。¹³

普段の画面操作、業務ロジック、ユーザーごとの設定保存まで全部管理者で動かすと、

攻撃面が広がる
運用説明がしにくい
毎回 UAC が出る
「本当はどの処理に管理者が必要なのか」が見えなくなる

という問題が増えます。Microsoft の UAC 設計ガイドも、不要な昇格をなくし、管理者特権が必要なのは本当に必要なタスクだけにすべき と説明しています。⁴

flowchart TB
    accTitle: 全部を管理者で動かすと増える問題
    accDescr: 普段の画面操作や業務ロジックまで全部管理者で動かすと、攻撃面が広がり、運用説明がしにくくなり、毎回UACが出て、本当はどの処理に管理者が必要なのかが見えなくなるため、基本線は通常のUIアプリを非昇格で動かすことであることを示す図。
    a1["全部を管理者で動かす"] --> b1["攻撃面が広がる"]
    a1 --> b2["毎回UACが出る"]
    b1 --> b3["運用説明がしにくい"]
    b2 --> b4["本当に必要な処理が 見えなくなる"]
    b3 --> c1["基本線はasInvokerで 非昇格に保つ"]
    b4 --> c1

図19: 基本はasInvokerで、昇格は本当に必要なタスクだけに絞る。

7.2 管理者が必要な処理だけ、別の実行単位へ分ける

Microsoft Learn には、管理者特権が必要な処理を持つアプリでも、標準ユーザーアプリとして動かしつつ必要部分だけを分離するモデル が明示されています。¹⁴

代表的には次の 4 つです。

Administrator Broker Model 標準ユーザーの UI アプリ + 管理者 helper EXE
Operating System Service Model 標準ユーザー UI + 常駐 service
Elevated Task Model 標準ユーザー UI + 最高権限のスケジュールタスク
Administrator COM Object Model 標準ユーザー UI + 昇格 COM

ざっくりした使い分けはこうです。

たまにだけ管理者操作 が必要なら helper EXE
常時・無人・頻繁 なら service
短い定型ジョブ なら highest task
既存 COM 前提 なら昇格 COM

Windows アプリでこの設計を具体化する話は、別記事の Windowsアプリで「管理者権限が必要な処理だけ」を分離する具体的な書き方でも詳しく扱っています。

flowchart TB
    accTitle: 4つの分離モデルの使い分け
    accDescr: 標準ユーザーアプリとして動かしつつ管理者処理だけを分離するモデルとして、たまにだけ管理者操作が必要ならAdministrator Broker Modelのhelper EXE、常時・無人・頻繁ならサービス、短い定型ジョブなら最高権限タスク、既存COM前提なら昇格COMという使い分けを示す図。
    q1{"管理者操作の性質は"}
    q1 -->|"たまにだけ"| m1["helper EXE （Broker Model）"]
    q1 -->|"常時・無人・頻繁"| m2["サービス"]
    m1 --> m3["短い定型ジョブなら 最高権限タスク"]
    m2 --> m4["既存COM前提なら 昇格COM"]

図20: 分離モデルは4つあり、管理者操作の頻度と形で選ぶ。

7.3 実行時データの置き場所を正す

保存先の原則は、かなり単純です。

ユーザー固有のデータ は HKCU や %AppData%
ローカル専用キャッシュ は %LocalAppData%
共有だが実行時に変わるデータ は %ProgramData% + ACL
実行ファイル本体 は Program Files

Microsoft Learn でも、アプリは per-user location か、ACL を正しく設定した %alluserprofile%（実体は ProgramData）へ保存すべき と説明されています。⁷

この整理をすると、インストーラーだけ昇格し、実行中アプリは非昇格 にしやすくなります。

flowchart TB
    accTitle: 置き場所を正すと昇格が絞れる
    accDescr: ユーザー固有のデータはHKCUやAppDataへ、ローカル専用キャッシュはLocalAppDataへ、共有だが実行時に変わるデータはProgramDataとACLへ、実行ファイル本体はProgram Filesへという原則で整理すると、インストーラーだけ昇格し実行中アプリは非昇格にしやすくなることを示す図。
    p1["実行時データの置き場所を 原則どおりに整理する"] --> p2["昇格が要るのは 実行ファイルの配置だけになる"]
    p2 --> p3["インストーラーだけ昇格"]
    p2 --> p4["実行中アプリは非昇格"]

図21: 置き場所の整理は、昇格をインストールの瞬間に閉じ込めるための土台。

7.4 per-user と per-machine を先に決める

意外と見落としやすいのがここです。

そのアプリは各ユーザーが自分で入れられるべきか
全ユーザー共通の 1 か所に入れるべきか
更新は誰が責任を持つのか
実行ファイルをユーザープロファイルから動かしてよいのか

この判断が曖昧だと、あとで

インストールだけ管理者
実行も管理者
更新も管理者
一部だけ user context

のように、ぐちゃっとしやすいです。

per-user / per-machine の違いは、単に配布方式の話ではなく、権限設計そのもの です。

flowchart TB
    accTitle: per-user / per-machineを先に決める
    accDescr: 各ユーザーが自分で入れられるべきか、全ユーザー共通の1か所に入れるべきか、更新は誰が責任を持つのかという判断を先にしないと、インストール・実行・更新の権限がばらばらになりやすく、per-userとper-machineの違いは配布方式ではなく権限設計そのものであることを示す図。
    d1["per-user / per-machineを 先に決める"] -->|"決めた場合"| d2["インストール・実行・更新の 権限が揃う"]
    d1 -.->|"曖昧なまま進むと"| d3["一部だけ管理者・一部だけ user contextでぐちゃつく"]
    d2 --> d4["配布方式ではなく 権限設計そのもの"]

図22: per-user / per-machineの判断は、最初に決める権限設計。

8. これからの Windows はどちらへ向かっているか

2026 年 3 月時点で、Windows 11 には Administrator protection (preview) という機能があります。Microsoft Learn では、この機能を 通常時は deprivileged state を保ち、必要なときだけ just-in-time で admin rights を与える ものとして説明しています。⁵

さらに Microsoft は、ソフトウェアのインストール、時刻やレジストリのようなシステム設定の変更、機微データへのアクセス といった管理者特権が必要な操作の前に、明示的な認証を求めると説明しています。⁵

この機能自体はまだ preview で、一般展開も段階的です。⁵

ここで、preview であることの実務上の意味 も押さえておきたいところです。preview 表記が付いている機能は、一般提供までに挙動や設定項目が変わり得ますし、そもそもすべての環境で有効にできるとは限りません。したがって、現時点では次のような使い方は避けたほうが安全です。

本番の標準構成として全社に展開する
この機能が有効である前提にして、アプリ側の昇格設計を省略する
顧客環境での動作要件として、この機能を必須にする

現実的な立ち位置は、検証環境で挙動を確認しておき、「将来こちらへ寄る」という前提で設計だけ合わせておく ことです。逆に言えば、いま asInvoker を基本にして昇格を最小化しておけば、この機能が一般提供になったときに慌てずに済みます。

flowchart TB
    accTitle: preview機能への現実的な立ち位置
    accDescr: preview表記の機能は一般提供までに挙動や設定が変わり得るため、本番の標準構成として展開したり、有効である前提で昇格設計を省略したり、顧客環境の動作要件にしたりするのは避け、検証環境で挙動を確認しつつ将来こちらへ寄る前提で設計だけ合わせておくのが現実的であることを示す図。
    p1["Administrator protection はpreview"] -.-> p2["本番標準構成での全社展開 や必須要件化は避ける"]
    p1 --> p3["検証環境で挙動を 確認しておく"]
    p3 --> p4["将来こちらへ寄る前提で 設計だけ合わせる"]
    p4 --> p5["asInvoker基本で昇格を 最小化しておけば慌てない"]

図23: previewの機能は前提にせず、設計の向きだけ合わせておく。

ただ、方向性としてはかなり明確です。

常時管理者トークンを持ちっぱなしにしない
必要な瞬間だけ昇格する
昇格したセッションを分離する
「いつ、どのアプリが、なぜ管理者になったか」をより明確にする

つまり、「とりあえず全部管理者で動かす」設計は、今後ますます相性が悪くなる と見てよいです。

flowchart TB
    accTitle: Windowsが向かっている方向
    accDescr: 常時管理者トークンを持ちっぱなしにせず、必要な瞬間だけ昇格し、昇格したセッションを分離し、いつどのアプリがなぜ管理者になったかをより明確にするという方向にWindowsは寄っており、とりあえず全部管理者で動かす設計は今後ますます相性が悪くなることを示す図。
    w1["常時管理者トークンを 持ちっぱなしにしない"] --> w2["必要な瞬間だけ昇格する"]
    w2 --> w3["昇格したセッションを 分離する"]
    w3 --> w4["いつ・どのアプリが・なぜ 管理者かを明確にする"]
    w4 -.-> w5["全部管理者で動かす設計は 相性が悪くなっていく"]

図24: 方向性は明確で、昇格は「必要な瞬間だけ・明示的に」へ寄っている。

9. よくある誤解

9.1 「自分は管理者ユーザーだから、UAC は出ないはず」

出ます。 UAC 有効時は、Administrators グループのメンバーでも通常プロセスは非昇格で動き、必要時だけ昇格します。⁶²

9.2 「インストールなら必ず管理者」

必ずではありません。 %LocalAppData% への per-user インストールのように、管理者特権なしで配れる設計はあります。¹¹¹²

9.3 「Program Files に置くのだから、設定もそこに保存してよい」

だめです。実行ファイルの配置先と、実行時に変わるデータの保存先は分けるべきです。Microsoft も、Program Files や HKLM への実行時書き込みを、不要な昇格の典型例として挙げています。⁴⁷

9.4 「管理者として実行さえすれば、設計問題は全部解決する」

解決しません。一時的に動くことはあっても、攻撃面、運用性、配布、サポートのしやすさは悪化しやすいです。しかも、同じプロセスの中の一部だけを都合よく昇格することもできません。²¹⁴

9.5 「昔は動いていたから、今も正しい」

そうとは限りません。旧来の 32-bit アプリが仮想化で「たまたま動いていた」だけなら、64-bit 化やマニフェスト追加で問題が表面化します。仮想化は互換性のための暫定策で、長期解ではありません。³⁷

10. まとめ

Windows の管理者特権が必要かどうかは、ひとことで言えば、「どこへ何を変えにいくのか」 で決まります。

自分のための変更 なら、標準ユーザーで済みやすい
全ユーザー・マシン全体の変更 なら、管理者が必要になりやすい
OS の保護領域やセキュリティ境界 に触るなら、管理者特権が必要

そして実務で本当に大事なのは、本当に管理者特権が必要な処理 と、単に保存先の都合で管理者が必要になってしまっている処理 を分けることです。

特に Windows アプリ開発では、次の線がかなり有効です。

UI は非昇格を基本にする
管理者処理は別 EXE / service / task に切る
実行時データは AppData / HKCU / ProgramData 側へ寄せる
per-user / per-machine を最初に決める

flowchart TB
    accTitle: Windowsアプリ開発で有効な線引き
    accDescr: UIは非昇格を基本にし、管理者処理は別EXEやサービスやタスクに切り、実行時データはAppDataやHKCUやProgramData側へ寄せ、per-userかper-machineかを最初に決めるという、実務で有効な線引きを示す図。
    g1["UIは非昇格を基本にする"] --> g2["管理者処理は別EXE / サービス / タスクに切る"]
    g2 --> g3["実行時データはAppData / HKCU / ProgramDataへ寄せる"]
    g3 --> g4["per-user / per-machineを 最初に決める"]

図25: この4本の線を最初に引いておくと、UACも配布も設計も見通しがよくなる。

「管理者特権が必要か」は、アプリが立派かどうかの話ではありません。 OS のどの境界に触っているか の話です。

この見方を最初に持っておくと、UAC の挙動も、インストール方式の選定も、アプリ設計も、ぐっと見通しがよくなります。

11. 関連記事

12. 参考資料

Microsoft Learn, User Account Control. UAC は OS への不正変更を防ぐためのセキュリティ機能で、管理者レベルのアクセス許可が必要な変更時に通知します。 ↩ ↩² ↩³
Microsoft Learn, How User Account Control works. 管理者アクセストークンを必要とするアプリは同意プロンプトの対象であり、子プロセスは親のトークンを継承します。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷
Microsoft Learn, UAC Architecture. 保護領域、installer detection、仮想化、requestedExecutionLevel の関係について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Microsoft Learn, User Account Control (Design basics). 不要な昇格をなくし、Program Files / Windows / HKLM / HKCR への実行時書き込みを避けるべきと説明しています。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, Administrator protection (preview). Windows 11 における least privilege / just-in-time elevation の方向性について。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, User Account Control for Game Developers. 標準ユーザーは Program Files や HKEY_LOCAL_MACHINE に書けず、カーネルドライバ導入のような system-changing task も行えません。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, Registry Virtualization. 仮想化は互換性のための暫定策であり、アプリは per-user か ACL を正しく設定した %alluserprofile% 側へ保存すべきとされています。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹
Microsoft Learn, Service Security and Access Rights. CreateService や ChangeServiceConfig に必要なアクセス権、および管理者権限との関係について。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Configure rules with group policy. 単一デバイスで Windows Firewall with Advanced Security を操作するには administrative rights が必要です。 ↩ ↩²
Microsoft Learn, Principal.RunLevel property, TASK_RUNLEVEL_TYPE enumeration, schtasks change. タスクの最小権限 / 最高権限、およびタスク変更に必要な権限について。 ↩ ↩²
Microsoft Learn, Install the Remote Desktop client for Windows on a per-user basis with Intune or Configuration Manager. per-user インストールでは各ユーザーの LocalAppData 配下へ入り、管理者権限なしで更新できます。 ↩ ↩² ↩³
Microsoft Learn, Install the sync app per-machine (Windows). OneDrive は既定では per-user で、/allusers による per-machine インストールでは UAC プロンプトが発生し、Program Files 配下へ入ります。 ↩ ↩² ↩³
Microsoft Learn, Application manifests. requestedExecutionLevel の asInvoker / highestAvailable / requireAdministrator について。 ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Developing Applications that Require Administrator Privilege. Elevated Task / Service / Administrator Broker / Administrator COM の分離モデルを整理しています。 ↩ ↩² ↩³

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

管理者権限が必要な処理を設計上どこで分離するかは、Windows アプリの運用性と保守性を大きく左右するため、Windowsアプリ開発と相性がよいテーマです。

サービスを見るお問い合わせ

技術相談・設計レビュー

UAC、per-user/per-machine 配布、保護領域アクセスの境界をどこで切るかは実装前の設計判断が重要で、技術相談・設計レビューとして整理する価値があります。