「マイナンバー」が危険なこれだけの理由-2


公開 (UL): 2023-05-18
更新 (UD): 2023-05-18
閲覧 (DL): 2024-07-25

この記事のもくじ

→本文へ
当サイトは SNS の公式アカウントがないので,「議論ネタ」にする際は,皆さんのブログ,メーリングリスト,SNS や掲示板などで,適当にハッシュタグを付けたりリンクを掲載するなどしてご利用ください。

前の記事

2023-04-08
オヤクショの「上から目線」という殺傷光線

次の記事

2023-08-30
倫理意識の社会的低下

最近の記事

2024-05-29
簡単にできるネット防犯対策
2024-03-25
福祉改善を阻むオヤクショ思考
2024-02-04
玄関前手すりを DIY
2023-12-25
「理不尽採点」教育と「英語力低下」
2023-03-30
給使乖離現象
新着情報
She appears also the top page.

新着情報 Recent docs.

Sorry, but most of these pages are only Japanese.
「ぱそはだ」シリーズ «PASOHaDA: Parts Assignment and Soldering Only Handmade Design Assist.»
高度な技能不要の電子工作で自立介護 DIY。
簡単にできるネット防犯対策 «Simple measures against phishing mails and malwares.»
フィッシングメールを暴き,ウイルスの侵入を阻止する簡単な対策を紹介。
福祉改善を阻むオヤクショ思考 «Japanese subsidy system of communication aid device for disabilities cannot be applied those if it's with features except communication, IDK why.»
「意志伝達」しかできない高額な装置にのみ税金が使われる謎制度。
「理不尽採点」教育と「英語力低下」 «Japanese English skill ranking in the world has been down. I guess one of the reason is that the government's education policy lacks coherence.»
日本人の英語力が低下,しかも小学校から英語が必修になった世代ほど。「教育方針の一貫性のなさが原因」とする考察。
倫理意識の社会的低下 «One day, I set to stop DM from a banking corporation, but those continue to be sent after that. I'm feeling falling sense of ethics in Japanese society.»
某銀行からの DM が,およそ金融と関係ないもの多数。停止設定後も何ヶ月も配信が続く状況に,倫理意識の社会的低下を感じた話。
給使乖離現象 «"Server and User Design Gap" phenomenon (abbr: SUDG), it's the trend to lack of considerations in design for user of the service.»
愚かな経営者たちが考えた劣悪なウェブサービスにより,人々が一方的に不利益を被るという話。
日本の「IT 人材不足」の正体 «The simple reason why Japanese companies lack IT-skill.»
保険会社からのセキュリティガバガバメールが「IT 人材不足」の正体を暴く。

人気記事 Frequent view pages.

現在当サイト人気 No.1!
Android のキーボード・ショートカット一覧 «The list of Android Keyboard Shortcuts (EN ready).»
Android のスマホやタブレットにキーボードをつないだ時に知っていると便利なキー操作。
表計算で「令和」に対応する方法
How to adapt the Gengo era "Reiwa" on spreadsheet applicaiton.

古いアプリも OK。「表計算 令和」の検索結果上位御礼!
表計算ソフトで予定表を自動作成する超便利な方法 «How to make the schedule table automatically on spread-sheet.»
「毎月第○×曜日」的な法則は自動で作らせてラクしよう!
表計算ソフトに「個人情報保護機能」を仕込む方法 «Prevention to leak private-data with spread-​sheet macro function.»
「漏えい」のためのフェイルセーフ。「表計算 個人情報」の検索結果上位御礼!
Wary-Basher (ワリバッシャー)
DIY device that enables the handicapped to operate many things with a switch like push-button.

障害者の様々な操作をスイッチ操作で実現する器具。キットも発売中! 「作り方」PDF ダウンロード多数御礼!←地方教育委で人気。

おすすめ! Recommend

貧乏人を殺す行政の構造 «Structurally, the administrators kill the poors in Japan.»
ヘタすると多摩川に流されるところだった台風 19 号

この記事に対する → 調布市の反応
[PDF 118KB] 生活保護申請時のオヤクショ対策
申請の「水際作戦」を突破するための心得。「ホームレス総合相談ネットワーク」製作の図解を小サイズ化したもの。

出典 ☞ 路上からもできるわたしの生活保護申請ガイド (2017 年版) (外部リンク)
文字ベース天気予報 «Weather forecast in text mainly from JMA Json-data.»
古いブラウザやスマホ,音読ソフトでも大丈夫! 気象庁の JSON データを利用した文字ベースの天気予報(試験版)。
「事故防シート」について «Cared persons taking with "Jiko-​Bow-​Sheet" prevents from accidents.»
介護現場の負担軽減と事故防止のアイデア
【連載】 キーボードの「キー」の詳しい使い方 «The detial of usage each key on keybord.»
各キーの機能詳細。機能別五十音順一覧。
和易ゐ記 (WAI-WIKI) «WAI-WIKI is light­weight markup language for Japanese, and generates HTML on this server on-​demand.»
当サイトで開発/使用中の日本語向けに特化した軽量マークアップ言語

ご連絡 Contact

▼ メールフォームはこちら
SSL 証明書の更新に不具合が多いため,期限切れエラーが出た際は,お手数ですが「例外指定」をお願いいたします。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。

ファイルの暗号化
当サイト管理者(石川)宛にメール添付で送信するファイルを暗号化したい時は,唯一のパスワードを PPOP で取得できます。 PPOP gives a password for encryption of the file(s) attached your mail to the admini­strator of this site M.Ishikawa.
PPOP

MEMO / Email to the Author
あとで調べたい点のメモなどに利用可能。
下部ボタンでそのまま著者にメールできます。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。


CAPTCHA: easy math prob in Japanese

時事川柳 News Senryu

パーティー券  
民意も一緒に
  蹴り返し
Kick back both party tickets and people's opinions.

 自民党の一部(?)派閥がパーティー券のノルマを上回る分の売上げを議員にキックバックしておきながら政治資金収支報告書に不記載だった問題が広がりを見せている。なるほど,こうしたことが党内で常套化していたのだとすれば,岸田総理はじめ同党政治家にことごとく「民意を蹴り返すクセ」が付いているのは当然という感じもする。これっぽっちも「悪いこと」と思わなかったのだろうな。そんな人たちに誰が票を入れるのだろうか。少なくとも,岸田の広島と「頭悪いねぇ」と暴言を吐いた議員を選出した長崎に「ふるさと納税」はしないことにしよう。
参考: 自民県 絶対しないぞ ふるさと税

今回はもう一句!

危機感の  
ワリに二階は
  誰も居ず
Having sense of crisis, but nobody takes shelter of 2F.

 大雨などで危機感を持ったら二階のような高い所へ避難すべき的な話を聞いたよーな気がするのだが? パーティー券のノルマ上回り分キックバックの政治資金収支報告書不記載問題で,安倍派は何人も辞任したのに,同じく捜索を受けている二階派に辞任する話があるかというと,今のところ誰もいない。総理は「危機感を持って」とか言っているらしいが,どこが「危機感」なのやら。

(⌚2023-12-19)

ご支援 Support this site.

まだまだ コロナ失業中!!
CORONA-NEET, seeking works now!

この活動をご支援いただける方はこちらへ Could you support this site, see here (but Japanese).
都道府県庁さん, 地方自治体さんや教育委員会さん, 障害者就労支援機関さんやその他公的機関,省官庁さん, 「タダ見」しているだけでは, 格差が広がるだけだと思いませんか?
Welcome!
Amazon    Google
The companies, thanks for many accesses every months! Are the articles I wrote helping for increasing your income? Although, I cannot get even a penny and jobs from that.

Japanese taxpayer ID system "My number" is repeating to leak private informations. Some machine issued the certification of other, and some governmental officer misregistrated to health insurance with the number of other. Those have risks of abusing the privacy info and mistake patients, surgical operations and medications. At the worst, that occurs serious aftereffects or death. But Japanese politicians, ministries and agencies don't mention about the responsibilities of the leakages.

 やれやれだ。またマイナンバーで個人情報の漏えい,あるいはそれに準ずる事案が起きた。
 筆者は以前,ほぼ同じタイトルの記事を書いている。それが以下。

▼ 「マイナンバー」が危険なこれだけの理由
http://treeware.jp-help.net/?dblg16

 上記記事では,主にシステムに潜むセキュリティのリスク対策が万全ではない点を中心に述べたが,ここ最近起きたマイナンバー関連の事案は,どうもそれ以前の問題のような気がする。
 具体的には,1つは「誤発行」。「マイナン『ば~か』ード」を利用した証書類発行サービスで,他人のものが発行されてしまったという。
 もう1つは「誤入力」。「マイナン『ば~か』ード」を健康保険証として使えるようにする紐付けが,他人の番号でされていたという話。
 筆者に言わせると,どちらも防ぐ手立てが確実に存在する。だから,そうしたことが起きないような仕組みを初めからシステムに組み入れておくことは,工学的にも常識だと思っていたから,前回のセキュリティ云々の話では詳しく触れていないのだが,今回のマイナンバーの事案を見ると,設計時点でその概念すらなかったとしか思えないような感じがする。まさかそんなことで追加の記事を書くことになるとはね。
 ここでは,今回の具体例と,それによって起こりうるリスク,そして「考慮されていて当然だった」その対策について説明してみたい。

● 事案1-証書の誤発行

 「マイナン『ば~か』ード」を利用し,コンビニで証書が発行できるサービスで,他人の証書が発行されたとか。
 ネット上では「個人情報ガチャ」と揶揄されていた。
 それによって起こりうるリスク,後の報道で判明した原因と,それを防ぐために本来取られているべきだった対策について述べてみる。

◆ 起こりうるリスク

 これ,元のデータの所有者にしてみれば「個人情報の漏えい」だし,他人の証書を受け取った側も,正しい証書を得られなかったために,その証書を元に進めるはずだった手続きができなくなれば,本来受け取れるはずだった金品を受けられなくなったりする可能性がある。そうでなくても,再発行という手間が追加でかかることは確実だし,場合によってはそのための経費も余計にかかる。気づいたからいいものの,気づかなかったらどうなっていただろうか。証書の内容が間違ったまま手続きが進められて,何の問題も起きないと言えるだろうか。サービス利用者に落ち度はないわけだが,もし間違ったまま手続きが進められたために「損失」が発生してしまった時,補償されるのだろうか。何だか「泣き寝入り」になりそうな気がするのは,筆者だけか?
 原因の詳細は次節で述べるが,簡単に言うと,1秒以内のほぼ同時刻に複数箇所で同じ証書の発行手続きがあると,タッチの差で後に手続きした側のデータで両方に同じ証書が発行される仕組みだったとか。
 だいたい,これは気づいた利用者が「報告した」から発覚したわけだが,気づいても報告せずに,悪用されたらどうなっただろうか。たとえば,誰かが「マイナン『ば~か』ード」を利用して手続きを始めたところを見計らって,悪意のある人が別の場所で素早く同じ手続きを開始すると,その人の証書を入手できてしまうことになる。しかし「後から」手続きをしたことになる側は,正しい自分の証書を受け取れるわけで,別の場所で同じ証書を手に入れた他人が居る……ということには気付けない。悪意のある人の側は他人の証書を当人に知られず手に入れられるわけで,その証書を元にした「なりすまし」の手続きもできてしまう。
 「当人に知られず」というのが怖いところ。これだと気付くまでの間に,いくらでも悪用できてしまうことになる。既にこうした悪用がされている可能性もあるが,「他人の証書が出てきた」と報告しなければ,気づかれないまま悪用し放題になってしまう。こうしたリスクの可能性が放置されていたわけだ。

◆ 原因

 手続きの「整理番号」的なものに「時刻」を利用していたため,ほぼ同時刻に同じ証書の発行手続きがあると,その「整理番号」も同じになり,タッチの差で後になった側のデータが両方に採用されて同じ証書が発行されてしまう仕組みだったらしい。
 なぜそうなるかというと,まずコンピュータ通信が発達したことで,証書の発行手続き用のサーバ(コンピュータ)は,手続き場所に関係なく同じである場合が多くなっている。たとえ2つの発行手続きが北海道と沖縄レベルに離れた場所で行なわれていたとしても,具体的な手続き処理は同じサーバ……たとえば東京のどこかに置かれたコンピュータで両方とも処理されたりするわけだ。コンビニ内で利用者が操作する機械はあくまでも「端末」で,どんなに離れた場所でも,その操作の状況がほぼリアルタイムで東京のサーバに送られて処理される仕組みだ。
 ヤクショに直接手続きに行った時など,まず「整理番号」の数字札を取るよう指示されたりするのと同様,サーバもそれぞれの「手続き」を区別するための仕組みがあるのが普通。問題だったのは,その整理番号……コンピュータの場合「セッション ID」などと呼ぶことがあるが,それに当たるものに「時刻」を使っていたらしいという点。すると,別の場所で「秒」まで同じ時刻に手続きが開始されると,同じ「セッション ID」が割り当てられてしまうことになる。手続きに必要なデータを一時的に保存しておく「ファイル名」としてそのセッション ID を使うと,マズいことが起きる。離れた場所で行なわれた手続きでも,同じコンピュータで処理されていれば,同じ場所にファイルが作られることになるが,同じ場所に同じ名前のファイルは複数作れない。既にあるものと同じ名前でファイルを作ると,前の内容が失なわれてしまうわけだ。そのため,「セッション ID」が同じだと,後から手続きを始めた人のファイルが前の人用に作られたものと同じ名前になってしまい,後の人の内容に置き換わってしまうことになる。サーバは「セッション ID は手続きごとに唯一」であることを前提に処理するから,前の人の手続きのセッション ID なら,内容もその人のものであることを前提に処理する。でもその時は,同じセッション ID で後から手続きした人のデータで書き換えられてしまっていて,そのファイルを元に,前の人にも証書を発行した……と,そういうことらしい。

◆ 怠った対策

 筆者は当サイトを独自に構築していて,簡単ながらシステムも設計する。利用者に何らかの手続きをしてもらうことを考えた時に神経を使うのは,やはり,その手続きを識別するための仕組み……つまり,まさに今回の問題の要因となった点だ。
 とはいえ,じつはその解消は原理的にむずかしくない。コンピュータというのは,処理ごとに「プロセス ID」と呼ばれるものが割り当てられる。一種の「番号」で,パソコンでは4~5桁ほどのもの。たいていは新たな処理が開始される度に1ずつ増えていく仕組みだから,たとえば4桁として,「時刻」にその4桁を付加して「セッション ID」とすれば,1秒間に1万以上の処理が開始されない限り……つまり,全国で同時に1万人が同じサーバで証書の発行手続きを始めたりしない限り,その秒で同じ番号が割り当てられることは原理的にはないわけだ。
 ただ,コンピュータによっては,そんな簡単ではない面もある。機械の動作状況の確認や,通信のための処理など,手続き以外の処理にも,それぞれ個別に「プロセス ID」が割り当てられる。すると,特に高速処理できる高性能なコンピュータの場合,1秒間に1万程度の新規処理が「発生しないとも限らない」場合も考えられる。「手続き」が1万を越えなくとも,「プロセス」が1万を越える可能性はあるわけだ。
 しかしそれも,考えようによっては解消はそれほどむずかしくない。前出のように,ヤクショなどでは「整理番号札の取得を促される」が,同様な感じで,プロセスのうち「証書の発行手続き」限定で1ずつ大きい番号の「セッション ID」を割り当てるようにすればいいわけだ。
 そうでなくたって,1つの端末で同時に2人が手続きすることなどないのだから,時刻と端末の識別番号を組み合わせて「セッション ID」とすりゃダブることなんかなかった気もする。それとも,どこの端末で手続きされているのか分からない仕組みなのか……マイナンバーは。

 他にも回避手段はあった。手続き用のファイルを作る時に「同じ名前のファイルが既にある時は書き込まない」ようにする方法もあるのだ。この方法を利用していれば「上書き」しないから,問題は起きなかったはずなのだ。で,ファイルが作れなかった時は手続き開始の時間を1秒から数秒ズラして別のセッション ID が割り当てられるようにするなどの方法も考えられたはずだ。

 ザッとこれだけ対策が考えられるわけだが,いずれにしても「単純に時刻をセッション ID とする」だけよりも処理は少々複雑。それでも,今回のような手続き上のミスが起きないようにするには必要な処理だったはず。残念ながら,マイナンバーシステムを設計した人たちは,その手間を惜しんだのか,そこまで考える「アタマ」がなかったのか……。

● 事案2-健康保険証で誤った紐付け

 もう1つの事案は,「マイナン『ば~か』ード」を健康保険証として利用できるようにする際に,番号を誤入力していたという。そこまではどこにでもありそうな誤りだが,大きな問題と感じるのは,そのために「別の人がひも付けされ診療情報などが閲覧されたケースがあった」という点。

◆ 起こりうるリスク

 「誤入力」といったって,全桁バラバラな数字を入れてしまうことなど,意図的にでもしなければ起こらないだろう。とすれば,間違ったのはせいぜい1桁か2桁と考えられる。
 これは,ちょっと番号を間違えただけで,たちまち別人として扱われてしまうことを意味する。それだけ「他人と取り違えられるリスク」が高いことになるが,保険証として医療機関で使われるようなものにそうしたリスクが高いということは,1桁番号を間違われたため,全く関係のない治療が自分に行なわれてしまったり,不要な手術を施されたり,誤った投薬を受けたりして,後遺症が残ったり,最悪死に至ったり……そうしたことが起きてしまう可能性が否定できないことになる。
 あ,そういえば高齢者が作る「シルバー川柳」にこんなのがあった。

「マイナンバー」 「なんまいだー」と 聞き違え

 今となっては,笑えねぇよ。

 また,1桁番号が違うだけで他の人のデータが見れるということは,適当に番号を入れれば誰かの病歴が閲覧できてしまうことも意味する。病院にも様々な人が出入りしている。マイナンバーの番号で病歴を閲覧できる端末の前に居るのは,必ずしも善意を持った医師だけとは限らない。悪意のある人がそうした方法で他者の病歴データを集め,たとえば特定の薬品を多く服用している人に一部を横流しするよう持ちかけたりとか,長らく病気で悩んでいる人の住所をアヤシいスピリチュアル療法をする団体にダイレクトメールの名簿用に売りつけたりとか,やろうと思えばできてしまうことになる。

◆ 怠った対策

 マイナンバーの桁数は 12 桁らしい。日本の人口が 1.2 億,納税者を識別するには法人も含める必要があるから,識別に最低限必要な桁数は9桁弱ほどだろう。12 桁というと千倍だから,適当な数字が誰かのマイナンバーに一致してしまう確率は,数千分の1程度と考えられる。
 これ,決して小さくないと筆者は思う。ランダムな数値を発生させてマイナンバーを扱うサーバに送り,データを不正に得ることを試みるような手続きを,あちらこちらのコンピュータに分散処理させれば,1分に数千回くらい試行は可能と思われる。すると1分に1個ペースでマイナンバーが特定できる。1日で 1440 個,毎日継続していれば,3ヶ月で十万を越える「生きた」マイナンバーを集めることができてしまう。
 クレジットカードとかはどうなのか。あれは 16 桁もの数字が並んでいる。全世界で使われているカードが 100 億枚あったとして,適当な 16 桁の番号がどれかのカードと一致する確率は百万分の1。マイナンバーの百分の1以下。つまり,前述と同じ方法で「生きた」クレジットカードの番号を知ろうとすると,百倍以上の時間を要することになる。150 倍とすると,1つの番号を得るため平均2時間半も時間がかかる。クレジット会社ごとに分割管理されていれば,確率はさらに低くなる。
 こうして比較すると,マイナンバーの「数千分の1」がどれほど高い確率なのかが分かると思う。つまり,12 桁ごときでは悪用され放題になってしまう可能性があるわけだ。せめてクレジットカード同様,あと4桁ほど多くてもよかったのではないかと思う。

 ただ,単に桁数を増やす方法では,「悪用」はしにくくなったとしても「誤入力」は防げない。が,じつは桁数を増やして「誤入力」を防ぐ手法もある。「誤入力」なんて「ヒューマンエラー」なんだから,起きる可能性は予測できたはずなのに,なぜ対策されていなかったのか。
 そもそも,デジタル化のための「マイナンバー」ではなかったのか。なぜ健康保険証との紐付けが「手入力」なのか。まずその点がナゾ。人が作業する時に「ヒューマンエラー」が起きるのだから,極力そうした人がする作業の少ないシステムに設計されていてもよかったはずだ。
 すでに「OCR(Optical Character Reader)」という技術は確立している。つまり,機械に読ませるのだ。機械が読み取る郵便番号や,確定申告の金額などの数字の記入欄には「枠」が書いてあるはず。「機械が読み取るべき場所」に数字を記載する仕組みになっているわけだ。

 ただ,それをそのままマイナンバーに応用するには,他のリスクもある。人間が書いた字は,人間でも間違って読むことはあるし,紛らわしい数字を書く人もいるから,機械が読んだものが必ず正しいとは言えないわけだ。でも,そこが解決するなら,機械で読ませるのも手だろう。
 あらゆる商品についている「バーコード」というものは誰もが知っていると思う。これも機械で読むものだが,間違って読むケースはほとんどない。多少汚れていてもほぼ正確に読む。なぜか。それは,間違って読んだ時には「間違い」と分かる設計になっているからだ。

 たとえば,以下のようなバーコードがあったとする。

▼ バーコードの数字部分(仮想)
   4 987654 321094

 これに対し,以下のような計算をする。

 じつは,この結果は,どんな 13 桁のバーコードでも,必ず十の倍数になる……つまり,この計算結果の「一の位」は必ず「0(ゼロ)」になるように,バーコードはできている。逆に言えば,バーコードの読み取り機は,読み取ったバーコードに対してこの計算をして,十の倍数にならなかったら「読み間違い」として読み直す仕組みになっているわけだ。「読み直す」ったって機械だから,1秒間に数十回くらい読むことができる。そのうち一回でも計算が合えば,正しく読み取ったデータとして扱う。バーコードが一部汚れていたり,印刷がはがれていたりしていても,人が読ませる時に,スキャン線が一回でも汚れのない場所を端から端まで通れば,正しく読める仕組みになっている。
 最後の桁(4)はチェックデジットと呼ばれ,前の 12 桁から計算で求められて,「十の倍数になる」ような数字が付加されている。これこそ機械が「正しく読める仕組み」で,つまり 13 桁の中に「間違い」を検出する仕組みが組み込まれた設計になっているとも言えるわけだ。
 さて,では「マイナンバー」はどうだろう。「間違い」の番号が入力され,そのまま放置されてしまっていたわけだから,そうした仕組みにはなっていなかったことは確実。
 「あと4桁増やしてもよかったのでは?」なんて提案をしたが,そのうち2桁ほどを「チェックデジット」のような扱いで,前の 14 桁から計算で求められる数字として,マイナンバーの入力を受け付ける機械側で計算し,入力と一致するかどうか確認する仕組みにしておけば,入力が正しいかどうかがその場で分かるわけだから,誤入力は2桁減らせる……つまり百分の一にできることになる。
 すると,OCR で機械に自動で読ませた時も,機械が「間違い」に気づくことができるようになる。デジタル化,自動化に対応できるわけだ。
 「バーコード」といういい例がありながら,その仕組みを活かせず,その場で「間違い」をチェックできずにスルーされてしまうシステムに作られてしまったのが「マイナンバー」ということだ。

 さて,筆者の大学受験の時は「共通一次試験」と呼ばれた……なんて言うと歳がバレるが,その時点で,試験は「マークシート」だった。
 「マークシート」というのも,入力を自動化する仕組み。健康保険証としての登録にマークシート方式を使っていれば,人が手入力する手間も,誤入力も減らせた可能性があるのは,言うまでもないだろう。
  40 年前の話でっせ? その時点でそうした「自動化」の仕組みがあったのに,40 年経ち,「デジタル化」推進のための保険証が「手入力」だとぅ? 何をちぐはぐなことをしているのかという感じしかしない。
 こう言うと懸念を抱く人もいるかもしれない。「マークシートの登録方法を理解できる人がどれほどいるのか」と。ただ,それを言ったら,「マークシート方式も理解できない人にマイナンバーの保険証を持たせて大丈夫なのか」という懸念のほうが大きい。「マイナン『ば~か』ード」を使う時は,いくつかパスワードが必要とかいう話を聞いている。「マークシート方式」を理解できない人でも「パスワードなら憶えられる」という理屈は理解しがたい。

● まとめ

 「間違いなら仕方ない,間違いは誰にでもあるのだから」と思う人もいるかもしれないが,でも,そのために自分の情報が犯罪者集団に知られて詐欺被害に遭ったり,増してや,医療事故を誘発し,最悪死に至るような要因が放置されていいのか。「仕方ない」で済む問題だろうか。
 「間違いは誰にでもある」というのは,そのとおりだ。だから,そのために「間違ったことに気づく(間違ったままにならない)」仕組みというものを組み入れておくことが工学的な常識なのだが,ここ最近のマイナンバーの事案を見ると,設計段階で既にその理念がなかったとしか思えないような感じがする。

 で,何がスゴいって,これほどのハイリスクな事案を起こしていながら,責任の所在についての話が大きく取り上げられないという点。マイナンバーの担当は総務省,健康保険の担当は厚生労働省,デジタル化についてはデジタル庁になると思うが,松本剛明総務大臣,加藤勝信厚生労働大臣,河野太郎デジタル庁大臣……引いては岸田文雄内閣総理大臣に至るまで,誰一人として自身の責任問題に踏み込んだ話は聞かない。

 端的に言えば,マイナンバーのシステムを作り運用する側は,筆者が述べて来たようなことを考えられない人たちばかりなのではないか。
 「では,あんた(筆者)が行ってマイナンバーのシステムを作ればいいだろう」と感じる人もいるかもしれないが,おそらく無理だ。なぜなら,本当にマイナンバーの「中の人たち」に,そこまで考えられる人が居ないとすれば,「排除されてしまった結果」と考えられるためだ。
 たとえば,筆者に限らず,そこまで考えられる人が「中の人」としてシステムを作っていたとしても,具体的な設計指示を出す「上」の立場の人から「『マークシート』なんて 40 年も昔の仕組みなんか使えないよ」的な方針が示されれば,それに従うしかない。その手の指示を出す人は,どんなに効率の悪い指示だったり,ヒューマンエラーが見過ごされる要因を含んでいたとしても,その点を指摘する人を煙たがったり,結果的に追い出したりするだろう。そんな指示を受けつつも「中の人」として残れば,医療事故の誘因要素を抱えたままシステムを作り続けることになる。もし実際に重大な事案が起き犠牲者が出てしまったら……それで自分が製作に関わったシステムで犠牲者が出たことに後々「罪の意識」に(さいな→)苛まれそうな人は,「中の人」など辞めたほうが賢明だ。筆者の場合も,述べているようなリスク回避や省力化を考慮した仕組みが採用されなければ,そこに居られなくなるのは必至だろう。
 すると,「中の人」としてそこに残るのは,リスクも省力化も考えられず,「罪の意識」も持つことのない人たちばかりになるわけだ。重要な点は,マイナンバーのシステムを作るために集めた人材がたまたまそんな人たちばかりだったというより,ヒューマンエラーや悪用リスクをしっかり意識する人はそこに居づらくなり,自然と排除されてしまうような状況があり,結果的にそうした意識の薄い人たちだけ残って作られたのが,今の「マイナンバー」である可能性があるということだ。述べて来たような「本来対策されていて当然の対策がされていない」とか,責任について誰も言及しないなんて状況は,その証左ではないか。

 マイナンバーで起きた不具合事案とそのリスク,それを回避するため「考慮されていて当然」だった対策について述べてきたが,筆者は現在(2023,5月),コロナの影響もあって,実質無収入だ。一方,今回のような個人情報の漏えいや誤入力を繰り返したマイナンバーの「中の人たち」や,責任問題をガン無視している大臣の皆様方は,いくらくらい報酬を受け取っているのだろう。そんなことをしている人たちが,税金から報酬をバカスカ受け取りつつ「SDGs! 格差をなくそう!」などと言っていないか。おまけに,やれ少子化対策の財源確保のため消費税率上げようとか,新たな税を導入しようとか,「先制攻撃力」の財源確保のため東日本震災の復興支援の一部を充てようとか……やろうとしていることがちぐはぐ過ぎるだろ。まず,ミスしたり,そのミスを見過ごし負担を増やすようなシステムを作る連中の報酬をカットして充てろや。



© M.Ishikawa; TREEWARE 2024.