DEIM Forum 2019 H8-4

スター型デマンド分布に対する寄り道型デマンドバスの活用手法の提案
坂井 佑理†

浅野 泰仁†† 京都大学情報学研究科社会情報学専攻分散情報システム分野 〒 606–8501 京都府京都市左京区吉田本町
E-mail: †yuuri.sakai@db.soc.i.kyoto-u.ac.jp, ††asano@i.kyoto-u.ac.jp
あらまし

本研究では，鉄道駅などを中心としたスター型のデマンド分布を持つ地域の公共交通機関として，「寄り道型デマンドバス」を活用することを提案する．寄り道型デマンドバスとはデマンドバスのうち，過去のデマンドデー
タなどをもとにして，大まかな運行ルートを事前に決定しておく方式のものを指す．スター型デマンド分布を持つベッドタウンなどにおいては，車両基地とデマンド分布の中心を行き来する路線が必要になる．この場合，従来の路線バ
スでは沿線人口と利便性を同時に確保するために系統数が増え全体の本数が過剰になるところを，寄り道型デマンドバスを用いて本数を抑えつつも利便性の低下を防ぐことを目指す．また，通勤通学などのための定期利用をユーザに登録してもらい事前のダイヤ構築に用いることで，より効率的な運行を行う．本論文では定期利用データを用いて事前に決定する「基本ダイヤ」の設計アルゴリズムの提案を行う．
キーワード 公共交通，デマンドバス，DRT，新交通，域内交通，路線設計
着点固定型設計の場合，利便性のために各系統に一定の便数を1 はじめに
大都市や地方中核都市近郊のベッドタウンや地方都市において，急速な人口集積が進んでいる．しかし交通インフラの発達がそれに追いついているとは言いがたい地域も多く存在する．
鉄道駅は存在するがそこまでのフィーダー輸送が未発達な地域
や，効率的な域内交通網が構築されていない地域などにおいては，人口規模の割に公共交通の利便性が低くくなる傾向にある．
本研究では，そのような人口密集地域に対し「寄り道型デマンドバス」を導入し効率のいい公共交通体系を構築することを目指す．
本研究では，域内交通において特に特定時間帯において「ある一点に向かう移動需要」ないし「ある一点から出発する移動需要」が多数を占める地域に着目する．たとえば都心に向かう
鉄道路線の駅が地域に存在する場合，特に朝の通勤通学時間帯
においては，地域住民の多くはその駅へと向かう．逆に帰宅時
間帯では，駅からそれぞれの自宅へと向かう移動需要が発生す
る．あるいは駅ではなく，地域の中心街でも同じようなことが起こり得る．この移動需要が集中する点を「デマンド集積点」と呼び，域内からデマンド集積点へと出入りする移動需要が特定時間帯において一定以上の割合を占める場合，そのデマンド

設定しなければならず，結果として地域全体での便数が過剰になる恐れがある．逆に人口に即した便数設定を行うと，今度は各系統の便数が減り利便性が低下するという問題が生じる．
この問題に対処するために，本研究では一定規模のスター型
デマンド分布を持つ地域に「寄り道型デマンドバス」を導入することを提案する．
「デマンドバス」とは，ユーザから出発地
点・到着地点・出発時刻・到着時刻などの希望を予約という形で受け付け，その予約をより多く満たせるような運行ダイヤをその都度構築するバス形態を指す．デマンドバスは従来，予約に基づいたダイヤ構築により運行便に少ないデマンドを集約できるという特徴を期待され，過疎地域や中山間地域でも一般的な公共交通システムに比べて採算性を改善できる可能性がある
ものとして論じられてきた．しかし近年，大規模なデマンドが発生する都市部において，デマンドバスはより効率的な運用ができるとのシミュレーション結果が示され [1]，多くのデマンドを効率的に処理する方法が検討されるようになった．
特に，デマンドバスは固定路線バスよりもスター型デマンド
分布を効率的に処理できることが野田ら [1] のシミュレーショ
ンにより示されている．デマンドバスは運行時に予約が入っている，すなわち乗車待ちのユーザが存在する地点を辿るように分布を「スター型デマンド分布」と呼ぶこととする．
スター型デマンド分布に乗合バスで対応する場合，バス路線の沿線人口を増やすためには，デマンド集積点を経由ないし発着点とする路線の系統数を増やすことで，バスの通過する地区
を増やさなければならない．しかし，域内にいくつも車両基地

デマンド集積点（鉄道駅，市街中心部など）を設置するのはコストの面で現実的ではないため，系統数を増やすとしてもバス車両の出発地は限られる．そのため「車両基地とデマンド集積点を往復する」系統を経由地を変え複数設定することで沿線人口を確保する，という方法が取られる．こういった路線設計を「発着点固定型設計」と呼ぶこととする．発

図 1 スター型デマンド分布

デマンド集積点（鉄道駅，市街中心部など）走行するため，従来の固定路線バスの系統に照らし合わせるとまた，「寄り道型」では曖昧ながら事前に大まかなダイヤが把複数系統に跨った運行になることがある．これは前述した「地握できるため，他のデマンドバスよりも比較的バス車両や乗務域人口に比べて多数の系統を設定することで沿線人口を確保し員の運用計画が立てやすい．予約を受け付ける前でも走行ルーなければならない」という固定路線バスの問題点を解決できる，

トの概要，ひいては走行距離・時間を把握することができ，そデマンドバスの優れた点と言える．

れに合わせて運用を事業者にとって都合のいい形に決定・固定

しかしデマンドバスは運行ダイヤがその時々の予約によってすることができるということである．これは運用上の利点にな左右され，また他の予約との兼ね合いのために予約の受理率をるだけでなく，ユーザにとっても予約以前から自分の移動ルー100%にすることが困難であるという性質ゆえに，朝の通勤通

トに対する所要時間を予想することができるという利点がある．

学など毎日時間の決まった需要に応えにくいという弱点を持つ．

例えば路線バスユーザは，自宅から鉄道駅までのバスでの所要この弱点のために現在実際に運用されているデマンドバスでは，時間を把握していて，日々の移動計画を立てる上でその知識を主婦の買い物や高齢者の通院といった外出に時間的制約が少な

参考にしている．あるいは，バス路線図に書かれた主要停留所

い用途にサービスの利用目的が限られてしまっている．[2] 公共間の概算所要時間を参考に移動計画を考える，ということも行

交通機関にとって，定期的な利用の獲得は採算性の面においてわれている．そういった従来の利用方法にも寄り道型デマンド

大きなポイントであり，デマンドバスを大規模運用するにはこバスは対応できる．予約受付前に用意する曖昧なルートは半年の問題を解決しなければならない．

や 1 年という長いスパンで改正するとすれば，各地点間での所

また人口密集地域における大規模運用となると，バス車両や要時間などは大きくは変動しない．すなわち出発地／目的地の乗務員の運用計画が問題になる．デマンドバスの多くの設計で組が同じであれば，いつでも所要時間は概ね同じになるというは，実際に予約を受け付けそれに基づいたルート計算をするまことである．

で，各バス車両がどういったルートを走るかは運行事業者にもこれらの特徴を持つ「寄り道型デマンドバス」を用いて，本わからない．その場合，事前に決めておかなければならないバ

研究では人口密集地域で既存の固定路線バスに代わる，新たなス車両や乗務員の運用計画を緻密に立てることが困難になる．

公共交通機関の提案を行う．本論文では基本ダイヤ構築アルゴ

バス車両は回送距離を減らし効率的な運用をすることが採算性リズムを提案し，構築された基本ダイヤの考察を行う．

向上に繋がるし，乗務員の人数と連続乗務時間には制限がある．
また，無理のない乗務計画を立てることは乗務員の労働環境の改善に繋がる．
そこで，本研究ではデマンドバスのサブタイプの中から「寄り道型デマンドバス」を採用する．
「寄り道型デマンドバス」とは，過去のデマンドデータなどから事前にある程度大まかにダイヤを決定しておくタイプのデマンドバスを指す．実際の運行
ダイヤは予約を見て，事前に決めたダイヤから「寄り道」する形で決定する．つまり，曖昧ながらも固定路線バスのように系統が存在するデマンドバスといえる．この事前に決定しておく
ダイヤのことを本研究では「基本ダイヤ」，予約受付後に決定する詳細なダイヤを「運行ダイヤ」と呼ぶ．この基本ダイヤからの「寄り道」を利用することで，従来の固定路線バスの系統を複数まとめるような形で統合することを本研究では目指す．
系統をまとめつつ，乗車待ちのユーザがいる地点を優先して走行することで，各系統の便数は維持ないしやや増便しつつ，全体の便数を削減できる効果が期待される．
さらに「寄り道型」の特徴を利用することで，前述のデマン
ドバスの 2 つの欠点に対応する．まず安定した定期的な利用を可能にするための仕組みとして本研究では「定期利用登録」によるユーザの定期的な利用データを収集し，それを基本ダイヤ作成に利用する．
「寄り道型」では事前に設計する基本ダイヤの中に「必ずこの時刻にこの地点に立ち寄る」という制約を含めておくことができる．予約受付後に実際に各バス車両に指示する詳細な運行ダイヤを決定するが，その際に定期利用登録を受理しているユーザについては必ずその内容を守るようにダイヤ設計を行う，ということである．これによりデマンドバスの弱点とされていた定期的な利用への安定した対応を実現する．

2 デマンドバスの現状
英語圏では Demand Responsive Transport (DRT) と呼ばれる交通形態の中に含まれている．その時々の需要に合わせた
柔軟な運行が可能であるとして古くより注目され，イギリスでは 1970 年代に電話予約によるサービスが開始されていた [3]．
予約に応じたダイヤ構築は人間のオペレータに長年任されてきたが，近年では計算機の発達によりダイヤ構築のアルゴリズム
開発が行われており，小規模サービス向けであれば予約システ
ムからバス運転手へのナビゲーションシステムまでを一体化したアプリケーションが既に開発・販売されている．
日本においては，東京大学オンデマンド交通プロジェクトがシステムを開発した「コンビニクル」が，順風路株式会社により各地で実運用されているほか [4]，多様な地域事情を鑑みて様々なデマンドバス形態が提案されている [2] [5] [6] [7]．

3 デマンドバスのサブタイプ
本研究ではデマンドバスのサブタイプ分類のために 4 つの軸を用いる．

3. 1 ルートの柔軟性
公共交通機関は一般にダイヤに基づいて運行されている．ダ
イヤは「どの経由地をいつ通過するか」という形で表され，運行ルートの情報と時刻表情報を含んでいる．
デマンドバスのルートは予約に応じて決定されるが，その際にルートにかける制約によってデマンドバスは「フルデマンド型」「セミデマンド型」「寄り道型」の 3 種類に分類される．

フルデマンド型 「フルデマンド型」は営業エリア内の道路上の任意の点を発着する予約を受け付けるもので，例えば道路沿いにある個人宅を出発地に指定することができる．Door-to-Door
輸送という面では最も優れていると言えるが，大量の予約を処理する場合には計算量の多さや，1 停車でピックアップする人
数の少なさにおいて不利である．
セミデマンド型 「セミデマンド型」は営業エリア内で，かつ運営者が指定する乗降地点を発着する予約を受け付けるものである．乗降地点の指定例としては各交差点という細かいものから，指定の公共施設といった粗いものまで，様々な粒度があり得る．きめ細かな Door-to-Door 輸送という面ではフルデマン
ド型に劣るが，乗降地点のバリエーションが減ることで計算量の削減や，1 停車でピックアップする人数の増加が見込める．
イギリス・リンカンシャー州の DRT サービス”CallConnect（C）OpenStreetMap contributors

では，州全体という広範囲に 1000 点以上の乗降地点を置き，

図 2 京都市西京区・南区の桂地域

DRT 運行支援ソフトウェアを用いて 33 台のバスを運用している [8]．これはセミデマンド型デマンドバスの実運用例の一つである．
寄り道型 「寄り道型」はあらかじめ過去のデマンドデータな
どから大まかなルートを決めておき，予約に応じてその周辺からルートを選択するものである．例えば「車両基地 A から道路

a 周辺を経由し鉄道駅 B まで運行する」というようにルートの概要を決めておき，予約を受け付けてから具体的なルートの決定に入るものである．本研究では，予約の際に指定できる希望
乗降地点はセミデマンド型のように，運営者が絞り込めるものとする．寄り道型はセミデマンド型よりもさらに制約が大きく，
これら 3 タイプの中では最も柔軟性が小さい．よって過去のデ
マンドデータから予測できなかった，特異な予約への対応力は

3. 3 予約受付タイミング
リアルタイム式

走行中のバス車両にも受理した予約を随時割り当てていくタイプを指す．走行中に新たに予約を割り当てられた車両は，予定していたダイヤをその分変更してその予約に対応するため，ダイヤは動的なものになる．
バッチ処理式

各バス車両への予約割当てはすべて当該車両の走行開始前に行うタイプを指す．各車両のダイヤは割り当てられた予約をできるだけ多く受理できるように構築される．走行中の車両に対する予約割当ては行われないため，ダイヤは走行開始後には変更されない．

3. 4 運 行 規 模

他と比べて低い．しかし事前にある程度ルート，ひいては走行

デマンドバスの性質は営業エリアの広さや処理する予約量と距離や所要時間が把握できるため，車両や乗務員の運用計画をいった運行規模によって異なってくる．営業エリアの広さや使立てやすいといったメリットがある．また既存の路線バスの路用するマップの細かさはルート計算の探索空間の大きさに言い

線図のように，ユーザにもあらかじめ大まかなルートや所要時換えられ，予約量が多いと各予約の車両への割当て方法が重要間を知らせられる．後述の「定期利用登録」の仕組みを取り入になる．

れるためにも，本研究では寄り道型を採用している．

3. 2 時刻表の柔軟性
次にダイヤのうち，時刻表部分の柔軟性について述べる．
非固定型

事前の時刻表設定がまったく無いタイプを指す．バスがいつ走るかは予約に完全に依存する．

本研究で設計するデマンドバスは，寄り道型／基準点固定型／バッチ処理式／一地域内での大規模運行とする．

4 既存の発着点固定型設計の路線例
固定路線バスで発着点固定型設計の路線網を運用している地

本数固定型 各時間帯において何本程度運行するかが事前に決域として京都市西京区・南区の桂地域（JR 京都線以西）を挙められているタイプを指す．例えば朝の通勤通学時間帯には 1

げ，その問題点を考察する．

時間に 5 台，昼間時間帯は 1 時間に 3 台のバスを車両基地から

桂は JR 京都線・阪急京都線が通り，京都市中心部・大阪梅出発させるといったものが当てはまる．

田方面へのアクセスが良好な京都市西部のベッドタウンである．

基準点固定型 ある点において運行時刻が事前に決められてい一部は「洛西ニュータウン」として 1970 年に開発され，ニューるタイプを指す．例えば車両基地を出発する時刻が決められてタウン地区の人口は平成 27 年国勢調査で 22,867 人となっているものや，通過時刻のチェックポイントとなる経由地が定めいる．[9] 鉄道駅は JR の桂川駅，阪急の桂駅・洛西口駅が存在られているものなどが当てはまる．同じ通過時刻を用いる車両

し，このうち最も乗降数・鉄道定期利用数が多いのは桂駅であを複数台運行させない限り，本数固定型と同じく本数は固定さる．[10] つまり，桂駅を主要なデマンド集積点とするスター型

れる．本研究では本数固定型を採用する．

デマンド分布を持つ地域と考えられる．また域内には京都市バスのバス路線網が存在し，洛西バスターミナルを起点に各駅へ

の路線が設定されている．[11] 特に域内最大の駅である桂駅へ

dl = (vlo , tol , vld , tdl )の便が多数を占め，系統数も多い．洛西バスターミナルから桂

vlo

∈ V

(2)

vld

∈ V

(3)

tol < tdl

(4)

駅西口・東口に向かう系統は，環状路線の右回り・左回りや時間帯で切り替わる系統を区別すると全部で 8 系統存在する．平
日の便数は 5 時 ∼23 時の間で 1 時間に平均 12.5 本，最少は 5時台・23 時台の 1 本，最多は 7 時台の 24 本である．ただしこ
れは起点である洛西バスターミナルから見た場合であり，各系
統の本数は最多で西 2 号系統 6 時台・7 時台の 8 本，他は概ねラッシュ帯で 2∼5 本，データイムで 1∼5 本程度である．[12]このように，洛西バスターミナル〜桂駅間の便数はかなり多い．しかしその便数の多さは輸送密度の高さではなく，経由地を増やすための系統の多さに由来すると言える．洛西バスター
ミナルを発着する系統はすべて赤字であり，中には営業係数が200 を超えているものもある．また，洛西バスターミナル〜洛(1)とし，過去のデマンドデータ集合 D を作成する．vlo , vld はそ
れぞれ乗車／降車交差点，tol , tdl はそれぞれ乗車／降車時刻を表す．

5. 1. 3 定期利用データ
通勤通学などで平日など決まった曜日の同じ時間帯に，同じ
乗車・降車交差点を行き来するユーザの利用データを「定期利用データ」として基本ダイヤ作成に用いる．1 ユーザ分の定期
利用データ ck を次のように定める．

西口駅・桂川駅の系統や，洛西ニュータウン内の洛西バスター
ミナルよりやや北にある，桂坂ニュータウン内の桂坂中央〜桂

ck = (Vko , tok , Vkd , tdk )駅の系統も存在するが，それらも同様に赤字である．[13]Vko

このケースにも「スター型デマンド分布に対し，全体の便数が過剰になる傾向がある」という発着点固定型設計の弱点が現れている．地域全体にバス路線を行き渡らせるためには，固定

(5)

⊆ V

(6)

Vkd ⊆ V(7)

tdk − tok >min(distance(Vko , Vkd ))バス路線の場合，系統数を増やさなければならない．この状況

AverageSpeed(8)に対し，動的にルートを設定できるデマンドバスを用いて系統

Vko は定期利用登録データ ck の乗車可能交差点集合，Vkd は数を減らしつつ，利便性も確保することが本研究の目標である．

降車可能交差点集合を表す．ユーザは定期利用申請をする際，乗車／降車可能な交差点を複数選択することができる．システ

5 基本ダイヤ構築アルゴリズム
本論文ではデマンドバス運行に必要なアルゴリズムのうち，運行開始前に定めておく「基本ダイヤ」を構築するアルゴリズ
ムの一部を提案する．
基本ダイヤは予約開始以前に決定しておく大まかなダイヤを指す．本研究では過去のデマンドデータと定期利用登録データを用いて各運行に対する基本ダイヤ bi を作成し，その集合を基
本ダイヤ集合 B とする．

5. 1 使用データ
5. 1. 1 マップデータ
本研究では乗降地点を交差点に限定する「セミデマンド型」を採用する．マップデータ G は交差点集合 V と，距離を重みとして持つ道路集合 E を用いた重み付きグラフ G = (V, E) でムは基本ダイヤを作成する過程で，その中から最も都合のいい交差点を選択する．また，tok は希望乗車時刻，tdk は希望降車時刻を表す．tok , tdk に対する制約として，希望乗車時間 tdk − tok が実現可能的な範囲に収まっていることが挙げられる．基準として，乗車可能交差点集合 Vko と降車可能交差点集合 Vkd の間でもっともマップ上の最短距離が短くなる vi , vj を選択し，その間の移動にかかる所要時間を見積もって tdk − tok がそれ以上になっていることを条件とした．この条件を満たしていないものについては，ユーザによる定期利用申請の段階で不受理とする．
この定期利用データ ck を収集し，定期利用データ集合 C を作成する．

5. 2 基本ダイヤ作成
運行 i に対する基本ダイヤ bi は次のように定められる．

ある．各交差点 v ∈ V は緯度・経度情報 v lat , v lon を持つ．
また，地域の事情や想定する状況を鑑みた上で，車両基地とみなす交差点 vbase ∈ V ，デマンド集積点とみなす交差点

vaccum ∈ V を設定しておく．
5. 1. 2 過去のデマンドデータ

bi = (direction, tbase, taccum, Vi , Ti , Ci )ii′ outward′ (往路運行の場合)
direction =′ return′(復路運行の場合)

(9)
(10)

これまでの移動需要を基本ダイヤに反映させるため，1 日分

Vi ⊆ V(11)の過去のデマンドデータを用意する．過去にあった 1 トリップ

Ci ⊆ C(12)を表すデマンドデータ dl はdirection は運行の方向を表す．本研究では車両基地とデマン
ド集積点の間を行き来する「発着点固定型設計」のダイヤを想定しているため，各運行は車両基地からデマンド集積点へ向かう「往路運行」と，デマンド集積点から車両基地へ向かう「復の集合合の到着時刻 taccumを見積もる（図 4）．この taccumll

T accum を |B|のクラスタに分割する．すなわち，往路デマン
2

車両基地vbase

本のバスに割り当てるということである．
ドデータ集合を |B|
2
その際，車両の定員を考えてクラスタサイズの上限を設定する．
往路運行 i のデマンド集積点到着時刻 taccum
を，クラスタ i のi
見積もり到着時刻集合 Tiaccum の平均に設定する．

復路

詳細なクラスタリング手法については検討中である．
往路

v ol

t ol

乗車交差点
dl
t dl

デマンド集積点vaccum

降車交差点

v dl

図 3 過去デマンドデータの往路／復路分類

路運行」に分けられる．

tbase, taccumはそれぞれ車両基地，デマンド集積点を発着す
ii
る時刻を表す．例えば direction =′ outward′ の場合は時刻
taccumltbaseに車両基地を出発し，時刻 taccumにデマンド集積点に到
i
i
着する．

vaccumデマンド集積点

Vi , Ti はそれぞれ経由交差点とその経由時刻の順序付き集合
図 4 デマンド集積点到着時刻の見積もりである．Ci は運行 i が輸送を担当する定期利用データの集合で
ある．
復路運行

5. 2. 1 1 日に運行するバスの便数の決定
過去のデマンドデータ集合 D の要素数を 1 日の見積もり輸送人

まず，往路運行と同じように，復路運行で輸送すると考えられるデマンドデータ集合 Dreturn を作成する．そして数とし，1 運行での望ましい輸送人数 P assengerP erOperation

その各要素 dl に対し，そのユーザが起点であるデマンド集積を与えて次のように求める．

点 vaccum から乗車した場合の出発時刻 taccumを見積もる．こlの集合 T accum をクラスタリングし，復路運行 i のデマンド集

|D|
|B| =
P assengerP erOperation

積点出発時刻 taccumを設定する．
i(13)

5. 2. 3 同じ運行に割り当てる定期利用データ集合の作成
収集した定期利用データをクラスタリングし，同じ運行に割

往路と復路の運行数はそれぞれ |B|とする．
2

り当てる定期利用データ集合 C[i] の集合を作成する．本項では

5. 2. 2 各基本ダイヤの運行時間帯の決定

往路運行分について説明するが，復路運行でも運行方向が逆で往路では多くの場合，デマンド集積点はユーザの最終目的地あること以外は同じように行える．

や鉄道などへの乗り継ぎ地点であると考えられ，ダイヤを決定

基本ダイヤ bi に割り当てられる定期利用データ集合 Ci の選する上での基準はデマンド集積点への到着時刻とすべきである．

び方には，時間的な制約が存在する．運行 i では各 ck ∈ Ci の

逆に復路でのデマンド集積点はユーザの出発地や鉄道などから乗車／降車可能交差点集合 Vko , Vkd から実際に停車する交差点の乗り継ぎ地点と考えられるため，ダイヤを決定する上での基を選び，その交差点に希望乗車／降車時刻 tok , tdk に到着しなけ

準は「デマンド集積点からの出発時刻」とすべきである．そのればならない．そのため，Ci に含まれる乗車／降車可能交差点

ため，往路／復路のいずれであるかを鑑みながら，まず運行 i

集合と希望乗車／降車時刻の組の集合 Si を時刻順に並び替えに対してデマンド集積点での発着時刻 taccumを設定する．
i

た時，次の式が成り立つことが必要になる．

往路運行 まず，過去のデマンドデータ集合 D から往路運行
で輸送すると考えられるデマンドデータ集合 Doutward ⊆ D を作成する．往路運行の方向ベクトル，つまり車両基地 vbase かSi = {(Si[0] , ti[0] ), (Si[1] , ti[1] ), ...}

(14)

らデマンド集積点 vaccum への方向ベクトルと，デマンドデー

min(distance(Si[a] , Si[a+1] ))ti[a+1] − ti[a] >AverageSpeed(15)

タ d の方向ベクトル，つまりデマンドの乗車交差点 v o から降車交差点 v d への方向ベクトルを求める．この 2 本のベクトル

まず，前項の過去デマンドデータの取り扱いと同じく，定期のなす角が 90◦ より小さくなるデマンドデータを往路運行で輸利用データ集合 C も往路運行で輸送する集合 C outward と復路送するものと考える（図 3）．

運行で輸送する集合 C return に分割する．ただし過去デマンド

往路デマンドデータ集合 Doutward の各要素 dl に対して，そデータ dl と違い，定期利用データ ck は乗車／降車交差点は 1のユーザが終点であるデマンド集積点 vaccum まで乗車した場

つに定まっていない．そのため，乗車可能交差点集合 Vko と降車可能交差点集合 Vkd それぞれについて座標の平均を求め，そ（C）OpenStreetMap contributors

れを用いて定期利用データの方向ベクトルを求め，集合の分割を行う．
この場合，往路運行に割り当てられる定期利用データ集合はC

outwardである．この集合に対し制約付きクラスタリングを行い，同じ運行に割り当てる定期利用データ C[i] の集合を求める．上記の制約に加え，クラスタ数は |B|
を超えてはならない．
2
また，前項で基本ダイヤ bi に対し設定したデマンド集積点到
着時刻 taccumから基本ダイヤ bi の運行時間帯が推測できるが，i
ある時間帯の運行数をクラスタ数が上回った場合，割当ては不可能になる．この場合，その時間帯において他の定期利用デー
タから座標的に外れた乗車／降車可能交差点集合 Vko , Vkd を持
つ定期利用データ ck を申請不受理として除外し，クラスタリ
ングをやり直すことが考えられる．定期利用データが不受理と

図 5 作成した道路グラフ

なった場合，そのことは申請したユーザに通知される．
詳細なクラスタリング手法については検討中である．

5. 2. 4 定期利用データの各運行への割当て

6. 1. 2 過去のデマンドデータ
京都市内を対象とした乗換検索サービス「歩くまち京都」の前項で作成した各定期利用データ集合 C[i] をどの運行に割り

検索クエリのログ（2016 年 7 月 1 日 ∼2016 年 12 月 31 日）を当てるかを決定する．これにより基本ダイヤ bi の順序付き経由

加工し，1 日分の推定デマンドデータを作成した．その際，京交差点集合 Vi ，順序付き経由時刻集合 Ti ，輸送を担当する定都市交通局が公表している各バス停留所の 1 日の乗降客数 [14]期利用データ集合 Ci が定まる．

と，検索ログから作成した各停留所の時間帯別のデマンド数ヒ

基本ダイヤ bi の運行時間帯は 5. 2. 2 項で定められているたストグラムからデマンドの母数と分布を推定した．

め，基本ダイヤ bi とそれに割り当てられる定期利用データ集合

本研究では現在使われている停留所ではなく交差点を停留所

Ci の時間帯の差の総和が最小となるように割当てを行う．割当としているため，デマンドの乗車／降車交差点は検索クエリロて後，基本ダイヤ bi の車両基地発着時刻 tbase，デマンド集積i

グの停留所の周囲からランダムに選択した．出発時刻は時間帯

点発着時刻 taccum
を，割り当てられた定期利用データ集合 Ci
i

別ヒストグラムによる分布から各時間帯の利用客数を推定し，に合わせて変更する．

各時間帯においてランダムに生成した．生成されたデマンド
データは 14812 件である．

5. 3 評 価 関 数

過去のデマンドデータを 5. 2. 2 項で挙げた手法で往路デマン

評価値の算出には過去のデマンドデータを用いる．作成された基本ダイヤによって，過去にあったその地域での移動をどの程度カバーすることができているかを評価基準とする．これにより，作成された基本ダイヤが非定期利用分にも対応できているかを測る．

6 実

ド／復路デマンドに分類し，それぞれデマンド集積点への見積
もり到着時刻／デマンド集積点からの見積もり出発時刻を求めた．その結果を図 6, 7 に示す．

6. 1. 3 定期利用データ
定期利用データも「歩くまち京都」の検索クエリログから作成している．定期利用数の推定方法として，停留所ごとに検索

験

数と統計資料の乗降数の比を取り，実際の乗降数に比べて検索利用可能なデータの確認を行い，入力となるデータの作成を行った．対象地域は 4 章で挙げた京都市の桂地域とした．

数が少ない停留所を「定期的な利用が多い停留所」とみなした．
乗換検索を行ったということはそのユーザが時刻表や系統を把握していない可能性が高く，逆に乗換検索を行わなずにバスを

6. 1 使用データ利用したということは検索をせずともバスを利用できるほど慣

6. 1. 1 マップデータ
データは Open Street Map の緯度 34.9455◦ ∼ 34.9944◦ ，経◦◦れたユーザである可能性が高いと考えたためである．
停留所ごとの検索数と統計資料の乗降数の比から乗車停留所

度 135.656 ∼ 135.7206 の範囲から作成した．その際，生活／降車停留所／時間帯ごとの定期利用データ数を決め，過去の道路などバス車両の走行には向かない属性の道路は削除した．

デマンドデータから定期利用とみなすものを抽出した．それをまたグラフが連結，かつ次数 1 以下の頂点が存在しないように

元に乗車／降車可能交差点を決定し，定期利用データとした．

適宜頂点・辺を削除した．頂点数は 1077，辺数は 1543 である．

実験時に生成する定期利用データの適切な件数については検討作成されたグラフが図 5 である．なお車両基地 vbase は洛西バが必要である．

スターミナル付近，デマンド集積点 vaccum は桂駅の西口付近の交差点と定めた．

1200
往路の降車時刻
往路のデマンド集積点到着時刻（見積もり）

デマンド数

900

600

300

0

0 1

2 3

4 5

6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23時間

図 6 往路デマンドの到着時刻別ヒストグラム
1200
復路の乗車時刻
復路のデマンド集積点出発時刻（見積もり）

デマンド数

900

600

300

0

0 1 2

3 4 5 6 7

8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23時間

図 7 復路デマンドの出発時刻別ヒストグラム

7 今後の課題
5. 2. 2 項と 5. 2. 3 項でそれぞれ過去のデマンドデータ集合 Dと定期利用データ集合 C のクラスタリングについて検討しているが，これらについて手法を決定し基本ダイヤ集合 B の作成を行うことが目標である．特に 5. 2. 3 項の定期利用データ集
合 C のクラスタリングについてはクラスタ数不定の制約付き
クラスタリングとなり，複雑になることが予想されるため，既存手法の調査から綿密に行いたい．

8 謝

辞

本研究は JSPS 科研費基盤研究 (S) No. 17H06099, (A) No.

18H04093, (C) No. 18K11314 の助成を受けたものです．

文

献[1] 野田五十樹, 篠田孝祐, 太田正幸, and 中島秀之. シミュレー
ションによるデマンドバス利便性の評価. 情報処理学会論文誌,
49(1):242–252, 2008.
[2] 坪内孝太, 大和裕幸, and 稗方和夫. 過疎地における時間指定のできるオンデマンドバスシステムの効果. 日本ロボット学会誌,
27(1):115–121, 2009.
[3] Marcus Enoch, Stephen Potter, Graham Parkhurst, andMark Smith. Intermode: innovations in demand responsive transport: final report. Social Research in Transport(SORT) Clearinghouse, 12 2018.
[4] 順風路株式会社. オンデマンド交通事業-オンデマンド交通事業｜順風路. http://www.jpz.co.jp/odb/index.html, 2018.
[5] 上原和樹, 赤嶺有平, 當間愛晃, 根路銘もえ子, and 遠藤聡志. デマンドバスと大型車両による協調型交通システムの提案. 情報処

理学会論文誌, 56(1):46–56, 2015.
[6] 上杉健太郎, 渡邉豊英, and 向直人. K-means 法を用いた寄り
道型デマンドバスの並列運行手法, March 2008.
[7] 坪内孝太 and 大和裕幸. オンデマンドバスシステムの開発と地域への導入設計の研究, December 2009.
[8] Lincolnshire County Council.
Callconnect — lincolnshire county council. https://www.lincolnshire.gov.uk/
callconnect/35955.article, 2018.
[9] 洛西ニュータウンアクションプログラム検討会. 洛西ニュータウン
アクションプログラム. https://www2.city.kyoto.lg.jp/shikai/
img/iinkai/machi/H28/data/290209machi-04.pdf, 2017.
[10] 京 都 府 政 策 企 画 部 企 画 統 計 課. 平 成 28 年 京 都 府 統 計 書
10-1. 鉄道乗車人員. http://www.pref.kyoto.jp/tokei/yearly/
tokeisyo/ts2016/tokeisyo2016a1001.xlsx, 2018.
[11] 京 都 市 交 通 局.
京 都 市 交 通 局：市 バ ス 路 線 図.
http://www.city.kyoto.lg.jp/kotsu/page/0000019770.html, 2018.
[12] 京 都 市 交 通 局. 京 都 市 バ ス 時 刻 表：洛 西 バ ス タ ー ミ ナ
ル. https://www2.city.kyoto.lg.jp/kotsu/busdia/hyperdia/
menu801.htm, 2018.
[13] 京都市交通局. 市バス各系統の営業係数（平成 29 年度）について. http://www.city.kyoto.lg.jp/kotsu/cmsfiles/contents/
0000242/242554/kouhousiryou.pdf, 2018.
[14] 京 都 市 交 通 局.
平 成 29 年 度 版 京 都 市 交 通 事 業 白書（事業概要）. http://www.city.kyoto.lg.jp/kotsu/page/0000073257.html, 2018.