応用情報技術者 試験情報＆徹底解説

令和7年春期試験 午後問4(システムアーキテクチャ)についての投稿を受け付けるスレッドです。

アクティブスタンバイとライブマイグレーション逆にした、、、

〇〇構成ってついてたからアクティブスタンバイにしました

計算間違えたかも。。

アクティブスタンバイ構成、ライブマイグレーション機能ですよね？

アクティブアクティブなら一発でそれ選んでたんですけどね・・・結局アクティブスタンバイ・マイグレーションで時間費やしてしまった

計算
216
900
でした？

計算、22と900ですか、、？

22だったー

計算は22と900になりました。
21.6を四捨五入して22ですかね、、？

終了1分前にミスに気づき、、22には修正できたがその次は間に合わず。。

自分もやじまりーさんと一緒になりました！

99.5と99.95を見間違えてた...

設問１の⑵は？
b移行性？
C運用・保守性？
ちんぷんかんぷん。でした。

可用性と運用・保守性にしました。

bウ
cイ
にしました。。

BEMSゲートウェイ

ウ 可用性
イ 機能性 保守性

ク ライブマイグレーション
ク ライブマイグレーション(どっちがどっちか忘れたのでどっちもクにしました笑)

ア 稼働

22
900

ウ ソフトウェアの障害

設問1
1 BEMSゲートウェイ
2 bウ cイ
3 dエ e未回答（ライブマイグレーションは思いつかなかった、、）

設問2
1 ア
2 22
3 900
4 エ

b可用性なのですね…涙

最後
E社クラウド基盤サービスはIaaSだからソフトウェアは対象外だと思ってソフトウェアの障害にしちゃいました

cが可用性では？

表1の項目2について〜
の段落で、異様に「保守」って単語が連発されてたからイにしちゃった

いや、回復時間は保守性の話だから違う
平成27年基本春季午前56とか見ればわかる

アクティブスタンバイ、RAID5にしました

最後ってアじゃないの？
障害時間の考え方って
上から、管理画面のエラー、インターネットのエラー、ディスクのエラー、の問題が起こった場合の話してるからcpuだけ保証されてないよね

2-(4)ウにした、、違うのかな

どうでしょうか....

1.
(1)BEMSゲートウェイ
(2)-b. イ
(2)-c. ウ
(3)d: エ、e: ク
2
(1) ア
(2) 22（21.6を四捨五入）
(3) 900
(4) イ（わからん）

アイアースのサービス範囲を考えて、アプリやソフトウェアは範囲外だからウにしました

2(4)はゴリラさんと同じく管理画面(ソフトウェア)、インターネット(ネットワーク)、ディスク(ストレージ)が保証対象だと考え、
保証されていないものはアにしました

設問2 4はクライアントとサーバを繋ぐネットワークについてはSLAに含まれないよってことだと思ったのでエとしました

問題文にネットワークはR社が管理との記述があった気がするので、最後はネットワークではないですか？

E社クラウドサービスのSLAで保証されるか否かだから、ソフトウェアかなと思いました、、

全く自信はないですが、
だるぅさんと同じ理由で最後はネットワークにしました。

この問題ってE社が別事業として行ってるIaaS上に対照システムを構築する想定であって、R社から見ればSaaSな気がする

応用情報でそんな凝った解釈求められるかなぁ

設問1(1)：BEMSゲートウェイ
設問1(2)：イ(運用・保守性)、ウ(可用性)
設問1(3)：エ(アクティブ-スタンバイ)、ク(ライブマイグレーション)
設問2(1)：ア(稼働)
設問2(2)：22
設問2(3)：1000円
設問2(4)：ウ(ソフトウェアの障害)

2-4はソフトウェアの障害にしました
ソフトバンクの通信障害が「エリクソン社製のソフトウェアが原因」みたいな事例が過去にあったりします
自分らの注意できる部分じゃないところから沸いて出てくるソフトウェアの障害なんてクラウドサービス提供者がどうにかできることじゃないので保証できんやろって思ってそうしました

設問2(3)は1000円(200000-199000)円になったのですが、900円の方はどういった計算でしょうか。

うろ覚えですが書いておきます、自信はないです( ｰ`дｰ´)ｷﾘｯ

設問１ (1)a：BEMSゲートウェイ
    (2)b：ウ c：イ
    (3)d：エ e：オ
設問２ (1)f：ア
    (2)22
    (3)924
    (4)エ

>>試験お疲れさまでしたさん
99.95%に満たなかった場合に"SLAで示す稼働時間よりも少なかった稼働時間分の利用料金を減額する"と記載あるため
99.95-99.5=0.45 の結果より、0.45%分の金額である900円かなと考えました。

> (No.38) さん
稼働率が99.95%の時の実際の稼働時間t1は、
t1 = 24 * 60 * 30 - 21.6（月間総稼働時間ー月間累積障害時間）
稼働率が99.5%の時の実際の稼働時間t2は、
t2 = 24 * 60 * 30 - 216（月間総稼働時間ー月間累積障害時間）
よって、稼働率が99.95%の時と稼働率が99.5%の時の実際の稼働時間の差異は、
t2 - t1 = 216 - 21.6
t2 - t1の時間分の価値が失われるので、
((t2-t1)/(24*60*30))*20万円=900円と計算しました。

設問1-2の組合せで回答の根拠を伺いたいです
自分はb：イ(運用・保守性)、c(可用性)で選択したのですが
どちらも計画停止の頻度と障害発生時の回復時間で、
利用不可な時間に関わるので共通するのはc(可用性)かなと思ったのですが…

2-4はエにしました。
本文中「FW及びインターネット接続環境はR社が設置・運用する。」とあるので、E社が提供するサービスのSLAではインターネット起因の障害は免責になると思われます。ただ、選択肢のエはインターネット障害ではなく「ネットワークの障害」なので微妙なところですね。。

2-4はウ(ソフトウェアの障害)が個人的には自信ありです
AWSの責任共有モデルなどを踏まえても、ソフトウェアに障害が発生しても基本的にハードウェアを管理しているIaasからするとしったこっちゃない、の話だと思うので…
ヨータスさんと同じ回答根拠です

みなさまありがとうございます。
わたしは30日障害ゼロ=24*30=43200mのとき20万と計算してしまいました。
よくわかりました。

>試験お疲れさまでした
恐らく私と同じくゴリ押しで計算されたのではないかと思います
共に祈りましょう…南無…

1000円仲間がいらっしゃったので喜んでしまいました。
お互い他で点を拾っていることを願いましょう...笑

(2)はchatGPT的にウ、イになりそうですね

この投稿は投稿者により削除されました。(2025.04.20 19:11)

わたしはこのように回答しました。

設問１
(1)a：BEMSゲートウェイ
(2)b：ウ c：イ
(3)d：エ e：ク
設問２
(1)f：ア
(2)22
(3)空白
(4)ウ

最後はネットワークかな
専用線引かない限り保証できないな

ネットワークの場合、ソフトウェアの障害はどうなるのでしょうか。ｱｲｱｰｽのSLAで保証されるとも思えないし。宙に浮いちゃいませんか

難しかった。他の回答を見てると、計算ミスったか。

設問1 （1）a：BEMSゲートウェイ
   （2）b：イ
      c：ウ
   （3）d：エ
      e：ク
設問2 （1）f：ア
   （2）g：22
   （3）9000円
   （4）ウ

ChatGPTに問題文全文と設問1(2)を入れた結果です↓

項番1：
 • 非機能要件の指標：BEMSサーバのメンテナンスに伴う計画停止の頻度
 • → これは、システムの継続運用のしやすさに関わる指標です。
 • → よって、該当する非機能要件の分類は イ：運用・保守性

項番2：
 • 非機能要件の指標：BEMSサーバのハードウェア障害発生時の平均サービス回復時間
 • → これは、障害が起きた時にどれだけ早く復旧できるかに関わる指標です。
 • → よって、該当する非機能要件の分類は ウ：可用性

⸻

よって、正解は：
 • b：イ（運用・保守性）
 • c：ウ（可用性）

保守性

障害やメンテナンスによってサービスが停止したとしても、原因の追及やシステムの変更・修正がしやすく、サービスを再開するまでの時間が短いシステムは、保守性が高いと評価できます。また、保守性が高ければ、短期間で復旧できるため、稼働率が上がり、高可用性にも繋がります。

なので
→ウ、イ
ですね。

設問(2)のd, eはdがクでeがエではないですか…？

でも後ろに続く構成、機能っていう言葉を考えると…って感じなんですよね…

ライブマイグレーションって動いている前提だから障害発生時はできないと思ってRAID5にしちゃった

設問2の(4)はアじゃないですか？
図3▪️月間累計障害時間の考え方より
1.仮想サーバに管理画面からアクセスすることができない状態
2.仮想サーバにインターネットからアクセスできない状態
3.仮想サーバに接続されているディスクに全くアクセスできない状態

上記が保証されるもので
1→管理画面を経由する＝ソフトウェアの障害
2→ネットワークの障害
3→ディスク＝ストレージの障害
よって残るア.CPUの障害が正解だと思います。

マジで自信ない

設問1 （1）a：BEMSゲートウェイ
   （2）b：イ（イかウどっちだ？）
      c：ウ（イかウどっちだ？）
   （3）d：エ
               e：イ
設問2 （1）f：ア
   （2）g：22
   （3）12000円（時間なかったので適当）
   （4）ア

私も「時間足りんかった」さんとまったく同じ考えで「ア」を選択しました。
この手の問題は、問題文に何かヒントがあると思ったので…
合っててほしいですね…

問2の 保守性か可用性かは未だにググッてもパッとしませんし、予備校の回答速報が気になる…

(2)b:イ(運用・保守性) c:ウ(可用性)

R社の要求を
1. 定期的なメンテナンスのせいでシステムが使えない！緩和してくれ！→運用+可用性の問題
2.  ハードウェア障害少ないのはいいけど、壊れた時なかなか直らんからどうにかしてくれ！→可用性の問題
という解釈をしました。

IaaSなんだから流石にウでしょ

あいさんと同意見

それ以外だとソフトウェアが宙に浮く

管理画面→ソフトウェアの想起も飛躍すぎると思っちゃった

配点
計算が3点
他2点
でしょうかね。

1-2
b ウ(可用性)
c イ(運用・保守性)
項番2のハードウェア障害時の回復時間は、保守性が担保されてることに依存するから運用・保守性かと。あと文章読み進めると異様に項番2に対して保守員のことが書かれてるから正解に誘導したいと読んだ。

やっぱりMTTRの長さは保守性に関係するからcが保守性でbが可用性なのでは

あとアクテイブスタンバイは障害時の切り替えの文脈で出る言葉で、切り替え時は一時的にシステムを利用できない。ライブマイグレーションはメンテナンスとかでシステム停止したくない文脈で出る言葉で、切り替え時にシステムが止まることがない。

ってことを考えるとdはクでeがエだと思うんですよね〜

ライブマイグレーションを移行の時に使用するとかいう嘘を吹き込まれてたから
RAID5とアクティブスタンバイ選んで詰んだわ

嘘知識吹き込まれるとつれーーー

私の回答です

設問1 （1）a：BEMSゲートウェイ
   （2）b：イ
      c：ウ
   （3）d：エ
      e：ク
設問2 （1）f：ア
   （2）g：22
   （3）90
   （4）エ

９０円は無い…無いよ…
２（４）はシステムとクラウド基盤をE社が持つので、そこから外のネットワークは勘弁してね、かと思いました。

ライブマイグレーション構成とは言わない
のでエクで合ってると思います、

2-(4)25ページ6行目にFW及びインターネット接続環境はR社が設置・運用すると記載があったのでエにしました。

設問2(4)は、私もアとウで迷いましたが、よく考えてみると仮想サーバの管理画面というのは、仮想サーバで動いているソフトが表示する画面ではなくて、ハイパーバイザのコンソールのことですよね。だからハイパーバイザのコンソールにアクセスできない=CPUの障害、ということになり、答えはウかなと思いました。

設問2(4)、自分は「BEMSクライアント上のWebブラウザを用いてBEMSサーバにアクセスし」と本文にあるので、図3中の「仮想サーバに管理画面からアクセスできない状態」はWebブラウザが障害を起こしている(=ソフトウェアの障害)と考えて(ウ)ではなく(ア)にしました

2-(4)はウ、エで迷いましたが、問題文に「BEMSサーバに発生する可能性がある障害の要因の内」と記載されてました。
よってエ）のネットワークはインターネット回線ではなく、サーバ内のネットワークの話だと解釈しました。
IaaSの場合このネットワークはE社の管轄になると思うので、ウ）のソフトウェアにしました。

可用性と運用・保守性の下りですけど、
IPAが出してる非機能要件グレード2018では、可用性の項目に目標復旧水準があるんですよね。

逆に、運用・保守性の項目には運用時間、バックアップ、運用監視、マニュアル、メンテナンスしかないのでこれってbが運用・保守性でcが可用性じゃないですかね？謎です

どっちの意味にも取れそうな問題は出さないでほしい
セキュリティの方も意見割れてるやつあるし

いや、普通にサーバーのソフトウェアが障害起こしてるから使えないでいいのか。よく分からんけど

設問2の(2)で0.36時間というところまで出せていたのに、なぜか計算結果19.8になって20分と書いた自分を殴りたい…

TACが！TAC解答速報が！
見解が割れていた 運用・保守性、可用性 のところ！
まさかの bイ cウ です！

TACの解答速報は毎回精度高いです！
他の業者が外した問題をTACだけ当ててるということがよくあります！

この投稿は投稿者により削除されました。(2025.04.22 17:37)

iTEC(午後の重点対策を出版したり模試を開催している)の解答速報も
bイ cウ
になってます。

受験者さんの間では逆順の bウ cイ も結構支持がありましたが、予備校各社の解答速報だと bイ cウ で見解一致みたいですね。

あとそういえば設問2(4)も割れてましたね
そっちはTACがウでiTECがエでした
一流の企業が作る解答予想でも見解割れてます(´・ω・`)

cまじでどっちも当てはまりそうで困る

あれ？てかiTECはなんで設問2(4)をエ(ネットワークの障害)にしてるんだろう？
エよりはア(CPUの障害)じゃないですか？

図3の要件から持ってくる考え方だとネットワークは要件記載済みなように思えるんだけど？

「仮想サーバに管理画面からアクセスできない」の部分がソフトウェア由来なのかCPU由来なのか(No.72の方の根拠参照)などでそこを考えるときに答えが揺れてるのだと思うのだけど…

ネットワーク障害はその下に見解違いも起こらず普通にそのまんま判断できる手がかり書いてあるっぽいよね？

てことは ウ(ソフトウェアの障害) に軍配が上がるのか……？

設問2(4)がCPU由来じゃないのって結局なんでなんだ？？
責任分界点的な観点だと、サーバー管理のためのソフトウェアもベンダー側が提供してるシステムのうちの一部なんだから、部品不良に関しては免責ですよ。
でアになりそうなもんだけど。

IaaSだから、管理ソフトに不具合あっても障害じゃありませんってどうなんだろう

いやでも、ハードウェアに責任って考えるとCPUの障害も対象内か。
難しい

bがイでcがウならAPのR4春季午前問56は何!?

tyさんほんとそれですよね
直前の電車でそれ解いたからcを保守性にした。

>>Tyさん、うかれうかれさん
本当にその通りなんですよね。
ITILの定義付けだと平均サービス回復時間が保守性の指標になっていて
IPAの出している資料だと、目標復旧時間が可用性の指標になってます。

ただ、移行性や運用・保守性、性能・拡張性っていう書き方は
IPAの出している資料の書かれ方なので、正直どちらを参考にしろとか
言われてないのでどちらも正解でいいんじゃないかなとも思います

あーなるほど・・・
仮想サーバーの管理画面にアクセスできないのをソフトウェア障害の要因としてるのか
よく見てなかったなあ、単純に仮想サーバに入れるソフトの障害の話かと思ってた

CPUって仮想サーバのCPU使用率の話かな？
だとしたらアだなあ

確かに可用性は稼働率が指標だってことならどちらにも当てはまるとは思うけど、項番2に保守性が当てはまらない理由にはならないよなあと思ってしまう
もうどっちも正解にします！って言ってくれる方が助かるけど選択問題だから難しいんかな？

>tyさん
まじで良い情報ありがとうございます。

管理画面＝ソフトウェア
を表しているのか
が争点なのでしょうか。

もしかして作問チーム設問全部作ったあと全文読み返して解き直しとかしてないのではとか思ってしまう()

これってR社に向けての非機能要件ですよね？
確かに保守性が高ければサービス復旧時間が早くなりますが、それはE社にとってであり、R社からすると関係無いです。(IaaSなので)
なのでやはりイ、ウで合ってるのでは？

たしかになぁ。客からしたら「保守性がいいよ！」って言われても知ったこっちゃないって話ですよね

>あいさん

でもそれだと非機能要件に保守性という言葉が出てくること自体がおかしくなる気がします(運用性の方を非機能要件として考えていると言われればそれまでなのですが)

自分は「システムの保守性が(E社にとって)高ければすぐにサービスが回復できる(ので、R社はシステムの保守性が高いことを要求している)」と考えました

ただ、2回目すぎおさんの言うようにIPAの中では目標復旧時間が可用性の指標の1つで、この問題も「みんな目標復旧時間が短くなってるのを読み取ってウを正解として選ぶよね？」って考えで出題している可能性があるなぁと思いました

あんまり詳しくはないのですが、細かいニュアンス？だと
目標復旧時間(RTO)→目標なので将来的な到達点を考えている→可用性としての指標
平均サービス回復時間(MTRS)→過去の復旧時間のデータの積み重ね→保守性の指標
ってイメージだと思うんですよね。違ったら申し訳ないですが。

だから今回は、新サービスの紹介として立ててる非機能要件なので
前者が近いのかなあって思ったり。
後者でも正解だとは思いますが本当に。

結論、どちらとも取れる問題を作るIPAが悪いですね
悪問でしょう。

>2回目すぎおさん

なるほど…たしかにそういう考え方も全然ありそうです

解答はみんな割れても、設問が悪いというのは全員一致してそうです

項目1,2どちらにも可用性がかかりそうな気もするし、かと言って項目2が保守性じゃなかったら令和4春午前56との整合性が取れなくなるし

まじで謎ですね。

項番2
ハードウェア障害発生時の平均サービス回復時間を指標(48時間→15分)としてるから
平均修理時間(MTTR)が指標のServiceability(運用・保守性)だろと思い「イ」
としたんですが、、

回復時間が早くなれば、システムを使用できる時間が増え
可用率も上がりますがね。。

難しい！

以下、ChatGPTより

■ MTRSとは？

Mean Time to Restore Service（平均サービス復旧時間）
 • 障害が発生してから、サービスが元の運用状態に復旧するまでの平均時間を指します。

⸻

■ 可用性との関係：
 • 可用性（Availability）は「どれだけ長くサービスが稼働しているか」を示す。
 • MTRSが短いと、障害時のダウンタイムが少なくなり、結果的に可用性が向上する。
→ 可用性の構成要素の一つとしてMTRSが使われます。

⸻

■ 保守性との関係：
 • 保守性（Maintainability）は「修理・保守のしやすさ、速さ」を示す。
 • MTRSは「障害発生から復旧までの速さ」を表すので、システムの保守性の高さを測る指標としても用いられます。
→ 特にITILなどでは、MTRSは保守性の定量指標とされることが多いです。

⸻

■ 結論（まとめ）：

MTRSは「保守性」の指標でありながら、可用性の計算にも関わる指標です。
→ つまり、「主に保守性の指標」だが、「可用性に間接的に影響する」という位置づけです


ううむ、どっちも！笑

「平均サービス回復時間」は百歩譲って可用性、運用・保守性どちらとも言えるけど、
保守会社サービスへの連絡、保守員の駆けつけ〜
からの文脈判断で、運用・保守性なんじゃないかな。
親切なほどの説明で、「保守の工数が削減するんだ〜。保守員の負担が軽減されるんだ〜。」
を読み取って欲しいんじゃない？

ただ保守性じゃなく、運用・保守性だったことにも何か意味があるんかな

もし項目2が可用性だったら、その下につらつら「保守会社サービス〜、保守員〜」と書かれているのはなんなんだろう。全く無意味な文章になってまう。

可用性ってイレギュラーな事象が発生してもサービスを止めないために備えるみたいな文脈で使われることが多い印象です。高可用性とかHA構成とか。
その意味で、事前の予知や制御が不可能なハードウェア障害発生時のことを指して、可用性ではなく運用・保守性とするのは違和感があります

運用・保守性、可用性 の問題は TAC・iTEC・スタディング全社の解答速報で bイ cウ なので講師やその道のプロから見ればこの順で確定する根拠がなにかあるんだと思いますね～

設問2(4)の方はTACとスタディングがウ(ソフトウェアの障害)でiTECだけエ(ネットワークの障害)でした

RASISの可用性、保守性と非機能要件の可用性、運用・保守性で若干意味合いが異なるのでイ、ウになるんでしょうかね？
RASISの保守性はMTRSが指標だけど、非機能要件の運用・保守性はそうではないみたいな

イウだとしたら世紀の大悪問でしょこれ

過去に平均サービス回復時間＝保守性って自分たちの作問で作ってんだから(令和4春午前56)

cの指標と指標値から保守性は合っているけれども運用性は読み取れないのかと。時間しか書いてないですし。

この投稿は投稿者により削除されました。(2025.04.23 12:00)

ぬちゃさんの書き込み見て思いましたが「運用・保守性」というふうに「運用」がくっついてるのを判断基準にしろっていう問題なんでしょうかね
よく考えたらみんな保守性にだけ目が行ってたけど運用性まで繋がって選択肢なわけですから

>ヨータスさん

IPAの試験のサービスマネジメントはITIL準拠なはずなので、その線での導出は違うのかなと思ってしまいました。

納得する根拠と導出があれば全然納得できるのですが、今のところどれも納得できないのが現状です。。。
(もちろん、私の理解不足、知識不足も大きいと承知しております)

確かに、運用性に着目するという視点は抜けておりました。

iPaぜったいゆるさん

それならば選択肢を運用・保守性ではなく運用性にするのでは？

計算はともかく、内容はわかりそうだったから今回は選択すれば良かったかなあ。

コメントはしたものの、正直後々の文章の駆けつけ〜とかみると運用ともよめなくもないかなと思いました…障害発生時というのが鍵なんですかね…
私もオンプレ屋さんと同じ目線でbのほうが運用保守性に近いなと感じて選んだので

保守員があたふたしなくて済む
の結果、48時間→15分ということで、
サーバのハードウェア障害発生時の平均サービス回復時間には運用性が包含されていると考えられませんかね。

大原も解答速報出てたので見たんですがbイcウですからね
設問2(4)の方が解答が割れているくらいですけど設問1(2)b,cはまったく割れてないので各社専門家が解答を導き出した結果bイcウになっていることで確定でしょう

ここでの集計結果
イウ派が8
ウイ派が9
と拮抗していました。。僕もウイと解答しましたが、大手4社がイウにしているので、イウなんだと思います。
議論して頂きありがとうございました。

各社bイcウにしてるのはIPAの考えに寄り添ってるのと、解答作った人は2年前の午前の問題なんて一々覚えてないってのがあると思います。流石にどっちでも正解なのでは

R4春の午前過去問ってITILの可用性要件の中のKPIとして保守性の指標「平均サービス回復時間」が書かれているので、今回の問題のcも要件としては可用性で相違していない気がします。IPAの非機能要求グレードも同じような考え方だと思いますし(運用保守性には駆けつけ時間などがあり、そもそもの復旧時間は可用性に記載)

運用が良くなれば回復時間は良くなるねは確かかと思いますが、そこの非機能要求としては可用性で見るということでないでしょうか。

広義可用性、狭義保守性ってことですかね。

どんぐりさんの説明で確かにcに可用性入れられるなぁとめっちゃ納得したんですが、今度はじゃあなんで項番2の非機能要件に運用・保守性が入らないんだ…って疑問になり始めました

GPTに聞いてみた。
イウかウイかで論争が起こっている理由がこれに詰まってる。
結論、100%問題が悪いし、どちらでも正解にすべき。

オンサイト保守サービスとライブマイグレーションの組み合わせは、可用性と運用・保守性の両方に関連します。

【可用性】
ライブマイグレーション: 仮想マシンを停止せずに別のホストに移行することで、システムのダウンタイムを最小限に抑え、高い可用性を維持します。

【運用・保守性】
オンサイト保守サービス: 保守員が現地に駐在し、障害発生時に迅速に対応することで、システムの安定稼働をサポートします。

このように、両者を組み合わせることで、システムの可用性を高めつつ、運用・保守性も向上させることができます。

ウ・イのみんなでIPAに訴えて考えを改めてもらいましょ。
一問で人生が変わる人もいるんです。
俺はIPAを絶対に許さない。

IPAの非機能要求グレード見ていただければと思いますが、可用性と運用・保守性はそもそも重複していると記載されています。ただ、重複している項目は運用スケジュールなどで、これは問題文の項版1にあたり、bとcが重複しているのと合致します。
じゃあ「平均サービス回復時間」はとなると、これはRTO(目標復旧時間)にあてはまり、これは重複しておらず、可用性のみが該当します。
運用・保守性に含まれる障害に関する項目は駆けつけ時間、復旧の自動化などがありこれは確かに「平均サービス回復時間」に寄与しますが、要件としては異なります（顧客の15分で復旧したいという要求に対し、駆けつけを早くしますと回答してもチグハグですよね）。
項番2について記載している文章はcに関係することを書いているだけなので、早くなった要因があり、そのなかに運用・保守性のものが入るのは変では無いと思います。

なるほどなぁと思いつつ、平均サービス回復時間≠目標復旧時間じゃない、？とも思っちゃいます

多分落ちたので、秋も受けたいのですが、システムアーキテクチャに強くなるために間になにかベンダ資格を挟みたいと思っているのですが、何が該当しそうでしょうか。ネットワークとの相乗効果も狙ってCCNAとかどうですかね。

過去にこういうどっちとも取れそうな答えで、IPA側からどっちとも取れるのでどちらでも可とするみたいな声明出たことあるんですか？

クラウドベンダのシス管向け資格、ITILファンデーションとかでしょうか

chatgptより
■ 非機能要求グレード2018での定義

【可用性（AV：Availability）】
 • 定義：
 「必要なときにサービスを継続して提供できること」
 • 代表的な指標：
 - 稼働率
 - 計画停止の頻度や時間
 - 障害発生時の継続運転可否
 - 障害発生時のサービス提供継続率

→ 要するに、システムが止まらず、利用者にサービスを提供できるかを測る。

⸻

【運用・保守性（OM：Operation and Maintenance）】
 • 定義：
 「運用・保守作業の負荷を軽減し、効率的かつ確実に実施できること」
 • 代表的な指標：
 - バックアップのしやすさ
 - ログ収集・障害検知のしやすさ
 - 障害復旧にかかる時間・手間  
 - バージョンアップ時の作業量やリスク

→ 要するに、システム運用者・保守担当者が「楽に、早く、安全に」作業できるかを測る。

やっぱりbが可用性では？

chatGPTよりもIPAの一次ソースみてみたほうが良いと思います…
https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html

定量的なサービス回復の時間は可用性に書かれているので…

RTOと平均サービス回復時間は意味が違うような？
また、非機能要求グレード2018のc.3.3.2項の保守員の話はまさに本文で述べられている内容に合致しているかと思います。

とりあえずIPAの解答を待つしかないですね。

運用・保守性、可用性を答えさせる問題は問題が悪い。本当に思う。ITILとIPAの指標が違うのは分かったけど、それなら令和4年春のような問題は出すべきではない。どっちで答えればいいか分からないんだから。それに今回答えをひとつにしたいんだったら、IPAの指標で答えろって言うべきであって。それが書かれてないんだから、誰がどう言おうと答えは今回2つしかありえないよ。指標を統一していないのが良くない。どっちの答えが出ても仕方がない。

ほんまや。c.1.1.1から大項目が運用・保守性になっとる
これcが運用性保守性やんけ！

そんでa.1.1.3の計画停止はc.2.1.1との重複項目になっとる。
これ決着着きましたね。

一応平均サービス時間とRTOの違いも聞いてみました。
「平均サービス回復時間（MTRS）」は、RTOと似ていますが、厳密には別の指標です。
■ RTO（Recovery Time Objective）
 • 意味：障害発生から業務を再開するまでに許容される最大時間（目標値）
 • 分類：可用性
 • 例：RTOが2時間なら、障害が起きてから2時間以内に業務を再開しなければならない。

■ MTRS（Mean Time to Restore Service）＝平均サービス回復時間
 • 意味：サービス停止から回復までにかかった平均時間（業務再開までの実績値）
 • 分類：運用・保守性
 • 違い：MTTRは「修理作業にかかった時間」だが、MTRSは「業務が実際に回復するまでの時間」＝より広い意味。
 • 例：修理は30分（MTTR）で終わったけど、業務再開までにシステム再起動や確認作業で+15分 → MTRS＝45分

3.2.2は保守員の駆けつけ時間なのでサービス回復時間ではないですよね
サービス回復時間の中運用の時間に含まれるだけで…

項番2の説明が問題文にあり
保守員の駆けつけに要する時間は大幅に短縮される(指標：48時間→15分の内容)

駆けつけ時間に関する非機能要求グレードの該当項目はC.3.3.2
C3.3.2の大項目は運用・保守性

これは・・・！！きたか！！？

皆さんの言っていること、全部わかる、本当にどっちか分からない

平均サービス回復時間が非機能要求グレードのどれに該当するのかが分かれば納得できる

紙の試験もう限界だって流石に。

保守員駆け付け時間が平均サービス回復時間に包含されるか、が現在の争点ですかね。
もっとも、平均サービス回復時間(MTRS)自体が保守性の指標なのでウイに軍配が上がると思うのですが。。。

修理時間が短くなる時点で保守性の指標ですよね、、

アクティブスタンバイ構成にかかってるかもですが
スタンバイ側がホットスタンバイの場合15分で切り替えは遅いような。。
保守員が切り替える構想(コールドスタンバイ)のため遅いのか？ということと
問題文としても保守員の駆けつけ時間が大幅に～がシステム移行による効果のメインと見えるんですが。。

しかし資格学校のプロたちが、可用性にしてるのが引っ掛かりすぎます。。
見解が聞きたい！

まぁ、過去にデータベースからなんかで解答速報と全く違ったなんてこともありましたからね。
こればっかりはIPAの解答を待つしかないかと。。

普通に考えて、既存システムの指標値48時間が可用性の範疇だったらヤバない？これは流石に可用性(稼働率)の話じゃなくない？ですか？

48時間がサービス稼働率の範疇だったら、改修前のシステムだったとしてもどんだけ止まってんねんってなりません？しかもこれ、もし可用性の話だったら、15分/月や15分/年みたいに単位つくはずじゃないですか？これだけ見ると月なのか年なのか分からなくないですか(本当に素人なので的外れだったらすみません)

応用情報のIPAシラバスを見ると、
項番１で出てくるアクティブースタンバイ方式＝（１９）サービス継続管理に分類される
項番２の”平均サービス時間”はMTRSのこと＝（１８）サービス可用性管理に分類される
と仮定すると、項番２のｃは”保守性”の指標だと推測できるかなと思ったのですがどうでしょうか？

非機能要件グレードに書いているものないかなと思って探してましたが作られた時のレビューのQA、指摘にありますね。初版の時のレビューですが、2018の改訂では影響ないのでこの内容が最新のものに当てはまるかと

非機能要求グレード 「ユーザビュー検討委員会」 報告書(経済産業省のサイトは貼れなかったので名前書いておきます。)
Q.可用性における運転時間率、平均ダウン率、等
【追記】
「等」の部分は以下の項目
平均回復時間、再開時間、自動リカバリー機能充足率

A.運用時間やサービス中断時間、稼働率などのメトリクスで定義していました。用語についてはできるだけ一般的なも
のを載せるようにしたいと考えています。
ご提案いただいた用語について、JUAS「UVC2」での定義を以下の通り確認しました。それぞれ項目一覧の項目との
対応を示しています。
平均回復時間⇒B18(平均回復時間)「障害回復の平均の時間」⇒⇒A.1.4.2RTO(目標復旧時間)

たそがれさんの止まりすぎでは？というところは、復旧しなくても影響が小さいものだと翌営業日対応とかにするケースあるので長すぎではとは思わなかったですね。48時間とかですと多分翌営対応だと思いますし(いくらなんでも国内の移動でこんな時間かからないですよね)。

既存構成：サーバー1台稼働 顧客敷地内に設置されている
48時間は顧客の連絡時間、保守員移動時間、修理対応時間(データ復旧含む)
設置場所も、故障個所も多岐にわたるので多めに見積もってあるのかな

新構成：サーバー1台稼働 スタンバイ1台 クラウド基盤に設置 保守員常駐
15分は顧客の連絡時間、スタンバイへの切り替え時間(移動時間、切り替え作業)
スタンバイへの切り替えは手動自動でも時間は変わる

スタンバイ切り替え後にサーバー修理するので顧客目線の時間は短い

いくらなんでもそんな深読みはさせないと思いますよ。
応用情報ごときでそんなQAとかJUASの定義とかどうとか調べないと出てこないようなとこ出してくるとは思えないんですが。

同感です。c.3.3.2(運用・保守性)と本文(表1.項2についての記述)が一致しているので運用・保守性となる、くらいの温度感でいいのかと思います。推察とかせずに

それ言い出したら回復時間と復旧時間なんて一緒な感じの温度感になる気がする

どの項目に書かれているのかとコメントいただいたので見てみただけですけどね…
IPAが決めた定義と違うとは思えないので私は整理出来たので良かったです

ウイ派
・非機能要件グレードの保守員云々の大項目が運用・保守性である
・そもそも平均サービス回復時間(MTRS)は保守性の指標である

イウ派
・予備校各社がイウである
・平均サービス回復時間(MTRS)は目標復旧時間(RTO)と同義である
・保守員駆け付け時間は平均サービス回復時間と同義ではない


うーん、今のところ同点！

この投稿は投稿者により削除されました。(2025.04.27 18:29)

これ非機能要求グレードってところの話なんですよね。
予備校各社はそのくらいのことは熟知してるからそこから抜粋して当てはめて解答を導き出してるから答えが割れることはない。
まず保守性がどうこうだからウイだ！と喚くのではなく非機能要求グレードから見ると「運用・保守性」が一語なんですよ。
「保守性」じゃないですよ、「運用・保守性」です。これらがIPA資料の非機能要求グレードにも記載あります。
その資料の通りに当てはめると運用・保守性がイになり可用性がウになるというだけの話なのではないでしょうか。
私は素人なので資料をちゃんと精読したわけではないですが、パッと見でいろいろ区分けされて運用・保守性などについても書いてはあるのでそういうものなのだろうと判断しました。

この投稿は投稿者により削除されました。(2025.04.27 20:50)

"非機能要件" OR "非機能要求" "可用性" "運用・保守性" "回復時間"
でググったら回復時間の部分は可用性でした。
試験問題を見ると回復時間でcだけにある物で判断しないとこれの答えって出せないわけですよね。
(計画停止などの話はbcどちらにも含まれて該当することになっているわけですから両方で相互にあって判断できる項目よりcだけにある物でこれの答えを判断します)
で、cだけに該当する回復時間を調べると可用性が当てはまりました。
回復時間の件と可用性の方から判断してcウしかないんじゃないでしょうか。
ここの掲示板はスクリーンショット貼ったり資料の載ってるサイトを貼れるようになってったりはしないので資料を貼れず申し訳ないですが気になる方はご自身で非機能要求グレードなりなんなり精査すればいいと思います。

確かになぁ。平均サービス回復時間は“保守性”の指標
非機能要求グレードのc.3.3.2は“運用・保守性”
の話だからちょいズレるって話ですね。

必死すぎて草

この投稿は投稿者により削除されました。(2025.04.27 23:44)

平均サービス回復時間が可用性に該当するのであれば、非機能要求グレードのAの何番に該当するのでしょうか？

該当しそうなやつ列挙してみます↓↓↓
A.1.3.2のRTOは見る感じも調べる感じも、“災害時”のニュアンスが強い(業務の継続対策を実施していないケース)ので違いそう
A.1.5.1の稼働率は、計算式がMTBF/(MTBF+MTTR)だから違いそう
A.4.1.1 C.3.1.1との重複項目なので絶対に無い

果たしてどれだ、、、、、？

これに関してはまじでどちらか分からないので、イイかウウにして負荷分散した人の戦略勝ちな気がしますね。

IPAがRTOと対応してると言っていて
RTOは目標で平均サービス回復時間は実績で今回の場合既存システムだから実績の数値使ってるだけなのに何を悩んでるのこの人

しかもリスク分散ならまだしも負荷を分散してて草

たそがれさんは自分がウイにしたからウイになるような見方しかしないので正解や資料が提供されようが重箱の隅をつつくようにして屁理屈を述べて何がどうあってもウイに持っていこうとするんじゃあないですか
もうそこまできたら建設的な話も誰もできないでしょうし勝手にやっててくださいとしか思えません
ハッキリ言って荒らしと同然のように見えてやってることが大迷惑ですけどね…
もうちょっと冷静になってちゃんと調べて結論付けて人から言われたことを聞き入れて納得する姿勢を持った方がいいと思います

No.154さんのコメント見たら確かにそうかもですね。ただ、対人論証にもっていく議論は掲示板のコミュニティガイドラインに引っかかる可能性があるので気をつけた方がよいかと。

No.154を見過ごしてしまっていましたが、これが決定打ですね。
平均回復時間＝目標復旧時間との事なので、平均サービス回復時間は可用性だとやっと納得出来ました。

しかし、それまでの議論は決して意味の無いものではなく、有意義なものだったと思います。

私は中立的に議論していたつもりでしたが、時々ウイに偏重してしまうこともあり、それは本当に申し訳ありません。ただ、中立的に議論しようとしていた姿勢はログにも全部残っているので遡って見て頂きたいです。

私の頑固さにイライラしていたのもあるとは思いますが、議論に必要のない表現や批判的な単語は使わない方がよいかと、、、。

長い間ありがとうございました〜。

やっぱり、しっくりは来ないな
ITILの指標だとどうしても逆になりませんか？

R5の問10解いてたらめちゃくちゃ逆のこと言ってるんだけどどっち信じればいいん？

たそがれ諦めるな

イウ、ウイ 論はIPA解答例まで結論でないですよね。

イイ→×
ウウ→×
イウ→〇
ウイ→〇

とかなったらどんなに...だろうと考えてしまう。
ほんとに我々が考えても仕方ない気もします。

正直分からないですよね。
指標だけ見るならどっちでもありえるとは思います。
自分的にはですけど、可用性は稼働率のことで、どれだけ動いてたかを表すため、bでもcでもないと思ってます。そもそも計画停止時間って稼働率に含めませんし、お客様に了承を得てとってる時間なためです。強いて言うなら保守性な気もします。項番1に入るのはその為保守性。
保守性とはどれだけの時間でそのシステムを治せるのかを表す意味ですよね。その為項番2の平均サービス回復時間というのは、どれだけ早くシステムを治せるかということなので、既存システムでは治すのに48時間→新システムは15分である。これは保守性だと考えます。保守性が早くなるから可用性も上がるよねは納得ですが、項番2に保守性が入らない理由にはなりません。よって保守性。

指標がこうだからという意見ではなく、確かな理由、根拠をもった話を聞きたいです。指標だけではどうしてもIPAとITILで異なっています。IPAもITILの指標を過去に問題で出してるので、しっかりした理由を論評に書いてくれるはずです。そのため考えた理由等を聞きたいと思います。

やっぱりもう一度問題見てみたのですが、項番1.2は、駆けつけ時間が短くなったから起こったこと。つまり、それが理由で平均回復時間が減ったということになりませんか？これは運用・保守性が良くなったから平均回復サービス時間が短くなった

イ、ウだとR5APの午後問10とかR4SM春午後1と食い違う気がするんだよなぁ

Momさん、食い違いというよりイ,イが正解です。それかイ,ウでも正解になるかもしれません。基本情報技術者試験の平成27年春の問56を見て欲しいのですが、
そもそもMTTRの指標自体は保守性であり、稼働率(可用性)の式が、MTBF/MTBF＋MTTRで、保守性(MTTR)が良くなれば分母が小さくなるから可用性(稼働率)が良くなるという意味です。項番2自体の指標は保守性のことを言っています。MTTR48時間→15分と。項番1.2はそれに保守員の駆けつけ時間を短くしたと本文中にあるのでこれは、運用に値しますよね。cは問題製作者が運用・保守に誘導してる感じがしますね。指標値を答えさせようとしていたり、項番1.2は駆けつけ時間を短くしたと言っていたりするためです。従ってcはイです。
項番1のbは正直謎です。計画停止時間とは可用性(稼働率)には含みません。強いて言うなら、bもイです。運用が良くなったよの意味で。そもそも計画停止時間に指標なんてものは、ありません。これは問題が誤りです。なので完全なる正解は空白です。
両方イになるのはおかしいから、bはイで、cはウという考え方も出来るかもしれませんが、cにイが入らない理由にはなりません。それは、指標を答えろと書いてあるし、実際に基本情報、応用情報で指標を答えさせる問題にも出てきたことがあるためです。例は上の基本情報の問題を参照ください。従って、b＝イ,c＝イor b＝イ,c＝ウです。もしくは、b＝なし,c＝イorウです。

IPAがどう納得いく解答出すかたのしみです。正直bは全て○にして、cはイとウの両方○にしないと答え的に納得いかない気がしますが

R4SM春午後1を見ると表に計画停止時間は可用性と書いてありました。
また、上での議論の通り、IPAが出している非機能なんたら〜を見ると、計画停止時間は可用性と運用•保守性の重複項目って書いてありました。
あと障害発生時の保守員の駆けつけを駐在にすることによるダウンタイムの短縮は運用•保守性との記載もありました。個人的にはこの根拠を見る限り揺れることなくウ、イになると思いました。
解答発表が楽しみです。

この投稿は投稿者により削除されました。(2025.05.15 19:15)

この投稿は投稿者により削除されました。(2025.05.15 19:24)

上でさんざん出てきてますけど

●項番1 b,c
指標 計画停止の頻度 年４回→計画停止無し

非機能グレード項目一覧から該当項目
可用性(A1.1.3)
運用・保守性(C.2.1.1)

●項番２ c
指標 平均サービス回復時間 ４８時間→１５分(保守員の移動時間削減と読み取れる)

非機能グレード項目一覧から該当項目
運用・保守性(C.3.3.2)

非機能グレードからするとウ、イですよね。
非機能自体はシステム導入時(今回は変更かな)の顧客との認識合わせと思うので、指標が目標値であってもいいのでは

盛り上がってきましたね。
私はもう完全に折れて、イウだと思っちゃってます。。。

表1ってE社によって示されてるから、平均サービス回復時間が可用性はないやろ。
E社の視点で現地駆けつけが短くなるって話は運用•保守性以外の何物でもないと思うが...
その結果可用性が高くなるのはわかるとして

https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000004623.pdf
IPAの資料に108Pに平均回復時間は可用性とかいてますよ

下部P143のほうがわかりやすいかもですね
MTTRはRTOでこれは可用性のA1.3.2です
駆けつけ到着時間は復旧規定に内包されるかたちですがcなので保守・運用性です。

今回はMTTRなので可用性です

本文は駆けつけ時間が〜とかあるので混乱するのかもですが、本文は無視して単純に平均サービス復旧時間はどの非機能要件かという問で考えて調べてみたらいかがですか。それで保守・運用性だという資料があるなら問題が成り立たないと思いますが(ないと思いますけど)。

JUASのB18項目：平均回復時間を見ると
①要求仕様の決定(ユーザの役割)から始まってます。
システムを導入したいユーザの要求事項(決めるのはユーザ側)

P143も
SaaS利用者がシステム提供者とSLAを締結する際に締結すべき項目を提示したもの
→提示するのはユーザ側
RTOもユーザ側が決める？

今回、問題はR社から停止時間を短くしたい要求はあったが
表１はE社が立てたので・・・どうでしょうか。

ちなみにJUASの資料によると項番１はどこに書いてあるのでしょうか？
見つけられなかったのでご教示もらえると助かります。

非機能要求グレードには可用性、運用•保守性共に「平均サービス回復時間」と言う言葉はありませんでしたので、そう言う意味でも判断材料となるようにわざわざ本文に非機能要求の運用•保守性に記載されている事項と同様の記載をしたのではないでしょうか？目標復旧時間と平均サービス回復時間を同等とするのも間違っていない気はしますが、本文を無視するのは応用情報においては危険な気もします。
あくまで非機能要求グレードベースの話ですがね。

非機能要求グレードにありますが、できた背景として発注者、受注者双方で共有認識をもつことが狙いなので、どちらが作ったというのは関係ないとおもいます。

JUASの①とかは決めるプロセスなのでどちらの立場からみたというのは関係ないかと。ユーザからみてもベンダからみても要件は要件ですし。

表1の、項番2は
発注者からみると運用、保守性
移動時間が少なくなるから修理その他業務時間にそそげる

受注者から見ると可用性
障害停止時間が減って使える時間が増えるから

本文無視は良くないですよ、、

Momさん
私が目標復旧時間と平均サービス回復時間を同等としたのではないですよ。IPAが非機能要求グレードベースだと同等としているといっています。

おっしゃる通り非機能要求グレードには平均サービス回復時間とズバリの言葉はない中、運用が減ったから運用・保守性だという議論になっていると思うのでIPAが平均サービス回復時間はどう判断しているかをのべている形です。

本文無視については平均サービス回復時間の非機能要件の分類はなにか聞かれているので、そこに本文中の解釈は不要かと。応用情報全体については述べてないです。

発注者の立場、受注者の立場から見たコメントが出てますがその場合どのように合意形成して要件定義書サインオフするのでしょうか。
非機能要件はベンダ側の要件ではなく、あくまでシステムの要件ですよ。

非機能要求グレードベースで考えるなら、平均サービス回復時間と書いていない以上推察の域を出ず、IPAではなく個人的な見解になると思うのですが、、
このままだと収拾がつかないので大人しく7月1日まで待つとします。

Momさん
多分すれ違ってますが以下ですよ。あくまでIPAの見解を記載しているだけです。
①IPAの非機能要件グレードにはRTOが可用性A.1.3.2に記載されている
②IPAの他の資料ではサービス回復時間は非機能要件グレードのRTO A1.3.2に対応しているとIPAがコメントしている

なるほど、、
ただ過去の午後試験にもサービス回復時間が保守性と書いてある表が存在するので、IPAの正式な解答が発表され次第、今回との相違点を自分の腹に落とし込むようにします。

コメントされていた、R5APの午後問10とかR4SM春午後1のとこですよね。以下は斜め読みかつ個人的見解ですが…
R5APの午後問10はITILの可用性の中の特性・指標の話、R4SM春午後1はSLAの話なのでちょっと違うと思うんですよね。
少なくともR5APは可用性の中の構成要素として保守性の指標があるよという問題なのかと

非機能要件とSLAとかの対応というか関係がわかる資料とかないかなぁと思いましたがぱっと見つからなかったです。(要求があってSLAがあるとか概念的なものはありましたが)。またなにかあったらコメントしてみますね。

問題の表3がSLAであり
発注者と、受注者の合意形成の表ですよね。。

これ以上は時間か惜しいので
ipa回答待ちますね

SLAで保守性として出てきた平均サービス回復時間が非機能要件で可用性に変わるなんてことはないと思うけど

非機能要件の問題なのに、なんでSLAの話が？
非機能要件はシステム要件、SLAはサービス提供者の保証するものだから裏返しの関係に近いけどだけど同じじゃないですよ。
先ず持って、文字どおりサービスレベルのアグリーメントなんだから、非機能要件の合意がSLAではないし、

過去問で似たようなものが書いてあるもん、としか言っていないようにみえます。
なぜその過去問のものと同じと判断しているのですか？
選択肢の非機能要件の分類の運用・保守性と、SLAの指標である保守性は同じ意味ですか？

判断理由がないと議論になりませんよ。

もうお互いに割れてんだからIPAの解答例待っとけばええやん笑

予備校全社の回答揃ってて、試験作成しているIPAの資料にものっているのに、異を唱える人の思考回路聞くチャンスなんてそうそうないやんw