機械学習を用いたコンテキストアウェアなサービス提供アーキテクチャの提案
2008MI214 沢田 天馬 2008MI233 鈴木 健太
指導教員 青山 幹雄

1. はじめに
近年，情報技術の発展により，ユビキタスコンピューティング環境が整いつつある．その結果，ユーザは容易に多くの情報を得られるようになった反面，膨大な情報から自身の必要とする情報を取得することが困難となっていることが問題として挙げられる．
この問題の解決には，ユーザの状況に応じた情報を提供することが必要になる．そのため，コンテキストアウェアなサービス提供アーキテクチャを提案する．

2. 研究課題
カーナビゲーションシステム(以下カーナビと略記)のルート提供サービスに着目する．カーナビの経路選択アルゴ
リズムは，グラフの最短経路選択手法を基に，距離や時間の最小化を図るものである[1]．コンテキストアウェアなサービス提供をするためには，以下の課題がある．
(1) 静的コンテキスト: ユーザ毎に「性格」，「趣味」，「運転熟練度」などが異なるため，要求するルートは異なる．
(2) 動的コンテキスト: 時間経過や位置の変化などの環境変化に伴い，ユーザの要求するルートは変化す
る．

3. 関連研究3.1. 多目的遺伝的アルゴリズムを用いた経路探索[3]
カーナビの経路探索は「時間」，「距離」，「快適性」を目的関数とした多目的最適化問題と考えられる．一度の探索で多目的最適化を行うことができない従来の手法に対し，多目的遺伝的アルゴリズムの導入により，同時に複数の目的関数を最適化した経路探索手法を提案している．
3.2. コンテキストアウェアサービスの意義[6]コンテキストアウェアサービスの意義は大きく分けて次の 3 つが挙げられる．
(1) 記憶のサポート: ユーザへの通知を行う．
(2) 判断のサポート: 最適な方法をユーザへ示す．
(3) 行動のサポート: ユーザへの情報提供を行う．
3.3. 機械学習[4]機械学習の目的は知識の構築である．そのため，与えられたデータから規則性を発見する．発見された規則性を用いて，与えられたデータには含まれない状況に対しても，有効な対応を行う知識を構築する．与えられた条件を基に一般化することや，具体的な事例から法則を見出すことを汎化と呼ぶ．
機械学習の実現技術として PredictionAPI が提供されている[2]．これは，Google の機械学習アルゴリズムを利用して，履歴データから規則性の発見を行い，機械学習の知識に相当する予測モデルを構築する．
予測モデルを用いて，新しいデータに対しても予測して出力を行うことが可能である．本研究では，PredictionAPI を用いる．
3.4. ベクトル空間モデル[5]ベクトル空間モデルは出現単語に基づいて文書あるいは文章を 1 つのベクトルで表現し，大量の情報の中からユーザ要求を満たす情報を見つけ出すことを可能とする．
検索対象となる情報を文書集合，ユーザからの情報要求を検索質問とし，多次元ベクトルを用いて情報の類似性を評価する．

4. アプローチ
4.1. 着眼点
ルート提供を必要とするユーザに対して，コンテキストが類似する別のユーザの走行履歴を提供する．機械学習
アルゴリズムを用いて，ユーザの走行履歴とコンテキストを学習し，知識を構築する．構築した知識を利用し，コンテキストアウェアなルート提供を行う．
4.2. 適用技術(1) コンテキストの適用ユーザに関する情報を表現するために，コンテキストを適用する．コンテキストの組み合わせから規則性を見出すことで，ユーザ要求の獲得につながる．
(2) 機械学習アルゴリズムの適用履歴データには存在しないコンテキストにも対応する必要があるため，コンテキストから得られる規則性の知識を用いて汎化を行い，異なるコンテキストに対応する．
また，学習機能により，多く利用されるコンテキストは利用価値が高いコンテキストとして扱われ，ユーザ要求の獲得に重要となる．

Google Storage

5. 提案アーキテクチャ

トレーニングデータ

走行履歴5.1. コンテキスト収集
コンテキストアウェアなサービスを実現するためには，ユーザに関するコンテキストを収集し，それらを過去のユーザから得たコンテキストと関連付けることにより，ユーザの状況に対応する必要がある．そのため，「ユーザの状況を表すことができるあらゆる情報」をコンテキストと定義し，分類を以下に述べる(図 1)．
(1) ユーザ属性：ユーザ自身の情報を表す
a) 感情的要素（ユーザ要求に直接関係する要素）b) ユーザ要素（ユーザの感情以外の要素）(2) 環境属性：ユーザの周囲の情報を表す
a) 自然的要素（天気，四季，場所などの要素）b) 物理的要素（基本的に数値で表される要素）
コンテキスト：ユーザの状況を表すことができるあらゆる情報
ユーザ属性：ユーザ自身の情報

環境属性：ユーザの周囲の情報

感情的要素（要求，気持ち等）
ユーザ要素（家族がいる等）

自然的要素（天気，四季等）
物理的要素（時間，距離等）

図 1 コンテキストの包含関係図
コンテキストはセンサなどから推定，取得できるものと仮定し，ユーザのシステムに対する操作によってコンテキストの提供を受ける．
5.2. コンテキストの重み付け
3.4.節での類似度計算では文書の中の出現頻度が高いものを索引語の重み（重要度）とし，それらをベクトル要素としている．本研究では，ユーザ要求に関係するコンテキストほど重要度は高くなる．
5.3. 類似度評価
収集したコンテキスト同士の類似度より，ユーザの状況に対応しているか評価する．以下にプロセスを示す．
(1) ユーザに関するコンテキストを要素としたものをベクト
ル a とする．ベクトル a に対し，類似度が計られるものをベクトル b とする．
(2) ベクトル a，ベクトル b のコサイン尺度を求める．
類似度(3)·(1)閾値を用いて類似度の評価を行う．本研究では 1 から 0 の間で，閾値を 0.8 と設定する．類似度が 0 以上0.8 未満ならば類似していない．0.8 以上 1 以下ならば類似していると評価する．
5.4. コンテキストアウェアサービス提供アーキテクチャ
コンテキストと機械学習アルゴリズムを適用し，コンテキストアウェアなルート提供を実現するためのアーキテクチャを提案する(図 2)．

ストレージアクセスサービス
Predictionサービス

カーナビ

サードパーティサービス

サードパーティアクセス
サービス

コンテキストアウェア
サービスブローカ

図 2 コンテキストアウェアなルート提供アーキテクチャ
以下に，提案するアーキテクチャの詳細を示す．
5.4.1. コンテキストアウェアサービスブローカ
コンテキストアウェアサービスブローカは，各技術との振舞いの整合をとる仲介サービスである．ブローカを構成するサービスの詳細を以下に述べる．
(1) Prediction サービス
機械学習を行うサービスでコンテキストアウェアサービス
ブローカの中心となる．カーナビから取得したコンテキストを用いて PredictionAPI と連携する．
(2) ストレージアクセスサービス
ストレージからカーナビに提供する走行履歴の取得や，トレーニングデータの更新を行う．
(3) サードパーティアクセスサービス
提供する情報に対しての付加情報の取得を行うため，サードパーティサービスとの連携を行う．
5.5. サービス提供プロセス
カーナビに対するルート提供サービスの振舞いを以下に示す(図 3)．
コンテキストアウェアサービスブローカ
カーナビPrediction
ストレージ
サードパーティ Prediction Google
APIStorage
サービス アクセスサービス アクセスサービス

コンテキスト提供
安全な運転がしたい(感情的要素)運転初心者(ユーザ要素)ルートサードパーティ
サービス

コンテキスト送信
走行履歴保存先
リクエスト

走行履歴取得リクエスト

走行履歴

走行履歴

リクエスト

道路情報リクエスト

道路情報

道路情報レスポンス

図 3 サービス提供の振舞い(1) ユーザのカーナビに対する操作から取得したコンテキストを，コンテキストアウェアサービスブローカのPrediction サービスに提供する．
(2) コンテキストアウェアサービスブローカは，(1) で得たコンテキストをリクエストメッセージとし Prediction サービスを利用して，PredictionAPI へ送る．
(3) PredictionAPI は受け取ったコンテキストを利用し，予測モデルからコンテキストが類似する別のユーザの走行履歴保存先を得る．その後，Prediction サービスにレスポンスメッセージとして走行履歴保存先（URL）を送る．

(4) コンテキストアウェアサービスブローカは，ストレージアクセスサービスを用いて，走行履歴保存先データベースにアクセスし，対象の走行履歴を取得する．
(5) コンテキストアウェアサービスブローカは，道路情報をリクエストし，渋滞情報や事故情報のレスポンスを得る．
5.6. 学習プロセス
サービス提供プロセス後，走行履歴と運転時のコンテキストをフィードバックする．コンテキストアウェアサービスブローカはフィードバックを受けた後，学習プロセスを行う．
学習プロセスにより，異なるコンテキストへの対応や予測出力の精度向上を図る．学習プロセスを図 4 に示す．

ロトタイプの振舞いを図 6 に示す．
仮想カーナビとして Android アプリケーションを実装する．
走行履歴を扱う手段としてKML(Keyhole Markup Language)を用いる．また，コンテキストアウェアサービスブローカはプラットフォームとして Google App Engine を用いる．サードパーティサービスにはスタブを用いる．
Google Storage

ストレージアクセスサービス
Android

コンテキストアウェアサービス
ブローカ
カーナビ

Predictionサービス

Google Storage

サードパーティアクセス
サービス

コンテキストアウェアサービスブローカ

図 5 プロトタイプの構成

走行履歴の追加
トレーニングデータの更新

モデル構築リクエスト

機械学習アルゴリズムの適用

モデル確認リクエスト

モデル
確認

構築完了レスポンス

サードパーティサービス

Google App Engine

Prediction
走行履歴 トレーニング
Prediction
ストレージ
予測モデル
API
DB
データDB
サービス アクセスサービス

走行履歴とコンテキストのフィードバック

トレーニングデータ

KML

Predictionサービスブローカ
Android
ルート
サードPrediction
ストレージ
サードパーティ Prediction Google
Prediction
API
Storage パーティサービス アクセスサービス アクセスサービス
アプリケーション
サービス

モデル構築
sendContext

getPrediction(context)

レスポンス

Request

図 4 学習プロセスの振舞い(1) カーナビを介し，ユーザは走行履歴とコンテキストをコンテキストアウェアサービスブローカに対してフィードバックする．
(2) コンテキストアウェアサービスブローカは，ストレージア
クセスサービスを用いて，提供された走行履歴をデータベースに追加する．
(3) コンテキストアウェアサービスブローカは，ストレージアクセスサービスを用いて，提供されたコンテキストと走行履歴を参照し，トレーニングデータを更新する．
(4) トレーニングデータの更新後，コンテキストアウェアサ
ービスブローカは PredictionAPI に対し，モデル構築リクエストを行う．PredictionAPI を介して Google の機械学習アルゴリズムを適用し，トレーニングデータから予測モデルを構築する．予測モデルの構築はサービス提供と並行して実行可能である．
(5) 予測モデルの構築後，コンテキストアウェアサービスブ
ローカはモデル確認リクエストを行うことによって，予測モデルが構築されているか確認する．

6. プロトタイプの実装と適用提案したルート提供アーキテクチャをプロトタイプとして実装する．
6.1. プロトタイプの仕様
プロトタイプの構成を図 5 に示し，5.5 節の図 3 を基にプ

getKml(PredictionURL)

Request

図6

getInfo

プロトタイプの振舞い

6.2. プロトタイプの実装
コンテキストに対して予測出力を行うためのプロトタイプを実装した．クライアント側は Android アプリケーションとして実装する．コンテキストアウェアサービスブローカ側は，Prediction サービスを実装する．
6.2.1. Android アプリケーション
仮想カーナビとなるルート Prediction アプリケーションを開発した．ユーザがコンテキストを選択して REST を用いてコンテキスアウェアサービスブローカに送信する．
送信した後，GoogleMaps 上にルートを表示する．
6.2.2. Prediction サービス
Google App Engine を用いて，Web サービスとして実装した．ルート Prediction アプリケーションから JSON を受け取る．PredictionAPI を用いて，コンテキストに対応するルートを取得する．ルート Prediction アプリケーションにルートを返す．以下に開発したプログラムの実装結果を示す(表 1)．
表1

プロトタイプの実装結果

対象

実装言語

LOC

Prediction サービス

Java96

ルート Prediction アプリケーション

Java1026.3. シナリオへの適用(1) 静的コンテキスト: 学生であるユーザAと家族連れであるユーザ B を想定する．各ユーザから収集され，重み付けされたコンテキストと，トレーニングデータ内のユーザ A’と B’のコンテキストの重み付けを表 2 に示す．
静的コンテキストに応じ，選択したルートを図 7 に示す．
類似度評価を行い，ユーザ A と A’の類似度は 1，ユー
ザ B と B’の類似度は 0.87 という結果を得た．
表2
コンテキスト

食事/学生/友人
食事/家族連れ/安全面/晴れシナリオ 1 の重み付け

ユーザ

食事

学生

友人

家族連れ

安全性

晴れ

A

1

1

1‐

‐‐

A’

1

1

1‐‐‐

B

1‐‐

1

10

B’

1‐‐

1

1

1

ユーザB

ユーザA

7. 評価と考察
類似度に基づき，コンテキストアウェアなサービス提供の良さを評価する．
(1) 静的コンテキスト
ユーザの様々なコンテキストの尺度に対応し，高い類似度(1，0.87)となるルートが提供できた．よって，静的コンテキストに応じたルート提供を解決できた．
(2) 動的コンテキスト
安全性のみや時間のみなど，静的な単一の尺度に対して，高い類似度(0.99，0.95)となるルートの提供ができたが，安全性と時間という 2 つの尺度を同時に考慮する場合では，類似度は低くなった(0.82)．しかし，矛盾が生じ動的に変化する 2 つの尺度においても，0.8 以上の高い類似度のルートが提供できた． よって，動的コンテキストに応じたルート提供を解決できた．

8. 今後の課題(1)(2)
図 7 静的コンテキストに応じたルート選択(2) 動的コンテキスト: 安全性と時間との要求変化を持つユーザ A を想定し，コンテキスト変化に対応する重み付
けを表 3 に示す．要求に基づき選択された 3 通りのルートを図 8 に示す．類似度評価を行い，ユーザ A に対するユーザ A’のそれぞれの類似度は順に 0.99，0.95，0.82 という結果を得た．
表3

シナリオ 2 の重み付け

コンテキスト
安全性重視

時間重視
安全性重視から時間重視への要求変化

安全重視

ユーザ安全性

学生時間A

2

1‐

A’

3

1‐

A‐

12A’‐

11A

111A’

110

時間重視

安全と時間の考慮

図 8 動的コンテキストに応じたルート選択

提案アーキテクチャの今後の課題を以下に示す．
提案アーキテクチャのプロトタイプの拡張
提案アーキテクチャの汎用性の確認

9. まとめコンテキストアウェアなサービス提供を実現するため，カーナビの現状の問題からルート提供サービスに着目した．
機械学習アルゴリズムとコンテキストを適用し，コンテキストアウェアサービス提供アーキテクチャを提案した．
実際にプロトタイプを作成し，シナリオを基に研究課題に対する評価を示した．

参考文献[1] デンソーカーエレクトロニクス研究会，図解カーエレクト
ロニクス[上]システム編，日経 BP 社，2010．
[2] Google PredictionAPI，
http://code．google.com/intl/ja/apis/predict/．
[3] 原 健太 他，多目的遺伝的アルゴリズムによるカーナビゲーションのための経路探索，情報処理学会 数理モデル化と問題解決研究報告，2004，pp. 49-52．
[4] 小高 知宏，はじめての機械学習，オーム社，2011．
[5] 牧 慶子，山崎 綾，動的コンテキストアウェアサービ
ス提供モデルの提案, 2010 年度南山大学数理情報学部情報通信学科卒業論文，2011[6] 上岡 英史，コンテクストアウェアネスを用いたアプリケーションの研究動向，情報処理，Mar. 2003，pp. 265-269