2021年3月6日開催「公共交通オープンデータ最前線 in インターナショナルオープンデータデイ2021」における野中綾介氏（国土交通省 九州運輸局）の発表資料です。

1. Ministry of Land, Infrastructure, Transport and Tourism
九州運輸局交通政策部交通企画課
令和３年３月６日
GTFS-JPを使った申請の検討について

2. 九州運輸局
おことわり
本日お話することは、国土交通省の公式見解で
はありません。
「お前が言うな」案件である事は自覚しています。
1
GTFSに関わってきて「良かった点」もですが、
どちらかというと、厳しい意見を頂けたらなと思ってます。
最後に溜まった鬱憤晴らしませんか？
かんたんなスライドで、
野中さんの想いを自由に語ってもらう感じで良いですので。
2/5 依頼メールより一部抜粋

3. 九州運輸局
伊藤先生の主張
平成３０年１１月、九州運輸局が開催した
「バス情報データ作成・活用シンポジウム2018」
に登壇した伊藤先生はこう述べられていました。
2
「運輸局へ提出する
書類も電子データで
出来る様にすべきだ」

4. 公共交通オープンデータ整備で
地域の移動をアップデートしよう
東京大学 生産技術研究所
伊藤昌毅
バス情報データ作成・活用シンポジウム2018
2018年11月8日
福岡県福岡市 福岡ガーデンパレス

5. • バス停時刻表
• デジタルサイネージ
• 申請・届出
• デジタル化によって業務の効率化と利用者へのより良い情報提
供を！
データがあれば業務は楽になる！（はず）

6. 運輸局への届出
• 2018年現在、紙が前提

7. 九州運輸局
電子申請の進展はあったのか
3
あれから２年半、進展はあったでしょうか？
一部の電子申請は認められたが、ＧＴＦＳ等の電子データの活用によるデ
ジタル化ではなく、媒体が「紙」から「電子」に変わっただけの内容
データを活用して、如何に効率よく業務を行うかという
視点での検討は全くなされていない
押印省略については拍手

8. 九州運輸局
GTFS-JPで申請する様になった場合を妄想してみた
4
①路線図や停留所一覧などの視覚化。
・T.Shimada‘s Data Lab. さんのGTFS Viewer
・GTFS Validation Report
こういった形で視覚化されたGTFSでないと意味がない。さらに、複数の事業者さんを重ねて見られるものがベスト。
Shapeが必須。
②運賃の運送法観点での検索や輸送実績など検索・集計が容易になるツール
A-B間の上限、実施、調整が三角表で検索出来る様になったり、条件を指定して輸送実績が集計出来るなど、紙より
も高度な作業が容易に出来るツールがあれば、データ申請の価値が高まる。
審査以外にも役立てる為のビューワー等の開発
GTFS-JPのままでは申請内容が理解が出来ないので、審査できる状態に表示するツールなどが必要。変更の場合は
、新旧両方のデータを使って変更箇所が分かる様に表示をしなければならない。
ただし、現行の様式に変換して、人間の眼で審査するだけであれば、データで申請する必然性が無い。
審査を可能にするためのツールの必要
データによる申請に意味を持たせるのであれば、日付住所などの形式審査、クリームスキミングの審査や運賃三角表
の審査など、数字により可否が判断出来るものについては、 GTFSチェックツールの様に機械審査によりエラーや警告
箇所を確認出来る様にすれば、審査の省力化につながりデータによる申請に価値が見いだせる。
審査の省力化に繋がるデータ利用

9. 九州運輸局
GTFS-JPから運行計画概要書を作る①
5
まずは、GTFS-JPで審査が可能かどうか、「運行計画概要書」へ変換
するツールを作成してみたら、とても面倒だった。
発生した問題
①route_idが役に立たない
A→B→C→DとD→C→B→Aが同一系統の往復と判断するのにroute_idを使えない。
左図の例でいえば、運送法の場合は経路１､2、3､4､5､6は
それぞれ1=2、3=4、5=6にペアリングされて赤系統、緑系統
、青系統の往路と復路と判断される。
一方、 GTFS-JPでは別のroute_idとする事が求められて
いる。その際、別のidを付すというルールさえ守られていれ
ば、相互のidに関連性は求められない。
jp_parent_route_idにより設定する事も可能だが、運用や
idの付け方は任意となっている。
結果、idを使わずにstop_times.txtから停留所の通過パター
ンを抽出し分類、往路と復路にペアリングしなおすという作業
が発生した。
最近では、 Googleから類似する経路は同一のroute_idに
する事を求められている事もあり、改善の見込みは無い。
GTFS-JP仕様書第二版より

10. 九州運輸局
GTFS-JPから運行計画概要書を作る②
6
②経過地が入力されていない
routes_jp.txtにvia_stopという項目で準備されているものの、ほぼ活用されていないうえにroute_idとの紐付けであるため、
使えない可能性がある。
しかし、運送法の手続では運行系統の違いを認識する要
素としてほぼ必須の記載項目となっており、左図の様に運
行計画概要書においても「主な経過地」として記載するよう
になっている。
「主な経過地」は事業者の判断によるものであり、
stop_times.txtから自動で作成するという事が出来ない。
そのため、運行計画概要書を作成する度に手入力の作
業が発生する。
→データ化の意味が無い
③stop_idがあてにならない
同一停留所の標柱違いは枝番であるとか、そもそも標柱毎に作るといった事が明確にルール化されていないので、運送
法の申請に利用できるという確証がない。

11. 九州運輸局
GTFS-JPから運行計画概要書を作る③
7
④新旧idが同じであっても、同一系統であるとは限らない
運送法の手続きでは新旧の運行計画を明示する事を求められる。すなわち新旧GTFS-JPを使って変更箇所を抽出す
る必要があるが、 GTFS-JPでは変更に際して旧のidと新のidを変更しないというルールは無いので、当該idが同一の
系統であるとは限らない。
したがって、idを使わずに同一系統である事を判断する必要があり、その手法については①の手法が利用できる。た
だし、同時に停留所にも変更が発生している可能性があり、かつstop_idについても新旧同一のもの使用するというルー
ルが無いため、名称又は位置情報で同一性を判断（名称が変わっていても同一場所なら新旧を同一停留所と判断）し
ていく必要がある。
新旧stops.txtを比較し、同位置で名
称が違うもの、名称が違うが同位置な
ものを確認。
同一性を確認したらstop_idが同じにな
るように修正。
修正後のstop_idを使って、stop_
timesから各tripの停留所通行パター
ンを抽出、同一パターンごとに運行系
統の往路と復路にに分類。
運行系統を新旧で比較し、曜日ごと
の回数や時刻などの変更点を抽出。
変更点の抽出により、運行系統の新
設、廃止も判断。
対象となる系統のみを概要書に反映
させて完成。
新旧idが同じならば同系統、同停留所という
ルールに統一されていれば、この工程が不要
となる
GTFS-JPから新旧変更箇所を抽出するための工程

12. 九州運輸局
GTFS-JPから運行計画概要書を作る④
8
⑤service_idが役に立たない
運行計画概要書では曜日ごとに時間帯運行回数を表示する必要がある。
例えば、第一便は「平日（月～金）」第二便は「月水金」とidを付した系統が存在する場合、月水金の運行回数は２回、火
木は１回となる。このような場合に平日１回、月水金１回というような記載は認められない。
データ作成の方法論としては、第一便をあえて二つのtrip_id
に分け、service_idを「月水金」と「火木」にする事でservice_id
毎の回数＝曜日毎の回数とする事も出来るが、基本的に
GTFS-JPではこの様な考え方をしていない。
変換にあたっての対処としては、一旦全ての曜日において時
間帯ごとの回数を算出し、同一の回数となる曜日ごとに分類、
分類に応じて「平日」「月水金」などの曜日名を作り、曜日名ご
とにエクセルの行（ぎょう）を分ける様に処理を行った。

13. 九州運輸局
GTFS-JPから補助金申請書を作る①
9
活用法の検討としてのGTFS-JPからフィーダー補助金認定申請の様式
へ変換するツールを作成してみたら、やっぱり面倒だった。
発生した問題 （運行計画概要書と同様の点を除く）
①系統の申請番号が判断出来ない
GTFS-JPには申請番号を入れる箇所が無いので、変換の過程で手作業にて入力をする必要がある。また、入力ルー
ルが徹底されていないroutes.txtの情報では系統の区別が出来ないので、通過する停留所の一覧など複数の情報を組
み合わせたものを表示した入力様式を作成しなければならない。
②距離が必須とされていない
フィーダー補助金申請においては主系統とみなし系統の判断が必要になるが、判断する為の要素となる「距離」が必
須とされていない。その為、①と同様に手入力の工程と入力様式が必要となる。
表１ 地域公共交通確保維持事業により運行を確保・維持する運行系統の概要及び運行予定者（地域内フィーダー系統） 30年度
起点 経由地 終点
運行態様の
別
基準ロで該
当する要件
接続する補助対象地
域間幹線系統等との
接続確保策
基準ニで該当
する要件
（別表７のみ）
（循環）
20.3 km
往 12.5 km
復 12.5 km
往 km
復 km
往 km
復 km
往 km
復 km
日
日
日
計画運
行日数
計画運行
回数
回
回
回
回
回
地域内フィーダー系統の基準適合
（別表７及び別表９）
市区町村 運行予定者名
運行系統名
（申請番号）
運行系統
再
編
特
例
措
置
〇〇 〇〇市役所 〇〇
(4)
〇〇市
✕✕町
(1) 〇〇線 365 1,825 路線定期 ①
日
300 1,200 〇 路線定期 ①
日
△△線 〇〇 〇〇センター △△
地域間幹線系統である●
●バスの▲▲線と◇◇停
留場にて接続
③
●●タクシー有限会社 (3) □□線 ✕✕地区 300 1,500 区域
(5)
②（１）
✕✕停留場において、鉄
道■■駅と接続 ①
〇〇交通株式会社
系統
キロ程
地域間幹線系統である●
●バスの▲▲線と◇◇停
留場にて接続
③
(2)
主系統のみを記載。回数について
は主系統とみなし系統の合算、日
数については主系統かみなし系統
のいずれかが運行する日数。

14. 九州運輸局
GTFS-JPから補助金申請書を作る②
10
仕様以外にも実務上の問題が…
①作成者が違うと使用が困難
GTFS-JPの作成者は事業者、補助金申請書の作成者は地方公共団体担当者になるのが一般的。 GTFS-JPは自由度
が高い故に他人が作ったGTFS-JPを理解して使いこなすことは難しく、場合によっては地方公共団体担当者にGTFS-JP
の知識が必要な事になる。
②半年前には作らないといけない
申請書に計上する「回数」「日数」は申請年の10月から翌
年9月となっている。これに対し認定申請は４、５月には準備
が必要となるので、10月以降のGTFS-JPを４月には作成し
ておかなければならない。また、タイミングによっては実際に
は使わないGTFS-JPをわざわざ作る必要がある。地方公共
団体の担当者は、それを事業者に依頼しないといけない。
③複数の事業者が対象となる場合のGTFS-JPの統合
フィーダー補助金は一つの申請で複数の事業者が対象となるケースが有る。その場合、GTFS-JPの統合もしく変換し
た後に統合するなどの作業を申請担当者が行う工程が発生する。

15. 九州運輸局
変換処理に関する結論
11
実際に変換処理を行ってみて
①現行のデータのみでも、一般的な形態のGTFS-JPを運行計画概要書に変換する事は可能でした。
②しかし、idの付け方を工夫し統一しないと工程が複雑になります。
複雑なので、運輸局のPCでは対応が難しい事も考えられます。
（実際に変換に相当な時間を要し、マシンパワーによって違いもでた。）
③工程が複雑である事は作業に時間を要する、活用の敷居が高くなるなど使い勝手の悪さにつながります。
使い勝手が悪ければ、運輸局側は電子データを管理する必要性を認めず、従来通りの申請を要求する事に
なります。
④変換中に入力作業が発生する事は、手間やミスを誘発するのでデータの活用としては問題が有ると思われ
ます。

16. 九州運輸局
データ内容を読むのに特殊な知識が必要で活用法も無いような状態では、GTFS-JPによる申請が認められる事はまず
ありません。業務の簡素化に繋がるビューワー、ツール、活用方法の検討を是非お願いします。
①審査用ツールの作成や活用法について検討を
提案
12
以上を踏まえ、GTFS-JPによる申請実現のため、どこかの誰
かに提案します。
強制ルール化や仕様の変更までを提案するつもりもありませんが、idの付し方など、ちょっとしたルール化や工夫により
運送法への対応が容易になるものについては、「この様にGTFS-JPを作成したら申請にも使えますよ」というガイドライン
はあってもいいんじゃないでしょうか。
②運送法対応推奨ガイドラインの作成を
GTFS-JPは「標準的な」フォーマットであり、オープンデータを前提としている事からも、改造は自由だと思います。例え
ば、「独自の情報を加える場合は名称に「_○○」と付けて説明のtxtを用意する」といったことをルール化して改造が可能
な事を明確化出来たら、輸送実績のデータを加えるなど活用の幅が広がるのではないかと思います。
③GTFS-JPの改造ルールを

17. 九州運輸局
さいごに
13
ここまで２年半以上にわたり、多くの方々にご指導いただきました。
本当にありがとうございました。
まだまだGTFS-JPが当たり前になるには時間がかかると思いますが、引
き続き九州運輸局ではGTFS-JPの普及に向けて支援していきたいと考え
ています。
データの作り方などお気軽にご相談下さい。
GTFS-JP（標準的なバス情報フォーマット）データの整備支援
https://wwwtb.mlit.go.jp/kyushu/m_koukatsu_00003.html
ご清聴ありがとうございました。