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

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

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

国土交通省は、移動サービスだけでなく、観光や医療といった目的地のサービスとの連携もMaaSに含めています。つまり、便利な経路検索アプリを作ることが最終目的ではありません。病院へ通える、観光地を回れる、買い物へ行けるといった生活の結果まで設計する考え方です。

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

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

どれか一つが欠けると、利用者は移動できません。アプリが使いやすくても、乗る車両が来なければ価値はありません。車両があっても、予約方法が難しければ高齢者に届きません。実証が成功しても、翌年度の運行費を誰が負担するか決まらなければ続きません。

この記事の結論は、MaaSの競争力はアプリの機能ではなく、交通の供給、運行責任、移動先で便益を得る事業者を一つの地域事業として設計できるかで決まるということです。主要8事例を比べ、新規事業の入口と懸念を整理します。

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

日本の地域交通では、利用者の減少と運転手不足が同時に進んでいます。便数を減らせば、さらに使いにくくなります。一方で、病院、学校、買い物へ移動できない人を放置することもできません。

そこで、決まった時刻と経路を走る大型バスだけでなく、予約に応じて経路を変えるオンデマンド交通、小型車両、自動運転バスなどを組み合わせる動きが広がっています。2025年度の「日本版MaaS推進・支援事業」で、国土交通省は29事業を選定しました。支援対象も、単体アプリから、他分野との連携、広域化、データ活用へ広がっています。

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

たとえば、通院しやすくなれば、医療機関は予約の空きを減らせます。観光客が周遊すれば、宿泊、飲食、小売の売上が増えます。従業員の送迎を共同化できれば、複数企業の採用範囲を広げられます。この便益を収益モデルへ組み込めるかが、地域交通を続ける鍵です。

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

MaaS、自動運転、ライドシェアは同じ意味ではありません。MaaSは移動全体をつなぐ仕組みです。自動運転バスやライドシェアは、その中で人を運ぶ手段です。

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

ライドシェアも、空いている車両と運転者を供給へ加える方法です。ただし、日本版ライドシェアは運行主体、地域、時間帯などに制度上の条件があります。利用者が「MaaS」で知りたい全体設計と、「ライドシェア」で知りたい制度や利用方法は異なるため、本記事では制度の詳細へ踏み込みません。

重要なのは、交通手段を流行で選ばないことです。需要がまとまる幹線は鉄道や定時バス、需要が散る地域はオンデマンド交通、限定経路は自動運転バスというように、地域ごとに使い分けます。

MaaS市場は、アプリ競争から地域交通DXへ移っている

初期のMaaSでは、複数の交通手段を一つのアプリへ載せることが注目されました。現在は、その先にある運行、生産性、データの標準化が中心になっています。

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

2025年には、オンデマンド交通のシステムが事業者ごとに分かれ、相互運用しにくい問題への対応も始まりました。MONET Technologiesは、デマンド交通データの標準化プロジェクトに参画しています。MaaSは「新しいアプリを増やす段階」から「異なるシステムをつなぎ、地域が運用できる段階」へ移っています。

市場規模の予測には注意が必要です。調査会社によって、配車、公共交通、決済、自動運転、観光まで含める範囲が違うからです。新規事業では、大きな世界市場の数字より、対象地域の移動回数、車両数、運行費、関係施設の便益から積み上げる方が現実的です。

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

MaaSには多くの企業と組織が関わります。役割を五つに分けると、自社がどこへ入るかを考えやすくなります。

車両やアプリだけでは事業は完結しません。3層の運行では、日々の遅延、乗客対応、車両故障、遠隔監視が発生します。5層の地域運営では、バス会社、タクシー会社、自治体、住民、病院などの利害を調整します。

大手企業と正面から競うより、層と層の間に残る仕事へ入る方が現実的です。たとえば、複数の配車システムを横断する運行管理、病院の予約と送迎の連携、自治体が翌年度の予算を判断する効果測定には、まだ標準形がありません。

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

国内の取り組みを、単純な知名度ではなく、どの層を担い、何を解決しているかで比較します。商用サービス、社会実装、実証を区別して見ることが大切です。

トヨタと西鉄は、移動と目的地をmy routeでつなぐ

my routeは、鉄道、バス、タクシー、シェアサービスの検索や予約だけでなく、デジタル乗車券、地域の店舗やイベント情報を組み合わせます。

この事例の要点は、交通情報の一覧ではありません。利用者に「どこへ行くか」という理由を示し、その場で移動手段を選べることです。交通事業者だけでなく、自治体、観光施設、飲食店が参加する余地があります。

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

小田急電鉄は、利用者向けのEMotと、他社や自治体も使える共通データ基盤「MaaS Japan」を展開しています。MaaS Japanは2025年11月に累計取扱額100億円を超えたと公表しました。

利用者向けアプリだけでなく、チケットの造成、販売、認証、精算を裏側で共通化する点が重要です。地域ごとに一からシステムを作らず、交通事業者が既存の仕組みへ参加できれば、導入費と運用負担を下げられます。

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

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

一社の沿線だけで閉じないことが強みです。一方、広域連携では、商品設計、データ形式、問い合わせ、障害対応、収益配分をそろえる必要があります。技術より、競合企業の間で共通ルールを作る運営力が価値になります。

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

MONET Technologiesは、利用者向けアプリ、オンデマンド配車、運行管理、医療・行政向けの車両サービスを提供します。国土交通省の公開記事では、オンデマンド交通の導入支援は53自治体に達しています。

大分県豊後大野市の乗合交通、鳥羽市の医療MaaS、各地の行政サービス車両など、同じ技術を地域課題ごとに組み替えています。MaaSを「移動のアプリ」ではなく、「人やサービスを必要な場所へ動かす基盤」として展開している事例です。

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

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

一般的な経路検索では、段差、乗り換え時の介助、車いす対応、空港内の移動が抜けます。Universal MaaSは、予約情報だけでなく「誰が、どこで、どの支援を引き継ぐか」をつなぎます。他分野MaaSでは、データ連携より先に、現場の引き継ぎを設計する必要があります。

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

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

茨城県境町では、自動運転バスを期間限定の実証ではなく、地域の交通として運行しています。ここで価値があるのは車両の自動運転機能だけではありません。遠隔監視、現地人材、バス停、運行情報、保険や保守まで含めて日常運用へ落とした点です。

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

TIER IVは、オープンソースの自動運転ソフトウェアAutowareを軸に、車両、センサー、開発環境、運行向けの仕組みをパートナーと展開します。塩尻市などの自治体と、自動運転バスやオンデマンド交通を一体で進めています。

オープンな基盤は、車両や部品を一社へ固定しない選択肢を作ります。ただし、オープンソースを導入すれば自動的に運行できるわけではありません。走行環境の定義、地図、車両調整、安全評価、運行責任を担う企業が必要です。

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

Via Transportationの技術は、近い方向へ向かう予約をまとめ、車両の経路と乗降場所を調整します。決まった路線を空のまま走る負担を減らしつつ、一人ずつ運ぶタクシーより乗り合いを成立させる考え方です。

重要なのはアルゴリズムの精度だけではありません。電話予約を残すか、乗降場所まで歩けるか、鉄道や幹線バスへ接続できるかで利用率が変わります。配車システムは地域の運行条件と一緒に設計する必要があります。

主要事例から見える地域交通の四つの成功条件

8事例を横断すると、成功条件は四つに絞れます。

第一は、先に移動目的を決めることです。「高齢者の通院」「観光客の周遊」「駅から工業団地への通勤」のように、誰の何を変えるかを具体化します。対象が曖昧なままでは、必要な車両も時間帯も決まりません。

第二は、幹線と支線を組み合わせることです。すべてをオンデマンドにせず、需要が多い区間は鉄道や定時バスへ集めます。小型車は駅や病院までの短い区間に使うと、車両を効率よく回せます。

第三は、運行責任を商品設計へ入れることです。予約、乗客対応、遅延、欠便、車両故障、事故、個人情報への対応者を決めます。アプリ開発会社が運行を担わないなら、交通事業者や運行支援会社との役割分担が必要です。

第四は、移動先の事業者を費用負担者へ加えることです。病院、商業施設、観光施設、雇用企業、不動産事業者は、人が来ることで便益を得ます。運賃と補助金だけでなく、この便益を契約へ変えます。

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

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

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

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

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

地域交通で運賃を上げれば、必要な人ほど使いにくくなります。だからといって、補助金へ依存すれば事業は不安定です。収益は、四つの財布に分けて考えます。

1. 利用者が払う運賃、定期、会員料金
2. 自治体が払う公共交通、福祉、観光などの委託費
3. 病院、商業施設、ホテル、雇用企業が払う送客・送迎費
4. 交通事業者が払う配車、運行管理、データ分析の利用料

たとえば、病院向けでは、送迎車両の費用だけでなく、予約の空きや家族の送迎負担を減らす価値があります。観光地では、乗車回数だけでなく、滞在時間、立ち寄り店舗、消費額を測ります。

一方、広告やデータ販売を安易な収益源にしてはいけません。利用者数が少ない地域では広告価値が限られます。移動履歴は生活や健康状態を推測できる情報でもあります。本人の理解がない二次利用は、信用を失う原因になります。

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

MaaSでは、経路、予約、決済、乗降、位置、支援情報などを扱います。国土交通省のデータ連携ガイドも、参加主体の間で連携項目と形式をそろえる重要性を示しています。

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

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

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

まだ埋まっていない市場は、運行と地域連携にある

経路検索や決済は、大手の地図、交通、決済サービスがすでに強い領域です。新規参入では、同じアプリをもう一つ作るより、現場に残る仕事を探します。

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

二つ目は、地域版の導入・運営パッケージです。需要調査、交通計画、住民説明、事業者調整、調達、運行手順、効果測定までをまとめます。自治体が毎回一から仕様書を作る負担を減らします。

三つ目は、目的地と移動を結ぶ業界特化型です。通院、介護、観光、工場通勤、学校、買い物など、一つの業務へ深く入ります。予約システムや職員の業務とつなぎ、移動以外の成果を測ります。

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

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

イノベーション総研では、MaaSへの参入を三つに分けます。自社が持つ資産によって、現実的な入口は変わります。

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

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

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

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

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

利益を出すには、個別コンサルティングだけにしないことです。標準の診断、合意形成の手順、調達仕様、運行マニュアル、評価指標を部品化します。地域固有の部分だけを追加する設計にします。

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

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

ただし、成果連動だけでは、天候や季節など交通以外の要因を受けます。基本料金と成果料金を組み合わせ、提供者が管理できる指標と、最終成果を分ける必要があります。

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

MaaSには、自治体、交通事業者、システム会社、車両会社、施設、決済会社が参加します。問題が起きたときの窓口を利用者へ押し付けてはいけません。

特に自動運転では、車両が止まった後を決めます。遠隔から復旧できない場合、誰が現地へ行くか。乗客を別の車両へ移すか。保守部品が届くまで何日かかるか。ここまで含めてサービスです。

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

参考文献

• 国土交通省「日本版MaaS推進・支援事業の実施について」
• 国土交通省「地域交通DXの推進」
• 国土交通省「MaaSのデータ連携への支援」
• 経済産業省「令和6年度スマートモビリティチャレンジ」
• トヨタ自動車「my route本格実施」
• 小田急電鉄・EMot「MaaS Japan累計取扱額100億円」
• KANSAI MaaS
• MONET Technologies
• ANA「お客様の多様性への対応」
• BOLDLY「Dispatcher」
• TIER IV「次世代自動運転のハイブリッド・アーキテクチャ」
• 伊藤忠商事「Via Mobility Japanが提供するオンデマンド型乗合サービス」