２８－２

平成２８年度
生体認証を用いた被災者支援システムの研究開発
報

告書

平成２９年３月
一般社団法人 日本自動認識システム協会

この事業は競輪の補助(28-2)を受けて実施しました。

http://ringring-keirin.jp

はじめに
阪神・淡路大震災から 22 年、東日本大震災から 6 年が経とうとしているが、平成 28 年 4 月の熊本地震も含め、その後も日本各地で自然災害は多発しており、その度に、地域の住民の方々は主に自治体が開設した避難所に避難され、身の安全の確保に努めている。
この中で、平成 23 年 3 月に発生した東日本大震災では、家も財産も失った 10 万人を超える避難者が発生し、学校の体育館などが用いられた避難所では、自治体を中心に着の身着のままでたどり着いた被災者の方々への支援活動が行われたが、想定外の大規模災害を前に支援に大きな混乱があった
ことが報道された。例えば、被災により身元を証明する免許証・健康保険証・キャッシュカードなどを紛失したため、被災者の方々が不自由な状況に追い込まれ、救済のため、経産省をはじめとする各省庁が、自己申告で銀行口座開設や携帯電話契約など各種サービスが受けられる特例措置を適用し、避難者の利便を図ったことは記憶に新しい。
自治体の関係者からは、地域住民の安心・安全を図ることは自治体の責務の一つであり、特に災害弱者といわれる高齢者や子供及び障害のある方々を始めとした災害時等避難行動要支援者に対する対策が喫緊の課題となっていると伺っている。
このような状況を踏まえると、避難者、その中でも特に避難行動要支援者に対する支援を身元特定という視点から見つめ直し、今までにない新しい支援方法を研究・検証することで、避難者支援の在り方に新しい光を当てることが、今後の自治体の被災者支援活動の改善と避難者に対する円滑な支援を提供することにつながっていくのではないかと考えた。
避難所を自治体の被災者支援のための原点であると考えると、避難所での避難者の身元特定は支援のための基本要素の一つと捉えることができ、特に、紛失する恐れのない利便性の良い本人認証技術である生体認証技術は、自ら誰であるかを示すことが難しい避難者に対してその威力を発揮し、避難者の身元特定手段の一つとして自治体に提供できるのではないかと考え、本研究開発に取り組んだ。
最後に、研究開発の実施にあたり、ご指導を賜った検討委員会の半谷委員長（東京理科大学）、委
員各位、ならびに関係者各位に対し、深く感謝を申し上げる。

平成29年3月
一般社団法人日本自動認識システム協会

目

次

はじめに
目

次

1．研究開発の目的 .................................................................................................................................1
2．研究開発の過去の取り組み内容と今年度計画 .................................................................................2
3．研究開発の実施体制 .........................................................................................................................4

3.1 実施体制 ......................................................................................................................... 43.2 検討委員会 ..................................................................................................................... 6
3.3 実施スケジュール........................................................................................................... 7
4．研究開発内容 ....................................................................................................................................8

4.1 検討委員会 ..................................................................................................................... 8
4.2 プロトタイプ・システム仕様の調査 ............................................................................ 10
4.2.1 活動概要 ................................................................................................................ 10
4.2.2 システム構成と必要な機能 .................................................................................... 11
4.2.3 API 仕様 ................................................................................................................ 20
4.2.4 画面等の仕様 ......................................................................................................... 29
4.3 プロトタイプ・プログラムの開発 ................................................................................ 41
4.3.1 被災者支援システム側の開発................................................................................. 41
4.3.2 連携及び生体認証システム側の開発 ...................................................................... 41
4.3.3 被災者支援システムと連携及び生体認証側の連動テスト ...................................... 44
4.4 プロトタイプ・システムの有効性の検証 ..................................................................... 47
4.4.1 発表・体験会用デモシステム概要.......................................................................... 47
4.4.2 発表・展示体験会 .................................................................................................. 48
4.4.3 発表・展示体験会での検証結果 ............................................................................. 49
4.4.4 自治体関係者よりいただいた感想.......................................................................... 51
5．研究開発のまとめ ...........................................................................................................................54

5.1 研究開発のまとめ......................................................................................................... 54
5.2 成果物の公開・提供と今後について ............................................................................ 56
6．今後に向けて ..................................................................................................................................58

付

録＜付録 1＞ 補助検索項目検討書＜付録 2＞ 操作処理遷移（画面中心）検討書＜付録 3＞ 連携機能シーケンス検討書＜付録 4＞ オフライン登録処理検討書（オフライン登録処理案）＜付録 5＞ 連携機能詳細仕様書

別

途

配

布 付 録

プロトタイプ・プログラムのサンプルコード等のプログラム詳細は、適切な用途に使用していただ
ける方に、弊協会より提供するので、別途配布付録とした。
業界関係者で希望する方は、別途弊協会まで連絡をいただきたい。
なお、成果物の提供や今後の取扱いは、5 章に記載している平成 27 年度 JAISA 報告に記載した事項に従うので、順守いただきたい。
＜付録 6＞ 被災者支援システム側 プロトタイプ・プログラム資料＜付録 7＞ 生体認証応用被災者支援システムプロトタイプ（連携機能）プログラム構成資料＜付録 8＞ 生体認証応用被災者支援システムプロトタイプ（連携機能）デモシステム構成資料

1．研究開発の目的
現代の日本において社会生活を営むにあたり身元を特定するために用いられているものは、免許証・健康保険証・パスポート・キャッシュカード・マイナンバーカードなど、いわゆる証明書が大多数である。しかしながら、東日本大震災において明らかになったのは、被災を受けられた方々のうち、証明書を失い身元特定ができなくなった一部の方に対して、支援の混乱や効率の低下を招いたことである。また、避難所に避難される方々の中には、災害弱者といわれる高齢者や子供や障害のある方々を始めとした災害時等避難行動要支援者が含まれており、その中には種々の理由により、自ら誰であるかを示すことが難しい方も含まれている。
自治体の方々からは、自治体が避難所で避難者の支援をする上で、身元の特定が困難な方の身元を特定できるようにすることが支援の改善に必要であるとのお考えもお聞きしている。
現在、身元特定のために適用可能な認証技術の中に生体認証技術がある。これは身体的特徴を用いた身元特定手段であり、いわゆる証明書を必要としない。生体認証技術による身元特定手段と自治体が避難所で用いる被災者支援システムが連携することにより、避難者、特に自ら誰であるかを示すことが難しい方の身元特定が容易になる可能性がある。また、避難所などでの支援物資の支給や生存確認など様々な用途にも生体認証技術を用いることで、身元特定用途だけでなく、他の被災者支援サービスの質が向上する可能性もある。さらに、この仕組みが全国の自治体に広がることにより、各所の自治体で避難者に均質なサービスが提供できるようになる可能性もあると考えている。
以上を鑑み、本研究開発では受益者として避難者と自治体職員を想定し、避難者、特に自ら誰であるかを示すことが難しい避難者には、個人の事情に即した支援を速やかに受けなければならなというニーズがあるのではないか、また自治体職員には身元特定が難して避難者の身元特定作業の手間をできるだけ低減し、避難された方々へ迅速かつ確実なサービスを提供したいというニーズがあるのではないかと想定した。
これらの想定をもとにして、本研究開発は、災害時に自治体が運営する被災者支援システムの改善につなげることを目指して、避難所における避難者の身元特定に利用できる手段の一つに生体認証技術があることを示すことを目的とした。
また、研究成果の自治体システムへの導入を考え、生体認証技術の自由な選択性を実現することも目的とした。

12．研究開発の過去の取り組み内容と今年度計画
被災者支援において中心的役割を果たす自治体が避難所で行う支援業務に、生体認証による身元特定手段を組み込むため、次の調査・検討、開発及び検証を 3 ヵ年の期間で行うことを計画し、平成 26 年度、平成 27 年度の 2 年間、それぞれ、調査・検討フェーズとプロトタイプ・システムの開発フェーズとして、下記の活動に取り組んだ。
1) 調査・検討フェーズ（平成 26 年度）
生体認証技術を被災者支援に適用するための利用方法を検討すると共に、適用時の課題の洗い出しと解決方法の検討を行った。
具体的には、過去に起きた災害での避難者支援状況を、文献及び有識者からのヒアリングにより収集し、集められた調査結果から、生体認証技術を避難者支援に応用する利点のある利用
シーンを検討した。また、その利用シーンを実現するための被災者支援システムと生体認証の連携方式について基礎検討し、基本的なプログラム仕様を開発した。
2) プロトタイプ・システムの開発フェーズ（平成 27 年度）
被災者支援システムの運営・管理元の関係者や自治体関係者をまじえて、生体認証技術を避難者支援に応用した際に利点のある利用シーンを具体化した。
その結果、自治体等が被災者支援システムを用いて実施する避難者支援業務の中の一つである避難所での避難行動要支援者（要援護者）に対する支援活動時の身元特定に生体認証を応用することが利用シーン（図 2-1）として適切であろうとの結論を得ることができた。
次にこの利用シーンに対応するために、被災者支援システムと生体認証の連携方式と生体認証を用いて身元特定する際に必要とされる仕様について検討した。

生体情報を使った避難者の身元特定の流れ
避難所（ネットワーク環境あり）

被災者支援システム
被災者支援・避難所関連システム（被災者・避難者登録）①健常者・意識がはっきりしている避難者
氏名・生年月日等で検索②意識不明・避難行動
要支援者等、意思表示できない避難者
生体情報（指紋・静脈
・顔等）

生体認証
システム

識別情報

本人
申告

生体情報

図 2-1 支援活動時の身元特定に生体認証を応用することが利用シーン

この検討成果をもとにして、被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロトタイプ・システムの開発に取り組んだ。
その結果、システム構成案として、図 2-2 に示す構成を取るのが適切であろうとの結論を得
2

ることでき、プロトタイプ・システムの開発に着手した。
なお、開発にあたっては、被災者支援システム全国サポートセンター（西宮市情報センター内）が開発・管理している被災者支援システムを生体認証との連携対象とした。

システム構成（生体認証との連携の実現）
避難所被災者受付（避難者の身元確認）

生体認証機能（サーバ）・各社独自技術
・生体情報の蓄積
・検索・認証・Webブラウザ
・各社クライアント

検索・認証
要求/応答

疎結合と
オープン化

検索・認証
要求/応答

・被災者支援・共通オープンシステム

検索・認証
要求/応答

・各社独自技術へ変換
・識別情報の変換
・オープンソース対応

連携機能（サーバ）

被災者支援システム（サーバ）

図 2-2 プロトタイプ・システム構成
平成 28 年度は、検証フェーズとして下記を計画した。
3) 検証フェーズ（平成 28 年度）
生体認証技術と被災者支援システムの連携に積極的な自治体と連携しながら、生体認証を用いた被災者支援システムのプロトタイプ・システムの開発を完了し、そのプロトタイプ・シス
テムを用いて被災者支援システムと生体認証技術が連携することの有効性を確認するための検証作業を行う。
具体的には、下記に取り組む。
(1) 委員会活動
有識者・自治体・生体認証機器ベンダー・応用システムベンダー・官公庁及び事務局からなる検討委員会を組織し、研究開発の実施に関係する事項、検討方針、検討内容や方向性について、専門的、具体的な検討を行い、研究開発にフィードバックする。
(2) 生体認証応用被災者支援プロトタイプ・システム仕様の調査（調査）
被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロ
トタイプ・システムの開発に向け、仕様等を明確にする。
(3) 生体認証応用被災者支援プロトタイプ・プログラムの開発（プログラム開発）
仕様の調査結果に基づいて、被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロトタイプ・システムを開発する。
(4) 生体認証応用被災者支援プロトタイプ・システムの有効性の検証（検証実験）
開発したプロトタイプ・システムを用いて、被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行う機能の有効性の検証を行う。

3

3．研究開発の実施体制
3.1

実施体制
研究開発の実施にあたって、本研究開発の全体計画と検討、研究開発の進行管理、ならびに産官学の有識者により構成した検討委員会（生体認証を用いた被災者支援システムの研究開発検討委員会）の開催と運営を（一社）日本自動認識システム協会が行った。また、自治体が発災時に運用する被災者支援システムのサポート・運営・管理を担っている西宮市情報センターにある被災者支援システム全国サポートセンター（センター長 吉田 稔氏）のご協力をいただき、研究開発を進めた。
検討委員会では、調査内容や検討内容を報告し、委員の知見をもとに研究開発内容の検討をいただき、研究開発を取りまとめた。
調査にあたっては、平成 27 年度活動成果に対する知見、ならびに「被災者支援システム」ある
いは「システム連携及び生体認証」という異なる分野に対する知見が必要なため、「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」（以下、被災者支援システ
ム側調査という）及び「生体認証を用いた被災者支援システム構築のための調査（連携及び生体認証側）」（以下、連携及び生体認証側調査という）の 2 つの調査に分け、それぞれ外部に調査委託し、また弊協会とそれぞれの委託先が協力して調査・検討を行った。また、相互の連携についても考慮することも必要なため、他方の委託先ならびに弊協会とも相互に連携をとって活動した。
なお、調査内容は、適宜検討委員会に報告、検討を行い、調査に反映した。これらの 2 つの委託調査は、昨年からの継続性が必要なため、昨年の調査委託先に委託した。
「被災者支援システム」あるいは「システム連携及び生
プロトタイプ・プログラムの開発には、体認証」という異なる分野に対する知見が必要なため、専門性を考慮し、「生体認証応用被災者支援システムのプロトタイプ・プログラム（被災者支援システム側）」と「生体認証応用被災者支援システムのプロトタイプ・プログラム（連携及び生体認証側）」の 2 つに開発作業を分け、それぞれ外部に作業委託し、また弊協会とそれぞれの委託先が協力して開発を行った。また、相互の連携についても考慮することも必要なため、他方の委託先ならびに弊協会とも相互に連携をとって活動した。なお、検討内容は、適宜検討委員会に報告、検討を行い、開発に反映した。これらの2 つの委託開発にも、昨年からの継続性が必要なため、昨年の開発委託先に委託した。

4

[実施者]①事業実施および進捗管理・調整②検討委員会の設置・運営③有識者･業界意見の反映④事業成果の業界での活用推進(A) 一般社団法人
日本自動認識システム協会

審議[検討委員会](有識者(東京理科大 半谷教授)
自治体関係者（西宮市、川口市、狭山市）
国内生体認証ベンダー（富士通、NEC、日立ほか)
サービス事業者（NTT Data、セコム、凸版印刷)[事業および成果活用協力]
事業協力

西宮市情報センター[委託調査委託先A]①生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）
調査委託

被災者支援システム知見者（（株）システム・エージ）[委託調査委託先B]①生体認証を用いた被災者支援システム構築のための調査（連携及び生体認証側）
調査委託

生体認証知見者（（株）日立システムズ）[プログラム開発委託先A]①生体認証応用被災者支援システムのプロトタイプ・プログラム（被災者支援システム側）
プログラム開発委託

プログラム開発委託

被災者支援システム知見者（（株）システム・エージ）[プログラム開発委託先B]①生体認証応用被災者支援システムのプロトタイプ・プログラム（連携及び生体認証側）
生体認証知見者（（株）日立システムズ）

図 3.1-1 研究開発実施体制（1）管理体制
広報係

代表理事 会長

常務理事
横田 修治

事務局長
稲垣 賢

常務理事

事務局

・小林 敬子(経理担当)
経理係（2）研究開発体制
センター長
酒井 康夫
研究開発センター・酒井 康夫(兼) /岩井 美香(プロマネ / 研究開発 / 委員会運営)
バイオメトリクス担当

RFID担当

バーコード担当

図 3.1-2 研究開発体制
5

3.2

検討委員会
生体認証を用いた被災者支援システムの研究開発検討委員会は、下記の方々（有識者（2 団体 2・応用システムベンダー（5 社名）・自治体（3 自治体 4 名）・生体認証機器ベンダー（4 社 5 名）
6 名）
・官公庁（2 名）及び事務局（2 名）））からなる(総計 21 名)。
表 3.2-1 生体認証を用いた被災者支援システムの研究開発検討委員会委員名簿（順不同・敬称略）
役割

氏名

所属

役職

備考
SC37/WG3
委員

委員長

半谷精一郎 東京理科大学

教授

委員

寳木 和夫

国立研究開発法人産業技術総合研究所

副研究
部門長

委員

吉田 稔

西宮市情報センター

センター長

委員

南

西宮市情報センター

課長

委員

森岡 毅

川口市

課長

委員

宮崎 昌美

狭山市

次長

委員

村上 秀一

株式会社日立製作所

委員

齋藤雄一郎 富士通株式会社

委員

塙

委員

晴久

担当部長

日本電気株式会社

シニア
エキスパー

齋藤 訓

株式会社日立システムズ

主任技師

委員

上田 隆

株式会社システム・エージ

代表取締役

委員

平岡 良彦

セコム株式会社 ＩＳ研究所

主務研究員

委員

鷺

日本電子計算株式会社

統括部長

委員

平野 誠治

凸版印刷株式会社担当課長

ｵﾌｻﾞｰﾊﾞ

高田 直幸

セコム株式会社 ＩS 研究所

ｵﾌｻﾞｰﾊﾞ

山田 徳幸

日本電気株式会社

ｵﾌｻﾞｰﾊﾞ野口 武彦

株式会社ＮＴＴデータ・エム・シー・エス

担当課長

ｵﾌｻﾞｰﾊﾞ加藤 誠司

経済産業省 産業技術環境局

課長補佐

ｵﾌｻﾞｰﾊﾞ中山 和泉

経済産業省 製造産業局

課長補佐

事務局

酒井 康夫

一般社団法人日本自動認識システム協会

センター長 SC37 委員

事務局

岩井 美香

一般社団法人日本自動認識システム協会

俊浩

宏行

6

SC37/WG3
ｱﾄﾞﾊﾞｲｻﾞ

グループ
リーダー
シニア
エキスパー

SC37 委員

3.3

実施スケジュール
平成 28 年度の生体認証を用いた被災者支援システムの研究開発活動は、「2.研究開発の実施計画」に述べた(3)検証フェーズとして、①生体認証応用被災者支援プロトタイプ・システム仕様の調査、②生体認証応用被災者支援プロトタイプ・プログラムの開発と③生体認証応用被災者支援
プロトタイプ・システムの有効性の検証（検証実験）に取り組んだ。
具体的には、表 3.3-1 に示す日程で研究開発内容に取り組んだ。
表 3.3-1 研究開発実施日程
上期・月別
事業項目（段階）

半 期

下

半 期

４ ５ ６ ７ ８ ９ 10 11 12 １ ２ ３①生体認証を用いた被災者支援システムの研究開発（1）生体認証を応用した被災者支援システ
ムのプロトタイプ・システム仕様調査
・被災者支援システム側に必要とされる機能と仕様の調査（第2ステップ）
・生体認証機能側に必要とされる機能と仕様の調査（第2ステップ）（2）生体認証を応用した被災者支援システ
ムのプロトタイプ・プログラムの開発
・被災者支援システム側に必要な機能提供
プログラムの開発（第2ステップ）
・生体認証機能側に必要な機能提供
プログラムの開発（第2ステップ）（3）プロトタイプ・システムの検証実験

・ 実験内容の検討
・ 実験の準備と実施
・ 結果まとめ（4） 報告書の作成（5） 委員会

74．研究開発内容
ここでは、平成 28 年度に実施した研究開発内容について述べる。
4.1

検討委員会

4.1.1

活動目的

研究開発実施にあたって、調査内容や検討内容を報告し、実施内容の検討をいただくため、産官学の有識者により構成した検討委員会（生体認証を用いた被災者支援システムの研究開発委員会）を組織した。
4.1.2

活動概要

生体認証を用いた被災者支援システムの研究開発検討委員会は、有識者・自治体・生体認証機器
ベンダー・応用システムベンダー・官公庁及び事務局からなり、研究開発の実施検討方針、検討内
容や方向性について、専門的、具体的な検討を行い、研究開発にフィードバックした。
検討委員会の活動内容は下記である。
4.1.2.1

第 1 回検討委員会

平成 28 年 6 月 7 日(火) 15:30～17:30 に、(一社)日本自動認識システム協会（JAISA）にて開催した。主な内容は、下記であった。
1) 本年度の計画概要説明
2) 連携及び生体認証側検討状況報告
3) 熊本地震を踏まえて被災者支援システム側検討状況報告
4) 委託調査計画と見積り依頼について
4.1.2.2

第 2 回検討委員会

平成 28 年 9 月 1 日(木) 15:00～17:30 に、(一社)日本自動認識システム協会（JAISA）にて開催した。主な内容は、下記であった。
1) 連携シーケンスとインターフェース（API）仕様検討状況報告
2) 検証実験について（プレス含む）
4.1.2.3

第 3 回検討委員会

平成 28 年 11 月 18 日(金) 10:00～12:00 に、(一社)日本自動認識システム協会（JAISA）にて開催した。主な内容は、下記であった。
1) 連携シーケンスと API 仕様検討状況報告
2) プログラム開発（連携及び生体認証側）状況報告
8

3) プログラム開発（被災者支援システム側）状況報告
4) 検証実験及びプレス発表について
4.1.2.4

第 4 回検討委員会

平成 29 年 3 月 10 日(金)15:00～17:00 に、(一社)日本自動認識システム協会（JAISA）にて開催した。主な内容は、下記であった。
1) プログラム開発（連携及び生体認証側）報告
2) プログラム開発（被災者支援システム側）報告
3) 発表展示会報告
4) 検証結果報告

94.2

プロトタイプ・システム仕様の調査
被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロトタイ
プ・システムの開発に向け、システムの「あるべき姿」を念頭におき、下記を明確にすること。
①避難者の身元特定を行うシステム構成と必要な機能②API 仕様③画面等の仕様

4.2.1

活動概要

下記の内容について調査した。
①避難者の身元特定を行う機能の精査と追加の必要性の検討②日々業務での生体認証情報の「登録」「削除」の要件検討③スタンドアローン「モバイル端末（PC）」による自治体拠点外での「登録」運用の検討④避難所における生体認証を用いた自称できない避難者の身元検索シナリオの精査⑤異なる体系の識別番号（避難者の身元を表す自治体の管理用 ID、サービス ID ともいう）
による生体認証情報の登録時の処理シーケンスの精査と検討⑥検索時の絞込み条件(年齢や性別等)の複数設定可能性のシステム的摺合せ⑦検索・認証におけるエラーケースを洗い出しと、エラー時の扱いについての検討⑧検索時の連携処理シーケンスの精査と検討

これらの調査は、「被災者支援システム」あるいは「被災者支援システムと連携及び生体認証」という異なる分野に対する知見が必要なため、被災者支援システム側調査と連携及び生体認証側調査の 2 つの調査に分け、検討に取り組んだ。

調査に際しては、特に下記に重点を置いて実施した。
(ⅰ) 被災者支援システム側重点調査事項
・被災者支援システム側で生体認証の「検索」と「確認」のユーザインターフェース仕様の確定「削除」の要件調査・日々業務として実施する生体認証情報の「登録」
・日々業務として実施する生体認証情報の「登録」「削除」のユーザインターフェース仕様と実現方法(ⅱ) 連携及び生体認証側重点調査事項
・被災者支援システムと生体認証機能の連携シーケンスの精査と確定
・被災者支援システムと生体認証機能の連携機能部のプロトタイプ・プログラムの仕様
・日々業務システムと生体認証機能の連携シーケンスの精査と確定

10

・日々業務システムと生体認証機能の連携機能部のプロトタイプ・プログラムの仕様

以下、以上の調査によりまとめた、避難者の身元特定を行うシステム構成と必要な機能、API
仕様、画面等の仕様について述べる。
4.2.2

システム構成と必要な機能

被災者支援システムと連携機能・生体認証機能（システム）との機能連携方法・内容について、実現可否や使い勝手、双方のシステムの分界点、API 仕様などを勘案しながら、「あるべき姿」を念頭におき、操作時の表示画面を中心にした操作処理遷移やを被災者支援システムと生体認証機能の連携シーケンスを検討した。
4.2.2.1

システム構成方針

生体認証技術には指紋、静脈、顔など様々な生体情報を使用するものがあり、その認証技術を使用するためのアプリケーションインターフェイス（API）もまた生体認証技術を提供するベンダーごとに異なっている。
一方、自治体に生体認証を用いて身元の特定を行うための機能が導入される際は、自治体には様々な状況があるので、使用できる生体認証技術を限定することは望ましくない。また、被災者支援システムはオープンシステムとして各自治体に提供されており、自治体が選択した生体認証技術により被災者支援システムの改変が必要になることも望ましくない。
さらに、自治体に機能を提供するベンターも複数あり、その開発を促進することも必要である。
そのため、平成 27 年度に定めた次のシステム構成方針を継続した。
① 体認証技術の被災者支援システム側への影響を極力少なくするため、疎結合で構成する。
② 生体認証技術を提供するベンダー固有の部分を除いて共有できる構成とする。
4.2.2.2

被災者支援システムの改修方針

被災者支援システムの改修をどのように捉えるかにより、必要な機能の仕様が影響を受けるため、改修方針検討し、平成 27 年度に定めた次の改修方針を継続した。
③ 被災者支援システムの改修はオプション機能として行う。
④ 避難行動要支援者が対象のため、身元特定は生体情報のみで 1:N 検索を行う。
⑤ 被災者支援システムのカスタマイズは必要最小限とする。
4.2.2.3

システム構成平成 27 年までの成果と上記を踏まえ、被災者支援システム上で生体認証を使って自称できない
避難者の身元特定を行うシステムのシステム構成を整理した。その結果を図 4.2-1 に示す。

それぞれの構成要素は、下記である。
①日々業務システム：例えば、避難行動要支援者管理システムのような、日常の避難行動要支援11

者の情報のメンテナンスなどの日々業務を行うためのシステムであり、被災者支援シ
ステムとは異なるシステムである。運用主体も被災者支援システムとは異なる。
住人の生体情報は、日々業務システムから連携機能を通して登録される。
②被災者支援システム：災害発生時の業務を行うためのシステム。災害発生時に事案ごとに起動される。
起動時に業務必要な情報が日々業務システム等の関連システムからコピーされる。
生体認証を利用した 1:N 検索機能等は、被災者支援システムの画面から起動される。

図 4.2-1 システム構成③連携機能：被災者支援システムと生体認証機能を接続するために用意するシステムである。
生体認証機能は提供元の生体認証機器ベンダーの仕様に依存するため、被災者支援シ
ステムが生体認証機能へ直接接続した場合、生体認証機能を提供するベンダーごとに、被災者支援システム側で複数の実装が必要になってしまう。連携機能は、それを回避するために設けるもので、オープンな環境で生体認証技術と被災者支援システムの連携を実現するために、各ベンターが用意する生体認証機能の固有の機能を吸収し、被災者支援システム向けに共通なインターフェース（連携 API）を提供する。これにより、被災者支援システムが異なるベンターが提供する生体認証機能に容易に対応できる。
また、秘密分散によるリスク低減の一環として、生体認証機能と被災者支援システム
で使用する ID を分離するため、被災者支援システムで使用する ID である「識別番号（サービス ID）」を生体認証機能で使用する ID である「連携 ID」に変換する（ID。
変換）
生体認証を用いて身元の特定を行うための機能を自治体に提供するベンターは、連携
12API 仕様を共有し、連携機能を実装し、自治体に提供することを想定している。
④連携 API：連携機能が提供し、被災者支援システムが生体認証機能を使用するための API である。連携 API に従った連携機能を生体認証機能の提供者が提供することで、被災者支援システムは統一されたインターフェースで複数の生体認証機能に対応可能になる。
⑤生体認証機能：生体認証機器ベンダーが提供する生体認証機能（システム）である。
生体認証機能の選択は被災者支援システムを運用する各自治体が選択を行う。
⑥ベンダ別 API：生体認証機器ベンダーが、自身が提供する生体認証機能に接続するために用意する API である。ベンダーが用意する生体認証機能ごとに異なることを想定している。
4.2.2.4

システムとして必要な機能

被災者支援システム側の今後のエンハンス・運用の簡便化の観点から、被災者支援システムと連携機能との連携は次の条件を満たす構成とすることとした。
①

連携機能から被災者支援システム側に検索結果を返すときは、元の検索画面ウィンドウに返す。

②

被災者支援システムと連携機能で、同一の画面ウィンドウを介して制御の遷移を行う。

以上を前提として、前述のシステム構成を念頭にして、検討を進め、避難者の身元特定を行う機能の実現のためには、次の機能が必要との結論を得た。
(1) 1:N 検索機能
避難者の生体情報の提示により、被災者支援システム上に候補となる身元情報を提示し、避難所の受付を行う担当者が達観により避難者の身元情報を特定し、避難者登録等を行う機能。
この際、担当者の達観を支援することも含め、次の機能を持たせる。
・候補となる身元情報の複数件表示とランク表示機能-

避難所の受付を行う担当者の達観を補助する機能として複数の候補者（最大 10 位）の表示機能を用意する。

-

ランク表示は、候補の確からしさを示すもの。生体認証時の機能から「ランク情報（確からしさ情報）」を基にして背景色を優先順に 3 段階に分けて表示する。

・補助検索項目の入力とそれを用いた絞り込み検索機能-

補助検索項目は、検索時の性能向上のために用意する。

-

補助検索項目は連携機能側で入力を促す。

-

検索結果を返す際に連携機能側で入力画面等を消す。

-

補助検索項目は、日々業務システムで入力されるため、その登録操作と登録情報の維持（陳腐化を防ぐ）のため、性別と生年で十分との結論となった。実際に自治体のシステムに導入する時に何を使うかは、被災者支援システムを使用する側（自治体関係
13者）の希望に従う事項とし、自治体関係者との調整により決定する事項とした。
検討した内容の詳細は、付録 1「補助検索項目検討書」として示す。
・検索処理結果-

検索処理終了後、連携機能側は戻り値として「識別番号」と「ランク情報」を戻り値として避難行動要支援者管理システムに返す。

-

生体認証での検索で候補者の該当がなかった場合、連携機能から被災者支援システムに API の戻り値として「Null」を返す

・避難行動要支援者台帳情報などを参照する機能-

担当者の達観を支援するため、被災者台帳や避難行動要支援者台帳などの情報を表示する。

・エラー対応-

エラーの場合は「エラー画面」を表示させる。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

-

表示するメッセージは、担当者が容易に対応する内容とする。

(2) 1:1 認証機能
担当者が達観で選択した避難者の「識別番号」と避難者に再提示いただいた生体情報の 1:1
認証により、避難者の身元情報が確かに正しいかの再確認を行う機能。
この機能の要否については、委員の中で議論があったが、被災者支援システムの 1:N 検索結果及び「被災者支援台帳」、「避難行動要支援者台帳」の確認でも達観で判断できない場合に
1:1 認証が有効な場合があると想定され、また、上記の 1:N 検索機能で用いる生体情報と異なる生体情報を用いることで身元情報の特定の確度が上がることも想定されるため、本人認証機
能を具備する 1:1 認証を行う機能を用意することとなった。
・候補者の身元の確認機能-

候補者の「識別番号」と「生体情報」を 1:1 認証する。

・1:1 認証処理結果-

1:1 認証処理終了後、「結果画面」を表示する。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

・エラー対応-

エラーの場合は「エラー画面」を表示させる。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

-

表示するメッセージは、担当者が容易に対応する内容とする。

(3) 生体情報登録機能
生体情報を登録する機能。
生体情報を使って避難行動要支援者の身元特定するためには、あらかじめ、その方の生体情報を登録しておく必要がある。自治体の活動で避難行動要支援者の生体情報の登録は、被災者支援システムとは連携せず、日々の業務の中の一機能として用意する。
14

この際、日々業務の中には、生体情報の登録時に 1:N 検索機能で用いる補助検索項目（性別・生年）を連携機能側に引き渡す機能を持つことが必要となる。
登録処理はインプリメント時に、自治体側の運用のルールの基に実施されることを前提に登録ログと処理時間の記録を取れる様、連携機能に API インターフェースを具備する。
・登録対象者の検索機能と登録処理指示機能-

避難行動要支援者の情報を管理している日々業務システムで登録対象者を検索し、対象者の「識別番号」等の情報を取得、表示する。

-

日々業務システムは生体情報の登録が指示できる画面を表示する-

指示ボタン押下により、連携機能に制御が遷移し、連携機能にて登録処理を実施する。
この時、「識別番号」と「補助検索項目」と遷移元（登録処理後の戻り先）画面の URL
を連携機能側に引き渡す。

・登録処理機能-「識別番号」と「補助検索項目」とともに登録する。
生体情報を取得し、・登録処理結果-

登録処理終了後、「結果画面」を表示する。

-

連携機能側が表示した画面の「閉じる」ボタンにより画面を閉じる。

-

登録処理終了後、連携機能側は「識別番号」と「処理時間（タイムスタンプ）」を戻り値として返す。

・エラー対応-

エラーの場合は「エラー画面」を表示させる。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

-

表示するメッセージは、担当者が容易に対応する内容とする。

登録処理では、自治体スタッフが登録対象者の自宅に出向いて日々業務の一環として、登録する方の生体情報を登録することが想定される。
現地にて、PC と日々業務システム及び連携機能・生体認証システムとをリアルタイム接続
するためには、モバイル VPN 等の外部から自治体ネットワーク（NW）にアクセスする NW
環境の準備と運用が必要となり、自治体地域によってはキャリアサービスの届かない地域があったり、モバイル VPN の利用を許可されていない場合があり、汎用性に欠ける側面がある。
登録機能は、オンラインシステム上での提供を前提として検討を進めたが、このように、全ての自治体でオンライン化された登録業務が可能ではないので、バッチ登録処理（オフライン
処理）の手順についても検討した。この検討内容は本項「4.2.3.4 バッチ登録処理」に記載する。
また、登録を行う日々業務システムと検索を行う被災者支援システムで、本人をユニークに特定する ID が異なる体系であることを想定し、生体認証情報の登録時の処理シーケンスの検討の要否を検討した。その結果、日々業務システムの例として検討対象とした避難行動要支援
15

者管理システムと被災者支援システムは同一体系の ID を使用しているため検討不要となり、今回の検討は見送った。
(4) 生体情報削除機能
日々業務システムの中に登録されている生体情報を削除する機能。
自治体の活動で避難行動要支援者の生体情報の削除は、被災者支援システムとは連携せず、日々の業務の中で実施されるので、日々業務の一機能として用意する。
削除処理は、日々業務システムと生体認証機能との連携において、唯一の生体情報登録対象者の操作を伴わず、自治体職員の判断により、登録済み生体情報を削除が可能となる。
削除処理はインプリメント時に、自治体側の運用のルールの基に実施されることを前提に削除ログと処理時間の記録を取れる様、連携機能に API インターフェースを具備する。

・削除対象者の検索機能と削除処理指示機能-

避難行動要支援者の情報を管理している日々業務システムで削除対象者を検索し、対象者の「識別番号」等の情報を取得、表示する。

-

日々業務システムは生体情報の削除を指示できる画面を表示する-

指示ボタン押下により、連携機能に制御が遷移し、連携機能にて削除処理を実施する。
この時、日々業務システムは、「識別番号」と遷移元（削除処理後の戻り先）画面のURL を連携機能側に引き渡す。

・削除処理機能-「識別番号」に基づき、対象者の生体情報を削除する。
実際に自治体のシステムに導入する時に、生体情報を DB から削除する際、論理削除とするか、物理削除とするかは、日々業務システムを使用する側（自治体関係者）の希望に従う事項とし、自治体関係者との調整により決定する事項とした。

・削除処理結果-

削除処理終了後、「結果画面」を表示する。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

-

連携機能側が表示した画面の指示ボタンにより画面を閉じる。

-

削除処理終了後、連携機能側は「識別番号」と「処理時間（タイムスタンプ）」を戻り値として返す。

-

日々業務システム側は、結果を受けて避難行動要支援者管理システム側が表示した生体情報の削除を促す画面のボタン表示を画面を閉じることを促すものに変更する。

-

日々業務システム側は当該ボタンのクリツクにより表示している画面を閉じる。

・エラー対応-

エラーの場合は「エラー画面」を表示させる。ただし、連携機能側で用意し、被災者支援システムに制御を遷移しない。

-

表示するメッセージは、担当者が容易に対応する内容とする。
16

(5) 登録、削除時のログ機能
自治体の日々業務の業務ログを取るための機能。
被災者支援システムを導入する自治体の日々業務システムの仕様の変更などが必要となる
ため、ログ機能実装は、自治体のシステムに導入する時に自治体関係者に検討の上、決定することとした。
実装に備え、登録、削除成功時に「識別番号」、「タイムスタンプ（処理実行時間）」を返す
インターフェースを連携機能に用意する。
日々業務システムは、連携機能側からの戻り値を基に登録処理実績を記録する。
以上の検討した内容の詳細は、付録 2「操作処理遷移（画面中心）検討書」と、付録 3「連携機能シーケンス検討書」として示す。
4.2.2.5

バッチ登録処理（オフライン処理）

生体情報登録について、下記前提・検討事項を基にバッチ登録処理の「あるべき姿」とプロトタ
イプ・システムへの実装案を検討した。
①前提：
生体情報登録は例えば避難行動要支援者管システムのような日々業務システムから、その機能が呼び出される。実際に自治体のシステムに導入する時に、登録機能は生体情報登録はオフ
ライン PC からの登録で実現される。実現案は、次の 2 案が考えられるが、実際の導入時、各案件ごとに詳細化し決定する。
・実現案 1：モバイル PC（オフライン・スタンドアロン）に蓄えた情報を入力情報として、
オンライン環境での登録処理プロセスを疑似的に動作させる。
・実現案 2：生体情報登録に必要なデータを全て特定し、サーバシステムにコピーする②検討事項：
生体情報登録は該当者がいる現地にスタッフが赴き、持参したモバイル PC にて登録する。
モバイル PC での登録処理は、次の「前処理」、「現地処理」、「後処理」の 3 行程からなる。
・前処理：自治体内 NW オンライン環境で、生体情報登録該当者の情報（識別番号他個人を特定する情報）を日々業務システムから抽出する。
・現地処理：事前に抽出した生体情報登録該当者の情報を入力とした日々業務システムの中の「生体情報登録」機能から、「連携機能」を通して生体認証機能の中の「登録機能」を呼び出し、生体情報登録を行う。
また、登録誤り抑止のため、登録後に 1:1 認証を行い登録した「識別番号」と「生体情報」の正当性を確認する。
この現地処理は、連携 API 及び引数にて実現可能である。
・後処理：帰庁後にモバイル PC から連携機能・生体認証システムに生体情報データを登録する。なお、バッチ登録処理でサーバへ登録した生体情報は、個人情報保護の観17

点からオンライン処理以外に本人の生体情報を使っての直接確認は基本的にできないものとする。
上記の検討事項を踏まえ、検討委員会にて検討した「バッチ登録処理概略」を図 4.2-2 に示す。

図 4.2-2 バッチ登録 処理概略図

18後処理の実装案は、表 4.2-1 の 2 案が考えられるが、実際に自治体のシステムに導入する時に、表 4.2-1 に示す方式比較より実現方法を検討の上、各案件ごとに詳細化し決定することとした。
また、生体情報（テンプレート）を生体認証システム外部で取り扱うため、情報流出に関するリスクヘッジが必要となる。
表 4.2-1 バッチ処理 後処理実現案比較

なお、実際に自治体のシステムに導入する時に実現案 2 が採用された場合、詳細仕様検討の結果によっては連携機能に修正が必要になることが考えられる。この場合、修正後も、本事業の主旨である「オープンシステムへの対応」、「生体認証技術の自由な選択性の確保」が確保されることが望まれるため、JAISA と被災者支援システム側及び各生体認証機能の提供者の協議において、変更仕様が決められ、変更後の仕様が生体認証機能の提供間で共有されることが望まれる。
登録のオフライン処理について検討した内容の詳細は、付録 4 に「オフライン登録処理検討書（オフライン登録処理案）」として示す。
4.2.2.6

連携機能動作環境

連携機能は、生体認証を用いて身元の特定を行うための機能を自治体に提供する提供者で仕様を共有し、連携 API 仕様に従い提供者が実装し提供することを想定しているため、その動作環境としてオープンプラットフォームを選択して仕様を検討した。
次に検討に用いた動作環境を示す。
・OS：CentOS 7.0、アプリケーションサーバ：Tomcat 8.5（Java8）

19

4.2.3

API 仕様実現可否や使い勝手、システムの分界点などを勘案しながら、被災者支援システムと連携機能・
生体認証機能（システム）が連携するための API 仕様を検討した。
図 4.2-1 に示すように、システム構成上、API は次の 2 つある。
(1) 連携 API
被災者支援システムと連携機能間の API である。
オープンな環境で生体認証技術と被災者支援機能の連携を実現するために用意するもので、被災者支援システムへの生体認証機能の提供はこの連携 API を介して提供する。
(2) ベンタ別 API
連携機能と生体認証機能間の API である。これは、各ベンターが用意する生体認証機能の固有の API である。そのため、本報告書では触れない。
被災者支援システムと生体認証機能の連携は、連携 API を介して行う。そのため、生体認証機
能の提供者が機能の提供の際は連携 API 仕様に従うことが必要である。連携 API 仕様を検討した
内容を次に示す。
4.2.3.1

連携 API 仕様

連携機能は、被災者支援システムのサーバ側プログラムから起動されることを想定し Web ページとして実装する。連携 API は、下記の「1:N 検索」、
「1:1 認証」、「登録」及び「削除」機能を実現するための API である。
(1) 連携 API 機能①1:N 検索： 生体情報を受け取り、該当者 ID を検索する機能である。生体情報を用いた ID の検索処理は、生体認証機能にて実行される。
②1:1 認証： ID と生体情報を受け取り、ID とその生体情報の組み合わせが正当なものであるかを検証する機能である。ID と生体情報の照合処理は生体認証機能にて実行される。
③登録：

ID と生体情報を受け取り、当該生体情報をデータベースに保存するための機能である。生体情報は生体認証機能がもつデータベースに保存される。

④削除:

ID を受け取り、データベースから ID と ID に紐づく生体情報を削除する機能である。

20

(2) 連携 API のインターフェース仕様
連携 API 機能インターフェースと各インターフェースの引数と戻り値を以下に示す。
①1:N 検索
被災者支援システム側（1:N 検索）の呼び出し： POST メソッドによる

引数：1:N 検索機能の引数はフォームデータとして指定する。
表 4.2-2 1:N 検索の引数
#
1.

引数
tckt

型
string説明
被災者支援システムが発行したワンタイムチケッ
トを指定する。不要な場合は指定なし（Null）で
も可。

2.

fltr

string補助検索項目を指定する。複数指定された場合は、指定されたすべての条件を AND で検索する。
※連携機能側で設定する画面を用意する。被災者
支援システムからは‘Null’となる。
※プロトタイプ・システムは複数指定されても最初の項目のみ有効とする。

3.

rtn

string

戻り先 URL。連携機能は生体情報を使用して候補者の ID リストを抽出した後、本引数に指定された
URL に POST 指示を行う。

4.

rtn2

string

戻り先ウィンドウ名。連携機能が引数 rtn に指定された URL に POST する際、ターゲットとして本引数に指定されたウィンドウ名を使用する。

戻り値：処理結果が正常の場合：引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#１、#2、#3 パラメータを含む。
処理結果が異常の場合：連携機能で下記の#4、#5 パラメータに従ってエラーメッセー
ジ画面を表示し、画面の閉じるボタンで画面を閉じる。

21

表 4.2-3 1:N 検索の戻り値
#
1.

引数
tckt

型
string説明
被災者支援システムが発行したワンタイムチケッ
ト。引数で渡されたワンタイムチケットそのもの。
指定されなかった場合、空文字列を返す。

2.

id0 … id9

string

候補者の ID。候補者が複数存在する場合、候補者の数だけ複数指定する。本人である確率が高い順に id0 から指定される。候補者が存在しない場合、指定なし（Null）。例えば、サービス ID＝abc とサービス ID＝xyz の 2 名がヒットし、abc の方がより本人である確率が高い場合、id0=abc、id1=xyzと指定する。

3.

id0_rnk … id9_rnk

string

候補者のランク（1、2、3 のどれかが指定される）。
候補者が複数存在する場合、候補者の数だけ複数指定する。1、2、3 の順で本人である確率が高い
ことを示す。どの値を使用するかは生体認証機能（システム）に依存する。

4.

err

string連携機能または生体認証機能（システム）でエラーが発生した場合のエラー内容を通知する。正常処理の場合は指定なし（Null 値）。

5.

ecd

string

生体認証システムでエラーが発生した場合、生体認証機能（システム）から受信したエラーコードを通知する。

例外：生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、POST 指示を行わず、画面にエラーメッセージを表示する。

②1:1 認証
被災者支援システム側（1:1 認証）の呼び出し： POST メソッドによる

引数：1:1 認証機能の引数はフォームデータとして指定する。

22

表 4.2-4 1:1 認証の引数
#
1.

引数
tckt

型
string説明
被災者支援システムが発行したワンタイムチケッ
トを指定する。不要な場合は指定なし（Null）で
も可。

2.

id

string

本人確認する利用者のサービス ID

3.

rtn

string

戻り先 URL。連携機能は生体情報を使用して候補者の ID リストを抽出した後、本引数に指定された
URL に POST 指示を行う。

戻り値：処理結果が正常の場合：正常処理結果（確認、不一致）画面を表示し、画面の閉じる
ボタンで画面を閉じる。
「rslt」= ”y”： 一致確認
「rslt」= ”n”： 不一致
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#１、#2 パラメータを含む。
処理結果が異常の場合：連携機能により、該当するエラーコード「err」とエラーメッ
セージ「msg」に従いエラーメッセージ画面を表示し、エラーメッセージ画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#3、#4、#5 パラメータを含む。
表 4.2-5 1:1 認証の戻り値#
1. tckt

引数型
string説明
被災者支援システムが発行したワンタイムチケッ
ト。引数で渡されたワンタイムチケットそのもの。

2. rslt

string

生体情報が一致したかどうか。
”y”：一致した。”n”：一致しなかった。

3. errstring連携機能または生体認証機能（システム）でエラーが発生した場合のエラー内容を通知する。正常処理の場合は指定なし（Null 値）。

4. ecdstring

生体認証機能（システム）でエラーが発生した場
合、生体認証機能（システム）ムから受信したエ
ラーコードを通知する。

5. msgstringecd に該当するエラーメッセージを通知する。

23

例外：生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、POST 指示を行わず、画面にエラーメッセージを表示する。

③登録
日々業務システム側（登録）の呼び出し： POST メソッドによる

引数：登録機能の引数はフォームデータとして指定する。
表 4.2-6 登録の引数
#
1.

引数
tckt

型
string説明
被災者支援システムが発行したワンタイムチケッ
トを指定する。不要な場合は指定なし（Null）で
も可。

2.

id

string

生体情報を登録する利用者のサービス ID

3.

fltr

string補助検索項目を指定する。複数指定された場合は、指定されたすべての条件を追加する。
※プロトタイプ・システムは複数指定されても最初の項目のみ有効とする。

4.

rtn

string

戻り先 URL。登録機能が完了された後、本引数に指定された URL に POST 指示を行う。

戻り値：処理結果が正常の場合：正常処理結果画面を表示し、画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#１、#2、#3 パラメータを含む。
処理結果が異常の場合：連携機能により、該当するエラーコード「err」とエラーメッ
セージ「msg」に従いエラーメッセージ画面を表示し、エラー
メッセージ画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#3、#4 パラメータを含む。

24

表 4.2-7 登録の戻り値
#
1.

引数
rslt

型
string説明
生体情報が登録できたかどうか。
”y”：登録した。”n”：登録できなかった。

2.

id

string

生体情報を登録する利用者のサービス ID

3.

timestamp

string

登録処理を行った日時。yyyyMMddHHmmss で表記。連携機能及び生体認証機能（システム）のどちらで取得してもよい。

4.

err

string連携機能または生体認証機能（システム）でエラーが発生した場合のエラー内容を通知する。正常処理の場合は指定なし（Null 値）。

5.

ecd

string

生体認証機能（システム）でエラーが発生した場
合、生体認証機能（システム）から受信したエラー
コードを通知する。

例外：生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、エラーメッセージを表示する。

④削除
日々業務システム側（削除）の呼び出し： POST メソッドによる

引数：削除機能の引数はフォームデータとして指定する。
表 4.2-8 削除の引数
#
1.

引数
tckt

型
string説明
被災者支援システムが発行したワンタイムチケッ
トを指定する。不要な場合は指定なし（Null）で
も可。

2.

id

string

本人確認する利用者のサービス ID

3.

rtn

string

戻り先 URL。削除機能が完了された後、本引数に指定された URL に POST 指示を行う。

戻り値：処理結果が正常の場合：正常処理結果画面を表示し、画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#１、#2、#3 パラメータを含む。
25

処理結果が異常の場合：連携機能により、該当するエラーコード「err」とエラーメッ
セージ「msg」に従いエラーメッセージ画面を表示し、エラーメッセージ画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の#3、#4 パラメータを含む。
表 4.2-9 登録の戻り値
#
1.

引数
rslt

型
string説明
生体情報が削除できたかどうか。
”y”：削除した。”n”：削除できなかった。

2.

id

string

生体情報を削除する利用者のサービス ID

3.

timestamp

string

削除処理を行った日時。yyyyMMddHHmmss で表記。連携機能及び生体認証機能（システム）のどちらで取得してもよい

4.

err

string連携機能または生体認証機能（システム）でエラーが発生した場合のエラー内容を通知する。正常処理の場合は指定なし（Null 値）。

5.

ecd

string

生体認証機能（システム）でエラーが発生した場
合、生体認証機能（システム）から受信したエラー
コードを通知する。

例外：id に指定されたサービス ID が登録されていないなどのエラーが発生した場合は、エラー
メッセージを表示する。
(4) タイムスタンプのフォーマット
登録及び削除の戻り値の「timestamp」は、数字 8 桁（yyyyMMddHHmmss）で表記する。
それぞれの表記ルールについて示す。
表 4.2-10 タイムスタンプの表記
#

位置

桁

説明

1.

yyyy

4桁

西暦 4 桁の年を表す。

2.

MM

2桁

月を表す。1 桁の場合は先頭に 0 を付ける。

3.

dd

2桁

日を表す。1 桁の場合は先頭に 0 を付ける。

4.

HH

2桁

時を表す。24 時間制。1 桁の場合は先頭に 0 を付ける。

5.

mm

2桁

分を表す。1 桁の場合は先頭に 0 を付ける。

6.

ss

2桁

秒を表す。1 桁の場合は先頭に 0 を付ける。

26

(5) 連携 API のエラーコード
API の戻り値 err に指定される値を表 4.2-11 に示す。発生したエラー（エラーコード）に対し、現場操作者が出来る主な対処方法と判り易いメッセージ表示とした。
(6) 外部パラメータ設定
エラーメッセージ等、連携機能をインプリメントする際に最適化に向け設定するパラメータについて以下に示す。
外部パラメータ名：Constants.jsp
設定項目：①生体認証サーバの設定：接続連携する生体認証サーバの URL 等②画面用メッセージの設定：連携機能から生成するウィンドウメッセージ③エラーメッセージ：表 4.2-11 エラーコード表のユーザーへのメッセージ
上記設定項目を各自治体ごとに設定することで、連携機能のプログラムコードを改変することなく、実装が可能となる。

生体認証機能（システム）自体の設定については、各生体認証機能（システム）の設定仕様に従う。
実際に自治体のシステムに導入する時に各社の方針により、提供システムに連携機能を実装する場合においても、上記設定項目について、外部パラメータ化されることが望ましい。

27

表 4.2-11 エラーコード表
1.

#

値
null

説明
処理は正常に完了した。

主な対処方法―2.

b

生体認証機能がエラーを返した。

ecd の内容を参照し、生体認証機能の指示に従う。

3.

c1

生体認証機器が接続されていない

生体認証機器が PC に接続されていることを確認し、再実行。

制限時間内に生体情報の撮影が完了しなかった（指や掌が置かれなかった、顔が認識できなかったなど）
撮影に失敗した（ペンなどの生体以外の物体が提示されたことを検知したなど）ユーザーへのメッセージ―
生体認証システムでエラーが発生しました。管理者にお問い合わせください（b:＜生体認証システムのコード＞）。
生体認証機器が接続されているか確認してください(c1)。

再実行し制限時間までに生体を提示

生体情報が読み取れませんでした。もう一度実行してください(c2)。

再実行し正しく生体を提示（正しい提示の方法は、生体認証機能のベン
ダーに依存）

生体情報が読み取れませんでした。もう一度実行してください(c3)。

cx

その他、生体情報の撮影に関するエラーecd の内容を参照し、生体認証機能の指示に従う。

生体情報が読み取れませんでした。管理者にお問い合
わせください(cx: ＜生体認
証機能のコード＞)。

7.

s1

生体認証機能に接続できなかった

・ 生体認証機能が正常稼働していることを確認し、再実行
・ 生体認証機能の接続先設定が正しいことを確認し、再実行

生体認証システムに接続できませんでした。管理者にお問い合わせください(s1)。

8.

s2データベースへの接続でエラー

DBMS が正常稼働していることを確認し、再実行連携システムでエラーが発生しました。管理者に問い合わせください(s2)。

9.

s3

指定されたサービス ID
は、システムに存在しないサービス ID を修正して再実行指定された ID は登録されていません(s3)。

10. s4

必須パラメータが不足している

11. s5

パラメータに指定された値が正しくない（書式不正、範囲外等）

12. sx

連携機能でのその他エ
ラー

4.

5.

6.

c2

c3

パラメータを修正（主に開発中に発生する問題であり運用中に発生する可能性は低い）
パラメータを修正（主に開発中に発生する問題であり運用中に発生する可能性は低い）
連携機能の稼働状況を確認。

連携 API 仕様の詳細は、付録 5「連携機能詳細仕様書」に示す。

28

内部エラーが発生しました。管理者にお問い合わせください(s4)。
内部エラーが発生しました。管理者にお問い合わせください(s5)。
連携システムでエラーが発生しました。管理者に問い合わせください(sx)。

4.2.4

画面等の仕様

被災者支援システムと連携機能で用意する画面等の仕様を検討した。
4.2.41

被災者支援システムで用意する画面等の仕様(1) 被災者支援システムの改修内容
被災者支援システムの改修方針と避難者の身元特定を行うシステムに必要な機能の検討結果を基に、被災者支援システムの改修内容について検討し、次を改修内容とした。
① オプション機能としての位置づけから、避難所関連システムメニューに組み込むのではなく、総合メニューに「避難所関連オプション」として独立メニューを作成する。生体認証 確認・検索画面の項目を追加し実行ボタンをクリックすることで生体認証検索用
画面に遷移する。
② 避難所にて身元情報を得るため生体認証検索画面を作成する。
③ 1:N 検索に対応するため複数の候補者をリスト表示する機能を持たせる。
この際、候補の確からしさを表示する機能を持たせる。
④ 生体認証検索ボタンを作成しクリックすることで連携機能に必要項目を POST リクエス
トし 1:N 検索の制御を連携機能に移す。戻り値として複数の「識別番号」を受け取り、
リスト表示する。
⑤ 1:N 検索における検索精度及び検索効率向上のための補助検索項目の入力のための GUI（ユーザインターフェース）は連携機能側での実装することとし、被災者支援システム
でカスタマイズは実施しない。
⑥ 連携機能、及び生体認証機器で発生したエラーは連携機能側で適切な処理を行うこととし、被災者支援システムではカスタマイズは実施しない。
⑦ 複数候補者があった場合、職員による達観での本人特定を補助する手段として、被災者台帳・避難行動要支援者台帳の画面参照機能を用意する。被災者台帳、避難行動用支援者台帳の参照につてはデータ不整合を防止するため、更新やその他別画面への遷移を制限した専用画面を作成する。なお、表示内容は既存の画面と同一のものとする。
⑧ 職員による達観で本人を特定した後でもう一度、生体情報を使用して身元特定が行える機能を用意する。本人確認ボタンを用意しクリックすることで、連携機能に「識別番号」
及び「必要項目」を POST リクエスト（1:1 認証)し、制御を連携機能に移す。
本人確認結果を連携機能側で画面表示する。
⑨ 身元特定後は避難所関連システムに避難者情報として登録を行う機能を用意する。その際には特定した「識別番号」から「必要項目」を抽出して入力効率の向上を図る。

29

(2) 画面イメージ(A) 被災者支援システム 総合メニュー(改修)· 被災者支援システム 総合メニューに「避難所関連オプション」の項目を追加する。
· 「生体認証 確認・検索画面」メニューの「実行」ボタンのクリックで生体認証検索用画面に遷移する。

追加部

図 4.2-3 総合メニューからの選択画面(B) 生体認証検索用画面（新規作成）· 生体認証検索用画面を新規に用意する。
· 「生体認証検索」ボタンのクリックで生体認証検索用画面に遷移する。

図 4.2-4 生体認証による検索開始画面

30

(C) 検索結果表示画面（新規作成）· 1:N 検索結果の複数の「識別番号」を受けて、複数の候補者をリスト表示する画面を新規に用意する。
「漢字氏名」· 受け取った「識別番号」をもとに被災者台帳を検索し、該当者の「ｶﾅ氏名」「世帯番号」「識別 NO（「識別番号」）」「生年月日」「性別」「被災時住所」を表示する。

· 「識別番号」ごとの「ランク情報」に従い、候補者表示行の色を変えて表示する。

図 4.2-5 検索結果表示画面(D) 被災者台帳個人詳細画面（新規作成）· 検索結果表示画面から呼び出される専用の被災者台帳参照画面を作成する。
· データ更新、他の画面への遷移するボタン等は非表示とする。
· 「戻る」ボタンのクリックで、画面を閉じ、生体認証検索画面に戻る。

図 4.2-6 被災者台帳個人詳細表示画面
31

(E) 避難行動要支援者台帳画面（新規作成）· 検索結果表示画面から呼び出される専用の避難行動要支援者台帳画面を作成する。
· データ更新、他の画面への遷移するボタン等は非表示とする。
· 「閉じる」ボタンのクリックで、画面を閉じ、生体認証検索画面に戻る。

図 4.2-7 避難行動要支援者台帳情報表示画面

32

(F) 避難者登録画面（新規作成）· 検索結果表示画面から呼び出される専用の避難者登録画面を作成する。
· 他の画面への遷移するボタン等は非表示とする。
「識別番号」）」を元に、被災者台帳データを読み込み、必要な項目を初期· 「識別 NO（表示する。また「識別番号」の項目は変更が出来ないように制限する。
· 「登録」ボタンのクリックで、入力されたデータを DB に登録後、画面を閉じ生体認
証検索画面に戻る。
· 「戻る」ボタンのクリックで、画面を閉じ検索結果表示画面に戻る。
· 同一避難所、同一識別コードのデータが既に存在する場合は「既に登録されています。
」とメッセージ表示し登録処理をキャンセルする。

図 4.2-8 避難者登録画面

33

4.2.4.2

日々業務システムで用意する画面等の仕様（参考）日々業務で用いているシステムは現在のところ各自治体が独自に用意しており、その具体的な回収方針まで、この研究開発で規定するのは、自治体からの参加者の責任範囲を超えるので、参考として言及することとし、取り組み方針について検討し、下記とした。
① 日々業務システムの改修を行う際の指針を示す。
② 具体的な改修内容は、実際にシステムを構築際に導入関係者で検討し、決定する。
(1) 日々業務システムの改修指針
改修方針を勘案しながら、日々業務システムの例として避難行動要支援者管理システムを対象として、改修指針について検討し、次を改修指針とした。
① 日々業務システムで生体情報登録あるいは削除対象者を検索し、諸情報を生体情報の登録あるいは削除を行う画面に表示する。
② 日々業務システムの生体情報の登録あるいは削除を行う画面に、「登録」「削除」機能の実行を指示するボタンを用意し、ボタンのクリックで「登録」「削除」機能に遷移する。
(2) 画面イメージ（参考）(A) 「登録」「削除」呼び出しボタン配置· 「登録」「削除」ボタンのクリックで、操作の意思を確認するための「生体認証管理」
画面を重ね合わせ表示する。

図 4.2-9 避難行動要支援者管理システムでの改修イメージ画面

34

(B) 登録時の生体認証管理画面· 登録機能は庁内 NW 環境にてオンライン処理されることを前提とする。
· 「次へ」のクリックで、連携機能を呼び出し、登録機能に遷移する。
· 避難行動要支援者管理システムの画面に表示されている「宛名 No」が「識別番号」として、「性別」及び「生年」が補助検索項目として連携機能に引き継がれる。

図 4.2-10 登録時の生体認証管理画面

35

(C) 削除時の生体認証管理画面· 削除機能は庁内 NW 環境にてオンライン処理されることを前提とする。
· 「はい」のボタンにより、連携機能を呼び出し、削除機能に遷移する。
· 避難行動要支援者管理システムの画面に表示されている「宛名 No」が「識別番号」として、連携機能に引き継がれる。

図 4.2-11 削除時の生体認証管理画面

36

4.2.4.3

連携機能で用意する画面等の仕様連携機能で用意する画面は、連携機能を実際に自治体のシステムに導入する時に、自治体関係者と協議し、各案件ごとに詳細化し決定する。画面イメージは一例として示す。
次の画面の用意が必要である。

①1:N 検索時の補助検索項目の入力画面
下図に一例を示す。

図 4.2-12 1:N 検索時の補助検索項目の入力画面②1:N 検索時の生体情報提示を促す画面
これは、生体認証機能を提供する生体認証ベンターの生体認証機能により表示される画面である。生体認証ベンターごとに異なるので詳細はここでは触れない。

③1:N 検索時のエラー表示画面
下図に一例を示す。

図 4.2-13 1:N 検索時のエラー表示画面37

④1:1 認証時の生体情報提示を促す画面
これは、生体認証機能を提供する生体認証ベンターの生体認証機能により表示される画面である。生体認証ベンターごとに異なるので詳細はここでは触れない。

⑤1:1 認証時の確認結果（一致、不一致）を示す画面
これは、補助検索項目情報を得るための画面であり、生体認証機能を提供する提供者と導入
自治体との協議により詳細を決めて用意する画面である。下図に一例を示す。

図 4.2-14 1:1 認証時の確認結果表示画面（一致時）

図 4.2-15 1:1 認証時の確認結果表示画面（不一致時）⑥1:1 認証時のエラー表示画面
下図に一例を示す。

図 4.2-16 1:1 認証時のエラー表示画面

38

⑦生体情報登録時の生体情報提示を促す画面
これは、生体認証機能を提供する生体認証ベンターの生体認証機能により表示される画面である。詳細はここでは触れない。

⑧生体情報登録時の登録成功を示す画面
下図に一例を示す。

図 4.2-17 1:1 認証時の確認結果表示画面（一致時）⑥生体情報登録時のエラー表示画面
下図に一例を示す。

図 4.2-18 生体情報登録時のエラー表示画面⑧生体情報削除時の削除成功を示す画面
下図に一例を示す。

図 4.2-19 生体情報削除時の削除成功表示画面（一致時）39

⑥生体情報削除時のエラー表示画面
下図に一例を示す。

図 4.2-20 生体情報削除時のエラー表示画面

40

4.3

プロトタイプ・プログラムの開発

本節に先立つ調査活動でまとめた、生体認証技術を応用する被災者支援システムの仕様及び必要な機能に基づき、西宮市情報センターが運用・管理している被災者支援システムと連携し、被災者支援
システム上で生体認証を活用して身元特定を実現するプロトタイプ・プログラムの開発に取り組んだ。
4.3.1

被災者支援システム側の開発

4.3.1.1

プロトタイプ・システム開発概要「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」の成果に基づき、災者支援システムの次の部分に変更を加える開発を行った。
① 災者支援システムにおける生体認証検索用のメニューの新規作成
・総合メニュープログラムの改修② 同、生体認証検索用の画面の新規作成
・各種画面へ遷移するボタンの作成
・避難所及び入所日の入力項目の作成
・検索結果一覧の表示（複数の対象者への対応を行う）③ 同、生体認証検索用の被災者台帳の参照画面の新規作成④ 同、生体認証検索用の避難行動要支援者台帳の参照画面の新規作成⑤ 同、生体認証検索用の避難者登録の画面の新規作成⑥ 連携サーバへ必要データを送信するインターフェースの作成（1:N 検索）⑦ 連携サーバから必要データを受け取るインターフェースの作成（1:N 検索）⑧ 連携サーバへ必要データを送信するインターフェースの作成（1:1 認証）⑨ その他：発表会にむけての環境整備、データ作成等

4.3.2

連携及び生体認証システム側の開発

4.3.2.1

プロトタイプ・システム開発概要「生体認証を用いた被災者支援システム構築のための調査（連携及び生体認証側）」の成果をもとに、連携及び生体認証側プロトタイプ・システムの実装方法の検討及びプログラム開発に取り組んだ。
以下に具体的な作業項目を記す。
①連携機能プロトタイプ・システムの実装検討②連携機能プロトタイプ・プログラムの開発

41

4.3.2.2

プロトタイプ・システム仕様(1) システム概要と開発範囲
図 4.3-1にプロトタイプ・システムの概要と生開発範囲を示す。

図 4.3-1 プロトタイプ・システム概要図

生体認証側のプロトタイプ・システムの開発範囲は、被災者支援システムと生体認証機能を連携させる「連携機能」の開発を主とし、生体認証機能は日立製作所製「指静脈認証システム」
を使用し、その改修はしないことを前提とした。
上記前提を踏まえて、プロトタイプ・システム開発における開発範囲（スコープ）について、
開発期間・開発規模の制約を考慮し、「あるべき姿」に基づき、被災者支援システム側及び検討委員会にて検討を重ね、開発する仕様を決定した。次に、決定した「プロトタイプ・システム」の仕様を「あるべき姿」との差異を中心に以下に示す。
(2) プロトタイプ・システム機能（「あるべき姿」との違い）の概要①1:N 検索ⅰ) 補助検索項目は性別の 1 つのみとする。
ⅱ) 1:N 検索された１名分の識別番号（サービス ID）を返す。
ⅲ) ランク情報（確からしさ情報）も 1 番のみを被災者支援システムに返す。
（被災者支援システムは 3 段階の色分け表示も最優先のみとなる）②1:1 認証「あるべき姿」と同じ仕様とする。
③登録ⅰ) バッチ登録処理破、方法論を示すだけで、プロトタイプには実装しない。
ⅱ) 連携機能、及び生体認証サーバはローカルで行う。
（ノート PC の中に検証実験環境を作
42

り込む）
ⅲ) 連携機能側に、日々業務システムとしてデモ用登録「避難行動要支援者管理 情報参照、
「性別」を指定することで、疑似的画面」を用意し、クライアント PC から「宛先 No」に生体情報が登録できるようにする。
ⅳ) 連携機能に引き渡す補助検索項目は性別のみとする。
④削除（ノート PC の中に検証実験環境を作ⅰ) 連携機能、及び生体認証サーバはローカルで行う。
り込む）
ⅱ) 連携機能側にデモ用削除「避難行動要支援者管理 情報参照画面」を用意し、クライア
ント PC から「宛先 No」を指定することで、疑似的に生体情報が削除できる様にする。
(3) プロトタイプ連携機能（「あるべき姿」との違い）の概要①ID 変換当初は、ID の変換は連携機能内で、ID 変換データベース（DB）を用意し変換する「DB変換」を考えていたが、下記理由により「暗号変換ロジック」による変換処理とした。
「識別番号」と「連携 ID」のペアを目視できない。
理由ⅰ) 「暗号変換ロジック」は、「識別番号」と「連携 ID」とのペアを DB 上からも確認できない様にすることで、生体情報と被災者支援側の個人情報との関連の秘匿性が高まる。
理由ⅱ) DB 使用しないことにより、DBMS を構築、運用する作業負担がない。
また、連携機能側にテーブル及び DB を保持しないために DISK リソースを使用しない。
暗号変換ロジックにおける ID 変換の概念を以下に記す。
ⅰ）連携 ID 生成：「識別番号」 + 「暗号変換ロジック」＝ 「連携 ID」
ⅱ）識別番号の復元：「連携 ID」－ 「暗号変換ロジック」 ＝ 「識別番号」
元になる「識別番号」に暗号変換ロジックを足し引きすることで、「連携 ID」との変換を行う。
暗号変換ロジックに変更により、「DB 変換」に対し日常の運用において DB クラッシュも含めたリスクや運用工数低減につながると考えられる。暗号変換ロジックは連携プロトタイ
プ・プログラム上に実装する。
この方式も生体認証機器ベンダーで共有できる機能とした。
②連携 API
連携 API は、被災者支援システムのサーバ側プログラムから起動されることを想定し Web
ページとして実装する。
被災者支援システム側からの各機能の呼び出しは、POST メソッドでアクセスするため
43

フォームデータにて実行される。その際、被災者支援システムから連携機能へ各機能 API に定義された引数にてデータ連携する。逆に、連携機能（生体認証システム）からの応答は同様に定義された戻り値として、被災者支援システムに返す。

4.3.3

被災者支援システムと連携及び生体認証側の連動テスト

前節で述べた仕様に従ってプロトタイプ・システムを開発し、被災者支援システムと連携及び生体認証側の連動テストを実施した。その内容について述べる。
(1) 連動テストの目的
被災者支援システム（デモ）システムと連携機能と生体認証機能の接続連携動作の確認(2) 連動テストの期間／連動テスト実施場所
期間：2017 年 1 月 18 日（水）から 19 日（木）場所：西宮市情報センター（被災者支援システム全国サポートセンター）(3) 連動テスト用システムの概要
連動テスト用に構築したシステムの概念を図 4.3-2 に示す。

図 4.3-2 .連動テスト用システム構成概念図
連動テスト用システムは、西宮市情報センター（被災者支援システム全国サポートセンター）
にてインターネット環境で運用されている「被災者支援デモシステム」に対し、「連携、生体認証サーバ」（連携機能+生体認証機能サーバシステムをノート PC 仮想環境に実装）、「検証用
PC」（検索、確認、登録、削除などを行うクライアント PC）をテスト会場建屋内 LAN 環境に構築した。
建屋内 LAN 環境の PC は HUB、ルータを経由してインターネット環境に接続した。
(4) 連動テスト用連携及び生体認証側システムのスペック
以下に連動テスト用に準備した、連携及び生体認証側システムのスペックを以下に記す。

44

①連携、生体認証サーバ（Hyhper-V 仮想環境構成）
ⅰ）ハードスペック （HP EliteBook 820 G2/CT Notebook PC）
CPU：インテル® Core™ i7-5600U プロセッサー（4MB キャッシュ、2.6-3.2GHz）
メモリ：16GB
OS：Windows 8.1 Update （64bit）（日本語）ⅱ）連携機能 ソフト構成
OS：CentOS 7.0
アプリケーションサーバ:Tomcat 8.5（Java8）ⅲ）生体認証サーバ（指静脈認証） ソフト構成
OS：Windows 2012 R2
DBMS：SQL Server 2012
アプリケーションサーバ：ASP.NET 4.0
生体認証機能:日立ソリューションズ 認証管理システム AUthentiGate 05-01(サーバ)②検証用 PCⅰ）ハードスペック （HP EliteBook 820 G2/CT Notebook PC）
CPU：インテル® Core™ i7-5600U プロセッサー（4MB キャッシュ、2.6-3.2GHz）
メモリ：16GBⅱ）ソフト構成
OS：Windows 8.1 Update （64bit）（日本語）
Web ブラウザ:Internet Explorer 11
生体認証機能:日立ソリューションズ 認証管理システム AUthentiGate 05-01(ｸﾗｲｱﾝﾄ)(5) 連動テストでのシステム性能検証結果
被災者支援システムとの画面制御連携において、インターネットエクスプローラ設定が原因による想定外の画面遷移が発生したが、被災者支援システム～連携機能～生体認証システム間のデータ連携は設計仕様通りの動作が確認できた。また性能、精度ともに妥当な結果が得られた。
連動テストの結果を以下に示す。
・登録生体情報(指数)： 事前登録済み：約 1,000 本、当日登録数：3 本
・操作回数：
・登録： 20 回
・検索（1:N 検索）：

62 回

・本人確認（1:1 認証）：26 回・削除： 19 回
・画面操作レスポンス（連携機能へ制御渡し～生体認証結果表示迄）：・登録： 1 秒以下：
・検索（1:N 検索）

1 秒以下
45

・本人確認（1:1 認証）： 1 秒以下・削除： 1 秒以下・発生したエラー：
・タイムアウト： 5 回（タイムアウト発生状況の確認。画面操作後約 15 秒でタイ
ムアウト）
・認証不一致： 13 回 （登録と異なる指での動作確認）
・他人受入： 誤認証無し
上記より、実仕様に十分耐える性能が出ていることが確認できた。
(6) 連動テスト時の課題と対応
連動テスト時の課題として何件か課題が発生した。
これらの事象は PC により発生する場合と発生しない場合があった。連携機能を呼び出す被災者支援システムのプログラムコーディング以外の原因も検討する必要があり、Web 上の公開
情報を検索して同様な事例とその対策を探り、対策を講じることで現象を解消することができた。
課題 1：連携機能から被災者支援へウィンドウ画面の制御を遷移する際、遷移元の被災者支援システムウィンドウではなく、新しい被災者支援システムのウィンドウが生成され、そこに制御がわたってしまう。
対策 1：インターネットエクスプローラの「インタネットオプション」－「セキュリティ－レベルのカスタマイズ」から「異なるドメイン間のウィンドウとフレームの移動」の「有効にする」にチェックを入れ有効にする。
課題 2：連携サーバから被災者支援システムへ１：Ｎ検索結果が呼び出し元のウィンド
ウに戻らず、新規ウィンドウが開き、リダイレクトされてしまう。
対策 2：これは、調査の結果、操作クライアント PC の Windows において、「管理者権限」のあるユーザーでログインすると発生することが判明した。システム側での制御は不可能なため、操作クライアント PC のログインユーザは「一般ユーザー権限」であることを動作条件とすることで解決した。
これは OS の仕様のため、システム側での制御は不可能なため、基礎自治体のセ
キュリティポリシー上、Windows パソコンを管理者権限で、運用することは少ないと考えられるが、実運用時のセットアップにおいては留意する必要がある。

46

4.4

プロトタイプ・システムの有効性の検証

被災者支援システム上で生体認証を活用して身元特定を実現するプロトタイプ・プログラムの有効性の検証のため、「被災者支援システム上で生体認証を用いて身元の特定を行うための研究成果の発表ならびに展示会」（以下、発表・展示体験会と略す）を開催し、プロトタイプ・システムの有効性をシステム性能の観点と利用者側の観点から検証した。
ここでは、その結果について述べる。
4.4.1

発表・体験会用デモシステム概要(1) デモシステム概要
発表・展示体験会用に構築したデモシステム概念図を図 4.4-1 に示す。

図 4.4-1 発表・展示体験会デモシステム構成概念図
発表・展示体験会デモシステムは、西宮市情報センター（被災者支援システム全国サポートセンター）にてインターネット環境で運用されている「被災者支援デモシステム」に対し、「連
携、生体認証サーバ」（連携機能+生体認証機能サーバシステムをノート PC 仮想環境に実装）、「登録用 PC」、「認証用 PC（検索、確認を行うクライアント PC）」を会場建屋内 LAN 環境に構築した。会場内 PC は、HUB、ルータを経由してインターネット環境に接続した。
(2) デモシステムの連携及び生体認証側スペック
以下に、発表会・体験会用に準備した、生体認証側デモシステムのスペックを示す。
①連携、生体認証サーバ（Hyhper-V 仮想環境構成）
ⅰ）ハードスペック （HP EliteBook 820 G2/CT Notebook PC）
CPU：インテル® Core™ i7-5600U プロセッサー（4MB キャッシュ、2.6-3.2GHz）
メモリ：16GB
OS：Windows 8.1 Update （64bit）
（日本語）

47

ⅱ）連携機能 ソフト構成
OS：CentOS 7.0
アプリケーションサーバ:Tomcat 8.5（Java8）ⅲ）生体認証サーバ（指静脈認証） ソフト構成
OS：Windows 2012 R2
DBMS：SQL Server 2012
アプリケーションサーバ：ASP.NET 4.0
生体認証機能:日立ソリューションズ 認証管理システム AUthentiGate 05-01(サーバ)②登録用ＰＣⅰ）ハードスペック (lenovo ThinkPad L540)
CPU：インテル® Core™ i5-4210M 2.6GHz
メモリ：4GBⅱ）ソフト構成
OS：Windows7(32bit)（日本語）
Web ブラウザ:Internet Explorer 11
生体認証機能:日立ソリューションズ 認証管理システム AUthentiGate 05-01(ｸﾗｲｱﾝﾄ)③認証用 PCⅰ）ハードスペック （HP EliteBook 820 G2/CT Notebook PC）
CPU：インテル® Core™ i7-5600U プロセッサー（4MB キャッシュ、2.6-3.2GHz）
メモリ：16GBⅱ）ソフト構成
（日本語）
OS：Windows 8.1 Update （64bit）
Web ブラウザ:Internet Explorer 11
生体認証機能:日立ソリューションズ 認証管理システム AUthentiGate 05-01(ｸﾗｲｱﾝﾄ)
4.4.2

発表・展示体験会

被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロトタイ
プ・システムの有効性をシステム性能の観点と利用者側の観点から検証するため、発表・展示展
示会を開催した。
(1) 発表・展示体験会概要①開催日： 2 月 17 日（金）②場所： 西宮市情報センター 1 階 NICC ホール（多目的ホール）
西宮浜産業交流会館 西宮市西宮浜 1 丁目 31 番地②報道向け発表会：

午後 1 時から 1 時 40 分（10 分間の体験時間含む）

検討委員会の半谷委員長のご挨拶の後、研究開発内容と成果の紹介とデモ展示・体験を行っ48

た。
③一般向け発表展示会：

午後 2 時から 4 時検討委員会の半谷委員長のご挨拶と講演の後、研究開発内容と成果の紹介とデモ展示・体験を行った。この体験を通して、システム性能の観点と利用者側の観点から検証を実施した。
(2) 発表内容
避難者に安全安心を提供するため、被災者支援システム上で生体認証を使って避難所で身元の特定を行う追加機能開発に取り組んだことと、研究開発成果を紹介した。
(3) デモ内容
被災者支援システム上の生体認証を使って避難所で身元の特定を行う機能を用いて、自称できない避難者の避難所での身元の特定が簡単にできることを示した。
下記をデモし、動作を解説した。
- 自称可能な避難者：通常の手順で身元を特定し、避難者台帳に登録- 自称できない避難者：生体認証を用いて身元を特定し、要援護支援者等の台帳情報で確認
し、確認後、避難者台帳に登録(4) 体験会概要
デモコーナーにて、体験したい希望者に対し、次の手順を踏んで体験していただいた。
[登録コーナー]①体験希望者に申告いただき、参加証を確認する②生体情報の「提供承認書」へ署名いただく③識別番号札をお渡しする③識別番号を確認して、避難行動要支援者台帳にあらかじめ登録している方として識別番号を入力して生体情報を登録する（事前に連携機能及び生体認証サーバに必要事項を登録し、生体情報の登録のみで体験可能とした）[検索コーナー]④自称できない方の避難所での受入れ処理の体験として、生体情報による検索をし、お持ちの識別番号札の番号が検索されていることを確認いただくことで避難者登録を体験していただいた。
4.4.3

発表・展示体験会での検証結果(1) 発表・体験会参加者
1）報道向け発表会参加者
報道関係者として、朝日放送、毎日放送、サンテレビのＴＶ局と、産経新聞、時事通信、毎日新聞の 6 社にご出席いただくことができた。説明後の質問では、使用場面と考えられるメリットについての質問があり、それぞれ研究内容に基づいて回答した。
2) 発表展示会参加者

49一般向け発表展示会では、19 名に参加をいただくことができた。メーカー系が 4 社 5 名。近畿地区の自治体の議員及び職員が 14 名であった。体験には、11 名に参加いただくことができた。
(2)システム性能検証結果： 事前登録済み：約 1,000 本、当日登録数：11 本・登録生体情報（指数）・操作回数：
・登録： 11 回
・検索（1:N 検索）：

31 回

・本人確認（1:1 認証）： 15 回
・画面操作レスポンス（連携機能へ制御渡し～生体認証結果表示迄）：・登録： 1 秒以下
・検索（1:N 検索）： 1 秒以下
・本人確認（1:1 認証）： 1 秒以下・発生したエラー：
・タイムアウト： 4 回（報道関係が写真撮影のタイミングと併せるためのタイムアウト）
3 回（報道関係が事前登録した指を忘れたための不一致）：
・該当者無し（正常処理）

・センサー誤操作： 0 回（生体情報登録の際、センサー操作についてよく説明を聞いていただ
けたこともあり、続く認証操作で誤ったセンサー操作によるエラーはなかった。
）(3）システム的観点からの検証結果
データの受け渡しにおいても必要最小限のデータを POST で送受信する方法としたこともありシステムの改修や調整を行うこともなく、両システム間が連携した動作確認ができた。
これにより、今回の研究成果による連携方式が、技術的にも運用的にも実用化の基礎として有効であることが確認できた。
(4）利用者側観点からの検証結果
報道関係者の取材の結果、Web 上で下記の報道が確認できたことから、関心の高さが伺えた。
・ABC 朝日放送 （WEB ニュース）・MBS 毎日放送（2/17 18:00 の TV ニュース 動画）
・サンテレビ（WEB ニュース）・時事通信社（WEB ニュース）

・産経ニュース
また、発表・体験会に参加された方からは、生体情報をシステム登録することに対しする、疑義や拒否感等の意見はなかった。
今回は自称できない方を対象としたデモストーリーとしたが、体験デモ参加者からは次のような意見をいただいた。
①健常者も災害時は自分を証明する物をなくしてしまう場合もあるので、事前に生体情報登録50

をしておけば良いのではないか？
②全般を通じて、現場が混乱している避難所等において、身元を表明できない方の身元の特定
を、生体認証技術を用いて素早く確実に行うことは、非常に重要であり、大いに実用化に期待するものである。また、今回の検証実験において、特定の生体認証機器ベンダーの生体認
証技術のみに対応するのではなく、汎用的に接続可能な仕様とされたことは、システムを選定・導入する立場から、選択の幅が広がるため、高く評価できる。
「避難所における適切かつスピーディーな身元特定ができる」ことに対する地方議員、
特に、
自治体関係者の関心の高さを実感することができた。
4.4.4

自治体関係者よりいただいた感想

今回の検証を通して、自治体の方からいただいた率直な感想、課題提起と期待を示す。

なお、自治体情報化の現状は、情報化の推進を機能提供ベンダーに依存している自治体がほ
とんどであり、以下のレベルに達しえていないのが実態であるとのお話も同時にいただいた①今回の検証は、発表・展示体験会で使用できるレベルの確認ができたレベルであり、実際の災害発生時の実現（実用）可能性は不透明ではある。また、静脈や指紋といった生体情報の収集には手間がかかりすぎることや、最終的に職員の達観によることを前提とするなら、写真等の外観等で判断ができる情報が圧倒的に有効であることも考慮しなくてはならない。
②全般を通じて、現場が混乱している避難所等において、身元を表明できない方の身元特定を、生体認証技術を用いて素早く確実に行うことは、非常に重要であり、大いに実用化に期待するものである。
また、今回の検証実験において、特定の生体認証機器ベンダーの生体認証技術のみに対応するのではなく、汎用的に接続可能な仕様とされたことは、システムを選定・導入する立場か
ら、選択の幅が広がるため、高く評価できる。しかしながら、以下に述べるとおり、実用化にはそれぞれのフェーズにおいて課題が山積しているものと考えている。
③登録フェーズについて
避難行動要支援者管理システムに登録する際に、本人同意のもと、生体情報を取得するために本人と面談する必要がある。避難行動要支援者管理システムは情報セキュリティの観点から、インターネット接続環境にサーバ設置することが不可能である。
登録者との面談は庁舎外で行われることになるが、スタンドアロンパソコンに、登録者情報を保存して持ち出し、パソコン内に生体情報を一旦取込み、帰庁した後にサーバに間違いな
く登録しなくてはならない。
通常、個人情報をパソコン等に保存して庁外に持ち出すことは、盗難・紛失のリスクから許可できない。仮に許可できた場合でも、生体情報をパソコンから取り出してサーバに登録するといった権限を、職員（人）に与えることに疑義が生じるものと考えられる。
また、通常は民生委員などが避難行動要支援者管理システムに登録するための申請手続きを51

行うが、生体情報を収集する場合は市職員が直接面談を行う必要があるため、人手の問題などから、導入に対して現場からの反発は必至であろう。
④確認フェーズ
お話をいただいた方の自治体の場合であっても、指定避難所において庁内ネットワークが敷設されていない施設が多数ある。敷設されていても避難場所（部屋）にネットワークが延伸されていない箇所が多数ある。実際、避難所にはインターネットに接続されるタブレットは常設されるが、パソコンを搬入できるのは、大規模災害の場合は発災数日後になると考えられる。
（また現時点では、職員に配備しているパソコンを避難所に持って行っても、パソコンの設定変更を行わない限り、ネットワーク的に接続できない場所が多数ある）
その他、ネットワークの断線や停電など、避難所において被災者支援システムが稼働できない状況が考えられる。避難所で被災者支援システムを発災当初から使える環境を構築しておくべきだが、現状では避難所で被災者支援システムを使うケースは少ないのではないかと推察している。
避難所に、職員に配備しているパソコンを持って行く場合に、平常時から全台に生体認証ソフトを入れておくことは無駄である。一方、災害で混乱し、人手が足りない中でインストー
ル作業を行えば、対応に遅れが生じることも問題となる。
⑤平常時の運用フェーズ
収集した生体情報は、住民異動（死亡・転出など）に連動して削除される必要がある。従って、今回は実装しなかったが、バッチで削除する機能が生体認証システム側に必要となる。
災害時に求められる機能として、サーバの冗長化、バックアップの取得、別サーバでの仮復旧などがある。そのような機能は既に実装されているかもしれないが、必要である一方で、生体情報を容易に他の環境に移動できることのリスクについても、導入前に評価する必要がある。
⑥導入フェーズ
今回は、導入費用については一切触れることがなかったが、生体認証の方式ごとに導入コス
ト・ランニングコストが提示されなければ導入の検討及び生体認証方式の選択ができない。
平常時の生体読み取り装置は少数でよいが、災害時には、多数の避難所があり、導入を検討する場合には、どこに生体読み取り装置を配置するのかが課題となる。
⑦期待するもの
生体認証には、身元を特定する証明書（カードなど）を持ち歩かなくても良い、認証率が高
い、なりすましリスクが低い、等のメリットがある。一方で、生体認証機能を搭載したスマー
トフォンの普及、ATM やレジャー施設でも生体認証の活用事例が出てきていることから、生活に浸透してきているものの、登録に手間がかかる、生体情報の提供に抵抗があるなどのイメージも依然として残る。
そこで、マイナンバーカードの普及が前提とはなるが、国からカード内に登録されている顔写真が自治体に提供され、顔認証に用いることが許可されれば、生体情報の提供に対する手52

間と、抵抗感を払拭できると考える。そうすれば、災害時はもとより、平常時の窓口をはじめ、あらゆるシーンで身元特定ための書類の提示が不要となれば、時間短縮にもつながるのではないだろうか。

以上いただいた感想、課題提起と期待に生体認証技術業界として対応していくことが、大切と考える。

53

5．研究開発のまとめ
5.1

研究開発のまとめ
被災者支援において中心的役割を果たす自治体が避難所で行う支援業務に、生体認証による身元特定手段を組み込むため、次の調査・検討、開発及び検証を 3 ヵ年の期間で行うことを計画し、平成 26 年度、平成 27 年度の 2 年間、それぞれ、調査・検討とプロトタイプ・システム開発に取り組んだ。
平成 28 年度は、検証フェーズとして、生体認証技術と被災者支援システムの連携に積極的な自治体と連携しながら、生体認証を用いた被災者支援システムのプロトタイプ・システムの開発を完了し、被災者支援システムと生体認証技術が連携することの有効性の検証作業に取り組んだ。
(1) 委員会活動
有識者・自治体・生体認証機器ベンダー・応用システムベンダー・官公庁及び事務局からなる検討委員会を組織し、研究開発の実施に関係する事項、検討方針、検討内容や方向性について、専門的、具体的な検討を行い、研究開発にフィードバックすることができた。
(2) 生体認証応用被災者支援プロトタイプ・システム仕様の調査（調査）
被災者支援システム上で生体認証を使って自称できない避難者の身元特定を行うプロトタイ
プ・システムの開発に向け、システムの「あるべき姿」を念頭におき、下記が明確にできた。
①システム構成②必要な機能- 1:N 検索機能
- 1:1 認証機能
- 生体情報登録機能- 生体情報削除機能- 生体情報登録機能（バッチ登録処理（オフライン処理）案）③API 仕様
オープンな環境で生体認証技術と被災者支援システムの連携を実現するために、被災者支援システムと生体認証機能間の API として連携 API を規定した。この連携 API を介して、被災者支援システムに生体認証機能を提供することで、被災者支援システムの改
修をせずに様々な種類の生体認証技術が使えるものである。
今後、生体認証機能提供者がこの連携 API を介して生体認証機能を提供されていくことを期待する。
④画面等の仕様連携 API に対応する被災者支援システム側の画面仕様を開発できた。
(3) 生体認証応用被災者支援プロトタイプ・プログラムの開発（プログラム開発）
仕様の調査結果に基づいて、被災者支援システム上で生体認証を使って自称できない避難者
54

の身元特定を行うプロトタイプ・システムとして、被災者支援システム側プロトタイプ・プロ
グラムと連携及び生体認証側プロトタイプ・プログラムを開発できた。
(4) 生体認証応用被災者支援プロトタイプ・システムの有効性の検証（検証実験）「被災者支援システム上で生体認証を用いて身元開発したプロトタイプ・システムを用いて、の特定を行うための研究成果の発表ならびに展示会」を開催し、報道関係者や一般の方に参加していただき、自称できない避難者の身元特定を行う機能の有効性をシステム性能の観点と利用者側の観点から検証できた。
参加者の反応を見ると、被災者支援システムに生体認証システムを組合せることが、発災時の避難者の身元特定に有効であるなら、一般に受け入れられるまでに生体認証に関する世論の認識が変化してきていると考えられる。
また、今回の発表・体験会を通じ、データの受け渡しにおいても必要最小限のデータをPOST で送受信する方法による両システム間の連携方式は、技術的にも運用的にも実用化の基礎として有効であることが確認できた。

このようなデータの受け渡しにおいて必要最小限のデータを POST で送受信する方法は、
被災者支援システムに限らず他の業務システムとの連携を考える上でも有効な方法と思われる。この方式を適用して、様々な種類の業務システムとの連携が容易に行えるようになることで生体認証を広く普及できるのではないかとの感触を持つことができた。

本研究開発の成果物は、被災者支援システムの改修や生体認証機能提供者が被災者支援システムに生体認証機能を提供すると際の開発の一助となるよう、被災者支援システムを運用・管理している西宮市情報センターに提供し、また、弊協会でも生体認証に係わる方々に下記の情報を成果物として公開する。
[成果物]
1. 報告書 （本報告書）
2. 補助検索項目検討書 （付録 1）
3. 操作処理遷移（画面中心）検討書 （付録 2）
4. 連携シーケンス検討書 （付録 3）
5. オフライン登録処理検討書（オフライン登録処理案） （付録 4）
6. 連携機能詳細仕様書 （付録 5）7.プロトタイプ・プログラム サンプルコード等プログラム詳細
なお、成果物のうち、サンプルコード等以外は、弊協会ホームページに公開する。
サンプルコード等のプログラム詳細は、適切な用途に使用していただける方に、弊協会より提供する。業界関係者で希望する方は、別途弊協会まで連絡をいただきたい。
なお、成果物の提供や今後の取扱いは、5.2 に再掲する平成 27 年度報告書に記載した事項に従うので、順守いただきたい。なお、記載されている成果物は合意当時の想定であり、取り扱
い合意事項は、本報告書の[成果物]に適用される。
55

5.2

成果物の公開・提供と今後について
本研究開発は、広く自治体で実施される被災者支援の改善に成果が提供されることを願って取り組んだ。また、協力いただいている被災者支援システム全国サポートセンターの担当者からは、成果物を必要とする自治体に被災者支援システムのオプションとして提供していきたいとのご希
望もいただいた。それを踏まえて、成果物の公開・提供条件について検討し、検討委員会参加者に賛同いただいた内容を以下に示す。
(1) 本研究開発における成果物の取り扱いについて
本研究開発における成果物は、必要とする自治体に被災者支援システムのオプションとして広く利用され、また実際に自治体に導入される時は、今回の成果物をベースに各生体認証機能の提供ベンダーはそれぞれの製品の機能エンハンスを行って自治体に提供することが想定される。
一方、生体認証側の委託調査実施者やプロトタイプ・プログラムの委託開発者には開発当事者としての著作権・知的財産権や開発物に関する複製・改変・再頒布権が発生する。
そのため、本研究開発における成果物の取り扱いについて、基本的には情報公開対象とすることを前提に、本研究開発参加者と委託開発者で図 5.2-1 に示す内容にて合意を得た。
(2) 本研究開発における成果物の改良等について
今後、実際に自治体のシステムへの導入が始まると、詳細仕様検討の結果によっては、今回の成果である連携機能や連携 API に改良・修正が必要になることが考えられる。
「生体
この場合、改良・修正後も、本研究開発の主旨である「オープンシステムへの対応」、
認証技術の自由な選択性の確保」が、引き続き確保されることが望まれるため、改良・変更仕様を決める際には、被災者支援システム側、各生体認証機器ベンダー、自治体への生体認証機
能の提供者及び弊協会を含めた場を設けていただき、改良・変更仕様について協議・共有の上で決め、変更後の仕様が、生体認証機能の提供間で共有される対応をいただくよう進めていただくことが望まれる。
協議・共有の場は、弊協会としても提供するので、連携機能や連携 API に改良・修正が必要になった際には、生体認証機能の提供者は、この点にご配慮いただくことを希望する。

56

[生体認証側の具体的成果物（平成 27 年度、平成 28 年度）]
1．「生体認証を用いた被災者支援システムの構築のための調査報告書」
2．プロトタイプ・プログラム関係成果物（連携機能部）(仕様書、ソースコード)
3．検証実験結果報告書（仮題）[取り扱い合意事項]
・上記、1～3 については本ＰＪの成果物として基本的に情報公開対象とする。
・ベンダー独自のものである生体認証機能に関する技術情報については各ベンダーが認める範囲とする。
・プロトタイププログラム（連携機能部）はオープンソース（OSS）での開発を前提とし、被災者支援システムとの連携に使用することに限定する。
・プロトタイププログラム（連携機能部）は、複製・改変・再頒布権を無償でプログラム
開発委託者から与える。また、調査委託者とプログラム開発委託者は、知的財産権を行使しないこと。なお、検証実験後のサポート、保証はないものとする。
・成果物は JAISA への納品物とするが、著作権、知的財産権、複製・改変・再頒布権はプログラム開発委託者にも残るものとする。
・プロトタイプ・システムの検証実験・デモ用に、プログラム開発委託者は、利用者数限定の生体認証機能部の評価版、生体認証装置及び必要な際は期間限定でサーバ等による生体認証サービス利用権を用意し、提供する。
図 5.2-1 本研究開発における成果物の取り扱い合意事項（平成 27 年度合意済み）

57

6．今後に向けて
今回取り組んだ研究開発の成果により、自ら誰であるかを示すことが難しい避難者の方でも、生体認証を活用することで身元を確実に特定できるため、スムーズに避難所への入所ができるようになることを示すことができた。生体認証技術の利便性を活用することで、避難所入所後の支援も、個別の事情を把握することによって的確に行うことができるという可能性も示せたと考えている。

今回の研究開発では、自治体の立場から見た課題はもとより、以下のような実務的な課題もあるとも感じている。
1. 実用するには、あるべき姿を含めた、機能整備が必要であること。
2. 登録の作業（日々業務）をもっと簡素化する必要があること。
3. 自治体での活用を考えるとき、今回の事例だけでなく日常的な業務の中での活用範囲の拡大を検討していく必要があること。
（可能かどうかはわからないが、警察との連携になるが徘徊高齢者の保護とその身元特定というようなものなどへの応用）
4. 運用面を含めた検討課題としての検証が十分できなかったことにより、生体認証システム導入
における実効性についての確認が取れなかったこと。
5. 被災者支援システムとの連携可能性についての有効性の確認の先にある行政情報システムにおける活用場面の多面的展開への踏み込み。

また、今回の研究成果である「生体認証技術とそれを使用するアプリケーションシステム間のデータの受け渡し方式」(種々の生体認証技術を包含する形で共通化し、必要最小限のデータをPOST で送受信する方法で、使用する生体認証技術を変えてもアプリケーションシステムの改修や調整を行うことの必要がない方式)は、被災者支援システムに限らず他の業務システムとの連携し生体認証技術が広く普及する上でも有効な方法と考える。今後も生体認証技術を取り扱う業界で、連携機能を活用改変して、様々な業務システムや生体認証システムの違いを吸収し、様々なアプリ
ケーションシステムと画一的共通化して連携が図れるようにインターフェースの充実を図っていくことが重要と考える。

今回検証実験に参加された自治体の方からは、生体認証技術と他のシステム、とりわけ被災者支援システムとの連携、曲がりなりにも標準化できたことは、さまざまな展開が期待できるもので、
電子自治体を推進する行政分野でも大いに歓迎すべきと感じているとの積極的な積極的な問題的と期待をいただいたので、次に記す。
①ベンダーと行政側でのスタンスの違い
双方のスタンスの違いは否定すべきことではない。むしろ必要なことでもある。
しかし、目的の共有は絶対条件であり、今回も共有できていたと思うが、行政側として、もう一歩踏み込んでおくべきだったようにも思う。
58

「生体認証」について、ベンダー側では「いかに高い精度で個人を認識するか」であると思うが、行政としては「認識することで何に使えるのか。どのように役立てるのか」が見えていないと話にならないうえに、ベンダーとの議論に齟齬が生じることになりかねない。
「新たなサービスを創造する」ことよりも、まずは「こ行政のフィールドで展開するには、れまでの業務に応用する」という、いわゆる「課題解決」の手段として用いるところから始めるべきである。被災者支援システムへの応用も、すでに課題として認識されていたことへの応用であるが故に、説得力を持ったと考えている。
②「生体認証」に求めるもの
行政の人間としての見解ではあるが、「生体認証」⇒「個人の特定」であり、言い換えると、「PW」を管理し、都度入力
生体認証は「ID」「PW」の代替でしかない。それでも、「ID」
することの煩雑さや混乱を解消することが、実は、最も求められていることではないか。シ
ニア世代や IT リテラシーの低い方々にとっては、大きな恩恵となり、電子自治体に参加していくことができるようになる。
「生体認証」も「ID」「PW」も、つまりは、「私が私であること」を証明するものである。
ならば、「私が私であること」を証明することで得られるメリットにはどんなものがあるのか。この生体認証の標準化研究の成果を真の成果としていくためには、「得られる効果」を前面に出すことが最も重要である。
③意義のあった被災者支援システムへの応用
そういう意味では、被災者支援システムは、住民の命を守る仕組みであり、今回の検証のベースに用いたことはとても説得力があり、有意義でもあった。
地方公共団体情報システム機構（J-LIS）が所管する被災者支援システムは、住民情報と連携して被災者を支援する唯一のシステムであり、個人を行政保有情報に紐付けることができるので、その後の丁寧な見守り・支援に繋げていくことができる。個人を特定することの重要性は、このことからも明らかで、生体認証技術の必要性を裏付けている。
生体認証技術の存在価値の証明は、逆説的に被災者支援システムの有用性を揺るぎないものにすると考える。
④横展開していくために普及という点からは、もう少し多様なシステムへの応用が必要であると考える。
そのためには、行政からの押し付けではなく、住民が能動的に求めるように、インセンティ
ブを感じられる展開が必要である。
「機会」などがあるが、住民票等のコンビニ交付を検インセンティブには、「金銭」「時間」
討した際も、「金銭」にかかるインセンティブの優位性が明らかであったと記憶している。
「生体認証を使えば、使用料や手数料が安くなる」といった応用があれば、登録数は増えるだろうが、適正な受益者負担の観点から、生体認証からコストに言及することは難しい。まずは、「利便」に供するかどうかだと考える。
例えば、ある金融機関では、静脈認証によって ATM を操作することができる。生体認証の59

精度は、それほど信頼に値するものであり、様々な公共サービスや決済に活路があるのではないか。
仮に生体認証の登録が義務化されれば、認証基盤として投票行為に活用したり、印鑑登録証
明書そのものが不要になったりするなど、劇的な変化が期待できる。さらに、登録情報の民間利用が可能になれば、PASMO や suica を手のひら静脈認証が代替する日が来るかもしれない。
官民問わず、「利便」を掲げて、生体認証を認証基盤としていくことが、イノベーションの発端となり、見知らぬ「価値の創発」につながるものと期待する。
⑤行政が管理していくことの必要性
今回の被災者支援システムをベースにした活用事例であっても、認証した先にセンシティブ
な個人情報との連携があってこそ意味を持つのである。
先述したとおり、「私が私であること」を証明する印鑑登録証明書の代用は、生体認証ならではの強みであり、これまでの概念を覆すことができると期待する。
この「私が私であること」は、行政が証明しているのだから、登録情報は行政が管理すべきだと考える。特に基礎自治体は福祉情報をはじめとする個人情報を保有しており、災害発生時にこれらの情報が命を救うことにもなる。
では、どのような登録情報を管理するのが望ましいかといえば、個人的には、顔、静脈、指紋、虹彩、声紋などぞれぞれの生体認証情報（同意したもの）とマッチングできなかったときのための補助情報（ID、PW など）で、二要素認証にも対応できるようにし、当然にマ
イナンバーと紐付けておく。
そもそも生体認証情報とのリンクをマイナンバーの活用事例とし、広く展開していくことが、
日本の情報化社会に大変革をもたらすと信じたい。
⑥ベンダーへの要望
生体認証の活用場面は様々であり、求められるマッチングレベルもそれぞれに異なる。
、1:N のマッチ
今回のような被災の現場を想定した活用である場合（生命にかかわる場合）ングとなることは想定内であるが、1:N ではマッチング度合いのスコア表示は絶対条件である。つまり、各ベンダーの手の内云々を度外視しなければならない活用場面もあることを理解いただかないと、行政での活用は進まないし、それは国民にとって不幸なことでもある。
技術的には、各ベンダーとも素晴らしく感心しているが、それぞれに誇れる特長があるのだから、まずは、それらを伸ばしてほしい。
そして、それぞれの認証技術と親和性の高い仕組みへの応用を進め、ベストプラクティスを作り上げ、社会のため、将来のためにベンダーを問わず共有し、そして、共に栄えてほしいと強く願う。

60

最後に、生体認証応用被災者支援システムプロトタイプ・プログラムの研究開発を総括するにあたり、自治体側の被災者支援システム関係者として積極的にご参加いただき、種々の教示を頂いた
被災者支援システム全国サポートセンター長、吉田稔氏よりいただいた言葉を記して報告を終わる。
「早いもので、この 3 月 11 日をもって東日本大震災から丸 6 年が経過し、あの阪神・淡路大震
災からも丸 22 年が経過したのである。昨年も熊本地震をはじめ、台風 9 号や 10 号などの風
水害害が多発し、甚大な被害が発生してきたのである。まさに、災害多発の昨今、他人事ではない。その都度、国民の危機管理意識は向上したものの、その時だけで危機管理意識の風化の速さと危機管理対応に同じ過ちを繰り返してきたのも事実である。
改めてこの機に、この間の大災害の体験・教訓を風化させないためにも、震災を知る人にも、知らない人にも、すべての人と記憶を共有する中で、皆さんと共に考えて生きたい。
そのためにも、「最善を望み、最悪に備えよ！」を強く実践頂きたいものである。
最終年度を迎えたこの度の研究開発は、発足当時、生体認証システムが被災者支援システム
における被災者支援業務に果たして実効性があるのか、その有効性を本当に発揮できるのかという不安いっぱいの中、進めてきたわけだが、この間に生体認証システムの要件等の調査や精査を重ねてきたことと、今回のプロトタイプ・プログラム開発による単体テスト及び連動テス
トの具現化により、広く検証実験を実施することができたことにより、その実効性及び有効性をある程度確認することができた。
しかも、前年度の報告における課題等が検証実験により、クリアされると共に更なる可能性を秘めており、今後、多方面での有効的な活用も検討する必要があると考える。
そして、今回の検証実験発表会において、あらゆる生体認証機器ベンダーの手法（指紋、顔、手のひら等々）に基づく生体認証システムが共通のインターフェースのもと簡単に導入且つ利活用できると確信している。
検証試験や研究開発内容については、それぞれの立場で課題や期待は山積するが、被災者支援システム上での生体認証による身元特定を実際に展開するうえで大きな壁があるのは承知している。それでも、3 年間に渡る研究開発の研究成果を無駄にしないために、理想像を語り共有し、そこに向かう努力は必要だと感じている。
まずは、いかに登録してもらうかということ。「何のために」を理解してもらうことが大前提であるが、手上げ方式による「災害時に援護を求める人」の登録が進まないことと、センシ
ティブな生体情報ということを考えると、正面切って「いざというときのために」という理由
では難しいと感じている。やはり、インセンティブを付与できる複数の取り組みからの横展開が期待できるのではないか。それぞれの認証技術との親和性を見極めて、とにかくベストプラ
クティスの実現に注力することが肝要ではないかと思う。
また、激甚災害発生時には、マイナンバーカードに用いた顔写真を顔認証に活用できるようにするといったことも、今後、検討していきたいことの一つである。
個人的には、顔の認証に最も期待しているが、遠隔から画像を送信して認証できる反面、本人
61

同意を確認できないリスクがある。指紋は、半谷先生の基調講演のとおり、指を切断されて悪用される危険がある。静脈は、遺体では難しい等、それぞれにメリットとリスクがあるので、何度も繰り返すが、それぞれの認証技術と親和性の高い活用モデルを見つけ出し、それを発信して共有できるようにしていくことが、国民の登録への理解に結びつき、今回の研究の成果を広く役立てていけるものと信じている。
このようなことから、生体認証システムを応用した被災者支援システムとの連携及び連動の検証成果は、今後の真の住民のための危機管理対応に少なからず役立つということを検証した
ことと行政情報システムにおける長年抱えてきた課題解決の手法として役立つことを確認したことも述べておきたい。
」

62

＜付録 1＞

補助検索項目検討書

検索補助項目について
1：ｎ検索時の補助検索項目の指示ポイント（処理）について、下記前提・検討事項を基に検索補助ａ）～ｃ）案を検討する。

前提
・補助検索項目は「1：ｎ検索」時に検索対象母数を絞り込む（少なくする）ことにより検索処理時間の短縮と検索結果精度の向上を期待する。
・「被災者支援システム」における生体認証1：ｎ検索結果に基づく、本人確定は最終的に操作スタッフ（自治体職員）の達観による。
検討事項※１：ｎ検索は検索対象母数全体をサーチする ⇒ 母数が少ないほど検索時間が短い。
※1：ｎ検索は生体情報のみによる検索のため、性別・年齢等の検索対象者と異なる属性情報を持つ候補者を結果として返す場合がある。
明らかに異なる属性の持ち主を検索対象から除外することで、現場利用時の混乱・誤解の低減が期待できる。
※各ベンダーの生体認証システムの仕様により補助検索項目の「ａｎｄ条件指定」「or条件指定」はできない場合がある。
（日立・指静脈認証システムは既存グルーピング機能の応用を前提しており、複数のグループ値毎の検索は可能だがグループ値の「and」「or」条件指定は現状不可能）※各ベンダーの生体認証システムの仕様によって、生体認証システムに設定された補助検索項目値に「前後＋－○○」といった幅を持たせた形での検索対象のグループ化は不可能。
※補助検索項目は生体情報登録を行う際に設定する。
※性別など登録時と検索時も実態の変更が発生しない項目は補助検索項目として有効性が高い※年代（年齢）、住所（地区）等、登録時と検索時とで実態が異なる場合、検索対象から漏れてしまう可能性がある。
変動要素のある補助検索項目を設定する場合、補助検索項目のメンテナンスについて運用面からも検討する必要がある。
※生体情報登録後の補助検索項目値の変更はシステム的に別途検討する必要がある。
※補助検索項目が指定されていない場合は全件を検索対象とする。
検索補助Ａ）「被災者支援システム」、「避難行動要支援者関連システム（日々業務システム）」から引き継ぐ
検索時：
スタッフが被災者支援システムの「本人確認（生体認証）」ボタンをクリックする際、補助検索項目値をリストボックスから選択または入力する。
「本人確認（生体認証）」ボタンをクリックにより発行される「GETメソッド」または「POSTメソッド」の引数として連携機能及び生体認証システムとして渡される。
登録時：

スタッフが生体認証登録対象者のサービスID入力又は上位画面の結果表示から対象者の情報を表示させた後、避難行動要支援者関連システムから「本人登録（生体認証）」ボタンをクリック際に、登録する補助検索項目値をリストボックスから選択する。
「本人登録（生体認証）」ボタンをクリックにより発行される「GETメソッド」または「POSTメソッド」の引数として連携機能及び生体認証システムとして渡される。
※スタッフによるリストボックスの操作以外にも、要援護者支援システム側で登録する補助検索項目を対象者の情報から自動で生成することが可能。（スタッフの入力無し）
例：性別⇒「男性ｏｒ女性」、年齢⇒「年代（青少年・成人・高齢者）」、住所⇒「地区（市、地域、町）」等

検索補助Ｂ）「連携機能（サーバ）」で生体情報撮影機能を呼び出す前に入力
検索時：
連携機能から生体認証撮影機能を呼び出す前に、補助検索項目を指示する画面を表示する。
スタッフは対象者の補助検索項目を指定後、「次へ」ボタンを押下し、ベンダー別API（クライアント）の生体認証撮影機能に制御を渡す。
登録時：

連携機能から生体認証撮影機能を呼び出す前に、補助検索項目を指示する画面を表示する。
スタッフは登録する対象者の補助検索項目を指定後、「次へ」ボタンを押下し、ベンダー別API（クライアント）の生体認証撮影機能に制御を渡す。
※スタッフによる予めリストボックスに設定されている補助検索項目値を選択する。
※リストボックスの補助検索項目、項目値は外部パラメータにより設定できるようにする。

検索補助Ｃ）「生体情報撮影」時に入力
検索時：
生体認証撮影時に生体認証システムから補助検索項目を指示する画面を表示する。
補助検索項目の指示項目値、入力方法は各ベンダー毎の仕様による。
登録時：

検索補助案別比較表
実装部位

登録用生体認証撮影時に生体認証システムから補助検索項目を指示する画面を表示する。
補助検索項目の指示項目値、入力方法は各ベンダー毎の仕様による。

実装者

プロト実装

操作性

システム変更

被災者支援システム／
検索補助Ａ） 避難行動要支援者関 被災者支援ＷＧ
連システム

項目値の設定高可

被災者支援システ
ム側で設定可能

共通

被災者支援
システム側

自動設定可

検索補助Ｂ）

連携機能

生体認証ＷＧ

可

中

共通

被災者支援
システム側

リストボックス

検索補助Ｃ）

生体認証システム

各ベンダー

不可

ベンダー仕様によるベンダー仕様による

各ベンダー

リストボック
ス/値入力※検索補助項目機能をプロト実装する場合、現状の日立指静脈認証システムで実装可能範囲となります。
第2回被災者支援システム側連携WG（8/25）での合意事項①検索補助B）にて設計を進める。
②補助検索項目は「性別」とする。他項目についてはその別途必要に応じて検討する。

操作性＜付録 2＞

操作処理遷移（画面中心）検討書

株式会社日立システムズ

一般社団法人日本自動認識システム協会

2016年11月15日

あるべき姿としての操作処理遷移(画面中心)「生体認証を用いた被災者支援システムの研究開発」

前提
1. 生体認証を応用した被災者支援システムの「あるべき姿」として実現する
操作を画面中心の処理遷移として記述する。
2. プロトタイプシステムでは、「あるべき姿」の災者支援システムと連携機能間のインターフェースと（API）を用いるものとする。
但し、連携機能の生体認証システム側インターフェース、及びその実装実体
については各生体認証システムベンダーの設計次第とする。
3. 「1：1認証機能」は「1：ｎ検索」処理実施の際の本人の再確認用として用意する。

要援護支援者検索時のシステム全体画面遷移図（1：ｎ検索）０）クラウイアントPC処理

１）被災者支援システム側処理２）連携機能-生体認証側処理

A)被災者支援システムＶ7.00 総合メニュー(改修)
連携機能

生体認証システム①初期化情報生成【初期化情報生成】・生体認証検索ボタンの押下により、生体認証システムの初期化要求を行う。
注記：生体認証システムの都合による実現機能で可・被災者支援システム側より以下の情報を受け取る。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- 補助検索項目「fltr」： 性別および生年の２つ- リダイレクト先URL「rtn」： 連携機能からの戻り画面URL

B)生体認証検索用画面（新規作成）
https://demo.nmc.jp/sinsai_700_seitai/kanri_seitai/ninsyo.php②補助検索項目指定画面生成(新規ポップアップウィンドウ)j【生体認証検索ボタン】
ボタン押下により連携機能を経由して生体認証1：ｎ検索機能を呼び出す。
被災者支援システム側よりリクエストとして、以下を連携機能に受け渡す[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- 補助検索項目「fltr」： 性別および生年の２つ- リダイレクト先URL「rtn」： 連携機能からの戻り画面URL【初期化情報生成】
生体認証システム処理の初期化を行う。
初期化情報を連携機能に渡す。
注記：生体認証システムの都合による実現機能で可【補助検索項目指定画面生成】
・補助検索項目を指定する画面を生成し、新規にポツプアッ
プウィンドウとしてクライアントＰＣ上に表示する。
・初期化情報を補助検索項目指定画面に渡す。
・補助検索項目指定画面では、以下の入力を促す。
[補助検索情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- 補助検索項目「fltr」： 性別、生年の２つのうち使用するも補助検索項目入力画面

注記）表示画面は、生体認証シ
ステム側の仕様に従い、連携機
能の中で実現する。

生体情報提示の促す画面表示
画面表示は連携機能と生体認証システム側で実現する。
表示内容は生体認証システムによる。

【補助検索項目指定】
補助検索項目：「性別」と「生年」のうち使用するものについて「選択しない」を含めてプルダウン項目から指定して処理を進める。
【 YESボタン】「1：ｎ検索」を実行【 NOボタン】：ポップアップウィンドウを閉じる。

③生体認証検索結果画面生成B)-１ 生体認証検索結果画面（正常処理）【検索結果処理（正常処理時)】①連携ＩＤをサービスＩＤ（識別Ｎｏ）に変換する。
②正常処理時、結果(サービスIDとランク情報)を被災者支援
システム側に返す。
戻り値：「ｔｃｋｔ」、「ｉｄ0･･･ｉｄ９」、「ｒｋ0･･･rk9」③ポップアップウィンドウを閉じる【検索結果処理（異常処理時)】①異常処理時は、結果(エラー情報)を被災者支援システム側に返す。
戻り値：「err」、「ecd」、「msg」②生体認証処理エラー画面を表示③【 閉じるボタン】：ポップアップウィンドウをを閉じる。

生体認証処理エラー画面

・「生体認証検索画面」から呼び出される専用の避難行動要支援者台帳画面を作成する。
・データ更新、他の画面への遷移するボタン等は非表示とする。
【閉じるボタン】：画面を閉じ、生体認証検索結果画面（正常処理）に戻る。

・候補者が存在しない場合、id0に・エラーの場合「err」（ｴﾗｰｺｰﾄﾞ）、「ecd」（ｴﾗｰ内容）、「msg」(メツセージ)を指定する。

【生体認証検索結果画面（異常処理）】
生体認証システムから異常系の結果が返された場合、連携機能でエラー内容、エラーコード、処理内容を表示する。
表示内容は現場スタッフが対応しやすい様、配慮する。

④本人確認（1：1認証）処理画面へ【本人確認（1：1認証）】処理

Ｃ)避難行動要支援者台帳画面（避難行動要支援者台帳から表示） …達観時の参考に使用

・検索の結果、候補者が複数存在する場合、候補者の上位より「１０人」分の連携ＩＤを結果として正常処理 得る。
・本人である確率が高い順にid0
か ら指定される。
例えば、連携ID＝abcと連携ID＝
xyzの2名がヒットし、abcの方がより本人である確率が高い場合、
id0=abc、id1=xyzと指定する。
異常処理 ・候補者の本人である確率が高い順に３段階のランク付けをし、id*に対応するｒｋ*情報として指定する。

Nullを指定する。

【生体認証候補者一覧表示】
連携機能から候補者ID「サービスＩＤ（識別Ｎｏ）」及び本人である確率ランクを連携機能より受け取る。
・連携機能より受け取った「サービスＩＤ（識別Ｎｏ）」をもとに被災者台帳を検索し、該当者の「ｶﾅ氏名」「漢字氏名」「世帯番号」「識別番号」「生年月日」「性別」「被災時住所」を表示する。
・id0からid9まで「サービスＩＤ（識別Ｎｏ）」が設定されている分だけ処理を繰り返す。
・連携機能からの本人である確率ランク情報により候補者欄を色分けで表示する。

【本人確認（1：1認証）】指定された方のサービスID(（識別Ｎｏ）)を基に1：1認証処理要求を連携機能に行う。
（詳細はシステム全体画面遷移図（1：1認証）にて記述）【生体認証 1:ｎ認証処理】
生体情報および補助検索項目情報を用いて検索を実行

Ｄ)被災者台帳個人詳細画面（被災者台帳から表示、必要により新規登録等）…達観時の参考に使用

・「生体認証検索画面」から呼び出される専用の被災者台帳参照画面を作成する。
・データ更新、他の画面への遷移するボタン等は非表示とする。
【戻るボタン】：画面を閉じ、生体認証検索結果画面（正常処理）に戻る。

E)避難者登録画面（避難者台帳を検索して表示、必要により新規登録等）

・「生体認証検索画面」から呼び出される専用の避難者登録画面を作成する。
・他の画面への遷移するボタン等は非表示とする。
【登録ボタン】：入力されたデータをDBに登録後、画面を閉じ生体認証検索画面に戻る。
【戻るボタン】：画面を閉じ生体認証検索結果画面（正常処理）に戻る。
・生体認証検索で取得したサービスＩＤ（識別Ｎｏ）を元に、被災者台帳データを読み込み必要な項目を初期表示する。また識別番号の項目は変更が出来ないように制限する。

サービスＩＤ（識別Ｎｏ）との突合せ確認時のシステム全体画面遷移図（1：1認証）
０）クラウイアントPC処理

１）被災者支援システム側処理２）連携機能-生体認証側処理B)-１ 生体認証検索結果画面（正常処理）

連携機能

生体認証システム①初期化情報生成【生体確認ボタン】
ボタン押下により連携機能を経由して、指定された方のサービスID（識別Ｎｏ）を基に本人確認（1：1認証）機能を呼び出す。
被災者支援システム側よりリクエストとして、以下を連携機能に受け渡す。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスＩＤ（識別Ｎｏ）- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL【初期化情報生成】・本人確認ボタンの押下により、生体認証システムの初期化要求を行う。
注記：生体認証システムの都合による実現機能で可・被災者支援システム側より以下の情報を受け取る。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスID（識別Ｎｏ）- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL
・サービスＩＤ（識別Ｎｏ）に紐づく連携ＩＤに変換する。

生体情報提示の促す画面表示②生体認証画面生成(新規ポップアップウィンドウ)

画面表示は連携機能と生体認証システム側で実現する。
表示内容は生体認証システムによる。

③本人確認（1：1認証）結果画面生成【初期化情報生成】
生体認証システム処理の初期化を行う。
初期化情報を連携機能に渡す。
注記：生体認証システムの都合による実現機能で可【生体認証画面生成】
生体認証を行う画面を生成し、新規にポツプアップウィンドウ【生体認証 1:1認証処理】【1：1認証結果処理（正常処理時）】①連携ＩＤをサービスＩＤに変換する。
②サービスＩＤ（識別Ｎｏ）と生体情報1：1認証結果をポツプ
アップウィンドウに表示する。
一致：識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができました。
不一致：識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができませんでした。
③「閉じる」ボタンでポツプアップウィンドウを閉じる。

連携ＩＤと生体情報による
１：１認証を行う。
正常処理
結果を連携機能に渡す。

一致確認時の画面不一致時の画面【1：1認証結果処理（異常処理時）】①異常処理時は、結果(エラー情報)を被災者支援システム側に返す。
戻り値：「err」、「ecd」、「msg」②生体認証処理エラー画面をポツプアップウィンドウ表示③【 閉じるボタン】：ポツプアップウィンドウを閉じる。

生体認証処理エラー画面【生体認証1：1認証結果画面（異常処理）】
生体認証システムから異常系の結果が返された場合、連携機能からのエラー内容、エラーコードを表示する。
表示内容は現場スタッフが対応しやすい様、配慮する。

異常処理

要援護支援者の生体情報登録時のシステム全体画面遷移図（登録）０）クラウイアントPC処理

１）日々業務管理システム側処理２）連携機能-生体認証側処理

避難行動要支援者管理システム

連携機能

生体認証システム①初期化情報生成【次へボタン】
ボタン押下により連携機能を経由して、指定された方のサービスＩＤ（識別Ｎｏ）を基に生体情報登録機能を呼び出す。
被災者支援システム側よりリクエストとして、以下を連携機能に受け渡す。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスＩＤ（識別Ｎｏ）- 補助検索項目：「fltr」 性別・生年- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL【初期化情報生成】・生体認証管理「次へ」ボタンの押下により、生体認証システムの初期化要求を行う。
注記：生体認証システムの都合による実現機能で可・被災者支援システム側より以下を受け取る。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスＩＤ（識別Ｎｏ）- 補助検索項目：「fltr」 性別・生年- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL
・ＩＤをサービスＩＤ（識別Ｎｏ）に紐づく連携ＩＤを自動採番し、ＤＢ化。

【初期化情報生成】
生体認証システム処理の初期化を行う。
初期化情報を連携機能に渡す。
注記：生体認証システムの都合による実現機能で可②生体情報登録画面生成(新規ポップアップウィンドウ)【生体情報登録画面生成】
生体情報登録を行う画面を生成し、新規にポツプアップウィ
ンドウとしてクライアントＰＣ上に表示する。
・画面に初期化情報と生体撮影処理を埋め込む
連携ＩＤ ＋ 補助検索項目 ＋ 生体撮影用画面
・生体認証登録機能を呼び出す

生体情報提示の促す画面表示
画面表示は連携機能と生体認証システム側で実現する。
表示内容は生体認証システムによる。

③登録処理結果画面生成【登録結果処理（正常処理時）】①連携ＩＤをサービスＩＤに変換する。
②サービスＩＤ（識別Ｎｏ）と生体情報登録結果をポツプアップ
ウィンドウに表示する
正常：識別番号ｘｘｘｘｘｘｘの方の本人確認ができました。
③登録結果としてサービスＩＤ（識別Ｎｏ）を被災者支援システ
ムに返す。
④「閉じる」ボタンでポツプアップウィンドウを閉じる

正常処理【本人登録処理】
連携ＩＤを生体認証ＩDとして生体情報と補助検索項目の登録処理行い、結果を連携機能に返す。

登録結果としてサービスＩＤ（識別Ｎｏ）を返登録成功時の画面【登録結果処理】
登録処理が正常の場合
サービスＩＤ（識別Ｎｏ）を連携機能より受け取り、避難行動要支援者管理システムに生体認証登録の実績を記録する。

【登録結果処理（異常処理時）】①異常処理時は、結果(エラー情報)を被災者支援システム側に返す。
②生体認証処理エラー画面をポツプアップウィンドウに表示③【 閉じるボタン】：ポツプアップウィンドウを閉じる。

登録失敗時の画面「閉じる」ボタンで生体認証管理画面を閉じる。

【生体認証登録結果画面（異常処理）】
生体認証システムから異常系の結果が返された場合、連携機
能からのエラー内容、エラーコードを表示する。
表示内容は現場スタッフが対応しやすい様、配慮する。

異常処理

要援護支援者の生体情報削除時のシステム全体画面遷移図（削除）０）クラウイアントPC処理

１）日々業務管理システム側処理２）連携機能-生体認証側処理

避難行動要支援者管理システム

連携機能

生体認証システム①初期化情報生成【次へボタン】
ボタン押下により連携機能を経由して、指定された方のサービスＩＤ（識別Ｎｏ）を基に生体情報削除機能を呼び出す。
被災者支援システム側よりリクエストとして、以下を連携機能に受け渡す。
[受渡し情報]- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスＩＤ（識別Ｎｏ）- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL【初期化情報生成】・生体認証管理「次へ」ボタンの押下により、生体認証システムの初期化要求を行う。
注記：生体認証システムの都合による実現機能で可・被災者支援システム側より以下を受け取る- 検索チケット「tckt」： 被災者支援システム側の仕様による- サービスＩＤ「id」： サービスＩＤ（識別Ｎｏ）- リダイレクト先URL「rtn」：」： 連携機能からの戻り画面URL
・サービスＩＤ（識別Ｎｏ）に紐づく連携ＩＤに変換する。

【初期化情報生成】
生体認証システム処理の初期化を行う。
初期化情報を連携機能に渡す。
注記：生体認証システムの都合による実現機能で可②削除処理画面生成(新規ポップアップウィンドウ)【生体情報削除画面生成】
生体情報削除を行う画面を生成し、新規にポツプアップウィ③削除処理結果画面生成【削除結果処理（正常処理時）】①連携ＩＤをサービスＩＤに変換する。
②サービスＩＤ（識別Ｎｏ）と生体情報登録結果をポツプアッ
プウィンドウに表示する
正常：識別Ｎｏ：ｘｘｘｘｘｘｘ の方の本人確認ができました。
③削除結果としてサービスＩＤ（識別Ｎｏ）を被災者支援シス
テムに返す。
④「閉じる」ボタンでポツプアップウィンドウを閉じる。

正常処理

削除結果としてサービスＩＤ（識別Ｎｏ）を返す。

削除成功時の画面【削除結果処理】
削除処理が正常の場合
サービスＩＤ（識別Ｎｏ）を連携機能より受け取り、避難行動要支援者管理システムに
生体認証削除の実績を記録する。
「閉じる」ボタンで生体認証管理画面を閉じる。

【削除結果処理（異常処理時）】①異常処理時は、結果(エラー情報)を被災者支援システム側に返す。
②生体認証処理エラー画面をポツプアップウィンドウに表示③【 閉じるボタン】：ポツプアップウィンドウを閉じる。

削除失敗時の画面【生体認証削除結果画面（異常処理）】
生体認証システムから異常系の結果が返された場合、連携機
能からのエラー内容、エラーコードを表示する。
表示内容は現場スタッフが対応しやすい様、配慮する。

異常処理【本人削除】
連携ＩＤを生体認証ＩDとして削除処理行い、
結果を連携機能に返す。

＜付録 3＞
連携機能シーケンス検討書

株式会社日立システムズ

2017年3月10日

生体認証応用被災者支援システムプロトタイププログラム（連携機能）
連携機能シーケンス「生体認証応用被災者支援システムのプロトタイプ・プログラム（連携および生体認証側）開発（被災者支援システムとの連携および生体認証側）

Ｖｅｒ.10.0【１：N検索】

クライアント

生体認証
センサー

サーバ（群）

ベンダ別API（ﾄﾞﾗｲﾊﾞ、ｸﾗｲｱﾝﾄｱﾌﾟﾘ含

Webブラウザ

被災者支援
システム

連携機能
（サーバ）

生体認証
システム

生体認証検索用画面へアクセス
検索チケットをメニュー
画面の「生体認証検索」
ボタンに埋め込む※埋め込み情報
検索チケット 「tckt」：Nulｌ
補助検索項目 「fltr」：Nul
戻り先URL 「rtn」：https://demo.nmc.jp/ｘｘｘｘｘｘｘｘｘｘ.php

新規ウインドスタッフが被災者支援シス
テムの「生体認証検索」ボタ
ンをクリックして連携機能に処理を渡す（画面は残す）

生体認証検索用画面表示（「生体認証検索」ボタン）含む「戻る」ボタンをクリックした
場合は戻り先URLに処理を渡す（画面を閉じる）

生体撮影用画面へアクセス
引数：チケット、補助検索項目、戻り先ｕｒを渡す

初期化情報要求

初期化情報生成（ex. チャレンジ生成）
必要に応じて実施

新規ウインド連携機能により生成

補助検索項目指定画面生成

補助検索項目表示＋
生体撮影用画面を表示

補助検索項目を指定する
画面を生成し、新規ウィンドウとしてクライアントＰＣ上に表示

スタッフが補助検索項目をリストボックスから選択する※プロトタイプシステムは「選択しない」、「男性」、「女性」から選択

画面に初期化情報と生体撮影処理を埋め込む

補助検索項目選択後「YES」ボタンをクリックして生体情報撮影に処理を渡す

補助検索項目指定画面に埋め込まれた情報を渡す。

生体情報撮影要求。
必要な初期化情報があれば、同時に渡す

生体撮影用画面に埋め込まれたscriptにより
自動実行

生体認証センサーに利用者の生体情報を読み込ませることを促すガイ
ド画面を表示

生体情報撮影要求
生体情報撮影

生体情報をテンプレート化

テンプレートを返却

1:N検索実行画面を呼び出すテンプレートと補助検索項
目、検索チケットを渡す

1:N検索機能を呼び出す

候補者リスト（連携ID）とランクを返す候補者リスト（連携ID）
を候補者リスト（サービスID）に変換

候補者リスト（サービスID）とランク、検索チケット、りダイレクト先のURLを編集し、Webﾌﾞﾗｳｻﾞに渡す

画面遷移
画面遷移先指示【エラー結果処理の場合】
エラー内容・エラーコードを表示する。
（詳細はエラー処理に記載）【正常系処理の場合】
ウインドを閉じる【正常系処理の場合】
リダイレクト先へアクセス
検索チケットの正当性を確認する候補者（サービスID）から
被災者支援DBを検索し、候補者情報を編集する（表示順、ランク含む）
検索結果画面を生成す
る
1：1認証の準備をして処理をブラウザに渡す（以降、詳細は1：1認証にて記載）

検索結果画面を表示

被災

被災

被災

被災

被災

被災

・チャレンジの確認
・DBを検索し生体情報を照合
・検索の結果、候補者が複数存在す
る
場合、候補者の数だけ複数指定する。
本人である確率が高い順にid0から指定される。
・候補者の本人である確率が高い順に３段階のランクが指定される。
・候補者が存在しない場合、id0に【１：１認証 】

クライアント

生体認証
センサー

ベンダ別API（ﾄﾞﾗｲﾊﾞ、ｸﾗｲｱﾝﾄｱﾌﾟﾘ含

サーバ（群）

被災者支援システム

Webブラウザ

連携機能
（サーバ）

生体認証
システム

⇒1：ｎ検索結果表示
処理より継続
検索チケットを発行し、DBに保存
引数：チケット、既に画面上に表示されているサービスID、
リダイレクト先ｕｒを渡す※埋め込み情報
検索チケット 「tckt」：Nulｌ
サービスID 「ｉｄ」：識別番号
リダイレクト先URL 「rtn」：https://demo.nmc.jp/ｘｘｘｘｘｘｘｘｘ

生体認証検索結果画面（正常処理）を表示
スタッフが生体認証検索結果画面（正常処理）から生体認証対
象者欄の「本人確認ボタン」をクリック

生体撮影用画面へアクセス
引数：チケット、サービスＩＤ、戻り先ｕｒを渡す

初期化情報要求

初期化情報生成（ex. チャレンジ生成）

その他初期化情報
生成

必要に応じて実施

画面に初期化情報と生体撮影処理を埋め込む

生体撮影用画面を表示

生体撮影用画面に埋め込
まれたscriptにより自動実行

生体情報撮影要求。必要な初期化

生体認証センサーに利用者の生体情報を読み込ませることを促すガイド画面を表示
生体情報撮影要求

生体情報をテンプレート化

テンプレートを返却

1:1確認実行画面を呼び出す（テンプレートと検索
チケットを渡す）

サービスIDを連携IDに変換
1:1確認機能を呼び出す

確認結果を返す【本人確認結果処理】
識別番号と生体情報1：1認証結果を画面に表示する。
一致：識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができました。
不一致：識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができませんでした。

確認結果と検索チ
ケット、戻り先のURLを編集し、Webﾌﾞﾗｳｻﾞに

結果表示指示

確認結果画面を表示【エラー結果処理の場合】
エラー内容・エラーコードを表示する。
（詳細はエラー処理に記載）

被災

被災

被災

被災

被災

被災

・チャレンジの確認
・DBを検索し生体情報【生体情報登録】※あるべき姿として、モバイルPCでスタンドアロンでの生体情報登録後、自治体内NWに接続してバッチ登録をする。
※ここではプロトタイプシステムでの生体認証登録部分の処理シーケンスを記す。
※モバイルPCでスタンドアロンの場合、被災者支援システム（日々業務部分＝避難行動要支援者管理システム）、連携機能、生体認証システムの其々がモバイルPC内に存在することが前提となる。

クライアント

生体認証
センサー

サーバ〔モバイルＰＣ〕

ベンダ別API（ﾄﾞﾗｲﾊﾞ、ｸﾗｲｱﾝﾄｱﾌﾟﾘ含

Webブラウザ

スタッフが避難行動要支援者管理システムの「生体認証登録」
ボタンをクリック

避難行動要支援者
管理システム「戻る」ボタンをクリックした
場合は戻り先URLに処理を渡す（画面を閉じ
る）

生体認証
システム

避難行動要支援者管理システムへアクセス

新規ウインドスタッフが「生体認証管理」
画面の「次へ」ボタンをクリッ
クして連携機能に処理を渡す（画面は残す）

連携機能
（サーバ）

避難行動要支援者管理システムの画面表示（「生体情報登録ボタン」含む）

検索チケット及びサービスＩＤ、補助検索
項目、リダイレクト先を
生体認証管理画面に初期化情報と共に埋め込む※埋め込み情報
検索チケット 「tckt」：Nulｌ
サービスＩＤ 「ｉｄ」：宛名№
補助検索項目 「fltr」：性別
リダイレクト先URL 「rtn」：

生体登録用画面へアクセス
サービスID、補助検索項目、
戻り先URLを連携機能に渡す

初期化情報要求
その他初期化情報生成
補助検索項目＋
生体撮影用画面を表示

初期化情報生成（ex. チャレンジ生成）
必要に応じて実施

画面に初期化情報と生体撮影処理
を埋め込む

画面を操作して、登録処理を実行
生体情報撮影要求。必要な初期化情報があれば、同時に渡す

生体認証センサーに利用者の生体情報を読み込ませることを促すガイド画面を表示
生体情報撮影要求

生体情報をテンプレート化

テンプレートを返却＋サービスID、
補助検索項目
登録情報を送信サービスIDに紐づく連携IDを採番

登録機能を呼び出す

登録結果画面を表示

新規ウインド【登録結果処理】
被災
登録処理が正常の場合
宛名№と生体情報登録結果を画面に表示する
正常：宛名№：ｘｘｘｘｘｘｘ の方の本人確認ができました。
「閉じる」ボタンをクリックして画面を閉じ
登録結果として宛名№：「ｉｄ」「ｒｓｌｔ」をリダイレクト先
URL「rtn」に返す。
【エラー結果処理の場合】
エラー内容・エラーコードを表示する。
（詳細はエラー処理に記載）

登録結果を返す【正常系処理の場合】
戻り先へアクセス
登録結果画面を受け取り記録する

結果画面を生成し登録結果を返す

DBに生体情報を登録

【生体情報削除】※生体情報削除の考え方：
被災者支援システムからサービスIDを指示して削除を行う。生体認証システムと連携機能の内、当該サービスIDに紐づく情報をDB上から物理削除を行う。
削除した連携IDは欠番とし、再利用はしない。また削除した生体情報は被災者管理システム及び生体認証サーバ管理機能から再現・再利用できない。

クライアント

生体認証
センサー

サーバ

ベンダ別API（ﾄﾞﾗｲﾊﾞ、ｸﾗｲｱﾝﾄｱﾌﾟﾘ含

Webブラウザ

避難行動要支援者管
理システム

連携機能
（サーバ）

生体認証
システム

避難行動要支援者管理システムにアクセス

スタッフが避難行動要支援者管理システムの「生体認証削除」
ボタンをクリック

避難行動要支援者
管理システムの画面表示

新規ウインドスタッフが「生体認証管理」
画面の「はい」ボタンをクリッ
クして連携機能に処理を渡す（画面は残す）「いいえ」ボタンをクリックした
場合は戻り先URLに検索チケット及びサービスＩＤ、リダイレクト先を
生体認証管理画面に初期化情報と共に埋め込む※埋め込み情報
検索チケット 「tckt」：Nulｌ
サービスＩＤ 「ｉｄ」：宛名№
戻り先URL 「rtn」：
https://demo.nmc.jp/ｘｘｘｘｘｘｘｘｘｘ.php

生体削除用画面へアクセス
削除機能を呼び出す・DBから生体情報を削除
削除結果を返す

削除結果画面を表示

新規ウインド【削除結果処理】
削除処理が正常の場合
宛名№と生体情報削除結果を画面に表示する
正常：宛名№：ｘｘｘｘｘｘｘ の方の生体情報の削除ができました。
「閉じる」ボタンをクリックして画面を閉じ

削除結果を返す【正常系処理の場合】
リダイレクト先へアクセス
削除結果画面を生成する【エラー結果処理の場合】
エラー内容・エラーコードを表示する。
（詳細はエラー処理に記載）

被災

削除結果画面を表示

連携機能のサービスIDに紐づく
連携IDを削除【エラー処理】（共通）

連携機能及び生体認証システムでエラーが発生した場合の処理シーケンス（共通）クライアント

生体認証
センサー

サーバ

ベンダ別API（ﾄﾞﾗｲﾊﾞ、ｸﾗｲｱﾝﾄｱﾌﾟﾘ含

Webブラウザ

避難行動要支援者管
理システム

連携機能
（サーバ）

生体認証
システム

被災者支援システム側処理（詳細略）

生体認証を呼び出す・DBから生体情報を削除
生体認証結果を返す

新規ウインド【エラー結果処理の場合】
エラー内容・エラーコードを表示する。
「閉じる」ボタンをクリックによりエラー結果画面を表示

生体認証システムからのエラーコードを受けった場合連携機能にてエラー編集を行いエラー結果画面を生成

＜付録 4＞
オフライン登録処理検討書（オフライン登録処理案）

バッチ登録処理案
生体情報登録について、下記前提・検討事項を基にあるべき姿とプロトタイプシステム実装案を検討する。
前提
生体情報登録は被災者支援システム側の日々業務システムの一部である「避難行動要支援者管理システム」から、その機能が呼び出される。
・プロトタイプシステムでは「現地処理」について連携機能と生体認証システムとオンライン処理される。
・本格導入に際し、登録機能のあるべき姿として、生体情報登録はオフラインＰＣ登録を実現する。
検討事項※生体情報登録は該当者がいる現地にスタッフが赴き、持参したモバイルＰＣ（オフライン・スタンドアロン）にて登録する。
※モバイルＰＣでの登録処理は「前処理」、「現地処理」、「後処理」の３行程からなる。
「前処理」：自治体内ＮＷオンライン環境で、生体情報登録該当者の情報（サービスＩＤ他個人を特定する情報）を「避難行動要支援者管理システム」から抽出する。
「現地処理」：事前に抽出した生体情報登録該当者の情報を入力とした「避難行動要支援者管理システム-生体情報登録」機能から、「連携機能」「生体認証システム-登録機能」を呼び出し、生体情報登録を行う。
登録誤り抑止の為、登録後に１：１認証を行い登録した「サービスID」と「生体情報」の正当性を確認する。
「後処理」：帰庁後にモバイルＰＣから連携機能・生体認証システムに生体情報データを登録する。
バッチ登録方法は実ビジネスにおいて各ベンダー毎に詳細化し、決定する。
※実現案１：モバイルＰＣに蓄えた情報を入力情報として、オンライン環境での登録処理プロセスを疑似的に動作させる※実現案２：生体情報登録に必要なデータを全て特定し、サーバシステムにコピーする

バッチ登録 処理概略

：内はモバイルＰＣでの処理

避難行動要支援者管理システム
生体情報
登録該当者
抽出条件

生体情報
登録該当者
抽出

「前処理」

要援護者支援ＤＢ

生体情報登録該当者情報.ＣＳＶ・サービスＩＤ、個人特定情報、補助検索項目（性別）「現地処理」

生体情報登録該当者情報.ＣＳＶ・サービスＩＤ、個人特定情報、補助検索項目（性別、年代、地区）

生体認証登録対象者の情報を表示させる
スタッフが一覧から該当者を選び「本人登録（生体認証）」ボタンをクリックし、「連携機能」「生体認証システム‐登録機能」を呼び出す

生体情報
登録該当者
登録
「モバイルＰＣ登録」〔「登録」処理シーケンスに同じ〕

連携機能

生体認証
システム

連携機能

生体認証
システム

ご登録誤り抑止の為、１：１認証による登録確認を行う。
生体認証登録対象者の情報を表示させる

生体情報
1：1認証

スタッフが「本人確認（生体認証）」
ボタンをクリックし、1：1生体認証を行う
認証が出来なかった場合は再度登録処理を行う

「後処理」
連携機能

生体認証
システム

登録生体情報アップロード

帰庁後、ＰＣをＮＷ接続し、連携機能（サーバ）、
生体認証システム（サーバ）に登録生体情報をアップロードする。

「登録」処理※アップロード方式については〔庁内ＮＷサーバ〕
別途検討・詳細化が必要

生体情報登録該当者情報.ＣＳＶによるアップロード対象データ指

連携機能

生体認証
システム

※現地処理は被災者支援システム側から連携機能を呼び出すＡＰＩ及び引数にて対応可能。
※バッチ登録処理でサーバへ登録した生体情報について、オンライン処理以外にご本人の生体情報を使っての直接確認は基本的にできない。
※後処理は下記方式比較より実現方法を検討の上、各ベンダー毎に方式を決定する。
「プロトタイプシステム」ではバッチ登録はスコープ外としているため、実現案２について場合によっては連携機能修正が発生する。
生体情報（テンプレート）を生体認証システム外部に出力するため、情報流出に関するリスクヘッジが必要。
実現案１：モバイルＰＣに蓄えた情報を入力情報として、オンライン環境での登録処理プロセスを疑似的に動作させる
・プロトタイプシステム（連携機能）、生体認証システムへの仕様変更はベンダーによりあり
モバイルＰＣ側の生体情報（テンプレート）をバッチ登録するプロセスの機能追加
・基本的にオンライン入力処理と同じになるため、必要なデータの洗い出す必要は無く、「連携ＩＤ」も含めシステム間のデータ整合性は意識する必要は無い
実現案２：生体情報登録に必要なデータを全て特定し、サーバシステムにコピーする・プロトタイプシステム（連携機能）、生体認証システムへの仕様変更はベンダーによりあり
・各ベンダー毎に生体認証システムとして必要なデータを全て洗い出し、整合性を保ったまま対象ＤＢを直接更新
・ベンダーによってはプロセスの整合性を保つためのデータを作りこむ処理が必要
・サービスＩＤに繋がる「連携ＩＤ（モバイルＰＣ）」から「連携ＩＤ（サーバ）」へ変換して連携機能（サーバ）に登録する

＜付録 5＞連携機能詳細仕様書

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）
詳細仕様書
2016.12.20

株式会社

日立システムズ第 ５版

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

変更履歴
#

版

変更日

1.

1

2016.03.09

―

新規作成

2.

2

2016.06.20

4．連携機能

被災者支援システムと連携機能の連携方式を、

変更箇所

変更内容

SOAP から URL による HTML 画面連携へ変更。
3.

2

2016.06.22

5．連携機能実装例

章を追加

4.

3

2016.08.19

4.2·

エラーハンドリング用の戻り値を追加

ース仕様

·

検索補助項目を追加

5.

4.3

エラーコード

節を追加

6.

4.2.2

1:1 認証連携機能インタフェ

戻り値で ID を返すのではなく、一致した／しないを返すように変更。それに伴い名前を「id」から「rslt」に変更

7.

5．連携機能実装例

記載追加

8.

4

2016.09.16

3．前提条件表７を詳細化9.

52016.12.xx

4.3

表１７に「ユーザーへのメッセージ」の列を追加

エラーコード生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

目次
変更履歴 .................................................................................................................................................... 2
目次 ........................................................................................................................................................... 3
1.

はじめに............................................................................................................................................. 1
1.1.

本書の位置付け............................................................................................................................ 1

1.2.

関連ドキュメント ........................................................................................................................ 1

1.3.

用語の定義 ................................................................................................................................... 12.

システム概要...................................................................................................................................... 2

3.

前提条件............................................................................................................................................. 44.

連携機能............................................................................................................................................. 5
4.1.

連携機能一覧 ............................................................................................................................... 5

4.2.

連携機能インタフェース仕様....................................................................................................... 5

4.2.1.

1:N 検索 ................................................................................................................................ 5

4.2.2.

1:1 認証 ................................................................................................................................. 7

4.2.3.

登録....................................................................................................................................... 8

4.2.4.

削除....................................................................................................................................... 9

4.3.
5.

エラーコード ..............................................................................................................................11

連携機能の実装例..............................................................................................................................13
5.1.

作業内容 .....................................................................................................................................13

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

1. はじめに1.1. 本書の位置付け
本書は、「生体認証応用被災者支援システムプロトタイププログラム（連携機能）」（以下、本プログラム）の使用を示す。

1.2. 関連ドキュメント
表 1 関連ドキュメント
#

用語

説明

1.

「別紙 連携機能シーケン

被災者支援システム、連携機能、生体認証機能の各機能の関連を示ス」

す。

1.3. 用語の定義
表 2 用語の定義
#

用語

説明

サービス ID

被災者支援システムが被支援者を識別するための ID

2.

連携 ID

連携機能と生体認証機能がユーザーを識別するための ID

3.

生体情報

生体認証機器ベンダが提供する機器を用いて取得可能な生体由来の情報。

1.

ユーザーの認証／識別に使用する。一般的にはテンプレート等と呼ばれるもの。
4.

生体認証機器

生体情報を取得するために使用される機器

1

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

2. システム概要
本プログラムを含む、生体認証応用被災者支援システムのシステム概要について、想定するシステム構
成を示す。
生体認証機能連携機能

日々業務システム

登録・削除 連携 ID (仮) 生体認証データ

 連携 ID (仮) サービス ID (仮) 住基データ 避難行動要支援者
 etc.

ベンダ別
API

API

被災者支援システム連携

発災時にデータコピー

登録・削除
1:N 検索






被災者台帳
避難者台帳
避難行動要支援者台帳
etc.

生体情報で検索（1:N 検索）

：本書の定義範囲

図 1 システム構成「図 1」の各コンポーネントについて説明する。
表 3 システムのコンポーネント#

コンポーネント

1.

日々業務システム

日常の日々業務を行うためのシステムであり、被災者支援システムとは異なるシ（避難行動要支援者管

ステムである。また運用主体も被災者支援システムとは異なる。

理システム）

住人の生体情報は、日々業務システムから連携機能を通して登録される。

被災者支援システム

災害発生時の業務を行うためのシステム。災害発生時に事案毎に起動される。

2.

説明

また起動時に業務必要な情報が日々業務システム等の関連システムからコピーされる。
生体認証を利用した 1:N 検索機能等は、被災者支援システムの画面から起動される。

2

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書#
3.

コンポーネント
連携機能

説明
被災者支援システムと生体認証機能を接続するためのシステムである。生体認証
機能は提供元のベンダの仕様に依存するため、被災者支援システムが生体認証機
能へ直接接続した場合、生体認証機能を提供するベンダごとに複数の実装が必要になってしまう。そこで、連携機能を用意し被災者支援システムとのインタフェースを統一することで、被災者支援システムが複数の生体認証機能に容易に対応できるようになる。
なお連携機能は、統一されたインタフェース（連携 API）に従い、生体認証機能を提供する各ベンダが実装し提供する。接続する生体認証機能の選択は被災者支援システムを運用する各自治体が選択を行う。
また生体認証装置を制御するクライアント側と 1:N 検索、1:1 認証、登録等の処理を行うサーバ側の２つのモジュールで構成される。

4.

連携 API

連携機能が提供し、被災者支援システムが生体認証機能を使用するための API である。連携 API に従った連携機能を各生体認証機能ベンダが提供することで、被災者支援システムは統一されたインタフェースで複数の生体認証機能に対応可能
になる。

5.

生体認証機能生体認証機器ベンダが提供する生体認証機能である。

6.

ベンダ別 API

生体認証機器ベンダが、自身が提供する生体認証機能に接続するために用意したAPI である。生体認証機能ごとに異なる。

3

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

3. 前提条件
本プログラムは次に示すソフトウェアおよびハードウェアを前提とする。
表 4 前提ソフトウェア（生体認証機能サーバ）
#

分類

説明

1.

OS

Windows 2012 R2

2.

DBMS

SQL Server 20123.

アプリケーションサーバ

ASP.NET 4.0

4.

生体認証機能日立ソリューションズ

認証管理システム

AUthentiGate 05-01

表 5 前提ソフトウェア（クライアント連携機能）
#

分類

説明

1.

OS

Windows 7 Professional x86

2.

Web ブラウザ

Internet Explorer 11

3.

生体認証機能日立ソリューションズ

認証管理システム

AUthentiGate 05-01

表 6 前提ハードウェア#
1.

分類
生体認証装置説明
日立製作所 指静脈認証装置 H-1 PC-KCA110
日立ソリューションズ

指静脈認証システム

表 7 前提ソフトウェア（サーバー連携機能）
#

分類

説明

1.

OS

CentOS

7.0

2.

アプリケーションサーバ

Tomcat 8.5（Java8）4

静紋 J300

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

4. 連携機能
連携機能は被災者支援システムから起動される Web ページとして実装される。
生体認証における被災者支援システムと連携機能の処理フローを「別紙 連携機能シーケンス」に示す。

4.1. 連携機能一覧
連携機能は、被災者支援システムのサーバ側プログラムから起動されることを想定し Web ページとして実装する。連携機能は 1:N 検索、1:1 認証、登録および削除の処理を実現する。
表 8 連携機能（サーバ）
#

機能

1.

説明

1:N 検索生体情報を受け取り、該当者を検索する機能である。生体情報の照合処理は、生体認証機能にて実行される。

2.

1:1 認証ID と生体情報を受け取り、ID が正当なものであるかを検証する機能である。生体情報の照合処理は生体認証機能にて実行される。

3.

ID と生体情報を受け取り、当該生体情報をデータベースに保存するための機能で登録ある。生体情報は生体認証機能がもつデータベースに保存される。
4.

ID を受け取り、データベースから ID と ID に紐づく生体情報を削除する機能であ削除

る。

4.2. 連携機能インタフェース仕様
連携機能のインタフェース仕様を次に示す。

4.2.1. 1:N 検索
1:N 検索機能のインタフェース仕様を次に示す。
(1)

引数
1:N 検索機能の引数は URL パラメータ（GET メソッドでアクセスする場合）またはフォームデータ（POST メソッドでアクセスする場合）として指定する。
表 9 1:N 検索の引数#
1. tckt

引数型
string説明
被災者支援システムが発行したワンタイムチケットを指定する。不要な場合は指定なし（Null）でも可。

2. fltrstring補助検索項目を指定する。複数指定された場合は、指定されたすべての条件を AND で検索する。
※連携機能側で設定する画面を用意する。被災者支援シ
ステムからは‘Null’となる。
※プロトタイプシステムは複数指定されても最初の項目のみ有効とする。

5

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書#

引数

3. rtn型
string

説明
戻り先 URL。
連携機能は生体情報を使用して候補者の ID
リストを抽出した後、本引数に指定された URL に POST指示を行う。

4. rtn2string

戻り先ウインドウ名。連携機能が引数 rtn に指定された
URL に POST する際、ターゲットとして本引数に指定されたウインドウ名を使用する。

(2)

戻り値
被災者支援システムの検索結果一覧画面への POST 指示を含んだ HTML 画面。本画面のロード完了後に引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記のパラメータが含まれる。
処理結果が正常の場合：下表の#1、#2、#3 被災者支援システムの検索結果一覧画面へのリダイ
レクト指示。
処理結果が異常の場合：#4、#5 連携機能のエラーメッセージ画面へ
表 10 1:N 検索の戻り値#

引数

1. tckt型
string説明
被災者支援システムが発行したワンタイムチケット。引数で渡されたワンタイムチケットそのもの。指定されなかった場合、空文字列を返す。

2. id0 … id9

string

候補者の ID。候補者が複数存在する場合、候補者の数だけ複数指定する。本人である確率が高い順に id0 から指定される。候補者が存在しない場合、指定なし（Null）。
例えば、サービス ID＝abc とサービス ID＝xyz の 2 名がヒットし、abc の方がより本人である確率が高い場
合、id0=abc、id1=xyz と指定する。

3. id0_rnk …

stringid9_rnk

候補者のランク（1、2、3 のどれかが指定される）。候
補者が複数存在する場合、候補者の数だけ複数指定する。1、2、3 の順で本人である確率が高いことを示す。
どの値を使用するかは生体認証システムに依存する。

4. errstring連携機能または生体認証システムでエラーが発生した
場合のエラー内容を通知する。正常処理の場合は指定な
し（Null 値）。

5. ecdstring

生体認証システムでエラーが発生した場合、生体認証シ
ステムから受信したエラーコードを通知する。

6

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書(3)

例外
生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、POST 指示を行わず、画面にエラーメッセージを表示する。

4.2.2. 1:1 認証
1:1 認証機能のインタフェース仕様を次に示す。
(1)

引数
1:1 認証機能の引数は URL パラメータ（GET メソッドでアクセスする場合）またはフォームデータ（POST メソッドでアクセスする場合）として指定する。
表 11 1:1 認証の引数#

引数

1. tckt型
string説明
被災者支援システムが発行したワンタイムチケットを指定する。不要な場合は指定なし（Null）でも可。

2. id

string

本人確認する利用者のサービス ID

3. rtnstring

戻り先 URL。
連携機能は生体情報を使用して候補者の ID
リストを抽出した後、本引数に指定された URL に POST指示を行う。

(2)

戻り値
被災者支援システムの検索結果一覧画面への POST 指示を含んだ HTML 画面。本画面のロード完了後に引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記のパラメータが含まれる。
処理結果が正常の場合：正常処理画面（確認、不一致）画面を表示する。
「rslt」=”y”： 識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができました。

「rslt」=”n”： 識別番号：ｘｘｘｘｘｘｘ の方の本人確認ができませんでした。

処理結果が異常の場合：該当するエラーコード「err」とエラーメッセージ「msg」を連携機能のエラーメッセージ画面に表示する。
エラーメッセージ画面の閉じるボタンで画面を閉じる。
表 12 1:1 認証の戻り値#
1. tckt

引数型
string説明
被災者支援システムが発行したワンタイムチケット。引数で渡されたワンタイムチケットそのもの。

2. rslt

string

生体情報が一致したかどうか。”y”：一致した。”n”：一致しなかった。

3. errstring連携機能または生体認証システムでエラーが発生した
場合のエラー内容を通知する。正常処理の場合は指定な

7

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

し（Null 値）。
4. ecdstring

生体認証システムでエラーが発生した場合、生体認証シ
ステムから受信したエラーコードを通知する。

5. msg(3)

stringecd に該当するエラーメッセージを通知する。

例外
生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、POST 指示を行わず、画面にエラーメッセージを表示する。

4.2.3. 登録
登録機能のインタフェース仕様を次に示す。
(1)

引数
登録機能の引数は URL パラメータ（GET メソッドでアクセスする場合）またはフォームデータ（POST メソッドでアクセスする場合）として指定する。
表 13 登録の引数#
1. tckt

引数型
string説明
被災者支援システムが発行したワンタイムチケットを指定する。不要な場合は指定なし（Null）でも可。

2. id

string

生体情報を登録する利用者のサービス ID

3. fltrstring補助検索項目を指定する。複数指定された場合は、指定されたすべての条件を追加する。
※プロトタイプシステムは複数指定されても最初の項目のみ有効とする。

4. rtnstring

戻り先 URL。登録機能が完了された後、本引数に指定された URL に POST 指示を行う。

(2)

戻り値
登録結果を示すメッセージを表示するための HTML 画面。
処理が正常終了した場合のみ、本 HTML 画面を閉じるときに引数 rtn に指定された URL に POST指示を行う。POST 指示には下記のパラメータが含まれる。
処理結果が正常の場合：登録結果画面を表示する。
「識別番号ｘｘｘｘｘｘｘの方の生体認証情報の登録ができました」
登録結果画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の＃１、＃2、＃３パラメータが含まれる。

8

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

処理結果が異常の場合：連携機能から該当するエラーコード「err」とエラーメッセージ「msg」
を連携機能のエラーメッセージ画面に表示する。
エラーメッセージ画面の閉じるボタンで画面を閉じる。
表 14 登録の戻り値#

引数

1. rslt型
string説明
生体情報が登録できたかどうか。”y”：登録した。”n”：
登録できなかった。

2. id

string

生体情報を登録する利用者のサービス ID

3. timestamp

string

登録処理を行った日時。yyyyMMddHHmmss で表記。
連携システムおよび生体認証システムのどちらで取得
してもよい

4. errstring連携機能または生体認証システムでエラーが発生した
場合のエラー内容を通知する。正常処理の場合は指定な
し（Null 値）。

5. ecdstring

生体認証システムでエラーが発生した場合、生体認証シ
ステムから受信したエラーコードを通知する。

6. msg(3)

stringecd に該当するエラーメッセージを通知する。

例外
生体認証装置が接続されていない、生体情報の生成処理でタイムアウトが発生し生体情報が生成できなかったなどのエラーが発生した場合は、エラーメッセージを表示する。

4.2.4. 削除
削除機能のインタフェース仕様を次に示す。
(1)

引数
削除機能の引数は URL パラメータ（GET メソッドでアクセスする場合）またはフォームデータ（POST メソッドでアクセスする場合）として指定する。
表 15 削除の引数#

引数

1. tckt型
string説明
被災者支援システムが発行したワンタイムチケットを指定する。不要な場合は指定なし（Null）でも可。

id

string

本人確認する利用者のサービス ID

3. rtnstring

戻り先 URL。削除機能が完了された後、本引数に指定2.

された URL に POST 指示を行う。

(2)

戻り値
削除結果を示すメッセージを表示するための HTML 画面。
9

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

処理が正常終了した場合のみ、本 HTML 画面を閉じるときに引数 rtn に指定された URL に POST指示を行う。POST 指示には下記のパラメータが含まれる。
処理結果が正常の場合：削除結果画面を表示する。
「識別番号ｘｘｘｘｘｘｘの方の生体認証情報の削除ができました」
削除結果画面の閉じるボタンで画面を閉じる。
引数 rtn で指定された URL に POST 指示を行う。
POST 指示には下記の＃１、＃2、＃３パラメータが含まれる。
処理結果が異常の場合：連携機能から該当するエラーコード「err」とエラーメッセージ「msg」
を連携機能のエラーメッセージ画面に表示する。
エラーメッセージ画面の閉じるボタンで画面を閉じる。
表 16 削除の戻り値#

引数

1. rslt型
string説明
生体情報が削除できたかどうか。”y”：削除した。”n”：
削除できなかった。

2. id

string

生体情報を削除する利用者のサービス ID

3. timestamp

string

削除処理を行った日時。yyyyMMddHHmmss で表記。
連携システムおよび生体認証システムのどちらで取得
してもよい

4. errstring連携機能または生体認証システムでエラーが発生した
場合のエラー内容を通知する。正常処理の場合は指定な
し（Null 値）。

5. ecdstring

生体認証システムでエラーが発生した場合、生体認証シ
ステムから受信したエラーコードを通知する。

6. msg(3)

stringecd に該当するエラーメッセージを通知する。

例外
id に指定されたサービス ID が登録されていないなどのエラーが発生した場合は、エラーメッセージを表示する。

4.2.5. タイムスタンプのフォーマット
登録および削除の戻り値の「timestamp」は、数字 8 桁（yyyyMMddHHmmss）で表記する。
それぞれの表記ルールについて示す。
表 17 タイムスタンプの表記
#

位置

桁

説明

1. yyyy

4桁

西暦 4 桁の年を表す。

2. MM

2桁

月を表す。1 桁の場合は先頭に 0 を付ける。

3. dd

2桁

日を表す。1 桁の場合は先頭に 0 を付ける。

10

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

4. HH

2桁

時を表す。24 時間制。1 桁の場合は先頭に 0 を付ける。

5. mm

2桁

分を表す。1 桁の場合は先頭に 0 を付ける。

6. ss

2桁

秒を表す。1 桁の場合は先頭に 0 を付ける。

4.3. エラーコード
API の戻り値 err に指定される値は次のとおりである。
表 18 エラーコード
#

値

1.

null

処理は正常に完了した。

―

―

2.

b

生体認証システムがエラーをecd の内容を参照し、生体認証シ

生体認証システムでエラー返した。

ステムの指示に従う。

が発生しました。管理者に説明

主な対処方法

ユーザーへのメッセージ

お問い合わせください（b:＜生体認証システムのコー
ド＞）。
3.

c1

生体認証機器が接続されてい生体認証機器が PC に接続されて生体認証機器が接続されてないいることを確認し、再実行。

いるか確認してください
(c1)。

4.

c2

制限時間内に生体情報の撮影

再実行し制限時間までに生体を提

生体情報が読み取れません

が完了しなかった（指や掌が示でした。もう一度実行してください(c2)。

置かれなかった、顔が認識できなかったなど）
5.

6.

c3

cx

撮影に失敗した（ペンなどの再実行し正しく生体を提示（正し生体情報が読み取れません

生体以外の物体が提示された

い提示の方法は、生体認証システでした。もう一度実行してことを検知したなど）

ムのベンダに依存）ください(c3)。

その他、生体情報の撮影に関

ecd の内容を参照し、生体認証シ

生体情報が読み取れません

するエラー

ステムの指示に従う。

でした。管理者にお問い合
わせください(cx: ＜生体認
証システムのコード＞)。

7.

s1

生体認証システムに接続できなかった

・ 生体認証システムが正常稼働

生体認証システムに接続でしていることを確認し、再実きませんでした。管理者に行

お問い合わせください(s1)。

・ 生体認証システムの接続先設
定が正しいことを確認し、再
実行
8.

s2

データベースへの接続でエラDBMS が正常稼働していることを連携システムでエラーが発ー

確認し、再実行

生しました。管理者に問い合わせください(s2)。

11生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

#
9.

値
s3

説明
指定されたサービス ID は、

主な対処方法サービス ID を修正して再実行システムに存在しない（削除

ユーザーへのメッセージ指定された ID は登録されていません(s3)。

時）
10. s4

必須パラメータが不足していパラメータを修正

内部エラーが発生しましる（主に開発中に発生する問題であた。管理者にお問い合わせ

り運用中に発生する可能性は低ください(s4)。

い）
11. s5

パラメータに指定された値がパラメータを修正

内部エラーが発生しまし

正しくない（書式不正、範囲（主に開発中に発生する問題であた。管理者にお問い合わせ外等）

り運用中に発生する可能性は低ください(s5)。

い）
12. sx

連携システムでのその他エラ

連携システムの稼働状況を確認。

ー

連携システムでエラーが発生しました。管理者に問い合わせください(sx)。

12生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

5. 連携機能の実装例
1:N 検索機能を例として、連携機能の実装方法と被災者支援システムでの想定実装方法について示す。
なお本章の記載はあくまでも例であり実装方式を規定するものではなく、また本方式で実装可能であることを保証するものでもない。

5.1. 作業概要
連携機能の実装に必要な作業は次のとおりである。
表 19 実装に必要な作業#
1.

作業
URL の決定説明
連携機能インタフェースの各機能にアクセスするための URL を決定する。

2.

連携機能の Web ページを実装

連携機能インタフェース仕様に従って、被災者支援システムからのリク（インタフェース）エストを受け付けるための Web ページを実装する。ここで実装する Web
ページでは、ベンダ別 API を使用して生体認証機器を操作し、生体情報を撮影する処理を実装する。

3.

連携機能の Web ページを実装

撮影された生体情報を受け取り、生体認証機能と連携して 1:N 検索を行

（ベンダ別 API の呼出）う Web ページを実装する。このページは常に被災者支援システムへリダ
イレクトする。

4.

被災者支援システムへのボタン

被災者支援システムへ、1:N 検索を実行するためのボタンを実装する。

の実装
5.

被災者支援システムへの候補者

連携機能から受け取ったサービス ID に対応する被災者情報を表示する

表示画面の実装

ための画面を実装する。

5.2. 作業例
上述の各項目に沿って、例を示す。

5.2.1. URL の決定
連携機能インタフェースの各機能にアクセスするための URL を決定する。URL は連携機能を実装する
言語、アプリケーションフレームワーク等に依存する。ここでは例として、search.jsp とする。

5.2.2. 連携機能の Web ページを実装（インタフェース）
連携機能インタフェース仕様に従って、被災者支援システムからのリクエストを受け付けるための Web
ページを実装する。ここで実装する Web ページでは、ベンダ別 API を使用して生体認証機器を操作し、生体情報を撮影する処理を実装する。
実装例を次に示す。

13

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書<!-- search.jsp --><html><head><title>生体認証１：ｎ検索</title><script type=”text/javascript”>
function scan() {/*ベンダ別 API を使用して、生体情報を撮影する処理が実装されます。
ここでは、撮影された生体情報が変数 bio に設定されると仮定します。
*/
var bio = vender_api();/*
取得した生体情報をフォームパラメータに設定したのちに、連携機能に送信します。
*/
document.forms[0].bio.value = bio;
document.forms[0].submit();}</script></head><!-自動で撮影が開始されるようにイベントを設定します。
--><body onload=”scan”>
リストボックスから項目を選択してから<br/>「ＹＥＳ」ボタンを押してください。
<!-生体情報を連携機能に送信するためのフォームを定義します。
--><form method=”post” action=”search_b.jsp”><input type=”hidden” name=”tckt” value=’<%= request.getParameter(”tckt”)’></input><input type=”hidden” name=”rtn” value=’<%= request.getParameter(”rtn”)’></input><input type=”hidden” name=”rtn2” value=’<%= request.getParameter(“rtn2”)’></input><input type=”hidden” name=”bio” value=’’></input>
検索補助項目： 性別<select name="fltr"><option value="N">選択しない</option><option value="M">男性</option><option value="F">女性</option></select><input type="button" value="ＹＥＳ" onclick="scan()" /><input type="button" value="ＮＯ"/></form></body></html>5.3. 連携機能の Web ページを実装（ベンダ別 API の呼出）撮影された生体情報を受け取り、生体認証機能と連携して 1:N 検索を行う Web ページを実装する。このページは常に被災者支援システムへリダイレクトする。
実装例を次に示す。

14

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書<!—search_b.jsp --><html><head><script>function next() {window.close();document.ichiran.submit();}</script></head><body onload="next()"><%/*ベンダ別 API を使用して 1:N 検索を実行します。
ここでは ids に候補者の ID が生体認証機能から戻されると仮定します。
*/
String[] ids = vender_api();/*
候補者の ID から被災者支援システムへの POST 指示を行うためのフォームを作成します。
フォームの宛先に、被災者支援システムから受け取った rtn と rtn2 を使用します。

%>*/
String rtn = request.getParameter(“rtn”);
String tckt = request.getPrameter(“tckt”);
String rtnWindow = request.getParameter(“rtn2”);<form method="post" name="ichiran" action="<%= rtn %>" target="<%= rtnWindow %>">
<input type="hidden" name="tckt" value="<%= tckt %>" /><input type="hidden" name="id0" value="<%= ids[0] %>" /><input type="hidden" name="id1" value="<%= ids[1] %>" />...
<input type="hidden" name="id9" value="<%= id[9] %>" /></form></body></html>5.4. 被災者支援システムへのボタンの実装
被災者支援システムへ、1:N 検索を実行するためのボタンを実装する。
ボタンの実装例を次に示す。
<form action="http://coop_server/search.jsp" method="POST"><input type="submit" value="本人確認（生体認証）"></input><input type="hidden" name="tckt" value="01010101"></input><input type="hidden" name="fltr" value="男性"></input><input type="hidden" name="rtn" value="http://support_server/search_result.jsp"></input><input type=”hidden” name=”rtn2” value=”bio”></input></form>15

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）詳細仕様書

5.5. 被災者支援システムへの候補者表示画面の実装
連携機能から受け取ったサービス ID に対応する被災者情報を表示するための画面を実装する。
ここでは被災者支援システムの候補者表示画面が JSP で実装されていると仮定して、実装例を示す。
<!—search_result.jsp --><html><head> </head><body><%// チケットと取り出します。
String ticket = request.getParameter(“tckt”);/*
チケットの正当性をチェックし、処理の続行可否を判断します。
*/// 連携機能から渡されるサービス ID を取り出します。
String serviceId = request.getParameter(“id0”);/*サービス ID に該当するユーザーの情報を表示します。
*/%></body></html>以上

16

－禁無断転載－

２８－２

平成２８年度
生体認証を用いた被災者支援システムの研究開発
報
告書
平成２９年３月
作

成 一般社団法人日本自動認識システム協会
東京都千代田区岩本町 1-9-5 FK ビル 7 階
TEL 03-5825-6651