２７－７

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

告書

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

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

http://ringring-keirin.jp

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

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

目

次

はじめに
目

次

1.

研究開発の目的.................................................................................................................... 1

2.

研究開発の実施計画............................................................................................................. 2

3.

研究開発の実施体制............................................................................................................. 3
3.1 実施体制 ......................................................................................................................... 33.2 検討委員会 ..................................................................................................................... 5
3.3 実施スケジュール........................................................................................................... 6

4．研究開発の内容..................................................................................................................... 84.1 検討委員会 ..................................................................................................................... 9
4.2 利用シーンの精査と必要な仕様及び機能 ..................................................................... 16
4.2.1 被災者支援システム側から見た利用シーンと必要な仕様及び機能 ........................ 16
4.2.2 生体認証側から見た利用シーンと必要な仕様及び機能 .......................................... 23
4.3 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発 ................ 31
4.3.1 被災者支援システム側のプロトタイプ・プログラムの開発 ................................... 31
4.3.2 連携及び生体認証側のプロトタイプ・プログラムの開発 ...................................... 40
4.3.3 成果物の公開・提供について................................................................................. 47
4.3.4 今後の課題 ............................................................................................................. 48
5.

平成２７年度活動まとめ.................................................................................................... 49
5.1 利用シーンの精査と必要な仕様及び機能 ..................................................................... 49
5.2 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発 ................ 53

6.

平成２８年度活動に向けて ................................................................................................ 55＜別紙-1＞ 生体認証応用被災者支援システムプロトタイププログラム（連携機能）
シーケンス図＜別紙-2＞ 生体認証応用被災者支援システムプロトタイププログラム（連携機能）
詳細仕様書＜別紙-3＞ 生体認証応用被災者支援システムプロトタイププログラム（連携機能）
サンプルコード＜別紙-4＞ 成果物の情報公開を行う考え方

1.

研究開発の目的
現代の日本において社会生活を営むにあたり身分を証明するために必要とされる ID は、免許証・健康保険証・パスポート・キャッシュカード・住基カードなど、所持するタイプの本人確認
手段が大多数である。しかしながら、東日本大震災において明らかになったのは、被災を受けられた方々の多くが津波や家屋の倒壊などにより家や身の回りのものを失った結果、身分を証明する手段も失ってしまい、本人確認ができなくなったことから支援の混乱や効率の低下を招いたことである。また、避難所に避難される方々の中には、災害弱者といわれる高齢者や子供、また障
害のある方々を始めとした災害時等避難行動要支援者が含まれており、その中には自分が誰であるかを示すために必要な情報の提供が困難な方がいらっしゃることが容易に想像できる。自治体の方々からは、自治体が避難所での災害対策を推進する上で、このような本人確認が困難な方に対する避難所での本人特定業務を改善することが必要であるとのお考えもお聞きしている。
現在、本人確認のために適用可能な認証技術の中に生体認証技術がある。これは身体的特徴を用いた本人確認手段であり、所持物を必要とせずに確実に本人を特定できる技術である。生体認
証技術による本人特定手段と自治体が運営する被災者支援システムが連携することにより、自治体が避難所で実施する避難者、特に自分が誰であるかを示すために必要な情報の提供が困難な方の本人特定が容易になり、自治体の避難所での避難者受け入れ業務の質が向上する可能性がある。
また、避難所などでの支援物資の支給や生存確認など様々な用途にも生体認証技術が応用されることで、他の被災者支援サービスの質が向上する可能性もある。さらに、この仕組みが全国の自治体に広がることにより、各所の自治体で避難者に均質なサービスが提供できるようになる可能性もあると考えている。
以上を鑑み、本研究開発では受益者として被災者と自治体職員を想定し、被災者、特に自分が誰であるかを示すために必要な情報の提供が困難な被災者は避難所での本人確認を容易にすることで個人の要望に即した支援を速やかに受けたいというニーズがあるのではないか、また自治体
職員には本人確認が困難な避難者の本人確認作業の手間をできるだけ低減して被災し避難された方々へ迅速かつ確実なサービスを提供したいというニーズがあるのではないかと想定した。
これらの想定をもとにして、本研究開発では、災害時に自治体が運営する被災者支援システムの改善につなげることを目指して、避難所における被災者支援時に必要な本人確認の改善のために有効に利用できる手段の一つに生体認証技術があることを示すことを目的とした。
また一方で、生体認証技術には被災者支援に適用するにあたっての様々な課題も存在する。
これらを踏まえ、本研究開発では、被災者支援システムへの生体認証技術の適用方法の具体的検討、適用時の課題の洗い出しと解決策の検討、生体認証技術を用いた被災者支援システムのプロトタイプ・システムの開発を行い、プロトタイプ・システムを用いた検証を通じて得られた成果をもとに、生体認証技術を適用した被災者支援の一つのあり方を示すことを目指した。

1

2.

研究開発の実施計画
被災者支援において中心的役割を果たす自治体が行う支援業務に、生体認証による本人確認手
段を組み込むため、次の調査・検討、開発及び検証を 3 ヵ年の期間で行うことを計画し、本研究開発に取り組んでいる。
(1) 調査・検討フェーズ（平成 26 年度）
生体認証技術を被災者支援に適用するための利用方法を検討すると共に、適用時の課題の洗い出しと解決方法の検討を行う。
(2) プロトタイプ・システムの開発フェーズ（平成 27 年度）
被災者支援システム全国サポートセンター（西宮市情報センター内）が運営・管理している
被災者支援システムを生体認証の組み込み候補とし、被災者支援システムと生体認証技術が連携する生体認証を用いた被災者支援システムのプロトタイプ・システムの開発を行う。
(3) 検証フェーズ（平成 28 年度予定）
生体認証技術と被災者支援システムの連携に積極的な自治体を見つけ、自治体と連携しながら、生体認証を用いた被災者支援システムのプロトタイプ・システムの開発を完了し、そのプロトタイプ・システムを用いて被災者支援システムと生体認証技術が連携することの有効性を確認するための検証作業を行う。

平成 27 年度は平成 26 年度の成果を踏まえながら下記に示す内容に取り組んだ。
(a) 利用シーンの精査と必要な仕様及び機能について検討
生体認証技術と連携する被災者支援システム側と被災者支援システムと連携に必要な連携と生体認証側のそれぞれに分割し、それぞれが連携しながら次の検討に取り組んだ。
・避難行動要支援者に対する生体認証を用いた本人確認が必要な利用シーンの精査とその利用シーン実現に必要な被災者支援システムの仕様及び機能の検討。
（被災者支援システム側）
・被災者支援システムと生体認証が連携するために必要な被災者支援システムとの連携機能及び生体認証機能部の仕様及び機能の検討。
（連携及び生体認証側）(b) 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発
上記の調査結果をもとに、平成 28 年度の完成を目指し、生体認証を用いた被災者支援シス
テムのプロトタイプ・システムを開発するため、プロトタイプ・プログラムの詳細仕様ならびにプロトタイプ・プログラムの開発を、次の 3 つの部分のに分け開発に取り組んだ。
・被災者支援システムでの必要機能を提供する部分の開発（被災者支援システム側）
・被災者支援システムと生体認証を連携させる部分の開発（連携及び生体認証側）
・生体認証の必要機能を提供する部分の開発（連携及び生体認証側）（生体認証機能部は生体認証ベンダーの独自開発部分のため、本報告の中では触れない。
）

2

3.

研究開発の実施体制

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

3

[実施者]①事業実施および進捗管理・調整②検討委員会の設置・運営③有識者･業界意見の反映④事業成果の業界での活用推進(A) 一般社団法人
日本自動認識システム協会①全体調整・審議②調査内容の検討と審議③プログラム仕様検討内容の検討と審議
審議[検討委員会](有識者(東京理科大)
自治体関係者（西宮市、川口市）
国内生体認証ベンダー（富士通、NEC、日立ほか)
サービス事業者（NTT Data、セコム、凸版印刷)[事業協力自治体]
事業協力

被災者支援システム全国サポートセンター（西宮市情報センター内）[委託調査委託先Ａ]①被災者支援システム側で必要とされる機能仕様調査(調査1)
調査委託

被災者支援システム知見者（（株）システム・エージ）[委託先B]①生体認証側で必要とされる機能仕様調査(調査2)
調査委託

生体認証知見者（（株）日立システムズ）[プログラム開発委託先Ａ]①被災者支援システム側プログラムの開発(開発1)プログラム開発委託

プログラム開発委託

被災者支援システム知見者（（株）システム・エージ）[プログラム開発委託先B]①生体認証側プログラムの開発(開発2)
生体認証知見者（（株）日立システムズ）

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

代表理事 会長

事務局長

事務センター

経理係

研究開発センター

バイオメトリクス担当（2）研究開発体制

RFID担当

バーコード担当

図 3.1-2 研究開発管理・研究体制

4

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

表 3.2-1 生体認証を用いた被災者支援システムの研究開発検討委員会委員名簿（順不同・敬称略）
役割

氏名

所属

役職

備考
SC37WG3
委員

委員長

半谷精一郎 東京理科大学

教授

委員

寳木 和夫

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

副研究
部門長

委員

吉田 稔

西宮市情報センター

センター長

委員

南

晴久

西宮市情報センター

課長

委員

佐藤 学

川口市 情報政策課

主査

委員

村上 秀一

株式会社日立製作所情報・通信システム社

委員

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

委員

塙

委員

中村 敏男

株式会社ＯＫＩソフトウェア

委員

平岡 良彦

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

鷺株式会社ＮＴＴデータ

シニア・ス
ペシャリス

委員

平野 誠治

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

ｵﾌｻﾞｰﾊﾞ

高田 直幸

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

ｵﾌｻﾞｰﾊﾞ

山田 徳幸

日本電気株式会社

ｵﾌｻﾞｰﾊﾞ齋藤 訓

株式会社日立システムズ

主任技師

ｵﾌｻﾞｰﾊﾞ

島方 光治

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

執行役員

ｵﾌｻﾞｰﾊﾞ

上出 和明

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

シニア・ス
ペシャリス

ｵﾌｻﾞｰﾊﾞ加藤 誠司

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

課長補佐

ｵﾌｻﾞｰﾊﾞ中山 和泉

経済産業省 製造産業局

課長補佐

事務局

酒井 康夫

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

センター長 SC37 委員

事務局

山口理津子 一般社団法人日本自動認識システム協会

俊浩

宏行

担当部長

シニアエキ
スパート

日本電気株式会社

5

SC37/WG2
ｴｷｽﾊﾟｰﾄ
研究員

SC37/WG3
ｱﾄﾞﾊﾞｲｻﾞ

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

SC37 委員

3.3

実施スケジュール
平成 27 年度の生体認証を用いた被災者支援システムの研究開発活動は、「2. 研究開発の実施計画」に述べた(2) プロトタイプ・システムの開発フェーズとして、①利用シーンの精査と必要な仕様及び機能について検討と②生体認証を用いた被災者支援システムのプロトタイプ・プログ
ラムの開発に取り組んだ。
具体的には、表 3.2 に示す日程と研究開発内容に取り組んだ。
①利用シーンの精査と必要な仕様及び機能の検討は、生体認証技術と連携する被災者支援シス
テム側と被災者支援システムと連携する生体認証側のそれぞれに分割し、それぞれが連携しながら、避難行動要支援者に対する生体認証技術を用いた本人確認が必要な利用シーンの精査とその利用シーン実現のために必要な生体認証技術を応用する被災者支援システムの仕様及び機能の検討に取り組み、それらをもとにして、避難行動要支援者に対する生体認証技術を用いた本人確認が必要な利用シーンの精査と生体認証技術を応用する被災者支援システムの仕様及び機能をまとめた。
また、②生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発は、生体認証技術と連携する被災者支援システム側と被災者支援システムと連携するために必要とされる連携及び生体認証側のそれぞれに分割し、それぞれが連携しながら、生体認証技術を応用する被災者支援システム実現のために被災者支援システム側に必要な追加プログラム（プロトタイプ）の開発と、連携及び生体認証技術側に必要なプログラム（プロトタイプ）の開発に取り組んだ。
なお、これらの必要な仕様及び機能の検討とプロトタイプ・プロクラムの開発には、平成 28 年度も継続して取り組み、プロトタイプを完成させ、開発したシステム・プロトタイプの機能を自治体関係者の協力を得て検証する予定である。

6

表 3.3-1 研究開発実施日程
期・月別
研究開発項目（段階）

上
半
期
下
半
期
４ ５ ６ ７ ８ ９ 10 11 12 １ ２ ３①生体認証を用いた被災者支援システムの研究開発（１）利用シーンの精査と必要な仕様及び機能について検討（調査）・被災者支援の利用シーン精査
・被災者支援システムと生体認証機能の連携のために被災者支援システム側に必要とされる仕様と機能の調査
・被災者支援システムと生体認証機能の連携に必要とされる仕様と機能の調査
・被災者支援システムと生体認証機能の連携のために生体認証機能側に必要とされる仕様と機能の調査（２）被災者支援システムのプロトタイプ・プログラムの開発（プログラム開発）
・被災者支援システム側の必要機能
提供部の開発（第１ステップ）
・被災者支援システムと生体認証機能と連携機能の提供部の開発（第１ステップ）
・生体認証機能側の機能提供部の開発（第１ステップ）（３）報告書の作成

74．研究開発の内容
被災者支援において中心的役割を果たす自治体が行う被災者支援業務に、生体認証による本人確認を応用するための調査・検討、開発及び検証を 3 ヵ年の期間で行うこととし、平成 26 年度から下記に取り組んできた。

(1) 平成 26 年度
過去に起きた災害での被災者支援状況を、文献及び有識者からのヒアリングにより収集し、集められた調査結果から、生体認証技術を被災者支援に応用する利点のある利用シーンを検討した。
また、その利用シーンを実現するための被災者支援システムと生体認証の連携方式について基礎
検討し、基本的なプログラム仕様を開発した。
①利用シーンの精査と必要な仕様及び機能について検討
現在自治体などで考えられている避難所運営における避難者の本人確認方法や、東日本大震
災や阪神淡路大震災など過去の大規模災害における避難所での避難者の本人確認について、文
献調査、諸活動調査、インターネット調査などを実施することにより明らかにするとともに、避難所において被災者支援のために生体認証を適用する際の利用シーンについて検討した。
②被災者支援システムのプロトタイプ・プログラムの開発
上記①の利用シーンにもとづいて、西宮市情報センターが運用している被災者支援システムに生体認証を組み込むことを想定したプログラム仕様を作成した。

(2) 平成 27 年度
平成 26 年度の成果をもとにして、被災者支援システムの運営・管理元の関係者や自治体関係者をまじえて、生体認証技術を被災者支援に応用する利点のある利用シーンを検討した。その結果、自治体等が被災者支援システムを用いて実施する被災者支援業務の中の一つである避難所での避難行動要支援者（要援護者）に対する支援活動時の本人確認に生体認証を応用することが利用シーンとして適切であろうとの結論を得ることができた。次にこの利用シーンに対応するために、被災者支援システムと生体認証の連携方式と生体認証機能に必要とされる仕様について検討した。
これらの検討成果をもとにして、自治体が実施する被災者支援業務の中に生体認証を応用するためのプロトタイプ・システムの開発に取り組んだ。なお、開発にあたっては、被災者支援シス
テム全国サポートセンター（西宮市情報センター内）が開発・管理している被災者支援システム
を生体認証との連携対象とした。

以下、平成 27 年度に実施した内容について述べる。

8

4.1 検討委員会
研究開発実施にあたって、調査内容や検討内容を報告し、実施内容の検討をいただくため、産官学の有識者により構成した検討委員会（生体認証を用いた被災者支援システムの研究開発委員会）を組織した。生体認証を用いた被災者支援システムの研究開発検討委員会は、有識者（2 団
体 2 名）
・自治体（2 自治体 3 名）・生体認証機器ベンダー（5 社 6 名）・応用システムベンダー（4社 6 名）
・官公庁（2 名）及び事務局（2 名））からなり、研究開発の実施検討方針、検討内容や方向性について、専門的、具体的な検討を行い、研究開発にフィードバックした。検討委員会の活動内容は下記である。

(1) 第 1 回検討委員会 平成 27 年 7 月 16 日(木)15:00～17:00

1) 本年度の計画概要説明
生体認証を用いた被災者支援システムの研究開発の概要の説明と、研究開発実施日程について説明した。研究開発の進め方として、次の事項が確認された。
①検討にあたっては、ひとつのメーカーに左右されないよう調査委託をされたベンダーの製品だけでなく、それ以外のベンダーも含めたヒアリングや調査をしていく。また、委託調査の中で作業部会を開催して実施することが考えられること。
②被災者支援システムの次のバージョンでオプション機能として生体認証と連携できる旨を謳いたいとの希望が表明された。
③被災者支援システムと生体認証が連携するための自治体が管理している個人コード=マイナンバーという考え方もできるが、検討が必要である。
④自治体が管理している被災者台帳と避難行動要支援者の台帳がシステム的にオンラインで連携していない自治体もある。
避難行動要支援者は福祉を担当している部署が行い、被災者台帳は防災危機管理を行っている部署が行うため、そこをマイナンバーでつなげるように検討している自治体もある。
⑤システムのセキュリティを考慮すると、バイオメトリックデータとマイナンバーは分断させるようにシステムを組むことを原則として考える。
⑥クラウド認証についても検討に加える。
⑦被災者支援システム側と生体認証側のそれぞれの委託調査の中で作業部会を開催し、相互に連携しながら検討する。
2) 委託調査計画と見積り依頼について
委託調査計画の説明と見積り依頼の回答状況が報告された。

9

(2) 第 2 回検討委員会 平成 27 年 9 月 29 日(火)10:00～12:00

1) 委託調査見積り結果報告
見積り締切りまでの応募状況と委託先決定結果が報告された。
2) 委託調査（被災者支援システム側）検討状況報告
委託調査（被災者支援システム側）の検討状況が説明された。
被災者支援システムの運用サイドから見た利用シーンと希望する仕様について意見が交され、下記についての委員の理解が深まった。
①被災者支援システムの中での生体認証技術の活用は、避難所の職員が、一緒に逃げてきた人などに聞いても、どうしても誰だかわからない避難行動要支援者が誰であるかを判断するために使うことを考えていること。
②避難所における避難者の特定には、候補者を何人か持ってきて、時間がかかろうが本人を特定することが大事。間違える可能性を含む１人を提示してもらうより、判断に 10秒かかってもいいので、候補を何人か提示してもらい職員が最終判断することで良いこと。
③候補の中の誰かというのは達観で職員が判定する。今後はマイナンバーが入ってくるので、検索で出てきたマイナンバーから住民の顔や写真情報が自動的に出てくるようにできる可能性が高い。特に危機管理において、自治体は個人らい報を自在に使えるので、このように顔写真で判断するようにすることは実現できると考えていること。

また、意見交換の中で、連携及び生体認証側として次の課題があることが明確になった。
①複数人の候補を返すという機能は、現在生体認証の機能として使われている照合機能というより、検索機能になるため、実現策についての検討が必要であること。
あるベンダーの標準パッケージではこの機能はカバーしていない。また、あるベンダー
はパラメータの変更で可能であるなど、ベンダーごとに異なっているため、今後検討が必要であること。
②複数人の候補を返すという機能は、個人情報の提供にあたるとの懸念もあり、その検討が必要であること。
③複数人の候補を返す機能の実現の際に、意見交換の中で一例として出てきたブロック分
けして実現する場合、ブロックの中で類似度が 1 位でないところに実際の人がいた際に、その方が排除されないようすることを考える必要があること。
④被災者支援システムの要求仕様の実現を考えた時、SDK を用いて実現する機能も含めて考えていかないといけないと考えている委員もいる。そのため、複数ベンダー向けの標
準インターフェースとして、複数の生体認証装置やベンダーが接続できる仕様を実現する際に、ベンダーによって接続する装置の捉え方が異なるため、生体認証を用いた被災者支援システムで、被災者支援システムと生体認証を連携させる際に必要などこの何を10標準にするかについて検討する必要があること。
3) 委託調査（連携及び生体認証側）検討状況報告
委託調査（連携及び生体認証側）の状況について説明された。
委員長より検討と議論を進める上で、現状の制約の中で現状あるものをどう使って実現しようかという議論ではなく、被災者支援のときに何が必要かを理解して、実際に現場で使えるものを作るためにはどうあるべきかという視点で検討を進めなくてはいけないとの指摘があった。これを踏まえ、本プロジェクトの目的としていることと被災者支援システムの現場希望事項を踏まえて、検討している対象を次のように分けて今後検討と意見交換を進める
ことが提案され、それを踏まえて次を意識しながら今後の調査を進めていくこととなった。
①本来あるべき姿②プロトタイプとして実現する姿(3) 第 3 回検討委員会 平成 27 年 12 月 15 日(火)13:00～15:00

1) 委託調査（被災者支援システム側）検討状況報告
委託調査（被災者支援システム側）の検討状況が説明された。
議論の中で、生体情報等の登録は、日々の作業として実施する避難行動要支援者台帳の管理業務のなかで実施することになることが明確になった。
また、引き続き以下を検討していくこととなった。
①生体認証側に登録する時に使用する識別番号の選択について
マイナンバーで持つならば高い確率で使えるが、自治体によって使えるかどうかの判断があるので、確定できない。また、福祉番号などは自治体により持っていないところもあるため、どのような対応をするかを含めて検討すること。
②避難所職員による達観時の顔写真を使用する実現方法
参考データとして顔写真を見ることができたら本当にやりやすいとの自治体側意見がある。マイナンバーカードの顔写真も使える形で持っていくと良いが、個人情報保護条
例の問題を含め、マイナンバーカード情報の目的外利用になるため、自治体担当部署の裁量で使える可能性は高いとは思うが、使えるかどうかは各自治体の判断事項であり確定できないため、別の方法があると良い。その場合、顔写真の登録は、生体情報の登録と同様に、日々の作業として実施する避難行動要支援者台帳の管理業務の中で実施することになる。その実現方法を含めて検討してもらいたいこと。
③登録時のシナリオの整備
今までの整理は、生体情報による避難行動要支援者の避難所での検索時のものであり、登録時は別途整理する必要があることが明確になった。
生体情報等の登録は、日々の作業として福祉部門等が実施する避難行動要支援者台帳の管理業務のなかで実施することになるが、この業務は、自治体によってシステム化され11ているところや紙台帳しかないところもある。
いずれにせよ、自宅に訪問して収集しないといけないため、PC 等のモバイル端末を１台スタンドアローンで持ち出して、登録する人の識別番号を持って生体情報を取得することが想定される。したがって、登録業務は全く独立した PC 等のモバイル端末の中で動く生体情報を収集できるアプリケーションだけのものになる可能性が高いと自治体の中は考えている。
そのため、独立機能あるいは避難行動要支援者台帳登録の際に機能リンクをする形になるかなど、その実現法を含めて検討する必要がある。

また、以下の意見交換と情報提供がされた。
①被災者支援システムで使用される被災者台帳は、災害発生時に新規に作成され、その中には市民全員と災害時にその自治体にいた観光客なども含まれる。
②被災者支援システムで使用される避難行動要支援者台帳は、災害発生時に、福祉課等の担当部門が日々管理している避難行動要支援者台帳からコピーして作成され、内容は災害発生時のものに固定される。これは支援業務の公平性を担保するためである。
登録は、福祉課等の担当部門が日々の管理されている避難行動要支援者台帳の情報とリンクする形で生体情報を登録することになる。
③災害発生時に使用される被災者支援システムで検索できる避難行動要支援者は事前に登録されていることが前提となる。
④被災者支援システムは様々な問題も含めて、日々管理している台帳から、災害発生時に被災者支援システムで管理する台帳に取り込めるので、データを登録しておく場所は、
日々の管理されている避難行動要支援者台帳でよく、避難行動要支援者となんらかの番
号で紐づけして検索できることでよい。
⑤あるべき姿を考えると、被災者登録されていなかった時に、避難所で避難者登録するときに生体情報も登録し、そのあとの物品管理などに利用することまで考えるほうが良いが、この研究開発ではそこまではやらないことで良い。
⑥セキュリティ評価基準の安全性の確保として、企業の宣言だけでよいのか、調達側、第三者が評価するのか。法的なことについても検討する必要があるのではないか。
2) 委託調査(連携及び生体認証側)検討状況報告
委託調査実施より、委託調査（連携及び生体認証側）の検討状況が説明された。
質疑の結果、避難所での避難行動要支援者に対して、自治体職員が使用する機能は被災者支援システムの避難所関連システムの中での検索であり、また、生体情報等の登録は、日々の作業として実施する避難行動要支援者台帳の管理業務のなかで実施することが明確になった。これを前提として、操作シナリオを見直し、また、説明いただいた資料全般を修正することとなった。また、操作性全般を自治体の担当者が使う立場に立ってシンプルにすることとなった。
12また、以下を検討していくこととなった。
①登録シーケンスや検索シーケンスでポップアップされる生体認証か関わる操作を促す
画面等を表示する機能の実現方法や分担などが明確になるよう説明図等を改善する。
クライアント端末上に生体確認用のアプリケーションとしてベンダーのドライバープ
ログラムをインストールする必要がある。また、被災者支援システムとユーザーの間にクライアント API の層があるのではないかという意見をベンダーWG の中でいただいているので、検討の際に考慮する。
②顔写真などの登録と検索時の扱いと提示の実現方法③生体情報に関する登録や削除の実現方法
これらの機能は連携機能側の中に持たざるを得ない可能性が大である。アプリケーショ
ンの方から呼び出せるようにボタン機能は共通のインターフェースとしてある程度用意する必要がある。
④登録が NG だった時の識別番号や連携 ID、生体情報の扱い⑤検索（1：n 検索）後に再度、本人確認（1：1 認証）をする必要があるか、次のことを踏まえて、実務にかなうよう検討を進める。
・検索（１:ｎ検索）の時は閾値を下げ、本人確認（1：1 認証）の時は上げたほうが良いのか。
・検索（１:ｎ検索）の後の確認には、本人確認（1：1 認証）ではなく、もう一度、検索（１:ｎ検索）による確認をするべきではないか。
・検索（１:ｎ検索）では、訪問時に持ち込むモバイル端末上にデータをすべて持つ必要があるため、訪問での登録時のセキュリティの問題がある。
3) プロトタイプ・プログラム開発委託と見積り依頼について
事務局より、プロトタイプ・プログラム開発計画の説明があり、開発委託と見積り依頼について説明がされた。
4) 生体認証側成果物の情報公開を行う考え方について事務局より、成果物の情報公開についての提案があり、成果物の情報公開については、提案の通り進めるということが確認された。
以下の意見があり、今後の研究開発の中で検討することとなった。
・今回の成果を活用するには、プレゼンで実際にできるということを示すことが必要。
そのために生体認証の装置がつき実動作で動かせるものを提供してほしい。
→

プロトタイプでデモを実施するときは、生体認証用のデータとしてダミーを使用するなどして提供することを検討することとなった。

13

(4) 第 4 回検討委員会 平成 28 年 3 月 4 日(金)15:00～17:00

1）作業委託（プログラム開発）選定結果報告
作業委託（プログラム開発）選定結果の報告がされた。
2）調査及びプログラム開発(連携及び生体認証側)報告
委託調査(連携及び生体認証側)とプログラム開発(連携及び生体認証側)について報告がされた。
質疑応答の結果、プログラム開発の際に以下を検討することとなった。なお、これらの検討内容は、来年度も継続して検討する課題として取り扱うこととなった。
(a)避難行動要支援者（要援護者）の日々管理業務で使う識別 ID と発災時に被災者支援シス
テムで使用する避難行動要支援者の識別 ID が共通するものかという点について議論し、自治体で持っている団体内統合宛名番号を使うという方向で考えを進めることになった。
その結果、連携 ID に関しては、連携機能を使って自治体で持っているユニークな番号をもとに連携 ID をマッピングするという考え方で登録と検索が統一的に実現できるので、
ID は同じインターフェースで渡すという考え方で検討を進め、インターフェースを整理することとなった。
(b)クライアント端末上で生体情報をテンプレート化した後、被災者支援システムを経由して連携機能（サーバ）に送る処理は、被災者支援システム側の処理が重くなるので、ク
ライアント端末上から直接連携機能（サーバ）にテンプレート化した情報を送る方式についても検討することとなった。
また、生体認証機能部で処理後の検索結果の避難行動要支援者 ID を連携機能（サーバ）から直接クライアント端末上に返し、クライアント端末上から WEB ブラウザ経由で被災者支援システムに検索結果の避難行動要支援者 ID を返す方式についても検討を進め、インターフェースを整理することとなった。
3）調査及びプログラム開発(被災者支援システム側)報告
委託調査（被災者支援システム側）とプログラム開発(被災者支援システム側)について報告がされた。
質疑応答の結果、以下となった。
(a)生体認証による確認検索というところが、独立して運用されるのであれば、被災者支援
システム側とはデータ連携はするが深くかかわったシステム連携をする必要はないので、生体認証は別システムとして存在し、被災者支援システムの中にその呼び出しメニューを置くことで、被災者支援システムの中で生体認証に関わる機能が動作しているイメー
ジを実現する。どこに呼び出しメニューを置くかは各自治体のシステムによるので、自治体の作りこみに任せる。
(b)顔画像の取り扱いについては来年度以降の検討課題とする。

14

また、来年度も継続して検討する課題は下記となった。
(a)今後は、検索結果の ID が、検索（１:ｎ検索）結果として帰ってくるデータをもとに表示できることを目指し、その実現方法について検討する。なお、登録も同じ考えで実現することを目指す。
(b)絞込み条件で年齢や性別等複数設定可能性をシステム的に摺合せする。

15

4.2

利用シーンの精査と必要な仕様及び機能

生体認証を用いた被災者支援システムのプロトタイプ・システムの開発に向け、利用シーンの精査と必要な仕様の検討に取り組んだ。
利用シーンの精査と必要な仕様及び機能についての検討は、「被災者支援システム」あるいは「被災者支援システムと連携する部分及び生体認証」という異なる分野に対する知見が必要なため、「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」（以下、被災者支援
システム側調査という）及び「生体認証を用いた被災者支援システム構築のための調査（被災者支援システムとの連携及び生体認証側）」（以下、連携及び生体認証側調査という）の 2 つの調査に分け、それぞれが連携しながら、それぞれの立場から、避難行動要支援者に対する生体認証技術を用いた本
人確認が必要な利用シーンの精査とその利用シーン実現のために必要な生体認証技術を応用する被災者支援システムの仕様及び機能の検討に取り組み、それらをもとにして、避難行動要支援者に対する生体認証技術を用いた本人確認が必要な利用シーンの精査と生体認証技術を応用する被災者支援システムの仕様及び機能をまとめた。
4.2.1 被災者支援システム側から見た利用シーンと必要な仕様及び機能
被災者支援システム側から見た利用シーンと必要な仕様及び機能の検討を行った。
「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」として、生体認証を用いた被災者支援システムのプロトタイプ・システムの開発に向け、被災者支援シス
テム全国サポートセンター（センター長 吉田 稔氏）のご協力をいただき、関係者で WG（ワーキンググループ）を作り、次の事項の調査検討を行った。
①被災者支援システムのバージョン調査②被災者支援システム側の避難行動要支援者に対する生体認証の利用シーンの精査③利用シーンを実現するために必要な被災者支援システム側の仕様及び機能（適用方法の具体的調査検討）④被災者支援システム側から見たプロトタイプ・システムへの要求仕様の調査検討(1) 被災者支援システムのバージョン調査
被災者支援システムについて、被災者支援システムの運用管理を行っている被災者支援シス
テム全国サポートセンターの担当者と情報交換し、連携に適する被災者支援システムのバージョンとして何をターゲットとすべきかについて調査した。
その結果、連携に適する被災者支援システムのバージョンとして V7.0 のご推薦を受けたので、それと生体認証の連携を想定し検討を進めることとした。

16

(2) 避難行動要支援者に対する生体認証の利用シーンの精査
被災者支援システムの避難行動要支援者に対する支援業務の中で、本人確認という目的で生体認証技術を利用するために適切なシナリオ、操作方法、操作画面等について検討した。
被災者支援で避難者支援のため被災者支援システムが最初に活用される場面は、避難所における避難者の登録（避難者名簿作成、本人確認）作業の時である。
この時、図 4.2-1 あるいは図 4.2-2 に示すように、一般の健常者や意識がはっきりしている
避難者であれば、自己申告や身分証明書（将来的にはマイナンバーカードも考えられる）等の提示などを行い、避難所運営管理者（通常は自治体職員）の中で避難者受付業務を担う方との間でコミュニケーションをとることにより、避難者として特定の個人を登録することができる。
しかしながら、避難者が意識不明の場合や避難行動要支援者などで意思表示ができない方（自称できない人）の場合は避難者受付業務担当者による本人確認ができないため、氏名不詳のま
ま匿名の避難者として登録されているのが現状である。この場合、避難者本人の特定は後手にまわるため、どうしても当該避難者に必要とされる支援が疎かになる恐れがある。
また、被災者支援システム全国サポートセンターの担当者との情報交換の中で、避難所の中には、ボランティアの方が立ちあげ、自治体の災害支援システムとつながっていない避難所（図4.2-1）と、自治体が運営管理し、自治体の災害支援システムとネットワークでつながっている避難所（図 4.2-2)があることが分かった。ネットワーク環境のない避難所での避難者確認
は、避難者受付時に手作業で一時的情報としてモバイル端末を利用してエクセル表などに入力されたもの、あるいは紙に手書きされたものを、後程ネットワーク環境が整った際にバッチ処
理等で再確認するのが一般的とのことであった。担当者からは、本研究開発で検討している生体認証の活用が効果を上げるのは、ネットワーク環境のある避難所で、意思表示ができない避難行動要支援者が避難してきた時であろうとのご意見をいただくことができた。
そのため、図 4.2-2 に示されるネットワーク環境の整った避難所での避難行動要支援者支援
業務の中の本人確認という目的で生体認証技術を利用することを想定し、避難所に意思表示ができない避難行動要支援者が避難してきたときに実施する本人確認に適用することが最適との結論を得た。
この場合、避難所において自称できない避難行動要支援者を対象とするため、生体情報の事
前登録が必要である。自治体関係者からは、自治体では、日々管理業務として避難行動要支援者名簿の作成が義務づけられており、避難行動要支援者名簿を作成する際に本人同意を得て生体情報も取得し登録することができるとのご意見をいただいている。

17

図 4.2-1 ネットワーク環境のない避難所での避難者名簿作成業務への活用

図 4.2-2 ネットワーク環境のある避難所での避難者名簿作成業務への活用

18

(3) 利用シーンを実現するために必要な被災者支援システム側の仕様及び機能
前述の(2)の検討結果にもとづき、被災者支援システム側で生体認証を活用するために必要な機能を検討し、必要機能をまとめた。現時点では下記の機能が必要と考えるが、今後の調査等により追加もあり得るものと考えている。
①生体情報の事前登録に関わる機能②避難所における利用シナリオ、操作方法、操作画面等の実現のための機能(a) 生体情報の事前登録に関わる機能
被災者支援システムは発災時に起動・構築されるため、被災者支援システムで参照する生体情報は、自治体の日々管理業務として福祉部門等で実施されている避難行動要支援者台帳の整備業務の一環として事前登録しておく必要がある。
この避難行動要支援者台帳の整備業務は、本研究開発で活用対象としている被災者支援シ
ステムを運営管理している部門と異なる部門が実施しており、自治体によってシステム化して整備しているところや、紙台帳で整備しているところがあり、本研究開発では、システム化しているところが対象となる。
避難行動要支援者台帳を管理しているシステムは日々管理業務でシステムが運用されているため、生体情報の登録や削除機能をシステムに取り込む際のシステムの改修に対する影響を最小とする必要がある。そのため、避難行動要支援者台帳を管理しているシステムから、
単に別システムで用意される登録や削除機能を呼び出すのみとし、呼び出された後は避難行
動要支援者台帳を管理しているシステムの外の機能として実現することが必要と考えた。
また、生体情報等の登録は、避難行動要支援者に役所に来ていただいて登録するだけでな
く、自治体職員が避難行動要支援者の自宅に訪問して収集することも考えられるため、PCを 1 台スタンドアローン等でモバイル端末として持ち出して、事前登録する避難行動要支援者を一意に特定するためのキーとなる識別用「ID」と共に生体情報を取得することも想定される。したがって、登録業務は独立した PC 等のモバイル端末の中で動き、生体情報を収集するアプリケーションだけのものになる可能性も考慮する必要がある。
さらに、生体情報を事前登録した避難行動要支援者を特定する「ID」を登録に使用したモ
バイル端末と避難行動要支援者台帳を管理しているシステムとの間で受け渡しを行う機能も必要である。
以上を踏まえたうえで、日々管理業務で使用されている避難行動要支援者台帳を管理しているシステムに次を実現する機能の付加が必要と考えている。
①登録機能の呼び出し機能②避難行動要支援者を一意に特定するための「ID」の受け渡し機能③登録情報の削除機能
そのため、独立機能あるいは避難行動要支援者台帳登録の際に生体認証側で用意する登録あるいは削除機能をリンクして呼び出す機能を提供するなど、その実現法を含めた検討が必19

要である。

(b) 避難所における利用シナリオ、操作方法、操作画面等の実現のための機能
避難者登録処理は、避難所に避難してきた方全員が対象であり、避難所の避難者受付業務担当者が、避難者受付業務を担い、避難者登録処理時の作業フローは図 4.2-3 に示すものである。

[自称できる避難行動要支援者]
一般・健常者、あるいは自称できる避難行動要支援者の方は、一般・健常者と同様に、避難者受付業務担当者との間でコミュニケーションをとることにより、避難者の同定ができ、受付業務を行っている方が避難者の避難行動要支援者台帳への登録の有無を確認する。登録がなければ、通常の避難者と同様に避難者登録を行い、避難行動要支援者台帳に登録されていれば、避難行動要支援者として避難者登録する。
また、この時に避難行動要支援者台帳に事前の生体情報の登録がない場合は、登録により、以降の避難所での避難行動要支援者に対する支援業務実施時、例えば薬の処方等の時、の本
人確認などに生体認証を活用する環境が整うため、生体情報の登録について同意が得られる方の登録をこの時に行うことも考えている。ただし、今回のプロトタイプでは、避難所での避難者登録時の確認までを対象としたため、この避難時の生体情報の登録については、フローに示すのみとし、機能の開発等は行っていない。

[自称できない避難行動要支援者]
避難所に避難してきた方が自称できない場合は、本人特定のための「ID」もなく、氏名・住所・年齢・生年月日もない状況なので、避難者受付業務担当者が避難者の同定をすることができないため、避難者の生体情報により本人の識別をすることとなる。
具体的には、自治体の日々管理業務で事前に登録してある避難行動要支援者の生体情報をもとに、避難者から取得する生体情報を用いて、生体認証の識別（1：n 照合）機能を活用
し検索を行い、避難者の特定を図る。この時、候補が一人まで絞り込まれた場合は、個人を特定し、以降の避難者登録等を行う。もし、複数の候補者が出てきた場合は、複数の候補の内、どの方らしいかは、避難者受付業務担当者（一般に自治体職員）が達観により同定し、その方であるかを生体認証の本人確認（1：1 認証）機能で本人確認を行い、本人である確認が得られたら、以降の避難者登録等を行う。もし本人確認が取れなかった場合、あるいは候補がなかった場合は、避難行動要支援者台帳に生体情報が事前登録されていない方として取り扱う。つまり、従来の自称できない避難行動要支援者が避難所に避難してきた時と同様に取り扱い、以降の避難者登録と避難行動要支援者対応を行う。
また、この時に生体情報の登録について同意が得られる方の登録を行う処理を行うことも考えられる。ただし、これも自称できる避難行動要支援者のフローと同様、フローに示すの20

みとし、機能の開発等は行っていない。

図 4.2-3 避難所での避難者登録業務内容

以上をまとめ、被災者支援システム側では次を実現することが必要と考えている。
①生体認証を用いた検索（１:ｎ検索）機能の呼び出し②本人候補者の提示③生体認証の本人確認（1：1 認証）機能の呼び出し④本人確認（1：1 認証）結果表示⑤避難所での即時登録のための機能の呼び出し(今回の今回のプロトタイプでは開発・検討対象としない)(4) 被災者支援システム側から見たプロトタイプ・システムへの要求仕様
プロトタイプでは、上述した日々管理業務で実施する事前登録/削除を行うための機能と、被災者支援システムに生体認証と連携するための機能を用意することが必要である。
また、自治体で運用するためには、自治体のセキュリティポリシーにあった通信環境等の構築も必要であるが、プロトタイプでは庁内の閉じた環境（ローカルネットワーク）での運用を前提とする。
それらを下記にまとめる。

[事前登録のための機能]
日々管理業務システムを改修するわけにはいかないので、ダミー機能として、下記を用意することが必要である。
21

①登録機能の呼び出し機能②避難行動要支援者を一意に特定するための「ID」の受け渡し機能③登録情報の削除機能[被災者支援システム側で用意する機能]
被災者支援システムのオプション機能として用意するため、疎結合で実現する。
一例として、ボタンを要有為するなどが考えられる。
①生体認証を用いた検索（１:ｎ検索）機能の呼び出し②本人候補者の提示③生体認証の本人確認（1：1 認証）機能の呼び出し④本人確認（1：1 認証）結果表示機能［通信環境等の構築条件］
実際に自治体の運用に供する場合は、下記の点のサポートが必要である。
①VPN(Virtual Private Network 仮想プライベートネットワーク)含む専用線での運用や非常時にはインターネット回線への接続、ローカルでの生体認証登録などさま
ざまな自治体の環境に合わせて行うこと②自治体のセキュリティポリシーに応じたセキュリティを構築すること

また、プロトタイプで配慮すべきセキュリティ面の配慮事項は下記とした。
①絶対に漏洩してはいけない範囲を明確にする。
②情報漏えいしたときの影響を最小限に抑えるため、サービス ID（住基番号、福祉
番号といった個人を特定できる番号）を連携機能サーバにおいて関連性のない連携
用 ID に置き換える。
生体認証機能を実現するサーバにはサービス ID を保持しない。
③暗号のアルゴリズムは CRYPTREC によって認証されているものを使用する。
（電子政府における調達のために推奨すべき暗号リスト（CRYPTREC 暗号リスト））

22

4.2.2

生体認証側から見た利用シーンと必要な仕様及び機能

生体認証側から被災者支援システムの利用シーンを想定した生体認証機能及び連携機能のあるべき姿（仕様）やその実現のために生体認証側に必要な仕様及び機能の検討を行った。
「生体認証を用いた被災者支援システム構築のための調査（連携及び生体認証側）」として、生体認証を用いた被災者支援システムのプロトタイプ・システムの開発に向け、生体認証ベンダー
及び SIer 各社のご協力を得て関係者で WG（ワーキンググループ）を作り、次の事項の検討について検討を行い、その後「被災者支援システム」側及び委員会でレビューを経て、検討内容を深めた。
①生体認証機能が被災者支援システムと連携するための基本構成②利用シーンを想定した、生体認証機能及び連携機能のあるべき姿（仕様）③生体認証機能及び連携機能のプロトタイプ・システム仕様(1) 生体認証が被災者支援システムと連携するための基本構成
最初に被災者支援システムと生体認証の連携のための基本構成について検討した。
被災者支援システムと生体認証の連携にあたっては、被災者支援システム側は、次の要望を持っている。
ⅰ）被災者支援システムを管理している西宮情報センターは、プロジェクト完了後、生体認証を使った被災者支援システム(プロトタイプ・システム)のデモを何年間か継続して行いたい。
ⅱ）実際の導入時に自治体がどのベンダーの生体認証を採用するとしても、被災者支援シ
ステム側で生体認証機能を実装する際に追加するインターフェースは１種類としたい。
ⅲ）各自治体で被災者支援システムに生体認証を導入する際は、本研究開発で開発する
被災者支援システム側で生体認証を実装するために用意するインターフェースを利用して提供することを前提とする。

つまり、特定のベンダー製品で機能が実現できるということではなく、オープンな環境で生体認証技術と被災者支援システムの連携が実現できることを大前提としている。
生体認証を実現する生体認証機能は、現在のところ各ベンターが固有の機能で用意するので、その詳細は各ベンターに依存し、またインターフェース等の各社固有の仕様もある。
そのため、図 4.2-4 に示すように各ベンダーの生体認証機能の違い、インターフェースの違いを吸収するための機能を持つ部分を被災者支援システムと生体認証機能の間に設けることとした。ここでは、その機能を連携機能と名付けた。この連携機能の部分で各社の特有なインターフェースを吸収し、被災者支援シス連携機能との間で単一の対応インターフェースを用意

23

することで、被災者支援システム側の要望を満足しつつ生体認証機能部との連携を行うことが可能となる。
この連携機能と生体認証機能部を合わせて「生体認証管理システム(仮称)」と呼ぶことにす
る。

現地ユーザ
（被災者確認）(生体認証サーバ/サービス)
認証連携用GW/
指静脈認証システム

・各社標準ｸﾗｲｱﾝﾄP.P
又はBioAPIFrame共有

生体認証
要求/応答

本人確認
要求/認証結果

認証要求/応答

被災者支援システム・Linux等OpenSourceプラットフォームを想定
・生体認証連携部分に各社の接続ＡPIを実装する事で使用する生体認証を選択できるようにすることを想定
生体認証と被災者支援システムとの連携機能〔連携機能〕

図 4.2-4 被災者支援システムと生体認証管理システムの連携構成

被災者支援システム側の関係者との情報交換により、「被災者支援システム」は災害発生時
毎に、住基システム等の関連システムからデータが被災者支援システム側にコピー等で用意され、災害単位に各種台帳が確立されること、また、生体認証管理システムへの生体情報の事前登録は、被災者支援システムとは関連なく、日々の業務の中で登録されることが判明した。
この情報と、前述の連携機能部を設けるとの方針にもとづき、検討の結果得られた被災者支援システムと生体認証管理システムのシステム構成を図 4.2-5 に示す。
ここで、被災者支援システム側あるいは自治体システム側と生体認証管理システムとの間には、被災者支援システムが必要とする 4.2.1(3)で述べた機能を呼び出すためのインターフェースを用意する。
また、被災者支援システムのオプション機能として生体認証管理システムとの連携を取り扱えるようするため、生体認証管理システムとの連携実現時も被災者支援システム本体への影響を最小限とすることが必要であり、生体認証管理システム側とは疎結合で実現することを基本方針とした。

24

・被災者支援システムは災害発生時に住基システムおよび関連システムから必要データをコピーして基本情報を確定させる。
・被災者支援システムとの連携における本人の生体情報登録・削除は日々業務において実施される。

図 4.2-5 被災者支援システムと生体認証管理システムとのシステム連携概略

以上をまとめ、次の機能を生体認証管理システム側で実現することとした。
①自治体システムと生体認証機能との間で各社の特有なインターフェースを吸収する連携機能②生体認証管理システムと被災者支援システムの間の疎結合連携③日々管理業務での生体情報の登録及び削除機能④被災者支援システムからの生体情報による検索機能への機能

以下、被災者。支援システム側の検討内容にもとづき、被災者支援システムとの連携に必要とされる、次の事項について検討した。
①生体認証を用いた検索（１:ｎ検索）機能（候補者の提示機能付き）②各社の特有なインターフェースを吸収する連携機能③連携する「被災者支援システム」サブシステムへの対応

25

(2) 利用シーンを想定した生体認証機能及び連携機能のあるべき姿（仕様）について利用シーンを想定した生体認証機能及び連携機能(生体認証管理システム)のあるべき姿（仕様）として、次について検討した。
(a) 検索機能
生体認証は、その組織・業務体制において本人を一意に特定する「ID」と本人の生体由来の「特徴量データ（以下「生体情報」という）の組み合わせによる、本人認証の仕組みとして利用され、発展してきた。
生体認証機能には、「ID」+「生体情報」による「1：1 照合」による認証機能と、対象者の「生体情報」から機能提供各社が最適と判断する認証閾値以上で最も照合度の高い値を持つ「生体情報」から「ID」を導く「１:ｎ照合」による識別機能の 2 つがある。
しかし、被災者支援システムとの連携において、災害時の利用シーンである避難所では、本人に紐づく「ID」もなく、氏名・住所・年齢・生年月日も判断できない状況で、生体情報による本人検索が威力を発揮することが期待とれ、被災者支援システム側から生体情報による候補
者検索の機能を求められている（図 4.2-6 参照）。
「被災者支援システムからの生体認証管理システムへの要望」（第 2 回 研究開発検討委員会 議事録より抜粋）
・どうしても誰だかわからない避難行動要支援者が誰であるかを判断するために使うことを考えている。
・候補者を何人も持ってきて、時間がかかろうが本人を特定することが大事。
・判断に 10 秒かかってもいいので、候補を何人か提示してもらって、職員が最終判断することで良い。
・候補の中の誰かというのは達観で判定できる。実際の職員が実施する。
・危機管理において、自治体は個人情報を自在に使える。
・複数人の候補を返すという機能は、個人情報の提供にあたる懸念もあり、その検討が必要である。
図 4.2-6 被災者支援システムからの生体認証管理システムへの要望

一般に情報システムにおいては、検索のキーとなる「生体情報」はもちろん「ID」に紐づく
本人の属性情報は個人情報として厳格に扱われる必要がある。そのため、ベンダーが提供している生体認証では、本人を認証することを目的に、ベンダーが設定した認証閾値（精度）以上の照合結果を持つ場合に認証 OK とのみ結果を返す仕様である事が多い。
従来の生体認証での識別（1：ｎ照合）は対象者母数（ｎ人）から本人（1 名）を識別し、本人以外を識別結果とした場合は誤識別とし、1：ｎ照合の速度早めることと誤識別を極力を小さくする（識別精度を上げる）ことを目指して製品エンハンスを重ねてきた経緯がある。
被災者支援システム側から要望されている検索機能は、従来の識別機能はそのままに識別精26

度を下げ、複数の候補者を検索結果として返すことになる。
こ機能の実装について、生体認証側 WG 及び委員会での全体レビューの中で、生体認証による検索の実現及び運用に対して、下記のような懸念事項があげられた。
①各ベンダー製品とも程度の差はあるが、機能エンハンスが必要。
②対象者の生体情報から、検索結果として複数の個人情報が表示される。
③複数の検索結果から対象者を特定するための手段を生体認証管理システムとしてどの様に具備するか？各ベンダー製品で統一的な方式が現時点で確立できていない。
④検索の結果、候補者がゼロの場合の運用について、生体認証側 WG だけでは判断できない。
⑤万が一検索結果から対象者を別人として判断された場合、生体認証管理システムでは対応ができない。

しかしながら災害時の現場において、より実効性の高いシステムの提供を第一義とし、上記懸念事項を踏まえた上で、以下の 3 点を前提に委員会参加の各生体認証ベンダーより、将来的に生体認証製品に生体情報による検索機能を具備する方向で合意が得られた。これにより、生体認証管理システムのあるべき姿の具現化に向かって一歩進めることができた。
[候補者検索機能実装の前提]①被災時の人命に関わるシステム機能であること②システム操作者が自治体の職員であること③複数候補者からの最終的な本人特定は自治体の職員が行うこと(b) 連携機能
連携機能は「被災者支援システム」と「生体認証機能」との仲介をすることを目的としている。
「連携機能」により以下の効果が期待される。
① 自治体により導入する生体認証技術を複数の種類から選択肢選択することが可能となる。
② 被災者支援システムは連携機能に向けたインターフェース機能を１パターン用意することで、導入される各社の生体認証技術を利用することができ、各社毎の導入・改修・維持運用の負担を軽減できる。
③ 被災者支援システム及び自治体関連システムからはアプリケーションレベルのイン
ターフェース（API）から生体認証機能〔検索（１:ｎ検索）、本人確認（1：1 認証）、登録、削除〕を、連携機能を通じて呼び出すことにより、簡便に利用することができる。又生体認証ベンダーはビジネス参入において生体認証製品の設計・カスタマイズ
作業を抑えることができる。

27

連携機能は前述の「被災者支援システム」側の期待の実現と各社の生体認証製品の変更をできるだけ少なくする観点から、機能実装に関する検討を進めた。
検討の結果、次の 3 点を基本構想として得た。
①「被災者システム」側からは「検索（１:ｎ検索）」、「本人確認（1：1 認証）」
、
「生体
情報登録」
、
「生体情報削除」の４機能を呼びだすことができるよう、統一したインターフェース（コマンド及び引数、リターン値）で連携する。
② 一方の生体認証機能側との連携は、各社の生体認証機能用の API に対し、コマンド変換をして各社の生体認証機能を呼び出し、実行する。
③ その際、本人を一意に特定する被災者支援システムの「識別番号」等を業務システ
ムの「サービス ID」として受取り、「連携用 ID」に ID 変換を行う。これは秘密分散によるリスク低減の一環として業務上、本人を識別する「サービス ID」及び本人の「属性情報」を生体認証機能部に直接保持しないことを目的とする。

以降の詳細設計は、プロトタイプの開発時に取り組むこととした。

(c) 連携する「被災者支援システム」サブシステムへの対応「被災者支援システム側」のどのシステムからも必要に応じて連携できる機能を疎結合で実現してほしいとの要望に対応するため、(b)で述べたように「検索（１:ｎ検索）
」
、
「本人確認
（1：1 認証）」、「生体情報登録」、「生体情報削除」の 4 機能を「ボタン」化して、被災者支援
システム側と生体認証管理システムとの間は疎結合で実現することを基本方針とした。
また、生体認証機能との連携実現時も災者支援システム本体への影響を最小限としてほしいとの要望に対応するため、被災者支援システムの改修や影響部分を最小限にするために、被災者支援システム側の関係者と協議し、連携する被災者支援システムのサブシステムを選定した。
選定したサブシステムは後述の 4.3.1(2)に示すものである。

(d) システム実装の検討条件「被災者支援システム」との機能連携に関する検討とあわせ、システム実装について検討を行った。
被災者支援システム側の検討では、4.2.2(1)で述べたように、生体認証を活用した被災者支援システムは自治体を主体として導入・運用を実施し、本研究開発で開発する被災者支援シス
テム側で生体認証機能を実装するために用意するインターフェースを利用して実現したいとの要望に対応するため、システム実装時の検討条件は、以下の要件を満たすことを念頭に置くこととした。
① 連携機能は導入後に維持・改修を自治体主体で行う可能性があるため、できるだけオー
プンソースシステム（OSS）で開発する② 連携機能の調査・検討の結果、実際に開発するプロトタイプ・システムに適用させる
28

ために、各社センサー製品に関する技術開示や製品の変更が必要となった場合、その対応は生体認証デバイスベンダー各社の責任と負担とするよう取り組む。
③ システム実装において、「連携機能」の実現においては「被災者支援システム」側の API
インターフェースを統一化することを前提に連携機能を各社の提供する生体認証管理システムに実装することも可能とする。

(3) 生体認証機能及び連携機能のプロトタイプ・システム仕様について
前述の検討結果を踏まえて、プロトタイプ・システムの仕様の検討を行った。
本研究開発は 3 つのフェーズ（①調査・検討フェーズ、②プロトタイプ・システムの開発フェーズ、③プロトタイプ・システムの検証フェーズ）を平成 28 年度までに実施する計画である。
これまでの調査結果から、実際に被災者支援システムと連携し、実業務で運用できるようにするためには、検索機能対応など、各生体認証ベンダーによる生体認証機能の機能エンハンスが必要であることが判った。
この機能エンハンスは本研究開発の成果を踏まえ、実際に自治体に生体認証と連携した被災者支援システムが導入される時に行われることとなる。そこで、本研究開発においては実業務で運用できる「あるべき生体認証管理システム」と現行仕様の各社の生体認証をベースとした「プロトタイプ・システム」とに分け、それぞれを念頭に検討を進めることとした。
また、連携機能についてもあるべき姿を目標と置きつつ、開発期限内での実現性を考慮し、検証を行うこと前提にプロトタイプ・システムを設計開発することとした。
その上で、連携機能及び生体認証機能(生体認証管理システム)のあるべき姿とプロトタイ
プ・システムとの関連を表 4.2-1 にまとめ、プロトタイプの開発仕様として関係者の合意を得た。
さらに、登録/削除機能についても検討した。
自治体側の関係者との協議で、多くの自治体において避難行動要支援者に対する日々管理業
務のシステムと被災者支援システムは別の部署で管轄・管理されているため、今回の検証実験のために日々管理業務のシステムに生体情報登録の機能を組み込むことは困難であるという見解をいただいたので、今回のプロトタイプでは、日々管理業務システム例を用意し、そこで生体情報登録の業務シーケンスを動作させることに留めることで取り組むこととした。また、必要な場合は、連携機能の中に、マスタメンテ機能として具備することも検討したいと考えている。

29

表 4.2-1 生体認証管理システム機能仕様検討対比表

30

4.3 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発
本節に先立つ調査活動で生体認証技術を応用する被災者支援システムの利用シーンの精査と必要な仕様の検討に取り組み、避難所に避難してきた避難行動要支援者などで意思表示ができない方（自称できない人）が誰であるかを特定することが避難所における生体認証の被災者支援システムへの適用ケースとして優れていることを見出し、その実現のために必要な仕様及び機能を整理した。
その結果をもとに、生体認証を組み込む被災者支援システムとして、西宮市情報センターが運用・管理している被災者支援システムを選択し、その被災者支援システムに生体認証を組み込むためのプ
ロトタイプ・プログラム設計と開発を進めた。
生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発には、「被災者支援システム」あるいは「被災者支援システムとの連携及び生体認証」という異なる分野に対する知見が必要なため、専門性を考慮し、「生体認証応用被災者支援システムのプロトタイプ・プログラム（被災者支援システム側）」と「生体認証応用被災者支援システムのプロトタイプ・プログラム（連携及び生体認証側）」の 2 つに開発作業を分け、それぞれが連携しながら、生体認証技術を応用する被災者支援システム実現のために被災者支援システム側に必要な追加プログラム（プロトタイプ）の開発と、連携及び生体認証技術側に必要なプログラム（プロトタイプ）の開発に取り組んだ。
本節では、その内容と今後の課題と取り組み方針を報告する。
4.3.1

被災者支援システム側のプロトタイプ・プログラムの開発

生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発にあたり、被災者支援システム側のプロトタイプ・プログラムの開発（被災者支援システム側）を実施した。
プロトタイプ・システムの被災者支援システム側のシステム構成や仕様の調査結果にもとづき、被災者支援システム側に追加する必要のある機能について、システム構成や機能仕様を検討した。
現時点では下記をまとめたが、継続検討により追加もあり得るものと考えている。
・生体認証を用いた被災者支援システムの機能仕様
・被災者支援システム側の改修仕様
・日々管理業務システムでの登録/削除機能の改修方針(1) 生体認証を用いた被災者支援システムの機能仕様
被災者支援システム全国サポートセンター（センター長 吉田 稔氏）のご協力をいただき、
また、「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」
WG での自治体関係者の意見をもとに、次のように仕様をまとめた。
(a) 検索に関わる仕様① 検索にかかる時間は最大 30 秒までと考える② 対象母数(N)は 100 件以上を想定する

31

③ 絞り込み条件では、性別・年齢層他複数設定可能とする④ 検索結果画面に、検索結果当該 ID（ｎ人）または該当無しの表示を行う。
順位表示に関しては検討していく⑤ 生体情報が重複していないか二重登録チェックを行う(b) 運用に関わる仕様① 通常運用はそれぞれの自治体にあわせ、専用線（VPN 含む）の使用も考える。
ただし、対象者訪問時に生体情報を登録する際は専用線というものは限りなく不可能に近いため、クライアントの機能とサーバとのやり取りだけでできるほうが安全である。その際の運用方法は再度議論する必要がある② 被災時運用は、状況に応じインターネット接続可とする③ 登録時の運用はリアルタイムで登録できるように、それぞれの自治体にあわせて専用線（VPN 含む）の使用も考える④ 自治体のセキュリティポリシーにあわせる(2) 被災者支援システム側の改修
避難所における生体認証を用いた避難行動要支援者の検索は、避難者受付業務担当者の作業を単純化することが肝要であるため、インターフェースとして次の二つ考えている。
(a)図 4.3-1 に示すように、被災者支援システムの総合メニューの中の避難所関連システ
ムのメニューの中に「生体認証 確認・検索」メニューを追加し、実行ボタンを押す
ことにより、直ちに検索を始める。
(b)図 4.3-3 に示すように、被災者支援システムのの総合メニューの中にオプション機能として「生体認証 確認・検索」機能を追加し、実行ボタンを押すことにより、直ちに検索を始める。

どちらを採用したほうが良いかについては、今後検討を継続する。

次に、検索時のインターフェースについて説明する。
①図 4.3-1 に示す被災者支援システムの総合メニューの中の避難所関連システムのプル
ダウンメニュー（図 4.3-2）の中の「生体認証 確認・検索」を選択し実行ボタンを押すこと、あるいは図 4.3-3 に示す「生体認証 確認・検索」機能の実行ボタンを押すことより図 4.3-4「生体認証検索」画面に移行する。
②図 4.3-4「生体認証検索」画面の左上部にある「生体認証検索」ボタンを押すことにより、(d)で作成する連携機能部へ必要データを送信するインターフェース（１：ｎ検索）により、生体認証管理システムによる検索機能が起動する。
③検索機能の実施により、生体認証管理システム側から、候補者の ID 情報が返されてく
るので、その ID 情報をもとに図 4.3-5 により候補者を表示する。
32

④候補者情報をもとにして、避難者受付業務担当者が達観により、避難者（避難行動要援護支援者）を同定する。
この際、生体認証による検索用の被災者台帳の参照画面（図 4.3-6）や、生体認証による検索用の避難行動用支援者台帳の参照画面（図 4.3-7）を参考にすることもできる。
これらは、図 4.3-5 に示す生体認証管理システムから必要データを受け取る画面（１：ｎ検索）の右側の欄にある「台帳」のボタンを押すことによって参照できる。
⑤避難者受付業務担当者が必要と判断した場合は、達観により選択した避難者（避難行動
要援護支援者）の欄にある「本人確認」ボタンを押し、生体認証による本人確認を行う
ことにより避難者を確認することもできる。
この時は、(h)で作成する生体認証管理システムへ必要データを送信するインター
フェース（１：１認証）により、生体認証による本人確認機能が起動し、図 4.3-8 に示す生体認証管理システムから必要データを受け取る画面により、結果を確認する。
⑥確認結果にもとづき、図 4.3-5 に示す生体認証管理システムから必要データを受け取る
画面避難者（避難行動要援護支援者）の右側の欄にある「避難者登録」ボタンを押すことで、検索画面から呼び出し用の避難者登録画面（図 4.3-9）により被災者台帳への登録を行う。

以上により避難者受付業務担当者による避難者（避難行動要援護支援者）の避難所での登録業務がなされる。

以上の検討を踏まえ、避難所関連システムの改修案として次を得た。

(a) 総合メニュー画面における「避難所関連システムメニュー」の改修
図 4.3-1 に示す被災者支援システムのメニューの中に図 4.3-2 に示す「本人確認(生体認証)」メニューを追加し、実行ボタンを押すことにより図 4.2-2 に示す「生体認証 確認・検索」画面に移行する。

33

図 4.3-1 被災者支援システム総合画面避難所関連システム画面追加イメージ

図 4.3-2 「避難所関連システムメニュー」の改修イメージ34

(b) 生体認証による検索用のメニューの新規作成
オプション機能としての追加を行うことも別案としてある。
これは、避難所関連システムメニューとは別途、オプションメニューの追加を行う案であり、オプションメニューを使用可とする権限の設定などについても今後検討が必要である。
図 4.3-3 は、被災者支援システムのオプション機能としての追加する画面である。

図 4.3-3 被災者支援システムのオプション機能としての追加する画面イメージ(c) 生体認証による検索用の画面の新規作成(a)案(b)案のいずれを採用するにしても、被災者支援システム側において生体認証による検索用のメニューの新規作成が必要である。ただし、当該メニューから「（生体認証システム側）
生体認証管理システム(仮称)」が起動することが必要となる。
図 4.3-4 は、生体認証による検索用の画面である。
新規作成あたっては、次を考慮することが必要である。
・オプション機能としての追加を行うこととするが、被災者支援システムバージョンアップに伴う差分処理対応同様の作業にてセットアップできるように考慮すること。
・生体認証管理システムとの連携により得られた情報を受け取り一覧表示すること。
・検索結果の一覧から「避難者の登録画面」に遷移する。その際に必要な情報を受け渡し
入力の省力化を図ること。
・生体認証による検索では、生体認証管理システムにて検索（１：ｎ検索）を行い閾値により絞り込まれた対象者のサービス ID（識別番号）を複数受け取りリスト表示する。
・本人確認では、サービス ID（識別番号）を生体認証管理システムに受け渡し、本人確認（1：1 認証）で本人に間違いないかの確認を行う。

図 4.3-4 生体認証による検索用の画面イメージ
35

(d) 生体認証管理システムへ必要データを送信するインターフェースの作成（１：ｎ検索）
生体認証機器（静脈、顔）の起動及び読み取った生体情報の送信を行うためのボタンの作成を行うためのものである。

(e) 生体認証管理システムから必要データを受け取るインターフェースの作成（１：ｎ検索）
被災者支援システムサーバにて、生体認証管理システムから受け取った ID（識別番号、住基番号等）を元に被災者台帳を検索し一覧表示を行うものである。その際、複数の ID を受信することを想定した処理を行うためのものである。
新規作成あたっては、次を考慮すること。
・生体認証による検索では、生体認証管理システムにて検索（１：ｎ認証）を行い閾値により絞り込まれた対象者のサービス ID（識別番号）を複数受け取りリスト表示すること。

図 4.3-5 生体認証管理システムから必要データを受け取る画面（１：ｎ検索）イメージ(f) 生体認証による検索用の被災者台帳の参照対応
ここでは、検索結果等を関連付けキー等により検索結果画面に表示する。すなわち、生体認
証管理システムにより得られた情報を受け取り図 4.3-6 のように一覧表示を行うこと。
新規作成あたっては、次を考慮すること。
・検索結果の一覧から「避難者の登録画面」に遷移する。その際に必要な情報を受け渡し
入力の省力化を図ること。
・検索結果の一覧から「被災者台帳 参照画面」に遷移する。生体認証による検索で得られた情報の詳細を被災者台帳にて確認し本人確認の正確性の向上を図ること。
・本人確認では、サービス ID（識別番号）を生体認証管理システムに受け渡しし、生体認証で本人確認（1：1 認証）し本人に間違いないかの確認を行うこと。
・生体認証 検索画面から呼び出し用の被災者台帳参照画面を作成すること。又、その際に他の画面への遷移やデータ更新が出来ないように制限をかけること。
・この画面から更新画面や住家台帳、義援金・支援金等の更新画面へ遷移するとデータ整合性の問題が発生するため、生体認証専用の画面を別途用意すること。

36

図 4.3-6 生体認証による検索用の被災者台帳の参照画面イメージ(g) 生体認証による検索用の避難行動用支援者台帳の参照対応
図 4.3-7 は、生体認証 検索画面から呼び出し用の避難行動要支援者台帳の参照画面である。
新規作成あたっては、次を考慮すること。
・その際、他の画面への遷移やデータ更新が出来ないように制限をかけること。
・この画面から地図画面や他の避難行動要支援者の台帳へ遷移すると問題が発生するため、生体認証専用の画面を別途用意すること。
・検索結果の一覧から「避難行動要支援者 参照画面」に遷移し、避難行動要支援者台帳にて対象者の要支援情報を確認し適切な対応（本人確認）を図ること。

37

図 4.3-7 生体認証による検索用の避難行動用支援者台帳の参照画面イメージ(h) 生体認証管理システムへ必要データを送信するインターフェースの作成（１：１認証）
生体認証機器（静脈、顔）の起動及び読み取った生体情報の送信を行うためのボタンの作成を行う。１：１認証では上記のほかに被災者支援システムサーバからも ID（識別番号、住基
番号等）を送信すること。

(i) 生体認証管理システムから必要データを受け取るインターフェースの作成（１：１認証）
被災者支援システムサーバにて、生体認証管理システムから受け取った OK、NG の情報を元にメッセージを表示する。本人の確認が出来た場合は、ボタンを「確認済み」と表示し一致した事が後からでも分かるようにすることが必要である。

図 4.3-8 生体認証管理システムから必要データを受け取る画面（１：１認証）イメージ(j) 生体認証による検索用の避難者登録対応
図 4.3-9 は、生体認証 検索画面から呼び出し用の避難者登録画面である。
新規作成あたっては、次を考慮すること。
・登録完了時に元の検索画面に戻り、他の画面への遷移を出来ないように制限すること。
また、呼び出し時に被災者台帳から必要な項目は受け渡すようにすること。
・生体認証による検索で取得した識別番号を元に、被災者台帳データを読み込み必要な項
38

目を初期表示すること。又、その際識別番号の変更等が出来ないように制限すること。

図 4.3-9 生体認証による検索画面から呼び出し用の避難者登録画面イメージ(3) 日々管理業務システムでの登録/削除機能の改修
プロトタイプ・システムで生体認証による避難者（避難行動要援護支援者）の確認を実施するために、生体認証管理システム側への避難行動要援護支援者の事前登録を行う必要がある。
しかしながら、生体情報の生体認証管理システムへの事前登録は、日々管理業務中で実施されるものであり、被災者支援システムにその機能を呼びたす画面等はなく、日々管理業務シス
テムの中に用意する必要がある。そのため、プロタイプ・システムによる検証試験を実施する
ために、ダミー画面を用意し、その中で登録/削除機能を用意することとした。
なお、詳細な内容や仕様は来年度の開発の中で検討し決定する予定である。

39

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

本年度は、下記に示す研究開発の前提条件を考慮しつつ、生体認証を用いた被災者支援システ
ムのプロトタイプ・システムの開発に向け、生体認証側の仕様検討を行った上で、検証実験用プ
ロトタイプ・システムの連携機能について仕様作成を実施した。
開発は、先に実施した「生体認証を用いた被災者支援システム構築のための調査（被災者支援システムとの連携及び生体認証側）」に引き続き、生体認証側で生体認証ベンダー及び SIer を中心にとした WG メンバーでシステム連携における仮説検証を実施し、平行して「被災者支援システム」側とのレビュー及び委員会でのレビューをへて仮説にフィードバックをした。
また、被災者システム側で検討した利用シーンをもとに、生体認証管理システムの生体認証機
能及び連携機能のあるべき姿（仕様）を追及したうえで、プロトタイプ・システムでの実現機能（仕様）を設計することとした。

［検討の前提条件］①プロトタイプ・システムのシステム構成は複数の生体認証技術が選択可能なこと②生体認証に関わる業界関係者にとって広く受け入れられる構成のこと③支援システム側調査者と密接な連携をとること④本委託調査の成果物を生体認証に関わる業界関係者が共有することを許容すること

以下その結果について報告する。

(1) 生体認証管理プロトタイプ・システムの実装検討(a) 日々管理業務システムと被災者支援システムとで、異なるサービス ID を運用する場合のID 連携について「生体認証機能部には個人を直接特定する機微な情報は持たせない」といった観点から、
生体認証機能部には、自治体側で要援護支援者をを一意に特定する業務上の ID(サービスID)を持たず、連携機能においてサービス ID と 1 対 1 対応した生体認証機能部でのみ使用

40

する間接的な ID（連携 ID）作り、それを生体認証機能部でユニークな ID として使用する仕様としている。
しかし、自治体側のシステム構成によっては、自治体の日々管理業務におけるサービス
ID（例：福祉番号）と被災者支援システムにおけるサービス ID（例：識別番号）が異なる可能性もあり、そのような場合は、日々管理業務システムによる登録時と被災者支援シ
ステムによる検索時のそれぞれのシステムで避難行動要支援者を示すために使用しているサービス ID が異なるため、被災者支援システムでの生体認証による検索時に正しく避難行動要支援者が特定できない恐れがある。
このように登録時と検索時のサービス ID が異なる場合、生体情報と一意に紐づくのは連携 ID のみであり、検索処理で導かれる「サービス ID」は「登録時のサービス ID」となるので、被災者支援システム側で個人の属性情報を導くために、一度「登録時のサービス
ID」から、被災者支援システム用の「検索時サービス ID」を導く処理を追加することが必要となる。
しかしながら、自治体関係者を含めて検討した結果、避難行動要支援者の支援のため
日々管理業務システムで使う識別 ID と発災時に被災者支援システムで使用する避難行動
要支援者の識別 ID が共通するものかという点について議論し、自治体で避難行動要支援者を識別する ID として、全国すべての基礎自治体が持っている ID に団体内統合宛名番号があり、それはマイナンバーと１対１になるので、マイナンバーを使わずにひとつの番号で自治体内は連携できるとの意見が出され、自治体で持っている団体内統合宛名番号を使うという方向で考えを進めることとした。
その前提を踏まえ、異なる体系のサービス ID による生体認証情報の登録について、以下の 2 点のどちらを採用すべきかについて、今後も継続検討をすることとした。

案１：「日々管理業務システム」から連携機能を経由して生体情報を登録
連携機能にマスタメンテイメージの生体情報登録/削除機能を具備することで、下記処理シーケンスを実現する。
連携機能は日々管理業務から入力された「サービス ID」に対し一意に対応する「連携 ID」を生成し、連携機能に「サービス ID」と「連携 ID」を格納。そして生体情報と「連携 ID」を生体認証機能部に渡す。

処理案シーケンス：①日々管理業務システム上のボタンから、連携機能を起動。
→②日々管理業務システムが、業務上のサービス ID を連携機能に提供。
→③連携機能が、連携機能の中でサービス ID と連携するユニークな ID（連携 ID）を生成・管理し、同時に本人を特定する生体情報を取得。
41

→④連携機能が、その連携 ID と生体情報とを生体認証機能部に提供。
→⑤生体認証機能部が登録。

案２：「日々管理業務システム」から直接生体認証機能を起動して生体情報を登録
連携機能にマスタメンテイメージの生体情報登録/削除機能を具備することで、下記処理シーケンスを実現する。
連携機能は日々管理業務から入力された「サービス ID」に対し一意に対応する「連携 ID」を生成し、連携機能に「サービス ID」と「連携 ID」を格納。そして生体情報と「連携 ID」を生体認証機能部に渡す。

処理案シーケンス：①日々管理業務システムから生体認証機能部の生体情報登録機能を起動する。業務上のサービス ID を生体認証機能に提供（手入力を想定。プログラムからの提供は個別開発を想定）。
→②生体認証機能部が、生体認証機能の中でサービス ID と連携するユ
ニークな ID（連携 ID）を生成・管理し、同時に本人を特定する生体情報を取得して登録する。
（生体認証機能に ID 連携の機能付加が必要）。
→③生体認証機能部からサービス ID と連携 ID を連携機能に登録。（生体認証機能と連携機能が別システム場合）(b) 連携機能部の構成
当初、連携機能部は被災者支援システムと生体認証機能部との中間に位置し、生体認証機能（①検索（１：ｎ認証）、②本人確認（1：1 認証）、③生体情報登録、③生体情報削除）を呼
び出し、結果を被災者支援システムに返すこととサービス ID と連携 ID を変換することを主な機能と想定していた。
開発に向けて検討を進めていくうちに生体認証側の検討メンバーより、被災者支援システム
側で生体認証管理システムに対応する機能を実装する際に追加するインターフェース仕様を
各生体認証ベンダー間で共有化するためには、被災者支援支援システムと各社が用意する生体認証機能部との間に連携に必要とされる連携機能部（サーバ側)を設けるだけではなく、現場で使用されるクライアント端末上にも、生体認証機能部との連携を実現するための連携機能部（クライアント側）が必要であるとの見解が示された。
一般的にセンターサーバー認証型の生体認証機能を提供するシステムでは、クライアント端
末上には、各生体認証ベンダーから製品として提供される生体認証センサーを駆動する「ドライバー」とユーザー操作及び生体認証サーバとの処理を仲介する「クライアントアプリ」が存在する。クライアントアプリにおいては BioAPI による標準的なインターフェースを具備する
42

ものがあるが、各種の生体認証を応用するシスシテムに最適化するために BioAPI の拡張機能部分に各社固有の機能を実現していることが多い。
そのため、今年の研究開発の結論としては、各社で連携機能部（サーバ側)と連携機能部（クライアント側）の 2 種類を用意し、被災者支援システム側に提供することで連携機能を実現することで対応する方針とした。
また、この連携機能部（サーバ側)と連携機能部（クライアント側）の被災者支援システムとのインターフェースを除く作りこみ内容は、各社が生体認証機能を提供するシステムにより異なり、その連携機能の実現方法も、①製品内に実装する、②SDK を利用する、③API を利用する等あるため、実際の被災者支援システムに連携機能部を提供する際にどのように提案、実現するかは、各社に委ねることとした。

(2) プロトタイプ・プログラムの開発
被災者システムの利用シーンを想定した、生体認証機能及び連携機能(生体認証管理システ
ム)のあるべき姿について調査・検討した結果を踏まえ、生体認証管理システムのプロトタイ
プ・プログラムの開発に着手した。
プロトタイプ・システムの連携機能プログラムは、前述の被災者支援システム側からの要望
である、「被災者支援システム側からの要望はどのベンダーの生体認証を採用するとしても、被災者支援システム側で生体認証を実装する際に追加するインターフェースは１種類としたい。
」を実現するために、被災者支援システムと生体認証管理システムとの間のインターフェースの実現とサービス ID と連携 ID との連携を実現する機能の実現を目的としている。
本年度は連携機能プログラム開発の内、プロトタイプ・システムの連携機能プログラムの詳細仕様として連携シーケンスと連携機能インターフェースの検討開発とサンプルプログラム
コードの開発を行った。以降のプログラム開発は本年度の検討開発内容をプロジェクト全体で評価・検証した上で、平成 28 年度研究開発時に段階的に詳細化していく予定である。

(a) 連携シーケンス
本研究開発の検討で明らかにした「被災者支援システム及び日々管理業務システムとの生体認証管理システムとのあるべき姿としての連携概略」（図 4.2-5）をもとに、被災者支援シス
テムと生体認証管理システムとの関係性を明確にするため、連携概略シーケンスを作成し、生体認証側及び被災者支援システム側と協力して検討を進めた。
また、4.3.2(1)(b)の状況も踏まえ、クライアント端末上の生体認証アプリにアドオンする
連携機能についても併せて検討することとし、連携シーケンスを設計した。
図 4.3-10 に被災者支援システムと生体認証管理システムの連携概略シーケンス（例：検索（１：ｎ認証））を示す。

43

図 4.3-10 被災者支援システムと生体認証管理システムとの連携概略〔例：検索（１：ｎ認証）〕

さらにプログラム仕様詳細設計を進めていく上で明らかになった機能シーケンスを補追した結果を別紙 1「生体認証応用被災者支援システムプロトタイププログラム連携機能シーケンス図」に記す。

なお、この連携シーケンスについては、生体認証側の検討メンバーより次の見解が示されている。
①クライアント端末上で生体情報をテンプレート化した後、被災者支援システムを経由して連携機能（サーバー）に送る処理についても、被災者支援システム側の処理が重くなるので、クライアント端末上から直接連携機能（サーバー）にテンプレート化した情報を送る方式のほうが良いのではないか。
②生体認証機能の検索結果である候補の避難行動要支援者を示す「連携 ID」を連携機能（サーバー）から直接クライアント端末上に返し、クライアント端末上から WEB ブラウ
ザ経由で被災者支援システムに検索結果の「連携 ID」を返す方式もあるのではないか。

これらの見解を受け、今後さらに検討を進め、インターフェースや連携機能部の詳細仕様を整理する予定である。

44

(b) 連携機能インターフェース
ここでは、被災者支援システムとの連例のためら連携機能が具備すべきインターフェース機能について述べる。
本研究開発の検討で、被災者支援システムから利用される生体認証管理システムの機能は①
検索（１：ｎ認証）、②本人確認（1：1 認証）、③登録、④削除の 4 つであることが確認された。
ここでは、被災者支援システムとの機能連携度合の高い①検索（１：ｎ認証）、②本人確認（1：1 認証）及び引き続き運用に関する検討要素の高い③登録についてのインターフェースについて詳細設計を実施した内容について述べる。
連携機能インターフェースは「連携機能（クライアント）」と「連携機能（サーバー）」から構成される。それぞれのインターフェースが具備する機能を表 4.3-1 と表 4.3-2 に示す。

表 4.3-1 連携機能（クライアント側）
#

機能

説明
生体認証機能のデータベースに登録される生体情報を生成するための機能

1. 登録用生体情報生成である。生成されるデータの内容は、生体認証機能を提供するベンダーの使用に依存する。
1:N 検索及び 1:1 認証を行う際の生体情報を生成するための機能である。生2. 認証用生体情報生成

成されるデータの内容は、生体認証機能を提供するベンダーの使用に依存する。

表 4.3-2 連携機能（サーバー側）#

機能

1. 1:n 検索

2. 1:1 認証

説明
生体情報を受け取り、該当者を検索する機能である。生体情報の照合処
理は、生体認証機能にて実行される。
ID と生体情報を受け取り、ID が正当なものであるかを検証する機能である。生体情報の照合処理は生体認証機能にて実行される。
ID と生体情報を受け取り、当該生体情報をデータベースに保存するため

3. 登録の機能である。生体情報は生体認証機能がもつデータベースに保存される。

(c) 連携機能インターフェースの機能仕様及び API 仕様
クライアント・サーバー連携機能インターフェースの機能仕様及び API 仕様は、別紙 2「生体認証応用被災者支援システムプロトタイププログラム（連携機能）詳細仕様書」に示す。

45

(d) 連携機能のサンプルコード
それぞれ連携機能のサンプルコードを別紙 3「生体認証応用被災者支援システムプロトタイ
ププログラム（連携機能）サンプルコード」に示す。
このサンプルコードは、生体認証応用被災者支援システム・プロトタイプ・プログラム（連携機能）の API の使用方法を示す。被災者支援システムにおいて、本サンプルコードに倣ってをプログラムコードを実装することにより生体認証管理システムを呼び出すことを想定して作成した。
ただし、サーバ側の実装方式は検討中であるため、疑似コードとして記述されている。そのため 2016 年 3 月現在、実機での動作を保証するものではない。

サンプルコード一覧を下記に示す。
①menu.jsp（メニュー）
生体認証を使用するために最初に表示されるメニュー画面を想定。連携機能（サーバー）から初期化情報を取得し、連携機能（クライアント）へ渡すためのコード。
②1n_search_result.jsp（1:ｎ検索）
menu.jsp 画面から遷移し、本人確認（生体認証）を実行した結果が表示される画面を想定。
1:N 検索機能の呼び出しと、結果表示のためのコード。
③11_verify_result.jsp（1:1 認証）
menu.jsp 画面から遷移し、本人確認（生体認証）を実行した結果が表示される画面を想定。
1:1 認証機能の呼び出しと、結果表示のためのコード。
④enroll_result.jsp（登録）menu.jsp 画面から遷移し、生体情報の登録処理を実行した結果が表示される画面を想定。
登録機能の呼び出しと、結果表示のためのコード。

今後、本作業の結果をもとに各生体認証ベンダー製品との整合性を評価した上で、被災者支援システム側と連携しプロトタイプ・システムの機能改修を進める予定である。

46

4.3.3

成果物の公開・提供について

本研究開発では、広く自治体で実施される被災者支援の改善に成果が供されることを願って取り組んでいる。また、協力いただいている被災者支援システム全国サポートセンターの担当者からは、成果物を必要とする自治体に被災者支援システムのオプションとして提供してゆきたいとのご希望もいただいている。それを踏まえて、成果物の公開・提供条件について検討したので、その内容について報告する。

(1) 本研究開発における成果物の取り扱いについて
本研究開発における成果物は、必要とする自治体に被災者支援システムのオプションとして広く利用され、また実際に自治体に導入される時は、今回の成果物をベースに各生体認証ベン
ダーはそれぞれの製品への機能エンハンスを行って自治体に提供することが想定される。
一方、生体認証側の委託調査実施者やプロトタイプ・プログラムの委託開発者には開発当事者としての著作権・知的財産権や開発物に関する複製・改変・再頒布権が発生する。
そのため、本研究開発における成果物の取り扱いについて、基本的には情報公開対象とすることを前提に、本研究開発参加者と委託開発者で下記内容にて合意を得た。

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

図 4.3-11 本研究開発における成果物の取り扱い合意事項

47

4.3.4

今後の課題(1) 登録機能のプロトタイプ・システム実装の検討① 登録対象者宅でのオフラインでの登録
被災者支援システムの運用側は、生体情報の登録は、日々管理業務の一環として、登録対象者宅でオフラインにて登録し、それを帰朝後オンラインによるバッチ登録することも想定されており、外出先のモバイル端末で生体情報を登録して、帰庁後オンラインにより生体認証管理システムにバッチ登録することに対する対応も求められている。
これに対応するため、今後、以下を検討する必要がある。
a）登録に関する事前処理（準備）、登録処理（現地）、事後処理（バッチ登録）をフロー化とプログラム仕様。
b）バッチ登録における ID の取り扱い、同期の仕組み等に関するプログラム仕様。

48

5.

平成２７年度活動まとめ
平成 27 年度は、生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発フェーズと位置づけ、被災者支援システムの運営・管理元の関係者や自治体関係者をまじえて、
生体認証技術を被災者支援に応用する利点のある利用シーンを検討した。また、被災者支援シス
テム全国サポートセンター（西宮市情報センター内）が開発・管理している被災者支援システム
を生体認証との連携対象として、プロトタイプ・システムの開発に取り組んだ。
その結果、自治体等が被災者支援システムを用いて実施する被災者支援業務の中の一つである避難所に避難行動要支援者（要援護者）の中で自称できない方が避難してきた時の避難者登録時の本人確認に生体認証を応用することが利用シーンとして適切であろうとの結論を得ることができた。次にこの利用シーンに対応するために、被災者支援システムと生体認証の連携方式と生体認証機能に必要とされる仕様について検討し、プロトタイプ・システムの開発に取り組んだ。
それぞれの活動のまとめを次に示す。

5.1 利用シーンの精査と必要な仕様及び機能(1) 被災者支援システムのバージョン調査
連携に適する被災者支援システムのバージョンを V7.0 とした。

(2) 避難行動要支援者に対する生体認証の利用シーンの精査
被災者支援で避難者支援のため被災者支援システムが最初に活用される場面は、避難所における避難者の登録（避難者名簿作成、本人確認）作業の時であり、その中でも、避難者受付業務担当者による本人確認ができない、避難者が意識不明の場合や意思表示ができない（自称できない人）避難行動要支援者の本人確認に適用するのが最適との結論を得た。
避難所の中には、自治体の災害支援システムとつながっていない避難所とつながっている避難所があるが、本研究開発で検討している生体認証の活用が効果を上げるのは、ネットワーク環境のある避難所での応用に適用することが最適とアドバイスを自治体関係者からいただいた。
この場合、生体情報の事前登録は、自治体に義務付けられている避難行動要支援者名簿の作成の際に本人同意を得て生体情報も取得し登録することができるとのご意見をいただいた。

(3) 利用シーンを実現するために必要な被災者支援システム側の仕様及び機能
被災者支援システム側で生体認証を活用するためには次の機能が必要と考えた。ただし、今後の調査等により追加もあり得るものと考えている。
(a) 生体情報の事前登録に関わる機能
日々管理業務で使用されている避難行動要支援者台帳を管理しているシステムに次を実現する機能の付加が必要と考えている。
49

①登録機能の呼び出し機能②避難行動要支援者を一意に特定するための「ID」の受け渡し機能③登録情報の削除機能(b) 避難所における利用シナリオ、操作方法、操作画面等の実現のための機能
自称できない避難行動要支援者の生体情報をもとに、避難行動要支援者と関連付けて保存されている生体情報の検索結果から複数の候補者を得て、避難者受付業務担当者（一般に自治体職員）が達観により同定し、避難者を特定するというシナリオが得られ、被災者支援シ
ステム側では次を実現することが必要と考えた。
①生体認証を用いた検索（１:ｎ検索）機能の呼び出し②本人候補者の提示③生体認証の本人確認（1：1 認証）機能の呼び出し④本人確認（1：1 認証）結果表示⑤避難所での即時登録のための機能の呼び出し(今回の今回のプロトタイプでは開発・検討対象としない)(4) 被災者支援システム側から見たプロトタイプ・システムへの要求仕様
プロトタイプでは、日々管理業務で実施する事前登録/削除を行うための機能と、被災者支援シ
ステムに生体認証と連携するための機能を用意することが必要である。
また、自治体で運用するためには、自治体のセキュリティポリシーにあった通信環境等の構築も必要である。ただしプロトタイプでは庁内の閉じた環境（ローカルネットワーク）での運用を前提とする。

(5) 生体認証機能が被災者支援システムと連携するための基本構成
被災者支援システムと生体認証機能の連携のための基本構成について検討し、その過程で、被災者支援システム側の要望を明らかにした。
この要望を実現するために、各ベンダーの生体認証機能の違い、インターフェースの違いを吸収するための機能を持つ連携機能部を被災者支援システムと生体認証機能の間に設けることとした。
また、「被災者支援システム」は災害発生時毎に、住基システム等の関連システムからデータが被災者支援システム側にコピー等で用意され、災害単位に各種台帳が確立されること、また、生体認証機能への生体情報の事前登録は、被災者支援システムとは関連なく、日々の業務の中で登録されることを明らかにした。
これらをもとに、被災者支援システムと生体認証機能及び連携機能のシステム構成を明確にし、この連携機能と生体認証機能部を合わせて「生体認証管理システム(仮称)」と呼ぶことにした。
そして、被災者支援システム側あるいは自治体システム側と生体認証管理システムとの間には、被災者支援システムが必要とする機能を呼び出すためのインターフェースを用意することとした。
50また、被災者支援システムのオプション機能として生体認証との連携を取り扱えるようするため、生体認証機能との連携実現時も災者支援システム本体への影響を最小限とすることが必要であり、生体認証管理システムとは疎結合で実現することを基本方針とした。

(6) 利用シーンを想定した生体認証機能及び連携機能のあるべき姿（仕様）について利用シーンを想定した生体認証機能及び連携機能(生体認証管理システム)のあるべき姿（仕様）として、次について検討した。
(a) 検索機能
機能の実装について、生体認証側 WG 及び委員会での全体レビューの中で、生体認証による検索の実現及び運用に対して、複数の懸念事項があげられたが、災害時の現場において、
より実効性の高いシステムの提供を第一義とし、あげられた懸念事項を踏まえた上で、以下の 3 点を前提に委員会参加の各生体認証ベンダーより、
将来的に各社の生体認証製品に生体情報による検索機能を具備する方向で合意が得られた。これにより、生体認証管理システムのあるべき姿の具現化に向かって一歩進めることができた。
[候補者検索機能実装の前提]①被災時の人命に関わるシステム機能であること②システム操作者が自治体の職員であること③複数候補者からの最終的な本人特定は自治体の職員が行うこと(b) 連携機能
連携機能は前述の「被災者支援システム」側の期待の実現と各社の生体認証製品の変更をできるだけ少なくする観点から、機能実装に関する検討を進め、次の 3 点を基本構想として得た。
①「被災者システム」側からは「検索（１:ｎ検索）」、「本人確認（1：1 認証）
」、
「生体情
報登録」
、
「生体情報削除」の４機能を呼びだすことができるよう、統一したインターフェース（コマンド及び引数、リターン値）で連携する。
② 一方の生体認証機能部側への連携は、各社の生体認証用の API に対応するようコマンド変換をして各社の生体認証機能を呼び出し、実行する。
③ その際、本人を一意に特定する被災者支援システムの「識別番号」等を業務システムの「サービス ID」として受取り、「連携用 ID」に ID 変換を行う。これは秘密分散によるリスク低減の一環として業務上、本人を識別する「サービス ID」及び本人の「属性情報」を生体認証機能部に直接保持しないことを目的とする。
(c) 連携する「被災者支援システム」サブシステムへの対応「被災者支援システム側」のどのシステムからも必要に応じて連携できる機能を疎結合で実現してほしいとの要望に対応するため、機能を「ボタン」化して、被災者支援システム側と生体認証管理システムとの間は疎結合で実現することを基本方針とした。
また、
生体認証機能との連携実現時も災者支援システム本体への影響を最小限としてほし51

いとの要望に対応するため、被災者支援システムの改修や影響部分を最小限にするために、
被災者支援システム側の関係者と協議し、連携する被災者支援システムのサブシステムを選定した。
(d) システム実装の検討条件「被災者支援システム」との機能連携に関する検討とあわせ、システム実装について検討を行い、本研究開発で開発する被災者支援システム側で生体認証を実装するために用意するインターフェースを利用して実現したいとの要望に対応するため、システム実装時の検討条
件は、以下の要件を満たすことを念頭に置くこととした。
① 連携機能は導入後に維持・改修を自治体主体で行う可能性があるため、できるだけオー
プンソースシステム（OSS）で開発する② 連携機能の調査・検討の結果、実際に開発するプロトタイプ・システムに適用させる
ために、各社センサー製品に関する技術開示や製品の変更が必要となった場合、その対応は生体認証デバイスベンダー各社の責任と負担とするよう取り組む。
③ システム実装において、「連携機能」の実現においては「被災者支援システム」側のAPI インターフェースを統一化することを前提に「生体認証管理システム」側の連携機能を各社の提供する生体認証管理システムに実装することも可能とする。

(7) 生体認証機能及び連携機能のプロトタイプ・システム仕様について
プロトタイプ・システムの仕様の検討の中で、実際に被災者支援システムと連携し、実業務で運用できるようにするためには、検索機能対応など、各生体認証ベンダーが提供する生体認証の機能エンハンスが必要であり、この機能エンハンスは実際に自治体に生体認証機能と連携した被災者支援システムが導入される時に行われることとなため、本研究開発においては実業務で運用できる「あるべき生体認証管理システム」と現行仕様の生体認証ベースとした「プロトタイプ・システム」とに分け、それぞれを念頭に検討を進めることとした。
また、連携機能についてもあるべき姿を目標と置きつつ、開発期限内での実現性を考慮し、検証を行うこと前提にプロトタイプ・システムを設計開発することとした。
その上で、連携機能及び生体認証機能(生体認証管理システム)のあるべき姿とプロトタイプ・システムとの関連をまとめ、プロトタイプの開発仕様として関係者の合意を得た。
さらに、登録/削除機能についても検討し、自治体側の関係者との協議で、今回の検証実験のために日々管理業務のシステムに生体情報登録の機能を組み込むことは困難であるという見解をいただいたので、今回のプロタイプでは、日々管理業務システム例を用意し、そこで生体情報登録の業務シーケンスを動作させることに留めることで取り組むこととした。また、必要な場合は、連携機能の中に、マスタメンテ機能として具備することも検討することとした。

52

5.2 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発(1) 生体認証を用いた被災者支援システムの機能仕様
被災者支援システム全国サポートセンター（センター長 吉田 稔氏）のご協力をいただき、また、「生体認証を用いた被災者支援システム構築のための調査（被災者支援システム側）」WG での自治体関係者の意見をもとに、次の仕様をまとめた。詳細は 4.3 節を参照されたい。
(a) 検索に関わる仕様(b) 運用に関わる仕様(2) 被災者支援システム側の改修
避難所生体認証を用いた避難者の検索は、避難者受付業務担当者の作業を単純化することが肝要であり、それを踏まえて操作画面の改修とインターフェースの追加の検討を行い、下記の追加が必要との結論を得た。詳細は 4.3 章を参照されたい。
(a) 総合メニュー画面における「避難所関連システムメニュー」の改修(b) 生体認証による検索用のメニューの新規作成(c) 生体認証による検索用の画面の新規作成(d) 生体認証管理システムへ必要データを送信するインターフェースの作成（１：ｎ検索）(e) 生体認証管理システムから必要データを受け取るインターフェースの作成（１：ｎ検索）(f) 生体認証による検索用の被災者台帳の参照対応(g) 生体認証による検索用の避難行動用支援者台帳の参照対応(h) 生体認証管理システムへ必要データを送信するインターフェースの作成（１：１認証）(i) 生体認証管理システムから必要データを受け取るインターフェースの作成（１：１認証）(j) 生体認証による検索用の避難者登録対応(3) 日々管理業務システムでの登録/削除機能の改修
プロトタイプ・システムで生体認証による避難者（避難行動要援護支援者）の確認を実施する
ために、生体認証管理システム側への避難行動要援護支援者の事前登録を行う必要がある。生体情報の事前登録は、日々管理業務中で実施されるものであり、被災者支援システムにその機能を呼びたす画面等はないため、プロタイプ・システムによる検証試験を実施するために、ダミー画面を用意し、その中で登録/削除機能を用意することとした。

(4) 生体認証管理プロトタイプ・システムの実装検討
プロトタイプ・システムの開発に向け、適用方法の具体的検討とプロトタイプ・システムのシ
ステム構成や仕様の検討及びプログラム開発として、下記に取り組んだ。
①連携機能プロトタイプ・システムの実装検討②連携機能プロトタイプ・プログラムの開発
53

この中で、日々管理業務システムと被災者支援システムとで、異なるサービス ID を運用する場
合の ID 連携について検討し、避難行動要支援者の支援のため日々管理業務システムで使う識別ID と発災時に被災者支援システムで使用する避難行動要支援者の識別 ID として、全国すべての基礎自治体が持っている ID に団体内統合宛名番号を使うという方向で考えを進めることとした。
その前提を踏まえ、異なる体系のサービス ID による生体認証情報の登録について、以下の 2 点のどちらを採用すべきかについて、今後も継続検討をすることとした。
その上で、異なる体系のサービス ID による生体認証情報の登録について、今後も継続検討をすることとした。
また、連携機能部の構成について検討し、被災者支援システム側で生体認証を実装する際に追加するインターフェース仕様を各生体認証ベンダー間で共有化するためには、被災者支援システ
ムと生体認証機能部との間に連携時に必要とされる連携機能部（サーバ側)を設けるだけではなく、現場で使用されるクライアント端末上にも、生体認証機能部との連携を実現するための連携機能部（クライアント側）が必要であるとの見解が示され、今年の研究開発の結論としては、各社で連携機能部（サーバ側)と連携機能部（クライアント側）の 2 種類を用意し、被災者支援システム
側に提供することで連携機能を実現することで対応する方針とした。
また、この連携機能部（サーバ側)と連携機能部（クライアント側）の被災者支援システムとのインターフェースを除く作りこみ内容は、各社が生体認証機能を提供するシステムにより異なり、その連携機能の実現方法も、①製品内に実装する、②SDK を利用する、③API を利用する等あるた
め、実際の被災者支援システムに連携機能部を提供する際にどのように提案、実現するかは、各社に委ねることとした。

(5) 連携機能プロトタイプ・プログラムの開発
被災者システムの利用シーンを想定した、生体認証機能及び連携機能(生体認証管理システム)のあるべき姿について調査・検討した結果を踏まえ、連携機能プロトタイプ・プログラムの開発に着手し、プロトタイプ・システムの連携機能部の詳細仕様として次の検討開発とサンプルプロ
グラムコードの開発を行った。
①連携シーケンス②連携機能インターフェースの機能仕様及び API 仕様
以降のプログラム開発は本年度の検討開発内容をプロジェクト全体で評価・検証した上で、平成 28 年度研究開発時に段階的に詳細化していく予定である。

(6) 成果物の公開・提供について合意形成
本研究開発の成果物を必要とする自治体に被災者支援システムのオプションとして提供可能とするため、成果物の公開・提供条件について検討し、基本的には情報公開対象とすることを前提に、本研究開発参加者と委託開発者の間で取り扱い条件の合意を得ることができた。

54

6.

平成２８年度活動に向けて
平成 28 年度も活動が継続できる場合は、平成 28 年度をプロトタイプ・システムの検証フェー
ズとして位置づけ、被災者支援システムと生体認証の連携を実現するため、次に示すようにプロ
トタイプ・システムの仕様調査・検討とプログラム開発を継続し、また開発したシステム・プロ
トタイプの機能を自治体関係者の協力を得て検証したいと考えている。
（1）生体認証応用被災者支援プロトタイプ・システム仕様の調査（2）生体認証応用被災者支援プロトタイプ・プログラムの開発（3）生体認証応用被災者支援プロトタイプ・システムの有効性の検証（検証実験）

なお、実施にあたっては、平成 28 年度の課題として今後の検討が必要な次の事項に留意しながら研究開発を進めたいと考えている。

(1) 利用シーンの精査と必要な仕様及び機能に関する今後の課題①被災者支援システム側で生体認証を活用するために必要な機能の精査と追加の必要性の検討②日々管理業務システムによる生体認証情報の「登録」「削除」の要件検討③スタンドアローン「モバイル端末」による自治体拠点外での「登録」運用の検討④避難所における生体認証を用いた避難行動要支援者の検索シナリオの精査⑤異なる体系のサービス ID による生体認証情報の登録時の処理シーケンスの精査と検討⑥検索時の絞込み条件(年齢や性別等)の複数設定可能性のシステム的摺合せ⑦検索・認証におけるエラーケースを洗い出しと、エラー時の扱いについての検討⑧検索時の連携処理シーケンスの精査と検討(2) 生体認証を用いた被災者支援システムのプロトタイプ・プログラムの開発①日々管理業務で実施される登録あるいは削除機能のプロトタイプでの提供方法の検討と実現②モバイル端末による生体登録に対する対応機能の実現③避難所における生体認証を用いた避難行動要支援者の検索シナリオの精査結果の実現④異なる体系のサービス ID による生体認証情報の登録時の処理シーケンスの精査と検討結果の実現⑤検索時の連携処理シーケンスの精査と検討と検討結果の実現⑥検索時の絞込み条件(年齢や性別等)の複数設定可能性のシステム的摺合せ結果への対応⑦被災者支援システムの改修の継続⑧生体認証管理システム(特に連携機能部)の開発要件の整理と開発の継続

55

(2) 検証試験に向けた準備と成果の周知活動①検証試験計画の立案②検証試験環境の構築③事業成果のプロモーション等の計画と実行

最後に、被災者支援システム側の関係者から次の言葉をいただいているので紹介する。

「早いもので、この 3 月 11 日をもって東日本大震災から丸 5 年が経過し、あの阪神・淡路大震
災からも丸 21 年が経過したのである。その都度、国民の危機管理意識は向上したものの、とりわけ東日本大震災における復興処理対応の遅さと危機管理意識の風化の速さに憤懣やるかたない思いを抱いてきたのは我々被災を経験したものだけなのであろうか。
改めてこの機に、阪神・淡路大震災及び東日本大震災の体験・教訓を風化させないためにも、震災を知る人にも、知らない人にも、すべての人と記憶を共有する中で、皆さんと共に考えて生きたい。
そしてここに、この間に犠牲になられた方々のご冥福と被災者の皆様に哀悼の意を表します。
そのためにも、“Hope for the best,but prepare for the worst”（最善を望み、最悪に備えよ！）を実践頂きたいのである。
さて、一昨年スタートしたこの度の研究開発は、発足当時生体認証が被災者支援システムにおける被災者支援業務に果たして実効性があるのか、その有効性を本当に発揮できるのかという不安いっぱいの中、進めてきたわけだが、この間に生体認証管理システムの要件等の調査や精査を重ねてきたことと、今回のプロトタイプ・プログラム開発による単体テストの具現化により、その実効性に及び有効性に光が見えてきたと確信するものである。
又、今後の課題として生体認証で複数の候補者がリストアップされた場合に本人を特定する手段として、表示する候補者を閾値（一致度）の高い順にリストアップしたり、顔写真を被災者台帳に関連づけして表示するといった対応も検討する必要があると考える。
そして、あらゆるベンダーの手法（指紋、顔、手のひら等々）にもとづく生体認証管理システ
ムが共通のインターフェースのもと簡単に導入且つ利活用できるのも時間の問題ではないだろうか。
このようなことから、28 年度に向けての生体認証を応用した被災者支援システムとの連結・連動テストを完全クリアするべく検証実験にその成果を、すなわち真の住民の為の危機管理対応に役立つということを大いに期待したいものである。
」

56

＜別紙-1＞生体認証応用被災者支援システムプロトタイププログラム（連携機能）シーケンス図（1:n 検索）

別紙 1-1

別紙 1-2

生体認証応用被災者支援システムプロトタイププログラム（連携機能）シーケンス図（1:1 認証）

別紙 1-3

別紙 1-4

生体認証応用被災者支援システムプロトタイププログラム（連携機能）シーケンス図（登録）

別紙 1-5

別紙 1-6

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

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

株式会社

日立システムズ

別紙 2-1

第1版

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

変更履歴
#

版

変更日

変更箇所

変更内容

1

2016.03.09

―

新規作成

別紙 2-2

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

目次
1.

はじめに............................................................................................................................................. 5
1.1.

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

1.2.

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

1.3.

用語の定義 ................................................................................................................................... 52.

システム概要...................................................................................................................................... 6

3.

前提条件............................................................................................................................................. 84.

連携機能............................................................................................................................................. 9

5.

4.1.

連携機能（クライアント） .......................................................................................................... 94.2.

連携機能（サーバ）..................................................................................................................... 9

連携機能 API 仕様 ............................................................................................................................10
5.1.

連携機能（クライアント） .........................................................................................................10

5.1.1.

GetEnrollmentCredential ...................................................................................................10

5.1.2.

GetReferenceCredential .....................................................................................................10

5.2.

連携機能（サーバ）....................................................................................................................115.2.1.

Identify................................................................................................................................115.2.2.

Verify...................................................................................................................................125.2.3.

Enroll ..................................................................................................................................125.2.4.

GetInitInfo ..........................................................................................................................125.2.5.

データ型 ..............................................................................................................................13

別紙 2-3

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

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

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

用語

説明

「別紙 連携機能シーケンス」

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

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

用語サービス ID
連携 ID

説明
被災者支援システムが被支援者を識別するための ID
連携機能と生体認証機能がユーザーを識別するための ID

別紙 2-5

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

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

日々業務システム

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

 連携 ID (仮) サービス ID (仮)

API

API

被災者支援システム連携

発災時にデータコピー

ベンダー別 住基データ 避難行動要支援者
 etc.

登録・削除
1:N 検索






被災者台帳
避難者台帳
避難行動要支援者台帳
etc.
生体情報で検索（1:N 検索）

：本書の定義範囲

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

コンポーネント
日々業務システム

7.

被災者支援システム

8.

連携機能

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

別紙 2-6

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

コンポーネント
連携 API10.
11.

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

別紙 2-7

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

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

分類
OS
DBMS
アプリケーションサーバ
生体認証機能説明
Windows 2012 R2
SQL Server 2012
ASP.NET 4.0
日立ソリューションズ

認証管理システム

AUthentiGate 05-01

説明Windows 7 Professional x86
Internet Explorer 11
日立ソリューションズ 認証管理システム

AUthentiGate 05-01

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

分類
OS
Web ブラウザ
生体認証機能表 6 前提ハードウェア
#
19.

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

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

分類
OS

説明
Linux 系オープンソース（詳細は別途決定）

別紙 2-8

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

連携機能
連携機能の実装方式について示す。
連携機能は、被災者支援システムの Web 画面から使用される「連携機能（クライアント）」と被災者支援システムのサーバ側プログラムから使用される「連携機能（サーバ）」の２つの部分から構成される。
被災者支援システムが連携機能（クライアント）を使用して、生体情報を取得する処理フロー
を「別紙 連携機能シーケンス」に示す。

連携機能（クライアント）
連携機能（クライアント）は、被災者支援システムの Web 画面から起動されることを想定する。また、各生体認証機能に対する統一されたインタフェースを被災者支援システムへ提供し、生体認証機能提供ベンダーごとのベンダー別 API の差異を吸収する。
連携機能（クライアント）が持つ機能を次に示す。
表 8 連携機能（クライアント）
#
21.

機能
登録用生体情報生成22.

認証用生体情報生成説明
生体認証機能のデータベースに登録される生体情報を生成するための機能である。生成されるデータの内容は、生体認証機能を提供するベンダーの使用に依存する。
1:N 検索及び 1:1 認証を行う際の生体情報を生成するための機能である。生成されるデータの内容は、生体認証機能を提供するベンダーの使用に依存する。

連携機能（サーバ）
連携機能（サーバ）は、被災者支援システムのサーバ側プログラムから起動されることを想定
し SOAP Web サービスとして実装する。連携機能（サーバ）は、連携機能（クライアント側）が生成した生体情報を受け取り、1:N 検索、1:1 認証及び登録のサーバ側の処理を行う。
表 9 連携機能（サーバ）
#
23.

機能
1:N 検索24.

1:1 認証25.

登録

説明
生体情報を受け取り、該当者を検索する機能である。生体情報の照合処理
は、生体認証機能にて実行される。
ID と生体情報を受け取り、ID が正当なものであるかを検証する機能である。生体情報の照合処理は生体認証機能にて実行される。
ID と生体情報を受け取り、当該生体情報をデータベースに保存するための機能である。生体情報は生体認証機能がもつデータベースに保存される。

別紙 2-9

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

連携機能 API 仕様
連携機能の API 仕様を次に示す。

連携機能（クライアント）
被災者支援システムの Web 画面から使用されることを想定し、JavaScript で実装する。
実装される API の一覧を次に示す。
表 10 連携機能（クライアント）の API
#
26.

API
GetEnrollmentCredential

27.

GetReferenceCredential

説明
生体認証機能のデータベースに登録される生体情報を生成するための機能である。生成されるデータの内容は、生体認証機能を提供する
ベンダーの仕様に依存する。
1:N 検索及び 1:1 認証を行う際の生体情報を生成するための機能である。生成されるデータの内容は、生体認証機能を提供するベンダーの使用に依存する。

GetEnrollmentCredential

GetEnrollmentCredential の仕様を次に示す。

定義
srting GetEnrollmentCredential(Object option)

引数#
引数
28. option型

説明
生体認証装置の初期化に必要な情報。設定内容は生体認証機能の提供ベンダーに依存する。
option の内容は、連携機能（サーバ）の GetInitInfo
API の戻り値に従う。

Object

戻り値
型
説明

戻り値の種
類

String
登録用の生体情報を生成した結果を返す。返される文字列のフォーマットは生体認証機能を提供するベンダーの仕様に依存し、生体認証機能ごとに定義される。
空文字列
ユーザーが生体認証情報の生成をキャンセルした等、生体情報の生成を中止した場合。
文字列（1 文 生体情報の生成に成功した場合
字以上）

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

GetReferenceCredential

GetReferenceCredential の仕様を次に示す。

定義
string GetReferenceCredential(int perpose, string userId, Object option)

引数#
引数
29. perpose

型

int

説明
1 が指定された場合、1:1 認証用の生体情報を生成

別紙 2-10

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

userIdstring30. option

Objectする。2 が指定された場合、1:N 検索用の生体情報を生成する。
認証するユーザーのサービス ID を指定する。
perpose に 1 が指定された場合は必須。perposeに 2 が指定された場合は任意（指定されても処理に使用しない）生体認証装置の初期化に必要な情報。設定内容は生体認証機能の提供ベンダーに依存する。
option の内容は、連携機能（サーバ）の GetInitInfo
API の戻り値に従う。

戻り値
型
説明

戻り値の種
類

String
認証用の生体情報を生成した結果を返す。返される文字列のフォーマットは生体認証機能を提供するベンダーの仕様に依存し、生体認証機能ごとに定義される。
空文字列
ユーザーが生体認証情報の生成をキャンセルした等、生体情報の生成を中止した場合。
文字列（1 文 生体情報の生成に成功した場合。
字以上）

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

連携機能（サーバ）
被災者支援システムのサーバ側プログラムから起動されることを想定し SOAP Web サービスとして実装する。

表 11 連携機能（サーバ）の API
#
31.

機能
Identify

32.

Verify33.

Enroll34.

GetInitInfo

説明
生体情報を受け取り、該当者を検索する機能である。生体情報の照合処理
は、生体認証機能にて実行される。
ID と生体情報を受け取り、ID が正当なものであるかを検証する機能である。生体情報の照合処理は生体認証機能にて実行される。
ID と生体情報を受け取り、当該生体情報をデータベースに保存するための機能である。生体情報は生体認証機能がもつデータベースに保存される。
連携機能（クライアント）に必要な初期化情報を取得。

Identify

Identify の仕様を次に示す。

定義
IdentifyResult Identify(string authData)

引数#
引数
35. authData型

string説明
認証用の生体情報データを指定する。

別紙 2-11

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

戻り値
型
説明

IdentifyResult

1:N 検索結果を返す。詳細は「0 IdentifyResult」を参照

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

VerifyVerify の仕様を次に示す。

定義
VerifyResult Identify(string userId, string authData)

引数#
引数
36. userId
37. authData型

stringstring

説明
認証するユーザーのサービス ID を指定する。
認証用の生体情報データを指定する。

戻り値
型
説明

IdentifyResult

1:N 検索結果を返す。詳細は「0 VerifyResult」を参照

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

EnrollEnroll の仕様を次に示す。

定義
EnrollResult Enroll(string userId, string enrollData)

引数#
引数
38. userId

型

39. enrollData

stringstring説明
生体情報を登録するユーザーのサービス ID を指定する。
登録用の生体情報データを指定する。

戻り値
型
説明

EnrollResult
1:N 検索結果を返す。詳細は「0 EnrollResult」を参照

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

GetInitInfo

GetInitInfo の仕様を次に示す。
別紙 2-12

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

定義
InitInfoResult GetInitInfo(int perpose)

引数#
引数
40. perpose

型

説明

int

取得したい初期化情報の種類を示す。
0：Identify 用の初期化情報を要求
1：Verify 用の初期化情報を要求
2：Enroll 用の初期化情報を要求

戻り値
型
説明

InitInfoResult

1:N 検索結果を返す。詳細は「0 InitInfoResult」を参照

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

データ型
連携機能（サーバ）の引数及び戻り値で使用されるデータ型について示す。
IdentifyResult
1:N 検索の結果を表す。次の属性を持つ。
表 2 IdentifyResult#
名前
41. resultCode

userList型

int

string[]

説明
Identify の処理結果を格納する。
0：該当者あり。
1：該当者なし。
-1：サーバエラー等により処理失敗-2：パラメータデータ不正（生体情報データが破損している等）
候補者（サービス ID）のリストを格納する。
resultCode が 1 以外の場合、内容は不定。
resultCode が 1 の場合、生体情報を照合した結果の候補者（サービス ID）のリストを格納する。

別紙 2-13

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

VerifyResult
1:1 認証の結果を表す。次の属性を持つ。
表 3 VerifyResult#
名前
42. resultCode型

説明
Verify の処理結果を格納する。
0：認証成功
1：指定されたサービス ID の生体情報が一致しな
い
2：指定されたサービス ID に生体情報が登録されていない
3：指定されたサービス ID が DB に登録されていない。
-1：サーバエラー等により処理失敗-2：パラメータデータ不正（生体情報データが破損している等）

int

EnrollResult
登録の結果を表す。次の属性を持つ。
表 4 EnrollResult#
名前
43. resultCode型

説明
Enroll の処理結果を格納する。
0：登録成功3：指定されたサービス ID が DB に登録されていない。
-1：サーバエラー等により処理失敗-2：パラメータデータ不正（生体情報データが破損している等）

int

InitInfoResult
初期化処理取得の結果を表す。次の属性を持つ。
表 15 InitInfoResult#
名前
44. resultCodevalues型

int
KeyValue[]

説明
GetInitInfo の処理結果を格納する。
初期化用データのセットを格納する。

KeyValue
初回化処理取得結果の格納のために使用される。次の属性を持つ。
表 5 InitInfoResult#
名前
45. namevalue

型

stringstring説明
初期化用データの名前を格納する。
初期化用データの値を格納する。

以上

別紙 2-14

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード＜別紙-3＞ 生体認証応用被災者支援システムプロトタイププログラム（連携機能）
サンプルコード

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）
サンプルコード
2016.03.09

株式会社

日立システムズ

別紙 3-1

第1版

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

変更履歴
#

版

変更日

変更箇所

変更内容

1

2016.03.09

―

新規作成

別紙 3-2

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

目次
1.

はじめに............................................................................................................................................. 5

2.

menu.jsp（メニュー） ....................................................................................................................... 6

3.

1n_search_result.jsp（1:ｎ検索）....................................................................................................114.

11_verify_result.jsp（1:1 認証） ......................................................................................................13

5.

enroll_result.jsp（登録） .................................................................................................................15

別紙 3-3

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

はじめに
このソースは、生体認証応用被災者支援システムプロトタイププログラム（連携機能）の API の使用方法を示すものです。被災者支援システムにおいて、本サンプルコードに倣ってをプログラムコードを実装することにより連携機能を呼び出すことを想定しています。
但し、サーバ側の実装方式は検討中であるため、疑似コードとして記述されています。
そのため実機での動作は出来ません。
サンプルコード一覧
下記のファイルから構成されます。
・menu.jsp（メニュー）
生体認証を使用するために最初に表示されるメニュー画面を想定しています。
連携機能（サーバ）から初期化情報を取得し、連携機能（クライアント）へ渡すためのコードが記載されています。
・1n_search_result.jsp（1:ｎ検索）
menu.jsp 画面から遷移し、本人確認（生体認証）を実行した結果が表示される画面を想定しています。
1:N 検索機能の呼び出しと、結果表示のためのコードが記載されています。
・11_verify_result.jsp（1:1 認証）
menu.jsp 画面から遷移し、本人確認（生体認証）を実行した結果が表示される画面を想定しています。
1:1 認証機能の呼び出しと、結果表示のためのコードが記載されています。
・enroll_result.jsp（登録）menu.jsp 画面から遷移し、生体情報の登録処理を実行した結果が表示される画面を想定しています。
登録機能の呼び出しと、結果表示のためのコードが記載されています。
動作概要
下記のような動作を想定します。
(1) menu.jsp をブラウザで表示する。
この画面に、1:N 検索実行用ボタン、1:1 認証実行用ボタン、登録実行用ボタンが表示されている。
(2) 上記、各ボタンをクリックする。
menu.jsp 内に記述されているクライアントコードが実行され、撮影画面が表示される。その後、各ボタンに応じた結果画面（～_result.jsp）に遷移する。
(3) 各結果画面にて、連携機能（サーバ）の API を呼び出し、結果を表示する。

別紙 3-5

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

menu.jsp（メニュー）<%@ page contentType="text/html; charset=UTF-8"%><html><head><title>メニューページ</title></head><body><h3>生体認証応用被災者支援システムプロトタイププログラム（連携機能）サンプルコード</h3><h1>メニューページ</h1><%-NOTE:
このソースは、生体認証応用被災者支援システムプロトタイププログラム（連携機能）の API の使用方法を示すものです。サーバ側の実装方式は検討中であるため、疑似コードとして記述されています。そのため実機での動作は出来ません。
--%>
<!--

START:

1:N 検索ボタンがあるメニュー画面のための処理--><%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 初期化情報を取得する
InitInfoResult initInfo = svc.GetInitInfo(0);if (initInfo.resultCode != 0) {// エラー発生時の処理
return;}%><script type="javascript">// 初期化用オブジェクトの生成
Object searchOption = new Object();<%
foreach (KeyValue kv : initInfo.values) {%>searchOption.<%= kv.name %> = <%= kv.value %>;<%}%>function search() {try {// 連携機能（クライアント）の機能を使用して、生体情報を取得する
別紙 3-6

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

var rtn = GetReferenceCredential(2, "", searchOption);
if ("" == rtn) {// 生体情報の取得結果が空文字列の場合は、キャンセル等されたと判断し// 何もしない
return;} else {// 送信用フォームに生体情報をセットする
document.searchForm.authData.value = rtn;// 生体情報を被災者支援システムに POST する
return true;}} catch (e) {// エラー発生時の処理を行う。
// 詳細は各生体認証ベンダーの意見を踏まえて別途検討
return false;}}</script><!-1:N 検索ボタン用のフォームです。本人確認（生体認証）ボタンが押されたら、onclick イベントで 1:N 検索用の Javascript 関数が呼び出されます。
--><form method="post" name="searchForm" action="1n_search_result.jsp"><input type="button" value="本人確認（生体認証）" onclick="search()" /><input type="hidden" name="authData" /></form><!---><!--->FINISH: 1:N 検索ボタンがあるメニュー画面のための処理

START:

1:1 確認ボタンがあるメニュー画面のための処理<%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 初期化情報を取得する
InitInfoResult initInfo = svc.GetInitInfo(1);if (initInfo.resultCode != 0) {// エラー発生時の処理
return;}%>
別紙 3-7

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード<script type="javascript">// 初期化用オブジェクトの生成
Object vrifyOption = new Object();<%
foreach (KeyValue kv : initInfo.values) {%>vrifyOption.<%= kv.name %> = <%= kv.value %>;<%}%>function verify() {try {// （サンプルとして）フォームのテキストエリアに指定された// サービス ID を取得する
var serviceId = verifyForm.serviceId.value;// 連携機能（クライアント）の機能を使用して、生体情報を取得する
var rtn = GetReferenceCredential(1, seriveId, vrifyOption);
if ("" == rtn) {// 生体情報の取得結果が空文字列の場合は、キャンセル等されたと判断し// 何もしない
return;} else {// 送信用フォームに生体情報をセットする
document.verifyForm.authData.value = rtn;// 生体情報を被災者支援システムに POST する
return true;}} catch (e) {// エラー発生時の処理を行う。
// 詳細は各生体認証ベンダーの意見を踏まえて別途検討
return false;}}</script><!-1:1 確認ボタン用のフォームです。本人確認（生体認証）ボタンが押されたら、onclick イベントで 1:1 確認用の Javascript 関数が呼び出されます。
1:1 確認のためのサービス ID は、テキストボックスに入力される前提です。
--><form method="post" name="verifyForm" action="11_verify_result.jsp"><input type="text" name="serviceId" /><input type="button" value="本人確認（生体認証）" onclick="verify()" /><input type="hidden" name="authData" /></form>
別紙 3-8

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード<!---><!--->FINISH: 1:1 確認ボタンがあるメニュー画面のための処理

START: 登録ボタンがあるメニュー画面のための処理<%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 初期化情報を取得する
InitInfoResult initInfo = svc.GetInitInfo(2);if (initInfo.resultCode != 0) {// エラー発生時の処理
return;}%><script type="javascript">// 初期化用オブジェクトの生成
Object enrollOption = new Object();<%
foreach (KeyValue kv : initInfo.values) {%>enrollOption.<%= kv.name %> = <%= kv.value %>;<%}%>function enroll() {try {// （サンプルとして）フォームのテキストエリアに指定された// サービス ID を取得する
var serviceId = verifyForm.serviceId.value;// 連携機能（クライアント）の機能を使用して、生体情報を取得する
var rtn = GetEnrollmentCredential(enrollOption);
if ("" == rtn) {// 生体情報の取得結果が空文字列の場合は、キャンセル等されたと判断し// 何もしない
return;} else {// 送信用フォームに生体情報をセットする
document.enrollForm.enrollData.value = rtn;

別紙 3-9

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード// 生体情報を被災者支援システムに POST する
return true;}} catch (e) {// エラー発生時の処理を行う。
// 詳細は各生体認証ベンダーの意見を踏まえて別途検討
return false;}}</script><!-登録ボタン用のフォームです。登録ボタンが押されたら、onclick イベントで登録用の Javascript 関数が呼び出されます。
登録対象のサービス ID は、テキストボックスに入力される前提です。
--><form method="post" name="enrollForm" action="enroll_result.jsp"><input type="text" name="serviceId" /><input type="button" value="登録" onclick="enroll()" /><input type="hidden" name="enrollData" /></form><!--->FINISH: 登録ボタンがあるメニュー画面のための処理</body></html>

別紙 3-10

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

1n_search_result.jsp（1:ｎ検索）<%@ page contentType="text/html; charset=UTF-8"%><html><head><title>メニューページ</title></head><body><h3>生体認証応用被災者支援システムプロトタイププログラム（連携機能）サンプルコード</h3><h1>検索結果ページ</h1><%-NOTE:
このソースは、生体認証応用被災者支援システムプロトタイププログラム（連携機能）の API の使用方法を示すものです。サーバ側の実装方式は検討中であるため、疑似コードとして記述されています。そのため実機での動作は出来ません。
--%><%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 連携機能（サーバ）の 1:N 検索機能を呼び出す。
// 生体情報は、前の画面（menu.jsp）の searchForm の Hidden フィールドである// authData に設定されているものを使用する。
IdentifyResult indentifyResult = svc.Identify(request.getParameterValues("authData"));int returnCode = identifyResult.returnCode;if (returnCode == 0) {// 該当者あり。一覧を表示する。
%><table><tr><th>識別番号</th><th>氏名</th><th>性別</th></tr><%
foreach (String serviceId : identifyResult.userList) {// サービス ID を使用して、被災者支援システムから一覧に// 表示する情報を取得する
User user = getUserInformation(serviceId);%><tr><td><%= seriveId %></td><td><%= user.name %></td><td><%= user.age %></td>
</tr>
<%
}
%>
</table>別紙 3-11

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード<%}
if (returnCode == 1) {// 該当者なし。メッセージを表示%>
該当者がありません。
<%}
if (returnCode == -1) {// サーバエラー。メッセージを表示%>
生体認証処理でエラーが発生しました。
<%}
if (returnCode == -2) {// パラメータエラー。通常はコーディングミスなどでしか発生しないはず%>パラメータエラーです。
<%}%></body></html>

別紙 3-12

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

11_verify_result.jsp（1:1 認証）<%@ page contentType="text/html; charset=UTF-8"%><html><head><title>メニューページ</title></head><body><h3>生体認証応用被災者支援システムプロトタイププログラム（連携機能）サンプルコード</h3><h1>本人確認結果ページ</h1><%-NOTE:
このソースは、生体認証応用被災者支援システムプロトタイププログラム（連携機能）の API の使用方法を示すものです。サーバ側の実装方式は検討中であるため、疑似コードとして記述されています。そのため実機での動作は出来ません。
--%><%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 連携機能（サーバ）の 1:1 認証機能を呼び出す。
// 生体情報は、前の画面（menu.jsp）の searchForm の Hidden フィールドである// authData に設定されているものを使用する。
VerifyResult verifyResult = svc.Verify(request.getParameterValues("serviceId"),
request.getParameterValues("authData"));int returnCode = verifyResult.returnCode;if (returnCode == 0) {// 認証成功%>
本人と確認できました。
<%}
if (returnCode == 1) {// 認証失敗。照合した結果、生体情報が一致しない。
%>
生体情報が一致しませんでした。
<%}
if (returnCode == 2) {// 認証失敗。指定されたサービス ID に生体情報が登録されていない。
%>
別紙 3-13

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

生体情報が未登録です。
<%}
if (returnCode == 3) {// 認証失敗。指定されたサービス ID が登録されていない%>
識別番号が連携機能に登録されていません。
<%}
if (returnCode == -1) {// サーバエラー。メッセージを表示%>
生体認証処理でエラーが発生しました。
<%}
if (returnCode == -2) {// パラメータエラー。通常はコーディングミスなどでしか発生しないはず%>パラメータエラーです。
<%}%></body></html>

別紙 3-14

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

enroll_result.jsp（登録）<%@ page contentType="text/html; charset=UTF-8"%><html><head><title>メニューページ</title></head><body><h3>生体認証応用被災者支援システムプロトタイププログラム（連携機能）サンプルコード</h3><h1>登録結果ページ</h1><%-NOTE:
このソースは、生体認証応用被災者支援システムプロトタイププログラム（連携機能）の API の使用方法を示すものです。サーバ側の実装方式は検討中であるため、疑似コードとして記述されています。そのため実機での動作は出来ません。
--%><%// 連携機能（サーバ）への接続を初期化する
svc = new BiometricConnection();// 連携機能（サーバ）の登録機能を呼び出す。
// 生体情報は、前の画面（menu.jsp）の searchForm の Hidden フィールドである// enrollData に設定されているものを使用する。
EnrollResult enrollResult = svc.Enroll(request.getParameterValues("serviceId"),
request.getParameterValues("enrollData"));int returnCode = enrollResult.returnCode;if (returnCode == 0) {// 登録成功%>
登録に成功しました。
<%}
if (returnCode == 3) {// サービス ID が連携機能に存在しない。
%>
指定された識別番号が連携機能に登録されていません。
<%}
if (returnCode == -1) {// サーバエラー。メッセージを表示%>
別紙 3-15

生体認証応用被災者支援システム
プロトタイププログラム（連携機能）サンプルコード

生体認証処理でエラーが発生しました。
<%}
if (returnCode == -2) {// パラメータエラー。通常はコーディングミスなどでしか発生しないはず%>パラメータエラーです。
<%}%></body></html>以上

別紙 3-16

＜別紙-4＞ 成果物の情報公開を行う考え方

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

別紙 4-1

－禁無断転載－

２７－７

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

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