一般社団法人 文字情報技術促進協議会
会長
小林 龍生
ユニコードとの許諾契約
大漢和辞典を巡る特別講演
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本体では、その規格本文で引用されているだけだ。
文字コード標準体系検討委員会の報告書を読み返してみると、そのころのぼくたちの国内のまさにアンシャンレジームに対する悪戦苦闘が蘇ってくる。
というわけで、村田真さんとの付き合いも、随分と長くなったなあ。
MJ戦記とほにゃらら戦記（書き始め）
先般(2021年7月9日)、協議会のメンバー限定で、文字情報基盤の信託譲渡、なかでも、MJ文字情報一覧表とMJ明朝についてのセミナーが開催された。 講師は、IPAの元理事で、今は開志専門職大学で教鞭を執っておられる田代秀一さ んと、当協議会の事務局長田丸健三郎さん。協議会の理事でもあるイワタの水野 社長が、コーディネートの労をとってくださった。ぼくは最初に、会長とし て短い挨拶をしたのだが、話をしながら万感こみ上げてきた。いわば、「ああ、 ぼくが手塩にかけて育ててきた文字情報基盤の成果物が、また、ぼくの手元に戻 ってきた」という感慨。この感慨は、田代さんや田丸さんの話の間も、ずっと続 いていた。お二人の話の話の端々から、文字情報基盤を開発していたころのさま ざまな思い出が、ものすごくリアルにフラッシュバックしてくる。ほとんどが、 結構大変だったけれど、今となってはいい思い出、の類。
田丸事務局長からは、このブログに一回は新し記事を投稿しろ、と厳命されている。「やる仕事があるのが、最大の老化防止策ですよ」と無茶苦茶なことも 言う。まあ、その謂にも一理ある。そんなわけで、上梓してからもう10年以上経 つ「ユニコード戦記」の後日譚を、時間軸では上梓前でも戦記に触れられていな いこと共も含めて、少しずつ振り返っていきたいと思う。ボケ防止のためにもね。
「ユニコード戦記」の索引には、「汎用電子情報交換環境整備プログラム」という言葉は、1個所しか出てこない。233ページ。ちょっと長くなるけれ ど、話のとば口として、引用しておこう。
汎用電子情報交換環境整備プログラムとIVS
「ユニコード戦記」が発行されたのが2011年6月10日。畏友ヒデキが急逝したのが、2010年4月7日。ぼくにとっては、この汎用電子コレクション のIVD登録が、「ユニコード戦記」を擱筆する上で、とても大きな区切りとなっ た。次回は、この2010年から2011年ごろから、「ユニコード戦記」で書き漏ら したことどもを中心に、時を遡っていこう。
《事後的な注》
汎用電子プロジェクトには、「戦記」に登場する高田さんの他にも、今でも協議会かかわっている人たちがいる。副会長の山本さん (アドビ)が文字グリフ作業委員会の委員長として、加除の野島さん(当時は富 士通)が副委員長として、係わっていた。まあ、狭い業界と言えば狭い業界なのだけれど、往時の事情を知る専門家が、身近にいることも、この協議会の大きな強みでもあるね。ぼくの（老化現象による）記憶違いも正してもらえるし。
ユニコードでIVSをめぐる議論が行われていたさなか、日本でも外字問題に決着をつけるべく大規模な プロジェクトが進行していた。汎用電子情報交換環境整備プログラム。このプログラムは、もともとは情報処理学会が主催していた文字コード委員会での 議論を踏まえて、佐藤さんとぼくが戸籍実務や住民基本台帳実務で用いられてい る漢字の悉皆調査が必要なことを経済産業省に訴えたことが契機となったものだ った。ぼくたちの働きかけが奏功して、2002年から情報処理学会、日本規格協 会、国立国語研究所が共同受託する形で、この汎用電子情報交換環境整備プログ ラム(以下汎用電子プログラムと略す)が開始された。佐藤さんとぼくは、問題提起をした関係もあって当初は積極的にこのプログラムの推進に協力し ていたが、プログラムの具体的な運営方法についての他のステークホルダーたちとの考え方のちがいから、実際のプログラムには参加することにはならなかっ た。プログラムは予想以上に、否、佐藤さんやぼくが予想していたとおり、2008 年になって、当初予定された期間が過ぎても、目に見える形での成果が見えてこない。そのために、さらにフォローアップのための予算措置が講じられた。ぼく は、経済産業省の担当者からプログラムの成果を標準化プロセスにのせるための 小委員会に参加することを要請された。汎用電子プログラムは当初、総務省 が所轄する住民基本台帳ネットワークに用いられる文字集合(住基ネット統一文 字)と、法務省が所轄する戸籍に使用される可能性のある文字集合(戸籍統一文 字)を整理統合するところから始まり、のちに登記簿謄本に実際に使われている 文字集合(登記統一文字)が加えられた。作業の多くは、当初は笹原宏之さん (プロジェクト途上で早稲田大学に異動)、のちにそれを引き継ぐ形で高田智和さんという国立国語研究所の気鋭の研究者が中心となって基礎調査研究を行い、それの基づいて具体的な平成明朝体のグリフを設計する作業が並行して行われた。ぼくが参画した標準化作業委員会は、それらの成果を可能な限り国際標準に反映させるとい う役割を持っていた。この一連の作業の結果、汎用電子プログラムの成果 の一部は、日本から統合漢字への採録が提案され、拡張CおよびDの一部として標準化された。また、従来のUCSの統合規則では統合の対象となる字形につ いて当初は互換漢字領域への提案として準備が進められたが、IRGやWG2におけるUSやUTCからの強い勧めもあり、最終的には互換漢字領域への提案を取り下げて、ユニコードに対してIVD登録することになった。そして、2010年12月14日、 正式に登録が完了した。IVSについて、なによりも特筆すべきことは、 2009年になってマイクロソフトがWindows7に、アップルコンピュータがMac OS Xの最新版に、IVSの表示機能を盛り込んだことだ。アドビのAcrobat9への実装やマイクロソフトのWindows7への実装、Msc OS Xへの実装が市場に投入されたことで、IVSはやっと実用的な普及段階に突入した。ヒデキとぼくがVSの アイディアをUTCに提案してから、すでに12年の年月が流れていた。(p.233~)
拙著『ユニコード戦記』（東京電機大学出版局、2011年）
「ユニコード戦記」が発行されたのが2011年6月10日。畏友ヒデキが急逝したのが、2010年4月7日。ぼくにとっては、この汎用電子コレクション のIVD登録が、「ユニコード戦記」を擱筆する上で、とても大きな区切りとなっ た。次回は、この2010年から2011年ごろから、「ユニコード戦記」で書き漏ら したことどもを中心に、時を遡っていこう。
《事後的な注》
汎用電子プロジェクトには、「戦記」に登場する高田さんの他にも、今でも協議会かかわっている人たちがいる。副会長の山本さん (アドビ)が文字グリフ作業委員会の委員長として、加除の野島さん(当時は富 士通)が副委員長として、係わっていた。まあ、狭い業界と言えば狭い業界なのだけれど、往時の事情を知る専門家が、身近にいることも、この協議会の大きな強みでもあるね。ぼくの（老化現象による）記憶違いも正してもらえるし。
MJ文字図形名とUCS符号位置との対応
久しく間が空いてしまいましたが。まあ、コロナ禍で、世間全般が半ば開店休業状態でもあるし。
とはいえ、ぼくはぼくなりに、コロナ蟄居状態をそれなりに楽しんでいる次第で。
その一つが、IPAから信託譲渡を受けた文字情報基盤の成果物に対する、Henry Chenさんからのコメント。文字情報一覧表のUCS符号位置との対応関係がおかしいのではないか、というコメントをいただいた。Henry Chenさんは、IRGで活発に活動している中国の専門家。ぼくは、最近のIRGには参加していないので、多分、直接の面識はないが、名前はよく耳にしている。Chenさんも文字情報基盤に注目してくれているのだ、と思うと悪い気はしない。押っ取り刀で、コメント内容を調べてみた。
問い合わせは二つ。いずれも、MJ文字図形名とUCS符号位置との対応関係に関するもの。
一つが、MJ054422が、現在は、U+2995Cになっているのだが、正しくはU+29946ではないか、というもの。
もう一つが、MJ046645が、現在は、U+26D1Fになってるのだが、正しくはU+26C5Dではないか、というもの。
| MJ文字図形名 | MJグリフイメージ | UCS（現） | UCS（Henry提案） |
| MJ054422 |  |  |  |
| MJ046645 |  |  |  |
調べてみると、どちらも戸籍統一文字に含まれており、大漢和辞典にも収載されている。この際だから、大漢和辞典の該当個所もクロップしておこう。
ご覧いただけば、一目瞭然だが、分はChenさんの方にある。
とはいえ、正すは正すにせよ、どうして、そして、いつどこで、このような誤りが紛れ込んだのかが分からないと、いかにも落ち着きが悪い。何よりも、2個見つかったということは、もっとある可能性が高い。これから、文字情報基盤事業成果物が、自治体などの実務システムに使われることがますます増えていくことが想定されるが、実装が増加する前に、正すべきは正しておきたい。
こうして、コロナ蟄居の間の、楽しい暇つぶしの調査が始まった。
調査の大筋は、二つに分かれる。
一つは、MJ文字図形とCJK符号位置の、それぞれどの部分が怪しいかを見極めること。
もう一つは、怪しい部分から、問題になりそうなMJ文字図形名とUCS符号位置の組を洗い出すこと。
MJの文字情報一覧表には、5万字近くの文字が収載されている。また、CJKの側は、今では、9万字ほどもある。
これらを、総当たりで調べるのは、いくら何でも気が遠くなる。何とか絞り込めないだろうか。
最初に頭に浮かんだのが、拡張Bが怪しい、ということだった。
ご存じの方も多いと思うが、UCSの漢字パートは、大きく、統合漢字(Unified Ideographs)と互換漢字(Compatibility Ideographs)に分けられる。さらに、それらに、拡張パートや補遺やらが加わって、今では、9万字余りの漢字に符号位置が与えられている。その中でも、拡張Bは規模も大きく、康煕字典の全ての文字を収載することが一つの大目標になっていたこともあって、一般にURO(Unified Repertoire and Ordering)と呼ばれている初版時からあるパートに次いで重要なパートと言えよう。しかし、今から振り返ると、規模が大きいせいもあって、どうも品質的にはイマイチではないかなあ、という疑念がぬぐいきれない。
それはさておき、康煕字典とともに、大漢和辞典は、規模の点でも信頼性の点でも、中国や台湾も含めた漢字圏内では非常に高く評価されている。余談ではあるが、台湾には大漢和辞典の海賊版が売られており、紀田順一郎さんなどは、「台湾の海賊版の方が紙質が悪い分、軽くて使いやすいぐらいですよ」とおっしゃっていたことを記憶している。
閑話休題。当然ながら、康煕字典は大漢和辞典編纂の折の基本典拠の一つだったわけで、収録字数もほぼ同規模になっている。
そして、日本の行政における人名用漢字使用（特に姓）の拠り所となっている戸籍統一文字は、法令に則ったこともあって、大漢和辞典を初めとする市販の大規模漢字辞典の見出し字を原則的にはすべて含んでいる。
というわけで、拡張Bを含むUCSが発行されたのが2001年で、汎用電子情報交換環境整備プログラムが開始されたのが2002年なので、汎用電子〜が開始された時点で、拡張Bはすでに国際規格として成立していたことになる。
汎用電子〜のプロジェクトメンバーが、戸籍統一文字に対応するUCSの符号位置を調査しようと試みたとき、その対象の多くが拡張Bに含まれていたことは、このような経緯から、ほぼ確実なことだった。ぼくが、「拡張Bが怪しい」と思ったのは、このような背景があったからに他ならない。（ま、急いで付け加えておくと、後から冷静に考えてみると、という条件付きではあるのだけれど。）
この辺りの事情を、汎用電子情報交換環境整備プログラムのころから一貫してこのプロジェクトの係わってこられた、国立国語研究所の高田智和さんに、メールで問い合わせてみた。何度かのやりとりがあったのだけれど、経緯を簡単にまとめると、だいたい以下のようなことだったようだ。
汎用電子情報交換環境整備プログラムから文字情報基盤整備事業に至る一連の活動は、戸籍統一文字と住基ネット文字という成立時期も策定方法も全く異なる二つの独立した文字集合を、UCSという国際的に認知された公的規格をピボットとして関連づける営為だった。
そこで、UCSとともに重要な役割を果たしたのが、大漢和辞典という民間で編纂された世界的にも評価が高かった漢字辞典だった。（※IRGで同文書局版の康煕字典がいわばバイブルとして用いられたこととを考え合わせると何だか興味深いなあ）
汎用電子情報交換環境整備プログラムの始めのころは、JIS X 0221解説のUCS（拡張Aまで）大漢和対応表が、ピボットとして用いられた。
※このJIS X 0221は、2001年に発行されたもので、ははは、ぼくも原案作成委員会の一員に名を連ねている。問題の対応表は、解説付表1というもの。
その後、汎用電子情報交換環境整備プログラムでは、UCS符号位置の範囲を拡張Bにまで拡張して、調査を行った。
文字情報基盤整備事業では、この汎用電子情報交換環境整備プログラム成果（拡張BまでのUCSとのマッピング）を前提として、UCSとのマッピングがないもののUCSへの追加提案がなされた。さらに、UCSで統合されるものについては、IVDへの登録がなされた。
そういうことか。この汎用電子情報交換環境整備プログラムにおける対象文字（戸籍統一文字と住基ネット文字の和集合）とUCS拡張B符号位置との対応関係調査でバグが紛れ込んだのだ。他の部分については、曲がりなりにもISO/IECやJISなどの公的規格に拠り所がある。
急いで付け加えておくが、その後の調査で、さらに20個所弱の疑問点が浮かび上がっているけれど、それでも対象となるペアの0.1%以下なのだ。関係者の間では常識となっているが、UCSそのものにも（特に拡張B）まだバグが残っていて、時々思い出したようにエラーレポートが報告される。ある程度以上の規模の文字集合間の対応関係にバグやバグとは言えないまでの見解の相違が含まれるのは、不可避なことなのだ。
どうも、問題は、現象面としてのバグにあるのではなく、文字情報一覧表に記載されているMJ文字図形名とUCS符号位置との対応関係の一部（というか半数以上）に、UCSやJISなどの公的規格に拠り所を持たないものがある、という点にあったのだ。
経緯を整理したおかげで、俄然視野が拓けた。問題の要は、UCSのJソースなのだ。と言っても、一般の方々には何のことだかチンプンカンプンに違いない。UCSに記載されている典拠情報（ぼくらの中ではCJKソースと言い習わしている。日本提案のものは、Jソース）について、ちょっと説明しておこう。
UCSの規格票をご覧になったことのある方々は、お気づきだと思うけれど。規格票のCJKパートには、例示字形の下に、何やら訳の分からないアルファベットと数字の組合せが記されている。先に挙げた、Henry Chenさんのコメントの例だと。
UCS2003とかGXX-1442.30とかTF-667Dとか。
これらは、関係者の中ではCJKソースといか典拠情報とか呼ばれていて、それぞれの国や地域からの提案の拠り所となる規格を示している。
もちろん、日本から提案した物には、一番最初がJで始まるおまじないが付いている。
へへへ。ぼくの名前の「龍」の例だと、左から4番目のJ0-4E36というのが、日本の原規格で、最初のUROが制定されたころから入っているJIS X -208起源ということが分かる。文字情報基盤整備事業の過程で日本から提案されたものもある。
これって、一部の業界人（文字コード屋）の間では有名な文字なんだけれど、これだけで「えだなし」と読む。「木」から枝をはらった文字だから「えだなし」。
こうして見てくると、文字情報一覧表に記載されているUCS符号位置の一定程度（調べてきたら2万字強）は、UCSの側に、MJを含む日本の規格（JIS規格だけではなく、ARIBなどの業界規格も含む）の情報が記載されていることが分かるだろう。
文字情報基盤の文字情報一覧表に記載されたMJ文字図形名とUCS符号位置との対応関係が、UCSの側に拠り所を持っているとは、すなわち、UCS符号表の該当位置に、Jソース（MJ文字図形名やJISだけではなく業界標準も含む）が記載されている、ということに他ならない。今回のChenさんからのコメントに即して考えてみよう。
Chenさんコメントの分は、誰がどう見ても、Chenさんの方にある。これって、明確なバグだから直さなくっちゃ、と思う。
しかし、文字情報一覧表も、MJ明朝も、すでに様々なところで実装されて用いられている。該当する文字がどこかで使われている可能性はゼロではない。とすると、例の後方互換性の問題が出てくる。あるフォントの特定の符号位置の表示字形を恣意的に変更すると、どこでどのような不具合が生じるか、ちょっと予測がつかない、というか、どこまで行っても予測不可能な不具合が生じる可能性が残る。この厄介な問題のおかげで、UCSでは、一度決めた文字名や例示字形は原則的に変更を行わない。やむを得ず変更する場合も、可能な限り既存の情報を残した上で、新しい符号位置や例示字形を追加し、変更情報は規格本文に明記する。
この伝で行くと、文字情報一覧表の情報は、更新履歴を明記した上で変更し、MJ明朝は、既存のUCS符号位置から該当MJ文字図形への対応を残したまま、新たな（正しい）UCS符号位置から該当MJ文字図形への対応を追加することになるだろう。
しかし、というか、それでも、というか。
オープンな環境で使われることが前提となっている文字情報一覧表やMJ明朝フォントの情報を、発足間もない弱小一般社団法人が、そうやすやすと変更してしまって良いものだろうか。
どうやら、当面の結論にたどり着いたようだ。
文字情報技術促進協議会としてなすべきこと。
- MJ文字図形のうち、対応するUCS符号位置にJソースの記載がないものについて、再調査して、さらなるバグの低減を図る
- その上で、しかるべきルートで、UCSへの該当MJ文字図形名の追加を提案する。
ああ、やっとスッキリした。
再調査の具体的なやりかたについては、技術的な話も含めて、いずれ。