毎月のパルスサーベイの自由記述をテーマと感情で分類し、部署ごとの要点にまとめて人事と管理職へ返す

処理の起点を決める

時間主導型のトリガーを、毎朝6時台に1つ置きます。 毎日動きますが、処理するのは回答期間が終わった翌日だけです。回答期間の終了日は、区分の定義のシートに人事が毎月書き込みます。終了日の翌日でなければ、スクリプトは何もせずに終わります。

フォームの送信のたびには動かしません。 送信ごとのトリガーでも1件ずつ分類はできますが、回答期間の途中で部署の件数を出すと、回答の早い人の声だけで部署の傾向が決まって見えます。 回答が出そろってから一度に分類し、集計します。

処理は3つの段に分けます。 1段目で取り出しと伏せ字、2段目で分類、3段目で集計と要点の下書きです。どの段のどの件まで終わったかをスクリプト プロパティに残し、6分に近づいたら区切って、次の実行（同じ朝の15分後に置いた2つ目のトリガー）で続きから始めます。

同じ回が二度処理されないようにします。 処理を始めるときにロックを取り、分類結果のシートにその回の印があれば止まります。手で再実行したときに二重に集計されると、部署の件数が倍になります。

入力データを集める

AIに渡すのは、伏せ字にした自由記述と、区分の定義だけです。 部署名も5段階評価の点数も渡しません。部署名を渡すと、AIはその部署らしい分類に寄せてきます。 点数を渡すと、点の低い回答の記述を不満に寄せます。記述そのものだけで区分を決めさせます。

区分の定義が、分類の質を決めます。 テーマの名前だけを渡すと、「残業が続いて上司に相談しにくい」の行き先が毎回揺れます。「業務量の多さそのものが主語なら業務量、相談のしにくさが主語なら上司との関係」のように、迷ったときの決め方を例とともに書いておきます。 これは今の担当2名が迷ってきた記述から作ります。

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

回答のシートは、スプレッドシートの範囲をまとめて読みます。回答期間の開始日と終了日で回答日時を絞り、その回の分だけを取り出します。 フォームのイベントの値を使う方法もありますが、この構成はまとめて処理するため、シートから読むほうが単純です。

Gemini API の鍵はスクリプト プロパティに置きます。 プロパティは文字列のキーと値の組で保存され、アプリ全体の設定を持たせる場所とされています。スクリプトの本文に鍵を書かないでください。 スクリプトの編集権限を持つ人を、人事の担当者に限ります。

API の呼び出しは UrlFetchApp で行います。 muteHttpExceptions を true にすると、失敗した応答でも例外にならずに応答が返るので、状態コードを見て、再試行するか「再分類待ち」にするかを決められます。

AIへ渡す前に整形する

1. 回の絞り込み … 回答日時が回答期間に入るものだけを取り出します。期間外の回答は数に入れません
2. 空欄と記号だけの記述の除外 … 「特になし」「なし」「—」などは分類せず、「記述なし」として数えます
3. 伏せ字 … メールアドレス、社員番号の形の数字、電話番号の形の数字を正規表現で ［伏せ字］ に置き換えます
4. 人名の候補の伏せ字 … 部署マスタの管理職の氏名と、社員名簿の姓が記述に含まれていれば ［氏名］ に置き換えます。AIに渡す前に、こちらで消しておきます
5. 長すぎる記述の扱い … 1件が800字を超えるものは分割せず、そのまま1件として送ります。ただし1回にまとめる件数を減らします
6. 部署の回答数の確認 … 部署ごとの自由記述の件数を数え、5件未満の部署には「上の組織にまとめる」の印を付けます
7. 20件ずつのまとまりにする … 部署を混ぜて20件ずつに分けます。同じまとまりに1つの部署だけが入らないよう、並び順を回答日時で混ぜます

4番目を軽く見ないでください。 自由記述には「○○さんの指示が毎回変わる」のように、特定の社員の名前が書かれることがあります。 AIに渡す前に消しておけば、要点の下書きに名前が残ることもありません。名簿に無い呼び方（あだ名など）は消せないので、8番目の人の確認で拾います。

7番目で部署を混ぜるのは、まとまりの中の他の記述に引っ張られないためです。 同じ部署の不満が20件並ぶと、AIは中立の記述まで不満に寄せることがあります。

AIに処理させる

させるのは2つです。 1つ目は、自由記述1件ずつにテーマ・感情・要対応の印を付けること。2つ目は、集計が済んだ部署ごとに、件数の多いテーマについて原文を言い換えた要点を書くことです。

要対応の印だけは「迷えば付ける」にしています。 テーマと感情は、迷えば「その他」や低い確信で人に回せば済みます。要対応の記述を見落とすと、対応が1か月遅れます。 付けすぎた分は人事が原文を読んで外せばよく、見落とすより安くつきます。

いちばん起きやすい失敗は、5行目です。 要点を書かせると、AIは「『会議が多すぎて資料を作る時間がない』という声がありました」のように原文を引用して具体的にしようとします。引用は、部署の人数が少ないほど書き手の見当をつけやすくします。 言い換えを指示し、さらに原文と同じ8文字以上の並びが要点に残っていないかをスクリプトで確かめます。

指示内容を固定する

1つ目の指示（分類）は次のとおりです。

あなたは人事部で、社員向けアンケートの自由記述を分類する立場です。
記述ごとに、決められた区分の中から選んでください。新しい区分を作らないでください。

【テーマ（主なテーマを1つ、関係するテーマを最大2つ）】
{theme_definitions}
（各テーマの説明と、迷ったときの決め方の例を含む）

【感情（1つ）】
- positive ... 前向き・満足・感謝
- negative ... 不満・困りごと
- request .... 具体的な要望・提案
- neutral .... 事実の報告など、どれにも当たらない

【要対応の印（当てはまるものをすべて）】
- harassment ... 言動による嫌がらせ・威圧をうかがわせる
- health ....... 心身の不調・眠れない・限界などをうかがわせる
- compliance ... 法令や社内規程に反する行為の疑い
- resignation .. 退職や異動を強く考えていることをうかがわせる
うかがわせる語句があれば印を付けてください。迷ったときは付けてください。

【厳守事項】
- 書いた人が誰か、どの部署かを推測しないでください。
- 部署や上司の良し悪しを判断しないでください。
- evidence には、区分を決めた語句を記述からそのまま写してください。
- 記述の内容が短く区分を決めきれないときは、theme を other、
  confidence を low にしてください。
- ［伏せ字］［氏名］の中身を推測しないでください。
- 入力の id をそのまま返し、件数を増やしたり減らしたりしないでください。

【記述（id と本文）】{comments}

2つ目の指示（部署の要点）は次のとおりです。

あなたは人事部で、部署の管理職へ返す要点の下書きを書く立場です。
次の件数の表と、テーマごとの記述をもとに、件数の多いテーマを最大3つ選び、
テーマごとに要点を2〜3行で書いてください。

【厳守事項】
- 記述の文をそのまま引用しないでください。必ず言い換えてください。
- 特定の出来事・日付・会議名・案件名・人数など、書いた人が分かる具体を書かないでください。
- 「〜という声が複数ありました」のように、件数の表の範囲で書いてください。
  件数が1件だけのテーマは要点に書かないでください。
- 部署や管理職の良し悪しを評価しないでください。改善策を指示しないでください。
- 要対応の印が付いた記述は渡していません。触れないでください。

【件数の表】{counts}
【テーマごとの記述（伏せ字済み）】{comments_by_theme}

「件数が1件だけのテーマは書かない」が、匿名を守るもう一つの線です。 1件だけの声は、それを書いた人と結び付きやすいからです。1件の声は人事が原文で読み、要点からは外します。

部署の要点を作るときは、要対応の印が付いた記述を最初から外して渡します。 指示で「触れない」と書くだけでなく、入力に入れないことで守ります。

出力形式を固定する

分類は次の形のJSONで受け取ります。 response_format の schema で、theme と sentiment と flags の値を enum で列挙しておきます。

{
  "results": [
    {
      "id": "R2026-10-0137",
      "theme_main": "workload",
      "theme_sub": ["manager_relation"],
      "sentiment": "negative",
      "flags": [],
      "confidence": "high | low",
      "evidence": "締め切りが重なって毎週残業"
    }
  ]
}

1つ目の理由は、enum で区分を決めた値の中に閉じ込められることです。 自由な文で返させると「業務負荷」「仕事量」「忙しさ」が別の区分として並び、集計のたびに名寄せが要ります。 それでも公式の説明では値の確かめはアプリケーションで行うようにとあるので、スクリプトで区分の一覧と照らし、外れたものは「再分類待ち」にします。

2つ目は、id で入力と出力を突き合わせられることです。 20件送って19件しか返らない、同じ id が二度返る、といったことをスクリプトで見つけられます。数が合わないまとまりは、まとまりごと送り直します。

3つ目は、flags を部署の集計と別の道に流せることです。 flags が空でない記述は、部署の要点の入力から外し、人事の要対応の一覧にだけ載せます。

部署の要点は次の形で受け取ります。

{
  "dept_code": "D14",
  "highlights": [
    { "theme": "workload", "count": 9, "summary": "" }
  ],
  "no_clear_theme": false
}

count はAIに数えさせず、スクリプトが入れた値をそのまま返させます。 返ってきた count が件数の表と違えば、その部署の要点は使いません。

システムへ連携する

管理職へのメールは下書きまでにします。 人事の担当が要点を読み、書き手が分かる言い回しが残っていないかを確かめてから送ります。自動で送ると、確認の前に要点が管理職に届きます。

要対応の一覧は、人事の責任者と担当だけが開けるシートに分けて書きます。 分類結果のシートと同じブックに置くと、共有の範囲を広げたときに一緒に見えてしまいます。

人が確認する

1. 要対応の一覧を最初に読む … 印が付いた記述を原文で読み、対応するかを決めます。付けすぎを外すのも人の仕事です
2. 「その他」と low の記述を読む … 区分を直したら、直した区分を結果のシートに書きます
3. 部署の要点を読む … 書き手が分かる具体（出来事、時期、少人数の役割名など）が残っていないかを見て、残っていれば消します
4. 少人数の部署のまとめ先を確かめる … 上の組織にまとめた部署が、まとめた先でも5件未満なら、その回は返しません
5. 送る … 下書きを確かめてから、人が送ります

3番目を省かないでください。 AIが言い換えても、「新しい評価制度の説明会のあと」のような時期の手がかりが残ることがあります。部署の人数が少ないほど、その手がかりだけで書き手の見当がつきます。

目標は、480件をならして1件1分です。 要対応と「その他」と low を合わせて1〜2割ほどを人が原文で読み、残りは集計の表と要点を読むだけ、という想定です。

例外に対処する

いちばん多いのは、下から3行目と、少人数の部署の扱いです。 どちらもAIの精度ではなく、匿名を守る線の問題です。線を下げて返す部署を増やすより、返さない回があってよいと先に決めておくほうが、回答する側の信頼を保てます。

記録を残す

• その回の回答期間、送った件数、分類できた件数、「再分類待ち」の件数
• 1件ごとの区分（theme_main、theme_sub、sentiment、flags、confidence、evidence）
• 人が区分を直した記録 … どの記述を、どの区分からどの区分へ変えたか
• 部署×テーマ×感情の件数と、上の組織にまとめた部署の一覧
• 管理職に送った要点の最終版と、送った日時
• そのとき使った区分の定義の版

2つ目の記録には、自由記述の原文を持たせません。 原文は回答のシートにあり、結果のシートには id と区分だけを残します。原文の写しを増やすほど、見られる場所が増えます。

最後の行は、区分の定義を直したときに効きます。 定義を変えると、前の月の件数と並べられなくなります。どの月がどの版で分類されたかが残っていれば、比べてよい範囲が分かります。

人が直した記録は、区分の定義の改善に使います。 毎月同じ型の記述が直されているなら、迷ったときの決め方の例をその型で書き足します。