住民アンケートの自由記述を施策ごとに分類し、意見の集約と代表的な声の一覧を作る

処理の起点を決める

毎日の夜に1回、前日分の回答を処理します。 回答が送信されるたびに動かす方法もありますが、同じ人が続けて何度も送る重複を、1日単位のほうが見分けやすいためです。Google Apps Script の時間主導型のトリガーで、毎日決まった時間帯に動かします。

動く時刻は、ちょうどではありません。 Google のドキュメントでは、毎日9時のトリガーを作ると9時から10時の間のどこかの時刻が選ばれ、その時刻が日々保たれるとされています。「夜の1時間のどこか」と考えて、職員の出勤前に終わる時間帯を選びます。 また、トリガーは作った人のアカウントで動くとされています。担当者個人のアカウントで作ると、異動したときに止まるので、課で管理するアカウントで作ります。

月末の集約は、別のトリガーで動かします。 月の最終日の翌朝に、その月の分類結果を施策ごとにまとめ、要旨と代表的な声の候補を作ります。日次の分類と月次の集約を分けておくと、どちらかが失敗しても、もう一方をやり直すだけで済みます。

処理済みの印は、回答のシートの側に付けません。 各課のシートは各課のものなので、書き込むと各課の集計を壊すおそれがあります。分類結果のシートに回答のIDを持たせ、そこに無いIDだけを未処理として拾います。

入力データを集める

質を決めるのは、施策の一覧の「含まれる例、含まれない例」です。 施策名は「安心して子育てできるまち」のように抽象的なので、名前だけでは「通学路の歩道」がここに入るのか道路の施策に入るのかが決まりません。第3章の（a）で3名の判断が分かれた例を、そのまま「含まれる例、含まれない例」に書き込みます。 担当者の暗黙の判断を、一覧の側に移すということです。

設問の情報も渡します。 同じ「対応が遅い」という記述でも、窓口の満足度調査なら窓口の施策、イベントのアンケートならそのイベントの施策です。どの設問への答えかが分からないと、分類の手がかりが半分になります。

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

各経路のスプレッドシートを、Google Apps Script から読みます。 経路ごとの設定表に、シートのIDと、自由記述の列、送信日時の列、設問の文を書いておきます。新しいアンケートを分類の対象に加えるときは、設定表に1行足すだけにします。

施策の一覧は、毎回その時点の内容を読みます。 施策の見直しは年度の途中でも起きます。一覧を処理の中に書き込んでしまうと、見直しの後も古いコードで分類し続けます。 一覧から列挙の値を毎回作り、スキーマに入れます。

AIへ渡す前に整形する

1. 空の回答を除く … 空欄、「特になし」「なし」「とくにありません」だけの回答は、分類に回しません
2. 重複を除く … 同じ経路で、同じ本文が短い時間に続けて送られたものは1件にまとめます
3. 個人の情報を伏せる … 氏名らしい記述、電話番号、メールアドレス、住所の番地を ［氏名］ のような記号に置き換えます
4. 長すぎる回答を確かめる … 数千字の回答は、それだけ別に処理します。ほかの回答とまとめて送ると、その1件に引きずられます
5. まとめて送る単位を決める … 1回の呼び出しに20件ずつ、回答IDを付けて渡します
6. 列挙の値を作る … 施策の一覧からコードの一覧を作り、「該当なし」を1つ足してスキーマに入れます

3番目は、Gemini に渡す前に行います。 伏せ字をAIに任せると、伏せる前の本文が外に出ます。住民が自由記述の欄に自分の名前や電話番号を書くことは珍しくありません。 「連絡してほしい」という意図で書かれた連絡先は、伏せたうえで、担当課への通知の側に元の回答IDで結び付けます。

6番目の「該当なし」を省くと、無理に近い施策へ入れます。 市の施策と関係のない意見（国の制度への意見、民間の店舗への苦情など）は、どこにも当てはまらないことを答えとして選べるようにしておきます。

AIに処理させる

させるのは、回答を意見の単位に分け、意見ごとに決まった一覧から値を選ぶことです。 日次の分類で選ぶのは次の5つです。

右端の列の review が、この構成で最も大事な値です。 緊急の要否で迷ったときに「否」を選ばせると、見逃した1件は月末まで誰の目にも触れません。 迷ったら人に回す値を、あらかじめ用意しておきます。

月末の集約でさせるのは、施策ごとに2つのことです。 1つは、その月の意見の要旨を3文以内で書くこと。もう1つは、意見の中から代表的な声の候補を原文のまま5件選ぶことです。候補には、その声が施策の中で多数の意見に近いのか、少数だが重要な意見なのかの区分を付けさせます。

3行目を機械の集計にしているのは、AIに件数を書かせると、要旨の文に合わせて数が丸まるからです。 「多くの意見が」と書いた要旨の横に、実際には3件しかない、ということが起きます。件数は関数で数え、AIには件数を渡したうえで要旨を書かせます。

指示内容を固定する

あなたは市役所の企画政策課で、住民アンケートの自由記述を
総合計画の施策ごとに整理する職員を補助します。

【作業】
渡した回答を1件ずつ読み、次のことをしてください。
1. 1つの回答に別々の事柄が書かれていれば、意見の単位に分けてください。
   分けたそれぞれに、元の本文の該当部分をそのまま text に写してください。
2. 意見ごとに、【施策の一覧】から最も当てはまる施策を1つ選んでください（main）。
   2つ目に関係する施策があれば、1つだけ選んでください（sub）。
3. 意見の種類を、要望・苦情・評価・提案・質問から選んでください。
4. 【緊急の基準】に当たるかを判定してください。

【厳守事項】
- 施策は【施策の一覧】のコードから選んでください。一覧に無い見出しを
  作らないでください。どれにも当たらなければ NONE を選んでください。
- 施策を選ぶときは、施策名ではなく「含まれる例」「含まれない例」を
  手がかりにしてください。
- 設問の文と所管の課も手がかりにしてください。同じ「対応が遅い」でも、
  窓口の満足度調査なら窓口の施策です。
- text は、元の本文を写してください。要約や言い換えをしないでください。
- 緊急の基準に当たるか迷ったら、urgent を review にしてください。
  迷ったときに no を選ばないでください。
- ［氏名］［電話］などの伏せ字は、そのままにしてください。
  元の内容を推測しないでください。
- 意見の良し悪しや、施策への評価を書かないでください。
- confidence には、施策の選択にどれだけ確信があるかを high / low で
  入れてください。「含まれる例」に近い例が無ければ low にしてください。

【設問】{question}（所管：{department}）
【施策の一覧】{policy_list}
【意見の種類の定義】{opinion_types}
【緊急の基準】{urgent_rules}
【回答】{responses}

「施策名ではなく例を手がかりに」を明記しないと、名前の語感で選びます。 「安心・安全なまち」という施策名があれば、安全という語が入った意見を何でもそこへ入れます。判断の根拠を、担当者が書いた例の側に置かせます。

「迷ったときに no を選ばない」は、緊急の判定の要です。 生成AIは、判断に迷うと穏当な側を選ぶ傾向があります。緊急の判定では、穏当な側が見逃しの側です。 そこで、迷った場合の値を指示の中で指定します。

出力形式を固定する

日次の分類は、次の形のJSONで受け取ります。

{
  "results": [
    {
      "response_id": "",
      "opinions": [
        {
          "text": "",
          "main": "P-2-3 | NONE",
          "sub": "",
          "type": "request | complaint | praise | proposal | question | other",
          "urgent": "no | yes | review",
          "urgent_reason": "",
          "confidence": "high | low"
        }
      ]
    }
  ]
}

main と sub の値は、施策の一覧から作った列挙です。P-2-3 は「基本目標2の施策3」のような施策のコードで、42個のコードと NONE のほかは返らないようにスキーマで限ります。

1つ目の理由は、text で意見の分割を確かめられることです。 分けた意見ごとに元の本文の該当部分が付くので、連携スクリプトは、text が元の回答の本文に含まれるかを文字列として照合します。 含まれなければ言い換えが起きているので、その回答は人の確認に回します。

2つ目は、urgent を3つの値で持てることです。 yes と review はどちらも当日の通知に回しますが、通知の文面を変えます。yes は担当課が対応を始めるもの、review は企画政策課がまず読むものです。

3つ目は、confidence で人の確認の範囲を決められることです。 low と NONE は全件を人が見ます。high は、その月の件数の5％を無作為に選んで見ます。

月末の集約は、施策ごとに次の形で受け取ります。

{
  "policy": "P-2-3",
  "count": 0,
  "summary": "",
  "voices": [
    { "response_id": "", "text": "", "position": "majority | minority_important" }
  ]
}

count はAIが書くものではなく、渡した件数をそのまま返させます。 連携スクリプトは、返ってきた count が渡した件数と同じかを確かめます。voices の text も、元の意見の本文に含まれるかを照合します。

システムへ連携する

各経路のシートには書き込みません。 各課のアンケートは各課のもので、分類の結果を書き戻す必要はありません。分類結果のシートに回答IDで結び付ければ、元の回答はいつでも引けます。

進行管理表への書き込みは、人の確認が済んでからにします。 分類結果のシートは下書きで、進行管理表は庁内で共有される確定版です。確認の前に書き込むと、見直す前の件数が庁議の資料に使われます。

人が確認する

人が見るのは、次の4種類です。

1. 緊急の yes と review … 当日のうちに企画政策課が読み、担当課への連絡を確かめます。review の多くは緊急ではありませんが、判断は人が行います
2. 確信度が low のものと NONE … 施策を選び直します。選び直した結果は、施策の一覧の「含まれる例」に足す候補にします
3. 確信度が high のものから無作為に5％ … 分類が正しいかを確かめます。誤りが続く施策があれば、一覧の例を見直します
4. 代表的な声の候補 … 庁議の資料に載せるものを選び、個人が特定できる記述が無いかを確かめます

2番目の選び直しを、一覧の側に返すことが大事です。 人が直したものをそのままにすると、翌月も同じ種類の意見が low で出てきます。直した理由を「含まれる例」に書き足すと、翌月からその種類は high で分類されるようになります。 この構成は、そうして一覧が育つことを前提にしています。

4番目では、原文であることを逆手に取られないよう注意します。 原文のまま載せるので、特定の地域名や店名、家族構成から、書いた人が分かることがあります。 載せるかどうかは、個人が推測できないかで判断してください。

目標は、1,500件をならして1件0.4分です。 low と NONE が全体の1割、high の抜き取りが5％という想定です。low が2割を超える月は、新しい種類の意見が増えているか、施策の見直しが一覧に反映されていません。

例外に対処する

上の2行は、形式を指定していても起きうると考えて作ります。 ドキュメントにもあるとおり、形式が正しいことは値が正しいことを保証しません。 照合は、後段の連携スクリプトに必ず置きます。

記録を残す

• 元の回答（伏せ字の前）と、伏せ字の後の本文。伏せ字の前の本文は、閲覧できる人を限った場所に置く
• Gemini に渡した本文と、返ってきたJSONの全文
• そのとき使った施策の一覧の版
• 人が選び直した分類と、その理由
• 緊急の通知を出した日時と、担当課が受け取った日時
• 月末の要旨と代表的な声の候補、庁議の資料に採用したもの

3つ目の「施策の一覧の版」を残すのは、施策が見直されるためです。 年度の途中で施策が統合されると、同じコードが見直しの前後で違う範囲を指します。 版が残っていないと、前年同月と比べるときに、件数の増減の意味が分からなくなります。

4つ目は、一覧を育てる材料です。 選び直しの理由がたまると、どの施策の「含まれる例」が足りないかが見えてきます。