一般社団法人 文字情報技術促進協議会
会長
小林 龍生
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、要素図形検索なら要素図形検索単独で用いるのが無難かな。
さて、いよいよ図形的に似た字についての議論に進みたいのだけれど、今回は、ここで一休み。
UCS水平拡張とパブリックレビュー
Chanさんからのコメント
中国のHenry Chanさんから、また、コメントが来た。日本の外からくるコメントは、ことのほか嬉しい。
しかし、今回のコメントの一つには、いささか、というか、かなり頭を抱えてしまった。
内容的には、先にもらった2件のコメントと同様で、MJ文字図形名とUCSとの対応関係のバグ。
先にもらった2件のコメントを受けて、いろいろ調べまくって、汎用電子情報交換環境整備プログラム時代の大漢和辞典とUCS符号位置との対応テーブルが怪しい、というところまでは当たりを付けて、現在の文字情報基盤資料をベースにした大漢和辞典とUCSとの対応テーブルと、このテーブルとは独立に調査作成された別のテーブル（NTTの川幡太一さんの力作）とを、ぶつけ合わせて、同じ対応関係のものは正しい、と仮定し、何らかの齟齬のあるものに絞って、当協議会のエキスパート会員で、文字情報基盤委員会の委員長をお願いしている国立国語研究所の高田智和さんや、同じくエキスパート会員で京都大学の安岡孝一さんに中心になってもらってレビューをやり、それなりの個数（30組ぐらい？）を、訂正候補として洗い出した矢先だった。
Chanさんの今度のコメントを調べてみたら、何とMJのテーブルと川幡さんのテーブルが共に同じ過ちを犯していることが分かってしまった。ありゃりゃ。
水平拡張計画
以前書いたことだけれど。
[https://moji.or.jp/2021/06/03/mj%e6%96%87%e5%ad%97%e5%9b%b3%e5%bd%a2%e5%90%8d%e3%81%a8ucs%e7%ac%a6%e5%8f%b7%e4%bd%8d%e7%bd%ae%e3%81%a8%e3%81%ae%e5%af%be%e5%bf%9c/]
Chanさんから新たなコメントをもらう前から、当協議会では、UCS策定を担当しているISO/IEC JTC1/SC2のミラーボディである情報処理学会文字情報規格調査会SC2専門委員会（JSC2）とも相談して、MJ文字図形名のうちUCSに日本ソースとしての記載がないものについて、すべてMJ文字図形名を記載する提案（いわゆる水平拡張）を行うべく、準備を始めていた。
文字数が多いとは言え、作業的には、それほど厄介なことではない。しかし、提案にバグが残っているとすると、これはちょっと厄介なことになる。公的標準規格になることで、バグが固定化されてしまう。一旦、公的規格として固定化されたバグは、おいそれとは変更することが出来ない。だからこそ、提案する母体としても、提案を審議する主体としても、慎重の上にも慎重なレビューをすることが求められる。ま、UCSにもまだバグは残っていて、特に、CJK拡張Bなど、いまだに、ポチポチとバグレポートが上がってくる。
今回水平提案を予定しているMJ文字図形は、合計すると3万字以上あるので、ぼく自身の経験を踏まえても、バグを根絶することはおそらく不可のだろう。だからといって、適当にお茶を濁すというわけにも行かない。
そんなわけで、意を決して、提案文字全てのUCSとの対応関係について、提案者として改めて悉皆レビューを行うことにした。
そこで、お願い、というか。
このレビューに、このブログを読んでくださっている方々にも参加していただきたいのだ。
以前著した「ユニコード戦記」のまえがきに、ぼくは以下のようなことを書いている。
符号化文字集合にみならず、情報標準は、一般のユーザーにとっては、通常は意識に上ることすらない所与のものであろう。しかし、すべての情報標準は、その開発にかかわった人々の営為の結果であり、開発の過程には悲喜こもごもさまざまなドラマがある。
ぼく的には、公開レビューによって提案文書のバグを少しでも減らしたいという思いとともに、当協議会がIPAから引き継いだ文字情報基盤の成果物を何らかの形で利用されるみなさまに、主体的な当事者として、ご自分のものとして活用していただきたいなあ、と思っているのだ。パブリックレビューに加わっていただくことにより、そのような「自分のもの感」を持っていただければなによりも嬉しい。
具体的なお願いは、改めてすることになると思うが、このブログの読者諸兄姉の積極的な御協力を懇願する次第。
Variation Selector縁起
MJ戦記とほにゃらら戦記を書き継いでいこうと思い立って、「書き始め」の下書きをして、副会長の村田真さんにレビューを依頼したら、誤植の指摘などをそっちのけで（後で、ぼく自身が読み返したら結構あった。編集者時代も、ザル校で有名だったからなあ）、
檜山さんがアイディアを出した場に居合わせたような覚えがあるのですが、あれがきっかけでしょうか？
と、昔話を蒸し返してきた。
たしか、村田さんと最初に出会ったころ。今でも在野のコンピュータサイエンティストとして活躍している檜山正幸さんが声を掛けてくれて、当時はバリバリのXML専門家（なにしろ、日本人として唯一W3Cのワーキンググループに参加して、オリジナルのXML策定に係わっていたわけで）だった村田さんと、これまた、UNIXのX Windowの日本語化（国際化）で辣腕を振るっていたスーパーエンジニアの樋浦秀樹さん、それにぼくとで、檜山さんご贔屓の渋谷のタイレストランで食事をした。檜山さんが連載を持っていた月刊ASCIIの（当時は）若手編集者だった西村賢さん（今では、押しも押されぬベンチャー投資ファンドのマネージャー）が、財布と小型録音機を持って参加してくれて、ぼくたちの雑談を、見事に換骨奪胎して、それでもものすごく臨場感に溢れた鼎談にまとめ上げてくれた。（1998年6月号所収）
この記事を読み返してみると、主な話題はこの年に東京で開催された国際ユニコード会議(IUC, International Unicode Conference)周辺のことだったが、この時点で、ヒデキとぼくがUTCに提案したVariation Selectorの話題が、規格化が予定されているイッシューの一つとして話題になっている。
ぼくが、最初にIUCに参加したのが、1995年だから、それから、3年しか経っていない。そうか、そのころ、もうVSの規格化は決まっていたんだ、みたいな。村田さんがメールで言及していたのは、この折のことだったのだと思う。
で、思い出したのが、文字コード委員会のこと。前回のブログにもちょっと触れたけれど、通商産業省（当時）の力添えで、情報処理学会情報規格調査会が、デジタル環境下での人名漢字を巡る問題圏を明確にすることを目的として開催した一連の委員会。一応、佐藤孝敬さんとぼくが仕切った。
この委員会の記録、以前は、情報規格調査会のホームページの委員会議事録と報告書のアーカイブが公開されていたが、大規模なクラッキングを喰らったドサクサで、公開が止まってしまったみたい。
で、今、手元のハードディスクを掘り返してみたら、報告書がいくつか出て来た。
1999年8月付けの「文字コード標準体系検討専門委員会報告書」
2001年8月付けの「文字コード標準体系専門委員会中間報告書」
2002年3月付けの「文字コード標準体系専門員会報告書」
この委員会のことは、そのうち、資料の再公開に向けた動きがあったときにでも、書くことにして。
報告書を見ていると、奇妙なことに気がついた。
2002年3月付けの報告書には、下記のような提言が掲げられている。
提言1 新字種提案制度の創設
公的標準で採録候補となる文字を提案する制度の創設。一般から提案 された文字の審査のための委員会の設立と文字データベースの作成の 提案。委員会での検討法や文字データベースの特徴などの詳細を整理。
提言2 異形字アーキテクチャの標準化
既に標準化されている文字を代表字として、その異形字を枝番で表現 するための新しいアーキテクチャ。具体的には符号枝番方式とフォント 枝番方式を提案。このような方式の利点と課題を整理。
提言1は、一般的な新字種提案制度としてではなく、まさに、その後の汎用電子情報交換環境整備プログラムや文字情報基盤整備事業で、戸籍統一文字と住基ネット文字の統合整理を中心とする行政実務で用いられている漢字の悉皆調査の形で、より包括的に実現されることとなった。
新字種提案という意味では、事実上、法務省への戸籍統一文字への追加要請という形で実施されているとみることも出来るだろう。
問題は、提言2。ぼく的には、あれれ、という感じ。というか、このあたり、かなりビミョー。
『ユニコード戦記』（p.222〜）にも書いたことだけれど、そもそもぼくが、ヒデキやアップルの木田さんと一緒に、Variation Selectorの提案を書いたのが、1997年12月。この提案は、当時マイクロソフトにいたマリー・サージェントの数学記号についての提案とのタッグで、思いのほかすんなりとUTCやSC2の審議に通って、標準化が実現した。
この時点でのぼくたちの狙いは、CJKのいわゆるマルチカラムの例示字形の差異（典型的な例が骨）を、このVSで解消しよう、というものだった。
ところが、この字形差というヤツがなかなかの厄介者で、ある視覚的な字形の差を、単なる字形差やデザイン差とみなすか、字体差とみなすか、が国や地域、適用領域によって千差万別なのだ。十人十色というけれど、この問題について言えば、十人百色といった塩梅になる。この字形と字体の問題について、後にぼくなりの結論をまとめたものがある。
いずれにしても、Variation Selectorを統合漢字全体に対して、一律に適用することには、佐藤さんが強く反対した。この時点で佐藤さんは、字体を分ける粒度（後にぼくは、字体判別粒度という勝手な言い方をするようになる）が、国や地域によって、また、場合によっては日本の国内においても、その用途や利用する分野によって異なることを、身に沁みていたに違いない。そんな状況の中で、CJKのカラムごとの字体のみをVSで使い分けられるようにしても、どうせさらなる細かな使い分けの要求が出てくるに違いない。所詮、国際標準なんて妥協の産物に過ぎないのだから、そもそも、国際的に統一された字体分別粒度を定めること自体が、ナンセンスなのだ。
まあ、今だから、わりと整理した形で説明できるが、佐藤さんの頭の中には、このような考えがモヤモヤと渦巻いていて、それが、IVSをCJKのマルチカラムに統一的に適応することへの強い反対となって表れたのだろう。
ともあれ、Variation Selectorが漢字に適用されるようになるのは、Adobeからの提案が元になってUnicode Consortiumの場で実現したIVD(Ideographic Variation Database)という、まさに登録制度まで待たなければならなかった。
で、文字コード標準体系検討専門委員会の提言に戻ると。
ぼくが、あれれ、っと思ったのは、このような経緯で、Variation Selectorのメカニズムは、1998年時点ですでに標準化が決定していたのに、2002年の提言では、シラッと「符号枝番方式の新しいアーキテクチャの提案」などと、書かれている。
定かな記憶はないが、提言を含め、報告書の多くの部分をぼくが書いたに違いない。直接には書いていなくても、細かく目を通していたことは確かなことだ。
それにしても、なぜ、このようなことが起こったのだろう。
村田さんがEPUB標準化の戦いをしていたころに書いた、ぼくが「だから私は嫌われる」と呼んでいる名（迷）論文がある。
この論文で、村田さんは、「駄目な発想」として、「国内合意から始めるという発想」をいの一番に掲げている。そして、「勝つ発想」として「国内では単に情報交換だけしかしない」という発想を掲げている。
そう、これなんですよ。
実際、ぼくたちが、Variation Selectorの提案を行ったのも、IOS/IECのパスではなく、UTCに対してだった。
そして、VSが統合漢字に適応されたのも、アドビの提案がきっかけで、UTCの場においてだった。今でも、IVDはUnicodeのテクニカルスタンダードとしてのみ明言化されていて、UCS本体では、その規格本文で引用されているだけだ。
文字コード標準体系検討委員会の報告書を読み返してみると、そのころのぼくたちの国内のまさにアンシャンレジームに対する悪戦苦闘が蘇ってくる。
というわけで、村田真さんとの付き合いも、随分と長くなったなあ。