前回もお伝えしたように，そもそも TSF の話を急いでする必要はなくなりました．

今後 Legacy IM が TSF で置き換えていく流れが確実になっているとはいえ，これで当面急いで TSF に乗り換える必要は無いと思います．

そういうわけでしばらく時間をおいてもいいのですが，いったんまとめかけていた資料を後でまた掘り起こすのが大変なので，ここで軽く書ききってしまうことにしました．全く持って需要がなさそうな記事ですが，しばらくおつきあいくださいませ．

まずは，Windows の Input Method の歴史から見ていきましょう．



余談その 2 - テキストストアを活用した変換候補の選択 TSF ではテキストストアと呼ばれる仕組みでテキストサービス (TIP などの入力サービス) がアプリケーション中のテキストデータにアクセスできるようにしています．

この仕組みの応用として誰でも考えつきそうなのが，入力箇所の前後のテキストを変換候補の評価材料に使用するというものです．当然のごとくこれは実装されているので，実際に実験してみましょう．

TSF に対応したアプリケーション，例えば Microsoft Word や Wordpad で，「危機」という単語を書いたファイルを開いて見てください．公正を期すためには，「危機」の入力は，コピーアンドペーストなど漢字変換を使用しない方法で入力した方が良いでしょう．

次にファイルを開き，「危機」の直後に caret を移動し，「いっぱつ」と入力して変換してみてください．MSIME ならば，おそらく「一髪」を変換候補として選ぶはずです．テキストストアを通じて caret 直前に「危機」という文字があることを MSIME は知っています．そのため，何もない箇所での変換候補第一位である「一発」ではなく，「危機一髪」が期待されている確率が高いと判断して「一髪」を選んだと考えられます．この機能，実は 5 年前の MSIME 2002 で既に実現されています．

左は TSF ネイティブ対応した Wordpad，右は TSF 未対応で CUAS 制御下の EmEditor 6．TSF に対応している場合としていない場合で変換結果が異なる． 残念ながら TSF に対応していない ATOK 2007 で実験すると，いずれの場合も候補として「一発」を提示しますが，それも ATOK が TSF に対応し，同じ条件に立つまでの話でしょう．TSF への対応によって，定評のある ATOK の漢字変換の精度がより向上するものと期待しています*6．

( 2011 年 2 月 13 日追記 : IMM32 ベースの ATOK でも，設定の「入力・変換」→「変換補助」→「ｶｰｿﾙ位置前後の文章を参照して変換する」を有効にすると，IMM32 の IMR_DOCUMENTFEED を利用した前後変換は可能です)

なお，このテキストストアという仕組みを自然に応用したのが，以前の Microsoft Office に付属していた Natural Input でした．Office に付属させるにしては明らかに従来の仕組みと違いすぎるという点では強く同意しますが，かといって完全に葬ってしまうのももったいない技術だったと思います．提供の仕方を間違えなければ，一定のファンは確保できたかもしれません．

(追記) なお，IMM32 ベースでも前後の文字列を変換に利用することは可能です．Word などはもちろんのこと，近年では 秀丸が対応した例 などがあります．



次回は Windows 次回は Windows SDK に付属する TSF のサンプルの紹介と，Thread Manager の使い方について．

ちょうどいい具合に Windows の Text Input の歴史が整理してある資料があります．それが今や 黒歴史 の祭典ともいうべき PDC 03 の PPT というのは何とも皮肉な話ですが，この PPT の 8 枚目をご覧ください．ただしこの図ではテクノロジのリリース時期と対応 OS の関係が分かりにくいので，別の図を用意してみました．いくつか注目すべき点を挙げておきましょう．