応用情報技術者 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」はサーバ側プログラミング言語で、クライアント側のスタイル切り替えには不向きです。
• “Web API” や “SPA” といったキーワードに引きずられ、サーバ側技術を選択してしまうミスが起きやすい点に注意が必要です。

FAQ

解答の論理構成

• 【問題文】では、動的データの受け渡しについて「動的なデータはAPからWeb APIを通して提供し、データ形式は各端末のWebブラウザ上で実行されるスクリプトが扱いやすいbとする。」と明記されています。
• 各端末（PC・タブレット・スマートフォン）のWebブラウザで直接扱いやすいデータフォーマットとして、現在もっとも一般的に用いられるのはJavaScriptのオブジェクト表現そのものをテキスト化した JavaScript Object Notation です。
• JSONは
  1. JavaScriptでネイティブにparse / stringifyでき、追加ライブラリが不要
  2. 軽量かつ人間可読で、ネットワーク転送量を削減
  3. RESTful Web APIやSPAのデファクトスタンダード
     という特長を持ち、【新システムの方針】で掲げる「SPA (Single Page Application)」と「Web API」に最適合します。
• よって 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. Web API “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ニュース記事」画面のスクリプトは
   「表示させたい記事の記事番号を指定して Web API “ITNewsDetail” を呼び出し、…次に…一つずつ指定して Web API “ITNewsHeadline” を呼び出し…」
   と記載されています。
2. つまりブラウザは1画面表示のたびに 1回の “ITNewsDetail” ＋ 6回の “ITNewsHeadline” をインターネット越しに発行しており、往復遅延が累積します。
3. 指摘(1)では「インターネットを介して実行された場合、試算した応答速度より大幅に遅くなる」とし、解決策として
   「Web API g 内から、Web API 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使用率が高い場合、Web APIの応答速度を優先するために、更新処理は行わない。」との条件があります。
3. つまりCPU使用率が高い状態が続くと、5分ごとの更新処理がスキップされ、キャッシュ内の
   ・「"ITニュース一覧画面に表示する記事の一覧"」
   ・「"各記事に関連する記事の一覧"」
   が古いままになります。
4. 〔不具合の指摘と改修〕(2) では
   「"APに処理が偏ってCPU使用率が高い状態が続いた場合、②ある画面の表示内容に不具合が出てしまう。」と述べられています。
5. この“ある画面”とは、前述の更新対象である「ITニュース一覧」および「各記事に関連する記事の一覧」を表示する画面です。CPU高負荷で更新が実行されないため “更新されない” という不具合が発生します。
6. 以上より回答は「ITニュース一覧と各記事に関連する記事の一覧が更新されない。」となります。

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ