令和5年度 春期 午後Ⅰ

本文の根拠

〔現行のシステムと業務の概要〕

A グループが得意先からの受注や出荷を行う営業日は，年末年始を除き平日と土曜日である。

〔現行のシステムと業務の概要〕

受注データ中の納品日には受注日の翌営業日から 7 日先までの営業日を設定可能であり，受注日の翌営業日が設定されることが多い。

〔情報システム部長から提示された再構築と移行に関する方針〕

この場合，移行期間中の土曜日の受注を停止するために，本稼働日の月曜日に品物を受け取りたい得意先に対して，

表2 得意先への出荷に関する対応

金曜日までの受注データに基づき，土曜日の出荷は通常どおり実施する。

営業日は平日と土曜日で，日曜日は営業日ではない。納品日は受注日の翌営業日が設定されることが多いので，月曜日に届く品物は，ふだんは土曜日に発注されている。移行期間の土曜日は受注を止めるので，この分をどこかで受け付けなければならない。

納品日は受注日の翌営業日から7日先まで指定できる。したがって土曜日より前，つまり金曜日までに発注してもらえば，納品日を月曜日にした受注として受け付けられる。金曜日の受注データはオンライン運用終了後の出荷指示データ送信処理で物流システムに渡ってから現行基幹システムを止める（表2 データ移行手順）ので，月曜日の出荷指示も移行前に物流システムへ届く。これが「移行期間前の適切なタイミング」である。

30字で「いつまでに」と「何を」の二つを書く。解答例は「金曜日までに，月曜日が納品日の品物を発注すること」で24字。「土曜日に発注しないこと」だけでは，月曜日に受け取りたい得意先がどうすればよいかが伝わらない。

本文の根拠

〔X 社から提供された ERP と分析ツールのバージョンアップに関する情報〕

ERP の現行バージョンと新バージョンとではデータ構造が異なる。そのため，現行バージョンのデータ構造から新バージョンのデータ構造に変更した上でデータを移行する必要がある。

〔X 社から提供された ERP と分析ツールのバージョンアップに関する情報〕

ERP 移行ツールを使用する場合，データ構造の変更は ERP 移行ツールの中で行われるが，コード変換のようにデータの値を加工することはできない。

表1 パターン3

(ア) 現行基幹システムから新基幹システムに移行するデータを抽出し，それらのデータを a する。

パターン3は，データの移行に ERP 移行ツールを使わず，個別のデータ移行プログラムで行う。移行ツールを使えばツールの中で済むデータ構造の変更も，プログラム側で引き受けなければならない。

X社の情報には，現行バージョンと新バージョンとでデータ構造が異なり，「現行バージョンのデータ構造から新バージョンのデータ構造に変更した上で」移行する必要があるとある。パターン3の(ア)〜(ウ)は，(ア)抽出と構造の変更，(イ)コード変換，(ウ)登録の順に並んでいて，(イ)(ウ)に構造の変更が出てこないので，空欄 a がそれに当たる。

解答例は本文の言い回しをそのまま使った「現行バージョンのデータ構造から新バージョンのデータ構造に変更」で30字。空欄の後ろの「する」につながる形にする。「新バージョンのデータ構造に変換」のように短くしても意味は通る。

本文の根拠

〔X 社から提供された ERP と分析ツールのバージョンアップに関する情報〕

ERP 移行ツールを使用する場合，データ構造の変更は ERP 移行ツールの中で行われるが，コード変換のようにデータの値を加工することはできない。

〔情報システム部長から提示された再構築と移行に関する方針〕

コードの統一が必要な理由は，予算管理や連結決算の際に，関連会社の経理担当者が表計算ソフトで A 社のコードに合わせた集計を別々に実施しており，各社から，これらに必要な経理担当者の事務処理の負担が大きいとの意見が以前から寄せられているからである。

パターン2は ERP 移行ツールでデータを移すが，このツールはコード変換のようにデータの値を加工できない。関連会社のコードを A 社のコードに統一できないまま新基幹システムに移ることになる。これが「データ移行時の制約事項」である。

コードが統一されないと何が困るかは，部長の方針に書いてある。関連会社の経理担当者が予算管理や連結決算のたびに表計算ソフトで A 社のコードに合わせた集計をしていて，その事務処理の負担が大きい。再構築後もこれが残るのが「業務上の問題」である。

25字なので「経理担当者の事務処理の負担が大きいこと」（19字）のように，誰の何が問題かを書く。講評のとおり「コードが統一されていない」と書いた答えが多かった。それはシステム上の問題で，問われているのはそれによって業務で起きていることである。

採点講評（IPA）

設問3(1)は，正答率がやや低かった。業務上の問題を問うたにもかかわらず，“各種のコードがA社と関連会社の間で統一されていない”というシステム上の問題を誤って解答した受験者が多かった。業務上の問題とシステム上の問題とを正しく区別して解答することを心掛けてほしい。

本文の根拠

〔現行のシステムと業務の概要〕

新たな切り口によるデータの集計が必要な帳票を定義する場合は，あらかじめ，基となるデータを現行基幹システムから抽出し，必要な集計を行ったデータを現行情報系システム内に保存している。

〔情報システム部長から提示された再構築と移行に関する方針〕

新しいシステムとして再構築する時に関連会社のコードを A 社のコードに統一し，4 社を一斉に移行する。

〔X 社から提供された ERP と分析ツールのバージョンアップに関する情報〕

分析ツールは，新バージョンを導入しても既存の帳票の定義がそのまま使用できる。

現行情報系システムの中にあるのは，現行基幹システムから抜き出して集計したデータである。関連会社の分は，関連会社の古いコードのまま集計されている。一方，新基幹システムでは関連会社のコードを A 社のコードに統一する。

関連会社の情報系データをそのまま移すと，新基幹システムのデータ（新しいコード）と新情報系システムのデータ（古いコード）とでコードが食い違う。そこで，コード変換が済んだ新基幹システムのデータから集計し直して登録する。A 社はもともと A 社のコードなので変換が起きず，そのまま移してよい。分析ツールは帳票の定義をそのまま使えるので，情報系側でコードを直す手段はない。

35字で「関連会社のデータにだけ何が起きるか」を書く。解答例は「関連会社の新基幹システムのデータはコード変換が行われるから」で29字。講評では基幹システムの移行方法の理由（パターン3を選んだ理由など）と混同した答えが多かった。問われているのは情報系システムの移行方法で，A 社と関連会社の違いがどこにあるかに絞る。

採点講評（IPA）

設問3(2)は，正答率が低かった。基幹システムのデータ移行方法に関する理由と混同して解答した受験者が多かった。複数のシステムを取り扱う移行計画の立案では，システムごとに異なる要件や制約条件を正しく理解することが求められる。システムごとのデータ移行方法の違いをよく理解して，正答を導き出してほしい。

本文の根拠

表2 基本施策

③現行のシステムの全ての過去データを，新しいシステムへの移行対象とする。

〔情報システム担当役員から提示された再構築と移行に関する指示〕

過去の経営状況を新たな切り口でも分析できるようにする。

〔現行のシステムと業務の概要〕

新たな切り口によるデータの集計が必要な帳票を定義する場合は，あらかじめ，基となるデータを現行基幹システムから抽出し，必要な集計を行ったデータを現行情報系システム内に保存している。

移行するデータを直近分に絞れば停止期間は短くなる。それでも全ての過去データを移すのは，過去のデータが後で要る指示があるからである。役員の指示に「過去の経営状況を新たな切り口でも分析できるようにする」とある。

新たな切り口の帳票を作るときは，基となるデータを基幹システムから抜き出して集計し直す。情報系システムにある集計済みのデータだけでは，新しい切り口に組み替えられない。過去の経営状況を新しい切り口で見るには，過去の基のデータが新しいシステムに残っていなければならない。

35字なので本文の指示をそのまま引いて「過去の経営状況を新たな切り口でも分析できるようにすること」（28字）とすればよい。「業務への影響を最低限に抑える」などの他の指示とは，全データを移すことが結び付かない。

本文の根拠

〔情報システム部長から提示された再構築と移行に関する方針〕

現行基幹システムの実績データは前月分と当月分だけ更新できる。このことを利用して移行作業によるシステムの停止期間を短縮したい。

表2 データ移行手順

(ア) 事前移行期間にマスターデータと④ある範囲の実績データを移行する。

表2 データ移行手順

現行基幹システム停止直前の 1 週間を事前移行期間とし，この期間はマスターデータの更新運用を停止する。

事前移行期間は現行基幹システムがまだ動いている間である。この間に移したデータが後で書き換わると，移し直しが必要になる。事前に移せるのは，もう変わらないと分かっているデータだけである。

実績データは前月分と当月分しか更新できない。つまり前々月以前の実績データは確定していて，システムの稼働中に移しても後から変わらない。マスターデータは事前移行期間中は更新運用を止めるので，同じく事前に移せる。前月分と当月分は停止後に移す（表2 (イ)）。

範囲は10字なので「前々月以前」（5字）。理由は25字で，範囲の言葉を繰り返して「前々月以前の実績データは更新されないから」（20字）とする。「過去の実績データ」のように境目があいまいな書き方では，前月分が入るかどうかが分からない。

本文の根拠

〔セミナー管理業務の概要〕(1)

企画・講師・運営の三つの担当役割について，それぞれ複数名の担当者を設定でき，一人の担当者が複数の担当役割を兼務する場合もある。

表1 セミナー担当

セミナー担当：セミナーID，担当役割，担当者 ID，リーダーフラグ（注1）。

セミナー担当ファイルの1件は「どのセミナーで，誰が，どの役割を担当するか」を表す。主キーは，この組が1件に決まる属性の組合せである。

一つの担当役割に複数名を設定できるので，セミナーIDと担当役割では1件に決まらない。一人が複数の担当役割を兼務できるので，セミナーIDと担当者IDでも1件に決まらない。三つを組み合わせて初めて1件に決まる。リーダーフラグはその組ごとに値を持つ属性で，キーには入らない。

字数の制限はないが「全て」答えるので，セミナーID，担当役割，担当者IDの三つを漏れなく書く。二つだけでは，本文の「兼務」と「複数名」のどちらかを見落としている。

本文の根拠

〔セミナー管理業務の概要〕(2)

当該セミナーについて同一メールアドレスで申込みが重複しておらず，セミナーの定員に達していない場合は申込みを確定し，受講確定メールを受講申込者へ送付する。

表1 受講申込

受講申込：受講 ID（主キー），セミナーID，氏名，会社名，部署名，役職名，メールアドレス，申込日時。

申込判定（重複）は，同じセミナーに同じ人が二度申し込んでいないかを調べる処理である。業務の概要では，重複を「同一メールアドレス」で判断すると決めている。

確定した申込みは受講申込ファイルにレコードとして残り，このファイルはセミナーIDとメールアドレスを属性に持つ。当該セミナーIDで受講申込ファイルを検索し，入力されたメールアドレスと同じメールアドレスがあればエラーにすればよい。a は受講申込，b はメールアドレス。

字数の制限はない。a はファイル名なので「受講申込」と表1の名前で書く（空欄の後ろに「ファイル」が続く）。b を「氏名」とすると，同姓同名の別人を重複とみなしてしまう。

本文の根拠

表2 申込判定（定員）

申込判定（定員）：当該セミナーID で，受講申込ファイル及びセミナーファイルを検索し，受講申込ファイルのレコード件数がセミナーファイルの定員以上のときは，定員超過でエラーとし，エラーメッセージを表示して処理を終了する。申込判定が OK のときは申込確認画面を表示する。

表2 申込確認

申込確認：申込確認画面の確定ボタンが押されたときは，受講 ID を発行して受講申込ファイルにレコードを作成するとともに受講確定メールを送信する。

定員の判定は申込確認画面を出す前に1回だけ行い，確定ボタンが押されたときには判定しない。判定から確定までの間に，申込者は申込確認画面を見ている時間がある。

この間に別の申込者が確定ボタンを押すと，受講申込ファイルにレコードが増える。それで定員に達しても，先に判定を通った画面は残っていて，確定ボタンを押せば受講申込ファイルにレコードが作られる。こうして定員を超える。設計変更で，確定ボタンが押されたときにもう一度申込判定をするようにしたのはこのためである。

40字で「いつ」「何が起きて」「どうなったか」を書く。解答例は「申込確認画面が表示されている間に他者の申込みが確定されて定員に達した場合」で36字。講評のとおり「他者が先に確定した場合」だけでは足りない。他者が確定しても定員に余裕があれば超過しないので，「定員に達した」まで書く。

採点講評（IPA）

設問2の正答率は平均的であったが，先に他者が申込みを確定した場合とだけ解答し，その結果として定員に達することについては全く触れていない受験者が多かった。どのような場合に定員を超過することがあるのかを考えて，正答を導き出してほしい。

本文の根拠

〔セミナー管理業務の概要〕(4)

なお，受講申込者は多重ログインできない。

〔新システムの概要〕(4)

ログイン時に受講 ID 及びアクセスキーのチェックを行い，受講ファイルにレコードを作成する。

〔新システムの設計変更〕

受講ファイルに，接続フラグという属性を追加し，初期値として“1”を設定する。別途，接続が切れたことを検知した際に接続フラグに“0”を設定するようにする。

今のログインでは受講ファイルにレコードを作る。多重ログインはできないので，同じ受講IDのレコードが既にあればログイン済みとして拒むことになる。接続が切れても受講ファイルのレコードは残るので，再接続しようとすると多重ログインと区別できずに拒まれる。

設計変更では，接続が切れたことを検知したら接続フラグを“0”にする。したがってチェックでは，当該受講IDのレコードがあっても接続フラグが“0”ならエラーにしない。“1”なら今もつながっているので，多重ログインとして拒む。再ログインを通したら，接続フラグを“1”に戻す。戻さないと，その後に別の端末から同じ受講IDで入れてしまう。

チェックは40字で「どのレコードの」「どの値のときに」「どうする」を書く。解答例は「当該受講IDの受講ファイルの接続フラグが“0”のときはエラーとしない。」（35字）。更新処理は30字で「受講ファイルの接続フラグに“1”を設定して更新する。」（26字）。値を“0”“1”まで書くこと。

本文の根拠

表1 セミナー

セミナー：セミナーID（主キー），セミナー名，セミナー内容，開催日時，終了時刻，定員，アンケート URL。

〔新システムの設計変更〕

セミナー終了後に受講申込者に送信するアンケート URL を，受講 ID ごとの個別の URL に変更する。

〔セミナー管理業務の概要〕(5)

また，受講した者（以下，受講者という）はセミナーの評価点を 10 点満点の数字で入力し，受講しなかった者は受講しなかった理由を入力する。

アンケートURLは今はセミナーファイルの属性で，セミナーごとに一つである。これを受講IDごとに変えるなら，受講IDを主キーに持つファイルに移さなければならない。

受講IDが主キーのファイルは受講申込，受講，アンケートの三つある。アンケートは受講しなかった者にも送り，理由を答えてもらう。受講ファイルにはログインした者のレコードしかないので，受講しなかった者のURLを持てない。アンケートファイルは回答してから作られるので，送る前には無い。セミナーの受講申込者全員のレコードがあるのは受講申込ファイルである。

字数の制限はない。属性は「アンケートURL」，移す先は「受講申込」と表1の名前で書く。講評のとおり移す先を誤った答えが散見された。受講IDを持つファイルならどれでもよいわけではなく，送る相手全員のレコードがあるかどうかで選ぶ。

採点講評（IPA）

設問3(2)は，正答率が低かった。移す先のファイル名を誤って解答した受験者が散見された。設計変更前のデータ設計を把握した上で，追加要望を満たすことができる適切な移動先のファイルを導き出してほしい。

本文の根拠

〔指摘及び追加要望〕

ここで，申込率は定員に対する受講申込者数の割合，受講率は受講申込者数に対する受講者数の割合，平均評価点はアンケートに回答した受講者の評価点の平均点を示す。

表1 注記

注3) 受講者の評価点は 1 から 10 の整数であり，受講しなかった者の評価点は 0 を設定する。

表3

平均評価点（点）： f ÷アンケートファイルで受講有無が“有”のレコード件数。

三つの項目の定義を表1の属性に置き換える。申込率は受講申込者数÷定員なので，c は「セミナーファイルの定員」。受講率は受講者数÷受講申込者数なので，d は受講者数，e は受講申込者数である。受講者はログインした者で，受講ファイルに受講IDごとに1件できる（受講IDが主キーなので再ログインしても増えない）。d は「受講ファイルのレコード件数」，e は「受講申込ファイルのレコード件数」。

平均評価点は，回答した受講者の評価点の合計÷その人数である。除数はもう表3にある。f は評価点の合計だが，受講しなかった者の評価点は0なので，受講有無で絞らずにアンケートファイルの評価点を全部足しても合計は変わらない。f は「アンケートファイルの評価点の合計」でよい。

各20字以内で，表3にならってファイル名と属性の名前を使う。解答例は c 11字，d 13字，e 15字，f 16字。d を「アンケートファイルで受講有無が“有”のレコード件数」とすると，アンケートに答えなかった受講者が数えられず，受講者数にならない。

本文の根拠

〔現在の業務と現行システムの概要〕

L 社では，全てのシステムで遵守が求められている情報セキュリティ規則で，外部信用機関との接続は特定の端末（以下，外信端末という）に限定しており，社内のネットワーク及びシステムとの接続を許可していない。

〔新システムへの要望〕

(e) 外部信用機関から情報を取得する機能を設けて，新システムで確認できるようにしてほしい。

「L社として不適合」という言い方から，利用部門の都合ではなく会社の決まりに反する要望を探す。L社には全てのシステムが守らなければならない情報セキュリティ規則がある。

この規則では，外部信用機関との接続は外信端末に限り，社内のネットワークやシステムとはつながせない。(e)は新システムに外部信用機関から情報を取る機能を設けるというもので，新システムを外部信用機関に接続することになり，規則に反する。そのため表1にも外部信用機関とつなぐ機能は無い。

要望は記号で「(e)」。理由は40字で「どの規則が」「何を限っているか」を書く。解答例は「情報セキュリティ規則で外部信用機関との接続は外信端末に限定しているから」で35字。「セキュリティ上危険だから」のような一般論ではなく，本文の規則に結び付ける。

本文の根拠

〔現在の業務と現行システムの概要〕

申込みには，新規申込と契約変更申込の二つの種別（以下，申込種別という）があり，申込種別の単位に異なる FAX 番号を設定して，金融機関と申込種別の単位で担当者を割り当てている。

〔新システムの方針〕

FAX サーバからは，ヘッダー情報として送信日時，送信元 FAX 番号，受信日時及び受信 FAX 番号，明細情報として申込書類イメージデータを取得する。

表1 金融機関管理

金融機関の情報は，金融機関コード，金融機関名，支店コード，支店名，電話番号，FAX 番号，金融機関用ポータルサイト ID 及びパスワードである。

空欄の後ろで「担当者を割り当て」ている。担当者は「金融機関と申込種別の単位」で割り当てるので，FAXのヘッダー情報から金融機関と申込種別の二つを導き出せればよい。

金融機関は，送ってきた側の番号で分かる。金融機関管理は金融機関ごとにFAX番号を持っているので，ヘッダーの送信元FAX番号から金融機関が引ける。申込種別は，L社側の受ける番号で分かる。L社は申込種別ごとに違うFAX番号を設定しているので，受信FAX番号から申込種別が決まる。

字数の制限はない。a は「送信元FAX番号」，b は「金融機関」，c は「受信FAX番号」，d は「申込種別」と本文の語で書く。送信元と受信を逆にすると，申込種別の番号から金融機関を探すことになり成り立たない。

本文の根拠

〔現在の業務と現行システムの概要〕(3)

L 社は，保証料が全額入金されていること，及び金融機関から保証契約書類を受領していることを確認し，対応する保証案件の契約状態を“実行中”にする。

表1 保証料管理

突合した結果を確認し，保証料が全額入金されている場合，当該保証案件の入金状態を“入金済”に更新する。

表1 書類管理

保証契約書類を金融機関から受領した際，当該保証案件の書類受領状態を“受領済”に更新する。

現行の業務で“実行中”にする条件は二つある。保証料が全額入金されていることと，保証契約書類を受領していることである。実行管理の「ある条件」はこの二つがそろったことを指す。

新システムでは，この二つをそれぞれ保証案件の状態として持たせた（新システムの方針）。入金状態を“入金済”にするのは保証料管理，書類受領状態を“受領済”にするのは書類管理である。実行管理はこの二つの状態を見て契約状態を“実行中”に変える。

字数の制限はない。「全て」答えるので保証料管理と書類管理の二つを書く。契約状態を“実行待ち”にする審査管理は，実行管理が対象を選ぶ前提であって，「ある条件」を設定しているわけではない。

本文の根拠

〔現在の業務と現行システムの概要〕(4)

完済された融資があった場合，対応する保証案件の契約状態を“終了”にして，外部信用機関に保証完了の報告をする。

〔現在の業務と現行システムの概要〕

外部信用機関との接続は特定の端末（以下，外信端末という）に限定しており，社内のネットワーク及びシステムとの接続を許可していない。

表1 融資残高管理

融資残高がゼロになった保証案件の一覧を帳票に出力する。

融資残高がゼロになった保証案件は完済された案件である。現行の業務では，完済されたら契約状態を“終了”にし，外部信用機関に保証完了の報告をしている。新システムの融資残高管理も“終了”への更新はするが，外部信用機関への報告はしない。

新システムは外部信用機関とつながれない（設問1のとおり情報セキュリティ規則で外信端末に限られている）。そこで報告は担当者が外信端末から行うことになり，その対象を知るために完済した保証案件の一覧を帳票に出す。

25字なので「外部信用機関に保証完了の報告をするため」（19字）のように，帳票を見て担当者が何をするかを書く。「完済した案件を確認するため」だけでは，確認して何をするのかという業務の観点が抜ける。

本文の根拠

〔融資保証の概要〕(5)

諸事情で顧客の借入金の返済が滞った場合，金融機関からの請求に基づき，L 社が借入金残高の全額を顧客に代わって金融機関に立替払をし，その後，顧客は L 社に返済する。

〔現在の業務と現行システムの概要〕(4)

融資残高レポートには，全ての保証案件が代位弁済になった場合に L 社が金融機関に支払う金額を記載する。

表1 融資残高管理

金融機関から送付された残高データで，契約状態が“実行中”の保証案件の融資残高を更新する。

代位弁済では，L社が借入金残高の全額を立替払する。全ての保証案件が代位弁済になった場合の支払額は，いま保証している案件の融資残高を合計したものになる。

どの案件が「いま保証している」ものかは契約状態で分かる。“実行中”は融資が実行されて保証が続いている案件で，融資残高もこの状態の案件について更新されている。“実行待ち”はまだ融資が実行されていない，“終了”は完済済み，“代弁”はすでに代位弁済して債権管理システムに移った，“受付中”“無効”は保証が始まっていない。どれも今後の立替払の対象にならない。

35字で「どの状態の」「何を」「どうする」を書く。解答例は「保証案件の契約状態が“実行中”である融資残高を合計する。」で28字。講評では正答率が低かった。“代弁”を含めると，すでに支払った分を二重に数える。

採点講評（IPA）

設問4(2)は，正答率が低かった。現行業務と融資保証の概要を踏まえた融資残高レポートに記載する内容を十分に理解できていないと思われる解答が散見された。現行業務と“契約状態”の示す状況を正しく理解した上で，支払う金額を導き出してほしい。

本文の根拠

〔現在の業務と現行システムの概要〕(1)

商品ごとに必要な申込書類が異なっており，担当者は必要な申込書類とその内容を業務マニュアルで確認している。

〔新システムへの要望〕

(d) 業務マニュアルを用いて実施している，必要な申込書類がそろっているかどうかのチェックを新システムで行ってほしい。

〔現在の業務と現行システムの概要〕(2)

また，顧客の売上高，信用格付及び商品ごとの保証料の算出に用いる利率から保証料を計算し，現行システムに入力する。

〔新システムへの要望〕

(f) 保証審査業務で必要な保証料を新システムで算出してほしい。

要望を一つずつ見て，これまで担当者が手元で扱っていた「商品ごとに違うもの」を新システムに持たせる必要がないかを探す。本文で「商品ごとに」と書かれているのは二か所ある。

一つは申込書類。商品ごとに必要な申込書類が違い，今は担当者が業務マニュアルで確かめている。要望(d)でこのチェックを新システムに任せるので，商品ごとのチェックのルールが要る（表1 保証案件管理の「申込書類のチェックのルール」）。もう一つは保証料。今は担当者が商品ごとの利率を使って計算し，結果を入力している。要望(f)で新システムが算出するので，商品ごとの利率が要る。

30字で二つとも書く。解答例は「申込書類のチェックのルールと保証料の算出に用いる利率」で26字。講評のとおり一つの要望に対応する項目だけを答えた受験者が多かった。「全て」とあれば，一つ見つけても他の要望を見直す。

採点講評（IPA）

設問5は，正答率が低かった。新システムへの要望のうちの一つに対応している項目だけを解答し，他の要望を考慮していない受験者が多かった。全ての要望を正しく理解した上で，正答を導き出してほしい。

本文の根拠

表1 顔認証端末

事業者のシステムに対して，認証結果として識別情報を送信する。

表1 事業者のシステム

顔認証端末から認証結果を受信し，認証された識別情報から利用者を特定して，様々なサービスを提供する。

〔本システムの要件検討〕(1)

本システムは，宿泊予約などを登録，管理するシステム（以下，会員管理システムという），及び提携する事業者のシステムと連携して動作する必要がある。

顔認証端末は識別情報を受け取るだけで，誰が宿泊予約をしているかは知らない。チェックインを完了させるには，予約を管理しているシステムに識別情報を渡す必要がある。

表1の顔認証端末は「事業者のシステムに対して，認証結果として識別情報を送信する」。ホテル事業者にとっての事業者のシステムは，宿泊予約を登録・管理する会員管理システムである。会員管理システムは識別情報（会員番号）から利用者を特定し，予約を確かめてチェックインを済ませる。

字数の制限はない。空欄の後ろの「することで」につながるよう「会員管理システムに送信」とする。「事業者のシステムに送信」でも仕組みは同じだが，この場面の相手は会員管理システムである。

本文の根拠

〔開発を打診された本システムの主な機能〕

チェックイン完了後，宿泊ルームの開錠やホテル内施設の利用など，各ホテルが提供する様々なサービスの利用が顔認証だけで可能になる。

〔本システムへの顔認証基盤の適用性検討〕

以降，ホテルの利用者がホテル内施設を利用する際，同様に顔認証端末で顔を撮影すると， b であるかどうかを判定し，ホテル内施設でのサービスの可否を決定する。

顔認証で分かるのは，その人の識別情報（会員番号）だけである。会員であってもホテル内施設を使えるとは限らないので，会員管理システムが別の確認をしてサービスの可否を決める。

本システムの機能では，ホテル内施設などのサービスが顔認証だけで使えるのは「チェックイン完了後」である。直前の手順でチェックインを会員管理システムに記録しているので，会員管理システムは識別情報から，その人がチェックインを済ませた宿泊客かどうかを確かめられる。

20字で，空欄の後ろの「であるかどうか」につながる名詞句にする。解答例は「チェックイン完了後のホテルの利用者」で17字。「会員であるかどうか」では，予約もしていない会員にまで施設を使わせることになる。

本文の根拠

〔本システムの要件検討〕(1)

ホテルの利用者が事前に顔情報を登録する際に，運転免許証，パスポート，マイナンバーカードなど，利用者の顔写真付きの公的証明書との照合によって，本人であることを確認する手段（以下，本人確認という）を提供する。

表1 利用者のスマホ

顔の撮影後，利用者の顔写真付きの公的証明書も撮影し，顔認証機能を使用してアプリが本人確認を行う。

本人確認は，顔情報を登録しようとしている人が本人であることを，顔写真付きの公的証明書との照合で確かめる手段と定義されている。何と何を照合するかを答える。

表1では，アプリは顔を撮影した後に公的証明書も撮影し，「顔認証機能を使用して」本人確認を行う。つまり，証明書の顔写真と，いま撮影した利用者の顔とを顔認証で照らし合わせ，同じ人かどうかを見る。近距離無線通信で証明書の情報を読み取る方法も書かれているが，これも証明書の情報を使って同じ照合をするものである。

30字で「何と何を」「どうするか」を書く。解答例は「公的証明書の顔写真と撮影した顔画像とで顔認証を行う。」で26字。「公的証明書を撮影する」だけでは，撮影した証明書を何に使うのかが抜ける。

本文の根拠

表1 利用者のスマホ

利用者が事業者のシステムにスマホでサインイン後，顔を撮影すると，アプリは顔情報を取得し，事業者のシステムに送信する。

表1 事業者のシステム

利用者のスマホからの要求で，識別情報及びスマホから送信された顔情報を顔認証サーバに送信する。

表1 顔認証サーバ

利用者のスマホから送信された顔情報をクラウドサービスのデータベースに登録，管理する。

表1 顔認証サーバ

事業者のシステムからの要求で，顔情報と識別情報とを関連付ける。

顔情報は，利用者がスマホから先に顔認証サーバへ登録している（本人確認付き）。事業者のシステムから届くのは，サインインした利用者の識別情報と，そのとき撮影した顔の顔情報である。この顔情報は登録済みのものと同じではないので，そのまま保存しても関連付けにならない。

顔認証サーバは，届いた顔情報で顔認証を行い，登録済みの顔情報のどれと一致するかを探す。一致したら，その登録済みの顔情報に事業者の識別情報を関連付ける。こうすれば，本人確認を済ませた顔情報に，事業者ごとの識別情報がぶら下がる。

40字で「認証」と「関連付け」の二段を書く。解答例は「受信した顔情報で認証を実施し，一致した顔情報に識別情報を関連付ける。」で34字。講評のとおり正答率が低かった。「顔情報と識別情報を関連付ける」だけでは表1の言い換えで，どの顔情報に付けるのかが書けていない。

採点講評（IPA）

設問2(2)，(3)は，顔情報と識別情報の関連付けの方法，及び識別情報の使われ方について出題したが，正答率が低かった。特に(3)は，具体的な目的が記述できていない解答が散見された。識別情報の構築方法や運用方法を通して，顔認証基盤が様々な事業者への適用を可能にしていることを理解してほしい。

本文の根拠

表1 顔認証端末

顔認証端末を複数の事業者で共有し，対応する事業者のシステムと連携することが可能である。

表1 顔認証サーバ

顔認証端末から受信した顔情報から顔認証を行い，認証結果として事業者に関連付く識別情報を顔認証端末に送信する。

〔本システムの開発方針〕(3)

識別情報の例としては，ホテル事業者であれば，会員管理システムにおける会員番号が該当する。

識別情報は事業者ごとに違う。ホテル事業者なら会員番号，提携する事業者ならその事業者の番号で，一人の利用者に複数の識別情報が関連付いている。顔認証だけでは「誰か」は分かっても，どの事業者の識別情報を返せばよいかは決まらない。

顔認証サーバは認証結果として「事業者に関連付く識別情報」を返す。顔認証端末は複数の事業者で共有できるので，端末がどの事業者のために認証しているかをサーバに伝えなければならない。そのために顔情報と一緒に事業者の情報を送る。

20字なので「当該事業者の識別情報を特定するため」（17字）のように，何を特定するためかを書く。講評では具体的な目的が書けていない答えが散見された。「事業者を識別するため」では，事業者を識別して何をするのかが抜ける。

採点講評（IPA）

設問2(2)，(3)は，顔情報と識別情報の関連付けの方法，及び識別情報の使われ方について出題したが，正答率が低かった。特に(3)は，具体的な目的が記述できていない解答が散見された。識別情報の構築方法や運用方法を通して，顔認証基盤が様々な事業者への適用を可能にしていることを理解してほしい。

本文の根拠

〔本システムへの顔認証基盤の適用性検討〕

具体的には，チェックインを予定しているホテルの利用者の認証に必要な情報を，会員管理システムからの要求によって，毎日，顔認証サーバから顔認証端末にダウンロードし，顔認証端末だけでローカルな認証を行うなどの機能である。

表1 顔認証端末

カメラを搭載した汎用タブレット端末であり，利用者が顔を撮影すると，顔情報を取得して，事業者の情報とともに顔認証サーバに送信し，認証結果として識別情報を受信する。

表1 顔認証端末

事業者のシステムに対して，認証結果として識別情報を送信する。

エッジ認証は，顔認証サーバがしていた仕事を顔認証端末だけで行う。サーバの仕事は，撮影した顔を登録済みの顔情報と照合し，一致した人の識別情報を返すことだった。端末がこれを自分でやるのに要るものを数える。

照合するには，比べる相手の顔情報が要る。照合できたら，事業者のシステムに認証結果として識別情報を送るので，その人の識別情報も要る。この二つがあれば，サーバに問い合わせずにチェックインまで進められる。

字数の制限はない。①「顔情報」②「識別情報」の二つ。事業者の情報は端末自身が知っている（事業者の情報とともにサーバに送っている）ので，ダウンロードは要らない。

本文の根拠

〔本システムの要件検討〕(2)

本システムに登録可能な顔情報の件数は，ホテルチェーンへの全展開や提携する事業者の拡大などを考慮し，最大 100 万人分を想定する。

表1 顔認証端末

カメラを搭載した汎用タブレット端末であり，

〔本システムへの顔認証基盤の適用性検討〕

具体的には，チェックインを予定しているホテルの利用者の認証に必要な情報を，会員管理システムからの要求によって，毎日，顔認証サーバから顔認証端末にダウンロードし，顔認証端末だけでローカルな認証を行うなどの機能である。

顔認証サーバには最大100万人分の顔情報がある。顔認証端末は汎用タブレット端末なので，これを全部持って照合することはできない。エッジ認証が役に立つのは，照合の相手を少人数に絞れる場面に限られる。

本文の具体例がチェックインである。その日にチェックインを予定している利用者は会員管理システムの予約から分かり，その人たちの情報だけを毎日ダウンロードすればよい。講評は，チェックインを完了した利用者（ホテル内施設を使う宿泊客）も同じように絞り込める例に挙げている。

40字で「具体例」と「どのような場合か」の両方を書く。解答例は「チェックインを予定しているホテルの利用者など，認証対象を絞り込める場合」で35字。講評のとおり，具体例だけ，又は一般論だけの答えが散見された。「サーバの負荷が高い場合」では，端末が情報を持ちきれないという制約に触れていない。

採点講評（IPA）

設問3(2)は正答率が低かった。具体例のない解答や，具体例だけで，どのような場合に使用すべきかが不明な解答が散見された。エッジコンピューティングは，リアルタイム性の確保や負荷分散の目的で導入されるが，一般にエッジコンピューティング用のデバイスは，ハードウェア制約から限られた情報しか内部に保持できない場合が多い。本システムでは，チェックインを予定している利用者やチェックインを完了した利用者など，認証対象を絞り込むことで，顔認証端末内部に保持する情報を限定し，エッジ認証を適用可能としていることを理解してほしい。

本文の根拠

〔本システムの要件検討〕(2)

ホテルの利用者の顔情報などの個人情報を扱うので，その保管や通信に高度なセキュリティが要求される。

表1 顔認証端末

カメラを搭載した汎用タブレット端末であり，

エッジ認証をする顔認証端末は，ダウンロードした顔情報と識別情報を中に持っている。これはホテルの利用者の個人情報で，保管に高度なセキュリティが求められている。

顔認証端末は汎用タブレット端末で，持ち運べる。紛失や盗難に遭えば，中の個人情報が第三者の手に渡るおそれがある。手元に端末が無くても，遠隔からの指示で消去できれば漏えいを防げる。

30字で「どんなときに」「何を」消すかを書く。解答例は「紛失などの場合に，利用者の個人情報を消去するため」で24字。「セキュリティのため」だけでは，なぜ遠隔から消す必要があるのか（端末が手元に無い場面）が伝わらない。