高木浩光＠自宅の日記

■ 神社で祈願してきた

スカイツリーを見に行ったところ、近くに「高木神社」というところがあるのだそうで、ちょうどこの土日が例大祭との張り紙があったので、ちょっと行ってみた。

お祭りは震災に配慮してお囃子や太鼓、露天商などが中止となっていたが、スカイツリーのミニ神輿があって可愛らしかった。

由緒書きには次のように書かれていた。ははあ、これは……。

応仁二年（一四六八年）の創祀と伝えられており（略）御祭神は「高皇産霊神」（高木神）と申し、古事記や日本書紀によれば、天孫降臨の際の国譲り伝承や神武東征などに度々登場し、天照大御神に助言するなど政治的な手腕を振るってきました。以上の神話から「万物生成」「人間関係を調整する」「交渉事を成就させる」などの尊い御神徳があると信じられて今日に至っています。

というわけで、お祈りしてきた。

パンパン、「ウイルス罪法案の立法趣旨が国会審議できちんと確認され、趣旨から逸脱した運用がなされることのないよう、適切な防止措置が講じられますように……。」

リアル巫女さんもいらしたので、お守りなど探しに行ったところ、「うけいの矢」なるものがあったので頂いてきた。

御利益は「万物生成」「人間関係を調整する」「交渉事を成就させる」とのこと。これは有り難い。気が引き締まる。

■ 今井猛嘉参考人曰く「バグが重大なら可罰的違法性を超える程度の違法性がある」

先日の「バグ放置が提供罪に該当する事態は「ある」と法務省見解」の件、その4日後の5月31日に参考人質疑が行われ、法政大学の今井猛嘉教授が、有識者参考人として、不正指令電磁的記録に関する罪（いわゆる「ウイルス作成罪」）について意見を述べている。この今井参考人は、8年前の平成15年に、法制審議会の「刑事法（ハイテク犯罪関係）部会」で、この法案の原案が作られた際に、部会の幹事を務めていらした方だそうだ。

今井猛嘉参考人の発言内容

衆議院の会議録に全文が掲載されているように、参考人の意見陳述の後、質問に立った大口善徳議員が、前回の法務大臣答弁を踏まえて、今井参考人に対し、以下の質問を投げかけている。

○大口委員 （略）それでは、まず今井先生に、実体法の立場から、この不正指令電磁的記録作成罪の構成要件の解釈についてお伺いをさせていただきたいと思います。

実は前回、大臣に対して、私は、フリーソフトウエアを公開したところ、重大なバグがあるとユーザーからそういう声があって、それを無視してプログラムを公開し続けた場合、それを知った時点で少なくとも未必の故意があって、提供罪が成立するという可能性があるか、こう質問いたしましたところ、大臣から、ある、こういう回答を得たわけでございます。

そこで、そのバグというものが、これが、「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令」にそもそも該当するのかということが一点でございます。

そして、インターネットにおいて、フリーソフトを公開し、それに対して、バグについての報告を踏まえて何度も改訂し、徐々によりよいソフトウエアの完成を目指していくという文化があると言われておりまして、すべて利用者の責任で使うことを条件に、自由なソフトウエア開発と自由な流通を促進するということによってソフトウエアが発展してきた歴史的経緯があるわけでございます。

そういうことで、その途中の段階でバグがあるソフトを公開していくことが提供罪として罰せられると、このような文化を阻害して、だれもフリーソフトを公開しなくなってしまうおそれがあるのではないか、こういうふうにも危惧されているわけです。この点についてお伺いしたいと思います。

衆議院会議録, 法務委員会第15号, 2011年5月31日

それに対して、今井参考人は次のように答えた。

○今井参考人　お答えいたします。

バグというものが、フリーソフトに限らず、ソフトに不可避的に起因しています望まない動きだというふうに考えますと、そのようなものがここで挙がっている百六十八条の二第一項の一号に当たることは否定できませんが、しかしながら、その不正な動作がどの程度のものであるかということが問題でありまして、重大なバグと先生はおっしゃったかと思いますが、そういったときには、可罰的違法性を超える程度の違法性があるということですので、これに当たることは十分考えられると思います。

二番目の御質問で、特にフリーソフトウエアの場合に、アップロードしてよりよいものに変えていくという文化を阻害するおそれがないかということでありますけれども、私の知っている限りでは、通常、そのようなソフトをアップロードしたときにはバグもあり得るということを潜在的なユーザーの方にもお示しをして、その方々の承諾を得て使っていっているのではないかと思いますので、個々の利用者が一定の危険を認識し、あり得る不都合を承諾して行っている限りにおいては、やはり違法性がないという理解も十分可能であろうと思っております。したがいまして、現在のようなアップロードの仕方、ソフトウエアの展開、提供について御懸念の点はないのかなと思っております。

衆議院会議録, 法務委員会第15号, 2011年5月31日

要するに、今井参考人は、「バグが不正指令電磁的記録に当たることは十分考えられる」、「その不正な動作がどの程度のものであるかということが問題」、「バグが重大なら可罰的違法性を超える程度の違法性がある」ということを述べている。

これはマズい。前回の日記に書いた悪い予感*1の通りになっている。

「重大な」とは何を指すか

「重大なバグなら」と言うが、具体例で考えてみてほしい。「不正な動作」の例として「電子計算機が動かなくなる」想定してみればいい。愉快犯ウイルス魔が、電子計算機を動かなくするトロイの木馬を作成してバラ撒いたならば、それはウイルス作成及び供用罪で処罰されるべきものだろう。それがこの法で処罰しようとしている「不正な動作」の典型的かつ代表的な例である。

そして、プログラム開発において、バグによって「電子計算機が動かなくなる」事態が起きるかといえば、当然にこれは十分容易に起き得ることである。

今井参考人は「重大なバグ」に限定すれば技術者の心配は払拭されると考えたのだろうか。結果の重大性で限定しても技術者の萎縮は払拭されないのだが。

ここで、対比として、プログラムのバグが原因で死人が出る場合を考えてみる。対策をとらずに放置したせいで死人が出た場合などで、業務上過失致死罪（ウイルス罪ではない）に問われかねないこと（実際に有罪とされるかは別にして）については、たとえプログラム開発者であろうとも、それを不当だとする者はいないだろう。そういうものを指して「重大なバグ」と言うのならいい。

だが、この法で処罰しようとしてるのは、たかが「電子計算機が動かなくなる」といった程度のものなのである*2。それを処罰の射程としているのだからこそ、それと同じ結果をバグによってひき起した場合にまで刑事責任を負わされるというのでは、プログラム開発者にはたまったものではないわけである。「そんなことになるのなら仕事をやめる」とする声もTwitterであがっていた。

おそらく今井参考人にプログラム開発の経験はないのではないか。

一方、大口委員はその後、同じ質問を法務大臣にも投げているのだが、江田法務大臣は、今井参考人よりは適切な答弁をしている。

○江田国務大臣 （略）フリーソフトウエア上のバグの問題について、先般、大口委員の御質問で、私は、委員の御質問、可能性があるかと。可能性ということならば、それはあると簡単に一言答えましたが、これが多くの皆さんに心配を与えたということでございまして、申しわけなく思っております。

（略）ただ、そういうバグが非常に重大な影響を及ぼすようなものになっていて、しかもこれが、そういうものを知りながら、故意にあえてウイルスとしての機能を果たさせてやろうというような、そういう思いで行えば、これはそういう可能性がある、そういう限定的なことを一言で申し上げたので、そうした場合でも、その限界はどこかというのは、これはなかなか大変なことでございまして、捜査機関においてそのあたりは十分に慎重に捜査をして、間違いのない処理をしていくものと思っておりますので、無用な心配はぜひなくしていただきたいと思っております。

衆議院会議録, 法務委員会第15号, 2011年5月31日

「あえてウイルスとしての機能を果たさせてやろうというような、そういう思いで行えば」とある。これはその通りで、犯罪か否かはここがキモであり、今井参考人が言うような結果の重大性は関係がないはずである。（おそらく大臣のこの発言には法務省担当者からのレクチャーも影響しているのではないか。）

「バグ」の用語法による混乱

ただし、大臣のこの答弁に対しては、以下のように言わねばならない。

大臣自身が「ウイルスとしての機能を果たさせてやろう」と、「機能」という言葉を用いているように、そのようなケースでは、それはもはや機能であってバグではない。

「バグ」とは、我々の用語法では、作成者の意図に反する動作をする原因部分を言う。したがって、「バグが犯罪になる」と言われれば、重大な場合に限るなどと条件を付けて限定されようとも、それは異常だと感じる。なにしろバグによる挙動は作成者の意図に反する動作であるのだから、過失犯規定を設けるのでない限り、犯罪ではないはずと思える。（正確には後述。）

つまり、5月27日の「あると思います」という大臣答弁が想定していたのは、元々は「バグ」によって意図せず重大な危険をもたらし得るプログラムを作成してしまった者が、その後、それをあえて機能として果たさせようとの意思を持って放置した場合であって、それはその時点でもはや「バグ」ではないと言うべきである。

これから大臣が、「バグという言葉の使い方を間違えた。それが機能ではなくバグである限り、犯罪になることはない」と訂正すれば、バグの件についての混乱は終息するだろう。そのような見解ならば、法務省が今年5月に公表していた「いわゆるサイバー刑法に関するQ&A」の内容とも整合する。（作成罪だけでなく提供罪も含めてバグで犯罪は成立しないとされている。）

Ｑ４ コンピュータ・ウィルスの作成・提供罪が新設されると，（略）あるいは，プログラマーがバグを生じさせた場合まで処罰されることになりませんか。

Ａ （略）この罪は故意犯ですので，プログラミングの過程で誤ってバグを発生させても，犯罪は成立しません。

いわゆるサイバー刑法に関するQ&A, 法務省, 2011年5月

もっと大事な話

バグ云々の話は、それ自体は実はあまり重要でない。重要なのは、この罪の趣旨が、何を処罰しようというものなのか、前回の日記で「次のどちらなのか」として二つを挙げた（以下参照）ように、どちらなのかが人によって（議員や有識者によって、もしかすると法務省内部でも？）理解が違っていることが問題なのである。バグを巡る質疑のおかげで、それぞれの人々がどちらの趣旨の罪と認識しているのかがあぶり出されることとなった。

• (X) 重大な危険を生じさせるプログラムの供用、作成、提供等を罪とする。
• (Y) 人々を騙して実行させるようなプログラムの供用、作成、提供等を罪とする。

今井参考人は、今回の発言内容から、この罪の趣旨を(X)と認識していることが窺われる。もし(Y)と認識しているならば、バグの重大性に関係なく、当人に騙して実行させる意図（「あえてウイルスとしての機能を果たさせてやろうという思い」）があるか否かをまず答えるはずであろう。それなのに、それを言わず、「文化を阻害するおそれ」との質問に対し、「フリーソフトウエアの場合」については「個々の利用者が一定の危険を認識し、あり得る不都合を承諾して行っている限りにおいては、やはり違法性がない」という説明を持ち出している。(Y)の理解ならばそのような説明を持ち出すまでもないし、(X)の理解だからこそ、「文化を阻害するおそれ」との批判に対してこの（やや苦しい）理屈を持ち出さざるを得なくなっている。

実は、江田大臣も(X)の理解をしてしまっている疑いがある。前記の通り、大臣答弁の「あえてウイルスとしての機能を果たさせてやろうというような」という説明は(Y)を想定していると思われるが、別の質問に対する答弁では、次のように述べており、(X)の理解が混在している様子が窺われる。

○江田国務大臣 （略）全体にこれは故意犯で、そしてもちろん故意は積極的な故意だけじゃなくて未必の故意と言われるものもあるわけですけれども、やはりそういう故意犯であるということは一つの縛りになるし、さらに、フリーソフトウエアというものが持っている社会的な効用、フリーソフトの場合にいろいろなそういうフリーズなどのことが起きるということをあえて引き受けながら、しかし、フリーソフトの世界をより有効に、有用に社会的に活用していこう、そういう、ここへ参加をしてくる者の多くの認容というものはあるわけで、そういう意味では、ある程度のバグ的なものがあってもこれは許された危険ということになっていくのだと思いますし、そこはまた、もし時間がありましたら、この条文の一語一語について細かなコンメンタール的な解説というものは必要かと思います。

衆議院会議録, 法務委員会第15号, 2011年5月31日

(X)の理解ではなく(Y)の理解であるならば、フリーソフトの社会的有用性を持ち出すまでもないはずである。

フリーソフトウェアだけの問題ではない

ここで、こう思う人がいるかもしれない。「いずれにせよ、(X)でも(Y)でも、フリーソフトは大丈夫なんだから、かまわないのでは？」と。しかし、社会的有用性が認められないプログラムの場合に罪に問われる虞れが残っている点に注意が必要である。

企業が開発しているフリーソフトや、所定の場所（様々なプログラムが集積して配布されている場所）で公開しているフリーソフトなどでは、(X)の理解であっても、「社会的有用性がある」「個々の利用者が一定の危険を認識し、あり得る不都合を承諾して行っている」と認められるかもしれないが、無名の個人が、自分のWebサイト上になんとなく掲載しているだけ（社会貢献などとは思ってもみないで）のプログラムは、はたして「社会的有用性がある」と認められるだろうか。ほとんど誰も利用していないものであっても「社会的有用性がある」と認められるのか。

また、この罪が対象としているプログラム（指令を与える電磁的記録）は、インストーラが付いたようなちゃんとしたソフトウェアに限定されるわけではない。Greasemonkeyスクリプトなどのように、パパッと書いてブログにちょいと掲載したようなコードも対象であるし、さらには、Webページ上のJavaScriptコードも対象であろう。そういったコードで典型的に見られるように、プログラムの公開というのは、いちいちライセンス条項を示して利用者に同意を求めるものばかりというわけではない点にも注意が必要である。

それなのに、今井参考人は、「私の知っている限りでは、通常、そのようなソフトをアップロードしたときにはバグもあり得るということを潜在的なユーザーの方にもお示しをして、その方々の承諾を得て使っていっているのではないか」として「御懸念の点はないのかなと思っております」と述べており、ライセンス条項を示していないプログラムが山のように存在する現実について触れていない。

今井参考人のような考え方でこの罪が運用されるようになったら、逐一ライセンス条項を用意するなど準備が必要になって、不用意にプログラムをブログに書いたりできなくなるのではないか。それは、いわば行為規制となるのであって、刑法の改正には馴染まないのではないか。168条の2が、禁止規定を置かない自然犯的な書きぶりであることからしても、この改正によって、善良な人々のこれまで通りのプログラム作成活動（それが社会的有益性に欠けるものであっても）に制約をもたらすようなことがあってはならないのではないか。

このようなことは、この罪の趣旨を(X)として理解している限り、どのように取り繕ってもどこかしら綻びが出てくるのではないか。

なぜ(Y)の趣旨なのか

では、なぜ(Y)の趣旨の方が正しいと言えるのか。これは、この「不正指令電磁的記録に関する罪」が、文書偽造罪とパラレルに設計されていることから明らかである（と、刑法学者の先生から教えて頂いた）。

この罪が文書偽造罪とパラレルに設計されていることは、この法案の原案を策定した法制審部会における以下の発言（どなたかの委員による）からも窺える。

●この問題は，現行法上の目的犯，例えば文書偽造罪などとパラレルに考えてよいと思うのです。単に文書を偽造しても，犯罪にはならず，行使の目的がなければなりません。「行使」というのは，それ自体はニュートラルな言葉なんですけれども，他方で，行使罪というのがあり，それは犯罪として要件が定められているのですね。その意味で，目的の内容は，別途定められており，行使罪を実行することを目的の内容として偽造罪という犯罪の内容が確定するという構造になっているのです。今回の原案もそれとパラレルに考えることができるはずであり，「実行の用に供する目的」というのは，それ自体はニュートラルな言葉なんですが，当然に，供用罪に当たる行為を行う目的というように理解されるべきものです。したがって，あえてそこのところに拘泥する理由はないと思うのです。現行法の規定について「行使」という言葉はそれ自体「およそ使う」というだけのことを意味するから，偽造罪の処罰範囲の限定には役立たない，なんて議論は誰もしないではないですか。ただいまの議論は，それと全く同じような議論ではないかと感じます。

以上のことが前提なんですが，他方で，電磁的記録不正作出罪の場合，「人の事務処理を誤らせる目的」というニュートラルでない表現が使われています。ここでも，そういうはっきりした文言が考案できれば疑義も生じないのかもしれないとも感じるのですが，ただ，私は原案で，解釈上，ご指摘のような問題が生じる余地はないと考えております。

法制審議会刑事法（ハイテク犯罪関係）部会第6回会議 議事録, 2003年7月4日

しかし、このことがあまり理解されていない様子が多々見受けられるのが現状である。この委員が「そういうはっきりした文言が考案できれば疑義も生じないのかもしれないとも感じるのですが」と、かすかに虞れを予感していたものが、ズバリ的中したとも言えることで、今回の5月31日の衆議院法務委員会の質疑で、柴山昌彦委員が次のように法務大臣に質問している。

○柴山委員　次の質問に移りますが、事前には通告をしていませんが、先ほどちょっと大臣の答弁をお伺いしていて気になる点がありましたので、一点確認をさせていただきたいと思います。

フリーソフトウエアのバグの問題で、バグがあることを知りつつも、引き続きそれをインターネット上の提供状態に置いていた場合に、提供者にウイルス提供罪、ウイルス供用罪が成立するかどうかというところで、大臣は、成立する可能性はあるんだけれども、ただ、目的として、損害や誤作動を与えるというような積極的な目的を持っていなければこれを処罰できないというようなお話をされていたのかなと思うんですけれども、ただ、これは条文を見ると、目的はあくまでも「電子計算機における実行の用に供する目的」というように書かれておりますので、大臣がおっしゃったような目的を私は限定の材料にすることはできないんじゃないか。

もちろん、利用者の推定的な承諾、推定的という言葉を使うかどうかはともかく、それは一つ根拠になります。あと、正当な理由なくといって、つまり、やはり一定のそういったバグがあっても、それを上回るさまざまな効用というものがあれば、これを提供し続ける正当な理由があるのかどうか。そういうようなところで縛りをかけるのはともかく、条文上、やはりこの目的のところで限定というものをすることはできないんじゃないかなというように思いますので、江田大臣、先ほどの御答弁を繰り返してください。

衆議院会議録, 法務委員会第15号, 2011年5月31日

これは、「実行の用に供する目的」という条文を、「供用罪に当たる行為を行う目的」として読めておらず、「ニュートラルな言葉」としての「実行の用に供する」（Webサイトで公開状態にするだけで該当する）という意味で解釈しているために出てきた質問ではないかと思われる。

このことは、これまでに何度も書いてきたことで、最近では2月9日の日記「ウイルス作成罪創設に向けて国民に迫られる選択」で「(A)解釈」と「(B)解釈」として整理した件（以下に再掲）である。柴山委員のこの質問は、「『実行の用に供する目的』という条文は(A)解釈としか読めないのでは？」という問いであろう。

(A)解釈

(A)解釈では、プログラムが「不正指令電磁的記録」であるか否かが静的に客観的に定まる*1（ことを前提としている）。

そのプログラムを「人の電子計算機における実行の用に供する」行為が「供用罪」となるのだが、このとき、(A)解釈では「人の電子計算機における実行の用に供する」の解釈が、単に「プログラムを渡す」というような意味であり、行為者がどういう意図でプログラムを渡しているかは罪の構成要件に関係がない。

そして、この「供用」の目的で作成する行為が「作成罪」となる。

(B)解釈

(B)解釈では、「人の電子計算機における実行の用に供する」の解釈が、単に「プログラムを渡す」というような意味ではなく、「不正指令電磁的記録としての実行」を行為者が意図していることを含む。すなわち、行為者の主観として「不正指令電磁的記録としての実行」*2の意図の有無が、犯罪の構成要件となる。

そして、この「供用」の目的で作成する行為が「作成罪」となる。

そして、柴山委員のこの質問に対して江田大臣は、以下のように回答を先送りして、即答ができない状態だった。

○江田国務大臣　条文の一つ一つの文言についての細かな解釈ということになりますと、私もよく吟味をしながらお答えをしなきゃならぬかと思いますが。

（略）もし時間がありましたら、この条文の一語一語について細かなコンメンタール的な解説というものは必要かと思います。

衆議院会議録, 法務委員会第15号, 2011年5月31日

これは単なる細かい条文解釈の話というわけではない。「実行の用に供する」の条文解釈のブレは、そのまま、立法趣旨が(X)なのか(Y)なのかということと直結している。(A)解釈と(Y)の趣旨とは相容れないもの（柴山委員ご指摘の通り）であるため、(A)解釈をとった時点で、立法趣旨を(X)だと思ってしまう。

このように、この罪の立法趣旨の理解が、法務委員会の委員にも大臣にも、ちゃんと確立していない。今井参考人は、原案を策定した法制審部会の幹事であったにもかかわらず、(A)解釈をとっているように窺われる。

どうしてこんなことになったのか

（執筆中）

■ ウイルス罪法案、どうしてこうなった

前回で書ききれなかった「どうしてこんなことになったのか」の件。

結論だけ先にざっくり言えば、ワーム（自己増殖能力を持つもの）を想定していた人と、トロイの木馬（伝染の手段として人による起動を要するもの）*1を想定していた人が混在していて、その認識の違いを確認することなく議論してきた（法制審や国会において）結果であろうと思う。

それはどういうことなのか。

私はこの問題を最初に理解した2006年10月22日の日記「不正指令電磁的記録作成罪 私はこう考える」で、「法制審議会の議論はプログラムには多態性があるという視点を欠いている」と書いた。

つまり、この不正指令電磁的記録の罪が、文書偽造罪や通貨偽造罪とパラレルに設計されているといっても、偽造文書や偽造通貨は、作成された時点で偽造文書かそうでないかは確定するのであって、誰にどう渡すかによって偽造文書になったり偽造文書でないものになったりということはない。罪となるかは行使の目的があるかどうかであり、たとえば、偽造通貨をたまたま入手した者が、偽造通貨の専門家に鑑定を依頼するために渡すといったことは、行使の目的がないので偽造通貨行使罪にはあたらないわけだが、その客体が偽造通貨であるという事実は変わらない。それに対してプログラムの場合はどうか。作成された時点で不正指令電磁的記録であるか否かが確定するのかどうか。

ワームであれば確定する。ワームはそれ自体社会的に危険なものであって、ワームが有益なプログラムとみなされることはない*2のであるから、それをそうとは知らずに実行してしまう人が出れば、人の意図に反していることは間違いないだろうから、誰かが実行することを期待して作成したり提供したり、実際に実行させたりすれば、不正指令電磁的記録作成・提供・供用罪に該当することとなるというのは、それでよい。何の疑義もない。

では、ワームではないトロイの木馬ではどうか。実行するとハードディスクをすべて消去するプログラムはどうか*3。これはワームではない単純なトロイの木馬である。ハードディスクを消去するプログラムの機能自体は、有益なものとして使われることもあるし、間違って実行させられて害が生じることもある。このようなケースについて、法制審部会では一切議論されていなかった。私が2006年10月22日の日記で、「プログラムには多態性があるという視点を欠いている」と書いたのは、こういうケースを法律家らが想定せずに議論していたことを指してである。

このようなケースについて、不正指令電磁的記録に該当しないとする解釈（あるいは立法趣旨）もあり得た。つまり、専らトロイの木馬として（あるいはワームとして）しか機能しないようなプログラムが不正指令電磁的記録であって、（ファイル消去プログラムのように）有益にも使われることのあるプログラムは、それがいかなる態様で人の電子計算機における実行の用に供されることがあろうとも、不正指令電磁的記録に該当しないとするものである。

しかし、そのような解釈（あるいは立法趣旨）ではないことが、今国会の衆議院法務委員会で確認された。以下の質疑がそのことを示している。

○江田国務大臣 コンピューターウイルスの定義は、今委員が御指摘のとおり、「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令」、その意図というのはだれを基準にするのかという御指摘かと思いますが、この罪は、電子計算機のプログラムに対する社会一般の信頼、これを保護法益とするわけでありまして、それぞれの個人の信頼とか不信とかという話ではございません。

電子計算機を使用する者一般の信頼を規範的に判断をしていくということでございまして、プログラムの具体的な機能に対するその使用者の現実の認識を基準とするのではなくて、一般に認識すべきと考えられているところが基準になる、そのように思っておりまして、その判断に当たっては、プログラムの機能の内容であるとか、あるいは機能についての説明内容であるとか、あるいは想定される利用者、あるいは利用方法、こういうことを総合的に考慮することになると思います。

○大口委員 そうしますと、判断の基準として、プログラムの使用説明書の記載というのが参考になると考えるんですが、いかがですか。

○江田国務大臣 使用説明書は一つの参考になると思います。

○大口委員 例えば、パソコンの中のデータをすべて消去するというプログラムがあって、それがプログラムとしては有用なものである場合に、それと異なる説明、例えば、これは気象速報を随時受信するプログラムである、こういう説明がなされたものが広く配布され、その利用者が被害を受けたというケースが考えられます。こういう場合、使用者の意図に反する動作をする不正指令電磁的記録等になるのか、お伺いしたいと思います。

○江田国務大臣 今具体的な事例をお挙げになっているわけでございますが、利用者の意図に反してデータが消去をされてしまう。利用者としては、今の場合に、天気予想プログラムですか、天気の予想が出てくるものと思ったら、意に反してすべてのデータが消去されてしまうというようなことでございますから、これは、この意図に沿うべき動作を一般的にさせず、また一般的に意図に反する動作をさせてしまう、そういう指令を出す、そうした電磁的記録だということが言えると思いますので、該当するというふうに評価をされる場合が多いのではないかと思います。

○大口委員　そうすると、使用説明書の説明の仕方いかんによって、これがウイルスかどうかということが判定されるというふうにお伺いしたわけでございます。

そこで、使用説明書等が存在しないプログラムはどうなのか。（以下略）

衆議院会議録, 法務委員会第14号, 2011年5月27日

このように、元が有益なソフトウェアとして作成されたプログラムであっても、その供用の際の態様によっては供用罪が成立する（その場合に、その客体は不正指令電磁的記録に該当する）ということが言われている。

ようやく議論がここまで来たかと感慨深いわけだが、となると、立法趣旨が以下のどちらなのかということが、俄然重要だ*4ということになる。

• (X) 重大な危険を生じさせるプログラムの供用、作成、提供等を罪とするもの
• (Y) 人々を騙して実行させる行為や、その目的でプログラムを作成、提供等する行為を罪とするもの

このどちらなのかは、上で引用した27日の質疑で大口議員が最後で尋ねている質問、「そこで、使用説明書等が存在しないプログラムはどうなのか」に、どう答えるかで決定付けられるところだった。

もし、(X)の立法趣旨であるなら、「説明なく配布されているプログラムであっても、誰かが不用意に実行して危険になるようなものは、不正指令電磁的記録であり処罰の対象である」と答えるだろうし、(Y)の立法趣旨であるならば、「説明なく配布されているというだけでは、騙して実行させる意図があるということにはならない」*5と答えるはずだ。

しかし、27日の答弁では、この点についての回答が回避されてしまった。「これは消去用のソフトですよということがあれば、そして、それをウエブにアクセスして、消去用のソフトが欲しいなと思っている人が見つけて、それを使えば、これはウイルスになるようなことはあり得ないと思います」という答弁で、この回答は、(X)の場合にも(Y)の場合にも当てはまるものであるから、肝心のことが確認できていない。

参議院での審議はあと2回あるそうなので、法務省におかれては、間違う事なくこの点について明確に回答していただきたく思う。

というわけで、以下は、これまでの議論がいかに、ワーム想定とトロイ想定を混同したものであったかを振り返ることによって、今国会でのこの議論がなぜこうも混迷しているのかを納得し、混迷打破の鍵が、(Y)の立法趣旨であることの明確化であることを示す。

8年前の法制審部会での議論から

以下は、ワームを想定したもの（あるいは単純なトロイの木馬を想定に含めていない）と考えると合点がいく発言の数々である。

●第一の一の「その他の記録」につきましては，コンピュータ・ウイルスの機能を有する，内容的にそういう実質を有するプログラムではあるが，電磁的記録以外の記録の形で存在しているもの，例えば，プログラムのソースコードを紙媒体に印刷したものを想定してます。このような紙媒体の形で社会に広めるという形態も十分に考えられるので，第一の一について「その他の記録」を客体にしているものでございます。

●電磁的記録になっていても，今一歩何か欠けている部分があって，使ってもそれだとウイルスとしてうまく動かないという場合であっても，場合によっては，こうなり得る余地はあるということにつながってきますか。

●ほんの少し手を加えただけで不正な指令として完成するような実体であるものは，ここでいう完成している電磁的記録，完成しているウイルス・プログラムとしてとらえるべきだと考えております。

法制審議会刑事法（ハイテク犯罪関係）部会第1回会議 議事録, 2003年4月14日

上の部分は、ワームの社会的危険性を想定すると、こういう趣旨も納得できるが、ハードディスク消去プログラムをトロイの木馬として供用するケースを想定すると、納得がいかない。

●私は，むしろ逆に，ちょっと法定刑が軽過ぎるのではないかという気がしないでもないのです。

つまり，社会的法益に対する罪として，プログラムに対する社会的信頼を害する行為を犯罪にするという考え方，すなわち，ウイルスが持っている危険性というのはネットワークを通じて社会に広がっていく可能性があるところにあり，それが処罰の根拠なのだという見方自体，正しいと思っているのです。

これを前提にしますと，ここで問題となっているのは，社会の中に危険な薬物を生み出すとか，危険な凶器を作り出すとか，そういうのと非常に近い反社会的行為なのです。あえて刑法典の中に，これと近い犯罪を求めるとすれば，公文書偽造とか電磁的記録不正作出が挙げられます。確かにそれは個人的法益を害する形で使うことも可能ですけれども，今申し上げたような見方をすれば，そういう潜在的危険性を持っているからこそ処罰されなければいけないのだと考えられます。電磁的記録不正作出でも，普通の場合であれば５年の懲役まで行きますし，公文書偽造であれば１０年までの懲役が法定刑として予定されています。それとの比較で考えても，３年以下というのはむしろ軽過ぎるのではないかという気がするのですね。これは，刑法典のどこに入れるのかということとも関係すると思うのですけれども，私はむしろもう少し重く評価してもよい，そういう実体を持っているのではないかと考えるのです。

法制審議会刑事法（ハイテク犯罪関係）部会第3回会議 議事録, 2003年5月15日

この発言は、事務局ではない委員によるものと思われるが、「社会の中に危険な薬物を生み出す」「危険な凶器を作り出す」ことと並列にみなしている。（それを、さらに文書偽造罪と並列に論ずるのは変ではないか？）

続けて別の委員と思われる方から以下の発言へと続く。

●先ほどの文書偽造にあります「行使の目的」にある意味相当します「実行の用に供する目的」という目的要件を付した上でこのような骨子が示されているわけでありますけれども，ここで「作成」というのは，複写・複製ではなしに，新たに生み出すということでございまして，そうなりますと，この世に新たに生み出す，あるいはそれまでなかった人の手元にこういった社会に害悪を及ぼすようなものを出現せしめるということですから，それと，それを使うというのは，偽造罪等の一般の考えからすれば，同等の評価と申しますか，むしろ，作り出した人が一番悪い−−薬物のような考え方をしてまいりますと，むしろ作り出した人が一番悪い，あるいはそれを売った人が悪いという考え方も，禁制品的にとらえればあろうことかとは思われます。ここでは，電磁的記録であって，権利義務等に関するものでない，正にプログラムという，そういう性質の電磁的的記録でありますが，それを文書偽造なり電磁的記録などと同様の，偽造罪と同じような規制の仕方というものは，当然考え得る話ではなかろうかと思われるわけでございます。

むしろ，私文書偽造は５年ということにはなってございますけれども，実はウイルスの方が社会全体に影響を及ぼしていくという……。私文書の偽造罪は，社会的法益とは言われながら，法律的な話ではございませんが，社会的な実態とすれば，むしろ，名前を使われた人の個人法益的な，その文書限りの話になってくるわけでございますけれども，ウイルスは，禁止薬物等の禁制品あるいはそれ以外の危険なものと申しますか，世の中にとって，コンピュータ社会全体に害悪を及ぼしかねないものですから，それを作る，他人の手元に生じさせる，現に使う，この辺は３年ではむしろ軽いのではないかというのもそれなりに理由があるお考えかなとも思われますが。

法制審議会刑事法（ハイテク犯罪関係）部会第3回会議 議事録, 2003年5月15日

この委員は、私文書偽造罪は社会的法益だから偽造した時点で罪となるとされているものの、実態としてはその文書限りの話だという話と対比させて、不正指令電磁的記録では、文書偽造どころではない（禁止薬物等の禁制品なみの）危険なものという扱いをしている。ワームを想定すれば、その言い分も納得できるが、ハードディスク消去プログラムをトロイの木馬として供用するケースを想定すると、納得がいかない。

ハードディスク消去プログラムをトロイの木馬として供用するケースは、まさにこの委員が言うところの、私文書偽造罪において「名前を使われた人の個人法益的な，その文書限りの話になってくるわけで」という話に相当するだろう。つまり、文書偽造罪が、個々の被害を問題とせずに文書に対する社会の信頼という保護法益とされているのは、その限度の意味においてであるのに、この委員は、不正指令電磁的記録においては、それを超える危険を想定している。

次に、「人の電子計算機における実行の用に供する目的」の解釈がブレている（2月9日の日記で書いた「(A)解釈」「(B)解釈」のブレ）ところを見てみよう。

以下は、「ソフトウェアの開発会社等がセキュリティのチェックを行うためにウイルスプログラムを使う」場合を除外するために、目的要件をより明確にして「実行の用に供する不正な目的で」と修正するべきではないかとする提案（おそらくは日弁連による提案）に対して、（部会幹事から？）その必要はないと説明する部分。

●それでは，配布の論点メモに基づきまして，要綱（骨子）第一の論点について御説明をいたします。（略）

正当な目的で不正指令電磁的記録等を作成・供用等した場合の規定の要否につきましては，条約の６条２項のような規定を設けるべきではないか，あるいは「実行の用に供する不正な目的で」とすべきではないかという御意見がございました。

しかしながら，例えば，ソフトウェアの開発会社等がセキュリティのチェックを行うためにウイルスプログラムを人の電子計算機に記録する場合には，その者の同意を得ている以上，「人の電子計算機において実行の用に供した」ということは言えず，同様に，そのような目的でウイルスプログラムを作成したり，保管しても，自己の電子計算機あるいは同意を得ている者の電子計算機でのみ実行させる目的である以上，「人の電子計算機における実行の用に供する目的」に欠けることから，いずれの場合においても，犯罪が成立しないことは明らかであると考えております。したがいまして，御意見にありましたような規定を設ける必要性はないものと考えております。（略）

●今の点，細かい点ですけれども，ちょっと確認させていただきます。

要するに，目的が落ちる，目的に当たらないということですが，要綱の「人」というのは他人を指していて，同意がある人はここでいう「人」には当たらない，ですから「人の電子計算機における実行の用に供する目的」に当たらないということになって落ちると，そういうふうに理解してよろしいのでしょうか。

●ここで「人」は他人という意味で考えております。

それで，同じ理解になるのかもしれませんが，あくまでも，この罪というのは，プログラムに対する社会の信頼を害する罪でございますので，同意をしている人について信頼を害するということはない。偽造の場合，偽造だと分かっている人に行使と外形的に同じ行為をするのは行使に当たらないのと同じように，ここでは，同意を得ている人，分かっている人に対して使うというのは，ここでいう「人の電子計算機の実行の用に供する目的」には当たらない，そういうふうに考えております。

法制審議会刑事法（ハイテク犯罪関係）部会第3回会議 議事録, 2003年5月15日

「同意を得ている以上，『人の電子計算機において実行の用に供した』ということは言えず」というところまではよい。(A)解釈であれ(B)解釈であれ、同意を得ている場合は「人の電子計算機において実行の用に供した」ことに当たらないというのはよい。問題は、なぜ同意を得ている場合にはそれに当たらないのかという、その論理構成である。上の発言では、「人」というのが他人のことであり、同意を得ていれば他人ではないのだという。

ちょっとその理屈（同意があれば他人でない）は若干無理があるような感じがするところ、(B)解釈をしているならば、このような無理筋の理屈を出すまでもない。つまり、この発言者（幹事？）は、(A)解釈で話しているのではないかと窺われる。

(B)解釈の下では、「実行の用に供する」の意味が、単に人に実行させる（単にプログラムを渡す）という意味ではなく、「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、またはその意図に反する動作をさせるべき不正な指令を与える」ような実行の用に供するという意味であるから、「実行の用に供する」という条文自体が、同意を得ていないことの意味を含んでいる。上の発言者は、その法解釈ができていないから、「人＝同意がない」の理屈を持ち出さざるを得なくなっているのではないか。

このことは、法制審部会でも、続く発言で以下のように指摘されている。

●今の質問に対する事務当局の正確なお答えを聞きたいですね。

●今の目的の点から申しますと，私どもとしましては，文書偽造罪などの目的規定がございますね，供用目的という。あれと同じような形で理解しておるということでございまして，その場合に，それを相手が同意しておるとか，情を知っておるという場合には供用に当たらないというところで解釈なさるのか，人に行使という，「人」のところで外すのかという，現行法の理解，○○委員のような御理解もあるかもしれませんが，いずれにしても目的のところで外れるという理解をしておるということでございます。

●多分，実質的には理解は異ならないというふうに思うのですけれども，せっかく「人」と書いてあるのですから，その「人」という意義が当然問題になって， そこで外れると。行使の場合には「人」というふうに書いてございませんので，したがって，今の御指摘のような点が行使に当たるかどうかという議論を踏まえて解釈されるということになると思うのですけれども，ここの場合には書いてあるわけですから，それをやはり使った方がよろしいのではないかという趣旨で， 実質的には多分事務当局の御説明と何ら異なるものではないと思います。

●具体的にはどういうふうになりますかね。何か修正が必要になりますか。

●いえ，このままでよろしいのではないかということでございます。

法制審議会刑事法（ハイテク犯罪関係）部会第3回会議 議事録, 2003年5月15日

つまり、事務当局は、文書偽造罪における行使の目的とパラレルに不正指令電磁的記録での「供用目的」を捉えれば、それだけで同意がある場合は除外されるので、「人の」を持ち出すまでもないということを言わんとしつつも、「いずれにしても目的のところで外れる」のだからということで、「人の」を持ち出した発言者の解釈（＝「○○委員のような御理解」）を積極的には否定せずに、それもアリとしてしまっている。そして、「人の」を持ち出した発言者は、「実質的には多分事務当局の御説明と何ら異なるものではない」として考え方を改めていない。

この解釈のブレは些末なことかというとそうではない。同意がある場合に構成要件を満たさないとする論理構成が、「人の」に頼ったものであるかぎり、その思考に囚われた人は、(A)解釈をしていてもその誤りに気づかないことになる。その結果として、この法の立法趣旨を(X)と取り違えてしまっても矛盾に気づかないことになる。（その結果として、バグが罪に当たり得るとする解釈が今国会で出てしまった。）

法制審部会で、この解釈のブレが「実質的には多分事務当局の御説明と何ら異なるものではない」と、些末なこととして放置されたのは、単純なトロイの木馬のケース（ハードディスクを消去するプログラムの機能自体は、有益なものとして使われることもあるし、間違って実行させられて害が生じることもある）のことを想定できずに議論していた（プログラムには多態性があるという視点を欠いていた）からであろう。

法務省は、今年5月になって「いわゆるサイバー刑法に関するＱ＆Ａ」なる解説を新たに公開した。その中に以下の記述がある。

Ｑ４　コンピュータ・ウィルスの作成・提供罪が新設されると，ウィルス対策ソフトの開発等の正当な目的でウィルスを作成した場合や，ウィルスを発見した人がそれを研究機関に提供した場合，あるいは，プログラマーがバグを生じさせた場合まで処罰されることになりませんか。

Ａ　コンピュータ・ウィルスの作成・提供罪は，
(1) 正当な理由がないのに，
(2) 無断で他人のコンピュータにおいて実行させる目的で，
コンピュータ・ウィルスを作成，提供した場合に成立するものです。

ウィルス対策ソフトの開発などの正当な目的でウィルスを作成する場合には，そのウィルスを，自己のコンピュータにおいてのみ実行する目的であるか，あるいは，他人のコンピュータでその同意を得て実行する目的であるのが通常であると考えられますが，それらの場合には，(1)と(2)の要件をいずれも満たしませんので，この罪は成立しません。

また，ウィルスを発見した人が，ウィルスの研究機関やウィルス対策ソフトの製作会社に対し，ウィルスの研究やウィルス対策ソフトの更新に役立ててもらう目的で，そのウィルスを提供した場合についても，(1)と(2)の要件をいずれも満たしませんので，やはりこの罪は成立しません。（略）

いわゆるサイバー刑法に関するＱ＆Ａ, 法務省, 2011年5月

この、「無断で」という説明は、8年前の法制審部会の議論には出てこなかった新しい説明方法である。「人の電子計算機における実行の用に供する目的」という条文がわかりにくいものであるため、「無断で他人の」という平易な説明をしているのだろうが、単に「他人の」とせずにあえて「無断で他人の」としたのは、「他人の」が同意なしにという意味だとする上記の法制審部会の発言者の解釈を採用していないということの現れではないか。

つまり、法務省は(B)解釈のつもりではないかと窺われる（法制審部会での事務当局もそうだったはず）わけで、そのことをはっきりさせてほしい。

ちなみに、「無断で」という説明をすると、「トロイの木馬を実行したのは本人だから、無断ではない」という考えが出てくるかもしれないが、たしかに、プログラム全体を見れば、それを起動して実行開始させたのは本人の意思によるものであるが、プログラム中の個々の指令（法に言う「指令」）を見ると、その一部として含まれている「不正な指令」は、本人の知らないところで意図に反して「与えられる」ものであるから、そのことを指しての「無断で」という説明だと理解すれば、合点がいく。

■ 不正指令電磁的記録の論点、落穂拾い

「実行の用に供する」の条文が(B)解釈であり、立法趣旨が(Y)であることが確認されるとして、その後に残る論点について検討を加えておく。

複製された不正指令電磁的記録の作成者は誰？

甲が正当な用途を想定して作成し公開したプログラム（たとえば、ハードディスクを消去するプログラム）を、乙がその機能を偽って第三者に実行させるよう誘導（たとえば、「気象速報を随時受信するプログラムである」と偽って）した場合、乙の行為は不正指令電磁的記録供用罪を構成し、そのプログラムは不正指令電磁的記録に該当することとなる。このことは、平成23年5月27日の衆議院法務委員会の審議で確認されている。*1

では、甲が作成したプログラムも不正指令電磁的記録なのか。

解釈1

乙が供用したプログラムは不正指令電磁的記録であるが、甲が作成したプログラムは不正指令電磁的記録ではない。前者と後者のプログラムは客体として別のものである。乙が供用した不正指令電磁的記録の作成者は乙である。

解釈2

乙が供用したプログラムは不正指令電磁的記録であるが、甲が作成したプログラムは不正指令電磁的記録ではない。前者と後者のプログラムは客体として同一のものであるが、客体の不正指令電磁的記録該当性は、各実行行為ごとに評価される。乙が供用した不正指令電磁的記録の作成者は誰かという問い自体が意味をなさない。

解釈3

乙が供用したプログラムも、甲が作成したプログラムも、客体として同一のものであり、どちらも不正指令電磁的記録である。甲の行為が不正指令電磁的記録作成罪を構成しないのは、「人の電子計算機における実行の用に供する（注：(B)解釈の意味で）目的」がないからである。

もし解釈3がまかり通ることになれば、我々は、「世の全てのプログラムは不正指令電磁的記録である」（168条の2および3の目的がないから犯罪に該当しないというだけで）という理解を受け入れなければならなくなる。なぜなら、いかなるプログラムも、悪意ある者によってその機能を偽って人の実行の用に供され、人の意図に反する動作をさせる指令として使われてしまうことが可能だからだ。

技術屋感覚では解釈1でいいんじゃないか、複製された時点で別の客体だしね、と思ったりするが、法律論ではどうか。解釈1の場合、乙は作成罪にも問われることになる。その場合の裁判の様子を空想してみる。

検察論告：「複製した時点で別の客体であり、作成者は被告人（乙）である。」（解釈1）

弁護人弁論：「複製しても作成者は甲であり、被告人（乙）は作成者ではない。もし、複製した時点で甲が作成者でないことになるのなら、悪質なワームを作成した者（丙）がいたときに、丙が供用行為に至らず、他の者（丁）に複製を提供し、丁が供用行為に至った場合、丙を作成罪に問えなくなる。法はそのような事態を予定しておらず、よって、複製されても作成者は甲であり、乙ではないと言うべきである。」

地裁：「被告人（乙）の作成罪は成立する。弁護人は、複製者が作成者となるのなら、悪質なワームの原作者を作成罪に問えなくなくなると主張するが、複製者が作成者となることは、複製前のプログラムの原作者が作成者であることを否定するものではなく、弁護人の主張は理由がない。」（検察の主張を丸のみ＝解釈1）

高裁：「原判決を破棄する。被告人（乙）の作成罪は成立しない。同一内容の電磁的記録が同一の客体であることは、刑法161条の2電磁的記録不正作出・供用罪等においても当然の帰結であり、原判決の複製前の電磁的記録と複製後の電磁的記録を別個の客体とする解釈は到底採用できない。」（解釈3）

最高裁：「原判決を破棄する。本件を高等裁判所に差し戻す。不正指令電磁的記録作成とは、プログラムに対する信頼を害する不正指令電磁的記録を存在するに至らしめる行為を言うところ、本件甲作成の電磁的記録は甲が作成した段階ではプログラムに対する信頼を害する危険が生じたとは言えず、乙の供用未遂段階において初めてプログラムに対する信頼を害する危険が生じたのであり、甲作成の電磁的記録を不正指令電磁的記録に該当すると言うことはできない。原判決は刑法168条の2の解釈適用を誤ったものであって破棄を免れない。」（解釈2？解釈1？）

……とかいう展開になったら面白い。

これに類する展開はわりと現実に起きそうな気がする。Winny等で出回っているトロイの木馬を見ると、「仁義なきキンタマ」系のトロイを、ファイル名だけ変更（テレビ番組の名前などに）して再頒布したり、ZIPに固め直して頒布している者が散見される。この改正刑法が施行され、そうした輩が検挙されることとなったとき、元の「仁義なきキンタマ」系トロイの原作者を罪に問うことはできないわけだが、ファイル名を変えて流したり、ZIPで固め直して頒布した者を、（供用罪で起訴するのは当然として）作成罪で起訴するかしないかが問題となりそうだ。

それを作成罪で起訴した場合、裁判所の判断はどのようになるのか。こちらのケースでは、上の空想裁判のケースとは違って、どのみち原作者の行為も犯罪に該当する（法の不遡及により罪とならないが）ものであることから、単純に、「複製しても同一の客体である（複製前も後も不正指令電磁的記録である）」とする判例ができてしまう予感がする。*2

そのとき、我々は「世の全てのプログラムは不正指令電磁的記録である」という理解を受け入れなくてはならないのだろうか。

侵入ツールの単純利用は供用罪？

趣旨が(Y)であることが確認されて、文書偽造罪と同列の構造であることが明確になればなるほど、不正指令電磁的記録に関する罪は、要するにトロイの木馬（伝染の手段として人による起動を要するもの）に関する罪であり、「ウイルス作成罪」という呼称から連想しがちな、ワームなどの自己増殖による社会的危険の重大性に着目したものではないということになる。

そうなると、トロイの木馬ではない不正プログラム（脆弱性を突いて起動し、人による起動を要しないもの）、つまり、単なる侵入ツールのようなものは、この罪の対象ではない（供用罪に該当しない）ということになる感じがする。侵入ツールを用いて特定の電子計算機に侵入する行為自体は、不正アクセス禁止法によって既に犯罪とされており、その点に不都合はないように思われる。つまり、この罪はいわゆる「受動的攻撃」に対処するもので、いわゆる「能動的攻撃」は不正アクセス禁止法の領域だという整理である。

そうすると、侵入ツールの作成を処罰対象とするかという点が残るが、これについては、3月31日のニコニコ生放送「徹底議論！ウイルス作成罪」でも石井徹哉教授から解説があったところで、元々サイバー犯罪条約はそうした侵入ツールの規制を促すものであるところ、日本ではそのような立法を避けた経緯があると言われている*3。私としては、その判断は優れたものだったと思う。

では、トロイの木馬ではないワームの場合はどうか。つまり、脆弱性を突いて起動し、人による起動を要しないもので、かつ、自己増殖能力を持つ不正プログラムのことである。*4

「不正指令電磁的記録に関する罪」=「トロイの木馬に関するの罪」であるなら、人による起動を要しないものである以上、この罪の対象ではないことになる。といって、侵入ツールの使用と同様に不正アクセス禁止法で対処できるかというと、疑問だ。

元々、ウイルス作成罪の立法の必要性の根拠が、現行法で対処できなかったからであり、不特定多数に向けて「誰かに被害が出ればいい」というような意図で行われる行為を、どの罪で処罰できるのかという限界があったように理解している。加えて、不正アクセス禁止法は、禁止する行為を極めて具体的に規定してたものであることから、「誰かに被害が出ればいい」というような意図でばらまかれるワームについて、その頒布者を同法違反に問えない限界があるような気がする。

じゃあどうするのか。トロイの木馬でないワームを処罰できないようでは、「ウイルス作成罪」と呼ばれるにしては、あまりに無力だとの誹りを免れない。そうすると、人による起動を要しないものであっても、不正指令電磁的記録の罪の対象ということにするのだろうか。

8年前の法制審部会の議事録を見ると、事務当局（？）から以下の説明がなされている。

「実行の用に供する」という概念につきましては，当該電磁的記録を，電子計算機を使用している者が実行しようとする意思がないのに実行される状態に置く行為をいうものとして記載しております。

法制審議会刑事法（ハイテク犯罪関係）部会第1回会議 議事録, 2003年4月14日

これを読むと、パッと見では、脆弱性を突いて侵入するプログラムのことを指していて、逆に、トロイの木馬のことは指していないかのように聞こえる。トロイの木馬を起動するのは当人の意思によるもの（ダブルクリック等）であるはずだからだ。

これに類似した話として、前回の日記で次のように書いた。

ちなみに、「無断で」という説明をすると、「トロイの木馬を実行したのは本人だから、無断ではない」という考えが出てくるかもしれないが、たしかに、プログラム全体を見れば、それを起動して実行開始させたのは本人の意思によるものであるが、プログラム中の個々の指令（法に言う「指令」）を見ると、その一部として含まれている「不正な指令」は、本人の知らないところで意図に反して「与えられる」ものであるから、そのことを指しての「無断で」という説明だと理解すれば、合点がいく。

ウイルス罪法案、どうしてこうなった, 2011年6月9日の日記

これと同様に、上の法制審部会での説明「実行しようとする意思がないのに実行される状態に置く行為」も、プログラム中の個々の指令（法に言う「指令」）の単位で含まれている「不正な指令」について「意思がないのに実行される」という意味で言われているのだと理解すれば、トロイの木馬のケースについての言及と理解することができる。

そう理解することによって(B)解釈、(Y)の趣旨ということになるわけだが、逆に、脆弱性を突いて全自動で広がるワームのことは、この説明が指すものに含まれるのだろうか。

この文言自体からは含まれるように解釈可能（むしろ自然）だが、しかし、不正指令電磁的記録に関する罪の保護法益が、「プログラムに対する社会的信頼を害する行為を犯罪にするという考え方」（法制審部会議事録より）であるわけで、「脆弱性を突いて全自動で広がるワーム」が害しているものは、はたして「プログラムに対する社会的信頼」と言えるだろうか？ 害しているのは別のものではないかという疑問がある。

ワームを想定して考えるとわかりにくくなるので、単純な侵入ツールの使用を想定してみれば、それを「プログラムに対する社会的信頼を害する行為」と言うことはできないように思えるがどうか。*5

というわけで、もしかすると、トロイの木馬ではないワームは不正指令電磁的記録に関する罪の射程外かもしれない。

それを処罰できないのでは困るという点については、この刑法改正で同時に盛り込まれることになっている、電子計算機損壊等業務妨害の未遂罪の新設によって担保されるのかもしれない。法制審部会でも、事務当局（？）から以下のように説明されている。

次に，要綱（骨子）の第一の五でありますが，これは電子計算機損壊等業務妨害罪の未遂を処罰することとするものでございます。

これは，電子計算機損壊等業務妨害につきましても，今日，コンピュータ・ネットワークにより遠隔から敢行され，あるいは広範囲に被害を及ぼし得るものとなっておりまして，これを未然に防止する必要性が高いと考えられますところ，その未遂は，不正指令電磁的記録供用罪，あるいはその未遂罪に該当する場合も少なくないと考えられますが，これによる処罰のみでは必ずしも十分でないと考えられますことから，電子計算機損壊等業務妨害罪の未遂を処罰することとするものであります。

法制審議会刑事法（ハイテク犯罪関係）部会第1回会議 議事録, 2003年4月14日

これは、上記で検討したような整理を経てこの結論に至ったものなのか、単に念のためにそうしたにすぎないのか、どちらだろうか。

仮に、トロイの木馬ではないワームは電子計算機損壊等業務妨害未遂罪で担保するのだとすると、業務の妨害とは言えないケース、たとえば家庭での被害*6が保護の対象から漏れることになるが、ワームが無差別なものであるからには、どこかの業務も妨害することになる（その未遂が罪に問われる）であろうから、そのことは問題ないと言えるかもしれない。

そうすると、処罰対象から外れるのは、Winnyネットワーク等の、ほぼ全部が業務と言えない利用者であるところに対して、トロイの木馬ではない方法で（脆弱性を突くなどして人を介さずに）動作するワームを撒く行為ということになる。

それはそれで、保護法益を考えれば妥当であるようにも思われるが、結果として起きる被害を考えたときに、第三者（Winny等の利用者以外の）のプライバシー情報までもが暴露されることは社会として堪え難いことのはずであり、何らかの措置が必要であるように思われる。

その点、何を保護法益とするのかから改めて考え直す必要があるのではないだろうか。*7

■ 参議院法務委員会で参考人意見陳述してきた

本日の参議院法務委員会で参考人として意見陳述してきました。取り急ぎご報告。

• 参議院インターネット審議中継 第177回国会 法務委員会 平成二十三年六月十四日 （Windows Media Player ブロードバンド（300/150Kbps））

以下の資料を配布して、この内容で意見陳述しました。*1

• 「不正指令電磁的記録に関する罪」についての意見, 参議院法務委員会参考人配布資料, 2011年6月14日

委員の先生方から頂いたご質疑への答弁でも述べている通り、この意見で「明示すべき」としたそれぞれの点について、次回の法務委員会（16日）で明らかにされることが望まれます。

振り返ってみるに、若干、強調し損ねたかなと思うのは、問題となるのはバグの件だけではないということです。

バグの件については、おそらく明確な回答がなされるのではないかと思います。しかし、バグの件さえ解決すればよいというものではないのです。その背景にある、立法趣旨への理解、条文の解釈のブレが解決されなければ、バグの件以外でも同様の混乱が生じ得ると懸念しています。

したがって、意見書の中で「バグ以外で問題となるケース」、「正当なプログラムが他者により悪用されるケース」として示した疑問点についても、回答がなされることが望まれます。それによって、立法趣旨への理解、条文の解釈が明確にされるはずと考えています。

■ 修正されつつある未来 岡崎図書館事件(17)

先週の参議院法務委員会の参考人意見陳述では、具体的な事件のことに触れるのはよろしくないと思い、配布資料に図書館事件のことは書き込まなかったし、冒頭の意見陳述でも触れなかった。ところが、意外なことに、委員の方々から率先して岡崎図書館事件に触れられ、質問されることとなった。尋ねられたものに答えないわけにはいかないので、可能な限り主観を排して答えた。奇しくもこの6月14日は、岡崎図書館事件で起訴猶予処分が下されて一周年にあたる日であった。

○有田芳生君 （略）やはりきっちりしたすばらしいように見える法律であっても、現場レベルでなかなかその趣旨を徹底することができなくて、恣意的な運用がなされたり、あるいは放置をされたりということはありました。（略）

そのように、この法律ができたとして、やはり現場レベルで恣意的に運用してしまうというようなケースが例えば愛知県などでもこれまで起きてきたということを顧みますと、果たして、今、山下参考人が述べられたような、その歯止めというものをどのような形で保障していくのかというのは、実際には大きな課題だというふうに思うんですよ。

その歯止めというのをどのように置くべきなのか。きっちりとそういうものに対して監視をしていくということなのか、あるいは、短い審議時間ではあっても、そこに何らかの条件を付けていくことができるのかということを含めて、お三人の参考人の御意見を伺いたいと思います。

第177回国会 参議委員法務委員会 会議録（平成23年6月14日）

この委員の発言の時点では、「愛知県」が何のことを指しているのかわからなかった（他に説明もないので）のだが、その後、他の委員から口々に「岡崎市立中央図書館の事件」との具体的な指摘が出てきた。どうやら、委員の方々には事前に何か資料が配布されたのか、事件のことは既に理解が共有されている様子だった。

○渡辺猛之君 ありがとうございました。

私、先ほど申し上げましたけれども、余りネットに対して詳しくなく、今回、こうやって法務委員会で質問させていただくに当たってちょっと勉強させていただいたんですが、昨年の愛知県の岡崎市立中央図書館の事件のように、多分これ、捜査機関の方も、もちろん法を整備すると同時に、先ほどの恣意的な運用の件とも関係すると思うんですけれども、やっぱり捜査する側も相当な知識を持って当たらないと多分誤りが出てくるんじゃないかなということを思うんですが、その捜査機関の専門的知識をどのように高めていくか、あるいは、どれぐらいのレベルを確保すべきなのかというところで、参考人の先生方の御意見、聞かせていただけたらなと思います。

○委員長（浜田昌良君） それでは、前田参考人、山下参考人、高木参考人の順番でお願いします。簡潔にお願いします。

○参考人（前田雅英君） これは、解釈学者のテリトリーから超えることになるかもしれませんけれども、仄聞するといいますか、警察の研究会なんかに出ていることが多いので見ていますと、やはり今は物すごいスピードで追い付いていく。各警察大学校とかそこの、教養と彼らは言いますけれども、教育の中にそういうものを組み込んで、やはり、もう一つは情報通信局というのを持っていますので、そことのつながりを持ちながらどんどんどんどん追い付いていく。ただ、まだ補わなければいけないといいますか、努力しなければいけない面があるというのは先生の御指摘のとおりなんだと思うので、これは私がそうお答えするというよりは、これを聞いている警察庁で更に頑張っていただくしかないんだと思うんですけれども。

○参考人（山下幸夫君） 愛知県の不正アクセス事例*1については、大変不幸なといいますか、そういう誤解の下に行われたという点、しかも身柄拘束までされたという点で大変問題があったと思うんですが、そういうことがないためにも、やはりこれは専門の技術者を警察の中に配置する、それから、最近警察庁の方では、ネット捜査については中央集権的にといいますか、警察庁と各地方自治体警察が協力してやっていくというような体制も含めて検討されていると聞いていますけれども、やはりそういう専門的な知見を持った人が捜査に必ず加わるという形で、今回はとりわけネット関係の法整備をされるわけですので、きちっと整備していただきたい、そういう人をきちっと配置して誤りがないように運用していただきたいと思っております。

○参考人（高木浩光君） 今、委員御指摘の岡崎市立中央図書館の事件のケースを考えてみますと、このウイルス作成罪が成立した場合に同様の問題というのはやはり懸念されると思います。

その岡崎の事件についてどういうものだったかといいますと、あちらは偽計業務妨害罪に問われたもので、未必の故意があったとみなされて*2起訴猶予処分となったという事件でございますけれども、実名を報道されて逮捕されたということになっているんですが、やはりこの問題が難しかったのは、偽計業務妨害罪が比較的広く適用され、実際に故意でもって、ＤｏＳ攻撃と言いますが、サービス不能攻撃などとも言いますが、大量のアクセスをしてサーバーを止めてしまう。これ、わざとやれば当然業務妨害に当たる。しかし、正当な目的で情報収集のために連続アクセスをしていた*3ところ、たまたまサーバー側の不具合でもって止まってしまったという事件だったんですが、それが、捜査機関はこれは典型的なＤｏＳ攻撃だと誤解して捜査を開始したところ、そうではないということが分かったとき*4にどうするかですね。そこで、そうなることは分かっていたようだということで未必の故意というふうに判断してしまったよう*5ですが、非常にこの未必の故意を取られるというのは危ういものだと思います。

その点、このウイルス罪について考えてみますと、バグの話もありましたし、あるいはハードディスクを消去するようなプログラムを作って公開したときに責任がどうなるかという論点において、故意があったかどうかということが問題になるときに、やはり未必の故意を取られると考えると危ういと思います。

その点、先ほどの解釈が一つ目なのか二つ目なのかという論点において、そもそも解釈が二つ目の方であれば、すなわち人をだまして実行させるという、そこまで含んで実行という言葉が意味しているのだとすれば、それは故意どころか、そもそも実行行為自体がない*6というふうに言えるのではないかと思いますので、この解釈を明確にすれば、あのような不幸な事件というのは起きにくくなるんではないかというふうに思います。

第177回国会 参議委員法務委員会 会議録（平成23年6月14日）

○井上哲士君 ありがとうございました。

この法案の立法趣旨についてそれぞれ参考人からお話があって、人々をだまして実行される行為、その目的でのものを罰するものだと、こういうお話がありました。

一方で、例えばだますといっても、ちょっとしたいたずら程度のものを出すプログラムもあれば、ハードディスクを破壊してしまうような大変重大なこともありますから、どこからを罰するかという問題もやっぱりあろうかと思うんですね。その辺が逆に非常に捜査当局の恣意的な運用にもつながるんではないかなという思いもしているんですが、その辺の、どこら辺を可罰的違法性とするのかという基準等については、それぞれの参考人どうお考えかと。

特に高木参考人には、先ほどの岡崎の図書館の話もあったんですが、あのときに三万三千の不正アクセス*7と言われたけれども、一日二千回程度といえばネットの専門家からいえば全く当たり前のことだということも出ておりました。つまり、ネット専門家から見ればごく当たり前のことでも相手から見れば大変なことだったり、サーバーの容量によっても違ったりすると思うんですが、その辺の点で、どの辺りを可罰的違法性と線引きをしていくのかという点で、特にプログラムの専門家として御意見をいただけたらなと思います。

それぞれからお願いいたします。

○委員長（浜田昌良君） それでは、高木参考人、山下参考人、前田参考人の順番でお願いします。

○参考人（高木浩光君） お答えします。

岡崎の事件との比較という点でいえば、先ほど来述べておりますように、一つ目の解釈をするか二つ目の解釈をするか。

一つ目の解釈をした場合には、委員御指摘のとおり、捜査側の恣意的な運用で、警察官が情報技術に無知であるがゆえにこれは非常識なプログラムだと思ってしまうかもしれません。しかし、二番目の解釈の方、すなわち相手をだます意図があるという解釈であるというふうにすれば、それをさすがに客観的に確認するというのはそれなりにハードルがあるだろうと思います。それでもなお境界領域にあるケース、境界ケースとしては、ジョークプログラムのようなものをどう考えるかという辺り、それからスパイウエアまがいの宣伝プログラムですね。事業者が営利目的でもって若干人をだましてお金を取るというような場合が、果たしてこちらのウイルス罪の方で処罰するのかどうかという辺りが微妙な論点になってくるかと思うんですが。（略）

第177回国会 参議委員法務委員会 会議録（平成23年6月14日）

このように、岡崎図書館事件は国会会議録として歴史に刻まれることとなった。

そして翌々16日の参議院法務委員会で、この質疑がそれなりに踏まえられた審議が行われ、採決の後、付帯決議がなされることとなった。*8

• 第177回国会 参議委員法務委員会 会議録（平成23年6月16日）

ウイルス罪について国会で何を達成できたか、未来はどう修正されたか、あるいは何がまだ達成できていないのかについて、近日中にまとめたい。

関連

• このまま進むと訪れる未来 岡崎図書館事件(15), 2011年1月23日の日記
• ウイルス作成罪創設に向けて国民に迫られる選択, 2011年2月9日の日記

■ りぶらサポータークラブによる“Librahack”フォーラムの公式記録 岡崎図書館事件(16)

3月上旬の時点では「被害届取り下げ」の問題がまだ燻っていた*9ものの、未曾有の大震災と原発大事故によりそれどころではなくなった感のあった岡崎図書館事件だが、3月30日にりぶらサポータークラブから、「“Librahack”フォーラムの公式記録」が公開されていた。

• “Librahack”フォーラムの公式記録が完成, りぶらサポータークラブ, 2011年3月30日

12月18日にりぶらサポータークラブ主催で開かれた「ネット時代の情報拠点としての図書館─ “Librahack” 事件から考える─」（2010年12月27日の日記参照）の様子が冊子にまとめられたもので、写真付きで当日の雰囲気がとてもよくわかるすばらしい編集となっている。おすすめの見所は、カーリルの吉本氏が飛び入りでいろいろ重大な発言をされてるところだと思う。

新しい情報としては、当日とられたアンケートから参加者の感想などが掲載されており、また、その後の展開についても掲載され、「"Librahack"共同声明」の掲載に続いて、「フォーラムのその後(3) "Librahack"共同声明の補足」として、それまでに未発表だった以下の説明が付け加えられている。

• 1. 中川氏の行為について……に関する誤謬
• 2. 障害と混乱の真因について……に関する誤謬
• 3. 中川氏の名誉回復について……に関する誤謬
• 4. 被害届の取り下げについて……に関する誤謬
• a) 中川氏が行ったのは「取り下げのお願い」です
• b) 中川氏が示したのは「理解」です
• c) 取りさげに関する手続き上の理由
• d) 1と2と4を誤用しないで下さい
• 5. Web技術の発展について……に関する誤謬
• 被害届の取り下げに関する取り組みについて
• 中川氏を図書館協議会委員に……との提案について

冊子の最後には「公式記録の先にあるもの」として、「オープンソース系システムの研究」が挙げられており、「フォーラムで示された『未来』を具現化するために、専門家の協力を得ながら進めてまいります。これは、図書館システムに対するセカンドオピニオン的な機能を発揮すると同時に、より実効性のある具体的なシステムの構築を目指すものです。図書館に対しても、研究の実現性を高めるために、今後のシステム導入に関して申し入れなどをしています。」と書かれている。今後の展開に期待したい。

一方の図書館と三菱電機ISはというと、4月1日、事件の元凶だったと言える図書館長、三菱電機ISの幹部は、人事異動で別のところへいかれてしまった。新たに着任された方々がこの問題をどのように認識されているのかは、まだ明らかになっていない。

■ 技術音痴な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日 （いつでも視聴可能になりました）
  

■ SoftBankガラケーの致命的な脆弱性がようやく解消

ソフトバンクモバイルのガラケーWebブラウザで、https:接続する際の仕様に変更があった。昨年10月に予告が発表され、元々は2月に実施される予定だったのが、6月30日に延期されていたもの。これまで、https:サイトへのリンクのすべてが https://secure.softbank.ne.jp/ 経由に書き換えられる仕様だったが、この機能が廃止された。

• ソフトバンクモバイル、携帯サイトの仕様変更で注意喚起, ITmedia, 2011年6月30日
• Yahoo! ケータイ、2011年2月に仕様変更 ユーザーとサイト開発者に注意喚起, ITmedia, 2010年10月15日
• MOBILE CREATION - WEB & NETWORK SSL/TLS, ソフトバンクモバイル
  

これは、昨年6月に、ソフトバンクモバイル宮川CTOにTwitterで約束を取り付けていた*1もので、このとき一般には、SSL使用時におけるcookieの非標準的な挙動を排するためのものと受け止められたかもしれないが、じつはそういう趣旨のものではなく、致命的なセキュリティ上の欠陥を排除するための措置である。

経緯

ソフトバンクモバイルのガラケーWebでは、かなり古くから（JPhoneだったころから）、https:サイトへの接続方法が、他キャリアとは異なるものになっていた。他キャリアでは、インターネットにおけるごく普通のSSL接続と同様、ブラウザからWebサーバまでを直接SSLで接続するもの（end-to-endのSSL）であったのに対し、ソフトバンクモバイルでは、HTML中のリンクのURLを書き換えて、例えば、https://example.com/index.html へのリンクをすべて、https://secure.softbank.ne.jp/example.com/index.html へと強制的に変更して、secure.softbank.ne.jp のゲートウェイ上で通信内容の書き換えを行うようになっていた。通信内容書き換えの目的は、ケータイID（X-JPhone-UID）の付与などであろう。

図1: ソフトバンクモバイルによる旧仕様の説明

ガラケーが昔ながらのガラケーであった数年前までは、この仕様も、「まあ許されないとまでは言えないもの」と思っていた*2。なぜなら、ガラケーにはJavaScript機能がない。アドレスバーもないので、アドレスバーによる本物サイト確認は元々できない。*3*4

ところが、昨年の4月、これがまずいことになっていることに気づいた。

事の始まりは、一昨年、NTTドコモが「docomo 2.0」としてJavaScript導入に踏み切った際、徳丸浩氏が「iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性」を指摘したことに遡る。その後、徳丸氏から、じつはソフトバンクモバイルでも端末の一部で同様の問題がある（のだが、回避策がないので公表ができない）という話を打ち明けられた*5。その時点まで、ソフトバンクモバイルの端末にJavaScript機能はないと思っていたのだが、いつの間にか、仕様にないのに一部の端末でJavaScript機能が搭載されているという話だった。自分がテスト用に持っていた端末816SHで確かめてみると、たしかにJavaScriptが動いた。

実証実験

これはまずいかもわからんね、ということで、具体的な危険を確認するため、Gmailを対象にして実験を行った。以下はそのときの記録である。

図2: 実証実験の様子（テスト用画面）

この画面は、私の管理するWebサーバ（攻撃者のサイトと想定）にhttps:のページを作り、以下のHTMLを記述して、IFRAMEとしてGmailサイトを埋め込んだ様子である。画面の上半分がIFRAME部分であり、Gmailにログインした後の状態で試したため、IFRAME中に私のGmailの受信トレイが表示されている。画面の下半分はテスト用のHTML（攻撃側の想定）である。

<iframe src="/mail.google.com/" id="foo"></iframe>
<script>
  function d() {
    return document.getElementById("foo").contentDocument;
  }
</script>
<a href="javascript:alert(d().body.innerText)">Get text</a><br>
<a href="javascript:alert(d().body.innerHTML)">Get html</a><br>
<a href="javascript:alert(d().cookie)">Get cookie</a>

IFRAMEタグでは、SRC属性に「/mail.google.com/」と指定しているが、このページ（https://takagi-hiromisu.jp/test.html）をソフトバンクモバイルの端末で訪れると、表示されるページのURLは、https://secure.softbank.ne.jp/takagi-hiromitsu.jp/test.html（※1）となり、IFRAMEの部分のURLは、https://secure.softbank.ne.jp/mail.gmail.com/（※2）となる。

これは、Webセキュリティの基本*6である same origin policy（同一生成元ポリシー）でいうところの「生成元」が、私の攻撃テスト用ページとGmailページとで同一（https://secure.softbank.ne.jp）になっている。

ということは、私の管理下にある※1のJavaScriptから、※2のコンテンツにDOM経由でアクセスできるということになるはずである。

以下の図3は、上の図2の「Get text」「Get html」「Get cookie」のリンクを踏んだときの様子である。

図3: 実証実験の様子（テスト用リンクを踏んだとき）

このように、Gmailの内容やcookieの内容を攻撃者側から取得できてしまっていることがわかる。同様にして、Gmail側を操作することもできるだろう。

つまり、ログイン中のサイトの情報を盗み出されたり、勝手に操作されてしまう被害（セッションハイジャックされたときと同等の被害）が出る危険があるということである。（Gmailに限らず。）

どう対処したか

これを脆弱性届出窓口に届けるべきか迷った。届けてしまうと、発見者には、取り扱いが終了するまで公開しないよう「お願い」されることになる。しかし、おそらくこの件は長期間直されないまま結果が出ないと予想され、その間何も言えなくなることの方が問題だと考えた。

この問題は、製品の脆弱性ではないし、Webサイトの脆弱性でもない。ソフトバンクモバイル向けにガラケーサイトを提供しているすべてのサイト運営者にも関わることであり、言わば「プロトコルの脆弱性」に類するものと考えた。脆弱性届出のガイドラインでは、次のように書かれている。

III.本ガイドラインの適用の範囲

・国内で利用されているソフトウエア製品
国内で、多くの人々に利用されている等のソフトウエア製品が該当します。「暗号アルゴリズム」や「プロトコル」を実装しているものも含みますが、一般的な「暗号アルゴリズム」や「プロトコル」等の仕様そのものの脆弱性は含みません。

情報セキュリティ早期警戒パートナーシップガイドライン

迷っている間に、何人かの脆弱性発見に慣れた方々に、「こんな脆弱性があるのですが、どうすべきですかね」と話しかけてみたところ、「その件は先日届け出た」という情報を得た。なるほど、既に先に気づいて届け出た人がいると。ならばということで、私としては届出をしないで、独自の活動をすることにした。根本的な解決は、端末の修正ではなく、この方式の廃止だと考えたからである。*7

そして、昨年6月、iPhone用の電波チェッカーの件でソフトバンクモバイルの宮川CTOとTwitterでお話をすることができた際に、ついでに、この件についてもお願いをしてみた。

実は、このやりとりの途中で、SBCSIRT（Softbank Telecommunications Security Incident Response Team）宛に、詳しいことを書いた以下のメールを送っていた。

Subject: secure.softbank.ne.jpの件 （Re: 脆弱性通知: 「電波チェッカー」で...）
Date: Wed, 16 Jun 2010 11:25:41 +0900

SBCSIRT〓〓様

（略）

別件についてここで続けさせていただいてよろしいでしょうか。secure.softbank.ne.jp についてです。

ソフトバンクモバイルの携帯電話のWebブラウザで、https:// のページにアクセスすると、secure.softbank.ne.jp を通すようにリンクが書き換えられる仕組みになっています。（以下参照。）
http://creation.mb.softbank.jp/web/web_ssl.html

これは「ユーザID」をSSL通信時にも利用できるようにするためなどの措置であると理解しています。

しかしこれは、JavaScript機能のある端末では重大なセキュリティ欠陥となります。

なぜなら、すべての https:// のサイトが同じ secure.softbank.ne.jp のドメイン上で表示されるのですから、Webのsame-origin policyが完全に破れ、任意ドメインのサイトから任意ドメインのサイトにアクセスできてしまいます。

たとえば、Gmailをソフトバンクモバイル端末で使うとき、普通にログインしますと、
https://secure.softbank.ne.jp/mail.google.com/.....
というURLで、ログイン状態になります。このとき、ログイン状態の維持は、secure.softbank.ne.jp に対して発行されたcookieによってブラウザ上で制御されます。

ということは、
<iframe src="/mail.google.com/" name="foo"></iframe>
というHTMLを、攻撃者の https:// サイト上に設置すれば、攻撃者は、alert(foo.document.body.innerText); といったJavaScriptでGmailのテキストを取得することができてしまいます。同様に、
alert(foo.document.cookie);
といったJavaScriptで当該cookieを取得することもできてしまいます。

ログイン中の画面を盗み読むことができるだけでなく、任意の操作も可能ですから、致命的な欠陥と言えます。

私がこの問題に気づいたのは、今年4月のことでした。もっと早く気づくべきだったと悔やんでいますが、ソフトバンクモバイルの一部の端末でJavaScriptが動くということを知らなかったためです。フルブラウザとケータイブラウザが分けて提供されている意味は、ケータイブラウザにはJavaScriptを搭載しないというつもりなんだろうと思っていました。

この問題について、私は、IPAの脆弱性届出窓口には届け出ていません。その理由は以下の理由からです。

1. この問題は、特定のWebサイトの脆弱性でもないし、ソフトウエア製品の脆弱性とも言い難い。いわばプロトコルの脆弱性であり、IPAの届出制度の取り扱い対象外だと思う。

2. 修正によって解決する方法がないと思われる。この仕組み自体を廃止して、各Webサイト側が対処するしか解決しないと思われる。

3. 何か月か前に同じ問題について既にIPAに届け出た人がいるという情報を得た。

ここで直接そちらに連絡を差し上げているのは、問題解決が困難と思われるからです。

上で「修正によって解決する方法がない」と書きましたが、修正方法として考えられるのは以下などの候補だと思いますが、それぞれ不適切であると思います。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

=> この方法は、どんな副作用が出るか予想もつきません。すべての機能が期待した通りにうまくいくかどうか大いに不安です。今後新機能が追加されるときに何が起きるかもわかりません。

(b) https://secure.softbank.ne.jp/www.foo.com/bar.html という形態をやめて、https://www.foo.com/bar.html の通信を直接書き換えるようにする方法。通信内容を書き換える（ユーザIDの付与等）ためには、SSL通信の中継をする必要があるので、man-in-the-middle attackと同様の方法によって実現する。このときに、端末側でSSLサーバ証明書のエラーが出てしまうのを避ける必要があるので、ゲートウェイ上で、アクセス先ドメイン用の偽の証明書をオンデマンドに自動生成し、その発行者となる独自CAのルート証明書を事前に全端末にインストールしておく。

=> この方法は、実現可能（偽証明書のオンデマンド生成は、企業向けの監視システムで実現されていると耳にします）と思われますが、偽証明書によるSSLというものをはたして、電気通信事業者がやってよいのかという疑問があります。私企業が社内ネットワークの監視目的で導入するのは許されても、電気通信事業者が一般向けのサービスにおいてそれを実施するのは、電気通信事業法違反かどうかわかりませんがスレスレだと思いますし、倫理的に許されないと思います。

(c) ゲートウェイ上のフィルタリングでなんとか攻撃を防ぐ方法。

=> 無理だと思います。

(d) JavaScript機能を凍結する方法。全端末を修正してJavaScript機能を凍結する。

=> 2010年夏モデルからJavaScriptを公式にサポートすると発表されているので無理ではないでしょうか。

以上のことから、secure.softbank.ne.jp は廃止するしかないと思います。

廃止によって何が失われるかですが、ユーザID付与の機能について言えば、元々、SSL経由で送られてきたユーザIDは、偽装されている可能性があるため、認証に使用することができません。

なぜなら、ソフトバンクモバイルは、現在、特定のAPNとProxyを使用することで、PCからゲートウェイ経由でアクセスすることができるため、
http://creation.mb.softbank.jp/web/web_ip.html
のIPアドレスでアクセス制限しているWebサイトであっても、任意のHTTPリクエストを送られる可能性がある状態であり、PCから直接SSLで接続されると、任意のX-JPhone-UID: を送られてしまうのですから、SSL経由でのX-Jphone-UID: はいずれにせよ使用できない状態です。

したがって、secure.softbank.ne.jp は廃止してしまってよいと考えます。

私は、この問題が放置されることを懸念しています。修正による解決が困難で、廃止するしかないときに、廃止の決断ができないで、半年、1年、あるいは何年も放置されるのではないかと懸念しています。

私としては、各Webサイトの安全を守るために、対策方法を周知していかなければならないと考えています。その一つは、secure.softbank.ne.jp を通さないようにするためのリンク方法を見つけ出して周知していくことです。

しかし、周知するにあたって、なぜそうしなければならないかの理由を説明しなければなりません。そのためには、この問題があることを説明せざるを得ません。

一般的には、脆弱性が修正されるまで、もしくは脆弱性を通知してから一定の期間は脆弱性の内容を公表することは控えるべきという考え方が、責任ある情報開示の手順とされていますが、今回のように、修正が見込まれないものについては、回避策を周知することも正当であると思っています。

しかし、できれば、ソフトバンクモバイル自身によってそれを行っていただきたいと思います。つまり、まず、secure.softbank.ne.jp の廃止を予告したうえで、暫定措置として、secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知することです。そのためには、廃止の妥当性を説明するために、そもそもSSLで送られてきたX-JPhone-UID:を使用してはならないことの周知も必要と思います。

いかがでしょうか。

高木 浩光＠自宅

これ対するSBCSIRTからのお返事は頂けなかったが、上のように宮川CTOとTwitter上で直接対話することとなった。

ソフトバンクモバイルの対応は適切だったか

正直、いくら「廃止するしかない」とお願いしたところで、実現は無理かもしれないと悲観的に思っていた。なぜなら、廃止すると不具合の生じるWebサイトがあちこちにありそうで、そこからの苦情対応に追われることになりそうだからだ。

一方で、昨年5月の時点で、2010年夏モデルから、ソフトバンクモバイルは、Ajaxなどに対応し、正式にJavaScriptをガラケーWebに搭載すると発表されていた（ケータイWatchの記事）。

その後、その夏モデルの一つである「944SH」について、徳丸氏が購入してテストしたという知らせが入った。それによると、新端末では、上記のSBCSIRTへのメールの中で書いていた(a)の対策がとられているっぽいとのことだった。

(a) 全端末のブラウザを修正して、ホスト名が secure.softbank.ne.jp のときだけ特別扱いをし、パス名の最初の部分を仮想的にドメインとして扱う方法。

944SHの発売日は2010年6月18日なので、Twitterでのやりとりから2日後である。つまり、これが「お願いへの対応」ということはないだろう。おそらく、別の方が先に（数か月前に）脆弱性として届け出ていた件への対応、もしくはソフトバンクモバイルが自力で気づいて対応していた結果であろうと考えられる。

一方、従来機種でJavaScriptを勝手にサポートしていた機種については、危険が残ったままということになるが、ソフトバンクモバイルは、別件の脆弱性への対応で、2010年5月27日の時点で、それらの機種ではJavaScriptをオフに設定するよう告知していた。*8

• ブラウザのセキュリティ設定に関する重要なお知らせ, ソフトバンクモバイル, 2010年5月27日（2010年7月2日更新）
• ソフトバンク107機種のブラウザに不具合――個人情報詐取の恐れも, ITmedia, 2010年5月28日
• 今ソフトバンクから携帯電話のスクリプトの設定を OFFにしてくださいとメールが入..., Yahoo!知恵袋, 2010年7月14日

ソフトバンクモバイルによる告知はわりと徹底されていたようで、メールによる告知もされていたようだし、旧機種の販売においては、JavaScriptをオフにするよう説明した紙を同梱していたようだった。（そのわりには、「ソフトウェアアップデート」によるJavaScriptオフ設定への強制変更という措置はとられなかったが。*9）

そうすると、ソフトバンクモバイルとしては、この事案も含めて「もう解決済み」というスタンスなのかもしれないという話になる。secure.softbank.ne.jp廃止の約束はどうなったのか。このまま「解決済み」として、廃止の話は立ち消えになってしまうのではないかとの不安がよぎる。

対処済みと言えるならば、脆弱性情報を公表して、危険性を呼びかけるということも考えられた。しかし、せっかく、宮川CTOがTwitterの場で廃止を約束してくださっているのだから、それを信じたいと思い、しばらく静観することにした。

そして、Twitterでのお願いから4か月後の10月15日、ソフトバンクモバイルから、secure.softbank.ne.jp廃止のお知らせが出た（ITmediaの記事）。廃止の実施はそれからさらに3か月半後の2月1日だという。ずいぶん時間がかかるなと思ったが、廃止が決定されただけでも大いなる英断であると思ったので、とやかくは言わなかった。

それがその後、廃止が2月1日から6月30日へと、5か月も延期されたときには、さすがにいかがなものかと思った。脆弱性の解消である旨も伝えられておらず、ITmediaの記事でも「サイト開発の利便性向上などを目的に」と伝えられているだけだった。

おそらくは、いわゆる「公式サイト」などソフトバンクモバイルと契約のあるサイトに対しては、事前に情報が伝えられて、サイト改修の必要性について説得が試みられていたのだろうと思うが、5か月もの延期が、そうした提携先のわがままによるものだったとすれば、情報を知らされないまま危険を放置することになった一般のWebサイトにとっては、やりきれないものがあるのではないか。

私としては、SBCSIRTへのメールの中で、暫定措置を提案していた。「secure.softbank.ne.jp に書き換えられない https:// のリンク方法を用意してそれを周知すること」と具体的に提案したのだったが、それは実現されなかった。

secure.softbank.ne.jpの機能が生きている限り、Webサイト側での自衛策はそれしかない。また、それさえ提供されれば、廃止までに各Webサイトで事前に対処できるわけで、スムーズに移行できたはずではないか。実現が不可能だったのだろうか。

Webサイト運営者らの反応と対応

secure.softbank.ne.jpは6月30日の早朝に廃止され、Twitterでいくらか反応が出ていた。ざっくり集めたものを以下に示す。

• Togetter - 「secure.softbank.ne.jp廃止時におけるWebサイト運営者らの反応」, 2011年6月30日

やはり、不具合が生じているようだが、secure.softbank.ne.jp廃止は、避けて通るべきではなかった重要な措置であるのだから、こうした措置を遅らせるようなことを言わないようにと願う。

その他、検索して調べてみたところ、2月の時点でもいくらか反応が出ていたようだ。

• Togetter - 「ソフトバンクSSL仕様変更について」, 2011年2月1日

また、この仕様変更によってどのような不具合が生じ得るかについてのまとめもあった。

• SoftBank SSL仕様変更への対処まとめ, 株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報, 2010年11月16日

ここに記載されている情報によると、「SSP（SoftBank Solution Provider）認定企業に限り、申請すれば2月以降も「GW中継SSL」を利用できるようだ。SSP認定企業ならこの方法も選択肢に入れて対処できる」とある。

しかし、そうした申請をする企業は、secure.softbank.ne.jpを使い続けることの危険性を知らされているのだろうか。*10

廃止の理由を単に、「セキュリティの向上。従来はゲートウェイサーバーが一旦SSLを解いていたが、今後は端末とWebサーバー間でSSLが解かれることがない」というものとして解釈していると、「うちのサイトではSSLが解かれても別に問題ない」と、誤った判断をしてしまう虞れがある。

不具合の出たWebサイト運営者におかれては、大変なこととはお察しするが、廃止の重要性に鑑みて、粛々と対応を進めて頂きたい。間違っても、secure.softbank.ne.jpを復活せよなどと要求するようなことはしないで頂きたい。

かんたんログイン廃止、ケータイID廃止に向けて

ソフトバンクモバイルは、2010年10月の時点で、この件についての利用者向けのお知らせを出している。

• 携帯サイト閲覧時の重要なお知らせ, ソフトバンクモバイル, 2010年10月15日
  

上のように、いわゆる「かんたんログイン」が（SSLサイトで）使えなくなることを知らせている。

昨年4月27日の日記「まだまだ他でも破綻しているケータイID認証 」で「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」とまとめたように、ソフトバンクモバイルの端末において、httpsサイトでケータイIDのなりすましを防ぐ方法は存在しない。

ケータイIDを使った「かんたんログイン」なる方式は、そもそも安全に実装できないのだから、この際やめてしまうべきであることは、これまでにも述べてきた通りである。

今回の事態からも、キャリアがインターネット標準から離れた独自方式を安易に投入して、技術コミュニティとのオープンな議論を断絶するようなやり方は、将来に長期にわたってやっかいな問題を引きずりかねないもので、いずれ自分の首を絞めることになるものと、そのような教訓が得られるはずではなかろうか。

その他の類似のケース

ガラケーWebでない、一般のインターネットのWebにおいても、1990年代には、DeleGateを用いて、「-_-」記法を用いて http://www.delegate.org/-_-http://example.com/ の形式で利用する中継サーバを立ち上げて、漢字コード変換や、大阪弁変換フィルタのようなサービスを提供するなどのことが行われていた。

今から思えばおおらかな時代であったわけだが、21世紀になると、JavaScriptが定着し、cookieを用いたログイン機能を持つサイトが当たり前となり、Webの仕組みがsame origin policy（同一生成もとポリシー）に強く依存して成り立つ時代になると、そのようなサービスは危険を生じさせ得るものとなっていた。

今でも、URL中に中継先を指定するサービスが残存しているところがあると思うが、そういうサービスで、中継先のサイトにログインしないように注意しないといけない。いくつかのそうしたサービスでは、そうしたログインができないようにcookieを削ったり、ログインを要するサイトへの中継を遮断するなどの対策をとっているようである。

そうしたサービスで対策のないものは、脆弱性に該当すると言える場合もあるかもしれない。

関連（この問題に気づいたころに書いたもの）

• ここまで破綻しているケータイID認証（簡単ログイン）, 2010年4月25日の日記
• まだまだ他でも破綻しているケータイID認証, 2010年4月27日の日記
• EMOBILEのX-EM-UID、はじめから破綻, 2010年4月28日の日記
• 共用SSLサーバの危険性が理解されていない, 2010年5月10日の日記
• クッキー食えないのはドコモだけ, 2010年5月20日の日記
• 今こそケータイID問題の解決に向けて, 2010年6月19日の日記