令和4年度 春期 応用情報技術者試験 午後 問8 新バスターミナルにおける運行事業者との空席データ連携と例外処理の設計
テクノロジシステム開発技術
学習ガイド
統合バスターミナルの案内表示に向けて、複数のバス運行会社から空席情報を集約するシステム間連携を扱います。論点は、異種コードを統合するデータ変換、CSVファイルやWeb抽出の特性、FTP転送時の件数チェック、および取得失敗時の画面表示制御です。表4から表6のデータ定義を読み解いて統合便コードや日時の変換ルールを特定し、後半のレビュー指摘事項からデータ欠落防止策と表示クリア処理の必要性を導き出します。
この記事で押さえる論点
- 複数事業者のコード体系を統合するデータクレンジングと項目変換ルールを説明できる
- CSVファイルの特徴とWebスクレイピングを用いたデータ抽出方式を理解できる
- ファイル転送時の欠落を防ぐヘッダ件数と実データ件数の突合チェックを説明できる
- データ取得失敗時に古い案内表示が残存することを防ぐ例外処理の仕組みを述べられる
出題情報
- 出題
- 2022(R4)春 応用情報技術者 午後 問8
- 配点
- 20点満点
- 模範解答
- 公表(設問ごとに掲載)
出題趣旨・採点講評(IPA 公表)
複数のシステムが連携する業務のシステム開発では,開発の初期段階におけるデータ連携方式の検討が重要である。本問では,バス運行事業者とバスターミナル間で空席情報を連携させる処理を題材に,コード体系,ファイル形式,及びデータの転送方法の特性を理解し,データ連携方式を検討する能力を問う。
問8では,バス運行事業者とバスターミナル間で空席情報を連携させる処理を題材に,コード体系,ファイル形式,データの転送方法,及びデータ連携方式について出題した。全体として正答率は平均的であった。
問題本文
問8 システム間のデータ連携方式に関する次の記述を読んで,設問1〜5に答えよ。
バスターミナルを運営するC社は,再開発に伴い,これまで散在していた小規模なバスターミナルを統合した,新たなバスターミナル(以下,新バスターミナルという)を運営することになった。
C社が運営する新バスターミナルには,複数のバス運行事業者(以下,運行事業者という)の高速バス,観光バス,路線バスが発着する。このうち高速バスと観光バスは指定席制又は定員制であり,空席がない場合は乗車できない。乗車券の販売は,各運行事業者が用意する販売端末やホームページで行う。
新バスターミナルでは,新バスターミナルシステムとして,バスの発着を管理する運行管理システム,及びバスの発車時刻,発車番線,空席の有無などを利用者に案内する案内表示システムを導入することになり,C社の情報システム部に所属するD君が,運行事業者から空席の情報を取得するデータ連携方式の設計を行うことになった。
〔新バスターミナルシステムの概要〕
新バスターミナルシステムの概要を図1に示す。

図の説明テキスト
図1 新バスターミナルシステムの概要
構成要素とデータの流れを示すブロック図。
外部システムとして「運行事業者1」〜「運行事業者m」がある。
「新バスターミナルシステム」内に「運行管理システム」と「案内表示システム」がある。
【運行管理システム内の構成】
- 受信用フォルダ: 「運行事業者データ連携機能(運行事業者ごと)」を通じて外部の各運行事業者からデータを受信し、「運行計画情報1」「空席情報1」〜「運行計画情報m」「空席情報m」ファイルとして保存する。
- 運行計画作成機能: 運行計画情報ファイル群を読み込み、「ターミナルの運行計画」データベースへ書き込む。
- 空席情報取得機能: 空席情報ファイル群を読み込み、「統合空席情報」データベースへ書き込む。
- 空席情報設定機能: 「統合空席情報」データベースから読み込み、「ターミナルの運行計画」データベースへ書き込む。
【案内表示システム内の構成】 - 案内表示機能: 運行管理システムの「ターミナルの運行計画」データベースからデータを受け取り、「表示器1」〜「表示器n」へデータを出力する。
【凡例】 - 実線矢印: データの流れ
- 平行四辺形: ファイル
- 角丸の長方形(左右辺が二重線): データベース
【注記】
運行管理システムには上記以外の機能もあるが,本問では省略している。
運行管理システムがもつ案内表示に関連する機能を表1に,案内表示システムがもつ機能を表2に,表示器の表示項目の例を表3に示す。

図の説明テキスト
表1 運行管理システムがもつ案内表示に関連する機能
| 機能 | 概要 |
|---|---|
| 運行事業者データ連携機能 | 各運行事業者から月に1回提供される運行計画情報,及び各運行事業者との連携によって一定の間隔で得られる空席情報を運行管理システムに取り込む。取り込んだ情報を収めたファイルは,受信用フォルダに格納する。その際,運行事業者ごとに決められたファイル名を使用し,同名のファイルがある場合は,最新のファイルで上書きする。 |
| 運行計画作成機能 | 受信用フォルダに格納された各運行事業者の運行計画情報を基に,新バスターミナルを発着するバスの運行予定を表すターミナルの運行計画を月に1回作成する。このとき,ターミナルの運行計画の空席数には初期値としてnullを設定する。運休などの変更発生時は,運行事業者からC社に変更情報が送付され,ターミナルの運行計画を変更する。作成したターミナルの運行計画は,案内表示システムからも参照が可能である。 |
| 空席情報取得機能 | 受信用フォルダに格納された高速バスや観光バスを運行する運行事業者の空席情報ファイルを取得し,情報を併合して,高速バス,観光バスの発車日,便ごとの識別情報と空席数を保持する統合空席情報ファイルを作成する。一部の運行事業者の空席情報ファイルが取得できない場合は,取得できた分だけで統合空席情報ファイルを作成する。 |
| 空席情報設定機能 | 統合空席情報ファイルに格納された発車日,便ごとの空席数を基に,ターミナルの運行計画に空席数を設定する。情報は上書きする。統合空席情報ファイルに空席数の情報がない便は,何もしない。 |

図の説明テキスト
表2 案内表示システムがもつ機能
| 機能 | 概要 |
|---|---|
| 案内表示機能 | ターミナルの運行計画を基に,表3の例のように表示器に出発便の案内表示を行う。表示器は複数の場所に設置されていて,総合案内所や乗り場などの設置場所によって表示の仕方を変える。ターミナルの運行計画に空席数が設定されている便については,空席数に対応する空席記号(○,△,×)を表示する。表示する空席記号は別途定義するしきい値によって決定する。ターミナルの運行計画の空席数がnullの場合は,“―”を表示する。 |

図の説明テキスト
表3 表示器の表示項目の例
| 発車時刻 | 種別 | 路線・行先 | 運行事業者 | 発車番線 | 空席記号 |
|---|---|---|---|---|---|
| 12:00 | 高速バス | 路線A 〇〇行 | F社 | 1 | ○ |
| 12:30 | 路線バス | 路線B □□行 | E社 | 4 | ― |
| 12:45 | 観光バス | ■■周遊コース | H社 | 2 | × |
| ⋮ | ⋮ | ⋮ | ⋮ | ⋮ | ⋮ |
〔運行事業者の概要と連携機能の有無〕
運行事業者データ連携機能の空席情報を取得する処理について,運行事業者が空席情報を含むデータの連携機能をもつ場合には,それを活用する方針とした。そこで,D君は,高速バス,観光バスの運行事業者であるE社,F社,G社,H社について,運行している全てのバスの種別と連携機能の有無を調査した。調査結果を表4に示す。
なお,高速バス,観光バスの運行事業者は上記の4社だけであるが,路線バスだけを運行する運行事業者であるS社,T社が存在する。

図の説明テキスト
表4 E社, F社, G社, H社の調査結果
| 運行事業者 | 種別 | 空席情報に関する連携機能の有無 |
|---|---|---|
| E 社 | 高速バス 路線バス |
高速バスについて,空席情報を含むファイルを作成し,ファイル転送を行う機能がある。 ファイル形式は固定長,ファイルの文字コードはシフト JIS コードである。 |
| F 社 | 高速バス | 要求を受け付け,便ごとの空席数を回答する API を提供している。 回答の形式は XML,文字コードは UTF-8 である。 |
| G 社 | 高速バス 観光バス |
高速バス,観光バスについて,空席情報を含むファイルを作成する機能がある。 ファイル形式は CSV,ファイルの文字コードは UTF-8 である。 |
| H 社 | 観光バス | 空席情報に関するファイル作成や API の機能はない。 ただし,H 社 Web ページに便ごとの空席情報を掲載している。 |
E社,F社,G社の空席情報の連携機能が提供しているデータ項目の書式と例を表5に示す。

図の説明テキスト
表5 空席情報の連携機能が提供しているデータ項目の書式と例(抜粋)
| 運行事業者 | 書式/例 | 発車日 | 発車時刻 | 路線コード | 便コード | 空席数 | 座席数 |
|---|---|---|---|---|---|---|---|
| E 社 | 書式 | YYYYMMDD | hhmm | 3 桁 | 3 桁 | 4 桁 | 4 桁 |
| E 社 | 例 | 20220510 | 1200 | 101 | 200 | 0020 | 0040 |
| F 社 | 書式 | YYMMDD | hhmm | colspan=2: 5 桁 1) | 可変長 | 可変長 | |
| F 社 | 例 | 220510 | 1300 | colspan=2: 90001 | 10 | 30 | |
| G 社 | 書式 | YYYY-MM-DD | hh:mm | 3 桁 | 2 桁 | 可変長 | 可変長 |
| G 社 | 例 | 2022-05-10 | 18:00 | 301 | 10 | 8 | 40 |
注記 複数の種別のバスを運行する運行事業者は,路線コードと便コードを共通の書式で管理している。
注 1) F社は一つのコードで路線と便を管理している。
〔データ項目の検討〕
D君は,表5の情報を基に,運行管理システムが運行事業者から取得する空席情報ファイルのレコード構成,データ項目を検討した。
- 空席情報ファイルは,ヘッダレコード1件と必要な数のデータレコードから成り,ヘッダレコードには,作成日,作成時刻に加え,データレコード件数を含めることにした。
- 路線コード,便コードが運行事業者間で重複しないよう,二つのコードを結合し,運行事業者ごとのコードを付加した一つのコード(以下,統合便コードという)として取り扱うことにした。この統合便コードは,新バスターミナルシステム全体で使用する。この検討において,①表5の運行事業者以外の情報も調査し,問題がないことを確認した。
- ②ファイル形式はCSV形式,文字コードはUTF-8とし,各項目の書式を揃えた。
空席情報ファイルのデータレコードの内容を表6に示す。

図の説明テキスト
表6 空席情報ファイルのデータレコードの内容
| 発車日 | 発車時刻 | 統合便コード | 空席数 | 座席数 |
|---|---|---|---|---|
| YYYYMMDD | hhmm | 路線コードと便コードとを結合した文字列の先頭に,運行事業者ごとのコード一文字(運行事業者コード:E,F,G,H,…)を付加して,8 桁のコードにする。桁数が 8 桁に満たない場合は,運行事業者コードの後にゼロパディングを行う。 | 可変長 | 可変長 |
〔連携方法の検討〕
D君は,連携方法について,それぞれの運行事業者と調整を行った。H社については運行する便数が少ないこともあり,開発費用が比較的安価である③Webページから情報を抽出する方法を用いることにした。連携方法に関する調整結果を表7に示す。

図の説明テキスト
表7 連携方法に関する調整結果
| 運行事業者 | 概要 |
|---|---|
| E 社 | E 社サーバが E 社の空席情報を含むファイルを C 社向けに変換し,E 社サーバ内に格納する。E 社サーバが 5 分ごとに FTP で E 社サーバ内の空席情報ファイルを C 社サーバ内の受信用フォルダに送信する。 |
| F 社 | C 社サーバが 5 分ごとに F 社 API で空席情報を要求し,API の回答から F 社の空席情報ファイルを作成して C 社サーバ内の受信用フォルダに格納する。 |
| G 社 | G 社サーバが G 社の空席情報を含むファイルを C 社向けに変換し,G 社サーバ内に格納する。C 社サーバが 5 分ごとに FTP で G 社サーバ内の空席情報ファイルを取得し,C 社サーバ内の受信用フォルダに格納する。 |
| H 社 | C 社サーバが 5 分ごとに H 社 Web ページから空席情報を取得し,H 社の空席情報ファイルを作成して C 社サーバ内の受信用フォルダに格納する。 |
〔空席情報取得機能と空席情報設定機能の処理について〕
D君が検討した空席情報取得機能と空席情報設定機能を用いた空席情報ファイルの取得から設定の処理について,図2に示す。

図の説明テキスト
図2 空席情報ファイルの取得から設定の処理の検討内容
(1) 受信用フォルダの空席情報ファイルを基に,空席情報を発車日,発車時刻順に格納した統合空席情報ファイルを作成する。
(2) (1)で使用した運行事業者ごとの空席情報ファイルを,退避用のフォルダに移動し,受信用フォルダから削除する。
(3) (1)で作成した統合空席情報ファイルを読み込み,ターミナルの運行計画と照合する。発車日,統合便コードが一致するターミナルの運行計画に空席数を設定する。
表7及び図2で検討した処理について,情報システム部内でレビューを実施したところ,次のような指摘があった。
(i) 運行事業者とのデータ連携においてFTPによるファイル転送を用いる場合は,ファイル全体が正しく転送されたことを確認する必要がある。
(ii) 特定の運行事業者から空席情報が取得できなかった場合,その運行事業者のバスについて表示器に古い空席記号が表示され続けてしまう。
D君は,(i)の指摘に対して運行事業者データ連携機能に空席情報ファイルのaとbが一致することを確認する処理を追加する対策案,及び(ii)の指摘に対して④図2の処理(3)の最初に新たな処理を追加する対策案の検討を行い,再度レビューを実施した。
D君は対策案が承認された後,後続の開発作業に着手した。
設問と解答・解説
設問1
〔データ項目の検討〕について,(1), (2)に答えよ。
本文中の下線①について,表5以外に調査した運行事業者を全て答えよ。
模範解答
H社,S社,T社
採点基準
- 4点: H社、S社、T社の3つの事業者をすべて解答している。
- 2点: 3つのうち1〜2つの事業者を解答している。
- 0点: それ以外。
解説
〔運行事業者の概要と連携機能の有無〕の記載によれば、高速バス、観光バスの運行事業者はE社、F社、G社、H社の4社であり、さらに路線バスのみを運行する事業者としてS社、T社が存在することが明記されています。
一方、表5にはE社、F社、G社の情報が記載されています。
したがって、統合便コードが新バスターミナルシステム全体で使用されるにあたり、表5に記載されていない運行事業者はH社、S社、T社の3社となります。
高得点のポイント
・調査対象となる全6社のうち、表5に含まれない3社を漏れなく挙げることが求められます。
表5のG社の例について,発車日,発車時刻,統合便コード,空席数を表6に合わせて変換した場合の変換後の値を答えよ。
模範解答
発車日: 20220510, 発車時刻: 1800, 統合便コード: G0030110, 空席数: 8
採点基準
- 4点: 発車日、発車時刻、統合便コード、空席数の4項目すべてが正しく変換されている。
- 3点: 3項目が正しく変換されている。
- 2点: 2項目が正しく変換されている。
- 1点: 1項目が正しく変換されている。
- 0点: 正しく変換されている項目がない。
解説
表5のG社の例(発車日: 2022-05-10, 発車時刻: 18:00, 路線コード: 301, 便コード: 10, 空席数: 8)を、表6の書式に合わせて変換します。
発車日は YYYYMMDD の形式にするため、ハイフンを除き「20220510」とします。
発車時刻は hhmm の形式にするため、コロンを除き「1800」とします。
統合便コードは、路線コード「301」と便コード「10」を結合して「30110」とし、先頭に運行事業者コード「G」を付加して「G30110」とします。8桁に満たない場合は運行事業者コードの後にゼロパディングを行うため、「G0030110」となります。
空席数は可変長のため、そのまま「8」とします。
高得点のポイント
・指定された各項目のフォーマット(ゼロパディングの位置や区切り文字の削除など)を正確に適用していることがポイントです。
設問2
本文中の下線②について,CSVファイルの特徴として適切なものを解答群の中から全て選び,記号で答えよ。
模範解答
選択肢ア: XMLファイルと比較して,1レコード当たりのデータサイズが小さい。
選択肢エ: 固定長ファイルと比較して,処理速度が遅い。
解説
CSV (Comma-Separated Values) ファイルは、データをカンマ区切りで表現するテキスト形式です。
固定長ファイルは各項目のバイト数が決まっているため、区切り文字を探す処理が不要で処理速度が速い一方、CSVファイルは区切り文字を探索しながら読み込む必要があり、処理速度は固定長ファイルと比較して遅くなります。
また、XMLファイルはデータにタグを付加して構造を記述するためデータサイズが大きくなりますが、CSVファイルはタグが不要なため、1レコード当たりのデータサイズはXMLファイルと比較して小さくなります。
各選択肢の解説
・ア: 正解です。XMLのようなタグがないためデータサイズは小さくなります。
・イ: XMLファイルのパース処理に比べると、一般的にCSVファイルの方が構造が単純であり処理速度は速くなります。
・ウ: CSVファイルは区切り文字で項目を分けるため、固定長ファイルと比較して項目の桁数や文字数に関する自由度は高くなります。
・エ: 正解です。固定長ファイルと比較すると、区切り文字の探索処理が必要な分、処理速度は遅くなります。
設問3
本文中の下線③の名称として適切な字句を解答群の中から選び,記号で答えよ。
模範解答
選択肢エ: Webスクレイピング
解説
H社の空席情報取得について「Webページから情報を抽出する方法」と説明されています。
Webページを構成するHTMLなどのデータから、プログラムを用いて必要な情報を自動的に抽出・収集する技術をWebスクレイピングと呼びます。
各選択肢の解説
・ア: WAIは、Webアクセシビリティを推進するための組織や活動を指す用語であり、情報を抽出する技術ではありません。
・イ: Web APIは、プログラム間でデータをやり取りするためのインタフェースですが、表4においてH社はAPIの機能はないと記載されています。
・ウ: Webコンテンツは、Webページ上のテキストや画像などの情報の総称であり、抽出する方法の名称ではありません。
・エ: 正解です。Webページから情報を抽出する手法として適切です。
模範解答
ヘッダレコードのデータレコード件数,処理したデータレコードの件数
採点基準
- 6点: 「ヘッダレコードのデータレコード件数」と「処理したデータレコードの件数」の2つを1つずつ答えている。
- 3点: 「ヘッダレコードのデータレコード件数」または「処理したデータレコードの件数」のどちらか1種類のみを答えている(同じ正解を二つ書いた場合を含む)。
- 0点: 「ヘッダレコードのデータレコード件数」と「処理したデータレコードの件数」のいずれも答えていない(同じ誤答を二つ書いた場合を含む)。
解説
解説
FTPによるファイル転送において、データレコードの欠落がなくファイル全体が正しく転送されたことを確認するための処理を検討します。
〔データ項目の検討〕において、空席情報ファイルは「ヘッダレコード1件と必要な数のデータレコードから成り,ヘッダレコードには,作成日,作成時刻に加え,データレコード件数を含める」と定義されています。
したがって、受信したファイルのヘッダレコードに記録された件数と、受信側で実際に処理対象として読み込んだデータレコードの件数が一致することを確認すれば、転送中の欠落を検知できます。
空欄 a・b に入る字句は比較対象となる件数そのものであるため、「ヘッダレコードのデータレコード件数」と「処理したデータレコードの件数」が入ります(順不同)。
高得点のポイント
- 比較すべき2つの値がそれぞれ何を表す件数かを問題文の用語を用いて正確に把握すること。
- 空欄に入る字句は比較処理の手順ではなく、件数を表す名詞句であることに注意すること。
なお、採点基準は、正解の2つを1つずつ答えている場合は満点、正解のうち1種類だけを答えている場合(同じ正解を二つ書いた場合を含む)は半分、正解を1つも答えていない場合(同じ誤答を二つ書いた場合を含む)は0点となります。
設問4は,正答率が低かった。FTPにおける転送データの欠落を検知するためには幾つかの方法があるが,本問では空席情報ファイルのヘッダーレコードにデータレコード件数を含めることが示されており,この値を用いてデータレコード件数を確認できることに着目して正答を導き出してほしい。
設問5
本文中の下線④で追加した処理の内容を35字以内で述べよ。
模範解答
ターミナルの運行計画に設定された空席数をnullにする。
採点基準
- 2点: ターミナルの運行計画の空席数をnullにする旨が記載されている。
- 1点: ターミナルの運行計画を初期化する、または空席数をリセットする旨が記載されているが、nullを設定することが明記されていない。
- 0点: それ以外。
解説
特定の運行事業者から空席情報が取得できなかった場合、処理(3)においてターミナルの運行計画の空席数が更新されず、前回の古い空席記号が表示され続けてしまうという課題があります。
表1の「運行計画作成機能」では、ターミナルの運行計画の空席数には初期値としてnullを設定するとあり、表2の「案内表示機能」では空席数がnullの場合は「―」を表示すると定義されています。
したがって、取得できなかった便の古い情報が残らないようにするためには、処理(3)で取得した空席情報を用いて上書きする前に、ターミナルの運行計画の空席数を一旦nullにリセットする処理を追加する必要があります。
高得点のポイント
・更新対象となる「ターミナルの運行計画」の「空席数」に対して「nullを設定する」という具体的な操作が明記されていることが評価のポイントです。
設問5は,正答率が低かった。システム間のデータ連携においては,相手側システムの状態によって,期待したデータが連携されないことも考えられる。そのため,データが連携されなかった場合を想定した事前の検討が重要である。本問では,空席情報が取得できなかった場合,表示器に表示すべき項目を検討することで,実施する処理の内容を導き出してほしい。