2003年度森基金研究成果報告

モバイル機器におけるエンドユーザプログラミング

はじめに

本節ではまず，本研究の背景として，携帯端末におけるプログラミングを実現する際の問題点を示す．次に，本研究の目的と提案するシステムの利用例について述べる．

背景

近年，携帯電話やPDAに代表される携帯端末の多機能化と多様化が進んでいる．例えば携帯電話は元々ただの電話であったのが，メールやアラーム，個人情報管理やウェブ閲覧の機能が追加されてきた．最近では，GPSやカメラなどの機能も追加されている．携帯端末の多機能化により，ユーザの携帯電話の使用形態も多様化している．GPSにより取得した現在位置をカメラで撮った画像に付加し，メールとして送るといった作業が日常的に行われている．多機能化と多様化により，ユーザの使用形態に合わせて個々の機能を自由に連携したいという欲求が生じてくる．デスクトップ上で複数の機能を連携するためには，ユーザはシェルスクリプトのような簡単なプログラミングを用いる．よって，携帯端末で個々の機能を自由に連携するためには，携帯端末上においても同様にプログラミングを行えるようにすれば良い．

しかし現状では，携帯端末上でのプログラミングは一般的でない．普及していない理由として次の二点が挙げられる．一点目としては，プログラミングの物理的な困難さが挙げられる．テキスト形式のプログラミングはインタフェースの制約により困難である．そのため，多量の文字入力や，広い表示画面を必要としないプログラミング環境が必要である．

二点目として，コンテクスト情報を扱うことの難しさがある．携帯端末の特性を活かしたプログラムは，時間や位置などのコンテクストに応じたパタンマッチや条件分岐を行える必要がある．しかし，現状ではプログラム中でGPSなどのセンサ情報をユーザが簡単に取得する手段が用意されていない．また，それをユーザが手軽に利用できる言語もない．例えば，GPSによる位置の情報があったとしても，「駅前にいる」というコンテクストを条件式に書くのは困難である．

本研究の目的

本研究の目的は，ユーザが携帯端末上で手軽にコンテクストを利用したプログラミングを行えるシステムを提案することである．本システムにより，ユーザが自分の行動や要求に合わせてプログラミングを行えるようになる．

本システムが想定する利用例を次に示す．ある会社員が「毎晩会社から帰宅する時，駅近くで携帯電話を使って電車の時刻を調べ，何時に帰宅するかを携帯電話で自宅にメールを送る」，という行動を日々行っていたとする．この例の場合，「毎晩」や「帰社時」という時間と，「駅近く」という位置から処理の定型性が判断できる．このようなコンテクスト情報をプログラムに組み込むことで，コンテクストが一定条件を満たすときに自動的に実行できるようになる．以下にこの例をプログラムとして記述した場合の実行手順を示す．

1. コンテクストを取得し，「毎晩」や「帰社時」,「駅近く」と比較
2. ブラウザを起動
3. 時刻表サービスを取得
4. 取得した情報をメールで家に送信

一旦プログラムができあがれば、それを編集・改変することで複雑なプログラムにすることも可能である．例えば，もしユーザがメールで家に送信するのではなく電話をかけたくなった場合には，このプログラムの最後の部分を編集し，メールか電話を選択できるようにすることが考えられる．

設計

設計方針

本システム全体の設計方針として次の三点を掲げる．

• 携帯端末のみでプログラミング可能である
• 携帯端末の持つ機能を組み合わせるグルーとなる
• 携帯端末の持つセンサや他の機能の実行結果をコンテクスト情報として扱える

このようなシステムを実現するためには，背景でも述べた以下の二点の問題を解決する必要がある．

1. 制約の多いインタフェースでも利用可能なプログラミング環境の実現
2. コンテクスト情報の容易な取り扱いの実現

一点目の問題解決として，携帯端末でのアプリケーションやサービスの実行を行うプログラムを作成するために，例示プログラミングやビジュアルプログラミングの手法を用いる[10][11]．例示プログラミングは，ユーザの行動例や履歴から特定のパターンを認識し，汎化することで定型的なプログラミングを行う手法である．ビジュアルプログラミングは，テキスト以外の図形などのビジュアルな情報を用いて行うプログラミングである．

これらの手法は，これまではほとんどデスクトップ上の環境を対象とした研究しか行われてこなかった．さらに，デスクトップ上の環境で実用化された例は少ない．しかし最近になって，携帯端末において，これらのプログラミング手法が有用であるという例が示されるようになった[4][1]．これは，携帯端末がデスクトップよりも制約の多い環境であるためだと考えられる．

二点目の問題解決として，携帯端末のユーザが，蓄積した実行履歴の汎化によって，曖昧なコンテクストを条件としたプロダクションルールの組み合わせとしてプログラムを作成できるようにする．コンテクストを用いたプログラムは，あるコンテクストに応じて何かのプログラムを実行するものであることが多いため，単純なルールベースのプログラムとして表すのが良いと考えられる．

本研究では，図2.1.1[各要素の関係]のように，上で挙げた要素を統合したシステムの提案を行う．以下に，各々の要素の関係について述べる．

一つ目はコンテクストアウェアネスと例示プログラミングの関係である．例示プログラミングの欠点として汎化の難しさがあるが，コンテクストには自然な制約条件があるので，汎化の候補を減らすことができる．また，具体的な事例から一般化を行うのは，コンテクストアウェアネスの考え方とも合致する．

二つ目はコンテクストアウェアネスとビジュアルプログラミングの関係である．ビジュアルプログラミングにより，画面サイズなどにより困難であるテキストのプログラミングから離れられる．コンテクストを視覚的に表現することにより，ユーザが手軽に扱える環境を提供できる．

三つ目は例示プログラミングとビジュアルプログラミングの関係である．ビジュアルプログラミングには一からプログラムを書くのが大変という問題があるが，例示プログラミングによって生成したプログラムをビジュアルプログラミングを編集可能とすることで，この問題を解決できる．

四つ目はコンテクストアウェアネスとプロダクションルールの関係である．プログラム内でコンテクスト情報を扱う簡便な方法として，プロダクションルールの条件部にコンテクストを記述する．

例示プログラミングとプロダクションルールの関係，及びビジュアルプログラミングとプロダクションルールの関係については，既に例示プログラミングやビジュアルプログラミングのバックエンドとしてプロダクションルールが有用であることが示されている[10][11]．

システムの構成

本論文では，現時点での成果として，ビジュアルプログラミングを除いた部分の統合手法の設計・実装について述べる．本論文で取り扱うのは，例示プログラミングの手法を用いて，プロダクションルールの条件部をコンテクスト情報の汎化によって生成する部分である．

プロダクションルールによるプログラムの記述

プロダクションルールの条件部をコンテクスト，行動部をアプリケーション実行とすることで，最も単純なコンテクストアウェアプログラムを記述できる．例えばリスト2.2.1.1[プロダクションルール例]のように表す．

if (時間 = 「夜」 & 場所 = 「鎌倉駅」) then (「時刻表を開く」)

より複雑なプログラムを記述するためには，ユーザが定義したシンボルや，「あるアプリケーションが実行された」というイベントなども条件部に含めることが必要であるが，ここでは議論を単純にするために，条件部に含まれるのはコンテクスト情報のみとする．

プログラムの作成

ユーザが直接プロダクションルールを記述するのは難しいため，例示プログラミングの手法を用いる．したがって，プログラムの作成は記録段階とルール化段階の二段階に分かれる．

記録段階(図2.2.2.1[記録の段階])では，ユーザはプログラミングを行いたい状況において，実際に操作する．この際，システムはその時点で取得可能なコンテクストを得る．このコンテクストを条件，ユーザの操作を行動とした，条件と行動の組み合わせを事実として蓄積する．

ルール化段階(図2.2.2.2[ルール化の段階])では，蓄積された事実からルール化の対象を選択し，条件部のコンテクストを汎化することで一般的なルールを作成する．汎化手法は，単純な推論により複数の汎化候補を優先度付きで生成し，ユーザが選択する，半自動的な方法である．

例えば，「夜鎌倉に来たときは時刻表を開く」という例の場合，まず記録段階として，ユーザは何度か実際に夜鎌倉において，本システムから時刻表サービスを起動することで，事実を蓄積する．

記録段階において蓄積された事実が「19:00」と「鎌倉駅東口」，「20:00」と「鎌倉駅西口」だとすると，時間は「19:00-20:00」，「夜」などと汎化可能であり，位置は「鎌倉駅」，「鎌倉」，「駅」などと汎化可能である．ルール化段階においてシステムが提示するコンテクストの汎化候補のリストは，時間に対しては「19:00-20:00」-「夜」-「いつでも」，位置に対しては「鎌倉駅」-「鎌倉」-「駅」-「どこでも」などとなる．

プログラムの実行

プログラムの実行は，作成されたルールが発火することにより行われる．システムは継続的に現在のコンテクストと，プログラム中の各ルールの条件部が合致するかを検査し，合致する場合は，行動部のアプリケーションを起動する．

プログラムの起動に関しては，いくつかの制限を設ける必要がある．例えば，実行の猶予期間を設ける必要がある．これは条件が満たされてからしばらくした時点で実行するという制限である．位置のコンテクストや温度のコンテクストなどの場合，あるコンテクストからあるコンテクストに切り替わる境界が存在するが，電車などで高速で移動している最中はその境界を次々と越えてしまうため，様々な望まないイベントが実行されてしまうかもしれない．例えば，電車に乗っているときに，「駅」にマッチするイベントが通る各駅で実行されてしまうと問題である．そのため，実行までの猶予期間に条件を外れてしまった場合には実行しないにようにするなどの工夫が必要となる．

状況範囲の定義

コンテクスト情報を得るために利用できるセンサの数がn個であり， それぞれのセンサの取り得る値の全体集合をとする．ある事象が発生したときのセンサの値の組$(x_1,x_2,·,x_n)$を，その事象の状況と呼ぶ．なお，以下では説明を簡単にするため，利用できるセンサは時計だけとし，取り得る値は0:00から23:59までとする．

プロダクションルールの条件部に書きたいのは，特定の状況ではなく，状況がある範囲に含まれるという条件式である．ユーザが範囲を指定するためには，範囲にラベル付けする必要がある．これを状況範囲(Situation Range;以後SRと略す)と呼ぶ．時間のSRであれば，「19時頃」や「19:00-20:00」，「夜」などが範囲のラベル付けである．

ここでSRをどのようにして定義するかという問題が生じる．SRの定義をユーザがテキストで入力すると，例示プログラミングのメリットが薄れる．また，事例からSRを生成するとした場合，充分多くの事例が蓄積されるのを待つ必要がある．本研究では，事例一個からでも手軽にプログラミングすることを考えているため，あらかじめSRの集合が与えられているものとする．このSRは，プログラミング環境の一部として，多くのユーザが共通して使うであろうラベル(「19時頃」や「夜」)を用意することを想定する．

次に問題になるのは，人間にとって使いやすいラベルは明確な範囲ではなく，曖昧な範囲が多いことである．例えば「19時頃」は，人によって18:50-19:10であったり18:55-19:05であったりするし，どちらでも構わないというユーザも多いと予想される．また，複数の事例がある場合に，定義された範囲からわずかに外れた事例が一つ存在するからといって，それを汎化候補から除外してしまうのは，あまり直感的とは言えない．

そこでSRをファジィ集合で表すことにする．例えば，「19時頃」というSRは次のようなメンバシップ関数 μを持つファジィ集合で表す(図2.3.1[「19時頃」のメンバシップ関数])．ただし，t の値は00:00からの秒数となっているので，67800は18:50，68160は18:56，68640は19:04，69000は19:10に対応する．

SRをファジィ集合で表すのは，汎化候補をユーザに提示する際にわかりやすいラベルを付け，次節で述べるようにその優先度を計算するためである．生成するプロダクションルールの実行部は，実行するかしないかの二者択一であるため，条件部はクリスプ集合でなければならない．したがって，実行時には，SRはメンバシップ関数の値がある閾値以上の区間からなるクリスプ集合として扱う．

この閾値は，プログラムの実行時にユーザが上下させることによって，動作の微調整が可能である．実行した結果，ルールの発火範囲が広すぎると感じる場合は閾値を上げ，狭すぎると感じる場合は閾値を下げる．

コンテクストの汎化方法

SRが表す範囲の広さは様々である．例えば，「19:00」という特定の状況だけを含むものから，「19時頃」，「夜」，「いつでも」といった広い範囲を表すものまである．

ある状況が与えられた時に，それをどのようなSRに汎化するかということがここでの問題である．通常の集合であれば包含関係によって半順序が定義でき，それによって汎化の候補が得られるが，ファジィ集合の場合はさらに帰属度を考慮しなければならないので，問題はより複雑である．

与えられる状況は正事例のみで負事例は含まない．また，状況の個数は一個しかない場合も考えられるので，自動的に適切な汎化を行うのは困難である．したがって，システムが汎化候補のリストを提示し，ユーザがその中から一個を選ぶ，半自動的な汎化方式とする．

汎化候補が多い場合は，すべてを表示できないので，その中から何個かを選ばなければならない．また，リストを表示する際に，どのような順序で表示するかということは，ユーザの使用感に大きな影響を及ぼす．そのため，汎化候補に対して優先度を計算し，優先度の高いものから表示を行うことにする．優先度の定義は次のようにする．

ルール化段階における，システムが行う汎化候補の提示処理の流れは，次のようになる．

1. すべてのSRに対して:
   • すべての与えられた事象の帰属度を計算する
   • 帰属度0の事象がなければ，そのSRを汎化候補リストに追加
2. 汎化候補リストに含まれるSRの優先度を計算
3. リストを優先度が大きい順にソートし，最初の数個のみを表示

実装

上記設計に基づき，プロトタイプとなるプログラミング環境を実装した．今回は，(1)事実の記録，(2)コンテクストの表現，(3)コンテクストの汎化，(4)ルール一覧，の4部分について実装した．以下に各部分について記述する．

プラットフォームとしては，Sharp Zaurus SL-C760とQT Embedded/Qtopiaを用いた．

事実の記録

記録段階においてユーザがアプリケーションのリストから選択・実行することで，システムは実行した項目とその時点のコンテクストの対を事実として記録する．その記録は操作履歴として利用可能になる．

事実のデータはXMLで記録される．各fact要素の中に，context要素とaction要素の対を持つ．

コンテクストの表現

使用するコンテクストは，今回の実装では日付情報と時間情報，位置情報のみに限定している．センサデータの取得先として，日付情報と時間情報はシステムの時計，位置情報には赤外線タグを用いた．

コンテクストの種類を問わない抽象クラスとして，Contextクラスを用意した．その派生として，「3月頃」「春」などの日付コンテクストはDateContextクラス,「19時」や「夜」などの時間コンテクストはTimeContextクラス，「鎌倉」などの位置コンテクストはLocationContextクラスを実装した．

状況はコンテクストの集合の積であるが，これはContextsクラスとして表現した．Contextsクラスは内部でContextのリストを持つ．また，各ルールは条件部としてContextsを持つ．

コンテクストの汎化

ルール化段階において，ユーザは操作履歴から実際にルール化したい事実を単数または複数選択する．選択された事実に基づく汎化候補リストをシステムが提示するので，ユーザがリストの中より適切な候補を選択することでルール化する．

図3.3.1[コンテクスト汎化画面]は，選択した事実のコンテクストを汎化する画面である．この例では，2003年11月11日19時1分50秒と2003年11月12日19時5分57秒にに"Search TimeTable"を実行した事実がある．ユーザは事実のリストよりその二つの事実を選択し，NewRuleボタンを押す．すると，コンテクスト汎化のためのダイアログが開く．システムは，各コンテクスト毎に2つの事実に対する優先度の高い汎化候補のリストを作成し，リストボックスとしてユーザに提示する．ユーザは汎化候補リストの中より適切な汎化候補を選択する．この例の場合では，汎化候補リストは"about 19:00"-"19:00-20:00"-"evening"-"any"となっており，ユーザは"evening"を選択しようとしている．必要のないコンテクストは"any"とする．例えば時間にとっての"any"は「いつでも」ということを意味する．

ルール一覧

事実データと同様に，ルールデータもXMLで記述する．事実のXMLとの違いは，各ルールを使用するかどうかを表すenable要素・属性の追加である．ルールは，ProductionRuleクラスで表現する．ProductionRuleクラスは，条件部としてContextsクラス，行動部としてActionクラスを持つ．

リストの中よりルールを選択することで，「ルールの条件コンテクスト」と，「実際に使用するかどうか」の選択が表示される．ルールを使用したい場合には，明示的にenableをtrueにする必要がある．図3.3.2[ルール画面]は，生成されたルールの画面である．

例示プログラミングの問題点検証

例示プログラミングの問題点検証として，文献[6]で提案されている評価基準を用いた．以下に，この基準の各項目についての評価を示す．

問題がない場合は「○」，問題が若干ある場合を「△」，大きな問題が有る場合を「×」とする．

プログラムを作成できない-○

ユーザの行動をプログラムとして作成可能とした．

プログラム作成のための指示が面倒-○

ユーザが行うのはアプリケーションやサービスの実行とリストによる汎化選択のみであり，指示は面倒ではない．

プログラム実行のための指示が面倒-○

実行のための指示は，リストの中から選択するだけであり面倒ではない．将来的には自動的に実行可能とする．

正しいプログラムの作成が困難-△

作成されるプログラムは単純なルールベースであり，正しいプログラムの作成は困難ではない．しかし，ユーザが選択を誤った場合は問題となるかもしれない．

実行に関するリスクが大きい- ×

アプリケーションの実行という性質上やり直す手段がないため，実行に関して一定のリスクがある．

例示プログラミングを使わない方が楽-○

アプリケーションをリストから実行するだけなので，普段の操作と変わらず，例示プログラミングの利用は面倒ではない．

推論がユーザの邪魔になる-○

システム側は汎化候補を提供するだけで，実際に選択するのはユーザであり，推論がユーザの邪魔にならない．

大量のデータを必要とする-△

最も単純な汎化に必要なデータは1つだけである．適切な汎化候補提示に必要な事象数は数個程度である．完璧に近い候補提示には大量のデータが必要となる．

ヒューリスティクスが多用されている-○

既に起きている事象のメンバーシップ関数と面積の割合から候補を算出する単純なルールに基づいている．

関連研究

携帯端末上でのテキストベースのプログラミング環境としては，Palm用のHotPaw Basic[12]，Quatrus Forth[14]，OrbWorks' Pocket C[13]，Teal Info[15]，などが挙げられる．また，Linuxが採用されているPDAでは，シェルスクリプトなどによりデスクトップと同等のプログラミング環境が実現されている．しかし，テキスト形式のプログラミングを携帯端末上で行うのは，入出力インタフェースの問題などにより困難である.

携帯端末の特性に合わせたプログラミング環境の先行研究としては，PDAGraph[1]が挙げられる. PDAGraphは，Prograph[2]というビジュアルプログラミング言語をVisor向けに改変したものである．PDAGraphはトリガベースの言語である．PDAGraphの問題点として，特定の端末への特化と，扱えるコンテクストが接続しているGPSによる位置情報しかないという点が挙げられる．PDAGraphでは曖昧なコンテクストを扱うことができない．

例示プログラミングの研究は数多く行われているが，汎化の方式によって分類できる．操作履歴や例示データをユーザが手動で汎化を行う方式の代表例はTopaz[8]である．Topazは，記録されたスクリプト中のオブジェクトへの参照を，ユーザにポップアップを提示することで汎化する．ほとんど推論する要素がないため，システムは間違えず，ユーザが完全に制御することができる．単純な推論により汎化を行う方式の代表例はPeridot[9]である．Peridotは，GUIウィジットを例示によって作ることができる．15のルールを用いることで，例から図形のレイアウトを推論する．ユーザに推論の確認を求める．複雑な推論により汎化を行う方式の代表例はGamut[7]である．数多く推論を行うことで，ユーザの意図を汲み取り，適応的な動作をさせることが可能となる．

本研究は，例示プログラミングとしてはTopazのようにユーザが明示的に汎化する方式を採用した．それは，たとえ事例の数が一個でも，手軽にプログラミングを行えることを目標としたためである．また，ユーザが汎化する際の負担を軽くするため，汎化候補はあらかじめ用意しておき，優先度順に提示する手法をとっている．

コンテクスト情報の表現にファジィ理論を用いる研究としては，文献[3]がある．これは，データソースから算出されるコンテクストの不確かさを考慮するためにファジィ理論を用いるもので，本研究におけるファジィ集合の利用とは異なるものである．

増井氏の実世界指向プログラミング[5]においても，本研究が提案するようなプログラミング環境の必要性が指摘されている．

まとめと今後の課題

本研究では，携帯端末上における曖昧なコンテクストに基づく例示プログラミング手法の提案・設計・実装を行った．提案するシステムにより，ユーザのアプリケーション実行履歴から，実行時のコンテクストを例示プログラミングにより汎化することで，コンテクストを条件としたプログラムを作成を可能とした．

最後に，今後の課題について述べる．まずルール実行について，実行前後の最適な猶予期間などを求めるべきである．また，設計方針において挙げた四要素の内，ビジュアルプログラミングの部分にも取り組む必要がある．

SRについては，本研究ではあらかじめSRが定義されていることを前提としているが，実社会で適用するためにはセンサの情報や他のユーザの履歴を利用することにより動的に生成する方法が必要であると考えられる．そのためには，複数のユーザの事例を集めて統計的にSRを定義するとともに，それを各ユーザの事情に合わせて変換する手法が必要となるであろう．

例示プログラミングについては，汎化のアルゴリズムやコンテクストの推論のための技術を研究する必要がある．コンテクストの曖昧さを表現するため，ファジィ集合とは別のアプローチとしてベイズ理論などを用いることも検討する．

研究成果

本研究の成果は以下の通りである．

• 加藤文彦，遠山緑生，服部隆志，萩野達也:携帯端末上での曖昧なコンテクストに基づく例示プログラミング, SPA2004, 2004
• 加藤文彦:携帯端末上での曖昧なコンテクストに基づく例示プログラミング,修士論文, 2004

参考文献