Windowsユーザープロファイル入門 - AppDataとNTUSER.DAT

この記事は、Windows を管理する情シス、端末展開担当、Windows アプリ開発者向けに、一般論としてまとめています。 図は概念図です。Mermaid 対応の Markdown 環境では図として表示されます。

内容は 2026 年 4 月時点で確認できる Microsoft の公式情報を前提にしています。[1][4][7][10][13][14]

読み方の目安

長い記事なので、立場ごとの入口を先に置いておきます。

Windows の相談で、「プロファイル」という言葉はかなり広く使われます。

• C:\Users\ユーザー名 の中身は何なのか
• %AppData% と %LocalAppData% はどう使い分けるべきか
• ドメイン環境のローミングプロファイルとは何か
• Mandatory プロファイルと Temporary プロファイルは何が違うのか
• 共有 PC、RDS、VDI、Azure Virtual Desktop では何を選ぶべきか
• プロファイルが壊れたとき、どこから見ればよいのか

このあたりは、アカウント、フォルダー、レジストリ、同期方式、運用ポリシー が一気に混ざるので、話がすぐずれます。

この記事では、まず Windows のユーザープロファイルを 1 枚の設計図として見る視点 を置き、そのうえで AppData の使い分け、ローミング、Mandatory、Temporary、FSLogix、トラブル時の見方 までを順番に整理します。

1. まず結論

細かい話に入る前に、実務上の結論を先に並べておきます。

• Windows のユーザープロファイルは、単なる C:\Users\ユーザー名 フォルダーではありません。ファイル群 + ユーザー レジストリ ハイブ (NTUSER.DAT) のセットです。[1]
• 普通のローカル PC では、既定で ローカルプロファイル が作られます。初回サインイン時には C:\Users\Default を土台にして新しいプロファイル が作られます。[11][12]
• アプリの保存先は雑に決めないほうがよく、ユーザーごとに持ち歩きたい設定は %APPDATA%、その PC 専用のキャッシュや一時的な状態は %LOCALAPPDATA% という整理が基本です。[2][3]
• ローミングプロファイル は「プロファイル全体を共有へ寄せる」仕組み、Folder Redirection は「Documents など既知フォルダーだけを別場所へ寄せる」仕組みで、同じではありません。[4][5]
• Mandatory プロファイル は「使わせるが保存させない」ための読み取り専用プロファイルです。Temporary プロファイル はエラー時の緊急避難で、毎回消える前提です。[7][8][9]
• OS 世代をまたぐローミングプロファイルは要注意です。Windows 10 / Server 2016 以降とそれ以前は非互換 があり、プロファイル バージョンを分けて扱う前提で考えるべきです。[6]
• RDS / VDI / Azure Virtual Desktop では、従来のローミングプロファイルだけで押し切るより、FSLogix プロファイル コンテナー を第一候補で考える場面がかなり多いです。Microsoft も Azure Virtual Desktop では FSLogix を推奨しています。[13][14]
• トラブル時は、いきなり C:\Users を触る前に、Application ログ、User Profile Service の Operational / Diagnostic ログ、共有パス、NTUSER.DAT / USRCLASS.DAT の属性と権限 を見るほうが筋が良いです。[10][11][16]

要するに、Windows プロファイルの話は 「どこに何を置き、どこまで持ち回り、失敗時にどう戻すか」 に尽きます。

1.1 この記事で使う略語

冒頭からいきなり並んでいる略語を、ここで展開しておきます。

この記事の知識マップ

Windowsのユーザープロファイルは、Desktop・AppDataなどのファイル群とNTUSER.DATというユーザーレジストリハイブの2層から成り、初回サインイン時にはC:\Users\Defaultを土台に作成される。AppDataはRoaming・Local・LocalLowに分かれ、持ち回りたい設定とPC固有のキャッシュ、低整合性プロセス専用領域とで置き場所を使い分ける。ローカルプロファイルを基本としつつ、複数PCで設定を共有したいときはローミングプロファイル、文書だけを中央管理したいときはFolder Redirectionを使い、RDS/VDI/Azure Virtual DesktopではFSLogixプロファイルコンテナーが推奨される。教育端末やキオスクにはMandatoryプロファイルが向き、NTUSER.DATの権限問題や長いパスによるイベント1509は一時プロファイル化の典型的な原因になる。

flowchart LR
    accTitle: Windowsユーザープロファイルの知識マップ
    accDescr: ユーザープロファイルがNTUSER.DATとAppDataのRoaming/Local/LocalLowから構成され、ローカル・ローミング・Mandatory・Temporary・FSLogixという方式の違いや、長いパスによるイベント1509や一時プロファイル化とどうつながるかを示す図。
    windows_user_profile["ユーザープロファイル"]
    ntuser_dat["NTUSER.DAT"]
    default_profile["既定プロファイル(Default)"]
    copyprofile["CopyProfile"]
    roaming_appdata["%APPDATA%(Roaming)"]
    local_appdata["%LOCALAPPDATA%"]
    appdata_locallow["AppData\LocalLow"]
    low_integrity_level["低整合性レベル"]
    local_user_profile["ローカルプロファイル"]
    roaming_user_profile["ローミングプロファイル"]
    mandatory_profile["Mandatoryプロファイル"]
    temporary_profile["Temporaryプロファイル"]
    fslogix_profile_container["FSLogixプロファイルコンテナー"]
    profile_version_incompatibility["ローミングプロファイルのOS世代間非互換"]
    folder_redirection["Folder Redirection"]
    azure_virtual_desktop["Azure Virtual Desktop"]
    shared_pc_mode["共有/ゲストPCの構成"]
    profile_auto_cleanup_policy["古いプロファイルの自動削除ポリシー"]
    group_policy["グループポリシー"]
    event_1509["イベントID 1509(長いパスでのプロファイル読み込み失敗)"]
    user_profile_service_log["User Profile Serviceのログ"]
    windows_user_profile -->|"利用する"| ntuser_dat
    windows_user_profile -.->|"前提とする"| default_profile
    default_profile -->|"で構成できる"| copyprofile
    windows_user_profile -->|"利用する"| roaming_appdata
    windows_user_profile -->|"利用する"| local_appdata
    windows_user_profile -->|"利用する"| appdata_locallow
    low_integrity_level -->|"利用する"| appdata_locallow
    windows_user_profile -.->|"利用する"| local_user_profile
    windows_user_profile -.->|"利用する"| roaming_user_profile
    windows_user_profile -.->|"利用する"| mandatory_profile
    windows_user_profile -.->|"利用する"| temporary_profile
    windows_user_profile -.->|"利用する"| fslogix_profile_container
    roaming_user_profile -.->|"原因になり得る"| profile_version_incompatibility
    mandatory_profile -->|"利用する"| ntuser_dat
    windows_user_profile -.->|"利用する"| folder_redirection
    fslogix_profile_container -->|"推奨される対応"| azure_virtual_desktop
    roaming_user_profile -.->|"用いるのは非推奨"| azure_virtual_desktop
    windows_user_profile -.->|"利用する"| shared_pc_mode
    shared_pc_mode -.->|"利用する"| profile_auto_cleanup_policy
    profile_auto_cleanup_policy -->|"で構成できる"| group_policy
    roaming_user_profile -.->|"原因になり得る"| event_1509
    event_1509 -.->|"原因になり得る"| temporary_profile
    temporary_profile -->|"で確認できる"| user_profile_service_log
    ntuser_dat -.->|"原因になり得る"| temporary_profile

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

2. そもそも Windows の「ユーザープロファイル」とは何か

最初に、アカウント と プロファイル を分けて考えると楽になります。

flowchart LR
    A[ユーザー アカウント<br/>だれがサインインするか] --> B[ユーザープロファイル<br/>その人の設定とデータ]
    C[端末 / OS] --> B
    B --> D[デスクトップ設定]
    B --> E[AppData]
    B --> F[Documents / Desktop など]
    B --> G[HKCU に見える設定]

• アカウント は、だれかを識別するものです
• プロファイル は、その人の作業環境の実体です
• 端末 は、そのプロファイルを読み込んで使う場所です

Microsoft Learn でも、ユーザープロファイルは ファイルシステム上のプロファイル フォルダー群 と レジストリ ハイブ NTUSER.DAT を含み、ログオン時にこのハイブが読み込まれて HKEY_CURRENT_USER として使われると説明されています。[1]

2.1 「フォルダーだけ」ではなく「レジストリも含む」

ここが大事なところです。

flowchart TD
    A[サインイン] --> B[プロファイル フォルダーを特定]
    B --> C[NTUSER.DAT を読み込む]
    C --> D[HKCU として利用]
    B --> E[Desktop / Documents / AppData を準備]
    D --> F[ユーザー設定が有効になる]
    E --> F

つまり、C:\Users\ユーザー名 を見ているだけでは、まだ半分です。

Windows プロファイルには大きく次の 2 層があります。

1. ファイル層 Desktop、Documents、Downloads、AppData など
2. レジストリ層 NTUSER.DAT が読み込まれた HKCU

プロファイル破損の話でややこしいのは、フォルダー側だけ壊れる場合 と レジストリ ハイブ側で問題が出る場合 があるからです。[1][11]

2.2 初回サインインでは Default が土台になる

新しいユーザーがその PC に初めてサインインするとき、Windows は C:\Users\Default をもとにローカルプロファイルを作成 します。[11]

flowchart LR
    A[C:\Users\Default] --> B[初回サインイン]
    B --> C[C:\Users\ユーザー名 を生成]
    C --> D[NTUSER.DAT を読み込む]
    D --> E[そのユーザー専用の環境になる]

イメージ展開やキッティングの文脈でここを雑に扱うと、あとでかなりつらくなります。

Microsoft は、既定プロファイルのカスタマイズについて、サポートされた方法は CopyProfile を使う方法 だと説明しています。手作業コピーや昔ながらの雑な複製は、余計な情報を持ち込み、アプリやシステム安定性に問題を起こすことがあります。[12]

3. C:\Users\ユーザー名 の見方

ユーザープロファイルをフォルダー側から見ると、おおまかにはこういう構造です。

flowchart TD
    A["C:\Users\ユーザー名"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

実務で最初に見る場所は、だいたいこのあたりです。

3.1 AppData を 3 つに分けて考える

Windows アプリ開発やトラブル調査で、一番混ざりやすいのがここです。

Microsoft のガイドでは、アプリ固有データには FOLDERID_RoamingAppData（Roaming AppData） を、一時ファイルや他のコンピューターで使わないデータには FOLDERID_LocalAppData を使うよう案内しています。[2]

また、Known Folders の定義では、既定パスは次のように整理されています。[3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[持ち回りたい設定]
    B --> B2[小さめのユーザー状態]

    C --> C1[キャッシュ]
    C --> C2[再生成できるデータ]
    C --> C3[その PC 固有の状態]

    D --> D1[低整合性プロセスが書ける領域]

LocalLow は「使わない場所」ではなく「権限が低いアプリの置き場」

3 つのうち LocalLow だけ説明が短くなりがちですが、これは用途が特殊なだけで、存在理由ははっきりしています。

Windows のプロセスには 整合性レベル（integrity level） という権限区分があり、低整合性で動くプロセスは、AppData\Roaming や AppData\Local、HKCU の大半へ書き込めません。そのままでは何も保存できないので、低整合性でも書ける場所 が用意されています。それが %USERPROFILE%\AppData\LocalLow と、レジストリ側の HKEY_CURRENT_USER\Software\AppDataLow です。[19]

つまり整理すると、こうなります。

代表例は、ブラウザーのようにインターネット上のコンテンツを直接扱う部分を、あえて低い権限へ落として動かす作りのアプリです。「万一そのプロセスが乗っ取られても、被害範囲を LocalLow の中に閉じ込める」という設計になっています。

アプリ開発側から見た結論はシンプルです。

• 自分のアプリを低整合性で動かしていないなら、LocalLow を使う理由はありません。 Local を使ってください。
• 逆に、LocalLow に見慣れないフォルダーが増えていたら、そこに書いているのは 低整合性で動いている何か です。容量調査のときに手掛かりになります。

実務での使い分けはこう考える

ProgramData は、Microsoft の既知フォルダー定義でも すべてのユーザー向けのアプリケーション データ とされ、ローミングされない共有データ向けです。[3]

ここで一番避けたいのは、ユーザーごとの実行時データを Program Files に置く ことです。 プロファイルの整理と権限設計が一気に崩れやすくなります。

3.2 Public と Default は役割が違う

ここも混ざりやすいです。

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[各ユーザー]

    B --> B1[新規プロファイル作成の種]
    C --> C1[全ユーザーから見える共有物]
    D --> D1[個別ユーザーの実体]

• Default は、新規プロファイルを作るためのテンプレート
• Public は、全ユーザーに見せる共有領域
• 各ユーザー フォルダー は、その人固有の実体

この 3 つは、似て見えて役割がまったく違います。

4. プロファイルの種類を整理する

「プロファイル」と一口に言っても、運用上は少なくとも次の種類があります。

flowchart TD
    A[Windows のプロファイル] --> B[ローカル プロファイル]
    A --> C[ローミング プロファイル]
    A --> D[Mandatory プロファイル]
    A --> E[Temporary プロファイル]
    A --> F[FSLogix プロファイル コンテナー]

4.1 ローカルプロファイル

普通の PC では、既定でこれです。

• その PC のローカル ディスク上に作られる
• 他の PC に自動では持ち回らない
• 単独 PC では一番シンプル

Microsoft も、既定では Windows は ローカルユーザープロファイル を作ると説明しています。[14]

4.2 ローミングプロファイル

Microsoft Learn では、ローミングユーザープロファイルはサーバー共有に保存され、複数コンピューターで同じ OS / アプリ設定を受け取れるようにする仕組み とされています。[4][5]

flowchart LR
    A[共有サーバー上のプロファイル] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

ただし、実務では次の注意点があります。

• サインイン / サインアウト時のコピーや同期が重くなりやすい
• AppData\Local に大きなデータを抱えるとつらい
• OS バージョン差分の問題を受けやすい
• 共有パスやネットワーク品質の影響を強く受ける

4.3 Mandatory プロファイル

Mandatory プロファイルは、管理者が作る「保存されないローミングプロファイル」 です。[7][8]

Microsoft の説明では、Mandatory プロファイルでは利用者がセッション中に変更しても、通常のローミングプロファイルのようには保存されません。[7]

さらに Win32 のドキュメントでは、

• NTUSER.DAT を NTUSER.MAN にリネームすると Mandatory になる
• プロファイル パスのフォルダー名末尾を .man にすると Super-mandatory になる

と説明されています。[8]

flowchart LR
    A[管理者が用意したプロファイル] --> B[ユーザーがサインイン]
    B --> C[利用中は変更できる]
    C --> D[サインアウト]
    D --> E[変更は保存しない]

たとえば、こんな用途に向いています。

• 教育端末
• 受付端末
• キオスク
• 毎回きれいな状態に戻したい共有端末

4.4 Temporary プロファイル

Temporary プロファイルは、設計として選ぶものではなく、エラーで本来のプロファイルを読み込めないときに出る退避先 です。[9]

Microsoft Learn では、エラー条件で本来のプロファイルを読み込めない場合に Temporary profile が発行され、セッション終了時に削除され、変更は失われると説明されています。[9]

flowchart TD
    A[通常プロファイル読み込み開始] --> B{読み込めるか}
    B -->|Yes| C[通常ログオン]
    B -->|No| D[Temporary プロファイルでログオン]
    D --> E[作業はできる]
    E --> F[サインアウトで変更消失]

つまり、Temporary プロファイルで動いている状態は、それ自体が異常のサイン です。

4.5 FSLogix プロファイル コンテナー

FSLogix は、Microsoft Learn では Windows のユーザープロファイル体験を仮想デスクトップ環境で一貫させる仕組み と説明されています。[13]

FSLogix プロファイル コンテナーは、ユーザープロファイル全体を VHD / VHDX として持ち、サインイン時にそれをアタッチしてネイティブなプロファイルのように見せる 方式です。[13][14]

flowchart LR
    A[VHD / VHDX 上のプロファイル] --> B[サインイン時にアタッチ]
    B --> C[セッション ホスト上で C:\Users\ユーザー として見える]
    C --> D[サインアウトでデタッチ]

Azure Virtual Desktop では、Microsoft は FSLogix profile containers の利用を推奨 しています。[14]

5. ローミングプロファイル、Folder Redirection、FSLogix は何が違うか

この 3 つは、同じ話として語られがちですが、役割が違います。

flowchart TD
    A[ユーザーの状態を持ち回る] --> B[ローミング プロファイル]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[プロファイル全体を共有へ]
    C --> C1[既知フォルダーだけを別場所へ]
    D --> D1[VHD/VHDX をアタッチ]

Microsoft Learn の整理に合わせると、違いはこう見ると分かりやすいです。[4][5][14]

5.1 Folder Redirection は「既知フォルダーだけ」寄せる

Microsoft Learn では、Folder Redirection は known folder のパスを別の場所へ向ける 仕組みです。[4]

たとえば Documents をファイル共有へ寄せると、利用者はローカルと同じように見えつつ、実体は別場所にあります。[4]

flowchart LR
    A[Documents] --> B[実体はファイル共有]
    C[Desktop] --> D[必要なら別設定]
    E[AppData] --> F[そのままか別方式]

つまり、Folder Redirection は プロファイル全体の代替ではなく、フォルダー単位の配置換え です。

5.2 ローミングプロファイルは OS 世代をまたいで雑に混ぜない

Microsoft は、Windows 10 / Server 2016 以降のローミングプロファイルは、それ以前の Windows と非互換 だと説明しています。[6]

flowchart LR
    A[Windows 7 / 8.1 系] -.混在注意.-> B[同じ共有]
    C[Windows 10 / Server 2016 以降] -.混在注意.-> B
    B --> D[不整合 / スタートメニュー異常 / タスクバー異常の原因]

ここで大事なのは、

• OS 世代ごとにプロファイル バージョンを分ける
• 「同じユーザーだから同じフォルダーでよい」と考えない
• 端末展開や更改では、プロファイルの互換性 を移行計画に入れる

という点です。[6]

6. 開発者・運用担当が先に決めるべき保存場所

プロファイルの話は、結局ここに戻ってきます。 何をどこへ置くか です。

flowchart TD
    A[保存したいデータ] --> B{ユーザーが作る成果物か}
    B -->|Yes| C[Documents など]
    B -->|No| D{その PC 固有か}
    D -->|Yes| E[%LOCALAPPDATA%]
    D -->|No| F{ユーザーごとの設定か}
    F -->|Yes| G[%APPDATA%]
    F -->|No| H{全ユーザー共有の可変データか}
    H -->|Yes| I[ProgramData + ACL]
    H -->|No| J[配置先を再検討]

6.1 ユーザーが作るファイルとアプリ内部状態を分ける

ここを混ぜると、バックアップも移行も壊れやすくなります。

• ユーザーが意識して扱う成果物 Documents、Pictures、業務用保存フォルダー
• アプリ内部の状態 設定、キャッシュ、サムネイル、セッション情報、ワークファイル

前者は業務データ、後者はアプリ都合です。 同じ「ファイル」でも扱いは分けたほうがよいです。

6.2 %APPDATA% に置くもの

ここに置くのは、だいたいこういうものです。

• 小さめの設定
• ユーザーごとのプリファレンス
• 複数端末で同じ見え方にしたい状態
• プロファイルと一緒に持ち回ってもよいもの

Fast User Switching のドキュメントでも、アプリ固有データの置き場として FOLDERID_RoamingAppData が案内されています。[2]

6.3 %LOCALAPPDATA% に置くもの

こちらに寄せたいのは、再生成や持ち回りの観点でローカルに閉じるべきものです。

• 再生成できるキャッシュ
• ローカルだけで意味がある状態
• 大きいワークファイル
• パフォーマンス重視で持ち回らせたくないもの

Known Folders の定義でも、LocalAppData は %USERPROFILE%\AppData\Local です。[3]

6.4 ProgramData に置くもの

全ユーザー共通だが、実行中に変わるデータ は ProgramData 側が候補です。[3]

たとえば、

• 共有辞書
• 全ユーザー共通の定義ファイル
• サービスと複数ユーザーが共有する可変データ

ただし、ここは ACL 設計込み で考える必要があります。 「共有だからとりあえず ProgramData」ではなく、だれが読み、だれが書くか を決めることが大事です。

6.5 既定プロファイルを作り込みたいとき

イメージ展開で「新規ユーザー全員に同じ初期設定を入れたい」ことは普通にあります。 このときは、Default を雑に触るのではなく、Microsoft がサポートしている CopyProfile ベースの方法で組む のが安全です。[12]

flowchart LR
    A[管理者アカウントで初期設定] --> B[Sysprep + CopyProfile]
    B --> C[Default profile に反映]
    C --> D[以後の新規ユーザーに適用]

「ある PC の C:\Users\A を別 PC の Default に手でコピーする」といったやり方は、見た目は早くても、後で壊しやすいです。[12]

7. 壊れた、一時プロファイルになった、同期しないときの見方

ここは現場で一番困るところです。 しかも、症状の見え方が似ているので、切り分けを雑にすると深追いしやすいです。

7.1 まず症状を 3 つに分ける

flowchart TD
    A[プロファイル問題っぽい] --> B{ログオンできるか}
    B -->|Yes| C{見た目が初期化されたか}
    B -->|No| D[読み込み失敗系]
    C -->|Yes| E[Temporary / 破損 / 別プロファイル]
    C -->|No| F{一部だけ設定が戻るか}
    F -->|Yes| G[ローミング / リダイレクト / 同期系]
    F -->|No| H[アプリ個別問題の可能性]

大きく分けると、次の 3 系統です。

1. ログオン時に失敗する
2. ログオンはできるが、初期化されたように見える
3. 一部だけ同期されない

7.2 まず見るべきログ

Microsoft Learn では、プロファイル問題の調査では次の順に見るよう案内されています。[10]

1. Application ログ
2. User Profile Service の Operational ログ
3. 必要なら Diagnostic ログ
4. さらに必要なら ETL トレース

具体的なパスは以下のとおりです。[10]

• Event Viewer Applications and Services Logs > Microsoft > Windows > User Profile Service > Operational
• より詳細を見る場合 ... > User Profile Service > Diagnostic

日本語版 Windows のイベント ビューアーでは、左のツリーが アプリケーションとサービス ログ > Microsoft > Windows > User Profile Service > Operational になります。プロバイダー名から下は英語表記のままです。

flowchart LR
    A[Application ログ] --> B[Operational ログ]
    B --> C[Diagnostic ログ]
    C --> D[ETL トレース]

現場では、最初からレジストリ修復やフォルダー削除に入るより、ログで「読み込み失敗」「コピー失敗」「アクセス拒否」「長いパス」「共有に書けない」などの方向性をつかむ ほうが安全です。

3 つのログは「別の場所」にあります

ここが最初に迷うところなので、先に整理しておきます。[10]

Diagnostic ログは、そのままではツリーに出てきません。イベント ビューアーの 操作ウィンドウ > 表示 > 分析ログとデバッグ ログを表示する をオンにしてから Diagnostic を選び、ログの有効化 を実行します。調査が終わったら、必ず無効へ戻してください。詳細すぎるログなので、出しっぱなしにする種類のものではありません。[10]

GUI を開かずに同じものを見る

再現性を上げたいときや、リモートの端末を調べるときは、コマンドで取るほうが確実です。イベント ビューアーの画面を人づてに説明するより、このコマンドを実行して結果を送ってください と言えるようにしておくと早く済みます。

# 1) Application ログから User Profile Service のイベントだけを新しい順に見る
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) Operational ログを直接見る
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) 長いパス起因の Event ID 1509 だけを絞り込む
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

ここで 1 つ罠があります。Application ログ側のソース名は Microsoft-Windows-User Profiles Service（Profiles と複数形）、Operational ログのチャネル名は Microsoft-Windows-User Profile Service/Operational（Profile と単数形） です。コピー&ペーストで動かないときは、たいていここです。

Event ID 1509 は Operational ログではなく Application ログ に出ます。レベルは警告で、本文は「Windows はファイル \\サーバー\共有\... を C:\Users\... へコピーできません」という形式のメッセージのあとに、DETAIL - The filename or extension is too long. が続きます。この最後の 1 行が、パス長が原因だと示す決め手です。[16]

もう 1 つ、実務で知っておくと時間を節約できるものがあります。User Profile Service のイベント 1530「レジストリ ファイルが他のアプリケーションまたはサービスによってまだ使用されています」は、無視して構わない と Microsoft が明記しています。[10] これを追いかけると空振りします。

7.3 よくある原因

NTUSER.DAT / USRCLASS.DAT の属性や権限

Microsoft は、NTUSER.DAT や USRCLASS.DAT が Read-only になっている、または必要なアクセス権がないと、プロファイル読み込みに失敗しうると説明しています。[11]

地味ですが、見落とすと長引く原因です。

flowchart LR
    A[プロファイル読み込み] --> B{DAT ファイルへアクセスできるか}
    B -->|No| C[ログオン失敗 / 初期デスクトップ / Temporary]
    B -->|Yes| D[通常読み込み]

ローミング コピー時の長いパス

Microsoft の KB では、共有パス側のサーバー名や共有名が長く、コピー先パス全体が長くなりすぎることで、Event ID 1509 とともに一時プロファイルへ落ちる例が説明されています。[16]

単純なパス長の制約に見えて、実際には ローミング先の設計そのもの が原因になっていることがあるわけです。

不完全な削除で残ったレジストリ / フォルダー情報

Microsoft には、レジストリと C:\Users に残った孤立情報を掃除して TEMP プロファイルを防ぐ ためのサンプルスクリプト記事があります。[15]

ここから分かるのは、フォルダーだけ消して終わりではない ということです。

flowchart LR
    A[古いプロファイルを雑に削除] --> B[レジストリ情報が残る]
    B --> C[次回ログオンで不整合]
    C --> D[TEMP プロファイルや追加フォルダーの原因]

7.4 まず何を確認するか

8. どの方式を選ぶべきか

ここは「正解が 1 つ」ではありません。 利用形態で変わります。

flowchart TD
    A[利用形態] --> B[個人専用 PC]
    A --> C[ドメイン参加の業務 PC]
    A --> D[共有 PC / 教育端末]
    A --> E[RDS / VDI / AVD]

    B --> B1[ローカル主体]
    C --> C1[必要に応じて Folder Redirection / ローミング]
    D --> D1[Mandatory / Shared PC / cleanup]
    E --> E1[FSLogix 第一候補]

8.1 個人専用 PC

基本は ローカルプロファイル で十分です。

• ユーザー設定は AppData
• 成果物は Documents
• 必要なら OneDrive など別レイヤーで文書同期

この構成は一番シンプルです。

8.2 ドメイン参加の業務 PC

要件次第で次を組み合わせます。

• 文章データを中央管理したい → Folder Redirection
• 複数 PC で同じ設定も持たせたい → ローミングプロファイル
• OS 混在や大型プロファイルがある → 慎重設計、または方式見直し

Microsoft Learn でも、Folder Redirection と Roaming User Profiles は中央集約、オフライン利用、バックアップ容易化などに役立つとされています。[4]

8.3 共有 PC / 教育端末 / キオスク

この用途では、「個人最適化を残す」より 毎回きれいに戻す が重要です。

候補はこの 3 つです。

• Mandatory プロファイル
• Shared PC モード
• 古いプロファイル自動削除ポリシー

Microsoft には、Delete user profiles older than a specified number of days on system restart というポリシーがあり、指定日数使われていないプロファイルを再起動時に削除できます。[17]

また Shared PC のガイドでも、共有端末ではアカウント / プロファイルの自動管理や削除を組み合わせる考え方が示されています。[18]

8.4 RDS / VDI / Azure Virtual Desktop

ここでは、従来のローミングプロファイルだけでは厳しい場面が多いです。

Microsoft は Azure Virtual Desktop で FSLogix profile containers を推奨し、VHDX / VHD をサインイン時にアタッチして、ネイティブなユーザープロファイルのように扱うと説明しています。[14]

flowchart LR
    A[複数セッション ホスト] --> B[共有ストレージ]
    B --> C[VHDX のユーザープロファイル]
    C --> D[接続したホストへアタッチ]

特に次のような条件では、FSLogix を先に検討する価値が高いです。

• セッションホストが毎回変わる
• Outlook / OneDrive / Microsoft 365 系を使う
• 非永続 VDI でプロファイル持ち回りが必須
• ローミングプロファイルのサインイン遅延が問題

9. よくある誤解

9.1 「アカウントを作れば、プロファイルも同じものがどこでも使われる」

そうではありません。アカウントは識別子で、プロファイルはその端末側の実体です。 どこまで持ち回るかは、ローカル、ローミング、Folder Redirection、FSLogix などの方式次第です。[4][14]

9.2 「C:\Users\ユーザー名 をコピーすれば移行できる」

雑なコピーは危険です。

• OS バージョン互換
• NTUSER.DAT
• 権限
• アプリ固有の状態
• 既定プロファイルとの混線

があるためです。特に OS 世代差のあるローミングでは、Microsoft もプロファイル バージョン分離を前提にしています。[6]

9.3 「Mandatory と Temporary は似たようなもの」

この 2 つは別物です。Mandatory は管理者が意図して作る読み取り専用プロファイル、Temporary はエラーで本来のプロファイルが読めないときの退避先です。[8][9]

9.4 「同期したいなら全部 Roaming に入れればよい」

それは危ないです。設定と巨大キャッシュを同じ箱に入れると、サインイン / サインアウトや障害時の扱いが重くなります。 Roaming させたいもの と Local に閉じるべきもの は分けるほうが運用しやすいです。[2][3]

9.5 「一時プロファイルになっても、そのまま使えばよい」

避けたほうがよいです。Temporary profile はサインアウトで消える前提なので、 その状態で作業を続けると、あとで消える場所に重要データを置いてしまう 危険があります。[9]

10. まとめ

Windows のユーザープロファイルは、単に C:\Users の下のフォルダーを指す言葉ではありません。

• ファイル群
• NTUSER.DAT を中心としたユーザー レジストリ
• そのプロファイルをどこに持ち、どう同期し、どう消すかという運用方式

まで含めて 1 つの設計として考えると、見通しがよくなります。

実務で先に押さえておきたいのは、この 6 点です。

• 単独 PC なら、まずは ローカルプロファイル を基準に考える
• アプリの保存先は Roaming / Local / ProgramData を分ける
• ドメイン環境では ローミングプロファイル と Folder Redirection を混同しない
• 共有端末では Mandatory / cleanup / Shared PC を検討する
• RDS / VDI / AVD では FSLogix を第一候補に入れる
• 壊れたときは、まず User Profile Service のログ を見る

結局のところ、プロファイルの設計は 「どこへ保存するか」ではなく、「何を誰のものとして、どこまで持ち回るか」 の設計です。 ここが固まっていると、端末展開も、Windows アプリの設計も、障害調査も、ずいぶんやりやすくなります。

11. 関連記事

• Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
• Windows サンドボックスで Windows アプリ開発の検証を速くする方法

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

Windowsアプリ開発

ユーザー設定、ログ、キャッシュ、共有データの保存先をどう分けるかは、Windows アプリの運用性と保守性を大きく左右します。 要件整理から設計・実装・長期運用まで見据えるなら、Windows アプリ開発の文脈と相性がよいテーマです。

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

技術相談・設計レビュー

ローカル / ローミング / FSLogix のどれを選ぶか、既存端末の運用をどう変えるか、保存先をどう切るかは、実装前の整理でかなり差が出ます。 方式選定や境界設計から整理したい場合は、技術相談・設計レビューとして切り出しやすいテーマです。

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

不具合調査・原因解析

Temporary プロファイル化、ログオン失敗、サインアウト時の保存失敗、共有パスまわりの切り分けは、不具合調査とかなり相性がよいです。 再現しにくいプロファイル問題を、ログ・イベント・権限・共有構成から詰めたいときの相談入口になります。

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

13. 参考資料

出典が多いので、先に 論点から引ける索引 を置いておきます。

1. Microsoft Learn, About User Profiles (Windows) ユーザープロファイルの構成要素、NTUSER.DAT、Temporary profile の基本。

2. Microsoft Learn, Fast User Switching アプリ固有データには FOLDERID_RoamingAppData、他のコンピューターで使わないデータには FOLDERID_LocalAppData を使う整理。

3. Microsoft Learn, KNOWNFOLDERID, CSIDL %APPDATA%、%LOCALAPPDATA%、LocalLow、ProgramData など既知フォルダーの定義。

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server Folder Redirection と Roaming User Profiles の違い、中央管理の考え方。

5. Microsoft Learn, Deploy roaming user profiles ローミングプロファイル展開、共有権限、GPO、バージョニングの実務手順。

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions OS 世代間の非互換性とプロファイル バージョニング。

7. Microsoft Learn, Create mandatory user profiles Mandatory user profile の用途と作成方法。

8. Microsoft Learn, Mandatory User Profiles NTUSER.MAN、Super-mandatory profile の定義。

9. Microsoft Learn, Temporary User Profiles Temporary profile の定義と性質。

10. Microsoft Learn, Troubleshoot user profiles with events Application / Operational / Diagnostic ログを使った切り分け。

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time C:\Users\Default を起点とする新規プロファイル作成、NTUSER.DAT / USRCLASS.DAT の属性・権限問題。

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows CopyProfile によるサポートされた既定プロファイルのカスタマイズ方法。

13. Microsoft Learn, What is FSLogix, Types of Containers FSLogix の基本、Profile Container の考え方。

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix Azure Virtual Desktop での推奨、VHD / VHDX を使ったプロファイル コンテナー方式。

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created 孤立したプロファイル情報と TEMP profile の関係。

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long ローミングプロファイル保存時の長いパス問題。

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Delete user profiles older than a specified number of days on system restart などのポリシー定義。

18. Microsoft Learn, Configure a shared or guest Windows device Shared PC モードと共有端末のアカウント / プロファイル管理。

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level 低整合性プロセスが書き込める場所として %USERPROFILE%\AppData\LocalLow と HKEY_CURRENT_USER\Software\AppDataLow が用意されていること。

関連する記事

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

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

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

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

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

NTUSER.DATとは何ですか？

NTUSER.DAT は、Windows のユーザープロファイルに含まれるユーザー レジストリ ハイブの実体ファイルです。C:\Users\ユーザー名 の直下にあり、サインイン時に読み込まれて HKEY_CURRENT_USER (HKCU) として使われます。つまりユーザープロファイルは Desktop や AppData などのファイル群と、NTUSER.DAT を中心としたレジストリ層の 2 層で構成されています。NTUSER.DAT が読み取り専用属性になっていたり必要なアクセス権がなかったりすると、プロファイルの読み込みに失敗し、ログオン失敗や一時プロファイル化の原因になります。

Windowsのユーザープロファイルとは何ですか？アカウントとは違うのですか？

アカウントは「だれがサインインするか」を識別するもので、ユーザープロファイルはその人の作業環境の実体です。プロファイルは単なる C:\Users\ユーザー名 フォルダーではなく、Desktop・Documents・AppData などのファイル群と、NTUSER.DAT というユーザー レジストリ ハイブのセットです。新しいユーザーが初めてサインインするときは、C:\Users\Default を土台に新しいプロファイルが作成されます。どこまで設定を持ち回るかは、ローカル・ローミング・Folder Redirection・FSLogix といった方式の選択で決まります。

%APPDATA%と%LOCALAPPDATA%はどう使い分ければよいですか？

ユーザーごとに持ち歩きたい設定は %APPDATA%（AppData\Roaming）、その PC 専用のキャッシュや一時的な状態は %LOCALAPPDATA%（AppData\Local）に置くのが基本です。再生成できるキャッシュや大きいワークファイルをローミングさせると、サインイン・サインアウトが重くなりやすいため Local 側へ寄せます。全ユーザー共通の可変データは ProgramData が候補ですが、だれが読み書きするかの ACL 設計とセットで考える必要があります。ユーザーごとの実行時データを Program Files に置くのは避けるべきです。

一時プロファイル(Temporary profile)でログオンされたときはどうすればよいですか？

Temporary プロファイルは、エラーで本来のプロファイルを読み込めないときに発行される緊急避難で、サインアウト時に削除され変更は失われます。そのまま作業を続けると重要データが消える危険があるため、避けるべき状態です。調査では、いきなり C:\Users を触るのではなく、Application ログと User Profile Service の Operational ログ、必要なら Diagnostic ログを先に確認します。よくある原因には、NTUSER.DAT / USRCLASS.DAT の属性や権限の問題、ローミング先のパスが長すぎる問題、不完全な削除で残ったレジストリ情報などがあります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。