JP2016115345A - 個人情報収集システム、個人情報収集方法および個人情報収集プログラム - Google Patents

Abstract

【課題】業務ボリュームに応じた処理能力のシステム構成を適切なコストで実現する。【解決手段】個人情報の収集業務の作業データを要求に応じて蓄積し、要求に応じて蓄積された作業データを提供する、クラウド環境上に構築されるシステムであって、前記収集業務を行う拠点毎に設けられ、対応する拠点にアクセスが制限される拠点単位サーバ群と、前記拠点単位サーバ群の蓄積データが集約されるデータ蓄積サーバ群とを備える。【選択図】図２

Description

本発明は、個人情報収集システム、個人情報収集方法および個人情報収集プログラムに関する。

大量の個人情報を収集する業務にあっては、業務の円滑な遂行を支援するため、基幹となるシステムの処理能力が十分なものであることが要求され、処理要求に対して高速にレスポンスが行われることが望まれる。

日本では、昨今、個人番号制度（通称「マイナンバー制度」）が法整備化され、個人情報である「マイナンバー」を大量に収集する業務の発生が予想されることから、対応が急がれている。なお、「マイナンバー制度」とは、複数の機関に存在する個人の情報を同一人の情報であるということの確認を行うための社会基盤（インフラ）であり、「社会保障・税制度の効率性・透明性の確保」と「国民にとって利便性の高い公平・公正な社会の実現」に向けて、国民全員に一意の個人番号を割り当てる制度である。

一方、特許文献１には、ロードバランシングによりオンラインゲームを効率的に実施する技術が開示されている。

上述したロードバランシングの手法は、実装された装置の能力を最適化する上では有効であるが、順次に業務ボリューム（業務量）が変化（主に減少）していく環境に対して処理能力を適切に維持することはできない。

また、業務ボリュームに応じてシステム構成を縮小していくことも考えられるが、システムのリソースを全て購入して自前で用意する場合、不必要になったリソースが無駄となり、コストの最適化を図ることができない。

本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、業務ボリュームに応じた処理能力のシステム構成を適切なコストで実現することにある。

上記の課題を解決するため、本発明にあっては、個人情報の収集業務の作業データを要求に応じて蓄積し、要求に応じて蓄積された作業データを提供する、クラウド環境上に構築されるシステムであって、前記収集業務を行う拠点毎に設けられ、対応する拠点にアクセスが制限される拠点単位サーバ群と、前記拠点単位サーバ群の蓄積データが集約されるデータ蓄積サーバ群とを備える。

本発明にあっては、業務ボリュームに応じた処理能力のシステム構成を適切なコストで実現することができる。

本発明の一実施形態にかかるシステムの構成例を示す図である。 受付システムの構成例を示す図である。 端末装置等のハードウェア構成例を示す図である。 複合機のハードウェア構成例を示す図である。 実施形態の処理例を示すシーケンス図（その１）である。 実施形態の処理例を示すシーケンス図（その２）である。 実施形態の処理例を示すシーケンス図（その３）である。 収集ＩＤが付与された発送依頼データの例を示す図である。 マイナンバー提供書の例を示す図である。 通知カード添付用紙の例を示す図である。 宛名シールおよび返信用封筒の例を示す図である。 分割画像データの例を示す図である。 データ入力画面の例を示す図である。 データ修正画面の例を示す図である。 入力・修正済データの例を示す図である。 納品データの例を示す図である。 業務ボリュームに対するシステム構成の例を示す図である。

以下、本発明の好適な実施形態につき説明する。なお、マイナンバーの収集を例に説明するが、これに限らず、その他の個人情報の収集に適用できることはいうまでもない。

＜構成＞
図１は本発明の一実施形態にかかるシステムの構成例を示す図である。図１において、個人情報保持者１は、収集対象となる個人情報であるマイナンバーの付与を受けている従業員や顧客等の個人である。個人情報収集依頼元２は、マイナンバーを収集する企業や金融機関等の組織である。企業や金融機関等は、従業員や顧客等の税務処理等のために、従業員や顧客等の承諾を受けた上でマイナンバーを収集することが必要になる。

個人情報収集請負業者３は、個人情報収集依頼元２からマイナンバーの収集の業務を請け負う事業者である。クラウド環境４は、ネットワーク上でコンピュータのハードウェアおよびソフトウェアのリソースを提供する環境である。提供書発送・受取業者５は、個人情報収集請負業者３との契約に基づき、個人情報保持者１に対するマイナンバー提供書の発送と返信の受取等を行う事業者である。データエントリ業者６は、提供書発送・受取業者５との契約に基づき、データ入力を行う事業者である。

個人情報収集依頼元２の管理下には、個人情報収集依頼元２がマイナンバーを管理する必要のある個人情報保持者１の住所や氏名等を含む発送依頼データを出力する端末装置２１が設けられている。管理下とは、各装置の物理的な設置場所や所有の有無を問わず、所望の情報処理を行う上での権限を有しているという意味である。

個人情報収集請負業者３の管理下には、処理サーバ３１と端末装置３２とが設けられている。処理サーバ３１は、個人情報収集依頼元２の端末装置２１から発送依頼データをオンラインで取得し、あるいは、フラッシュメモリ等の記憶媒体から端末装置３２を経由して発送依頼データを取得し、取得した発送依頼データをクラウド環境４に送信する。

クラウド環境４には、マイナンバー収集作業のための中心的な処理を行う受付システム４１が設けられている。受付システム４１は、サーバ等の１台以上の情報処理装置で構成され、利用する情報処理装置の台数は業務ボリュームに応じてシステム構成を柔軟に変更できるようになっている。

提供書発送・受取業者５の管理下には、提供書印刷・発送システム５１と端末装置５２と複合機５４とが設けられている。提供書印刷・発送システム５１は、例えばシステム管理者が操作するコンピュータ等の情報処理装置と、封筒やシール等の普通紙とは異なる専用紙や特別素材に対する印刷も実行可能な印刷装置により構成され、受付システム４１から管理上の収集ＩＤが付与された発送依頼データを取得し、発送依頼データに基づいて個人情報保持者１に発送する種々の書類（マイナンバー提供書等）を印刷する。端末装置５２は、個人情報保持者１から返送されたマイナンバー提供書の封筒（返信用封筒）からバーコードリーダ５３によりバーコード（１次元コード）を読み取って受付登録等を行う。封筒にバーコードを用いているのは、２次元コードのリーダに比べてバーコードリーダ５３が普及しているためであり、２次元コードが使用できないというわけではない。従って２次元コードによる代替も可能である。端末装置５２は、受付後の審査等にも用いられる。複合機５４は、マイナンバー提供書等の画像を読み取るとともに、マイナンバー提供書等に付された２次元コードの認識等を行う。

データエントリ業者６の管理下には、１台以上の端末装置６１が設けられている。端末装置６１は、マイナンバー提供書に手書きで記載されたマイナンバー部分の分割画像から目視確認でデータを入力等するのに用いられる。

図２はクラウド環境４で構築される受付システム４１の構成例を示す図である。図２において、受付システム４１は、提供書発送・受取業者５およびデータエントリ業者６の拠点毎に設けられる複数の拠点単位サーバ群４２と、データを集中的に管理するデータ蓄積サーバ群４３とを備えている。拠点単位サーバ群４２は、対応する拠点からのアクセスに制限される。

拠点単位サーバ群４２は、複数のロードバランサ４２１と、複数のＡＰサーバ（アプリケーションサーバ）４２２と、複数の入力用ＤＢサーバ（入力用データベースサーバ）４２３と、仮想化されたストレージ４２４とを備えている。ロードバランサ４２１は、外部からネットワーク（ネットワーク４４）を介して送られてくるデータや処理要求を、同等に機能する複数の装置（ＡＰサーバ４２２）に振り分けて一台あたりの負荷を抑える。ＡＰサーバ４２２は、各拠点の業務を遂行（業務処理機能を提供）するアプリケーションプログラムを実行する。入力用ＤＢサーバ４２３は、ストレージ４２４に対するＤＢ処理機能を提供する。ＡＰサーバ４２２にて分散された入力データは、入力用ＤＢサーバ４２３により、クラスタ構成（複数のコンピュータが連結され、利用者や他のコンピュータに対して全体で１台のコンピュータであるかのように振舞うシステム）により仮想化された一つのストレージ４２４に集約される。

データ蓄積サーバ群４３は、複数のロードバランサ４３１と、複数のＡＰサーバ４３２と、複数の参照用ＤＢサーバ（参照用データベースサーバ）４３３と、仮想化されたストレージ４３４とを備えている。ロードバランサ４３１は、外部からネットワーク（ネットワーク４４）を介して送られてくるデータや処理要求を、同等に機能する複数の装置（ＡＰサーバ４３２）に振り分けて一台あたりの負荷を抑え、システムのレスポンスを向上させる。ＡＰサーバ４３２は、データ照会等のアプリケーションプログラムを実行する。参照用ＤＢサーバ４３３は、ストレージ４３４に対するＤＢ処理機能を提供する。ＡＰサーバ４３２にて分散された入力データは、参照用ＤＢサーバ４３３により、クラスタ構成により仮想化された一つのストレージ４３４に集約される。

また、拠点単位サーバ群４２のストレージ４２４に蓄積されたデータは、夜間バッチ処理等により、ネットワーク４５を介してデータ蓄積サーバ群４３のストレージ４３４に集約される。

図３は端末装置２１等（端末装置２１、処理サーバ３１、端末装置３２、端末装置５２、端末装置６１）のハードウェア構成例を示す図である。図３において、端末装置２１等は、バス２０７を介して相互に接続されたＣＰＵ（Central Processing Unit）２０１、ＲＡＭ（Random Access Memory）２０２、ＲＯＭ（Read Only Memory）２０３、ＨＤＤ（Hard Disk Drive）２０４、接続Ｉ／Ｆ（Interface）２０５、通信Ｉ／Ｆ２０６を備えている。ＣＰＵ２０１は、ＲＡＭ２０２をワークエリアとしてＲＯＭ２０３またはＨＤＤ２０４等に格納されたプログラムを実行することで、端末装置２１等の動作を統括的に制御する。接続Ｉ／Ｆ２０５は、端末装置２１等に接続される機器とのインタフェースである。通信Ｉ／Ｆ２０６は、ネットワークを介して他の情報処理装置と通信を行うためのインタフェースである。

図４は複合機５４のハードウェア構成例を示す図である。図４において、複合機５４は、コピー機能、スキャナ機能、ファクス機能、プリンタ機能等の各種の機能を実現可能な本体５１０と、ユーザの操作を受け付ける操作部５２０とを備える。本体５１０と操作部５２０は、専用の通信路５３０を介して相互に通信可能に接続されている。通信路５３０は、例えばＵＳＢ（Universal Serial Bus）規格のものを用いることもできるが、有線か無線かを問わず任意の規格のものであってよい。なお、本体５１０は、操作部５２０で受け付けた操作に応じた動作を行うことができる。また、本体５１０は、クライアントＰＣ（パーソナルコンピュータ）等の外部装置とも通信可能であり、外部装置から受信した指示に応じた動作を行うこともできる。

本体５１０は、ＣＰＵ５１１と、ＲＯＭ５１２と、ＲＡＭ５１３と、ＨＤＤ５１４と、通信Ｉ／Ｆ５１５と、接続Ｉ／Ｆ５１６と、エンジン部５１７とを備え、これらがシステムバス５１８を介して相互に接続されている。

ＣＰＵ５１１は、本体５１０の動作を統括的に制御する。ＣＰＵ５１１は、ＲＡＭ５１３をワークエリア（作業領域）としてＲＯＭ５１２またはＨＤＤ５１４等に格納されたプログラムを実行することで、本体５１０全体の動作を制御し、上述したコピー機能、スキャナ機能、ＦＡＸ機能、プリンタ機能等の各種機能を実現する。通信Ｉ／Ｆ５１５は、ネットワークと接続するためのインタフェースである。接続Ｉ／Ｆ５１６は、通信路５３０を介して操作部５２０と通信するためのインタフェースである。エンジン部５１７は、コピー機能、スキャナ機能、ＦＡＸ機能、および、プリンタ機能を実現させるための、汎用的な情報処理および通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（画像読取部）、用紙等のシート材への印刷を行うプロッタ（画像形成部）、ＦＡＸ通信を行うＦＡＸ部等を備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（Auto Document Feeder：自動原稿給送装置）のような特定のオプションを備えることもできる。

操作部５２０は、ＣＰＵ５２１と、ＲＯＭ５２２と、ＲＡＭ５２３と、フラッシュメモリ５２４と、通信Ｉ／Ｆ５２５と、接続Ｉ／Ｆ５２６と、操作パネル５２７と、外部接続Ｉ／Ｆ５２８とを備え、これらがシステムバス５２９を介して相互に接続されている。ＣＰＵ５２１は、操作部５２０の動作を統括的に制御する。ＣＰＵ５２１は、ＲＡＭ５２３をワークエリアとしてＲＯＭ５２２またはフラッシュメモリ５２４等に格納されたプログラムを実行することで、操作部５２０全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示などの各種機能を実現する。通信Ｉ／Ｆ５２５は、ネットワークと接続するためのインタフェースである。接続Ｉ／Ｆ５２６は、通信路５３０を介して本体５１０と通信するためのインタフェースである。操作パネル５２７は、ユーザの操作に応じた各種の入力を受け付けるとともに、各種の情報（例えば、受け付けた操作に応じた情報、複合機５４の動作状況を示す情報、設定状態などを示す情報等）を表示する。更に、これに加え、またはこれに代えて、ハードウェアキー等の操作部やランプ等の表示部を設けることもできる。外部接続Ｉ／Ｆ５２８は、ＩＣカードリーダ等の機器と接続するためのインタフェースである。

＜動作＞
図５〜図７は上記の実施形態の処理例を示すシーケンス図である。

［発送依頼］
図５において、個人情報収集依頼元２の端末装置２１は、ネットワークを介してオンラインにより直接に、個人情報収集請負業者３の処理サーバ３１に発送依頼データを引き渡す（ステップＳ１０１）。または、記憶媒体を介して（オフライン）個人情報収集請負業者３の端末装置３２により読み取った発送依頼データを処理サーバ３１に引き渡す（ステップＳ１０１）。発送依頼データには、個人情報収集依頼元２である企業や金融機関等が、自らマイナンバーを収集し管理する必要のある１以上の個人情報保持者１に関する個人情報が含まれる。また、個人情報には少なくとも各個人情報保持者１の氏名と住所が含まれる。個人情報収集請負業者３の処理サーバ３１は、引き渡された発送依頼データをクラウド環境４の受付システム４１に送信する（ステップＳ１０２）。

受付システム４１は、受信した発送依頼データをストレージ４３４に保存し（ステップＳ１０３）、所定のタイミングで、発送依頼データの各レコードに対してユニークな収集ＩＤを付与する（ステップＳ１０４）。収集ＩＤは連番で発行してもよいし、重複なくランダムに発行してもよい。つまり、後述するが、これから収集することになる一人分のマイナンバーは、受付システム４１内で１の収集ＩＤにより管理される。従って収集ＩＤはマイナンバーとは異なる情報である。また、この収集ＩＤによってマイナンバーが容易に推測されることのない番号や記号が付与されることが当然望ましい。図８は収集ＩＤが付与された発送依頼データの例を示す図である。この例では、金融機関の各支店を識別する情報が入力される「部店コード」、金融機関が管理すべき個人情報保持者２である顧客の口座番号が入力される「口座番号」、顧客の氏名が入力される「顧客名」、顧客の住所が入力される「住所」、そして各レコードに対して付与された収集ＩＤが入力される「収集ＩＤ」等の項目を有している。また、後述するが、各顧客（ユーザ）からマイナンバーが取得されると、当該顧客のマイナンバーが管理されることになるが、ステップＳ１０４の時点ではまだマイナンバーは登録されていない。なお、「マイナンバー」の項目はこの時点で用意されていてもよい。

［発送］
図５において、提供書発送・受取業者５の提供書印刷・発送システム５１は、受付システム４１から収集ＩＤの付与された発送依頼データを取得し（ステップＳ１０５）、各レコードに対して、収集ＩＤを埋め込んだバーコード（１次元コード）と２次元コードを生成する（ステップＳ１０６）。バーコードは返信用封筒に付すために用いられる。２次元コードはマイナンバー提供書等に付すために用いられる。

提供書印刷・発送システム５１は、所定のフォーマット（雛形）に従い、発送依頼データに基づいて、各顧客に対して発送する発送書類を印刷する。具体的には、顧客の氏名と住所が印字される封筒（送付用）、顧客にマイナンバーを記入させるための２次元コード付マイナンバー提供書、顧客が所持する通知カードのコピーを取得するための２次元コード付通知カード添付用紙、バーコード付返信封筒用宛名シールおよび返信用封筒の印刷データを印刷する（ステップＳ１０７）。なお、これらの書類のうち、発送依頼データに基づかなくても作成可能な書類については、ステップＳ１０７による処理とは別のタイミングで、予め用意されていてもよい。例えば、本実施形態の例で言えば、返信用封筒等は予め用意されていてもよい。そして、提供書印刷・発送システム５１を運用する従業員は、システム５１により作成された封筒（送付用）にマイナンバー提供書、通知カード添付用紙、返信封筒用宛名シールおよび返信用封筒を封入し、郵便等により個人情報保持者１に向けて発送する（ステップＳ１０８、Ｓ１０９）。

図９はマイナンバー提供書の例を示す図であり、右上に、収集ＩＤを埋め込んだ２次元コードが印刷されている。また、他の３つの隅には、用紙の上下方向および裏表を認識しやすくするためのマーカが印刷されている。マイナンバー提供書には、名宛人（本人）のマイナンバーを記入するための分割されたマイナンバー記入枠（１２桁のマイナンバーを４桁ずつ３つに分割して記入する欄）が設けられるとともに、扶養親族についてもマイナンバーを記入するための分割されたマイナンバー記入枠が設けられている。なお、枠の数は３つでなくてもよい。例えば、一つの枠を点線で区切りユーザが１２文字の記入枠を認識できるようにしてもよい。また、１つの枠に記入する文字数も均一であることは必須ではなく、４桁ずつであることも必須ではない。

図１０は通知カード添付用紙の例を示す図であり、マイナンバー提供書（図９）と同様に２次元コードおよびマーカが印刷されているとともに、マイナンバーの通知カード（地方自治体により交付）のコピーを貼り付ける欄が設けられている。

図１１は宛名シールおよび返信用封筒の例を示す図であり、図１１（ａ）のように、シール台紙にバーコード付きの返信封筒用宛名シールが印刷され、図１１（ｂ）のように、返信用封筒には宛名シールを貼り付ける欄が設けられている。

［受取］
図５において、各種の書類が封入された封筒を受け取った個人情報保持者１は、マイナンバー提供書にマイナンバーを記入し、通知カード添付用紙に通知カードのコピーを貼り付け、返信封筒用宛名シールを返信用封筒に貼り付け、住民票等の証明書類とともに返信用封筒に封入し（ステップＳ１１０）、提供書発送・受取業者５に返送する（ステップＳ１１１）。

提供書発送・受取業者５の担当者は、返信用封筒を開封し、所定の書類が含まれていて何らかの記入等があるか否か確認（明確な不備の有無を確認）する（ステップＳ１１２）。そして、提供書発送・受取業者５の担当者が、返送された返信用封筒のバーコードをバーコードリーダ５３で読み取り（ステップＳ１１３）、不備の確認結果を入力すると（ステップＳ１１４）、端末装置５２はバーコードに含まれる収集ＩＤと確認結果を受付システム４１に送信する（ステップＳ１１５）。これを受け、受付システム４１は受付登録または不備登録を行う（ステップＳ１１６）。

次いで、提供書発送・受取業者５の担当者は、複合機５４のスキャナ機能により封入されていた全ての書類をスキャンする（ステップＳ１１７）。複合機５４は、コード認識機能により、書類に含まれる２次元コード（予め付される位置が規定されている）を認識し（ステップＳ１１８）、２次元コードに含まれる収集ＩＤと対応付けて、読み取った書類の画像を受付システム４１に送信する（ステップＳ１１９）。これを受け、受付システム４１は画像登録を行う（ステップＳ１２０）。各画像については、収集ＩＤに枝番号を付した管理番号を付与して登録する。例えば、収集ＩＤが「１」で、読み取った書類が３枚ある場合、それぞれの書類に対して「１−１」「１−２」「１−３」といった管理番号が付与されることで、１の収集ＩＤに関連付く各書類を識別する。なお、同じ返信用封筒に封入された複数枚の書類がそれぞれ識別できれば、数字に限らなくてもよい。また、担当者がスキャナによる一度の読み取りで一人分の書類をまとめて読み取る場合、複合機５４は、読み取った複数枚の書類の中から少なくとも１つの２次元コードを認識できれば、その２次元コードの収集ＩＤを用いて、２次元コードを含まない書類（住民票のコピー等の付帯書類）も管理することができる。あるいは複数人の書類をまとめて読み取る場合、例えば、マイナンバー提供書、通知カード添付用紙、住民票コピーといったように予め２次元コードが先頭に来るような順番で書類を読み取らせることで、複合機５４は一人分の書類につき最初の書類から収集ＩＤを取得できる。よって、読み取った収集ＩＤを保持しておき、保持してある収集ＩＤとは異なる収集ＩＤが新たに読み取られた場合は、保持してある収集ＩＤを新たな収集ＩＤに更新して保持する。そして、保持されている収集ＩＤが更新されるまで、読み取られた書類に順番に枝番号を付与する（書類が１枚ずつ読み取られる毎に、番号をカウントアップして付与する）と、一人分の書類のそれぞれに同じ収集ＩＤが付与され、さらにそれぞれに異なる枝番号を付与することができる。

提供書発送・受取業者５の担当者は、個人情報保持者１から返送された返信用封筒について上記の処理を繰り返し、処理済の返信用封筒および書類を原本として保管する（ステップＳ１２１）。

［１次審査］
図６において、提供書発送・受取業者５の端末装置５２（返信の受取とは別の部署で処理を行う場合には、受取用とは別の端末装置であり、バーコードリーダ５３は不要）は、受付システム４１から収集ＩＤで識別される案件単位でまとめられた書類画像を取得する（ステップＳ１２２）。

担当者は、端末画面に表示される書類画像に基づき、マイナンバー提供書の記載内容と付帯書類の突き合わせによる１次審査を行う（ステップＳ１２３）。この際、内容的に機微な部分への塗り潰し（表示時のマスク設定）の操作を併せて行う。担当者が、１次審査の結果（不備がある場合は不備理由を含む）を入力すると（ステップＳ１２４）、端末装置５２は収集ＩＤと審査結果を受付システム４１に送信し（ステップＳ１２５）、受付システム４１は１次審査の結果を登録する（ステップＳ１２６）。担当者は、処理対象の案件につき、上記の処理を繰り返す。

［２次審査］
提供書発送・受取業者５の端末装置５２（１次審査とは別の部署で処理を行う場合には、１次審査用とは別の端末装置）は、受付システム４１から収集ＩＤで識別される案件単位でまとめられた書類画像と１次審査結果を取得する（ステップＳ１２７）。

担当者は、端末画面に表示される書類画像と１次審査結果に基づき、マイナンバー提供書の記載内容と付帯書類の再度の突き合わせによる２次審査を行う（ステップＳ１２８）。２次審査で不備が認定された場合、受付システム４１の登録情報を用いた不備レターの作成（ステップＳ１２９）を行い、その案件については以下の処理を行わない。不備レターの作成は、不備のある書類の画像と不備の理由を含み、宛先の住所・氏名等が含まれたものとなる。

２次審査で不備がないとされた場合、端末装置５２は、マイナンバー記入枠（予め位置が規定されている）の画像を記入枠毎の複数の画像に分割し（ステップＳ１３０）、各分割画像に対してＯＣＲ（Optical Character Reader）処理を行い（ステップＳ１３１）、各分割画像に対し、収集ＩＤ（あるいは管理番号）にさらに分割の順序を示す枝番号を付した項目ＩＤを付与する（ステップＳ１３２）。なお、ＯＣＲ処理を行ってから分割画像を取得し、ＯＣＲ処理結果を分割画像に合わせて分割してもよい。また、項目ＩＤには、枝番号を使用しなくても、各分割画像に付与した項目ＩＤを用いて分割した分割画像を元のマイナンバー記入枠の順に復元できればよい。そして、端末装置５２は、受付システム４１に項目ＩＤに対応付けて分割画像とＯＣＲ結果を送信し（ステップＳ１３３）、受付システム４１はこれらを分割画像データとして登録する（ステップＳ１３４）。なお、ＯＣＲ結果は、後述するように、手入力した内容との照合に用いる。担当者は、処理対象の案件につき、上記の処理を繰り返す。

図１２は分割画像データの例を示す図であり、マイナンバー提供書のマイナンバー記入枠の画像を４桁ずつの３つに分割した画像と、それぞれに付与された項目ＩＤと、ＯＣＲ結果とを含んでいる。この例では、既に記入枠が複数に分割されているため、記入枠毎に画像を取得すればよいが、記入枠が一つであっても、一つの記入枠の画像を所定の文字数単位で区切った画像を取得するようにしても同様の結果を実現できる。つまり、マイナンバーのように複数の文字列からなる特定の情報を複数に分割することができればよい。なお、同じ収集ＩＤに関し、各書類を識別する管理番号に利用する枝番号と、各分割画像を識別する項目ＩＤに利用する枝番号は重複しないようにするのが望ましい。但し、例えば、いずれの枝番号も１から順に番号を付与する場合、収集ＩＤではなく管理番号に対してさらに枝番号を付与した項目ＩＤで分割画像を管理すれば重複することはなくなる。図１２には、収集ＩＤが「２３４８９７６９」のマイナンバー提供書に対して、管理番号用の枝番号は記入無しとなっており（記入無しは０番目の順番を意味しており、他の書類に「１」「２」と枝番号が付与されることで各書類を識別できる）、さらに項目ＩＤ用の枝番号として「Ｋ１」「Ｋ２」「Ｋ３」が付与されている例が挙げられている。なお、図示の例では全てにＯＣＲ結果が正しく表示されているが、クセのある書き方の場合は、一部が正確に認識されなかったり、全く認識されない場合もある。分割画像は、単独ではマイナンバーを特定できるものではないため、個々の分割画像を取得するだけではユーザは個人のマイナンバーを特定できない。よって、分割画像データの個々についてはセキュリティを考慮する必要はなくなる一方で、装置は項目ＩＤにより、マイナンバーを特定することができる。

［データエントリ］
図６において、データエントリ業者６の端末装置６１は、受付システム４１から項目ＩＤで識別される分割画像（分割画像データ）を取得する（ステップＳ１３５）。そして、端末装置６１は、分割画像データをランダムに抽出して１の分割画像データを画面表示し（ステップＳ１３６）、担当者による目視によるデータ入力を受け付ける（ステップＳ１３７）。図１３はデータ入力画面の例を示す図であり、上部に分割画像が表示され、下部にデータ入力欄が表示され、右下に「ＯＫ」ボタンが表示されている。図１３からもわかるように、このデータ入力画面にはＯＣＲ結果は表示されない。担当者は、分割画像を目視により確認した上で、データ入力欄にテンキー等により対応する数字を入力し、「ＯＫ」ボタンを押すことで、１件分の入力を完了する。なお、画面には複数の分割画像データとそれぞれに対するデータ入力欄が表示されていてもよいが、重要なことは、担当者（ユーザ）がデータ入力画面に表示される分割画像データを組み合わせて個人のマイナンバーを特定できないようにすることである。従って、受付システム４１は、十分な人数分のマイナンバー提供書から分割された分割画像が収集された段階で、そこから画面に表示する分割画像をランダムに抽出していくことが望ましい。十分な人数は、システム運用者が適宜決定すればいいが、人数は多いほど良いだろう。

図６に戻り、データ入力が完了すると、端末装置６１は項目ＩＤと、１の分割画像に対して手入力された分割ナンバーとを受付システム４１に送信し（ステップＳ１３８）、受付システム４１は項目ＩＤと対応付けて分割ナンバーを登録する（ステップＳ１３９）。担当者は、処理対象の案件につき、上記の処理を繰り返す。

［データ修正］
図７において、受付システム４１は、１の分割画像に対して、手入力された分割ナンバーとＯＣＲ結果とが一致するか否かを判定する。そして、受付システム４１は、不一致と判定した分割画像をデータエントリ業者６の端末装置６１に通知し、データエントリ業者６の端末装置６１は、受付システム４１から、手入力された分割ナンバーとＯＣＲ結果とが不一致の案件について、その分割画像の項目ＩＤと分割画像と分割ナンバーとＯＣＲ結果を取得する（ステップＳ１４０）。

そして、端末装置６１は、データ修正画面を表示し、担当者からデータ修正または修正なしの確認を受け付ける（ステップＳ１４１）。図１４はデータ修正画面の例を示す図であり、ランダムに表示されたナンバー画像（分割画像）と打鍵内容（分割ナンバー）とＯＣＲ結果と修正確認のチェックボックスが表示されている。なお、図１４からもわかるように、このデータ入力画面には項目ＩＤや収集ＩＤは表示されない。担当者は、ナンバー画像と打鍵内容とを目視により確認し、打鍵内容が正しいと判断した場合は、修正を行わずに「済」チェックボックスにチェックを入れる。打鍵内容が正しくないと判断した場合は、打鍵内容を修正し、「済」チェックボックスにチェックを入れる。なお、正しいか否かの判断及び修正の対象をＯＣＲ結果としても構わないし、別途データ入力欄を設け、そこに正しいと判断した内容を入力するようにしても構わない。

図７に戻り、データ修正確認が完了すると、端末装置６１は、項目ＩＤと修正確認内容を受付システム４１に送信し（ステップＳ１４２）、受付システム４１は項目ＩＤと対応付けて修正確認内容を登録する（ステップＳ１４３）。図１５は入力・修正済データの例を示す図であり、項目ＩＤに修正確認済の分割ナンバーが対応付けられている。担当者は、処理対象の案件につき、上記の処理を繰り返す。

なお、手入力された分割ナンバーとＯＣＲ結果とが不一致の案件について、担当者による修正または修正なしの確認を行うことで、分割ナンバーの精度を高めるようにした例について説明したが、多数の担当者に分割ナンバーを手入力され、最も頻度の高い分割ナンバーを正解として採用することもできる。この場合、ＯＣＲ結果は不要となる。

［納品データ生成］
図７において、受付システム４１は、項目ＩＤに基づき、入力・修正済のデータから個人のマイナンバーのデータを再構築して納品データを生成する（ステップＳ１４４）。すなわち、項目ＩＤの本体部（枝番号を除いた収集ＩＤ部分）でまとめた上で、枝番号の順序で並べ替えて合体してマイナンバーを再構築し、他の項目と結合して納品データを生成する。図１６は納品データの例を示す図であり、「部店コード」「口座番号」「顧客名」「住所」等の項目に加えて、入力・修正済のデータに基づき生成されたマイナンバーを入力する「マイナンバー」の項目を有している。

そして、受付システム４１は、納品データを個人情報収集請負業者３に送信し（ステップＳ１４５）、個人情報収集請負業者３は、納品データを個人情報収集依頼元２にオンラインまたはオフラインにより引き渡す（ステップＳ１４６）。

［受付システムの構成変更］
受付システム４１は、業務ボリュームに応じてシステム構成を柔軟に変更できることは前述した通りである。マイナンバーは所定の期日から全国一斉に利用が開始されるものであるため、その収集業務は、初期には相当量の業務ボリュームとなり、徐々に業務ボリュームが減少し、その後は一定の低い水準で推移するものと想定される。業務ボリュームに対してシステムの処理能力が不十分である場合にはレスポンスの低下を招き、業務効率を悪化させるため、業務ボリュームに応じて適切な処理能力を維持することが重要となる。

図１７は業務ボリュームに対するシステム構成の例を示す図である。図１７（ａ）は、運用開始当初の最も業務ボリュームが多い場合に対応したものであり、提供書発送・受取業者５およびデータエントリ業者６の拠点数を１０とし、拠点単位サーバ群４２を拠点単位サーバ群４２＃１〜４２＃１０〜の１０個としている。図１７（ｂ）は、業務ボリュームが下がってきた場合に対応したものであり、拠点数を５とし、拠点単位サーバ群４２を拠点単位サーバ群４２＃１〜４２＃５〜の５個としている。図１７（ｃ）は、業務ボリュームが収束した場合に対応したものであり、拠点数を１とし、拠点単位サーバ群４２を拠点単位サーバ群４２＃１の１個としている。つまり、受付システム４１は、拠点単位サーバ群４２単位で、適宜システム構成を変更することができる。

また、拠点単位サーバ群４２の個々およびデータ蓄積サーバ群４３についても、内部構成が変更可能であり、各サーバ群を構成する物理的なコンピュータ装置やネットワーク装置の台数やディスク装置の容量を増減することが可能である。

受付システム４１は、クラウド環境４を利用して構築するものであり、物理的なコンピュータ装置やネットワーク装置やディスク装置を購入して自前で用意する必要はなく、運用途中の各時点で業務ボリュームに対応したリソースの利用料を支払えばよいことから、コストの最適化を図ることが可能となる。

一方で、図１の全体的なシステム構成でも示されるように、受付システム４１は、企業や金融機関等の個人情報収集依頼元２からマイナンバーの収集依頼を受ける受注業者により運用され、収集依頼データの受領および納品データの納品が行われる。また、数百万、数千万人レベルでのマイナンバーのデータ入力業務ともなると、１社のデータエントリ業者６に依頼するのではなく、複数のデータエントリ業者６に依頼をすることが想定され、業務ボリュームが落ち着くことにより、依頼を行うデータエントリ業者６の数も少なくなるだろう。

そこで、受注業者が常に依頼の状況を監視して拠点単位サーバ群４２のボリュームを制御してもいいが、受注業者が１のデータエントリ業者６に対して１あるいは複数の拠点単位サーバ群４２を割り振り、受付システム４１のデータ蓄積サーバ群４３がその対応関係を管理することが考えられる。このようにすることで、受付システム４１は、受注業者によるデータエントリ業者６の増減に応じて、拠点単位サーバ群４２の増減を制御することができる。

つまり、受注業者は、依頼するデータエントリ業者６を追加する時には、受付システム４１に対して、データエントリ業者６の新規登録と、割り振る拠点単位サーバ群の数を入力する。受付システム４１のデータ蓄積サーバ群４３は、新規のデータエントリ業者６を識別する業者ＩＤを付与し、また、付与した業者ＩＤに対応付けて、新規データエントリ業者６に割り振る拠点単位サーバ群４２のサーバ群ＩＤを登録する。

また、受注業者は、依頼するデータエントリ業者６を減らす時には、受付システム４１に対して、対象のデータエントリ業者６の削除を要求する。受付システム４１のデータ蓄積サーバ群４３は、対象のデータエントリ業者６の業者ＩＤに対応付くサーバ群ＩＤに基づいて拠点単位サーバ群４２の利用を停止する。このようにすれば、受注業者は、受付システム４１を構築するためにクラウドサービス業者から借りるサーバの数を柔軟に変更し、余分な利用料の支払いを抑制することができる。

＜総括＞
以上説明したように、本実施形態によれば、業務ボリュームに応じた処理能力のシステム構成を適切なコストで実現することができる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

１ 個人情報保持者
２ 個人情報収集依頼元
２１ 端末装置
３ 個人情報収集請負業者
３１ 処理サーバ
３２ 端末装置
４ クラウド環境
４１ 受付システム
４２ 拠点単位サーバ群
４２１ ロードバランサ
４２２ ＡＰサーバ
４２３ 入力用ＤＢサーバ
４２４ ストレージ
４３ データ蓄積サーバ群
４３１ ロードバランサ
４３２ ＡＰサーバ
４３３ 参照用ＤＢサーバ
４３４ ストレージ
４４、４５ ネットワーク
５ 提供書発送・受取業者
５１ 提供書印刷・発送システム
５２ 端末装置
５３ バーコードリーダ
５４ 複合機
６ データエントリ業者
６１ 端末装置

特開２０１３−２０８４２６号公報

Claims (5)

1. 個人情報の収集業務の作業データを要求に応じて蓄積し、要求に応じて蓄積された作業データを提供する、クラウド環境上に構築されるシステムであって、
   前記収集業務を行う拠点毎に設けられ、対応する拠点にアクセスが制限される拠点単位サーバ群と、
   前記拠点単位サーバ群の蓄積データが集約されるデータ蓄積サーバ群と
   を備えたことを特徴とする個人情報収集システム。
2. 請求項１に記載の個人情報収集システムにおいて、
   前記拠点単位サーバ群は、処理負荷を振り分ける複数のロードバランサと、業務処理機能を提供する複数のアプリケーションサーバと、データベース処理機能を提供する複数のデータベースサーバと、仮想化されたストレージとを備える
   ことを特徴とする個人情報収集システム。
3. 請求項１または２のいずれか一項に記載の個人情報収集システムにおいて、
   前記データ蓄積サーバ群は、処理負荷を振り分ける複数のロードバランサと、業務処理機能を提供する複数のアプリケーションサーバと、データベース処理機能を提供する複数のデータベースサーバと、仮想化されたストレージとを備える
   たことを特徴とする個人情報収集システム。
4. 個人情報の収集業務の作業データを要求に応じて蓄積し、要求に応じて蓄積された作業データを提供する、クラウド環境上に構築されるシステムを構成する装置が実行する方法であって、
   前記収集業務を行う拠点毎に設けられ、対応する拠点にアクセスが制限される拠点単位サーバ群が、前記拠点の情報処理装置との間でデータの入出力を行う工程と、
   前記拠点単位サーバ群がデータ蓄積サーバ群に対して前記拠点単位サーバ群の蓄積データを集約する工程と
   を備えたことを特徴とする個人情報収集方法。
5. 個人情報の収集業務の作業データを要求に応じて蓄積し、要求に応じて蓄積された作業データを提供する、クラウド環境上に構築されるシステムを構成する装置を構成するコンピュータに、
   前記収集業務を行う拠点毎に設けられ、対応する拠点にアクセスが制限される拠点単位サーバ群が、前記拠点の情報処理装置との間でデータの入出力を行う手順と、
   前記拠点単位サーバ群がデータ蓄積サーバ群に対して前記拠点単位サーバ群の蓄積データを集約する手順と
   を実行させる個人情報収集プログラム。