  |
はてなキーワード: チェックデジットとは
いや、実際は11桁なんだよ。最後の1桁はチェック用の数字。チェック・ディジットと呼ばれている。番号の誤入力があった場合はチェックデジットと番号が合わないのでエラーになる。これを誤り検出といいます。
と思ったかもしれないけど、これ、全然すごくないんだよね。チェック・ディジットが1桁だと、10%の確率で偶然ＯＫになってしまうんだ。こういうことはごくまれにしか発生しないけど、日本国全人口が使用するのであれば、数件起こってもおかしくない。これが昨今マスゴミでやかましく報道されている誤入力の原因にもなっている。
2桁にすると1%の確率に。ただでさえ少ない誤入力のさらに1%なのだから、これはほぼほぼ確率ゼロ。でも本当に2桁でよいの？
チェック・ディジットの長さをもっともっと長くすると、誤りを検知するだけじゃなくて誤りを訂正できるようになる。これでほぼほぼトラブルがなくなる。みんな幸せになれるお。
調べたら、銀行によって、チェックデジット無しと有りで両方あるみたいだった
無いところだと連番にもなるのだろう（あんまりそんな口座持ちたくないけど、間違えて引き落されることはなさそうだし、誤入金の可能性が増えるだけだとしてら問題ないか）
同じ支店で有り無しで支店番号が違うケースもあるみたいだけど、そこは名称が分かれてた
と思って、自分の銀行Bの口座から銀行Aの口座番号の±1の番号に振込しようとしてみた
これが、チェックデジットとかがあって適当に入力したり誤入力したときに弾くようになっているのか、
単に、支店が違うところにその口座番号が存在し、支店違いなのでエラーになったかどっちなんだろう
と思って、調べてみた
口座番号は7桁で、実質６桁しか有効ではないから、100万件ぐらいで枯渇するのだけど、そんなに人が集まる支店がないのか
総資産が大きいから口座数が多いとも限らないのだけど、一番大きい銀行は 三菱UFJ～らしい。4000万口座とかあるらしい。
支店とかは17年度末で515店。減らして130～140店とか。一億以上は行ける。
まだまだ十分な数があるし、物理支店減らしても、支店名だけは残ったりするし、まだまだ余裕ありそうだ？
100店切ると危うくなってくる。
そもそも配布済みのバーコード側にチェックデジットがついていない、という根本的な問題らしいんだよねぇ。何が問題かというと、読み取りエラーになるのはまだ良くて、違う人間が接種したことになるのが怖い。当初はスキャナ側の問題もあったんだろうが、ここが解決しないと高性能なスキャナを持ってきても誤入力の問題が付き纏うってことなんじゃないか。高いスキャナを買うにも追加予算がいるしね。でなければ、自治体側があんな頑なに利用を拒否しないだろう。
https://maonline.jp/articles/corona_vaccination_ticket_problem_is_elementary_mistake210520
日付や市町村とかのバリデージョンできるところをバリデーションしていないのが最初の問題なんじゃないの。
日付すらやらないならGoogle Docsのアンケート機能以下なわけで。
予約コードにチェックデジットが入っていなかったのは、防衛省の責任ではないというなら、この案件を防衛省が受けたのがそもそもの間違いだっただろう。
仕様作成をやったところに予約サイトをやらせて、防衛省は現地の運営の手伝いをするぐらいで十分だったのでは。
自衛隊のメリットは、元気で体力がある一定の人を一気に多数動員できることなんだし。
もちろん、防衛医大とかもあるから、医師や看護師も一定数抱えているから、現地での摂取を手助けできる。
予約サイトなんて、防衛省の本来の業務でないものをなぜに受けてしまったのかってところじゃないかなあ。
本来の業務ではないのは、現地でのオペレーションもあるわけで、こちらも大丈夫なんだろうかというも心配になる所。
自衛隊だから設営はできるだろうけど、やってきた人を誘導して会場回すオペレーションのイベント運営のプロではないわけで。
https://anond.hatelabo.jp/20210517234543
「ひでえ」とは言うんだが、あれ、接種券やその配られ方そのものが、あまり予約システム化した場合の対応について考慮されていないので、あの仕様になったのもどうしようもない。
流石に年齢チェックとかは・・・・・・とは思いはするが、あんまり意味のないチェックではあるしな。
他の会場で予約しても予約出来る、というのは、ちょっとシステム連携は難しいし、コストを考えるとやるべきでもない。
通常の予約システムは、イベント毎に大きければ1万人くらいの人を受け付けるというシステムになるのだが、今回の予約はそれを毎日分で処理するという形になるし、他の接種会場は自治体規模によってはそれが月2回とかそんな感じになる。千を超える自治体間とかで連携するのは、不毛でもあるし。
そもそも、自治体単位でやってるのであれば、全国規模で連携する必要もないのよ。一自治体の中の予約システムで弾けばいいだけなので。
東京や大阪が異例な接種会場を設置した為に、厄介な事になっている。
とは言え、自治体内で閉じているシステムであっても、なんでかシステムダウンしていたりするのだけど、多分予約受付とかの更新と予約参照の照合とかのDBアクセスがあまり工夫されていなくて厄介な事になっていると思われ。そんなシステムが連携とか出来る訳もないしなー。
生年月日のチェック機能は、今後を考えるとたるい。あの大規模接種会場用だもの、当然ながら発注時には「年齢制限等を切り替える設定を盛り込め！」とかってやってないと思うし。そもそも接種券の発行時点でセレクションされていて、それが高齢者な訳だし。
桁数チェックはあってもいいけど、やれるのそこまででしかない。なお、東京会場の場合には関東近辺の人が中心だと思うが全国の自治体のコードかどうかチェックいるのかねえという気がする。本来、接種番号には余裕を持った桁数でチェックデジットとか入れつつやって、関数で誤入力チェック出来るようにはしておいてほしかったが、今更だしなあ・・・・・・
予約時に本人照合とか要らないんじゃね？とか割り切ったシステムだとは思う。ただまあ、二重登録はボケた爺さんとかやりそうなんで、そういう「予約した人がこねえ問題」は別途対応した方がよさそうだなあ。
なお、これ高齢者だからではなくて、大規模にやると必ず予約をすっぽかす人は出て来るし、そのあたりは柔軟にしてほしい。
いっその事、お上から接種会場や接種日時割り当ててもらった方が楽なんだが・・・・・・流石に用事としての優先度は上げるからさあ。まあ、一定人数接種拒否する人がいるから、意思確認含めて予約としたい気持ちは分かるけど。結構な人数予約が難しいとかで離脱しちゃうんだよな。
あと。
マスコミ、試しにシステムなぶってみたとかはいいんだけど、そういうチェックに意味があるかとか含めてもう少し記者も考えてほしい。
ハッキリ言って雑なんだけど、でも雑に予約するシステムだ、って割り切って使うものだと思ってほしい。
で、雑だよ、って話を、予めリリースとともに説明つけておいてほしいな開発側も。予約システムに個人識別とかはないんだけど、接種会場ではある訳で。
こんなやっつけの予約システムで、うっかりマイナンバーカードでの認証とか使ったら、むしろボロい予約システムがハックされた時に個人情報を引き抜く踏み台にされるので、これはこれでいいと思う。
政府向けシステムに関わったことがある身からすると、政府向けシステムの話をするときに前提として知っておいてほしいことは、住基ネット最高裁判決に「現行法上，本人確認情報の提供が認められている行政事務において取り扱われる個人情報を一元的に管理することができる機関又は主体は存在しない」という骨子があること。これによって政府向けシステムは個人情報を一元的に管理できず、個人情報は各自治体で分散管理しかできない。この文面でググれば政府がどれだけこの骨子を気にしているかは分かると思う。
今回の話は「国民マスターテーブルを持たずに認証するにはどうすべきか」という政府向けシステムで常に挙がる課題で、良いアイデアがある人は政府に提案しにいってほしい。個人情報保護法の目的外利用に違反しない上で。
これをできるのは自治体のみで防衛省はできない。防衛省は国民の住所氏名を知らないのではがきを送れない。防衛省に限らず、どの省庁も国民の住所氏名を一元的には知らないので、政府はできない。
かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的にそう言えないというのはあり得るが、乗り越えなければならない」課題。
これで良いなら予約システムなんていらないけど、密を作って高齢者に何日も前から徹夜で並ばせるのが今のシステムより良いと思う？
政府が使える一元的な情報はマイナンバーしかない。マイナンバーカードを読み取れる人だけが利用できる予約システムなら認証できるけど、自治体のネット予約さえ高齢者には使えないと叩かれているのに「マイナンバーカードとリーダーが必要です」なんて要件で作れるわけがない。そもそも「短期間に多くの人に接種させる」という目的にもそぐわない。
各自治体の予約システムがAPIを持って防衛省が接種券番号の有効性をAPIで確認できれば認証できるけど、首都圏だけで200以上ある自治体がばらばらに調達しているすべての予約システムに高負荷でも落ちないAPIを共通仕様で緊急で作らせれる必要がある。けど、そんな体力があるならば自治体の予約システム自体が落ちないようにすれば良いわけで、大規模接種自体が不要かもしれない。
個人情報を一元的に管理することができる機関を立法すればできる。けど、そんなものは「たった1年」じゃ作れない。マイナンバーと住基ネットに何年掛かったと思っている？「パンデミックという緊急事態なので防衛省が高齢者の個人情報を一元的に管理することができる」世界は「戦争という緊急事態なので防衛省が20代30代男性の個人情報を一元的に管理することができる」世界につながっていることを理解した上で、国民はこの法案に賛成できるのか？ できるなら、良くも悪くも政府向けシステムの将来は大きく変わる。
結局、「国民に行政サービスを直接提供するのは自治体で、そのための個人情報を持っているのも自治体。政府は自治体を支援する」というデザインですべてが作られている日本において、菅の「政府主導でのワクチン接種」というアイデアの実現がそもそも無理ゲー。出生届や転入届を出すのは各自治体、運転免許の番号を発行しているのは各都道府県公安委員会。政府は国民の個人情報が一元的に入った共通データベースをどこにも持っていないから管理できない。従来通り、政府は自治体の支援に特化するべきだった。
中国みたいな管理国家に日本はならないという選択を国民がした時点で、この予約システムでの認証の実装の難易度は相当高い。ウイルスとの戦いに強い国は戦争にも強い国で、「人間にせよウイルスにせよ、敵との戦いに勝つために国民は政府にどれだけ一元管理されてもよいか」の総意を国民が取らないといけないので、マイナンバーや住基ネットの実績を考えると1年くらいの準備期間じゃ、みんなが期待している認証をこのシステムでは実現できない。
チェックデジットがないことで誰かの誤入力で自分の予約ができない確率が上がっているのは残念。ただ、発券しているのは各自治体なのでチェックデジットをつけられるのも各自治体なので、開発会社も防衛省もやれることはない。誰なら事前に自治体に統一仕様で作らせられたかというと厚労省だけど、接種券の仕様が決まったあとに大規模接種の話が出てきたので事後諸葛亮。こんなこともあろうかとチェックデジットの指摘が事前にできる勘が良い人がいたなら、たぶん落ちない予約システムの作り方の指摘も事前にできただろうから、大規模接種自体が不要だったかもしれない。
現状でもreCAPTCHAでBot対策されている。reCAPTCHAを越えて大量予約するやつは悪意があるので逮捕で良いでしょ。
できた。でも、接種券番号のバリデーションができない時点で大した意味はない。入力フォームの電話番号にSMS送って電話番号全体の有効性を確認することはあっても、市外局番の存在有無だけをバリデーションするなんてことしないでしょ。入力された市外局番と市外局番マスターを引きあててバリデーションをしている者だけが石を投げられる。
防衛省は生年月日の正しい情報を持っていないので、この数字に大した意味はない。たぶん予約キャンセル用のパスワード相当、当日の誤入力を見つけるためのヒントくらいの意味しかない。「パスワードを設定してください」でも良かったんだけど、高齢者には難易度が高いと思って生年月日にしたんだろう。秘密の質問みたいなもの。あなたの母親の旧姓が本当に正しいかどうかにシステム側は興味がないのと同じくらい、この生年月日が正しいかどうかに大規模接種予約システムは興味がない。
いまだに具体例が出てこないので、多分ガセ
異なる市町村番号＋同じ接種券番号＋異なる生年月日でログインできないことで接種券番号だけがユニークと主張しているけど、ログインできない理由はそれだけじゃない。たとえば2-123,5678がすでに登録されていることをこの人は知らない状況で、この人は1-123,1234でログインできるけど、2-123,7890はログインできない。システムとしておかしくない。
よくあるコメントに返信。
法律は素人のシステム屋なので、この指摘は正しいのかもしれない。一方で「個人情報とは個人を一意に識別できる情報のことを指すもの」というコメントもある。私には判断できないけど、仮に個人情報ではないとすると、
かなり難しい。上の骨子により防衛省が個人情報を一元的に管理することができないので、最高裁判決とは条件が異なることを主張しないといけない。たとえば「接種券番号は個人情報ではない」とか「都市圏だけなので一元ではない」とか。それに国民や野党が納得するかどうか。これがひろみちゅの言う「政治的に（『接種券番号と生年月日は個人情報ではないので一元管理します』とは）言えないというのはあり得るが、乗り越えなければならない」課題。
が正しいのかもしれない。住基ネット最高裁判決によって政府向けシステムに認証機能をつけることは想像以上に難しいという趣旨は変わらないけど、悪いのは菅じゃなくて「個人情報ではない」で突っ張れなかった防衛省なのかもね。いずれにせよ「認証すらまともに作れない技術力」から「接種券番号は個人情報なのか」に議論が高まってくれれば書いた甲斐があった。
VRSってのは各自治体の接種会場で使われているバーコードがなくてOCRが必要なことで有名なシステム。OCRは置いておいて、VRSは一元管理していない。 https://cio.go.jp/sites/default/files/uploads/documents/vrs_overview_210506.pdf の6ページ目に書いてある。
＞市区町村ごとに区切られて保存されており、個人の記録は、接種券を発行した市区町村が確認できます
国民の接種率が重要指標なんだからDBは1個にしたほうが便利なのに、「あえて」区切って保存している。また、個人の記録は各市区町村しか確認できい、つまり串刺しで全国民の個人記録を見られる人はいないと書いてある。そんなわけでVRSは「政府は一元管理していません」に気を使っていることが分かる事例。
「一年前から」論もシステム開発という面では若干事後諸葛亮なんだよな。自治体主体での接種で厚労省は進めてるので、国主体の接種を想定した予約システム開発は発注できない。そこを動かせ、というのはもはやシステムより業務の問題だし。
「一年前から」論で唯一いえるのは、最終的な接種完了自体は国も把握する必要があるので、接種券番号の発番は国が国民に割り当てる、ぐらいかなぁ。接種券番号は自治体コード+自治体内で一意な10桁だけど、後半の10桁で例え1桁チェックデジット入れても国民全員に一意な数振れるので。ただこれも国外からの帰国や出生による番号の追加もあり得るので、結構業務がめんどくさくなるよな。
チェックデジット理解してる？ チェックデジットは善意のユーザが一桁ないしは隣り合う数字をtypoしたときに誤りであると計算で判定できるだけで、悪意のユーザを防ぐ性質のものではないよ。誤登録の防止にはなるが、悪戯での架空番号の登録を防止できるものではない。
接種券番号の有効性確認せず何でも受け付ける以上は、Luhnアルゴだろうがdamm法だろうがチェックデジットを悪意のユーザ側で算出して付加すればいいんだから。
接種券番号の採番及び管理の運用の誤りは既に散々指摘されており、ひろみちゅ先生が言うとおり一年前の自治体での接種業務のフローを厚労省が検討する際に原因はある(ただそのタイミングでは各自治体での接種が原則で、それに基づく業務フローを決めていたので、防げたかというと怪しい)ので、システムの問題と言うより業務フローの問題。
International Standard Book Numberの略称で、世界共通で図書（書籍）を特定するための番号である（wikipedia）。
２００６年まではISBNは１０桁で運用されていた。俗にISBN-10と呼ばれる。１０桁の内訳は
言語記号-出版社記号-書名記号-チェックデジット（以下CD）
となる。各桁の割り当てはCDに１桁、以外は決まっておらず、CD込みで合計１０桁になる。
各項目の概要は
２００７年以降は１３桁に移行した、俗称ISBN-13、内訳は
ISBN-13に移行した理由は、英語圏でのコードが枯渇してきたため（その場合perfixに９７９が追加された）、EANコードとの共通化を図るためである。ISBN-13への以降に伴い、CDの計算方法が変更されたのは、CDの計算方法がEANに準じたためである。
手近のバーコードが印刷されている製品を見ると、45もしくは49から始まる１３桁の番号が印刷されている、これがEANコード（日本の場合はJANコード）である。
ISBNが書籍識別番号なら、EANコードは世界のあらゆる商品の識別番号である。こちらの概要は詳しくは説明しないが、
このEANコードとISBNを共通化させるために行われたのがISBNの１３桁化である。
先頭のコードは国を表す（日本は45と49）が、書籍という商品にのみ９７８、９７９という固有の番号が振られている。
当然の事ながら、製造者が勝手な番号を振っては共通コードの意味を成さないので、国別にコードは管理されている。
日本の書籍の場合は「日本図書コード管理センター」が、JANコードは「財団法人流通システム開発センター」が一元管理している。
以上の事から「勝手なISBNを発行する」という行為がどれほど業界無視かわかるだろう。
wikipedia電子化書籍の楽天ISBNは、例えば「芥川龍之介」の場合
が付与されているが、このISBNの問題点は、勝手な番号が振られている事以外には
という点である。楽天ISBNがどの程度広く利用されるかは不明だが（楽天内部ですら使ってほしく無いが、１３桁もいらんだろ？）、
商品コードの混同、汚染という事態を惹起する可能性がある。「ISBNコード」が「商品番号」に変わった今、
あまり心配は無いだろうが、世界共通のコードを勝手に我が物とする厚顔無恥な態度は会社の体質と考えられ、
今後に同じような事態を引き起こす可能性は大いにあると考えられるので、
