一般社団法人 文字情報技術促進協議会
会長
小林 龍生
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文字図形名の追加を提案する。
ああ、やっとスッキリした。
再調査の具体的なやりかたについては、技術的な話も含めて、いずれ。
音訓索引
ちょっと書き込みの間が空いてしまって。
その間に、従来独立行政法人情報処理推進機構が担ってきた文字情報基盤事業資産の当協議会への信託譲渡契約も無事完了し、プレスリリースも出すことが出来た。まあ、煩瑣な手続きの大半は、田丸健三郎さんを初めとする事務局におんぶにだっこだったので、ぼくは余り偉そうなことは言えないが。
まあ、その間も、コロナ蟄居状態は続いているわけで、ぼく的には、相変わらずPythonでちょこちょことプログラムを書いて、過ごしている。ここのところ、集中してやってきたのが、大字源の音訓索引の電子化。最終的には、以前自炊しておいたページイメージへのジャンプを、と考えて作業を始めたのだけれど、意外と厄介でね。いろいろなレベルで問題が次々に出て来て、退屈する暇が無くって。
そもそも、漢字の音訓そのものが、結構厄介な代物なのだ。その位置づけというか。
例えば、JIS X 0213にも音訓情報が記載されているが、附属書6（規定）には、「m)音・訓（参考） 辞書・辞書に見られる代表的な音を片仮名で示し、訓を平仮名で示す。この欄は、参考であって規定の一部ではない。」との記載。だれが、代表的な音・訓を選んだのだろうね。ぼくの記憶では、常用漢字については、国語審議会（当時）が示した音訓表の情報がそのまま転記されていたように思うけれど、どうだったかしらね。
文字情報基盤の文字情報一覧表に記載されている音訓情報も、じつは、よくわからない。基本的には、文字情報基盤事業の前身だった汎用電子情報交換環境整備プログラムの報告書がベースになっていることは間違いないのだけれど。
音訓情報については、どうも気持ちの収まりが付かないので、何かの機会に、文化審議会国語分科会で常用漢字表の改定をとりまとめられた元筑波大学教授で図書館長も務められた林典史さんや、国立国語研究所の高田智和さん、それに、そのころ新字源の編集に携わっていたKADOKAWAの坂倉基さんなんかに、「音訓情報ってどうなのよ」みたいなことを、聞いてみたことがある。答えは、異口同音に「音訓情報はねえ」といった曖昧なもの。ああ、専門家でも音訓情報には難儀しているのだとわかって、変に気持ちが落ち着いた。
今回、大型市販辞書の音訓索引を電子化しようと思い立ったのも、このあたりの曖昧さに、ぼくなりの決着をつけたいと思ったから。大型辞書に記載されている音訓情報は、全部でこれだけです、と断言したかったわけ。
ところがどっこい、ことは、そう簡単なものではありませんでした。
音訓索引の構造
他の辞書も似たり寄ったりだが、大字源の音訓索引も、要素としては、読み情報、対応する漢字のイメージ、その漢字が掲載されているページ数からなっている。一部、検字番号を直接示しているものもあるが、多くは、掲載ページ。これが、電子化の際の、第一のやっかいごと。該当する見出し文字の記述に直接ジャンプすることが出来ない。
漠然とだけれど、ぼくが構想している電子化漢字辞典は、iPadなどのタブレットPC上で閲覧できるものにしたいと思っている。そうなると、辞典の全ページを一画面に表示するのはちょっとキツい。ズームアップを使えばいい、という考えもあるが、使いやすいとは言えないだろう。
そこで、考えているのが、各ページを分割して、カラムごとに表示する、という方法。タブレットの画面を横にすれば、なんとか1段分を可読表示できそうだし、空きスペースを検索窓やナビゲーションボタンに使うこともできそう。
ところが、現在の音訓索引のページ情報からは、対応ページのどの段に該当漢字があるかが分からない。これが第一の問題。この問題の解決は、データの整備がある程度進んで、アプリケーションの構造とUIを考えるまで先送りすることにして、データ整備の作業に入ることにした。
OCR作業の問題
次の、というか、最大の問題が、読み情報とページ情報のテキスト化。というか、電子化とはそういうことだよね。該当漢字のイメージは、画像情報をそのまま切り出せばいいので、多くを考える必要はない（とはいえ、実際には、デジタル画像のゴミがいろいろなところで悪さをしてくれるのだが、それはまた別の話）。
手順としては、1ページ分の画像情報を段ごとに分割し（大字源の音訓索引は10段）、それをさらに1行毎（【】付の大見出しは2行取り）に分割した上で、読みの画像、対応漢字の画像、対応ページの画像に切り分けて、OCRにかければいい。
と思っていたぼくがバカだった。手元のパナソニック製のOCRもPythonから使えるTesseractのOCRも、索引情報には、仮名文字にも漢数字にも、驚くほど無力なのだ。急いで、付け加えておくが、一般の新聞記事や小説などは、それは見事にテキスト情報化してくれるのだが、なぜか、仮名文字だけ、とか、漢数字だけ、とかは苦手なようで、日本語指定しておいても、よけいな漢字や記号に置き換えてしまうことが多すぎるわけ。TwsseractのOCRをカスタマイズすることも考えたけれど、何だかめんどくさそうだし、そもそも、ディープラーニングでトレイニングするためのサンプルデータの準備を考えただけで気が遠くなる。
で、実際には、以前、IRGの新レパートリーとUCSの既存の符号位置に存在する文字との重複をチェックするために作った仮称なんちゃってOCRを流用することにした。
もともとのなんちゃってOCRは、画像として似ている漢字をラフに拾い出してきて、細かなチェックは人力（eye ball check）で行い、という方針で作ったもの。
pythonのnumpyを活用して、画像情報をarrayに置き換え、array間のコサイン近似値を比べる、というだけのもの。とはいえ、これはこれで、地ベタを這うような、IRGのレビュー作業には大いに役立ったが。
今回は、音訓情報でも、平仮名片仮名だけだし、ページ情報に至っては、漢数字10文字だけなので、文字の切り出しさえうまくいけば、ことは簡単なはずだった。
ところが。この、文字の切り出し作業に、おもわぬ伏兵が潜んでいて、大苦戦を強いられることになる。
最初に手を付けたのは、角川書店の「大字源」。1992年2月2月10日初版発行。ぼくの手元には、3月10日の再版と自炊した1993年1月10日の第3版がある。実際の作業に使ったのは、この自炊した第3版。この大字源は、まえがきにもあるように、活版活字で組まれている。というか、かの諸橋大漢和でさえ、ごく初期のものとはいえ、写真写植で制作されたものだし、大字源の印刷もあきらかにオフセットなので、活版活字で組まれていたなんて、考えてもみなかった。
しかし、この《活版活字で組んだ》ところに、思わぬ落とし穴が潜んでいた。すなわち。
大字源の音訓索引は、本文に掲載されている音訓情報を、五十音順に並べて、対応する掲載ページ数を記載する形式になっている。
ぼくがやろうとしたのは、この音訓索引を1項目ずつ（すなわち1行ずつ）切り出し、さらに音訓情報（平仮名もしくは片仮名）とページ数（漢数字）とに切り分けて、それぞれ何らかのOCRにかければいいだろう、とったものだった。
ところがところが、これがとんでもなく面倒なことに相成った。切り出しまでは、まあ、適当な作業で、そこそこうまくいくのだが、以外や以外、OCRがね。試してみたOCRは、Panasonicの読み取り革命Ver.15と、Python3で動く、TessorOCR。それぞれ、一般の日本語文書（特に横書き）のデータの処理に関しては、結構優秀な結果を出してくれる。それが、音訓情報の平仮名や漢字、ページ数の漢数字になると、なぜか全然使い物にならない。よけいな漢字が混じったり、記号類と間違えたり。そもそも一文字一文字の切り出しがうまく処理できないようなのだ。
しかたがないので、市販の（Tessorocrはオープンソースだけれど）OCRを使うのは諦めて、どうせ字母数が限定されているのだからと、先に触れた2次元ヒストグラムのコサイン類似を用いた手製の簡易OCRで処理することにした。
ところがところがところが。何しろ、手製の簡易版なので、文字列からの一文字一文字の切り出しなどという気の利いた機能は持っていない。文字列のままでヒストグラムを取るか、事前に一文字ずつ切り出す作業をしなければならない。この一文字ずつの切り出し、それも漢数字の切り出しに、とんでもなく苦労する仕儀と相成った。
なんと、各段のページ数の漢数字の位置がそろっていないのだ。見た目では分からない。しかし、スキャン情報を子細に調べてみると、微妙に揺れている。というか、最初は、一行ずつ切り分けて、バウンディングボックスでクロップしたら、漢数字って、特に一、二、三で、高さが違うのね。4桁の場合だと、1の桁と1000の桁では、文字列の高さが全然違うの。4桁を切り分ける処理に途方に暮れて、だったら各段の版面の一番下から段全体を対象に追っかけていけば、うまく切り出せるだろうと思ったら、豈図らんや、この段内の版面がそろっていないことが判明した、という次第。だって、活版なんだもの、致し方ないよなあ。
結局、だいたいのところを段ごとに処理し、エラーになった行を、別に取り出して、一、二、三の文字毎の例外処理を施す、という方法に切り換えた。
音訓情報のテキスト化は、、、、、今のところ、ギブアップ。。
新潮社の「日本語漢字辞典」は、絶対に電算組版で処理しているに違いないので、こっちの方を先にやろうっと。
文字情報基盤事業の資産（1）
ようやく、IPAとの信託譲渡契約が締結段階に入った。そろそろ、軸局から手続き終了の知らせた入るころ。
コロナウィルス騒ぎで、自宅にいる時間が少し（以前からそれなりに閑だったけれど）増えたこともあり、ここのところ、IPAから信託譲渡される文字情報基盤事業の成果物（以下、MJ資産）について、主にPythonで簡単なプログラムを書いて、いろいろ調べている。それこそ、時の経つのを忘れるぐらい、面白い。
MJ資産の主軸は、あくまでも、すでに公開されているMJ文字情報一覧表とIPAmj明朝にあることは言うまでもないけれど。
当初からこの事業に係わってきた身としては、一覧表成立に至るまでのさまざまな中間成果物に、魅力とある種の愛着を覚えるわけだ。中でも、市販の大型漢字辞典関係の情報は、多くの好事家にとっても、垂涎物だろうと思う。
MJ事業で対象とした辞書は、以下の5点。
大漢和辞典（大修館書店）
新大字典（講談社）
大字源（角川書店）
日本語漢字辞典（新潮社）
大漢語林（大修館書店）
大漢和辞典は別格としても、日本を代表する大型辞典が網羅されている。
MJ事業で調査した情報は、大きく3つに分類出来る。
なによりも、MJ文字図形名と各辞書の検字番号との対応表。
次に、各辞書の検字番号と掲載ページの対応表。
そして、各辞書に記載されている見出し文字間の関係。
MJ文字図形名と検字番号の対応関係は、一覧表に掲載されている。
見出し文字間の関係は、MJ文字図形とJIS X 0213の縮退マップを開発する際に、大いに役立った。
問題は、検字番号と掲載ページの対応表。
以前、大修館書店の担当者と情報交換を行った際、この対応表は、絶対に公開しないでもらいたい、と強く言われた。この対応表があると、ページイメージベースであれば、電子辞書が簡単に開発出来てしまう。
実際、ぼく自身は、上記の辞書すべてを私費で購入したうえで自炊し、ページごとのPNGファイルに分解してあるので、それこそ、Pythonから簡単に呼び出すことができるようになっている。
辞書系の電子書籍の核心がインデックスにあるということが、自分の体感からも大修館書店担当者の謂からも、よくわかる。
ともあれ、この検字番号とページとの対応表は、死蔵するにはあまりにも惜しい情報だ。何とか、版元の利益を毀損しない形で、世に出すことは出来ないものか。
一方、各辞書を自炊した目的の一つに、各見出し文字の切り出しがあった。こちらの方も、Pythonを使って、いろいろ悪戦苦闘してなしとげたのだけれど、今調べているのは、MJ文字図形との対応関係が取られていない見出し字について。
戸籍法だったか戸籍法施行規則だったかに、戸籍に記載してよい文字の条件に、「市販の辞書に記載されていること」という条項があったように思う。だとすると、MJ文字と対応関係の取れない見出し文字が、将来、戸籍統一文字に追加され、MJ文字一覧表やIPAmj明朝でも対応を迫られることがないとは言えない。
実際、最近も《ささ》という字が、日本語漢字辞典に掲載されていることを根拠に、戸籍統一文字に追加されたという事態もあったことだし。
以下、辞書関係のデータの中身を、すこしずつ見ていこう。
まずは、それぞれの辞書の総文字数。ぼくは、OED(Oxford English Dictionary)を気取って、それぞれの辞書に3文字のアブリビエーションを充てて使っている。
大字源:DGJ
大漢語林:DKR
大漢和:DKW
日本語漢字辞典:NKJ
新大字典:SDJ
DJG:12300
DKR:13938
DKW:51110
NKJ:15375
SDJ:21094
対応するMJMJ文字図形名を持たない見出し字の数は、下記の通り。
戸籍統一文字に追加するための要件の一つが市販の漢字辞典に記載されていること、だとすると、これらの文字は、潜在的に将来戸籍統一文字に加えられる可能性がある、ということになる。とは言え、字体弁別の尺度は、これまた辞書によっても異なる。辞書に別見出しとして掲げられているからといって、無条件に（戸籍統一文字の尺度で）別字体だとは断言出来まい。このあたりは、今後の漢字行政上の大きな論点になりそうな。
DJG:41
DKR:41
DKW:1610
NKJ:620
SDJ:491