小形克宏の「文字の海、ビットの舟」
|
|
●激論の末に修整されて最終審査を通過、制定された2000JIS
今年1月20日に制定された、拡張版JIS文字コード、JIS X 0213:2000[*1]（以下2000JISと略）。しかし、これはすぐに一般ユーザーが使えるという状況にはない。現在主流をしめるOSであるWindowsもMacOSも、規格単体として2000JISを実装しない。将来アップデートされたUnicodeのなかに2000JISの文字が収録された時点で、そのバージョンのUnicodeに対応することで、結果的に2000JISにも対応する。時期的には2001年末以降だろう。
[*1]……"X"はJIS規格中の情報部門、"0213"は規格番号、"2000"は制定・改訂年をあらわす。なお、待望の規格票発売は2月中の予定。それまで詳細は http://jcs.aa.tufs.ac.jp/fdis/X0213t-p1.pdf 、および http://jcs.aa.tufs.ac.jp/fdis/X0213t-p2.pdf の文字表を見るしかない。
さて、2000JISの原案は日本工業標準会の情報部会での最終審議は、2000JISを規格ではなくテクニカル・レポートにするべきという一部メーカー系委員と、それに反論するJCS委員会（2000JISの原案作成委員会）芝野耕司委員長との間で激論がかわされ、2回にわたった審議は難航した。
結果的に、シフトJIS、ISO-2022-JP、EUCによる符号化方法をきめた附属書1～3を規格から外し“参考”にするという修整が加えられ、2000JISはようやくJIS規格として成立した。ここで問題になったのは、2000JISの文字集合ではなく、コンピューターに実装するための符号化方法だった。より詳しくいえば、新しいバリエーションのシフトJISを規定することで、新たな文字化けの原因をつくることの是非だった。
シフトJISは純粋に“符号化方法”であって“文字集合”ではない。つまり、ひとくちに“シフトJISマシン”といっても、各社は空き領域に勝手に独自のJIS外字を収録し実装しており、世の中には想像される以上に多くのシフトJISのバリエーションが存在している。そして、それらは同時に常に文字化けの可能性をはらんでいるのだ。
そのような状況のなかで文字を拡張しようという2000JISは、結果としてさらに新たなシフトJISを規定することになる。
2000JISは従来あった空き領域に新しい文字を入れることによって拡張する方法をとった。それは同時に従来ここに外字を入れていた会社にとって、文字化けが発生することを意味する。これがもし規格として成立すれば、市場からは実装要求が強まる。しかし、これを本当に実装すれば、メーカーは古いシステムに実装したシフトJISとの間で身動きがとれなくなるおそれがある。情報部会の委員として名を連ねるメーカーの代表たちは、そこを強く心配したのだった。
そんな面倒なものを新たに作るよりは、ISO/IEC 10646（Unicode）[*2]があるじゃないか。世界中の多くの文字を収録しているISO/IEC 10646（Unicode）は、いったんプログラムをこれで記述すれば、日本語版であろうと、フランス語、ドイツ語、中国語、韓国語であろうと、ISO/IEC 10646（Unicode）に対応したアプリケーションであるなら部分的な修整でことがすむ。シフトJISにはこういう拡張性がない。日本だけを市場にしていた従来と違い、これから国際的なビジネスをするにはISO/IEC 10646（Unicode）以外の文字コードはありえない。バスに乗り遅れてはならないのだ。情報部会の委員たちの共通認識は、このようなものだった。
しかも、もともと2000JISの多くの文字は、すでにISO/IEC 10646（Unicode）に収録されている。また、新しい文字がISO/IEC 10646に収録されれば、ほぼ自動的にUnicodeにだって収録されるのだ。そういう、いわばUnicodeへのレールが敷かれた状況下で、いたずらに新たなシフトJISを作ることは、文字化けの要因をまたひとつ増やすだけで、顧客を混乱させることでしかない……。
それにしても、なぜ2000JISの原案を作成した芝野はシフトJISにこだわったのだろうか？ 彼はJSC委員会の委員長をつとめるかたわら、ISO/IEC 10646を制定する国際機関、ISO/IEC JTC 1/SC2の委員長でもあるのだ。本来ならシフトJISからISO/IEC 10646（Unicode）への移行には、双手をあげて賛成するべき立場にあるのではないか。それなのに、なぜ……？
[*2]…… “ISO/IEC 10646”は公的な国際規格であり、“Unicode”はアメリカのコンピューター企業が集まる『Unicodeコンソーシアム』が制定した私的な国際規格。現在のところこの2つはほとんど同一であり、まるで自転車の前輪と後輪のように連携をとりながらひとつの文字コードを開発している。 ただ、実際に製品が実装される場合は“Unicode”と称する場合が多い（ISO/IEC 10646を実装するメーカーがないわけではない）。これはUnicodeコンソーシアムの会員の顔ぶれをみれば理解できると思う。これら巨大メーカーたちが、みずから作った規格である以上、それを自分たちの製品に反映させない理由はない。その一方で、情報部会のような役所的な色あいがつよい場所で語られる場合は“ISO/IEC 10646”といった使い分けをされているようだ。
気をつけなければならないのは、両者が連携をとっているといっても、それぞれの改訂のスケジュールは別であり、一方が他方の改訂を反映するとしても、数カ月から数年のタイムラグが生じるということだ。
しかし実際には、たんに“Unicode”と言った場合“ISO/IEC 10646”をふくめている場合が多い。例えばこれから始まる芝野のインタビュー中、彼はひんぱんに“Unicode”という単語をつかうが、よく発言を分析してみると規格としての“Unicode”をいう場合が多いが、“ISO/IEC 10646”と“Unicode”を包括して“Unicode”と言っている場合もあることがわかる。たぶんこれは、芝野の「どっちでもええがな」という実務家気質をあらわしていると思うが、それ以上にこのふたつが分けられない現状を反映しているし、両者を統括する言葉が存在しないことをあらわしている。“ISO/IEC 10646（Unicode）”か“Unicode（ISO/IEC 10646）”としか書けないし、話し言葉としては“Unicode”で代表させたほうが簡単だ。
このふたつを厳密に書き分けるには、これらの規格だけでなく、周辺の規格（ISO/IEC 10646以前に多言語処理を目的とした国際規格、それにそれらの引用規格）まで視野に入れて内容を検証することが不可欠だが、残念なことに現在の私にはそれができない。これは他日を期すことにして、不完全を承知でこの原稿では会話のままとする。以下、“「 」”でくくった会話部分でたんに“Unicode”と言った場合、“ISO/IEC 10646”をふくめる場合もあることをご了承いただきたい 。
●強烈な実務家、芝野耕司にはじめて会った日
以上、ここまでの取材を終えたのは'99年もそろそろ終わりに近づいた11月も下旬の頃。はじめて芝野耕司にインタビューをしてから、そろそろ２カ月になろうとしていた。
それはまだ10月に入ったばかりの日。汗ばむような陽気にジャンパーを脱いて、東京外語大にある彼の研究室に入ったことをおぼえている。ありふれた濃紺のスーツを着て、大柄でちょっと長髪の芝野は、関西弁まじりの大きな声で精力的に話す、学者というよりは実務家タイプの男だった。2000JISの制定についてレポートをまとめるだけの簡単な仕事と思い、多少気軽な気分で芝野に会いに行った私に、彼はまるでしゃべる速さが考える速度に追いつかないとでもいうように、ものすごい早口で、難解な用語や英単語を散りばめながら話したのだった。
インタビューの後、120分テープが2本、私の手元に残った。彼はほぼ4時間、話しはじめた時と変わらぬテンションをずっと維持して語りに語った。快刀乱麻というのか、こちらがそれを知っているかどうか斟酌なく、さまざまな人や技術を俎上にのせては、容赦なくバッサバッサと切り捨てていく。しかし、たんに口が悪いというだけではなく、その内容は広く文字、とりわけ漢字というものの玄妙さと文字コードを定めることの難しさを語っていた。それは同時に、彼自身その針の穴のような難関を突破する明確な見通しをもっていること、それを最後までやり抜く強い意志をもっていることを、強烈にアピールしていた。
「なんか、スゲエ人だ……」
インタビューから解放された後エレベーターに乗り込み、私は首を振りながらつぶやいた。彼の話した内容はすごく難しくて、とても全部は理解できそうもなかった。哀れなことに、私は彼の話を必死に分かった振りをしながら聞いていたのだ。それでも彼は、とても示唆にとむ話をしてくれたことはわかった。
彼がついている役職の多さと責任の重さ、そして私が素性のしれない無名ライターであることを考えると、たんに彼が話好きだから私のインタビューに長い時間を割いたわけではないと分かる。なによりも彼は、話してくれた文字の仕事にケタ外れの熱意をもっている。そしてその熱意は裏表のある打算づくのものではなく、純粋なものなのだ。
「もうちょっと性根をすえてかかるか」
私は取材範囲をひろげて、周辺の人々の話を聞き始めた。フォント・ベンダー、ソフトウェア・メーカー、JCS委員会のメンバー、そしてその事務局……。芝野の熱意に対して私ができることは、彼の話をできるかぎり理解し、それを原稿にすることだ。しかし、そのためには彼の話だけでは分からないことが多すぎる。
そうしておよそ2カ月後、取材テープを積み上げると40センチほどになった頃、私は前回まで述べてきたような、シフトJISからUnicode（ISO/IEC 10646）へと世代交代しつある状況を、ようやく理解していた。11月下旬に情報規格調査会[*3]の棟上昭男会長と、JSC2[*4]の石崎俊委員長に話を聞くに及んで、私はもはやUnicode（ISO/IEC 10646）への流れは、押しとどめることができないように思うようになった。
文字化けがおこりやすいシフトJIS、アプリケーションを他言語に移植しにくいシフトJISの一方で、主要なOS、新しい技術が続々と採用しているUnicode。数年前にはUnicodeが日本の美しい伝統文化を破壊するという論調が目立った[*5]。しかし、現在においてはUnicode（ISO/IEC 10646）が良いか悪いかという段階はとっくに過ぎており、むしろいかに我々日本人にとって使いやすいものにするのかを考える段階なのではないだろうか。
だいたい、芝野はISO/IEC 10646を策定する国際機関ISO/IEC JTC 1/SC2（以下SC2と略）の、他ならぬ委員長ではないか。Unicode（ISO/IEC 10646）が何をもたらすのか一番分かっているはずなのに、どうして芝野は2000JISで古くさいシフトJISのバリエーションを増やすことにこだわるのだろうか？
[*3]…… 情報処理学会におかれる。国内の情報通信分野の標準審議組織として、ISO/IEC JTC1に対応する国内審議、および国際幹事国業務等をおこなう。
現在SC2の幹事国は日本で、実際には情報規格調査会が担当し、秘書は情報規格調査会の木村敏子、議長は芝野が務める。また情報規格調査会の棟上会長は、情報通信分野のJIS規格を審議する日本工業標準会（JISC）の情報部会長をかねている。
[*4]…… ISO（国際標準化機構）とIEC（国際電気標準会議）によるJoint Tchnical Committee-1（第1合同委員会）という親委員会のもとで、ISO/IEC 10646を審議するのがSC2（第2専門委員会）。この関係を表記すると“ISO/IEC JTC 1/SC2”となる。
一方でこのSC2に日本代表として出席するのがJSC2。日本(J)のSC2であることからこうよばれる。情報処理学会の情報規格調査会におかれる。国際機関に対応することから、“国内対応委員会”とか“ナショナル・ボディ（NBと略される）”とよばれる。
[*5]…… 例えば日本文藝家協会は'97年10月13日、江藤淳理事長（当時）名で国語審議会に要望書を提出した。その中では以下のよう書かれている。
〈更に、漢字を国際的な情報交換用の文字符号ととらえるならば、漢字が非英語圏の文字であるが故に国際的規格統一に際し、外国の有力私企業等の恣意によって、いわれのない字数の制限、字体の改変等を余儀なくされるおそれもなしとしません。これはJIS規格の枠を拡げるというような措置をはるかに超えた大問題であり、わが国の言語文化の存否に関わる事態と考えます。〉( http://www5.mediagalaxy.co.jp/bungeika/youb1013.html )文中の〈外国の有力私企業等の恣意〉との認識は、Unicodeへのいわれのない恐怖心がもたらしたものであろう。
●2000JISで文字化けはおこる。でもそれは当然の“コスト”なのだ。
このような疑問を胸に、私がふたたび芝野研究室の扉をノックしたのは、12月も中旬の頃だった。
芝野は2カ月半前に会ったときと同様に明解で、そして容赦なかった。彼がまず指摘したのは、情報部会でメーカー系委員が反対理由としてあげた、2000JISをシフトJISで実装した場合に文字化けがおきるという問題の意味のなさだった。
「シフトJISの混乱というけれど、べつに2000JISを実装したから文字化けがおこるのではなくて、現状すでに文字化けはおきているということ、それから例えば日本電気がどれだけ今までウソついてきたとかね、これは基本的にはそういう問題なわけね。PC-9801からDOS/Vに変わったときの変更も、きわめて非互換な変更でしたよ。メーカーは今までそういうことをたくさんやってきたわけ」
もともとシフトJISには無数のバリエーションが存在し、それらの間で情報交換すれば文字化けがおこる可能性をはらんでいる。これは前回までの原稿で書いたとおりだ。つまり2000JISを新しいシフトJISで実装したから混乱がおこるのではなく、すでに混乱はおきているのだ。しかも、そういう“シフトJISの混乱”をつくってきたのは、ほかならぬ2000JISの最終審議で反対したメーカー自身ではないか。芝野はそう言う。
「なにか誤解されていると思うけど、2000JISはまったく新しい文字コードなの。コードが違えば文字化けがおこるのは当たり前でしょう？ 新しいことをやるときにコスト・ゼロというのはありえない。分かりますか？ コストとベネフィット（利点）を比較して、ベネフィットが上まわると思うなら乗り換えればいい、それだけでしょう。それはもちろん作るときに、なるべくコストが少なくなるよう考えましたよ。最初は5,000字増やすことを見込んでいたのに、従来のシフトJISやEUCとの互換性に配慮して4,300字にしたんだから（*訂正1）。でも、まったくコストがゼロということはあり得ないし無理なわけ」
なるほど、それはそうだ。考えてみれば、完全に文字化けがない文字コードの改訂などありえない。メリットとデメリットはつねにトレード・オフ、どちらを取るか選択の問題だ。肝心なことは、改訂が自分にとってメリットがあるかどうかなのだ。2000JISで作られたファイルを、別の規格である従来のJIS漢字コード（97JIS、つまりJIS X 0208:1997）を実装したパソコンで読めば文字化けがおこる。これは事実だ。しかし、そのデメリットと引き替えに多くの今まで使えなかった漢字を使うことができる。では自分はそのどちらをとるか、という問題なのだ。もちろん2000JISを実装したマシン同士なら文字化けはおこらない。そして文字化けがおこる領域は現在メーカーが外字領域としてつかっている領域に限られる。
「いろいろ言う人が、じゃあ日本で本当に必要とする字をUnicodeに提案したのか。字は足らんといいながら、なにもしない。そうやって他人の足を引っ張りながら、Unicodeに移行しなきゃいかん、移行するんだと言う。もし今Unicodeしかいらないというのだったら、すべての新規のアプリケーション開発は、すくなくとも全部Unicodeに移行してないといけませんよ。既存のものを変更する前に、では今新しく作っているものを全部Unicodeで作ってますかって言ったら、依然として既存のシフトJISで作られてるわけでしょう。Unicodeで動作するアプリケーションって、今現実にいくつあるんですか？ マイクロソフトの製品とか、それこそ一太郎とか、ごく一部だけが16ビットコード[*6]のUnicodeにしているだけですよ。2000JISだと電子メールが化けるという言い方もされるけど、その前にまずUnicodeシステムすら動いていない。これが現実なわけ。だからそこのところで、私は嘘の固まりだと思うんです」
たしかに現時点でアプリケーションはシフトJISのままだ。このインタビューの前にいくつかソフトハウスに取材していたのだが、ほぼおしなべて返ってきたのは「これからはUnicodeに変わるかもしれない。でも現状はシフトJIS」という答えだった。
……ここで話は脇道にそれるが、Unicodeについてすこし詳しく説明する。これ以上はUnicodeがわからないと、話じたいの理解がおぼつかなくなるからだ。
文字コードは“文字集合”と、それをどのように符号位置をあたえ、コンピューターに実装させるかという“符号化方法”のふたつの部分に分けられる。この総称として、文字コードという言い方以外に“符号化文字集合”ともよぶ。
世界中の文字を収録しようという多言語国際規格の符号化文字集合、ISO/IEC 10646は、現在2つの種類がある。UCS-2とUCS-4だ。まずUCS-4の説明をする。
UCS-4は、タテ256×ヨコ256の区点からなる“面”を256面あつめて“群”とし、全体を256群とする体系だ。256×256×256×256＝4,294,967,296文字となる。2^32＝4,294,967,296と同じで、つまり32ビットコード。このUCS-4は16ビットコードを発想の原点とするUnicodeには存在しない。これを実装するのはSun MicrosystemsのSolarisだ。
このUCS-4の42億もの符号位置は当然まだまだ埋められていない。ではどこまでいっているかというと、最初の群の最初の面、つまり第00群の第00面だけは“ほぼ”収録が終了していて、この面をとくにBMP、Basic Multilingual Plane、基本多言語面とよぶ。第01面以降は今はからっぽであり、つまりUCS-4を実装するOSも、あつかっている文字はBMPにかぎられているのが現状だ。このBMPだけを実装すると、256×256＝65,536文字＝2^16＝16ビットコードとなる。そして、これこそがUnicodeと実質的に等しいものなのだ。UCS-2を実装しているのは、MicrosoftのWindowsシリーズだ。
今、全体像の説明しやすさのためにISO/IEC 10646のUCS-4からのべたが、Unicodeのそもそもの発想は、16ビットであらわされる範囲内（65,536文字）で世界中の文字を処理しようというきわめて単純明解なものだった。しかし結局は16ビットでは追いつかず拡張しようとしている歴史をもつ。くわしい人が16ビットのUnicodeを“本来的な”というニュアンスで語るゆえんだ。
このUCS-4とUCS-2は、文字集合とその符号位置がセットになったものだから符号化文字集合だ。一方でさまざまなニーズのなかで符号化方法だけが追加で考案された。そのひとつがJavaや各社ブラウザーなどインターネット関連ソフトに実装されているUTF-8だ。これは桁数が16ビット、つまり16桁になる冗長さをきらって、US-ASCIIと符号位置に互換性をもたせながら、UCS-4の文字集合を符号化する方法だ。1文字をあらわす最小単位（桁数）は8ビットだが、8ビットですむのはUS-ASCIIだけで、たとえば日本の漢字をUTF-8で表現すると24ビット（24桁）になったりする。つまり8ビットを単位とする8ビット可変長コードだ。
なぜUTF-8が考案されたかといえば、ひとえにUS-ASCIIと互換性があるため従来の文字コードから乗り換えるのが簡単だという事情による。
このUTF-8の考えは当初のUnicodeの世界平等思想、つまり収録されたすべての言語間で文字化けの不安がなくなる代償に、平等に従来の8ビットコードよりも2倍の桁数の文字をあつかう負担を引き受けようという思想とは矛盾している符号化方法と言えるかもしれない。
これとは別に、限界に達したUCS-2の“正嫡”ともいえるのがUTF-16という符号化方法だ。この“正嫡”という表現は、私が取材した結果感じたもので、少なくともUnicodeコンソーシアム参加企業（とくにMicrosoftとApple Computer）の間では、UCS-2を拡張するための符号化方法として、UTF-8よりもこのUTF-16を期待している雰囲気をつよく感じる。ちなみに、ISO/IEC 10646を開発するSC2では、後述するように現在UTF-16の枠内で文字集合を追加する作業をすすめている。
ただし、この奥歯に物がはさまったような言い方からも分かるように、これらの企業から公式なコメントとして出ることは決してない（どうしてだろう？）。また、当然ながら同じマイクロソフトでもインターネット関連のセクションに働く人に聞けば、UTF-8が優勢という答えが返ってくることは言い添えておく。
さてこのUTF-16とは、BMPのなかで保留（使用禁止）されていた、それぞれ1,024の区点をもつ2つの未定義領域をつかい、これを前後に組み合わせる（サロゲート・ペアと称する）ことで、1,024×1,024＝104万8576文字を表現可能とし、この1,048,576のキャラクターを、UCS-4で説明したタテ256×ヨコ256の区点をもつ面に、順番に割り振っていくという方法なのだ。サロゲートとは“代理”の意味。つまり2つの保留領域のコードをペアで、第01面以降の代理として使う、という意味だろう。
1,048,576を面に換算すれば、1,048,576÷(256×256＝65,536)＝16で、全部で第16面までの文字を表現することができる。つまり第01面から第16面までだ。第00面（BMP）も使用可能なので、合計で1,048,576＋65,536＝111万4,112文字が使用可能だ。
UTF-16は“16”という数字からも分かるとおり、表現される文字の単位は16ビットだが、サロゲートペアでは16ビットが2つ＝32ビットになるので、16ビット可変長コードということになる。UTF-16をいち早く実装したアプリケーションにジャストシステムの一太郎Arkがある。ジャストシステムは唯一の日本企業としてUnicodeコンソーシアムに正会員として参加している会社でもある。
このように、UCS-2を拡張するための符号化方法といっても、UTF-16は第16面までしかあつかうことはできない。32ビットコードのUCS-4と比べてもしょうがないが、第17面以降が必要になったときはどうなるのか？ という疑問が頭をよぎらないでもない。このことから、UTF-16を「付け焼き刃」として批判する人々もいる。例えば2000JISの最終審査をした情報部会の部会長である棟上昭男は、このことをインタビューの席上繰り返していた。情報規格調査会の会長でもある棟上は、ISO/IEC 10646を開発するSC2の上部機関、JTC 1の日本代表でもあることを考えると、この批判はそれなりの重みをもつ。
このUTF-16にもとづき、SC2では現在第01面から第16面までに文字を追加する作業をおこなっており、これはISO/IEC 10646のパート2（ISO/IEC 10646-2と表記される）として2001年12月頃に発行されるといわれている。なかでもアジアの漢字使用国で注目されているのが、漢字のために割り当てられた第02面の制定だ。このうちパート2に収録されるのがエクステンションBと呼ばれ、約40,000字の追加が予定されている。Unicodeじたいの改訂作業は、'99年10月に発表されたUnicode3.0以降は予定が明確化していないが、漢字に関してはこのエクステンションBをUnicodeに反映させるかたちで追加することになろう。逆にいえばUnicodeコンソーシアムの会員企業は、Unicodeを実装する以上は、このエクステンションBが制定されないと、漢字文化圏の各国で“漢字にこまらない”という売り文句でビジネスをすることが出来ないわけだ。エクステンションBの他にAとCもあるのだが、その関係については次号にゆずる。
今までのべた他にも、Unicodeの符号化方法には7ビットのUTF-7、それに私は（恥ずかしながら）知らなくて、読者の前寺正彦さんから存在をお教えいただいた32ビット固定長のUTF-32がある。しかし、これらについての詳述は、ここではさけたい。当面の状況のなかでは、これらは名前だけ覚えておけば十分だろうからだ。
●Unicodeへの移行を叫ぶのは、たんなる建前論でしかない。
話を東京外語大の芝野研究室に戻そう。彼はシフトJISからUnicodeへの移行にも、悲観的な見通しをもっていると語った。
「簡単にUnicodeに移行というけれど、現状で圧倒的に多数を占めるシフトJISは8ビット可変長コードです。ところがアプリケーションを、16ビットに書き換えようとしたとたんに、実はとんでもない工数が発生しちゃうわけ。ある意味でアタマから作り直すくらいの作業をしないといけない。そういう開発工数が分かっていて反対しているのか、そういう移行するためのトータル・コストを考えているのか。新しいものが出たら、なんか対応しなきゃいかんと言うだけで、本当に必要な開発工数と期間、あるいはユーザーにこれを出せば、どれだけ売れるかという戦略、そういうのが全部なくってね、建前論としてのUnicode、建前論としての既存のシステムに対する互換性を言っているだけでしょう。
そりゃ建前じゃないところもありますよ、ワールドワイド・ビジネスをしているIBM-USとか、MicrosoftやApple Computer。US（アメリカ）のこういう企業の戦略にとっては、Unicodeは必要なんですからね。でもその日本法人もふくめて国内のメーカーは建前で言ってるだけです。既存のシステムが、単純に4～5年の間にUnicodeに置き換わるというふうな予想は、どこにも存在しないんですよ。言っているだけであって、アプリケーション全部が変わらなければならないわけでね」
どうも分が悪い。なんだかデキの悪い生徒が、先生の前で口頭試問を受けているようなぐあいだ。それでも私はおずおずと質問を口にしてみた。
「おっしゃるとおりかもしれません。その他にも、開発者にとってはUnicodeに移行すると、長年のシフトJIS環境で蓄積してきたサブルーチン群をゼロから書き直さなければならなくなる。しかもUnicodeで得られる多言語化のメリットは、世界規模のメーカーならいざ知らず、ごく小規模な国内向けのソフトハウスにとってはコストが上積みされるだけで、俺たちには関係ないよというのが実際のところかもしれない。
でも、アプリケーションをゼロから開発するなら、Unicodeで開発した方が楽だってことはあるんじゃないでしょうか？ 現在のようにOSがUnicodeに対応した環境で、アプリケーションをシフトJISで書く場合、OSからデータを受け取る時も、それにOSにわたす時もいったん自分でシフトJISに変換しないといけませんよね。ところがアプリケーション自身がUnicodeで動作するように書けば、このような変換は必要なくなり、上から下までストレートにUnicodeで動作するようになります。つまりUnicodeへの対応はアプリケーション開発にとってもメリットはあるし、結果として動作も軽くなるということなんですが」
芝野は私の質問をかるく切り返した。
「そうなって欲しいとは思いますけど、その前にデータはみんなシフトJISですよね。仮に新しいUnicodeのアプリケーションができても、データはシフトJISで残っているわけで、それこそ2000年問題と同じですよ。2000年問題って、本来はとっても簡単なはなしなわけね。2桁の年のデータを4桁に直すだけなんだから。あんな簡単な話ですらこれだけ大騒ぎになる世界で、しかもネットワークのどこかに2000年対応してないのが残っているだけで、全体がおかしくなる世界なんですよ。これはだから、今蓄積されている膨大なデータを、明日になったらUnicodeに変えろって言えるかどうか。それは5年だと言えるか？ 10年だと言えるか？
みんなギガ・バイトのファイルを持っているわけですよね。そのギガ・バイトのファイルがUnicodeに変わっていかなきゃいけないわけです。皆さんのデスクトップ上にあるギガ・バイトのファイルは、みんなシフトJISなんです。でしょ？ これがみんな変わっていくまでに何年かかるのか。それはそんなに簡単な話じゃないと思うけどなあ」
●日本のメーカーは当事者能力を失っている。
ここまで言って、芝野はアーロンチェアの肘掛けに両手をおき、すこし浅く座り直して足をのばしながら、やれやれというように、ふうと軽く息をついた。
「私はシフトJISを生き残らせろって言ってるわけでもなんでもないんです。もともと97JISにシフトJISを入れた[*7]のは、いったん認知してシフトJISを打ち止めにするのが目的だったんです。いわば私生児のような技術が生まれたと。ところが私生児が認知もされないまま、市場で大きな顔をしている。だからまず規格として認知してあげて、認知した上で、それはこの間に削除するよといって、5年なり10年で打ち止めにしようとしているわけ。ただしそれを、すぐに明日からUnicodeで全部いけますよなんて話をされると、どこにそんな根拠があるのということになる。それだったら、2000年問題なんてね、今回のシフトJISからUnicodeへの移行と比べれば、本当に大したことない話なんです。
例えばマイクロソフトOfficeなんかは、Unicodeに移行できましたと言うかもしれない。でもそりゃそうですよ、大勢のスタッフがいて、ワールドワイドに、何兆円のビジネスをしているわけですから。それも基幹プロダクトですよね。メジャーなオペレーティングシステムとか、officeや一太郎なんかのメジャー・アプリケーションのように、何百人という開発スタッフがいて、ずっと開発を続けているところはそれでいいわけ。そういうところならUnicodeに移行するメリットも充分あるでしょう。
でも実際に社会のあちこちで動いているアプリケーションというのは、1回作ったら、そのままほったらかしで10年使うとかね、あるいはひとつのアプリケーションがあったら、何年かに一度はメインテナンスに来ますけど、それも1人か2人くらいという世界。こういうところが2000年問題と同じなんですよ。まさか20年も30年も未対応のシステムを使うとは思わなかった、でもそれが使われていたわけ。中身をだれも見ていない、だからわからない、直せない。で、文字コード問題っていうのは、そういうシステムの下にもういっこ、データが溜まってくるわけね。そう簡単にいく話じゃないと私は思いますけどね」
[*7]……芝野は従来デファクト規格でしかなかったシフトJISを、はじめて公的な国内規格で明文化したJIS X 0208:1997（現行の97JIS）、つまり0208の第4次規格の原案作成委員会の委員長。シフトJISをめぐる国内状況については前回の第2回原稿を参照のこと。
そうして、芝野はつづけた。
「皆さん権威として、規制としてJISを使おうとしているんじゃないかと思うんですよ。本来技術とはニュートラルなものでしょう？ もともとJIS規格なんてね、法規でもなんでもないわけですよ。使おうが使うまいが、どっちでもいいわけ[*8]。反対する前にあなたたち別にインプリメント（実装）しなけりゃええじゃんと、それだけでしょ？
ただし、例えばうちの大学（東京外語大）に来年システムを入れますけども、その時に教科書書けないシステムじゃ困るよね。うちの大学は多言語環境だけど、まず日本語で教えなきゃいかん。そうすると、まず発音記号[*補注1]がなけりゃダメねと、それだけでしょ？ こういうものを出すには2000JISを使うしかないんだから。出せないという業者は帰ってもらえばいいだけ。シンプルな話だと私は思いますけどね」
[*8]…… 正確には、JISの根拠である工業標準化法に以下のような条文がある。 第六七条（日本工業規格の尊重）国及び地方公共団体は、鉱工業に関する技術上の基準を定めるとき、その買い入れる鉱工業品に関する仕様を定めるとき、その他、その事務を処理するに当たって第二条各号に掲げる事項に関し一定の基準を定めるときは、日本工業規格を尊重して、これをしなければならない（六法全書平成10年版2より。読解のため筆者が句点促音を加えた）。
つまり、お役所でなにかを調達するなどのために仕様や基準を決めるとき、それが日本工業規格がさだめる範囲のものならば、これを尊重する義務があるわけだ（ただし罰則規定はない）。したがって国や地方公共団体にかぎっては、JISは“使おうが使うまいが”というものではない。もちろん2000JISを実装する立場のコンピューター・メーカーなど私企業は、この67条とは関係ない。
[*補注1]……この原稿の発表後、前寺正彦さん、松川一也さんから、Unicode―ISO/IEC 10646―JIS X 0221に発音記号はすでに収録されており、発音記号を出せるのは2000JISだけという発言は間違っているのではないかという趣旨のご指摘をいただいた。しかし2000JISにしかない発音記号はあり、そのことを芝野はこの原稿に採録しなかった別の部分で明確にコメントしている。
2000JISにだけにある発音記号とはアクセントつきの発音記号だ。2000JISの面区点番号では1-11-41以降、43、45、47の計4面区点の文字をさす[*訂正2]。これらの元になる親字はいずれもISO/IEC 10646（和訳がJIS X 0221）では、IPA(International Phonetic Alphabet)拡張とよばれる領域（0250～02A8）に収録されているが、アクセント記号つき（具体的にはアキュートつき）の字形は収録されていない。ISO/IEC 10646（Unicode）ではアクセント記号単体はすでに収録ずみなので、これと合成すればよいという判断からだ。ラテン文字圏ではこうした文字を合成する技術が確立されている。
しかし日本では、アクセント記号の合成をする機能は普及していないので、現実によく使われているものについては合成ずみの字形を2000JISで収録することにした。
以上のように芝野は説明した。(2000.2.12)
芝野は少し言葉を区切って視線をおとし、言葉をつづける。
「……今回の情報部会での反対というのは、基本的には、国内のメーカーが本当の意味で当事者じゃなくなってしまっている現状を表していると思います。ユーザー・ニーズについても、デベロップメント（開発）についても、当事者能力を失っているから、最終審議でああいう話になった」
ここで彼は目をあげて、ひたと私を見つめながらこう言った。
「そう私は理解しています」
（以下次号）
◎参考文献
・漢字文化は危なくない 見えてきたUnicode3.0（月刊ASCII 98.6）
・Unicodeを巡る放談会 Unicodeはどうやって決まっているのか（月刊ASCII 98.12）
・パソコンにおける日本語処理／文字コードハンドブック（川俣晶著 技術評論社 99.6.10）
・文字コードの世界（安岡孝一・安岡素子著 東京電機大学出版局 99.9.30）
・JIS X 0212:1993（日本規格協会）
・The Unicode Standard Version 2.0（The Unicode Consortium著 Addison Wesley 96年）
・文字コード標準体系検討専門委員会報告書(99-08) (99-09-22版) ( http://www.itscj.ipsj.or.jp/domestic/mojicode/houkoku922.pdf )
・JIS X 0221（ISO/IEC 10646）の目指すもの（98-11)芝野耕司 http://www.itscj.ipsj.or.jp/jp/ns39012.html.)
※とくに文字コードのアーキテクチャの理解には川俣氏の『パソコンにおける日本語処理／文字コードハンドブック』が役に立った。この本は体系的に文字コードの歴史と構造を解説しており、二読三読した。氏よりあたたかいメールをいただき筆者は感激している。記して感謝します。
また、多言語処理をめぐるさまざまな国際規格の歴史については、芝野氏の『JIS X 0221（ISO/IEC 10646）の目指すもの』が、ほとんど決定版ともいえる貴重な資料だと思う。これについても、筆者にあつく感謝したい。
(2000/2/9)
◆お詫びと訂正
[訂正1]…… 2000JISの収録文字数を間違えて書いてしまったのを修正した。指摘してくださった 池田証寿さん、前寺正彦さん、Yasunori Sugiiさん、松川一也さんに感謝いたします。
◎誤：最初は50,00字増やすことを見込んでいたのに、従来のシフトJISやEUCとの互換性に 配慮して43,000字にしたんだから。
◎正：最初は5,000字増やすことを見込んでいたのに、従来のシフトJISやEUCとの互換性に 配慮して4,300字にしたんだから。 <2000.2.10>
[*補注1]……2000JISにしかふくまれない発音記号に関する説明を、補注1として追加した。
(2000.2.12)
[訂正2]…… 豊島正之さんよりご指摘いただき、“Unicodeになく 2000JISにある発音記号”は、まだ2面区点あることがわかり、以下のように訂正した。
これらの元になる親字は
◎誤：2000JISの面区点番号では1-11-41以降、43、45、47の計4面区点の文字をさす 。
◎正：2000JISの面区点番号では1-11-41以降、43、45、47、1-11-69、1-11-70の計 6面区点の文字をさす。前半の4面区点の元になる親字は（中略）技術が確立されて いる。また1-11-69は声調記号上昇調、1-11-70は声調記号下降調をあらわす記号だ 。
[Reported by 小形克宏]