JP6601772B2 - 個人情報管理システム - Google Patents

Description

本発明は、個人情報管理システムに関する。

従来、個人を特定可能な個人情報は、厳正な管理をする必要がある。個人情報の管理としては、例えば、不要になった情報を他のコンピュータに移動したり削除したりすることや、個人情報と個人が特定されない匿名情報とを直接的に結び付けることなく監理することが考えられている（例えば、特許文献１，２参照）。

特開２００１−１７５５１１号公報 特開２０１１−３９７１０号公報

政府が国民１人１人に重複しないユニークな番号である個人番号（「マイナンバー」ともいう。）を付与し、個人情報管理の容易化や、電子計算機による行政事務の効率化を目的とする番号制度の導入に伴い、個人番号に関しても厳正に取り扱うことが必要である。
顧問先企業が従業員の税や給与処理を行うために、当該顧問先従業員やその家族の個人番号が必要となるが、従業員やその家族の個人番号の厳密な管理が必要となる。
また、公認会計士事務所や税理士事務所等の会計事務所（以下、単に「会計事務所」と称す。）においては、顧問先毎の各顧問先従業員やその家族の個人番号が必要となり、顧問先企業の個人番号の管理よりも煩雑になる。

そこで、本発明は、個人番号の取得、利用、保管及び廃棄を厳正に行うことが可能な個人情報管理システムを提供することを目的とする。
また、顧問先だけでなく、複数の顧問先の管理が煩雑になる会計事務所においても、効率的に個人番号の取得、利用、保管及び廃棄を厳正に行うことが可能な個人情報管理システムを提供することを目的とする。

本発明は、以下のような解決手段により、前記課題を解決する。
第１の発明は、出力した一意に定まる個人番号を含む紙媒体、ＰＤＦ及びＣＤＲＯＭを含む可搬型記録媒体に焼いたＰＤＦのうち少なくとも１つである出力媒体について、前記出力媒体に含まれた個人番号について削除条件を満たす場合に、オフライン環境で、前記出力媒体の削除状況を追跡し、確実に削除したかどうかまでを管理する個人情報管理システムであって、一意に定まる個人番号と、業務を識別する業務識別情報が対応付けられた前記個人番号の使用に関する使用許諾情報とを含む個人情報と、企業や事務所の組織を識別する企業識別情報とを対応付けて特定個人情報記憶部に記憶させる個人情報記憶制御手段と、個人番号を含む帳表を、紙媒体、ＰＤＦ形式を含む出力媒体で出力する場合に、出力した出力媒体に関する情報を記録すると共に、出力媒体に対する管理、変更、移動、削除の履歴を含むログ情報を記録する、出力媒体関連情報記録手段と、前記業務識別情報と、前記企業識別情報と、企業内の個人を識別する個人識別情報とに基づく消去条件を満たした場合に、前記消去条件を満たした前記個人情報を含む消去対象情報を出力する消去情報出力手段と、所定の個人番号について、消去条件及び前記出力媒体関連情報記録手段によって記録された情報に基づいて、消去条件を満たした消去対象情報に含まれる紙媒体ないしＰＤＦを含む前記出力媒体の削除リストを作成するリスト作成手段と、を備え、前記削除リストは、（ａ）前記出力媒体の名称を含む名称一覧、（ｂ）前記出力媒体に含まれる前記個人番号に係る個人の名前又は社員番号、その個人の組織を含む個人情報、（ｃ）前記出力媒体の出力年月日及び時間、出力者、出力場所（プリンタやＰＣ名称等）、管理責任者の情報、（ｄ）ＰＤＦ出力したものや、印刷出力した帳表のＰＤＦ（印刷したものはＰＤＦ化してある）へのリンク（格納先情報やそのディレクトリも含む）を含むリンク情報、（ｅ）紙媒体に関する、送付した先、保管したバインダーファイルの名称、ロッカーの名称等を含む保管情報、（ｆ）削除の有無、出力した年月日、削除することが必要になった年月日、その理由（契約解消、文書の保存年限経過）、削除したものは削除した年月日、削除した管理者の氏名やＩＤを含むステータス情報、（ｇ）システム管理者が「１週間以内に削除が必要」に例示される注意を喚起する表示を含む注記情報、（ｈ）削除した結果を入力するチェック欄、及び、（ｉ）所定の期間内に前記削除リストのチェック欄（ｈ）の削除結果が入力されていない場合は、システム管理者に通知し、未削除出力媒体の前記出力者又は前記管理責任者に削除処理を促す旨の注意情報、のいずれか１以上を一覧表示すること、を特徴とする個人情報管理システムである。
第２の発明は、第１の発明の個人情報管理システムにおいて、前記出力媒体に関するログデータを記録するログ記録手段を備え、前記ログ記録手段は、自動で、又は、入力を受け付けることで記録すること、を特徴とする個人情報管理システムである。
第３の発明は、第１の発明又は第２の発明の個人情報管理システムにおいて、前記削除リストのチェック欄（ｈ）は、所定のアクセス権限者による削除完了の入力を求めるものであること、を特徴とする個人情報管理システムである。
第４の発明は、第２の発明の個人情報管理システムにおいて、前記ログ記録手段は、前記出力媒体に関するコピーの履歴や、変更の有無を記録するものであること、を特徴とする個人情報管理システムである。
第５の発明は、第１の発明から第４の発明までのいずれかの個人情報管理システムにおいて、オフライン環境で出力した前記出力媒体が紙媒体である場合には、同時にＰＤＦ化して保存するＰＤＦ保存手段を備え、前記ＰＤＦ保存手段によって保存したＰＤＦは、帳表の概要を含み、かつ、前記個人番号は、参照不可に処理がされたものであること、を特徴とする個人情報管理システムである。
第６の発明は、第１の発明から第５の発明までのいずれかの個人情報管理システムにおいて、削除処理を指示した場合に、無意味なデータを上書きしてデータ復元できない削除処理を行う削除ツールを使用して、前記個人番号を含む前記出力媒体のデータを完全消去すること、を特徴とする個人情報管理システムである。

本発明によれば、個人番号の取得、利用、保管及び廃棄を厳正に行うことが可能な個人情報管理システムを提供することができる。

本実施形態に係る会計処理システムの全体構成を示す図である。 本実施形態に係る会計処理装置の機能ブロックを示す図である。 本実施形態に係る会計処理装置での個人情報管理メイン処理のフローチャートである。 本実施形態に係る会計処理装置での個人情報取得処理のフローチャートである。 本実施形態に係る顧問先ＤＢの例を示す図である。 本実施形態に係る特定個人情報ＤＢの例を示す図である。 本実施形態に係る特定個人情報ＤＢの例を示す図である。 本実施形態に係る会計処理装置での業務アプリ利用処理のフローチャートである。 本実施形態に係る業務処理データＤＢの例を示す図である。 本実施形態に係るログＤＢの例を示す図である。 本実施形態に係る会計処理装置での個人番号照会処理のフローチャートである。 本実施形態に係るユーザＤＢの例を示す図である。 本実施形態に係る表示部の例を示す図である。 本実施形態に係る会計処理装置での個人番号無効化処理のフローチャートである。 本実施形態に係る会計処理装置での削除処理のフローチャートである。 本実施形態に係る会計処理装置での削除対象リスト作成処理のフローチャートである。 本実施形態に係る会計処理装置の記憶部に記憶されるデータの例を示す図である。 本実施形態に係る会計処理装置でのデータ削除処理のフローチャートである。 本実施形態に係る会計処理装置の記憶部に記憶されたバックアップ管理テーブルの例を示す図である。 他の実施形態に係る会計処理装置での個人情報管理メイン処理のフローチャートである。 他の実施形態に係る会計処理装置での削除処理のフローチャートである。

以下、本発明を実施するための形態について、図を参照しながら説明する。なお、これは、あくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。
（実施形態）
＜会計処理システム１００の全体構成＞
図１は、本実施形態に係る会計処理システム１００の全体構成を示す図である。
図２は、本実施形態に係る会計処理装置１の機能ブロックを示す図である。
図１に示す会計処理システム１００は、顧問先の端末７から依頼を受けた会計事務所の会計処理装置１（個人情報管理システム）が、各種の業務アプリケーションプログラム（以下、アプリケーションプログラムのことを、「アプリ」ともいう。）を実行して会計処理を行うシステムである。

会計処理システム１００は、会計処理装置１と、端末７とを備える。そして、会計処理システム１００は、通信ネットワークＮによって、会計処理装置１と、端末７の間でデータ通信を行う。
会計処理装置１は、例えば、会計事務所に設けられ、各種会計処理を行う装置である。会計処理装置１は、個人情報の管理に関する機能と、各種の会計処理に対応する複数の業務処理機能とを有する。
会計処理装置１は、サーバ１ａと、複数台の端末１ｂ（コンピュータ）とにより構成される。サーバ１ａは、端末１ｂから受信した操作データに基づいて処理を行う。複数台の端末１ｂは、会計事務所の業務処理担当者（以下、「ユーザ」という。）が操作する端末である。

なお、図１では、会計処理装置１を、サーバ１ａと、端末１ｂとからなるものとして説明したが、これは、一例である。サーバ１ａは、後述する機能ごとに複数台を有してもよい。また、会計処理装置１は、例えば、１台のスタンドアロンのコンピュータで構成されていてもよい。会計処理装置１は、会計事務所ではなく、顧問先企業内にあったり、業務委託等のサービスを行っている企業内であったり、クラウドサービスであってもよい。
このほか、会計処理装置１は、サーバのみ、あるいは複数のサーバで構成されていてもよく、会計事務所のサーバである場合の他、複数の企業（の従業員）の個人番号を預かって管理するサービスを行うＩＤＣ（インターネットデータセンター）のサーバでもよい。さらには、実体が仮想化された仮想マシンやクラウドであってもよい。
あるいは、企業の本社等が各部門や各支店（の従業員）等を対象にマイナンバーの管理を行う場合には、会計処理装置１は、企業内のサーバであってもよい。その際、顧問先の端末７は各部門や各支店の端末に読み替えることで本発明を適用可能である。

端末７は、顧問先に設けられたパーソナルコンピュータ（ＰＣ）等である。端末７は、例えば、ノートＰＣ、タブレット等の携帯型端末であってもよい。
なお、会計処理装置１は、国税庁のサーバ８に各種の電子書類を送信する。サーバ８は、会計処理装置１から受信した電子書類に基づいて、納税処理等を行う。会計処理装置１で作成した電子書類には、後述するように、政府が国民に付与した重複しないユニークな番号である個人番号が含まれるので、納税に関する処理を厳正に行うことができる。

＜会計処理装置１＞
図２に示すように、会計処理装置１は、制御部１０と、記憶部３０と、入力部４５と、表示部４６と、通信インタフェース部４９とを備える。図１の会計処理装置１の構成によれば、サーバ１ａは、制御部１０と、記憶部３０と、通信インタフェース部４９とが該当し、端末１ｂは、入力部４５と、表示部４６とが該当する。表示部４６は、出力部も含む。
制御部１０は、会計処理装置１の全体を制御するＣＰＵ（中央処理装置）である。制御部１０は、記憶部３０に記憶されているＯＳ（オペレーティングシステム）やアプリケーションプログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、各種機能を実行する。

制御部１０は、個人情報制御部１１と、業務アプリ制御部２５（業務アプリ制御手段）とを備える。
個人情報制御部１１は、個人番号を含む個人情報に関する処理を制御する。
個人情報制御部１１は、取得管理部１２と、情報利用部１５と、情報管理部１８とを備える。
取得管理部１２は、個人番号の取得及び登録に関する制御部である。
取得管理部１２は、情報取得部１３（情報取得手段）と、情報登録部１４（個人情報記憶制御手段）とを備える。
情報取得部１３は、例えば、顧問先の端末７から受信した個人番号を含む個人情報を取得する。個人情報には、取得した個人番号の使用許諾情報が含まれていてもよい。
情報登録部１４は、情報取得部１３が取得した個人番号を、特定個人情報ＤＢ（データベース）３３に記憶させる。特定個人情報ＤＢ３３には、取得した個人番号と関連付けた使用許諾情報を、個人番号と一緒に保存してもよい。

情報利用部１５は、個人番号の利用に関する制御部である。
情報利用部１５は、アプリ判別部１６（アプリ判別手段）と、個人番号出力部１７（個人番号出力手段）と、画面データ出力部１７ａ（画面データ出力手段）とを備える。
アプリ判別部１６は、実行する業務アプリ３２が、個人番号を使用するものであるか否かを判別する。業務アプリ３２については、会計事務所で使用する記帳代行、会計、財務、税務、監査等の処理に必要なアプリや顧問先企業で使用する会計、財務、給与計算等の処理に必要なアプリに限られない。
個人番号出力部１７は、実行する業務アプリ３２に、個人番号を出力する。
画面データ出力部１７ａは、業務アプリ３２が出力した帳簿データ（処理データ）に、個人番号を含めた画面データを生成して表示部４６に出力する。

情報管理部１８は、特定個人情報ＤＢ３３の管理（消去、追加修正、読出しの無効化等）や、個人番号を含むデータ、個人番号を使用して出力した帳簿データに関する管理及び無効化等を行う制御部である。
情報管理部１８は、個人情報処理部１９（個人情報記憶制御手段）と、業務データ処理部２０（処理データ記憶制御手段）と、ログ処理部２１（ログ取得手段、ログ記憶制御手段）と、消去対象生成出力部２２（消去対象生成出力手段）と、消去関連生成出力部２３（消去関連生成出力手段）とを備える。
個人情報処理部１９は、特定個人情報ＤＢ３３の個人番号を消去、追加ないし修正の他、無効にしたり、無効化された個人番号を有効にしたりする。ここで、無効化とは、特定個人情報ＤＢ３３の個人番号を、業務アプリ３２等から取得できない状態にすることをいう。削除の場合は、以後、個人番号にアクセスできなくなるのに対し、無効化は、アクセス可能に戻すことができる点で削除と相違する。
なお、個人番号の追加とは、新たに個人番号を取得することのほか、既に取得済みの従業員に対して扶養者等が追加される場合を含む。また、ここでいう修正とは、誤って入力した番号の修正といった個人番号自体の修正や個人番号の漏洩等の事情により特例として個人番号を修正する場合の他、個人番号に関連付けられている個人情報（氏名、住所等）の修正を含むものとする。
業務データ処理部２０は、業務アプリ３２が出力した帳簿データを、業務処理データＤＢ３６に記憶させる。

ログ処理部２１は、各種ログを取得して、ログＤＢ３７に記憶させる。ログ処理部２１は、特定個人情報ＤＢ３３へのアクセスログや、個人番号を含むデータに関するログ、端末７や入力部４５による各種のオペレーションログ等を取得する。
消去対象生成出力部２２は、消去対象となった個人番号を含む削除対象リスト（項目）を生成して出力する。
消去関連生成出力部２３は、消去対象となった個人番号を含むデータを消去し、ＰＤＦ出力や印刷出力等の出力履歴を元に、特定個人情報ＤＢ３３の、個人番号を含む、データではない紙や記録媒体に保存したデータ等の情報である削除対象リスト（詳細）を生成して出力する。
消去対象生成出力部２２と、消去関連生成出力部２３とにおける各処理の相違は、消去対象生成出力部２２では、ある年度に作成した帳表が文書としての保有期限を超えた場合に、その帳表に係る個人番号を消去する必要が生じるので、どの帳表（どの年度のどの帳表種別）が保有期限を超えたのかを判定してリスト化するのに対し、消去関連生成出力部２３では、このリスト化した帳表の出力履歴（紙出力、ＰＤＦ出力）等を加味して、どういった態様（紙出力、ＰＤＦ出力）の帳表があるかの情報を付加する点で相違する。
業務アプリ制御部２５は、業務アプリ３２での処理を制御する。
なお、上述した各機能の詳細については、後述する。

記憶部３０は、制御部１０が各種の処理を実行するために必要なプログラム、データ等を記憶するためのハードディスク、半導体メモリ素子等の記憶領域である。
記憶部３０は、プログラム記憶部３１と、特定個人情報ＤＢ３３（特定個人情報記憶部）と、ユーザＤＢ３４（担当者権限記憶部）と、顧問先ＤＢ３５と、業務処理データＤＢ３６（処理データ記憶部）と、ログＤＢ３７とを備える。
プログラム記憶部３１は、個人情報管理アプリ３１ａと、各種の業務アプリ３２（３２ａ，３２ｂ，・・・）を記憶している。
個人情報管理アプリ３１ａは、上述した制御部１０の個人情報制御部１１が行う各種機能を実行するためのアプリケーションプログラムである。
業務アプリ３２（３２ａ，３２ｂ，・・・）は、上述した制御部１０の業務アプリ制御部２５が行う各種機能を実行するためのアプリケーションプログラムである。例えば、業務アプリ３２ａは、所得税のためのアプリであり、業務アプリ３２ｂは、相続税のためのアプリである。

特定個人情報ＤＢ３３は、個人番号に関するデータを記憶するＤＢである。
ユーザＤＢ３４は、会計処理装置１を使用するユーザに関するデータを記憶するＤＢである。
顧問先ＤＢ３５は、会計処理の依頼主である顧問先に関するデータを記憶するＤＢである。
業務処理データＤＢ３６は、会計処理を行う元データである業務処理データや、業務処理後の帳簿データに関するＤＢである。
ログＤＢ３７は、各種ログを記憶するＤＢである。
なお、各ＤＢの詳細については、後述する。

入力部４５は、キーボードやマウス等の入力装置である。
表示部４６は、ＬＣＤ（液晶ディスプレイ）等で構成される表示装置である。
通信インタフェース部４９は、端末７やサーバ８との間のインタフェースである。
なお、本発明でいうコンピュータとは、制御部、記憶装置等を備えた情報処理装置をいい、会計処理装置１は、制御部１０、記憶部３０等を備えた情報処理装置であり、本発明のコンピュータの概念に含まれる。

＜会計処理装置１の処理＞
次に、会計処理装置１による個人番号に関する処理について説明する。
図３は、本実施形態に係る会計処理装置１での個人情報管理メイン処理のフローチャートである。
この個人情報管理メイン処理は、個人情報管理アプリ３１ａの実行により行われ、この会計処理装置１の電源がＯＮである間に、適宜のタイミングで行われる。

図３のステップＳ（以下、単に「Ｓ」という。）１において、会計処理装置１の個人情報制御部１１（取得管理部１２）は、個人情報の取得に関する処理を行うか否かを判断する。個人情報の取得に関する処理を行う場合（Ｓ１：ＹＥＳ）には、個人情報制御部１１は、処理をＳ２に移す。個人情報の取得に関する処理を行わない場合（Ｓ１：ＮＯ）には、個人情報制御部１１は、処理をＳ３に移す。
Ｓ２において、個人情報制御部１１（取得管理部１２）は、後述する個人情報取得処理（図４）を行う。

Ｓ３において、個人情報制御部１１（情報利用部１５）は、業務アプリ３２に関する処理を行うか否かを判断する。例えば、会計処理装置１を使用するユーザの操作によって業務アプリ３２が選択されることで、個人情報制御部１１は、業務アプリ３２に関する処理を行うと判断する。業務アプリ３２に関する処理を行う場合（Ｓ３：ＹＥＳ）には、個人情報制御部１１は、処理をＳ４に移す。他方、業務アプリ３２に関する処理を行わない場合（Ｓ３：ＮＯ）には、個人情報制御部１１は、処理をＳ５に移す。
Ｓ４において、個人情報制御部１１（情報利用部１５）は、後述する業務アプリ利用処理（図７）を行う。

Ｓ５において、個人情報制御部１１（情報利用部１５）は、個人番号を含むデータに関する処理を行うか否かを判断する。例えば、会計処理装置１を使用するユーザが入力部４５から個人番号を含むデータの表示を選択することで、個人情報制御部１１は、個人番号に関する処理を行うと判断する。個人番号を含むデータに関する処理を行う場合（Ｓ５：ＹＥＳ）には、個人情報制御部１１は、処理をＳ６に移す。他方、個人番号を含むデータに関する処理を行わない場合（Ｓ５：ＮＯ）には、個人情報制御部１１は、処理をＳ７に移す。
Ｓ６において、個人情報制御部１１（情報利用部１５）は、後述する個人番号照会処理（図１０）を行う。
Ｓ７において、個人情報制御部１１（情報管理部１８）は、後述する個人番号無効化処理（図１３）を行う。

Ｓ８において、個人情報制御部１１（情報管理部１８）は、個人番号を含むデータの削除条件か否か判断する。例えば、個人番号を含むデータの保存期間（以降、保有期限という）が経過したことで、個人情報制御部１１は、個人番号を含むデータの削除条件になったと判断する。個人番号を含むデータの削除条件である場合（Ｓ８：ＹＥＳ）には、個人情報制御部１１は、処理をＳ９に移す。他方、個人番号を含むデータの削除条件ではない場合（Ｓ８：ＮＯ）には、個人情報制御部１１は、本処理を終了する。
Ｓ９において、個人情報制御部１１（情報管理部１８）は、後述する削除処理（図１４）を行う。その後、個人情報制御部１１は、本処理を終了する。
なお、Ｓ７やＳ９の処理中に、個人情報制御部１１（情報利用部１５）は、後述する個人番号照会処理（図１０）を行ってもよい。

次に、各処理について説明する。
＜個人情報取得処理＞
まず、個人情報取得処理について説明する。
図４は、本実施形態に係る会計処理装置１での個人情報取得処理のフローチャートである。
図５は、本実施形態に係る顧問先ＤＢ３５の例を示す図である。
図６（図６−１、図６−２）は、本実施形態に係る特定個人情報ＤＢ３３の例を示す図である。

図４のＳ１０において、会計処理装置１の個人情報制御部１１（情報取得部１３）は、顧問先の端末７から受信することで、個人番号を含む個人情報を取得する。個人情報は、会社コード及び社員番号と、個人番号と、個人番号を使用する業務の業務名（業務識別情報）と、その使用許諾情報とを含む。個人番号は、会社コード及び社員番号で特定できる。また、個人番号は、政府が国民１人１人に付与した０〜９の数字１２桁からなる番号である。使用許諾情報は、該当業務での個人番号の使用を許諾する情報である。顧問先企業が、事前に従業員とその家族から個人番号の使用の許諾を受けて使用許諾情報を作成する。使用許諾情報により、会計事務所側では、業務で個人番号を使用する都度、個人番号の使用に関してその本人に同意を得る必要がない。それゆえ、会計処理装置１は、個人番号を、許諾された業務で使用することができる。

なお、個人番号を含む個人情報の取得は、端末７から受信することで取得する方法に限定されない。例えば、顧問先によって個人番号を記載した紙を、図示しないＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅａｄｅｒ）等の光学式文字読取装置を用いて読み取ってデータ化したものを取得してもよい。また、顧問先にて個人番号を記載した用紙を会計事務所で受け取り、データ化は端末７で行ってもよいし、会計処理装置１で行ってもよい。

Ｓ１１において、個人情報制御部１１（情報登録部１４）は、個人情報の整合性確認を行う。個人情報制御部１１は、個人情報の内容が全て揃っているか、また、会社コード及び社員番号が顧問先ＤＢ３５に登録されているか等を確認する。
顧問先ＤＢ３５は、図５に示すように、会社テーブル３５ａと、社員テーブル３５ｂとを記憶している。図５（Ａ）に示す会社テーブル３５ａは、顧問先に関する情報を記憶したものである。また、図５（Ｂ）に示す社員テーブル３５ｂは、顧問先の社員に関する情報を記憶したものである。

図４に戻り、Ｓ１２において、個人情報制御部１１（情報登録部１４）は、アクセスキーを生成する。アクセスキーとは、会社コードと社員番号とに基づいて一意に定まる情報をいう。よって、アクセスキーは、個人番号を特定可能な情報である。なお、アクセスキーは、個人番号と混同されないようにするために、個人番号とは異なる構成であることが望ましい。具体的には、個人番号は、０〜９の数字の羅列であるので、アクセスキーは、英字や記号等を含む情報にするとよい。アクセスキーをこのようにすることで、アクセスキーから容易に個人番号を特定できないものにできる。
なお、アクセスキーとして、直接に会社コードと社員番号を用いるようにしてもよい。
また、実施例では、アクセスキーとして、上記情報を使用しているが、個人を特定できる情報であれば他の情報でもよい。
Ｓ１３において、個人情報制御部１１（情報登録部１４）は、個人情報と、アクセスキーとを、特定個人情報ＤＢ３３に記憶させる。その際、個人情報制御部１１（ログ処理部２１）は、アクセスログを取得して、ログＤＢ３７に記憶させる。

特定個人情報ＤＢ３３は、図６に示すように、特定個人番号テーブル３３ａと、使用許諾テーブル３３ｂと、アクセスキーテーブル３３ｃとを記憶している。
図６（Ａ）に示す特定個人番号テーブル３３ａは、アクセスキーと、個人番号とを対応付けたテーブルである。顧問先企業自身で従業員の個人番号を管理する場合や、複数の顧問先を集中管理する場合には、特定個人番号テーブル３３ａは、図６（Ａ−１）に示すように１つであるのに対し、複数の顧問先を分散管理する場合には、特定個人番号テーブル３３ａは、図６（Ａ−２）に示すように顧問先企業の数であるＮ個になる。
図６（Ｂ）に示す使用許諾テーブル３３ｂは、会社コード及び社員番号と、使用許諾を受けた業務名とを対応付けたテーブルである。なお、会社コードのみが入力されているものは、その会社コードの全社員について、同一の許諾を受けている場合である。また、業務名は、一例である。例えば、「給与」と「年末調整」とを１つの業務としてもよい。複数の顧問先を集中管理する場合には、使用許諾テーブル３３ｂのようになる。
そして、使用許諾テーブルも、集中管理する場合における図６（Ｂ）に示す使用許諾テーブル３３ｂとは異なり、顧問先企業ごとに分離して管理する分散管理の場合には、図６（Ｄ）に示す使用許諾テーブル３３ｄのように、会社コードごとに別々のテーブルとして管理することができる。
なお、顧問先企業自身で従業員の個人番号を管理する場合には、図６（Ｄ）に示す使用許諾テーブル３３ｄの会社コードが００１のテーブル１個のみになる。また、複数の顧問先企業を分散管理する場合には、使用許諾テーブル３３ｄのように、使用許諾テーブルが顧問先企業の数であるＮ個になる。そして、例えば（実際にはまれであるが）、会社コード「００１」の社員番号「０００１」の社員と、社員番号「０００２」の社員とでは、業務単位での異なった使用許諾管理も行えるものである。
図６（Ｃ）に示すアクセスキーテーブル３３ｃは、会社コード及び社員番号と、アクセスキーとを対応付けたテーブルである。顧問先企業の場合や複数の顧問先を集中管理する場合には、アクセスキーテーブル３３ｃは、図６（Ｃ−１）に示すように１つであるのに対し、複数の顧問先を分散管理する場合には、アクセスキーテーブル３３ｃは、図６（Ｃ−２）に示すように顧問先企業の数であるＮ個になる。

なお、ここで説明した集中管理と分散管理との違いは、換言すると、図６のような各種管理テーブルや顧問先毎の社員の個人番号等を記録した領域の管理の方式の違いを主とするが、これに限られるわけではない。
例えば、各種管理テーブルや顧問先毎の社員の個人番号を記録した領域の管理の方式の例としては、１つのサーバの中の１つのディスク装置に集中して記録されている場合と、複数のディスク装置に分散して記録されている場合や、１つのサーバの中の１つのディスク装置の所定のディレクトリに集中的に記録されている場合と、複数のディレクトリに分散して記録されている場合等がある。あるいは、以上のような物理的な領域の意味合いを含む管理方式の区別の他にも、ある種の論理的な領域の意味合いを含む管理方式の区別として、顧問先毎、業務ごとに、アクセスキーや個人番号の記録領域を割当てて管理することについて分散管理と呼ぶこともできる。例えば、業務（アプリ）ごとにアクセスキーや個人番号の記録領域を管理したり、さらに業務（アプリ）毎かつ顧問先ごとにアクセスキーや個人番号の記録領域を管理する場合も、分散管理の一例である。
なお、複数の企業（の従業員）の個人番号を預かって管理するサービスを行うＩＤＣ（インターネットデータセンター）のサーバ（クラウドや仮想マシン含む）の場合にも、顧問先企業が複数ある場合の例を適用できる。
また、企業の本社等が各部門や各支店（の従業員）等を対象にマイナンバーの管理を行う場合には、顧問先企業に代えて、企業の各部門や各支店に対するサービスに読み替えることで、本発明を適用可能である。

個人情報制御部１１は、Ｓ１２において生成したアクセスキーと、Ｓ１０において取得した個人情報に含まれる個人番号とを対応付けて、特定個人番号テーブル３３ａに記憶させる。また、個人情報制御部１１は、アクセスキーと、アクセスキーの生成元である会社コード及び社員番号とを対応付けて、アクセスキーテーブル３３ｃに記憶させる。さらに、個人情報制御部１１は、Ｓ１０において取得した個人情報に含まれる使用許諾情報に対応する業務名と、会社コード及び社員番号とを、使用許諾テーブル３３ｂに記憶させる。

図４に戻り、Ｓ１４において、個人情報制御部１１（情報登録部１４）は、特定個人情報ＤＢ３３に記憶されている個人番号を暗号化する。図６（Ａ）に示す特定個人番号テーブル３３ａは、暗号化されていないが、実際には暗号化された個人番号が記憶される。そうすることで、特定個人番号テーブル３３ａに対して不正アクセスがあった場合でも、個人番号を特定できないので、個人番号のセキュリティが向上する。その後、個人情報制御部１１は、本処理を終了し、図３に移す。なお、特定個人番号テーブル３３ａに暗号化した個人情報を保存した上で無効化し、正規のアクセスがあった場合のみ有効化するようにしてもよい。

＜業務アプリ利用処理＞
次に、業務アプリ利用処理について説明する。
図７は、本実施形態に係る会計処理装置１での業務アプリ利用処理のフローチャートである。
図８は、本実施形態に係る業務処理データＤＢ３６の例を示す図である。
図９は、本実施形態に係るログＤＢ３７の例を示す図である。
図７のＳ２０において、会計処理装置１の個人情報制御部１１（情報利用部１５）は、図示しない業務画面にしたがって、業務処理データを出力し、ユーザによる選択を受け付ける。

ここで、業務処理データについて、図８に基づき説明する。
図８に示すように、業務処理データは、業務処理データＤＢ３６の業務処理データテーブル３６ａに記憶されている。業務処理データテーブル３６ａには、業務アプリ３２による業務処理を行った業務処理データと、業務処理を行っていない業務処理データとが混在して記憶されている。端末７から受信した業務処理データは、制御部１０によって、所定の格納先に格納される。個人情報制御部１１は、業務処理データＤＢ３６にレコードを追加し、業務コード、業務名、年度を入力し、業務処理データ格納先を追加する。また、アクセスキーは、会社コード及び社員番号から生成して追加される。なお、申告済フラグは０の場合が未申告で、１の場合が申告済みを意味するフラグである。しかし、実際に国税庁に申告を行っていない場合でも、申告データの作成が完了した時点で、申告済フラグを１としてもよい。そういう意味で、申告済フラグは、国税庁に申告するデータのみならず、給与アプリケーション等の必ずしも国税庁に申告しないデータの作成完了を示すフラグであってもよい。
そして、業務処理を行っている場合には、業務処理データに対応する帳簿データ格納先に、データが入っている。
そこで、個人情報制御部１１は、処理を行っていない、つまり、帳簿データ格納先がブランクの業務処理データを出力する。

Ｓ２１において、個人情報制御部１１（情報利用部１５）は、選択された業務処理データに対応する業務アプリ３２を呼び出す。これにより、業務アプリ制御部２５は、呼び出された業務アプリ３２を実行する。そして、業務アプリ３２では、その業務アプリ３２において個人番号が必要である場合には、依頼データ（依頼情報）を出力する。依頼データは、アクセスキーを含み、個人番号を要求するデータである。

Ｓ２２において、個人情報制御部１１（アプリ判別部１６）は、実行した業務アプリ３２で個人番号の使用が可能であるか否かを判断する。個人情報制御部１１は、業務処理データのアクセスキー（図８）に基づいて、特定個人情報ＤＢ３３のアクセスキーテーブル３３ｃ（図６（Ｃ））を参照し、会社コードと社員番号とを得る。次に、個人情報制御部１１は、使用許諾テーブル３３ｂ（図６（Ｂ））を参照し、実行した業務アプリ３２に対応する個人番号の使用許諾の有無を判断する。そして、個人番号の使用許諾がされている場合には、個人番号の使用が可能であると判断する。他方、使用許諾テーブル３３ｂにおいて使用許諾がされていない場合や、そもそも個人番号を使用しない業務アプリ３２である場合には、個人番号の使用が可能ではないと判断する。個人番号の使用が可能である場合（Ｓ２２：ＹＥＳ）には、個人情報制御部１１は、処理をＳ２３に移す。他方、個人番号の使用が可能ではない場合（Ｓ２２：ＮＯ）には、個人情報制御部１１は、処理をＳ２３ａに移す。

Ｓ２３において、個人情報制御部１１（情報利用部１５）は、業務アプリ３２から依頼データを受け付けたか否かを判断する。依頼データを受け付けた場合（Ｓ２３：ＹＥＳ）には、個人情報制御部１１は、処理をＳ２４に移す。他方、依頼データを受け付けていない場合（Ｓ２３：ＮＯ）には、個人情報制御部１１は、業務アプリ３２から依頼データが出力されるのを待つ。
他方、Ｓ２３ａにおいて、個人情報制御部１１は、個人番号を出力しない旨のメッセージを業務画面に出力する。その後、個人情報制御部１１は、本処理を終了し、図３に移す。つまり、個人番号を使用しない業務アプリ３２である場合には、個人情報制御部１１がメッセージを出力しつつ、業務アプリ制御部２５が業務アプリ３２の処理を行う。
なお、個人番号が必要であるが使用許諾がされていない場合には、個人情報制御部１１は、使用許諾がされていない旨のエラーメッセージを出力して、処理を終了させてもよい。

Ｓ２４において、個人情報制御部１１（情報利用部１５）は、特定個人情報ＤＢ３３から依頼データに対応する個人番号を取得する。個人情報制御部１１は、依頼データに含むアクセスキーに基づいて、特定個人番号テーブル３３ａ（図６（Ａ））から個人番号を取得する。ここで取得する個人番号は、暗号化されている。
なお、上述のように、分散管理の場合には、個人番号について業務（アプリ）毎や顧問先企業ごとに分散して管理可能であるので、個人番号の読出しは、必ずしも特定個人情報ＤＢ３３からではなく、分散管理された個人番号の格納領域から読み出すようにしてもよい。
また、個人情報制御部１１は、依頼データが、アクセスキーではなく、会社コード及び社員番号や個人番号を含んだものである場合に、該当の個人番号を無効化してもよい。そのようにすることで、業務アプリ３２になりすました不正なアプリからの依頼データに対しては、個人番号に対する処理を行わないだけでなく、無効化することで個人番号のセキュリティを向上できる。

Ｓ２５において、個人情報制御部１１（個人番号出力部１７）は、個人番号を業務アプリ３２に出力する。こうすることで、業務アプリ制御部２５は、個人番号を受け付けて暗号化された個人番号を復号し、個人番号と業務処理データとを使用して帳簿データを作成する。帳簿データは、例えば、申告書や帳簿等のデータ、その他のアプリデータ（給与アプリのデータ等）である。そして、業務アプリ制御部２５は、作成した帳簿データを、紙で出力したり、ＰＤＦ（登録商標）等の電子書類にして出力する。
なお、ここで出力された電子書類は、会計処理装置１が、通信ネットワークＮを介して国税庁のサーバ８に送信する。そうすることで、国税庁では、電子書類に基づいて、納税処理等を行うことができる。

また、業務アプリ制御部２５は、例えば、電子書類を出力してサーバ８に送信したことに応じて、個人情報制御部１１に対して通知することで、個人情報制御部１１は、業務処理データＤＢ３６の該当の帳簿データの申告済フラグを０から１に変更する。
そして、個人情報制御部１１は、申告済フラグが１である帳簿データに対しては、以降の処理において（個人番号部分の）印刷等を行えないように制御することもできるし、アプリデータの作成完了済み、ないし申告済みである以上、個人番号等の個人情報を表示して確認する必要もないので、後掲のように無効化したりすることができる。

Ｓ２６において、個人情報制御部１１（ログ処理部２１）は、特定個人情報ＤＢ３３へのアクセスログをログＤＢ３７に出力する。
図９は、ログＤＢ３７の例を示す。ログＤＢ３７は、図９（ａ）に示すアクセスログテーブル３７ａと、図９（ｂ）に示す個人番号管理ログ３７ｂとを記憶している。アクセスログテーブル３７ａは、個人情報管理アプリ３１ａが特定個人情報ＤＢ３３の特定個人番号テーブル３３ａに対してアクセスした際のログを記憶する。よって、個人情報制御部１１は、アクセスログテーブル３７ａにアクセスログを追加する。アクセスログテーブル３７ａは、上述のログ以外に上記アクセスした個人番号に関するログ（業務アプリ３２が管理するログや、バックアップログ等の個人番号が含まれる処理を行ったログも含む。）も記憶してもよい。個人番号管理ログ３７ｂは、後述するユーザテーブル３４ａで管理されるユーザが処理した個人番号に関する管理ログであり、ユーザが誰の個人番号にアクセスしたかを管理し、個人番号への不正なアクセスを防止することになり、セキュリティが向上する。

Ｓ２７において、個人情報制御部１１（業務データ処理部２０）は、業務アプリ３２が出力した帳簿データを、業務処理データＤＢ３６に記憶させる。その際、個人情報制御部１１（業務データ処理部２０）は、業務アプリ３２が出力した帳簿データに含まれる個人番号を、アクセスキーに変更して、帳簿データ格納先に記憶させる。このようにすることで、業務処理データＤＢ３６を参照して帳簿データが不用意に流出しても、個人番号が特定されることがない。なお、帳簿データを作成した際に、個人情報制御部１１は、その帳簿データに関する保有期限情報を、記憶部３０に記憶させる。
Ｓ２８において、個人情報制御部１１（ログ処理部２１）は、帳簿データの作成に関するログを、ログＤＢ３７に出力する。個人情報制御部１１は、個人番号管理ログ３７ｂに帳簿データの作成ログを追加する。また、個人情報制御部１１は、業務アプリ３２によって個人番号を使用した紙やＰＤＦを作成した場合に、業務アプリ３２からその情報を取得してアクセスログテーブル３７ａに記憶する。その後、個人情報制御部１１は、本処理を終了し、処理を図３に移す。

＜個人番号照会処理＞
次に、個人番号照会処理について説明する。
図１０は、本実施形態に係る会計処理装置１での個人番号照会処理のフローチャートである。
図１１は、本実施形態に係るユーザＤＢ３４の例を示す図である。
図１２は、本実施形態に係る表示部４６の例を示す図である。
図１０のＳ３０において、図示しない業務画面からユーザによる個人番号を含むデータ表示の選択を受け付けることで、会計処理装置１の個人情報制御部１１（情報利用部１５）は、ユーザＤＢ３４を参照し、ユーザが個人番号表示に関する権限を有するか否かを判断する。

ここで、ユーザＤＢ３４について、図１１に基づき説明する。ユーザＤＢ３４（担当者権限記憶部）は、ユーザテーブル３４ａを記憶している。ユーザテーブル３４ａは、ユーザＩＤと、ユーザに関する情報として、ユーザ名等と、個人番号表示及び個人番号管理に関する権限とを対応付けたテーブルである。
個人情報制御部１１は、このユーザテーブル３４ａを参照し、ユーザが個人番号表示の権限を有するか否かを判断する。個人番号表示の権限を有するユーザである場合（Ｓ３０：ＹＥＳ）には、個人情報制御部１１は、処理をＳ３１に移す。他方、個人番号表示の権限を有さないユーザである場合（Ｓ３０：ＮＯ）には、個人情報制御部１１は、本処理を終了し、処理を図３に移す。なお、その際、個人情報制御部１１は、個人番号表示権限がないため、表示できない旨のメッセージを出力してもよい。
図１０のＳ３１において、個人情報制御部１１（情報利用部１５）は、個人番号を有するデータを、該当のＤＢから取得する。

Ｓ３２において、個人情報制御部１１は、画面データを生成して、表示部４６に表示させる。
図１２（Ａ）は、表示部４６に表示された個人番号選択画面５０の例を示す。個人番号は、ボタン５０ａが表示されており、個人番号が表示されていない。
そして、ユーザは、個人番号の表示が必要なレコードのボタン５０ａを選択することで、個人情報制御部１１は、図１２（Ｂ）に示すように、そのレコードの個人番号のみを表示させる。よって、必要な個人番号のみを表示させるので、セキュリティが向上する。
なお、本処理においては、ユーザに個人番号に関する表示権限がない場合には、画面表示を行わないものとして説明したが、ボタン５０ａ自体を無効化した状態で画面表示を行ってもよいし、個人番号をマスク処理等による非表示にした状態で画面表示してもよい。
その後、個人情報制御部１１は、本処理を終了し、処理を図３に移す。

＜個人番号無効化処理＞
次に、個人番号無効化処理について、図１３に基づき説明する。
図１３は、本実施形態に係る会計処理装置１での個人番号無効化処理のフローチャートである。
図１３のＳ７０において、個人情報制御部１１（情報管理部１８）は、業務処理データＤＢ３６にアクセスキーを有する帳簿データがあるか否かを判断する。業務処理データＤＢ３６にアクセスキーを有する帳簿データがある場合（Ｓ７０：ＹＥＳ）には、個人情報制御部１１は、処理をＳ７１に移す。他方、業務処理データＤＢ３６にアクセスキーを有する帳簿データがない場合（Ｓ７０：ＮＯ）には、個人情報制御部１１は、本処理を終了する。
Ｓ７１において、個人情報制御部１１は、顧問先ＤＢ３５（図５）を参照し、帳簿データに対応する顧問先が継続的な契約先であるか否かを判断する。継続的な契約先である場合（Ｓ７１：ＹＥＳ）には、個人情報制御部１１は、処理をＳ７３に移す。他方、継続的な契約先ではない場合（Ｓ７１：ＮＯ）には、個人情報制御部１１は、処理をＳ７２に移す。
Ｓ７２において、個人情報制御部１１は、顧問先ＤＢ３５を参照し、顧問契約が終了済であるか否かを判断する。顧問契約が終了済である場合（Ｓ７２：ＹＥＳ）には、個人情報制御部１１は、処理をＳ７４に移す。他方、顧問契約が終了済ではない場合（Ｓ７２：ＮＯ）には、個人情報制御部１１は、処理をＳ７３に移す。

Ｓ７３において、個人情報制御部１１は、業務処理データＤＢ３６を参照し、同一のアクセスキーを有する帳簿データに対応する申告済フラグが全て１であるか否かを判断する。同一のアクセスキーを有する帳簿データの申告済フラグが全て１である場合（Ｓ７３：ＹＥＳ）には、個人情報制御部１１は、処理をＳ７４に移す。他方、同一のアクセスキーを有する帳簿データの申告済フラグが全て１ではない場合（Ｓ７３：ＮＯ）には、個人情報制御部１１は、本処理を終了する。
Ｓ７４において、個人情報制御部１１（個人情報処理部１９）は、特定個人情報ＤＢ３３の該当の個人番号を無効化にする。この処理では、帳簿データを既に提出済である場合や、顧問契約が終了した顧問先の個人番号を無効化する。その後、個人情報制御部１１は、本処理を終了し、処理を図３に移す。

＜削除処理＞
次に、削除処理について説明する。
個人番号を削除するのは、顧問先との顧問契約が終了した場合や、顧問先企業の従業員が退職した場合のほか、単年度契約や１つの業務の依頼だけを請け負うスポット業務の場合、ある帳表の保有期限を経過して、その帳表に係る個人番号を保有しておく理由がなくなった場合等がある。
ここで、契約終了した場合における削除処理ルーチンの起動条件としては、削除権限を有する担当者が、上記の契約が終了等したことを把握して、随時、削除処理を起動するほか、上記の契約が終了等したことの入力を受け付ける手段を設けて、契約関係の管理テーブル等に記録し、削除条件を監視するプログラムが当該管理テーブルをサーチして、削除処理を起動するようにしてもよい。

他方、帳表の保有期限が経過した場合における削除処理ルーチンの起動条件としては、いちいち担当者が多数の顧問先の複数の税目毎、年度ごとの帳表の保有期限を把握することは困難なので、後述のように、保有期限情報を記録したテーブル（図１６（Ａ）参照）を用意し、担当者が随時、削除処理の起動を行うと、図１５の処理フローを実行するようにしてもよいし、保有期限に係る削除条件を監視するプログラムが保有期限情報を記録したテーブル（図１６（Ａ）参照）をサーチして、削除処理を起動するようにしてもよい。あるいは、保有期限に係る削除処理は、保有期限経過後速やかに行えば足りるので、顧問先の業務処理のために業務アプリを起動する度や、業務アプリを終了する度でもよいし、月末等の月次（監査）処理の際や、顧問先の会計年度の終了する月の末日や翌月の初日等に起動するようにしてもよい。

図１４は、本実施形態に係る会計処理装置１での削除処理のフローチャートである。
図１５は、本実施形態に係る会計処理装置１での削除対象リスト作成処理のフローチャートである。
図１６は、本実施形態に係る会計処理装置１の記憶部３０に記憶されるデータの例を示す図である。
図１７は、本実施形態に係る会計処理装置１でのデータ削除処理のフローチャートである。

図１４のＳ４０において、会計処理装置１の個人情報制御部１１（情報利用部１５）は、ユーザＤＢ３４のユーザテーブル３４ａ（図１１）を参照し、ユーザが個人番号管理に関する権限を有するか否かを判断する。個人番号管理の権限を有するユーザである場合（Ｓ４０：ＹＥＳ）には、個人情報制御部１１は、処理をＳ４１に移す。他方、個人番号管理の権限を有さないユーザである場合（Ｓ４０：ＮＯ）には、個人情報制御部１１は、本処理を終了し、処理を図３に移す。なお、その際、個人情報制御部１１は、個人番号管理権限がないため、削除処理ができない旨のメッセージを出力してもよい。
Ｓ４１において、個人情報制御部１１は、削除対象リスト作成処理を行う。
ここで、削除対象リスト作成処理について、図１５に基づき説明する。
図１５のＳ５０において、会計処理装置１の個人情報制御部１１は、記憶部３０に記憶されている保有期限情報を取得する。保有期限情報は、図１６（Ａ）に示す情報であり、業務アプリ３２による帳簿データの作成時に、記憶部３０に記憶されている（図７のＳ２７参照）。
Ｓ５１において、個人情報制御部１１は、業務処理データＤＢ３６を参照して１つの帳簿データを取得する。

Ｓ５２において、個人情報制御部１１（情報管理部１８）は、記憶部３０の保有期限情報を参照し、取得した帳簿データの保有期限が経過したか否かを判断する。保有期限が経過している場合（Ｓ５２：ＹＥＳ）には、個人情報制御部１１は、処理をＳ５４に移す。他方、保有期限が経過していない場合（Ｓ５２：ＮＯ）には、個人情報制御部１１は、処理をＳ５３に移す。ここで、帳簿データは、その種類によって保有期限が定められている。
Ｓ５３において、個人情報制御部１１は、顧問先ＤＢ３５（図５）を参照し、顧問契約が終了しているか否かを判断する。顧問契約が終了している場合（Ｓ５３：ＹＥＳ）には、個人情報制御部１１は、処理をＳ５４に移す。他方、顧問契約が終了していない場合（Ｓ５３：ＮＯ）には、個人情報制御部１１は、処理をＳ５５に移す。
なお、Ｓ５３は、会計事務所と顧問先との顧問契約内容（各種契約条件）に照らし合わせて行うことが可能な処理であり、その条件は、「顧問契約が終了したか」「代理人契約でないか」等がある。

Ｓ５４において、個人情報制御部１１（消去対象生成出力部２２）は、該当の帳簿データ（消去対象情報）を、削除対象リスト（項目）に追加する。削除対象リスト（項目）の例を、図１６（Ｂ）に示す。削除対象リスト（項目）は、保有期限情報に削除欄が追加されたものである。
Ｓ５５において、個人情報制御部１１は、全ての帳簿データに対して処理を行ったか否かを判断する。全ての帳簿データに対して処理を行った場合（Ｓ５５：ＹＥＳ）には、個人情報制御部１１は、処理をＳ５６に移す。他方、全ての帳簿データに対して処理を行っていない場合（Ｓ５５：ＮＯ）には、個人情報制御部１１は、処理をＳ５１に移し、未処理の帳簿データに対して繰り返し処理を行う。

Ｓ５６において、個人情報制御部１１は、削除対象リスト（項目）が作成されたか否かを判断する。削除対象リスト（項目）が作成された場合（Ｓ５６：ＹＥＳ）には、個人情報制御部１１は、表示部４６に対して削除対処リスト（項目）が作成された旨のメッセージを出力（通知）し（Ｓ５７）、本処理を終了して、処理を図１４に移す。他方、削除対象リスト（項目）が作成されなかった場合（Ｓ５６：ＮＯ）には、個人情報制御部１１は、本処理を終了して、処理を図１４に移す。
なお、ユーザがメッセージを確認した後に、削除対象リスト（項目）の表示を行う操作をすることで、表示部４６には、図１６（Ｂ）に示す削除対象リスト（項目）を表示できる。
そして、ユーザは、削除対象リスト（項目）を見て、データの削除を手動で行うこともできる。

図１４に戻り、Ｓ４２において、個人情報制御部１１は、データ削除処理を行う。
ここで、データ削除処理について、図１７に基づき説明する。
図１７のＳ６０において、個人情報制御部１１は、削除対象リスト（項目）が作成されているか否かを判断する。削除対象リスト（項目）が作成されている場合（Ｓ６０：ＹＥＳ）には、個人情報制御部１１は、処理をＳ６１に移す。他方、削除対象リスト（項目）が作成されていない場合（Ｓ６０：ＮＯ）には、個人情報制御部１１は、本処理を終了する。
Ｓ６１において、個人情報制御部１１は、削除対象リスト（項目）に基づいて業務処理データＤＢ３６から削除対象の帳簿データを取得する。
Ｓ６２において、個人情報制御部１１（業務データ処理部２０）は、取得した削除対象の帳簿データ（消去対象情報）のアクセスキー（データ出力情報）を削除する。削除処理として、具体的には、個人情報制御部１１は、業務処理データＤＢ３６のアクセスキーをＮＵＬＬにする。アクセスキーを削除（ＮＵＬＬに変更）することで、個人番号へのアクセスができないようになる。なお、顧問先契約が終了し、当該個人番号を使用した帳簿データの保有期限が全て経過している場合には、当該個人番号も削除する。また、個人情報制御部１１（ログ処理部２１）は、アクセスログを取得して、ログＤＢ３７に記憶させる。

Ｓ６３において、個人情報制御部１１は、削除対象リスト（項目）から１つのリストが選択されたか否かを判断する。これは、削除対象リスト（項目）が表示部４６に表示され、リストが選択可能になっている状態で、ユーザが１つのリストを選択したか否かを個人情報制御部１１が判断する。１つのリストが選択された場合（Ｓ６３：ＹＥＳ）には、個人情報制御部１１は、処理をＳ６４に移す。他方選択されなかった場合（Ｓ６３：ＮＯ）には、個人情報制御部１１は、本処理を終了する。
Ｓ６４において、個人情報制御部１１（消去関連生成出力部２３）は、選択された１つのリストに関して、削除対象リスト（詳細）（消去関連情報）を作成する。図１６（Ｃ）は、削除対象リスト（詳細）の例を示す。削除対象リスト（詳細）には、ＮＵＬＬデータ（上述の削除対象の帳簿データ）、ＰＤＦデータや、バックアップデータ（後述する）の他に、データとしてではなく、紙等で出力されたものに関するものをも含む。個人情報制御部１１は、削除対象リスト（詳細）を、ログＤＢ３７を参照して作成する。
Ｓ６５において、個人情報制御部１１は、表示部４６に対して削除対処リスト（詳細）が作成された旨のメッセージを出力（通知）した後、本処理を終了する。

なお、このデータ削除処理において、個人情報制御部１１は、業務処理データＤＢ３６から削除対象の帳簿データを取得して、取得した削除対象の帳簿データのアクセスキーを自動的に削除するものとして説明したが、これに限定されない。例えば、表示部４６に表示された削除対象リスト（項目）から１つのリストを選択することで、削除対象リスト（詳細）を作成した後に、ユーザがリストを選択して、削除指示をすることで、手動で削除するようにしてもよい。
また、このデータ削除処理において、個人情報制御部１１は、削除対象リスト（詳細）を作成するものとして説明したが、削除対象リスト（詳細）を作成した後に、個人情報制御部１１は、データとして記憶部３０に記憶された該当のデータを自動的に削除してもよい。
実施例では、削除対象リスト（項目）から１つのリストを選択した場合を記載しているが、複数対象が存在する場合は、複数のリストを選択するようにしてもよい。

＜データバックアップ＞
次に、データバックアップについて説明する。
図１８は、本実施形態に係る会計処理装置１での記憶部３０に記憶されたバックアップ管理テーブルの例を示す図である。
会計処理装置１の制御部１０は、図１８のバックアップ管理テーブルに示すように、個人番号を含むＤＢのバックアップデータを適宜取得して記憶する。個人番号を含むＤＢは、特定個人情報ＤＢ３３である。また、個人番号を直接に含まないが、個人番号に対応するアクセスキーや、会社コード及び社員番号を有するデータであって、随時更新されるデータを含む業務処理データＤＢ３６及びログＤＢ３７に関してもバックアップデータを取得する。
バックアップデータは、上述のように、個人番号を含むものであるので、削除データの対象になりうる（図１６（Ｃ）参照）。

＜他の実施形態＞
上述した実施形態では、顧問先企業での従業員に関する個人番号管理や会計事務所において、顧問先企業の情報を１つのＤＢで集中管理する場合について説明したが、ここでは、会計事務所が個人番号を顧問先ごとに管理する場合において、分散管理する場合について説明する。
上述した実施形態と、分散管理による処理とが異なるのは、メイン処理及び削除処理の２点である。

図１９は、他の実施形態に係る会計処理装置１での個人情報管理メイン処理のフローチャートである。
基本的なメイン処理（Ｓ２０１からＳ２０９まで）については、図３に示す処理（Ｓ１からＳ９まで）と同じなので、異なる部分のみを説明する。
図３との違いは、図３の場合は、１つのＤＢに全ての顧問先の個人番号が管理されているため、１度のメイン処理で済むのに対し、図１９では、顧問先ごとにメイン処理（図３記載の処理）を、顧問先の数（Ｎ個）だけループ処理を行う（Ｓ２００及びＳ２１０）。

図２０は、他の実施形態に係る会計処理装置１での削除処理のフローチャートである。
基本的な削除処理（Ｓ２４０からＳ２４２まで）については、図１４に示す処理（Ｓ４０からＳ４２まで）と同じなので、異なる部分のみを説明する。
図１４との違いは、図１４の場合は、１つのＤＢに全ての顧問先の個人番号が管理されているため、１度のメイン処理で済むのに対し、図２０では、顧問先ごとにメイン処理（図１４記載の処理）を、顧問先の数（Ｎ個）だけループ処理を行う（Ｓ２４０ａ及びＳ２４３）。

他の実施形態の削除処理の場合は、顧問先ごとに削除対象を選択して行う（フローチャートとしては、Ｓ２４０ａ→Ｓ２４０→Ｓ２４１→Ｓ２４３）が、最初に図１５の削除対象リスト作成処理を顧問先ごとに一括で作成し、複数の顧問先の削除対象リスト（項目）の削除対象を全て選択してから削除処理（フローチャートとしては、Ｓ２４０ａ→Ｓ２４２→Ｓ２４３）を行ってもよい。同様に、図１７のデータ削除処理のうち、削除対象リスト（詳細）の作成処理（Ｓ６３〜Ｓ６５）を顧問先ごとに一括で作成してもよい。

このように、実施形態の会計処理装置１によれば、以下のような効果がある。
（１）個人番号の取得、利用、保管及び廃棄の処理を適宜行うことで、個人番号の取得、利用、保管及び廃棄を厳正に行うことができる。
（２）個人番号と共に使用許諾情報を取得するので、個人番号を一度取得すれば、その後の業務において、同意を得るための手続をとる必要なく使用できる。よって、個人番号を業務で使用する度に、使用の同意を得る手間を省くことができる。

（３）個人番号に関する処理や、特定個人情報ＤＢ３３へのアクセスに関するログを取得するので、個人番号に関する全てのログを取得してログＤＢ３７に記憶させることができる。よって、トレーサビリティが容易である。
（４）顧問先契約が終了したり、保存期限が経過した場合には、個人番号を無効化するので、個人番号の廃棄を、的確に行うことができる。
（５）電子書類を送信後の帳簿データは、法定期限内は保管する必要があるが、個人番号を取得できないようにすることで、セキュリティが向上する。
（６）個人番号を無効化した場合であっても、必要に応じて有効にできる。よって、以前契約していた顧問先と再度契約をした場合等に、以前の情報を利用できる。

以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限定されるものではない。また、実施形態に記載した効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、実施形態に記載したものに限定されない。なお、上述した実施形態及び後述する変形形態は、適宜組合せて用いることもできるが、詳細な説明は省略する。

（変形形態１）
（１）実施形態では、使用許諾情報に、許諾する業務の業務名を含むものとして説明したが、これに限定されない。複数業務を行わず、１つの業務を行うものであれば、個人番号に関する使用許諾情報であればよく、業務名を含む必要がない。
（２）実施形態では、個人番号の無効化を、既に顧問契約が終了した顧問先の個人番号と、同一アクセスキーの業務処理データの申告済フラグが全て１の場合のアクセスキーに対応する個人番号とに対して行うものとして説明したが、これに限定されない。例えば、保有期限が経過したことに応じて、個人番号を無効化してもよい。
（３）実施形態では、アクセスキーテーブルとして、会社コード及び社員番号に対応するアクセスキーを記憶するものとして説明した。しかし、社員の家族を含む場合も考えられる。そして、社員の家族にも個人番号が付与される。その場合には、会社コード、社員番号及び続柄に関する続柄コードに対応するアクセスキーを記憶すればよい。

（４）実施形態では、業務処理データＤＢには、個人番号を有さずにアクセスキーを記憶するものとして説明したが、これに限定されない。アクセスキーの代わりに、会社コード及び社員番号を記憶してもよい。そうすることで、個人番号に対応するアクセスキーも記憶せずに済むので、よりセキュリティが向上する。
（５）実施形態では、会計処理装置に対してユーザがオンラインで操作を行うものとして説明したが、これに限定されない。オフラインで作業をした場合であっても、個人番号に関するログを取得しておき、会計処理装置とオンラインになったときに、取得したログを会計処理装置に送信することで、会計処理装置では、ログ記憶部にそのログを記憶してもよい。
（６）実施形態では、会計処理装置は、会計事務所内に有するものとして説明したが、これに限定されない。例えば、会計処理装置のアプリを開発している企業に会計処理装置１の機能を有するサーバを設け、このサーバに会計事務所のコンピュータが接続されることで実現してもよい。
（７）実施形態では、個人情報管理メイン処理が、図３のフローチャートのように一連の処理として説明したが、これに限定されない。例えば、業務アプリ利用処理や削除処理等を個別に処理したり、組合せたりしてもよい。

（変形形態２）
この変形形態２で説明するものは、個人番号を記載した出力物について、ファイル等の電子情報で管理しているものだけでなく、印刷したものはＰＤＦにして出力先を全て把握した上で、さらにその出力先の出力物の変更等の操作を含めた全ての処理のログをとり、出力した担当者が削除処理（削除フラグを立てる）を終えない限り、消去期限が来たときに個人番号の削除処理されていない出力物がある場合は、警告等で担当者に知らせ、担当者に確実に出力物を削除又は個人番号部分の抹消をさせる（ログも取る）までの履歴を含めたシステムである。
これは、処理データ等の個人情報管理システムからみたときのオンラインでの管理に対し、印刷等により出力した紙等の個人情報管理システムからみたときのオフラインでの「紙媒体、ＰＤＦ（所定のフォルダ等に格納）、ＣＤＲＯＭ等の記録媒体に焼いたＰＤＦ等のデータ」等（以後、出力媒体とする）については、従来は個人情報ＤＢで管理されず、アクセス管理もされていないケースが多いため、出力された後に削除期限が来た場合等が来ても出力媒体の場所等をわからなくて、削除漏れが発生するので、出力媒体の管理、変更、移動の履歴を含むログ情報を取ることで、それ自体を確実に削除させたり、削除状況を追跡できる。
このオフラインでの「紙出媒体、ＰＤＦ、ＣＤＲＯＭ等の記憶媒体に焼いたＰＤＦ」について、アクセス管理されていない環境で、これらを確実に削除させたり、削除状況を追跡できるようなシステムでは、以下の構成を備える。
（１）削除リストには、下記を一覧表示
（ａ）紙媒体（印刷した帳表）、ＰＤＦや電子文書（ＣＤＲＯＭ等の記録媒体に記録したファイル単位）の名称の一覧、
（ｂ）その紙媒体やＰＤＦに含まれる個人番号に係る個人の名前又は社員番号、その個人の組織、
（ｃ）出力媒体の出力年月日及び時間、出力場所（プリンタやＰＣ名称等）、出力者（個人番号の削除権限を有する者を含む）、管理責任者（出力場所の責任者やシステム管理者と個人番号の削除権限を有する者を含む）の情報、
（ｄ）ＰＤＦ出力したものや、印刷出力した帳表のＰＤＦ（印刷したものはＰＤＦ化してある）へのリンク（格納先情報やそのディレクトリも含む）、
（ｅ）紙媒体の場合は、送付した先、保管したバインダーファイルの名称、ロッカーの名称等、
（ｆ）ステータスとして、削除の有無、出力した年月日、削除することが必要になった年月日、その理由（契約解消、文書の保存年限経過）、削除したものは削除した年月日、削除した管理者の氏名やＩＤ、
（ｇ）「１週間以内に削除が必要」に例示される削除期限を設定して、（システム）管理者が出力媒体の出力者又は管理責任者へ削除期限の注意を喚起するための表示、又は直接に出力媒体の出力者又は管理責任者へ削除期限の注意を喚起するための表示を含む注記情報、
（ｈ）削除した結果を入力するチェック欄、
（ｉ）所定の期間内に削除リストのチェック欄（ｈ）の削除結果が入力されていない場合は、（システム）管理者に通知し、未削除出力媒体の出力者又は管理責任者に削除処理を促す旨の注意情報、
（２）以上のログを（システムが自動取得できない場合は必要により入力させて）記録する。
（３）個人番号の削除権限を有する者による、削除完了の入力を求める。
（４）ＰＤＦや電子文書については、ファイルのコピーの履歴や、変更の有無まで記録し、確実に追跡できる。
（５）紙媒体に出力するときは、同時にＰＤＦ化して保存して、どういった帳表であるかの概要を参照可能とする。但し、個人番号の部分は墨付きにして、原則として見られないようにする処理を施してある。
（６）削除処理を指示した場合に、削除ツール（無意味なデータを上書きしてデータ復元できない削除処理）を使用して完全消去する。
なお、削除完了したかのチェックは、削除した担当者がパスワードや認証等の手段でログインした上で行う。データがオンライン上に残っている場合は、同様に認証等でログインして削除指示から削除処理、削除完了チェックまでもログを取り、後から履歴を追って検証することができる。

１ 会計処理装置
１０ 制御部
１１ 個人情報制御部
１２ 取得管理部
１３ 情報取得部
１４ 情報登録部
１５ 情報利用部
１６ アプリ判別部
１７ 個人番号出力部
１７ａ 画面データ出力部
１８ 情報管理部
１９ 個人情報処理部
２０ 業務データ処理部
２１ ログ処理部
２２ 消去対象生成出力部
２３ 消去関連生成出力部
２５ 業務アプリ制御部
３０ 記憶部
３１ａ 個人情報管理アプリ
３２，３２ａ，３２ｂ 業務アプリ
３３ 特定個人情報ＤＢ
３４ ユーザＤＢ
３５ 顧問先ＤＢ
３６ 業務処理データＤＢ
３７ ログＤＢ
４６ 表示部
１００ 会計処理システム

Claims (6)

1. 出力した一意に定まる個人番号を含む紙媒体、ＰＤＦ及びＣＤＲＯＭを含む可搬型記録媒体に焼いたＰＤＦのうち少なくとも１つである出力媒体について、前記出力媒体に含まれた個人番号について削除条件を満たす場合に、オフライン環境で、前記出力媒体の削除状況を追跡し、確実に削除したかどうかまでを管理する個人情報管理システムであって、
   一意に定まる個人番号と、業務を識別する業務識別情報が対応付けられた前記個人番号の使用に関する使用許諾情報とを含む個人情報と、企業や事務所の組織を識別する企業識別情報とを対応付けて特定個人情報記憶部に記憶させる個人情報記憶制御手段と、
   個人番号を含む帳表を、紙媒体、ＰＤＦ形式を含む出力媒体で出力する場合に、出力した出力媒体に関する情報を記録すると共に、出力媒体に対する管理、変更、移動、削除の履歴を含むログ情報を記録する、出力媒体関連情報記録手段と、
   前記業務識別情報と、前記企業識別情報と、企業内の個人を識別する個人識別情報とに基づく消去条件を満たした場合に、前記消去条件を満たした前記個人情報を含む消去対象情報を出力する消去情報出力手段と、
   所定の個人番号について、消去条件及び前記出力媒体関連情報記録手段によって記録された情報に基づいて、消去条件を満たした消去対象情報に含まれる紙媒体ないしＰＤＦを含む前記出力媒体の削除リストを作成するリスト作成手段と、
   を備え、
   前記削除リストは、
   （ａ）前記出力媒体の名称を含む名称一覧、
   （ｂ）前記出力媒体に含まれる前記個人番号に係る個人の名前又は社員番号、その個人の組織を含む個人情報、
   （ｃ）前記出力媒体の出力年月日及び時間、出力者、出力場所（プリンタやＰＣ名称等）、管理責任者の情報、
   （ｄ）ＰＤＦ出力したものや、印刷出力した帳表のＰＤＦ（印刷したものはＰＤＦ化してある）へのリンク（格納先情報やそのディレクトリも含む）を含むリンク情報、
   （ｅ）紙媒体に関する、送付した先、保管したバインダーファイルの名称、ロッカーの名称等を含む保管情報、
   （ｆ）削除の有無、出力した年月日、削除することが必要になった年月日、その理由（契約解消、文書の保存年限経過）、削除したものは削除した年月日、削除した管理者の氏名やＩＤを含むステータス情報、
   （ｇ）システム管理者が「１週間以内に削除が必要」に例示される注意を喚起する表示を含む注記情報、
   （ｈ）削除した結果を入力するチェック欄、
   及び、
   （ｉ）所定の期間内に前記削除リストのチェック欄（ｈ）の削除結果が入力されていない場合は、システム管理者に通知し、未削除出力媒体の前記出力者又は前記管理責任者に削除処理を促す旨の注意情報、
   のいずれか１以上を一覧表示すること、
   を特徴とする個人情報管理システム。
2. 請求項１に記載の個人情報管理システムにおいて、
   前記出力媒体に関するログデータを記録するログ記録手段を備え、
   前記ログ記録手段は、自動で、又は、入力を受け付けることで記録すること、
   を特徴とする個人情報管理システム。
3. 請求項１又は請求項２に記載の個人情報管理システムにおいて、
   前記削除リストのチェック欄（ｈ）は、所定のアクセス権限者による削除完了の入力を求めるものであること、
   を特徴とする個人情報管理システム。
4. 請求項２に記載の個人情報管理システムにおいて、
   前記ログ記録手段は、前記出力媒体に関するコピーの履歴や、変更の有無を記録するものであること、
   を特徴とする個人情報管理システム。
5. 請求項１から請求項４までのいずれかに記載の個人情報管理システムにおいて、
   オフライン環境で出力した前記出力媒体が紙媒体である場合には、同時にＰＤＦ化して保存するＰＤＦ保存手段を備え、
   前記ＰＤＦ保存手段によって保存したＰＤＦは、帳表の概要を含み、かつ、前記個人番号は、参照不可に処理がされたものであること、
   を特徴とする個人情報管理システム。
6. 請求項１から請求項５までのいずれかに記載の個人情報管理システムにおいて、
   削除処理を指示した場合に、無意味なデータを上書きしてデータ復元できない削除処理を行う削除ツールを使用して、前記個人番号を含む前記出力媒体のデータを完全消去すること、
   を特徴とする個人情報管理システム。

Images