コミュニティ状況考察結果の評価，検証

（１）シミュレーションによる考察

（ⅰ）シミュレーションによる実現イメージ

第４章，４.３.３項において，コミュニティの変動による匿名度変化への対処につ いて，人の流れや付帯する属性情報などを予め把握し，ユーザにその旨を伝え，ユー ザの意志を反映した属性開示制御手法の考え方を述べた．マルチエージェントシミュ レータ[75]を用いたシミュレーションにより，この手法の可能性を検証し，妥当性を 評価する．とりわけ，サービス領域に向かう人の状況を事前に把握し，それに基づく 開示属性の変化について予めユーザと交渉することによるオプトイン開示コントロー ルの可能性を検証する．この様子を図５.２，図５.３に示す．

図５.２において，歩行者エージェントは，空港で搭乗ゲートに向かう顧客を想定し，

入口からアプローチであるＡエリアを通り，Ｂエリアでサービスを受け C エリアから 出口へと移動する．Ａエリアで人数や属性などをセンスする．ここで，“コミュニテ ィ”とは物理的な同一空間で同一サービスを受けるユーザ集合であり，歩行者エージ ェント全体はパスポートなどで把握されているとする．但し，考え方としてはユーザ どうしが物理的に離れていてもインターネットや無線で論理的に繋がっており，パー ソナル情報も同じＤＢ上処理され同じＰＰＳを通じてサービスを受けるような場合は，

同じコミュニティとして扱うべきであり，考え方としては問題ない．但し，その時の コミュニティ変動の予測内容は，変動する属性の内容やセンス方式により決められる ことになり，システムデザイン時における今後の課題の一つである．

第 ５ 章 提 案 手 法 の 評 価，検 証

89 パラメータなど条件設定は以下のとお りである．

（１） 歩行者エージェントがＡエリア を通過する平均時間をＡ_tステ ップ（単位時間），サービスを 受けるためにＢエリアに滞在 する平均時間をＢ_t ステップと し，Ａ_t ，Ｂ_tの関係をＢ_t= α

×Ａ_tとする．

（２）入口より入ってくる歩行者エー 図 ５.２ コミュニティ変動シミュレー ジェントの数は平均ｍ個／ステ ション[26]

ップとし，その時間間隔はラン

ダム（乱数）とする．また，進行方向や歩行速度の制御や分布などは歩行者モ デル ASPF（Agent Simulation of Pedestrian Flow）[64]による．

（３）歩行者エージェントに付帯する属性数Ｐは４個とし，それぞれを一様分布で発 生させ，匿名度の計算はＫ匿名性の考え方に則り，Ｂエリアに滞在してサービ スを受けているある歩行者エージェント（自分）と同じ属性を持つ，Ａエリア あるいはＢエリアの歩行者エージェントの数とする．

図５.３は，仮に α=２，Ａ_t=40 ステップ，Ｂ_t=80 ステップ，m=0．3 とした場合の 状況である．上下のグラフは，それぞれＡエリア，Ｂエリアの状況を示す．

Ａ(t)，Ａ１(t)，Ａ２(t)はそれぞれ時間 t におけるＡエリアの人数，属性１の匿名 度，属性２の匿名度を示し，同様にＢ(t)，Ｂ１(t)，Ｂ２(t)はそれぞれＢエリアの人 数，属性１の匿名度，属性２の匿名度を示す．

グラフより，

Ｂ(120) ≒ Ａ(40) + Ａ(80)，Ｂ(160) ≒ Ａ(80) + Ａ(120) など，あるいは，

Ｂ１(440) ≒ Ａ１(360) + Ａ１(400)，Ｂ１(480) ≒ Ａ１(400) + Ａ１(440) などを読み取ることができ，Ｂエリアの状況がＡエリアの状況より予側できることを 示す．これは，Ｂ_t=２Ａ_tの関係より平均値的に

Ｂ(40n) ≒ Ａ(40(n-1)) + Ａ(40(n-2))， ただしｎは２以上の正整数，

の関係が成り立っているからである．すなわち，図５.３のＢエリアにおいて匿名度Ｂ １については言えば，時刻 440 時点にて，時刻 480 時点には希望匿名度を上まわるこ とが予側でき，時刻 440 時点でユーザと事前に開示属性について交渉し，開示承諾可 否の意向を伺うことができ，オプトイン制御が可能となることを示唆している．

意向確認内容は，確認済み開示可能属性の，コミュニティ変動による実際にサービ スを受ける直前の変化であり，ユーザとの交渉にかかる時間などを考えた場合，開示

第 ５ 章 提 案 手 法 の 評 価，検 証

90 時点（現在）より，

本研究では 40 お よび 80 ステップ 遡った時点（過去）

のデータより予測 される現時点での 開示可能属性の状 況を確認するのが 現実的といえる¹ ． つまり未来を予測 するというより過 去より現在を予測 する考え方である．

以上，シミュレ ーションによりコ ミュニティ状況の 考察による考え方

についての実現イ 図 ５.３ 匿名度変化シミュレーション[26]

メージ，基本的

考え方は確認できるものの，実際の応用に向けては表５.４に示すような課題があり今 後の検討課題である．

表 ５.４ シミュレーションにおける残課題

（ⅱ）プライバシ保護の検証

基本的には４.３節でも述べたように予測により開示属性を増やせる状況において は，何らかの確認メッセージを事前に伝えることはでき，意向確認を踏まえたオプト インによる制御は可能であることから前節評価視点①は問題ないといえる．

1 詳細は，第６章「６.２.１ 処理シーケンス」で述べる．

第 ５ 章 提 案 手 法 の 評 価，検 証

91

一旦開示した情報の開示を中止するような場合は，サービス実行をリトライする場 合，つまり最初のサービスですでに開示済みの属性が次のサービス実行ではコミュニ ティ変動で匿名度が下がり開示不可能になるときである．この場合ユーザは最初の開 示は意識しており，またこの開示中止の処理は少なくとも再設定したＬより匿名度を 下げることにはならず，事前告知による一刻も早い開示中止処理は，ユーザ諒解のも と匿名度の犠牲を最小限にすることで評価視点②も問題ないといえる．一旦開示され た情報であっても，情報寿命がＴＴＬ（Time To Live）でコントロールされているよ うな場合は，一刻も早く開示を止めるのは適切な措置である．以上，評価視点①②に おいて問題ないことの確認である．表５.５はそのまとめである．

表 ５.５ コミュニティ状況考察結果におけるプライバシ保護の評価・検証

（２）シミュレータの概要

（ⅰ）マルチエージェントシミュレータ「artisoc」

上述シミュレーションで使用したシミュレータ artisoc （artificial societies：

人工社会）は，自律的に行動する人間（エージェント）の行動ルールおよび相互作用 を定義し，コンピュータの中に人工的な社会を構築することで，ダイナミックに変化 する社会などの複雑系を再現・分析するマルチエージェント・シミュレータである[75]．

人工社会として社会現象のモデルを作りシミュレーションを実行することを念頭に 置いて開発され，様々な社会現象を扱うことが可能で，適用例は，電力取引自由化，

雇用政策，排出権取引といった制度設計・政策の評価から，津波・洪水発生時の避難，

災害救援物資の輸送，店舗・道路の人流・渋滞などを含む防災，避難，交通といった 環境評価まで多岐にわたっている．

データベースや各種センサ機器からのデータ取り込み，コンピュータの中のエージ ェントを人間がＷｅｂ画面から操作するＷｅｂサービス，ネットワーク上の複数のマ シンを並列実行させる等，実務システムの一部としてのマルチエージェントのアプロ ーチを適用できる数々の連携機能をも有する．

Universe・空間・エージェントという３層構造を基本的な枠組みにして，人工社会

第 ５ 章 提 案 手 法 の 評 価，検 証

92

を簡単に作ってシミュレーションをできるようにしただけでなく，人工社会への関与

（操作や調査）も簡単にできるようにしたシミュレータである．もう一つの大きな特 徴は，シミュレーション実行過程をリアルタイムで「見る」ことができ，空間上をエ ージェントが動き回ったり相互作用をしたりする様子は，簡単な設定をすることによ りパソコン上で見ることができる．また，集計した値を時系列グラフとして表すこと もできる．図５.２や図５.３はこのような機能を用いて描いた．

標準的な作り方を以下に示す．

人工社会の基本的な構造は，多数のエージェントとそれらが相互作用する空間であ る．「多数のエージェント」というのは，単一タイプのエージェントが多数でも良い し，様々なタイプのエージェント１体（少数）ずつでも構わない．artisoc ではエー ジェントのルールをタイプごとに記述するので，同じルールで行動するエージェント はひとまとめにしておくと便利である．エージェントのルールは，シミュレーション に際して最初だけ実行されるものと繰り返して毎ステップ実行するものに大別されて いる．たとえば，多数のエージェント（トリを 100 羽）を 50×50 の大きさの空間（大 空）の中央からランダムな方向に直進させるというモデルを実行したいとき，必要な 入力作業は，次のようなものになる．

（１）「大空」という空間名（50×50 という空間の大きさはデフォルト値なので入 力不要），「トリ」というエージェント名，100 という個体数（デフォルト 値は０）をダイアログ・ボックスに書き込む．

（２）エージェントのルールエディタに，初期設定のルールとして my. X＝25

my. Y＝25

my. Direction＝rnd()＊360 毎ステップ実行するルールとして

Forward⑴

と，合計４行のルールを書き込む．これだけで，実行ボタンを押せば直ちにシミュレ ーションを実行できる．因みに，my.Direction＝rnd()＊360 というルールを初期設定 の部分から毎ステップ実行部分に移すと，全く違うルールにしたがってエージェント が行動することになる．ルールは，順次実行，繰り返し，条件分岐の３構造の組み合 わせからなり，具体的なルールのほとんどは既に用意されている関数（組み込み関数）

を利用する．

最新バージョンでは，より大規模なシミュレーションを可能にするため，64bit メ モリ空間に対応し，3 次元表示，複数空間の同時表示，出力画面のグループ化，およ び 2 次元マップでのエージェントのサイズ・透明度指定などシミュレーションの表現 力向上を実現し，直感的な分析が可能になっている．