移動をまとめて提供するサービス（MaaS）は続く？主要8事例と事業機会

移動をまとめて提供するサービス（MaaS）とは、複数の移動手段をつなぐ考え方

MaaSは、複数の移動手段を組み合わせ、検索・予約・決済を一つの移動体験として提供する考え方です。「Mobility as a Service」の略で、鉄道、バス、タクシー、シェアサイクル、オンデマンド交通などをつなぎます。

国土交通省は、移動サービスだけでなく、観光や医療といった目的地のサービスとの連携もMaaSに含めています。つまり、便利な経路検索アプリを作ることが最終目的ではありません。

病院へ通える、観光地を回れる、買い物へ行けるといった生活の結果まで設計する考え方です。

MaaSには、三つのものが必要です。

1. 鉄道、バス、タクシーなど実際に人を運ぶ「交通の供給」
2. 検索、予約、決済、運行管理をつなぐ「デジタルの仕組み」
3. 自治体、交通事業者、病院、商業施設などが役割を分ける「地域の運営」

三つがかみ合わなければ、目的の移動を成立させにくくなります。アプリが使いやすくても、乗る車両が来なければ価値はありません。

車両があっても、予約方法が難しければ高齢者に届きません。実証が成功しても、翌年度の運行費を誰が負担するか決まらなければ続きません。

日本で地域MaaSが必要とされる理由

日本の地域交通では、利用者の減少と運転手不足が同時に進んでいます。便数を減らせば、さらに使いにくくなります。

一方で、病院、学校、買い物へ移動できない人を放置することもできません。

定時定路線の交通を、予約に応じて運行する交通などで補う取り組みが進んでいます。国土交通省の支援一覧では、2025年度は当初選定の29件から、現行掲載では36事業となっています。

2026年度は「観光MaaS推進事業」として9事業が掲載されています。制度や対象が異なるため、この件数の増減を市場の成長率や成功率とは扱いません。

ただし、需要が少ない地域で配車を最適化しても、運賃収入だけで費用を回収できるとは限りません。地域MaaSでは、誰を運ぶかと同じくらい、移動によって誰の費用が減り、誰の売上が増えるかを考える必要があります。

例えば、通院の移動手段を確保すると予約日の受診が増えるのか、観光客の移動支援で来店や消費が増えるのかを測ります。これらは期待する効果であり、交通を導入しただけで実現するものではありません。

誰にどれだけ便益があり、費用負担に合意するかを確認します。

自動運転バスやライドシェアは、地域交通を支える供給手段

MaaS、自動運転、ライドシェアは同じ意味ではありません。MaaSは移動全体をつなぐ仕組みです。

自動運転バスやライドシェアは、その中で人を運ぶ手段です。

自動運転を入れても、乗り場、ダイヤ、遠隔監視、事故時の対応、保守が必要です。自動運転の記事で解説した通り、車両が自動で走れることと、地域交通として安定運行できることは別です。

ライドシェアも、空いている車両と運転者を供給へ加える方法です。ただし、日本版ライドシェアは運行主体、地域、時間帯などに制度上の条件があります。

利用者が「MaaS」で知りたい全体設計と、「ライドシェア」で知りたい制度や利用方法は異なるため、本記事では制度の詳細へ踏み込みません。

需要が多い区間の幹線と、駅や病院へつなぐ交通を組み合わせます。オンデマンドは需要が散るだけで最適と決まらず、待ち時間や迂回も評価します。

自動運転も経路が限定されているだけでは導入できず、走行条件と運行体制の確認が必要です。

MaaSの政策・技術動向は、地域交通DXとデータ連携で見る

国の地域交通DXは、アプリだけでなく、データ・運営・現場業務を一緒に改善する方針です。市場全体が既に移行したという意味ではなく、導入計画を考える際の政策の方向として読みます。

国土交通省のMaaS2.0は、地域交通のデジタル化を「サービス」「データ」「マネジメント」「ビジネスプロセス」の四つから進めます。検索や決済だけでなく、運行計画、事業者間のデータ連携、現場業務まで変える方針です。

2025年度には、MONETがデマンドバスシステムの標準化に参加しました。その後、国土交通省は連携APIの標準仕様書と標準業務モデル、技術検証レポートを公開しています。

仕様の策定と、各地域の既存システムで実際に接続・運用できることは別に確認します。

市場規模の予測には注意が必要です。調査会社によって、配車、公共交通、決済、自動運転、観光まで含める範囲が違うからです。

新規事業では、大きな世界市場の数字より、対象地域の移動回数、車両数、運行費、関係施設の便益から積み上げる方が現実的です。

MaaSの業界構造は、車両から地域運営までの5層で見る

MaaSの役割は、車両、自動運転・配車、運行管理、利用者接点・データ、地域運営に分けて考えます。以下は主な役割を5層に整理したもので、1社が複数の層を担う場合もあります。

自社が担当する仕事と、運行主体や提携先へ残す仕事を分け、必要な体制・費用を確認します。

車両やアプリだけでは事業は完結しません。3層の運行では、日々の遅延、乗客対応、車両故障、遠隔監視が発生します。

5層の地域運営では、バス会社、タクシー会社、自治体、住民、病院などの利害を調整します。

運行管理、病院予約との連携、効果測定には、既に製品や支援サービスが存在します。層の間を自動的に空白市場と考えず、対象地域が現在の方法で解決できない仕事と、外部へ発注する理由を確認します。

MaaSを進める主要8事例は、どこで違いを作っているか

国内の取り組みを、どの役割を担い、何を解決しているかで比較します。商用サービス、社会実装、実証を区別し、各社が公表した成果の範囲を確認します。

自社が担当する仕事と、運行主体や提携先へ残す仕事を分け、必要な体制・費用を確認します。

my routeは、移動情報から目的地の予約まで連携を広げる

2019年にトヨタと西鉄が本格実施を発表したmy routeは、交通情報と地域の店舗・イベント情報を組み合わせてきました。現行の事業主体はトヨタファイナンシャルサービスです。

2026年9月の同社発表では、交通と観光・体験・飲食等を一体で手配する新機能を11月中旬に提供する予定です。外部サイトへの移動で手配が分断される課題への対応であり、確認時点では提供後の利用・消費拡大の実績ではありません。

導入を考える際は、検索数だけでなく予約完了と実際の利用を測る設計が参考になります。

小田急は、EMotの裏側を共通基盤へ広げた

小田急電鉄は、EMotを支える共通データ基盤「MaaS Japan」について、2019年10月の開始から2025年11月までの累計取扱額が100億円を超えたと2026年1月に発表しました。100億円は基盤を通じた取扱額であり、小田急の売上や利益ではありません。

同社は、Klookとの販売連携やQR認証の導入を成長の柱と説明しています。交通・観光事業者が共通の販売・認証の仕組みを使える点が参考になります。

一方、費用削減や黒字化を判断するには、手数料収入、運用費、他社への精算を別に見る必要があります。

関西MaaS協議会は、競合する鉄道会社を広域で束ねる

KANSAI MaaSは、大阪市高速電気軌道、近鉄、京阪、南海、JR西日本、阪急、阪神を中心に運営されています。経路検索、観光情報、電子チケットを関西の広い範囲で提供します。

累計ダウンロードの拡大と、イベント後の日常利用の定着を分けて測ります。

関西MaaS協議会の2026年2月報告（9・12頁）では、万博閉会時に約160万ダウンロードへ到達しました。一方、2025年12月の月間アクティブ利用者は9月のピークの約2割で、万博前の1月に比べると6倍以上です。

ここでのアクティブ利用者は、1カ月に1回以上アプリへアクセスした人数です。

この比較は同じ人を追った継続率ではありません。

同報告14〜15頁は、アクセス集中による障害や問い合わせ増加、サーバー・窓口体制の増強も示しています。利用拡大を計画する際は、販売・認証だけでなく混雑時の対応費も見積もる必要があります。

MONETは、自治体のオンデマンド交通を導入から運行まで支える

MONETは配車・運行管理や医療・行政MaaSを扱います。国土交通省の紹介記事にある53自治体はオンデマンド交通の導入支援の規模であり、53地域すべてが採算や移動改善を達成したという数字ではありません。

豊後大野市の「コミタク」事例では、減便や運転士の高齢化に対応するため配車システムを導入し、LINEによる予約を可能にしました。提供企業は運行効率と利便性の改善を説明していますが、削減時間や費用の比較値は示していません。

予約方法の追加が、利用者と受付担当それぞれの負担をどう変えるかを現地で測る必要があります。

ANAは、支援が必要な人の移動を一括手配する

ANAのUniversal MaaSは、障がいの有無や年齢を問わず移動できることを目指します。航空、鉄道、バス、タクシー、宿泊などの支援情報をつなぎます。

ANAは68の企業・団体との連携を公表しています。これは連携先の数であり、利用者数や支援完了件数ではありません。

一般的な経路検索では、段差、乗り換え時の介助、車いす対応、空港内の移動が抜けます。Universal MaaSは、予約情報だけでなく「誰が、どこで、どの支援を引き継ぐか」をつなぎます。

他分野MaaSでは、データ連携より先に、現場の引き継ぎを設計する必要があります。

BOLDLYは、自動運転バスの運行そのものを商品にする

BOLDLYのDispatcherは、車両の位置や映像の監視、走行指示、乗客との通話、運行ログの共有を行う運行管理基盤です。複数車種を同じ画面で扱い、一人が複数台を監視する方向を示しています。

境町の事例を紹介した2023年の公式記事では、2020年11月から定時運行を始め、住民との調整で停留所や路上駐車への対応を進めたことが分かります。運行ルートと時間も需要に合わせて変更しています。

公道での定時運行という到達と、無人化による人件費削減や黒字化は同じ成果ではありません。

Dispatcherは複数車両の監視・操作を支援しますが、必要な人数は経路、走行条件、緊急時対応で変わります。「複数台に対応する機能がある」ことから、すべての地域で同じ人員削減ができるとは判断しません。

TIER IVは、オープンな自動運転基盤と地域実装を組み合わせる

TIER IVはAutowareを基盤に、車両や開発・運行向けの仕組みをパートナーと展開しています。塩尻市の2025年1月発表では、同月9日に特定自動運行の許可を取得し、駅と市役所の間でレベル4の実証運行を予定していました。

この発表では一般試乗は対象外です。許可取得、限られた実証、一般利用者への定常運行を区別します。

オープンな基盤は、車両や部品を一社へ固定しない選択肢を作ります。ただし、オープンソースを導入すれば自動的に運行できるわけではありません。

走行環境の定義、地図、車両調整、安全評価、運行責任を担う企業が必要です。

Viaは、固定路線とタクシーの間をオンデマンド交通で埋める

Viaの技術は、複数の乗客の予約をまとめ、経路や乗降場所を調整します。伊藤忠商事の2019年発表は、東京本社の社員向けに日本交通の協力で導入する計画でした。

社員の個別負担はなく、業務移動を改善する企業側が費用を担う構成が特徴です。

発表の実施期間は2019年10月〜2020年7月の予定で、時間短縮とコスト削減は目標です。この資料だけで現在の継続運行や効果実績を断定しません。

参考になるのは、利用者と支払者が異なるサービスを、業務目的で設計する点です。

重要なのはアルゴリズムの精度だけではありません。電話予約を残すか、乗降場所まで歩けるか、鉄道や幹線バスへ接続できるかで利用率が変わります。

配車システムは地域の運行条件と一緒に設計する必要があります。

MaaS事例から整理する、地域交通の四つの確認点

当研究所では、目的・交通の組み合わせ・運行責任・財源を四つの確認点に整理しました。全事例で成功との因果関係を検証した条件ではありません。

第一は、先に移動目的を決めることです。「高齢者の通院」「観光客の周遊」「駅から工業団地への通勤」のように、誰の何を変えるかを具体化します。

対象が曖昧なままでは、必要な車両も時間帯も決まりません。

第二は、幹線と支線を組み合わせることです。すべてをオンデマンドにせず、需要が多い区間は鉄道や定時バスへ集めます。

小型車は駅や病院までの短い区間に使うと、車両を効率よく回せます。

第三は、運行責任を商品設計へ入れることです。予約、乗客対応、遅延、欠便、車両故障、事故、個人情報への対応者を決めます。

アプリ開発会社が運行を担わないなら、交通事業者や運行支援会社との役割分担が必要です。

第四は、便益と費用負担の関係です。病院、商業施設、雇用企業などに便益があれば、負担に合意するかを確認します。

民間の負担者を増やすこと自体が必須ではなく、公共交通として自治体が支える場合も、必要なサービス水準と継続財源を明確にします。

実証後に導入が止まる五つの理由

MaaSの実証では、アプリを公開し、車両を走らせるところまで進みます。しかし、本番では毎日の運行と費用が問題になります。

登録数やアプリのダウンロード数だけでは、事業性を判断できません。見るべきなのは、移動が成立した回数、相乗り率、一台一時間当たりの乗客数、欠便、問い合わせ、既存交通を含む総費用です。

実証は技術を試す場であると同時に、翌年度の運営者を決める場です。終了直前に予算を探すのではなく、開始時に「誰が、どの条件なら引き継ぐか」を合意します。

地域MaaSの収益モデルは、運賃だけで考えない

地域交通全体の収支と、システム会社の収益を分けて計算します。運賃、自治体の委託費、施設・企業の負担は交通を支える財源の候補です。

システム利用料は提供会社の売上ですが、交通事業者には費用となります。両者を同じ収入として足しません。

1. 利用者が払う運賃、定期、会員料金
2. 自治体が払う公共交通、福祉、観光などの委託費
3. 病院、商業施設、ホテル、雇用企業が払う送客・送迎費
4. 配車・運行管理・データ分析の利用料は、システム提供会社側の収益として別に整理

例えば、病院向けなら受診完了や送迎担当の作業時間、観光地なら周遊や消費の変化を確認します。ただし、便益の推計額がそのままサービスの収入になるわけではありません。

料金、予算、契約期間への合意まで確かめます。

一方、広告やデータ販売を安易な収益源にしてはいけません。利用者数が少ない地域では広告価値が限られます。

移動履歴は生活や健康状態を推測できる情報でもあります。本人の理解がない二次利用は、信用を失う原因になります。

架空例：月1,000回の乗車があっても、財源が10万円足りない

通院等の乗合交通を想定した説明用の計算例です。1カ月の延べ片道乗車が1,000回、運賃200円、運行・保守・受付・保険・システム等の総費用が120万円と仮定します。

往復した人は2回に数えるため、1,000人の実人数ではありません。金額は特定地域の実績や相場ではありません。

システム会社へ払う10万円を「MaaSの収入」として再び足すと、不足が見えなくなります。事業主体は追加財源かサービスの見直しを検討し、提供会社は自社の10万円で保守原価を賄えるかを別に判断します。

便数の削減には移動できなくなる人への影響も伴うため、収支だけでなく必要な移動の確保と両立する案を比べます。

交通データの連携では、便利さと責任を一緒に設計する

交通データの連携は、データの項目・形式だけでなく、利用目的と障害時の対応もそろえて設計します。MaaSでは経路、予約、決済、乗降、位置、支援情報などを扱います。

国土交通省のデータ連携ガイドを参考に、参加者の間で項目・形式・ルールの認識を合わせます。

連携するほど便利になりますが、障害や漏えいの影響も広がります。最初に次の境界を決めます。

• どの組織が、どのデータの正本を持つか
• 必要な利用目的の通知や同意取得を、誰が、どこで行うか
• 遅延や運休の情報を、誰が更新するか
• 決済の返金と問い合わせを、誰が受けるか
• 緊急時に、支援情報を誰まで共有できるか
• 事業終了時に、データをどう返却・削除するか

標準APIを使っても、責任は自動で決まりません。データ項目の接続と、業務の責任分界を同時に作る必要があります。

MaaSの事業機会は、地域に残る運行・連携の課題から探す

経路検索や決済は、大手の地図、交通、決済サービスがすでに強い領域です。新規参入では、既存の製品・支援会社・地域の体制で不足する仕事を探します。

以下は検証候補であり、競合がいない領域を示すものではありません。

一つ目は、複数車種を横断する運行管理です。定時バス、オンデマンド車両、自動運転バス、タクシーを一つの運行センターで扱い、遅延や故障時に代替手段を出します。

二つ目は、地域版の導入・運営パッケージです。需要調査、交通計画、住民説明、事業者調整、調達、運行手順、効果測定までをまとめます。

自治体が毎回一から仕様書を作る負担を減らします。

三つ目は、目的地と移動を結ぶ業界特化型です。通院、介護、観光、工場通勤、学校、買い物など、一つの業務へ深く入ります。

予約システムや職員の業務とつなぎ、移動以外の成果を測ります。

四つ目は、交通データを意思決定へ変える支援です。ダッシュボードを見せるだけでなく、どの便を残すか、乗降場所をどこへ変えるか、交通以外の予算とどう統合するかまで提案します。

新規事業では、MaaSへの三つの参入ルートが考えられる

自社の運行技術、地域での調整力、医療・観光等の顧客接点に合わせ、提供する仕事を選びます。ここでは参入の候補を三つに整理します。

既存の競合、必要な人員、顧客の支払意思まで確認して選びます。

自社が担当する仕事と、運行主体や提携先へ残す仕事を分け、必要な体制・費用を確認します。

運行統合SaaSは、異常時の判断まで設計する

車両の位置を表示するだけでは、運行管理になりません。遅延、故障、予約超過、乗客の体調不良が起きたとき、代替車両を出し、関係者へ連絡し、記録を残す必要があります。

ソフトウェア企業は、交通事業者や保険会社と組み、通常時と異常時の業務を分けます。自動運転が増えるほど、遠隔監視と現場出動の連携が重要になります。

地域実装パッケージは、実証後の運営者まで決める

自治体向けでは、導入前の需要調査から住民説明、事業者調整、仕様書、調達、運行、評価までが連続します。地域ごとに違いはありますが、調整事項、契約、指標は共通化できます。

個別支援で利益が出ないと決まっているわけではありません。標準化できる調査や契約・評価の手順と、地域ごとの合意形成を分け、それぞれの人員時間を見積もります。

再利用できる部分が増えても、受注価格と保守負担を含めた採算の確認は必要です。

目的地連携は、移動以外の成果を契約へ変える

病院なら受診完了率、商業施設なら来店と購買、工場なら採用範囲と遅刻、観光なら周遊と消費を成果にします。交通の費用を、目的地側の業務改善や売上へ結びつけます。

ただし、成果連動だけでは、天候や季節など交通以外の要因を受けます。固定料金、成果料金、それらの組み合わせから、測定可能性とリスク分担に合う方式を選びます。

提供者が管理できる仕事と、外部要因にも左右される成果を分けて契約します。

運行責任と事業責任は、システム導入より先に決める

通常の運行、予約変更、事故・故障を誰が判断し、誰が利用者へ対応するかを導入前に決めます。自治体、交通事業者、システム会社などで役割を分け、利用者の連絡窓口も明示します。

下表は運用分担の例であり、許認可や法的責任は契約と個別の制度に沿って確認します。

特に自動運転では、車両が止まった後を決めます。遠隔から復旧できない場合、誰が現地へ行くか。

乗客を別の車両へ移すか。保守部品が届くまで何日かかるか。

ここまで含めてサービスです。

MaaSへの関わり方を4つに分けて考える

参入：顧客接点か運行資産がある

一地域、一つの移動目的、一つの支払者へ絞って商品化します。

提携：車両・運行・地域営業の一部が足りない

自社の強い層を残し、交通事業者や技術企業と責任を分けます。

待機：実利用と支払者が読めない

既存サービスを使った小規模な有償運行で需要を確認します。

見送り：固有資産と運行責任が残らない

汎用アプリの受託だけで終わるなら、別の未解決工程を選びます。

自社は参入・提携・待機・見送りのどれを選ぶか

参入・提携の判断には、自社の強みに加え、顧客の支払意思、必要な運行体制、継続できる収支の確認が必要です。

参入が向くのは、交通事業者や自治体との顧客接点、特定業界の業務データ、運行や保守の人材のいずれかがある企業です。まず対象地域と移動目的を絞り、必要な体制と負担に合意する主体を確認します。

提携が向くのは、顧客接点はあるが、車両、配車、運行管理を持たない企業です。自社は病院や工場の業務を担当し、交通は既存事業者と組みます。

逆に技術企業は、地域営業と運行を提携先へ任せます。

待機が必要なのは、需要と支払者が曖昧な場合です。大規模なアプリ開発へ進まず、既存サービスを使って有償運行を小さく始めます。

登録意向ではなく、実際の乗車と支払いを確認します。

見送りを検討するのは、顧客が払う理由や、自社の役割に必要な体制・採算を確認できない場合です。また、事故時の現場対応を引き受ける主体がない地域では、提供を急いではいけません。

判断時には、次の六点を確認します。

1. 誰の、どの移動を変えるのか
2. 既存交通のどこを残し、どこを補うのか
3. 通常時と異常時の運行責任者は誰か
4. 運賃以外に誰が便益を得るか
5. 地域を越えて再利用できる仕組みは何か
6. 撤退時に利用者の移動をどう守るか

MaaSに詳しい相談先は、技術より運営条件を聞く

MaaSの相談先は、画面や機能に加え、運営体制・費用負担・効果測定を具体化できるかで選びます。対象地域の移動目的、既存交通、運転手、支払者、運行責任を一緒に整理できるかを確かめます。

次の質問をしてみてください。

• 既存の鉄道、バス、タクシーをどう生かすか
• 実証後に誰が運営し、費用を負担するか
• 電話や窓口を含め、利用完了までどう支えるか
• 遅延、欠便、事故、故障時に誰が判断するか
• 交通以外の成果をどの指標で測るか
• 一地域の個別対応を、次の地域へどう再利用するか

技術会社だけ、交通会社だけ、コンサルティング会社だけでは、すべてを担えない場合があります。重要なのは一社で完結することではなく、足りない役割を認識し、責任分界を示せることです。

イノベーション総研では、MaaSを流行テーマとして評価するのではなく、自社資産、地域課題、主要企業、提携先、運行責任、収益モデルを一枚の事業構造へ整理します。参入、提携、待機、見送りのどれが妥当かを、事業判断として具体化します。

MaaSに関するよくある質問

定義、代表的な取り組み、運賃と財源、参入の考え方に関する疑問を整理します。

Q. MaaSとは簡単に言うと何ですか？

A. 鉄道、バス、タクシーなどを一つの移動サービスとしてつなぎ、検索、予約、決済をしやすくする考え方です。日本では、観光や医療など目的地のサービスと連携し、地域課題を解くところまで含めて捉えます。

Q. MaaSと経路検索アプリの違いは何ですか？

A. 経路検索はMaaSの一機能です。MaaSは、予約、決済、チケット、実際の運行、目的地サービス、地域の運営までを含みます。アプリがなくても、複数交通を一体運営する仕組みならMaaSの考え方を使えます。

Q. 自動運転はMaaSに必須ですか？

A. 必須ではありません。自動運転は交通を供給する選択肢の一つです。既存の鉄道、バス、タクシー、シェアサイクル、オンデマンド車両を組み合わせるだけでもMaaSは作れます。

Q. 日本のMaaSで進んでいる事例は何ですか？

A. my route、EMot、KANSAI MaaSのような広域検索・電子チケット、MONETのオンデマンド交通、ANAのUniversal MaaS、BOLDLYやTIER IVの自動運転支援などがあります。目的と担う層が異なるため、単純な順位では比べられません。

Q. MaaSは運賃だけで黒字化できますか？

A. 地域とサービスで異なります。運賃、自治体の委託費、施設や企業の負担と、運行・保守・システムの総費用を比較します。交通事業者がシステム会社へ払う料金は地域内の支出でもあり、地域全体の新たな財源と二重に数えません。

Q. MaaSへ新規参入するなら、どこが有望ですか？

A. 運行管理、地域での導入支援、医療・観光・通勤との連携が検討候補です。いずれも既存事業者がいるため、対象顧客が解決できていない仕事、支払者、必要な体制、採算を確認して選びます。

まとめ：移動を地域事業として続けられるか

MaaSを続けるには、通常期の移動需要を確かめ、運行責任と総費用を担う財源を合意します。複数の交通手段を便利につないでも、利用数だけで事業の成立は判断できません。

主要8事例を見ると、価値は広域の交通連携、共通チケット、オンデマンド配車、支援の引き継ぎ、自動運転の運行管理へ広がっています。共通する課題は、実証後の運営者、異常時の責任、運賃以外の支払者です。

新規事業では、運行統合SaaS、地域での導入・運営支援、目的地との連携が検討候補です。受託開発でも、役割と適切な対価があれば成立し得ます。

一方、必要な運行・事故対応を担う主体がなく、採算や継続財源も確認できない場合は、投資を見送る判断が必要です。

MaaSで最初に作るべきものはアプリではありません。「誰を、どこへ運び、誰が便益を得て、誰が運行責任を持つか」という一枚の事業構造です。

情報確認日：2026年9月27日。事例の数字には公表時点と対象を併記しました。

提供機能、採用・許可、利用規模、費用・生活上の効果を分けて読みます。収支の計算は架空例です。

参考文献

行政・事業主体の一次資料を参照しています。数字や提供段階の直接の出典は各節にも示しました。

• 国土交通省「日本版MaaS推進・支援事業の実施について」
• 国土交通省「地域交通DXの推進」
• 国土交通省「MaaSのデータ連携への支援」
• 国土交通省「デマンドバスシステム連携API標準仕様書」
• トヨタ自動車「my route本格実施」
• 小田急電鉄・EMot「MaaS Japan累計取扱額100億円」
• KANSAI MaaS
• MONET Technologies
• ANA「お客様の多様性への対応」
• BOLDLY「Dispatcher」
• 塩尻市「特定自動運行の許可取得（2025年1月）」
• 伊藤忠商事「Via Mobility Japanが提供するオンデマンド型乗合サービス」