労働組合の執行部が、フォームで集めた職場の要望を職場とテーマで分け、会社との協議に出す要求項目の案と回答状況の一覧を作る

処理の起点を決める

フォームの回答がスプレッドシートに入ったことを起点にします。 Apps Script のインストール型のトリガーには、フォームの送信で動くものが2種類あり、フォーム側のものと、フォームの回答先のスプレッドシート側のものがあります。この構成ではスプレッドシート側のトリガーを使います。 公式のページでは、スプレッドシート側のフォーム送信のイベントは、質問の名前と値をまとめた namedValues、スプレッドシートの並びと同じ順の values、書き込まれたセルの range を持つとされています。range から行の番号が分かるので、処理の結果を同じ行の横の列に書けます。

回答はまとめて届くことがあります。 職場集会のあとに数十人が続けて出すと、スクリプトが同時にいくつも動きます。要望の一覧に同時に書き込むと行が重なるので、書き込みの前にスクリプトのロックを取ります。 公式のページでは、スクリプトのロックで守った部分は、利用者が誰であっても同時には実行されないとされています。ロックが取れなかったものは「未処理」の印を残して終わり、1時間ごとの時間主導型のトリガーで未処理の行を拾い直します。

集計は、執行委員会の10日前の朝に時間主導型のトリガーで動かします。 公式のページでは、時間主導型のトリガーは毎分から月1回までの間隔で動かせるとされています。執行委員会の日は月ごとに変わるので、毎朝動いて「労使協議の日程」のシートを見て、10日前の日だけ集計を作る形にします。

インストール型のトリガーは、作った人のアカウントで動きます。 書記長個人のアカウントで作ると、役員が改選で替わったときに止まります。執行部で共有している組合のアカウントで作ります。

入力データを集める

質を決めるのは、要求の台帳の「要求の文」です。 近い要求の候補は、台帳の文と新しい要望の本文を比べて選びます。台帳の文が「照明の件」のように短いと、何の照明かが分からず候補に挙がりません。「〇〇工場の夜勤明けに使う第2駐車場の照明を増やす」のように、場所と困りごとが分かる文にしておきます。

AIに渡すのは、要求の台帳のうち状態が「合意」以外のものだけです。 合意して片づいた要求まで渡すと、候補が古い話に引っ張られます。

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

すべて同じスプレッドシートの中にあるので、Apps Script から読むだけです。 要望の本文はイベントの namedValues から取り、台帳はシートの範囲をまとめて読みます。

支部と職種は、フォームの選択式の値をそのまま使います。 AIに本文から支部を推し量らせることはしません。選択式の値が空のとき（古いフォームの回答など）だけ、「支部不明」として書記の確認に回します。

氏名は AI に渡しません。 任意で書かれた氏名は、連絡の希望がある人に書記長が連絡するときにだけ使い、分類の材料にはしません。

AIへ渡す前に整形する

1. 空の回答と試しの回答を外す … 本文が空、または「テスト」だけのものは処理しません
2. 本文の長さを確かめる … 極端に長いものは、先頭から決めた長さまでで切り、切ったことを印に残します
3. 氏名と連絡先らしい文字列を伏せる … 本文の中に書かれた電話番号やメールアドレスを、決まった記号に置き換えてから渡します
4. 同じ人の連続した送信をまとめる … 同じ支部から数分以内に同じ本文が届いたら、二重送信として1件にします
5. 未解決の要求を短い一覧にする … 要求ID、テーマ、要求の文、対象の支部の4つだけを1行ずつ並べます
6. 安全の言葉を拾っておく … 「けが」「転倒」「挟まれ」「熱中症」など、決めておいた言葉が本文にあれば印を付けます

3番目は、AIの側で外せないものを先に外す処理です。 要望の本文に「私（内線1234）は」のように書く人がいます。本人が分かる情報は、渡す前にスクリプトで伏せます。

6番目は AI の判定と別に持ちます。 AIが「安全に関わらない」と判定しても、言葉の印が付いていれば執行部へ知らせます。安全の話を見逃す側の誤りだけは、二重に防ぎます。

AIに処理させる

させるのは、1件の要望について次の5つを決めることです。

「迷ったら個人の相談」「迷ったら安全に関わる」としているのは、誤りの重さが違うためです。 職場の要望を個人の相談と誤っても、書記長が読んで一覧に戻すだけです。逆に、個人の相談を職場の要望と誤ると、本人が分かる形で資料に載ります。

最後の行を書いているのは、少数の声を残すためです。 件数の多いテーマだけを要求にすると、人数の少ない職種の困りごとがいつまでも上がりません。一覧には全件を残し、要求にするかは人が決めます。

テーマの7つは、組合が決める分け方です。 執行委員会の担当の分け方に合わせておくと、集計がそのまま担当ごとの資料になります。担当の分け方が変わったら、指示のテーマの一覧と構造化出力の列挙の値を同時に直します。 片方だけを直すと、指示にないテーマが返ってきたり、指示にあるテーマを返せなかったりします。過去の要望のテーマは付け直さず、いつの分け方で付けたかを処理ログに残しておきます。

指示内容を固定する

あなたは労働組合の執行部で、組合員から届いた職場の要望を仕分ける担当です。
以下の要望1件について、決められた項目だけを返してください。

【kind の選び方】
- workplace_request … 職場の設備・制度・働き方について、職場全体に関わる要望
- personal_consultation … 特定の人との関係、本人の処遇・評価・健康、
                          ハラスメントなど、本人に関わる相談
- union_feedback … 組合の運営への意見や質問
職場の話のように書かれていても、特定の人の言動や本人の処遇に触れていれば
personal_consultation を選んでください。迷ったら personal_consultation です。

【theme の選び方】
wages / hours_leave / safety_health / facilities / staffing / training_system / other

【厳守事項】
- safety_related は、けが・病気・事故の危険が書かれていれば true。迷ったら true。
- summary は一文で書き、人名・役職名・個人が分かる表現を入れないでください。
- related_requests は【未解決の要求】の要求IDから、同じ困りごとを扱うものを
  最大3つ選んでください。一覧にない要求IDを作らないでください。
  同じ困りごとが無ければ空の配列にしてください。
- 要求にすべきか、会社の回答が妥当かは書かないでください。
- 要望を出した人が誰かを推し量らないでください。
- 判断の材料が足りないときは note に理由を書いてください。

【支部】{branch}　【職種】{job_type}
【要望の内容】{request_text}
【未解決の要求】{open_requests}

「職場の話のように書かれていても」の一文が、この指示の要です。 「うちの職場では残業を断ると評価が下がる雰囲気がある」は職場の話の形をしていますが、特定の上司を思い浮かべて書かれていることが多く、本人が分かる場合があります。 指示に書かないと workplace_request に入ります。

「一覧にない要求IDを作らない」も外せません。 何も言わないと、それらしい形の要求IDを作って返すことがあります。

出力形式を固定する

OpenAI API の Responses API で、構造化出力を使って次の形の JSON を受け取ります。 公式のページでは、text.format に json_schema を指定して strict を true にし、すべての項目を required にして、additionalProperties: false を付けることとされています。省いてよい項目は、型に null を加えて表します。

{
  "kind": "workplace_request | personal_consultation | union_feedback",
  "theme": "wages | hours_leave | safety_health | facilities | staffing | training_system | other",
  "safety_related": false,
  "summary": "第2駐車場の照明が暗く、夜勤明けに足元が見えない",
  "related_requests": ["R-2026-031"],
  "note": null
}

1つ目の理由は、振り分けをスクリプトの条件だけで書けることです。 kind が personal_consultation なら個人の相談のシートへ、safety_related が true なら知らせる、という分岐を文章の解釈なしに書けます。

2つ目は、related_requests を検算できることです。 返ってきた要求IDが台帳にあるかをスクリプトで確かめ、無いIDが入っていたらその要望を書記の確認に回します。

3つ目は、断りの応答を見分けられることです。 公式のページでは、安全上の理由でモデルが応じないとき、出力に refusal の項目が入るとされています。ハラスメントの相談のように重い内容で断りの応答が返ってきたら、分類せずに個人の相談として扱います。 迷ったら個人の相談、という方針と同じ向きに倒します。

月末の集計では、要望の一覧から次の3つを作ります。

回答状況の一覧の「関連する新しい要望の数」が、催促の根拠になります。 「検討中」のまま半年たった要求に、今月も新しい要望が5件結び付いていれば、それをそのまま協議の場で示せます。

システムへ連携する

個人の相談は、別のファイルに移します。 同じファイルの別のシートにすると、ファイルを共有した人には見えてしまいます。書記長だけに共有したファイルに書き、要望の一覧からは行ごと消して「個人の相談に移した」とだけ残します。

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げずに応答を返すとされています。失敗したらその行に「未処理」の印を残し、1時間ごとの拾い直しに任せます。

人が確認する

1. 個人の相談は書記長がその日のうちに読む … 連絡の希望があれば本人に連絡します。職場の要望として一覧に戻すかも、書記長が決めます
2. 安全の知らせは執行部が当日中に見る … 支部の役員に現場を確かめてもらいます
3. 書記が週に一度、要望の一覧を確かめる … テーマの付け方と、近い要求の候補を見て直します。候補を採るか外すかを決めるのは書記です
4. 執行部が要求項目の案を直す … どの要望を束ね、どれを新しい要求にするかを決め、決めた理由を一言ずつ残します
5. 執行委員会で決める … 協議に出す要求を確定し、台帳に足します

3番目の確認は1件2分を目安にします。 本文を読み、付いたテーマと候補が合っているかを見るだけです。2分を超える要望が多い週は、テーマの分け方そのものを見直す時期です。

4番目の「決めた理由」は、組合員への説明の材料になります。 「出した要望はどうなったのか」と聞かれたとき、どの要求に束ねたか、なぜ見送ったかを答えられます。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分、同時に動く実行は利用者あたり30です。フォーム送信のトリガーは1件ずつなので普段は収まりますが、拾い直しで未処理の行をまとめて処理するときは、時間を見ながら途中で区切ります。

外部への呼び出しの回数にも上限があります。 公式の表では、URL の取得は個人のアカウントで1日20,000回、Google Workspace のアカウントで1日100,000回です。月300件の分類では届かない数ですが、拾い直しの処理が同じ行を何度も呼ばないよう、処理済みの印を必ず付けます。

記録を残す

• 回答ごとに、処理した日時、渡した本文（伏せた後のもの）、AIが返した JSON の全文
• 書記が直した記録 … テーマや候補を、何から何に変えたか
• 個人の相談に移した記録 … 日時と移した理由（中身は要望の一覧に残さない）
• 安全の知らせを送った日時と、支部での確認の結果
• 要求項目の案に、どの要望を束ねたか、見送ったものとその理由
• 執行委員会で確定した要求と、台帳に足した日

2つ目の「書記が直した記録」は、指示を直す材料になります。 同じテーマの取り違えが続くなら、テーマの説明を指示に足します。

3つ目で中身を残さないのは、ログから本人が分かるのを防ぐためです。 処理ログは執行部の3名が見るので、個人の相談の中身は書記長のファイルにだけ置きます。

5つ目の「束ねた要望と見送った理由」は、次の役員への引き継ぎになります。 改選で執行部が替わっても、どの要求にどの職場の声が積み上がっているかが一覧で残ります。