運送業の点呼・運行日報をClaude Codeで効率化【2026】

「また今日も点呼記録の清書に30分かかった」「日報を集計してドライバーの労働時間チェックをするのが月末の地獄だ」——中小運送会社の運行管理者から、こうした声を繰り返し聞く。

2024年4月1日から適用された改正改善基準告示（厚生労働省：自動車運転者の労働時間等の改善のための基準）により、拘束時間・休息期間のルールは一段と厳格化された。同時に国土交通省が遠隔点呼・自動点呼の制度化（国土交通省：自動車運送事業の安全対策）を進めるなど、運行管理のデジタル化が加速している。しかし現実には「対面点呼は手書き記録、月末は電卓とにらめっこ」という事業者が多い。

本記事では、Claude Code を使って点呼記録・運行日報・改善基準告示チェックの下書き業務を省力化する具体的な実装手順を解説する。重要な前提として、点呼記録・運行管理の最終的な法的責任は運行管理者（人間）にある。Claude Code はあくまで「ドラフト生成・集計支援ツール」として位置づけ、人間が必ず確認・署名するフローを維持することが不可欠だ。

1. 運送業の運行管理・労務管理が抱える5つの構造的課題

問題の構造を整理しておく。中小運送会社の運行管理担当者が抱える課題は、技術的な問題ではなく「記録・確認・集計」という繰り返し作業の量にある。

課題1：点呼記録の清書・転記負担

貨物自動車運送事業輸送安全規則により、事業者は乗務前後の点呼を原則対面で実施し、その結果を記録・1年間保存することが義務付けられている。実際の運用は「口頭確認→手書きメモ→後でExcelに転記」という二度手間が常態化しており、繁忙期には翌日まで清書が溜まるケースもある。

課題2：運行日報の整形・ファイリング

ドライバーが記入する運行日報は記入漏れ・略語・手書き文字の判読困難が頻発する。これを所定書式に整形し、運行管理者が内容を確認するまでに1件あたり5〜15分程度かかることも珍しくない。

課題3：改善基準告示への対応チェック

2024年4月1日適用の改正改善基準告示では、トラック運転者について1か月の拘束時間284時間以内（労使協定があれば年6か月まで310時間まで延長可）、1日の拘束時間13時間以内（最大15時間）、休息期間は継続9時間以上（11時間以上を基本）といった規定が適用される。これらを複数ドライバー分、毎月確認するのは手作業では負担が大きい。

課題4：ドライバー不足による兼任・属人化

運行管理者が事務も兼務するケースが増えており、記録業務に使える時間が圧迫されている。特に「退勤前の記録まとめ」が深夜になることが中小事業者の共通課題だ。

課題5：デジタルツール導入コストの壁

市販の運行管理システムは月額費用が数万円からとなり、車両台数が少ない中小事業者には費用対効果が合わないと判断されることが多い。「既存のExcelとメモ運用を少し効率化したい」というニーズに対して、フルパッケージSaaSは過剰投資になりがちだ。

2. Claude Code をどう位置づけるか——「自動化」ではなく「下書き生成」

Claude Code は、Anthropic が提供するターミナルベースの AI コーディングエージェントだ（code.claude.com）。コード生成・実行・ファイル操作を対話形式で行えるため、定型の文書整形・データ集計スクリプトの作成と実行に強い。

運送業の記録業務への適用では、次の役割分担が現実的だ。

「Claude Code がやってくれるから記録は任せた」という運用は絶対に避けなければならない。Claude Code の出力はドラフトであり、運行管理者による確認と承認が常に必要だ。この認識を社内で徹底することが、導入の大前提となる。

3. 具体的なワークフロー——点呼メモから点呼簿ドラフトへ

ここでは「車両数十台規模の中小運送会社」を想定した具体的なワークフローを描く。特定の企業名・実測値は伴わないが、実装構造は現場で再現可能な形で示す。

シナリオ：朝の乗務前点呼処理

運行管理者が朝6時に複数ドライバーの乗務前点呼を実施する。現在の流れは「点呼台紙に手書き→後でPCでExcel入力」だが、これを「点呼メモをテキスト入力→Claude Code がドラフト生成→管理者が確認・保存」に変える。

以下は Claude Code セッション内で動かす Python スクリプトの実装例だ。点呼メモのテキストを受け取り、点呼簿の項目に構造化して出力する。

#!/usr/bin/env python3
"""
点呼メモ → 点呼簿ドラフト生成スクリプト
使い方: python3 rollcall_draft.py --memo "メモテキスト" --driver "氏名" --date "2026-06-08" --type "乗務前"

注意: 出力はドラフトです。必ず運行管理者が内容を確認・修正の上、正式記録として保存してください。
"""

import argparse
import datetime

def parse_args():
    parser = argparse.ArgumentParser(description="点呼メモから点呼簿ドラフトを生成します")
    parser.add_argument("--memo", required=True, help="点呼時のメモ（自由記述）")
    parser.add_argument("--driver", required=True, help="運転者氏名")
    parser.add_argument("--date", default=str(datetime.date.today()), help="点呼日（YYYY-MM-DD）")
    parser.add_argument("--type", choices=["乗務前", "乗務後"], default="乗務前", help="点呼区分")
    parser.add_argument("--manager", default="（運行管理者名を入力してください）", help="運行管理者名")
    return parser.parse_args()

def extract_items_from_memo(memo_text: str, call_type: str) -> dict:
    """
    メモテキストから点呼項目を推定してドラフトを生成する。
    ※ここをClaude Codeとの対話で精緻化するか、追加のNLP処理に置き換えられる。
    """
    draft = {
        "日時": "",              # 記録者が確認・入力
        "運転者名": "",          # 引数から取得
        "点呼区分": call_type,
        "実施方法": "対面",      # 遠隔の場合は変更
        "アルコール検知": "（検知器結果を入力してください）",
        "疾病・疲労確認": "（確認結果を入力してください）",
        "睡眠不足確認": "（確認結果を入力してください）",
        "日常点検結果": "（点検結果を入力してください）" if call_type == "乗務前" else "不要",
        "道路・気象情報": "（指示内容を入力してください）" if call_type == "乗務前" else "不要",
        "特記事項": "",
        "運行管理者確認": "【要確認・署名】",
        "メモ原文（参考）": memo_text,
    }

    # メモから特記事項の候補を抽出（簡易版：キーワードベース）
    keywords_to_flag = ["体調不良", "睡眠不足", "頭痛", "発熱", "前日飲酒", "疲れ", "腰痛"]
    flagged = [kw for kw in keywords_to_flag if kw in memo_text]
    if flagged:
        draft["特記事項"] = f"【要注意】以下のキーワードが検出されました: {', '.join(flagged)} — 内容を必ず確認してください"

    return draft

def format_as_record(driver: str, date_str: str, manager: str, items: dict) -> str:
    """点呼簿ドラフトを人間が確認しやすい形式で出力"""
    lines = [
        "=" * 60,
        "【点呼記録 ドラフト】※内容を必ず確認・修正のうえ正式保存",
        "=" * 60,
        f"点呼日時: {date_str}  （時刻を入力してください）",
        f"運転者名: {driver}",
        f"運行管理者: {manager}",
        "-" * 60,
    ]
    for key, value in items.items():
        if key == "メモ原文（参考）":
            continue  # 正式記録には含めない
        lines.append(f"{key}: {value}")
    lines.append("-" * 60)
    lines.append(f"■ メモ原文（参考のみ・正式記録に含めないこと）:\n  {items['メモ原文（参考）']}")
    lines.append("=" * 60)
    lines.append("※このドラフトは Claude Code により生成されました。")
    lines.append("※法的記録としての有効性は、運行管理者による確認・署名後に発生します。")
    return "\n".join(lines)

if __name__ == "__main__":
    args = parse_args()
    items = extract_items_from_memo(args.memo, args.type)
    items["運転者名"] = args.driver
    output = format_as_record(args.driver, args.date, args.manager, items)
    print(output)

このスクリプトを Claude Code セッション内で作成・実行し、出力ドラフトを運行管理者が確認・修正して正式記録に転用する。Claude Code との対話を通じて「特定の日報書式に合わせた出力形式に変える」「アルコール検知数値を引数で受け取れるようにする」といった改修を自然言語で依頼できるのが最大の強みだ。

Claude Code への依頼プロンプト例

Claude Code のターミナルインターフェースでは、以下のような自然言語プロンプトでスクリプトの生成・改修を依頼できる。

# Claude Code へのプロンプト例

「以下の点呼メモから、所定の点呼記録様式に近い形でドラフトを整形してください。
出力には必ず「このドラフトは確認が必要です」という注記を入れてください。

【点呼メモ】
山田さん 6:15 乗務前 アルコール0 体調良好 睡眠6h
右後タイヤの空気圧が少し低め→調整済み 本日の経路確認済み
特記事項なし

【出力形式】
- 点呼日時（日付+時刻の欄）
- 運転者名
- アルコール検知結果（数値）
- 疾病・疲労の状況
- 睡眠時間
- 日常点検結果（乗務前のみ）
- 特記事項
- 運行管理者確認欄（未記入のまま出力）」

4. 改善基準告示チェックの下書き自動化

改善基準告示（2024年4月適用版）のチェックは、月末にまとめてやると漏れが発生しやすい。週次・月次で「今月のドライバーXの拘束時間と休息期間を一覧化し、閾値超えがないか確認する」下書き資料を Claude Code に作らせることで、管理者の確認作業を効率化できる。

主要な閾値（2024年4月1日適用・トラック運転者の目安）は以下の通りだ。最新の詳細・例外規定は必ず厚労省の公式ページで確認すること。

※上記は概要です。例外・条件・バス・タクシーは別規定。必ず厚労省公式を最新版で確認してください。

デジタコやExcelから出力した運行データを以下のような形で Claude Code に渡すと、集計下書きが得られる。

# 労働時間集計下書きの依頼プロンプト例

「以下は今月のドライバー山田さんの運行データです（CSV形式）。
改善基準告示（2024年4月適用・トラック運転者）の主要閾値と照合して、
1か月拘束時間・1日拘束時間の最大値・休息期間の最小値を集計し、
閾値を超えている日がないかチェックした表を作ってください。
結果はドラフトであり、最終確認は運行管理者が行います。

[データ]
日付,出庫時刻,帰庫時刻,運転時間(h),休息前時刻,休息後時刻
2026-06-01,06:00,18:30,9.5,18:30,翌06:00
2026-06-02,06:00,20:00,10.0,20:00,翌06:00
...（以下続く）」

Claude Code はこのデータを受け取り、Python スクリプトを生成・実行して集計結果をテーブル形式で出力する。「15時間を超えた日がある場合はセルを強調する」「月間拘束時間が280時間を超えたら警告コメントを付ける」といった追加要件も自然言語で依頼できる。

5. 導入の3ステップ——小さく始めて全体へ

中小運送会社での Claude Code 活用は、大規模システム導入ではなく「スクリプト1本から」始めるのが現実的だ。

ステップ1：最小実装（1〜2週間）

まず、最もストレスの高い「点呼メモの清書」だけを対象にする。

• Claude Code をローカルPC（または管理者のノートPC）にインストールする
• 本記事の rollcall_draft.py を Claude Code と対話しながら自社の様式に合わせてカスタマイズする
• 1週間試用し、「ドラフトの精度が実用レベルか」「管理者の確認フローが無理なく回るか」を評価する

ステップ2：テンプレ化・チーム展開（1〜2か月）

最小実装が回り始めたら、対象業務を広げる。

• 運行日報の整形スクリプト（デジタコCSV/手書き転記テキスト対応）を追加する
• 月次の改善基準告示チェックシートの下書き生成スクリプトを追加する
• スクリプト群を共有フォルダに置き、複数の運行管理者が使えるようにドキュメントを整備する

ステップ3：運行管理フロー全体への組み込み（2〜3か月以降）

スクリプトが安定稼働したら、より広い自動化を検討する。

• デジタコシステムのAPI・エクスポート機能との連携（データ取り込みの自動化）
• 月次レポートの自動生成（ドライバー別の傾向分析・要注意ドライバーのリストアップ下書き）
• 社内ポータルや既存の業務管理ツールへの出力連携

「全部一度に」ではなく「1つ動かして信頼を積む」というアプローチが、現場の受け入れと品質維持の両立につながる。

6. 注意点——法的責任・個人情報・運用の落とし穴

Claude Code を運送業務に活用する際に、必ず押さえておくべき注意点を整理する。

点呼・記録の最終責任は必ず人間が負う

貨物自動車運送事業輸送安全規則に基づく点呼の実施・記録は、運行管理者（もしくは補助者）が行う義務がある。Claude Code の出力は「下書き支援」であり、スクリプトが生成したドラフトをそのまま正式記録として扱うことは認められない。必ず運行管理者が確認・修正・署名を行う業務フローを設計すること。

個人情報・運転者データの取り扱い

点呼記録・運行日報にはドライバーの氏名・健康状態・位置情報などが含まれる。Claude Code にデータを渡す際は以下の点に注意する。

• クラウドAPI（Anthropic API）経由で処理する場合、個人情報の外部送信に当たるため、自社のプライバシーポリシー・就業規則・個人情報保護法に照らして扱い方を確認すること
• ローカル実行環境（インターネット非接続環境での処理）を検討する場合は、セキュリティ担当者・顧問に相談する
• スクリプト内でのログ出力・一時ファイル保存時に個人情報が残らないよう設計する

改善基準告示の閾値は「最新公式」で確認する

本記事の閾値は概要として記載したが、例外規定・特例・労使協定の有無によって適用内容が異なる。スクリプト内にハードコードする数値は、必ず厚労省の最新告示を確認してから設定すること。告示の内容が変わった場合はスクリプト内の閾値も更新する運用ルールを決めておく。

スクリプトの「出力を鵜呑みにしない」文化の醸成

Claude Code の出力には誤りが含まれる可能性がある。特に自然言語のメモから項目を抽出する処理では、文脈の読み違いや抜け漏れが発生しうる。「AIが出した数字だから正しい」という思い込みを防ぐため、出力ドラフトには必ず「※要確認」「※数値を人間が検証してください」という注記を付けるコード設計を推奨する。

7. 横展開のヒント——他の運行管理業務への応用

点呼記録・日報・労務チェックの下書き自動化が軌道に乗ったら、同じアプローチで横展開できる業務がある。

これらの業務でも「Claude Code が生成するのはドラフト」という原則は変わらない。人間の確認・承認フローを前提としたシステム設計が、導入成功の条件となる。

8. まとめ——「下書き支援」から始める運行管理 DX

本記事で示したアプローチを整理する。

• 運送業の点呼記録・運行日報・改善基準告示チェックは、繰り返し発生する「入力→整形→確認」という構造を持つ業務であり、Claude Code を使った下書き自動化と相性が良い
• 実装は python rollcall_draft.py のような小さなスクリプト1本から始められ、段階的に対象業務を広げられる
• 法的責任・個人情報保護・閾値の最新化に関する運用ルールを設計することが、導入の前提条件となる
• 「AIが全部やってくれる」ではなく「AIが下書きを作り、人間が確認・承認する」というフローを徹底することが、安全で持続可能な活用の鍵だ

ドライバー不足・改善基準告示の厳格化という逆風の中で、運行管理者の事務負担を減らし、本来の「安全確認」業務に集中できる環境を作ること——Claude Code はその小さな一歩を、開発リソースのない中小事業者でも踏み出せるように支援するツールだ。