貨物業務のオペレーションセンター

依頼から配送まで、すべての貨物を一画面で。リアルタイムの位置情報、書類、メッセージ、ステータスがひとつのレコードに集約されます。

すべての貨物を一画面で——ステータス、ルート、日付で絞り込み

陸路とRoRoのリアルタイム追跡を、ドライバーアプリから直接

書類、メッセージ、ステータスが同じ貨物レコードにまとまります

依頼から請求書まで、ひとつのレコードで

すべてのステップが同じ貨物レコードの中で進みます。コピー＆ペーストも、書類の紛失もありません。

依頼

見積もり

承認

書類

通関

追跡

配送

請求書

すべてをひとつのレコードで

陸路も海路も、同じ地図で

位置情報はドライバーアプリが共有します。ボードを更新しなくても、すべての貨物の現在地がわかります。

ステータスが変わるたびに、即座に通知が届きます。

貨物の詳細を、1枚のカードに

個数、重量、容積を一か所に。ローディングメーターはシステムが算出し、パレットはお手元の端末で計測できます。寸法は自動で容積に換算されます。

個数、重量、容積を1枚のカードに集約。

ローディングメーター（LDM）は、入力した数値から自動で算出されます。

スマートフォンやタブレットでパレットを計測し、寸法を容積に換算。

貨物業務のすべてを、ひとつのコアで

可視化、追跡、通知、書類管理——バラバラのツールではなく、ひとつのシステムで。

• 一画面での可視化 — すべての貨物をひとつのリストに。ステータス、ルート、日付で数秒で絞り込み、必要な貨物をすぐに開けます。
• リアルタイム追跡 — 陸路とRoRoの輸送が、ドライバーアプリから届くリアルタイムの位置情報とともにボードに表示されます。
• ステータス通知 — 積込済み、通関中、輸送中、配送済み——ステータスが変わるたびに、関係者へ即座に通知が届きます。
• 混載・複数配送先 — 互いに分離された複数の荷口を1台の車両で輸送できます。ルートは自動で並べ替えられ、各貨物は別々のレコードとして管理されます。
• 公開範囲は貴社が決める — 依頼を誰に送るかは貴社が選べます。自社の運送会社リストのみ、除外した会社以外のすべて、またはその路線を扱うすべての運送会社から選択できます。
• 書類とメッセージをひとつのレコードに — CMR、インボイス、ATR、すべてのメッセージが貨物ごとのレコードに集まります。書類はAIが読み取り、項目を入力します。

連携するモジュール

ひとつのコア、ひとつのオペレーティングシステム——各モジュールのデータが次のモジュールへとつながります。

• 通関インテリジェンス — HS関税率・関税・アンチダンピング検索
• 倉庫・在庫 — 商品カタログ、パレット計測、在庫台帳
• AI — 書類読み取り・翻訳・関税分類・整合性チェックを担うAI
• メーカー・貿易会社 — 貴社の役割に合わせたソリューションページ

貨物業務を一画面に集約しましょう

依頼から配送までのすべてのステップを、ひとつの貨物レコードで管理。リアルタイム追跡、書類、ステータスがそろいます。

国際道路輸送で、貨物と書類の追跡をどのようにデジタル化すればよいですか？

順序立てて、そしてひとつの記録の上で進めます。最初にステータスフロー（貨物がどの段階にあり、誰がいつ更新したか）をデジタル化し、次に受領証（POD）と現場写真、続いてドライバー側のレイヤー、その次にリアルタイム位置情報へと進みます。書類アーカイブと外部連携は最後です。成否を分けるのは技術ではなくデータモデルです。位置情報、ステータス、書類、メッセージは、車両ではなく貨物の記録の下に置く必要があります——2社の顧客が1台のトラックを共有した瞬間、車両単位の記録では表示範囲を分けられなくなるからです。紙が完全になくなるわけではありません。条件付きで電子化できる書類もあれば、自社の路線ではいまだに紙で運ばれる書類もあります。進捗の尺度は、いくつの画面を導入したかではなく、貨物がどこにあるかを電話で尋ねなければならない場面がまだ何回残っているかです。

貨物と書類の追跡のデジタル化は、導入作業ではなく、順序づけの作業です。国際道路輸送では、データは3つの別々の場所で生まれます——オフィス（依頼、見積もり、受注）、運転席（ステータス、位置、配達）、そして国境（申告、随伴書類、スタンプ）です。この3つの発生源がつながるまでは、いくつ画面を導入しても意味がありません。多くの企業は、最も目に見えやすいところから始めます。車両追跡装置か、書類アーカイブです。どちらも堅実な投資ですが、順序を誤ると、日中に最も頻繁に聞かれる質問——この貨物はいまどの段階にあるのか——には、どちらも答えられません。

正しい順序は、安いものから高いものへではなく、効果が確実なものから不確実なものへと進みます。ドライバーが2回タップするだけで生まれるステータスの記録は、導入コストがほとんどかからないのに、オフィスにかかってくる電話の大部分を吸収します。リアルタイム位置情報は、同じ価値をすぐにはもたらしません。バッテリー、電波状況、権限設定、そして習慣に左右されるからです。書類アーカイブが役に立つのは、書類が発生したその瞬間に取り込まれている場合だけです。そのため、以下のレイヤーは意図的にこの順序で並べてあり、それぞれについて、どの手作業を置き換えるのか、どう測定するのか、どこで破綻するのか、何が必要なのかを示しています。

ページの後半では、多くの企業が飛ばしてしまう判断——記録を何に紐付けるか——を扱います。続いて、どの書類がどのような条件で電子化できるか（ルールは国、路線、時期によって異なるため、各項目は条件付きで記述しています）、現場で何が破綻するか、ベンダーの追跡機能に関する主張をデモでどう検証するか、そして実行可能な13週間の手順を紹介します。

• 最初のレイヤーは位置情報ではなくステータスです。「どこにある？」への答えは、たいてい座標ではなく段階——積込済み、通関中、輸送中、配送済み——だからです。
• 記録の単位は荷口（個々の貨物）にします。運行や車両を単位にすると、2社の顧客のデータがひとつの記録に入り、表示範囲を分けられなくなります。
• ステータスの記録に、誰が・いつ・どこから書き込んだかが表示されないなら、それはデジタルの記録ではありません——デジタル化された伝聞にすぎません。
• 書類はアーカイブからではなく、発生した場所で取り込みます。書類は現場、国境、通関業者のもとで生まれるものであり、後からかき集めたアーカイブには必ず欠けが出ます。
• 実際にどれだけ紙が減るかは、書類とルートによって異なります。自社の路線で確認していない電子的有効性の主張を前提に、業務フローを組み立ててはいけません。
• ドライバー側が空のままなら、システムは半分しかできていません。現場での入力がひとつの画面で完結しなければ、データは相変わらず電話でオフィスに届き続けます。

何を、どの順序でデジタル化するか——7つのレイヤー

• 1. ステータスフロー——最初の、そして最も安価なレイヤー — 貨物がどの段階にあるか——積込待ち、積込済み、輸送中、通関中、荷降ろし中、配送済み——を、ひとつの場所に、ひとつの形式で記録します。一覧は短く保ち、自社が実際に区別している段階だけに絞ってください。15段階のステータス一覧は、現場では3段階に縮んでしまいます。 日中に何度もかかってくる「どこにある？」という電話、配車担当者が個人のノートにつけている並行リスト、そして最新のメッセージを探してグループチャットをさかのぼる作業です。 1週間に受けた「この貨物はいまどの段階？」という問い合わせの件数を数え、変更後に同じ集計を繰り返します。2つ目の指標は、完了した運行のうち、ステータスの記録がすべてそろった状態で締めくくられたものがいくつあるかです。 オフィスがステータスを入力する場合です。オフィスは自分たちが思っていることを書き込み、現場の情報は遅れ、記録はたちまち信頼できなくなります。2つ目の失敗は一覧の肥大化です。2つのステータスの違いがわからないドライバーは、適当にどちらかを選んでしまいます。 貨物が単一のコードを持つ記録として存在し、ドライバーがその記録に紐付けられ、どのステップを誰が入力するかが書面で示されていることです。
• 2. 受領証（POD）と現場写真 — 配達が完了した証拠を集めます。署名済み書類の写真、配達時刻、貨物を受け取った人の氏名、そして必要に応じて貨物や機材の状態を示す写真です。このレイヤーが特殊なのは、やり直しがきかない点です——配達の瞬間に集めなかった証拠は、後から集めることができません。 何日もドライバーの運転席に置かれたままの紙の控え、帰着後にまとめてスキャンされる書類の山、そして損害をめぐるあらゆる紛争で耳にする「誰も写真を撮っていなかった」という一言です。 配達から書類がシステムに表示されるまでの時間（日単位ではなく時間単位で測ります）と、写真なしで完了した配達の割合です。 写真が貨物の記録ではなく、スマートフォンのギャラリーやチャットのスレッドに保存される場合。暗すぎて判読できない場合。貨物を受け取った人の氏名が記録されない場合。この3つのどれかひとつでも当てはまれば、その証拠は紛争の場で使えなくなります。 ドライバーの手元に使えるカメラがあり、積込時と荷降ろし時に数秒の時間を取れることです。機材の状態も追跡する場合は、前後の写真を撮るというルールを事前にチームへ周知しておく必要があります。
• 3. ドライバーのレイヤー——現場からのデータ入力 — 現場でのデータ入力そのものです。ドライバーが目にする画面、タップの回数、インターフェースの言語、そして登録の手順が対象です。これは機能の問題ではなく定着の問題であり、システムの半分はここで埋まります——オフィス側をどれほどうまく設定しても、現場側が空なら記録は不完全なままです。 オフィスとドライバーの間で交わされる音声での調整の大半と、電話で聞いた内容を配車担当者が入力し直す作業です。 アクティブドライバー率（アプリから少なくとも1回更新を送ったドライバー数 / 全ドライバー数）と、運行の各ステップのうち、オフィスではなく現場から入力されたものがいくつあるかです。 長い登録とパスワード設定の手順、多国籍のチームなのに単一言語のインターフェース、現場に求める入力項目の肥大化、そして電波の届かない地域です。オフラインキュー（圏外時の送信待ち機能）がなければ、接続が切れている間に入力した更新は送信できず、ドライバーは入力をやり直さなければなりません。 ドライバーの端末にアプリがインストールされ、アカウントが使える状態にあり、どのステップを誰に期待するかについて明確なルールがあることです。ドライバー自身にとってのメリットも必要です。配車の詳細、住所、書類がスマートフォンで見られることなどです。
• 4. リアルタイム位置情報 — 車両またはドライバーの位置を貨物の記録へ継続的に送り、ルート上に表示します。位置情報はひとつの答えですが、それだけでは十分ではありません。顧客が求めているのは座標ではなく、到着時刻です。 ドライバーに電話して現在地を尋ねることと、オフィスが自分たちの推測にもとづいて顧客に到着時刻を伝えることです。 位置情報の連続性です。運行のうちどれだけの割合で位置情報が実際に届いているか、途切れはどのくらいの長さで、どこで発生しているか（電波状況、バッテリー、権限、アプリの終了）を確認します。 スマートフォンのバッテリー、オフにされたバックグラウンド位置情報の権限、電波の空白地帯、そしてその時点で運んでいる貨物に紐付けられないまま車両の記録に書き込まれる位置情報です。位置情報は慎重に扱うべき個人データでもあります。何を、いつ、なぜ収集するのかを、ドライバーにわかりやすく伝えなければなりません。 アプリがインストールされてその運行に紐付けられていること、バックグラウンド位置情報の権限、そして勤務時間外や運行と運行の間に共有がどう扱われるかについての書面のルールです。
• 5. 書類の取り込み——発生した場所で — 各書類を、それが生まれる場所で取り込みます。積込地ではパッキングリストと運送状の控え、国境では随伴書類とMRN、通関業者からは申告書の出力、売り手からは請求書です。書類が発生する場所がどこであれ、デジタル化はその場所に組み込まなければなりません。 運行が終わってからフォルダーをスキャンすること、メールの添付ファイルから書類を探し回ること、同じファイルを3か所にコピーすることです。 完了した運行のうち必須書類一式がそろっているものの件数と、特定の書類を見つけるのにかかる平均時間です。 種別を付けずにアップロードされた書類（すべてが「その他」になり、後から何も見つけられなくなります）、貨物とは無関係なフォルダーツリーとして作られたアーカイブ、そして過去分の一括スキャンプロジェクトを最優先にすることです。最後のものは多くの企業で頓挫し、その間は新しい書類も集められません。 定義済みの書類種別、現場と通関業者にまで広げたアップロード権限、そして判読できる解像度の写真です。
• 6. 関係者への可視化 — 貨物に関わるすべての関係者を、それぞれの役割で同じ記録に紐付けます。荷送人、運送会社、利用する場合は下請運送会社、荷受人、通関業者です。各関係者に見える内容は役割によって異なるべきであり、その切り分けは「初期状態では非公開」を基本にすべきです。 顧客に向けて手打ちするステータス報告メール、通関業者へ1通ずつ転送する書類、そしていつ届くのかを尋ねてくる荷受人からの電話です。 手動で送信するステータス報告メールやメッセージの件数の変化と、顧客から寄せられる問い合わせの件数です。 すべてを全員に公開してしまう（価格や他の顧客の情報が漏れる）か、まったく何も公開しない（電話のやり取りが変わらず続く）ことです。3つ目の誤りは、運行の完了後もアクセスを無期限に開いたままにすることです。 正確な取引先台帳と、どの役割に何を見せるかについて事前に下した決定です。
• 7. 業務運用から請求へ — 運行データを請求と照合につなげます。運んだ貨物、追加料金、待機時間、通貨、日付がすべてひとつの記録から取り出されます。デジタル化の効果が金額で測られるのは、このレイヤーです。 月末に業務側のリストと経理側のリストを並べて手作業で突き合わせることと、誰も覚えていなかったために請求書に載らない追加料金です。 月次の締めに何日かかるかと、請求書に反映されなかった追加料金の件数です。 業務と経理が別々の2つのシステムで運用され、両者の照合が共通のコードではなく人の記憶に頼っていることです。 貨物の記録で価格と追加料金の項目が実際に使われていることと、経理側が同じ貨物コードを認識できることです。

すべてを左右する判断：記録を何に紐付けるか

デジタル化がうまくいくかどうかを決める唯一の判断は、データを何に紐付けるかです。同じ情報でも、車両、運行、顧客のどれの下に記録するかによって、まったく異なる3つのシステムが生まれます——しかも、これは後から覆すのに最もコストがかかる判断です。以下の6つのルールは、その判断を国際道路輸送の実務に落とし込んだものです。

• 記録の単位は車両ではなく荷口 — 貨物の記録は1件の輸送業務を表します。2社の顧客の貨物が同じトラックで運ばれるなら、記録も2件でなければなりません。車両や運行を中心に作られたシステムは両者をひとつにまとめてしまい、一方の顧客が他方の住所、貨物、書類を見てしまうことがあります。混載を扱っているなら、これは好みの問題ではなく必須要件です——また、貸切輸送であっても、運行を下請運送会社に回した瞬間に同じ必要性が生じます。
• 位置情報とステータスは貨物の記録に書き込む — 装置やスマートフォンから届く位置情報は、ナンバープレートではなく、運ばれている貨物の記録に紐付けるべきです。ナンバープレートごとに書き込まれた位置情報は、実際に問われている質問に答えられません。誰もトラックの居場所を知りたいわけではなく、特定の荷口がいつ届くのかを知りたいのです。タコグラフや燃料のデータにも同じ基準が当てはまります——それ自体に価値はあっても、運行に紐付けられて初めて業務上の答えになります。
• すべてのステータス記録に記入者情報を残す — ステータスを誰が、いつ、どのチャネルから（現場からか、オフィスからか）書き込んだのかが、記録上で見えなければなりません。記入者情報のないステータスは紛争の場で何も証明できず、チームもやがてそれを信用しなくなります。編集はできても履歴が残る記録のほうが、編集はできないが誰も入力しない記録よりも優れています。
• 関係者は個人ではなく役割で紐付ける — 荷送人、運送会社、下請運送会社、荷受人、通関業者は、それぞれの役割で記録に紐付けるべきです。アクセス権が個人のメールアドレスに結び付いていると、その人が退職したときに表示範囲が失われ、アーカイブは宙に浮き、引き継ぎは手作業になります。役割ベースで紐付ければ、「誰が何を見られるか」を貨物ごとに毎回議論し直す必要もなくなります。
• 識別子はひとつ：貨物コード — 1件の貨物にはひとつのコードを持たせ、書類、メッセージ、位置情報、受領証、請求書をすべてそのコードに紐付けるべきです。業務上のファイル番号と経理上の請求書番号という2つの採番体系がつながっていないと、月末の照合は手作業の突き合わせに成り下がります。顧客にもそのコードを伝えておけば、問い合わせを受けたときに検索できます。
• 表示範囲は初期状態で非公開 — アクセス権は明示的に付与するものであり、ひとりでに生じてはなりません。国際輸送では、同じ貨物の周りに互いに競合しうる関係者がいます。誰が何を見るかは貨物を登録する時点で決め、業務が終わればアクセスを閉じるべきです。これは商業上の安全策であると同時に、個人データの観点からも正当性を説明できる初期設定です。

書類のレイヤー：何を電子化でき、その条件は何か

実際にどれだけ紙がなくなるかは、書類、ルート、当局によって異なります。「もうすべて電子化された」というひとつの答えはありません。下の表は、国際道路輸送でよく見られる書類に電子的な形式があるかどうか、そしてその形式が何に左右されるかをまとめたものです。ルールは国によって異なり、時とともに変わるため、すべての項目は条件付きです。

このセクションは情報提供のみを目的としており、法的助言ではありません。これをもとに業務フローを組み立てる前に、自社のルートについての状況を、税関当局、会計士、または運送業界団体に確認してください。どの輸送にどの書類が必要かは、別途「輸送書類チェックリスト」で解説しています。

• CMR運送状 — 電子形式あり——関係国と当事者の合意が条件. 2008年に採択された、電子運送状に関するCMR条約の追加議定書により、e-CMRが可能になりました。利用するには、ルート上の国々がこの議定書の締約国であり、運送契約の当事者が電子運送状を受け入れる必要があります。締約国のリストは時とともに拡大しています。 実務上は移行期間にあります。ドライバーがルートの途中で、紙の控えを求める検査官に出会うこともまだあります。電子的なフローに切り替える前に、自社の路線上のすべての国の状況と、相手方が受け入れるかどうかを確認してください。スキャンした控えを貨物の記録に保管しておけば、紙がまだ輸送中であっても、オフィスと通関業者は手続きを進められます。
• 通過申告（T1/T2）と通過随伴書類 — すでに電子化済み——申告は当局のシステムに提出. 共通通過手続では、申告は電子的に提出されます（NCTS）。貨物とともに運ばれるのは申告そのものではなく、MRN（movement reference number：移動参照番号）が記載された通過随伴書類です。 ここでやるべきことは、申告をデジタル化することではなく、MRNと随伴書類を貨物の記録に紐付けることです。MRNが記録上で検索できるようになれば、国境から寄せられる質問の大半に、ドライバーが書類を探して撮影するのを待たずにオフィスから答えられます。
• 輸出・輸入申告 — すでに電子化済み——当局のシステムに提出. 申告は所轄の税関当局の電子システムに提出され、通常は通関業者が作成します。申告番号は、出域書類や随伴書類がある場合はそれらとあわせて、その輸送の識別情報となります。 デジタル化するのは申告そのものではなく、その番号と出力書類を貨物の記録に紐付ける作業です。通関業者が同じ記録に書類を直接アップロードできるようにすれば、本来なら行き来するはずのメールのやり取りがなくなります。
• 商業送り状（インボイス） — 電子形式が広く普及——対象範囲は国や納税者によって異なる. トルコでは、e-Fatura（電子請求書）とe-Arşiv（電子アーカイブ請求書）の制度の対象範囲が税務当局の通達によって定められており、売上高の基準や業種によって異なります。欧州連合（EU）では、公共調達における電子請求書の標準が定められている一方、より広範な義務化については加盟国がそれぞれのスケジュールで進めています。 自社が対象に含まれるかどうかは、会計士に相談し、当局の最新のルールを確認してください。対象範囲は拡大を続けているため、1年前の情報では判断を誤るおそれがあります。業務側でやるべきことは、貨物の記録から請求書を作成でき、発行した控えを同じ記録に保管できるようにすることです。
• 国内出荷伝票（ウェイビル） — トルコには電子形式あり（e-İrsaliye）——対象範囲は規則で定められる. e-İrsaliye制度の対象と適用除外は税務当局の通達によって定められており、対象範囲は時とともに拡大してきました。 国際輸送において、出荷伝票が関わるのは国内区間です。国境を越える移動のための書類は運送状です。一方を他方の代わりに使わないでください。また、自社が対象に含まれるかどうかは会計士に確認してください。
• 移動証明書・原産地証明書（A.TR、EUR.1、原産地証明書） — 一部電子化——協定や国によって異なる. これらの書類には、承認や査証（裏書）の手続きが必要です。電子的な発給と検証を運用している国もあれば、いまだに押印された紙の書類を求められる路線もあります。特恵原産地を証明書ではなく輸出者の申告によって証明する制度も広がりつつあります。 自社の路線でどの形式が受け入れられるかは、輸送の前に確認してください。スキャンした控えを貨物の記録に保管しておけば、紙の原本が輸送中でも、通関業者や荷受人とのやり取りを止めずに進められます。
• パッキングリスト、計量票、貨物明細 — 自由形式の商業書類——電子的に保管するうえで一般的な障害はない. これらは当事者間の商業書類であり、その形式は契約と買い手の要望によって決まります。税関が申告の添付書類として求めることがあるため、判読できる控えを常に手元に置いておくべきです。 最もデジタル化しやすく、効果が最も早く表れるグループです。梱包数、総重量と正味重量、容積を貨物の記録にデータとして入力すれば、積載メートルや車両の適合性の計算も手作業でする必要がなくなります。
• 受領証、現場写真、ADR書類、ドライバー・車両の書類 — 業務上の証拠は電子化可能——法的な証拠は書類によって異なる. 法的な配達の証明は、通常、荷受人が署名した運送状の控えです。アプリ内での確認や写真は業務上の強力な証拠ですが、契約で裏付けられていない限り、紙の代わりになるとは考えないでください。ADRの対象となる輸送では、ドライバーが携行しなければならない書類（書面による指示書を含む）の電子版が認められるかどうかは、国によって異なります。 すべての配達で写真とタイムスタンプを記録してください。費用はかからず、紛争の際には大きな価値を持ちます。ドライバーと車両の書類の有効期限をシステムで管理すれば、期限切れの書類に国境で気づくというリスクの大半をなくせます。

どこで破綻するか——デジタル化を後戻りさせる6つの状況

• 切り替え日を決めていない — デジタル化はたいてい、ソフトウェアを導入した日ではなく、古いチャネルが記録の正本でなくなった日に始まります。日付を告知しないと、2つの記録がしばらく並行して運用されます。どちらも不完全になり、チームはどちらが正しいのか判断できず、信頼できるチャネル——電話——に戻ってしまいます。現実的な方法は、まずひとつの路線またはひとつの顧客に切り替え日を適用することです。その路線では、ステータス、写真、書類はシステムの中だけで管理し、チャットは記録の正本にはせず、あくまで連絡手段として使います。
• テレマティクスのデータが孤立したまま — 追跡装置、タコグラフ、燃料センサーはそれぞれのポータルの中では正しく動作しますが、質問が寄せられるのは業務の側です。データが運行に紐付いていないと、オフィスは一日じゅう2つの画面の橋渡しに追われます。しかも、装置提供会社のポータルにアクセスできる人は少ないため、知識は1人か2人に集中してしまいます。ハードウェアの入れ替えを検討する前に、そのデータをどのような形で取り出せるのか——リアルタイムのアクセスか、ファイルか、それともまったく取り出せないのか——を確認してください。この質問ひとつで、連携が可能かどうかがおのずと決まることも少なくありません。
• 必須項目が徐々に増えていく — 新しい要件が出るたびにフォームの項目が増え、半年後には現場が何も入力しなくなります。システムが現場に求める内容は、そのデータで答える質問の範囲を超えるべきではありません。誰も見ない項目はコストを生むだけです。有効な見直し方法として、必須項目ごとに「これが空欄のままだと、どの判断ができなくなるか」を問い、答えのない項目はすべて任意にします。
• 導入が1人の担当者に依存している — デジタル化は、たいてい1人の熱心な担当者が担っています。その人が休暇を取ったり異動したりすると、流れが止まってしまいます。少なくとも2人が、システムを設定できるほど深く理解している必要があります。さらに重要なのは、下した決定——ステータス一覧、書類種別、誰が何を見るか、切り替え日——を書面に残し、どこかに保管しておくことです。文書化されていない導入は、1年後に誰も説明できない設定を残すことになります。
• データが一方向にしか流れない — システムに入れたものを取り出せないなら、デジタル化は2年目に新たなアーカイブ問題に変わります。3つの出力を別々に検討してください。業務履歴、会計・勘定の取引履歴、そして書類の画像です。たいていのシステムは、最初の2つを表形式で出力できます。本当のボトルネックは3つ目です。何千件もの書類画像を一括でダウンロードできなければ、移行は技術的に不可能なのではなく、実質的に不可能になります。
• 顧客向けの窓口を開かない — 社内業務はデジタル化されても、外部に向けた窓口は以前のままです。顧客は相変わらず電話をかけ、荷受人はメールを送り、通関業者は書類を求めてきます。そうなると、節約できた時間の大部分が外部への情報の中継に費やされ、チームは「デジタル化はうまくいかなかった」と結論づけてしまいます。公開する範囲は小さくてかまいません。ステータス、到着予定、関連書類です。価格や他の顧客の情報は見えないようにすべきです。

ベンダーの追跡機能に関する主張をデモで検証する6つの方法

• 「当社のシステムは、御社の貨物をリアルタイムで追跡します。」 — デモでは、地図上の点として表示される車両1台で満足しないでください。特定の貨物の記録を開いてもらい、位置情報がそこから来ていることを示してもらいます。そのうえで、厳しい質問をします。2社の顧客の貨物が同じトラックに積まれている場合、それぞれの顧客には何が見えるのか？位置情報が貨物ではなくナンバープレートに紐付いているなら、返ってくる答えは「どちらにも同じものが見えます」か、話題のすり替えのどちらかです。 位置情報がどの記録に書き込まれるのかを明確に説明できないこと、そして混載のシナリオを「その場合は個別に開発します」とかわされること。
• 「ドライバーアプリは現場でも問題なく動きます。」 — 端末を機内モードにして、ステータスの更新と写真をそれぞれ1件送信してみてから、接続を元に戻します。更新は送信待ちに入ってから送られるのか、失敗して消えてしまうのか、それともドライバーが最初から入力し直さなければならないのか？国際路線では、電波の空白地帯は例外ではなく日常的なものです。 その質問に「たいてい電波は入ります」と答えられ、オフライン時の動作がどこにも文書化されていないこと。
• 「すべての書類がシステムに集約されます。」 — 自社で最も読み取りにくいスキャン書類をアップロードし、2つの点を確認します。その書類は貨物の記録に入ったのか、それとも汎用のアーカイブに入ったのか。そして種別は正しく選択されたか。次に、その書類を顧客が見られるかどうかを誰が決めるのかを尋ねます——書類ごとに設定するのか、それとも全体共通のひとつの設定で決まるのか？ 書類の表示範囲が全体共通のひとつの設定で決まること、書類種別の一覧を変更できないこと、誤って割り当てられた種別を後から修正する方法がないこと。
• 「御社のお客様が、ご自身で輸送状況を追跡できます。」 — 顧客の視点の画面を開いてもらい、何が見えるのかを正確に列挙してもらいます。ステータス、到着予定、書類。価格は見えるか？自社の他の貨物は見えるか？そのアクセスがいつ閉じるのかも確認してください。運行後も無期限に開いたままのアクセスは、可視化ではなく情報の露出です。 デモで顧客側の画面をまったく見せられないこと、「同じ画面が見えます」という回答、アクセス期間について明確なルールがないこと。
• 「御社の既存の追跡装置と連携します。」 — 契約前に、小規模なライブサンプルを実施してください。車両1台分の1日のデータを実際に転送してもらいます。そして4つの回答を書面で受け取ります——誰が構築するのか、データはどの形式で届くのか、費用はかかるのか、装置提供会社がそのアクセスを許可するのか。この4点が書面になっていなければ、その連携は日付の決まった計画ではなく、ただの願望です。 連携が「ロードマップにあります」と説明され、装置提供会社とのアクセスについて一度も話し合われていないこと。
• 「導入は1週間で完了します。」 — 導入作業のうちどの部分が自社の担当になるのかを、書面で項目ごとに尋ねてください。会社情報と取引先台帳、ユーザーと権限、書類種別、ドライバーの端末、導入時のトレーニング、データの整理などです。そのうえで、そのリストを自社チームの週あたりの業務量と照らし合わせます。導入を遅らせるのは、ほとんどの場合、ベンダーが担当する部分ではありません。 導入作業はすべてベンダー側が担うと言われ、購入者側の準備リストが一度も提示されないこと。

3つのアプローチ：グループチャット、車両中心の追跡、貨物中心のシステム

• グループチャットとスプレッドシート（デジタルツールはあるが、デジタル化はされていない） — 取扱量がごく少なく、路線がひとつで、1人で運営している場合に向いています。導入コストはゼロで、全員がすでにそのツールを使っており、初日から機能します。関係者が少なく取扱量が不定期であれば、本当にこれで十分な場合もあります。 習得の手間がかかりません。チームもドライバーも、すでに毎日そのツールを使っています 追加コストがかからず、導入プロジェクトにも依存しません 柔軟です。標準から外れた状況も自由記述で説明できます 記録を検索できません。情報はメッセージの流れの中に埋もれ、最終的には1人の記憶の中にしか残りません 同じ情報が複数の場所で繰り返され、どれが最新版なのかがわからなくなります 外部に対して、管理された表示範囲を提供できません。すべてを共有するか、何も共有しないかのどちらかです 担当者が辞めると、履歴もその人とともに失われます。紛争の際に証拠を示すのも困難です
• 車両中心の追跡（テレマティクス / フリート管理ソフトウェア） — 自社で車両を保有・運用している企業と、車両に属する問い——運転時間規制の遵守、燃料のモニタリング、整備計画、位置情報の連続性——に向いています。こうした問いには、ハードウェアベースのソリューションに代わるものはありません。 位置情報の連続性はハードウェアによって確保されます。ドライバーのスマートフォンやそのバッテリーには左右されません タコグラフや燃料の読み取り値など、装置からしか得られないデータを生み出します 車両関連コストの分析やドライバーの運転傾向の把握に強みがあります 記録の単位は車両です。貨物のステータス、書類、関係者には、このモデルの中に自然な置き場所がありません 混載では、1台のトラックを共有する複数の顧客の表示範囲を分けられません 傭車や下請運送会社による運行は、追跡の対象範囲から外れてしまいます 顧客に公開できる画面がたいていないか、あっても必要以上の情報を見せてしまいます
• 貨物中心の業務システム — 複数の顧客や複数の運送会社と取引している企業、混載を扱う企業、そして「トラックはどこか」ではなく「この貨物はどの段階にあるか」が問われるあらゆる業務に向いています。書類や関係者との調整が一日の大半を占める現場ほど、効果がはっきり表れます。 ステータス、位置情報、書類、メッセージがひとつの記録に集まるため、情報をつなぎ合わせる作業を人が毎日やり直す必要がありません 関係者が役割で紐付けられるため、表示範囲を貨物ごとに調整できます 業務データを請求や照合に直接つなげられます 下請運送会社や傭車による運行も、同じモデルの中で扱えます 位置情報の取得元は製品によって異なります。ドライバーのアプリに頼るシステムは、それ単体ではハードウェア並みの連続性を得られませんが、装置との連携を提供するシステムなら得られます——候補ごとにどちらなのかを確認してください 現場から何も届かなければ、記録は半分しか埋まりません——このモデルでは定着がクリティカルパスです タコグラフ、燃料、整備といった車両固有のニーズには、別のソリューションか連携が必要です

よくある6つの誤解

• デジタル化とは、トラックに追跡装置を取り付けることです。 — 追跡装置が教えてくれるのは車両の居場所です。しかし、業務の現場が実際に知りたいのは、貨物がどの段階にあり、いつ到着するかです。装置はその答えを得るための入力のひとつであって、答えそのものではありません。ステータスフローにはハードウェアも取り付け作業も追加のサブスクリプションも不要なため、最初の測定可能な成果に至る最短ルートであることがほとんどです。
• システムを導入すれば、紙はなくなります。 — 条件付きで電子化できる書類もあれば、自社の路線ではいまだに紙で運ばれる書類もあります。現実的な目標は紙をなくすことではなく、紙を唯一の控えにしないことです。そうすれば、書類を探すのにドライバーの運転席にあるフォルダーを頼る必要がなくなります。
• まず過去のアーカイブをすべてスキャンして、それからシステムに移行しましょう。 — 過去分の一括スキャンプロジェクトは多くの企業で頓挫し、その間は新しい書類も集められません。順序は逆です。今日以降に発生する書類をその発生地点で取り込み、過去のファイルは必要に応じて選択的に追加します。
• リアルタイム位置情報があれば、顧客から電話がかかってこなくなります。 — 顧客が求めているのは座標ではなく、確約です。今日中に荷降ろしされるのか、通関でどれくらい止まるのか、何時に到着するのか。位置情報はその答えの材料であり、答えそのものはステータス、到着予定、そして遅延の通知です。地図は共有しても通知を一度も設定しない仕組みでは、答えを導き出す作業を顧客に任せることになります——だからこそ、電話はかかってき続けるのです。
• 保有台数が少なければ必要ありません。電話で十分です。 — 重要なのは車両の台数ではなく、関係者の数です。トラックが1台しかなくても、荷受人、通関業者、顧客と仕事をすれば調整の負担が生じます。とはいえ、すべての企業にフル機能のシステムが必要なわけではありません。ステータスフローと受領証のレイヤーは、それだけを単独で導入できる最小のステップです。
• すべてを一度に有効にしましょう。チームはそのうち慣れます。 — 大量の新しい入力項目を一度に有効にすると、たいてい現場はそのどれも入力しなくなります。レイヤーごとに進める企業は、各ステップで測定可能な成果を示せるため、チームを説得しやすくなります。測定がなければ、議論は「良くなった気がする」対「悪くなった気がする」のレベルにとどまります。

各段階に測定可能なチェックを設けた13週間の手順

以下の手順は優先順位の提案であり、スケジュールの約束ではありません。所要期間は、企業の取扱量やチームが割ける時間によって変わります。変わらないのは、どの段階も手で数えられるチェックで締めくくるという点です——数字がなければ、進捗はいつまでも議論の余地を残します。

• 第0〜2週——単一路線でのパイロット — ひとつの路線またはひとつの顧客で、ステータスフローを機能させます。 自社が実際に区別しているステータス一覧を書き出します。5〜7段階に収めてください パイロット路線を選びます。取扱量が安定し、関係者が顔なじみで、想定外の事態が少ない路線です 貨物をシステムに登録し、すべての運行に単一のコードを付けます どのステップを誰が入力するかを書面で周知します パイロット期間の1週間で、システム上のステータス記録とともに完了した運行はいくつあり、いまだにチャットで追っていた運行はいくつあったか？両方を手で数えて書き留めます。
• 第3〜5週——現場のレイヤー — ドライバーがステータス、受領証、写真を現場から直接送信します。 最も消極的なユーザーと一緒にアプリをインストールし、何分かかるかを計測します 現場に求める入力を最小限に絞り、すべての必須項目に「これが空欄だと、どの判断ができなくなるか」というテストをかけます 配達時の写真撮影と受取人の氏名の記録をルールにします 電波の空白地帯があるルートで何が起きるかを書き留めます アクティブドライバー率（少なくとも1回更新を送ったドライバー数 / 全ドライバー数）と、配達から書類がシステムに表示されるまでの平均時間（時間単位）。
• 第6〜9週——書類と関係者 — 書類を発生した場所で取り込み、顧客と通関業者に表示範囲を開放します。 書類種別を定義し、「その他」は例外扱いにします 通関業者が貨物の記録に書類を直接アップロードできるようにします 顧客に見せる内容を決めます。ステータス、到着予定、関連書類を見せ、価格と他の貨物は除外します MRNと申告番号を貨物の記録上で検索できるようにします 完了した運行のうち、必須書類一式がそろっているのはいくつか？手動で送信したステータス報告メールの件数は、パイロット前の期間と比べてどう変化したか？
• 第10〜13週——切り替えと経理との連携 — 古いチャネルを記録の正本から外し、業務データを請求につなげます。 切り替え日を告知します。その日以降、記録はシステムの中で管理し、チャットは連絡手段としてのみ使います 残りの路線も、パイロットと同じ設定で取り込みます 追加料金、待機時間、通貨を貨物の記録に入力することをルールにします エクスポートの手順を一度試します。対象は業務履歴、会計の取引履歴、書類の画像です 月次の締めに何日かかったか、請求書に反映されなかった追加料金はいくつあったか？そして最もシンプルな質問として、「うちの貨物はどこ？」という電話の件数は、最初の週と比べてどうなったか？

この手順の中でのLogistivoの位置づけ

Logistivoは、このページで解説したモデルを製品として実装した物流オペレーションシステムです。記録の単位は車両ではなく貨物であり、ステータス、位置情報、書類、メッセージは同じ貨物の記録に集約されます。ドライバーはiOSおよびAndroidアプリから、ステータスの更新、位置情報の共有、書類の写真の送信を記録に対して直接行えます。ステータスが変わるたびに、関係者へ通知が届きます。混載では、同じトラックに積まれた荷口ごとに別々の記録となり、チャット、書類、ステータスは互いに切り離されたまま保たれます。一方、複数の立ち寄り地を経由する運行はひとつの記録で進みます。関係者（荷送人、運送会社、下請運送会社、荷受人、通関業者）はそれぞれの役割で記録に紐付けられ、誰が何を見られるかは、その貨物を登録した関係者が決めます。書類は種別を付けてアップロードされます。AIが項目を読み取ってフォーム上に候補として提示し、それらは保存される前に承認を経ます。業務データは、同じコアから請求と取引先勘定につながります。クレジットカード不要で、無料で始められます。

テレマティクス、タコグラフ、燃料センサーとの連携はありません。位置情報はドライバーのスマートフォンから取得するため、スマートフォンの電源が切れている場合や、バックグラウンドでの位置情報の権限が一度も許可されていない場合は、位置情報が届きません。アプリにはオフラインキューがありません。圏外で送信しようとした更新は、接続が回復するまで送信できません。複数当事者による電子署名（eCMRの署名フロー）はまだありません——書類は記録に添付・保管されますが、システム内で署名されることはありません。この機能はロードマップに含まれています。アカウントを持たない関係者が開ける公開追跡リンクはありません。荷受人や顧客は、関係者として記録に紐付けられます。到着予定はシステムが算出するものではありません。関係者が入力した日付（または書類から読み取って承認した日付）です。過去の運行から学習する予測モデルはありません。一部の操作ではクレジットを消費します。貨物または見積もりでは車両1台につき1クレジット、関税率検索1回につき1クレジットです。クレジットはプランの年間クレジット枠から差し引かれます。追加クレジットの単体販売はなく、枠を使い切った場合は上位のプランに移行します。取扱量の多い事業者は、この消費量を踏まえて最初からプランを選ぶべきです。

よくある質問

貨物はどのように追跡しますか？

ボードを開くと、すべての貨物がステータスチップ付きで一覧表示されます。貨物をクリックすると、ルートのタイムライン、リアルタイム位置、書類、メッセージがひとつの画面に表示されます。

陸路と海路は同じ画面で確認できますか？

はい。陸路とRoRo（海上）の輸送は、同じステータスの流れで同じボードに表示されます。海上区間と陸上区間は、ひとつの貨物レコードにまとめられます。

ドライバーの位置情報はどのように届きますか？

ドライバーがiOSまたはAndroidアプリから位置情報を共有します。位置情報は貨物のレコードに記録され、ボード上にリアルタイムで表示されます。ステータスの更新や書類の写真も、同じアプリから届きます。

複数の顧客の貨物を1台の車両で運べますか？

はい。混載機能を使えば、互いに分離された複数の荷口を1台の車両で輸送できます。各荷口は別々の貨物レコードとして管理され、チャット・書類・ステータスは互いに分離されたまま、ルートは自動で並べ替えられます。

依頼は誰に表示されますか？

依頼の作成時に貴社が選びます。自社リストの運送会社のみ、除外した会社以外のすべて、またはネットワーク上でその路線を扱うすべての運送会社です。自社リストにその路線を扱う運送会社がいない場合は、依頼が回答されないままにならないよう、ネットワーク上の条件に合う運送会社に公開されます。

貨物と書類の追跡をデジタル化するとき、どこから始めるべきですか？

ステータスフローから始めてください。貨物がどの段階にあるかをひとつの場所に、ひとつの形式で記録することは、導入コストが最も低く、効果が最も早く目に見えるステップです。日中の「どこにある？」という電話の大半を吸収してくれます。次が受領証（POD）と現場写真、その次がドライバー側での定着、そしてリアルタイム位置情報です。書類アーカイブと外部連携は最後に回します。ひとつの路線またはひとつの顧客でパイロットを行うほうが、業務全体を一度に変えるよりも早く、後戻りもしやすくなります。

すでに車両追跡システムがあります。それでも貨物追跡ソフトウェアは必要ですか？

両者は異なる問いに答えるものです。追跡装置が教えてくれるのは、車両の居場所、燃料の使用量、運転時間の記録の内容です。一方、貨物追跡が管理するのは、特定の荷口がどの段階にあるか、その書類がそろっているか、どの関係者が何を見るかです。2社の顧客の貨物が1台のトラックを共有した瞬間、車両単位の記録では足りなくなります。問うべきは「どちらを選ぶか」ではなく、既存の装置のデータを貨物の記録に紐付けられるかどうかです——両方のベンダーに、まさにその点を尋ねてください。

e-CMRとは何ですか？紙の運送状を完全にやめることはできますか？

2008年にCMR条約に加えられた追加議定書により、運送状を電子的に発行できるようになりました。これに依拠するには、ルート上の国々がこの議定書の締約国であり、運送契約の当事者が電子運送状を受け入れる必要があります。締約国のリストは時とともに変わってきました。実務上は移行期間にあり、ドライバーが紙を求める検査官に出会うこともまだあります。業務フローを組み立てる前に、自社の路線についての状況を税関当局と相手方に確認してください。

ドライバーが使ってくれなかったらどうなりますか？定着させるにはどうすればよいですか？

現場から何も届かなければ、システムの半分は空のままとなり、オフィスは以前とまったく同じように電話でデータを集めることになります。効果があるのは次の3つです。現場での入力をひとつの画面で完結させること、現場に求める内容を最小限に絞ること、そして最も消極的なドライバーで設定を試すことです。ドライバー自身にとってのメリットも必要です——配車の詳細、住所、書類がスマートフォンで見られること、そして作業を中断される回数が減ることです。監視だけを目的に導入されたシステムは現場の抵抗にあい、不完全なデータしか集まりません。

まず過去の書類をスキャンすべきですか？

いいえ。今日以降に発生する書類を、それが生まれる場所——積込地、国境、通関業者のもと——で取り込んでください。過去分の一括スキャンプロジェクトは多くの企業で頓挫し、その間は新しい書類も集められません。過去のファイルは必要に応じて選択的に追加できます。たいていは直近1年分と、係争中の紛争に関わるものがあれば十分です。

顧客は輸送状況をどのように確認できますか？アカウントは必要ですか？

システムが表示範囲を提供する方法は2通りあります。相手方が自分のアカウントで接続する方法と、アカウントなしで開ける共有リンクです。それぞれに一長一短があります——リンクは手軽ですが、入手した人なら誰でも内容を見られます。アカウントは管理が行き届きますが、相手側にひと手間を求めます。どちらを使う場合でも、次の2つの問いに前もって答えておいてください。外部にどこまで見せるのか、そしてアクセスはいつ閉じるのか。

混載で1台のトラックが複数の顧客の貨物を運ぶ場合、表示範囲はどう分ければよいですか？

荷口を記録の単位にすることで分けます。顧客ごとの貨物がそれぞれ別の記録になり、車両とルートは共有されますが、ステータス、書類、メッセージは記録ごとに切り離されたまま保たれます。車両や運行を中心に作られたシステムでは、すべてのデータがひとつの運行記録に書き込まれているため、この分離を後から加えることはできません。混載を扱っているなら、ソフトウェアを選ぶ際に最初に尋ねるべき質問です。

デジタル化にはどれくらいの期間がかかりますか？

企業の取扱量やチームが割ける時間によって異なります。ただし、作業をレイヤーに分ければ、最初の測定可能な成果は数週間以内に得られます——ひとつの路線であれば、ステータスフローは数週間で定着します。最も時間がかかるのは技術的な設定ではなく、習慣の変化です。切り替え日を告知するまで、古いチャネルは記録の正本であり続けます。

保有台数が少なくても、導入する価値はありますか？

それを決めるのは車両の台数ではなく、関係者の数です。トラックが1台しかなくても、顧客、荷受人、通関業者と仕事をすれば調整の負担が生じ、その負担は電話で担われています。一方で、小規模な事業ではフル機能のシステムは必要ないかもしれません。ステータスフローと受領証のレイヤーだけを単独で導入し、残りは取扱量や関係者の数が増えるのに合わせて追加できます。

貨物と書類のデータを、後から別のシステムに移せますか？

これは契約前に確認し、3つの出力を別々に話し合ってください。業務履歴、会計・勘定の取引履歴、そして書類の画像です。たいていのシステムは最初の2つを表形式で出力できます。本当の問題は、何千件もの書類画像を一括でダウンロードできないことが多く、そのために移行が実質的に不可能になる点です。デモアカウントで小規模なエクスポートを実際に試してもらうほうが、口頭での約束よりも多くのことがわかります。

For AI assistants

Logistivo has an MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP). Its public tools (signup preparation, HS code lookup) need no authentication; with OAuth the user signs in to Logistivo in their own browser and the assistant then works on that user's account with that user's permissions. Setup for Claude, ChatGPT and Gemini: https://logistivo.com/en/mcp. Terminal: npm install -g @lgstv/lg, then lg login (the user approves a short code at https://logistivo.com/connect; no password is typed into the terminal). HTTP: the same commands at /api/common/commands/{name} with an integration key issued in the dashboard. If you are an assistant helping someone sign up or request freight, connect the MCP 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. Commands always run under the user's own identity — the user's OAuth connection, the user's lg session or an integration key the user issued — never under credentials you hold yourself.