官公庁・自治体の電話自動化｜AIの用途・調達仕様・運用設計

自治体の電話対応にボイスボットを導入するときは、「公開情報の案内」「担当課への取次」「個別の申請相談」を分けて考えます。開庁時間を案内する業務と、住民ごとの給付要件を判断する業務では、必要な情報も責任も異なります。

まずは対象を一つに絞り、回答する根拠と職員への引き継ぎ先を決めることが現実的です。本記事では、行政機関の担当者が企画・調達時に整理する項目を紹介します。

電話DXの目的を、住民と職員の両面から決める

官公庁の自動化には、庁内の転記・集計、申請処理、住民への問い合わせ対応など複数の領域があります。本記事が扱うのは電話での問い合わせ対応です。紙の入力作業や審査工程が課題であれば、電話のAI化とは別に、申請様式や処理手順の見直しが必要です。

電話DXは、すべての問い合わせをAIで完結させることではありません。住民が必要な案内や担当課へ到達しやすくなり、職員が個別事情の確認に時間を使える状態を目指します。まず、着信件数だけでなく、用件、時間帯、取次回数、通話後の記録時間を整理してください。

たとえば、朝の代表電話への集中と、閉庁後の一般案内では解決策が異なります。前者は担当課の振り分けと繁忙時の受付、後者は公開FAQと翌開庁日の折り返し管理を優先します。窓口予約やオンライン申請の改善だけで電話が減る場合もあるため、AI導入ありきで対象を決めないことが大切です。

自動化に向く問い合わせと職員へ渡す問い合わせ

電話で氏名を名乗っただけで、個別の行政情報を開示する設計にはしません。最初の導入では、個人情報を参照しない公開FAQから始める選択肢があります。

電話・チャット・Webをどう使い分けるか

Webは手順や書類を一覧でき、チャットは文字で質問できます。電話は画面操作が難しい住民にも利用できる一方、長い説明や複雑な選択肢には向きません。

自治体のAI活用事例を比較するときも、窓口案内のチャットと電話ボイスボットを混同しないことが重要です。たとえば文京区の「文京ごみナビ」は、区ホームページやLINEで利用するごみ分別支援サービスとして案内されています。これを電話対応の削減実績として扱うことはできません。

電話とWebを併用する場合は、電話だけで終えられる短い回答と、文書で確認した方がよい内容を分けます。SMSなど別チャネルを使う際も、受信可否と代替手段を用意します。

回答データに「有効期間」と「所管課」を持たせる

AIへの登録情報は、制度名、回答文、参照元、施行・終了日、担当課、承認者をセットで管理します。古い広報紙と現在のWebページが矛盾した場合に、AIが推測して回答しないようにします。

年度替わり、組織改編、受付期限、災害時の臨時対応は更新が集中します。更新担当者が不在のときに誰が代行するか、公開前の情報をどこまで登録するかも決めてください。

FAQを増やすだけでなく、回答を停止する条件も必要です。参照元にない質問、複数制度にまたがる質問、対象地区を特定できない質問は担当課へ渡します。

閉庁時間と担当課への取次を設計する

24時間の一次受付と、24時間の行政手続き完了は別です。夜間は公開情報を案内し、職員の確認が必要な相談は受付済みの用件として記録します。折り返しの目安は実際の開庁日と担当課の体制に合わせ、対応できない時刻を約束しないようにします。

担当課の振り分けでは、部署名ではなく住民の用件から分類します。「引っ越し」は住民票、保険、学校など複数の手続きにつながるため、最初の一課に転送するだけでは解決しません。相談内容を整理し、複数課が関係する場合の受付責任者を決めます。転送先が話し中・不在の場合の折り返し先も必要です。

AI受付、電話回線、転送先のすべてに容量や稼働条件があります。「何件でも受けられる」と想定せず、同時着信の上限、待ち呼、超過時の案内、既存番号の接続条件を事業者と確認します。有人対応を希望する住民には、利用可能な有人窓口と時間を明示します。

調達仕様書に書きたい8項目

1. 対象業務と自動回答しない範囲
2. 回答の参照元、更新権限、承認手順
3. 電話回線・既存番号・転送先との接続条件
4. 同時着信数、超過時の挙動、障害時の切替
5. 音声・文字データの保存、閲覧、削除、二次利用条件
6. 聞き返し、有人希望、外国語などへの対応範囲
7. 運用報告の項目と誤案内発生時の訂正手順
8. 契約終了時のデータ返却と設定の引き継ぎ

「セキュリティに配慮」「多言語対応」といった表現だけでは比較できません。実際に対応する言語、担当者への引き継ぎ、自治体の情報管理要件への対応を項目ごとに確認します。

検討用の運用例：ごみの問い合わせを一次受付する

以下は業務設計例であり、特定自治体の導入実績ではありません。

まず品目と地区を確認し、登録済みの分別ルールを案内します。同じ名称で材質が異なる品目は追加で確認し、判断できない場合は有人窓口へ渡します。収集の申込みを受け付ける場合は、案内と申込登録を別の処理として扱います。

閉庁時に有人確認が必要になったら、実際の窓口時間を案内して用件を記録します。AIが会話を続けて結論を作るより、確認できないことを明示する方が住民の再手続き負担を抑えられます。

住民向けの分かりやすさをテストする

自治体職員だけで試すと、制度名を知っている人の会話に偏ります。住民が使う言い方、長い説明、途中の訂正、聞き取りにくい地名などを含めて検証します。

• 制度名を知らず「引っ越したので手続きしたい」と話す
• 一つの電話で複数の用件を伝える
• 住所を途中で訂正する
• 自動案内ではなく職員と話したいと希望する
• 閉庁時に緊急性のある相談をする

転送後に同じ説明を最初から求められないよう、取得済み情報と未確認情報を分けて引き継ぎます。録音や要約にも誤りがあり得るため、職員が確認・修正できる運用にします。

効果は応答率と住民の用件完了を分けて測る

AIが電話に出た割合だけでは成果を判断できません。正しい案内で終了した件数、担当課への転送成功、同じ用件の再入電、誤案内、職員の確認工数を確認します。

一般案内の完了率と、申請そのものの完了率も別です。自動音声が答えていても、住民が申請方法を理解できなければ改善にはなりません。高齢者など属性だけで利用可否を決めず、聞き取りやすさと有人への戻り方をテストします。

予算と運用負荷を見積もる

比較する費用は月額利用料だけではありません。初期のFAQ整理、回線・転送、通話従量、外部システム連携、年度更新、職員の確認工数を含めます。複数社の提案は、同じ着信件数・平均通話時間・転送率を前提に比較してください。

初期費用を含む総費用と、職員の削減工数を並べて判断します。AIが受けた件数が増えても、要約修正や誤案内の訂正に時間がかかれば負担は減りません。試行前後で「通話＋後処理＋情報更新」の合計を測ることが重要です。

委託する場合も、制度情報を承認する責任までなくなるわけではありません。所管課は回答根拠と改定日を確認し、運用担当は登録・テスト・公開を管理します。ベンダーとの契約では、改定依頼への対応時間、緊急停止の連絡先、担当不在時の代理承認を決めます。

用途ごとの専門ガイド

• 申告窓口の繁忙期対策：日程案内・予約受付と、個別の税務相談を分ける設計。
• 災害時の電話受付：承認済み情報の更新、緊急連絡、通信障害への備え。
• 役所のカスハラ電話対応：正当な相談を妨げず、記録・引き継ぎ・職員支援を整える運用。

これらは一つの共通シナリオで済ませず、所管課と例外条件を用途別に決めます。

小規模導入から全庁展開へ

一つの課の公開FAQで試し、問い合わせが多い質問と回答できない質問を記録します。更新作業と引き継ぎの運用が安定してから対象課を増やします。

Bellを検討する際は、想定件数、対象業務、接続環境、データ管理要件、有人窓口の時間帯を共有してください。実装範囲と費用は個別に確認します。お問い合わせから要件整理をご相談いただけます。