パブリックコメントに寄せられた意見を論点ごとに分けて同じ趣旨のものをまとめ、市の考え方の案を作る

処理の起点を決める

動かすきっかけは2つです。 意見募集の期間中は毎晩、その日に届いた意見を取り込んで論点に切り分けます。締め切りの翌朝に、全論点をまとめて同じ趣旨の候補を作り、要旨と回答の文案を書かせます。

論点の切り分けを期間中に済ませておくのは、締め切り後の時間を担当課の検討に回すためです。 意見は締め切り間際に集中するので、締め切り後に全件を一度に切り分けると、最初の一覧が出るまでに時間がかかります。まとめは全件がそろってからでないと意味がないので、締め切りの翌朝に一度だけ行います。

締め切り後に郵送で届いた意見も、消印などで期間内と確認できれば受け付ける運用があります。 その場合は、受付簿に追加された時点でもう一度まとめ直します。まとめ直しても、担当課がすでに確定させたまとめは動かしません。

入力データを集める

質を決めるのは、3つ目の考え方のメモです。 メモが無いと、回答の文案は計画案の文を言い換えるだけになり、「計画案に記載のとおりです」という答えが並びます。 担当課は意見募集の前に、出そうな論点（目標値、財源、対象地域、スケジュール）について、方針と根拠の箇所を数行ずつ書いておきます。

過去の一覧表は、文体と粒度をそろえるために使います。 根拠としては使いません。過去の回答を根拠にすると、今回の案で方針が変わった点まで過去の答えで書いてしまいます。

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

メールの添付ファイルは、文字を取り出してから本文に足します。 文書ファイルやPDFで意見を送る人がいるためです。画像だけのPDFで文字が取れないものは、人が文字に起こす側に回します。

計画案は、番号ごとの塊に分けて持ちます。 論点に該当箇所の候補を付けるとき、AIには計画案の全文ではなく、章・節の番号と見出しの一覧を先に渡し、候補になった節の本文だけを回答の文案のときに渡します。全文を毎回渡すと、要求が大きくなるうえ、関係の薄い節を根拠にした文案が出やすくなります。

埋め込みを作るのは、論点の原文の範囲です。 AIが書いた論点の言い換えを埋め込むと、言い換えの段階で似た表現にそろえられ、本来は違う論点どうしの類似度が上がります。 まとめの候補は、提出者が実際に書いた言葉の近さで作ります。類似度の基準の値は最初は高めに置き、担当課が「つなぐべきだった」と直した件数を見て下げていきます。

AIへ渡す前に整形する

1. 個人の情報を外す … 氏名、住所、電話番号、メールアドレスを本文から外し、受付番号で管理します
2. 定型の文を外す … メールの署名、フォームの設問の文、「以下、意見です」のような前置きを外します
3. 重複の確認 … 同じ人が同じ本文をフォームとメールの両方で送った場合を、本文の一致で見つけて印を付けます
4. 同文の意見の確認 … 違う人が同じ文面で送った意見は、重複ではなく同文として1件ずつ残します
5. 計画案の番号付け … 章・節・項の番号と見出しの一覧を作ります
6. 長さの確認 … 極端に長い意見（添付の資料を含むもの）は、段落で分けて論点の切り分けに渡します

3番目と4番目を分けるのが大事です。 同じ人の二重送信は1件として数えますが、違う人が同じ文面で送ったものは、それぞれが1件の意見です。 まとめて1件に減らすと、受け付けた意見の数が実際より少なく公表されます。逆に、同文の意見が多いことを理由に重く扱うこともしません。数は数として正しく残し、考慮は内容で行います。

1番目で外した情報は、受付簿にだけ残します。 公表する一覧表に提出者の名前は載せず、整理の作業にも要りません。

AIに処理させる

させるのは、3段階の作業です。 論点の切り分け、まとめの要旨、回答の文案で、それぞれを別の要求に分けます。

3行目の「違いを書き出す」が、この構成でいちばん大事な指示です。 埋め込みの類似度でまとめた候補には、言葉が似ているだけで論点の違うものが入ります。要旨だけを書かせると、違いを丸めた要旨が出ます。違いを別の欄に書かせれば、担当課はその欄を見て、分けるかどうかを決められます。

4行目で根拠が無いときに文案を書かせないのも、意図してのことです。 計画案にも考え方のメモにも答えが無い論点は、担当課が新しく考えるべき論点です。そこにAIがもっともらしい回答を書くと、検討されないまま公表されます。

3行目は、要旨の書き方にも出ます。 「多くの方から〜とのご意見」と書かせると、それだけで数の多さを強調する文になります。要旨に件数を入れず、件数は一覧表の別の欄に機械で数えて入れます。

指示内容を固定する

あなたは市の職員として、パブリックコメントに寄せられた意見の整理を手伝う立場です。
（まとめの要旨と回答の文案の段階の指示です）

【やること】
1. 【まとめの候補】に含まれる論点を読み、共通する趣旨を要旨として書いてください。
2. 含めた論点どうしで、求めていること・対象・理由が違う点を differences に書き出してください。
3. 違いが大きく、1つの要旨では一方の趣旨が伝わらないと判断したら、
   split_suggested を true にし、分け方の案を書いてください。
4. 【計画案の該当箇所】と【考え方のメモ】だけを根拠に、市の考え方の文案を書いてください。

【厳守事項】
- 要旨は、提出された意見の趣旨を変えずに書いてください。
  意見に書かれていない理由や評価を足さないでください。
- 要旨に件数や「多くの方」「一部の方」などの量を表す言葉を入れないでください。
- 要旨の各文について、根拠にした論点の point_id を示してください。
- 回答の文案は、計画案とメモに書かれていることだけを根拠にしてください。
  根拠が無い場合は文案を書かず、answer_status を needs_policy にしてください。
- 計画案を修正する・しないを、あなたが決めないでください。
  stance_candidate には、メモに書かれた方針から読み取れる候補だけを入れてください。
- 案と関係のない要望には回答を書かず、scope を out_of_scope にしてください。
- 文体は【書き方の手引き】に従ってください（敬体、要旨は100字程度）。
- 提出者の年齢、住所、立場を推測して書かないでください。

【まとめの候補】{group_points}
【計画案の該当箇所】{plan_sections}
【考え方のメモ】{policy_memo}
【書き方の手引き】{style_guide}

「量を表す言葉を入れない」を明記しないと、ほぼ必ず入ります。 まとめの候補に20件の論点が入っていれば、AIは「多くの市民から」と書き始めます。数の多さを要旨の言葉にしない、という市の方針を、指示の側で守ります。

「方針を決めない」と書いても、文案は方針を含みます。 回答の文は「〜します」「〜は考えていません」で終わるからです。そこで、文案の方針は考え方のメモから読み取れる範囲に限り、メモに無い方針は needs_policy で返させます。 メモが充実するほど、文案が使えるようになります。

出力形式を固定する

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

{
  "group_id": "",
  "summary": "",
  "summary_sources": [
    { "sentence_no": 1, "point_ids": [""] }
  ],
  "differences": [
    { "point_id": "", "what_differs": "" }
  ],
  "split_suggested": false,
  "split_plan": "",
  "scope": "plan | procedure | out_of_scope",
  "answer_status": "drafted | needs_policy",
  "stance_candidate": "reflect | already_included | future_reference | not_reflect | other | none",
  "answer_draft": "",
  "answer_basis": [
    { "source": "plan | memo", "ref": "" }
  ]
}

論点の切り分けの段階は、別のスキーマで point_id、quote_range（原文の範囲）、scope、plan_ref_candidates を返させます。原文の範囲は、本文の文字の位置で返させ、Python で本文から切り出します。 AIに原文を写させると、写すときに言い換えが混ざるためです。

1つ目の理由は、要旨の各文を論点にさかのぼれることです。 summary_sources があれば、担当課は要旨の1文ずつについて、どの意見の原文から来たかを開けます。趣旨が変わっていないかを、原文と並べて確かめられます。

2つ目は、1件だけの論点の行方を機械で追えることです。 Python で、すべての point_id が、どこかのまとめの summary_sources か differences に出てくるかを照合します。どこにも出てこない論点は、要旨から落ちたものとして一覧の先頭に出します。

3つ目は、回答の区分を担当課の欄と分けられることです。 stance_candidate は候補で、一覧表の「区分」の欄は担当課が埋めます。整理表では両方を並べ、候補と確定が違った件数を数えます。

システムへ連携する

公表する一覧表は、整理表から人が作ります。 整理表には point_id、類似度、候補の区分など、公表しない列が多くあります。整理表をそのままホームページに載せる経路は作りません。

計画案の文書は読むだけです。 意見を受けて計画案を直すのは担当課で、この構成から案の文書へは書き込みません。

人が確認する

担当課が見る順番を、整理表の並びで決めておきます。

1. どのまとめにも出てこない論点を先に見る … 要旨から落ちた論点です。どこかのまとめに入れるか、単独の行にします
2. split_suggested のまとめを見る … 違いの欄を読み、分けるかどうかを決めます
3. 要旨を原文と並べて読む … summary_sources から原文を開き、趣旨が変わっていないかを確かめます
4. needs_policy の論点を検討する … メモに無い論点です。ここが担当課の本来の検討の中心になります
5. 文案を直し、区分を付ける … 文案は根拠の箇所と並べて読み、市の考え方として確定させます
6. 政策企画課が様式と書き方を確かめる … 要旨に量を表す言葉が残っていないか、個人の情報が残っていないかも見ます

3番目を省かないでください。 要旨の誤りは、提出者から見ればすぐ分かります。自分の意見が違う意味でまとめられた一覧表は、意見募集そのものへの信頼を損ないます。

4番目に時間が残ることが、この構成の目的です。 並べ直す作業が減った分、新しい論点の検討と、関係課との調整に時間を使います。

例外に対処する

6行目は、AIで判断させません。 公表する一覧表から除くかどうかは、市の要綱と個別の事情で決まります。AIには「個人を名指ししている可能性がある」という印を付けさせるまでにします。

8行目は、公表の段階で効いてきます。 一覧表の「該当箇所」は、意見を寄せた人が見た案の番号で書かないと、提出者が自分の意見を探せません。

記録を残す

• 意見の原本（フォームの回答、メール、紙・ファクスのスキャン）と受付簿
• 前処理で外した個人の情報は受付簿にだけ残し、整理の作業のデータには残さない
• 論点の切り分けの結果（point_id、原文の範囲、scope、該当箇所の候補）
• 埋め込みの類似度と、まとめの候補の構成
• AIが返したJSONの全文と、使ったモデルのデプロイ名
• 担当課がまとめを分けた・つないだ記録と、要旨と文案をどう直したか
• 確定した一覧表と、決裁の記録

6つ目は、次の意見募集の質を上げる材料になります。 担当課がどのまとめを分けたかを数えると、類似度でまとめる基準の値が粗すぎるか細かすぎるかが分かります。基準の値は分野ごとに変えてかまいません。

整理表と確定した一覧表の両方を残すのは、後から問い合わせがあったときのためです。 「自分の意見がどこに入ったか」と聞かれたら、受付番号から point_id、まとめ、一覧表の行までをたどれます。