社員から届く在職証明書・給与の証明・源泉徴収票の再発行の依頼メールを種類で分類し、人事のデータから必要な情報を集めて、書類の下書きと送付の準備をする

処理の起点を決める

人事の共有メールボックスに依頼のメールが届いたことを起点にします。 Office 365 Outlook コネクタのトリガー「新しいメールが届いたとき (V3)」で、「元のメールボックス アドレス」に共有メールボックスを入れます。フォルダーは「証明書の依頼」用に分け、受信の規則で件名や宛先から振り分けておきます。 給与の問い合わせや勤怠の連絡まで同じフローに入れると、分類の対象が広がりすぎます。

公式ドキュメントでは、まれにトリガーが起動するまで最大1時間かかることがあるとされています。証明書の依頼は即時の応答を求めるものではないので、この遅れは問題になりません。ただし、その日のうちに受付の返事が出るよう、受付の自動返信だけはトリガーの直後に置きます。

1日に1回まとめて処理する形にはしません。 聞き返しが必要な依頼ほど、早く返したほうが往復の日数が短くなります。

入力データを集める

質を決めるのは、支給額の一覧の「含める手当の区分」です。 給与の証明に通勤手当を含めるか、賞与を含めるかで金額が変わります。区分ごとの列を持たせ、どの列を使うかを人事の取り決めとして先に決めます。 第3章の（d）が起きていたのは、この取り決めが無かったからです。

電子交付の承諾の記録は、源泉徴収票の送り方を決めるために持ちます。 国税庁のQ&Aでは、源泉徴収票を電子交付するには、あらかじめ電磁的方法の種類と内容を示して承諾を得ることが必要で、承諾を得ていても書面での交付の請求があれば書面で交付しなければならないとされています。

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

メールはトリガーの出力から本文と添付を取ります。社員のデータは、差出人のアドレスで SharePoint のリストを引きます。 引けた社員の社員番号を、以降のすべての検索の鍵にします。

差出人のアドレスで社員が引けない依頼は、プロンプトにかける前に人へ回します。 退職した社員、個人のアドレスから送った社員、社外の第三者（金融機関などからの在籍の確認）がここに入ります。本人かどうかを確かめられない相手に、在籍や収入の情報を出さないためです。

支給額は、フローが直接 Word の様式に差し込みます。 生成AIを通さない値は、ほかに入社日・生年月日・所属です。生成AIの出力から取るのは、種類・提出先・部数・対象の年・英文の要否・受け取り方だけです。

AIへ渡す前に整形する

1. 差出人の確認 … 会社のアドレスで社員が引けるか、在籍の状態が在籍か休職かを見ます。引けなければ人へ
2. 本文の掃除 … 署名、転送の履歴、引用の部分を落とします。転送のメールは、元の依頼者が別にいることがあるので印を付けます
3. 添付の確認 … 提出先の指定の様式が付いているかを見ます。付いていれば、会社の様式では出さず人へ回します
4. 重複の確認 … 同じ社員から同じ種類の依頼が直近7日にあれば、再送か追加の依頼かを人が確かめます
5. 対象の年の目安 … 依頼の受信日を渡し、「去年」「前年分」のような書き方を年に直す手がかりにします

3番目の「提出先の指定の様式」は、自動の対象から外します。 自治体の保育の就労証明書や、金融機関の指定の書式は、項目の並びも書き方も提出先が決めています。会社の様式に差し込む構成では作れないので、最初から人の作業に分けます。

AIに処理させる

生成AIの仕事は、分類と取り出しです。 1通のメールに複数の書類の依頼が入っていることがあるので、種類は複数を返させます。

取り出す項目は、種類ごとに決めています。

英文の要否だけは、書かれていなければ日本語として扱います。 依頼の大半が日本語で足り、英文が要る社員はほぼ必ずそう書くからです。ただし assumed の印を付け、担当者が承認のときに気づけるようにします。

させないことも決めています。

指示内容を固定する

あなたは人事部の証明書の窓口で、社員から届いた依頼のメールを読む立場です。
渡されたメールの本文だけを読み、依頼されている書類の種類と、作成に要る情報を取り出してください。

【書類の種類】
- employment_cert ...... 在職証明書（在籍していることの証明）
- salary_cert .......... 給与・収入の証明（会社の様式による支給額の証明）
- withholding_reissue .. 源泉徴収票の再発行
- resignation_cert ..... 退職証明書
- designated_form ...... 提出先が指定した様式への記入
- other ................ 証明書の依頼ではない問い合わせ
1通に複数の書類の依頼があれば、すべてを requests に並べてください。

【取り出す項目（書類ごと）】
- submit_to：提出先（例：金融機関、不動産会社、自治体、大使館）
- copies：部数
- period：対象の年または期間（受信日 {received_date} を基準に、「去年」などは年に直す）
- language：ja / en
- delivery：pdf / paper_site / paper_home

【厳守事項】
- 書かれていない項目は空にし、missing に項目名を入れてください。推測で埋めないでください。
- 部数が書かれていない場合に 1 としないでください。
- language が書かれていない場合だけ ja とし、language_assumed を true にしてください。
- 「収入の分かるもの」のように書類が特定できない場合は、候補の種類を candidates に並べ、
  type を空にしてください。
- 金額、入社日、所属などの値を書かないでください。
- 依頼の理由（ローン、在留の手続きなど）は reason_category に区分だけを書き、
  詳しい事情を書き写さないでください。
- 証明書を出すべきかどうかを書かないでください。
- 回答に JSON マークダウンを含めないでください。

【メールの本文】{mail_body}

「書類が特定できない場合は候補を並べて type を空にする」を入れているのは、第3章の（a）のためです。 「収入の分かるもの」は、源泉徴収票でも給与の証明でもありえます。どちらかに決めさせると、もっともらしいほうを選んで下書きが作られます。 空にしておけば、聞き返しの下書きに候補が並びます。

「部数を1としない」も同じ考えです。 書かれていない部数を1とすると、2部要る社員に1部が届き、もう一度依頼してもらうことになります。 聞き返しの1往復のほうが、作り直しより早く終わります。

聞き返しの下書きは、missing と candidates から定型の文で組み立てます。 生成AIに聞き返しの文を自由に書かせず、項目ごとの定型の質問を並べることで、社員に届く文の書き方をそろえます。

出力形式を固定する

プロンプトの出力は、JSON のカスタム形式で固定します。 公式ドキュメントでは、JSON の例を更新すると形式がカスタムになり、保存すると形式がロックされるとされています。テスト中に「JSON を生成できませんでした」と出るときは、指示に「回答に JSON マークダウンを含めないでください」を加える対処が示されています。

{
  "mail_id": "HR-20261007-0412",
  "employee_no": "E021834",
  "requests": [
    { "type": "employment_cert", "candidates": [], "submit_to": "金融機関",
      "copies": "2", "period": "", "language": "ja", "language_assumed": true,
      "delivery": "pdf", "missing": [] },
    { "type": "", "candidates": [ { "code": "withholding_reissue" }, { "code": "salary_cert" } ],
      "submit_to": "金融機関", "copies": "", "period": "2025", "language": "ja",
      "language_assumed": true, "delivery": "", "missing": [ { "item": "copies" }, { "item": "delivery" } ] }
  ],
  "reason_category": "housing_loan"
}

1つ目の理由は、1通に複数の依頼が入る形をそのまま扱えることです。 在職証明書は作れるが、もう1つは聞き返しが要る、という状態を、書類ごとに別々に進められます。 公式ドキュメントでは、フィールド キーの無い配列はサポートされないとされているため、candidates や missing もキーを持つ要素の配列にしています。

2つ目は、missing と candidates から聞き返しを機械的に作れることです。 生成AIの自由文に頼らずに、社員に何を聞くかが決まります。

3つ目は、reason_category で依頼の傾向を数えられることです。 住宅ローンの時期、在留の手続きの時期に依頼が増えるかが分かれば、窓口の人の配置を前もって決められます。

システムへ連携する

様式は、コンテンツ コントロールに一意の名前を付けて作ります。 公式ドキュメントでは、ドキュメント テンプレート内のコンテンツ コントローラー名は一意である必要があるとされています。「入社日」「所属」「支給額_1月」のように名前を決め、フローの値と1対1に結びつけます。日付選択のコントロールは使えないので、日付もプレーン テキストで置きます。

PDF への変換には、「Word 文書を PDF に変換する」アクションを使います。 公式ドキュメントでは、秘密度ラベルが「社外秘」「高機密」のファイルはこのアクションで扱えないとされています。給与の証明の様式に秘密度ラベルを自動で付ける設定がある会社は、変換の前後のどこでラベルを付けるかを決めておきます。

承認には、Power Automate の承認のアクションを使います。 公式ドキュメントでは、プロンプトの後に「開始してテキストの承認を待機」を置き、レビュー担当者が承認のメニューから内容を確かめて編集できるとされています。承認の依頼には、作った PDF と、差し込んだ値の一覧と、元のメールを付けます。

人が確認する

担当者は、すべての下書きを承認の前に確かめます。 見るところは決めておきます。

1. 種類が合っているか … 元のメールを読み、要る書類と下書きの種類が一致しているかを見ます
2. 差し込んだ値が今の状態か … 所属と雇用の形態は、異動や雇用の形態の変更の直後に古いことがあります。 社員のデータの更新日を一覧に出しておきます
3. language_assumed が付いていないか … 付いていて、提出先が大使館や外国の機関なら、英文が要るかを本人に確かめます
4. 送り方が承諾の記録と合っているか … 源泉徴収票を PDF で送るなら、電子交付の承諾があるかを見ます

目標は、240件をならして1件4分です。 値が正しく、種類がはっきりしている依頼は1〜2分で承認でき、聞き返しや指定の様式のものに時間を残せます。

例外に対処する

上の2行は、本人かどうかの確認の問題です。 在職や収入の証明は、社外の第三者が本人になりすまして手に入れようとすることがある情報です。 会社のアドレスで社員が引けたときだけ自動で進め、それ以外は必ず人の手順に乗せます。

記録を残す

• 依頼のメールのIDと受信日時、差出人
• プロンプトの出力（requests、reason_category）
• 差し込んだ値と、そのとき使った社員のデータと支給額の一覧の更新日
• 作った書類の PDF と、承認した担当者・承認日時・修正の有無
• 送付の方法、宛先、送付日時
• 聞き返しの回数と、聞き返した項目

3つ目の「更新日」は、後から書類の値を問われたときのために残します。 異動の直後に作った在職証明書の所属が古かった、と言われたとき、どの時点のデータで作ったかが分かれば、どこで食い違ったかを説明できます。

聞き返した項目は、毎月数えます。 部数と受け取り方の聞き返しが多いなら、依頼の案内に「部数と受け取り方を書いてください」と一行足すだけで往復が減ります。