1. 経済産業省掲示
-
改元に伴う企業等の情報システム改修等への対応
- 新元号「令和」が公表されたことを踏まえたシステム改修等における留意点について
- 2019年4月2日掲載
- 2019年4月5日掲載
- 情報サービス産業・ソフトウェア産業の皆様への呼びかけ
- 説明会の開催
-
2019年4月5日説明会資料(2019年4月12日掲載)
-
2019年2月7日説明会資料(2019年2月22日掲載)
-
- よくご質問頂く事項(FAQ)について
- 新元号「令和」が公表されたことを踏まえたシステム改修等における留意点について
2. 改元直前、直後に発生した問題
-
[仕様] 新元号での合字(U+32FF)はユニコードにのみ存在し、Shift-JISでの対応予定はない
新元号(平成の次の元号)対応におけるMicrosoftのセミナー「新元号とマイクロソフト製品における対応」を受けてきました
-
[修正済] 2019年2月のWindows Updateで、一時的にレジストリ内の元号一文字表記が㍻などの合字に変更されたことがあった
マイクロソフトさん、お願いですから.NET Frameworkの動作を何の説明もなく変更するのはやめてください。- 改元対応で思うこと | Qiita
-
[仕様] 2019年4月のOS更新で仕様変更。Win32(影響を受けDelphiも)のAPIでシステム日時が5月となるまでは令和表記とならない
-
[仕様] 元年表記が書式指定にかかわらず適用されるように変更された
[.NET][改元] 「元年」表記に変わる日付書式が今になって拡大!(フレームワーク別の対策が必要)――マイクロソフト様、重大な変更をしれっとリリースしないで
-
[修正済] 設定次第で画面のレイアウト(Excelなども)が崩れることがある
【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい
-
[仕様] 「令」という字体を表すUnicodeは2つある
3. 言語、環境
3.1. Microsoft
-
新元号への対応について
2019 年 5 月の新元号への変更に関する更新 (.NET、Office、Windows、Windows(英語記事)) -
山市良のえぬなんとかわーるど - Windows Updateに関する情報(不具合情報など)
3.1.1. Microsoft製品で参照するレジストリ
3.1.1.1. 元号定義
Using the Registry to Test the New Japanese Era on Windows
Windows 全体が参照する元号定義設定。
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras
- 手動追加はあくまで検証環境での使用が想定されている。運用環境での手動追加は想定外。
- 検証環境では、更新プログラムの適用後手動で新元号の値を追加して確認
- 運用環境では、Windows OS の更新プログラムが自動的に値を作成するため手動での作業は不要
3.1.1.2. .NETが参照する元号設定
Handling a new era in the Japanese calendar in .NET
.NET 4.5.2以前では以下のレジストリを参照する。.NET 4.6以降・.NET Coreはアプリケーション毎の設定ファイルを参照する。
WOW64(64ビット Windows で x86 ターゲット)の場合は、場所が変わるので注意
HKEY_LOCALMACHINE\SOFTWARE
→
HKEY_LOCAL_MACHINE\Software\Wow6432Node
Key: HKEY_LOCALMACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
Name: Switch.System.Globalization.EnforceJapaneseEraYearRanges
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
Name: Switch.System.Globalization.FormatJapaneseFirstYearAsANumber
Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AppContext
Name: Switch.System.Globalization.EnforceLegacyJapaneseDateParsing
3.1.1.3. 元年表記
VBA.Format・Win32等の元年表記は以下のレジストリを参照する。
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese
Name: InitialEraYear
Value: "1年" or "元年"
既定値(Microsoftの情報から)
バージョン | 値 |
---|---|
2019/5にリリース予定のWindows 19H1 | "元年" |
Windows 10 1809以前、7等 | "1年" |
3.1.2. VB6
-
サポートされるOSでは、VB6ランタイムも新元号対応が行われる(レジストリを参照する)。
-
元号定義はレジストリを参照する。
-
元年表記はレジストリを参照する(最新OSの既定値は元年表記)。
3.1.2.1. 独自実装する場合
前提として、公式対応されたため、現在Format関数を使用しているなら基本的には独自実装しないほうが望ましい。OfficeのVBAも同時対応されることからも、OSの累積更新プログラムは適用する必要がある
期間的な制約などで独自実装する場合は次のように行う。
- 日付から文字列への変換(Format)は、標準モジュールに、Public Format ~ As Stringで宣言することで、オーバーライドできる。
- As Stringで宣言しないと、
Format$
が対象とならない(コンパイルできない)。 - <標準モジュール名>.Format、VBA.Formatとすれば、それぞれの関数を呼び出せる。
- <標準モジュール名>.Format内のロジックでは、渡されたExpressionが日付型でない(Not IsDate)場合はVBA.Formatを呼び出せば処理が簡単となる。
- As Stringで宣言しないと、
- 文字列から日付への変換(CDate, DateValue)は影響範囲が大きいため、オーバーライド以外、または文字列からの変換とならないようなロジックの見直しが妥当と考えられる。
3.1.2.2. GrapeCity(ActiveX)
- 新しい元号(年号)への対応方法について(ActiveX製品) | GrapeCity
-
C:\Windows\gceras.ini
の情報を読み込む
3.1.2.2.1. 対応製品
- InputMan Pro 7.0J ※SP12(Ver.7.0.0.16)以降
- SPREAD 7.0J ※SP2(Ver.7.0.0.59)以降
3.1.3. NET
-
.NET 3.5系、4系ともに、元号定義はレジストリを参照する。
- .NET 3.5系はOSによってはパッチ適用が必要(以前はハードコーティングされていた)。
-
常に元年表記となる。
-
既定値は、リラックス元号範囲チェック(元号範囲移行の平成31年5月などを許容する)有効となる。
Handling a new era in the Japanese calendar in .NET
- .NET 4.6以降なら.configを設定して、アプリ単位で挙動を設定できる。
- .NET 4.5.2以前はレジストリで対応可能だが、「他の.NETアプリにも影響する」ことを考慮する。
-
Microsoft.VisualBasic.Compatibility.VB6.Format
は、VB6と同じ仕様となる(OS更新が必要。元年表記はレジストリを参照し最新OSの既定値は元年表記)
3.1.3.1. 独自実装する場合
3.1.3.2. GrapeCity(.NET)
- 新しい元号(年号)への対応方法について(.NET製品) | GrapeCity
- アプリケーションの構成ファイルに記載する。アプリケーションが10個なら、10個書き換える必要がある。
3.1.3.2.1. 対応製品
- CalendarGrid for Windows Forms 1.0J/2.0J
- El Tabelle for .NET 3.0J
- El Tabelle MultiRow 4.0J
- El Tabelle Sheet 4.0J
- El Tabelle Sheet for Windows Forms 4.1J
- InputMan for .NET 3.0J
- InputMan for .NET Windows Forms 4.0J
- InputMan for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J
- InputMan for .NET Web Forms 2.0J
- InputMan for ASP.NET 3.0J/7.0J/8.0J/10.0J
- InputMan for Windows FormsおよびInputMan for ASP.NETの自由書式入力機能を使用している場合はGrapeCityの記事を参照
- InputMan for WPF 1.0J/2.0J
- InputMan for Silverlight 1.0J
- MultiRow for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J
- MultiRow for ASP.NET 1.0J
- PlusPak for Windows Forms 5.0J/6.0J/7.0J/8.0J/10.0J
- SPREAD for Windows Forms 7.0J/8.0J/10.0J/11.0JのGcDateTime型セル
- 日付時刻型セルの動作については、GrapeCityの記事を参照
- SPREAD for WPF 1.0J/2.0J
- SPREAD for Windows Forms 5.0Jの日付時刻型セル
3.1.3.3. アドバンスソフトウェア
- 弊社製品の新元号対応について
- VB-Reportでは、製品独自機能による帳票出力に新元号を反映させる場合、新元号対応アップデートが必要となる。また、Excelを開いた場合、およびExcelモードを使用するならOS・Office依存となる。
3.1.4. Office
Office 2010以降が対象。
- クイック実行形式には、Windowsインストーラー形式用の更新プログラムには適用できません。
- Officeアプリケーションから更新を取得するか、オフライン環境ではODTを使用します
- MSI形式用の更新プログラムの諸注意
- Office 2010 SP3 / Office 2013 SP1 適用済みの状態が前提となります。
- 複数の更新をご提供しており、順序は問いませんが、すべて適用いただく必要があります
- Windows OSのレジストリ、APIに依存するため、OSの更新プログラムも合わせて適用が必要です。
引用元:マイクロソフト資料の47P
アップデート | 影響を受ける機能 | 関連KB等 |
---|---|---|
Office製品 | Excelのセルの書式設定、Accessの表示書式 | 日本の新元号に関する Office の更新プログラム |
OS |
VBA.Format など |
日本の元号の変更について - KB4469068 |
VBA.Format
の元年表記はOSにより既定値が異なる。
3.2. Red Hat Enterprise Linux
RHELの新元号「令和」対策お済みですか | 赤帽エンジニアブログ
※リンクされている https://access.redhat.com/solutions/2749651 はアカウントが必要です
3.3. Java
別記事に詳細にまとめていただいていますので、ご一読をお勧めします。
Javaバージョン別の改元(新元号)対応まとめ | Qiita
3.4. Delphi
別記事に詳細にまとめていただいていますので、ご一読をお勧めします。
3.5. Oracle
Oracle データベースの日本の新元号「令和」への変更方法について | Oracle Support Japan
3.6. 文字コード
-
Unix系では、文字コードや使う文字によっては、ダメ文字問題に当たることもあるかもしれない。ダメ文字への対応が不明であれば、検証が必要
-
新元号「令和(れいわ)」の令という字体を表すユニコードは2つ(「U+4EE4」、「U+F9A8」)ある。通常は意識する必要はない。
3.7. 明治元年開始日の判定
明治元年の開始日は諸説*1、*2あり、言語により実装が異なる。グレゴリオ暦に変わったことによる空白の期間なども踏まえると、アプリケーションとしては、基本的には明治6年1月1日以降をサポートする方針が望ましい。
開発言語 | 明治元年開始日 |
---|---|
VB6 | 1868/10/23 |
.NET | 1868/9/8 ※明治5年まではグレゴリオ暦が反映されていない |
.NET(レジストリ参照時 2019年2月パッチ時点) | 1868/1/1 |
Java | 明治6年1月1日より前はサポートしてない |
GrapeCity(設定ファイル初期値) | 1868/9/8 |
4. 経済産業省通達
1.情報システム改修等の対応
(1)元号をデータとして保有している場合、元号データの変更や追加または西暦データへの統一化
(2)書面やシステム上に元号や「元年」を印字・表示している場合、印字・表示内容の変更
(3)西暦と和暦との変換処理を行っている場合、変換ロジックの変更または変換テーブルへの登録
(4)他の事業者や関係機関のシステムと情報連携している場合、当事者間での対応策の必要性確認
(5)その他、必要な対応2.事務・運用面の対応
(1)元号の記載が含まれる証書・帳票等の記載の変更
(2)旧元号が記載された状態で利用が想定される契約書等の証書や帳票等の取扱の明確化
(3)運転免許証等の官公署発行の証明書等に旧元号が残る場合でも、有効な証明書等として受け付ける措置
(4)顧客に影響が生じうる事項への対応策等に関する顧客への十分な周知
(5)その他、必要な対応出典:「改元に伴う情報システム改修等への対応について」(経済産業省)
5. 各フェーズ注意
5.1. 調査・改修
- OS・ツール、それぞれについて、元号への対応、適用方法について調査する(調査内容 参考)。特に適用方法が自動で行えるかどうかで、設定工数に増減が生じる。
- 明治元年の開始日が、各OS・ツールで異なる方針となっている場合がある。(多くのシステムには関連がないと想定できるが)
- 元号が印字済みの帳票がある場合は、印刷会社も交えた調整が必要。
- 望ましくはないが、和暦年2桁(yy)、和暦元号数値 & 和暦年2桁(gyy)で年を保存、受け渡ししているシステムも考えられるので、考慮が必要。
- 年までの表記、年月までの表記を行っている場合は、元号判定に使用している情報の確認が必要。(例えば、2019/05に出す帳票で、年表記の場合に、2019/01/01と2019/05/01のどちらを渡しているのか)
- OCR等も含め、データを和暦でやり取りしている場合は、範囲外の元号(平成31年5月など)も許容することを検討したほうが良い。その場合も送信は厳密に行う。
- 送信は厳格に、受信は寛容に
5.2. 運用
- 他システム(機器)とのファイル交換がある場合には、双方がいつ新元号対応の形式を送り始めるのか、というタイミング、スケジュールの調整が重要となる。場合によっては、特定ファイルのみ、平成での出力、ということも想定される。
- .NET の標準機能を使用し、CS型のシステムの場合は、他システムへの影響(他システムが元号対応へどのように想定しているか)について調査・調整が必要。
- 一斉の対応とならない場合は、各種機能の対応スケジュールの確認が必要。
5.3. 検証
- 等幅でないフォントで年号を出力する場合は、新しい年号文字で、表示位置がずれていないか、予定外の改行が行われていないかの確認が必要。紙での運用が想定されるなら、想定される環境で出力しておきたいところ。
- 元号考慮済みのシステムの場合も、元号処理を行っている場所について、最低限一機能は動作確認する。
- 日付の指定、特に期間指定を行っている箇所については、計算ロジックについて一通り検証しておきたい。(参考 テストケース)
- .NET の元号対応 Windows Update の配布後は、通常の Windows Update に対する動作確認に加え、レジストリを事前登録している場合は、影響を受けていないかを一通り検証する(基本的にはレジストリの手動追加は、検証環境のみ、とされている)。2019年1月にOffice2010で発生したように、対応するKBが別の障害を起こすこともあるので、早急、かつ慎重な検証が必要となる。
- 並び順について確認が必要。(表示値で並び替えている場合)
- 内部に和暦でデータを保持している場合は、未来の日付が想定される場合について特に注意が必要。
6. 改修またはテスト必要箇所調査のヒント
6.1. VB6
- 日付型から文字列に変換しているか。(
Format
)- "ggg","gg","g","ee","e"(大文字小文字区別しない)
- 和暦文字列から日付に変換しているか。(
CDate
,DateValue
)- VB6はリラックス元号変換。基本的には西暦文字列が使えないかを検討する。
- 日付の計算で和暦文字列から変換しているか。(
DateAdd
)- VB6では、
Option Strict On
がないため、自動的に日付型へ変換される。
- VB6では、
6.2. NET
- .NETの機能を使用する場合
-
JapaneseCalender
を使用しているか- "ggg","gg"(大文字小文字区別する)
- Frameworkのバージョンは何か。(4.5以前は、設定(リラックス元号変換、和暦表記)がホスト共通となる)
-
VB6.Format
を使用していないか-
Microsoft.Visualbasic.Compatibility.VB6
を参照して、VB6.Format
を使用している場合、VB6.Format
は、VBA(VB6)が対応したタイミングでの対応となる
-
-
- .NETの機能を使用しない場合
-
JapaneseCalender
を使用していないか。
-
6.3. サードパーティ
- コンポーネント固有の機能(例えばActiveReportsなら、フィールドのプロパティ
OutputFormat
)を使用して和暦文字列変換を行っていないか
6.4. Office
- 出力物として使用している場合、元号変換にExcel、Accessの書式を使用しているか。
6.5. 共通
- 規約外の和暦計算(コード、SQL)
-
1988
を使用している(2019 - 1988 = 31) -
2000
を使用している(2019 - 2000 + 12 = 31) -
1925
を使用している(1979 - 1925 = 54) -
19261224
を使用している(昭和開始日の前日) -
19890107
を使用している(平成開始日の前日) -
19261225
を使用している(昭和開始日) -
19890108
を使用している(平成開始日)
-
- 埋め込み
-
平成
を埋め込んでいる -
H
を埋め込んでいる -
4
を埋め込んでいる
-
- 年度判定
- 年度を表示している場合、元号取得に使用している年月は正しいか(4~3の年度なら、4月だが、1月の年度を使用している、など)
- 表示値で並び替えていないか。(仕様または実装不具合に該当)
6.6. DB
- 下記に該当する場合は、入力可能な日付の範囲により、適切なタイミングでのデータ変換の必要性を検討する。
- 和暦文字列(例:
平成31年5月1日
)を保存していないか - 和暦数値(例:
4310501
など)を保存していないか - 和暦年のみを保存していないか
- 和暦文字列(例:
6.6.1. Oracle
-
Japanese Imperial
を使用していないか(参考)
6.7. 帳票
- 元号文字列の埋め込みがないか。("平成","平","H")
- ソース
- 帳票フォーマット
6.8. ファイル
- 和暦年号のみの入力がないか。
- 入出力インタフェースで、和暦文字列、和暦数値が使用されていないか。
- 外部システム連携ならタイミングを検討
6.9. 配布方法
- 元号追加に関わる設定の設定方法
- 設定範囲(ホスト全体、アプリ)
- 適用箇所(サーバー、クライアント)
- 配布方法(必要な権限、オンライン・オフライン)
- 再起動の必要性