籠鳥ろうちょう配列とは

キメラですこしカオスな行段系かな配列です。
定義に制約の多いATOKでも実装できるよう作られています。

ダウンロード

籠鳥配列 v1.05 ATOK用定義ファイル

設定方法はこちらを参照ください

特徴

あること

• 「DVORAK配列」を基にしているようで右端に「OEA配列」が混ざっています。
• 「Km式」のように行段系でありながら母音以外にも単打で打てる文字が左手側にあります。
• 「ACT」「JLOD」のように担当する指によって拗音キーの位置を変えています。
• 「ACT」「JLOD」「AOUR」のように「SKY配列」からの流れをくむ二重母音や撥音拡張ももちろんあります。
• 「AZIK」の頃からある子音同士での母音省略を多くとりいれています。
• 左手側のみ最上段に動詞用拡張が2ストローク目にマッピングされています。

ないこと

• 専用のソフトウェアを必要としません。日本語入力ソフト(ATOK等)だけでOK。
  よってSandSや親指シフトなどのギミックは当然ながらありません。(ざんねん🥲)
• 拗音を2打で入力できるCH、SH、Jなどのキーはありません。3打で入力します。

つまり？

• 漢字より文章を優先した設計でそれなりに効率のよい日本語入力方式です。
• 使用するキーの範囲は左手側4x5 右手側3x6と変則的な形となっています。
• ATOKの制約のために不完全なのは仕様です。

ことのいきさつ(手短に)

ATOK を使う際、AOUR 以外の選択肢がほしかったのです。

 

ことのいきさつ(長話)

それは籠鳥配列ができる以前のお話

その昔、Typewellというタイピングソフトがあったそうな。
そこにある子どもがであい
ランキングサイトまでもあるたいそうイケてるフリーウェアに
狂ったように1日に何万打も打っては、ランキング1000位以内に入ったこともあったそうな。

 

そんなある日、
集中力というより文字を認識するまでの速度、「意識の壁」を感じ
激しい競争に興ずるのをやめてしもうた。

 

時が流れるなか、たまーにAHKやXmodmapで無駄に奇抜で変な配列をつくっては、

公開もせず使ったり使わなかったりしました。(だって扱いにくいんですもん) ※

 

いろんな配列で遊べるタイピングソフトをつくるも
複雑にしていくうちにいつのまにか偶発的なバグが混入し開発は破棄されたものの、
そのソフトによって自身が作った配列が
醜悪な使いにくさのわりに月配列と同等かそれ以下の打鍵効率だということが露呈したのでした。（彼らは優秀すぎる）

 

そうしてタイピングからも配列作りからもプログラミングからも離れるなか一太郎がやってきて、こう言いました。

 

「変換中の辞書が便利だからATOKを使いなさい。あっ、スマホは別ですよ。」

 

そんなわけでATOKユーザーとなったわたしは、さすがにQWERTYじゃな･･･と思い配列を探し始めます。
見つかったのは「月配列」の古い定義ファイルと「AOUR」でした。
わたしはすぐさまAOURを試してみることにしました。

 

「うん。趣味じゃないな。」

 

それはまぎれもない率直な最初の印象でありながら致命的なものでした。
効率や速度に不満が出たのではありません。設計の方向が趣味じゃなかっただけです。
使えるかどうかで言えば十分に使えるでしょう。
でもそんなことで別の配列をつくっちゃうのがオタクなんですよ。

 

そうして元々はAOURだったものは籠鳥配列へと姿を変えいまに至ります。

 

※ 失敗作の例

• 複数形や擬音が打ちやすくなる繰り返し記号「々」のような働きをするキーを配置した配列
• どんな文字列でも確実に3打で2文字打てる「半分行段系入力で半分かな入力」な配列
• 母音の圧縮が可能な子音が先に来て母音が後に来る「逆・行段系入力」な配列
  ポーランド記法では母音を示す子音が必要になるため、打鍵数が増える場面もあります。
  逆ポーランド記法だと文字を出力するタイミングが決まっていないため定義数が際限なく必要になります。
• 膠着言語の特徴に着目した配列
  動詞をテ形でつなげていき「？かないでいるのではなかった」など1～15文字ほどを半分以下の打鍵数で出力する。
  その昔uim-anthyではロードが遅すぎたため、
  IMEを使用するすべてのアプリケーションが遅くなるという事情からボツになった。
  表現のゆれを考えるだすとつらいので忘れよう。

ふりかえってみると頭を働かせないと打てないものが多かったですね。

ATOKの制約のなかで

ATOKでも実装可能な行段系かな配列をつくっていくわけですが、
ATOKのローマ字定義テーブルの制約にはかなり厳しいものがあります。
他の日本語入力（IME）と比べてもトップクラスの柔軟性のなさです。
親指入力に対応していたAnthyや、
柔軟性が高くハングアップしづらいGoogle日本語入力（mozc）を見習ってもらいたいものです。

それでも使うのはATOKがやはり便利だからにほかなりません。
そのATOKの制約はというと具体的には以下のようなものです。

ATOKのローマ字定義には５つの制限がある。

 

1. 設定できる定義数は550個まで
   ローマ字拡張をフル活用するには心もとなさすぎる数といえる。
   この４倍あっても使いきることはたやすいのだから、
   少ない定義数のなかで機能的になるよう工夫する必要ある。
    
2. 右手下段に独自のキーストロークの割り当て不可能
   「N」        ２ストローク目は自由に定義可能。単打割り当て不可（だったと思う）。未定義パターンでは「ん」になる。
   「M」        ２ストローク目は自由に定義可能。単打割り当て不可（だった気がする）。
   「、。・」まったく改変不可能 ※
    
3. SHIFT 時に 別のストロークを割り当てられない。
   zもZも同じキーとして判定される。
   つまりSHIFTを前提とした入力方式を採用できない。
    
4. 定義可能な打数と出力可能な文字数が決まっている
   定義は４打まで
   出力は６文字まで
   
   出力は６文字までというのは「ありがとう」は出力できても
   「ありがとうございました」は出力を分ける必要があるということ。
   ステノタイプでは一瞬で出力できる「かぶしきがいしゃ」も一度には出力できないのだ。
   
   その上、この６文字という制限は半角ｶﾅで「濁音」も１文字として数える仕様だ。
   シーラカンスのような古さです。
5. 次のストロークの定義不可
   他のIMEでは「tt」と打つと「っt」となり「a」と続けることで
   「tta」＝「った」と出力されるよう定義できる。
   
   ATOKではこのようなルールは特別なオプションで実装されており
   ローマ字テーブル内で自由に定義できない。
   
   「っ」をは別の打ち方を用意しておき、
   「ttk」＝「たたk」のように母音省略時はア段とする･･･なんてこともATOKではできないのだ。

※古いバージョンで定義してインポートするなら一応下段すべてに割り当て可能
だがちょっとした改変がめちゃんこ面倒になるのでそんな方法は使いたくない。

1 > 2 > 3 > 4の順に厳しい。

意外とATOKって貧弱っていうか仕様が古いです。

もしもこの条件がなければ･･･？

定義数に制限がなく贅沢な仕様にできるのであれば、
定義数が数千に膨れ上がる３打で２文字打てる仕組みも採用できただろう。

SHIFTが使えたなら動詞活用にpoliteとcasualを使い分けるなど種類に幅を増やせただろう。
SHFITを拗音としたSKY#や蒼星配列のようなこともできただろう。

右下段も当然の権利のように有効活用していただろう。

しかし制限が多いというのはよいこともあります。
「使える手段が限られているほど考えることは少なく済む」ということです。