日本語を扱え、現在のようなかな漢字変換機能を備えたコンピュータの歴史は意外と浅い。今に近いような形で日本語を扱えた最初のコンピュータは、東芝が発売したJW-10であると思われる。JW-10の発売は1978年、つまり最初のかな漢字変換ワープロが発売されてから現在まで、まだ26年しかたっていないわけだ。（1977年にシャープがかな漢字変換方式のワープロをビジネスショウに参考出展しているが、これは製品化されていない。）
コンピュータで日本語が使えるようになった最初の頃は、日本語入力システムはアプリケーションに組み込まれているものであり、この入力プログラムとあのアプリケーションを組み合わせて、などということはできなかった。これは専用ワープロだけでなく、パソコンでも同じ状況だった。
この状況を変えたのは、バックスのVJE-86である。VJE-86はデバイスドライバとして実装され、キー入力を受けとってアプリケーションに日本語文字列を送ることで日本語入力を可能にしていた。なぜデバイスドライバとして実装されたのかというと、当時の主流OSであったMS-DOSでは同時に複数のアプリケーションを動作させる事ができなかったからである。バックスはVJE-86を日本語入力FEPと呼び、そのうちFEPという語はもともとの「Front End Processer」という意味よりも日本語入力用プログラムという意味合いを帯びてゆく。VJE-86以降、MS-DOS用にATOKや松茸など、数多くのFEPが発売される。そして、マルチタスクをサポートするWindowsの発売により、日本語入力プログラムはドライバではなく普通のプログラムとして実装されるようになる。ちなみに、VJE-86の開発は1983年、発売は1984年の事であったようだ。最初のワープロの発売から最初の日本語入力FEPの発売まで6年しかかかっていない。
さて、Unixでの日本語入力ソフトウェアはどのような変遷を遂げていったかを、簡単に追ってみよう。
ここでは話を簡単にするために、連文節変換を行う変換エンジンのみを扱う。マイコンショウのオムロンブースでWnnが公開された1987年5月には、Unixワークステーションで日本語が使えるのはまだ珍しい事であったようだ。しかし、そんな状況で公開されたWnnは当初から連文節変換やサーバ・クライアント方式など、今とほぼ変わらない特徴を持っていた。他にも、1987年はGNU Emacsを日本語化したNemacsが公開されたり、SKKの開発が開始されたりと、Unixにおける日本語入力環境のターニングポイントとなった年のようだ。公開当時バージョン2だったWnnはその後順調にWnn3(1987年)、Wnn4(1989年)、Wnn4.1(1991年)とバージョンを上げてゆく。
1991年、NECが開発した変換エンジンであるCannaが公開される。公開当時のバージョンは1.2であった。Cannaも順調にCanna2.1(1992年)、Canna2.2(1992年)とバージョンを上げてゆく。
しかし、Wnnは1994年のWnn4.2、Cannaは1996年のVer3.5 β2以降、開発は停滞し、リリースは行われず、そこかしこで私家版パッチが公開されるような状況になってしまった。
このように変換エンジンの開発が停滞状態にあった2000年、田畑悠介氏ら京大マイコンクラブの有志で新しいかな漢字変換エンジンAncy(後にAnthyに改名)の開発が開始される。Anthyは2001年にIPAの未踏ソフトウェア創造事業に採択されるなどして、現在まで順調に開発されている。
なお、Wnn4.2はFreeWnnという新しい名前で1999年に公開される。FreeWnnとWnn4.2の違いは、FreeWnnのライセンスはGPLになっており、改変した場合の再配布が明示的に許可された事である。こうしてWnnはFreeWnn Projectの手に引き渡された。一方、Cannaの方も2002年に相田氏ら有志によって開発が再開されている。
次にコンソールにおける日本語入力システムの変遷を見てゆきたいところなのだが、この分野はあまり進歩のあるところではない。Wnnは公開当時からwnn(ややこしいので、後にuumに改名された)という名前のFEPを持っていたし、それからskkfepやcanfepなどいくつかのFEPがでてきたが、FEPであるという構造自体は変わっていない。
さて、それではX Window System上での日本語入力環境の歴史を見ていこう。まず、X11R3(X Version11Release3)の頃に、kinputというソフトウェアがSRAの石曽根信氏によって開発された。これによりX Window System上で日本語入力が可能となったようだ。この頃はXアプリケーションとkinputの間はkinputプロトコルという独自のプロトコルで通信しており、kinputプロトコルに対応しているアプリケーション以外では日本語は入力できなかった。この状況はX11R4まで続く。
X11R5で、入力システムのための仕様がxlibに規定された。APIのみの規定で、アプリケーションと入力サーバの間のプロトコルが規定されていなかったため、XsiとXimpというふたつのプロトコルが作られてしまうなどのアクシデントもあったが、ともかくxlibに入力システムのためのコードが入ったため、Xアプリケーションに日本語入力用の対応を施すことは格段に簡単になった。プロトコルの問題も、X11R6でXIMプロトコルが規定され、一応の解決をみた。ネット上でいろいろなドキュメントを調べているとkinputプロトコルだとかXimpだとかいう単語をみかける事があるが、現在ではXIMプロトコル以外のプロトコルが使われる事はほとんどないので、XIMと言えばXIMプロトコルを用いてアプリケーションとXIMサーバが通信を行い入力を行うものだと考えてよい。
X11R6.4のリリース後、XコンソーシアムはOpenGroupに吸収されてしまい、XIM自体の開発は終わった。XIMにはいくつかの欠点があったのだが、代替となるものもなく、今日まで多くの人に使われてきている。使われてはいるが、実はXIMにはその開発者自身も含めて多くの開発者が嫌気がさしており、代替となる入力用フレームワークの整備が望まれた。
そこで登場するのがIIIMFである。IIIMFはもともとはSunでSolaris用に開発されていた分散入力メソッドフレームワークであり、2000年9月にオープンソース化され、Linuxなどにも移植された。XIMの反省から、IIIMFはX Window Systemに非依存なプロトコルとして設計され、入力言語の動的切り替えなどもサポートしていたが、オープンソース化されたあともLinuxなどではなかなか普及しなかった。素のXFree86 4.2.0で動かなかった事、ドキュメントが整備されていなかった割にインストールがややこしかった事などが、原因として挙げられるであろう。
IIIMFはなかなか普及せず、2002年8月には、Anthy projectの田畑悠介氏がUIM projectを始める。uimが開発された理由はいくつかあるが、最大の理由はセキュリティである。IIIMFはオフィシャルサイトに「Unlike XIM server running as per-user server, single IIIM server process provides input method service to multiple users in multiple languages simultaneously」と誇らしげに書いてあるように、マルチユーザ・サーバである事が1つのウリであるのだが、これはセキュリティ面では逆にデメリットとなりえる。田畑氏はこの部分を問題視し、セキュリティ面で問題が起こりにくい共有ライブラリ方式で新しい文字入力ライブラリを実装する事にした。メモリの節約になるという事でメリットとして扱われたマルチユーザのサーバ・クライアント形式をセキュリティ面で問題があるとして否定しているわけで、入力システムの世界にもトレンドがあるわけだ。なんとなく面白い。uimはその後2003年4月頃に筆者にメンテナを交代し、2003年度のIPA未踏ソフトウェア創造事業に採択されるなどして、現在まで順調に開発されている。
最後に、GUIライブラリの入力サポートについて少し見ておこう。X Window System上でよく使われるGUIライブラリとしては、Gtk+とQtの2つが挙げられる。Gtk+の方は、バージョン1.2まではXIM関連のコードをソース中にそのまま埋めこんでいたが、2000年11月にリリースされた開発版のGtk+1.3.2からはXIM関係のコードを分離し、モジュール化してしまった。2002年3月に新しい安定版であるGtk+2.0がリリースされ、2004年3月現在では1.2よりも2.xの方が使われる場合が多くなってきている。このモジュール機構はimmoduleと呼ばれており、起動時に動的にロードすることができ、しかも使用するモジュールは動的に切替え可能であるなど、使用する環境をGtk+に限るものの、近代的な入力環境をユーザにもたらした。
QtはXIMのコードがべったりと埋めこまれていたが、Gtk+に似たモジュール機構にXIMのコードを閉じこめてしまうためのimmodule for Qtというプロジェクトが2003年に開始され、2004年3月現在、最新安定版であるQt 3.2.1に対するパッチとして成果物が公開されている。プロジェクトはQt4に成果物を取りこんでもらうために、Qtの開発元であるTrolltech社と現在交渉中である。もともとのパッチはQtのABI (Application Binary Interface)を破壊してしまうものであったが、2004年5月、ABIを壊さないパッチ(BCパッチと呼ばれている)が公開された。BCパッチはQt3へ取りこまれるかもしれない。
このように、GUIライブラリは徐々にXIMへの依存から脱却しつつある。