Windows 10

このところ何かと忙しく、少し間が空いてしまいました。

英語関連で書きたい事が幾つかあるのですが、今日は時間がないので英語とは関係ない話を軽く。

金曜日に（正確には、日本時間土曜日の18時59分に）、あのWindows 10への無償アップグレード期間が終了したのはご存知の方も多いと思います。

私はWindows 7, 8.0, 8.1, Vista, OS X, 各種Linux と公私で色々なOSを使っている人ですが（さすがにXPはもう無い）、Windows 10だけは触ったことがないので、金曜日の夜中にWindows 8.0マシンを10にUGしようと思い立ち、トライしてみました。

結果は、、、見事に失敗。UGについてはすんなりと行かない場合も少なくないようですが、今回の原因は私の側にありました。詳しい方はお分かりだと思いますが、8.0から10へのUGを行うことはできず、一度 8.1 に上げた後、さらに10に上げる必要があります。

なので、まずは8.0を8.1にUGしようとしたのですが、これをやるにはまず8.0の上で、windows updateの”重要”カテゴリの更新プログラムを全て適用しておく必要があります。結局、この作業を丸一日かけても終えることができず、win 10へのUGはタイムオーバーとなってしまいました。

原因は、間抜けな話なんですけど、win 8.0マシンを仮想マシンで作っていたためにディスクの容量が足りず、更新プログラムのダウンロードに失敗してしまっていたのです。8.0のマシンは普段ほとんど使っていなかったので更新プログラムが溜まっていたのと、仮想マシンのディスクの切り方が少なかった（という事に気づいていなかった）のでそれがダウンロードできなかった、というオチでした。

ダウンロード中に”ディスクが足りないよ”と教えてくれればいいものを。。。結局、最後の最後にエラーメッセージを見て気づいてしまった次第。この時点でもうwin 10へのアップグレードは絶望的だったのですが、せめてwindows updateくらいは終えておかないとセキュリティ上よくない、ということで、ディスククリーンアップを駆使して、何とかwindows updateだけは無事に終え、これにて終了となったわけです。8.1へのUGも難しいでしょう。

まあ、手元に色々なOSを残しておきたい人なので、8.0が残ったのは、それはそれで良かったです。これからはもう少しちゃんとメンテナンスしながら使わなきゃ。win 10 は、、たぶん自腹で買うんだろうな。

理系教育

今日は少し志向を変えて理系分野の話をまったりと。

昨今、小学校でもプログラミング教育を必須化しようなんて議論があるようですが、個人的にはいい方向の話だと思います。

日本は米国に比べてソフトウェア分野が非常に弱い、なんてことを今さら声高に叫んでも滑稽なくらい、それは当たり前の話ですのでここでは触れません。今日は、理系人間の端くれとして、”プログラミングだけ”教えても駄目、というか、それだけでは日本人の間に真のソフトウェア文化は根付かないかもしれない、という話をします。特に明確な根拠もない、完全に個人的な見解ですが。

端的に言うと、これから日本を背負う若い人たちが、本当にソフトウェアがやりたいと思うようになって、かつ、大きな成果として花開かせるためには、プログラミング教育と同時に、以下のような事を充実させる必要があると感じています。特に上の3つ。

（1）起業しやすい環境の整備
（2）言語・ディベート教育
（3）数学教育
（4）地域格差の是正
（5）ハードウェア教育

（1）について。ソフトウェアのいい所は何と言っても、大した元手なしにモノが作れるという所です。コードを打ち込むPCさえあればいい訳ですから。つまり、アイデアを即、形にできるということ。でも、折角それで金儲けしようと思っても、今の日本じゃ怖くてできませんよね。一旦落ちぶれたら再起不能というのもありますが、ベンチャーキャピタルみたいな金を出してくれる組織・仕組みがまだまだ浸透してない。私はビジネスの専門化ではないので詳しいことは分かりませんが、現状の日本では、お金儲けを考えるときのモチベーションにはまだまだ成りにくいでしょう。お金儲けにつながる希望が無いモノを、普通は真剣にはやりません。

（2）。私はこれが非常に重要、というか、欧米との差が一番大きいのがこれではないかと思っています。欧米の方と話をすることがたまにありますが、特にアメリカ人、まあよく喋ること。驚くくらい”語る”んですよね。日本人に大きく欠けている能力だと思います。

これはIT系の人だけではないです。例えば向こうのアーティストのインタビューなんか聞いてても、物凄く語りますよね。必ずしも学があるとは思えない（失礼）ミュージシャンみたいな人でも、自分の子育て論とか、喋る喋る。なんなんでしょう、あの自己主張力。

彼らがああである本当の理由はよく分かりませんが、ソフトウェアってとどの詰まり、自分のアイデアの丈を思う存分”書き綴った”ものなんですよ。いわゆる良いソフトのソースコードを読んでいると、作った人のそういう思いの丈がヒシヒシと伝わってくるんです。迫力があります。筋道立ててしっかり自己主張できない人間には、良いソフトウェアは書けないと思います。日本の小中学校、そういう教育、してませんよね。まあ、日本人気質の奥ゆかしい良い部分を破壊することになってしまうかも知れないですけど。

（3）。単にプログラム言語に詳しいだけでは、まともなソフトは書けません。無限ループに落ちないか、いかなる場合もちゃんと終了するか、などなど、プログラムの動作をきちんと検証する論理的思考力が最低限必要です。しかし、もっと重要なのが、本当に斬新なアプリケーション、工業的価値の高いアプリを書こうと思うと、数学的な素養が要求されるケースが非常に多いということです。画像処理とか信号処理とか、ネットワークを扱うソフトとか、はたまた昨今はやりの機械学習とか、数学の塊ですよね。

数学教育というと、受験数学みたいな”パズルを解く営み”を想像する方が多いと思いますが、学術やエンジニアリングの場面で必要になる数学はそういう物ではなくて、自然現象を”記述”する、言語としての数学を操る能力です。だから、別に天才的なひらめきとか、そんなものはいらない。ソフトで扱いたい現実世界をモデル化して、式で書ける。そういう基本的な素養があればいいんです。というか、数学の本来の営みはそういうものであって、パズルを解くことではありません。サイン・コサインなんて受験が終わったら絶対使わない、なんてのは完全に都市伝説です。数学が学者やエンジニアだけのものであるという文化レベルのままでは、ソフトウェア文化が広く浸透していくことはないでしょう。

（4）、（5）はオマケですが、相互に関係が深い話です。ソフトと言っても結局はコンピュータの上で動くものですから、当然ながらハードの知識も持っている人間の方が活躍の場が広くなります。しかし、電気電子系の教育、ましてやコンピュータ”システム”の教育なんてほとんど成されていませんよね。まあ、万人向けの教育プログラムの中にいきなりこのような話を組み込む必要は無いかもしれませんが、ソフトをやり出すと当然の成り行きとして、ハードにも興味が向くことになるわけです。子供は基本的に好奇心旺盛なので、ソフトを教えているだけでは済まなくなるのは必然の成り行きです。絶対、ハードもやりたいと言い出すはず、というか、目の前のソフトがどうやって動いているのか、その仕組みを知りたいと思うのは人情です。で、子供がそういう興味を抱いた時にきちんと教えられる人間、教材を調達できる環境があるかと考えると、（4）の問題が出てくるのです。

電子工作をやってみたいと思ったときに、ちょこっと秋葉原に寄って数十円のICチップを山盛り買ってこれる子と、そんな電気街なんか無い田舎とでは、差が出てくるのは当然です。もちろん今ではネットで大抵のモノは買えますが、それでも手間の差は出てくるでしょう。私も大学で都会に出てきた時にカルチャーショックを受けたのですが、コンピュータの分野って、昔（パソコン通信の時代）ほどでは無いにしろ、子供の頃からどれだけ馴染んでいるかという点で都会と田舎の差が非常に大きいんです。もちろん、この差をなくすために学校レベルの教育に取り入れていくのでしょうけど、埋められない差があるのは真実です。改善が望まれます。

取りとめのない話をウダウダと書いてしまいましたが、私が本当に言いたいことは何かというと、コンピュータとかソフトウェアを”専門”にできる人を増やしたり、そういう人の能力を強化したりするだけじゃなくて、実は、コンピュータやソフトウェアを職業にしない人達にとっても、ソフトウェアができるか、できないか、が文化レベル、もっと言えばその人の世の中でのサバイバル能力を大きく決定づける要因になる時代が来るかもしれない、そしてそれは、日本人同士ではなく、世界中の人達との競争になる、だからちゃんと教育しないとマズイよ、ということなんです。

人工知能とかディープラーニングとか、はたまた自動運転なんて言葉が最近メディアを賑わしているのはご存知だと思いますが、我々の身の回りの中にますますこういった高度なソフトウェアが、物凄い勢いで入り込んでいるのです。もちろん、私たちの身の回りにコンピュータがあふれ返っているというのは今に始まった事ではありません。マイコンなんて炊飯器にも入っていますし、車はとうの昔からコンピュータの塊です。でもそれが、IoTやAIの形態を取るようになると、数の面でも、処理の高度さの面でも、今までとは比べものにならない度合いで我々の身の周りに進出してくることになります。そういう時代において、「コンピュータは自分にとっては完全にブラックボックス」としか言えない人と、たとえ少しでもソフトがいじれる人。。。あるいは、単にソフトが書けるだけの人と、数学的なアルゴリズムの設計まできちんとできる人。。。あるいは、ハードウェアまで理解してソフトが書ける人。。。こういう差が何を意味することになるのか。

今の日本に読み書きができない人はほとんどいませんが、ある程度でもコンピュータのソフトが分かるか、あるいは全然分からないか、という事が、少し昔の時代の”文字が読めるか読めないか”の差に匹敵するような、そんな時代が来ないとも限らないと、私は思うのです。ひょっとすると、英語ができるかできないかよりもクリティカルな問題になるかも知れませんね。高度なソフトウェアを積んだコンピュータが世の中を支配する時代になるということは、ソフトをいじれる人以外は仕事が無くなる、ということですから。

強勢音節等間隔（7）

今回でこの話題を最後にしたいと思います。

（2）文脈に基づく連想能力、の話をまだしていませんでしたが、これは簡単に言ってしまえば”語彙力”のことです。そうですねぇ、何でもいいですけど例えば、

I bought this book ( ) 1000 yen.

という英文を見て、括弧の中に入れる語句として'for'を瞬時に思いつくことができない人は、このforを聞き取れない可能性が高いと思います。「1000円と引き換えに（買った）」という感じですが、こういう言い方に慣れていれば、for の部分をいい加減に発音されても「forに決まってる」と思えるわけです。逆にこういう言い方に慣れていないと、forの部分が”ファ”みたいな、はしょられた発音になったときにはもうアウトでしょう。そういうことです。（”価格が変動する物”の場合はatが入る場合もあるようですが、その場合は”～円のときに買った”という意味になりますね）。

こういう話をすると、「結局、語彙を覚えないといけないのかー」とため息をつかれる方が多いと思いますが、リスニングに限らず、このような狭い意味での”覚える”という考え方は、止めた方がいいと思うんですね。ま、大学受験のような姑息な世界は別として、実用英語を相手にする場合には止めた方がいいと思います。とてもじゃないですが、暗記で対処できるような狭い世界ではありませんから、押しつぶされてしまいます。

じゃあ、どのように考えればよいのか。私の感覚で言うと、”覚える”ではなくて”馴染む”、だと思うのです。以前ちょっと言った”技術が知識を飲み込んでしまう”という方向性、それを目指すのです。リーディングで言えば、このブログでも「その文章がチョー簡単、あほらし」と思えるようになるまで繰り返せと言っていますが、それは決して「脂汗を流して暗記しろ」ということではありません。その文章の内容を自分自身で喋っているつもりになって、何回も読むなり、つぶやいてみるなりしてみるのです。”覚える”とか”暗記する”とかではなくて、よどみなくスラスラと喋れるようになったか、を意識してやるのです。分からないところはスクリプトをちら見しても全然構いません。それでいいと思います。

このとき大事なのが、「英文を上から目線で見る」ことです。英文に振り回されながらそれを必死に暗記しようとするのではなくて、あたかも芝居の台詞を覚えようとしている役者のように、その文章を自分自身で喋っているように”なりきって”、”自分がその英語を操っている”というイメージを持つことが重要です。そして、同じように重要なのが、ただ機械的に英文を喋るのではなくて、”何を言おうとしているのか”という意味のイメージを思い浮かべながらそれに対応した英文をひねり出していく、という感覚で英語をアウトプットすることです。これによって、”どういう事を言いたいときにどういう表現を使えばいいのか”というような”対応表”みたいなものが頭の中にできあがるので、実践的な知識として英語が頭に残るのです。

英語に対してそのような能動的な接し方をしていれば、この単語を覚えたとかこの熟語を覚えたとか、そんな瑣末な事にいちいち神経をすり減らさなくても当たり前のように個別の表現にもいつの間にか”馴染んで”しまえるのです。実際、そうやって身につけた知識しか使い物になりません。

おっと、リーディングの話になってしまいましたが、リスニングの練習をするときも基本的には同じです。聞こえてくる音を丸ごと飲み込んでやろう、という上から目線で聴くことがやはり大切です。そのような感覚でたくさん音を聴いて英語の音に馴染む、リスニングができないということは結局、そういうことが足りていないのです。

しかし、そうは言ってもリスニングはリーディングと違って難易度が高いのでなかなかそう簡単にはいきませんよね。私も長年辛酸を舐めてきました（いる）ので、力の無い初心者の方にそんな事をしろと言っても、実際には聞き取れない箇所が多すぎて何がなんだか分からない、そんな感じだろうな、ということは重々承知しています。

この点に関しては、「特効薬もなんか無いよ。本当にやる気があるなら俺と同じように辛酸を舐める覚悟をしろ」と本当は言いたいのですが、、、そうですねぇ、最初のとっかかりとして心がけて頂きたい点があるとすれば、

日本人のカタカナ発音を徹底的に嫌いになる所から始める

のがいいんじゃないかなと、今の私はそう思いますね。英語の勉強を始めた頃の私はこういう意識は持っていませんでしたが、今になって思うと、これって凄く重要です。

リスニングが上手くなれるか、なれないか。もし才能というか向き・不向きみたいなものがあるとすれば、英語を母語とする人たちのあの発音、あのリズムを「格好いいと思えるか否か」が分岐点だと、私は思います。格好いいものに出会ったとき人はどうするか。ずっと側にいたい（笑）と思うでしょうし、あの格好良さを自分でも真似してみたい（格好いいモデルさんの真似したいでしょ？）とも思うでしょう。英語の音に対してそういう感情を抱くことができたら、、、英語の音声がグッと身近なもの、近づきやすいものになって、抵抗が薄れるはずです。

で、その”格好よさ”をちゃんと味わうために、日本人風のカタカナ発音を頭の中で思い浮かべることを完全に断ち切る必要があるのです。これができないと、英語の格好よさなんて絶対に分かりません。別に、ジャパニーズイングリッシュを振り回すなとか、発音に神経質になれとか、そんな事を言っているのではありません。日本人風のカタカナ発音を思い浮かべているような”鈍感”な音声感覚では、英語の音を手なずける事など到底できませんよ、って事です。


今私が一番聴いているのはNHK World TVですが、あの番組でもレポーターやコメンテーターとして時々日本人が出てきます。もちろん、流暢な英語を話しているのですが（私なんかよりずっとずっと、英語ができる方々だと思います）、発音の方は、残念ながら日本人発音になってしまっている方が多いです。もちろん、それについてとやかく言うつもりはありませんし、あれはあくまでテレビ番組であって英語の学習教材ではないので、その事自体は無問題だと思います。しかし、英語のネイティブの格好いい発音に浸って気持ちよくなりたい、そういう目的で聴いているときに急に日本人に切り替わると、正直、興ざめします。そんな時はイヤホンを外したりもします。それくらい、英語本来の音が体に染み付いていて、逆にそれ以外のものは受け付けないという耳になってしまっているんですね。英語の音をものにしようと思ったら、英語本来の音に対してこれくらい敏感にならないと駄目だと思います。

だから、教育現場でも、学生にくだらないリスニングテストを課す前に、まずはそういう音声教育をちゃんとやれと言いたいですし、ゴリゴリのカタカナ発音のままやたらめったらに音読をやらせるのも、音声感覚を逆に鈍らせてしまう危険性が大だと、私なんかは思っています。音読をやりたいなら、別に完全でなくても構わないから、できるだけネイティブの発音とリズムを真似るように心がけてやるべきです。確かに少々恥ずかしいかもしれませんが、そういう”照れ”の感覚よりも、不自然な英語を発することの方により大きな違和感を感じるようになったとき、正しい英語の音声感覚が身についたと言えるのだと思います。へたくそなカタカナ発音で一生懸命音読をやって、英語の字面は覚えられるかもしれないけど、耳の方はどんどん悪くなっていくのではないでしょうか。

なんだかとりとめのない話になってしまいましたが、やっぱりいつも言っている哲学に戻ります。”英語そのものの音とリズムにしっかりと注意を向けろ”ということです。で、ただ単に一生懸命聴くだけではなくて、英語の発声原理の根本にある”強勢音節等間隔の心”を意識しながら、彼らの発音を真似るつもりで能動的に聴け、ということが言いたいのでした。

要するに、一流のモノマネ芸人になればいいんです。

気づきというか、再認識というか

また少し間が空いてしまいました。最近忙しいもので。書く書くと言っているトピックをほったらかしでズルズル引きずっていて申し訳ないですが。近いうちに片付けます。

というわけで、今日も軽い話を。この一ヶ月くらいですかね、自分の英語力がまた1ランク上がったと実感しています。英語を読んだり聞いたりする時に頭を一生懸命使っているという感覚がほとんど無くなってきているのです。そんなに難しい英語でなければ何にも考えずに読めるし、聞ける。書いたり話したりする方はまだそうはいきませんが、それでも、英語らしきものに落とし込むのに要する時間が短くなってきています。とにかく、”英語が軽い”。

特にリスニングの力が、数ヶ月前の自分とは確実に違ってきていますね。忙しいのでそんなに根詰めて練習できてはいませんが、なぜか最近、英語を聞くのがラクなんです。NHK World TVなんかを見ていると、英語の音が本当にスムーズに耳に入ってきて、嬉しくなってしまいます。

この番組については以前から90%以上は聞き取れると言っていました。そもそも、以前から相当聞き取れてはいたのです。しかし、そうは言っても、ほんの数ヶ月前までは一生懸命集中して必死のパッチで聞いていましたし（関西人しか分からない !?）、アナウンサーから天気予報のお姉さんに変わったとたんに苦しくなったりしていました。ところが、、、このところ、本当に全部といっていいくらいの精度で聞き取れてしまうんです。しかも、すごーくラクに。

これは見栄でもなんでもなく、この番組に関してはもう英語の聞き取り練習をしているという感覚はほとんどなくて、純粋に「テレビを見ている」「中身だけを追っている」状態です。英語が聞き取れないストレスのようなものはほぼゼロです。

このところ忙しくてそんなに英語をやれてないのに、一体どうしたことなのでしょうか？実は、リスニングに関しては一つ、”気づき”のようなものがありました。ひょっとするとそれが影響しているかもしれないなと思っています。以前から分かっていたつもりの事なんですけどね。先達たちの本の中にも書かれていることですし、そういう本もたくさん読んできていますから。

でも、最近ある1冊の本を読んだ際に、今まで分かったつもりになっていた事が違う言葉で表現されているのを見て、それが改めて私の琴線に触れて、”ハッとさせられた”のです。そして、最近は英語を聞くときに、改めて今まで分かったつもりになっていた”その事”を少し意識した聞き方をするようにしたのです。それが今の私にいい具合に作用して、微妙な改善がなされたのかもしれない、と思っています。

”その事”って何なのか。次の記事に書きます。

マイナンバー (3)

前回は準備で終わってしまいましたが、マイナンバーのC/Dの生成方式である「モジュラス11ウェイト2-7」の亜種2つを取り上げ、誤り検出率の観点から議論してみよう、というのが今回の目的でした。数学が凄く得意、あるいは、符号理論に造詣のある人からすると（私はないです）、私が何を言わんとしているかは既に自明かもしれませんが、まあ、まったりとお付き合い下さい。数学なんか大嫌いという人は、まあ頭の体操だと思って読んでみて下さい。実体は小学校の算数レベルの話ですから。

で、議論再開の前に1つだけ訂正なのですが、「ウェイト2-7」と表記する場合と「ウェイト2～7」と表記する場合とでは積和の作り方が違う、というような事を書いてあるサイトもあります（本当の所どうなのかは知りません）。それによると、マイナンバーのように下の桁から順番に1つずつずらした桁の重みを表す場合は「ウェイト2～7」と書くのだそうで、ウェイト2-7と書くと積和の計算式が違うのだそうです。確かに積和の作り方にも亜種があるというのはなんとなく知ってはいたのですが、こういう表記の仕方で区別するというのは知りませんでした。重ね重ね、本当の所は知りませんが、そういう説明をしているサイトもあるので、念のため今後は「モジュラス11ウェイト2～7」と書くことにします。

さて、符号の誤り検出率という言葉を前回出しました。C/Dの役割は、どこかで数字を間違えた場合にそれを”検出”することでしたね。じゃあ、数字をどんな風に間違えても必ずきちんと検出できるのか、とか、どんな間違いは検出できて、どんな間違いは検出できないのか、とか、そういう事が当然問題になります。この、どれくらいの割合で誤りを検出できるのかという性能指標を「誤り検出率」といいます。誤り検出率100%といえば、どこをどんなふうに間違えても必ず検出できるということです。
（前回から符号、符号と言っていますが、簡単には、生のデータをいじって若干の情報変更を加えることを”符号化する”という風に理解しておけばいいと思います。11桁が生データで、誤り検出機能を持たせるために下1桁に適切な数字を付けるという”符号化”を行っているのです。）

どんな間違いでも必ず誤りを検出できる（ランダムエラーに対する誤り検出率100%と言います）というのは素晴らしいことですが、なかなかそう上手くはいきません。もちろん、付与する情報量（桁数）を増やせばできるでしょうが、桁数を増やしすぎても煩雑になります。付与する余分な桁数はできるだけ少なくして、それでいて如何に誤り検出率を上げるか、それが符号設計者の腕の見せ所なのです。モジュラス11の場合は、付与する桁数は1つだけと、始めから決めているんですね。

如何に誤り検出率を上げるか、と言いましたが、いきなりランダムエラーを考慮の対象にしたのでは範囲が広過ぎて難しいです。そこで、「発生しやすいエラー」に着目して、そういうエラーの検出率を上げることを重点的に考えるのが上手なやり方、ということになります。で、数字の羅列を扱う場合、この「発生しやすいエラー」として挙げられるのが、以下のようなものです。

(1) トランスクリプションエラー

　　数字の書き間違い。12345 → 12845 など。

(2) トランスポジションエラー

　　2つの数字の入れ違い。12345 → 13245 など。

(3) ダブルトランスポジションエラー

　　間に1桁おいた2つの数字の入れ違い。12345 → 14325 など。

確かに、(2)はよくやりそうですね。さらにこれらのエラーが同時に何個起こるか、例えば、(1)の数字の書き間違いも同時に2つ、3つやってしまう場合も考えられますが（バカですけど）、それについては私自身が検証しきれてないので置いといて、各エラーを1つだけやってしまった場合のエラー検出率については、モジュラス11ウェイト2～7は結構優秀で、(1), (2), (3) の場合全て検出率100%だそうです。ただし、前回の（方式A）の場合です。ランダムエラーに対するエラー検出率は91%と言っている資料もありますが、確かめてないので知りません（計算にはかなり骨が折れそうです。こういう計算をサクッとやってしまうのが天才君なのでしょう。ハミング距離とか使ってできるのかな？よく知りません）。モジュラス11はモジュラス10に比べて検出率がかなり高いようです。

で、上の（1）～（3）について、方式Aの場合とBの場合とでエラーの検出具合がどうなるか、ちょっと具体的に確かめてみましょう。

(1) トランスクリプションエラーの検出率

マイナンバー12桁を扱う時に一カ所だけ上記のエラーを犯してしまった場合に、C/Dを使ってそれを検出できるかどうか、みてみましょう。

マイナンバーについて、C/D 部分の値をP0、C/D以外の部分については定義どおりに下位桁の数字から順番に Pn と書くことにします。また、C/Dの計算時に Pn に掛け合わせる重みの値は Qn でした。この時当然、1 ≦ n ≦ 11 となります。

今、 本来は値が a である P0またはPn を、間違えて b と書いてしまったとしましょう（もちろん、他の桁は間違えてないことが前提）。このエラーを検出できるかどうか、調べてみます。

(a) P0を間違えた場合

C/Dの値を勝手に変えてしまったのですから、確実に検出できますね。これ以上考えることはありません。方式AでもBでも同じです。

(b) Pn （1 ≦ n ≦ 11）を間違えた場合

この間違いがC/Dの値にどう影響するかを見てみればよいのです。メンドクサイのでC/Dの計算式の Σ Pn×Qn の部分を単に Σ と書くことにすると、上記の間違いによって Σの値は　Qn (b - a) だけ変化します。いいですね。積和の部分の他の項の値は変わりませんから、引き算すると消えますよ。で、考えたいことは、 Σ の部分を11で割った余りが変わるかどうか、です。順を追ってみてみましょう。

定義から、Qn は2以上7以下の自然数です。また、b - a は -9 以上 9以下の整数で0を含みません（0だと間違えたことにならない。当然 a ≠ b の場合を考えていますから）。いいですよね。9を0と間違えてしまった場合に一番減って（-9）、0を9と間違えた場合に一番増える（9）わけです。

そうすると、Qn (b - a) について何が言えますか？よく考えてみてください。。。そう、これは、マイナスの符号も含めて「11の倍数ではない」ことが言えますよね。だって、11は素数ですから、その11の倍数を、11より小さいQn という自然数と、b - a という絶対値が11より小さい、そして0でもない整数、との積として表すことなんてできないはずです。分かりますよね。要するに素数11の倍数を、絶対値が11より小さい整数のみの積として表すことなんてできない、ということです。素数11の倍数は（０を除いて）素因数分解したとき必ず素因数11を含むはずですよね。

はい、Qn (b -a ) は11の倍数ではないことが分かりました。もちろん0でもありません。すなわち、Σの変化分を ΔΣ と書く事にすると、ΔΣ = Qn (b - a) は11の倍数ではないということです。ということは、「Σを11で割った余りの変化分」はどうなるでしょうか？そうですね、0ではないということが言えますよね。余りがズレないのは値が11の倍数ずれた場合”だけ”ですから、値のズレが11の倍数じゃないということは、11で割った余りは必ずもとの値からズレてしまうということです。

すなわち「Σを11で割った余りはこのエラーによって必ず変化する」ということが言えます（当然、Σを11で割った余りを11から引いた値もこのエラーによって必ず変化します）。さあ、このとき、C/Dはどうなるでしょうか？ここで、方式AとBとで事情が異なってきます。

方式Aの場合、Σを11で割った余り（メンドウなので Σ % 11と書きます）の、全ての異なる値に対して異なる扱いをしています。この値が1なら廃棄するし、0ならC/Dを0にするし、あとは、この値の11の補数（11 - Σ % 11）を C/D に採用しています。この補数の中に0はありません。なので、方式Aの場合、今回のエラーによって C/D の値が必ず変化するか、Σ % 11 の値が1になって”廃棄しなければならない番号だ、おかしいぞ”ということになるわけです。つまり、エラーを見逃してしまうようなことは絶対起こらない！のです。はい、誤り検出率 100% だと言えました。

一方、マイナンバーに実際に採用されている方式Bはどうでしょうか？方式BがAと違うところは、Σ % 11の値が0の場合と1の場合で同じ扱い（C/D = 0）をしている点です。これを考えると、方式Bの場合は今回のエラーを「場合によっては見逃してしまう」ことは、すぐに分かるでしょう。だって、たとえΣ % 11の値が必ず変化すると言っても、

・元々の Σ % 11の値が0（1）だったのが、エラーによって1（０）に変化した場合

のように変化した場合は、C/Dは結局0のまま変化しないということになりますから。つまり、方式Bは、一カ所のトランスクリプションエラーの検出率は100% ではない、ということが分かります（具体的に何% になるかは、頑張って計算すれば出るでしょうが、そこまでやるほど暇じゃありません。暇な人はトライしてみて下さい）。

具体的な例を挙げてみましょう。簡単です。上記ケースに当てはまる場合を適当に探せばいいんです。

000000110000 ( Σ % 11 = (5x1 + 6x1) % 11 = 0 なので C/D = 0)

を

000000310000

と一カ所書き間違えてしまった場合、Σ % 11 = (5x1 + 6x3) % 11 = 1 なので C/D は0のままとなり、元の正しい場合の C/D と変わりません。なので、1 を 3に書き間違えたエラーを検出できないですね。方式Aの場合だと、上記の値が1になってしまって、「00000031000などという、本来欠番の11桁の数字が使われるはずがない、どこかで間違っているはずだ」と、ちゃんと分かります。

疲れましたか？ (2) のトランスポジションエラー、(3) のダブルトランスポジションエラーについても、同じように考えることができます。簡単に触れておきます。

(2)については、Pn = a, Pn+1 = b を入れ違えたと考えると、

ΔΣ = (Qn+1 - Qn) (b - a) となり、Qn+1 - Qn の部分は基本的に 1、n = 6 のときだけ -5 となります。 P0 =a と P1 = b を入れ違えた場合については、P1 を b から a に書き間違えた (1) のトランスクリプションエラーに含まれるので考えなくてよいです。方式Aだと検出率100%になるのは(1)と同じ理屈です。方式Bだと100%にならないことも、相互に区別できない以下のような例から分かります。

000000100110（Σ % 11 = (2x1 + 3x1 + 6x1) % 11 = 0 -> C/D = 0）
000000101010（Σ % 11 = (2x1 + 4x1 + 6x1) % 11 = 1 -> C/D = 0）

(3)については、Pn = a, Pn+2 = b を入れ違えたと考えて、

ΔΣ = (Qn+2 - Qn) (b - a) となり、Qn+2 - Qn の部分は 2, -4 の場合があります。P0 とP2 を入れ違えた場合については、P2のトランスクリプションエラーに含まれます。これも同じ理屈から方式Aだと検出率100%だし、方式Bだと100%にならないことも以下のような相互区別できない例から分かります。

000001107100（Σ % 11 = (3x1 + 4x7 + 6x1 + 7x1) % 11 = 44 % 11 = 0 -> C/D = 0）
000001701100（Σ % 11 = (3x1 + 4x1 + 6x7 + 7x1) % 11 = 56 % 11 = 1 -> C/D = 0）

さて、そろそろまとめたいのですが、方式Aだと折角 (1) ～ (3) のタイプの1個のエラーについて検出率100%なのに、どうしてわざわざ検出率が落ちる方式Bになっているのか、というのが、私が抱いた疑問でした。

で、1つ想像できることとして、方式Aの場合は「上位11桁部分でも欠番がでる」ことが大きな問題になるのではないか？ということです。復習ですが、マイナンバーの上位11桁の部分は、11桁の住民票コードをつかって”生成”されます。11桁の住民票コード自体の作り方は公開されていますが、この、住民票コードからマイナンバーの11桁部分を作る方法については公開されていないようです。ただ、マイナンバーの11桁から11桁の住民票コードを復元できないようにしている、ということは言われているので、住民票コードをそのまま持ってきているわけではないようです。何かしらの演算処理が行われているのです。

仮に、この演算処理の結果、先に「Σ % 11」と書いた部分の値を1にする11桁の数字がどうしても出現してしまうのだとしたら、、、方式Aは使えないですよね。マイナンバーを付与できない人が出て来てしまいます。「お前のマイナンバー、なし」というわけにはいかないじゃないですか。だから、符号の性能が少々さがっても、方式Bを採用せざるを得ない、ということなのかなーと想像するわけです。もちろん、何も公開されていないので真実はしりませんよ。あくまで想像です。

マイナンバー1つとっても、色々と頭の体操ができるわけです。