第６章 今後の課題と留意点
６.３.３ プロバイダにおけるプライバシ保護
第 ６ 章 今 後 の 課 題 と 留 意 点
115
第 ６ 章 今 後 の 課 題 と 留 意 点
116 とその自然淘汰を経て，サービスが進化する．
（３）サービスコンテンツ生成におけるプライバシ保護
プロバイダがサービスンテンツを生成し提供するとき， 同類のコンテンツ内容を提 供できる個人(ＳＣ所有者)が，ある論理的エリア内に複数いる場合にのみ，その情報 をサービスコンテンツとして扱うことにより匿名性を確保する．いわゆるＫ－匿名性 によってプライバシ保護を実現する．その場合の課題は, 匿名度の評価をどう定義し, その定義によってサービス合成に必要なＳＣをいかに発見し,いかに合成するか, と いうことである．
図６.１２は，この考え方による匿名性確保のイメージを示す．サービス要求者ＳＲ
（Service Requester）の発信する入力情報1 をキャッチしたＳＣ１とＳＣ２がサービ スを合成し，それぞれ入力条件にあわせて処理を行い，それぞれの出力をＳＲの出力 条件に合わせ出力する．ＳＣ１は匿名度Ｋ＝２を要望し，ＳＣ２は匿名度Ｋ＝３を要 望する場合，それぞれ，同じサービスを提供できるＳＣを自律的に発見し，匿名度を 確保する．つまり，匿名度を確保するためにＳＣ１はＳＣ３を発見し，ＳＣ２はＳＣ ４とＳＣ５を発見している．
図 ６.１２ サービス合成における匿名度確保のイメージ図
（４）サービスコンテンツ生成における匿名度確保の考え方
前述趣旨による匿名度の評価を以下に定義する．
1 情報推薦サービスの場合なら，嗜好や行動履歴など．
第 ６ 章 今 後 の 課 題 と 留 意 点
117 Ｖ ＝ Ｋ´Ｓ
ただし, Ｖ : 匿名度評価値
Ｋ´ : コンテンツ提供者が望む匿名度（Ｋ）確保のために発見さ れた同類コンテンツを持つＳＣの数
Ｓ : Ｋ´個のＳＣの類似度
すなわち, 希望匿名度(Ｋ)を確保するために発見され集められた同類コンテンツを 持つＫ´個のＳＣがすべて同一の属性を持つとは限らないので, それらの類似度Ｓを 計算し, ＳとＫ´の積で匿名度評価Ｖとし, ＶがＫ以上になってはじめて所望する匿 名条件が満たされるものとする． 図６.１３にその概念を示す．
図 ６.１３ サービス合成における匿名性確保の概念[62]
（５）コンテンツサービス合成・実行
ＳＣの探索, 発見の手がかりとなるＳＣのサービス記述ＳＣＳＤ1 は, 以下４つの セマンティックメタ属性, つまり, サービス内容(What), 利用目的(Why), 利用日時 (When), 利用場所(Where), および入出力インタフェースなどサービスを利用するた めの情報から成るとする．表６.２にＳＣＳＤのセマンティックメタ属性の例を示す．
表 ６.２ セマンティックメタ属性の例
サービス内容 利用目的 利用日時 利用場所 格安航空券情報 海外旅行 2012.10.01 ロンドン, パリ
1 SC Service Description の略．
第 ６ 章 今 後 の 課 題 と 留 意 点
118
サービス要求者ＳＲの要求内容ＳＲＳＤ1 に基づき複数のＳＣが並列的にサービス を合成する場合の手順を以下に述べる．
手順 １：
ＳＲは自分の要求（ＳＲＳＤ）を入出力条件などとともにネットワークに 開示する．手順 ２：
そのＳＲの要求に自分なら対応できると最初に察知したＳＣがトリガーに なって連携できる他のＳＣを探索, 発見し合成する．合成条件は, サービ ス内容(What), および他３つのメタ属性のうちの１つ以上がＳＲＳＤと 共通しているとする．手順 ３：
合成に参加するＳＣの希望匿名度(Ｋ)を満たすために前節で述べた匿名度 制御がなされる．手順 ４：
最終的に合成された新ＳＣはＳＲより評価を受けＯＫサイン受領後実行さ れる．（６）まとめ
複数のＳＣが結託してサービスコンテンツを生成する場合，同じ属性を持つＳＣを 探索することでＫ－匿名性に基づく，プライバシ保護の基本的な考え方を提案した．
今後，ますます Facebook や Twitter などのＳＮＳを介して一般個人が発信する情報 が多くなりサービスコンテンツとして利用されるようになれば, 現在プロバイダにお いてシステム的に個人名を伏せている情報についても, リンケージ推論による個人識 別の危険性を防ぐために，匿名性によるプライバシ保護の仕組みが必要になってくる ことが予想される．
本研究のアイデアを展開させたサービスシステムをデザインする場合，プロバイダ 側のプライバシ保護については，本項の提案を参考にして留意することにより，関連 システムも含めたトータルなプライバシ保護が実現されると考える．
６．４ 結言
今後，本研究の考え方をベースに何らかの実用的なシステムをデザインし，構築し ていく場合に，検討が欠かせないあるいは留意が必須な項目がたくさんあるなかで，
前者については，
（１）処理シーケンス
（２）アーキテクチャ
（３）ＵＩ画面
1 Service Description の略．
第 ６ 章 今 後 の 課 題 と 留 意 点
119
の３項目を取り上げ，今後の課題として述べ，後者については，
（１）パーソナル情報の二次使用におけるプライバシ保護，
（２）プロバイダにおけるプライバシ保護
の２項目を取り上げ，今後の展開における留意点として述べた．
各項において述べたキーポイントを以下に記す．
「処理シーケンス」の項では，決定木の生成やユーザ背景情報探索のタイミング，
あるいはコミュニティ状況のチェックやプロバイダへの情報開示のタイミングなど，
また，最終的にいつサービスを受けるのか，というシーケンスについて述べた．
「アーキテクチャ」の項では，ブロック的な機能を果たす各機構について述べたの ち，各機構を構成するモジュールについて述べた．
「ＵＩ画面」では，第４章の空港待合室でのグループ事例において，あるユーザが コミュニティに参加し，始めてサービスを受けることを想定したときの，端末に表示 されるＵＩ画面の例について述べた．
「パーソナル情報の二次使用におけるプライバシ保護」では，今後，パーソナル情 報がネットワークにおいて蓄積・流通され，多種多様なパーソナルサービスが普及し ていく場合，二次使用により個人が識別されないように匿名性を確保することが必須 であること，そのためには個人識別因子を除き“非個人情報”化することが不可欠で あること，そのための手法などについて述べた．本研究の提案手法における，意図し ない匿名度の犠牲を避けるという基本的特徴はプライバシ保護の原点であり，二次使 用におけるプライバシ保護においても極めて有効であると考える．
「プロバイダにおけるプライバシ保護」では，今後 Facebook や Twitter などの ＣＧＭを介して，一般個人がプロバイダの立場でコンテンツを提供する場合のプライ バシ保護のために，Ｋ－匿名性を用いる方法によりサービス生成におけるプライバシ 保護の実現について述べた．
第 ７ 章 お わ り に
120
第７章 おわりに
現在，社会では IC カードや GPS 機能を装備した携帯電話等のセンサーデバイスの 普及や，Web 上でのブログ，SNS，EC サイト等の広がりにより，個人に関連する様々 な情報がリアル／バーチャルの双方で集積されつつある．実際にこれらのパーソナル 情報を活用することで，携帯電話を利用した生活支援サービスや，行動ターゲティン グ広告など，様々なパーソナルサービスが国内外で展開され始めており，利用者はそ のメリットを享受しつつある．また，これらのパーソナルサービスが産みだす市場の 規模は大きく，今後も様々なパーソナルサービスが実現され，パーソナルサービス産 業とも呼べる一大産業が新興すると考えられる．
その一方で，パーソナルサービスに用いられる情報の中には日々の生活情報も含ま れるため，自身の情報が利用されることに対し抵抗感を持つ人も多い．そのため，こ れらの情報を蓄積・利用する場合に，プライバシに対する配慮は不可欠であり，技術 的な解決策と共に，行政，学会を含めた業界内の協調も必要である．しかし，これら の情報の取り扱いについては，関係省庁のいわゆる“配慮原則”に見られるガイドラ インでは定性的で曖昧な判断基準が多く，産業界では現状ケース・バイ・ケースで対 応している状況である．
このような背景を鑑み，ユーザが自身の情報を提供し利活用されることに，少しで も抵抗感なく安心できるシステム，ひいては環境の構築を支援し，業界の活動が行政 のガイドラインに沿えるべく，プライバシ保護に関し独自の課題を掲げ，その解決へ の提案手法を示した．
具体的には，課題：ユーザ背景情報の扱い方，についてコミュニティ状況を考察し つつ明らかにした．つまり，プライバシ保護とサービス品質の間で発生するトレード オフの観点より，解決する手法を提案しその有効性を示した．以下にまとめる．
[課題] ユーザ背景情報の扱い方
キーポイントは「プロバイダに希望匿名度Ｌを損ねるユーザ背景情報があるとき如 何に対処するか」であり，匿名化手法によって，意図しないパーソナル情報が漏れる ことを防ぎ安心感を与えることを狙う．つまり，ユーザが希望する匿名度に従ってプ ロバイダに情報を提示する際，万一プロバイダにユーザに関する何らかの背景情報が あるとき，実質匿名度が下がる可能性があるので，開示する情報の見直しをユーザに 告げ安心させる手法を講じる．平たく言えば，もしプロバイダがそのユーザのことを よく知っているなら，あえていろいろな情報を渡す必要はなく，その旨をユーザに伝