令和6年度 春期 午後Ⅰ

本文の根拠

表1

情報系サービスは，営業店での販売，相談，分析の支援などを内容とし，顧客は T 事業部，サービス時間は平日の 6 時から 21 時まで，サービスコンポーネントはサーバ 80 台とストレージ 100TB。

〔Rクラウド利用料の見積り〕

情報系サービスのサーバは，“①従量制料金”の価格モデルの場合，サービス時間だけ利用するので

サービス時間は平日の6時から21時までなので，1日15時間。1年の平日は260日と設問に与えられている。

15 × 260 ＝ 3,900時間。

「サービス時間だけ利用する」と本文が断っているので，24時間ではなく15時間で数える。ここを24時間にすると，次の設問の価格モデルの比較まで狂う。

本文の根拠

表3 サーバサービス

①従量制料金は 1 台当たり 100 円／時間，②使用量予約は従量制料金を 25％割引して年単位に換算。

〔Rクラウド利用料の見積り〕

② 使用量予約：一定のリソース使用量を，1 日 24 時間で 365 日分年間予約することで，予約した年単位のリソース使用量分の従量制料金に年間割引を適用する。

サーバ1台の年額を，2つの価格モデルで出して比べる。

①従量制は，使った時間だけ払う。100円 × 3,900時間 ＝ 390,000円。

②使用量予約は，1日24時間で365日分をまとめて予約する。時間数は 24 × 365 ＝ 8,760時間。25％引きなので 100円 × 8,760 × 0.75 ＝ 657,000円。

①のほうが安い。割引率は25％あるが，予約では動かさない夜間や休日のぶんまで払うことになり，時間数が3,900時間に対して8,760時間と2倍以上になる。25％の割引では埋まらない。

平日の日中しか動かさないサービスでは，予約より従量制が有利になる，という形で覚えておくとよい。

本文の根拠

表1

サービスコンポーネントはサーバ 80 台とストレージ 100TB

〔情報系サービスの移行計画〕

2024 年度期初に 2023 年度期初に比べて 20％の容量・能力増加が必要で

表3 ストレージサービス

①従量制料金は 10GB 当たり 100 円／月，②使用量予約は従量制料金を 25％割引して年単位に換算。

表1 注記

1TB（テラバイト）は 1,000GB（ギガバイト）とする。

落とし穴は容量の増加である。表1の100TBは2023年4月時点の値で，2024年度期初には20％増やす必要がある。

100TB × 1.2 ＝ 120TB ＝ 120,000GB。

従量制は10GB当たり100円／月なので，月額は 120,000 ÷ 10 × 100 ＝ 1,200,000円。年額は 14,400,000円。

ストレージは“②使用量予約”を適用する方針なので25％引き。14,400,000 × 0.75 ＝ 10,800,000円，つまり10,800千円。

表4のサーバ側で検算できる。サーバも20％増で 80台 × 1.2 ＝ 96台。①従量制なので 100円 × 3,900時間 × 96台 ＝ 37,440,000円。表4に書かれている37,440千円と一致する。20％増を忘れていればここが合わないので，見積りの前に必ず突き合わせる。

採点講評（IPA）

設問1(3)は，正答率が低かった。予算の見積りでは，需要の変化，容量・能力の変化を考慮して見積りを行い，予算化することが必要であることを理解してほしい。

本文の根拠

〔サービス事業本部への費用の提示〕

直接費は実績に基づき各事業部に課金している。その際に，関連する作業負荷，容量・能力の情報も報告し，予算及び需要見込みに対して実績が適切かどうかを各事業部も把握できるようにしている。

〔Rクラウド利用料の見積り〕

① 従量制料金：サーバは時間単位，ストレージは月単位に割り当てたリソース使用量に応じて課金額が決まる方式

「新たに割り当てる直接費」は，移行後のRクラウド利用料である。移行前のハードウェアリース料などに代わって，表4のとおり外部委託費として直接費に入る。

Rクラウドの料金は，サーバなら時間単位，ストレージなら月単位の使用量で決まる。つまり費用の裏付けになる実績は，使用量そのものである。

金額だけを渡しても，T事業部は需要見込みとの差を追えない。見込みより使ったから増えたのか，使用量は見込みどおりなのかが分かれるからである。使用量を並べて初めて差異の原因が見える。

30字。解答例は「Rクラウドのサーバとストレージの使用量」で18字。サーバとストレージの両方を挙げる。

本文の根拠

冒頭

運用人件費及び DC 使用料は，費用の総額を各事業部に按分し，間接費として配賦している。なお，DC 使用料は固定料金制の長期契約となっており，2026 年 3 月まで費用の変動はない。

〔情報系サービスの移行計画〕

情報系サービスで専用に使用する IT インフラ群を外部のクラウドサービスに移行し，2024 年 3 月から利用を開始する移行方針を立てた。なお，運用要員は IT サービスのシステム運用業務を行っており，移行後も運用業務量の変動はない予定である。

冒頭

Q 社の IT インフラ群は，V 社が運営するデータセンター（以下，DC という）にハウジングされている。

間接費は運用人件費とDC使用料の2つしかない。移行後どうなるかを1つずつ見る。

運用人件費は，本文に「移行後も運用業務量の変動はない」とあるので，これまでどおり按分してよい。

DC使用料は事情が違う。情報系サービスのITインフラ群はDCから出ていくので，T事業部はDCを使わなくなる。それでも総額を按分し続ければ，使っていない設備の費用をT事業部が負担することになる。しかもDC使用料は2026年3月まで固定で総額は下がらないので，移行して費用を抑えたはずのT事業部にそのしわ寄せが行く。

30字。設問が聞いているのは間接費の配賦である。Rクラウド利用料は直接費なので，ここで答えるものではない。

採点講評（IPA）

設問2(2)は，正答率が低かった。直接費であるクラウド利用料金について誤って解答した受験者も見受けられた。ITサービスを移行した場合，直接費だけでなく間接費の配賦方法にも着目することが必要なことを，是非知っておいてもらいたい。

本文の根拠

〔予算と費用実績の管理に向けた検討〕

2024 年 3 月時点で，販売キャンペーンの規模などは不透明で，販売キャンペーンの規模を拡大して実施することになった場合に，現時点の販売キャンペーンの計画よりも需要は増加することが考えられる。

〔予算と費用実績の管理に向けた検討〕

T 事業部と IT インフラ部のプロジェクト担当者は，リソースオンデマンドを使って迅速にリソース拡張を行うことで，急増する需要に対応できることを確認している。

〔Rクラウド利用料の見積り〕

① 従量制料金：サーバは時間単位，ストレージは月単位に割り当てたリソース使用量に応じて課金額が決まる方式

予算に織り込めるのは，2024年3月時点で分かっている販売キャンペーンの計画までである。規模が拡大すれば，予算に入っていない需要が出てくる。

そこにリソースオンデマンドがある。管理ツールで手早くリソースを増やせるので，需要そのものには応えられる。だが料金は従量制なので，増やしたぶんはそのまま費用になる。

つまり「需要に応えるために増やした結果，予算を超える」というのがリスクである。増やせること自体が問題なのではなく，増やすと費用が予算を超えるところが予算管理上のリスクになる。

35字。解答例は「急増する需要に対応してリソースを拡張し，予算を超過する。」で27字。需要が増えるとだけ書くと予算の話にならないので，予算超過まで言い切る。

本文の根拠

〔予算と費用実績の管理に向けた検討〕

S 氏は，予算管理者として，予算がどのように執行されるかを監視する責任がある。

〔予算と費用実績の管理に向けた検討〕

事業環境変化に対応してタイムリーにリソースオンデマンドを活用できるように

〔情報系サービスの移行計画〕

R 社から管理ツールとその使用権限が与えられ，これによってリソースオンデマンドの機能を使うことができる。

条件は2つある。タイムリーにリソースオンデマンドを使えること，そして予算管理者としての対策であること。

拡張を禁じたり，そのつど上位者の判断を待つ形にすると，タイムリーさが失われる。逆に自由に増やさせれば予算を超える。どちらも条件を満たさない。

そこで，予算を超える支出をするときの承認の手順をあらかじめ決めておき，利害関係者と合意しておく。手順が決まっていれば，その場で判断して拡張できる。事前に決めておくから，タイムリーさと予算の監視が両立する。

40字。リソースにしきい値を決めて監視するのは容量・能力管理であって，予算の話ではない。使ってから請求するのでは，執行を監視する責任を果たしたことにならない。

採点講評（IPA）

設問3(2)は，正答率が低かった。リソースにしきい値を設定して監視するという容量・能力管理の観点での解答や，予算超過した費用支出の後に請求するという解答が見受けられた。予算の超過が見込まれる場合は，費用支出の前に対応方法について合意形成できるような手順を整備することが，ITサービスマネージャの重要な役割である。

本文の根拠

計算式

全台の年間稼働予定時間の合計 － 全台の年間故障修復時間の合計

表1

自動券売機は 80 台，7,000 時間，7 回，5.0 時間，0 時間，年間稼働率は空欄 a。

式の分子は「稼働予定時間の合計 － 故障修復時間の合計」である。故障修復時間は表に直接は載っていないので，故障回数と1回当たりの修復時間から作る。

自動券売機は80台。稼働予定時間の合計は 80 × 7,000 ＝ 560,000時間。故障修復時間の合計は 80 × 7回 × 5.0時間 ＝ 2,800時間。

（560,000 － 2,800）÷ 560,000 ＝ 0.995，つまり99.50％。

台数は分子・分母の両方に掛かるので，1台当たりで計算しても同じ値になる。（7,000 － 35）÷ 7,000 ＝ 0.995。

計画停止時間を引きたくなるが，引いてはいけない。表1の注1のとおり，計画停止のぶんは稼働予定時間からあらかじめ差し引かれている（自動改札機だけ7,000時間ではなく6,990時間なのがその印）。自動改札機で検算すると（6,990 － 12×1.5）÷ 6,990 ＝ 0.99742…で，表の99.74％と一致する。

本文の根拠

冒頭

自動改札機は点検作業の回数と台数が多く，営業時間内に行われている。

表1 注1

自動改札機は営業時間中に計画停止時間を設けているので，自動券売機と窓口端末に比べて稼働予定時間が少ない。

〔CBMシステムの構築準備〕

今回は点検対象の一部に CBM システムを導入することで，点検対象を削減し，点検作業時間も削減できると考えた。

「サービス可用性管理の観点から」と条件が付いている。可用性管理はサービスを使える時間の話なので，故障が減るという答えはここでは外れる。

表1を見ると，自動改札機だけ年間稼働予定時間が6,990時間で，他の2つの7,000時間より10時間少ない。注1のとおり，営業時間中に計画停止しているからである。点検の回数と台数が多くて夜間に収まらない，というのが理由である。

CBMシステムで点検対象と点検作業時間が減れば，この計画停止も減る。つまりサービスを提供できる時間が増える。これが可用性の観点でのメリットになる。

25字。解答例は「計画停止時間を削減することができる。」で18字。

採点講評（IPA）

設問1(2)は，正答率は平均的であった。サービス可用性管理の観点からのメリットを問う設問に対し，故障の観点から解答する受験者が多かった。

本文の根拠

図1 臨時交換

臨時交換は，点検作業を実施する作業員が目視などで確認を行って交換が必要と判断した部材がある場合に，当該部材を交換する作業。

〔CBMシステムの構築準備〕

取得したデータから搬送速度の低下を検知するための

従来の点検作業で故障の前ぶれを見つけていたのは，図1の臨時交換である。作業員が目視などで確認して交換の要否を判断していた。つまり判断がその作業員の腕に左右される。同じ部材でも，見る人が変われば結論が変わりうる。

しきい値は数値である。搬送速度がその値を下回ったかどうかで決まるので，誰が見ても同じ判断になる。

40字。解答例は「作業員が目視で判断していた故障の前兆を，データに基づいて判断できる。」で33字。

狙いは「正確になる」ではなく「客観的になる」ところにある。目視よりデータのほうが精度が高い，とは本文のどこにも書いていない。書いてあるのは「作業員が目視などで確認して判断していた」という一点なので，そこと対にして答える。

採点講評（IPA）

設問2(1)は，正答率が低かった。CBMシステムの導入によって，作業員よりも正確に故障を検知できる，検知率を向上できるなどの誤答が多かった。従来の点検作業が熟練作業員のノウハウに依存しているという問題点を的確に捉え，誰もが同じように判断できる客観性を担保できる旨の内容を解答してほしい。

本文の根拠

図1 定期交換

定期交換は，故障が発生していなくても，一定期間利用した部材を交換する作業。

図1 注1

一定期間とは，部材が最も高い頻度で使用され続けたときに故障が発生する確率が高まるまでの期間を，F 社が独自の統計的手法に基づいて算出し，部材ごとに耐用年数や耐用時間として定めたもの。

〔現状の課題と改善策の検討〕

現在の定期交換の対象部材には，実際にはまだ使えるものがあって，無駄が多い。

定期交換の「一定期間」がどう決まっているかが鍵である。注1のとおり，最も高い頻度で使われ続けたときを前提に算出した期間である。つまり一番厳しい使い方に合わせてあるので，実際にはまだ使える部材が多く含まれる。本文も「無駄が多い」と書いている。

CBMシステムは搬送速度という実際の状態を見て，故障の可能性が高まってから交換する。同じ部材をより長く使えるので，交換の回数そのものが減る。

点検の手間が減るのとは別に，部材の費用が減る。これが「点検対象の機器数の削減及び点検作業時間の削減以外の」コスト削減効果である。

45字。解答例は「定期交換と比べて部材を長期間利用するので，部材の交換頻度を減らすことができるから」で39字。

本文の根拠

〔SNSデータの分析を活用した障害検知〕

当該駅では，駅の利用客対応を優先し，駅業務部への障害連絡が遅れてしまった。インシデントの初動対応が遅れて解決までに時間を要し，駅務サービスの可用性が悪化した。

〔SNSデータの分析を活用した障害検知〕

情報システム部では，障害当日 20:10 に駅業務部からの障害連絡を受け，20:15 にインシデントの対応を開始していた。また，SNS 上では障害に関する最初の投稿は 20:00 であった。

今回のインシデントの時刻を並べると，SNSの最初の投稿が20:00，駅からの連絡が20:10，対応開始が20:15である。

連絡が遅れたのは，駅が利用客の対応を優先したからで，駅を責めても直らない。ところがSNSにはその10分前から投稿が出ていた。SNSで検知できていれば，駅からの連絡を待たずに動き出せる。

初動が10分以上早まれば解決も早まり，「初動対応が遅れて解決までに時間を要し，可用性が悪化した」という今回の流れを断てる。

20字。解答例は「インシデントの初動対応の早期化」で15字。障害の検知が早くなるだけでは改善にならないので，初動対応まで書く。

本文の根拠

〔SNSデータの分析を活用した障害検知〕

SNS への投稿は，“情報源が不特定多数であって現場からの情報より正確性は低いが，情報の早さは現場よりも早い場合がある”といった特性がある。

〔SNSデータの分析を活用した障害検知〕

三つの検知条件の全てを採用すると検知遅れや検知漏れが増え，

設問が「SNSへの投稿の特性を表した本文中の字句を使って」と指定しているので，特性が書いてある1文を探す。本文には，情報源が不特定多数で現場より正確性は低い，ただし現場より早いことがある，と2つ書いてある。

使うのは正確性のほうである。投稿しているのは不特定多数なので，障害と関係のない投稿や思い違いも混ざる。条件を1つに絞れば，そうした投稿だけで障害と判定してしまう。だから誤検知が増える。

逆に3つ全部を求めると条件が厳しくなりすぎて，検知が遅れたり漏れたりする。間を取って2つを満たすことにした，という流れである。

25字。解答例は「情報の正確性が，現場からの情報より低いから」で20字。一般論としてのSNSの問題点ではなく，本文が挙げた特性で答える。

採点講評（IPA）

設問3(2)は，正答率は平均的であった。SNSへの投稿の特性を表した解答を求めているにもかかわらず，自らがもつ知識や一般的なSNSの課題などから解答する受験者が散見された。設問の内容に沿った解答をするよう留意してもらいたい。

本文の根拠

表1 項番1

運用部は手順書を用いて試験環境を開発部が指定する状態にする。運用部が試験環境を整備している期間，開発部の試験が中断する。

〔コンテナ型仮想環境の導入検討〕

試験項目に応じたコンテナをあらかじめ用意しておくことで，現在のコンテナの廃棄と用意されたコンテナの起動を行うことができるので，試験環境の整備を迅速かつ正確に行うことができる

Z氏は「迅速かつ正確に行うことができる」と2つ挙げている。設問が「試験環境が正しく整備されること以外」と断っているので，「正確に」は外れる。残るのは「迅速に」のほうである。

もう1つ条件がある。「運用部にとっての」利点である。試験の中断が減るのは開発部の利点なので，これも違う。運用部の側で何が変わるかを見る。

運用部はいま，手順書を見ながら試験環境を指定の状態に作り込んでいる。コンテナなら，用意しておいたものを起動して，今のものを廃棄するだけで済む。整備にかけていた作業時間そのものが減る。

20字。解答例は「試験環境整備の作業時間を削減できる。」で18字。

採点講評（IPA）

設問1(1)は，正答率がやや低かった。開発部にとっての利点やコンテナの特徴だけに着目して解答した受験者も多かった。コンテナの特徴だけではなく，コンテナを用いることで運用部が得られる利点に着目して解答してほしい。

本文の根拠

〔コンテナ技術〕

サーバのリソースを有効利用でき，環境の準備，起動，廃棄などを迅速に行うことができる。

〔コンテナ型仮想環境の導入検討〕

現在の運用では，原因を調査後，原因となった問題を除去して再度 AP の起動を行っているが，その間は 2 台のアプリサーバのうち 1 台だけしか稼働していない状態となる。

設問が「コンテナ技術の特徴を生かすことによって」と言っているので，本文が挙げた3つの特徴のどれかを選ぶ。専有して開発できる，準備・起動・廃棄が迅速，別環境への移行が簡単——時間短縮に効くのは2つ目である。

現在は，APが止まると原因を調べ，問題を取り除いてからAPを起動し直している。その間ずっと1台だけの状態が続く。

コンテナなら，止まったコンテナを廃棄して新しいコンテナを起動すればAPが動き出す。原因調査の完了を待たずに2台の状態へ戻せる。起動が速いという特徴が，そのまま復旧時間の短縮になる。

20字。解答例は「APを迅速に起動できるから」で13字。専有できる・移行が簡単といった特徴は，どちらも復旧の速さには結び付かない。

採点講評（IPA）

設問1(2)は，正答率がやや低かった。インシデント発生から復旧までの時間短縮に関連するコンテナの特徴を踏まえて解答してほしかったが，時間短縮に関連しないコンテナの特徴を解答した受験者も多かった。

本文の根拠

表1 項番3

稼働環境にデプロイする作業は W サービスを停止する必要があることから，W サービスの停止時間が発生し利用者に対して不便をかけている。

〔デプロイ方法の改善〕

現状の稼働環境（ブルー）とは別に，新しい稼働環境（グリーン）を構築して最新版の AP を準備しておき，デプロイする日時に合わせて，利用者が使う稼働環境を切り替える運用方法のことである。

これまでは，動いている稼働環境そのものに新しい版を入れていた。入れ替えている間はサービスを止めるしかない。表1の項番3の「Wサービスの停止時間が発生し」はここを指している。

ブルーグリーンデプロイメント方式では，新しい版をグリーン側にあらかじめ作って起動しておく。準備している間，利用者はブルーで使い続けられる。止まるのは切り替える一瞬だけである。

35字。解答例は「Wサービスをほとんど止めることなくデプロイすることができる。」で29字。「ほとんど」を落として「止めずに」と言い切ると，切り替えの瞬間があることと食い違う。

本文の根拠

〔デプロイ方法の改善〕

2.0 版のコンテナの動作に問題がないことを確認できた場合

〔デプロイ方法の改善〕

1.0 版のコンテナを停止し，1.0 版のコンテナを廃棄する。

表1 項番5

1 世代前の版のゲームアプリに戻すための緊急変更が必要で

本文の手順の順番が答えになっている。1.0版のコンテナを停止して廃棄するのは「2.0版の動作に問題がないことを確認できた場合」である。裏を返せば，確認が済むまで1.0版はそのまま残っている。

だから戻すときは，残っている1.0版へ切り替えるだけでよい。バックアップから復元したり，1.0版をもう一度デプロイし直したりする必要がない。ここが時間の差になる。

30字。解答例は「1世代前の稼働環境をコンテナとして残すことができるから」で26字。「コンテナだから速い」ではなく，前の版を残したまま新しい版を用意できる，というこの方式の形を書く。

採点講評（IPA）

設問2(2)は，正答率が平均的であった。バックアップからの戻しやコンテナを再びデプロイすればよいといった，現状の稼働環境を保持したまま新たな版の稼働環境を用意できていることを意識できていない解答も散見された。ブルーグリーンデプロイメント方式の特徴に着目して解答してほしい。

本文の根拠

〔デプロイ方法の改善〕

二つの稼働環境を用意して，利用者が使う稼働環境を切り替えられるようにする。

〔デプロイ方法の改善〕

コンテナ管理ソフトウェアを使って，現在の稼働環境をブルーからグリーンに変更する。

行きの手順は「コンテナ管理ソフトウェアを使って，稼働環境をブルーからグリーンに変更する」である。戻すときはこれを逆にたどる。

1.0版のコンテナは，2.0版の動作を確認できるまで廃棄していない。だから利用者の接続先をグリーンからブルーへ，つまり1.0版のコンテナへ切り替えるだけで元に戻る。

25字。解答例は「接続先を1.0版のコンテナに切り替える。」のほか，「利用者が使う稼働環境をブルーに切り替える。」でもよい。復元やデプロイのやり直しを書くと，この方式を使う意味が無くなる。

本文の根拠

〔コンテナ型仮想環境の検証〕

今回の検証における AP のエラーログなどの情報も，コンテナ内に出力する設定とした。

〔コンテナ型仮想環境の検証〕

しばらく稼働していたがその後 AP が異常終了し，コンテナが廃棄される事象が発生した。

〔コンテナ型仮想環境の導入検討〕

W システムの稼働環境及び試験環境は，2 台の物理サーバ，通信装置，外部記憶装置など，W 社の設備を使って構成されている。

原因は置き場所である。エラーログをコンテナの中に出していたので，コンテナが廃棄されたときにログも一緒に消えた。

コンテナは「準備，起動，廃棄などを迅速に行う」のが持ち味で，廃棄されること自体は異常ではない。中に置いたものが残らないのは，この技術では前提として受け入れる性質である。

したがってログはコンテナの外に書き出しておく。本文に挙がっている設備のうち，コンテナが消えても残るのは外部記憶装置である。

25字。解答例は「エラーログの情報を外部記憶装置に保存」で18字。「ログを残す」だけでは，どこに残すのかが決まらない。

本文の根拠

計算式

スケーリング後のコンテナ数 ＝ 現在のコンテナ数 ×

〔コンテナ型仮想環境の検証〕

検証で最大 8 個までコンテナを稼働できる環境を用意し，現在の稼働環境の稼働状況を踏まえて，期待する CPU 使用率を 50％とした。

式に当てはめるだけである。現在のコンテナ数が4，現在の平均CPU使用率が80％，期待するCPU使用率が50％。

4 × 80 ÷ 50 ＝ 6.4。設問の指示どおり切り上げて7個。

切り捨てて6にすると，1コンテナ当たりの負荷が 4 × 80 ÷ 6 ＝ 53.3％となり，期待する50％に届かない。切り上げるのはこのためである。

検証環境は最大8個まで動かせるので，7個は収まる。