― 一人で走る人と、人を走らせる人。同じ「軽貨物」でも事務の形は別物である。
§ 01 / 同じ軽貨物でも、事務は二種類ある
軽貨物（黒ナンバー）の話をするとき、たいてい想定されているのは自分で走っている人です。確定申告は会計ソフトで足り、仕事はマッチングプラットフォームで拾える。事務は個人の範囲で閉じます。
これとは別に、配下にドライバーを抱えている事業者がいます。荷主から仕事を受け、委託または雇用のドライバーに割り振り、荷主に請求し、ドライバーに支払う。ここでは事務が二重になります。
この二つは、必要なものが違います。前者に要るのは記録を残す手段。後者に要るのは、記録と、お金の二面です。そして後者の事務は、元請のアプリにもマッチングプラットフォームにも含まれていません。どちらも自社の範囲までしか面倒を見ないからです。
§ 02 / 点呼は「記録した」で終わらない
2025 年 4 月の制度改正で、軽貨物にも点呼・アルコールチェック・日報の記録が求められるようになりました。ここまでは、走る人も束ねる人も同じです。
違うのは、束ねる側には確認する責任が乗ることです。ドライバーが自分で入力した記録を、誰かが見て承認する。その「誰か」は、制度上は指定された安全管理者です。
つまり運用としては、少なくとも三つの動きが要ります。
- ドライバーが記録を出す — 出先からその場で。事務所に戻ってからでは形骸化します
- 管理側が確認する — 承認と、間違いだったときの取り消し。取り消したという事実も残す必要があります
- 出ていないことに気づく — 記録は「無い」ことが問題なので、揃った分だけ見ていても抜けは見つかりません
3 つ目が、紙と Excel でいちばん難しいところです。提出されたものは目に入りますが、提出されなかったものは何も起きない。業務前点呼は取ったのに日報が出ていないドライバーは、月末の集計まで誰にも気づかれません。
私たちが作っているものでは、この検知を毎朝の自動チェックに寄せています。前日ぶんを見て、点呼はあるのに日報が無いドライバーを管理者に通知する。人が気づく前提を、仕組みの側に移しています。
酒気帯びが検知された日は、ドライバー本人からの日報提出はブロックし、管理者による是正入力だけを通す —— といった細かい分岐も、現場で運用してみないと必要性が分からない類のものです。
§ 03 / 二面精算 ─ 請求と支払は、同じ稼働から出る
束ねる事業者の事務で、いちばん重く、いちばん間違えられないのがここです。
同じ「あるドライバーが、ある日、ある荷主の仕事をした」という 1 件から、二つの金額が出ます。
- 荷主に請求する金額（請求単価）
- ドライバーに支払う金額（支払単価）
この差が、事業者の粗利です。当たり前のようですが、Excel で管理していると、この 2 本を別々のシートで持つことになりがちです。そうなると、どちらか片方を直したときにもう片方が古いまま残り、粗利が合わなくなります。単価を月の途中で改定したときは、さらに追えなくなります。
構造としてはこうなります。
日報（稼働日）
└─ その日に有効な担当割当を引く
├ 請求単価 ──▶ 荷主への請求
└ 支払単価 ──▶ ドライバーへの支払
単価は「稼働日ごと」に引くのが勘所です。月単位で引くと、月中の単価改定に耐えられません。4 月 10 日から単価が変わったなら、9 日までと 10 日からで別の単価が当たるべきで、これを人力の転記でやると必ずどこかで間違えます。
実装では、確定前に粗利を含むプレビューを出し、同じ稼働日に有効な割当が複数ある場合は確定を止めるようにしています。按分先が決められないまま金額を出すと、後から追えない数字になるからです。逆に割当が見つからない稼働日は、金額には含めず「割当なし」として一覧に返すだけにして、確定自体は妨げません。全部を止めると月次が回らないからです。
確定したら月をロックし、やり直すには解除が要る。解除すれば発行済みの請求書は無効になり、関係者に通知が飛ぶ。「静かに書き換わっていた」を作らないための作りです。
§ 04 / 請求書は、インボイスの要件を満たしていないと出せない
もう一つ、束ねる側にだけかかる制約があります。荷主への請求書は、適格請求書（インボイス）の記載事項を満たしている必要があります。番号・発行日・支払期日・税率別の税額・登録番号。
システム側では、登録番号が設定されていない状態では請求書そのものを発行させないようにしています。出してから「要件を満たしていませんでした」となるより、出せない方が安全だからです。
Excel のテンプレートで運用していると、この手の要件は「気をつける」で担保することになります。台数とドライバーが増えるほど、気をつける対象が増えていきます。
§ 05 / どこまでを自分たちでやるか
念のため書いておくと、配車の最適化や運賃計算は、私たちの土俵ではありません。そこは大手の運行管理システムが長く作り込んできた領域で、後から薄く作っても勝てません。
私たちが作っている KuruMane（くるマネ） は、点呼・アルコールチェックの記録を入口に、ドライバー名簿、日報・稼働、そして二面精算と請求書までを 1 つにまとめたものです。ドライバーの接点は LINE だけで、アプリのインストールは要りません。IT に不慣れなドライバーに「まずアプリを入れてください」と言わずに済むことは、導入の成否をかなり左右します。
対象は、配下にドライバーを抱えて、荷主への請求とドライバーへの支払の両方を回している事業者です。一人で走っている方向けではありません。現在開発中で、先行案内を受け付けています。
軽バンを貸し出す側のリース事業者向けには、KeiMane（軽マネ）を別途開発しています。また、ドライバー個人の視点から義務化対応を整理した記事は軽貨物の運転日報・点呼をLINEでにあります。
いま Excel と紙で回していて、ドライバーが増えるたびに月末が重くなっているなら、まず二面精算のどこが手作業で残っているかを一緒に洗い出すところから始められます。
本記事は制度の概要を一般化して説明したものです。点呼・アルコールチェックの実施方法や記録の保存要件、機器の要件は、国土交通省の告示・輸送安全規則で最終確認してください。記録をシステムで残すことと、法令上どの方式の点呼として認められるかは別の論点です。KuruMane は開発中のため、機能・提供時期は変更される場合があります。