新元号へ変更、改元、元号改正に伴うITシステムの改修対応

2019年に改元が行われ、新しい元号に変わります。

過去、1989年に平成へと改元が行われた時や、2000年問題と同様に元号改正、新元号への変更に伴い、ITシステムの改修が必要です。

新元号への変更に伴うITシステムの改修について調べてみました。

スポンサーリンク
スポンサーリンク

新元号の発表は?改元、元号改正の発表時期、いつから?遅い?

政府は平成29年 (2017年) 12月8日の閣議で、今上天皇の退位日を平成31年 (2019年) 4月30日にすることを閣議決定しました。

これに伴い、元号改正、元号の変更が行われます。

5月1日に皇太子殿下が新天皇に即位し、新元号が施行されます。

平成という元号は平成31年 (2019年) 4月30日をもって幕を閉じ、2019年5月1日から新元号になるということになります。

2019年のカレンダー

政府は平成に代わる新元号の公表時期について、天皇陛下の即位30年を祝う平成31年2月24日の記念式典後とする方向で調整に入っています。

式典より前に公表すれば、国民の関心が新天皇に移り、式典の祝賀ムードに水を差しかねないとの判断です。

新元号は、皇太子殿下が新天皇に即位される2019年5月1日の少なくとも1か月前に発表される予定です。

つまり、平成31年2月25日から平成31年3月31日までに新元号が発表になる訳ですが、ITのシステム改修の観点からは遅すぎるという声も聞こえます。

元号は、特定の年代に付けられる称号のことで「年号 (ねんごう) 」と呼ばれることもあります。

新元号の予想

では、新元号は何になるんでしょうか?

明治・大正・昭和・平成がアルファベットでM・T・S・Hと略されて使われる場面があります。

そのため、新元号はこれらのアルファベットではないものになる、といわれています。

しかし、政府は新元号の予想や候補については一切発表をしていません。



新元号のシステムに対する影響サンプル (C#で日付を和暦で取得)

新元号のシステムに対する影響を調べるために、簡単なサンプルを見てみましょう。

C#で日付の年号を和暦、元号で取得するプログラムのサンプルを見てみます。

和暦を扱うには、JapaneseCalendarクラスとCultureInfoクラス(ともにSystem.Globalization名前空間)を利用します。

書式指定文字列「gg」を使うと、元号名が表示されます。

出力結果は以下の通りです。

現在のように元号が不明だと上記のように

「平成31年5月1日」と表示されます。

また、元号データのレジストリ格納先:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Nls\Calendars\Japanese\Eras]

を編集することにより、新元号のテストを行うことが可能となります。

改元について既存のコードを調査したということで、こんな記事を見つけました。

元号が変わるので既存システムの影響調査だ。と乗り出したら、
if(x==true){
return "平成";
} else {
return "昭和";
}

#本当にあったIT怖い話

実際の所、こんなコードは山ほどあると思います。

改元に伴うシステム改修、元号変更、新元号対応、なぜ大変?

経済産業省から、各団体へ「改元に伴う情報システム改修等への対応について」依頼が行われたようです。

以下はその文章の一例です。

事 務 連 絡
平成 30 年 6 月 20 日
経 済 産 業 省

〇〇 御中

改元に伴う情報システム改修等への対応について
日頃より政府の経済施策等にご理解、ご協力を賜り、厚く御礼申し上げます。
天皇の退位等に関する皇室典範特例法(平成 29 年法律第 63 号、以下「皇室典範特例法」という。)に基づく皇位の継承に伴って、2019 年5月1日に改元が行われることが検討されております。
新元号への円滑な移行に向けた関係省庁連絡会議(平成 30 年 5月 17 日開催)において、各情報システムの取組状況を踏まえ、情報システム改修等を円滑に進めるための作業上の便宜として、新元号の公表時期を改元の1ヶ月前と想定し、準備を進めることとすることを決定いたしました。

(注)新元号の公表時期は、現時点で未定です。

つきましては、各法人等におかれましても、これを踏まえた対応をご検討いただき、新元号への円滑な移行に向けてご協力いただきますよう、よろしくお願い申し上げます。
<参考:改元に係る対応の例>

1.情報システム改修等の対応
(1) 元号をデータとして保有している場合、元号データの変更や追加または西暦データへの統一化
(2) 書面やシステム上に元号や「元年」を印字・表示している場合、印字・表示内容の変更
(3) 西暦と和暦との変換処理を行っている場合、変換ロジックの変更または変換テーブルへの登録
(4) 他の事業者や関係機関のシステムと情報連携している場合、当事者間での対応策の必要性確認
(5) その他、必要な対応

2.事務・運用面の対応
(1) 元号の記載が含まれる証書・帳票等の記載の変更
(2) 旧元号が記載された状態で利用が想定される契約書等の証書や帳票等の取扱の明確化
(3) 運転免許証等の官公署発行の証明書等に旧元号が残る場合でも、有効な証明書等として受け付ける措置
(4) 顧客に影響が生じうる事項への対応策等に関する顧客への十分な周知
(5) その他、必要な対応

※ なお、新元号公表から短期間で改元を迎えるため、全量対応は現実的に間に合わないことも想定される。そのため、優先順位を付けた対応が必要になることに留意。また、その場合でも、旧元号と新元号が混在することを想定した運用が必要になることも留意。
(以上)

上記の文章の表現を借りると、ITにおける改元対応は以下の5点になります。

  1. 元号をデータとして保有している場合、元号データの変更や追加または西暦データへの統一化
  2. 書面やシステム上に元号や「元年」を印字・表示している場合、印字・表示内容の変更
  3. 西暦と和暦との変換処理を行っている場合、変換ロジックの変更または変換テーブルへの登録
  4. 他の事業者や関係機関のシステムと情報連携している場合、当事者間での対応策の必要性確認
  5. その他、必要な対応

システムを保守しているSEが、これらの課題をしっかりと調査した上で、変更が必要な場合は、正しく変更を行う必要があります。

新元号対応の難易度、かかる費用

元号対応の難易度、費用はシステムの規模により様々です。

日経コンピュータによるとNTTデータや日立は新元号の対応が難しくないとコメントしているそうです。

皇室会議で2019年5月1日に元号を改正することが決まったと、2017年12月1日に新聞各紙が報道した。2018年中に新元号が公表されるという。政府は2017年12月8日に正式に閣議決定する見通し。元号の改正に伴うシステム修正が必要となる。

NTTデータは「元号改正による修正は限定的」(同社広報)とみる。システム内部で保持する西暦日付を和暦日付に変更するテーブルの修正が必要とする。

日立製作所は「平成から新元号への対応は比較的容易」(同社広報)と話す。新元号の公表から元号改正までの時期に余裕があるため、変更作業を計画的に実施できるほか、昭和から平成への元号変更の際に培ったノウハウを生かせるためだ。

https://tech.nikkeibp.co.jp/it/atcl/news/17/120102783/

一方で、佐賀県は新元号対応に1億円以上の予算を計上しているそうです。

県情報課によると、本年度の当初予算に、新元号対応のシステム改修費約1億3200万円を計上した。県庁内部の事務システムのほか、教育関係や運転免許証など32のシステムが該当するという。情報課は「いずれも元号表記が使われており、幅広く対応する必要がある」と説明する。

https://www.saga-s.co.jp/articles/-/211701

自治体の改元対応

自治体では、多くのシステムや帳票が元号を使っているために、新元号対応のシステム改修を行う必要があります。

日経新聞によると、システム改修が遅れた場合のために、行政関係の証明書が「平成」でも有効とする注意書きの表示等を決めたそうです。

政府や自治体の情報システムは新元号に合わせて改修する必要がある。証明書などに「昭和」や「平成」などの和暦を記しているためだ。改修が遅れると、西暦と和暦のシステムを接続する際などに障害が起きる可能性がある。例えば税を納めても納税記録が残らなかったり、住民票を発行できなかったりする可能性があるという。

もし改修が遅れて改元後も行政関係の証明書に旧元号の「平成」を使わざるを得ない場合の政府の対応も決めた。(1)証明書を訂正印で訂正(2)「平成」と明記しても有効である文書を同封(3)希望者には新元号を表記した証明書に交換(4)電子申請の申請画面に「平成」でも有効だという注意書きを表示、などを挙げた。

政府関係者によると、金融機関などの対応が間に合わなければ、深刻な場合はATMでお金を引き出せないシステム障害もあり得るという。企業にも来年4月1日の新元号公表を想定して、システム改修を要請する。

https://www.nikkei.com/article/DGXMZO30640720X10C18A5PP8000/

「平成」でも有効とするっていう対応はみっとも無いけど、ATMでお金が下ろせないとことがあると困るわな。

マイクロソフト Office の改元対応、新元号対応

マイクロソフトでは、「Japan New Era Name Support Blog」という日本マイクロソフトの新元号 (和暦) 対応に関するサポート情報のブログを公開しています。

URLは以下の通りです。

https://blogs.technet.microsoft.com/jperablog/

.NET Frameworkの新元号対応予定については以下のように記載がありました。

今回は、.NET Framework の新元号対応に関わる変更について、変更の内容とリリース予定についてご案内します。

変更内容

現在、マイクロソフトでは .NET Framework のクラス ライブラリの新元号対応に関して以下の 2 点の変更を予定しています。

変更 1.

各元号における最終年を超えた和暦表現の文字列 (平成 32 年、昭和 65 年など) を日付型オブジェクトに変換する際の緩和措置

変更 2.

.NET Framework 3.5 においても、和暦計算時に元号情報のレジストリを参照するような変更

それぞれの詳細について、以下にご案内します。

変更 1. について

.NET Framework では、System.DateTime.Parse メソッドや VisualBasic の CDate 関数など、和暦表現の文字列を DateTime などの日付関連のオブジェクトに変換する処理において、”昭和65年1月1日” のような各元号の最終年を超える日付に対しては、System.FormatException やSystem.InvalidCastException といった例外をスローする動作となっていました。

今回、元号のレジストリが追加されたことによって .NET Framework でも平成は 31 年が最終年であると認識するようになりますが、これにより、レジストリが追加される前までは問題なく処理されていた “平成32年1月1日” といった和暦表現の入力も例外を発生させてしまうことが想定されます。

しかしながら、昭和65年や平成32年といった表現は、法令上無効なものではなく、本来は例外をスローすることなく処理されるべきものでした。

これを踏まえ、本変更にて “平成32年1月1日” や ”昭和65年1月1日” といった和暦表現に対しても例外をスローせずに正しく処理するよう修正が加えられました。

なお、上記のような動作を望まないアプリケーションに対しては、更新プログラムの適用後でも、以下のような設定を適用することで、従来の動作と同様に例外をスローさせることが可能となっています。

- .NET Framework 4.6 以降のアプリケーションで変更 1. の動作を無効化する方法

アプリケーション構成ファイル (***.exe.config) の <runtime> 要素に、以下のような <AppContextSwitchOverrides> 要素を記述します。

本設定は .NET Framework 4.6 から提供されている AppContext の機能を使用して本変更をオプトアウトするもので、アプリケーションごとに設定可能です。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<AppContextSwitchOverrides value="Switch.System.Globalization.EnforceJapaneseEraYearRanges=true" />
</runtime>
</configuration>

- .NET Framework 4.5.2 以前のアプリケーションで変更 1. の動作を無効化する方法

以下のレジストリ値を設定します。本設定は対象のシステム上で動作するすべての .NET Framework 4.5.2 以前のアプリケーションに対して本変更を無効化します。

キー : HKEY_LOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
名前 : Switch.System.Globalization.EnforceJapaneseEraYearRanges
種類 : REG_SZ
データ : 1

変更 2. について

.NET Framework では、これまで、西暦に対応する和暦の算出方法がバージョンによって以下のように異なっていました。

.NET Framework 3.5 (2.0/3.0 も含む)

モジュールにハードコードされた情報をもとに算出

.NET Framework 4 以降

レジストリ (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras) に定義された情報をもとに算出

このため、Windows 10 April 2018 Update で追加されたように、上記のレジストリに新しい元号の情報が追加されたとしても、.NET Framework 3.5 アプリケーションではその情報が利用されることはありませんでした。

本変更では、.NET Framework 3.5 についても .NET Framework 4 以降と同様に、上記のレジストリを参照して和暦を算出できるよう修正が加えられています。

これにより、各種書式関数における和暦の処理や、System.Globalization.JapaneseCalendar クラスの GetEra メソッドや Eras プロパティなども、上記レジストリの情報に基づいて処理を行うようになります。

https://blogs.technet.microsoft.com/jperablog/2018/06/25/netframework/

このアップデートのリリース日は2018年7月10日です。

また、マイクロソフトは、将来的に元号の変更をWindows Updateによって追加の時代を追加するそうです。

通常のWindows Updateを通して、レジストリにキーを追加するわけです。

対象となるのはWindows 7、Windows Server 2008 R2、および.NET Framework 4以降の製品です。

時代データは以下のレジストリキーの下に格納されており、レジストリエディタでこの部分に「"2020 09 01"="仮名_仮_Test Era_X"」のキーを書き込むことで、テスト目的などの新元号組み込みにも対応するそうです。

元号データのレジストリ格納先:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Nls\Calendars\Japanese\Eras]

スポンサーリンク
スポンサーリンク
スポンサーリンク

フォローする