■★桜を見る会の「招待者名簿」は簡単に再作成できる、リレーショナルデータベースにデータがあるから
★桜を見る会の「招待者名簿」は簡単に再作成できる
★招待(候補)者のデータはリレーショナルデータベース(RDB)に保存されている(99%の確度)
★市民・野党・マスコミは RDB を理解して、より"実効的"な追求をしよう
メモ by 澤田石 順 jsawa@nifty.com version 1.3 (2012/1/26)
(文書の履歴: 1/22 version 1.0, 1/24 version 1.1, 1/25 version 1.2)
※ RDB についての理解がないと、私の訴えは意味不明で説得力なし
なので、少し詳しく説明します。本文書は長いですから、冒頭の数ページを
読んで本質的な理解が得られたと思ったら、そこから先は読まないで、行動を
開始することでもいいと思います。ただし、RBDについて生半可な知識で
質問すると、瞞されかねないので、できればデータベースエンジニア
に RDB の性質についてレクチャーしてもらうことが望ましいでしょう。
本文書は同じようなことを繰り返してますが、それはあえてしました。
RDB の運用経験がない方が対象なので、表現を変えて繰り返さないと
つまり冗長に説明しないと、正しい理解には至らない蓋然性が高い
からなのです。
※ https とかのインターネット文書の場所はカラーで表示されてませんが
そこをクリックすると当該文書に飛びますので、パソコンとか
フマートフォンにダウンロードできます
▼本文書の所在:
note → https://note.com/sawataishi/n/n2dc46744c665
twishort→ https://twishort.com/tUGnc
PDF文書 in dropbox→ https://www.dropbox.com/s/546bhqaxffcgbms/20200122-%E6%A1%9C%E3%82%92%E8%A6%8B%E3%82%8B%E4%BC%9A-2.pdf?dl=0
平文テキスト in dropbox→ https://www.dropbox.com/s/546bhqaxffcgbms/20200122-%E6%A1%9C%E3%82%92%E8%A6%8B%E3%82%8B%E4%BC%9A-2.txt?dl=0
■はじめに
政府であれ企業であれ病院等であれ、何千何万の人々についての生データをマイクロソフトのエクセルのようなセキュリティー無しのソフトで管理することはありません(昔はそんなことをしてたけど)。
莫大なデータはリレーショナルデータベース(RDB)に入力され、蓄積されています。市民・野党議員・報道人のほとんど全ては、RDBを現実に管理・運用した経験がないために、桜を見る会の「招待者名簿」がどのようにして作成されるのか理解してないのです。だから、「招待者名簿」を復元しろとか、隠しているんだろうから出せとかばかり要求しているのです。そのような要求のみだと、モリカケのように政府はいつまでも頬被りするばかりで、解決はできないでしょう。
「招待者名簿」の作成過程はこうなります。当然のことながら、前年度までの桜を見る会の招待候補者データはRDBに蓄積されてます。その年の桜を見る会の何ヶ月か前に、官庁や自民議員等の事務所から送られてきた招待推薦リスト(主として電子データでしょうが、紙の場合もあるでしょう)に関して、RDBにその人物の名前があるとき修正が必要ならそうするし、名前が無いなら追加します。それから招待候補者の1人1人に関して、「2019年に招待」という項目をマウスでクリックする。審査など全くなしで、無条件にクリックしている蓋然性が高いでしょう。「招待者名簿」は「2019年に招待」がYESに限定して、電子データとして出力されます。電子データである「招待者名簿」を印刷する実務的な必要はないと思いますが、役所は今でも紙にこだわっているし、役所では紙に決裁の印鑑を押さないと正式な承認とならないので、印刷しているわけです。
何故、印刷された紙も電子データも破棄したのか? 紙に関しては保管する場所を取るのでそもそも無駄なので破棄しないわけにはいきません。ところが、破棄する期限があり、破棄した記録を残さねばならないのにしなかった。破棄記録を残さなかったのは違法で問題ですが、たいしたことではないのです。電子データの破棄にしても、実質的には違法でもたいしたことではない。なぜならば、リレーショナルデータベースにデータは残っているので、「招待者名簿」の再作成など簡単にできます。だから、「招待者名簿」の再作成を要求したらいいだけのことなのです。
政府は「招待者名簿」の再作成を求められた時に、リレーショナルデータベースから既にデータを削除したのでそれはできないと言うかもしれません。実際に本当に削除したとしても、リレーショナルデータベースのデータは日常的にいくつもcopyされて保存されておりますから復元は簡単。削除したとの主張を事実だと証明する唯一つの方法は、削除したことを記録するログを提示すること。またも、ログの提示は不正侵入につながりかねないと嘘を言うでしょうが、その嘘は放置してもいいと言えなくはないのです。
「招待者名簿」という単一の電子データは完全な削除が技術的に可能ですし、リレーショナルデータベースに蓄積された莫大なデータの削除も可能ですが、リレーショナルデータベース管理システムは自動的に日常的にバックアップ(copy)しており、copyされたデータを全て削除することは、データベースエンジニアという高度な技術者でないとできません。
■本文書の目的
1) 市民・野党・マスコミ関係者が、桜を見る会の「招待者名簿」や集計データは政府のリレーショナルデータベース(RDB)に蓄積されている生データからの産物だと理解すること
2) RDBに蓄積されたデータの一つ一つはそれ自体としては公文書とはみなされないであろうが、政府が生データを消去した公算は極めて低いと、市民・野党・マスコミ関係者が理解すること
3) RDBというものは高度なセキュリティーを有するので、もしも蓄積された何千人の生データを削除したらきちんと記録されるし、しかもデータの復旧は容易だと、市民・野党・マスコミ関係者がしっかりと理解すること
4) RDB におけるテーブルの構造、それしてテーブルとテーブルの関連付けについて基本的に理解すること
5) 市民・野党・マスコミ関係者が RDB の生データから「招待者名簿」を再作成して公開しろと、しつこくしつこく要求すること。最終的には公開されること
■解 説
私は 1/22 に「招待者名簿」という公文書は本当に完全に削除されているとしても、その元データは必ずリレーショナルデータベース(以下、RDB)に保存されているに違いない(99%の確度でしょう)ことに気付きました。気付くのが遅すぎた理由は、公文書管理法に違反して破棄するなどあり得ないし信じられなかったからでした。
さて、昔は企業も役所も住所録などのデータはエクセルなどのシンプルかつ幼稚なソフトで管理してましたが、今では RDB (リレーショナルデータベース)に生データを保存します。ちなみに、私が勤務先病院で患者データをRDBで管理するようになったのは2003年から、RDBによりデータ処理は飛躍的に向上しました。11ある病棟の医師、看護師らは目の前のパソコンから患者データを入力・修正できるようになりました。データは日常的にbackupされているので、希におこるデータ破損があっても、復元は簡単に。医学論文を作成することは極めて容易になりました。例えば、71～89才までのくも膜下出血患者の治療成績はどうかとの統計処理をするときに、 RDB からデータを抽出して、得れたデータを統計処理ソフトで解析するようなこと。(なお、病院の電子カルテシステムにおいてもデータは PostgreSQL などの RDB に格納されます
※RDBの運用は高度な技術を有するエンジニアでないとできません。
病院の電子カルテの場合、RDBの管理は契約企業の社員が行ってます。
政府の場合も政府職員が RDB を管理することはまずあり得ないと
考えられます。RDB のうちMySQL, PostgreSQLなどはフリーソフトなので
政府がデータベースエンジニアを雇用するならば、自前で
"リレーショナルデータベース管理システム"(RDBMS)を構築して運用する
ことができなくはありません(例、MS Access + MySQL)。
しかし、民間企業が有料のソリューションとして提供するの RDBMS は
"手作り"のよりも遙かに入力も出力も高機能であり、堅牢かつ安全です。
▼リレーショナルデータベースは素朴なデータベースでは無い
ちょいと脱線するように見えるかも知れませんが、私の主張を理解してもらうためには必要なので、年賀状ソフトを例にしてRDBの特質を解説します。年賀状ソフトを用いてデータ(名前住所など)を管理している人は多いでしょう。年賀状ソフトはデータベースの一種ではありますが、リレーショナルデータベースではないので、データ項目は最初から決まっており、1人1人について新たに項目を追加したい、例えば twitterやfacebookでの名称を加えたくても、それはできません。「その他」に追記するくらいです。RDBというものは、テーブルに新たに項目をいくらでも追加できます。それだけではなく、リレーショナルなこと(関連付けできる)ことが最大のメリットなのです。
年賀状を送る候補者が1000人いたとして、貴方独自に新たな分類を作成して、その分類ごとに印刷することはできません。もしも、年賀状をRDBで管理するとそれができます。新たな分類名を格納するテーブルというものを RDB に新規作成するのです。1-家族、2-親類、3-極めて大切な友人、4-まあまあの友人、5-単なる知人、6-今の職場の人達、7-国会議員・・とかという新たなテーブルを作ります。年賀状送付候補者のテーブルと新たに作成した分類テーブルとを「関連付け」るのが RDB の優れた点です。年賀状送付候補者に関する諸項目に、新たな分類を追加するわけです。新たな分類を入力する時には、マウスをクリックすると、複数の分類がずらりと並んで出てきて、当てはまるのをマウスで選択したらそれでOKです。
以上、RDBについて簡単に例をあげて解説しました。本題に入ります。
▼RDBにおけるテーブルとフィールドについて
このことを理解できないと、反社会的勢力の山口しの番号「60-2357」のことがわからないのでお付き合いください。
以下の話は、自前で"リレーショナルデータベース管理システム"(RDBMS)を構築して運用していない(政府は間違いなくこうでしょう)、つまり民間企業が RDBMS を有料で保守管理しているという前提です。
テーブルとフィールドを作成するのはデータベースエンジニアのみに可能なことです。内閣府の役人はエンジニアに項目リストを示すことはできますが、生半可な知識しかない素人にはテーブルとフィールドの定義をする自由など与えません。テーブルに新たに項目(フィールド)を一つだけ追加する場合は、無料でしてくれるようなことはあるかもしませんが、新たにテーブルを追加することは有料化かもしれません。
RDBにデータを入力すること自体は内閣府とか病院の素人がします。入力はwebpage閲覧ソフト、マイクロソフトのアクセスとか、専用のソフトでもないでもいいです。データはテーブルに蓄積されます。
テーブルの中味はこんな感じとなります(テーブルには好きな名前をつけます)
以下に示す、テーブルの諸項目を「フィールド」と呼称します。
(テーブルとその内容であるフィールドには理解しやすい名前がつけれられます。table X, A...としてますが、そのような名前では絶対にないです)
-table X(審査の水準)
1. 通し番号(これは自動的にふられます)
2. 審査の水準: 推薦があれば無条件に招待、2年連続はダメ、三年連続はダメとかの文字列
-table A(招待候補者の個人情報)
1. 通し番号
2. 名前, 3. ふりがな, 4.郵便番号, 5.住所, 6.電話番号
7.所属(誰の後援会、会社名等), 7.推薦者(安倍晋三とか外務省等)の分類番号
9.招待する年(例えば2019), 11.招待する年の招待のyes/no
12. 招待履歴, 13.審査の水準についての番号
※12については自動入力だと思います。例えば2001年から2200年まで
システムを運用すると規定するならは、200年分の招待について
200桁の2進数で表現します。10番目のフィールドが2019で、11番目の
フィールドにyes(yesと文字打ちするのではなく、マウスで
クリックすると実際は1が入る)と入力すると、2進数の19番目が0から1となり、
12の招待履歴には2進数でも16進数でもよいので数値として自動入力するのです。
内閣府がさすがに過去の招待履歴などどうでもよいと考えないでしょうから、
RDBMS の運用会社には招待履歴の記録を求めたろうし、求めなくても
企業は履歴を残しますかと質問したことでしょう。ほとんど確実に
過去の招待履歴は記録されています。そうでないと実運用に支障をきた
します。安倍後援会から推薦された人物に関しては何年連続しても
無条件とし、石破さんの後援会の者については二年連続はダメとかの
内部的ルールの運用は不可能となりますから
そもそものこと、履歴のことはともかく、毎年毎年何千人のデータを新たに
入力して、せっかくのデータを全削除するような馬鹿げたことをするはずは
ありません。このことは内閣府についても諸官庁についても同様であり、
安倍事務所などに関しても同じ。安倍事務所のパソコンには、100%の確度で
招待候補者のリストが電子データとして存在します。
云うまでも無く、安倍事務所にしろ、内閣府以外の官庁にしろ、次回の
桜を見る会の推薦者リストは電子的にのみ提供するのであり、紙で
送ることなどありえません。
電子的に提供された招待推薦者リストをいちいち役人が手作業で、この人は
新しいのか、既に RDB にあるのかとcheckすることもありえません。
住所、電話番号、所属が変わってないかいちいちcheckすることも当然に
ありえません。
computerが自動的に処理する方法は簡単です。
1) 内閣府はエンジニアに命じて、電子データの形式の定義を依頼する
例えばこのような順番と内容のエクセルデータで提出をと
推薦者(安倍晋三とか外務省等)の分類番号(あの反社会的人物だと60)、
名前(姓名の間は半角空白)、ふりがな(空白付き)、住所・・・・・・・
2)データの追加や修正
内閣府が外務省や安倍事務所からエクセル等のカタチで定義された
形式でデータを受け取ると、リレーショナルデータベース運営会社が
作成したソフトウェアにファイルを読み込ませることでしょう。
すると、ソフトウェアは瞬時に既に RDB に記録されているのかを判定し
存在してない場合は、新たにレコードとして追加します。新たに
記録された人物に関しては 60-3553 とか自動的に番号がふられます。
既に記録されている人物に関しては、電話番号などの変更があれば
瞬間的に修正します。おそらく、推薦された人物に関しての
"11.招待する年の招待のyes/no"にはYES(実際は1)と自動入力される
ことでしょう。
以上、長々と説明しました。このように詳しく説明しないと、リレーショナルデータベースの運用経験がない方には理解できないからであり、理解しないで野党議員等が内閣府に質問しても、騙されてしまう蓋然性が高いからなのです。
ここまで読んで下さった方は、内閣府が自民・公明議員や官庁から送られてくる、何千人もの招待候補者のデータをゼロから入力していることはあり得ないことわかると思います。非常に苦労して入力した数千人以上のデータを毎年毎年破棄するとしたら狂っているか、都合悪いので敢えてしているかのどちらかです。そのこととは別に、莫大なデータをエクセルのごとき素朴なソフトで管理していることは絶対にないこともわかると思います。
-table B: 郵便番号
1. 通し番号, 2.郵便番号, 3.住所(郵便番号からの住所なので何番地までではない)
-table C: 推薦者(安倍晋三とか外務省等)情報
1.通し番号, 2.推薦者の分類番号(総理ならば60), 3.推薦者の名称
-table D: 推薦者の分類番号毎の情報
1.通し番号, 2.推薦者の分類番号, 3.table Aにおける候補者の通し番号
4.分類番号毎の候補者の通し番号
レコードと呼称されるのは、テーブルに格納されたフィールドのセットで、table A ですと例えば、"23, 山田 二郎, やまだ じろう、2270048, ...."。table A に登録された人物が 8765人ならばレコード数は8765。新たにレコードを一つ追加すると、新規レコードの通し番号は8766となります。
もしも、1000あるレコードが100のレコードを削除すると、レコードの総数は900となりますが、削除後に追加したレコードの通し番号は 1001 になります。つまり、通し番号というものは必ずしもレコードの総数を意味しないし、レコードの通し番号が 556 だから、そのレコードは556番目ということには必ずしもなりません。
ちなみに、レコードの削除は役人とか医師などのエンドユーザーの全員に許可されてはいないのが通常だと思われます。レコードを構成するフィールドの削除と修正にしても、すべてのフィールドについて自由ではありません。例えば、私の勤務先病院の電子カルテにては、患者のID、名前などの修正削除は医師や看護師には許されて無く、医師らには日々の記録を記すこととその修正と削除は許されてます。もちろんのことですが、修正と削除は自動的に記録され、間違った削除とかしたばあいは、一定期間まで遡って復元できます。ただし、復元する権限は医師たちには許されてません。
かくのごとく、リレーショナルデータベース管理システムは堅牢に作られております。桜を見る会の招待者名簿は単一のエクセルとかPDFファイルでしょうから、それを消去することは簡単にできますが、RDBに格納されたデータのうち、住所というフィールドの内容を修正・削除するようなことは内閣府の役人には自由にできましょうが、レコードの削除は役人のうち一部のみにしか権限がないのではと思います。レコードの削除がどの役人にも許されているとしても、何千人ものレコードを削除してもログはのこるし、かなり前まで復元できます。どの程度の過去まで復元できるかは契約の内容で規定されていると思います。一日単位で、365日前まで復元できるという契約かもしれないし、二年前まで一日単位かも知れません。。
▼テーブルとテーブルのリレーション(関連付け)について
table のフィールドをみて気付かれたかも知れません。郵便番号と招待者の分類番号等が共通していること等を。この共通するフィールド(項目)を関連させる(リレーション)ことができるのが、リレーショナルデータベースのメリットです。
例えば、table A(個人情報)の入力をマイクロソフトアクセス等からするとき、郵便番号の7桁を入れると、"5.住所"に自動的に住所データが入るようにできます。完全な住所ではもちろんないので、後は何番地とかを入力して完全にします。推薦者の分類番号を入れる時は、その項目をマウスでクリックすると60とか59とか、ずらりと選択肢が出てきます。該当するのをマウスで選択すると、"7.推薦者の分類番号"が入力されます。
▼「60-2357」という招待葉書の番号はどのようにして決まるのか?
table C の フィールドを私はこう定義しました
1.通し番号, 2.推薦者の分類番号(総理ならば60), 3.推薦者の名称
table C のフィールドをこのようにしても実用的にはOKです
1.通し番号, 2.推薦者の名称
反社会勢力の山口氏は「60-2357」。60は官邸枠であることは確定してます。この
60は通し番号なのか、それとも推薦者の分類番号なのか? テーブル構造が前者ならば、通し番号ではなく、「任意」に決めた分類番号でしょうし、テーブルが後者ならば必ず60は通し番号です。
もしも私が当該リレーショナルデータベースを管理するとしたらば、前者の構造で定義します。何故ならば、通し番号だと RDB が勝手に順番にふるので、番号を任意に決めることができないし、番号の修正もできません。
どちらにしろ、60は官邸枠。さて、2357という番号は何を示すのか?
case 1: 内閣府の招待候補リストの通し番号
つまり table A (招待候補リスト)にて自動的に振られた通し番号。この可能性はゼロだと思います。何故ならば、山口氏の2357という番号が通し番号だとしたら、彼は2357番目に登録されたことを意味するのであり、毎年毎年何千人が招待されてきたのであるから、2357という小さい数値となるはずは全くありえません。
case 2: 60という推薦者毎のテーブルにおける通し番号
この可能性は大いにあります。山口氏が自民党のお気に入りなので、招待候補者のリレーショナルデータベースにかなり早い時期に登録された公算は小さくないから。
重要なテーブルについて再掲します。
-table D: 推薦者の分類番号毎の情報
1.通し番号, 2.推薦者の分類番号, 3.table Aにおける候補者の通し番号
4.分類番号毎の候補者の通し番号
table Dのフィールドへの入力は table A に候補者を追加すると瞬時に自動的にできます。そのように作るのは簡単であり、そうしないことは考えられません。
データ入力のソフト(MS Accessでも専用ソフトでもなんでもいい)にて山口氏のデータを入力するとき、推薦者の分類という項目をマウスでクリックすると、ずらりと番号と推薦者名(安倍総理とか外務省とか)が出現し、マウスで選択します。すると、60 が入力されて、table D に60の分類番号では何番目かという「分類番号毎の候補者の通し番号」を自動的に入力するためのプログラミングは簡単なのです。
アルゴリズムはこうなります。
推薦者の分類番号を入力した直後にtable A の全データをサーチして、推薦者の分類番号 60 の総数を求める。この時点でデータは RDB に保存されてないので総数は当該データを含まない数です。そして、"総数+1"を"分類番号毎の候補者の通し番号"として自動入力する。データを保存するためにマウスで「保存ボタン」を押して、当該人物に関するデータは RDB に入るわけです。
すなわち、case 2 が事実だとすると、山口氏の 2357 という番号は、総理枠で 2357番目に登録されたということになります。
★★重大なこと★★
2357が60という分類番号で登録された順番を示すかどうかを確認する方法があります。桜を見る会に招待された人は、新宿御苑の入り口で招待状を示すわけで、内閣府が認めてきたように必ずXX-YYYY の番号が振られてます。
二回以上招待された方を一人でも2人でも見つける。そして、XXの番号がいつも同じな時、YYYYも同じかを確認するのです。同一の XX で複数回招待された人の YYYY が同じならば case 2 が事実だと強く強く示唆されます、というか確実でしょう。
case 3: 2357という番号は 60 という推薦者番号毎の登録順番を意味するのではない
これも十分にありえます。
2357という番号は 60 という推薦者番号毎の登録順番ではなく、実際に招待状が送付された人達に限っての通し番号ということ。この場合も番号付けはアルゴリズムにより自動的になされるわけですが、招待された人々の番号をどのように振るかのアルゴリズムは何十種類も考えられます。
・単純にふりがな順に番号を振る
山口は「や」なのでほとんど最後の方。総理枠の数からして 2357 は
数字として若すぎるように思います
・郵便番号とふりがなでソートして番号を振る。
どのように番号をつけるのかは、実のところどうでもいいのです。大事なことは、case 2 が事実なのか否かを確定するための調査です。同一人物の分類番号(例えば 60) が2年前も昨年も同一な人について、分類番号に付加された4桁の番号が同じなのか否かを確認することが極めて大切で必須であることを再度強調します。
▼RDB から「招待者名簿」は何に出力されるか、招待状はどのように印刷されるか
RDB そのものにはエクセルとかPDF文書に出力する機能はありません。商用の RDBMS においては出力するためのソフトが含まれていることでしょう。Microsoft Access やエクセルとの接続を可能としている RDB 管理システムもありましょう。
出力ソフトが何であれ、出力する作業そのものは極めて簡単です。
1) 招待者名簿
RDBに記録されている招待候補者に関して「今年」の招待のyes/noがあり、yesとされている人々の一覧をエクセルとかPDFに出力するだけ。一瞬でできます。招待者名簿が事実として削除されていても、簡単に再作成できます。招待候補者のデータを削除するというほとんど全く考えられないことを内閣府がしていたとしても、リレーショナルデータベース管理システムは契約に従って、例えば毎日三回テーブルのデータを5つcopyして別々のハードディスクに自動的に保存しており、1000日前までの生データを復元するようなことができます(契約次第に)。云うまでもなく、削除したら自動的にどの computer から誰が削除したのかの履歴は残り、履歴そのものも複数 copy されて別々のハードディスクに保存されているはずです。
更にまた大切なことを強調します。内閣府の職員の中で選ばれた人のみがデータの入力とデータを選択・抽出してのエクセルとかPDFファイルへの出力だけに関してのみ権限が与えられているけども、テーブルのレコードを削除する権限が与えられている職員は極めて限られているはずなのです。まさかのことですが、削除権限の制限がないとしても、復旧することは簡単にできます。
2) 招待者への葉書(封書)の印刷
内閣府は「招待者名簿」の全員に葉書(封書?)を送るわけですが、葉書の印刷は「招待者名簿」という単一の(おそらくはPDFファイルまたはエクセル等)からするのではなく、専用ソフトあるいはマイクロソフトアクセス等に命じて、リレーショナルデータベースを読み込ませて、プリンターに印刷します。(エクセルのマクロで印刷することももちろんできます。)
でありますから、反社会勢力の山口氏への招待状の再印刷は簡単にできるわけです。
3) 集計データの出力
推薦者60とかの分類ごとの招待者数は、エクセルファイルやPDF文書として出力されたことでしょう。集計データは1/21でしたか、いやいやながら内閣府は公開しましたね。
-----------------------------------------------
/** 以下は旧文書における記載と、更なる補足ですので、理解できた方には
読むことを必ずしもお願いしません **/
▼桜を見る会について追及している野党議員等に呼びかけること
繰り返しが多くなりますが、冗長でないと理解が深まらないのであえて。
桜を見る会を追求する野党議員そしてマスコミの方々の恐らく誰1人として、RDB を管理・運用した経験がないために、「招待者名簿」が存在しなくても、生データ群はしっかりと RDB に保存されていることに思い至らなかったのでしょう。RDBについての知識を有する議員・報道者は幾人かいるでしょうけども、実際に管理・運用した経験なくしては、思いつくことは困難。ましてや、RDB についての知識が無く、データベースとして現実に管理しているのは年賀状ソフトくらいならば・・・・、申すまでもありません。私が1人以上の国会議員の秘書に、地元支援者などのリストを RDB で管理しているのかと尋ねたところ、そもそも RDB のことを知らないのでした。
RDB は年賀状ソフトとは異なる汎用のデータベースなので、管理・運用はプログラミングの知識と経験ないと不可能に近いです。必要なデータ項目の決定までは素人でも決めることができますが、諸項目をテーブルに振り分けること、テーブル毎のフィールド作成などなど、非常にややこしいです。作業は SQL という言語によりなされます。SQLを知らなくても、RDB 管理システム(RDBMS)でテーブル、フィールドの作成、そしてテーブルの関連付けはできますけども、国会議員とその秘書や報道人のほとんど全てにはできません。
以上、長々と解説してきました。その理由は、「招待者名簿」や集計データという公文書は RDB に蓄積された生データ群なくして、作成不可能ということを知って欲しいからです。
野党もマスコミも、「招待者名簿」は存在するのに隠しているんだろう、削除したとしても復元できないはずはない、公開しろ・復元しろと訴えるばかりで、事実の解明は遅々として進んでません。この状況を打破することができるのです。
「招待者名簿」がどのようにして作成されるのか? 簡単なことであります。RDB に記録されている生データ群(何千人もの人物リスト)の一つ一つには「2019年の招待」というyes/no項目があり、その項目にyesとチェックされているもののみを印刷するだけのことです。1/21に隠していたのが公開されました。それは集計データでしたが、それも同様にしてデータベースから抽出され、集計そのものはエクセルとかMS Access 等のソフトにより数値がはじき出されて、最終的に招待客者の内訳という公文書となったわけです。
繰り返しますが、膨大な生データ群(何千人もの人物リスト)をエクセルのごときセキュリティーゼロ(変更履歴の記録なし、復元機能なし、一度に一人しか操作できない)かつ低機能のソフトで管理することは、現代の政府機関ではありえません。政府機関はもとより、ほとんどの病院は電子カルテで患者データを管理しており、電子カルテの全データはリレーショナルデータベースに保存されます。
データの入力、保存、そして必要に応じての出力について、電子カルテを例に簡単に述べます。患者の個人データを RDB に入力する方法・ソフトは幾種類もあります(HOMEPAGE閲覧ソフト、マイクロソフトアクセス、専用ソフト等)が、データそのものはすべて RDB に保存されます。出力は個々の患者毎に、請求書とか明細書としてされますが、出力をするソフトウェアは入力と同様に、幾種類もあります。
例えば、ある病院では、入力も出力もPHPという言語を用いた web system で、リレーショナルデータベースはマイクロソフト SQL サーバー。別の病院では、富士通の電子カルテが採用されており、入力も出力も専用ソフトで、リレーショナルデータベースは PosgreSQL(これはフリーソフト)とか。
▼野党とマスコミへの提案
内閣府に対して、当然のことだねというニュアンスで確認を求めたり、強く要求することは以下の諸点です。
(※以下で、内閣府に対する質問としている理由は、管官房長官とか安倍総理は、RDB について全く知らない。だから、回答は官僚が忖度したものとなり中味が曖昧で、再質問しても意味不明の回答しか来ないであろうから。内閣府の責任者に質問すると、その責任者は RDB を用いていることを直接は知らないとしても、その部下はその運用に関与しているか、あるいは RDB のことを知っているから、虚偽の回答は困難である)
1. 内閣府は「招待"候補"者」の1人1人の情報を何という名前のソフトで入力しているのか? (※ マイクロソフトアクセス、webpage閲覧ソフト、専用ソフトなどであろう)
2. 個人データを何という名前のリレーショナルデータベース(RDB)に入力しているのか? (※RDBに入力しているのか、それともRDBではないエクセル等のソフトウェアに入力しているのかと尋ねてはいけない。ちなみに、RDBにはOracle、IBM、Amazon などの商用もあれば、PostgreSQL、MySQLなどフリーソフトもあるが、いずれにしても RDB の管理システムは民間企業により保守・管理されている蓋然性が極めて高い。内閣府がコスト削減のためにフリーソフトである PostgreSQLを採用し、なおかつ内閣府がその RDB を運用するためにデータベースエンジニアを直接雇用している蓋然性は小さい)
3. RDB に入力する諸項目に関してのテーブル振り分け、テーブルのフィールド項目決定、テーブル間のリレーション(関連付け)等は、内閣府の正規職員がしているのか、それとも民間企業に委託しているのか?
4. RDB に集積された生データは政府の建物内にあるサーバに保存されているのか、それとも外部に保存されているのか。政府施設の外部ならば、民間企業のサーバに保存されているのか。民間企業だとして、国内なのか国外なのか
5. 内閣府は「招待"候補"者」を RDB に入力し、最終的に「招待者名簿」を作成したのだね。
6. 内閣府は「招待"候補"者」を RDB に入力した後、1人1人について「招待者名簿」に載せるかどうかの yes/no の項目をcheckしたのか? それともcheckなしで一律に yes だったのか回答せよ。
7. 6に関連して、もしも1人1人についてcheckしてyes/noを決めたならば、審査基準についての公文書を公開せよ。公開しないならば法的理由を示せ
8. RDBから「招待者名簿」という公文書を出力したソフトウェアの名称を示せ
9. RDB に保存された「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータは公文書なのか否か。yes or no で法律の根拠を示して回答せよ
10a. 9に YES ならば、『「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータ』は削除してないのだね。もしも、削除ししているとしたら「招待者名簿」の削除と同様に違法だ。もしも生データの削除をしてて、違法でないと主張するならば法的根拠を明言せよ
10b. 9に NO ならば、つまり『「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータ』は公文書でないと主張するならば、公文書ではない根拠となる法令を示せ。
10c. 9に NO であり、『「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータ』を実際に削除したのか、yes or no で回答せよ
11. RDB に記録されている『「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータ』を毎年削除しているのか、yes or no で答えよ
12a. 11に YES だとする。RDBのデータは日常的に複数のcopyが取られ、データの削除履歴は残り、間違いによる削除とか、悪意による削除・改変があっても、復元できるのが RDB の管理システムの基本的な性質である。技術的に容易にできるのであるから、削除する前のデータを復元せよ。しないなら、しないことの法律による根拠を示せ
12b. 11に NO だとする。RDB に記録されている『「招待"候補"者」リスト、そして1人1人についての実際に招待するかどうかの yes/no 項目というデータ』は今でもあるのだから、招待者名簿を新たに作成して、公開しなさい。もしも公開しないとするならば、法律による根拠を言え。
---------------- 以上です。
↓↓は、1/22の version 1.0 に記した文章でありまして、↑↑に記したこととかなり重複しております。以下の文章については、補足とみなして下さい。どうもよくわからない時、あるいは理解を深めたいならば読んでくれたらと思います。
■基礎1: データベースとは
マイクロソフト、Oracle とかの民間企業が開発・運用しているリレーショナルデータベース管理システム(RDBMS)のこと。そのようなデータベースの"エンジン"には、PostreSQLとかMySQLなどのフリーソフトもある。商用のエンジンを採用しているのか、フリーのそれを採用しているのかにかかわらず、中央政府・自治体にはRDBMSを運用する能力がないので、運営する主体は民間企業である。データの入力という地道な作業は官僚 and/or 非正規の職員がしている。
■基礎2: データベースへのデータ入力、データベースからの出力について
情報を入力する手段は複数ある。マイクロソフトのアクセスとかエクセル、インターネットのブラウザと言われるhomepage閲覧ソフト、あるいは入力に特化したソフト。
大事なことは、個々のデータがデータベースの"エンジン"に保存されること。
出力は「桜を見る会の招待者名簿」とか招待者についての集計データとしてなされるのであるが、出力するのはデータベースの"エンジン"そのものにはできない。出力つまりは、「桜を見る会の招待者名簿」等の電子データ化は別のソフトウエアによる。データベースに保存された電子データなくして、「桜を見る会の招待者名簿」という電子データが作成されることはあり得ない。
■私の主張: 桜を見る会の「招待者名簿」の破棄への注目からデータベースに視点を移行すべき
「招待者名簿」というリストはデータベースの生データがあるからこそ、電子文書(PDFとかのカタチで)で作成されるのであり、電子文書を印刷したのが紙データであり、紙は確かに破棄された。電子データも削除されたとのことではあるが、電子データの復元を不可能にすることは技術的に困難ではあるができなくはない。実際に「招待者名簿」という電子データの復元が不可能にされた公算は低いが、奴らは復元しない。
しかし、「招待者名簿」というリストを作成するために絶対に必要なデータベースに記録された生データ群(個人情報群)が政府施設内のサーバー(ハードディスク)あるいは民間企業のサーバー(国内とは限らない)から完全に消去されている蓋然性はほんどゼロである。
★★要約というか、私が最も強調したいこと(繰り返しが多いですが)
1) 内閣府が個人情報(生データ)をデータベースに入力して、それを元にして「招待者名簿」及び集計データを作成したことは、99.99%確実であろう。
2)「招待者名簿」及び集計データはデータベースに集積されている生データ群からの"出力"に過ぎないのであり、野党とマスコミは印刷された"出力"にこだわりすぎてきたのであった。
3) 安倍内閣の誰1人として、生データが蓄積されたデータベースについての知識などないに違いない。だから、単なる出力に過ぎない紙あるいは電子データである「招待者名簿」が破棄されたことで安心しきっていると考えられる。
4) 内閣府の官僚の多くもデータベースについてよくわかってないであろうが、内閣府にはデータベースエンジニアが雇用されている公算が高く、その人物達は恐れているであろう。もしも、データベースエンジニアはすべて民間企業に雇用されており、内閣府の一員ではないとしても、恐れているであろう。
何を恐れるのか? 第一に悪事に荷担することをだ。あるいは痕跡なしで消去することは極めて困難であり、自分の能力を超えているので現実にはできそうもないと恐れているかも知れない。
彼/彼女らは知っている→ データベースに過去から昨年度までの全招待者"候補"及び現実に招待された全員の個人情報が記録されていること、さらには全データの消去を痕跡なしで実施することがほとんど不可能であることを。
もしも、今から、内閣府の上司から生データの全削除を痕跡なしで削除せよを命じられたとしたら、データベースエンジニアは苦境に陥る。云うまでも無く、極めて優秀なデータベースエンジニアであれば、消去の痕跡を残すこと無く消去することが絶対にできなくはないが、そのためにはデータベース管理者の権限が必要であり、内閣府の直接雇用のデータベースエンジニアであれ、民間企業から出向したエンジニアであれ、たまたまデータベース管理者の権限を有しているならば、痕跡なき消去はかろうじて可能かもしれない。しかし、データベース管理者の権限を有しているエンジニアであっても、毎日copyされている複数のバックアックを痕跡なしで、24時間以内とかの短時間に完全消去することは不可能。データベースというシステムは悪意あるいはミスによるデータ改変とかデータの消去を記録するように構築されており、悪意であれミスであれ、復元することがほとんど100%できるようになっている。
■内閣・内閣府官僚のこれまでの言明と非言明、そして野党議員の質問と非質問
・「招待者名簿」は破棄した
→ 事実だとしてもデータベースから簡単に再作成できる
・野党もマスコミも生(元)データを破棄したのかとは質問してないし、そのことを示唆するような言明はなかった。
■野党が質問するべき諸点(Q)と要求すべき諸点(R: request)
Q0: 政府や地方自治体は国民の名前や住所などの莫大な個人情報をデータベースに入力して管理しているのだね ※これにはYESの回答しかあり得ない
Q1: 何千にも上る招待者の生データ(個人情報)はデータベースに入力しているのだね?
まさか、ワードとかエクセルで管理してないね?
▼Q1に対してデータベースに入力していると回答した場合
Q2. 「招待者名簿(リスト)」および集計データはデータベースにある生データから作成しているのだね? (これにはYESの回答しかあり得ない)
Q3. 「招待者名簿(リスト)」は破棄したというが、まさかデータベースから毎年生データを全て破棄してはいないね?
▼生データの"全ては"破棄はしてないと回答するなら
Q4. 政府機関・閣僚・自民党議員事務所等から送られてくる招待候補者リストをデータベースと照合して、データベースにない人物については追加したり、データベースにあるものの住所変更がされているような場合は修正しているのだね?
※これには YES としか回答しようが無い。
Q5a. データベースに入力された招待候補者の1人1人について、実際に招待状を送るか否かを決める最終決裁者は誰なのか? 総理大臣なのか?
Q5b. 最終決裁者に対して、招待状リストの"案を"提出する責任者は誰なのか?
Q5c. 最終決裁者に対して、招待状リストの"案"を紙に印刷して提出しているのか、それとも電子データで示しているのか?
Q5d. 最終決裁者は何千人もの招待状リストの案を現実に見ているのか?
Q5e. 最終決裁者はある特定の人物はリストから外すようなことをしたことが過去にあったのか?
Q5f. 最終決裁者は慣行的に一括して承認してきたのではないか?
Q5g. そもそも、データベースに入力された招待候補者の1人1人について、実際に招待状を送るか否かの審査をする基準はどうなっているのか?
R1. 審査基準を口頭で述べよ、さらにまた審査基準を根拠付ける文書を提出せよ
R2. 手続きのルールを記載した文書を公開せよ。もしも手続きを記した文書あるのに公開しないなら法令の根拠を示せ。
Q6. データベースと照合して、データベースにない人物については追加したり、データベースにあるものの住所変更がされているような場合は修正しているのだね?
Q7. データベースには、1人1人の招待履歴も記録されているね?
R1a-招待履歴が記されていると回答したら: 2013年度～2018年度の生データはあるのだから、「招待者名簿(リスト)」を再作成して提示しなさい。
R1b-招待履歴は記されてないと回答したら: 2018年度の生データはあるのだから、「招待者名簿(リスト)」を再作成して提示しなさい。
国・社会に貢献したことが理由で桜を見る会に招待されたのであるから、人物の名前と肩書を公開することはいかなる法令にも違反しない。そもそも招待者されたことはその人にとって名誉であり、当該人物の承諾なく公開することはプライバシーの侵害には全くあたらない。
ただし、当該人物が特別に名前の公開をしないように求めたケースにては、非公開とすることが直ちに法令に違反するとは断言できない。しかし、非公開を求めたとしても公費により参加したのであるから、非公開を求めるような人物に関しては、招待を取り消すのが相応であろう。
▼生データは毎年破棄していると回答するなら
Q8. 政府機関・閣僚・自民党議員事務所等から送られてくる何千人の招待候補者リストを本当に新たにデータベースに入力しているのか?
R4. 新たにデータベースに入力している証拠あるいは証言を公開せよ
R5. 全ての生データを消去した証拠となる電子記録を示せ。消去した記録はデータベースに必ず残る。もしも、消去した記録がないとしたら、意図的に消去した履歴を消したことが確実となる。
R4. データベースの生データは複数のcopyが取られるから、復元は容易にできるので、復元せよ。
この記事が気に入ったらサポートをしてみませんか？