介護・福祉業向け介護送迎管理システム開発の発注/外注/依頼/委託方法について

介護送迎管理システムの発注は、課題整理、要件定義、会社比較、試行の順で進めると送迎ミスを減らせます。

発注形態、RFP、契約と費用、委託先選定の4段階で、それぞれ何を決めればよいかをまとめます。全体像は、下の関連記事でも確認できます。

▼全体ガイドの記事
・介護・福祉業向け介護送迎管理システム開発の完全ガイド

介護・福祉業向け介護送迎管理システムの発注・外注の進め方

送迎計画の周囲に、利用者条件・運行条件・変更対応・属人化を配置した図解
日々の変更と条件整理が計画作成を複雑にします。

発注は、現場の困りごとを洗い出したうえで、既製サービスで足りる範囲と開発が必要な範囲を分けて進めます。複数社に同じ条件を示すと、提案と見積を並べて比べられます。

「AIで最適なルートを作る」のような機能名だけで選ぶと、誰が何を確認するかが曖昧なまま進みやすくなります。そこで出発点になるのが、誰がいつ何を確認し、どの状態で計画を確定するかを決めることです。

送迎管理システムを外注する理由

送迎計画では、利用者の条件や日々の変更が大きな負担になります。

  • 利用者条件:住所、曜日、乗降場所、車いす、介助、同乗不可の組み合わせ
  • 運行条件:運転者の経験や車両定員も計画に影響
  • 変更対応:欠席や振替を複数の表に反映すると、連絡漏れや二重入力が起きやすい
  • 属人化:詳しい職員が休むと計画を作れない

属人化や変更対応を見直す方法の一つは、送迎業務を理解する外部の知見を取り入れることです。

発注先に任せられる範囲

委託先には、現状業務のヒアリングから保守までを依頼できます。対象は、業務整理やデータ項目の整理、サービス比較に加えて、RFP作成や設計、開発、テストです。移行と研修も含まれます。

ただし、利用者の安全に関わる乗車条件や、職員が送迎計画を確定するルールは、事業者自身が判断します。そこで、業務ルールと実装する機能を分けて、委託先と合意しておきます。

発注方式を決める基本的な考え方

発注方式は、事業所の規模と必要な機能に応じて、候補を絞っていきます。

  • 標準的な運用:利用者数や車両数が少なく、標準の送迎表で足りるなら送迎特化SaaSやパッケージ
  • 複雑な運用:複数拠点や複雑な条件があれば、カスタマイズや個別開発も比較
  • 選定材料:介護記録・請求ソフトとの連携、法人独自の権限、車いす条件

判断の軸は、機能をどれだけ持つかより、送迎ミスを減らし、計画担当者を増やし、利用者への対応時間を確保する目的に沿うかどうかです。

ポイント

迷ったときは、既製サービスで足りるか開発が必要かを先に分け、誰がいつ何を確認するかを決めてから比べます。機能名だけで選ぶと、確認の役割が曖昧なまま話が進みやすくなります。

発注形態(SaaS・パッケージ・個別開発)の選び方

発注形態は費用だけで決めず、導入の速さ、業務への合い方、保守の責任、将来どこまで変えられるかを比べます。

まず、課題を標準機能、運用、開発のどれで解決するかを分けておきます。

送迎特化SaaSが向いている事業所

早く試して費用を抑えたい単一拠点や、紙・Excelから移行する事業所には、送迎特化SaaSが向いています。導入前には、次の機能を実データに近い条件で確認します。

  • 基本情報:利用者、車両、運転者のマスター
  • 計画変更:曜日パターン、欠席変更、乗降実績
  • 現場連絡:スマートフォン通知と職員の使いやすさ

ダイハツ工業の「らくぴた送迎」は、最大2か月の無料試用を案内しています。試用を使えば、候補サービスを実際の条件に近づけて比べられます(出典:ダイハツ工業「らくぴた送迎」、2026年確認)。

パッケージ導入とカスタマイズの見極め方

標準機能を活かす場合も、追加で改修する場合も、設定や連携の条件を先に確認します。

  • 設定調整:初期設定、CSV移行、権限、帳票、通知文を業務に合わせる
  • データ連携:介護ソフトと連携できれば二重入力を減らせる
  • 連携条件:連携方向、更新時期、削除や訂正の扱いを確認する
  • 改修範囲:標準外の改修は、更新時の追加費用や検証負担を踏まえて優先順位をつける

スクラッチ開発を選ぶケース

標準サービスが業務に合わないときは、スクラッチ開発を検討します。

  • 複雑な運用:複数拠点・共同送迎・独自の車いす配置
  • 個別要件:施設とどこまでを誰が受け持つか、既存システムとのAPI連携、監査ログ
  • 小規模開発:単一拠点でマスターと送迎表だけなら、開発費と保守負担が大きくなりやすい
  • 試行と拡張:単一拠点のMVP(Minimum Viable Product)を作り、計画作成時間、変更連絡の漏れ、問い合わせ件数を測る

PoCで試すデータと条件

PoCでは、匿名化した利用者20〜50名程度と車両2〜3台を使い、次の条件を含めて計画を作ります。

  • 利用者条件:車いす、乗車時の介助、送迎時間の希望
  • 変更条件:急な欠席と現場からの変更入力
  • 確認項目:ルート、乗降順、定員、関係者への通知

AIや自動配車の結果は、そのまま確定せず、管理者が修正できるかを確かめます。あわせて、ドライバーが停車中に情報を見られるかも試します。

ポイント

発注形態は、標準機能で解決できるかで決めます。足りるならSaaSやパッケージから試し、標準では解けない複雑な運用や個別要件だけスクラッチ開発を検討すると、費用と保守の負担を抑えやすくなります。

RFPと要件整理の記載項目

RFPの記載項目を利用状況・運行体制・機能要件・データ連携に分けたチェック図
規模と現場条件をそろえると、各社の提案を比べやすくなります。

RFPには、機能一覧に加えて、現状業務や課題、利用規模を書きます。既存データやセキュリティ、導入後の運用、見積条件もまとめ、各社が同じ前提で提案できる資料にします。

「使いやすい画面」のような曖昧な表現より、誰が何分以内に何を終えたいかを書くと、提案を比べやすくなります。

現行業務と利用規模の整理

朝のお迎えから施設到着までの流れと、欠席連絡、午後の送り、実績登録を、担当者ごとに書き出します。そのうえで、規模と運行条件を次の項目で整理します。

  • 利用状況:曜日別の人数、繁忙曜日、拠点数
  • 運行体制:1日あたりの車両数、車いす対応台数、運転者と添乗者
  • 便数:往復の便数と1日あたりの利用規模

利用者50名、車両3台、車いす2名という条件に、2拠点の情報を添えて示すと、定員上限だけでなく、実際の制約を踏まえた提案を受けられます。

機能要件に書く介護現場の条件

機能要件には、利用者と家族、住所、停車位置を含めます。身体状況や車いす、介助上の注意、乗車不可の組み合わせも、同じ要件に書きます。加えて、曜日や車両定員、運転者と添乗者も記載します。

計画機能は、曜日パターンの複製、乗降順の提案と手動修正、欠席・振替・新規利用者の反映に分けて要件にします。また、変更履歴と確定処理も、別の要件として書きます。

ドライバー向けには、ルートや到着予定を含めます。注意事項、乗降実績、申し送りも含めます。特に、運転中の操作を前提にしない画面を要件にします。

連携・セキュリティ・運用要件の確認項目

連携、施設間の共有、安全管理に関わる条件は、RFPにまとめておきます。

  • データ連携:CSV・APIの初回移行、更新、欠席、削除、訂正の扱い
  • 閲覧範囲:法人・施設管理者、計画担当者、ドライバーの権限と共同送迎時の他施設情報
  • 安全・運用:多要素認証、暗号化、ログ、バックアップ、障害復旧、委託先管理、解約時のデータ返却

厚生労働省の手引きは、安全な使用環境やログイン・ログオフ、閲覧・入力・送信の対策を示しています(出典:厚生労働省「介護情報基盤について」、2026年確認)。

ポイント

RFPは、利用規模や現場の条件、連携や安全面の要件を具体的に書くほど、各社の提案を同じ土台で比べられます。曖昧な言葉は、提案ごとに解釈が分かれる原因になります。

契約形態(準委任と請負)の使い分け

工程ごとに契約を分ける方法があります。たとえば、変わりやすい企画や要件定義は準委任、完成機能と検収条件を合意して進める開発は請負、リリース後は月額保守とします。

IPAの情報システム・モデル取引・契約書も、開発段階ごとの責務や、請負と準委任の論点を整理しています(出典:IPA「情報システム・モデル取引・契約書 第二版」、2025年更新)。

準委任契約の成果の管理方法

準委任は、専門業務の遂行に対して報酬を支払う契約です。業務整理や要件定義、PoC、アジャイルな改善に向いています。

目標を「送迎計画をよりよくする」と書くだけでなく、定例会の回数や現場職員へのヒアリング人数も決めておきます。画面案や要件一覧の提出時期、検討結果の形式も定めます。

作業は稼働時間だけでなく、意思決定に必要な成果とレビューの方法を契約に明記して管理します。

請負契約の検収条件

請負では、納品物と完成条件を具体的に決め、受入テストに次の項目を含めます。

  • 計画機能:マスター登録、曜日パターン、定員内の計画
  • 変更対応:欠席通知、CSV取込、乗降実績の保存
  • 管理機能:権限別表示と操作ログ

匿名データを使い、車いす利用者の割当、変更通知、確定後の訂正履歴を確かめてから検収します。完成条件を満たしたといえるのは、画面が表示されたうえで、業務の流れが通ったときです。

知的財産権・データ・保守の責任範囲

契約時には、プログラムの利用権と汎用部品を確認します。画面・帳票の著作権や、地図・ルートAPIの契約も見ておきます。あわせて、利用者データの所有者と返却方法を決めます。

SaaSでは、データの出力形式と解約後の保存期間を確認します。削除証明やサポート終了時の移行支援も、あわせて確かめます。

保守契約には、受付時間と重大障害の連絡期限、復旧目標を記載します。脆弱性対応とバックアップも含め、制度改定や追加開発の単価も決めておきます。

介護送迎管理システムの発注費用・相場

公開料金と個別開発の推定レンジは、分けて考えます。初期設定や移行、端末、通信が別料金の場合もあります。研修や連携、保守も、別に料金がかかることがあります。

個別開発費には、公的な一律の相場がありません。そのため、ここに挙げる数字は、一般的な業務システム費と公開価格例をもとにした予算推定です。実額は要件と見積で決まります。

公開料金のある送迎サービスの料金例

公開料金の例では、台数で課金するものと、登録人数で課金するものがあり、料金の体系が異なります。

  • ぴっくあっぷプランナー:事業所番号とPC台数に応じた年額制
  • はやまる送迎:登録人数に応じた月額制と送迎パック

シスコムは1事業所番号あたり、パソコン1台目が年額21万6,000円です。2台目以降は年額3万6,000円です(出典:株式会社シスコム「送迎支援システム」、2026年7月確認)。料金は税別で、保守・バージョンアップ費を含みます。

ベストリハは、登録1名あたり月額100円の例と、送迎パックの基本料金を掲載しています(出典:ベストリハ「はやまる送迎」、2026年確認)。小規模拠点で送迎機能のみを使う場合、月額3,000〜1万8,000円程度が公開価格の目安の一つです。比べる際は、機能の範囲をそろえておきます。

カスタム開発の費用レンジ

開発方式ごとの推定レンジは、必要な機能や支援範囲によって、次のように幅があります。

  • 既製クラウド:初期設定・移行込みで0〜30万円程度、月額3,000円〜10万円程度
  • パッケージ:初期設定、CSV整形、研修、限定改修を含めて30〜150万円程度
  • カスタマイズ:標準機能を活かす場合は150〜500万円程度
  • スクラッチ:MVPは300〜800万円程度、本開発は800〜2,000万円程度

単一法人向けのMVPと本開発では、対象とする要件が異なります。本開発では、複数拠点やAI配車候補、API連携を含みます。さらに、監査ログや共同送迎、強い権限管理も対象になります。

これらは、一般的な業務システム開発費を組み合わせた推定で、特定企業の受注価格ではありません。金額は、利用者数や拠点数に加えて、連携や帳票、支援範囲によっても変わります。

画面数や連携数を分けて見積もります。スマートフォン対応、移行量、テスト範囲も、それぞれ別に見ます。

月額以外にかかる費用

初期費用と月額利用料のほかに、マスター移行や住所確認、研修の費用が発生する場合があります。端末や通信、地図API、SMSの費用がかかることもあります。さらに、介護ソフト連携、拠点追加、保守、制度改定対応も費用になる場合があります。

個別開発の保守は、初期開発費の年10〜20%、または月額5〜30万円程度を予算に置けます。ただし、クラウドや問い合わせ対応を含むかどうかは、各社で異なります。

初年度の額だけでなく、3年間の総額と解約・移行費も比べます。

ポイント

公開料金と個別開発の推定レンジを分けて考え、初期費用だけでなく、月額や保守、連携、研修の別料金も含めて見ます。個別開発の金額は推定なので、最終的な額は要件と見積で決まります。

委託先の選定と見積比較の確認項目

委託先の確認項目を、介護・送迎の実績・デモとPoC・見積書・個人情報と障害対応の4パネルで示した図
現場での試行と見積条件を並べて、委託先を評価します。

委託先は、介護・福祉の送迎を理解し、現場の判断をシステムに落とし込める会社を選びます。製品デモに加えて、匿名化した実データでの提案、導入支援、連携実績も確認します。

障害時の対応とデータ返却も確認します。また、見積は合計額だけでなく、前提条件と除外項目をそろえて比べます。

介護・送迎の実績の確認方法

導入業態や利用者数、車両数、車いすや介助条件への対応を確認し、計画作成者以外の運用実績も見ます。対象となる業態は、デイサービスや通所リハビリ、障害福祉、医療・介護施設です。

ダイハツの公開事例では、2025年8月時点で市内8施設、車両6台、ドライバー約20名の共同送迎が紹介されています(出典:ダイハツ工業「市内8施設の送迎共同化」、2025年)。

大規模な事例は規模が違うため、そのまま当てはめにくいものです。そこで、自社に近い規模の事例で効果指標を確認します。

デモとPoCでの評価項目

事業者が用意した条件で、利用者登録から計画確定までを操作してもらい、次の動きを見ます。

  • 割当:車いす車両と乗車不可の組み合わせ
  • 現場情報:停車位置の写真と注意事項の表示
  • 変更連絡:欠席入力後に通知される相手

パナソニックの事例では、表計算で30分〜1時間かかった作成が、DRIVEBOSS導入後に15〜30分短縮したと紹介されています(出典:パナソニック カーエレクトロニクス「春日丘荘デイサービスセンター導入事例」、2025年)。

これは一例にすぎません。そのため、自社でも同じ指標を測り、実際の改善幅を確かめます。

見積書の比較項目

見積書は、要件定義から保守までを工程ごとに分けて見ます。数量や期間、担当者、データ件数も確認します。打ち合わせや修正の回数、検収方法もあわせて見ます。

安い見積では、ヒアリングや移行、権限設計が除外される場合があります。テストや研修、保守が外れることもあります。一方、高い見積には、不要な独自機能や過剰なAI開発が含まれる可能性もあります。

金額の差が出る理由を委託先に説明してもらい、必要な作業が含まれているかを判断します。

個人情報と障害対応の確認

クラウドの保管場所や、委託先と再委託先、アクセス権を確認します。管理者ログや通信・保存時の暗号化、バックアップも確かめます。脆弱性対応や端末紛失時の措置も対象です。

共同送迎では、施設間で共有する情報の範囲と、事故や問い合わせがあったときの責任者を、契約と運用手順に記載します。

厚生労働省の手引きや個人情報保護の資料を参照します。そのうえで、委託先の回答を自社の安全管理規程に反映できるかを確かめます。

ポイント

委託先は、介護・送迎の実績と、匿名化した実データでの提案を確かめて選びます。障害時の対応やデータ返却、前提条件をそろえた見積まで確認すると、比較の材料がそろいます。

よくある質問(FAQ)

費用だけでなく、導入規模やデータ、契約も検討します。さらに、セキュリティと現場への定着もあわせて見ます。

小規模なデイサービスでも外注するメリットはありますか?

計画を作れる職員が限られていたり、変更が伝わりにくかったり、紙から利用者情報を探す手間があったりすれば、小規模事業所にも外注の利点があります。

初期開発より、無料試用や月額サービスから始めます。計画時間や変更連絡漏れ、残業、問い合わせ件数を導入前後で比べ、効果を確かめてから複数拠点や連携を追加します。

AIが作った送迎計画をそのまま採用しても安全ですか?

AIや自動配車は、住所や時間、定員、車いす条件から、計画の候補を作る支援機能として使います。確定は、管理者が確認して行う運用にします。

利用者の相性や当日の体調、道路事情、介助者の配置は、データに表れにくい要素です。そのため、候補の根拠や手動修正の内容、確定者、変更履歴を残しておくと、説明と改善に役立ちます。

補助金を使える前提で発注してもよいですか?

支援策を使える可能性はありますが、その内容は、対象製品や申請時期、対象経費によって変わります。自治体の公募条件によっても異なります。特に、採択前提で契約・着手すると、対象外の場合に資金計画が崩れます。

発注前に、厚生労働省や自治体、公募要領を確認します。そのうえで、見積を対象と対象外の経費に分け、採択前に着手できるかを委託先に確かめます。

既存の介護ソフトと二重管理にならないためにはどうしますか?

既存ソフトの正本をどのデータにするかを決めます。利用者や予定、欠席、送迎実績が対象です。

CSV取込かAPI連携かを決め、更新頻度も要件にします。エラー時の再取込と手動訂正の履歴も、要件に含めます。

連携が難しい場合は、利用者マスターだけを取り込むなどして、二重入力が起きる範囲を限定します。そのうえで、段階的に改善します。

参考情報:株式会社シスコム「送迎支援システム」、ベストリハ「はやまる送迎」、ダイハツ工業「らくぴた送迎」、厚生労働省「介護情報基盤について」、IPA「情報システム・モデル取引・契約書」、パナソニック カーエレクトロニクス「春日丘荘デイサービスセンター導入事例」

まとめ

発注時は、送迎表だけでなく、身体状況や車いす、介助、停車位置まで要件に含めます。欠席や家族への通知、乗降実績、変更履歴も、あわせて要件にします。

小規模な拠点では、SaaSやパッケージを試します。独自の連携や共同送迎が課題であれば、カスタマイズやスクラッチ開発も比べます。

発注前にRFPへ書く項目

発注前に、RFPの記載項目と見積の比較条件を整理します。

  • RFPの規模:利用者・車両・拠点数、車いす対応、運転者・添乗者
  • 現状と安全:現行のExcelや介護ソフト、連携、権限、ログ、バックアップ、障害対応、データ返却、導入時期
  • 見積比較:要件定義、開発、移行、研修、保守を分け、初期・月額費用や端末、通信、API、拠点追加を比較
  • 総額と体制:3年間の総額に加え、安全に使い続けるための支援体制と、どこまでを誰が受け持つかを評価

最初の一歩は現場データを使った小さな比較

試行の範囲と導入前後の評価指標をそろえておくと、次の投資判断に備えられます。

  • 試行範囲:1拠点・1車両群・代表的な利用者条件で、計画から変更通知、送迎後記録までを確認
  • 評価指標:計画時間、送迎ミス、変更漏れ、家族の問い合わせ、残業、計画を作れる職員数を導入前後で測定

AIの提案を人が承認でき、職員の修正を改善に反映してくれる委託先を選ぶと、システムの定着につながります。

▼全体ガイドの記事
・介護・福祉業向け介護送迎管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。