運送会社のソフトウェア選び：現場で何を確かめるべきか

車両を保有する運送会社、フォワーダー、中小の輸送事業者のための実践的な選定ガイドです。日々の業務のどこでソフトウェアが実際に破綻するのか、デモで何をどう確かめるのか、そして4つのアプローチの本当のコスト構造を解説します。発行元はLogistivoで、当社製品の位置づけは独立したセクションで率直に示しています。 ソフトウェアを選ぶ運送会社への短い答えはこうです。最も繰り返し発生するチェーンを、ひとつのレコードの中に保持できるシステムを選んでください。道路輸送では、そのチェーンは決まっています。依頼、見積もり、受注、車両とドライバーの割り当て、書類の作成、国境の通過、貨物の配達、請求書の発行、そして入金です。製品がその途中のどこかで途切れれば、WhatsAppとスプレッドシートが再びその隙間を埋めることになり、支払ったライセンスは、同じデータを入力する場所をもう1つ増やしただけになります。 運送会社がよく判断の拠り所にしてしまうのは、誤解を招く2つの軸です。機能一覧の長さと、車両追跡が地図上でどれだけ見栄えがよいかです。現場で結果を決めるのは別のことです。ドライバーがその画面を実際に使うかどうか、運賃や顧客名がドライバーに閉じられているかどうか、同じ重量と梱包数を1日に何回書き直しているか、そして下請けに出した業務が貴社から見え続けるかどうかです。 このガイドはLogistivoが発行しています。そのため、中立ではなく率直なものとしてお読みください。以下の基準は特定の製品ではなく現場で起きることを軸に書かれており、この比較の中でLogistivoがどこに位置するのか——Logistivoがやらないことも含めて——は独立したセクションで示しています。ワークフロー、基準、4つのアプローチの比較を使って貴社の業務を採点し、デモはベンダーが用意した整ったサンプルデータではなく、貴社で最も厄介な案件で試してください。

業務のステップと、ソフトウェアに求められること

• 依頼が届く：顧客から、ネットワークから、あるいは入札シートから — ある朝、3つの経路から同時に仕事が届きます。常連の顧客からの電話、ネットワーク内の企業からのシステム上の依頼、そして年間契約のために記入する路線リストです。どれから先に見るかは、その日空いている車両と、実際に運行している路線で決まります。 届いた依頼を1つの一覧に集約すること。ルート、国、機材の種類での絞り込み。新しい依頼が届いたときのチームへの即時通知。複数路線の季節料金については、シートからの見積もりの一括入力。 適した仕事に一覧上で気づくのが遅れ、顧客は返事を待たされ、トラックは空で戻ってきます。多くの路線が並ぶリストは手で埋めるには骨が折れるため、そうした仕事にはそもそも見積もりが出されません。
• 価格を組み立て、見積もりを送る — 車両1台あたりの運賃、国境や通関の費用、帰り荷が見つかる見込みを誰かが頭の中で足し合わせ、その金額を電話かメールで伝えます。顧客が交渉すると、2つ目、ときには3つ目の金額が出てきて、どれが有効なのかがあいまいになります。 車両単位の運賃と総収入が同じ画面で見えること。見積もりを改定でき、改定時には以前の金額が自動的に無効になること。誰がいつ何の見積もりを出したかの記録と、測定された受注率。 顧客はどの金額が最新なのかわからず、合意した価格と最終的に請求書に載る金額が一致しません。どの路線が稼いでいるのか、見積もりのうちどれだけを受注しているのかがわからないままなので、価格戦略は勘頼みのままです。
• 受注：トラクター、トレーラー、ドライバーを組み合わせる、または業務を下請けに出す — 空いているトラクター、適したトレーラー、そしてそのルートを走ることが認められているドライバーを組み合わせます。適した車両がないときは、業務の全部または一部を知り合いの運送会社に回し、調整は電話に逆戻りします。 割り当て時の適格性チェック。ドライバーの書類は有効か、国外での滞在可能日数は足りているか、その日程ですでに別の運行に入っていないか。下請けに出す場合は、顧客と運賃の情報を下請け業者に閉じたまま、進捗を引き続き確認できること。 同じドライバーが2つの運行に割り当てられ、ビザの切れたドライバーが出発して国境で追い返されます。下請けに出した業務は「渡したので連絡待ち」の状態に落ち込み、顧客への回答は下請け業者が電話に出るかどうかにかかってしまいます。
• 積込と書類：納品書、CMR運送状、パッキングリスト、輸出申告 — 積込地で梱包数、重量、荷姿が確定し、同じ情報が納品書（トルコではirsaliye）、運送状、パッキングリスト、請求書にそれぞれ別々に書き込まれます。国際道路輸送ではCMR運送状が貨物とともに移動します。原則として原本3通で作成され、荷送人と運送人が署名します。CMR条約のもとでは、当事者名、梱包数、重量、貨物の品名など運送状に記載された事項の正確性について、原則として荷送人が責任を負います。運送人の役割は、梱包の数、荷印、貨物の外観上の状態を確認し、必要に応じて留保を記入することです。 ひとつの貨物レコードから運送状やその他の書類を作成できること。ドライバーが積込時にスマートフォンから書類の写真を添付できること。書類間の重量、梱包数、当事者名の違いを自動で指摘すること。 同じ情報を複数の書類に手で書き込むため、どこかでずれが生じ、そのずれはたいてい国境か銀行で発覚します。現場で撮った写真はグループチャットの中に埋もれ、オフィスは何週間も経ってからそれを探し回ることになります。
• 国境、通過、通関での待機 — 輸出申告は通常、貨物の所在地を管轄する税関に行いますが、どの税関が管轄するかは国、手続き、適用される簡易手続きによって異なります。その後、車両はそれらの書類を持って国境へ向かいます。国境では出国手続きが行われ、必要な場合は通過書類（T1申告またはTIRカルネ）が処理され、書類が確認されます。不整合や書類の不足が見つかると、待ち時間は何時間単位になり、デマレージや遅延のコストがまったく計画外に膨らんでいきます。 貨物が出発する前の書類間の整合性チェック。通関業者が当事者として同じファイルに参加できること。出発前に、品目のHSコードを仕向国の関税や貿易措置と照合できること。ドライバーのシェンゲン協定90/180日の滞在可能日数の自動カウント。 書類の不足が国境で発覚し、車両は待たされ、コストは計画を超え、顧客に伝えた配達日がずれ込みます。気づかなかった追加関税が、利益が出ると思っていた運行を赤字に変え、滞在可能日数を超えたドライバーは入国を拒否されます。
• 輸送中の追跡と顧客への情報提供 — 顧客は1日に1〜2回「トラックはどこ？」と尋ねてきます。ドライバーに電話しても、ドライバーは運転中で、返事は遅れます。同じ情報を、1日のうちに3人に3回説明することになります。 位置情報が車両ではなく、運んでいる貨物のレコードの下に流れること。すべてのステータス変更がタイムスタンプ付きで保存されること。顧客が自分の画面または共有リンクから確認できること。やり取りが貨物ごとに保持され、必要に応じて自動翻訳されること。 1日がステータスの報告で終わります。紛争になっても、車両がいつどこにいたかを証明できません。外国語のメッセージを読み違え、トラックが誤った住所へ向かいます。
• 配達、受領証（POD）、機材の返却 — 貨物を荷降ろしし、署名済みの運送状の写しと受領証を受け取り、トレーラーは空にするか、相手方に切り離して預けます。損傷をめぐる言い争いはたいていまさにこの時点で始まり、責任の所在は証明されないままになります。 ドライバーがスマートフォンから受領証を貨物に直接添付できること。配達の時刻と場所が自動で記録されること。トレーラーの引き渡し時に写真付きの受け渡し記録が残り、責任期間が追跡されること。 署名済みの運送状がオフィスに届くのは何週間も後で、届くまで請求書を発行できず、入金が遅れます。どの段階で損傷が生じたかを誰も証明できないため、控除額はたいてい最後のドライバーに不当に負わされます。
• 精算、請求、入金、帳簿の締め — 運行が終わり、運賃請求書が発行されます。下請け業者への精算額とドライバーの経費が差し引かれます。顧客は支払条件どおりに支払うこともあれば、支払わないこともあります。多くの会社では、この段階全体がまったく別のプログラムで回っています。 貨物レコードから請求書が作成されること。入金を記録すると、取引先勘定の残高と売掛金年齢表が自動で更新されること。EUの顧客のシステムが受け付ける電子請求書の形式に対応していること。ドライバーの経費が正しい側に計上されること。 同じ金額を業務、請求、会計の3か所に入力し、ミスが重なります。期日超過の売掛金が誰にも気づかれずに膨らんでキャッシュフローを壊し、形式を理由に差し戻された国際請求書のせいで、入金が何か月にも延びます。

選定基準

• 配車の中核：割り当ての時点でドライバーと車両の適格性をチェックできるか — 運送会社の1日は、誰が何をどこへ運ぶかを決めることに費やされます。システムがその割り当てを記録するだけなら、それは台帳をつけているにすぎません。割り当てる時点で、ドライバーの書類の有効性、国外であと何日滞在できるか、車両が空いているかをチェックしてはじめて、配車をしていると言えます。両者の違いは、車庫を出たあとで国境から追い返されるトラック1台分です。 ビザの期限が間近で、国外での滞在可能日数もほぼ使い切ったドライバーを設定し、新しい運行に割り当ててみてください。警告は割り当て画面そのものに表示されるでしょうか、それとも別の書類ページを開かないと見えないでしょうか？日程が重なる2つ目の運行でも同じことを試し、システムが何と表示するかを正確に記録してください。
• ドライバーが誰にも尋ねずに完了できる現場の操作 — 輸送データの大半は運転席で生まれます。積込の確認、書類の写真、位置情報、受領証です。ドライバーがその操作を1人でこなせなければ、データは遅れて、あるいは不完全なまま届くか、まったくオフィスに届かず、オペレーションチームは電話でそれを集めることに1日を費やします。ドライバー向けの画面は、運送業向けソフトウェアで最も過小評価されている項目であり、最も多くのプロジェクトを頓挫させている項目でもあります。 デモアカウントを貴社のドライバー本人のスマートフォンに入れ、横に立たず、口頭で手順を教えることもせずに、貨物を「積込済み」にしてCMR運送状の写真を添付するよう頼んでください。最初の1回で1人で完了できるでしょうか？どこでつまずいたかを記録してください。その操作は、すべての運行で毎回繰り返されるからです。
• ドライバーと現場に商業データを閉じておけるか — 貨物を更新してもらうためにドライバーにアカウントを渡した瞬間、多くのシステムでは運賃、顧客リスト、やり取りまで見えるようになります。その情報はいったん社外に出れば戻ってきませんし、たいていは最も近い競合の手に渡ります。ここでの権限の分離は高度な機能ではありません。運送会社にとっては参入の前提条件です。 ドライバーアカウントでデモにログインし、わざと探し回ってください。運賃、顧客の会社名、取引先勘定の残高、オフィスのチャット。どこかの画面で金額や顧客名が1つでも見えるなら、そのシステムは貴社の取引先名簿を漏らしています。
• 車両だけでなく、貨物のレコードにひも付いて流れる位置情報 — 運送会社の顧客が尋ねるのは「自分の貨物はどこか」であり、この質問に答えられるのは、位置情報がその貨物のレコードにひも付いている場合だけです。位置情報が別の地図の上にあると、顧客に共有できる答えは生まれず、配達の瞬間も記録されません。すでに車載端末を使っているなら、問うべきは「そのデータを運行レコードにひも付けられるか、ひも付けられるならどのような形か」です。 デモで貨物を1件開いて車両を割り当て、顧客向けの画面を自分で作ってみてください。共有リンクがあれば、ログインせずに自分のスマートフォンで開きます。なければ、顧客権限を持つ2人目のユーザーをデモに招待し、そのウィンドウから見てください。その貨物の位置とステータスは見えても、運賃やほかの顧客は見えないでしょうか？「配達済み」の時刻と場所が自動で記録されるかも確認してください。
• 見積もりの計算：車両単位の運賃、改定、受注・失注の履歴 — 運送業では、価格はたいてい車両1台あたりで話し合われ、交渉の中で1〜2回動きます。ソフトウェアが合計金額1つしか保持できなければ、合意した価格と請求額はずれていき、どの路線がいくら稼いでいるのかもわからないままです。受注率を測定していない営業プロセスは、勘で回している営業プロセスです。 車両3台の依頼に車両単位の価格で見積もりを出し、その後、価格を改定してください。3つの点を同時に確認します。総収入は自動で更新されるか、以前の見積もりは自動的に無効になるか、相手側には現在の金額が1つだけ表示されるか。
• ひとつのレコードから書類を作成し、出発前に整合性をチェックできるか — 国際道路輸送では運送状が貨物とともに移動し、同じ重量、梱包数、当事者の情報が、請求書、パッキングリスト、納品書（トルコではirsaliye）にも記載されます。その情報を手で書き写せば、どこかで必ずずれが生じ、そのずれは国境か銀行で発覚します。ひとつのレコードから書類を作成すれば、そのずれを元から断てます。実際にどれだけの時間と修正が省けるかは、貴社自身の書類量でしか判断できません。 自社のアーカイブから実際の請求書とパッキングリストをアップロードし、片方の梱包数をわざと変えてみてください。こちらが指摘する前に、システムがその違いを検出するでしょうか？次に、データを一切入力し直さずに、同じ貨物レコードからCMR運送状を作成してみてください。
• 下請けに出した業務の可視性と情報の壁 — 輸送能力が足りなくなると、業務を別の運送会社に渡します。そのとき、2つのことが同時に必要になります。相手の進捗が引き続き見えること、そして相手には貴社の顧客や運賃が見えないことです。多くのソフトウェアはこれをまったくモデル化していないか、「2社目の顧客」として設定してしまいます。自社車両だけで運行し、下請けに一切出さないならこの基準の重みは下げ、業務のかなりの部分を下請けに回しているなら最重要に引き上げてください。 貨物の一部を2社目の運送会社に渡し、その会社のアカウントから見てください。正しい結果は次のとおりです。下請け業者には貴社の顧客も、その顧客に提示した運賃も見えてはならず、一方で貴社は、電話をかけずに相手のステータス更新を確認できなければなりません。
• 車両とドライバーの書類の有効期限カレンダーと、先回りのアラート — 保険、車検、パスポート、ビザ、職業ドライバーの資格証は音もなく期限切れになり、それに気づく場所はたいてい国境の検問所か路上検査です。その時点で運行は取り消しになります。日付を保存しておくだけでは足りません。システムの方から知らせてくれる必要があります。画面を開いたときにはじめて見える警告は、監視とは言えません。 どちらも2週間後に期限が切れるドライバーのビザと車検を登録し、ログアウトして数日待ってください。アラートはメールや通知で自動的に届くでしょうか、それとも自分で探しに行かなければならないでしょうか？
• 精算・請求・入金・帳簿締めを同じレコードから回せるか — 運送業では、運行を終えた時点ではなく、入金された時点ではじめてお金を稼いだことになります。その間には運賃請求書、下請け業者への支払いの精算、ドライバーの経費があります。業務がある1つのプログラムで回り、請求と帳簿が別の場所にあると、同じ金額を2〜3回入力することになり、ミスが重なり、期日超過の売掛金が誰にも気づかれずに膨らみます。EUの顧客を相手にするなら、相手側が受け付ける電子請求書の形式で請求書を発行できるかどうかが、入金の早さに直接影響します。 デモで完了した貨物から請求書を発行し、入金済みにしてください。取引先勘定の残高と売掛金年齢表は、その1回の操作で更新されるでしょうか、それとも会計画面で同じ金額をもう一度入力することになるでしょうか？

アプローチの比較

• 電話・WhatsApp・スプレッドシートによる手作業の調整 — 単一の路線を運行し、月に数えるほどの運行しかなく、すべての車両とドライバーを名前で把握している小規模事業者。また、1年の大半は業務が止まっている季節型の事業。全員が全員を知っているうちは、柔軟性が手間を上回ります。 コストはライセンスではなく、人とミスに積み上がります。国境で止まったトラック、遅れて発行された請求書、誰も気づかなかった期日超過の売掛金、そして成長に合わせて採用する追加のオペレーション要員。どれも予算の項目には現れません。だからこそ無料に見えるのです。
• 汎用ソフトウェア＋スプレッドシートの仕組み（会計パッケージ、ERPのアドオン、テンプレート） — 会計面はすでに固まっていて、輸送業務も同じパッケージに押し込もうとしている企業。あるいは、スプレッドシートづくりが好きで、業務の流れを自分の手で形づくりたいオペレーション責任者がいる事業者。 サブスクリプションの行は安く見えます。本当の出費は、シートを作り、壊れるたびに直す人の時間です。その労働は請求書に載らないので測られることもなく、その人が辞めたときに、仕組み全体を作り直すコストが一度にのしかかります。
• 単機能のポイントツール（車両追跡だけ、書類アーカイブだけ、会計だけ） — 悩みが1か所に集中している運送会社。たとえば車両の位置以外はすべて回っている、あるいは運送状と請求書のアーカイブだけが崩れている、といった場合です。ツール間のデータ移動を手作業で行うことを受け入れられる場合や、まさにその作業のために1人を割ける場合にも理にかなっています。 ツールごとに別々のサブスクリプション、別々の契約、別々のサポート窓口があり、そこにツール間でデータを手作業で運ぶ時間が加わります。勘で決めないでください。すでに使っているツールの月額料金、データの移し替えにかかる時間、更新日をひとつの表にまとめ、その合計を、エンドツーエンドのプラットフォーム1つの見積もりと並べてみてください。
• エンドツーエンドの輸送管理プラットフォーム（TMS） — 自社車両、下請け業者、またはその両方で同じ路線を繰り返し運行し、国際輸送や複数地点を回る業務を行う運送会社やフォワーダー。運行数が増えるにつれて配車デスクが電話に追われているのが見えるなら、この列が貴社に当てはまります。ドライバーにアプリを使ってもらえることが前提条件です。 目に見える出費はサブスクリプション1つと、導入・研修の手間です。実際に答えを決めるのは料金モデルの形ではなく、貴社の取扱量でそのモデルがはじき出す金額です。同じ製品について、昨年の実際の取扱量と、成長を見込んだ場合の2通りで見積もりを取ってください。ユーザー単位、車両単位、貨物単位、定額のどれが安く収まるかは、その2つの計算を終えてはじめてわかります。

選定でよくある失敗

• テレマティクスのデータと運行レコードを切り離したままにする — 車載の追跡端末、タコグラフ、燃料センサーは、運送業で実際に役割を果たしています。運転・休息時間の遵守管理にはタコグラフのデータが、燃料ロスが疑われるときにはレベルセンサーが役立ち、ドライバーのスマートフォンの電源や充電が切れたときには、ハードウェアが位置情報を途切れさせません。問題は、このデータが運行レコードと一度も結び付かないことです。地図はある画面に、貨物のステータスと書類は別の画面にあり、オフィスはそれを突き合わせることに1日を費やします。判断を「テレマティクスか、輸送管理ソフトか」という形で捉えないでください。どちらの候補にも、既存の端末データをその貨物のレコードにひも付けられるか、どのような形でかを尋ねてください。
• ドライバーが決して使わない現場向け画面を買ってしまう — オフィス向けの画面はデモで見栄えがします。デモは、オフィスの人がオフィスの人に見せるものだからです。しかし輸送データの大半は運転席で生まれ、ドライバー側が使いにくければ、システムの現場側の半分は埋まりません。位置情報も、書類の写真も、配達時刻もなく、オフィスは以前とまったく同じように電話でデータを集めることになります。初回登録の手順でさえ重要です。長い登録とパスワード設定の流れだけで、定着が終わってしまうことがあるからです。判断の検証は、最も熱心なドライバーではなく、最も乗り気でないドライバーで行い、横に立たず、口頭で手順を教えることもせずに、運行を1件完了させてみてください。
• 料金モデルを自社の取扱量で計算し直さない — 一般的なモデルは4つあり、どれもそれ自体が正しいわけでも間違っているわけでもありません。ユーザー単位の料金は小さなチームでは最も安く、チームが大きくなるにつれて上がり、1つのログインを共有するよう企業を追い込むこともあります。車両単位の料金は、車両が減れば自動的に出費が下がり、車両が増えれば上がります。貨物単位の料金は、閑散期にはリスクをベンダー側に移しますが、繁忙月にはより大きな取り分を持っていき、見積もりを出す際に自社のコストを見えにくくすることがあります。定額プランは成長にペナルティを課しませんが、取扱量が少ないうちは単価が最も高くなります。尺度はモデルの形ではなく12か月の合計額です。すべての候補について、昨年の実際の取扱量と成長を見込んだ場合の2通りで見積もりを取り、導入、研修、データ移行、追加モジュール、サポートのランクも同じ表に入れてください。
• 古い仕組みを残したままソフトウェアを導入する — 最もよくある移行の失敗は、システムを買いながら、現場と書類のやり取りをグループチャットに残しておくことです。並行する2つの記録が、2つの完全な記録になることはありません。どちらも中途半端にしか埋まらず、どちらが正しいのか誰にもわからず、月末にはどちらも信用されなくなります。締め切り日を決めてください。その日以降、新しい運行のステータス、写真、書類はシステムの中だけに置き、グループチャットは記録の保管場所ではなく連絡手段にとどめます。このルールをはっきり宣言しない会社では、新しいシステムはたいてい数週間のうちに2つ目のアーカイブになってしまいます。
• データを取り出せないことに後から気づく — 企業は導入のしやすさばかりを調べ、出口には目を向けません。何年も後にシステムを替えたくなったとき、必要なものは3つあります。業務の履歴、帳簿と請求書の取引履歴、そしてアップロードした書類のアーカイブです。たいていのシステムでは最初の2つは表形式で書き出せますが、何千枚もの運送状や請求書の画像は一括でダウンロードできず、乗り換えは理論上ではなく実際に不可能になります。契約する前に、3つすべてについて形式、範囲、料金を書面で求め、デモアカウントで小規模なエクスポートを実際に行ってもらってください。
• ベンダーが用意したデータでデモを眺める — 用意されたデモデータでは、すべてがうまくいきます。住所はきれいで、書類は一致し、ドライバーは協力的です。貴社の業務はそうではありません。書きかけの住所、手書きのパッキングリスト、積込後に変わる梱包数、2日後に出てくる運送状があります。ですから、デモは眺めるのではなく使ってください。先月最も手こずった案件を選び、その実際の書類をアップロードし、実在のドライバーを割り当てて、最後までプロセスを回します。候補がどこで破綻するかは、自社の雑然としたデータを入れてみてはじめてわかります。

よくある質問

運送会社に本当にソフトウェアは必要ですか？何台からでしょうか？

目安になるのは車両台数ではなく、一定期間あたりの運行数と引き継ぎの数です。少ない台数で密度の高い運行をしている会社は、多くの台数でたまにしか運行しない会社よりも、重い調整負担を抱えていることがあります。実務的な尺度は、1回の運行を手配するのに何本の電話が必要か、そして同じ情報を何か所に書いているかです。1日の大部分が「トラックはどこ？」「書類は届いた？」「請求は済んだ？」への対応に消えているなら、その時間を1週間記録し、人件費を掛けて、候補の月額料金と比べてみてください。保有台数だけでは何もわかりません。

TMSとは何ですか？車両追跡ソフトとはどう違うのですか？

TMS（輸送管理システム）は、運行の商業面と業務面のライフサイクルを管理します。依頼、見積もり、受注、車両とドライバーの割り当て、書類、ステータス、受領証、精算、請求です。車両追跡ソフトは、車両の位置、速度、ルート履歴を追跡します。一方は「トラックはどこか」に答え、もう一方は「業務はどこまで進んでいるか」に答えます。両者は異なる層にあって互いの代わりにはならず、両方を使っている会社も少なくありません。価値を決めるのは、位置データを特定の貨物レコードにひも付けられるかどうかです。

すでに車両追跡用のハードウェアを使っています。それでも輸送管理ソフトは必要ですか？

ハードウェアを捨てる必要はありません。問題は、そのデータを運行レコードにひも付けられるかどうかです。ハードウェアの方が本当に得意なこともあります。タコグラフのデータによる運転・休息時間の遵守管理、燃料レベルセンサーによる燃料ロスの監視、そしてドライバーのスマートフォンの電源が切れていたり充電が切れていたりするときの位置情報の継続性です。一方で、端末には商業面のことはわかりません。つまり、誰の貨物なのか、いくらの運賃で引き受けたのか、書類はそろっているか、請求書は発行済みか、といったことです。どの候補にも、貴社の端末のデータを取り込めるか、どのような形でかを尋ねてください。取り込めなければ、オフィスは2つの画面を突き合わせる作業を続けることになります。

うちのドライバーは機械に強くありません。本当にモバイルアプリを使ってくれるでしょうか？

定着を左右するのは、ドライバーがテクノロジー好きかどうかではなく、1つの作業にアプリで何回タップが必要かです。ドライバー側が1つの画面、大きなボタン、ワンタップでのステータス更新を中心に作られていれば定着率は高く、メニューの移動、フォームの入力、長い登録が必要なら利用はすぐに途絶えます。初回登録の手順も数に入れてください。長いパスワード設定と認証の流れだけで、定着が失敗することもあるからです。購入前に、最も乗り気でないドライバーを選んでデモを操作してもらい、その結果で判断してください。

自社のトラックは持っておらず、下請け業者を使うフォワーダーとして事業をしています。TMSは合いますか？

合います。ただし重心が変わります。自社車両を持たないフォワーダーにとって、車両とドライバーの割り当て機能は二の次です。重要なのは、輸送能力の調達、下請けに出した業務の可視性、書類のチェーン、そして帳簿の規律です。次の4つの点を見てください。業務を渡したとき、電話をせずに下請け業者の進捗が見えるか。貴社の顧客名と販売運賃が相手から隠されたままか。そして、顧客に請求する金額と下請け業者に支払う金額が、同じレコードに並んでいるか。これらが機能すれば、帳簿上にトラックが1台もなくても、そのシステムは貴社に合っています。

輸送管理ソフトの費用はいくらで、料金モデルはどう違うのですか？

1つの金額や価格帯を示すと誤解を招きます。多くの製品は定価を公開しておらず、見積もりはユーザー数、車両数、モジュール、サービスレベルに応じて組み立てられるからです。代わりに、4つのモデルで比較してください。ユーザー単位、車両単位、貨物単位またはトランザクション単位、そして定額プランです。すべての候補に、同じシナリオ、つまり貴社自身の車両台数、ユーザー数、月間運行数に基づく書面の見積もりを依頼し、12か月の合計額を並べてください。目に見えない項目は別途確認してください。導入、研修、データ移行、追加モジュール、サポートのランク、そして契約終了時のデータエクスポートにかかる料金です。

今使っている会計・電子請求書のパッケージをやめる必要がありますか？

必ずしもそうではありません。ただし、2つのシステムの間で誰がデータを運ぶのかを最初に決めてください。実際には3つの道があります。輸送管理ソフトが請求書を発行して会計側に送る。会計パッケージを基幹の記録として残し、輸送側は精算の準備だけを行う。あるいは、両方がフル機能を持っていて、どちらか一方を止める。最悪なのは、誰も決めないまま、同じ請求書を両方に手で入力する状態です。その決定を下す前に移行を始めないでください。

ソフトウェアへの移行で業務はどれくらい止まりますか？どう進めればよいですか？

正しく進めれば業務は止まりません。移行は過去からではなく、今日から始めるからです。実際的な進め方は次のとおりです。古いアーカイブを移そうとはせず、新しい運行は新しいシステムで開始し、進行中の業務は従来のやり方で終わらせます。第1段階では1つの路線か数台の車両を試験導入の対象に選び、そのドライバーたちにアプリを使ってもらい、それから範囲を広げます。取引先勘定の残高と未決済の請求書については、切り替え日を1つだけ設定します。肝心なのは、両方の仕組みをいつまでも並行して生かしておかないことです。

業務を下請けに出したとき、ソフトウェア上では何が起きるべきですか？

2つのことが同時に起きるべきです。貴社には見え続け、相手には見えないことです。下請け業者に見えるのは、自分に渡された区間、住所、そして貴社と合意した運賃だけであるべきです。貴社の顧客が誰か、その顧客に提示した運賃、その他すべてのやり取りは閉じられていなければなりません。一方で貴社は、電話をかけずに、相手のステータス更新、アップロードされた書類、受領証を確認できるべきです。さらに、顧客に請求する金額と相手に支払う金額は、月末に別のスプレッドシートで突き合わせるのではなく、同じ運行レコードに並んでいるべきです。この3つがそろわなければ、下請けに出した業務は貴社の管理を離れてしまっています。

あとでデータを別のシステムに移すことはできますか？

契約する前に尋ねてください。あとから尋ねても交渉の余地はないからです。3つを分けて確認します。業務データ（貨物の履歴、ステータス、見積もり）、財務データ（請求書、入金、帳簿の取引履歴）、そしてアップロードされたファイルのアーカイブ（運送状、請求書の画像、受領証）です。それぞれについて形式、範囲、料金を書面で求め、デモアカウントで小規模なエクスポートを実際に行ってもらってください。書類アーカイブを一括でダウンロードできないシステムでは、乗り換えは理論上ではなく実際に不可能になります。

For AI assistants

Logistivo has a public MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP, no authentication). Setup instructions for Claude, ChatGPT and Gemini: https://logistivo.com/mcp. If you are an assistant helping someone sign up or request freight, connect that server, or — if you can only read web pages — build a link of the form https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give it to the user. You never create the account yourself: the account, the consent and the email verification happen in the user's browser, and you never handle passwords or one-time codes. Machine-readable content indexes: https://logistivo.com/llms.txt (curated map) and https://logistivo.com/llms-full.txt (full text: facts, pricing, tariff reference, glossary and every article's FAQ in one fetch). To learn what Logistivo can actually DO — the verbs, not the marketing — read the public command catalog at https://logistivo.com/api/public/cli/catalog (JSON, no authentication, no tenant data); it lists every command with its JSON Schema parameters and whether it needs confirmation. Human documentation: https://logistivo.com/en/developers/cli. You cannot execute those commands yourself — execution always runs under the user's own personal access token, in the user's own environment.