本記事は、アーカイブに保存されている過去の記事です。最新の情報は、公益社団法人日本印刷技術協会(JAGAT)サイトをご確認ください。
独立行政法人 情報処理推進機構
オープンソフトウェア・センター センター長 田代 秀一 氏
2011年10月に、文字情報基盤に関するフォントや文字の一覧表の正式版を公開した。
もともと経済産業省で7年間進めてきた文字に関する調査で、文字のフォントを作成して実用できるようにする事業を経済産業省からIPAが受託した。
経済産業省の事業として行われたものをIPAが受けて、現在はIPAの事業となって進んでいる状況である。
経済産業省でこの事業を始めた理由は、文字を巡る課題は過去からずっとあり、特にコンピュータ化された70年代、漢字がコンピュータで出るようになったのは80年代以降かもしれないが、電子化のとき、文字セットをどのように設定するかなどについて常にいろいろなことが繰り広げられてきた。
そういった文字を巡る混乱をいかに解決して、統一的で便利な電子計算機上の文字の環境を作っていくかという意識から進められたものである。
最終的には電子行政をうまく推進すること、情報産業などいろいろな産業の中で効率的にコンピュータあるいは文字が活用されることを狙っているものである。
今回の第一の目的は電子行政、行政コストを削減し、行政の中での機器その他のシステムの調達コストを下げることを目的にしている。
そのために字をしっかりと識別できるように、統一的な文字の一覧表を作成し、それをインデックスとして活用することで、既に作られている多様な文字の体系の間での相互接続を効率的にできるようすることが第一の目的である。
例えば電子申請などで正しい氏名が表示送信できたり、一般の方のパソコンでも新しい文字、複雑な文字が使用できたり、政府や自治体の中のシステムは多様なので、その間でも接続できるようにすることである。
そのためにフォントを作成し、使用できる環境を整えることと、一覧表を整備してインデックスとして使用できるようにすることが2つの大きな目的になっている。
それから、文字そのものをどうやって管理していくのか。増えたり減ったりするし、運用上字が多ければいいというわけではないので、どういう運用をしていくのがいいのか。
あるいは、文字の符号化に関しても、どういうやり方をすると国際標準との間での矛盾が起きないかといった視点から最適な文字の活用についての検討をいろいろ行った。
この辺は経済産業省の問題意識だが、企業と行政機関や、行政機関と行政機関などで電子的な手段によって情報交換が行われる機会が増加傾向にある。
特に今回、震災で東北地方が大変な被害を受け、これまでの経験にない、広域に渡った避難、県を越えて避難の人がどこか別なところへ移るということが起きている。そのようなときに、自治体間での情報の連携やバックアップなどが非常に深刻な問題になった。このときも常に文字の非互換性がつきまとい、業務コストを引き上げることとなっていた。
このように、電子的に文字を扱う基盤をどのように再構築していくか、問題となっている。
この事業を進めることによって、フォントに絡むいろいろなビジネスあるいは印刷など、文字を直接コンピュータ上に出す以外のいろいろなビジネスの活性化も期待できる。
そのようなことを経済産業省として判断されたのである。
文字を巡る環境だが、いろいろな価値観やその他の目的で、文字を使っている。もともとは情報交換で、何か意思を伝えるときに使用するのが文字の目的だが、個人のアイデンティティとして正確に表記することが、例えば住民にとっては非常に重要な文字の用途になる。
そうすると、同じ「ワタナベ」さんでも、こちらのワタナベさんとあちらのワタナベさんでは使っている異体字が違っている。情報交換という意味では、「ワタナベ」で別に呼び方が違うわけでもないが、ただアイデンティティとして、自分はこうで先祖から引き継いでいるとして表記する。
一方で、コンビニでも簡単に住民票を取りたい、行政コストを下げるべきだという目的も意識も住民は持っている。これは相反することになるが、どうやって折り合い付けるかが問題になる。
企業も、もちろん業務効率を落とさないこともあるが、必要な字を必要なだけ使った上で落とさないことも大事な問題になる。それから、行政機関などが、電子申請などの要求水準に対してどう対応していくかも大事な課題である。ある意味、企業活動で、効率的という観点から言えば、現在使われている文字がもっと増えるのは面倒でコストが上がるのではないかという考え方もある。
行政機関側の問題意識から見ると、個人のアイデンティティ、先祖代々の字をそのとおり印刷して住民票に書いてほしいなどの住民の要望に応えていくような、住民サービスとして正確な字を使えるようにすることである。
もちろん戸籍などの記録を使って個人を証明をしていくことも大事なので、正確さが当然求められているが、一方で行政効率ももちろん求められている。
今回、震災の被害の場所や行政現場も見てきたが、例えばGISシステムに、地図の上に住民の被害状況がきれいにマップして出てきて、例えば浸水エリアがこれぐらいで浸水領域の中に何人要介護者がいるのかといった情報がすぐに出てくるようなシステムが整備されていたりする。
ところが、そこに住基台帳の文字のデータを流しこむと文字化けしてしまう。出ない字もたくさんあって、住所や名前が黒丸になっているところがあるが、実用上、全く使えないわけでもないのでそのまま使っているのが現状である。
そういった現場も、そんなに字を拘らずにもっと少ない文字セットにしておけば、文字化けなどは起こらないで、もっと行政コストは下がるはずだし、災害対応も迅速にできたはずだが、そのあたりが非常に大きな矛盾点で、住民が正確に使えるように作った住民台帳システムが、実は被災者支援の緊急的に必要な業務に対しては足を引っ張る結果を招いている。
行政コストを落とさないで、特に緊急時などの迅速な作業を支えるにはどうしたらいいかなどの需要もあり、両方で足を引っ張り合っている。
従って、適材適所で文字をどう使っていくかについてガイドラインをきっちり決めていくべきだという問題意識も強く持っている。
いろいろな要望がある中で、実際、これまで日本では公的な目的で使われている文字の体系が複数あった。常用漢字は基本的な文字セットで、文部科学省から一覧表として提示されている。これが一番基本的な文字セットになるのだろう。それから、表外漢字で、それを越えたものに関する文字セットが規定されているし、人名漢字も法律的に規定されている。
情報交換用という観点からいくと、JISの文字セットが1万文字ほどある。それから、漢字検定の字なども6,000字くらいあるらしい。こういうものも文字セットとしてある。これは法律的なものではないが。
それから戸籍統一文字という、法務省が定めている文字セットが5万文字くらいあるし、住基統一文字、正確に言うと住民基本台帳ネットワーク統一文字という文字セットが2万文字くらいある。
このように、それぞれの目的で文字セットがいろいろと規定されているのが現状である。これを用途に応じて各自治会や企業などが使っている。ただ、IPAmj明朝ができるまでは符号化されていないので、住基ネットは住基ネットの独特な符号で文字が符号化されているが、戸籍に関してはコンピュータでそのままフォントとして使えるような文字符号が付いていないので、一般にコンピュータで使うときにはいろいろ苦労も多かった。
先ほど、アイデンティティと情報交換性という話をしたが、例として「ワタナベ」の「ナベ」を出してみた。常用漢字というと、「辺」の字1つになるが、JISだともう2つあって、住基ネットワーク統一文字だともっとたくさん字があって、さらに戸籍になるとさらに別の形がある。
図5の例は、戸籍文字のセットにしかない文字と、住基の中にしかない文字、JISにしかない文字と包含関係になっている。こういう形で、それぞれどの範囲でどんな異体字が利用可能になっているかがまた違っていたりする。
図6は異体字に関する需要がどれくらいあるのかという1つの例で、衆議院のホームページである。衆議院のホームページに行くと、トップページの左下にメニューリストが並んでいるが、その中に「正しい表記はこうです」というようなお詫びというか説明のページがある。
要するに、普通にインターネットで皆さんが見られるようにするためにはJISの範囲内で文字を送る必要があるが、その範囲に入っていない異体字を名前の中に使われている議員が結構いらっしゃる。
その方については、ホームページで、「JISの範囲である字に置き換えられているが、それは本当はこうである。本当はこうなんだけど、ごめんなさい」というようなページがあって、例えば菅直人さんなども「直」の上の角度がJISで普通に使われている字の角度と違っている。
この例は結構多くて、田中真紀子さんの「真」の字もそんな例である。いろいろな異体字を皆さんお使いになっていて、衆議院全体でいくと5%の方がJISでは使えなくて、かつ、「本当はこうだということを主張してほしい」と言っている。
おそらく、投票のときに違う字を書いても、「それは無効としろ」とまでは言わないと思うが、普段いろいろなところで使われるときは、JISの字ではない別の字が本当の字であることを大事にされている例である。
世の中全体も、衆議院議員の中も5%がそういう文字に対する表記上の困難を持っておられるので、一般的に国民全体もおしなべて5%ぐらいだろうと、そんな予測があったりする。
現状、電子申請でどういう文字セットが使われているかというと、e-Gov電子申請システムという、いろいろな省庁で共通的に使われているシステムでは、JISの第二水準までに限った文字を使う規定になっている。それから、確定申告などを電子的に行うe-Taxは、基本的にUnicodeのUTFの、あるセット範囲内の文字を使うことに規定されている。
また、警視庁のインターネット申込みのFAQを見ると「外字は入力できないのでひらがなで入れてください」とある。これは警視庁の採用のための、電子申請の電子申込みのページらしいが、そんなことが書かれている現状である。
いろいろな問題を解決していくために、実際コンピュータでどう使っていったらいいかを検討する文字情報基盤推進委員会が設けられた。これは、2010年に経済産業省の事業として文字情報基盤整備事業を行ったが、その際、いろいろと意志決定をしていくために、このような委員の方々を集めて検討した。
いろいろな業界団体の代表者、日本印刷産業連合会にも印刷技術協会にも委員として出ていただいているが、印刷関係の方や、電子デバイス関係の方、ソフトウェアの方などに委員として出ていただいた。
それから各省庁、内閣官房。これは政府全体の、例えばIT調達などの戦略を立てていくべき任務がある。それから総務省。総務省とはいっても中はたくさんあって、元自治省と元総務省、中央官庁の調達などを管轄するところもあるが、その辺の方々に来ていただいた。それから法務省は戸籍や外国人登録などになる。
それから文字に関する責任を持っておられる文化庁や二次的な産業関係で経済産業省からも委員として出ていただいて、その他、多様なところからオブザーバとしても出ていただいている。こういったところでコンセンサスをとりつつ決めてきた。技術的な方向性や、制度的な方向性について、いろいろ議論をいただいた。
今回収録した文字の対象は、戸籍統一文字と住民基本台帳ネットワーク統一文字の全体を包含したもの、これを1つの目標としている。戸籍と住基ということで、一応、人名に関してはほぼこれで網羅できるだろうと考えている。
ただ、もう1つ法務省で取りまとめている文字に、登記統一文字がある。これは会社の名前や、いろいろな登記関係で使える文字セットで公開されている文字セットだが、これはとりあえず対象としていない。
新日鉄の「鉄」という字はちょっと変わった字になっていて、これは戸籍のほうではなくて登記のほうにあるが、今回、まずは人名に関してきちんと処理できるようにし、登記は対象から外している。
それから、漢字に対象を絞っている。例えば変体仮名が住基文字や戸籍文字に入っているが、変体仮名については対象としていない。住基の漢字2万1,000字と、戸籍の漢字5万6,000文字、これを足すと同じ字が重なったりするので、6万7,000文字くらいになった。
今回の1年間の事業でこれを全部整理したわけではなくて、その前に7年間ぐらい先立つ調査事業が行われた。これは、こちらで言っている文字セットと、住基で言っている文字セットと、同じ字なのか、違う字なのかは結構難しくて、2つを合成したときにどういう文字セットにしたらいいのかは結構大変である。
それを同定して、「これとこれは同じ字だ」というようなことをすべて整理した汎用電子情報交換環境整備プログラムがあり、調査事業として文字の整理を行った。
それが前提となる経済産業省からの成果物となって、漢字情報テーブルが作られた。これを元にして、さらにフォント化する。一部、文字を増やしたりしたが、フォント化するというのが、今回の文字情報基盤の事業である。
成果物としてOpneTypeフォーマットのフォントを作り、ある程度品質の高い文字として、現場の行政業務で使えるような品質の字を作ろうとした。あくまで行政の現場でプリントして出すくらいのことを対象としているので、一般の出版物や、ちゃんとした印刷物に耐えるようなところまでの品質は追求していない。それぞれの出版社その他での美しい文字は、文字として、そういう商品として、それぞれ別々に流通させていただくのがいいという考え方になっている。
文字をフォントとしてコンピュータで使えるようにしただけではなく、文字の一覧表も作った。図11は、一覧表の中にどんな項目が書かれているかを出したものである。
文字図形名ということで、すべての文字にユニークな番号というか、名前を付けている。名前は大事で、「あの字とこの字はそっくりだが、どうしようか」というときに、「あの字」はどれを指しているのか、それが今後きちんと一覧表の図形名を使えば言えるようになるので、今後、字に関する議論、例えばもっと字を減らそうというとき、「この字とこの字とこの字は要らないだろう」というとき、それはどれとどれなのかがきちんと指せるので、今後の作業も非常に有効な情報になると思っている。
図形そのものや、図形のバージョン、過去に行われたプロジェクトでの整理番号、あるいは、大事な情報としては他の体系、住基ネットの上ではどんなコードになっているのか、UCS、ユニコードではどんなコードになっているのか、戸籍ではどんな番号が付けられているのかなど他の体系との間の対応関係を明らかにするような情報も入っている。
読みや、辞書的な情報、これは常用漢字なのかどうなのかといった政策的な区分などの情報を入れている。
これはあくまで初期状態としてこういう表を用意したが、今後入れる項目については必要に応じて拡大することで考えている。
運用についてだが、IPAのサイトから文字の一覧表やフォントなどの情報をすべて無料で提供している。
ただ、今後のメンテナンスなどのお知らせをすることもあって、任意ではあるが、アンケートなどで登録を行っていただくことをお願いしている。
また、簡易検索システムも整備しており、字を調べるときに役に立つような環境も提供している。
このようにいったん文字が整ったが、今度はそれを自治体や政府機関へ実際に広げていかなければならない。字に関しても、今回外国人登録の文字がまた新しく追加されたなどいろいろな変化があり、それらに対応することも継続的に続ける必要がある。
2010年の4月からの2011年度だが、その前に文字を整理したプロジェクトの後継プロジェクトとして文字情報基盤推進委員会を実施することにしている。
今回はさらに政府にきちんと整えていくことで、委員会の運用主体を内閣官房IT室、経済産業省、情報処理推進機構(IPA)との三者の連携で委員会をホストする形をとっている。
その中に、関係省庁の方や、有識者に入っていただく。それから、技術的な検討などを行うワーキンググループを分野ごとに3つ設けている。検討の議事録などは、URLに入っているので、適宜ご参照いただきたい。
2011年度の新しい文字情報基盤推進委員会では、東京大学の須藤先生を委員長にお願いしている。須藤先生は電子自治体や電子政府に対して非常に知見が豊かな方で、特に総務省系などではよくいろいろな委員会の委員長、座長をされている。それから文字に関する専門家の方や、自治体の方、それから各省庁の方に入っていただいている。
IT戦略本部から出されている「新たな情報通信技術戦略」の工程表がある。この中で、文字に関する施策はこういうタイムラインで進めていくことになっていて、この先には、例えば国民IDとどう結びつけていくか、その活用にどう役立てていくかなども出てくると思う。
2011年の8月に、電子行政推進に関わる基本方針が、高度情報通信ネットワーク、IT戦略本部から発表され、この中に文字情報基盤の活用が掲げられている。2011年8月に文字基盤が政策の中にきちんと明記されたことになる。
「仕組みを検討していく」と書いてあるが、正式版が出たのが10月で、この本部決定が出たのが8月だったので、この時点では仕組みを検討するという書き方になってしまった。これは事業の進み具合がこれに間に合わなかったという背景だと聞いている。
全体の章立ては重要施策の推進の中の位置付けてあり、その中の、国民ID、企業コードなど電子化を進めるに当たってのアイデンティファイをどうするかという話の中の1つとして、国民IDと企業コードと文字情報基盤を進めるべしという位置付けで入っている。
これは、経済産業省が主になっているが、事業そのものは総務省の事業を紹介したものがある。総務省で、自治体クラウドの円滑なデータ移行等に関する研究会というのが、2011年度進められている。
これは、自治体などの行政コストを削減するためにクラウドを活用するべきだと総務省が言っていて、自治体クラウド実証実験を実施しているが、それをさらに進めるために、外字、JISコード等に入っていない字、標準に入っていない字を、各自治体がそれぞれ別個に作成しているので、これがまた自治体間の相互連携に非常に障害になっている。これをクラウドでいろいろ情報をまとめてこようとすると、さらに障害になる。
そこで、実際、外字を各自治体がどれくらい作っていて、どんな状況になっているのかを、しっかり1回整理しよう、把握しようということを、調査事業として行っている。
この調査は、当初はすべての自治体から外字を集めてきて、それを自分達で整理しようと考えたそうだが、結果としては、IPAのmj明朝、文字情報基盤の文字を突合先として、各自治体が作った字が文字情報基盤の漢字のどれに相当するかを突合していく作業とになっている。
2011年度中に結論を出すことで、今着々と進んでいる。先日の中間報告会では、各自治体からコンピュータの中に登録してある外字を提出してもらい、全自治体というわけではないが、それをIPAmjの文字図形名のどれに相当するかをやっている。
そうすると、幾つかはIPAmj明朝の中のどれにも該当しない文字が出てくることもありうる。それがどれくらい出てくるのか、それは本当にそのままの字を維持すべきなのか、それとも他の字に置き換えるべきなのか、またさらに議論を進めていくと聞いている。そういう文字情報基盤の漢字との間での突合作業を続けることになって、総務省でも我々の字を活用していただいている。
それは中央の総務省としての施策だが、その他、各自治体で自主的にmjの文字一覧表を使った新規システムの開発に着手しているところも幾つか出てきている。そういう普及へ向けた動きが各地で始まっている状況である。
経済産業省見解として、例えば、今実際使われている字を全部置き換えるのは現実的ではないので、それを目指すべきではないとの考え方を持っている。やはり、複数のシステム間で連携するときの基準として、一覧表を活用してほしい。
既に持っている字が一体どの字なのか。これをいったんIPAmjの番号で認識すると、それを他の自治体も同じことをやると、自治体間で連携するようなとき非常にうまくいくので、そういう連携のための基準として使っていただきたい。
例えば、ある自治体がこういう外字を使った人の文字を別な自治体に送ろうというとき、「この外字はうちの自治体は持っていない」と思ったら、「これはmjの何とかですよ」と教えてあげると、これをそこからダウンロードして外字に登録して自分のシステムでも使えるようになるとか、こんな使い方がとりあえずは現実的な使い方ではないか。全システムを新しい体系にすべて置き換えるのは、10年かかるかもしれないし、100年かかるかもしれない。
さらに、実際に字を使いやすい形で各自治体、省庁へ広げていくにあたっては、字が多ければ多いほどいいのかというと、多いと選ぶのが大変だし、微妙に違う字があり、かえって不便であることもあり得る。
従って、適材適所でうまく文字セットの大きさをコントロールし、適切な文字セットを使うようにやるべきだろう。例えば学校で名簿を作るとき、「本当の字はこうだが、普通使うのはこっちでいいだろう」ということで、簡単な字のほうにして、普段はそちらを使うようにすることで利便性を増すなどよく検討しようとと呼びかけている。
現実問題としては、例えば中学校などで、受験票、受験の申請をどこかの高校などに送るとき、戸籍と同じじゃないとはねられることもある。そういう場面では学校の中での名簿などをしっかりした戸籍と同じ文字で作っておく必要があるとも聞いている。
そうすると2本立てになると思うが、そういうことをして、字の使い方をよくコントロールしていくのがいいのではないかと考えている。その辺の、文字の利用のガイドラインについては、小林さんが非常に高い知見を持っていて、小林さんが中心になって作成しているのである。
文字の利用ポリシーや、同定基準、あるいは違うポリシー間で、文字セットの大きさが違う間でどうやって連携するのがいいのかは技術的な問題もあるので、それらを今後慎重に、かつ大胆に検討していく必要がある。
ポリシーをきちんと考えたほうがいいという話をするときに、例えば、違う字として明確に住基文字などでは区別されていても、ここに筆押さえがあるかないかの違いだけというのもある。「こんなのどうでもいいだろう」と言うと、場所によっては殴られるが、逆に別の場所によっては「これを区別しろ」と言ったら殴られる場合もある。こんな感じだから迷うので、一覧表がある。
「盾」の字も、縦棒の角度が違う。これは垂直だが、これは少し斜めである。文字の専門家に言わせると、「これは単に文字の角度がほんの少し違って、ビットマップ的にはわずかな違いだろう」となる。
ただ、書き方が違っているとは、「その字の大元の由来に関わる非常に重大な違いかもしれない」などで、ビットマップ的に類似度が高いからといって、字として類似度が高いかどうかというのは別な問題である。
そういうこともあり、「こんなの、1個でいいじゃん」などとは非常に慎重に言わないといけない。まさにどういうところでどう使い分けるか、ポリシーの問題というのが自ずとここえ明らかになってくる。
この辺までが字の政策に関する経済産業省としての説明である。
ここからは技術的に、実際に文字を作成することを担当したIPAとしての説明になる。
(1)公開中成果物の概要/公開物ライセンス
どんなものができたのかだが、IPAmj明朝を置いてある。55,267文字の戸籍文字と住基の19,432の文字、これを大体6万文字くらいにしてある。ただ、これは漢字で、その他、かなやアルファベットもあるので、若干多くなる。
国際標準に則って符号化しているが、まだ符号が付いていないものが7,000文字ほどあって、これはコンピュータ上では外字という使い方で使うしかない。フォントの中には字形情報は入っているが、符号化、テーブルの中に文字コードを入れていないので、普通のやり方で文字の字形にアクセスすることはできない状態である。
要するに、無駄な情報としてフォントのファイルの中に入っている。それは、よく技術のわかる人ならその字を取り出せるが、通常のやり方では、その字は単に無駄なデータとして入っているだけになる。ただ、無駄なデータが入っていても有害ではないので、フォントの中にデータとして一緒に入れている。
それから、文字情報一覧表を提供しており、先ほど紹介したような文字のいろいろな情報を一覧表の形で提供している。また、報告書とは、「文字はこんなふうに使うといいのではないか」などいろいろな方からいただいた意見などをまとめたり、調査してまとめた報告書である。こういったものを公開している。
それぞれ独特なライセンスで公開しており、IPAmj明朝フォントに関してはIPAフォントライセンスという、IPAで独自に作ったライセンスを適用している。IPAフォントライセンスは、無償で使えたり、誰でもいくらでも複製して再配布できたり、変更していいなど自由なことを認めている。
ただし、フォントに変更を加えた場合、それを自分で使うだけならいいが、それを他人に配布する場合、変更を加えたフォントを再配布する場合は、「再配布先の人が、その人の意思によってオリジナルのフォントに戻すことができるようにしなさい」という条件を付けてある。
条件が付いている理由だが、文字を誰かが少し変えたりして、それがどんどん一人歩きして元に戻せなくなっていくことがあると、その文字の信頼性が減ってしまう。
また、文字をゲーム機やスマホ、デバイスの中にフォントとして入れ込んでしまうと、その製品の人気、その製品のシェアを背景にして、例えば社長の趣味の字みたいなものが抱き合わせで広がっていく、そんなことになってしまうと困ることもあって、元に戻せることを条件にしている。
このライセンスについては、オープンソースライセンスでオープンソースとは独特なそれぞれのライセンスがあって、よく知られているLinuxはGPLというライセンスでライセンスされているが、実はオープンソースライセンスは非常にたくさんあって、そのどれをオープンソースライセンスと言っていいかを認定している組織がアメリカにある。
オープンソースイニシアチブという任意団体だが、そこでIPAフォントライセンスはオープンソースライセンスとして認定できるというお墨付きをいただいている。そこが認定しているオープンソースライセンスは50何種類かあるが、そのうちの1つとしてIPAのフォントライセンスがリストされている状態である。
それから、文字の一覧表に関しては、クリエイティブ・コモンズ・ライセンスでライセンスしている。これは「IPAの著作権だ」と表記すればどう使ってもいいので、フォントそのものよりは緩いライセンスになっている。
また、SVGフォーマットの、フォントとしてではないが、文字の図形データをベクターとして表現したものを1文字1ファイルという形で提供している。これについても、クリエイティブ・コモンズという、より自由度の高いもので提供している。
(2)IPAmjフォントの符号化状況
IPAmjフォントは、符号化が図24の形で行われている。文字符号に関して詳しい人はこれを一目見るとわかるかもしれない。文字はISO10646、ユニコードがISO化されたもので表現している。
ISO10646も、実は文字セットに結構いろいろなレベルがある。基本領域は、文字符号を16ビット、2バイト文字だけで表しているものである。これをユニコードの基本領域、ベーシック・マルチリンガル・プレイ、BMPというが、こういうところにマップされている。
それから、基本領域を越えた32ビット範囲の中に割り当てられたものがある。さらに、文字符号としてではなく、文字符号を1回与えた後、さらに異体字の枝番号を付けるやり方もユニコードで規定されていて、それがIVD、イデオグラフィック・バリエーション・データベースに登録して、その1個1個のセレクターをIVS、イデオグラフィック・バリエーション・セレクターとか、イデオグラフィック・バリエーション・シークエンスとか言うが、そういうもので字を表現したものという、何通りかの場所に広がっている。
基本領域は16ビットなので65,000字入るが、ここに漢字だけでなくハングルやインドの文字など、いろいろな文字を入れなくてはいけない。インターナショナルな標準なので、漢字だけで全部入れることは許されないので、漢字に使えるのはここしかない。そこからはみ出したものが32ビット領域に入っている。
現実に情報機器がどれくらい対応しているかというと、いわゆるレガシーマシンというか、メインフレームとか古いマシンだと、16ビットまでしか使えないことが結構多い。言語的にも、コボルなどでは、16ビットの文字キャラクターは16ビットになってしまっているので、32ビットエリアに入ったものがシステム上使えないこともある。
従って、16ビット範囲までは、ほぼすべての情報機器で利用可能である。「うちの機械は8ビットまでだ」などという人は、それは捨ててもらうことになるが、普通のマシンであれば、大体16ビットまで、今は使える。PC-98は使えるが、昔のPC-88だと使えないというところである。
16ビットを越えた範囲は、例えばWindowsだと、WindowsXPの最新のサービスパックでは使えるということである。ただ、システム上使えても、アプリケーションが使えるかというと、また違う話である。
アプリケーションが使えるかどうかは、またそれぞれのアプリケーションに聞いてもらいたいが、大体このエリアは、普通のアプリケーション、WordやExcel、IEやOpenOfficeなどはみんな大体使える。
問題はIVDまで行ってしまったものである。これは結構使えない。Windowsの場合は、Windows7はOSのほうのシステムとしてはIVDが使えるようになっているが、今のところ、Wordなどのアプリケーションは対応していない。
ノートパッドのような非常にシンプルなものは対応しているし、IEも表示はできるという状況だが、メジャーなワープロなどはまだ使えないというのが現状である。そういうことなので、この字をインストールすると全部使えるかというと、実はそうでもないということになる。
それから、問題はインプットメソッド、かな漢字変換である。辞書が先にこの字を指していなければ、ひらがなを打ってもこの字が漢字にならない。もちろんコードで入れれば出るが、読みで入れても出ないので、辞書がどこまで対応しているかも、この字がどれくらい使えるかには重要な要素になる。
それから、まだ符号化していないものも7,000文字ほどあり、これはもともと普通には使えない。外字領域などに入れて、外字として使うことになってくる。
これはIVDの説明である。普通、一次元的に文字を符号化していく。この字は9087番、9088番、9089番というふうに、順番に番号を付けていくのが符号化だが、この一次元の中に1列に並べていくのではなく、とても似ていて、「これに別な新しいコードを今さら振るのか」という字もある。
学問的に、類似であるが故に、新しいコードを与えるよりは、1つの字の枝であるというほうが相応しいと専門家が判断した字に関しては枝番でやろうということである。
(3)IVS/IVD
一次元の対等な番号ではなくて、枝番で整理するようなやり方、それを表現した結果の文字コードの列をイデオグラフィック・バリエーション・シークエンス、そういうものをとりまとめて1つのデータに入れたものをイデオグラフィック・バリエーション・データベースという言い方をして、このように文字を区別する。
IVSに対応していないシステムなどでは枝番を無視するという規則になっている。ただ、その規則どおりに作られていないシステムが結構多いのでまた問題だが、規則を守っていれば、このフォントまで搭載していないマシンではここは代表字体で出る。上位互換性みたいな感じに自動的になる。検索するときも、バリエーション・セレクターのほうを無視して検索すると、ワタナベの何十種類が自動的に一瞬で検索されることが期待される。
ただ、本当の現実の世界は、異体字が必ずIVSになっていて、UCSがきちんとコードをもらって並んでいるものは異体字関係にあるものはないと完全に整理されていれば、検索でここを切り捨てれば親の文字が出るという美しい姿になるが、実は異体字なのにこちらにあったりして、いまひとつ統一性がない。
この辺は小林さんの責任だと私は考えているが、その辺の統一性が必ずしも完璧ではないこともあるので、検索はやはりテーブルでやるしかない。数学的機械的に検索する美しい作り方には実はならない。従って、字を表現する最新のユニコードのやり方として、IVSというものが規定されており、ここを使って我々の文字もコード化している。
(4)UCS符号化への対応状況
文字一覧表を見ていただくと、UCS符号化への対応状況でカテゴリ分けしている。カテゴリAはA1、A2、A3、A4、それからカテゴリB、カテゴリCというふうにカテゴリ分けをしている。
実際にIPAのサイトに接続して見てもらいたい。文字情報基盤のところに行って、文字情報一覧表をダウンロードしてみる。こうすると、例えばこの辺の字はMJ012001というMJの図形名で、住基文字ではこれで、戸籍文字の番号では127570でとなっている。
ここにUCS対応カテゴリがある。UCSでは61DBという文字コードだが、それについてカテゴリA1となっている。それから、この字に関してはカテゴリBと書いてある。カテゴリCというのはあまりないと思うが、こ
んなことになっている。
これはUCS、ユニコードのコード付けと、住民基本台帳や戸籍などで文字を識別するときの識別と、実は考え方に相容れない部分があったりして、無理矢理UCSを割り振ると、いろいろひねれたことが起きてしまう。それを、言い訳を予めしておくために、こういうカテゴリを分けているということである。
例えば、カテゴリAは自信を持ってUCSを付与している。「この文字は自信を持ってユニコードではこの番号だと言っていいと思う」という感じだが、それもいろいろ由来がある。昔の文字情報基盤でしっかりと確認したもので、日本から提案した例示字形のものとか。
ユニコードはいろいろな国から提案される。例えばこの字は中国から提案されたもの、これは台湾から提案されたもの、日本から提案されたもの、韓国から提案されたものである。こういうものを統合して、各国でこういう字として符号化したいということでユニコードのコンソーシアムに持ち込んだ。
UCSの全体の例示字体が載っているが、その他にこんな字で登録されているというのを見ることができる。これを見ると、日本字体はこうだからIPAmj明朝もこれにしようとか、日本からユニコードに提案されたのはこの字だから、IPAmj明朝もこの字という形になって、これが一致しているからOKという意味である。
「骨」も、各国からいろいろな「骨」が提案されていて、日本はこんな「骨」だが、中国の「骨」は中が逆だし、台湾の「骨」は中がちょっと曲がっていたりする。そのように各国からいろいろ提案されているが、日本からきちんと提案があって、日本の提案にきっちり一致しているので、これは自信を持ってOKだと言えるだろうというのがカテゴリAである。
カテゴリAも細分化していくと住基ネットの中のどこかと同じかなどあるが、おしなべて言うと、日本からちゃんと提案されているので、これがぶれる可能性は全くないと言えるだろう。
カテゴリBは、中国から提案された字、台湾から提案された字、韓国から提案された字で、とりあえずユニコードの中に、これを統合した文字で符号が付いているが、日本から提案されていない。日本で提案したときに、まだ戸籍文字などしっかり提案に持っていっていなかった。
これも小林さんの責任だと思う。小林さんが作業されたときには、まだ日本で使う文字として提案しようという動きになっていなかった。これは日本の文字がないので、全体を見て、中国、台湾、韓国を見て、「まあまあこうだろう」という感じである。それでIPAmjはこんな形になっている。
この字は中国も台湾も韓国も、どこも変わらないようなので、どれにしても問題なさそうな例だが、同じカテゴリBでも、これは中国提案と台湾提案で糸偏に関する基本的なデザインが違う。しかし、日本の漢字は、一般的に糸偏はこんなふうにしない。
「この字は日本から提案されていないので、中国、台湾から提案されて、UCS2601BというUCSが付けられたこの統合漢字にしてしまっていいだろう」というふうにしているが、もし万が一、日本も「こういう糸辺とこういう糸辺を別な字として区別するべし」などと将来言い出したりすると、もしかすると違う法則に持っていかないといけなくなるかもしれない。
今は日本の提案がないので、予想でUCSの番号を付けているので、そういう意味では将来絶対100%変なことが起きないとは言い難い。
カテゴリCは、そもそもUCSの中に似た字を見つけられない。これは戸籍文字と住基文字にあるが、どう探しても似たような字がUCSの中にないもので、これはもうどうしようもない。これからUCSを提案するしかないが、カテゴリCである。こういう感じで、符号化にいろいろなレベルがあるということをご理解いただきたい。
(5)今後の課題
今後の課題として、運用ガイドを、小林さんを中心にいろいろ整備していく、一覧表をさらに拡充していく、異体字関係はどうなっているのかとを拡充していくなどがある。
また、実証実験をする。今、実は公募中だが、Webを使っていろいろな方に、一般の方にこの文字セットを体験してもらったり、文字セットを使って名簿を作る作業を試してみるなど、いろいろな試しができるようなサイトを公開することで、今公募していて、6月ぐらいからデモが公開できると思う。
それから、自治体の現場で文字の変換のシステムを作ってみたり、自治体の現場の業務の中で、こういう漢字テーブルなどをどう活用していくかなどの実証実験を行う計画になっている。
また、文字の情報を今は簡単に公開しているが、もっとデータベースという形できちんと使いやすく公開することを進めていったり、符号化を継続してやっていくことを計画している。
また、簡易検索システムがあって、ここで字をいろいろ探すことができる。例えば、とんでもない字を探そうとか、例えば住基コードADCEを探すとき、ここにコードから探す。住基コードADCE100とかやると、一応出てくる。そんな検索システムも用意しているので、住基文字で何番と言われたらどれなのか、それと一緒に戸籍番号はどうなのか、これは残念ながらUCSは付いていないなどそんなことがわかる。更に細かい情報も出る。そういうデータベースも公開している。
使い道だが、例えばWordなどを動かして、コピペするとちゃんと入る。これはコード化されていないのでグラフィックだが、Wordはこういうグラフィックと普通の文字と、まぜこぜに、字のような形をして使うことができるので、例えば字の大きさを調整すれば、いかにも字が書けたように、とんでもない字もワープロで表現できる。例えば学校で名簿を作るようなとき、どうしようもないときは、こんなやり方で活用していただくことも、できないことはない。
ただ、字が何だったかわからなくなると困るので、字の番号は何だったのかを一緒にどこかに記録しておくのは非常に大事なことだが、そういうことで使っていただくことが今日からもうできる。
文字符号16ビットに入らないなど、いろいろ面倒なことはあるが、それはコンピュータとして自由自在に使えるためにはそうしなくてはいけないのであって、仮に何とかねじ伏せて使おうというときは、やり方もある。
(6)最後に
これで大体終わりだが、データベースをさらに拡充する、まだ符号化されていないところは追加して符号化していくといった作業がまだ残されている。
ロードマップを書いているが、こんな形で、順調に進んでいる。現在、3つのワーキンググループ、文字情報のところで文字の同定の基準とかハンドブックのガイドラインの作成とか符号化の検討といったことを行っている。
それから運用検討WGとは、主に自治体や政府の方に集まっていただいて、現場でどんな運用をするのがいいのか、ガイドラインを作ってもらっている。技術検討のところでは情報交換やプロトコル、どんなふうにシステムを作っていくとうまく字を使って既存のシステムを乱さないか、両立可能にするかといったことを検討している。
2012年1月26日TG研究会「文字情報基盤とIPAmj明朝フォント」より(文責編集)