一般社団法人 文字情報技術促進協議会
会長
小林 龍生
雇い止めその後：阿南さんと加治佐さん
「ユニコード戦記」は、2010年5月の「樋浦秀樹さんを送る会」の描写で終わっている。ヒデキがなくなったのが、2010年4月7日。晩年のというか急逝する直前のヒデキは、必ずしも順風満帆というわけではなかった。スコット・マクネリーにあこがれて、富士通を退社して飛び込んだサン・マイクロシステムズが、ヒデキが力を入れていたオープンソースの世界から退場し、そのタイミングで浮川夫妻に招かれて、ジャストシステムに入社していた。しかし、ヒデキが技術面での指揮を執っていたxfyは、営業面での欧米への無謀とも言える積極展開があだとなって、ジャストシステムの経営基盤を揺るがす状況になっていた。浮川夫妻は、最終的に経営権を委譲し、我が子のように育ててきたジャストシステムと社員をキーエンスに委ねる決断を下した。キーエンスへの株式譲渡が2009年の4月、取締役退任と新会社メタモジ設立が2009年10月。それに先立つ2009年9月、ぼくも、ジャストシステム退社後も続いていた業務委託契約（デジタル文化研究所所長職と国際標準化活動）の打ち切りを通告された。この前後の「ユニコード戦記」の記述
2009年9月、ジャストシステムからの契約打ち切りの通告。
ジャストシステムからの契約打ち切りの通告を受け、ぼくは、インディペンデントになってからも続けていたジャストシステムデジタル文化研究所の所長を退任した。デジ研という組織（もともと、メンバーは、ぼくとアシスタントの斯波綾子さんだけだったけれど）も廃止された。
2010年10月、浮川夫妻、ジャストシステム取締役を退任。
浮川夫妻がジャストシステム取締役を退任。同時に、メタモジ社を設立。
ジャストシステムからの禄を断たれ、路頭に迷いかけたぼくに、救いの手をさしのべてくれたのは、意外にも「一太郎」やATOKで、OOXMLやODFで敵どうしとして戦ってきたマイクロソフトCTO（当時）の加治佐俊一さんだった。
「何か日本語の将来に役立つことをやりましょう」
これだけの条件で、ぼくとコンサルタント契約を結んでくれた。あとは、情報処理推進機構（IPA）の文字情報基盤事業の手伝いで糊口をしのぐことができた。
（「EPUB戦記」p170、一部改）
「EPUB戦記」でのぼくの物語は、事実上、ここで終わっている。あとは、JLreqの第2版の発行と、紙版の「日本語組版処理の要件」の発行、W3CにおけるRichard Ishidaによる様々なreqシリーズへの展開などが、簡単に触れられているだけだ。
一方、「ユニコード戦記」の方は、といえば、これは、2010年5月28日に西麻布のイタリアン・レストラン《エスペリア》で開かれた「樋浦秀樹さんを送る会」の記述が最後。
あとがきで触れた台北の鼎泰豊での村田真や木田泰夫さんとのエピソードが、2010年10 月7日。
こうして見てくると、ぼくの個人史の中で、2010年は、随分と大きな区切りの年だった。
大きく区切ると、
1976年〜1989年：小学館編集者
1989年〜2000年：ジャストシステム社員
2000年〜2010年：インディペンデント（ジャストシステムデジタル文化研究所所長）
2010年〜：インディペンデント（マイクロソフトコンサルタントとCITPCへの係わり）
といったことかしらね。こうして列挙してみると、何のことはない、今となっては2010年以降のCITPCとの係わりが一番長くなってしまった。
2025年12月のCITPC結成15周年に向けて、2010年を起点として、今に至るまでぼくの活動の中軸となってきた文字情報技術促進協議会（前身のIVS技術促進協議会も含む）と、文字情報基盤整備事業について、あくまでもぼく個人の視点からではあるけれど、記録を留めておこう。おそらく、技術的な内容よりも、係わりのあった人々との思い出が中心になると思うけれど。
加治佐さんとの面談
ジャストシステムから雇い止めを宣告され、ぼくは、マジで路頭に迷いそうになった。2010年といえば、ぼくはまだ50代の最後。普通に会社員をやっていれば、定年まで何年かを残す年代だ。ジャストシステムを退社して、有限会社スコレックスを設立し、インディペンデントのITコンサルタントを標榜してはいたが、じつのところ、ジャストシステムとのコンサルタント契約、それも実態は国際標準化活動に対するパトロネージュが主な生活の糧だった。他にもスポットでの調査の仕事が無いわけではなかったが、生活を支えるにはほど遠いものだった。救いと言えば、3人の子供たちがすでに独立してそれぞれ自分たちの家庭を持っていたことだろうか。
さて、これからの生活をどうしようか、と思い悩んでいたとき、意外な人が声を掛けてくれた。マイクロソフトの阿南さん。
阿南康宏さん
阿南さんとは、JSC2での活動を通して、旧知の仲だった。
今調べてみると、JIS X 0213:2000の符号化文字集合調査研究委員会第2分科会（WG2）の委員名簿に、マイクロソフトプロダクトディベロップメントリミテッド所属として、その名がある。それも、「（平成10年11月から）」という付記とともに。それまでは、「松沢高志さん（平成9年4月まで）」の名があり、JIS X 0208:1997の委員名簿にも、松沢さんの名前があるので、このころ、松沢さんから引き継ぐ形で、符号化文字集合の世界に入ってきたのではないかと思われる。
あれれ、「ユニコード戦記」の人名索引には、阿南さんの名前がない。これ、浦山さん（当時東京電機大学出版局での編集担当）のミスだな、きっと。でも、第6章 JIS X 0213:2004 1 表外漢字字体表とJIS喚起規格の整合の節、符号化文字集合（JCS）調査研究委員会第1回委員会の委員会構成のところに、阿南さんの名前もある。この会合が開かれたのは、2001年5月。
ともあれ、このころには、阿南さんは、外資系ITベンダーの一方の雄であるマイクロソフトにあって、開発陣の最前線で日本語関連の符号化文字集合標準化活動に参画してきた。
ヒデキにとって、阿南さんはちょっと不思議な存在だった。
そもそも、ヒデキからすると、マイクロソフトはあらゆる面で不倶戴天の敵。彼が属していたサンマイクロのUnix路線に対するWindows、Javaに対するC++、そして、後のODFとOOXML等々。ところが、IRGのミーティングでは、ヒデキはUS代表団の一員であるにもかかわらず、なぜか昼食の折には、日本代表団のメンバーにすり寄ってきて、一緒に日本料理店やラーメン屋に出向いたりする。そして、阿南さんとも親しく雑談している。
ヒデキは、ワインに凝っていた。それも、半端なく。自宅にもワインセラーがあったが、置ききれずに、空調の整ったサンマイクロのサーバールームに、何本ものワインをこっそり保管していた。あるとき、ヒデキが知らない間に、サーバールームの引っ越しが挙行され、持ち主不明のまま貴重なワインが没収されてしまう、という悲劇が起こったり。
ぼくも、ヒデキに洗脳されて、ある時期、結構ワイン沼にはまった。
二人で、何度もナパバレーに行った。ナパの多くのワイナリーでプレミアムワインのテイスティングも経験した。そのうち、阿南さんも、そんなナパツアーに参加するようになった。運転はもっぱら阿南さん。二人で、ワインが6本入るおそろいのトートバッグを買い込み、会議でベイエリアに行くたびに、ワインを買い込んだりした。仕事の関係で阿南さんが参加できないときは、バッグを借りていって、都合2つのバッグに12本もの（実はそれ以上）ワインを詰め込んで帰ってきた。阿南さんには、バッグを借りたお礼に、お気に入りのワインを1本進呈した。
ヒデキが日本に来た折には、そんなワインの何本かを持ち込んで、ヒデキが定宿にしていたお茶の水のホテル近くのイタリアンの店で、気の置けない仲間たちと盛り上がったものだった。その場にも、阿南さんは、いた。
そんな阿南さんが、ジャストシステムから雇い止めを喰らったぼくに、メールをくれた。
「一度、MSのCTO、加治佐とお会いになりませんか」
加治佐さん
加治佐さんは、マイクロソフトジャパンのCTOとして、その勇名はとどろいていた。浮川夫妻の口からも度々、その名前が語られていた。ぼくがジャストシステムに入社したころで言えば、東芝の溝口氏やソフトバンクの孫氏など、当時のパソコン業界を先頭に立って引っ張っていたストラテジストの一人、といった印象だった。いわば、雲の上の人。加治佐さんご本人が、ShiftJISそのものをデザインしたことを知ったのは、知遇を得て、親しく交わるようになってからのこと。
その加治佐さんが、自ら乗り込んできたのが、国際標準化活動の中での、ODFとOOXMLの覇権争い。舞台は、IOS/IEC JTC1/SC34。委細は、ぼくの理解と記憶の彼方だが、雑駁に言えば、ヒデキや当時IBMの木戸彰夫さんらが主導していたオープンソースグループのODF対マイクロソフトグループのOOXML。グローバルなデジタル通信ネットワークの世界では、OSIのモデルを押さえて、TCP/IPが覇権を取った。文字コードの世界では、UCSとユニコードが覇権を取った。そして、構造化文書の世界でのHTML。こうした流れの中で、ワードプロセッサーやスプレッドシートなどのビジネスドキュメントの公的なフォーマット規格をどうするか。各社が次の時代のビジネスモデルを構築していく上でも、まさに雌雄を決する大きな戦いだった。
ヒデキは、サンマイクロの大看板を背負って、陣頭に立って戦っていた。そんな戦場において、JTC1における日本のナショナルボディである情報規格調査会がどちらの側に付くか、それが問題だった。日本マイクロソフトは、加治佐さんの下に、国際標準化活動の世界ではまさに百戦錬磨の村田真を迎えて、いわば柔と剛の絶妙なコンビネーションで挑んできた。
傍から見ていても、まさに血を血で洗うような激戦が繰り広げられた。
結果は。
短期的には、双方の痛み分け。ODFもOOXMLもISO/IECの正規の国際規格として発行された。
中長期的には、OOXMLの一人勝ち。ヒデキは、サンマイクロを去り、サンマイクロそのものも消滅した。その後、ヒデキはジャストシステムに移り、xfyによる世界制覇という浮川夫妻の見果てぬ夢とともに果てることになる。
ユニコード戦記の人名索引には、加治佐さんの名前もある。該当個所は、こんな感じ。
そして、ヒデキは日本マイクロソフトの最高技術責任者の加治佐俊一さんとも食事をした。加治佐さんがマイクロソフトとしてIVS技術を目本で強力に推進する決意を話すと、ヒデキはとてもうれしそうだった。 「今なら、マイクロソフトといっしょに仕事ができそうですね」このテーブルが、今まで何かにつけて対峙しつづけてきたヒデキの、マイクロソフトとの和解の場となった。
(「ユニコード戦記」p.240)
今、ネットで調べてみると、ODFの制定は、2006年5月、OOXMLの制定は、2008年11月。
ヒデキの最後の来日は、2010年の2月だった。ぼく自身、記憶は曖昧なのだが、この時点で加治佐さんとぼくとは、全く知らぬ仲、というわけではなかったようだ。
ともあれ、ぼくがジャストシステムから雇い止めの宣告を受けたことを知った阿南さんが、繋いでくれて、ぼくは加治佐さんのオフィス近くの喫茶店で、加治佐さんと話をした。
委細は覚えていない。「EPUB戦記」の記述によると。
ジャストシステムからの禄を断たれ、路頭に迷いかけたぼくに、救いの手をさしのべてくれたのは、意外にも一太郎やAＴOＫで、OOＸMLやODＦで敵どうしとして戦ってきたマイクロソフトCTOだった加治佐俊一さんだった。 何か目本語の将来に役立っことをやりましょう」これだけの条件で、ほくとコンサルタント契約を結んでくれた。あとは、情報処理推進機構(IPAの文字情報基盤事業の手伝いで糊口をしのぐことができた。（P170）
加治佐さんは、そのころ、米国本社での最前線の実装部隊を離れて、日本に召喚されていた田丸健三郎さんに、IVSとIVDの日本における何らかの普及活動を、ぼくとともに企画立案することを指示してくれた。こうして、田丸さんとのいわば二人三脚での活動が始まった。
一方の阿南さん。マイクロソフトジャパンの中で、着実にキャリアアップしていたのだと思う。
あるとき、突然
「もう、部下たちのベビーシッティングには飽き飽きしたんですよね」
と、軽やかに宣言して、マイクロソフトを離れ、それまで着実に積み上げていた中国語のスキルをさらに高め、日中間のIT分野での橋渡しに自分自身のビジネスチャンスを拓くべく、勇躍中国に渡っていった。
ぼくの手元には、2012年4月に発行された「日本語組版処理の要件」（東京電機大学出版局）を記念して村田真がエディターたちのために作ってくれたプレートの、阿南さんの分がまだ残っている。
こうして、ぼくは、ヒデキから委ねられた文字情報技術の普及促進を目指す新しい戦場に赴くこととなった。
文字情報技術の30年
謹賀新年
まあ、齢を重ねてくると、新年といっても、これといった新しい感慨はたいして湧いてこない。とはいえ、こと本協議会に限っていえば、今年2025年は、母体となった任意団体IVS技術促進協議会の設立から15年という特別な年になる。先のブログにも書いたけれど、IVS技術促進協議会の設立総会が開催されたのは、2010年12月6日。1年近く先のことにはなるけれど、事務局長の田丸さんを中心に、記念イベントの計画が動き始めている。
協議会が設立された2010年は、ぼくの個人史的にも、わりと際だった年なのだけれど、日本の文字情報技術史全体を見ても、なんというか、箱根駅伝の折り返し点といったところに位置している。
協議会副会長の村田真が日本人としては唯一、グローバルなゼロックスグループの代表として、W3Cのワーキンググループの一員として策定に主体的に係わったXMLの勧告が出されたのが、1998年2月。
協議会の主要メンバーでもあるマイクロソフトとアドビが手を結んで、デジタルフォントのデファクトスタンダードとなっているオープンタイプの最初の版を発表したのが1997年4月。
そして、ぼくの個人史の中でも重要な位置をしめるUCSの第1版の発行が1993年5月。ちなみに、ぼく自身が、当時ジャストシステム専務だった浮川初子さんに、いわば背中を蹴っ飛ばされて参加した最初のユニコード技術委員会が、1995年12月。
このように見てくると、文字を主体とする情報通信の世界がまさに国際技術標準の策定を基盤としてグローバルな発展を始めたのが、ほぼ30年前といえるだろう。
そんなわけで、《文字情報技術の30年》といったシンポジウムみたいなものも、協議会として開催できればいいなあ。
CITPCの15年
先般（2024年9月4日（水））に、コロナ禍などでしばらく途絶えていたCITPC恒例の暑気払いの会が開催された。久々に楽しい歓談はビジネス展開の話も含めて、つきることがなかった。そのおり、事務局をお願いしているエッジプラスの木村社長から、「CITPCも例年でもう15周年なんですよ」と聞かされた。そうか、もう15年か。総会の折の特別講演になるか、別個のセミナーになるかは措くとして、2025年には、何か記念になるイベントをやりたいと思っている。いい機会なので、15周年を目指して、CITPCの15年を振り返っておくのも悪くないだろう。とともに、前からいつかは書きたいと思っていた「ユニコード戦記」と「EPUB戦記」の続編への助走にもしたいし。
一念発起して、事務局の佐藤さんの手を煩わせて、昔の資料をまとめて送っていただいた。以下、その資料を掘り返しつつの、雑感。
2010年12月6日「IVS技術促進協議会」設立総会
一般財団法人文字情報技術促進協議会の前身となる「IVS技術促進協議会」の設立総会が開催された。同日、ニュースリリースも公開された。協議会の設立趣意書。
IVS技術促進協議会設立趣意書
パソコンや各種デジタルデバイス、インターネット、オンラインサービスの普及に伴い、電子出版に見られるように情報の発信者である作者と受信者である読者との距離がこれまでになく近くなっています。しかし、文字には地域、用途によって様々な字体が存在し、現在の多くのコンピューターソフトウェアではこれらを取り扱う事が出来ず、同じ文字を作者と読者が共有する事を保証する事が出来ません。
例えば、住民基本台帳、戸籍には、一般に入力、表示が出来ない字体が多く含まれ、これらの文字はデジタルデータとして広く交換出来ないのが実際です。
「書き手と読み手が同一の文字を見ている」
IVS (Ideographic Variation Sequence)は、これまで困難であった文字入力から、メール・記録媒体による情報の伝送、受信、そして情報の表示・印刷において、常に同じ文字（字体）であることを保証できる仕組みです。また、これにより歴史的・文化的資産の電子書籍化や、電子政府システムを促進するために不可欠な人名、地名の正確な表記を、国際基準に則り、クラウドコンピューティング時代に欠くことのできない相互運用性を担保しながら実現することが可能となります。
IVS技術の実装はまだ緒に就いたばかりですが、IVS技術促進協議会は、オペレーティングシステムからアプリケーションまでのIVS技術を促進することで、字体を含む文字情報の保全を可能にし、相互運用性の向上を実現するための技術啓発、参加企業間での相互運用性検証、事例紹介、そして共同マーケティングまで幅広い活動を予定しています。また、電子政府などの公共システムのオープン化へ環境づくりに対しても貢献していきます。
発起人企業・団体：
l アドビ システムズ 株式会社
l イースト株式会社
l 株式会社ジャストシステム
l 大日本スクリーン製造株式会社
l マイクロソフト株式会社
l 株式会社モリサワ
【本協議会の目的と事業】
［目的］
本協議会は、ユニコード（公的規格としてはISO/IEC 10646）では同一符号位置に統合される文字の異なる字形（グリフ）の使い分け、字体情報の保全が可能な既に標準化されているIVS (Ideographic Variation Sequence)技術についての情報共有、啓発などの活動を通じて、その技術の普及促進と既存システムとの協調に資することを目的とします。
［事業］
上記の目的を達成するため、本協議会では次の事業を行います。
- IVSに関する情報交換と経験交流に関する事業
- IVSに関する普及啓発
- IVSに関する相互運用性の向上に関する事業
- その他本協議会の目的を達成するために必要な事業
- 本協議会は営利を目的とする活動、事業を行わない
詳細については、IVS技術促進協議会規約（案）をご参照ください。
このアーティクルを書くために、ハードディスクを掘っていたら、設立趣意書の原稿と思われるファイルがいくつも出て来た。趣意書の原案を起草したのはどうもぼくのようだ。
この設立総会の折に提案された、役員候補の名簿も見ておこう。
「IVS技術促進協議会」 役員候補
平成 22 年 12 月 6 日 (月)
IVS技術促進協議会 発起人会
会長
三上 喜貴 (長岡技術科学大学教授、ISO/IEC JTC1/SC2国際議長)
副会長
加治佐 俊一 （マイクロソフト株式会社 業務執行役員 最高技術責任者）
村田 真 （国際大学GLOCOMフェロー）
理事
山本 太郎 （アドビ システムズ 株式会社）
下川 和男 （イースト株式会社）
福良 伴昭 （株式会社ジャストシステム）
小林 龍生 （Unicode Consortium）
藤澤 恭平 （大日本スクリーン製造株式会社）
森澤 彰彦 （株式会社モリサワ）
事務局長
田丸 健三郎 （マイクロソフト株式会社 技術統括室 本部長）
エキスパート会員
安岡 孝一 （京都大学東アジア人文情報学研究センター准教授）
師 茂樹 （花園大学准教授）
以上
会長は、当時ISO/IEC JTC1/SC2の国際議長だった三上喜貴さんが引き受けてくださった。三上さんが会長を引き受けてくれたおかげで、IVS技術促進協議会は、スタート時点からある種のステイタスというかレピュテーションを日本の内外から認められる存在になったような気がする。副会長には加治佐俊一さんと村田真。例によって、村田真には《さん》が付かないなあ。付けると、なんだかよそよそしくなってしまってね。 この二人も、今から思うと、素晴らしい布陣だなあ、と。かたや加治佐さんが代表的なグローパルIT企業の日本における最高技術責任者だったのに対し、かたや村田真は若いころからW3CのXMLワーキンググループにグローバルなゼロックスグループを代表して日本人として唯一アクティヴメンバーとして参画し、オリジナルのXML策定に力を振るって勇名を馳せると同時に、そのころはまだ策定の最終段階にあったEPUB3のレコメンデーション化を目指して、辣腕を振るっていた。彼の悪名、おっと、勇名は、日本でよりも、むしろ、グローバルな国際標準化の専門家の間で轟いていた。他の理事やエキスパートも、業種やアカデミーにおける専門分野を超えて、単にIVSという至極専門的なIT技術の一分野に限ることなく、幅広い分野の専門家の参画者を得たことで、この協議会は、とても幸せなスタートを切ることが出来たように思う。 後に、IVS技術促進協議会は、名称を文字情報技術促進協議会と変更することになるが、このチームビルディングを見ると、その萌芽はすでにこの発足時点であったような気がする。
それにしても、IVS技術促進協議会は、どういう経緯で発足に至ったのだろうか（以下次回）。
固有名詞の字体同定
「字形概念と字体概念の関係」「文字集合の独立性」と、符号化文字集合にとって重要な考え方について、述べてきた。最後は、「固有名詞の字体同定」について。
じつは、これって、結構厄介な問題なのだ。
この手の問題を考えるとき、ぼくがいわばバイブルとして参照する豊島正之さんの「JIS批判の基礎知識」を、再度紐解いてみよう。
https://joao-roiz.jp/mtoyo/on-JCS/mt-gene.pdf
固有名詞の典拠性について、下記のような記述がある。
1.1.1 旧 JIS の「文字概念」の語の問題
（前略）
文字の符号化自体は、具象的な図形そのものではなく、その概念上の存在に対して行われるものであり、且つ、 図形文字の概念は、(字義の差は図形差に反映されるという前提の下での) 図形概念に依存しているから、文字概念は、字義 (字の意味・用法) と字の図形概念とが相互に規定しつつ結ばれたもので、つまり、それ自体が記号で ある。
1.1.3 字義の合意 意味の指定は難しいので、字義の合意は、何らかの文献参照で替えられる事が多い。この場合、文献自体に就て の合意があれば参照底本とし易いので、著名な字典、法律、経典等を用いて、これらは既に本文と字体が定まって いるという合意を利用する。（中略） 尚、字義を殆ど欠いた固有名詞では、その名前を持つもの (referent) の存在を参照対象とするしかなく、同定は 時に困難で、「人の名前は本人が違うといったら文字は絶対違う」(坂村健,1997) と、同定を諦める見解も現れる事 になる。
豊島さんのこの部分は、JIS X 0208のいわゆる新旧JIS問題に関連して、《文字概念》について論じたものなので、必ずしも現時点でのぼくの立場と完全に一致しているわけではない。その上で、重要なのは、第一に、
「意味の指定は難しいので、字義の合意は、何らかの文献参照で替えられる事が多い。」この場合、（中略）著名な字典、法律、経典等を用いて、これらは既に本文と字体が定まって いるという合意を利用する。」
という部分。IRGが康煕字典（中華書局版）を典拠の中軸に据えていることは、豊島さんのこの部分の議論に見事に対応する。国際標準化活動としての符号化文字集合という立ち位置（すなわちぼく自身の立ち位置）で、重要なことはこの中華書局版の学術的な正統性云々（このアーティクルで省略した豊島さんの議論）ではなく、標準化活動の主体（ここではISO/IEC JTC1/SC2）として、康煕字典（中華書局版）を典拠の中軸としますよ、と宣言することなのだ。
UCSの統合漢字部分に、各カラムごとに典拠情報が記載されているのも、同じ文脈で理解することが出来る。すなわち、統合漢字として符号化するIdeographは、それぞれの国や地域のauthenticな辞字典類や公的な符号化文字集合規格、そして、公的な文字データベース（文字情報基盤の文字図形を国際提案するに当たって、日本の提案で追加された）など。IRGでの実際の文字同定の作業は、突き詰めると、それぞれの典拠に掲示されている文字相互の同定、ということになる。
そして、もっと重要なのは、後半。
「字義を殆ど欠いた固有名詞では、その名前を持つもの (referent) の存在を参照対象とするしかなく、同定は 時に困難」という部分。
要は、固有名詞の字体の異同については、当事者に聞くしかない、ということ。前々回のアーティクルで詳述したように、符号化文字集合で符号化しているのは、あくまでも抽象的で視覚的に見ることの出来ない字体。なので、ご本人に聞くべき問いかけは、例示字形を手がかりとして「あなたがお名前に使われている字体は、この字体集合の中のどの字体に帰属しますか」といったことになる。
行政事務標準文字に即して、前々回の思考実験（字体に対応する百均の小袋モデル）で考えると。電子化の対象となる行政文書（戸籍や住民票など）に含まれる人名や地名などの固有名詞を構成する文字について、小袋に貼り付けてある字形を頼りに、どの小袋に入れるのが一番適当かを探していくことになる。行政事務の担当者が迷った場合は（本来は迷わなかった場合も）、最終的にはご本人もしくはご遺族などの当事者に確認する必要があろう。
厄介なのは、当事者が、該当する小袋が見つかりません、とおっしゃった場合。
解決策は、二つしか無い。
一つ。字形が一番近そうな小袋を示して、これでいかがですか、と提案して納得してもらう。
一つ。新しい小袋を用意して、該当する字形を小袋に貼り付けて、新たな字体の例示字形とする。当然ながら、後者の事後的な手続きには、膨大な手続きとコストが発生する。
行政事務標準文字は、デジタル庁の担当部署が、各自治体の全面的な協力を得て、戸籍関連文書を中心とする現今の行政文書に現れる人名や地名などの固有名詞に含まれる字形を渉猟した上で、ある一定の粒度で整理統合した字体集合になっているので、後者の可能性は、限りなくゼロに近いだろう。
包摂規準（統合規則）の大切さ
ここまで来れば、考えなければならないことは、案外単純なことだ。
対象となる字形につき、字体を代表(represent)する例示字形とのある一定粒度の類似性のみに拠って、帰属する字体を選ぶこと。
その類似性を具体的に示したのが、他ならぬ包摂規準（統合規則）なのだ。そして、その包摂規準は、字体集合ごとにそれぞれ異なっている。
再び、豊島さんのバイブルを見てみよう。
1.1.4.1 精度規定としての包摂規準 実際に存在する字形は、一回限りの存在であり、二つとして同じ字形は存在しない。こうした存在を符号化する 為には、それらの図形的な差を捨象して、抽象化せねばならない。全ての字形 (加算無限) に符号を振る符号化は、 (理論的には可能だが) 現実的ではなく、「見た目により同一形状の文字は統合する」(坂村健,1996b) のが、符号化 の一般である。 （中略） こうした「捨象」をどの程度まで行うかに就ての合意が「包摂規準」であり、工業規格としての符号化文字集合 では、いわば情報交換の「精度」の規定であると見てよい。
この部分も、包摂概念の記述として、間然とするところがない。
特に、最後の行『情報交換の「精度」の規定』のところ。今までのぼくの議論に引き寄せると、文字集合が異なると（包摂分離が行われると）、包摂の精度が変化するのだ。言い換えると、文字集合が異なれば包摂規準も異なるのだ。ぼく自身は、このような包摂の精度を勝手に字体弁別粒度と呼んでいる。
さらに言えば、包摂規準は、文字集合全体に一律に適用されるものではなく、厳密には、集合の個々の要素となる字体毎に独立しているものなのだ。例を挙げた方が分かりやすいだろう。
たとえば、点のあるなし。JIS X 0213の「6.6.3.2漢字の字体の包摂規準の詳細」を見ると、d)1点画の増減の違いとして、124)大、犬（便宜上、該当する文字そのものを記しているが、実際には、偏や旁などに用いられる校正要素）が掲げられている。そして、
（1-51-26）が掲げられている。CITPCの漢字検索ページの要素図形検索で「戻」をキーとして検索をかけると、（MJ043010、U+5533、<5533,E0103>と
（MJ043250、U+5533、<5533,E0105）がヒットする。また、
（MJ198250、U+6D66、1-86-83）、
（ MJ015472、U+6DDA、1-86-83）もヒットする。
細かく見ていくときりがないが、概ね常用漢字体は点なし、いわゆる康煕字典体が点あり、ということのようだ。ともあれ、ここでの議論は、構成要素として
や
を持っている漢字でも、JISで包摂されたりUCSで統合されるものと、JISで包摂されなかったり、UCSで統合されなかったりするものがある、ということ。構成要素としてやを持つものの中では見つけられなかったが、前回のアーティクルで議論したように、JISで包摂されながら、UCSでは統合分離されているものもある。（ちなみに、JISで包摂されていないものは、原規格分離の原則を援用して、互換漢字に符合位置を与えている。）
簡単な例を挙げるつもりだったのに、かえってややこしい話になってしまったが。要は、包摂規準や統合規則といっても、全ての漢字に適用されているわけではなく、（標準化活動の当事者の一人としてははなはだ忸怩たるものがあるけれど、）結構いい加減に使われている、ということ。
さてと。気を取り直して、今回のアーティクルの結論めいたことを纏めておこう。
固有名詞に用いられる文字は、辞書や古典籍などの典拠があるわけではないので、字形のみをよりどころにして、対象となる符号化字体集合（前回の議論の文脈では、Annex Aを用いて宣言されたUCSのサブセット）のどの字体に紐付けるかを決定しなければならない。最終的には、当事者に、例示字形をたよりに、より近いと思われる字体を選んでいただくことになる。その際、字体集合の中では同じ字体とみなす字形の相異部分を列挙したリスト（JISでは包摂規準、UCSでは統合規則）が、判断のより所として有用だ。ただし、当事者が、この字体集合の中には、自分の姓を表記する文字（字体）が存在しないと、強固に主張されたときは、面倒でも、しかるべき手続きをとって字体集合そのものへの追加と、その国際標準化をやらなければならない。
文字集合の独立性
まず、二組の漢字字形を見ていただきたい。
1-36-45、U+585A
1-15-55、U+585A
1-46-20、U+968
1-93-61、U+9686
ツカとリュウ、大塚隆といった感じで、姓や名に多出するし、一里塚とか筋肉隆々とかいった一般名詞にもよく用いられる字だ。
しかし、よく見ると、ツカもリュウも、それぞれ少しずつ異なっている。
先に素性の種明かしをしておくと、1-36-45と1-46-20は、常用漢字表（平成22年6月7日改定版、以下同）に掲示されている字形で、1-15-55と1-93-61は、常用漢字表では丸括弧に入れられた字形で、いわゆる康煕字典体。
ちなみに、貼り込んだ画像は、MJ明朝体。CITPCの文字検索システムからコピーしてきた。字体は、常用漢字表に掲載されている例示字形と同じ。というか、常用漢字表も、MJ明朝体を用いているのだけれど。
常用漢字のなかには、いわゆる康煕字典体と字体が異なるものがいくつかある、ということ。ちなみに、常用漢字以外の漢字の字体をどのように考えるか、という問題については、2000年に当時の国語審議会が出した「表外漢字字体表」に仔細な論述がある。
とはいえ、今回議論したいのは、常用漢字表字体といわゆる康煕字典体との違いといったことではなく、これらツカとリュウの扱いが、JIS X 0208単独の場合と、JIS X 0213の一部としてのJIS X 0208とで、じつは異なっているということ。
規格票のそのものにそって、経緯を復習しておこう。手元に、文化庁文化部国語課が、当時の国語審議会における審議に資するために復刻したJIS C 6226:1978がある。これを見ると、36区45点の字形は、
の形に近い。
一方、同じ資料に含まれているJIS X 0208:1983では、36区45点の字形は、の形に近い。そして、JIS X 0208：1997。この版の、36区45点の記述が面白い。過去の規格票の字形（参考）の欄に、78としてに近い字形が、78/4Xとしてに近い字形が掲げられている。そして、JIS X 0208:1990から加えられた包摂規準では、129)として、豕（いわゆるいのこ）の点があるものとないものを包摂している。（ぼくの手元には、JIS X 0213:1990がないので、JIS X 0213:1997を参照している。）
JIS X 0208では、（たぶん）ツカに関しては、一貫して常用漢字字体といわゆる康煕字典体とを包摂している。
そして、JIS X 0213:2000。
ちょっとやっかいな話だが、JIS X 0213には、JIS X 0208のすべての面区点位置が含まれている。表層的には、JIS X 0213は、JIS X 0208の区点位置に、新たにいくつかの面区点位置を追加した形となっている。
しかし、JIS X 0213の規格票には、面区点位置の一覧表部分にJIS X 0208相当の例示字形が掲載されているが、附属書6（規定）漢字の分類及び配列には、追加部分だけが記載されていて、JIS X 0208相当部分についての詳説はない。
（ということは、漢字の分類及び配列に関しては、JIS X 0208を見ろよな、ということなのかなあ。）
とについても見ておこう。
こちらの方は、JIS X 0208では、一貫してに近い字形が掲載されている。
その上で、包摂規準のd)連番132で、に近い字形とに近い字形が包摂されることが明記されている。
そして、JIS X 0213。に新しい面区点位置を与えた上で、包摂規準の詳説については、連番133としてJIS X 0208とほぼ同等のものを掲げている。あれれ、別の面区点位置を与えながら、包摂規準に掲げていいのかなあ。（いまさら、このような細部をほじくり返しても、なんだかなあ、という気がするので、これ以上深追いしないが、何だか釈然としない。）
JIS X 0208で包摂されていながら、JIS X 0213では、別の面区点位置を与えていた例は、他にもいくつもある。いわゆる包摂分離。
今回の議論の眼目は、まさに、この包摂分離（Unicodeの場合はDisunification、統合分離）の符号化文字集合における情報交換上の問題についてだ。
JIS X 0208を単体で運用した場合の36-45と、JIS X 0213の一部として運用された場合の1-36-45では、たとえ、そこに掲示されている例示字形が全く同じであっても、その区点位置、面区点位置に帰属する字形の範囲が異なる、ということ。
JIS X 0213では、に類似した字形（よりも一画多い）は、JIS X 0213では、別の面区点位置1-36-45に帰属する。
事情は、一般的にJIS X 0213で包摂されており、Unicodeでも統合されていた文字が、Unicodeで統合分離された場合でも、変わりがない。
次のように言い換えてもいいだろう。
ある字形が対応付けられる字体は、その字体を要素として含む字体集合が異なれば、たとえ同じ文字名を持った字体であっても、その字形が同じ名前の字体に帰属することは保証されない。
もう一つ、別の言い方。
符号化された文字列が送信者側と受信者側で同一であることを保証するためには、送信者側と受信者側が同一の符号化文字集合を用いなければならない。
当たり前と言えば当たり前の話だが、一見同じ字体集合に見えても、改正等で包摂分離や統合分離が行われると、それらの字体集合は互いに非互換となり、通信における同一性は保証されなくなる。
Annex Aの重要性
先に述べたように、どのような場合であれ、ある符合位置を包摂分離もしくは統合分離すると、分離以前と以後では、情報交換上非互換となる。特に、UCSあるいはUnicodeでは、日本、中国、台湾、韓国などが、統合漢字領域を共有しているので、一部の国や地域の都合で行われた統合分離が、該当する文字を統合を前提として運用している他の国や地域で、混乱をもたらす可能性が大きくなる。
たとえば、
(U+5409)と
(U+20BB7)。業界では「サムライよし」と「ツチよし」などと称して、以前から話題に上ることが多いが。JISでは、一貫して、「サムライよし」と「ツチよし」は、包摂されている。
UCSにCJK統合漢字拡張Bが追加制定された際、この「サムライよし」に台湾の典拠により、独立した符合位置が付与された。ご自分のお名刺などに「ツチよし」を使っておられた方の一部には、欣喜雀躍してこの拡張Bの符合位置を用いて、電子メールなどに使われた方があるかもしれない。しかし、あにはからんや、JI X 0213に対応する符合位置にしか対応していないフォントで表示すると、文字化けというかこの拡張Bの符合位置が欠落してしまう事態となり、なんだかなあ、という結果を招来する。
文字情報基盤では、「ツチよし」にも文字図形名を付与し、今般、UCSの水平拡張によって、UCSの側にも、MJ文字図形名を日本典拠として追加してもらったので、規格論的には、いわば日本の漢字として堂々と使えるようには、なっている。
（ただし、JIS X 0213とMJ文字図形集合との関係は依然として変わっていない。即ち、JIS X 0213の面区点位置に対応するUCSの符合位置全体から成る文字集合と、MJ文字図形全体から成る文字集合では相互の情報交換は保証されない。）
このような問題は、IVDが絡んでくるとますます厄介になる。
例えば、ぼくの名前の一部の
。これには、
という異体字があって、IVDにも<9F8D,E0104>として登録されている。は、<9F8D,E0103>。
は、名刺など（特に楷書体で刷られたもの）でもそうだが、賀状や凧などにもデザイン的に好んで使われている。ぼくのオヤジも、ぼくの名前を書くときには、の字形を使っていたことを懐かしく思い起こす。
システムやアプリケーションがIVSをサポートしており、MJ明朝体フォントがインストールしてあれば、とを自由に使い分けることが出来る。システムやアプリケーションがIVSをサポートしていなかったり、MJ明朝体フォントがインストールされていなければ、UCSの規定では、VSの符合位置を読み飛ばすことになっているので、元のU+9F8Dに対応するフォントが表示される。
以下は、仮の話だが。
このに独立したUCSの符合位置が与えられたらどうなるだろう。
先に挙げた拡張Bの「ツチよし」と同様の事態が出来する。
日本が、IVDに汎用電子情報交換環境整備プログラムのコレクション登録を要請していたころから、IRGでは、新規符号化に当たって、それまでバイブル視されていた附属書S（いわゆるUnification Rule）に反する統合分離が散見されるようになってきた。また、IRGにはcognate ruleというのだが、字形が類似していても元々の意味が異なれば異なる符合位置を与える、というものがある。逆に言えば、cognateであれば、少々の字形の相異は捨象してunifyする、ということでもある。cognateかnon-cognateか、といった使い方をする。
しかし、このころから、IRGでは、字形が酷似していれば、non-connateであっても同一の符合位置を付与する、という流れが大きくなってきた。新規符号化の対象となる文字が、どんどん拡散し、固有名詞など典拠を明確に示すことが困難になってきた、という事情もあった。
そんなわけで、日本としては、IRGの場でコントロール不能となった非互換な統合分離に関して、国内でのUCS利用に伴うリスクを低減するための、防衛的な対応が必要となった。
ここで、日本が採った戦略が、Annex Aの積極的活用だった。
すなわち、Annex Aに日本の社会生活に必要な符合位置と符合位置の組を切ったコレクションを標準化し、このコレクションを明示することで、UCSに準拠した上で、使用する符合位置の範囲を限定しよう、というものだった。
UCSのAnnex A、翻訳規格のJIS X 0221では、附属書A（規定） 部分集合用図形文字の組のパートを見ても、さまざまな部分集合の名前と含まれる符合位置及び符合位置の組とをだらだらと羅列しただけのものにすぎない。では、なぜ、このAnnex Aが重要なのかというと、キモは規格書本体の4 適合性 4.3 装置の適合性のところにある。
ちょっと面倒だが、JIS X 0221:2022から該当部分を引用する。
「適合性を主張する場合、（中略）、採用した符号化形式、符号化方式、部分集合及び個条11に従って採用した制御機能の種類を明記しなければならない（部分集合は、組及び／又は文字の一覧によって示す。）。」
UCSに適合していると主張するためには、他のゴチャゴチャとした項目とともに、該当する装置で用いるUCSの符合位置を明記しろよな、符合位置すべてをダラダラと記述するのが面倒なら、Annex Aに記載されている組の名前を使ってもいいよ、ということ。
ぼくが文字コードの標準化に係わり始めたころは、装置やフォントの規格への適合性といっても、次々に新しく規格化された符号化方式や符合位置に対応していくことに精一杯で、装置から、不要な、もしくは、いたずらをする符合位置を排除した上で、規格適合性を主張するなどという必要性が顕在化することはなかったように思う。
拡張Bが規格化されて、康煕字典の見出し文字すべてが曲がりなりにも統合漢字に含まれるようになったころから、国や地域に特有の異体字を区別して使いたい、というニーズが顕在化してきた。汎用電子情報交換環境整備プログラムで、人名や地名に用いられる多くの異体字を拾い集めた日本も例外ではなかった。そんな需要に応えるために、随分以前に規格としては成立していたVSのメカニズムを、統合漢字に適用し、登録制度を設けることで国や地域による必要性の差異を解決しようとしたのが、Unicode Consortiumが提案した、IVD(Ideographic Variation Databese)の仕組みだった。
しかし、この仕組みは日本とUS以外のIRGのメンバーにはなかなか理解されず、規格の整合性という点からは目も当てられぬような非互換な統合分離が、繰り返されている。
このような状況の中で、日本の現代社会で必要不可欠な符合位置（と符合位置の列）とを、用途毎に明確にAnnex Aのコレクションとすることで、不要もしくは害悪を及ぼす符合位置を排除しよう、というのが、近来のJSC2（情報処理学会情報規格調査会SC2専門委員会）の基本的な戦略となっている。
Annex Aを用いれば、例えば、JIS X 0208だけとか、JIS X 0213の漢字部分とJIS X 0208全体とか、常用漢字と仮名文字だけ、とかいった部分集合をUCSの中だけで、宣言することが可能となる。
WTO/TBTとの関連
この実際に使用するUnicodeのサブセットとしての文字集合を明示することの重要性が増してきたもう一つの理由は、WTOやTBT協定といった貿易に関する国際条約の側から、国内の工業規格が非関税障壁とならないように国際標準に則った調達を促進する動きが強まったことがある。
例えば、現在では、JIS X 0213に適合した装置といえば、JISの面区点位置に対応するUCSの符合位置と符合位置の列のすべてをUCSの符号化方式で符号化したもの、といったことのなるが、かつてのShift JISなどは、典型的なWTO/TBT違反とったことになってしまう。
ちかごろ、デジタル庁で行政事務標準文字の策定が進んでいるが、これも、現時点でUCSにもIVDのMJコレクションにも対応する符合位置や符合位置の組を持たないものを標準化したりIVD登録した上で、Annex Aに新たなコレクションを切ることで、晴れて国際標準準拠を謳うことができるようになる。
国際標準とWTO/TBTとの関係については、下記を参照のこと。
CREPDL
ISO/IEC JTC1には、UCSのみならず、ある装置に用いる文字レパートリを明示的に記述するための言語が規格化されている。ISO/IEC 19757-7:2020。
この翻訳規格が、JIS X 4177-7 （文書スキーマ定義言語(DSDL)—第７部：文字レパートリ記述言語(CREPDL)）。
国際規格、翻訳規格共々、悪友村田真（当協議会の副会長）が中心となって規格化を行った。
今後、地域や用途毎に、半ばカオスと化したUCSの中で、必要な符合位置と符合位置の組とを明示的に限定する用途はますます増大するものと思われる。そのためにも、機械的な処理でUCSへの適合性を検証できる仕組みの必要性も増してくることだろう。
CREPDLのJIS化経緯については、村田真の下記の報告が参考になる。
最後に
ちょっとまとまりのない流れになってしまったので、簡単に整理し直しておこう。
一旦統合されて同じ符合位置を与えられた文字を、複数の字体とみなして統合分離することは、規格の相互非互換となり混乱を招く。
それを避けるためには、メカニズムとしてはIVSを用いることが好ましい。
自国の状況に反して非互換な統合分離が行われた場合は、弊害をもたらす符合位置を排除するため、用いるべき符合位置と符合位置の列を明示的に宣言するために、Annex Aを用いることが有効である。
この方式は、国際規格に準拠した上で、国や地域のニーズに対応するという点で、WTO/TBTの観点からも好ましい。
字体と字形、改めて
ここ一年ほどお手伝いしてきた、デジタル庁の「地方公共団体情報システムにおける文字要件の運用に関する検討会」がひとまず終結した。当初、ぼくの方も、デジ庁の担当の方々も、ゴールの設定を含めて手探り状態だったのが、終盤にさしかかるころには（少なくともぼくの方では）目指すべき方向性というか、符号化文字集合を用いた公共的情報システムに求められる要件が何かについて、かなり明確に理解できるようになったのではないか、と思う。いまさらなにを、という声も聞こえてきそうだが、1995年にユニコードの技術委員会に顔を出すようになってから、四半世紀以上経って、自分が何をなし、何を考えてきたかが、ようやくほの見えてきた、といったところか。一区切りついたところで、過去をも振り返りつつ、いくつかの基本資料に触れながら、符号化文字集合とはいかなるものなのかについて、ぼくなりの考えをまとめておきたい。
というわけで、ぼくの符号化文字集合論、その一。
常用漢字表
字体と字形、初めの初め
[https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kijun/naikaku/kanji/]
まずは、この二つの言葉から始めよう。《字体》と《字形》。
この二つの概念の相違についての理解がなければ、そもそも符号化文字集合についての議論は成り立たない。とはいえ、関係者の間でも、符号化文字集合の文字集合が何を意味しているかについて、完璧な合意があるわけでもない。ユニコードにしてもJISの漢字集合にしても、文字とは何かについて開発者間で明確な合意があるとは言い難い。以下は、あくまでぼく個人の考え。
《字体》とは字の骨組み（骨格）を表す抽象的案概念。
《字形》とは、視覚的に認知できる具体的な字の形。
この概念の違いは、多分、符号化文字集合だけでなく、もう少し広い範囲の専門家の間でも共有されているように思える。例えば、内閣告示となっている常用漢字表。これは、符号化を前提としない純粋な文字表（文字集合）だが、字体概念と字形概念を明確に切り分けて記述されている。さすが。
常用漢字表を策定した側（文化審議会国語分科会の委員の方々と文化庁国語課の専門官）では、常用漢字表は字体集合だという明確な意識をお持ちだということがよく分かる。しかし、字体は抽象概念なので、それを視覚的にどう表現するかにものすごくご苦労なさっている。下記の記述など、そんなご苦労の跡がにじみ出ていて、何だかニヤニヤしてしまう。
「個々の漢字の字体については、現行の常用漢字表同様、印刷文字として、明朝体が現在最も広く用いられているので、便宜上、そのうちの一種を例に用いて示した。このことは、ここに用いたものによって、現在行われている各種の明朝体のデザイン上の差異を問題にしようとするものではない」（改定常用漢字表平成22年6月7日、(15)ページ）
ちなみに、この改定常用漢字表の印刷には、IPAMJ明朝体が用いられているのですよね。エヘン。
このような字体表の視覚的表現に明朝体フォント（活字）を用いるという手法は、JISの漢字集合でも採用されていて、これも、苦し紛れといえば苦し紛れながら、JISの規格票に印刷された視覚的字形は、あくまでも参考情報としての例示字形ということになっている。なので、JISについても（そして、UCSについても）、ここで引用した常用漢字表記述の後段には、まったくもって納得がいく。
さらにちなみに。常用漢字表の前身である当用漢字字体表は、ある意味で、むしろ潔い。明朝体ではなく、手書きのそれも太さに変化が少ない、太めの鉛筆で書いたような書体で字体を示している。この方が、字体は文字の骨格であることがより明確に伝わってくる。
[https://www.bunka.go.jp/kokugo_nihongo/sisaku/joho/joho/kakuki/syusen/tosin05/index.html]
『行政用文字の調査研究』（高田智和・井手順子・虎岩千賀子）
『行政用文字の調査研究における文字同定』（高田智和）
https://doi.org/10.15084/00002197
行政用文字の調査研究 : 汎用電子情報交換環境整備プログラム
高田, 智和,井手, 順子,虎岩, 千賀子,TAKADA, Tomokazu,IDE, Junko,TORAIWA, Chikako
日本語科学, 23, p. 95-110, 2008-04-22
https://doi.org/10.15084/00002218
行政用文字の調査研究における文字同定 : 辞書同定と辞書非掲載字に対する文献資料・非文献資料による同定
高田, 智和,TAKADA, Tomokazu
日本語科学, 25, p. 131-141, 2009-04-24
上記の二つの論文は、CITPCの理事でもあり文字情報基盤委員会の委員長もお願いしている国立国語研究所教授の高田智和さんの国研の紀要に掲載された論文。
この論文自体、人名に用いられる漢字の扱いがいかに困難ことなのかを、汎用電子情報交換環境整備プログラムから文字情報基盤整備事業に至る豊富な実体験に立脚して論じていて、自治体の現場で実務に係わる方々には、ぜひ、読み込んでいただきたいものなのだが、白眉は、じつは、この論文に掲載されている図。高田さんは、図よりも本文！と文句を言うかもしれないが、この図ほど、字種、字体、字形の違いを明確に示したものをぼくは他に知らない。というか、上にぼくが書いた説明など、この図を見れば瞭然、説明など全く必要ない、というものだ。
(img)(img)
左側が共著、右側が単著。字種、字体、字形の階層構造が一目瞭然。この図を目にするだけでも、両論文を参照する価値がある、というものだ。
あえて、言わずもがなの説明を加えると。これらの図が、優れているのは、字種、字体、字形の違いが階層構造で分かりやすく表現されているところにある。一つの字種に複数の字体があり、さらに、それぞれの字体にも複数の字形があることが、まさに一目瞭然なのだ。特に、左側の図で、一つの字体（明朝体の字形で代表させている）の下に、明朝体字形と手書き字形を並べて掲げてあるところ。まさに、字形が具体的な視覚イメージであり、字体が抽象的な文字の骨格であることが、簡単に理解できる。
字体と字形の狭間で（小林龍生）
文字情報基盤整備事業を例として
[https://www.jstage.jst.go.jp/article/johokanri/58/3/58_176/_article/-char/ja/]
拙論でいささか気恥ずかしいのだが、もう一つだけ、字体概念と字形概念の違いを理解するための、試行実験の例を掲げておく。
題記の論文は、国立研究開発法人科学技術振興機構（JST）が刊行していた「情報管理」vol.58 no.3,2015に掲載されたもの。手前味噌だが、わりとうまく書けていると思う。2016年に発表された文化審議会国語分科会報告『常用漢字表の字体・字形に関する指針』の編集を担当していた文化庁国語課（当時）の武田さんが、文字情報基盤整備事業の委員会が終わったとき、わざわざ、歩み寄ってきて、絶賛してくれた。ものすごく嬉しかった。
閑話休題。
この論文に、書いた思考実験。
簡単な思考実験で説明する。
さまざまな新聞や雑誌などから切り取ってきた多数の文字（具体的な字形の集合）を，視覚的類似性を手がかりに複数のグループにまとめる。まとまった字形のグループを，小さな箱か袋にまとめて入れる。これらの箱や袋に，他と明確に区別できる整理番号や固有の名前を付ける。
この整理番号や固有名を字体と見なすのである。
すなわち，同一の箱に入れられた字形は同じ字体に属し，異なる箱に入れられた字形は字体が異なる，と考える。
読者の多くは，はぐらかされたように感じられると思うが，情報技術としての符号化文字集合では，ラベル（整理番号や固有名）そのものを伝達や複製などの処理の対象としても，何ら不都合は生じない。逆にいえば，情報処理装置は，ビット列に還元でき
るラベルしか扱うことができない。
字体とは異同を判別するために字形の集合に付けられた固有名である。
(情報監理2015 vol.58 no.3 p177）
最初の常用漢字表の説明に戻ると、常用漢字表に印刷されている明朝体の文字も、新聞や雑誌、手書きメモなどから切り取ってきたさまざまな文字を入れた袋や小箱に貼り付けられたラベルのようなものなのだ。原理的には、このラベルは、文字として判別できれば、明朝体だろうが、ゴシックだろうが、手書きだろうが、どのような書体でもいいのだが、デザイン的に統一されていた方が見やすいし、間違いも起こりにくい、ということで、便宜上ある明朝体書体（この場合は、IPA MJ明朝体）に統一しておく、といったことと考えればいい。