JP2017059099A - 行動制御システム及び行動制御方法 - Google Patents

Abstract

【課題】多数のユーザの行動の全体状況を最適化するための技術を提供する。
【解決手段】行動制御システムは、一部のユーザの端末装置に行動変更を促すコンテンツを送信するコンテンツ提供手段と、前記コンテンツの提供を受けたユーザが前記コンテンツに従って実際に行動を変更したか否かを確認する確認手段と、前記確認手段による確認結果とデータベースに記憶されているユーザの特性及び／又は状態に基づいて、前記コンテンツを受け入れやすいユーザの特性及び／又は状態を判定して判定結果を前記データベースに記録するコンテンツ効果判定手段と、を有し、前記コンテンツ提供手段は、次に前記コンテンツを提供するときに、前記データベースに記録された前記判定結果に基づいて、前記コンテンツの提供先として選択すべきユーザを決定する。
【選択図】図１

Description

本発明は、多数のユーザの行動の全体状況を最適化するために、個別ユーザの行動制御をする技術に関する。

多数のユーザの行動（例：要求する行動、消費する行動、移動する行動、生産する行動、使用する行動など）が、時空間の一部に過度に集中することで、それらの行動に必要な資源（時間、空間、物質、エネルギーなど）の不足が生じたり、ユーザ間の衝突が発生したり、ユーザの行動が不正確になることがある。また、多数のユーザの行動（例：要求する行動、消費する行動、移動する行動、生産する行動、使用する行動など）が、同じ対象（例：道路、建物、通信チャネル、コンピュータ、水資源、エネルギー資源）に過度に集中することで、それらの行動に必要な資源の不足が生じたり、ユーザ間の衝突が発生したり、ユーザの行動が不正確になり、事故，故障，不具合などの問題を起こすことがある。交通渋滞、店舗等の混雑、電力の需要過多、アクセス集中によるサーバーダウンなどは、デマンドの集中が原因で発生する不具合であり、多数のユーザの行動によっておこる全体状況の不具合のパターンの１つであると言える。

交通渋滞を緩和するための手法として、例えば特許文献１には、走行中の車両に対してサービスエリア等で使えるクーポンを配信し、当該車両を道路外の施設に導くことで、渋滞を緩和させる方法が提案されている。しかしながら、一律にクーポンを配信する方法では、あまり高い効率は期待できない。また、クーポンを受け取った車両の何割が施設に向かうのか予測できないため、道路の渋滞緩和と施設の混雑防止を両立するような制御は困難である。通信を希望するユーザに対する通信チャネルの割り当てを工夫して、通信の混雑を緩和するための手法として、例えば特許文献２に記載の手法がある。

特開２０１４−２２５０９８号公報 特開２０１５−１０４１１４号公報

本発明は上記実情に鑑みなされたものであり、多数のユーザの行動の全体状況を最適化するための技術を提供することを目的とする。

請求項１に記載された発明は、多数のユーザの行動の全体状況を所定の基準による全体最適の状態に近づけるために、前記多数のユーザの中の選択された一部又は全部のユーザの行動を変更させる行動制御システムであって、各ユーザの特性及び／又は状態を表す情報を更新しつつ記憶するデータベースと、前記データベースに記憶されている情報に基づいて、前記全体状況を前記全体最適の状態に近づけるために前記選択されたユーザが行うべき行動を決定する行動決定手段と、前記データベースに情報が記憶されているユーザの中から選択した一部のユーザの端末装置に、前記行動決定手段が決定した行動への変更を促すコンテンツを送信するコンテンツ提供手段と、前記コンテンツの提供を受けたユーザが前記コンテンツに従って実際に行動を変更したか否かを確認する確認手段と、前記確認手段による確認結果と前記データベースに記憶されているユーザの特性及び／又は状態に基づいて、前記コンテンツを受け入れやすいユーザの特性及び／又は状態を判定して判定
結果を前記データベースに記録するコンテンツ効果判定手段と、を有し、前記コンテンツ提供手段は、次に前記コンテンツを提供するときに、前記データベースに記録された前記判定結果に基づいて、前記コンテンツの提供先として選択すべきユーザを決定することを特徴とする行動制御システムである。

請求項１に記載された発明によれば、コンテンツの提供を行う度に、コンテンツがどのような特性及び／又は状態のユーザに受け入れられやすいかという判定結果がデータベースに蓄積（学習）され、その学習した判定結果に基づいてコンテンツを提供すべきユーザが選択される。このようにして選択されたユーザは、他の人たちに比べ、提供されたコンテンツを受け入れ実際に行動を変更する可能性が高い。したがって、ユーザに提供するコンテンツが、ユーザの行動変更をもたらしやすいコンテンツになっていくため、多数のユーザの行動の全体状況を効率的に最適化することができる。

請求項２に記載された発明は、前記全体状況が道路ネットワークに対する車両の分布の状況であり、前記全体最適の状態が非渋滞の状態であることを特徴とする請求項１に記載の行動制御システムである。請求項２に記載された発明によれば、交通渋滞を緩和ないし防止することが可能となる。

請求項３に記載された発明は、前記コンテンツ効果判定手段は、前記コンテンツを提供した回数に対する前記コンテンツに従って実際に行動を変更した回数の割合である行動変更率をユーザ毎に計算し、ユーザ毎の行動変更率を前記判定結果として前記データベースに記録することを特徴とする請求項１又は２に記載の行動制御システムである。請求項３に記載された発明によれば、ユーザの特性及び／又は状態と行動変更する確率の相関をデータとして蓄積することができる。このようなデータは、コンテンツを提供するユーザの選択、コンテンツを提供するユーザ数の決定、受け入れの予測などに有用である。

請求項４に記載された発明は、前記コンテンツ提供手段は、前記コンテンツを提供するときに、前記コンテンツに対する行動変更率の高いユーザを、前記コンテンツの提供先として選択することを特徴とする請求項３に記載の行動制御システムである。請求項４に記載された発明によれば、提供されたコンテンツを受け入れ実際に行動を変更する可能性が高いユーザを簡単に抽出することができる。

請求項５に記載された発明は、前記コンテンツ効果判定手段は、前記複数のユーザを特性及び／又は状態に基づき複数のクラスタに分け、前記コンテンツを提供したユーザの総数に対する前記コンテンツに従って実際に行動を変更したユーザの割合である行動変更率をクラスタ毎に計算し、クラスタ毎の行動変更率を前記効果判定の結果として前記データベースに記録することを特徴とする請求項１又は２に記載の行動制御システムである。請求項５に記載された発明によれば、ユーザの特性及び／又は状態と行動変更する確率の相関をデータとして蓄積することができる。このようなデータは、コンテンツを提供するユーザの選択、コンテンツを提供するユーザ数の決定、受け入れの予測などに有用である。

請求項６に記載された発明は、前記コンテンツ提供手段は、前記コンテンツを提供するときに、前記コンテンツに対する行動変更率の高いクラスタに属するユーザを、前記コンテンツの提供先として選択することを特徴とする請求項５に記載の行動制御システムである。請求項６に記載された発明によれば、提供されたコンテンツを受け入れ実際に行動を変更する可能性が高いユーザを簡単に抽出することができる。

請求項７に記載された発明は、前記コンテンツを受け入れ可能なユーザの数に上限がある場合に、前記コンテンツ提供手段は、前記コンテンツの提供先として選択されたクラスタに属するユーザの数に、当該クラスタの行動変更率を乗じることにより、前記コンテン
ツを提供した場合の受入予測人数を計算し、前記受入予測人数が前記上限を超えている場合には、前記コンテンツを提供するユーザの数を減らすことを特徴とする請求項６に記載の行動制御システムである。請求項７に記載された発明によれば、必要十分な数のユーザにだけコンテンツを提供するので、コンテンツ提供にかかる処理負荷を軽減できるとともに、少ない受入上限に対し多くのユーザの受入希望が殺到しシステム負荷が増大する事態を避けることもできる。

請求項８に記載された発明は、前記コンテンツ提供手段は、内容の異なる複数のコンテンツを提供可能であり、前記コンテンツ効果判定手段は、前記複数のコンテンツのそれぞれについて、各コンテンツがどのような特性及び／又は状態のユーザに受け入れられやすいかという効果判定を行い、前記複数のコンテンツそれぞれの効果判定の結果を前記データベースに記録することを特徴とする請求項１〜７のいずれかに記載の行動制御システムである。請求項８に記載された発明によれば、コンテンツ毎に適切なユーザに配信することができる。

請求項９に記載された発明は、前記複数のコンテンツは、行動を変更したユーザに対しインセンティブを授与するコンテンツと、行動を変更したユーザに対しインセンティブを授与しないコンテンツを含み、前記コンテンツ提供手段は、行動を変更したユーザに対しインセンティブを授与するコンテンツよりも、行動を変更したユーザに対しインセンティブを授与しないコンテンツの方を優先的に提供することを特徴とする請求項８に記載の行動制御システムである。インセンティブを授与しないコンテンツの提供を優先することにより、インセンティブ授与に伴う運用コストの負担を軽減することができる。

なお、本発明は、上記構成ないし機能の少なくとも一部を有する行動制御システムとして捉えることができる。また、本発明は、上記処理の少なくとも一部を含む行動制御方法、又は、かかる方法をコンピュータに実行させるためのプログラム、又は、そのようなプログラムを非一時的に記録したコンピュータ読取可能な記録媒体として捉えることもできる。上記構成及び処理の各々は技術的な矛盾が生じない限り互いに組み合わせて本発明を構成することができる。

本発明によれば、ユーザに提供するコンテンツがユーザの特性に応じた行動変更をもたらしやすいコンテンツになっていくため、多数のユーザの行動の全体状況を効率的に最適化することができる。

実施例１に係る行動制御システムの概要を示す図。 実施例１に係る行動制御システムの全体構成を示すブロック図。 ユーザ特性管理ＤＢのデータ構造の一例を示す図。 ユーザ状態管理ＤＢのデータ構造の一例を示す図。 ユーザ行動パターン管理ＤＢのデータ構造の一例を示す図。 コンテンツ効果管理ＤＢのデータ構造の一例を示す図。 コンテンツ効果管理ＤＢのデータ構造の一例を示す図。 地域内交通経路ＤＢに記録された情報を模式的に示す図。 端末装置のメイン処理のフローチャート。 行動制御システムのメイン処理のフローチャート。 端末装置の画面に表示されたコンテンツの例。 平準化モデル生成処理の詳細フローチャート。 コンテンツ提供処理の詳細フローチャート。 図１３のステップＳ４０５の詳細フローチャート。 コンテンツ提供の流れを示すフロー図。 実施例２に係る行動制御システムの概要を示す図。

本発明は、多数のユーザの行動の全体状況を所定の基準による全体最適の状態に近づけるために、多数のユーザの中の選択された一部又は全部のユーザの行動を変更させる、行動制御システム及び行動制御方法に関する。本発明は、例えば、交通渋滞、店舗等の混雑、電力の需要過多、サーバーへのアクセス集中など、多数のユーザの行動によっておこる全体状況の不具合の解消に適用することができる。

＜実施例１＞
実施例１は、本発明に係る行動制御システムを交通流の制御（交通デマンド制御）に適用した例である。

実施例１に係る行動制御システムは、渋滞が発生した時又は渋滞発生が予測された時に、地域内にいるドライバーに行動変更を促すコンテンツを提供し、行動を変更（移動開始時刻の変更、交通手段の変更、移動経路の変更など）してもらうことで、地域内の交通流を分散する。つまり、実施例１の行動制御システムは、地域内の道路ネットワークに対する車両の分布の状況（全体状況）を、非渋滞の状態（全体最適の状態）に近づけることを目的とする。これにより、地域内にある道路の渋滞緩和や渋滞防止を図ることができ、それに伴うＣＯ_２排出量削減や事故削減などの効果を得ることができる。

（システムの概要）
図１は、実施例１に係る行動制御システム（以下、単に「システム」とも呼ぶ）の概要を示している。行動制御システムは、インターネット上のサーバ装置により構成されており、各ユーザがもつ端末装置や、他の装置（交通情報などを提供するサーバ、データベース、センサなど）とインターネットを通じて通信可能である。

各ユーザは、各自の端末装置を使って事前にユーザ登録を行い、個人特性（性別、年齢、家族構成、住所、勤務地、勤務形態（始業・就業時刻）、車両保有状況、運転レベル（運転歴）など）をシステムに設定する。また、各ユーザは、定期的もしくは運転開始時などに、個人の今の状態（現在の所在地、移動状況、目的地、移動状況（車にのっているなど）、移動予定経路など）と、個人の過去の状態（移動履歴（移動軌跡、行動パターン）など）のデータをシステムに通知する。

システムは、各ユーザの特性および状態のデータと、他の装置から取得できる交通状況関連情報（例えば、カレンダー情報、近隣のイベント情報、道路に設置されたセンサの情報、気象情報、渋滞予測情報など）に基づいて、当該地域内の現時点および近い将来の交通状況を推定する。渋滞が発生している場合、又は、渋滞発生が予測できた場合、システムは、地域内の車を時間的・空間的に分散させるため、ユーザに対し行動変更をレコメンドするコンテンツを提供する。端末装置で受信したコンテンツを見たユーザが、そのコンテンツのレコメンドを受け入れ、行動を変更（迂回路の選択、行き先や出発時刻の変更、他の交通機関や徒歩の利用など）すると、渋滞の緩和や防止を実現できる。

一方で、システムは、各ユーザがコンテンツを受け入れたかどうかや、実際に行動を変更したかどうかを確認する。そして、システムは、各ユーザがどんな特性・状態のときにどんなコンテンツを受け入れたのかを学習し、データベースに蓄積する。この情報は、次回以降のコンテンツ提供の際に、コンテンツの提供先となるユーザの選択、コンテンツの内容の選択などに活用される。

本システムでは、例えば、渋滞している道路に今いる車や将来いるであろう車のドライバーに対し、迂回をレコメンドするコンテンツを提供する。ただし、全ての車を迂回路に誘導してしまうと迂回路が渋滞する可能性がある。そのため、迂回路への分散だけでは渋滞が解消できない場合は時間差移動や他の交通機関利用を促し、地域全体で渋滞を解消する。つまり、地域内の車を空間的・時間的に分散させることで、交通渋滞の緩和や防止を行う。このとき、その地域の特性を考慮するとよい。例えば、鉄道やバスなどの公共交通機関のある地域であれば、迂回路の案内や公共交通機関の案内などの空間的な分散を優先するとよい。一方、道路が少ない、公共交通機関がないといった地域の場合は、車の時間的な分散を優先するとよい。

地域内の全員に一律に同じコンテンツを提供しても、有効な結果が得られない可能性が高い。また、もし全員がコンテンツの案内に従い迂回路に移動すると、普段空いている道に車が集中し、そこに交通渋滞が発生してしまう可能性もある。したがって、データマイニングを利用して、どのような人たちに、どのようなコンテンツを提供すれば、どの程度の割合の人が行動変更してくるかを予測した上で、適切な人に、適切な内容のものを、必要最小限の人に絞って提供するとよい。コンテンツ提供先や提供内容を選択する際には、個人特性、運転のレベル、個人の状態、個人の行動変容ステージ、行動を変更することに伴うストレスレベルなどを考慮するとよい。そうすることで、コンテンツ提供されたり行動を変更することでストレスを感じる人に対しては、コンテンツを提供しない、もしくはストレスを感じづらいコンテンツに限定して提供する、といった制御が可能になる。また、コンテンツ提供の際、ユーザの運転レベルも考慮する（例えば、迂回路の情報は運転に慣れた人にのみ提供し、運転歴が短い人には提供しないなど）とよい。運転レベルが低いユーザに細い道や初めての道を案内すると、事故など不測の事態を誘発するおそれがあるからである。

提供するコンテンツの受入率をあげていくため、その人の知識レベルを向上させるための情報提供（例えば、迂回路、すいている時間帯などを教える）を実施する。また、コンテンツ受入率の高いユーザには褒めたりお礼をいったりするなど、コンテンツの伝え方を工夫し、地域全体で渋滞緩和や渋滞防止ができていくようにする。また、コンテンツを受け取った人が行動を変更したか、それはコンテンツ提供の効果によるものか、また地域内の交通状況は改善されたかを評価・学習し、以後のコンテンツ提供先・コンテンツ内容の選択に反映するとよい。知識レベルを向上させるための情報提供を実施すると、例えば、今まで迂回路の存在を知らなかった人が、迂回路があると認識すると、コンテンツ配信がなくても、自ら迂回路を走行するようになり、徐々に、本システムを動かさなくても渋滞しづらい地域になっていくと期待できる。また、システムを動かす頻度や、コンテンツ提供人数が減るとともに、インセンティブ授与の数も減っていき、運用コストは少しづつ下がると期待できる。

行動を変更した人に対しインセンティブを授与してもよい。インセンティブは、ユーザが喜ぶであろう情報、モノ、金銭、権利などである。例えば、「情報」の例として、詳細な道路交通情報、シークレットセールの情報など、「モノ」の例として、電車移動時の快適グッズなど、「金銭」の例として、キャッシュ、有料道路や駐車場や店舗での割引券、無料券、クーポン券、パーキングメータ延長券、ポイント、デジタルマネーなど、「権利」の例として、優先レーン利用、車両入場規制のある地域や道路の利用、商品の先行購買権などが例示できる。蓄積ポイント数に応じて上記の情報、モノ、金銭、権利に交換可能にしてもよい。これによりコンテンツ受入率を向上し、渋滞緩和や渋滞防止の効果を高めることができる。ただし、インセンティブの授与は、道路管理者やシステム運営者の運用コストを増大させるため、提供コンテンツに優先順位を設け、コストがかからないものから優先してコンテンツ提供していくとよい。なお、ユーザの特性や状態に応じて授与するインセンティブの種類や内容を変更してもよい。また、コンテンツをよく受け入れてくれ
る人（受入ｘ回以上、受入率ｘ％）や、あまり人気のないコンテンツを受け入れてくれる人（電車に乗ったり、時間差で移動してくれる）などは、別途ポイントがたまったり、ポイントの累積率が上がったり、また次回以降の適切なタイミングでインセンティブ付きコンテンツが配信される確率が高くなるような仕組みを採用することも好ましい。

（システム構成）
図２は、実施例１の行動制御システムの全体構成を示すブロック図である。行動制御システム１００は、ユーザの端末装置２００や他の装置３００とインターネットを通じて通信可能である。図２では、端末装置２００と他の装置３００が１台ずつしか示されていないが、実際のシステムでは、地域内の登録ユーザ（例えば数百人から数万人）全員の端末装置２００が存在し、また、他の装置３００も複数存在し得る。

行動制御システム１００は、ＣＰＵ、メモリ、大容量の記憶装置、通信装置などを備えた汎用のコンピュータシステムにより構成可能である。複数台のサーバ装置により冗長かつ堅牢な構成としたり、分散処理を実現したりすることが望ましい。後述する行動制御システム１００の処理及び機能は、記憶装置に格納されたプログラムがＣＰＵによって実行されることでソフトウェア的に実現されるものである。また、端末装置２００は、ＣＰＵ、メモリ、大容量の記憶装置、通信装置、入力装置、表示装置などを備える汎用のコンピュータシステムにより構成可能である。具体的には、スマートフォン、タブレットＰＣ、モバイルＰＣ、カーナビゲーション装置、ウェアラブル端末などが想定される。行動制御システム１００を利用する際には、専用のアプリケーションプログラム（以下、単に「アプリ」とも呼ぶ）を端末装置２００にインストールすることで、個人の特性や状態の通知、センサデータの送信、コンテンツの受信・閲覧などが可能となる。

行動制御システム１００は、主な機能として、サーバ通信部１１０、ユーザ行動管理部１２０、ユーザ情報記憶部１３０、交通管理・デマンド制御部１４０、交通状況記憶部１５０を有している。サーバ通信部１１０は、端末装置２００および他の装置３００とデータ通信を行う機能である。ユーザ行動管理部１２０は、ユーザから入力された個人特性や現在の状態をユーザ情報記憶部１３０に登録するユーザ情報登録部１２１と、ユーザの行動パターンやコンテンツ受入状況などを分析しその分析結果をユーザ情報記憶部１３０に記録するユーザ分析部１２２とを有する。交通管理・デマンド制御部１４０は、交通状況把握・予測／渋滞判定部１４１と、平準化モデル生成部１４２、コンテンツ選択／提供部１４３、コンテンツ効果判定部１４４を有する。これらの機能の詳細については後述する。

ユーザ情報記憶部１３０は、ユーザ特性管理ＤＢ１３１、ユーザ状態管理ＤＢ１３２、ユーザ行動パターン管理ＤＢ１３３、ユーザセンサデータ管理ＤＢ１３４、コンテンツ効果管理ＤＢ１３５を有する。また、交通状況記憶部１５０は、交通状況履歴ＤＢ１５１、交通状況予測ＤＢ１５２、地域内交通経路ＤＢ１５３を有する。

ユーザ特性管理ＤＢ１３１は、ユーザ登録時に入力された初期設定値（個人特性）がユーザごとに記録されるデータベースである。初期設定値（個人特性）とは、名前、性別、生年月日、住所、通勤状況、勤務地、始業・就業時刻など、移動ごとに変わらない情報である。図３にユーザ特性管理ＤＢ１３１のデータ構造の一例を示す。この例では、ユーザＩＤに関連付けて、性別、生年月日、住所、車の保有状況、勤務地の緯度経度などが記録されている。もちろん、初期設定値の内容に変更がある場合には、いつでもユーザが端末装置２００のアプリ上で変更することが可能である。

ユーザ状態管理ＤＢ１３２は、ユーザの現在及び過去の状態が記録されるデータベースである。図４Ａにユーザ状態管理ＤＢ１３２のデータ構造の一例を示す。この例では、ユ
ーザＩＤに関連付けて、現在移動中であるかどうか、移動手段（車／鉄道／バス／自転車／徒歩など）、移動先の緯度経度、現在値の緯度経度、同伴者の有無や人数、障害情報（車以外の移動手段の利用の可否）、運搬物の有無などが記録されている。また、このユーザに対してコンテンツを提供した場合には、どのようなコンテンツを提供したか、そのコンテンツが受け入れられたか否か、といった情報もリアルタイムに記録される。

ユーザ行動パターン管理ＤＢ１３３は、ユーザが、過去、どのような特性や状態のときに、どのような種類のコンテンツを受け入れたか（又は受け入れなかったか）、といった情報が記録されるデータベースである。図５にユーザ行動パターン管理ＤＢ１３３のデータ構造の一例を示す。この例では、ユーザＩＤに関連付けて、コンテンツの提供日時、コンテンツを受け入れ（又は拒否）したときのユーザの個人状態（同伴者の有無、移動先の緯度経度、運搬物の有無、障害情報）、コンテンツを受け入れた場所の緯度経度、提供したコンテンツの種類、ユーザが実際に行動を変更したかどうか、などの情報が記録されている。

ユーザセンサデータ管理ＤＢ１３４は、ユーザの端末装置２００から受信したセンサデータが記録されるデータベースである。センサデータとしては、例えば、ＧＰＳデータ（移動履歴のデータ）が記録される。

コンテンツ効果管理ＤＢ１３５は、過去に提供したコンテンツの行動変更率が記録されるデータベースである。図６と図７にコンテンツ効果管理ＤＢ１３５のデータ構造の一例を示す。図６は、個人特性や状態に基づき登録ユーザを複数の集団（クラスタ）に分け、クラスタ別、コンテンツの内容別に、行動変更率（受入率とも呼ぶ）を記録したデータベースである。行動変更率とは、コンテンツを提供したユーザの総数に対する、コンテンツに従って実際に行動を変更したユーザの割合である。図７は、各コンテンツの提供優先順位、コンテンツの内容（種類）、受入条件（受入上限数など）を記録したデータベースである。

交通状況履歴ＤＢ１５１は、過去の交通状況（渋滞状況）の履歴を記録するデータベースである。また、交通状況予測ＤＢ１５２は、端末装置２００や他の装置３００から集めたデータをもとに予測した現在から将来の交通状況（渋滞状況）を記録するデータベースである。

地域内交通経路ＤＢ１５３は、道路や線路等の交通情報を含む地図情報や、各道路の（分岐や交差点を区切りとして、各区切り内での）許容車両台数が記録されたデータベースである。道路の新設、工事や事故による通行止めなどにより、地図情報や許容車両台数に変化があれば、地域内交通経路ＤＢ１５３の内容が随時更新される。図８は、地域内交通経路ＤＢ１５３に記録された情報を模式的に示している。道路（本線、迂回路）と線路の地図情報に関連付けて、各道路の区間ＩＤ、道幅、車両許容台数が記録されている。この情報は渋滞予測や、迂回路および代替交通手段の検索に利用される。

（システムの動作）
次に、行動制御システム１００および端末装置２００の処理の流れを説明する。図９は端末装置２００の処理フローチャートであり、図１０は行動制御システム１００の処理フローチャートである。なお、端末装置２００への専用アプリのインストール、および、ユーザ登録や初期設定値（個人特性）の入力はすでに完了しているものとする。

（１）端末装置２００の動作
ユーザが車での移動を開始する際に、端末装置２００の専用アプリを起動し、目的地、出発予定時刻、到着予定時刻、経路、同乗者の有無などの個人状態値を入力する（ステッ
プＳ１００）。すると、端末装置２００が、現在のユーザの状態を把握するため、端末装置２００に搭載されたセンサから、ＧＰＳ情報、加速度情報、時刻情報などのセンサデータを取得し（ステップＳ１０１）、専用アプリで取得したユーザの状態とセンサデータを、行動制御システム１００に送信する（ステップＳ１０２）。行動制御システム１００は、地域内の複数のユーザから収集したデータをもとに交通状況の変化を随時予測し、必要に応じてユーザに対しコンテンツ提供を行う（詳しくは後述）。なお、ユーザが車での移動を開始する際に、ユーザ自身がアプリの起動操作をするのではなく、カレンダーの予定、ＧＰＳでの場所情報、ユーザの普段の行動履歴などに基づき、アプリが自動で起動するようにしてもよい。

端末装置２００の専用アプリは、行動制御システム１００からコンテンツを受信するのを待ち受ける（ステップＳ１０３、Ｓ１０４；Ｎｏ）。移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１０５；Ｎｏ）、端末装置２００は、ユーザの個人状態値とセンサデータを定期的に行動制御システム１００に通知する（ステップＳ１０１、Ｓ１０２）。このような仕組みにより、ユーザの状態がリアルタイムに行動制御システム１００に収集・蓄積されていく。

端末装置２００の専用アプリは、行動制御システム１００からコンテンツを受信すると（ステップＳ１０４；Ｙｅｓ）、そのコンテンツをユーザに提示する（ステップＳ１０６）。図１１は、端末装置２００の画面に表示されたコンテンツの例である。迂回路をレコメンドする情報が表示されるとともに、このコンテンツを受け入れるか否かを選択させるボタンが表示される。ユーザは、コンテンツを受け入れレコメンドに従う場合には、「受入」ボタンを押し、レコメンドに従いたくない場合には、「拒否」ボタンを押す（ステップＳ１０７）。ユーザの選択結果は行動制御システム１００に送られる（ステップＳ１０８）。

ユーザがコンテンツに気づかない場合、あるいは、興味のないコンテンツである場合には、ボタンが押されない可能性もある。所定の時間、ボタンが押されなければ、専用アプリはコンテンツがスルーされたと判断し、コンテンツを非表示にするかボタンを選択不可にする。また、コンテンツ受入上限数が決められているコンテンツの場合には、コンテンツを受け入れたユーザの数が上限数に到達すると、その情報が行動制御システム１００から端末装置２００に通知され、コンテンツが非表示（またはボタンが選択不可）となる。

ユーザがコンテンツを受け入れた場合（ステップＳ１０９；Ｙｅｓ）、ステップＳ１１０へと進む。端末装置２００は、移動が終了（目的地に到着または目的地を変更）するまでの間（ステップＳ１１２）、ＧＰＳや加速度などのセンサデータを定期的に取得し（ステップＳ１１０）、行動制御システム１００へ送信する（ステップＳ１１１）。これにより、コンテンツ受入後のユーザの移動経路や交通手段などを行動制御システム１００が把握することができる。

移動終了後、行動制御システム１００から、ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、ユーザが受け入れたコンテンツの条件を満たしていたかどうかの結果が送信されてくるので、端末装置２００はその結果情報を受信する（ステップＳ１１３）。なお本実施例では、コンテンツの条件を満たしたかどうか（ユーザがコンテンツのレコメンド通りに行動を変更したかどうか）の判断を行動制御システム１００側で行ったが、端末装置２００側で行い、その結果を端末装置２００から行動制御システム１００に通知してもよい。

ユーザがコンテンツの条件を満たす移動を実行していた場合には（ステップＳ１１４；Ｙｅｓ）、専用アプリにユーザの行動変更を賞賛するメッセージなどを表示する（ステッ
プＳ１１５）。また、コンテンツがインセンティブを授与する内容のものであった場合には、ユーザに対してインセンティブを授与する。例えば、店舗で利用できるクーポンを表示したり、ＥＴＣの割引コードを表示したり、ポイントやデジタルマネーを付与したりなど、インセンティブの授与方法はどのようなものでもよい。

（２）行動制御システム１００の動作
行動制御システム１００（ユーザ情報登録部１２１）は、各ユーザの端末装置２００から初期設定値（個人特性値）を受信すると、そのデータをユーザ特性管理ＤＢ１３１に保存する（ステップＳ２００）。ユーザの新規登録時（専用アプリのインストール時）、ユーザの個人特性に変更があった時などに、この処理が実行される。

また、行動制御システム１００（ユーザ情報登録部１２１）は、各ユーザの端末装置２００から個人状態値とセンサデータを受信すると、そのデータをユーザ状態管理ＤＢ１３２およびユーザセンサデータ管理ＤＢ１３４に保存する（ステップＳ２０１）。この処理は、端末装置２００からデータが送られてくるたびに（図９のステップＳ１０２、Ｓ１１１参照）実行される。

行動制御システム１００（交通状況把握・予測／渋滞判定部１４１）は、ユーザから収集した個人状態値およびセンサデータと、他の装置３００から収集した交通状況関連情報に基づいて、現在の交通状況を把握するとともに、近い将来（例えば数十分から数時間後）の交通状況を予測する（ステップＳ２０２）。交通状況関連情報としては、例えば、カレンダー情報（日付、曜日、祝日、季節など）、地域のイベント情報、道路に設置されたセンサの情報（トラフィックカウンタなど）、気象情報、工事情報、渋滞予測情報など、交通状況の把握や予測に利用可能な情報であればどのような情報を用いてもよい。ステップＳ２０２で把握ないし予測された結果は、交通状況履歴ＤＢ１５１および交通状況予測ＤＢ１５２に保存される。

行動制御システム１００（交通状況把握・予測／渋滞判定部１４１）は、ステップＳ２０２の結果をもとに、地域内の道路ですでに渋滞が発生しているか、または渋滞が発生する可能性が高いかを判断する。当分のあいだ渋滞が発生しそうになければ、対策を打たなくてよいので、なにもしない（ステップＳ２０３；Ｎｏ）。渋滞が発生している、またＳは、近い将来渋滞が発生しそうだと判断であれば（ステップＳ２０３；Ｙｅｓ）、ステップＳ２０４に進む。

ステップＳ２０４では、行動制御システム１００（平準化モデル生成部１４２）が、地域内の車をどのように空間的・時間的に分散したり、車の数をどの程度減らしたりすれば、渋滞が緩和または渋滞発生を防止できるか計算する。地域内の人ができるだけ希望どおりの移動手段や経路で移動でき、かつ渋滞が発生しない状態が理想である。

例えば、対象となる地域内に、図８に示すように、一般道の本線と迂回路があり、電車も利用可能である状況を想定する。各道路の許容車両台数（渋滞が発生しない上限の車両台数）は、本線が７０台、迂回路が３０台であるとする。ステップＳ２０２において、１５時に各道路を走行しているであろう車両の台数が、本線：１００台（渋滞）、迂回路：１０台（非渋滞）と予測されたとする。このような場合、地域内の渋滞を緩和ないし防止するため、１５時に本線を走行する車両台数を７０台以下にすることが行動制御システム１００の目的となる。このとき、車両を迂回路に誘導してもよいが、迂回路を渋滞させてはならない。そうすると、上記目的を達成するための平準化モデルは、「本線から迂回路に２０台移動し、残り１０台は通行時間または交通手段を変更する」という対策となる。

図１２は、平準化モデル生成処理（ステップＳ２０４）の詳細フローである。平準化モ
デル生成部１４２は、走行中または走行開始予定の車のなかから、対象時刻（渋滞緩和させたい時刻）に、対象道路（渋滞緩和させたい道路）を走行する予定の車を抽出する（ステップＳ３００）。上記の想定例では、１５時に本線を走行すると予想される車が抽出され、その数が１００台であることがわかる。次に、平準化モデル生成部１４２は、対象道路から、当該時刻に何台の車を減らすべきかを計算する（ステップＳ３０１）。上記の想定例では、本線の許容車両台数が７０台であるため、１５時に本線から３０台の車を減らすべきであると計算される。次に、平準化モデル生成部１４２は、地域内に他の経路や他の移動手段がないか探索する（ステップＳ３０２）。具体的には、地域内交通経路ＤＢ１５３の地図情報および許容台数情報を参照し、代替経路や代替移動手段を選択する。このとき、移動時間や移動距離がより短いもの、有料道路より一般道、道幅がより広い道、という基準で代替経路や代替移動手段を選ぶとよい。次に、平準化モデル生成部１４２は、代替経路や代替移動手段ごとに、受入許容台数を算出する（ステップＳ３０３）。上記の想定例では、迂回路に２０台、電車または時間差移動に１０台、と計算される。

以上のとおり平準化モデルが生成されると、図１０のステップＳ２０５に進み、行動制御システム１００（コンテンツ選択／提供部１４３）が、コンテンツの提供先および提供コンテンツの内容（種類）などを決定し、必要なユーザにコンテンツを送信する。このとき、ユーザ特性管理ＤＢ１３１、ユーザ状態管理ＤＢ１３２、コンテンツ効果管理ＤＢ１３５の情報に基づき、コンテンツ選択／提供部１４３は、地域内のどのユーザに対し、どのような内容のコンテンツを提供するとよいかを判断する。ユーザの特性や状態などを考慮することで、実行が不可能なコンテンツ、ユーザにストレスや安全面での不安を与えるコンテンツなどが提供されないようにする一方で、過去のコンテンツ受入率などを考慮することで、コンテンツを受け入れ、行動を変更してくれる可能性の高いユーザに優先的にコンテンツを提供する。

図１３は、コンテンツ提供処理（ステップＳ２０５）の詳細フローである。コンテンツ選択／提供部１４３は、まず、コンテンツ提供優先順位を０で初期化する（ステップＳ４００）。コンテンツ選択／提供部１４３は、コンテンツ提供優先順位をインクリメントしながら（ステップＳ４０１）、コンテンツ効果管理ＤＢ１３５（図７参照）に登録されているコンテンツを提供優先順位の高いものから順に注目する（ステップＳ４０２）。コンテンツ選択／提供部１４３は、注目したコンテンツが現在の環境下で受け入れ可能なコンテンツか否かを判断し（ステップＳ４０３）、受け入れ可能性のあるコンテンツであれば、その注目したコンテンツを提供コンテンツとして選択する（ステップＳ４０４）。例えば、迂回路のない地域で迂回路利用をレコメンドするコンテンツを提供したり、電車やバスなどがない地域で代替交通手段をレコメンドするコンテンツを提供しても、ユーザは受け入れ不可能なため、ステップＳ４０３では、そのようなコンテンツが提供コンテンツから外される。ステップＳ４０１〜Ｓ４０３の処理が、全体状況を全体最適の状態に近づけるためにユーザが行うべき行動を決定する行動決定手段の処理に該当する。

提供コンテンツが選択されると、コンテンツ選択／提供部１４３は、その提供コンテンツの提供先となるユーザを選択し、そのユーザの端末装置２００にコンテンツを送信する（ステップＳ４０５）。

図１４は、ステップＳ４０５の詳細フローである。コンテンツ選択／提供部１４３は、コンテンツ効果管理１３５（図６参照）を参照して、提供コンテンツに対するコンテンツ受入率（行動変更率）の高いクラスタを抽出する（ステップＳ５００）。クラスタの抽出条件は、例えば、「コンテンツ受入率がｘ％以上のクラスタ全て」、「ｙ人以上になるクラスタ集団」、「コンテンツ受入率上位ｚ個のクラスタ」のように、予め設定されている。次に、コンテンツ選択／提供部１４３は、抽出したクラスタに属するユーザの中から、コンテンツ提供するユーザを抽出する（ステップＳ５０１）。本実施例では、クラスタに
属するユーザの中から、他のコンテンツの受け入れ待ちになっておらず、かつ、この提供コンテンツをまだ受け入れ拒否しておらず、かつ、運転レベル及びストレスレベルに問題のないユーザが抽出される。

ユーザの運転レベルは、過去の移動履歴、事故歴、走行距離、運転年数などから判断することができる。一例として、「ユーザが過去に車で走行したことのある道の幅」から運転レベルを判断してもよい。道幅を１０段階程度にレベル分けし、図８のように、各道路ごとに道幅レベルを設定しておく。ユーザが過去走行したことのある道路のうち、最も道幅レベルが低い値を、当該ユーザの運転レベルと定義する。つまり、道幅の狭い道路を利用する人は運転が上手いとみなすのである。例えば、図８の迂回路（道幅レベル＝５）をレコメンドするコンテンツは、運転レベルが５より低いユーザには提供しない。運転レベルの判断方法はこれに限らない。例えば、道幅をレベル分けするのではなく、道幅（何メートルか）自体で判断してもよい。また、ユーザが迂回路の走行経験がある場合（あるいは多い場合）に運転レベルが高いと判断してもよい。また、ユーザの積算走行距離が長いほど、運転年数が長いほど、運転レベルが高いと判断してもよい。迂回路や運転の難しい道のレコメンドは、運転レベルが高い人にのみ送ることが望ましい。また、車両に搭載された加速度センサのセンサデータを基に、ブレーキやアクセルの使い方が上手かどうかを評価し、運転レベルを判断してもよい。

ストレスレベルは、ユーザがそのコンテンツを受け取ること、もしくは、そのコンテンツに従って行動を変更することで、ユーザが受けるストレスの程度である。ストレスレベルは、ユーザの個人状態、ユーザに対し過去に提供されたコンテンツ、そのときのユーザの状況、そのコンテンツの受入率などから判断される。例えば、ユーザ状態管理ＤＢ１３２の「障害情報」に何か記録されているユーザ（歩行困難者など）や、「同伴者」が多いユーザには、車以外の移動手段は受入不可能（車以外の移動手段への変更をお願いしてもユーザはストレスに感じるだけ）と予想されるので、そのようなコンテンツは提供しない。また、ユーザがすでに車の走行を開始している場合、他の移動手段への変更は受入不可能と予想されるので、そのようなコンテンツは提供しない。また、直近の所定期間（例えば１週間）内に、今から提供しようとしているコンテンツと同じコンテンツを当該ユーザに提供したが受け入れられず、かつ、当該ユーザの特性・状態（位置情報除く）がそのときと同じであった場合には、繰り返し同じようなコンテンツを提供するとユーザにストレス（不快感）を与える可能性が高いので、そのような場合はコンテンツの提供は行わないことが望ましい。

コンテンツ選択／提供部１４３は、ステップＳ５０１で抽出したユーザに対し提供コンテンツを配信した場合の受入人数を予測する（ステップＳ５０２）。受入予測人数は、ステップＳ５０２で抽出された人数に、各クラスタのコンテンツ受入率を乗じることで、計算することができる。

提供コンテンツに受入上限数の制限がある場合（ステップＳ５０３；Ｎｏ）であって、受入予測人数が受入上限数を超えている場合には、コンテンツ選択／提供部１４３は、受入上限数を下回るようにユーザ数を減らす（ステップＳ５０４）。例えば、迂回路に誘導するコンテンツの場合、迂回路の許容台数以下になるよう、ユーザ数を絞り込む。また、コンテンツに付加するインセンティブ（割引クーポンなど）に発行数制限がある場合は、発行数以下になるよう、ユーザ数を絞り込む。このとき、コンテンツ受入率の高いユーザを優先的に選択すると、コンテンツの受入および渋滞緩和に効果が大きいと期待できる。ただし、ユーザの絞り込みを無作為に行うことも好ましい。無作為にユーザを選ぶことで、コンテンツが提供されるユーザに偏りがなくなり、ユーザ間での不公平がなくなるからである。また、普段はコンテンツ受入率が悪いユーザであっても、状況によってコンテンツを受け入れる可能性もあるし、そのようにコンテンツを受け入れたことで経験を積み、
今後受入率があがる可能性もあるからである。

提供コンテンツに受入上限数の制限が無い場合（ステップＳ５０３；Ｙｅｓ）、コンテンツ選択／提供部１４３は、減らしたい車両数に比べ、コンテンツの受入予測人数が過大である場合のみ（ステップＳ５０５；Ｙｅｓ）、ユーザの絞り込みを行う（ステップＳ５０６）。数台の車を減らせばいいときに、数万人にコンテンツを配信すると、かえって他の交通に悪影響を与える可能性があるからである。したがって、例えば、減らしたい車両数の数倍から数十倍の範囲のユーザ数となるように、ユーザの絞り込みを行うとよい。

以上のように、コンテンツを提供すべきユーザが決定したら、コンテンツ選択／提供部１４３は、提供コンテンツを各ユーザの端末装置２００に対し送信する（ステップＳ５０７）。このとき、各ユーザの行動変容レベルに合わせてコンテンツ内容の記載を変えてもよい。これにより、コンテンツの受入率向上を期待できるからである。例えば、コンテンツ受入率が高いユーザには「いつもご協力ありがとうございます」などの文章を追加するとよい。機械相手でも、お礼を言われたり褒められたりすると、人は嬉しい感情をもつので、今後もコンテンツを受け入れてくれたり、少々無理なお願いをしても聞いてくれる確率が上がるのが期待できる。また、通ったことのない経路を通ってもらうようユーザにお願いする場合には、その経路を通ることのメリットを詳しく記載するとよい。いつも通っている道より迂回した方が渋滞を避けられ旅行時間が短縮できることを知ると、以後のコンテンツ受入率があがったり、コンテンツ提供しなくても迂回する可能性が期待できるからである。

その後、コンテンツ選択／提供部１４３は、コンテンツ受入人数を予測し（ステップＳ５０８）、図１３のステップＳ４０６に進む。ステップＳ４０６では、コンテンツ選択／提供部１４３は、コンテンツの受入予測人数（複数種類のコンテンツ提供を行った場合は、その合計人数）が、渋滞緩和させたい道路から減らすべき車の数に達したかを確認する（ステップＳ４０６）。必要な台数分、車が減らせると予想できたら（ステップＳ４０６；Ｙｅｓ）、ステップＳ４０７に進み、受入予測人数が必要な台数に達してなければ（ステップＳ４０６；Ｎｏ）、ステップＳ４０１に戻って別のコンテンツの提供を検討する。

コンテンツ提供後、コンテンツ選択／提供部１４３は、一定時間、ユーザの端末装置２００からの選択結果（受入／拒否）を受け付ける（ステップＳ４０７、Ｓ４０８）。タイムアウト、もしくはコンテンツの受入上限数に到達した場合は、受付を締め切り、ステップＳ４０９に進む。コンテンツを受け入れてくれたユーザの数が、渋滞緩和させたい道路から減らすべき車の数に到達していれば（ステップＳ４０９；Ｙｅｓ）、図９のステップＳ２０６へ進む。一方、受け入れ人数が足りない場合は（ステップＳ４０９；Ｎｏ）、ステップＳ４００に戻り、コンテンツの再配信を行う。再配信の場合は、すでに提供したコンテンツと同じものを選んでもよいし、別のコンテンツを優先的に選んでもよい。また、コンテンツの提供先（ユーザ）を選ぶ際は、前回コンテンツを提供したユーザとは別のユーザを優先的に選ぶとよい。

図９のステップＳ２０６では、ユーザ情報登録部１２１が、コンテンツを受け入れたユーザの端末装置２００から個人状態値とセンサデータを受信し、そのデータをユーザ状態管理ＤＢ１３２およびユーザセンサデータ管理ＤＢ１３４に保存する。センサデータに基づき、ユーザが目的地に到着したか（あるいは目的地を変更したか）を判断し、目的地に到着（あるいは目的地を変更）するまで、当該ユーザのセンサデータ（つまり移動の履歴）を記録し続ける（ステップＳ２０７）。

ステップＳ２０８では、コンテンツ効果判定部１４４が、コンテンツの提供を受けたユーザがコンテンツに従って実際に行動を変更したか否かを確認する。具体的には、コンテ
ンツ効果判定部１４４は、ユーザのセンサデータの記録（移動履歴）に基づき、当該ユーザが実際に採った移動経路や移動手段、あるいは移動時刻が、当該ユーザが受け入れたコンテンツの条件を満たしていたかを判定し、その判定結果をユーザの端末装置２００に送信する。

最後に、コンテンツ効果判定部１４４が、各ユーザがどのような特性・状態のときに、コンテンツ通りに行動を変えたかどうかを分析し、その分析結果をユーザ行動パターン管理ＤＢ１３３に記録する。また、コンテンツ効果判定部１４４は、データマイニングにより、交通デマンド制御の効果測定を行い、地域全体の行動パターンを分析する。例えば、コンテンツ効果判定部１４４は、システムに登録されている全ユーザを特性・状態の共通性に基づきクラスタリングし、どのような特性・状態の人が、どのような内容のコンテンツを提供されたら、何％程度の行動変化が期待できるかを整理し、その情報をコンテンツ効果管理ＤＢ１３５に保存する。効果判定の結果は、前述のように、コンテンツの提供先の選択に利用される。ユーザが行動を変えるたび、または定期的にコンテンツ効果の判定を行うことで、より適切なコンテンツ提供先の選択が可能となり、コンテンツ受入率の向上を期待できる。

（コンテンツ提供の例）
次に、コンテンツ提供の具体例を説明する。図８に示す地域において、１５時に本線に１００台、迂回路に１０台の車両が走行することが予測された場合に、「１５時に本線から迂回路に２０台移動し、残り１０台は通行時間または交通手段を変更してもらう」という交通デマンド制御を行う例を想定する。図１５は、コンテンツ提供の流れを示すフロー図である。図１５の横軸は時間軸であり、左側のコンテンツ提供から順に実行される様子を示している。

（１）「迂回」コンテンツの提供
まずは、提供優先順位の最も高い「迂回」コンテンツが選択される。「迂回」コンテンツは、迂回への協力をお願いするコンテンツである。「迂回」コンテンツは、インセンティブ授与が無い分コストが安いので、優先的に実行される。

各種ＤＢに基づき、「クラスタ番号ａ，ｂ，ｃに当てはまる人は、迂回をお願いすると、１０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ａ，ｂ，ｃに当てはまり、運転レベルやストレスレベルに問題のない人は、２０人いる」ことが確認できたとする。２０人×１０％＝２人は協力してくれると予測した上で、その２０人に対し「迂回」コンテンツが配信される。システムは、この２０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が受入予測人数（ここでは２人）に達するか、一定時間が経過したら、受付を終了する。図１５の例では、１人のユーザがコンテンツを受け入れたと仮定する。

（２）「駐車場割引＋迂回」コンテンツの提供
「迂回」コンテンツの受入予測人数は２人であり、目的達成（２０台を迂回路にまわす）のためには、残り１８人の行動変更が必要である。そこで、次に提供優先順位の高い「駐車場割引＋迂回」コンテンツが提供される。駐車場割引券というインセンティブが付加されたコンテンツである。

各種ＤＢに基づき、「クラスタ番号ｄ，ｅ，ｆに当てはまる人は、迂回してくれたら駐車場割引券を提供するという提案に対し、５０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｄ，ｅ，ｆに当てはまり、（１）で既にコンテンツを配信した２０人とは異なり、運転レベルやストレスレベルに問題のない人は、８０人いる」ことが確認できたとする。８０人×５０％＝４０人は協力してくれると予測さ
れる。駐車場割引券は発行枚数制限が特にない。しかし、４０人全員に迂回されると、迂回路が状態を起こしていまう。そこで、８０人から３６人を無作為抽出し、その３６人に対し「駐車場割引＋迂回」コンテンツが配信される。システムは、この４０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が１８人に達するか、一定時間が経過したら、受付を終了する。図１５の例では、１８人のユーザがコンテンツを受け入れたと仮定する。

（３）「時間差移動」コンテンツの提供
ここまでのコンテンツ提供により、２０台の車が本線から迂回路へ移ると期待できる。目的達成のためには、残り１０台を本線から減らさなければならない（但し、迂回路にはもう移せないので、通行時間又は交通手段の変更が必要である）。そこで、迂回以外のコンテンツのうち次に提供優先順位の高い「時間差移動」コンテンツが提供される。

各種ＤＢに基づき、「クラスタ番号ｇ，ｈ，ｉに当てはまる人は、時間差移動をお願いすると、５％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｇ，ｈ，ｉに当てはまり、（１）と（２）で既にコンテンツを配信した人とは異なり、運転レベルやストレスレベルに問題のない人は、６０人いる」ことが確認できたとする。６０人×５％＝３人は協力してくれると予測した上で、その６０人に対し「時間差移動」コンテンツが配信される。システムは、この６０人から選択結果（受入／拒否）を受信するのを待ち、一定時間が経過したら、受付を終了する。何人が時間差移動しても構わないので、特に受入人数の上限を設けなくてよい。図１５の例では、５人のユーザがコンテンツを受け入れたと仮定する。

（４）「飲食店無料券＋電車」コンテンツの提供
「時間差移動」コンテンツの受入予測人数は３人であり、目的達成（１０人の通行時間又は交通手段を変更）のためには、残り７人の行動変更が必要である。そこで、迂回以外のコンテンツのうち次に提供優先順位の高い「飲食店無料券＋電車」コンテンツが提供される。飲食店無料券というインセンティブが付加されたコンテンツである。

各種ＤＢに基づき、「クラスタ番号ｊ，ｋ，ｌに当てはまる人は、電車移動してくれたら飲食店無料券を提供するという提案に対し、６０％の確率でコンテンツを受け入れる」こと、「１５時に本線走行予定で、クラスタ番号ｊ，ｋ，ｌに当てはまり、（１）、（２）、（３）で既にコンテンツを配信した人とは異なり、運転レベルやストレスレベルに問題のない人は、３００人いる」ことが確認できたとする。３００人×６０％＝１８０人は協力してくれると予測される。飲食店無料券の発行には管理者の経費コストがかかるため、その発行枚数は３０枚までに制限されているとする。また、「時間差移動」に３人が協力してくれると期待できるため、残り７人が「飲食店無料券＋電車」コンテンツを受け入れてくれればよい。そこで、３００人から３０人を無作為抽出し、その３０人に対し「飲食店無料券＋電車」コンテンツが配信される。システムは、この３０人から選択結果（受入／拒否）を受信するのを待ち、コンテンツを受け入れた人数が７人に達するか、一定時間が経過したら、受付を終了する。図１５の例では、７人のユーザがコンテンツを受け入れたと仮定する。

（５）コンテンツの再配信
ユーザから受信した選択結果を集計すると、通行時間または交通手段の変更の受入人数は目標の１０人に達しているのに対し、迂回の受入人数は目標の２０人に達していない（１人足りない）。したがって、迂回に協力してくれるユーザを１人見つけるため、コンテンツの再配信を行うこととする。

ただし、提供優先順位の最も高い「迂回」コンテンツは、（１）において配信可能なユ
ーザにはすでに配信済みのため、今回は配信しない。次に提供優先順位の高い「駐車場割引＋迂回」コンテンツについては、（２）で全員に配信されたわけではないし、また、（２）で配信されたにもかかわらず、コンテンツ選択受付締切に間に合わなくて選択できなかったユーザがいる可能性もある。したがって、「駐車場割引＋迂回」コンテンツをもう一度配信する。このとき、他のコンテンツを既に受け入れているユーザ、及び、（２）でコンテンツを拒否したユーザは、コンテンツの提供先から除外する。

コンテンツを受け入れた人が１人現れたら、目標が達成されるので、コンテンツ提供処理は終了である。

以上述べた本実施例の構成によれば、渋滞が発生した時又は渋滞発生が予測された時に、地域内にいる一部のユーザにコンテンツを提供し、行動を変更してもらうことで、地域内の交通流を分散することができる。これにより、地域内にある道路の渋滞緩和や渋滞防止を図ることができ、それに伴うＣＯ_２排出量削減や事故削減などの効果を得ることができる。しかも、ユーザの特性や状態、コンテンツの受入率などを考慮し、提供コンテンツの種類（内容）や提供先を決定するので、効果的かつ効率的な行動制御（交通デマンド制御）が実現できる。

＜実施例２＞
実施例２は、上述した実施形態に係る行動制御システムを購買客の行動制御（購買分散）に適用した例である。

スーパーやデパート等の店舗において、その店舗での特売日や、近隣でのイベントなどにより購買客が集中する、また人気店なので常に混雑するなどで、店舗営業に支障が出る（人が多くて店内が混乱、警備の目が届かず万引きが発生、特定商品の品切れ、レジの行列、駐車場に車が入庫できずに入店を断念されるなど）場合がある。実施例２に係る行動制御システムは、このような購買客の集中による問題を避けるため、購買客それぞれに内容の異なる個別コンテンツを提供し、行動を変更（入店時刻の変更、購買物の変更、購買数の変更など）してもらうことで、店舗、及び各売り場への人集中を解消したり、購買対象を分散する。つまり、実施例２の行動制御システムは、店舗における購買客の分布の状況や在庫の状況（全体状況）を、店舗営業に支障が出ない程度の人数や在庫（全体最適の状態）に近づけることを目的とする。

（システムの概要）
図１６は、実施例２に係る行動制御システム（以下、単に「システム」とも呼ぶ）の概要を示している。行動制御システムは、インターネット上のサーバ装置により構成されており、各ユーザがもつ端末装置や、他の装置（店舗情報などを提供するサーバ、データベース、センサなど）とインターネットを通じて通信可能である。

各ユーザは、各自の端末装置を使って事前にユーザ登録を行い、個人特性（性別、年齢、家族構成、住所、勤務地、勤務形態（始業・就業時刻）、車両保有状況など）をシステムに設定する。また、各ユーザが保有するポイントカード等の記録から、各ユーザの個人の状態（購買履歴、よく行く店舗、来店頻度など）のデータがシステムに収集される。

システムは、各ユーザの特性および状態のデータと、他の装置から取得できる店舗関連情報（例えば、カレンダー情報、近隣のイベント情報、店舗の広告・特売情報、店舗の在庫状況、店舗に設置されたセンサの情報、気象情報など）に基づいて、各店舗の混雑や商品の品切れなどを予測する。店舗ないし売り場の混雑や商品の品切れが予測できた場合、システムは、購買客を時間的・空間的に分散させるため、ユーザに対し行動変更をレコメンドするコンテンツを提供する。端末装置で受信したコンテンツを見たユーザが、そのコ
ンテンツのレコメンドを受け入れ、行動を変更（入店時刻の変更、購買物の変更、購買数の変更、店舗の変更など）すると、混雑の緩和や防止、品切れの防止を実現できる。

一方で、システムは、各ユーザがコンテンツを受け入れたかどうかや、実際に行動を変更したかどうかを確認する。そして、システムは、各ユーザがどんな特性・状態のときにどんなコンテンツを受け入れたのかを学習し、データベースに蓄積する。この情報は、次回以降のコンテンツ提供の際に、コンテンツの提供先となるユーザの選択、コンテンツの内容の選択などに活用される。

複数の系列店（同じオーナーが５店舗経営するチェーン店など）がある場合、行動範囲の広い（店舗が固定されていない）顧客に対して、空いている店舗に誘導するコンテンツを提供するとよい。このとき店舗限定の割引券等のインセンティブ授与により、コンテンツの受入率を向上できる。行動範囲の広い顧客全員に割引券を提供するのではなく、購買率の高い顧客の一部をランダムに抽出し、無料券などかなりお得なコンテンツを提供して、通常時の購買率をあげることも好ましい。

セール時間帯を人によって分散させることも好ましい。例えば、一日中いつでも来られそうなユーザに対しては空いている時間帯に使える割引券を提供し、日中働いているユーザに対しては帰宅時間帯や夜間に使える割引券を提供するとよい。

同一商品しか購入しない購買客にはその商品の割引券を提供ことで、その購買客の入店率を上げることができる。類似商品群からとくにこだわりなく購入している購買客には、その中から商品をランダムに選んだ割引券や在庫の多い商品の割引券を提供し、特定の商品が品切れになることを防ぐとよい。

地域内の全員に一律に同じコンテンツを提供しても、有効な結果が得られない可能性が高い。また、もし全員がコンテンツの案内に従い行動変更すると、かえって店舗の混雑や商品の品切れを招いてしまう可能性もある。したがって、データマイニングを利用して、どのような人たちに、どのようなコンテンツを提供すれば、どの程度の割合の人が行動変更してくるかを予測した上で、適切な人に、適切な内容のものを、必要最小限の人に絞って提供するとよい。コンテンツ提供先や提供内容を選択する際には、個人特性、個人の状態、個人の行動変容ステージ、行動を変更することに伴うストレスレベルなどを考慮するとよい。そうすることで、コンテンツ提供されたり行動を変更することでストレスを感じる人に対しては、コンテンツを提供しない、もしくはストレスを感じづらいコンテンツに限定して提供する、といった制御が可能になる。例えば、ユーザが絶対に来られない時間帯や遠すぎる店舗に誘導するなど、無理な行動を引き起こすような内容はユーザにストレスを与えるので、そのようなコンテンツ提供は避けるべきである。

提供するコンテンツの受入率をあげていくため、その人の知識レベルを向上させるための情報提供（少し値段が高くなるが、こういった材料を使った食品の方が健康のためにいい。人気スイーツのシリーズで新作が発売されるなどの情報）を実施する。これは、客単価やあげたり、購買範囲をひろげることにも貢献する。

行動を変更した人に対しインセンティブを授与してもよい。インセンティブは、ユーザが喜ぶであろう情報、モノ、金銭、権利などである。例えば、「情報」の例として、詳細な道路交通情報、シークレットセールの情報など、「モノ」の例として、電車移動時の快適グッズなど、「金銭」の例として、キャッシュ、有料道路や駐車場や店舗での割引券、無料券、クーポン券、パーキングメータ延長券、ポイント、デジタルマネーなど、「権利」の例として、優先レーン利用、車両入場規制のある地域や道路の利用、商品の先行購買権などが例示できる。蓄積ポイント数に応じて上記の情報、モノ、金銭、権利に交換可能
にしてもよい。これによりコンテンツ受入率を向上し、混雑緩和や品切れ防止の効果を高めることができる。ただし、インセンティブの授与は、店舗経営者のコスト増につながるため、提供コンテンツに優先順位を設け、コストがかからないものから優先してコンテンツ提供していくとよい。なお、ユーザの特性や状態に応じて授与するインセンティブの種類や内容を変更してもよい。また、コンテンツをよく受け入れてくれる人（受入ｘ回以上、受入率ｘ％）や、あまり人気のないコンテンツを受け入れてくれる人（電車に乗ったり、時間差で移動してくれる）などは、別途ポイントがたまったり、ポイントの累積率が上がったり、また次回以降の適切なタイミングでインセンティブ付きコンテンツが配信される確率が高くなるような仕組みを採用することも好ましい。

スーパーで、商品を買い物かごに入れたことがリアルタイムで把握できるなら（例えば商品にＩＣタグがついていて、買い物かごにＩＣリーダがついていれば、買い物かごに入れた商品を即座に識別できる）、買い物かごに入れられた商品に合わせた商品をレコメンドしたり、割引券を提供したりしてもよい。

システムの具体的な構成、コンテンツ提供の動作などは、実施例１のものと同じように設計できるため、ここでは説明を省略する。

以上述べた本実施例の構成によれば、購買客の集中による問題を避けるため、地域内にいる一部のユーザにコンテンツを提供し、行動を変更（入店時刻の変更、購買物の変更、購買数の変更など）してもらうことで、店舗、及び各売り場への人集中を解消したり、購買対象を分散することができる。これにより、店舗販売員や購買客は、店舗内の人が多すぎることによるストレスをあまり感じることなく店舗運営や買い物ができる。また、混雑による売り上げ低下（混雑で入店できない、レジが長すぎて購入をあきらめる、特定商品しか注目されない、混雑や品切れによる店舗の印象悪化など）を防ぐことができる。

＜その他の実施形態＞
上述した実施形態の構成は本発明の一具体例を示したものにすぎず、本発明の範囲を限定する趣旨のものではない。本発明はその技術思想を逸脱しない範囲において、種々の具体的構成を採り得るものである。また、本発明の行動制御システムは、多数のユーザの行動を制御して全体の最適化を図る目的で、様々な用途に適用可能である。

例えば、前述した実施例では、ユーザが操作する端末装置（スマートフォンなど）を想定したが、自動運転車の場合には、自動運転車の制御部（人工知能）に対しコンテンツ配信を行うことも可能である。例えば、人工知能が車両に乗っているユーザの特性や状態を把握していれば（各種センサでユーザの表情や行動を検知したり、車両の動きからユーザの特性や状態を推測してもよい）、自動運転車に搭載された人工知能がユーザを介さずコンテンツ提供を受け、ユーザの意思を確認することなく、ユーザの特性や状態を考慮してコンテンツ受入／拒否を自動で決定することが可能である。コンテンツを受け入れて受け取ったインセンティブは、人工知能が勝手に使うこともあるし（今日はユーザが急いでいるなと判断したときに、優先レーンを走る権利を使うなど）、モノをもらったときは、ユーザに喜びを与えるために、なぜもらえたかを説明し、ユーザの喜び度合いを判断して次のコンテンツ受入可否判断に利用することもできる。

また、前述した実施例では、ユーザをクラスタに分類し、クラスタ毎に行動変更率を記録したり、クラスタ毎にコンテンツ提供先候補を選定したが、ユーザ毎に行動変更率の記録やコンテンツ提供先候補の選定を行うことも好ましい。ユーザ毎の行動変更率は、例えば、ユーザに同じコンテンツ（或いは類似のコンテンツ）を提供した回数に対する、ユーザが実際に行動を変更した回数の割合、から計算することができる。このとき、ユーザがコンテンツを受け入れた場合と拒否した場合で、ユーザの状態や外部環境がどう違ったか
を考慮してもよい。ユーザ毎の行動変更率を基にコンテンツの提供先を選定する方法としては、行動変更率の高いユーザを優先的に選んだり、行動変更率の高いユーザと低いユーザが混在するように選ぶなど、目的や期待する効果に応じて適宜の方法を採ることができる。

また、前述した実施例では、ユーザの特性や状態に基づいて、コンテンツの選択・提供や、コンテンツ受入（行動変更）の結果を集計したが、ユーザの特性や状態だけでなく、外部環境（例えば、気象状態、カレンダー、イベントなど）を考慮することも好ましい。

例えば、電力デマンド制御にも本発明を適用可能である。電力需要が高まり電力が不足した際、地域全体が停電にならないようにするためには、電力需要を減らす必要がある。そこで、行動制御システムによって、節電可能な家庭に対し、節電要請のコンテンツ提供を行い、電力需要の削減を図る。このときも各家庭の特性や状態を考慮することで、適切な行動制御ができる。ところで、電力自由化により、どの電力供給事業者からでも電力を買えるようになる。また発電方法は複数あり、天気や発電機器の状態等により、発電事業者が供給可能な電力量は都度変化する。そこで、供給に対して需要が多い、又は多くなると予測される発電事業者がある場合に、コンテンツ提供によって一部のユーザに、他の供給に余裕のある発電事業者に一時的に切り替えてもらうことで、電力供給を分散することができる。これにより、地域全体での電力需要と電力供給のバランスをとることができ、停電を防止することができる。システムは、各家庭の状況や過去のコンテンツ受入率等に基づき、コンテンツの提供先を選択するとよい。また、必要であればインセンティブを授与することで、節電や発電事業者の切り替えなどの行動変更を促進できる。

１００：行動制御システム
１１０：サーバ通信部
１２０：ユーザ行動管理部、１２１：ユーザ情報登録部、１２２：ユーザ分析部
１３０：ユーザ情報記憶部、１３１：ユーザ特性管理ＤＢ、１３２：ユーザ状態管理ＤＢ、１３３：ユーザ行動パターン管理ＤＢ、１３４：ユーザセンサデータ管理ＤＢ、１３５：コンテンツ効果管理ＤＢ
１４０：交通管理・デマンド制御部、１４１：交通状況把握・予測／渋滞判定部、１４２：平準化モデル生成部、１４３：コンテンツ選択／提供部、１４４：コンテンツ効果判定部
１５０：交通状況記憶部、１５１：交通状況履歴ＤＢ、１５２：交通状況予測ＤＢ、１５３：地域内交通経路ＤＢ
２００：端末装置
３００：他の装置

Claims (11)

1. 多数のユーザの行動の全体状況を所定の基準による全体最適の状態に近づけるために、前記多数のユーザの中の選択された一部又は全部のユーザの行動を変更させる行動制御システムであって、
   各ユーザの特性及び／又は状態を表す情報を更新しつつ記憶するデータベースと、
   前記データベースに記憶されている情報に基づいて、前記全体状況を前記全体最適の状態に近づけるために前記選択されたユーザが行うべき行動を決定する行動決定手段と、
   前記データベースに情報が記憶されているユーザの中から選択した一部のユーザの端末装置に、前記行動決定手段が決定した行動への変更を促すコンテンツを送信するコンテンツ提供手段と、
   前記コンテンツの提供を受けたユーザが前記コンテンツに従って実際に行動を変更したか否かを確認する確認手段と、
   前記確認手段による確認結果と前記データベースに記憶されているユーザの特性及び／又は状態に基づいて、前記コンテンツを受け入れやすいユーザの特性及び／又は状態を判定して判定結果を前記データベースに記録するコンテンツ効果判定手段と、を有し、
   前記コンテンツ提供手段は、次に前記コンテンツを提供するときに、前記データベースに記録された前記判定結果に基づいて、前記コンテンツの提供先として選択すべきユーザを決定する
   ことを特徴とする行動制御システム。
2. 前記全体状況が道路ネットワークに対する車両の分布の状況であり、前記全体最適の状態が非渋滞の状態である
   ことを特徴とする請求項１に記載の行動制御システム。
3. 前記コンテンツ効果判定手段は、前記コンテンツを提供した回数に対する前記コンテンツに従って実際に行動を変更した回数の割合である行動変更率をユーザ毎に計算し、ユーザ毎の行動変更率を前記判定結果として前記データベースに記録する
   ことを特徴とする請求項１又は２に記載の行動制御システム。
4. 前記コンテンツ提供手段は、前記コンテンツを提供するときに、前記コンテンツに対する行動変更率の高いユーザを、前記コンテンツの提供先として選択する
   ことを特徴とする請求項３に記載の行動制御システム。
5. 前記コンテンツ効果判定手段は、前記複数のユーザを特性及び／又は状態に基づき複数のクラスタに分け、前記コンテンツを提供したユーザの総数に対する前記コンテンツに従って実際に行動を変更したユーザの割合である行動変更率をクラスタ毎に計算し、クラスタ毎の行動変更率を前記判定結果として前記データベースに記録する
   ことを特徴とする請求項１又は２に記載の行動制御システム。
6. 前記コンテンツ提供手段は、前記コンテンツを提供するときに、前記コンテンツに対する行動変更率の高いクラスタに属するユーザを、前記コンテンツの提供先として選択することを特徴とする請求項５に記載の行動制御システム。
7. 前記コンテンツを受け入れ可能なユーザの数に上限がある場合に、前記コンテンツ提供手段は、前記コンテンツの提供先として選択されたクラスタに属するユーザの数に、当該クラスタの行動変更率を乗じることにより、前記コンテンツを提供した場合の受入予測人数を計算し、前記受入予測人数が前記上限を超えている場合には、前記コンテンツを提供するユーザの数を減らす
   ことを特徴とする請求項６に記載の行動制御システム。
8. 前記コンテンツ提供手段は、内容の異なる複数のコンテンツを提供可能であり、
   前記コンテンツ効果判定手段は、前記複数のコンテンツのそれぞれについて、各コンテンツがどのような特性及び／又は状態のユーザに受け入れられやすいかという効果判定を行い、前記複数のコンテンツそれぞれの効果判定の結果を前記データベースに記録する
   ことを特徴とする請求項１〜７のいずれかに記載の行動制御システム。
9. 前記複数のコンテンツは、行動を変更したユーザに対しインセンティブを授与するコンテンツと、行動を変更したユーザに対しインセンティブを授与しないコンテンツを含み、
   前記コンテンツ提供手段は、行動を変更したユーザに対しインセンティブを授与するコンテンツよりも、行動を変更したユーザに対しインセンティブを授与しないコンテンツの方を優先的に提供する
   ことを特徴とする請求項８に記載の行動制御システム。
10. 多数のユーザの行動の全体状況を所定の基準による全体最適の状態に近づけるために、前記多数のユーザの中の選択された一部又は全部のユーザの行動を変更させる、行動制御方法であって、
    コンピュータが、各ユーザの特性及び／又は状態を表す情報をデータベースに更新しつつ記憶させるステップと、
    コンピュータが、前記データベースに記憶されている情報に基づいて、前記全体状況を前記全体最適の状態に近づけるために前記選択されたユーザが行うべき行動を決定するステップと、
    コンピュータが、前記データベースに情報が記憶されているユーザの中から選択した一部のユーザの端末装置に、前記決定した行動への変更を促すコンテンツを送信するステップと、
    コンピュータが、前記コンテンツの提供を受けたユーザが前記コンテンツに従って実際に行動を変更したか否かを確認するステップと、
    コンピュータが、前記確認結果と前記データベースに記憶されているユーザの特性及び／又は状態に基づいて、前記コンテンツを受け入れやすいユーザの特性及び／又は状態を判定して判定結果を前記データベースに記録するステップと、を有し、
    次に前記コンテンツを提供するときに、前記データベースに記録された前記判定結果に基づいて、前記コンテンツの提供先として選択すべきユーザが決定される
    ことを特徴とする行動制御システム。
11. 請求項１０に記載の行動制御方法の各ステップをコンピュータに実行させることを特徴とするプログラム。

Images