2.3.3. 関数へのコメント追加

Nixによる別の例 [12] にDMを適用した例を図4に示す． ここではLispプログラム(a)のすべての関数の先頭に コメントを追加し(b)のようにすることが目標である． 長い変換操作が必要となっているが， 繰り返しの2回目の最初の操作を行なった後でを入力すると (b)のような結果が得られ，以後を入力する度に次の関数の 先頭にコメントが挿入される．

  図4. Lisp関数へのコメント追加([12]の例)

2.3.4. DM試用ウィンドウ

Java対応ブラウザを使用することにより、以下のウィンドウで 実際にDMを試用することが可能である。 Emacsのコマンドのサブセットを使用できる。 としてControl-Tを使用する。

2.4. DMの利点

DMには以下のような利点がある．

使用法が単純

使用するキーはのみである．また繰り返し操作において どの時点でを入力しても同様の結果が得られる．

広い範囲に適用可能

単純な機構にもかかわらず，前節の例のような複雑な繰り返し操作にも 適用できる．

実装が簡単

システムはが入力されない限り操作の履歴を保持するだけでよいし， 規則1，規則2は高速に実行することが可能である． 履歴保持のオーバーヘッド及び計算コストについては 5.2節で詳しく述べる．

ユーザの邪魔をしない

普段システムは操作の履歴をとっているだけなので，そのために 動作が遅くなったりすることはない． またを入力しない限り予測は実行されないので 予測機能を使わないユーザの邪魔になることがない．

汎用

DMはテキストエディタ以外にも適用可能である．

2.5. DMの問題点

DMの最大の問題点はユーザの期待と異なる予測を実行する可能性が あることである．例えば， の後でを入力すると 規則1が適用されてが実行されるが，ユーザは を期待しているかもしれない． 規則2が規則1より優先するようにすればこの場合ユーザの期待どおりに なるかもしれないが， ``bab long-forgotten-sequence abab'' のような操作の後でを入力すると， ``ab''のかわりに忘れられた昔の操作列が実行されてしまうことに なり望ましくない． また， ``abracadabra ab''の後でを入力した場合， ユーザは``racadabra ''を期待しているかもしれないが， 規則2により``ra ''が実行される． DMは予測手法のひとつであるため，どんな場合でも ユーザの期待通りの動作をするような仕様を設定することは不可能であるが， この問題は新たに「予測キー」(以降と表記) を導入することにより解決する．

3. DMと既存の予測手法の融合

3.1. 既存の予測手法

テキストベースのプログラムにおいて各種の予測手法が現在広く使用されている． 例えばUNIXのシェルでは以前発行したコマンドに対しその省略形を 指定するだけで再実行することのできるヒストリ機能や， ファイル名の先頭だけ指定すると残りの名前を示してくれる コンプリーション機能がよく使われているし， GNU Emacsではテキスト中に既に現われているの別の文字列を参照して 次の入力を予測するdabbrev機能が広く使用されている． これらの例のいくつかを図5に示す．

  図5. 各種の予測手法の比較

これらの多くのものは， ユーザの指示により何らかの方法で次の操作を予測して それをユーザに提示するという型式になっているため， 予測手法毎に異なるキーを割りあてず， 順番に各種予測を適用していくことにより， 単一の「予測キー」()を用いて実装することができる． 次のユーザ入力をファイル名から予測する手法と 辞書エントリから予測する手法を併用した例を 図6に示す．

  図6. ファイル名からの予測と辞書を用いた予測の併用

が最初に入力された場合はその時点で一番もっともらしい 方式により次の操作を予測してユーザに提示する． 続けてが入力された場合は前の予測を撤回して 次の予測をユーザに提示する．

3.2. 予測キーと繰返しキーの併用

とを併用することにより， 前節で述べたDMの問題点が解決されるだけでなく， さらに複雑な各種の予測手法を使うことが可能になる． DMの最大の欠点は，予測がユーザの期待と異なっていたとき 修正不可能なことであったが， を用いることにより， 期待と異なる予測が得られた場合の動作を変更することができる． 前節で述べたように， の後でを入力すると規則1が適用され が予測されるが， この状態でを入力すると次侯補である規則2が 適用されるようにすると， が予測されるようになる． これがユーザの期待と一致する場合は，この後再び を入力することによりこの予測結果を繰り返させることが できる．この様子を図7に示す．

  図7. による予測手法の切り替え

また前節で示した別の例に対して同じ手法を適用 した結果を図8に示す．

  図8. による予測手法の切り替え

またの意味を拡張し，が押された後で が入力された場合は直前の予測方式を繰り返すことにすると， 図9のように， で予測手法を選択した後でその実行を 繰り返させることができる．

  図9. 予測手法を選択後同じ予測を繰り返す

最初のが入力されたときシステムはその前の入力列を ASCII文字列と判断して`` ''を予測し実行する． このときシステムは``ASCII文字列予測モード''になっているため， ここでユーザはを入力することにより 次のASCII文字``; ''を予測させることができる． 最初の予測がユーザの期待と異なっていた場合， ユーザがもう一度を入力するとシステムは今度は 前の入力列を10進文字列と判断して``10進数予測モード''となり ``10 ''を予測し実行する． これがユーザの期待と一致していた場合は を入力することにより ``11 '', ``12 '', ... を順に予測させることができる．

同様の手法を用いて 図10のようにLaTeX文書の作成に応用することもできる． システムは% 最初の が押されると ``\begin''からitemize環境であると判断して itemizeモードに状態遷移しつつ ``\begin{itemize}'' ... ``\end{itemize}''を予測する． このモードにおいてが入力されると システムは``\item''を予測する． ユーザの期待がitemizeでなかった場合， ユーザが最初のに引き続いてもう一度を 入力すると，今度はシステムはdocumentモードに遷移しつつ ``\begin{document}'' ... ``\end{document}''を予測する． ここでが入力されると システムはモードの知識により``\section{}''を予測する．

  図10. LaTeXプリミティブの予測

このとの機能を整理すると 図11のようになる．

  図11. とによる状態遷移

ここで，Sは予測戦略， Cは現在のコンテキスト， P,Rはそれぞれ とが押されたとき実行すべき操作列を S及びCから計算する関数， p,rは計算された操作列を保持するための変数を示す． Sp1, Sp2, Sr1, Sr2は とが押されたときの遷移状態を示し， 図11の遷移図のように状態遷移する． 例えば初期状態においてが入力されるとシステムは状態 Sr1に遷移し， 予測戦略としてDMを選択し，これにもとづいて 操作列を予測し実行する． そこでが入力されると状態は Sp2に遷移し，前の予測を撤回して 新たな予測を実行する． このようにとを併用していろいろな 順番で使用することにより，DMの欠点が解消されかつ 各種の予測手法を適用することができる．  

4. 評価

本システムを多くのEmacsユーザに配付して 1年以上にわたり反応を調査した． また数人のユーザに予測操作のログを取ってもらうことにより 予測の的中率や実際の使われ方を調査した． この結果は以下のようになった．

• 評判はおおむね良好であった．特にキーボードマクロを普段 あまり使っていないようなユーザには好評であった．

• 逆にEmacsのエキスパートは本システムをあまり有難いと 思わないようであった． この原因は，そのようなユーザはキーボードマクロ を普段から多用しているため使用を面倒だと思わないためと， 各種の繰り返し操作に対応する機能/関数について 熟知しているので自分でマクロを定義する必要があまり無いため であると思われる．

• 予測の的中率(1回目のまたはによる システムの予測がユーザの期待と一致する割合)はユーザにより かなり異なっていた． 最高は100%であったが，このユーザはごく稀に(月に数回)しか予測機能を 使用せず，またその際には非常に慎重に入力を行なっていた． 逆に，間違った予測にはundoで対処すればよいと考えるユーザは 気軽に予測インタフェースを使用するが，的中率は低かった． 平均すると的中率は約85%であった．

• により予測されるキーストローク長の平均値は 約5であり，キーストローク数が3または4の予測が最も多かった． これはDMによる予測方式が，短いキー操作列の繰り返しに対し 効果的であることを示している． 長いキー操作列の繰り返しに対してはキーボードマクロが有効であり， ごく短いキー操作列の繰り返しに対してはマクロ定義が無意味であるが， DMはその中間程度のキー操作列の繰り返しに対し有効であることが わかる．

5. 議論

5.1. 予測インタフェースの条件

一般に予測インタフェースは以下の要件を満たす必要があると考えられる．

 
1. 予測を実行させる手間が小さいこと  
2. 予測がユーザの期待に一致する確率が高いこと  
3. 予測機能を使わないユーザの邪魔にならないこと  
4. 予測の実行に対しユーザが不安にならないこと

本システムではふたつのキーしか使用しないため 予測のための手間は最小限に押さえられている． 4節で述べたように 予測結果がユーザの期待と一致する確率は非常に高い． 予測実行キーを入力しない限り予測機能は実行されないし 予測に使用する操作履歴を保持することによるオーバーヘッドも小さいため 予測機能を使用しないユーザの邪魔にはならない． またGNU Emacsでは予測の実行結果は常にundoにより取り消すことが できるためユーザが不安を感じることはない*． このように本システムは上述の要件をすべて満たしている．
*次の操作を予測可能であることを 音や表示によりユーザに知らせるシステムも提案されているが [2] [4] [8]， 予測機能にあまり頼らないユーザにとってはかえって迷惑となる ことの方が多い．  

5.2. 履歴保持のオーバーヘッドと予測のための計算コスト

DMによる予測を行なうためには システムは常にユーザの操作履歴を記憶しておく必要がある． GNU Emacs Version18は常に100個のキーストローク履歴を保持しており， (recent-keys)関数で参照することができるため， これを用いてDMを実装しているが， このとき規則1では50キーストローク， 規則2では最高99キーストロークまでの繰り返しパタンを 認識可能ということになる． 実際には50キーストロークにも及ぶ操作を繰り返すことは稀であるから 履歴はこの程度保持しておけば充分であり， そのためのオーバーヘッドは小さい．

現在の実装では規則2のXの長さを1からひとつずつ 増やしながらXYXというパタンを検索しているため， 規則1/規則2を満たす文字列を捜すのに 最悪O(n^2)(nは履歴文字列長)時間が必要であるが， 実際の使用場面においては繰り返されるキーストローク長は 4節で述べたように 平均して3から4程度であり，Xが10ストローク以上となる ことは稀であるため，使用に関して予測の遅さが問題になることは ほとんどない． またDMでは予測のために時間がかかるのはを最初に 押したときのみで，続けてを押したときは予測のための 時間はかからないため 5.1節の要件3が満足されている ことになる． これに対し，各キーの入力時にキーストローク履歴の部分文字列を トライ構造などで記憶しておけば規則1/規則2の実行は高速になるが， あらゆるキーストロークに対しこのような処理を行なうと 要件3が満たされなくなる可能性があるため 得策ではないと考えられる．

5.3. かな漢字変換との類似性

はかな漢字変換方式の 日本語入力システムにおける 「漢字変換キー」または「次侯補キー」と似た動作をする． 実際「漢字変換キー」を図6と同じように使って ローマ字文字列をかな文字列，漢字文字列に順次変換していくような かな漢字変換システムも存在する． このような性質のためは かな漢字変換システムに慣れたユーザにとってなじみやすいし， また本システムのような予測インタフェースを かな漢字変換システムと融合して使用することも可能である．

5.4. DMが効果的に働く理由

グラフィックインタフェースに予測を用いる研究が近年盛んに 行なわれているが， グラフィックインタフェースにおいては ユーザの意図を正しく理解することは本質的に困難であるため [1]， システムが間違った推論を行なわないようにするため 問題を簡単化したりヒューリスティクスを使ったり 頻繁にユーザに問いあわせを行なったりしているものが多い [14]． これに対し本システムではテキスト操作に限ってはいるものの 簡単な規則で予測インタフェースが成功している． この大きな理由のひとつとして，Emacsではユーザの意図と操作が ほぼ1対1に対応している点がある思われる． Emacsでは例えばユーザがカーソルを行頭に動かしたい場合はを 入力するし，左に何文字か移動させたい場合はを文字の 数だけ入力する． このように，Emacsでは同じようにカーソルを左に動かす場合でも その意図によりユーザの操作は異なっているのが普通である． これに対しグラフィックの直接操作インタフェースでは， 例えば図形をマウスで左にドラッグしたとき， それが画面の右に場所を空けるためなのか， 移動量が重要なのか， 別の図形と位置を揃えるためなのか， などが操作のみからは判断がむずかしいため 推論が困難になっているわけである． Emacsではユーザの意図を反映した機能が別々の操作として あらかじめ用意されておりそれをユーザが実際に区別して使用するため， システムがユーザの意図をくみとって予測を行ないやすいということができる． この点を考慮すると， グラフィックインタフェースにおいてもユーザがその意図を 常に無意識にシステムに知らせ続けることができれば 効果的な予測インタフェースが構築できると考えられる．

5.5. 本方式の限界

近年提案されている各種の例示/予測インタフェース手法に比べると とによる予測手法は貧弱である． 予測手法はその実行時点における操作履歴や コンテキストのみから決定しなければならず， 複数の例を使ったり以前の予測を参考にしたりすることが できないため， 汎化を行なったり条件判断動作をさせることができない． またユーザは予測結果のみを見て予測手法が適当かどうか 判断しなければならないが，常に予測方式を予測結果から 正しく判断できるとは限らない． また一度選択した予測手法は後で編集したり再利用することが できないため，どうしても使われるのは簡単な予測手法ばかり ということになってしまう． 本方式は，強力な予測を行ないたい場合よりは， 単純な予測を手軽に使いたい場合に有効だということができる．

6. 結論

文書の入力/編集作業において とというふたつのキーのみを用いる 予測インタフェース手法を提案した． 本手法は単純であるにもかかわらずキーボードマクロをはじめとする 従来の各種手法にない特長を持っており適用範囲が広い． 今後は本手法を文書編集以外の領域にも適用していく予定である．

7. 謝辞

DMの実装，評価にあたり数多くの有益な助言をいただいた 長岡技術科学大学の太和田誠氏ならびに シャープ株式会社の舟渡信彦氏，市川雄二氏，及び今井明氏に 感謝します．

1.   Bos, E.: Some Virtues And Limitations Of Action Inferring Interfaces, Proceedings of the ACM Symposium on User Interface Software and Technology (UIST'92), ACM, ACM Press, 1992, pp.79-88.
2.   Cypher, A.: EAGER: Programming Repetitive Tasks By Example, Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI'91), ACM, Addison-Wesley, 1991, pp.33-39. also in [3].
3.   Cypher, A. (ed.): Watch What I Do - Programming by Demonstration, The MIT Press, Cambridge, Massachusetts, 1993.
4.   Darragh, J. J., Witten, I. H., and James, M. L.: The Reactive Keyboard: A Predictive Typing Aid, EEE Computer, Vol. 23, No. 11 (1990), pp. 41-49.
5.   Halbert, D. C.: Programming by Example, Technical Report OSD-T8402, Xerox Office Systems Division, 1984.
6.   Kurlander, D. and Feiner, S.: A History-Based Macro By Example System, Proceedings of the ACM Symposium on User Interface Software and Technology (UIST'92), ACM, ACM Press, 1992, pp. 99-106.
7.   Maulsby, D. L., Witten, I. H., and Kittlitz, K. A.: Metamouse: Specifying Graphical Procedures by Example, SIGGRAPH'89 Proceedings, ACM, 1989, pp. 127-136.
8.   Micro Logic Corp.: KeyWatch, POB 70, Hackensack, NJ 07602, 1990.
9.   Mo, D. H. and Witten, I. H.: Learning text editing tasks from examples: a procedural approach, Behaviour & Information Technology, Vol. 11, No. 1 (1992), pp. 32-45. also in [3].
10.   Myers, B. A.: Creating User Interface by Demonstration, Academic Press, San Diego, 1988.
11.   Myers, B. A.: Demonstrational Interfaces: A Step Beyond Direct Manipulation, IEEE Computer, Vol. 25, No. 8(1992), pp. 61-73.
12.   Nix, R. P.: Editing by Example, ACM Transactions on Programming Languages and Systems, Vol. 7, No. 4 (1985), pp. 600-621.
13.   増井俊之, 太和田誠: 操作の繰返しによるマクロの自動生成, 情報処理学会ヒューマンインタフェース研究会研究報告 93-HI-48, Vol. 93 (1993), pp. 65-72.
14.   萩谷昌己: ビジュアルプログラミングと自動プログラミング, コンピュータソフトウェア, Vol. 8, No. 2 (1991), pp. 27-39.