入社予定者の受け入れ準備を、入社日から逆算して関係部署へ手配する

処理の起点を決める

毎朝1回の定時実行を起点にします。 入社予定者の登録をきっかけにするのではありません。登録された瞬間に出せる手配は、ほとんど無いからです。 3か月先に入社する人の入館証を今日申請しても、発行の日付が合いません。

毎朝、登録されているすべての入社予定者について入社日までの営業日数を計算し直し、 締切に達した品目だけを当日の手配として選びます。入社日が変わっても翌朝には計算し直されます。

補助の起点をもう1つ置きます。入社予定者の一覧で、入社日または状態（辞退・延期）が書き換えられたときです。取り消しの動線に使います。朝まで待つと、その日に出た手配が無駄になります。

入力データを集める

中心は要件定義表です。 品目ごとに手配先と締切、初日に要るのか初週でよいのかを持ちます。

この表と合わせて、次のものを入力にします。

「初日／初週」の列を軽く見ないでください。 全部を初日締切にすると、締切が守れないことが前提の運用になります。初日に無いと本人が動けないもの（席、PC、アカウント、入館証、制服）と、初週でよいものを分けます。

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

すべてスプレッドシートの読み取りで足ります。

引き当ては、AIではなくワークフローの照合で行います。 4つの値をつないだ区分キーを作り、要件定義表の「対象となる区分」の列と突き合わせます。一致した行だけが品目の一覧になります。

営業日数の計算もワークフローの側に置きます。暦日で数えないでください。 連休をまたぐと3営業日前が実際には1週間前になります。会社の休業日を並べた表を1枚持ち、そこから数えます。

AIへ渡す前に整形する

1. 状態の確認 … 辞退・延期の状態の人を手配の対象から外します
2. 必須項目の確認 … 入社日、職種、配属、雇用区分のどれかが空なら、手配せず採用担当へ戻します
3. 区分キーの組み立て … 4つの値をつなぎ、要件定義表と突き合わせます
4. 営業日数の計算 … 休業日の表を使い、今日から入社日までの営業日数を出します
5. 当日分の抽出 … 営業日数が締切と一致する品目だけを残します
6. 既発行の除外 … 台帳に同じ品目の依頼済みの行があれば、二重に出しません
7. 渡す項目の絞り込み … 手配先ごとに、渡してよい項目だけを残します

2番目で止めるのは、埋めさせないためです。 雇用区分が空のままAIに渡すと、文章としては成立する依頼文が出てきます。

6番目は、毎朝動かす設計に必ず要ります。 入社日が書き換わると、同じ品目が再び締切に当たります。依頼済みかを台帳で見ないと、同じ依頼が二度飛びます。

AIに処理させる

させるのは、引き当て済みの品目一覧を、手配先ごとの文章にすることだけです。

1行目がいちばん起きやすい失敗です。 介護職の一覧に制服が入っていなければ、AIは「制服も必要ではないか」と書き足します。善意の補完ですが、要件定義表を直さないかぎり翌月には同じ抜けが再発します。 足したいものは別枠に出させます。

4行目は、この題材で最も守るべき線です。 AIに渡す段階で絞っていないと、渡してよい項目とそうでない項目の区別が文章の中で消えます。

指示内容を固定する

あなたは人事部で、入社予定者の受け入れ準備を関係部署へ依頼する立場です。
渡された「必要品目の一覧」だけを使って、手配先ごとの文面の下書きを作ってください。

【前提】
- 必要品目の一覧は、要件定義表から機械的に引き当て済みです。
- 締切日も営業日で計算済みです。どちらも作り直さないでください。

【作るもの】
mode が request なら手配の依頼文、reminder なら未完了の督促文、
cancel なら出した手配の取り消し依頼文を、手配先ごとに1通ずつ作ってください。

【厳守事項】
- 必要品目の一覧に無いものを、依頼文に足さないでください。
  必要だと思うものがあれば、本文には入れず unresolved に理由とともに書いてください。
- 締切日は渡された値をそのまま書いてください。日数を数え直さないでください。
- 本文に書いてよいのは、その手配先の allowed_fields にある項目だけです。
  一覧に無い項目（住所、私用の連絡先、生年月日など）は、
  入力に含まれていても本文に書かないでください。
- どの業務システムにどの権限を与えるかを、あなたが決めないでください。
  一覧に書かれた権限区分の名称をそのまま写してください。
- 完了したかどうかを書かないでください。完了は手配先の返答で決まります。
- cancel のときは、すでに発行・手配済みのものをどう扱ってほしいかを
  確認する一文を必ず入れてください。「破棄してください」と断定しないでください。
- 件名には入社日と社員番号を入れてください。氏名だけにしないでください。
- 本文に使った項目名を fields_used に並べてください。

【入力】
mode: {mode}
入社予定者: {hire}
必要品目の一覧: {items}
手配先ごとに渡してよい項目: {allowed_fields}
未完了の行（reminder のとき）: {open_items}

「一覧に無いものを足さない」を明記しないと、必ず足してきます。 介護職の受け入れという文脈を与えた時点で、制服や名札は自然に出てくる語だからです。禁じるのは補完そのものではなく、補完を依頼文に混ぜることです。

「入力に含まれていても書かない」も意図してのことです。 絞り込みは前処理で行いますが、督促の対象を探す過程で余分な列が混ざることがあります。

出力形式を固定する

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

{
  "hire_id": "",
  "start_date": "",
  "mode": "request | reminder | cancel",
  "messages": [
    {
      "assignee_dept": "情報システム | 総務 | 人事 | 配属先",
      "channel": "mail | chat",
      "subject": "",
      "body": "",
      "item_codes": [""],
      "due_date": "",
      "need_by": "day1 | week1",
      "fields_used": [""]
    }
  ],
  "unresolved": [ { "point": "", "reason": "" } ]
}

形を固定するのは、そのまま手配台帳の行になるからです。 Claude API には構造化出力があり、output_config.format に type: "json_schema" とスキーマを渡すと、制約付きデコードで、スキーマに沿った応答が保証されるとされています。スキーマ違反のためのやり直しが要らなくなります。

書くときに効く制約が3つあります。 第一に、オブジェクトの additionalProperties は false である必要があります。余計なキーが混ざらず、台帳の列とずれません。 第二に、enum と const が使えるので、assignee_dept、mode、need_by、channel は列挙で縛ります。第三に、minimum／maximum などの数値の制約と minLength／maxLength の文字数の制約は対応していません。 締切日が過去でないか、件名が長すぎないかは、ワークフロー側で確かめます。 再帰的なスキーマも対応外なので、messages は入れ子にせず平らに並べます。

fields_used を返させるのは、機械で確かめるためです。 allowed_fields に無い項目名が入っていたら、文面を読んで気づくのではなく照合で弾きます。

最初の1回だけ応答が遅い点は、運用の前に知っておいてください。 文法のコンパイルのぶんの遅延があり、コンパイル済みの文法は24時間キャッシュされるとされています。

システムへ連携する

人事システムへは書き込みません。 この構成が触るのは、要件定義表、手配台帳、下書きの3つだけです。手配先の各システム（アカウント管理、資産台帳、入館証の発行）にも直接つなぎません。つなぐと承認と監査の設計が一気に重くなります。そこまで踏み込むのは第9章の本格構成です。

人が確認する

人が見るのは、送る前の下書きと、完了の入っていない行だけです。 引き当てられた品目の一覧そのものは毎回は確認しません。要件定義表が正しければ結果も正しく、表が間違っていたら一覧を見ても気づけないからです。

1. 下書きを承認する … Zapier の Human in the Loop の Request Approval を使うと、レビュー担当にメール、Slack、または別の Zap 経由で確認が届きます。承認・却下のボタンの文言は各75文字までで、内容の編集を許すかも選べます
2. 時間が過ぎたときの動作を決める … 待ち時間は分・時間・日・週で指定でき、「応答なしで続行する」か「実行を終了する」を選べます。 この構成では実行を終了するを選びます
3. 未完了の行を見る … 督促の下書きに目を通し、送る相手と文面を確かめます
4. 取り消しを判断する … 辞退・延期のとき、何を取り消して何を残すかは人が決めます

2番目を「応答なしで続行する」にしないでください。 承認されていない依頼文が後続の処理に流れます。承認が漏れた日は、その日の手配が出ないほうが安全です。

目標は、20名をならして1名15分です。 下書きの確認が大半で、取り消しが発生した人だけ時間がかかります。

例外に対処する

最後の行を落とさないでください。 締切と営業日数が一致する日だけを見る設計にすると、動かなかった1日の手配が永久に出ません。 「締切に達したが依頼済みでないもの」を毎朝拾う形にします。

記録を残す

• 入社予定者の情報と、引き当てられた品目の一覧（引き当てに使った区分キーも残す）
• AIが返したJSONの全文と、fields_used の照合の結果
• 承認の記録（誰が、いつ、承認か却下か、編集したか）
• 依頼日、完了日、督促を送った日
• 取り消し依頼を出した日と、手配先からの取り消し完了の返答
• 要件定義表の変更の履歴（いつ、どの区分にどの品目を足したか）

1つ目で区分キーを残すのは、表が後から変わるためです。 当時どの行で引き当てたかが残っていないと、やり直しの範囲が決まりません。

最後の行は、この仕組みが育つかどうかを決めます。 unresolved に出た品目を表へ足した記録がたまるほど、抜けの多い区分がはっきりします。