住民基本台帳ネットワーク統一文字とその問題点
2013 年 55 巻 11 号 p. 826-832
詳細
2013 年 55 巻 11 号 p. 826-832
住民基本台帳ネットワーク統一文字は，当初はUCS（国際符号化文字集合）を拡張する形で設計されており，いかなるコンピューターでも使用できるオープンなシステムを目指したはずだった。しかし，UCSの基本設計に対する誤解や，その後のUCSの変化に十分追随できなかったために，住民基本台帳ネットワーク統一文字は，もはや現代のOS上では動作しない文字コードになってしまっている。本稿では，住民基本台帳ネットワーク統一文字の問題点と，その問題点を踏まえた上での今後の方策について述べる。
2012年4月6日付，最高裁判所事務総局経理局一般競争入札「裁判員候補者に対する通知書等の印刷，発送及び集計等の業務 一式」の官報公告には，以下の条件が付されていた。
実は，裁判員候補者予定者名簿システムや，後期高齢者医療広域連合電算処理システムには，住民基本台帳ネットワーク（以下，住基ネット）に使われている文字コードと，同一の文字コードが用いられている。いわゆる住民基本台帳ネットワーク統一文字（以下，住基文字）と呼ばれている文字コードだ。ところが，この入札公告では，住基文字の使用を，入札条件として書いていない。その代わり，「ＫＡＪＯ＿Ｊ明朝」という住基文字と互換なフォントを指定することで，結果として使用する文字コードを，住基文字に決め打ちさせているわけである。本件業務の通知書等の印刷物は，ＫＡＪＯ＿Ｊ明朝フォントを利用したものを作成すること。
ではなぜ，この入札公告は，住基文字の使用を，条件に書いていないのだろうか。使用する文字コードを明示せず，「ＫＡＪＯ＿Ｊ明朝」というフォントを指定する形となっているのは，なぜなのだろうか。忖度するに，住基文字の仕様が，現在も非公開となっているからだ。仕様が非公開のものを，入札公告の条件に書くわけにはいかず，特定のフォントを指定する形で代用しているのだ。
そもそも文字コードというものは，国際規格（ISO）に基づくオープンなものでなければならない。さもなければ，現代の国際化されたOSの上で使用することができないし，システム間をまたぐ文字のやりとりができなくなってしまう。そのために，日本の文字コード関係者は，かなりの労力を割いて，日本で必要な文字をISOに国際提案し，さらにはISOが制定している国際符号化文字集合（UCS，いわゆるUnicode）を，日本の国内規格すなわちJISに翻訳しているのである。
住基文字も，その点を考慮して，オープン・システムとして設計されたはずの文字コードだった1)。そうすることで，住基ネットの外とのやりとりも可能とし，ゆくゆくは日本の行政を支える文字コードとなるはずだった。ところが，住基ネットやその周辺の紆余曲折2)もあって，住基文字の仕様は公開されなかった。そして住基文字は，現在では，オープン・システムにはほど遠い，かなり多くの問題を抱えた文字コードとなってしまった3),4)。本稿では，住基文字がどのような問題を抱えているのか，問題を抱えるに至った経緯を明らかにするとともに，今後の方策を検討する。
住基文字は，地方自治情報センターが2001年2月26日に「検討版」を配布，2002年5月8日に「確定版」21,039字となり，2002年8月5日に住基ネットとともに運用開始された文字コードである。当時のJIS X 0221-1「国際符号化文字集合（UCS）―第1部：体系及び基本多言語面」（2001年4月20日制定版）のUCS-2に沿って設計されているものの，独自の拡張を施した2バイトコードである。各文字には16進数4桁のコードが振られており，表1に示す7つの領域に分かれている。
住基文字の中心をなすのは，当時のJIS X 0213「7ビット及び8ビットの2バイト情報交換用符号化拡張文字集合」（2000年1月20日制定版）11,123字である。ただし，この11,123字がそのまま収録されているのではなく，同規格票の附属書11「3.3 JIS X 0221からの索引」に示された11,319個のUCSが，ほぼそのまま住基文字に採用されている。この中には，当時UCSに提案中だった491個のコードポイント（JIS X 0213ではカッコ付きUCSで示されていた）も含まれているが，それらもすべて住基文字となっている。なお，「確定版」住基文字においては，11,319個のうち12個のコードポイントが削除され，代わりに，表2に示すコードポイントが使用された。
住基文字には，JIS X 0212「情報交換用符号―補助漢字」（1990年10月1日制定版）6,067字もすべて収録されている。うち6,040字は，JIS X 0221-1の附属書1で示されていたUCSに収録されているが，2,879字がJIS X 0213とダブっており，純粋にJIS X 0212から採録されたのは3,161字である。また，残り27字は，JIS X 0212とJIS X 0213とで規格票字形が異なるがUCSが衝突している漢字で，JIS X 0212の方を追加漢字領域に収録している（表3）。
住基文字の追加漢字領域には，各自治体の住民票システムで使われていたメーカー外字が，ほぼ部首画数順に収録されている。ただし，メーカー外字のうち，UCSとの対応付けがうまくいった1,201字については，3400～9fa4の漢字領域に収録されている。また，いわゆるIBM外字については，互換漢字領域のfa0e～fa2dにも収録されている。ac00～aca7には，変体仮名168字が収録されている。e000～f8ffは外字領域であり，ビットマップ画像とともに，住基ネットでの外字のやりとりに用いる。
なお，JIS X 0213は2004年2月20日の改正で，491個のカッコ付きUCSをすべて解消し，新たなUCSを示したが，住基文字はこれに追随せず，カッコ付きUCSをそのまま使い続けている。一方，2011年12月26日付法務省告示第582号「在留カード等に係る漢字氏名の表記等に関する告示」（2012年7月9日施行）に対しては，追加漢字領域のc109～c18bに，入管漢字131字を新たに追加した。この結果，住基文字の総数は現在21,170字となっている（表1）。
住基文字の問題点は，それがUCSをもとに作られたものであるにも関わらず，かなりの部分でUCSと一致していない，という点である。端的に言えば，住基文字21,170字中，UCSと一致しているのは15,379字で，残りの5,791字はUCSとは異なっている。5,791字の内訳は，非漢字領域122字，変体仮名168字，漢字領域303字（aaa1～abbf），互換漢字領域26字，追加漢字5,172字となっており，不一致の大半が漢字である。
UCSと一致しない漢字のうち，最も重症だと考えられるものは，漢字領域のaaa1～abbfに含まれる303字である。これらは，JIS X 0213のカッコ付きUCSに由来しているが，UCSの他の地域の文字とバッティングしているため（表4），UCSベースのシステムでは正常な処理が期待できない。例えば，住基文字aabe「𡈽」は，黒タイ文字のU+AABE「TAI VIET VOWEL AM」のコードポイントを流用しているが，「TAI VIET VOWEL AM」は非前進文字なのである。この結果，UCSベースのシステムでaabe「𡈽」を表示・印刷すると，それは直前の文字に重なってしまう。非前進文字として扱われるのだから仕方がない。aab0，aab2，aab3，aab4，aab7，aab8，aabf，aac1，aaeb，aaec，aaed，aaee，aaef，aaf5，aaf6も同様である。
UCSと一致しない漢字のうち，これもまた重症だと考えられるものは，互換漢字領域のfa45～fa5dとfa6bである。表5を見ればわかるとおり，UCSとは別の漢字が収録されている。端的に言えば，1文字ズレているのだ。このようなズレ方をすれば，当然，文字化けの原因となるし，また文字化けしてもなかなか気づかない，という問題がある。このズレは，元々はJIS X 0213のカッコ付きUCSに由来している。実は，JIS X 0213の附属書11「3.3 JIS X 0221からの索引」を作成したのは筆者（安岡孝一）であり，その点では筆者にも責任の一端があると言える。ただし，JIS X 0213は2004年改正でこのズレを修正して，カッコ付きUCSをすべて解消しており，住基文字がこの改正に追随しなかったところに，いまだ禍根が残っている。
追加漢字5,172字と変体仮名168字は，すべて，UCSのハングルとバッティングしている。したがって，住基文字はハングルと同時には使えない。住民票には通常，ハングルは併記されないので，この問題が表面化する可能性は極めて低いのだが，考慮しておく必要はある。非漢字領域で，UCSと一致していない122字についても同様である。
前章でも明らかにしたとおり，住基文字はUCSベースのシステムでは，正常に扱うことができなくなっている。しかし，住基ネット内部の文字コードを変更するのは，リスクが大きい。それゆえ，入出力部分だけをUTF-16に完全移行し，住基ネットとのインターフェース部分で住基文字との変換を行う，という方策を採用すべきである。すなわち，住基文字はシステム内部に閉じ込め，入出力には住基文字そのものは用いない，という方策である。以下，そのような方策を採るために，必要な手順を考えることにしよう。
まず第一に，住基文字の仕様は，公開すべきである。この10年の間に，住基文字の内容については，さまざまな形で非公式に言及されてきた5),6)し，本稿もその一翼をなしている。しかし，住基文字の仕様は，現在まで，公式な形で公開されたことがない。公式な形で公開されないと，一連の手続きをオープンに行えないため，UCSすなわち国際符号化文字集合へのアクションが，十全な形で起こせないのだ。本来，文字コードというのは，プライバシーだの個人情報だのとは何の関係もない。しかも，住基文字はJIS X 0213・0212・0221-1を元に設計した文字コードで，もともとオープンなものなのに，それを10年以上も非公開にしてきたという事実の方が，はっきり言って驚きだろう。また，公開を行うのは地方自治情報センターではなく，総務省がガバメント・アクションとして行うべきである。
次に，すべての住基文字について，UCSとの公式な対応表を作成・公開する。もちろん，一からすべてを作る必要はなく，情報処理推進機構が公開している「文字情報基盤 文字情報一覧表」7)や，あるいはJIS X 0213の追補1などを利用して，対応表を作成すべきだろう。ただしそれを，公式な形で公開する，という点が重要であり，UCSにない字は，正直に「ない」と書いてほしいのだ（表6）。また，住基文字とUCSの対応は，1対1にすべきだ。例えば，ad08とad0aはかなり字形が似ているが，ad08に<4E11 E0102>を対応させるなら，ad0aに<4E11 E0102>をダブって対応させるべきではなく，現時点ではad0aは「ない」と言い切るべきだろう。
その上で，UCSにない字は国際提案する。公開された住基文字の仕様と，公式な対応表を元に，国際提案する。国際提案そのものは，情報処理学会配下のITSCJ/SC2専門委員会に依頼することになるだろう。国際提案を通すためには，いくつか追加資料が必要になるかもしれないし，あるいは何か手を使うことになるかもしれないが，とにかく国際提案する。
さらに，住基文字とUCSの公式な対応表を，継続的にメンテナンスして，バージョンアップし，新旧あわせて公開し続ける。最初の対応表は，もちろん間違いを含んでいるだろうし，UCSへの国際提案が通れば，対応表は徐々に埋まっていくからだ。そして，対応表がすべて埋まった段階になったら，改めて，住基ネットにおける文字コードをどうするか，検討すべきだろう。それまでは，住基文字という文字コードそのものは，あくまで現状維持を続けるべきだ。拙速な変更は，さらなる禍根を生むだけである。
住民基本台帳ネットワーク統一文字について，現状の問題点と，今後行うべき方策を述べた。現代のOSは，UCSをベースに設計されており，そのようなOS上では，住基文字はほぼ確実に文字化けする。この状態を脱却するためには，入出力に住基文字を使わないようにするしかない。
以前，筆者は，本誌2007年5月号に「ケータイの絵文字と文字コード」8)と題する小論を発表した。これが導火線となって，ケータイ絵文字のUCS化が行われたが，最終的に国際規格となったのは2011年3月15日で，3年と10か月を要した。一方，筆者は，住基文字に対しても，2010年10月に警告を発した3)つもりだったのだが，関係各部局（住基ネットを担当する総務省，裁判員候補者予定者名簿システムを担当する最高裁判所，後期高齢者医療広域連合電算処理システムを担当する厚生労働省）からは何の音沙汰もなく，また，何のアクションもない。
住基文字の開発と保守を担ってきた地方自治情報センターは，2013年3月で廃止が予定されている。その際に住基文字がどうなるのか，その処遇は現時点では不明である。その意味では，今，住基文字の仕様を公開しておかなければ，住基ネットを継続するにしろ，マイナンバーへの移行を行うにしろ，まったくの手詰まりとなってしまう可能性が高い。国民全員と日本在住の外国人すべてを記述するための文字コードである住基文字が，水泡と帰す危険性すらあるのだ。関係諸氏の速やかな対応を，強く望むところである。
