高木浩光＠自宅の日記

■ 技術音痴なIT企業CTOが国のWGで番号制度の技術基盤を歪める

非公開で進められている（傍聴が許されていない）「情報連携基盤技術WG」の配布資料を入手した。しかも、この「情報連携基盤技術WG」には、存在自体が非公表のサブWGがあり、その構成員は、「情報連携基盤技術WG」から中立の有識者らを除いた、ベンダーの人々だけの集まりになっているらしい。入手した資料は、そうしたベンダーの構成員から今月提出されたもののようだ。

入手した資料のうち、一つは重大な問題のある文書であり、他にもう一つ、問題のある文書があった。

「番号制度」は、推進派に言わせれば「国家百年の大計として国の礎を作ることに他ならない」という*1ものであり、ベンダー試算によれば何千億円もの国家予算が必要と言われているものである。しかも、その方式設計は国民のプライバシー影響を左右する重要なものであって、一度不適切な方式を普及させると後戻りのできないものである。

このような重大決定に差し掛かっている「情報連携基盤」の設計において、技術論として完全に誤った情報がWGに注入されつつある。ここでこれを見逃したら、また何千億円もの金をドブに捨てることになりかねないので、ここで指摘しておきたい。

背景

問題を理解するには、「情報連携基盤」がどういうもので、どういう議論がなされてきたかを把握する必要があるので、以下簡単に示す。

「情報連携基盤」は、国民に唯一無二で悉皆な番号を割り振って各行政事務で活用するに際して、一人に一つの番号をすべての行政事務で共通にして使う「フラットモデル」は避けるべき*2であることから、必要とされている仕組みであり、「情報連携基盤」は、各「情報保有機関」に対して、それぞれに別の値となる「リンクコード」を払い出す。

すなわち、ある国民 X の識別子は、情報保有機関Aにおいてはリンクコード Xa であり、別の情報保有機関Bにおいてはリンクコード Xb となるもので、情報保有機関Aが、情報保有機関Bで保有されている国民 X の情報を（法令に基づいた行政事務において）必要とする場合、情報保有機関Aがリンクコード Xa を情報連携基盤に送信し、情報連携基盤がそれを（何らかの方法で）変換して Xb の値を得て、それを情報保有機関Bに指示して、情報保有機関Bが保有する国民 X の情報を提出させるという仕組みである。

これにより、情報保有機関AとBの権力者が結託して両者の保有する情報を突合しようとしても（情報連携基盤が結託しない限り）、直ちにはできないようにする*3ことができる。「国家による一元管理」の防止はこの仕組みによって担保されるというわけである。

これを図で表すと、以下の図1のようになる。これは、3月の段階で示されていた「骨格案」のものである。

図1: 情報連携基盤技術ＷＧ（第5回）資料3-2「番号連携方式検討表」より

このような「情報連携基盤」の実現方式には、これまでにいくつかの論点があった。

3月の時点で示されていた「骨格案」では、データ（国民の「属性情報」）がすべて、この「情報連携基盤」を通るというものであった。データのすべてが「情報連携基盤」を通るなら、「情報連携基盤」が一元管理の可能な組織となってしまうので、「国家による一元管理」の防止が達成できないのではないかという指摘があった。

このことは、3月26日の堀部政男情報法研究会の第4回シンポジウムのパネル討論で、私も資料を提出して、問題提起している（図2）。

図2:「パネル討論 論旨」より

また、4月12日の情報連携基盤技術WGにおいて山口英委員から提出された「情報連携基盤技術に関する質問／情報連携基盤に関する個人情報保護に関する質問」においても、次のように指摘されている。

【質問先】
骨格案（その1）7ページ
5.(4) 情報連携の手順

【質問】
「照会先情報保有機関においては、当該リンクコードに係る個人の情報連携対象個人情報を付して、情報連携基盤を通じて照会元情報保有機関に対して、回答すべきではないか」とあるが、照会先情報保有機関から照会元情報保有機関への個人情報の回答方式としては、情報連携基盤を通さずに直接回答する方式もあり得るところ、それを採用しない理由は何か。

【趣旨】
確かに、政府基本方針には、「番号制度構築に当たっては、各機関間の情報連携は情報連携基盤を通じて行わせることにより、情報連携基盤がデータのやり取りの承認やアクセス記録の保持を行い（略）個人情報保護に十分配慮した仕組みとする」とあるが、この「通じて」という記述は、個人情報のデータそのものを情報連携基盤を通じさせるとは書かれておらず、「データのやりとりの承認」を情報連携基盤を通じてしていれば、「情報連携基盤を通じて行わせることにより（略）個人情報保護に十分配慮した仕組み」としたことになるのではないか。したがって、情報連携基盤を通さずに直接回答する方式の採用を排除する理由がない。

【想定される答え】
ご指摘の通り、理由がないので、情報連携基盤を通さずに直接回答する方式も選択肢として残すよう修正する。

---

【質問先】
骨格案（その1）7ページ
5.(4) 情報連携の手順

【質問】
3. 情報連携の手順として、情報連携基盤において個人情報そのものは保存しないようにするとした点について

情報連携の手順は、まず、照会元の情報保有機関が、情報連携を行う対象者のリンクコードを用いて情報連携基盤に問い合わせ、次に、情報連携基盤が、当該照会に係る情報連携の内容が法令によって許可されているものか確認した後に、照会先情報保有機関のリンクコードを生成して、当該照会先情報保有機関に当該リンクコードを伝達し、最後に、照会先情報保有機関が対象個人情報を情報連携基盤を通じて照会元情報保有機関に対して回答するというものであるが、このとき、保護適合要件を満たすために、情報連携対象の個人情報は、情報連携基盤を通じて回答がされることにとどめ、情報連携基盤においては保存されないようにすることを検討しているところであるが、この判断は必要かつ十分なものか。

質問3の1
個人情報を情報連携基盤を通じて回答する際に情報連携基盤に保存されないようにすることは、保護適合要件を満たすために十分なものと言えるか。
（略）

【想定される答え】
質問3の1への回答: 十分でない。
理由: 最高裁判断枠組みに適合するためには、個人情報を一元的に管理することができる機関又は主体が存在しないことが必要である。情報連携の際に、情報連携対象の個人情報が情報連携基盤を通じて回答されるのであれば、情報連携基盤の運営機関は、当該個人情報を記録することが可能となるのであり、その個人情報はIDコードと紐付けて記録することも可能である。したがって、情報連携基盤が個人情報を保存しないようにするというだけでは保護適合要件を満たすのに十分でなく、照会先情報保有機関は、情報連携対象の個人情報を情報連携基盤を通じることなく照会元情報保有機関に回答するようにするなど、何らかの技術的解決策が必要である。
（略）

情報連携基盤技術に関する質問／情報連携基盤に関する個人情報保護に関する質問

その結果、6月7日の情報連携基盤技術WGにおいて、以下の図3のような資料が用意され、「ゲートウェイ方式（案1）」と「アクセストークン方式（案2）」の二つが検討されることとなった。

図3: 情報連携基盤技術ＷＧ（第5回）資料3-3「データ送受信方式検討表」より

「案2」のアクセストークン方式は、データ（属性情報）が情報連携基盤を通らない方式であり、「国家による一元管理」が可能となる組織が生まれないようにする方式である。

3月時点の骨格案で予定されていたゲートウェイ方式（案1）では、たとえ「データを直ちに消去するようにする」（保管しないようにする）としたところで、組織単独での権力者の意向により「一元管理」が可能な状態となる*4。最高裁判断枠組みから求められていることは「一元管理できない」ことであり、「一元管理しない」ということとは違うのだから、「直ちに消去するから」では言い訳にもならない。

日本IBM長島哲也CTOの主張

今回入手した資料の一つ「第5回情報連携基盤技術ワーキンググループ開催時に配布された資料に関する意見」は、6月17日付のもので、著者は「情報連携基盤技術ワーキング・グループ構成員 長島哲也」とある。

この意見書には、「1.情報連携方式と番号連携方式の関連性と取り得る組み合わせについて」として、次のように書かれている。

（略）骨格案や要綱、個人情報保護WGの意見をまとめると番号連携機能や情報連携機能に対して下記「要件または制約」が課せられると認識する。

要件1: 「番号」を用いた情報連携をしてはいけない
要件2: 他情報保有機関が利用している「符号」と、自情報保有機関が利用している「符号」を一元的に管理してはいけない

これら番号連携機能や情報連携機能に関しての「要件または制約」を加味した上で、第5回情報連携基盤技術ワーキンググループで提示された「情報連携基盤構築に当たっての論点整理」（資料3-1、資料3-2、資料3-3）中の番号連携方式（【案1】~【案5】）、および、情報連携方式（【案1】「ゲートウェイ方式」、【案2】「アクセストークン方式」）について、システム設計における両方式（番号連携方式と情報連携方式）の実現可能性や関連性について検討した結果、実現可能性に関する懸念や両方式間の関連性が及ぼすシステム構築上の要件が発見されたため、ここに報告する。

長島哲也, 第5回情報連携基盤技術ワーキンググループ開催時に配布された資料に関する意見, 2011年6月17日

さて、どんな「発見」をしたというのだろう。

この意見書は「＜アクセストークン方式による情報連携の検討＞」として、以下の主張をしている。

図2の吹き出しに記載したように「要件2」で指摘されている「リンクコードaとリンクコードbが同時に同一情報保有機関で保有してしまう危険性」や「リンクコードaとリンクコードbが同一情報保有者である事を示す情報を当該情報保有機関以外のどこかに保有しないと処理が完結しない」問題点が発生する。しかし、同一情報保有者である事を示す情報、すなわち、リンクコードaとリンクコードbを同時に保有する事自体が「要件2」に抵触する。また、図1中の仮名IDに「番号」を指定する事も考えられるが、これは「要件1」に抵触する。また、仮名IDにIDコードを指定する事も考えられるが、個人情報保護ワーキンググループの意見では、IDコードそのものも「個人を特定するID」や「IDを暗号化した符号」と認識する委員が多かった事を踏まえると、「要件1」の範疇と認識される可能性が高く、抵触の可能性が高い。

この問題点は2者間通信の前提では解決できないため、3者間通信を前提とせざるを得ない【図3参照】。結局のところ、この方式はゲートウェイ方式に酷似しており、「要件1」「要件2」を前提としてアクセストークン方式を用いて情報連携実現可能性は低いと言わざるを得ない。

長島哲也, 第5回情報連携基盤技術ワーキンググループ開催時に配布された資料に関する意見, 2011年6月17日

おいおい、いったい何を言っているのだ。「リンクコードa」から「リンクコードb」への変換を情報連携基盤でするのは当たり前だ。その後の、データ（属性情報）の通信を、「情報保有機関a」から「情報保有機関b」へ直接に接続して要求するというのが「案2」なのであり、「案2」でも当然、「リンクコードa」から「リンクコードb」への変換を情報連携基盤でする。

どうやら、この著者の頭では直接接続が不可能に見えているらしい。あまりにも基礎的なことを理解していない。そもそもなぜ「案2」が「アクセストークン方式」と呼ばれるのか、その名前の由来すら知らないと見える。

アクセストークン方式とは、その名前が示すように、通常、次のような方式を指す。（バリエーションはいろいろあるにせよ。）

つまり、「リンクコードXb」の指定でアクセス要求を受けた情報保有機関Bは、予測困難な受付番号を暗号論的乱数で発行し（トランザクションIDなどと呼ばれる）て、その受付が「リンクコードXb」についての要求だということを記憶する。そして、その受付番号をアクセス要求元である情報保有機関Aに渡し、情報保有機関Aはその受付番号でもって直接、情報保有機関Bにアクセスを要求する。情報保有機関Bは、受付番号からそのアクセス要求が「リンクコードXb」についてのものだとわかるので、国民Xの属性情報を情報保有機関Aに返す。

これはまったくごく普通の方法で、業界の常識じゃないか。Webアプリでセッション管理を実現したことがあるという程度の経験の学生でも、このくらいの発想はするだろう。

こんなことがわからない長島哲也という人はどういう人なんだ？ と、ググってみたところ、なんと、「日本アイ・ビー・エム株式会社 官公庁担当チーフ・テクノロジー・オフィサー ディスティングイッシュト・エンジニア（技術理事）」の方だという。

これはいったいどういうことか。意見書の続きを読むと、結論としてこんな表が出てくる。

長島哲也, 第5回情報連携基盤技術ワーキンググループ開催時に配布された資料に関する意見, 2011年6月17日

どうしても「アクセストークン方式」は駄目で、「ゲートウェイ方式」でないといけないのか。*5

長島氏の提出資料には、もう一つ別の資料があった。その意見書では、「諸外国の行政機関や国内民間企業で実績*6のある情報連携基盤のアーキテクチャがほぼ活用できるのではないか」という論旨になっている。

これはようするに、IBMの実績をそのまま採用してくれという意見ということではないか。資料には、「諸外国」の例として、ベルギーで採用されているという「連携基盤」の図が掲載されている。ググってみたところ、IBMの「STTAR」という製品がベルギーで実績があるらしい。

• IBM STTAR（スタア）のご紹介 - 実績あるアーキテクチャによる次世代電子行政バックオフィス連携の実現, 日本アイ・ビー・エム, 2010年5月13日

このページの説明を見ると「分散データをハブで連携する仕組みを日本向けにアレンジ」といった記述がある。図も掲載されているが、ようするに、このIBMの既存のパッケージ製品が「ゲートウェイ方式」だということではないのか。

そうすると、長島哲也氏の意見書は、単なる無知によるものではない可能性も疑われる。（日本IBMほどの超一流企業のCTOほどの方が、そんな低レベルな技術力のはずがないのだから。）

1. 会社の方針で、技術上虚偽の情報（アクセストークン方式は実現不可能であるとする）をWGに提出している可能性
2. 個人の判断で、技術上虚偽の情報（アクセストークン方式は実現不可能であるとする）をWGに提出している可能性
3. 単に、技術に無知でアーキテクトセンスにも欠けるため、純真に誤った情報（アクセストークン方式は実現不可能）をWGに提出している可能性

どれなのか。

もし、1.であるなら、そのような会社は国賊企業との誹りを免れない。なぜなら、情報連携基盤の設計は、国民のための番号制度における方式設計の根幹であり、連携基盤に全データを通すか通さないかは、「国家の一元管理」の防止の要件を満たせるか満たせないかに関わる選択である。一企業の既存製品の都合で、基礎的な設計方針をねじ曲げられてはたまらない。組織ぐるみで故意に虚偽情報をWGに出すような会社に対しては、出入り禁止にするなど政府は断固たる措置をとるべきだろう。

もし、3.であるなら、国の一大プロジェクトの設計に、識者として携わる資格がないと言わざるを得ない。（これが失態なのなら、「気づきませんでした」で済むレベルではないのであり、今後も同様のことが繰り返されるだろう。）

もし、2.であるなら、会社はそれを放置するのかという問題になるはずではないか。

NTTデータ宮坂肇氏の主張

もう一つ、やや小さな点だが、問題のある文書が見つかった。「第5回情報連携基盤技術WG意見書」という6月16日付の文書で、著者は「情報連携基盤技術WG構成員 宮坂肇」となっている。

この意見書では、「別表1. 符合変換方式における検討要素とその影響度」という表があり、そこに次のように書かれている（問題部分のみ抽出）。

検討要素	主な懸念等	影響度
国民の出生や在留外国人等の追加及び情報保有機関が増大した際の処理性能とコスト	・コード変換テーブル方式の場合、国民（出生や在留外国人等）や情報保有機関を追加する度に該当分のレコード領域の確保が必要となります。また検索対象レコードの増大に伴い、テーブル検索速度が低下します。	大
一元管理性（※）	・コード変換テーブル方式の場合、情報連携基盤にすべての情報保有機関におけるリンクコードを電磁的手段で記録することとなる為、一元管理と見なされる可能性があります。	大

宮坂肇, 第5回情報連携基盤技術WG意見書, 2011年6月16日

少し背景説明が必要になる。これらの指摘は、リンクコードの変換処理（上のFlashアニメーションで、「Xa → Xid → Xb」と変換された部分）を、テーブル参照で実現するか、可逆暗号で実現するかについて論じられたものである。

まず2番目の点。「情報連携基盤にすべての情報保有機関におけるリンクコードを電磁的手段で記録することとなる為、一元管理と見なされる」というのだが、それは、可逆暗号方式であっても同じだ。テーブル参照方式も可逆暗号方式も機能として等価なのであり、もし、テーブル参照が「一元管理」だとするなら、可逆暗号方式でも「一元管理」である。

情報連携基盤が「一元管理」と言われないためには、情報連携基盤がデータ（属性情報）を扱わないことによってのみ実現可能なのであり（例えば「アクセストークン方式」とするなど）、そうするのであれば、テーブル参照方式だろうが可逆暗号方式だろうが、どっちでもよい。

このことは、4月12日の情報連携基盤技術WGにおいて山口英委員から提出された「情報連携基盤技術に関する質問／情報連携基盤に関する個人情報保護に関する質問」においても、次のように指摘されていた。

【質問先】
骨格案（その1）2ページ

3.(2)ID コード及びリンクコードの生成方法

【質問】
1. IDコードとリンクコードの生成方法として、コード変換テーブルによる管理を行わず可逆暗号を用いることとした点について 情報連携基盤では、異なる情報保有機関同士の情報連携を図るために、IDコードからリンクコード、またリンクコードからIDコードに遡る処理が必要不可欠であるところ、個人情報保護に十分配慮した仕組みとするため、及び最高裁判断枠組みへ適合するための要件（以下、保護適合要件という。）を満たすために、コード変換テーブル方式（乱数を用いてコードを変換し、変換前後のテーブルを保持する）の採用を避け、可逆暗号方式（その都度可逆暗号によってリンクコードからIDコード、又は IDコードからリンクコードを生成する）の採用を検討しているところであるが、この判断は必要かつ十分なものか。

質問1の1
可逆暗号により生成する方式は、保護適合要件を満たすために十分なものと言えるか。
質問1の2
コード変換テーブルによる管理方式を避けることは、保護適合要件を満たすために必要なものか。

【趣旨】
情報連携基盤技術WGでは、情報連携基盤技術の骨格案検討にあたり、個人情報保護に十分配慮した仕組みとするため、並びに、住民基本台帳ネットワークシステムに係る最高裁合憲判決（最判平成20年 3月6日）で示された個人情報を一元的に管理することができる機関又は主体が存在しないこと、及び、何人も個人に関する情報をみだりに第三者に開示又は公表されない自由を有することなどの判断枠組み（以下、最高裁判断枠組みという。）に適合した形で個人情報を取り扱うシステムとするため、いくつかの技術要件を検討しているところであるが、検討しているそれぞれの技術要件が、個人情報保護への十分な配慮及び 最高裁判断枠組みへの適合性として、十分な要件であるか、また、必要な要件であるか、個人情報保護WGの見解を求めたい。

【想定される答え】
質問1の1への回答: 十分である。ただし、当該可逆暗号の鍵の機密性が保たれなければならない。
理由: 最高裁判断枠組みに適合するには、情報保有機関が他の情報保有機関と個人情報を無秩序に突合できないようにする必要があり、そのために、各情報保有機関ごとに異なる「リンクコード」を用いて各リンクコード間の突合を情報連携基盤のみが可能とする方式には合理性がある。この突合を情報連携基盤のみが可能とするにあたり、鍵の機密性が保たれた可逆暗号を用いることは、十分である。

質問1の2への回答: 必ずしも要しない。
理由: リンクコードの突合を情報連携基盤のみが可能とするにあたり、コード変換テーブルによる管理方式を用いることもできる。このときコード変換テーブルのデータの機密性が保たれなければならないが、可逆暗号の鍵も同様に機密性が要求されるのであるから、可逆暗号方式とコード変換テーブル方式のどちらを用いても同じであり、コード変換テーブル方式を避けることは必要でな い。

---

【質問先】
骨格案（その1）3ページ
3.(4) 「番号」とIDコード・リンクコードの管理のあり方

【質問】
2. リンクコードの管理のあり方として、情報連携基盤においてはリンクコードは生成後直ちに消去することとした点について

情報連携基盤においては、IDコードからリンクコードを生成する処理が必要不可欠であるところ、保護適合要件を満たすため、生成されたリンクコードを連 携終了後に直ちに消去する方式を検討しているところであるが、この判断は必要かつ十分なものか。

質問2の1
生成されたリンクコードを連携終了後に直ちに消去する方式は、保護適合要件を満たすために十分なものと言えるか。
質問2の2
生成されたリンクコードを連携終了後に直ちに消去することは、保護適合要件を満たすために必要なものか。

【趣旨】
1.の質問に同じ。

【想定される答え】
質問2の1への回答: 十分である。
理由: とくになし。

質問2の2への回答: 必ずしも要しない。
理由: 可逆暗号で生成されたリンクコードを直ちに消去したとしても、当該可逆暗号が利用可能であればいつでも同じリンクコードを生成することができる。当該可逆暗号が情報連携基盤以外で利用不可能とする必要があるが、それには当該可逆暗号の鍵の機密性が保障されなければならない。鍵の機密性が保たれるならば、同様に生成されたリンクコードの機密性も保たれるはずであり、また、リンクコードの機密性を保てないのであれば鍵の機密性も保たれないはずである。よって、リンクコードを直ちに消去することは必要でない。

情報連携基盤技術に関する質問／情報連携基盤に関する個人情報保護に関する質問

テーブル参照方式も可逆暗号方式も機能として等価なことは、技術者なら普通にわかるはずなのに、この宮坂肇氏がどういう方なのかと調べてみると、「（株）エヌ・ティ・ティ・データ 技術開発本部 ITアーキテクチャ&セキュリティ技術センタ部長」の方だという。

他にも、先の「検討要素」の表で、1番目の指摘は、テーブル参照方式では人や組織が増えると遅くなるというのだが、logオーダーという概念をまさか知らないということはあるまい。しかも、組織が増えた場合は、独立したテーブルを増やすことになるだけであり、個々のテーブルの検索自体が遅くなることはない*7。

官庁の事務屋にはこんなものでも信じられてしまうかもしれないが、技術者がこんな検討をしていたら怪しまれるのではないか。「レコード領域の確保が必要」というのも、何が問題なのか。

そもそも、必要とされている機能は、単なる番号から番号への1対1対応のマッピングだけであるわけで、まさかRDBMSを使って実現するなどと考えているのではあるまいな。

検索速度が云々というが、たかが一億数千万エントリ（=0.1ギガエントリ）のテーブルくらい、いまどきメモリに載せられるだろう。

まとめ

情報連携基盤技術WGは非公開で行われており、こうした議論が公正に行われているのか、外部から監視することができない状態になっている。

私は、3月の堀部政男情報法研究会のシンポジウムの席で、役所の方に「なぜ、情報連携基盤WGは非公開なのか」と尋ねたところ、「住基ネットの技術情報を扱うことがあるため、秘密にする必要があった*8」というお答えだった。私がそこで述べた意見は、「毎回住基ネットの情報を扱うわけがない。典型的な詭弁だ。」というものだったが、今日に至ってもこのWGは非公開で行われている。

4月のことだったか、IT企業から情報連携基盤WGの構成員として出席されている方から、「私が発言できるのはここまでです。会社の方針があるので。」というような話を聞かされたことがある。WGに「識者」として招かれているIT企業の技術者が、会社の営業から（？）の指示（？）で、WGで口がきけないというのだ。

そんな中で目立っているのが、日本IBM長島哲也CTOの立ち振る舞いだ。こんなのが通って、システムができあがってから違憲訴訟で「国家による一元管理」とみなされたらどうするのか。何千億円をパーにするのか。

こういうことにこそマスコミの役割が求められるところではないか。「国家百年の大計としての国の礎」が、こんなチープで胡散臭い議論によって作られようとしていることに、ちゃんと警戒して、事実を暴き出して国民に警鐘を鳴らすべきだろう。

訂正記録

「長島哲也」と書くべきところを「長島哲哉」と誤記していた点を修正した。

追記

番号制度の基礎については、以下の番組をどうぞ。

• 一番いいのを頼むための共通番​号制度徹底解説　〜そんな共通​番号制度で大丈夫か？〜, M​IAU Presents ネ​ットの羅針盤, ニコニコ生放送, 2011年6月13日 （いつでも視聴可能になりました）