ページの先頭です。 メニューを飛ばして本文へ
現在地 トップページ > 分類でさがす > 市政情報 > 計画・審議会 > 審議会 > 行財政運営 > 高槻市個人情報保護運営審議会 > 令和3年度第2回高槻市個人情報保護運営審議会会議録を公表

本文

令和3年度第2回高槻市個人情報保護運営審議会会議録を公表

ページID:001485 更新日:2022年3月22日更新 印刷ページ表示

日時

令和3年6月14日(月曜日)

午前10時00分から午前11時15分まで

場所

高槻市総合センター6階 C604会議室 (インターネットWeb会議)

事務局

法務ガバナンス室

傍聴者数

0人

出席委員

片桐会長、山崎委員、大山委員、高橋委員、井上委員、久末委員、小阪委員

会議の議題

  1. 審議会に係る実施方法
    インターネットWeb会議の実施について
  2. 答申書の確認
    職員採用管理システム「Be‐Smart」の導入について
    [担当課:総務部 人事企画室]
  3. 新規諮問事項
    高槻市個人番号カード予約・管理システムの導入について
    [担当課:市民生活環境部 市民課]
  4. 報告事項
    高槻市個人情報保護運営審議会で承認された類型に基づく個人情報の目的外利用について(令和2年度)
    [担当課:総務部 法務ガバナンス室]
  5. その他

審議等の内容

1 審議会に係る実施方法

インターネットWeb会議の実施について

新型コロナウイルス感染症の感染状況を踏まえて、本日の審議会の開催方法として、インターネットWeb会議での開催とすることを会長から出席委員に確認がなされた後、了承された。

2 答申書の確認

職員採用管理システム「Be-Smart」の導入について

前回、実施機関(総務部 人事企画室)から諮問のあった案件について、事務局から審議結果を踏まえた答申案が提案され、承認された。

3 新規諮問事項

高槻市個人番号カード予約・管理システムの導入について

実施機関(市民生活環境部 市民課)から出席職員の紹介があった後、次の説明がなされた。

実施機関:本日は、市民課の高槻市個人番号カード予約・管理システム(以下「本システム」という。)に関する業務が、高槻市個人情報保護条例(以下「条例」という。)に規定する諮問事項に該当するため、審議をお願いする。

本事業はマイナンバーカード(以下「カード」という。)交付事業に係るものである。本システムは、政府方針に基づき、令和4年度中にはほとんどの市民がカードを保有できるよう、今後より一層の交付促進を図っていく上で、事務の正確性、安全性及び効率性を向上させようとするもので、導入に当たり、本日諮問するものである。


まず、諮問書に沿って概要を説明する。諮問件名は「高槻市個人番号カード予約・管理システムの導入について」、業務名は「個人番号カード交付関連事務」、諮問課は「市民生活環境部市民課」、結合先関係機関は「株式会社TKCデータセンター」である。

電算処理及び電算結合に係る個人情報の種類については、別紙1のとおりとなっており、3つの分類に分けて掲載している。詳細については、記載のとおりになるが、カード製造管理番号、カード申請者の氏名、生年月日等、カードを管理するに当たり必要となるカード申請者の個人情報となっている。なお、本システムで管理する個人情報には、マイナンバーは含まれていない。

諮問資料(以下「資料」という。)の1ページ目に戻っていただき、目的・理由についてであるが、市民課では、「行政手続における特定の個人を識別するための番号の利用等に関する法律」に基づき、カードに係る交付関連事務を行っている。令和3年3月末時点の本市におけるカード保有者の割合は、全市民約35万人の約33%であるが、政府方針に基づき、令和4年度にはほとんどの市民がカードを保有できるよう、今後、より一層の交付促進を図っていく必要がある。

このような状況の中、現在本市では、カードに係る申請情報等を申請方法別に複数の表計算ソフトで管理しているため、交付日や発送日などの複数の情報を手作業で何度も入力する必要があること、情報を分散管理しているためにカードの交付現況を効率的に管理できないこと、窓口の混雑緩和を目的に導入した予約制に係る情報管理が煩雑であること、管理すべき情報が日々増加し、10万件を超えるほど膨大になっていることが課題となっている。

そこで、本システムとして、TKCデータセンターが提供するクラウド型のLGWAN‐ASPサービスと新たに調達する端末をLGWAN回線で結合し、予約管理、申請者情報管理、カード交付・発送管理等を同システム内で一元的に処理することにより、事務の正確性、安全性及び効率性を向上させようとすることから、条例第12条の規定による新たな電算処理に関する事項及び条例第12条の2第1項の規定による電子計算組織の結合に関する事項として高槻市個人情報保護運営審議会に諮問するものである。

続いて、処理概要について、別紙2‐1を御覧いただきたい。カード交付業務の現状等について説明する。現在、カードの取得方法は2つある。1つ目は申請時来庁方式というもので、カードを申請する際に本市の窓口にお越しいただき、本人確認等所定の手続を行うことで、後日郵送されるカードを自宅にて受け取るという方法である。

大まかな流れとしては、最初に、市民が本市ホームページから簡易電子申込サービスを使用して、来庁予約をする。

次に、本市が窓口で市民の本人確認や顔写真撮影などを行い、専用タブレットまたは手書きの申請書で受付をする。その後、受付時のデータまたは申請書原本をカード発行機関である「地方公共団体情報システム機構(以下「J‐LIS」という。)」へ送付する。

次に、J‐LISの方で本市からの申請データを基にカードとカード発行一覧と呼ばれる、申請書ID、カード製造管理番号、カード発行者氏名、住所、性別及びそれらを読み込むためのQRコードが記載された一覧表を作成し、まとめて本市へ送付する。

本市はJ‐LISから送付されてきたカードについて、カード発行一覧を用いて表計算ソフトに申請書ID、カード製造管理番号及びカード発行者氏名を入力する。その後、統合端末でカードの初期設定を行い、窓口で市民から預かった暗証番号記載票を基に、本市が代理で暗証番号を入力してカードを使用できる状態にする。最後に、カードを市民の住民票の住所地へ簡易書留で送付し、市民が自宅でカードを受け取って完了となる。

2つ目は、交付時来庁方式というもので、郵送またはインターネットで市民が申請手続を行い、後日、本市の窓口へ来ていただき、本人確認の後、カードを手渡しで受け取る方法である。

大まかな流れとしては、最初に、市民自身がカードの交付申請書を使用して郵送またはインターネットで申請を行う。

J‐LISとのやり取りは申請時来庁方式と同様であるが、統合端末でカードの初期設定を行った後、交付時来庁方式では、市民へカードの交付時に必要な交付通知書と受付窓口の予約に必要な書類を送付する。

書類を受け取った市民は専用サイトまたは電話にてカード交付窓口を予約する。

予約日に、市民は本市の窓口にて本人確認を受け、市民自身で統合端末にて暗証番号の設定を行い、カードを手渡しで受け取る。

以上が2つのカード取得方法である。

データ管理の面では、このように人によってカード申請方法やカードの設定作業が異なるため、予約者名簿やカード管理簿、発送リストについては申請方法別にデータで管理を行っている。

また、カード交付に至らず、申請取消を行った方の一覧表などのデータも管理している。

今後、カードの普及促進に伴い、これらのデータは増加する一方になるため、複数のデータを使用することによる検索性、破損などの危険性及び効率性に課題を感じている。

本システムの導入によって、申請者情報からカードの受入状況まで、予約情報からカードの交付状況までを一元化してデータ管理を行えるようになる。

続いて、別紙2‐2を御覧いただきたい。

こちらは導入しようとする本システムの全体概要図となっている。

まず、市民側から申請・交付予約を行う通信であるが、インターネット通信でインターネットWebサーバへアクセスする。

この際、表の下にある1ネットワークセキュリティ対策に記載のとおり、不正侵入防止システム(以下「IPS」という。)及びファイアウォールを経由することで、不正な通信をブロックする。

また、インターネットからのIPリーチャビリティ(到達範囲)についてはインターネット側Webサーバまでとしており、データベースへのアクセスは不可となっている。

次に、本市及びカードの申請や交付窓口を委託している委託業者側が予約情報の照会やカード管理情報を入力する場合などの通信であるが、LGWAN回線を用いた通信を行い、ファイアウォールを経由して、LGWAN側Webサーバへアクセスする。

また、LGWAN側Webサーバからデータベースサーバ(以下「DBサーバ」という。)への通信については、2LGWAN側Webサーバの配置に記載のとおり、インターネット通信とは異なるセッションでLGWAN側Webサーバからアクセスし、ファイアウォールを経由することで不正な通信をブロックする。

次に、市民側からのインターネット側WebサーバからDBサーバへの通信については、3に記載のとおり、インターネット側Webサーバ自体に個人情報は保有しないが、個人情報以外の情報の通信の際はHTTPSによる暗号化通信を行う。

最後に、DBサーバについてはウイルスチェックサーバとメール送信サーバのある共通サーバ群に設置されており、本市及び委託業者側からファイルをDBサーバにアップロードする際は、4に記載のとおり、ウイルスチェックサーバで確認後に処理を行う。

続いて、別紙2‐3を御覧いただきたい。

こちらは申請時来庁方式の処理概要である。

最初に、市民が本市ホームページから本システムの専用Webページへアクセスして、カードの申請予約または変更を行い、インターネットWebサーバを経由してDBサーバにて予約情報の管理を行う。本市及び委託業者は翌日の申請受付準備のため、LGWAN側Webサーバにて、予約情報の照会や、予約枠の設定を行う。予約者の申請受付後は、本市及び委託業者は予約状況を基に、受付した申請者情報を登録し、システムで申請者情報の管理を行う。

次に、カード発行機関であるJ‐LISから本市へカード及びカード発行一覧の送付があった後、本市及び委託業者でQRコードリーダを使い、カード発行一覧のQRコードからカード申請者の氏名などのカード情報を読み取り、DBサーバへアップロードする。また、カードの初期設定や代理での暗証番号設定を行う中で、カード発送までの進捗情報を登録し、システムで情報を管理する。

最後に、本市から市民へカードを送付した後、市民からカード発送状況等の問合せがあった際は、本市及び委託業者はシステムのDBサーバにある情報を照会する。

また、発送したカードについて、本市及び委託業者は発送日などの情報をシステムに登録する。

図に記載のとおり、本システムを導入してカード申請・交付等の情報を処理及び管理することが、条例第12条の規定による新たな電算処理に関する事項の諮問対象となり、本システムと本市または委託業者の間のLGWAN接続について、条例第12条の2第1項の規定による電子計算組織の結合に関する事項の諮問対象となる。

続いて、別紙2‐4を御覧いただきたい。

こちらは交付時来庁方式の処理概要である。

最初に、本システムを介さない部分になるが、市民がカードの交付申請書を使用して郵送またはインターネットで申請を行う。

次に、カード発行機関であるJ‐LISから本市へカード及びカード発行一覧の送付があった後、本市及び委託業者でQRコードリーダを使い、カード発行一覧のQRコードからカード申請者の氏名などのカード情報を読み取り、DBサーバへアップロードする。また、カードの初期設定を行う中で、交付通知書及び交付予約関連書類の発送までの進捗情報を登録し、本システムで情報を管理する。

本市から市民へ交付通知書及び交付予約関連書類を発送した後、市民が交付予約関連書類から本システムの専用Webページへアクセスして、カードの交付予約または変更を行い、インターネットWebサーバを経由してDBサーバにて予約情報の管理を行う。本市及び委託業者は翌日の交付受付準備のため、LGWAN側Webサーバにて、予約情報の照会や、予約枠の設定を行う。

最後に、市民から本市へカードの交付準備状況等の問合せがあった際は、本市及び委託業者は本システムのDBサーバにある情報を照会する。

また、市民が本市の窓口でカードを受け取った後、本市及び委託業者はカード交付日などの情報を本システムに登録する。

諮問範囲については、別紙2‐2の図の記載の範囲となる。処理概要については、以上である。

最後に、別紙3の保護措置についてである。「1 システム面」について説明する。

(1)使用機器及び制限については、使用機器は、パソコン端末(5台)、プリンタ、QRコードリーダ及び外部記録媒体とする。

外部記録媒体への記録は、原則として禁止し、業務上やむを得ず記録する必要がある場合は、管理責任者である市民課長の許可を得て行う。なお、外部へ持ち出す場合等は、必要に応じて暗号化等の措置を講じる。

(2)ネットワークについては、本市または委託業者である管理者側とデータセンターとの通信は、LGWAN接続とする。また、市民側とデータセンターとの通信は、インターネット接続とする。ただし、インターネットによる通信は、インターネット側Webサーバで受信し、DBサーバへの通信は、IPS及びファイアウォールを経由して不正な通信をブロックできるようにする。

(3)アクセス制限については、ユーザーID・パスワードで本システムを操作することができる者を限定するとともに、担当業務以外へのアクセスを制限する。また、本システム専用のパソコン端末にログインする際にはユーザーID・パスワード及びICカードによる二要素認証を必須としている。

(4)操作履歴については、操作者ごとのログを取得し管理する。

(5)ウイルス対策としては、ウイルス対策ソフトを使用する。

(6)使用機器等の保管については、パソコン端末及び入出力した帳票類は、施錠可能な保管庫に保管し、パソコン端末を使用する際は、セキュリティワイヤー等による固定を行う。

(7)情報の保存及び廃棄については、本システムで取り扱う情報及び入出力した帳票類は、法令等の規定に基づき保存し、保存期間満了後、直ちに消去及び廃棄する。また、外部記録媒体内の情報は、目的達成後、直ちに消去する。

(8)データセンターについて、本システムで運用するデータセンターでは、次のとおりセキュリティ対策が実施される。

  1. データセンターへの入退室は、ICカードや生体認証等により入退室者を識別できるセキュリティ設備を有する。また、施設周辺及び施設内はカメラで監視を行う。
  2. 脆弱性に関する情報を定期的に収集し、必要によりパッチ適用等の対策を講ずる。
  3. DBサーバとインターネット側Webサーバの間にファイアウォールを設置する。
  4. IPSを設置することで外部及び内部からの不正侵入や攻撃を検知する。
  5. 管理者側でアップロードしたCSVファイルは、ウイルスチェックサーバで感染の有無について確認した上で、処理を実行する。
  6. インターネット側Webサーバでは個人情報を保有しない。
  7. J‐LISが示す「総合行政ネットワークASPガイドライン」に準拠しており、インターネットからのIPリーチャビリティはインターネット側のWebサーバまでとし、LGWAN環境に到達しないようする。

続いて、「2 制度面」について説明する。

  1. 条例及び「高槻市個人情報保護条例施行規則」並びに「高槻市情報セキュリティポリシー」を遵守する。
  2. 「高槻市個人番号カード予約・管理システムの管理及び運営に関する要綱」を作成し、遵守する。

要綱案については、資料9ページを御覧いただきたい。

まず、第1条で本システムの趣旨、第2条から第4条までで本システムの管理責任者を市民課長とすることや、管理責任者の役割、操作者の責務を定めている。

第5条では本システムの利用の範囲、第6条から第8条まででは、先ほど説明した保護措置の内容について記載しており、第9条で本システムの稼働時間を定めている。

保護措置については以上である。

以上で、案件の説明を終了させていただく。

以上の説明の後、次の質疑がなされた。

委員:保護措置の1の(3)のアクセス制限で、資料に記載はないが、先ほどICカードという言及がなされたと思うが、(8)の1にもICカードが記載されているが、要綱(案)の第3条第3号では「操作者に対して、ユーザーID及びパスワードを発行すること。」でICカードの言及がないので、ICカード、ユーザーID及びパスワードの関係を説明願いたい。

実施機関:ICカードをセットして使用端末を起動させ、本システムにログインする際にユーザーID及びパスワードを使用する2要素の認証となっている。

委員:先ほどの保護措置の1の(3)のアクセス制限のところで、ICカードの記載がこのままなくても良いのか。

事務局:仰るとおり実態はICカードを使用するということであるので、答申書作成の際に、具体的に記載させていただこうと考えるがどうか。

委員:今の説明だと使用端末へのアクセスの話であるので、保護措置の1の(1)に追記するイメージか。

事務局:そのとおりである。

委員:そのあたりを精査して答申書に記載していただきたい。その他に御意見はないか。

委員:少し大きな話として、申請時来庁方式を利用することのメリットということになるが、今回の処理概要を拝見すると、申請時来庁方式はデータのやり取り、行ったり来たりが交付時来庁方式に比べるとかなり多い印象を受けた。そうすることで、様々なリスクが増えると考える。ただ、申請時来庁方式を採用する意味はあると思うのでそれを伺いたい。

現状だと高槻市役所に来て申込みをするということであろうから、例えばショッピングセンターなど市民がアクセスしやすい場所で受付することを予約するわけでもないように思われる。要するに、カードを受け取るときか、申請するときか、いずれにしても高槻市役所の開庁時間に来る必要があることは、申請時来庁方式も交付時来庁方式も同じである。その上で、申請時来庁方式を維持すると、そのデータの行き来が複雑になるということであれば、本システムの導入の関係ではメリット及びデメリットを考量する意味があるのかなと…。現実問題として、一度採用した申請時来庁方式を止めるということはできないと思うので、止めろという趣旨ではないが、今回の本システムとの導入との関係でなお申請時来庁方式を維持することのメリット・意義を聞きたい。

実施機関:申請時来庁方式と交付時来庁方式と2方式があるが、元々は交付時来庁方式だけで実施していた。そこに申請時来庁方式を加えた理由としては、先ほど言及いただいたが、前提として申請時か交付時かどちらかに来庁いただき、本人確認、顔写真と本人との見比べをさせていただくことになるが、申請時来庁方式は高槻市役所と出張先であるショッピングセンター等の両方で受付ができる。つまり、申請時来庁方式は、来庁いただくか、ショッピングセンター等の申請会場に来ていただき、そこで本人確認等を済ませれば、後はカードが自宅に送付されるという形になっており、より手軽にカードの申請・入手をしていただけるように取り入れている方式になる。しかし、交付時来庁方式だとショッピングセンター等の出張先でカードを交付することは管理上できない(カードの交付は必ず市役所で行う。)ため、市民の申請の利便性等を勘案して、申請時来庁方式を取り入れた。

委員:要するに、申請時来庁方式には、交付時来庁方式にはない非常に大きなメリット、市民のアクセス・利便性を高めるといった点があり、今回本システム導入後も維持する必要があるということか。

実施機関:そのとおりである。

委員:分かった。

委員:今の質問の関係で私からいくつか質問してもよろしいか。

実施機関:はい。

委員:申請時来庁方式があるのはよく分かるところであるが、結局のところ高槻市としてすべき仕事は、本人確認をして市民にカードを交付する意思決定をするということが、核心の業務であるということか。

実施機関:はい。

委員:ただ、J‐LISに郵送し申し込んんで、認証をしてカードを交付するという方法だと、J‐LISに申し込むところがハードルになっており、普及率が上がらないと。また、J‐LISへの申込みの方が使い勝手が悪いにもかかわらず、国から普及率を上げろという指令が来ていることから、J‐LISを介して、あるいはJ‐LISがやるべき処理を代行して高槻市がすることになっている。それをするが故に、本システムのような不思議なシステムを作らざるを得ないようになっていて、その処理を表計算ソフトを使用して手入力で処理していることが限界であるから、外注したいということか。

実施機関:そうである。煩雑になってきている。

委員:基本的な現場作業は委託していて、高槻市が自らの仕事としては処理していないのであるなら、これを高槻市で処理する意味がないのではないか。

実施機関:全ての業務を委託できているわけではなく、国が定めた範囲の業務を委託している

委員:それは重々承知している。申し上げたいのは、J‐LISがきちんと処理すれば、QRコードからの登録作業など不要ではないか。J‐LISがそのような業務を一貫してするシステムを作って処理すれば、高槻市がQRコードから登録する必要はなく、J‐LISから送られたデータを一括承認すれば良いような話ではないか。なぜ、QRコードを読み取って、データベースに上げる作業が必要なのか。その部分は、当審議会で処理してはいけないとは言っていないし、当審議会の所掌ではないとも思えるわけで、このようなことに高槻市のお金を使って本システムを作らせようとすること自体に、国に声を上げるべきだろう。

他の委員が本システムに疑問を感じるのも理解できる。動かないレガシーシステムの上に、利便性を高めようとして情報を載せた上で、業務を請け負う業者がパッチを当ててくれていて、なんとか高槻市で法令上の対策をするということを行っているから、このような状況になる。

もう一点、諮問案件とは関係ない今後の話になるが、このようなことを続けていれば、国でシステムを作ったから、伸るか反るかしてくださいというようになるのではないか。そうならないとまずいと思う。そのときに、高槻市としてどうするのかという話である。カード交付関連事務のコントロールも上手くなるし、制度を考える仕事もなくなったときに、何をすべきかということがあると思う。その意味で、今後そのようなことが増えるだろうと思う中で、別紙2‐3だが、高槻市として考えなければならないのは、市民から見たときの利便性だと思う。つまり、国のシステムや本システムのようなものが増加してきたときに、安全であるかと同時に、便利であるかということが市民の非常に大きな関心だと思う。

これで、結局なぜ来庁しないといけないかというと、本人確認しなければならないということであるから、申請時か交付時に一度は受付に来てくださいということは動かせないとしても、例えば予約申込の変更、申請予約、申請の手続などがとにかく使いやすいものであってほしい。こういうことが重要であると考える。

昨年の定額給付金の申込みやGotoトラベル事業の還付金の申請を見ていて愕然(がくぜん)としたが、これも全て表計算ソフトで作成せよと国は言う。だが、やはり皆さんスマートフォンでフォームに簡単に入力していきたいわけである。ネットで表計算ソフトに入力しろ、酷(ひど)い場合は表計算ソフトにできた書式に入力しろ、それが面倒であればPDFで出すから手書きしてスキャンして作成しろという感じである。それは結局、行政側の書式の都合であって、市民の都合ではない。便利なツールがあるのだから、データを入力すれば書式は自動生成されることなども考えられる。そのため、どうしても書式が必要であれば、市民に手間をかけるのではなくて、自動生成するように、そこにコストをかけて欲しいし、入力するポータルの段階、入口の段階で分かりやすくあってほしいと思う。そういう観点から、今回の予定されているユーザーアクセス、ユーザーのインターフェイスがどういう仕様になっているか分からないし、今後そのようなものも資料として添付していただきたい。今回は良いが、市民向けの窓口サービスに係るものは特に添付をお願いしたい。

事務局:事務局と実施機関とで事前に諮問資料を検討する際に、今後同じようなものにつきましては、市民から見てどのように見えるのか、どのようにアクセス、入力するのかという点も重視した資料作りに努めたいと思う。

委員:お願いする。それと同じことは行政職員の皆さんにも言えると思う。要するに、これだけよく分からないシステムが、雨後の筍のように出てくるとどこに何があるのか、何を入力したら良いのか分からなくなってきているのではないか。そうすると、操作ミスも増えるだろうし、仕事をする上でのストレスになると思う。そのため、表計算ソフトで自由度の高い書式を自ら作らせるようにしてほしいということになると思う。そういう意味では、高槻市が操作する側のインターフェイスを確認したい。予定される画面のワンショットでも良いから、見せてほしい。今、株式会社TKCのホームページを見て、どのようなシステムか確認したが、ユーザーインターフェイスの部分が全然分からない。そのため、今後その部分は気をつけていただきたい。私からは以上である。

実施機関:国またはJ‐LISには、本市の視点から言えることは言っていきたいと思う。また、市民の利便についても、今回はユーザーインターフェイスと高槻市側の操作画面を示せていないが、分かりやすく使いやすいようにという、市民に向けてのところは特に心掛けていきたい。

委員:他に御意見はないか。

(意見なし)

委員:それでは、委員からの意見も踏まえて適切な取扱いに努めていただきたい。

以上の質疑の後、本件は承認された。

4 報告事項

高槻市個人情報保護運営審議会で承認された類型に基づく個人情報の目的外利用について(令和2年度)

平成15年10月7日付け高個議第14号答申において承認された類型に基づく目的外利用について、事務局から報告があった後、次の質疑がなされた。

委員:今年は類型3から5までの件数が0件であるのは、理由があるのか。

事務局:例年、特にこれらの税情報に係る部分については、類型化はされているが、類型の中で最終的には本人の同意を取ることという条件が設定されており、地方税法上の守秘義務との関係で、当時の審議会の判断として答申で守秘義務を解除することまでは難しいという判断であったと思う。その加減で、類型化されているが、実務上使用しにくい部分があるのでこのようになっていると思われる。

委員:類型を使用しないのであれば、類型から外しても良いかもしれない。検討いただけないか。

事務局:はい。

委員:これだけ、類型の使用実績がないということは、それを使用するときは突発的な特別な理由があるということになるだろう。それを自己コントロールで良いのか、審議会に事前にかけるべきかというのは、審議会がチェックする仕組みがいつまで残るのか分からないが、検討いただきたい。その上で、他に御意見はないか。

委員:新型コロナウイルス感染症関係の目的外利用が増えたという説明があったが、表を見る限り分からない。私たちは分かるが、それを記載しない方が良いのか。どこの類型に当たるのか分からないので、「感染症」と累計で例示に入れたり、個別の理由のところに書くのは難しいのか。

委員:確かに、項番37番などは違うということは分かる。

事務局:一見して分かるようにはなっていない。業務名のところで御確認いただくしかない状況であるが、紹介した項番3番のほかにも、24番、25番、26番、27番及び42番については、新型コロナウイルス感染症関係で目的外利用した事案である。

委員:私たちは良いが、この運用実績が外に公表されたときに、令和2年度だけ目的外利用が増えて何かあったのではないかと疑念を抱かれるのではないかと懸念がある。

委員:他に御意見は無いか。

委員:項番7番と8番がいわゆる社会調査のために住民基本台帳を確立するというものが含まれている。そういったことはあるのではないかと思うが、この2件しかないというのは不思議に感じる。社会調査を行う上で、住民基本台帳を使用するのは常套手段であるが、報告書に上がる前にスクリーニングがかかっているのかということを聞きたい。2件だけしか来なくて報告に上がっているということであればよく分かる。スクリーニングがかかっていて住民基本台帳を見せないという判断が別にされているのであれば、どのような手続かを参考までに聞きたい。

事務局:本市では、毎年度全庁に対して、類型に基づいた目的外利用をした場合は必ず報告するよう照会をかけた上で取りまとめている。仰られるとおり、昨年度については2件の報告となっているが、年度によっては今年度より多い場合もあるため、本市による主体的な調査としては市民生活相談課が行うが、それ以外のいわゆる大学連携のものなどの運用については、大学側の事業展開のタイミングによって多かったり少なかったりする場合がある。例えば、「このレベルの調査であれば報告は不要」とするような事前の捌(さば)きは特段ないため、目的外利用に当たるものについては全て報告が上がってくるようになっている。

委員:その点は、そのようになっていると思っている。ここでは分からないことかもしれないが、住民基本台帳を見せてほしいという申請が事前に弾かれているということがあって、結果的に2件だけこの報告書に上がってきているのかを聞きたい。要するに、調査したいので住民基本台帳を見せてほしいという申請は結構沢山、高槻市に届いているのではないかと思う。

委員:類型8に関わる部分だが、まず調査目的が市政に反映させるものでなければならならず、また、実施主体が高槻市でなければならない。調査、研究のために高槻市が調査を行うときに、住民基本台帳を見せるとなると、やはり目的外利用になり、手続が必要となると思う。その点については除外していないと思う。なので、高槻市と共催・合同で行う場合だと、この類型8に引っかかるかもしれない。

そうすると、利用する側としては少し(条件が)厳しくなってくる可能性が考えられる。

委員:分かった。

委員:私から一点確認したい。新型コロナウイルス感染症により、目的外利用が増加すると思っていたが、意外に報告書記載の件数(57件)だけなのか。令和2年度中ということもあるのか、例えば「〇〇給付金」がありますということを積極的に連絡しても良い気がするが、意外とそうでもないのか。個人情報の利活用について、この類型以外のものは、事前に諮問をかけなければならないと認識されていて、そこの部分にハードルがあって、プッシュ型の支援にたどり着いていないということであれば、それは問題だという意識がある。

事務局:本市または国由来の施策で、特に新型コロナウイルス感染症関連については、その施策を実現する方向で動いている中で、個人情報の関係で施策そのものを止めるということは、通常担当課の判断だけではされない。担当課は、個人情報が壁となる場合は、必ず法務ガバナンス室まで相談に来ているところである。その実数が、この報告書にリンクしてきているため、プッシュ型の支援をするに当たって、個人情報が壁で実質的に施策を止めているということはないと思われる。

委員:この手の手続は全国的にもしっかりとした手続が行われていて、「重い」ものである。重いと考えると、その部分とは別のところでリソースを投下して、集中させて施策を進めようとする考えはあると思う。要するに、個人情報の利活用であればコンサルティングも必要になるし、場合によっては諮問も必要になるし…それは分かると。それだったら個人情報を使わない方が早いし、コスト的に楽になると考えることがあるのではないか。しばらく、ワクチンのこともあるだろうから、必要なセキュリティを守りながらも、行政としてこの手続が重いというだけで、ハードルになることは不本意であるので、やりたいことがあれば言ってほしいというポーズをとっていただければ有難い。

事務局:はい。

委員:他に御意見はないか。

(意見なし)

委員:それでは、この報告については終了する。

以上の質疑の後、本件は了承された。

5 その他

次回の日程及び本日の諮問事案に係る答申書の取扱いについて

次回審議会(令和3年度第3回審議会)については、現時点では開催の予定がないため、後日日程調整を行うこととなった。

 

Adobe Reader<外部リンク>
PDF形式のファイルをご覧いただく場合には、Adobe社が提供するAdobe Readerが必要です。
Adobe Readerをお持ちでない方は、バナーのリンク先からダウンロードしてください。(無料)