令和7981年12月31日、それはWindows最後の日：その知識、ホントに正しい？ Windowsにまつわる都市伝説（134）（1/2 ページ）

2019年4月1日、5月1日からの新元号が「令和」に決定、発表されました。Windowsの場合は、Windows Updateで新元号対応が行われるはずだから大丈夫、と安心していませんか？　Windows（3.0）が登場したのは平成が始まってからのこと。改元はWindowsにとって初めてのイベントであり、新元号に対応するための変更が想定外のところに影響しないとも限りませんよ。

[山市良，テクニカルライター]

Windowsにまつわる都市伝説

単に新元号のレジストリが追加されるだけじゃない！

　2019年4月10日の定例のWindows Updateで配布された更新プログラムで、Windowsに「新元号対応の変更」が行われなかったことに疑問を持った人は多いでしょう。

　しかし、新元号対応の変更は、改元が正式に決まって以降、徐々に進められてきたもので、今回の更新プログラムにもこれまでの変更が累積されて含まれています。これまでの変更に未知のバグがあって、今後、修正されることもあるでしょう（これまでもそのようなことが何度かありました）。

　4月の定例更新で多くのユーザーが期待していたことは、2019年5月1日からの新元号「令和」およびその短縮形「令」「R」の表示（書式設定）と解釈（日付変換、日付計算）に対応することだったと思います。

　これは最終的には、レジストリキー「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras」に「2019 05 01」という文字列型の値が追加され、この値に「令和_令_Reiwa_R」が設定されることで行われます。現時点でも手動でレジストリを追加することで変更できますが、これはITプロフェッショナルやアプリケーション開発者がテストのために行うことであって、一般ユーザーが行うことではありません。

　また、変更はこれだけではありません。別の変更点の一つに、「Unicodeに新元号を漢字1文字で表現する合字（U+32FF）が追加される」ことがあります（平成〜明治に対応する合字は既にU+337B〜U+337Eに存在します）。

　Windows Updateにより、「Microsoft IME」の入力変換候補一位に登録されることと勘違いしている人もいるかもしれません。そして気が付いたら、変換候補一位になったことで驚いたかもしれません。しかし、それはあなたの入力が学習されたか、クラウド変換機能が影響したのでしょう。なぜ変換候補一位になったのか知りませんが、今回のWindows Updateとは関係ないはずです。

　Windows、.NET Framework、Microsoft Office、Microsoft Azureなど、その他のMicrosoft製品およびサービスの新元号対応状況については、以下のサポート情報にリンク先がまとめられています。

• 2019年5月の新元号への変更に関する更新（Microsoftサポート）

　日本マイクロソフトは以下の特設サイトで「4月中のご提供ができるよう準備を進めております」と表明していますが、上記のサポート情報（2019年4月18日時点）では「2019年4月1日に新元号の名称が発表されました。弊社のエンジニアリングチームは、段階的に実稼働環境用の更新プログラムをリリースしていきます。完了するまでに数カ月程度かかることがあります」と説明されています。

• 新元号対応へのマイクロソフトの取り組み（日本マイクロソフト）

　企業のIT部門の方は、5月1日の改元に向けて、各サポート情報の内容も日々更新されているので、以前に確認していたとしても、再確認した方がよいかもしれません。個人ユーザーの方は、Windowsやアプリケーションが適切に更新されていれば何もする必要はありません。5月1日以降も平成31年と表示されたとしても、何も不都合はないでしょう。

　個人的な目的で、取り急ぎ「令和元年」というドキュメントを作る必要があるなら、そう書けばいいだけです。Excelシートはどうするの？　と思うかもしれませんが、セルに日付データ（1900年1月1日を「1」としたシリアル値）として入っているのなら何も問題はないはずです。平成31年5月1日以降の日付表示が気になるのなら、セルの書式設定を西暦（グレゴリオ暦）にすればいいだけのことです。

　Windowsの新元号対応に関する詳しい情報は、以下のサポート情報になります。

• 日本の元号の変更について - KB4469068（Microsoftサポート）

　実は、Windowsは以前から和暦の元号を前述のレジストリキーの値で管理していたわけではありません。前述のレジストリキーの値で管理するようになったのはWindows 7（およびWindows Server 2008）からであり、それ以前、例えばWindows Vistaにはこのレジストリキーは存在せず、Windowsのバイナリ（おそらく.nlsファイルのいずれか）の中にハードコードされていました（画面1、画面2）。

画面1　Windowsが和暦の元号をレジストリで管理するようになったのはWindows 7から。全く更新されていないWindows 7にもレジストリが存在することを示すため、インストールメディアのWindows PE環境で確認した

画面2　Windows Vistaには「Nls」キーの下に「Calendars\Japanese\Eras」は存在しない。画面の環境は、サポート終了までの重要な更新プログラムは全てインストール済み

　別の言い方をすると、このレジストリキーを最初から持つWindows 7以降なら、手動で新元号の文字列値を追加すれば、Windows Updateに頼らずとも新元号に“ある程度”対応できることになります。

　しかし、後述しますが、話はそう簡単ではありません。また、Windows Vista以前の古いバージョンのWindowsはレジストリを使用しない仕様なので、手動で対応することはできませんし、製品サポートが終了しているためMicrosoftが対応してくれることもありません。新元号に対応することはできず、永久に平成の時を刻むのです。

旧元号使用の緩和と元年表示初対応の負の側面

　話はそう簡単ではないといった理由の一つに、新元号対応と並行して進められてきた「.NET Frameworkの仕様変更」があります。「Windows API（Application Programming Interface）の仕様変更」といってもよいでしょう。詳しくは以下のサポート情報で説明されていますが、今回の記事タイトル「令和7981年12月31日」はこの仕様変更に関係しています。

• .NET Framework用の日本の新元号対応更新プログラムの概要（Microsoftサポート）

　Windowsが日付として扱える最後の日付は、「西暦9999年12月31日」です。その日付を和暦で表現すると「令和7981年12月31日」（R7981/12/31）となるわけです。日付の書式設定が「西暦」になっているWindowsで、Windows PowerShellの「Get-Date("R7981/12/31")」や「Get-Date("令和7981年12月31日")」コマンドレットを実行すると、西暦9999年12月31日が返ってきます。「Get-Date("R7982/XX/XX")」はWindowsが扱える日付を超えてしまうため、例外をスロー（throw）します（画面3）。

画面3　「Get-Date("R7981/12/31")」コマンドレットが西暦9999年12月31日を返すのは、つい最近になってからの.NET Frameworkの新仕様。これは、テストのために「令和」のレジストリ設定を手動で追加した環境。レジストリが存在しない環境では、「Get-Date("S8074/12/31")」で試してみよう

　現在そして将来の日付は西暦9999年12月31日まで、明治（M8132）、大正（T8088）、昭和（S8074）、平成（H8011）を使用したとしても、正しい日付として扱われます。しかし、この挙動は新元号への対応と並行して進められてきた.NET Frameworkの仕様変更の一つなのです。

　つい最近まで.NET Frameworkは、元号の最終年のみで新旧両方の元号を使うことができ（例えば、平成1年1月1日や昭和64年12月31日）、最終年を超える旧元号の日付（例えば、昭和65年1月1日）を例外として処理する仕様でした（画面4）。

画面4　.NET Frameworkの以前の仕様では、各元号の最終年を超えた日付は例外エラーとなる（画面は2017年5月にサポートが終了し、以後、更新されていないWindows 10初期リリース）

　しかし、昭和65年は法令上無効なものではない（これを無効とする法的根拠はない）ため、本来なら例外として扱うべきではありませんでした。.NET Frameworkの最初のバージョン（1.0）が登場した2002年は平成14年で、当時昭和77年なんて使う人はまずいなかったでしょうから、旧元号（昭和）の扱いが考慮されることも、問題になることはなかったのでしょう。

　アプリケーション開発者は例外エラーになることを知れば、それに合わせてコーディングするでしょうから、この仕様で大きな影響が出ることはなかったのだと思います。旧元号の使用が緩和（事実上無制限）されたことは、逆に例外エラーを期待して開発されたアプリケーションに想定外の影響を与えるかもしれません。アプリケーション側で旧仕様（各元号の最終年を超えた使用は例外エラー）に切り替える方法も用意されていますが、それにはアプリケーションの変更（改修）が必要です。

　なお、.NET Frameworkのこの新仕様は、平成の使用に限っていえば、新元号に対応する方法がないWindows Vista以前と同様の挙動になります。

　ちなみに、Windowsが扱える最初の日付はどうかというと、状況によりけりです。例えば、Get-Date関数は西暦1年1月1日から扱えますが、Windows 10標準の「カレンダー」は1919年1月1日（明治33年1月1日）〜2119年12月31日の201年間を扱えます。その他、以下に示すようにアプリケーションによっても日付として扱える範囲は異なります。

• Accessの日付／時刻型：100年1月1日〜9999年12月31日
• Excelの日付書式：1900年1月1日〜9999年12月31日
• SQL Server（Transact-SQL）のdatetime型：1753年1月1日〜9999年12月31日

　もう一つの大きな変更点は、「元年」の表示と解釈のサポートです。Windows 10 バージョン1809以前のカレンダーの書式設定は「1年」と表示するのが既定になっていますが（レジストリで既定を変更可能、バージョン1903からは「元年」が既定になる予定）、.NET FrameworkではWindowsのバージョンにかかわらず「元年」が既定になります（画面5）。

画面5　.NET Frameworkは既定で「元年」の表示と解釈をサポート。これも最近変更された仕様で、つい最近までは「1年」のみ扱えた。なお、カレンダーが「西暦」の場合は、「元年」を解釈しない場合があるようだ

　つい最近までは、Windowsも.NET Frameworkも「1年」としか表示できませんでした。「元年」表記は、Windowsや.NET Frameworkがこれまで経験したことのない日付データなので、データ交換の際に想定外の影響があるかもしれません。こちらもアプリケーション側で旧仕様（常に「1年」）を使用する方法も用意されていますが、それにはアプリケーションの変更（改修）が必要です。