一般社団法人 文字情報技術促進協議会
会長
小林 龍生
大漢和辞典の関連字
しばらく間が空いてしまって。事務局長の田丸さんから、会長ブログを毎月更新するよう厳命を受け、やっかいなことに、副会長の村田真さんがその場にいたものだから。。。
言い訳じみたことになるが、ここのところ、大漢和辞典の関連字情報の整理に取り組んでいる。かなりやっかいな大仕事だ。とは言え、今やっておかなければ、という危機感というか使命感もある。
こんな気持ちになったのには、それなりの経緯がある。
ことは、ぼくが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本体では、その規格本文で引用されているだけだ。
文字コード標準体系検討委員会の報告書を読み返してみると、そのころのぼくたちの国内のまさにアンシャンレジームに対する悪戦苦闘が蘇ってくる。
というわけで、村田真さんとの付き合いも、随分と長くなったなあ。
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年ごろから、「ユニコード戦記」で書き漏ら したことどもを中心に、時を遡っていこう。
《事後的な注》
汎用電子プロジェクトには、「戦記」に登場する高田さんの他にも、今でも協議会かかわっている人たちがいる。副会長の山本さん (アドビ)が文字グリフ作業委員会の委員長として、加除の野島さん(当時は富 士通)が副委員長として、係わっていた。まあ、狭い業界と言えば狭い業界なのだけれど、往時の事情を知る専門家が、身近にいることも、この協議会の大きな強みでもあるね。ぼくの（老化現象による）記憶違いも正してもらえるし。