介護送迎管理システムの開発・導入は、6段階に分けて進みます。要件整理から始まり、テストと段階的な稼働を経て、定着へ進みます。
各段階で次へ進む条件を決めておくと、後工程の作り直しを抑えられます。全体像は、介護・福祉業向け介護送迎管理システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・介護・福祉業向け介護送迎管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
介護・福祉業向け介護送迎管理システムの全体像
介護送迎管理システムは、介護現場のルールに沿って送迎情報をつなぐ業務システムです。カーナビや一般的な配車ソフトとは違い、利用者の状態や家族との連絡まで扱う点が特徴です。
扱う範囲は広く、利用者や車両の情報から、送迎ルート、乗降時刻までを含みます。欠席・振替や家族への通知、送迎後の実績も一元管理します。扱う情報が多いため、導入前に情報の判断者と記録内容を決めておく必要があります。
最初に押さえるべき機能と業務範囲
基本となるのは、利用者・家族と車両・職員のマスター登録です。そのうえで、曜日ごとの定期パターンを組み、乗車順を作成します。
- 計画変更：欠席、振替、時間変更を計画に反映。
- ドライバー支援：ルートの表示と、乗降実績の記録。
- 利用者情報：車いす、歩行状態、乗降介助、停車位置の登録。
- 個別条件：家族への連絡方法や、乗り合わせを避ける条件の登録。
項目が不足すると、注意事項が紙や口頭に残ったままになり、導入後も伝達ミスが減りません。そこで、送迎中の遅延連絡や到着前通知を対象に含めるかも、導入前に決めておきます。
業務範囲には、運転者の報告や変更履歴まで含めます。送迎後の実績やヒヤリハットも、同じ範囲で扱います。さらに、介護記録・請求ソフトからCSVまたはAPIで取り込めば、二重入力を抑えられます。
利用者情報を毎日コピーする設計にすると、住所や利用曜日の変更が反映されない恐れがあります。そのため、連携の方式と、データの正本をどこに置くかを要件に含めておきます。
SaaS、パッケージ、ローコード、スクラッチの違い
方式ごとに、始めやすさと対応範囲を比べると、自社の規模や要件に合う選択肢を絞れます。
- 送迎特化SaaS：短期間で始めやすく、無料トライアルのある製品もあります。
- 介護パッケージ：利用者情報をまとめやすい一方、送迎最適化や画面は製品ごとに確認が必要です。
- ローコード：欠席申請などを早く試作できますが、地図や車いす対応には追加設計が要ります。
- スクラッチ開発：複数拠点や共同送迎に合わせやすい。ただし、長期保守の体制づくりが欠かせません。
SaaSでは、独自ルールや複雑な連携に制約が出る場合があります。また、ローコードでも、ルート計算やリアルタイム位置の追加設計が必要です。
スクラッチ開発では、制度改定や端末更新、障害対応を長く管理し続ける必要があります。方式は、1拠点の計画改善か、法人全体の基盤整備かで選びます。
介護送迎管理システム開発・導入の進め方
導入を進めるには、現場の困りごとを機能の一覧に置き換える前に、業務の流れとして整理することが欠かせません。
業務と例外処理は、計画担当者や管理者、介護職員が確認します。ドライバーや請求・情報システムの担当者も加わると、確認の抜けを減らせます。可能であれば、家族対応の担当者も加えます。
6段階は、前の段階で決めた内容を次の段階で使う順に並んでいます。前の決定を次の段階で使うため、段階ごとに次へ進む条件を決めておくと、後工程の作り直しを抑えられます。
1. 要件整理：現場の制約と責任者の確認
まず、送迎前日から当日の送迎後までを時系列に並べ、担当者と帳票を記録します。流れの中で扱うのは、利用予定や乗車可否、車両・運転者の割当てです。さらに、家族連絡や出発・到着も含めます。
欠席や遅延が起きたときに、実績が確定するまでの流れも記録しておきます。急な欠席を誰が何分以内に計画に反映するか、ルート変更を誰が承認するかも、決めておくべき事項です。さらに、事故やヒヤリハットをどの画面で報告するかも、機能より先に業務ルールとして定めます。
必須機能の範囲は、必須、重要、将来対応の3段階に分けて定めます。次の一覧のとおり段階ごとに機能を分けておくと、初期予算を調整しやすくなります。
- 必須：車いすスペース、乗降介助、相性、往復、複数便、欠席・振替、権限、実績・変更履歴。
- 重要：家族通知、地図表示、CSV連携、運行状況の共有。
- 将来対応：AIの候補ルート、法人内共同送迎、自治体・他施設との連携。
2. 選定：製品と開発会社の同条件での比較
候補となる製品や開発会社は、実務への適合性と導入後の条件を、同じ基準で比べます。
- 実データのデモ：匿名化した利用者50名、車両3台、車いす利用者2名で試す。
- 例外条件：午前・午後の往復、急な欠席2名、乗り合わせ不可の設定。
- 計画機能：作成から変更通知までの実演と、介助時間や停車場所を条件にできるかの確認。
- 製品条件：対応業態、人数・台数の上限、スマホ・タブレット、介護ソフト連携、複数拠点、家族通知、実績保存。
- 導入・運用：無料試用、初期設定、移行、研修、障害窓口、解約時のデータ返却。
事例を見るときは、何名を何台で運用し、計画時間や走行距離がどう変わったかを確かめます。作成できる職員数の変化も、合わせて見ておきます。
3. 設計・開発：AI候補と管理者の承認
管理者向けのWeb画面と、ドライバー向けのスマホ・タブレット画面は、分けて設計します。ドライバー画面は、停車中に安全に操作できる情報量に抑えます。運転中の操作を前提にしないためです。
- 管理者画面：曜日パターン、利用者、車両定員、車いすスペース、担当者、変更履歴。
- ドライバー画面：停車順、到着予定、注意事項、乗降確認、遅延・不在報告の表示。
- AI候補：ルートは自動で確定させず、管理者が候補を確認・修正して承認する。
- 記録と制約：希望時間、乗車負担、定員、車いす、介助者、勤務時間の扱いと、変更者・確定時刻の記録。
希望時間や定員、車いすの条件を同時に扱うと、最短ルートが現場に合わない場合があります。そのため、AIの候補は管理者の承認を経て確定する形です。
誰が条件を変え、いつ確定したかは、監査ログに残ります。確定後の実績は、上書きできない仕組みです。
4. テスト：例外日を含めた検証
テストでは、通常日と例外日の両方を想定します。そのうえで、機能ごとに担当者、条件、合格基準を決めます。
- 運行変更：欠席、振替、新規利用、車両故障、運転者交代を試す。
- 連絡・端末：住所・停車場所の変更、家族への遅延通知、通信断、端末紛失、復旧後の再送信。
- 介護特有の制約：定員に余裕があるのに、車いす固定装置が足りない場合。
- 受入基準：欠席後の必要情報、変更前の計画、変更者・時刻、通信断時の代替手順の検証。
欠席を登録したあと、計画担当者とドライバー、関係職員が必要な情報を確認できるかを試します。変更前の計画や変更者・変更時刻が残るか、通信断時に代替手順へ移れるかも確かめます。また、利用者や家族の個人情報を、本番環境からテスト環境へコピーしない運用も必要です。
5. 稼働：1拠点・1便からの段階的な切替
稼働では、切替の条件と初日の連絡体制を整えます。現場が迷わない手順にしておく必要があります。
- 試験導入：把握しやすい1拠点または1便で始め、最初の1〜2週間は紙・Excelと照合する。
- 並行運用：欠席・遅延・ルート変更の伝達を確認し、終了日と紙を使う条件の決定。
- 初日の体制：ベンダー窓口、施設の判断責任者、予備端末、通信障害時の連絡先の明確化。
- 基本手順：ログイン、ルート確認、乗降記録、異常報告、電話への切替の説明。
家族への通知が、到着時刻を保証するような表現になっていないかを確かめます。そのうえで、現場の説明と画面の表示をそろえます。
6. 定着：KPIと改善会議による運用改善
効果は、導入前の基準値と比べて確かめます。そのうえで、伝達漏れ、家族からの到着時間の問い合わせ件数、遅延件数、走行距離も確認します。拠点・便・曜日ごとに分けて見ると、どこで効果が出ていて、どこに課題が残るかが分かりやすくなります。
- 作業効率：計画作成時間と、作成できる職員数。
- 運行状況：伝達漏れ、家族からの問い合わせ、遅延、走行距離、車両稼働率。
- 安全記録：ヒヤリハット報告の完了率。
- 定期改善：月1回程度、未使用機能、入力項目、運用ルール、通知先の見直し。
厚生労働省の2026年3月の導入モデルは、送迎計画作成時間の短縮を示しています。さらに、経験の浅い職員でも作成できるようになった事例もあります（出典：厚生労働省「介護テクノロジー等のパッケージ導入モデル（改訂版）」、2026年）。
使われなかった機能は、個人を責めずに、使わなかった理由を確認します。利用者の状態変化や新サービス、車両の入れ替えがあったときは、マスターを更新する担当を決めておきます。新拠点で広げる際は、標準手順と拠点ごとの例外ルールを分けておくと、法人全体への展開に役立ちます。
介護送迎管理システムの費用相場とコストの内訳
費用は、既製サービス、パッケージのカスタマイズ、個別開発のどれを選ぶかで変わります。公開料金の製品と問い合わせ制の製品、個別見積の開発費は、分けて比べます。
示す金額は、公開価格と機能範囲からの推定レンジです。規模や連携の範囲によって変わり、端末、通知、保守範囲も影響します。そのため、推定は予算の初期仮説として扱います。
公開価格から見る既製サービスの目安
送迎特化クラウドの費用は、利用者数や拠点数に応じて変わります。
通知・動態管理・端末・複数拠点を含めると、月額数万円から10万円程度のケースがあります。公開価格と予算の仮説は分けて考えると、端末や保守が料金に含まれるかを比べやすくなります。
- ぴっくあっぷプランナー：1事業所番号あたり、パソコン1台目は年額21万6,000円、2台目以降は年額3万6,000円です。
- 価格に含むもの：税別の価格で、電話・メール問い合わせなどの保守とバージョンアップ費が対象です（出典：株式会社シスコム「送迎支援システム」、2026年確認）。
- 追加確認：1台目は月額換算で1万8,000円相当です。端末購入費と初期データ整備費、申込可否の確認が要ります。
- クラウドの予算仮説：基本は月額数千円〜数万円、追加機能込みでは数万円〜10万円程度のケースがあります。
- 公開例：月額3,000円から、1名あたり月額100円、送迎パック月額4,000〜6,000円、タブレット月額1,900円。
2026年7月時点では、同製品はバージョンアップ検討に伴い新規受付を一時中止と掲載されています。ここに挙げた価格は各サービスの公開例で、全体の標準価格ではありません。
カスタマイズ・個別開発の推定レンジ
次に、カスタマイズの範囲と開発規模ごとの推定額を並べます。見積もりを比べる際は、その前提も合わせて確かめてください。
- パッケージ導入：初期設定、CSV整形、データ移行、研修、帳票変更を含め、30万〜150万円程度。
- パッケージ改修：権限、通知、帳票、介護ソフト連携のカスタマイズで、150万〜500万円程度。
- 単一法人のMVP：マスター、計画、ドライバー画面、実績、管理画面に絞った場合で、300万〜800万円程度。
- 本開発：複数拠点、AI、API、監査ログ、共同送迎、強い権限管理を含む場合で、800万〜2,000万円程度。
金額は、公開価格や一般的な業務システム開発費、機能範囲をもとにした推定です。公的な定価ではありません。
要件定義やデータの状態、地図APIや通知量によって上下します。端末管理やセキュリティ検証も影響するため、見積もりは項目と前提条件をそろえて比べます。
見落としやすい初期費用・運用費
初期費用と運用費、保守費を合わせて比べると、総額が見えやすくなります。開発期間も、見積もりの対象範囲とあわせて確認します。
- 初期費用：住所・利用者マスター移行、CSV整形、ルート登録、権限設定、研修、操作マニュアル。
- 運用費：端末、通信、地図API、SMS・電話通知、保守、問い合わせ、バックアップ、脆弱性対応。
- 保守費：個別開発の場合、初期費の年10〜20％、または月額5万〜30万円程度が仮説。
- 期間の目安：既製設定は2〜8週間、パッケージ連携は2〜4か月、単一拠点MVPは3〜6か月。
- 大規模開発：複数拠点・外部連携は6〜12か月、AIや共同送迎の責任分界を含むと9〜18か月の場合があります。
保守費にクラウドや端末、通知が含まれるかは、見積もりの段階で確かめておきます。「導入支援一式」と書かれている場合は、研修回数や移行件数、問い合わせ範囲まで確認します。
見積もりを取る際のポイントとチェックリスト
見積もりは、同じ業務範囲で比べることが前提です。候補会社へ渡す資料には、拠点数や利用者数、車両数を書きます。車いす利用者数や1日の便数も、必ず記載します。
職員やドライバーの数、既存ソフト、送迎表も伝えます。伝える内容には、例外処理や必要なKPI、希望時期も入ります。個人情報は匿名化したうえで、実データに近いダミーケースを用意します。
要件書に入れるべき実務チェック
要件書では、扱うデータと連携方法を具体的に書きます。そうしておくと、確認漏れや二重管理を防げます。
- 利用者情報：氏名、住所、曜日、送迎区分、車いす、介助、停車位置、家族連絡。
- 車両・計画：定員、車いす固定数、車種、点検状態、定期パターン、乗降順、所要時間、複数便、往復。
- 変更・実績：欠席、振替、車両・運転者変更、相性、出発・到着、乗降、未乗車理由、遅延、ヒヤリハット。
- 記録管理：修正履歴、確定者、保存期間、削除権限の明記。
- ソフト連携：ケアカルテ、ワイズマンシステムSP、ほのぼのシリーズなどとのデータの流れの図示。
CSVでは、項目名と文字コード、更新頻度を決めます。重複の判定やエラー時の戻し方も、あらかじめ定めておきます。
APIでは、認証方式や接続先、利用上限を確認します。障害時の再送、仕様変更の通知、連携費用も対象です。連携しない項目を決めておくことも、二重管理を防ぐ要件になります。
デモとPoCで確認する判定基準
デモでは現場の担当者が実務の操作を試し、PoCでは自施設に合う合格条件で測ります。
- デモ操作：利用者の追加、車いす車両への割当て、同乗不可の入れ替え。
- 変更操作：当日欠席とドライバー通知、乗降実績の確定を、担当者と運転者で試す。
- 改善分類：迷った操作を、研修、画面改修、運用変更に分ける。
- PoCの基準：計画時間、欠席変更の通知時間、作成職員数、入力漏れ、停車中の確認しやすさ。
計画作成時間は導入前後で何分かかるか、欠席変更は何分以内に全員へ届くかを決めておきます。作成できる職員数や入力漏れの上限、停車中の確認しやすさも、基準として並べます。
ダイハツ工業の「らくぴた送迎」は、導入施設の例として、作成時間が2時間から15分になり、月間走行距離が平均113km削減したと紹介しています（出典：ダイハツ工業「らくぴた送迎」、2026年確認）。
これは、その施設の事例です。自施設でも同じ効果が出るとは限らないため、基準値と実績をPoCで測ります。
セキュリティ、契約、共同送迎の確認
介護送迎では、住所や連絡先のほか、身体状況や介助内容などの個人情報・要配慮個人情報を扱います。
見積もりの段階から、職種・拠点・担当便に応じた最小権限と多要素認証を確かめておきます。
- アクセス管理：職種・拠点・便ごとの最小権限と多要素認証。
- データ保護：通信・保存時の暗号化、操作ログ、バックアップ。
- 障害対応：端末紛失時の停止、脆弱性対応、連絡先、復旧目標。
- 委託管理：委託先を含む安全管理の体制。
厚生労働省は2026年に「介護事業所における情報安全管理の手引き」を公開しました。ログインや閲覧・入力・送信、バックアップなどの扱いを示しています（出典：厚生労働省「介護事業所における情報安全管理の手引き」、2026年）。
契約では、サービスレベルや障害時の対応時間を確認します。保守範囲や保存期間も、契約書に明記されているかを見ます。
解約時の返却形式と削除証明も対象です。再委託先やクラウドのリージョン、料金改定も確認します。
地図やSMSなどの外部サービス費用も確かめます。複数拠点や共同送迎では、閲覧範囲と共有情報、事故・遅延の責任分界を定めます。料金負担や保険、運転資格の取り決めや、共同運行の承認者も、契約で扱う項目になります。
国土交通省の2025年度実証では、福祉系送迎車両約25万台と1日平均4時間程度の稼働に着目し、共同管理を検証しています（出典：国土交通省「COMmmmONS 施設送迎共同管理システム」、2026年）。
ただし、共同送迎には、システムに加えて制度、契約、運行体制の設計が必要です。
よくある質問（FAQ）
導入前の疑問は、費用や機能とあわせて、事業所の規模や既存ソフト、現場の運用に照らして確かめます。個人情報の扱いについても、同じ考え方で確認します。
小規模なデイサービスでも介護送迎管理システムを導入できますか？
導入できます。利用者や車両が少ない場合は、送迎計画や欠席・振替、共有に絞った既製クラウドを試します。
最初から個別開発を選ぶ前に、月額料金と削減できる作業時間を比べます。そのうえで、まず1便や1拠点でPoCを行い、連携や複数拠点の要件を確かめてから広げれば、初期投資のリスクを抑えられます。
AIが送迎ルートを完全に自動で決めてくれますか？
完全自動で確定するとは限りません。AIや最適化機能は、候補を出す支援機能として使います。
候補は、住所や希望時間、車両定員などをもとに作られます。管理者は、安全性や例外条件を確かめたうえで承認します。候補の根拠や変更条件、承認者、確定後の履歴は、あとから確認できる形で残ります。
介護利用者の個人情報をクラウドで管理しても問題ありませんか？
判断の中心は、クラウドかどうかより、事業所と委託先が必要な安全管理措置を実施できるかです。
- 技術対策：権限管理、認証、暗号化、ログ、バックアップ。
- 委託先と障害対応：再委託先の扱いと、障害時の対応。
- 解約時の対応：データの返却と削除。
- 現場運用：端末利用と紙の持ち出しルールを整え、最新の厚生労働省の手引きや個人情報保護委員会のガイダンスに照らします。
管理体制は、契約・運用・技術の3面からそろえて確認することが大切です。
介護送迎管理システムに補助金を使えますか？
送迎システムが必ず対象になるとは限りません。対象かどうかは、年度や自治体、事業区分によって異なります。さらに、対象技術や申請時期、導入前後の手続きも関係します。
厚生労働省は、介護テクノロジー導入・定着支援やICT導入支援の情報を公開しています。確認するのは、TAIS登録、対象経費、申請前の契約の禁止です。実績報告と公募要領も、あわせて見ておきます。
補助金がなくても成り立つ総額で、事業計画を立ててください。
まとめ
介護送迎管理システムは、送迎表に加えて、安全判断や職員・ドライバー間の共有、家族連絡をつなぐ業務基盤です。送迎後の実績まで含めると、日々の業務全体を支えます。
導入は要件整理、選定、設計開発、テスト、稼働、定着の6段階に分けて進め、各段階の合格条件をあらかじめ決めておきます。
導入前に確認する5つの観点
最終判断では、次の観点で候補を比べます。
- 現場制約：車いす、介助、相性、停車位置、欠席を入力できるか。
- 責任分界：管理者承認と変更履歴を説明できるか。
- 総額：連携、移行、端末、通知を含めて比較したか。
- 情報管理：権限、ログ、バックアップ、障害、解約時の返却を確認したか。
- 効果測定：1拠点PoCで時間、伝達漏れ、問い合わせ、走行距離を測れるか。
特に、車いすや介助への対応と、相性や停車位置、欠席への対応が必要です。
最初の一歩は現行の送迎表と例外処理の洗い出し
開発会社へ相談する前に、直近1週間の送迎表と、利用者・車両・運転者の条件を匿名化して整理します。欠席・遅延の連絡方法と、月間の問い合わせ件数もまとめておきます。
同じ条件で複数社にデモと見積もりを依頼します。そのうえで、1拠点・1便のPoCで安全性と効果を確かめると、無理のない導入につながります。
▼全体ガイドの記事
・介護・福祉業向け介護送迎管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。