要件

4.2節で述べたユースケースを踏まえて，Inter PPRに対する要件を述べる．まず，各組 織に必要なプライバシ保護の要件について述べ，次に，プライバシ保護によって低下が懸 念される，処理性能と推薦精度の要件について述べる．

4.3.1 プライバシ保護の要件

ID管理組織と商店と訪問者の3者は，それぞれの立場から安全性に対して次の要求を 持つ．ID管理組織はユーザから預かっている個人情報を漏洩したくない．商店は商店が 記録した履歴データを漏洩したくない．訪問者は自身のプロファイルに沿った適切な推薦 を受けたいが，プロファイルなどのプライバシ情報は漏洩したくない．

提案システムに対する攻撃者としては，システムの利用主体(すなわちID管理組織，商 店，訪問者)と，外部からの攻撃者が想定される．本論文の主旨は主体間のプライバシ保 護であるため，ここでは攻撃者としてシステムの利用主体を前提とする．外部からの攻 撃者については，SSL(Secure Sockets Layer)，WPA(Wi-Fi Protected Access)，ファイアー ウォール，侵入検知などの別技術によって対応するものとする．

攻撃者のモデルとしては，他の主体との通信において能動的な攻撃を仕掛けるmalicious adversary と，そのような攻撃を行わないsemi-honest adversary が考えられる．ID管理 組織は事業者であるため，契約，従業員教育，計算機の操作に関する監視・監査により，

maliciousな攻撃を行わないようにできると考えられる. また，プロトコルの実装プログラ

ムとして正規のプログラムのみ利用されるように，プログラムの認証および改ざん防止機 能を設けることができるので，semi-honestを想定する．商店も事業者であり，ID管理組 織との提携における契約およびID管理組織と同等の対策によって，同等の安全性を担保 できるため，semi-honestを想定する．訪問者は，任意の個人が含まれるため，実装プロ グラムの認証および改ざん防止といった対策を講じたとしても，maliciousを想定する必 要がある．

以上のことから，プライバシ保護の要件は下記のように具体化される．

(要件1)プライバシ保護の要件

ID管理組織と商店がsemi-honestで，訪問者がmaliciousの想定において，ID管理 組織が保有する個人情報と，商店が保有する履歴データと，訪問者のプロファイル を，各々他の2者に対して秘匿できること．

“(要件1)各々他の2者に対して秘匿する”をプロトコルの内と外で分割して，プライバ シ保護の要件を詳細化する．

(要件1a)プロトコル自体の安全性

プロトコルの利用主体は，そのプロトコルの出力情報を除いて，相手主体のプライ ベート情報を入手できないこと．

(要件1b)プロトコルの出力の安全性

プロトコルの利用主体は，そのプロトコルの出力情報から，相手主体のプライベー ト情報を推定できないこと．

4.3.2 推薦精度の要件

個人情報と履歴データと訪問者のプロファイルの全てを保有している大組織と同等ある いはそれに近い推薦精度であることが望ましい．大組織のみで処理が完結する場合は，ス ムージングなどの一般的な推薦精度向上の方法を適用できるため，組織間においてもス ムージングによって推薦精度を向上させたい．また，大組織のみで処理が完結する場合 は，プライバシ保護による精度低下は生じないため，組織間で新たに必要とされるプライ バシ保護によって推薦精度を低下させたくない．

以上のことから，組織間での推薦における精度の要件は下記のように具体化される．

(要件2a)スムージングに対する推薦精度の要件

個人情報と履歴データを直接扱えなくても，スムージングにより推薦精度を向上で きること

(要件2b)プライバシ保護に対する推薦精度の要件 匿名加工による推薦精度の低下を抑止できること

4.3.3 処理性能の要件

ID管理組織と商店と訪問者の3者は，それぞれの立場から処理性能に対して次の要求 を持つ．商店は，定期的に新商品を取り入れたり，売れ行きの良い商品を選別するなどし て，魅力のある推薦を保ちたい．訪問者は商店を訪れた際に直ちに推薦を受けたい．

以下では，ID管理組織や商店が取り扱うデータの規模や内容を，日本の電子マネーで 最大の決済件数を誇るnanaco[93]に倣って想定する．

まず，ID管理組織の個人情報について．2017年2月末時点のユーザ数は5,350万人で ある[94]．これより，個人情報のユーザ数(以後，N と表す)は10⁷ ∼10⁸人を想定する．

個人情報のプロファイルについては，年代と性別と住所の項目を想定し，プロファイルの 項目数(以後，W と表す)は3項目を想定する．また，各プロファイルの項目が取りうる 値は，年代は8区分(10代から10才刻み．80才以上は区別しない)，性別は2区分，住 所は47区分(都道府県)とし，プロファイルの値の種類数(以後，V と表す)は57種類を 想定する．

次に，商店の履歴データについて．全国23万箇所で1ヶ月に1.68億件の電子マネー決 済が行われていることから[94]，1ヶ月1箇所あたりの決済件数は730件である．この値 は商店の規模，所在地，業種，訪問者のリピート率などにより大きく異なると考えられる ため，履歴データに含まれる人数(以後，M と表す)は10² ∼10⁵ 人を想定する．商品の 種類数については，飲食店のメニューは高々100種類を想定すれば十分と考えられるが，

コンビニエンスストアの商品は2,800種類もある[95]．商店の規模，所在地，業種などに より大きく異なると考えられるため，商品の種類数(以後，Lと表す)は10∼10⁴種類を 想定する．また，全国で1回あたりの決済金額は 907円/回であるので[96]，一度の決済 で購入される商品は数種類であると考えられる．履歴データを月単位に締めるとすると，

訪問者が毎週商店を訪れたとしても1ヶ月にユーザが購入する商品は十数種類であると考 えられるので，履歴データに含まれる1人あたりの商品の種類数(以後，Gと表す)は10 種類を想定する．ID管理組織や商店が実際に取り扱うデータの規模と内容を整理すると 表4.1となる．

ID管理組織-商店間プロトコルの処理に許容される時間は，このプロトコルの実行間隔 (以後，T₁ と表す)から決定する必要がある．T₁ が長すぎると推薦内容が流行から遅れて しまう．一方，短すぎると，T1の間に履歴データがほとんど変化しないので，ID管理組 織-商店間プロトコルを再実行しても推薦結果は変わらない．また，T1 が短いとプロトコ ルを短時間に実行する必要があり，高速の計算設備が必要となる．そのため，T₁が短すぎ

表4.1 データの規模と内容

データの種類 データの規模のパラメータ 値の範囲 ID管理組織の 個人情報に含まれるユーザ数(N) 10⁷ ∼10⁸ 人

個人情報 プロファイルの項目数(W) 3項目 プロファイルの値の種類数(V) 57種類 商店の履歴データ 履歴データに含まれるユーザ数(M) 10² ∼10⁵ 人

(1ヶ月分) 商品の種類数(L) 10∼10⁴種類 1人あたりの商品の種類数(G) 10種類

るとコストパフォーマンスが低くなる．最適な実行間隔T₁ は業界等によって異なる．た とえば，洋服の推薦であれば季節ごとに商品を入れ替えるために3ヶ月であったり，ゲー ムのように日々新たなタイトルが登場するのであれば1日であったりする．そのため，T1

の具体的な値は文献等でも殆ど言及されていないが，[97]では1ヶ月となっている．Inter PPRではプライバシを保護するため，クロス集計表に匿名加工のノイズを加える．そのた め，T1 が短すぎると，ノイズによるクロス集計表の変化が，ユーザの嗜好の変化による 履歴データの真の変化を上回ってしまい，ユーザの嗜好の変化が推薦結果に反映されなく なってしまう．以上から，今回は一例としてT₁ を1ヶ月に設定することとし，T₁の増減 による影響については7.4節で考察を行うこととする．

以上から，表4.1に示したデータの規模や内容で，ID管理組織と連携した購入傾向の生 成を1ヶ月以内に実行可能となるようにシステムを設計する必要がある．また，商店-訪 問者間プロトコルにより，訪問者が商店を訪れたときの商品の推薦はリアルタイム(ある いは準リアルタイム)である必要がある．その許容時間(T2 とする)は小さいため，たと えば5秒と想定すると，表4.1に示したデータの規模や内容で，訪問者への推薦を5秒以 内に実行可能となるようにシステムを設計する必要がある．

以上のことから，処理性能の要件は下記のように具体化される．

(要件3a) ID管理組織-商店間の処理性能の要件

ID管理組織-商店間プロトコルは，表4.1のデータの規模と内容において，許容時 間T₁ の制約を満たすこと．

(要件3b)商店-訪問者間の処理性能の要件

商店-訪問者間プロトコルは，表4.1 のデータの規模と内容において，許容時間T2

の制約を満たすこと．

4.3.4 社会実装容易性の要件

中小組織の間で推薦に必要な情報を統合利用したいが，2.3節で述べたように，ユーザ IDとプロファイルの管理が避けられず，中小組織には負担が重い．また，中小組織は保 有するデータ数が少ないことから，多組織間の連携に拡張可能なシステムであることが望 ましい．

以上のことから，社会実装容易性の要件は下記のように具体化される．

(要件4a)ユーザIDおよびプロファイルの安全な利用と負担抑制の要件

ユーザIDおよびプロファイルを安全に管理し利用するにあたって，新たな負担が 少ないこと．

(要件4b)多組織間連携への拡張性の要件

ID管理組織と商店の2組織間の連携だけでなく，ID管理組織と複数の商店の間の 多組織間連携に拡張可能であること．