令和3年度 春期 午後Ⅰ

本文の根拠

〔現行業務の概要〕(4)

再発行すると，古い利用者カードを無効にし，使用できないようにする。

表1 利用者カードマスタ

利用者カードマスタ：利用者カード番号（主キー），利用者コード，状態区分。

〔現行業務の概要〕(3)

その際，事業管理システムで利用者を一意に識別する利用者コードが付与される。

利用者カードは持参を忘れると再発行され，そのとき古いカードは無効にされる。同じ利用者のカードが新旧2枚存在し，古い方だけを使えなくする必要がある。そのためにはカード1枚ごとに違う値をバーコードに入れなければならない。表1でカード1枚を識別できるのは利用者カードマスタの主キーである利用者カード番号で，同じマスタの状態区分で有効か無効かを管理できる。

利用者コードは利用者を一意に識別する値なので，再発行しても新旧のカードで同じになる。利用者コードをバーコードに入れると，古いカードを読み取っても新しいカードと区別できず，無効にしたはずのカードが使えてしまう。講評もこの誤りを挙げている。

属性名は表1の表記どおり「利用者カード番号」と書く。理由は35字で「再発行」と「古いカードを使えなくする」の二つを入れる。解答例は「再発行の際，古い利用者カードを使用できないようにしたいから」で29字。

採点講評（IPA）

設問1は，正答率が低かった。特に属性名については，“利用者コード”と誤って解答した受験者が多かった。“利用者コード”とすると，再発行時に古い利用者カードを無効にすることができない。〔現行業務の概要〕の記述をよく読んで，利用者カードの管理運用を理解して，正答を導き出してほしい。

本文の根拠

〔現行業務の概要〕(8)

郵送の場合の送付先は，利用者が所属する事業所の所在地にしている。

〔企業に関する情報の管理運用の見直し〕

法人情報以外の電話番号，代表者氏名，支店の情報などは提供されない。

〔企業に関する情報の管理運用の見直し〕

一方で，事業所情報は，利用者マスタで管理する。

業務の流れの中で事業所の情報を使う場面を探す。(8) 報告書の納品では，報告書を郵送するとき，送付先を利用者が所属する事業所の所在地にしている。宛名は企業名なので企業単位の情報で足りるが，送付先は事業所ごとに違う。

刷新後の企業マスタは法人情報で企業単位に管理され，法人情報には支店の情報が含まれない。本店以外の事業所に所属する利用者へ報告書を郵送するには，その利用者の事業所の所在地を別に持つ必要がある。これを利用者マスタに持たせることにした。料金の判断は企業単位で行うので，事業所情報を使う理由にはならない。

20字なので「報告書の送付先」を中心に書く。解答例は「報告書の送付先として利用すること」で16字。

本文の根拠

〔A 研究所の事業概要〕

一般料金と優遇料金のどちらを適用するかについては，株式会社・社団法人などの法人種別，業種，資本金及び従業員数で A 研究所が判断している。

〔企業に関する情報の管理運用の見直し〕

国税庁法人番号公表サイトで提供されている企業名，本店又は主たる事務所の所在地，及び 1 法人に一つ指定される法人番号から構成される基本 3 情報（以下，法人情報という）

〔現行業務の概要〕(2)

入力された内容を基に，適用料金区分として，中小企業及び個人事業者向けの料金を適用する“優遇”か，それ以外の“一般”かを，事業管理システムが自動判断して登録する。

〔現行の事業管理システムにおける企業及び利用者に関する情報の管理運用〕

企業情報を利用者に確認したり，職員が公表情報を調べたりする作業負荷を軽減するため，企業マスタで管理する属性の一部は，信用調査会社から年に 1 回，企業データベース（以下，企業 DB という）を購入し，登録している。

下線①の「特定の属性情報」が何かを考える。法人情報は企業名，所在地，法人番号の3つだけである。一方，適用料金区分を決めるには法人種別，業種，資本金，従業員数が要る。これらは法人情報には含まれない。

表1では，法人種別，業種，資本金，従業員数に注1)が付いており，企業DBに存在する項目である。企業DBを買わなければ，料金区分を判断するたびに利用者に確認したり職員が公表情報を調べたりしなければならない。この作業負荷を増やさないために企業DBの購入を続ける。代表電話番号や代表者氏名も法人情報に含まれないが，料金区分の判断に使わないので理由にならない。講評は，こうした判断に関係のない属性を挙げた誤りが多かったとしている。

35字で「適用料金区分」という表1の属性名と，「法人情報には含まれない」の両方を書く。解答例は「適用料金区分を判断するための情報は，法人情報には含まれないから」で31字。

採点講評（IPA）

設問2(2)は，正答率がやや低かった。“代表電話番号”，“代表者氏名”など，適用料金区分を判断する上で関係のない情報を誤って解答した受験者が多かった。なぜ企業情報を確認したり，調べたりする必要があるのかをしっかり理解してほしい。

本文の根拠

〔A 研究所の事業概要〕

主要事業は，A 研究所が所在する地域の中小企業の利用が中心であるが，その他の地域の企業，大企業，法人登記していない個人事業者などによる利用も可能である。

〔企業に関する情報の管理運用の見直し〕

また，法人番号が指定されない個人事業者などは対象外である。

〔現行の事業管理システムにおける企業及び利用者に関する情報の管理運用〕

本店以外の事業所情報及び個人事業者の情報は購入していない。

企業マスタは法人情報と企業DBで登録・更新される。この二つのどちらにも入らない利用者を探す。法人情報は法人番号が指定された法人だけが対象で，個人事業者は対象外である。企業DBも個人事業者の情報は購入していない。

主要事業は法人登記していない個人事業者も利用できる。個人事業者が初めて利用するときは企業マスタに情報がないので，現行どおり企業情報として新規に登録する必要がある。設問が示すもう一つのケース（法人登記直後）とは別の理由で登録されていないケースである。

15字なので「個人事業者が利用するケース」（13字）のように，誰が利用するかを書けば足りる。

本文の根拠

〔利用者に関する情報の管理運用の見直し〕

オンラインでの登録の場合，なりすましによる不正登録を防止するため，仮登録の状態にする。

〔利用者に関する情報の管理運用の見直し〕

初回の来所時に身元を確認してから本登録にする。

〔利用者に関する情報の管理運用の見直し〕

本登録の際に，利用者の電子メールアドレスに利用者マスタの情報から生成した URL を送付し，その URL にアクセスすると QR コードが表示される。

刷新後はオンラインで事前登録した利用者を仮登録にし，来所して身元を確認してから本登録にする。利用者マスタに登録された利用者が，いま仮登録なのか本登録なのかを区別できなければ，この運用は回らない。

表1の利用者マスタには，この状態を表す属性がない。本登録のときに利用者カード（QRコード）のURLを送るので，仮登録のまま利用者カードを出さないようにするにも，この区別が要る。もう一つの新しい情報である事業所情報は，企業マスタから移すものである。

25字で「仮登録か本登録かを識別する」ことを書く。解答例は「利用者が，仮登録か本登録かを識別する情報」で20字。

本文の根拠

〔利用者に関する情報の管理運用の見直し〕

その際，法人に所属する利用者の場合は，企業情報の入力をできる限り簡略化し，かつ所属企業との関連づけができるよう，aの入力を求める。

〔企業に関する情報の管理運用の見直し〕

及び 1 法人に一つ指定される法人番号から構成される基本 3 情報

〔企業に関する情報の管理運用の見直し〕

企業マスタは法人情報の利用に伴い，事業所単位ではなく企業単位で情報を管理することにし，登録済の企業情報は，システム刷新時にできる限り法人情報に名寄せする。

刷新後の企業マスタは法人情報で登録され，企業単位で管理される。法人番号は1法人に一つ指定される番号なので，利用者が法人番号を1つ入力すれば，企業マスタの企業を一意に特定できる。企業名や所在地を入力させる必要がなく，入力が簡略化される。

企業名で検索する方法では，企業名の変更や屋号での登録によって同じ企業が別に登録される問題があった（専門部署の職員からの改善要望）。法人番号で関連づければ，この問題も起きない。空欄の前に「法人に所属する利用者の場合は」とあるのも，法人番号が法人にしか指定されないことと合う。

答えは「法人番号」。本文の語をそのまま使う。

本文の根拠

〔現行業務の概要〕(3)

そのため，同じ企業に所属する者であっても，他の利用者の利用者カードを借りて利用することは禁止している。

〔企業及び利用者に関する情報の管理運用に対する改善要望〕(2)

電子化後も利用者カードの発行の考え方，使用ルールは現在の運用を踏襲したい。

〔利用者に関する情報の管理運用の見直し〕

URL にアクセスする都度，利用者の電子メールアドレス又は携帯電話のショートメッセージサービスにワンタイムの PIN を送付し，PIN を入力しないと QR コードが表示できない仕組みにする。

電子化前の利用者カードの使用ルールとして本文に書かれているのは，他の利用者の利用者カードを借りて利用することの禁止である。利用者個人ごとに誰が利用したかを管理するために，カードの貸し借りを禁じている。

QRコードはURLにアクセスすれば表示できるので，URLを他人に教えるだけで貸し借りができてしまう。そこで，アクセスのたびに本人のメールアドレスか携帯電話にワンタイムのPINを送り，本人でなければQRコードを表示できないようにした。下線③の後に書かれた仕組みが，貸し借りを防ぐためのものだと分かれば答えが決まる。

30字で「他の利用者のカードを借りて利用すること」と「禁止」を書く。解答例は「他の利用者の利用者カードを借りて利用することの禁止」で25字。

本文の根拠

〔改善後の配達システムの新機能〕(1)

配達員から配達端末を用いて連携された情報を基に，推奨移動経路で移動した場合の各受取場所への配達予定時刻を計算する。

〔現在の業務の概要〕(3)

配達システムが蓄えている過去の配達実績情報及び現在の交通情報に基づいて，使用する配達車両に応じた推奨移動経路と配達到着予想時刻を配達端末に提示する。

〔配達システム改善後の配達業務の概要〕

配達員は営業所出発前に，配達時に使用する配達車両に加えて配達員の氏名を配達端末で配達システムに入力し，あらかじめ決めておいた配達順序の順番に送付伝票のバーコードを読み取り，配達状況を“配達開始”にする。

〔現在の業務の概要〕(3)

各便の配達順序は営業所を出発する前に配達員があらかじめ決定する。

各受取場所への配達予定時刻を出すには，どの順に回るか（配達順序）と，何で移動するか（配達車両）が分からなければならない。推奨移動経路は使用する配達車両に応じて決まり，受取場所ごとの到着時刻は，その前に何か所回るかで決まる。過去の配達実績情報や交通情報は配達システムがもともと持っているので，配達員から受け取る必要はない。

改善後の業務では，配達員が営業所出発前に，配達車両と氏名を配達端末から入力し，あらかじめ決めた配達順序の順番に送付伝票のバーコードを読み取る。この読取りの順番が配達順序として配達システムに伝わる。同時に入力する配達員の氏名は時刻の計算には使わない（設問1(2)の通知に使う）。講評は，配達端末から連携していない情報を挙げた誤りが多かったとしている。

各15字なので「あらかじめ決めた配達順序」（12字），「配達時に使用する配達車両」（12字）のように，本文の語で短く書く。

採点講評（IPA）

設問1(1)は，正答率がやや低かった。配達予定時刻を計算するために，配達員が配達端末を用いて配達システムに連携している情報を問う問題であったが，配達端末を用いて連携していない情報を誤って解答した受験者が多かった。一般論で解答するのではなく，本文中の記述及び設問の内容から，配達システムにどのような情報を連携する必要があるのかを理解して，正答を導き出してほしい。

本文の根拠

〔宅配便サービスの改善要望〕(1)

依頼主が誰なのかを届け先顧客に通知してほしい。

〔宅配便サービスの改善要望〕(2)

配達員として誰が来るのかが分かるようにしてほしい。

〔配達システム改善後の配達業務の概要〕

配達員は営業所出発前に，配達時に使用する配達車両に加えて配達員の氏名を配達端末で配達システムに入力し

〔現在の業務の概要〕(1)

配達システムに送付伝票の依頼主名，届け先顧客名，郵便番号，住所，電話番号，配達予定日及び配達予定時間帯を登録すると

配達予定情報は届け先顧客に通知するものなので，届け先顧客に知らせてほしいという改善要望を拾う。依頼主からは「依頼主が誰なのかを届け先顧客に通知してほしい」，届け先顧客からは「配達員として誰が来るのかが分かるようにしてほしい」という要望がある。待ち時間の要望は配達予定時刻で満たしている。

依頼主名は集荷時に送付伝票から配達システムに登録されている。配達員の氏名は，改善後に配達員が営業所出発前に配達端末で入力するようになった。どちらも営業所を出発する時点で配達システムにそろっているので，出発のタイミングで通知できる。

各10字なので「配達員の氏名」（6字）と「依頼主名」（4字）のように名詞で答える。

本文の根拠

〔現在の業務の概要〕(4)

ただし，再配達希望日が当日で，かつ再配達希望時間帯の受付締切時刻経過後は，再配達希望は受け付けない。

〔宅配便サービスの改善要望〕(2)

荷物が届く前でも再配達依頼時と同様に配達日，配達時間帯などを変更できるようにしてほしい。

〔改善後の配達システムの新機能〕(5)

ただし，配達状況が“配達完了”又は“不在連絡済”の荷物については受け付けない。

配達条件変更機能は，届け先顧客の「荷物が届く前でも再配達依頼時と同様に」配達日や配達時間帯を変えたいという要望に応えるものである。再配達依頼時の決まりを見ると，再配達希望日が当日で，かつ再配達希望時間帯の受付締切時刻を過ぎていれば受け付けない。これを配達条件の語（配達希望日，配達希望時間帯）に置き換えたものが空欄に入る。

空欄は「aの場合，かつbの場合」と二つの条件を「かつ」でつないでいる。本文の再配達の条件も「当日で，かつ…受付締切時刻経過後」と同じ形である。講評によると，配達状況が“配達完了”や“不在連絡済”という答えが多かった。これらはすでに直前の文で受け付けない荷物として挙げられており，また二つの配達状況を「かつ」で同時に満たすことはない。

各20字。解答例はa「配達希望日が当日」（8字），b「配達希望時間帯の受付締切時刻経過後」（17字）。bは「受付締切時刻」の語を落とさない。

採点講評（IPA）

設問1(3)は，正答率がやや低かった。配達条件の変更を受け付けられない場合の条件を問う問題であったが，配達状況が“配達完了”や“不在連絡済”など，成立しない条件を誤って解答した受験者が多かった。本文中の記述から，複合条件としては成立しないことに気付いてほしい。システムアーキテクトは現行業務を踏まえた上で，システム改善後の機能を設計することを心掛けてほしい。

本文の根拠

〔宅配便サービスの改善要望〕(2)

帰宅して不在連絡票を確認しなくても再配達依頼できるようにしてほしい。

〔改善後の配達システムの新機能〕(3)

配達員が不在連絡票を投かんし，配達状況を“不在連絡済”にしたタイミングで，不在連絡票の内容を届け先顧客に通知する。

〔配達システム改善後の配達業務の概要〕

不在連絡票を投かんした場合は，配達員が，配達状況を“不在連絡済”にする。

追加された入力ケースは“担当区域外”と“不在連絡済”の二つである。このうち改善要望に直接つながるのは“不在連絡済”で，配達員がこれを入力したタイミングで不在連絡票通知機能が動き，不在連絡票の内容が届け先顧客に通知される。

届け先顧客は，帰宅して紙の不在連絡票を見なくても，通知で不在だったことと連絡票の内容を知り，再配達を依頼できる。これが届け先顧客の「帰宅して不在連絡票を確認しなくても再配達依頼できるようにしてほしい」という要望に当たる。“担当区域外”は受取場所の変更に伴う社内の作業のための入力で，改善要望そのものを実現するものではない。

30字で要望の中身を書く。解答例は「不在連絡票を確認しなくとも再配達依頼ができること」で24字。

本文の根拠

〔現在の業務の概要〕(3)

各配達員の担当区域は，営業所ごとに管理されており，配達システムには登録されていない。

〔現在の業務の概要〕(3)

配達員は自分の担当区域を把握しており，担当区域外に配達することはない。

〔配達システム改善後の配達業務の概要〕

受取場所に配達員の担当区域外を指定されていた場合は，配達員が，配達状況を“担当区域外”にする。

配達条件変更機能で受取場所が変わると，変更後の受取場所がその荷物を持っている配達員の担当区域の外になることがある。これを配達システムが自動で判断できれば，“営業所倉庫保管”や“営業所戻り”のようにシステムが配達状況を変えられる。

しかし，各配達員の担当区域は営業所ごとに管理されていて，配達システムには登録されていない。システムには担当区域外かどうかを判断する材料がない。担当区域を把握しているのは配達員自身なので，配達員が配達端末で“担当区域外”を入力することにした。

30字で「担当区域が配達システムに登録されていない」ことを書く。解答例は「各配達員の担当区域は配達システムに登録されていないから」で27字。

本文の根拠

〔改善後の配達システムの新機能〕(5)

変更後の受取場所として配達先の営業所が指定された場合は，配達状況を“営業所倉庫保管”として，営業所帰還時に荷物を降ろすことを配達員に指示する。

〔現在の業務の概要〕(3)

1 便目，2 便目の配達業務完了後は配達車両から荷物を降ろさない。3 便目の配達業務完了後に配達車両から荷物を降ろし，営業所倉庫に保管する。

〔現在の業務の概要〕(2)

配達先の営業所受取を指定された場合は営業所倉庫に保管する。

空欄cは「配達システムが配達状況を変更」するものなので，配達条件変更機能で配達システムが付ける配達状況から選ぶ。候補は“営業所倉庫保管”と“営業所戻り”である。このうち本文が「営業所帰還時に荷物を降ろすことを配達員に指示する」としているのは“営業所倉庫保管”で，これまでに無い作業が発生するのはこちらである。

現在は，1便目・2便目の後は荷物を配達車両から降ろさず，3便目の後にだけ降ろして営業所倉庫に保管している。配達中に受取場所が配達先の営業所に変わると，1便目・2便目の帰還時でもその荷物を降ろし，営業所受取の荷物として営業所倉庫に保管しなければならない。これが「これまでの配達業務では行わなかった作業」である。“担当区域外”の荷物も同じく途中の便で降ろす必要がある。

cは本文の語どおり「営業所倉庫保管」。作業内容は35字で「当日の配達業務完了前」（3便目より前）に「降ろして営業所倉庫に保管する」ことを書く。解答例は「当日の配達業務完了前に荷物を降ろし，営業所倉庫に保管する作業」で30字。

本文の根拠

〔現状の融資りん議の業務〕(2)

りん議書には基幹システムと担保評価システム以外の情報も必要であり，りん議書を作成するために複数のシステムを操作する。

〔WF システムの概要〕

WF システムは，既存システムの機能をサービスとして利用し，りん議書作成に必要なデータを一括で取得できる方式にした。

〔WF システムの概要〕(2)

りん議書入力画面の起動時に，WF システムは必要なデータを複数の既存システムから一括で取得し，WF システムに保存した後，りん議書入力画面に案件データとともに表示する。

下線①は，りん議書作成に必要なデータを既存システムから一括で取得する方式である。現状のりん議書作成業務では，基幹システム，担保評価システム，それ以外のシステムに必要な情報が分かれているので，案件担当者が複数のシステムを操作して情報を集めている。

WFシステムがりん議書入力画面の起動時にこれらのデータを一括で取得し，画面に表示するので，案件担当者が一つずつシステムを操作する作業は要らなくなる。講評は，一部の業務に限定した答えが多かったとしている。下線①はシステム全体の方式の決定なので，りん議書の作成に使う複数のシステム全体の操作が不要になる，と答える。

30字で「りん議書を作成するため」と「複数のシステムを操作する作業」を書く。解答例は「りん議書を作成するために複数のシステムを操作する作業」で26字。

採点講評（IPA）

設問1は，正答率がやや低かった。システム全体に影響するアーキテクチャの決定事項に関する問題であったが，一部の業務に限定して解答した受験者が多かった。システムアーキテクトは，情報システム全体を俯瞰して検討する立場であることを認識してほしい。

本文の根拠

〔現状の融資りん議の業務〕

融資希望金額が担当営業店の決裁可能金額を超える案件の場合，回付経路には担当営業店に加え本部が含まれる。

〔WF システムの概要〕(3)

ある条件を満たすりん議書の回付経路に本部の回付先担当者が含まれていない場合，WF システムは案件担当者に修正を要求する。

表1 案件

案件：案件番号（主キー），顧客番号，店番，融資希望金額

表1 店

店：店番（主キー），店名，郵便番号，住所，決裁可能金額。

下線②は「回付経路に本部の回付先担当者が含まれていなければ修正を求める」ための条件なので，本部を回付経路に含めなければならない案件の条件を答える。本文は，融資希望金額が担当営業店の決裁可能金額を超える案件の場合に，回付経路に本部が含まれるとしている。

これを表1の属性に当てはめる。融資希望金額は案件ファイルにあり，決裁可能金額は店ファイルにある。案件ファイルの店番で店ファイルを引けば，担当営業店の決裁可能金額が分かる。

40字で「どのファイルのどの属性」と「超える」の関係を落とさずに書く。解答例は「案件ファイルの融資希望金額が店ファイルの決裁可能金額を超えている場合」で34字。

本文の根拠

〔現状の融資りん議の業務〕

承認者及び決裁者は，判断の際に融資対象の顧客の担保明細が更新されていないか，担保評価システムの評価日を確認する。

〔現状の融資りん議の業務〕

りん議書には最新の不動産担保評価帳票を添付する必要があるので，担保明細が更新されている場合は案件担当者に差し戻す。

〔WF システムの概要〕(3)

りん議書審査画面起動時には WF システムが担保評価システムに担保明細の最新情報を問い合わせる。

表1 担保評価

担保評価：案件番号（主キー），担保明細番号（主キー），担保評価額，担保物件，評価日。

下線③は，該当すれば差戻しと同じ処理をする条件である。現状では，承認者と決裁者が担保評価システムの評価日を見て，担保明細が更新されていればりん議書を差し戻している。WFシステムはこの確認を自動で行う。

りん議書作成時に取得した担保明細は，WFシステムの担保評価ファイルに評価日とともに保存されている。審査画面の起動時に担保評価システムへ最新情報を問い合わせ，担保評価システムの評価日が担保評価ファイルの評価日より新しければ，りん議書作成後に評価替えがあったと分かる。講評は，WFシステムの中のデータどうしを比べた答えや，担保評価システムのデータの判定条件があいまいな答えが多かったとしている。比べるのは「WFシステムの担保評価ファイル」と「外部の担保評価システム」の評価日である。

40字で比べる二つのデータの在りかと「新しい」という向きを書く。解答例は「担保評価ファイルの評価日より担保評価システムにある評価日が新しい場合」で34字。

採点講評（IPA）

設問2(2)は，正答率が低かった。業務要件を踏まえ，WFシステムのデータと外部システムである担保評価システムのデータを比較する際のシステム上の判断基準を問う問題であったが，WFシステム内のデータ同士を比較している解答や，担保評価システムのデータを判定する条件を明確にしていない解答が多かった。複数のシステムが連携して業務を実現するケースが増えてきており，そのような中でも業務と情報システムの機能及びデータの関係を正確に把握して設計することを心掛けてほしい。

本文の根拠

〔現状の問題点〕

目標期日の到来に気付かず期限を超過することがある。

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

目標期日までの残り日数が 3 営業日以下になっていることは，りん議書入力画面及びりん議書審査画面起動時に画面上で通知するだけでなく，日次で処理者に電子メールで通知する。

〔WF システムの概要〕(3)

回付経路に本部の回付先担当者が含まれている場合，WF システムは，顧客情報と融資期日を本部の回付先担当者に電子メールで通知する。

アラーム通知機能が通知するのは，顧客の信用格付の更新と，目標期日までの残り日数が3営業日以下になったことの二つである。信用格付の方は設問に挙がっているので，もう一つは目標期日の通知で解決される問題点になる。〔現状の問題点〕の「目標期日の到来に気付かず期限を超過することがある」がこれに当たる。

現状の問題点のうち，本部で処理状況が分からない問題は，回付の開始時に本部の回付先担当者へ電子メールで通知することで解決しており，アラーム通知機能によるものではない。

25字なので問題点の文をほぼそのまま使う。解答例は「目標期日の到来に気付かず期限を超過すること」で21字。

本文の根拠

〔現状の融資りん議の業務〕(2)

資金使途及び返済財源を確認し，基幹システムにある信用格付，財務分析結果及び過去のりん議結果を調査し

〔WF システムの概要〕

りん議書作成に必要な主なデータは複数の既存システムにある。これらのデータは，引き続き既存システムで管理する。

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

そのために，アラーム通知機能は，aにある最新の信用格付を問い合わせ，WF システムに保存した案件ファイルの信用格付と比較する。

信用格付がどのシステムにあるかを本文から探す。現状のりん議書作成業務に「基幹システムにある信用格付」とある。WFシステムは既存システムのデータを取得して保存するだけで，元のデータは引き続き既存システムで管理される。

したがって最新の信用格付は基幹システムにあり，WFシステムの案件ファイルにあるのはりん議書作成時に取得した時点の値である。両者を比べれば，同一顧客の別案件の調査などで信用格付が更新されたことに気付ける。

答えは「基幹システム」（6字）。担保評価システムは担保明細の在りかで，信用格付は持っていない。

本文の根拠

〔追加要望への対応〕

同一顧客で進行中の他の案件の内容を参照しやすくしてほしいという追加要望が提示された。

〔WF システムの概要〕(1)

この時点で案件ステータスは“受付”になる。

〔WF システムの概要〕(3)

決裁者が決裁の操作をすると案件ステータスは“決裁”になる。却下の操作をすると案件ステータスは“謝絶”になる。

〔現状の融資りん議の業務〕(3)

決裁者が決裁又は却下の判断をすると，りん議が完了する。

追加要望は「同一顧客で進行中の他の案件」を参照したいというものである。「他の案件」は設問で示された「案件番号が当該案件の案件番号と異なること」に当たる。残りは「同一顧客」と「進行中」の二つで，これを案件ファイルの属性で表す。

同一顧客は，案件ファイルの顧客番号が当該案件の顧客番号と同じであること。進行中は案件ステータスで表す。案件ステータスは受付で“受付”，りん議書入力画面に移ると“作成中”，回付を始めると“回付中”になり，決裁者の操作で“決裁”か“謝絶”になってりん議が完了する。完了していない“受付”“作成中”“回付中”が進行中である。

各35字で「どの属性がどうであること」を書く。解答例は「顧客番号が当該案件の顧客番号と同一であること」（22字）と「案件ステータスが“受付”，“作成中”又は“回付中”であること」（30字）。ステータスは三つとも挙げる。

本文の根拠

〔NFR システムの概要〕⑥

放水ロボットが放水している間，NSC 装置はa及び放水ロボットに指令を送信し，⑤の制御を繰り返す。

〔NFR システムの概要〕⑤

NSC 装置は，飛行型監視ロボットのカメラで撮影された映像を処理し，上空の風向及び風速，注水目標とその周辺の温度変化などを基に

〔消防本部のサーバに蓄積されたデータの活用〕

NSC 装置は，サーバにある消火対象施設の構造図を用いて，適切なbを設定できる。

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

火災の状況を分析し，適切な放水位置，注水目標を各放水ロボットに指令する。

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

また，地上から観測できない場所に対して注水目標を適切に設定できない。

aは，放水中に⑤の制御を繰り返すために，NSC装置が放水ロボットのほかに指令を送る相手である。⑤は飛行型監視ロボットのカメラの映像を基に注水位置のずれを補正する制御なので，飛行型監視ロボットに監視を続けさせる指令が要る。NSC装置が指令を送るロボットは放水ロボットと飛行型監視ロボットの二つしかない。

bは，NSC装置が消火対象施設の構造図を使って設定する「適切な」ものである。開発目標(4)に「適切な放水位置，注水目標を各放水ロボットに指令する」とあり，現行システムの問題点には，地上から観測できない場所に注水目標を適切に設定できないことが挙がっている。施設の構造が分かれば，どこに放水するか（注水目標），どこから放水するか（放水位置）を決められる。解答例はどちらも正解としている。

aは本文の語どおり「飛行型監視ロボット」。bは「放水位置」「注水目標」のどちらか一つを書く。

本文の根拠

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

複数の現行システムを運用する場合，全体を指揮する消防士は放水ロボットを操作する消防士に放水位置などを指示するが，“迅速性に欠ける”，“放水位置が適切でない”という問題がある。

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

さらに，火災現場で稼働中の全てのロボットに対して，搬送指令車 1 台だけで監視・指令が行えるようにする。

〔現行システムの概要〕

F 社の現行システムは，監視・指令装置を備えた搬送指令車及び放水ロボットで構成される。

表2 注記

複数のロボットを同時に運用する場合，搬送指令車で搬送するロボット以外は，搬送専用車両で搬送する。

現行システムは搬送指令車と放水ロボットが1組で，複数の放水ロボットを使うときは現行システムを複数台運用する（図1の現行システム1・2）。それぞれの搬送指令車に消防士が乗って操作し，全体を指揮する消防士が指示を出すので，迅速性に欠け，放水位置も適切にならないことがある。

NFRシステムでは，稼働中の全てのロボットを搬送指令車1台のNSC装置で監視・指令する。表2の注記のとおり，2台目以降のロボットは搬送専用車両で運ぶだけになる。搬送指令車ごとに分かれていた指令が1か所にまとまることが，複数の放水ロボットの運用で大きく変わる点である。講評によると，放水制御の自動化を書いた答えがあった。これは放水ロボット1台でも言えることで，「複数の放水ロボットの運用」についての答えにならない。

35字で「搬送指令車1台」と「複数のロボット」を入れる。解答例は「1台の搬送指令車で複数のロボットを操作できるようになること」で29字。

採点講評（IPA）

設問1(2)は，正答率は平均的であったが，放水制御の自動化について記述した解答が見受けられた。複数の放水ロボットの運用について改善できる点について問うていることを認識してほしい。

本文の根拠

冒頭

例えば，貯蔵する物質によっては消火に泡を用いるなど，消火方法が異なる場合があるほか，

表1 放水ロボット

消火のために，危険物の種類に応じて水又は泡を放射する。

問題文の冒頭で，石油・化学プラントでは貯蔵する物質によって消火に泡を用いるなど，消火方法が異なる場合があるとしている。放水ロボットも，危険物の種類に応じて水か泡かを切り替えて放射する。

したがって，危険物の種類と量が分かれば，水と泡のどちらを使うかなどの消火方法を決められる。構造図は放水位置や注水目標の設定にも使えるが，設問は危険物の情報も含めた「これらの情報」全体の目的を問うているので，消火方法の決定と答える。

15字なので短く「消火方法を決定するため」（11字）とする。

本文の根拠

〔消防本部のサーバに蓄積されたデータの活用〕

大規模・特殊火災のリスクがある施設及びその周辺の情報を平時からサーバに収集しておき，火災発生時に活用できるようにする。

表2 飛行型監視ロボット

自律飛行機能には，指定された位置までの飛行，火災現場全体の状況を把握するための周回飛行，特定箇所を監視し続けるための継続監視飛行がある。

表2 飛行型監視ロボット

監視範囲の構造物・障害物の位置を検出できる。

設問は，消火対象施設の情報だけでは飛行ルートの安全性が足りず，更に必要な情報を問うている。飛行型監視ロボットは火災現場全体を把握するための周回飛行をするので，飛ぶ範囲は消火対象施設の上空だけでなく，その周辺に広がる。施設の構造図だけでは，周辺のどこを安全に飛べるかが分からない。

本文は，サーバに施設だけでなく「その周辺の情報」も平時から収集しておくとしている。これを使って，施設周辺のどこが飛行可能かを事前に知っておけば，監視範囲の構造物・障害物をロボット自身が検出するのと併せて，安全な飛行ルートを組める。

25字で「消火対象施設周辺」と「飛行可能な場所」を入れる。解答例は「消火対象施設周辺の飛行可能な場所の情報」で19字。設問が「具体的に」と求めているので，「周辺の情報」だけで終わらせない。

本文の根拠

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

効果的な消火活動を目指す。

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

飛行型監視ロボットが取得したデータと，消防本部のサーバが保有する消火対象施設の情報とを AI 技術で処理することによって，火災の状況を分析し，適切な放水位置，注水目標を各放水ロボットに指令する。

飛行型監視ロボットのデータと消防本部のサーバの情報をAI技術で処理する場面は，開発目標(4)に書かれている。火災の状況を分析し，適切な放水位置，注水目標を放水ロボットに指令する。見出しは「効果的な消火活動を目指す」である。

この二つをつなげると，期待できることは，適切な放水位置・注水目標による効果的な消火活動になる。(5)の稼働率の改善は各ロボットの稼働中のデータを使うもので，飛行型監視ロボットのデータとサーバの消火対象施設の情報の組合せではない。

30字で手段（適切な放水位置，注水目標）と結果（効果的な消火活動）を両方書く。解答例は「適切な放水位置，注水目標による効果的な消火活動」で23字。

本文の根拠

表2 飛行型監視ロボット

自律飛行機能には，指定された位置までの飛行，火災現場全体の状況を把握するための周回飛行，特定箇所を監視し続けるための継続監視飛行がある。

〔NFR システムの概要〕①

なお，飛行型監視ロボットは，複数機を順次運用する。ただし，火災現場では，複数機を同時に飛行させる監視は行わない。

〔NFR システムの概要〕⑤

注水位置と注水目標のずれを補正すべきか，又は注水目標を変更すべきかを判断し

「自律飛行による監視を継続している」ときは，特定箇所を監視し続ける継続監視飛行をしている。継続監視飛行では注水目標付近しか見ていないので，火災現場のほかの場所で状況が変わっても気付けない。火災現場全体の状況を把握するのは周回飛行である。

一方，火災現場では複数機を同時に飛ばさないので，継続監視用と周回用に2機を分けることはできない。1機で継続監視飛行を続けながら，周回飛行も併せて行う必要がある。講評によると，「周回飛行へ切り替える」とだけ書いた答えが見受けられた。周回飛行だけにすると，⑤の注水位置の補正に要る継続監視ができなくなる。

30字で「継続監視飛行」と「周回飛行」の両方を書き，組み合わせることを示す。解答例は「継続監視飛行だけでなく，周回飛行も併せて行う。」で23字。

採点講評（IPA）

設問2(3)は，正答率はやや低かった。“周回飛行へ切り替える”とだけ記述した解答が見受けられた。周回飛行による火災状況の変化の検出だけを行うのではなく，継続監視飛行も続ける必要があることを考慮し，継続監視飛行と周回飛行の組合せによる監視が効果的であることに気付いてほしい。

本文の根拠

〔NFR システムの概要〕⑥

NSC 装置は，これらの指令のデータと処理に用いたデータとをリンクさせ，消防本部のサーバに送信して蓄積する。

〔NFR システムの概要〕⑥

複数の放水ロボットを運用する場合は，①〜⑤の指令・制御を各ロボットに順次行う。

表1 放水ロボット

・高精度 GPS 受信機

サーバには，複数のロボットのセンサデータと，NSC装置が各ロボットに順次出した指令のデータが蓄積される。⑤の制御は放水中に繰り返されるので，同じロボットについても指令とセンサデータが何度も記録される。あるセンサデータがどの指令と対応するかを後から突き合わせるには，それぞれがいつのデータか（時刻）と，どこのデータか（位置）が分かる必要がある。

位置は，放水ロボットと飛行型監視ロボットがどちらも高精度GPS受信機を搭載しているので記録できる。飛行型監視ロボットが撮った場所と，放水ロボットのいる場所や注水目標とを，位置で結び付けられる。

字数の制限はない。「時刻情報」「位置情報」のように情報の種類で答える。

本文の根拠

表1 放水ロボット

ホース敷設ユニットは，高耐熱性を備えた最大 300 メートルの延長用消防ホースを敷設できる。

〔NFR システムの概要〕④

放水ロボットが放水位置に到着後，NSC 装置は水源までの走行ルートを決定し，ホース敷設ユニットに指令する。ホース敷設ユニットは，延長用消防ホースを敷設しながら水源まで自律走行する。

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

複数の放水ロボットが連携して消火活動を行えるようにする。

放水位置を決めた後，水源はホース敷設ユニットが延長用消防ホースを敷設しながら走って行ける場所でなければならない。敷設できるホースは最大300メートルなので，放水位置から水源までの敷設ルートの長さがこれに収まる必要がある。

複数の放水ロボットを運用する場合はさらに，各放水ロボットの走行ルートや敷設したホースが互いにじゃまにならないようにしなければならない。ホース敷設ユニットはホースを敷きながら走るので，ほかのロボットの走行ルートをホースがふさぐおそれがある。講評は，ホースの長さだけを書いた答えが見受けられたとし，走行や水源の確保で相互に支障がないようにする必要を挙げている。

40字で「ホースの敷設ルートの長さ」と「各ロボットの走行に支障がないこと」の二つを入れる。解答例は31字。

採点講評（IPA）

設問3(2)は，正答率はやや高かったが，消防ホースの長さについてだけ記述した解答が見受けられた。複数の放水ロボットが協調して消火活動を行う場合に，各放水ロボットの走行，水源の確保において相互に支障がないように運用する必要があることを理解してほしい。