hechimaは、日本語入力に必要なパーツ（論理配列・かな漢字変換・学習・ユーザー辞書）を ブラウザのページの中に置くためのソフトウェア群です。
そして、ここ「へちま言語ラボ」はその実験場という位置づけです。各ページが、OS組み込みのIMEではできない （あるいはなかなかやりにくい）日本語入力のデモになっています。
日本語入力は、だいたいこの4つの箱でできています。ふだんこれはOSの中にあって、アプリからは触れません。 hechima はこれをページの中に持ってきているので、どの箱でも差し替えられます。
箱を差し替えられるのは、あいだを流れるものの形が決まっているからです。 入力からキーマップへ渡るのは「どのキーをいつ押して、いつ離したか」だけ（フリックなら触った位置と向き、 ゲームパッドならボタンとスティック）。キーマップから変換へ渡るのはかな。 変換から表示へ返ってくるのは文節に区切られた候補の並び。 つまり入力をゲームパッドに取り替えても、出てくるものが同じ「かな」であるかぎり、 その先の箱は何が起きたのか知らないまま動きます。
各実験ページの同じ場所に、そのページがどの箱を差し替えたかを同じ書式で置いてあります。 塗ってある箱が差し替えたところです。
- 標準IME（ローマ字入力） ： キーボードでふつうにローマ字で打って、 スペースキーで変換。OSのIMEを経由せずに違和感なく日本語入力できる、をまず体験してみてください 差し替えた層：なし — 素の hechima。以下はどれも、この状態からどこかを差し替えたものです
- フリック入力 ： スマホ標準のフリック入力キーボードをブラウザ上に再現しました 差し替えた層：入力・キーマップ・表示（キー配置はJSON一枚、候補はキーボード上の帯に）
- 新配列サンプル（薙刀式） ： 新配列対応のデモとして、薙刀式を設定なしに体験できます。 制限だらけの「iPad+物理キーボード」という環境でも動きます 差し替えた層：キーマップだけ — JSON一枚。コードは一行も変えていません
- 縦書きエディタ＆縦書きIME ： 縦書きで書けるテキストエディタと縦書きなIME。 変換候補ポップアップが縦書きの横並びという、理想的なUIです 差し替えた層：表示だけ（ただし候補窓の並びは本文の向きに追随します）
- テーマ連動 ： テーマを切り替えると、本文と一緒に変換候補ウィンドウも着替えます。 ダークテーマのアプリで候補窓だけが白く光る、が起きません 差し替えた層：表示だけ（CSS変数の差し替えだけ。本文と候補窓が同じ変数を見ています）
- 候補の二層化 ： 変換候補を「選ぶ層」と「探す層」に分けます。 ふだん見えるのは5件だけ。残りはTabで開く一覧に送ってあります 差し替えた層：表示だけ（変換は同じMozc。候補の見せ方だけを変えています）
- ゲームパッド日本語入力 ： ゲームパッド（コントローラー）で日本語を入力します。 左手で子音、右手で母音。フリック入力の文法を応用して直感的に文字が打てます 差し替えた層：入力・キーマップ — その先の変換・候補・学習は他ページと同じものです
6つ並べて眺めると、「変換」の箱だけは一度も差し替わっていないことがわかります。 そこが細くて動かない部分で、その上下（入力の手段と、見せ方）はいくらでも増やせる、という形です。
かな漢字変換・学習・テキスト・ユーザー辞書はすべてブラウザ内で完結し、一切外部へ送信されません。 また、学習・テキスト・ユーザー辞書は各実験ページ間で共有されます。
OSの日本語入力と、どこが違うのか
部品そのものは、どれも前からあったものです。新しいのは継ぎ目のほうで、 全部が同じ土俵に、同じ形の継ぎ目で並んでいます。なので違いは「できる／できない」よりも、 試したり差し替えたりするのがどれだけ容易かに出ます。
| 日本語入力の部品 | OSの日本語入力 | hechima（へちま言語ラボ） |
|---|---|---|
| 入力デバイス | できない キーボードと画面キーボードから。ゲームパッドやカメラを入力源にはできない | コードで ブラウザが受け取れるものなら入力源にできる（ゲームパッド） |
| キーマップ（配列） | 一部できる ローマ字の綴りを変えたり、かな入力に切り替えたりはできる。ただし同時押しの新配列は IMEの外（専用ハードや常駐ツール）が要る | データ一枚 JSONの差し替えだけ（薙刀式・フリック） |
| 変換エンジン | 環境による Windows・Mac・LinuxではIMEごと入れ替えられる。ChromeOS（Chromebook）はアプリ形式のIMEを 入れられず拡張機能の範囲まで、しかも学校や職場の貸与機ではそれも管理者次第。 iPad / iPhone に外付けキーボードを繋いだ場合は標準のもの一択 | コードで WebAssemblyを差し替える。いまは Mozc |
| 候補の見た目・並べ方 | ほぼできない フォントや配色を選べるIMEはある。ただしアプリ側からは触れず、 並べ方（何段で、どういう順に出すか）は変えられない | コードで 候補窓もただのDOM。縦書きなら横並び、フリックならキーボードの上、と作り分けられる。 本文と同じCSSを見ているので、配色も書体も揃う（テーマ連動） |
| 見せる候補の選び方 | ほぼできない 表示する件数を設定できるIMEはある。ただし「どれを既定で見せて、どれを奥に送るか」の 決め方はIMEの中に閉じていて、外から変えることも、基準を動かして試すこともできない | コードで 変換エンジンが返すコストを使い、ふだん見せる候補とその先に送る候補に分けている。 分ける基準はその場で動かせる（候補の二層化） |
| 表示・レイアウト | アプリ次第 縦書きに対応したアプリなら縦書きで書ける。macOSの標準IMEは、そうしたアプリでは 変換候補の窓も縦組で出す。ただしブラウザの中の縦書きに対しては、横書きの候補窓が出てくる | コードで CSSで組む。候補窓も本文の向きについてくる（縦書き） |
| 学習・ユーザー辞書 | できる（分けられない） 単語登録も学習もできる。ただし記憶はひとつで、文書やジャンルごとに分ける手段はない （汚したくなければ学習を止めるしかない） | コードで 辞書も学習もこのページの持ち物。将来は文書やジャンルごとに分けられる |
OSのIMEを不当に低く描かないように、できることは「できる」と書いています。 そのうえで残る「できない」が、ここで実験している場所です。 各ページのソースは GitHub にあります。