４．３　多言語対応システムの設計と運用の実際

国立情報学研究所実証研究センター長

宮　澤　　彰

1. はじめに

2000年1月から、目録所在情報サービスNACSIS-CATが多言語対応システムで運用されるようになり、その第一段階として中国語資料の本格的な取扱が始まった。この多言語対応システムが、どのように作られたか、また、その運用に係わるトピックを紹介する。

2. 多言語対応と文字コード

多言語対応（multi-lingual）と、多文字種対応（multi-script）は、密接に関係しているが異なる機能である。多文字種対応は複数の文字種（スクリプト）を扱える機能であり、多言語は複数の言語を扱える機能である。実は、NACSIS-CATは最初のシステムから、ラテンアルファベット（拡張文字セットEXCを含む）、カナ、日本語用漢字、ギリシャアルファベット（基本）、キリルアルファベット（基本）という多文字種を扱うことができたし、日本語の他に、ヨーロッパのほとんどの言語を扱うことができたので、多文字種多言語対応であったといえなくはない。そもそも、multi-lingual, multi-scriptという言い方は、文字セットとしてほとんど8859-1（WebブラウザのWesternやラテン1というencodingで使われる文字コード）しか扱えない欧米のシステムでいわれだしたことである。

しかし、旧CATシステムでは、漢字を扱えても、中国語を本格的に扱うことができなかった。文字コードとして、JIS X 0208とJIS X0201を中心に、EXCを加えたものをつかっているため、漢字には日本語用の漢字しかなかったためである。まして、ハングルも扱うことができなかった。

これらを改善するには、3つのアプローチが考えられた。第1は、EXCを拡張して中国語用漢字やハングルを扱う方法、第2は現用の文字コードのほかに中国語用やハングル用の別の文字コードも扱えるようにする方法、最後が必要なスクリプトがすべて入った大きな文字コードを使用する方法である。第1の方法は、EXCを実現している外字処理のコード領域の制限からほとんど実現性はなかった。第2と第3のアプローチを比べると、データベースアプリケーションの実現の点で、第3のアプローチが有利である。ちょうど80年代の後半にISOで10646UCSの開発が始まり、その利用を考えた。ISO10646UCSは1993年に成立したが、実用システムでの普及を待ったため、ようやく2000年になって運用にいたったものである。

したがって、多言語対応CATシステムはこのISO10646UCSコードを用いている。ただし、インタフェースではUTF8というコーディングを用いている。これは、32ビットまたは16ビットで表されるUCSコードを、8ビットの1〜6バイトの列として表すコーディング方法で、8ビットバイトを対象とした既存の通信、ファイル操作など多くのアプリケーションと共存できる方式である。

3. 新CATと多言語対応

新CATシステムは、その最初の設計時から、多言語対応を視野に入れて設計された。一方、旧CATもデータベースは多言語対応になっているが、インタフェースは従来の日本語用のもののみである。新CATはNACSIS-CAT/ILLのサーバシステムが、図書館側にあるクライアントシステムと、NACSIS/CAT専用の目録作成用プロトコルであるCATPでやりとりして（CATPはWebで使われるHTTPプロトコルの上にある応用プロトコルとなっている）動く仕組みになっている。

この、CATPではヘッダ等は英数字等いわゆるASCIIを使うが、検索条件やレコード本体などデータベース内容に係わる部分は使用文字コードを選べるようにしてある。多言語以前のシステムでは、ここには旧来のJISコード（EXCつき）のみが指定できたが、多言語システムでは、ここにGBコード（中国の標準コード）、KSコード（韓国の標準コード）などの指定を行えるほか、UTF8も指定できる。クライアントは、指定したコードでレコードのやりとりや、検索条件の指定をする。指定した文字コードにない文字は、◆U4E00◆のような形でコードで示される。

図書館側のシステムで使うCATPクライアントを、日本語環境の上に用意して、JISコードでやりとりするのが、従来の新CATクライアントであった。同様のものを中国語環境の上に構築して、GBコードでやりとりすれば、中国語用の目録システムとなる。ただし、こうすると、日本語用のシステムで中国語が（実際上）扱えないように、中国語用のクライアントでは日本語が（実際上）扱えなくなる。

CATPの使用コードをUTF8にして、UCSフォントを使えば、日本語も中国語も（その他の言語も）同時に扱う多言語クライアントを作成することもできる。

4. 漢字統合インデックス

UCSには2万字以上の漢字が含まれている。その中には、中国の簡体字も、日本のいわゆる新字体も含まれている。中国語資料では表紙が繁体字でも、タイトルページが簡体字で記された資料なども多い。これらは、情報源の字体にしたがって記述することになるが、検索の際に、これらの字体の差でヒットしなくなることは、検索漏れによる重複書誌作成などの問題を引き起こしやすい。（実は、日本語でも同じことで、「文芸春秋」といれても、「文藝春秋」はヒットしなかった。これを救うためにその他のタイトルとして「文芸春秋」がいれてある）。これを解決するため、漢字統合インデクスを作成した。

これは、「藝」と「芸」さらに中国の簡体字「草冠に乙」の字（この原稿はJISコードで

書いているために表すことができない）を、インデクスのうえでは同じに扱うものである。「文藝春秋」しか書いてない場合にも、「文芸春秋」で検索してヒットする。もちろん、記述のうえでは「藝」、「芸」、「草冠に乙」は別の字とされるし、表示も当然区別されるが、表示されないインデクス用のフィールドでは、これらの中の一つの字に変換されている。検索の際にも同じアルゴリズムで変換してからひくために、字体によらない検索が可能となるのである。

ただし、現在使用している漢字統合インデクスは、この字体関係を非常に広くとっている。「互換性のある」という言い方をしているが、「藝」と「芸」のようにほとんどの場合「互換性のある」ものばかりでなく、「才」と「歳」のように部分的にしか互換でないものも統合されるようにしている。（この場合、「20歳」と「20才」は互換性があるが、「才能」は「歳能」とは互換性がない）。このため、「機上」でひいても「机上」がヒットするという副作用もある。（「机」は現代中国語では「機」の簡体字であるが、日本語では別字と考えられる）。これらは、検索漏れを防ぐためにやむを得ないものと考えているが、今後の運用の結果によっては改良の必要があるかもしれない。

5. 記述用文字セットと外字

UCSには漢字が多いばかりでなく、これまでのJISX0208に含まれていない多くの記号類も含まれている。このため、これまで一文字としてあらわせなかったために、書き換え等別の手段で表していた文字が、UCSの文字として表現できるようになった。例えばローマ数字である。ローマ数字は、これまでアルファベットI, V, X等を使用して表現していた。（実は日本語Windowsではローマ数字をJISの空き領域に定義していて、使用したレコード例があった。旧CATではこういった空き領域の使用をチェックしていなかったため、他の環境で見ると未定義文字が現れてしまっていた)。UCSではローマ数字がある程度定義されている。したがって、UCSコードを使えば、ローマ数字を1文字として表現することは可能である。

しかし、問題は、こうすると、JISコードを使っている人にこの字が見えず、コード表示になってしまう点にある。また、参照MARCではアルファベットを使用してローマ数字を表記しており、これを自動的にローマ数字として認識するのは、それほどやさしいことではない。また、既にできているデータベースも、ローマ数字をアルファベットで表記している。UCSにローマ数字があるからといって、それを使用することにすると、こういった点が問題になるため、総合判断として、ローマ数字はアルファベットを使うという従来の方法を続けたほうが良いと考えた。UCSのローマ数字は不使用とするわけである。同様の理由で、結局、従来使っていたJISX0208とJISX0201にない記号類は不使用とすることにした。これまでと同様の方式で扱うことになる。

しかし、例えば新しいJISX0213にはこれらのいくつかの記号類も入っている。もし、JISX0213が広く普及する、あるいはUTF8が広く普及するということになれば、コード表示になるという問題はなくなるわけで、そうなれば、これらの文字を記述の表記に使用した方がよいという結論になることは考えられる。これらは絶対的なものでなく、この応用の世界で普及している文字コードとその利用度によって、相対的に決まるものであり、将来的に変化していくことを予定しなければならない。

なお、UCS化によって、NACSIS-CAT固有の私的拡張であったEXCをすべて、標準コードであるUCSに統合した。このため、上付き開始・終了などいくつかの文字は、廃止され、他の方法で表記することになった。

6. 目録規則の運用

多言語、多文字種のデータのために、書誌レコードに今回追加されたフィールドがある。その他のヨミとよばれるフィールドで、これまでのタイトル等のヨミフィールドに加えられた。これは、中国語のローマ字表記であるピンインなどを入れるためにできたフィールドで、UNIMARCの場合での異なるスクリプトでの並行フィールドにあたる。

ただし、中国語資料の場合、ヨミは必須であるが、ピンインはオプションとなった。今回の中国語資料の取扱でもっとも議論の多いところであろう。ピンインをオプションとしたのは、日本の図書館の目録作成者は中国語資料を扱っていても、中国語を本格的に学んだ人は少なく、若干の勉強とトゥールと経験とによって簡体字を読むだけで中国語資料の目録作成をしている（せざるを得ない）場合が多いという事情による。このため、目録作成作業の負担を大幅に増加させるピンイン入力は、オプションとすることになった。

この一方で、（日本語）ヨミを必須としている。中国語を日本語として読むのは当然無理があるが、本のタイトルの場合、かなりの割合で比較的容易に日本語として読むことができる。（いくつかの場合には、大変不自然な「ヨミ」を付けなければならなくなるのも事実であるが）。このヨミを分かち書きしておくことにより、日本語の場合と同じく、ヨミを手がかりにもとの文字列を語分割して、自動的に漢字でのキーワードを取り出すことができる。この方法は、NACSIS-CATの大きな特徴である。CHINA MARCのデータや米国OCLCの中国語データでは、漢字の語分割がなされていないため、タイトル中の語で検索することができない。米国RLINでは翻字での入力の際に、目録作成者が特殊記号を入れることによって語を認識する方式をとっているが、その方式よりははるかに容易に語分割を可能とする方式と考えている。ただ、このために、この方式で中国語目録を作成する人は、十分な日本語能力がないと作成できない、というやや皮肉なことにもなっている。

総合目録のレコード作成に適用される目録規則は、これまで、日本語資料がNCR、いわゆる洋書がAACR2としてきた。中国語資料の場合は、NCRを適用することになった。ただし、というのがついていて、場合により中国の目録規則に対応するための例外を設けることもあるとなっている。これは、主として、参照MARCとしてCHINA MARCを導入したことによるものである。CHINA MARCは当然中国の目録規則によっている（と思われる）が、これが、NCRと違う場合に、CHINA MARCからの流用入力ができず、人手による編集を加えなければならないという無駄を省くための条項である。具体的にどのような場合にこれを適用するかについては、実際のデータによる運用経験をふまえて決める必要があろう。

7. 今後の展開

今回の多言語対応システムは、システム的にはUCSで処理可能な文字種には対応できるものとなっている。しかし、ヨミを利用した検索用語分割のような処理は、文字種ではなく言語に依存する。また、漢字統合インデクスのような検索用処理も、一見文字レベルのようであるが、実は言語依存である。（仮に、漢字（字喃）で書かれたベトナム語も対象にすれば、漢字統合インデクスを増やさなければならなくなると言うことは、十分あり得る）。このため、今後の対応言語は順次増やしていく予定であるが、言語ごとに検討が必要である。当然、参加図書館の蔵書中所蔵が多く、要望の強いものが優先度が高く、中国語に続いては韓国・朝鮮語の処理を可能にすべく、検討を始めている。

UCSを使用して、多言語・多文字種処理を可能としたシステムは世界でもまだ、ほとんどない。しかし、欧米の大きな図書館システムベンダーが現在UCSによる多言語化に取り組んでおり、近い将来世界の潮流になるであろう。日本の図書館システムも、今日現在では本格的な多言語対応はできていないが、国際化の波はこのようなところにも及んでくると思われる。