新元号（平成の次の元号）対応におけるMicrosoftのセミナー「新元号とマイクロソフト製品における対応」を受けてきました

# 新元号（平成の次の元号）対応におけるMicrosoftのセミナー「新元号とマイクロソフト製品における対応」を受けてきました

日本政府は、天皇陛下の退位と皇太子さまの即位に伴う新元号の施行を2019年に行うことで調整に入ったと報道されています。
新元号への対応は、西暦と和暦間の日付フォーマットの変換、和暦による日付の表示・印刷だけでなく、様々な実装上の対応が必要となります。
また、新元号への対応には文字コードの標準化、そしてこれらに対応するためのオペレーティングシステムの更新など多くの作業が必要となります。
新元号への改元のタイミングは`2019年5月1日`とされており、そのタイミングまでに新元号対応を進めていく必要があります。

そこで、日本マイクロソフトが主催している以下セミナーに参加してきました。

[新元号とマイクロソフト製品における対応](https://www.microsoftevents.com/profile/form/index.cfm?PKformID=0x4009476abcd)

**2018年4月20日（金）　10：30~12：00**

## 更新履歴

- 2018年4月23日 10:08
 - 2018/4/20にマイクロソフトのblogへ新元号対応におけるWindows10のレジストリ更新に関する情報が追記されていたので、そのサイトへのリンクを追加。
- 2018年5月18日
 - トピックスを追加。新元号の公表時期が決定。
- 2018年6月25日
 - [Japan New Era Name Support Blog](https://blogs.technet.microsoft.com/jperablog/) の内容に更新情報がありました！
- 2018年10月26日
    - トピックスに最新情報をまとめました！

## トピックス

### 2018年10月26日 更新

[Japan New Era Name Support Blog](https://blogs.technet.microsoft.com/jperablog/)の内容をしばらく見ていなかったのですが、いくつか更新されていました。

- [.NET Framework の新元号対応予定について](https://blogs.technet.microsoft.com/jperablog/2018/06/25/netframework/)
    - `System.DateTime.Parse`や`CDate`関数で不正な和暦文字列から日付変換する際、`System.FormatException`が発生していたが、エラーが発生しなくなった。（昭和65年1月1日などが正常に日付変換できるようになった。）
    - 従来通りエラーを発生させるためにはレジストリの変更やAppContextへの設定が必要とのこと。
- [新元号プレースホルダーのレジストリを個別に削除、追加する方法について](https://blogs.technet.microsoft.com/jperablog/2018/06/25/delete-reg/)
    -  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]のレジストリを個別に修正するための.regファイルを提供してくれる。（Windows Updateを適用できない環境で個別に対応が必要なPCがあるから？）
- [弊社製品の新元号対応予定について](https://blogs.technet.microsoft.com/jperablog/2018/07/20/microsoft-products-newera-schedule/)
    - Microsoft製品の新元号対応が難航していてスケジュールが遅れるかも。。。
    - [元号／和暦 の変更に伴う影響について (SQL Server, Azure SQL Database, SQL Data Warehouse)](https://blogs.msdn.microsoft.com/jpsql/2018/02/26/%E5%85%83%E5%8F%B7%EF%BC%8F%E5%92%8C%E6%9A%A6-%E3%81%AE%E5%A4%89%E6%9B%B4%E3%81%AB%E4%BC%B4%E3%81%86%E5%BD%B1%E9%9F%BF%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6-sql-server-azure-sql-database-sql-data-war/)という記事があって、SQLServer製品の対応状況・新元号における影響について確認できる。
- [新元号検証ラボと新元号に関するセミナー開催予定のご案内](https://blogs.technet.microsoft.com/jperablog/2018/10/09/testlab/)
    - 新元号対応における注意点やMicrosoftの対応状況などを聞けるセミナーが開催される！
    - 以下のスケジュールとのこと。
        - 日時：11月28日13:30(13:00開場) 【予定】
        - 場所：東京ステーションカンファレンス（東京駅）
        - 定員：120名
        - 1. 新元号をとりまく最新状況アップデートとマイクロソフト製品対応方針
        - 2. マイクロソフトにおける検証とそのステータス共有（概要レベル）
        - 3. 新元号対応とシステム更新。相互運用の問題と細心の注意が求められる展開、その手順
        - 4. .NET Framework、Win32などにおける実装上の注意点
        - 5. QA
    - まだ確定ではないため、マイクロソフトの担当営業へ問い合わせすると良い。

### 2018年5月18日　更新

[新元号の公表、改元１カ月前の来年４月想定　政府明かす](https://www.asahi.com/articles/ASL5K5GMBL5KUTFK00L.html)

どうやら、新元号が何になるかは、来年4月（2019年4月）になるようです。
本当に間に合うのか。。。

## マイクロソフト（製品）への対応

### スピーカー

日本マイクロソフト株式会社
業務執行役員　ナショナルテクノロジーオフィサー　田丸　健三郎様

### 新元号への改元での問題

セミナーを通して、新元号対応での問題点は、おおむね以下に収束されていたように思われます。

- 日付フォーマット変換
 - 西暦／和暦の変換処理や変換機能を含んだ製品／コンポーネントへの対応が必要
- 符号位置
 - 新元号に対する`合字`[^1] の文字コード（符号位置）
 - 新元号に対する合字の符号位置は、すでに予約申請をしている。基本的には変わらないはずとのこと。
  - 符号位置：`U+32FF`でほぼ決まり。
- 照合順序
 - 文字コードが追加となるが、`明治`~`平成`まではUnicode上並んでいるものの、新元号はそこに並べることはできないので、照合順序の対応をどのようにしていくのか考慮する必要がある。  
![1.PNG](https://qiita-image-store.s3.amazonaws.com/0/246556/3eeed0cb-5a2f-cf01-fb67-28e1aa5b65d2.png)

 - ISO-14651やCLDRでの対応？というキーワードが出てきていた。
- フォント
 - 文字コード追加に伴う各フォントの対応（MSゴシックなど）
- 正規化
 - `が`と`か`＋`”`の組み合わせを比較したときに、同じ文字データと認識されるように`正規等価`
 - 検索文字列として`平成`と入力した場合でも`平成`と`㍻`のどちらも検索にヒットするように対応する

[^1]: `合字`とは、`平成`に対する`㍻`のように、2文字以上の表現を1文字にまとめた依存文字のこと。  新元号にもこの合字が作られることになるため、この文字コード（符号位置）への対応が求められている。

### マイクロソフトにおける文字コードの歴史

- 1983年
 - 第一世代Shift JIS（JIS78 or JIS83)＋メーカー拡張
- 1993年
 - 第二世代マイクロソフト標準キャラクタセット JIS90,10646
 - **「マイクロソフト標準キャラクタセット」の仕様を凍結**
  - **将来の改変、拡張はしない**
- 1998年
 - 第三世代　補助漢字をUCS拡張　補助漢字をUCS拡張
- 2007年
 - 第四世代　国語審議会答申に基づく最新規格への対応 JIS2004

### シフトJISとCodePage932

- JIS X 0208
- JIS X 0213
- ISO-2022-JP
- Windows-31J
- CodePage932
 - マイクロソフト標準キャラクタセット（合字を含んでいる）Microsoft製品でシフトJISはこの文字コードを表す。
 - 平成などの合字はCodePage932で対応されているが、**新元号では対応されない**。

### シフトJISに対する新元号対応はマイクロソフトとして行わない

1993年に**「マイクロソフト標準キャラクタセット」の仕様を凍結**しており、このスタンスを崩すことはしない。

- シフトJISへのマイクロソフトにより独自対応は行わない
 - 1993年にマイクロソフトは仕様凍結しているため対応しない
 - 新元号の合字を使う場合、`Unicode`を使ってもらう必要がある。
- CodePage932 / 拡張文字を含むシフトJISにおける新元号対応は行わない
- ISO-10646 / Unicode標準の対応に準じた製品やコンポーネントの更新を予定している

### フォントの更新

新元号対応予定のフォント

- MSゴシック
- MS明朝
- MS Pゴシック
- MS P明朝
- Meiryo UI
- Yu Gothic UI
- その他いろいろ

2019年5月1日に全て対応が間に合うか、マイクロソフトとしても確約はできない。

### 入力変換（辞書の更新）

フォントを含む全ての更新作業対応

### 西暦、和暦の変換

以下のメソッド（ファンクション）などが対象
`GetDateFormat`/`GetDateFormatEx`/`Ctime`/`VarFormatFromTokens`

2018年4月のWindows 10 Updateに、以下のレジストリ情報が含まれるように対応され、この内容によって西暦／和暦の変換で考慮が必要な西暦に対する和暦のマッピング情報を保持するとのこと。
※`2019 05 01`のキーが追加されるのだろう。

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

![2.PNG](https://qiita-image-store.s3.amazonaws.com/0/246556/0af20505-36ac-6d0a-5774-c2575060d6a9.png)


#### レジストリ更新のWindows Updateについて

現時点（2018年4月20日時点）では、Windows 10へのこのアップデートのみが決まっており、
他のサーバー製品や、Windows 10以降導入された、`CB` `CBB` `LTSB` などの長期サービスに対して、具体的にWindows Updateへ含めるのか、パッチを配布して個別適用してもらうのかなどの対応方針は、定まっていないとのこと。

**ただし**`CB`や`CBB`で2019年5月1日まででサポートが切れているバージョンを使い続けるようなケースでは、このWindows Updateが適用されることはない。

上記リリースモデルの詳しい内容は、下記サイトなどを参考にして下さい。
https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-overview

### 対応予定製品

2019年5月1日時点でサポート対象（延長サポートを含む）の製品

- Windows 10
 - Windows 7SP1 　~　Windows Server 2016までとか
- Windows Server
- Officeクライアント
- Microsoft 365
- Dynamics CRM
- 他

#### サポート対象の製品の具体的な線引き

線引きが気になっている人も多いと思います。
具体的にセミナーで質問が出ていた内容について、Q&A形式で下表にまとめました。

|＃|質問|マイクロソフトの回答|
|:--|:--|:--|
|1|VB6.0やWindows XPへの新元号対応はアップデートとして提供される？|提供されません。サポートがすでに終了している製品に対しては対象外です。|
|2|Windowsオペレーティングシステム上で利用されるVB6.0ランタイムがありますが、それはOSがサポートしている限り、新元号対応されると考えて良いか？|対象のWindowsOSがVB6.0ランタイムをサポートしており、そのWindowsOSがサポート期間内である場合、厳密には2019年5月1日以降もサポート対象として含まれる場合、VB6.0ランタイムへも新元号対応は実施されます。※あくまでもVB6.0単独で構築されたようなシステムなどは対象外です。|

VB6.0ランタイムのWindowsOSへのサポートについては、下記記事などが参考になるかと。
https://docs.microsoft.com/ja-jp/visualstudio/vb6/vb6-support


## マイクロソフト社でテストをしている担当者からのセミナー

アプリケーションの観点からどのような検証項目があるのか？

### スピーカー

Quality Engineer
休場　晶子様

### 検討すべき検証項目

- 日付関連
 - カレンダー形式の設定
 - 日付の表示
 - カレンダー、スケジューリング機能
- フォント（合字）関連
 - 入力や変換

#### カレンダー形式の設定

カレンダー形式（西暦・和暦・その他）の選択設定がアプリケーションに備わっているのか？

アプリケーション内に設定を持っているものとして
- Share Pointの`サイトの設定`
- Visioの`タイムラインのカレンダー設定`

など

#### 日付の表示

以下パターンがある

- アプリケーションで和暦が選択肢として選べる
 - Excelのセルの書式設定
 - Excelのグラフ、Excelのスライサー、フィルター、条件付き書式などなど
- Windows OSの日付設定が和暦であればアプリケーションも和暦で表示
 - OneNoteのノートブックの日付
 - Outlookのメール受信日
- Windows OSの日付設定を和暦にしていてもアプリケーションの日付表示は西暦表記
 - Outlook on the web,Microsoft Teams, Yammer, Plannerなど

#### カレンダー、スケジューリング機能

- Outlookの予定表
 - 祝日や六曜の表示、うるう年など特殊な日にちに要注意
- Windowsのタスクスケジューラで開始日などの設定項目
 - 元号の切り替わりの表示に注意
※昭和から平成に切り替わったのは、月の途中で切り替わったので仕様が複雑になっている。
今回は、月の途中で元号が変更されることは無いので、月の境目での判断
 - SharePointのイベントリストなどで、元号をまたぐ期間の設定をしている場合、どのように表記するか
 - CRM営業ー＞活動で日付の並べ替えをする際、和暦表示での並び替え機能
 - Outlookの指定日付へ移動するカレンダー選択での和暦表示の機能
 - Visioタイムラインの構成で和暦を選択している場合、

#### 日付の挿入

- Word：日付と時刻の挿入機能
- クイックパーツ＞フィールド＞日付と時刻
- 日付選択コンテンツコントロールを作って挿入
- MS IMEの機能で`きょう`を入力して変換すると、変換候補に`和暦`や`西暦`で今日の日付が変換できる機能がある
- MS IMEだと`２０１８ねん`と入力して変換すると、変換候補に`平成30年`と出てくる。

#### 合字：入力・表示

- MS IMEの合字への変換対応
- フォント：新元号の合字のグリフ
- IMEパッド：合字の表示対応

#### 合字：検索・並べ替え（ソート）

- Bing：合字を使った検索で両方が検索されるか？
- Word：合字を使った検索で両方が検索されるか？

この辺は正規化の状況によって動作に影響が出る。

## アプリケーションごとの主なチェック項目

開発者が気にしなければいけない、アプリケーションごとの新元号対応における考慮点が、セミナー配布資料に含まれていましたので、
それを下表に記載します。

|＃|エリア|項目|
|:--|:--|:--|
|1|日付|日付の表記を和暦に設定できる、もしくはWindows Sの日付設定を参照しており、和暦であればアプリケーション上も和暦表記になる|
|2|日付|和暦を選択できる機能がある|
|3|日付|カレンダー、スケジュール機能がある|
|4|日付|祝日、六曜などの表記がある|
|5|日付|日付を挿入できる（当日の日付、カレンダーからの選択など）|
|6|日付|日付で並べ替え、フィルターができる|
|7|日付|レポート、グラフ機能がある|
|8|日付|西暦、和暦変換ができる|
|9|合字|合字の入力、表示の確認|
|10|合字|合字の検索、並べ替え動作の確認（正規化："㍻"と"平成"など）|

## Partner Readiness Program

日本マイクロソフトは、パートナー企業に対して以下のプログラムを準備中とのこと。

- 仮の文字（U+32FF）によるフォント、更新された製品・コンポーネントを使用した検証環境のご提供（を現在検討している。）
- プログラムの実施時期、形態については改めてご案内予定

## 追加／補足情報

### .NET Framework 3.5を利用中のシステムは注意

`.NET Framework 3.5`のモジュールには、前述しているレジストリの値を参照せず、ハードコーディングによって西暦／和暦変換処理を行っているコードが含まれているとのこと。
`[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]`

そのため、`.NET Framework 3.5`を利用して開発されたシステムで、例えば.NET Frameworkをインストーラに含めて配布しているようなシステムがあった場合は、そのインストーラ含めてバージョンアップ対応及び更新作業が必要となります。

### シフトJISにおける新元号対応は行わない

シフトJISに対しての新元号対応は含まれないため、新元号に対応したシステムでは`Unicode`の利用が必要になるとのこと。

### モジュール／ステータス（マイクロソフトの対応状況）

- レジストリ
 - 新元号発表後の早期に更新予定
- フォント
 - 新元号発表後に作業開始となるため、更新までに一定の時間を要する。
- .NET Frameworkなどのライブラリ、API
 - すでに符号位置が仮指定されているため、可能な限り早期に更新できるよう努めています。

※Windows Updateで配布されるものは、必ずUpdateしてもらう必要がある。

### その他Q&A事項まとめ

|＃|質問|マイクロソフトの回答|
|:--|:--|:--|
|1|2019年5月1日以降の日付データがすでに永続化されている場合、そのデータはUpdate適用後でも正常に動作するように考慮されているか？|・日付データが`DateTime型`等になっているものについては問題ない<br>・文字列型として文字列変換された状態の日付データについては、現在仕様検討中。（エラーとするのが良いか、正常に変換できるようにしてしまうのが良いか）<br>※この件については、2018年夏ごろには確定したいと考えているとのこと。|
|2|`.NET Framework3.5`は現状ハードコーディングされているが、今回の新元号対応によって、レジストリ情報を参照する処理に置き換わるのか？|現状はまだ決まっていない。.NET 3.5は古いバージョンでもあり、サポート切れも考慮すると暫定対応としてハードコーディングでの改修となる可能性も否定できない。|
|3|`.NET Core`についても対応されるのか？|サポート期間対象の`.NET Core`であれば、新元号対応は対象範囲です。|
|4|Updateは全製品／全バージョンが一度にまとめての予定か？|対応が完了した製品やコンポーネントごとに随時配信になります。また、優先順位としては、確定ではないが、最新バージョンのものから順に対応されるのではないか。|

## 自分自身に関りがありそうな内容をメモ

- 新しい元号も含めて、和暦文字列を`合字`で出力するか？
- `合字`で出力するのであれば、システムが使用している文字コードをシフトJISからUnicodeに変更するのか？
 - 例えば、CSVファイルなどへ出力して、あとでExcelで取り込んでデータを確認する程度の運用であれば、データベースの文字コードを変更したりする必要はないか？
 - Oracleなどでは、データベースの文字コードを`JA16SJISTILDE`と設定しているシステムは多いから、こういったDBに元号の合字が直接永続化されるようなケースは対応が必要か？
 - 帳票サーバーを経由して、`合字`をレポート出力しているような機能では、何か対応する必要が出てこないか？
- システムの設定として`西暦`と`和暦`の表示形式を変更する機能がある場合、そのシステムでの対応が必要になる。
- 和暦を利用して、例えばタスクスケジュールやカレンダーの予定を`期間`で指定するような機能がある場合、その機能に対する新元号対応を検討しておく必要がある。

## 参考情報

以下は、日本マイクロソフトのブログ情報など、参考サイトです。

Japan New Era Name Support Blog
日本マイクロソフトの新元号 (和暦) 対応に関するサポート情報のブログ
https://blogs.technet.microsoft.com/jperablog/

The Japanese Calendar's Y2K Moment
開発チームによる和暦に関するブログです。
https://blogs.msdn.microsoft.com/shawnste/2018/04/12/the-japanese-calendars-y2k-moment/

Windows 10 機能更新プログラム (2018 Spring Release) における元号のレジストリ更新について
https://blogs.technet.microsoft.com/jperablog/2018/04/20/rs4-registry/