SKKプラス - SKK辞書処理の拡張手法
SKKFEP - Project SKKPlus

これまでのあらすじ

「……かりそめのシフト操作に酔いしれる『壁を越えし者ども』は
　真なる絶望をもたらす『コンヴァート・オヴ・オクリガノス』の『再構築』により
　互換性消滅の危機に瀕していた。しかし、むしろこれを進化の過程と歓迎するものもいた――」

ダウンロード

概要

「SKKプラス」とは

　SKK(シンプルかな漢字変換)による日本語入力方式では、未知の単語の入力時に積極的な学習を行うことにより、辞書学習と入力が融合した独自の学習機能を持っています。
　利用者の変換履歴がそのまま学習に繋がるという、単純かつ強力な機構であり、未知の入力に対しても適応力を持つ強力な機能となっています。
　しかしその反面、入力エラーや学習させたくない単語などの操作が行なわれた際にも全て学習されてしまい、見分けることができないという部分が弱点となっていました。
　なお、学習させたくない単語をSKKで扱うために、SKKGateではカプセル化などの工夫によって既に解決がなされており、次世代ではもはや大した問題ではなくなりつつあります。

　一方、この弱点がまだ十分に克服できていない部分が存在します。それが『送りがなを含む単語』です。
　SKKでは、ユーザの送りがな入力ミスによるゴミデータが意図せず大量に学習されてしまいます。
　その結果SKKでは、長期間使い込むほどユーザ辞書内に使用されないゴミデータが貯まっていってしまうという仕様上の欠陥が存在します。
　実はこちらについてもSKKGateで一部は対処済みです。不正な促音の連続などがある送りがなについては学習対象から除外する、などの工夫で解決しています。しかしながらこれだけでは完全な解決には至らず、もっと根本的な解決方法が必要とされていました。主に私が。

　このゴミデータは、具体的にはユーザ辞書の未使用語部分の肥大化という形で蓄積していきます。未使用語が増えても、見かけ上はほとんど問題にはなりません。しかし、ユーザ辞書のインポート・エクスポートなどの際、無駄なゴミデータごと情報をやりとりするというのはシンプルを信条とするSKK日本語入力方式の理念とはかけ離れています。何とかしてゴミデータを一掃したいというのがSKK利用者の悲願となっていました。主に私が。

　SKKFEPではこの普段は利用されないゴミデータの性質を逆手に取り、ゴミデータの中に入力補正のための情報を追加できるよう独自の拡張を施しました。さらに今回、補正情報を追加辞書の形で簡単に導入できるようにした上で、ユーザ辞書にはゴミが一切たまらないようにする根本的な解決策を導入しました。
　追加情報の記述は送りがなの変換候補にアスタリスクを追加するだけという極めてシンプルな手法であり、既存のSKKユーザ辞書フォーマットやその処理プロセスにほとんど変更を加えることなく実現可能です。
　もちろん、拡張情報のない従来の辞書を使うのであれば、SKKの変換ルールに一切影響はありません。

　簡単にまとめると、この拡張によって、以下を実現することができます。

　こうした新たな機能を、SKK本来の操作を自然に拡張する形で、かつ単純明解な実装で実現可能であることをここに実証します。

つまり、どういうことだってばよ？

　送りがなの入力ミスに対するSKKの挙動ってのは、要するにこういうことさ。

入力 KANI ……KANDE……KANZIte……KANGAEte ……
出力 噛に ……噛んで……噛んじて……噛んが得手……

　上の文字パターンを見てピンと来るのであればSKK使いであることは確定的に明らかと言えるでしょう。
　SKKを長年使ってきた愛好家であればあるほど、高速打鍵時のこうした誤入力の挙動がどれほどウザったらしいかはいちいち語るまでもないと思います。
　なんつーか長年使い続けてるとウザさを通り越して突き抜けてしまってもはや何が問題なのかすら考えることを放棄して

『体が、、、か。。ら・・だが求める・・・・・・・・・・・・・・・
　変換ミスという快楽を』

……とかパンチの効いたアヘ顔で語り出せるレベルになっているんじゃないでしょうか。主に私が。

　従来はこの手の誤変換のパターンが視界に入った瞬間にCTRL+Gを脊髄反射で押せるかどうかが、SKKへの適正第一歩だったといっても過言ではないでしょう。

　そして、今回のSKKプラスによる辞書拡張データを適用するとこうなります。

入力 KANI ……KANDE……KANZIte……KANGAEte ……
出力 蟹……噛んで……感じて……考えて ……

　つまり、極端な言いかたをするなら、SKKプラスの辞書が充実すれば、いつの日か誤入力に気づく必要すらない世界が来るかもしれません。
　そ‥それだよ！視聴者が求めているモノは！！SKKに欲しかったのはこういう操作系なんだよ。主に私が。
　もはやSKK使いにとって超人的な反射神経は必須ではないのですよヒューマン。だってオラは人間だから。
　互換性？知るかバカ！そんなことより拡張だ。これから毎日SKKプラスやろうぜ？

導入方法

　SKKFEP β0+11iから、劇的に導入が簡単になりました。
　SKKプラス辞書を辞書フォルダに放り込んで辞書を読み込ませるだけで即使えます。

　もしβ0+10i以前の旧バージョン(ユーザ辞書に制御データを書き込む古い方式)を使っていた場合は、アンインストーラskkplus.jsをダウンロードして実行し、古い設定を除去してから使ってください。

　以下は古い説明です。
　まず、SKKFEPのβ0+7i版以降をインストールしてください。
　次にブラウザでskkplus.jsをダウンロードして実行します。

　実行すると、追加辞書データが自動的にカレントディレクトリ上にダウンロードされ、その内容が現在の辞書(ユーザ辞書、メイン辞書)と融合されます。

　設定結果はユーザ辞書に即時反映され、再起動の必要はありません。
　なお、本拡張は送りがな以外の変換に関しては一切影響はありません。

　追加辞書データをユーザ辞書からアンインストールしたい場合は、skkplus.jsを引数 /c を指定して実行してください。インストールした拡張送りがな情報がすべて削除されます。こちらも結果は即時反映され、再起動の必要はありません。

　つまりいつでも設定・解除ができるってことさ！ならいつ設定(や)るか？今でしょ！

使いかた

　現在の追加辞書を導入することで、特に誤入力が多いと思われる2文字目または3文字目に小文字Nの打鍵が必要となる単語(シフト押しっぱなしで大文字で誤入力してしまうことが多い)を中心に補正情報が追加されます。

　以下に入力例とその補正結果を示します。

入力: KANiSPACE
出力: 蟹

入力: KANZite
出力: 感じて

　なお、送りがなの誤入力の判定に成功して入力補正が行なわれた場合、学習(ユーザ辞書の更新)は行なわれません。

え？たったこれだけ‥か？

　そう！そのとうり！！
　100バイトちょっとのバイナリで実装できる範囲なんて所詮はこの程度なのです。

落ちつけ……
大丈夫、こんなもんだよ
泣く程の事じゃねぇよ
最初から期待なんてしてなかったもん
こんなもんだよ！

　でも、たったこれだけのことですが、人によっては格段に操作性が向上したと感じる場合があるかもしれません。主に私が。
　入力補正にはSekkaみたいな進化の方向以外にも、SKKの枠組みの中だけでやれることがあると示したかっただけなんだ。

　辞書、設定スクリプトともにライセンスフリーの改造推奨品です。改良案などあればお気軽にご連絡を！

更新履歴

2013.11.09

　コア部分の処理が完成
　送りがな削除確定、自動送りがなキャンセラー、順次打鍵との処理区別など
　辞書は根性で手動設定。単語設定どころか単語順序ソートも何もかもが手動手動アンド手動でちょっと使いものにならんレベルだった模様。

2013.11.26

　SKKプラス爆誕！
　メンテナンス用スクリプト初版。

2013.11.30

　SKKプラスをさらに拡張したニューSKKプラス爆誕！
　辞書プロセスの改良による送りがなのワイルドカード拡張記述に対応。
　ワイルドカードマッチの簡易表記を追加。全てワイルドカードのケースではユーザ辞書に無駄な送りがなを追加しないようにしてメモリ占有量を削減。
　拡張スクリプト側の送りがなチェックで登録できないケースを回避するよう改良。
　アップデートで正確に内容が反映できるよう、必ず古い内容を消してから再設定するよう改良。

2016.02.14

　あれから3年――

　SKKGateの仕様変更(改行対応)に追随。
　設定ツールを起動するたびに、補正データのインストール←→アンインストールを繰り返すことで、簡単に導入と解除ができるよう改良。

2017.01.03

　そして1年の歳月が過ぎた――

　新式辞書フォーマットに対応。ユーザ辞書を使わず辞書を1つ追加するだけで全ての機能を実現できるようになり、さらにお手軽になって新登場！

技術情報

　以下は古い説明です。

オリジナル辞書の作りかた

　ダウンロードしたskkplus.jsと同じ場所に送りがな拡張辞書(以下、拡張辞書)を置いておくと、そちらを使って登録が行われます。この拡張辞書は利用者が自由に作成可能です。
　ひとまず拡張辞書をダウンロードし、メモ帳などの適当なエディタを使って自由に編集すればオーケーです。
　辞書内容を更新したら、skkplus.jsを実行するだけでアップデート完了。
　ね、簡単でしょう？(very easy)

　拡張辞書の内容はJavaScriptの辞書設定スクリプトを経由してSKKFEPの辞書プロセスにインストール・アンインストールされます。
　インストール後はユーザ辞書に情報が反映されるため、一度導入を行えば設定は維持されます。

　各行には単語(日本語の文字列)を2つ以上、任意の個数のタブまたは空白で区切って記述します。
　なお、この拡張はあくまで「送りあり」の変換の候補に対してのみ機能します。送りがなのない名詞などの候補には何の影響もありません。
　送りがなのない通常の候補について、はアスタリスクの有無に関係なく、これまでのSKKと同じ動作(その文字を出力するだけ)となります。

送りがな補正辞書の記述フォーマットについて

　SKKプラスが使う送りがな補正辞書のフォーマットは、通常のSKK辞書とは記述方法が異なるので注意してください。
※開発版につき、フォーマットは予告なく変更される可能性があります。

　以下に例を記します。
かn 噛;マ行五段活用/んで 兼ね …記述形式A
かn 感*/んじ 関*んす 関*んし …記述形式B
かn *に んど んが …記述形式C
ろn * …記述形式D

1. 最初の単語は辞書の見出し部分です。末尾に送りがなのアルファベットを含みます。
2. 次の単語から、変換候補を送りがなつきで記述します。

　1行あたり、1の見出しは1つのみ、2の候補部分は複数記述できます。
　送りがなはひらがなで記述します。
　候補部分と送りがな部分との区切り文字にはスラッシュが利用可能です。スラッシュは省略可能です。
　候補部分に「*」を含む文字を登録すると、送りがな補正拡張機能が有効になります。記述形式の詳細については以下を参考にしてください。

記述形式A
　候補の文字列にアスタリスクが含まれていない場合は、従来通り普通に漢字変換が行われます。
注意: 辞書の肥大化を防ぐため、同音の候補が複数ある場合は、なるべく代表的なものを先頭に1つだけ書くようにしてください。(記述形式Dが含まれない場合のみ)
注意: 辞書の肥大化を防ぐため、同じ漢字で異なる送りがなのものが複数ある場合、それが1種類しかない場合は代表的なものを1つだけ書くようにしてください。(記述形式Dが含まれない場合のみ)

記述形式B
　候補の文字列の末尾にアスタリスクがある場合、アスタリスクの個数分だけ送りがなの文字が先頭から削除(補正)されて確定されます。補正時に学習は行なわれません。
例: 「▽か*んじ」の誤入力時に、「感じ」を出力したい場合、"かn 感*んじ"と記述します。

記述形式C
　2の候補の文字列の先頭にアスタリスクがある場合、入力がマッチした瞬間に送りがな変換状態がキャンセルされ、単語編集状態に即座に復帰(補正)します。補正時に学習は行なわれません。
　なお、候補部分が「*」になる場合、アスタリスクの記述を省略して送りがなのみで記述することができます。たとえば「*/んど」「*んど」「んど」の記述はどれも同じ内容となります。
例: 「▽か*んが」の誤入力時に、続けて「▽かんが*え」「▽かんがっき」などを変換したい場合に備えて自動的に「▽かんが」に戻したい場合、"かn んが"と記述します。

記述形式D
　アスタリスク1文字のみを書いた場合、送りがなが他のものとマッチしなかった場合、記述形式Cと同様の動作を行ないます。
　記述形式Dを使う場合は、記述形式A〜Cで全ての送りがなのパターンが記述されている必要があります。この意味がよくわからないうちは、「ピーキーすぎてお前にゃ無理だよ！」と言われるのがオチですので使わないでください。この形式は「全ての送りがな」にマッチするため利用には細心の注意が必要ですが、補正情報のデータ量を極端に小さくすることができる可能性を秘めています。うまく使いこなせるようになれば非常に強力です。

その他、表記の詳細に関して
候補部分と送りがな部分との分割のスラッシュは、日本人ならこんなものなくても十分判別できるし、そのほうが見やすいし書きやすいと思われるので、省略も可能となっています。むしろ積極的に省略すべき。
候補の後にセミコロンで区切って注釈をつけることも可能です。
利用頻度が低くてほぼ未使用となるのが明らかだけど、どうしても記述しておきたい候補や、考慮はしたけど万人が入れる必要はないと判断された候補については、候補の先頭や末尾に半角でクエスチョンマークをつけておくことで登録時にスキップ(単体コメント扱い)されます。必要な人が自分でこのマークを消して有効化して使ってもらう、などの使用法を想定しています。
注釈を書かず、かつアスタリスクのない候補の場合は、ユーザ辞書あるいはL辞書に存在する注釈と同じものが自動的に設定されます。いちいち注釈をL辞書からコピーする必要はありません。注釈を直したい場合はL辞書側の編集に注力するべきとの考えからこのようにしてあります。
注釈を書かず、かつアスタリスクつきの候補の場合は、自動的に「入力補正」の文字が注釈として追加されます。
セミコロンが先頭にある単語から行末まではコメント扱いとなり、内容は無視されます。

設定スクリプトの動作概要

　SKKGateを使ってサクっと動かしてます。詳細はskkplus.jsのソースをそのまま見るべし。

設定時

定義ファイルを解析し以下を実行
1. 各行の内容を以下の3種類に分類する
A. 通常の候補
B. 末尾にアスタリスクを持つ候補
C. 先頭にアスタリスクを持つ候補
※BとCには注釈文字列(デフォルトでは"入力補正")を付加する
2. ユーザ辞書に以下の順序で登録(学習)を行う
C → B → A

消去時

ユーザ辞書を解析し以下を実行
1. 各行の送りがなを(テキトーに)取得
2. アスタリスクを含む送りがな候補をすべて削除

フロントエンド側から手動で拡張辞書内容に触る場合の操作方法

　入力補正が発動した場合、学習(辞書の更新)は行なわれません。学習を行なって辞書の順序が崩れてしまうと、以後の動的補完や入力補正が意図しない結果になるためです。この仕様の都合上、既存の入力補正情報を流用した確定操作を行なった場合に学習は行なわれず、辞書にゴミが貯まらないようになっています。このため、辞書登録されていない誤入力のパターンを新規登録する場合は変換・確定操作のかわりに単語登録モードを経由する(新規登録または註釈編集を行う)必要があります。

　入力補正による編集キャンセル(アスタリスクが先頭にある送りがな候補の変換)が発生すると変換状態を飛び越えて編集状態に戻ってしまうため、一見するとこのままでは単語削除の操作ができないかのように思えますが、入力補正機能はシフトキー(大文字アルファベット)による送りがな入力時のみ動作するため、順次打鍵による送りがな入力(例えばKa;ngae等)を行った際には入力補正は発生しません。順次打鍵による変換をまず行い、そこで削除操作を行うことで個別のエントリの削除が可能です。

　辞書の順序が変わる(*のエントリが先頭に回ってしまう)と、通常の操作への影響が大きいため、この方法は最後の手段、おまけレベルの話と思っておいてください。
　そもそも、そこまでして手動操作したい奴なんて、まずいないだろうし。大丈夫だ、問題ない。
　基本はインストーラを使って辞書を更新するほうが管理も楽だし辞書順序も自動ソートだし格段に便利かと。……初期段階ではこんなスクリプトがなかったので全部手動で順序設定をやってたんだぜ……想像を絶する面倒臭さだったんだぜ……

ユーザ辞書フォーマットの拡張

　ユーザ辞書の仕組みそのものは一切変更なし。
　どんな感じになっているのかは、自分の目で確かみてみろ！完

SKKFEPにおける実装 - フロントエンド側の機能拡張

　SKKプラスにおける自動補正の処理の流れを以下に記します。

1. 送りありの漢字変換を行なう
2. 変換結果の第一候補の先頭がアスタリスクだった場合、確定せずにCTRL+Gによるキャンセル処理を実行し、通常処理へ復帰
3. 変換候補の末尾がアスタリスクだった場合、アスタリスクの文字数と同じ文字数だけ送りがな部分を先頭から削除して確定し、学習は行なわずに通常処理へ復帰

　ね、簡単でしょう？(very easy)

他のSKKクローンでも実装しやすくするための配慮

　コントロールコードを混ぜるとか、Emacs以外ではまともにデコードできないlisp命令を使うとか、絶対に許されざるよ。
　というわけで他のSKKクローンのラインエディタでも簡単に編集できるアスタリスク1文字にした。
　これなら辞書を何も考えずにエクスポートしちゃって、この機能が使えない別のクローン上でも最低限ユーザ辞書をサクっと葬り去ることができるので安心である。
　あと、送りがなの部分のみの拡張ってのが超重要。送りなしの辞書部分には一切影響がないように作ってあります。

ちくわ大明神

　ふー、びっくりした。ジャンプ中は無敵。当然だよね。
　例によってドキュメント書くのが面倒になったので以下書き途中

送りがなの入力補正

チャット等の超高速打鍵時やネトゲ操作中の誤入力発生率の高さ(体感)

　自分のSKKの操作パターンを調べていたら、なぜか送りがなつき単語の変換をよく失敗していることに気付いた。

そもそも高速打鍵時には何が起きていたのか？

　送りがなつきの単語がなぜか変換できない。
　何度もキャンセルしてる。
　失敗するパターンには共通点が多い。
　2文字目か3文字目にNのキーが含まれることが多い (蟹、姉、感じ、関し、等)
　なんとかしたいけどどうしたらいいの？
　なんとかした

　パターンに規則性があるので自動生成してもいいような気もするんだけど、補正情報を作りすぎるとゴミの塊みたいになるから人間が失敗しやすいパターンだけをうまく抽出したほうが美しいんじゃないかな〜と思って手動作成にしてる。

高速打鍵時の親指・小指の挙動の推測

　たぶんシフトキーを離すタイミングがちょっとずれるんじゃネーノ？
　特定のシーケンスの時とか思考状況とか、ホームポジションからの手のずれとかによってシフトキーを離すタイミングが微妙に遅れる現象が多発することが、まれによくある。

入力ミスが起きた時、今まではどんな操作をしていた？

　必死で脳死CTRL+Gを連打するだけの簡単なお仕事

入力エラーの対抗策として今できること

SKKの枠組みの中で実現するにはどうすればよいか？

ユーザ辞書フォーマットの拡張

SKKFEPにおける実装 - フロントエンド側の機能拡張

他のSKKクローンでも実装しやすくするための配慮

表示が見づらいのはなんでだぜ？

　補正直前の表示は、なんかやたら見づらいと感じると思うが、これは狙ってあえてやっている。「入力ミスが発生した」「このまま進めても大丈夫」のどちらの見た目を優先するか、これは永遠の課題だと思うけど、何もかもが全自動じゃねーんだぜ？っていう道具側の自己主張が必要っていうこだわりだと思いねぇ！

非正則の入力も補正しちゃうゾﾓﾙｧ？

　ヲ？

辞書データを作成する方へ

　今回使った「N」の入力でシフトが遅れるってのはたぶんSKK利用者全員に該当する誤入力パターンじゃないと思われるので、他の誤入力パターンについての情報や考察があればぜひ教えてｸﾚｸﾚｰﾁｮ

この手法の限界点と今後の課題

　「誤入力に気づく必要すらない」とかアホ抜かせ。このパターンの時、ぜんぜん解決できねーだろ！と得意満面のミサワ顔の皆さんこんにちはこんにちは。その通りです。
　そこまで見えてきたなら、その先の一手を一緒に考えようぜ？

　例えば……

変換前に入力していたひらがな文字列を用いた再変換・変換精度向上
送りがな変換後、暗黙の確定の文字情報を用いた再変換・変換精度向上
送りがなの暗黙の確定後、スペース入力でオートマチック物理アンドゥ
物理アンドゥ情報を多重に持たせて連文節変換と同じ感覚で複数文節を後から再変換

　SKKの重力に魂を引かれた連中のことなんて気にすんな。枠に囚われない限り、やれることなんてまだいくらでもあるんだぜ！

ハードボイルド編

SKKのソフトウェア側を一切弄らずに、ハードウェア側のみで解決したい！ ―― SKKキーボードへの道

　シフトキーを小指で押すという行為。これはSKKの本質を理解してない連中から散々馬鹿にされる鉄板ネタになっているだけあって、押しづらいという意見自体は間違っていないと思う。だからシフトは親指で押すデザインにするべきというのは自然な流れのはず。
　SandSはそのコンセプト通りの実装なわけだけど、親指で押すのはいいけどスペースバーと共用にするとか、そういう妥協がまずいかん。
　フフ・・・・・・　へただなあSKKくん　へたっぴさ・・・・・・・・！
　欲望の解放のさせ方がへた・・・・　SKKくんが本当に欲しいのは・・・
　こっち（独立したシフトキー）・・・・・・！

　親指シフトの配列自体のコンセプトは素晴らしいと思うけど、スペースが横にあって左親指で押せないとかSKK使いからしたら悪夢以外の何者でもないでしょ。既存の形状に迎合する必要なんて微塵もない。

　ならばこれを、こうして、こうじゃ！
　スペースバーは今のまま、その真下に、少しだけスペースバーよりも高さを低くしたシフトキーを1つか2つ追加するだけ、これだけでいい。これで最強のSKKキーボードになるはず。
　これによって、既存のスペースバーの打鍵感覚にも一切影響を与えずに、送りがなや通常変換の区切りの操作性が格段に向上する。高速打鍵時における、シフトキーの「押す」「離す」操作の遅れや通常キーとの打鍵順序の間違いを物理的に減らすことにより、ソフトウェアでの軟派な補正なんて金輪際いらなくなるはずなんだ。
　そうそう、高さを少しだけ低くするってのが超重要な。スペースキーを押し込んだ時の誤爆を防ぐことができるかどうかが全てといっていい。
親指シフトはこの部分がまるでなってない。そのせいで親指シフトの中央部分がデッドスペースになってしまっている。どうせ指が永遠に置かれることのない場所なら、利用頻度の低いボタンでもそこに置いとくべきなんじゃね？
ここは、自然に押せる場所ではないのは確かだけど、ゲームとかだとでかいボタンを連打したいじゃん？その時誤入力が発生したら嫌じゃん？だからスペースキーの場所下の位置のボタンの高さってのは本当に大事なはず。
　キーボード屋はこういうった形が他と違う部品を混ぜるのは(カネがかかるし)なるべくやりたくないってのはわかる。だったら自分で作るしかねえ！
　ハードな人誰か手伝ってくれ。REALFORCEのスペースバーの下をノコギリで切り取って2つキーをつけたいんじゃよ！

　えーと、ノートPC？
　ノートPCだと下に部品があるから高さ調節は厳しい？できるかな？じゃない。やるんだよ。いつの日か部品は小さく作れるようになる時代が必ず来るんだから今は部品ごと穴あけちまえ。構わん、やれ。
　あと、ノートPCで右シフトキーの横にカーソル上があるクソ配列を作った奴は腹を切るべきなんじゃないかな？カーソル部分は別部品にして組み合わせてくれ頼む。
　それから、タッチパッドをつけるなら、キーボードから十分に離すのが大前提だけど、上側の縁には触覚でわかるように凸か凹の線をつけようぜ？な？

　一方、ロシアは変換と無変換キーの部分をシフトキーにした。

　あーとにかくSHIFT/CTRL/ALTをスペースの左右と下に配置して親指で押したいんだよなあ……
　結局、SKKとか全然関係ない気がするけど終わり

co (Twitter♺)

inserted by FC2 system