住民からの手続きの問い合わせに、AIとの対話で必要な書類と窓口まで案内する

処理の起点を決める

住民がチャット画面に最初の書き込みをしたときに始まります。 公式サイトのトップと、手続きの案内ページの上部に入口を置きます。電話と窓口では、職員が同じ画面を開いて住民の代わりに入力します。 電話の問い合わせも同じ記録に残ります。

1回の対話を1つのセッションとして扱います。 回答の生成は1往復ごとに answer メソッドを呼ぶ形で、複数回のやり取りにできます。途中で画面を閉じた場合は、そこまでの状況を捨てます。

月次の集計は、毎月1日の夜に動かします。 住民への回答の経路とは切り離し、集計が止まっても案内は止まらない形にします。

入力データを集める

質を決めるのは、上から2つ目と3つ目です。 聞き取りの項目が決まっていないと、AIは思いついた順に聞き、子どもの有無を聞き忘れたまま案内を終えます。

手続きの一覧表は、住民の出来事ごとに作ります。 「転入」「転出」「市内転居」「出生」「死亡」「婚姻」などの行に、条件（子どもがいる、国民健康保険に入っている、など）と手続きを並べます。表の1行が、案内に出る1つの手続きです。

担当課の連絡先は、案内ページとは別に持ちます。 回し先なので、検索に頼らず表から確実に引きます。

データの取得方法を決める

案内ページは、検索基盤のウェブサイトのデータストアで読みます。 索引の方式は、サイトマップと手動で指定したURLだけを索引にする方式（Sitemap Mode が Exact）を選びます。

3行目を選ぶのは、公式ページの更新に追随する責任を自分で持つためです。 自動の方式では、ページが直ってもいつ索引に反映されるかが決まりません。CMSのサイトマップを出発点にし、担当課がページを更新したらサイトマップを更新して索引を作り直します。

含めるURLは手続き案内の階層に限ります。 たとえば city.example.lg.jp/kurashi/tetsuzuki/* を含め、city.example.lg.jp/kurashi/tetsuzuki/archive/* を除きます。除くほうが優先されるので、過去の制度のページを確実に外せます。 動的なURLで同じ内容のページが増えると索引と保管の費用が大きく増えると注意されているので、検索結果のページや印刷用のURLも除きます。

手続きの一覧表と担当課の連絡先は、中継プログラムが起動時に読み込みます。

AIへ渡す前に整形する

1. 個人情報の検知 … 書き込みに電話番号、郵便番号、番地、生年月日、12桁の数字の並びが含まれていれば、生成AIへ送る前に伏せ字にし、入力しないよう画面で伝えます
2. 用件の振り分け … 手続きの問い合わせか、それ以外（苦情、道路の損傷の通報、ごみの収集日など）かを分けます。手続き以外は、その窓口の案内へ回します
3. 状況の項目の確定 … 聞き取った内容を、一覧表の選択肢のどれかに当てはめます。当てはまらない答えは、選択肢を示して聞き直します
4. 確かめる手続きの決定 … 状況の項目を一覧表の条件に当て、行を拾います。AIに手続きを足させません
5. 検索の問い合わせ文の組み立て … 手続きの名称と、状況のうち関係する項目だけを文にします。たとえば「国民健康保険の加入の手続き 転入 必要なもの 窓口」
6. 判断を求める質問の検知 … 「もらえますか」「対象になりますか」「いくらですか」のような問いを拾い、案内ではなく担当課への回し先として扱います

1番目を軽く見ないでください。 注意書きがあっても、住民は丁寧に書いてきます。入力させない設計と、送らない処理の両方が要ります。

4番目で手続きを決めるのは、表です。 AIに任せると一般的な手続きを並べ、この市に無い手続きまで出てきます。

AIに処理させる

AIにさせることは2つです。 1つは生成AIによる状況の聞き取り、もう1つは検索基盤による、案内ページを根拠にした回答の生成です。

検索基盤には、答えないための設定を最初から入れます。 関連性の低い内容、攻撃的な問い合わせ、質問でない書き込みに回答しない設定を有効にし、支持スコアが基準に届かない回答も返させません。

1行目がいちばん起きやすい失敗です。 住民は「子どもが生まれたら児童手当はもらえますか」と聞きます。答えは案内ページの対象者の欄から読めそうに見えますが、所得や養育の状況で変わる判断を、AIが「もらえます」と言い切ってしまいます。 案内は「申請の手続きと必要なもの」までにし、対象になるかは担当課へ回します。

指示内容を固定する

生成AI（聞き取り）への指示：

あなたは市役所の手続き案内の窓口で、住民の状況を聞き取る係です。
制度の説明や、手続きの案内そのものはしないでください。案内は別の仕組みが行います。

【聞く項目】{intake_items}
  （出来事ごとに、聞く項目と選択肢の一覧が入ります）

【聞き方】
- 1回の返事で聞くのは1項目だけにしてください。
- 選択肢があるものは、選択肢を示して選んでもらってください。
- 答えが選択肢に当てはまらないときは、推測で当てはめず、選択肢を示して聞き直してください。
- すでに答えてもらった項目は、もう一度聞かないでください。

【聞いてはいけないこと】
- 氏名、住所、電話番号、生年月日、個人番号、世帯の所得は聞かないでください。
- 住民がこれらを書いてきた場合は、内容を繰り返さず、
  「個人を特定できる情報は入力しないでください」とだけ伝えてください。

【してはいけないこと】
- 給付や減免の対象になるか、手続きが必要かどうかを判断しないでください。
- 金額や期限の扱いを答えないでください。
- 「もらえますか」「対象ですか」と聞かれたら、判断はできないことと、
  担当課で確認できることだけを伝え、聞き取りを続けてください。

【出力】次のJSONだけを返してください。
{"event": "", "answers": {}, "missing_items": [], "judgement_question": "", "next_question": ""}
- missing_items が空になったら、next_question は空にしてください。
- 判断を求める質問があれば、judgement_question にその文を写してください。

検索基盤の回答の生成に渡す指示（preamble）：

あなたは市の手続きの案内係です。検索結果に含まれる、市の公式の案内ページに
書かれていることだけで答えてください。

- 答えるのは、必要なもの（書類・持ち物）、手続きの窓口、受付時間、手続きの期限の4つです。
- 案内ページに書かれていない項目は「案内ページに記載がありません」と書き、補わないでください。
- ほかの自治体の例や、一般的な手続きの説明を加えないでください。
- 対象になるか、もらえるか、金額がいくらかは答えないでください。
- 窓口の名称と受付時間は、案内ページの表記をそのまま使ってください。
- 敬語で、箇条書きで答えてください。

聞き取りの指示に「1回に1項目」と書かないと、項目を全部まとめて聞きます。 住民は最初の2つにだけ答え、第3章の（a）の聞き漏れがそのまま起きます。

「案内ページに記載がありません」と書かせるのは、補わせないためです。 空欄のままにすると、生成の側が一般的な知識で埋めます。書かれていないという事実が住民にも見えれば、担当課に聞くきっかけになります。

出力形式を固定する

中継プログラムが住民へ返す前に組み立てる形は、次のJSONです。

{
  "session_id": "",
  "event": "転入",
  "answers": {
    "move_type": "市外からの転入",
    "household": "2人以上",
    "children": "未就学の子どもがいる",
    "insurance": "国民健康保険"
  },
  "procedures": [
    {
      "procedure_id": "P-012",
      "name": "国民健康保険の加入",
      "status": "answered | no_source | judgement_needed",
      "documents": [],
      "counter": "",
      "hours": "",
      "deadline": "",
      "source_urls": [],
      "support_score": 0,
      "skipped_reason": "",
      "department": { "name": "", "phone": "", "form_url": "" }
    }
  ],
  "judgement_question": "",
  "pii_masked": false
}

1つ目の理由は、手続きごとに status を持てることです。 全体を1つの回答にすると、答えられなかった手続きが見えなくなります。

2つ目は、status を規則で決められることです。 source_urls と skipped_reason は検索基盤の返り値からそのまま入れ、status は中継プログラムが表の条件で決めます。 生成の側に「答えられたか」を自己申告させません。

3つ目は、skipped_reason がそのまま月次の集計の材料になることです。 関連性の低い内容しかなければページが無い、根拠が弱ければページの書き方が足りないという意味になります。

システムへ連携する

公式サイトのCMSへは書き込みません。 ページを直すのは担当課の仕事です。案内の誤りをAIの側で直す経路を作ると、ページと案内が食い違ったまま運用が続きます。

申請の受付や予約の仕組みにはつなぎません。 手続きそのものは、窓口か既存の電子申請で行います。

人が確認する

住民への案内は、1件ずつ人が確かめてから出す形にはしません。 答えてよい範囲を根拠のページで閉じ、規則で確かめたものだけを返し、確認は事後の抜き取りに移します。

1. 担当課へ回ったものに対応する … no_source と judgement_needed のものは担当課の職員が対応します。判断が要る質問は、ここで初めて本人の事情を聞きます
2. 回答の記録を抜き取りで見る … 総務課が毎週一定数の answered を選び、案内の内容と根拠のページが一致しているかを確かめます
3. 食い違いを見つけたら止める … 案内とページが食い違っていれば、その手続きの行を一覧表で一時的に止め、担当課へ連絡します
4. 月次の集計を担当課へ返す … 答えられなかった質問を手続きごとにまとめ、ページの追記を依頼します

3番目の「止める」を、手順として持っておいてください。 誤った案内が1件見つかれば、同じ手続きの案内はすべて同じ誤りを含みます。行ごとに止めれば、ほかの案内は止めずに済みます。

抜き取りで見る数は、制度の改正で案内ページが書き換わる年度替わりの前に増やします。

例外に対処する

上から2行目までが大半を占めます。 どちらも仕組みの失敗ではなく、案内ページの不足の表れです。 回数を数えて担当課へ返します。

記録を残す

• 対話のセッションごとに、聞き取った状況の項目（選択肢の値だけ。自由記述は伏せ字にした後のもの）
• 手続きごとの status、根拠のページのURL、支持スコア、回答しなかった理由
• そのとき使った手続きの一覧表の版と、索引を最後に作り直した日時
• 担当課へ回したものについて、担当課の対応の結果（案内ページで答えられる内容だったか）
• 抜き取りで食い違いを見つけた記録と、止めた手続きの行
• 手続きごとの no_source の件数の推移

3つ目で一覧表の版と索引の日時を残すのは、誤案内の範囲を決めるためです。 誤りが分かったとき、いつからいつまでの案内に同じ誤りが含まれていたかは、この2つが無いと決まりません。

最後の行は、ページを直した効果の確かめにも使います。