2007/9/15
分類: 開発記 / タグ: VOCALOID, 形態素解析, 辞書引き, 音韻解析
発音関連のモジュールの開発に於いては、母音省略という要件をすっかり忘れていたので、せこせこと修正を重ねる羽目となりました。散文については文字通り書き散らかすことは苦ではなく、呼吸するように（少なくとも手書きよりは早く）書けるのですが、芸術的感性といったものを人生の道の途中に落として来たらしく、韻文を書くことが日常生活で皆無でしたので、考えからすっかり漏れていました。というところで、電車に揺られる朝の通勤時間帯に思い付きでメモした機能は、要件定義と外部設計は勢いで書けたとしても、詳細設計ともなるとなおざりになってしまいました。
それはさて措き、こうした開発をしていると、目下話題急上昇中の初音ミクに、エスペラントで歌わせることが出来るのではないかと思うようになりましたので、以下に考察を述べてみました。
(#36「初音ミクはエスペラントで歌えるか」の続きを読む)
2007/9/14
分類: 公開, 開発記 / タグ: 処理概説, 形態素解析, 辞書引き, 音韻解析
ようやくversio 0.9.0で実装を始めた音韻関連の機能が整いつつあります。直近で更新した内容は、韻文中での発音に関する二点です。
修正点 versio 0.9.5の詳細と、実装方法の紹介
versio 0.9.5 (23-a publikigo, en 2007/09/11)
- 【機能追加】韻文中の「’」で終わる語の発音（アクセントを含む）を正しく表示するようにしました。例えば、esper’をこれまで「エスペル」と読んでいましたが、正しく「エスペール」と読むようにしました。
- 【機能追加】「l’」の後に母音が続く場合に、発音を後続の語と融合するようにしました。例えば、韻文中でl’ esperoではなくl’esperoと続けて書いたとき前提ですが、「ルエスペーロ」ではなく「レスペーロ」と読むようにしました。
前者では、アクセントを変更しないという点が曲者です。エスペラントの規則性ゆえに、実装も極めて論理的かつ簡素なものとなっていたのですが、こういう特例の存在により、優雅さとは程遠い泥臭い実装を行う羽目になります。前者ではl’を「ル」と読めるようになるのですが、l’armoをルアーモと読んでしまうために、ここでも特例を設けてラーモと読めるように処理を書き加えました。
エスペラントの字面から発音を得るロジック
良い機会なので、発音をカタカナやIPAで転記する処理の概要をご紹介します。あまり変なことを考えず、人間の頭の中で行っている処理を素直にコード化することが一番と言えます。
- まず、これまでの形態素解析で、既に語根や接辞の区切り文字を持った文字列が得られています。例えば、samideanojnという単語はsam/ide/an/o/j/nという文法上の区切りです。
- ここで、単純に「/」を区切り文字として、splitにより元の文字列というスカラを一旦リストに分解して配列に突っ込みます。
- この配列について、接尾辞や品詞語尾であった場合には、前の要素と結合するようにします。例えば、
('sam', 'ide', 'an', 'o', 'j', 'n')は('sam', 'ideanojn')になります。これはまだ文法上の区切りですが、続け読みが出来るように配慮された配列になっています。
- それぞれの要素について、「子音」「母音」「子音と母音」という音韻上の区切りを得ます。この際、文字が母音か子音かを判断しながら、文字を一つずつ処理していきます。内部処理では字上符付き文字をx後置式としているので、ここが私がうっかりはまった陥穽でした。
'sam'は('sa', 'm')に、'ideanojn'は('i', 'de', 'a', 'no', 'j', 'n')に分解されます。これで、それぞれの要素が一つの音に対応するような配列になりました。
- 上記を結合して
('sa', 'm', 'i', 'de', 'a', 'n', 'o', 'j', 'n')というリストを得て、配列に突っ込みます。
- アクセント位置を決定します。配列を後ろから辿って、二つめの母音がある要素がアクセント付きの場所です。
- 上記状態を、単純にIPAに置換します。エスペラントのアルファベートはIPAと1対1の関係にありますから、単純に
trすれば事足ります。アクセント位置には長母音の記号を与えて完成です。samとideanojとの間は空白を入れておきます。
- また、カタカナ発音にも置換します。カタカナ発音は子音と母音からなる二重ハッシュ構造を予め作っておき、ハッシュのキーをそれぞれ指定すれば事足ります。例えば、
'sa'は$japana->{'s'}{'a'}で「サ」が求まりますし、母音のみや子音のみの場合にはダミーのキーを与えて$japana->{'m'}{'_'}で「ム」、$japana->{'_'}{'i}で「イ」が求まるという次第です。長母音で「ー」を与えて完成です。
このように可能な限り手を抜いて楽をして発音させている無邪気な実装なので、世知辛いesper’などという文字列を与えたら、まず「’」なんてハッシュキーがないのでこけますし、これを無視したら母音が一つ足りないわけでエスペル（エがアクセント）と読もうとするしで大変です。
そこで、以下のように機能追加することによって、こうした言語現象にも対応出来るようにしました。
(#39「エスペラント発音解析の実装方法 (単語辞書引き機能 versio 0.9.5)」の続きを読む)
2007/9/12
分類: 開発記 / タグ: 形態素解析, 辞書引き
本サイトで提供している「エスペラント語単語辞書引き機能」の形態素解析（・単語変換・文字列生成）機能が、エスペラント検定に合格したことを発表致します。……といっても、Akademio de Esperanto（エスペラント学士院）や日本エスペラント学会等の機関により権威付けられた検定では全くなく、けんてーごっこというサイトで有志が公開しているいくつかの検定を通過しただけです。半ば確信犯（誤用）的な発表ですが、景気付けということでご寛恕願います。
例えば『エスペラント合成語検定第三弾』を例に取りますと、最初はエスペラント日本語小辞典にも（合成語の形で）見出し語が存在するsendependeco等の語がありますが、進めていくとporvirina等の、『小辞典』の語根を組み合わせないと訳語に辿り着けないような合成語も出て来ます。この検定は三択問題の連続となっていますが、「引っ掛け」としても優れた選択肢が用意されています。poŝtelefonoを例に取り上げますと、poŝt/…と区切ってしまった場合の「“郵便”貯金」という選択肢があったりします。この辺り、出題者のbarkituro氏（「空想エスペラント」著者）の機知に感心致しました。なお、語根区切りを間違えて「郵便」という形態素訳を誤導出する例は、エスペラント日本語翻訳プログラムの先達である山野敏夫氏が「トラちゃん95処理概要」にて採り上げています。
何にせよ、上記の例ですと合成語の分解理解には成功していることが裏打ちされているわけで、設計書のメモの山だけでコードが1行もなかった1年前と比べれば、本サイトの翻訳システムの土台である形態素解析機能も成長した感があります。親馬鹿のようですが、「ごっこ」とはいえ合格を賜ったことは素直に嬉しく感じました。日本エスペラント学会が開催するエスペラント学力検定試験のエス和翻訳部分で満点をいただけることを目指しつつ、エスペラント語日本語翻訳システム「Ermitejo」の完成を目指して邁進する所存です。
もっとも、「ごっこ」とはいえあくまで検定ですので、本サイトの辞書引き機能の実力を計るのではなく、皆さんご自身が受験する場合には、本サイトの機能をお試しになるのは受験結果が出た後の復習まで取っておいてくださいね。
……と、もっともらしいことを書いておきながら、音韻関係の開発の際に参考となるウェブサイトを求めてGoogleの結果に引っ掛かった上記サイトに於いて、真っ先に本サイトの辞書引き機能を用いてカンニングしたのは内緒です。ただ、『エスペラント検定大学編』については、流石に天地神明に誓って素直に受験しました。元歴史学徒としてはつつがなく合格しましたが、どちらかというとエスペラントというより文化史的な分野の問いで、人工知能でいうところのいわゆる世界知識が必要となるような問題でした。これをプログラムにカンニングさせるには、翻訳システム以上の実装が求められそうです。
2007/9/10
分類: 公開, 開発記 / タグ: 処理概説, 字上符付き文字, 形態素解析, 辞書引き, 開発環境, 音韻解析
音韻関係のモジュールを先の辞書引き機能の改版に合わせて新規に作成したのですが、予想通り、初物の機能はなかなか安定しませんでした。それというのも、エスペラントの規則性を過大評価したというかこれに甘えてしまい、乏しいテストケースしか用意しなかったのが敗因と言えます。結果、連日連夜の改版を行うこととなりました。大多数の場合は問題なかったとはいえ、誤った発音が表示されたり、処理が異常終了したりすることがあり、反省しています。
もう少し具体的に述べますと、エスペラントの規則性に例外があるというのではなく（sam/ide/an/oやらといった場合は除きますが）、Perlで字上符付き文字を実装する際に手抜きをしており、これが後々尾を引いているといったところでしょうか。
実は、エスペラント語日本語翻訳システム「Ermitejo」は、21世紀、このUnicodeの時代に、字上符付き文字の内部処理を前時代的なx後置式の代用表記で行っています。関数名やら変数名やらをエスペラント式に名付けているだけなら特に問題がないのですが、取り扱うデータを代用表記すると、色々不都合が起きます。
普通に処理している場合には、外部から正書法ないし代用表記で突っ込まれたデータのアルファベートを変換して内部で使い、外部に表示する際には逆変換して正書法で返しているので問題はありませんでした。しかし、エスペラントの誇る1文字1音という原則が崩れ、「ĉ」の音「ʧ」を「cx」と2文字で表現することになりますので、音韻関係の機能の実装で舞台裏が拙さが露見したという次第です。
責任転嫁するつもりは毛頭ありませんが、コーディングに使っているエディタのサクラエディタがUTF-8への対応が甘く、なかなかこうした悪癖を改められないという思いもあります。サクラエディタは内部コードがUTF-8等ではなくShift-JISなので、UTF-8のファイルの読み書き自体は出来ますが、エスペラントの字上符付き文字等やIPA等は保存出来ないので、痛いところです。今更秀丸にも戻れませんが、さりとてサクラエディタの抜本的な書き直しを行える技量も時間も私には無いので、開発者の方々に声援を送ることしか出来ません。
【追記】kobake氏のウェブサイト「digital hole」にて、UNICODE版サクラエディタの開発が進められています。
ということで、そうした発音関係の修正を中心として、ここ数日での改版点の委細を以下に転記します。
(#33「字上符付き文字の葛藤 (単語辞書引き機能 versio 0.9.4)」の続きを読む)
2007/9/8
分類: 公開, 開発記 / タグ: 未実装, 辞書引き, 音韻解析
構文解析機能の開発の息抜きに、エスペラント語の単語辞書引き機能へ発音関連情報を追加しました。辞書引き結果に国際音声記号(IPA)とカタカナ読みの表記を新たに加えることにしたものです。
エスペラント語は表記と発音が完全に一致している言語ですので、実装は割合簡単でした。接尾辞や文法語尾等は語幹と融合し、その一方で接頭辞と語幹や語幹同士は融合しないという規則さえあれば、後は単にエスペラントの字母（アルファベート）をIPAに字訳したり、「子音」「母音」「子音＋母音」でカタカナに置換したりするだけで実現出来ました。アクツェント（アクセント）も後ろから二番目の母音に必ず付与されますし、その後ろに子音が二つ連続している場合を除いて長母音とすることも、一貫した論理（ロジック）で記述出来ます。
とはいえ、sam/ide/an/oを「サムイデアーノ」ではなく慣用化した「サミデアーノ」と読む場合は例外ですので、今は実装していません。また、アクツェント付き母音の直後にtr, dr, br, bl, kv, dzのように連続した子音がある場合には人により長母音にすることもあるそうですが、これも未実装です。なにぶん息抜き程度の機能なので、今後の実装優先度も低い物と考えています。
上記の通り、（ほぼ）完全な規則性に基づく発音なので、初学者の方や、興味本位でエスペラントの“触り”を眺めたい方以外には無用の長物かも知れません。とはいえ、エスペラント語日本語翻訳システムが完成した暁には、そうした方々にもお使いいただいて、エスペランティストの間口を広げたいと思っているので、こうした「言わずもがな」な機能を敢えて盛り込むことも大事だと、私は思っています。
なお、9月7日の朝日新聞の夕刊に、JR釜石線の駅にエスペラントの愛称が付けられている旨の記事（矢野直美氏のコラム「鉄子の鉄学」より、「銀河ドリームライン」）が載っていたため、それで興味を抱いて当サイトを訪れたというシナリオで何気なくluna noktoを検索してみたところ、versio 0.9.1で是正することになった障害が判明しました。いやはや、業務ですらコーディングから離れつつあるというのに、いわんや業務でないとテストケースがなおざりになりがちで、反省するところしきりでした。
その他、ここ数日で連続した改版点の委細は、以下の通りです。
(#32「発音関連情報の追加、他 (単語辞書引き機能 versio 0.9.1)」の続きを読む)
記事の配信