タクシー配車システムとは：配車アプリ・無線・乗務員端末の構成と自社開発の判断

タクシー配車システムは、利用者からの依頼を受けて、いちばん早く着ける空車を選び、乗務員に迎車を指示する仕組みです。中身は電話受付と配車室の画面、車載の乗務員端末とGPS、利用者向けの配車アプリという3つの層の組み合わせです。この記事では、それぞれの層の役割、トラックの貨物配車との違い、2026年2月に国土交通省が公表したタクシー配車システム連携API標準仕様、日本版ライドシェアと配車データの関係を順に整理します。最後に、既存の配車プラットフォームで足りる事業者と、送迎や乗合のために自社開発が見合う事業者の分かれ目を条件付きで示します。

まとめ｜タクシー配車システムの構成と、既存プラットフォームで足りる条件

タクシー会社が自前で持つべきなのは、配車室の配車管理システムと乗務員端末までです。利用者向けの配車アプリは、GOやS.RIDE、DiDi、Uberといった既存のプラットフォームにつなぐ形が現実的で、一般のタクシー事業者が自社アプリをゼロから作っても利用者は集まりません。

接続の前提は2026年に変わりました。国土交通省が「タクシー配車システム連携API標準仕様書」を公開し、配車アプリと配車管理システムの間で配車依頼を受け渡し、配車状況と車両位置を同期する方法を標準として定めたからです。これまでアプリごとに必要だった個別開発が減る方向にあります。配車管理システムを選び直すなら、この標準APIへの対応予定を必ず確認してください。

自社開発が見合うのは、介護・福祉の送迎、病院や施設の定時送迎、自治体のデマンド交通のように、予約の受け方や乗合の組み方が一般のタクシー配車と違う場合です。標準APIも予約配車や乗合はまだ十分にカバーしていません。この領域は既製品の外側に要件が残ります。

タクシー配車システムの構成要素｜受付・配車室・乗務員端末・配車アプリの役割

製品カタログでは一括りに「配車システム」と呼ばれますが、実際は担い手の違う3つの層が連携しています。どの層を買い、どの層を他社に任せるかで費用も自由度も変わります。

電話受付と配車室の画面が担う、住所の特定から空車の選定までの流れ

電話配車では、オペレーターが利用者の住所や目印を聞き取り、地図上の迎車地点を確定させます。常連客の通話時間を大きく縮める方法は、電話番号から過去の乗車地を呼び出せるようにしておくことです。迎車地点が決まると、配車管理システムが周辺の空車を距離や到着予想時間の順に並べ、オペレーターまたは自動配車機能が1台を選んで指示を出します。

この「誰に振るか」の判断を人が担うか機械が担うかで、配車室の人数は変わります。到着予想時間で自動的に割り当てる考え方は、貨物の分野で自動配車システムの仕組みと導入条件として整理されている内容と、一部が共通する考え方です。ただしタクシーは1件ごとに即時で決める点が違い、計算の重さよりも位置情報の鮮度が精度を左右します。

車載の乗務員端末とGPSが送る、空車・迎車・実車のステータスと位置

乗務員端末は、配車指示を受け取り、乗務員が「了解」「到着」「乗車」「降車」を押して状態を返す装置です。メーターと連動させると、空車・迎車・実車の切り替えが自動で記録されます。GPSの位置情報と合わせて、配車室は「いまどこに何台の空車がいるか」を地図上で把握できます。

端末の方式は、専用の車載器、タブレット、乗務員のスマートフォンの3通りが主流です。専用車載器はメーターやドライブレコーダーとの連動が確実な一方、入れ替えに車両ごとの工事がかかります。スマートフォン方式は導入が速く、台数の少ない事業者で選ばれています。

利用者向け配車アプリと、プラットフォーム事業者に依頼が集まる構造

利用者がスマートフォンから呼ぶ配車アプリは、GO、S.RIDE、DiDi、Uberなどのプラットフォーム事業者が運営しています。タクシー会社はこれらと契約し、自社の車両をアプリ上に表示させて依頼を受ける仕組みです。アプリでは乗車前に運賃を確定させる事前確定運賃や、アプリ内での決済も使えます。事前確定運賃は2019年10月に国の認可を受けて本格運用が始まりました。

課題は、プラットフォームごとに接続方式が違うことでした。複数のアプリと契約すると、配車室の画面とアプリ側の依頼が別々に届き、同じ車両に二重の依頼が入る事故も起こります。後述する国の標準APIは、この分断を解くために作られました。

専用無線から携帯網とクラウドへ移った経緯と、2016年5月のアナログ期限

かつてのタクシー配車は、事業者ごとに基地局を持つ専用無線が前提でした。総務省は、タクシーの運行に使う無線局のアナログ方式について周波数の使用期限を2016年5月31日と定め、電波法関係審査基準の改正（2016年6月1日施行）でその後の扱いを整理しました。この切り替えを機に、デジタル無線へ移る事業者と、携帯電話網とクラウド型の配車管理システムへ移る事業者に分かれています。

クラウド型では配車管理の機能を事業者の社内サーバーではなく外部のデータセンターに置くため、基地局やサーバーの保守が不要になります。いま新たに配車システムを検討するなら、専用無線を新設する選択肢はほぼ残っていません。

タクシーの旅客配車とトラックの貨物配車の違い｜即時性・割当単位・運賃で比較

同じ「配車」でも、旅客と貨物では業務の中身が大きく違います。貨物側の業務は配車とは何か、物流の配車業務の流れと配車計画の組み方で詳しく扱っているので、ここでは違いだけを並べます。

数分以内の即時配車と、翌日分をまとめて組む計画配車の判断基準の違い

貨物の配車は「組み合わせの計算」で、旅客の配車は「近い空車の選択」です。貨物向けの配車管理システムの機能と費用をタクシーにそのまま流用しても、積載や順路の機能は使われず、位置の更新頻度や乗務員端末との連動が足りません。製品を探すときは旅客向けかどうかを最初に確認してください。

送迎・デマンド交通は両者の中間にあたり、既製品が合いにくい理由

介護施設の送迎、病院の通院送迎、自治体のデマンド交通は、旅客を運ぶのに予約制で、1台に複数の利用者を乗せて順に回ります。つまり旅客の乗車管理と、貨物に近い順路の計算を両方必要とします。

タクシー向けの配車システムは即時配車が中心で乗合の順路計算が弱く、貨物向けは旅客の乗降記録や車いすの有無といった属性を持ちません。この中間領域が、後で述べる自社開発の主な対象になります。

国交省のタクシー配車システム連携API標準仕様｜2026年2月公表で変わる接続

2026年に入って、タクシー配車の接続の考え方に国の標準ができました。配車システムを入れ替える予定のある事業者は、この章の内容を製品選びの条件に入れてください。

配車アプリごとの個別接続の負担と、標準APIが定める連携の範囲

国土交通省は、地域交通のDXを進めるCOMmmmONS（コモンズ）の取り組みとして2025年度に「タクシー配車アプリ連携API標準化プロジェクト」を実施し、その成果をタクシー配車システム連携API標準仕様書として公開しました。ガイダンスはv1.0で、2026年2月13日の初版制定、作成は総合政策局 公共交通政策部門 モビリティサービス推進課です。

対象は、配車アプリと配車管理システムの間で配車依頼を連携すること、そして配車状況と車両位置の情報を同期することです。公開物はガイダンスに加え、業務一覧、業務フロー、機能一覧、論理構成図、インフラ構成図、API仕様（1.0.0）、ERD、テーブル定義までそろっています。アプリ側とシステム側がこの仕様に合わせれば、多対多の接続ごとに個別開発をしなくて済む、というのが狙いです。システム同士を仕様でつなぐ考え方はAPI連携の仕組みと導入判断でも解説しています。

4地域の実証で確かめられた点と、予約配車・乗合が標準APIに残した論点

標準APIの実証レポートによると、実証は愛媛県松前町、愛知県高浜市、福岡県福岡市、新潟県新潟市の4地域で行われ、参画した電脳交通は自社のDS配車システムに標準API連携を実装しました。配車依頼の受付、配車指示、結果の返却を標準APIで通し、データ項目や通信エラー時の挙動、実際の車両運行まで確認しています。

成果として、事業者側では依頼の受付窓口が広がり、実証期間中に月間の配車依頼数が増えたと報告されています。既存のUber連携の配車機能と標準API連携が併存できることも確認されました。一方で、予約配車、乗合、料金と連動するサービスなど各社独自の機能をどこまで標準に含めるかは、今後の検討課題として残っています。送迎やデマンド交通で自社開発が残る根拠は、まさにこの未カバー部分です。

共同配車ガイドラインが示す、複数事業者で配車室を共有する運用

同じ2025年度には「タクシー共同配車業務標準化プロジェクト」も実施され、タクシー共同配車業務の運用ガイドラインが公開されています。複数のタクシー事業者が配車業務をまとめて行う共同配車について、立ち上げと運用の業務一覧・業務フロー、運用機能一覧、構成図、API仕様を示したものです。

配車室のオペレーターを1社で確保できない地方の事業者にとって、共同配車は配車室の人員を補う現実的な選択肢です。夜間だけ共同配車室に任せる、といった部分的な運用も検討できます。システム面の検証結果は配車連携APIと共同配車システムの技術検証レポートにまとまっています。

日本版ライドシェアと配車データ｜不足車両数の算定とタクシー事業者の管理

2024年4月に始まった日本版ライドシェア（道路運送法第78条第3号に基づく自家用車の有償運送）は、タクシー配車システムのデータを制度の根拠に使っています。配車システムの記録が、事業の許可の範囲に直結する点はほかの業務システムにない特徴です。

配車アプリのデータで決まる不足車両数と、雨天時の運用の見直し

国土交通省は、雨天時における日本版ライドシェアの案内で、配車アプリのデータ等に基づき国が指定した不足車両数の範囲内で自家用車による有償運送を認めていると説明しています。そのうえで、雨の日に移動需要が増える傾向が確認されたため、1時間5mm以上の降水量が予報される時間帯とその前後1時間は、自家用車を稼働させられるよう運用を見直しました。

どの時間帯にどれだけ車が足りないかは、配車依頼に応えられなかった件数で測られます。配車システムに「依頼を受けたが配車できなかった」記録を残せない事業者は、自社地域の不足を数字で示せません。システムを選ぶときは、未配車の件数と時間帯を集計できるかを確認項目に加えてください。

タクシー事業者が担う運行管理と、配車アプリを使わない場合の扱い

日本版ライドシェアは、タクシー事業者の管理の下で一般ドライバーが運送する仕組みです。北海道運輸局の日本版ライドシェアのページには、運行管理や整備管理の取扱いとあわせて、「配車アプリを使わない日本版ライドシェアの導入ガイドライン」も掲載されています。アプリが普及していない地域では、電話受付の配車システムで運用する形も想定されているということです。

一般ドライバーの点呼や乗務の記録は、タクシー乗務員と同じく事業者側で管理する記録です。事業の区分と許可の考え方は道路運送法の事業区分と点呼記録の保存年限、記録の持ち方は運行管理システムで点呼と乗務記録を法定要件どおりに残す方法で整理しています。配車システムと運行管理の記録が別々だと、同じドライバーの情報を二度入力する手間が残ります。

既存プラットフォームか自社開発か｜タクシー事業者と送迎事業者の判断基準

結論から言えば、一般のタクシー事業者は既製品とプラットフォームで足ります。自社開発に踏み込むのは、既製品の守備範囲の外にある予約・乗合・連携の要件を持つ事業者だけです。

クラウド配車システムと既存の配車アプリで足りる事業者の運行条件

次の条件に当てはまるなら、開発ではなく選定に時間を使ってください。

• 運行の大半が即時の迎車と流しで、予約は電話で受ければ回る
• 依頼の入口として、主要な配車アプリのうち1〜2社と契約すれば地域の利用者をカバーできる
• 運賃はメーターと事前確定運賃で完結し、法人契約の請求も既製品の帳票で出せる
• 配車室の人数が少なく、夜間は共同配車や自動配車で補う方針である

この場合、比べるべきは配車管理システムの月額と端末の方式、そして標準APIへの対応予定です。独自のアプリを作る費用を、既存アプリの手数料と比べて検討する必要はありません。製品の比べ方は貨物向けですが配車管理システムの比較の観点が参考になります。

自社開発が見合う場面：送迎・乗合・独自予約と既存業務システムの連携

自社開発の費用を回収できるのは、次のような要件がある場合です。介護・福祉の送迎で、利用者ごとの車いすや介助の有無、乗降場所、曜日ごとの定期予約を扱う場合。病院や商業施設が無料送迎を運行し、予約と乗車実績を自社の業務システムに戻したい場合。自治体のデマンド交通で、停留所単位の乗合予約と運行事業者への配車指示を一体で回したい場合です。

いずれも標準APIで未カバーとされた予約と乗合が中心で、既製のタクシー配車システムを無理に合わせると手作業が残ります。乗務員側のスマートフォンアプリと予約受付の画面を作り、既存の配車管理システムとはAPIでつなぐ構成なら、ゼロから全部を作るより費用を抑えられる構成です。乗務員端末アプリや予約画面の開発、既存システムとの連携の相談は業務用・Webアプリ開発で受け付けています。

利用者向けの配車アプリを自前で作るべきでない場面と、回収できない典型

一般のタクシー事業者が、地域限定の利用者向け配車アプリを自前で作るのはやめるべきです。理由は単純で、利用者はすでにGOやUberなど全国で使えるアプリを入れており、1社のためだけに別のアプリを入れる動機がありません。開発費に加え、iOSとAndroidの改修、決済の対応、ストア審査への追従が毎年続きます。

失敗の典型は、「手数料を払いたくない」という理由で自社アプリを作り、ダウンロード数が伸びずに電話配車へ戻るパターンです。手数料を減らしたいなら、標準APIに対応した配車管理システムで複数の入口を束ね、地域の自治体アプリや施設のサービスからの依頼を受けられるようにするほうが効果があります。

よくある質問

タクシー配車システムの導入や入れ替えを検討するときに、よく出る質問をまとめました。

タクシー配車システムの費用はどのような内訳でかかりますか？

大きく分けて、配車管理システムの初期費用と月額、乗務員端末の費用、配車アプリ経由の依頼にかかる手数料の3つです。クラウド型は初期費用が小さく、台数や配車件数に応じた月額や従量課金が中心になります。専用車載器を使う場合は車両ごとに機器と取付工事の費用がかかり、スマートフォン方式なら端末費を抑えられます。製品ごとに見積の前提が違うため、自社の台数と月間の配車件数をそろえて複数社に見積を依頼してください。

配車アプリとタクシー会社の配車システムは何が違いますか？

配車アプリは利用者が車を呼ぶための入口で、GOやS.RIDE、DiDi、Uberなどのプラットフォーム事業者が運営しています。配車システムはタクシー会社側で依頼を受け、空車を選んで乗務員に指示を出す仕組みです。アプリからの依頼も最終的には配車システムや乗務員端末に届きます。2026年2月に国土交通省が公表した標準仕様は、この両者をつなぐ方法を定めたものです。

保有台数が10台程度の小さなタクシー会社でも導入できますか？

保有台数が10台程度でも導入は可能です。クラウド型の配車管理システムとスマートフォンの乗務員端末を組み合わせれば、基地局やサーバーを持たずに始められます。配車室の人手が足りない場合は、地域の事業者と共同配車を組む方法もあり、国土交通省が共同配車の運用ガイドラインを公開しています。まず配車アプリ1社との契約と、電話受付の画面を1つにまとめるところから始めるのが現実的です。

介護タクシーや施設の送迎バスの配車にも使えますか？

即時配車が中心のタクシー向け製品は、定期予約や乗合の順路計算、車いすの有無といった利用者属性の管理が弱く、そのままでは合わないことが多いです。送迎専用の製品を探すか、予約受付と乗務員アプリを開発し、既存の配車システムや業務システムとつなぐ構成を検討してください。予約と乗合は国の標準APIでも未カバーとされた領域で、要件を先に書き出すことが選定の出発点になります。

配車システムの導入に補助金は使えますか？

使える可能性はありますが、制度は旅客と貨物で分かれています。貨物のトラック輸送向けの補助金は配車システムの補助金で整理しており、これらは旅客のタクシー配車には当てはまらないものが多いです。タクシーや送迎の配車システムは、地域公共交通の確保やDXを目的とした国や自治体の支援が対象になり得るため、管轄の運輸局と自治体の公募要領で対象経費を確認してください。

関連記事

• 配車管理システムとは？運送業の配車計画・運行計画の機能と費用・導入判断：貨物向けの配車管理システムの機能と費用の全体像
• 配車管理システムの比較｜3タイプの選び方と費用・受託開発の判断基準：製品の比べ方と受託開発に進む条件
• 自動配車システムとは？AI配車の仕組みと導入条件・受託開発の判断：自動で割り当てる仕組みと向く業務
• 配車システムの自作：Excel・kintone・Pythonで作れる範囲とパッケージへの切り替え基準：自作で済む範囲と切り替えの目安
• 配車とは？物流の配車業務の流れと配車計画の組み方・属人化の解き方：貨物の配車業務そのものの解説