社内に残る古いWindowsアプリを塩漬けにしている情報システム部門や、レガシー資産の移行計画を任されているエンジニアに向けた内容です。2026年初頭、Hacker News（技術者向けニュース共有サイト）で話題になったある投稿が、この問題の輪郭をはっきりさせてくれました。
話題の中心は「Microsoft Word 1.1a for Windows」を現行の64bit Windows 11でネイティブ動作させたという報告です。1989年にリリースされたこのWord 1.1aは16bitアプリケーションで、本来はエミュレータ（旧環境の動作を模倣するソフトウェア）や仮想マシンなしには動きません。この事例は懐古趣味の話にとどまらず、社内システムの保守運用に直結する教訓を含んでいます。
何が起きるか：16bitアプリは64bit Windowsで単純に動かない
16bitのWindowsアプリケーションは、64bit版Windowsでは原則として起動できません。これは仕様の隅にある例外ではなく、OSのアーキテクチャそのものに起因する制約です。
32bit版のWindowsであれば、NTVDM（NT Virtual DOS Machine、16bitアプリを実行するための互換レイヤー）を通じて動作させられる場合がありました。しかしMicrosoftは32bit Windowsでも2020年頃にこの互換性を段階的に整理し、Windows 11では32bit版自体が提供されていません。つまり社内に「32bit版だから何とか動く」という逃げ道すら残っていないケースが増えています。
影響範囲は古いオフィスソフトだけではありません。1990年代に作られた業務専用ツール、ベンダーが撤退した検査機器の制御ソフト、社内で誰かが個人的に作った16bit時代のユーティリティなど、心当たりのある方は少なくないはずです。
なぜ起きるか：メモリモデルの根本的な違い
原因を段階的に見ていきます。まず16bit Windowsアプリは「セグメントメモリモデル」という仕組みでメモリを扱います。CPUが16bitのセグメントセレクタとオフセットを組み合わせてアドレスを計算する方式で、現在主流のフラットな64bitアドレス空間とは根本的に構造が違います。
次に、当時のWindows 2.x/3.xはGlobalAllocやLocalAllocといったAPIでメモリを管理し、ポインタには「far」「near」の区別がありました。呼び出し元がセグメントを把握しているかどうかで扱いが変わる、今では馴染みのない設計です。
こうした前提がOS側から取り払われた結果、16bitアプリはそのままでは実行環境を見つけられなくなります。エミュレータやVM（仮想マシン）が必要になるのはこのためで、Word 1.1aのネイティブ移植プロジェクトでも、開発者はソースコードなしにバイナリレベルで16bit命令を解析し、x86-64向けに書き直す手法を選んでいます。単純な再コンパイルでは済まない、という事実がこの制約の重さを物語っています。
自分のプロジェクトが該当するか確認する方法
社内に残るアプリが16bitかどうかは、いくつかの方法で確認できます。まず実行ファイルのプロパティです。
# PowerShellでファイル情報を確認する例
Get-Item "C:\LegacyApp\app.exe" | Select-Object Name, Length, LastWriteTimeより確実なのは、実行ファイルのヘッダー構造を見ることです。32bit以降のWindows実行ファイルはPE（Portable Executable）形式ですが、16bitアプリはNE（New Executable）形式という古い構造を持っています。バイナリエディタやfileコマンド相当のツールでヘッダーの先頭マジックナンバーを確認すると、MZの後に続く形式識別子で判別できます。
実務的には次の基準で当たりをつけるのが早道です。
- 開発年代が1995年より前、または「Windows 3.1対応」と明記されている
- インストール先が
Program Files (x86)ではなく古いドライブレターの固定パス - アプリ起動時に「このアプリは実行できません」とWindows 11が表示する
- 開発元・保守ベンダーがすでに存在しない、または問い合わせ窓口がない
- ソースコードの所在が社内で不明、あるいは紙の設計書しか残っていない
該当する項目が複数あれば、リプレースか延命かの判断を急いだ方がよい状態です。
対策の手順
まず現状の動作環境を確認します。すでにWindows 10や旧世代のWindows Serverで動いているなら、いつまでその環境を維持できるかを洗い出してください。Microsoftの製品ライフサイクルページで、使用OSのサポート終了日を確認するのが最初の一歩です。
次に、延命策として仮想化を検討します。Hyper-VやVMware上に古いOSのゲスト環境を構築し、業務アプリをそこに隔離する方法です。ネットワーク分離やアクセス制御を組み合わせれば、セキュリティリスクを抑えながら延命できます。ただしゲストOS自体もサポート切れであることが多く、恒久対策にはなりません。
三つ目の選択肢が再実装です。Word 1.1aの事例のように、バイナリを解析して現代の環境向けに書き直すアプローチは技術的には可能です。しかし現実の業務システムでこれを選ぶ場合、リバースエンジニアリングにかかる工数と、元の業務ロジックを仕様として文書化するコストを見積もる必要があります。ソースコードが残っているなら、言語のバージョンアップや.NET Frameworkから.NETへの移行など、まだ現実的な選択肢が残っています。
最後に、業務要件そのものを見直す視点も欠かせません。30年前に作られた機能の中には、今の業務フローではもう使われていないものも混じっています。移行を機に「本当に必要な機能は何か」を業務部門とすり合わせると、再実装の範囲を絞り込めます。
まとめ
16bitアプリの実行不能は、ある日突然OSアップデートで表面化する問題です。原因はセグメントメモリモデルという古い設計思想とNTVDM廃止という互換性方針の変化にあります。
まず手元の資産で該当するアプリがないか、実行ファイルの形式と開発年代を確認してください。該当するものが見つかったら、仮想化による延命か再実装かを、サポート期限とコストの両面から早めに判断することが大切です。