小形克宏の「文字の海、ビットの舟」
|
|
●9月の情報部会の閉会後になにがあったか？
こうして要望書が出されたのが1999年8月31日。その1ヵ月後の9月27日、いよいよJIS X 0213（以下、0213）の最終審査を行なう第83回情報部会がひらかれる。席上、斎藤と芝野の間に激しい論争が戦わされたのは既述の通りだ（第2部第7回を参照）。
そうするうちに席上、富士通から附属書を規定ではなく参考にするという、いわば中間案が出された。では、ここで日本IBMへのインタビューに話を戻し、斎藤輝部長に、彼らがこの富士通の提案をどのように見たのか説明してもらおう。「実効的にですね、文字化けが防げるという観点からすると、まあ富士通案もそんなに悪いわけじゃない。つまり文字集合は認めるけどもエンコーディング（符号化方法）は問題ですと、そういう感じですよね。そうすると実質的には、我々が言おうとしてることとあまり変わらないという意識がありました。実際にJISよりもテクニカルレポートの方が影響力は弱いですよね。そうすると、文字集合をあれだけ努力して作られたんだから、それはやっぱりテクニカルレポートよりもJISとして規格化してもいいかなという気持ちになってたわけです」
つまり、土壇場で仏心が出たということか。そうして情報部会の論議の方向は0213の原案をテクニカルレポートにするかどうかではなく、富士通案の可否に論点を絞った形で、ひとまず次回に継続して審議するという結論になった。なお、受けて立つ形の芝野委員長は、附属書1（シフトJIS系）は参考にすることは認めるものの、2と3（それぞれ日本語EUC系とISO-2022-JP系）については依然規定とすることを主張していた。
さて、問題は情報部会の閉会後のことだ。当時の工技院の担当者である永井裕司技官は、私のインタビューに答えて以下のように言う。第2部第9回から再録しよう（詳細はhttp://internet.watch.impress.co.jp/www/column/ogata/part2_9.htm）。
永井：（前略）工技院は事務局として調整役の立場もあります。漢字が足りないとう世の中の要求に対して、0213の文字をこのまま廃案にする、あるいはテクニカルレポートにするという判断はない、やはりJISとして世の中に出そうと調整しました。
小形：それは9月と10月の情報部会の間に調整にまわったということですね。
永井：ええ、関係者が満足するよう、事務局調整に入りましたよ。事務局としての立場と、標準化政策を推進する工技院の立場と、ふたつを使い分けながら、調整しました。
●工技院の“事務局調整”とは？
私がぜひとも知りたいのは、この“事務局調整”なるものが、具体的にどのような形で行なわれたのかということだ。しかし、当然かもしれないが永井技官はこの点で口を濁す。その後、電子協の東條喜義参事へのインタビューで、9月の部会の開催後、工技院が橋渡しになって、東京外語大の芝野研究室で、メーカーと芝野委員長との会見が行なわれたことが分かった（http://internet.watch.impress.co.jp/www/column/ogata/part2_13.htm）。では、その前後の詳細を、斎藤に聞いてみよう。
「9月の部会が終わった後、永井さんが連絡をとってこられて、どうなんですかと、やっぱりテクニカルレポートにこだわるんですかと、こうおっしゃるわけですよ。我々としては要望書を出した以上は頑張りたいと言ったんですけど、そうすると永井さんが、この情報部会パンクしますねと。パンクすればエライことになりますよと」斎藤は笑いながら言った。私も笑いながら言った。そりゃあ脅しですね、永井さんもやるよなぁ。私の挑発にとりあわず、斎藤はつづける。
「それとやっぱり何回も言われたことですけども、委員の一人が最後にひっくり返すというのは、やっぱりそれはマナーとしてイマイチじゃないですかと。まあ私の方も、芝野先生とずいぶん対立したんですけども、いよいよとなるとやっぱりね、皆さんハッピーになるようにということでね、分かりましたと永井さんにお伝えしました」私は数日前の電子協、東條参事とのやりとりを思い出しながら、斎藤にたずねた。
「東條さんにお話を聞いたところ、こうおっしゃっていました。9月の情報部会の後、電子協で富士通さんも含めていろいろ話をした。で、その後に芝野さんと実際に会った。それは2回目、10月の情報部会の1週間ほど前らしいんですが、その時の芝野さんの意見は、確かに附属書1から3の全部が参考でいいよとは言わなかったんだけども、まあ、あまりこだわってないなという感触があったんで、それでは富士通案で行こうかというようなことで2回目の情報部会に臨んだ。そう東條さんは説明されたんですが、いかがですか」斎藤は笑顔で言う。
「そうですね」と言って斎藤はかたわらの榎本の方を向いて聞いた。
「外語大へ行ってワアワアやった時点では、附属書2と3は呑まなかったんだよね、確か。譲れるのはシフトJIS（附属書1）までだって、あそこへ行ったときも言われたんだよな」榎本は肯きながら答える。
「ええ、そうですね」ということは、私は言った。
「つまり1回目の部会と同じ立場ですね」斎藤は答えた。
「そうですね。芝野先生がおっしゃるには附属書の2から3は本質的なものだと。ですから、外語大へ行って話し合ったけども、行く前と結果は変わらなかった」
●世界の文字コードとシフトJIS、そして0213
つまり、この時点で芝野委員長はインターネットメールで使われるISO-2022-JP系を定義する附属書2（ISO-2022-JP-3符号化表現）、それに主としてUNIXで使われる日本語EUC系を定義する附属書3（EUC-JISX0213符号化表現）を参考にすることを、拒んでいた。その一方でシフトJIS系を定義する附属書1（Shift_JISX0213符号化表現）は参考でよいと真っ先に妥協している。この事実はなにをしめすのだろうか？
斎藤が芝野委員長の言葉として言った〈附属書の2から3は本質的なものだ〉というのは、規格本体に規定されている符号化方法がISO/IEC 2022（和訳JISは、JIS X 0202）によるものであり、日本語EUCもISO-2022-JPもそのバリエーションであることを指すのだろう。
ここでちょっと解説を入れさせていただく。でないと話が分かりづらい。現在使われている文字コードの基本中の基本は7ビット（2の7乗＝128文字を規定）コードであるアメリカのASCII（US-ASCIIとも。1963年制定）だ。しかし、ここで規定された94文字（残りの128-94=34文字は不可視の制御用符号）ではヨーロッパ等の発音記号つきの文字を表現できない。そこで94文字のASCIIのうち、12文字を適当な自国の文字に入れ替えて使い、残り82のラテン文字の大文字／小文字などはASCIIそのままという規格が考えられた。つまりこの枠組みを使えば大筋では判読が可能な情報交換ができるわけだ。これが1967年に制定されたISO R 646であり（のちに改訂してISO/IEC 646）、イギリス、ドイツ、フランス、スウェーデンなど、多くの国で対応バージョンが作られた。日本では、JIS X 0201（1969年制定）がある。
こうしてASCIIの枠組みを使って自国語を使う方法は確立された。しかしいったん言葉や文字の違う国同士が情報交換をしようとすると、この枠組みはすぐに使いづらくなる。つまり多言語処理（というより多スクリプト[*1]処理か）というものだ。ではどうするか？
ここから先の拡張法は、大別してふたつに分けられる。ひとつは、ものすごく大きな文字表（具体的には16ビット＝6万5,536文字や、31ビット＝21億4,748万3,648文字）を用意して、ここに複数のスクリプトを入れようという、いわば大風呂敷主義。この方法をとるのがISO/IEC 10646（≒Unicode）だ。制定は1993年。和訳JISはJIS X 0221。
もうひとつが複数の7、8ビットの文字集合を切り替える[*2]ことで、結果的により多くの文字を使えるようにする方法だ。これがISO/IEC 2022で、制定は1973年。制定年でお分かりの通り、考え方としては後者の方が古く、前者は新しいものだ。
[*1]……スクリプト（JISでは“用字”）とは、JIS X 0221:1995規格票の『4.1定義』によれば〈一つ以上の言語の表記の方法で、使用する図形文字の集合〉。例えば英語、ドイツ語、フランス語、タガログ語、スワヒリ語などは同じ文字で表記する。そこでこれらの言語の表記に使う文字の集合（スクリプト）を一括して“ラテン文字”とよぶ。また日本、中国、韓国などで共通して使われる象形文字のスクリプト名を“漢字”とよぶ。そして日本語は漢字、ひらがな、カタカナ、ラテン文字という4つの異なるスクリプトを使って表記される言語である。ついでながら文字コードは言語ではなく、スクリプトを符号化するのが普通だ。例えばJIS漢字コード、JIS X 0208ではＡ、Α、Аと一見同じ文字が符号化されているが、これは左からラテン、ギリシャ、キリルのスクリプト。一方でドイツ語、フランス語、タガログ語、スワヒリ語で使う“Ａ”はすべてラテン文字の“Ａ”を使う。
[*2]……ここでは〈切り替える〉と簡単に書くにとどめたが、より詳しくは各種専門書を参照して欲しい。例えば『パソコンにおける日本語処理／文字コードハンドブック』（川俣晶 技術評論社 1999年）のp.195以降、『文字コードの世界』（安岡孝一・安岡素子 東京電機大学出版局 1999年）のp.14以降。もちろん一番の原典は最新の版であるISO/IEC 2022:1994か、その翻訳であるJIS X 0202:1998の規格票（2,700円）を読むことだろう。日本規格協会（電話:03-3583-8002）に依頼すれば、JISはもちろん海外の規格票もファクス注文と郵送による受け取りが可能だ。ややこしい言葉が連続したが、ここではISO/IEC 10646（≒Unicode）とISO/IEC 2022は、多言語処理という同じニーズにもとづく、方向の異なるアプローチ（技術）であるということを覚えておいていただきたい。
ただし、ISO/IEC 10646（≒Unicode）とISO/IEC 2022を多言語処理という側面で見た場合、前者のISO/IEC 10646（≒Unicode）の方が、より実装がしやすいということが言える。
例えば、ISO/IEC 10646（≒Unicode）のうち、『基本多言語面』とよばれる6万5,536文字を符号化可能な領域には、20ものスクリプトが収録されているが、これだけの数のスクリプトを同様にISO/IEC 2022の方法で切り換えようとしたら、おそろしく複雑な処理が必要になってしまう。もちろん、そうした複雑な処理で多言語処理をやろうというアプローチが皆無なわけではなく、現在もさまざまな方面で開発が進められているが、実装の容易さ、そして実際にインストールされたシステムの数という面で、ISO/IEC 10646（≒Unicode）に一日の長があるのは確かだと思う。さて、ISO/IEC 2022は符号化方法、つまり容器だけの規格で、文字集合、つまり中味は定義していない。これを使った文字コードの代表格は、ヨーロッパ等の国々で使われているISO/IEC 8859シリーズ、そして我らが日本のJIS漢字コード、JIS X 0208（以下、0208）、そして、そう、0208を拡張する0213も、実はISO/IEC 2022の系統に属するのである。
ところで、ここまでさまざまな符号化方法の名を挙げたが、ひとつ我々日本のパソコンユーザーになじみ深い符号化方法が抜けているのに気がつかれただろうか？ それこそがシフトJISである。
ここではシフトJIS自体の説明は省略する。詳しいことは第1部第2回を参照していただきたい。とりあえず、シフトJISは世界の文字コードの2大流派、ISO/IEC 10646（≒Unicode）とも、ISO/IEC 2022とも、異なる流れであり、0208の文字を使っているつもりでも、符号化方法はシフトJIS（Windows 95/98/MeはシフトJIS）ということが多いということを押さえておいて欲しい。
確かに0208も、それを拡張する0213も、規格本体で規定する符号化方法はISO/IEC 2022によるものだ。例えばUNIX系のシステムで一般的な日本語EUCは、ISO/IEC 2022のバリエーションだ。そういう意味では日本語EUCを実装したシステムは、0208を本体の規定通りにコンピューターに実装した例と言えるだろう。しかし、前述したように多言語処理を念頭においてISO/IEC 10646（≒Unicode）と比較すれば、おのずから日本語EUC、つまりISO/IEC 2022には限界が露呈してしまう。
まったく同様のことはシフトJISにも言える。いや、EUC系の文字コードはシフトJISよりもずっと拡張性にすぐれているから、シフトJISを実装したシステムにおいては、より事態は切迫していると表現した方がいいだろう。
パソコンが世界中に普及し、世界中の言語版の開発が要請される現在、たったひとつの文字コードでさまざまな言語版の開発を進めることができるISO/IEC 10646（≒Unicode）へ移行することは、もはやOSメーカーにとって、議論の余地のない大前提でしかないのだ。
●芝野委員長は、なぜ最初にシフトJISを参考でよいと妥協したのか？
シフトJISについて、詳しいことは第1部第2回を参照していただきたい。しかし重要なことは以下の3点に要約できるだろう。
（1）日本のパソコン市場で現在でも大きなシェアを占める符号化方法、シフトJISは、もともとは私企業によって作られたデファクト規格であった。
（2）それゆえに空き領域に各メーカーが勝手に独自の外字を収録して、結果的に文字化けの悲劇を生み出してしまった。
（3）この状況をJISとして解決するために、1997年に行なわれた0208の3回目の改訂の際、初めて規格に盛り込み明文化したのが、他ならぬ芝野耕司その人だった。
そして0213においても〈現状の使用環境で直ちに実装できる〉（『開発意向表明』[訂正] http://www.tiu.ac.jp/JCS/より）ために、当初からシフトJISによる符号化を意識した開発方針をとったのは、ついこの前、第3部第1回で述べた通り。というよりも、私はそのように理解していたのだ。しかし……。
ここで、ようやく前章で述べた疑問に戻る。なぜ芝野委員長は、シフトJIS系を定義する附属書1は参考でよいと真っ先に妥協したくせに、ISO-2022-JP系を定義する附属書2、日本語EUC系を定義する附属書3は、あくまで参考にすることを拒んだのか？ もしも本当に0213がシフトJISによる実装を目玉としていたのなら、附属書1こそ参考にすることを峻拒するべきではないか。芝野委員長はシフトJISに拘っていたのではなかったか？ なぜだろう？
工技院から開示を受けた9月の情報部会議事録には、芝野委員長の発言として以下のように記録されている。
〈議事録3枚目最終行～4枚目、3行目まで〉
芝野原案作成委員長
・附属書1に規定するShiftJISじゃ、もともと本体で規定する符号化方式とは異なる方式であることから、参考とすることは問題ない。
ただし、附属書2及び3は、本体規定と同じ符号化方式である。こちらで参考とするということは、本体規定と矛盾してしまう。これはどういう意味なのだろうか。前述したように、0213は本来ISO/IEC 2022の系統に属する文字コードだ。JISにはもうひとつ、ISO/IEC 10646（≒Unicode）の系統であるJIS X 0221があるのは前述した通り。逆に言えば、パソコン市場では圧倒的にシフトJISが支配的だった現実をよそに、JISにはこのふたつの系統しか存在しなかったのだ。シフトJISを97JISに盛り込んだ芝野委員長の意図がいかに画期的だったか、すこしはお分かりいただけるだろうか？
上の芝野委員長の発言は、JISの本来の系統として0213を考え合わせると理解することができる。附属書2も3もISO/IEC 2022のバリエーションであるなら、本来ISO/IEC 2022の系統である0213においては、規定である方がよりふさわしい。そういうロジックなのだろう。しかしその原則論には、かつて97JISにシフトJISを盛り込んだ野心家、あるいは実際の実装に目を向け、使われる規格を目指す理想家としての芝野委員長の面影は感じられない。だいたいが、妥協してよかったのなら制限の多いシフトJISに対応させることによって削られた文字は、浮かばれないのではないかという疑問も浮上するのだ。
なにより、0213は〈現行各社の独自文字が割り当てられている領域は含む〉（開発意向表明）と当初から声高らかに宣言し、従来のシフトJISと0213のシフトJISとの間で文字化けが起こることも覚悟の上、最終的に0213のシフトJISで市場が統一されれば問題は収束するのだという、いわば大見得を切って開発を開始したはずではないのか。もちろん、これらは承知のうえの妥協だったのだろう。附属書2と3の規定化を死守するためにも、最初に附属書1で妥協したということなのかもしれない。一番無念なのは芝野委員長のはずだ。しかし、それにしても……。
●要望書に署名したメーカーの名前は？
さて、話を日本IBMの取材に戻そう。2回目の情報部会の1週間ほど前、要望書を出した[*3]メーカー代表たちは、工技院の仲介のもとに、東京外語大にある芝野委員長の研究室をおとずれた。しかしそこでの話はやはり平行線をたどった。私は聞く。
[*3]……電子協から公開を受けた要望書の複写をPDFファイルで公開している。http://internet.watch.impress.co.jp/www/column/ogata/part2_10/youbousyo.pdf 「外語大に行かれたのは、日本IBMさん、NECさん……」榎本が記憶をたどるように答える。
「富士通さん、東條さん」ああ電子協の東條参事ですね、それから……、今度は斎藤がひきとる。
「それから、工技院」あっそうか、当然ですね。私には確かめたいことがあった。そこで私は説明する。
「じつは議事録だけ読むと、〈原案に対する要望書は、部会委員の他に、電子協会員である東芝、沖電気、三菱電機も連名〉とあって、部会委員の中に日本IBMとNEC以外にも署名しているメーカーがあってもおかしくないような書き方なんです。他に署名した企業というと、どこなんですか？」なんだ、そんなことかと言うように笑って斎藤がこたえた。
「いえ、議事録に載っていた通りですよ。ですから、あの要望書にサインしたのは私ども日本IBMとNECさん、他にこれこれと今社名を挙げられましたよね。あれ、全部その通りなんです。ですからあれから抜けてもいないし、足す必要もないんです」なーんだ、そうだったのか。通産官僚のもったいぶった表現のおかげで、よけいな憶測をしてしまったというわけか。私は斎藤に確かめた。じゃあ、他にはいないということですね？
「ええ、あれでおしまいです」なるほど、これで一件落着。私は質問の方向を変えた。
「それでは話を戻して、どうしてテクニカルレポート案から富士通案に方針を変更することにしたんですか？」うんうん、相変わらずの笑顔で斎藤は説明をする。
「結局テクニカルレポートにすると、かなりステータスが落ちますんでね。そうすると、まず工技院は顔が丸つぶれになりますよね。それから、芝野先生もこれ、大変なことになるでしょう。そうすると、そんなに不幸な人を出していいのかというのが正直あります。やっぱり、みんなこう丸く収まるのがよい案じゃないかというふうなね、そういう理由です。だって私どもも、文字集合自体は、すばらしいもんだと言ってるわけですから、それは否定する気持ちはまったくないわけですね。したがって、あの折衷案もいいところで出てきたなと」そうなってくると、聞きたいことが出てくる。私は頭の中の想像を言葉にしはじめた。
「あらかじめ要望書の内容を検討する時点で、附属書1から3を参考にするというのは、選択肢として考えておられなかったんですか」少しはするどいところを突いたつもりだったが、あっさり斎藤は答えた。
「正直言いますと、いくつかね、一番厳しいとこ、一番楽なとこと、いろんなケースを想定して、そのへんまでは頭の中にありました」ほう、選択肢のひとつとしてあったんですね。そう聞く私に、斎藤は答える。
「ええ、ありました。でもそこからスタートしたんじゃ、ねえ、どうしようもないじゃないですか」分かるでしょう？ 斎藤は同意をもとめるように笑った。そう、確かにそれがタフネゴシエーターの常道だ。私はうなずきながら言った。
「交渉としては、ガツンと一番厳しいところから始める。なるほど、よく分かりました」さて、情報部会のことについては、これで一応は全部聞いたことになる。次に私が聞きたいことは、日本IBMという会社が、0213の原案作成過程を、どのように見ていたかということだった。次週はこれについて、日本IBMの辛口批評を聞こう。
(2001/2/7)
[Reported by 小形克宏]