第 13 部

自動翻訳

545

第 1章序論

1.1

背景PACCOM

コンピュータネットワークというものは、この度のの開通でもわかるように、現在、日本の中だけで行われているものではなく、日本とアメリカというように国と国の間で通信を確立するために使用されているものである。国家間での通信を行うということは、当然、異種の言語
ど うしでのコミュニケーションが必要になってくる。そこで考えられるのは、ネットワーク上において機械翻訳システムを使えるようにし 、異種の言語間でのコンピュータコミュニケーションを容易に行えるようにすることである。
ネットワークで機械翻訳システムを使えるようにするためには 、まずそのシステムを複数のユーザ（ホスト ）が共有できるようなものにしなければならない。つまり、自動翻訳（ 機械翻訳）サーバ：（）とそれを使用するためのクライアント：（）を設計し 、ネットワークにおける自動翻訳機構を構築しなければならない。これが実装されると、例えば日本語の文章をを送ったりして通信を行うことが英語に翻訳して日本からアメリカにできる。また、機械翻訳システムをやに組み込んで、直接日本とアメリカで通信を行うことも可能である。本論文では、自動翻訳サーバ）とそれを使用するためのクライアント（）を設計し 、これら（を実装し 、ネットワーク上で効率的に機械翻訳を行えるようにすることを目標とした。

Automatic TransAutomatic

lation Server ATS
Translation Client ATC

mailtalk phone

ATS

1.2

ATC

本研究の目的現在の機械翻訳システムは 、単なるアプ リケーションプログラムで 、データの入出力から翻訳までを単一のホストで行うようになっている。よってこのままでは、それぞれのホストに機械翻訳システムを稼働させて、し

547

548

1989 年度 WIDE 報告書

かも単一のホスト内で機械翻訳を行わなければならない。ネットワークをを稼働させるのは、資源利用できる環境で全てのホストにそれぞれの無駄使いであり、ネットワークの有効利用をしていないことになる。そこで、この機械翻訳システムを分散環境で利用できるサーバ型に改良して、複数のユーザ（ホスト ）が、あるいくつかのホストで稼働するサーバ型の機械翻訳システムを共有できるようにする必要がある。これによって、各ホストのコンピュータ資源の消費を軽減し 、広域分散環境においても機械翻訳がより効率的に行えるようにすることができる。
）とそれを使用するためのクライアント（）
自動翻訳サーバ（を設計する際に一番重要なことは、ホストとホストの間でのデータのやりとり、即ちクライアントとサーバ間のプロトコルをどのようにするかを決めることである。

ATS

ATS

1.3

ATC

本論文の構成本論文の構成は、第１章で本研究の背景と目的について述べる。第２章）
で機械翻訳システムについて述べる。第３章では、プロセス間通信（について考え、サンプルプログラムをもとに、インターネットでの通信を中心に、クライアント／サーバモデルについて、バーチャルサーキット型とトランザクション型の特徴と違いや問題点を述べる。第４章では、広域分散型機械翻訳システムを構築するにあたって、自動翻訳のためのクライ）と自動翻訳サーバ（）とをに割り当てるたアント（
めのスケジューリングサーバ（ ）をもとに考えられる６つのシステムモ
デルについて考察する。第５章でこの翻訳システムを実際にネットワーク
上に構築した際に、どのような通信の流れをなすか、またどのような特徴と問題点があるかを考える。第６章でこの翻訳システムの評価を行い、その結論と今後の課題を述べる。最後に謝辞及び参考文献をまとめる。

IPC

ATC

SS

ATS

ATC ATS

第 2章
機械翻訳システム

ここでは、機械翻訳とその応用について述べる。

2.1

機械翻訳とはコンピュータが世の中に登場して以来、科学技術計算を中心にいろい
ろな面でそれが役に立っている。しかし 、コンピュータに計算能力だけではなく人間のように思考する知的な能力を持たせることができないかということは、昔から現在に至るまで多くの研究者が考えてきた。その中の１つとして上げられるのが、機械翻訳である。
現在、機械翻訳システムはいくつかの企業から商品として提供され、実用化されている。しかし 、人間が行っても困難な翻訳をコンピュータにやらせようとするのだから、当然解決しなければならない課題も少なくない。これを克服するために、今もなお多くの研究者が機械翻訳に取り組んでいる。
2.1.1

機械翻訳の仕組み

機械翻訳とは、入力文（原文）を解析し 、コンピュータで処理できる内部表現（中間表現）を得たあと、その内部表現から翻訳対象言語の文（ 訳文）を生成する処理である。この処理を翻訳処理という。翻訳処理では 、言語に関する知識として辞書と文法を使う。
原文が書かれている言語を原言語と呼び 、訳文を書くための言語を目
標言語と呼ぶ。翻訳処理では、原文の解析は原言語について行い、訳文の生成は目標言語について行う。
原文の解析は、翻訳しようとしている文章の意味内容を辞書と文法を使って分析しその結果を計算機内部に表現する。このように文を解析して得られた文の構造を計算機内部で表現したものを中間表現と呼ぶ。この中
間表現の内容は原言語の性質を反映している。従って、この中間表現から訳文を生成するためには、これを目標言語の性質を反映する内容に直さな

549

550

1989 年度 WIDE 報告書

ければならない。そのための処理が中間表現の変換であり、原言語と目標言語を結び付ける辞書と文法を使って行う。
機械翻訳の処理には、大きく分けて２つの方式がある。１つは上記のように中間表現の変換を必要とするもので、これを変換方式またはトランス参照）。中間表現を言語に依存しない内容で表ファ方式と呼ぶ（
しておくと、中間表現の変換は必要なくなる。このように、中間表現の変換を行わないものを、中立言語方式またはピボット方式と呼ぶ（参照）。一般に、中間表現が構文的な内容を表すときはトランスファ方式となり、意味的な内容を表すときはピボット方式となる。これらの処理形
態を簡単に示すと、次のようになる。目標言語に関する辞書と文法を使って、この変換された中間表現から訳文を生成する。

Figure2.1

Figure2.2

1. 構文トランスファ方式（構文的な構造を中心に解析）(a) 入力文の解析(b) 入力文を記述している言語の性質を反映する中間表現の作成(c) 訳出文を記述している言語の性質を反映する中間表現への変換(d) 訳出文の生成
2. 意味ピボット方式（構文的な構造と文の意味内容をもとに解析）(a) 入力文の解析(b) 入力文を記述している言語の性質を反映する中間表現の作成(c) 入力文を記述している言語の性質を反映する中間表現の解析(d) 言語に中立な内容を示す中間表現の作成(e) 訳出文を記述している言語の性質を反映する中間表現の生成(f) 訳出文の生成
2.1.2

これからの機械翻訳システム

１９７０年代に構文トランスファ方式のシステムが出現するようになった。構文解析の方法は、大きく分けて句構造文法と依存文法がある。句構
造文法は、名詞句や動詞句などの句単位に文の構造をまとめる文法である。
また依存文法は、語と語の依存関係によって文の構文構造を与える。両方
とも表現能力は同じであることが証明されている。しかし 、システムの検証が進むにしたがって、構文の理解だけでは言語が持っているあいまいさを解決するには十分でないということが分かってきた。そこで、１９８０

第 13 部

551

自動翻訳

入力文

訳出文

CC

33 3

解析

C

CC
C

CC

C

CC
C

CC

C

CC

原言語
中間表現

図

33

CCW
変換

33 3

33 3

33 3

33 3
33

生成

- 目標言語中間表現

2.1: 構文トランスファ方式

構文的な内容552

1989 年度 WIDE 報告書

入力文

訳出文

BB

2
2
22 2 生成

解析

BB
B
BB
BN

22 2

目標言語
中間表現

原言語
中間表現

1
11

AA

A
AA
解析

A
AA
AU

1
1
1

1
1
1 生成

言語に中立な
中間表現

図

構文的な内容2.2: 意味ピボット方式

意味的な内容第 13 部

自動翻訳

553

年代に意味理解を重視したピボット方式のシステムが出現するようになった。これは、日本の企業が中心となっている。なぜならば 、英語や仏語よりも日本語の方が意味理解をより重要としているからである。意味理解を行うためには、人が言葉を理解するために用いているような知識や常識を必要とする。つまり、意味理解のための知識ベースを確立しなければならない。ところが、この意味に関する情報を収集するには莫大な労力と時間が必要なので、今もまだ発展している段階である。
機械翻訳システムの技術は、かなり進歩してきているが、まだ解決されるべき課題も多い。完璧な翻訳システムを目指すことは大変難しい。しかし 、何百万もの専門用語を記憶しておくなど 、人間よりもコンピュータの方が適しているようなこともいくつかある。従って機械翻訳は、まず第一に計算機でなければできないような処理を行うようにし 、翻訳者を支援することが目的である。この考え方は、これから先も変わることはないだ
ろう。

2.2

ネット ワークにおける機械翻訳

すでに述べたように、ネットワーク上で機械翻訳システムを効率よく利用するためには 、このシステムをサーバ型に改良しなければならない参照）。通信という観点からネットワークを眺めてみれば 、この（）の設計及びこれによる翻訳機構というものは、い自動翻訳サーバ（
ろいろな意味でこれからのネットワークを支える基盤となるものであることは言うまでもない。

Figure2.3

2.2.1

ATS

多言語間の機械翻訳

世界中をコンピュータネットワークで張り巡らしている現在においては、それを使って国際的にコミュニケーションを行おうとすることは自然なことである。それにはまず、できる限り多くの言語の機械翻訳システムがあることが望ましい。しかし 、そのシステムを開発するとなると、多大な労力を必要とする。また、翻訳者が少ない言語のシステムを開発するのも大変である。しかし 、言語間で共有できる中間表現や知識を少しずつ収集していけば 、より多くの言語の機械翻訳システムを作り上げることも可能になるだろう。
2.2.2

talk や phone への機械翻訳システムの応用

我々はコンピュータネットワークにおいて、端末上で会話を行うとき
に、
や
を使う。
は二人のユーザが会話をするときに使用し、talk phone

talk

554

1989 年度 WIDE 報告書

ATS
日
英

-英
-日

6

6

英

?

日

?

クライアント(ホスト )

図2.3: 自動翻訳機構

Lisp ,C 言語
C 言語
C 言語

第 13 部555

自動翻訳

phone は二人以上のユーザが会話をするときに使用する。通常の phone は
ローマ字かひらがなでメッセージの交換を行うが、これに機械翻訳を組み込
んで日本語のメッセージを英語に変換して送ったり、英語のメッセージを日本語に変換したものを受け取ったりして会話を行うことを考える（
参照）。これが実現されれば、国家間でのコンピュータコミュニケーション
もやりやすくなる。
しかし 、実際にはかなり多くの問題が考えられる。最大の問題は、通信時間のことである。本研究で使用する機械翻訳システムは、株式会社で開発された上で動作するもので 、によって書かれている。終止符（ 。）で終わるまでの一文を入力して結果を得るまでにややや時間がかかる。通信時間が限りなく０に近づくことを望まれる
では、これは深刻な問題である。解決法としては、まず翻訳システ
ムそのものを改良することが考えられる。ところが、これは長年の技術と経験があってこそできることなので、ここでは別な方法を利用することに着目する。ソフトウェアからのアプローチではなく、ハード ウェアからのを持つマシンに翻訳システム
アプローチを考える。つまり、高速のを乗せることによってこの遅さをカバーしようとするのである。自動翻訳）を高速のの上で実装することによってどれだけ遅さ
サーバ（がカバーされるかについては、実際に試してみないとわからないが、金銭の問題をあまり考えなければ 、これが翻訳処理時間の短縮につながることは言うまでもない。
他の問題点としては 、日常会話を十分に扱えるほど 翻訳機構が整備されていないことや、翻訳できない部分を含むような文章をどのように扱ったらいいかとか、一文全体を翻訳し終えるまで相手に送るのを待たなければならないのかということが挙げられる。科学技術に関する文章を翻訳するのは割と容易であるが 、さまざまな言い回しがある日常会話を翻訳するやに限らず機械翻訳全体におけことは容易ではない。これはる課題である。まず、辞書の整備から行わなければならないだろう。また、
翻訳できない部分が存在する文章は、ユーザの手直しを必要とする。つまり、一度サーバから送信者にその文章が返されて、完全に翻訳しなおした
ら、受信者に再転送される。翻訳は一文全体が揃わないと行えないので、文単位で相手に転送することになる。
の実現はかなり難しい
これらの問題点を考えると、が、これは将来のネットワークにおいて絶対に必要なものであると思う。

Figure2.4

SUN workstation

Lisp

CSK

talk

phone

CPU

ATS

CPU

talk phone

Translation Phone556

1989 年度 WIDE 報告書

ATS
日
英

Lisp ,C 言語

7

英

/

J]J
J日
JJ
^

2

ホスト

ホスト

(アメリカ)

図

-英
-日

(日本)

2.4: Translation Phone

C 言語
1

C 言語

第 3章
プロセス間通信（ IPC ）コンピュータネットワークのもとでは、あるホストで動作しているいく
つかのサービスを提供するプロセス（プログラム）に、別のホストからデー
タを送信してその結果を受信するようなことがある。このデータを送受信するものも１つのプロセスである。このように、あるプロセスと別のプロセスの間で行われるようなデータの送受信をプロセス間通信（
）
：
と呼ぶ。
４ ３
は
のためのい
くつかの方法を提供している。ここでは、インターネットド メインのスト
リーム転送とデータグラム転送を中心に述べる。

communication IPC [63]3.1interprocess
UNIX . BSD IPC

ド メインとプロト コル

プロセスとプロセスの間でコミュニケーションを行おうとするとき、それらが独立に生成されたものであるならば 、どのようにすればよいのだろうか。ここで考えられるのが、２つのプロセスがそれぞれにソケットを生４
成し 、それらの間でデータメッセージを送受信することである。
３では、個々にソケットを生成し 、それらに名前を与えて、それらの間で通信を行うことをサポートしている。
各々のプログラムで生成されたソケットは 、お互いが問い合わせをするための名前を使用する。その名前は、使用されるときにはネットワーク
アドレスに変換される。このようなアドレスが記述されている空間をド メ）と呼ぶ。ソケットのためのド メインはいくつかあるが、そイン（の中でよく知られているものが次の２つである。

UNIX .

BSD

domain UNIX ド メイン
 インターネットド メイン

UNIX ド メインでは、ソケットは、ファイルシステムの名前空間内でパスネームを与えられる。ファイルシステムノードがソケットのために生成

557

558

1989 年度 WIDE 報告書

されて、他のプロセスは、そのパスネームを与えることによってソケット
ド メインは、同一ホスト内で動作すに問い合わせをする。よって、るプロセス間での通信を提供する。インターネットド メインは、
インターネットの標準プロトコルである／／の上での実装である。インターネットド メインでのアドレスは、ネットワークア
ドレスとポートと呼ばれる識別番号から成る。よって、インターネットド
メインは、ホストとホストの間での通信を提供する。つまり、異なるホストで動作するプロセス間での通信を提供する。
通信の形態には次の２つの種類がある。

UNIX

DARPA
IP TCP UDP UNIX ストリーム型
 データグラム型
ストリーム型の通信は、２つのソケットの間でコネクションをつないで行う。これは、信頼性があり、送信するデータに誤りがあるかど うかを気にする必要がなく、メッセージデータに境界がない。送られてくるデータが大きすぎて全部を受信できるほどのメモリーが空いていないときは、デー
タの一部だけを読むこともできる。ストリーム型の通信を実装するプロト
コルは、エラーとともに受信したメッセージを再転送する。また、コネク
ションが切れたあとでメッセージを送ろうとすると、エラーメッセージが返ってくる。データグラム型の通信は、コネクションを使用しない。各々のメッセージは、直接送り先のアドレスを指定して送信される。そのアドレスが正しければ 、一般には相手に受信されるが、その保証はされていない。従って信頼性がないのである。データグラム型の通信は、受信者からの応答を求めてくるような要求を出すために使われることがよくある。適正な時間内にその応答が到着しなければ 、その要求は繰り返される。また、データグラム型のメッセージには境界が存在し 、読まれるときは分割されている。
ストリーム型の通信において、コネクションを確立するためのコンピュー
タ資源の消費は、コネクションを頻繁に使用してはじめて正当化される。また、データグラム型の通信において、失われたメッセージをただ無視していると、トラフィックの量は重大な問題になる。プロトコルの動作は、ネットワークの状態が変わると、それにつれて変化するから、プロトコルの動作が大きく影響を及ぼすようなプログラムでは、最近のネットワークの情報を得て、それによってプロトコルを選択することが望まれる。
）とは、データフォーマットや通信関係者の間でプロトコル（のデータ転送に関する決まりというような一連の規則である。一般には 、各々のド メイン内で、各々のソケットの型に対して１つのプロトコルがあprotocol第 13 部559

自動翻訳る。プロトコルを実装しているコードは 、ソケットにバインド される名前のトラックを保持している。その名前によって、コネクションを確立し 、ソケットの間でデータ転送を行う。いくつかのプロトコルが、ある特定のドメイン内で同じ通信の型を実装することは可能である。また、使用するプ
ロトコルを選択することは可能であるけれども、ほとんどすべての使用において、デフォルトのプロトコルを要求すれば十分である。インターネット／を使用し 、デード メインでは、ストリーム型の通信においては
タグラム型の通信においては／を使用する。

TCP IPUDP IP

3.2

クライアント ／サーバモデル

現在の機械翻訳システムは、それが動作しているホストからデータを入力して翻訳された結果をそのホストに出力する。ネットワークが確立されている以上は、この翻訳システムをあるホストで動作させておいて、別のホストからデータを入力して翻訳された結果をこのホストに出力されるようにしたいものである。つまり、翻訳というサービスを提供するプロセ
スとデータの入出力（送受信）を行うプロセスとの間の通信を確立させるわけである。このように、いくつかのサービスを提供し 、ネットワークを通して到着した要求を受け入れて、そのサービスを実行し 、要求を出した）と言い、このサーバ
ものに結果を返すようなプログラムをサーバ（に要求を送り、応答を待つことを行うプログラムをクライアント（）と言う。クライアント／サーバモデルの動作原理は、次のようになる。

serverclient1. サーバを起動する
2. サーバはクライアントからの要求を待つ
3. クライアントからサーバへ要求を送信する
4. サーバはクライアントから要求を受信する
5. サーバは子プロセスを生成する
6. サーバの子プロセスはその要求を処理し 、プロセスを終了する
7. クライアントはサーバの子プロセスからの応答を受信する
8. サーバの親プロセスは再びクライアントからの要求を待つ
クライアント／サーバモデルのサンプルプログラムとして、英小文字から英大文字への変換と英大文字から英小文字への変換とローマ字からひら560

1989 年度 WIDE 報告書

がなへの変換の３つのサービスを提供するサーバプログラムと、このサーバにデータを送信して変換された結果を受信して出力するクライアントプ
ログラムを作成した（付録１参照）。バーチャルサーキット型とトランザクション型の２種類があるが、これについての詳しいことは３ ３で述べるこ
とにする。

.

通常サーバは 、提供するサービス用に予約されているポート番号を使用する。ポート番号は、ソケットの識別子のために使われる。しかし 、この作成したサーバは予約されているポート番号を持つサービスを提供しないので、予約済みでないポート番号を使わなければならない。まず始めは０のポート番号を指定しておく。それからソケットにバインド すると、が適当なポート番号を割り当ててくれる。これによってサーバは動作を開始し 、クライアントの要求を待つ。

OS

クライアントは、このサーバが動作しているホスト名と指定されたポー
ト番号を使ってサーバに要求を出し 、応答を待つ。サーバはクライアントからの要求を受信したら、ストリーム転送のサーバにおいては、フォークして子プロセスを作り、これに要求の処理をさせて、親プロセスは別のクライアントからの要求を待つ。データグラム転送のサーバにおいては、シーケンシャル処理なので、順番に要求を受信し処理していく。クライアント
は結果を受信したら、また要求を出すか動作を終了する。すべてのクライ
アントが動作を終了しても、サーバは動作を終了することなく永久にクライアントからの要求を待つ。サーバは、強制的に止められる以外は動作を終了することはない。

3.3

バーチャルサーキット 型とト ランザクション型

インターネット標準のトランスポートレベルプロトコルには、２つのプロトコルが存在する。１つは、信頼性のあるストリーム転送を提供するもの（）と呼ばれる。もう１つは、で、（信頼性のないデータグラム転送を提供するもので、）と呼ばれる。バーチャルサーキット型は、によるストによるデータグラム転
リーム転送を使用し 、トランザクション型は、、参照）これらの動作原理を簡単に示
送を使用する。
（
すと、次のようになる。

TCP Transmission Control Protocol [14]Protocol [14]Figure3.1 Figure3.2

UDP User Datagram
TCP
UDP

1. バーチャルサーキット型(a) クライアントからサーバへ使用したいサービス番号を送信する

第 13 部

561

自動翻訳

V: TCP を使用
C

UL 使用要求
message
resultmessageresult



RH

6
?

-

サービス変更要求

message result
RH 終了要求
サービス終了要求

-

- OK
- OK
- OK

- OK
- OK

RH: ローマ字→ひらがな
UL: 大文字→小文字
LU: 小文字→大文字

図

S
6
?

-

UL 終了要求

RH 使用要求
message
result- OK

3.1: バーチャルサーキット型

LU

 - UL562

1989 年度 WIDE 報告書

T: UDP を使用
C

RH

6
?

-

RH-message

resultRH-message

LU-message

LU-message

resultresultresult

サービス終了要求-- OK

RH: ローマ字→ひらがな
UL: 大文字→小文字
LU: 小文字→大文字

図

3.2: トランザクション型

S
6
?

LU

 - UL第 13 部563

自動翻訳(b) サーバはそれを受信したら、クライアントからのデータメッセー
ジを待つ(c) クライアントはサーバにデータメッセージを送信する(d) サーバはそれを受信したら、処理して、クライアントに送り返す(e) あとは、このデータメッセージの送受信だけを繰り返す
2. トランザクション型(a) クライアントからサーバへ使用したいサービス番号とデータメッ
セージをいっしょに送信する(b) サーバはそれを受信したら、サービス番号に従って処理して、クライアントに送り返す(c) あとは 、このサービ ス番号＋データメッセージの送受信を繰り返す
ここでは、このクライアント／サーバモデルの２つの形式について詳しく述べることにする。なおこれから先においては、バーチャルサーキッ
ト型のことを 、トランザクション型のことを と書くことにする。

V

3.3.1

T

インターネットド メインでの通信

netinet/in.h

インターネットド メインのアドレス構造体は、＜＞ファイルに定義されている。ソケットのアドレスはホストのアドレス（ ３２ビット ）とそこでのポート番号を明確にする。ポート番号は特定のプロトコルを実装しているシステムルーチンによって管理されている。ホスト間でメッ
セージデータが送られるとき、それはまずデスティネーションホストのプロトコルルーチンに送られて、そのプロトコルルーチンがメッセージを送るべきソケットを決定するために、いっしょに送られてくるデスティネー
ションアドレスを解析する。いくつかの異なるプロトコルが同じホストで稼働しているが、それらが同じポート番号を使用することは許されている。
そこで、ソケットのアドレスは、ホストアドレスとポート番号とプロトコルタイプの３つから構成される。ソケット間で通信を行うとき、相手を明確にするために、プロトコルタイプ、ローカルホストアドレス、ローカル
ポート、リモートホストアドレス、そしてリモートポートを使用する。デー
命令がタグラムソケットを使用する場合、相手を明確にするものは、作用している間だけ必要になる。
ソケットが生成されるとき、それのためのプロトコルが選択される。クライアントから見て、サーバのソケットのためのローカルホストアドレス

send

564

1989 年度 WIDE 報告書

は、明確なホストのネットワークアドレスが必要である。サーバの動いているホストのアドレスを得るために 、サンプルプログラムのサーバでは 、を呼んでホスト名を得て、それからを呼んでホストのアドレスを得ている。これを用いて、ソケット用の構造体のアドレスをセットする。また、サーバ自身は、必ずしも自分の動いている
ホストのアドレスを知る必要はないので、ソケット用の構造体のアドレス（０）にセットすることもできる。
をワイルド カードである
サンプルプログラムのサーバを起動させるときに、オプション をつけるとこの場合になる。アドレスが不確定のところからデータを受け取ることは可能であるが、アドレスが不確定のところにデータを送ることはできない。従って、クライアントの方は、まずコマンド 行の引数からデスティネー
ションホストの名前を得て、メッセージを送るためのネットワークアドレ
を呼んでホストのスを決定するために、サーバと同様にアドレスを調べる。そして、ホストのネットワークアドレスを含む構造体が返されて、そのアドレスがメッセージのデスティネーションを明確にするための構造体へコピーされる。

gethostname()gethostbyname()

INADDR ANY

agethostbyname()port number）とは、郵便箱のような数字であって、プロ
ポート番号（トコルはそこにメッセージを置く。公示されているサービスを提供するあ、るデーモンは、あらかじめ予約されたポート番号を持っている（参照）。これらは 、１から１０２３までに予約されている。このとの２２つの表を見てもわかるように 、前で述べたような、つのプロトコルが同じポート番号を使用していることが示されている。これより大きな数字が、一般のユーザが利用できる数である。サーバだけが特定の数を要求する必要がある。アドレスがソケットにバインド されるとき、システムが未使用のポート番号を割り当てる。ソケット用の構造体に０のポート番号を入れておいてバインド するときか、バインド されていなしたりするときにこれが起こる。ポートいソケットにコネクトしたり
番号は自動的にユーザに知らされるわけではないから、ポートを０にしてを呼び出したあと、を呼び出して、実際に割り当てによって返さられたポート番号を調べなければならない。
れる値はネットワーク表現の数なので、これをホスト表現の数に変換しなというルーチンを呼んければならない。サンプルプログラムでは、
でこれを行っている。

Table3.1

Table3.2

TCP UDPsendbind()

getsockname()

getsockname()

ntohs()

ストリーム型のソケットの間でデータ交換を行うときは、そのソケットの間にコネクションをつながなければならない。クライアントの方は、コネクションを確立するために、ストリーム型のソケットを生成したら、コを呼び出してい
ネクトしたいソケットのアドレスを明確にして、

connect()

第 13 部

Decimal

0
1-4
5
7
9
11
13
15
17
19
20
21
23
25
37
39
42
43
53
67
68
69
75
77
79
95
101
102
113
118
123
133-159
160-223224-241247-255
表

Keyword

自動翻訳

Description

Reserved
Unassigned
RJE
Remote Job Entry
ECHO
Echo
DISCARD
Discard
USERS
Active Users
DAYTIME
DaytimeNETSTATWho is up or NETSTATQUOTE
Quote of the Day
CHARGEN
Character Generator
FTPDATA
File Transfer Protocol(data)
FTP
File Transfer Protocol
TELNET
Terminal connection
SMTP
Simple Mail Transport Protocol
TIME
Time
RLP
Resource Location Protocol
NAMESERVER Host Name Server
NICNAMEWho Is
DOMAIN
Domain Name Server
BOOTPS
Bootstrap Protocol Server
BOOTPC
Bootstrap Protocol Client
TFTP
Trivial File Transfer
any private dial out service
any private RJE service
FINGER
FingerSUPDUPSUPDUP Protocol
HOSTNAME NIC Host Name Server
ISO-TSAP
ISO-TSAP
AUTH
Authentication Service
UUCP-PATH UUCP Path Service
NTP
Network Time Protocol
Unassigned
Reserved
Unassigned
Unassigned

3.1: 予約されている TCP ポート番号の例

565

566

1989 年度 WIDE 報告書

DecimalKeyword

Description

0
Reserved
1-4
Unassigned
5 RJE
Remote Job Entry
7 ECHO
Echo
9 DISCARD
Discard
11 USERS
Active Users
13 DAYTIME
Daytime15 NETSTAT
Who is up or NETSTAT
17 QUOTE
Quote of the Day
19 CHARGEN
Character Generator
37 TIMETime
39 RLP
Resource Location Protocol
42 NAMESERVER Host Name Server
43 NICNAME
Who Is53 DOMAIN
Domain Name Server
67 BOOTPSBootstrap Protocol Server
68 BOOTPCBootstrap Protocol Client
69 TFTP
Trivial File Transfer
75
any private dial out service
77
any private RJE service
79 FINGER
Finger123 NTP
Network Time Protocol
133-159
Unassigned
160-223
Reserved
224-241
Unassigned
247-255
Unassigned
表3.2: 予約されている UDP ポート番号の例

第 13 部

567

自動翻訳る。目的のソケット、つまり、サーバのソケットが存在して、コネクションを処理する準備をしているならば 、コネクションは完成し 、クライアント
はサーバに要求を出し始めることができる。クライアントからのメッセー
ジは 、順序よくサーバに送られる。おのおののソケットが閉じられると、コネクションが切れる。コネクションが切れたあとにプロセスがメッセー
シグナルを送る。そジを送ろうとすると、 がそのプロセスにのプロセスは、そのシグナルを受信するとただちに終了する。

OS

SIGPIPE

サーバの方は、ソケットを生成し 、それに名前をバインドして、それからクライアントからの要求を受け付け始める。サンプルプログラムでは、を呼んでいる。いソケット番号を出力して、このソケットのために
くつかのクライアントが同時にコネクト要求を出した場合、未処理のコネクションのための待ち列をシステムアドレス空間に維持しなければならなは、コネクションを待ち受けようとするソケットに印をつけ、い。
待ち列を初期化する。コネクションが要求されると、それは待ち列に入れられる。待ち列がいっぱいになったら 、エラー状態が要求者に返される。
の２番目の引数で定義される。そして、そこの待ち列の最大長は、が呼ばれると、の最大長は、システムによって限られている。一度サーバは無限ループに入る。ループを回るごとに、新しいコネクションが受け入れられ、待ち列から取り除かれて、そのコネクションのための新しいソケットが生成される。コネクションが生成されたら、サーバはフォー
クして子プロセスを作り、親プロセスはコネクションソケットを閉じて再びクライアントのアクセプトを行い、子プロセスはサービスを実行してコは待ち列からの未処理のコネクト
ネクションソケットを閉じる。
要求を受け付けるか、要求を待ちながらブロックする。メッセージは、コネクションソケットから読まれる。つながっているコネクションでをで返される値は、
行うと、データを受信するまでブロックしている。
読み込まれたデータのバイト数である。コネクションが切れると、リードコールが直ちに返される。そのときに返されるバイト数は０である。

listen()listen()listen()listen()accept()read()

3.3.2

read()

両者の特徴と違い

V の方は、TCP を使用しているので、クライアントのソケットとサー
バのソケットの間でコネクションが確立されている。従って、クライアン
トはまず最初に使用するサービス番号だけをサーバに送信し 、その後からデータを送信する。１つのクライアントプロセスに対して１つのサーバプ
ロセス（フォークされた子プロセス）が動作し 、その間でコネクションが確立されているので、それぞれのクライアントが 、各々に使用したいサー
ビスを並列して同時に使うことができる。また、サーバは並列処理をして

568

1989 年度 WIDE 報告書

いるから、１回の変換処理においてバッファサイズを越えるデータを扱うことができる。つまり、文字列終了文字を受信するまでは一連のデータであると判断し 、それまでデータをためておくことができる。それから変換処理を行って、処理結果をバッファサイズごとに分割してクライアントに
送信する。

T

UDP

の方は、
を使用しているので、クライアントのソケットとサー
バのソケットの間でコネクションが確立されていない。従って、クライア
ントは使用するサービス番号と変換するデータの組をサーバに送信する。
サーバはシーケンシャル処理で受信データを扱っているので、１回の変換処理において受信用バッファサイズを越えるデータを扱うことはできない。
クライアントがサービス番号と変換すべきデータをいっしょに送ろうとして、データが送信用バッファサイズを越えたとき、次に越えたデータだけを送ったとしても、サーバの方はそのデータがどのクライアントのどのデー
タに続くものなのかを判断することは困難である。よって、クライアントとサーバのそれぞれのバッファサイズの範囲内で１回の処理が行われる。

V の方は、クライアントとサーバの間にコネクションが確立されているので、データの送信において送り先のアドレスは必要ない。よって、プロという関数を使用する。逆
グラムでは、引数にアドレスを含まないに の方は、クライアントとサーバの間にコネクションは確立されていないので、送り先のアドレスが必要になる。よって、プログラムでは、引数という関数を使用する。この場合、データを受信にアドレスを含むするときは送り元のアドレスを必要とするので、プログラムでは、引数にという関数を使用する。 の方は、データを受信
アドレスを含むするときに送り元のアドレスを必要としないので、プログラムでは、引数という関数を使用する。
にアドレスを含まない

write

T

sendtorecvfromV

read

V の方は、クライアント側が途中で使用するサービスを変更しようとす

るとき、それをサーバに知らせるためにサービス変更文字を送信する必要がある。両者とも、クライアントが１回のソケットの生成で何回も連続してサービスを使用できるようにしてあるので、外面的にはどちらも変わりはない。しかし 、 の方は一回の実行ごとに選択するサービスの識別番号
をクライアントからサーバに送らなければならないのに対し 、 の方は最初にそれを送ればコネクションをつなげてあるので、あとはデータだけを送ればよいので、そのことだけを見れば の方がサービス選択のエラーが生じやすい。しかし 、 の方はコネクションをつなげていないので、サーバがクラッシュしたときにはそのリセットは よりもやりやすい。つまり、の方はリセットしたら切れたところから始められるが、 の方はまたコ
ネクションをつなぎなおさなければならない。また、実行速度はほとんど

T

V

T

T

T

V

V

第 13 部569

自動翻訳

違いがない。
エラーリカバリーにおいては、 の方は使用サービスの決定とメッセー
ジ交換が分かれていて、 の方は両方ともいっしょであるので、 の方がよりもエラーの検出と修復がいくらかやりやすい。
サンプルプログラムでは 、サーバは変換処理を行うときに２つのテン
ポラリファイルを使用するので、それが他のプロセスからアクセスされないようにしなければならない。そこで、このプログラムでは、両者ともテをファイル名に使用して、そンポラリファイルを作るとき、プロセスの後で、そのファイルを消去している。 の方は、フォークして子プロセスにサービ スを実行させるので、子プロセスが自分のプロセスを使ってテンポラリファイルを作る。つまり、親プロセスがフォークした分だけテンポラリファイルが用意される。

T

T

V

V

ID
V

3.3.3

ID

加えるべき制御機構

両者とも、ユーザがサーバのサービスを使用する前に、どのようなサービスがあって、現在動作しているサービスはどれなのかをメニューの形式
で知らせる必要がある。これは、クライアントがサーバと最初の通信を行う前にユーザに知らせなければならない。現在動作しているサービスがどれなのかを自動的に調べるようなプログラムはないので、今のところは管理者が定期的に調べるしかない。サンプルプログラムでは、ユーザが使用するサービス番号とデータの入力方法をメニューから選択するようになっている。
また両者とも、クライアントの１回のソケットの生成で連続してサービスを使用できるようにしなければならない。サンプルプログラムでもわかるように、この機構はクライアントに依存されている。従ってサーバは、ただ到着したデータを受信して処理し 、クライアントに送り返している。
3.3.4

問題点

提供されるサービスが正しいかど うかを調べることは非常に難しい。テストのためのファイルを用意してそれを使って確かめてみることもできるかもしれないが、この場合、このようなファイルを用意すればいいと決めることはかなり困難である。転送されるメッセージが正しいかど うかは 、クライアント側にそれをエコーバックさせて知ることもできる。しかし実際のところ、このような単純な方法ではちょっと頼りないものがある。
適当なバッファの大きさを決定するのもかなり重要である。サンプルプ
ログラムの の方は、クライアントにおいては、送信用が２０４８で受信用が４０９６に指定してある。サーバにおいては、送信用も受信用も４０

T

570

1989 年度 WIDE 報告書

９６に指定してある。サーバが処理した結果のバイト長が 、クライアントが送信するデータのバイト長の二倍を越えることはないので、このような大きさに設定してある。クライアントのデータの送信において、一度に２０４７文字を越える文字列を扱うことができない。しかし の方は、クライアントのデータの送信において、一度にバッファサイズを越える文字列を扱うことができるので、クライアントもサーバも２０４８に指定してあを呼びる。バッファサイズを越えるデータを扱うときに、送信側の出す回数と受信側のを呼び出す回数が同じになるように、クライア
ントとサーバのバッファサイズを等しくしてある。さらに も も、入力
ファイル名の文字数の合計が一度に２０４７を越えたら、２０４７文字目のところまでしか扱うことができない。２０４７文字を越えようとしたら、強制的に入力を終了する。しかし 、入力ファイル名の方の問題は実際に起こる可能性は０に等しいので、考えなければならないのは のバッファサ
イズの問題である。実際のサービス処理の能率を考えて、適当なバッファ
サイズを選択しなければならない。

V

write

read

V T
T

3.3.5

サンプルプログラムにおける注意点

サーバプログラムを見てわかるように、ローマ字をひらがなに変換するために配列にひらがなの五十音を入れている。この配列に納められていモード
るひらがなを使って変換を行うときは、ソースプログラムをにしてコンパイルを行わないと、実行可能のサーバプログラムが作成されない。よって、このサンプルプログラムのサーバとクライアントを使用す
モードにする必要がある。
るときは、画面を

EUC

EUC

a

サーバには、前で述べたように、起動するときに というオプションをつけることができる。このオプションをつけると、どんなホストでも起動するが、つけないと、ホストによっては起動しないこともある。

D

コンソール入力で一度＾ を使用すると、それから後のコンソール入力
がブロックされてしまう。よって、入力の終了は、すべて「
」「
」
で行う。

RET . RET

配列に納められている「？＊＠」の３文字の文字列と、コンソールから入力される「？＊＠」の３文字の文字列では、コードが違うので、それぞれ区別される。よって、バーチャルサーキットにおいてクライアントが、サービス継続／変更文字である「？＊＠」の３文字の文字列を、データメッ
セージとしてコンソールから入力してサーバに送信しても別に問題はない。
ローマ字からひらがなに変換するときは、英小文字によるローマ字だ
けが変換対象文字として判断され、英大文字などの他の文字は、そのまま出力される。

第 13 部「ん 」と母音が続くときは、間に

自動翻訳

571

x を入れる。

tani=) たに
tanxi=) たんい
tanka=) たんか
UNIXの規則において、１つのファイル名は２５５文字以内でスペースは含まないようにすることになっているので、これをもとにプログラムは作成されている。

第 4章
広域分散型機械翻訳システムの設計

Lisp

ネットワーク上に機械翻訳システムを構築するためには、で稼働する機械翻訳プロセスに、第３章で述べたプロセス間通信の考えを応用させなければならない。この章では、実際にそれを行っていくためのいくつかの方法を考察し 、詳しく述べることにする。

4.1

ネット ワークにおける自動翻訳機構の確立

ネットワーク上に広域分散型機械翻訳システムを構築するとき、それは大きく分けると次の３つのプロセスから成り立つ。

 自動翻訳のためのクライアント（ Automatic Translation Client : ATC） スケジューリングサーバ（ Scheduling Server : SS ）
 自動翻訳サーバ（ Automatic Translation Server : ATS ）Lisp で稼働する機械翻訳システムは、本体だけで１０ Mbyte あるので、ATS は非常に重いプロセスになる。これだけの大きさになると、普通は１つの計算機内で翻訳プロセスをフォークすることはできないので、各計算を稼働させたとしても最大１つしか置くことがで機（各ホスト ）にはきない。しかし 、ネットワーク中にはが複数個存在することになる。
を管理するためのが必要になる。 は、から
よって、このを使用する要求が来たら、複数のの中から適切なところを使えるようにする。この場合、との間は、直接コネクションをつなぐ 方法と、 を経由してつなぐ 方法が考えられる。通信時間の短縮やの負荷軽減を考えると前者の方が望ましいが、セキュリティーの問題を考えると後者の方が望ましい。これの詳しいことは後で述べることにする。
を管理する
は、ネットワーク全体で１つだけでなければな
複数の

ATS

ATS

ATS

SS

ATS

ATS
SS
ATS
ATC ATS

SS

572

SS

ATC

SS

第 13 部

ATC

573

自動翻訳

ATS

らない。
は翻訳を行うためのソーステキストをに送信し 、そのはに翻訳の要求を発行し 、結果を受信するためのプロセスである。
とつながったらソーステキストを送信し 、すべて結果を受信したら終了する。

ATC SSATS

4.1.1

自動翻訳のためのクライアント（ ATC ）一般的にクライアントに求められる一番重要なことは 、できる限り速を設計
く正確にサーバの処理結果をユーザに知らせることである。
する際に、このことをまず第一に考え、セキュリティーの問題もあるかもと直接コネクションをつなぐようにした。また、きちん
しれないが、とに把握させるために、一回のと通信が行われているかど うかを
データ受信ごとに確認応答（）を返送する。逆にやにデータを待つことになる。
の送受信を行うというを送信したときは、
ことは、その分だけ通信時間がかかることを意味するので、本当に信頼のできるプロセス間での通信を行うのであれば 、これは必要のないものであを使用しているこのシステムでは、通信のエラーがるかもしれない。
発生する確率はほとんど０に等しい。しかし 、万一のエラーに備えることで稼働する翻訳プロセスがいつ異常終了するかわからなはもちろん、
いので、このの送受信はを操作するユーザにとって必要なものの送受信における所要時間は、全である。人間の見た目には、このく気にならない程度であるので、翻訳処理の遅延はほとんど起こらないに
等しい。

ATC

ATS

ACK

ACK

ATS SSACKATS SS

TCP

Lisp
ACK

ATC
ACK

ここでの翻訳処理は４つの行程に分かれている。順に、形態素解析、構が順番にこれらを処理していく
文解析、構文変換、構文生成となる。
間に、はそれぞれの結果を順番に受信していく。正常に終了したらその結果が、またエラーを伴って終了したらそのエラーを示すメッセージが受信される。正常な結果なのか、それともエラーを示す結果なのかは、ヘッダのコードで区別できる。この４つの行程のすべての結果をユーザに表示を起動す
するか、または生成された最後の結果だけを表示するかは、るときに、オプションで決めることができるようにしてある。また、は、最初にから接続要求認証を受け取った時点を０にして、処理結果を受信するごとにそこからの実行時間を計って表示するようにしやてある。これは、４つの行程でのおおまかな処理時間や通信時間がわかる
ので、非常に便利である。

ATS

ATC

ATC

ACK

SS

ATC

574
4.1.2

1989 年度 WIDE 報告書
スケジューリングサーバ（ SS ）

SS は、ATC からの要求を受信すると、起動している ATS を順番に検索していき、空いている ATS が見つかったら、それを ATC に割り当てる。
つまり、その ATS のホスト名を ATC に送信する。そして、ATC からのホ
スト名認証を受信すると、SS は割り当てた ATS を使用中とし 、その ATCとのコネクションを切って、再び別の ATC からの接続要求を待つ。あとは ATC と ATS の間での通信の進行状況を知らせるコード を ATS から受
信し 、SS はどこまで翻訳処理が進んでいるかを常に把握しておくようにする。そして、ATS から翻訳処理が終了したという知らせを受信したら、SSはその ATS を空きデーモンとする。
この一連の動作は、ATC と ATS が直接コネクションを確立する場合
で、SS を経由してコネクションを確立する場合はちょっと違ってくる。このときは、SS は ATS からの処理結果を常に受信して、それから ATC にその結果を送信する。ACK の送受信も同じで、必ず SS を経由して ATC
から ATS 、あるいは、ATS から ATC に送られる。当然、一連の翻訳処理がすべて終了するまで、ATC と SS の間のコネクションは切られることはない。この２つの詳しいモデルは、次のセクションで述べることにする。
からの接続要求を受信すると、空いてい今のところでは、 はを探して、一番最初に見つかった空き
をその
に知らせ
る
が使用中だったら、 はそのに空いている
る。もし 、すべてのがないことを伝え、がそれを認証したことがわかったらコネクの要求のための待ち列を用意していない。まションを切る。 は 、だの使用率や平均使用時間などがはっきりしないためこのようにしてある。将来的にしっかりと広域分散型機械翻訳システムを確立するためがに接には、このような機能は絶対に必要なものである。また、からはを選択することはできない。これを続要求を出すとき、があるきちんとした機能を持ち合わせていないと意味行うためには、がなくなるので、これに関することは次の自動翻訳サーバのところで説明することにする。

SS ATC

ATS

ATS

ATS

ATS

SS

ATS

4.1.3

ATS
ATC
SS
ATC

ATC
ATC

ATC

ATS

ATC SS

自動翻訳サーバ（ ATS ）ATS は、ATC から翻訳すべきデータを受信したら、それを翻訳して、その結果を ATC に送信する。前にも述べたように、翻訳処理には４つの行程があるので、それぞれの結果を順に ATC に送信する。このとき、ATSと ATC の間で直接コネクションが確立されていれば 、例えば ATS が形態
素解析を終了したら、その結果を直接 ATC に送信し 、形態素解析が終了したという途中経過の状況だけを SS に知らせる。また、SS を経由してコ

第 13 部

575

自動翻訳

ATS
ATC

SS

ネクションが確立されているならば 、は形態素解析の結果をまずに送信し 、 が、通信を行っているにそれを送信する。形態素解析、
構文解析、構文変換、構文生成のどれをとっても実行された結果のデータはかなりの量なので、 を経由する場合は、これにかかる負荷がかなり大きくなる。それを考えると、とは直接つながれている方が便利
である。

SS

SS

SS

ATC

ATS ATC

ATSには、を受け付ける窓口の役割と、の４つの行程を本来管理する役割がある。１つのにこの２つの役割を任せてもいいが 、この中に４つの行程を管理するを設けて、このと翻訳プ
こでは、と呼ぶようにする。すなわち、おおもとのは、ロセスを合わせてこのの中にあるを管理することになる。現段階では 、が翻上で稼働する翻訳プロセスを呼び出してこの訳処理を実行するとき、プロセスを立ち上げたら、は双方向パイプによってデータの送受信を行い、翻訳処理の結果を得る。よって、この４つの行程は１つのプロセス
の中にある
は単なる
の窓口
になっているので、今のところには１つのしか割り当てられなになっている。従って、１つのを割り当てることもできなくはないが 、４つの行程がすい。複数のの処理を行うので、これは行わない。これをべて終了してから次の意味あるものにするには、この４つの行程を独立に動くようにしなければならない。つまり、この４つの行程が４つのプロセスになることが重要での中にあるが威力を発揮するのである。例えば 、ある。このとき、あるからの要求を形態素解析に割り当てているときに、別のかにらの要求を構文解析に割り当てることもできる。すなわち、１つのを割り当てて意味をなすのである。このようになれば 、 は、複数のからどのようなにつなげてほしいかを聞いて、処理時間の問題を考えた上で複数のを１つのにつなげるようにすれば 、希望をがといかなえることができる確率も高くなる。具体的には、からの要求を待ち、おおもとのう関数を使って、複数のソケットではが求める条件に合ったをすべて検索し 、利用できるが見つかったら、そのホスト名をに知らせる。１つのに対して１つのしかつなげないのであれば 、希望を聞いても、偶然それに合が空いていなければ 、利用することはできない。
う

ATS

ATS

ATC

ATC

SS ATC

ATC
ATS

SS

ATS
SS
Lisp
ATS

ATS
ATS

ATC

ATC

SS

SS

SS
ATS

SS
ATC

ATS

ATC

ATS

ATS
ATC

SS

ATS

ATC
ATS
ATC

ATC
ATS
SS

ATS select()
ATS

ATS

このように４つの行程が独立に稼働していれば 、かなり便利であることは言うまでもない。一連の流れでしか行えなければ 、途中で結果が気に入らなくても最後までそのまま翻訳処理を実行していかなければならない
が、４つの行程が４つのプロセスになっていると、例えば 、構文解析の結果が気に入らないときに、それをユーザが手直しして、また構文解析を行576

1989 年度 WIDE 報告書

うこともできる。また、構文変換の結果と同じようなものをユーザが作成
して、いきなり構文生成を行うことも可能である。

4.2

ネット ワークにおける機械翻訳環境モデル

機械翻訳システムをネットワーク上に構築するためには 、自動翻訳の）とスケジューリングサーバ（ ）と自動翻訳ためのクライアント（
サーバ（）が必要であることは前のセクションで述べた。この３つの要素からなる翻訳システムのモデルには以下の６つが考えられる。ここで、が２つ存在するモデルにおいては、の中で翻訳処理における４つの行程を管理するスケジューリングサーバを、このスケジューリング
サーバを管理する本来の意味でのスケジューリングサーバを
と呼ぶこ
とにする。

ATS

ATC

SS

SS

ATS

SS2

SS1

1. ATC と SS2 が直接コネクションをはり、SS2 と ATS が双方向パイプ
でつながれているタイプ =)DCP 方式
2. ATC と SS2 の間で SS1 を経由して２本のコネクションをはり、SS2と ATS が双方向パイプでつながれているタイプ =)IDCP 方式
3. ATC と SS2 が直接コネクションをはり、SS2 と ATS の４つの行程がそれぞれ４本のコネクションでつながれているタイプ =)DCC 方式
4. ATC と SS2 の間で SS1 を経由して２本のコネクションをはり、SS2と ATS の４つの行程がそれぞれ４本のコネクションでつながれているタイプ =)IDCC 方式
5. ATC を管理する SS がフォークして、子プロセスの SS と ATS が双方向パイプでつながれているタイプ =)FP 方式
6. ATC を管理する SS が同時に ATS の４つの行程を管理しているタイ
プ =)CC 方式
4.2.1

DCP 方式

DCP 方式（ Direct Connection and Pipe、Figure4.1参照）は、次のような通信形態をとる。

1. ATC が SS1 に空いている SS2（ ATS）を使用したいという要求を出す
2. SS1 は空いている SS2（ ATS）を探し 、そのホスト名を ATC に知らせる

第 13 部

577

自動翻訳

3. ATC はそのホストの SS2 と直接通信を開始する
4. SS2 は ATS を起動して、ATS は SS2 と双方向パイプでつながる
5. SS2 は ATS の４つの行程のうちの１つが終了するごとに、ATS からの翻訳結果を直接 ATC に送信した後、SS1 に途中経過を知らせる
6. SS2 は翻訳処理がすべて終了したら 、そのことを ATC に知らせて 、
その後 SS1 に知らせる
SS2 ATSとは双方向パイプでつな
この方式では、前にも述べたように
は単にの窓口の役割しか果たしていない。
がれているので、から通信開始要求が到着すると、はプロセスを立ち上げて、そとなる。このとき、この翻訳
こで翻訳システムを起動する。これが）との間で、双方向パイプが結ばれる。それからプロセス（
はから翻訳を実行したいソースデータを受信し 、これを一文ずつ区に送信して翻訳を行う。このは、形態素解析、構文解析、
切って構文変換、及び構文生成の４つの行程を一連の処理として扱うので、途中に返すことと、エラーが生じたときにその一連の流れの処理結果をが構文解析を行っを止めること以外のことを行うことは許されない。
てから、その処理結果をが手直ししてまたに送り返して、再度が構文解析を行うというようなことはできない。
は、構文解析をに送信するわけではないか
行ってその結果を得ると、それをそのままはとしての結果（ 次に構文変換を実行できらである。つまり、る結果）は保持しておいて、ユーザにわかりやすいような結果になおしてそれをＣの文字列にしてに送信している。
はそれをに送信のしているので、ユーザが見た結果を手直ししても無駄なのである。
結果をそのままユーザに送り返すことは、システムの都合上ちょっと無理なことである。
が空いている（）を探してすべて使用中であったら、
は
にすべての
（
）が使用中であることを伝えて、お互いにソケットを閉じて、コネクションを終了する。今のところは、待ち列を用意していない。
は、に空いている（）のホスト名あるいはすべて使用中であるということを知らせたら、とのコネクションを切る。
は、それ以後のの状態を、が送信してくるによって判断の責任はかなり重くなるが、は、することになる。この形態では、からの要求と、からのを処理しなければならないの
複数ので、少しでもの負担を軽くすることを考えるとこの形態が一番いいよ

SS2

ATS

ATS

SS2

ATC
ATS

SS2 Lisp
ATS

ATC

ATS

ATS Lisp

SS2

SS2

SS1
ATC

ATS
ATS
ATS

SS2

ATC

Lisp

SS2 ATS
SS2 ATS

ATC

ATC

ATC

SS2

ATS

ATC

SS1

ATC

SS1

SS2 ATS
ATC
SS2
SS2
SS2
ACK

SS1

ACK

SS1

SS1

578

1989 年度 WIDE 報告書

ホスト 1

ホスト 2

ATS

ATS

SS2

SS2

ホスト 5

ホスト 6

6
双方向パイプ?

6
双方向パイプ
?

ホスト 3

ATS

6
双方向パイプ?

8* SS2
8
11 6
6
88
8
1
StoS
88
1
StoS
8
8 StoSAAA ホスト 4 11 8888
1 88
AU
1
8
S
S
S
SS1 8QkQQ
 AK
QQ
A
11
QQQ
A
11 S
A S
QQS
1
A
QQ
1
AU
? 1
?
?
Q
Q
ATC
ATC
Qs ATC
6 AKA
AA

図4.1: DCP 方式

ホスト 7

第 13 部

SS2

579

自動翻訳

SS1

ACK

うに思われる。
からに途中経過のを一切送らないで、最後に翻訳が終了したということだけを伝えるという方法も考えられるが、少かかのどれかがダ
しでも正確な通信を行うことと、途中でが知るためには、途中経過のウンしてしまったことをいち早くの送受信は行った方が望ましい。
がダウンしてしまったら、どうしようの処理速度によって、途中経過のもないことは言うまでもない。
による翻訳処理の遅延はかなり変わるので、これをしっかりさせることは重要である。現段階では、からの受け付けと複数のとの通信を待つことを１秒ごとに切り変えているので、この時間をきちんと決める必要がある。これからの経験によって、この値もしくはの送受信の必要性も変わってくると思われる。

SS1
SS1
SS1

SS1

ATC SS2 ATS

ACK

ACK

ATC

SS2

ACK

4.2.2

IDCP 方式

IDCP 方式（ InDirect Connection and Pipe、Figure4.2参照）は、次のような通信形態をとる。

1. ATC が SS1 に空いている SS2（ ATS）を使用したいという要求を出す
2. SS1 は空いている SS2（ ATS）を探し 、SS1 がその SS2（ ATS）にコ
ネクションをはる

3. ATC は SS1 を経由して、その SS2 と通信を行う
4. SS2 は ATS を起動して、ATS は SS2 と双方向パイプでつながる
5. SS2 は ATS の４つの行程のうちの１つが終了するごとに、ATS からの翻訳結果を SS1 に送信した後、SS1 が ATC に受信した結果を送信する

6. SS2 は翻訳処理がすべて終了したら、そのことを SS1 に知らせて、SS2と SS1 の間のコネクションを切り、その後 SS1 が ATC にそのことを知らせて、SS1 と ATC の間のコネクションを切る
DCP

SS2 ATS
ATS

方式と変わらない。
とが双方
この方式も、基本的には向パイプでつながれていることと、はすべてのが使用中であったに伝えて、との間のコネクションを終了してらそのことを方式と同じである。最も違うところは、翻訳処理の結しまうことはから何からすべて、からあるいは果はもちろん通信でのからへ送信するとき、必ずを経由することである。

ATC
DCP

ATC

SS2

SS1
SS1 ATC

ACK

SS1

SS2

ATC

580

1989 年度 WIDE 報告書

ホスト 1

ホスト 2

ATS

ATS

SS2

SS2

6
双方向パイプ?
AKAAAAStoS A

6
双方向パイプ?

StoS 1

11 1

ホスト 3

ATS

6
双方向パイプ?

8* SS2
8
88
8
8
8
8
8
88

1
StoS
1
8
8
AA
1
8
1 888U
ホスト 4
SS1 QkQQ
AK QQ
11
QQ
A
1
A
AA S QQQ S
11S
QQ
AA
111
QQ
AU
QQ
1
QQs ATC
ATC
ATC
ホスト 5

ホスト 6

図

4.2: IDCP 方式

ホスト 7

第 13 部

581

自動翻訳

SS1 が ATC からの接続要求を受信すると、DCP 方式では空いている
SS2 のホスト名を ATC に返すが、この方式では SS1 自身が空いている SS2にコネクションを張りにいく。つまり、ユーザ（ ATC ）に SS2（ ATS ）のことを知られなくてすむ。ATC は実際には SS1 とだけ通信を行っているが、あたかも ATS と通信を行っているかのように見える。DCP 方式では、
ATC と SS2 は直接通信を行うので、SS2 あるいは ATS のことが見えてしまう恐れがある。よって、セキュリティーが問題になってくる。また、ATCが直接 SS2 と通信を行うときは、ATC 、SS 、ATS といったすべてのプロ
セスが動いているネットワーク内では、同種のネットワークアドレスを使用しなければならない。しかし
方式では、
には
のことし
かわからないし 、が理解していなければならないネットワークアドレのアドレスだけである。
と（）の間で使われている
スはが知っている必要はない。
アドレスを方式で最も問題になることは、実行速度との負荷のことでと（）を直接つないでいる
方式は、
を経
ある。
にデータを
由するこの方式よりは実行速度が速い。また、必要以上にの負荷も比較的軽くてすむ。ところが方式で送信しないので、が翻訳して得た莫大なデータから通信のまですべてがは、を経由する。しかも、１つの
が複数個の
（
）と
の通信
の負荷
のフィルタを行わなければならない。これだけでも実行速度やにかなり影響している。
方式では、がから空いている（）のホスト名をとの間でのコネクションを切る。よって、が実受信すると、
質的に通信のために使用しなければならないソケットの数は、につなからの要求を待つためのもの、つまり、の数＋１となる。
ぐ 分と方式では、一連の翻訳処理がすべて終了するまではとしかしの間でのコネクションはつないだ状態でなければならないので、が通信のために使用しなければならないソケットの数は、につなぐ 分とにつなぐ 分、そして新たなからの要求を待つためのもの、つの数＋の数＋１となる。
の数が増えるにつれて、両まり、にかかる負荷の差はどんどん広がっていく。また、がダウン者のしたときの影響もこの方式の方が大きい。

IDCP

ATC

SS1

ATC

SS1 SS2 ATS

ATC

IDCP
ATC SS2 ATS
ATS

DCP

SS1

4.2.3

SS1
DCP

SS1

SS1

SS1
IDCP

SS1

ACK
SS2 ATS

ATC SS1ATC SS1SS2 ATS

ATC
IDCP

ATC
SS2
SS1

SS1

ATC
SS1

SS1
SS2

SS2

ATC

ATC

SS2

ATC

SS1

ATC
SS1

SS1

DCC 方式

DCC 方式（ Direct Connection and Connection、Figure4.3参照）は、
次のような通信形態をとる。

1. ATC が SS1 に条件付きの ATS 使用要求を出す

582

1989 年度 WIDE 報告書

2. SS1 はその条件に合った ATS を管理する SS2 を順に検索し 、接続可能になっている SS2 のホスト名を ATC に知らせる
3. ATC はそのホストの SS2 と直接通信を開始する
4. SS2 は ATC から送られてきたソースデータの内容にしたがって、ATSとして独立に動く４つの行程のうちの１つを実行する

5. SS2 は４つの行程のうちの１つが終了するごとに、その翻訳の結果を直接 ATC に送信した後、SS1 に途中経過を知らせる
6. SS2 は ATC からの結果の ACK によって、次の動作を決める
7. ATC からの結果の ACK が翻訳処理終了であったら、SS2 は ATC とのコネクションを切り、そのことを SS1 に知らせる
DCP

DCP
ATS
SS2 ATS

方式の機能を拡張したモデルである。
方式でこの方式は、
は、とが双方向パイプでつながれているので 、１つのにしか割り当てられないが、
方式は、
と
の４
は１つの
つの行程がそれぞれ４本のコネクションで結ばれているので、うまくスケに一度に複数のを割り当てることがでジュールさせれば１つのきる。ここでの割り当てるという意味は、待ち列に入れておくことではな
く、が処理を行っている状態を指している。
はまずに条件付きの翻訳プロセス使用要求を送る。この条件というものは、どのようなを使用したいかということを示したコードである。例えば 、どのような分野の翻訳を行いたいとか、できる限り速い
翻訳システムを使用したいとか、このようなマシン上のシステムを使用しはを検索たいといったことが挙げられる。その条件に合わせて、は独立に動く４つの行程で１つの翻訳システムを形成するのである。
を管理するスケジューラである。このはそれ自身が管理すするるの能力に合ったそれぞれの待ち列を持ち、最大いくつまでのを一度に処理するかを決める。４本のコネクションを使用して４つの行程を管理しているので、理論上は４つのまでは一度に接続することはが稼働するホストとが稼働するホストは、必ずしも可能である。
で動く翻訳システムは同じでなければならないということはないが、ダウンする率が決して低くはないので、同一ホストにある方が便利である
ためこの方式を用いている。
はそれぞれのの実行状態を把握しているわけではない。そである。従ってとという２つのスケれを把握しているのは
ジューリングサーバが存在するのである。負荷を分散させることが第一のSS2 ATS
ATC

DCC

ATS

ATC
ATC

ATS
ATS

SS1

ATS

SS1 SS2

SS2

SS2

ATC
SS2

ATS

SS1

ATC

ATS
SS2

Lisp

SS1 SS2

ATC

自動翻訳

583

ホスト 1

ホスト 2

ホスト 3

- Keitai- Keitai- Keitai- Kaiseki- Kaiseki- Kaiseki- Henkan- Henkan- Henkan- Seisei- Seisei- Seisei

第 13 部

ATS
StoA
????
SS2

ATS
StoA
????
SS2

ATC

ATC

ATC

ホスト 5

ホスト 6

ホスト 7

6 AK
AA

ATS
StoA
????
SS2
88*

6 BMB
1 6
8
8
1
8
BB
8
StoS 118
8
A StoS
8BB
AA ホスト 4 11 8888 StoS
BS
1 888 S
AAU
S
BB
1
8XyX
S
SS1 HYH X XXX X
BXX XXXSBB
1
AK H HX
1
A
BN
HH
XX XXXX
H
HH S
1
XXz ATC
A S
1S
A
HH
HH
1
ホスト 8
AA
1
H
AU ?
HHj ?
? 1

図

4.3: DCC 方式

584

1989 年度 WIDE 報告書

SS1

SS2 ATC

は、の割り当て状態（どの行程を使用している目的である。
が待っているか ）をか）と待ち列待機状態（どの行程から開始するはあらかじめからどの行見て、接続可能かど うかを判断する。
の要求に合っ程から始めたいかを送信させ、それをもとに判断する。
たを管理するの１つが接続可能であれば 、はそのホスト名に伝えて、はそのと直接通信を行う。接続可能のがをの待ち列に入れておいて一定時間待ってからまた検索しなかったら、てそれでもなかったらそのことをに知らせてコネクションを切る。

SS1

ATS
ATC

SS1

SS2
ATC

ATC

SS2

ATC
ATC
SS1

SS2

ATC

DCP 方式と DCC 方式の最大の違いは、ATS の４つの行程が独立に動くか否かである。DCP 方式は、４つの行程が一連のプロセスになっている

ので、エラーが起こらない限りは形態素解析から始まって構文生成で終わるまでをは順序よく必ず実行する。しかし方式は、どの行程か
ら始まるか、いくつの行程を実行するか、処理結果を手直しして同じ行程の希望によって決まるのである。
を繰り返すのかなどがすべては始めにソースデータを送信するときに、いっしょにどの行程から始めたに知らせる。デフォルトは形態素解析からである。１つの行程
いかをの処理が終わったら、はに直接その結果を送信する。この結果）は、そのまま終了するのか、手直ししてもう一度繰
を見てユーザ（とともにに知らせる。当然り返すのか、次の行程に進むのかをに送り返す。
は納得のいっ繰り返すときは、手直ししたデータをた時点でに翻訳処理終了のコードを送り、がそれを受信したら、がに知らせて一連
両者の間のコネクションを切って、このことをの流れが終了する。

ATS

DCC

ATC

SS2

ATC

SS2 ATC

SS2

4.2.4

ATC

ACK
SS2

SS2

ATC

SS2
SS2 SS1

IDCC 方式

IDCC 方式（ InDirect Connection and Connection、Figure4.4参照）は、
次のような通信形態をとる。

1. ATC が SS1 に条件付きの ATS 使用要求を出す
2. SS1 はその条件に合った ATS を管理する SS2 を順に検索し 、SS1 が接続可能になっている SS2 にコネクションをはる
3. ATC は SS1 を経由して、その SS2 と通信を行う
4. SS2 は SS1 を経由して ATC から送られてきたソースデータの内容にしたがって、ATS として独立に動く４つの行程のうちの１つを実行する

第 13 部

585

自動翻訳

5. SS2 は４つの行程のうちの１つが終了するごとに、その翻訳の結果をSS1 に送信した後、SS1 が ATC に受信した結果を送信する
6. SS2 は SS1 を通ってきた ATC からの結果の ACK によって、次の動作を決める

7. ATC からの結果の ACK が翻訳処理終了であったら、SS1 は ATC とのコネクションを切り、そのことを SS2 に知らせて、SS1 と SS2 の間のコネクションを切る

IDCP

IDCP
SS1

方式の機能を拡張したモデルである。よって、この方式は、
方式に比べて機能が拡張したところは、との通信の間に必ずが入っているという点を除けば 、方式を方式に機能拡張した
方式と方式の違いも、方式と部分と同じである。また、方式の違いと同じである。しかし 、ここで特に考えなければならなにかかる負荷のことである。
いことは、やはりIDCP

ATC SS2
DCP
DCC
DCC
IDCC

DCP

SS1
IDCP 方式は、SS2 と ATS が双方向パイプでつながっているため、SS1と SS2 の間にはられるコネクションの数は多くて起動している SS2（ ATS ）の数だけである。ところが 、IDCC 方式では、SS2 は複数の ATC からの要求を一度に引き受けることができるので、その分だけ SS1 と SS2 の間にコネクションがはられることになる。仮に、起動している SS2 （いっしょに ATS も起動していると仮定する）の数が３つであるとする。このとき、理論上は１つの SS2 に４つの ATC からの要求を一度に割り当てることができるから、SS1 と SS2 の間には最大４ 2 ３＝１２本のコネクションが結ばれることになる。そのとき SS1 と結ばれている ATC の数も１２個だか
ら、SS1 は最も多くのソケットを処理しているときには、その数が２４個になってしまう。それの他にもう１つ新たな ATC に対するソケットを用意しなければならない。これが単なる ACK の送受信だけを扱うならまだしも、莫大な大きさの翻訳結果を中継しなければならないのであるから 、にかかる負荷は、
方式には比べものにならないほどの大きさである。これに加えては、に対する待ち列の処理や、の状態管がかなり効率良くか理を行わなければならないので、この方式では、
つ高速に動けるようなマシン上に存在しないと、システム全体の遅延は免
れない。

SS1

4.2.5

IDCP
SS1 ATC

SS1

SS2

FP 方式

FP 方式（ Fork and Pipe、Figure4.5参照）は、次のような通信形態を
とる。

586

1989 年度 WIDE 報告書

ホスト 1

ホスト 2

- Keitai- Keitai- Keitai- Kaiseki- Kaiseki- Kaiseki- Henkan- Henkan- Henkan- Seisei- Seisei- Seisei

ホスト 3

ATS
StoA
????
SS2

ATS
StoA
????
SS2

ATS
StoA
????
SS2
88*

ATC

ATC

ATC

ホスト 5

ホスト 6

ホスト 7

AK AK
1
8
8
1
AAA
8
8
1
AA A StoS
11 StoS 8888StoS
StoS AAAAAAホスト 4 11 88888
18
AAUAU
SS1 8HYXy XXXXXXXXXXSX
AK HHH
11
A
XXXXX
HHH
11
A
XXXXXz ATC
H
A
H
S
1
HH
AA S
11 S
HHH
ホスト 8
A
H
11
HHj
AU

図

4.4: IDCC 方式

第 13 部

587

自動翻訳

1. ATC が SS に ATS を使用したいという要求を出す
2. SS はフォークして子プロセスを作る
3. 親プロセスは、新たな ATC からの接続要求を待つ
4. ATC は子プロセスの SS と通信を開始する
5. 子プロセスの SS は、ATS を起動して、ATS はその SS と双方向パイ
プでつながる6. 子プロセスの SS は、ATS の４つの行程のうちの１つが終了するごとに、ATS からの翻訳結果を ATC に送信する
7. 子プロセスの SS は、ATC に構文生成の結果（途中でエラーが生じた
らそのときの結果）を送信したら、プロセスを終了しコネクションを切る
この方式は、形式的には第３章で述べたサンプルプログラムのクライ
アント／サーバモデルにおけるバーチャルサーキット型と同じである。
はからの接続要求を受信すると、フォークして子プロセスを作る。このとき、子プロセスはとの翻訳通信を開始し 、親プロセスは新たなからの接続要求を待機する。

SS

ATC

ATC
ATC
FP 方式の利点は、アルゴリズムが簡単なことである。親プロセスの SSに対して子プロセスの SS は、他の方式で言えば SS1 に対する SS2 である。
他の方式での SS1 と SS2 は完全に別のプロセスでしかもそれぞれ別のホ
ストで稼働しているので、本来のスケジューラの役割を果たす SS1 は常にSS2 の動きを把握しておく必要性がある。しかし 、この方式での親プロセ
スの SS と子プロセスの SS は別のプロセスではあるが、同一ホストに存在

し 、子プロセスは翻訳処理が終了したらホストのメモリ上からは消えてしまうので、親プロセスは子プロセスがゾンビになってマシンに残らないよ
うにすること以外は、別に子プロセスの途中経過を常に把握しておく必要
性はそれほどない。従って、アルゴ リズムが簡単なのである。
方式には最大の難点がある。それは、この複数の子プロセ
しかし 、スのフォークに耐えうるだけのハード ウェアが用意できるかど うかということである。莫大な金を投資すれば用意できるかもしれないが、それでは）は、約１０ の記憶容量を必話にならない。１つの翻訳システム（と通信を行おうとすると、１つのマシン上に要とする。 が３つのがそれぞれにを立ち上げるので、このとき３つのフォークされた起動される３つのだけで３０ の記憶容量を使うことになる。もし 、

FP

SS

ATS

ATC
SS

ATS

M

ATS

M

588

1989 年度 WIDE 報告書

ホスト 1

ATS

ATS

6
双方向パイプ?

6
双方向パイプ
?

SS

ATS

6
双方向パイプ?

SS
88* SS
8
CO AK
 3
1
8
1
8
CC A
3
1
88
3
8
A
1
C A fork
1fork 833 888 fork
CC A
1
8833
1
C AA
8
8
1
8
CC
3
1
Q
k
3
Q
SS
1
C 1
1
AK QQ33 Q
CC 1
1
A 3 QQ
1
C 11
A
3
Q
1
C1 S
QQ 1
AA3 S
QQ1 S
AA
111
QQ
AU
QQ
1
QQs ATC
ATC
ATC
ホスト 3

ホスト 2

図

4.5: FP 方式

ホスト 4

第 13 部

自動翻訳

589

これが実現できるマシンが無理をせずに手に入るならば 、この方式を採用することが広域分散型機械翻訳システムを構築させる一番の近道である。
4.2.6

CC 方式

CC 方式（ Connection and Connection、Figure4.6参照）は、次のような通信形態をとる。

1. ATC が SS に ATS のどの行程を使用したいという要求を出す
2. SS はその行程のプロセスへのソケットが空いていればその ATC と通信を開始する3. SS はその行程のプロセスから処理結果を得たら、それを ATC に送信する

4. ATC は次に何を実行してほしいかを SS に知らせる
5. SS はその要求に従って実行する
6. SS は ATC から翻訳処理終了の要求を得たら、ATC とのコネクショ
ンを切る

IDCC

IDCC

方式の変型版である。
方式は、４つの行程のこの方式は、プロセスが同一ホストで動いているが、この方式はそれぞれの行程のプロ
セスが違うホストで動いている。これの一番の利点は、１つのホストにかかる負荷が軽減されることである。またホストによって動いている行程が決まっているので、 が管理しやすい。
図では１つのホストに１つのある行程のプロセスしか動いていないが、これは複数個動いていても構わない。この場合は、他の方式のようにこのが必要になる。こうなるとほと複数個動くある行程のプロセスのためのんど方式と変わらなくなる。ホストごとに動いている行程が決まっにかかる負荷は相当なものである。
ているとはいえ、やはり

SS

IDCC

SS

SS

590

1989 年度 WIDE 報告書

ホスト 1

ホスト 2

ホスト 3

Keitai

KaisekiHenkan

ホスト 4

Seisei

CO
@I@
00
22 2
C
0
@
CC
0
2
@@
0
StoA
2
StoA
0
2
@ StoA CC
0
StoA
@@
CC
0
222
0
@
C
0
2
@@ C 2 0@@R CCW 22 0900
ホスト 5

SS

0 6 @I@
0
@@
00
@
0
@@ S
0
0 S
S
@
0
@@
0
0
@@R
90
?

ATC

ATC

ATC

ホスト 6

ホスト 7

ホスト 8

図

4.6: CC 方式

第 5章
インプリメンテーション

前の章で、６つの翻訳環境モデルについて述べた。それぞれに利点があ
方式による広域分散型機
るが、ここでは、その中で一番最初に述べた
械翻訳システムをネットワーク上に実装することにする（付録２参照）。既
存の機械翻訳システムの４つの行程が独立に稼働するようになればこれを方式に拡張することもできる。また、通信時間の短縮と、スケジュー方式ではなく、
リングサーバの負荷の軽減を第一の目的としたため、方式を採用した。

DCP

DCC

IDCP

DCP
5.1

通信の流れ

ネットワーク上に機械翻訳システムを構築させれば、当然そのシステムの、、、動作には一連の通信の流れができあがる（、参照）。このセクションでは 、方式の通信の流れを追うことによって、どのように機械翻訳が行われているかを述べることにする。

Figure5.1 Figure5.2 Figure5.3
DCP

Figure5.4 Figure5.5

DCP 方式は、まず SS1 が起動するところからシステムの動作が始まる。起動するべきホストはデフォルトで決まっているが 、別のホストで起やが接続要求を出すと動することもできる。しかしその場合は、きに、が起動しているホストをオプションで示さなければならないのはデフォルトで決められたホストで起動する
で、特に何もなければ 、べきである。このは、広域分散型機械翻訳システムの中核を成すスケ
ジューラである。これがダウンすると、システム全体がダウンすることには起動すると、その時点から接続要求を受け付け始める。接続なる。
要求を受け付けるためのソケットと、デーモン（）と通信を行うためのソケット（システム全体で起動することが許されているデーモンの個数だけ存在）を決められたタイムアウトごとに順に調べていき、要求が到着しはていたら、処理を行ってまた次のソケットを調べに行く。つまり、
タイムシェアリングにサービスを提供している。従って、やはあSS2 ATC

SS1

SS1

SS1

SS1

SS2

SS1
ATC SS2

591

592

1989 年度 WIDE 報告書

クライアント

サーバ

(ATC)

(SS1)

デーモン

(SS2/ATS)

起動
要求待ち



接続要求認証SS CONNECT OK



デーモン開始要求認証



DAEMON START OK



-

-

ホスト名

-

ユーザ名

-

パスワード

-

MT HOST

MT USERMT PASSWD



開始データ認証-

デーモン要求INQUIRE DAEMON
図

接続要求認証SS CONNECT OK

接続

START DATA OK
空きデーモン獲得

5.1: ステートダ イアグラム１

-

接続


起動
接続要求

-

起動
接続要求

デーモン開始要求

DAEMON START

-

接続待ち

自動翻訳

593

クライアント

サーバ

(ATC)

(SS1)

デーモン

第 13 部

デーモンホスト名-

デーモンホスト名認証

DAEMON HOST OKDAEMON HOST

-

切り離し

-



接続要求

(SS2/ATS)

接続要求認証ATS CONNECT OK



-

接続
ホスト名

MT HOST

-

ユーザ名

-

翻訳ファイル名-

MT USERMT FILE

翻訳開始要求MT START



翻訳データ認証-

ACK MT DATA
翻訳開始要求認証

MT START OK

ソーステキスト



SRC DATA

図5.2: ステートダ イアグラム２-

ソーステキスト認証

SRC DATA OK

594

1989 年度 WIDE 報告書

クライアント

サーバ

(ATC)

(SS1)

AGAIN:

デーモン(SS2/ATS)ATS を起動
DoKeitai (文章)

形態素解析終了-

形態素解析終了認証

ACK KEITAI OKACK KEITAI ERROR



形態素解析終了

ACK KEITAI OKACK KEITAI ERROR

エラーなら END へ

DoKaiseki ()

構文解析終了KAISEKI OK
KAISEKI ERROR-

構文解析終了認証

ACK KAISEKI OKACK KAISEKI ERROR



構文解析終了認証

ACK KAISEKI OKACK KAISEKI ERROR図KEITAI OK
KEITAI ERROR-

形態素解析終了認証

KEITAI OK
KEITAI ERROR

5.3: ステートダ イアグラム３

構文解析終了-KAISEKI OK
KAISEKI ERROR
エラーなら END へ

自動翻訳

595

クライアント

サーバ

(ATC)

(SS1)

デーモン

第 13 部(SS2/ATS)
DoHenkan ()

構文変換終了-構文変換終了認証

ACK HENKAN OK
ACK HENKAN ERROR



構文変換終了認証

ACK HENKAN OK
ACK HENKAN ERROR

構文変換終了HENKANI OK
HENKAN ERROR-

エラーなら END へ

DoSeisei ()

構文生成終了SEISEI OK
SEISEI ERROR-

構文生成終了認証

ACK SEISEI OKACK SEISEI ERROR


構文生成終了認証

ACK SEISEI OKACK SEISEI ERROR

図HENKAN OK
HENKAN ERROR

5.4: ステートダ イアグラム４

構文生成終了-SEISEI OK
SEISEI ERROR
エラーなら END へ596

1989 年度 WIDE 報告書

クライアント

サーバ

(ATC)

(SS1)

デーモン

(SS2/ATS)

END:

未処理の文章があれば



翻訳継続

-

翻訳継続認証MT CONTINUE OK

MT CONTINUE

翻訳継続

翻訳継続認証MT CONTINUE OK-

MT CONTINUEAGAIN へ
未処理の文章がなければ



翻訳終了

-

翻訳終了認証MT FINISH OK



-

切り離し


翻訳終了認証MT FINISH OK
デーモン解放終了
図MT FINISH

5.5: ステートダ イアグラム５

翻訳終了

-

MT FINISH
ATS を終了
接続待ちに戻る

第 13 部

597

自動翻訳

SS1

たかも一対一でと通信を行っているかのように見える。後ろのステーは複トダイアグラムの図もこのように見えるかもしれないが、実際のやに対してタイムシェアリングに一連の処理を行っている。
数のからの要求に対しては、空きデーモンを探してそのホスト名を伝えるまでを１つの処理単位とし 、（）に対しては、翻訳処理の４つの行程の途中経過に関する通信や翻訳終了、または翻訳継続を認識するための通信を１つの処理単位としている。４つの行程のうちの１つに関する通の処理が１つの処
信が１つの処理単位である。
（ 図の」で区切られた理単位である。）

ATC SS2ATCSS1

SS2 ATS

SS1

SS1 が立ち上がると、次に SS2 がこれに接続を要求する。SS1 と SS2の間でコネクションが確立されて始めて ATC は翻訳処理を実行することができる。SS1 はシステム全体で受け付ける SS2 の数を限定している。現
在は、負荷を考慮して、最大２個までとしている。また、SS1 は接続を許可する SS2 のホストを決めているので、SS2 はどのようなホストでも起動することはできるが、必ずしも SS1 と接続できるとは限らない。ここでの接続とは、単なるコネクションの接続ではなく、通信を確立するための接を判断するために、はが起動続を意味する。受け付け可能な
すると、そこからデーモン開始要求のコードと起動しているホスト名を受信する。あらかじめ用意されているテーブル（構造体の配列）にそのホスに送信し 、そこから本当の意
トが存在したらデーモン開始要求認証を
は、負荷を考えて、１つのホストか味での接続が確立される。さらにらは最大１つのしか接続要求を受け入れないので、すでに接続を確立が存在するホストから新たにの接続要求を受信したときしている
は、接続を許可しない。

SS2

SS2

SS2

SS1

SS1 SS2

SS2

SS2

ATC は翻訳を開始するとき、まず SS1 に接続要求を送信する。コネク
ションが確立されたら、次にホスト名、ユーザ名、パスワードを SS1 に送信する。SS1 は送られてきた３つのデータからその ATC が受け付け可能なユーザであるかど うかを判断し 、正当なユーザであると判断できるときに開始データ認証を送信する。
（現時点では、ユーザが入のみ、その力したパスワードからだけその判断を行っているが、この翻訳システムを構築するネットワークが広域になればなるほどホスト名とユーザ名からもその判断を行わなければならない。）入力されたパスワードが誤っているとき、はそのに開始データ認証エラーを送信し 、接続要求を拒否す
から翻訳システムの使用許可をもらった
は、次に
に空
る。
は、接続しているを順きデーモンホストを探すことを要求する。
に検索していき、空いているデーモンホストが見つかったらそのホスト名に知らせる。もしすべてのデーモンホストが使用中であれば 、
を

ATC

SS2
SS1

ATC

ATC

SS1

ATC

SS1
SS2

SS1

598

1989 年度 WIDE 報告書

ATC

ATC

に伝える。
は、空きデーモンホストを受信するにはそのことをしろ、すべてのデーモンホストが使用中であることを受信するにしろ、そをに送信し 、ここで両者の間のコネクションは切れ
れに対するはに対する待ち列を用意していないので、る。今のところ、は空きデーモンを獲得できなかったら、そこで終了する。

ACK SS1
SS1 ATC

ATC

ATC

SS2

は、直接
に接続要求を送信す
空きデーモンホストを獲得したる。コネクションが確立されたら、次にホスト名、ユーザ名、翻訳ファイに送信する。
はこの３つを受信したら、翻訳データ認証をル名をに送信する。現時点では、はこの３つを受信しさえすればに翻訳データ認証を送信しているが、このままだと翻訳ファイル名を送信する意味が全くない。そこで将来的には、このでもの接続許可を判断し 、認めることができないユーザであると思われるときは、ここではにこの３つを送接続要求を拒否するようにする。そのためには 、次に翻訳を実行信させているのである。接続要求を許可された
してもらいたいソーステキストをに送信する。１つのが長時間を使用し続けることを避けるため、が１回のの使用で送信できる翻訳ファイルは１つで、その文字数は全部で１０２４文字に限ってで入力をいる。コンソール入力の場合も同様で 、ユーザが終了するまでのデータをテンポラリファイルにためておいて、そのファイル１つに限っている。コンソール入力も文字数の上限は１０２４文字であはソーステキストを受信したら、にソーステキスト認証を送
る。
信する。

ATC

SS2

SS2

SS2

ATC

SS2

SS2

ATS

ATC

SS2 ATC
ATC

ATC
ATS

ATC

[RET].[RET]

SS2

ATC

SS2 はソーステキストを受信したら、Lisp を立ち上げて ATS を起動する。このとき、SS2 と ATS は双方向パイプで結ばれる。それから、SS2 はソーステキストを１文ずつ区切って翻訳を実行していく。始めに形態素解析が行われる。このときが呼び出す関数は、引数としてソーステキス
は双方向
トの１文をとり、それとともにこの関数が呼び出されると、パイプを通って送られてくるその文章に対して形態素解析を実行する。次がそれの結果を得るための関数を呼び出すと、は双方向パイプにを通してにその結果を送信する。
はその結果を受信したら、直接に形態素解析終了を表すコード とともにその結果を送信する。このコードはその結果が正常なものであるかエラーを表すものであるかを示しはそれを受信したら、そのコードに合った
を
に送
ている。
はそれを受信したら、今度は途中経過を知らせるために、信する。
に形態素解析終了を表すコードだけを送信する。
はそれを受信したら、をに送信する。ここで結果がエラーであっそのコードに合った
たら、も（）もこの文章に対する翻訳処理を終了する。

SS2

SS2

ATC

SS2

ATC
SS2

ACK SS2
ATC SS2 ATS

ATS

ATS

SS2

ACK SS2

SS1

SS1

ATS

第 13 部

599

自動翻訳

Lisp

は
上で稼働するシステムだから、４つの行程の結果もそれ自身が理解できるものとユーザが理解できるものとはかなり違いがある。そこではが翻訳処理結果を要求してくると、その結果をユーザが理解できるは自分が理解できる結ような文字列になおして送信する。このとき、果は保持しておいて、次の行程を実行してほしいということを示す関数がで呼ばれるまで待機している。従って、構文解析、構文変換、およびに実行させるための関数は、引数を取らないのである。同
構文生成を様にして、エラーが起こらない限り順に構文解析、構文変換、および構文生成の一連の流れを実行していく。
ででのエラーが生じたら、特別にそのことを示すメッセージとコードを送信する。

ATS

SS2

ATS

SS2

ATS

ATS Lisp

翻訳の結果が正常に得られても、エラーが得られても、１文の処理がは未処理の文章が残っていれば翻訳継続を表すコード を終了したら、に送信し 、未処理の文章が残っていなければ翻訳終了を表すコードをに送信する。
はそれを受信したら、そのコードに合ったをに送信する。
が翻訳終了のを受信したら、この時点でとの間のコネクションは切れる。同様にはに対してもこれをも同様にを送信する。
が翻訳継続をおよび行い、に送信したら、全体の動きはまた形態素解析から実行される。また、が翻訳終了をおよびに送信したら、は動作を終了し 、はデーモンを空き状態にして別の要求の実行に移り、はを終了させて再び接続待ちの状態に戻る。

ATC
ATC
SS2
SS2

SS2

ATC
SS2

ACK

ACK

SS2

SS1

ATC

5.2

SS1

SS2 SS1
ATC

ACK
ATC

ATC

SS1
SS2
SS1

SS2 ATS

DCP 方式の実装における特徴と問題点

DCP 方式による広域分散型機械翻訳システムには、いろいろな特徴がある。利点であることも多いが、逆に欠点であることも少なくない。このセクションでは、これらを具体的に考えて、現時点ではどこまで実現できるのかを明確にし 、問題点は何なのかをはっきりさせることにする。
5.2.1

スケジューリングサーバ（ SS ）の並列処理

ATC SS ATS

広域分散型機械翻訳システムはととの３つのプロセスから成り立っているが、その中で通信という点から一番重要な役割を果たである。前のセクションでも述べたように、方式でしているのはとという２つのが存在するが 、ここで述べるとはシスはの方である。
方式のは 、複数のとテムの中核をなすを管理しなければならない。
と
、
と
、および
と
の間は、すべてコネクションを張って通信を行う。つまりをSS1 SS2

ATC
ATC

SS

SS1

SS

DCP
SS1
SS1 SS2 SS1 ATC

DCP
SS

SS2
SS2
TCP

600

1989 年度 WIDE 報告書

UDPを使用すればあまり問題なく複数の相手からの通信を扱使用する。
うことができる。これはコネクションを張っていないので、とにかく到着した要求を順番に処理して、アドレスを使ってその相手に返せばよい。しかし 、正確に処理を行うことを何よりの目標としている今回の実装においを使うよりも、信頼性のあるを使用ては、やはり信頼性のないによる通信において、複数の相手を扱う方法はすることを選択する。
という関数を使いくつか考えられるが、ここでの実装においては、うことによって、複数のソケットをタイムアウトを決めて順番に処理する方法を採用した。そこで、少しこの方法を説明することにする。

UDP
TCP

TCP

select()SS1 はまず、起動して待機状態に入っているときに必要なソケットと、
新しい ATC あるいは SS2 からの接続要求を受け付けるためのソケットと、SS2 から接続要求を受信したとき複数の SS2 を識別するためのソケットの配列を用意する。その配列の大きさは、SS1 が接続を許可する SS2 の数＋１個である。最後の１個は、SS1 が空いている SS2 を探すときに使用するもので、それほど 重要なものではない。そして起動して待機状態に入ったを識別する複数ら、その直後から、待機状態に入っているソケットとのソケットをタイムアウトごとに順番にセレクトして、要求が到着していやたらその処理を行う。このときに行う処理の大きさは、他のに迷惑がかからない程度の量を１つの処理単位とする。

SS2

ATC SS2

SS1をフォー
複数の通信相手を処理する方法として他に考えられるのは、
クするやり方である。しかしこのやり方だと多少不都合なことが生じる。
まず、子プロセスの動きをどのように親プロセスに知らせるかである。
は、との両方からの接続要求を処理する。一般にサーバがフォークする時期は、クライアントからの接続要求を受信するときである。ここがあるから接続要求を受信したときにフォークすると仮定す
で、とコネクションを確立し 、親プロセスる。すると、子プロセスはそのはソケットを閉じて別の接続要求を待機することになる。ここでもしから接続要求が到着したら、親プロセスは今接続を要求してきたが動をそこに割り当てる。このときは、いているものと判断してこのにが割り当てられたらコネクションが切れるので、わざわざフォーク
がの認めていないホストであっする必要はない。ところが、このがの子プロセスにデーモン開始要求を送信したら、たとすると、
その時点で接続を拒否されて、両者の間のコネクションは切り離されてしまう。これを親プロセスが認識できないところが問題である。なぜならば 、
フォークした時点から親プロセスと子プロセスは全く別のプロセスになっはこのに接続できない。これてしまうからである。従って、当然を解決するために、フォークしたら子プロセスと親プロセスの間に双方向

SS1

ATC SS2
SS1

SS2

SS2

SS2

ATC

SS2

SS2 SS1SS2 SS1

ATC

SS2

ATC

ATC

第 13 部

601

自動翻訳

パイプをつなぐことも考えられる。しかし 、このようにすれば 、結局親プ
ロセスはこの双方向パイプの窓口と新たな接続要求の窓口をセレクトしなければならないので、実装しているやり方と変わらない。もう一つフォー
クした場合の問題点は、メモリをたくさん消費することである。込み入っを動かさざるおえない状況になったときに、この方法だ
たマシン上でと困ってしまう。

SS1

フォークせずにセレクトを使う方法も問題がないわけではない。タイ
ムシェアリングに複数の要求を処理する以上は、やはりどのような処理を方式による広
どのように扱うかをきちんと決める必要がある。この
域分散型機械翻訳システムは、パスワードを入力させて使用許可の判断を行っている。ここでもしパスワード 入力にタイムアウトを用いないと、いはから送らじわるなユーザが永遠にパスワードを入力しないとれてくるパスワード を読むところでブロックしてしまう。これは、システ
ム全体のブロックを意味する。そこで今度はパスワード 入力に１０秒のタのブロックはあり
イムアウトを設定する。これならば 、１０秒以上のがパスワードを入力するまでが他のえない。ところが、ここで要求処理に移らないとすると、いつもパスワード の送受信のところでシス
テム全体がブロックするので、かなりの遅延が生じてしまう。これを避けるために、はからホスト名とユーザ名を受信したら、一度別の要求処理に移り、ある程度経ってからパスワード の受信に入るようにするべの１つの処理の切れ目と扱い方をしっかりさきである。このように、せることは、翻訳システム全体をしっかりさせることにつながるのである。

DCP

SS1 ATC

ATC

SS1

SS1

SS1 ATC

SS1

5.2.2

自動翻訳のためのクライアント（ ATC ）のラップタイム表示

ATC も SS も ATS も起動するときに'T' というオプションを指定すると、通信の一連の流れをウィンドウに出力する。指定しなければ SS と ATS
は何も表示せず、また ATC は翻訳処理結果と以下で述べるような翻訳処
理時間だけを表示する。

ATC は T オプションを指定したときに、SS1 からの接続要求認証を受信した時点を０として、そこからの実行時間をはかり、何かを受信するごとにラップタイムを表示するようにしてある。４つの行程のところでは 、
ラップタイムだけではなくて、その行程にかかった処理時間も表示する。この処理時間は、オプションに関係なく表示する。これによってどんな文章がどれくらいの時間で翻訳されるかがわかる。この時間を短縮するためには、）を高速のスーパコンピュータ
やはり翻訳システムの本体（ここではの上で動くこのシスで稼働させることがまず思いつく。
テムをスーパコンピュータ上で動かすためには、翻訳システムそのものをATS
SUN workstation

602

1989 年度 WIDE 報告書

いじる必要があるので、ここではこのような案があるということにとどめておくことにする。
5.2.3

バッファサイズにおける問題点

ど のようなクライアント／サーバモデルでも必ず考えなければならなもももバッいことは、バッファサイズである。現段階では、ファを用意するところはすべて２０４８バイトに設定してある。まだ十分なテストを行っていないため、どのような文章がこの大きさでオーバフロー
するかははっきりしていないが、いずれにしろどんな大きさのデータでも送受信を行えるようにしなければならない。この３つのプロセスのあらゆるところでデータの送受信は行われているが、やはりその都度必要なメモ
リ領域を送信側と受信側に確保させて通信を行うことが、最も自然なやり方である。送信側は受信側にまず送るデータサイズを送信する。受信側はによって確保す
それを受け取ったら、それに合うだけのメモリをる。このようにすれば 、空きメモリがある限り、大きなデータの送受信も可能である。また、バッファサイズごとに分割して送受信を行うことも考えられる。第３章で述べたクライアント／サーバモデルのサンプルプログ
ラムにおけるバーチャルサーキット型はこの方法を使って送受信を行っていることはすでに述べた。いずれにしても、このような機能は絶対に必要なことである。

ATC SS ATS

malloc()

5.2.4

ACK の通信方法

DCP

通信の流れを示した前のセクションからもわかるように、方式でを返すようにしている。これはは、あるデータの受信に対して必ず、 、のすべてにおいてそのようにしている。このの送受信にもいろいろな方法がある。ここでは、これについて述べることにする。
の送受信方法は、コネクションのはり方にも依存してくる。実装
した
方式は、
と
の間は
が
に空きデーモンホストを要求し 、そのホスト名を受信するときだけコネクションが張られる。実とはコネクションで結ばれ際に翻訳処理が行われているときは、が起動してから、それがからのコネてはいない。そのかわりに、との間でコネクションを確立しているのクト要求を受け付けて、である。このコネクションを確立する方法は、これとは逆にからの方へコネクト要求を出す方法が考えられるが、この方法だと、がダを起動するところから始めなければウンしたら再起動するときにまたを一度止めなければならない。これだとかなり不ならない。つまり、便である。よって、がを受け付ける形式を採用した。これならば 、

ACK

ATC SS ATS
ACKDCP

ATC SS1ATC SS1

SS1
SS1 SS2

SS1
SS1 SS2ACK

ATC SS1

SS1

SS2

SS1

SS2

SS2

第 13 部

603

自動翻訳

SS2 がダウンしても、また SS1 にコネクト要求を出せば 、容易に再起動できる。また、起動する SS2 の数も調節することができる。もっとも SS1 がダウンしたら、どのような方法を採っていても同じである。

ATC、SS1、SS2（ ATS）のうちの二者間での ACK の送受信方法は一通りしかない。ここで考えるのは、三者間での ACK の送受信方法である。
問題になるところは、翻訳処理の結果を SS2 から ATC に返送するときである。実装した DCP 方式は、SS2 が ATC に結果とそれを表すコードを送信すると、それを受信した ATC は SS2 にその ACK を返送し 、SS2 はそれを受信すると、次は SS1 に結果を表すコードだけを送信し 、それを受信した SS1 は SS2 にその ACK を返送する。つまり、SS2 が SS1 と ATC の通信相手をしている。従って、ATC と SS1 の間は不必要にコネクションを張っておくことはしない。これとは違って、一連の翻訳処理が終わるまでとの間のコネクションを張り続けておいて、がとの通信相手をする方法もある。このときは、との間にコネクショ
ンを張る必要がない。しかし 、この方法では、にかなり負担をかけるがの状態を知ることができるかど うかもことになる。また、にかかってくる。このように、クライアントに必要以上の負担をかけるよ
うなクライアント／サーバモデルは、あまり望ましいものではない。従っかになるようにしている。
て、通信の責任を担うところは、

ATC SS1ATC SS1 SS2SS1 SS2ATCATC

SS1 SS2

SS1 SS2

5.2.5

自動翻訳サーバ（ ATS ）のためのメモリ確保

ATS

前にも述べたように、は立ち上がるために莫大なメモリを必要とのする。これを常に確保しておくかど うかが少し問題である。もし 、が立ち上がってために必要なメモリをいつも確保しておくとすると、いないときには、このメモリはすべて無駄になっている。
を一度立ち上げたら永久にそのままにしておくようにしても、ユーザが使用していな
いときには同じようなことが言える。そこで、メモリを気にせずに立ち上を立ち上げて使用することにする。つまり、
は空いて
がれたら
を割り当てられても、はを立ち上げられるかど うかがいるわからないのである。今のところは、これに関して制御することはしていない。
があるを割り当てられて、このがを立ち上げらがれなかったら、当然その時点で翻訳処理が終了する。しかし 、次の接続要求をに送信したら、またこのが割り当てられてしまう。だが定期的にを立ち上げられるだけのメモリ領域
から本来ならば 、を調べて、このホストを使用停止状態にし 、使えを確保できていない
るようになったら、また使用可能状態にすればよい。これも将来的には必要なことである。

ATS
ATS

SS2

ATS

ATC

SS2 ATS

SS2

SS1

SS1
SS2

ATC

SS2 ATS

ATS

SS2

ATS

ATC

604
5.2.6

1989 年度 WIDE 報告書
入力文字について

日英翻訳で入力する日本語は全角文字である。半角文字を入力すると、コードであ
システムは変換を行うことができない。また、コード はる。その他のコードは変換することができない。
は、にからのソーステキストを送る前に、それが正当なものであるかを判断しなけれ
コードであるかど うかを調べるのは大変なので、ここでばならない。
コー
は半角文字が交じっていないかど うかだけを調べるようにする。
ドにすることは、ユーザに任せるようにしているが、これも将来的には制は、から送られてくるソースデータのう
御しなければならない。
ち改行以外の半角が入っているかど うかを調べて、入っていたら、にはこれを受信したら、そのエラーコードを返送するようにしている。
時点で異常終了する。

SS2

EUC

EUC
ATS ATC
EUC

SS2

ATC

ATC

ATC

第 6章
評価と結論

第４章と第５章で、広域分散型機械翻訳システムをどのように設計しネットワーク上に実装するかについて述べてきた。この章では、実際にそのシステムを使用するユーザから見て、これがどのように感じるか、またど
こをどのように変えていかなければならないかについて述べることにする。

6.1

広域分散型機械翻訳システムの利用効果

実際にいくつかの日本語の文章を翻訳してみた。入力した文章とその翻訳結果は以下のとうりである。使用した辞書が証券関係のものであるか
ら、その方面の文章が中心になっている。

CSK が値を上げた。
（結果）CSK Co. rose.
（例１）（例２）これは本である。

This is a book.

（結果）（例３）今日は円安ドル高の一日だ。

Today is the 1st of a yen's weakness strong dollar.

（結果）（例４）為替、株、債券のトリプル安の波乱場面では腰の入った買い物は期待しにくい。

Buy orders that trading was activated hardly expect [due to] wilductuations stage of the exchange markets, the stock and bonds offalls.

（結果）

現状の機械翻訳では 、同じような文章を入力しても、機械が判断できる文章は限られているので、必ずしもすべての文章が翻訳できるとは限ら

605

606

1989 年度 WIDE 報告書ない。例えば 、上の例２のように「これは本である。」と入力すれば正しい結果を得られるが、「これは本です。」と入力しても正しい結果を得られない。
「です」という言葉を別の意味に解釈するからである。従って、実際に機械翻訳を仕事として使用する人たちは、入力する文章が機械の理解できるものであるかど うかをチェックして、手直しを加えてからその文章を機械翻訳にかける。
章末に実際の機械翻訳の流れがどのようになるかを示したウィンド ウ、、
は、例４の文章が翻の出力図を載せた。
、
訳されるときの一連の流れである。４つのウィンド ウのうち、右上が
（
）、左下が
である。
、
は、例２
右下が
の文章が翻訳されるときの一連の流れである。
は、
がダウン
は、
のパスワード 入力がタイムアしたときの状態である。
は、翻訳処理結果がエラーで終了しウトしたときの状態である。
は、が半角文字を入力しようとした
たときの状態である。
ときの状態である。
次に、上の４つの例文を翻訳するときにどれくらいの時間がかかった参照）。表の値は５回の平均値で、単位は秒である。まかを示す（のセレクトタイムアウトは１秒である。
方式による翻訳シス
た、
が立ち上げられ 、翻訳が終わるとテムは、文章が入力されたときにが終了する。同じことを繰り返しても、そのたびにを立ち上げなければならないので、５回とも処理時間はだいたい一定している。また
例１と例２を見てもわかるように、長さがほぼ同じである文章において、
例１は形態素解析の処理時間が例２の半分だが、構文解析の処理時間は例
２の２倍かかっている。従って、処理時間というものはもちろん文章の長さも関係してくるが、それ以上に文章の種類が関係してくる。

Figure6.1 Figure6.2 Figure6.3

SS2 ATS

ATC

Figure6.4 Figure6.5
Figure6.6 ATS
ATC

SS1

Figure6.7
Figure6.8
Figure6.9 ATC

SS1

Table6.1

DCP

ATS

ATS

表

ATS

6.1: 機械翻訳の処理時間

Keitai Kaiseki Henkan Seisei SUM
Ex.1
Ex.2
Ex.3
Ex.4

4.4
8.8
4.4
24.8

5.8
2.6
8.8
29.2

3.8
8.4
7.2
34.6

2.4
1.6
2.6
7.6

16.4
21.4
23.0
96.2

辞書の確立さえしっかりさせれば 、口語の文章の機械翻訳もかなり実用化される。また、ここでのクライアント／サーバモデルの形式は、他のものにも応用できるので、幅広く利用していきたい。

第 13 部

6.2

607

自動翻訳

今後の課題

DCP

第４章で述べた翻訳環境モデルのうち本研究で実装したものは、方式によるものである。この実装において何よりもまず達成しなければならなかったことは、１つの大きな翻訳システム環境を複数のユーザで効率よく利用できるようにすることであった。そのためにスケジューリングサー
バを用意した。また、より正確な通信の流れを確立することも重要であった。この２つは 、ある程度のレベルでは達成されたように思われるので、方式のシステムを
これからまず考えなければならないことは、この方式のシステムへと拡張することである。最初にバッファのオーバ
フロー制御を行わなければならない。これの解決策については第５章で述べた。それから、翻訳システムの４つの行程が独立に動くようにするためで記述された翻訳システムそのものを改良しなければならない。
に、この４つの行程がきちんと４つのプロセスとして働くようになると、との両方のスケジューリングサーバをもう少ししっかりとさせる必要に複数のユーザを効率良く割り当てらがある。１つのホストで動くれるようにするために、待ち列を設定することが大事である。システム全
体の遅延をできる限り少なくするためには、これはかなりしっかりとさせなければならない。
が翻訳の処理を行ってその結果をに送信し 、それをが受け取ったら、現時点ではそれをそのままディスプレ イに出力している。
構文解析と構文変換の結果は、文法を記述するデータが画面上に現れる。
この２つの結果は、本来ならばきちんとした木構造で画面に出力させなければならないものであるが 、これはかなり時間のかかる作業で、しかも本研究の趣旨からは少しはずれているように思われたので、これに関しては
手をつけなかった。しかし 、このユーザインタフェースの部分は非常に大事であるので、機械翻訳というものをよりわかりやすくするためにはこれが重要である。
最後に、一番真剣に今後の課題として取り組まなければならないものとのことをあげたい。本研究では、時間の都合上、して、日英翻訳しか扱わなかったが、やはりこれを行うためには英日翻訳も必要である。おおまかな原理は両方とも同じである。また、は口語の辞書の確立や翻訳速度の高速化などいろいろな問題を含んでいるが、これからのネットワークにおいて必要不可欠なものであると思う。国際通信の簡易化というものが、やはりネットワークでの何よりの目標であると思うからである。

DCP

DCC

Lisp

SS2

SS1

ATS

ATS

SS2

ATC

Translation Phone

Translation Phone608

1989 年度 WIDE 報告書

図6.1: 機械翻訳の実行例１

第 13 部

図自動翻訳

6.2: 機械翻訳の実行例２

609

610

1989 年度 WIDE 報告書

図6.3: 機械翻訳の実行例３

第 13 部

図自動翻訳

6.4: 機械翻訳の実行例４

611

612

1989 年度 WIDE 報告書

図6.5: 機械翻訳の実行例５

第 13 部

図自動翻訳

6.6: 機械翻訳の実行例６

613

614

1989 年度 WIDE 報告書

図6.7: 機械翻訳の実行例７

第 13 部

図自動翻訳

6.8: 機械翻訳の実行例８

615

616

1989 年度 WIDE 報告書

図6.9: 機械翻訳の実行例９