1995年10月14日に東京大学山上会館で行なわれた、 「かな漢字変換システムについてのワークショップ」のメモ version 0.2(1996.10.23) この文書について:  この文書は、1996年11月23日〜24日に行われる「日本語入力システムに ついてのワークショップ」参加者に、前回の催しについての予備知識を 持ってもらうために、その場で行われた議論の内容を紹介する文書である。 上記ワークショップ参加者の一人である狩野宏樹(g92k0323@mn.waseda.ac.jp) が、参加当日に取った自筆のメモと、前田薫(maeda@src.ricoh.co.jp)氏が テキストファイルの形でお寄せくださったメモ、当日に参加された方々の ご意見を元にして、当日参加しなかった人に、その場の雰囲気を分かって いただけるように書いたものである。  文書の著作権は狩野・前田の両人に属するが、この文書の内容を改変 しない限りに於いて、自由に複製・配布することができる。また、内容の 不備についての責は、文章をまとめた狩野にすべて属する。  この文書は、できる限り正確になるように配慮しているが、個人の主観 に基づく不正確な記述があるかもしれないし、事実関係についての完全な 正確さを保証しない。また、この文書は jus の公式な立場を代表するもの ではない。より詳細な情報を求める人は、その他の、より信頼できる文書など を用いて記述の内容を確認してほしい。  jus のウェルカムページ(http://www.jus.or.jp/)からたどれる場所 (http://www.iijnet.or.jp/jus/workshop/ime-ws.html)に、jus が発表 した、「かな漢字変換システムについてのワークショップ報告」がある。 その文書を予め読んでいただけると、理解しやすくなると思う。  この文書の version 番号(0.2)は、まだβ版であることを意味している。 内容が、予告なしに変更されることがある。 ★午前の部(講演) ● Wnn コンソーシアム・和賀さん  「Wnnコンソーシアムの活動報告」 私は遅刻して、この報告の途中からしか聞くことができませんでした。 jus の報告を読んでください。 ●慶応大学理工学部・土井先生  「計算機言語とキャラクタセット」 計算機言語で、日本語などの ASCII 以外の文字が使えるかどうかと いう話でした。大まかに言うと、 ・古い言語(FORTRAN, COBOL など)は、規格で保証されているのは ASCII  のみで、処理系ローカルの拡張して、文字列への使用に対応している。 ・新しい言語では、ASCII のみか、ISO 10646 に決め打ちにしている  場合が多い。 ・国際規格の制定に皆さん関心を持って欲しい。 という話でした。 ●「日経パソコン」副編集長・西山さん  「かな漢字変換システムの評価と問題点」 ○読者向けの記事を書いている。 平均的な読者像 平均40歳台のビジネスユーザで6割が98ユーザ。 パワーユーザと呼ばれる人はあまりいない。 売上部数は20万部(業界一位。ASCIIは13万) ※「読者の意見」がこのようなユーザのものである事に注意。 ○どのようなIMEを使っているのか? 読者へのアンケートで使っている*ワープロ*を尋ねた。 一太郎が過半数。AI変換つきのATOKは40%。 MS Wordが(つまりMS IMEが)増えている。 ASCII で '94 2月に200人の読者に*Windows上の*IMEを尋ねた。 ATOK 8 42% MS IME(3.1純正) 22% WXII 14% NEC Windows の NEC AI 12% VJE-γ 3% OAK 2% その他のバージョンのATOKが2割ほどなので合わせると過半数。 ○パソコン上のかな漢字変換の歴史 ・DOS時代 2HD 2台にアプリケーションと一緒に入れる必要があった。 辞書も小さかった。 ・DOS(HDDつき)コンベンショナルの大きさ640KBが制限になり、変換ルーチ ンの大きさが重要だった。 ・現在 辞書の巨大化 語彙数 10数万〜30万。 アルゴリズムの高度化 AI変換がなければ今どき売れないんじゃないか? GUI対応のインタフェース 設定などが昔より楽になった。 マルチプラットホーム 辞書の流用。 #「FEP」という言葉から、「IME」という言葉に変わった。 ○現在の流れ ・AIは欠かせない。→係り受け解析。 過去のセールスポイント:2、3文節最小一致 現在のセールスポイント:見てくれる係り受けの挟み込み文節数 ・カタカナ、ひらがな変換の自動辞書登録。 ・ダイアログボックスによる単漢字変換。 ・軽量化より機能強化(ハードがそのうち速くなる) ・プラスαの入力支援 ATOK9 キーボード入力 ローマ字入力の間違いを直す。 揺らぎ変換。間違っていても正確に→ユーザの勘違いがそのままに なる欠点。 WX3の顔文字辞書 辞書データの取り込み、キーアサインの変更 カスタマイズよりも、他ソフトのクローンを望む人が多い。 →パッケージを用意。 ・結果として、どの製品も機能的には同じになりつつある。 ○ユーザの使い方は変わったか? 日経パソコンの読者へのアンケートをまとめると、 ・3 ページ程度の報告書などの入力が主な用途。 ・変換機能に不満のあるユーザは少ない。 ・ATOK8 になって、問い合わせが減った。反面、関心も薄くなった。 ・キーアサインは覚えたら変えたくない。 ・口語の変換にやや不満(だが、需要はあまり無い)。 ・辞書は資産だがメンテナンスはあまりしない(登録しっぱなし)。 ・ATOK の辞書検索との連係機能は不要? (編集部として、製品の)定量的、定性的評価に意義を感じない。 つまり、製品として成熟してきたため、一般ユーザからは特に存在を 意識されないものになってきたのだろう。 ○今後望むこと ・用字用語の基準としての役割 変換辞書を信じる人が増える 辞書ファイルの標準化が必要か? かな漢文法は日本語文法の現代文法部分の体系に近い。 ・登録された用語や係り受けをよそで使えるようにしたい。 ・推敲支援や OCR との連携 ・GUI を生かした判りやすい操作性 ★午後の部(パネルディスカッション) 司会:太田さん(リコー) ●「日本語入力システムのアーキテクチャ再考」 パネリスト:今さん(NEC)・石曽根さん(SRA)・小山さん       (エー・アイ・ソフト)・桑理さん(オムロン) 太田さんの巻頭言: 現在、かな漢字変換が、日本語入力の大半を占めている。 かな漢字変換の作り方について、各パーツ、すなわち、 ローマ字仮名変換 エンジン部――辞書アクセス UI・API など、それぞれのモジュールとしての出来と相互通信の善し悪し などを考えてみたい。 ◎桑理さん:「UNIXの仮名漢字変換におけるアーキテクチャ〜Wnnを例に」 ○ Wnn のアーキテクチャ概説   ┏━━━┓   ┃サーバ┠──┬─────┬───   ┗━┯━┛ ┏┷━┓   ○     │   ┃辞書┃ ユーザ辞書     │   ┗━━┛ 線のつながりは、    ┌┴──────┬──┬──┬─ TCP/IPベースでの ┏━━┿━━━━━┓ │  │  │ 通信を示す ┃┏━┷━━━┓ ┃ ○  ○  ○ ┃┃ライブラリ┃ ┃ ┃┗━━━━━┛ ┃ ┃アプリケーション┃ ┗━━━━━━━━┛ ○辞書の扱い方について Wnn4 では 変換サーバが直接辞書にアクセスしていたが、Wnn6 では、 辞書アクセス専用のサーバを新しく作り、変換サーバはそれと通信し、 「辞書サーバが一括管理 + アプリケーションごとに辞書を持てる」 形になった。        ┏━━━━━┓        ┃辞書サーバ┃        ┗━━┯━━┛    ┌──────┼─────┐ ┏━━┷━━┓ ┏━┷━┓ ┏━┷━┓  ┃変換サーバ┃ ┃   ┃ ┃   ┃ ┗┯━┯━┯┛ ┗┯┯┯┛ ┗┯┯┯┛  │ │ │   │││   │││  ○ ○ ○ アプリケーション 一つの辞書サーバで複数のアプリケーションをサポートすることに なった。「辞書を共有したい」という目的のためである。 ・辞書の共有 システム辞書 ユーザ辞書 共有のグループ辞書 各個人(クライアント)の頻度ファイル グループ共有のユーザ関係辞書 ○「学習情報の他システムとの交換」(今日のポイントはここ) ・現在、辞書サーバとお話できれば共有可能な情報 ユーザ登録単語・自動登録単語 ・将来、可能にしたい情報 同音異義語群内の優先度・文節切り学習情報・共起関係学習情報 つまり、辞書サーバと会話できる変換システムを作れ、 辞書サーバを通じて互いの持つ学習情報を交換したい。 ○学習情報の保存のやり方      ┏━━━┳━━┳━━┳━━┳━━┳━━━━━━━┓      ┃index ┃読み┃候補┃品詞┃頻度┃今使ったよ bit┃      ┣━━━╋━━╋━━╋━━╋━━╋━━━━━━━┫      ┃   ┃  ┃  ┃  ┃  ┃       ┃      ┗┯━┯┻━━┻━━┻━━┻━━┻━━━━━━━┛       │ └──────────┐       ↓            ↓ ┏━━━┳━━┳━━━┓ ┏━━━┳━━━┳━━━┓  ┃index ┃頻度┃今 bit┃ ┃index ┃index ┃今 bit┃ ┣━━━╋━━╋━━━┫ ┣━━━╋━━━╋━━━┫ ┃   ┃  ┃   ┃ ┃   ┃   ┃   ┃ ┗━━━┻━━┻━━━┛ ┗━━━┻━━━┻━━━┛    頻度ファイル         共起辞書 #index は、システム辞書内の単語に振られた通し番号。 #今 bit というのは、辞書内の各単語に対し、変換結果に存在した単語に # 1(使ったよ)をつけ、誤変換の原因となった(つまり、一発変換で #出てきた文字列にあったが、変換文字列を確定した時には除かれた)単語 #に 0(使わなかったよ)をつけ、同音語などの優先順位を決める情報。 ○学習情報の交換 ・現在「index + 情報」の形でやっているのを、  「システム辞書のフィールド + 情報」にしたい。 ・同音異義語の優先度 システム辞書 + 頻度ファイル            ↓     ┏━━┳━━┳━━┳━━┳━━━┓     ┃読み┃候補┃品詞┃頻度┃今 bit┃     ┣━━╋━━╋━━╋━━╋━━━┫     ┃  ┃  ┃  ┃  ┃   ┃     ┗━━┻━━┻━━┻━━┻━━━┛ ・共起関係 システム関係辞書 + ユーザ関係辞書 品詞情報が統一されていないのが問題→各社共通のフォーマットにしたい。 ◎石曽根さん:「X ウィンドウシステムの日本語入力」 変換システムを使って入力サーバを作る立場としての解説 ○ X には日本語入力の機能は無い。キーイベントは ASCII のみ。 ○キーを押下 → 発生したキーイベントをどこが処理するか? 1. アプリケーション組み込み 例:Muleのたまご                ┏━━━━━━━━┓ ┏━━━━┓ キーイベント  ┃アプリケーション┃ ┃X サーバ┠────────→┃┏━━━━┓  ┃ ┗━━━━┛         ┃┃変換機能┃  ┃                ┃┗━━━━┛  ┃                ┗━━━━━━━━┛ 2. 入力サーバ(フロントエンド) 例:DOS の 日本語 FEP。 ┏━━━━┓キーイベント┏━━━━━┓変換結果┏━━━━━━━━┓ ┃X サーバ┠─────→┃入力サーバ┠───→┃アプリケーション┃ ┗━━━━┛      ┗━━━━━┛    ┗━━━━━━━━┛ 3. 入力サーバ(バックエンド) kinput2 はこれ。 ┏━━━━┓ キーイベント ┏━━━━━━━━━┓ ┃X サーバ┠────────╂┐アプリケーション┃ ┗━━━━┛        ┗┿━━━━━━━━┛                   ↓  ↑               ┏━━━┷━┓               ┃入力サーバ┃               ┗━━━━━┛ ○Xの多言語入力の歴史 ・X11R4まで:標準の入力機能なし。           ┏━━━┳━━━━━━┓    ┏━━━━━┓           ┃アプリ┃独自変換機能┃←……→┃入力サーバ┃ ┏━━━━┓ key ev.┣━━━┻━━━━━━┫    ┗━━━━━┛ ┃X サーバ┠───→┃    Xlib    ┃ ┗━━━━┛    ┗━━━━━━━━━━┛ ・X11R5:標準入力API(XIM)が定義された。           ┏━━━━━━━━┓           ┃アプリケーション┃    主な実装:Xsi, Ximp ┏━━━━┓ key ev.┣━━┯━━━━━┫     ┏━━━━━┓ ┃X サーバ┠───→┃Xlib│  XIM  ┃←………→┃入力サーバ┃ ┗━━━━┛    ┃  └─────┨  ↑  ┗━━━━━┛           ┗━━━━━━━━┛通信プロトコルは                     決まっていなかった API(アプリケーションがライブラリを通じてデータを受け取る形式)は 定まったが、サーバとの話し方は定まっていなかった。Xlib の一部である XIM には、通信プロトコルの異なる二つの主な実装が作られた。 ・X11R6:標準入力プロトコル(XIMプロトコル)が定義された。           ┏━━━━━━━━┓           ┃アプリケーション┃ ┏━━━━┓ key ev.┣━━┯━━━━━┫XIM Protocol┏━━━━━┓ ┃X サーバ┠───→┃Xlib│  XIM  ┃←────→┃入力サーバ┃ ┗━━━━┛    ┃  └─────┨      ┗━━━━━┛           ┗━━━━━━━━┛              ・標準化される以前のにも対応しないと困るので、結局プロトコルが  増えただけとも言える。現在対応しているのはkinput2プロトコル・  Ximp・XIMの3つ。 ○kinput2 の内部アーキテクチャ ┏━━━━━━━━━━━━━━━━言語非依存部━┓ ┃     ┏━━━━━━━━┓        ┃ ┃     ┃管理ウィジェット┃        ┃ ┃     ┗┯━━━━━━┯┛        ┃ ┃      ↓      ↓         ┃ ┃┏━━━━━━┓    ┏━━━━━━┓───╂─→その場入力、変換 ┃┃ プロトコル ┣┓   ┃入力スタイル┣┓  ┃  ウィンドウなどの ┃┃ウィジェット┃┣┓  ┃ウィジェット┃┣┓ ┃  機能を提供 ┃┗┳━━━━━┛┃┃  ┗┳━┯━━┯┛┃┃ ┃ ┃ ┗┳━━━━━┛┃   ┗┳┿━━┿━┛┃ ┃   ┃  ┗━━━━━━┛    ┗┿━━┿━━┛ ┃ ┗━━━━━━━━━━━━━━━┿━━┿━━━━┛        ┏━━━━━━━━┿━━┿━━━━言語依存部━┓        ┃        ↓  ↓          ┃        ┃┏━━━━━━━━┓ ┏━━━━━━━━┓ ┃        ┃┃変換オブジェクト┣┓┃描画オブジェクト┣┓┃        ┃┗┳━━━━━━━┛┃┗┳━━━━━━━┛┃┃        ┃ ┗━━━━━━━━┛ ┗━━━━━━━━┛┃        ┗━━━━━━━━━━━━━━━━━━━━━━┛ プロトコル、入力スタイル、変換エンジンを自由に組み合わせられる。 ○変換部分のコンポーネント化 ローマ字仮名変換・かな漢字変換・キーバインディングは分けられる さらに細分化して組み合わせられるか? そもそも、組み合わせて嬉しいのか、まとまっていた方が嬉しいのか? ◎今さん:「ユーザインタフェースの統一のためのアーキテクチャ」 「いろんな入力方法のおいしい部分を組み合わせて使いたい」という考え。 ○『かんな』の構造 開発思想:UI はどこでも使い回せるようにして、emacs 上でも X でも      同じ使用感を得られるようにしよう。 ・既存(UNIX)の構造     ・『かんな』の構造 ┏━━━┓          ┏━━━━┓ ┃ FEP ┃          ┃  FEP ┃ □ ┣━━━┫          ┣━━━━┫/  カスタマイズファイル ┃UI Lib┃          ┃ UI Lib ┠─□ ┗━┯━┛          ┣━━━━┫← UI Lib API   └┐           ┃ RKC Lib┃ ┏━━┷━━━┓       ┗━━┯━┛ ┃かな漢サーバ╂─┐        └┐ ┗━━━━━━┛┏┿━┓    ┏━━┷━━━┓         ┃辞書┃    ┃かな漢サーバ╂─┐         ┗━━┛    ┗━━━━━━┛┏┿━┓                         ┃辞書┃                         ┗━━┛ #前田さんのメモだと、UIlib API は「UI と FEP の間」とあります。 #そっちの方が合っているように思う。 ・UI Lib の存在理由 UIをどこ(tty,NEmacs,Athena Widget,vi)でも使い回せるようにするため 作った。UI Lib は FEP の一部としてリンクされ、それがカスタマイズ ファイルなどの面倒を見る。 ここで今さん曰く: 「UI ライブラリは直せば直しただけメリットがある(使用感が向上する)。 かな漢字サーバの方は直すと不整合につかまって困ってしまう。」 ・他に見られる構造  ┏━━━┓         ┏━━━━━━━━━━━━━━┓  ┃FEP┃         ┃   UI   Lib   ┃  ┗━┯━┛         ┣━━┳┳━━━━┳┳━━━━┫    └┐          ┃ RKC┃┃ RK API ┃┃ RK API ┃ ┏━━━┷━━┓       ┗┯━┛┠────┨┠────┨ ┃かな漢サーバ┃        │  ┃Wnn Lib┃┃SJ3 API┃ ┗━━┯━━━┛        │  ┗━┯━━┛┗━┯━━┛    └┐           └┐   └──┐  └───┐  ┏━━┷━━┓         │      │      │  ┃辞書サーバ╂─┐   ┏━━━┷━━┓ ┏━┷━━┓ ┏━┷━━┓  ┗━━━━━┛┏┿━┓ ┃Cannaserver ╂┐┃jserver ╂┐┃sj3serv ╂┐          ┃辞書┃ ┗━━━━━━┛□┗━━━━┛□┗━━━━┛□         ┗━━┛     『かんな』2.2 で試しに作った。  Wnn6で見られる構造     変換の切り替え・ダイナミックロードする。               自分の好きなUIで複数の変換エンジンを使える。                    けっこう気に入っている。 ○「かんな for Windows」を作って、Windowsの日本語入力に感じた問題点 各 IME の開発者がみんな単漢字パレットを作る。こういう物は、誰が作っても 同じだから他の人の作ったのを使えばいいのにと思う。だが、組み込む仕組みが ない。情報のやりとりの仕組みがあれば、パレットだけ取り替えられるはず。 そういう仕組みが欲しい。 ◎小山さん:「IMEの構造」 図1: Windows 上の IME                        アプリ                         ↑WX2 API             ┏━━━━━━┓  ┏━━━━┓             ┃MS-KANJI FEP┃  ┃WX2.SYS ┃             ┗━━━━━━┛  ┗━━━━┛   こちらが         ↑       ↑  ↑ Windows 上での本流      ├───────┘  │     ↓          │ MS KANJI API    │ ┏━━━━━━━━━━━━━━┿━━━━━━━━━━┿━━━━━┓ ┃┏━━━━━━━━┓  ┏━┿━━━━━━━━━━┿━━━┓ ┃ ┃┃PROCESS TYPE IME┃  ┃┏━━━━━━┓ ┏━━━━━┓┃ ┃ ┃┗━━━━━━━━┛  ┃┃MSKANJI.EXE ┃ ┃WX2WIN.EXE┃┃ ┃ ┃   ↑↓        ┃┗━━━━━━┛ ┗━━━━━┛┃ ┃ ┃ ┏━━━┓      ┗━━━↑━━━ DEVICE TYPE IME ┛ ┃ ┃ ┃WINNSL┃──────────┘ (DOS上の FEP を Windows で┃ ┃ ┗━━━┛            使うために作られた仕組み)┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ IAE(Input Assist Editor) #前田さんのメモから移したので、どのような文脈で出たか忘れて #しまいました。 図2:WX の構造             ┏━━━━┓             ┃WX の UI┃             ┗━━━━┛                ↑                ↓   ┏━━━━━━┓ ┏━━━━━━┓ ┏━━━━━━┓   ┃WXライブラリ┃ ┃変換カーネル┃ ┃WXオプション┃   ┗━━━━━━┛ ┗━━━━━━┛ ┗━━━━━━┛ サーバー化は素直である。 #モジュール化ができていたので、サーバ形式への移行が楽だった…という #文脈だったように思う。 図 3: IMEの構造         ┏━━━━━━┓  ┏━━━━━┓         ┃入力表示 API┠──┨特殊な変換┃(オプション入力)         ┗━━┯━━━┛  ┗━━━━━┛            │            │     ┏━━━━━━┷━━━┓   逆変換 ローマ字┃ネットワーク・サーバ┃  ┏━━━━━━━━┓  変換 ┃  ┏━━━━━━┓┠──┨文節の多目的変換┃→類語・用例  学習 ┃  ┃変換カーネル┃┃  ┗━━━━━━━━┛  登録 ┃  ┗━━━┯━━┛┃     ┗━━━━━━┿━━━┛            │      ┌─────┼──────┐      │     │アクセス  │ ┏━━━━┷┓┏━━━┷━━┓┏━━┷━━┓             ┃国語辞書群┃┃ 付属語辞書 ┃┃ 辞 書 ┃ ┃単語・共起┃┃語尾・付属語┃┃(その他)┃ ┗━━━━━┛┗━━━━━━┛┗━━━━━┛           ↓ 補助用言・形式名詞、助詞・助動詞(よく使う慣用表現「に」「と」など)、 接辞の類の辞書をこれから流通させたい。それによって方言に対応するのは いかがか。文法辞書(接続辞書)の流通は、難しい。 ◎ディスカッション ○狩野@早稲田の質問(小山さんへ): 付属語と接続情報は一体のものだから、付属語のエントリだけを 流通させるのは難しいんじゃないか? 答え(小山さん): 全部は難しいかもしれないが一部(口語表現など)は可能ではないか。 狩野: 口語には文章語と対応するものもあり、そういうものは簡単に救える んじゃないか。 今さん: 付属語、文法などは次のセッションでやりましょう。 ○長門@sunソフトさんの質問 パネラーが他のパネルの意見をどう思ってるか。 桑理: 学習情報の交換 石曽根: 変換オブジェクトの分解 今: ユーザーインターフェースの独立、変換可能 小山: 付属語情報の流通 あたりが興味深かった。 各パネリストと司会の、他のパネリストへのコメント: ---桑理 石曽根: XIM Protocolが問題解決していないというのはショック 今: かんなはアーキテクチャ的には進んでる 小山: 興味がわいた ---小山 いい勉強になりました ---石曽根 エンジンはよく知らない。 小山、今: がんばってらっしゃるね ---今 石曽根: だいぶ手伝ったんですが... kinput2はkinputと比べると構造がよくなった 一方、Windowsは構造がよくわからない。 桑理: 辞書サーバーには期待している。学習情報を交換する より、みんなでひとつの辞書を使えばいい。 Wnn以外の人が本当に使える辞書サーバーになるのか。 → 今のところは無理でしょう。どうして? それ(使えない理由)は今から議論して深めましょう。 司会の太田さんの感想: 各社が独自の思惑と「売り」を持って、開発しているのはいいことだ。 メーカーから独立した形でkinput2が出てくるのもいい状況だ。 でも私はもう少し細かい単位のモジュールを組み合わせて使いたい。 辞書サーバー単体、UI lib単体で売ってほしい。 「アーキテクチャ再考」といいながら、説明だけで終っている。 ○松山@創夢さんの質問(桑理さんへ): 辞書サーバーの使い分け、 primary/secondaryサーバーによるバックアップ、 サーバー間の頻度情報の整合を取る方法は、どのようにしているか。 ---桑理 昔の変換サーバーを複数動かして情報を共有するための 辞書サーバーという考え方である。 複数のサーバを分散させて、相互に情報を取るための方法は まだ考えていない(他にも、誰も解決した人はいないらしい)。 ○今さんの質問(桑理さんへ): 辞書サーバは何を返すのか。辞書サーバの返す単語には、付属語も入るのか。 ---桑理: 自立語だけ ---今: 自立語の品詞だけ統一すれば使えるようになるのか。 ---桑理: 今の辞書サーバー 解析時 読み → 辞書内 index、品詞、頻度、共起関係 候補決定時、 辞書内 index → 漢字 確定時 学習情報の登録(頻度・共起関係、自動登録単語) 汎用化するには、 ・API(ライブラリ)の構造 ・品詞、頻度情報の標準化 ・共起関係の汎用化は可能か? あとは ・速度の問題(汎用化して遅くならないか) ・Wnnよりのプロトコルにして解決した点。  (Wnn が後ろから辞書引き・解析を行なうので、逆順の    読みを食わせるようにしている)  正順からも逆順からも返せるようにできるか? ○前田さん(リコー)の質問 品詞は各変換システムの文法に依存するが、どう解決するか? 答え(小山さん) 再分類を各社が行なう必要がある。 どこも橋本文法を元にしているから、難しいかも知れないけど 不可能ではないだろう。 ○長門さんの質問 文法文法と言う割には、みんな入力単位が小さいんじゃないか。 私の回りには単語単位入力の人が多くてびっくりしている。 (ここで参加者に「どれくらいの入力単位で変換キーを押しますか?」と  質問し、挙手させて数えてみた) 短い人: 文節単位くらい。13人くらい 長い人: 文単位くらい 21人くらい ---狩野: 使っているエンジンや環境によっても違うのでは? ---長門: 最初に使ったもの? ---狩野: システムに体が慣れていくものじゃないのか。 賢い変換を使っていると長文入力に傾くが、文節の切り方が 悪いシステムだと、誤変換を防ぐように短い入力に傾く。 ---太田: では使っている入力システムは? 狩野: 自宅 Canna 3.2、学校 Wnn 4.108 長門: SUN自社システム、ATOK on SUN ---太田: 昔のATOKは32文字までしか仮名が入らなかった。 そういうことが問題か? 長門: 希望の変換結果に早くヒットすることが大事だから、付属語 をつけない方が有利なのではないか。 ○狩野の質問 ローマ字かな変換を切り離すという話について: 自分でローマ字テーブルを書き直して交互打鍵ベースにしている。 新しく使う各システムごとにカスタマイズファイルを書き直している。  一つの定義ファイルで様々なシステムに与えられればいい。 ローマ字→仮名変換を他の部分から切り離すことの難しさはどうか? ---石曽根: できればうれしいけど結構難しい。 Wnnの変換では、ローマ字かな変換と制御キーのバインディン グテーブルが今はひとつになっている。 ローマ字かな変換と制御コマンドの分離が難しい --> 無理に分離すると機能が落ちる?? 入力モードに依存したキーの定義が難しい ---小山: 作ったけど、困る。テーブルを別にして参照するならいい が、ローマ字を入れたときに中間状態のエコーバーックができ ない。ローマ字入力中に英数字を入力しないとどうなるか。 ---小山: 決定性のない部分に放り込んでやればいいのでは? ---桜川: Wnnでは実現しているのでは? ---桑理: 実現しているが、後悔している。AI変換しようとしたとき、 どういう入力によって仮名になったかどうかが分からないから 困る。キーのアサインも困る。 ---今: ローマ字変換。DOSベースのものを見てて思うことのひとつ。 ローマ字文字に制限がある。例: ATOKだと必ず後ろに母音がな いといけない。TUT-Codeなんかを組み込もうと思うと苦労する。 ---前田: ローマ字ルールと制御キーとは切り離すべきではないのでは。 ●仮名漢字変換システムの変換効率の向上 パネリスト:長岡さん(オムロン)、小山さん、今さん ◎司会の太田さんによる用語の定義: 「変換効率」という言葉はあいまいで2つの意味がある。 ここではきっちり定義して使おう。 エンジン単体の性能(変換の一発的中率) 『変換精度』と呼ぶ システム全体の性能(誤った変換結果を、文節の切り直しや単語選択で直し、   正しい結果を得るまでのターンアラウンドタイム) 『変換効率』と呼ぶ。 ◎今さんの講演「かな漢字変換のしくみ」 一般論「変換ってどうやるの?」の解説。 「日本語ワードプロセッサーにおける自然言語処理」 情報処理 Vol.34, No.10, 1993.10 が分かりやすい。 文節 := [接頭語]自立語[接尾語][付属語]* 例: 会社では 学校文法では「取り」までを語幹と 休みを 見なすが、仮名漢字変換では 取りたくない 「取」だけを語幹とする。 付属語 - 自立しない単語。助詞とか     - 活用語の語尾も付属語と見なす。(上の例での「り」) ・最長一致法 文節をできるだけ長く取れるように区切っていく。 「空想的な おはなし」  ^^^^^^^^ 「思っていた とき」が、「思っていたと き」という 誤った分解になってしまう ・二文節最長一致法 二つめの文節までが一番長かったら、そこではじめて 一番目の文節をokにする。 最長一致法:「研究のも 句 敵は」 二文節最長:「研究の 目的は」 経験的に、単純で効果が高いことが知られている。 最初の方しか見なくていいので入力の長さに比例する時間で解析できる。 ・最尤一致法 評価値を元に判断。 特異な例として文節数最小法がある。 ・その他 細かい工夫(経験則を利用) 1字名詞は優先度を下げる 漢字熟語を連結 名詞に直接動詞はつきにくい 高度な方法 共起(AI変換) 格情報 ニューラルネット ◎小山さんの講演 ○変換精度とは 1. 単語が辞書にあって変換される(辞書の充実) 2. 単語が欲しい表記に変換される(接辞の分類、送りがな基準) 3. 正しい文節、わかち書きを行なう。 4. 共起情報を利用する。 5. 学習効果が上がる。誤変換を修正したら繰り返さない。 6. 修正範囲が限られている。誤変換の修正にひきずられて新しい 誤変換を出さない。 ○変換効率の向上策 ・複合漢字の連結パターン WX では最小コスト法を採用している。 文法とは関係ない漢字同士のくっつきやすさの情報も使っている。 □□+□□ と □□+□ の漢字列 ―― コスト低い。 ・連語 「熱いお茶」など。 (係り受け解析などの方法より)非常に効果が高い。 ・係り受け 医師が石を投げる (ヒト)が投げる (モノ)を投げる 複文でも成立。 太郎が 鳥が 鳴く 声を 聞いた。 「係り受けは交差しない」「主格は用言に二重に係らない」などの 性質により効率向上。 ・係り受け学習 ここではきものをぬぐ ここで・履物を・脱ぐ 「履物―脱ぐ」「着物―脱ぐ」が、共起辞書の中に 両方あるとき 順番を入れ換える。 片方のみのとき 新しく作り、優先度の先頭に置く。 両方無いとき 片方作る ・文節の拡張解釈 アスペクト 起動 手紙を 書き始める 継続 手紙を 書き続ける       終える 書いてある など。 ほか、終結、結果・状態、完了 ムード(確信、説明、意志、願望、依頼) 推量 出すらしい 〜 かもしれない 〜 はずだ 〜 ことになる 〜 わけだ など。 これらを一文節と見なすと、変換効率が向上することが多い。 ・これらの変換精度向上の方法の限界 辞書に無いと出ない。「エリツィン」など。 文語、方言、新表現は出ない。 ○ユーザによる変換効率向上策 1. 登録する。 2. 自動登録。 3. 連語の登録 4. 共起の登録。 5. 一部の付属語表現や接辞の登録 (存在しない表現も出てしまうことが多いので、諸刃の刃である) ○変換効率が高いとは? 1. 入力・表示が速い 2. 変換が速い 3. 入力・変換が容易。すぐ覚えられる。 4. 修正・選択が容易 5. 難読語の入力が容易(読み、部首、画数から入力できる) 6. 用例を表示 7. 類語を表示 8. 短文の変換 9. 固有分野の変更(住所入力ツールなど) ○今後 意味・文脈解析 漢字のゆれ、国語表記の入力統制 入力の切口としてマルチメディアの変換 入力手段の拡大 日本語解析―→自然言語理解 ●今さん:「『かんな』の変換について」 アルゴリズム: ・複数の自立語辞書から自立語をサーチ。 ・接続する付属語を複数の付属語辞書からサーチ。 ・読み長が一緒で最後尾の単語が同一の枝はマージ(一種の枝刈り) ・区切り情報をサーチ。例が登録されていれば採用(最長二文節より優先) ・最長二文節以外の枝をカット。 ・一文節目の自立語のキャッシュ内タイムスタンプをチェック。  (あれば最新のものを採用―Wnnの「今使ったよビット」に似ている)  古いのは自動で使われなくなる。 ・最優先辞書の最優先候補を出す。 ・一文節目の長さが決まったので、次の文節からまた繰り返し。 学習: ・区切りを学習する。 ・候補順(pernanent)・辞書優先順(volatile)を学習。  サーバの内に持っている。 ・タイムスタンプを押す。 ●長岡さん:「Wnnにおける仮名漢字変換効率の向上策」 Wnn 6 では、機能レベルでの改良を行なった。 #この先、木構造が少し乱れている部分があるのではないかと思う。 ○変換精度の向上策 - アルゴリズムの改良 - 関係(共起)辞書を使った変換 - 辞書頻度の見直し - 辞書の語彙を増やす - 文脈解析 日本、中国と来たら「韓国」 not 「勧告」 - 辞書の種類を増やす、分野切り換え機能 ・アルゴリズム(誤変換の原因を調べて、回避する) 文節長最長一致法の採用 青い木と行き->青息吐息 辞書内候補頻度の見直し 彼破格->彼は書く 付属語の接続情報の見直し 文法上は接続するが、日本語ではありえない物を削る。 関係(共起)辞書を使った変換 確定後も記憶 全文節に対して処理 ○学習による向上 区切り、関係学習 接頭語、接尾語学習 お願い/御願い、・・済み/・・すみ 未登録語自動登録 グループで登録語共有 オフライン学習 同一語削除、頻度微調整 変換精度向上には効果が少ない。 “シス総研”のような略語まで学習ができればいい。 ○ユーザによる向上 メーカの尻を叩く 明示的文節切り入力 SKK、松茸 ○評価法 文字一致率 ¥ 変換精度の評価基準 文節一致率 / 修正に要したキーストローク数 効率の評価基準 入力に必要な全キーストローク数 効率評価に最適 ↓ キーの重みづけ・最適操作の検討が必要(例えば、マウス操作はどう評価?) ○今後 変換効率、出来れば入力効率向上 文節切り指定入力のサポート 次候補をいかに速く選択 誤り訂正(うろ覚え、入力文字間違い) 手書き入力・音により入力/確認 入力モードの改善 ●ディスカッション 司会の太田さんの提案: 議論内容を 変換効率の評価方法 学習の表現、共有、再利用 の二点にしぼろう。 ★狩野: 評価方法について - キーの重みづけよりも、操作の重みづけ -> ターンアラウンドタイムの長さ。 文節の切り直しをすると時間がかかる。 -> 文節区切り かな漢字変換の内部構造としての文節と、 表示用の文節とを分けてほしい。 候補にルビを振ってもらう。 ---今: 文節区切りを情報として入れることは必要。 ユーザーインターフェースとしてどう実現するかが難しい。 -> 変換キーがスペースに割当てられているとは? -> 文節区切りでスペースをおしましょうという意味 文節を指定したいユーザーとしたくないユーザーがいる。 指定したくてしょうがない人はスペースを使えばいい。 ---狩野: ぼくは指定したくない方。 SKKは漢字とかなの切れ目を自分で指定する方式だが、あれは いや。区切りの情報を入れる間をおしんで音を入力したい。 「こと」と「事」の書き分けを行いたい。 「話したこと」動作 vs. 「話した事」内容 ---小山: 文法上の文節と表示上の文節は分けて考えていいと思う。 今は各メーカーが自分の文節はどうだということを表現してい る。ルビと漢字の対応が難しい。 ---狩野: 何が文節かをユーザーカスタマイズしたい。メーカーではな く自分で決めたい。 ★長門: 自動変換のものとアクション変換の比較 自動変換だと間違いがすぐわかるので直せる 一括変換だと、入力した表記の訂正がやりにくい。 ある文節だけ読みに戻したいのに、残り全部を戻してしまうシ ステムが多い。 ---小山: 文節長が変わると残りの解析がすべて無駄になる。悲しい出 来事。文節長の変更による再解析を全部はやらないで、関係し そうな部分だけをやる。 ---太田: 昔のシステムへのトラウマに対して解決された部分を各メー カーはアピールしていってほしい。 ★太田: 区切り学習の正体は何ですか。 ---長岡: Wnn4のころには適切に学習されていなかった。真面目にやり すぎてて、次回に反映されにくかった。文法情報としてではな く結果を覚える。 ---太田: もう一度同じのばしちぢめを見たくない。どうやってんの? ---桑理: Wnnは前後二文節を一文節の言葉として覚えます。 ---今: それはファイルに取っとくの? ---桑理: はい。 ---今: ATOKは昔メモリー上だけでそれをやっていた。しかし今はやっ ていない。長い文節がたくさんできてしまって、最長一致法に 対して不利になる。ATOKはそのため、volatileにしか覚えない ように工夫していたようだ。 ---桑理: 学習する条件を制限することによって、後の変換に悪影響 を残すようなものは残らないように工夫している。 ---小山: WXでは連文節で、前の文節と後ろの語幹の情報を学習辞書に 記録する。共起と文節学習の間でコンフリクトが起こることも ある。 ---今: タイムスタンプで実質的にできていた。あるバージョンからは、 前後2つの文節の読みをファイルに取っておく。 ★相馬@キヤノン 仕様書を外注さんに頼むと、かな漢字変換の選択の間違い。 オウムの影響か、「観察」が保護監察の監察になってしまう。 どうやったらそれを回避できるか。 かな漢字変換が自信のない候補には「自信がない」と申告して ほしい。赤く出るとか。ユーザーは「このかな漢は○○に強い」 というのが明確にわかる。 エンジン開発区は「うちのがバカだ」ってばれるからイヤ ---長岡: どこに自信があってどこにないのかの評価が難しい。 アルゴリズムによって決めたのるか頻度によったのかくらいは区別 がつく。 その他、時流の反映などの必要もあり難しい。 ---小山: 差別語、いみ語の方へ移ってしまう。 ---相馬: 入力者の文法能力に依存する。 ★藤枝@jaist 要望のたぐいが多いが、フリーのかな漢の変換効率を上げるこ とに日夜悩んでいる。ソースが出ているフリーのシステムなら、 自分でも直せる。フリーのものが出続けてほしい。フリーで使 わせてもらっている分フィードバックもしたい。フリーのもの をかしこくするために我々は何をするべきか。教えてほしい。 ---狩野: 性能としてかしこくなる他に、自分が理解できるシステムで あってほしい。そのためにソースを読みたい。 ---今: かんなの文法はちょっと勉強すればすぐわかる。誤変換に対し てどう直せばいいかという問題に対し、文法を直すことができ る。品詞分類が表示され、間違った接続がすぐわかる。 かな漢字変換の文法、品詞、接続などに対し、これが最終版だ というものが今はない。「文法なんて最近いじってないよ」な のか、「文法を日々いじってます」という人はどれくらいいま すか。 ---小山: 毎日いじってます。毎日出てきちゃうから。「飛んでいる」 ではなくて「飛んでる」とか。品詞が増えるとマトリクスの大 きさが変わったりする。 ---秋山@シャープ: 毎日いじっている。ユーザークレーム ---杉浦@管理工学: まつたけではほとんどさわっていない。若い人の中 には文法体系一気に変えようと人もいる。 ---今: まつたけはユーザーが文法をさわれるパイオニアですよね ---太田: あれはユーザーの解析によるものです。 ---大池@ブラザー: 細かいデータを少しずつ調整している。 ---井ノ上@digital UNIX: まったく手を入れていない。OSからの片手間 でいじるのは難しく、かな漢字メーカーにお願いしている。 ---長門@sun: さわりたいけど恐くてさわれない。 ---若松@ソニー: sj3の開発をしてます。フリーの方はさわっている。 学習のタイミングが効いてくる。こまめに手を入れている。 ---今: 長い門やっている方々は「ばっちり決まった文法」を持ってい るもんだと思っていたので、認識を新たにした。 ---藤枝: ぼくたちの素人仕事と同じようなことをしていると聞いてぼ くらの仕事は間違っていないと知った。文法は細分化に細分化 を重ねてしゅうしゅうがつかなくなっている。商用システムで そういうことが起こらないのは、基となる文法がしっかりして いるのではないか。 ---小山: いじっているのは、枯れてないからいじっているというより は、複合助詞などを考えるような方向へ行っている。 ---長岡: Wnnでは「契約」に対し「京八区」が出たことがある。数+数 助詞。文法的には正しいけど、間違っている。そういう部分を 工夫することで良くなっていくんではないか。 ---今: 品詞とはrowとcolumnかな成り、左接続性rowと右接続性column の対とで定義される、というモデルがある。 なってしまった --- --- r1c1 r2c2 なっちまった ----- r1c2 にすればいい。今はやっていない。 文法の話は非常に重要。あまり体系だった研究はされていない んじゃないか。国語学的な研究はあるが、それがすぐかな漢に 使えるものではない。抜けも多い。「かな漢字変換のための文 法学」みたいな分野が必要なんじゃないか。 -> もっと各システムの文法が見えるようになっている必要が あるんじゃないか。 ★前田 「人間は間違えるものである」という前提で、入力されたかな 列をうたがった変換エンジンというのはどう難しいだろうか。 例えば ATOK9 の「いっっぱつ変換」の修正のような。 ---小山: WXIIの「ゆらぎ(とうり、とおり→通り」はその初歩であろう。 しかし、どんどん進めていくとキケン極まりないと思う。 さじ加減ではないだろうか。 ★佐藤@東芝 辞書の学習をキーボードから入力しない方法でできないか。 WAISではテキストをどんどん食わしていけばインデックスがで きあがる。同様のアプローチはあるか。 ---太田: 変換済の文書を読んで学べということですよね。 ---さくらがわ@京大: Wnnコンソシアムではやりかけて途中の状態。逆 変換は同じアルゴリズムでできる。自然言語翻訳なんかをして いる人は同じことをやっているはず。 ---長岡: Wnnには漢字->かなの変換の機能があるので、技術的にはでき なくはないが、間違った解析の訂正ができない。単語の登録な らできる。 ---小山@アーツテック: 法律文書をたくさん通すことで法律辞書を作っ たりはできそうですね。 ---太田: 筒井やすたかを通した辞書なんてものがマニア受けするかも しれない。 ---小山@アーツ: そういうものを作ろうと思ったらプログラムできる材 料はあるか。 ---長岡: ある。訂正フィードバックのUIFが難しい。 ---今: かんなでは「最後にやったものが有効」であって頻度は見てい ないので、見ていない。統計情報を見るためにかんなを使うこ とは可能であろう。RKの返す形態素情報を使えばよい。 ---さくらがわ: Wnnのjserverの場合には返ってくる情報が不足してい る。サーバーをいじらないといけない。やってみると、「来る」 でも「きたる」と「くる」があってどうしようもない部分もあ る。それ以外の部分はよくできる。外国人向けに漢字かな交じ り->かな->ローマ字をやったことはある。 ---石曽根: ラフな統計情報だけでも面白い。fjの読み書きに最適な 辞書とか。 ★太田: その他課題で用意していた話題 o AI変換の得失と今後の展開 -> 変換精度がサチっているというのは本当か o 学習情報の流通について o かな漢字変換システムは特許や実用新案でしばられてユーザーイン ターフェースに限界があるらしい。真相如何? o 日本語以外の言語は? o AI変換について ---藤枝: 「絶対いらない人」として今さんが名乗りをあげなかったと いうことは、かんなにはいつかAI変換が入るのか? 入らないと したらぼくらは何ができるのか。共起情報はどうやって集めて いるんだろう。 ---安藤@マイクロソフト: Windows'95のためにAI変換を作った。約48万 件の共起情報が入っている(辞書が4メガ!)。ある大学の先生に 協力していただいて入手したデータにビジネスデータを加えた。 自動的に変換させて、誤変換を見るようなことをした。 ---相馬: 自然言語処理の研究の中で、言語学的にデータを集めている 先生がいる。そういう人に聞けばペーパーなんかが出ているは ずだろう。 ---長岡: 力づくでやるのも持ってくるのと2つある。力づくの方は本当 に文書を流して、その中から候補を出すようなことになる。あ る程度のプログラムを作ってフィルタリングするようなことは ある。 ★長門: 口語変換が弱い。フォーマルな文書の変換精度は高い。E-mail などのインフォーマルな文書では口語がぜひ必要。今後の展望 は? ---桑理: フリーなWnnでは関西弁の付属語辞書とオプションがあった。 ひとつの文法情報で両方やるのは無理。Wnn6では逆に口語を切っ た。今後、オプションとしてサポートすることを考えていく。 ---今: かんなの付属語辞書には口語のものもある。辞書をマウントし て使うということができるので、使えばできる。デフォルト辞 書に全くない品詞が出てきてしまうので、そういうものはこぼ れていく。「なっちまった」など--->「なってしまった」の置 き換えとするのでない限り、品詞を増やさないといけない。 かんな4.xで辞書のフォーマットが変わるときにはなんとかし たい。 ---秋山: うちは口語にはちょっと弱い。付属語テーブルを取り換える こうな仕組を検討している。 ---杉浦: 口語変換は全然だめ。「できてほしい」という声は強い。や りたいとは思うが、文法が変わってしまう部分があるので難し い。口語変換ぽくなったら自動切換なんてアイディアはある。 ---若松: エンジンはやっていないので個人的な意見ですが、同じ単語 でも地方によって意味が違うようなことはある。辞書を切り換 えるようなことや、関西べん用にコンパイルするようなことが 必要になるんじゃないだろうか。 ---長門: 変換精度は、技術的文書やビジネス文書ではかなりいいのに、 一般的な文書ではまだまだ弱いと思います。 ---狩野: 口語の場合にはコーパス(用例集)を集めるのが難しいのでは ないでしょうか。 ---今: 言われたことをやる。 ---相馬: 口語のサンプルデータは、電子化されていないので打ち込む ことからはじめた。少年ジャンプなどまんがを大量に買ってき て入力した。効果的だったのは少年ジャンプ/キキ/ララなど低 年代層のものがいいようだ。成年男性向のモーニングなどはま た別である。論文に書けませんでした。 ★前田: 誤入力を前提としたシステムの難しさは何か。 ---石曽根: AIローマ字かな変換は辞書とか必要になって難しくなり はしないか。前処理が難しくなりそう。 ---今: JUSTのJAC(いっっぱつ、じゅううりょく)みたいな技術はすばら しい。「とうる」を「通る」とするのは辞書で吸収しているん じゃないか。ら抜き言葉は言語が生き物であることの証明であ ろう。西山さんのおっしゃるような明らかな間違いを直すのは 必要では。 ---桑理: 間違いのパターンを限定しないで広げていくと、変換速度 に大きな影響があるだろう。組合せが級数的に増えていくから。 ---石曽根: コンピューターが1000倍速くなったらできるのかなあ。 ---桑理: うん、そうなったらやりたいねえ。 ---今: 「T-Coderは私のタイプは間違っていない」と信じてると思って ました。今は誤変換が出ることで私は間違ってるということが よくわかるという意味はある。 ---長岡: 千倍速くないんでどうしたいかというと、打つ速度と同じ速 度で間違いのフィードバックをかける方法はあるんじゃないか。 ---若松: わざと「っ」を効果として入れたいときには邪魔。 ---前田: T-Codeでは間違いはすべて自分の責任。パイプラインではフィー ドバックは邪魔かもしれない。ユーザーは間違う。だから訂正 したい。文節を2文字長くしたいと思ってもUIFに1文字のばす 機能しか用意されていないと無駄がある。 ★太田: さいごに一言。 ---長岡: 何が必要なのか聞けたは面白かった。もっとたくさんの人と 話をしたかった。 ---石曽根: 最初のパネルは静かだったんだけど、その後もり上がっ て良かったと思います。 ---今: 話し足りなかった。今回、1日というのは足りなかった。次回は ぜひ1泊というのを考えてみたい。 ---桑理: フリーから商品版に移ったとこですが、最近フリーという 考え方を忘れていました。フリーというものを思い出しました。 ---太田: じょうずとは反対の司会でしたが、どうも。司会はストレス たまりますね。次回はぜひ質問をする側に回りたいと思います。 部屋をセットアップするようなので、終ったところで一担荷物 を持って外に出ていただきます。 以上