研修後のアンケートの自由記述を要約して、講師と研修企画の担当それぞれに返す改善レポートにする

処理の起点を決める

毎朝1回動く定時の処理を起点にします。 Google Apps Script の時間主導型のトリガーで、研修台帳を見て、回答の締切を過ぎていて、報告書の状態が「未作成」の研修を探します。

フォームの回答が届くたびに動かすことはしません。 Google Apps Script にはフォームの送信を起点にするトリガーもありますが、1件ずつの回答で要約を作ると、同じ研修について何度も下書きができます。締切を過ぎて回答がそろってから、1回だけ作ります。

見つけた研修ごとに処理し、下書きを書き出せたら台帳の状態を「下書きあり」に変えます。状態を変えるのは、下書きの書き出しに成功したときだけです。 失敗した研修は翌朝にもう一度拾われます。

トリガーは研修課の共用のアカウントで作ります。インストール型のトリガーは作った人のアカウントで動くので、個人のアカウントで作ると、その人の異動で止まります。

入力データを集める

質を決めるのは、研修のねらいと進行表です。 「分かりにくかった」という自由記述は、どの時間帯の何の話かが分からないと、講師に返しても直しようがありません。 進行表を渡すと、「後半のロールプレイの説明」のように、時間帯と内容で意見を寄せられます。

宛先の区分は、例で定義します。 「会場が寒かった」は運営、「教材の事例が小学生向けばかり」は企画、「質問への答えが早口だった」は講師、のように、研修課が迷った実例を手引に並べて渡します。 定義の文だけでは、教材の問題と講師の説明の問題が混ざります。

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

フォームは研修の種類ごとに1つにし、回の番号を設問で選ばせます。 回ごとにフォームを作ると、回答のスプレッドシートが月に40枚増え、取り出す先を毎回変えなければなりません。

前回の要点は、報告書の全文ではなく「返した点」だけを渡します。 全文を渡すと、今回の要約が前回の言い回しに寄ります。渡すのは、今回それが解消されているかを確かめる材料だけです。

AIへ渡す前に整形する

1. 回答の絞り込み … 研修の回の番号で、その回の回答だけを取り出します
2. 重複の除去 … 同じ回答者が二度送った回答（回答日時が近く、内容が同じもの）を1件にします
3. 数字の計算 … 満足度の4設問の平均点、回答数、前回の平均点との差を Google Apps Script で出します
4. 回答番号を振る … 自由記述1件ごとに R01、R02…と番号を振ります。引用の照合に使います
5. 固有名詞を伏せる … 自由記述に書かれた受講者の氏名、教室名、生徒の名前を、名簿と照らして「〔氏名〕」「〔教室〕」に置き換えます
6. 空の回答の除去 … 「特になし」「なし」だけの自由記述を除き、件数を別に数えます
7. 回答数の確認 … 回答が5件未満の回は、要約の下書きを作らず、担当者に回します

5番目を先にやるのは、報告書が講師の手に渡るからです。 「〇〇教室の〇〇さんの質問への対応が冷たかった」と書かれていれば、その受講者が誰かが講師に分かります。AIに渡す前に伏せておけば、要約にも引用にも名前が出ません。

7番目の5件という線は、匿名性のためです。 少人数の回で原文を引用すると、書き方の癖や内容から誰が書いたかが分かります。少人数の回は、担当者が原文を読んで、引用せずに要点だけを返します。

AIに処理させる

させるのは、自由記述を宛先ごとに分けて要約し、件数と引用を付けること、そして人が必ず読む指摘を別に出すことです。

宛先の区分は、たとえば次のように分かれます。

1行目と2行目は、どちらも「分かりにくかった」という不満ですが、直す人が違います。 企画の問題を講師に返すと、講師は自分の説明を直そうとして、教材の問題が残ります。

人が必ず読む指摘は「迷ったら出す」にします。 人が必ず読む指摘は、出しすぎても担当者が数件余計に読むだけですが、出し漏らすと、安全やハラスメントの指摘が埋もれます。 片方に倒すなら、出すほうに倒します。

4行目が、この構成で最も効く禁止です。 「講師の発言で不快に感じた」という記述を「講師の言葉づかいに改善の余地」と要約すると、ハラスメントの申し出が言葉づかいの話に変わります。 原文のまま、回答番号を付けて出させます。

指示内容を固定する

あなたは社内研修の研修課で、研修後アンケートの自由記述を整理する担当です。
渡した回答だけを根拠にしてください。推測で補わないでください。

【渡すもの】
研修名と開催日：{training}
研修のねらい：{objectives}
当日の進行表：{schedule}
宛先の区分の定義と例：{audience_rules}
人が必ず読む指摘の定義：{must_read_rules}
前回までに返した点：{previous_points}
自由記述（回答番号つき）：{responses}

【手順】
1. 1件ずつ、講師・企画・運営・その他のどれに返すものかを決めてください。
   迷ったら「その他」にしてください。
2. 同じ宛先の中で、似た意見をまとまりにしてください。
   まとまりごとに、一文の要約、件数、回答番号の一覧、原文の引用を1〜2件付けてください。
3. 1件だけの意見も、まとまりとして残してください。「一部」「少数」と書かず、件数を書いてください。
4. まとまりが進行表のどの時間帯の話か分かれば書いてください。分からなければ「特定できない」。
5. 前回までに返した点ごとに、今回も同じ意見があるかを「ある／ない」で書き、
   ある場合は回答番号を付けてください。

【人が必ず読む指摘】
- 安全、ハラスメント、内容の誤り、個人への批判、体調に当たる記述は、
  件数にかかわらず must_read に回答番号と種類を出してください。
- 当たるか迷ったら、出してください。
- must_read に出した記述は、要約しないでください。

【講師向けの下書き】
- よかった点を先に書き、直すとよい点は2つまでにしてください。
- 直すとよい点には、原文の引用を1件添えてください。
- 講師の人柄や能力について書かないでください。

【厳守事項】
- 引用は、回答の文字列をそのまま写してください。言い換えないでください。
- 平均点などの数字を書かないでください。
- 研修を続けるべきか、講師を替えるべきかを書かないでください。
- 〔氏名〕〔教室〕と伏せた箇所を、推測で戻さないでください。

「1件だけの意見も残す」を明記しないと、AIは件数の多いまとまりだけを残します。 要約は多数派に寄るのが自然な振る舞いで、指示しなければ1件の意見は「その他の意見」に吸収されます。

「迷ったら出す」と「要約しない」は、must_read の節に並べて書きます。 片方だけだと、出すけれども一文にまとめ直す、という中途半端な出し方になります。

出力形式を固定する

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

{
  "training_id": "",
  "clusters": [
    { "audience": "trainer | planner | operations | other",
      "summary": "", "count": 0, "response_ids": ["R03", "R17"],
      "quotes": [""], "schedule_slot": "" }
  ],
  "previous_points": [
    { "point": "", "still_raised": true, "response_ids": [""] }
  ],
  "must_read": [
    { "response_id": "R22", "type": "安全 | ハラスメント | 内容の誤り | 個人への批判 | 体調" }
  ],
  "trainer_draft": "",
  "planner_draft": ""
}

1つ目の理由は、引用を機械で確かめられることです。 quotes の文字列が、response_ids に挙げた回答の中にそのまま含まれるかを Google Apps Script で照合します。含まれない引用が1つでもあるまとまりは、下書きに「引用を確認できませんでした」と出し、担当者が原文を読みます。

2つ目は、must_read に本文を持たせないことです。 持たせるのは回答番号と種類だけで、本文は Google Apps Script が回答のスプレッドシートから原文を引いて下書きに貼ります。 AIが写した本文を使うと、写す途中で言い回しが変わることがあります。

3つ目は、audience で宛先ごとの下書きを機械的に組めることです。 講師向けの下書きには trainer のまとまりだけを、企画担当向けには planner と operations を並べます。講師に企画への意見が届かないようにするのは、講師を守るためでもあります。 日程や教材の不満を講師個人への意見として受け取らせないためです。

count は、response_ids の数と一致しているかを照合します。一致しなければ、response_ids の数のほうを使います。

システムへ連携する

送付はこの構成から行いません。 講師へのメールは、課長の確認を経た報告書を担当者が送ります。要約の誤りや、人が必ず読む指摘の扱いが決まる前の下書きが、講師へ届く経路を作りません。

回答のスプレッドシートには書き込みません。 回答番号と伏せ字は、処理の中で作るだけで、回答そのものは変えません。

人が確認する

担当者は全部の下書きを見ます。 ただし、見る順番を決めておきます。

1. 人が必ず読む指摘を先に読む … 下書きの冒頭に原文のまま貼られています。講師に返す前に課長へ上げるか、別の手順で扱うかを決めます
2. まとまりの件数の多いものから、原文と見比べる … 回答番号から原文を開き、要約が原文と合っているかを確かめます
3. 1件だけのまとまりを読む … 重い意見が「1件」として埋もれていないかを見ます
4. 講師向けの下書きを直す … 伝え方を研修課の方針に合わせます
5. 課長が確認して送る

1番目のうち、ハラスメントと体調に当たるものは、講師への報告書には載せません。 研修課長が、社内の相談の手順に沿って扱います。講師に「こういう声がありました」と返すと、書いた受講者が特定されるおそれがあります。

講師向けの下書きを直すときは、引用を消さないでください。 伝え方をやわらげたくなっても、受講者の言葉がそのまま1件あるだけで、講師は何が起きていたかを思い出せます。要約の文だけに直すと、講師にとっては研修課の意見に見えてしまいます。

目標は、1回15分です。 60件の自由記述を読み直すのではなく、要約と原文の対応を確かめ、下書きを直す時間です。15分を大きく超える回が続くときは、宛先の区分の例が足りず、担当者が区分を直しているかどうかを見ます。

例外に対処する

上から2行目までが、例外の大半です。 小規模な地域の回と、時間が押して自由記述が書かれなかった回です。どちらもAIに要約させる必要がありません。 要約を作らない判断を、前処理の段階で機械的に行います。

7行目は、研修そのものの問題の兆しです。 1回の研修で安全やハラスメントの指摘が複数出たなら、それは要約や報告書で扱う話ではありません。報告書の作成を止め、課長が講師と企画担当から事情を聞くところから始めます。 台帳の状態は「保留」にし、翌朝の処理で拾い直されないようにします。

記録を残す

• その回の回答（元のスプレッドシートの行）と、伏せ字にした後の自由記述
• AIへ渡した入力（研修のねらい、進行表、手引の版）と、返ってきたJSONの全文
• 引用の照合の結果と、確認できなかった引用
• must_read に出た回答番号と、課長の扱い（報告書に載せたか、別の手順に回したか）
• 担当者が下書きから変えた箇所（区分を変えたまとまり、消した・足したまとまり）
• 送った報告書の最終版と送付日

5つ目が、宛先の区分の例を足す材料です。 担当者が「企画」から「講師」に直したまとまりを月に一度見ると、手引に足すべき例が分かります。

4つ目は、課長の判断の記録として残します。 後から「アンケートに書いてあったのに対応しなかった」と問われたとき、いつ、誰が、どう扱ったかを答えられるようにします。