令和4年度 春期 午後Ⅰ

本文の根拠

〔カスタマサービスの現状〕

IVR 経由で着信した電話は，コンタクトセンタ内にある構内交換機（以下，PBX という）でオペレータの座席に設置されている電話機に分配され，つながる仕組みになっている。

表2 (e)

育児，介護などで，フルタイムで出社して働くことが難しいオペレータもおり，在宅かつ柔軟な勤務時間で働きたいというニーズが高まっている。

表3 クラウド型 PBX

オペレータが利用する電話機を PC 上で電話対応できるソフトフォンに変更し，PC からインターネットを経由して電話の発着信，通話などができるようにする。

今の電話は，コンタクトセンタ内にあるPBXからオペレータの座席の電話機に分配される。電話を受けるには，センタに出社してその座席に着くしかない。クラウド型PBXは電話機をPC上のソフトフォンに替え，インターネット経由で発着信できるようにする。PCとインターネットがあれば，センタの外でも電話を受けられる。

勤務形態に関わる課題は表2の(e)にある。オペレータの人材確保が難しい一方で，育児や介護でフルタイムの出社が難しく「在宅かつ柔軟な勤務時間で働きたい」というニーズが高まっている。クラウド型PBXはこの「在宅」の部分に応える。在宅で働けるようになれば，出社できない人も採用でき，人材確保にもつながる。

25字なので「在宅で働ける」ことを目的の形で書く。解答例は「オペレータが在宅でも働けるようにするため」で20字。「電話対応をPCでできるようにする」だけでは機能の説明で，設問が問う勤務形態の改善になっていない。

本文の根拠

〔コンタクトセンタシステム構築後の運用〕

稼働当初は，オペレータの業務を補完する目的で，急増しやすい問合せ，かつそれぞれの機能の特徴で対応できる見込みが高い問合せを対象にする。一方で，新商品購入者の声を直接聞きたい狙いもあり，顧客が使用中の商品に関する問合せは，稼働当初は対象にしない。

表2 (a)

新商品の発売が毎月数回あり，発売時にテレビなどのメディアで取り上げられると，商品購入前の検討，購入方法及びオンラインストアでの購入手続に関する問合せが急増し，対応が大変になる。

表2 (b)

オンラインストアの会員限定のセール・キャンペーンが始まると，会員情報に関する問合せが急増し，1 件ごとの対応は簡単であるが，1 日中電話が鳴りやまない。

表1 購入方法の情報収集

店舗情報を参照し，明確に回答できるものが多い。

表1 会員情報の確認

本人確認を行うことで，手続，回答できるものが多い。

表3 AI チャットボット

顧客からの質問に対して AI が FAQ を参考に自動回答したり，定型的な手続を実行したりする。

稼働当初の対象は「急増しやすい問合せ，かつそれぞれの機能の特徴で対応できる見込みが高い問合せ」で，顧客が使用中の商品に関する問合せは外す。この二つの条件と一つの除外を表1の五つの行動に当てはめる。

急増しやすいのは，表2(a)の商品購入前の検討・購入方法・オンラインストアでの購入と，(b)の会員情報である。このうち機能で対応できるかを表1の特徴で見る。購入方法の情報収集は「店舗情報を参照し，明確に回答できる」ので自動回答に向く。会員情報の確認は「本人確認を行うことで，手続，回答できる」ので，定型的な手続を実行できるAIに向く。商品購入前の検討は顧客ごとに気になる点が「多岐にわたる」ので自動回答に向かず，オンラインストアでの購入は「オンラインストア上で処理できない」ものが多い。購入した商品の使用は定型的に答えられるが，使用中の商品に関する問合せなので除外される。

答えは「購入方法の情報収集，会員情報の確認」。講評によると「購入した商品の使用」を含めた答えが多かった。表1の特徴だけを見ると最も自動回答に向いて見えるが，本文の運用方針で稼働当初は対象外とされている。表だけでなく本文の条件まで当てはめる。

採点講評（IPA）

設問1(2)は，正答率が低かった。AIチャットボット及びボイスボットで対応可能な問合せ内容を，表1の内容を読んだだけで選択し，“購入した商品の使用”を解答に含めていた受験者が多かった。本文中に記載されている稼働当初の対象範囲をよく読み，サービス導入の方針をよく理解して，正答を導き出してほしい。

本文の根拠

表3 オムニチャネル

有人対応ではないサービスは 24 時間対応可能とする。

表3 AI チャットボット

AI チャットボットで対応困難な場合，顧客は有人チャットを起動できる。ただし，オペレータが繁忙の場合は“お待ちください”と表示する。また，ある条件のときは，有人チャットを起動できない設定にする。

〔コンタクトセンタシステム構築後の運用〕

オペレータの勤務時間帯は，従来どおりの日中だけとする。

AIチャットボットは有人対応ではないので24時間動く。一方，有人チャットに答えるのはオペレータで，その勤務時間帯は従来どおり日中だけである。夜間にAIチャットボットから有人チャットを起動できると，答える人がいないのに顧客を待たせることになる。だから勤務時間帯の外では起動できないようにする。

繁忙の場合は「お待ちください」と表示すると別に書かれているので，「オペレータが忙しいとき」は答えにならない。忙しくても勤務中ならいずれ応答できるが，勤務時間外は待っても応答がない。設問が「コンタクトセンタの運用を踏まえて」と言っているのは，運用の節の勤務時間帯の記述を指している。

20字なので「勤務時間帯以外」を条件の形にする。解答例は「オペレータの勤務時間帯以外のとき」で16字。「夜間」と書いても意味は近いが，本文の語は「勤務時間帯」である。

本文の根拠

表3 コールバック

電話がつながるまでそのまま待つか，オペレータからの電話の折返しを要求するかを IVR 上で顧客が選択できるようにする。

表2 (c)

問合せが急増すると，オペレータに電話がつながるまでに長時間待たせることになり，顧客からのクレームにつながっている。

表2 (b)

会員情報に関する問合せが急増し，1 件ごとの対応は簡単であるが，1 日中電話が鳴りやまない。

コールバックは，電話がつながるまで待つか，オペレータからの折返しを求めるかを顧客が選べる仕組みである。折返しを選んだ顧客は電話口で待たなくてよい。これが直接解決するのは，電話がつながるまで長時間待たせてクレームになっている(c)である。

(a)(b)も問合せの急増を扱っているが，(a)は急増で対応が大変になること，(b)は電話が鳴りやまないことが課題で，どちらも問合せの件数の問題である。コールバックは件数を減らさない（折り返す分の対応は残る）。件数を減らすのはAIチャットボット・ボイスボットやFAQの役目である。(f)の出勤人数の調整もコールバックでは解決しない。

記号で一つ答える設問。「直接的な」とあるので，待ち時間そのものを課題にしている行を選ぶ。解答例は「(c)」。

本文の根拠

表2 (i)

顧客からの問合せの情報は，コンタクトセンタ内で解決できない内容がエスカレーションされることはあるが，それ以外は特に共有されていない。商品の改善のために，他の情報も有効に活用したい。

表3 キーワード分析

テキスト化した通話内容からキーワード分析を行い，商品ごとにどのような問合せ，クレームなどが多いのかを自動で統計をとり，分析できるようにする。

〔新たなコンタクトセンタシステムの構築〕

ナレッジベース及びキーワード分析の機能は，商品事業部の社員も利用できることにした。

商品事業部の社員の課題は表2の(i)にある。問合せの情報はエスカレーションされたもの以外は共有されておらず，「商品の改善のために，他の情報も有効に活用したい」。キーワード分析は，通話内容から商品ごとにどのような問合せやクレームが多いかを統計で出せる。商品事業部の社員がこれを使えば，問合せやクレームの傾向を商品の改善に生かせる。

つまり理由は機能の説明ではなく，その機能で何をしたいかである。キーワード分析で「商品ごとの問合せ，クレームが分かる」のは手段で，目的は「商品の改善につなげる」ことである。この目的は(i)に商品事業部の社員自身の言葉で書かれている。

35字に「問合せ・クレームの内容」と「商品の改善」の両方を入れる。解答例は「商品の問合せ，クレーム内容などを商品の改善につなげたいから」で29字。講評によると，表3の機能概要をなぞっただけの答えが散見された。何のために使わせるのかまで書く。

採点講評（IPA）

設問1(5)は，正答率は平均的であったが，単に表3のキーワード分析の機能概要に記載された内容だけを解答するものが散見された。商品事業部の社員が利用できることにした理由を問うているので，機能でできることだけでなく，何の目的に機能を利用させるのかを理解した上で解答してほしい。

本文の根拠

〔コンタクトセンタシステム構築後の運用〕

有人チャットは，会話型のコミュニケーションができる良さがあるものの，突然会話が途切れて反応がなくなるなどの特殊なコミュニケーション手段になる。

表3 有人チャット

一人のオペレータが複数のチャットを起動し，同時に複数の顧客との対応ができるようにする。

〔コンタクトセンタシステム構築後の運用〕

ビデオ通話と電話は，通話だけか，映像も交えた対応かという違いだけで，対応処理がほぼ同じであるので，同じ体制で対応する。

表3の有人チャットは，一人のオペレータが複数のチャットを起動し，同時に複数の顧客と対応できるようにする機能である。電話やビデオ通話は一人の顧客と話している間は他の顧客に対応できないが，チャットなら相手の返信を待つ間に別の顧客に答えられる。これが下線①の「効率的に顧客対応を行う」の中身である。

専任にする理由もここにある。チャットは突然会話が途切れて反応がなくなるなど，電話とは違う特殊な手段である。電話やビデオ通話と兼務させると，通話中はチャットを並行して進められず，同時に複数の顧客と対応するという利点が生きない。そこで電話・ビデオ通話と分けて，チャット専任にする。

25字で「一人」「同時に」「複数の顧客」を入れる。解答例は「一人のオペレータが同時に複数の顧客と対応する」で22字。「チャットに集中する」だけでは，何が効率的なのかが書けていない。

本文の根拠

表2 (h)

大規模災害時，感染症の拡大時などには，特定のコンタクトセンタを一時的に閉鎖せざるを得ないケースが想定され，その際にカスタマサービスの継続が危ぶまれる。

表3 コンタクトセンタ間の着信自動分配

国内 3 拠点のコンタクトセンタの運用状況及びオペレータの稼働状況を総合的に管理し，問合せ内容だけでなく，運用状況及び稼働状況を見ながら適切に電話の振分けを行えるようにする。

〔コンタクトセンタシステム構築後の運用〕

問合せ内容に応じて，国内 3 拠点のコンタクトセンタに振り分けるのはこれまでと同じ対応とするが，

振り分けは今までどおり問合せ内容で決めるが，状況によっては柔軟に振り分ける。柔軟に振り分けるべき状況を，表2の課題から探す。設問は一つ目として「特定のコンタクトセンタへの問合せが急増して，対応しきれなくなりそうな状況」を挙げている。これは(a)(b)の問合せの急増に当たる。

もう一つは(h)である。大規模災害や感染症の拡大で特定のコンタクトセンタを一時的に閉鎖せざるを得ないと，内容に応じてそのセンタに振り分けられる問合せを受ける人がいなくなる。表3のコンタクトセンタ間の着信自動分配は，運用状況を見ながら振り分けを変えられるので，閉鎖したセンタの分を他の2拠点に回せる。そのためにオペレータに担当外の内容のトレーニングを行う。

30字で(h)の状況を書く。解答例は「特定のコンタクトセンタを一時的に閉鎖せざるを得ない状況」で27字。「災害時」だけでは状況として足りない。災害で何が起きるか（センタの閉鎖）まで書く。

本文の根拠

〔カスタマサービスの現状〕

また，A 社では，四半期に一度，問合せ内容の統計をとり，分析して，よくある問合せ内容について，A 社の Web サイト上に，FAQ として掲載し，情報発信している。

表2 (g)

新商品の発売時は，当該商品の FAQ が掲載されていないので，電話及び Web フォームからの問合せが急増する。FAQ を見れば分かるような簡単な問合せも多いので，FAQ を早く掲載したい。

〔コンタクトセンタシステム構築後の運用〕

コンタクトセンタの管理者及び商品事業部の社員がナレッジベースの機能を使い，随時 FAQ の作成・更新を行い，公開する。

今のFAQは四半期に一度，問合せの統計を分析して掲載している。これでは新商品の発売時にFAQが間に合わない。表2(g)のとおり，発売時は当該商品のFAQが無いので問合せが急増し，その中にはFAQを見れば分かる簡単な問合せも多い。

随時FAQを作成・更新して公開できれば，新商品の発売に合わせてFAQを出せる。顧客はFAQで自己解決できるので，簡単な問合せが電話やWebフォームに押し寄せるのを防げる。狙いは二段になっている。随時作れることでFAQを早く掲載できること，そして公開したFAQで簡単な問合せの急増を防ぐことである。

30字に「新商品発売時」と「簡単な問合せが急増しないようにする」を入れる。解答例は「新商品発売時に，簡単な問合せが急増しないようにするため」で27字。講評によると，FAQを早く掲載できることと問合せの急増を防ぐことのどちらか一方しか書いていない答えが多かった。「FAQを早く掲載するため」で止めると，何のために早く掲載するのかが抜ける。

採点講評（IPA）

設問2(3)は，正答率が低かった。“随時FAQの作成・更新”をできるようにすることでFAQを早く掲載できるようにしたことと，その“FAQを公開”することで簡単な問合せの急増を防ぐ効果を期待したことの両方に気付いてほしかったが，いずれか一方にしか気付いていないと思われる解答が多かった。新しいサービス機能の導入とともに，運用を見直したことによる狙いをしっかり理解してほしい。

本文の根拠

〔現行の製造及び品質管理の概要〕（ア）

曜日，便，及び品目ごとに検査担当者を 1 人ずつ割り当てている。しかし，特定の製造日と便における検査担当者の都合などによって，担当する一部又は全部の品目の品質検査を実施できない場合がある。その場合，検査責任者はその製造日，便の製造指示が出る直前に，品目ごとに他の検査担当者への変更を行う。

〔新システムへの要望〕

一度変更した検査担当者の内容は，再度変更しない。

表2 品質検査指示作成

社員コードは検査担当者マスタを参照し格納する。該当する検査担当者変更ファイルのレコードが存在する場合は，検査担当者変更ファイルの内容を優先し格納する。

表1 検査担当者マスタ

検査担当者マスタ：曜日，便コード，品目コード（ここまでが主キー），社員コード。

検査担当者変更ファイルは，いつの，どの便の，どの品目の担当者を誰に変えるかを記録する。本文によると，変更は「特定の製造日と便」について「品目ごとに」行う。したがってレコードを一意に決めるのは製造日・便・品目で，表1の属性名では製造日，便コード，品目コードになる。社員コードは変更先の担当者で，キーではない属性である。

検査担当者マスタの主キーは曜日，便コード，品目コードだが，変更ファイルでは曜日を製造日に置き換える。マスタは毎週繰り返す割当てなので曜日で足りるが，変更は特定の日だけに効かせるものだからである。品質検査指示作成は製造日・便・品目のレコードがあればマスタより優先するので，この三つで引ければよい。また「一度変更した検査担当者の内容は，再度変更しない」ので，同じ製造日・便・品目に変更履歴が複数並ぶことはなく，連番などをキーに足す必要もない。

属性名で「全て」答える。解答例は「製造日，便コード，品目コード」。「便」ではなく表1の属性名「便コード」で書く。曜日を入れると特定の日の変更を表せない。

本文の根拠

〔新システムへの要望〕

検査担当者の変更時に，変更する製造日，便における各検査担当者の作業負荷を確認したい。そのために，作業負荷の目安となる品質検査の実施見込回数（以下，見込回数という）を参照したい。このとき，変更元となる検査担当者については品目ごと，変更先の検査担当者については検査担当者ごとの見込回数を参照したい。

表2 検査担当者変更

指定した変更元検査担当者の社員コードをもつレコードから，品目コードごとのレコード数を集計し表示する。また，他の検査担当者の社員コードをもつレコードから，社員コードごとのレコード数を集計し表示する。

表2 検査担当者変更

その結果を基にどの品目を誰に変更するのかを決定し

(D)が表示するのは，変更元の担当者については品目ごとのレコード数，他の担当者については担当者ごとのレコード数である。これは要望にある「変更元となる検査担当者については品目ごと，変更先の検査担当者については検査担当者ごとの見込回数」そのものである。レコード1件がロット1回分の品質検査なので，レコード数が見込回数になる。

要望は，見込回数を参照して「各検査担当者の作業負荷を確認したい」としている。検査責任者は(D)の表示で作業負荷を確かめ，その結果を基にどの品目を誰に回すかを決める。空欄bは，表示を見てから決定するまでの間の行為なので，作業負荷の確認が入る。

20字以内で，要望の語をそのまま使う。解答例は「各検査担当者の作業負荷の確認」で14字。「見込回数の確認」でも筋は通るが，見込回数は作業負荷の目安にすぎず，確認したいのは作業負荷である。

本文の根拠

〔新システムへの要望〕

品質検査の実績の中で他の検査担当者への変更が行われていた場合でも，変更前の検査担当者の割当てに従って集計してほしい。

表2 品質検査指示作成

社員コードは検査担当者マスタを参照し格納する。該当する検査担当者変更ファイルのレコードが存在する場合は，検査担当者変更ファイルの内容を優先し格納する。

表2 検査担当者変更

(A) 品質検査指示実績ファイルから，指定した製造日の前週の同曜日の日，便コードを検索条件とし，品目コードを抽出する。

表2 検査担当者変更

(B) 検査担当者マスタから，指定した製造日の曜日，便コードを検索条件とし，品目コード，社員コードを抽出する。

品質検査指示実績ファイルの社員コードには，検査担当者変更ファイルにレコードがあれば変更後の担当者が入る。前週の実績の社員コードをそのまま使うと，前週に担当者を変えていた品目は変更後の担当者の回数として数えられてしまう。

要望は「変更前の検査担当者の割当てに従って集計してほしい」である。変更前の割当ては検査担当者マスタにある。そこで(A)の実績からは品目コードだけを取り（品目ごとの検査回数を数えるため），誰の担当かは(B)でマスタから取って品目コードで結び付ける。マスタは曜日ごとの割当てなので，前週の同じ曜日の実績と組み合わせても割当てはずれない。

30字で「変更前の割当てで集計する」という要望に結び付ける。解答例は「変更前の検査担当者の割当てに従って集計するから」で23字。「実績の社員コードは変更後だから」と書くのは理由の半分で，だからどう集計したいのかまで書くと要望とつながる。

本文の根拠

〔現行の製造及び品質管理の概要〕（エ）

検査担当者は，受け取った全てのロットに対して製造完了日時が古い順にロットの品質検査を実施し

表2 品質検査指示作成

検査結果は“未実施”とする。

表2 製造完了日時更新

製造完了日時を品質検査指示実績ファイルに格納し，そのロットの品質検査が可能な状態とする。

表2 品質検査実績入力

検査担当者が品質検査を実施する順序に従い，次に品質検査対象となるロットを表示し

次に検査するロットは，検査担当者が検査する順序に従って決まる。本文(エ)によると，担当者は受け取ったロットを「製造完了日時が古い順に」検査する。したがって一つ目の項目は製造完了日時で，条件は最も古いこと。製造完了日時は製造実績を受けて格納され，格納された時点でそのロットは検査可能になる。

二つ目は，まだ検査していないロットに絞る条件である。品質検査指示作成で作られたレコードの検査結果は“未実施”で，検査を入力すると“合格”か“不合格”になる。検査済みのロットを除かないと，いつまでも最も古いロットが表示されてしまう。そこで検査結果が“未実施”であることを条件にする。

項目は表1の属性名で答え，条件は15字以内。解答例は「製造完了日時」と「最も古いこと」（6字），「検査結果」と「“未実施”であること」（10字）。「製造日」「ロットNo.」は検査の順序とは関係しない。

本文の根拠

〔現行の製造及び品質管理の概要〕（オ）

製品検査を担当する検査担当者は，検査責任者に製品検査が完了した旨を報告するために，その便で担当する全ての製品の製品検査が終わった時に，製品ごとに，品質記録票の合格数の合計と，製造管理システムが製造開始までに自動で作成した製造指示数の合計が一致することを確認する。

〔現行の製造及び品質管理の概要〕（カ）

製品検査完了確認を実施した旨を事務所の検査責任者に報告する。

〔新システムへの要望〕

製品検査の完了状況を事務所でもすぐに参照できるようにすることで，品質検査実施準備から出荷前承認までの業務を効率化したい。

表2 出荷前承認

検査担当者ごとの製品検査の完了状況を表示し，検査責任者が製造日，便ごとの承認入力を行う機能。

新システムの出荷前承認機能は，検査担当者ごとの製品検査の完了状況を表示する。完了かどうかは，製造開始時の製造指示数の合計と出荷可能な製品の製造数が一致するかで判定する。これは(オ)で検査担当者が手で行っていた「合格数の合計と製造指示数の合計が一致すること」の確認と同じ内容である。

システムが一致を判定して完了状況を事務所に表示するので，検査担当者が確認する(オ)は要らなくなる。確認の結果を電話などで検査責任者に報告する(カ)も，責任者が画面で直接見られるので要らなくなる。要望の「製品検査の完了状況を事務所でもすぐに参照できるようにする」がこれに当たる。(ア)の担当者変更，(エ)の検査，(キ)の最終確認と承認は新システムでも人が行う。

理由は30字で「検査責任者が直接確認できる」ことを書く。解答例は「検査責任者が直接，製品検査の完了状況を確認できるから」で26字。講評では，不要になる業務は選べても理由の正答率がやや低かった。「システム化されるから」では足りず，誰が何を直接見られるようになるのかを書く。

採点講評（IPA）

設問3(1)は，顧客の業務がどのように変更されて効率化されるのかの理解を問う問題であったが，業務が不要となる理由に対する正答率がやや低かった。本文中の記述から，顧客の業務が新システムによってどのように変更されるのかを理解して，正答を導き出してほしい。

本文の根拠

表2 品質検査指示作成

追加フラグは，製造日，便ごとの製造開始前に受信した場合は“通常”，製造開始後に受信した場合は“追加”とする。

〔現行の製造及び品質管理の概要〕（エ）

製造担当者は直ちに，製造管理システムで，不合格になったロットと同じ製造指示数で新たなロット No.の製造指示を作成し，追加製造を行う。

〔現行の製造及び品質管理の概要〕（エ）

合格したロットを，仕掛品の場合は次工程の製造担当者に，製品の場合は出荷担当者に渡す。

表1 品質検査指示実績

追加フラグ（“通常”，“追加”），製造完了日時，検査結果（“未実施”，“合格”，“不合格”）

(1)の「製造開始時の製造指示数の合計」は，製造開始前に作られた製造指示の分である。品質検査指示作成は，製造開始前に受信した指示の追加フラグを“通常”，開始後（不合格による追加製造）を“追加”にする。したがってcは追加フラグが“通常”のレコードで，その製造指示数を合計すれば製造開始時の数になる。

(2)の「出荷可能な製品の製造数」は，検査に合格して出荷担当者に渡された分である。合格したロットだけが出荷担当者に渡るので，dは検査結果が“合格”のレコードになる。不合格のロットは同じ製造指示数で追加製造されるので，全ロットが合格まで進めば“合格”の合計が“通常”の合計に追い付き，二つが一致した時点で製品検査の完了と判定できる。

表1の属性と値を使って15字以内で書く。解答例は「追加フラグが“通常”」（10字）と「検査結果が“合格”」（9字）。dに“追加”分を除く条件を足すと，追加製造で合格した分が数えられず一致しなくなる。

本文の根拠

〔製造から出荷までの流れ〕

その便で出荷する全ての製品を製造し，品質管理規定に従った最終確認を行った後に，出荷を開始する。

〔現行の製造及び品質管理の概要〕（キ）

加えて，品質管理規定に従い，製造設備の異常有無，従業員の衛生チェック結果など，各部署からの報告に基づいた最終確認を行った上で，出荷前承認記録票に承認日時と承認者を記録する。

表2 出荷前承認

出荷前承認の対象の製造日，便における全ての製品の製品検査が完了した状態になった後，検査責任者の承認入力の操作によって出荷前承認記録ファイルのレコードを作成する。

製品検査が全て完了したことはシステムが判定できるので，完了した時点で自動で承認することもできそうに見える。しかし(キ)によると，出荷前承認は製品検査の完了だけでは行えない。品質管理規定に従い，製造設備の異常有無や従業員の衛生チェック結果など，各部署からの報告に基づいた最終確認を行った上で承認する。

これらの報告は表1のファイルには無く，新システムが扱う情報の外にある。システムは製品検査の完了までしか判定できないので，最終確認を済ませたことは検査責任者が承認入力で示すしかない。だから製品検査が完了しても自動では承認せず，承認入力の操作を必須にしている。

35字に「各部署からの報告に基づく最終確認」を入れる。解答例は「出荷前承認には，各部署からの報告に基づいた最終確認が必要だから」で31字。講評によると，承認するための業務上の前提条件を明確に書いていない答えが多かった。「責任者の確認が必要だから」では，何を確認するのかが抜ける。

採点講評（IPA）

設問3(3)は，正答率がやや低かった。出荷前承認を自動化せずに，承認入力の操作を行う設計とした理由を問う問題であったが，承認するための業務上の前提条件を，明確に解答していない受験者が多かった。顧客の業務は情報システム外の情報も用いて行うことが一般的であるので，システムアーキテクトは業務全体の状況を正確に理解してほしい。

本文の根拠

〔現在の業務と K 社の保険申込システムの概要〕(2)

提案書を作成する際，一意となる提案書の番号（以下，提案書番号という）を現行システムが付与する。

〔現在の業務と K 社の保険申込システムの概要〕(3)

現行システムを利用して新しい提案書の基となる提案書を検索し，その提案書を選択して再作成することで，元の提案書の保険条件を引き継いだ新規の提案書が作成される。

〔現在の業務と K 社の保険申込システムの概要〕(4)

申込書には提案書番号が記載されており，申込書の基になった提案書の内容と不整合にならないようにしている。募集人は，印刷済みの提案書の提案書番号を現行システムに入力し，提案書の内容から申込書を作成する。

申込書は，募集人が印刷済みの提案書の提案書番号を入力し，その番号の提案書の内容から作る。申込書にも提案書番号が記載され，基になった提案書の内容と不整合にならないようにしている。提案書番号が提案書の内容を一つに決める鍵になっている。

もし再作成のときに同じ提案書番号のまま保険条件を変えて印刷すると，同じ番号で条件の違う提案書が手元に複数できる。顧客が説明を受けた提案書と，番号から作られた申込書の条件が食い違うおそれがある。そこで再作成では元の条件を引き継いだ「新規の提案書」とし，新しい提案書番号を付ける。

40字で「申込書と提案書の不整合を防ぐ」ことを書く。解答例は「申込書と基になった提案書の内容が不整合にならないようにしているから」で33字。設問は「業務上の観点から」としているので，番号管理の都合ではなく申込書作成業務とのつながりで書く。

本文の根拠

〔新システムへの要望〕

また，ペーパレス手続の場合，手続の途中でも書面手続に切り替えられるようにしたいが，告知書に署名した後は，切り替えられないようにしてほしい。

表1 申込書作成

ペーパレス手続が選択された場合，申込ステータスを“ペーパレス手続選択済”とする。

表1 申込確認

申込確認の完了後，申込書データの申込確認日時を完了した際の日時にし，申込ステータスを“申込確認済”とする。

表1 申込書入力

申込書入力の完了後，申込書データの申込書入力日時を完了した際の日時にし，申込ステータスを“申込書入力済”とする。

表1 告知手続

告知手続の完了後，申込書データの告知手続日時を完了した際の日時にし，申込ステータスを“告知手続済”とする。

要望は，ペーパレス手続の途中でも書面手続に切り替えられるが，告知書に署名した後は切り替えられない，というもの。告知書への署名は告知手続機能の中で行い，告知手続が完了すると申込ステータスが“告知手続済”になる。したがって“告知手続済”より前のステータスが切替え可能である。

表1でステータスが変わる順を追うと，“ペーパレス手続選択済”→“申込確認済”→“申込書入力済”→“告知手続済”→“払込方法選択済”→“承認待ち”→“承認済”となる。このうち告知手続済より前の三つが答えになる。告知手続の途中（署名前）のステータスはまだ“申込書入力済”なので，署名前ならこの状態で切り替えられる。

表1の字句で全て答える。解答例は「“ペーパレス手続選択済”，“申込確認済”，“申込書入力済”」。“告知手続済”を含めると，署名した後の切替えを許してしまう。

本文の根拠

〔新システムへの要望〕

電子書類のうち顧客控え書類は，申込手続完了後に募集人が印刷して，顧客に手渡しする。そのため，顧客控え書類は，顧客が自署した画面と同様のレイアウトにしてほしい。また，保存する電子書類の真正性を確保するために，顧客控え書類に改ざん検知の仕組みを導入してほしい。

表1 申込書入力

署名完了後，顧客控え用の申込書を作成し，保存する。

表1 告知手続

署名完了後，顧客控え用の告知書を作成し，保存する。

改ざん検知の対象は，要望にあるとおり「顧客控え書類」である。顧客が画面上で自署した電子書類を保存し，申込手続完了後に印刷して顧客に手渡す。保存した電子書類の真正性を確保するため，顧客控え書類に改ざん検知の仕組みを入れる。

表1で顧客控え書類を作成・保存する機能を探すと，申込書入力（署名完了後に顧客控え用の申込書を作成し保存）と告知手続（署名完了後に顧客控え用の告知書を作成し保存）の二つである。書類印刷は保存済みの電子書類を印刷するだけで，書類を作る機能ではない。提案書作成も電子書類を作るが，顧客の署名は無く顧客控え書類でもない。

表1の機能名で全て答える。解答例は「申込書入力，告知手続」。改ざん検知は書類を作成して保存する時点で仕組みを組み込む必要があるので，作成・保存する機能を選ぶ。

本文の根拠

〔新システムへの要望〕

責任者が書類の記載内容をチェックして不備があった場合，対応に時間が掛かっているので，

〔現在の業務と K 社の保険申込システムの概要〕(6)

募集人は，責任者に申込書，告知書，意向確認書，及び取扱報告書を確認してもらう。

表1 申込確認

顧客が確認した旨を入力できるようにする。入力する際に入力内容をチェックし，確認漏れがある場合は画面に表示する。

表1 申込書入力

申込確認の完了後，ペーパレス手続メニューから申込書に必要な内容を入力できる画面を表示する。入力する際に入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。

表1 告知手続

申込書入力の完了後，ペーパレス手続メニューから告知書に必要な内容を入力できる画面を表示する。入力する際に入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。

表1 取扱報告書作成

表示項目には，募集人名と責任者名を含める。入力する際に入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。

不備対応に時間が掛かるのは，責任者がチェックして不備を見つけてから，顧客や募集人に戻して直すからである。入力する時点で誤りを見つけてその場で直させれば，責任者のチェックで不備が出ること自体が減る。表1で「入力する際に入力内容をチェック」している機能がこれに当たる。

責任者がチェックする書類は，申込書，告知書，意向確認書，取扱報告書である（(6)）。これに対応する入力機能は，申込書入力（申込書），告知手続（告知書），申込確認（意向確認の説明を確認した旨の入力で，確認漏れを表示），取扱報告書作成（取扱報告書）の四つで，どれも入力内容をチェックしている。提案書作成も入力内容をチェックするが，提案書は責任者がチェックする書類ではない。

機能名は全て，内容は20字以内。解答例は「申込確認，申込書入力，告知手続，取扱報告書作成」と「入力内容をチェックすること」（13字）。講評によると，責任者がチェックしている書類を十分に理解していない答えが散見された。(6)の書類の並びと表1の機能を一つずつ対応させる。

採点講評（IPA）

設問2(3)は，正答率が低かった。責任者が書類の記載内容をチェックして，不備があった場合の不備対応時間の短縮を考慮して設計した新システムの機能を問う問題であったが，責任者がチェックしている書類を十分に理解していないと思われる解答が散見された。情報システムへの要望の背景・目的を正しく理解して機能を設計することが重要であることを理解してほしい。

本文の根拠

〔新システムへの要望〕

手続を円滑に進めるために募集人が手続の順番を把握できるようにしてほしい。

表1 ペーパレス手続メニュー

ペーパレス手続が選択された申込書データに対して，実施する作業のメニューを画面に表示する。次に実施すべき作業メニューだけ活性化する。

下線③の要望は，募集人が手続の順番を把握できるようにすること。ペーパレス手続は，申込確認→申込書入力→告知手続→払込方法選択→取扱報告書作成と順に進み，それぞれの機能は前の手続の完了後にペーパレス手続メニューから開く。

ペーパレス手続メニューは実施する作業のメニューを表示し，次に実施すべき作業メニューだけを活性化する。募集人は活性化されたメニューを見れば次に何をすべきかが分かり，順番を間違えずに手続を進められる。これが要望を考慮した設計である。

機能名は表1の名前で，内容は25字以内。解答例は「ペーパレス手続メニュー」と「次に実施すべき作業メニューだけ活性化すること」（22字）。「作業メニューを表示すること」だけでは，順番が分かる仕組み（次の作業だけ選べる）になっていない。

本文の根拠

〔現在の業務と K 社の保険申込システムの概要〕(5)

申込書を作成開始してから申込手続業務を完了するまでの時間を手続所要時間と呼ぶ。

〔現在の業務と K 社の保険申込システムの概要〕(5)

また，保険料の口座振替依頼書の記入を依頼して記入内容を確認する。

表1 申込書作成

提案書データから申込書データを登録する。また，登録した際，申込書データの申込日時を登録した際の日時にする。

表1 払込方法選択

払込方法選択の完了後，申込書データの払込方法選択日時を完了した際の日時にし，申込ステータスを“払込方法選択済”とする。

表1 取扱報告書作成

払込方法選択の完了後，取扱報告書データを登録する画面を表示する。

手続所要時間は「申込書を作成開始してから申込手続業務を完了するまでの時間」である。始まりは申込書データの申込日時（申込書作成で登録した日時）になる。終わりは申込手続業務の最後の作業で，(5)では口座振替依頼書の記入の確認，新システムでは払込方法選択に当たる。その次の取扱報告書作成は(6)の申込手続事後業務である。したがって終わりは払込方法選択日時である。

「当月に申込手続業務が完了した申込」なので，対象は払込方法選択日時が当月の申込書データになる。申込日時が当月かどうかでは選ばない（前月に作成を始めて当月に完了したものも含む）。対象ごとに払込方法選択日時と申込日時の差を出し，その平均をとる。

40字で「対象の条件」と「差をとる二つの日時」を表1の字句で書く。解答例は「払込方法選択日時が当月である申込書データの，払込方法選択日時と申込日時の差」で37字。講評によると，業務に関連しない値を使った答えが散見された。承認日時や連携日時は申込手続業務より後の業務の日時である。

採点講評（IPA）

設問3は，(1)，(2)ともに正答率が低かった。当月に申込手続業務が完了した申込の手続所要時間と，当月に契約管理システムに連携が完了した申込の申込書到着所要時間の算出方法を問う問題であったが，これらの業務に関連しない値を用いた解答が散見された。現行業務を正しく理解した上で，情報システムの機能を設計することが重要であることを理解してほしい。

本文の根拠

〔現在の業務と K 社の保険申込システムの概要〕(7)

現在の業務では，申込書を作成開始してから K 社へ書類一式が到着し，契約管理システムに入力するまでの時間を申込書到着所要時間と呼ぶ。

〔新システムへの要望〕

申込書の内容をデータとイメージファイルの両方で契約管理システムに連携してほしい。

表1 申込書データ連携

連携後，申込書データの連携日時を連携した際の日時にする。

申込書到着所要時間は，現在の業務では申込書を作成開始してから書類一式がK社に着き，契約管理システムに入力するまでの時間である。新システムのペーパレス手続では，書類を郵送する代わりに申込書の内容を契約管理システムに連携する。郵送・入力に当たる終わりの時点は，申込書データ連携で登録される連携日時になる。始まりは設問3(1)と同じく申込日時である。

「当月に契約管理システムに連携が完了した申込」なので，対象は連携日時が当月の申込書データになる。対象ごとに連携日時と申込日時の差を出し，その平均をとる。

35字で「対象の条件」と「差をとる二つの日時」を書く。解答例は「連携日時が当月である申込書データの，連携日時と申込日時の差」で29字。講評のとおり正答率が低かった。承認日時を終わりにすると，K社に届いた時点（連携）までの時間にならない。

採点講評（IPA）

設問3は，(1)，(2)ともに正答率が低かった。当月に申込手続業務が完了した申込の手続所要時間と，当月に契約管理システムに連携が完了した申込の申込書到着所要時間の算出方法を問う問題であったが，これらの業務に関連しない値を用いた解答が散見された。現行業務を正しく理解した上で，情報システムの機能を設計することが重要であることを理解してほしい。

本文の根拠

〔新たなシステムにおける取組方針と開発項目〕(3)

橋梁の環境データ，診断データ及び設計データを AI で分析，学習することによって，劣化の予測モデルを構築することで予兆診断・保全を可能とする。

表2 診断サーバ

を構築し，予兆診断・保全を支援する。

表2の診断サーバの最後の行は「AIを活用してaを構築し，予兆診断・保全を支援する」。開発項目(3)に，同じ流れの文がある。環境データ，診断データ，設計データをAIで分析・学習して「劣化の予測モデルを構築することで予兆診断・保全を可能とする」。

AIを活用して構築し，予兆診断・保全につながるものは劣化の予測モデルである。取組方針の「補修や対策が必要な状況のより早い検知」も，この予測モデルで実現する。

字数の制限は無く，本文の語をそのまま入れる。解答例は「劣化の予測モデル」。「予測モデル」だけでは何を予測するのかが抜けるので，「劣化の」まで書く。

本文の根拠

〔現行システムの問題点〕

また，ゲートウェイは商用電源を使用する必要があるので，設置できる橋梁が限られてしまう。

表1 ゲートウェイ

消費電力が大きいので，商用電源で駆動する。

表2 センサノード

現行システムのセンサノードに，低消費電力でデータの送受信が可能なモバイル通信機能を搭載し，診断サーバとの双方向通信を現行システムと同程度の低消費電力で行う。

図2 注記

センサノードと診断サーバ間はモバイル通信で接続されている。

現行システムでは，センサノードは特定小電力無線でゲートウェイにデータを集め，ゲートウェイがモバイル通信で診断サーバに送る。ゲートウェイは消費電力が大きく商用電源で動かす必要があるので，商用電源の無い橋梁には設置できない。これが問題点に挙がっている。

新システムではセンサノード自身に低消費電力のモバイル通信機能を持たせ，診断サーバと直接双方向に通信する。図2にはゲートウェイが無く，注記にもセンサノードと診断サーバ間はモバイル通信で接続とある。ゲートウェイが要らなくなれば，商用電源の無い橋梁でもセンサノードを使える。

20字で「ゲートウェイを不要にする」ことを書く。解答例は「ゲートウェイの設置を不要にするため」で17字。「診断サーバと直接通信するため」は手段で，その結果何が改善するのかまで書くと目的になる。

本文の根拠

〔現行システムの問題点〕

センサノードは固定式で，使い捨ての電池で駆動するので，電池交換及びそれに伴う設置工事などの保守コストが増大化している。

〔新たなシステムにおける取組方針と開発項目〕

必要なときだけ，センサノードを設置し，必要なセンサデータが取得できたらセンサノードを低コストで回収可能な方式を検討する。

〔新たなシステムにおける取組方針と開発項目〕(2)

センサノードはセンサロボットによって，橋梁に運搬，設置された後，必要な期間だけセンサデータの収集・送信を行い，センサロボットによって回収される。そのために，センサロボットでセンサノードの設置・回収を可能とするノード設置アダプタを開発し，橋梁に固定設置する。

現行システムのセンサノードは橋梁に固定設置されている。新システムでは，橋梁に固定するのはノード設置アダプタだけで，センサノード自体はセンサロボットが運んで取り付け，必要な期間だけデータを集めたら回収する。

回収したセンサノードは，別の橋梁のノード設置アダプタに運んで使える。橋梁ごとにセンサノードを置きっぱなしにする必要が無くなり，一つのセンサノードを複数の橋梁で使い回せる。コストの削減は設問で除かれているので，運用面の改善としてこの再利用を答える。

25字で「異なる橋梁で再利用できる」ことを書く。解答例は「異なる橋梁でセンサノードが再利用できる」で19字。講評によると，「コストの削減以外に」と問うているのにコストの削減を書いた答えが散見された。講評は，現行システムより少ないセンサノード数で運用できることに気付いてほしいとしている。

採点講評（IPA）

設問1(3)は，正答率が平均的であったが，“コストの削減以外に”と問うているにもかかわらず，コストの削減を示す解答が散見された。センサロボットの導入によって，現行システムに比べてより少ないセンサノード数で運用が可能であることを理解して，正答を導き出してほしい。

本文の根拠

冒頭

しかし，複雑な構造の橋梁を点検するためには，カメラロボットを手動で操縦する必要があり，熟練操縦者の不足など幾つかの問題がある。

表1 カメラロボット

GNSS 受信機，高度センサ，全方位近接センサ及びレーザ測距装置を搭載する。

表2 カメラロボット

飛行ルートと撮影位置・方向（以下，飛行計画という）を設定すると，飛行計画に従い，自律飛行しながら撮影を行う。

カメラロボットは飛行計画に従って自律飛行する。飛行計画は橋梁の3Dモデル上で作るが，複雑な構造の橋梁の周りを飛ぶと，部材や計画にない物に近づくことがある。今まではこれを熟練の操縦者が手動で避けていた。

全方位近接センサは，機体の周り全方向で近くにある物を検出するセンサである。障害物を検出したら，ぶつからないように避けて飛ぶ。操縦者なしで点検するには，この回避をロボット自身が行う必要がある。回避した後も飛行計画に沿って撮影を続けるので，「回避しながら飛行する」となる。

25字で「検出した障害物を回避する」ことを書く。解答例は「検出した障害物を回避しながら飛行する。」で19字。「停止する」「着陸する」は点検を続けられないので，自律飛行での点検という目的に合わない。

本文の根拠

表1 センサノード

無線センサネットワークを構成し，取得したデータ（以下，センサデータという）を処理してセンサノード間でマルチホップ通信を行ってゲートウェイに集約して，1 時間ごとに診断サーバに送信する。

表2 センサノード

現行システムと同様の周期でセンサデータの取得と診断サーバへの送信を行う。また，診断サーバからの要求によってオンデマンドで計測を行うことが可能である。

表2 点検制御装置

モバイル通信を利用して，診断サーバと通信する。

〔新システムの概要〕

点検制御装置は各カメラロボットに設定された飛行計画とのずれを監視し，必要であればカメラロボットに対して飛行計画の修正を指示する。

センサノードは1時間ごとにセンサデータを診断サーバに送る。新システムでも同じ周期である。診断サーバに蓄積されている風向・風力のデータは最大で1時間前のもので，今の風を表していない。点検制御装置は飛行中のカメラロボットのずれを監視して計画の修正を指示するので，使う風のデータは今の値でなければ役に立たない。これが問題点である。

解決策は，新システムのセンサノードがもつオンデマンド計測を使うことである。センサノードは診断サーバからの要求でその場で計測でき，点検制御装置はモバイル通信で診断サーバと通信できる。点検制御装置が診断サーバを経由して必要なデータをオンデマンドで取得すれば，飛行制御に使える最新の風向・風力が手に入る。

問題点は40字で「リアルタイムでない」ことと「飛行制御に適さない」ことを，解決策は35字で「診断サーバ経由でオンデマンドに取得」を書く。解答例は「データがリアルタイムでないため，カメラロボットの飛行制御には適さない」（34字）と「必要なデータを診断サーバを経由してオンデマンドで取得する。」（29字）。講評によると，問題点を「センサデータが標準化されていないこと」と捉えた答えが散見された。標準化は他社とのデータ共有の話で，飛行制御の問題ではない。

採点講評（IPA）

設問2(2)は，正答率が低かった。問題点を“センサデータが標準化されていないこと”と捉えている解答が散見された。風向・風力のデータを基にカメラロボットを制御するためには，データのリアルタイム性が重要であることを理解してほしい。IoTシステムにおいて，データのリアルタイム性について必要性の有無を評価することは極めて重要であるので，是非理解を深めてほしい。

本文の根拠

冒頭

建設後 50 年以上経過する社会資本の割合が加速度的に高くなってきており，これらの老朽化対策が大きな社会課題となっている。

〔新たなシステムにおける取組方針と開発項目〕

センサで収集した橋梁の環境を示すデータ（以下，環境データという），カメラロボットで収集した画像データ，画像データから得られた診断データ，及び橋梁の構造や材質などの設計データの相関関係を時系列に分析し，補修や対策が必要な状況のより早い検知を可能とする。

〔新たなシステムにおける取組方針と開発項目〕(3)

橋梁の環境データ，診断データ及び設計データを AI で分析，学習することによって，劣化の予測モデルを構築することで予兆診断・保全を可能とする。

〔新たなシステムにおける取組方針と開発項目〕

F 社は，環境データ，画像データ及び設計データを業界横断的に共有，活用できるようにするため

予兆診断・保全は，AIが環境データ，診断データ，設計データを分析・学習して作る劣化の予測モデルで行う。データの相関関係を時系列に分析するので，構造や材質，環境の違う多くの橋梁について，長い期間のデータが要る。

F社が点検・診断した橋梁のデータだけでは，橋梁の数も期間も限られる。これだけで学習すると，予測モデルが十分な精度に達するまでに長い年月が掛かる。老朽化する社会資本の割合は加速度的に高まっているので，早く精度を確保する必要がある。業界横断で他社のデータも共有すれば，学習に使えるデータが一気に増え，予測モデルの精度を早く上げられる。

40字で「F社のデータだけでは」「予測モデルの精度」「早期に」を入れる。解答例は「F社のデータだけでは劣化の予測モデルの精度が早期に確保できないから」で33字。「データが多いほうがよいから」だけでは，何のためにデータが要るのか（予測モデルの精度）が抜ける。

本文の根拠

〔新たなシステムにおける取組方針と開発項目〕(4)

現行システムにおける環境データ，画像データ及び設計データは独自のフォーマットで診断サーバに格納されているが，これらをそのまま活用し，かつアライアンスの成果も活用するため，診断サーバ上に変換層を開発し，他社へのデータの提供及び他社のデータの活用を図る。

表2 診断サーバ

API を介して，蓄積された環境データや画像データなどを標準化されたデータモデルで提供し，アライアンスに準拠した他社との相互利用が可能である。

〔新たなシステムにおける取組方針と開発項目〕

各データのデータモデルの標準化，及び標準化されたデータモデルを提供するための API の標準化を目的として，業界内でアライアンスを推進してきた。

診断サーバのデータは独自のフォーマットで格納されている。これをそのまま使い続けながら，アライアンスで標準化したデータモデルでも扱えるようにするのが変換層である。独自フォーマットを作り直すのではなく，間に変換を挟む。

変換は両方向に要る。他社へデータを提供するときは，独自フォーマットのデータを標準化されたデータモデルに変換してAPIで出す。他社のデータを活用するときは，標準化されたデータモデルで受け取ったデータを診断サーバの独自フォーマットに変換して取り込む。本文の「他社へのデータの提供及び他社のデータの活用」がこの二つの方向に当たる。

40字で「標準化されたデータモデル」と「現行システムのデータ」の「相互変換」を書く。解答例は「標準化されたデータモデルと現行システムのデータの相互変換を行う。」で32字。提供の方向だけを書くと，他社のデータを活用する側が抜ける。