- ベストアンサー
ユニークID （社保庁問題）
ユニークID （社保庁問題） コンピュータを利用していると、識別（ユニークなもの・唯一のもの）としてユニークIDの概念に直面します。例えばIPプロトコルでのIPナンバーです。イーサネットを開発した各コンピュータにユニークな番号を振り分けた（IPナンバー）先見のある概念です。 で、社保庁の消えた年金問題で国民総背番号を早期に導入していればこのような問題は発生していなかった（アメリカのソーシャルセキュリティー番号を例にとり）と言われています。が、年金手帳を複数発行しようが、入力間違いがあろうが、名前や生年月日を間違って入力しようが、そして結果として一人のユニークな人物が複数のIDを振り分けられていても、コンピュータから見ればそのデータが破棄されていない限り、個人のユニークIDに複数データを統合するのは問題が無いと考えます。あくまでも技術的にはです。 説明が長くなりましたが、質問は「上記の考え方」に何か見落としていることはあるのでしょうか？ よろしくお願いします。 ありがとうございます。
- kaoru-chan
- お礼率60% (256/421)
- その他（プログラミング・開発）
- 回答数7
- ありがとう数5
- みんなの回答 （7）
- 専門家の回答
質問者が選んだベストアンサー
#6です。新たに分かったことを追加。 けっこうざーっと調べた所では、以下のサイトが一番技術的資料が豊富で、よりエンジニア向けですよね。（プログラミング言語の違いに、階層型のデータベース（CDB）とリレーショナルデータベース（RDB）との併用や、社会保険庁と国税庁の比較、などなど・・・。） 厚生労働委員会「５０００万件の年金記録への対応」を提言 http://www.fujisue.net/archives/2007/06/post_1940.html ただし、こっちの日経コンピュータの記事を見ていると、そもそもシステム上の名寄せでは同一人物と特定し切れないものが残るパターンが３つあり、名寄せプログラムが生きるのは、「間違い方が想定できる入力ミス」のパターンだけだ、ということです。 名寄せで解決しない年金記録問題 日経コンピュータ（年金問題取材班）[ 2007/06/18] http://itpro.nikkeibp.co.jp/article/NC/20070618/275038/ 以下のサイトでも、シノニム（同物異名）やホモニム（異物同名）という言葉を使って解説されています。 不明データ５０００万件 年金名寄せ http://www.janjan.jp/living/0706/0706147276/1.php 要するに、古いプログラミング言語に独自OSの乗っかっている汎用機マシンなど、技術的には好ましくなさそうに見える部分も多々ありますが、それとは別に「個人のユニークIDに複数データを統合するのは技術的には問題が無くはない」ということです。（どうしても、人海戦術に頼らざるを得ない状況が有り得る、ということ。） で、最終的にはもう一度、「年金データの作り直し」という風になるわけですね。（まあ、これにも原本を廃棄されたものは新たに作り直すことが出来ない、というオチがあるわけですが・・。） 年金データ作り直し 手書き原本、再入力 http://www.yomiuri.co.jp/iryou/news/kaigo_news/20070621ik10.htm
その他の回答 (6)
- choconamacream
- ベストアンサー率44% (152/338)
COBOL 向こうの方ではもう既に取り上げられていましたね。 Top > ＠IT会議室 > ＠ITクラブ Cafe 会議室 > 年金問題 http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=39368&forum=3&32 ただ一つだけ気になるのは、ちょうど私も先月の「朝まで生テレビ」を見ていたのですが、その時にとある方が「３５歳や４５歳、５８歳のそれぞれにしていた処理を、その他の年齢にまで広げるのには技術的に難しい。（→結果的に、今すぐには年金記録の通知を全ての対象者に送付することは難しい。）」といったようなことをおっしゃっていたんですね。Java使いなんでその辺に関してはよく分かんないけど、COBOLってそもそもcase文やif文はできるけどfor文は無理なの？まさか～とは思いますが・・。
- 神崎 渉瑠（@taloo）
- ベストアンサー率44% (1016/2281)
（´・ω・`）つ「住基ネット」
- dekopa-
- ベストアンサー率42% (161/378)
現状は個人に複数のIDが振られている状態。 で、その「個人」を統合するのが困難だ、という前例がペイオフ解禁時の銀行の「名寄せ」問題。 例えると、「アベシンゾウ」氏が10件登録されているとして、どれとどれが同じ人なのかを判断するのは困難だと言うこと。 住所が違う、電話番号が違う、結婚して姓が変わった、等。 IDがユニークでも、それを個人レベルで統合するのは面倒なので、結局人手に頼る必要があります。 あと、「国民総背番号制」を嫌がってマスコミを煽ったのは、サヨとか後ろ暗い動機がある連中だという通説アリ。 普通の人が、役所の手続きに必要な番号を統一されても明確なデメリットは無い。問題はその番号に紐づけられているのがどんな情報か？という事なので、納税とか年金とか住所だけならどうという事はない。
- neKo_deux
- ベストアンサー率44% (5541/12319)
> 入力間違いがあろうが、 ユニークID自体を入力間違いされると、目も当てられないような？ 問題点は、管理のキー、IDがユニークだったかどうか？でなく、 そういったものを人間が入力、チェックしていたような点とか。 本籍地、生年月日、氏名なんかでも、適当な本籍地で無い限りは重複する事はまず考えられません。 昔のコンピュータの都合で、氏名や本籍地はカタカナでしか扱えなかったってのは痛いですが。 現在でも、漢字コードで定義されていない漢字の氏名だと、微妙かも。
国民総背番号は世論は否定的です ネット全盛なのに法律が整備されてない日本では データだだもれでプライバシー的に問題が多いからです 年金問題に国民総背番号を導入していればというのは後付けすぎですが １００年前から国民総背番号を導入してれば否定的な意見は少なかったかもね
- tky-ny
- ベストアンサー率27% (275/1003)
ユニークＩＤそのものについてはお考えのとおりではないですかね。 http://www1.mhlw.go.jp/topics/kiso/ このページを見る限り、基礎年金番号が必ずしもユニークＩＤとはなってなかった様子です。 厳密に言うと、ユニークではあるのですが、ひとりに複数の年金番号が振られていた模様。 愚かの極みです。
関連するQ&A
- 一意なID
コンピュータ内でなるべく不変で一意な値を組み合わせて、ネットワーク上でほぼ確実に一意な識別子を作りたいと思います。 ユーザー名やコンピュータ名だけでは一意性に欠けるので、ユーザーIDとOSシリアルナンバー、MACアドレスなども足したいのですが、それらは何を参照すればいいのでしょうか? レジストリのパスや関数名などあれば教えてください。 ユーザーIDはHKEY_USERS\S-?-?-??-???・・・に入っていますが、たまにここに複数あって、どれが自分のIDなのかわかりません。 MACアドレスもNICが複数刺さっている場合のプライマリの検出方法など。 ほかにもここに挙げたもの以外に、何かできるだけ一意で不変なものがあったら、教えてください。 IPなど頻繁に変わる可能性があるものはだめです。 開発環境 XP Pro SP1 + VB.NET 言語はVB.NETですが、これに依存しない手段でもかまわないのでVBのカテゴリには入れてません 実行環境 2000またはXP
- ベストアンサー
- その他（プログラミング・開発）
- EXCEL:ID番号の自動入力
EXCEL:ID番号の自動入力 複数のシートに、 B列 C列 日付 案件 が入力されるファイルがあり、A列に自動的にID番号をふりたい と考えております。 可能であれば、B列の日付ごとに複数シートにわたって（シート毎のID ではなく、ファイル内で連番）ID番号が入力されればベストなのですが、 同日付の案件もあるのでそれはやはり関数では難しいでしょうか？ また、B列に日付を入力された時点で、連番式にIDが入力されるVBA を組んだとして、その行を削除した場合、他のIDも自動的に一個前に詰める ように組むことはできますでしょうか？ もしよい方法をご存知の方いらっしゃいましたら ご教示願えれば幸いです。
- ベストアンサー
- その他MS Office製品
- 旧社保庁OB なぜ腐った奴が多くいるのか？
何かとお騒がせした社会保険庁。 終いに、解体されて年金機構に名称替えしています。 旧社保庁の悪党の人脈は、そうとう広いみたい。 旧社保庁OBには、何故腐った奴が多くいるのでしょうか？ 参考記事 ＡＩＪ投資顧問が預かった企業年金の資金のほとんどがなくなっていた問題で、旧社会保険庁のＯＢが、複数の企業年金に対し、ＡＩＪ投資顧問と契約するよう勧めていたことが分かりました。 このＯＢは、ＡＩＪ投資顧問から年間６００万円の報酬を得ていたということで、証券取引等監視委員会は、契約の拡大に旧社会保険庁ＯＢの人脈が利用されたとみて調べています。 http://www3.nhk.or.jp/news/html/20120303/t10013451181000.html
- ベストアンサー
- ニュース・時事問題
- 社保丁は解体せずに存続させる意義はあるのでしょうか？
いつも基本的な質問で申し訳ありません。 このところ「年金問題」については情報量が多すぎてちょっと食傷気味でした。自らの年金記録が正しく社保丁に登録されているか？ を確認しなければいけないなと感じておりました。そしてその労力―納入事実の証明―を考え、ちょっと憂鬱でした。そんなこともあって最近は社保丁関係の記事にはなるべくふれないように自らセーブしていました。 そんな折り。なんで人の神経を逆なでするのでしょうか？ 今朝（07.6.24）の新聞です。 社保丁職員による横領―保険料横領―が1億１千万円にも及ぶそうです。これは社保丁自らが行った内部調査に過ぎません。それも2002年までのデータに過ぎません。ですから氷山の一角でしょう。真実の被害額は膨大なものでしょう。 総理大臣と厚生大臣がボーナスを返還するそうですね。この判断は、行政の長として至極自然と思います。別段評価されるような行為とも思いません。一方で社保丁の職員にはボーナスが予定通り支給される？そうです。個人的・感情的にはボーナスを返還し被害の弁済の一部に当ててほしいとは思いますが… しかし公務員のボーナスはその仕事内容の如何に関わらず支給するというのが暗黙の了解でしょう。 ですから、ボーナスは支給されるのも致し方ないかと思っています。ただし今回が最後にしてほしいと思っています。早急に社保丁を解体し社保丁職員としてのボーナス支給がなくなることを強く望んでいます。 さて質問です。社保丁は解体されずにこのまま存続する意義はあるのでしょうか？ あるとすれば、どの部分でしょうか？ 私は今回の年金問題は第三者機関に調査をゆだね被害を明確にすべきと思っていますー内部調査では隠蔽工作が起こるのは自然と思いますー。そして早急に社保庁を解体すべきと考えています。 被害が明瞭になった後「血税で被害を弁済するしかないかな」とかんがえています。社保丁の仕事の多くは民間でも十分可能なものと考えています。ですから年金は民間に委託して十分と考えていますーもちろんシステムは十分考慮した上での民間委託ですが…。 以上宜しくお願いします。
- 締切済み
- その他（行政・福祉）
- 所在不明高齢者問題なぜ起きるのですか
所在不明高齢者問題なぜ起きるのですか よく年金支給の話が出ますね、という事は戸籍と住民票などがリンクしているという事ですよね。 戸籍が独立した記録なら家族の届け出がなければ判らないという事もあるかもしれませんが、 年金支給とかなら、逆に 住民税、固定資産税、社会保険料、介護保険料、健康保険など・・生きているなら色々な書類があるでしょう、、 どうして役所は判らないのでしょう不思議です。 善意の届け出を前提の仕組みだから役所は判らない・・と言い訳をしますが、だったらなぜ今続々判明するのでしょうか？ 私は昔から、想像していました、社保庁の年金問題の時、公文書のいいかげんさは他にもあると確信しましたが、コンピュータ化しないで手作業でやる以上不正確になるのは必須だと思います。 セキュリティの問題やプライバシーの問題で国民総背番号制がなかなかできませんが国民すべてにＩＤすなわち生まれたと同時に番号を与える方式にすべきだと思います。 それによるマイナス面の問題は運用でカバーすればいいと思います。 私は役所の怠慢だと思うのですが、 少なくとも 住民税はどうなっているのでしょうか？
- ベストアンサー
- ニュース・時事問題
- 2チャンネル ID→IP変換機
２チャンネルの事なんですが ２チャンネルのＩＤでRmaU7sHVが出たとします。 このＩＤを使って (1)個人がＩＰアドレスを特定する事は出来るのでしょうか？ (2) ２ＣＨのＩＤだけで個人がどこまで相手を探る事が 出来るのでしょうか？ またこういうサイトを見つけました ＩＤを入力すればＩＰ番号がわかるサイトです。 ID→IP変換機 http://hp-sv.facty.net/index.php (3)これはイタズラのサイトでしょうか？
- ベストアンサー
- その他（インターネット・Webサービス）
- Apple IDの盗用
Apple IDがよく乗っ取られるという話はありますか？ 私は５つのIDを持っているのですが、なぜこんなに持っているのかというと、それらのIDとパスワードでログインしようとしたところ、このうち３つが「Apple ID が見つかりません。」とでるからです。 AppleではこのIDは削除できないとの回答でしたので、新しく作るしかありません。 当方は年に数回しかMy Appleを使いませんが、久々にログインしようとしたところ、IDが使えないといわれるので、おかしいなとは思っていましたが。 これだけならまだしも、そのうちの１つのIDが、利用していないiTune Cardを登録済みですのでおだやかではありません。登録済のiTune Cardを思い出し、さて、使おうかなと思ったところログインできず、ID検索してみたところこれもないと言われるのです。 別のIDで、iTune Cardのナンバーを入力しなおしたところ、「このコードは使用済みです」とでます。 使用済みのはずはありません。 IDとパスワードもすべて保管しております。 通常、iTune Card自体のナンバーやナンバーに対応する登録済みのIDが違うのでしたら、その旨表示されるはずです。 検索してみましたが、乗っ取られたという声もありました。 この場合も乗っ取りの可能性があるのでしょうか？ さいわいクレジット登録はしておりませんが、乗っ取られたらiTune Cardナンバーも盗まれることになりますか？ そもそもAppleでは問題化されていないのでしょうか？メールがIDになること、それも変更できないこと、ましてやIDが削除できないことは大きな問題だと思いますが。
- ベストアンサー
- ネットトラブル
- 【年金】 ユーザーID、パスワードを発行できません
先日、自分の年金記録を調べたく年金個人情報サービスへ ユーザーID・パスワードの発行申込みを行いました。 １か月以上待たされたやっと郵送されてきた結果が、 「ユーザーID、パスワードを発行できません」でした。 どうやら郵便番号と住所が異なるということなのです。 社会保険庁のHPの入力フォームで入力する「郵便番号」「住所」とは 現住所ではないのでしょうか？ 私は年金に加入した時点から住所が変更となっています。 住所が変わったときの手続きは行っていません。 （手続きは不要と年金手帳に明記されていますので） こういうケースの場合、年金記録を確認するためには 行列覚悟で窓口へ行かざるを得ないのでしょうか？
- ベストアンサー
- その他（年金）
- ID登録の時
ID登録の時に、画像認証がありますが、もしその画像認証の画像をコンピューターに保存しても問題ありませんか？ 保存するつもりはありませんが、気になったので質問させていただきました。 また、その画像認証の入力を間違えてしまったらどうなるのですか？ （例）12345→12335 また、画像認証はメモするのですか？ 僕は一応保存しています。 画像認証は、登録後必要になりますか？ 複数の質問をして申し訳ありませんが、回答お願いします。
- ベストアンサー
- その他（インターネット接続・通信）
- 別々のテーブルで共通のid使う
一つのページから別々のテーブルにデータをINSERTしたいのですが、"id"と"number"は同じ値でそれぞれのテーブルにいれたいのですが、どうやってやるのでしょうか？ 下のPHPのコード(一部)でデータを流してみたのですが、このままやると、もしデータに不具合があって片方だけ登録されないことがあると、一方は登録されて、一方は登録されないという事態が発生してしまい、"id"が違う番号で登録されてしまう可能性があります。 id int(8) NOT NULL AUTO_INCREMENT で"id"は作りました！ $insertSQL1 = sprintf("INSERT INTO tbl1 (id, number, name, price) VALUES (%s, %s, %s, %s)", GetSQLValueString($_POST['id'], "int"), GetSQLValueString($_POST['number'], "text"), GetSQLValueString($_POST['name'], "text"), GetSQLValueString($_POST['price'], "int")); $insertSQL2 = sprintf("INSERT INTO tbl2 (id, number, ename, eprice, extra) VALUES (%s, %s, %s, %s, %s)", GetSQLValueString($_POST['id'], "int"), GetSQLValueString($_POST['number'], "text"), GetSQLValueString($_POST['ename'], "text"), GetSQLValueString($_POST['eprice'], "int"), GetSQLValueString($_POST['extra'], "text")); 別々のテーブルで共通のidを使う方法はないでしょうか？ phpMyAdminのSQLを使ってます。 回答よろしくおねがいします！
- ベストアンサー
- MySQL
