Ermitejo - エスペラント語日本語翻訳

日本広しといえど、今更エスペラントと日本語の翻訳システムという「車輪の再発明」を行おうという物好きは私くらいのものだと思っていましたが、先日物好きの仲間が増えました。アキラさんという方です。「エスペラントを勉強せずに」というブログを立ち上げられ、精力的に更新を続けていらっしゃいます。

ブログを数ヶ月も平気で放置するどこかの誰かはアキラさんの爪の垢を煎じて飲むべきだと思いました。

という反省はさて措き。そんなアキラさんが上野式システムにいたく驚かれているようです。「上野式」というのは、故・上野俊夫氏が1985年4～6月の「PCマガジン」（ラッセル社）に連載された機械翻訳のシステムです。その後同社から『パーソナルコンピュータによる機械翻訳プログラムの制作』として書籍にもまとめられています。

その「驚き」というのは、私もいつか来た道です。現在は「敬意を表して別の道を行く」こととしています。この記事では、自然言語処理を趣味で取り組んでいる方へ向けて、「別の道」を採った判断根拠や、「別の道」としてのHPSGやオブジェクト指向Perlという道具仕立ての利点などを、簡単ではありますが紹介してみます。

上野式・US式の効用と限界

伝統的な機械翻訳の手順

上野式の位置付けを明らかにするためにも、まずは一般的な機械翻訳がどのようなものかをおさらいしましょう。伝統的には以下のような手順を踏みます。

機械翻訳の解析/生成のトライアングル

長尾真(編)『岩波講座ソフトウェア科学15 自然言語処理』（岩波書店, 1996年）、p.463「図12.1 解析/生成のトライアングル」から引用・改変。三角形を上下反転させた他、斜体青文字を追記しました。

統計翻訳などの方法論は谷底の辺りの処理が異なりますが、ともあれ大抵の翻訳というものはこうした超大枠のTemplate Methodパターンに則って実装を進めます。

卑近な例ですが、エスペラント日本語翻訳システムErmitejoでは、最終的に意味ピボット方式を志向するという野望を抱いています。ただし、当初は構文トランスファ方式で正式版としての公開を迎えるつもりでもいます。

上野式の位置付け ～ 何が大変なのか

規則の量が多い

上記の図を踏まえて上野式を見ますと、単語訳方式に近い形の構文変換（構文トランスファ）方式を採用していることが解ります。この微妙な表現を噛み砕くためには、上野式の直系として「US式」を提唱していらっしゃる柴田勝征氏の言葉を引用するのが妥当でしょう。

ここで注目すべき点は、上野方式は、実質的に句構造木を生成しているにもかかわらず、英語から日本語への変換自体は、ごく簡単な直接変換方式の手続きを再帰的に繰り返しているにすぎないことです。そして、構文木の変換規則も、（母親ノード、娘ノードたち）という2世代だけの「系図」に関するものを用意すればよいのです。

柴田勝征『C原語による英和翻訳システム』（ラッセル社, 1990年）pp.29-30より引用。

語弊を恐れずに乱暴に表現するならば、書き換え規則をいっぱい用意して頑張って変換しよう、という方式です。

ただ、アキラさんが感じられたような「”for Tokyo”が辞書に必要である」というのは、少なくともUS式であれば大丈夫です。とはいえ「自然な訳語」を実現するために句レベルでの変換規則を辞書に載せる必要があるため、大変なことには変わりがありません。とかなんとか書いている内に、アキラさんは「単語の親ノードに規則を設ける」という上野式の正攻法で解決されたようで、良かったですよね。

さて、そうはいっても語形変化（屈折のこと。つまり曲用と活用）程度であればアキラさんのように辞書の自動生成を行う手もありましょうが、変換規則の自動生成は流石に大変です。人間がやるのはもっと大変で、見通しが付かなくなります。

組み合わせが爆発と影響分析に苦労する

さらに忘れてはならないのが、規則が多くなると、規則の組み合わせが爆発することです。何か一つの変換規則を追加・変更・削除する度に、他の変換規則への副作用が起きていないかを確認する必要があります。

今風のテスト駆動型開発の枠組みであれば、徹底的にエンドツーエンドテストケースの山を用意すれば副作用の検知それ自体は容易に出来るかも知れません。しかし、副作用が起きないように細心の注意を払って規則を編集するのは、いかにも大変というものです。翻訳システムの真髄は語彙辞書と訳語辞書にあるのですが、これらを拡充する作業の生産性に難があるのは、なかなかに厳しいです。

このサイトの参考文献一覧でも言及していますが、かつて私は、諸々の書籍でこうした分野の情報を集めたとき、真っ先にこう思いました。

しかし、さすがにO(n!)オーダでの影響分析が必要な書き換え規則の保守はぞっとしないので、Ermitejoでは根幹の処理への適用は行わないこととしました。

つまりそれは、いかにも「頑張っちゃっている」感が強すぎて、私のような不精者にはとても務まらないという驚きでした。これはアキラさんと同じ種類の驚きだろうと推測します。

そもそも、何でこんなにも苦労しなければならないのでしょうか。それは、逆説的ですが、苦労する方法をわざわざ選ぶからに他なりません。

楽をしよう

時代は変わり、理論と実装も変わる

私は先人の労作を否定しません。何せ20年以上も前のことです。PCで翻訳システムを作るというのは、1985年当時にしてみれば或る意味では革命的な出来事でしょう。当時の限られたコンピュータ資源を用いて現実的な速度と品質で翻訳を行うのには、上野式は必要にして十分な方式だと思います。

こうした試みがなければ、翻訳システムの開発という刺激的な題材は、大学院や企業の研究室の中にとどまっていたかも知れません。専門家が魔術的に楽しむだけではなく、私のような市井の人間でも楽しめるようになったのは、24年も前に「やろうと思えば出来る」ということを明らかにした上野さんの偉大な功績に他なりません。

しかし、時代は変わっています。

アポロ計画用計算機よりも際限なく高性能な計算機は、お澄まし顔で家庭に鎮座しています。前の記事で“フォースの暗黒面”ことモンテカルロ法の話に触れましたが、富豪的プログラミングを平気で行えるいい時代になりました。そして、理論が先か実装が先かというと理論ではありますが、近代的な理論を自然言語処理の場で実際に回せるようにもなりました。統計翻訳のように性能を活かす理論の現実味もますます増してきています。

現代の理論と実装を使わないのは勿体ない

昔は限定された範囲の使用法でも良かったはずです。計算機の限界に人間が折り合いを付けていました。上野式が世に燦然と登場した当時、翻訳に求める精度は今ほど高くはなかったでしょう。

しかし、今では翻訳サイトで荒訳を簡単に得ることも出来ますし、市販の翻訳ソフトは使い方次第で実用に堪えうる品質の訳文を得られることが多くなりました。さらに、先進の翻訳家は翻訳支援システムとしての「翻訳メモリ」ソフトを活用しています。

これらと24年前のシステムを比べるのは流石に申し訳ありません。現在私達が翻訳システムに求める水準は、昔から遙かに上がって来ているのです。そうであれば、今使える道具を活用したいと私が思ったのも、自然な流れでした。

頑張らなくてもいいことは頑張らない

そもそも「頑張っちゃう」ことを私が避けたがるのは、何故でしょうか。それは、今日の理論や計算機性能が人間の変わりに頑張ってくれることを、昔ながらの手工業的に自分でやってしまおうとすることのしんどさが目に付くからです。自然言語処理に限りませんが、他に任せられることは任せて楽をしてみるのは上策です。一つの方法に固執せず、他の優れた方法があれば、それを取り入れる勇気を持つと、経験的にいいことがあります。

真面目に努力することが格好悪いとか、熱血主義を冷笑するわけではまったくありません。真面目は大好きですし、熱血愛好家なのですが、要はベクトルの向き先次第といったところでしょう。さらに、楽になって空いた時間は、その分を品質の向上などの「真にやりたいこと」に充てられます。まさに「選択と集中」ですね。

勿論、自分自身がオレオレフレームワークを作るという車輪の再発明をしていますので、効率のみを優先するのが良いとは思いません。思いませんが、効率の代償が必要だとは思います。私の場合は学習のためであったり、将来的に言語モデル自体もCGMとして共有するためなどの理由で、敢えて車輪を作ったという次第です。

古いものが全部駄目ということでも勿論ありません。訳語の形態素生成処理での工夫については、US式は今でも見るべきところが多く、大変参考になります。

一般化への探求

それでは、今ではどんな理論・設計・実装方法があるのでしょうか。比較的見通しの良い理論とシステムの組み合わせとして、私はHPSG（主辞駆動句構造文法）とオブジェクト指向言語を使っています。

次のページでは、何故それらの道具仕立てが効果的なのか、「一般化」というキーワードに絡めて概要を簡単にご紹介します。