【運送業×AI活用】kintoneのAIエージェントで事故の再発防止｜ヒヤリハットと点検記録から防止案を作成

「この事故、前にも同じ場所であった気がする」

「この車、点検で何か出ていなかったか」

「結局、注意喚起の紙を貼って終わりになってしまう」

事故の報告を受けたあと、こんなふうに迷った経験はないでしょうか。

事故の再発防止は、単なる事後処理や形式的な注意喚起ではありません。「ハンドルを握るドライバーに、もう二度と危険な思いをさせたくない」「今日出庫した仲間が、無事に家族のもとへ帰れるように」という、現場を守る人々の切実な願いであり、“おもいやり”そのものです。私たちがお届けしたいのは、単に報告書を埋める手間を省くだけの効率化ではなく、現場が大切にしてきたそうしたドライバーへの配慮や安全への祈りをテクノロジーで形にする「おもいやりDX」です。

過去の事故やヒヤリハット、日々の点検記録をつなぎ合わせ、根本的な原因から現場を守る。 それを叶えるのが、kintoneのAIエージェントです。事故報告を登録するだけで、過去の事故・ヒヤリハット・点検・整備の記録を突き合わせた再発の判定と防止の案が、承認待ちで届きます。ただし、それらの記録が kintone に残っていることが前提で、要因と対策を決めるのは運行管理者などが確認してからです。

ベテランの運行管理者なら、場所を聞いただけで「あそこの構内、春にも同じ車でぶつけたな」「この車、点検で何か出ていなかったか」と思い出せます。

でも、新しく担当になった人には、その手がかりがありません。

この記事では、kintone の事故報告で、事故・ヒヤリハットの再発確認と再発防止の案づくりを AIエージェントに任せたところを、実際の画面と動画で紹介します。

この記事でわかること

• 再発かどうかを確かめるために、AIエージェントが kintone の事故報告・ヒヤリハット集・日常点検・整備記録から何を調べるか

• よく似た2つのバック事故で、要因が「運用面」と「直っていない後退灯」に分かれる理由

• 事故報告に書き込む前に、運行管理者が根拠を確かめて承認する流れ

1. 事故の再発確認で起きていること

事故が再発かどうかを確かめ、防止の案を考えるには、本来こんな手順が必要です。

1. 事故の報告を受けて、kintone に登録する

2. 過去の事故報告で、同じ場所・同じ車両・同じ種類の事故を探す

3. ヒヤリハット集で、似た状況の事例を探す

4. 日常点検で、その車両に指摘がなかったかを見る

5. 整備・修理記録で、指摘が直っていたかを確かめる

6. 再発かどうかと、防止の案を決める

アプリをいくつも開いて、それぞれで探して、照らし合わせる。

事故の報告を受けるたびに、多忙な現場の中でここまでの調査を重ねるのは非常に大変な作業です。

再発を防ぎたい気持ちはあっても、「まずは全体へ注意喚起を行い、速やかに現場の安全を確保する」といった一次対応で手一杯になってしまいがちです。過去の膨大な記録にまで細かく目配りし、根本的な要因を突き止める時間を確保するのは大きな負担と言えます。

2. 事故の再発確認をAIエージェントに任せると

担当者がするのは、いつもどおり事故報告アプリにレコードを登録することだけです。

1. 担当者が、事故報告を登録する

2. エージェントが動き出し、4つのアプリを調べる

3. 再発の有無・根拠・防止の案をまとめて、提案する

4. 人が中身を確かめて、承認する

5. 事故報告のレコードに書き込まれる

ここからは、実際の画面で順に見ていきます。

① 登録をきっかけに動き出す

※以下すべての画像はダミーデータです。

ドライバー、車両、発生日時、場所、事故の種類、事故の概要を入れて保存します。

ここまでは、エージェントがいなくても毎日している作業です。

② 関係するアプリを自分で調べる

エージェントはまず、各アプリにどんな項目があるかを確かめます。

それから、4つのアプリで関係する記録を探します。

• 事故報告：同じ場所、同じ車両、同じ種類の過去の事故

• ヒヤリハット集：場所や「バック」「後退」「輪留め」などの言葉が重なる事例

• 日常点検：同じ車両の、事故の前3か月分

• 整備・修理記録：同じ車両の記録

何をどの条件で探したかは、あとで届く提案の中にそのまま書かれています。

どのアプリを見るかは、あらかじめエージェントへの指示に書いておきます。どの欄でどう探すかの条件は、エージェントがアプリの欄の構成を確かめて組み立てています。

③ 「こう書き込みたい」と提案して承認を待つ

このデモの設定では、調べ終わっても、エージェントはいきなりレコードを書き換えません。

何を調べて何がわかったか、どの欄に何を書き込むかをまとめた提案を出して、承認待ちになります。

人が中身を見て「承認」を押すと、はじめて書き込まれます。納得できなければ「却下」もできます。

④ 再発の有無・根拠・防止の案が記録に入る

承認すると、事故報告のレコードに再発の有無、再発確認の根拠、再発防止の案が書き込まれます。

根拠は「似た過去の事故」「似たヒヤリハット」「点検・整備」「考えられる要因」に分けて書かれます。

コメント欄には、判定と、似た記録の件数が1行で残ります。

3. 2つの事故で要因と再発防止の案はこう分かれた

同じエージェントに、よく似た2つの事故を登録してみました。

どちらも、荷卸しのときのバックで起きた軽い接触事故です。

※動画と画面に出てくる会社名などは、サイボウズ社が提供する kintone のサンプルアプリのデータと、デモ用に作った架空のデータです。実在の企業・団体とは関係ありません。

荷卸し後に後退で出庫する際、後方の輪留めに接触。リアバンパー下部を軽微に損傷。走行に支障なし。

日没後、荷卸しのため後退中に後方の車止めポールに接触。リアバンパー右側を軽微に損傷。後方が暗く見えにくかった。

判定はどちらも「再発」でした。どちらにも、場所・車両・事故の種類の3つがそろって一致する過去の事故があったからです。

分かれたのは、何が要因と考えられるかと、何から手を打つかでした。

4. 再発かどうかを確かめる4つのポイント

結果だけでなく、判断の中身にも見どころがあります。

① 点検と整備の記録を事故の言葉と突き合わせる

2つの事故で分かれ目になったのは、日常点検と整備・修理記録でした。

エージェントは、点検で出た指摘が事故の前に直っていたかどうかを、日付で確かめています。

事故発生日（2026-10-29）時点では、点検で指摘された「右リアの後退灯」の整備記録が存在しない（入庫予定は事故後の11/5）。

そのうえで、報告に書かれていた言葉とつなげています。

今回の事故は「日没後」「後方が暗く見えにくかった」との記載があり、バックランプ不灯と符合する可能性がある。

平和島センターの件では、同じ確かめ方をして、逆の結論を出していました。

点検は全項目OKで、関係する整備もない。だから「車両の機械的な不具合に起因する可能性は低い」として、手順の見直しを先にしています。

記録に何があるかで、手を打つ順番を変えています。

② 一致の度合いを分けて書く

エージェントは、過去の事故を「似ている」「似ていない」の2つで片づけていません。

場所・車両・種類のどれが一致したかを、1件ずつ書き分けています。

#13 車両-001、2026-07-14、接触（構造物）、静岡県 東名高速 SA構内 → 車両番号のみ一致、種類・場所は異なる。

さいたま市の件では、名前が似ているだけの場所にも気づいていました。

#9：事故の種類「バック時」が一致、場所は「東京都足立区 配送先駐車場」で「配送先駐車場」という名称は同じだが都県が異なる

「再発」の決め手にしたのは3つがそろって一致した1件だけで、ほかは参考として根拠に並べています。

③ 状況が似ていれば別の場所の事例も前例にする

2本とも、同じヒヤリハットを使っていました。

平和島センター構内で、後退中にミラーの死角に輪留めが入り、接触寸前で止まった事例です。

平和島センターの件では、場所も動作も一致する前例です。

さいたま市の件は場所が違いますが、エージェントはこう書いて関連づけていました。

後退時の死角・視認性という点で今回の状況と共通。

そのため、どちらの防止の案にも、このヒヤリハットで決めた「降車目視を1回挟む」「誘導者がいなければ一旦停止」が入っています。

現場で出したヒヤリハットが、別の場所の事故の防止にも生きています。

④ 案ごとに根拠を添えて人が書いた欄には触れない

再発防止の案には、1つずつ「（根拠：日常点検#5の異常箇所…）」「（ヒヤリハット集 #1の対策を踏襲）」のように出どころが付いています。

気になれば、その記録を開いて確かめられます。

また、このデモの設定では、エージェントが書き込むのは自分の担当の欄だけです。提案の中でも、はっきり書いていました。

事故概要・相手方情報・対応ステータスなど人が記録した欄には一切手を加えていません。

5. 運行管理の現場はこう変わる

• 報告のあとに調べる時間が減る：登録して約40〜50秒で、再発の判定と防止の案の提案が届きます。

• ベテランの記憶に頼らなくてよくなる：担当になったばかりの人でも、過去の事故やヒヤリハットをふまえた対策を考えられます。

• アプリをまたいだ見落としに気づける：「点検で指摘されたのに直っていない」を、整備の記録まで見にいって拾ってくれます。

• 対策を決めるのは運行管理者：再発防止の案は承認待ちで届くので、根拠の記録を開いてから承認するか却下するかを決められます。

再発防止の案は、記録から組み立てた下書きです。要因の特定や車両の整備、社内ルールへの反映は、運行管理者などが現場と実車を確かめたうえで決める前提です。

6. あなたの会社の事故対応は当てはまる？

次のうち、当てはまるものはありますか。

• 事故報告やヒヤリハットを、kintone に記録している

• 再発かどうかの判断や防止の案が、運行管理者によってばらつく

• 「あそこの構内で前にもぶつけた」を、ベテランの記憶に頼って思い出している

• 日常点検や整備・修理の記録が、車両ごとに残っている

2つ以上当てはまるなら、AIエージェントに任せられる余地があります。

よくある質問

Q. AIエージェントが勝手に事故報告を書き換えることはありますか？

承認されるまで書き込みません。エージェントは、何を調べて何がわかったか、どの欄に何を書き込むかをまとめた提案を出して、承認待ちになります。承認後も、事故概要や相手方情報など人が記録した欄には書き込まない設定にしています。どのアプリに何を書けるか、承認を挟むかは、エージェントの設定で決めます。

Q. 場所が少し違う事故やヒヤリハットも参考にしてもらえますか？

参考にしています。エージェントは場所・車両・種類のどれが一致したかを1件ずつ書き分けています。動画のさいたま市の件では、場所の違う平和島センターのヒヤリハットを「後退時の死角・視認性という点で共通」として、防止の案に生かしていました。

Q. 車両の不具合が原因かどうかも見てもらえますか？

エージェントは日常点検と整備・修理記録を、事故の日付と突き合わせています。動画では、事故の1週間前に「右リアの後退灯が点灯しない」と記録され、直した記録がないことに気づいて、要因に加えていました。あくまで記録から考えられる要因の一つなので、車両の不具合かどうかは、運行管理者や整備の担当が実車を確かめて判断します。

まとめ：事故の再発防止はたまっている記録の見直しから

このエージェントが使っているのは、どれもすでに kintone にたまっていた記録です。

過去の事故報告、ヒヤリハット、毎朝の日常点検、整備の記録。

「書いておしまい」になりがちな記録が、次の事故を防ぐ材料として生きてきます。

ヒヤリハットや日常点検を書き続けるほど、エージェントが参照できる前例は増えていきます。

事故の再発確認のように、いくつもの記録を突き合わせて初めて要因が見える業務は、AIエージェントに任せやすい業務の一つです。

毎朝の点検や小さなヒヤリハットを書き残し続けることが、次の事故を防ぐ備えにつながります。

運送のもう一つの記事はこちら

運送配車案の作成「依頼する」を押すだけで、AIエージェントが配車案とその根拠を用意してくれる

この業務、あなたの会社でも実現できるかもしれません。

同じ業務でも、会社によって進め方や判断のルールは異なります。

ノベルワークスは、kintoneの開発経験を活かし、それぞれの業務に合ったAIエージェントの活用を支援します。

👉 自社の業務について相談する