(57)【要約】【課題】本発明は、属人的な属性情報とは性質や観点の異なる学習要素を採用することにより、審査業務を適切に支援する審査支援技術を提供する。【解決手段】  申請案件の情報を取得する取得部と、取得した申請案件の情報を判定基準に適用して、要件不備の推定結果を得る推定部と、要件不備の推定結果を申請案件の審査業務に情報提供して、審査業務を支援する支援部とを備える。ここで使用される判定基準は、『入力としての、申請者の属性情報、審査経緯の情報』および『学習対象としての、申請の要件不備』として収集された過去の履歴を少なくとも訓練データとして、機械学習をおこなった結果である。【選択図】  図１
2020004161.tif 000002
【特許請求の範囲】
【請求項１】
申請案件の情報を取得する取得部と、
取得した前記申請案件の情報を判定基準に適用して、要件不備の推定結果を得る推定部と、
前記要件不備の推定結果を前記申請案件の審査業務に情報提供して、前記審査業務を支援する支援部とを備え、
前記推定部が使用する前記判定基準は、
申請者の属性情報と審査経緯の情報とを入力とし、要件不備を学習対象とした履歴を少なくとも訓練データとした機械学習の結果である
ことを特徴とする審査支援装置。
【請求項２】
請求項１に記載の審査支援装置において、
前記審査経緯の情報は、
過去の違反者において、共通する傾向を示す審査経緯の情報と、
申請の要件不備の状況に応じて変化する傾向がある審査経緯の情報と、
の少なくとも一つを含む
ことを特徴とする審査支援装置。
【請求項３】
請求項２に記載の審査支援装置において、
前記審査経緯の情報は、
申請受理または審査開始から審査処分までの期間についての経緯情報と、
最初の審査処分から最終の審査処分までの期間についての経緯情報と、
前記申請の更新回数についての経緯情報と、
の少なくとも一つを含む
ことを特徴とする審査支援装置。
【請求項４】
請求項1〜３のいずれか１項に記載の審査支援装置において、
前記支援部は、
前記要件不備の推定結果に基づいて、前記申請案件を詳細審査案件に振り分ける
ことを特徴とする審査支援装置。
【請求項５】
請求項１〜４のいずれか１項に記載の審査支援装置において、
前記推定部は、
前記申請案件の情報と、前記申請が要件不備であった過去案件の情報との類似度合を求め、前記類似度合の高い前記過去案件について要件不備の事例を得て、
前記支援部は、
前記要件不備の事例を前記申請案件の審査業務に情報提供して、前記審査業務を支援する
ことを特徴とする審査支援装置。
【請求項６】
請求項５に記載の審査支援装置において、
前記推定部は、
前記審査に適用する規定の改正時期の情報に基づいて、適用する規定が異なる過去案件については類似度合を低くする
ことを特徴とする審査支援装置。
【請求項７】
請求項１〜６のいずれか１項に記載の審査支援装置において、
前記推定部が使用する前記判定基準は、
申請者の属性情報を入力し、審査経緯の情報を学習対象とする履歴を少なくとも訓練データとした機械学習の結果である第１ルールと、
申請者の属性情報と審査経緯の情報とを入力とし、要件不備を学習対象とする履歴を少なくとも訓練データとした機械学習の結果である第２ルールとを有し、
前記推定部は、
取得した前記申請者の属性情報を前記第１ルールに適用して、前記審査経緯の情報の推定結果を求め、
前記申請者の属性情報と前記審査経緯の情報の推定結果とを前記第２ルールに適用して、要件不備の推定結果を求める
ことを特徴とする審査支援装置。
【請求項８】
請求項１〜７のいずれか１項に記載の審査支援装置において、
過去の申請案件の業務について情報蓄積することにより前記訓練データを生成する蓄積部と、
前記蓄積部に生成された前記訓練データにより機械学習を行い、前記判定基準を生成する学習部と
を備えたことを特徴とする審査支援装置。
【請求項９】
申請案件の情報を取得する取得ステップと、
取得した前記申請案件の情報を判定基準に適用して、要件不備の推定結果を得る推定ステップと、
前記要件不備の推定結果を前記申請案件の審査業務に情報提供して、前記審査業務を支援する支援ステップとを備え、
前記推定ステップにおいて使用する前記判定基準は、
申請者の属性情報と審査経緯の情報とを入力とし、要件不備を学習対象とする履歴を少なくとも訓練データとした機械学習の結果である
ことを特徴とする審査支援方法。
【請求項１０】
請求項１〜８のいずれか１項に記載の審査支援装置が、前記要件不備の推定結果を前記申請案件の審査業務または申請者宛てに情報提供して、前記審査業務または前記申請者の申請業務を支援するサービスを提供するサービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は審査支援装置、審査支援方法、およびサービス提供方法に関する。
【背景技術】
【０００２】
従来、建築確認、出入国管理、税関の審査、事業の許認可、税務調査、ローン審査など、その他多くの審査業務が知られている。このような審査業務において、審査者は申請の内容が所定の要件を満足するか否かについて審査を行う。
【０００３】
特許文献1は、このような審査業務を支援するシステムを開示する。この従来システムは、申請者の属人的な属性情報（国籍、性別、年齢）が、違反者の過去の傾向に該当するか否かを機械学習技術により推定し、その推定結果を審査業務に提供する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１７−４３２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明は、特許文献１（属人的な属性情報）とは異なる要素を採用して要件不備を推定することにより、審査業務を適切に支援する審査支援技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、代表的な本発明の一つは、申請案件の情報を取得する取得部と、取得した申請案件の情報を判定基準に適用して、要件不備の推定結果を得る推定部と、要件不備の推定結果を申請案件の審査業務に情報提供して、審査業務を支援する支援部とを備える。
【０００７】
ここで使用される判定基準は、
入力:申請者の属性情報、審査経緯の情報
学習対象:申請の要件不備
とする履歴を少なくとも訓練データとした機械学習の結果である。
【発明の効果】
【０００８】
審査経緯の情報を新たな要素に採用することにより、要件不備を新たな観点から推定し、審査業務を適切に支援することが可能になる。
【０００９】
なお、上記した以外の課題、構成、および効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１０】
【図１】審査業務システムの構成図。
【図２】審査業務システムの全体処理を説明するシーケンス図。
【図３】審査データベース３０の蓄積動作を説明するシーケンス図。
【図４】申請者属性情報３１の説明図。
【図５】審査業務履歴３２の説明図。
【図６】規則違反事例情報３３の説明図。
【図７】判定基準４８の学習処理を説明するシーケンス図。
【図８】新規追加属性４４１の算出方法の例である。
【図９】新規追加属性４４１の例である。
【図１０】判定基準４８の例である。
【図１１】判定基準の表示画面である。
【図１２】審査支援を説明するシーケンス図（１／２）。
【図１３】審査支援を説明するシーケンス図（２／２）。
【図１４】詳細審査振り分け結果の表示画面である。
【図１５】法制度改正と審査処分日の関係の例示である。
【図１６】法制度と処分日に関する非類似度の定義例である。
【図１７】違反事例の表示例である。
【図１８】審査経緯の情報を中間ノード化した実施例である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、本発明による実施形態について詳細に説明する。
【実施例１】
【００１２】
１．構成の説明
図１は、審査業務システム（審査支援装置を含む）の構成を説明する図である。
【００１３】
本システムには、審査端末１０、審査サーバ２０、審査データベース３０、および支援サーバ４０が、ネットワーク５を介して通信可能に設けられる。
【００１４】
審査端末１０は、審査者１（オペレータ）が審査業務の操作を行うためのクライアント端末であり、複数の審査者１が同時に審査業務を行うため、必要な台数が用意される。この審査端末１０は、インターフェース１１と、ＣＰＵ１２と、メインメモリ１３、入力装置１５、および表示装置１６とを備える。このメインメモリ１３には、審査業務クライアント機能１４をＣＰＵ１２で実施するためのソフトウェアが格納される。
【００１５】
審査サーバ２０は、審査端末１０に対して審査業務のデータ処理やデータ管理などのサービス提供を行う。この審査サーバ２０は、インターフェース２１と、ＣＰＵ２２と、メインメモリ２３とを備える。このメインメモリ２３には、審査業務サーバ機能２４をＣＰＵ２２で実施するためのソフトウェアが格納される。
【００１６】
審査データベース３０は、審査端末１０および審査サーバ２０で処理された業務の履歴を逐次に蓄積する。例えば、審査データベース３０は、申請者属性情報３１、審査業務履歴３２、および規則違反事例情報３３を蓄積し保持する。
【００１７】
支援サーバ４０は、審査業務の支援サービスを審査サーバ２０および審査端末１０に対して提供する。この支援サーバ４０は、インターフェース４１と、ＣＰＵ４２と、メインメモリ４３と、記憶装置４７とを備える。メインメモリ４３には、詳細審査を要するか否かの判定基準４８を作成する機能４４をＣＰＵ４２で実施するためのソフトウェアが格納される。ここで作成された判定基準４８は記憶装置４７に格納される。また、メインメモリ４３には、申請案件が詳細審査を要するか否かの振り分けを行う機能４５をＣＰＵ４２で実施するためのソフトウェアが格納される。さらに、メインメモリ４３には、詳細審査に振り分けた申請案件について過去違反事例を抽出する機能４６をＣＰＵ４２で実施するためのソフトウェアが格納される。
【００１８】
２．全体処理の流れ
図２は、審査業務システムの全体処理を説明するシーケンス図である。
以下、図２のステップ番号にそって全体処理の流れを説明する。
【００１９】
ステップＳ１:  審査者１は、審査端末１０の電源を投入し、審査業務クライアント機能１４のソフトウェアを起動する。この審査業務クライアント機能１４のログイン処理により、審査端末１０は、審査用のサーバ群（審査サーバ２０、審査データベース３０、および支援サーバ４０）と連携し、以降の審査業務が開始する。
【００２０】
ステップＳ２:  審査データベース３０は、審査業務の進行に応じてシステム内でやり取りされる情報を履歴として取得し、申請者属性情報３１、審査業務履歴３２、および規則違反事例情報３３に分類し蓄積する。
【００２１】
ステップＳ３:  審査端末１０は、申請案件を詳細審査案件／通常審査案件に振り分けるための判定基準４８を支援サーバ４０に適時に要求する。
【００２２】
ステップＳ４:  支援サーバ４０は、機械学習された判定基準４８を審査端末１０の要求に応えて審査端末１０に送信する。なお、機械学習の詳細については後述する。
【００２３】
ステップＳ５:  支援サーバ４０は、審査サーバ２０、審査データベース３０および審査端末１０と連携して、審査者１の審査業務を支援する。ここでの支援内容は、判定基準４８による申請案件の振り分け処理、類推される違反事例を抽出して審査画面に表示する処理などである。
【００２４】
ステップＳ６:  審査端末１０は、審査者１による申請案件の審査処分が完了すると、審査処分に係る処理データを、決裁者の決裁を受けるシステムや、審査処分を申請者に通知するシステムへ送信し、審査業務を完了する。その後、審査業務クライアント機能１４のログアウト処理により、審査端末１０は、審査用のサーバ群（審査サーバ２０、審査データベース３０、および支援サーバ４０）との連携を解除する。
【００２５】
３．履歴蓄積の詳細
図３は、審査データベース３０の履歴蓄積を説明するシーケンス図である。
以下、図３のステップ番号にそって、全体処理で述べた履歴蓄積（図２Ｓ２）の詳細を説明する。
【００２６】
ステップＳ１００:  審査端末１０は、審査業務システムにログインすると共に、審査サーバ２０に対して、申請案件や審査業務のデータ蓄積を要求する。
【００２７】
ステップＳ１０１:  審査サーバ２０は、申請案件や審査業務について複数の審査端末１０から入力される情報や、審査サーバ２０が外部の連携システム（不図示）から取得する情報を、審査データベース３０内の申請者属性情報３１、審査業務履歴３２、および規則違反事例情報３３に分類して蓄積する。
【００２８】
以下、図４〜図６を参照して、審査データベース３０内の蓄積データについて説明する。
図４は、審査データベース３０内の申請者属性情報３１を例示する。申請者属性情報３１は、個々の申請者ごとに、申請者ＩＤ３１０および属性情報（性別／生年月日／住所／職業などの属性３１１とその値３１２）を情報として蓄積する。これらの情報は、申請者が紙またはオンラインの申請フォームで入力した情報であり、審査端末１０の入力操作や審査サーバ２０の情報収集を介して審査データベース３０に蓄積される。このとき、同一申請者の属性情報が重複しないよう、審査データベース３０が申請者属性情報３１に対して名寄せ処理を行うことが好ましい。
【００２９】
図５は、審査データベース３０内の審査業務履歴３２を例示する。審査業務履歴３２は、申請者ＩＤごとに、審査の経緯（審査種別、業務履歴、タイムスタンプによる日付など）を情報として保持する。これら情報は、審査者１が審査端末１０で行う審査業務に応じて自動的に生成され、審査サーバ２０の処理を介して審査データベース３０に蓄積される。
【００３０】
図５に示す例では、申請者ＩＤ“１”の申請者が資格Ａの認定審査を申請し、審査者がその申請を受理した経緯（履歴３２０１）と、認定の審査処分をした経緯（履歴３２０２）が記録される。また、同申請者が資格Ａの更新審査を申請し、審査者がその申請を受理した経緯（履歴３２０３）と、更新の審査処分をした経緯（履歴３２０４）とが記録される。さらに、同申請者が資格Ａから資格Ｂへの変更審査を申請し、審査者がその申請を受理した経緯（履歴３２０５）と、変更の審査処分をした経緯（履歴３２０６）とが記録される。
【００３１】
一方、申請者ＩＤ“２”の申請者が、審査の経緯（履歴３２０７〜３２１０）を経た後、申請者の規則違反が判明して資格剥奪処分を受けた履歴３２１１が記録される。この資格剥奪処分の履歴３２１１の有無により、申請者に規則違反履歴があるかないかが判別できる。
【００３２】
図６は、審査データベース３０内の規則違反事例情報３３を例示する。規則違反事例情報３３は、規則違反した申請者の申請者ＩＤごとに、違反事例３３１（手続き種別、違反内容、違反の具体内容）を情報として保持する。これらの情報は、審査者１が審査端末１０から入力し、あるいは審査サーバ２０が違反処分を外部から情報取得して登録するといった処理を介して、審査データベース３０に蓄積される。
【００３３】
ステップＳ１０２:  審査端末１０は、審査データベース３０に蓄積される履歴（登録結果）を適時に取得し、審査画面に表示する。
【００３４】
以上の動作（図３Ｓ１００〜Ｓ１０２）が、複数の審査端末１０と審査サーバ２０との間で実施されることにより、審査データベース３０内には機械学習に必要な量の訓練データが順次に蓄積される。
【００３５】
４．学習処理の詳細
図７は、判定基準４８の学習処理を説明するシーケンス図である。
以下、図７のステップ番号にそって、全体処理で触れた機械学習（図２Ｓ３〜Ｓ４）の詳細を説明する。
【００３６】
ステップＳ２００:  審査端末１０は、申請案件を詳細審査案件／通常審査案件に振り分けるための判定基準４８を支援サーバ４０に適時に要求する。
【００３７】
ステップＳ２０１:  支援サーバ４０は、審査データベース３０にアクセスして、審査業務履歴３２を取得する。
【００３８】
ステップＳ２０２:  支援サーバ４０は、審査業務履歴３２の時系列の情報を申請者ＩＤ単位および審査経緯の単位に抽出し、抽出された審査経緯に基づいて審査経緯の情報を生成する。
【００３９】
ここでの審査経緯の情報としては、下記のいずれか又は両方の性質を有する情報が好ましい。
（１）過去の違反者に共通する傾向（例えば一定の似た傾向や特定の傾向）を示す審査経緯に関する情報
（２）申請の要件不備の状況に応じて変化する傾向がある審査経緯に関する情報
【００４０】
また、この種の性質を備える審査経緯の情報として、下記の情報のいずれか1種類または２種類以上の組み合わせを採用することが好ましい。
（Ａ）審査経緯のタイムスタンプ間の期間長さ
（Ｂ）審査経緯の回数
（Ｃ）審査経緯の種別（種別の時系列パターンを含む）
【００４１】
さらに、審査経緯の情報としては、下記の情報のいずれか1種類または２種類以上の組み合わせが更に好ましい。
（ａ）申請受理または審査開始から審査処分までの所要期間についての経緯情報
（ｂ）最初の審査処分から最終（最近）の審査処分までの期間についての経緯情報
（ｃ）申請の更新回数についての経緯情報
【００４２】
図８は、審査経緯の情報の例として新規追加属性４４１の算出処理を示す図である。
図９は、この新規追加属性４４１の算出結果を示す図である。
支援サーバ４０は、審査業務履歴３２から申請者ＩＤ“１”について資格Ａの認定申請の受理の経緯を検出すると、この受理の履歴３２０１のタイムスタンプ以降で最短の資格Ａの審査処分の履歴３２０２のタイムスタンプを検出し、両タイムスタンプ間の期間４４１０（審査経緯の間の期間）を検出し、資格Ａの認定審査の所要期間というラベルとともに、新規追加属性４４１に記録する。
【００４３】
また、支援サーバ４０は、審査業務履歴３２から申請者ＩＤ“１”について資格Ａの更新申請の受理の経緯を検出すると、この受理の履歴３２０３のタイムスタンプ以降で最短の資格Ａの更新の審査処分の履歴３２０４のタイムスタンプを検出し、両タイムスタンプ間の期間４４１１（審査経緯の間の期間）を検出し、資格Ａの更新審査の所要期間というラベルとともに、新規追加属性４４１に記録する。
【００４４】
さらに、支援サーバ４０は、審査業務履歴３２から申請者ＩＤ“１”について資格の変更申請（ＡからＢへ）の受理の経緯を検出すると、この受理の履歴３２０５のタイムスタンプ以降で最短の変更の審査処分の履歴３２０６のタイムスタンプを検出し、両タイムスタンプ間の期間４４１２（審査経緯の間の期間）を検出し、資格Ａから資格Ｂへの変更審査の所要期間というラベルとともに、新規追加属性４４１に記録する。
【００４５】
また、支援サーバ４０は、審査業務履歴３２から申請者ＩＤ“１”について資格Ａについての最初の審査処分の経緯を検出すると、この最初の審査処分の履歴３２０２のタイムスタンプ以降で資格Ａについての最終の審査処分の履歴３２０６のタイムスタンプを検出し、両タイムスタンプ間の期間４４１３（審査経緯の間の期間）を検出し、資格Ａの認定期間というラベルとともに、新規追加属性４４１に記録する。
【００４６】
さらに、支援サーバ４０は、審査業務履歴３２から申請者ＩＤ“１”について資格（申請）の更新回数４４１４を計数し、申請の更新回数というラベルとともに、新規追加属性４４１に記録する。
【００４７】
支援サーバ４０は、このような処理を申請者ＩＤごとに行うことにより、図９に示す情報４４１０〜４４１８を作成し、新規追加属性４４１に履歴として保持する。このとき、情報４４１０〜４４１８を時系列に並び替えすることにより、審査経緯の種別（種別の時系列パターンを含む）の情報も保持される。
【００４８】
ステップＳ２０３:  続いて、支援サーバ４０は、図４に示した申請者属性情報３１から申請者の属人的な属性情報の履歴を取得する。
【００４９】
ステップＳ２０４:  支援サーバ４０は、申請者属性情報３１（申請者の属性情報）と、新規追加属性４４１（審査経緯の情報）とを、共通する申請者ＩＤで関連付けて統合した後に、訓練データとしてバッチ処理可能にデータ化および配列化する。これらデータは、機械学習する判定基準の分岐やノードなどの入力（状態変数）になる。
【００５０】
支援サーバ４０は、訓練データの個々の列に、申請の要件不備が学習対象となるように教師データや報酬データを付与する。ここでの学習対象は、機械学習において教師役（反面教師役）、報酬（減点）、正解（不正解）、模範（非模範）、利得（損失）などの学習上の目標として定義されるものである。また、この学習対象は、機械学習された後の判定基準においては、推定結果の可能性や、可能性が最大となる推定結果を選ぶなどして、推定の答えになる。
【００５１】
ここでの要件不備については、「資格剥奪などの違反者になった」、「審査やり直しになった」、「申請が不受理になった」など、多様な定義が可能である。どの定義を要件不備に含めるかは、審査支援の情報としてどこまでの要件不備の可能性を提供することが有益かといったシステム上の観点から適宜に設計することが好ましい。
さらに、支援サーバ４０は、要件不備を違反規定ごとや代表事例ごとに分類し、その分類コードが学習対象となるように教師データや報酬点数データを訓練データの個々の列に付与してもよい。
【００５２】
ステップＳ２０５:  支援サーバ４０は、作成された訓練データを用いて機械学習を行い、判定基準４８を作成する。
【００５３】
ここでの機械学習には、決定木学習や、相関関係の学習や、ニューラルネットワークの学習や、訓練データの学習対象を教師値とする機械学習、ディープラーニングの誤差逆伝播法による学習その他の機械学習一般の技法が適用できる。
例えば、決定木学習では、情報利得（分岐による学習対象の不純度低下）が順次に大きくなるよう分岐ルールを階層的に作成する。
【００５４】
図１０は、この決定木学習の結果として得られる判定基準４８の例である。この判定基準４８は、決定木の特徴である説明変数により記述される振り分け基準４８１〜４８３を備える。この振り分け基準４８１〜４８３のいずれかを満足することにより、要件不備の可能性が高いとの推定結果となる。また、振り分け基準４８１〜４８３が重複する場合には、同時に満足する振り分け基準の数が多いほど、要件不備の可能性が高いとの推定結果を得てもよい。
支援サーバ４０は、このように作成した判定基準４８を、記憶装置４７に格納する。
【００５５】
ステップＳ２０６:  審査端末１０は、支援サーバ４０から取得した判断基準４８の内容を審査者の画面上に図１１に示すように表示する。
【００５６】
決定木の判定基準４８は、振り分け基準４８１〜４８３が説明変数により表示される。そのため、審査者にとって振り分け基準４８１〜４８３の中身は分かりやすく、かつ振り分け基準４８１〜４８３による振り分けの結果に対して審査者の理解を得やすいという利点がある。
【００５７】
５．審査支援の詳細
図１２および図１３は、審査支援を説明するシーケンス図である。
【００５８】
以下、図１２および図１３のステップ番号にそって、全体処理で述べた審査支援（図２Ｓ５）の詳細を説明する。
【００５９】
ステップＳ３００:  審査端末１０は、申請者または審査者により情報入力された申請案件を、審査サーバ２０に照会する。
【００６０】
ステップＳ３０１:  審査サーバ２０は、照会を受けた申請案件が判定基準４８に合致するか否かの判定を、支援サーバ４０に要求する。
【００６１】
ステップＳ３０２:  支援サーバ４０は、申請案件の情報から審査者の属人的な属性情報を抽出する。支援サーバ４０は、申請者の属性情報について過去の申請者属性情報３１を検索し、過去に該当する申請者のＩＤ（以下、該当者ＩＤという）を抽出する。なお、該当者ＩＤが見つからない場合は、支援サーバ４０は、申請者と類似の度合いが一定程度高い過去の申請者のＩＤを該当者ＩＤとして抽出してもよい。また、支援サーバ４０は、該当者ＩＤが見つからない場合は、申請者の属性情報に基づく従来の審査支援（特許文献１）に移行してもよい。
【００６２】
ステップＳ３０３:  支援サーバ４０は、該当者ＩＤを検索キーにして、審査業務履歴３２の申請者ＩＤを検索し、該当者ＩＤにおける過去審査の経緯を抽出する。抽出された過去審査の経緯を、上述した訓練データの作成手順と同様に処理し、審査経緯の情報を得る。
【００６３】
ステップＳ３０４:  支援サーバ４０は、該当者ＩＤの属人的な属性情報と、該当者ＩＤの過去審査経緯の情報とを入力（推定の状態変数）として判定基準４８に照合し、『判定基準４８の合致結果（要件不備の推定結果）』および『振り分け基準の該当番号』を審査サーバ２０を介して審査端末１０に返答する。
【００６４】
ステップＳ３０５:  審査サーバ２０は、申請案件が判定基準４８に合致した場合、違反事例の抽出（ステップＳ３０７）に動作を移行する。
【００６５】
ステップＳ３０６:  審査端末１０は、判定基準４８に合致した申請案件を、要件不備の可能性が高いと判定し、詳細審査案件に振り分ける。一方、審査端末１０は、判定基準４８に合致しない申請案件については、要件不備の可能性が低いと判定し、通常審査案件に振り分ける。この詳細審査案件の振り分け結果は、図１４に示すように、『判定基準４８の合致結果（要件不備の推定結果）』と『振り分け基準の該当番号』と『合致した振り分け基準の内容説明』とを画面表示することにより、審査者に伝達される。
【００６６】
なお、この振り分け処理は、審査者が予定する複数の審査案件に対して一括に処理することも可能である。その場合、審査案件１件ごとに詳細審査案件／通常審査案件が表示される以外に、『詳細審査案件○件／通常審査案件○件』といった件数表示も可能になる。この件数表示によれば、審査者は申請案件の審査にこれから所要する時間を計画的に予定配分することが可能になる。
【００６７】
ステップＳ３０７:  審査サーバ２０は、今回の申請者（申請案件）と類似属性を持つ過去の違反事例を支援サーバ４０に要求する。
【００６８】
ステップＳ３０８:  支援サーバ４０は、規則違反事例情報３３に格納された過去案件について、判定基準４８の合致状況が今回の申請案件と類似するものを抽出する。このように抽出した場合、判定基準４８を類似の尺度として、申請案件の属性（申請者の属性情報，審査経緯の情報）と類似度合の高い過去案件（以下、類似案件という）が抽出される。
例えば、決定木分析であれば、申請案件を条件分岐した先のグループに属する過去案件が類似案件となる。
この類似案件の違反事例は、申請案件の要件不備を審査者が考慮する際に有益な参考情報となる。
【００６９】
ステップＳ３０９:  図１５に示すように、過去の違反事例の判断は、その判断時期の法制度３２２０〜３２２２や法令規則などの規定に従う。この規定は、社会状況などに応じて適時かつ累進的に改正される。そのため、判断時期３２０２〜３２１０が改正の世代を重ねるに従って、過去の違反事例は審査の参考にならなくなる。そこで、支援サーバ４０は、図１６に示すように判断時期の期間差に含まれる改正の世代数を累積して非類似度を求める。支援サーバ４０は、この非類似度に応じて類似案件の申請者の類似度合を低くすることにより、規定の改正状況を類似度合に反映させる。
【００７０】
ステップＳ３１０:  支援サーバ４０は、類似案件の違反事例の中から、類似度合の高い順に、予め定めた事例数だけ、違反事例を抽出する。
【００７１】
ステップＳ３１１:  支援サーバ４０に抽出された違反事例は、審査サーバ２０を介して、審査端末１０に送信される。
【００７２】
ステップＳ３１２:  審査端末１０は、受信した違反事例を、図１７に示すように画面表示し、審査者に情報提供する。
【００７３】
６．実施例の補足事項
実施例は、申請者に該当する過去の該当者を検索し、その該当者の過去審査経緯の情報を学習要素とする。この部分を機械学習ルールに置き換えることも好ましい。すなわち、図１８に示すように、支援サーバ４０は、申請者の属性情報を第１ルール７０１に適用して、審査経緯の情報の推定結果を求める。さらに、支援サーバ４０は、申請者の属性情報と審査経緯の情報の推定結果とを第２ルール７０２に適用して、要件不備や違反事例の推定結果を求める。この第1ルール７０１は、申請者の属性情報を入力し、審査経緯の情報を学習対象とする履歴データを少なくとも訓練データとした機械学習の結果である。また、第２ルール７０２は、申請者の属性情報と審査経緯の情報とを入力とし、要件不備や違反事例を学習対象とする履歴データを少なくとも訓練データとした機械学習の結果である。このように審査経緯の情報を中間ノードに採用することにより、経緯情報を有しない新規の申請者についても審査経緯の情報を学習要素とした推定が可能になる。
【００７４】
なお、実施例では、審査サーバ２０、審査データベース３０、および支援サーバ４０それぞれを複数のサーバコンピュータにより分散して構成しているが、これらを適宜に一体に構成することも好ましい。
【００７５】
また、実施例では、審査経緯の情報として、申請の受理から審査処分までの期間を算出する。しかし、審査待ちのために受理から審査開始まで所定の遅れが生じた場合、この遅れは申請者側の要件不備の状況とは関連性が低い。そこで、審査経緯の情報として、審査開始から審査処分までの期間を算出してもよい。
【００７６】
なお、実施例において、審査経緯の情報として、審査経緯の時系列パターン（資格Ａの認定処分から不自然な短い期間で資格Ｂに変更されたなど）を採用してもよい。このような経緯の時系列パターンを推定の要素とすることにより、要件不備となる『審査経緯の時系列パターンの傾向』についての機械学習が可能になり、より適切な審査支援が可能になる。
【００７７】
また、申請者には、申請者が代理を委任する者（以下、申請代理者という）を含めることが好ましい。申請代理者においても審査の経緯と要件不備との間に一定の傾向が生じ得るため、審査支援に一定の効果がある。
【００７８】
さらに、申請代理者は複数の申請者を代理し、過去の審査経緯が蓄積されやすい。そのため、審査経緯の情報を採用した審査支援に好適である。
【００７９】
また、申請代理者が複数や法人の場合は、筆頭や担当などの実質的な申請代理者の優先度を高めた機械学習および推定処理も好適である。
【００８０】
なお、実施例では、過去事例の判断時期から現時点までの期間差に含まれる改正の世代数を累積して非類似度を定義している。この改正の世代数を、審査に影響する大幅改正ほど大きな世代数とし、審査に影響しない改正は世代数をゼロとして、実質的に定義してもよい。この世代数の実質的な定義によれば、改正内容の実質的な影響を踏まえた非類似度の定義が可能になる。
【００８１】
また、実施例では、要件不備の推定結果を審査業務にサービス提供しているが、これに限定されない。例えば、支援サーバ４０は、要件不備の推定結果を、申請者宛ての通信手段などを介して申請者に提供するサービスを行ってもよい。このようなサービスによれば、申請者は、要件不備の警告を受けて申請案件の自発的な訂正や取り止めを行うことが可能になる。このようなサービスは申請者を支援するのみならず、要件不備の自発的な訂正や取り止めが促進されることにより、申請の受理や審査の業務を結果的に支援することになる。
【００８２】
７．実施例の効果
以下、実施例の一般傾向の効果について説明する。なお、機械学習では学習要素と学習対象との傾向に適合するように判定基準が適宜に作成される。そのため、特殊な種類の審査においては、機械学習の結果が、ここで述べる一般傾向と異なる場合もあり得る。そのような特殊な種類の審査については、機械学習の結果が優先される。
【００８３】
（１）審査において生じる経緯は、申請案件の要件不備を反映する事象である。そのため、審査経緯の情報を新たな学習要素として機械学習した判定基準を採用することにより、要件不備を新たな観点から推定し、審査支援を適切に実施することが可能になる。
【００８４】
（２）実施例は、申請者の属性情報と、審査経緯の情報とを組み合わせて新たな学習要素とする。したがって、要件不備の推定が一段と詳細化し、審査支援を適切に実施することが可能になる。
【００８５】
（３）実施例は、審査経緯の情報として、過去の違反者において、一定の似た傾向を示す審査経緯の情報を学習要素に採用する。そのため、この審査経緯の情報から類推する形式で、過去の違反者と同じ傾向を有するか否か（違反者となる可能性が高いか否か）を判定することが可能になる。
【００８６】
（４）実施例は、審査経緯の情報として、申請の要件不備の状況に応じて変化する傾向がある審査経緯の情報を学習要素に採用する。そのため、この審査経緯の情報から逆に辿って申請案件に内在する原因を類推する形式で、要件不備となる可能性を判定することが可能になる。
【００８７】
（５）実施例は、審査経緯の情報として、申請受理（または審査開始）から審査処分までの期間についての経緯情報を学習要素に採用する。一般に審査に所要する期間が長いほど、審査者にとって困難な審査対象であって要件不備を有する可能性が高いという傾向がある。そのため、この審査の所要期間が長いほど、要件不備となる可能性が高いと判定することが可能になる。
【００８８】
（６）実施例は、審査経緯の情報として、最初の審査処分から最終（最近）の審査処分までの期間についての経緯情報を学習要素に採用する。一般に、このように資格期間が長いということは、途中で資格剥奪などの処分を受けずに安定状態にあったと類推される。そのため、この資格期間が長いほど、要件不備となる可能性が低いと判定することが可能になる。
【００８９】
（７）実施例は、審査経緯の情報として、前記申請の更新回数についての経緯情報を学習要素に採用する。一般に、更新回数が多いということは、途中で資格剥奪などの処分を受けずに安定状態にあったと類推される。そのため、この更新回数が多いほど、要件不備となる可能性が低いと判定することが可能になる。
【００９０】
（８）実施例は、要件不備の推定結果に基づいて、申請案件を詳細審査案件に振り分ける。この振り分け処理に応じて、審査者は、要件不備の可能性が高い審査案件を詳細に審査できるため、審査の品質を高めることができる。また、要件不備の可能性が低い審査案件については通常審査を行うことにより、審査の速度を効率よく高めることができる。その結果、審査の品質とスピードという相反する問題をバランスよく解決することが可能になる。
【００９１】
（９）実施例は、申請案件と類似する過去案件（類似案件）について要件不備の違反事例を求め、その類似案件の違反事例を審査業務に提供する。したがって、審査者は、この違反事例について優先的に申請案件の審査検討を行うことにより、審査の品質および速度の両方を改善することが可能になる。
【００９２】
（１０）実施例は、申請者の属性情報と、審査経緯の情報とを組み合わせて、類似案件の違反事例を抽出する。そのため、違反事例の抽出数を一段と絞りつつ、より適切な違反事例を抽出できる。
【００９３】
（１１）実施例は、改正前の過去案件の類似度合を低くする。その結果、規定の改正状況を勘案した適切な違反事例を抽出できる。
【００９４】
（１２）実施例は、過去案件と申請案件との間の改正回数が多いほど、類似度合を低くする。その結果、規定の累進的な改正状況を踏まえて、より適切な違反事例を抽出できる。
【符号の説明】
【００９５】
５…ネットワーク、１０…審査端末、１１…インターフェース、１２…ＣＰＵ、１３…メインメモリ、１４…審査業務クライアント機能、１５…入力装置、１６…表示装置、２０…審査サーバ、２１…インターフェース、２２…ＣＰＵ、２３…メインメモリ、２４…審査業務サーバ機能、３０…審査データベース、３１…申請者属性情報、３２…審査業務履歴、３３…規則違反事例情報、４０…支援サーバ、４１…インターフェース、４２…ＣＰＵ、４３…メインメモリ、４７…記憶装置、４８…判定基準、７０１…第１ルール、７０２…第２ルール
【図１】
2020004161.tif 000003
【図２】
2020004161.tif 000004
【図３】
2020004161.tif 000005
【図４】
2020004161.tif 000006
【図５】
2020004161.tif 000007
【図６】
2020004161.tif 000008
【図７】
2020004161.tif 000009
【図８】
2020004161.tif 000010
【図９】
2020004161.tif 000011
【図１０】
2020004161.tif 000012
【図１１】
2020004161.tif 000013
【図１２】
2020004161.tif 000014
【図１３】
2020004161.tif 000015
【図１４】
2020004161.tif 000016
【図１５】
2020004161.tif 000017
【図１６】
2020004161.tif 000018
【図１７】
2020004161.tif 000019
【図１８】
2020004161.tif 000020