一般社団法人 文字情報技術促進協議会
会長
小林 龍生
UCS水平拡張提案公開レビュー
文字情報基盤文字情報一覧表の全ての文字名と例示字形を、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には入っているのだ、といった関心だけでも持っていただければ幸い。そして、このデカいファイルの背後には、日々、文字と格闘しているエンジニアや研究者がいることに、チラリとでも思いを馳せていただければ、もっと幸い。
木田泰夫さんがJSC29へのリエイゾンに決定
情報処理学会情報規格調査会SC29専門委員会（以下、JSC29）に対する本協議会からのリエイゾンとして、木田泰夫さんが参加してくれることが、正式に決定した。
JSC29は、主としてJpegやMpegなどの静止画や動画に係わる国際規格を担当しているが、なぜか、Open Font Format(ISO/IEC 14496-22)というフォントに係わる規格も担当している。しかし、仄聞するところだとJCS29にはフォント技術のエキスパートはおいでにならない、とのこと。そりゃそうだ。動画関係の技術とフォント技術では、だいぶ事情が異なるからね。
一方、ほとんどのベンダーが、当協議会のメンバーになっているフォント業界は、従来からOpenTypeの規格内容を実質的に仕切っているMicrosoft社やAdobe社から提供される技術情報を直接用いてフォント開発を行っており、国際標準化活動という意味での関与は行ってこなかった。
しかし、えらそうなことを言うようだが、国際規格というのは、天から降りてくる神の声のようなものではなく、その技術に係わる当事者たちが、グローバルな公共性、公平性を維持しながらも、それぞれの利害をぶつけ合って作り上げていくものなのだ。とまあ、こういう偉そうなことも、ぼく自身がSC2（UCS、ISO/IEC 10646）やUTC（Unicode Technical Comittee）の活動を通して学んできたことなのだけれど。
というわけで、協議会の会長としては、フォントベンダー各社にも特に若いエキスパートに、与えられた規格を唯々諾々としてうけいれるだけではなく、規格の問題点を積極的に指摘し、出来れば、特に日本語の表記に係わる新たな提案をしてもらいたいなあ、と日ごろから思っていた次第。
そんな折、例の村田真が、アクセシビリティの方から、Open Font Formatにも興味を持ち始めて、現在のJSC29の状況にも気付いた、というわけ。
公的国際規格策定の場でも、日本のフォントベンダーの意見を反映できるパスを通せないか、とJSC29の関係者ともいろいろ相談した結果が、木田泰夫さんにリエイゾンとしてJSC29に参加してもらう、という妙手だった。
フォントベンダー各社が、独自に情報規格調査会の会員になって意見を言えばいいではないか、という考え方もあるにはあるが。ここには、日本の公的技術標準への関与のしかたそのものの大きな問題がよこたわっている。
情報規格調査会は、経産省からの補助金も得ているが、基本的には、会員各社が負担する会費でまかなわれている。これが、結構高額なので。従来は、それこそ、日立製作所や富士通、日本電気、MicrosoftやIBMといった大企業が金も出す、人も出す、という形で係わってきたが、フォントベンダーはごく一部を除いて、ほとんどが小規模で、とてもではないが、金の面でも人の面でも、日立や富士通の向こうを張るような芸当は出来ない。もちろん、CITPCにも、独自の予算で情報規格調査会の会員になるなどとは、夢のまた夢。
一方、SC2についても言えることだが、文字符号やフォントは、単なる《技術標準》では解決できない文化的、社会的要件が深く関わってくる。価値中立的な技術的議論だけでは、いかんともしがたいのだ。
木田さんのJSC29へのリエイゾン参加というのは、このような閉塞的な状況を打破する可能性のある、妙手というか、ちょっとしたクリーンヒットなのではないか、と自賛する次第。
言い忘れていたけれど、リエイゾンというのは、元々は軍隊用語で、連絡将校のこと。標準化活動の世界では、利害が関係する団体やグループ間調整役のような位置づけになる。オブザーバーとは、わけが違うのだ。
木田泰夫さんのこと
ぼくが書きたかったのは、こんなややこしい国際標準化の現場の話ではなくって、木田さんご自身のこと。というか、木田さんとは、村田真ともども、もう長いお付き合いだしね。
木田泰夫さんの知遇を得たのは、ずいぶん以前のことだ。といっても、あまり以前のことで、記憶も定かではない。
「ユニコード戦記」にも木田さんは登場していて、UTCに対して、Variation Selectorの提案をしたころ、ルビタグも問題になっていて、ルビタグが理解できない処理系がルビタグを読み飛ばしてしまって、結果的に平文になった場合、意味が真逆になる絶妙な例をひねり出してくれたのが木田さんだった。樋浦秀樹さんも含め、三人でほぼ徹夜で二つの寄書を書き上げたことを、昨日のように覚えている。「ユニコード戦記」の記述では、1998年2月のこと。
同じ1998年には、東京でInternational Unicode Conferenceが開催されていて、このカンファレンスの後、樋浦さん、村田さん、檜山正幸さんと、確か「Unicodeは怖くない」といったタイトルで月刊ASCII誌上で放談会みたいなものをした記憶がある。
この月刊ASCII誌上での放談会は、檜山さんが、当時ASCIIの編集部にいた西村賢さんを引きずり込んで企画してくれたもので、何度か行われた。この一連の集まりに、木田さんも参加したことがあったように記憶している。そのころって、まだ木田さんはクパチーノの本社ではなく、日本のオフィスを拠点にしていたように記憶している。
いずれにしても、このころ木田さんの知遇を得たことは間違いない。
その後、木田さんは拠点をクパチーノのアップル本社に移して、仮名漢字変換機能の実装や日本語フォントの調達だけではなく、Macを初めとするアップルの諸製品の日本語関連を含む国際化の中核を担っていくことになる。
UTCやSC2のために西海岸に出張した折に、樋浦さんと共にミーティングに参加したり、一緒に食事したり。ベイエリアにはいろいろな日本食屋があり、徳島ラーメンの店もある。だけど、ぼく的には、そのころはジャストシステムの社員だったし、ジャストシステムの本社は徳島だし、いくら木田さんが旨い旨いと言っても、ちょっとなあ、という気分で、樋浦さんともども、お二人に本場の徳島ラーメンをご馳走するために、ジャストシステムの招待したこともあった。
あと、忘れられない思い出は、2010年の10月に台北で開かれたEPUB関連の会議の折、村田さんも含めて、3人で鼎泰豊で、この年の4月に急逝した樋浦さんの思い出を語り合ったこと。
このころの木田さんは、EPUBの日本語機能の前提となった「W3C技術ノート日本語組版処理の要件」とオープンソースとして開発されていたWebKitの実装とすりあわせの場面で、大活躍をしてくれていた。
国際標準を含め、一連の要件を策定するとき、策定する側があまり実装局面での制約や既存のシステムのことを忖度することは、好ましいことではない。旧来の方式の問題点を引きずってしまったり、システム全体としての整合性や効率を毀損してしまうことが多々ある。かといって、机上の空論ではだれも実装してくれない。
W3Cでは、このような状況を避けるために、最終的なrecommendationとする前に、最低限二つは実際に動く実装が存在することを求めている。
EPUBのときも、仕様制定と並行して、WebKitにおけるCSS縦書き実装が進んでいた。この実装がなければEPUBとHTMLの縦書きはどうなっていたか分からない。縦書きの電子書籍はなくなっていた可能性もある。
そんなわけで、村田真も木田さんには頭が上がらないわけよ。
そんな木田さんが、日本の高校に進学したお嬢さんの弁当作りのために、出身地の京都に戻ってきた。「EPUB戦記」によると、2015年9月に、帰国準備のために一時来日していた木田さんを含めて、会食をしている。
そして、2017年。講談社、小学館、集英社、KADOKAWAの出版大手4社と電子出版のメディアドゥがスポンサーとなって、慶應義塾大学藤沢キャンパスに、Advanced Publishing Laboratory（以下、APL）が設立される。
このラボの大きな目的の一つに、SFCにあるW3Cホストを通して、日本の出版界からの要望をW3Cの関連ワーキンググループのインプットすることがあった。
ぼくは、「日本語書記技術」のワーキンググループの座長を引き受け、村田真とも語らって、木田さんにもメンバーに加わってもらった。
このワーキンググループは、二つの側面を持っていて、一つは、「日本語組版処理の要件」の批判的継承、もう一つは、旧来の紙の出版物が500年余りにわたって担っていた社会的役割を継承する未来のドキュメンテーションの在り方の模索。
あたりまえのことだけれど、後者の議論は、既存の出版界の（したがって、スポンサー各社の）在り方に対して、批判的にならざるを得ない。というか、ぼく自身は、かつての電子書籍コンソーシアム時代やEPUB戦争時代のことも含め、 日本の出版社の電子出版に対する取り組み方には、常々批判的だったわけだけれど。
そんなわけで、日本語書記技術WGは長くは続かなかった。
で、前者の「日本語組版処理の要件」の批判的継承の方は、出版業界のみならず、まさにデジタル通信技術時代の日本語の在り方全般に係わる重大な問題でもあるし、日本語のみならずグローバルなW3Cのアクティビティの中でも、JLreqのアプローチはある種のロールモデルみたいになってしまってもいたので、APLの活動とは切り離して、W3Cの正式なTask Forceとして仕切り直すことになった。
ここでだ。ついに揚げ幕がチャリンと鳴って、花道から木田泰夫議長が登場。「いよ〜、竹屋あ〜」
※木田さんの京都のお住まいは、竹屋町に接しているのでね。
せっかく、アップルを退社して、ハッピーアーリーリタイアメントのつもりだったようだけれど、へへへ、またも舞台に引きずり出してやった。
で、このTask Forceについては、昨年実施されたJEPAのセミナーがなかなかよかったので、このヴィデオを見ていただくことにして。
フォント規格の闇
ぼくは、昔からフォントがらみの話題が苦手だ。内輪話めくが、文字符号屋とフォント屋は、どうも人種が違うような気がする。ぼくは、たぶん文字符号屋なのだが、フォント屋の典型はたぶん副会長をお願いしているアドビの山本太郎さん。太郎さんとの付き合いも長くって、彼がまだモリサワにいた30年以上も前からの知り合い。ぼくがジャストシステムに入って、大地という当時最先端のDTPシステムの製品企画を担当していたころから。
いずれにしても、フォントというのはある種の美的素養が係わっていて、美しいとか美しくないとかいったレベルの議論が大きな割合を占めるようだ。で、ぼく的には、ここらあたりの議論がどうにも苦手なわけ。フォント屋さんというのは、美意識とも係わりがあるのだろうが、文字の一点一画への拘りがまた半端ではない。例えば、文字情報基盤の文字情報一覧表では、ぼくの名前の一部でもある《龍》の字の最初の一画が、縦棒になっているのと横棒になっているのとに、それぞれ別の文字図形名が付けられているが、本人が言うのも何だが、まあ、どっちでもいい、と思っている。ぼくも昔編集者の端くれだったが、編集者の中には、縦棒の《龍》は品がないから使わない、とかのたまう現役の編集者もいたりして。
閑話休題。フォントの議論になると、どうしてもどのように符号化するか、ということよりも、どのような字形にするか、ということに重きが置かれるような。
そのせいかどうか、フォントフォーマットについては、今まで、規格としての美しさというか整合性の議論があまりなされてこなかったように見受けられる。このあたりからは、文字符号屋から見てもこれまた異人種であるゴリゴリの規格屋である村田真からの耳学問が多くなる。
昔から、フォントフォーマットにはWindows系とMac系の二つの大きな潮流があって、それぞれ独自の進化を遂げてきた。それが、あるときから、相互に使われるようになって、今の国際標準となっているOpen Font Format も、このWindows系とMac系のフォーマットを呉越同舟のような形で一緒くたにしてしまったために、ある視覚的な機能を実現する方法が二つならずいくつも存在する、といった状況になっている。カラーフォントにいたっては、三方式が併存しているとか。
まあ、中身については、おおむねMicrosoftの専門家とAdbeの専門家が話し合って決めているのだが、公的標準としてのOpen Font Formatは、SC29という本来はJpegやMpegなどの静止画・動画フォーマット周辺の規格を担当するSCが担当していて、SCとしての議論もほとんどないままにラバースタンプを押す、といった状況になっているらしい。書き足すなら、Microsoftは、Open Font Formatと同じものを、OpenTypeとして出版し続けている。
まあ、ぼくの主戦場である文字符号の世界でも、あまり偉そうなことは言えず、特に、利用者が非常に少ない言語に係わる文字(minority script)や、歴史的な文字(histric script)については、日本国内の専門家へのアプローチもままならないままに、UTCのエキスパートにおんぶにだっこのままで、ほとんど無批判に賛成票を投じているような現実もあるのだけれど。
背景説明が長くなったが、やっと木田さんの話に戻れそう。
JSC2にフォントにもわがCITPCから標準化活動にも通暁した専門家を送り込もう、と考えたとき、もうぼくたちの頭の中には、木田さん以外の名前は浮かんでこなかった。
木田さんは、どうも、規格屋でも文字符号屋でもフォント屋でも、なさそうなのだ。
あえていえば、「竹屋あ〜」。
アップルにももちろん、規格屋もいれば、文字符号屋もフォント屋もいるわけで、木田さんは、そんな一癖も二癖もあるエキスパートたちをうまくコントロールして、現在のMacやiPhoneの日本語関連機能を、アクセシビリティをも含むグローバル、ユニバーサルな機能の中で、調和的に実現してきたわけだ。
そんな木田さんを、リエイゾンとしてJSC2に送り込むことが出来るCITPCって、なかなかなもんだなあ、とまたも自画自賛で今回はチョンチョンチョンチョン。
2022年から2023年へ
いささか遅蒔きながら。謹賀新年。
事務局長の田丸健三郎さんとの約束もあるし、この機会に昨年の協議会活動の振り返りと、今年の抱負というか課題を纏めておこうと思う。
2022年の振り返り
特別講演での諸橋漢和をめぐる講演
毎年の恒例となっている理事会・総会の折の特別講演。今回は、写研の杏橋達麿（OB）さん、そして、大修館書店の池澤正晃さん（OB）と山口隆志さん。山口さんとは面識があったが、杏橋さんと池澤さんは初対面。委細は以前のブログでも触れたので割愛するが、日本の出版印刷史の上でも、文字情報技術の流れの中でも、まさに時代を画した記念碑的出版物について、内容面技術面双方からの貴重なお話をうかがえたことは、協議会の若いメンバーにとっても、得がたい経験だったと思う。
浦山毅さんの講演
浦山さんの講演もまた記憶に残るものだった。
まあ、個人的には、ぼくの「ユニコード戦記」（東京電機大学出版局）と「EPUB戦記」（慶應義塾大学出版会）の編集者だったこともあり、いささか手前味噌とはなるが、安岡さんや三上さんの著書や「インターネット時代の文字コード」（bit最後の別冊）も含め、浦山さんがいなければ、日本の文字情報技術に係わる記録が出版物として残されることもなかっただろう。
浦山さんの講演が契機となって、今は新潟の開志専門職大学で副学長を務めておられる協議会元会長で現在も理事を務めてくださっている三上喜貴さんを含め、三人で（おっと、同大学の教授で、前SC2国際議長の田代秀一さんも含めて四人で）新潟での清談の機会を得たことも嬉しかった。
全国地域情報化推進協会(APPLIC)主催セミナー
APPLIC主催のセミナーに招かれて、事務局長の田丸健三郎さん、理事の袴田博之さん、同じく理事の田原恭二さんが講演をしてくれた。
[https://moji.or.jp/seminar/]
このような機会を与えてくださったAPPLICの関係者の方々には感謝の思いしかないのだが、望外の喜びは、このセミナーを契機として複数の組織が協議会に参加してくださったこと。今後も、文字情報技術と協議会活動についての競技化以外での衆知活動はより積極的に行っていかなければならない、と肝に銘じた次第。
フォントのメインテナンス体制
凸版印刷の田原恭二さんとフォントワークスの津田昭さんが中心となって、MJ明朝体のメインテナンス体制についての詳細な検討をしてくださった。技術的な裏付けと、作業手数の規模がおおむね把握できたことで、今後の事業計画への見通しが格段とよくなった。現場でビジネスとして係わっている専門家を擁する協議会の強みというかありがたみを改めて感じた。
文字情報基盤委員会の正式発足とUCS水平拡張のためのレビュー
2020年に独立行政法人情報処理推進機構との信託譲渡契約に基づき、文字情報基盤整備事業の成果物全般についての権利と義務を引き継いだことをうけて準備をすすめてきた、委員会が正式に発足した。関係府省庁の担当者や協議会外の専門家もオブザーバーとして招き、公開性と公共性にも配慮しながら審議を進めていきたいと考えている。
この委員会としての最初の大仕事が、UCSの符号位置に対応するすべてのMJ文字名を典拠として追加する提案。きっかけは、IRGのアクティヴメンバーの一人であるHenry Chenさんからの、MJ文字図形名とUCS符号位置の対応関係についての複数のコメントだった。この件の経緯についてはこのブログでも何度か触れている。
2022年の大きな到達点は、文字情報基盤委員会のメンバーによる内部レビューが終了したこと。このことで、修正必要個所（約40個所）の規模感が把握でき、今後の情報処理学会情報規格調査会SC2専門委員会と共同で主宰する国内レビューと、ISO/IEC JTC1/SC2への正式な提案へのかなり明確な見通しがたった。
2023年に向けて
以下、2022年の成果を踏まえてのランダムなToDoリスト。
UCS水平拡張のためのパブリックレビューの実施
情報処理学会情報規格調査会SC2専門委員会と共同で実施することになっている。ユニコードコンソーシアムは、UCSに対して提案を提出する前でも、積極的にパブリックレビューを実施し、広くコメントを求めているが、日本から国際規格への提案を行う際に、事前のパブリックレビューを行ったことは寡聞にして聞いたことがない。結構画期的なことだと思っている。
APLICと協働でのデジタル庁に対する文字情報技術に関する提言
デジタル庁では、さまざまな面から、自治体のIT化に向けたガイドラインなどを策定してくれている。文字情報基盤が数少ない民間管理の情報としてベースレジストリに採用されていることもあり、協議会としても、その動向に無関心というわけにもいかない。
手前木曽ながら、協議会には、文字情報技術についての、真の専門家がそろっているので、細かなことも含め、いろいろと気になることが出てくる。これらのことがらを取りまとめて、APLICさんとも協力して、提言として提出する準備をすすめている。
文字情報基盤準拠フォントの確保
上記でも触れたが、デジタル庁の自治体IT化への指針では、MJ明朝体フォントの使用が前提となっていると仄聞している。
しかし、IPA時代の関係者の考えは、何が何でもMJ明朝体フォントでなければならない、というものではなかった。むしろ、事業の性格上、一つだけは無償で利用できる明朝体フォントは必須だが、それが民業を圧迫することなく、願わくばゴシック体などの別書体フォントも含め、複数の文字情報基盤準拠書体が開発・市販されることを期待して、具体的な使用許諾契約の作成や、さまざまな施策を行ってきた。
正直なところ、IPAとの信託譲渡契約で、MJ明朝体フォントについても、その権利と責任を引き継いではみたものの、その保守には、それなりの予算投入が必要であり、まだまだ発足まもなく、予算規模も限られている協議会としては、保守費用の捻出が頭痛の種。
一方で、協議会会員のなかには、開発中のものも含め、文字情報基盤に準拠したフォントを持っておられる会員が複数在るとも仄聞している。
このような会員会社が保有されている文字情報基盤準拠フォントに対して、協議会としてのおおやけに承認する制度の検討も焦眉の急だと思われる。
運営委員会で話し合った結果、文字の知識部会（田原恭二主査）が中心となり、文字技術支援部会の協力も得て、この認証制度に特化したタスクフォースを結成して、準備作業を加速することにしている。
文字情報技術チュートリアルビデオ
これは、昨年運営委員会でアイディアを提案して、大方の賛同は得たものの、ぼく自身、動画での情報提供については、ずぶの素人なものだから、具体的に手が付けられないままで、年を越してしまったもの。
個人的には、ぼくも齢70を越えて、自分が手がけてきたことについては、そろそろラップアップというか手仕舞いのフェイズに入りたいなと思っている。で、協議会会長としての最後のお務めは、ぼく自身（と同世代の仲間が）先達から受け継いできたことどもを次の、そして、次の次の世代に、きちんと申し送りすることかな、などと。チュートリアルビデオの開発の背後のは、このような思いもある。
協議会は、国立国語研究所の高田智和さん、京都大学の安岡孝一さんという、文字情報技術に関してはまさに日本の第一人者、第二人者（ま、どっちが上と言うこともないのだけれど）を擁している。このお二人に、協議会副会長で日本タイポグラフィ学会会長の山本太郎さん（アドビ）を加えれば、フォントや組版周りまでカバーした鉄壁の布陣となる。このお三方に不肖小林（ユニコードに関してはね）が加わって、編集委員会みたいなものを立ち上げ、技術面についてと具体的な事柄に関しては適宜若手会員の協力を仰ぐような形で、進めて行ければいいなあ、と思っている。
当面は、コンテンツ面を、高田さん、安岡さん、山本さん、小林が、技術面を、下川さん（イースト）、水野さん（イワタ）が、全体の進行管理を宮田さん（大日本印刷）が担当して、いくつかのパイロットビデオを制作してみようと話し合っている。
仮のタイトルが「村田真にも分かる文字情報技術のすべて」（笑）
大漢和辞典の関連字
しばらく間が空いてしまって。事務局長の田丸さんから、会長ブログを毎月更新するよう厳命を受け、やっかいなことに、副会長の村田真さんがその場にいたものだから。。。
言い訳じみたことになるが、ここのところ、大漢和辞典の関連字情報の整理に取り組んでいる。かなりやっかいな大仕事だ。とは言え、今やっておかなければ、という危機感というか使命感もある。
こんな気持ちになったのには、それなりの経緯がある。
ことは、ぼくがIPAに専門委員として係わっていたころに遡る。2010年、そのころIPAにいた田代秀一さんに慫慂されて、経済産業省から受託した文字情報基盤整備事業にかかわることになった。文字情報基盤事業の前身となる、汎用電子情報交換環境整備プログラムが、何だか腰砕けというか成果が店ざらしのようになっていて、やるせない思いもあったので、手伝うことにした。
この事業は、IPAの独自予算で継続され、2017年になって、ISO/IEC 10646第5版の発行で、整備してきた約6万字の国際整合性が取れたことで、一応の終結を見た。
この事業の二つの大きな成果物が、文字情報一覧表とＭJ明朝体フォントであることは言を俟たないが、実は、この文字情報一覧表を開発する過程で、一覧表には明示的には含まれておらず、一般には公開もしていないいくつかの情報が開発された。当協議会は、これらの一般には公開していない情報も含めて信託譲渡を受けたわけだが、これらの情報の扱い方については、現時点では、協議会内で議論しているところ。
で、これらの一般には公開していない情報の中に、大漢和辞典のぼくたちが内々に関連字情報と呼んでいる一連の情報がある。要は、正字と俗字や古字の関係、譌字や籀文と呼ばれる、誤り字の情報など。
ところが、大漢和辞典は、その編纂作業が実質的には先の太平洋戦争以前に遡ることもあってか、これらの関連字情報の記述が、現代的な意味では正規化されていない。ある意味で、味のある表現ではあるのだけれど。
例えば、文字情報基盤事業で調査の対象とした大型漢字辞典の中でも、最も新しく編纂された新潮社の日本語漢字辞典では、
といった塩梅で、常用漢字体を見出し字として掲げ、旧字、正字などを整理して、親字の下にまとめて掲げている。
それに対して、大漢和辞典では、
とか、
とか、
とか、いわば、バラバラに記載されている。さらに、記載方法も多岐にわたっていて、「〜の俗字」という書き方だけではなく、「俗に〜に作る」とか、「〜に作り、通じて〜に作る」とか、まあ、百花繚乱といったところ。それぞれの記述方法の間に、どのような差があるのかは、調査の目処がたったら、ぜひとも、高田さんや笹原さんにうかがってみたいと思っている。
というわでけ、この大漢和辞典の関連字調査は、相当な大仕事（ほとんど全巻をなめるように調査しなければならない）なので、調査を受託した某社との打ち合わせの際、ぼくはついつい、「見出し字の下に記載してある情報だけでいいですよ」と口走ってしまったのだ。慚愧の極みなのだけれど、そのころのぼくは、まだ、大漢和辞典の実物を手元に持っていたわけではなく、必要に応じて、近場の図書館で調べてみる、という程度で、上に掲げたような大漢和辞典の実態について、よく理解してはいなかったのだ。
その後、一念発起して、全巻を（ネット上の古書店で）入手し、えいやで自炊してみて初めて「しまった」と思い知った次第。
「しまった」と思い知ってからも、作業の膨大さに尻込みして、調査を始めることはなかった。
時は移り、近ごろになって、協議会が文字情報基盤事業の成果物をIPAから信託譲渡され、文字一覧表が政府のベースレジストリに取り上げられ、府省庁などから縮退情報についての問い合わせなどが来るようになって、さすがに、このままではちょっとやばいなあ、と思い始めた次第。何しろ、各大型辞典の関連字情報は、これも、協議会として公開している、MJ文字からJISX0213への縮退マップ情報の、基礎資料として使われているのだから。
いずれにしても、近ごろのぼくは、Python上で、PIL（Python上の代表的なイメージ処理のライブラリー）やら、OpenCV（元々はインテルが開発したオープンソースのグラフィックライブラリー）やら、Tessoract（グーグルが開発しているオープンソースのOCRライブラリー）やらのお世話になりながら、自炊した大漢和辞典のイメージデータからの関連字情報の抽出に没頭していて、会長ブログの更新がおろそかになっていた次第。
田丸事務局長、ゴメンナサイ。
ユニコードとの許諾契約
大漢和辞典を巡る特別講演
2022年5月25日、2年ぶりに対面での（ネットミーティング併用）理事会、総会が、新宿のイースト株式会社の素敵なカンファレンスルームをお借りして開催された。
その後開催された懇親会も、感染症対策には十分留意しながらも、楽しく有意義なものだった。
しかし、それよりも何よりも、総会と懇親会の間に開催された特別講演会が、素晴らしかった。
講師は、元写研の杏橋達麿さんと、元大修館書店の池澤正晃さん、そして、同じく大修館書店の山口隆志さん。お三方から、大漢和辞典の誕生と成長に係わる貴重なお話を伺えた。なかでも、杏橋さんと池澤さんのお話の双方からは、石井明朝体の字体設計理念といわゆる康煕字典体との関係が浮かび上がり、興味は尽きなかった。
今でも、当協議会会員のフォントベンダー各社には、必ず大漢和辞典が（おそらくは一セットならず）置かれているに相違ないが、大漢和辞典が、日本だけではなく東アジア漢字圏全体でも高い評価を維持している理由を垣間見た気がした。
ユニコードコンソーシアムとの契約
講演会が終わって幾日もしないうちに、Ken Lundeからのメールが届いた。このメールには、当コンソーシアムの副会長をお願いしているアドビの山本太郎さんがKenとともに骨をおってくださった”License Agreement For use of the MJ Character Information List”に、Unicode ConsortiumのPresidentであるMark Davisのサインが入った正式の契約書が添付されていた。
当協議会から会員にお送りしたお知らせを読んでいただければ、この契約の概略がお分かりいただけると思う。
お知らせ
2022年5月30日に一般社団法人文字情報技術促進協議会は、The Unicode Consortium（正式名称：Unicode Inc.）とのあいだで、『「MJ文字情報一覧表」の利用許諾契約』（License Agreement For use of the MJ Character Information List）を締結しました。
この契約は、The Unicode Consortiumが、『MJ文字情報一覧表』に含まれる情報の一部をThe Unicode Consortiumが開発し、管理しているthe Unicode Han Databaseの属性情報に取り込むことを許諾するものです。それによってthe Unicode Han Databaseの内容の改善が可能になります。具体的には、The Unicode Consortiumでは、『MJ文字情報一覧表』に含まれる一部情報を用いて、the Unicode Han DatabaseのCJK統合漢字の属性情報の追加・修正を行うことを予定しています。このことは、UnicodeにおけるCJK統合漢字の維持・管理・拡張のために用いられる情報の品質と一貫性を向上することに資するものであり、今後のUnicodeの普及促進にも寄与すると考えます。
本件は、文字情報技術促進協議会とThe Unicode Consortiumとのリエゾン関係の締結と並行して、2020年から両者のあいだで協議されてきましたが、このたび、その正式な締結に至りましたのでお知らせいたします。
文字技術促進協議会
当協議会とUnicode Consortiumは、正式なリエイゾン関係を結んでいる。
リエイゾンというのは、元々は軍隊の連絡将校のこと（正確にはliaison officer）。標準化の世界では、関係のある委員会やコンソーシアムなどの間で、情報共有を図るために相互に技術者を派遣する。
Unicodeと当協議会でも、Unicode側がKen Lunde、協議会側が山本太郎さん、ということになる。
当協議会が、一般社団法人格を取得した直後、Unicode側からリエイゾン関係の申し入れがあり、もちろん、喜んでお受けした。というか、CITPCも世界のUnicodeとリエイゾン関係を結べるようになったのだ、とある種の感慨を覚えたものだ。
大漢和漢和とUCSとの対応テーブル
じつは、Unicode ConsortiumがCITPCにリエイゾンの申し入れをしてきたのには、わけがある。ずばり、UCSと大漢和辞典との対応テーブル。
Unicodeは、漢字関連のさまざまな情報を集めた、Unihan Databaseという巨大な情報群を持っている。
詳細は、Unicode.orgご本家のホームページを参照していただくこととして。
[https://unicode.org/charts/unihan.html]
ところが、ここに含まれている大漢和辞典とUCSとのマッピングテーブルは十全なものではない。カバーしている範囲がかなり少ないのだ。そこで、文字情報基盤の情報の出番ということになる。
文字情報基盤の文字情報一覧表には、それぞれのMJ文字図形に対応するUCSの符号位置とともに、日本の代表的な大型漢字辞典の検字番号との対応表が記載されている。もちろん、諸橋徹次の大漢和辞典の検字番号も記載されている。ということは、MJ文字図形名を媒介としてUCSと大漢和辞典の対応関係が取れる、ということだ。ユニコードコンソーシアムが欲しがっているのは、まさに、この対応テーブルというわけ。
ところが、以前の会長ブログでも触れたことだが、文字情報基盤の文字情報一覧表には、MJ文字図形名とUCS符号位置の対応関係には、すでにいくつか改訂すべき個所が見つかっている。当然、大漢和辞典の検字番号とMJ文字図形名との対応関係もきちんと見直さなければならない。
それよりも何よりも、MJ文字図形が大漢和辞典のすべての見出し字をカバーしているわけではない。
そんなわけで、Unicode Consortiumとの契約は締結されたというものの、この契約を実施に移すには、まだまだやるべきことが山積というわけ。やれやれ。
似ている漢字とは（その1）
ユニコードには、統合規則(Unification Rule)、JISには包摂規準という、似ている漢字を同一の符号位置だと見做す決まりがある。ご存じの方も多いと思われる。
このような決まりの背後には、字体(character)と字形(glyph)の違いという、言語学的な概念の違いがある。この字体と字形の概念については、ぼく的には、以前書いた下記の文章がわりとよく書けていると思っている。
[https://www.jstage.jst.go.jp/article/johokanri/58/3/58_176/_article/-char/ja/]
また、早稲田大学の笹原宏之さんたちの力作、
「常用漢字表の字体・字形に関する指針」（文化審議会国語分科会報告）
https://www.bunka.go.jp/koho_hodo_oshirase/hodohappyo/pdf/2016022902.pdf
が、文字行政での運用に関しては、基本資料と考えていいだろう。
何かの会議のあと、文化庁国語課の武田さんが、わざわざ近づいてきて、上に挙げたぼくの文章のことを気恥ずかしくなるほど褒めてくれたので、ぼくの考えも、文化審議会の考え方とそれほどは違っていないのだろう。
ちなみに、JIS X 0213では、2014年だったかの改正の折、従来は解説で、常用漢字表の字体と字形についての図版だけを引用していたところを、本文もごそっと引用して、文化審議会に対する（というか内閣告示・訓令に対する）恭順の意を明確にしている。
そんなわけで、前回触れた、文字情報基盤のいわゆるMJ文字図形とUCSの符号位置との対応関係についても、基本的には、UCSの附属書Sに記載されている統合規則に従って、同一の字体と見做せるものを結びつければいいわけで、この規則に従って、同一の書体とは見做せないものは、エラータとして訂正する必要がある。
今回のレビューは、ISO/IEC JTC1/SC2に対して、いくつかの（と言っても3万以上だけれど）符号位置について、新たな典拠（MJ文字図形名）の追加を日本から提案する前に、間違いがないかどうか、念のためにもう一度確認しておこう、というものだ。まあ、それが国際標準に提案する際のお作法といった塩梅でもある。
で、その準備を少しずつ進めているのだが、協議会の主力メンバーのお一人から、「社員にレビューを手伝ってもらいたいのだけれど、具体的にどうやったらいいか教えてもらいたい」という問いかけをいただいた。
正直なところ、ちょっと足下をすくわれた思いだった。
ぼく自身、もう20年ぐらいは、UCSの漢字パートのレビューをやってきてはいるが、では、具体的にどうすればいいか、マニュアル化しろとか言われると、ちょっと戸惑ってしまう。UCSの標準化に日本として係わっている情報処理学会情報規格調査会SC2専門委員会(JSC2)でも、ISO/IEC JTC1/SC2?WG2の下で実作業を担っているIRGにしても、具体的な方法のガイドラインがあるわけではなく、いわば、見よう見まねで、受け継がれてきた、というのが実情なのだ。
ぼくが、標準化に係わり始めたころ、作業の中核を担われていた、元日立製作所の小池さんなど、新しい符号化提案のリストを見ながら、「定規で一行ずつさささっと追っていけば、UROにあるかないかぐらいすぐに分かるよ」とおっしゃっていたし、元アドビのKen Lundiなど、フォトグラフィックメモリーの特殊能力を持っていて、CJKの漢字のイメージが全部脳に刻み込まれているみたいで、このような人たちには、どう逆立ちしても、勝てっこない。
それに、小池さんの時代は、UROの漢字は、全部併せても2万字に満たなかったのが、今では、9万字以上もある。
とても、ゼロから目視で似ている漢字を探し出すなどという作業が出来るとは思えない。というか、やってはいるが、誤りや見落としをゼロとして、完璧に出来るとは考えがたい。
そこで、何らかな機械的な作業を補助的に使おう、ということになる。
今回は、そんなお話。
部首画数順
IRGでは、新しい文字の標準化を提案する際には、典拠資料とともに、いくつかのメタデータを添付することになっている。その一つが、康煕部首と部首内画数。
最初に発行されて以来、CJKパートは伝統的に、まず、康煕部首の順に、次いで部首内画数の順に排列することになっている。何のことはない、一般的な漢字辞典の見出し字の排列順と同じ。
で、IRGのメンバーも、レビューの際には、基本的に、部首画数順に排列された既存の文字と照らし合わせていくことになる。
ところが、ご存じのように、CJK統合漢字は、UROを初めとして、現在の拡張Gまで、拡張に拡張を重ねていて、それぞれのブロックごとに部首画数順に並んでいて、いちいち見ていくなど、面倒で仕方がない。
そこで、Unicode Consortiumのホームページにある、全統合漢字の部首画数順インデックスを使ったりする。
(img)
しかし、厄介なことに、この部首画数順というのがくせ者なのだ。
経験された方も多いと思うが、あれっと思う字があれっという部首に属していたりする。漢字学の泰斗、阿辻哲次さんは、実家が活版印刷屋さんで、門前の小僧で、活字箱に慣れ親しんでいたため、高校生のころ、授業で難解な漢字の部首を言い当てて、先生に褒められ、それがきっかけとなって漢字学の道に進むことになったと、その著書に書いておられる（今、探してみたのだけれど、何という本のどこに書かれていたかが見つけられない）。
世界に名だたる諸橋徹次の大漢和辞典でも、複数の部首に誤って二重に掲載されている漢字が複数ある。
というわけで、CJK統合漢字でも、どの漢字がどの部首に排列されているかには、どうしてもある程度の曖昧さが伴う。というわけで、提案された文字に付いている部首名だけを頼りに、統合されるべき文字を探しても、相手が別の部首に排列されていて見つけられない、などということは、日常茶飯のことなのだ。
そんなこともあって、文字情報基盤のMJ文字情報一覧表では、参考として康煕部首が複数（最大4個）掲げられていたりする。
教訓風に言うと、康煕部首に頼りすぎるのは危険。
UCSの方はと言えば。
規格票には、一応、部首と部首内画数は記載されているが、情報の多くは、Unicode.orgのUnihanDatabaseに記載されている。
いつも、オリジナルのファイルを探すのに苦労するので、覚えのために書き留めておくと。
https://www.unicode.org/Public/UCD/latest/ucd/Unihan.zip
にまとまっている。
ところが、これがまた、見にくい。
全コードポイントの部首と部首内画数、総画数が含まれているのは、
Unihan_IRGSources.txt
で、この中で、二つ目のカラムが”kRSUnicode”となっているのが、康煕部首番号と部首内画数、”kTotalStrokes”となっているのが、総画数。
やれやれ。これを、表計算ソフトやデータベース、何らかのスクリプトで処理しないと、それぞれのコードポイントごとの部首番号、部首内画数、総画数を一覧することは出来ない。
注意点を一つ。UnihanDatabaseには、”Unihan_RadicalStrokeCounts.txt”というファイルがあり、康煕字典の部首画数情報とAdobe Japnan 1の部首画数情報が収められているが、この情報は、符号化されたCJK 統合漢字やCJK互換漢字の全符号位置を網羅しているわけではない。恥ずかしながら、ぼくがこのことに気付いたのは、ごく最近、水平拡張レビューのための、下作業を始めてから。面目ない次第。
部品検索
部首画数順とちょっと似ているのが、漢字を構成する要素を、部首に限定せずに指定して検索する方法。当協議会のサイトでは、要素図形（検索）と呼んでいる。
電子メールはおろか、ファクシミリもなかったころは、現地取材に出た新聞記者が、本社に記事を電話で送っていた。いわゆる電話送稿。同音異義語の間違いを防ぐために、「うしへんにつち」（牡）とか「おんなみっつ」（姦）とかやっていた。共同通信で電子化関係を担当していた知人の話だと、この表現も、新聞社による多少の違いはあれ、かなり統一されていたということだ。
この仕組みはユニコードにも導入されていて、漢字を構成する要素を、どのように並べるかを指定するIdeographic Description Charctersという一群（⿰⿱⿲⿳⿴⿵⿶⿷⿸⿹⿺⿻都合10文字）の文字が規定されている。
この仕組みを用いれば、例えば、⿱ 山奇（嵜）と⿰山奇（崎）といった要素の位置の違いと表現することも出来る。このようなIDCを含み、要素図形の構成で漢字を表す文字列をIdeographic Description Sequence(IDS) と呼んでいる。
しかし、ちょっと考えればお分かりと思うが、ある漢字を表現するIDSは一通りではない。例えば、「淋」という字は、⿰氵⿰木木 とも表現できるし、⿲氵木木とも表現できる。
そんなわけで、IDSを漢字検索に用いるためには、いろいろと厄介な操作が必要となる。
ちなみに、当協議会の要素図形検索は、IDSは用いずに、該当漢字の構成要素と見なすことの出来るMJ文字すべてを列挙するようにしてある。そのため、入力する要素図形によっては、膨大な数の候補文字が出て来たりするが。
IDSで一番整備されているのは、何と言っても、兄弟の守岡さんが作っている、Chiseプロジェクトのもの。これについては、以前、書いたことがある。
https://moji.or.jp/2020/05/07/chise%E3%83%97%E3%83%AD%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%AEids/
IDSと文字情報基盤の要素図形情報は、似ているようで、じつのところ、相互参照しながら利用しようと思うと、案外厄介な問題がある。今回の水平拡張レビューを目指した試行錯誤でも、いろいろやってみたが、大まかなフィルタリングには使えるが、細かく絞り込もうと思うと、なかなか連動させるのが難しく、結構苦労した。MJならMJ、大漢和なら大漢和、UCSならUCSという文字セットごとに、IDSならIDS、要素図形検索なら要素図形検索単独で用いるのが無難かな。
さて、いよいよ図形的に似た字についての議論に進みたいのだけれど、今回は、ここで一休み。