市役所の税務課に届く住民税・固定資産税の問い合わせメールに、条例・手引き・過去の回答から回答案を作り、職員の確認に回す

処理の起点を決める

フォームの送信とメールの受信を、そのつど起点にします。 1日1回まとめる形にはしません。通知書の発送後は1日に数十件届くため、まとめると朝の一覧が長くなり、(d)の遅れがそのまま残ります。

フォームは送信のたびに受付の一覧へ書き込み、メールは共有メールボックスへの着信を Azure Functions が受け取ります。どちらの経路で届いても、同じ受付番号の体系に載せます。 経路ごとに一覧が分かれると、同じ人がフォームとメールで二重に送ってきたときに気づけません。

自動返信は、受付の確認だけにします。 「受け付けました。回答には数日かかることがあります。個別の税額のお問い合わせは、ご本人の確認のため電話または窓口でお受けしています」という定型文を返し、AIの回答案を自動で送ることはしません。

入力データを集める

質を決めるのは、過去の回答の入れ方です。 送信済みのメールをそのまま入れると、住民の氏名や住所、個別の税額がそのまま検索の対象になります。 過去の回答は、質問と回答の一般的な部分だけを書き起こし直し、係長が承認したものだけを入れます。

フォームには「お名前」「ご連絡先」の欄がありますが、AIには渡しません。 回答案を作るのに氏名は要らないからです。返信の宛先は、受付の一覧の側で持ちます。

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

条例・規則は、例規集で公開している本文を条ごとに分けて取り込みます。1つの文書を条単位に分けておくと、回答案の根拠を「第何条」で示せます。 手引きは節ごとに分け、版と改訂日を付けます。

索引は、文書が変わるたびに作り直します。 条例の改正、手引きの改訂、過去の回答の追加のたびに、Azure Functions が索引を更新します。索引の各文書には「いつの版か」を持たせ、改正前の版は検索の対象から外します。

検索は、論点ごとにハイブリッド検索で上位を取ります。取る件数は論点あたり5件ほどに絞ります。 多く渡すほど、関係の薄い文書を根拠にした文が混ざります。

論点ごとの検索の要求は、次のような形になります。search に論点の要旨を、vectorQueries に同じ要旨の埋め込みを入れ、税目と「最新の版か」をフィルターで絞ります。

{
  "search": "年の途中で家屋を売却した場合の固定資産税の納税義務者",
  "vectorQueries": [
    { "kind": "vector", "vector": [0.0], "k": 50, "fields": "contentVector" }
  ],
  "filter": "tax_type eq 'fixed_asset' and is_current eq true",
  "select": "doc_id, doc_type, title, article, content, revised_on",
  "top": 5
}

select で返す欄は、人が読める本文と根拠の表示に要るものだけにします。 doc_type には「条例」「規則」「手引き」「過去の回答」を入れておき、確認画面で根拠の種類が分かるようにします。同じ内容が条例と手引きの両方にあるときは、条例の条を先に示すように並べ替えます。

AIへ渡す前に整形する

1. 番号を伏せる … 12桁のマイナンバー、宛名番号、通知書番号、口座番号に当たる並びを ［番号］ に置き換えます
2. 氏名・住所を外す … フォームの氏名・住所の欄は渡しません。本文中の住所は町名までに丸めます
3. 引用の除去 … メールの返信で付いてくる過去のやり取りを切り落とし、新しい本文だけにします
4. 添付の扱い … 通知書の写真などの添付はAIに渡さず、「添付あり」の印だけを付けます
5. 重複の検知 … 同じ送信元から同じ内容が短時間に届いたものを束ねます
6. 長さの確認 … 極端に長い本文は、質問の部分だけを先に人が確かめる扱いにします

4番目は省かないでください。 納税通知書の写真には、氏名・住所・税額・宛名番号が全部写っています。添付をAIに渡すと、伏せたはずの情報が画像のまま入ります。 添付があった問い合わせは、ほぼ個別の質問なので、そのまま本人確認の経路へ回す候補にします。

AIに処理させる

させるのは2段です。 1段目で質問を論点に分けて個別の中身に触れるかを判定し、2段目で引いた文書だけを根拠に回答案を作ります。

個別の中身に触れる、の判定の例です。

最後の行のような混在が、実際には多くあります。 一般的な手続きの説明は書き、亡くなった方の課税の中身は書かずに窓口へ案内します。論点ごとに判定を分けるのは、この混在を扱うためです。

指示内容を固定する

あなたは市役所の税務課で、住民からの問い合わせへの回答案を作る担当です。
渡された【参照文書】だけを根拠にしてください。
あなたが知っている税の知識で補わないでください。

【1段目で付けた論点と判定】{issues}
  各論点に scope（general ／ individual）が付いています。

【回答案の書き方】
- scope が general の論点だけ、回答の文を書いてください。
- 文ごとに、根拠にした参照文書の doc_id と、
  根拠にした箇所をそのまま写した quote を付けてください。
  quote は参照文書の文字列と一字一句同じにしてください。
- 参照文書に根拠が無い論点は、文を書かず status を no_source にしてください。
- scope が individual の論点には、文を書かないでください。
  guide_id に案内の定型文の番号だけを入れてください。
- 個人の税額を計算したり、推定したりしないでください。
  「おそらく」「一般的には高くなります」のような書き方もしないでください。
- 減免や課税の取消ができるかどうかを書かないでください。
  手続きの名前と窓口だけを書いてください。
- 日付と月は、参照文書に書かれたものをそのまま写してください。
  市の条例で定める納期は、参照文書の条例の条から写してください。
- 問い合わせの本文にある［番号］の部分には触れないでください。
- 住民に向けた丁寧な文体で書いてください。
  ただし、条文の言葉を言い換えて意味を変えないでください。

【問い合わせ】{inquiry}
【参照文書】{documents}
【案内の定型文の一覧】{guides}

「あなたが知っている税の知識で補わない」を最初に置く理由は、税の質問ほどモデルが答えを知っているからです。 一般的な地方税の知識で書いた文は、その市の条例の納期や手続きと食い違うことがあります。根拠を参照文書に限ることで、職員が確かめる先が1つに決まります。

quote を一字一句同じにさせるのは、後段で機械的に照合するためです。 写しが文書に無ければ、その文は根拠が無いものとして案から外します。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "inquiry_id": "",
  "tax_type": "resident | fixed_asset | city_planning | other | unknown",
  "issues": [
    {
      "issue_id": "",
      "summary": "",
      "scope": "general | individual",
      "status": "answered | no_source | guided | needs_human",
      "sentences": [
        { "text": "", "doc_id": "", "quote": "" }
      ],
      "guide_id": ""
    }
  ],
  "has_attachment": false,
  "draft_greeting": "",
  "draft_closing": ""
}

1つ目の理由は、論点ごとに判定と回答を分けて持てることです。 混在した質問でも、一般の論点には文があり、個別の論点には案内の番号だけがある形で受けられます。職員は、どの論点が案内に回ったかを一目で確かめられます。

2つ目は、根拠の照合を規則で書けることです。 Azure Functions が quote を参照文書の本文と照らし、見つからない文には印を付けて画面で赤く出します。

構造化出力では、スキーマのすべてのフィールドを必須にし、オブジェクトに additionalProperties: false を設定する必要があるとされています。 使わない欄は空文字や空の配列で返させます。文字数の上限や正規表現のような maxLength・pattern は使えないとされているので、長さや形式の確認はプログラムの側で行います。

3行目は、プロンプトで禁じたことが守られなかった場合の受け皿です。 指示だけに頼らず、出力の側でも個別の論点の文を捨てます。

システムへ連携する

Azure OpenAI の「On Your Data」の機能は使いません。 公式の説明では、持ち込みデータのシナリオでは構造化出力がサポートされていないとされています。検索は Azure Functions の側で行い、引いた文書をプロンプトに入れて渡します。 こうすると、どの文書を渡したかを記録にも残せます。

人が確認する

全件を人が確かめます。 減らすのは探す時間と書く時間で、確認そのものは減らしません。

1. 個別の論点を先に見る … individual と判定された論点が本当に個別か、逆に general の中に個別の中身が混ざっていないかを見ます
2. 根拠の写しを見る … 画面で文と写しを並べ、写しがその文の言っていることを本当に支えているかを確かめます
3. 日付と月を見る … 納期・期限・受付時間は、条例と手引きの最新の版と照らします
4. 直して係長に回す … 直した箇所は、どの文をどう直したかが記録に残ります
5. 係長が確かめて、職員が送る … 送信は共有メールボックスから職員が行います

1番目がいちばん大事です。 general の中に「あなたの場合は」のような文が混ざっていれば、それは個別の中身に触れています。迷ったら案内の文面に置き換えます。

目標は、1件5分です。 案が根拠付きで出ているので、探す時間がほぼ無くなり、確かめて直す時間が中心になります。

係長の確認は、職員が直した箇所を中心に見ます。 確認画面では、AIの案から職員が変えた文に色を付けて出し、照合で外れた文と個別の論点を一覧の先頭に並べます。変えていない文と照合を通った文は流し読みにし、判断の入った箇所に時間を使います。

例外に対処する

3行目は、毎年4月前後に必ず起きます。 税制改正は年度単位で入るので、条例と手引きを改訂した日に、改正前の過去の回答を検索の対象から外す作業を手順に入れておきます。

最後の行の止まり方も決めておきます。 生成AIが止まっても受付の登録だけは続くようにし、未処理の問い合わせが受付の一覧から消えないことを優先します。復旧したあとに未処理分をまとめて流すと、古い問い合わせほど後回しになるので、届いた順に処理し直します。

記録を残す

• 問い合わせの受付番号、届いた日時、経路、伏せた後の本文
• 1段目の論点と判定、2段目の回答案（JSONの全文）
• そのとき渡した参照文書の doc_id と版
• 根拠の照合の結果（外れた文と理由）
• 職員と係長が直した箇所 … どの文を、どう直したか
• 送った文面と送った日時、送った職員

伏せる前の本文は、AIの記録には残しません。 原本は共有メールボックスとフォームの受付に残っているので、記録の側に同じ個人情報を二重に持たないようにします。

直した箇所の記録は、検索とプロンプトを直す材料になります。 同じ論点で毎回同じ直しが入るなら、手引きの書き方か、過去の回答の入れ方に原因があります。