| ホーム ＞ 結城浩の日記 ＞ 2003年8月 | 検索 | 更新情報 |
| 読者の声 | 先月 | 日記ダイジェスト |
|
さまざまな原稿を書き書き。忙しい。
NHK朝8:00〜8:10の「にほんごであそぼ」は我が家での人気番組の1つである。
あそこに登場する歌の秘密を探った（おおげさ）のでご紹介。
「♪たけのこ、芽え出した」の歌。 あれはジャンケンですよね。
「♪はやしの中から、おばけが…」の歌。 あれもジャンケンですよね（これはうちの長男の意見）。
え、当たり前だろうって？
すみませーん。気がついたときにはすごく大発見だったような気がしたもので。
失礼しました〜(^_^;
[CR] 今日は拙著『暗号技術入門 —— 秘密の国のアリス』の2度目の読み合わせ（再校の読み合わせ）でした。 家を出かける前、私は「おーいみんなー。祈ってー」と家族を招集する。 食卓の上に再校用紙を置き、家族みんながその上に手を置く。 家内が、私のこと・編集長のこと・この本に関わるすべての人のことをイエスさまにお祈りする。 みんなで「アーメン」と唱和する。 家族で祈れる喜びを神さまに感謝。
前回の読み合わせの話にはけっこう反響メールがあったので、今回も少し詳しく書いてみましょう。 前回の読み合わせは約3時間半でしたが、今回は短くすんで約2時間半でした。 いつもと同じく編集長と1ページ1ページめくりながら疑問点の解消などを徹底的に行います。 最後には二人とも疲れ切っておりました。 でも、いくら疲れても手は抜きません…というか、二人とも手を抜かないのでいつの間にかくたびれているというほうが真実に近いので、あまり自慢はできない。 それから「一生懸命やったからといってよい本になるとは限らないが、でも一生懸命やらないとよい本にはならない」ということにも注意。
ともあれ、地道に愚直に編集作業は進むのです。 おじさん二人が原稿はさんで2時間半。 ちなみに、机をはさんで向かい合わせではありません。大きな机に二人が並びます。私が右、編集長が左。 この体勢がいちばん読み合わせには楽。向かい合わせだと原稿が互いにさかさまになるから。
編集長「ここは「の」を入れたほうがよろしい？」
結城「あ、そうですね。入れてください。そこはどうするつもり？」
編集長「ここは前に出てきているので欧文をトルで」
結城「いえ、これはこっちとの対比で出しているので、トルは困ります。」
編集長「なるほど。ではこのままで。前回確認したんですがｆはどちらで。立体で？」
結城「いえ、数学のフォントで全体をあわせます。」
編集長「はい。ここは「最後」または「最終ラウンド」と入れますか。」
結城「本文が「最終ラウンド」ならそれに合わせて。この参照ページはDiffie-Hellman鍵交換ですか。」
編集長「そのはずです。違ったら困ります。確認してみましょうか…そうなっていますね。」
結城「はい、OKです。」
編集長「このソルトは外か中かという…」
結城「あ、それはもう直してあります。中です。」
編集長「はい、はい。ではその通りに。こちらの参照ページがわからなかったのですが。」
結城「あ、それは直しました。参照ページはトルで。」
編集長「ここに「ある」を入れてもよい？ 「ある一方向ハッシュ関数…」とします。」
結城「…はい、そうしてください。いいですね。「ある…それ…」の対応ですね。」
編集長「この『少なくても512ビット以上』は「以上」は不要？」
結城「う。確かに。不要です」
編集長「ここは平文ブロック１でよろしい？」
結城「ええと、図はどうなっていますか。…はい、はい。それでよいです。」
…というような感じ。 初校の時よりも個数は少なめ（朱の個数は数百箇所くらいだろうか）だけれど、 その分だけチェックポイントが細かくなっているので、 手間はあまり変わらない。
ちょうど索引の初校も出ていたので、さくさくとチェック。 索引項目がちゃんと対応するページにあるかどうかは編集部のほうですべてチェックしてくれるので、 私は項目を読み直して適切な項目が出ているかをチェック。
校正は、 紙やすりの目を少しずつ細かくして、磨きをかけているのとよく似ている。
読み合わせが終わったあと、疲れきった編集長と二人で、よろよろと夕食を食べて情報交換。 編集長から、 最近アマゾンで「暗号」を検索すると『暗号技術入門 —— 秘密の国のアリス』が1位に来る、 という話を聞いて喜ぶ。
編集長「そういえば、この暗号本は本当にプログラミングの本ではないんですね。 結城さんの本でプログラミング以外というのは初めてですね」
結城「そうですね。もちろんプログラマが読んでも面白いと思いますけれど、プログラミングに興味のない人でも面白く読めるんじゃないでしょうか。暗号技術の仕組みに知的な興味を持っている読者なら楽しめると思います」
編集長「いまさらながら変な話ですが、再校になってさらにじっくり読み込むと、この本は非常に面白いですね」
結城「（笑って喜ぶ）そうですよね。私も自分が書いていて言うのは何ですが、非常に面白いです。どんなところに面白さを感じましたか」
編集長「なんというか…人類はここまで到達したのか、という感じでしょうか。はじめのほうのシーザー暗号や単一換字暗号、それにエニグマの話、対称暗号なども面白いですが、やっぱり白眉は公開鍵暗号ですね。この仕組みが結城さんのわかりやすい文章で説明されると、うなってしまう面白さがあります」
結城「説明の流れ自体はオーソドックスなんですが、噛み砕いて説明されると「なるほど！」と思いますよね。RSAなどは本当にシンプルですし。私自身も驚きました」
編集長「もちろん高度な数学なんですが、文章を読んでいるときにはそのことをあまり意識しない。せいぜいちょっとした算数？くらいのイメージですね。たとえ話も、よいです。厳密にいえば違う点はありますけれど、話を理解する上でとても効いている」
結城「ですよね（にっこり）」
編集長「認証の話もトントンッと読み進められました。デジタル署名と証明書で、「信用」というものの意味を考えさせられますね」
結城「私も考えちゃいました。信用がどういう風に生み出され…厳密には生み出されていないんですけれど、何をどういう風に信用するかというのが、技術を背景に浮かび上がってきますね」
編集長「ずっと説明してきた暗号と認証の話が、PGPの章で総合的にまとめられるところもいいし、それからweb of trustも」
結城「あの解説文はおそらく一番わかりやすいweb of trustの解説だと思いますよ。私、たくさんの本を読みましたけれど、すっと理解できたものはありませんでした。自分であの説明文を書いてやっと理解しました」
編集長「あっ、そうなんですか。私は結城さんの文章しか読んでいないので、すっと理解しちゃいましたが。 シュナイアーの『暗号技術大全』もバイブル的な本としてかなり人気がありますが、 結城さんの『暗号技術入門 —— 秘密の国のアリス』も読者に喜んでもらえると思いますよ」
結城「だといいですね。 『暗号技術大全』は翻訳チームもすごいですが、 最後にまとめた山形さんも素晴らしいです。 監訳でありがちなごつごつ感がないです。 もちろん最後に編集作業をなさった編集さんも大変でしたでしょうけれど」
編集長「分量も分量ですが、内容も難しいですからね。 他の本といえば、サイモン・シンの 『暗号解読』にはドラマがありましたが、結城さんの暗号本にもドラマというかストーリーがありますね」
結城「そうですね。『暗号解読』の人間ドラマはとても面白かった。 青木さんの翻訳で読めたのは幸せなことです。 私の本には人間のドラマは少ないですけれど、暗号の仕組みを追うだけでも十分ドラマになりますね」
編集長「結城さんの暗号本は、各章がばらばらではなく、ずっとつながっていくストーリーがあって、最後まで思わず読んでしまうような。あれは、結城さん自身が何かを見つけつつ、発見のプロセスを書いているからでしょうか」
結城「そういうところはありますね。 本を書きながら自分が順次発見していったこと（といっても、私にとっての発見なのですが）をその都度まとめていき、最後に最終章でしめる、という形になっていますね。書いていてわくわくしましたし、校正で読みながらもすごく楽しかった」
編集長「なんだかんだいって一年ほどかかりましたね」
結城「かかりましたね。申し訳ありません」
編集長「いえいえ、大丈夫です。売る側のほうも結城さんの本ということで期待して待っていますよ。私のほうからもたくさん宣伝をしておきます」
結城「よろしくお願いします。私のほうはよい本を書けて楽しいのですけれど、必要としている読者にこの本がきちんと届くのは、出版社の営業・販売のかたのおかげだと思っています。どうぞよろしくお伝えください。いつも感謝しています」
結城さん、
先日結城さんにご挨拶のメールをさしあげた者です。 結城さんの日記に行ったら、 メールと結城さんのお返事が掲載されていて、びっくりしました。 公開していただいても結構です。:-) 私のように八方塞で困っていた初心者が、 ここの個所を読んで結城さんの本を買いに行ったら素敵ですね…。:-)
私のためにお祈りしてくださり、ありがとうございました。 誰かに祈っていただいたなんて初めてで、とても感動しました。 結城さんが祈ってくださったような、 「神様に用いられて、周りにたくさんのはげましと愛を与えられる」 ような者に変えられたら、と本当に願っています。 聖書を読み始めたばかりのまだ何もかもつたない者ではありますが、 結城さんのお仕事がいつも祝福され、 元気をなくしているプログラミング挑戦者が結城さんの本を通してこれからも励まされることを、 お祈りしております。
結城さんの本の一読者より
結城です。応援とお祈りを本当にありがとうございます。
とってもうれしいです *^_^*
神さまには神さまのご計画がありますけれど、
神さまの御心にかなう願いは、信じて願えばかならずかなうと私は確信しています。
たとえ自分の思う通りにはならなくても、神さまがご介入なさるとき、
そこには最善の道が備えられていますから安心です。
プログラミングを学ぶ人は、人間関係の経験が浅い若い人が多く、また過酷な環境で仕事をしている方も多く、 さまざまな矛盾や無理難題をかかえつつ仕事をしている方がたくさんいらっしゃると思っています。 仕事が忙しいだけではなく、その忙しい中で新しいことを次々に学んでいかなければなりませんし。
厳しい納期や、頻繁な仕様変更、進捗会議での苦しい報告（進捗会議の前夜「明日がゆううつ」というメールを私はたくさんの方からいただきます）、 貧弱なマシン環境、同僚やクライアントとのコミュニケーションギャップ（ねたみや不満、失望と不信、それにそもそもうまく話が伝わらない苦労）、 現在の仕事がうまく収束するのかという不安、いまの仕事をいつまで続けていられるのかという不安……。 そういった中で心を病む人や、心傷ついている人がたくさんいらっしゃると思っています。 外からはうまく波に乗っているように見える人でも、 心の中に人知れず大きな悩みやストレスを抱えている人も多いでしょうね。
私の仕事やWebページが、 少しでもそういった人たちのお役に立てればよいとは思っているのですが。 いつも、イエスさまへの祈りが必要ですね。
ともあれ、フィードバックをありがとうございます(^_^)。
高木さんは、 2003年8月24日の日記の中で、 結城の日記に触れてくださった。ありがとうございます。
同氏の「固有IDのシンプルシナリオ」は、この問題の当事者の人の要素を排除したものなのだろう。
だが、これは本質的に「人の問題」なのだ。技術的な理屈はべつにたいした話ではない。 問題に薄々感づいていながら、問題がないことにする人、 フォーラムや学会の場ですら問題点を整理しようとしない人、「ユーザに説明すればよいこと」と言いながら、 ユーザには決して説明することをしない人。そこにこそ問題の本質がある。
学会発表ではこういう「人の問題」は書くわけにはいかないだろう。だから5月5日、このように日記という媒体を使うしかないと決意をしたのだ。
…ということで、 わたしの理解（高木さんがこの問題を「人」にフォーカスをあてて論じている点）は間違っていなかったと思いました。 つまり高木さんは 人に問題があると考え、人にフォーカスをあてて、日記の中で論じているのですね。 わたしは高木さんのこういう態度を偉いなあと思います。
高木さんにとっては、 たいした理屈ではないかもしれないけれど、 理解できない人はたくさんいらっしゃるので、 私の書いた文章は無駄ではないと思っています。 私の文章が高木さんの邪魔になっていないといいのですが。
なお、私の 加筆・修正予定のメモに対して、高木さんが 自動車登録番号追跡サービスのビジネスモデルというページでコメントをつけてくださっている。ありがとうございます （やっぱり、何でも公開しておくものだと再確認したしだい）。 高木さんは「自動車のナンバープレートの読み取りキット」という仮想的な例を出しておられた。 ふむ。なるほど。
ちょっと話はそれます。
セキュリティに関連した議論をするときには、必ずといっていいほど、 悪用・濫用されることを想定して考えなければならないと思っています。 たとえば上記の高木さんの例に対して「そんなことを考えるのはよくない」という指摘はよくない。 賢い人が真剣になって悪用を考えて考えて、 それでも悪用できない（しにくい）というのがよいシステムだからです。
暗号の世界では、暗号の強さを評価するときに、他の人の（あるいは自分の）アルゴリズムを必死で破ろうと試みます。 専門の暗号学者が必死で破ろうと試みる。そのような試みに耐えてきたアルゴリズムだけが「現在のところ強いとみなされるアルゴリズム」となるのです。 ブロック暗号DESの後継AESを選ぶときにNISTがとった方法もそうでした。 NISTがAESを選定するというよりも、暗号の専門家たちを公募して集め、互いに戦わせる。 その戦いに勝ち残ったアルゴリズムを「強いとみなす」というのです。 そこでは、暗号解読は悪ではない。強さを評価するための唯一の方法だ。
セキュリティのことを議論するときには、 「悪いことを考えてくれる良い人」を大切にしなければならない。 さもないと「悪いことを考える悪い人」が登場したときに悲惨なことが起こるからだ。
現代では、もしかしたら「自分の力で自分らしく生きよう」とするあまり、 自分を損ねたり自分を見失ったりする人が多いかもしれない、とふと思った。
「自分らしく生きる」ということを、この世の価値観から見出そうとしても難しいだろうと思う。 自分は人間だから、まず、ごまかしのない人間の姿に直面しなければならない。 人間の醜さに。自分の醜さに。 そして、そこからどうしたら救われるか、何が救いの道かを見極めないことには、 本当の意味で「自分らしく」生きることは不可能だとわたしは思っている。
神さまは、わたしたちの創り主。 創造主である神さまだけが、わたしたちが作られた本来の目的と意味を知っている。 神さまにはご計画があり、そのご計画に沿っているとき、私たちの人生はもっとも輝く。 そして本当の意味で「自分らしく」生きることができる。 それは単調な人生ではない。一人一人は同じ人間だが、異なる性格、異なる顔かたち、異なる環境で生まれたように、 そこには深い意味がある。神さまがご存知の意味が。 わたしたちは、神さまを信頼し、自分が自分の人生の目的に（神さまのご計画にしたがって）歩むことを、祈り求める必要がある。
自分勝手な判断を信じてはいけない。この世の価値観で自分を値踏みしてはいけない。 自分勝手な判断によるゆがんだ自己像を捨てる。 そして神さまを見上げて、しっかりした信仰に立って歩もう。
毎日、いろんな問題がふりそそぐ。 しかしそんなものにゆらがない人生を歩もう。 それには自分の力にたよってはいけない。 全能の主なる神さまにたよるのだ。
考えてみれば、 わたしたちは沈みつつある豪華客船の上でパーティをやっているようなものだ。 パーティの中で、あの子のドレスがきれいだとか、 あいつのヒゲはかっこわるいとか、 この飲み物はまずいとか、そういうことをやっているわけだ。 でも、なにより大事なのは「救命ボートの場所」という情報だ。 甲板の上はパーティの音楽でいっぱいだ。 でも、耳をよく済ますと、かすかに（救命ボートはこっちだ）という声が聞こえる。 そのかすかな声が聞こえないふりをして、新しい飲み物を取りに行く人もいる。 しかし、かすかな声に真剣に耳をすまし、救いの道を見出す人もいる。
何だか冷たいようだけれど、シビアな現実だ。
読者のお一人から「自分が負うべき十字架」について質問がありました。 本来はきちんと参考書で調べるべきなんですが、 以下、わたしの個人的な考えを書きます。 間違ったことを書いていたらごめんなさい。
結城です。 主の御名を賛美します。
私は「自分が負うべき十字架」というのは、 神さまが自分に与えてくださる使命のことだと思っています。 使命というと大げさになってしまいますが、 神さまが自分を生かしてくださるのには目的があります。 その目的を捜し求め、それに従うことです。
大きな能力を与えられて、大きな目的を果たす人もいます （たとえば牧師先生などは、 たくさんの人に神さまの言葉を伝え、 教会の信徒を神さまの言葉で養うという大きな目的があります）。
ある人はお金もうけが得意で、 その能力を神さまの御用に用いる場合もあるでしょう。
ある人は人をもてなすことがうまくて、 その能力を神さまの御用に用いる場合もあるでしょう。
ある人は強い信仰があって、 その能力を神さまの御用に用いる場合もあるでしょう。
ある人は賛美の能力があって、 その能力を神さまの御用に用いる場合もあるでしょう。
ある人は何もできないけれど、 ひたすら「祈りの人」として教会を支える場合もあるでしょう。 ——こういう人は目立ちませんが、非常に重要です。
ある人は教会の奉仕は何もできなくても／何もしなくても、 愛にあふれた家庭を作り出す人もいるでしょう。
神さまの働きはありとあらゆるところに及びます。 そして私たち、神さまを信じる人たちは、それぞれの能力と立場を使って 神さまの栄光を示す担い手となるのだと思っています。
私は「自分の十字架を負う」というのは、 そういう意味を持っているのだと理解しています。 他の解釈もいろいろとあると思います。 本来は、きちんと参考書にあたり釈義を調べてみるべきですね。
ルカ9:23には「イエスさまについていきたいと思うひと」はどうするかが書かれていますね。 神さまに従うときには (1)自分を捨てること (2)自分の十字架を背負うこと と書かれています。 神さまに「従う」ことの意味を考えさせられます。 「自分の十字架を背負う」ということは、 「神さまに従う」という文脈で理解する必要がありそうです。
そして、有名な次の御言葉が続きます。
自分のいのちを救おうと思う者は、それを失い、 わたし［イエスさまのこと］のために自分のいのちを失う者は、それを救うのです。 人は、たとい全世界を手に入れても、自分自身を失い、損じたら、何の得がありましょう。 （ルカ9:24, 25）
以上、何かの参考になれば。 （にっこり）
礼拝。今日は特に聖霊様が触れてくださったのか、礼拝中に涙が流れてしかたがなかった。
お昼はレストランで。 オーダーがやってくるのを待ちながら、次男に マックス・ルケードの 『そのままのきみがすき』を読んでやっていたら、 最後のほうになって涙で声が詰まり、 読み続けることができなくなった。 泣いてばっかりだ。
王様が、5人のみなし子を「自分の子供」として迎えに来る。 というので、子供たちはそれぞれに王様に気に入っていただこうと考える。 でも末っ子は何にもとりえがない。すると……
というお話。 お話は単純といえば単純なんだけれど、 とってもやさしい絵と、何度も読み返したくなる文章で、 思わず引き込まれてしまう。 人生で大切なこと、本当に大切なことっていったい何だろう、 としみじみと考える。
[CR] 『暗号技術入門 —— 秘密の国のアリス』の校正は続く。 PGPの章、SSL/TLSの章、そしてまとめの章。 うーん、おもしろい！ 自分で書いておいて自分で言うのも何ですが、 まとめの章で行っている「暗号技術の道具箱」の解説なんか、 ちょっと感動しちゃった。
暗号技術および認証技術の話って、 Webのニュースなどでよく見かけるんだけれど、 何となくもやもやっとしている部分があった。 書かれていることはだいたいわかるんだけれど、 何だかこう、スキッとしない。 書かれてることを自分の頭で再構成できない。判断できない。
でも、この『暗号技術入門 —— 秘密の国のアリス』を読んでみると、 いろんな技術とその役割が明確になり、 またそれぞれの技術の欠点（というか、その技術がカバーしていない範囲）というのが明確になるように思う。 そういえば、 レビューアさんのアンケートの中にも、 「＠ITの記事がすらすら読めるようになった」という感想を書いてくださった方がいた。 うん、まさにそんな感じですね。
本書を書くことになった背景はたくさんある。 暗号に興味を持つきっかけになったのは、 『PGP——暗号メールと電子署名』でした。1996年ごろのことだったと思います。 そして、一番お世話になったのは、なんといっても シュナイアーが書き、山形浩生さんたちが翻訳した 『暗号技術大全』ですね。 続編的な "Practical Cryptography"も大いに参考にしました。 山形さんにはメールでいろいろ相談させてもらいました。ありがとうございます。 そういえば、 打ち上げにもご招待いただきましたね。 感謝します。 わたしはこのときにはじめて山形さんにお会いしました。
「暗号学者の道具箱」という表現は、 これもまたブルース・シュナイヤー著、山形浩生訳の 『暗号の秘密とウソ』からお借りしたものです。
エニグマなどの歴史上の暗号については、 定番の 『暗号解読—ロゼッタストーンから量子暗号まで』がよかった。サイモン・シンの文章と、青木薫さんの翻訳ですものね。 執筆とは直接関係はないのですが、 以前メールをさせてもらったときに 青木さんから はげましのメールをいただきました。 ありがとうございます。
以上挙げた本と、わたしの『暗号技術入門 —— 秘密の国のアリス』との位置関係はおおよそ次のようになります。
さて、もうひと読みしよう。
アリスがコインを投げた。
すると、表が出た。
表と裏のどちらが出たのか、アリスはイブに知られたくない。 コインの表裏をイブに知られずに済んだとき、 アリスのプライバシーは守られた、と考えてみよう。
「コインの表裏くらい、知られてもいいじゃない」と第三者が決め付けることはできない。 コインの表裏をイブに知られたくない理由は問わない。 自分が持っている1ビットを、 その1ビットが何をあらわすものであれ、理由がどうであれ、 誰にも知られずにいられる、ということがプライバシーの本質ではないか、 と思う。
コインの表裏というのは一例にすぎない。 たとえば…
別に「二つに一つ」という内容だけに限定しなくてもいい。
自分の持っている情報を、 それが何をあらわすものであれ、理由がどうであれ、 誰にも知られずにいられる、ということがプライバシーの本質ではないか、 と思う。
なお、以上は、 眠い頭で何も調べずに書いているので、 見当違いのことを書いていたらごめんなさい。
補足: (2003-08-22) officeさんからコメントがあったので読む。
結城さんの結論の中で、特に 「誰にも」 の部分が特にまずいと思う。 そのすぐ上では「イブには」になっていたではないか。 「イブには」と「誰にも」の乖離は大きい。 誰かには知られてもよいけれども、誰かには知られたくないのだ。 そして、その制御を「自分がしたい」ことこそ重要なのだ。
なるほど！ 確かにその通りですね。 この部分に関して、わたしもofficeさんの考えに賛成です。 ということは…「どの情報を誰に知らせるかを自分が制御できる」ということですね。 コメントありがとうございます。
[CR] うう、時間が時間が。仕事が仕事が。
楽しみながら『暗号技術入門 —— 秘密の国のアリス』再校のお仕事。 第10章まで読んだ。 一方向ハッシュ関数やデジタル署名のところも面白いですねえ。 そこまでずっと読んできたことがドドンとつながっていく。 何だかテトリスのピースが積み重なったところに、細長い □□□□ のピースが続けて縦に落ちてきて、 一気にたくさんの段が消えるような快感。
固有IDのシンプル・シナリオ の適用例に関して、 技術的な可能性、合法性・違法性、 それに道義的な良し悪しを議論するための立脚点となる「チェックリスト」を提示します。
このチェックリストを使ったからといって、 技術的な可能性、合法性・違法性や道義的な良し悪しがすぐわかるわけではありません。 しかし、状況を整理し、すれ違った議論や問題のすり替えが起きないようにするための 立脚点として用いることができるのではないか、と思っています。
「固有IDのシンプル・シナリオ・チェックリスト」 は次のように構成されています。
という3つの事柄それぞれに対して、
という3つの観点から質問文が作られています。
あなたが、固有IDにまつわる議論を目にしたとき、 アリスになったつもりになって、 心の中で
「アイテム・ID読取機・ボブ」に関して、アリスの「把握・同意・拒否」はどうなっているかな、
と考えていただければ幸いです。 それでは、どうぞ。
[CR] 待ちに待った再校が到着。 再校になるとざらざらがだいぶ取れていて、 初校の加筆も反映されていて、楽しみながら校正ができる。
とりあえず、第6章まで一気に校正する。 とっても、面白い！ 読んでいてわくわくする、知的冒険。 一見ややこしそうに見える図なんだけど、読んで理解できると、すごいカタルシス。
この本を書き始めたのが昨年の9月だから、もうすぐ一年だ。
神さま、神さま。あなたの御名を賛美します。 あなたが本を書かせてくださっていることを感謝します。 本が完成間近です。神さま感謝します。 あなたがはじめられたことですから、あなたが完成させてください。 主よ、感謝します。
この本を必要としている読者に、この本が届けられますように。 この本を通してもあなたの栄光があらわされ、 この本に関わるすべての人に、あなたからの祝福と恵みがたくさんありますように。
イエスさまのお名前で祈ります。アーメン。
文章の校正をするときには、いろんな人の帽子をかぶり、その人になりきります。 暗号技術のことを知らない読者の帽子をかぶって読む。 断片的な知識を持っている読者の帽子をかぶって読む。 疲れて流し読みしている読者の帽子をかぶって読む。 じっくり細かなチェックをしている読者の帽子をかぶって読む。 さまざまな帽子をかぶりなおしては読み返し、気になったところにしるしをつける。 そして、著者の帽子をかぶってしるしをつけたところを修正する。 その地道な繰り返し。書くのも地味だが、読むのも地味、校正するのはもっと地味。
以下のリンクは昔書いた「校正の実例」など。 もっとも、再校の段階ではこの実例ほど大きな修正はそれほど出てこない（はず）。
ところで、こういう「文章の書き方」や「本の書き方」について書くと、 「そのような商売上の重要なテクニックを公開しても大丈夫なんですか？」と心配してメールを送ってくださる方がいらっしゃる。 お気遣いいただいてありがとうございます。
でも、大丈夫なんです。
私がいくら自分の文章のテクニックやノウハウを公開しても、 わたしが困ることはまったく起きないのです。むしろ良いことだけが起きます。 理由をいくつか挙げましょう。
まず、私が書いているような内容は、 本屋さんにいって「文章の書き方」の類の本を探せばたいてい書いていることです。 つまりは、表現は違えども、すでに公になっている内容が多い。 それから、いくら私が書いても、そのノウハウを実行に移すのは難しい。 実行に移せるような人は、実はそんなことはすでにやっている場合が多い。
それに、もしもわたしのテクニックやノウハウを使って、 わかりやすい本がたくさん生まれたとしましょう。 そのような現象が起こって、困る人は誰かいるでしょうか。 いませんよね。わたしも自分の本を書くときには他の本を参照して勉強します。 読みやすく、わかりやすい本がたくさん生まれたら、 自分がもっと勉強しやすくなる道理です。
そういえば、 山崎さんと奥村さんが共著で本を執筆していますが、公開レビューアを募集なさったようです。 こういう活動って素晴らしいと思います。 執筆がんばってくださいね。応援してます。
それはさておき話を戻します。 何より、私が自分がやっていることを文章にまとめて公開すると、 それは私自身の勉強になるのです。自分の考えがすっきり整理されるからですね。 また、自分で読み返して勉強にもなる。過去の自分から習うわけです。
さらに、公開していると、いろんな人から反応がある。 「こういう方法もありますよ」「こういうツールについてはどう思いますか」 「これはこうしたほうがよいのでは」「こんな本は書かないんですか」 これは一人で本を書いている人間にとってはかけがえのない情報です。 しかも、私がたくさん公開していればいるほど、 他の人からの反応や情報は的を射たものになる。 結城の現状にマッチした情報をみなさんが送ってくださるのです。
だからわたしは、自分が書いたものをせっせと公開している。 それは楽しい（いささか楽しすぎて仕事がおろそかになるくらい楽しい）し、 他の人にとっても役に立つし、自分にとっても役に立つ。 つまりは、誰にもデメリットにならない。
逆に、自分だけに閉じこもってしまうと、 メリットはほとんどなくなります。 自分だけの小さな世界がもっと小さくなっていく。
だから、わたしは嬉々として文章を書き、嬉々として公開しているのです。
(^_^)
似たような話を、わたしは何度も書いてますね。以下、リンク。
バスを降りたとき「孤独な人のために祈る」という言葉がふと心に浮かんだので、祈る。
一人ぼっち。
まわりには誰もいない。
それはとても孤独だ。さびしい。誰もいない。誰も自分のそばにいない。 それはとてもさびしい。
でも、まわりにたくさん人がいても孤独なこともある。 まわりにはたくさん人がいる。でも、誰も自分の話を聞いてくれる人はいない。 言葉は聞いてくれる。でも、本当の自分の声に耳をすましてくれる人はいない。 ……そのように感じている人は、とても多い。
学校で、職場で、家庭で、自分のそばにいつも人はいるのだけれど、 自分の本当の気持ちをうちあけたり、 心からの感情を吐露できない人は多い。
自分の気持ちを話せないどころではなく、 いじめや仲間はずれ、陰口やいやがらせに悩む人もいる。 毎日行かなければならない学校や、職場、 あるいは家庭がそのような場所だったらどれほどつらいことだろう。
孤独。
信頼している人に裏切られるのもつらい。 いままでずっと一緒に歩んできた仲間から、 いざというときに突き放されるのは本当につらい。 自分は何も悪くないのに「悪いのはこいつ」と名指しされ、 いわれのない濡れ衣を着せられ、大勢の前で恥をかかせられる。 そのようなひどい目にあっている人もいるかもしれない。
あなたはいかがですか。
あなたの悲しみ、あなたの孤独、あなたの受けた傷のことは、 誰も理解できないかもしれない。
でも、イエスさまは、あなたの悲しみ、孤独、そしてあなたの傷のことを知っている。 その痛みを本当に知っている。
なぜなら、イエスさまもあなたと同じ道を通られたからだ。 信頼して共に歩んできた弟子の一人に裏切られ、 他の弟子たちもちりぢりに逃げてしまい、 一人だけ縄目を受けたイエス。 自分は何も悪いことをしていないのに「死刑にしろ」と言われ、 鞭打たれ、いばらの冠をかぶらされ、つばをかけられ、 恥ずかしい姿で、十字架で盗賊と一緒に死んだイエス。
イエスさまは、 孤独なあなたの受けた苦しみ——受けている苦しみを、 誰よりもよく知っています。
しかし、イエスさまは、十字架の死で終わったのではありません。 三日目に死に打ち勝って復活なさいました。 イエスさまの生涯は、孤独で終わったのではない。 孤独は通らねばならない通過地点でした。 孤独を通り、裏切りと悲惨な痛みと悲しみを通って、 しかし、最後には勝利をつかまれました。
時にイエスさまは、自らさびしいところに赴かれました。 さびしいところに行き、神さまにお祈りになったのです。 孤独を孤独とせず、孤独を神さまとの深いコミュニケーションの場となさったのです。
いま、孤独の中にいる人のために祈ります。
（沈黙）
天の父なる神様。あなたの御名をほめたたえます。 あなたは何とすばらしい方でしょう。 わたしたちを愛してくださり、そのためにひとり子イエスさまを十字架にかけてくださり、 わたしたちの罪（神を忘れ、自己中心に走ること）をゆるしてくださったことを覚えて感謝します。
神さまを忘れ、自分勝手に、 自己中心に生きているわたしたちが本来は死ななければならないところなのに、 イエスさまが、私たちの身代わりに死んでくださったことを感謝します。 あなたの救いを信じます。 イエスさまが死に打ち勝って復活し、わたしたちをもまた引き上げてくださることを信じ、感謝します。
神さま。 いま、孤独に苦しんでいる方がいらっしゃいます。 たった一人で悩んでいる方、たった一人で泣いている方、 誰にも理解されずに苦しんでいる方、 思うとおりに勉強が、仕事が、家事が、計画が進まない方がいらっしゃいます。 いったいどうしたらよいだろうと、とほうにくれている方がいらっしゃいます。
神さま。 わたしたちは本当に弱く、はかないものです。 どうか、わたしたちをあわれんでください。 悲しみの涙をぬぐってください。悩んでいる人にはよい解決を、 思うように物事が進まないという方には正しい導きを、主が与えてくださいますように。
人間関係で悩んでいる方もたくさんいらっしゃいます。 神さま。あなたはすべてをご存知です。 ほんとうに、あなたに知られていないことはありません。 この世の誰も知らなくても、神さま、あなたはご存知です。 そのことを畏れつつ感謝します。
どうか、人間関係で悩んでいる方、恋愛で悩んでいる方の上に、 神さまからのしっかりとした支えとはっきりとした指針が与えられますように。 聖霊さま、あなたは私たちの人生の導き手、正しいガイドです。 聖書の御言葉を通し、私たちの道を明るく照らしてください。
いじめや陰口で悩んでいる人の上に、主からの知恵と助けがあたえられますように。 どうか主がご介入くださって、よい解決、よい逃れの道があたえられますように。
伴侶を求めている方の上に、神さまからのよき出会いがありますように。 うまく人とコミュニケーションできないと悩んでいる人の上に神さまからの助けがありますように。 イエスさまがいつも共にいてくださり、人生のどんな場面でも主に祈り、主により頼んで生きることができますように。
弱いわたしたちにとって、人生は本当に困難や障害に満ちています。 あちこちに誘惑があり、落とし穴があります。 主よ、どうか、わたしたちひとりびとりの必要を覚えてください。 あなたが与えてくださる恵みを先取りして感謝します。 祈ったことはすでにかなえられたものとして感謝します。
何よりもまず、あなたご自身を祈り求めることができますように。 聖書を読み、あなたに祈り、あなたをほめたたえ、あなたに感謝することができるように。 いつも喜び、たえず祈り、すべてのことに感謝することができますように。 そうです、主よ。あなたに感謝します。 命を与えてくださっていること、いま、この場所に生かされていることを感謝します。 問題はやってきますが、すべて主によって解決すると信じます！ 主よ、そのプロセスを通しても、あなたの栄光が表されますように。
新しい光を主が与えてください。 あなたが与えてくださる恵みによって、わたしたちは満ち足ります。 あなたが与えてくださる恵みはわたしたちにあふれんばかりに注がれるからです。 人から与えられるものに感謝し、さらに自分から与えるものとなれますように。 人から愛されるだけではなく、人を愛することができますように。 人をうらまず、人をゆるすことができますように。 人をさばくのではなく、人のことをとやかくいうのではなく、 人に喜びと励ましを与えることができますように。
関わるひとすべてに、イエスさまの薫りを伝えることができますように。 主よ。人にはできませんが、神さまにはおできになります。 ハレルヤ、主よ、感謝します！
この祈りをわたしたちの救い主、イエスキリストさまのお名前によって 御前におささげいたします。
アーメン！
[VN]レビューアさんにNo.001「目次」を送付。
うう、仕事が仕事が。時間が時間が。
それはさておき、 森山さんの勧めに従って真面目に勉強する。 といっても時間がないので、 とりあえず30分だけ携帯電話のセキュリティの歴史を勉強。 こういうときには 『情報セキュリティ技術大全』(Ross Anderson)が便利。
p.338からの「電話通信網のセキュリティ」には固定電話網および携帯電話網のセキュリティの失敗の歴史がつづられている。 携帯電話についてはp.345から。 第一世代では電話機のシリアル番号が平文でアナログ送信されていた。 悪者はこれらの番号を近くでキャッチして使った。 第二世代のGSMではデジタルになったが、使われていたハッシュとプロトコルに脆弱性があった。 （使われていた暗号プリミティブに非公開のものがあった——Security by Obscurityだ）。 第三世代のデジタル携帯電話3GPPについては詳しくは書かれていない。
ふむ。確かにいろいろ勉強すべきかもしれない。 セキュリティの歴史を、固有ID（固定ID）の観点から見てみると面白いかも、と思った。
なお、この日記をお読みの方にお伝えしておきたいのですが、 今回の森山さんとのやりとりを、 私と森山さんの対決のように考えるのは不適切だと思っています。 そういうスタンスで考えると大事なことが見えにくくなるからです。 情報を提示している「人」に着目するのではなく、 情報そのものや論理的な道筋に着目して考えを進めるほうが建設的だと思っています。 そういう意味で、 Otsuneさんの一言というのは貴重な意見です。
それから、 私あてにいろいろ情報を送ってくださる方、ありがとうございます。 時間が取れたら少しずつ整理して公開したいと思います。
以下は、読者からいただいた「関連あるかないかわからないけれど参考までに」と送られてきたリンクです。 わたしも内容をよく見ていないのですが、公開。
森山さんの日記（結城への返事）に返事を書く。
▼結城さんの日記に返事を書く。
> 森山さんは「携帯電話の話」といったとき、 「固有IDのシンプル・シナリオ」のボブとして誰をイメージしていますか。 「携帯電話の位置情報を盗聴している人」のことをイメージしていますか？ それともキャリアのこと？
さあ？ 話をはぐらかしてるわけじゃありません。そもそも僕には「固有IDのシンプルシナリオ」に照らし合わせた話は良く分かりません。というのは、もともと結城さんのシナリオでは、ボブが人間である場合、機械である場合、区別されてないですよね。それと同様だと思うのですが？ だから、結城さんが続けて書いているとおり、
> アリスは携帯電話のユーザで、IDは端末の番号、ID読取機は無線基地局、そしてボブは携帯電話のキャリアなのかな、と思いました。
ということなのでは？
私の「固有IDのシンプル・シナリオ」ではボブが人間か機械かを区別していません。その通りです。 でも「適用例」のほうでは区別しています。たいていは人間、もしくは人間の集団です。 森山さんには、私が「固有IDのシンプル・シナリオ」本体と「適用例」を区別した構成と理由がわかってもらえていないのですね。 少し残念です。「適用例」は現実の技術詳細によって妥当性が変化する。 でも「固有IDのシンプル・シナリオ」本体の構成は変化しない。 一般の人の多くは技術詳細を聞いているうちに「IDがボブに読まれている」という本質を見失ってしまうのです。 ボブは必ずしも悪い人じゃない。自分が良く知っている信頼している相手かもしれない。 「誰かに読まれている」と書くと多くの人は「盗聴だ」といって盗聴の可能性について議論し始める。 それは議論の本質を見失う。だから私はわざわざ「固有IDのシンプル・シナリオ」本体で役割の表を作り、 適用例でその表を埋めているのです。議論の立脚点として「アリスは誰？」「ボブは誰？」といったことをはっきりさせたいからです。 その構成を理解していただけないなら、不毛な議論になる可能性が高いです。
▼次に読み取り機のことですが、これは、
> 近未来に実現不可能なものとその理由を具体的に教えてください。
と、同様なので一緒に答えたいと思います。ただしその前に。結城さんは、まだ現在に存在しない技術を仮定して、それを前提に話を作ってますよね。確かに、突然みょうな技術ができないとは限らない。でも僕には、まだ存在しない仮の技術を仮定して、しかもあたかも近未来に実現するような話をしている理由がよく分かりません。
理由はシンプル。 この業界の技術は10年たったらがらりと変わるからです。 せっかく文章を書くのに1年や2年で古くなる文章を書いてもしょうがないからです。
それに、仮の技術でもいいんですよ。 たとえば「この適用例は想像上のものであり、実現は困難と考えられます。理由はアリスのチップをこのスピードでこの距離から読むことは困難だからです」のような 理由をつけておけばよいのです。それは「適用例の検証」ですよね。 でもその検証をする前には、その適用例が何を言っているのか、読者に伝えなければならない。そのためには骨組みを理解してもらうことが重要。 私の書いた適用例には不適切なものがあるかもしれないが、すべて同じ骨組みを持っています。 それが「固有IDのシンプル・シナリオ」本体です。 お願いですから、この構成をわかってほしいです。
▼ということを前提として、取り合えず話を続けます。あり得そうにないものとして、僕はいろんなタグを非接触、しかもかなり遠距離からでも読み取れる読み取り機を挙げます。適用例３と４にあたるんでしょうか。RFIDのうち特にパッシブタグは、非接触といっても、それは端子から直接リード／ライトしなくて良い、といった意味であって、ほとんどは密着させないと読むことができません。いわゆる「近接型」という奴です。コンテナ用にある程度距離があるところから読めるタグもありますが、多くはアクティブタグですし、読み取り機は大きなものになります。RFIDの特性については色々な雑誌や本に出てますし、結城さんもウェブなどでご覧になったとのことですから省略します。必要であれば「RFマガジン」や「カードウェーブ」「月刊バーコード」など業界雑誌を読むことをオススメします。結城さんが適用例で示しているのとは逆に、必要なタグをきちんと読みとることにいかに業界が苦労しているのか分かると思います。マンガと現実は違います。
なるほど、適用例3と4では、密着させるほどの距離でないと読めないのですね。理解しました。 では適用例3と4にその旨加筆しておきましょう。…加筆しました。
ところで、業界的には「距離を伸ばすこと」を目標として動いているのではないでしょうか。
▼そもそも、複数のぜんぜん用途の違うタグを読めるリーダーの存在意義が僕には分かりません。RFIDの主な用途はタグです。その名の通り、無線による個別識別が用途です。そのためにはむしろ、余計なタグは読まない、という仕様のほうが必要とされます。たとえば、レジを通過するためのタグ読み取り機を想定しましょう。それが客がいま着ている服そのほかにも反応してしまったら困ると思いませんか？ いまでもあるサービスですが、カフェテリアの自動決済システムが、財布のなかのＩＣカードの情報を盗んだりしていますか？ Suicaの読み取り機が、タイプAカードやＩＣチップ入りクレジットの情報も読みとっていますか？ 僕も専門家じゃないし、RFIDメーカーの出しているタグ全てを知ってるわけではもちろんありません。ですから正確なところは知りません。また、RFIDがもともと戦闘機の識別用として発案されたことを考えると、遠距離で届くものもあるのかもしれません。海上コンテナ用や車両用のタグなどは時速１３km以上の速度でも読みとれることがISOで定められており、たしか現行電波波のもとでは最長２ｍの距離からの読み取りが可能なはずです。が、それは特殊な例であって、通常RFIDと呼ばれるもの、あるいは結城さんが「適用例」で想定しているようなタグとは違うんじゃないでしょうか。さて、魔法のようにどの周波数のタグでもバンバン読みとれる万能読み取り機は技術面でも運用面でも想定しにくいと考えるのは不自然でしょうか？ というか結城さんは、どこのメーカーのどのタグシステムを想定して話をしているのでしょうか？ 結城さんが言ってるようなことができるタグシステムがあるのであれば、それこそ僕も具体的に教えてもらいたいです。
なるほど。用途の違うタグを読むリーダーというのが存在しない・少ないのですね。理解しました。 適用例3の場合には、マニアのボブくんが複数のリーダーをカバンに入れて歩いているかもしれませんけれど。
▼細かいことですが、適用例２で靴のようにすり減るものに乗車券機能を持つタグをつけるというのもまずないでしょう。また、これまでにも何度も書いたことですが、僕はカードを意識的に使うということと、（知っているとはいえ）無意識のうちに読みとられるという想定は全く違うと思っていて、今後もゲートのようなところでは原則、カードをかざすような形になると思います。それと、適用例１で「顧客データベースなしで」と言っているのも良く分かりません。購入履歴を参照しているわけだから、それはデータベースでしょう？ それとも、客のカードに履歴が表示されるようなものを考えている？
適用例2の「チップのついた靴」ですが、あれは乗車券機能とは限りません。 もしもボブが鉄道会社だったら乗車券機能かもしれない。 でもボブが興信所だったら、違うかもしれない。 だから「シンプル・シナリオ」が重要なのです。 「ボブは誰？」「アリスは誰？」という問いに答えることは重要です。 まあでも、これはここでは、細かい話。
適用例1というのはメンバーズカードの例ですね。 メンバーズカードの番号が新宿店のレジと銀座店のレジでスキャンされたとする。 そのデータ（番号）を入手したボブは、新宿店のレジと銀座店のレジを通過した人が同一人物らしいことがわかる、 という意味です。 カード番号から顧客データベースへアクセスして、顧客の名前を取得しなくても、同じ番号であることだけで同一人物であることがわかる、 という意味です。 買った商品と番号がバインドされるような表現になっていたのはちょっとまずかったですね。 「土曜日に新宿店でスカーフを買った人」が「日曜日に銀座店で靴を買った人」と同じらしい、 と書くよりは「土曜日に新宿店のレジを通った人」が「日曜日に銀座店のレジを通った人」と同じらしい、 と書いたほうがよかったですね。
メモ：「あるIDをあるリーダが読んだ」という事実は、データベースの小さなカケラなのですよね。
▼次。
> もっとよい事例があるなら、ぜひ具体的に教えてください。
あのう、そこも僕は今回の結城さんの「シナリオ」の書き方への疑問点なんですけど、結城さんは、悪用される例には、まだ存在しない技術を色々考え出して「お話」を創ってますよね。なのになぜ、良い例に関しては「具体例を挙げろ」になるんでしょうか？ 今回結城さんは、技術は中立だ、と言いながら、「うまく使えばこんなことができますよ」ということをぜんぜん提案していない。むしろ一方的に不安をあおり立てるような書き方をしている。それは中立とは言えないのでは？ 可能性の話をするのであれば、そりゃ色々言えるでしょうけど、そのためには、もうちょっと具体的なことに基づいて言うべきなんじゃないでしょうか。
すみませんが、遅ればせながら、 徘徊老人の例や、 遊園地の迷子探しも書いてありますので、いちおうぜんぜん提案してないわけではないです。
▼取りあえず話を進めます。遊園地や徘徊への適用は既にココセコムそのほかの商品で実施されている例です。無くなった宝石が戻ってきたのは有名な話ですね。それ以外に実施されている例としては、たとえばタクシーやバスの配車サービスなどがあります。DoCoですCarなどですね。単に最適な配車をするだけではなく、ユーザーが位置情報を知らせるとタクシーを一発で呼ぶことのできるサービスも、既にサービスインしています。そもそもカーナビや、GPS携帯による人ナビサービスなども同様のサービスですね。盗難防止のイモビライザーもRFIDです。もっと広く言ってしまえば、電子メールやウェブ、インターネットなど物理的なコンピュータにアドレスを振るという技術一般も固有IDを利用したサービスではないのでしょうか。そもそもRFIDによるタグ付けは、これまで機械が識別することができなかった物体を個別に識別して計算機で扱えるようにするというところに特徴があるわけですから。また、結城さんは乗車券カードについて全く言及していませんが、当然、あれもそうですね。そのほかインタフェースとしてRFIDを使うという研究もあります。以前もこの日記で紹介したことあると思いますがPlayStandなどは分かりやすい例ですし、他にもいろいろと考えられるでしょう。そもそも僕は、RFIDは、結城さんが想定しているようなケース、つまり勝手に情報が読みとられて勝手にどうのこうのされる、ということを、むしろ防ぐためにあると考えています。そのことは既に「中央公論」の原稿、またはあれを書いているときの日記でも断片的に書いているとおりなので、読んで頂きたいと思います。
ええと、素朴な疑問なんですが、遊園地や徘徊に実施できるということは、 マリネラから帰国したアリスを成田で捕まえることもできそうな気がするんですけれど…。 それともそれは読取機のサイズの問題なのでしょうか。
私が理解できないのはこういうところです。 つまり、1つの役に立つ技術があるときに、 そのシナリオはちょっと変えると悪用できると思うのに、 どうして悪用のシナリオを作らないかな、という点。 よい事例がたくさん出てくるのはよいことです。でも悪い事例をたくさん作って危険に備えるほうがバランスとしてはよいと思うのですけれど。 徘徊の精度を上げたい、なくしものの精度を上げたい、コストを下げたい、そういう努力は「良いシナリオにも、悪いシナリオにも」影響を与えるのです。
▼Suicaについてですが一言いいでしょうか。色々と仰るのは別に結構だと思いますし、別に僕はソニーからもＪＲ東日本からもお金をもらったりしていませんが、６００万人のユーザーが５００円払ってタグを購入しているという事実をまるで評価しない、あるいは無視しているのは、RFIDあるいは固有IDについて語る上で、公正な態度でしょうか？ たとえば僕の知人の中にも、Suica定期を無くしたけども全額戻ってきたという人がいます。これは固有IDのメリットです。既存の定期では無理だった。なぜそれらのことについて全く言及しないんでしょうか。ＩＣカードで何ができるか、ＩＣカードとは何か、RFIDの可能性は、といったことについては、僕も未だに色々と考えている最中ですが、色々なサービスが考えられる、ということは、これまで何度も、あちこちの媒体やこの日記で書いてきたとおりです。具体例を言えと仰るのならば、せめて僕が書いた記事くらい読んだ上で質問して頂きたいと思うんですけど、駄目ですか？ 上記の例については既にどこかで僕が書いたことがあるものです。結城さんが悪用例でやっているように空想で良いのならばもっと色々書けると思いますが、ここでは触れません。これまで同様、自分の日記や原稿で書いていくつもりです。
物知らずですみませんが、私がSuicaの話を書かなかった理由の1つは「６００万人のユーザーが５００円払ってタグを購入しているという事実」を知らなかったからです。 もう1つの理由は「６００万人のユーザーが５００円払ってタグを購入しているという事実」は私のページに直接的な関係はないからです。 わたしが「６００万人のユーザーが５００円払ってタグを購入しているという事実」から感じることは、 もしもそれだけユーザの数がいるのなら、リスクに関する説明責任はそれだけ大きくなるだろうな、ということですね。
私が「具体例を教えてください」と書いたのは、私が考えるよりも適切だと思ったからです。 時間ができたら、森山さんのページを読み返して「良い例」を探してみましょう。 そして、その技術水準を使って「悪い例」が作れないかどうかも考えてみましょう。
▼なお、僕が本当のメリットだと思っているのは、以上のような、あれができるこれができるといったレベルの話ではありません。たとえば、日記って、誰が一番読むかというと、自分ですよね。自分の履歴を一番知りたいのは、自分なんですよ。自分の履歴を（安全にね、もちろん）参照できたら便利だなと思いませんか？ しかもそれが、そのときに周囲にあった事物も含めて記録されているとしたら？ まったく違う視点が開けるんじゃないかと思いませんか？ まあ、それはずっと先の話で、近未来じゃないですが。また、そもそもユビキタスなサービスを実現しようとしている人たちは、周囲の環境全体を賢くしようとしているわけですよね。それが本当のメリットだと思うのですが。それは何だ、と言われても、そこは一言では答えられません。たぶん結城さんがユビキタスな環境について全く言及しなかったのと同様の理由で。
「悪い犬はたいしたことがないが、悪い人間は危険である」という考え方があります。 賢いからといって良いとは限らない。賢くなればなるほど、悪くなったときは危険です。 周囲の環境全体を賢くするならば、それが悪くなる可能性を考えたほうがよいですよ。
それ以外の「便利だなと思いませんか？」については同感です。 というか、このようにやりとりしていると、 まるで私がRFID反対の急先鋒のような気分になってくるのですが、 私はそのつもりはなかったのですが…。 まあ、しかたないか。
▼なお、
> ところで、まだ「存在しない危険性」が「存在する」時点になってからでは、もう遅いような気がするのですがどうでしょう。
確かにそのとおり。同感です。ですが、僕は結城さんが不安に思っているようなことは、まず起きないだろうと思ってます。そしてこのような話の場合は「可能性としてあり得る」というシナリオを色々考えるよりも、「もっともあり得そうなシナリオについて考える」ほうが良いと思っています。たとえば、結城さんは「あり得る」と書いていますが、そういう言い方だったら何でも言えるんじゃないでしょうか。クッキーのときにも同様の懸念が色々言われましたが、現実問題としては、履歴どころかＣＲＭで顧客の購入履歴を調べて分析云々といった良く言われていた「脅威」さえも、現実的にはできてない企業が多いわけです。コストがかかるから。そういう現実や技術面を全部抜きにして、なんでも「あり得る」と言うのは、あまり意味がないんじゃないですか。そもそも、危険性を議論したいのであれば、それこそタグの使う周波数や標準化動向など現実的な法制度や運用、技術の詳細などを議論すべきだと思いますが、結城さんは「シンプル・シナリオ」という形にすることで、そこを意識的に無視しちゃってるように見えます。
ふむふむ。ここは私と森山さんでまったく考え方が違うところですね。 私は危険なシナリオも興味はありますが、それよりも大事なのは、 固有IDがなぜ問題なのか、ということを理解してもらうことではないかと思っています。 だから私はシンプル・シナリオにしたのです。肉付けはあとでできるから。
▼たとえば結城さんは、アダルトビデオにあっちこっちに電波をとばしまくるRFIDが張られるといったことを適用例３でお書きになってますが、そんなこと本当に起きると思いますか？ ビデオ屋、あるいはビデオメーカーにとって、そんなタグを張り付けて単品管理することはコストに見合うのでしょうか？ 私も計算したわけではありませんが、かなり怪しいと思います。「携帯電話については知らないから」と言って書かなかった結城さん、アダルトビデオの流通には詳しいのでしょうか。悪いけど今回の結城さんのシナリオは公正中立とは言い難いと思います。
あそこでアダルトビデオを出してきたのは「ある人が、ある場所に存在していたモノを所持している」ということを知られるという状況が、 そのモノが何であるかがわからなくても不愉快に感じられる、という例を作りたかったからです。 適用例を無数に書くことができない以上、何らかの意図をもって適用例は作るべきだからです。 なお、私はアダルトビデオの流通には詳しくありません。
また、あそこではわざと「アダルトビデオ」のIDを読み取ったとは書いていません。 マニアのボブくんはリーダーを持って動いている。 アダルトビデオ店でスキャンした「何かのID」なのです。 まあ、でも、森山さんがおっしゃるように、それはナンセンスな仮定なのかもしれない。 でも、そうなのかな？ 現在の店の形態、現在のRFIDの利用法、現在のRFIDの技術ではナンセンスな仮定だとしても、 それは10年後、20年後にもナンセンスなのだろうか。 私にはあまりそうは思えないのですけれど。
▼RFIDの話ばかりしても仕方ないと思いますので違う話をしましょう。たとえば身近なところにある固有IDは、缶ジュースやペットボトルについているシールに印刷されている懸賞応募番号でしょう。購入者は指定のサイトにアクセスしてシールの番号を打ち込むことで懸賞に応募することができます。実際にそうしているかどうかは別として、ドリンクメーカーは懸賞応募結果を見ることで、特定個人の懸賞応募状況ならびに、どこでどんなドリンクを買っているのか断片的ながら知ろうと思えば知ることが出来るでしょう。それだけのコストをかけても見合うと判断すればの話ですが。結城さんはそのことが問題だと思っている立場なんでしょうか？ シナリオ云々を離れて意見を聞きたいと思います。実際にはメーカーが知りたいのは特定個人が何を飲んでいるかではなく、マスの単位で商品がどう動いているかという情報であり、クッキーを使うなどウェブを含めた機械による自動応答サービスの充実である場合が多いと思いますが。
いえ、特に問題だとは思っていません。 もし、メーカーがマスの単位が問題だとすれば、固有IDはロット単位くらいでよい話ですよね（実際ロット管理に利用されるRFIDもありますが）。 賞味期限を考えてもそうです。
▼それと、固有IDが暗号化されているかどうかは重要ではない、という話ですが、これはケースバイケースでしょう。RFIDにしても単に聞かれたら番号を返すだけのものもあれば、暗号化しているものもあるし、バイオメトリクスと組み合わせたものもある。もちろん暗号と言ってもいろいろある。暗号に関しては結城さんのほうがプロですからいちいち言いませんが、番号を読みとられると困るものに関しては、高度なセキュリティが必要だという点では誰でも意見が一致していると思います。でも、別に困らないものに関しては、そんなにコストをかけなくて良いのでは？ 特に、結城さんが想定しているように、ぶんぶん番号が飛び交うようなわけじゃないとしたら。というか、逆に言えば不安ならばぜんぶＩＣカードみたいにCPU入りにしてしまえば良いんじゃないですか。それこそ、コストは将来的に下がりそうだし。
この文章から、森山さんが、固有IDのことを理解しているのかちょっと不安になりました。 「番号を読みとられると困るものに関しては、高度なセキュリティが必要だという点では誰でも意見が一致していると思います」はよいです。 でも暗号化したら固有IDになる可能性がありますよね。 その場合にはまさに「固有IDのシンプル・シナリオ」に合致するのですよ。
あっ、そうだ。 森山さんは、 消費者に理解されていない「ICタグ」についてはどんな意見をもっていらっしゃるのだろう。 あの文章に対して多くの技術者があきれた理由は、 森山さんは理解していらっしゃるだろうか。 日記ではリンクだけで、何もコメントはついていなかったが。
▼なんだか不毛だなあという気がしてきた。机上の仮定に対して色々言うのは疲れる。僕にすればどうでもいい話題だし。
確かに不毛なやりとりなのですが、私にとっては有益でした。 私のまとめ。
最後に、貴重なお時間を使ってコメントを書いてくださった森山さんに感謝します。 実際、こういうコメントを作るのは非常に時間がかかり、疲れるものです。 私は今日の日記を書くのに2時間もかかりました。
まじめな話、森山さんには本当に感謝しています。 ぜひこれからも、よい記事を書いてください。
以下は「固有IDのシンプル・シナリオ」へのリンク。
教会で礼拝。帰ってきてからお昼寝。
固有IDのシンプル・シナリオに対しては、 たくさんの人からメールやWeb日記で「わかりやすい」という励ましの言葉をいただきました。感謝します。 「どうしたらそのようにわかりやすく文章が書けるのか」という質問も複数の方からいただきました。 恐縮ですが、私にはうまく説明できません。 でも、忘れないうちに今回の「固有IDのシンプル・シナリオ」を書いた経緯を簡単に書こうと思います。 誰かの何かの参考になればよいのですが。
まず、もともとの発端は、 森山さんが日記で 高木さんの文章を批判なさったことでした。 あれをきっかけとして、私は高木さんの文章を読みました。 私は 日記の中で、自分の考えを数行にまとめてメモとしました。
(中略)
しばらくして 高木さんの日記が「はてなダイアリー」で始まり、 固有ID（固定ID）の問題がなかなか理解されない、という話題が書かれていました。 私は 『暗号技術入門』を執筆していたこともあって、セキュリティがらみの話は興味がありましたし、 高木さんの書かれている内容もよく理解できました。 しかしそれと同時に、高木さんの文章に物足りないものも感じていました。 1つは長いこと。 それから話が正確で具体的であるあまり、話の大きな流れが見えにくいこと、 それから当事者に対するいらだちがちらちら文章の中に現れるためか、 「技術そのもの」よりも「人」にフォーカスがあたりがちだという点です。
その後、高木さんの日記は毎回すごい量が続き、 しかもその内容はなかなか注目すべきものばかりでした。 でも、たとえば私が自分の読者として想定している人は、 あの文章を読みこなすことは難しいだろうな、 とも思いました。 何しろ高木さんの日記は半端じゃない量なのです。
その後、 消費者に理解されていない「ICタグ」という記事が登場し、 高木さんは、 その記事に途方にくれている文章をお書きになりました。 私もITProの文章を読み、高木さんのいらだちを理解しました。
あの記事には読者コメントがつけられるのですが、
読者コメントを読むためにはクッキーをONにしたブラウザでログインしなければなりません
（クッキーで自分をトラッキングしてもらわなければ、記事が読めないわけです(^_^)）。
それでしばらくは放置していました。
でも、 たださんの日記を読んで、 コメントがたくさんついているらしいことを知りました。 私もログインしてコメントを読んでみました。 RFIDの専門の方から、一般の技術者まで多数の人がコメントをつけていました。 高木さんの記事などをあげて批判している人もいましたが、 扇情的な文章で、単に煽っている人もいました。
コメントを読んでいるうちに、 セキュリティやプライバシーに関わる文章は、 ちょっとした前提条件の変化で主張の妥当性が大きく変化するし、 感情的な反応を受けやすいものだなあ、と思いました。 技術的な前提条件をきちんと書かなければ正確な表現にならないけれど、 きちんと書けば書くほど話の大筋はわかりにくくなり、ポイントもぼやけてしまう。
掲示板のような場所で議論をするには不向きなテーマかもしれない、 とも思いました。掲示板では相手の揚げ足取りに終始してしまって、 建設的な議論がしにくいからです。
そこで、技術的な詳細に依存しない、骨組みだけの文章はできないだろうか、 というアイディアが沸いてきました。フレームワーク的な文章です。 私はRFIDについては門外漢ですが、 幸い、高木さんが主張している固有IDの問題そのものは理解しています。 しかも、高木さんが嘆いている「固有IDの問題の理解しにくさ」は、 RFIDの技術詳細に依存しません。 さらに、暗号技術の説明に関しては、 わかりやすい図を使うという方法が有効であることがわかっていました。 これは私の 『暗号技術入門 —— 秘密の国のアリス』の執筆経験によるものです。
ここまで考えると、後は書くだけです。 一番最初に考えるのはファイル名です。 rfid.htmlにしようかと思ったのですが、 RFIDという名前をファイル名につけると、RFIDのみのページと勘違いされる可能性があると思い、 uniqid.htmlにしました。
同様の理由で「RFIDの問題点」などとはせず「固有IDのシンプル・シナリオ」というタイトルにしました。 そのほうが内容を適切に表現していると感じたからです。 このページは、おそらく多くの人に言及されるだろう、と考えましたので、 覚えやすく印象に残る語句をタイトルに入れたいと思いました。 そのため「シンプル・シナリオ」という語句を使いました。 「固有IDのシンプル・シナリオ」。 うん、なかなかいいじゃん。 シナリオのつづり(scenerio)は間違えやすいので、 ファイル名をscenerio.htmlとはしませんでした。
さて、まず私は話をできるだけ単純化するために、 IDを持った「アリス」と、IDを受け取る「ボブ」を登場させました。 ここで、アリスとボブが誰であるかを定めないのがポイントです。 それから固有IDがふられた「アイテム」を登場させました。 最初は「商品」と書いていたのですが、もっと一般化させようと思い「アイテム」としました。 それから「ID読取機」も必要です。これは最初「リーダ」と書こうと思いましたが、 リーダだとreaderなのかleaderなのか一瞬迷うし、もっと泥臭い名称のほうが直感的にわかると思い、 「ID読取機」としました。 無線を前提とはしたくなかったので、アンテナは登場させませんでした。 ここまで考えたところで、適用例1は「メンバーズカード」にしようと思いました。
それから図を描きます。図は、時間が左から右、上から下に流れるように描くのが自然です。 文章から参照しやすいように(A)や(B)のようなラベルをつけておきます。 ラベルをつけるときに、最初は(1)と(2)とつけようかと思ったのですが、 適用例に1, 2, 3,...という番号が登場するかもしれないので(A)(B)にしました。 これはどっちでもよかったかな。
図ができたので、文章を書きました。 「固有IDのシンプル・シナリオ」本体の部分には、RFIDやアンテナや無線といった、 特定技術に依存した話が含まれないように注意しました。 また、「だから危険」「だから安全」といった判断が入らないようにし、 単純明快に「たしかにそれはそうだな」といえるような内容に絞り込んだ解説にしました。
でも「固有IDのシンプル・シナリオ」本体だけでは何を言っているかわかりません。 そこで、 適用例を作ることにしました。適用例を作っているうちに、 「データベースは不要」「個人情報がIDに含まれている必要はない」 「暗号化は意味がない」「読み取られていることをアリスは知っているかどうか」 といった点がポイントとなることがわかってきました。
そこで、 Q&A形式で、補足説明のようなことを書こうとしました。 ここは、誤解を恐れずにできるだけ「話を単純化する」「はっきり言い切る」というスタンスで書きました。 ここのQ&Aの質問となる項目に関しては、 先ほど読んだITProのコメント欄に書かれた項目を参考にしました （文章はすべて独自に書き起こし、自然なQ&Aになるようにしました）。
ところで、以前からYukiWikiに作られていた「RFID反応リンク集」が気にかかっていました。 多くのサイトからリンクされているけれど、これはWikiのページですから、 何かの事故で消える可能性もあります（バックアップしていますけれど）。 そこでこの機会に、スナップショットをとっておくことにしました。
ここまで書いて読み返してみると、 私の意図はだいぶ表現されていると感じられましたので、 公開しました。
自分の日記、自分のニュースサイトであるwww.textfile.org、 それから高木さんの日記の「ツッコミ欄」で案内し、 反応を待ちました。 すぐにフィードバックやメールがやってきました。 フィードバックを元に、細かい修正をかけました。 みなさんからたくさんのフィードバックやメールをいただいて、とてもうれしいです。 「読みやすい」という意見だけではなく、 「こう書いたほうがよい」「これはフェアじゃない」という意見も、 とても励みになります。 今後ともよろしくお願いいたします。
ただ、 だいぶ自分の仕事をほったらかしてこのページに関わってしまったので、 これからは、ちょっとペースを落とします。
森山さんの日記からヒントをいただいたので「適用例7: 携帯電話」を加筆しました。 これはサービスを受けるために固有IDが有効に機能している例ですね。
加筆のきっかけを与えてくださった森山さんに感謝します。
それでは教会へ行ってきます。
森山さんの日記で、私の「固有IDのシンプル・シナリオ」に反応があったので、 お返事を書く。
▼結城さんの固有IDのシンプル・シナリオ。僕が読んで素朴に疑問なのは、なぜ結城さんは携帯電話のことについて書かないのか、ということ。クレジットカードなんて例を出すのは何だかトンチンカン。
反応ありがとうございます。 森山さんの反応をお待ちしていました。
携帯電話のことについて書かないのは、 私が携帯電話のことをよく知らないからです。
クレジットカードの例を出したのは、 ITPro 記者の目 「消費者に理解されていないICタグ」の読者コメントの中に、 クレジットカードに言及していた方がいらしたからです。
私の記憶では、 森山さんが「なぜこれだけ普及している携帯電話のことを書かないのか」と似たトーンで 「なぜこれだけクレジットカードが普及しているのにいまさらRFIDで騒ぐのか」というトーンだったような気がします （すみません、あの読者コメントを読むのにはちょっと手間がかかるので記憶で書いています——加筆：調べてみたところ、 クレジットカードは複数人の方がいろんな角度でRFIDとの違いを述べておりました。 その中に、クレジットカードをみんなが使っていることを引き合いに出して 過敏な反応は「セキュリティアレルギー」と表現をした方がいらしたのでした）。 RFIDのことを知っている人にはトンチンカンに見えるのかもしれませんが、 クレジットカードの例のQ&Aに納得していた読者さんもいらしたようですので、 一般読者にはそれほど無駄ではないと思いますが、いかがでしょうか。
▼携帯電話は、結城さんは当然知ってると思うけど、自分の番号を持っていて、電源が入っている限り、自分の位置をキャリアの無線基地局に連絡している。サービス制御局は各端末を位置登録している。つまりキャリアは、どの端末がどのエリアにあるのか知っている。携帯電話は既に相当普及している。今後、まずできないだろうと思われる読み取り機云々の話を例として持ち出す一方で（まさかあの例は本気で言ってる？）、既に今日普及している携帯電話のことを触れないのはどうしてなんでしょうか。まさか「自分で電源を切れるから問題ありません」と答えるつもりなのかな？ 自分の時空間情報を随意に提示できることによるメリットも全然触れてないし。ユビキタス系サービスを受けようと思ったら、機械に（人間じゃなくてもいい場合も多い）自分がいまどこにいるか提示しないとまず無理ですよ。ただし、機械への情報提示は匿名でもいいものもあるだろうし、逆に個人識別が必要なものもある。大事なのは、その両者を区別し、技術的に安全を担保しながら成立することだと思うのだけど。少なくとも僕はそう思う。携帯電話も持ってないけど。
なるほど。携帯電話の仕組みはわかりました。ありがとうございます。
森山さんは「携帯電話の話」といったとき、 「固有IDのシンプル・シナリオ」のボブとして誰をイメージしていますか。 「携帯電話の位置情報を盗聴している人」のことをイメージしていますか？ それともキャリアのこと？
私は「固有IDのシンプル・シナリオ」にあてはめて、 アリスは携帯電話のユーザで、IDは端末の番号、ID読取機は無線基地局、そしてボブは携帯電話のキャリアなのかな、と思いました。 その場合には、アリスは自分のサービスを受けるために、ボブを信用しているということですね。 それは（もしもアリスがそのことを理解していれば）問題がない例ではないでしょうか。 携帯電話のキャリアを信用できない人は携帯電話を使わないことになりますね。 時間ができたら、この携帯電話の例を事例として加筆しておくことにします。 ありがとうございます。
「自分の時空間情報を随意に提示できることによるメリット」 の例としては、たとえば 徘徊老人の例や、 遊園地の迷子探しなどを昨日・今日書いてみました。 もっとよい事例があるなら、ぜひ具体的に教えてください。
「大事なのは、その両者を区別し、技術的に安全を担保しながら…」のくだりはまったく同感です。 私の書いた事例の中で「今後、まずできないだろうと思われる読み取り機」というのはどれでしょうか。 具体的に指摘していただけると、加筆・修正がしやすいのでよろしくお願いします。 なお、私が書いた事例は「現在は難しくても、近未来には実現可能じゃないかな」と私が想像したものも含めて書いています。
▼ていうか、そもそも「〜することができる」「あり得る」ということと「現実にある」ということを、意図的か無意識か知らないけど混ぜて使われているように読めますね。携帯電話の位置情報がずーっと取られているということは事実。だけど、たとえばSuicaカードの履歴が、読み取り機を持った知らない人に読みとられました、というケースは（僕が知る限り）聞いたことない。Suicaカードは６００万枚が毎日使われているのに、だ。その両者を同列に、というか片方には言及もせずに、一方的にまだ存在しない危険性だけを主張するのは結城さんらしくないと思えるのだけど。
携帯電話について言及しなかった理由は上述したとおり。
「Suicaカードの履歴が、読み取り機を持った知らない人に読み取られました、というケース」があるのかないのかは私にはわかりません。 私は私の知っている（あるいは想像できる）範囲で書いているだけですので、ごめんなさい。
ところで、まだ「存在しない危険性」が「存在する」時点になってからでは、もう遅いような気がするのですがどうでしょう。
▼Suicaは今のCLIEの一部機種でも読みとれるんだけど、ポケットの中のカードの履歴を読みとるためにCLIEを手にそーっと近づいている人がいると想定してみましょう。その人は、タグ読み取り機を持っていようがいまいが不審人物です。セキュリティには、そういう物理的障壁もあるんだ、ということをなぜ触れないのかな。ていうか、そもそもタグの特性は使う電波によって全然違ってくる、ということを結城さんが触れないのは何だか分からない。RFIDは魔法じゃないんだから。
現在のSuicaに限って言えば、そうかもしれない。 でもそのほかのすべてのタグについてそうなのでしょうか？ 私が書いた 適用例3: 読取機を持ち歩く人の例を見ますと、そこに書かれているのはSuicaの例ではありません。 このボブが読み取っているのは、何かのアイテムです。
もちろんセキュリティには物理的障壁もあります。 でも、何から何まで書いたら、わけがわからないページになって終わりだと思いますよ。 私はできるだけしぼってしぼって、でも、あれだけ長いページになっているのですから。
私はRFIDに関する製品を作っている会社のWebページをいくつか見ました。 でもそこにあるのは、非常に細かい技術詳細か、ふわっとした事例だけでした。 メリットとリスクをきちんと書いている、 会社のWebページを見つけることはできませんでした （会社は、リスクを書かないだろうなとは思っていましたが）。
タグの特性が使う電波でぜんぜん違ってくる、というのはおぼろげには知っています。 でもそういうことより何より重要なのは、次の二点です。
この2点です。実現方法や距離、物理的な特性などは、 これから何年かたてば大きく変化するでしょう。 現在不可能と思われていたことも、可能になるでしょう。 でも、上に書いた2点は変化することがありません。 これはRFIDの本質だからです。 メリットも、デメリットも、ここから発生します。
そして、モノにIDがふられるということは、 そのモノを持っている人がいたら、その人にもIDがふられることになります。 IDに個人情報が含まれていようがいまいが、IDを暗号化しようがしまいが、データベースがあろうがなかろうが、 その事実は変わらない（「暗号化」については、固有IDにならないやりかたはありますが）。
私は「固有IDのシンプル・シナリオ」でその点を強調したかった。 そしてそれは、RFIDの現在の距離がどうこう、 Suicaがどうこうというよりもずっとずっと大事なことだと思いました。 あの「固有IDのシンプル・シナリオ」（ページ全体ではなくはじめのほうにある図がついた一節のこと）を よく読んでもらえばわかるように、RFIDとは一言も書いてない。善悪も書いていない。
その後の適用例は、適用例にすぎない。 適用例を作れば、議論することができるからだ。 よいものもある。わるいものもある。 適切なものもある。不適切なものもあるかもしれない。 でも不可能なものはない、と思っている。 自分の無知は自慢できないけれど、 私は 2003年4月25日まで、RFIDという言葉を知らなかった。 森山さんのように、現状のRFIDに非常に詳しい人こそ、よい適用例をたくさん作ってほしいと思います。 他の人がよく納得できて、しかも検証できるような適用例を作ってください。 これは森山さんに対する批判や皮肉ではなく、本当にまじめなお願いとして書いています。
というわけで、森山さんに対するお願いとして2点あります。
1. 私が、 シンプル・シナリオ適用例で書いた事例のうち、近未来に実現不可能なものとその理由を具体的に教えてください。
2. 森山さんが、より適切だと思う事例、現実味を帯びていると思う事例を教えてください。
1番はぜひ急いで教えてください。 お盆休みが終わって私のページへのアクセスが増える前に少しでも適切な形にしておきたいと思っておりますので、よろしくお願いいたします。 2番はお時間の都合もあるでしょうからそのうちに。
以下は、上記ページへのリンクなど(個人ページが主, リンク探しにはishinaoさんのページを利用させていただきました)。
「結局、固有IDの悪いところだけ書いているじゃないか」 という批判がやってくるので、 固有IDが人の命を救うという例を加筆しました。 この例では、徘徊老人アリスの命を固有IDが救います。
興味深いのは、 「適用例5（徘徊老人）」で徘徊老人アリスを見逃さないためにID読取機の性能が上がれば上がるほど、 それは、 「適用例4（ダイヤの密輸入）」で観光客アリスを見逃さない確率が高くなる、ということですね。
つまりは技術は諸刃の剣だ、と。
お盆休みの時期であるにも関わらず、 先日公開した「固有IDのシンプル・シナリオ」には 多数の反応とフィードバックがありました。感謝します。 www.hyuki.comに対するアクセス数では、 普段はトップページや「日記」が最上位にくるのですが、 一時は「固有IDのシンプル・シナリオ」が最上位にくるほどでした。 みなさんからのフィードバックはページのほうに反映させています。
このページの構成の意図を理解してくださらない読者さんもいらっしゃったので、 以下のような解説を加筆しました。
「固有IDのシンプル・シナリオ」の部分では、図と文章を用いて「固有IDのシンプル・シナリオ」とわたしが呼んでいるシナリオを解説しています。 この部分は特定の技術に依存せず、 また善悪の区別や、違法性の有無について 判断できないような形式で書きました。 この中では、 アリスやボブという固有名詞を使っていますが、 これは単なる役割の名前であると考えてください。 この「固有IDのシンプル・シナリオ」はいわばフレームワークなのです。
シンプル・シナリオ適用例の部分では、 「固有IDのシンプル・シナリオ」に対してもっと具体的な肉付けをしています。 カードのスキャナや、離れてIDを読み取れるチップのように、 登場する技術に多少の具体性が加わります。 適用例の中には「問題のない例」「プライバシーの侵害と感じられる例」「違法性を持った例」 「非常に現実味のある例」「近未来では実現できそうもない例」などが含まれるでしょう。 もっと具体化しないと何も判断・評価できないものがあるかもしれません。 しかし、いずれの例も、 はじめに述べた「固有IDのシンプル・シナリオ」を適用した例になっているはずです。
なお、 officeさんの文章のオープニングを読むと、 私の書いた文章の意図をよく汲んでくださっているようで、とてもうれしい。 以下引用。
「固有IDのシンプル・シナリオ」は、純然たる技術についてのシナリオである。私は極端な物言いとして時として「技術には善も悪もない」ということを言うが、まさにこの文章はそういったものの例といってよかろう。「RFID」だろうと「ウイルス」であろうと、それに関連する特定の「シナリオ」はあるが、それを保持しているから悪いということにはなり得ない。善となるか、悪となるかは運用次第なのだ。
（中略）
ややもすると、固定ID技術推進派からはデメリットだけが示されているように見え、固定ID技術反対派からみるとメリットだけが示されているように見えてしまいかねないが、決してそうではない。現状では「メリット」も「デメリット」もほとんど明確にはされていないのであって、この「固有IDのシンプル・シナリオ」はそれらを明らかにするための基盤となるべき文章なのだ。
RFIDなどの固有IDが生み出す問題は、 複雑で理解しにくい場合があります。 そこで、議論を明確にするために、技術的な詳細に依存しない、 できるだけシンプルなシナリオとして「固有IDのシンプル・シナリオ」を書いてみました。 どうぞご利用ください。
この「固有IDのシンプル・シナリオ」で言いたいのは、 「固有IDを使うと、個人を追跡できる場合がある」ということです。 そして、その際に、
ということを明確にしたいと思いました。
固有IDに個人情報が盛り込まれていなくても、 固有IDが暗号化されていても、 データベースがそもそも存在しなくても、 固有IDを使って個人を追跡できる可能性がある、ということです。
ある読者さんからフィードバックをいただきました。 連絡先がわかりませんので、掲載許可がとれませんけれど、 とても私にとって大きな励みとなる文章でしたので、 みなさんとシェアさせてください。
（送ってくださった方、もしも公開がまずいときにはご連絡ください→許可がとれました。ご連絡ありがとうございます）
結城さん、
いつもホームページを楽しく(たまにうなりつつ）拝見しております。 私は、ホームページを見ても管理者さんにメールを送ったりすることはまずないのですが、 どうしても結城さんには一筆書かねばなるまい、と思ってこれを書いています。 というのは、今月いっぱいで現在勤めているソフトウェア関係の会社を退職することになっており、 お世話になった方々にご挨拶しているところなのです。
私はコンピュータのことなど何もわからずに現在の仕事につき、 今でもそうですが特に最初は周りは宇宙語で、泣きました。 プログラミングの本って、どうしてこんなにもわからないんだろうか。 もしかしてわからせないように書いているんではないか。 どうしてこんなにわからないんだかわからない!! …とげっそりしていたときに結城さんの C の本に出会い、 本当にくるりと一皮むけたような気がしました。
それ以来、C、Java、Perl、CGI の本とホームページで大変お世話になりました。 この世界では結局大成せずに、退職することになりましたが…。 会社で使っていた参考書などはすべて捨ててしまいましたが、 結城さんの本だけは家に持って帰りました。 結城さんの本からは、もちろんコンピュータのことはたくさん学びましたが、 何と言っても人との接し方を学ばせてもらったように思います。 他のコンピュータの本はすごく高飛車で読むのが本当にイヤになってくるのですが、 結城さんの本からはいつも、親切さややさしさがにじみ出ていて、 いつも私のような初心者を辛抱強く導いてくれました。 これからまたこの業界に戻ってくることは全く考えていませんが、 結城さんの本はいつまでも蔵書にして楽しく読ませていただこうと思っています。
もうひとつお世話になったのは、結城さんの Java本の前書きが、 すっかり忘れていた聖書のことを私にまた思い出させたことです。 今はひとりで細々と聖書を読んでいるだけで、この先どうなるかわかりませんが、 聖書も読みつづけたいな、と思います。 そしていつか心の底から聖書の言ってることに確信が持てたらいいな、と思っています。
今まで大変お世話になりました。結城さんの更なるご活躍を 陰ながら応援しております！
結城さんの本の一読者より
結城から
あなたからのお手紙を見ながら、何ともいえぬ思いで胸が熱くなり、涙ぐんでしまいました。(T_T)
新しい道に進まれるとのこと、いろいろと大変なこともあるかもしれませんが、
いつもイエスさまが共にいてくださることを信じております。
神さまの祝福が常にありますように。
その手のわざが祝福されますように。
聖書の学びも守られますように。
そして、あなたご自身が主にますます用いられ、
周りの方々にたくさんのはげましと愛を与えることができますようにと、
心からお祈りいたします。
お手紙ありがとうございました。
[OO] JAVA Developer誌(ソフトバンクパブリッシング)の リファクタリングの連載が終わるので、 次の新連載の準備をする。 先日編集部さんと打ち合わせした内容に基づいて、 12回分（一年分）のテーマを考える。 今晩くらいに編集部さんへメールする予定。
文章を書くのは、恋に似ている。
若いときには書きたいことがたくさんある。 しかし書くための技術も経験もない。 熱意はあるけれど、肝心の読者がいない。
若いときには、恋をしたい気持ちでいっぱいだ。 自分が好きになった女の子を大切にしたいという熱意はあるのだが、 女の子とどうやって話せばいいのかすら、わからない。 肝心の相手がいない。
時が過ぎる。
技術も経験も増えていき、運がよければ読者もいる。 そこでついうっかり、書きたいことを忘れてしまう。 あるいは手抜きをして題材を吟味せずに書いてしまう。 …… 初心を忘れるな。
主のあわれみと恵みにより、最高の相手と幸福な結婚をする。 そこでついうっかり、自分が好きになった女の子——奥さんのことだ——を大切にするのを忘れてしまう。 …… はじめの愛から離れるな。
文章を書くのは、愛に似ている。
神さま。あなたは素晴らしい方。 私たち一人一人に特別の命を授けてくださる方。 あなたの恵みと愛を感謝します。 あなたは何と麗しいかたでしょう。
私たちの毎日には本当にいろんなことがあります。 いろんな出来事があります。私たちの目を惑わせ、 あせらせ、迷わせるたくさんの出来事がやってきます。
しかし、主よ。本当に大切なこと、 私たちにとって第一にすべきことは、 あなたを見上げることです。 あなたを賛美します。 あなたは何と麗しいかたでしょう。
主よ。私たちはあなたを喜びます。 心を大きく開いて、聖霊様を歓迎いたします。 主よ、どうぞ、私たちの心に来てくださって、 私たちを聖め、導いてください。 主よ、感謝します。
どんな出来事があっても、私たちはあなたを見上げ、賛美します。 賛美の歌を持ってあなたを喜び、サタンのたくらみを打ち砕きます。 主よ、あなたこそ主です。王の王、主の主。あなたが最高です。
主よ、あなたは何と麗しいかたでしょう。
人を裁くのではなく、人をゆるすことができますように。 人の欠点ばかりに目をとめるのではなく、愛の目で見ることができますように。 気をくじくのではなく、励ましを与えることができますように。 直接言葉をかけることができなくても、祈ることができますように。
主よ、主よ。あなたは何と麗しいかたでしょう。 両手を打ち叩き、あなたを賛美します。
主よ、私たちは弱いものです。 同じ失敗を繰り返すおろかなものです。 しかし、あなたの哀れみを感謝します。 あなたのゆるし、あなたのいやしを感謝します。
いまつらいときを過ごしている方の上に、 あなたのはげましがありますように。 必要な解決が与えられますように。
勇気をもって進み、あるいはとどまり、 語り、あるいは黙することができますように。 いつも、自分のことではなく相手のことを思うことができますように、 どうか助けてください。
主よ、あなたは素晴らしい方、麗しい方です。
あなたのすべてに感謝して、 イエスさまの御名で祈ります。 アーメン！
現在、結城は、日経ソフトウェア誌で「結城浩の動物相談室——インターネット・コミュニティの歩き方」という連載記事を書いています。
「掲示板」や「メーリングリスト」といったテーマを毎月ひとつずつ取り上げて、
動物との対話形式で紹介するというやわらかい読み物記事です。
このたび、日経ソフトウェア誌の編集部さんから許可をいただいて、
Webでも公開できることになりました。ぜひお読みください。
まずは、今回は「掲示板」のお話です。コアラくんとカンガルーくんが登場します。(^_^)
Webでの公開は雑誌での公開から数ヶ月遅れになりますので、 本記事にご興味を持たれた方は、ぜひ日経ソフトウェア本誌もご覧になってください。 日経ソフトウエア誌は、毎月24日発売です。
Matz日記にアイデンティティの話題が出ていて、 ふむふむ、と読みながら、別のことを考えていた。
スレッド本にImmutableというパターンの話を書いた。 これは状態が変化しないオブジェクトだ。 状態が変化しないオブジェクトは、 自動的にスレッドセーフになる。 なぜなら、スレッドセーフでないという現象は、 あるスレッドが、オブジェクトを状態遷移させている途中（中途半端な状態）に、 別のスレッドが同じオブジェクトに作用を及ぼすときに起きるからだ。 状態遷移しないオブジェクトは中途半端な状態になることはない。 だから自動的にスレッドセーフになる。 例をあげると、java.lang.StringクラスはImmutableであり、 何もしなくてもスレッドセーフになる （インスタンスをコンストラクトするときは例外。構築途中で中途半端な状態を取り得る）。
それはさておき、 変化することのないオブジェクトのアイデンティティは、 その本質（内容）にある。 という話をツッコミに書こうとしたら、 すでにshiroさんが書いていた。ふむふむ、と読みながら、また別のことを考えた。
（以下は、半分はジョークだと思って聞いてください。真面目にとり過ぎないように）
そういえば、神さまも「とこしえからとこしえまで変わらない方」だな。 ということはImmutableだ。 変化することがないから、 そのアイデンティティは参照にあるのではなく、 本質にあるのだな。 おお、三位一体！ 三つの位格が同じ本質を持っておられる！
高木浩光さんは、繰り返し繰り返し「固定ID」の問題点を指摘している。 高木さんの主張は基本的に正しい。 しかし、高木さんが 日記でいらだっているように、 固定IDの問題は非常に誤解されやすいものらしい。
いま「何とかID」というID（アイディー）があったとする。 それはRFIDでも、サブスクライバーIDでも、住民票コードでも何でもいいが、 とにかく何かの番号だ。
「何とかID」は短いから、個人情報は含まれていないように感じられる。 だから「何とかID」がセキュリティを脅かすことはない、と感じられる。 「単なる番号でしょ？その番号がわかっても私の個人情報が漏れるわけじゃない」と感じられる。 また「何とかID」が個人情報のデータベースのインデクスになっているとしても、 そのデータベースさえきちんと守っていれば問題はないように感じられる。
でも、それは錯覚だ。
そのIDの中に個人情報が含まれているかどうかは問題ではない。 また、データベースが守られているかどうかも問題ではない。
その「何とかID」が 「固定ID」かどうかが問題 なのだ。 Webのクッキーとよく似ている。
「何とかID」を通信するときに必ず暗号化したらどうだろうか。 暗号化したら元のIDがわからないから大丈夫だよね……いや、違う。 もしも、暗号化した結果が「いつも決まったビット列」になるのであれば同じだ。 なぜなら暗号化した結果が新たな「固定ID」になってしまうからだ。
繰り返すが、 そのIDの中に情報が含まれているかどうかが問題ではなく、 そのIDが「固定ID」かどうかが問題なのだ。
[CR] と、いうわけで 『暗号技術入門 —— 秘密の国のアリス』の初校読み合わせである。
今回は約3時間半。でも、疲れました。 編集長と二人でみっちり読み合わせして、二人とももうバテバテです。 でもまあ、ここで細かい修正をして、少しでも読みやすく・理解しやすいものにするのは、 著者と編集者のお仕事ですから、バッチリやるしかありません。 だって、ここで決めたことが何千冊（あるいは何万冊？だったらいいですね）と増殖して 日本全国に散らばっていくわけですから、がんばって質を上げる価値がありますよね。
で、志は高く、作業は地道に進むわけです。 今回は全体的に「書きすぎ」ている部分が多いと思っているので、 刈り込みぎみに進みます。 刈り込めば刈り込むほど、テーマはくっきりわかりやすくなり、 テンポは軽くなり、読みやすくなるという道理です。 しかし、はっきりいって、作業内容は愚直を絵に描いたようなものですね。
編集長「ここは『こと』が三つ重なっていますね」
結城「確かに。じゃあ、これは「の」にして、こっちはトルで」
編集長「ここはクーリエでよろしい？」
結城「はい。あ、そこは『暗号文』ではなくて『鍵』です」
編集長「ああ、なるほどなるほど。そうです」
結城「ここはローマンにしてもよい？」
編集長「はい。それもそうですが、ここは級数をもっと落とします」
結城「ここのダブルクォートはクーリエですが、“ ”にしたいんですが」
編集長「ただ、中身がクーリエなので、ちょっと合うかどうか」
結城「じゃあ、なしにしましょうか」
編集長「そのほうがすっきりするかと」
結城「この朱、わかりますかね。矢印を上を回すのではなく、下を回す」
編集長「ええと、あ、大丈夫です。問題ありません。この図は場所をとりすぎているのでここを切って縮めます」
結城「こっちはいいんですけれど、こっちは切らないでください。線を細くして分かれている様子がはっきりわかるように」
編集長「ははあ、じゃ、そうしましょうか。うーむ。このリストがちょっとよくわからなかったのですが」
結城「あっ、これは改行が変ですね。送ったのをそのままフィルせずに入れていただければいいんですが」
編集長「じゃ、そうしましょう」
結城「ここの網掛けはやめませんか」
編集長「もうやめてあります。ここはこちらのインデントで…」
結城「はいはい、そうです。OKです」
編集長「この『ビット長の強さ』というのは表現としてどうかと」
結城「あっ、それはここに「長さ」と補うことにしましょう」
編集長「このページは特にないです」
結城「私も特にないです。ここは縦を揃えてください」
編集長「うーん。それでは、左側を例外的にすこしはみださせましょう。こちらも？」
結城「そうですね。あ、こっちはこの"1"だけは、ボールドにしないでください」
編集長「これですか？」
結城「はいそうです。これはパディングの経過を表現しているので、こっちの"1"はボールドで、でもこっちの"1"は普通のクーリエで」
編集長「はい、問題ありません。ところで、ここの数字は0, 1, 2でよろしい？」
結城「その図はうそがあったのでリライトしました。数字はそもそもなくなります」
編集長「本文のほうも？」
結城「はい。なくなります。そのほうが数学っぽくなくてよいです。図は今晩メールします」
編集長「よろしくお願いします。ここは矢印がないとわかりにくいですね」
結城「そこは、こう直してください。こうですね」
編集長「それはいいですね。ここではまだPKIの説明をしていないと思うんですが」
結城「この後の本文にでてくるし、そこはよしとしましょう」
編集長「そうですね。そうしましょうか。ここで鍵を削除しているのはすでに手遅れだと思うんですが、どうですか」
結城「（考える）…んー、ここの前の段落から書きなおしましょうか」
編集長「よろしくお願いします」
結城「（書く）…こういうのではどうでしょう」
編集長「（読む）はい…はい…はい、結構です。…どうです。一度休憩しましょうか」
結城「そうですね。休みましょう。今回はけっこう順調ですね」
編集長「ですね。でも、二時間はすでに経っていますが」
結城「うっ、本当ですね」
…というような感じだ。 この調子で3時間半びっしり。
こんな作業は、 ぜんぜんセクシーではないし、はたで見ている人がいたら、きっと面白くも何ともないだろう。 ひとつひとつの修正に気がつく人はおそらく読者の中でもほんのわずかのはず。 でも。でも、そのちょっとした修正の集大成が読みやすい本と読みにくい本を分けるのだ。 まさに「神は細部に宿る」のである。
で。 私も編集長も、 実は、そういう仕事が大好きなのである。
神さま。今回も楽しく有意義な読み合わせの時間をありがとうございます。 神さま。あなたは祈りを聞いてくださる方。 10年前、強い風が吹き抜ける井の頭線の吉祥寺のホームで祈った、 「本を書かせてください」という祈りをあなたが聞いてくださり、 私の想像を越えた形で成就してくださることを心から感謝します。
いま、私は大いなる主をあかしいたします。 あなたは約束をたがえない方です。 あなたは祈りを聞いてくださる方です。 あなたはもっともよい恵みをいつも与えてくださる方です。 まことにあなたはほむべき方です。 イエス様、あなたに感謝します！
この小さき祈り手が、いつも初心を忘れず、 読者のことを忘れず、またあなたの恵みと哀れみを忘れずに、 謙虚な思いで仕事をすることができますように。 時がよくても悪くても、熱心に祈り、家族に感謝し、 支えてくださる多くの人々に感謝して、日々を歩むことができますように。
今回の本もあなたが完成させてくださり、必要な読者に本書を届けてください。 あなたに栄光をお返しいたします。 賢明に仕事をなさっている編集長さん、それに組版の方、デザイナーさん、 営業・販売・広告の方、 多くの関係者の上に、神さまの祝福が豊かに・あふれんばかりにありますように。 ひとりびとりの手の業が主によって導かれ、 ほんとうに「よいもの」を生み出すことができますように。 そしてまた何よりも、一人でも多くの方が、イエスさま、あなたを知ることができますように。
あなたにすべてを感謝し、イエスさまのお名前で祈ります。
アーメン！ 感謝します！
[WB] 新しい書籍に関する打ち合わせ。 編集者さんが熱心に聞いてくださるので、 本を書くことについてついついアツく語ってしまう。 申し訳ないです。
[NC]原稿書き書き。
[PI]原稿書き書き。
質問
前々から気になっていたのですが、「読み合わせ」ってどんな作業をされるのですか？
回答
読み合わせというのは、編集者と一室にこもって、 書籍のゲラを一ページ一ページめくりながら、 微妙な疑問点の確認を行ったり、 間違いやすい指示を徹底したりする作業です。 初校と再校の2回やります。 読み合わせまでには編集者と著者の朱入れは済んでおり、 著者から編集者への情報伝達は朱を入れた校正紙で用はほとんど足りるのですが、 「読み合わせ」は面と向かわないとできない種類の情報交換の場になります。 読み合わせにかかる時間は、 短いときには2〜3時間、長いときには6時間くらいでしょうか。 編集者や著者によって進め方や呼び名は違う可能性があります。 そもそも読み合わせを行わない編集者や著者もいます。
私は経験的にこの「読み合わせ」は書籍の品質を上げるために重要なステップだと思っています。
[CR] 読み合わせに向けて校正と索引のマーカ付け。三巡目。 これっていい本だ。感謝。
[NC]原稿書き書き。
[PI]原稿書き書き。
いろいろなことがあった一日。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。
何かの理由でうまく送れない場合にはメール hyuki@hyuki.com でお願いします。