物流・倉庫

運送業の事故報告書・ヒヤリハット記録をClaude Codeで仕組み化する

公開 2026年7月28日

中小運送会社の運行管理者が、事故報告書とヒヤリハット記録の下書き・整理・傾向分析をClaude Codeで仕組み化する実装パターンと、警察・運輸支局への届出はAI化しない一線を解説する。

結論：運送業で事故報告書・ヒヤリハット記録の運用が続かない主因は、法定の報告義務がある「事故」と、各社が任意で集める「ヒヤリハット」を、同じ記録フローの中で区別せずに扱っていることにある。Claude Codeは警察への事故報告や運輸支局への提出そのものを代替する道具ではなく、ヒヤリハットの日次記録・事故記録簿の下書き生成・月次の傾向分析という「記録運用の周辺作業」を仕組み化する道具として使える。

要点1：報告義務のある「事故」（自動車事故報告規則第2条が定める15類型）と、貨物自動車運送事業輸送安全規則第9条の2が定める「事故の記録」（3年保存）、そして各社任意のヒヤリハット情報は、根拠法令も保存期間も報告先も別物である。
要点2：実装の骨格は「ヒヤリハットの日次収集 → 事故記録簿・報告書の下書き生成 → 月次の傾向分析」という3段パイプラインで、Claude Codeにはスクリプトの生成・保守・レビューを任せる。
要点3：警察への事故報告、運輸支局への自動車事故報告書・速報の提出、事故が報告対象に該当するかどうかの最終判断は運行管理者・事業者自身が行うものであり、AIが代替する領域ではない。

対象読者：運送業向けに事故記録・安全管理の仕組みを受託開発・内製する開発者、PM、運行管理システム担当者

今日やること：自社（または支援先）の事故発生時の対応フローを1枚の図に描き、「法定報告対象の事故」「記録だけ必要な事故」「任意で集めるヒヤリハット」のどこが区別されずに一本化されているかを洗い出すこと

本記事は特定の実在運送会社の支援事例ではありません。複数の運送業向け受託開発・内製化の相談でくり返し出てくる「事故報告書とヒヤリハットの記録が続かない」という課題を一般化した実装パターン解説です。文中の工数・時間の数値はすべて試算・想定であり、実測結果ではありません。

運送業向けのシステムを扱う開発者の間で、最近「事故やヒヤリハットの記録を仕組み化してほしい」という相談が増えている、という声をよく聞く。話を聞いていくと、要望の中身は毎回よく似ている。「事故が起きたときの報告書作成が特定の運行管理者に属人化していて、毎回書式を思い出しながら書いている」「ヒヤリハットは朝礼で口頭共有されるだけで、記録としてはほとんど残っていない」「監査や運輸支局の巡回指導で、記録の不備を指摘されないか不安」。点呼記録や運行日報の整備はある程度進んでいる運送会社でも、事故・ヒヤリハットという「起きてほしくない出来事」の記録は後回しにされがちだ。この記事では、報告義務のある事故とヒヤリハットの法的な位置づけの違いをまず正確に整理したうえで、Claude Codeで仕組み化できる範囲とできない範囲を明確に線引きしながら、実装パターンをコード例とともに解説する。

なぜ事故報告書とヒヤリハットの記録は「続かない」のか

運送業の事故・ヒヤリハット記録が続かない現場には共通点がある。事故は発生頻度が低いため、報告書の書き方が組織のノウハウとして蓄積されず、その都度「前回はどう書いたか」を探すところから始まりがちだ。一方でヒヤリハットは日常的に発生するにもかかわらず、法定の報告義務がないぶん記録の動機付けが弱く、「わざわざ書くほどのことでもない」という判断が現場で先行しやすい。

さらに厄介なのは、この2つの性質が異なる記録を、同じ「事故報告書」というフォルダや台帳に混在させてしまう運用だ。法定報告対象の重大事故と、記録だけで足りる軽微な事故と、任意で集めるヒヤリハットが同列に並ぶと、どの記録が誰にいつまでに提出すべきものかが現場で判別できなくなる。実装で解決するなら、まずこの3種類を制度上の根拠から切り分けて棚卸しするところから始めるのが実務的だ。

法的枠組みを正確に理解する——「報告義務のある事故」と「記録すべき事故」とヒヤリハットは別物

実装に入る前に、制度の枠組みを一次情報で正確に押さえておく。運送業の事故・ヒヤリハット対応には、性質の異なる3つの制度が関わっている。

自動車事故報告規則（昭和26年12月20日運輸省令第104号、最終改正：令和2年3月31日国土交通省令第20号）——国土交通大臣（運輸支局長経由）への報告義務を定める省令。第2条は、転覆・転落・火災、10台以上の衝突、死者・重傷者の発生、10人以上の負傷者、危険物等の飛散・漏えい、酒気帯び運転を伴う事故、運転者の疾病による運行継続不能、救護義務違反、装置の故障による運行不能など、15類型の「事故」を定義している。第3条により、事業者等はこれらの事故があった日から30日以内に、事故ごとに自動車事故報告書（別記様式）3通を、当該自動車の使用の本拠を管轄する運輸支局長等を経由して国土交通大臣に提出しなければならない。さらに第4条は、死者2人以上（旅客輸送の場合は1人以上）を生じた事故など特に重大なものについて、24時間以内にできる限り速やかに電話・ファクシミリ等で運輸支局長に速報することを求めている。
貨物自動車運送事業輸送安全規則第9条の2「事故の記録」——事業用自動車の事故について、当該事故発生後30日以内に記録を作成し、事故発生後3年間保存することを定める。記録の内容は「自動車事故報告書の記入等の取扱いについて」（平成元年3月29日付け地車第45号、地備第58号）に準ずるとされ、事故報告規則の別記様式をそのまま活用してよいとされている（この場合、事故の当事者〈乗務員等を除く〉の氏名を付記する）。つまりこの記録義務は、自動車事故報告規則の報告対象になるかどうかにかかわらず、事業用自動車が起こした事故全般に及ぶ。
ヒヤリ・ハット情報の収集・活用——国土交通省大臣官房運輸安全監理官室が公表する「事故、ヒヤリ・ハット情報等の収集・活用の進め方（自動車モード編）」（令和5年6月第4版）は、運輸事業者における安全管理の進め方に関するガイドライン5.(7)の解説資料であり、バス・タクシー・トラック事業者を対象に、事故・ヒヤリハット情報を継続的に収集・分析し対策を講じる「リスク管理」をPDCAサイクルで進めることを推奨している。同資料は「公的機関への報告義務の対象である事故等以外に、防止したい事故等は事業者によって異なる」として、各事業者が収集範囲（定義）を自ら定めるものと位置づけている。つまりヒヤリハットの収集自体は、個別の法令上の報告義務ではなく、ガイドラインに基づく安全管理の推奨実務である。

本記事のコード例は、この3つの制度上の区分——①自動車事故報告規則が定める報告義務のある事故、②貨物自動車運送事業輸送安全規則第9条の2が定める記録義務のある事故、③各社任意のヒヤリハット——を前提に設計している。自社のどの事故がどの区分に該当するか、記録様式や保存方法が法令に適合しているかどうかの最終確認は、必ず所轄の運輸支局、行政書士、または社会保険労務士等の専門家に相談してほしい。本記事は一般的な解説であり、個別事案への適用を保証するものではない。

Claude Codeが担う範囲、運行管理者・事業者が担う範囲

ここが最も誤解されやすい部分なので、先に明確にしておく。Claude Codeにやらせるのは以下の作業に限定する。

ヒヤリハットの入力補助——現場からの報告をCSV・DBに素早く構造化して残すツールの実装
事故記録・報告書の下書き生成——自動車事故報告規則の別記様式、貨物自動車運送事業輸送安全規則第9条の2の記録項目に沿って、入力済みの事実関係を様式のフォーマットに流し込むテンプレート生成
月次・四半期の傾向分析——発生場所、時間帯、天候、当事者属性などを軸にヒヤリハット情報を分類・整理し、根本原因分析の材料を作るスクリプトの実装
記録様式の整備・バージョン管理——様式や記録項目が改正されたときに、差分をGitで追えるようにするテンプレート管理

逆に、Claude Codeにやらせてはいけないのは、次の3つだ。第一に、道路交通法上の運転者本人の義務である警察への事故報告。第二に、自動車事故報告規則第3条・第4条に基づく運輸支局への自動車事故報告書・速報の提出という行為そのもの（下書きの作成支援までは可能だが、内容の最終確認と提出は事業者・運行管理者の責任で行う）。第三に、事故が報告対象に該当するかどうかの判定や、過失割合・法的責任の判断。これらは事業者・運行管理者が担う法的責任であり、AIが代替できる領域ではない。実装者としては、システムの設計段階で「これはあくまで記録・下書き・分析の道具であり、判断と届出の主体はシステムではなく人である」という前提をUIやドキュメントに明記しておくことをすすめる。

実装全体像：ヒヤリハット収集 → 事故記録下書き → 傾向分析のパイプライン

骨格はシンプルな3段構成にする。想定環境はPython 3.11 / pandas 2.x、記録データはローカルのCSV（将来的にSQLiteへ移行しやすい設計）とした。

trucking-safety-records/
├── data/
│   ├── near_miss/          # ヒヤリハットの日次記録 (CSV, 月別)
│   └── accidents/          # 事故の記録(輸送安全規則第9条の2相当) (CSV, 月別)
├── config/
│   └── report_categories.yaml  # 自動車事故報告規則第2条15類型のチェックリスト
├── scripts/
│   ├── input_near_miss.py      # ヒヤリハットの日次入力
│   ├── draft_accident_record.py # 事故記録・報告書下書きの生成
│   ├── monthly_trend.py        # 月次傾向分析
│   └── deadline_tracker.py     # 30日/24時間の期限管理(通知のみ、提出は行わない)
└── templates/
    └── report_form_template.csv  # 自動車事故報告書別記様式相当のテンプレ

この構成をClaude Codeに作らせる際の最初の指示は、次のように役割の境界を明示すると精度が上がる。

自動車事故報告規則第2条が定める15類型のチェックリストと、貨物自動車運送事業輸送安全規則
第9条の2の記録項目に沿って、上記のディレクトリ構成でPythonプロジェクトを初期化してください。
ヒヤリハットと事故の記録は別々のCSVスキーマにしてください。
このシステムは記録の下書き・整理・分析までを行うものであり、
警察への事故報告や運輸支局への提出そのものは行わない旨を、README.mdの冒頭に明記してください。
不足している情報があれば、実装前に質問してください。

ヒヤリハットの日次収集を仕組み化する

ヒヤリハットの記録は、①発生日時、②発生場所、③関与した車両・ドライバー、④状況（何が起きかけたか）、⑤天候・道路条件、⑥推定される要因、をそれぞれ入力する運用に合わせる。CLIでの入力例は次のようになる。

$ python scripts/input_near_miss.py
発生日時 [自動: 2026-07-28 09:15]:
発生場所: 国道○号線 ○○交差点付近
車両番号: XX-XX
状況（自由記述）: 対向車線から右折してきた乗用車と接触しそうになり、急ブレーキで回避した
天候: 晴れ / 道路条件: 乾燥
推定要因（複数可）: 見通し不良, 交差点進入速度
記録者名: 佐藤
→ data/near_miss/2026-07.csv に1行追記しました

Claude Codeへの実装指示はこのように書いた。

状況の自由記述欄は必須項目にしてください。
推定要因は複数選択可能なタグ形式にし、後で集計しやすいよう正規化してください。
このヒヤリハット記録は法定の報告義務がある「事故」とは別の任意記録であることを
コード内コメントとREADMEに明記し、事故報告規則の対象事故と誤って混同されないよう
入力画面の見出しも「ヒヤリハット（任意記録）」と明示してください。

この最後の一文が地味に重要だ。ヒヤリハットの入力画面が事故報告書の画面と見た目が似ていると、現場の担当者が「これは正式な事故報告なのか、ただのメモなのか」を混同しやすい。画面の見出しや色使いで、法定記録と任意記録をはっきり区別しておくと、後々の監査対応でも説明しやすくなる。

事故記録・報告書の下書きを生成する（提出は人が行う）

事故が発生した場合、貨物自動車運送事業輸送安全規則第9条の2に基づく記録は、自動車事故報告規則の別記様式を活用して作成してよいとされている。ここでClaude Codeが担うのは、現場から上がってきた事実関係の断片（発生日時、場所、当事者、状況、損害の程度など）を、様式の項目に沿って整形する下書き生成だ。

# scripts/draft_accident_record.py の骨子（Claude Codeと一緒に実装した例）
import pandas as pd
import yaml
from datetime import date, timedelta

def build_draft(raw_report: dict, categories_path: str) -> dict:
    with open(categories_path) as f:
        categories = yaml.safe_load(f)  # 事故報告規則第2条15類型のチェックリスト

    draft = {
        "事故発生日時": raw_report["datetime"],
        "事故の発生場所": raw_report["location"],
        "当時の状況": raw_report.get("situation", "【要記入：現場状況の詳細】"),
        "事故の種類": raw_report.get("category", "【要確認：第2条何号に該当するか運行管理者が判定】"),
        "損害の程度": raw_report.get("damage", "【要記入】"),
        "報告期限（作成後30日以内）": (
            date.fromisoformat(raw_report["datetime"][:10]) + timedelta(days=30)
        ).isoformat(),
    }
    return draft  # あくまで下書き。内容確認・様式への正式転記・提出は運行管理者が行う

Claude Codeへの指示では、判断が必要な項目を空欄のまま埋めさせないことを徹底した。

「事故の種類」（自動車事故報告規則第2条何号に該当するか）は、AIが自動判定せず、
必ず「【要確認：運行管理者が判定】」というプレースホルダーを出力してください。
損害の程度や当事者の過失に関わる記述も、事実として確認できていない推測は
出力に含めず、「【要記入】」のままにしてください。
生成した下書きの末尾に「この下書きは提出前に運行管理者が内容を確認し、
正式な自動車事故報告書に転記のうえ、運輸支局へ提出してください」という
注記を必ず自動挿入してください。

下書き生成を定期実行したい場合は、非対話モードで実行する構成もある。たとえば当日分の未処理記録をチェックして下書きフォルダに出力したいなら、必要な操作範囲だけをツールに許可する--allowedToolsで権限を絞る構成が安全だ（全権限を許可する--dangerously-skip-permissionsは、事故記録という機微な領域では避け、読み書き先を限定するのが望ましい）。

0 18 * * 1-5 cd /path/to/trucking-safety-records && \
  claude -p "本日分の事故記録の生の入力データを確認し、draft_accident_record.py で下書きを
  生成して drafts/ に保存して。提出は行わないこと" \
  --allowedTools "Read(./data/**)" "Write(./drafts/**)" \
  >> logs/daily_draft.log

月次の傾向分析でヒヤリハットのリスクを可視化する

月次では、①ヒヤリハットの件数と要因別の内訳、②発生場所・時間帯の傾向、③事故記録の件数と自動車事故報告規則の類型別内訳、の3種類を出す。国土交通省の資料が示すリスク管理の手順（情報収集 → 分類・整理・傾向把握 → 根本原因の分析 → 対策の策定と実施 → 効果の把握）に沿って、傾向把握までをスクリプトで支援する設計にした。

分析軸	ヒヤリハットで見るもの	事故記録で見るもの
場所	交差点・カーブ等の危険箇所の偏り	報告対象事故の発生地点の傾向
時間帯	疲労・眠気が出やすい時間帯との関連	速報対象（重大事故）が集中する時間帯
要因タグ	見通し不良・車間距離不足等の頻度	酒気帯び等、第2条各号への該当有無

# scripts/monthly_trend.py の骨子（Claude Codeと一緒に実装した例）
import pandas as pd

def summarize_near_miss(csv_path: str) -> pd.DataFrame:
    df = pd.read_csv(csv_path)
    tag_counts = df["推定要因"].str.split(",").explode().value_counts()
    location_counts = df["発生場所"].value_counts().head(10)
    return tag_counts, location_counts

Claude Codeへの指示では、集計結果を「対策の断定」に使わせないことを徹底した。

集計スクリプトの出力には、要因タグの頻度ランキングだけを出し、
「この要因を直せば事故が防げる」といった断定的な結論文はコード側で生成しないでください。
傾向の解釈と対策の決定は、運行管理者とドライバーが集まって議論する材料として
使うものであることをレポートの冒頭に明記してください。

段階的な導入ロードマップ

Phase 1（2〜3週間程度）：現状の事故対応フローとヒヤリハットの共有方法を棚卸しし、自動車事故報告規則の15類型・輸送安全規則第9条の2の記録項目に沿ってCSVスキーマを設計。ヒヤリハット入力ツールのプロトタイプを一部の営業所で試す。

Phase 2（1〜2ヶ月）：事故記録の下書き生成スクリプトを実装し、実際に事故（軽微なものを含む）が発生した際に運行管理者が下書きを使ってみる。月次の傾向分析を並行して回し、要因タグの分類が現場の感覚と合っているかを確認する。

Phase 3（継続運用）：記録様式のバージョン管理を定着させ、自動車事故報告規則や輸送安全規則の改正、運輸支局の指導内容の変化にスクリプト側も追従させる。複数営業所展開する場合は、傾向分析を営業所別・全社別の両方で見られるようにする。

想定される工数の変化（試算）

以下はあくまで実装パターンとしての試算モデルであり、特定運送会社での実測結果ではない。事故報告書の作成を都度ゼロから書き起こす運用と、下書き生成＋確認作業を比較したイメージとして参考にしてほしい。

作業	想定：都度ゼロから作成	想定：下書き生成＋確認
事故記録・報告書の下書き作成	様式を確認しながら1件ずつ手入力	入力済みの事実関係から下書きが自動生成される
ヒヤリハットの傾向把握	紙・口頭情報を月末に思い出しながら整理	日次入力の集計スクリプトを確認するだけ
30日・24時間の期限管理	担当者の記憶とカレンダーに依存	期限管理スクリプトが未処理案件を可視化（提出自体は人が行う）

正直に言うと、下書きがあっても最終的な内容確認と運輸支局への提出は運行管理者の作業として必ず残る。効果が出るのは「様式を思い出しながら書く」手間が減る部分であり、確認作業そのものを省略する設計は事故記録の性質上避けるべきだ。

よくある失敗パターンと回避策

失敗1：事故報告書の提出まで自動化しようとする
❌ 「Claude Codeで仕組みを作ったから、運輸支局への提出も自動化してしまおう」と考える。
⭕ Claude Codeが担うのは下書き・整理・分析までで、内容の最終確認と提出は必ず運行管理者・事業者が行う前提を崩さない。

失敗2：ヒヤリハットに法定記録と同じ厳格さを求めてしまう
❌ ヒヤリハットの入力欄を事故報告書並みに厳格化し、現場が「面倒だから書かない」を選ぶようになる。
⭕ ヒヤリハットはあくまで任意の安全管理データであることを前提に、入力の心理的ハードルを下げる設計にする。

失敗3：下書きをそのまま提出用の正式記録として確定させる
❌ 自動生成された下書きを、確認なしにそのまま運輸支局への提出書類として扱う。
⭕ 下書きには判断が必要な項目をプレースホルダーで残し、運行管理者が内容を確認・加筆してから正式な様式に転記する運用にする。

失敗4：貨物軽自動車運送事業など対象外の事業形態にも同じ報告義務があると誤認する
❌ 自社の事業形態を確認せずに、自動車事故報告規則の報告義務が一律にすべての運送事業者に適用されると思い込む。
⭕ 自動車事故報告規則第3条は貨物軽自動車運送事業者を適用対象から除外している。自社がどの区分に該当するかは、所轄の運輸支局に確認する。

よくある質問

Q. Claude Codeで事故報告書の作成・提出を完全に自動化できますか？

できません。事故記録・報告書の下書き生成、ヒヤリハットの記録、月次の傾向分析はサポートできますが、事故が報告対象に該当するかどうかの判定、内容の最終確認、運輸支局への提出、警察への報告は運行管理者・事業者・運転者が行う必要があります。

Q. ヒヤリハットの記録は法律で義務付けられていますか？

ヒヤリハット情報の収集そのものを直接義務付ける個別の法令はありません。国土交通省の「運輸事業者における安全管理の進め方に関するガイドライン」に基づく推奨実務として、多くの事業者がリスク管理の一環で取り組んでいます。ただし、貨物自動車運送事業輸送安全規則第9条の2が定める「事故の記録」（3年保存）は、法定報告対象になるかどうかにかかわらず事業用自動車が起こした事故全般に及ぶため、ヒヤリハットと事故の記録を混同しないよう注意してください。

Q. 貨物自動車運送事業輸送安全規則の「事故の記録」と、自動車事故報告規則の「事故報告書」はどう違いますか？

自動車事故報告規則は、第2条が定める15類型の重大な事故について、30日以内（特に重大なものは24時間以内に速報）に国土交通大臣へ報告する義務を定めるものです。一方、貨物自動車運送事業輸送安全規則第9条の2は、事業用自動車が起こした事故について、報告対象かどうかにかかわらず30日以内に記録を作成し3年間保存することを求めるもので、記録の保存が目的です。自動車事故報告規則の別記様式をそのまま記録に活用してよいとされていますが、両者は根拠条文も義務の内容も別物です。

Q. どんな事故が自動車事故報告規則の報告対象になりますか？

転覆・転落・火災、10台以上の車両の衝突、死者・重傷者の発生、10人以上の負傷者、危険物等の飛散・漏えい、酒気帯び運転等を伴う事故、運転者の疾病による運行継続不能、救護義務違反、装置の故障による運行不能など、第2条に15類型が定められています。個別の事故がどの類型に該当するかの判断は、所轄の運輸支局にご確認ください。

Q. 記事中のコマンドやコード例はそのまま使えますか？

実装パターンの一例であり、自社の車両規模・事業形態・既存の記録様式に合わせた調整が必要です。また自動車事故報告規則や輸送安全規則の条文、Claude Code自体のコマンドやオプションの仕様は改正・更新される可能性があるため、実装前に法令は所管の運輸支局・e-Gov法令検索、Claude Codeの仕様は公式ドキュメント（code.claude.com/docs）で最新の内容を確認してください。

まとめ：今日から始める3つのアクション

今日やること：自社（または支援先）の事故発生時の対応フローを1枚の図に描き、法定報告対象の事故・記録だけ必要な事故・任意のヒヤリハットがどこで区別されずに一本化されているかを洗い出す
今週中：ヒヤリハットと事故の記録を別スキーマに分けたCSV設計案を、Claude Codeと一緒にたたき台として作ってみる
今月中：既存の記録運用と並行しながら、事故記録の下書き生成・月次傾向分析のスクリプトを1サイクル回してみる

関連記事として、同じ運送業でも点呼記録・運行日報の仕組み化という観点では「運送業の点呼・運行日報をClaude Codeで効率化」、配車計画やドライバー教育を含む物流・運送業の網羅的な活用パターンという観点では「物流・運送業のClaude Code活用｜配車計画・伝票処理・ドライバー教育の自動化」、旅客輸送側の点呼・運行指示の実装パターンという観点では「貸切バスの点呼・運行指示書をClaude Codeで効率化する実装パターン」もあわせて参考にしてほしい。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

著者プロフィール

佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。

参照・出典

自動車事故報告規則（昭和26年12月20日運輸省令第104号、最終改正：令和2年3月31日国土交通省令第20号）e-Gov法令検索（第2条：事故の定義15類型、第3条：30日以内の報告書提出、第4条：24時間以内の速報）
国土交通省東北運輸局「自動車事故報告規則」条文PDF（条文全文の参照用）
貨物自動車運送事業輸送安全規則 e-Gov法令検索（第9条の2：事故の記録、30日以内作成・3年間保存）
国土交通省「貨物自動車運送事業輸送安全規則の解釈及び運用について」（第9条の2の記録項目・様式の取扱いの解説）
国土交通省大臣官房運輸安全監理官室「事故、ヒヤリ・ハット情報等の収集・活用の進め方（自動車モード編）」令和5年6月第4版（バス・タクシー・トラック事業者向けのリスク管理ガイド、PDCAサイクルの解説）
Claude Code公式ドキュメント CLIリファレンス（-p / --allowedTools の仕様）