社員の改善提案・アイデアの投稿を、テーマと担当部門に分類して回し、毎月の件数と検討状況の一覧を作る

処理の起点を決める

フォームへの投稿を1件ずつきっかけにします。 Google Forms の New Form Response は、新しい回答を受け取ったときに動く即時のトリガーです。1日1回にまとめて処理する形にはしません。 まとめると、部門に届くのが数日遅れ、その間に投稿者が「届いたのか」と気にし始めます。

もう1つ、毎週月曜の朝に動く追跡の Zap を別に作ります。こちらは投稿ではなく、Schedule by Zapier の定時で動き、提案一覧の中から止まっているものを拾います。受付の Zap と追跡の Zap を分けるのは、片方を直しているあいだにもう片方が止まらないようにするためです。

フォームの回答の編集では動かしません。 投稿者が回答を直せる設定にしていると、編集のたびに同じ提案が2回回付されます。New or Updated Form Response ではなく New Form Response を選ぶのはこのためです。

入力データを集める

質を決めるのは、部門の受け持ちの一覧の「受け持つ範囲の説明」の列です。 「総務部」という名前だけでは、AIは出張の精算を経理に回すか総務に回すかを決められません。「出張の手配、社用車、事務所の設備、福利厚生の制度」のように、受け持つものを具体的に書きます。 この列は、これまで事務局のベテランの頭の中にあった知識を書き出したものです。

「回付してよいか」の列は、窓口の準備ができた部門だけを対象にするために持ちます。 窓口が決まっていない部門の提案は、当面は事務局が手で回します。

投稿者の氏名と所属は、AIに渡しません。 分類に要るのは本文だけです。氏名を渡すと、要旨に名前が入って部門へ届くことがあります。

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

部門の受け持ちの一覧は、投稿のたびに読み直します。 Get Many Spreadsheet Rows (Advanced) は最大1,500行を1つのJSONの値として返せるので、部門が30前後の会社なら1回で全部が取れます。組織変更で部門が増減したときも、シートを直すだけで翌日の投稿から反映されます。 指示の文面に部門名を直接書くと、組織変更のたびに Zap を開き直すことになります。

回付先の窓口は、AIの出力ではなく、シートから引きます。 AIが返すのは部門コードだけです。Lookup Spreadsheet Row で部門コードの列を探し、その行の窓口のアドレスを使います。AIがメールアドレスを書く経路を作りません。

止まっている提案の判定は、シートの計算式に持たせます。 提案一覧に「回付日から30日を過ぎ、検討状況が『回付済』のまま」のとき TRUE になる列を作り、追跡の Zap は Lookup Spreadsheet Rows (Advanced) でその列が TRUE の行を拾います。この検索は最大500行までなので、それを超えるほど止まっているなら、通知より先に制度の運用を見直す段階です。

AIへ渡す前に整形する

1. 空の投稿を落とす … 本文が空、または数文字だけのものは分類に回さず、事務局の確認待ちとして一覧に記録します
2. 氏名と所属を外す … AIに渡すのは件名と本文だけにします
3. 本文の中の個人名に気づける形にする … 本文に人の名前が書かれていることがあります。外すのではなく、後段の sensitive の判定の材料として残します
4. 長すぎる本文を確かめる … 新規事業の案などで本文が長いときは、そのまま渡します。要旨は1行に収めさせます
5. 受付番号を振る … 投稿日時と回答の行番号から受付番号を作り、以降はこの番号で追います
6. 部門の一覧を整える … 「回付してよいか」が「いいえ」の部門は、候補から外して渡します

3番目で名前を消さないのは、意図してのことです。 消してしまうと、特定の人への申し立てが「職場環境の改善の提案」に見えてしまい、通常の回付に乗ってしまいます。 名前が書かれていることは、分類で見るべき信号の1つです。

AIに処理させる

させるのは、テーマを1つ、担当部門を1つ選ぶことと、選べないときに印を付けることです。 要旨は、回付のメールの件名と月次の一覧に使う1行だけです。

テーマの区分は7つです。 improvement（業務の手順・書式・ムダ）、it_system（社内のシステム・ツール）、workplace（職場環境・設備・福利厚生）、safety_quality（安全・品質）、customer（顧客対応・サービス）、new_business（新規事業・新商品）、other です。区分を増やしすぎると、AIも人も選ぶたびに迷います。

2行目がこの構成でいちばん大事な線です。 sensitive の印を付けるのはAIですが、その中身をどう扱うかは、相談窓口や通報窓口の社内の規程に従って人が決めます。 AIの仕事は「通常の回付に乗せない」ことだけです。

指示内容を固定する

あなたは社内の改善提案制度の事務局で、届いた投稿を担当部門へ振り分ける立場です。
投稿の本文だけを読んで判断してください。推測で補わないでください。

【テーマの区分】次の7つから1つだけ選ぶ
- improvement ...... 業務の手順、帳票・書式、会議、ムダの削減
- it_system ........ 社内のシステム、ツール、アカウント、端末
- workplace ........ 職場環境、設備、休憩室、福利厚生、働き方の制度
- safety_quality ... 作業の安全、製品やサービスの品質
- customer ......... 顧客対応、サービスの改善、顧客の声
- new_business ..... 新規事業、新商品、新しい販路
- other ............ 上のどれにも当たらない

【担当部門の候補】
{departments}
（各行は「部門コード｜部門名｜受け持つ範囲」です）

【department_code の選び方】
- 受け持つ範囲の説明に照らし、提案を実施するときに主となる部門を1つ選ぶ
- 候補の中から選ぶ。候補に無い部門名を書かない
- 決められないときは空にし、flags に unclear を入れる
- 実施に2つ以上の部門が要るときは、主となる部門を書き、flags に multi を入れる

【sensitive とするもの】次のどれかが書かれていれば flags に sensitive を入れ、
department_code は空にする
- 特定の個人（名前、役職、席の位置などで特定できる人）への不満や申し立て
- ハラスメント、差別、法令や社内規程に違反するかもしれない行為の指摘
- 本人や家族の健康、家庭の事情の相談
これらが事実かどうか、どれほど重大かは判断しないでください。

【厳守事項】
- summary は40字以内の1行。個人名、役職名を入れない
- 提案の良し悪し、採用すべきかを書かない
- 投稿者が誰かを推測しない
- 本文が短すぎて内容が分からないときは、theme を other、flags に unclear
- reason には、選んだ根拠になった本文の語句をそのまま短く写す

【投稿の件名】{subject}
【投稿の本文】{body}

「候補に無い部門名を書かない」を明記しないと、もっともらしい部門を作ります。 「働き方改革推進室」のような、ありそうで無い部門が返ると、Lookup で窓口が引けずに Zap が止まります。候補の外に答えを作らせないことが、後段を単純に保つ条件です。

sensitive の定義に「事実かどうかを判断しない」と書くのも同じ理由です。 書かなければ「内容から判断して軽微なため通常の提案として扱う」と自分で線を引き直します。線を引くのは規程の側です。

出力形式を固定する

Analyze and Return Data の出力の項目を、次のように定義します。

受け取る値は、たとえば次のようになります。

{
  "theme": "improvement",
  "department_code": "D07",
  "flags": "multi",
  "summary": "出張精算の領収書の貼り付けを写真の提出に替える案",
  "reason": "出張の精算で領収書を台紙に貼る作業"
}

1つ目の理由は、Paths の規則をこの項目だけで書けることです。 flags に sensitive を含むか、unclear を含むか、department_code が空か。分かれ道は文字列の比較だけで決まります。 AIの文章を読んで判断する段を、後段に置きません。

2つ目は、multi でも回付は止めないことです。 主となる部門に回し、回付のメールに「他部門との調整が要る可能性」と書き添えます。事務局に戻すのは、どの部門が主か決められないときだけです。

3つ目は、reason で事務局の確認が速くなることです。 月次の一覧で分類の誤りに気づいたとき、AIが本文のどこを見たかが分かれば、受け持つ範囲の説明のどこを直せばよいかがすぐ分かります。

システムへ連携する

回付のメールに入れるのは、受付番号、テーマ、要旨、本文、一覧へのリンクだけです。 氏名と所属は入れません。部門の担当者はメールを読み、一覧の検討状況の列を「検討中」「採用」「保留」「見送り」に更新します。 メールで返事をもらう形にすると、返事を一覧に書き写す作業が事務局に戻ってきます。

月次の一覧は、Digest の頻度を Monthly にし、毎月1日の朝に配信します。 1件ごとに「受付番号｜テーマ｜部門｜要旨」を1行ためます。Digest のタイトルは32文字まで、1つのダイジェストは1MBまでとされているので、月240件の1行ずつなら余裕があります。

検討状況の件数は、Digest ではなくシートの集計で出します。 状況は回付の後に部門が変えるので、投稿の時点でためた Digest には反映されません。月次のメールには、件数の集計シートへのリンクを添えます。

人が確認する

事務局が開くのは、Paths の1番目と2番目に入ったものだけです。 3番目の通常の回付は、一覧の行と回付のメールを流し見ます。

1. sensitive を最優先で見る … 本文を読み、社内の相談窓口・通報窓口の手続に移すかを決めます。一覧には本文を残しません
2. unclear の回し先を決める … 部門を決めて手で回付し、受け持つ範囲の説明のどこが足りなかったかをメモします
3. 通常の回付を週に1回流し見る … テーマと部門の組み合わせに違和感のあるものだけを開きます
4. 部門から「うちではない」と戻ったものを記録する … 誤った回付の件数を月ごとに数えます

4番目を記録し続けることが、精度を上げる唯一の方法です。 戻ってきた提案の多くは、受け持つ範囲の説明の書き方で直ります。AIの指示を直すより、シートの説明を1行直すほうが効きます。

目標は、240件をならして1件2分です。 印が付くのは1割前後という想定で、それより多い月は、部門の一覧の説明が古くなっています。

例外に対処する

最後の行は、起きたら最も重い失敗です。 起きにくくするために、sensitive の定義は広めに取り、迷ったら印を付けるほうに倒します。 印を付けすぎて事務局の確認が増える損は、時間だけで済みます。

記録を残す

• 投稿の原文（回答のスプレッドシート。これまでどおり）
• AIの出力（theme、department_code、flags、summary、reason）と、そのとき使った部門の受け持ちの一覧の版
• 回付した日時、回付先の窓口、通る分かれ道の番号
• 部門から戻された記録 … どの提案が、どの部門からどこへ移ったか
• 検討状況の変更の履歴（スプレッドシートの変更履歴）
• sensitive の件は、受付番号と相談窓口へ移した日時だけを一覧に残し、本文は事務局の限られた場所に置く

2つ目で一覧の版を残すのは、組織変更をまたいで振り返るためです。 部門の受け持ちを書き換えると、過去の回付が正しかったかの意味が変わります。当時の説明が残っていれば、誤りが一覧のせいか指示のせいかを分けられます。