IPAフォントライセンスを巡って

先般、当協議会所属のフォント技術のエキスパートから、MJ明朝体フォントをWOFF化するサービスを提供しているサイトがある、MJ明朝体フォントの使用許諾契約に違反しているのではないか、との指摘があった。事務局長や対外窓口をお願いしている理事の方とも相談して、このサイトのオーナーに連絡を取り、MJ明朝体決め打ちのサービスについては、公開を差し控えていただいた。
ぼく的には、フォントをWOFF化するサービスの必要性もよく分かるし、協議会としても、WOFF化やサブセットフォントの提供など、協議会として直接行うか、協議会メンバーのフォントベンダー各社にビジネスとしてやっていただくかも含めて、具体的な方策を検討しているところだ。
ちょうどいい機会なので、MJ明朝体フォントの使用許諾契約書の成立の経緯と、ついでに、フォントの知的所有権を巡るず〜っと以前のぼくの経験を書き記しておきたい。
そう考えて、経緯を思い起こそうと、過去のメールなどを掘っていたら、先般、開志専門職大学の田代秀一さんが、当協議会メンバーの勉強会でお話しくださった折の資料が出て来た。とてもよくまとまっているので、この資料を引用しながら、ぼくなりのコメントを添えていくことにしたい。

IPAフォントの歴史（田代さん）

2003年 タイプバンク社から権利を購入 (JIS X 0208相当の文字セット(約7千文字)) 2004年 IPAの委託により開発されたソフトで使用することを条件として公開
2007年 (ソフトにかかわらず)誰でも使えるライセンスを適用(改変は不可)
JIS X 0213相当の文字セット(約1万文字)へ拡張
2009年IPAフォントライセンスの適用
OSI(Open Source Initiative)から、同団体の定めるOpen Source Definitionに合致する オープンソースライセンスであるとの認定を受ける。
2010年文化庁が常用漢字改訂の検討に採用。同年11月に告示された常用漢字表はIPAフォント を活用して構成された。
2010年「文字情報基盤整備事業」開始
内閣官房IT総合戦略室、経済産業省と共に、行政の実務で求められる人名や地名等の正 確な表記をコンピュータで可能にするため、約6万文字の漢字について、文字フォント の整備や文字コードの国際規格化等を実施
2017年 ISO/IEC 10646 ed.5発行、IVD version 2017-12-1発行
2019年ISO/IEC10646ed.5追補2発行。提案していた全ての国際規格化が完了。

昔話（小林）

ぼくがIPAフォントに係わったのは、2007年あたりからかな。特に、2009年のOSIからのOSD認証は印象に残っている。電子書籍コンソーシアム時代からの盟友、沼田秀穂さんと池田佳代さんが、獅子奮迅の活躍をしてくれたっけ。
このライセンスがあったからこそ、後のMJ明朝体フォントの開発、公開が出来たと言っても、過言ではないだろう。

IPAフォントライセンスの背景（田代さん資料）

ライセンス開発当時の議論(1)

「何を」守るのか

1. タイプバンク社との約束
   • タイプバンクフォントのファミリー化(ウエイトのバリエーション)とバッティングさせない。
2. フォント産業
   • IPAフォントの存在がフォント産業の脅威とならない。
3. 一般ユーザー
   • 出所や仕様の明らかでないフォントが混在する状態を作らない。
   • メンテナンスされたIPAフォントの評判をおとさないような改変フォント名規則が必要。
4. IPA
   • レピュテーション
5. OSSコミュニティー
   • 自由に使いたい、開発モチベーション。

ライセンス開発当時の議論(2)

「派生」を制限する方法についての案

1. 差分ファイル(difference file)方式
   • 例えば、UNIXのdiffなどを用いて、差分ファイルとpatchツールのみ派生を許諾する。
   • 差分ファイル自身にファイルの更新機能を付加して配布してもよい。
   →議論の結果「もとに戻せるようにする」という条文とした
2. 派生フォントは必ずコピーレフト
   • ビジネスで用いるための高品質改訂フォントへコストをかけた改訂への敷居とする。
3. 改変に伴って既存の市販流通フォントに類似してしまった場合、IPAは一切責 任を負わないことを明記。
   • 既存バリエーションフォントとのバッティングにはIPAは責任をとらない姿勢を出す。
   4.フォント名、フォントファイル名に対する使用制限
   • 派生フォントにはIPAフォントの名称を使用してはいけない(SILのOFL精神と同じ)。

その心は。。。

• 表意文字
• わずかな形状変更が(意味に及ぶ)大きな影響
• 多数の異体字
• 文字に発展性がある
• 製品のシェアを背景として、変更された字形が普及してし まう恐れ
• 利用者の主体性が保証されることが重要

もう一つのポイント（小林）

IPAライセンス開発の背景については、この田代さんの資料で十全に尽くされていて、ぼくがあえて付け加えることはない。ただ、今回のWOFFをめぐる出来事で、思い知った、IPAライセンスの重要なポイントについてだけ、付記しておきたい。
フォントの知的所有権を巡る議論は、今も昔も、主として、書体デザインに係わるものがほとんどだ。
しかし、MJ明朝体フォントについては、文字情報一覧表に記載されている文字図形のすべてが、UCSの符号位置（IVSを含む）から視覚的に表現できる、ということがとても重要なのだ。例えば、JIS X 0213の範囲のフォントなら、それこそ枚挙に暇がないほどの種類がある。JIS X 0208やかつてのCP932相当にまで範囲を拡げれば、その数はさらに膨らむ。
しかし、少なくとも文字情報基盤整備事業が完了した2019年時点では、文字情報一覧表の全ての文字をカバーしたフォントは、MJ明朝体フォントしか存在しなかった。というか、文字情報一覧表すべての文字を網羅するフォント、というのが、 MJ明朝体フォントのいわばレゾンデートルそのものなのだ。
田代さんの資料からは、フォント名への強いこだわりが読み取れるが、そのこころは、MJフォントを標榜するからには、文字情報一覧表に記載されているすべての文字図形が含まれていなければならない、という決意というか責任感があった。
ぼくは、今回のWOFF化ツールを巡る問題で、いわば条件反射的に、「こればヤバイ！」と思ったのだが、その思いをブレイクダウンしていくと、まさに、この田代さんの思いに突き当たる。
MJフォントには、文字情報一覧表のすべての文字図形が含まれていなければならないのだ。

文字セットの表象としてのフォント

ちょっとややこしい話になるけれど。というか、このブログでも、何度か言及してきたことだが、現在のカオスのようなUCSの世界では、Annex Aでコレクションを切って、使用符号位置を制限し、（可能な限り）集合論でいうコンパクトセットを保持することが重要になっている。
元AdobeのフォントエンジニアのKen Lundeは、IVDの説明のところで、glyphic subsetという言葉をつかっているが、文字の抽象的な形としてのglyphに内包される具体的な図形の範囲は、文字集合全体が（コンパクトセットとして）定まっていなければ、定めることが出来ない。言い換えれば、文字集合の構成要素が変化すれば、あるglyphに含まれる具体図形の範囲も変化する、ということ。
かつて、JIS X 0213でJIS 0208では包摂されていた文字を分離した際に起こったことを思い起こせば、ピンとくるだろう。
MJフォントに戻って、WOFFやサブセット化の問題は、MJフォントから、一部のグリフイメージを切り取って、サブセットを作ってしまうと、その背後にある文字集合も変化し、ユニコードでいうところの、統合範囲も変化してしまう、ということ。

協議会としてのWOFFやサブセットフォント化の検討

とはいえ、文字情報基盤の運用上、その実装環境によっては、WOFF化やサブセット化が必要な局面があることは、十分承知している。
端的な例を挙げれば、現在、デジタル庁で検討が進められている、行政事務標準文字（いわゆるMJ+）でも、現在の文字情報基盤にこれらの文字を追加すると、現在のオープンタイプフォントの制限である16bitの範囲を超えてしまうので、複数のファイルに分離するか、何らかの形での文字一覧表のサブセット化が避けられない。
協議会としてのソリューションについては、会員となっているフォントベンダー各社によるビジネス化も含めて、鋭意検討が進められている。
その場合、現在のIPAフォントライセンスとは異なるライセンスによる使用許諾が必要になるかもしれない。その場合でも、上に掲げた田代さんの思いが継承されることは言うまでもないだろう。

IPAフォントライセンス v1.0（田代さん資料）

• 文案作成を野口祐子弁護士に依頼
• 商用利用を含み、無償で利用可能。
• コピー・再配布を自由とするが、再配布にあたっては同じIPAフォントライセンスを継承さ せなくてはならない。またフォントの名称(「IPAフォント」商標登録済み)の変更は認めない。
• IPAフォントを改変した「派生フォント」を再配布可能。 (条件)
• 利用者が、その意志により、派生フォントを オリジナルのフォントに戻せる方法を提供しなければならない。
• 派生フォントは、Web等のだれもがアクセスできる方法により 。
• 派生フォントには、それをさらに改変するために必要となる十分な情報を添付しなければならない。
• 派生フォントにも、同じIPAフォントライセンスを継承しなければならない。

オープンフォントの志（小林コメント）

このライセンスの文案を作成してくださった野口祐子弁護士は、クリエイティヴ・コモンズ・ジャパンの中心人物としてつとに有名な方。彼女に文案をお願いし、OSIとの密なやりとりを経て完成したのが、IPAフォントライセンスというわけ。
現在、当協議会から配布しているMJ明朝体フォントも、もちろん、このライセンスの元で配布している。当協議会は、独立行政法人情報処理推進機構から、文字情報基盤に係わる一切の成果物について、信託譲渡を受けているわけだけれど、その中核となる文字情報一覧表とMJ明朝体フォントとともに、このライセンスも、文字情報基盤の重要な成果物と言えるだろう。

IPAフォントライセンスを巡って

先般、当協議会所属のフォント技術のエキスパートから、MJ明朝体フォントをWOFF化するサービスを提供しているサイトがある、MJ明朝体フォントの使用許諾契約に違反しているのではないか、との指摘があった。事務局長や対外窓口をお願いしている理事の方とも相談して、このサイトのオーナーに連絡を取り、MJ明朝体決め打ちのサービスについては、公開を差し控えていただいた。
ぼく的には、フォントをWOFF化するサービスの必要性もよく分かるし、協議会としても、WOFF化やサブセットフォントの提供など、協議会として直接行うか、協議会メンバーのフォントベンダー各社にビジネスとしてやっていただくかも含めて、具体的な方策を検討しているところだ。
ちょうどいい機会なので、MJ明朝体フォントの使用許諾契約書の成立の経緯と、ついでに、フォントの知的所有権を巡るず〜っと以前のぼくの経験を書き記しておきたい。
そう考えて、経緯を思い起こそうと、過去のメールなどを掘っていたら、先般、開志専門職大学の田代秀一さんが、当協議会メンバーの勉強会でお話しくださった折の資料が出て来た。とてもよくまとまっているので、この資料を引用しながら、ぼくなりのコメントを添えていくことにしたい。

IPAフォントの歴史（田代さん）

2003年 タイプバンク社から権利を購入 (JIS X 0208相当の文字セット(約7千文字)) 2004年 IPAの委託により開発されたソフトで使用することを条件として公開
2007年 (ソフトにかかわらず)誰でも使えるライセンスを適用(改変は不可)
JIS X 0213相当の文字セット(約1万文字)へ拡張
2009年IPAフォントライセンスの適用
OSI(Open Source Initiative)から、同団体の定めるOpen Source Definitionに合致する オープンソースライセンスであるとの認定を受ける。
2010年文化庁が常用漢字改訂の検討に採用。同年11月に告示された常用漢字表はIPAフォント を活用して構成された。
2010年「文字情報基盤整備事業」開始
内閣官房IT総合戦略室、経済産業省と共に、行政の実務で求められる人名や地名等の正 確な表記をコンピュータで可能にするため、約6万文字の漢字について、文字フォント の整備や文字コードの国際規格化等を実施
2017年 ISO/IEC 10646 ed.5発行、IVD version 2017-12-1発行
2019年ISO/IEC10646ed.5追補2発行。提案していた全ての国際規格化が完了。

昔話（小林）

ぼくがIPAフォントに係わったのは、2007年あたりからかな。特に、2009年のOSIからのOSD認証は印象に残っている。電子書籍コンソーシアム時代からの盟友、沼田秀穂さんと池田佳代さんが、獅子奮迅の活躍をしてくれたっけ。
このライセンスがあったからこそ、後のMJ明朝体フォントの開発、公開が出来たと言っても、過言ではないだろう。

IPAフォントライセンスの背景（田代さん資料）

ライセンス開発当時の議論(1)

「何を」守るのか

1. タイプバンク社との約束

• タイプバンクフォントのファミリー化(ウエイトのバリエーション)とバッティングさせない。

1. フォント産業

• IPAフォントの存在がフォント産業の脅威とならない。

1. 一般ユーザー

• 出所や仕様の明らかでないフォントが混在する状態を作らない。
  • メンテナンスされたIPAフォントの評判をおとさないような改変フォント名規則が必要。

1. IPA

• レピュテーション

1. OSSコミュニティー

• 自由に使いたい、開発モチベーション。

ライセンス開発当時の議論(2)

「派生」を制限する方法についての案
1.差分ファイル(difference file)方式

• 例えば、UNIXのdiffなどを用いて、差分ファイルとpatchツールのみ派生を許諾する。
• 差分ファイル自身にファイルの更新機能を付加して配布してもよい。
  →議論の結果「もとに戻せるようにする」という条文とした
  2.派生フォントは必ずコピーレフト
• ビジネスで用いるための高品質改訂フォントへコストをかけた改訂への敷居とする。
  3.改変に伴って既存の市販流通フォントに類似してしまった場合、IPAは一切責 任を負わないことを明記。
• 既存バリエーションフォントとのバッティングにはIPAは責任をとらない姿勢を出す。
  4.フォント名、フォントファイル名に対する使用制限
  • 派生フォントにはIPAフォントの名称を使用してはいけない(SILのOFL精神と同じ)。

その心は。。。

• 表意文字
• わずかな形状変更が(意味に及ぶ)大きな影響
• 多数の異体字
• 文字に発展性がある
• 製品のシェアを背景として、変更された字形が普及してし まう恐れ
• 利用者の主体性が保証されることが重要

もう一つのポイント（小林）

IPAライセンス開発の背景については、この田代さんの資料で十全に尽くされていて、ぼくがあえて付け加えることはない。ただ、今回のWOFFをめぐる出来事で、思い知った、IPAライセンスの重要なポイントについてだけ、付記しておきたい。
フォントの知的所有権を巡る議論は、今も昔も、主として、書体デザインに係わるものがほとんどだ。
しかし、MJ明朝体フォントについては、文字情報一覧表に記載されている文字図形のすべてが、UCSの符号位置（IVSを含む）から視覚的に表現できる、ということがとても重要なのだ。例えば、JIS X 0213の範囲のフォントなら、それこそ枚挙に暇がないほどの種類がある。JIX X 0208やかつてのCP932相当にまで範囲を拡げれば、その数はさらに膨らむ。
しかし、少なくとも文字情報基盤整備事業が完了した2019年時点では、文字情報一覧表の全ての文字をカバーしたフォントは、MJ明朝体フォントしか存在しなかった。というか、文字情報一覧表すべての文字を網羅するフォント、というのが、 MJ明朝体フォントのいわばレゾンデートルそのものなのだ。
田代さんの資料からは、フォント名への強いこだわりが読み取れるが、そのこころは、MJフォントを標榜するからには、文字情報一覧表に記載されているすべての文字図形が含まれていなければならない、という決意というか責任感があった。
ぼくは、今回のWOFF化ツールを巡る問題で、いわば条件反射的に、「こればヤバイ！」と思ったのだが、その思いをブレイクダウンしていくと、まさに、この田代さんの思いに突き当たる。
MJフォントには、文字情報一覧表のすべての文字図形が含まれていなければならないのだ。

文字セットの表象としてのフォント

ちょっとややこしい話になるけれど。というか、このブログでも、何度か言及してきたことだが、現在のカオスのようなUCSの世界では、Annex Aでコレクションを切って、使用符号位置を制限し、（可能な限り）集合論でいうコンパクトセットを保持することが重要になっている。
元AdobeのフォントエンジニアのKen Lundeは、IVDの説明のところで、glyphic subsetという言葉をつかっているが、文字の抽象的な形としてのglyphに内包される具体的な図形の範囲は、文字集合全体が（コンパクトセットとして）定まっていなければ、定めることが出来ない。言い換えれば、文字集合の構成要素が変化すれば、あるglyphに含まれる具体図形の範囲も変化する、ということ。
かつて、JIS X 0213でJIS 0208では包摂されていた文字を分離した際に起こったことを思い起こせば、ピンとくるだろう。
MJフォントに戻って、WOFFやサブセット化の問題は、MJフォントから、一部のグリフイメージを切り取って、サブセットを作ってしまうと、その背後にある文字集合も変化し、ユニコードでいうところの、統合範囲も変化してしまう、ということ。

協議会としてのWOFFやサブセットフォント化の検討

とはいえ、文字情報基盤の運用上、その実装環境によっては、WOFF化やサブセット化が必要な局面があることは、十分承知している。
端的な例を挙げれば、現在、デジタル庁で検討が進められている、行政事務標準文字（いわゆるMJ+）でも、現在の文字情報基盤にこれらの文字を追加すると、現在のオープンタイプフォントの制限である16bitの範囲を超えてしまうので、複数のファイルに分離するか、何らかの形での文字一覧表のサブセット化が避けられない。
協議会としてのソリューションについては、会員となっているフォントベンダー各社によるビジネス化も含めて、鋭意検討が進められている。
その場合、現在のIPAフォントライセンスとは異なるライセンスによる使用許諾が必要になるかもしれない。その場合でも、上に掲げた田代さんの思いが継承されることは言うまでもないだろう。

IPAフォントライセンス v1.0（田代さん資料）

• 文案作成を野口祐子弁護士に依頼
• 商用利用を含み、無償で利用可能。
• コピー・再配布を自由とするが、再配布にあたっては同じIPAフォントライセンスを継承さ せなくてはならない。またフォントの名称(「IPAフォント」商標登録済み)の変更は認めない。
• IPAフォントを改変した「派生フォント」を再配布可能。 (条件)
• 利用者が、その意志により、派生フォントを オリジナルのフォントに戻せる方法を提供しなければならない。
• 派生フォントは、Web等のだれもがアクセスできる方法により 。
• 派生フォントには、それをさらに改変するために必要となる十分な情報を添付しなければならない。
• 派生フォントにも、同じIPAフォントライセンスを継承しなければならない。

オープンフォントの志（小林コメント）

このライセンスの文案を作成してくださった野口祐子弁護士は、クリエイティヴ・コモンズ・ジャパンの中心人物としてつとに有名な方。彼女に文案をお願いし、OSIとの密なやりとりを経て完成したのが、IPAフォントライセンスというわけ。
現在、当協議会から配布しているMJ明朝体フォントも、もちろん、このライセンスの元で配布している。当協議会は、独立行政法人情報処理推進機構から、文字情報基盤に係わる一切の成果物について、信託譲渡を受けているわけだけれど、その中核となる文字情報一覧表とMJ明朝体フォントとともに、このライセンスも、文字情報基盤の重要な成果物と言えるだろう。

特別講演会：日本のITと行政との接面での《外字とは何か》

例年、当協議会の総会を機に開催している特別セミナーの記録映像と発表資料が公開された。
[https://moji.or.jp/seminar/]
前半は、当協議会副会長の山本太郎さんによる、『文字サイズの標準化の歴史をたどる』というちょっとディープなお話。文字の大きさを指定するポイントの歴史を辿りながら、その話題自体が、活版印刷からDTPをへて、現在のデジタル出版に至る印刷技術史を俯瞰するものになっていて、秀逸。
後半は、『日本のITと行政との接面での《外字》とは何か』と題したパネル。
パネリストには、今、MJ+の議論でチョー話題となっているデジタル庁の前田みゆきさん、地方自治体の行政現場を知悉している一般財団法人全国地域情報化推進協(APPLIC)　企画部担当部長の吉本明平さん、そして、実装実務を担うベンダー代表みたいな感じで、当協議会事務局長で、日本マイクロソフトのNTO(National Technology Officer)のご存じ田丸健三郎さん。田丸さんは、デジ庁職員でもある。
ぼくも、モデレータとして登壇した。けれど、司会をしていて後悔した。自分で言いたいことが、山と出て来て、冷静に司会なんてやっていられなくなってしまった。まあ、反省と言えば反省だけれど、それだけ議論が熱かったってことかな。
委細は、記録映像をご覧いただくこととして、ぼく的には、このパネルを通して、感じたこと、考えたことを書いておこうと思う。

外字とは何か

前田さん、吉本さん、田丸さん、それぞれが、ポジショントークで述べてくれたことを、一言でまとめると。
前田さん：MJ文字情報一覧表に同定できない文字が外字。
吉本さん：複数のシステム（自治体）で、相互運用性がとれない文字が外字。
田丸さん：国際標準で標準化さんれていない文字が外字。
それぞれの立ち位置がはっきり表れていて、これだけでも面白いね。
で、ぼく的には、当然と言えば、当然だけれど、田丸さんに一票。
というか、前田さんのMJ+プロジェクトについては、ぼくも、有識者検討会の末席に加えていただいているので、もはや当事者の一人になってしまっているわけで。で、この有識者検討会には、将来の国際標準化に向けたアドバイスをする、みたいな役割分担を仰せつかっている。この有識者検討会で、ぼくが申し上げたことは、一言で言えば、MJ+プロジェクトのゴールは、現在のMJ文字情報一覧表からこぼれ落ちる文字を、国際標準（IVDを含めて）と紐付けることですよ、紐付けられないものの新規符号化提案も含めて、ということになる。検討会の時に、つい、口をすべらせて「国際標準との整合性がゴールで、まあ、MJとの関係なんてどうでもいいんです」などと、文字情報技術促進協議会会長としては、いささか問題発言もしてしまったけれど。
で、田丸さんの「国際標準で標準化されていない文字が外字」という立場について、もう少し敷衍すると（田丸さん自身が記録映像で話していることだけれど）、現今の情報システムでは、広い意味での国際標準に準拠していないシステムは事実上、開発出来ない、ということになる。事実上、というのは、コストの面とWTO/TBT的な意味での非関税障壁という両方の意味を持っている。
逆に言えば、国際標準になってしまえば、前田さん的な意味での、MJとの整合性も担保できる（文字情報基盤としてMJ+への拡張を行わないという選択肢はない！）し、吉本さん的な意味での、相互互換性も担保できる。

符号化文字集合屋がやるべきこと

一つ前のブログ（水平拡張提案の公開レビュー）にも書いたことだが、国際標準は、専門家（コンテンツエキスパートとプロシージャエキスパート）が少人数で原案を作り、それに対するコメントを広く求めて、練り上げていく、というやり方が一番高品質なものを短時間で作ることが出来る（とぼくは信じている）。MJ+について言えば、文字の検討については、すでに、早稲田大学の笹原宏之を筆頭に、当協議会の仲間である京都大学の安岡孝一さんや国立国語研究所の高田智和さんも係わってきておられるみたいだし、プロシージャに関しては、JSC2のメンバーの多くが当協議会のメンバーとも重なっているので、こちらの方も役者はそろっている。敢えて難があるとすると、みなさん、いい人過ぎるんだよな。
村田真ではないが、国際標準化活動には、ある種の悪巧み、というか、手練手管が必要な場面がないわけではない。
今回のMJ+について言えば、スピード最優先。
標準屋の一部には、というか、多くは、ぼく自身も含めて、ある種の美意識を持っている。標準（Standard）というよりも規格（Specification）としての側面。全体として一貫性と整合性があり、不必要な文言がない簡潔で十分な記述、みたいな。
しかし、この辺りを追求していくと、結構時間と手間がかかる。特に、符号化文字集合は、相手が言語や文字であるだけに、そもそも、体系そのものに矛盾や不整合満載。特に、CJKパートは、東アジア漢字文化圏全体（チュノムを用いるヴェトナムも含む）に係わっているため、台湾や香港を含む中国語の地域差や、歴史的変遷もあり、もうしっちゃかめっちゃか状態。
そうした中で、日本の現代社会における人名・地名を表すために用いられる漢字を、情報システムで扱うために必要最小限の整合性（文字集合として、その構成要素が固有名（符号列）と排他的に結びついていること）を担保しつつ、可及的速やかに国際標準化することが必要になる。
この文字集合としての整合性を担保することが困難だという問題は、じつは、今に始まったことではなく、潜在的にはUCSがCJK統合漢字というモデルを採用したときからあった問題で、ぼくが故樋浦秀樹さんらとともに提案したVS(variation selector)というメカニズムも、統合規則と国や地域によって異なる字体の弁別粒度との折り合いを付けるためのものだったりする。
もう一つのキーは、UCSのAnnex A（部分集合用図形文字の組）というヤツ。
ここには、Unicodeの過去のversionに対応する部分集合から、日本の常用漢字に対応する部分集合にいたるまで、さまざまなレベル、さまざまな性格の部分集合が収められている。部分集合といっても、単に、UCSの符号位置（と符号位置の列）を列挙しただけのものなのだが、UCSの一部の符号位置だけを使って、UCSへの準拠性を主張するときには、とても便利。このAnnex Aの規定がないと、使いたいUCSの符号位置をぜ〜んぶ列挙しなければならない。ヤレヤレ。
JSC2では、ここ数年にわたって、このAnnex Aに、JISの漢字集合を中心に、日本の現在の社会で必要だと思われる部分集合を積極的に提案している。この動きは、ある意味では、JISの漢字集合の記述内容を、JISを用いずにUCSだけで閉じた形で記述することでもある。JIS意外にも、常用漢字字体表など、じつは、Annex Aのコレクションとして記載されるまで、国内規格も含め、公的な標準規格情報としては、UCSの符号位置との対応関係の記述は存在していなかった。（ちょっとややこしい話だが、JIS X 0213には、ある面区点位置が常用漢字に含まれるという情報はあるが、それが常用漢字表のどの字であるかは、印刷された例示字形をヒントにして、結びつけるしかない。しかも、その例示字形は、参考情報であって規格本文ではない！　とはいえ、現在の常用漢字表はMJ明朝体を用いて作成されているので、実質的には文字情報基盤文字情報一覧表の常用漢字についての記載内容で、UCSと常用漢字の対応関係は明確なのだけれど。）
一方、JISとUCSとの関係を見ていくと、ところどころ、包摂規準と統合規則のズレを中心に、矛盾する個所がある。
卑近な例を二つばかり挙げると、吉(U+5409, 1-21-40)と𠮷(U+20BB7,1-21-40)、髙(U+9AD8,1-25-66)と髙(U+9AD9,1-25-66)。括弧内の前の方がUCSの符号位置で、後の方がJIS X 0213の面区点位置。それぞれ、「土ヨシ」「はしごダカ」といった言い方で、姓などで区別して使われることが多いが、JIS X 0213では同一面区点位置に包摂されている。現状のJIS規格では、これらを区別して扱うことは事実上出来ないわけだ。
𠮷にしても、髙にしても、UCSに入っているのは、日本以外の国や地域から提案された結果であり、あくまでも日本の工業標準としては、吉と𠮷、高と髙の区別をしていない。（規格としての美しさ、という点では、これらの区別は、JIS X 0213の例示字形をベースキャラクターとして、VSで区別するのが理想的なのだけれど、今改めて文字情報一覧表を確認してみたら、現状ではIVDを用いずに、UCSの別符号位置を充てている。）
いずれにしても、今後のこととして、JIS X 0213では包摂されていて、IVDのコレクションで区別をしている字体が、他の国や地域から提案されて、別符号位置が付与される可能性は大いにありうることだ。このことは、日本の行政や社会生活上の漢字使用にとっては、大きな混乱の種となりうることだ。
パネルの際、吉本さんが強調しておられた相互運用性にとって、符号化文字集合に限って言えば、その文字集合が閉じている（集合論で言えばcompact setになっている）ことが、とても重要なことなのだ。
ところが、自然言語における文字は、変幻自在、国や地域、時代によって、さまざまに変化する。
そんなわけで、吉本さんと前田さんの立場の違いというのは、相互運用性のための文字集合としての厳密さを採るか、住民感情まで配慮した例外をも（ある程度）容認するか、といったところにあったのではないか。まあ、ぼくなりの偏見的独断かもしれないけれど。
現状のユニコードというのは、どちらかというと、前田さんの立場に近い。「だって、欲しいと言っている人がいるのだから入れてしまおうよ」みたいな。

随分と、些末、オタク的議論にはまり込んでしまったが。
上に挙げたような、地域や国、使用目的の違いによる、字体分別粒度の差異と、それに起因する文字集合としての破綻を最小限に留めるためには、できるだけ使用目的に則した部分集合を定めて、使用範囲をその部分集合に限定するのが手っ取り早い。
ぼくが、Annex Aにこだわっているのは、まさに、そのためなのだ。
このアーティクルの前の方に、MJ+の最終目的は、国際標準としてのUCSとの整合性を取ることだ、と書いた。しかし、もうお分かりのように、ゴールはもう一つある。Annex AにMJ+コレクションを追加すること。こうすることによって、中国をはじめとする他の東アジア漢字圏からの（日本の社会的要請とは衝突する）提案の影響を受けずに、相互運用性を担保することが可能となる。

日本の文字符号屋にも、まだまだやることがあるなあ。

UCS水平拡張提案公開レビュー

文字情報基盤文字情報一覧表の全ての文字名と例示字形を、UCSの日本ソース欄に記載する提案文書が、ISO/IEC JTC1/SC2に提出された。
同時に、というか、ちょっと遅くなってしまったが、情報処理学会情報規格調査会SC2専門委員会（以下、JSC2）と当社団との共宰での公開レビューが始まった。
多くの方に、提案内容を精査していただき、積極的にコメントをお寄せいただくことによって、国際標準の策定作業に直接かかわっていただくこととを願っている。

提案の背景の背景

この水平拡張提案のそもそものきっかけは、IRGで積極的に活動している中国のHenry Chenさんが、MJ文字図形名とUCS符号位置の現在の対応関係について疑義を呈する複数のコメントを寄せてくださったことに始まる。
このコメントの委細は、すでにこのブログに書いたけれど。

UCS水平拡張とパブリックレビュー

ざっと復習すると。
このChenさんからのコメントがきっかけになって、協議会の文字情報基盤委員会では、都合2回の内部レビューを行い、結果的には、40個所ほどの修正が必要と思われる対応関係と、さらに30個所ほどの「う〜ん、迷うなあ、結論はIRGに委ねよう」という対応関係を洗い出した。

その過程で、どうもMJ文字図形名とUCS符号位置との対応関係が、UCSの規格票に記載されていないのは、ちょっと（というか、かなり）まずいのではないか、という考えに傾いてきた。
先般行われた協議会総会の機に毎年開催される特別セミナーのパネルセッションで、協議会の事務局長で日本マイクロソフト社のNTO(National Technology Officer)でもある田丸健三郎さんも強調していたが、現今の情報通信産業では、広い意味での国際標準に準拠しない実装は、コスト面でもWTO/TBT的な意味での非関税障壁という面でも事実上不可能となっている。
一方、文字情報基盤は、現在はデジタル庁が所管しているベーシックレジストリの一つに指定されていて、いわば今後の行政の全面的なデジタル化に向けての公的な側面を持っている。
ところが、先にも記したように、文字情報一覧表に記載されているMJ文字図形の内、過半数の約3万文字については、現在、UCSの側には何の記載もない。MJ文字図形名とUCS符号位置の対応関係は、いわば、文字情報基盤の策定責任者（かつては独立行政法人情報処理推進機構、現在は、当協議会）が勝手に定めているだけなのだ。
ぼくも、文字情報基盤整備事業には、その立ち上げの時から、かなりディープに係わってきたこともあって、その全般的な品質（信頼性）を疑うものではないが、これほどの大規模文字集合になると、誤謬（バグ）の露見は、どうしても避けられない。UCSにしてもCJKパートにはいまだにバグが残っていて、それが、忘れたころに発覚したりしている。
Chenさんのコメントを契機として発覚したバグは、いわば、出るべくして出て来たバグだ、とも言えるわけだ。もちろん、当事者の一人として、忸怩たる思いはあるけれど。
しかし、この問題の本当の問題は、MJ文字図形名とUCS符号位置の対応関係にバグがあった、ということではなく、そのバグの処理方法にある。国際標準、特に、符号化文字集合規格では、一般に、バグが発覚しても、それを変更することは、原則として行わない。なぜなら、バグを含む既存実装にどのような副作用を及ぼすか予想がつかないから。だから、バグはバグとして残したままで、何らかの対応方法を検討する、というのが一般的な原則となっている。
しかし、今般のMJとUCSとの間のバグは、それを修正してもUCS本体には何のインパクトも与えない。その上、幸か不幸か、発覚したバグのほとんどは、日本の現代社会における人名や地名にはまず使用されることがないと思われる中国の古典籍に典拠をもつものだということも分かっている。そんなわけで、今回発覚したバグについては、文字情報一覧表そのものを修正しても、副作用はまずないと思われる。
とは言え、先に書いた田丸さんの言ではないけれど、いまや日本のデジタル行政の根幹の一つとなった文字情報基盤が、国際規格との関係を恣意的に変更することが許されるような現状は、（広い意味での）システムの安定性という点で、決して望ましいことではない。
この際だから、UCS本体にMJ文字図形名とMJ明朝体のグリフを記載してしまい、MJ文字図形一覧表全体を、UCSの側から規定できるようにしてしまおう、というのが今回の水平拡張提案の狙いなのだ。
いそいで付け加えておくが、MJ明朝体の現在の実装（誤謬と思われるUCS符号位置での実装）は、まさに後方互換性のために残しておくことになると思う。

公開レビューの背景の背景

提案は提案として、今回、JSC2と共宰で、提案内容そのものについて、公開レビューを行うことが出来たのは、ぼく的には、ものすごく嬉しいことなのだ。
小著「ユニコード戦記」（東京電機大学出版局刊）の前書きにも書いたことだけれど、標準規格は、天から降ってくる所与のものではなくって、規格策定に係わる生身の人間が、その激しく対立する利害関係も含めて、議論に議論を重ねて作り上げていくものなわけだ。もちろん、UCSだってその例に漏れない。現在では、UCSとほとんど同じと言っていい、ユニコードにしても、UCTが主体となって策定している部分（CJKパート以外のほとんどすべて）についてはもちろん、IRGでの議論を踏まえて策定されるCJKパートについても、UCSとしての国際投票の前に、部分的な提案も含め、ユニコードとして、公開レビューの機会を設けている。ユニコードが登録窓口となっていて、UCSとしては、その結果を追認するだけとなっているIVDについても、登録を受け付けてから、一定期間の公開レビューを経た上で、正式に登録公開する手順を踏んでいる。このあたり、公平性、公開性、といった点で、なかなかやるよなあ。
一方、ISO/IEC JTC1傘下のSCの中には、極端に言うと、国際規格を私物化して、まさに恣意的に規格の策定、変更を行っている例もないとは言えない。
もちろん、当協議会副会長の村田真の言ではないけれど、衆議一決、根回し万全みたいな日本的合意形成を待っていたら、国際標準化活動のスピードについて行けるわけがない、というのも事実。まあ、このあたりは、村田真の名/迷論文「だからわたしは嫌われる」（仮称）を読んでいただくこととして。
[https://www.jstage.jst.go.jp/article/johokanri/55/1/55_1_13/_article/-char/ja/]
多分、理想的なのは、その規格の本質的な部分についての専門家（コンテンツエキスパート）と規格策定の手続きを含めた専門家（プロシージャエキスパート）が少人数で協力してドラフトを開発し、それに対するコメントを広く受け入れる、といったやり方なのだろう。
今回の水平拡張提案のきっかけはChenさんという中国の専門家からのものだった。このこと自体、ものすごく、嬉しく、かつ、意義深いことではあるのだけれど、日本の人たちにも、文字情報基盤やUCSについて、もっと自分事として関心を持ってもらいたいなあ、という思いも、またホンネ。
ちょっと、というか、かなり大きなファイルではあるけれど、ダウンロードしていただいた上で、へえ、こんなことやっているのだ、こんな字もUCSには入っているのだ、といった関心だけでも持っていただければ幸い。そして、このデカいファイルの背後には、日々、文字と格闘しているエンジニアや研究者がいることに、チラリとでも思いを馳せていただければ、もっと幸い。

木田泰夫さんがJSC29へのリエイゾンに決定

情報処理学会情報規格調査会SC29専門委員会（以下、JSC29）に対する本協議会からのリエイゾンとして、木田泰夫さんが参加してくれることが、正式に決定した。

JSC29は、主としてJpegやMpegなどの静止画や動画に係わる国際規格を担当しているが、なぜか、Open Font Format(ISO/IEC 14496-22)というフォントに係わる規格も担当している。しかし、仄聞するところだとJCS29にはフォント技術のエキスパートはおいでにならない、とのこと。そりゃそうだ。動画関係の技術とフォント技術では、だいぶ事情が異なるからね。

一方、ほとんどのベンダーが、当協議会のメンバーになっているフォント業界は、従来からOpenTypeの規格内容を実質的に仕切っているMicrosoft社やAdobe社から提供される技術情報を直接用いてフォント開発を行っており、国際標準化活動という意味での関与は行ってこなかった。

しかし、えらそうなことを言うようだが、国際規格というのは、天から降りてくる神の声のようなものではなく、その技術に係わる当事者たちが、グローバルな公共性、公平性を維持しながらも、それぞれの利害をぶつけ合って作り上げていくものなのだ。とまあ、こういう偉そうなことも、ぼく自身がSC2（UCS、ISO/IEC 10646）やUTC（Unicode Technical Comittee）の活動を通して学んできたことなのだけれど。

というわけで、協議会の会長としては、フォントベンダー各社にも特に若いエキスパートに、与えられた規格を唯々諾々としてうけいれるだけではなく、規格の問題点を積極的に指摘し、出来れば、特に日本語の表記に係わる新たな提案をしてもらいたいなあ、と日ごろから思っていた次第。

そんな折、例の村田真が、アクセシビリティの方から、Open Font Formatにも興味を持ち始めて、現在のJSC29の状況にも気付いた、というわけ。

公的国際規格策定の場でも、日本のフォントベンダーの意見を反映できるパスを通せないか、とJSC29の関係者ともいろいろ相談した結果が、木田泰夫さんにリエイゾンとしてJSC29に参加してもらう、という妙手だった。

フォントベンダー各社が、独自に情報規格調査会の会員になって意見を言えばいいではないか、という考え方もあるにはあるが。ここには、日本の公的技術標準への関与のしかたそのものの大きな問題がよこたわっている。

情報規格調査会は、経産省からの補助金も得ているが、基本的には、会員各社が負担する会費でまかなわれている。これが、結構高額なので。従来は、それこそ、日立製作所や富士通、日本電気、MicrosoftやIBMといった大企業が金も出す、人も出す、という形で係わってきたが、フォントベンダーはごく一部を除いて、ほとんどが小規模で、とてもではないが、金の面でも人の面でも、日立や富士通の向こうを張るような芸当は出来ない。もちろん、CITPCにも、独自の予算で情報規格調査会の会員になるなどとは、夢のまた夢。

一方、SC2についても言えることだが、文字符号やフォントは、単なる《技術標準》では解決できない文化的、社会的要件が深く関わってくる。価値中立的な技術的議論だけでは、いかんともしがたいのだ。

木田さんのJSC29へのリエイゾン参加というのは、このような閉塞的な状況を打破する可能性のある、妙手というか、ちょっとしたクリーンヒットなのではないか、と自賛する次第。

言い忘れていたけれど、リエイゾンというのは、元々は軍隊用語で、連絡将校のこと。標準化活動の世界では、利害が関係する団体やグループ間調整役のような位置づけになる。オブザーバーとは、わけが違うのだ。

木田泰夫さんのこと

ぼくが書きたかったのは、こんなややこしい国際標準化の現場の話ではなくって、木田さんご自身のこと。というか、木田さんとは、村田真ともども、もう長いお付き合いだしね。

木田泰夫さんの知遇を得たのは、ずいぶん以前のことだ。といっても、あまり以前のことで、記憶も定かではない。

「ユニコード戦記」にも木田さんは登場していて、UTCに対して、Variation Selectorの提案をしたころ、ルビタグも問題になっていて、ルビタグが理解できない処理系がルビタグを読み飛ばしてしまって、結果的に平文になった場合、意味が真逆になる絶妙な例をひねり出してくれたのが木田さんだった。樋浦秀樹さんも含め、三人でほぼ徹夜で二つの寄書を書き上げたことを、昨日のように覚えている。「ユニコード戦記」の記述では、1998年2月のこと。

同じ1998年には、東京でInternational Unicode Conferenceが開催されていて、このカンファレンスの後、樋浦さん、村田さん、檜山正幸さんと、確か「Unicodeは怖くない」といったタイトルで月刊ASCII誌上で放談会みたいなものをした記憶がある。

この月刊ASCII誌上での放談会は、檜山さんが、当時ASCIIの編集部にいた西村賢さんを引きずり込んで企画してくれたもので、何度か行われた。この一連の集まりに、木田さんも参加したことがあったように記憶している。そのころって、まだ木田さんはクパチーノの本社ではなく、日本のオフィスを拠点にしていたように記憶している。

いずれにしても、このころ木田さんの知遇を得たことは間違いない。

その後、木田さんは拠点をクパチーノのアップル本社に移して、仮名漢字変換機能の実装や日本語フォントの調達だけではなく、Macを初めとするアップルの諸製品の日本語関連を含む国際化の中核を担っていくことになる。

UTCやSC2のために西海岸に出張した折に、樋浦さんと共にミーティングに参加したり、一緒に食事したり。ベイエリアにはいろいろな日本食屋があり、徳島ラーメンの店もある。だけど、ぼく的には、そのころはジャストシステムの社員だったし、ジャストシステムの本社は徳島だし、いくら木田さんが旨い旨いと言っても、ちょっとなあ、という気分で、樋浦さんともども、お二人に本場の徳島ラーメンをご馳走するために、ジャストシステムの招待したこともあった。

あと、忘れられない思い出は、2010年の10月に台北で開かれたEPUB関連の会議の折、村田さんも含めて、3人で鼎泰豊で、この年の4月に急逝した樋浦さんの思い出を語り合ったこと。

このころの木田さんは、EPUBの日本語機能の前提となった「W3C技術ノート日本語組版処理の要件」とオープンソースとして開発されていたWebKitの実装とすりあわせの場面で、大活躍をしてくれていた。

国際標準を含め、一連の要件を策定するとき、策定する側があまり実装局面での制約や既存のシステムのことを忖度することは、好ましいことではない。旧来の方式の問題点を引きずってしまったり、システム全体としての整合性や効率を毀損してしまうことが多々ある。かといって、机上の空論ではだれも実装してくれない。

W3Cでは、このような状況を避けるために、最終的なrecommendationとする前に、最低限二つは実際に動く実装が存在することを求めている。

EPUBのときも、仕様制定と並行して、WebKitにおけるCSS縦書き実装が進んでいた。この実装がなければEPUBとHTMLの縦書きはどうなっていたか分からない。縦書きの電子書籍はなくなっていた可能性もある。

そんなわけで、村田真も木田さんには頭が上がらないわけよ。

そんな木田さんが、日本の高校に進学したお嬢さんの弁当作りのために、出身地の京都に戻ってきた。「EPUB戦記」によると、2015年9月に、帰国準備のために一時来日していた木田さんを含めて、会食をしている。

そして、2017年。講談社、小学館、集英社、KADOKAWAの出版大手4社と電子出版のメディアドゥがスポンサーとなって、慶應義塾大学藤沢キャンパスに、Advanced Publishing Laboratory（以下、APL）が設立される。

このラボの大きな目的の一つに、SFCにあるW3Cホストを通して、日本の出版界からの要望をW3Cの関連ワーキンググループのインプットすることがあった。

ぼくは、「日本語書記技術」のワーキンググループの座長を引き受け、村田真とも語らって、木田さんにもメンバーに加わってもらった。

このワーキンググループは、二つの側面を持っていて、一つは、「日本語組版処理の要件」の批判的継承、もう一つは、旧来の紙の出版物が500年余りにわたって担っていた社会的役割を継承する未来のドキュメンテーションの在り方の模索。

あたりまえのことだけれど、後者の議論は、既存の出版界の（したがって、スポンサー各社の）在り方に対して、批判的にならざるを得ない。というか、ぼく自身は、かつての電子書籍コンソーシアム時代やEPUB戦争時代のことも含め、　日本の出版社の電子出版に対する取り組み方には、常々批判的だったわけだけれど。

そんなわけで、日本語書記技術WGは長くは続かなかった。

で、前者の「日本語組版処理の要件」の批判的継承の方は、出版業界のみならず、まさにデジタル通信技術時代の日本語の在り方全般に係わる重大な問題でもあるし、日本語のみならずグローバルなW3Cのアクティビティの中でも、JLreqのアプローチはある種のロールモデルみたいになってしまってもいたので、APLの活動とは切り離して、W3Cの正式なTask Forceとして仕切り直すことになった。

ここでだ。ついに揚げ幕がチャリンと鳴って、花道から木田泰夫議長が登場。「いよ〜、竹屋あ〜」

※木田さんの京都のお住まいは、竹屋町に接しているのでね。

せっかく、アップルを退社して、ハッピーアーリーリタイアメントのつもりだったようだけれど、へへへ、またも舞台に引きずり出してやった。

で、このTask Forceについては、昨年実施されたJEPAのセミナーがなかなかよかったので、このヴィデオを見ていただくことにして。

フォント規格の闇

ぼくは、昔からフォントがらみの話題が苦手だ。内輪話めくが、文字符号屋とフォント屋は、どうも人種が違うような気がする。ぼくは、たぶん文字符号屋なのだが、フォント屋の典型はたぶん副会長をお願いしているアドビの山本太郎さん。太郎さんとの付き合いも長くって、彼がまだモリサワにいた30年以上も前からの知り合い。ぼくがジャストシステムに入って、大地という当時最先端のDTPシステムの製品企画を担当していたころから。

いずれにしても、フォントというのはある種の美的素養が係わっていて、美しいとか美しくないとかいったレベルの議論が大きな割合を占めるようだ。で、ぼく的には、ここらあたりの議論がどうにも苦手なわけ。フォント屋さんというのは、美意識とも係わりがあるのだろうが、文字の一点一画への拘りがまた半端ではない。例えば、文字情報基盤の文字情報一覧表では、ぼくの名前の一部でもある《龍》の字の最初の一画が、縦棒になっているのと横棒になっているのとに、それぞれ別の文字図形名が付けられているが、本人が言うのも何だが、まあ、どっちでもいい、と思っている。ぼくも昔編集者の端くれだったが、編集者の中には、縦棒の《龍》は品がないから使わない、とかのたまう現役の編集者もいたりして。

閑話休題。フォントの議論になると、どうしてもどのように符号化するか、ということよりも、どのような字形にするか、ということに重きが置かれるような。

そのせいかどうか、フォントフォーマットについては、今まで、規格としての美しさというか整合性の議論があまりなされてこなかったように見受けられる。このあたりからは、文字符号屋から見てもこれまた異人種であるゴリゴリの規格屋である村田真からの耳学問が多くなる。

昔から、フォントフォーマットにはWindows系とMac系の二つの大きな潮流があって、それぞれ独自の進化を遂げてきた。それが、あるときから、相互に使われるようになって、今の国際標準となっているOpen Font Format も、このWindows系とMac系のフォーマットを呉越同舟のような形で一緒くたにしてしまったために、ある視覚的な機能を実現する方法が二つならずいくつも存在する、といった状況になっている。カラーフォントにいたっては、三方式が併存しているとか。

まあ、中身については、おおむねMicrosoftの専門家とAdbeの専門家が話し合って決めているのだが、公的標準としてのOpen Font Formatは、SC29という本来はJpegやMpegなどの静止画・動画フォーマット周辺の規格を担当するSCが担当していて、SCとしての議論もほとんどないままにラバースタンプを押す、といった状況になっているらしい。書き足すなら、Microsoftは、Open Font Formatと同じものを、OpenTypeとして出版し続けている。

まあ、ぼくの主戦場である文字符号の世界でも、あまり偉そうなことは言えず、特に、利用者が非常に少ない言語に係わる文字(minority script)や、歴史的な文字(histric script)については、日本国内の専門家へのアプローチもままならないままに、UTCのエキスパートにおんぶにだっこのままで、ほとんど無批判に賛成票を投じているような現実もあるのだけれど。

背景説明が長くなったが、やっと木田さんの話に戻れそう。

JSC2にフォントにもわがCITPCから標準化活動にも通暁した専門家を送り込もう、と考えたとき、もうぼくたちの頭の中には、木田さん以外の名前は浮かんでこなかった。

木田さんは、どうも、規格屋でも文字符号屋でもフォント屋でも、なさそうなのだ。

あえていえば、「竹屋あ〜」。

アップルにももちろん、規格屋もいれば、文字符号屋もフォント屋もいるわけで、木田さんは、そんな一癖も二癖もあるエキスパートたちをうまくコントロールして、現在のMacやiPhoneの日本語関連機能を、アクセシビリティをも含むグローバル、ユニバーサルな機能の中で、調和的に実現してきたわけだ。

そんな木田さんを、リエイゾンとしてJSC2に送り込むことが出来るCITPCって、なかなかなもんだなあ、とまたも自画自賛で今回はチョンチョンチョンチョン。