富士市でAI活用を考えるとき、重要なのはAIにすべてを任せることではありません。地域の困りごとを受け付け、情報を整理し、責任を持つ人へ安全につなぐ仕組みが必要です。この記事では、FUJI PRESSが開発した高齢者サポートマッチングを参考に、通知キューと重複防止を解説します。取り上げる具体例は「買い物支援の担当決定通知」です。
要点
- 通知は案件IDと宛先を組み合わせて管理し、同じ確定連絡の重複送信を防ぎます。
- 送信要求、送信結果、再試行、既読確認を分けて記録します。
- 再送回数を制限し、届かない場合は電話など別経路へ人が切り替えます。
参考にした仕組み
高齢者サポートマッチングは、日常生活で困りごとを抱える高齢者と、地域の承認済みサポーターを、管理者が仲介する試作システムです。高齢者は音声または文字で依頼し、AIが内容を整理します。ただし、AIによる自動公開や自動マッチングは行いません。管理者が安全性と内容を確認してから公開し、応募者を比較して最終選定します。
基本フローは、依頼受付、AI整理、本人確認、管理者審査、限定公開、応募、選定、作業前チェック、作業、完了報告、管理者承認、利用者評価です。高齢者、サポーター、コーディネーター、管理者の役割を分け、マッチング前は氏名、電話、詳細住所、音声全文、管理者メモを候補者へ見せません。
この仕組みから学べるのは、AIの精度だけでは地域サービスは成立しないという点です。本人確認、権限、危険作業の除外、問題報告、保険、苦情窓口、監査記録まで含めて設計する必要があります。
富士市で考える意味
高齢者本人や離れて暮らす家族が、日常の小さな困りごとを誰へ頼めばよいか迷う場面はあります。一方、手伝える人がいても、個人同士で連絡先を公開し、事故や料金の問題まで当事者だけで扱う形には不安があります。
AIは、ばらばらな話し言葉を同じ項目へ整えることが得意です。しかし、住宅環境、健康状態、資格、保険、家族関係、緊急性を正確に判断できるとは限りません。地域支援では、便利さより「止められる」「人へ引き継げる」「後から確認できる」を優先します。
以下は富士市での運用を想定した架空例です。富士市や公的機関での導入実績を示すものではありません。実証時は、行政、地域包括支援センター、社会福祉協議会、自治会、民間事業者などとの役割整理が必要です。
具体例：買い物支援の担当決定通知
通信エラーで再送しても同じ確定通知を何度も送らないよう、送信履歴と識別子を確認する。
依頼受付
利用者の言葉をそのまま仕事として公開しません。何に困っているか、希望日時、依頼範囲、費用や道具、分からない点へ分けます。利用者自身が整理結果を確認し、違っていれば修正します。
AIによる整理
今回のAIの役割は「通知文と送信状態を整理する」ことです。断定ではなく、管理者が確認すべき質問を作ります。年齢や話し方から能力を推測したり、支援の優先度を勝手に採点したりしません。
人による安全確認
再送条件と緊急連絡を運営者が管理する。通常の地域サポートで扱えない内容なら保留または取消とし、専門事業者や緊急窓口など適切な相談先へつなぎます。
必要最小限の情報で募集
募集時は作業カテゴリ、概略地域、希望日時、所要時間、必要技能など、応募判断に必要な範囲だけを表示します。選ばれていない人へ詳細住所や電話番号を開示しません。
候補比較と選定
AIは技能、稼働日、距離などの一致点を整理できます。最終選定は本人の希望、作業経験、当日の安全、利益相反、移動方法を確認して人が行います。評価点だけで機械的に決めません。
作業と完了承認
開始前に依頼内容と現場の差を確認します。問題があれば作業を止めて管理者へ報告します。サポーターの完了報告だけで案件を閉じず、管理者が依頼範囲と問題の有無を確認して承認します。
AIに任せやすい仕事
- 音声の文字起こし
- 長い依頼文の要約
- 作業内容、希望日時、確認事項への分類
- 不足している質問候補の作成
- 条件が近い候補者の整理
- 通知文とチェックリストの下書き
- 完了報告と月次実績の集計補助
人が責任を持つ仕事
- 本人確認と意思確認
- 危険性、緊急性、資格の判断
- 公開、保留、取消
- サポーターの審査
- 最終マッチング
- 契約、料金、保険、事故、苦情対応
- 個人情報の開示範囲
- 完了承認と低評価案件の確認
AIの提案には誤りがあり得ます。「AIが選んだため」という説明で責任を曖昧にせず、各段階の承認者を記録します。
導入前に整える7項目
- <b>対象範囲</b>：買い物や軽作業など扱う依頼を限定する
- <b>除外範囲</b>：医療、身体介護、電気・ガス工事、多額現金、契約代行などを定義する
- <b>運営責任</b>：公開、選定、事故、苦情、緊急時の担当を決める
- <b>本人確認</b>：利用者とサポーターの確認方法を決める
- <b>個人情報</b>：取得目的、閲覧権限、保存期間、削除方法を決める
- <b>記録</b>：重要操作、連絡、問題報告、承認を残す
- <b>停止基準</b>：事故、誤配信、障害、苦情時の停止条件を決める
確認する指標
- 依頼受付から確認までの時間
- AI整理を人が修正した割合
- 情報不足で差し戻した件数
- 公開、保留、取消の内訳
- 応募から選定までの時間
- 作業前チェックで中止した件数
- 問題報告、低評価、相談希望の件数
- 利用者とサポーターの継続意向
- コーディネーターが一件に使った時間
成立数だけを成功指標にすると、危険な依頼まで成立させる圧力が生まれます。安全に保留・取消できた件数も、仕組みが働いた結果です。
まとめ
通知キューと重複防止で大切なのは、AIの回答を増やすことではなく、安全に止め、人が確認し、必要な相手へつなぐことです。「買い物支援の担当決定通知」でも、AIは整理を助けますが、公開、選定、安全、個人情報、完了承認の責任は人に残します。
富士市で試すなら、システム提供者だけで完結させず、現場運営を担う地域パートナーと役割を分け、小規模実証から始めることが現実的です。
関連プロジェクト
※本記事は情報提供です。個別の医療・介護・法律・保険判断を行うものではありません。緊急時はAIの返答を待たず、適切な緊急窓口へ連絡してください。
運用上の確認
Webhookや外部APIは同じイベントを再送する場合があります。イベントIDを保存して二重処理を避け、失敗時は間隔を空けて再試行します。順序が前後しても、古い状態で確定通知を上書きしない設計が必要です。
よくある質問
Q. なぜ同じ通知が複数届くことがありますか？
通信の再送、担当者の重複操作、処理完了前の再実行などが原因になります。案件IDとイベントIDで重複を判定します。
Q. 送信成功なら相手が読んだと考えてよいですか？
送信成功と既読・理解は別です。重要な連絡は応答期限を決め、反応がなければ有人確認へ切り替えます。
Q. 再送は何回まで行いますか？
連絡の重要度と時間帯に合わせて上限と間隔を決めます。無制限の自動再送は行いません。
Q. 通知に住所や健康情報を入れてよいですか？
ロック画面など第三者に見える可能性を考え、本文には必要最小限だけを載せ、詳細は認証後の画面で確認させます。