自治体の担当課が住民からの要望・苦情に返す回答文を、受付の記録と計画・要綱・過去の回答から下書きし、公用文の表記と書いてはいけない個人情報を点検する

処理の起点を決める

起点は、担当者が事実のメモを書いて「下書きを作る」を押したことです。 回付の時点で自動に作らないのは、事実関係と方針が決まる前に下書きが出ると、その下書きが方針の代わりになってしまうからです。

メモの欄が空のときは、ボタンを押せないようにします。 「現在確認中です」と答えるだけの中間の回答を送るときも、「確認中で、○日までに改めて回答する」という事実をメモに書いてから下書きを作ります。

直した事実のメモで、何度でも作り直せるようにします。 課長の決裁で方針が変わったときは、メモを直して作り直します。下書きの文を手で継ぎはぎすると、2回目の点検を通らない文が残ります。 作り直すたびに、点検も同じ順で行います。

入力データを集める

質を決めるのは、事実のメモの書き方です。 メモには、「確かめた事実」「対応すること」「対応しないこと・できないこと」「時期」を分けて書きます。 時期は決まっているものだけを書き、決まっていなければ空にします。空の時期は、回答文に時期を書かないという指示につながります。

過去の回答は、文の調子をそろえるために渡します。 中身の材料には使わせません。過去の回答で約束していた対応を、今回の回答にも書いてしまうことがあるからです。

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

受付の仕組みと回答の台帳からの取り出しは、利用している仕組みに応じた個別の実装になります。 API が無い場合は、担当者の画面のボタンから受付番号を渡し、中継プログラムが仕組みの出力を読む形にします。

根拠文書の一覧は、課ごとに「分類 → 文書名・条や節・共有フォルダの場所」を並べた表です。 担当者は分類に合う候補から選ぶだけで、計画の全文をAIに渡すことはしません。 選んだ条や節の文だけを渡すので、回答に引かれる根拠が担当者の選んだ範囲に限られます。

過去の回答は、送付済みのものだけを使います。 決裁で差し戻された文や下書きのまま止まった文を混ぜると、直されたはずの書き方が戻ってきます。

2回目の呼び出しには、構造化出力のスキーマを付けます。 Chat Completions API なら response_format、Responses API なら text.format に JSON Schema を渡し、すべての項目を required に、オブジェクトごとに additionalProperties: false を付けます。 source と verdict は Enum で値を限り、モデルが「おおむねメモに基づく」のような中間の値を作れないようにします。出力の項目はスキーマの順に並ぶので、text と source_ref を判定の項目より前に置き、根拠を書いてから判定させる順にします。 1回目の下書きは自由な文で受け取り、スキーマは付けません。

AIへ渡す前に整形する

1. 申出人以外の個人の情報を見つける … 受付の記録の本文から、人名・住所・電話番号・車のナンバーなどを抜き出し、申出人本人の情報と分けます
2. 記号に置き換える … 申出人以外の個人の情報を「近隣の方A」「事業者B」のような記号にしてから渡します
3. 申出人本人の情報も最小限にする … 宛名は中継プログラムが最後に差し込み、本文の材料には渡しません
4. 事実のメモの項目を分ける … 事実・対応・対応しないこと・時期を、見出しを付けて渡します
5. 根拠文書の該当箇所に出典を付ける … 文書名と条・節の番号を、文の前に付けます
6. 過去の回答から固有名詞を除く … 台帳の回答に残る地名や施設名のうち、今回と関係の無いものを消します
7. 表記の規則を正規表現に起こす … 「ございます」、「？」「！」、読点の「、」と「，」の混在、全角と半角の数字の混在、4桁以上の数にコンマが無いもの、「箇所」と「か所」の混在などを、一覧の行ごとに式にします

1番目を軽く見ないでください。 申出人が「隣の○○さんが」と書いた名前は、受付の記録にそのまま残っています。置き換えずに渡すと、回答文に「○○様のお宅の前」と書かれます。 置き換えはAIではなく、受付の仕組みの項目と辞書と正規表現で行い、拾えなかったものは2回目の点検で拾います。

3番目は、宛名の誤りを防ぐためでもあります。 回答文の本文に申出人の名前を書かせると、受付の記録の中の別の名前と取り違えることがあります。宛名と敬称は、受付の記録の項目から差し込みます。

7番目の規則は、公用文作成の考え方に合わせつつ、市の文書の決まりで決めます。 例えば読点は、考え方では「、」を原則とし横書きでは「，」も使えるとされていますが、一つの文書内でどちらかに統一するとされています。市がどちらに統一するかを先に決め、規則の一覧に書きます。正規表現が拾った箇所は直さずに印だけを付け、直すのは担当者です。

AIに処理させる

1回目にさせるのは、事実のメモと根拠文書の該当箇所だけを材料に、公用文の書き方で回答文を組み立てることです。 2回目にさせるのは、その下書きの1文ずつが、どの材料に基づくかを判定することです。

1回目の文の順は、「お礼、結論、理由、今後の対応、問い合わせ先」に固定します。 考え方が示す「結論は早めに示し、続けて理由や詳細を説明する」に沿った順で、申出人がいちばん知りたい「要望はかなうのか」が冒頭の数文で分かるようにします。要望に応えられないときも、結論を後ろに回して理由から書き始めないようにします。

判定の表の4行目（apology_scope）は、苦情への回答で起きやすいものです。 申出人の書いた不満の全部に謝ると、市が誤りを認めていない事実まで認めた形になります。 謝罪はメモに「市の対応に誤りがあった」と書かれた事実に限り、それ以外は担当者が判断します。

指示内容を固定する

1回目の指示の例です。

あなたは市役所の担当課の職員として、住民からの申出に返す回答文の下書きを書きます。
読むのは申出をした住民本人です。

【材料】
- 事実のメモ（確かめた事実／対応すること／対応しないこと・できないこと／時期）
- 根拠文書の該当箇所（文書名と条・節が付いています）
- 過去の回答（文の調子の参考にだけ使ってください。中身を使わないでください）

【書き方】
1. 申出へのお礼、結論、理由、今後の対応、問い合わせ先の順に書いてください。
2. 結論を先に書いてください。
3. です・ます体で書き、「ございます」は使わないでください。
4. 一文を短くし、一文に一つのことだけを書いてください。
5. 専門用語は、言い換えるか短い説明を添えてください。

【厳守事項】
- 事実のメモに書かれていない対応・時期・数字を書かないでください。
  「時期」が空のときは、時期を書かないでください。
- 「検討します」「努めます」は、メモの「対応すること」にあるときだけ使ってください。
- 謝罪は、メモの「確かめた事実」に市の誤りが書かれているときだけ書いてください。
- 「近隣の方A」のような記号で書かれた人や事業者に触れないでください。
- 他の申出や、他の住民からの意見に触れないでください。
- 根拠文書は、渡した該当箇所だけを、文書名と条・節を付けて引いてください。
- 宛名と申出人の名前は書かないでください。後で差し込みます。

【申出の本文】{request_text}
【事実のメモ】{fact_memo}
【根拠文書の該当箇所】{documents}
【過去の回答】{past_replies}

「時期が空のときは時期を書かない」が、この指示の要です。 時期を書かないように言うだけでは、「早期に」「できる限り速やかに」のような時期を感じさせる言い回しで埋めます。2回目の点検の commitment で、この言い回しも約束として拾います。

2回目の指示は、「下書きの1文ずつについて、根拠にした材料を memo ／ document ／ courtesy ／ none から選び、約束・第三者の情報・謝罪の範囲を判定してください。材料に無い記載を、文脈から正しいと推測して memo にしないでください」という形で、下書きと材料と置き換えの一覧を並べて渡します。

出力形式を固定する

1回目は、本文の文字列で受け取ります。 2回目は、次の形のJSONで受け取ります。

{
  "request_id": "",
  "sentences": [
    { "no": 1, "text": "", "source": "memo | document | courtesy | none",
      "source_ref": "", "commitment": false, "commitment_in_memo": false,
      "third_party": false, "apology": false, "apology_in_memo": false }
  ],
  "verdict": "ready | needs_edit | blocked"
}

1つ目の理由は、1文ずつの根拠が残ることです。 担当者の画面では、下書きの各文の横に source_ref（メモの項目、または文書名と条・節）を並べ、根拠の無い文が一目で分かるようにします。

2つ目は、verdict を規則で決められることです。 AIの返す verdict はそのまま使わず、中継プログラムが次の規則で決め直します。

3つ目は、blocked を決裁に回せなくできることです。 blocked の下書きは、該当の文を担当者が消すか、事実のメモを直して作り直すまで、電子決裁への添付のボタンを押せないようにします。

システムへ連携する

申出人への送付は、自動にしません。 下書きから決裁、広聴の担当課の確認、送付までは、すべて人の操作で進みます。 受付の記録と回答の台帳にも、この構成からは書き込みません。

人が確認する

担当者は、下書きの全文を読み、1文ずつの根拠と点検の結果を見てから直します。

1. blocked の文を先に直す … 第三者の情報は消し、メモに無い約束は消すか、課内で決めてメモに足して作り直します
2. source が none の文を確かめる … あいさつ以外で根拠の無い文は、消すか、材料を足します
3. 表記の指摘を直す … 正規表現が拾った箇所を担当者が直します
4. 申出の全部に答えているかを見る … 申出が複数の事項を含むとき、答えていない事項が無いかを確かめます

4番目は、AIの点検では拾えません。 下書きはメモの範囲で書かれるため、メモに書き漏らした事項は回答からも抜けます。 申出の本文と回答を並べて読むのは、担当者の仕事として残します。

課長の決裁と、広聴の担当課の確認は従来どおり行います。 広聴の担当課は、点検の結果の画面を見られるようにし、needs_edit のまま決裁を通った回答だけを詳しく読みます。

目標は、200件をならして1件18分です。 メモを書いて根拠文書を選ぶ時間と、下書きを直す時間の合計です。直しの時間の大半は、blocked と none の文に使います。それより長い課は、メモの書き方か根拠文書の選び方に戻って見直します。

例外に対処する

3行目と4行目は、受付の時点で広聴の担当課が印を付けます。 印の付いた申出は、ボタンを押しても下書きを作らず、回す先を表示します。

記録を残す

• 受付番号、事実のメモの版、選んだ根拠文書の条・節、使った過去の回答の番号
• 置き換えの一覧（記号と元の値の対応は中継プログラムの中だけに保存し、閲覧を広聴の担当課に限る）
• 1回目の下書きの全文と、2回目の判定の全文
• 表記の規則で拾った箇所
• 担当者が直した後の文と、決裁で直された文
• 送付した最終の回答文

直した後の文を残すのは、下書きと最終の文の差を見るためです。 毎月、差の大きい分類を数え、根拠文書の一覧や事実のメモの書き方を見直す材料にします。 差が「約束の削除」に偏っていれば、メモの「時期」の書き方を課に案内し直します。