通知を見て現地へ向かう。到着すると、もう誰もいない。警備支援では、検知できたかだけを見ていると、この間の問題が抜け落ちます。
HULIXが現在開発している警備支援でも、AIの候補提示から、人の確認、対応、その後の記録までを一つの仕事として設計しています。この記事で扱うのは、開発中の設計と試作の話です。導入効果が確認できた実績として紹介するものではありません。
目次
同じ範囲に長くいる。何度も往復する。一度離れた後に、また集まる。人の動きを続けて見ると、確認したい変化を拾えるようになります。
ただ、長く立っている人が客引きとは限りません。同行者を待っているかもしれませんし、往復しているだけで問題行動とは言えません。
そこで、AIが絞るのは確認候補です。現場の人が実際の状況を確かめ、対応の要否を判断する。その役割を分けています。確認候補を、違反を断定した情報のように表示しないことも必要です。
観測できた動きと、人が確認した出来事は、記録の種類も分けます。「同じ区域に長くいた」は観測です。「確認に行ったら待ち合わせだった」は現認の結果です。この二つを同じラベルに上書きしてしまうと、後からAIが何を根拠に候補を出したかが分からなくなります。
候補の見せ方も、現場の判断を左右します。断定的な名前を付ければ、確認する前から問題があるように受け取られかねません。どの動きが、いつ観測されたため確認候補になったのか。現場の人が判断を始められる情報として渡すことを考えています。
AIが見つけた時刻と、巡回員が確認した時刻は違います。その差の間に、人も状況も動きます。
到着時に誰もいなかった場合も、「異常なし」だけでは情報が足りません。通知が古かったのか、別の場所へ移ったのか、最初の候補が違っていたのか。次に直すべきことが変わるからです。
最低限、候補の発生時刻、確認時刻、その場の状況、対応内容、再確認の結果をつなげて残します。ただし、現場に長い報告文を求めると続きません。不在、対象外、対応済みなど、よく使う結果は短い操作で残せる形にします。
この流れは、Observation、Incident、Action、Resultという四つで整理できます。観測したこと、確認対象として扱う出来事、実際の対応、その結果です。英語の名前を覚えてもらうことが目的ではなく、途中の記録が抜けないようにするための整理です。
例えば、同じ候補へ複数の通知が出たとき、すべて別件として扱うと確認作業が増えます。前の対応と同じ件なのか、いったん解消した後に起きた別の件なのか。その関係を残せれば、通知件数の増加と、現場で対応した件数を混同せずに済みます。
地図上で近くても、別の対応中かもしれません。複数の班が同じ場所へ向かえば、別の場所が空きます。確認したい場所は、向かっている間にも変わります。
HULIXの提案・試作では、候補の優先度と班の状態を合わせて考える巡回支援を扱っています。現場に出す情報は、「次にどこへ行くか」に加え、「なぜそこか」「いつの情報か」が必要です。
通信が切れたときに、古い情報を現在の状態として見せない。指示が変わった場合も、前の指示が残らない。こうした部分まで含めて、現場の人が迷わず使えるかを確かめます。
班の位置が分かっても、その人がすぐ動けるとは限りません。現在の担当、移動経路、引き継ぎの有無も判断に関わります。推薦を出す仕組みには、使える情報と、現場で補う情報の境界があります。HULIXの試作でも、推薦と人の判断をつなぐ画面を扱っています。
現場の通信状態も無視できません。情報が更新されていないのに、地図上の点だけが現在の位置のように見えると、担当者が誤解します。いつの観測かを表示し、現在確認できていない状態を分かるようにする。通信が戻ってから、どの記録を引き継ぐかまで設計する必要があります。
社内の提案資料では、検知、巡回の推薦、現地での介入、指導員の記録、レポートまでをつないで検討しています。どこで人が判断し、どこに結果を戻すかを、一枚の構成で見るためです。
最初の確認では、大きな区域に一度に広げる前に、少ない候補でこの流れを通します。候補が届く、担当者が受ける、現地へ向かう、その場で判断する、結果を残す。この中で、分からない表示や余計な入力がないかを確かめます。
現場の担当者にとって、新しい仕組みは仕事を増やすものにもなります。記録が分析に役立つからといって、毎回長文を求めれば続きません。定型の結果は短い操作で済ませ、事情があるときだけ補足を残す。管理者向けの詳しい比較と、現場向けの次の行動を、同じ画面に詰め込みすぎないようにします。
この段階で見るのは、AIの正しさだけではありません。候補を受け取る人が決まっていなければ、先に役割を決める必要があります。担当者が動けなかった結果を、全部AIの誤検知として扱わないようにします。
例えば、候補を確認するまでの時間が長かった場合でも、理由は一つではありません。通知に気づかなかったのか、移動に時間がかかったのか、別の対応を優先したのか。受信、着手、到着を分けて残せば、画面を直す話と、人員や担当範囲を見直す話を切り分けられます。
一方、記録項目は増やしすぎないようにします。最初からすべての理由を入力してもらうより、日々の運用で迷う場面を確かめ、必要な項目を足す。現場で続く記録であることと、管理側が知りたいことの両方を満たす必要があります。
引き継ぎの場面も試したいところです。勤務が交代した後、次の担当者が未確認の候補と対応済みの件を区別できるか。画面を閉じた人の記憶にだけ結果が残っていないか。検知から対応までを一つの業務にする、というのは、担当者が替わっても続けられる形にすることでもあります。
検知件数が増えても、現場の確認が増えただけなら負担になります。空振りの確認が多ければ、ほかの仕事に使う時間が減ります。
評価では、人員数と巡回時間をそろえたうえで、次を見ます。
客引き対策なら、件数だけでなく、活動できる時間が減ったかも検証したいところです。ただし、別の場所へ移っただけなのに、解消したと数えないための観測範囲が必要です。
これらは現場で検証していく項目です。現時点で効果を断定することはできません。最初は一つの区域で、候補提示、現認、対応、再確認を通してみる。その記録があれば、AIを直すべきか、通知を速くするべきか、巡回の組み方を変えるべきかを判断できます。
同じカテゴリーの他の記事も読む
Copyright ©
HULIX Technologies, Inc.