応用情報技術者 2024年 春期 午後 問04

解答の論理構成

• 【問題文】には「ユーザインタフェースの表示速度を向上させるために、①静的ファイルを最適化する。」とあります。
• “静的ファイル”には HTML・CSS・スクリプト・画像が含まれると【問題文】に明記されています。したがって、最適化の方向性は
  ① 軽量化：テキスト系ファイルの容量削減
  ② 圧縮率の高い画像フォーマットの採用
  の二本立てになります。
• 解答群を分析すると
  ア：パイプライン処理の有効化 → HTTP/1.1 のパイプラインはブラウザ側設定であり、ファイル自体は軽くならない。
  イ：HTML, CSS, スクリプトの余分な改行・コメント削除 → ファイルサイズを直接削減できるため軽量化に合致。
  ウ：BMP や TIFF は非圧縮または可逆高画質で容量が大きい → 最適化の方向性と逆。
  エ：PNG や SVG は圧縮率が高く、テキスト系描画の SVG は拡大縮小にも強い → 軽量化に寄与。
  オ：全ファイルをバイトコードへ変換して圧縮 → 汎用ブラウザでは解凍・解釈の追加負荷が生じ、標準仕様外。
• 以上より、“静的ファイルを最適化”の具体策として妥当なのは
  「イ：HTML、CSS、スクリプトなどのコードに含まれる、余分な改行やコメントを削除する。」
  「エ：画像を、PNGやSVGなどの画像フォーマットにする。」
  の2つです。

誤りやすいポイント

• 「パイプライン処理＝高速化」と短絡し、アを選んでしまう
  → 転送の同時化で往復遅延は減らせてもファイル容量は変わらず、①の“ファイル自体の最適化”とは異なります。
• 「全て圧縮＝最適」と考えオを選ぶ
  → ブラウザが標準対応しない独自形式は、読込手順の追加でかえって遅延や互換性問題を招きます。
• BMP/TIFF を高画質と誤認しウを選ぶ
  → 静的コンテンツでは“高画質”より“軽量”が優先される点を見落としがちです。

FAQ

解答の論理構成

• 【問題文】では、下線②として「スマートフォンの CPU 負荷が大きく、頻繁に使用するとバッテリの消耗が激しい」とあります。
• CPU負荷の大きさを調査した結果、【表1】から「Webブラウザ内で日誌のデータを日付の降順にソートして、画面に表示する最大件数である4件目までを抽出する。」処理が「1,200」ミリ秒と突出して長く、さらに「日誌本文が42文字を超える場合…」が「300」ミリ秒、「本人が作成した日誌には“編集”ボタンを表示する。」が「200」ミリ秒となり、合計で1秒超を占めています。
• 【問題文】は「図3の応答データのスマートフォンへの転送処理と、Webブラウザ内でその応答データを加工する処理に多くの時間を要していることが判明した。」とも明確に述べています。
• したがって、CPUを最も使っているのは「スマートフォンのメモリ上で日誌のデータを加工する処理」であり、解答群では「ウ」が該当します。

誤りやすいポイント

• ネットワーク転送（解答群ア）は遅延の原因ではあってもCPU利用率を大きく押し上げる要因ではない点を見落としやすいです。
• HTMLやCSSのレンダリング（解答群イ）は描画時にGPUも利用するため、CPU負荷だけを見る設問では決め手になりません。
• ログインユーザ判定（解答群エ）は【表1】で「200」ミリ秒と相対的に小さく、CPU負荷増大の主因にはなりません。

FAQ

解答の論理構成

1. 図3は
   "diaries": [　[　α　 {"date": "2023-08-21", ...}, …, {"date": "2023-10-04", ...}, … ]　β
   という JSON 形式のコード片を示しています。
2. JSON における [ と ] は「配列（array）」を表す記号です。
3. 配列の中には、同じ構造を持つ複数の要素が順番に格納されます。ここでは
   • "date"
   • "salesperson"
   • "salesprocess"
   • "diary"
   を持つオブジェクトが並んでいます。
4. 図2の画面見出しは【日誌一覧】であり、要素一つ一つが個別の“日誌”を示していることが分かります。
5. 以上より、[ α … β ] 全体は「複数の日誌が連続して入っている配列」であると論理的に導けます。
6. よって解答は
   日誌の繰返しデータ

誤りやすいポイント

• count があるため「日誌件数のメタ情報」と誤解し、配列そのものの意味を見落とす。
• {} と [] の区別を曖昧にし、オブジェクトの集合と単一オブジェクトを取り違える。
• 画面が一覧形式なので「一覧表示用データ」とだけ答え、データ形式（配列）への言及が不足する。

FAQ

解答の論理構成

• 表1より、方式Pでは
  「Webブラウザ内で日誌のデータを日付の降順にソート」（No.3）などの処理に1,200ミリ秒、さらに転送にも800ミリ秒を要していました。
• 方式②の説明には
  「リクエストのあった応答データのうち、Webブラウザで描画するデータだけを返すWebAPIを開発して」
  とあり、転送対象を必要最小限に絞ることが示されています。
• また、No.3〜No.5の処理は
  「No.3の処理はDBで、No.4とNo.5の処理はAPで行われる」
  と明示され、データ加工がサーバ側へ移管されるため、スマートフォンのCPU負荷が下がります。
• その結果、表2では方式②が
  「レスポンス ○」「CPU負荷 ○」と評価され、総合6点で方式P（3点）より高評価です。
• 以上から、レスポンス向上の主因は
  ①データ加工をサーバ側で行うこと
  ②応答データ量を削減すること
  であると導けます。

誤りやすいポイント

• 転送量削減だけに注目し、サーバ側加工移行を見落とす。
• 表2の評価点をそのまま列挙し理由と混同する。
• 「CPU負荷低減＝レスポンス向上」と短絡して根拠を示さない。

FAQ

解答の論理構成

1. 【問題文】に「方式②のWebAPIからの応答データのサイズは、図3のデータのサイズの4分の1」とあります。
2. さらに「サーバ側でのデータ転送には時間を要しないものと仮定すると、No.2の所要時間は［　a　］ミリ秒」とあるので、ネットワーク転送・受信処理はデータ量に比例するとみなします。
3. 表1の No.2 は「WebブラウザがWebAPIにリクエストして、図3の応答データを全て受信する。」で所要時間は「800」ミリ秒でした。
   800 ms × 1/4 ＝ 200 ms → a＝200
4. No.3～No.5 の計算
   • 「No.3の処理はDBで、No.4とNo.5の処理はAPで行われる。」
   • CPU 性能は「スマートフォンが10,000MIPS相当、DBが40,000MIPS相当、APが20,000MIPS相当」。
   • 時間は MIPS に反比例すると仮定。

1. 以上より
   　a：200
   　b：550

誤りやすいポイント

• 「800 を 4 で割る」際に 200 ではなく 400 と誤計算する。
• No.3～No.5 のうち DB に載せ替わるのは No.3 だけで、No.4・No.5 は AP で実行される点を見落とす。
• MIPS 倍率を逆にして、処理時間を増やしてしまう。
• No.3～No.5 の合計を算出後に a の 200 ms を加えてしまうなど、試算の対象範囲を取り違える。

FAQ

解答の論理構成

• 下線③は〔システム構成の検討〕に登場します。
  引用：「図1のAPとは別に、スマートフォンやノートPCから呼び出されるWebAPIのためのAPを、新たに追加する構成にした。」
  ここで “別に” 配置する目的が拡張性です。
• 改修方針でも同じ趣旨が強調されています。
  引用：「将来的に、CRMシステム以外の社内システムとも連携できるように拡張性をもたせる。」
  つまり WebAPI を共通の窓口とし、他の社内システムが後から利用できるようにしておくことが狙いです。
• したがって③が指す拡張性とは、
  「WebAPI を介して既存 CRM 以外の社内システムも接続できる柔軟性」
  という結論になります。

誤りやすいポイント

• スマートフォンの台数増への対応と誤認し、スケールアウト面だけを答えてしまう。
• AP を分離した理由を “セキュリティ強化” と短絡的に捉え、連携面を見落とす。
• 「将来的な拡張性」を“画面追加が容易”と解釈し、データ連携の文脈を読み飛ばす。

FAQ