EvoQuest
EvoQuest AI出動判断支援AI 2026.08

SCENARIO ── SNOW DISPATCH DECISION CASE

出るか、出ないか。
決める時刻を、前夜23時へ動かす。

シーズン契約120軒・オペレーター6人・重機5台の除排雪業者を想定します。契約書にあるのは「朝6時までに、降雪10cm以上で間口と車庫前に入る」の一行。この一行を守るために、社長は雪の夜ごとに何度も起きて、窓の外と気象台の数値を見比べています。方面ごとの降雪予測AI(EvoQuest AI)と、出動・見送り・午前1時に再判断の三択を確定してオペレーター6人へ通知する画面(EvoQuest Apps)を組み合わせる開発プランです。

想定領域
出動判断支援AI / 降雪予測
担当範囲
要件整理・予測AI設計・画面設計・実装
想定対象
シーズン契約100〜150軒・重機5〜6台の除排雪業者
想定期間
設計〜初雪の並行運用 約 3 ヶ月

OVERVIEW

プロジェクト概要

除雪と出動判断を検索して出てくるのは、内閣府の降雪対応の手引き、自治体向けの除雪管理GIS、道路管理者向けのAI路面判定です。ウェザーニューズは1時間ごと3日先までの路面積雪リスクを提供していますが、これも道路を管理する側の道具です。どれも10tダンプが何百台と動く世界のもので、シーズン契約120軒の会社が毎晩やっている「今夜、出るか」を支える道具は、その間にありません

この判断が重いのは、家庭向けのシーズン契約が定額だからです。1回出れば、6人の夜間の人件費と燃料が出ていきます。基準に届かない夜に出ても、その費用はどこにも請求できません。逆に、出なかった朝に積もっていれば電話が鳴りやまず、春の契約更新で軒数が減ります。片側は金額、片側は信用。通貨の違う2つの損を、社長は毎晩、窓の外の暗がりと突き合わせています。以前の出動ボードの開発プランでは、出動が決まったあとの号令と進捗を扱いました。このプランが受け持つのはその手前、決めるまでの夜です。

CHALLENGE

課題

  • 01 正確さと、間に合うことが、両立しない。朝3時に窓の外を見れば、判断はまず外れない。ただ、そこから6人に電話をかけて招集すると、作業が終わるのは通勤の車が動き出したあとになる。前夜のうちに決めれば間に合うが、23時にはまだ降り始めてもいない夜がある。
  • 02 基準は「朝6時までに10cm」の一本線なのに、測る場所が決まっていない。気象台の積雪計は中央区に1つ。コースは手稲・新発寒・西宮の沢の3方面に分かれている。石狩湾から筋状の雪雲が入った夜は、同じ札幌市内で降雪量が数十cm違うことがあり、気象台5cmの朝にコースだけ15cm積もっている。
  • 03 出て損する金額は見え、出なくて失う信用は数字にならない。定額契約なので、基準に届かなかった夜の人件費と燃料は持ち出しになる。出なかった朝に積もっていれば電話が集中し、契約更新に響く。どちらの損が大きいかを比べる材料がないまま、毎晩どちらかへ倒している。
  • 04 雪の夜は、社長が眠れない。23時、1時、3時と起きては、アメダスの数値と窓の外を見比べる。オペレーターも、招集の電話が来るかどうか分からないまま眠る。ひと冬の判断はすべて頭の中で行われ、外れた夜に何を見て決めたかは、どこにも残らない。

APPROACH

アプローチ

予測の前に、23時の時点で決まっていることを固めます。その時刻までに積もった雪は、もう予測の対象になりません。アメダスの観測と、札幌市が公開している区ごとの降雪量・積雪深。それに、方面に住むオペレーター2人が22時に自宅前で測って送る定点の報告。これを方面に割り付ければ、「いま何cmか」は実測で埋まります。予測AIが受け持つのは、その上に朝までへ何cm乗るかだけです。気象庁の「今後の雪」は6時間先までの降雪を1時間ごとに更新しているので、23時に開けば朝5時までの降り方が1時間刻みで見えます。作業は2時台に始まるため、判断の材料としてはこれで足ります。

答えは三択に絞ります。出動、見送り、午前1時に再判断。予測は方面ごとの範囲で出し、たとえば「手稲は朝6時までに7〜11cm」のように、基準の10cmと比べられる形にします。範囲の全体が基準を越えた方面は出動、届かない方面は見送り。範囲が基準をまたいだ方面があるときだけ、午前1時の再判断が選択肢に上がります。起きる夜を仕組みが指名し、それ以外の夜は朝まで眠る。海側の方面だけ出す部分出動も選べるようにします。契約の基準は各戸の前の雪なので、方面ごとに判定するほうが基準に忠実で、お客さんへの説明も立ちます。決めるのは社長のままで、AIが出すのは方面ごとの材料と、23時という期限です。

効果の測り方も先に決めます。的中率は使いません。出たのに朝の実測が基準に届かなかった出動の回数と、その人件費・燃料。見送った朝に基準を越えていた回数と、その朝の電話の件数。それから、社長が夜中に起きた回数。想定例の計算では、基準に届かなかった出動が1回およそ8万円で、ひと冬に4回あれば32万円です。この数字を夜ごとの台帳に残し、シーズン後に翌季の判断と契約の見直しへ戻します。

CONSULTATION

「今夜、出るか」を、窓の外と勘だけで決める冬を終わらせませんか。

基準に届かなかった出動の人件費も、見送って積もった朝の電話も、いまはどこにも記録が残っていません。
アメダスと札幌市の観測データは公開されていて、昨季の検証から始められます。
データの確認から予測AIの設計、前夜23時の判断画面まで、EvoQuestが設計します。

SCREENS

主要画面

想定する画面のサンプル。毎晩23時に社長が開く判断画面を中心にした構成です。地名は札幌市の実在の地区名を借りていますが、契約軒数・降雪量・金額はすべて想定例で、実在の会社・観測値とは関係ありません。

01. 前夜23時、三択で確定する

毎晩いちばん開く画面。方面ごとに、23時までに積もった実測と、朝6時までに乗る降雪の予測範囲、契約基準の10cm線が同じ物差しの上に並びます。範囲が基準を越えた方面には出動、届かない方面には見送りの判定が付き、社長は出動・見送り・午前1時に再判断の三択で確定します。確定と同時にオペレーター6人へ通知が届く構成。

出動判断
設計のポイント
積雪の数字を眺める画面にしない。23時の期限付きで、三択のどれかを選んで確定する画面にする。
実測と予測を分ける
すでに積もったぶんは実測で固定し、予測が受け持つ範囲だけを薄い塗りで示す。どこからが予測かを隠さない。
再判断の扱い
予測の範囲が基準をまたいだ夜だけ、午前1時の再判断を提案する。起きる夜を仕組みが指名し、それ以外の夜は朝まで眠る。

02. 方面ごとの実測と、朝までの降り方

アメダス、札幌市が公開する区ごとの観測、オペレーター2人が22時に自宅前で測って送る定点の報告。観測の点を3つの方面に割り付けて、1時間ごとの降り方を実測と予測に分けて棒で並べた画面です。気象台の数字とコースの体感がずれた夜に、どの観測を根拠に判定したかをここで確かめられます。

地点別実況
観測網の作り方
専用の機器を新設しない。公開データと、方面に住むオペレーターの定点報告で3方面をまかなう。
ずれを補正に使う
気象台とコースの差は夜ごとに記録し、方面別の補正としてAIの学習に戻す。
更新の頻度
気象庁「今後の雪」は1時間ごとに更新される。23時の判断と午前1時の再判断で、同じ画面を見る。

03. 降り止みから、集める時刻を逆算する

出動を決めたあとの「何時に集めるか」。降り止みの予想時刻と、コースごとの作業時間から、招集時刻の候補を3つ並べて終了見込みを出します。朝6時に間に合わない候補は赤く表示。早く出れば終わったコースに降り直しが乗り、遅く出れば間に合わない。この綱引きを終了見込みの時刻で見えるようにしました。

招集時刻
作業時間の根拠
コースごとの所要時間は昨シーズンの日報から実測で置く。理論値で組まない。
順番の入れ替え
降り止みが遅い夜は、通勤の早い地区のコースから先に終わらせる順へ、この画面で入れ替える。
号令との接続
招集を確定したら、出動ボード側の一斉連絡へそのまま渡す前提の設計。判断と号令を二重入力にしない。

04. 夜ごとの判断台帳

1晩1行の台帳です。23時の実測と予測範囲、選んだ判断、朝6時の実測、結果の4区分(出動して基準超え・出動したが基準未満・見送りで正解・見送りだが積もった)が並びます。外れた夜には風向きや雪雲の入り方をひと言残し、翌季の予測の材料とシーズン前の契約見直しに使います。

判断記録
結果は4区分
当たり外れの2択にしない。出た夜と見送った夜では、外れ方の意味も金額も違う。
記録の手間
実測と判断は自動で残る。人が書くのは、外れた夜のひと言だけ。
翌季への接続
台帳はシーズン報告書として出力し、契約単価や出動基準の相談に使える形にする。

05. 出動回数と、判断の成績

月ごとの集計画面。出動回数と平年との差、基準に届かなかった出動の回数と金額、見送りで積もった朝の回数と電話の件数、夜中に起きた回数が並びます。定額のシーズン契約では出動回数がそのまま採算を決めるので、残りシーズンの出動見込みもここで確かめます。

月次集計
金額に直す
基準に届かなかった出動は、1回ごとの人件費・燃料を掛けて金額で示す。回数のままでは翌季の材料にならない。
起きた回数を数える
再判断で起きた夜の数を数える。眠れた夜の数も、この仕組みの成績として扱う。
採算との接続
出動回数の見込みと契約軒数を並べ、翌季の値付けと受注数の相談材料にする。

OUTCOME

変わったこと

出動ボードのプランで変えたのは、決めたあとの号令でした。ここで変えるのは、決めるまでの夜の過ごし方です。

01

出動を決める時刻が、朝3時から前夜23時になる

Before社長が夜中に何度も起きて決め、3時すぎの電話リレーで6人を招集していた。オペレーターは招集があるかどうか分からないまま眠る。
After23時に三択で確定し、6人へ同時に通知が届く。見送りの夜は全員が朝まで眠り、迷う夜だけ午前1時の再判断が予定として決まっている。

早く決めるほど外れる危険は増えます。だから三択に再判断を残し、早く決めてよい夜かどうかを、予測の範囲が基準をまたぐかどうかで分けています。

02

気象台の1点ではなく、コースのある方面ごとに判定できる。

Before中央区の積雪計と窓の外だけを頼りに、3方面ぶんの出動をまとめて決めていた。
After方面ごとの実測と予測範囲で判定し、海側の2方面だけ出す部分出動が選択肢になる。

契約の基準は各戸の前に積もった雪にあります。方面ごとの判定は、出動した・しなかった理由をお客さんに説明するときの根拠にもなります。

03

判断の結果が、金額と回数で翌季に残る

Before外れた夜の記憶だけが残り、春には「今年は無駄な出動が多かった気がする」より細かい振り返りができなかった。
After基準に届かなかった出動が2回で16万円、見送りで積もった朝が1回、という台帳がそのままシーズン報告書になる。

想定例では、基準に届かなかった出動1回がおよそ8万円。ひと冬に4回で32万円になり、この金額が翌季にどちら側へ倒すかを決める物差しになります。

PROCESS

3ヶ月の進め方

オンラインでも進められますが、札幌市内・近郊なら事務所へ直接伺います。9月に始めて、初雪の前に並行運用へ入る3ヶ月です。

1
MONTH 01 / 要件整理 + 昨シーズンの復元

昨季の毎晩を、データで並べ直す月。

出動基準・契約内容・いまの判断の手順を聞き取り、昨季の出動日を請求書と日報から復元します。気象庁と札幌市の観測データは公開されていてさかのぼれるので、昨季の毎晩について「23時時点の材料だけならどう判定したか」を再現し、実際の判断と朝の積雪に突き合わせます。外れ方が分かってから、方面の分け方と観測の割り付けを設計します。

  • 出動基準・契約内容・判断手順の聞き取り
  • 昨季の出動日を請求書・日報から復元
  • 公開観測データでのさかのぼり検証
  • 方面の分け方と観測の割り付けの設計
2
MONTH 02 / 画面と通知の開発

判断の画面と、6人への通知を作る月。

出動判断・地点別実況・招集時刻・判断記録・月次集計の5画面と、三択の確定をオペレーター6人へ届ける通知を開発します。22時の定点報告は、方面に住むオペレーター2人と運用の形を決めて、雪が降る前に練習しておきます。予測の範囲をどのくらいの広さで出すかも、昨季の検証結果に合わせてここで調整します。

  • 判断・実況・招集・記録・集計の5画面の開発
  • 三択の確定をオペレーターへ通知する仕組み
  • 22時の定点報告の運用決めと練習
  • 予測の範囲の広さの調整
3
MONTH 03 / 初雪からの並行運用

通知を止めたまま、判断だけ並べて走らせる月。

初雪の月は、画面の判定と社長のいつもの判断を並べて記録するだけにします。招集は今までどおりの電話で行い、画面はまだ夜を預かりません。数夜ぶん並べてずれの傾向を直し、社長が「これなら」と言ってから通知を生かします。12月の本格シーズンからは、月次集計を月初に一緒に見る運用へ移ります。

  • 初雪からの並行運用(判断は従来どおり)
  • 画面の判定と実際の判断のずれの確認
  • 通知の切り替えと夜間運用の開始
  • 月次集計の初回レビュー

FAQ

よくある質問

  • Q1 出動の判断をAIに任せて、事故や苦情が起きたときの責任はどうなりますか?
    判断は社長に残します。仕組みが出すのは方面ごとの実測・予測の範囲・基準との比較と、23時という期限までで、三択を選んで確定するのは人です。出る・出ないの見極めはこの商売の中身そのもので、そこを自動判定に置き換えると現場が仕組みを信用しなくなります。出動ボードの開発プランでも同じ考え方を書きましたが、自動で動くのは通知と記録だけです。
  • Q2 気象庁の予報を見れば済むのでは?
    予報はすでにあります。気象庁の「今後の雪」は6時間先までの降雪を1時間ごとに更新していて、この仕組みも材料として使います。足りないのは、その予報を「うちの契約基準とコースでどうするか」に直す部分です。約5km格子の数字を方面に割り付け、基準の10cmと比べて招集時刻まで逆算する。ここが毎晩、社長の頭の中だけで行われてきました。その変換を画面にするのがこの開発プランです。
  • Q3 過去の判断なんて記録していません。それでも作れますか?
    作れます。気象のデータは公開のものがさかのぼって手に入ります。アメダスの1時間ごとの降雪と積雪、札幌市が公開している区ごとの観測。出動した日は請求書と日報から復元できます。最初の月にやるのはこの復元で、昨季の毎晩を1晩ずつ再現して、どのくらい判定できていたかを確かめてから先へ進みます。判定の成績が悪ければ、そこで正直にお伝えして設計を見直します。
  • Q4 方面ごとに出したり出さなかったりして、お客さんから不公平と言われませんか?
    契約の基準が「その家の前に10cm」なら、方面ごとの判定はむしろ基準に忠実です。気象台の1点で決めるほうが、降った方面を見送ってしまう危険が大きい。台帳には方面ごとの実測が残るので、「その朝、お宅の方面は8cmでした」と数字で説明できます。ただし、いまの契約書の文言と合っているかは最初の月に確認して、必要なら更新時の直し方まで一緒に考えます。
  • Q5 予測が外れて、出るべき夜に出そこねたら?
    外れる前提で組みます。予測は一本の数字でなく範囲で出し、範囲が基準をまたぐ夜は決め切らずに午前1時の再判断へ回します。初雪の月は通知を止めて、社長のいつもの判断と並べて記録するだけの並行運用にします。ずれの傾向を直してから通知を生かすので、いきなり仕組みに夜を預けることにはなりません。それでも見送りで積もった朝は起きます。その回数を台帳で数え続けることが、翌季の判断を直す唯一の材料になります。

「今夜、出るか」を、窓の外と勘だけで決める冬を終わらせませんか。

基準に届かなかった出動の人件費も、見送って積もった朝の電話も、いまはどこにも記録が残っていません。
アメダスと札幌市の観測データは公開されていて、昨季の検証から始められます。
データの確認から予測AIの設計、前夜23時の判断画面まで、EvoQuestが設計します。