一般化への探求
言語学分野では型付き素性構造に基づく文法理論
オブジェクト指向と型付き素性構造の親和性
現在、自然言語処理のナウなヤングにバカウケなのは、主辞駆動句構造文法(HPSG), 一般化句構造文法(GPSG), 語彙機能文法(LFG)といった理論です。といっても市井の人間の言うことなので、学生の方は絶対に鵜呑みにしないでください。専門家の方は鼻で笑ってくださっても結構ですが、ナウなヤングを僭称する私としては、1985年に生まれて現役ばりばりのHPSGが特にバカウケです。
素性構造に基づく諸理論の魅力
洗練された方法によって、力仕事を頑張らなくても文法を記述出来るというのが、これらの理論の特長といえます。
統語理論の研究者は倹約に対する配慮を重んじる。複数の分析の選択基準として、「一般化をとらえる」ことの望ましさに重きが置かれる。エレガントな記述を与えることに対するこのような感心はこの分野に限ったことではない。とはいえ、言語学の立論においてはおそらく他分野より顕著にあらわれている。
アイバン A. サグ, トーマス ワソー(著); 郡司隆男, 原田康也(訳)『統語論入門－形式的アプローチ（下）』（岩波書店）p.1より。
という表明が如実に物語るように、型付き素性構造の発明は統語理論に見通しの良さをもたらしました。際限のない許容規則の積み重ねをするより、制約規則をモジュール的に付け加えていく方が現実的です。これはActive DirectoryでDenyより先にAllowを設定することが稀であることと似通っています。例え話の粒度はいい加減ですが。
一般化の実例：数と格の一致
例えば名詞句の成立要件の一つとして「名詞と形容詞の数が一致していること」という制約を宣言するために、
NPSINGULAR → ASINGULAR NSINGULAR
NPPLURAL → APLURAL NPLURAL
長尾真(編)『岩波講座ソフトウェア科学15 自然言語処理』（岩波書店, 1996年）、p.166より改変引用。元はNP → DET Nでしたが、エスペラントならではの例としてNP → A Nを用いました。
という（単数と複数で二つの）規則を書くのは面倒です。これだけなら1が2に増えただけですが、例えば格（主格と対格）を考慮すると2*2で4つになり、万事この調子で組み合わせ的に規則を生やしていかなければなりません。
そこで、数と格という文法範疇に一致のための制約を設ける（構造共有する）と、以下の「ような」形になります。
|~ ~| |~ ~| |~ ~| | CATEGORY = NP | | CATEGORY = A | | CATEGORY = N | | NUMBER = n | -> | NUMBER = n | | NUMBER = n | | CASE = c | | CASE = c | | CASE = c | |_ _| |_ _| |_ _|長尾真(編)『岩波講座ソフトウェア科学15 自然言語処理』（岩波書店, 1996年）、p.168 より改変して引用。
原文はNP = DET ⊔ Nですが、上記の例に合わせてNP = A ⊔ Nにしています。「ような」と強調したのは、開発中のエスペラント日本語翻訳システムErmitejoに於けるエスペラント文法の実装とは全く異なる図であるからです。AVM（素性型行列）は全く異なります。この例に関係のない素性は省略していますし、素性名や素性の位置も異なります。そもそも単一化だというのにスキーマではなく書き換え規則然とした書きぶりですが、あくまで例示のための便宜的な図だと思ってください。
一般化オブジェクト指向と型付き素性構造の親和性
ともあれ、せっかくエスペラントの自然言語処理を志向するのですから、私は
- 他の言語に比べれば比較的一般化し易い特性を最大限活用し、
- その特性を活かせる文法理論を採用する
という策を採ることにしました。勿論、他の言語でもこれらの理論はお勧めです。およそ言語とは例外の集成であり、エスペラントもその軛をから逃れることは出来ませんが、他の言語はその比ではありません。そうした例外の山と勝負する場合には、表層で定義した構造を深層で上書きするということで例外を実現出来るこれらの理論の強力性がさらに発揮されるでしょう。
情報科学分野ではオブジェクト指向
オブジェクト指向による一般化
次は、理論を設計と実装に落とし込む道具についてです。言語学に優るとも劣らぬ「一般化」への探求は、他でもない情報技術の分野で発露していると考えます。情報技術といっても、
- 私に飯の種を提供している金融ユーザ系システム会社がバックエンドシステムで使っているCOBOL
- COBOLの区分コードによる処理振り分け（テトランじゃないんですから……）
- それらに付随する「旧来の」汎用機文化
- 各種の手続き型言語
などの多くの部分とは、残念ながら相容れません。正直なところこれらも「頑張っちゃっている」感があまりに強くて、最近は暗澹たる思いが募ります。いやまあ単なる愚痴ですが。
では情報技術の何が一般化を求める思想と合致しているのでしょうか。それはオブジェクト指向の設計と実装です。オブジェクト指向の利点の一つに、コードの再利用が容易であることが挙げられます。コードの再利用性を高めることで効率的に成果を達成することが出来、腰を据えてコードにお付き合いするからこそ品質も上がるというものです。
オブジェクト指向と型付き素性構造の親和性
実は、と勿体振るまでもありませんが、オブジェクト指向は素性構造と大変相性が良いです。以下に型付き素性構造とオブジェクト指向の対応表を掲げます。
| 素性構造 | オブジェクト指向 |
|---|---|
| 型 | クラス |
| 型階層 | クラス階層 |
| 型の継承 | クラスの継承 |
| 素性値の上書き | オーバーライド |
まるで示し合わせたかのように合致していますね。あと足りないのは型の単一化くらいです。
例えば字句解析を明けて形態素解析を行う段では、語を一つのオブジェクトと見なすと扱いが楽です。例えばgrandajn leonojnの曲用を還元する（stemming）場合、形容詞だろうが名詞だろうが構わずに$word->stemという形で実現出来ます（Perl 5での例）。つまり、ポリモーフィズム（多態性）の恩恵を享受出来ます。
例によって実際の次版のコードとは違いますが、あくまで説明用ということで。実際には語クラスの中に形態素やら語幹やら語根やら語尾やら接辞やらといったクラスがCompositeパターンで紐付いていたりします。
力仕事で「頑張っちゃう」ことへの戒めも共通している
なお、類似点の一端としては、上述した書き換え規則の（素性構造と比べての）悪い点が、マーチン ファウラー(著); 児玉公信, 友野晶夫, 平澤章, 梅沢真史(訳)『リファクタリング～プログラミングの体質改善テクニック』でいうところの「コードの不吉な匂い」に似通っていることでも示されています。即ち、
- 重複したコード(p.76)
- 変更の発散(p.79)
- 変更の分散(p.80)
- データの群れ(p.81)
等々が該当しています。
P言語と型付き素性構造の親和性
オブジェクト指向言語という切り口以外でも、素性構造と親和性のある言語があります。それはLL(軽量言語)の中でもPerl, Ruby, Python, PHPなどのいわゆるP言語で、これらの組み込みデータ型は素性構造を巧く実現出来ます。
| 素性構造 | 軽量言語での実装法 |
|---|---|
| 素性構造(feature structure) | ハッシュ, 連想配列 |
| 素性(属性, attribute) | ハッシュキー |
| 素性値 | ハッシュ値 |
| 素性構造の入れ子(nesting) | ハッシュの入れ子 |
| 素性構造の順列リスト | リスト, 配列 |
私がもっぱら使っているPerl5では、素性構造のセット(set, 集合)のみが組み込みデータ型にはありません。集合演算はSet::ScalarまたはList::Compareにて実現します。Perl6であればjunctionという組み込みデータ型が出来るので、楽しみですね。なお、Pythonならsetを使えます。
ウェブシステムを作ろうとするならば、企業向けアプリケーションでなければJavaやC++ではなくPerlなどを使うことが多いでしょうが、特に自然言語処理関連ではこうしたスクリプト言語の軽快さと柔軟さがとてもよく働きます。
その他の言語
自然言語処理ではPrologをはじめとする論理型言語の活用例も多く、これまでの技術やノウハウの蓄積も大変な物があります。
また、C++からも使える論理言語的ライブラリを備えるという、鬼に金棒的なLiLFeSという言語も、とても素晴らしい言語です。私は上述した「足りないのは型の単一化くらい」という現状に対応するために（PODとコメントが7割方を占めますが）6000行くらいのコードを書きましたが、LiLFeSなら言語に組み込みまれて用意されていますので、文法の記述に専念することが出来ます。
どれも素晴らしいですが、流石に私自身の慣れの問題などもあって、私のシステムでは採用していません。
そもそもここまで掲げてきた以外の言語での実装が不可能ということは有り得ません。それに、スタンドアロンアプリであれば、言語の実行系をユーザにインストールして貰うのは敷居が高いために、LLという選択肢は考え物です。
結局のところ、実装に用いる言語は理論と同様に道具の一つであるので、適用範囲とよく相談して言語を選択するのが良いかと思います。ただし、言語仕様的に設計と実装で「頑張ってしまう」ことにも繋がりかねないものについては、再考することも選択肢の一つだと思います。
結論に代えて ～ 何を求めて、何を作るのか
ここまで、近代的な自然言語処理の方法の一つの選択肢をご紹介しましたが、これはあくまで選択肢に過ぎません。自然言語処理システムに何を求めるのかという観点によって、作る内容もまた大きく異なってきます。
早熟型は稼働が早くてそれなりの機能も得られるが、いつかは行き詰まる
例えば、出版社によっては中学1年生の英語の教科書の最初の方に「訳語ルビ振り」がありますが、そのような手法であれば上野式・US式でなくても単語をベタに書けばよいです。上野式・US式の訳文品質向上の道を辿らず、その基礎部分のみを採用した場合には、辞書さえあれば比較的容易に実現出来ます。
これはユーザにとっても利点があります。アキラさんのブログへもコメントしましたが、バザール方式でいう「早めのリリース。しょっちゅうリリース」は、ユーザにとっても早い内から「それなりの物」に触れられるのでお勧めです。
勿論、リスクとリターンは背中合わせであり、楽をしすぎてしまうと深い解析や巧みな生成を阻害してしまうことは留意する必要があります。
大器晩成型は完成形では感動品質を得られるかも知れないが、立ち上がりが遅い
私の場合は夢を大きく掲げて意味ピボット式を最終的に目指していますが、「頭でっかち」な設計であるために実装がまだまだ追い着いておらず、字句解析・形態素解析の結果に適当な（×適切かつ妥当な ○テキトーな）単語訳をぶちまけただけの「文章内単語訳」くらいしか公開出来ていません。
稼業の多忙さにかまけて万事楽をする癖が付いてしまい、苦労しなければならないところも楽をしたがる悪い癖が付いて、自作をヴェイパーウェア呼ばわり出来るくらいの私の例は余り参考にならないにせよ、大器晩成型は産みの苦しみが長く続くことに留意する必要があります。
好きこそものの上手なれ
しかし、どのような道具を使うにせよ、結局は携わる有志の熱意こそが全ての源です。その意味では、興味を持った分野に楽しみながら付き合い続けていくことが、成功への一番の近道なのかも知れませんね。
謝辞と蛇足
上記でバザール方式を例示した割には、私のエスペラント日本語翻訳システムErmitejoは（公開するに足るドキュメントがないだとか、ライセンスが未定だとかといった理由で）現段階ではオープンソースに出来ていません。きりのいい時点でそれらを整備してオープンソースにする予定です。
なお、完全な余談ですが、COBOLを使っている事くらいは、取締役が社外講演で熱く語ったり、それがIT系ニュースサイトでも公開されているので、書いても大丈夫です。
余談ついでに、COBOLもCOBOL2002（いわゆるオブジェクト指向COBOLという、フランケンシュタイン的な怪物）であれば違うのでしょうが、Cの置き換えくらいにしか捉えていずにJavaを使う某社は、COBOL2002でも「オブジェクトを使わないこと」という設計・実装規約がまかり通りそうです。これが冗談で済まないのですから、いやはや現実というものは怖いものです。
なお、書き終わりに際して内容を振り返ってみると、2006年の春にサイトを開いて以降、殆ど初めてと評して良いほどにまともっぽい設計の話をしたような気がします（さわりだけですが）。末筆で恐縮ですが、切っ掛けを提供してくださったアキラさんにお礼を申し上げます。
記事の配信