2022年 春期 応用情報技術者試験 問8

システム間のデータ連携方式

バスターミナルを運営するC社は，再開発に伴い，これまで散在していた小規模なバスターミナルを統合した，新たなバスターミナル（以下，新バスターミナルという）を運営することになった。

C社が運営する新バスターミナルには，複数のバス運行事業者（以下，運行事業者という）の高速バス，観光バス，路線バスが発着する。このうち高速バスと観光バスは指定席制又は定員制であり，空席がない場合は乗車できない。乗車券の販売は，各運行事業者が用意する販売端末やホームページで行う。

新バスターミナルでは，新バスターミナルシステムとして，バスの発着を管理する運行管理システム，及びバスの発車時刻，発車番線，空席の有無などを利用者に案内する案内表示システムを導入することになり，C社の情報システム部に所属するD君が，運行事業者から空席の情報を取得するデータ連携方式の設計を行うことになった。

[新バスターミナルシステムの概要]

新バスターミナルシステムの概要を図1に示す。

図1 新バスターミナルシステムの概要

運行管理システムがもつ案内表示に関連する機能を表1に，案内表示システムがもつ機能を表2に，表示器の表示項目の例を表3に示す。

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

E社，F社，G社の空席情報の連携機能が提供しているデータ項目の書式と例を表5に示す。

表5 空席情報の連携機能が提供しているデータ項目の書式と例（抜粋）
運行事業者書式/例発車日発車時刻路線コード便コード空席数座席数
E社書式YYYYMMDDhhmm3桁3桁4桁4桁
例20220510120010120000200040
F社書式YYMMDDhhmm5桁1)可変長可変長
例2205101300900011030
G社書式YYYY-MM-DDhh:mm3桁2桁可変長可変長
例2022-05-1018:0030110840
注記 複数の種別のバスを運行する運行事業者は，路線コードと便コードを共通の書式で管理している。
注 1) F社は一つのコードで路線と便を管理している。

[データ項目の検討]

D君は，表5の情報を基に，運行管理システムが運行事業者から取得する空席情報ファイルのレコード構成，データ項目を検討した。

・空席情報ファイルは，ヘッダレコード1件と必要な数のデータレコードから成り，ヘッダレコードには，作成日，作成時刻に加え，データレコード件数を含むことにした。

・路線コード，便コードが運行事業者間で重複しないよう，二つのコードを結合し，運行事業者ごとのコードを付加した一つのコード（以下，統合便コードという）として取り扱うことにした。この統合便コードは，新バスターミナルシステム全体で使用する。この検討において，①表5の運行事業者以外の情報も調査し，問題がないことを確認した。

・②ファイル形式はCSV形式，文字コードはUTF-8とし，各項目の書式を揃えた。

空席情報ファイルのデータレコードの内容を表6に示す。

表6 空席情報ファイルのデータレコードの内容
発車日発車時刻統合便コード空席数座席数
YYYYMMDDhhmm路線コードと便コードとを結合した文字列の先頭に，運行事業者ごとのコード→文字（運行事業者コード：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に示す。

(1) 受信用フォルダの空席情報ファイルを基に，空席情報を発車日，発車時刻順に格納した統合空席情報ファイルを作成する。

(2) (1)で使用した運行事業者ごとの空席情報ファイルを，選択用のフォルダに移動し，受信用フォルダから削除する。

(3) (1)で作成した統合空席情報ファイルを読み込み，ターミナルの運行計画と照合する。発車日，統合便コードが一致するターミナルの運行計画に空席数を設定する。

図2 空席情報ファイルの取得から設定の処理の検討内容

表7及び図2で検討した処理について，情報システム部内でレビューを実施したところ，次のような指摘があった。

（i）運行事業者とのデータ連携においてFTPによるファイル転送を用いる場合は，ファイル全体が正しく転送されたことを確認する必要がある。

（ii）特定の運行事業者から空席情報が取得できなかった場合，その運行事業者のバスについて表示器に占い空席記号が表示され続けてしまう。

D君は，（i）の指摘に対して運行事業者データ連携機能に空席情報ファイルのaとbが一致することを確認する処理を追加する対策案，及び（ii）の指摘に対して④図2の処理(3)の最初に新たな処理を追加する対策案の検討を行い，再度レビューを実施した。

D君は対策案が承認された後，後続の開発作業に着手した。

出典：令和4年度 春期 応用情報技術者試験 午後 問8