文字情報基盤文字情報一覧表の全ての文字名と例示字形を、UCSの日本ソース欄に記載する提案文書が、ISO/IEC JTC1/SC2に提出された。
同時に、というか、ちょっと遅くなってしまったが、情報処理学会情報規格調査会SC2専門委員会（以下、JSC2）と当社団との共宰での公開レビューが始まった。
多くの方に、提案内容を精査していただき、積極的にコメントをお寄せいただくことによって、国際標準の策定作業に直接かかわっていただくこととを願っている。
提案の背景の背景
この水平拡張提案のそもそものきっかけは、IRGで積極的に活動している中国のHenry Chenさんが、MJ文字図形名とUCS符号位置の現在の対応関係について疑義を呈する複数のコメントを寄せてくださったことに始まる。
このコメントの委細は、すでにこのブログに書いたけれど。
UCS水平拡張とパブリックレビュー
ざっと復習すると。
このChenさんからのコメントがきっかけになって、協議会の文字情報基盤委員会では、都合2回の内部レビューを行い、結果的には、40個所ほどの修正が必要と思われる対応関係と、さらに30個所ほどの「う〜ん、迷うなあ、結論はIRGに委ねよう」という対応関係を洗い出した。
その過程で、どうもMJ文字図形名とUCS符号位置との対応関係が、UCSの規格票に記載されていないのは、ちょっと（というか、かなり）まずいのではないか、という考えに傾いてきた。
先般行われた協議会総会の機に毎年開催される特別セミナーのパネルセッションで、協議会の事務局長で日本マイクロソフト社のNTO(National Technology Officer)でもある田丸健三郎さんも強調していたが、現今の情報通信産業では、広い意味での国際標準に準拠しない実装は、コスト面でもWTO/TBT的な意味での非関税障壁という面でも事実上不可能となっている。
一方、文字情報基盤は、現在はデジタル庁が所管しているベーシックレジストリの一つに指定されていて、いわば今後の行政の全面的なデジタル化に向けての公的な側面を持っている。
ところが、先にも記したように、文字情報一覧表に記載されているMJ文字図形の内、過半数の約3万文字については、現在、UCSの側には何の記載もない。MJ文字図形名とUCS符号位置の対応関係は、いわば、文字情報基盤の策定責任者（かつては独立行政法人情報処理推進機構、現在は、当協議会）が勝手に定めているだけなのだ。
ぼくも、文字情報基盤整備事業には、その立ち上げの時から、かなりディープに係わってきたこともあって、その全般的な品質（信頼性）を疑うものではないが、これほどの大規模文字集合になると、誤謬（バグ）の露見は、どうしても避けられない。UCSにしてもCJKパートにはいまだにバグが残っていて、それが、忘れたころに発覚したりしている。
Chenさんのコメントを契機として発覚したバグは、いわば、出るべくして出て来たバグだ、とも言えるわけだ。もちろん、当事者の一人として、忸怩たる思いはあるけれど。
しかし、この問題の本当の問題は、MJ文字図形名とUCS符号位置の対応関係にバグがあった、ということではなく、そのバグの処理方法にある。国際標準、特に、符号化文字集合規格では、一般に、バグが発覚しても、それを変更することは、原則として行わない。なぜなら、バグを含む既存実装にどのような副作用を及ぼすか予想がつかないから。だから、バグはバグとして残したままで、何らかの対応方法を検討する、というのが一般的な原則となっている。
しかし、今般のMJとUCSとの間のバグは、それを修正してもUCS本体には何のインパクトも与えない。その上、幸か不幸か、発覚したバグのほとんどは、日本の現代社会における人名や地名にはまず使用されることがないと思われる中国の古典籍に典拠をもつものだということも分かっている。そんなわけで、今回発覚したバグについては、文字情報一覧表そのものを修正しても、副作用はまずないと思われる。
とは言え、先に書いた田丸さんの言ではないけれど、いまや日本のデジタル行政の根幹の一つとなった文字情報基盤が、国際規格との関係を恣意的に変更することが許されるような現状は、（広い意味での）システムの安定性という点で、決して望ましいことではない。
この際だから、UCS本体にMJ文字図形名とMJ明朝体のグリフを記載してしまい、MJ文字図形一覧表全体を、UCSの側から規定できるようにしてしまおう、というのが今回の水平拡張提案の狙いなのだ。
いそいで付け加えておくが、MJ明朝体の現在の実装（誤謬と思われるUCS符号位置での実装）は、まさに後方互換性のために残しておくことになると思う。
公開レビューの背景の背景
提案は提案として、今回、JSC2と共宰で、提案内容そのものについて、公開レビューを行うことが出来たのは、ぼく的には、ものすごく嬉しいことなのだ。
小著「ユニコード戦記」（東京電機大学出版局刊）の前書きにも書いたことだけれど、標準規格は、天から降ってくる所与のものではなくって、規格策定に係わる生身の人間が、その激しく対立する利害関係も含めて、議論に議論を重ねて作り上げていくものなわけだ。もちろん、UCSだってその例に漏れない。現在では、UCSとほとんど同じと言っていい、ユニコードにしても、UCTが主体となって策定している部分（CJKパート以外のほとんどすべて）についてはもちろん、IRGでの議論を踏まえて策定されるCJKパートについても、UCSとしての国際投票の前に、部分的な提案も含め、ユニコードとして、公開レビューの機会を設けている。ユニコードが登録窓口となっていて、UCSとしては、その結果を追認するだけとなっているIVDについても、登録を受け付けてから、一定期間の公開レビューを経た上で、正式に登録公開する手順を踏んでいる。このあたり、公平性、公開性、といった点で、なかなかやるよなあ。
一方、ISO/IEC JTC1傘下のSCの中には、極端に言うと、国際規格を私物化して、まさに恣意的に規格の策定、変更を行っている例もないとは言えない。
もちろん、当協議会副会長の村田真の言ではないけれど、衆議一決、根回し万全みたいな日本的合意形成を待っていたら、国際標準化活動のスピードについて行けるわけがない、というのも事実。まあ、このあたりは、村田真の名/迷論文「だからわたしは嫌われる」（仮称）を読んでいただくこととして。
[https://www.jstage.jst.go.jp/article/johokanri/55/1/55_1_13/_article/-char/ja/]
多分、理想的なのは、その規格の本質的な部分についての専門家（コンテンツエキスパート）と規格策定の手続きを含めた専門家（プロシージャエキスパート）が少人数で協力してドラフトを開発し、それに対するコメントを広く受け入れる、といったやり方なのだろう。
今回の水平拡張提案のきっかけはChenさんという中国の専門家からのものだった。このこと自体、ものすごく、嬉しく、かつ、意義深いことではあるのだけれど、日本の人たちにも、文字情報基盤やUCSについて、もっと自分事として関心を持ってもらいたいなあ、という思いも、またホンネ。
ちょっと、というか、かなり大きなファイルではあるけれど、ダウンロードしていただいた上で、へえ、こんなことやっているのだ、こんな字もUCSには入っているのだ、といった関心だけでも持っていただければ幸い。そして、このデカいファイルの背後には、日々、文字と格闘しているエンジニアや研究者がいることに、チラリとでも思いを馳せていただければ、もっと幸い。