ニュース
改元されたあとの“平成31年”表記はどう扱うべき?
～日本マイクロソフトやAdobeが改元対応を説明
2018年12月6日 21:06
文字情報技術促進協議会は都内にて、「新元号対応の最新動向」と題したセミナーを開催した。
日本マイクロソフト株式会社 業務執行役員 NTOの田丸健三郎氏、アドビシステムズ株式会社 Adobe Type日本語タイポグラフィ シニアマネージャの山本太郎氏らが登壇し、各社の新元号対応について講演、自治体担当者を招いたパネルディスカッションも行なわれた。
同セミナーには、自治体やシステムベンダーなどの関係者らが参加。会場はほぼ満席となっていた。
文字情報技術促進協議会 会長の小林龍生氏は、冒頭の挨拶にて、改元まですでに半年を切っているが、発表に際しての不透明要素や、平成元年以来の作業となることから不安や“もやもや感”を各位が持っていることと思うと述べ、そんな気持ちを共有できるだけでも本セミナーは目的を達成できたと言えるだろうと語った。
田丸氏は、「新元号対応で求められる開発、展開と運用における対応」と題して、日本マイクロソフトの改元対応と、改元にともなうシステムベンダー側の注意点などを講演。
昭和から平成へと改元したのは、約30年前のことになるが、当時はWindows 3.0やSQL Server 1.0がPC上で稼働していた時代であり、日本語版のマイクロソフト製品はほぼ存在していなかったと述べ、加えて、当時はデータをシステムやアプリケーション間で交換することは多くなかったため、改元はあまり大きな問題にならなかったという。しかし、現在では多くのアプリやシステム間で、当たり前のようにデータを共有しており、今回の改元では勝手が異なるとした。
同氏が示した、4月30日に新元号が発表されると仮定した作業日程では、OSやアプリケーションの更新作業は、基本的に元号が発表されてから作業が開始できるものとなるため、変更作業のほとんどは元号発表を待つ必要があると説明。
実際に元号が変更されたあとに起こりうる問題として同氏が提示したのは、.NET Frameworkの振る舞いで、.NETを使った開発物には、無効な日付を入力するとエラーが発生することを利用し、ユーザーが入力した日付の有効性を確認する(和暦として正しくないものを無効なデータとして扱う)といった実装が多数見受けられると述べ、後述する改元にともなう仕様の変更により、それらが動作しなくなるという。
「(和暦として正しくない)“昭和70年”を1995年に変換する」というニーズはもはや存在しないのに対して、運転免許証の有効期限表記などの対応に「“平成31年”を2019年に変換する」というニーズは存在するための仕様変更となるが、ファイル読込や通信といったデータの扱いでは前述の処理が求められるのに対し、入力確認のようなユーザーインターフェイスでは、平成31年に対して“正しくない和暦”としてエラー処理を行なうのが望ましくなると指摘。
またExcelを例に挙げ、日付を扱う関数について、アップデートで新元号の処理に対応したExcelと、未対応のExcelとで、共有したデータを正しく扱えるかどうかが異なるといったように、同一組織内でも対応状況が異なる可能性があると指摘した。
同氏は、データ交換や通信においては、「送信は厳格に、受信は寛容に」という送信側は規格に準拠して送信し、受信側は例外にも対応しておくことで運用をスムーズに行なう原則があることを紹介。
Microsoft製品に限らず、Webサービスとクライアントのように、さまざまなユーザーやシステムと連携するサービスは、相互運用性の問題を慎重に評価する必要があると述べ、「ユーザー環境のシステムが新元号に対応していてサービスが未対応」の場合、データが不通となる可能性があり、依存関係にもとづき「サービスが対応済みでユーザーが未対応」という順番で対応が進むことが望ましくなるとした。
だが、現実的にはすべての依存関係を明らかにすることは難しく、循環した依存関係がある場合には、すべてを同時に新元号対応へと更新する必要も生まれるとし、組織におけるシステム更新順序など、新元号を使い始めるタイミングも考慮する必要があるとした。
同氏は、フォント対応についても説明。
元号には1文字で表記を行なう「合字」があり、新元号にあわせて新たな文字を追加しなくてはならないとし、それにさいして日付フォーマットの変換、符号位置、照合順序、正規化、フォント、共通実装などを考慮する必要があるとした。
すでに新元号の合字は、基本多言語面(BMP)以外の面(Plane)への追加が検討されており、Unicodeの符号位置は予約されている段階にある。
「元年」の扱いも問題で、平成元年当時は、ソフト開発各社が各々でJIS漢字を拡張して実装するなど、文字の相互運用も困難な時代であり、前述のように情報交換を目的とする「平成元年」や「平成1年」を含むデータはほぼ存在しないのが実情だったという。
同社では、1993年に「マイクロソフト標準キャラクタセット」として、相互運用を目的とした文字コードを策定しているが、今回の新元号対応では同社独自の対応は行なわず、ベースとなる標準に準拠し、Code Page 932/拡張文字を含むシフトJISでは対応を行なわないと説明。Unicodeについては標準の対応に準じた更新を予定する。
1年と元年については、省庁などが元年で基本的に表記することや、日本語的により正しいだろうという判断で、デフォルトのフォーマットとして1年ではなく元年を採用する。
フォント更新については、同社のシステム標準フォントであるMSゴシックやMeiryo UI、Yu Gothic UIなどで新元号に対応するとした。なお、IME辞書の更新については、フォントを含むすべての更新作業後の対応となる。
同氏は実装/展開上のポイントとして、.NET Frameworkでの振る舞い変更(オプトアウト可能)、日付データの文字列フォーマット(元年問題)などを紹介。
同社の基本方針は、「2019年5月1日時点で延長サポートが終了していない製品」で、「現時点で和暦に対応している」製品について新元号に対応するかたちであるとし、WindowsについてはWindows Updateによる対応を予定しているとした。
Windows Update経由となるため、適用時に累積パッチも当たることとなり、今までアップデートしていない環境などについてはその影響も考慮する必要があるとした。
Adobe製のフォント名は元号対応後も変わらず
山本氏は、Adobeの新元号にともなうフォント対応について説明。
同社最大の文字コレクション最大のグリフ集合となる「Adobe-Japan1-6」に基づき、新元号でも縦組み横組みそれぞれの合字を用意。グリフを追加するため、新たに「Adobe-Japan1-7」文字コレクションとなる。
既存のフォント名では、「小塚明朝 Pr6 R」のように、文字コレクションの数字が明示されているが、今回の更新では小塚明朝 Pr6 Rのまま変更せず、Adobe-Japan1-7を明示しない方法を採用するという。ただし、フォント名についてのみであり、内部のROS情報はAdobe-Japan1-7と記述されることになる。
結果、Adobe-Japan1文字コレクションに基づく日本語OpenTypeフォントは合字を追加して対応し、基づかないフォントの場合はそれぞれ対応するGIDとグリフを追加して対応する予定であるとした。
