オンデマンドバスサービス導入前の シミュレーションロジックの構築 トヨタコネクティッド株式会社 先行企画部 新技術開発室 中島 朋哉

自己紹介 TC先行企画部での経歴 2023/12にトヨタコネクティッドの先行企画部にジョインし、最初は生成AI関連の案件に携わる。 現在は、データサイエンティスト見習いとして、データサイエンス案件に従事している。 趣味/最近のこと • サウナに2回/週で通う。週末には高速で、西へ東へ、サウナ巡りをしている。 • signateというコンペを開催している媒体の、国土交通省開催のデータ分析コンペに、チームを 組んで参加中。 signate：第1回 国土交通省 地理空間情報データチャレンジ ～国土数値情報編～

目次 概略 オンデマンドバス事業は、収益化が難しく、補助金などの受 給期間が終了するとすぐにサービスが立ち行かなくなってし まうケースも多い。 これは、事前にデータ分析を活用した予測が不十分であるた めに起きてしまうと考えられている。 そのため今回は、サービス導入前に事前検証ができるような シミュレーションロジックを構築した。 1. 背景や現状 2. 課題 3. ステーション配置 3-1. ODデータの多いメッシュを抽出する 3-2. メッシュ内の複数のPOIデータの中点をとる 3-3. 制約条件を基にステーションを調整し、最終決定する 4. シミュレーション構築 4-1. 予約データの作成 4-2. 入力パタメータの設定 4-3.評価指標の算出のため活用したツール 4-4. シミュレーション結果の表示 4-5. 評価結果の比較を可視化 4-6. 今後の改修について

1. 背景や現状 MONET社HP 従来のような固定ルートではなく、 利用者の需要（デマンド）に応じた経路で運行 されるバス 国土交通省：新モビリティサービス推進事業に関わる公募について 新モビリティサービスの推進に向けて、公共交通政策の中で公募を募り、初期導入をサポートしている 国土交通省：新モビリティサービスの推進 技術的進歩、環境意識、ライフスタイルの変化などによって、MaaSサービスや新モビリティサービスが推進 されている。

2. 課題 • オンデマンド交通では客単価が低い 例1：固定料金(地域によって異なる)300円, 210円など（参照元：大阪メトロ社の事例） 例2：固定料金で200円、１日乗り放題券など（参照元：愛知県春日井市の事例） • 利用者数が少なく、どういう形の運用が最適なのかわからない オンデマンドバス事業は、国や自治体からの補助金や助成金に大きく依存している場合が多い。 そのため、事業が独立して黒字化することが難しく、補助金の受給期間が終了後、サービスが立ち行かなく なってしまう…。 理由：収支予測や配車シミュレーションなど、データ分析を活用した予測が甘いため …と、考えられる オンデマンドバスに着目し、サービス導入前の事前検証ができるシミュレーション構築を検討した 参考資料：国土交通省HP公開資料 まだまだ、頭を悩ませる問題もある。

3. ステーション配置 オンデマンドバスサービスにおけるステーションは、バーチャルステーションと言われており、既存の目立つ建 物などをバス停の代わりとして使用するものである。 今回利用した、公共施設やショッピングセンターなどのPOI(Point of Interest)データ一覧 プラウザ利用ver：Overture Maps Overture Maps 世界中のPOIデータを幅広く網羅し、プラウザ やローカルで利用ができるオープンソース

3-1. ODデータの多いメッシュを抽出する 今回は、愛知県一宮市を舞台にして、シミュレーションロジックを構築していった。（参考：愛知県一宮市HP） エリア特徴 • 愛知県北西部にある中核市 • 人口は約38万人（2024/11/1現在）で約60位/1,741市区町村（2024/10/1現在） • 「繊維の街」であり、ウールの世界三大産地(イギリスのハダースフィールド、イ タリアのビエラ)である尾州の中心地 • 繊維産業、製造業、サービス業、など多様な産業を保有 • 名古屋へのアクセスも容易（JR一宮駅ーJR名古屋駅 12分） 移動の出発地点と到着地点のデータ（ODデータ）より、一宮市内のメッシュ単位での人の流れ（人流）を可視化した。 O地点とD地点を線で結んだ図 メッシュごとにODデータ数をカウントし、 数が多い順に、赤・黄・緑・青の色分けをし た。 ヒートマッピング図 参考：国土数値情報に定義されている土地メッシュ

3-2. メッシュ内の複数のPOIデータの中点をとる 続いて、まずは、ODデータ数の多いメッシュ（赤のメッシュ）内にある全てのPOIデータを抽出した。 上記では、同じメッシュ内に複数のPOIデータが含まれているため、それらの中点を取ることで、 メッシュ内に1つのポイントがあるようにした。

3-3. 制約条件を基にステーションを調整し、最終決定する さらに、例えば以下のような要望・制約条件にも対応できる形でステーション配置アルゴリズムを決定していった。 • 0.4km以内には1つのステーションとしたい • 名鉄線の玉ノ井駅はオンデマンドバスのステーションとしたい 等 今回は、上記の2点を制約条件として踏まえた上で、条件を全て満たしたポイントを、オンデマンドバスのバーチャ ルステーションとして決定した。 ※実際には、各ポイントを細かく手動で微調整（例えば、 建物入り口付近に置く、道路の左側に全て置く、等）のうえ、 ステーションを正確に決定していく必要がありそうです。 こうして決定したステーション配置を基に、サービス導入事前検証のシミュレーションを構築していった

4. ステーション構築 ここでは、前章で決めたステーション配置を使い、実際に運用した場合、例えば、運行台数を何台にした ら、何人の利用者がいて、何円の収益が上がるのか、等を事前検証できるためのシミュレーションを構築 していった。 再掲 前章で決定した一宮市内のステーション配置 ステーション配置 (3章) 予約データ (4-1) 入力パラメータ (4-2) Route Optimization API Distance Matrix API (4-3) 評価指標 算出 (今回割愛) シミュレーション結果 の表示と比較(4-4,4-5) シミュレーション構築の流れ

4-2. 入力パタメータの設定 今回は以下のような入力パラメータを設定してみた。 ※値は仮置き ここで入力した各数値を変更した場合、サービス運用結果はどうなるのか、の事前検証ができるというイメージ です。 まずは、ODデータを元にして、以下の表のような仮の予約データを作成した。 4-1. 予約データの作成

4-3. 評価指標の算出のため活用したツール ここまでの「ステーション配置」、「予約データ」、「入力パラメータ」を使い、今回は以下のツールを活用す ることで、シミュレーション結果として出力する評価指標の算出アルゴリズムを検討した。 • Route Optimization API（参考：Google Documentation） • Distance Matrix API （参考：Google Documentation） 複数台の車両を扱って配送ルートを決定してもらい、 利用者ごとの乗車時間、複数人が相乗りしている時間、車両の走行 距離、等の数値を返してもらう。 相乗りなどが発生した場合に、もし仮に利用者が直接、出発地点から 到着地点まで移動したときの移動距離や所要時間を回答してもらう。

4-4. シミュレーション結果の表示 上記までで構築したシミュレーションを実際に回して、結果を出力した。 ※ここでは、利用時間を1日3時間で2日分、予約希望数を合計で25件としている。 利用者満足度は、以下の表のスコア要素を持っているものであり、各要素から算出される値である。 また、利用者ごとの詳細な情報も表示できるようになっている。

補足4-4 出力されてくるシミュレーション結果一覧 ステーション配置 入力パラメーター 利用者満足度 利用者データ シミュレーション結果

4-5. 評価結果の比較を可視化① 入力パラメータ（やステーション配置）を変更してシミュレーションを回した時の結果を比較できるようにした。 利用時間：3時間×2日、利用料金：200円 車両台数ごとの予約データ数と最終収益の推移 車両台数ごとの予約データ数と予約成功率および 総利用者数の推移

4-5. 評価結果の比較を可視化② 入力パラメータ（やステーション配置）を変更してシミュレーションを回した時の結果を比較できるようにした。 利用料金：200円 予約データ数：10:00-13:00では118件 or 9:00-18:00では324件 車両台数ごとの利用可能時間と最終収益の推移 利用料金：500円 予約データ数：10:00-13:00では118件 or 9:00-18:00では324件

4-6. 今後の改修について 改修候補検討事項 • 結果の比較がより直感的にわかるように可視化したり、そこからさらに分析して示唆に繋げて いくことで、事前検証の精度や洞察がより良くなるようにしたい • 利用者属性によって、利用者満足度の算出アルゴリズムを変えて算出できるようしていきたい • 現在の入力パラメータに加えて、支援金や広告費も取り入れ、より実際に沿った評価指標の算 出をしたい 今回、シミュレーションの枠組み、シミュレーションロジック、を構築した 今後は、各種評価指標の考え方や要素、算出アルゴリズムなど、事業者様とも一緒になって、 サービスごとに特化したシミュレーションができるよう進化させていく

おわりに 今回のLTでは、シミュレーションのプレーンみたいなものを構築した、というお話をさせていただい たかと思うのですが、先ほども少し触れましたように、実際のサービスをやられているような企業さ んとも一緒になって、それぞれのサービスに適した形になるように進めて行ければ嬉しいなって考 えています。 ですので、もし、このLTの中のどれかしらにご興味持たれた方いらっしゃいましたら、この後の交流 会にて、少しだけでも意見交流などさせていただけたらなと思ってます。

No content

補足資料

MaaSとは、異なる交通手段を一つのサービスとして統合して提供する概念を指す。 MaaSの現在地(MaaS1.0)と将来像(MaaS2.0)が構想されてる。 現在は個々の事業者がそれぞれに試行錯誤している(MaaS1.0)ため、サービスレベ ルが低いままであり、業界そのものが人の生活の中に標準化していない。 そういった中で、MaaS事業の概念の転換をしようとしているとのこと。

MaaSやシェアカーが広まった背景には、さまざまな社会的、経済的、技術的要因が絡み合っている。 以下に主な背景要因を列挙する。 1. 都市化の進展 人口集中、インフラの制約 2. 技術の進歩 デジタル化とモバイル技術、ビッグデータとAI 3. 環境意識の高まり 持続可能な交通、電動車両の普及 4. 経済的要因 コスト削減、新しいビジネスモデル 5. ライフスタイルの変化 シェアリングエコノミーの台頭、働き方の多様化 6. 政策・規制の後押し 政府の支援、交通インフラの整備 7. パンデミックの影響 COVID-19の影響