MENU

Win32アプリ設定のレジストリ保存パターン徹底解説｜HKCU・HKLMと管理者権限の考え方

Windows

Windowsデスクトップアプリ（Win32アプリ）の設定をどこに保存するかは、リリース後に変更しづらいわりに「とりあえずレジストリで…」と決めがちなポイントです。本記事では、レジストリを使って設定を保存する場合に、どのルートキー（HKCU / HKLM）を使うべきか、管理者権限の要否、WOW64 への対応、アンインストールや代替案まで、実務で迷わないための判断軸を整理します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Win32アプリの設定保存先としてのレジストリの位置づけ

まず前提として、「設定をレジストリに保存するべきか」「設定ファイルにするべきか」という選択があります。どちらも一長一短ですが、Windowsの世界では以下のような役割分担で考えると整理しやすくなります。

項目レジストリ設定ファイル（JSON / INI など）
アクセスのしやすさWin32 API から直接アクセスしやすい。型付きで保存できる。アプリ側でパースが必要だが、ライブラリを使えば容易。
管理・バックアップOS全体で1つの大きなデータベース。増えすぎると把握しづらい。アプリ単位でファイルを分けられ、コピーしやすい。
権限書き込み先キーにより管理者権限が必要になる場合あり。ユーザープロファイル配下に置けば通常権限で完結。
ポリシー連携グループポリシーとの親和性が高く、企業環境で扱いやすい。ポリシー連携は基本的に自前実装が必要。
構成の複雑さ階層と値のみ。構造化データはやや扱いにくい。JSONなどを用いれば複雑な構造も表現しやすい。

企業向けのクライアントアプリや、既存のWindowsアプリと整合性をとりたい場合は、今でもレジストリ保存がよく選択されます。一方、個人向けツールやクロスプラットフォームアプリでは、設定ファイル方式が採用されることも多くなっています。

本記事は「レジストリを使う」と決めた前提で、どのキーに、どのように書き込むかを具体的に解説します。

Win32アプリ設定向けの主要レジストリルートキー

Windowsレジストリには複数のルートキーがありますが、Win32アプリの設定保存で主に検討対象になるのは次の2つです。

  • HKEY_CURRENT_USER（HKCU） – 現在ログオン中のユーザー専用
  • HKEY_LOCAL_MACHINE（HKLM） – コンピューター（マシン）全体で共有

アプリの設定を保存するときの定番パターンは、次のようなパスです。

HKEY_CURRENT_USER\Software\<会社名>\<アプリ名>
HKEY_LOCAL_MACHINE\Software\<会社名>\<アプリ名>

ここでの「会社名」は、ソフトウェアベンダー名や組織名（英語表記）を使うのが一般的です。Windowsの慣例上、「\Software\Microsoft\…」など、既存大手ベンダーと紛らわしい名前は避けます。

保存対象別：推奨ルートキーと権限の整理

どのルートキーを使うべきかは、「設定がユーザー専用か」「PC全体で共通か」で判断するのが基本です。

保存対象推奨ルートキー権限主な用途・注意点
ユーザーごとの設定HKEY_CURRENT_USER\Software\<会社名>\<アプリ名>
（略記: HKCU\Software\…）		不要（通常権限で書き込み可）・現在ログオンしているユーザー専用の設定を格納。
・インストール時の追加作業は不要。アプリ起動時にキーが無ければ自動作成でよい。
・プロファイルごとに設定が分かれるので、共有PCでもユーザー別に環境を変えられる。
全ユーザー共通の設定HKEY_LOCAL_MACHINE\Software\<会社名>\<アプリ名>
（略記: HKLM\Software\…）		必要（管理者権限でのみ書き込み可）・既定値やライセンス情報など、PC共有の設定を格納。
・インストーラ（管理者として実行）でキーを作成し、アプリ本体は読み取り専用にする。
・一般ユーザーに読み取り権限を付与するかどうかは、情報の機密性と運用ポリシー次第。

この2つを基本に、「ユーザー専用なら HKCU」「PC共通なら HKLM」と覚えておくと迷いづらくなります。

シナリオ別：どのキーを選ぶべきか

ユーザーに管理者昇格を求めたくない場合

一般ユーザー向けのツールや、社内ユーザーに配布するアプリで、日常利用時にUACの昇格プロンプトを出したくない場合は、迷わず HKCU を使います。

  • ユーザーごとのウィンドウ位置・テーマ・最近使ったファイル一覧など
  • ログインユーザーごとに変わるAPIトークンやユーザーID
  • 「前回チェックした日時」「チュートリアルを表示済みか」等の軽量なフラグ

これらはすべて HKCU に置くのが自然です。アプリ初回起動時にキーが存在しないなら、コード側で自動的に作成して構いません。

マシン全体で共通化したい設定がある場合

例えば次のような情報は、PC単位で共通にしたいケースが多くなります。

  • ライセンスキー、シリアル番号、アクティベーション情報
  • プロキシサーバーのアドレスやポート等、ネットワークポリシーに関わる設定
  • 組織全体で固定したいアプリの既定動作（ログの保存期間、機能制限など）

この場合は HKLM\Software\<会社名>\<アプリ名> に保存するのが一般的です。ただし、HKLM への書き込みは管理者権限が必須です。そのため、次のような設計が推奨されます。

  • 管理者として実行されるインストーラが HKLM のキーと値を作成する
  • アプリ本体（通常権限で動く）は HKLM を読み取りのみ行う
  • 運用ポリシーに応じて、一般ユーザーに読み取り権限を与えるかを決める

アプリ本体から HKLM に書き込もうとすると、環境によっては UAC が表示され、ユーザー体験を損ないます。よほどの理由がない限り、アプリ本体で HKLM に書き込みに行かないのが現実的です。

「既定値 + ユーザー上書き」の二段構えにする場合

よくある要件として、「会社としての既定値は管理者が配布しつつ、ユーザーがそれを上書きできるようにしたい」というものがあります。この場合は、次のパターンが定番です。

  • 既定値を HKLM\Software\<会社名>\<アプリ名> に配置
  • ユーザーごとの上書きを HKCU\Software\<会社名>\<アプリ名> に配置
  • アプリ起動時は HKCU を優先して読み込み、存在しなければ HKLM をフォールバック

擬似コードにすると以下のようなイメージです。

// キー名: "LogLevel" を読みたい例
int ReadLogLevel()
{
    // 1. ユーザーごとの設定を HKCU から試す
    if (TryReadIntFromHKCU(L"Software\\MyCompany\\MyApp", L"LogLevel", out int value))
    {
        return value;   // 見つかればそれを採用
    }

    // 2. 見つからなければ HKLM の既定値にフォールバック
    if (TryReadIntFromHKLM(L"Software\\MyCompany\\MyApp", L"LogLevel", out value))
    {
        return value;
    }

    // 3. それも無ければハードコーディングされたデフォルト
    return 1; // 例: INFO レベル
}

この構成にしておくと、次のようなメリットがあります。

  • 管理者は HKLM に既定値を配布するだけで済む（インストーラやスクリプトでOK）
  • ユーザーは HKCU に自分の好みを設定できる（通常権限のまま）
  • HKCU を全削除しても、HKLM の既定値でアプリが動作し続ける

レジストリキー構造の設計例

ルートキー（HKCU / HKLM）が決まったら、次はどのようなキー構造にするかです。よくあるパターンを具体例で示します。

HKCU\Software\MyCompany\MyApp
    (既定)        = ""
    InstallDir    = "C:\\Program Files\\MyApp"
    Language      = "ja-JP"
    WindowX       = 100 (REG_DWORD)
    WindowY       = 80  (REG_DWORD)
    WindowWidth   = 1024
    WindowHeight  = 768
    Theme         = "Dark"

HKLM側は、例えば次のようにします。

HKLM\Software\MyCompany\MyApp
    (既定)            = ""
    LicenseKey        = "XXXX-XXXX-XXXX-XXXX"
    DefaultLanguage   = "en-US"
    MinLogRetention   = 14 (REG_DWORD)

設計時のポイントとして、次の点を意識すると後で楽になります。

  • 会社名の下にアプリ名をぶら下げる（将来アプリが増えても整理しやすい）
  • キー名・値名には半角英数字を使い、スペースを避ける（スクリプトから扱いやすい）
  • バージョンごとに大きく構造が変わる場合は MyApp\v1 のような階層を切る
  • 値の型は REG_SZ / REG_DWORD / REG_QWORD を基本とし、複雑な構造はファイルに逃がす

権限とインストーラの役割

レジストリ周りでトラブルになりがちなのが「権限エラー」です。特に、開発環境では管理者権限で実行しているため再現せず、本番環境で初めてエラーになるケースが多くあります。

アクセス先読み取り書き込み備考
HKCU\Software\…通常権限で可通常権限で可アプリ本体からの読み書きに最適。
HKLM\Software\…読み取りは通常権限で可（権限設定による）原則として管理者権限が必要インストーラで作成し、アプリ本体は読み取り専用とするのが定石。

実装としては、次のような分担を意識します。

  • インストーラ
    • HKLM配下のキーと値を作成
    • 必要に応じてアクセス権（ACL）を調整（一般ユーザーに読み取り権限を付与など）
    • アンインストール時に HKLM の設定を削除
  • アプリ本体
    • ユーザー設定は HKCU に読み書き
    • HKLMは読み取りのみ（既定値・ライセンス状態など）
    • HKLM書き込みでアクセス拒否になった場合は、ユーザーに「管理者として再インストール」を案内

例えば、RegCreateKeyEx が ERROR_ACCESS_DENIED を返した場合には、次のような具体的なエラーメッセージを表示しておくと、サポート対応が非常に楽になります。

設定をレジストリに保存できませんでした。
必要であれば、管理者としてインストールを実行し直すか、システム管理者にお問い合わせください。

WOW64（32bit / 64bit）環境での注意点

64bit版Windows上で32bitアプリを動かす場合、レジストリにはWOW64リダイレクトという仕組みが働きます。特に HKLM\Software に関しては、次の挙動を理解しておくことが重要です。

  • 32bitアプリが HKLM\Software\MyCompany\MyApp に書き込むと、実際には
    HKLM\Software\WOW6432Node\MyCompany\MyApp に保存される
  • 64bitアプリは HKLM\Software をそのまま見ており、WOW6432Node は見ない

つまり、次のようなケースでは注意が必要です。

  • 64bitインストーラ（またはスクリプト）が HKLM\Software に値を書き込む
  • 32bitのWin32アプリがその値を読もうとする

この場合、アプリ側が見ているのは WOW6432Node配下の別ツリーであり、インストーラが書いた値とは食い違ってしまいます。対策としては、次のいずれかが考えられます。

  • アプリとインストーラのビット数を揃える（両方32bit or 両方64bit）
  • インストーラ側で WOW6432Node側にも値を複製する
  • レジストリではなく、共通の設定ファイル（ProgramData 配下など）に保存する

特に古い32bitアプリを64bit環境に持ち込む場合は、「期待したキーが見つからない」現象の多くが WOW64 リダイレクト絡みです。デバッグ時は必ず regedit で WOW6432Node を確認するようにしましょう。

フォルダー保存（設定ファイル）との使い分け

レジストリは便利ですが、「何でもかんでも突っ込む」のはおすすめできません。単純な設定であれば、%APPDATA% 配下の設定ファイルにする選択肢も常に検討すべきです。

要件レジストリ向き設定ファイル向き
少量のキー・値（10〜20個程度）◯◯
大量の設定・複雑な構造（ネストしたオブジェクトなど）△（管理が大変）◯（JSONなどで自然に表現可能）
他ツールとの連携（設定ファイルを配布したい）△◯（ファイルコピーだけで済む）
ポリシー（GPO）で集中管理したい◯（レジストリベースのポリシーと相性が良い）△（自前仕組みが必要）

設定ファイルの配置例としては、次のようなフォルダーがよく使われます。

  • ユーザーごとの設定:
    • %APPDATA%\<会社名>\<アプリ名>\config.json
  • 全ユーザー共通の設定:
    • %PROGRAMDATA%\<会社名>\<アプリ名>\config.json

レジストリとファイルを組み合わせるパターンもよくあります。例えば「設定ファイルのパスやバージョン情報だけレジストリに保存し、実際の設定はJSONファイルにある」という構成です。これにより、GPOとの連携や企業内配布と、アプリ内部の柔軟な設定構造を両立できます。

実装例：C++からレジストリに設定を保存する

Win32 API を直接使った場合の、シンプルな書き込み例を示します。ここではユーザーごとの設定を HKCU に保存するケースです。

// HKCU\Software\MyCompany\MyApp に "Theme" = "Dark" を保存する例
bool SaveThemeToRegistry(const std::wstring&amp; theme)
{
    HKEY hKey;
    LONG result = RegCreateKeyExW(
        HKEY_CURRENT_USER,
        L"Software\\MyCompany\\MyApp",
        0,
        nullptr,
        REG_OPTION_NON_VOLATILE,
        KEY_WRITE,
        nullptr,
        &amp;hKey,
        nullptr);

    if (result != ERROR_SUCCESS)
    {
        return false;
    }

    result = RegSetValueExW(
        hKey,
        L"Theme",
        0,
        REG_SZ,
        reinterpret_cast&lt;const BYTE*&gt;(theme.c_str()),
        static_cast&lt;DWORD&gt;((theme.size() + 1) * sizeof(wchar_t)));

    RegCloseKey(hKey);
    return (result == ERROR_SUCCESS);
}

読み込み時は、先ほど紹介した「HKCU → HKLM → ハードコード」の順でフォールバックする関数を用意しておくと、アプリ全体で一貫した挙動になります。

.NET アプリ（C#など）の場合は、Microsoft.Win32.Registry クラスを使うと、より簡潔に記述できます。

using Microsoft.Win32;

void SaveWindowSize(int width, int height)
{
    using (var key = Registry.CurrentUser.CreateSubKey(@"Software\MyCompany\MyApp"))
    {
        key.SetValue("WindowWidth",  width,  RegistryValueKind.DWord);
        key.SetValue("WindowHeight", height, RegistryValueKind.DWord);
    }
}

これらの実装では、例外やエラーコードを適切にハンドリングし、「保存に失敗してもアプリは落とさない」「ユーザーに必要十分なメッセージを出す」といった運用の細部も重要です。

エラー処理とユーザーフィードバックの設計

レジストリ周りの不具合は、ユーザーから見ると「何も変わらない」「設定が保存されない」という形で現れます。デバッグしやすいよう、次のような方針で実装するとよいでしょう。

  • HKCU への保存失敗:
    • ディスクフルやプロファイル障害など、根本的な問題の可能性がある
    • ユーザーには「設定の保存に失敗しました」の旨を表示し、ログにはエラーコードも残す
  • HKLM 読み取り失敗:
    • インストールの失敗やポリシー設定ミスが疑われる
    • ログに「HKLMの設定が見つからない」旨を出し、アプリは安全側のデフォルトで動かす
  • HKLM 書き込み失敗（原則アプリ本体では行わない）:
    • アクセス拒否は想定通りの挙動であることが多い
    • どうしても必要な場合のみ、「管理者として実行」を案内する UI を出す

また、ログ出力にレジストリパス（例: HKCU\Software\MyCompany\MyApp\Theme）とエラーコードを含めておくと、サポート担当者が原因を追いやすくなります。

アンインストール時のレジストリクリーンアップ

アンインストーラの振る舞いも、ユーザー体験とサポートコストの両方に影響します。基本方針は次の通りです。

  • HKLM のキー
    • 原則としてアンインストール時に削除する
    • ライセンス情報など残しておきたい場合は、運用ポリシーに基づき判断
  • HKCU のキー
    • 「ユーザー設定を削除しますか？」というチェックボックスを用意し、ユーザーに選択させる
    • 複数ユーザーが同一PCで利用している可能性があるため、慎重に扱う

企業環境では、「アンインストールしてもユーザーの設定は残してほしい」「再インストール時には以前の設定を復元したい」といった要望がよくあります。その場合、HKCUを残す設計の方が歓迎されることが多いです。

セキュリティ・パフォーマンス上の注意点

設定をレジストリに保存する際に、セキュリティとパフォーマンスの観点で気を付けたいポイントもまとめておきます。

機微情報の扱い

  • パスワードやトークンなど、機微な情報を平文でレジストリに保存しない
  • どうしても保存が必要な場合は、DPAPIなどを用いた暗号化を検討する
  • HKLM に機微情報を置くと、PC上の全ユーザーから読み取られる可能性があるため特に注意

パフォーマンスへの影響

  • レジストリアクセスは比較的軽いが、頻繁な読み書きを行うと不要なオーバーヘッドになる
  • 起動時にまとめて読み込み、アプリ内部でキャッシュしておく設計が望ましい
  • 終了時に必要な分だけ書き戻すなど、アクセス回数を意識して設計する

将来の拡張性

  • 設定項目を増やす余地を持たせたキー構造にしておく
  • バージョンアップ時に設定の互換性をどう保つかをあらかじめ想定する
  • 大きな設計変更が予想される場合は、レジストリから設定ファイル方式への移行も視野に入れる

まとめ：Win32アプリの設定レジストリ設計の指針

最後に、本記事の要点を整理します。

  • ユーザー別の設定なら HKCU\Software\<会社名>\<アプリ名> を利用する
    • 昇格不要で書き込みでき、ユーザーごとのカスタマイズに最適
  • PC全体で共通の設定は HKLM\Software\<会社名>\<アプリ名> へ
    • 管理者権限でインストーラが作成し、アプリ本体は読み取りのみ
  • 既定値 + ユーザー上書きを実現する場合は、HKLM を既定値、HKCU を上書き用としてフォールバック読み込みする
  • 64bit環境では WOW6432Node の存在を意識し、アプリとインストーラのビット数を揃えるとトラブルを減らせる
  • レジストリが肥大化しないようにしつつ、複雑な設定は %APPDATA% や %PROGRAMDATA% 配下のファイル保存も選択肢に入れる
  • アンインストール時のレジストリ削除方針（特に HKCU）を決め、ユーザーに選択肢を提供すると親切

これらの指針を踏まえたうえで、最初に「どの設定を誰の単位で管理したいのか」を整理してからレジストリ設計を行うと、後から大きく作り直すリスクを減らせます。Win32 アプリの設定保存先に迷ったときは、まず「HKCU」「HKLM」「設定ファイル」の三択を、本記事の観点で評価してみてください。

Windows
Windows レジストリ アプリ設定 Win32

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次