Windowsアプリ互換の仕組み ── 互換モード・シム・Compatibility Administratorで古いアプリを延命する

「ソースコードが残っていない10年前の業務アプリが、新しいWindows 11のPCでは起動しない。ところが、互換性タブで『Windows XP』を選ぶと動いた。このまま使い続けてよいのか」。古い業務アプリを預かる現場では、こうした相談があります。

互換モードは、OS全体を昔のWindowsへ戻す機能ではありません。そのアプリにだけ、古いWindowsを前提とした動作を補う仕組みです。中心になるのは、アプリとWindows APIの間に割り込む小さな互換修正、シム(Shim)です。¹

本記事では、中小企業の情シス担当者とWindowsアプリ開発者に向けて、何を直せるか → なぜ動くか → どう適用・配布するか → 延命か移行かをどう判断するかの順に整理します。Microsoft Learnの一次情報をもとに、チェックボックスの先で起きていることを確認していきます。

1. まず結論 ── 互換モードは使ってよい。ただし、延命として管理する

互換モードで当面の業務を続けること自体は、Windowsが正式に用意した仕組みを使う妥当な選択です。 Windows自身も、既知のアプリに互換修正を適用しています。¹ ただし、アプリを修正したわけではありません。本筋は、最終的にシムなしで動く形へ直すことです。

使うかどうかは、次の順に判断すると整理できます。

特に、「管理者かどうかのチェックに成功を返すこと」と「管理者権限を与えること」は別です。シムはアプリと同じセキュリティ制約を受け、OSの保護を回避しません。¹² RunAsInvokerも、昇格要求を抑えて呼び出し元と同じ権限で起動させるものであり、権限を増やす機能ではありません。³

仕組みを理解すれば、「なぜ動いているのか分からないから触れない」という延命から、頼れる範囲・壊れる条件・作り直す時期を説明できる延命へ変えられます。

flowchart TB
    accTitle: 仕組みの理解が延命の質を変える
    accDescr: 仕組みを知らないまま互換モードを使うと触れない不安定な延命になるが、仕組みを理解すればどこまで頼れるか、何が起きたら壊れるか、いつ作り直すべきかを根拠を持って判断できる
    unknown["仕組みを知らないまま使う"] --> fear["触れない不安定な延命"]
    known["仕組みを理解して使う"] --> judge["根拠を持った判断"]
    judge -.-> j1["どこまで頼れるか"]
    judge -.-> j2["何が起きたら壊れるか"]
    judge -.-> j3["いつ作り直すべきか"]

図1: 同じ延命でも、仕組みを知らないままの不安と、理解にもとづく判断では質が変わる。

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

2. 最初の切り分け ── シムで直せる問題か

2.1. 直せるのは、ユーザーモードのアプリ側の問題

シムでできることは、アプリのコード修正でもできる範囲に収まります。ソースコードがない、ベンダーのサポートが終わっている、今すぐには直せない、といった場合の代替手段であって、コード修正より強力なものではありません。¹

たとえば、OSバージョンを見て起動を拒否する、古い書き込み先を前提にしている、実際には不要な管理者権限を要求する、といった問題は検討対象になります。具体的なシムは5章で確認します。

2.2. 設定を試し続けても解決しないケース

次の問題は、互換モードとは別の対策が必要です。

カーネルモードの問題とセキュリティの制約は、シムの動作場所から来る限界です。¹ ForceAdminAccessやWRPMitigationは、チェックや書き込みの成功を偽装してアプリを先へ進めるだけで、実際に保護された資源を書き換えているわけではありません。²

16bitの問題では、アプリ本体だけでなくインストーラーも確認してください。本体が32bitでも、起動部分(スタブ)だけが16bitの古いパッケージでは、「アプリは動くのにインストールできない」となります。64bit Windowsではハンドルが32bitの有効ビットを持ち、16bitに切り詰めて渡せないことなどから16bitアプリはサポートされず、起動はERROR_BAD_EXE_FORMATで失敗します。⁴

flowchart TB
    accTitle: シムが効かないケース
    accDescr: シムはユーザーモードのプロセス内で動くため、カーネルモードのドライバー問題、16bitアプリ、ハードウェアへの直接アクセス、セキュリティ機構の回避には効かない
    shim["シム（ユーザーモードで動作）"] -->|効かない| drv["カーネルドライバー"]
    shim -->|効かない| b16["16bitアプリ"]
    shim -->|効かない| hw["ハード直接アクセス"]
    shim -->|効かない| sec["セキュリティ機構の回避"]
    b16 -.-> fmt["64bitでは起動自体が失敗"]
    sec -.-> fake["成功の偽装で先へ進めるだけ"]

図2: シムはユーザーモード限定で、カーネル・16bit・ハードウェア直接アクセス・セキュリティ回避には届かない。

また、古いコピープロテクトや改ざん検出など、自己整合性チェックを持つアプリはAPIフック自体を異常とみなすことがあります。ユーザーモードのアプリなら必ずシムで救える、というわけでもありません。

3. 似ている機能を分ける ── シム・UAC仮想化・WOW64・DPI仮想化

「古いアプリが動いた」ときに働いている仕組みは、シムだけとは限りません。Windowsが持つ後方互換の層を分けておきます。実際には、複数の仕組みが組み合わさることもあります。

3.1. UAC仮想化: 書き込み先をユーザー別に逃がす

UAC仮想化は、マニフェストを持たない32bit対話型プロセスに対して働く経過措置です。Microsoft自身が、将来のWindowsから削除する意向の暫定技術と位置づけています。⁵ 32bitアプリを動かすWOW64と、書き込み先をユーザー別に転送するUAC仮想化は別の仕組みです。

Wow6432NodeへのリダイレクトやVirtualStoreの実害と対処は、レジストリの32bit/64bitリダイレクトと仮想化の落とし穴で扱っています。本記事では、シムとの区別に必要な範囲にとどめます。

flowchart TB
    accTitle: UAC仮想化の位置づけ
    accDescr: UAC仮想化はマニフェストを持たない32bit対話型プロセスに対して働く経過措置で、書き込みをユーザー別のVirtualStoreへ転送するが、Microsoft自身が将来のWindowsから削除する意向の暫定技術と明言している
    proc["マニフェストなしの32bit対話型プロセス"] --> uacv["UAC仮想化が働く"]
    uacv --> vs["ユーザー別VirtualStoreへ転送"]
    uacv -.-> tmp["将来削除の意向がある暫定技術"]

図3: UAC仮想化はマニフェストを持たない32bitプロセス向けの経過措置で、恒久的には頼れない。

3.2. DPI仮想化: 古い描画を引き伸ばす

DPI対応を宣言していないアプリは、96 DPI(100%)で描画しているものとして扱われます。Windowsがそのビットマップを引き伸ばすため、高DPIモニターでは表示がぼやけます。互換性タブの「高DPI設定の上書き」は、この仮想化の挙動を切り替えるスイッチです。⁶

flowchart TB
    accTitle: DPI仮想化の仕組み
    accDescr: DPI対応を宣言していないアプリは96 DPIで描画しているものとして扱われ、Windowsがビットマップを引き伸ばして表示するためぼやけて見え、互換性タブの高DPI設定の上書きはこの仮想化の挙動を切り替える
    app["DPI対応を宣言しないアプリ"] --> treat["96 DPIとして描画扱い"]
    treat --> stretch["ビットマップを引き伸ばし表示"]
    stretch --> blur["高DPIモニターでぼやける"]
    tab["高DPI設定の上書き"] -.->|仮想化の挙動を切り替え| treat

図4: DPI非対応アプリは96 DPI扱いで引き伸ばされ、互換性タブの上書きはこの仮想化のスイッチになる。

4. なぜ互換モードで動くのか ── シムと起動時の適用

4.1. API呼び出しの行き先を差し替える

Windowsの実行ファイル(PEフォーマット)が外部DLLのAPIを呼ぶ経路には、インポートアドレステーブル(IAT)があります。たとえばGetVersionExの呼び出しでは、IATに書かれたアドレスへ処理が移ります。

シムは、アプリのロード時にこのIATエントリをシムコードのアドレスへ書き換えます。これがAPIフックです。動的にGetProcAddressで取得するAPIも、GetProcAddress自体をフックして対応します。¹

割り込んだシムは、古いOSバージョンを返したり、ファイルアクセス先を付け替えたりし、必要に応じて本物のAPIを呼びます。アプリには「期待しているWindowsの動作」を見せ、OSには現在の仕組みに合う呼び出しを渡す、いわば通訳です。

flowchart TB
    accTitle: シムがAPI呼び出しに割り込む経路
    accDescr: アプリのAPI呼び出しはIATを経由しており、ロード時にIATエントリをシム宛てに書き換えることでシムが割り込み、古いWindowsと同じ応答を偽装してから必要に応じて本物のAPIを呼ぶ
    app["アプリ"] -->|API呼び出し| iat["IATエントリ"]
    iat -->|ロード時にシム宛てへ書き換え| shim["シム（通訳）"]
    shim -->|必要に応じて| api["本物のWindows API"]
    shim -.-> lie["古いWindowsと同じ応答を偽装"]
    gpa["GetProcAddress経由の呼び出し"] -.->|フックで対応| shim

図5: アプリとWindows APIの間にシムが割り込む。書き換わるのはアプリ側のIATで、OS本体は変わらない。

変わるのはアプリ側の呼び出し経路であり、OS本体ではありません。 シムはアプリと同じセキュリティ制約下で動くため、利用のためにOSのセキュリティ設定を緩める必要もありません。¹

4.2. .sdbが「どのEXEに何を適用するか」を決める

シムデータベースは、拡張子.sdbのバイナリファイルです。ファイル名・サイズ・チェックサム・バージョンといったマッチング属性で実行ファイルを識別し、プロセス起動時に照合します。ここで使う用語を分けると、次のようになります。⁷

照合されるのは、利用者が互換モードを設定したアプリだけではありません。すべてのプロセス起動で、OS標準のデータベースとの照合が行われます。 Windowsには何千という既知アプリの修正が同梱され、実体は%WINDIR%\AppPatch配下にあります。Microsoft提供の互換修正はWindowsの一部として出荷され、Windows Updateで更新されます。¹

flowchart TB
    accTitle: プロセス起動時のシムデータベース照合
    accDescr: すべてのプロセス起動でシムデータベースと照合され、マッチング属性に一致する登録があればAppfixによるシム注入やApphelpのメッセージ表示が行われ、なければそのまま起動する
    start["プロセス起動"] --> db["シムデータベース（.sdb）と照合"]
    db -.-> attr["ファイル名・サイズ等で照合"]
    db --> hit{"登録がある?"}
    hit -->|はい| appfix["Appfix（シムを注入）"]
    hit -->|はい| apphelp["Apphelp（メッセージ表示）"]
    hit -->|いいえ| plain["そのまま起動"]
    layer["互換レイヤー（互換モード）"] -.->|複数のシムとフラグの束| appfix

図6: 照合は互換モードを設定したアプリだけでなく、すべてのプロセス起動で行われている。

互換レイヤーには、APIフックだけでなく起動時のフラグも含まれます。7章のRunAsInvokerは、APIを傍受するのではなく、ローダーフラグとして起動時の実行レベルに作用する互換修正です。³

4.3. PCAが問題を見つけて適用することもある

管理者が手動で設定しなくても、PCA(Program Compatibility Assistant)が互換設定を適用することがあります。PCAはアプリの実行を監視し、既知の問題の兆候を検出すると、修正を提案するか、一部のケースでは自動で適用します。⁸

たとえば、解放済みDLL内のコードを呼んでクラッシュするアプリにはPINDLL、保護されたWindowsファイルへの書き込みに失敗するアプリにはWRPMITIGATIONのような互換モードが使われます。⁸

flowchart TB
    accTitle: PCAが自動で互換設定を当てる流れ
    accDescr: PCAはアプリの実行を監視し、既知の互換性問題の兆候を検出すると修正の適用をユーザーに提案するか、一部のケースでは自動で互換設定を適用する
    run["アプリの実行"] --> pca["PCAが監視"]
    pca --> sign{"既知の問題の兆候?"}
    sign -->|あり| resp{"ケースは?"}
    resp -->|提案で対応| suggest["修正の適用を提案"]
    resp -->|一部のケース| auto["自動で互換設定を適用"]
    sign -->|なし| none["そのまま実行"]
    auto -.-> ex["例：PINDLLやWRPMITIGATION"]

図7: PCAはアプリの実行を監視し、既知の問題の兆候を検出すると修正の提案または自動適用を行う。

「設定した覚えがないのに、互換モードのチェックが入っていた」という現象は、多くの場合この経路です。故障や誤操作とは限らず、Windowsが問題に対応した結果でもあります。

5. 症状から修正を選ぶ ── 代表的なシムとバージョン判定

5.1. 既製シムで補えること

Microsoftが公開している既製シムのうち、業務アプリの延命でよく使うものを挙げます。²

多くのシムが行うのは、古いアプリが期待する答えを返すことです。「ディスク容量は2GBまで」「OSはXP」「管理者チェックは成功」といった、アプリが作られた時代の前提を、そのプロセスの中にだけ再現します。2章で見たとおり、答えの偽装と実際の権限・資源の変更は別です。

5.2. GetVersionExの値は、互換モードを選ばなくても変わる

バージョン詐称は、互換モードを手動で選んだ場合だけの話ではありません。Windows 8.1以降、GetVersionExが返す値はアプリのマニフェストに依存します。<compatibility>内に<supportedOS>の宣言がなければ、実際には新しいWindows上でもWindows 8相当の6.2を返します。宣言があれば、そのうち最も高いOSまでの値を返します。たとえばWindows 8.1のGUIDまで宣言したアプリは、Windows 11上でも6.3です。⁹¹⁰

そのうえでVersionLie系シムが適用されていれば、互換モードで選んだOSのバージョンを報告します。マニフェストによる既定の応答と、シムによる応答の置き換えを順に見る必要があります。⁹

flowchart TB
    accTitle: アプリが見るOSバージョンの決まり方
    accDescr: GetVersionExの返す値はマニフェストのsupportedOS宣言の有無で決まり、宣言なしならWindows 8相当の6.2、宣言ありなら宣言した最も高いOSまでの値が返り、VersionLie系シムが適用されていれば選択したOSのバージョンで上書きされる
    q["GetVersionExの問い合わせ"] --> m{"supportedOS宣言がある?"}
    m -->|いいえ| v62["Windows 8相当（6.2）が返る"]
    m -->|はい| decl["宣言した最も高いOSまでの値"]
    v62 --> lie{"VersionLie系シム適用?"}
    decl --> lie
    lie -->|はい| fake["互換モードで選んだOSの値"]
    lie -->|いいえ| asis["そのままの値が返る"]

図8: アプリが見るWindowsバージョンはマニフェストとシムの多段で決まる。

したがって、確認する場所も症状で分かれます。自社アプリがWindows 11をWindows 8と判定して困っているなら、まずsupportedOSの宣言を確認します。一方、古いアプリがバージョンチェックだけで起動を拒否しているなら、VersionLieを試す価値があります。実際の動作は新しいOSでも問題ないことが多く、このタイプはシムで起動拒否を解消できる可能性が高いためです。

flowchart TB
    accTitle: バージョン起因の2つの症状と対処
    accDescr: 自社アプリがWindows 11なのに8と判定されるならマニフェストのsupportedOS宣言を疑い、バージョンチェックで起動を拒否する古いアプリはVersionLieシムで高確率で突破できる
    sym1["Windows 11なのに8と判定"] --> fix1["supportedOS宣言を疑う"]
    sym2["バージョンチェックで起動拒否"] --> fix2["VersionLieで突破を試す"]
    fix2 -.-> why["動作自体は新しいOSでも問題ないことが多い"]

図9: 判定が古くなる症状はマニフェストを、起動拒否はVersionLieをそれぞれ疑う。

6. まず1台で確認する ── 互換性タブとLayersキー

6.1. チェックボックスの保存先を見る

プロパティの互換性タブで保存した設定は、レジストリのAppCompatFlags\Layersキーに書かれます。DXGIのアプリ互換設定でも使われる、互換レイヤーの指定先です。¹¹

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

「Windows XP (Service Pack 3)」「管理者としてこのプログラムを実行する」「高DPI設定の上書き」を設定したEXEでは、たとえば次のような値が見えます。

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

各項目と値の代表的な対応は次のとおりです。Windows 11の例であり、OSのバージョンにより項目名・値は変わり得ます。

6.2. 適用するユーザーと、適用のタイミングを分ける

HKCU側は、そのユーザーだけの設定です。「すべてのユーザーの設定を変更」から保存すると、HKLM側の同名キーに書かれ、全ユーザーに適用されます。キッティングでは、どちらに保存しているかを確認してください。

また、設定がプロセスへ適用されるのは、次にそのEXEを起動するときです。ローダーが保存された値を読み、対応する互換レイヤーを適用します。

flowchart TB
    accTitle: 互換性タブ設定が効くまでの流れ
    accDescr: 互換性タブの設定はAppCompatFlagsのLayersキーにEXEパスと値として保存され、次にそのEXEを起動するときローダーが値を読んで対応する互換レイヤーをプロセスに適用する
    tab["互換性タブで設定"] --> reg["LayersキーにEXEパスと値を保存"]
    reg --> boot["次回のEXE起動"]
    boot --> loader["ローダーが値を読む"]
    loader --> apply["互換レイヤーをプロセスに適用"]
    reg -.-> hkcu["HKCUはそのユーザーだけ"]
    reg -.-> hklm["HKLMは全ユーザーに効く"]

図10: チェックボックスの実体はLayersキーへの書き込みで、適用は次回起動時に行われる。

6.3. 互換モードと昇格指定を混同しない

RUNASADMINもWINXPSP3と同じLayersキーに同居します。「互換モードを設定したら昇格まで付いた・消えた」と見える場合は、値を直接確認すると、互換レイヤーの指定と昇格の指定を切り分けられます。

互換性タブは、代表的な既製レイヤーへの入口です。個別のシムを選んで組み合わせる用途は、8章のCompatibility Administratorが担当します。その前に、日常の運用で出番の多いRunAsInvokerを見ておきます。

7. RunAsInvoker ── 不要な昇格要求だけを抑える

7.1. 「管理者を要求する」と「管理者権限が必要」を分ける

古い業務アプリには、マニフェストのrequireAdministrator指定や、EXE名・内容によるインストーラー誤検出によって、起動のたびにUAC昇格を要求するものがあります。しかし、XP時代の設計を引き継いで要求しているだけで、実際には管理者権限を使っていないアプリも多くあります。

RunAsInvokerは、インストーラー検出とマニフェスト処理の両方を上書きし、親プロセスから継承したトークンのまま起動させます。呼び出し元が一般ユーザー権限なら、その権限のままです。³

flowchart TB
    accTitle: RunAsInvokerが昇格要求を抑える仕組み
    accDescr: マニフェストのrequireAdministrator宣言やインストーラー誤検出が起動時のUAC昇格要求の原因になるが、RunAsInvokerを適用すると両方が上書きされ、親プロセスから継承したトークンのまま起動する
    manifest["requireAdministrator宣言"] --> shim{"RunAsInvoker適用?"}
    detect["インストーラーと誤検出"] --> shim
    shim -->|いいえ| uac["起動のたびにUAC昇格要求"]
    shim -->|はい| token["親のトークンのまま起動"]
    token -.-> limit["管理者必須の処理はアプリ内で失敗"]

図11: RunAsInvokerは昇格要求の原因を上書きするだけで、権限が増えるわけではない。

7.2. 環境変数で一時的に試す

.sdbを作成しなくても、環境変数__COMPAT_LAYERで同じレイヤーを一時的に適用できます。以下は、そのコマンドプロンプトやPowerShellから起動する子プロセスに適用する例です。

:: このコマンドプロンプトから起動する子プロセスにRunAsInvokerを適用
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# PowerShellの場合
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

実際の利用者と同じ一般権限で、業務に必要な操作まで動くことを確認してから採用します。² 管理者権限が不要なアプリなら、コマンドをバッチファイルにしてショートカット代わりに配ることで、ローカル管理者権限の配布や、UACのパスワード入力のたびの情シス呼び出しを減らせます。最小権限の原則に沿う方向の互換テクニックです。

flowchart TB
    accTitle: RunAsInvokerバッチ配布の効果
    accDescr: RunAsInvokerを設定する2行のバッチファイルをショートカット代わりに配れば、一般ユーザーにローカル管理者権限を配らずに済み、UACのパスワード入力で情シスが呼ばれることもなくなり、最小権限の原則に沿う運用になる
    bat["2行のバッチを配布"] --> noadmin["管理者権限を配らずに済む"]
    bat --> nocall["UACで情シスが呼ばれない"]
    noadmin --> lp["最小権限の原則に沿う運用"]
    nocall --> lp

図12: バッチ配布だけで、管理者権限の配布とUAC対応の呼び出しの両方を減らせる。

7.3. 効く範囲と、恒久適用・改修を区別する

RunAsInvokerで権限が増えるわけではありません。 本当に管理者権限が必要なHKLMへの書き込みやProgram Files配下の更新は、アプリ内で失敗します。条件を満たす場合は、UAC仮想化でVirtualStoreへ転送されることもあります。設定保存が「効かなくなった」ように見えたら、仮想化を疑います。⁵

環境変数方式が効くのは、その環境を受け継いで起動した子プロセスです。恒久適用には、Layersキーへの直接設定か.sdbの配布を使います。RUNASINVOKERを選ぶ項目は互換性タブにはありません。

flowchart TB
    accTitle: RunAsInvokerの一時適用と恒久適用
    accDescr: 環境変数COMPAT_LAYERによる適用はそこから起動した子プロセスにしか効かず、恒久的に適用するにはLayersキーへの直接設定か.sdbでの配布を使う
    env["環境変数で設定"] --> child["子プロセスにだけ効く"]
    child -.-> tmp["一時的な適用"]
    layers["Layersキーへ直接設定"] --> always["恒久適用"]
    sdb["sdbで配布"] --> always

図13: 環境変数方式は子プロセス限定の一時適用で、恒久化はLayersキーか.sdbで行う。

アプリを改修できるなら、互換設定を増やすよりも、設定ファイルの保存先を%APPDATA%配下へ移し、マニフェストでasInvokerを宣言するのが本来の修正です。³

8. 組織へ展開する ── Compatibility Administratorとsdbinst

8.1. アプリとツールの32bit/64bitを合わせる

Compatibility Administratorは、Windows ADK(Windows Assessment and Deployment Kit)に含まれます。¹² 32bit版と64bit版がインストールされ、32bitアプリの修正には32bit版を、64bitアプリには64bit版を使います。¹³

もう1つの注意は、管理者としてテストして「直った」と判断しないことです。昇格状態ではUAC仮想化やリダイレクトが本来のように働かず、結果を誤判定することがあります。修正の効果は、実際の利用者と同じアカウント・権限で確認します。²

flowchart TB
    accTitle: Compatibility Administrator利用時の2つの注意
    accDescr: 32bitアプリの修正には32bit版を、64bitアプリには64bit版を使い、修正の効果は昇格状態ではなく実際の利用者と同じアカウントと権限で確認する
    app32["32bitアプリ"] --> tool32["32bit版で修正"]
    app64["64bitアプリ"] --> tool64["64bit版で修正"]
    elev["昇格状態でテスト"] -.-> wrong["直ったと誤判定の恐れ"]
    user["実利用者と同じ権限でテスト"] --> ok["効果を正しく確認"]

図14: 32bit版と64bit版の使い分けと、実際の利用者と同じ権限での確認が入口の注意点。

8.2. まずレイヤーで試し、必要なシムと対象EXEに絞る

カスタム互換データベースの作成は、次の順に進めます。¹⁴

1. 左ペインの「Custom Databases」で新規データベースを作り、「Create New」→「Application Fix」を選びます。
2. アプリ名・ベンダー名を入力し、対象のEXEファイルを指定します。
3. 「Windows XP互換」のような互換モード(レイヤー)を選び、まずシムの束で試します。
4. 必要なら個別の互換修正を選びます。VersionLieだけ、CorrectFilePathsだけ、といった最小構成に絞れます。
5. ファイルサイズ・チェックサム・バージョンなどのマッチング条件を確認して保存します。

「効くシムを選ぶ」と「正しいEXEにだけ効かせる」は、どちらも必要です。マッチングは既定の基本条件で通常は十分ですが、アプリのバージョンを特定できる条件は残してください。ベンダーが修正版を出した後、その新バージョンにまで古い修正を当て続けないためです。¹⁴¹⁵

flowchart TB
    accTitle: カスタム互換データベースを作る手順
    accDescr: 新規データベースにApplication Fixを作成し、アプリ名と対象EXEを指定し、互換モードの束で試してから必要なら個別のシムに絞り込み、マッチング条件を確認して保存する
    new["新規データベースを作成"] --> fix["Application Fixを選ぶ"]
    fix --> info["アプリ名と対象EXEを指定"]
    info --> layer["互換モードの束で試す"]
    layer --> single["必要なら個別シムに絞る"]
    single --> match["マッチング条件を確認し保存"]
    match -.-> ver["バージョン特定の条件を残す"]

図15: Application Fixはまず互換モードの束で試し、最小構成に絞り、マッチング条件で対象を限定する。

作成した.sdbを検証機で試し、狙いどおり動くことを確認してから配布へ進みます。

8.3. sdbinstで適用・解除し、GUIDで更新を管理する

各PCへの適用は、管理者権限でsdbinst.exeを実行します。インストールだけでなく、ファイル指定またはデータベースGUID指定でアンインストールできます。¹⁵

:: インストール(-q は確認なしのサイレント)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: アンインストール(ファイル指定)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: アンインストール(データベースGUID指定)
sdbinst -q -u -g {データベースのGUID}

互換修正が増える組織では、アプリのインストーラーごとに個別の.sdbを持たせるより、会社で1つ、または部門ごとのカスタムデータベースへ集約し、集中管理する方式が勧められます。多数の1行データベースを追うより、集約したデータベースを更新・再配布するほうが管理しやすいためです。¹⁵

カスタムデータベースには固有のGUIDがあります。同じGUIDの新バージョンをインストールすると、旧バージョンは自動的に置き換わります。 配布はMSIパッケージやスタートアップスクリプトなど、管理者権限で実行できる既存の経路に載せます。¹⁵

flowchart TB
    accTitle: カスタム.sdbの作成から配布までの流れ
    accDescr: Compatibility Administratorでカスタム互換データベースを作成して検証機でテストし、sdbinstで各PCへ適用し、更新時は同じGUIDの新バージョンをインストールすると旧バージョンが自動的に置き換えられる
    make["Compatibility Administratorで作成"] --> test["検証機でテスト"]
    test --> deploy["sdbinstで各PCへ適用"]
    deploy --> update["同じGUIDの新版をインストール"]
    update -.-> replace["旧バージョンは自動的に置き換え"]
    deploy -.-> inv["プログラムと機能に登録される"]

図16: カスタム.sdbは作成・検証・sdbinst配布の流れで展開し、更新はGUIDで管理する。

インストール済みのカスタムデータベースは「プログラムと機能(インストールされているアプリ)」にも登録され、棚卸しや削除の確認に使えます。どのPCにどの.sdbを入れたかは、資産管理台帳にも残しておきます。

9. 動いた後に決める ── 延命の保守と移行の期限

9.1. OSが提供する修正と、自組織の適用判断を分ける

シムで動くようになっても、アプリの問題そのものを直したわけではありません。シムは特定のAPIの使い方に合わせた応急処置で、OSの実装が変われば前提が崩れることがあります。

Microsoft提供のシム自体は、Windowsの一部としてWindows Updateで保守されます。¹ 一方、カスタムデータベースで何を当てたか、その組み合わせで業務を続けられるかを管理するのは自組織です。機能更新ごとの検証まで、延命の費用に含めてください。

flowchart TB
    accTitle: 応急処置としてのシムと保守責任
    accDescr: シムは特定のAPIの使い方に合わせた嘘でOS側の実装が変われば前提が崩れる、Microsoft提供のシムはWindows Updateで保守されるが、カスタムデータベースで当てた嘘の面倒を見るのは自組織で、機能更新のたびの検証が延命の費用になる
    shim["シムは応急処置の嘘"] --> break["OS実装が変われば前提が崩れる"]
    ms["Microsoft提供のシム"] --> wu["Windows Updateで保守"]
    own["カスタムデータベースの嘘"] --> self["面倒を見るのは自組織"]
    self --> cost["機能更新ごとの検証が延命の費用"]

図17: シムという嘘の保守責任は、Microsoft提供分と自組織のカスタム分で分かれる。

9.2. 残り利用期間・依存・検証体制で判断する

「互換モードで動いた」という事実だけで、長期利用を決めないことが重要です。シムで動くのは、Windowsが用意した受け皿に収まったということです。次の軸を合わせて判断します。

9.3. 延命するなら、記録・検証・期限を一組にする

1. 記録する。 どのEXEに、どのシム・レイヤーを、なぜ当てたかを残します。Layersキーの値と.sdbのGUIDも台帳に載せます。「なぜ動くのか誰も知らない」状態を次の担当者へ渡さない、という考え方は、ソースコードも仕様書もないシステムを引き継いだらで扱った保全と同じです。
2. 検証する。 Windowsの機能更新時に、延命中アプリの起動・主要操作を確認します。Windows 10サポート終了後の現実解で扱うOS入れ替えの計画とも連動させます。
3. 期限を切る。 「次の基幹システム更改まで」「2028年3月まで」のように延命の終わりを決め、移行の検討を並走させます。

flowchart TB
    accTitle: 延命と決めた場合の運用3点セット
    accDescr: どのシムで動いているかを台帳に記録し、機能更新のたびにシム延命中アプリの動作を検証し、延命の期限を切って移行の検討を並走させる
    decide["延命と決める"] --> rec["記録：何のシムで動くか台帳へ"]
    rec --> verify["検証：機能更新ごとに動作確認"]
    verify --> deadline["期限：延命の終わりを決める"]
    deadline --> mig["移行の検討を並走させる"]

図18: 延命は記録・検証・期限の3点セットに移行検討の並走まで含めて運用する。

9.4. シムは、移行の検討・準備期間を稼ぐために使う

移行の選択肢は、アプリの技術によって変わります。VB6製なら、VB6アプリはいつまで動くのかで整理した全面リライト・自動変換・段階移行の3択が出発点です。ActiveX/OCX依存なら、ActiveX / OCX を今どう扱うかの「残す・包む・置き換える」の判断表が使えます。

シムは、こうした移行プロジェクトの検討・準備期間を安全に稼ぐための手段、と位置づけるのが健全です。

flowchart TB
    accTitle: 移行側の選択肢とシムの位置づけ
    accDescr: 移行の定石はアプリの技術によって変わり、VB6製なら全面リライトと自動変換と段階移行の3択、ActiveX依存なら残す包む置き換えるの判断表が使え、シムは移行プロジェクトの検討と準備の期間を安全に稼ぐ時間稼ぎと位置づける
    tech{"アプリの技術は?"} -->|VB6製| vb["リライト・自動変換・段階移行"]
    tech -->|ActiveX依存| ax["残す・包む・置き換える"]
    shim["シムでの延命"] -.->|検討と準備の時間を稼ぐ| tech

図19: 移行の定石はアプリの技術で決まり、シムはその検討期間を稼ぐ時間稼ぎと位置づける。

10. まとめ

互換モードは、アプリにだけ古いWindowsを前提とした動作を補う仕組みです。 中心となるシムはIATの差し替えなどでAPI呼び出しに割り込み、バージョン判定やアクセス先を補います。Windows自身も既定のデータベースやPCAを通して利用しています。

対応は、まずシムの適用範囲かを切り分け、互換性タブやRunAsInvokerで必要な設定を確認し、組織展開ではCompatibility Administratorとsdbinstで管理する、という順で考えます。32bit/64bitのツール選択、実際の利用者の権限での検証、マッチング条件とGUIDによる対象・版の管理が実務の要点です。

ただし、ユーザーモード限定であり、セキュリティ機構を回避するものではありません。カーネルドライバー、64bit Windows上の16bitアプリ、ハードウェア直接アクセスの問題は別の対策が必要です。RunAsInvokerも、不要な昇格要求を抑えるだけで権限は増やしません。

動いた後に、設定を記録し、機能更新のたびに検証し、期限を切って移行を並走させる。 ここまで含めて、互換モードに頼る判断です。

次にチェック1つで古いアプリが動いたら、こう問い直してください。「このアプリは、どの嘘のおかげで動いているのか。その嘘はいつまで通用するか」。答えられるなら、延命は立派な戦略です。

関連記事

• レジストリの32bit/64bitリダイレクトと仮想化の落とし穴 ── Wow6432Nodeと「書いたはずの値がない」問題
• VB6アプリはいつまで動くのか ── ランタイムのサポート状況と現実的な.NET移行の進め方
• ActiveX / OCX を今どう扱うか - 残す・包む・置き換える判断表
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表
• ソースコードも仕様書もないシステムを引き継いだら ── 止めずに運用・保守するための実務手順
• Windowsシェル統合の今 ── 右クリックメニュー・ファイル関連付け・Windows 11の変化

関連する相談領域

合同会社小村ソフトでは、ソースコードのない古い業務アプリの動作調査と延命設計(シム・互換モードの選定、カスタム.sdbの作成と展開)、Windows 11移行にともなう既存アプリの互換性検証、そして延命と並走する作り直し・移行の計画づくりを扱っています。「互換モードで動いてしまったが、このままでいいのか」という段階からの相談で構いません。

• 既存資産活用・移行支援
• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

互換モードにチェックを入れたら動いたアプリは、そのまま使い続けていいですか？

当面の業務継続という意味では使い続けて問題ありません。互換モードの実体はシムと呼ばれるユーザーモードのAPIフックで、OSの設定として正式に用意された仕組みだからです。ただし、シムはあくまでアプリを直さずに動かすための応急処置であり、OSの更新で前提が変わればまた動かなくなる可能性があります。互換モードで動いている事実は台帳に記録し、そのアプリを作り直すか、計画的に延命するかの判断とセットで運用してください。

互換モードのチェックボックスは、具体的に何をしているのですか？

プロパティの互換性タブで設定を保存すると、HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers キーに、対象EXEのパスと「WINXPSP3」「HIGHDPIAWARE」のような値が書き込まれます。次にそのEXEを起動するとき、Windowsのローダーがこの値を読み、対応する互換レイヤー(シムの束)をプロセスに適用します。たとえばWindows XP互換モードなら、OSバージョンを問い合わせるAPIに古い値を返すバージョン詐称などが働きます。OS本体の動作を変えているのではなく、そのプロセスにだけ「昔のWindowsのふり」をして見せる仕組みです。

16bit時代の古いアプリは64bit Windowsの互換モードで動かせますか？

動かせません。64bit WindowsはWOW64という仕組みで32bitアプリを実行しますが、16bitアプリの実行はサポートしておらず、起動しようとするとERROR_BAD_EXE_FORMATで失敗します。これはシムでは回避できないアーキテクチャ上の制限です。インストーラーの起動部分だけが16bitという古いパッケージも同じ理由で失敗します。どうしても必要な場合は、32bit版Windowsを含む仮想マシンなど、互換モード以外の手段を検討することになります。

「管理者として実行しないと起動しない」アプリを、一般ユーザー権限のまま動かせますか？

試す価値があるのがRunAsInvokerです。コマンドプロンプトで set __COMPAT_LAYER=RunAsInvoker を実行してからアプリを起動すると、マニフェストのrequireAdministrator指定やインストーラー検出による昇格要求が抑止され、呼び出し元と同じ(一般ユーザーの)権限で起動します。管理者権限を「要求するだけで実際には使っていない」アプリなら、これだけで日常運用から昇格を排除できます。ただし権限が増えるわけではないので、本当に管理者権限が必要な処理はそのアプリ内で失敗します。動作確認のうえで採用してください。

Compatibility Administratorはどこで入手できますか？

Windows ADK(Windows Assessment and Deployment Kit)に含まれています。MicrosoftのサイトからADKをダウンロードし、インストール時にApplication Compatibility Tools系の機能を選択すると使えるようになります。32bit版と64bit版の両方がインストールされ、32bitアプリの修正には32bit版を、64bitアプリには64bit版を使う必要がある点に注意してください。作成したカスタム互換データベース(.sdb)は、各PCでsdbinstコマンドを実行して適用します。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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