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

解答の論理構成

1. 【問題文】には「・aの機能を用いて、一つの Webサイトで全ての種類の端末に最適な画面を表示できるようにする。」とあります。
2. 端末の画面サイズや解像度に応じてレイアウトを自動調整する仕組みは、一般に“レスポンシブ Web デザイン”と呼ばれます。
3. レスポンシブ Web デザインを実現する中心技術は、メディアクエリなどを備えた「CSS（Cascading Style Sheets）」です。HTML 文書に対してスタイルを切り替えることで、同一 URL でも PC、タブレット、スマートフォンへ最適化した表示が可能になります。
4. 選択肢のうち「ア：CSS」だけがこの要求を直接満たすため、a に入る適切な字句は「CSS」と判断できます。

誤りやすいポイント

• 「DOM」は文書構造の API であり、表示を制御するスタイル自体は持ちません。レスポンシブ対応には直接結び付きません。
• 「HREF」はリンク先 URL を示す属性で、画面レイアウト制御の機能はありません。
• 「Python」はサーバ側プログラミング言語で、クライアント側のスタイル切り替えには不向きです。
• “WebAPI” や “SPA” といったキーワードに引きずられ、サーバ側技術を選択してしまうミスが起きやすい点に注意が必要です。

FAQ

解答の論理構成

• 【問題文】では、動的データの受け渡しについて「動的なデータは AP から WebAPI を通じて提供し、データ形式は各端末の Webブラウザ上で実行されるスクリプトが扱いやすいbとする。」と明記されています。
• 各端末（PC・タブレット・スマートフォン）の Webブラウザで直接扱いやすいデータフォーマットとして、現在もっとも一般的に用いられるのは JavaScript のオブジェクト表現そのものをテキスト化した JavaScript Object Notation です。
• JSON は
  1. JavaScript でネイティブに parse / stringify でき、追加ライブラリが不要
  2. 軽量かつ人間可読で、ネットワーク転送量を削減
  3. RESTful WebAPI や SPA のデファクトスタンダード
     という特長を持ち、【新システムの方針】で掲げる「SPA (Single Page Application)」と「WebAPI」に最適合します。
• よって b に入る字句は「JSON」と判断できます。

誤りやすいポイント

• XML と迷う
  • 旧来の Web サービスでは XML が多用されていたため、慣習的に選びがちです。しかし問題文は「Webブラウザ上で実行されるスクリプトが扱いやすい」と限定しており、パーサ不要で直接扱える JSON が適切です。
• CSV や YAML を想起する
  • CSV は階層構造を表しにくく、YAML はブラウザネイティブではありません。SPA で複雑なオブジェクトをやり取りする前提と合致しません。

FAQ

解答の論理構成

• 【問題文】表2の “ITNewsDetail” には「キャッシュするデータは①LFU方式で管理する。」とあります。
• 「LFU方式」は Least Frequently Used、すなわち“参照頻度が少ないデータを追い出し、参照頻度が高いデータを残す”アルゴリズムです。
• したがって、同方式を採用するとキャッシュ領域には参照頻度の高いデータが保持されやすくなります。
• このデータとは「ITニュース記事画面でアクセスされる記事」のことであり、頻繁に読まれる記事ほどキャッシュに残るため、
  ➡︎ 答え「参照回数の多い記事」と結論づけられます。

誤りやすいポイント

• LFU を LRU（最近使われた順）と取り違え、「最新の記事」や「直近に読まれた記事」と答えてしまう。
• 「キャッシュサーバに格納されやすい」を“登録時点”と誤解し、「新着記事」などと回答してしまう。
• 「参照回数＝アクセス数」の理解不足で、単に「人気記事」と曖昧に書いて減点される。

FAQ

解答の論理構成

1. ITニュース一覧画面 ― 初回表示
   • 測定結果 No.1「“80ms”」＋ No.2 方式(2)「“200ms”」
   • よって $80+200=280$ → c は 280
2. ITニュース一覧画面 ― ページ切替
   • ページ切替時は HTML などを再取得しないので No.2 方式(2)「“200ms”」のみ
   • よって d は 200
3. WebAPI “ITNewsDetail” の平均応答時間
   • キャッシュヒット率 No.3 方式(2)「“90%”」
   • ヒット時時間 No.4 方式(2)「“120ms”」
   • ミス時時間 No.5「“300ms”」
   • 平均 $0.9\times 120+0.1\times 300=108+30=138$
   • よって e は 138
4. ITニュース記事画面 ― 平均応答時間
   • “ITNewsDetail” 平均 138ms
   • “ITNewsHeadline” は 6 件、No.6 方式(1)「“15ms”」より方式(1)は $6\times 15=90$ms
   • 方式(1)：$156+90=246$ → f は 246

誤りやすいポイント

• No.1 の “80ms” をページ切替時にも加算してしまう
• ヒット率を百分率でなく小数で計算し、$90\times 120$ のように掛けてしまう
• “ITNewsHeadline” が 6 件であること（表2 で「6件」）を見落とす
• 方式(1) と 方式(2) の測定値を混在させ、平均を誤る

FAQ

解答の論理構成

1. 【問題文】の表3には、
   「ITニュース記事」画面のスクリプトは
   「表示させたい記事の記事番号を指定して WebAPI “ITNewsDetail” を呼び出し、…次に…一つずつ指定して WebAPI “ITNewsHeadline” を呼び出し…」
   と記載されています。
2. つまりブラウザは 1 画面表示のたびに 1 回の “ITNewsDetail” ＋ 6 回の “ITNewsHeadline” をインターネット越しに発行しており、往復遅延が累積します。
3. 指摘(1)では「インターネットを介して実行された場合、試算した応答速度より大幅に遅くなる」とし、解決策として
   「WebAPI g 内から、WebAPI h を呼び出すように改修」とあります。
   これは「ブラウザ → AP へのリクエスト数を 1 件に集約し、関連見出し取得をサーバ側で完結させよ」という意味です。
4. サーバ側で関連記事の見出しを集約する主体は「対象記事のデータを返す」役割を持つ “ITNewsDetail” です。
   一方、集約対象となる「関連する記事1件分の画像のURLと見出し」を返すAPIは “ITNewsHeadline” です（表2を参照）。
5. よって
   g＝ITNewsDetail
   h＝ITNewsHeadline
   が最適解となります。

誤りやすいポイント

• “ITNewsHeadline” をブラウザが呼ぶ仕様が表3にあるため、「g に ITNewsHeadline」と思い込みやすい。改修後は逆転する点に注意。
• 表2の説明文で “ITNewsDetail” に「関連する記事の記事番号のリストを返す」とあることを読み飛ばすと、どちらが呼び出し元か判断できなくなる。
• 「呼び出す側／呼び出される側」を混同しがち。呼び出し“内”に入るのは常に“上位”の業務 API。

FAQ

解答の論理構成

1. 問題文ではキャッシュ更新の仕組みとして
   「"AP の OS のスケジューラが 5 分間隔で、ITニュース一覧画面に表示する記事の一覧と、各記事に関連する記事の一覧のデータを更新する処理を起動する。」と記載されています。
2. さらに同じ段落で
   「"なお、AP の CPU 使用率が高い場合、WebAPI の応答速度を優先するために、更新処理は行わない。」との条件があります。
3. つまり CPU 使用率が高い状態が続くと、5 分ごとの更新処理がスキップされ、キャッシュ内の
   ・「"ITニュース一覧画面に表示する記事の一覧"」
   ・「"各記事に関連する記事の一覧"」
   が古いままになります。
4. 〔不具合の指摘と改修〕(2) では
   「"AP に処理が偏って CPU 使用率が高い状態が続いた場合、②ある画面の表示内容に不具合が出てしまう。」と述べられています。
5. この“ある画面”とは、前述の更新対象である「ITニュース一覧」および「各記事に関連する記事の一覧」を表示する画面です。CPU 高負荷で更新が実行されないため “更新されない” という不具合が発生します。
6. 以上より回答は「ITニュース一覧と各記事に関連する記事の一覧が更新されない。」となります。

誤りやすいポイント

• 「WebAPI がタイムアウトする」と勘違いし、表示内容ではなく応答時間の不具合と答えてしまう。
• 更新対象が “記事本文” だと思い込み、本文が古くなると記述してしまう。問題文で更新対象は「記事の一覧」「関連する記事の一覧」に限定。
• 方式(2) の集中キャッシュと混同し、「NoSQL が単点故障になる」といった対策面を不具合として書いてしまう。

FAQ

解答の論理構成

1. 現状の関連記事抽出方法
   – 問題文には「各WebサーバのアクセスログをRDBに取り込み、URL中の記事番号を用いたアクセス解析をRDB上のストアドプロシージャによって行っている。」とある。
   – つまりアクセスログの URL に含まれる記事番号 が解析の鍵になっている。
2. 新システムへの変更点
   – 新方針では「AP での動的な HTML の生成処理を行わない、SPA (Single Page Application) の構成にする。」
   – SPA では Web サーバは HTML やスクリプトなどの静的ファイルのみを返却し、記事データ取得は WebAPI が担当する。
3. 変更による影響
   – ブラウザが記事を閲覧する際に呼び出すのは WebAPI “ITNewsDetail” であり、その URL は Web サーバではなく AP が受け取る。
   – 従って Web サーバのアクセスログには 記事番号を含む URL が記録されなくなる。
4. 結論
   – 記事番号が含まれないため「記事間の遷移がWebサーバのアクセスログのURLでは解析できない」。これが下線③の理由である。

誤りやすいポイント

• 「SPA でも URL は変化するから解析できる」と誤解しやすい
  SPA の画面遷移はフロント側のスクリプトが制御するため、サーバに HTTP リクエストが飛ばないケースが多い。
• 「AP のログも取り込んでいる」と思い込む
  現状の仕組みは Web サーバのログしか対象にしていないと明示されている。
• 「静的ページにも記事番号が残る」と勘違いする
  記事本文は動的データとして WebAPI で配信されるため、静的ファイルの URL に記事番号は含まれない。

FAQ