システムアーキテクト 2023年 春期 午後I 問題

共通の文章

システム再構築における移行計画に関する次の記述を読んで,設問に答えよ。 A社は,医療用品の製造及び販売を行うメーカーである。A社とその関連会社の3 tt GUE,Aグループという)は,基幹システムとしてX HO ERPパッケージ製品 (以下,ERPという)と,情報系システムとしてERPのオプション製品である分析ツ ールを使用している。 LOL,現在使用しているERPと分析ツールのサポート期限が2年後に迫っている ので,これらをバージョンアップし,新しいシステムとして再構築するための移行計 画を立案することになった。A社情報システム部のB課長がプロジェクトチームのリ ーダーに任命された。 [現行のシステムと業務の概要〕 Aグループは現行の基幹システム(以下,現行基幹システムという)として,ERP のうち財務会計,管理会計,販売管理,生産管理,購買管理の五つのサブシステムを 利用している。現行基幹システムは各社で独立した構成となっており,ERPに対する 定義やマスターデータを独自に設定している。また,各社の業務に応じて個別に開発 されたアドオンプログラム(以下,アドオンという)が存在している。 現行の情報系システム(以下,現行情報系システムという)では,前月や前年度と いった過去の売上や製造原価などの経営状況を翌月以降に必要に応じて分析するため の帳票を,各社の要望に応じて個別に定義している。新たな切り口によるデータの集 計が必要な帳票を定義する場合は,あらかじめ,基となるデータを現行基幹システム から抽出し,必要な集計を行ったデータを現行情報系システム内に保存している。 運用スケジュールは.,8時から24時までがオンライン運用時間.それ以外はアド オンとして開発された夜間バッチ処理やシステムメンテナンスの時間となっている。 毎月上旬の数日間に分割して実行される夜間バッチ処理では,実績データに対する各 種の締め処理が行われる。 Aグループが得意先からの受注や出荷を行う営業日は,年末年始を除き平日と土曜 日である。受注にはEDIを用いる。受注データ中の納品日には受注日の翌営業日から 7日先までの営業日を設定可能であり,受注日の翌営業日が設定されることが多い。 |aes 〔物流システムの概要〕 Aグループは各社共通の物流システムを使用している。現行基幹システムでオンラ イン運用時間内に受信した受注データを基に,夜間に出荷指示データ送信処理が出荷 指示データを作成し,物流システムに送信する。 Aグループは出荷当日に得意先に納品可能な体制を整備しており,物流システムは 出荷指データに基づき,受注データで指定された納品日に得意先への出荷を行う。 [情報システム担当役員から提示された再構築と移行に関する指示〕 A社の情報システム担当役員から再構築と移行に関して次の指示があった。 ・ERPと分析ツールのサポート期限までの期間が短いので,新しい基幹システム(以 下,新基幹システムという)と新しい情報系システム(AE,新情報系システムと いう)の構築では,業務プロセスの見直しは行わない。 ・ERPと分析ツールのバージョンアップを作業の中心とし,重要な経営方針である, 業務の効率化と高付加価値型業務へのシフトに直接関連する改善案件の実施だけを プロジェクトの対象とする。 ・過去の経営状況を新たな切り口でも分析できるようにする。 ・移行作業によるシステムの停止に伴う,受注や出荷などの業務への影響は最低限に 抑える。特に受注や出荷において,得意先からの受注データが移行期間中に滞留し て出荷が遅れることは避ける。 情報システム部長から提示された再構築と移行に関する方針] A社の情報システム部長からは再構築と移行に関する次の方針が提示された。 ・マスターデータの勘定科目コードや各種のコードが,A社と関連会社との間で統一 されていない。新しいシステムとして再構築する時に関連会社のコードをA社のコ ードに統一し,4社を一斉に移行する。コードの統一が必要な理由は,予算管理や 連結決算の際に,関連会社の経理担当者が表計算ソフトでA社のコードに合わせた 集計を別々に実施しており,各社から,これらに必要な経理担当者の事務処理の負 担が大きいとの意見が以前から寄せられているからである。 ・業務への影響が少ないいずれかの土日を移行期間とし,新基幹システムの本稼働日 を月曜日とする移行計画としたい。この場合移行期間中の土曜日の受注を停止す ー3一 るために,本稼働日の月曜日に品物を受け取りたい得意先に対して,①移行期間前 の適切なタイミングに協力を依頼する。 ・各社の既存のアドオンは,新基幹システムでも継続利用する。 ・現行情報系システムの帳票の定義は,新情報系システムでも継続利用する。 ・現行基幹システムの実績データは前月分と当月分だけ更新できる。このことを利用 して移行作業によるシステムの停止期間を短縮したい。 ・移行期間前後のマスターデータの登録や情報系システムの使用に対する運用制限が 必要な場合は,各社に協力を仰ぐ。 (X社から提供されたERPと分析ツールのバージョンアップに関する情報] X社からは,バージョンアップに関する次の情報提供を受けた。 ・新基幹システムを新規に構築する場合は,サーバに新バージョンのERPをインスト ールした上で,各種の定義の設定やアドオン追加などによる構築を行う。 ・現行基幹システムを基にして新基幹システムを構築する場合は,サーバに新バージ ョンのERPをインストールした上で,ERP移行ツールを用いてERPの標準機能と各 種の定義を新基幹システムに移行する。 ・ERPの現行バージョンと新バージョンとではデータ構造が異なる。そのため,現行 バージョンのデータ構造から新バージョンのデータ構造に変更した上でデータを移 行する必要がある。データ移行の要件に基づき,ERP移行ツールを使用したデータ 移行とするか,個別のデータ移行プログラムを使用したデータ移行とするかを選択 する必要がある。ERP移行ツールを使用する場合.データ構造の変更はERP移行ツ ールの中で行われるが,コード変換のようにデータの値を加工することはできない。 なお,現行基幹システムでコード変換などのデータの値の加工を行ってからERP移 行ツールを使用する方法は,作業手順が複雑になるので推奨していない。 ・既存のアドオンは,X社が提供する手順書を用いて移行する。 ・現行基幹システムを停止した後に新基幹システムに移行するデータ量が多ければ多 いほど,システムの停止期間が長くなる。 ・分析ツールは,新バージョンを導入しても既存の帳票の定義がそのまま使用できる。 X社から提示されたERPの新バージョンへの移行パターンを表1に示す。 ー4一 表1 X社から提示されたERPの新バージョンへの移行パターン 各パターンの作業概要特徴など パターン1:(1)初期状態のERPに対し,業務要件に合わせた必要な定義を行う。 新規構築(2)業務要件などによるアドオンが必要な場合は新規に開発する。 (3)移行要件に基づき,現行基幹システムからデータを移行する。 パターン2:(1)、X社が提供する手順書を用い,アドオンを移行する。 ERP移行ツールを|(2)現行基幹システムの停止後,ERP移行ツールによって,現行基幹シス 使用したデータ移テムから新基幹システムに対して,各種の定義を配置する。さらに,ERP 行移行ツールによって,現行基幹システムから新基幹システムに移行するデ ータを抽出し,格納されているデータの値は加工せずに新基幹システムに 登録する。 パターン3:(1)X社が提供する手順書を用い,アドオンを移行する。 個別のデータ移行|(2)現行基幹システムの稼働中に,ERP移行ツールによって,現行基幹シ プログラムを使用ステムから新基幹システムに対して,各種の定義を配置する。 したデータ移行(3)移行要件に合わせた,次の(ア)~(ウ)を実施する複数のデータ移行プ ログラムを事前に開発し,実行する。 (ア)現行基幹システムから新基幹システムに移行するデータを抽出し, それらのデータを| a』|する。 (イ)コード変換を行う場合,あらかじめ作成したコード変換表に従い, 変換対象のコードを格納する全てのテーブルに対するコード変換を行 う。 (9)(ア),(イ)の処理を行ったデータを新基幹システムに登録する。 [立案した移行計画〕 B課長は,再構築と移行に関する指示と方針に合致する移行パターンを検討した。 その過程で,パターン1は再構築と移行に関する指示と方針に合致しないと判断した。 また,パターン2はデータ移行時に制約事項があり,再構築後も現在発生している業 務上の問題を解決できないことから,再構築と移行に関する指示と方針に合致しない と判断し,パターン3を選択した。 新情報系システムへのデータ移行においては,②A社のデータは現行情報系システ ムから新情報系システムにそのまま移行するが,関連会社のデータは,新基幹シス テムに移行したデータに基づいて集計を行ったデータを新情報系システムに登録す ることにした。 これらを踏まえ,B課長は再構築と移行に関する指示と方針に基づいた移行計画を 立案した。立案した移行計画の概要を表2に示す。 の)5ーー: 表2立案した移行計画の概要 基本施策・業務への影響が少ない,月の中旬の土日を移行期間とし,関連会社のコー ドをA社のコードに統一した上で4社を一斉に移行する。 ・パターン3の移行パターンを選択し,現行基幹システムの稼働中に,新基 幹システムに各種の定義やアドオンを配置する。 ・③現行のシステムの全ての過去データを,新しいシステムへの移行対象と する。 得意先への出荷・金曜日までの受注データに基づき,土曜日の出荷は通常どおり実施する。 に関する対応・土曜日の受注を停止するために,得意先に対して必要な協力を依頼する。 データ移行手順・現行基幹システム停止直前の1週間を事前移行期間にし,この期間はマス ターデータの更新運用を停止する。 ・金曜日のオンライン運用終了後の出荷指示データ送信処理が完了した後に 現行基幹システムを停止し,移行作業を開始する。 ・システムの停止期間を短縮するために,現行基幹システムのデータを2回 に分けて移行する。 (ア)事前移行期間にマスターデータと④ある範囲の実績データを移行 する。 (イ)現行基幹システム停止後に,残りの実績データを移行する。 ・情報系システムのデータの移行作業は新基幹システムの稼働後に行う。新 情報系システムを用いる業務には移行作業完了まで運用制限を行う。 物流システム(省略) への対応

共通の文章

セミナー管理システムに関する次の記述を読んで,設問に答えよ。 ソフトウェアパッケージの開発・販売を行っている(社では,全国主要都市で自社製 品の説明会を開催していたが,新たに無料のオンラインセミナーを開催することになり, それをサポートするセミナー管理システム(以下,新システムという)をWebシステム として開発することになった。 [セミナー管理業務の概要〕 C社のセミナー管理業務の概要は次のとおりである。 (1)セミナー登録 企画担当者がセミナーを企画し,企画書を作成する。 セミナーは,企画担当者のほか,講演資料を作成して講演を行う講師担当者及び セミナーの運営を行う運営担当者で担当する。企画・講師・運営の三つの担当役割 について,それぞれ複数名の担当者を設定でき,一人の担当者が複数の担当役割を 兼務する場合もある。一つの担当役割に複数名を設定した場合は,その中でリーダ ーを一人設定する。 セミナーには,リソースのひっ人迫を避けるために受講する人数について定員を設 定している。 企画書には,セミナー名,セミナー内容,定員,開催日時,終了時刻及び企画・ 講師・運営の各担当者の担当者IDと担当者名が記載されている。 企画担当者は,作成した企画書を上長に提出し,承認を受けた後,実施予定セミ ナーとして登録する。 (2)募集・申込み 企画担当者はセミナーの概要を募集画面に掲載して受講申込みを受け付ける。 受講を希望する者は申込入力画面からセミナーを選択し,氏名,会社名,部署名, 役職名,メールアドレスなどの情報を入力して申込みを行う。 当該セミナーについて同一メールアドレスで申込みが重複しておらず,セミナー の定員に達していない場合は申込みを確定し,受講確定メールを受講申込者へ送付 する。 申込みはセミナー開催の3日前に締め切る。 ー8一 (3)開催準備,開催案内 運営担当者はセミナー開催の2日前にオンラインルームを開設し,アクセスURL とアクセスキーを決定する。 運営担当者は受講申込者に開催案内メールを送信する。開催案内メールには,受 講確定メールに記載した内容に加えて,アクセスURL及びアクセスキーが記載され ている。 企画担当者は,受講申込者に回答してもらうアンケートを作成する。 (4)受講 受講申込者はセミナー開催当日にWebブラウザからアクセスURLにアクセスし, オンラインルームにログインしてセミナーを受講する。 なお,受講申込者は多重ログインできない。 (5)アンケート セミナー終了後,運営担当者から受講申込者にアンケートURLが記載されたアン ケートメールを送信する。受講申込者はアンケートURLにアクセスし,受講ID, 氏名及び受講の有無を入力し,個別の設問に回答する。また,受講した者(以下, 受講者という)はセミナーの評価点を10点満点の数字で入力し,受講しなかった 者は受講しなかった理由を入力する。入力したアンケートの回答は変更できない。 (6)集計・分析 企画担当者はアンケートの回答について,集計・分析を行った結果を上長に報告 する。また,担当者の業務負荷確認のために,1か月ごとに担当したセミナーの数 と担当役割を集計して上長に報告する。 〔新システムの概要〕 情報システム部のD課長は,業務の概要を基に新システムの設計を行った。 (1)セミナー登録 セミナーの企画書を登録する機能。企画担当者が企画書の内容を入力すると,セ ミナー,セミナー担当の各ファイルにレコードを作成する。この時,セミナーに一 意のセミナーTIDを付与する。セミナー担当に登録する担当者IDは別システムで事 前に付与されている。 (2)募集・申込み aie= 受講を希望する者からの申込みを受け付け,申込みの重複及び定員超過を判定し, 受講を確定させる機能。申込判定がOKのときは申込確認画面を表示し,確定ボタ ンが押されたら受講を確定する。申込確認画面で,取消ボタンが押されたら申込入 力画面に戻る。 受講確定時に受講IDを発行し,受講申込ファイルにレコードを作成する。受講 IDは,英数字8桁から成る一意のID CHS, 受講確定後,受講ID。セミナーID,セミナー名,開催日時,終了時刻及びセミ ナー内容を記載した受講確定メールを受講申込者へ送付する。 (3)開催準備,開催案内 開設したオンラインルームのアクセスURLとアクセスキーをオンラインルームフ ァイルに登録し,受講申込者に開催案内メールを送信する機能,及びセミナー終了 後に回答してもらうアンケート画面を作成する機能。開催案内メールには,受講確 定メールに記載した内容に加えて,アクセスURL及びアクセスキーを記載する。 (4)受講 受講を受け付ける機能。受講申込者はアクセスURLにアクセスし,開催案内メー ルにある受講ID及びアクセスキーを転記してオンラインルームにログインし,セ ミナーを受講する。ログイン時に受講ID及びアクセスキーのチェックを行い,受 講ファイルにレコードを作成する。この時,受講受付日時に現在日時を設定する。 (5)アンケート 対象者にアンケートメールを送信する機能,及びアンケート画面から入力された 回答を基にアンケートファイルにレコードを作成する機能。 (6)集計・分析 アンケートの回答の集計・分析,及び担当者の担当役割とセミナー数を集計する 機能。 D課長は,上記の概要を基に新システムのデータ設計を行い,主要なファイルを表 1のように設計した。 ー19一 表1新システムの主要なファイル 主な属性(下線は主キーを示す。) セミナーセミナー1D,セミナー名,セミナー内容,開催日時,終了時刻, 定員,アンケートURL セミナー1ID,担当役割,担当者ID,リーダーフラグ メールアドレス,申込日時 セミナー1D,アクセスURL,アクセスキー 受講ID,受講受付日時 アンケート受講ID,受講有無2,評価点?,受講しなかった理由, 個別設問回答内容,回答日時 注記セミナー担当ファイルについては,全ての属性を記載しているが,主キーの下線は省 略している。 9担当役割に複数の担当者が設定されたとき,その中のリーダーの担当者のリーダーフ ラグに“1”を,それ以外の担当者のリーダーフラグに“0”を設定している。 3?受講者に"有",受講しなかった者に"無"を設定している。 °°受講者の評価点は1から10の整数であり,受講しなかった者の評価点は9を設定す る。 また,新システムにおける募集・申込みの処理について,表2のように設計した。 表2新システムにおける募集・申込みの処理 申込入力|申込入力画面から,セミナーID,KZ,会社名,MBL,役職名及びメール アドレスを受け付ける。 申込判定当該セミナーIDで,[a]ファイルを検索し,入力された[b ] (重複)|と同じ[|b|が存在すればエラーとし,エラーメッセージを表示して 処理を終了する。 申込判定当該セミナーIDで,受講申込ファイル及びセミナーファイルを検索し,受 (定員)講申込ファイルのレコード件数がセミナーファイルの定員以上のときは,定 員超過でエラーとし,エラーメッセージを表示して処理を終了する。申込判 ED OKのときは申込確認画面を表示する。 申込確認|申込確認画面の確定ボタンが押されたときは,受講IDを発行して受講申込 ファイルにレコードを作成するとともに受講確定メールを送信する。取消ボ タンが押されたときは,申込入力画面に戻る。 [指摘及び追加要望〕 D課長が設計内容を上長に説明したところ,次のような指摘及び追加要望が出され た。 ・申込確認処理について,今のままでは確定ボタンを押した際に定員を超過する可能 性がある。定員超過の際は,エラーとするよう変更してほしい。 ・今のログイン方式では,通信障害などで接続が切れた場合に再接続ができなくなる。 接続が切れたことを検知した場合には,当該受講IDで再ログインができるように してほしい。 ・アンケートURLにアクセスした際に,入力画面で受講ID及び氏名を入力させるの ではなく,あらかじめ受講ID及び氏名を埋め込んだページを開いて回答させるよ うにしたいので,個別のアンケートURLを送信してほしい。 ・開催したセミナーの申込率,受講率及び平均評価点の三つの項目を一覧表示する機 能を追加してほしい。ここで,申込率は定員に対する受講申込者数の割合,受講率 は受講申込者数に対する受講者数の割合,平均評価点はアンケートに回答した受講 者の評価点の平均点を示す。 [新システムの設計変更] D課長は指摘及び追加要望を受け,次のような設計変更を行った。 ・申込確認画面で確定ボタンが押されたときに再度申込判定の処理を行うようにし, エラーになった場合はエラーメッセージを表示して処理を終了する。また,確定ボ タンを押してもエラーとなることがある旨を申込確認画面に表示する。 ・受講ファイルに,接続フラグという属性を追加し,初期値として“1”を設定する。 別途,接続が切れたことを検知した際に接続フラグに“"@'"を設定するようにする。 その上で,再接続する際の①ログイン時の受講IDに関するチェック及び受講ファ イルの更新処理を新たに追加する。 ・セミナー終了後に受講申込者に送信するアンケートURLを,受講IDごとの個別の URLに変更する。これに伴って,②@表1中のある属性を別のファイルに移す。 ・セミナーファイルに,PAK,受講率及び平均評価点の属性を追加する。申込率, 受講率及び平均評価点は,セミナー1ID及びセミナーIDから検索した受講IDを用い て表1の各ファイルを検索し,その結果を用いて,THEN,表3に示す計算式で ー12一 ROS.KEL,各計算式の除数が9のときは項目の値を6とする。 表3各項目の計算式

共通の文章

基盤システムに関する次の記述を読んで,設問に答えよ。 生体認証は,人間の身体的特徴や行動的特徴を用いて本人であることを認証する 仕組みであり,暗証番号やパスワード,又はカードなどの物による認証に代わり忘 却や紛失のおそれのない認証方式として実用化が進められてきた。 生体認証機器メーカーである『社は,指紋,虹彩,BARI,顔などを利用した 様々な生体認証端末を開発している。F社はこれらの機器を販売するとともに,シス テムインテグレーターとして,単一事業者向けに生体認証端末と制御用PCを利用し たシステムの開発も行っている。SR,ホテルチェーンを展開する事業者(以下, ホテル事業者という)DSF社に対して,顧客体験価値向上のため,ホテルの利用 者が顔認証だけで系列ホテルが提供する様々なサービスやホテル事業者と提携する 事業者のサービス(以下,提携サービスという)を受けられるシステム(以下,本 システムという)の開発が打診され,F社で検討を行った。 [開発を打診された本システムの主な機能] 本システムの主な機能を次に示す。 ・ホテルの利用者は,事前に顔認証に必要な情報(以下,顔情報という)を登録し て宿泊予約を行えば,宿泊日に各ホテルのチェックインカウンターに設置された 顔認証端末で顔認証を行うだけでチェックインが可能となる。 ・チェックイン完了後,宿泊ルームの開錠やホテル内施設の利用など,各ホテルが 提供する様々なサービスの利用が顔認証だけで可能になる。 ・上記サービスは系列ホテルの全てで利用可能である。 ・ホテルの利用者は,レンタカーや宅配サービスなど,提携サービスも顔認証だけ で利用することができる。 F社において自社開発の実現性を検討した結果,これまで開発してきた単一事業者 向けのシステムに比べて規模は大きくなるが,F社の自社保有技術をコアとする新た なアーキテクチャを構築することで対応可能であると結論付け,本システムの開発 を進めることになった。本システムのサービスの概要を図1に示す。 ー29一 ED E>ED CED 開錠施設利用利用 oN/ 図1本システムのサービスの概要 〔本システムの要件検討〕 F社のシステムアーキテクトであるGK,本システムの開発に当たり,開発要件 の検討を行い,次の機能要件及び非機能要件を抽出した。 (1)機能要件 ・ホテルの利用者が事前に顔情報を登録する際に,運転免許証.,パスポート,マ イナンバーカードなど,利用者の顔写真付きの公的証明書との照合によって 本人であることを確認する手段(以下,本人確認という)を提供する。 ・ホテル内施設の店舗での決済を顔認証で行う場合など,精度の高い認証が求め られるサービスに対しては,顔認証に加え,ワンタイムパスワードによる追加 の認証もサポートする。 ・ホテル事業者のシステムだけでなく,提携する事業者のシステムに対しても共 通の顔認証機能を提供する(以下,マルチサービスという)。 ・本システムは,宿泊予約などを登録,管理するシステム(以下,会員管理シス テムという),及び提携する事業者のシステムと連携して動作する必要がある。 これをシステム間連携という。 (2)非機能要件 ・本システムに登録可能な顔情報の件数は,ホテルチェーンへの全展開や提携す る事業者の拡大などを考慮し,最大100万人分を想定する。また,顔情報を入 力してから認証結果が得られるまでの実用的な時間は1秒以内とする。 ・ホテルの利用者の顔情報などの個人情報を扱うので,その保管や通信に高度な セキュリティが要求される。 ・将来的にホテル事業者以外の様々な事業者のシステムに適用できるよう,汎用 性・拡張性の高いアーキテクチャとする。 a Hm [本システムの開発方針 G氏は抽出した要件に基づき,次のように開発方針を整理した。 (1)アーキテクチャ構築方針 本システムのアーキテクチャを,顔認証機能を提供する基盤システム(以下, 顔認証基盤という)とホテル事業に依存するシステムとに分離することで,ホテ ル事業者だけでなくほかの事業者のシステムへの適用を容易にする。また,顔認 証基盤の拡張によって,将来的に顔認証だけでなく,様々な生体認証機能を提供 できるようにする。 (2)サーバ構築方法の選択E 利用者の顔情報の登録,管理及び顔認証処理をサーバに集約する。このサーバ を顔認証サーバという。さらに,顔認証サーバは次の理由から,クラウドサービ ス上に構築することとする。 ・初期費用及び維持管理費用の削減を図ることができる。 ・セキュリティを確保するための機能が充実している。 (3)マルチサービスの実現 マルチサービスを実現するために,事業者が利用者を識別するための情報(以 下,識別情報という)を利用者の顔情報と関連付ける仕組みを開発する。識別情 報の例としては,ホテル事業者であれば,会員管理システムにおける会員番号が 該当する。このような関連付けによって,顔認証によって個人を特定し,COM 別情報を事業者に提供することができる。 (4)利用者のスマートフォンの活用 利用者のスマートフォン(以下,スマホという)を使用して顔認証に必要な情 報を入力するため,顔情報の登録,本人確認.追加の認証などを行うスマホのア プリケーションプログラム(以下,アプリという)を開発する。 (5)システム間連携の実現 システム間連携を実現するために,顔認証サーバを利用する上顔認証APIを開発 し,事業者が利用できるようにする。また,事業者のシステムと顔認証端末及び 利用者のスマホとを連携させるため,事業者のシステムにアクセスする事業者シ ステムAPIを「社が定義し,事業者で実装後,F社が利用できるようにしてもらう。 ー22一 〔顔認証基盤のアーキテクチャ]〕] G氏は顔認証基盤のアーキテクチャ構築が最も重要であると考え,顔認証基盤の検 討から着手した。顔認証基盤の概要を図2に,顔認証基盤が提供する機能を表1に 示す。 クラウドサービス CT顔認証端末]—" M2顔認証基盤の概要 表1顔認証基盤が提供する機能 構成要素機能説明 ・利用者のスマホで利用者の顔を撮影し,顔情報を取得した後,顔認証サーバに送信する。 ・顔の撮影後,利用者の顔写真付きの公的証明書も撮影し,顔認証機能を使用してアプリが本 利用者の人確認を行う。又は,スマホの近距離無線通信機能を使用して,公的証明書から情報が読み スマホ取れる場合は,その情報を使用してアプリが本人確認を行う。 ・利用者が事業者のシステムにスマホでサインイン後,顔を撮影すると,アプリは顔情報を取 SL,事業者のシステムに送信する。 ・カメラを搭載した汎用タブレット端末であり,利用者が顔を撮影すると,顔情報を取得し て,事業者の情報とともに顔認証サーバに送信し,認証結果として識別情報を受信する。 i認証・追加の認証を行う場合,顔認証サーバから利用者のスマホにワンタイムパスワードを送信 端末し,利用者が受信したワンタイムパスワードを顔認証端末から入力することで認証する。 *・事業者のシステムに対して,認証結果として識別情報を送信する。 ・顔認証端末を複数の事業者で共有し,対応する事業者のシステムと連携することが可能であ る。 ・利用者のスマホから送信された顔情報をクラウドサービスのデータベースに登録,管理す rhage・顔認証端末から受信した顔情報から顔認証を行い,認証結果として事業者に関連付く識別情 en=る。 報を顔認証端末に送信する。 ・事業者のシステムからの要求で,顔情報と識別情報とを関連付ける。 ・利用者のスマホからの要求で,識別情報及びスマホから送信された顔情報を顔認証サーバに 事業者の送信する。 システム・顔認証端末から認証結果を受信し,認証された識別情報から利用者を特定して,様々なサー ビスを提供する。 [本システムへの上顔認証基盤の適用性検討] G氏は,ホテルの利用者が本システムを利用して,予約からホテル内施設及び提携 サービスが利用できるようになるまでのシナリオを想定し,処理を明確にすること で,本システムへの上顔認証基盤の適用性の検討を行った。 ・本システムを利用するホテルの利用者がスマホで顔を撮影すると,アプリは顔情 報を顔認証サーバに送信する。さらに,ホテルの利用者が会員管理システム及び 提携する事業者のシステムにスマホからサインインして顔を撮影すると,顔認証 サーバで顔情報と識別情報との関連付けが行われる。 ・ホテルの利用者は会員管理システムにサインインして宿泊予約を行う。 ・宿泊日当日に,ホテルの利用者がホテルのチェックインカウンターに設置された 顔認証端末で顔を撮影すると,顔認証サーバが顔認証を行い,認証結果として識 別情報を顔認証端末に送信する。 ・顔認証端末は受信した識別情報を|a|することで,チェックインを完了す る。 ・以降,ホテルの利用者がホテル内施設を利用する際,同様に顔認証端末で顔を撮 影すると,|b|であるかどうかを判定し,ホテル内施設でのサービスの可 BERETS. ・提携サービスでは,ホテルの利用者が顔認証端末で顔を撮影すると,本システム は提携サービスの利用者として顔認証を行い,識別情報を用いてホテルの利用者 にサービスを提供する。 検討の結果,顔認証端末,会員管理システム及びアプリからの顔情報の送信頻度 が非常に高く,顔認証サーバでの認証に影響することが想定された。これに対して, 顔認証サーバをクラウドサービス上でスケールアウトしただけでは,非機能要件で 規定した性能要件を達成できないことが判明した。そこで,G氏は顔認証端末だけで ローカルな認証を行うエッジ認証機能が必要であると考え,実装することにした。 具体的には,チェックインを予定しているホテルの利用者の認証に必要な情報を, 会員管理システムからの要求によって,BA,顔認証サーバから顔認証端末にダウ ンロードし,顔認証端末だけでローカルな認証を行うなどの機能である。 ごes