入社・異動の連絡から、部署と職種の標準に沿ってアカウント・権限・端末の手配依頼を作り、入社日までに終わっていないものを拾う

処理の起点を決める

連絡表の「連絡確定」の列が変わったときに動かします。 Google Sheets の New or Updated Spreadsheet Row で、監視する列に「連絡確定」を指定します。特定の列を指定すると、その列が変わったときだけ Zap が動きます。 「どの列でも」にすると、人事部が氏名の誤字を直しただけで依頼が作り直されます。

行の追加そのものをきっかけにしないのは、書きかけの行で動かないようにするためです。 Zapier のヘルプでも、Google スプレッドシートの自動保存で、行を書いている途中の不完全なデータが次の手順へ送られることがあるとされています。人事部が全部の列を埋めてから印を付ける運用にし、印を付けることを「送信」の操作にします。

この列の動きには、注意が1つあります。 新しい行が足されたときも、監視する列が空のまま動くことがあるとされています。そこで、トリガーの直後に Filter を置き、「連絡確定」が「確定」の行だけを通します。 空の行や「保留」の行はここで止まります。

Zap 2 は平日の朝に動かします。 Schedule by Zapier は「毎日」を選ぶと時刻を指定でき、週末を除く設定があります。 時刻は Zapier のアカウントのタイムゾーンで決まり、指定した分ちょうどではなく数分の幅で動くとされています。担当者の始業より少し前に置きます。

入力データを集める

質を決めるのは、標準の権限表です。 ベテランの担当者が覚えている「代理店担当だけは代理店向けの共有フォルダ」のような例外を、職種を1つ分けて表に書きます。 表にない例外は、この構成では拾えません。表に書き出す作業そのものが、属人化の解消です。

「何日前までか」は、品目ごとに表で持ちます。 アカウントは3日前、端末は7日前、権限は2日前のように、手配にかかる日数が品目で違います。一律の締切にすると、端末だけが間に合いません。

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

標準の権限表は、Lookup Spreadsheet Rows (Advanced) で引きます。 検索する列に「部署と職種」を結合した列を作っておき、検索する値に連絡表の「異動後の部署」と「職種」をつないだ値を入れます。1つの列で引けるようにしておくと、条件の書き方が1つで済みます。

異動のときの見比べは、品目IDだけで行います。 異動後の品目のうち、異動前にも同じ品目IDがあるものは「引き続き使う」、無いものは「新しく付ける」です。品目名で見比べると、「営業部共有フォルダ」と「営業部 共有フォルダ」のような表記の違いで別物になります。

見比べは、Zap の中ではなく、表の側で済ませる方法もあります。 異動前の品目IDを並べた列を連絡表に置き、標準の権限表の側で「この品目IDが含まれるか」を数式で返すと、Zap は結果を読むだけで済みます。 どちらにするかは、表の管理を誰がするかで決めます。

異動前の部署で外す品目は、この Zap では依頼しません。 外す側の確認は、退職・異動の際の確認の流れ（UC-0379 のような構成）に渡します。付ける依頼と外す依頼を同じ文に混ぜると、手配先が読み違えます。

AIへ渡す前に整形する

1. 行の確認 … 氏名、社員番号、区分、部署、職種、日付のどれかが空なら、依頼を作らずに人事部へ差し戻しのメモを残します
2. 部署と職種の確認 … 標準の権限表で1行も引けないときは、表に無い部署か職種です。依頼を作らず、担当者へ「表の追加が要る」と知らせます
3. 締切の計算 … Formatter の Date / Time で、入社日・異動日に「−7 days」のような式を当てます。この機能に営業日の計算は無いので、表の日数は暦日で余裕を見て持ちます
4. 締切が過ぎていないかの確認 … 入社日の2日前に連絡が来たときなど、計算した締切が今日より前になる品目は「至急」の印を付けます
5. 備考の切り出し … 備考の欄だけを、標準外の申し出を拾う材料として別に渡します

2番目を省かないでください。 新しい部署ができた月や、職種の名前を人事部が変えた月に、表を引いても何も返りません。何も返らないまま進むと、「付けるものが0件の入社」として静かに通ります。

3番目の暦日の扱いは、連休の前に効いてきます。 「7日前」が連休の中日に当たると、手配先は実質的に数日しか持てません。連休の多い月は、表の日数を一時的に増やすほうが確実です。

AIに処理させる

させるのは、引き当て済みの品目を手配先ごとにまとめた依頼文と、受け入れ部署の上長への案内文を作り、備考から標準外の申し出を書き出すことです。

標準外の申し出を、依頼文に入れさせないのがいちばん大事なところです。 備考に「設計ツールも使いたい」とあっても、それは承認を待つ要望で、手配先に届く依頼文には載せません。別の出力のフィールドに書き出させ、担当者が承認の手続きに回します。

指示内容を固定する

AI by Zapier の指示の欄に、次のように書きます。 出力のフィールドは、項目ごとに名前と型と説明を定義します。

あなたは情報システム部で、入社・異動に伴うアカウント・権限・端末の
手配依頼の文面を作る担当です。
次の品目の一覧は、標準の権限表から引き当て済みです。
品目を足したり減らしたりせず、一覧のとおりに文面を作ってください。

【対象者】{name}（社員番号 {employee_no}）
【区分】{kind}（入社／異動）
【部署・職種】{dept} {job}
【入社日・異動日】{start_date}
【受け入れ部署の上長】{manager}
【品目の一覧】{items}  （品目ID、品目名、種類、手配先、締切、至急の印）
【備考】{note}
【依頼文の型】{templates}

【作るもの】
1. 手配先ごとの依頼文。手配先ごとに、その手配先の品目だけを並べる
2. 受け入れ部署の上長への案内文
3. 備考に書かれた、品目の一覧に無いものの要望の書き出し

【厳守事項】
- 品目の一覧に無いものを、依頼文に書かないでください。
  備考に書かれた要望も、依頼文には入れず、3. に書き出してください。
- 3. には、備考に書かれた言葉をそのまま写してください。
  要望を認めるか、どの品目に当たるかを書かないでください。
- 締切は品目の一覧の日付をそのまま使ってください。日付を計算し直さないでください。
- 至急の印がある品目は、依頼文の先頭に「至急」と書いてください。
- 備考と品目の一覧が食い違うとき（例: 「端末は不要」と書かれているが品目に端末がある）は、
  どちらかに決めず、conflicts に両方を書いてください。依頼文は品目の一覧のとおりに作ります。
- 上長への案内文に、承認されていない要望を「用意します」と書かないでください。
  「別途確認します」とだけ書いてください。
- パスワードや初期の認証情報を文面に書かないでください。

「品目を足したり減らしたりしない」を最初に書いているのは、AIが気を利かせるからです。 営業職と書かれていれば、一覧に無い名刺管理のツールを「通常必要」として足すことがあります。一覧のとおりに作ることを、指示の冒頭で縛ります。

上長への案内文で「用意します」を禁じるのは、承認前の約束になるからです。 案内文は本人にも転送されます。承認されなかったとき、約束を取り消す連絡が必要になります。

出力形式を固定する

AI by Zapier の出力のフィールドを、次の項目で定義します。

{
  "requests": [
    { "handler": "", "to": "", "subject": "", "body": "", "item_ids": "", "urgent": false }
  ],
  "manager_notice": "",
  "nonstandard_requests": "",
  "conflicts": "",
  "item_count": 0
}

1つ目の理由は、手配先ごとの依頼をループに渡せることです。 requests の要素を Looping by Zapier の「line items から作るループ」に渡すと、後ろの手順が要素ごとに1回ずつ動き、 手配先ごとに Gmail の下書きが1通できます。

2つ目は、item_count で品目の数を確かめられることです。 引き当てた品目の数と、AIが依頼文に載せた品目の数を Filter で比べ、食い違えば下書きを作らずに担当者へ知らせます。 品目を足した・落としたという誤りを、文面を読む前に機械で止めます。

3つ目は、nonstandard_requests と conflicts を手配台帳の別の列に入れられることです。 空でなければ、台帳の行に「承認待ち」「要確認」の印が付きます。

手配台帳には、品目ごとに1行を足します。

要督促の列は、シートの数式で決めます。 Zap 2 はこの列が「要督促」の行を引くだけで、どれが遅れているかをAIに判断させません。

システムへ連携する

Looping の後ろの手順は、ループの回数だけ動きます。 Zapier のヘルプでは、ループの後ろのすべての手順が、ループの1回ごとに動くとされ、ループの1回ごとに別の Zap の実行として履歴に残ります。上長への案内文の下書きはループの前に置き、 ループの中に入れないようにします。入れると、手配先の数だけ同じ案内文ができます。

どのシステムの管理画面にも書き込みません。 アカウントの作成をZapから直接行う構成も考えられますが、権限の付与を人の目を通さずに行うことになります。 この構成は依頼の段取りまでに留めます。

人が確認する

担当者が見るのは、Gmail の下書きと、手配台帳の「承認待ち」「要確認」の行です。

1. 品目の数を見る … 下書きに載った品目が、台帳の行と一致しているかを確かめます
2. 標準外の申し出を回す … nonstandard_requests に書かれた要望を、上長と情報システムの責任者の承認に回します。承認されたものだけ、手で依頼を足します
3. 食い違いを解く … conflicts を見て、人事部か上長に確かめます
4. 下書きを送る … 至急の印があるものは、チャットでも一声かけます
5. 毎朝の一覧を見る … 要督促の行について、催促文の下書きを直して送ります

2番目を省かないでください。 承認待ちの要望を放置すると、入社日に本人から「話が違う」と言われます。承認するか断るかを早く決めて、上長に伝えることが、この工程の本当の仕事です。

目標は、1件あたり18分です。 下書きの確認と送信に8分、標準外の申し出と食い違いの処理に4分、毎朝の一覧と催促をならして6分という想定です。

例外に対処する

上から1行目が、運用でいちばん多い例外です。 組織の改編で部署名が変わった月は、まとめて0行になります。人事部の組織変更の予定を、情報システム部が先に聞いておく取り決めが要ります。

記録を残す

• 連絡表の行と、「連絡確定」の印が付いた日時
• 引き当てた品目の一覧と、そのとき参照した標準の権限表の版
• AI by Zapier に渡した内容と、返ってきた依頼文・案内文・標準外の申し出の全文
• 担当者が送った依頼文 と、手で足した依頼
• 手配台帳の行ごとの状態の変化（依頼前、依頼済み、完了の日時）
• 標準外の申し出と、承認・却下の結果

2つ目で「表の版」を残すのは、後から付け過ぎを調べるためです。 監査で「なぜこの人にこの権限があるのか」と聞かれたとき、当時の標準の権限表と、承認された標準外の申し出の記録で説明できます。

最後の行は、標準の権限表を育てる材料です。 同じ部署と職種で同じ申し出が何度も承認されているなら、それは標準に入れるべき品目です。