「令和」への改元が目前、経済産業省と日本マイクロソフトがシステム改修への注意を喚起：「改元」対応に落とし穴あり

経済産業省と日本マイクロソフトは、改元に伴う情報システム改修などへの対応に注意を促している。特にシステム間で日付データを文字列で交換している場合は注意が必要だ。

[＠IT]

　経済産業省と日本マイクロソフトは、2019年5月1日に新元号の「令和」が施行されるため、改元に伴う情報システム改修などへの対応に注意を促している。例えば、西暦と和暦のフォーマット変換や、和暦を使用しているときの日付によるソート、文字列検索の際の正規化ルールなどだ。

令和対応のまとめ（出典：日本マイクロソフト）

　その中でも、トラブルを起こしそうな例として、元号の合字の扱いと、システム間でのデータ交換について取り上げる。

　明治から平成までの4つの元号については、それぞれ1文字分（シフトJISやEUC、JISコードで2バイト）の文字で表示できる合字が用意されている。これに対して令和の合字は、Unicode（ISO-10646）でのみ対応し、シフトJIS（Windowsではコードページ932）などでは対応しない。

Unicodeを使っていても正しく表示されない場合あり

　また、システムが利用しているエンコーディング（文字コード体系）がUnicodeであっても、使用するフォントに令和の合字に相当するグリフが用意されていなければ、画面には正しく表示されない。日本マイクロソフトでは、フォントの更新によって令和に対応するとしている。例えば、Windows 10 October 2018 Update（バージョン1809）が備えているMSゴシック（MSGothic.ttc）はバージョン5.11だが、バージョン6.00を使えば令和の合字を表示できる。

　こうした変更は、Windowsや.NET Framework、OfficeといったMicrosoft製品であれば、Microsoftが毎月提供する更新プログラムを適用することで対応できる。ただし、例えば更新を適用したPCで令和の合字を使った文書を作成し、それを未適用のPCで開いた場合は正しく表示されないので注意が必要だ。

Windowsだけの更新では対応できない（出典：日本マイクロソフト）

システム間のデータ交換に落とし穴

　一方、対応に苦慮しそうなのがシステム間のデータ交換についてだ。REST（REpresentational State Transfer） APIなどを使って、クラウド上で稼働しているソフトウェア同士を連携させるような処理がこれに当たる。

　日本マイクロソフトによると、こうしたシステム間で日付データを交換する際、和暦を文字列でやりとりしている例があるという。また、平成初期に作られたシステムの中には、日付の年号が2けたの場合は平成の和暦、4けたの場合は西暦と見なすような実装もあるという。こうした場合は、データの送信側と受信側の両方で、データ交換方法について調査、検討し、改修する必要がある。

　その他、運転免許証や自動車検査証（車検証）の有効期限にあるような「平成31年10月1日」という表現を許容するか否か、「元年」という表現の扱い、元号を合字で表示する際のエンコーディングの変更など、システムの影響する範囲を慎重に調査し、変更する必要がある。

　こうした改元に伴うシステム改修に関する情報は、経済産業省のWebサイトにまとめられている。