結城浩
RFIDなどの、固有IDの問題を考えるためのシンプル・シナリオを提示します。
シンプルなシナリオと具体例を通して、固有IDの注意点がどこにあるかを明確にしましょう。
このページでは「固有ID」（商品などのアイテム1つ1つに振られる異なる番号）というものが引き起こす可能性のある問題を、 できるだけシンプルなシナリオを通して解説します。
固有IDの例として、RFID、サブスクライバID、Webのクッキーなどが考えられますが、 ここではできるだけ特定の技術に依存しないように解説を進めます。
言うまでもありませんが、 このページへのリンクはご自由に。 結城に許可を求める必要はありません。
このページをお読みになった後は、 ぜひ、 「固有IDのシンプル・シナリオ・チェックリスト」もお読みください。
このページの構成は次のようになっています。
まず、 「固有IDのシンプル・シナリオ」では、図と文章を用いて「固有IDのシンプル・シナリオ」とわたしが呼んでいるシナリオを解説します。 この部分は特定の技術に依存せず、 また善悪の区別や、違法性の有無について 判断できないような形式で書きました。 アリスやボブという固有名詞を使っていますが、 これは単なる役割の名前であると考えてください。 この「固有IDのシンプル・シナリオ」はいわばフレームワークなのです。
次に シンプル・シナリオ適用例では、「固有IDのシンプル・シナリオ」に対してもっと具体的な肉付けをします。 カードのスキャナや、離れてIDを読み取れるチップのように、 登場する技術に多少の具体性が加わります。 適用例の中には「問題のない例」「プライバシーの侵害と感じられる例」「違法性を持った例」 「非常に現実味のある例」「近未来にならないと実現できそうもない例」などが含まれるでしょう。 もっと具体化しないと何も判断・評価できないものがあるかもしれません。 しかし、いずれの例も、 はじめに述べた「固有IDのシンプル・シナリオ」を適用した例になっているはずです。
最後に 固有IDに関連するQ＆Aでは「疑問と回答」という形式を用いて、 固有IDや「固有IDのシンプル・シナリオ」に関して議論を展開します。 読者から送られてきた フィードバックは、こちらに反映する予定です。 送られてきたものが直接掲載されるわけではなく、 フィードバックの意図を結城がくみとって独自のテキストとして書きます。 ですから、このQ&Aは読者と結城の本当のやりとりではありません。 すべて結城の作文ということになります。
私は、 個人的な興味でこの問題の解説をしていますが、 固有IDの専門家ではありません。 もしも技術的な誤りやご意見がありましたら、 フィードバックをお願いいたします。
また、私は、 特定の技術や製品に関して「推進したい」あるいは「推進を反対したい」と思っているわけではありません。 私は、多くの人が勘違いしそうなややこしい話を解きほぐすのが好きなだけなのです。
前置きが長くなりました、 それではさっそく「固有IDのシンプル・シナリオ」をお読みください。
265159358というIDのついたアイテムを持って、場所(A)にいます。
265159358というIDを読み取ります。
265159358というIDを、ボブに送ります。
265159358というIDのついたアイテムを持って、場所(B)にいます。
265159358というIDを読み取ります。
265159358というIDを、ボブに送ります。
以上のプロセスを通して、 ボブが知りえたことは次の通りです。
265159358は、時刻(B)に場所(B)で読み取ったID:265159358に等しい。
以上が「固有IDのシンプル・シナリオ」です。
前述した「固有IDのシンプル・シナリオ」は、特定の技術に依存せず、 善悪の区別や違法性の有無について判断できないような形式で書きました。
それでは今度は「固有IDのシンプル・シナリオ」にもう少し肉付けをして、 状況を具体的に書いてみましょう。対応関係がわかりやすいように、以下の表を併記します。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | |
| ボブ | |
| アイテム | |
| ID | |
| 時刻(A) | |
| 場所(A) | |
| ID読取機(A) | |
| 時刻(B) | |
| 場所(B) | |
| ID読取機(B) |
シンプル・シナリオの適用
アリスは、○○デパートのメンバーズカードを持っています。買い物のときにこのカードを提示すると割引になるのです。
土曜日、アリスは、○○デパート新宿店でスカーフを買いました。アリスはメンバーズカードをレジで提示し、レジ係はカードをスキャナに通しました。
日曜日、アリスは、○○デパート銀座店で靴を買いました。アリスはメンバーズカードをレジで提示し、レジ係はカードをスキャナに通しました。
メンバーズカードにはIDがふられており、 ○○デパート側は「土曜日に新宿店でスカーフを買った人と、日曜日に銀座店で靴を買った人が同じ顧客である可能性が高い」という情報を手に入れました。
検討
この適用例では、○○デパートがボブに相当します。 アイテムはメンバーズカード、IDはカードの番号です。 ID読取機はスキャナになります。
この適用例では、IDの読み取りはアリスの了解のもとで行われています。
ボブ（○○デパート）は、 「土曜日に新宿店でスカーフを買った人」が「日曜日に銀座店で靴を買った人」と同じらしいということまでは、 顧客データベースを調べなくてもわかります。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | ○○デパートの顧客 |
| ボブ | ○○デパート |
| アイテム | メンバーズカード |
| ID | カードの番号 |
| 時刻(A) | 土曜日 |
| 場所(A) | ○○デパート新宿店 |
| ID読取機(A) | 新宿店レジのカードスキャナ |
| 時刻(B) | 日曜日 |
| 場所(B) | ○○デパート銀座店 |
| ID読取機(B) | 銀座店レジのカードスキャナ |
シナリオの適用
アリスがはいている靴には、 小さなチップが取り付けられているとします。 そして、そのチップに対応したID読取機は、 そばにあるチップのIDを自動的に読み取ることができるとします。 さらに、ID読取機が各駅の改札口に設置されていると仮定します。
土曜日の10:23に、アリスは渋谷駅のハチ公口の改札を通過しました。 改札口のID読取機(A)は、アリスが履いている靴のIDを自動的に読み取りました。
同じ土曜日の10:51に、アリスは新宿駅の南口の改札を通過しました。 改札口のID読取機(B)は、アリスが履いている靴のIDを自動的に読み取りました。
ここで、ボブがID読取機(A)とID読取機(B)の情報を入手できると仮定すると、 ボブは「土曜日の10:23に渋谷駅のハチ公口の改札を通過した人」と「土曜日の10:51に新宿駅の南口の改札を通過した人」が 同じ人である可能性が高い、という情報を手に入れることができます。
検討
この適用例では、さきほどのメンバーズカードの場合と異なり、 IDの読み取りはアリスの知らないところで行われています。
ただし、もしもアリスが「自分の履いている靴にはチップが取り付けられている」ということを知っており、 さらに「各駅の改札口にはID読取機が設置されている」ということも知っていれば、 自分の靴のIDが二つの駅で読み取られるだろう、ということは予測することができます。
靴に取り付けられているチップのIDから、 そのIDの持ち主がアリスである、ということはわからないかもしれません。 しかし、少なくとも 「土曜日の10:23に渋谷駅のハチ公口の改札を通過した人」と「土曜日の10:51に新宿駅の南口の改札を通過した人」が 同じ人である可能性が高い、ということはわかります（たとえ、それがアリスであるとわからなくても）。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | チップのついた靴を履いている人 |
| ボブ | ID読取機の情報を入手できる人 |
| アイテム | 靴についたチップ |
| ID | 靴のID |
| 時刻(A) | 土曜日の10:23 |
| 場所(A) | 渋谷駅ハチ公口の改札 |
| ID読取機(A) | 渋谷駅ハチ公口のID読取機 |
| 時刻(B) | 土曜日の10:51 |
| 場所(B) | 新宿駅の南口の改札 |
| ID読取機(B) | 新宿駅南口のID読取機 |
シナリオの適用
ボブは、チップのID読取機をコンピュータにつないで、いつも持ち歩いています。 駅構内、電車の中、デパートの中…、 ボブのID読取機は、読み取りできる圏内にあるチップのIDをすべて読み取っていきます。 それらのIDが何を意味しているか、ボブにはわかりませんが、 どのIDがいつどこの場所で読み取ったものかは、 ボブのID読取機が、カバンの中のコンピュータに自動的に保存していきます。
ボブは、保存されていくIDの量を見て、 世の中にはずいぶんたくさんのチップがあるんだなあ、と思いました。
さてボブは、いま読み取ったIDが過去に読み取ったことのあるIDに一致したならば、 音楽が流れ、ディスプレイに場所と日時が表示されるようなプログラムを作りました。
あるとき、ボブが電車に乗っているとき、電車に若い女性が一人乗ってきました。 ボブはその人が誰か知りません。 でも、コンピュータは音楽を鳴らし始めました。 ボブは何だろうと思い、カバンの中のコンピュータを見ました。
すると、ディスプレイには、
「20XX年8月XX日11時04分に、新宿のアダルトビデオ店○○で読み取ったID:265159358に一致」
と表示されていました。
ボブは、いま電車に乗り込んできた女性が誰かは知りません。 でも、この女性が 「20XX年8月XX日11時04分に、 新宿のアダルトビデオ店○○に存在したアイテム」 を持っている可能性が高い、とボブは知ることができました。
検討
この適用例でも、 IDの読み取りはアリスの知らないところで行われています。 この例では、アリスが自分の持っている何かのIDが読み取られるだろうということを予測するのは困難です。
ボブは、自分が読み取ったIDが、何の製品のIDであるかを知りません。 しかし「20XX年8月XX日11時04分に、新宿のアダルトビデオ店○○にあったアイテム」を、 現在自分の目の前に立っている女性が持っているということはボブは知りえます。
注意：これは必ずしもアリスがアダルトビデオを購入しているとは限りません。 ボブがアダルトビデオ店に入ったときにボブとすれ違った男性がアリスの夫で、 アリスの夫のポケットにあった指輪のIDをボブがスキャンし、 アリスはその指輪をしていただけかもしれません。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | 電車に乗り込んできた女性 |
| ボブ | ID読取機を持って町を歩き回っている人 |
| アイテム | 不明（アダルトビデオ店に存在した何か） |
| ID | 265159358（アイテムにふられているID） |
| 時刻(A) | 20XX年8月XX日11時04分 |
| 場所(A) | 新宿のアダルトビデオ店 |
| ID読取機(A) | ボブが持っていたID読取機 |
| 時刻(B) | 現在 |
| 場所(B) | 電車の中 |
| ID読取機(B) | ボブが持っていたID読取機 |
補足
なお、現在(2003年)の技術ではこの例に示すようなID読取機の実現は困難である、 という指摘を森山さんからいただきました。 ご指摘ありがとうございます。
補足
なお、現在(2009年)、Bluetoothによって、この例に示していることは実現可能になった模様です。 以下の記事では、Bluetoothで山手線の乗客の乗降パターンが追跡されています。
シナリオの適用
マリネラ王国（仮名）は気候が温暖なリゾート地ですが、ダイアモンドの産地でも有名です。
アリスはマリネラ王国で観光を楽しみ、いま日本に帰国しようとマリネラ国際空港にいます。 いま、アリスのバッグにボブがそっと近づき、角砂糖ほどの小さな箱をバッグに滑り込ませました。 その小さな箱の中には、ボブがマリネラ王国で盗んだダイアモンドと、ボブが固有ID(265159358)を割り当てたチップが入っています。 アリスは日本に（小さな箱と共に）帰国します。 ボブはマリネラ王国に残ったままです。
ボブは、日本の成田空港で待機しているボブの仲間たち（ボビー1, ボビー2, ボビー3, ...）に電話をかけ、 固有ID(265159358)を伝えます。
ボビーたちは、固有ID:265159358を検出したらランプが光るように細工したID読取機を手に持って 空港で待機します。
アリスが成田に着きました。 ボビー3のID読取機が反応を示したので、ボビー3はアリスを尾行します。
人気のないところでボビー3はアリスのバッグを盗んで逃げます。
これで、ボブとボビーたちは一般の観光客アリスを利用してマリネラ王国のダイアモンドを密輸入できたことになります。
検討
この適用例では、IDの読み取りが行われたことだけではなく、固有IDを備えたアイテムを自分が所有していることもアリスは知りません。 アリスの知らないところで、アリスは密輸ダイアモンドの運び屋をさせられたことになります。 たとえアリスのバッグの中の箱が税関で発見されたとしても、アリスとボブたちには何の関係もありませんので、 ボブたちを突き止めることは困難です。
ここで使われている固有IDは、何かの製品IDである必要はありませんし、どこに届出をする必要もありません。 単なるランダムなビット列でかまいません。大切なのは、ボブが割り当てたIDと、 ボビーたちが見張っているIDとが一致することだけです。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | マリネラ王国から日本に帰ってきた女性 |
| ボブ | マリネラ王国からダイヤを密輸しようとしている一味 |
| アイテム | ダイヤモンドの入った箱 |
| ID | 265159358（ダイアモンドと一緒に箱に入れられたチップのID） |
| 時刻(A) | アリスの出発前 |
| 場所(A) | マリネラ国際空港 |
| ID読取機(A) | ボブが持っていたID読取機 |
| 時刻(B) | 現在 |
| 場所(B) | 成田空港 |
| ID読取機(B) | ボビー3が持っていたID読取機 |
補足
なお、現在(2003年)の技術ではこの例に示すようなID読取機の実現は困難である、 という指摘を森山さんからいただきました。 ご指摘ありがとうございます。
シナリオの適用
アリスは、介護施設で暮らしている老人です。 アリスは普段はとても温和で、 同じ施設で暮らす老人に編み物の指導をしたりする知的な女性なのですが、 不定期に徘徊するという病を持っています。
徘徊する状態のとき、 アリスは介護施設から抜け出し、行方不明になります。 あるときは高速道路の入り口付近をふらふらしているところを保護されました。 アリスが介護施設の外に出ることは非常に危険です。
ボブは、アリスの孫です。 ボブは、おばあちゃんが大好きで、 何とかアリスが安全に施設で暮らせるようにしたいと思いました。 アリスを一室に閉じ込めておくなんてことはしたくありません。 でも、一日24時間つきっきりでボブがアリスを見張っているわけにはいきません。
そこでボブは固有IDをもったチップをアリスの指輪にそっと仕込み、 また、介護施設にお願いして、施設の出入り口すべてにID読取機を設置しました。
このボブの配慮により、 アリスは普段まったく制約を受けずに施設の中で暮らすことができました。
ある日の真夜中、アリスが介護施設の裏門から外に出ようとしたところ、 ID読取機がアリスの指輪の固有IDを読み取り、警報を鳴らしました。 介護施設のスタッフがいそいで裏門にかけつけ、アリスを保護することができました。
固有IDがアリスの命を救ったのです。
検討
この適用例では、IDの読み取りが行われたことだけではなく、固有IDを備えたアイテムを自分が所有していることもアリスは知りません。 アリスの知らないところで、アリスは施設外に出ていないかどうか監視されていたことになります。 しかし、その監視がアリスの命を守ったのです。
この例では、アリス一人だけを考えました。 しかし、老人が何百人いても、それぞれが固有IDをもったアイテムを持っていれば、 それぞれの老人が移動できる区域を定めることが可能でしょう。 いわば「人にやさしい、やわらかい管理」が固有IDを使って実現できるのです。
ここで使われている固有IDは、単なるランダムなビット列でかまいません。 大切なのは、老人に固有のIDが割り当てられることと、そのIDが移動できる区域がシステムに把握されていることだけです （この場合にはデータベースが必要になりますので、厳密にいえば「固有IDのシンプル・シナリオ」の例ではなくなります）。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | ときどき行方不明になる老人 |
| ボブ | アリスの孫 |
| アイテム | アリスの指輪（につけられたチップ） |
| ID | 265159358（アリスの指輪につけられたチップのID） |
| 時刻(A) | アリスの指輪にチップをつけるとき（それより前でもよい） |
| 場所(A) | どこでもよい |
| ID読取機(A) | ボブが持っていたID読取機 |
| 時刻(B) | ある日の真夜中 |
| 場所(B) | 介護施設の裏門 |
| ID読取機(B) | 介護施設の裏門に取り付けられていたID読取機 |
シナリオの適用
アリスは3才の女の子。まだうまくしゃべれないんだけど、好奇心は旺盛。 面白いものを見つけるとそっちに走っていってしまいます。 ある日、アリスはお父さんと一緒に、 最近できた遊園地「ボブ・ランド」に出かけました。 入り口で、スタッフのお姉さんが アリスとお父さんの胸にバッジをつけてくれました。 お姉さんは「このバッジは迷子防止なんですよ」とにっこりして教えてくれました。
ボブ・ランドの中で、 お父さんが目を離した一瞬の隙に、 アリスは人ごみのほうへ駆け出していってしまいました。 あわてたお父さんが人ごみをかきわけていきましたが、 もうアリスの姿は見えません。 アリスは迷子になってしまいました。
困ったお父さんはボブ・ランドの迷子センターへ行き、状況を話しました。 迷子センターの係員はお父さんの胸のバッジに機械のアンテナを向けました。 10分後、迷子センターの地図上でランプが光り、アリスの場所がわかりました。
お父さんとアリスのバッジはペアになっていて、 同じ固有ID(265159358)が記録されています。 お父さんが迷子センターにいって固有IDを読み取ってもらえば、 ボブ・ランド内の要所要所に取り付けれらたID読取機が、 同じ固有IDをウォッチし続けてくれます。 迷子のアリスがボブ・ランドのID読取機のそばを通りかかると、 バッジの固有IDが読み取られ、その場所がわかるのです。
検討
ここでは固有IDが迷子探しに一役買っています。
ボブ・ランドのスタッフのお姉さんも、迷子センターの係員も、 アリスやお父さんの個人情報は知る必要がありません。 ただ、固有IDが一致するという事実を使って目的の迷子をさがすことができるのです。
固有IDを持ったバッジというアイテムをユーザに持たせることで、 個人をトラッキングし、 子供が迷子になるのを防ぐことができるのです。
この例では、お父さんが迷子センターに行きましたが、 先にアリスが保護されることもありえます。 その場合、アリスが自分の名前やお父さんの名前を言うことができなくても、 アリスのバッジと同じ固有IDを持ったお父さんの場所を探すことができることになります。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | 好奇心旺盛な3才の女の子 |
| ボブ | 遊園地 |
| アイテム | アリスと父親のバッジ（につけられたチップ） |
| ID | 265159358（バッジにつけられたチップのID） |
| 時刻(A) | バッジをつけるとき（それより前でもよいし、お父さんが迷子センターにいったときと考えてもよい） |
| 場所(A) | どこでもよい |
| ID読取機(A) | 特に特定する必要はないが、バッジを用意する人が使ったID読取機 |
| 時刻(B) | アリスがID読取機のそばを通りかかったとき |
| 場所(B) | 遊園地内のどこか |
| ID読取機(B) | 遊園地のどこかに取り付けられていたID読取機 |
シナリオの適用
携帯電話は、電源が入っている限り自分の位置をキャリアの無線基地局に連絡し続けています。 携帯電話は個人が持っているものですから、 アリスを携帯電話のユーザとし、IDを端末の番号、ID読取機は無線基地局、そしてボブは携帯電話会社（キャリア）だとすると、 携帯電話を持ちながら動いている状態というのは、 「固有IDのシンプル・シナリオ」に一致します。
検討
アリスは、携帯電話のサービスを自分が受けるために、 「自分」がいまどこにいるかという情報をボブに送っていることになります。 実際に送られている情報は携帯電話の端末番号なのですが、 そこで追跡してもらっているのは「携帯電話を持っている自分」ということになります。
アリスは、携帯電話会社に自分を追跡してもらい、 サービスを受けていることになります。 きちんと追跡してもらえないと「この携帯電話は切れやすい」という苦情を会社に言うことでしょう。 携帯電話会社は、顧客に満足のいくサービスを提供するために基地局（ID読取機）を増設します。 携帯電話会社から自分の携帯電話を追跡されるのを好まない人は、 携帯電話は使わないほうがよいでしょう。
| 「固有IDのシンプル・シナリオ」適用表 | |
|---|---|
| アリス | 携帯電話のユーザ |
| ボブ | 携帯電話会社（キャリア） |
| アイテム | 携帯電話 |
| ID | 携帯電話の端末番号 |
| 時刻(A) | いつと考えてもよいが、たとえば携帯電話の製造時 |
| 場所(A) | どこでもよい |
| ID読取機(A) | 特に特定する必要はないが、携帯電話会社が把握しているID読取機 |
| 時刻(B) | 携帯電話の電源を入れている間中 |
| 場所(B) | どこでもよい |
| ID読取機(B) | 携帯電話会社の基地局 |
「固有ID」および「固有IDのシンプル・シナリオ」に関連する話題をQ＆A形式で整理しました。 読みやすいように議論を単純化してありますが、 技術的に誤った記述はしないように心がけたつもりです。 もしも技術的に誤っている記述がありましたら、 ご指摘ください。
疑問
あなたは「固有IDのシンプル・シナリオ」で、何を言いたいのですか？
回答
「固有IDのシンプル・シナリオ」で言いたいのは、 固有IDを使うと、個人を追跡できる場合がある ということです。 そして、その際に、
ということを明確にしたいと思いました。
固有IDに個人情報が盛り込まれていなくても、 固有IDが暗号化されていても、 データベースがそもそも存在しなくても、 固有IDを使って個人を追跡できる可能性がある、ということです。
「個人の追跡」自体は良くも悪くもありません。 良く使えば便利なサービスを生み出しますが、悪く使えば危険です。
疑問
適用例1のメンバーズカードってよくある話ですよね。 これって何か問題なんですか？
回答
いや、利用者がメンバーズカードを提示することの意味をよく理解していれば、 大きな問題は起きないと思います。 この例を一番最初に示したのは「固有IDのシンプル・シナリオ」の流れを読者に理解してもらうためです。 メンバーズカードを提示する、というのは日常よくやることですから、 情報をボブに渡す、という感覚がよく理解できると思いました。
また、メンバーズカードの場合にはカードを出すかどうかをユーザが自分の意志で選べますね。 そのことから、他の適用例との違いがはっきりすると思い、この例を示したのです。
疑問
もしも、IDに個人情報を盛り込む容量がなかったら、 そもそもプライバシーの問題は発生しないのではありませんか？
回答
いいえ。
IDに個人情報が盛り込まれているかどうかは無関係です。 「固有IDのシンプル・シナリオ」では、 IDに個人情報が盛り込まれているかどうかではなく、 IDが固定（固有ID）かどうかが重要なのです。
「固有IDのシンプル・シナリオ」では、IDに個人情報は盛り込まれていません。 しかし、「固有IDのシンプル・シナリオ」に描いたように、 「(A)にいた個人と(B)にいた個人が同じ人間である可能性は高い」 という情報を他の人が入手することは可能です。
そして、そのような情報が非常に多数集まれば、 結果的に特定の個人を追跡することも可能になると思います。
ここは一般の人に非常に誤解されるポイントではないかと思います。 「IDを見ても個人は特定できないから問題はない」や「IDには個人情報は盛り込まれていないから問題はない」 というのは話を単純化しすぎており、一般の人をミスリードする主張だと思います。
繰り返しますが「個人の追跡」自体は良くも悪くもありません。 良く使えば便利なサービスを生み出しますが、悪く使えば危険です。
疑問
固有IDを使うのが問題なら、ID読取機が読み取るのは、 IDを暗号化した結果だけにすればいいと思います。
回答
いいえ。話はそう単純ではありません。
「固有IDのシンプル・シナリオ」で、 ID読取機が読み取るのはIDを暗号化した結果だけだとしましょう。 そうすれば、ボブの手に渡るのはアイテムのIDそのものではなく、 「暗号文」（IDを暗号化した結果のビット列）ということになります。
ところで、同じアイテムを二つの読み取り機にかけた場合、 ID読取機(A)がボブに送ってくる「暗号文」と、 ID読取機(B)がボブに送ってくる「暗号文」は同じでしょうか。
もしも同じものならば「固有IDのシンプル・シナリオ」で描いた状況はまったく変化していません。 ボブは(A)と(B)から送られてくる2つの「暗号文」を見て、同じアイテムかどうかを判断できるからです。 ここで、暗号文を復号化、もしくは解読する必要はない、というのがポイントです。 暗号文のままで、(A)と(B)にあるアイテムの同一性を推測することが可能です。
もしも、(A)と(B)が送る「暗号文」が異なるものだとしましょう。 この場合には、 その暗号文を復号化して、暗号前のIDを得ることができる人だけが、 (A)と(B)にあるアイテムの同一性を判断できることになります。
さらに、 適用例4の場合ですと、 そもそもボブ（とボビー）に固有IDを知られることが問題なのですから、 この場合には暗号化は意味を持ちません。
「IDを暗号化すれば大丈夫」 というのは話を単純化しすぎており、一般の人をミスリードする主張だと思います。
「IDを暗号化すれば大丈夫」と述べるだけではなく、 暗号化された結果は固有IDと一対一に対応する固定的な値になるのかどうか、 固定的な値にならないとしても、暗号化された結果から固定的な値を知りえるのは誰か、 を明確にする必要があると思います。 途中の経路を暗号化した場合であっても、 もともとのアイテムに付与されたIDと一対一の関係にある値を知りえる人は、 「固有IDのシンプル・シナリオ」のボブに相当することになるからです。
（メモ：ここで生成される暗号文は、単に「毎回異なる」だけではだめで、予測不可能性を持つ必要がある。「暗号文」同士の同一性を推測されてはいけない）
（メモ：また、何を何のためにどう暗号化するのかをきちんと述べないと無意味。「暗号化する」という表現だけでは何の評価もできない）
疑問
固有IDが使われていても、 個人情報を守っているデータベースを 強固なセキュリティシステムで守っていれば大丈夫だと思います。 固有IDを誰かに読み取られたとしても、 個人情報が読み取られたわけではないですからね。
回答
いいえ。
データベースがどんなセキュリティシステムで守られているかどうかは、 「固有IDのシンプル・シナリオ」には無関係です。
そもそも、個人情報が含まれているデータベースが存在しなくてもかまいません。 「固有IDのシンプル・シナリオ」の図にはデータベースは登場しないことを思い出してください。
「固有IDのシンプル・シナリオ」では、 固有IDがたとえ単なるランダムな数であったとしても、 それがアイテム固有のIDである限り、 ボブは(A)と(B)のアイテムの同一性を知ることができます。
「データベースを強固に守れば大丈夫」 というのは話を単純化しすぎており、 一般の人をミスリードする主張だと思います。
疑問
すでに個人IDとしてクレジットカードが普及しているのだから、 いまさら固有IDが増えたところでトラブルは増えないと思います。
回答
クレジットカードと固有IDは区別して考えたほうがよいと思います。 なぜなら、クレジットカードと固有IDの間には次のような大きな相違点があるからです。
1. クレジットカードを持つ・持たない、クレジットカードを今回の買い物で使う・使わないの選択は 利用者が行えるが、固有IDの場合には、利用者にその選択の自由がない可能性がある。
2. クレジットカード番号は本人が提示しなければ読み取れないが、 固有IDは本人が知らないうちに読み取られる可能性がある。
疑問
経済を立て直すための重要な技術を感情的な議論で台無しにするのはまずいのではありませんか？
回答
メリットとデメリットがバランスよく提示されていれば、 あまり感情的な議論にはならないと思います。
このページはできるだけ感情的な議論をあおらないように書いているつもりですが、 もし「ここは感情的である」という部分がありましたら、 ぜひ教えてください。
疑問
固有IDといっても、従来のバーコードの延長上にあると思いますので、 新たなトラブルを生むとは考えにくいです。 違いますか？
回答
バーコードは商品の種類ごとにつけられています。 一方、固有IDは商品の1つ1つに異なるIDがつけられています。 商品につけられる固有IDは、 その名(identifier; 識別子)の通り、 個々の商品を識別するためにつけられるのです。 ですから、種類識別のためのバーコードとは性質が大きく異なります。
疑問
固有IDを使うと、確かに2つの場所にいた個人（アイテム）が同一であるということは知りえるかもしれません。 でも、それだけのことを「個人の追跡」というのは大げさではないでしょうか。 だって、2地点の途中をずっと追いかけているわけではないでしょう？
回答
個人の追跡(tracking)というのは、 個人をずっと追いかけていくという意味ではなく、 ある個人が、ある時点に、ある地点にいた、ということを知りえるかどうかという意味です。
「固有IDのシンプル・シナリオ」では、 話をシンプルにするために2地点だけにしましたが、 これはID読取機の数に応じて何箇所にでも拡張できます。 また、たとえID読取機が1個でも、 特定の場所に繰り返し訪れる個人の同一性を認識することは可能になります。
また、 適用例2のような場合、ある個人が「渋谷から新宿に移動していった」ということは推測可能になります。
適用例4のような場合、たった2地点(マリネラ国際空港と成田空港)でのID読み取りしか行っていませんが、 個人が追跡できていることがよくわかると思います。
また「場所(A)」がたとえば「犯罪が行われた場所」だったりすると、 たとえ地点の数が少なくても重大な意味を持つ可能性があります。
個人の追跡は悪いことだけではありません。 適用例5では、徘徊老人の安全を確保するため「個人の追跡」をしています。
疑問
固有IDで、プライバシーに多少問題を引き起こしたとしても、 利便性がそれを上回っていたらよいのではありませんか？
回答
その通りです。
ただし、そのためには、 メリットとデメリットが十分に研究・提示される必要があると思います。 特に固有IDを広めることで利益を受ける企業や団体は、 リスクに関する情報をきちんと提示することが重要である、と思います。
一般の人に、 わかりやすく利便性とリスクを提示することは非常に重要です。
また、メリットとデメリットをユーザがよく理解した上で、 一般ユーザが選択できる自由が用意されていることが大切ではないか、と思います。
疑問
固有IDに関しては、 企業の専門家がきちんと研究しているので大丈夫ではないのでしょうか？
回答
もしも、専門家がきちんとした研究をしているなら、 その結果は一般の人々にわかるように解説されている必要があると思います。
たとえば、 固有IDに関わる製品を作っている会社のWebサイトで、 固有IDの持つメリットとデメリットについて、 わかりやすく書かれているページはありますか。 もしも、よいページがあったら、URLを ぜひ教えてください。 このページからリンクしますので。
疑問
たとえば薬品に固有IDがつけられていれば、 その薬品が誤用される危険や、 使用期限を越えて使われる危険を防ぐことができる、 という話を聞いたことがあります。 それはメリットではありませんか？
回答
はい、メリットだと思います。
ただし、薬品につけられた固有IDを、 もしも他人がすりかえることができるなら、 逆に大きなデメリットになる可能性がありますね。
メリットを提示する場合には、 同じ仕組みが生み出しうるデメリットも提示したほうが 建設的な議論になると思います。
なお、この「薬品の誤用の判断」という話自体は、 このページで述べている「固有IDのシンプル・シナリオ」とは直接関係がありません。
疑問
固有IDの問題といっても、 要するに「購入時にIDを必ず壊す」という仕様にしてしまえば、 まったく問題はないと思いますが、どうですか？
回答
もしもIDを壊すことができるなら、 それは固有IDにまつわる問題をかなり軽減します。 しかし、それは万能ではありません。
なぜなら、固有IDの用途を考えると、壊せないものがあるからです。 たとえば、よく言われる例ですが「犬の首輪にIDをつけておき、迷子になったときに備える」という機能を固有IDを使って実現する場合、 購入時に壊すのは意味がありません。
また「薬品の利用可能期限を自動的に調査するためにIDをつけておき、利用直前に必ずチェックする」という用途の場合にも 「IDを壊しておく」という方法は使えません。
疑問
バイアスがかかっていないような書き方をしているが、 内容はRFIDに反対しているようにしか読めません。 メリットもたくさんあるのだから、 一般の人にわかりやすいように「固有IDのよい事例」も示してほしいです。
回答
このページでは 固有IDのシンプル・シナリオで、何を言いたいのか？に書いたような「一般の人に誤解されやすそうなポイント」を書いていますので、 RFIDに反対の論調の事例が多くなっていることは認めます。 よい事例は、RFIDの商品を展開している企業がたくさん出していますので、 個人のWebページでわざわざ書くまでもないように思いますが、 「よい事例」も出すこと自体はやぶさかではありません。 よければ 事例を送っていただけるととても助かります。
無線を使った固有IDの「よい例」として、 適用例5: 徘徊老人を書きました。
疑問
はじめに書かれている 「固有IDのシンプル・シナリオ」の部分を読んだだけでは、 固有IDが良いものなのか、悪いものなのかはっきりしません。 適用例を読んではじめて「これは問題ではない」や「こりゃこまるな」や「場合によるんじゃないの」とわかります。
はじめに書かれている 「固有IDのシンプル・シナリオ」の部分で、もっとはっきり固有IDが良いものか悪いものかを書いたほうがよいと思いますが、 どうですか？
回答
そもそも、 固有IDは良いものでも悪いものでもありません。 良い使い方も、悪い使い方も考えられます。 すべては状況と使い方に依存すると思います。
「固有IDのシンプル・シナリオ」の部分は、できるだけ、 良いものか悪いものか判断できないようなトーンで書いています。 「固有IDのシンプル・シナリオ」はいわば骨組みだけであり、 これに具体的な状況を肉付けしていくと、 しだいに「これは問題だ」「いや、問題じゃない」という判断ができるようになると考えています。 その肉付けの例として、 シンプル・シナリオ適用例を示しています。 以上の構成をご理解いただけるとありがたいです。
以下のリンク集はYukiWikiの「RFID反応リンク集」のページの2003年8月14日のスナップショットから作ったものです。 書き込んでくださった方に感謝します。
〔2018年追記〕リンク切れが多数ありますが、記録という意味で残してあります。
このページを書く上で参考にさせていただきました。 ありがとうございます。
〔2018年追記〕リンク切れが多数ありますが、記録という意味で残してあります。
あなたのご意見やご感想をお送りください。
あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。