ハイブリッド月配列の追記

配列

現状、配列作者として避けて通れないベンチマークは月2-263と新下駄かと思いますが、これらをご存じのものとして、配列の性能向上に使えそうなネタを解説します。


ハイブリッド月配列は月2-263配列程度の習熟難易度で新下駄配列程度の効率を達成した前置シフト配列です。わりと自信作です。


【シフトキーと句読点の共有】
『キー共有』と呼んでいますが、この、2打目の内容によって、1打目の文字をキャンセルして他のものに書き換えるというテクニックです。
ここでは、シフトキーと句読点の共有について説明します。
ハイブリッド月では、句読点を打つと句読点が出力されますが、さらに他のキーを打つと句読点を削除されて、シフト面のカナが出力されます。これによって、シフトキーと句読点を同じキーに配置でき、ハイブリッド月は表面のキーを3キー分節約できています。


新下駄の打鍵効率の源泉はどこかというと、表面にシフトキーが無いので、中段中指の特等席に「か」「い」の最重要文字を配置できることだと理解しています。表面が2キー多いと言い換えても良いです。これによって3%ほど打鍵効率に差が出ると勝手に見積もっています。


かといって新下駄の同時押しは誤打鍵のもとであったり実装を選ぶという短所がありますから、できれば避けたいという要求も、未だに月系配列をいじっている人々が多いことからわかります。


私個人としては、同時打鍵のために一瞬2倍の力が必要になるのが苦手で断念しました。


前置シフトで、シフトキーが邪魔問題を(ある程度)克服するには、やはりシフトキーに何らかの方法で文字キーを割り当てる必要がありまして、例えばSandS的な手法も考えられます。しかし、SandSでは結局同時押しと同じです。


そこで、いろいろ考えた結果、シフトキーは句読点と兼用させても問題ないというところに思い至りました。句読点打った後は変換なり、Enter押してそのまま広がなのまま確定すること通常かと思います。ですので、その後に他のカナを打ったときには句読点を取り消しても問題が無いはずです。


これは、わりと便利な着想でして月2-263のシフトキーに句読点を配置して、元々の句読点の場所に適当な文字をおいても月2-263の効率は直ちに改善します。


この『キー共有』ですが、2打目の内容によって、1打目の文字をキャンセルして他のものに書き換えるというテクニックはいろいろ便利です。


【清濁分置と行段ハイブリッド】
ハイブリッド月は清濁分置ではありますが行段ハイブリッドによって簡単に使いこなせるようになっています。特に、拗音シフトも行段になっていますので、複雑な配列にありがちななかなか最後のひっかかりが取れないと言うことがありません。


清濁分置を選んだ理由は、清濁分置の方が行段ハイブリッドと相性が良いからです。ハイブリッド月ではカナのBZP行とカタカナ語向けのFVWL行を行段にしているわけですが、BZP行はどれも濁音半濁音で、清濁同置なら別に行段ハイブリッドを導入する必要がなくなります。


だったら、清濁同置でも良いような気がしますが、清濁同置では過去に作ったabj配列などのパフォーマンスを超えられそうも無く、パフォーマンスでは清濁分置が有利なのは明らかですので、清濁分置としました。


【習熟難易度】
配列の習熟難易度は諸説あるわけですが、個人的には、例えば繰り返し(例えば100回)打鍵したキーは指が覚えられる説を信じています。
単に難易度がキーの個数に比例するのであれば、清濁同置なら55キー(45+10パぁ行)と清濁分置なら75キー(45+20+10パぁ行)、拗音シフトフル装備で106(75+21拗音+15FVW行)キーで拗音シフトフル装備でも清濁同置の倍は習熟に時間がかからないはずですが、とてもとてももっと時間がかかるのは皆さんの実感しているところかと思います。
これは使用頻度の低いキーを、使う機会が少ないだけになかなか覚えられないからです。実際のところは、出現頻度の低いキーもふくめて全部100打鍵して、全キーフルコンプして初めて習得完了と言ったところかと思います。また、割と清濁同置配列でもパぁ行が僻地に適当に並べられているケースが多く、パぁ行を覚えるのにやたらめったら時間のかかることもあります。
ですので、出現頻度の低いキーを行段にして覚えやすくすると言うことにはキー数の削減以上にメリットがあると信じています。
なお、ハイブリッド月のキー個数は64(45+2パぁ行+10(がだ行)+2(ばざ)行+3FVW行+ぃぇ)です。


そうですね。月2-263と同等というのは少し大げさかもしれませんが、ちょっと覚える気がしない「ウィ」とかもハイブリッド月では簡単に習得できますので悪くないと思います。


【拗音シフト】
ハイブリッド月は拗音シフトをつくるのに、この『キー共有』と『ハイブリッド』の両方のテクニックを併用しています。
拗音は出現頻度が2.5%程度とたかがしれていますので、従来は拗音シフトを導入しても手間の割にあまり効果が無いというのが実情かと思います。
まずは、3打叩いていいなら特に難しい工夫をしなくてもたいていの配列で拗音は打てますので、2打で拗音が打てることが拗音シフト導入の条件になります。入力の流れを阻害しないためにも1モーラ2打鍵以内というのはそれなりに効果があると思います。
この点、新下駄はシフトキーを増やすことによって2打拗音を達成しています。
しかし、月系配列では拗音シフトを作ると、独立したシフトキーをわざわざもうける必要があって、表面にそんな余裕がないのが通常ですので、今までの月系配列での拗音シフトはいまいちな結果になってきたかと思います。


さて、ハイブリッド月では『キー共有』を利用した後置シフトで2打で拗音が打てるようになっています。
一打目は、表面シフト面にかかわらず、拗音の起点になるカナを叩いて、それから「ゃゅょ」のキーを叩くことになります。「ちゃ」で言えば、「う(ち)(ぶ)(ず)」キーを叩いてから「ゃ」を叩くと「ちゃ」が出力されます。「う-ち-ぶ-ず」の中で「ゃゅょ」をつなげられるのが「ち」だけですので、これが選択される形になります。


このテクニックによって、拗音シフトを使用しているという感覚を持たずに拗音が打てますので、使用頻度の低い拗音も気持ちよく打鍵できるかと思います。
また、「ちぇ」「フィ」などにも対応するために「ゃゅょ」キーの他に「ぃぇ」キーを設けました。


ただ、この後置シフト拗音は、拗音の起点になる「き」なり「し」なりイ段のカナを表面シフト面通して一つのキーに一つしか配置できないという制約があります。実際には、普通の拗音の他にも「ヴァ」「ウァ」「ファ」と単体での「ぁ」ついでに「デュ」の入力にも対応する必要があるので、イ段はかなり注意を払って配置することになりました。
また、これにより『キー共有』を利用した拗音シフトは「き」「ぎ」を同じキーに配置できないので清濁分置になります。
後置シフトのメリットは、2打で拗音が打てると言うほかにも、行段入力になるので、拗音シフトのキー配置を覚える必要が無いと言うところにもあります。確かに、たいていの配列では拗音が規則正しく並んではいるのですが、それでも記憶コストはかかりますし、さらには指がスラスラ打てるようになるには、やはりそれなりの修練が必要になるからです。


ところで、GZP行は「あいうえお」の位置と行段の母音「AIUEO」を同じキーにしているのですが、FVWL行は違います。FVWL行の母音は「ゃぃゅぇょ」になっていて、ちょっとわかりにくいです。拗音との関係で「ふぁふゅふぉ」は割とすんなりと打鍵できるかと思いますが「ふぇふぃ」はちょっと戸惑うかも知れません。
これは、まずは「ふぇ」について「ぇ」に専用キーをもうけています。導入の経緯は「ちぇ」を打つための「ぇ」キーが「ゃゅょ」以外にどうしても必要で、ここで「ぇ」キーがあるなら「ふぇ」も「ヴェ」も同じキーに割り当てたところから来ています。なら「ぃ」キーも作ってしまおうと。微妙なところですが、行段的にはそんなに違和感はないかと思います。


この拗音の配置は同時押し系でも使えますので、どなたか試されてみるといいかと思います。
ただ、打鍵効率自体は1.5%くらいしか改善しませんので、打鍵効率のためと言うよりはスムーズな打鍵と覚えやすさのためと考えた方が良いと思います。


【長押し】
割とどうでも良い機能ですが、いわゆる下段から上段への跳躍などの悪運指に対応するために長押しで頻出2gramが出るようにしてあります。
例えば「の(o)」長押し→「ので(o.)」といった感じです。
まぁ、最初はクールなアイデアだと思ったのですが、キーの長押しって思ったよりも指に負担がかかるので結局はあまり活用していません。この辺はもう少し突き詰めても良いのですが、移植も大変ですので、ハイブリッド月の公式？仕様には含めないこととしました。
nodokaファイルには長押しがほとんどのキーに割り当ててあるのではありますがね。


【変換・無変換キー】
当初は変換・無変換キーを使う計画だったのですが、結局、使わないことにしました。
これは、変換・無変換キーはBSやCtrlその他のファンクションに使う人が多いからと、私自身もそうしているからです。
最初は、変換・無変換キーに「い」「ん」を割り当てるバージョンも作りました。確かに「い」「ん」につながる2gramが多いだけに配列設計が大いに楽になるのですが、日常的には連打するほどは私の親指が強くないことがわかりました。また、「○い」「○ん」と親指に収束する流れから、スペースを押すのもなかなかしっくりきませんでした。個人的には小梅配列も一度試しているのですが、そのときも親指に負荷がかかりすぎて挫折しましたので、思い切って変換・無変換キーはカナには使わないこととしました。


ただ、変換・無変換キーではないのですが「ー」だけは「カタカナひらがな」キーで出るようにしています。これは「ー」はやはりちょっと特別な打鍵感覚が欲しかったからです。なお「ー」のシフト面には「〜」が入っています。


【表面の配置について】
これは従来からあるキー配置のセオリーに従っているのでそれほど特別なことはないのですが、キーごとの打ちにくさ評価は以下のように重み付けをしていて、人差し指は下段、それ以外は上段に寄らせる、ややハの字構えに適した分布にしています。

小 薬 中 人 人 _ 人 人 中 薬 小 小
15 15 12 15 20 _ 25 15 12 15 15 20
12 11 10 10 15 _ 15 10 10 11 12 20
20 20 15 12 25 _ 15 12 15 20 20 25
9.8% 8.7% 16.1% 15.3% _ _ _ 16.5% 15.4% 9.9% 7.8%

また、その関係で、同段アルペジオの他に人差し指中段→中指上段(F→E)のような流れを比較的好意的に判断することとしました。これによって頻出2モーラを叩きながら自然と上下段に移行できるようにしています。


【実用性】
実用性については、概ね配列が固まってから3年間使いこんで大きな不満点はありませんので、十分実用的かと思っています。特に理由が無い限りは普段の日本語入力は全てハイブリッド月で行っています。
一応ですが、私はプログラマ兼特許屋ですので、特許文書をこれでバリバリ打ち込んでいます。また、PBWと言うマイナーな趣味でラノベもどきの文章も打っています。総計すると三年で100万字は打っているはずですので、まぁ、十分にコンバットプルーフはされていると考えています。
いわゆる、脳に対する負荷は従来のAZIKなどの変則行段系と比べて軽いと実感しており、まさにしゃべるように打てていますので特に問題ないと思います。
(なお、私はローマ字入力は特に脳に負担と考えてはいません)


【そのほか】
『キー共有』ですが、現在は「う、BS、ち、ょ」的な出力で実装しているのですが、BSが一部のソフトを混乱させるようです。そこで、「う」を押した時点では何も出力せず、スペースなりEnterなり矢印なりカナ以外のキーを押したときに「う」が確定するような実装の方が、BSを出力しないで良いのではないのかと思っています。キーカスタマイズソフト次第ではあるのですけれどもね。


ところでハイブリッド月配列ってネーミングはどうかと思うんですよね。
最初は半月配列とかでいいかなと思っていたのですが、あまり風流ではないので、決まらないでいます。

ハイブリッド月配列

配列

ハイブリッド月配列は、月配列をベースに行段の要素と、キー共有機構を追加したハイブリッド配列です。
キー共有等、他の配列ではあまり見られないアイデアが組み込まれていますが、覚えるのは比較的簡単な方です。
スペック的はカナ一字を出すのに必要な平均打鍵数は1.25とトップクラスと言って良いかと思います。


【キー共有】
キー共有は、複数のキーの意味を一つのキーに共有させるものです。例えば「、(d)」はいわゆる左シフトを兼ねています。これは「、」を入力した後は通常はスペースなどを押して変換モードに移行するところであるので、続けてカナを打つ場合には、他の役割に代えることが出来るからです。
同様に、例えば「う」を打った後には「ゃゅょ」を打つことは無いので、「うゃ」という入力には「ちゃ」と言う別の意味を割り当てています。
一見かなり、複雑なようですが、「ち」は「右シフト+う」と配置していますので「ちゃ」は「右シフト」を省略しただけという形になります。もちろん「右シフト+う+ゃ」でも「ちゃ」は出ます。

このキー共有の導入によって、いままで月系配列では、どうしても指の上下移動が多かったり、拗音の入力が多打鍵になったり奇っ怪な配置になったりしていた問題を解消しています。
ハイブリッド月配列では「ふぇ(ey)」「ヴァ(r/)」なども拗音系はすべて2打で出るようになっております。


【ハイブリッド】
カナ配列と行段配列の両方の特徴を有しているハイブリッド配列です。
行段的キー配置は特に使用頻度の低いBZP行に適用してあり、これによって清濁異置を覚えるときの難所を簡単にクリアできるようになっています。また、キー共有との組み合わせも含めると「BZP」→「あいうえおゃぃゅぇょ」がすべて行段配置となっていますので簡単に指が覚えてくれます。もちろん「あいうえおゃぃゅぇょ」は単体で「あいうえおゃぃゅぇょ」を打つときと同じキーです。また「FVWL」については「ゃぃゅぇょ」を第二の「AIUEO」代わりに入力する形になっています。ちょっと微妙なところですが、試してみれば案外簡単に指が覚えてくれます。なお、「ぱ」はP段で最頻ですのでabjシステムで優先されるようになっています。これによって従来のかな配列を覚えるときの難所である「ぱ行」「ぁ行」を簡単に習得できます。

【アルペジオ打鍵】
表面の配列は「てた」「った」「なに」「なの」「です」等の頻出2モーラが同段片手のいわゆるアルペジオ打鍵で入力できるように注意が払ってあり、手の上下移動が最小となるように配慮してあります。また「した」「して」も「FE」「FW」とやや、手をハの字に置いたときに打ちやすく配置しています。その代わりに指が届きにくい「y」には「ぇ」を配置するなどしています。


【その他】
その他、「づぢ」は例外として「づ(k3)」「ぢ(d8)」の打鍵で出るようになっています。それほど深い意味は無いのですが、他の月配列と比べて中指の負担が軽めなのでこのようにしました。
また、「ー」は「カタカナひらがな」キーでも出せるようになっています。


実用試験としておおよそ現在の形に固まってから3年間、仕事の特許文書と趣味のラノベ風文章の入力で使い続けて納得のいくものになっています。よろしかったら試してみてください。

そうそう三点リーダ「……」はEsc。「――」ダーシュはShift+Escで出るようになっています。なんでEscなのですかね。


【ダウンロード】
https://drive.google.com/file/d/0Bwr_MDdxot9tcjB4VC12ejUyb1k/view?usp=sharing
nodokaファイルですが、拡張子を変えればmayuでも動くはずです(中のインクルード文の拡張子も)。ひょっとしたらmayuにはないオプションなどを無効にする必要があるかもしれません。
このスクリプトでは「か」を長押しすると「から」が出るとか長押し系の仕掛けがいくつか施されていますが、結局あまり使わないのでどうしたものかと思っています。そのうちAutoHotkeyなどもう少しメジャーなキーバインドソフトに移植しようかなと思っていたりもします。


【開発経緯】
原理的には最強そうな気配のしたabj配列ですが、abj配列は母音を補う必要がある場合と無い場合の切り分けを脳内で行うのが非常に難しく、どうしてもすらすら打てるようにはなりませんでした。ですので、常用するのを断念しました。母音省略システムはやはり無理があったのだと思います。しかし、abj配列の作成からはよいアイデアもいくつかうまれました。

キー共有は、abj配列を作った頃に導入したものですが、思いの外効果的でしたので、これを使って月2-263を改良できないかというのが最初です。清濁分置は入力効率を上げるのには不可欠であるのと、ハイブリッドと相性が良いので導入しました。

昔に作ったハイブリッド配列は、行段がベースで、頻出カナは専用のキーを置くという発想でしたが、これではどうしても重複によりキーに無駄が出てしまうと言う欠点がありました。一方、今回のハイブリッド月は頻度の低い行に限って行段入力とすることによってキーの無駄を無くす構造になっています。

当初はシフトは「、。」の二つのみで、さらに無変換、変換キーに「いん」を割り当てていました。これも無変換、変換キーに字を割り当てと指のつながりが格段に良くなる上に打鍵効率も3%程度向上することがことがわかっていたからです。しかし、「いん」は「たい」「たん」などと打鍵の流れの後に入ることが多く、また、続いてスペースを押すことが多いことからなかなかしっくりとこなくあまりうまくいきませんでした。
それと、無変換、変換キーは他の用途にも使いたく、カナ入力には使いたくないというのがありました。
そこで、原則として三段のみを使う月配列をベースに作業を始めました。打鍵効率的にはシフトは「、。」の二つのみの方が優秀でしたが、シフト面の同手キーを出来るだけ排除したかったので、考えた末にシフトは三つにしました。無変換、変換キーの不使用と3シフトにしたことにより打鍵効率は5%ほど悪化しています。

3シフトにしたもう一つの理由は、「BZP+A」行の行段入力の起点が全部で4つ必要で、頻度の低いPは僻地に置くとしても「BZA」の3つはそれなりの場所に置く必要があったからです。

その制約の中でも、打鍵効率でabjを越えるのにいろいろ考えまして、拗音についてもキー共有が有効だということに思い至りました。これは、打鍵をスムーズにするためにも、１モーラ３打鍵は出来るだけ排除したかったので一つのブレークスルーでした。ただ、「ゃゅょ」の配置はだいぶ悩みました。

それからほぼ1年ほどかけて配置を微調整しました。拗音についてもキー共有を使っているので配置の自由度は割と少ないので、表面と拗音を発動させるイ段の配置には苦心しました。特に打鍵効率の観点からは「き」は表に配置した方が良いのですが、なかなかこれというポジションが見つからず結局シフト面に送ることになりました。

それから、2年ほど使ってから「ぃ」を8に送りました。よく考えればシフト面は数字キーを使っても良いので、それを考えたら2シフト配列にもできそうです。しかし、2年使いこんでだいぶ手になじんだことと、2シフト配列とすると「き」を表面に出すことになりキー共有の利点が減ること、中指の負担が重すぎる等を勘定して見送ることとしました。


【スペック】
なんとなく作ったスペック表は以下の通りです。

打鍵効率 負荷ポイント
通常ローマ字 1.77 2476
NICOLA 1.43 1806
月2-263 1.31 1803
飛鳥 1.44 1697
小梅(私家版) 1.35 1656
新下駄 1.27 1535
qwerty_hybrid注 1.28 1768
abj注 1.29 1595
ハイブリッド月 1.25 1601

(qwerty_hybridとabjは母音の補足に必要な打鍵が計算に入っていないから5%程悪化するはず)
データは今まで通り小梅配列さんのところの10万字サンプル(英字抜き)で集計しています。
この負荷ポイントというのは下の図のように、押しにくいキーに負荷計数を乗じたものです。人気の高い新下駄は本当に優秀で、私の直感に即した重み付けでも相当な高得点をたたき出します。
このハイブリッド月の負荷ポイントが劣るのは、上段下段でのアルペジオ打鍵を重視したためです。

試験的に作成したハイブリッド月の無変換、変換キー使用の2シフトバージョンは打鍵効率1.21、負荷ポイント1520くらいですので、この辺が現状の理論で到達できる限界かと思います。とはいえこのポイントは人差し指と中指を酷使させれば向上するものですので、実用上はこんなものかなと思います。

なお、覚えやすさ、習熟の容易さですが、一般的には難しいとされる清濁分置ではありますが、ハイブリッドの導入により、月2-263と同等程度と考えています。特に清濁同置配列の泣き所であるパ行ぁ行も覚えやすいのは大きいです。

指が覚える習熟についても、この拗音シフトの一貫性は非常に良好で、従来の月Ux等で見られる拗音を比較的規則正しく並べている拗音シフト系配列と比べても、歴然とした差があります。いわゆる拗音シフトフル装備の配列にしては現状一番の覚えやすさと考えています。

長所

前置シフトにより流れるように打鍵が出来る。
ハイブリッドにより低頻度文字の配置を覚える必要が無い。
キー共有によって前置シフト配列の中では群を抜いた打鍵効率。
全ての拗音が2打で出力されるスムーズさ。
全ての拗音が一貫した運指で入力できるので指が覚えやすい。
同時打鍵不要。
アルペジオ打鍵の重視。

短所

無変換、変換キーを使わないのはもったいない。
2シフトに収まらなかったのか。
実装がnodoka。
理屈が難しい。


では、よろしかったら試して見るなり、配列の改良のネタにするなりしていただければと思います。質問などはtwitterが早い気がします。

再帰とループについて

programing

　the interviews のサービスが終わると言うことで、投稿内容をスクレープするスクリプトをscalaで書きました。
　そこで、再帰とループについて考えてみました。

　関数型言語ではループは再帰で表現した方がよいと言うことになっているのですが、ループインデックスへの再代入を避けるための苦し紛れとしか思えません。
　そこで、スクリプトの関数型バージョンと手続き型バージョンを見比べて見たいと思います。

関数型バージョン

  val name = "tamanoir"
  val url_base = "http://theinterviews.jp/" + name + "/page/"

  type TheList = List[net.htmlparser.jericho.Element];
  @tailrec
  def ScrapeRecur(count: Int, ls: TheList): TheList = {
    Thread.sleep(1000)
    val url = if (count == 1) url_base else url_base + count.toString
    val str = scala.io.Source.fromURL(url).mkString
    val s = new net.htmlparser.jericho.Source(str)
    val body = s.getAllElements(HTMLElementName.BODY)
    if (body.isEmpty()) ls
    else {
      val res = body.get(0).getAllElements(HTMLElementName.DIV).filter { e => {
          val attr = e.getAttributeValue("class")
          attr != null && (attr == "title" || attr == "note")
        }
      }
      if (res.isEmpty()) ls
      else ScrapeRecur(count + 1, ls ::: (res.toList))
    }
  }
  val results = ScrapeRecur(1, List())

  val html_txt = "<html xmlns=\"http://www.w3.org/1999/xhtml\" lang=\"ja\" xml:lang=\"ja\">" +
    "<head><title>" + name + "</title>" +
    "<meta http-equiv=\"Content-Type\" content=\"text/html;" +
    " charset=UTF-8\" /></head><body>" +
    results.mkString +
    "</body></html>"

手続き型バージョン

  val name = "tamanoir"
  val url_base = "http://theinterviews.jp/" + name + "/page/"

  val results = ListBuffer[net.htmlparser.jericho.Element](); // ミュータブルリスト
  var cont = true // ミュータブル
  var count = 1 // ミュータブル
  while (cont) {
    Thread.sleep(1000)
    cont = false
    val url = if (count == 1) url_base else url_base + count.toString
    val str = scala.io.Source.fromURL(url).mkString
    val s = new net.htmlparser.jericho.Source(str)
    val body = s.getAllElements(HTMLElementName.BODY)
    if (!body.isEmpty()) {
      body.get(0).getAllElements(HTMLElementName.DIV).filter { e => {
          val attr = e.getAttributeValue("class")
          attr != null && (attr == "title" || attr == "note")
        }
      }.foreach(e2 => { results += e2; cont = true })
    }
    count += 1
  }

  val html_txt = "<html xmlns=\"http://www.w3.org/1999/xhtml\" lang=\"ja\" xml:lang=\"ja\">" +
    "<head><title>" + name + "</title>" +
    "<meta http-equiv=\"Content-Type\" content=\"text/html;" +
    " charset=UTF-8\" /></head><body>" +
    results.mkString +
    "</body></html>"

　これは小説家の佐藤亜紀 http://theinterviews.jp/tamanoir の投稿内容を収拾するスクリプトです。
　このサイトはよくあるようにPaginateされています。
　そこで、ページごとにcollectする必要があり、それぞれのページに複数のエントリがあります。わりと終了条件のわかりづらい二重ループです。
　ここで、内ループの一つのページに含まれるエントリを収拾するのは簡単で、いずれの例でも1行の関数型アプローチ(body.get(0).getAllElements(HTMLElementName.DIV).filter 〜〜)で済ませています。
　問題は外ループの終了条件です。内ループが空振りに終わったら、外ループも終了するようになっています。関数型アプローチでは再帰を抜けるようにして、手続き型アプローチではwhileを止めます。
　また、収拾したエントリの扱いも異なります。
　関数型アプローチでは、関数型の作法に従ってイミュータブルリストを連結して新しいイミュータブルリストを作成しています。
　手続き型アプローチではミュータブルリストにpush_backするおなじみの方法を採っています。
　意外と両バージョンの行数はほとんど同じです。

　これ、どっちの方が書きやすくて可読性が良いかといえば、手続き型バージョンだと思うんですよね。
　ページをめくって読んでいく流れがそのままコードに落としてあるからです。
　そして、内ループの流れも関数型っぽく書いてはいますが、foreach内でpush_backしているので、手続き脳の人にも理解しやすいと思います。
　それに引き替え、関数型バージョンは内ループで作成されるリストを検証するステップを追加する必要があり煩雑です。末尾再帰最適化が働くようにするようにするにも一手間かかりました。
　Scalaの場合は、再帰関数をdefするときにリストの型( List[net.htmlparser.jericho.Element] )を明示しないといけないのもイライラ感があります。
　Scalaの型推論が不十分だと言う不平不満も理解できます。

　どっかの教科書に「再帰によるループの表現はほとんどの場合は自分で書く必要が無いから安心して良い」とか書いてあったように思いますが、逆に、foreach、map、foldなどのお仕着せのループ関数が使えない場合は、手続的に書いた方が良いように思えます。
　パフォーマンスもこちらの方が期待できますしね。
　というわけで、Haskellのような純粋な言語よりは、関数型のおいしいところだけをつまみ食いできるScalaの方が私の好みに合います。
　マルチパラダイム万歳と言うことで。

Haskell始めて、終わりました。

programing

　Haskell始めました。
　Scalaを使いこなすには(ついでにC++11、boostも)、Haskellを通らないわけにはいかないと言うことで「すごいHaskell楽しく学ぼう」を読んだところです。実際本を買ったのは半年ほど前で、半年かけてゆっくり読み進みました。

　本を読みがてら、ちょろちょろとライブラリとかを見て驚いたのですが、例えば、Qtとか、Gtkとか、MessagePackとか、C++で実績のある重量級のライブラリは既にHaskellに対応していてドキュメントもわりかししっかりしています。WebフレームワークもYesod等まともに動作するとされているのが三種類もあります。

　なんとなく、実用という意味ではOCamlの方が盛り上がっているイメージがあったのですが、そうでもないようです。みなさんF#に流れているのでしょうか。

　しかし、このHaskellと言う言語は興味深いところも多いのですが、じゃ、Toyでもいいから何か作ってみようかと思うとなにも思い浮かびません。ですのでHaskellで身につけた知識をC++、Scala、C#に持ち帰って使うというのが正解のように思えます。(実際そうされている方は多いのでは無いのかと思います)
　HaskellPlatformが相当に良い仕事をしているのでもったいないのですけどね。
　Toyと言うとスクリプト的な使い方から始まるわけですが、スクリプトなんて、逐次処理の代表みたいなモノですのでHaskellと相性BADです。じゃ、画像処理の一部をHaskellに置き換えてみようかというと、画像処理なんてmutable処理の塊ですので、さすがにC++でループ書いた方が手早いです。そういう意味では、scalaはGUIもスクリプティングもなんでもござれで、本当にCの速度が必要な局面以外では使えるのでよくできていると思います。小から大までスケールできる言語という触れ込みは伊達では無いと思います。
　そして、Haskellですが、今時シングルパラダイム言語というのは、使えるシチュエーションが非常に限られるのでやはり厳しいのではないのかなと思います。
　Haskellだとクイックソートが簡潔(5行で)に書けると言われても、そのクイックソートはニセモノ(笑)とか言われるていたらくでどうしようもありません。それにクイックソートを自分で書く機会なんかありませんし、ちょっと意味がわからないなぁという感じです。

　実用という観点では、VCからHaskellを使うには、FFIをdll経由で使うというアクロバティックなことが必要で、デバッグがウルトラ面倒くさそうです。
　典型的なHaskellの用途として、コンパイラと金融関係がよくあげられていますが、私はもちろん、どちらの分野でもありません。そして、Yesodならどうかというのもありますが、WEB屋でも無いのでどうかなと言うところです。
　確かに、関数型プログラミングはいわゆるRESTとは相性良いのは理解できますが、趣味でWEBをやるならScalaのPlay2があるのでわざわざHaskellでやるモチベーションに欠けます。
　関数型のお作法というのは、MVCで言うところのimutableなcontrollerを記述するのに向いているとは思うのですが、viewとdocumetを書くには向いていないように思えます。ですので、viewとdocumetはC++で書いて、controllerはHaskellと言う組み合わせには夢が見られます。
　しかし、そういう使い方をするにはFFIはpoor過ぎると思います。C形式でしかインターフェイスできないのは仕方が無いとしても、VCとスタティックにリンクできないのはいただけません。
　個人的には、シングルパラダイム言語というのは一種のDSLだと思うわけで、他の言語との相互運用性が問われるところだと思います。その点はF#とscalaは非常に柔軟な言語のmixができるので、関数型プログラミングしたいところだけできるのですばらしいと思います。
　しかし、HaskellとC++を組み合わせようとすると結局のところtrivial object以外のオブジェクトの受け渡しが大いに面倒くさくなるので二の足を踏んでしまいます。
　となれば、結局、アプリケーションそのものが関数的であるコンパイラにHaskellが向いているのもうなずけます。
　そうですね。特許の出願書類の検証ソフトとかを作るには良いかもしれません。

　それと気にくわないのが、Intがいわゆるintで、IntegerがいわゆるBigIntと言うような80年代な命名規則で、個人的にはこういう往年のUnix丸出しは得意ではありません。こういう一貫性の無い命名規則は、毎日10時間つきあい続けるプロエンジニアのためのもので、土日だけつきあうには覚えきれるものではありません(同様の理由でruby vs pythonではpython派です)。
　また、今時、ByteStringがあちらこちらで使われていていてUnicodeではないというのは減点どころではありません。F#やScalaでは当然、内部の文字列は全てUnicodeであるので余計なことに悩まずにコードが書けるのに、ライブラリ内部の知らないところでByteStringに変換されて不可解なバグに悩まされる環境でコードは書きたくありません。

　結論としては、Scalaは関数型パラダイムの9割、C++11でも8割はサポートしているので残りの1〜2割のためにHaskellを導入して、余計なオーバーヘッドで四苦八苦するのは割に合わないかなと言うところです。

　それと、オブジェクト指向がオワコンかというと、そういうところはあるかと思いますが、既存のライブラリの多くがオブジェクトパラダイムで作成されているので、それらとの橋渡しが困難というのもあります。
　ようは、一つ未解決の問題として、オブジェクトを言語境界をまたいで渡す簡単な手法がないというのがあります。
　これはオブジェクトモデルが言語によって異なり、互換性が基本的にはないからです。
　SWIGなんかがあるにはあるわけですが、結局、クロージャーはおろかコールバック関数ですら言語をまたいで渡すのが非常に困難です。
　そのために多くのシステムでは、PODをバイナリなりJSONで渡すしかなくて、後はCスタイルのインターフェイスを通じて関数を呼ぶしかないわけです。
　これがあるためにRubyでプロトタイプを書いて、速度の必要な部分だけC++で書き直すというのが絵空事になってしまうと言う現実があります。例えば、railsのようなmagicalなフレームワークがどんなにウケたからといってボトルネックをC++に書き直すことは結局為されていません。mongrel2が完全にCで書き直されrubyと独立してしまったのが興味深いです。
　特に、ここでCで書き直すというのがポイントで、C++では書き直せないのが溜まらなく苦痛です。
　これはRubyに限らず、Haskellも、Javaもそうで、インターフェイスはCしかないのは色々不便です。となるとQtのようなC++のオブジェクトシステムががっちり食い込んだフレームワークを他言語から使うのはだいぶ分が悪くなります。

　この問題を解決するにオブジェクトモデルを共有するほかなく、F#とScalaはVMにそのまま乗っかかる形でうまくやっています。

　個人的には、D言語っぽいシンタックスの、C++を吐くだけの新規の言語に期待したいところです。

同人誌と著作権再考

知財

　いわゆるアニパロ同人誌は、原著作物の翻案(著2条1項11号)に当たるから違法であるとされていますが、必ずしもそうとは言えないという話をします。
同人誌 - Wikipedia
　世間的には違法とされており、私もそうであるとは信じていたのですが、アニパロ同人誌のようなものの違法性についてまじめに検討した教科書が見当たらなかったので考えてみました。すると、実は大部分は合法なのでは無いのかと言う結論に至りました。
　違法であるという考えが広まっているのは「表現」「翻案」「パロディ」「キャラクター権」等の用語が誤って理解されていることと、やっている人たちの後ろめたさから来るものと思われます。

　判例を調査しますと、海賊版の販売といった完全にクロな行為以外で著作権侵害が認められたケースがあまりないと言うことに気付かされます。それ以外の原著作物を改変参考にした二次著作物にどこまで原著作者の権利が及ぶのかはケースバイケースではあるのですが、普通に思われているよりかなり範囲が狭くなります。

　そして、あまり知られていないことですが、特に小説については、原作者の承諾無しに続編を作ることは著作権法上合法とされています(著:中山)。マンガの場合にこれがそのまま当てはまるかを考えてみます。

  • パロディとは

　ここで、注意しないといけないのはいわゆるアニパロ同人誌は辞書的な意味の「パロディ」では無いと言うことです。
本来の「パロディ」とは芸術作品を揶揄や風刺、批判する目的を持って模倣した作品であって、
http://matome.naver.jp/odai/2127417147379498301
のように原作品のコピーをベースに作成するものを指します。これはWEB上などではコラージュと呼ばれています。詩におけるパロディもそうで、本歌取りのように、現作品の一部をそのまま含むのが通常です。
　それに対して、同人誌では一から絵を描くのが通例ですのでコラージュではありません。
　判例では「パロディ＝モンタージュ事件」によって、日本ではパロディは事実上禁止されましたが、これは写真コラージュが訴えられた事件で、同人誌とは直接は関係ありません。同人誌のような模倣の様態はパロディであったしても同じ扱いができるか微妙です。

  • 著作物とは

　著作物とは「思想又は感情を創作的に表現したもの」(著2条1項1号)とされています。わかりにくい物言いですが、同人誌を考えるときに「創作」と「表現」が問題になります。

  • 「創作」について、

　創作がなんであるかは自明とも思われますが、そうではありません。法解釈的にはなんらかの創作者の個性があらわれていればいいとされていますが、単にそれだけではありません。
　例えば、タイトルは「創作」では無いとされています。あまりに短い表現には「創作」が含まれていないと考えられるからです。このようなものを商標法では「選択」と言いいます。つまり、たくさん候補のある中から選んだ程度のもので誰か個人に権利を与えるのは好ましくないと言うことです。ありふれた表現は創作的ではないという言い方をしたりもします。
　例えば「空が青かった」に一々権利が発生したらなにも書けなくなるからです。
そこで、どの程度の文章があれば「創作的」とは認められるかと言えばケースバイケースです。文章のばあいは、俳句の五七五が「創作的」とされる最低限度とされています。それも独立して完結している俳句のばあいであって、小説ではもっともっと分量が必要です。
　例えば「雪月花事件」と言うのもありまして、これは写真の背景に書の掛け軸の作品が映り込んでいたというものです。この場合は書の創作的な特徴部分が写真には十分に写っていないとして、合法とされました。
　音楽であれば、コード進行、を決めることは「選択」とされます。
　そして、写真の場合は「創作」の範囲が極めて小さいです。例えば、ありふれた構図とか、被写体の選択には著作権が発生しません。
　イラストの場合は線の一本でも引き方は無数にあるので比較的細かいところでも「創作的」とされます。
　「ワン・レイニー・ナイト・イン・トーキョー事件」「交通標語事件」「銀河鉄道999事件」「廃墟写真事件」

  • 「表現」について

　これは具体的であることをいいます。つまり、アイデアは著作権法で保護されないと言うことです。
　例えば、作品の雰囲気、テーマ、モチーフ、ギミック、ゲームのルールと言った抽象概念には著作権法はおよばないということです。
　さらに「表現」と言うと、絵のタッチ、文体、が含まれそうですが、そうではありません。あくまで作品そのものが著作権法で保護されます。
　また、キャラクターも抽象概念として、著作権法で保護されません。
　これらが共通する作品をパクリと思うことは多々ありますが、著作権の問題ではありません。
　このような抽象概念をパクリと訴える事件は例えば「NHK武蔵事件」「江差追分事件」「春の波濤事件」で争われますが、ことごとく原作者が敗訴しています。
　イラストの「表現」が類似しているとして違法とされた例としては「世界の名所旧跡のイラスト著作権侵害事件」があります。この事件では、イラストのタッチは異なってとしても、全体の構図、名所旧跡の選択の完全一致やそれぞれの名所旧跡も似ているとして侵害とされました。これを考えるとマンガ原作品の特徴の強い一場面をまったく同じ背景構図のまま、自分のタッチで描く行為は違法とされそうです。

  • 翻案とは

　同人誌は原作品の複製ではありませんが、原作品に「依拠」した創作であるのは間違いないところですので、法上の二次的著作物(著2条1項11号)に当たるかが問題になります。
　「依拠」していれば何でも二次的著作物かというとそういうことはありません。スターウォーズが七人の侍を参考にしているからと言って、スターウォーズが二次的著作物とは言えないということです。ですので、原作品とどの程度に似ているかが問題となります。
　では、条文を見てみましょう。

二次的著作物 著作物を翻訳し、編曲し、若しくは変形し、又は脚色し、映画化し、その他翻案することにより創作した著作物をいう。(著2条1項11号)

　同人誌は翻訳、編曲、脚色、映画化には当たらなそうです。
　ここで「変形」と言うのも耳慣れない言葉ですが「既存の美術などの著作物を他の表現に変換すること」を指します。例えば、イラストからフィギュアを作成することを言います。同人誌とはちょっとなじみません。


　さて「翻案」ですが、本来の国語的な意味は

既存の事柄の趣旨を生かして作りかえること。特に小説・戯曲などで、原作の筋や内容をもとに改作すること。また、そのもの。「舞台を日本に置き替えて―する」(デジタル大辞泉)

です。巌窟王とか小説聖書とかのことを指します。イラストであれば、江戸時代のサムライの絵をコラージュして現代のスーツを着せるようなものをさします。
　これを同人誌にも及ぶように拡張できるかが問題となります。
　法的に「翻案」とは「内面的形式を維持しつつ外面的な表現を変えること」を言いますが、いまいちしっくりしない定義なので、判例では「原著作物の本質的な特徴を直接体感できる」と言う言い方がよく使われます。これは「原著作物の内容及び形式を知覚させるに足りる」とも言い換えられます。
　どこまで似ていれば「原著作物の本質的な特徴を直接体感できる」のかは一概には言えませんが、二次的著作物を読めば、原著作物をも読んだも同然の体験ができる程度が必要であると言えるでしょう。小説聖書を読めば、細かいところはさておき聖書の「本質的」ところは理解できます。つまり、細かい表現は異なったり、一部欠落したとしても原著作物(の少なくとも一部)を内部に含んでいることが要求されます。


では、同人誌の場合はどうかと考えてみましょう。
　同人誌には原作品のストーリーが含まれていないのが通常であるので、同人誌を読んでも原作品を体感できません。
　作品の雰囲気とかキャラクターを体感することはできるかもしれませんが、それのみで原作品の「本質的な特徴」と言うには不足です。
また、単体のイラストを取り出しても、自分で絵を描いていれば複製にも翻案にも当たりません。
　ですので、同人誌は通常、二次的著作物ではありません。


　複製翻案に関わる判例は以下のサイトにまとめられていますが、侵害が認められるケースがほとんどない点に注意してください。
http://park2.wakwak.com/~willway-legal/kls-c.case.g33.html

  • キャラクター権について

　そこで、同人誌のストーリーでは無く、個々のキャラクターの絵に着目して、絵が侵害に当たるかを見てみたいと思います。
前提として、キャラクターは抽象概念であるので著作物ではありません。
「思想，感情若しくはアイデア，事実若しくは事件など表現それ自体でない部分や表現上の創作性がない部分は，ここにいう既存の著作物の表現上の本質的な特徴には当たらない」
　としており、キャラクターはアイデアにすぎないとされています。
　特に、キャラクターの性格や名前などの内面的特徴は一切保護されません。
しかし、まったく法で保護されないのかというとそうでもありません。
どういうことでしょう。
　キャラクターの絵が保護される場合はあります。基準となるのは「サザエさん事件」「ポパイ事件」です。この二つの判例では一見キャラクターが保護されるかのようになっていますが厳密には違うと言う、微妙な判例です。
判例では、

第三者の作品が漫画の特定の画面に描かれた登場人物の絵と細部まで一致することを要するものではなく、その特徴から当該登場人物を描いたものであることを知り得るものであれば足りる

とあり、直接の絵のコピーがあったと見なすとされています。
　この表現が一人歩きしてあたかもキャラクターが保護されるかのように言う人もいますが、判例は具体的に原作のどのコマに似ているかと証明する必要がないと言っているだけです。
　ここで注意が必要なのは、キャラクターの外見でも、単にネコミミが生えているとか、ツインテールであるとか、巫女服を着ているな服装をしているとかは、それ自体は保護されないと言うことです。
　となればタッチが違うことにより、原作のどのコマにも明らかに一致しない無い場合はどうなるとか、と言うのが問題になります。特に、初音ミクのように誰がどんなタッチで描いてもデフォルメしても初音ミクにしか見えない、と言うケースが問題です。


　結局は「原著作物の本質的な特徴を直接体感できる」のかと言うことが問題になるでしょう。
　では「パロディ＝モンタージュ事件」を見てみましょう。
　この事件はいわゆるフォトショコラが違法とされた事件ですが、コラージュですので原写真がそのまま使われています。さすがにそのままですので「原著作物の本質的な特徴を直接体感できる」と言うことになりました。
ここで判決文を読むと
　「一般にパロデイといわれている表現のもつ意義や価値を故なく軽視したり否定することとなるものではない……写真というものの技術的性質から原写真のその部分をこれと寸分違わないかたちで取り込まざるをえないものであること……」
とあり、最高裁はパロデイに一定の理解を示していることがわかります。


また、合法とされる条件として

パロデイとしての表現上必要と考える範囲で本件写真の表現形式を模した写真を被上告人自ら撮影し、これにモンタージユの技法を施してするなどの方法が考えられよう

　の基準が示されているのところを考えると、トレスなどせずに自分のタッチでちゃんと描けば「原著作物の本質的な特徴を『直接』体感できる」とまではいかなくなって許容されるのでは無いのかと思います。法的には「直接」とか言う限定的な言葉入っている場合はむやみな拡大解釈を許さないと言うことですので、このような結論になると思います。
　ただドラえもんのような、比較的シンプルな絵柄をそのままそのタッチで描いてしまうと、相違点がほとんどなくなってしまうので違法とされる可能性が高まります。
　ここで「キャンディキャンディ事件」というのもありまして、原作(水木杏子)と作画(いがらしゆみこ)がもめた事件です。これは複雑な事件で同人誌に関係する部分だけ要約すると、キャンディキャンディの作画を行ったいがらしゆみこ本人が描いたキャンディキャンディの複製原画、新たに書き下ろしたイラストを水木杏子が差し止めることができるとされた事件です。複製原画はともかくとして、新たに書き下ろしたイラストまで違法とされたのは漫画家にとっては厳しい判決かと思います。しかし、本件をそのまま適用すると、小畑健が進藤ヒカルをちょっとバクマンに登場させると即違法と言うことになりますが、そのようなことはちょっと考えにくいと思われます。本件は原作と作画の関係が問題の中心で特殊な事案かもしれません。また、逆に続編で作画が交代する場合などはどうなるのかなど色々問題があります。


　なお、「サザエさん事件」はバス、「ポパイ事件」はネクタイとキャラクター商品サービスが争われたケースで、商品化権との関係で厳しく判断されている可能性が高いです。商標法や不正競争防止法では、他人の名声に便乗して商売することをフリーライドとして取り締まられますので、その考え方が入っています。一方、著作物では名声に便乗して商売は合法(例えば、ゲーム攻略本は合法)ですので、純然たる著作物である同人誌で同一の判断が為されるとは限りません。
　また、日本の裁判所の傾向から考えて先入観によりエロパロ同人誌は厳しく判断される可能性もあります。

  • SSについて

　前述の通り、SSは原作品の抽象要素を含んではいるものの原作品を体感できないので翻案ではありません。
また、キャラクターは抽象概念であるので著作物なく、さらにイラストが無いので「サザエさん事件」のような議論も成立しません。
よって、SSが違法とされる可能性はほとんどないものと思われます。
この考え方で、小説の続編を勝手に書く行為も合法です。一見、不条理にも思えますが、無許可の続編作成はシャーロックホームズの時代から完全に合法な行為とされています。
「明智小五郎」「ルパン」「クトゥルフ」が登場する商業作品はいくらでもありますが、合法です。


　なお、マンガの続編が違法とされた「タイガーマスク無断続編作成事件(地裁仮処分)」と言う例がありますが、マンガ家からのアンケート調査を元にした仮処分判決にすぎず、仮処分判決ですので判断の根拠が示されておらずあまり参考にはなりません。

  • 模型化について

　模型化は「変形(著2条1項11号)」に当たりますので原則アウトです。

  • トレースについて

　トレースは一見アウトのような気がしますが、単に「依拠」していれば違法と言うわけでは無いので難しいです。
　「政治宣伝用ビラ作成配布事件」では写真のトレースが合法とされました。
考え方としては、
・トレースした部分に「創作」が無ければ合法
　ありふれた構図の写真の構図、特別に特徴の無い被写体の被写体と言った部分には著作権が発生しないからです。写真の著作権は非常に限定的ですので、写真トレースの場合が合法である場合が多そうです。ただ、写真ならともかくとして、イラストで特徴にある部分を全部削除というのは簡単では無いと思われます。


　なお、画風には著作権は生じませんので、単に絵柄が似ているというのは合法です。

  • 服、車

　工業製品には原則著作権は生じませんので、ファッション雑誌とかから服を適当にパクって自キャラに着せるのは合法です。ただし、製品写真をトレースする場合は注意が必要です。

  • コラージュについて

　「パロディ＝モンタージュ事件」のとおり、MAD含めて通常はクロです。
　一応は「本質的な特徴を直接体感でき」なければ合法ですので、一音単位でサンプリングして全然違った曲を作るとか、フォトショップで原画像を認識できないくらいぐちゃぐちゃに混ぜてそれを素材にするとかは合法と考えられます。
「原写真の同一性がもはや完全に失われたと認められるほど細分された原写真の部分を利用してモンタージユ……」
とあるからです。

　著作権法以外にも不正競争防止法、商標法がありますが原則として著作物には及ばないので同人誌には関係がないものと思われます。ただし、同人グッズには及ぶので注意が必要です。
　民法一般の不法行為が問題になる可能性があります。これは、特に明文の規定が無くても不法行為と判断される場合があると言うことです。例えば、肖像権や日照権には直接根拠となる条文は存在せず判例の中で定まっています。
　著作権に近いところでは「ニュース見出し無断使用事件」ではニュース見出しは著作物ではないとされたが、法的保護価値はあるとして、月１万円の使用料が言い渡されました。
　同人誌もスピンオフ使用料として、なんらかの金銭が請求される可能性はあります。

  • あとがき

　色々書きましたが、著作権法上は合法と思われても、言いがかりで訴えられることもめずらしくありません。そして、いったん訴えられたら少なからぬ損失を被ります。何も知らない警察がやってくることもあります。びくびくしながらファン活動を行うのもつまらないものです。
　また、原作者が不快に感じているのに同人活動を行うことは法的にはおとがめ無しでも、あんまり気が進まないものです。そう考える人たちは、東方とかの公式にOKの出ているジャンルに流れているものと思われます。
　かくいう私も、PBWで活動しているのでシェアード・ワールドをベースにオリジナル作品を作成している状態です。
　最後の方で軽く触れましたが、将来的にはスピンオフ使用料のような方向に進むのが望ましいのでは無いのかと私は考えています。例えば、スピンオフ作品の売り上げに対して金銭的請求権が発生する等が健全な落としどころと思われます。

  • 参考文献

著作権法:中山信弘
最新著作権関係判例と実務:知的所有権問題研究会
逐条解説 不正競争防止法:経済産業省
工業所有権法(産業財産権法)逐条解説:特許庁

abj配列

配列

abj配列は、母音省略システムを搭載した行段系配列です。

【abjシステム】
　abjシステムは母音の入力を可能な限り省略するシステムです。abjシステムでは、子音(例:K)が入力されたときに優先度の高いカナ(例:か)を表示します。優先度の低いカナを入力する場合は、適切な母音を追加することによって目的のカナになります。これによって母音入力の約35%を省略できます。
　例えば「dkims」と言う文字列は日本語で「できます」に見えるかと思いますが、abjシステムでは実際「できます」が出力されます。


【abjの意味】
　abjとはabjadの略で、アラビア語やヘブライ語などの短母音を表す文字が存在しない言語のことをいいます。詳しくはwikiを参照してください。
アブジャド - Wikipedia
　これを日本語入力に取り入れてみたのがabj配列です。この分野での先駆的な研究には「Touch Me Key」「T9」などがあります。


【入力方法】

母音推定

　子音を入力されると、デフォルト設定のカナがいきなり表示されます。

例 : S->す

　このようなデフォルト設定のカナを「優先カナ」と呼びます。
　このときに立て続けに子音を入力し続けると「優先カナ」が確定していきます。

例 : BKDSN->バカですな

　もし「優先カナ」が希望のカナがではない場合には適切な母音を入力すると希望のカナに変わって確定します。

例 : BoKuDSNe->ボクですね

　母音のいくらかを省略できるローマ字だと思ってください。

子音 優先カナ 子音 優先カナ 子音 優先カナ
b ば ch ち d で
f ふ g が h は
j じ k か l ぁ
m ま n な p 。
r る s す t た
v ・ sh し y よ
ly ょ z 、
確定カナ

　特によく使うカナである「た」「と」「の」「ん」「っ」は専用キーが用意してあります。専用キーを押しても直前の「優先カナ」が確定します。これはタ行、ナ行では「た」「と」「て」「な」「の」等の出現頻度が高い上に均等でabjシステムがうまく動作しないからです。また「ん」とナ行を区別する必要もありました。
　もちろん「あいうえお」も「aiueo」でそのまま確定します。
　また「を」「わ」についても専用キーを用意してあります。「これをあげる」と言った文章で「わ」を誤打鍵するミスを防ぐためです。

追加子音

「sh」「ch」の子音にはキーに割り振られています。このルールでは「SH」と入力すると「すは」と出てしまうからです。また拗音を入力しやすくするためでもあります。
　これによって「TI」「SI」と打った場合は「ち」「し」ではなく「てい」「すい」が入力されます。

長母音拡張

子音を入力した後に「-ai」「-ou」を入力すると長母音が入力されます。これは母音省略が行われたものと勘違いするミスを軽減するためです。

例 : 「K(か),I」で「かい」が出そうだが「き」が出る

撥音「っ」

撥音「っ」は専用キー(slash)を打つことによって入力できます。子音連打では出ないのは「かかく」等を打つ利便性を優先させたからです。「っP」のみは「。(P)」の連打でも出ます。これは、colon→commaの運指が厳しいことと「。」が続くことが通常ないからです

拗音

k-Y-o等の拗音の「Y」は「-y」キーで入力します。「Y」を押しても出ません。これは運指を改善するのと、意図しない動作(例:×MY->まよ ○MY->みょ)を防止するために分離したものです。また、「-y」を押した時点でk-Y-oと「ょ」が優先されます。aiを打つことによって「ゃゅ」に変わります。-ai、-ouに続けることもできます。この結果3打必要とする拗音は拗音全体の8%以内に収まります。
　そのほか、あまり一般的ではない拗音の入力方法は無効になっています。

例外1

以下のキーの連続は通常の規則から外れています。

  • KR : から
  • Mの : もの
  • RR : られ
  • RRR : られる
  • NN : なに
  • Sん : せん
  • -y-y : ゅう
例外2

「PZV」行に関しては「優先カナ」がありません。「、。・」とキーを共有しています。これによってキー数を稼ぎ指の移動を減らしています。


【配列作成者向けの設計思想話】
　プログラマー的な省略記法では子音のみで表現することがままあり(例:cmd(command)、wnd(window)、msg(message))これを日本語入力に応用できないかと常々考えていました。AZIKの特殊拡張のように限定されたパターン(ds->です、ms->ます)でならできるのですが、一般化された状況ではIMEの補助無しには不可能と思えました。
　これらの先行例としてはT9入力などがあります。
　ネックになったのはTKN行の変化の多彩さで「とて」「かき」「もの」のように、デフォルトでどれかを選択する仕様にしてもイマイチ中途半端な結果に終わりました。
　ところが、最近いくつかのカナ行段のハイブリッド配列を作成した関係で行段にもいくつかの確定カナキーを置くのが有効であるとわかったので確定カナキーを使ってTKN行を制御することを思いつきました。試行錯誤の結果、K行はなにもせずTN行に専用キーを設けて完成としました。
　これで実用レベルになったと思います。

親指キーの使用

　親指キーの使用は当初から考えていました。もともとは親指シフト系を使っていて親指の使用頻度が多すぎるかなと思ったのが発端だからです。

確定カナ

　この辺がカナ行段ハイブリッド配列の名残になります。
　abj配列は行段系配列ですが、子音キーの連続に意味がありますので、子音キーにazikのような拡張を配置することがなかなかできません。そこでまずは「ん」を独立したキーにする必要がありました。それ以外の「確定カナ」が無くても動作しますが、打鍵数が約8%増加するのに加え「あったとて」のようにabjシステムがうまく動作しないパターンが多く発生する問題がありました。
　候補として「たとかなの」の5カナが考えられましたが、キー配置とのバランスを考慮して「たとの」を選択しました。「た」と「か」のどちらを採用するかはだいぶ試行錯誤しましたが、「た」を採用すると「て」が「優先カナ」に繰り上がり、Eの使用頻度を減らすことを優先し「た」を採用しました。
　「わ」については当初「を」と共有させていましたが、わかりにくいことと、「Y」キーになにも割り当てておらずもったいなかったのでこのようにしました。

母音の配置

　母音の配置がほぼqwertyのままですが、これは習得の容易性を考慮したものではありますが、場所を移動しても、あまり利益が無かったのでこのようになりました。
　。いざというときにqwertyに復帰しやすいからです。私の場合は約3分カチャカチャすればすんなりqwertyに戻れます。経験的に、指に異なる母音を割り当てない(例:右手人差し指にIを割り当て)のが鍵のようです。

悪運指について

　2ヶ月程かけて目立った悪運指は減ってきたかと思いますが、定量的な評価は単に悪運指の出現頻度に限らず指の運動量を総合的に評価する段になってから検討したいと思います。

性能

小梅配列さんのところの10万字サンプル(英字抜き)で集計したら
字数計 102,070

打鍵数(k) 負荷ポイント
通常ローマ字 177 2476
NICOLA 143 1806
月2-263 131 1803
飛鳥 144 1697
小梅(私家版) 135 1656
新下駄 127 1535
qwerty_hybrid 128 1768
abj 129 1595

(abjは母音の補足に必要な打鍵が計算に入っていないから5%程悪化するはず)
となり、まずまず最新の配列と遜色ない性能が出ています。
　qwerty_hybridより見た目の打鍵数が増加しているのはabjが「っ」を設けて「-ei」を削除したためです。その代わり、母音の補足が必要な回数が減っているはずです。

今後の予定

　nodokaにタイマーが実装されたら、一定時間で「優先カナ」が確定するようにしたいです。一呼吸おくと「優先カナ」が確定していないことを忘れるからです。そうなればいっそう使いやすくなると思います。


【ダウンロード】
abj_001.nodoka - Google ドライブ

「自炊の森」問題まとめ　Q&A

知財

議論が一段落したと思いますので、それを踏まえて私の見解をまとめてみました。


前提として「自炊の森」を

  • ユーザに電子的に複製させることを目的として
  • 著作物を複製に適した形態に裁断し店舗に置き
  • 自動複製機器(スキャナ)も同時に店舗に置く
  • ビジネス

とします。

  • Q1 「自炊の森」は非合法ではないのですか？

裁判所が判断するまでわかりません。著作権法の条文上は白に近いですが、日本の裁判所はいわゆる「カラオケ法理」等によって黒と判断することが多々あります。

  • Q2 条文上は白とはどういうことですか？

いわゆる「私的使用を目的とする複製(著30条)」に該当します。

第三十条　著作物は、個人的に又は家庭内その他これに準ずる限られた範囲内において使用すること（以下「私的使用」という。）を目的とするときはその使用する者が複製することができる。

  • Q3 今までの自炊は自分の本をスキャンするものですよね。そもそも自分が所有していない本をコピーするのは「私的」に当たらないのではないのですか？

いいえ、自分の所有していない著作物をコピーすることは合法です。これが禁止されたらテレビ番組を録画できなくなります。

  • Q4 条文には「家庭内」とあるのでお店でコピーするのはダメのではないのですか？

「家庭内」というのは「において使用することを目的とする」にかかっています。つまり個人的に使用(読む)ためのコピーのことを指します。ですのでコピーをどこで行うかは問題ではありません。コンビニでコピーすることが合法なのもこれによります。
　現状でも漫画喫茶にコピーが置いてあることがありますが、これも合法とされています。

三十条にはいくつかの例外規定がありますが、重要な例外にお店での「自動複製機器」を用いた複製が禁止されているというものがあります。ただややこしいことに、お店での「自動複製機器」を全て禁止すると、コンビニのコピー機も禁止されてしまうので「紙」をコピーする「自動複製機器」については例外の例外で合法になっています。

次に掲げる場合を除き、その使用する者が複製することができる。
第三十条一項　公衆の使用に供することを目的として設置されている自動複製機器を用いて複製する場合

著作権法附則
（自動複製機器についての経過措置）
第五条の二 　著作権法第三十条第一項第一号及び第百十九条第二項第二号の規定の適用については、当分の間、これらの規定に規定する自動複製機器には、専ら文書又は図画の複製に供するものを含まないものとする。

  • Q6 図書館と一緒ですね？

　図書館にあるユーザが操作するコピー機については「私的使用を目的とする複製(著30条)」なのか「図書館等における複製(著31条)」法学上の論点で決まっていません。「自炊の森」とは関係無いので忘れて下さい。

  • Q7 それでは合法なのですね

　わかりません。「カラオケ法理」があるからです。

  • Q8 カラオケ法理?

　簡潔にいうと
「業者の管理下で」客のやったことが「私的使用を目的とする複製(著30条)」でも業者にとっては私的使用を目的「にあたらない」から違法
　と言う理屈です。
　細かい要件を取り出して論じたいところですが、近年「カラオケ法理」は拡大解釈される一方なので裁判所がどのように判断するのか予想がつきにくいです。
　なお、何でもかんでもこの理屈を通すとネットサービスの多くがこれに抵触し違法となりますので現在は批判が多いです。

  • Q9 ならば黒なのか?

　去年(H22)の改正でダウンロードが違法化されたり、検索サービスが合法化されたり、著作権の影響する範囲が細かく修正されましたが「カラオケ法理」に関しては明文化されずにスルーされました。これが裁判所にどう影響するか不明です。
　なお、今現在(2011.1)カラオケ法理に関わる重要な事件(まねきTV訴訟)が最高裁で争われていますので、その結果によっても大きく変わりそうです。

  • Q10 つまりはどういうことよ

　店にある紙をスキャンできるサービスは条文上は合法ですが、裁判所の機嫌によっては違法とされる場合もあります。

  • Q11 出版社は動くのか？

わかりません。出版社には音楽映画ゲーム会社と異なり著作権がありません。ですので出版社には訴える権利がありません。この辺は電子書籍との関係で非常にややこしくなっており展開が読めません。

  • Q12 他に影響があるのか

　Kinko's、BOOKSCAN、漫画喫茶、図書館、裁断済み書籍の転売、各種ネットサービス、電子書籍、教育機関などに幅広く影響が出ます。


個人的見解
　音楽映画業界に対しては裁判所は有利に判断しますが、ブックオフや漫画喫茶が合法とされたように書籍に関しては業界が敗北し続けています。
　これは書籍は教育と言論の根幹をなしており、規制によって生じる悪影響が大きいからであると思います。ネットを始め世間のことにうとい裁判官でも「これが違法なら裁判所で書証のスキャンも違法になりますよ」と言われればすぐにピンと来ます。
　これは例えば「見出し」をサイトに表示しニュース記事に直リンを貼った「読売オンライン見出し事件」ではライセンス料月1万円、差し止め不可と言う事実上の敗北を出版側がしました。
　H22改正でさりげなく「国立国会図書館における所蔵資料の電子化(31条2項)」が法制化されており、ここでも書籍に関しては特別な扱いを受けていると言って良いと思います。


さて、
自炊の森のサービスが「店内在庫書籍であれば、定価の40％（+消費税）の料金で1冊まるまるを電子化できる」と言う従量制であると言うことが明らかになりました。これはマンガ喫茶とは明らかに異なります。マンガ喫茶ではユーザーが手に取る書籍についてマンガ喫茶側は関知しませんが、自炊の森では一冊ごとに料金が発生するとのことですので、自炊の森がどの本がコピーされるのかを積極的に管理した上でユーザに渡しているので、これをもって実質的な貸与だと言われる余地が生じます。
　つまり「カラオケ法理」を争うまでもなく違法とされる可能性が高いです。


まぁ、どちらにせよ。まともな電子書籍が出たら終了するビジネスですので、裁判を待たずに終わる公算が高いと思います。


一応この辺の議論を参考にしました。
「自炊の森」問題　http://togetter.com/li/83973
「自炊の森」問題に関する専門家の見解 http://togetter.com/li/84045