退職日が決まった社員のメールボックス・OneDrive・Teams のデータの引継ぎ先を上長に確かめ、退職日から逆算した案内と督促を回す

処理の起点を決める

フローは2本に分けます。 1本目は人事の退職者リストに退職日が入ったときに動き、案内を作って送ります。2本目は平日の毎朝動き、未回答の項目の督促と、回答のそろったものの作業票への写しを行います。

日付は、退職日と最終出社日から逆算して決めます。 最終出社日の後は本人に確かめられないので、本人の確認が要る項目は最終出社日を基準にします。

回答の期限を最終出社日より前に置くのが、第3章の（a）への答えです。 期限が最終出社日と同じだと、本人に「この共有ファイルはどこへ移すか」を確かめる時間がありません。5営業日は、本人が引継ぎの合間にファイルを移せる日数として置いた値です。

退職日が入ってから最終出社日までが短い退職者もいます。回答の期限が案内の日より前になるときは、案内の日から2営業日後を期限にし、情報システム部のチャネルに「期限が短い」と出します。

入力データを集める

質を決めるのは、職種ごとの質問の型です。 第3章の（b）で担当者が頭の中で書き分けていたものを、表にします。営業なら顧客から届くメールの扱い、開発なら所有するチームと共有のリポジトリの案内、管理部門なら OneDrive に置いた共有のファイル、といった具合です。

所有するチームは、人が確かめて入れます。 ほかの所有者がいないチームは、退職後に管理する人がいなくなります。この一覧はAIに推測させず、情報システム部の担当者が案内の承認の前に入れます。

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

退職者リストは、トリガーが返す行の値をそのまま使います。 変更のたびに動くトリガーなので、退職日の列の値と、作業票にすでに行があるかを最初に確かめ、二度目の案内を出さないようにします。

Get manager (V2) は、取り出す項目を「Select fields」で絞れます。 公式ドキュメントでは、既定で選ばれる項目のどれかがテナントの方針で止められていると403で失敗することがあり、項目を指定すると避けられるとされています。氏名・UPN・部署だけを指定します。

AIへ渡す前に整形する

1. 退職日が入ったかの判定 … 退職日の列が空でなく、作業票に行が無いときだけ進みます
2. 上長の確認 … Get manager (V2) で引けなければ止まり、人事に確かめる依頼を出します
3. 上長が同時に退職するかの確認 … 上長も退職者リストにいれば、上長の上長を送り先にします
4. 日付の計算 … 営業日で数え、会社の休日の一覧を使います
5. 質問の型の選択 … 職種で質問の型を選び、所有するチームが1つ以上あればチームの項目を足します
6. 短い期限の印 … 回答の期限が案内の日より前なら、期限を置き直して印を付けます

3番目を軽く見ないでください。 組織の再編や事業の撤退では、上長と部下が同じ月に退職することがあります。上長に引継ぎ先を聞いても、その上長のデータもまもなく引継ぎの対象になります。

AIに処理させる

させるのは、渡された材料から、上長への案内・本人への案内・督促の3種類の文面を作ることだけです。

本人への案内には、チャットのファイルのことを必ず入れさせます。 Microsoft のサポートの説明では、チャットで送ったファイルは送った人の OneDrive for Business に保存され、その会話の相手だけに共有されるとされています。第3章の（c）の問い合わせは、ここを案内に書いていないことから起きます。

上長への案内には、「期限を過ぎるとどうなるか」を書かせます。 公式ドキュメントの内容に沿って、次の材料を渡します。

2行目がいちばん起きやすい失敗です。 部署の名前を渡すと、「同じ部署の○○さんを引継ぎ先にするのがよいでしょう」と書きます。上長は忙しいほど、その名前をそのまま回答に入れます。

指示内容を固定する

あなたは情報システム部で、退職する社員のデータの引継ぎについて、
上長と本人に送る案内と督促の文面を書く補助です。
誰に引き継ぐかを決めるのは上長です。あなたは文面を書くだけです。

【入力】
- 文面の種類：{message_type}（manager_notice／leaver_notice／reminder）
- 退職者：{leaver}（氏名、部署、職種、最終出社日、退職日）
- 上長：{manager}（氏名）
- たずねる項目：{items}（項目名と選択肢）
- 所有するチーム：{teams}
- 計算済みの日付：{dates}（回答の期限、督促の日、管理の操作の日）
- 未回答の項目（督促のとき）：{open_items}
- 督促の回数：{reminder_count}
- 期限を過ぎたときの影響の材料：{impact_notes}

【してほしいこと】
1. 文面の種類に応じて、件名と本文を書いてください。
2. 日付は計算済みの日付をそのまま使ってください。
3. 上長への案内では、たずねる項目を箇条書きにし、
   回答の期限と、期限を過ぎたときの影響を1〜2文で書いてください。
   影響は「期限を過ぎたときの影響の材料」に書かれた内容だけを使ってください。
4. 本人への案内では、チャットで送ったファイルが本人の OneDrive に
   置かれていることと、最終出社日までに共有の場所へ移すことを書いてください。
5. 督促では、未回答の項目だけを書いてください。
   1回目は丁寧に、2回目は期限を過ぎたことをはっきり書いてください。

【厳守事項】
- 日付を計算したり、書き換えたりしないでください。
- 引継ぎ先の候補となる人の名前を挙げないでください。
- 材料に無い管理の手順や、保持の日数を書かないでください。
- 「必ず復元できます」など、データを取り戻せると約束しないでください。
- 退職の理由や、退職者の評価に触れないでください。
- 本文は400字以内にしてください。
- 回答に JSON マークダウンを含めないでください。

「材料に無い保持の日数を書かない」を明記しないと、もっともらしい日数を書きます。 保持の期間は会社の設定で変えられるので、自社の設定と違う日数が上長に届くと、上長はその日数を信じて回答を後回しにします。 影響の材料は、情報システム部が自社の設定に合わせて書いた文を渡します。

督促の回数で調子を変えさせるのは、第4章の③で担当者がしていたことです。 1回目と2回目で同じ文面だと、2回目が読み飛ばされます。

最後の1行は、公式ドキュメントの FAQ にある対処です。 モデルが JSON をマークダウンで囲むと形式の検証が通らないことがあり、この一文を足すよう案内されています。

出力形式を固定する

プロンプトの出力を JSON にし、次の形の例を渡して形式を「カスタム」で保存します。

{
  "message_type": "manager_notice",
  "subject": "",
  "body": "",
  "listed_items": [ { "item": "" } ],
  "dates_used": [ { "label": "", "date": "" } ]
}

1つ目の理由は、使った日付をフローの側で確かめられることです。 dates_used の日付が、フローが渡した日付と1つでも違えば、その文面は送らずに担当者へ回します。 本文の中の日付を目で追わなくても、日付の書き換えを止められます。

2つ目は、たずねた項目を確かめられることです。 listed_items と、渡した項目の一覧を比べ、抜けた項目があれば担当者へ回します。 本人への案内でチャットのファイルの項目が抜けていないかも、ここで見ます。

3つ目は、形式が固定されることです。 公式ドキュメントでは、プロンプトを保存すると形式がロックされ、フローでは保存された形式が使われるとされています。フィールドのキーの無い JSON はサポートされないので、listed_items と dates_used はキー付きの要素の配列にしています。

上長に届く案内は、たとえば次のようになります。

【退職者のデータの引継ぎ先のご確認】山田 花子さん（営業部）
最終出社日：11月20日　退職日：11月30日
次の3点について、11月13日までに回答用のリストでお知らせください。
・顧客から届くメール：転送／共有メールボックスにして閲覧者を指定／不要
・OneDrive のファイル：引き継ぐ人／不要
・所有者になっているチーム「関西営業」：後任の所有者
期限を過ぎると、本人にファイルの置き場所を確かめる時間が無くなります。
→ 回答用のリスト（リンク）

システムへ連携する

管理の操作は、フローに入れません。 メールボックスの変換、OneDrive のアクセス権の付与、サインインの停止、ライセンスの削除、アカウントの削除は、情報システム部の担当者が作業票を見て行います。 Microsoft の公式ドキュメントが示す元社員の削除の手順も、サインインの停止、メールボックスの内容の保存、転送または共有メールボックスへの変更、OneDrive と Outlook のデータへのアクセスの付与、ライセンスの削除、アカウントの削除と、段階に分かれています。

作業票に入れる操作の順番は、公式ドキュメントの注意に沿って決めます。

Teams への投稿の上限にも気を付けます。 公式ドキュメントでは、メッセージの大きさは約28KBが上限で、フロー ボットの操作は接続あたり300秒で25回とされています。月15人の退職では、上限に届くことはまずありません。

人が確認する

人が確かめるのは、案内を送る前と、管理の操作の前の2か所です。

1. 案内を送る前 … 担当者が上長と本人への案内を読み、所有するチームの一覧を入れて承認します。退職者リストの情報に誤りがあれば、ここで止まります
2. 回答がそろったとき … 作業票に写された引継ぎ先を見て、引継ぎ先も退職予定でないか、社外の人になっていないかを確かめます
3. 管理の操作の前 … 作業票の順番どおりに、計算された日に操作します。操作した日と担当者を作業票に入れます

1番目を省かないでください。 退職の情報は、本人と上長と人事のあいだでまだ公表していない段階のことがあります。案内が届く時期と相手を誤ると、公表前の退職が周りに伝わります。 人事が「公表日」を入れている場合は、その日より前に案内を送らない条件も足します。

督促は、人の確認を経ずに送ります。 中身は未回答の項目と期限だけで、毎回人が見ると、督促が予定の日に届かなくなります。 ただし2回目の督促は情報システム部のチャネルにも出し、担当者が上長に直接声をかけるかを決めます。

例外に対処する

上から2行は、Microsoft Entra ID の上長の登録の問題です。 上長が登録されていないと、この構成で送り先が決まらないだけでなく、退職後に OneDrive へのアクセス権が自動で誰にも渡りません。 公式ドキュメントでは、上長も2番目の所有者も設定されていなければ、削除のときに誰にも自動のアクセス権が付かず、削除の通知も届かないとされています。例外の件数が、上長の登録を整える材料になります。

記録を残す

• 退職者ごとの案内と督促の文面（AIが返した JSON の全文）と、送った日時・送り先
• 案内の承認をした担当者と日時
• 項目ごとの回答と、回答の日時
• 作業票の操作ごとの予定日・実施日・担当者
• 回答の期限までに回答がそろった割合
• 退職後に届いた「データが見られない」という問い合わせと、その原因

5つ目が、この構成の効き目を測る数字です。 督促の回数が減ることより、期限までにそろう割合が上がることのほうが、管理の操作を予定の日に行えることに直結します。

最後の行は、案内の文面を直す材料です。 問い合わせの原因がチャットのファイルなら本人への案内を、共有メールボックスの閲覧者なら上長への質問の型を直します。保存期間は、人事の退職者の記録に合わせます。