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

プロジェクト概要

対象は、住宅の除排雪をシーズン契約で請け負う会社です。契約先がある方面ごとの観測値と降雪予測をまとめ、今夜出動するかを社長が判断するための画面を作ります。出動基準やコース、作業時間を登録し、自社の契約に合わせて確認できるようにします。

この判断が重いのは、家庭向けのシーズン契約が定額だからです。1回出れば、6人の夜間の人件費と燃料が出ていきます。基準に届かない夜に出ても、その費用はどこにも請求できません。逆に、出なかった朝に積もっていれば電話が鳴りやまず、春の契約更新で軒数が減ります。出動費用と、対応が遅れた場合のお客様への影響の両方を考えて判断する必要があります。以前の出動ボードの開発プランでは、出動が決まったあとの号令と進捗を扱いました。このプランでは、出動を決めるまでの情報収集と判断を支援します。

CHALLENGE

課題

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

APPROACH

課題への対応

まず、23時までに観測できた降雪量を整理します。その時刻までに積もった雪は、もう予測の対象になりません。アメダスの観測と、札幌市が公開している区ごとの降雪量・積雪深。それに、方面に住むオペレーター2人が22時に自宅前で測って送る定点の報告。観測地点を方面ごとに整理し、現在の降雪量を確認します。予測AIの出番は、朝までにさらに何cm降るかだけです。気象庁の「今後の雪」は6時間先までの降雪を1時間ごとに更新しているので、23時に開けば朝5時までの降り方が1時間刻みで見えます。この予報だけでは朝6時までをカバーできないため、画面には予報の対象時刻を明示し、その先の予測とは区別して表示します。

答えは三択に絞ります。出動、見送り、午前1時に再判断。予測は方面ごとの範囲で出し、たとえば「手稲は朝6時までに7〜11cm」のように、基準の10cmと比べられる形にします。範囲の全体が基準を越えた方面は出動、届かない方面は見送り。範囲が基準をまたいだ方面があるときだけ、午前1時の再判断が選択肢に上がります。再確認が必要な夜と時刻をあらかじめ決め、夜間の確認負担を減らすことを目指します。海側の方面だけ出す部分出動も選べるようにします。契約の基準は各戸の前の雪なので、方面ごとに判定するほうが基準に忠実で、お客さんにも判断の根拠を説明しやすくなります。判断は社長に残し、AIは方面ごとの予測を示し、画面には判断の目安時刻である23時を表示します。

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

CONSULTATION

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

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

SCREENS

主要画面

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

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

毎晩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区分
出動・見送りと、基準以上・未満の組み合わせを4区分で記録し、それぞれの費用や影響を確認する。
記録の手間
実測と判断は自動で残る。人が書くのは、外れた夜のひと言だけ。
翌季への接続
台帳はシーズン報告書として出力し、契約単価や出動基準の相談に使える形にする。

05. 出動回数と、判断結果

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

月次集計
金額に直す
基準に届かなかった出動について、その回の人件費と燃料費を合計する。回数と費用の両方を翌季の判断に使う。
起きた回数を数える
再判断で起きた夜の数を数える。夜間の確認が不要だった夜の数も、負担の変化を測る指標にする。
採算との接続
出動回数の見込みと契約軒数を並べ、翌季の値付けと受注数の相談材料にする。

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

AI相談窓口

EvoQuestについて、
気になることを聞いてください。

サービスの内容や制作実績、
費用の目安などをご案内します。

AIが回答します。個人情報・機密情報は入力しないでください。入力内容は回答のためにAI提供元へ送信されます。利用について(新しいタブ)

直接お問い合わせ

会話はこのタブに一時保存されます。