ATOK15 for Mac OS X の使用感

[Junn Ohta]

fj.comp.input-methodにもクロスポストします。

fj.sys.macの記事<koabe-937E54....@binarykiller.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。
> また、評価の着眼点が分かると、次は評価方法はどうなって
> いるのだろうと興味が湧いてきました。

文節区切り誤りと同音語選択誤りについては、学習辞書
を捨てて、初期状態からいろいろな文章を変換してみて
その結果に含まれる誤りをカウントすることになります。
また学習については、入力を修正して正解の文章にして
から確定し、もういちど同じ文章を入力して正解の文章
が得られるかどうかを確認すればよいわけです。

同音語選択誤りについては1件ごとに1ずつカウントして
いけばよいのですが、文節区切り誤りについてはどうカ
ウントするか考慮の余地があります。たとえば変換結果
に複数の誤りがあったとしても、先頭文節の区切りを修
正したら残りもすべて正しく区切り直されることもある
わけですから。私が採用したのは、正解に達するまでに
必要だった文節区切り直し回数を1回ごとに1とカウント
するという方法です。

正解が得られなかったときにどれだけの操作が必要だっ
たかという観点に立てば、同音語選択誤りについても正
解に達するまでに何回のキー操作が必要だったかで重み
をつける方法もありますし、文節区切りについても何文
字分ずれていたかで重みをつける方法があります。また、
同音語選択誤りよりも文節区切り誤りのほうが修正に頭
を使うので、ペナルティーをより強くしたいと感じるか
もしれません。とはいえ、そこまで細かく点数化しても
読者に対する説得力につながるとは限りませんし、かえ
って客観性を失うことにもなります。

上記の方法(同音語選択誤りは1件で1カウント、文節区
切り誤りは1回の修正で1カウント)でWindows上のATOK13
とIME2000を比較した結果が手もとにあるので書いてお
きます。テストに使用した文章の文字数は概算で3万7千
字、1回の変換は20～30字程度の節または完全な文です。
文章の種類は随筆や雑誌記事、プレスリリースなど硬い
ものから軟らかいものまで含みます。

ATOK13: 文節区切り誤り 121, 同音語選択誤り 154
IME2000: 文節区切り誤り 62, 同音語選択誤り 199

これをみるとわかるように、ATOKのほうが格段に文節区
切り誤りが多いですね。具体的な誤変換例(IME2000では
正解だったもの)をいくつか挙げておきます。

正解 ATOK13の誤変換
いくらか/手が/出やすくなった いくら/糧が/でやすくなった
少し/似た/感触で 少しに/多感色で
打ち/間違えを/防ぐ 内町/替えを/防ぐ
登場/以降/毎年/内容が/改訂 登場/憩うまい/年/内容が/改訂
もし/書けた/人が/いたとすれば もしか/桁/費とが/いたとすれば
一般/社会人として 一般車か/偉人として
まだ/出す/前から まだだ/須磨/絵から
これから/始めたい/方も これから/始めた/伊方も

> 私の友人も、厳密に比較した訳ではないのでしょうが、
> ATOKは文節の区切りがおかしいと言っていました。
> 辞書ひとつ取ってもATOKってかなり研究して作っている
> という記事を見かけるので、意外だという気がしています。

文節は自立語と活用語尾、その後に続く助詞の並びなど
で構成されるわけですが、どういう自立語や活用語尾に
どういう助詞の並びが続く可能性があるかは内部にもっ
ている文法テーブルをみて検討します。そのテーブルに
ない並びは存在しないものとして候補から外されてしま
うわけです。また複数の解釈がある場合は、いずれの解
釈がよりもっともらしいかという評価値を求めて、最善
の結果を変換結果として提示することになります。この
あたりは微妙な匙加減が必要なので、各社とも膨大なテ
ストと経験則によって評価値要素を決めているわけです。

また、大きく文節に区切ったときにどの文節区切りがよ
り適切かを判定するためには2文節最長一致法、3文節最
長一致法、接続コスト最小法などのアルゴリズムが使わ
れているのですが、ATOKの採用している2文節最長一致
法では、先頭の2文節の合計が最長であるもの(合計が同
じなら後の文節がより長いもの)の評価値が高くなるよ
うになっています。

これらを考慮したうえで上の誤変換例をみてみると、正
しい文節区切りを得るのはそう簡単なことではないとい
うことが理解できるのではないでしょうか。

> > 私はATOKの変換の味がわりと好きなので、Mac上で選ぶ
> > としたら変換精度にかかわらずATOKにするかもしれませ
> > んが、他人にすすめるならMacVJE-Deltaにするかなあ。
> これは、どのような理由からなのでしょうか。
> ちなみに、windowsだったらどうなるのでしょうか。

MacVJE-Deltaを他人にすすめるのは、VJE-Deltaの変換
エンジンのほうがバランスがとれていて、破綻も少なく
より万人向きだろうと思うからです。学習のバランスも
VJE-Deltaのほうがまともそうです。Windowsでも他人に
すすめるならVJE-Deltaです。

> > キー割り当て、変更しなはれ。(天の声)
> いや、キー割り当てを変更しても、結局ATOKは、同音語パレット
> （候補ウインドウ）が私の感覚からすると違和感があるから、
> だめなんですよ。

なるほど。

> それと、いちどOAK風にしてみたのですが、［無変換］［変換］
> キーがキーボードにないから、だめでした。［無変換］という
> キーは素晴らしかったんだけどなー。

OAKの操作はほかの製品とはかなり方向性が異なるもの
でしたね。かなを入力してから、漢字に変換したければ
[変換]、かなのままにしておきたければ[無変換]を必ず
押すというリズミカルな操作を要求するものでした。

そのかわり[確定]キーがなく、日本語入力はオンだけど
未確定の文字はない、という状態にすることができない
ことに私は閉口しました。viというエディターで「入力
を確定してESCを押すとエディターの入力モードが終了
し、日本語入力もオフになる」という操作がプログラム
側で実現できなかったからです。

> これだけ日本語に関心が高いのに、コンピュータで日本語を
> 入力する基のところがどうだっていいということなのかなぁ。
> どれを選んでもそれなりに満足を覚えるくらい技術が進んだ、
> ということなのかも知れませんが。

そうなんでしょう。

> キーボードとかディスプレイと並んで、かなり重要なことだと
> 思うのに、このあたりのところって案外ないがしろにされている
> ような気がしています。

ないがしろにしているのは読者自身です。メディアの側
でも啓蒙活動はしてきたのですが、ライターや編集者が
頑張っても読者から反応がないわけで、重要であるとい
われてもいかんともしがたいです。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp

[ABE Keisuke]

koabe＠佐倉です。

丁寧に日本語入力ソフトの評価方法をご説明いただきありがとう
ございました。

こうやって評価方法が明示されると（さらには、評価に使用した
文章または語が明示されると）追試が出来るし、説得力がある記事
になると思うのに、そういう記事が 評価されるとは限らないん
でしょうね。
いまなら、必ずしも細かい評価方法を雑誌の記事や雑誌中の注釈に
記載する必要はなく、Webに置いておくとか方法はあると
思うのに。でも、そこまで読者に求められていないんだろうな、
きっと。

In article <aj7s56$kh4$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 同音語選択誤りについては1件ごとに1ずつカウントして
> いけばよいのですが、文節区切り誤りについてはどうカ
> ウントするか考慮の余地があります。たとえば変換結果
> に複数の誤りがあったとしても、先頭文節の区切りを修
> 正したら残りもすべて正しく区切り直されることもある
> わけですから。

先頭文節の区切りを直すと、ぱらぱらーっと残りも正しく
なるのはけっこう気持ちよかったりします。

> 正解が得られなかったときにどれだけの操作が必要だっ
> たかという観点に立てば、同音語選択誤りについても正
> 解に達するまでに何回のキー操作が必要だったかで重み
> をつける方法もありますし、文節区切りについても何文
> 字分ずれていたかで重みをつける方法があります。

たぶん、このあたりは、なぜそういう評価をしたのか
説明がつけばいいのでしょうね。
つまり、さきほどの「先頭の区切りを修正したら残りもすべて
正しく区切り直され」るのであれば、1回の訂正で済むわけで、
そこを評価したということなのだと理解しました。

> 同音語選択誤りよりも文節区切り誤りのほうが修正に頭
> を使うので、ペナルティーをより強くしたいと感じるか
> もしれません。
ここは、結果が数値で示されていて、係数を操作することに
よって独自に計算し直すことが出来ればそんなに問題がない
ような気がします。

そして、

> ATOK13: 文節区切り誤り 121, 同音語選択誤り 154
> IME2000: 文節区切り誤り 62, 同音語選択誤り 199

こうやって説明を受けたうえで、数値で示されると、一つの指標
として、なるほどと説得力があると感じます。
これだと、「たまたまそういう結果になったんじゃないの」とか、
「印象に基づくものじゃないの」という反論がしづらいです。

> 正解 ATOK13の誤変換
> 少し/似た/感触で 少しに/多感色で
＃多感色って、どんな色なんだろう？
＃レモン色かな。水色かな。それとも七色？

> れているのですが、ATOKの採用している2文節最長一致
> 法では、先頭の2文節の合計が最長であるもの(合計が同
> じなら後の文節がより長いもの)の評価値が高くなるよ
> うになっています。

日本語のこのような解析についてまったく知識がないのですが、
2文節最長一致法というのは、日本語が、1文の中で前の方にある
文節が長い傾向があるというという特徴を利用したものなの
でしょうか。いや、実際に前の方が長いのかどうか調べた訳では
ないのですが、本多勝一という人が、分かりやすい文を書くには
長い節や語を前に持っていった方がいいというようなことを
書いていたと記憶しているので、そういうことなのかなと思った
次第です。

また、もうひとつ知識がなくて知りたいと思っていたこと
なんですが、こういったコンピュータでの日本語利用のための
各種解析のために、現代日本語文法学（論？）というのは
どの程度かかわり合いがあるものなのでしょうか。

お互いにばらばらに研究をしているのかな。

> MacVJE-Deltaを他人にすすめるのは、VJE-Deltaの変換
> エンジンのほうがバランスがとれていて、破綻も少なく
> より万人向きだろうと思うからです。学習のバランスも
> VJE-Deltaのほうがまともそうです。Windowsでも他人に
> すすめるならVJE-Deltaです。

不思議ですね。それなのに、どうしてATOKの方が一般的に
使われているんでしょう。
他の分野でも、どうしてこれがという製品・商品が売れている
例がありますが（それは、私がなぜかマイナーな製品を選び
がちだからかも知れないけど）、不思議だなー。

> OAKの操作はほかの製品とはかなり方向性が異なるもの
> でしたね。かなを入力してから、漢字に変換したければ
> [変換]、かなのままにしておきたければ[無変換]を必ず
> 押すというリズミカルな操作を要求するものでした。

OAKと富士通製のキーボードと組み合わせて使う、つまり、
入力デバイスと入力ソフトが一体となってひとつの操作体系を
提供している点で、いま思い出すと、良く考えているなと
感じます。

> そのかわり[確定]キーがなく、日本語入力はオンだけど
> 未確定の文字はない、という状態にすることができない
> ことに私は閉口しました。viというエディターで「入力
> を確定してESCを押すとエディターの入力モードが終了
> し、日本語入力もオフになる」という操作がプログラム
> 側で実現できなかったからです。

あらら。確定しないでいいというのはOAKの特徴だったんですが、
害もあったんですね。

> ないがしろにしているのは読者自身です。メディアの側
> でも啓蒙活動はしてきたのですが、ライターや編集者が
> 頑張っても読者から反応がないわけで、重要であるとい
> われてもいかんともしがたいです。

ごめんなさい。これは読者というか、心あるライターや編集者
（とユーザー）以外の人に対して、ないがしろにしていると
いう感想のつもりでした。

でも、「机の上で長時間作業するにもノートパソコンがいい！」
という記事もあったりするのも確かで。いちいちデータをあっち
こっち動かすのは面倒というもの分かるけど、作業するにあたって
健康に及ぼす影響とか、考えているのかなと疑問に思っていたり
します。まあ、これはちょっと話がそれてしまいました。

--
阿部圭介　(ABE Keisuke)
ko...@mbp.sphere.ne.jp (main)
ko...@catv296.ne.jp (sub)
jh1...@jarl.com

-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-E40E0D....@binarykiller.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> こうやって評価方法が明示されると（さらには、評価に使用した
> 文章または語が明示されると）追試が出来るし、説得力がある記事
> になると思うのに、そういう記事が 評価されるとは限らないん
> でしょうね。

ライターや編集者が「うーむこれは力の入ったいい記事
だ。説得力も文句なしだぞ」と思っていても、読者から
の反響もほとんどなく、もちろんソフトの売り上げにも
まったく影響がなかったりするわけです。

くさかべさんがあれだけ長いあいだ(もう20年?)
やーいatok
とか
ふつーvje
とか書いても大勢に影響がなかったのと同じですね。:-)

> > 同音語選択誤りよりも文節区切り誤りのほうが修正に頭
> > を使うので、ペナルティーをより強くしたいと感じるか
> > もしれません。
> ここは、結果が数値で示されていて、係数を操作することに
> よって独自に計算し直すことが出来ればそんなに問題がない
> ような気がします。

それは先に示したように同音語選択誤りと文節区切り誤
りの件数を個別に示しているわけですから、ちゃんと知
りたい読者は自分で計算できるわけです。ライター側が
あえて係数を出してもあまり役には立たないだろうとい
うことです。

> こうやって説明を受けたうえで、数値で示されると、一つの指標
> として、なるほどと説得力があると感じます。
> これだと、「たまたまそういう結果になったんじゃないの」とか、
> 「印象に基づくものじゃないの」という反論がしづらいです。

でもメーカーが変換テストに使っている文章の量と比較
すると2～3桁少ないはずです。だからこれだけ数値化さ
れているようにみえても、この結果はやはり感覚的なも
のにすぎない。文章の種類にしてももっといくらでもあ
るはずですからね。

> 日本語のこのような解析についてまったく知識がないのですが、
> 2文節最長一致法というのは、日本語が、1文の中で前の方にある
> 文節が長い傾向があるというという特徴を利用したものなの
> でしょうか。

それは関係ないです。日本語文を先頭から順に文節に区
切ろうとするとき、文法的に正しいと考えられる候補が
いくつか出てくるわけですが、そのうち先頭2文節の長
さの和がもっとも長いものを正しいとみなし、次に先頭
の1文節を取り除いた残りについて同じ操作を繰り返し
て最終的に文全体を文節の並びに分解する方法です。

たとえば
にほんごのこのようなかいせきについてまったく...
という読みを変換するとき、
日本語の/この世/うなかいせきについてまったく...
日本語の/このような/かいせきについてまったく...
では後者が正しいとみなし、先頭の「日本語の」を変換
済み候補として取り除きます。以後同様に
このような/解析に/ついてまったく...
解析に/ついて/まったくちしきが...
ついて/まったく/ちしきがないのですが...
まったく/知識が/ないのですが
のように分解を進め、最終的に
日本語の/このような/解析に/ついて/まったく/知識が/ないのですが
を得るわけです。

もちろんすべての文章がこんなに簡単に分解できるわけ
ではなくて、どういう助詞の並びをより「それらしい」
と評価するかとか、自立語の並び(複合語)と助詞による
接続のどちらを優先するかとか、複雑微妙なさまざまな
要素があります。

たとえば自分でプログラムを書くとして、
一般/社会人として
一般車か/偉人として
のどちらが適切か正しく評価するプログラムをすぐに書
けますか? またそのプログラムで類似の他の文章を受け
取ったときも適切な区切りを得られるでしょうか? そう
考えると日本語の解析がそれほど簡単なものではないこ
とがわかるでしょう。

> また、もうひとつ知識がなくて知りたいと思っていたこと
> なんですが、こういったコンピュータでの日本語利用のための
> 各種解析のために、現代日本語文法学（論？）というのは
> どの程度かかわり合いがあるものなのでしょうか。

いろいろな日本語入力プログラムの開発者が話している
ことですが、学校文法を含めていわゆる国文法として発
表されている研究成果は役に立たないそうです。もちろ
んおおまかなところはどの開発者も既存の研究成果を利
用するわけですが、細かいところになると手探りでやる
しかないと。

> 不思議ですね。それなのに、どうしてATOKの方が一般的に
> 使われているんでしょう。

売れているものを買う、知名度の高いものを買う、知り
合いの誰かが使っているから買うというユーザーがかな
りの部分を占めているのも原因のひとつでしょうし、そ
ういうユーザーにおもねるメディアがあるのも原因のひ
とつでしょう。しかも「買ってみたらあまりにひどくて
使いものにならなかった」という感想をもつのは相当な
ヘビーユーザーぐらいのもので、そういう人は多くあり
ませんし、そういう人は上記のような理由で買ったりし
ないでしょうから、売れ行きを落とす要因にもあまりな
らないわけです。

> OAKと富士通製のキーボードと組み合わせて使う、つまり、
> 入力デバイスと入力ソフトが一体となってひとつの操作体系を
> 提供している点で、いま思い出すと、良く考えているなと
> 感じます。

日本語だけを連続して入力する手段としては、オアシス
の日本語入力は優れていたと思うのですけどね。そのか
わり、ほかのアプリケーションと連係させるためにさま
ざまな入力を切り替えたりするのは不得手だったのでは
ないかと思います。

[Yoshihito TAKANO]

高野ともうします。

Junn Ohta wrote:
>
> 同音語選択誤りについては1件ごとに1ずつカウントして
> いけばよいのですが、文節区切り誤りについてはどうカ
> ウントするか考慮の余地があります。たとえば変換結果
> に複数の誤りがあったとしても、先頭文節の区切りを修
> 正したら残りもすべて正しく区切り直されることもある
> わけですから。私が採用したのは、正解に達するまでに
> 必要だった文節区切り直し回数を1回ごとに1とカウント
> するという方法です。

後ろの方の文節区切りが間違っていると、注目文節をそこまで動かさないといけ
ないので、結構面倒なんですよね。
これに懲りた人はしょっちゅう変換キーを押す入力スタイルになったりするわけ
ですが、そうすると input-method の評価も変わったりします。

> また、大きく文節に区切ったときにどの文節区切りがよ
> り適切かを判定するためには2文節最長一致法、3文節最
> 長一致法、接続コスト最小法などのアルゴリズムが使わ
> れているのですが、ATOKの採用している2文節最長一致
> 法では、先頭の2文節の合計が最長であるもの(合計が同
> じなら後の文節がより長いもの)の評価値が高くなるよ
> うになっています。

VJE は３文節最長一致法、 WX は最小コスト法でしたね（この文章は WX を使っ
て書いているのですが、“最小コスト法”がデフォルトで登録されていて一発変
換したので、笑ってしまいました）。

もっとも、基本となる２文節最長一致法にしても、どうして最長一致する候補が
もっともらしいといえるのか？と聞かれると…。
…？？？ (^_^;
--
Yoshihito TAKANO
mailto:yota...@ty2.fitweb.or.jp

[Yoshihito TAKANO]

高野ともうします。

Junn Ohta wrote:
>
> > 不思議ですね。それなのに、どうしてATOKの方が一般的に
> > 使われているんでしょう。
>
> 売れているものを買う、知名度の高いものを買う、知り
> 合いの誰かが使っているから買うというユーザーがかな
> りの部分を占めているのも原因のひとつでしょうし、そ
> ういうユーザーにおもねるメディアがあるのも原因のひ
> とつでしょう。しかも「買ってみたらあまりにひどくて
> 使いものにならなかった」という感想をもつのは相当な
> ヘビーユーザーぐらいのもので、そういう人は多くあり
> ませんし、そういう人は上記のような理由で買ったりし
> ないでしょうから、売れ行きを落とす要因にもあまりな
> らないわけです。

こと“ことえり”に関しては、“あまりにひどくて使いものにならなかった”と
思った人は過去結構いたと思いますが…。 (^_^;

input method の場合、何かにバンドルされて販売されることも多く、必ずしも
input method 自体の能力でシェアを切り開いてきたわけではないように思いま
す。

[Yoshihito TAKANO]

高野ともうします。

ABE Keisuke wrote:
>
> こうやって評価方法が明示されると（さらには、評価に使用した
> 文章または語が明示されると）追試が出来るし、説得力がある記事
> になると思うのに、そういう記事が 評価されるとは限らないん
> でしょうね。
> いまなら、必ずしも細かい評価方法を雑誌の記事や雑誌中の注釈に
> 記載する必要はなく、Webに置いておくとか方法はあると
> 思うのに。でも、そこまで読者に求められていないんだろうな、
> きっと。

Web 掲示板なんかでやってみれば、 input method マニアが集まってくるかもし
れませんよ。
雑誌では商業的に四苦八苦していたことが掲示板では大盛況なんて例はあります
から。

> > MacVJE-Deltaを他人にすすめるのは、VJE-Deltaの変換
> > エンジンのほうがバランスがとれていて、破綻も少なく
> > より万人向きだろうと思うからです。学習のバランスも
> > VJE-Deltaのほうがまともそうです。Windowsでも他人に
> > すすめるならVJE-Deltaです。
>
> 不思議ですね。それなのに、どうしてATOKの方が一般的に
> 使われているんでしょう。
> 他の分野でも、どうしてこれがという製品・商品が売れている
> 例がありますが（それは、私がなぜかマイナーな製品を選び
> がちだからかも知れないけど）、不思議だなー。

VJE より ATOK の方がシェアが高いということであれば、昔、一太郎という製品
が流行ったからでしょう（ Mac で流行ったという話は聞いたことがありません
が）。
しかし、 Mac では ATOK より EGBRIDGE のシェアが高いという話を聞いたこと
がありますが、最近はどうなんでしょうか。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5B7DE9...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> 後ろの方の文節区切りが間違っていると、注目文節をそこまで動かさないといけ
> ないので、結構面倒なんですよね。
> これに懲りた人はしょっちゅう変換キーを押す入力スタイルになったりするわけ
> ですが、そうすると input-method の評価も変わったりします。

そうですね。

かつてのATOK(MS-DOS版のATOK7まで)では文節区切りの
変更は先頭文節についてしかできなくて、それ以前に注
目文節の移動という操作がそもそも用意されていません
でした。しかも一度に入力できる読みは36文字までとい
う制限がありましたし、ATOK使いには「しょっちゅう変
換キーを押す入力スタイル」以外の選択肢をはなかった
わけです。それゆえ文節区切りの精度について不満を感
じることも少なかったと。

同時期にMS-DOS版のEGBridgeは500文字の一括入力・変
換が可能でしたし、いったん変換操作を行ったあとで次
の読みを入力しても以前の変換結果が自動的に確定しな
いという仕様でした。つまりEGBridgeは未確定文字列を
可能なかぎり残しておき、ユーザーがあとから編集でき
ることを主眼として開発されていたということ。

ATOKもEGBRIDGEもそれ以後ずいぶん進化してきましたし、
操作性についてはどの会社の製品もずいぶん似てきては
いるのですが、変換のクセや細かい操作性といったもの
は当時からそれほど大きく変わったわけではないですね。
そういった日本語入力プログラムの性格というか設計思
想というか、それをユーザーはもっと知るべきだし、そ
れを考慮して選んだほうがいいのではないかと思うので
した。

> VJE は３文節最長一致法、 WX は最小コスト法でしたね

VJEが3文節最長一致法になったのはVJE-Deltaからだっ
たと思います。名前からも想像できるように、アルゴリ
ズムとしては2文節最長一致法の自然な拡張でしょうね。

3文節最長一致法を採用したのは、2文節最長一致法では
どうしても正しく変換できない場合があるのをどうにか
するためではないかと思いますが、メモリーが潤沢に使
えるようになったからこそ実現できたわけですね。まあ
いずれにしても文節ごとに変換してしまうようなユーザ
ーにはメリットがないと。:-)

WXシリーズは当初のWXから最小コスト法を採用してまし
た。この方法はぴたりと決まるとかなり複雑な文章もき
れいに変換できて美しいのですが、重み付けの匙加減が
微妙でむずかしそうです。ある文章を正しく変換できる
ようにパラメーターを変更すると別の文章が正しく変換
できなくなったりするわけで、変換精度を向上させるた
めには職人芸が必要でしょう。ほかのメーカーが採用し
ていない(らしい)のはそのためかも。

> もっとも、基本となる２文節最長一致法にしても、どうして最長一致する候補が
> もっともらしいといえるのか？と聞かれると…。
> …？？？ (^_^;

それは単なる経験則だそうです。

読みとなるテキストについて辞書から自立語を探し、そ
の語に続く可能性のある活用語尾や助詞をどんどんつな
げてゆく、それがだめになったら次の自立語を探し、前
の句と文法的に接続できるものだけを残す、という作業
を行うわけですが、結果として得られる文節区切り候補
をいくつか検討すると、たいていの場合、正しい候補は
最初の2文節の長さの和がいちばん長いものであること
が観察されるということですね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5B88D2...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> こと“ことえり”に関しては、“あまりにひどくて使いものにならなかった”と
> 思った人は過去結構いたと思いますが…。 (^_^;

それはPC-9801シリーズについてきたNEC純正のかな漢字
変換についてもいえることです。もっともこちらの場合
は変換精度が格段に劣っていたのではなくて、操作性が
とんでもなくひどかったというひとことに尽きるのです
けどね。まともになったのはMS-DOS3.3CのAIかな漢字変
換以降でした。

> input method の場合、何かにバンドルされて販売されることも多く、必ずしも
> input method 自体の能力でシェアを切り開いてきたわけではないように思いま
> す。

おっしゃるとおり。

MS-DOS時代のサードパーティー製品の日本語入力プログ
ラムは、たいていワープロソフトにバンドルされていた
ものです。ATOKしかり松茸しかり、FIXERしかりKatana
しかり。

例外はVJEで、これは最初から単体製品として販売され
ていました。とはいえそれだけでは商品として成立しな
かったので、さまざまな他社アプリケーションにバンド
ルしてもらっていましたけどね。どんな環境で使われる
かわからないこともあって、VJEは最初からほかのアプ
リケーションの邪魔をしないようにできるだけ行儀のよ
いふるまいをするように作られてました。そのあたりが
ATOKなどとは大きく違うところ、でしょうか。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5B8A62...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> Web 掲示板なんかでやってみれば、 input method マニアが集まってくるかもし
> れませんよ。
> 雑誌では商業的に四苦八苦していたことが掲示板では大盛況なんて例はあります
> から。

そうなんでしょうね。誰かページを作ってくれれば参加
するのにやぶさかではないのですが、私自身はそういう
ものを管理するのはめんどうなのでイヤです。(^^;

> VJE より ATOK の方がシェアが高いということであれば、昔、一太郎という製品
> が流行ったからでしょう（ Mac で流行ったという話は聞いたことがありません
> が）。

そうですね。あと一太郎が当初からMS-DOSベースで、し
かも早い時期からコピープロテクトを外していたのでコ
ピーユーザーがきわめて多かったからだという話も聞き
ます。コピーユーザーそのものは売り上げを減らす元凶
ですが、圧倒的なシェアが得られるのならそれを上回る
メリットがあるわけで、最初からそれを狙っていたので
はないかというといううがった意見もありました。

VJEはキラーアプリをもてなかったのが最大の敗因かな。
それでもUNIXワークステーション用とか組み込み用途と
かでは現在でもそれなりのシェアがあるのではないかと
思っていますが。

> しかし、 Mac では ATOK より EGBRIDGE のシェアが高いという話を聞いたこと
> がありますが、最近はどうなんでしょうか。

どうなんでしょうね。EGBRIDGEはWindowsとMacの両方に
製品を出しているメーカーの中で唯一Macを優先してい
るメーカーです。それなりのシェアがないとやっていら
れないでしょう。

[Kusakabe Youichi]

In article <aj8rn3$26$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp (Junn

Ohta) wrote:
> 売れているものを買う、知名度の高いものを買う、知り
> 合いの誰かが使っているから買うというユーザーがかな
> りの部分を占めているのも原因のひとつでしょうし、そ
> ういうユーザーにおもねるメディアがあるのも原因のひ
> とつでしょう。しかも「買ってみたらあまりにひどくて
> 使いものにならなかった」という感想をもつのは相当な
> ヘビーユーザーぐらいのもので、そういう人は多くあり
> ませんし、そういう人は上記のような理由で買ったりし
> ないでしょうから、売れ行きを落とす要因にもあまりな
> らないわけです。

ちょっとまえまではそれがあったみたいですね。
でも、Windows用に関して、最近はユーザー層が広がったせいか
不景気のせいか「ついてきたおまけ」をそのまま使うひとの
割合がかなり高いみたいです。

> とか書いても大勢に影響がなかったのと同じですね。:-)

まあ、「そうでなかった場合」を試せないので、
なんともいえないのではないかと。

# ここ一週間で12人に改宗させましたし;)

ヘ_ヘ ____________________________
ミ・・ ミ vo...@merope.pleiades.or.jp
( ° )～ 日下部陽一
‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾

[Kusakabe Youichi]

In article <ajgnmo$da4$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp

(Junn Ohta) wrote:
> かつてのATOK(MS-DOS版のATOK7まで)では文節区切りの
> 変更は先頭文節についてしかできなくて、それ以前に注
> 目文節の移動という操作がそもそも用意されていません
> でした。しかも一度に入力できる読みは36文字までとい
> う制限がありましたし、

あと、1単語の読みが12文字までっていう制限が
最初のころありませんでしたっけ?

あと、1「文字」に対応する読みが5文字以上できないってのが
あったのはATOKじゃなかったかなあ。(松茸だったかなあ)

[ABE Keisuke]

koabe＠佐倉です。

In article <ajgoke$da4$3...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> fj.sys.mac,fj.comp.input-methodの記事<3D5B8A62...@ty2.fitweb.or.jp>で
> yota...@ty2.fitweb.or.jpさんは書きました。
> > Web 掲示板なんかでやってみれば、 input method マニアが集まってくるかもし
> > れませんよ。
> > 雑誌では商業的に四苦八苦していたことが掲示板では大盛況なんて例はあります
> > から。
>
> そうなんでしょうね。誰かページを作ってくれれば参加
> するのにやぶさかではないのですが、私自身はそういう
> ものを管理するのはめんどうなのでイヤです。(^^;

作ってみましょうか。
この分野に詳しいという訳ではありませんが、興味があります。
出来れば、日本語インプットメソッド（IM）の歴史とか、IMをめぐって
これまでネットニュースでなされた議論や、どのような方法で変換しているのか
という説明（「2文節最長一致法」などの説明）をまとめた文書も置きたいです。
この話、私が言い出しっぺにあたるようですし。

掲示板を作るとしたら、スレッド式のものがいいのでしょうか。
作るといっても、どなたかが制作したフリーものを使おうと思っているのですが。
出来れば、素敵なマークアップがされたHTMLを吐き出してくれる掲示板があれば
いいのですが、お勧めってありますか。

[Yoshihito TAKANO]

高野です。

Junn Ohta wrote:
>
> そうなんでしょうね。誰かページを作ってくれれば参加
> するのにやぶさかではないのですが、私自身はそういう
> ものを管理するのはめんどうなのでイヤです。(^^;

同感。
あんなのよくやってられると思う…。 (^_^;

> VJEはキラーアプリをもてなかったのが最大の敗因かな。
> それでもUNIXワークステーション用とか組み込み用途と
> かでは現在でもそれなりのシェアがあるのではないかと
> 思っていますが。

VJE 使っているといえば Mac や Windows ではないという気も…。 (^_^;

携帯電話のカタログに VJE の文字がありました。
でも ATOK の文字もあって、知名度は ATOK の方が上。 (^_^;;

> > しかし、 Mac では ATOK より EGBRIDGE のシェアが高いという話を聞いたこと
> > がありますが、最近はどうなんでしょうか。
>
> どうなんでしょうね。EGBRIDGEはWindowsとMacの両方に
> 製品を出しているメーカーの中で唯一Macを優先してい
> るメーカーです。それなりのシェアがないとやっていら
> れないでしょう。

EGWORD は力作のワープロで、これを買うと EGBRIDGE が付いてくるので使って
いる Mac ユーザーもいるでしょうね。
うちの会社の Mac にも EGWORD が入っています。
しかし、どのくらいのシェアがあるのかは知りません。

[Yoshihito TAKANO]

高野です。

Junn Ohta wrote:
>
> ATOKもEGBRIDGEもそれ以後ずいぶん進化してきましたし、
> 操作性についてはどの会社の製品もずいぶん似てきては
> いるのですが、変換のクセや細かい操作性といったもの
> は当時からそれほど大きく変わったわけではないですね。
> そういった日本語入力プログラムの性格というか設計思
> 想というか、それをユーザーはもっと知るべきだし、そ
> れを考慮して選んだほうがいいのではないかと思うので
> した。

うーん、コンピュータ時間的には大昔の話だと思いますが、今に至るもその頃の
くせを引きずっているとは思いませんでした。
速度もメモリ量も大違いで、 OS やハードウェアじゃないんだから、変えようと
思えば変えられるのではと…。
各日本語入力プログラムの生い立ちなんて話はあまり聞いたことがありません。
よろしければ、お聞かせ願いたいところです。

> 3文節最長一致法を採用したのは、2文節最長一致法では
> どうしても正しく変換できない場合があるのをどうにか
> するためではないかと思いますが、メモリーが潤沢に使
> えるようになったからこそ実現できたわけですね。まあ
> いずれにしても文節ごとに変換してしまうようなユーザ
> ーにはメリットがないと。:-)

ｘ文節最長一致の類はそもそもあまりアテにならないもののような気が…。
VJE の成績が優れているとすれば、３文節最長一致法だからというより、他の解
析結果をうまく活かしているんでしょうね。

> WXシリーズは当初のWXから最小コスト法を採用してまし
> た。この方法はぴたりと決まるとかなり複雑な文章もき
> れいに変換できて美しいのですが、重み付けの匙加減が
> 微妙でむずかしそうです。ある文章を正しく変換できる
> ようにパラメーターを変更すると別の文章が正しく変換
> できなくなったりするわけで、変換精度を向上させるた
> めには職人芸が必要でしょう。ほかのメーカーが採用し
> ていない(らしい)のはそのためかも。

パテントか何かがあるのかと思っていました。
最小コスト法は文節数最小法の拡張ということで、これもｘ文節最長一致法の仲
間のはずですが、他の解析結果もコストとして統一的に評価できそうで、かえっ
てやりやすそうな気もしますが。

[Yoshihito TAKANO]

高野ともうします。
Mac の話でなくなりそうなので、 followup-to から fj.sys.mac を削っておき
ますが、復活させたければどうぞ。

Kusakabe Youichi wrote:
>
> でも、Windows用に関して、最近はユーザー層が広がったせいか
> 不景気のせいか「ついてきたおまけ」をそのまま使うひとの
> 割合がかなり高いみたいです。

Mac ではもともと ATOK のシェアはたいしたことなかったようですが、今や
Windows でも一太郎と共に消し去られてしまったマシンが多いようですよ。
後釜はもちろん MS-IME です。

[Yoshihito TAKANO]

高野ともうします。

Junn Ohta wrote:
>
> 同音語選択誤りについては1件ごとに1ずつカウントして
> いけばよいのですが、文節区切り誤りについてはどうカ
> ウントするか考慮の余地があります。たとえば変換結果
> に複数の誤りがあったとしても、先頭文節の区切りを修
> 正したら残りもすべて正しく区切り直されることもある
> わけですから。私が採用したのは、正解に達するまでに
> 必要だった文節区切り直し回数を1回ごとに1とカウント
> するという方法です。
>
> 正解が得られなかったときにどれだけの操作が必要だっ
> たかという観点に立てば、同音語選択誤りについても正
> 解に達するまでに何回のキー操作が必要だったかで重み
> をつける方法もありますし、文節区切りについても何文
> 字分ずれていたかで重みをつける方法があります。また、
> 同音語選択誤りよりも文節区切り誤りのほうが修正に頭
> を使うので、ペナルティーをより強くしたいと感じるか
> もしれません。とはいえ、そこまで細かく点数化しても
> 読者に対する説得力につながるとは限りませんし、かえ
> って客観性を失うことにもなります。

太田さんの評価法はおおむね妥当だと思いますが、実際にやってみれば、“正解
に達するまでに必要だった文節区切り直し回数”といっても一筋縄ではいかない
のがわかると思います。
たとえば、“同／音／語／選／択／誤り”のようにしないと原稿どおりの文字が
出ない場合（こんな簡単なのを知らないのは近頃ないと思いますが）、ここまで
もっていく数を数えるのか（そうしないとすればどうするのか）とか、どうやっ
ても結局原稿どおりの文字が出ない場合はどうするのかとか。

[ABE Keisuke]

koabe＠佐倉です。

In article <3D5E2EC6...@ty2.fitweb.or.jp>,
Yoshihito TAKANO <yota...@ty2.fitweb.or.jp> wrote:

> Mac ではもともと ATOK のシェアはたいしたことなかったようですが、今や
> Windows でも一太郎と共に消し去られてしまったマシンが多いようですよ。
> 後釜はもちろん MS-IME です。

たいしたことがないということはなく、むしろATOK優勢ではなかったかと思う
のですが、にわかに資料が見つかりません。

傍証としては、「Mac POWER」（2002年5月号）で、定番ハードウェア
・ソフトウェアを疑えという特集があり、そのなかでATOKが「定番」として
扱われていることが挙げられます。

[ABE Keisuke]

koabe＠佐倉です。

In article <3D5E1F49...@ty2.fitweb.or.jp>,
Yoshihito TAKANO <yota...@ty2.fitweb.or.jp> wrote:

> > どうなんでしょうね。EGBRIDGEはWindowsとMacの両方に
> > 製品を出しているメーカーの中で唯一Macを優先してい
> > るメーカーです。それなりのシェアがないとやっていら
> > れないでしょう。
>
> EGWORD は力作のワープロで、これを買うと EGBRIDGE が付いてくるので使って
> いる Mac ユーザーもいるでしょうね。
> うちの会社の Mac にも EGWORD が入っています。
> しかし、どのくらいのシェアがあるのかは知りません。

EGWORDは、歴史の古いソフトで、私自身もこれによってGUIとWYSIWYGの
洗礼を浴びたので思い入れの深いものなのですが、今はどうなんでしょう。
マイクロソフトのwordもあるし、AppleWorksもあるし、という状況なので、
かつてほど圧倒的な立場ではないのではないと推測しています。

もう少し動作がきびきびして、せめてEUC-JPやISO-2022-JPといった
文字コードが扱えればいいのになーと思っています。

人々の意識は、EGWORDのオマケとしてEGBRIDGEが付いてくるというもの
なのか、それともEGBRIDGEを買うときに、EGWORDやEGWORD Pureが
付いてくるという選択肢があるというものなのか。

[ABE Keisuke]

koabe＠佐倉です。

In article <3D5B7DE9...@ty2.fitweb.or.jp>,

Yoshihito TAKANO <yotakano@ty3�fitweb.or.jp> wrote:

> 後ろの方の文節区切りが間違っていると、注目文節をそこまで動かさないといけ
> ないので、結構面倒なんですよね。
> これに懲りた人はしょっちゅう変換キーを押す入力スタイルになったりするわけ
> ですが、そうすると input-method の評価も変わったりします。

こればっかりは、変換直後の注目文節を最後の文節にしたところで、最初の
文節が間違っていると同じことなので、難しい問題ですね。

いまの日本語インプットメソッドは、細かく文節に切って入力しても、直前に
入力した文／語を覚えていて係り受けなどを解析して変換するという話も
聞いたことがあるのですが、どうなんでしょう。

> VJE は３文節最長一致法、 WX は最小コスト法でしたね（この文章は WX を使っ
> て書いているのですが、“最小コスト法”がデフォルトで登録されていて一発変
> 換したので、笑ってしまいました）。

EGBRIDGEやMacVJE-Delta、ことえりでは、「最小コスト法」は一発変換
出来ませんでした。

それは置いておいて、3文節最長一致法というのはだいたいは推測しようが
あるのですが、最小コスト法というのはどんな方法なんでしょう。

あと、うろ覚えの点として、VJEとWXの関係って、関係がある
という話を聞いたことがある気がするのですが、どうだったのでしょう。

> もっとも、基本となる２文節最長一致法にしても、どうして最長一致する候補が
> もっともらしいといえるのか？と聞かれると…。

IMを作るうえでは、とにかく正しい結果が得られる方法を開発すればいいの
であって、こうした疑問こそ、現代日本語文法関係の学者が解明すればいいのに
と思います。

IMを作っている現場と、現代日本語文法関係の人びとが手を結べば、例えば、
いろいろなテキストを解析するうえで有益な知見が得られそうですし、
具体的には辞典の編集にもなんらかの革新が起こりそうという気がする
のですが、そうはならないのかな。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajgnmo$da4$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> ATOKもEGBRIDGEもそれ以後ずいぶん進化してきましたし、
> 操作性についてはどの会社の製品もずいぶん似てきては
> いるのですが、変換のクセや細かい操作性といったもの
> は当時からそれほど大きく変わったわけではないですね。
> そういった日本語入力プログラムの性格というか設計思
> 想というか、それをユーザーはもっと知るべきだし、そ
> れを考慮して選んだほうがいいのではないかと思うので
> した。

そういう、性格や設計思想を知りたいです。でも、そこまで
深みのある情報が得られません（その原因は、以前このスレッドで
検討したとおり、ユーザー側に依る部分が大きいのですが）。

使う人が何も考えずとも期待している結果が得られれば、
それに越したことはないのでしょうが、使い手が心に思った
だけで、それがコンピューター上に入力されないのであるから、
使う側が、日本語入力ソフトがどのようなつもりで設計されて
いるかを知り、性格を知ったうえで扱っていけば、少しでも
効率かに結びつくのではないかと思います。

辞典だって、ある程度性格を知っていたほうが、ひくときに
効率的になりそうなものなんですが。

[ABE Keisuke]

koabe＠佐倉です。

In article <aj8rn3$26$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> くさかべさんがあれだけ長いあいだ(もう20年?)
> やーいatok
> とか
> ふつーvje
> とか書いても大勢に影響がなかったのと同じですね。:-)

「そうですね」と同意するのもなかなかためらわれますが、
たぶんそうなんでしょう。

例えば日本語入力ソフトについての議論が華やかなりしころに
くさかべさんがしてきたような指摘が全面的にされていたら……、
あまり変わらないのかな？

でも、MacVJEがMac OS Xに対応する準備が始まっていて、楽しみです。

> それは先に示したように同音語選択誤りと文節区切り誤
> りの件数を個別に示しているわけですから、ちゃんと知
> りたい読者は自分で計算できるわけです。ライター側が
> あえて係数を出してもあまり役には立たないだろうとい
> うことです。

これは、ライターが一つの見識として係数を提示して、
読者が自分なりの重みで計算し直すことが出来るという形式が
よりよいのかなと思った次第です。

> でもメーカーが変換テストに使っている文章の量と比較
> すると2～3桁少ないはずです。だからこれだけ数値化さ
> れているようにみえても、この結果はやはり感覚的なも
> のにすぎない。文章の種類にしてももっといくらでもあ
> るはずですからね。

そうですね。それでも、メーカーとは独立した立場での比較・
購入ガイドはほしいわけで、できるだけのベストがあればなあ
と思います。

> 一般/社会人として
> 一般車か/偉人として
> のどちらが適切か正しく評価するプログラムをすぐに書
> けますか? またそのプログラムで類似の他の文章を受け
> 取ったときも適切な区切りを得られるでしょうか? そう
> 考えると日本語の解析がそれほど簡単なものではないこ
> とがわかるでしょう。

書けません。
最初にここにたどり着いた人は、素晴らしいですね。

> 売れているものを買う、知名度の高いものを買う、知り
> 合いの誰かが使っているから買うというユーザーがかな
> りの部分を占めているのも原因のひとつでしょうし、そ
> ういうユーザーにおもねるメディアがあるのも原因のひ
> とつでしょう。しかも「買ってみたらあまりにひどくて
> 使いものにならなかった」という感想をもつのは相当な
> ヘビーユーザーぐらいのもので、そういう人は多くあり
> ませんし、そういう人は上記のような理由で買ったりし
> ないでしょうから、売れ行きを落とす要因にもあまりな
> らないわけです。

数を比較したわけではないので印象論になりますが、Webの
検索サイトで、VJEとATOKをAND検索して出てきたページの中には、
ATOKのほうが優れているとするページも意外とあったかと
思います。
その原因は、慣れの問題なのか、その人が入力する文章が、
たまたまVJEが得意でなかったのか、それともほかの原因が
あるのか。

> 日本語だけを連続して入力する手段としては、オアシス
> の日本語入力は優れていたと思うのですけどね。そのか
> わり、ほかのアプリケーションと連係させるためにさま
> ざまな入力を切り替えたりするのは不得手だったのでは
> ないかと思います。

その辺りが、ワープロ出身の限界だったのかなあ。

[ABE Keisuke]

koabe＠佐倉です。

In article <3D5E3AFC...@ty2.fitweb.or.jp>,
Yoshihito TAKANO <yota...@ty2.fitweb.or.jp> wrote:

> 太田さんの評価法はおおむね妥当だと思いますが、実際にやってみれば、“正解
> に達するまでに必要だった文節区切り直し回数”といっても一筋縄ではいかない
> のがわかると思います。
> たとえば、“同／音／語／選／択／誤り”のようにしないと原稿どおりの文字が
> 出ない場合（こんな簡単なのを知らないのは近頃ないと思いますが）、ここまで
> もっていく数を数えるのか（そうしないとすればどうするのか）とか、どうやっ
> ても結局原稿どおりの文字が出ない場合はどうするのかとか。

一つの方法としては、正しい結果にたどり着くまでに何回キーを押したかという
回数をカウントすることに割り切ってしまうとか。これだと、以前のEGBRIDGEが
不利になってしまうか。同じキー割り付けにして行えばいいのかな。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajgo78$da4$2...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> > input method の場合、何かにバンドルされて販売されることも多く、必ずしも
> > input method 自体の能力でシェアを切り開いてきたわけではないように思いま
> > す。
>
> おっしゃるとおり。
>
> MS-DOS時代のサードパーティー製品の日本語入力プログ
> ラムは、たいていワープロソフトにバンドルされていた
> ものです。ATOKしかり松茸しかり、FIXERしかりKatana
> しかり。

論じられかたとしても、松茸とATOKは、松と一太郎の比較を
するなかで、ということもあったかもしれませんね。

> 例外はVJEで、これは最初から単体製品として販売され
> ていました。とはいえそれだけでは商品として成立しな
> かったので、さまざまな他社アプリケーションにバンド
> ルしてもらっていましたけどね。どんな環境で使われる
> かわからないこともあって、VJEは最初からほかのアプ
> リケーションの邪魔をしないようにできるだけ行儀のよ
> いふるまいをするように作られてました。そのあたりが
> ATOKなどとは大きく違うところ、でしょうか。

なるほど。EGBRIDGEもATOKと同様なんでしょうね。
入力の効率といういった面で考えると、日本語入力ソフトが原因で
ソフトが異常終了するなどはもってのほかであって、そこも含めて
評価できるとベストなんでしょうが、そういうのも評価可能なのかな。

また、この面ではWXはどうなんでしょう。
#WXって、もう先がないのかなぁ。

[Kusakabe Youichi]

In article <koabe-746393....@news.fu-berlin.de>, ABE Keisuke

<ko...@mbp.sphere.ne.jp> wrote:
> > 一般/社会人として
> > 一般車か/偉人として
> > のどちらが適切か正しく評価するプログラムをすぐに書
> > けますか? またそのプログラムで類似の他の文章を受け
> > 取ったときも適切な区切りを得られるでしょうか? そう
> > 考えると日本語の解析がそれほど簡単なものではないこ
> > とがわかるでしょう。
>
> 書けません。
> 最初にここにたどり着いた人は、素晴らしいですね。

人名の語彙を増やして、「牛場」さんという名前を登録したが
ために、「株式会社東芝」が「株式会社と牛場」になってしまう
ロジックは見たことがあります。

> > 日本語だけを連続して入力する手段としては、オアシス
> > の日本語入力は優れていたと思うのですけどね。そのか
> > わり、ほかのアプリケーションと連係させるためにさま
> > ざまな入力を切り替えたりするのは不得手だったのでは
> > ないかと思います。
>
> その辺りが、ワープロ出身の限界だったのかなあ。

不得手...といえば、MacVJEの初期ヴァージョンで「不得手」
っていう言葉を変換するとアレでしたね(^^;
...といっても、いまごろそんなのを持っている人はいないか...。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5E1F49...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> 携帯電話のカタログに VJE の文字がありました。
> でも ATOK の文字もあって、知名度は ATOK の方が上。 (^_^;;

携帯電話だといまのところWnnがシェアトップでしょう。
ATOKがそれに続いていて、あとは各社どっこいどっこい、
というか苦戦中:-)。VJEは携帯電話よりはPDA方面に注
力しているみたい。

●変換エンジン
モバイルWnn:ソニーエリクソン(SO)、松下通信工業(P)、
三洋電機(SA)、京セラ(K)、ケンウッド(K)、パイオ
ニア(PE)
ATOK: 三菱電機(D)、日立製作所(H)、鳥取三洋電機(ST)、
カシオ(CA)
Compact VJE: 松下通信工業(P)
NEC AI変換: NEC(N)
Mobile Rupo: 東芝(T)
OASYS?: 富士通(F)

●入力支援
POBox: ソニーエリクソン(SO)
T9: NEC(N)

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<160820020458177046%vo...@merope.pleiades.or.jp>で
vo...@merope.pleiades.or.jpさんは書きました。

> あと、1単語の読みが12文字までっていう制限が
> 最初のころありませんでしたっけ?
> あと、1「文字」に対応する読みが5文字以上できないってのが
> あったのはATOKじゃなかったかなあ。(松茸だったかなあ)

どちらも憶えてないです。というか、私はそちらにあま
り興味がなかったので系統だった調査はしてない。

そういえば、くさかべさんの主な興味は辞書方面にあっ
たんですよね。私は入力インターフェース方面に興味が
あったので、くさかべさんの問題意識とは多少のずれが
あるかも。

ところで、

> > でした。しかも一度に入力できる読みは36文字までとい
> > う制限がありましたし、

これは29文字の間違いでした。(^^;

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5E3854...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> うーん、コンピュータ時間的には大昔の話だと思いますが、今に至るもその頃の
> くせを引きずっているとは思いませんでした。
> 速度もメモリ量も大違いで、 OS やハードウェアじゃないんだから、変えようと
> 思えば変えられるのではと…。

変換エンジンの形態素解析の部分はプログラムとしては
そう大きなものではないですし、リソースが格段に多く
使えるようになったからといって、アルゴリズムをがら
りと変えて変換精度を大きく向上できるようなものでは
ないです。

最近の変換精度向上の手法としては、むしろ意味解析の
寄与が大きいですね。これはいわゆるAI変換で、辞書単
語に意味属性をもたせておき、係り受けの蓋然性を候補
選択や文節区切りのための補助情報として利用するもの
です。ただ、これは単語や文節の学習情報と相反するこ
とがありますし、本来の形態素解析のクセまで消せるよ
うなものでもありません。またAI変換は辞書が大きくな
るので、携帯電話などでは使われていないと思います。

> 各日本語入力プログラムの生い立ちなんて話はあまり聞いたことがありません。
> よろしければ、お聞かせ願いたいところです。

だいぶ前(ATOK12のころ)のものですが、以前DOS/Vマガ
ジンに書いた原稿をこの記事の末尾につけておきます。
たいした反響もありませんでしたし、興味のある読者も
少なかったのだろうと思うのですが、何かの参考にでも
していただければ。ただ、ATOK(とMS-DOSやWindows)の
来歴がメインで、個々の製品についてはあまり詳しく書
いていません。個々の製品について質問していただけれ
ば知っていることは書きます。

> ｘ文節最長一致の類はそもそもあまりアテにならないもののような気が…。
> VJE の成績が優れているとすれば、３文節最長一致法だからというより、他の解
> 析結果をうまく活かしているんでしょうね。

まあそういっていいかな。

n文節最長一致法とか最小コスト法とかは、形態素解析
が行われたあとでその中のどれがいちばんそれらしいか
を決めるためのものです。それ以前にどういう自立語に
どういう活用語尾や助詞がどれくらいの確実さで続くか
といった接続表(文法テーブル)がどれだけまともに作ら
れているかという話がありますから。

> パテントか何かがあるのかと思っていました。

パテント関係は私はあまり詳しくないです。日本語入力
はユーザーインターフェース方面ではきわめて多くのパ
テントがあるそうです(Canna開発者の今さん談)が、変
換アルゴリズムそのものにパテントがあるという話は寡
聞にして聞いたことがありません。

> 最小コスト法は文節数最小法の拡張ということで、これもｘ文節最長一致法の仲
> 間のはずですが、他の解析結果もコストとして統一的に評価できそうで、かえっ
> てやりやすそうな気もしますが。

そういう面もあると思いますが、純粋なn文節最長一致
法と比較すると大枠で絞り込みしにくいのが難点かな。
つまり、あるパラメーターを変更したときにおおざっぱ
な文節区切りにどこまで影響するか予測しにくいだろう
ということですね。

以下、DOS/Vマガジンに書いた原稿の再掲です。もう4年
近く前のものなので、それ以降の進化については情報が
ありませんが...。

----------------------------------------------------------------------------
■ATOK150% 第8回 最終回・ATOKの歴史をたどる

ATOKを使いこなすというテーマで連載を続けてきたATOK
150%も、今回がいよいよ最終回となった。編集部から特
別にお許しをいただいたので、今回はATOKの来歴をたど
り、競合製品との確執の中でATOKがどのように成長して
きたかを眺めてみることにしよう。

●日本語入力FEPの黎明～ATOKの誕生(1983～1986)

文書作成は、パソコンの登場当初からその用途の上位を
占めている。8ビットCPUを搭載した当時のパソコンは非
力だったため、日本語入力は単漢字変換や熟語変換が一
般的であり、長い文章を入力するのはなかなか骨の折れ
る作業だった。実用的なワープロソフトが普及するのは
16ビットCPUを搭載したパソコンが登場してからのこと
になる。

NECは同社初の16ビットMS-DOSパソコンであるPC-100に、
アスキーとジャストシステムの共同開発になるワープロ
ソフトJS-WORDをバンドルした。1983年のことだ。JS-WO
RDのかな漢字変換部はKTISと呼ばれ、活用語尾や助詞を
認識して変換を行う文節変換を採用していた。PC-9801
が登場すると、JS-WORDはPC-9801に移植されてJS-WORD2
となり、KTISもKTIS2にバージョンアップされた。その
後ジャストシステムはアスキーと袂を分かち、連文節変
換が可能なjX-WORD太郎を発売した。

◆ATOK4が産声をあげる

1985年、jX-WORD太郎から半年を経て、ジャストシステ
ムは一太郎を発売する。一太郎のかな漢字変換部はATOK
4と呼ばれていたが、一太郎から切り放され、独立して
使うことができた。日本語入力FEPとしてのATOKの登場
だ。東芝が630万円のワープロ専用機JW-10を発売してか
ら7年後のことだ。

このときすでにバックスはVJE-IIを販売している。最初
のFEPであるVJE-86は1984年に発売され、当初から連文
節変換が可能だった。VJE-IIはローマ字入力を提供し、
その後改良されてVJE-αとなる。管理工学研究所はPC-9
801のBASICで動く日本語ワードプロセッサを販売し、こ
れはその後「松」となるが、松茸のFEP化はもう少し先
のことだ。いずれにしても、日本語入力FEPの主戦場はP
C-9801のMS-DOSだった。

◆ATOK、VJE、松茸の御三家がシェアを競う

1986年、一太郎Ver.2の登場とともに、ATOKもバージョ
ンアップされてATOK5となる。一太郎上のみという制限
はあったが、ATOK5は変換操作を不要にする自動変換を
搭載していた。同年、バックスもVJE-βで逐次自動変換
を実現する。松茸が松から切り放されて松茸86となった
のもこの年だ。日本語入力FEPはこの三者がメジャーと
なり、御三家と呼ばれた。

当時のATOKが持つ最大の特徴は、スペース変換を採用し
ていたことだ。他社の製品はほとんどがPC-9801のXFER
キーを変換操作に使っていたが、親指で気楽に叩けるス
ペースを変換のトリガーに使っていたことが、ATOKを普
及させた要因のひとつであったことは疑いない。VJE-β
もしぶしぶながら1987年のV1.2でスペース変換を採用す
る。松茸も同年の松茸V2でこれに追随する。

また、ATOKやVJEは当初から後変換が可能だった。後変
換とは入力した文字をキー操作でカタカナや英字にする
機能で、いちいちモードを変更して別の文字種を入力せ
ずにすむ便利な機能だが、当時は後変換を持つ製品は多
くなかった。

しかし、ATOKは一度に入力できる文字数が29文字と少な
く、ユーザーは細切れ入力を強いられた。また、ATOKの
操作体系には変換後の文節選択操作がなく、途中の文節
を切り直すためには先頭から部分確定をくり返し、目指
す文節にたどり着いてから伸ばし縮めを行う必要があっ
た。これらの操作性の改善は、1993年のATOK8まで待た
なければならない。

●百花繚乱の時代～ATOKの台頭(1987～1993)

一太郎は1987年にVer.3となり、ATOKはATOK6となる。AT
OK6は、VJEがだいぶ前から実現していたCTRLキーによる
ショートカット操作をようやく提供し、操作性の面では
一応の完成を見た。アプリケーションからATOKのオン・
オフなどを行うためのAPIも公開され、多くのアプリケ
ーションがATOK6に対応した。操作性や変換精度ではVJE
-βに一日の長があるというのが衆目の一致するところ
だったが、一太郎のシェア拡大とともにATOK6の地位は
不動のものとなる。

2年を経て1989年、一太郎はVer.4となり、ATOK7が登場
する。ATOK7ではATOK6の弱点だった学習能力が改善され、
VJE-β同様に半角英字からのローマ字漢字直接変換が可
能になった。20MB超のハードディスクに対応するなど低
レベルの変更も行われている。ATOK7独自の改良として
は、送り仮名基準を本則、送る、省くから選べることが
目立つ。これはきわめて有益な改良で、その後1991年に
はWXII、Katana4、VJE-γが追随する。ATOKは安定期を
迎え、この後しばらくATOK7の時代が続く。

◆FEPメーカーの興亡

当時はさまざまなFEPが登場し、消えていった時代でも
あった。1987年にはMacintoshの有力な日本語入力ソフ
トだったEGBridgeがエプソン版MS-DOSにバンドルされ、
ワープロソフトのテラIII世からはFIXER3が独立する。
1988年には弘法IIのMGR2、創文αのWXが登場し、NECも
MS-DOSにAIかな漢字変換を搭載する。1989年にはp1.EXE
のDFJ、忍者のKatana2が登場し、FIXER3はFIXER4となる。
FIXER4やNECのAIかな漢字変換は簡単なAI変換を実現し
ていた。これとは逆に、8ビットワープロから出てきた
FEPの多くはこの時期にその生涯を終えている。たとえ
ばハドソンのHuTOPは単体発売の予定広告まで打ちなが
ら、とうとう発売されずに消えてしまった。

しかし、1989年でいちばん重要だったのはWXPの登場だ。
エー・アイ・ソフトがフリーソフトとして配布したWXP
は、メモリ食いで動作も重かったが、変換精度は高く、
ユーザーからはおおむね好評で迎えられた。同社はWXP
のフィードバックを受けて1991年にWXIIを投入する。WX
IIはカスタマイズ機能や他社互換操作体系を実現し、主
にパワーユーザーから一定のシェアを取り込んだ。FEP
業界に新規参入の可能性が残されていることを知らしめ
た面で、WXシリーズには大きな功績があったといえる。

◆ATOK8への長い道程

4年のあいだ沈黙を守っていたATOKだったが、1993年、
一太郎Ver.5とともにATOK8が登場する。ATOK8は用例辞
書を利用して意味解析を行う、業界初の本格的AI変換を
搭載していた。ATOK委員会を編成して辞書単語の網羅的
チェックを行うなど、ATOK8では辞書にも莫大なコスト
を掛けている。ATOKが変換精度の面で業界をリードする
のはこれ以降のことだ。

ATOK8は操作性の面でも大きな進化を遂げた。一度に100
文字までの入力が可能になり、文節選択の操作がようや
く実現された。また、WXIIが1991年に業界で初めて搭載
したカスタマイズ機能は、同年にKatana4、VJE-β3.0、
DFJ2が追随していたが、ATOKも2年遅れでカスタマイズ
機能を搭載した。

●Windows時代の幕開け(1991～1998)

1987年に登場したWindowsは、1991年のWindows 3.0でよ
うやく実用の域に達した。これ以後はWindowsの時代と
なり、MS-DOSは徐々に衰退する。これに伴って日本語入
力システム(MS-DOSではFEPだったがWindowsではIMEと呼
ぶ)の主戦場もWindowsに移ることとなった。

Windows 3.0に対応したIMEはそれほど多くない。サムシ
ンググッドのKatana、バックスのVJE-γ、エー・アイ・
ソフトのWX2-Win程度のものだ。東芝版Windows 3.0には
ATOK7が付属していたが、これは東芝が独自に移植した
ものだったらしく、他社のWindowsには提供されなかっ
た。

◆遅れてきたATOK

ジャストシステムはWindows 3.0の登場から3年近くのあ
いだ、Windows対応製品をまったく出していない。ATOK
ユーザーはやきもきしながら、WinATOKというブリッジ
ソフトでMS-DOS版のATOKを使ったり、あきらめて他社製
品を使っていた。

1993年にはMS IMEを標準搭載したWindows 3.1が登場す
る。MS IMEはWX2-Winに由来する製品であり、カスタマ
イズ機能は落とされていたが、性能的には一般ユーザー
にも十分満足できるものだった。他社製品も続々とWind
ows 3.1対応を果たす。

Windows 3.1から半年以上を経過して一太郎Ver.5が登場
し、ようやくATOK8のWindows 3.1対応が実現する。しか
し、ATOK8は候補ウィンドウを持たず、同音語候補は画
面の一番下に並べて表示するというきわめて不完全なイ
ンタフェースを持つ製品だった。

インタフェースを改善したATOK9は1995年に登場し、よ
うやく他社製品に見劣りする部分がなくなった。このこ
ろにはすでにVJE-DeltaがAI変換を搭載しており、WX3-W
inもようやくAI変換を実現してATOK9と同時に登場する。
ATOK9は辞書サイズが格段に大きくなったが、変換エン
ジンはATOK8とそれほど変わっていない。

◆ATOK vs. MS-IME時代の到来

1995年末にはWindows 95が登場し、標準IMEは用例変換
を搭載したMS-IME95となる。VJE-DeltaはWindows 95と
同時に32ビット対応を果たしたVJE-Delta 2.0となり、
入力補正を実現する。この機能はその後WXGやATOK10の
入力・校正支援へと受け継がれる。翌年にはWXGが登場
し、拡張ローマ字入力などきわめて強力なカスタマイズ
機能をアピールしたが、初期バージョンにはバグが多く、
1年近く安定しなかった。

同じ1996年、Windows 95対応を果たしたATOK10が登場す
る。ATOK10では構文解析方式を全面的に変更し、長らく
使ってきた2文節最長一致法からMS-IME95やWXGと同じ最
小コスト法に変更した[これは後にガセネタであったこ
とが判明^^;]。それと同時にさまざまな改善が行われた
らしく、体感的な変換精度は大きく向上した。機能面で
も英数字記号だけを半角で入力可能にするなど、他社製
品より遅れていた部分のキャッチアップが行われた。

それからまもなくAI変換を搭載したMS-IME97が登場する。
相変わらずカスタマイズ機能は持たないものの、安価な
アップグレード、手書き文字認識を搭載したことなどか
ら、多くのユーザーがMS-IME97を好評で迎えた。このこ
ろから一般ユーザーはATOKかMS-IMEで満足し、それ以外
の製品はあまり話題に登らなくなる。ATOK vs. MS-IME
時代の到来だ。

しかしその陰で、OAK、書院IME、RupoACE、CanoIMEなど、
専用ワープロの衰退とともにWindowsソフトへの移行を
始めたワープロメーカーのIMEが続々と登場する。Wnn95
やCannaなど、UNIX方面からの参入も目立つ。ここに到
ってWindows IMEも百花繚乱の時代を迎えることになる。

◆AI変換の熟成～未来へ

MS-IME97から遅れること数か月、1997年にATOK11が登場
する。ATOK11ではVJE-DeltaやWXGに遅れていた意味解析
後の構文再解析を実現し、細切れ入力への対応や、文章
のジャンルを判断して意味解析に利用するなど、細かい
改善が行われた。AI変換はもはや熟成した技術であり、
こうした付加的な改良によらなければ差別化が行えない
ところまできた。

これと前後してWXG2とVJE-Delta 2.5が登場している。
WXG2は住所入力オプションを持ち、漢字から読みがわか
る逆変換を搭載していた。同時に発売されたパワーアッ
プキットでは手書き文字認識や英和・和英変換が可能だ
った。VJE-Delta 2.5も住所入力アクセサリを搭載し、
これ以後MS-IMEとATOK以外の製品は多機能化で生き残り
を図ることになる。

1998年初頭にはWXG3とMS-IME98が登場する。WXG3は和英
変換を始めとしたさまざまな特殊変換を提供し、MS-IME
98は初めてカスタマイズ機能を搭載した。9月にはATOK1
2が登場し、省入力機能や校正支援、またカスタマイズ
機能を大幅に改善している。

いまやメジャーな製品すべてが多機能化への道を歩みは
じめている。今後のIMEは単なる日本語入力システムで
あることを超え、ユーザーに最も近い位置にある計算機
インタフェースとしてさらなる新境地を拓いてゆくこと
になろう。

●ATOKを総括する

ATOKは長いあいだ「賢くはないが気のいいヤツ」という
評価を受けてきた。しかしATOK8でAI変換を搭載してか
らは、コンスタントに改良を行い、トップクラスの変換
精度を維持しつづけている。機能面では競合製品に遅れ
がちだったが、最近のキャッチアップは貪欲ともいえる
ほどだ。一般ユーザーの好感度は相変わらず高い。ジャ
ストシステムが健全な経営を続け、ATOKに継続して開発
コストを投下できるなら、ATOKは今後も巨人でありつづ
けるに違いない。

さて、ここで紙数が尽きた。これまでの連載にお付き合
いくださった読者の方々に感謝して、この稿を閉じるこ
とにしたい。いつかまたお目に掛かる機会があることを
願おう。

★ATOK年表
1983 (KTIS) (JS-WORD)
1984 (KTIS2) (JS-WORD2)
1985. 1 (ATOK3) (jX-WORD太郎) 2文節最長一致法による連文節変換
1985. 8 ATOK4 (一太郎) 日本語入力FEPとして分離
1986. 5 ATOK5 (一太郎Ver.2) 自動変換
1987. 6 ATOK6 (一太郎Ver.3) CTRLショートカット
1989. 5 ATOK7 (一太郎Ver.4) 送り仮名基準
1991. 7 (ATOK7) (東芝Windows3.0)
1993. 5 ATOK8 (一太郎Ver.5) AI変換、文節操作、カスタマイズ
1993.12 ATOK8 (一太郎Ver.5/Win) Win3.1対応
1995. 1 ATOK9 (一太郎Ver.6/Win) インタフェース改善
1996. 8 ATOK10 (一太郎Ver.7/Win) 最小コスト法に転向、Win95対応
1997. 2 ATOK11 (一太郎Ver.8/Win) ジャンル解析、構文再解析
1998. 9 ATOK12 (一太郎Ver.9/Win) カスタマイズ機能改善

★MS-DOS年表
1983 MS-DOS 2.11
1983 (KTIS) ジャストシステム(JS-WORD)
1984 VJE-86 バックス
1984 (KTIS2) ジャストシステム(JS-WORD2)
1985. 1 (ATOK3) ジャストシステム(jX-WORD太郎)
1985 VJE-II バックス
1985. 8 ATOK4 ジャストシステム(一太郎)
1985 VJE-α バックス

1985.10 MS-DOS 3.1
1985.12 VJE-Σ バックス
1986. 5 ATOK5 ジャストシステム(一太郎Ver.2)
1986. 6 松茸86 管理工学研究所
1986.10 NEC連文節変換 NEC
1986.10 VJE-β バックス
1987. 6 ATOK6 ジャストシステム(一太郎Ver.3)
1987. 9 EGBridge V2 エルゴソフト(EPSON版MS-DOS3.1)
1987. 9 VJE-β 1.2 バックス
1987.10 NEC逐次自動変換 NEC
1987.11 松茸V2 管理工学研究所
1987.12 FIXER3 シティソフト(テラIII世)
1988. 1 MGR2 リードレックス(弘法II)
1988. 2 WX エー・アイ・ソフト(創文α)

1988. 7 MS-DOS 3.3
1988. 7 NEC AI変換 NEC
1989. 3 VJE-β 2.0 バックス
1989. 5 ATOK7 ジャストシステム(一太郎Ver.4)
1989. 6 WXP エー・アイ・ソフト
1989. 6 DFJ 1.0 デービーソフト(p1.EXE)
1989. 7 Katana2 サムシンググッド(Success)
1989. 7 EGBridge V3 エルゴソフト(アシストカルク)
1989.10 FIXER4 シティソフト(テラQueen)
1990. 3 JJ リードレックス(F1 DataBox)

1990. 7 MS-DOS 3.3C
1990. 7 NEC AI変換 NEC
1991. 2 WXII エー・アイ・ソフト
1991. 4 松茸V3 管理工学研究所
1991. 5 Katana4 サムシンググッド
1991. 7 WXII+ エー・アイ・ソフト

1991.11 MS-DOS 5.0
1991.11 VJE-β 3.0 バックス
1991.12 DFJ 2.0 デービーソフト(ARUGA)
1992. 5 松茸V3.5 管理工学研究所
1993. 5 ATOK8 ジャストシステム(一太郎Ver.5)
1995. 1 WXIII エー・アイ・ソフト

★Windows年表
1991. 2 Windows 3.0
1991. 3 Katana 3.5 サムシンググッド
1991. 5 VJE-γ バックス カスタマイズ
1991. 7 (ATOK7) 東芝
1991.10 WX2-Win エー・アイ・ソフト カスタマイズ

1991.12 Windows 3.0A
1992. 3 Katana 4.0 サムシンググッド カスタマイズ
1992. 3 WX2-Win 1.1 エー・アイ・ソフト
1992.10 VJE-γ 1.2 バックス

1993. 5 Windows 3.1
1993. 5 MS IME マイクロソフト
1993. 6 VJE-γ 2.0 バックス
1993. 6 WX2-Win 2.0 エー・アイ・ソフト
1993. 7 OAK/Win 2.0 富士通
1993. 7 E1Win 3.1 イースト
1993.10 WPIME 1.1 ワードパーフェクトジャパン
1993.12 ATOK8 ジャストシステム AI変換、カスタマイズ
1994. 1 WritingHeads 日本IBM
1994. 4 VJE-Delta バックス AI変換
1994. 6 EGBRIDGE 6.0 エルゴソフト
1994. 6 DFJ2 1.5 デービーソフト
1995. 1 ATOK9 ジャストシステム
1995. 1 WX3-Win エー・アイ・ソフト AI変換
1995. 6 Katana 4.5 サムシンググッド
1995. 7 EGBRIDGE 7.0 エルゴソフト
1995. 9 Canna 3.4β NEC

1995.12 Windows 95
1995.12 MS-IME95 マイクロソフト 用例変換
1995.12 VJE-Delta 2.0 バックス 入力補正
1996. 5 WXG エー・アイ・ソフト 入力校正支援、拡張ローマ字
1996. 7 OAK/Win 4.0 富士通
1996. 8 ATOK10 ジャストシステム 入力校正支援
1996. 8 書院IME シャープ
1996. 8 Wnn95 オムロンソフト AI変換
1996. 9 RupoACE 2.0 東芝
1996.10 MS-IME97 マイクロソフト AI変換、手書き文字認識
1996.10 EGBRIDGE 7.3 エルゴソフト 用例変換
1996.12 Wnn95 R2.0 オムロンソフト 英日混在、エンジニアサポート
1997. 1 WXG2 エー・アイ・ソフト 住所入力、逆引き変換
1997. 2 ATOK11 ジャストシステム
1997. 3 CanoIME 1.1 キヤノン
1997. 5 VJE-Delta 2.5 バックス 住所入力
1997. 5 松茸 七夕版 カスタマイズ
1998. 1 WXG3 エー・アイ・ソフト 和英変換
1998. 1 MS-IME98 マイクロソフト カスタマイズ
1998. 1 Canna3.5 NEC
1998. 9 ATOK12 ジャストシステム

以上
----------------------------------------------------------------------------

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D5E3AFC...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> 太田さんの評価法はおおむね妥当だと思いますが、実際にやってみれば、“正解
> に達するまでに必要だった文節区切り直し回数”といっても一筋縄ではいかない
> のがわかると思います。

そういうことですね。

> たとえば、“同／音／語／選／択／誤り”のようにしないと原稿どおりの文字が
> 出ない場合（こんな簡単なのを知らないのは近頃ないと思いますが）、ここまで
> もっていく数を数えるのか（そうしないとすればどうするのか）とか、どうやっ
> ても結局原稿どおりの文字が出ない場合はどうするのかとか。

そこまで考えるなら、修正だけでなく入力そのもののコ
スト(運指コスト+思考コスト)をカウントしなければな
らなくなりそうです。たとえば

ど う お ん ご せ ん た く あ や ま り <変換>
<出ないじゃんかよちくしょー> (思考コスト+10 :-)
<カーソルを「ご」の直後に移動> <変換>
<何だよこれでもだめかよ> (思考コスト+10 :-)
<カーソルを「う」の直後に移動> <変換> <変換> ...

とか、あるいは

お な じ <変換> <後退>
お と <変換>
ご <変換> <変換> <変換>
え ら ぶ <変換> <後退>
...

とか。:-)

あとは、文節を大きめに区切る(名詞の複合語を全体で
ひとつにするとか、活用語を補助用言まで含めて文節に
するとか)か小さめに区切るかによっても違ってきます
ね。大きめに区切れば移動はしやすくなるけど、文節候
補選択はめんどうになるわけです。

文節区切り位置選択や同音語候補選択については、どれ
だけの距離があってもマウスでイッパツ、という考えも
ありますね。ただ、マウスに手を伸ばさなければならな
いというのはキー入力1回と比較して何倍もコストがか
かると見るべきでしょうし、そこは判断がむずかしい。

私自身はマウスはいざ知らず、ファンクションキーなど
ホームポジションから手を離さなければならない操作は
こんりんざい願い下げなので、個人的にはそういう操作
にはきわめて大きいペナルティーを課したい。:-)

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-746393....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。
> 例えば日本語入力ソフトについての議論が華やかなりしころに
> くさかべさんがしてきたような指摘が全面的にされていたら……、
> あまり変わらないのかな？

「日本語入力プログラムは自分で選んで買うもの」とい
う雰囲気があれば違ってきたかもしれませんね。OSやワ
ープロのおまけについてきたものをそのまま使うのがふ
つうで、わざわざ日本語入力プログラムにお金を出そう
というユーザーが増えなかったのが現在の状況に落ち着
いた最大の理由だと思っています。

> 数を比較したわけではないので印象論になりますが、Webの
> 検索サイトで、VJEとATOKをAND検索して出てきたページの中には、
> ATOKのほうが優れているとするページも意外とあったかと
> 思います。
> その原因は、慣れの問題なのか、その人が入力する文章が、
> たまたまVJEが得意でなかったのか、それともほかの原因が
> あるのか。

一般ユーザーがテストしてみようとして思いつく文章っ
て、それほど複雑なものは多くないんですよね。実際に
ある文章を数多くテストしてみないと「あれっ、変換で
きないや」という場面にはなかなか遭遇しない。なので、
ふつうのユーザーが「ATOKのほうが優れている」と書い
ているページはあまり信用しないほうがいいです。

ただし、係り受けベースでのAI辞書というのは網羅性が
重要なので、コストをかければかけるだけよいものがで
きてきます。そういう意味ではジャストシステムがいち
ばん辞書にコストをかけていそうで、係り受けで判別可
能ないちばん適切な同音語候補を第一候補として出して
くる率はATOKがいちばんかもしれませんね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-479EF6....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> そういう、性格や設計思想を知りたいです。でも、そこまで
> 深みのある情報が得られません（その原因は、以前このスレッドで
> 検討したとおり、ユーザー側に依る部分が大きいのですが）。

設計思想についてはメーカー自身がそれを明らかにして
いるわけではないので、辞書単語や用意されている機能
から類推するだけですけどね。

ATOK
・もともとワープロソフト一太郎の日本語入力機能とし
て作られたので文章の入力がメイン
・長い文章を一括変換することは考えていない
・文字種後変換やCtrlショートカットなどが早くから用
意されていたように、省入力操作は重視されている
・送り仮名を本則に限定する機能を用意したり辞書編纂
のための委員会を作ったりするなど、変換結果の日本
語としての品質を重くみている

VJE
・ほかのアプリケーションと組み合わせて使う外付けの
日本語入力プログラムとして作られた。文章入力とデ
ータ入力のどちらも想定
・プログラムとしての安全性、移植性を当初から重視し
ている
・辞書単語の選択は公平で、自社都合による単語などは
ほとんど含まれていない
・辞書学習、辞書メンテナンスなどの機能は当初から充
実していた
・機能的にはバランス重視で、突出した新機能の採用に
は腰が重い

EGBRIDGE
・文章入力がメイン
・プログラムとしての移植性を当初から重視している
・500文字一括入力・変換など、日本語入力プログラム
管理下での編集操作を重視
・ローマ字入力時シフトキー同時押しによるカタカナ入
力など、入力機能に独自性があった

WX
・もともとワープロソフト創文の日本語入力機能として
作られたので文章入力がメイン
・突出した新機能の採用にきわめて積極的
・WXPをフリーソフトとして公開するなどユーザーコミ
ュニティーを重視し、とくにヘビーユーザー層の要望
を数多く採用してきた
・他社製品より格段に強力なカスタマイズ機能や辞書管
理機能をもつ
・バグは多い

松茸
・もともとワープロソフト松の日本語入力機能として作
られたので文章入力がメイン
・当初は連文節変換に文節分かち書きを要求するなど機
能的には進化が遅れぎみだった
・文法テーブルがユーザーによって解析され、特定のユ
ーザーコミュニティーによってサポートされていた

ほかにもいろいろ書きたいことは多いのですが、いっぺ
んにぜんぶは書けないな。(^^;

> 辞典だって、ある程度性格を知っていたほうが、ひくときに
> 効率的になりそうなものなんですが。

いまの国語辞典って、新明解国語辞典以外は性格といえ
るほどの性格の違いはないんじゃないかな。:-)

どういう表記を採用するか(ソフトウェアかソフトウエ
アかとか)、初出用例が信用できるか(広辞苑はまあまあ
だけどほかは怪しいとか)、解説がまともな日本語にな
っているか(大辞泉はいいが大辞林はひどいなとか)、ま
あそういった違いはありますけどね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<180820020501281068%vo...@merope.pleiades.or.jp>で
vo...@merope.pleiades.or.jpさんは書きました。

> 人名の語彙を増やして、「牛場」さんという名前を登録したが
> ために、「株式会社東芝」が「株式会社と牛場」になってしまう
> ロジックは見たことがあります。

固有名詞はある意味鬼門ですよね。

WXシリーズやMS-IMEで「賀久子」という人名があるため
に「書くことが」が「賀久子とが」になり、しかもうま
く学習してくれなくて「賀久子とが」にたびたび遭遇す
るはめになる、という経験はしました。:-)

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-D793FF....@goliath2.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> いまの日本語インプットメソッドは、細かく文節に切って入力しても、直前に
> 入力した文／語を覚えていて係り受けなどを解析して変換するという話も
> 聞いたことがあるのですが、どうなんでしょう。

それは行われています。ATOKなら12以降ですね。あとは
入力をしばらく続けているとどんなジャンルの文章を書
いているかを絞り込んでそのジャンルの単語が出やすく
なるという方式もあります。

とはいえ、べたで文章を打ち込んでいるときには有効で
も、あとで編集しているときに(カーソル移動などをは
さんで)係り受けによる絞り込みがあると邪魔になるこ
ともありますし、データ入力にはあまり向いていなかっ
たりします。むずかしいところですね。

> それは置いておいて、3文節最長一致法というのはだいたいは推測しようが
> あるのですが、最小コスト法というのはどんな方法なんでしょう。

別冊トランジスタ技術『トラ技コンピュータ』の1990年
7月号p.55にWX開発者の小山さん直々の解説があるので
抜粋しておきます。

--------------------------------------------------
●最小コスト法のメリット

最小コスト法の基本は、文節数最小法(5),(6)です。こ
の方法のメリットについては参考文献を参照してくださ
い。文節数最小法とは、一つの文章を分ち書きすると、
多数の分ち書きのパターンが存在しますが、この中で最
も文節数の少ない候補を採用しようというロジックです。
言いかえれば、単語の重み付けを、自立語=1、付属語=0
とし、これを加算し最小の分ち書き候補を得るといった
方法です。

これに対して最小コスト法は、この重み付け、すなわち
コストを、
(1) 単語コスト(単語そのもののコスト)
(2) 文節間コスト(自立語同士が連接する場合、お互い
のくっつきやすさのコスト)
(3) 単語間コスト(ある特定の単語どうしのくっつきや
すさのコスト)
という三つに分割しています。文節数最小法が単語のコ
ストのみに着眼しているのに対し、文節と文節の結合の
しやすさに関して文節間コストと、単語の結合のしやす
さに関して単語間コストを追加し、より確度の高いと思
われるコスト計算を実現しています(図5参照)。

…以下省略…

●参考文献
(5) 吉村, 日高, 吉田; 日本語の構文解析, 文節の統語
規則と表方式を用いた文節構造分析アルゴリズム,
九大工学集報, Vol.54, No.1, 1981年.
(6) 吉村, 日高, 吉田; 日本語文の形態素解析における
最長一致法と文節数最小法について, 情報処理,
Vol.30, No.7, 1982年.

●図5 最小コスト法による例

<入力例1> かれはまたかごしまにたった

候補1: 彼 は / またか / 五指 / 間 に / たっ た
名詞 副助詞 副詞 名詞 名詞 格助詞 動詞 助動詞
1 0 1 1 1 0 1 0
コスト = 5

候補2: 彼 は / また / 鹿児島 / 煮立っ た
名詞 副助詞 名詞 固有名詞 動詞 助動詞
1 0 1 1 1 0
<鹿児島><煮立っ> の文節間コスト[固有名詞-動詞] = α
コスト = 4 + α

候補3: 彼 は / また / 鹿児島 に / 発っ た
名詞 副助詞 名詞 固有名詞 格助詞 動詞 助動詞
1 0 1 1 0 1 0
<に><発っ> の単語間コスト[格助詞(に)-動詞] = β
コスト = 4 + β

文節数最小法の場合は、α=β=0で、候補2と候補3が
採択される。最小コスト法の場合は、5＞4+α＞4+β
になるよう設定してあり、候補3が採択される。

<入力例2> いぬがはしりまわり

候補1: 犬 が / 橋 / 利回り
名詞 格助詞 名詞 名詞
<橋><利回り>の文節間コスト[名詞-名詞] = a

候補2: 犬 が / 走り / 回り
名詞 格助詞 動詞 動詞
<走り><回り>の文節間コスト[動詞連用形-動詞] = b

この例の場合、最小コスト法ではa＞bであるため候補
2が採択される。
--------------------------------------------------

> あと、うろ覚えの点として、VJEとWXの関係って、関係がある
> という話を聞いたことがある気がするのですが、どうだったのでしょう。

それは聞いたことがないなあ。Windows 3.1のMS IMEが
WXシリーズのOEMだった(ソース込みのOEMでそれ以降は
MSKKによる独自開発)という話ではないですか?

> IMを作るうえでは、とにかく正しい結果が得られる方法を開発すればいいの
> であって、こうした疑問こそ、現代日本語文法関係の学者が解明すればいいのに
> と思います。

それはどうかな。国文法学者にとって文法とは定性分析
の対象でしかないでしょう。かな漢字変換には定量分析
が必要なんだし、それは情報科学の分野でがんばるしか
ないのではないかと思います。

> IMを作っている現場と、現代日本語文法関係の人びとが手を結べば、例えば、
> いろいろなテキストを解析するうえで有益な知見が得られそうですし、
> 具体的には辞典の編集にもなんらかの革新が起こりそうという気がする
> のですが、そうはならないのかな。

それは日本語文献の総データベース化とその分析による
国語学に対する寄与ということかな。辞書単語の初出用
例とか総用例数とか年代分析とかにも活用できそうです
し、そういう意味では「辞典の編集」に有益であるとは
私も思いますね。

著作権の切れた日本語文献のデータベース化については
ボランティアベースでいろいろと行われていると思いま
すが、国語学の重要なインフラなんだし、政府が金を出
してローラー作戦でやってくれるのがいちばん。それに
はまあ過去の文献に出てくるすべての漢字を一律に扱え
るコード体系が必要だったりして、いろいろめんどうは
多そうな気もしますが...。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-F5C3C7....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> 論じられかたとしても、松茸とATOKは、松と一太郎の比較を
> するなかで、ということもあったかもしれませんね。

それはありますね。

> なるほど。EGBRIDGEもATOKと同様なんでしょうね。

EGBRIDGEはわりと移植性を重視して作られていましたか
ら、ATOKよりははるかにましでしょう。

> 入力の効率といういった面で考えると、日本語入力ソフトが原因で
> ソフトが異常終了するなどはもってのほかであって、そこも含めて
> 評価できるとベストなんでしょうが、そういうのも評価可能なのかな。

それは評価できたとしてもほかの評価との順序がつけら
れないですね。MS-DOSのころは、バグだけでなく、ほか
の常駐プログラムとの相性の問題もありましたし。

> また、この面ではWXはどうなんでしょう。
> #WXって、もう先がないのかなぁ。

先がないかどうかはわかりません。これだけのリソース
を捨てるメーカーはないと思いますが、当面WindowsXP
対応の見込みがないとか、開発ペースはだいぶ落ちてし
まったようですね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-E55C5D....@binarykiller.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> 作ってみましょうか。
> この分野に詳しいという訳ではありませんが、興味があります。
> 出来れば、日本語インプットメソッド（IM）の歴史とか、IMをめぐって
> これまでネットニュースでなされた議論や、どのような方法で変換しているのか
> という説明（「2文節最長一致法」などの説明）をまとめた文書も置きたいです。
> この話、私が言い出しっぺにあたるようですし。

私は文章を書き散らすだけなので、だれかまとめてくれ
るとありがたいのですが、それは欲張りすぎかな。(^^;

> 掲示板を作るとしたら、スレッド式のものがいいのでしょうか。
> 作るといっても、どなたかが制作したフリーものを使おうと思っているのですが。
> 出来れば、素敵なマークアップがされたHTMLを吐き出してくれる掲示板があれば
> いいのですが、お勧めってありますか。

私はその方面には詳しくないです。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-B2B5F0....@binarykiller.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> 人々の意識は、EGWORDのオマケとしてEGBRIDGEが付いてくるというもの
> なのか、それともEGBRIDGEを買うときに、EGWORDやEGWORD Pureが
> 付いてくるという選択肢があるというものなのか。

私のまわりでEGBRIDGEをもっている人(4例)というのは、
みなEGBRIDGE単体で購入した人です。

そういえば私もBeOS版のEGBRIDGEをなんてのを自分で
買ってたりするなあ。:-)

[Wacky!]

oh...@src.ricoh.co.jp (Junn Ohta) wrote :

> ・辞書単語の選択は公平で、自社都合による単語などは
> ほとんど含まれていない

ここを読んでいてふと思い出してしまったのですが、以下の噂は事
実だったのでしょうかねぇ？

----------------------------
☆かつて存在したＳＯＮＹ・ＭＳＸパソコンで「もりた」は必ず最
初は「盛田」と変換された。この字だけは学習機能が働かず常にト
ップに表示された。
----------------------------

[ABE Keisuke]

koabe＠佐倉です。

ひとまず、
http://www4.airnet.ne.jp/koabe/com_inet/im/index.html
に、ページの趣旨と、内容の柱を作ってみました。

In article <ajmci7$6q9$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 私は文章を書き散らすだけなので、だれかまとめてくれ
> るとありがたいのですが、それは欲張りすぎかな。(^^;

私は、書く材料がほとんどないので、太田さんが書いたことを
掲載させていただけると、非常にうれしいです。

もし、太田さんの記事を基にまとめていいのであれば、
上記ウェブページに挙げた柱の中で、

「日本語入力ソフトの歴史」は、
<ajmc02$6mp$3...@ns.src.ricoh.co.jp>
の記事に、EGBRIDGEなどMac系の話、Wnnの話を加えればいいかな
と思っています。

「変換の仕組み」は、
<ajgnmo$da4$1...@ns.src.ricoh.co.jp>
<aj8rn3$26$1...@ns.src.ricoh.co.jp>
<ajmc1g$6mp$5...@ns.src.ricoh.co.jp>
をまとめたいと考えています。

「各ソフトの特徴」については、
開発元の公式資料を基にしたものに、
<ajmc1t$6mp$6...@ns.src.ricoh.co.jp>
を加えることを考えています。

あと、評価方法についての紹介も必要かな。

> > 掲示板を作るとしたら、スレッド式のものがいいのでしょうか。
> > 作るといっても、どなたかが制作したフリーものを使おうと思っているのですが。
> > 出来れば、素敵なマークアップがされたHTMLを吐き出してくれる掲示板があれば
> > いいのですが、お勧めってありますか。
>
> 私はその方面には詳しくないです。

とりあえず、KENTさんの掲示板を付けてみましたが、吐き出すHTMLが……。
無償提供しているものをそのまま使っているので、ぜいたくは言えませんが、
探してみるなり、改造してみるなりしてみようと思います。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajmd24$6q9$3...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 私のまわりでEGBRIDGEをもっている人(4例)というのは、
> みなEGBRIDGE単体で購入した人です。

そうなると、かえってEGWORDは大丈夫なのだろうかと心配になって
しまいます。

それは置いておいて、太田さんの周辺では、それだけEGBRIDGEの
評価が高いのでしょうか。それとも日本語入力ソフトを評価するのが
好きな人が集まっているとか。

ちなみに、みなさんがご購入されたEGBRIDGEは、Mac用
なのでしょうか。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajmc3b$6mp$8...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> > 入力の効率といういった面で考えると、日本語入力ソフトが原因で
> > ソフトが異常終了するなどはもってのほかであって、そこも含めて
> > 評価できるとベストなんでしょうが、そういうのも評価可能なのかな。
>
> それは評価できたとしてもほかの評価との順序がつけら
> れないですね。MS-DOSのころは、バグだけでなく、ほか
> の常駐プログラムとの相性の問題もありましたし。

これは、それこそ個々の情報交換やトラブル情報の収集で対応する
しかない
のかな。

> > また、この面ではWXはどうなんでしょう。
> > #WXって、もう先がないのかなぁ。
>
> 先がないかどうかはわかりません。これだけのリソース
> を捨てるメーカーはないと思いますが、当面WindowsXP
> 対応の見込みがないとか、開発ペースはだいぶ落ちてし
> まったようですね。

日本語入力ソフトは、みんなが別々のものを使ったからといって、
他のソフトと違い、ファイル交換に支障が出るといったことはあまり
なさそう
なので、できるだけ多様な選択肢が残ればと思います。

--
阿部圭介　(ABE Keisuke)
ko...@mbp.sphere.ne.jp (main)
ko...@catv296.ne.jp (sub)
jh1...@jarl.com

[ABE Keisuke]

koabe＠佐倉です。

In article <ajmc2p$6mp$7...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 「日本語入力プログラムは自分で選んで買うもの」とい
> う雰囲気があれば違ってきたかもしれませんね。OSやワ
> ープロのおまけについてきたものをそのまま使うのがふ
> つうで、わざわざ日本語入力プログラムにお金を出そう
> というユーザーが増えなかったのが現在の状況に落ち着
> いた最大の理由だと思っています。

順応性が高いというのか、無頓着というのか分かりませんが、
私の気持ちとしては、残念で仕方ありません。
でも、ボールペン（ペン）一つとっても、会社で支給される
ものを使えばいいというのが、たぶん普通なのでしょうから、
日本語入力プログラムについても、同じなのでしょう。

> ただし、係り受けベースでのAI辞書というのは網羅性が
> 重要なので、コストをかければかけるだけよいものがで
> きてきます。そういう意味ではジャストシステムがいち
> ばん辞書にコストをかけていそうで、係り受けで判別可
> 能ないちばん適切な同音語候補を第一候補として出して
> くる率はATOKがいちばんかもしれませんね。

文節さえ正しく切り分けられれば、というところなのでしょうか。
ATOKがここに力を注ぐと、評価が変わってくるのかもしれませんね。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajmc1t$6mp$6...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> ATOK
> ・もともとワープロソフト一太郎の日本語入力機能とし
> て作られたので文章の入力がメイン
> ・長い文章を一括変換することは考えていない
というのが、ちょっと面白いですね。パソコンでは、短い文章が主流
だと考えたとか（もちろん、勝手に面白がって考えている想像ですが）。

あと、今回あげられた中では、VJEだけが、
> ・ほかのアプリケーションと組み合わせて使う外付けの
> 日本語入力プログラムとして作られた。文章入力とデ
> ータ入力のどちらも想定
というのが大きな特徴かもしれませんね。

> ほかにもいろいろ書きたいことは多いのですが、いっぺ
> んにぜんぶは書けないな。(^^;
楽しみにしていますm(_ _)m。

> > 辞典だって、ある程度性格を知っていたほうが、ひくときに
> > 効率的になりそうなものなんですが。
>
> いまの国語辞典って、新明解国語辞典以外は性格といえ
> るほどの性格の違いはないんじゃないかな。:-)

あ、どちらかというと、英和辞典を想定していました。
いわゆる熟語・成句を、動詞を重視して配列するか、名詞を
重視して配列するか辞典によって傾向があるらしいので。

> どういう表記を採用するか(ソフトウェアかソフトウエ
> アかとか)、初出用例が信用できるか(広辞苑はまあまあ
> だけどほかは怪しいとか)、解説がまともな日本語にな
> っているか(大辞泉はいいが大辞林はひどいなとか)、ま
> あそういった違いはありますけどね。

広辞苑と大辞泉・大辞林で比較すると、語釈の並べ方が異なり
ませんか？　たしか、もともと広辞苑は歴史的な順を重視していて、
大辞泉は現代で使われる順を重視していたはずですが。いまの
広辞苑は、そうでもないのかな。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajmc1g$6mp$5...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> それは行われています。ATOKなら12以降ですね。あとは
> 入力をしばらく続けているとどんなジャンルの文章を書
> いているかを絞り込んでそのジャンルの単語が出やすく
> なるという方式もあります。

やはりそうでしたよね。

というのも、

> とはいえ、べたで文章を打ち込んでいるときには有効で
> も、あとで編集しているときに(カーソル移動などをは
> さんで)係り受けによる絞り込みがあると邪魔になるこ
> ともありますし、データ入力にはあまり向いていなかっ
> たりします。むずかしいところですね。

と同様に、文書を直すときに突然変な語が出てきて「？」と思う
ことがありました。この機能を簡単にOn Off出来ると、便利かも
知れませんね。編集モードとか。

> > あと、うろ覚えの点として、VJEとWXの関係って、関係がある
> > という話を聞いたことがある気がするのですが、どうだったのでしょう。
>
> それは聞いたことがないなあ。Windows 3.1のMS IMEが
> WXシリーズのOEMだった(ソース込みのOEMでそれ以降は
> MSKKによる独自開発)という話ではないですか?

ずっと勘違いしていました。勘違い解消ですっきりしました。

> > IMを作るうえでは、とにかく正しい結果が得られる方法を開発すればいいの
> > であって、こうした疑問こそ、現代日本語文法関係の学者が解明すればいいのに
> > と思います。
>
> それはどうかな。国文法学者にとって文法とは定性分析
> の対象でしかないでしょう。かな漢字変換には定量分析
> が必要なんだし、それは情報科学の分野でがんばるしか
> ないのではないかと思います。

そうですか。
「こう解析すると正しい結果が得られやすくなる」というのは
入力ソフトを作る側が、「どうしてそうなるのか」は文法学が、
という役割分担かなと考えたのですが、変でしたか。

> それは日本語文献の総データベース化とその分析による
> 国語学に対する寄与ということかな。辞書単語の初出用
> 例とか総用例数とか年代分析とかにも活用できそうです
> し、そういう意味では「辞典の編集」に有益であるとは
> 私も思いますね。

国語辞典って、その語をどう使うかということが出ていないし、
出てくる用例もあまりそういうことを説明していないんですよね。
その辺りの充実にも役立つのではと思いました。

> 著作権の切れた日本語文献のデータベース化については
> ボランティアベースでいろいろと行われていると思いま
> すが、国語学の重要なインフラなんだし、政府が金を出
> してローラー作戦でやってくれるのがいちばん。それに
> はまあ過去の文献に出てくるすべての漢字を一律に扱え
> るコード体系が必要だったりして、いろいろめんどうは
> 多そうな気もしますが...。

そういうテキストに電子化については、日本は遅れているらしい
ですね。

[ABE Keisuke]

koabe＠佐倉です。

In article <180820020501281068%vo...@merope.pleiades.or.jp>,
Kusakabe Youichi <vo...@merope.pleiades.or.jp> wrote:

> 人名の語彙を増やして、「牛場」さんという名前を登録したが
> ために、「株式会社東芝」が「株式会社と牛場」になってしまう
> ロジックは見たことがあります。

あらら。これをみると、本当にいろんなバランスのうえで出来た
難しいことをやっているんだなと思います。
「株式会社と牛場」を防ぐために、「株式会社東芝」をそのものを
登録するなどとやっていると、辞書が大きくなるばかりですし。

> 不得手...といえば、MacVJEの初期ヴァージョンで「不得手」
> っていう言葉を変換するとアレでしたね(^^;
> ...といっても、いまごろそんなのを持っている人はいないか...。

どんなことが起きたのでしょう？
気になります。

[MUNEMOTO Hisaya]

In article <koabe-C066FC....@news.fu-berlin.de>,
ABE Keisuke <ko...@mbp.sphere.ne.jp> wrote:
> 順応性が高いというのか、無頓着というのか分かりませんが、
:

> でも、ボールペン（ペン）一つとっても、会社で支給される
> ものを使えばいいというのが、たぶん普通なのでしょうから、
> 日本語入力プログラムについても、同じなのでしょう。

工学部の学生にも、使い心地ということに無頓着なのがいます。
こういうのがメイカーに就職して製品開発したりするのか? と思うと、

> 私の気持ちとしては、残念で仕方ありません。

です。

hi...@eve.u-ryukyu.ac.jp　宗本久弥

[Kusakabe Youichi]

In article <ajmbud$6mp$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp
(Junn Ohta) wrote:
> Compact VJE: 松下通信工業(P)

ということはPの一部の機種にしなきゃいけないのですね。
Pのは昔から小型でいい感じのが多いですが、
わたしはやはり2つ折りのが好きだからなあ...。

# とかいいつつ携帯電話は持っていませんが。

[Kusakabe Youichi]

In article <ajmbup$6mp$2...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp

(Junn Ohta) wrote:
> そういえば、くさかべさんの主な興味は辞書方面にあっ
> たんですよね。私は入力インターフェース方面に興味が
> あったので、くさかべさんの問題意識とは多少のずれが
> あるかも。

わたしも主な興味は「ユーザーインターフェイス」のほうでした。
ただ、なかなか考えることが多く、複雑なので、
「とりあえず簡単なところから」というのが辞書ファイルでした。

[Kusakabe Youichi]

In article <ajmbud$6mp$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp

(Junn Ohta) wrote:
> 携帯電話だといまのところWnnがシェアトップでしょう。
> ATOKがそれに続いていて、あとは各社どっこいどっこい、
> というか苦戦中:-)。VJEは携帯電話よりはPDA方面に注
> 力しているみたい。
>
> ●変換エンジン
> モバイルWnn:ソニーエリクソン(SO)、松下通信工業(P)、
> 三洋電機(SA)、京セラ(K)、ケンウッド(K)、パイオ
> ニア(PE)
> ATOK: 三菱電機(D)、日立製作所(H)、鳥取三洋電機(ST)、
> カシオ(CA)
> Compact VJE: 松下通信工業(P)
> NEC AI変換: NEC(N)
> Mobile Rupo: 東芝(T)
> OASYS?: 富士通(F)

各メイカーのシェアで重み付けをすると、実はWnnは案外シェアが
少なく、とっぷがATOKで、2位のVJEもけっこう多いとも(1位と同じぐらい)
聞きましたが、実際のところどうなんでしょう?

シャープあたりがVJEを採用すれば逆転するかも。

[Kusakabe Youichi]

In article <ajmbud$6mp$1...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp
(Junn Ohta) wrote:

> OASYS?: 富士通(F)

なんか「OAK」がつく名前だたかも。

[Kusakabe Youichi]

In article <ajmc1t$6mp$6...@ns.src.ricoh.co.jp>, oh...@src.ricoh.co.jp
(Junn Ohta) wrote:
> ほかにもいろいろ書きたいことは多いのですが、いっぺ
> んにぜんぶは書けないな。(^^;

前述の「歴史」みたいなのもこういうのも、
どこかにhtmlファイルで置いてあれば便利なのにー
って思います。
「けーじばん」のペイジとかよりも、私はそういう資料のペイジが
見たいほうです。

[eeldog]

In article <koabe-F15B90....@goliath2.newsfeeds.com>, ABE
Keisuke <ko...@mbp.sphere.ne.jp> wrote:

> とりあえず、KENTさんの掲示板を付けてみましたが、吐き出すHTMLが……。

掲示板より Perl Wiki とかどうですか?

http://www.hyuki.com/yukiwiki/
http://digit.que.ne.jp/work/?WalWiki
http://isweb21.infoseek.co.jp/computer/h_yanai/html/ese-nikki.html

[nobu_mur]

　太田さんの一連の解説、興味深く拝見しました。
実は、Windowsにもお詳しかったのですね。
　元スレッドは、fj.sys.mac ということで、
MacintoshのFEP・IMの歴史(漢字Talk6～7にかけての頃)についても
説明いただけると、EgBridge主流だったのが、急激にシェアを落としたわけなど
皆さん、理解できるのではないかと思うのですが。

[Kusakabe Youichi]

In article <B986FD44.DC24%nobu...@opal.plala.or.jp>, nobu_mur
<nobu...@opal.plala.or.jp> wrote:
> 太田さんの一連の解説、興味深く拝見しました。
> 実は、Windowsにもお詳しかったのですね。

そういえば、
「私、レミさんのファンなんですー」っていう自称「平野レミファン」
のオバサンが、「レミさんってお歌もお上手なんですねー」とか言って
本人は苦笑してたらしい(^^;

> 元スレッドは、fj.sys.mac ということで、
> MacintoshのFEP・IMの歴史(漢字Talk6～7にかけての頃)についても
> 説明いただけると、EgBridge主流だったのが、急激にシェアを落としたわけなど
> 皆さん、理解できるのではないかと思うのですが。

日本語入力ソフトが「FEP」とか総称された時代があったのは、
VJEの影響なんでしょうね。
VJE自体は、いわゆる「フロントエンドプロセッサー」(コンピューターの
ハードウェア関係でよくでてくる用語)から思いついたんでしょうけど。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<B986FD44.DC24%nobu...@opal.plala.or.jp>で
nobu...@opal.plala.or.jpさんは書きました。

すみません、じつはMacはあまり詳しくないのです。Mac
のそのころの話についてはほとんど知識がありません。
誰かご存じの方が書いてくれるとうれしいな。

行きがかり上fj.sys.macにも投稿されてますが、本来は
すでにfj.sys.macを外して話すべきことだったのでしょ
う。次からそちらは外します。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<koabe-C066FC....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> 順応性が高いというのか、無頓着というのか分かりませんが、
> 私の気持ちとしては、残念で仕方ありません。
> でも、ボールペン（ペン）一つとっても、会社で支給される
> ものを使えばいいというのが、たぶん普通なのでしょうから、
> 日本語入力プログラムについても、同じなのでしょう。

一太郎などワープロソフトの相場が5万8千円程度だった
ころ、単体の日本語入力プログラムは2万8千円が相場で
した。その後ATOKやVJEが1万円台後半ぐらいに値段を下
げてきましたが、1万円を切るようになったのはWindows
が当たりまえになってユーティリティー全体の価格相場
が下がってからのことです。

当時から文房具として気楽に買える値段だったら、もう
ちょっと話は違っていたかもしれませんね。

うーん、それでも1枚のキーボードに2万円以上払おうと
いう人にくらべたら、日本語入力プログラムに数千円出
そうという人のほうがいそうな気はするけどなあ...。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<koabe-A3F26F....@goliath2.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> それは置いておいて、太田さんの周辺では、それだけEGBRIDGEの
> 評価が高いのでしょうか。それとも日本語入力ソフトを評価するのが
> 好きな人が集まっているとか。

べつに評価が高いわけではないのでしょうけど、全員が
Macintosh Plusのころからのユーザーです。早いうちか
らEGBRIDGEを使っていて操作性に慣れてしまい、もうほ
かには移れないらしい。うち親族2人。

EGWORDを使わないのは、とくに印刷の必要がないのでエ
ディターのほうが軽くて便利、だからかな。

> ちなみに、みなさんがご購入されたEGBRIDGEは、Mac用
> なのでしょうか。

あ、カウントしたのはMac版のEGBRIDGEだけです。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<190820022012378291%vo...@merope.pleiades.or.jp>で
vo...@merope.pleiades.or.jpさんは書きました。

> 日本語入力ソフトが「FEP」とか総称された時代があったのは、
> VJEの影響なんでしょうね。
> VJE自体は、いわゆる「フロントエンドプロセッサー」(コンピューターの
> ハードウェア関係でよくでてくる用語)から思いついたんでしょうけど。

でしょうね。まあ誰でも思いつくでしょうけど。

でもVJEは「日本語入力フロント・プロセッサ」だった
からなあ...。

そのせいでFPなんていう略語ができちゃったり、「フロ
ント側では処理しているがエンド側では処理をしていな
いのでフロント・エンド・プロセッサという呼び名はお
かしい。フロント・プロセッサが正しい」などと言いだ
すそそっかしい人まで出てきたりと、困ったこともちょ
っとありました。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<190820020308321315%vo...@merope.pleiades.or.jp>で
vo...@merope.pleiades.or.jpさんは書きました。

> わたしも主な興味は「ユーザーインターフェイス」のほうでした。
> ただ、なかなか考えることが多く、複雑なので、
> 「とりあえず簡単なところから」というのが辞書ファイルでした。

そうでしたか、失礼。

当時いろいろ考えていたことで、いま書けるようなもの
があったら聞かせてもらえるとうれしいな。いろいろ縛
りはあったのかのかもしれませんが、そろそろ時効とい
ってよいのではないかと。:-)

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<koabe-F15B90....@goliath2.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> ひとまず、
> http://www4.airnet.ne.jp/koabe/com_inet/im/index.html
> に、ページの趣旨と、内容の柱を作ってみました。

ひえー、足が速いというか腰が軽いというか。(^^;

> 私は、書く材料がほとんどないので、太田さんが書いたことを
> 掲載させていただけると、非常にうれしいです。

それはもう、いくらでもご自由にしてくださってかまい
ませんです。ここが薄いから書き足せなどとおっしゃっ
ていただければへこへこ書きますです。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<ajnu4j$f2d$1...@cobalt01.janis.or.jp>で
mai...@me.104.netさんは書きました。
> ここを読んでいてふと思い出してしまったのですが、以下の噂は事
> 実だったのでしょうかねぇ？

うーん、どう考えてもウソっぽいですけどね。:-)

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<koabe-7AAD65....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> > それは行われています。ATOKなら12以降ですね。あとは
> > 入力をしばらく続けているとどんなジャンルの文章を書
> > いているかを絞り込んでそのジャンルの単語が出やすく
> > なるという方式もあります。
> やはりそうでしたよね。

ATOK11以降でした。(_ _;

> 「こう解析すると正しい結果が得られやすくなる」というのは
> 入力ソフトを作る側が、「どうしてそうなるのか」は文法学が、
> という役割分担かなと考えたのですが、変でしたか。

国文法というのは考古学のようなもので、過去の文献を
いろいろ調べてそれをつらぬく一定のルールのようなも
のを探す学問ですよね。で、おおざっぱなところがわか
れば細部はどうでもいい。自分の考える文法規則にあわ
ない部分は「あ、それは例外」でよい。というわけで情
報科学からの疑問に答えられるほどの精密な成果はない、
ということでしょう。

> 国語辞典って、その語をどう使うかということが出ていないし、
> 出てくる用例もあまりそういうことを説明していないんですよね。
> その辺りの充実にも役立つのではと思いました。

初出用例のデータベースなんてのはあるとうれしいです
けどね。でもすべての単語(辞書に載っていないような
ものまで)のデータベースができたとすれば、それは辞
書とはまた別のものになるような気がします。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<190820020320153624%vo...@merope.pleiades.or.jp>で
vo...@merope.pleiades.or.jpさんは書きました。

> 各メイカーのシェアで重み付けをすると、実はWnnは案外シェアが
> 少なく、とっぷがATOKで、2位のVJEもけっこう多いとも(1位と同じぐらい)
> 聞きましたが、実際のところどうなんでしょう?

台数ベースならNの端末がわりと出ているのでNEC AIも
それなりに、とか、ATOKはあまり人気のある端末に載っ
ていないので台数ベースではちょっと落ちるかも、とい
うような話は聞きました。

どれもここ1年くらいの話です。くさかべさんの情報は
いつごろのものですか? この世界はわりと変化が激しい
ので、シェアもころころ変わっているかもしれません。

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<koabe-8DA951....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。
> > ATOK
> ...

> > ・長い文章を一括変換することは考えていない
> というのが、ちょっと面白いですね。パソコンでは、短い文章が主流
> だと考えたとか（もちろん、勝手に面白がって考えている想像ですが）。

まさかね。:-)

辞書単語の長さとか読みの長さもそうですが、上限を小
さくしておけば何ごとも楽になるわけです。四苦八苦し
て工夫を重ねなくてすむ。画面最下行で変換するときも、
読みの最大長が画面行長より短ければ変換編集行を一時
的にスクロールすることを考えなくてよい。いろいろと
サボれるわけですね。

> あと、今回あげられた中では、VJEだけが、
> > ・ほかのアプリケーションと組み合わせて使う外付けの
> > 日本語入力プログラムとして作られた。文章入力とデ
> > ータ入力のどちらも想定
> というのが大きな特徴かもしれませんね。

あとはKatanaあたりがわりとデータ入力に向いた製品だ
ったかもしれません。

> > ほかにもいろいろ書きたいことは多いのですが、いっぺ
> > んにぜんぶは書けないな。(^^;
> 楽しみにしていますm(_ _)m。

ほんじゃまぼちぼちと。

Katana (サムシンググッド)
・カード型データベース「Ninja」に付属していた。も
ともとはワープロ「即戦力」の日本語入力機能から出
発したらしい(?)
・大塚商会のワープロ「オーロラエース」にOEM採用さ
れていた。そちらでの名称はACE
・短縮入力機能が豊富だったこと、送り仮名基準で省略
を選ぶと送り仮名全省略(「申込」のような)が可能だ
ったことなど、データ入力指向の製品だった
・カナキーで日本語入力のオン・オフが可能
・Windows95対応の32ビット版Katanaも開発されていた
らしい(アスキー社内にベータ版があったらしい。サ
ムシンググッドはアスキー傘下に入りアスキーサムシ
ンググッドとなっていた)が製品化はされなかった

FIXER (シティソフト)
・ワープロ「テラ」の日本語入力部をFEP化したのが始
まり。テラは日立B16のMS-DOS版などもあり、PC-9801
以外への移植にわりと積極的だったという印象がある。
FIXERはシャープX68000版もあったはず
・わりと初期のころからAI変換を標榜していたが、用例
辞書をもっていないので文法レベルの処理だけだった
のではないかと思う
・入力文字のうち濁点半濁点が独立の文字として表示さ
れるとか、変換キーを押すといっぺんに最終結果が表
示されるのではなく、先頭文節のみ変換された結果、
次の文節まで変換された結果のように“つるつる”と
表示が更新されるなど、ユーザーインターフェースに
はわりとクセがあった
・FIXERを開発した深水さん(ずいぶん若かったはず)は
オタクハッカーの典型みたいな人のようで、アセンブ
ラーでごりごり書いた変換カーネルがいっぱつで動い
たという逸話(だか噂だか)が当時あった
・Windows対応の製品は出なかった。最後まで2万8千円
という価格を下げなかった

DFJ (デジタルファーム)
DFJ2 (デービーソフト)
・DFJはデービーソフトとBUGの共同出資によるソフト開
発会社デジタルファームで作られたもので、デービー
ソフトのワープロ「p1.EXE」に搭載されていた。DFJ2
はデービーソフトの開発で、p1.EXEの後継者にあたる
ワープロ「ARUGA」に搭載されていた。
・BUGはISDNルーターMN128の開発元として有名であり、
上記各社はハドソンなどとともに「サッポロバレー」
文化を作っていた。fjに出没している某滝川さんは当
時BUGにいた
・DFJとDFJ2は内部構造がだいぶ違う。基本的なリソー
スは継承されているだろうがまったくの別開発という
印象
・DFJはシンプルな作りで派手なところがどこにもなか
ったが、理科系の文章に強いという風評もあり、わり
と好評だった。ただしデバイスドライバーとしての出
来はやや不十分であり、環境によってはうまく動かな
いことがあった
・DFJ2はプログラムとしての完成度も高くカスタマイズ
機能も充実していたが、Windows対応はとうとう行わ
れなかった

MGR2/JJ (リードレックス)
・MGR2はワープロ「弘法II」に付属していた。前バージ
ョンのMGRは辞書をROMで搭載したPC-9801用Cバス辞書
ボードをもつ製品として有名だった。JJはMGR2の後継
製品でデータ管理ソフト「F1データボックス」に付属
していた
・性能的にも機能的にもあまり特徴はなかった

おてもと (言語工学研究所)
・言語工学研究所は管理工学研究所でワープロ「松」を
作っていた人がスピンアウトして作った会社らしい
・OEMで亀島産業(現AIロジック)のエキスパートシステ
ムに搭載されていたほかは製品化状況不明
・操作性は松茸にわりとよく似ていた

E1 (イースト)
・いちおうFEPとして製品化され販売されていたが、ど
ちらかというとアプリケーション組み込み用途で販売
するためのデモ製品的な位置づけだったらしい。ソー
ス込みでライセンス販売するという広告が当時の技術
系雑誌にたまに載っていた
・操作性も見かけもシンプル、というか付加機能がほと
んどない。変換辞書はおまけ程度の粗雑なものがつい
ていた

憶えているのはこんなところかな。誰かもっと憶えてい
る人が書いてくれるといいのだけど

> あ、どちらかというと、英和辞典を想定していました。
> いわゆる熟語・成句を、動詞を重視して配列するか、名詞を
> 重視して配列するか辞典によって傾向があるらしいので。

なるほど、そうでしたか。CD-ROMになっている学習英和
辞典のたぐいはたいてい手もとにあるのですが、そうい
うことをあまり考えて眺めていませんでした。(^^;

> 広辞苑と大辞泉・大辞林で比較すると、語釈の並べ方が異なり
> ませんか？　たしか、もともと広辞苑は歴史的な順を重視していて、
> 大辞泉は現代で使われる順を重視していたはずですが。

投稿したあとで気づきました。私はあまり語釈の順序を
気にしていないので、どうでもよかったという説もあり
ます。:-)

[ABE Keisuke]

koabe＠佐倉です。

In article <spam-E99E05.1...@news01.so-net.ne.jp>,
eeldog <sp...@chainmail.to> wrote:

> 掲示板より Perl Wiki とかどうですか?

こういうものがあるんですね。知らなかったです。
面白そうですが、だれでも勝手に変えられる（？）のがちょっと
こわい気がしました。こちらは、もう少し時間をかけて、どのような
ものかつかんでいきたいと思いました。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajqtdi$ik0$8...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> > 「こう解析すると正しい結果が得られやすくなる」というのは
> > 入力ソフトを作る側が、「どうしてそうなるのか」は文法学が、
> > という役割分担かなと考えたのですが、変でしたか。
>
> 国文法というのは考古学のようなもので、過去の文献を
> いろいろ調べてそれをつらぬく一定のルールのようなも
> のを探す学問ですよね。で、おおざっぱなところがわか
> れば細部はどうでもいい。自分の考える文法規則にあわ
> ない部分は「あ、それは例外」でよい。というわけで情
> 報科学からの疑問に答えられるほどの精密な成果はない、
> ということでしょう。

もう少し、文法学のような分野で説明をつけてくれそうな
気がしたのですが、その辺というのは、言語学という分野
なのかな。言語学もちょっと違うのかな。

> 初出用例のデータベースなんてのはあるとうれしいです
> けどね。でもすべての単語(辞書に載っていないような
> ものまで)のデータベースができたとすれば、それは辞
> 書とはまた別のものになるような気がします。

英和辞典は、わりと使い方まで示してくれているのに対し、
国語辞典はこのあたりが遅れているのでは、という疑問が
常々ありました。国語辞典は、母語の辞典であることを
想定して、そこまで必要がないという判断をしている
のかもしれませんが、このあたりはどのくらい研究が
進んでいるのだろうとちょっと関心があります。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajqtco$ik0$7...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> > > ATOK
> > ...
> > > ・長い文章を一括変換することは考えていない
> > というのが、ちょっと面白いですね。パソコンでは、短い文章が主流
> > だと考えたとか（もちろん、勝手に面白がって考えている想像ですが）。
>
> まさかね。:-)
>
> 辞書単語の長さとか読みの長さもそうですが、上限を小
> さくしておけば何ごとも楽になるわけです。四苦八苦し
> て工夫を重ねなくてすむ。画面最下行で変換するときも、
> 読みの最大長が画面行長より短ければ変換編集行を一時
> 的にスクロールすることを考えなくてよい。いろいろと
> サボれるわけですね。

電脳時代の日本語が、短文化の傾向が高まるという予測の下、開発
されていたら面白いのですが、まあ、そんなわけないですよね。

でも、こういう説明を聞くと、ますますATOKってどうして
もてはやされたのだろうと、ますます疑問が涌いてしまいます。

> > > ほかにもいろいろ書きたいことは多いのですが、いっぺ
> > > んにぜんぶは書けないな。(^^;
> > 楽しみにしていますm(_ _)m。
>
> ほんじゃまぼちぼちと。

ありがとうございます。

それから、別記事<ajqt9e$ik0$4...@ns.src.ricoh.co.jp>で、
お許しが出たので、
<ajmc1t$6mp$6...@ns.src.ricoh.co.jp>
<ajqtco$ik0$7...@ns.src.ricoh.co.jp>
の二つをあわせてまとめられれば、と思っています。

今回取り上げられなかったものとして、OAKとか、NECAI変換なんて
ところはどうでしょうか？
OAKについては、ソフトバンクから（ユーザー向けだと思う）解説書が
出ていましたね。Oh!FM-TOWNSの連載をまとめたもののはずです。
ほしかったのですが、買いそびれてしまいました。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajqtbr$ik0$6...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 一太郎などワープロソフトの相場が5万8千円程度だった
> ころ、単体の日本語入力プログラムは2万8千円が相場で
> した。その後ATOKやVJEが1万円台後半ぐらいに値段を下
> げてきましたが、1万円を切るようになったのはWindows
> が当たりまえになってユーティリティー全体の価格相場
> が下がってからのことです。

高かったですね。私は、社会人になるまで、自宅のパソコンには
ワープロソフトも、表計算ソフトも入っていませんでした。

> 当時から文房具として気楽に買える値段だったら、もう
> ちょっと話は違っていたかもしれませんね。
万年筆、凝り始めると高いですよー。楽しいけど。
でも実際問題、上記のような値段だと、（いまにおける）万年筆の
ような「趣味のもの」になってしまうのですよね。

> うーん、それでも1枚のキーボードに2万円以上払おうと
> いう人にくらべたら、日本語入力プログラムに数千円出
> そうという人のほうがいそうな気はするけどなあ...。

ハード（＝モノ）とソフトの違いなのかなあ。

[ABE Keisuke]

koabe＠佐倉です。

In article <ajqt9e$ik0$4...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> > 私は、書く材料がほとんどないので、太田さんが書いたことを
> > 掲載させていただけると、非常にうれしいです。
>
> それはもう、いくらでもご自由にしてくださってかまい
> ませんです。ここが薄いから書き足せなどとおっしゃっ
> ていただければへこへこ書きますです。

ありがとうございます。
時間のあるときに、まずは最近の記事から、少しずつ
まとめたいと思います。
それを見ていただいて、いろいろとご指摘いただければ、
幸いです。

[Takashi Sato]

佐藤です。

　本題から大分離れてしまいますが・・・。
　「Wiki」が出てきてるよーなので、これも紹介しておこーかな。
　「Smalltalk」の一種である「Squeak」で実装された「Swiki」ってのもありますね。

　　　http://minnow.cc.gatech.edu/squeak.1
　　　http://www.mars.dti.ne.jp/~umejava/smalltalk/squeak/swiki/
　　　http://www.ether-usa.net/ether-server/macosx/LAN-c-18.html

　などなど。

--

Takashi Sato (stak...@jaist.ac.jp)

[Junn Ohta]

fj.comp.input-methodの記事<koabe-7EB3D4....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> でも、こういう説明を聞くと、ますますATOKってどうして
> もてはやされたのだろうと、ますます疑問が涌いてしまいます。

NEC純正のかな漢字変換よりはるかにまともだったこと、
たいていのユーザーはワープロを買うけど、ほかの製品
が10万円くらいしたころに一太郎は5万8千円で当時とし
ては価格破壊といってよかったこと、だから一太郎を買
って一太郎以外でもATOKを使うのが当たりまえだったこ
と、などですかね、理由としては。

操作性の微妙ななめらかさ、というのもあるかな。VJE
はほかのプログラムの邪魔をしないという大前提があっ
たので、入力中の文字列全体をことあるごとに書き直し
ていました。だからVJEと無関係の常駐プログラムが画
面をスクロールしても入力画面が壊れない。そのかわり
入力に対する反応がなんとなく遅いし、画面もなんとな
くちらちらする。ATOKは常駐プログラムの作者が腹を立
てるほど長時間割り込みをマスクしていて、そのかわり
入力に対する反応も表示もスムーズでした。とはいって
もハードディスクなんてぜいたく扱いのころですから、
入力のたびにフロッピーにかったんかったんアクセスし
ていたんですけどね。

とはいえ、VJEがベストセラーのワープロ製品に付属し
ていたら、上に書いた操作性の違いなんて関係なくVJE
が当時のATOKの位置にいることになったでしょうね。

> 今回取り上げられなかったものとして、OAKとか、NECAI変換なんて
> ところはどうでしょうか？

MS-DOS版のOAKはPC-9801で動いていないかったせいもあ
ってあまり使ったことがないのです。操作性については
前に書いたように入力して[変換]か[無変換]を必ず押す
という独特のものであったことがよくも悪くもユーザー
を選んだでしょうね。あと、変換直後の文字列では文節
区切りが示されず、文節区切りの変更などの操作をしよ
うと思ったらそのためのキーを入力しなければならない
など、長い文章を入力して変換することはあまり考えら
れていないような印象があります。実際文節区切りもあ
まり精度がよくなかったはず。

オアシスのプロの人たちは、私の知るかぎりほとんど文
節ごとに変換操作をしてましたね。学習機能もオフにし
て、同音異義語についてはどれが何番めの候補か憶えて
いて、画面を見ずに必要な回数変換キーを叩いて入力し
てました。

Windows版のOAKは、当初はPC-9801キーボードではまと
もに使えず、しかもカスタマイズの余地がほとんどない
もので、当時The WINDOWS誌の評価記事でけちょんけち
ょんにけなした(オアシス乗り換え組にはいいかもしれ
ないが、ふつうのユーザーには百害あって一利なし、と
まあそんなことを書いた:-)ら、雑誌に載ったときは編
集部にだいぶ書き直されてました。(^^;

Windows版のOAKはそれから操作性がだいぶ変更されて、
ふつうのIMEとかわらなくなってしまいました。いまで
はJapanistという名前になって入力支援機能や辞書アク
セス機能など、日本語入力総合ユーティリティーのふり
をして販売されています。ま、これはこれでおもしろい
やりかただと思いますが...。

NEC AI変換は、PC-9801版MS-DOS標準付属の日本語入力
プログラムとして、MS-DOSの進化とともに文節変換、連
文節変換、逐次自動変換、AI変換と進化してきたのです
が、MS-DOS3.3Bまでは操作性の面でちょっと使いものに
なりませんでした。インライン変換できなかったしスペ
ースで変換できなかったし、変換操作直後にバックスペ
ースを押したらカーソルが左に移動するだけだし、ほか
にもたくさん不便な面があったような気がします。あま
りに不便なのでほとんど使わなかったし、そのせいでよ
く憶えていません。(^^;

MS-DOS3.3CのAI変換からはそういった不便はなくなって、
だいたいふつうの日本語入力プログラムとして利用でき
る仕様になりました。カスタマイズ機能がなかったので
いろいろ解析してNECAICFGというカスタマイズユーティ
リティーを作って公開したりもしましたが、まあほとん
ど使ってくれた人はいないでしょうね。:-)

Windows版のNEC AI変換はNEC版のWindowsにしかついて
こなかったので、まあいまでは使っている人はほとんど
いないと思います。

あとは...スズキ教育ソフトのハイパーキューブについ
ていたDANGO変換(見かけや操作性はATOK風)とかモーリ
ンワークスについていたOMAC(なんとなくFIXER風)とか、
見るべきものもないけどAJIP1とかJOKERとか...。

いずれにしてもPC-9801用MS-DOSで動く日本語入力プロ
グラムを出していたメーカーは20近くあったので、まだ
名前の出ていないものもかなりあるでしょう。

[Junn Ohta]

fj.comp.input-methodの記事<koabe-C253FC....@news.fu-berlin.de>で
ko...@mbp.sphere.ne.jpさんは書きました。

> もう少し、文法学のような分野で説明をつけてくれそうな
> 気がしたのですが、その辺というのは、言語学という分野
> なのかな。言語学もちょっと違うのかな。

言語学...は違う気がする。

> 英和辞典は、わりと使い方まで示してくれているのに対し、
> 国語辞典はこのあたりが遅れているのでは、という疑問が
> 常々ありました。

英語はたしか正書法があるのでしたよね。日本語にはそ
ういうお墨つきのようなものがないので「正しい使いか
た」そのものが存在しないと。ならば使いかたを示すっ
てナニ? という疑問もありますし、国語辞典にできるこ
とはそれほど多くはないでしょう。

これ以上話が続くようならfj.sci.lang.japaneseあたり
に移ったほうがいいかな?

[Junn Ohta]

フォローアップ先からfj.sys.macを外します。

fj.sys.mac,fj.comp.input-methodの記事<koabe-C0EA57....@binarykiller.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。
> これは、それこそ個々の情報交換やトラブル情報の収集で対応する
> しかない
> のかな。

それ以前に、PCのリソースのうち自分の使いたいものを
勝手にひとり占めしている時点で設計思想としてわがま
ますぎるわけです。ほかとの共存を考えて設計していれ
ば「個々の情報交換やトラブル情報の収集」などはそも
そも不要のはず。

> 日本語入力ソフトは、みんなが別々のものを使ったからといって、
> 他のソフトと違い、ファイル交換に支障が出るといったことはあまり
> なさそう
> なので、できるだけ多様な選択肢が残ればと思います。

個人が自分の甲斐性で計算機リテラシーを身につけるの
であればそうでしょうけど、学校で集中して教育するな
ら、教える側のリソースを「多様な選択肢」を残すため
に割くのはもったいないと考える人も多いでしょうね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<ajqtco$ik0$7...@ns.src.ricoh.co.jp>で
私は書きました。
> DFJ (デジタルファーム)
> DFJ2 (デービーソフト)
> ...
> ・DFJ2はプログラムとしての完成度も高くカスタマイズ
> 機能も充実していたが、Windows対応はとうとう行わ
> れなかった

あー、嘘書いちゃった。

DFJ2Winはちゃんとありました。単体で売れるほどの知
名度がなかったせいか、商品としてはいつのまにか消え
てしまいましたが...。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<ajqstr$ik0$1...@ns.src.ricoh.co.jp>で
私は書きました。

> > 　元スレッドは、fj.sys.mac ということで、
> > MacintoshのFEP・IMの歴史(漢字Talk6～7にかけての頃)についても
> > 説明いただけると、EgBridge主流だったのが、急激にシェアを落としたわけなど
> > 皆さん、理解できるのではないかと思うのですが。
>
> すみません、じつはMacはあまり詳しくないのです。Mac
> のそのころの話についてはほとんど知識がありません。

せめてネタ振りだけでもしておきましょうか。

Macで初めて日本語が使えるようになったのは、メモリ
ーが512KB載ったFat Macにキヤノン販売が漢字ROMを乗
せて、エルゴソフトのEGBRIDGEを組み込んだDyna Macと
いう製品でしたっけ? 漢字Talkが使えるようになったの
はもっと後だったはず。

日本語に非対応のMacで日本語を使えるようにするSweet
JAMなんてのがありませんでしたっけ? これはどういう
ものだったのか興味あります。

むかしのMacでは日本語入力のための標準APIが用意され
ていなかったため、インライン変換ができるかどうかは
IMとアプリケーションの組み合わせしだいだったのです
よね。漢字Talk6のころの話?

「ことえり」というのは「言選り」のことだったはずで
すけど、作ったのはキヤノン販売? かつてのバージョン
はずいぶん機能が低かったと聞きます。それぐらいなら
EGBRIDGEをOEMして最初から載せてしまえばよかったと
思うのですが、どうしてそうしなかったのかな。

あとはMacVJEとWXIII for Macかな。MacVJEには「主に
何とかを入力する」とかいう、日本語は2バイト文字で、
英数字記号は1バイト文字で入力するモードが用意され
ていたように記憶しています。そのあたりを開発した人
もfjに顔を出していた(名前忘れちゃいました。すみま
せん)はず。

[余丁町散人]

Junn Ohta at oh...@src.ricoh.co.jp wrote on 02.8.20 13:24:

> Macで初めて日本語が使えるようになったのは、メモリ
> ーが512KB載ったFat Macにキヤノン販売が漢字ROMを乗
> せて、エルゴソフトのEGBRIDGEを組み込んだDyna Macと
> いう製品でしたっけ? 漢字Talkが使えるようになったの
> はもっと後だったはず。
>
> 日本語に非対応のMacで日本語を使えるようにするSweet
> JAMなんてのがありませんでしたっけ? これはどういう
> ものだったのか興味あります。

Dyna Mac 512k と当時の EGBridge プロッピー（一枚）それに Sweet JAM フロッピー
（数枚）なら置いてありますよ。漢字トーク 1.0 も。ご興味があるならお貸しでき
ます。新宿あたりに来られることがあればどうぞ。

--
余丁町散人
http://homepage.mac.com/naoyuki_hashimoto/

[Kaz Hagiwara]

Junn Ohta wrote:
> 日本語に非対応のMacで日本語を使えるようにするSweet
> JAMなんてのがありませんでしたっけ? これはどういう
> ものだったのか興味あります。

SweetJamなら今でもフリーウエアとして存在します。
<http://www.aanda.co.jp/download/Jam.html>

私もちょっとの間お世話になったことがありますが、init, cdev, DA の組み合
わせで出来ていたものだったかな。英語版しかなかったMSWordでも一応日本語の
入力ができました。当時の出力はスクリーンフォントだけだったから、応急的な
ものにしか使えませんでした。それでも２倍のフォントで作って50%に縮小して
印字すれば画数の多い漢字でも一応読めたんですが、ふだんはワープロ専用機を
使ってました。

> むかしのMacでは日本語入力のための標準APIが用意され
> ていなかったため、インライン変換ができるかどうかは
> IMとアプリケーションの組み合わせしだいだったのです
> よね。漢字Talk6のころの話?

漢字トーク6には2.0変換という「FEP」がおまけで付いてきましたね。あれは、
アップルジャパンの自社製だったんでしょうか。

> 「ことえり」というのは「言選り」のことだったはずで
> すけど、作ったのはキヤノン販売? かつてのバージョン
> はずいぶん機能が低かったと聞きます。それぐらいなら
> EGBRIDGEをOEMして最初から載せてしまえばよかったと
> 思うのですが、どうしてそうしなかったのかな。

「ことえり」はアップルジャパンの自社開発だったのでは？キヤノン販売が噛ん
でいたという話はありそうですが、聞いたことはありません。で、最初の「こと
えり」はけっこう高機能だったけど、サードバーティーのIMの開発を促すために
オマケとしてはわざと機能を削ったという噂も……。隠しコマンドがついていた
り、ある文字列を変換すると、ほほうと思うような文字列が現れたりするのは
Appleらしいですね。

System7は英語が先行して、しばらく日本語環境がなかったんですが、それを補
うために出来た「GomTalk」というのもありました。

萩原＠グリフィス大学

[Sasaki Atsushi]

In article <3D61D12F...@gu.edu.au>,

Kaz Hagiwara <K.Hag...@gu.edu.au> wrote:
> 隠しコマンドがついていた
> り、ある文字列を変換すると、ほほうと思うような文字列が現れたりするのは
> Appleらしいですね。

「ことえり」とか、「ことえりのさくしゃ」とか「ことえりのなかま」と
か。 2 になってなくなってしまったのが寂しい。「だぶるくりっく」も
ありましたね。

--
[ Sasaki Atsushi ] Hab Sonne im Herzen,
mailto:h...@mac.com Hab ein Lied auf den Lippen.
-- Flaischlen

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<B987FA1F.A8EA%naoyuki_...@mac.com>で
naoyuki_...@mac.comさんは書きました。

> Dyna Mac 512k と当時の EGBridge プロッピー（一枚）それに Sweet JAM フロッピー
> （数枚）なら置いてありますよ。漢字トーク 1.0 も。ご興味があるならお貸しでき
> ます。新宿あたりに来られることがあればどうぞ。

お誘いありがとうございます。情報だけあれば私は満足
なのでお伺いすることはないと思いますが、なかなか貴
重なものをお持ちですね。

新宿ですか。工学院大学とか、あとはちょっと遠くなり
ますけど小滝橋のあたりにはたまに用事で出かけます。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<B986FD44.DC24%nobu...@opal.plala.or.jp>で
nobu...@opal.plala.or.jpさんは書きました。

> MacintoshのFEP・IMの歴史(漢字Talk6～7にかけての頃)についても
> 説明いただけると、EgBridge主流だったのが、急激にシェアを落としたわけなど

Sankei-PCReport
http://www.sankei.co.jp/databox/pc/1221EGBRIDGE.html

の「EGBRIEDGEは草分け的存在」に情報がありました。
要点だけ書いておくと、

・漢字トークには「2.0変換」というFEPがついていたが
使いものにならなかったので、このころのMac使いは
たいていEGBRIDGEを使っていた。このころVJEも移植
されていた
・漢字トーク7で日本語入力インターフェースが変更さ
れてTSM(テキストサービスマネジャー)になった。最
初に対応したのがことえりで、EGBRIDGEは対応がやや
遅れた
・そのうちATOK8が出て、マックの爆発的な普及と相ま
ってATOKが定番になった(あまり説明になっていない
ような気もするが...)

だそうです。

漢字TALK7のTSMにATOKがまっさきに対応したのならその
せいで普及したということも考えられますが、そのあた
りの前後関係までははっきり書かれてないですね。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<ajsgai$48c$1...@ns.src.ricoh.co.jp>で
私は書きました。
> あとはMacVJEとWXIII for Macかな。

WXシリーズではWXG for Macもありました。

あとTurboJIPとKatana for Mac。

[Takashi Sato]

佐藤です。

＃もう元スレッドから話が大分変わってきているので、
＃変更させていただきました。

Junn Ohta-san wrote:
> Macで初めて日本語が使えるようになったのは、メモリ
> ーが512KB載ったFat Macにキヤノン販売が漢字ROMを乗
> せて、エルゴソフトのEGBRIDGEを組み込んだDyna Macと
> いう製品でしたっけ? 漢字Talkが使えるようになったの
> はもっと後だったはず。

　そこらへんの話は「もうひとつのMacintosh物語」という
　本に詳しく書かれていたような気がしますが、記憶違いだったかな？

　　http://www.amazon.co.jp/exec/obidos/ASIN/4839906947/powerbooknews-22

> 日本語に非対応のMacで日本語を使えるようにするSweet
> JAMなんてのがありませんでしたっけ? これはどういう
> ものだったのか興味あります。

　初期Versionが1985年に発表されてたと思います。
　「漢字Talk 7.1」から採用された「WorldScript」が出てくる
　前までは現役だったと思います。

> 「ことえり」というのは「言選り」のことだったはずで
> すけど、作ったのはキヤノン販売? かつてのバージョン
> はずいぶん機能が低かったと聞きます。

　「ことえり」はかなりお馬鹿さんでした。
　しかし、当時、「ことえり」を賢くするための
　「Kotoeri Tuner」という無料のコントロールパネルが
　あって、これにより、ことえりの「健忘症」が大分マシに
　なりました。
　あと、無料のことえり用辞書も多数存在していました。

　　　http://www.pluto.dti.ne.jp/~ishit/mac/ktkotoeri/

--

Takashi Sato (stak...@jaist.ac.jp)

[ABE Keisuke]

koabe＠佐倉です。

In article <ajsf17$3iu$2...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> 個人が自分の甲斐性で計算機リテラシーを身につけるの
> であればそうでしょうけど、学校で集中して教育するな
> ら、教える側のリソースを「多様な選択肢」を残すため
> に割くのはもったいないと考える人も多いでしょうね。

なるほど。

子供に対してなら、適当に選択肢を与えておけば、勝手に
何とかしそうな気もしますが、乱暴過ぎるかな。

--
阿部圭介　(ABE Keisuke)
ko...@mbp.sphere.ne.jp (main)
ko...@catv296.ne.jp (sub)
jh1...@jarl.com

-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----

[ABE Keisuke]

koabe＠佐倉です。

In article <ajsdh0$3dd$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:

> NEC純正のかな漢字変換よりはるかにまともだったこと、
> たいていのユーザーはワープロを買うけど、ほかの製品
> が10万円くらいしたころに一太郎は5万8千円で当時とし
> ては価格破壊といってよかったこと、だから一太郎を買
> って一太郎以外でもATOKを使うのが当たりまえだったこ
> と、などですかね、理由としては。

なるほど。今から考えると一太郎は「価格破壊」だったの
ですね。NEC AI（私が知っているNEC純正のかな漢字
変換は、NEC AIからです）を使っている人って、見たこと
なかったです。

> 操作性の微妙ななめらかさ、というのもあるかな。VJE
> はほかのプログラムの邪魔をしないという大前提があっ
> たので、入力中の文字列全体をことあるごとに書き直し
> ていました。だからVJEと無関係の常駐プログラムが画
> 面をスクロールしても入力画面が壊れない。そのかわり
> 入力に対する反応がなんとなく遅いし、画面もなんとな
> くちらちらする。ATOKは常駐プログラムの作者が腹を立
> てるほど長時間割り込みをマスクしていて、そのかわり
> 入力に対する反応も表示もスムーズでした。とはいって
> もハードディスクなんてぜいたく扱いのころですから、
> 入力のたびにフロッピーにかったんかったんアクセスし
> ていたんですけどね。

なんということ。裏でみんなに迷惑をかけて、表向きは
いい子を演じているみたいですね。これを知っている人が
「ATOKなんて」って思うのは、理解できます。

> MS-DOS版のOAKはPC-9801で動いていないかったせいもあ
> ってあまり使ったことがないのです。操作性については
> 前に書いたように入力して[変換]か[無変換]を必ず押す
> という独特のものであったことがよくも悪くもユーザー
> を選んだでしょうね。

XFER、NFERを使って、OAKを使えといわれたら、多分
いやになっていたかも知れません。

> あと、変換直後の文字列では文節
> 区切りが示されず、文節区切りの変更などの操作をしよ
> うと思ったらそのためのキーを入力しなければならない
> など、長い文章を入力して変換することはあまり考えら
> れていないような印象があります。実際文節区切りもあ
> まり精度がよくなかったはず。
>
> オアシスのプロの人たちは、私の知るかぎりほとんど文
> 節ごとに変換操作をしてましたね。学習機能もオフにし
> て、同音異義語についてはどれが何番めの候補か憶えて
> いて、画面を見ずに必要な回数変換キーを叩いて入力し
> てました。

あまり長い文はだめでした。複文節変換モードでも、
単文節で変換するのが普通でした。

FM-TOWNSのOAK（OAK2）は、辞書をROMに持っていて、
PC-9800+ATOKがフロッピーディスクカタカタいわせて
いた時に、静かだったのが良かった点かな。でも学習結果は、
CMOS-RAMに保持しており、容量が少ないという意見が
出ていた覚えがあります。

> Windows版のOAKは、当初はPC-9801キーボードではまと
> もに使えず、しかもカスタマイズの余地がほとんどない
> もので、当時The WINDOWS誌の評価記事でけちょんけち
> ょんにけなした(オアシス乗り換え組にはいいかもしれ
> ないが、ふつうのユーザーには百害あって一利なし、と
> まあそんなことを書いた:-)ら、雑誌に載ったときは編
> 集部にだいぶ書き直されてました。(^^;

もともと、OAKはカスタマイズさせないソフトでした。
黙ってこっちが用意したキーボードとソフトを使え、
といったところでしょうか。

> Windows版のOAKはそれから操作性がだいぶ変更されて、
> ふつうのIMEとかわらなくなってしまいました。いまで
> はJapanistという名前になって入力支援機能や辞書アク
> セス機能など、日本語入力総合ユーティリティーのふり
> をして販売されています。ま、これはこれでおもしろい
> やりかただと思いますが...。

Japanistは、ちょっとおもしろそうだと思ったのですが、
実際にはいじったことがありません。誰か使っている人は
いらっしゃるのでしょうか。

> NEC AI変換は、PC-9801版MS-DOS標準付属の日本語入力
> プログラムとして、MS-DOSの進化とともに文節変換、連
> 文節変換、逐次自動変換、AI変換と進化してきたのです
> が、MS-DOS3.3Bまでは操作性の面でちょっと使いものに
> なりませんでした。インライン変換できなかったしスペ
> ースで変換できなかったし、変換操作直後にバックスペ
> ースを押したらカーソルが左に移動するだけだし、ほか
> にもたくさん不便な面があったような気がします。あま
> りに不便なのでほとんど使わなかったし、そのせいでよ
> く憶えていません。(^^;

OAKしか選択肢がなかったともいっていいFMシリーズと
違い、PC-9800シリーズ（単に98と書きたい！）は、
これまで挙げられたように、いろいろなソフトが開発
されていたので、それで良かったのかも知れませんね。

--
阿部圭介　(ABE Keisuke)
ko...@mbp.sphere.ne.jp (main)
ko...@catv296.ne.jp (sub)
jh1...@jarl.com

[ABE Keisuke]

koabe＠佐倉です。

太田さんのご厚意により記事を使わせていただき、
「各日本語入力ソフトの特徴」というページを作成
いたしました。
http://www4.airnet.ne.jp/koabe/com_inet/im/feature.html

まだ暫定版なので、リンク等におかしい点があります。
できれば、上記ページのATOKの項のような形式を標準に
したいと考えています。でも、ひょっとすると太田さんの
記事だけでまとめたほうがいいのかなとも考えています。
ATOK以外については、まずは太田さんの記事をまとめて、
載せました。

掲載順は、ひとまずアルファベット順にしています。
現行のものと、現在サポートまたは開発が止まっている
ものとで分けた方がい
いのかなとも思っています。

これで大丈夫そうでしたら、他のページからリンクする
ようにしようと思いま

[Junn Ohta]

fj.comp.input-methodの記事<koabe-8985CD....@goliath2.newsfeeds.com>で
ko...@mbp.sphere.ne.jpさんは書きました。

> なるほど。今から考えると一太郎は「価格破壊」だったの
> ですね。NEC AI（私が知っているNEC純正のかな漢字
> 変換は、NEC AIからです）を使っている人って、見たこと
> なかったです。

FEPCTRLライブラリーを作っていたとき、受託開発ソフ
トを納入するのにNEC純正FEPで動かすことが条件なので
純正FEPに対応してほしいという要望がありました。納
入するほうも大変だけど、そのソフトを使わされる側も
大変だなあと同情しました。:-)

というわけで、使っている人もいなかったわけではない
ようです。

> なんということ。裏でみんなに迷惑をかけて、表向きは
> いい子を演じているみたいですね。これを知っている人が
> 「ATOKなんて」って思うのは、理解できます。

とはいうものの、MS-DOSはもともと日本語入力をデバイ
スドライバーとしてきちんと動かすためのしくみを持っ
ていなかったわけで、自分がどこまで重要なプログラム
でどこまでわがままを通してよいかもわりと微妙なとこ
ろではあったのです。

ワープロやら表計算やらしか使わん、というユーザーに
はATOKのほうが使い勝手がよい面もあったわけで、単純
に悪モノにできるわけでもありません。やはり思想の違
いに尽きるのでしょう。

> Japanistは、ちょっとおもしろそうだと思ったのですが、
> 実際にはいじったことがありません。誰か使っている人は
> いらっしゃるのでしょうか。

常用はしていませんがノートには入れてあります。V1.0
のままですけど。興味がおありでしたら質問していただ
ければお答えします。

[MUNEMOTO Hisaya]

In article <3D61D12F...@gu.edu.au>,
Kaz Hagiwara <K.Hag...@gu.edu.au> wrote:

> で、最初の「ことえり」はけっこう高機能だったけど、サードバーティーの
> IMの開発を促すためにオマケとしてはわざと機能を削ったという噂も……。

これは噂じゃなくて、作者ご本人が書かれてたんですが、件のページは消滅
してしまったようです。私が引用した記事がqueenやgoogleにありました。
http://queen.heart.ne.jp/cgi-bin/queen4?msgid=%3C9h72dh$t4$1...@news2.u-ryukyu.ac.jp%3E%0D%0A&go=%B8%A1%BA%F7
http://groups.google.co.jp/groups?selm=9h72dh%24t4%241%40news2.u-ryukyu.ac.jp&oe=ISO-2022-JP&output=gplain

# 今まだgoogleのキャッシュには元ページ(のコピー)が残ってました。
http://www.google.co.jp/search?q=cache:y45EFzLCWW4C:www.alan.co.jp/~miya/docs/profile.html

hi...@eve.u-ryukyu.ac.jp　宗本久弥

[MUNEMOTO Hisaya]

In article <ajstet$7vf$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) wrote:
> Sankei-PCReport
> http://www.sankei.co.jp/databox/pc/1221EGBRIDGE.html

ここには「MacOS8.5と相性が悪い？日本語入力プログラム」という項が
ありますが、MacVJE-DeltaはMac OS 8.6でこけてしまいました。
Mac OS 9でまた使えるようになったようですが、
# http://www.vacs.co.jp/update/macvjeup.htm
私は浮気したままになってしまってます。
# Mac OSに8.6がなければ、今でも使ってたかも。
# これを書いてたら、なんかまた急に戻そうかという気になってきました...

hi...@eve.u-ryukyu.ac.jp　宗本久弥

[MUNEMOTO Hisaya]

In article <koabe-8985CD....@goliath2.newsfeeds.com>,

ABE Keisuke <ko...@mbp.sphere.ne.jp> wrote:
> FM-TOWNSのOAK（OAK2）は、辞書をROMに持っていて、
> PC-9800+ATOKがフロッピーディスクカタカタいわせて
> いた時に、静かだったのが良かった点かな。でも学習結果は、

5インチFDDのオアシス(OASYS F100とかそんな機種名だったかな?)は
キーを打つたびにガッチャンガッチャンとてもうるさいドライブでした。

hi...@eve.u-ryukyu.ac.jp　宗本久弥

[MUNEMOTO Hisaya]

In article <koabe-C253FC....@news.fu-berlin.de>,

ABE Keisuke <ko...@mbp.sphere.ne.jp> wrote:
> 英和辞典は、わりと使い方まで示してくれているのに対し、
> 国語辞典はこのあたりが遅れているのでは、という疑問が
> 常々ありました。国語辞典は、母語の辞典であることを
> 想定して、そこまで必要がないという判断をしている
> のかもしれませんが、

http://sekky.tripod.com/jishointro.html#SEC7
「日本で出版されている英和辞典の水準は，世界的に見てもトップレベルで，
イギリスやアメリカの辞書出版社も，参考資料として使っているそうです。」
とのことです。
# 一応クロスポスとしときました > <ajsejk$3iu$1...@ns.src.ricoh.co.jp>

hi...@eve.u-ryukyu.ac.jp　宗本久弥

[Yoshihito TAKANO]

高野です。
followup-to は fj.comp.input-method のみ。

ABE Keisuke wrote:
>
> > 後ろの方の文節区切りが間違っていると、注目文節をそこまで動かさないといけ
> > ないので、結構面倒なんですよね。
> > これに懲りた人はしょっちゅう変換キーを押す入力スタイルになったりするわけ
> > ですが、そうすると input-method の評価も変わったりします。
>
> こればっかりは、変換直後の注目文節を最後の文節にしたところで、最初の
> 文節が間違っていると同じことなので、難しい問題ですね。

私は変換結果をチェックするときに注目文節を逆送りする（左に動かす）のが性
に合わないのと、多くの場合、始めの方の文節区切りが間違っていると後が全部
駄目になるので、変換直後に最後の文節を注目文節にしたいとは思いません。

> IMを作るうえでは、とにかく正しい結果が得られる方法を開発すればいいの
> であって、こうした疑問こそ、現代日本語文法関係の学者が解明すればいいのに
> と思います。
>
> IMを作っている現場と、現代日本語文法関係の人びとが手を結べば、例えば、
> いろいろなテキストを解析するうえで有益な知見が得られそうですし、
> 具体的には辞典の編集にもなんらかの革新が起こりそうという気がする
> のですが、そうはならないのかな。

もっともなご意見だと思いますが、個人的には期待薄だと思います。
むしろ、論理学（という名前が付けられている分野）の人なんかの方が期待でき
るかも。
--
Yoshihito TAKANO
mailto:yota...@ty2.fitweb.or.jp

[Yoshihito TAKANO]

高野です。
followup-to は fj.comp.input-method のみ。

Junn Ohta wrote:
>
> そこまで考えるなら、修正だけでなく入力そのもののコ
> スト(運指コスト+思考コスト)をカウントしなければな
> らなくなりそうです。たとえば
>
> ど う お ん ご せ ん た く あ や ま り <変換>
> <出ないじゃんかよちくしょー> (思考コスト+10 :-)
> <カーソルを「ご」の直後に移動> <変換>
> <何だよこれでもだめかよ> (思考コスト+10 :-)
> <カーソルを「う」の直後に移動> <変換> <変換> ...
>
> とか、あるいは
>
> お な じ <変換> <後退>
> お と <変換>
> ご <変換> <変換> <変換>
> え ら ぶ <変換> <後退>
> ...
>
> とか。:-)

まあ、実際に使うときには、あまりにも変換してくれなくて、しかもある程度使
いそうな単語は登録しちゃいますけどね。
しかしテストの場合は、登録などしない建前のがほとんどなので、どうするのか
なと。

> あとは、文節を大きめに区切る(名詞の複合語を全体で
> ひとつにするとか、活用語を補助用言まで含めて文節に
> するとか)か小さめに区切るかによっても違ってきます
> ね。大きめに区切れば移動はしやすくなるけど、文節候
> 補選択はめんどうになるわけです。

そうですね。
私はなるべく大きめに区切るようにしていますが、そうしてみたら漢字が出ない
ということも、もちろん多いです。 (^_^;
テストの場合、文節長を修正する際にどちらの方針で行くかによっても、結果が
変わるでしょう。

> 文節区切り位置選択や同音語候補選択については、どれ
> だけの距離があってもマウスでイッパツ、という考えも
> ありますね。ただ、マウスに手を伸ばさなければならな
> いというのはキー入力1回と比較して何倍もコストがか
> かると見るべきでしょうし、そこは判断がむずかしい。

私は文節操作や候補選択をマウスで行うことはないですね。
あまりにもうっとうしく、何が好きでこんなことをしなくてはならないのかとい
う感じです。
行やページをまたいだインライン変換中にわけのわからんことになったこともあ
ったかな。

> 私自身はマウスはいざ知らず、ファンクションキーなど
> ホームポジションから手を離さなければならない操作は
> こんりんざい願い下げなので、個人的にはそういう操作
> にはきわめて大きいペナルティーを課したい。:-)

私が今この文章を打っているキーボードにはファンクションキーがないので、そ
ういうのは困ります（笑）。

[Yoshihito TAKANO]

高野です。
followup-to は fj.comp.input-method のみ。

http://www.geocities.co.jp/SiliconValley/8087/zakki.html
によれば、 Nifty の SAISWX というところに

> 「芙蓉塾: 日本語＆ＦＥＰ教養講座」会議室中で、WXシリーズの開発者オムラ
> イス氏が連載された「ＦＥＰ文法講座」がなくなるのは、仮名漢字変換の技術
> ・文化にとっての損失といってもいいと思います。この講座、実に150回も連
> 載され、仮名漢字変換の内部に興味のある人にとっては必須の資料といえます。

といわれるものがあったらしいのですが…。
どんなものだったのか気になります。

[Yoshihito TAKANO]

高野です。
followup-to は fj.comp.input-method のみ。

ABE Keisuke wrote:
>
> > 人名の語彙を増やして、「牛場」さんという名前を登録したが
> > ために、「株式会社東芝」が「株式会社と牛場」になってしまう
> > ロジックは見たことがあります。
>
> あらら。これをみると、本当にいろんなバランスのうえで出来た
> 難しいことをやっているんだなと思います。
> 「株式会社と牛場」を防ぐために、「株式会社東芝」をそのものを
> 登録するなどとやっていると、辞書が大きくなるばかりですし。

まっとうな方法として、“法人名”のような品詞（属性）を用意して“東芝”を
登録しておき、“（株）”とか“合資会社” (^_^; とかとひっつきやすくして
おけばいいですね。

しかし、ついさっき“いいかわるいか”（“善いか悪いか”のつもり）を変換し
たら“飯川ルイか”となってのけぞってしまった…。
飯川ルイって、なんかタレントみたいな名前…。 (^_^;;

[Yoshihito TAKANO]

高野です。
Mac の話のようなので、 fj.sys.mac を加えておきます。

ABE Keisuke wrote:
>
> > Mac ではもともと ATOK のシェアはたいしたことなかったようですが、今や
> > Windows でも一太郎と共に消し去られてしまったマシンが多いようですよ。
> > 後釜はもちろん MS-IME です。
>
> たいしたことがないということはなく、むしろATOK優勢ではなかったかと思う
> のですが、にわかに資料が見つかりません。

Mac における ATOK のシェアがたいしたことないという資料は数年前に見たもの
ですが、見つかりませんでした。

逆に ATOK 優勢という資料は、たとえば
http://www.watch.impress.co.jp/pc/docs/article/970709/result.htm
のようなものがあります（ 1997 年？のアンケート）。
これによれば、 Mac でメインで使う日本語入力システムが ATOK という人の割
合は 46% とのこと。

私の見た資料は誤りで、 Mac でも ATOK のシェアは高かったし、今も高いのか
もしれません。 (^_^;

ただ、個人的に見聞きした範囲からは、 ATOK が 1997 年時点で 46% ものシェ
アを占めていたとは信じがたいものがあります。
また、 ATOK を入れていると Mac が固まるという話が（ fj でも）流れていた
ため、入れないことにしているという人は結構いました。

> 傍証としては、「Mac POWER」（2002年5月号）で、定番ハードウェア
> ・ソフトウェアを疑えという特集があり、そのなかでATOKが「定番」として
> 扱われていることが挙げられます。

最近 MAC POWER を読んでいないのですが、私が読んでいた頃は、 MAC POWER 編
集部の人はほとんどが ATOK を使っていましたね（笑）。

[Yoshihito TAKANO]

高野です。
followup-to は fj.comp.input-method のみ。

Junn Ohta wrote:
>
> 最近の変換精度向上の手法としては、むしろ意味解析の
> 寄与が大きいですね。これはいわゆるAI変換で、辞書単
> 語に意味属性をもたせておき、係り受けの蓋然性を候補
> 選択や文節区切りのための補助情報として利用するもの
> です。ただ、これは単語や文節の学習情報と相反するこ
> とがありますし、本来の形態素解析のクセまで消せるよ
> うなものでもありません。またAI変換は辞書が大きくな
> るので、携帯電話などでは使われていないと思います。

人間（日本人）が日本語を扱う場合は間違いなく意味を考慮しているわけで、き
わめてまっとうな手段だと思います。（ｎ文節最長一致なんてことは頭の中でや
っているのでしょうか？）

> だいぶ前(ATOK12のころ)のものですが、以前DOS/Vマガ
> ジンに書いた原稿をこの記事の末尾につけておきます。
> たいした反響もありませんでしたし、興味のある読者も
> 少なかったのだろうと思うのですが、何かの参考にでも
> していただければ。ただ、ATOK(とMS-DOSやWindows)の
> 来歴がメインで、個々の製品についてはあまり詳しく書
> いていません。個々の製品について質問していただけれ
> ば知っていることは書きます。

ありがとうございます。
こうしてまとまったものは、資料として大きな価値があると思います。
ATOK に関しては一太郎の功績が大きかったであろうことがよくわかりますね。

私はもともとはキーカスタマイズしやすかったために WX シリーズを使ってきた
のですが、 ATOK などと比べて辞書の品詞分類が細かく分けられていた（という
か、それをユーザーに見せていた）のが印象的でした。
AI 変換が導入されたときも、ユーザー登録単語についても“動物、獣、鳥、虫、
魚…”のような属性登録が可能だったのですが、こういうのはやっぱり特異な例
なんでしょうか？

[Sasaki Atsushi]

In article <ajtmtf$jbj$1...@news2.u-ryukyu.ac.jp>,

hi...@eve.u-ryukyu.ac.jp (MUNEMOTO Hisaya) wrote:
> これは噂じゃなくて、作者ご本人が書かれてたんですが、件のページは消滅
> してしまったようです。私が引用した記事がqueenやgoogleにありました。

(snip)
> # 今まだgoogleのキャッシュには元ページ(のコピー)が残ってました。

ここにも残っているようです。

http://web.archive.org/web/*/http://www.alan.co.jp/‾miya/docs/profile.html
http://web.archive.org/web/20011018012641/http://www.alan.co.jp/‾miya/docs/profile.html

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D624881...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> まあ、実際に使うときには、あまりにも変換してくれなくて、しかもある程度使
> いそうな単語は登録しちゃいますけどね。
> しかしテストの場合は、登録などしない建前のがほとんどなので、どうするのか
> なと。

私が行ったテストでは、最初の変換結果をみて、登録さ
れていない単語は登録しました。未登録単語はテスト結
果として別途記録しておきます。

単語が辞書にないのはもちろんペナルティーを課すべき
なんですけど、その単語が辞書にあれば文節を正しく区
切れたなら、それを文節区切り誤りとしてカウントする
のもおかしい話ですからね。

> > あとは、文節を大きめに区切る(名詞の複合語を全体で
> > ひとつにするとか、活用語を補助用言まで含めて文節に
> > するとか)か小さめに区切るかによっても違ってきます

> ...

> 私はなるべく大きめに区切るようにしていますが、そうしてみたら漢字が出ない
> ということも、もちろん多いです。 (^_^;
> テストの場合、文節長を修正する際にどちらの方針で行くかによっても、結果が
> 変わるでしょう。

いえ、人間の操作としてどう区切るかではなくて、日本
語入力プログラムが変換結果をどういう文節の集まりと
して提示するかという話です。たとえば「想像してくだ
さい」という文節を「想像して/ください」と区切って
提示するか、それとも「想像してください」のようにま
とめて提示するか、ということ。

「想像して/ください」になっていれば「ください」だ
けを同音語選択で漢字に直して「想像して/下さい」と
するのは簡単だけど、そのかわり「想像して/ください」
を通過したいときは文節移動操作を2回行わなければな
りませんよね。

逆に「想像してください」なら通過するのに文節移動が
1回ですむけど、そのかわり「想像して下さい」に直し
たければ「創造してください」「創造して下さい」など
の中から選ぶことになって同音語の選択肢が増え、選択
に必要なキー操作の回数が増えるかもしれない。

このあたりの方針は日本語入力プログラムによってけっ
こう異なっていて、他社製品をカスタマイズして使い勝
手を同じにしたつもりでも、こういうところが違うとず
いぶん違和感があったりするものです。

> 私は文節操作や候補選択をマウスで行うことはないですね。
> あまりにもうっとうしく、何が好きでこんなことをしなくてはならないのかとい
> う感じです。

GUIベースの日本語入力プログラムでは同音語候補を縦
横に並べて同時に多数表示できるものがありますね。そ
ういう環境でJIS第二水準漢字などの単漢字変換をする
ときはマウスで選びたくなるかもしれません。:-)

また、500文字一括入力・変換で途中の文節に行きたい
ときに文節右移動キーなどでえっちらおっちら進むのも
大変そうではあります。:-) :-)

> 私が今この文章を打っているキーボードにはファンクションキーがないので、そ
> ういうのは困ります（笑）。

WXGだとローマ字入力に使わない英字キーを機能キーに
したり、Ctrl+X Ctrl+Qのような複数ストロークの並び
を機能キーに割り当てたりできるので、たいていの操作
はホームポジションから手を離さずに行えてすごく便利
なんですよね。

[saitoh akinori]

大阪大学の齊藤です。

Junn Ohta wrote:
> ワープロやら表計算やらしか使わん、というユーザーに
> はATOKのほうが使い勝手がよい面もあったわけで、単純
> に悪モノにできるわけでもありません。やはり思想の違
> いに尽きるのでしょう。

ATOK単体か一太郎か忘れましたが、入力をリターンで確定してからその
文字列が画面に現れるまでのどこかのタイミングで、先行キー入力をクリア
するという特性がありました。DOS時代だったとおもいます。

これで一太郎/ATOKが大嫌いになりました。

常時だったのか、ひらがなだけのもじれつを変換せずにリターンで確定させた
ときだけだったのかはもはや忘れてしまった。

齊藤明紀　sai...@ist.osaka-u.ac.jp

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<ajtmtf$jbj$1...@news2.u-ryukyu.ac.jp>で
hi...@eve.u-ryukyu.ac.jpさんは書きました。

> > で、最初の「ことえり」はけっこう高機能だったけど、サードバーティーの
> > IMの開発を促すためにオマケとしてはわざと機能を削ったという噂も……。
>
> これは噂じゃなくて、作者ご本人が書かれてたんですが、

そこには「マーケティング見地から、辞書の大幅な削減
が行われ」としか書かれていませんでした。辞書単語を
削っただけなら、辞書単語にヒットするかぎり同じ変換
結果になるはずですよね。

「ことえりはかしこくない」と書いていた人たちが、辞
書単語が少ないことに憤慨していたのか、それとも形態
素解析の稚拙さに憤慨していたのか、そのあたりは私に
はわからないのですが、単語が少ないのなら「ことえり
は単語を知らない」という表現になりそうな気もするし、
やっぱり形態素解析のレベルが低かったんじゃないかな
と思う...。

変換エンジンをかしこく作っておいて、あとから「わざ
と機能を削っ」ておバカにするのはむずかしそうですし、
技術者ならふつうはやらないでしょう。

[Junn Ohta]

fj.sys.mac,fj.comp.input-methodの記事<3D62CEC4...@ty2.fitweb.or.jp>で
yota...@ty2.fitweb.or.jpさんは書きました。

> 人間（日本人）が日本語を扱う場合は間違いなく意味を考慮しているわけで、き
> わめてまっとうな手段だと思います。（ｎ文節最長一致なんてことは頭の中でや
> っているのでしょうか？）

日本人って、どんなふうに日本語の文章を解析して理解
しているんですかね。このあたりは認知心理学で扱う話
なのかな?

自分自身を考えてみたのですが、寝ぼけた頭で他人の話
を聞いていると、誰がとか何がとかどうしたとか、そう
いう自立語の部分はあまり頭に入ってこなくて、「～が
～したんで～したんだよ。だから～したら～なふうにな
っちゃってさあ」というように、話の流れを作る“言い
回し”の部分だけが頭に残ることが多いようです。

だとすると、そういう“言い回し”をパターンマッチで
引っかけて、あとの部分はそこから前後に芋蔓式に認識
しているのではないかという気がします。

考えてみれば、知らないことばが出てきたとき、それが
名詞か動詞かは考えなくても判断できますもんね。n文
節最長一致でも最小コスト法でもさすがにそれは無理。

> 私はもともとはキーカスタマイズしやすかったために WX シリーズを使ってきた
> のですが、 ATOK などと比べて辞書の品詞分類が細かく分けられていた（という
> か、それをユーザーに見せていた）のが印象的でした。
> AI 変換が導入されたときも、ユーザー登録単語についても“動物、獣、鳥、虫、
> 魚…”のような属性登録が可能だったのですが、こういうのはやっぱり特異な例
> なんでしょうか？

特異な例...のようです。

カスタマイズについては、IBMのWritingHeadsも内部的
にはかなり自由度の高いカスタマイズが行えるだけのし
くみをもっていたんですが、それを行うためのユーティ
リティーが公開されませんでした。いろいろいじれたら
おもしろかったと思うのですけどね...。

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <ajv3pe$s7a$1...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) writes

>「ことえりはかしこくない」と書いていた人たちが、辞
>書単語が少ないことに憤慨していたのか、それとも形態
>素解析の稚拙さに憤慨していたのか、そのあたりは私に
>はわからないのですが、単語が少ないのなら「ことえり
>は単語を知らない」という表現になりそうな気もするし、
>やっぱり形態素解析のレベルが低かったんじゃないかな
>と思う...。

Mac OS X のβの頃のは、明らかに人工的に挿入された
エラーみたいなのがあったような気がします。辞書の
優先順位に確率的なエラーをいれるとかやっていたん
じゃないかなぁ。

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)