令和5年度 春期 午後Ⅰ

本文の根拠

〔システム監視の改善〕

しきい値を現在の 80％から 90％に変更する案を検討したが，インシデントが発生した際の業務への影響を最小限にするための対応を考慮すると

〔システム監視の概要〕

インシデント対応に時間を要する場合は，CPU 使用率が 90％以上となって，生産システムの利用者に業務影響を及ぼすインシデント（以下，業務影響有インシデントという）になる前に，利用者に連絡し，業務量を一時的に抑制してもらう。

しきい値を90％に上げると，警告が出るのはCPU使用率が90％を超えてからになる。ところが90％以上は，すでに利用者の業務に影響が及んでいる水準である。

いまの運用では，80％でしきい値超えを検知してから90％に達するまでの間に，利用者へ連絡して業務量を抑えてもらっている。しきい値を90％にすると，この「影響を最小限にするための対応」を取る時間そのものが無くなる。警告の数は減るが，インシデントが起きたときの被害は大きくなるので，改善策として成り立たない。

25字に収めるときは「何のための時間が無くなるのか」を主語に立てる。解答例は「インシデント対応を行うための時間が減少するから」で24字。

採点講評（IPA）

設問1(1)は，正答率がやや低かった。業務影響有インシデントが発生することだけを記述した誤答が多かった。インシデントが発生した際の業務への影響を最小限にするための対応に着目して解答してほしい。

本文の根拠

表4 項番1

設定されたしきい値が“指定する基準値”を超える時間帯がある場合，しきい値設定の警告が表示される

表4 設定内容

“指定する割合”は 5％ポイントとする，“指定する基準値”は 80％とする

この警告は「CPU使用率がしきい値を超えた」という知らせではない。Rソフトが自動で決めたしきい値そのものが，基準値の80％を超えたという知らせである（表4の注1が，しきい値85％・基準値80％の例を挙げている）。しきい値超過の通知は項番2の機能で，こちらとは別物である。

しきい値は，過去4週間の同じ曜日・同じ測定時間帯の平均に5％ポイントを足した値である。それが80％を超えたということは，その時間帯のCPU使用率が平常時から75％を超えているということになる。そのまま高いしきい値で監視を続ければ，異常を検知できる幅が狭くなってしまう。

したがって確認すべきは，自動で設定されたしきい値を監視の基準として使ってよいかどうかである。解答例は「Rソフトが設定したしきい値の妥当性」で18字。

採点講評（IPA）

設問1(2)は，正答率が平均的であった。発生時刻，対象サーバなどしきい値超えが発生した際の確認と誤って解答した受験者も多かった。警告のメッセージが出力されるのはどのような場合なのかに着目して正答を導き出してほしい。

本文の根拠

表4 項番1

4 週間分の同じ曜日，及び同じ“測定時間帯”の値の平均値に“指定する割合”を加算した値をしきい値として設定する

表5

曜日と測定時間帯を行に，月曜日 10:31〜10:40，水曜日 13:31〜13:40，金曜日 16:51〜17:00 を列にとった表。CPU 使用率の平均値は，4 週間前が 51％，67％，74％。3 週間前が 49％，64％，72％。2 週間前が 47％，66％，69％。1 週間前が 45％，67％，73％。

しきい値は「同じ曜日・同じ測定時間帯の過去4週分の平均値」に「指定する割合（5％ポイント）」を足して決まる。

水曜日13:31〜13:40の4週分は67，64，66，67なので，平均は（67＋64＋66＋67）÷4＝66。これに5を足して71となる。

計算の仕方に迷ったら，値が入っている月曜と金曜で検算できる。月曜は（51＋49＋47＋45）÷4＝48で，5を足して53。金曜は（74＋72＋69＋73）÷4＝72で，5を足して77。どちらも表5の値と一致するので，読み取りが合っていると確かめられる。

本文の根拠

冒頭

W 社は，土曜日，日曜日及び年末年始を休業日としており，休業日以外の日を勤務日としている。W 社の従業員は，勤務日の 9 時から 18 時まで勤務している。

〔Rソフトの検証〕

監視を開始して約 1 か月が経過した 1 月上旬のある日に，しきい値の超過が多く発生することがあった。

表4 項番1

4 週間分の同じ曜日，及び同じ“測定時間帯”の値の平均値に“指定する割合”を加算した値をしきい値として設定する

監視を始めたのは2022年12月1日で，異常が出たのは1月上旬。しきい値は直前4週間の同じ曜日から計算されるので，1月上旬のしきい値には年末年始が計算元として入っている。

年末年始は休業日で従業員が出勤していないから，CPU使用率は勤務日よりも低い。低い値が平均に混ざれば平均が下がり，そこから決まるしきい値も下がる。下がったしきい値で勤務日を監視すれば，いつもどおりの負荷でもしきい値を超えてしまう。これが「しきい値の超過が多く発生」した理由である。

だから休業日を除外日に設定して，学習の対象から外す必要がある。50字には「休業日のCPU使用率は勤務日より低い」と「それを学習するとしきい値が下がる」の2つを入れる。解答例は44字。

本文の根拠

〔システム監視の概要〕

しきい値超えが発生した場合は，イベント記録簿に，発生時刻，対象サーバ及びメッセージ内容（以下，これらをイベント情報という）を記録する作業が必要であり，運用業務工数の多さが，監視チームの負担となっていた。

表4 項番2

算出された値がしきい値を超過した場合，イベント情報及び設定されたしきい値を R ソフトに記録し

改善前は，しきい値超えが起きるたびに監視チームが手でイベント記録簿へ書き写していた。この工数が負担になっていた。

Rソフトの項番2は，しきい値を超過したときにイベント情報を自動で記録する。さらに下線（ウ）の直前にあるとおり，記録した内容は出力できる。つまり手で書き写す作業そのものが要らなくなる。

40字には「自動で記録される」と「イベント記録簿として出力できる」の2つを入れる。記録されるだけでは記録簿にならないので，出力できることまで書く。解答例は33字。

本文の根拠

〔インシデント発生の未然防止への活用〕

当該インシデントが発生しなかった日と同じ曜日，同じ時間帯の CPU 使用率は 50％程度であったが，当該インシデントの発生日は，CPU 使用率 70％の状態が 1 時間継続し，その後 CPU 使用率は 80％超に上昇して監視システムがしきい値超えを検知した。

〔システム監視の改善〕

AI を用いて，過去の CPU 使用率の傾向を学習し，曜日や時間帯に合わせた最適なしきい値で監視する機能

従来の監視はしきい値が全時間帯一律80％だったので，CPU使用率が70％で1時間続いても何も起きない。80％を超えて初めて検知するため，気付くのが遅れていた。

Rソフトは，その曜日・その時間帯の過去4週平均に5％ポイントを足した値をしきい値にする。この時間帯の平常時は50％程度なので，しきい値は55％前後になる。70％が続けばその時点で超過として検知でき，80％に達するのを待たずに済む。

つまり「いつもと違う推移」を早く捕まえられる，というのが理由である。解答例は2通りあり，同じ曜日・同じ時間帯と違う傾向を検知できると書いても，70％以上が1時間継続する状態を発見できると数値で書いてもよい。どちらも35字。

採点講評（IPA）

設問3は，正答率が平均的であった。前日の13時に業務影響有インシデントの発生を予測できる旨を記述した誤答が多かった。過去に発生した業務影響有インシデントのCPU使用率の推移に着目して解答してほしい。

本文の根拠

〔情報セキュリティ対策の現状〕

複数の機器のログを突き合わせたときに，それぞれのシステム時刻が正確ではなく，時間軸での発生事象の流れを正確に把握できないことがある。

表2 記録

NTP サーバを導入することによって各 J 社機器が常に正確な時刻でログを記録する，複数のログを突き合わせたときに空欄 a できるようにする。

空欄の前後が，課題の文とほぼ同じ形になっている。課題は「複数の機器のログを突き合わせたときに…時間軸での発生事象の流れを正確に把握できないことがある」，対策は「複数のログを突き合わせたときに空欄aできるようにする」。

できなかったことができるようになる，という対応なので，課題の文から「できない」の手前をそのまま持ってくればよい。

25字。解答例は「時間軸での発生事象の流れを正確に把握」で18字。「時系列でインシデント状況を正確に把握」と言い換えてもよい。設問が「具体的に」と言っているので，「ログを分析」のような漠然とした書き方は避ける。

本文の根拠

図1 凡例

LAN1 はインターネットに接続するサーバを設置するセグメント，LAN2 は LAN1 及び LAN3 だけからアクセス可能なセグメント，LAN3 は営業部の PC を設置するセグメント

〔情報セキュリティ対策の現状〕

情報セキュリティインシデントが発生した場合は，J 社機器のログを分析し，原因を調査している。

表2 管理

災害やサイバー攻撃などによって J 社内で管理しているログの消失などの被害が発生するリスクがあるので可用性の確保が必要である

図1の凡例が2つのセグメントの性格を分けている。LAN1はインターネットに接続するサーバを置く場所で，外部からの通信が届く。LAN2はLAN1とLAN3からしかアクセスできないので，インターネットから直接は届かない。

ログがどういうものかを考える。インシデントが起きたときに原因をたどる唯一の手がかりであり，攻撃する側から見れば，痕跡を消すために真っ先に狙いたい対象である。外部から届く場所に置けば，改ざんや消去の的になる。

したがってLAN2に置く。営業部のPCも情報システム部の各サーバも，LAN1・LAN2・LAN3のいずれかにあるので，LAN2からでもログは集められる。

理由は40字。解答例は「内部セグメントは，外部から攻撃を受けにくく，ログの改ざんから守れるから」で34字。「LAN2のほうが安全だから」では，何の脅威から何を守るのかが言えていない。

採点講評（IPA）

設問1(2)の解答で，セグメントを選択する理由は，正答率がやや低かった。情報セキュリティ管理の観点から，セキュリティへの脅威やリスクといった内容を解答してほしい。

本文の根拠

表2 管理

新たに導入するログ管理システムで一元管理する各種ログについて空欄 b し，被害発生時に速やかに復旧できるようにする。

図1

クラウド事業者はストレージサービスとして業務データを保持し，インターネット経由で接続される。

冒頭

ストレージサービスでは，利用者の要求に応じて容量を動的に拡張できる。なお，クラウド事業者とのインターネットを介した通信は，セキュリティ上の安全性が確保されている。

課題は「J社内で管理しているログの消失」である。ログ管理システムで一元管理すると，かえって1か所にまとまるので，そこがやられれば全部失う。J社の外に写しを置く必要がある。

図1でJ社の外にあるのはクラウド事業者のストレージサービスだけである。しかも容量を動的に拡張できるので，増え続けるログの置き場所として都合がよく，通信の安全性も確保されていると本文が断っている。

30字。解答例は「ストレージサービスを使って，バックアップを保存」で22字。設問が「図1中の字句を使って」と指定しているので，「クラウド」ではなく「ストレージサービス」と書く。

本文の根拠

〔未知マルウェアへの対応〕

検知対象外とする実行ファイルの指定ができる。L サーバに検知対象外とする実行ファイルを登録すると，登録された実行ファイルのハッシュ値が，L ソフトを導入している J 社機器に自動的に配付される。

〔インシデントの発生とその対応〕

検体は，安全な実行ファイルであると確認できた。検体の挙動を L ソフトが過検知して検知メッセージを表示した

L社が安全と判定したのだから，この業務ツールはもう検知しなくてよい。Lソフトには検知対象外とする実行ファイルを指定する機能があるので，これを使う。

登録先はLサーバである。登録すればハッシュ値が各J社機器へ自動的に配付されるので，1台ずつ設定して回る必要がない。今回は複数のPCで検知されているので，配付の仕組みに乗せることに意味がある。

30字。解答例は「当該業務ツールの実行ファイルをLサーバに登録する。」で25字。登録先を落として「検知対象外にする」だけだと，どこでどう設定するのかが決まらない。

本文の根拠

図2

③営業員は，承認を得てから業務ツールを作成し，完成後に M 氏に利用申請を行う。④M 氏は，完成した業務ツールの利用申請を承認する。

表1

L ソフトが採取した不正プログラムの検体を解析しマルウェアなのか又は安全なファイルなのかの判定を行う。

〔インシデントの発生とその対応〕

図2の④の業務ツール利用申請の承認前に

追加する手順の目的は，本文が「当該業務ツールが安全なファイルであることを確認する」と書いている。確認せずにいきなり検知対象外へ登録してしまうと，本物のマルウェアを素通しする仕組みを作ることになる。順番を取り違えないこと。

手順は2段になる。まず情報システム部で，完成した業務ツールをLソフトで動かしてみる。何も検知されなければそのまま承認へ進める。検知された場合は，それが過検知なのか本物なのかを自分たちでは判定できないので，L社の保守サービスに解析を依頼して判定を受ける。

安全と分かってから，設問2(1)のLサーバへの登録に進む。こうしておけば，今回のように業務を止めてから調べる事態にならない。

50字。解答例は「完成した業務ツールをLソフトでテストし，検知した場合は安全かどうかの判定をL社に依頼する。」で44字。

採点講評（IPA）

設問2(2)は，正答率がやや低かった。安全なファイルであることの事前確認なしで業務ツールを検知対象外として登録する誤答が多かった。情報システム部でテストを行い，必要に応じて保守サービスを利用して安全なファイルかどうかを確認する具体的な手順を導き出してほしい。

本文の根拠

〔情報セキュリティ対策の現状〕

情報セキュリティインシデントが発生した場合は，インシデント対応手順に従って即時に対応し，解決に時間が必要なインシデントが発生したときでも，当日中にはインシデントの解決方法を決定することなどを定めている。

表1 注記

標準サポート保守サービスで受付時刻が 18 時以降の場合，解析に時間が掛かるときは回答が翌営業日になることがある。

〔インシデントの発生とその対応〕

ある日の 18 時 30 分頃に，営業部にある複数の営業員の PC で，不正プログラムが検知された。

運用ルールは「当日中にはインシデントの解決方法を決定する」である。今回，解決方法を決められたのは，L社から「安全な実行ファイルだった」という回答が来たからで，回答が無ければ過検知なのか本物なのかが分からず，何も決められない。

ところが標準サポートには注記がある。18時以降に受け付けた場合，解析に時間が掛かると回答が翌営業日になることがある。今回の検知は18時30分頃で，まさにその時間帯だった。19時50分に回答が来たのは運がよかっただけである。

営業システムの運用時間は19時までなので，18時以降にインシデントが起きることは今後もある。そのたびに運用ルールを守れない恐れが残る。24時間365日のプレミアムサポートなら，この穴が塞がる。

40字。解答例は「解析依頼時刻が18時以降の場合，L社の回答が翌営業日になる可能性があるから」で37字。「24時間対応が必要だから」では，どの運用ルールがどう守れないのかが言えていない。

採点講評（IPA）

設問3は，正答率がやや低かった。標準サポートの保守サービスでは，解析依頼の時間帯によっては，情報セキュリティ管理の運用ルールが守れない場合があることを具体的に解答してほしい。

本文の根拠

図1 課題3

営業所員は月に一度，基幹システムの施工情報や報告情報などを使って手作業で施主向け報告書を作成する。

〔改善策の検討〕

G システムは，保守時間帯以外は常に利用可能であり，全ての操作履歴を利用者 ID とともに G システムのログファイルに記録する。

〔改善策の検討〕

(2) 施主向け機能：基幹システムの施工情報を編集し，施主向けに情報提供する。

空欄aは表1の(2)の2つ目の効果で，1つ目が営業所員の作業が不要になる話なので，こちらは施主にとって何が変わるかを書く。

これまでは，営業所員が月に一度手作業でまとめた報告書を受け取っていた。次の報告まで1か月あるので，その間の進捗は分からない。

Gシステムは保守時間帯以外は常に利用可能で，図2のとおり施主のPCからインターネット経由でつながる。だから施主は，待たずに，そのときの最新の内容を見られる。

20字。解答例は「最新の施主向け報告書を確認すること」で17字。「いつでも」という時間の面から書いてもよい。

本文の根拠

図1 課題2

現場作業員は毎日営業所に戻ってから，現場で撮影した写真を基幹システムのサーバに格納して報告書をまとめる作業（報告作業）を行っており，報告作業の大半が残業時間となっていた。現場作業員の残業時間の多さが課題となっている。

表1

現場作業員が営業所に戻ることなく報告作業を行うことで残業時間を抑制することができる。

冒頭

長時間労働の常態化や深夜作業といった過酷な労働環境を改善することが経営課題となっている。

「現場作業員への」効果と限定されているので，まず対象を絞る。図1の課題1は工事関係者の情報閲覧，課題3は営業所員と施主の話で，現場作業員に当たるのは課題2だけである。

課題2は残業時間の多さで，表1の効果も「残業時間を抑制することができる」となっている。

定量的に測るとあるので，時間という数えられる形にする。導入の前後で残業時間を比べれば，削減量や削減率が出る。これは経営課題の「長時間労働の常態化」の改善を測る数字でもある。

10字。解答例は「残業時間の削減量」で8字。

本文の根拠

〔新サービスの準備〕

表2の完了基準を設け，サポート終了の 1 週間前時点でサポート内容の状況を測定し，全ての完了基準を満たしていれば予定どおりに初期サポートを完了する。ただし，項番 3 が完了基準に満たない場合，項番 3 のサポート終了日を 1 週間延長し，サポート終了の 1 週間前時点で再度状況の測定を行う。

表2 項番3

項番3はインシデントの解決で，完了基準は未解決インシデントなし。

完了の判定をいつ行うかが鍵である。判定はサポート終了の1週間前で，その時点で未解決のインシデントが無ければ予定どおり完了する。

つまり判定日から実際の終了日までに1週間の隙間がある。この1週間のあいだに新しく起きたインシデントは，判定の対象に入っていない。終了の時点でまだ解決していなければ，G社要員は引き上げてしまうので，情報システム部が引き継ぐことになる。

判定の時点で未解決のものがあれば，項番3のサポート終了日が1週間延長される。そちらは延長して解決させる仕組みがあるので，引継ぎの対象にはならない。

40字。解答例は「初期サポート完了判定後に発生し，初期サポート終了時点で未解決のインシデント」で37字。「未解決のインシデント」だけでは，延長される分と区別できない。完了判定の後に発生した，という条件を入れる。

採点講評（IPA）

設問2は，正答率が低かった。初期サポートの完了時におけるインシデント対応に関する業務引継ぎについて，一般的な内容を解答する受験者が多かった。初期サポートの内容と完了基準の内容をよく理解し，設問に対応した解答をしてほしい。

本文の根拠

〔新サービスの展開〕

システムを使い慣れていない作業員が理解できない専門用語が，利用者マニュアルにそのまま用いられていたことと，鉄道事業に特化した工事で使われている用語で記述されていないことが原因と考えられた。

冒頭

工事内容には，一般の建設工事のほか，一部鉄道事業に特化した軌道や土木構築物に関する工事を含んでいる。

原因は2つ書いてある。理解できない専門用語がそのまま使われていること，そして鉄道事業に特化した工事で使われている用語で書かれていないこと。

2つとも，E社の現場で通じる言葉になっていない，という一点に集まる。Gシステムは建設業界向けのパッケージなので，マニュアルも業界一般の言葉で書かれており，E社が請け負う鉄道向けの工事で使う呼び方とは違う。

だからE社で使われている用語や表現に直す。用語集を別に付けるという手もあるが，マニュアル自体が読めない状態なので，本文に手を入れるほうが直接である。

20字。解答例は「E社で使われている用語や表現に変更」で17字。

本文の根拠

〔新サービスの展開〕

F 氏は，“FAQ の材料として過去に他社で G システムを導入した際に発生した，利用方法についてのよくある問合せの提供”を G 社に依頼し，G 社は，よくある問合せの一覧表を F 氏に提供した。

〔新サービスの展開〕

利用方法に関する同様の問合せは，説明会の後もしばらくの間続いたが，G 社の初期サポートの対応によって，問合せの 9 割以上は即時に解決していた。

〔新サービスの展開〕

第 1 段階は本社と東京営業所に，第 2 段階はその他四つの営業所を含む全社に，展開することとなった。

G社からもらった一覧表は「他社で」発生した問合せである。E社の現場で実際に何が分からなかったかは含まれていない。設問が言う「E社現場の特性」はここに掛かる。

E社にはすでに材料がある。第1段階の展開で，説明会の後もしばらく問合せが続き，その9割以上をG社が解決している。用語が通じないことから来た問合せも，そこに含まれている。

FAQを整備するのは第1段階と第2段階のあいだなので，この実績をそのまま使える。第2段階で展開する四つの営業所でも，同じ問合せが起きると見込める。

25字。解答例は「第1段階の展開で実際に発生した問合せの内容」で21字。

採点講評（IPA）

設問3(2)は，正答率がやや低かった。FAQの整備が第1段階展開と第2段階展開の間で行われたこと及びE社現場の特性を踏まえて，FAQに追加する内容を導き出してほしい。

本文の根拠

〔改善策の検討〕

全ての操作履歴を利用者 ID とともに G システムのログファイルに記録する。

図2

G システムとして G システムサーバと利用者情報・権限情報・ログ情報のデータベースがある。

誰が使っているかを知るには，操作の記録を見るしかない。Gシステムは全ての操作履歴を利用者IDとともに記録している。

設問が「図2中の字句を使って」と指定しているので，図2のデータベースの並び（利用者情報・権限情報・ログ情報）から「ログ情報」を選ぶ。

本文が「その結果をGシステムの利用者情報に照らし合わせた」と続けているのも手がかりになる。ログ情報に現れる利用者IDと，利用者情報にある本来使うべき現場作業員を突き合わせれば，使っていない2割を割り出せる。

10字。解答例は「ログ情報」で4字。

本文の根拠

冒頭

E 社では，現場作業員の人手不足が深刻化していて，DX に取り組むことによって，長時間労働の常態化や深夜作業といった過酷な労働環境を改善することが経営課題となっている。

〔全社への展開と定着の確認〕

“システムのユーザビリティが悪く操作しづらい”，“操作方法が分からない”，“営業所での報告作業が習慣化している”といった意見が上がった。

〔新サービスの提案〕

③ 全ての現場作業員に新サービスの利用が定着するようにすること

ヒアリングで出た3つの意見を分けて見る。ユーザビリティと操作方法は，画面を直したり教えたりすれば情報システム部で手当てできる。ところが「営業所での報告作業が習慣化している」は，仕事のやり方そのものである。情報システム部が頼んでも変わらない。これが深刻度の高い阻害要因である。

定着しなければ，報告作業のために営業所へ戻る人が残り，残業時間は減らない。つまり長時間労働の改善という経営課題が解決しない。

経営課題であるからこそ，経営層が自ら現場に語る意味がある。情報システム部の都合ではなく会社として取り組むことだと伝われば，習慣を変える理由になる。

30字。解答例は「経営課題の解決には，新サービスの定着が必要だから」で24字。「現場が使ってくれないから」では，なぜ経営層でなければならないのかが言えていない。

採点講評（IPA）

設問4(2)は，正答率が平均的であった。設問では，現場に新システムの定着を図るだけでなく，DXによって経営課題の解決に取り組むことへの理解が求められている。近年，DXの取組として提供されるITサービスの事例も多く，ITサービスマネージャの役割が重要である。