Windows の「The evolution of window and class extra bytes in Windows」は、一般的な新機能の発表というより、Win32 アプリケーション互換性に関わる重要な設計ルールを整理した公式解説です。結論から言うと、Windows 管理者が直ちにポリシー変更や設定変更を行う必要はありません。ただし、社内で古い Win32 アプリ、業務アプリ、VBA・C++・C# のネイティブ連携コードを保守している場合は、GetWindowLong / SetWindowLong などの 32bit 前提の API 利用を棚卸しし、ポインターやハンドルを扱う箇所では GetWindowLongPtr / SetWindowLongPtr へ移行できているかを確認する価値があります。
Microsoft は 2026年6月29日に、Windows の「window extra bytes」と「class extra bytes」が 16bit、32bit、64bit Windows の流れの中でどのように変化してきたかを解説しました。ポイントは、GWL_、GWLP_、GCL_、GCLP_、DWLP_ といったプレフィックスには「どの関数で扱うべき値か」という意図が埋め込まれていることです。つまり、名前の違いは単なる命名規則ではなく、64bit 対応や整数切り捨てバグを避けるための実務上の手掛かりになります。(Microsoft for Developers)
Windows の「The evolution of window and class extra bytes in Windows」とは
「The evolution of window and class extra bytes in Windows」は、Windows の古典的な Win32 API における追加メモリ領域、つまり extra bytes の歴史と命名規則を説明した Microsoft Dev Blogs の記事です。対象は主に Windows デスクトップアプリの開発者、互換性検証担当者、古い業務アプリを保守する情シス・開発チームです。
Windows のウィンドウには、ウィンドウクラスに属する追加領域と、個々のウィンドウに属する追加領域があります。前者が class extra bytes、後者が window extra bytes です。アプリケーションはクラス登録時に追加領域を要求でき、Windows 側もシステム定義のオフセットを用意しています。Microsoft の解説では、このシステム定義オフセットの名前が、16bit 時代から 32bit、64bit へ移行する中でどのように変化したかが整理されています。(Microsoft for Developers)
この記事で管理者が押さえるべき点は、次の3つです。
- Windows の設定項目が追加されたわけではない
- 既存アプリの互換性に直結する API 利用ルールの確認が主目的
- 64bit Windows でポインターやハンドルを扱うコードは、Ptr 系 API の利用確認が必要
特に古い C/C++ アプリや、Windows API を直接呼び出す Office VBA、.NET の P/Invoke、古い UI フレームワークを含むアプリでは、64bit 化の過程でこの領域が問題になることがあります。
今回の更新ポイントは「プレフィックスに意図がある」こと
今回の公式解説で最も重要なのは、「The intended usage is encoded in the prefix.」という考え方です。日本語で言えば、「どの用途で使うべきかはプレフィックスに表れている」という意味です。
たとえば、GWL_ は Get Window Long、GWLP_ は Get Window Long Ptr、GCL_ は Get Class Long、GCLP_ は Get Class Long Ptr と対応します。Ptr が付くものは、32bit Windows では 32bit、64bit Windows では 64bit になるポインターサイズの整数を扱う意図があります。Microsoft Learn でも、32bit と 64bit の両方に対応するコードを書く場合は GetWindowLongPtr を使うよう説明されています。(Microsoft Learn)
| プレフィックス | 主な意味 | 使うべき関数の目安 | 実務上の見方 |
|---|---|---|---|
GCW_ | Get Class Word | GetClassWord | 16bit 時代の名残が強い |
GWW_ | Get Window Word | GetWindowWord | 16bit 値を扱う古い設計 |
GCL_ | Get Class Long | GetClassLong | 32bit 値を扱う |
GWL_ | Get Window Long | GetWindowLong | 32bit 値を扱う |
GCLP_ | Get Class Long Ptr | GetClassLongPtr | ポインターサイズの値を扱う |
GWLP_ | Get Window Long Ptr | GetWindowLongPtr | 64bit 対応で特に重要 |
DWLP_ | Dialog Window Long Ptr | GetWindowLongPtr / SetWindowLongPtr | ダイアログ用のポインターサイズ値 |
この表で実務上重要なのは、Long と LongPtr を曖昧に扱わないことです。32bit アプリでは問題が見えなくても、64bit 化したときにポインターやハンドルの上位 32bit が失われると、クラッシュ、表示不具合、メッセージ処理の異常につながる可能性があります。
影響範囲：一般ユーザーよりも開発・運用チーム向け
今回の情報は、Windows Update のように全ユーザーへ新しい挙動が展開されるタイプの変更ではありません。影響を受けやすいのは、Windows のネイティブ API を直接または間接的に利用しているアプリケーションです。
特に確認したいのは、次のような環境です。
| 対象 | 影響の有無 | 確認すべき理由 |
|---|---|---|
| 一般的な Windows 利用者 | 低い | 設定変更や操作変更は基本的に不要 |
| Windows 管理者 | 中程度 | 社内アプリの 64bit 対応状況を把握する必要がある |
| C/C++ の Win32 アプリ開発者 | 高い | GetWindowLong / SetWindowLong の誤用が不具合につながる |
| VBA から Windows API を呼ぶ業務ツール | 中〜高 | 32bit Office から 64bit Office への移行時に問題化しやすい |
| .NET の P/Invoke 利用アプリ | 中程度 | IntPtr ではなく int で受けていると危険 |
| パッケージ製品の利用企業 | 中程度 | ベンダー製アプリの 64bit 対応状況を確認する材料になる |
管理者の観点では、「Windows の設定を変える」よりも「資産管理台帳やアプリ棚卸しに反映する」ことが現実的です。古い業務アプリを 64bit Windows、64bit Office、仮想デスクトップ、アプリ仮想化環境へ移す予定がある場合は、検証観点に追加しておくとよいでしょう。
設定変更は必要か
今回の公式情報に基づく限り、Windows 管理者がグループポリシー、Intune、レジストリ、Windows Update の設定を変更する必要は示されていません。これは OS の新しい管理機能ではなく、Win32 API の歴史的背景と安全な使い分けを説明する内容です。(Microsoft for Developers)
ただし、設定変更が不要だからといって、何もしなくてよいとは限りません。実務では次のように判断します。
| 状況 | 推奨アクション |
|---|---|
| 社内アプリがすべて Web アプリ中心 | 特別な対応は不要。Windows API 直接利用の有無だけ確認 |
| 古い C++ 製業務アプリがある | ソースコードまたはベンダー資料で GetWindowLong / SetWindowLong 利用を確認 |
| 64bit Office へ移行予定 | VBA の Declare 文、Long / LongPtr、PtrSafe の確認を実施 |
| 32bit アプリを 64bit 化中 | GWL_ から GWLP_ へ置き換えるべき箇所をレビュー |
| ベンダーアプリで UI 不具合が出ている | 64bit 対応状況、サブクラス化、ウィンドウプロシージャ変更の有無を問い合わせる |
ポイントは、Windows 側の設定ではなく、アプリ側の実装と検証に目を向けることです。
移行期限はあるか
今回の「The evolution of window and class extra bytes in Windows」に関して、Microsoft は特定の移行期限や廃止期限を示していません。したがって、「何月何日までに設定を変更しなければならない」というタイプの対応ではありません。
一方で、64bit Windows への対応という観点では、実質的な移行期限は組織ごとの環境更新計画に左右されます。たとえば次のタイミングでは、古い API 利用が表面化しやすくなります。
- 32bit アプリを 64bit アプリへ移行する
- 32bit Office から 64bit Office へ切り替える
- 古い業務端末を Windows 11 以降の標準端末へ更新する
- VDI、Azure Virtual Desktop、Citrix などへアプリを移す
- 古い UI 部品やサブクラス化を含むアプリを再ビルドする
- セキュリティ強化のため、古い未署名 DLL や互換レイヤーを廃止する
つまり、公式な一律期限はなくても、社内の端末更改やアプリ刷新のタイミングが実務上の期限になります。
なぜ GetWindowLongPtr / SetWindowLongPtr が重要なのか
16bit Windows ではハンドルも小さく、Word や Long の使い分けで足りる場面が多くありました。32bit Windows ではハンドルやポインターが 32bit に拡大し、さらに 64bit Windows ではポインターやハンドルが 64bit サイズになります。Microsoft の解説では、64bit Windows への移行時に、ポインターやハンドルを保持する可能性がある extra bytes はポインターサイズに拡張されたと説明されています。(Microsoft for Developers)
ここで重要なのが、Long と LongPtr の違いです。
GetWindowLong は 32bit 値を取得する関数です。Microsoft Learn でも、ポインターやハンドルを取得する場合は GetWindowLongPtr に置き換えられていると説明されています。(Microsoft Learn)
一方、SetWindowLongPtr は指定したウィンドウの属性や extra window memory の値を設定する関数で、32bit と 64bit の両方に対応するコードを書く場合に使うべき関数として案内されています。(Microsoft Learn)
実務でよくある問題は、次のようなコードです。
LONG oldProc = GetWindowLong(hwnd, GWL_WNDPROC);
SetWindowLong(hwnd, GWL_WNDPROC, (LONG)newProc);32bit 前提なら動いていたとしても、64bit 環境ではポインターサイズが合わず危険です。見直し後は、概念的には次のように考えます。
LONG_PTR oldProc = GetWindowLongPtr(hwnd, GWLP_WNDPROC);
SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)newProc);ここで大切なのは、関数だけでなく、プレフィックスと型も合わせて見直すことです。GetWindowLongPtr を使っているのに GWL_ をそのまま使う、戻り値を LONG や int に入れる、といった中途半端な修正は避けるべきです。
GWL_ を GWLP_ に置き換えれば十分とは限らない
64bit 対応のレビューでは、「GWL_ を検索して GWLP_ に置き換える」だけでは不十分です。理由は、すべての値がポインターサイズになるわけではないためです。
たとえば、ウィンドウスタイルや拡張スタイルのように 32bit 値として扱うものは、引き続き GWL_STYLE や GWL_EXSTYLE が使われます。一方で、ウィンドウプロシージャ、インスタンスハンドル、ユーザーデータ、ダイアログプロシージャなど、ポインターやハンドルを保持する可能性があるものは Ptr 系を検討します。
| 確認対象 | ありがちな誤り | 見直しの方向性 |
|---|---|---|
GWL_WNDPROC | ウィンドウプロシージャを LONG に格納 | GWLP_WNDPROC と LONG_PTR / WNDPROC を使う |
GWL_USERDATA | ポインターを int にキャスト | GWLP_USERDATA と LONG_PTR / IntPtr を使う |
DWL_DLGPROC | ダイアログプロシージャを 32bit 値として扱う | DWLP_DLGPROC の利用を確認 |
GWL_STYLE | 何でも GWLP_ に置き換える | スタイルは 32bit 値として扱う |
GWL_EXSTYLE | 拡張スタイルまで Ptr 化する | こちらも 32bit 値として確認 |
GWL_ID | ID にポインターを入れる | ID とポインターの混用を避ける |
Microsoft の解説では、64bit 移行時にプレフィックスを変えた理由について、ビルド時に修正が必要な箇所をあえて検出しやすくするためだと説明しています。これは、整数切り捨てバグを見逃さないための設計上の工夫です。(Microsoft for Developers)
管理者が確認すべきポイント
Windows 管理者や情報システム部門は、ソースコードの細部まで理解していなくても、次の観点で確認できます。
社内アプリの 32bit / 64bit 状況を棚卸しする
まず、社内で使っている Windows アプリを 32bit と 64bit に分けて整理します。古いアプリが 32bit のままでも、64bit Windows 上で動作しているだけならすぐに問題化しないこともあります。しかし、再ビルド、Office 連携、DLL 差し替え、UI 部品の更新が入ると不具合が出る可能性があります。
棚卸しでは、次の情報を残しておくと後で役立ちます。
| 確認項目 | 記録例 |
|---|---|
| アプリ名 | 受注管理システム、検査端末ツールなど |
| 実行形式 | 32bit / 64bit / 不明 |
| 開発元 | 内製、外部ベンダー、パッケージ |
| Windows API 利用 | あり、なし、不明 |
| Office 連携 | 32bit Office 前提、64bit Office 対応済みなど |
| 移行予定 | Windows 11 更新時、VDI 移行時、次期更改時など |
ベンダーに確認する質問を具体化する
パッケージ製品や外部委託アプリの場合、単に「64bit 対応していますか」と聞くだけでは不十分です。次のように確認すると、実装面のリスクが見えやすくなります。
GetWindowLong/SetWindowLongを使ったウィンドウプロシージャ変更はありますか- 64bit 版で
GetWindowLongPtr/SetWindowLongPtrを使用していますか - VBA、COM、ActiveX、古い DLL 連携は 64bit Office に対応していますか
- ウィンドウのサブクラス化やフック処理を使っていますか
- 64bit Windows での UI 自動操作、印刷、ダイアログ表示の検証実績はありますか
特に、画面の一部が反応しない、ダイアログが閉じない、印刷ダイアログで落ちる、特定のボタン操作でクラッシュする、といった不具合は、UI メッセージ処理やサブクラス化に関連している可能性があります。
ソースコードがある場合は API 名で検索する
内製アプリや保守可能なソースコードがある場合は、まず単純検索で対象箇所を洗い出します。
検索したいキーワードは次の通りです。
GetWindowLong
SetWindowLong
GetClassLong
SetClassLong
GWL_
GCL_
DWL_
GWLP_
GCLP_
DWLP_
LONG_PTR
IntPtr
PtrSafeC/C++ だけでなく、C# の P/Invoke、VB.NET、VBA、Delphi、古いマクロにも注意が必要です。特に VBA では、64bit Office 対応時に LongPtr や PtrSafe の修正が必要になるケースがあります。
テストでは「起動するか」だけでなく UI 操作まで見る
64bit 対応の互換性テストでは、アプリが起動するだけでは不十分です。window extra bytes や window procedure の問題は、起動直後ではなく、特定の UI 操作で表面化することがあります。
確認したい操作例は次の通りです。
| テスト項目 | 確認内容 |
|---|---|
| メイン画面の表示 | 起動直後にクラッシュしないか |
| ダイアログ表示 | 設定画面、検索画面、印刷画面が正常に開くか |
| ボタン操作 | クリック後に反応が止まらないか |
| 入力欄操作 | IME、フォーカス移動、タブ移動が正常か |
| 印刷・プレビュー | 共通ダイアログや独自ダイアログで落ちないか |
| アドイン連携 | Office、ブラウザ、外部 DLL 連携が動くか |
| 長時間利用 | メモリ破損や不定期クラッシュが起きないか |
「32bit 版では問題ないが 64bit 版でだけ落ちる」という場合、単なる OS の問題ではなく、ポインターサイズに依存した実装ミスが隠れている可能性があります。
開発者が確認すべき実装ポイント
開発者は、プレフィックス、関数、型の3点をセットで確認する必要があります。
関数とプレフィックスをそろえる
GetWindowLongPtr を使うなら GWLP_、GetClassLongPtr を使うなら GCLP_、ダイアログ関連なら DWLP_ を確認します。Microsoft の解説では、名前のプレフィックスから、どの関数と組み合わせる意図かを読み取れると説明されています。(Microsoft for Developers)
悪い修正例は、関数だけを変えて型や定数をそのままにすることです。
LONG oldValue = GetWindowLongPtr(hwnd, GWL_USERDATA);このようなコードは、一見 64bit 対応に見えても、戻り値を 32bit の LONG に入れているため危険です。次のように、戻り値の型も合わせて見直します。
LONG_PTR oldValue = GetWindowLongPtr(hwnd, GWLP_USERDATA);ポインターやハンドルを int に入れない
64bit Windows では、ポインターやハンドルを int や LONG に入れると情報が失われる可能性があります。C/C++ では LONG_PTR、UINT_PTR、DWORD_PTR、INT_PTR などを適切に使います。.NET では IntPtr を使うのが基本です。
特に P/Invoke では、宣言が 32bit 前提のまま残っていることがあります。
// 32bit 前提になりやすい例
[DllImport("user32.dll")]
static extern int GetWindowLong(IntPtr hWnd, int nIndex);64bit 対応では、用途に応じて GetWindowLongPtr 相当の宣言を用意し、戻り値を IntPtr で扱う設計にします。アプリの対象フレームワークや実行環境によって宣言方法は変わるため、既存コードの呼び出し箇所とセットで確認してください。
SetWindowLongPtr の戻り値とエラー処理を確認する
SetWindowLongPtr は、指定したウィンドウ属性や extra window memory の値を変更します。Microsoft Learn では、ウィンドウプロシージャを変更することでサブクラスを作成できる一方、別プロセスで作成されたウィンドウクラスをサブクラス化すべきではないこと、処理しないメッセージは CallWindowProc で前のプロシージャへ渡す必要があることも説明されています。(Microsoft Learn)
実務では、次の点も合わせて確認します。
| 確認項目 | 理由 |
|---|---|
| 変更前のウィンドウプロシージャを保存しているか | 後続処理や復元に必要 |
CallWindowProc で未処理メッセージを渡しているか | メッセージチェーン破壊を防ぐ |
| 別プロセスのウィンドウを不用意に変更していないか | 安定性・セキュリティ上の問題になる |
| 戻り値 0 の扱いを誤っていないか | 失敗と以前の値 0 を区別する必要がある |
| 32bit / 64bit 両方でテストしているか | 片方だけでは型の問題を見逃しやすい |
よくある失敗パターン
「動いているから問題ない」と判断する
32bit Windows や 32bit アプリで長年動いていたコードでも、64bit 化で問題が出ることがあります。ポインターサイズの問題は、すべての環境ですぐにクラッシュするとは限りません。特定のメモリアドレス、特定の操作、特定の DLL 組み合わせでだけ発生することもあります。
そのため、「起動できる」「一通り画面が出る」だけで合格にせず、業務シナリオに沿った操作テストが必要です。
一括置換で修正する
GWL_ をすべて GWLP_ に置き換えるような一括対応は危険です。スタイルや拡張スタイルのように 32bit 値として扱うものもあります。置換ではなく、値の用途を見て判断する必要があります。
判断基準はシンプルです。
- ポインター、ハンドル、プロシージャ、ユーザーデータを扱うなら Ptr 系を疑う
- スタイル、拡張スタイル、サイズ値、フラグ値は 32bit のままか確認する
- ダイアログ関連は
DWLP_を確認する - 型は
LONGではなくLONG_PTRやIntPtrが必要か確認する
VBA の 64bit 対応を軽く見る
Office マクロや Access 業務アプリでは、Windows API 呼び出しが残っていることがあります。32bit Office では動いていた Declare 文が、64bit Office でコンパイルエラーや実行時エラーになることがあります。
特に Long でハンドルやポインターを受けているコードは注意が必要です。PtrSafe や LongPtr への対応は、単なる構文修正ではなく、呼び出している API の意味まで確認する必要があります。
ベンダーに「Windows 11 対応」だけ確認する
「Windows 11 対応済み」と「64bit ネイティブ実装で安全にポインターサイズを扱っている」は同じ意味ではありません。互換レイヤーや 32bit アプリとして動作している場合もあります。
ベンダー確認では、次のように一歩踏み込んで聞くとよいでしょう。
- 64bit 版アプリとして提供されていますか
- Windows API の
LongPtr対応は完了していますか - 32bit Office と 64bit Office のどちらを前提にしていますか
- UI フック、サブクラス化、独自ダイアログの 64bit 検証は済んでいますか
- 既知の制限や推奨構成はありますか
グローバル環境での確認ポイント
グローバル企業では、国や拠点ごとに端末更改、Office の bit 数、アプリ配布方法が異なることがあります。そのため、Windows API の互換性問題は一部拠点だけで発生することがあります。
たとえば、日本拠点では 32bit Office、米国拠点では 64bit Office、欧州拠点では VDI という構成になっている場合、同じ業務アプリでも挙動が変わる可能性があります。管理者は、OS バージョンだけでなく、アプリの bit 数、Office の bit 数、配布方式、ローカル DLL の有無まで確認する必要があります。
| 確認観点 | グローバル運用での注意点 |
|---|---|
| OS 標準化 | Windows 11 でも 32bit アプリは残ることがある |
| Office の bit 数 | 32bit / 64bit が拠点で混在しやすい |
| 言語環境 | IME や入力欄周りの不具合が地域限定で出る場合がある |
| アプリ配布 | Intune、SCCM、VDI、手動配布で DLL が異なることがある |
| ベンダーサポート | 国別バージョンやローカルカスタマイズに注意 |
| テスト体制 | 本社環境だけでなく主要拠点の代表構成で確認する |
グローバル向けには、単に「最新版 Windows で動くか」ではなく、「各拠点の実行環境で同じように動くか」を見ることが重要です。
今回の情報を受けた実務チェックリスト
Windows 管理者、開発者、アプリオーナーは、次の順番で確認すると効率的です。
| 手順 | 確認内容 | 担当の目安 |
|---|---|---|
| 1 | 古い Win32 アプリ、VBA、P/Invoke 利用アプリを洗い出す | 情シス、アプリ管理者 |
| 2 | 32bit / 64bit の実行形態を確認する | 情シス、開発チーム |
| 3 | GetWindowLong / SetWindowLong / GWL_ などを検索する | 開発チーム |
| 4 | ポインターやハンドルを扱う箇所を Ptr 系 API へ見直す | 開発チーム |
| 5 | LONG、int、Long に格納していないか確認する | 開発チーム |
| 6 | 64bit Windows、64bit Office、VDI など代表環境でテストする | QA、情シス |
| 7 | ベンダー製品は 64bit 対応範囲を文書で確認する | 調達、情シス |
| 8 | 端末更改や Office 移行計画にリスクとして記録する | IT 管理者 |
このチェックリストの目的は、すべてのコードを即時修正することではありません。重要なのは、次の環境更新で問題になりそうな箇所を早めに可視化することです。
まとめ：Windows の設定変更ではなく、互換性レビューの観点として扱う
Windows の「The evolution of window and class extra bytes in Windows」は、管理画面に新しい設定が追加されるような更新ではありません。管理者が今すぐ GPO や Intune の設定を変更する必要も、公式に示された移行期限もありません。
ただし、古い Win32 アプリや 32bit 前提の業務ツールを持つ組織にとっては、64bit 対応の見落としを防ぐための重要なヒントになります。GWL_、GWLP_、GCL_、GCLP_、DWLP_ といったプレフィックスは、単なる名前ではなく、使うべき関数と値のサイズを判断する手掛かりです。
次に取るべき行動は明確です。社内アプリの棚卸しで、Windows API を直接使うアプリ、VBA や P/Invoke を含むツール、古い 32bit 前提の UI アプリを洗い出してください。そのうえで、64bit 化や Windows 11 展開、Office 64bit 移行、VDI 移行の前に、GetWindowLong / SetWindowLong と Ptr 系 API の使い分けを検証項目に追加することが、実務上もっとも効果的な対応です。
コメント