応用情報技術者 2022年 春期 午後 問08

解答の論理構成

1. 下線部①の原文は「①表5の運行事業者以外の情報も調査し、問題がないことを確認した」です。この文が示すのは、表5に登場しない運行事業者を洗い出す必要があるということです。
2. 表5に登場する運行事業者は【問題文】の「表5　空席情報の連携機能が提供しているデータ項目の書式と例」に列挙されている「E社」「F社」「G社」の3社だけです。
3. 表5以外に運行事業者が登場する箇所を探すと、【問題文】の「表4　E社、F社、G社、H社の調査結果」と「高速バス、観光バスの運行事業者は上記の 4 社だけであるが、路線バスだけを運行する運行事業者である S 社、T 社が存在する。」という記述があります。
4. ここで表5に含まれていない運行事業者は、「H社」「S社」「T社」の3社です。
5. したがって、解答は「H社、S社、T社」になります。

誤りやすいポイント

• 表4に「E社、F社、G社、H社」が載っているため、うっかり「E社」「F社」「G社」まで含めてしまう。
• 路線バス専業の「S社」「T社」は高速・観光バスではないため見落としやすい。
• 「表5の運行事業者以外」という条件を読み飛ばし、単に“全社”を列挙してしまう。

FAQ

解答の論理構成

1. 発車日の変換
   表5のG社の例では発車日が「2022-05-10」とハイフン区切りです。表6の書式は「YYYYMMDD」ですから、ハイフンを除去して「20220510」とします。
   引用：「表5　G社　例　発車日　2022-05-10」
   引用：「表6　発車日　YYYYMMDD」
2. 発車時刻の変換
   表5の発車時刻は「18:00」でコロン付き、表6は「hhmm」です。コロンを除去して「1800」とします。
   引用：「表5　G社　例　発車時刻　18:00」
   引用：「表6　発車時刻　hhmm」
3. 統合便コードの生成
   手順は表6の説明のとおりです。
   引用：「路線コードと便コードとを結合した文字列の先頭に、運行事業者ごとのコード文字…を付加して、8桁のコードにする。桁数が8桁に満たない場合は、運行事業者コードの後にゼロパディングを行う。」
   • 路線コード「301」と便コード「10」を結合し「30110」（5桁）。
   • 先頭に運行事業者コード「G」を付与し「G30110」（6桁）。
   • 8桁に満たないので、運行事業者コードの直後に2桁分ゼロパディングし「G0030110」。
4. 空席数の取込み
   空席数はそのまま可変長でよいので「8」を使用します。
   引用：「表5　G社　例　空席数　8」
   引用：「表6　空席数　可変長」

誤りやすいポイント

• ゼロパディングの位置を末尾に入れてしまい「G3011000」とするミス。規定は「運行事業者コードの後」に入れる点に注意。
• 発車時刻を 4 桁化する際に「18:00」を「01800」としてしまう誤り。24 時制 2 桁＋ 2 桁で十分なので先頭ゼロは不要。
• 路線コード「301」と便コード「10」の結合順序を逆にしてしまうケース。問題文は“路線コードと便コードとを結合”と明示。

FAQ

解答の論理構成

1. 【問題文】では、空席情報ファイルについて「②ファイル形式はCSV形式」と方針を定めています。設問はこの“CSV形式”の特徴を他形式（XML、固定長）と比較して選ぶ問題です。
2. CSVはカンマ区切りでタグを持たないため、
   • XMLのような開始・終了タグを含まずメタ情報も少ないことから、同じデータを格納した場合に「1レコード当たりのデータサイズ」が小さくなります。よって解答群「ア：XMLファイルと比較して、1レコード当たりのデータサイズが小さい。」が該当します。
3. 固定長ファイルは各項目の開始位置を計算で直参照できるので、I/O とパースの両面で高い性能を発揮します。CSVは区切り文字を読み取りながら可変長項目を解釈する必要があるため、「処理速度」が固定長より遅くなりやすいです。よって「エ：固定長ファイルと比較して、処理速度が遅い。」が該当します。
4. 残りの選択肢を検証します。
   • 「イ：XMLファイルと比較して、処理速度が遅い。」
   → XMLはツリー構造を解析する必要がありオーバーヘッドが大きいので、一般にCSVの方が速い。誤り。
   • 「ウ：固定長ファイルと比較して、項目の桁数や文字数に関する自由度が低い。」
   → 固定長は桁数が固定であるのに対し、CSVは可変長で自由度が高い。誤り。
5. よって正しい組合せは「ア、エ」となります。

誤りやすいポイント

• 「XMLはテキストだから軽い」と思い込み、データ量に対してタグが増える事実を見落とす。
• 固定長＝古い形式＝遅いと短絡的に判断する。実際には位置計算だけでアクセスできるため高速。
• CSVの“自由度”を“低い”と誤読しやすい。可変長ゆえに自由度は高い点を押さえる。
• 処理速度をファイルサイズの大小だけで判断し、解析コスト（パース処理）を考慮しない。

FAQ

解答の論理構成

• 問題文には、H社と連携する際の方法として
  “H社については運行する便数が少ないこともあり、開発費用が比較的安価である③Webページから情報を抽出する方法を用いることにした。”
  と記載されています。
• “Webページから情報を抽出する”行為は、公開された HTML などの画面を機械的に取得し、タグを解析して必要データを取り出す技術を指します。
• この技術を一般に呼ぶ名称は “Webスクレイピング” です。
• 解答群を照合すると、 “エ：Webスクレイピング” が該当します。
• 以上より、下線③に入る適切な字句は “エ” です。

誤りやすいポイント

• 「API も Web を経由するから ‘Web API’ では？」と早合点するケース
  → API はサービス提供側が正式に用意するインタフェースであり、画面解析とは異なる。
• “Webコンテンツ” はページそのものを指す一般語で、データ取得方法の名称ではない。
• “WAI” は “Web Accessibility Initiative” などを連想させるが、本設問の文脈と無関係。

FAQ

解答の論理構成

1. 確認すべき項目の導出
   • 指摘 (i) で、FTP 転送後に「ファイル全体が正しく転送されたことを確認」する必要が示されています。
   • 対策案では「空席情報ファイルのa と b が一致することを確認」とあります。
2. “どの値を突合するか” の手掛かり
   • データ設計段階で「空席情報ファイルは、ヘッダレコード1件と必要な数のデータレコードから成り、ヘッダレコードには、作成日、作成時刻に加え、データレコード件数を含める」と明記されています。
   • したがってヘッダには“送信側が想定するデータレコード件数”が入る。
3. 受信側で算出できる対応値
   • 受信後、プログラムはファイルを読み込み「処理したデータレコードの件数」をカウントできます。
   • ヘッダに記載された件数と、実際に読み取った件数が一致すれば「全件受信できた」と判断できます。
4. 解答
   • a に入るのは「ヘッダレコードのデータレコード件数」
   • b に入るのは「処理したデータレコードの件数」

誤りやすいポイント

• ヘッダにあるのは “ファイル全体のバイト数” と誤解しがち。本文で指定されているのは「データレコード件数」です。
• b を “空席数の合計” と読み違えるケース。確認対象はレコード件数であり数値合計ではありません。
• 文字コードや CSV 形式など他の仕様と混同して、突合項目を複数設定してしまうミス。設問は件数一致のみを問います。

FAQ

解答の論理構成

1. 指摘事項の把握
   レビューでは、
   ― “特定の運行事業者から空席情報が取得できなかった場合、その運行事業者のバスについて表示器に古い空席記号が表示され続けてしまう。”
   と指摘されています。古い空席数が残れば誤表示になります。
2. 対策の方針
   指摘に対し、D君は “④図2の処理(3)の最初に新たな処理を追加する対策案” を検討しました。
   処理(3)は “ターミナルの運行計画と照合し空席数を設定する” ため、その直前で対策を行えば古い値を無効化できます。
3. 追加すべき具体的処理
   誤表示を防ぐ最も確実な方法は、更新対象となる便の空席数をいったん未設定状態に戻すことです。ターミナルの運行計画で未設定を表す値は “null” と規定されています。
   ― “ターミナルの運行計画の空席数には初期値として null を設定する。”
   ― “ターミナルの運行計画の空席数が null の場合は、“—” を表示する。”
4. 結論
   したがって、新たに追加する処理は “ターミナルの運行計画に設定された空席数を null にする” となります。

誤りやすいポイント

• ファイル未取得時の表示を “×” と誤解し、空席数を０に初期化してしまう。
• “null” を単に空文字列や０と置き換えてしまう。
• 処理(1)や(2)に追加すると考え、更新前に上書きされ旧データが残る問題を解決できない。

FAQ