<前の日記(2011年05月15日) 次の日記(2011年05月27日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 112   昨日: 2746

2011年05月22日

榎並利博著「共通番号(国民ID)のすべて」を読んだが

前回の日記で参照した、消えた富士通総研のコラムの著者、榎並利博氏の著書「共通番号(国民ID)のすべて」(2010年12月発行)を読んでみたところ、消えたコラムと同様の問題のあるものだった。いくつかかいつまんでそれを示す。

たとえばp.24、ここは「住基ネット反対論拠の崩壊」という節の一部で「代替手段(名寄せ)がある」という見出しの部分。見出しから想像するに、「どのみち住所氏名等で名寄せできるのだから、番号による名寄せの危険を挙げる反対論など馬鹿げている」という主張かと思ったら、そうではなかった。ここに書かれていることは、

実はどのような優秀なプログラムを作成しても、技術的に「名寄せ」は不可能なのである。しかし、その事実が正しく取り上げられず、報道されなかったことは非常に残念である。他の例でも同じであるが、実際に被害が起きてはじめてやっと気づくのである。

この「名寄せ」の不可能性については、残念なことに国民の犠牲という大きな被害を伴って証明されてしまった。2007年5月以降、年金の納付記録問題で名寄せの問題が顕在化し、持ち主のわからない年金の納付記録が大量に発覚することとなった。(略)日本人の氏名を正しくコンピュータで管理・表現することは技術的に不可能なのである。

共通番号(国民ID)のすべて, 榎並利博, 東洋経済新報社

という内容になっている。書いてあることはその通りだが、それがいったいなぜ「住基ネット反対論拠の崩壊」なんだ?と疑問に思いつつ読み進めると、続いて次のように書かれている。

この年金問題は、台帳による裏付けのない基礎年金番号という番号が、いかに国民に不利益をもたらすものであるかを証明することになった。そして「名寄せ」という手段があるから共通番号は必要ないという反対派の論拠が一挙に崩壊したのである。

共通番号(国民ID)のすべて, 榎並利博, 東洋経済新報社

お前は何を言っているんだ。

「反対派」が言っていた名寄せの問題というのは、「分野をまたがっての名寄せが共通の番号によって容易になってしまう」という指摘であって、「名寄せという手段があるから共通番号は必要ない」などという意味不明な主張は聞いたこともない。

何を混同してこうなったのかよくわからないが、いずれにせよ、正しくは次の通りである。

年金をめぐるその問題から言えることは「初めから番号で管理しておく必要がある」ということである。その番号は年金専用の番号であれば十分であり、他分野と共通の番号である必要はない。ただし、同じ人が複数の年金番号を持つことがない(番号の唯一無二性)よう、何らかの手段でそれを保障する必要がある。それを各分野で手作業で実現すると多大なコストとなることから、たとえば、住民票コードが既に番号の唯一無二性を実現しているのであれば、住民票コードを基にした何らかの方法で、年金番号の唯一無二性を実現することが可能である。それは必ずしも、年金番号と住民票コードを同一にする必要性はない。

今、内閣官房で設計中の「情報連携基盤」は、住民票コードの唯一無二性を借りて生成する「IDコード」を基に、各分野に別々の「リンクコード」を払い出す方式で実現されようとしている。これにより、住基ネット騒動のときに懸念されていた、「分野をまたがっての名寄せが共通の番号によって容易になってしまう」との指摘に対し、配慮した仕組みとなっていると言える。*1

これまで、「分野をまたがっての名寄せが共通の番号によって容易になってしまう」との懸念に対し、推進派(プライバシー軽視派)が「どのみち住所氏名等で名寄せできるんですよ」と主張することが多々あった。それに対するプライバシー擁護派の反論は、「共通番号が生まれることによって名寄せにかかるコストが格段に小さくなる」ということになるわけだが、このことは、まさに、榎並氏の言う通り、「どのような優秀なプログラムを作成しても、技術的に『名寄せ』は不可能なのである」、「日本人の氏名を正しくコンピュータで管理・表現することは技術的に不可能なのである」という理由を背景としている。

つまり、榎並氏は、プライバシー擁護派に対して「論拠が一挙に崩壊」と言ったつもりが、実は、プライバシー擁護派の論拠を補強することを書いているわけである。何重にも理解が足りてないと評せざるを得ない。「反対派」を馬鹿と決めつけたいばかりに「反対派」の馬鹿な主張ばかり見ているから、こうなったのではないか。

次に、たとえばp.89、「共通番号とIDの問題」という節は、以下の書き出しで始まっている。

よく番号の問題とIDの問題が混在し、番号がばらばらならばOpenIDやSAML2.0でIDを統合すれば良いではないかという議論が起こることがある。

共通番号(国民ID)のすべて, 榎並利博, 東洋経済新報社

榎並氏は「フラット派」(すべての情報保有機関や分野で共通の番号を用いる方式を推す人々)なので、この書き出しからすると、この節はフラット方式でなければならない理由を書いてくれるのかと期待して読んだのだが、そういうことは書かれていなかった。書かれていることは以下の内容である。

OpenIDおよびSAML2.0とは、どちらもウェブサイトにおけるシングル・サイン・オンを実現する技術のことである。インターネットで行う宿泊予約、図書館蔵書の予約、飛行機の予約など、すべて異なるIDとパスワードをそれぞれの画面で入力して操作するのはとても不便を感じる。だから一回のIDとパスワード入力ですべての処理が操作できるシングル・サイン・オンの機能があれば便利だと誰もが思うだろう。そのような便利さを追求するのは構わない。(略)しかし、これは番号の問題ではない。

もう少し詳しく解説しよう。情報技術にあまりこだわらない方は読み飛ばしていただいて構わない。(略)まとめると、(略)専門的に言えば、情報システムの利用を可能とするために、識別(アイデンティフィケーション)・認証(オーセンティケーション)・認可(オーソライゼーション)というプロセスを経るときに使われるものがIDなのである。この意味からいえば、行政で利用される共通番号とはアカウントの実体(アカウントそのものではない)であり、IDではない。

共通番号(国民ID)のすべて, 榎並利博, 東洋経済新報社

何を言っているのかよくわからないが、この節を最後まで読んでも、期待したことは書かれていなかった。これは要するに、以下のようなことになっているのだろう。

番号制度の議論では、「フラット方式」(すべての情報保有機関や分野で共通の番号を用いる方式)か「セクトラル方式」(情報保有機関や分野ごとに別々の番号を用いる方式)かという論点があるところ、榎並氏は「フラット方式」を推す「フラット派」である。「フラット派」の一部には、「セクトラル方式」に対して「そんなことが本当に実現できるのか」と疑念を抱く情報技術に疎い人々がいるので、「セクトラル方式」を推す人々は、「OpenIDやSAMLでそれが実現できる」と説明をすることになる。

OpenIDやSAMLを用いれば、ID変換によって個別の番号(PPID)を払い出すことができ、情報保有機関や分野ごとに別々の番号を用いることができるので、「共通の番号による名寄せが容易になる」というリスクを回避することができる。それが「セクトラル方式」によるプライバシー配慮の仕組みである。

番号制度の議論においてOpenIDやSAMLの話が出てくるのは、そういう文脈であるにもかかわらず、榎並氏は、「OpenIDやSAMLはシングルサインオンを実現する技術だ」と頓珍漢なことを言っている。

たしかに、SAMLが単なるシングルサインオン実現用途でしか普及していないという現実はある。Liberty Allianceが当初目指した「プライバシー保護のためIDを別々にする」*2という目的は、技術的には既に達成したものの、そうした用途での普及(一般Webサイト間の連携用途での普及)は進まず、企業内での利用(ユーザIDがバラバラの既存の社内システムを統合して、シングルサインオンを低コストで実装する用途での利用)にとどまっているという現実がある。榎並氏は、SAMLをそういうものとしてしか理解しておらず、元々の趣旨を知らないのではないか。*3

プライバシー擁護派は「番号はばらばらであるべきである」と言っているのに、榎並氏はそのことを指して、「番号がばらばらならばOpenIDやSAML2.0でIDを統合すれば良いではないかという議論」とねじ曲げて解釈している。意図的にねじ曲げているのでないならば、技術への根本的な理解が足りていないと評せざるを得ない。

この本の読者は、「情報技術にあまりこだわらない方は読み飛ばして」とか「専門的に言えば」と書かれているのを見て、「ああ、この著者は情報技術の専門家なんだな」と思ってしまうであろうから、注意が必要である。

他にも突っ込みどころは多々あるが、きりがないのであと1つだけ。最後の章に「個人情報を活用した地域における景気対策」という節があり、次のように書かれている。

個人情報保護法が制定されて以来、個人情報に対する過敏な反応が広まっており、個人情報を利用することが悪であるかのような雰囲気さえある。個人情報を悪用することが社会的に問題なのであって、個人情報を使うことが悪いわけではない。(略)

例えば、自治体の例を考えてみよう。自治体は住民の個人情報を保有しているが、それを利用して地域における景気対策を実行することもできるはずだ。(略)

住民情報を活用した景気対策とは、民間企業がダイレクトメールを発送するにあたり、自治体が保有する住民情報を活用することで、有効かつ的確なダイレクトメールの発送が可能となり、地域の消費マインドを高めることで経済の活性化を図ることができるというものである。(略)

民間事業者は、ダイレクトメールのサンプルと申請書を自治体に提出し、その内容を自治体が審査する。審査基準については自治体が独自に設定すればよい。(略)など、好ましくない事業者の参加や個人情報の流出を避けることを目的とした審査基準を作ればよい。(略)

民間事業者にとっては、行政が保有する住民情報が利用できるため、性別・年齢だけでなく年収区分や家族構成に適したダイレクトメールを送付することができるため、通常よりも大きな効果が見込まれる。また、住民の個人情報は自治体が取り扱い、自治体が条件抽出した宛名シールを貼付するため、民間事業者は個人情報に一切触れることなく、住民のプライバシーは保護される。自治体にとっては、事業の費用を民間事業者が負担するため、財政支出が不要であるというメリットがある。(略)

共通番号(国民ID)のすべて, 榎並利博, 東洋経済新報社

これを是とするか非とするかは、国民が判断することであろうから、私はあえて何も言わないが、榎並氏はそういう立場の人だということであろう。この本のAmazonでの書評では、星5つを付けた読者レビューでさえ、この部分への違和感が書かれている。なぜこの提案が嫌われるのか、榎並氏は知る由もないのだろうか。

ところで、前回の日記で参照した消えた富士通総研のコラムで、「諸外国を参考とした番号制度モデル比較論と社会情報学の役割」という榎並氏の論文(日本社会情報学会第25回全国大会、2010年9月)が参照されていたので、これも読んでみたところ、やはり同様に問題があり、特にこの文献では問題が顕著になっている。

この論文の書き出しは、

1.はじめに

社会情報学とは何か、明確な定義は確定していないが、一つの考え方として情報技術と社会制度の間を橋渡しする領域における学問であると位置づけることが可能であろう。社会システムの制度設計にあたっては、制度側からすれば情報技術に依存し、情報技術側からすれば制度に依存する傾向にある。相手に対する知識が乏しい状況において、相手方へ依存することは、大きな誤謬を招き、社会システムを破綻させる可能性がある

(略)番号制度の設計においては、行政学及び公共政策学的な見地のほか、情報工学および情報システム学などの知識が必要となることは無論のこと、両者が重なり合う領域を対象とした社会情報学的な見地が必要である。

本論文では、番号制度の検討における情報連携というテーマを社会情報学的な見地によって分析する。そして、日本が採用すべき番号制度として、先行研究ではセクトラルモデルを推奨しているが、本研究ではフラットモデルを採用すべきこととを主張したい

2.先行研究における最適モデルの方向性

(略)

このようにほとんどの研究が、国民の不安感に対処するため、統一番号を回避するか、フラットモデルではなくセクトラルモデルを採用すべきとの方向性を持っているのが現状である。これらの研究は、行政学・公共政策学的な見解、および情報工学・情報システム学的な見解としては評価できる。しかし、両者が重なり合う社会情報学的な視点から見たとき、限界があり、より有効な方法が求められる。

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

となっている。「フラットモデルを採用すべき」とし、その論拠として、セクトラルモデルを推す従来研究は「社会情報学的な見地」を欠いているという主張のようだ。「制度側からすれば情報技術に依存し、情報技術側からすれば制度に依存する」ため、「大きな誤謬を招き、社会システムを破綻させる」という。

では、榎並氏の言う「社会情報学的な視点から見たとき」のセクトラルモデルの問題点とは何だろうか。これは、第6節の「両モデルに対する各立場からの視点とその問題点」で、以下のように書かれている。

(1)行政学や公共政策学からの視点(政策担当者)

国民の不安を解消し、政策を推進することを第一義とするため、次のような視点を持つ。

  • 国民の不安を解消するために、セキュリティが技術的に100%完璧であることを求める。
  • セキュリティ技術の完璧性を前提としているため、問題が発生した場合の国民保護の仕組み(第三者機関の設置など)については消極的である。あるいは組織の権限を外部から規制されたくないという組織拡大志向を持っている。

それゆえ、オーストリア方式については、複雑な技術を駆使しているため完璧に見え、かつ国民の不安を解消させるツールとしても有効であると判断する。実施後問題があれば、政策的な問題ではなく技術的な問題としてすり替えが可能である。

(2)情報工学や情報システム学からの視点(専門家)

情報工学の立場からは次のような視点を持つ。

  • 100%安全で完璧なセキュリティ技術などあり得ない。しかし、100%に少しでも近づけることが情報工学としての技術的使命であると考えてしまう。
  • オーストリア方式については、技術的な整合性に問題があるかどうかを判断する。

それゆえ、オーストリア方式については、技術論的な整合性がとれているため、良い方式であると判断する。実施後問題があれば、技術的な問題ではなく行政実務の問題としてすり替えが可能である。

ここで両者の問題点について検討してみる。行政学および公共政策学からの視点においては、100%のセキュリティが担保されれば、そして国民が納得すればそれで問題が解決したと錯覚することにある。少なくとも、オーストリア方式の複雑なセキュリティ技術ばかりを注目してしまうため、技術的な運用可能性について見落としてしまう。行政実務と情報システムの関係性について知識が無いために、無関心になってしまうことが原因である。(略)

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

このように、ここでもまた榎並氏は「皆が無知だからそういう選択になる」という論を展開しているが、無知が原因であるなら、知識を与えて設計させればよいのであって、それ自体が方式の問題ということにはならない。

そればかりか、やはりここでも、番号を別々にする方式の意義を「セキュリティ技術」と位置づけており、ID変換による連携方式の本来の意義を理解していない(前回の日記で指摘した通り)わけで、基礎的な知識を欠いたままこの論を展開している。たとえば、第7節の「社会情報学的な見地からの考察:フラットモデルについて」では、フラットモデルの課題として以下の点のみを挙げている。

7.社会情報学的な見地からの考察:フラットモデルについて

フラットモデルは、個人情報の収集や「なりすまし」という問題があり、これにどう対処していくかが課題となる。

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

番号を情報保有機関あるいは分野ごとに別々とする方式は、「国家による一元管理の懸念」への配慮であるのに、この点をフラットモデルの課題に挙げていない。

続く第9節には、こんな記述もある。

9.日本がとるべき道 ― 採用すべきモデルと不安解消装置のあり方

結論として、日本が採用すべきモデルはシンプルな設計でシンプルに運用できるフラットモデルが最も望ましい。(略)

(略)過度に複雑な仕組みや高度な技術に頼ることは、かえって危険であり、次の問題を招く。

(1)トラブル時の対処ができない

(略)

(2)複雑さの罠によってパニックを起こす

複雑な仕組みや高度な技術を使っていると安心だと思い込んでしまうことが問題である。技術とは完璧なものではない。常に様々なトラブルを想定して、システムの停止を回避する設計を行い、国民の不安感を解消する制度を作らなくてはならない。複雑な仕組みや高度な技術を使っているから安心だという理由で、第三者機関や国民自らによる監視の仕組みをおろそかにしてしまうことは非常に危険である。

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

「思い込んでしまうことが問題」なら、思い込まないようにすればいい話なわけだが、そもそも、OpenIDやSAMLのPPIDのような仕組みが「高度な技術」というほどの複雑なものなのか。現に広く普及しつつある技術なのだが、富士通の技術力ではパニックを起こすよとでも言わんとしているのだろうか。

その他、明らかにおかしな点としては以下の記述がある。

(略)分野別PIN(28桁の英数字)を生成するには、「文字列拡張→SHA-1でハッシュ化→Base64標準でコード化」という手順で行われる。このように、かなり処理負荷の高いアルゴリズムの計算を行わなければならない。

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

SHA-1やBase64が「かなり処理負荷の高いアルゴリズム」だそうな。(富士通のシステムエンジニアにはそう見えるのか?)

そして最後はこう締めくくられている。

おわりに

これまでに述べたように、一見セキュリティが高く運用が可能に見えるセクトラルモデルも、社会情報学的見地から見るとあまりにも問題が多いことがわかる。社会情報学的な立場で考えれば、日本の番号制度はセクトラルモデルではなく、制度と技術による保護手段を講じてフラットモデルを採用するべきである。

今回扱った番号制度の検討における情報連携というテーマでは、「複雑さの罠」という知見を導き出した。ある事象が複雑であると、リスクが少なく見える。しかし、リスクはゼロではないため、リスクが発覚すると、事象の複雑さのためにリスクの算定が不可能となる。それゆえリスクを過大に評価して、パニック状態となる。サブプライム・ローンなどはまさにその例であり、セクトラルモデルの採用はまさにその二の舞と言って良いだろう。

(略)

榎並利博, 諸外国を参考とした番号制度モデル比較論と社会情報学の役割, 日本社会情報学会第25回全国大会論文集, pp.291-296

「社会情報学」というのはこんなものを言うのだろうか?

この種の議論に関わっていていつも思うのは、論者の階層が以下の図のようになっているなということ。

図
図1: 世論と論者の階層構造

第一層の平凡な一般市民らは、直感的に懸念をなんとなく抱いている。しかし、専門家ではないが故に、その直感的する懸念がどういうものなのかを理論立てて説明することができない。中には、その根拠を取り違えて、不適切な論拠でもって不安を訴える人もいる。

第二層の論者は、そうした第一層の一部の「不適切な論拠」をあげつらって、そういう不安は無知からくる杞憂だという論を展開する。しかし、第一層が直感的に抱いている懸念の本当の理由は、第二層の論者があげつらう点にあるのではなく、それが何かを第三層が解説するという構図である。榎並氏は第二層の論者で、私は今、第三層の作業をしているところと言える。

制度設計に限らず、専門家がする議論は、結論ありきでの「為にする議論」であってはならない。客観的に言える点を羅列するのが専門家の仕事で、主観的にしか決まりようのない部分*4を、国民世論に問い、政治決断を仰ぐ。

榎並氏は、どういうわけか、何がどうあれ「フラットモデル」という結論を導きたいがために、「複雑さパニック」などという無理のある論を組み立てようとしている。為にする議論という点で、櫻井よしこ氏ら「反対派」と同格と評せざるを得ない。

ところで、消えた富士通総研のコラムでは、NPO法人東アジア国際ビジネス支援センターによる「情報連携基盤技術WGの骨格案に関する疑問点・危惧点」という文献も紹介されていたので、それも読んでみた。

これは、

2010年3月4日に開催された情報連携基盤技術WG第2回会合にて、社会保障・税に関わる番号制度及び国民ID制度における情報連携基盤技術の骨格案(その1)が示された。

EABuSでは、有志を中心にその内容を仔細に検討したところ、以下の疑問点・危惧点を抱いた。国民番号制度は、今後の社会インフラにあたる重要な検討事項であることから、我々の疑問点・危惧点について当ホームページを通じて公表し、国民番号制度の健全な構築に向けた建設的な論議を呼び掛けたい。

情報連携基盤技術WGの骨格案に関する疑問点・危惧点, NPO法人東アジア国際ビジネス支援センター

という趣旨のもので、良い指摘もあるのだが、いくかの指摘はおかしいので、それを示しておく。

(1) 住民票コード(+4情報)、共通番号、ID コード、リンクコードといった複雑な番号体系がなぜ必要なのかが不明。個人情報保護に対する過剰反応のためかも知れないが、単に技術的な「屋上屋」的議論を重ねているだけではないか?

情報連携基盤技術WGの骨格案に関する疑問点・危惧点, NPO法人東アジア国際ビジネス支援センター

なぜ必要かが「骨格案」に書かれていないのはその通りだが、「単に技術的な「屋上屋」的議論を重ねているだけ」という指摘は誤り。本来の設計趣旨が正しく書かれていないだけなので、正しく書くようにすればよい。

(2) 上記システムの維持のためには、情報保有機関ごとでリンクコード―利用番号への紐付けテーブル、突合のための基本4情報の逐次メンテナンス、情報連携基盤におけるIDコード―リンクコード間の変換といった膨大な作業が要求されるが、適正な費用対コストが保たれるのか?

また、基本4情報の一意性(漢字コード等)維持をどのように実現し維持していくのか?(そもそも識別番号は4情報による名寄・突合に代わるものではないのか)

「番号」―リンクコード間の紐付けは住基4情報の突合によって各情報保有機関が「対照テーブル」を作成、保守することになっているが、保守については利用者の異動情報を住基ネットから配信することを想定するのか。あるいは、各情報保有機関の努力に期待するのか。また住基4情報突合において氏名や住所に含まれる外字はどのように解決するのか。

情報連携基盤技術WGの骨格案に関する疑問点・危惧点, NPO法人東アジア国際ビジネス支援センター

「突合のための基本4情報の逐次メンテナンス」が必要という理解が誤り。情報保有機関ごとでリンクコードを利用番号へ紐付けるために基本4情報による突合を行うのは、情報保有機関が情報連携基盤に参加する際に、最初に1回行うだけであり、その後は「リンクコード」によって個人が識別されるので、基本4情報の「逐次メンテナンス」は不要。新生児は、出生届の際に「IDコード」が割り当てられ、各情報保有機関は、情報連携基盤から払い出される「リンクコード」によってその個人を識別する。

また、「情報連携基盤におけるIDコード―リンクコード間の変換といった膨大な作業」というが、それは機械が自動処理する部分なので、「膨大な作業」という指摘は誤り。

「識別番号は4情報による名寄せ・突合に代わるものではないのか」というのはその通りであり、「基本4情報の一意性(漢字コード等)維持」は不要。ただし、情報連携基盤に参加する際に1回だけは必要。

「外字はどのように解決するのか」等は、既存のデータを使う以上、どのようにしても避けられないことであり、情報連携基盤に参加する際に1回だけは必要な作業。

(4)(略)

また、「可逆暗号方式」とは双方向のコード変換を可能にした方式のため、行政内で個人情報を自由に連携させ、それを利用することも可能な仕組みである(オーストリアで採用している方式は不可逆暗号方式である)

この方式では、情報照会元機関が自己のリンクコードからIDコードに変換することによって、どの情報保有機関にも照会可能と思われるが、目的外使用防止のために情報連携基盤ではどのような措置をとるのか。5(1)では「予め法律またはこれに基づく政令によって、情報連携を行う目的、情報連携を行う情報保有機関及び情報連携の対象となる個人情報の種類および情報連携のパターンについて、明確に定めておくべきではないか。」としているが、このことは法制度だけでなく、情報連携基盤の機能として実装するべきである。

情報連携基盤技術WGの骨格案に関する疑問点・危惧点, NPO法人東アジア国際ビジネス支援センター

不可逆変換方式を採用して本人による操作がなければ機械的な情報連携ができないようにするという案もあり得るところ、現在の政府案では、法令で定められた用途に限り、個別の本人同意を得ずに情報連携するという設計になっている。*5

オーストリアがどうかと関係なく、日本の政府はこの方式を選択しているところで、法令で定められた情報保有機関への照会しか認めない制御を、情報連携基盤の機能として実装することになっている様子なので、「どの情報保有機関にも照会可能」というわけではなく、「行政内で個人情報を自由に連携させ、それを利用することも可能な仕組み」なわけではない。

(6)「セキュリティ確保のためIDコード・リンクコードは各個人に通知しない」としているが、これは、個人の情報に関する番号が国民の立ち入れない世界で交換されるという、極めて不透明な仕組みになりかねない

セキュリティ確保の重要な観点は技術的完全性ではなく、透明性の担保であり、欧州で実現しているような「見える番号」に対するアクセスポリシーと樹立と、国民監視の仕組みを構築することが何よりも優先されるべきと考える

情報連携基盤技術WGの骨格案に関する疑問点・危惧点, NPO法人東アジア国際ビジネス支援センター

「極めて不透明な仕組み」というが、IDコードやリンクコードがどのような方式で生成、利用されるものであるかは、既に骨格案で公表されている*6わけで、各個人のコードの具体的な値が本人に知らされないと「不透明な仕組み」だと断ずるのは、意味不明と評せざるを得ない。

番号のプライバシーへの影響は一般に、「見える番号」であるほど、番号が共通して広範囲で使われるほど、番号の使用期間が長いほど、問題がある。見えない番号、かつ、内部でしか使われない番号は、それ自体がプライバシーの問題を生じさせるわけではない。

「セキュリティ確保の重要な観点は技術的完全性ではなく」というが、そもそも誰もそんなことをしようとしていない。(「骨格案」がそう誤解させる誤った記述になっていたという事情はあるが。)

以上。

*1 ただし、「社会保障と税の番号制度」においては、「情報連携基盤」を前提としつつも、税分野と社会保障分野に限って共通の番号としようとしている。本来はそれらも別々の番号でよいはずであるが、何らかの利便性を想定したものか、あるいは何らかの政治判断によるものなのだろう。今、政府で検討が進められている方式は、いわば、分野毎別々番号方式と部分的な共通番号方式とのハイブリッド方式になっている。この部分的な共通番号方式を認めるかどうかは、世論の分かれるところであるはず。

*2 世界中のWebアプリケーションのログインIDがMicrosoftのPassportに一点集約されかねない事態が生じ始めたため、それに対抗して、IDを別々にできる方式の標準化が始まったという経緯がある。

*3 実務経験を自負するシステムエンジニアが、技術の基礎原理を理解していないという場面には、私もしばしば出くわしたことがある。

*4 「国家による一元管理」を懸念として重視するか軽視するか、税と社会保障の分野に限って番号を共通とするのは是か非かなどの選択のこと。

*5 ここは、主観的な選択の余地のあるところで、「法令によるバルクの許可ではなく、本人同意の下で情報連携すべきである」という対立意見があってもよいところ、既に、政治判断により、このような設計が進められている。

*6 仕組みが公開されても複雑すぎて意味がわからないというのであれば、誰かがちゃんと国民にわかるように解説を出せばよいことであり、「自分がわからないから」では理由にならない。

本日のTrackBacks(全4件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20110522]
検索

<前の日記(2011年05月15日) 次の日記(2011年05月27日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2011年05月15日) 次の日記(2011年05月27日)> 最新 編集